Abstract: A virtual chassis system includes a plurality of network nodes configured with a master virtual chassis address. The network nodes are connected by virtual fabric link (VFLs) that provide a connection for exchange of data packets between the network nodes. The data packets include source MAC addresses and associated hardware device information, such as source chassis ID, source network interface identifier and source port identifier information. The network nodes use this information to maintain synchronized MAC address tables for forwarding of data packets in the virtual chassis system. One or more control protocols in the network node are used for topology discovery, master network node election, generation of routing tables, health monitoring and other functions.

Abstract: A virtual chassis system includes a plurality of network nodes configured with a master virtual chassis address. The network nodes are connected by virtual fabric link (VFLs) that provide a connection for exchange of packets between the network nodes. The packets include source MAC addresses and associated hardware device information, such as source chassis ID, source network interface identifier and source port identifier information. The network nodes use this information to maintain synchronized MAC address tables for forwarding of packets in the virtual chassis system.

Abstract: A virtual chassis system includes a plurality of network nodes connected by virtual fabric link (VFLs) that provide a connection for exchange of packets between the network nodes. A network node in the virtual chassis system is operable in a pass thru mode. In pass thru mode, the network node receives packets over a VFL and transparently forwards the packet over another VFL to another network node in the virtual chassis system. However, the network node 110 disables other port interfaces, such as port interfaces connected to external nodes from the virtual chassis system. The network node 110 in pass thru mode is operable to receive management commands over one or more VFLs and can still be managed through management commands.

Abstract: A virtual chassis system includes a plurality of network nodes configured with a master virtual chassis address. The network nodes are connected by virtual fabric link (VFLs) that provide a connection for exchange of packets between the network nodes. The packets include source MAC addresses and associated hardware device information, such as source chassis ID, source network interface identifier and source port identifier information. The network nodes use this information to maintain synchronized MAC address tables for forwarding of packets in the virtual chassis system.

Abstract: A virtual chassis system includes a plurality of network nodes connected by virtual fabric link (VFLs) that provide a connection for exchange of packets between the network nodes. A network node in the virtual chassis system is operable in a pass thru mode. In pass thru mode, the network node receives packets over a VFL and transparently forwards the packet over another VFL to another network node in the virtual chassis system. However, the network node 110 disables other port interfaces, such as port interfaces connected to external nodes from the virtual chassis system. The network node 110 in pass thru mode is operable to receive management commands over one or more VFLs and can still be managed through management commands.

Abstract: A virtual chassis system includes a plurality of network nodes configured with a master virtual chassis address. The network nodes are connected by virtual fabric link (VFLs) that provide a connection for exchange of data packets between the network nodes. The data packets include source MAC addresses and associated hardware device information, such as source chassis ID, source network interface identifier and source port identifier information. The network nodes use this information to maintain synchronized MAC address tables for forwarding of data packets in the virtual chassis system. One or more control protocols in the network node are used for topology discovery, master network node election, generation of routing tables, health monitoring and other functions.

Abstract: A manner of providing for re-convergence in a dual homing network following the failure of one of the dual homing links. When such a failure is detected, the port roles are recomputed using an xSTP protocol. Prior to the completion of the computation, the operEdge variable is set to true, typically resulting in a more rapid re-convergence that may achieve sub 50 ms performance. When the computation is complete, the operEdge variable is reset to “false. The xSTP protocol may be, for example, RSTP or MSTP. The invention may be implemented in a CE device attached to a VPLS core or other network, and may be used in a LAG environment.

Abstract: A bridge (e.g., IEEE 802.1 bridge) and a method are described herein which ensure the proper propagation of a “cut” within a bridged network (e.g., Ethernet-based bridged network). In one embodiment, the bridge has a port role transitions (PRT) state machine which uses a first condition represented as (proposed && !agree) to transit to an X_PROPOSED state and a second condition represented as (! proposed && allSynced && !agree) ? (proposed && agree) to transit to an X_AGREED state (where X represents “ROOT”, “ALTERNATE” and “MASTER”). The first condition and the second condition are both defined such that the X_PROPOSED state is always entered before the X_AGREED state which ensures the proper propagation of a “cut” within the bridged network.

Abstract: A manner of providing for re-convergence in a dual homing network following the failure of one of the dual homing links. When such a failure is detected, the port roles are recomputed using an xSTP protocol. Prior to the completion of the computation, the operEdge variable is set to true, typically resulting in a more rapid re-convergence that may achieve sub 50 ms performance. When the computation is complete, the operEdge variable is reset to “false. The xSTP protocol may be, for example, RSTP or MSTP. The invention may be implemented in a CE device attached to a VPLS core or other network, and may be used in a LAG environment.

Abstract: System and method for performing automatic trunk formation in a multiple spanning tree protocol (“MSTP”)-enabled bridge comprising a plurality of ports are described. In one embodiment, the method comprises determining which ones of the ports comprise MSTP trunk ports; forming an MSTP trunk group for each multiple spanning tree instance (“MSTI”) comprising a group of Virtual Local Area Networks (“VLANs”) belonging to the MSTI; and, for each of the MSTP trunk ports, determining whether a status of the MSTP trunk port is trunk active and if so, adding all VLANs in the MSTP trunk group of the MSTIs that are forwarding on the MSTP trunk port as tagged members of the MSTP trunk port.

Abstract: A bridge (e.g., IEEE 802.1 bridge) and a method are described herein which ensure the proper propagation of a “cut” within a bridged network (e.g., Ethernet-based bridged network). In one embodiment, the bridge has a port role transitions (PRT) state machine which uses a first condition represented as (proposed && !agree) to transit to an X_PROPOSED state and a second condition represented as (! proposed && allSynced && !agree) ? (proposed && agree) to transit to an X_AGREED state (where X represents “ROOT”, “ALTERNATE” and “MASTER”). The first condition and the second condition are both defined such that the X_PROPOSED state is always entered before the X_AGREED state which ensures the proper propagation of a “cut” within the bridged network.

Abstract: System and method for performing automatic trunk formation in a multiple spanning tree protocol (“MSTP”)-enabled bridge comprising a plurality of ports are described. In one embodiment, the method comprises determining which ones of the ports comprise MSTP trunk ports; forming an MSTP trunk group for each multiple spanning tree instance (“MSTI”) comprising a group of Virtual Local Area Networks (“VLANs”) belonging to the MSTI; and, for each of the MSTP trunk ports, determining whether a status of the MSTP trunk port is trunk active and if so, adding all VLANs in the MSTP trunk group of the MSTIs that are forwarding on the MSTP trunk port as tagged members of the MSTP trunk port.