VPLS with BGP Autodiscovery

Previously in E-LAN and E-Tree, we used VPLS with manual neighbors. We had to manually specify each remote PE with this command:

l2vpn vfi context NAME
 neighbor <address> encapsulation mpls

Imagine if a customer has 50 locations in this VPLS domain. If we had dozens of PEs, it would be a huge pain to manually add every single PE to every single other PE’s l2vpn vfi configuration. Remember that VPLS is a full mesh of pseudowires between all participating PEs. (You could say that E-Tree is an exception though, because PEs with only leafs do not need to have a psuedowire between them).

Using BGP to auto-signal which PEs are participating in the VPLS domain is a solution to this scalability issue.

With BGP, we can use the l2vpn vpls address-family in a similar way that you might be familiar with vpnv4 for L3VPN.

When a PE belongs to a VPLS domain, it advertises a BGP update that contains an RD and an export RT (using an extcommunity), to all iBGP peers. Other iBGP peers, if they have a VPLS domain which has an import RT which matches the RT of the l2vpn vpls route, will add the PE as a new pseudowire for the VPLS domain.

This BGP advertisement does not necessarily include the MPLS label to use for the service, however. With BGP autodiscovery, you have a choice to learn the service label for the pseudowire with LDP (as we have been doing up to this point), or using BGP.

To summarize, autodiscovery is the method by which PEs learn of other PEs. You can use manual (which we did before), or BGP for autodiscovery. Autosignaling is the method that PEs learn which service label to use when sending frames to other PEs. In this aritcle we will demonstrate both BGP autodiscovery with LDP autosignaling, and BGP autodiscovery with BGP autosignaling.

Lab

We will re-use the VPLS topology from the E-LAN article.

OSPF and LDP are pre-configured in the MPLS core, as before.

First, we’ll configure BGP in the MPLS core. P4 will be a route reflector.

PE1,2,3#
router bgp 65000
 bgp log-neighbor-changes
 neighbor 4.4.4.4 remote-as 65000
 neighbor 4.4.4.4 update-source Loopback0
 !
 address-family l2vpn vpls
  neighbor 4.4.4.4 activate
  neighbor 4.4.4.4 send-community extended
 exit-address-family

P4#
router bgp 65000
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 65000
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 2.2.2.2 remote-as 65000
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 3.3.3.3 remote-as 65000
 neighbor 3.3.3.3 update-source Loopback0
 !
 address-family l2vpn vpls
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 route-reflector-client
  neighbor 1.1.1.1 send-community extended
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 route-reflector-client
  neighbor 2.2.2.2 send-community extended
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 route-reflector-client
  neighbor 3.3.3.3 send-community extended
 exit-address-family

In order to generate L2VPN VPLS “routes” we will remove the manual neighbors from the VFI, and add the autodiscovery bgp command.

First let’s use LDP signaling with BGP autodiscovery. Here’s the configuration on PE1 after removing the manual members.

PE1#show run | sec l2vpn
l2vpn vfi context CUSTOMER_VPLS
 vpn id 100
 autodiscovery bgp signaling ldp

PE1#show run | sec bridge
bridge-domain 1 
 member GigabitEthernet2 service-instance 100
 member vfi CUSTOMER_VPLS

As you can see, you can simply use a single command to turn this feature on. This is because by default, the router will auto-generate the RD and RT values. These are both <BGP ASN>:<VFI VPN ID>. If you’d like, you can specify the RD and RT values you would like to use.

Below is the route that PE1 advertised:

The BGP NLRI (”route”) is the PE’s loopback (which is 1.1.1.1), prepended with the RD of 65000:100. 65000 is the BGP ASN and 100 is the VFI VPN ID.

Let’s configure PE2 now. Notice how the targeted LDP session comes up between PE1 and PE2 once you exit out of the vfi configuration mode. PE1 and PE2 discovered each other as neighbors through BGP, and then used targeted LDP to signal the service label to each other.

PE2(config)#l2vpn vfi context CUSTOMER_VPLS
PE2(config-vfi)# vpn id 100
PE2(config-vfi)# autodiscovery bgp signaling ldp
PE2(config-vfi-autodiscovery)#exit
PE2(config-vfi)#exit
PE2(config)#
*Jun 30 23:55:18.067: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (2) is UP

When we configure PE3, we should see two LDP sessions come up.

PE3(config)#l2vpn vfi context CUSTOMER_VPLS
PE3(config-vfi)# vpn id 100
PE3(config-vfi)# autodiscovery bgp signaling ldp
PE3(config-vfi-autodiscovery)#exit
PE3(config-vfi)#exit
*Jun 30 23:58:01.694: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (2) is UP
*Jun 30 23:58:01.697: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (3) is UP

At this point, traffic between the CEs should work.

Here’s the CE configuration:

CE1#
interface GigabitEthernet0/0
 ip address 10.1.1.1 255.255.255.0
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

CE2#
interface GigabitEthernet0/0
 ip address 10.1.1.2 255.255.255.0
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

CE3#
interface GigabitEthernet0/0
 ip address 10.1.1.3 255.255.255.0
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

We have full OSPF adjacencies:

CE1#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:39    10.1.1.2        GigabitEthernet0/0
3.3.3.3           1   FULL/DROTHER    00:00:39    10.1.1.3        GigabitEthernet0/0

This data plane is exactly the same as the VPLS configuration in E-LAN, with the only difference being that we do not need to manually specify members of the VFI any longer. We use BGP to discover PEs that belong to the VFI.

BGP Auto-Signaling

Instead of using LDP signaling, let’s turn on BGP signaling. Now the PEs will learn the service label of other PEs through iBGP instead of targeted LDP sessions.

This reduces a lot of state in the network - instead of a full mesh of targeted LDP sessions, we simply add one more attribute to the L2VPN VPLS route that is already present in the BGP table. In most situations, if you are turning BGP autodiscovery on, you will likely want to use BGP for signaling as well. This mitigates the burden of maintaining n LDP sessions, one per PE participating in the VPLS domain.

Make sure you delete the VFI first, and then change to bgp signaling. You must remove the VFI as a member of the bridge-domain before you can delete the VFI.

PE1(config)#l2vpn vfi context CUSTOMER_VPLS
PE1(config-vfi)#autodiscovery bgp signaling bgp
% VFI auto-discovery signaling protocol changes are not allowed. Delete the VFI and reconfigure.

In order for the PE to advertise its new BGP route with the service label, you need to supress the LDP signaling protocol under BGP. If you forget to do this on a PE, it will not advertise its route to the router reflector (P4). If you forget to do this on the RR, it will not reflect the route to its clients (other PEs).

PE1,PE2,PE3#
l2vpn vfi context CUSTOMER_VPLS
 vpn id 100
 autodiscovery bgp signaling bgp
   ve id [1,2 or 3]
!
bridge-domain 1
 member vfi CUSTOMER_VPLS
!
router bgp 65000
 address-family l2vpn vpls
  neighbor 4.4.4.4 suppress-signaling-protocol ldp

P4#
router bgp 65000
 address-family l2vpn vpls
  neighbor 1.1.1.1 suppress-signaling-protocol ldp
  neighbor 2.2.2.2 suppress-signaling-protocol ldp
  neighbor 3.3.3.3 suppress-signaling-protocol ldp

Here is PE1’s advertised route now:

First notice that the prefix is now a /136 instead of a /96 as we saw earlier when using LDP signaling. This is because the VE ID and VE block size are included in the prefix. (More on that later).

Another difference is that now MTU is signaled through BGP, as well as the MPLS outbound label base value (27). This is the base of the label range, which will make more sense as you read on. This is how BGP replaces the functionality of the targeted LDP sessions. (Remember that the MTU of the VFI is signaled and must match on each PE!)

The difference between the way BGP allocates labels for L2VPN VPLS and L3VPN, is that with L3VPN there is a single label that represents the route or all routes in the VRF (depending on how you allocate labels). However, remember that with L2VPN VPLS, we are replacing a full mesh of targeted LDP sessions. In L2VPN the router is preforming MAC learning, whether using BGP signaling or LDP signaling, so the router needs to know which PE the frame came from because it is preforming MAC learning. With L3VPN the router does not care which particular PE the packet came from, so all remote PEs can use the same service label for a given PE.

If L2VPN VPLS advertised only a single label, how would PE1 know whether a frame arrived from PE2 or PE3? (The answer is that it wouldn’t be able to differentiate!)

If using LDP signaling, it would know based on the label received. PE1 would advertise label X to PE2 on the targeted LDP neighborship, and label Y to PE3. A frame arriving with label X was known to have come from PE2, and so the corresponding MAC entry can be added to the CAM table with outgoing interface of the pseudowire to PE2. Likewise for label Y. This label allocation per-PW or "per-PE" happens automatically when using LDP signaling.

In order to solve this issue in BGP, there is a label base value that each PE advertises, and a label block size. Each PE has its own unique VPLS Endpoint (VE) ID, which you specified above in the configuration above (ve id [1,2 or 3]). Each remote PE picks a label from a PE’s advertised label block, so that the advertising PE knows which PE sent it a frame when it sees the label.

The label block size is defined with the VE range value, which by default is 10. Since we did not specify ve range [11-100], we are using the default of 10 which you can see in the ‘Block Size’ attribute in the BGP route. This limits us to 10 PEs in the VPLS domain. As you can probably guess, there is a maximum of 100 PEs permitted, using the command ve range 100.

An example may help. In this lab, we have three PEs, and the default label block size of 10. Each PE chooses a dynamic label to start the block.

Let’s use the following command to see each PE’s advertised label base:

PE1’s block starts at 27 and ends at 36. PE2 is 16-25, and PE3 is also 16-25.

That command doesn’t show you the label size, so if you wanted to double check what the label block size is for each PE, you can look at the details of the BGP udpate that the PE advertised:

Let’s say for PE1’s block, PE2 might pick label 32, and PE3 might pick label 34. So if PE1 receives a frame with label 34, it knows the frame originated at PE3.

The math used by a PE to determine which label in the remote PE’s label block to use is a little too complex for this article, but we can check which label the PE uses by using this command: show l2vpn vfi name CUSTOMER_VPLS

This tells us that a frame with label 29 came from PE3, and a frame with label 28 came from PE2. Both PE2 and PE3 use the same label base and label block size, so the math worked out that PE1 will use label 16 for frames sent to both PE2 and PE3.

To recap, the local label column is the label the PE will see when it is the egress PE. The remote label column is the label the PE will push when it is acting as the ingress PE, forwarding traffic to remote PEs.

Looking at the LFIB, we can see that frames with label 28 and 29 are in use and have seen traffic. Labels 27 through 36 are all reserved. Until additional PEs join the VPLS domain, they will all have an action of “drop.”

Let’s verify what a packet sourced from CE1 to CE3 looks like by capturing on PE1’s outgoing interface, Gi1, towards P4:

We see the top label is the label for PE3’s loopback (3.3.3.3) and the bottom label the service label for PE3 (16) which we learned through BGP.

Let’s see what a packet from CE3 to CE1 looks like, capturing on PE3’s outgoing interface, Gi1, towards P4:

The bottom label is 29, which as we saw earlier, is PE1’s local label for the pseudowire to PE3.

Futher Reading

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/virtual-private-lan-services-vpls/116121-tech-vpls-bgp-00.html