In this article we will explain the several protocols and Junos configurations that can be used to design a simple VPLS domain. We will also provide some troubleshooting commands and some recommendations.
The topology for the different scenarios covered is depicted below:
As you can see, we want to interconnect 3 CEs (in grey) in a VPLS architecture. Each CE is connected via a VLAN to a dedicated PE. The core network is made of P routers that only have ISIS and LDP enabled. A Route Reflector is in charge of distributing BGP NLRI between the PEs.
We will cover different scenarios, but each time the result should be the same: the 3 CE can communicate between each other. The 3 CE are in the same subnet (192.168.1.0/24)
The scenarios covered will be:
- Use BGP as VPLS auto-discovery and signalling protocol
- Use LDP as VPLS signalling protocol
- Use a mix of BGP and LDP.
- Use BGP as auto-discovery protocol and LDP as signalling protocol.
Generic PE/CE configuration
On each PE the interface connected to CE is configured like this:
With this encapsulation type the VLAN-ID must be 512 or higher. For this reason we used VLAN-ID 600. With flexible-vlan encapsulation it is possible to use VLAN-IDs below 512.
Case 1 - BGP as auto-discovery and signalling protocol
The use of a Route-Reflector in this kind of configuration should be a must have. Indeed, in order to avoid a full mesh of all the PE and to have a better scaling and flexibility the RR is highly recommended. The BGP family configured between each PE and the RR is the following - Hereafter the configuration of PE1:
With BGP as protocol you need to define a unique Site identifier per PE. For our topology we set: Site 1 for PE1, Site 2 for PE 2 and Site 3 for PE3. Moreover you need to define also the maximum number of Sites. In our case we plan to have a maximum of 8 Sites. Remember that the VPLS Label allocation with BGP as signalling protocol follows those rules: (more information can be find there to complete your study): http://kb.juniper.net/library/CUSTOMERSERVICE/technotes/Understanding_VPLS_Label_Blocks_Operation.pdf)
Let's move on to the VPLS routing-instance configuration. For each PE you need to configure a unique Route-Distinguisher and a unique Site Identifier as mentioned above.
Now, it's time to verify if all PE exchange well their VPLS Routes. On PE1 we can see the local L2VPN routes and the 2 remote L2VPN routes:
The VPLS connections toward the 2 other PEs (site 2 and site 3) on PE1 should be in UP state:
And finally we can check if MAC Learning is ok in our VPLS domain work well. We started before that "pings" from CE1 to CE2 and CE3 and now we are going to check the Forwarding Database of PE1 by calling this following command:
The First MAC address is the local MAC address of the the CE1 directly attached to the PE1 via the VLAN 600 (interface ge-0/0/2). The 2 other MAC addresses are remote CEs MAC. As you can see, those MAC addresses are reachable via MPLS.
Case 2 - LDP as signalling protocol
Now, let's try to see another approach by first removing our BGP configuration and configure LDP to allow Targeted LDP Session establishment. To do that simply add the interface lo0 within "protocols ldp".
Keep in mind that we keep LDP as transport label allocation protocol and the p2p LDP sessions between PE/P and P/P routers. Here we want to allocate the inner Label (the L2VPN label) between each PEs. In this case the L2VPN label is allocated by each PE and sent to each others via a dedicated T-LDP session (via the FEC 128).
So for each PE add the lo0 interface in ldp.
Remember that just setting up interface lo0.0 in ldp is not enough to trigger the initialization of T-LDP sessions. Indeed, there is no auto-discovery mechanism in this case. PE1 is not aware of remote PE2 and PE3. We need to specify explicitly for each PE which are its remote neighbors. We do that within the L2VPN routing-instance like this.
Hereafter the configuration of PE1:
With LDP as signalling protocol the routing-instance is a little bit more simple to configure. Indeed, there is no need of route-distinguisher or route-target. Here, we just need to specify a global VPLS- ID (here 1234) - which is unique within the Domain and configured on each PE that want to join this VPLS. Then, you have to configure the IP address of each remote PE. This part of configuration trigger the T-LDP sessions establishment.
So it's enough regarding the configuration, let's move on to check our VPLS connections, again on PE1. First, check that T-LDP sessions with PE2 and PE3 are well established:
And check the Label allocation, for example between PE1 and PE2:
Then you can again check that VPLS connections are well UP and also check the Forwarding Database with the 2 following commands:
Case 3 - Mix BGP and LDP protocols
In some scenarios you may want to mix the both solutions explained above. For example because one PE doesn't support one solution. Junos allows to mix the both configuration within the same routing-instance. The LDP related configuration is grouped in what junos called a "mesh-group". The configuration is quite simple and depicted below. Here, the configuration of PE1. PE1 and PE2 use BGP protocol to exchange their Labels and PE1 and PE3 will use a T-LDP session (still via the FEC 128).
The same troubleshooting commands provided for Case 1 and 2 may be used to check that all VPLS connections (BGP and LDP based) are UP.
Case 4 - BGP as auto-discovery protocol and LDP as signalling protocol
The RFC 6074 presents a new way to deal with the 2 protocols. BGP will be used to discover automatically all PEs that want to participate to a specific VPLS and then a full mesh T-LDP sessions will be established between auto-discovered PEs to exchange L2VPN Label (Now via the FEC 129). A new BGP NLRI is defined to do that. So a new BGP family must be configured between our PEs and the RR. The topology is quite similar and depicted below:
First we change the configured BGP family to "auto-discovery-only" on each PE and the RR. Here the config of PE1:
Then we configure the routing-instance. As all is done automatically the routing-instance is very simple. You need to configure a unique route-distinguisher per PE, an import/export RT community and for BGP AD a new L2VPN community. This community must be the same for all PEs that want to participate to the same VPLS.
Note: The prefix l2vpn-id is mandatory, you may choose what you want. Here 1234:1 is used.
Let's check now if PE1 advertised well itself as a PE participating to VPLS ID 1234:1:
Yes, it sends well its NH (lo0) with the right BGP AD community which is l2vpn-id:1234:1. PE1 receives also the 2 lo0 of remote PEs that want to participate to the same VPLS ID.
So now PE1 can establish a T-LDP session with the 2 remote PEs (Auto-discovered). As you can see 2 new LDP neighbors have appeared:
Then we can check the labels exchanged between PE1 and PE2 via the FEC 129:
All is good. To finish the next 2 commands can be used to check if VPLS connections are UP and also to check the Forwarding Database.
Conclusion:
VPLS is quite simple to configure on Junos even if we didn't cover here more complex architectures like VPLS Dual-Homing. But you have now the bases to study the advanced VPLS scenarios in the iNET ZERO JNCIE-SP workbook and study guide materials.
