WO2018118062A1

WO2018118062A1 - Method and system for preventing propagation of stale topological information

Info

Publication number: WO2018118062A1
Application number: PCT/US2016/068208
Authority: WO
Inventors: Sai Ram BANDARUPALLI; Nalinakshan Kunnath
Original assignee: Ale Usa Inc.
Priority date: 2016-12-22
Filing date: 2016-12-22
Publication date: 2018-06-28

Abstract

A method and a system for preventing propagation of stale topological information are disclosed. An identity of a current root bridge is stored at a bridge. The bridge receives first modified root bridge information. In response to receiving the first modified root bridge information, the bridge records the identity of the current root bridge as stale information before using the first modified root bridge information to update the identity of the current root bridge and before sending a first update message carrying the identity of the current root bridge. The bridge receives a second update message carrying second modified root bridge information. Using the second modified root bridge information, the bridge updates the identity of the current root bridge if the second modified root bridge information does not match the stale information.

Description

METHOD AND SYSTEM FOR PREVENTING PROPAGATION OF STALE

TOPOLOGICAL INFORMATION

FIELD

[01] The present technology relates to interconnected bridges used in support of local area networks. In particular, a method and a system aim at preventing the propagation of stale topological information

BACKGROUND

[02] Spanning Tree Protocol (STP) was developed to overcome the possibility of bridging loops in bridging networks having redundant switches and switch paths. Basically, the protocol enables switches to become aware of each other so they can negotiate a loop-free path through the network. A spanning tree builds a logical loop-free topology for an Ethernet layer-2 bridging network. The basic functionality of STP is to prevent Ethernet bridge loops and the broadcast radiation that might result from the presence of bridging loops in a network. STP creates a loop-free active topology within an Ethernet layer-2 bridges network by enabling active ports in the spanning tree and by disabling ports that are not part of the spanning tree. STP also allows including redundant links in the design of a network so to provide automatic backup paths in case of active link fails dynamically.

[03] Rapid spanning tree protocol (RSTP) was introduced in the IEEE 802. lw standard and later revised in IEEE 802. ID 2004 standard. RSTP supersedes the Spanning Tree Protocol (STP) that was specified in previous revision of the IEEE 802. ID standard. RSTP is designed to overcome a long convergence time of networks using STP.

[04] The IEEE 802. ID 2004 standard specifies a single instance of STP that encompasses all virtual local area networks (VLAN) instances of a given Ethernet layer-2 bridging network. This instance is referred to as a common spanning tree (CST). The CST builds a single logical loop-free active topology among the bridges of the network. Within the network, each bridge exchanges configuration information by sending bridge protocol data units (BPDU) to its neighboring bridges. All the VLAN instances in the network share a single loop-free active topology created by the CST to forward traffic in the network topology. BPDUs are transmitted between bridges over links to propagate information the CST. These BPDUs carry untagged Ethernet frames, meaning that they are sent without a VLAN instance identity. Use of a single spanning tree for all VLAN instances simplifies switch configuration and reduces processing load in the bridges during STP calculations. However, having only one STP instance may limit the capabilities of the network. Redundant links between bridges and switches may become blocked, with no capability for load balancing. Conditions also may occur that could cause the CST to mistakenly enable forwarding on a link that does not carry a specific VLAN instance, whereas other links could be blocked.

[05] A particular implementation of STP offers more flexibility than the basic IEEE 802. ID 2004 implementation of the CST. In this particular implementation, a per- VLAN spanning tree mode operates a separate instance of STP for each individual VLAN instance. Accordingly, each spanning tree instance is mapped to VLAN instance in a one-to-one mapping; for instance 'VLAN Γ is mapped to 'STP instance Γ. This STP instance builds an independent logical loop-free active topology for the specific VLAN instance. Consequently, all traffic for that specific VLAN instance follows the corresponding loop-free active topology STP instance. This allows the STP instance corresponding to each VLAN instance to be configured independently, offering better performance and tuning for specific conditions. Multiple spanning trees also make load balancing possible over redundant links when the links are assigned to different VLAN instances. One link might forward traffic for one set of VLAN instances, while another redundant link might forward a different set.

[06] In STP, each bridge maintains a single spanning tree path. There are no backup paths, which mean there is no alternative path to a root bridge. In contrast, in RSTP, each bridge may compute alternate spanning tree paths using redundant links that are not included in the active forwarding topology. These alternate paths are used for fast failover when a primary spanning tree path fails to achieve Rapid convergence. RSTP bridges use a hop-by-hop handshake mechanism called 'sync' to explicitly synchronize states among bridges in order to ensure that no temporary loops in the active topology and converge the topology rapidly.

[07] RSTP implements an active topology computation by employing a distributed spanning tree algorithm (STA) that computes a unique spanning tree over a network that includes bridges and connecting links, and generates a loop free topology. Fig. 1 illustrates a simplified example of a network of bridges. An example network 10 includes bridges distributed over a core layer 12, a distribution layer 22 and an access layer 32. The core layer 12 includes a pair of bridges 14 and 16 that are interconnected to each other, one of which being designated by configuration as a core bridge, the other being a backup core bridge and ready to be designated as a core bridge by configuration change. The distribution layer includes a pair of bridges 24 and 26 that are interconnected to each other and that each have connections to both bridges 14 and 16 of the core layer 12. The access layer 32 includes a pair of bridges 34 and 36 that each have a connection to both bridges 24 and 26 of the distribution layer 22. Each bridge 14, 16, 24, 26, 34 and 36 has two or more ports (shown on later Figures) providing connections to at least two neighboring bridges via links 40. A practical example may comprise a larger number of bridges in each layer 12, 22 and 32.

[08] Under the IEEE 802. ID 2004 standard, each bridge has a unique bridge identity (ID) in the topology. Fig. 2 represents a format of a bridge ID defined according to the standard. Each of the bridges 14, 16, 24, 26, 34 and 36, as any further bridge of the network 10, has a bridge ID defined according to this format. The bridge ID 50 is an 8-byte value consisting of 2-byte priority field 52 containing a bridge priority and a 6-byte MAC address field 54 containing a media access control (MAC) address of a bridge. The bridge priority field 52 is in a most significant portion of the bridge ID 50 and is configurable by an operator of the network 10, in a range of 0 to 65,535 (unsigned). The IEEE 802. ID 2004 standard defines a default bridge priority value of 32768. The MAC address field 54 of the bridge is in a least significant portion of the bridge ID 50 and is a unique, hard-coded value assigned to a given bridge by its manufacturer

[09] Within the network 10, the bridge having the lowest bridge ID 50 is designated as the root bridge by the spanning tree algorithm. Otherwise stated, the lowest bridge ID 50 represents the highest priority, or best priority. The bridge having the second best priority is the backup root bridge. Generally, the bridges of the core layer 12 will be elected as the root bridge and as the backup root bridge. In the present disclosure, the expression 'best priority' is used to avoid any possible confusion between expressions such as 'highest priority' and 'lowest bridge ID'. The MAC address being fixed, it is primarily the priority field 52, which is placed in the most significant bytes of the bridge ID 50, that determines which of the bridges is elected as the root bridge. When two (2) or more of bridges in the network 10 have the same value in their priority fields 52, the bridge having the lowest value in its MAC address field 54 is designated as the root bridge. [10] Once a root bridge is elected, each bridge computes a root path cost (RPC), which is a path cost from itself to that root bridge. To this end, the bridge sums path costs of each link 40 between itself and the root bridge. If there are plural possible paths because the bridge has multiple ports that can reach the root bridge, the lowest path cost is selected as the RPC. Each of the bridges in the network 10 exchange configuration information by sending bridge protocol data units (BPDU) to their neighboring bridges. Fig. 3 is a simplified illustration of a BPDU format. A BPDU 60 includes a bridge ID field 62 comprising the bridge ID 50 of the bridge that has been elected as the root bridge for the network 10, a RPC field 64, a MessageAge field 66 that is first set to zero (0) by a bridge that first sends the BPDU 60 and that is incremented by one (1) by each bridge that receives and forwards the same BPDU 60, and a MaxAge field 68. A bridge that receives the BPDU 60 recalculates the RPC field 64 by added thereto a cost of the link 40 between itself and a previous bridge having sent the BPDU 60 before forwarding the BPDU 60 to a next bridge. Otherwise stated, when a bridge forwards the BPDU 60, it includes the value of the RPC between itself and the root bridge. Other fields (not shown) of the BPDU 60 include a designated bridge ID and a Hello timer. A Hello function is described hereinbelow.

[11] In a given bridge, once the root bridge is identified, the spanning tree algorithm elects one of the ports of the given bridge as a root port (RP). The RP of a bridge is the port that provides the lowest path cost toward the root bridge. Then, the spanning tree algorithm elects one or more designated ports (DP), which are ports toward the one port each further bridge attached to each local area network (LAN) that provides the lowest cost path from that LAN to the root bridge. Finally, when other ports are available on the bridge, the spanning tree algorithm selects an alternate port and a backup port that are assigned to bridge ports that can provide connectivity if other network components fail. The alternate port and the backup port are not part of the active spanning tree topology. The alternate port connects a bridge to a redundant link that provides a backup path to the root bridge. A port's state is either forwarding or blocking, depending on whether the port forwards data packets or blocks their flow. An alternate port is always blocking. Generally, ports that are a part of active topology of the spanning tree are forwarding. However, during changes to the spanning tree, such ports may become blocking.

[12] Each bridge constructs BPDUs 60 based on the latest topology information that it has received from one or more other bridges. Bridges send BPDUs 60 to announce new information. In the absence of any new information, bridges still send a BPDU 60 as 'heartbeat messages', once every 'Hello time', wherein for example the IEEE 802. ID 2004 standard recommends setting this Hello time to once every two (2) seconds.

[13] The BPDU is initiated by the root bridge, which initializes the MessageAge field 66 to zero (0). When a bridge other than the root bridge sends a BPDU 60, it sets the MessageAge field 66 to one more than the MessageAge field 66 of the BPDU 60 that it last received from another bridge. When the MessageAge field 66 exceeds the MaxAge field 68, the BPDU 60 is dropped. By comparison, the MessageAge field 66 operates in a large extent as the opposite of the time to live (TTL) field in an Internet protocol version 4 (IPV4) header. In the IEEE 802. ID 2004 standard, the value of the MaxAge field 68 is configurable in a range of 6 to 40, with a recommended or default value of 20.

[14] Each bridge uses a token-bucket algorithm to limit the rate of BPDU 60 transmission per port per second. Generally, a bucket size is given by a bridge's transmit hold count (TxHoldCount) parameter. Specifically, each port has a counter TxCount that keeps track of the number of transmitted BPDUs 60 within a second. If TxCount reaches TxHoldCount, no more BPDUs 60 are transmitted by the port during the current second. Situations where transmission of BPDUs 60 is prevented may lead to transmissions delays. The token-bucket algorithm uses a token rate of one. In other words, the TxCount is decremented by one every second, unless its value is already zero. [15] As mentioned hereinabove, RSTP relies on a simple handshake operation, called sync mechanism, in order to avoid creating temporary forwarding loops in the topology during the topology convergence over point-to-point links. A root port can transition to forwarding without transmitting or receiving messages from other bridges, while a designated port attached to a point-to-point LAN can transition to forwarding on the condition that it receives an explicit role agreement transmitted by the other bridge attached to that LAN through a handshake process is made with the nearest neighbor bridge. When a blocked designated port connected to a given link 40 intends to become forwarding, it first requests permission from the bridge located at the end of the given link 40. This is done by sending on this given link 40 a BPDU 60 carrying a set proposal flag. In response, the bridge that receives this BPDU 60 typically blocks all its designated ports and then responds with a BPDU 60 carrying a set agreement flag. This operation cascades down through various bridges in the spanning tree because the blocked designated ports intend to become forwarding again. Operation of the sync mechanism allows one port to become forwarding at a time. This operation cascades downwards until it reaches a port that should be permanently blocked.

[16] In an RSTP active topology, dynamic learned end station MAC address location information is stored in a forwarding database of each bridge. In normal and stable operation, this information in the forwarding databases may change as a consequence of the physical relocation of end stations. However, when the active topology is reconfigured, a topology change (TC) event arises, for example when a blocked port becomes a forwarding port in the topology. As a result, end stations may appear to move from the point of view of a bridge, even if that bridge's port states have not changed. Information needs to be relearned when ports become part of the active topology, even though only part of the network may have reconfigured. If a port is no longer part of the active topology, end stations are no longer reachable through that port and its dynamic learned MAC address is removed from the forwarding databases. Conversely, stations formerly reachable through other ports might be reachable through newly active ports by a flooding mechanism. The dynamic learned end stations MAC address entries for the other ports are removed and TC BPDUs are transmitted both through the newly active port and through the other active ports on that bridge. A bridge that receives a TC BPDU message on an active port removes dynamic learned MAC address entries for their other active ports and propagates the TC BPDU through those ports. [17] The TC message consumes a TxCount. If the TxCount reaches the TxHoldCount, BPDUs 60 are no longer transmitted by the port during the current second. This situation leads to transmissions delays. A bridge receiving a TC message forwards this message on all of its ports participating in the active topology, except for the one that it received the TC message on. Whenever a bridge receives a TC message on one of its ports, it clears forwarding table entries at all of its other ports. Such clearing operation on a single port may consume several milliseconds in the bridge.

[18] In an RSTP topology, each bridge computes alternate paths to the root bridge using redundant links that are not part of a current active forwarding topology. RSTP alternate paths are used for fast failover when the primary path to root bridge fails. This is one of the key features allowing RSTP to converge rapidly. However, RSTP Alternate Root port information is not always valid in few specific scenarios. Alternate root port information that is no longer valid, called 'stale information', may be used by bridges that may spread this stale information to other bridges through sending incorrect BPDUs 60, which potentially leads to a so called 'count-to-infinity' (CTI) problem.

[19] In a CTI scenario, stale information may propagate via BPDUs 60 sent through the network 10 until the MessageAge field 66 reaches the value of the MaxAge field 68. At the same time, correct topology information may stall at a bridge when its port has reached its TxHoldCount. The stale information may subsequently be received at the bridge. As a result, the correct information may be eliminated from the network 10. BPDUs 60 carrying stale information continue to propagate around the network 10. [20] The CTI scenario may occur when an operator exchanges the role of the root bridge and of the backup root bridge by changing the priority of the bridges 14 and/or 16 of the core layer 12 through configuration. In this scenario, an RSTP three (3) layer hierarchy topology with 128 spanning tree VLAN instances may take as long as 30 minutes before reaching traffic convergence. [21] When the roles of the root bridge and of the backup root bridge are exchanged, RSTP may exhibit the CTI problem. During this, the RSTP topology is continuously reconfigured as stale information cycles in the network 10. This phenomenon temporarily generates many topology changes and causes the formation of temporary forwarding loops in the network 10. As result traffic, convergence is temporarily impacted. While CTI is ongoing, the spanning tree topology of the network 10 is continuously being reconfigured and ports of the bridges tend to oscillate between forwarding and blocking data packets. Many data packets may be dropped. Even after the end of the CTI, some delay may still occur before the network 10 stabilizes and allows the traffic to converge.

[22] The IEEE 802. ID 2004 standard defines the following four (4) rules that are relevant to the count-to-infinity scenarios.

Rule 1: A bridge sends out a BPDU immediately to all neighbor bridges when the operator changes the priority of the root bridge.

Rule 2: When a designated bridge receives, via its root port, a BPDU carrying a bridge ID field 62 having a numerical value greater than the root bridge ID (the received bridge ID indicates a 'best priority'), if the designated bridge does not have an alternate port, it declares the bridge ID as a new root bridge ID.

Rule 3: When a designated bridge receives, via its root port, a BPDU carrying a bridge ID field 62 having a numerical value greater than the root bridge ID (the received bridge ID indicates a 'best priority'), if the backup root bridge has one or more alternate ports, it adopts the alternate port with the lowest cost path to the root bridge as its new root port.

Rule 4: A designated port becomes the root port if it receives a BPDU having a best priority than what the bridge has received before; this is the case when this BPDU announces a best path to the root than via the current root port.

[23] Considering these four (4) rules, Figs. 4 to 10 provide an illustration of a count-to- infinity scenario in an RSTP fully redundant, two-level hierarchical network topology. Figs. 4 to 10 respectively represent the same network topology at a first time TO, when a CORE 1 bridge is the root bridge and a CORE 2 bridge is the backup root bridge, until a time T6, when the CTI scenario is ongoing. In Figs. 4 to 10, bridge IDs (BID) are represented in a simplified format: for example, the bridge ID of the CORE 1 bridge is ΊΟΟ+Α', which is a concatenation of the value ΊΟΟ', which is a priority of the CORE 1 bridge, and 'Α', which is a MAC address of the bridge. In order to simplify the illustration, all link between the bridges shown on Figs. 4-10 have a same cost of 10, this cost being an un-dimensioned value indicative of an available bandwidth on these links.

[24] At an initial time TO (Fig. 4), because the bridge ID of the CORE 1 bridge is the lowest (best priority) of all bridges, it is designated as the root bridge. The RPC value for the CORE 1 bridge is zero (0) since there is no path cost from the CORE 1 bridge to itself. The CORE 1 bridge has two (2) ports, called PI and P2. Both ports PI and P2 of the CORE 1 bridge are designated ports (DP) because they both lead away from the root bridge toward designated bridges. The CORE 2 bridge stores a root bridge ID (RBID) that designates the CORE 1 bridge. A RPC to the CORE 1 bridge is 10, as there is one (1) link between these bridges. As such, the RBID value stored in the CORE 2 bridge is ΊΟΟ+Α' with a RPC of 10. The CORE 2 bridge also has two (2) ports PI and P2. P2 is a DP because it leads away from the root bridge. PI is a root port (RP) because it leads toward the root bridge; PI has a value of '100+A,RPC=10'. [25] An ACCESS-SW-1 bridge has a bridge ID of '300+C. It stores a RBID of ΊΟΟ+Α' with a RPC of 10, because it is aware that CORE 1, which has the bridge ID ΊΟΟ+Α', is the root bridge, and because it has a single link with a cost of 10 toward the root bridge. The ACCESS-SW-1 bridge has a port PI that is a root port because it has a lowest path cost toward the root bridge. PI has a value ' 100+A,RPC=10' . A port P2 of the ACCESS-SW- 1 has a RPC of 20 toward the root bridge, given that it is connected toward the root bridge via two (2) links, i.e. a link from the ACCESS-SW-1 bridge to the CORE 2 bridge and another link from the CORE 2 bridge to the CORE 1 bridge. Because the RPC on P2 is higher than the RPC on PI, P2 is designated as an alternate port (ALT), with a value of '100+A,RPC=20'. [26] At time Tl (Fig. 5), the operator changes the priority field 52 for the CORE 1 bridge from 100 to 250, for all VLAN instances supported by the CORE 1 bridge. The priority value of the CORE 2 bridge, which remains unchanged and equal to 200. As a result, the bridge ID of the CORE 2 bridge is now the lowest of all bridges on Fig. 5 and, otherwise stated, the CORE 2 bridge now has the best priority. According to Rule 1, RSTP causes the CORE 1 bridge to send BPDUs on its directly connected bridges CORE 2 and ACCESS-SW-1. In theses BPDUs the bridge ID field 62 is set to '250+A', which is the bridge ID of the CORE 1 bridge, the RPC is zero (0) since this is the cost from the CORE 1 bridge to itself (no other bridge has been declared as the root bridge at this time). The MessageAge filed 66 is set to zero (0). [27] At time T2 (Fig. 6), according to Rule 2, the CORE 2 bridge having received the BPDU sent by the CORE 1 bridge at time Tl determines that its own bridge ID '200+B', has a best priority when compared to the bridge ID field 62, '250+A', of the received BPDU. The CORE 2 bridge declares itself as the root bridge with a RBID '200+B' and send BPDUs carrying its bridge ID '200+B' as the bridge ID field 62, with a RPC of zero (0) to its connected bridges. The BPDUs are sent by the CORE 2 bridge to the CORE 1 bridge at time T2.1 and to the ACCESS-SW-1 bridge at time T2.2.

[28] Also at time T2, the ACCESS-SW-1 bridge having received the BPDU sent by the CORE 1 bridge at time Tl updates its root port PI to '250+A,RPC=10'. However, the P2 alternate port of the ACCESS-SW-1 bridge still has the value of 'ALT-100+A,RPC=20'. According to Rule 3, RSTP elects P2 as the best port to reach what still appears to be the root bridge with a bridge ID of ΊΟΟ+Α'. P2 changes its state to forwarding and changes its function from alternate port to root port to root bridge with a value '100+A,RPC=20'. This is evidently an incorrect value, given that no bridge currently has a bridge ID of ΊΟΟ+Α'. However, RSTP cannot determine that this information is stale. The next events will trigger a CTI scenario when the stale information designating ΊΟΟ+Α' as the root bridge will cycle among the various bridges.

[29] At time T2.1, the ACCESS-SW-1 bridge sends a BPDU through its proposed designated port PI to the CORE 1 bridge, carrying the stale information, on the belief that the ACCESS-SW-1 bridge is has a best path to a root bridge ΊΟΟ+Α', which no longer exists. The BPDU fields are '100+A,RPC=20,MA=2', the MessageAge (MA) being set to two (2). Concurrently, at time T2.2, the ACCESS-SW-1 bridge sends a BPDU through its proposed root port P2 to the CORE 2 bridge, carrying the same stale information. The BPDU fields are the same as those sent to the CORE 1 bridge.

[30] At time T3 (Fig. 7), a race condition takes place as the CORE 1 bridge receives BPDUs send by the CORE 2 bridge and by the ACCESS-SW-1 bridge at time T2.1. Though other situations may occur, in one particular sequence, the CORE 1 bridge first receives the BPDU sent at time T2.1 by the CORE 2 bridge. Because the bridge ID field 62 of that BPDU '200+B' has a best priority than the own bridge ID of the CORE 1 bridge '250+A', the CORE 1 bridge accepts the CORE 2 bridge as the root bridge, the CORE 1 bridge changing its role from root bridge to backup root bridge, which is a correct decision. The CORE 1 bridge stores a RBID of '200+B' and it assigns PI as its RP with 200+B,RPC=10'. This is valid topology information received from the CORE 2 bridge. The CORE 1 root bridge then receives the BPDU sent at time T2.1 by ACCESS-SW-1 bridge. The bridge ID field 62 of this last BPDU is ΊΟΟ+Α', which is a best priority than the priority '200+B' of the RBID that has been just stored. Unaware that this is stale information, the CORE 1 bridge changes the RBID to ΊΟΟ+Α'. The port P2 of the CORE 1 bridge becomes a RP with given a value of '100+A,RPC=30'. The port PI of the CORE 1 bridge becomes a DP and sends a BPDU to the CORE 2 bridge with the fields '100+A,RPC=30,MA=3'. At this time, the stale information that erroneously indicates a root bridge ID of '100+A' has superseded the valid bridge ID '200+B' in the CORE 1 bridge. The stale information now circulates between the various bridges. [31] Also at time T3, the ACCESS-SW-1 bridge receives on its root port P2 the BPDU having been sent at time T2.2 by the CORE 2 bridge. Fields of this BPDU are '200+B, RPC=0,MA=0'. This correct information overwrites the previous stale information of the port P2, which was '100+A,RPC=20'. With this correct information, the bridge ID at the port P2 has a best priority value than the bridge ID at the port PI, which is '250+A'. The ACCESS-SW-1 bridge stores the RBID as '200+B, RPC=10', which correctly designates CORE 2 as root bridge with path cost 10 through port P2, which is now the root port. The ACCESS-SW-1 bridge can now reach the correct root bridge 'RBID-200' with a path cost of 10. This is valid topology information propagating from the CORE 2 bridge to the ACCESS- SW-1 bridge. Because the ACCESS-SW-1 bridge now has a new root bridge designation, it sends a BPDU to the CORE 1 bridge with fields set to '200+B, RPC-10, MA=1'. As a part of the RSTP sync mechanism, the ACCESS-SW-1 bridge also sends via its root port P2 a BPDU to the CORE 2 bridge with fields set to '200+B, RPC-10,MA=1'.

[32] At time T4 (Fig. 8), the CORE 2 bridge having received on its port PI the BPDU sent by the CORE 1 bridge at time T3 with the fields '100+A,RPC=30,MA=3' accepts this information, without knowing that the RBID '100+A' is stale information. The CORE 2 bridge selects this RBID as a root bridge designation with a RPC equal to 40, selects PI as its root port, and forwards this stale information on its port P2 in a BPDU sent to the ACCESS - SW-1 bridge, with a MessageAge equal to 4. [33] This BPDU is received at time T5 (Fig. 9) at the port P2 of the ACCESS-SW- 1 bridge, which accepts the best priority of the RBID '100+A' as a new root bridge designation, with a RPC equal to 50, and select P2 as its root port. The ACCESS-SW-1 bridge propagates again this stale root bridge information by sending from its port PI to the CORE 1 bridge a BPDU with the fields set to '100+A,RPC=50,MA=5'. [34] Then at time T6 (Fig. 10), the CORE 1 bridge receives on its port P2 the BPDU sent by the ACCESS-SW-1 bridge at time T5, the fields of the BPDU being '100+A,RPC=50,MA=5'. Once again, the CORE 1 bridge updates its designation of the root bridge with RBID of '100+A' and a RPC equal to 60 through its root port P2. The CORE 1 bridge propagates again the stale root bridge information to CORE 2 bridge by sending a BPDU with the fields '100+A,RPC=60,MA=6' . [35] The stale topology information about a non existing root bridge with RBID of ΊΟΟ+Α' will continue to propagate among the bridges during the CTI scenario until the MessageAge field in the BPDUs reaches the MaxAge. The stale topology information may for example propagate for 20 hops in the topology of Figs. 4 to 10 if the MaxAge field 68 is set to 20, as recommended by the IEEE 802. ID 2004 standard.

[36] For instance, the CORE 1 bridge will process the stale topology information at least seven (7) times in the topology given that the MessageAge field reaches the MaxAge value of 20 at a 7^th iteration, the CORE 1 bridge dropping the BPDU carrying the stale RBID of ΊΟΟ+Α'. This terminates the CTI scenario. [37] There are three (3) key factors that allow the formation of a CTI induced forwarding loop. Firstly, CTI occurs around a physical network cycle. Secondly, during CTI, the fresh topology information stalls at a bridge because the bridge port has reached its TxHoldCount and subsequently the stale information is received at the bridge. As a result, the fresh information is eliminated from the network. BPDUs carrying stale information continue to propagate around the network and the CTI scenario continues until the stale information is aged out. Third, the operation of the sync mechanism that would have prevented a forwarding loop is not performed by a bridge because of a race condition and nondeterministic behavior in RSTP, allowing the forwarding loop to be formed.

[38] The impact of the CTI problem on RSTP traffic convergence during, and even after CTI, is difficult to predict because several factors are involved. One factor comprises a size of the RSTP topology. Another factor comprises a total number of active ports involved in each spanning tree protocol VLAN instance. Yet another factor comprises a total number of redundant ports in the RSTP topology. Adding redundant links in the RSTP topology results in more alternate ports per bridge. These alternate ports may initiate CTI stale information loops and extend the duration of the CTI scenario, delaying traffic convergence because of the generation of numerous topology changes. Whenever a bridge receives on one of its ports a BPDU requesting a topology change, the bridge flushes forwarding table entries at all of its other ports. For a given TC BPDU, a total number of flushes is equal to a total number of active ports in one spanning VLAN instance minus one (1). Otherwise stated, if the bridge has 'n' active ports and the total number flushes is 'η-Γ flushes. The time required by the bridge's hardware for perform a single flush may for example be from 8 to 10 milliseconds (ms) in a typical bridge.

[39] Table I shows results of a laboratory test. In this test, a RSTP topology had two (2) layers with 128 spanning tree VLAN instances. There was 16 access switches connected to aggregation switches Aggregation SW-1 and Aggregation SW-2 for high redundancy purposes. Each VLAN was configured with a total 19 ports in Aggregation SW-1 and in Aggregation SW-2. There were 16 alternate ports in each and every VLAN in Aggregation SW-2.

Total number of ports configured in one 19 ports (16 ports are connected to 16 access VLAN in Aggregation SW-1 switches) and 3 ports are connected to the

Core Network

Total number of ports configured in one 19 ports (16 Alternate ports are connected to VLAN in Aggregation SW-2 16 access switches) and 3 ports are

connected to the Core Network.

CTI stale BPDU processed by each- 6 times

aggregation switch

Total number of flushes generated by one 6 X 18 = 108 flushes

CTI loop for one VLAN

Total number of alternate ports in one VLAN 19

Each alternate port may initiate one CTI loop So there are 19 CTI loop's in the topology

Total number of lushes for one spanning tree 108 X 19 (CTI loops) = 2052 flushes

VLAN Instance

Total number of configured spanning tree 128 spanning VLAN instances

VLAN instances

Grand total number of flushes generated for 128 X 2052 = 262,656 flushes.

128 spanning tree instances

Typical number of flushes handled by per 125 flushes (a flush takes around 8 ms) switch per one second

Amount time to handle 262,656 flushes 262.656 X 125 = 2,101 seconds, or 35

minutes

TABLE I

[40] In the example of Table I, the CTI problem caused a 35-minute delay before reaching proper traffic convergence. [41] Improvements may therefore be desirable, in particular, improvements aiming at preventing the CTI problem caused by the presence of stale information in the RSTP topology. SUMMARY

[42] It is an object of present technology to provide improvements, in particular improvements aiming at preventing the count-to-infinity (CTI) problem caused by the presence of stale information in the RSTP topology. [43] The present technology arises, in one aspect, from an observation made by the inventor that stale topology information may be recorded in just a few bridges of a network and that topology update messages carrying the stale information may be discarded to those bridges to prevent the CTI problem throughout the network. The present technology also arises, in another aspect, from another observation made by the inventor that changes to the topology information may be initiated at a bridge other than a root bridge to avoid the CTI problem.

[44] Thus, in one aspect, various implementations of the present technology provide a method for preventing propagation of stale topological information, comprising: storing, at a bridge, an identity of a current root bridge; receiving, at the bridge, first modified root bridge information; in response to receiving, at the bridge, the first modified root bridge information, recording, at the bridge, the identity of the current root bridge as stale information before using the first modified root bridge information to update the identity of the current root bridge and sending, from the bridge, a first update message carrying the identity of the current root bridge; receiving, at the bridge, a second update message carrying second modified root bridge information; and using, at the bridge, the second modified root bridge information to update the identity of the current root bridge if the second modified root bridge information does not match the stale information.

[45] In some implementations, recording, at the bridge, the identity of the current root bridge as stale information further comprises starting a timer and deleting the stale information when the timer expires. [46] In some further implementations, the identity of the current root bridge, the first modified root bridge information and the second modified root bridge information each defines a bridge priority.

[47] In some implementations, an identity of a given bridge is formed of a combination of a priority value assigned to the given bridge and of a media access control (MAC) address of the given bridge.

[48] In some further implementations, the priority value is in a most significant portion of the identity of the given bridge and the MAC address of the given bridge is in a least significant portion of the identity of the given bridge.

[49] In some implementations, the given bridge is elected as the current root bridge if is has a best priority among a plurality of interconnected bridges.

[50] In some further implementations, the best priority is conferred by a numerically lower value among identities of the plurality of interconnected bridges.

[51] In some implementations, the bridge is the current root bridge and wherein receiving, at the bridge, first modified root bridge information comprises receiving operator configuration information to modify a priority of the bridge.

[52] In some further implementations, a root path cost to the root bridge is zero and wherein the first update message sent by the bridge further carries the root path cost.

[53] In some implementations, the first update message sent by the bridge further carries a message age set to zero.

[54] In some further implementations, receiving, at the bridge, first modified root bridge information comprises receiving a third update message carrying the first modified root bridge information.

[55] In some implementations, the third update message received by the bridge further carries a root path cost and wherein the first update message sent by the bridge further carries a sum of the root path cost and of a cost of link established between the bridge and a bridge having sent the third update message. [56] In some further implementations, wherein the third update message received by the bridge further carries a message age and wherein the first update message sent by the bridge further carries the message age having been incremented by one.

[57] In some implementations, the bridge is part of a rapid spanning tree protocol (RSTP) network.

[58] In some further implementations, the first update message is sent on one or more destination ports of the bridge.

[59] In another aspect, various implementations of the present technology provide a bridge, comprising: a first port adapted for communicating with a first peer bridge; a second port adapted for communicating with a second peer bridge; a memory device; and a processor operatively connected to the first and second ports and operative to read and write in the memory device, the processor being configured to: store, in the memory device, an identity of a current root bridge; receive first modified root bridge information; in response to receiving the first modified root bridge information, record, in the memory device, the identity of the current root bridge as stale information before using the first modified root bridge information to update, in the memory device, the identity of the current root bridge and sending, via one of the first and second ports, a first update message carrying the identity of the current root bridge; receive, via one of the first and second ports, a second update message carrying second modified root bridge information; and use the second modified root bridge information to update, in the memory device, the identity of the current root bridge if the second modified root bridge information does not match the stale information stored in the memory device. [60] In some implementations, the processor is further configured to start a timer when recording the stale information in the memory device and to delete the stale information in the memory device when the timer expires.

[61] In some further implementations, the first port is adapted to receive the first modified root bridge information.

[62] In some implementations, the bridge further comprises an interface allowing an operator to provide the first modified root bridge information.

[63] In some further implementations, the processor is further configured to send an instance of the first update message carrying the identity of the current root bridge via each of the first and second ports.

[64] In some implementations, one of the first and second ports is a root port and an other of the first and second ports is a designated port or an alternate port.

[65] In some further implementations, the first and second ports are both designated ports. [66] In some implementations, the bridge further comprises one or more additional ports. [67] In a further aspect, various implementations of the present technology provide, in a network of interconnected bridges including a first core bridge, a second core bridge and a further bridge, the first core bridge initially being elected as a root bridge, the further bridge having a root port communicatively coupled to the first core bridge and an alternate port communicatively coupled to the second core bridge, a method for preventing propagation of stale topological information, comprising: changing a priority of the second core bridge, whereby the second core bridge is elected as a new root bridge; sending, from the second core bridge toward the first core bridge, a first update message indicating that the second core bridge is the new root bridge; sending, from the second core bridge toward the further bridge, a second update message indicating that the second core bridge is the new root bridge; receiving, at the alternate port of the further bridge, the second update message; and inverting, at the further bridge, roles of the root port and of the alternate ports.

[68] In some implementations, the method further comprises sending, from the first core bridge toward the further bridge, a third update message indicating that the second core bridge is the new root bridge; and sending, from the further bridge first core bridge toward the further bridge, a fourth update message indicating that the second core bridge is the new root bridge.

[69] In some further implementations, changing the priority of the second core bridge comprises lowering a numerical value of a priority field in an identity of the second core bridge.

[70] In the context of the present specification, unless expressly provided otherwise, a "bridge" and a "switch" are any hardware and/or software appropriate to the relevant task at hand. Thus, some non-limiting examples of hardware and/or software include computers, servers, network equipment (routers, switches, gateways, etc.) and/or combination thereof.

[71] In the context of the present specification, unless expressly provided otherwise, the expressions "memory" and "memory device" are intended to include media of any nature and kind whatsoever, non-limiting examples of which include RAM, ROM, disks (CD-ROMs, DVDs, floppy disks, hard disk drives, etc.), USB keys, flash memory cards, solid state-drives, and tape drives.

[72] Implementations of the present technology each have at least one of the above- mentioned object and/or aspects, but do not necessarily have all of them. It should be understood that some aspects of the present technology that have resulted from attempting to attain the above-mentioned object may not satisfy this object and/or may satisfy other objects not specifically recited herein.

[73] Additional and/or alternative features, aspects and advantages of implementations of the present technology will become apparent from the following description, the accompanying drawings and the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS [74] For a better understanding of the present technology, as well as other aspects and further features thereof, reference is made to the following description which is to be used in conjunction with the accompanying drawings, where:

[75] FIG. 1 illustrates a simplified example of a network of bridges; [76] Fig. 2 represents a format of a bridge ID defined according to the standard;

[77] Fig. 3 is a simplified illustration of a BPDU format;

[78] Figs. 4 to 10 provide an illustration of a count-to-infinity scenario in an RSTP fully redundant, two level hierarchical network topology;

[79] Figs. 11 to 13, together with Fig. 4, provide an illustration of a solution to the count- to-infinity problem using a configuration method;

[80] Figs. 14 and 15 provide a generalized illustration of the configuration method of Figs. 11 to 13;

[81] Figs. 16 to 19, together with Fig. 4, provide an illustration of a solution to the count- to-infinity problem that identifies stale configuration information; and [82] Fig. 20 is a block diagram of a bridge according to an embodiment.

DETAILED DESCRIPTION

[83] The examples and conditional language recited herein are principally intended to aid the reader in understanding the principles of the present technology and not to limit its scope to such specifically recited examples and conditions. It will be appreciated that those skilled in the art may devise various arrangements which, although not explicitly described or shown herein, nonetheless embody the principles of the present technology and are included within its spirit and scope.

[84] Furthermore, as an aid to understanding, the following description may describe relatively simplified implementations of the present technology. As persons skilled in the art would understand, various implementations of the present technology may be of a greater complexity. [85] In some cases, what are believed to be helpful examples of modifications to the present technology may also be set forth. This is done merely as an aid to understanding, and, again, not to define the scope or set forth the bounds of the present technology. These modifications are not an exhaustive list, and a person skilled in the art may make other modifications while nonetheless remaining within the scope of the present technology. Further, where no examples of modifications have been set forth, it should not be interpreted that no modifications are possible and/or that what is described is the sole manner of implementing that element of the present technology.

[86] Moreover, all statements herein reciting principles, aspects, and implementations of the present technology, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof, whether they are currently known or developed in the future. Thus, for example, it will be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the present technology. Similarly, it will be appreciated that any flowcharts, flow diagrams, state transition diagrams, pseudo-code, and the like represent various processes which may be substantially represented in computer-readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[87] The functions of the various elements shown in the figures, including any functional block labeled as a "processor", may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a computer, by a single shared processor, or by a plurality of individual processors, some of which may be shared. In some embodiments of the present technology, the processor may be a general purpose processor, such as a central processing unit (CPU) or a group of cooperating CPUs, or may alternatively be a processor or a group of co-processors dedicated to a specific purpose, such as a graphics processing unit (GPU). Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional and/or custom, may also be included. [88] Software modules, or simply modules which are implied to be software, may be represented herein as any combination of flowchart elements or other elements indicating performance of process operations and/or textual description. Such modules may be executed by hardware that is expressly or implicitly shown. [89] In the context of the present disclosure, a "bridge" may be a computer networking device, for example a "switch", and may operate, without limitation, in the first two (2) layers of the Open System Interconnection (OSI) model. A bridge may include a plurality of ports allowing its interconnection to other bridges, and may further include a processor and a memory. An interface may be provided for receiving configuration information, this interface being for example an operator interface directly connected to the bridge or a network interface suitable for remote connection to a distant operator interface. In a given bridge, the processor is operatively connected to the ports and to the memory. Incoming messages received at any port are treated by the processor. The processor prepares any outgoing messages and directs the ports to forward the outgoing messages. Configuration information including a bridge ID for the own bridge, a root bridge ID, states of the various ports and root path costs toward the root bridge are calculated by the processor and stored in a memory.

[90] The count-to-infinity (CTI) problem has been described hereinabove in the context of the Rapid spanning tree protocol (RSTP) topology in which a bridge identity (ID) is formed of an 8-byte field including a 2-byte priority field and a 6-byte media access control (MAC) address field and in which the bridge having the lowest bridge ID is deemed having the best priority and designated as the root bridge. Regardless, the present technology is not so limited. Applications of the present technology as described hereinbelow in non-RSTP topologies, in topologies that would define bridge identities using different formats, and/or in topologies that would define a bridge priority independently from its bridge identity are also contemplated.

First solution, changing the backup root bridge priority

[91] In an aspect of the present disclosure, the CTI problem is avoided by configuration of the priority of the backup root bridge. Figs. 11 to 13, together with Fig. 4, provide an illustration of a solution to the count-to-infinity problem using a configuration method. Reference is made again to Fig. 4 to show that, at an initial time TO, the present first solution may apply when the initial conditions described earlier are present. The bridge ID of the CORE 1 bridge is the lowest (best priority) of all bridges; it is consequently designated as the root bridge with a RPC of zero (0). Both ports PI and P2 of the CORE 1 bridge are designated ports (DP). The CORE 2 bridge stores a root bridge ID (RBID) that designates the CORE 1 bridge with a RPC of 10. P2 of the CORE 2 bridge is a DP while PI is a root port with a value of '100+A,RPC=10'. The ACCESS-SW-1 bridge stores a RBID of ΊΟΟ+Α'. In the ACCESS- SW-1 bridge, PI is a root port with a value of '100+A,RPC=10' while P2 is designated as an alternate port (ALT), with a value of '100+A,RPC=20'. As in the example of Figs. 4 to 10, costs of all links established between the various bridges are set to 10 in the topology of Figs. 4 and 11 to 13. This link cost value is used to simplification purposes and does not limit the present disclosure. It may be noted that while the costs of the various links shown in the drawings have an impact on which port of a non-root bridge is designated as the root port for that bridge, the link costs have no impact on the designation of the root bridge.

[92] In the RSTP topology, the alternate ports, such as the port P2 of the ACCESS-SW-1 bridge, are directly connected to designated ports of the backup root bridge. When the role of backup root bridge, which is the CORE 2 bridge in the example of Fig. 4, is changed so that it becomes the root bridge, it updates the bridges connected via its designated ports. Using this principle, the present first solution to the CTI problem suggests configuring the priority of the CORE 2 backup root bridge, at time Tl (Fig. 11) so that it adopts a bridge ID that causes its designation as a new root bridge. On Fig. 11, an operator changes the priority of the CORE 2 bridge from 200 to 50. The bridge ID of the CORE 2 bridge is now '50+B', which confers to this bridge a best priority than the priority of the CORE 1 root bridge, which is Ί00+Α. The CORE 2 bridge designates itself as the new root bridge and sends BPDUs on both of its ports PI and P2 to the CORE 1 bridge and to the ACCESS-SW-1 bridge respectively. The fields of the BPDUs are '50+B,RPC=0,MA=0'. [93] At time T2 (Fig. 12), the CORE 1 bridge having received on its port PI the BPDU sent by the CORE 2 bridge at time Tl notes that CORE 2 is now elected as the root bridge because of its best priority. The CORE 1 bridge stores a root bridge identity (RBID) of '50+B' with an RPC of 10. PI is elected as the root port (RP) while P2 is elected as a designated port (DP). The CORE 1 bridge sends a BPDU on port P2 toward the ACCESS-SW-1 bridge. The fields of the BPDU are '50+B,RPC=10,MA=l'. [94] Also at time T2, the ACCESS-SW-1 bridge having received on its port P2, which is currently the alternate port, the BPDU sent by the CORE 2 bridge at time Tl notes that the CORE 2 bridge is now elected as the root bridge because of its best priority. The alternate port P2 is updated to '50+B,RPC=10' and is elected as the new root port (RP) because the RBID of '50+B' has a best priority than the RBID of ΊΟΟ+Α' configured at the port PI. The ACCESS-SW-1 bridge elects PI as a designated port (DP) and sends an BPDU on port PI to the CORE 1 bridge, this BPDU having the fields '50+B,RPC=10,MA=l'.

[95] At time T3 (Fig. 13), the CORE 1 bridge having received on its port P2 the BPDU sent by the ACCESS-SW-1 bridge at time T2 notes that the CORE 2 bridge remains elected as the root bridge. Its port P2 remains elected as the DP. Also at time T3, the ACCESS-SW-1 bridge having received the BPDU from the CORE 1 bridge on its port P2 notes that the CORE 2 bridge remains elected as the root bridge. In the ACCESS-SW-1 bridge, the RPC on the port P2 is 20, which is greater than the RPC on the port PI. For that reason, P2 is elected as the alternate port in the ACCESS-SW-1 bridge. No more BPDU is sent and the RSTP topology is converged without causing the CTI scenario.

[96] Therefore, while the conventional manner of updating the RSTP topology has been to change the priority field 52 of the bridge ID 50 of the root bridge, the present solution suggests to instead change the priority field 52 of the bridge ID 50 of the backup root bridge to provide this backup root bridge a best priority so that it becomes a new root bridge. In this solution, no stale information from alternate ports of the non-root bridges is disseminated because the correct configuration is first received at the alternate ports of the non-root bridges. This solution is generalized by reference to Figs. 14 and 15 that provide a generalized illustration of the configuration method of Figs. 11 to 13. The configuration method is applied in an RSTP topology in which a core layer includes two (2) core bridges CORE 1 and CORE 2 while an aggregation layer includes two (2) aggregation bridges AGGREGATION-SW-1 and AGGREGATION- S W-2. Each of these bridges includes three (3) ports PI, P2 and P3.

[97] At time TO (Fig. 14), the various bridges are configured as follows:

[98] The CORE 1 bridge has a bridge ID ΊΟΟ+Α', in which 'A' is the MAC address of the CORE 1 bridge and '100' is an operator defined priority value. This bridge ID is numerically the lowest of all bridge IDs on Fig. 14, which in the particular case of RSTP confers the best priority to the CORE 1 bridge that is therefore elected as the root bridge. Consequently, the RBID is ΊΟΟ+Α' and the RPC is 0. All ports PI, P2 and P3 are designated ports (DP) because they all lead away from the CORE 1 root bridge.

[99] The CORE 2 bridge has a bridge ID '200+B', in which 'B' is the MAC address of the CORE 2 bridge and '200' is an operator defined priority value. The RBID is ΊΟΟ+Α' and the RPC is 10. The port PI is elected as a root port (RP) with a value '100+A,RPC=10' while the ports P2 and P3 are DPs because they lead away from the root bridge.

[100] The AGGREGATION-SW-1 bridge has a bridge ID '300+C, in which 'C is the MAC address of the AGGREGATION-SW-1 bridge and '300' is an operator defined priority value. The RBID is '100+A' and the RPC is 10. The port PI is elected as the RP with a value '100+A,RPC=10' because it has the lowest RPC to the CORE 1 root bridge. The port P3 is a DP because it leads away from the root bridge. The port P2 leads toward the root bridge, but has a RPC of 20, which is not the lowest path cost. Consequently, the port P2 is an alternate (ALT) port with a value '100+A,RPC=20'.

[101] The AGGREGATION-SW-2 bridge has a bridge ID '400+D', in which 'D' is the MAC address of the AGGREGATION-SW-2 bridge and '400' is an operator defined priority value. The RBID is '100+A' and the RPC is '10'. None of the ports is a DP because none of them leads away from the root bridge. The port P2 is elected as the RP with a value '100+A,RPC=10' because it has the lowest RPC to the CORE 1 root bridge. The ports PI and P3 both lead toward the root bridge, but have a RPC of 20, which is not the lowest path cost. Consequently, the ports PI and P3 are both alternate ports with a value '100+A,RPC=20'.

[102] At time Tl (Fig.15), the operator changes the priority of the CORE 2 bridge from 200 to 50. The bridge ID of the CORE 2 bridge is now '50+B', which confers to this bridge a best priority than the priority of the CORE 1 root bridge, which is ' 100+A. The CORE 2 bridge designates itself as the new root bridge with RBID of '50+B' and RPC of zero (0), and sends BPDUs on all of its ports PI, P2 and P3, respectively to the CORE 1 bridge, to the AGGREGATION-SW-1 bridge and to the AGGREGATION-SW-2 bridge. The fields of the BPDUs are '50+B,RPC=0,MA=0'.

[103] In the AGGREGATION-SW-1 bridge, having received the BPDU, because the RBID received at the alternate port P2 has a best priority than the previous RBID at its root port PI, P2 becomes the root port with a value '50+B,RPC=10'. Likewise in the AGGREGATION- SW-2 bridge, having received the BPDU, because the RBID received at the alternate port PI has a best priority than the previous RBID at its root port P2, PI becomes the root port with a value '50+B,RPC=10'. These updates overwrite any stale information of the alternate ports in the AGGREGATION- SW- 1 and AGGREGATION-SW-2 bridges. The AGGREGATION- SW-1 and AGGREGATION-SW-2 bridges can therefore only propagate valid configuration information when they send BPDUs on any of their ports. For example, the AGGREGATION-SW-2 bridge may send from its port P3 a BPDU to the AGGREGATION- SW-1 bridge with a value '50+B, RPC=10,MA=1'. The BPDU is then received on port P3 of the AGGREGATION- SW- 1 bridge. The received field '50+B' concurs with the RBID value already stored in the AGGREGATION-S W- 1 bridge. The received RPC field being greater than the RPC field of its root port P2, which has just be set to '50+B,RPC=10', the AGGREGATION- SW-1 bridge does not change is port designations.

[104] It may be observed that, on Fig. 14, the AGGREGATION-SW-2 bridge has more than one alternate port. Regardless, the CTI problem is avoided according to the present first solution by forwarding to that bridge the correct topology information on at least one of its alternate ports before sending the same correct information to another of its port. However, this first solution is dependent at least in part on an operator configuration, which may not be practical in some situations. For that reasons, a second solution will now be described.

Second solution, identifying the stale information [105] The second solution identifies stale information within one hop in order to discard this stale information from the RSTP Network at the onset of a CTI scenario. This allows the propagation of correct topology information only so that the network topology converges very quickly. Bridges implementing the second solution are adapted validate and detect the stale information so that they can discard this stale information from RSTP topology when modified root bridge information is received, whether by operator configuration or through receiving a BPDU. This favors a rapid propagation of the valid topology information.

[106] According to the second solution, bridges are adapted to monitor configuration changes made to the root bridge identity by the operator. When the operator changes the priority of the root bridge, the bridges temporarily record the previous root bridge identity (RBID) as a stale root bridge ID. The bridges monitor incoming BPDUs that include changes of the RBID by providing a changed root bridge priority and root bridge MAC address for all configured spanning tree VLAN instances.

[107] When a bridge is informed of a configuration change that causes a change of the designation of the root bridge for a specific spanning tree VLAN instance, that bridge records the previous RBID as a stale root bridge ID for the specific spanning tree VLAN instance and activates a CTI detection logic for a brief time window. In a non-limitative example, this time window may be set to two (2) Hello time periods, for example four (4) seconds. According to the RSTP standard, the bridge then updates the RBID for the specific spanning VLAN instance according to the received root bridge priority configuration and forwards BPDUs on all of its designated ports to report the updated RBID. Using the recorded stale root bridge ID, the bridge will be able to detect and discard an eventual BPDU received with the stale information. The CTI detection logic is inactivated at the end of the time window if no stale information has been received. The recorded stale root bridge ID information is deleted from each bridge at the end of the time window. [108] In more details, Figs. 16 to 19, together with Fig. 4, provide an illustration of a solution to the CTI problem that identifies stale configuration information. Reference is made again to Fig. 4 to show that, at an initial time TO, the present second solution may apply when the initial conditions described earlier are present. The bridge ID of the CORE 1 bridge is the lowest (best priority) of all bridges; it is consequently designated as the root bridge with a RPC of zero (0). Both ports PI and P2 of the CORE 1 bridge are designated ports (DP). The CORE 2 bridge stores a root bridge ID (RBID) that designates the CORE 1 bridge with a RPC of 10. P2 of the CORE 2 bridge is a DP while PI is a root port with a value of '100+A,RPC=10'. The ACCESS-SW-1 bridge stores a RBID of ΊΟΟ+Α'. In the ACCESS- SW-1 bridge, PI is a root port with a value of '100+A,RPC=10' while P2 is designated as an alternate port (ALT), with a value of '100+A,RPC=20'. As in the previous examples, all link costs are set to 10 in the topology of Figs. 4 and 11 to 13. This link cost value is used to simplification purposes and does not limit the present disclosure. Without limitation, initial conditions for the present second solution are therefore identical to those of the previous examples. [109] The following paragraphs, which will refer to Figs. 16-19, provide an example to illustrate the present second solution for a spanning tree VLAN 10 instance. [110] At time Tl (Fig. 16), the operator configures the CORE 1 bridge to become by backup root bridge by changing its priority to 250 for a spanning tree VLAN 10 instance. It may be observed that the priority of the CORE 2 bridge, which remains at 200, is now numerically lower - and thus better - than the priority of the CORE 1 bridge. The CORE 1 bridge records the previous RBID ΊΟΟ+Α' as a stale root bridge ID for the spanning tree VLAN 10 instance and initiates the CTI detection logic for a 4-second time window. The CORE 1 bridge sends BPDUs with its fields set to '250+A,RPC=0,MA=0' to via both its designated ports PI and P2 to the directly connected bridges CORE 2 and ACCESS-SW-1.

[Il l] At time T2 (Fig. 17), the CORE 2 bridge having received the BPDU sent by the CORE 1 bridge at time Tl determines that it does not currently have any recorded stale root bridge

ID and that its own bridge ID '200+B' has a best priority when compared to the bridge ID field '250+A', of the received BPDU. The CORE 2 bridge declares itself as the root bridge.

The CORE 2 bridge records the previous RBID ΊΟΟ+Α' as a stale root bridge ID for the spanning tree VLAN 10 instance and initiates the CTI detection logic for a 4-second time window. The CORE 2 bridge sends BPDUs carrying its bridge ID '200+B' as the bridge ID field, with a RPC of zero (0), to its connected bridges. The BPDUs are sent to the CORE 1 bridge at time T2.1 and to the ACCESS-SW-1 bridge at time T2.2.

[112] Also at time T2, the ACCESS-SW-1 bridge having received the BPDU sent by the CORE 1 bridge at time Tl determines that it does not currently have any recorded stale root bridge ID. The ACCESS-SW-1 bridge updates its root port PI to '250+A,RPC=10' and records the previous RBID ΊΟΟ+Α' as a stale root bridge ID for the spanning tree VLAN 10 instance and initiates the CTI detection logic for a 4-second time window. Because the P2 alternate port of the ACCESS-SW-1 bridge still has the value of 'ALT-100+A,RPC=20', P2 is elected as the best port to reach what still appears to be the root bridge with a bridge ID of ΊΟΟ+Α'. P2 changes its state to forwarding and changes its function from alternate port to root port with a value '100+A,RPC=20'. This is evidently an incorrect value, given that no bridge currently has a bridge ID of ΊΟΟ+Α'. RSTP cannot at this point in time determine that this is incorrect information. At time T2.1, the ACCESS-SW-1 forwards a BPDU via it port PI to the CORE 1 bridge to indicate that is has a best path to a root bridge, the fields of the BPDU being '100+A,RPC=20,MA=2'. Likewise, at time T2.2, the ACCESS-SW-1 forwards a BPDU via it port PI to the CORE 2 bridge to indicate that is has a best path to a root bridge, the fields of the BPDU being '100+A,RPC=20,MA=2'. [113] At time T3 (Fig. 18), the CORE 1 bridge having received a correct BPDU sent by the CORE 2 bridge at time T2.1 notes that this RBID is not the stale root bridge ID recorded in the CORE 1 bridge at time Tl. The CORE 1 bridge therefore accepts the best priority defined by the RBID '200+B' and accepts the CORE 2 bridge as the root bridge. The CORE 1 bridge changes its role from root bridge to backup root bridge. The CORE 1 bridge also assigns its port PI as its RP with an RPC of 10. This is valid topology information received from the CORE 2 bridge. The CORE 1 root bridge has also received the BPDU sent at time T2.1 from ACCESS-SW-1 bridge. The bridge ID field of this last BPDU is ΊΟΟ+Α', which is a better priority than the priority '200+B' of the RBID that has been just stored at the CORE 1 bridge. Using the CTI detection logic, the CORE 1 bridge matches the ΊΟΟ+Α' bridge ID received in the BPDU from the ACCESS-SW-1 bridge to the stale root bridge ID recorded at time Tl. Consequently, the CORE 1 bridge discards the information received in the BPDU from the ACCESS-SW-1 bridge and sends another BPDU to the ACCESS-SW-1 bridge with the correct information '200+B, RPC=10,MA=1'. It may be observed that the order in which are received the correct BPDU from the CORE 2 bridge and the incorrect BPDU from the ACCESS-SW-1 has no consequence: the correct BPDU is accepted and the incorrect BPDU is rejected notwithstanding their order of arrival at the CORE 1 bridge.

[114] Also at time T3, the CORE 2 bridge has just received the BPDU sent at time T2.2 from the ACCESS-SW-1 bridge. The bridge ID field of this last BPDU is ΊΟΟ+Α', which is a better priority than the priority '200+B' of the RBID stored in the CORE 2 bridge at time T2. Using the CTI detection logic, the CORE 2 bridge matches the '100+A' bridge ID received in the BPDU from the ACCESS-SW-1 bridge to the stale root bridge ID recorded at time T2. Consequently, the CORE 2 bridge discards the information received in the BPDU from the ACCESS-SW-1 bridge and sends another BPDU to the ACCESS-SW-1 bridge with the correct information '200+B, RPC=10,MA=1 ' .

[115] Still at time T3, the ACCESS-SW-1 bridge having received on its port P2 the BPDU sent at time T2.2 by the CORE 2 bridge with '200+B, RPC=0' notes that this RBID does not match the stale root bridge ID it has recorded at time T2. The ACCESS-SW-1 bridge changes the RBID to '200+B, designating the CORE 2 bridge and updates its port P2 as the root port with a RPC of 10. The ACCESS-SW-1 bridge records the previous RBID ΊΟΟ+Α' as stale root bridge ID for the spanning tree VLAN 10 instance and initiates the CTI detection logic for a 4-second time window. The ACCESS-SW-1 then forwards another BPDU with the correct information '200+B,RPC=10' to the CORE 1 bridge through its designated port PI.

[116] At time T4 (Fig. 19), the CORE 1 bridge having received from the ACCESS-SW-1 bridge on its port P2 a BPDU send at time T3 with the correct information '200+B,RPC=10' accepts the BPDU and updates its port P2 as a designated port. Also at time T4, the ACCESS- SW-1 bridge having received on its port PI a BPDU sent at time T3 by the CORE 1 bridge with the correct information '200+B,RPC=10' accepts the BPDU. Because the RPC on the port PI is 20, which is greater than the RPC on the port P2, the port PI of the ACCESS-SW-1 becomes an alternate port with '200+B,RPC=20'. Now ACCESS-SW-1 can reach the Root Bridge 'RBID-200+B' via its root port P2 with an RPC of 10.

[117] With the second solution, at time T4, all bridges share the same correct RBID '200+B' and no more BPDU messages, other than regular heartbeat messages, need to be sent to propagate the RSTP topology. The network of Fig. 19 is stable with the correct RSTP topology. [118] Fig. 20 is a block diagram of a bridge according to an embodiment. A bridge 100 as shown generically represents, in a number of variants, the bridges 14, 16, 24, 26, 24 and 36 of Fig. 1, as well as the CORE 1 bridge, the CORE 2 bridge, the ACCESS-SW-1 bridge and the ACCESS-SW-2 bridge of the various other drawings. The bridge 100 includes a processor 102, a memory device 104, a configuration interface 106 and two ports respectively referred to as PI 108 and P2 1110. On Fig. 20, thick arrows illustrate traffic and signalling exchanged between the bridge 100 and peer bridges (not shown). Traffic and signalling 112 is exchanged with a first peer bridge via the port PI 108. Traffic and signalling 114 is exchanged with a second peer bridge via the port PI 110. Data traffic received at the port PI 108 is forwarded 118 to the port P2 110, and vice-versa. Signalling such as BPDUs received at either of the ports PI 108 and P2 110 is forwarded from the port having received it to the processor 102. Likewise, the processor 102 may request the ports PI 108 and P2 110 to forward BPDUs to either of the first and second peer bridges. Figure 20 is greatly simplified and other elements of the bridge 100 are not shown for ease of illustration. In an actual implementation, the bridge 100 may comprise a higher number of ports capable of communicating over links toward a number of peer bridges. [119] The configuration interface 106 may comprise an operator interface or may be communicatively coupled to a remote operator interface (not shown). Configuration information 116 is received at the configuration interface 106 and forwarded to the processor 102 for processing and for storage in the memory device 104. In particular, the configuration information 116 may comprise information about the identity of the bridge 100. Referring to Fig. 2, the confirmation information 116 may comprise information related to the priority field 52, which is part of a bridge ID 50 of the bridge 100. Other conventional manners of storing in the memory device 104 a priority of the bridge 100 are also contemplated.

[120] In a particular implementation of the bridge 100, the processor 102 stores, in the memory device 104, an identity of a current root bridge. The processor 102 is made aware of first modified root bridge information received at the bridge 100. The first modified root bridge information may be received in the form of a changed priority of the bridge 100 as part of configuration information 116 received at the configuration interface 106. Alternatively, the first modified root bridge information may part of an update message, for example a BPDU, received at one of the ports PI 108 and P2 110 and forwarded to the processor 102. The processor 102 having received the first modified root bridge information records the identity of the current root bridge as stale information in the memory device 104 before using the first modified root bridge information to update, in the memory device 104, the identity of the current root bridge. It should be observed that the memory device 104 stores the identity of the current root bridge and the stale information as two (2) distinct information elements. The processor 102 may implement a timer that, upon expiry, will trigger the deletion of the stale information stored in the memory device 104. The processor then requests one of the ports PI 108 and P2 110 to send a first BPDU carrying the identity of the current root bridge. When one of the first and second ports PI 108 and P2 110 receives a second BPDU carrying second modified root bridge information, the second modified root bridge information is forwarded to the processor 102. The processor 102 uses the second modified root bridge information to update, in the memory device 104, the identity of the current root bridge on the condition that the second modified root bridge information does not match the stale information stored in the memory device 104. If the second modified root bridge information is consistent with the stale information, the second modified root bridge information is ignored by the bridge 100. [121] When the bridge 100 has a best priority among a plurality of interconnected bridges, it is designated as the current root bridge and the own identity of the bridge 100 is stored in the memory device 104 as the identity of the current root bridge. In that situation, both the first and second ports PI 108 and P2 110 are designated ports because they both relate to non-root peer bridges.

[122] When the bridge 100 does not have the best priority among a plurality of interconnected bridges, the memory device 104 stores the identity of the current root bridge according to information received in a BPDU. In that situation, one of the first and second ports PI 108 and P2 110 is elected as a root port while the other of the first and second ports PI 108 and P2 110 is elected as a designated port or as an alternate port. The root port is the port of the bridge 100 having the lowest path cost toward the root bridge while a designated port of the bridge 100 leads to a peer bridge further away from the root bridge. A port is an alternate port if it leads to a peer bridge that itself has a better path cost toward the root bridge. [123] The processor 102 is generally configured to execute the various operations of the bridges described in Figs. 1 to 19. However, a particular bridge 100 may be part of the core layer 12 and operate as a root bridge or as a backup root bridge while another particular bridge 100 may be part of the distribution layer 22 or part of the access layer 32. For that reason, in some embodiments, the processor 102 may implement a subset of the features of the bridges described in Figs. 1 to 19.

[124] The present second solution is capable of detecting the stale information and preventing the CTI problem in a network where at least some of the bridges implement the CTI detection logic and record stale root bridge identities. In particular, in an RSTP topology having a three-level hierarchy, it is sufficient to implement the CTI detection logic in at least two (2) bridges for the second solution to perform adequately.

[125] Laboratory tests of RSTP topologies similar to the one described in relation to the above Table I were performed with bridges implementing the present second solution. Traffic convergence was obtained in various tests after delays ranging between 20 and 50 seconds for all 128 spanning tree VLAN instances. [126] It should be expressly understood that implementations of the system and of the method for preventing propagation of stale topological information are provided for illustration purposes only. As such, those skilled in the art will easily appreciate other specific implementational details for the system and for the method for preventing propagation of stale topological information. As such, by no means, examples provided herein above are meant to limit the scope of the present technology.

[127] While the above-described implementations have been described and shown with reference to particular operations performed in a particular order, it will be understood that these operations may be combined, sub-divided, or re-ordered without departing from the teachings of the present technology. Accordingly, the order and grouping of the operations is not a limitation of the present technology.

[128] As such, the methods and systems implemented in accordance with some non-limiting embodiments of the present technology can be represented as follows, presented in numbered clauses. [Clause 1] A method for preventing propagation of stale topological information, comprising: storing, at a bridge, an identity of a current root bridge; receiving, at the bridge, first modified root bridge information; in response to receiving, at the bridge, the first modified root bridge information, recording, at the bridge, the identity of the current root bridge as stale information before using the first modified root bridge information to update the identity of the current root bridge and sending, from the bridge, a first update message carrying the identity of the current root bridge; receiving, at the bridge, a second update message carrying second modified root bridge information; and using, at the bridge, the second modified root bridge information to update the identity of the current root bridge if the second modified root bridge information does not match the stale information. [Clause 2] The method of clause 1, wherein recording, at the bridge, the identity of the current root bridge as stale information further comprises starting a timer and deleting the stale information when the timer expires.

[Clause 3] The method of any one of clauses 1 or 2, wherein the identity of the current root bridge, the first modified root bridge information and the second modified root bridge information each defines a bridge priority.

[Clause 4] The method of clause 3, wherein an identity of a given bridge is formed of a combination of a priority value assigned to the given bridge and of a media access control (MAC) address of the given bridge.

[Clause 5] The method of clause 4, wherein the priority value is in a most significant portion of the identity of the given bridge and the MAC address of the given bridge is in a least significant portion of the identity of the given bridge

[Clause 6] The method of clause 5, wherein the given bridge is elected as the current root bridge if is has a best priority among a plurality of interconnected bridges

[Clause 7] The method of clause 6, wherein the best priority is conferred by a numerically lower value among identities of the plurality of interconnected bridges

[Clause 8] The method of any one of clauses 1 to 7, wherein the bridge is the current root bridge and wherein receiving, at the bridge, first modified root bridge information comprises receiving operator configuration information to modify a priority of the bridge

[Clause 9] The method of clause 8, wherein a root path cost to the root bridge is zero and wherein the first update message sent by the bridge further carries the root path cost

[Clause 10] The method of clause 9, wherein the first update message sent by the bridge further carries a message age set to zero

[Clause 11] The method of any one of clauses 1 to 10, wherein receiving, at the bridge, first modified root bridge information comprises receiving a third update message carrying the first modified root bridge information [Clause 12] The method of clause 11, wherein the third update message received by the bridge further carries a root path cost and wherein the first update message sent by the bridge further carries a sum of the root path cost and of a cost of link established between the bridge and a bridge having sent the third update message

[Clause 13] The method of clause 12, wherein the third update message received by the bridge further carries a message age and wherein the first update message sent by the bridge further carries the message age having been incremented by one

[Clause 14] The method of any one of clauses 1 to 13, wherein the bridge is part of a rapid spanning tree protocol (RSTP) network

[Clause 15] The method of any one of clauses 1 to 14, wherein the first update message is sent on one or more destination ports of the bridge

[Clause 16] A bridge, comprising: a first port adapted for communicating with a first peer bridge; a second port adapted for communicating with a second peer bridge; a memory device; and a processor operatively connected to the first and second ports and operative to read and write in the memory device, the processor being configured to: store, in the memory device, an identity of a current root bridge; receive first modified root bridge information; in response to receiving the first modified root bridge information, record, in the memory device, the identity of the current root bridge as stale information before using the first modified root bridge information to update, in the memory device, the identity of the current root bridge and sending, via one of the first and second ports, a first update message carrying the identity of the current root bridge; receive, via one of the first and second ports, a second update message carrying second modified root bridge information; and use the second modified root bridge information to update, in the memory device, the identity of the current root bridge if the second modified root bridge information does not match the stale information stored in the memory device

[Clause 17] The bridge of clause 16, wherein the processor is further configured to start a timer when recording the stale information in the memory device and to delete the stale information in the memory device when the timer expires

[Clause 18] The bridge of any one of clauses 16 or 17, wherein the first port is adapted to receive the first modified root bridge information

[Clause 19] The bridge of any one of clauses 16 to 18, further comprising an interface allowing an operator to provide the first modified root bridge information

[Clause 20] The bridge of any one of clauses 16 to 19, wherein the processor is further configured to send an instance of the first update message carrying the identity of the current root bridge via each of the first and second ports

[Clause 21] The bridge of any one of clauses 16 to 20, wherein one of the first and second ports is a root port and an other of the first and second ports is a designated port or an alternate port

[Clause 22] The bridge of any one of clauses 16 to 20, wherein the first and second ports are both designated ports

[Clause 23] The bridge of any one of clauses 16 to 22, further comprising one or more additional ports

[Clause 24] In a network of interconnected bridges including a first core bridge, a second core bridge and a further bridge, the first core bridge initially being elected as a root bridge, the further bridge having a root port communicatively coupled to the first core bridge and an alternate port communicatively coupled to the second core bridge, a method for preventing propagation of stale topological information, comprising: changing a priority of the second core bridge, whereby the second core bridge is elected as a new root bridge; sending, from the second core bridge toward the first core bridge, a first update message indicating that the second core bridge is the new root bridge; sending, from the second core bridge toward the further bridge, a second update message indicating that the second core bridge is the new root bridge; receiving, at the alternate port of the further bridge, the second update message; and inverting, at the further bridge, roles of the root port and of the alternate ports.

[Clause 25] The method of clause 24, further comprising: sending, from the first core bridge toward the further bridge, a third update message indicating that the second core bridge is the new root bridge; and sending, from the further bridge first core bridge toward the further bridge, a fourth update message indicating that the second core bridge is the new root bridge.

[Clause 26] The method of any one of clauses 24 or 25, wherein changing the priority of the second core bridge comprises lowering a numerical value of a priority field in an identity of the second core bridge.

[129] It should be expressly understood that not all technical effects mentioned herein need to be enjoyed in each and every embodiment of the present technology. For example, embodiments of the present technology may be implemented without the user enjoying some of these technical effects, while other embodiments may be implemented with the user enjoying other technical effects or none at all.

[130] Some of these operations and signal sending-receiving are well known in the art and, as such, have been omitted in certain portions of this description for the sake of simplicity. The signals can be sent-received using optical means (such as a fibre-optic connection), electronic means (such as using wired or wireless connection), and mechanical means (such as pressure-based, temperature based or any other suitable physical parameter based). [131] Modifications and improvements to the above-described implementations of the present technology may become apparent to those skilled in the art. The foregoing description is intended to be exemplary rather than limiting. The scope of the present technology is therefore intended to be limited solely by the scope of the appended claims.

Claims

What is claimed is:

1. A method for preventing propagation of stale topological information, comprising: storing, at a bridge, an identity of a current root bridge;

receiving, at the bridge, first modified root bridge information;

in response to receiving, at the bridge, the first modified root bridge information, recording, at the bridge, the identity of the current root bridge as stale information before using the first modified root bridge information to update the identity of the current root bridge and sending, from the bridge, a first update message carrying the identity of the current root bridge;

receiving, at the bridge, a second update message carrying second modified root bridge information; and

using, at the bridge, the second modified root bridge information to update the identity of the current root bridge if the second modified root bridge information does not match the stale information.

2. The method of claim 1, wherein recording, at the bridge, the identity of the current root bridge as stale information further comprises starting a timer and deleting the stale information when the timer expires.

3. The method of claim 1, wherein the identity of the current root bridge, the first modified root bridge information and the second modified root bridge information each defines a bridge priority.

4. The method of claim 3, wherein an identity of a given bridge is formed of a combination of a priority value assigned to the given bridge and of a media access control (MAC) address of the given bridge.

5. The method of claim 4, wherein the priority value is in a most significant portion of the identity of the given bridge and the MAC address of the given bridge is in a least significant portion of the identity of the given bridge.

6. The method of claim 5, wherein the given bridge is elected as the current root bridge if is has a best priority among a plurality of interconnected bridges.

7. The method of claim 6, wherein the best priority is conferred by a numerically lower value among identities of the plurality of interconnected bridges.

8. The method of claim 1, wherein the bridge is the current root bridge and wherein receiving, at the bridge, first modified root bridge information comprises receiving operator configuration information to modify a priority of the bridge.

9. The method of claim 8, wherein a root path cost to the root bridge is zero and wherein the first update message sent by the bridge further carries the root path cost.

10. The method of claim 9, wherein the first update message sent by the bridge further carries a message age set to zero.

11. The method of claim 1, wherein receiving, at the bridge, first modified root bridge information comprises receiving a third update message carrying the first modified root bridge information.

12. The method of claim 11, wherein the third update message received by the bridge further carries a root path cost and wherein the first update message sent by the bridge further carries a sum of the root path cost and of a cost of link established between the bridge and a bridge having sent the third update message.

13. The method of claim 12, wherein the third update message received by the bridge further carries a message age and wherein the first update message sent by the bridge further carries the message age having been incremented by one.

14. The method of claim 1, wherein the bridge is part of a rapid spanning tree protocol (RSTP) network.

15. The method of any one of claims 1 to 14, wherein the first update message is sent on one or more destination ports of the bridge.

16. A bridge, comprising:

a first port adapted for communicating with a first peer bridge;

a second port adapted for communicating with a second peer bridge;

a memory device; and

a processor operatively connected to the first and second ports and operative to read and write in the memory device, the processor being configured to:

store, in the memory device, an identity of a current root bridge; receive first modified root bridge information;

in response to receiving the first modified root bridge information, record, in the memory device, the identity of the current root bridge as stale information before using the first modified root bridge information to update, in the memory device, the identity of the current root bridge and sending, via one of the first and second ports, a first update message carrying the identity of the current root bridge;

receive, via one of the first and second ports, a second update message carrying second modified root bridge information; and

use the second modified root bridge information to update, in the memory device, the identity of the current root bridge if the second modified root bridge information does not match the stale information stored in the memory device.

17. The bridge of claim 16, wherein the processor is further configured to start a timer when recording the stale information in the memory device and to delete the stale information in the memory device when the timer expires.

18. The bridge of claim 16, wherein the first port is adapted to receive the first modified root bridge information.

19. The bridge of claim 16, further comprising an interface allowing an operator to provide the first modified root bridge information.

20. The bridge of claim 16, wherein the processor is further configured to send an instance of the first update message carrying the identity of the current root bridge via each of the first and second ports.

21. The bridge of claim 16, wherein one of the first and second ports is a root port and an other of the first and second ports is a designated port or an alternate port.

22. The bridge of claim 16, wherein the first and second ports are both designated ports.

23. The bridge of any one of claims 16 to 22, further comprising one or more additional ports.

24. In a network of interconnected bridges including a first core bridge, a second core bridge and a further bridge, the first core bridge initially being elected as a root bridge, the further bridge having a root port communicatively coupled to the first core bridge and an alternate port communicatively coupled to the second core bridge, a method for preventing propagation of stale topological information, comprising:

changing a priority of the second core bridge, whereby the second core bridge is elected as a new root bridge;

sending, from the second core bridge toward the first core bridge, a first update message indicating that the second core bridge is the new root bridge;

sending, from the second core bridge toward the further bridge, a second update message indicating that the second core bridge is the new root bridge;

receiving, at the alternate port of the further bridge, the second update message; and inverting, at the further bridge, roles of the root port and of the alternate ports.

25. The method of claim 24, further comprising:

sending, from the first core bridge toward the further bridge, a third update message indicating that the second core bridge is the new root bridge; and

sending, from the further bridge first core bridge toward the further bridge, a fourth update message indicating that the second core bridge is the new root bridge.

26. The method of any one of claims 24 or 25, wherein changing the priority of the second core bridge comprises lowering a numerical value of a priority field in an identity of the second core bridge.