Browse Prior Art Database

Prevention of Forwarding Loop After Reload

IP.com Disclosure Number: IPCOM000246959D
Publication Date: 2016-Jul-19
Document File: 5 page(s) / 105K

Publishing Venue

The IP.com Prior Art Database

Related People

Anandgouda Jalihal: INVENTOR

Abstract

In protocols – such as STP, RSTP or MSTP – the existing STP Loop-Guard feature does not prevent the forwarding loop that occurs within the network upon the reload of the Network Interface Card (NIC) or the entire switch box itself. This invention provides a solution to this problem.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

Page 01 of 5

Date: June 29, 2016

Prevention of Forwarding Loop After Reload

Author: Anandgouda Jalihal

     In protocols - such as STP, RSTP or MSTP - the existing STP Loop-Guard feature does not prevent the forwarding loop that occurs within the network upon the reload of the Network Interface Card (NIC) or the entire switch box itself. The Loop-Guard feature starts only after there has been at least one BPDU (Bridge Protocol Data Unit) received. However, upon reloading, as there was a unidirectional link failure that existed before the reload and might still exist, the unidirectional failure might be due to: The malfunctioning or faulty network interface cards (NICs) and/or transceivers; a switch's central processing unit (CPU) being too busy with other processes to send BPDU messages for a relatively long time; or any other such reasons.

     As a result of a continuous unidirectional failure, the port does not receive the BPDU at all. The Loop-Guard feature, which is configured on the port, did not have an opportunity to set/start the Receive-Info-While (RIW) timer on the port. The RIW timer helps determine if a BPDU was received. Hence, the port which was said to be in a loop-inconsistent state OR protection mode OR loop guard- error state before reloading, now goes through the normal STP re-computation and faultily transitions to the DESIGNATED role and FORWARDING state.

If the above faulty transition occurs upon reloading, then there is a chance that a forwarding loop will be created in the network, consequently causing an entire network's outage.


Page 02 of 5

STP ports role/status before hitting loop-inconsistent state

     In the case of RSTP (Rapid Spanning Tree Protocol), there are three switches (Switch-A, Switch-B and Switch-C) connected in a ring topology. All network ports are configured under VLAN 100. Now as per the STP protocol, Switch-A is selected as a designated root bridge; Switch-B and Switch-C as non- root bridges.

     After the STP convergence, all the ports on Switch-A (i.e., ports 1/2 and 1/3) have the role as Designated and status as Forwarding (FWD). Similarly the ports directly connected to the designated root bridge (i.e., port 1/2 of Switch-B and port 1/3 of Switch-C) have role set to "Root" and status as "Forwarding" (FWD).

     Which port will be the Alternate/Blocking (BLK) port must be determined. Considering the STP path cost and port priority, the port 1/3 of Switch-B has been selected as the Root/FWD port.

     Lastly, the port 1/3 of Switch-C has been selected as the Alternate/Blocking (BLK) port. The STP Loop-Guard has been configured on port 1/2 of Switch-C, followed by kick-starting loop-guard functionality on port 1/2 of Switch-C immediately after receiving the first BPDU.

Figure 1: STP ports role/status before hitting loop-inconsistent state


Page 03 of 5

STP ports role/status with loop-inconsistent state

     Now assume that there is unidirectional failure from Switch-B to Switch-C, then port 1/2 of Switch-C failed to receive three...