This post is a continuation of MPLS L2VPNs since it’s describing MPLS VPLS running on the top of the same LDP infrastructure.
Well a disadvantage of MPLS L2VPN is scalability in configurations
where you need to connect more than two sites since L2VPNs is a
point-to-point technology. Creating more and more L2VPNs might be a bit
complicated and time consuming especially in case of troubleshooting
MPLS L2VPN problems.
To solve these problems VPLS was created and yeeeeees (!!) is that it’s a
point-to-multipoint technology.
Imagine that you need to span a VLAN across three Data Centers in
different localizations and you own the core network connecting all
sites. What you need is VPLS that will simply create a “cloud hub”
thanks to MPLS running in your core. Here’s an example topology:
This article describes a simple and effective VPLS configuration running on LDP used for L2VPN in previous article.
On that note, I will mention that there is another way of
implementing VPLS based on MP-BGP. This method is a little bit more
complicated and involves upgrading your iBGP configuration; however,
it’s automated to a point where you don’t have to defines all neighbours
of a VPLS to create a full mesh (as described below) and
requires
defining VPN ID only (it’s using build-in auto-discovery to
automatically create the full mesh).
In my opinion, both MPLS technologies meaning L2VPNs and VPLS based
on LDP are extremely easy to implement and provide really cost effective
way of tunnelling traffic through your network!
Steps 1. Configuring Provider router (P router) configuration - routers building the core
– Enabling LDP protocol which is responsible exchanging label mapping information’s between Label Switch Routers (LSR):
mpls label protocol ldp
– Forcing Router-ID of LSR to loopback:
mpls ldp router-id Loopback0 force
– Enabling MPLS on needed interfaces:
mpls ip
Changing MTU on interfaces running MPLS:
mtu 1564
Double labeling needs to be added to an MPLS frame on PE router. The
first one is used for label switching and the second one carries the
L2VPN label. MTU 1564 allows to q-in-q tunnels to be carried over
L2VPNs.
– Enabling CEF if not on by default.
Step 2. Configuring Provider Edge router (PE router) configuration
– these router/L3 switch are found on a MPLS edges. They are
responsible for adding and removing MPLS tags. Because of it, these
handling these packets will be using more hardware performance and if
not taken care of in hardware this might increase the CPU utilisation
(example C7200s).
As described above enabling LDP on a router:
mpls label protocol ldp
mpls ldp logging neighbor-changes
mpls ldp router-id Loopback0
Under MPLS enabled interfaces:
mpls ip
mtu 1564
To create a VPLS tunnel, PEs are defining “l2 vfi” that include all
the VPLS tunnel configuration. They are attached to VLAN interfaces,
using xconnect command (similarly to L2VPN) and finally as you can
imagine, all is being added to a physical interface as described below.
Defining VPLS VLAN ID and its neighbours:
l2 vfi l2vpn manual
vpn id 1
neighbor 10.0.0.2 encapsulation mpls
neighbor 10.0.0.3 encapsulation mpls
neighbor 10.0.0.4 encapsulation mpls
Attaching l2 vfi to VLAN using xcommand:
interface Vlan2
no ip address
xconnect vfi l2vpn
Attaching VLAN 2 to an interface:
interface FastEthernet4/2
no ip address
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
Step 3. Configuring L2 switches
These switches are used to provide more ports for other potential VPLS VPNs while saving ports on your PEs.
Link connecting PE with a L2 switch is a trunk.
Other L2 switch ports are used to connect customer’s/network devices to VPLSs.
Configuration of this switch is omitted since defining one trunk and a number of access ports shouldn’t be a problem.
Troubleshooting:
– Make sure that the CEF is enabled on all P and PE routers
– Make sure that MPLS and corrct MTU is enabled on all required interfaces
– Make sure that all CE have C configuration plus VFI configuration
– Confirm consistency of th MPLS VPN tag and basic port configuration
– For the status of the VPN per neighbor do:
sh mpls l2 vc
– To check the MPLS table and confirm that the traffic is not being blackholed do:
sh mpls forwarding-table
– To check VFI info’s do:
sh vfi..
– To check next hop details by label do:
sh xconnect all details —- check remote labels of the next hops
sh mpls forwarding-table labels xxx —- confirm next hop neighbor
