Concept Guide

A simple ping for an IP address in the subnet will result in a continuous loop without being detected. The reason being we don’t
learn our own MAC address and hence, the MAC station move is never detected. Without station moves, the existing PE Loop
Detection Feature would not kick-in. If there is no data traffic on the LAN to detect the loop, the control PDUs like LACP, LLDP,
ARP, DHCP etc., will be used to detect loops at PE.
● At kernel, the following validations are done:
○ Any control PDU (LACP or LLDP or ARP or DHCP etc) received at CB will be first checked for the source MAC address
against matching any one of its PEX interface address.
○
In this scenario the source MAC could be the system MAC and in this case, the receiving PE interface would be brought
down to cut the loop.
● If there is a match, the kernel notifies L2Mgr about the loop detection and L2Mgr would in turn, bring down the appropriate
PE interface and show an appropriate syslog to the user to correct the loop.
Loop caused due to mis-cabling in an un-managed L2 switch
● An un-managed layer 2 switch is connected to a PE.
● There is some mis-cabling in the L2 switch.
This can result in loops. The current PE loop detection mechanism with data traffic MAC station move, can possibly bring down
the other PE interface which is not connected to the L2 switch, thereby keeping the loop active.
The first recommendation is to enable xSTP on the un-managed switch. The uplink port connected to the PE must be made as
an edge port in the L2 switch. This would ensure the local loop in the L2 switch is cut by itself without having to bring down any
of the PE interfaces. Bringing down the PE interface would still keep the loop active in the switch which affects all the hosts
connected to the L2 switch.
In the event of the L2 switch not supporting xSTP (hub etc), the control PDUs will be used to detect loops at PE to mitigate the
effect of the loop in other parts of the network.
Loop between a LM interface and PE interface
Port Extenders (PEs)
705