I’m starting to dive into MPLS based technologies, an area where I have very little experience. I started out with a two “customer site” VPLS network. After getting that working, I added 3rd CE and PE pairing. I made a configuration mistake on PE3 that helped me understand VPLS and MPLS a little better. This article will dive into what happened.
Demo Network
I started out by getting a VPLS link working between CE1 and CE2 and an EIGRP adjacency between them to share their loopbacks. After that worked, I added PE3 and CE3 to the mix and things got interesting.
VPLS
Virtual Private LAN Service or VPLS is a method to transport ethernet frames over an MPLS network. The result is that CE1, CE2, and CE3 all appear to be ethernet adjacent and can form full mesh EIGRP adjacencies using the standard EIGRP multicast process. This VPLS core emulates having all 3 CE routers connected to the same Ethernet switch. The screenshot below shows CE2’s neighborships with CE1 and CE3.
This isn’t a deep dive on VPLS configuration, but I’ll share the relevant configurations from PE2. PE1 and 3 have similar configurations. The VFI member commands build unidirectional point-to-point MPLS tunnels from PE to PE. A full mesh of tunnels is needed for basic VPLS service. The MPLS tunnel destinations are the loopback addresses of the other PE routers. This causes each PE to send LDP targeted hellos to each other and construct label switched paths between each other.
VPLS Forwarding
Before I recreate the configuration error, I’ll walk through the forwarding path from CE2 to CE3. The CE sub-interfaces listed below are configured for 802.1Q encapsulation using VLAN tag 10.
CE2 E0/0.10 address: 192.168.1.2/24
CE3 E0/0.10 address: 192.168.1.3/24
As we can see in the PE2 interface configuration, ethernet service instance 10 is expecting frames tagged with VLAN 10. The bridge domain configuration links the VFI (MPLS tunnels) to the service instance on the interface.
VPLS uses MAC learning like an ethernet switch and split horizon to prevent loops. We can see in the output below that PE2 has learned 3 MAC addresses. Two are learned from remote PEs via MPLS tunnels and 1 is learned locally on Gig1 ethernet service instance 10.
5.5.5.5 is the loopback0 address of PE3. Let’s view the label switched path from PE2 to PE3.
PE2 uses outgoing label 20 on Gi2 toward P2.
Penultimate Hop Popping (PHP) is used, P2 “pops” the top label and sends the packet out of Et0/2 toward P3.
P3 is the tail of the pseudowire, Gi2 is the attachment point for CE3. The ethernet service, VFI, and bridge-domain configuration are comparable with the PE2 configuration.
My Typo
When I initially added PE3 and CE3, I misconfigured the loopback on PE3. This resulted in unidirectional connectivity for CE3. CE3 could reach CE1 and 2 just fine. CE3 was unreachable from the other two CE routers.
I accidentally configured PE3s loopback with 5.5.5.5/24 and I’m running OSPF as the IGP. By default, OSPF advertises loopbacks as /32s regardless of the configured subnet mask. This causes issues because the way LDP allocates lables. PE3 had the /24 in its table so it allocated a label for the /24 route. All other LSRs in the network received the /32 route. I will recreate the issue and demonstrate.
Changing the loopback subnet mask causes all the LDP neighbor adjacencies to reset.
Let’s revisit the LFIB to see the issue. As expected, (because of the aforementioned OSPF behavior) PE2 has prefix 5.5.5.5/32 in its RIB and LFIB and outgoing label 20.
P2 has no outgoing label for 5.5.5.5/32 because PE3 did not allocate a label for 5.5.5.5/32.
We can confirm this by checking the LDB binding table on PE3. The next screenshot displays the relevant LDP bindings (or lack thereof) on PE3.
5.5.5.0/24 is allocated implicit null as expected. This binding is not useful for other LSRs because they did not receive a route for 5.5.5.0/24 as confirmed by the screenshot below. 5.5.5.5/32 has no local binding, so no label advertisement for 5.5.5.5/32 is sent to P2.
The label switched path to PE3 (and CE3 behind it) is broken! This unidirectional forwarding failure causes the EIGRP on CE1 /2 to establish briefly and time out. CE1/2 can send EIGRP hellos and they are both able to receive hellos from CE3. The neighborship comes up until EIGRP’s reliable transport tries to synchronize routing information. CE2, receiving no acknowledgement, retransmits until the retry limit is exceeded and the neighborship is torn down.
Instead of fixing the subnet mask, we have one other option to fix the network. If we change the network type of PE3’s loopback to point-to-point, it will advertise the /24 route to the rest of the network, and everything should work.
Changing the network type resolves the unidirectional connectivity issue. EIGRP between the CEs becomes stable and connectivity is good.
P2 has an outgoing label entry for 5.5.5.0/24 as expected.
Thanks for stopping by and checking out my broken lab!