VPLS with BGP only
Load basic.vpls.ldp.init.cfg
The CE routers CE1-3 are preconfigured with EIGRP.
Configure VPLS and verify that the EIGRP neighborships come up.
Use BGP for both autodiscovery and signaling of the service label.
Use R4 as the RR for VPLS services.
Answer
Explanation
With BGP used for the signaling of the VPN label, we can get rid of the targeted LDP sessions that were previously used to enable VPLS.
The problem with using BGP for signaling of the VPN label is that a unique label is required for every single remote PE. This was handled automatically with LDP previously, because each LDP session is point to point and is a full mesh between all PEs. Every PE advertises a different service label to each remote PE for the same VPLS domain. This allows a PE to know which remote PE a frame arrived from in order to do proper MAC address learning. (If every remote PE used the same label when sending traffic to the local PE, the local PE wouldn’t be able to differentiate which PE the traffic arrived from).
In BGP, this could have been solved by having the PE advertise one BGP Update per remote PE. However, this would not be very scalable, as each PE would recieve n*PE updates for each VPLS domain - an update per PE from each remote PE. Each PE is only interested in one single update from each PE though - the update that has its own label.
A mathematical formula is used instead to scale this. Each PE advertises one update per VPLS domain. This update contains a block of labels that the remote PEs can choose from. Each PE uses a formula to determine which label in that block it uses. The local PE uses the same formula, so they both understand which label is in use for that pseudowire even though it is never explicitly signaled - it is instead calculated based on the block values and the VE ID values.
Note that if you are having trouble understanding this, the books MPLS Fundamentals and MPLS-Enabled Applications might help you understand these ideas. If you are still having trouble, I would suggest continuing on with the lab and coming back to the theory later. (It may make more sense once you fully understand how the big picture works).
The BGP update contains the RD and RT values as we would expect. It also contains a VE ID, which must be unique per PE. It contains a block offset (where the block starts), a block size (how many labels are in the block), and a label base (the starting number for the label block).
The VE ID and block offset are contained in the prefix itself. The block size and label base are contained in the NLRI attributes.
The MTU and control word are signaled in the Update as well, as an extcommunity.
Block size and Block offset
The VE block size (VBS) has a default value of 10. It can be changed using the ve range command
The VE block offset (VBO) is the offset to use when multiple label blocks need to be created by a PE. The offset it calculated using the following formula:
When using VE IDs with low values, this will result in a block offset of 1 (the formula will result in round(1/10) * 10, and the round portion reduces to 0 which produces 1).
As another example, if using the defaults with a VE ID of 100, you will see an offset value of 100:
Basically, the offset value ends up being close to the VE ID, but rounding down. So if the VE ID above was 101 or 102, the offset would still be 100. This will ensure that each PE can pick a free label in a given block.
Each PE must advertise a label block that satifies all remote PEs in the VPLS domain. Let’s say we use the defaults of VE block size 10 on all routers. If there are VE IDs 1,2,3 and 15 in the domain, every router will have to advertise two blocks:
A block with offset 1 to satisfy VE IDs 1,2,3
A block with offset 10 to satisfy VE ID 15
For this reason, you never really run out of available labels, because as remote PEs start using higher and higher VE IDs, new label blocks need to be allocated and advertised on all PEs in the domain to satisfy these higher VE IDs.
An example of block offset
Currently all VE IDs are within the range 1-10, so only one block is advertised by each PE:
Each PE will calculate its label value for each PE. We can see this using show vfi
It appears that the formula is fairly simple. Because R1’s VE ID is 1, it uses the first label in each PE’s block. We can see this on R3 and R5. R1 is using the remote label as 57 for R3, and 59 for R5. These are the first available labels in the block:
Let’s change R1’s VE ID to 100. This will force R3 and R5 to advertise additional label blocks with an offset of 100. This is because they still need to support each other (R3 and R5) on the block with offset 1, but now need to also support R1 with its VE ID of 100.
Now examine the remote labels on R1:
It’s now grabbing the first label in the new blocks allocated on R3 and R5:
What this means is that you never run out of label space. As new VE IDs are seen that require a new label range, the label range is automatically reserved and advertised as a new BGP update.
The label block size is just an efficiency mechanism - if you have only 3 PEs, you don’t want to reserve 100 labels when 97 will be unused. Instead you can always just keep the default lowest block size and the router will automatically create more blocks as required.
Verification
Verification of the label values and advertisements was seen above. Verifying the bridge-domain and CE connectivity is the same as in the previous labs:
Last updated
