Using Loopback Detection
Loopback Video
Introduction
The goal of this application note is to explain the Loopback Detection features of the Tellabs OLT and how it can be utilized to implement loopback detection.
Document Number
ENG-010684
Applies To:
This application note applies to all Tellabs OLTs (1150/1134/OLT6) and all Tellabs ONTs.
Loopback Detection Description
In a Layer 2 network, if two ports are joined together, this can cause a loop. This will cause problems with learning (MACs being learned on the wrong port) and also looping of broadcast or multicast packets. Looped Multicast or Broadcast packets will often continuously loop and can, if not protected against, consume a majority of the bandwidth on the affected VLAN(s).
Looped Broadcast packets will continue to loop in the system and grow in volume until the loop is broken.
Looped Unicast packets can cause learning issues with traffic sent to the wrong location. This can cause a network segment to lose all contact with the upstream network.
The Tellabs OLT supports loopback detection for ONT UNI ports via multiple loopback detection methods. The detection occurs on the PON card within the system. The methods differ between the OIU8 and QOIU7. It is critical that this loopback detection be deployed as a standard part of network setup.
The QOIU7 card watches learning events on the PON card and will drop alarm packets whose MAC is already learned, but the MAC is coming from a different port within a very short time interval. The packets coming from the wrong direction will be dropped, and the MAC will not be learned. A loopback alarm will be generated and the port, if the auto disable is set will disable the port. On some systems, this same setting is known as err-disable.
The OIU8 card periodically sends loopback messages downstream to the UNI ports. The loopback message is a multicast message and if a port is looped, it will be received back at a PON card. The receiving PON card will alarm and shut down the port.
Due to the two proprietary mechanisms above, RSTP generally does not have to be enabled on any of the UNI ports that are attached to end station devices such as a PC, phone, camera, etc. RSTP only needs to be enabled on ports that will actually participate in RSTP, such as switches or devices with redundant uplinks.
There is a limit of 512 RSTP clients per QOIU7 or OIU8 card that must be adhered to for proper operation.
Tellabs has observed a number of misbehaving devices which will, for some length of time at startup loop traffic back up to the OLT, as a result it is very important that some form of loopback detection be configured on all ports.
For the QOIU7 looped packets are detected and dropped and learning is prevented.
For the OIU8, loopback packets are sent periodically and if detected to be received from an ONT UNI that port is blocked from forwarding until the loop is removed and downstream loopback packets from the OLT are no longer seen coming in from the UNIs. This can be combined with the auto disable to also completely shut the port down, but it is not required as the port is blocked from forwarding.
The system allows both loopback detection and RSTP to be enabled at the same time. For the OIU8, RSTP will take precedence over the loopback checks.
RSTP should only be enabled on ports that have a switch or need to block a redundant link into the network. See the application note on RSTP for configuration guidance on RSTP-enabled ports. Using RSTP and MSTP on OLAN
Loopback Detection Configuration
Loopback detection is configured into two profiles that are assigned to ONT UNI ports.
- Port Profile
- NAC Profile
A standard port profile should always have Loopback Enabled, this will alarm the loopback and allow it to be used to trigger shutdown of the port.
The second profile that contains configuration relevant to the loopback detection is the NAC profile.
Within the NAC profile ensure that auto disable is always selected as this will allow the port to be disabled whenever any of the port alarms are detected. When a loopback is detected, this allows the port to be shut down for the duration of the Auto Re-enable Timeout. The default for the re-enabled timer is 300 seconds or 5 minutes. This allows the port to recover without manual intervention once the loop is removed. As long as the loop is present, it will re-enable the port every 5 minutes, then begin checking for a loop.
If the Auto Re-enable timeout is set to zero, the port is permanently disabled until an Admin disables and re-enables the port from the Panorama EMS or from the OLT CLI.