In this quick article, I’m going to show you how OAM LFM 1 can be used on MPLS L2VPN ACs to detect point-to-point connectivity faults on Junos. OAM LFM can be extremely helpful to enhance the AC (Layer 2) connectivity troubleshooting when you don’t have back to back physical connectivity on the PE-CE Ethernet link. This lack of back to back Ethernet connectivity, for instance, can arise when you have an underlying transport technology such as DWDM. In order to simulate this environment, I’ll run my entire topology (Figure 1) on virtual Ethernet bridges, which also have this lack of back to back physical connectivity between the two endpoints (i.e., even if you shut down one side of the link, the Ethernet link will still be perceived as up from the other endpoint’s perspective).
In this topology, to illustrate this problem, I’ll set OAM LFM only on the AC of PE1 and I’ll leave the AC of PE2 as it is. We’ll see shortly how this will reflect on the L2VPN Martini VC status between these two PEs.
As you can see, in the configuration bellow between PE1 and CE1, they both have OAM LFM enabled. In particular, I set the
PDU-interval as 1 second (
1000 ms) and the
PDU-threshold is three times this value. As a result, as soon as 3 PDUs are lost the link-adjacency-loss will be triggered and the link will be set to down. In addition, a syslog message will be sent. So, whenever a connectivity fault occurs in this point-to-point link, the status will be correctly reflected on the AC.
First, let’s see from PE1’s perspective and make sure we can ping from CE1 to CE2. The status of the L2VPN Circuit is operational and OAM LFM is also OK, you can tell by the status
Send-Any and the peer MAC address. Plus, we can ping from CE1 to CE2.
Now, from PE2’s point of view the L2VPN circuit is also operational.
So far so good, everything is working as expected. Let’s simulate some network failures to analyze how OAM LFM improves the troubleshooting and the signaling status of the AC.
Remember that we don’t have OAM LFM between PE2-CE2 Ethernet link. Consequently, if I shut down CE2’s interface ge-0/0/2, PE2 won’t notice this event because all of the Ethernet links on this topology are virtual. As a result, the AC will appear as if it is still UP. So, from the control plane point of view, everything seems OK, as we’ll see. However, the data plane won’t work, which makes the troubleshooting process more difficult.
As expected, the ping won’t succeed. Let’s check the control plane status. Both PE1 and PE2 are still signaling the L2 circuit as operational, which they shouldn’t after all the AC between PE2 and CE2 is not operational. However, as pointed out earlier PE2 can’t realize this, which is why OAM LFM help to remedy the troubleshooting.
Before I run the test of shutting down CE1’s interface ge-0/0/1, I’ll rollback the configuration, so we have an operational configuration once again.
Now let’s shut down CE1’s interface and check how both PE1 and PE2 will now perceive the status of the L2 circuit. As you can see, in the snippet bellow, the OAM LFM status now currently reflects the down state of the AC. As a result, PE1 signals the L2 circuit as
LD (local site signaled down). Because of this, PE2 perceives the L2 circuit as
RD (remote site signaled down). Cool! The troubleshooting couldn’t get any easier thanks to OAM LFM in this case.
Troubleshooting can be challenging if you happen to have an underlying transport technology that mask the actual status of the Ethernet link of the AC. Fortunately though, to facilitate this this process you can use OAM LFM to correctly signals the L2 connectivity status for point-to-point Ethernet links.