Hello my friend,
VPLS is good technology to provide multipoint L2 connectivity between different sites, but it can more. Just as I’ve shown already for VPWS (link), you can bundle together L2 and L3 to terminate clients’ circuits at BNG. VPLS also has possibility to terminate L3 inside it.
One of the widely deployed use cases of coupling VPLS with L3 interface (or routed VPLS) is connectivity of VMs in and between data centers to provide possibility for smooth VM mobility and migration between different locations.
Though EVPN (link) solves this task better, it’s still developing technology and VPLS is here already for decades.
Another widely deployed case is mobile backhaul network in the service providers, where low-end routers, which doesn’t have BGP functionality, establish pseudowires using targeted LDP sessions to PE routers, what terminate these pseudowires into corresponding VRFs/VPRNs.
The following image shows basic idea of the routed VPLS:
What are we going to test?
I’ll configure routed VPLS for the second case (mobile backhaul). So we’ll have two PE routers, what terminates VPLS connectivity in Active/Standby fashion.
The image of the service will be provided later in the configuration section
I use the classical physical topology with two Nokia (Alcatel-Lucent) VSRs and Cisco IOS XRv 9000:
More information on the lab setup could be found in the very first article in this series.
Logical topology for this case will be ring:
Single area OSPF with process-id 1 is used as IGP, and this protocol is used as well to build IP/MPLS transport using Segment Routing (SPRING) extension. There is no BGP configured or used in this topology.
Configuration of the routed VPLS in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR
In our topology SR2 and XR4 play role of PE routers, whereas SR1 and XR3 are used as Access routers (or CSG – cell site gateway):
Here is the routers’ configuration to accomplish this goal:
|Nokia (Alcatel-Lucent) SR OS||Cisco IOS XR|
A:SR1>edit-cfg# candidate view
A:SR2>edit-cfg# candidate view
More information about VPLS configuration and verification you will find in the dedicated article.
What we do here is we configure full mesh of pseudowires between all devices and terminate this pseudowires into VRF/VPRN at PE routers.It’s worth to make some comments about the configured service.
In order to provide resiliency for connection of base stations of mobile network (BTS for 2G, NB for 3G and eNB for 4G) we configure VRRP for this L3 service in VPRN/VRF over VPLS. So if one of the PE routers goes down, another one can take over its function, as VRRP IPv4/IPv6 address is used as default gateway for base stations.
Another key point is the pseudowire between SR1 and XR3. It’s not needed for 2G/3G networks as the connectivity between BTS/NB is necessary only to controller BSC/RNC that usually resides behind PE routers. In case of 4G this link in general is necessary to provide direct eNB to eNB connectivity (X2 interface). I say ”in general”, because there are some caveats caused by encryption stated by LTE standard, but it’s not the focus for the current article. So we say we just need this connectivity. There is no problem if you don’t fully understand described above, as you can understand it truly only if you works with them. There is useful picture (link), what helps to understand interfaces in mobile network.
Cisco IOS XRv 9000 doesn’t support dataplane for L2 MPLS services currently, so not all the outputs will be correct now, as there is no traffic sent/received over VPLS.
Now let’s see some outputs. The first point is to see if VPLS is established correctly at Nokia (Alcatel-Lucent) SR OS side:
A:SR2# show service id 10 base
And at Cisco IOS XR side:
RP/0/0/CPU0:XR4#show l2vpn bridge-domain bd-name R_VPLS
We see that pseudowires are established and works well. From VPLS side it is more or less enough.
More information about configuration and verification of VPLS you can find in of the previous articles.
What we else need to do is to check the routing table at our routers and the status of VRRP. As usually we start with Nokia (Alcatel-Lucent) VSR:
A:SR2# show router 111 route-table ipv4
As I’ve already said Cisco XRv 9000 doesn’t have currently data plane for L2 MPLS data plane, so the output of VRRP will be not correct at XR4, but I will provide it in any case:
RP/0/0/CPU0:XR4#show route vrf R_VPLS ipv4
As Nokia (Alcatel-Lucent) VSR (SR 7750) supports data plane for MPLS L2 VPN services, we can test it’s part. So I create a VRF eNB at XR3 and connect it as client on SAP at SR1 so that it terminates then in corresponding VPRN in SR2. Here is the test topology:
The configuration is pretty easy at XR3:
Here is the test ping for IPv4 address from XR3 to SR2:
RP/0/0/CPU0:XR3# ping vrf eNB 172.16.0.1
Wireshark helps us to see what is going on the wire:
Now we can check als FDB (mac address table for VPLS):
A:SR1# show service fdb-mac
The same exercise for IPv6 just to show that it works as well:
ping vrf eNB fc00:172:16::1
And Wireshark output:
Seems strange? We have dicussed once that Wireshark doesn’t always understand MPLS L2 VPN packets correctly. Look, it says that we have control word field, though we don’t have it:
If we take a look on control-world bits and also on the next couple, we see that it’s just MAC address of eNB:
A:SR2# show router 111 neighbor
More info on that topic you can find in the lessons learned in the following article.
You see that the labels are the same both for IPv4 and IPv6 ping results as labels are associated with pseudowires, not with IP addresses.
There is one more possibility, how you can build VPLS in Nokia (Alcatel-Lucent) SR OS and in Cisco IOS XR. In Nokia you can used spoke-sdp instead as well as in Cisco your put neighbours outside of VFI context. By default, such configuration will bring down your network, because in both cases traffic coming from pseudowire will be replicated to other, meaning that single packet will cause broadcast storm and continuous loop. Such problem doesn’t exist in VFI/mesh-sdp configuration, because you have split-horizon activated by default activated there and VFI or all mesh-sdps are treated as single interface. If you implement (what is highly not recommended from me) or operate the network with such installation, you need to take care of manual split-horizon-groups (SHG) configuration across spoke-sdps/neighbours so that no loops occur.
Routed VPLS is quite useful and widely used technology in service provider networks as well as in data centre. Though EVPN tends to overtake leadership here due to better design and functionality, VPLS will still be in place for a long time. And it’s OK, because with the proper planning and implementation it makes good job. Take care and good bye!