Multiple Spanning Tree Protocol: Difference between revisions

Revision as of 14:21, 26 September 2017

Latest revision as of 21:45, 30 May 2025

(39 intermediate revisions by 20 users not shown)

Line 1:

{{Short description|Network protocol that builds a loop-free logical topology for Ethernet networks}}

{{IPstack}}

{{commons category|MSTPMultiple Spanning Tree Protocol}}

The '''''Multiple Spanning Tree Protocol''''' (MSTP) and [[algorithm]], provides both, simple and full, connectivity assigned to any given [[Virtual LAN]] (VLAN) throughout a Bridged Local Area Network. MSTP uses [[Bridge Protocol Data Unit|BPDUs]] to exchange information between spanning-tree compatible devices, to prevent loops in each [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances (MSTI)|MSTI]] (Multiple Spanning Tree Instances) and in the [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree(CST/CIST)|CIST]] (Common and Internal Spanning Tree), by selecting active and blocked paths. This is done as well as in [[Spanning Tree Protocol|STP]] without the need of manually enabling backup links and getting rid of [[Bridging (networking)|bridge]] [[Switching loop|loops]] danger.

The '''''Multiple Spanning Tree Protocol''''' ('''MSTP''') and [[algorithm]], provides both, simple and full, connectivity assigned to any given [[Virtualvirtual LAN]] (VLAN) throughout a Bridgedbridged Local[[local Areaarea Networknetwork]]. MSTP uses [[Bridgebridge Protocolprotocol Datadata Unit|BPDUsunit]] (BPDUs) to exchange information between spanning-tree compatible devices, to prevent loops in each [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances (MSTI)|MSTI]] (Multiple Spanning Tree Instancesinstance]] (MSTI) and in the [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree (CST/CIST)|CIST]] (Commoncommon and Internalinternal Spanningspanning Treetree]] (CIST), by selecting active and blocked paths. This is done as well as in [[Spanning Tree Protocol|STP]] (STP) without the need of manually enabling backup links and getting rid of [[Bridging (networking)|bridge]] [[Switchingswitching loop|loops]] danger.

Moreover, MSTP allows frames/packets assigned to different VLANs to follow separate paths, each based on an independent MSTI, within MST Regions composed of [[Local area network| LANs]] and or MST Bridges. These Regions and the other Bridges and LANs are connected into a single Common Spanning Tree (CST).

Moreover, MSTP allows frames/packets assigned to different VLANs to follow separate paths, each based on an independent MSTI, within MST Regionsregions composed of [[Locallocal area network|networks (LANs]] ) and or MST Bridgesbridges. These Regionsregions and the other Bridgesbridges and LANs are connected into a single Commoncommon Spanningspanning Treetree (CST).

== History ==

It was originally defined in [[Institute of Electrical and Electronics Engineers|IEEE]] 802.1s as an amendment to [[IEEE 802.1Q|802.1Q]], 1998 edition and later merged into [[IEEE 802.1Q]]-2005 Standard, clearly defines an extension or an evolution of [[Radia Perlman]]'s Spanning Tree Protocol (STP) and the [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|Rapid Spanning Tree Protocol]] (RSTP). It has some similarities with [[Cisco Systems]]' Multiple Instances Spanning Tree Protocol (MISTP), but there are some differences.

== History and motivation ==

If there is only one VLAN in the network, single (traditional) STP/RSTP will work appropriately but if the network contains more than one VLAN, the logical network configured by single STP/RSTP wouldn’t work as efficiently as it is supposed to, even letting some errors ([[Switching loop|loops]], bad paths…) to appear. Instead, it is possible to make better use of the alternate paths available by using an alternate [[spanning tree]] for different VLANs or groups of VLANs, here is where the necessity of hammering away a new extension of RSTP philosophy into multiple trees organized by VLANs' groups came up.

It was originally defined in [[Institute of Electrical and Electronics Engineers|IEEE]] 802.1s as an amendment to [[IEEE 802.1Q|802.1Q]], 1998 edition and later merged into [[IEEE 802.1Q]]-2005 Standard, clearly defines an extension or an evolution of [[Radia Perlman]]'s Spanning Tree Protocol (STP) and the [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|Rapid Spanning Tree Protocol]] (RSTP). It has some similarities with [[Cisco Systems]]' Multiple Instances Spanning Tree Protocol (MISTP), but there are some differences.

The original STP and RSTP work on the physical link level, preventing bridge loops when redundant paths are present. However, when a LAN is virtualized using VLAN trunking, each physical link represents multiple logical connections. Blocking a physical link blocks all its logical links and forces all traffic through the remaining physical links within the [[spanning tree]]. Redundant links cannot be utilized at all. Moreover, without careful network design, seemingly redundant links on the physical level may be used to connect ''different'' VLANs and blocking any of them may disconnect one or more VLANs, causing ''bad paths''.

Instead, MSTP provides a potentially better utilization of alternate paths by enabling the use of alternate spanning trees for different VLANs or groups of VLANs.

== Main Entities ==

Line 14 ⟶ 18:

=== Multiple Spanning Tree Instances (MSTI) ===

[[File:MSTI.png|thumb|Different Spanning trees created by different MSTIs on the same physical layout.]]

As MSTP enables grouping and mapping VLANs into different spanning tree instances, there’sthere's an urge of determining a group or set of VLANs, which are all using the same spanning tree, this is what we come to know as a MSTI. <br />

Each instance defines a single forwarding topology for an exclusive set of VLANs, by contrast, STP or RSTP networks contains only a single spanning tree instance for the entire network, which contains all the VLANs. A region can include:<ref>{{cite book

|last = packard

Line 20 ⟶ 24:

|title = Multiple Instance Spanning-Tree Operation

|year = 2006

|url = ftphttp://ftp.hp.com/pub/networking/software/2900-AdvTrafficMgmt-Aug2006-59916197-Chap04.pdf

}}</ref>

* '''Internal Spanning-Tree Instance (IST)''': Default spanning tree instance in any MST region. All VLANs in this IST instance conform a '''single''' spanning tree [[Topology#Computer science|topology]], allowing only one forwarding path between any two nodes. It also provides the root switch for any VLAN configured switches which are not specifically assigned to a MSTI.

* '''Multiple Spanning Tree Instance (MSTI)''': Unlike IST, this kind of instance comprises all static VLANs specifically assigned to it and at least, must include one VLAN.

''While each MSTI can have multiple VLANs, each VLAN can be associated with only one MSTI.''.

=== MSTP Regions ===

[[File:MST Region.png|thumb|MSTIs in different regions.]]

A set of interconnected switches that must have configured the same VLANs and MSTIs, also have the same following parameters:

* '''MST Configuration Name'''

* '''Revision Level'''

Line 39 ⟶ 43:

We can differentiate two kinds of conformated Spanning Trees into the different networks created by MSTP, these are:

* '''Common Spanning Tree (CST):''' Administers the connectivity among MST regions, [[Spanning Tree Protocol|STP]] LANs and [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] LANs in a bridged network.

* '''Common Internal Spanning Tree (CIST):''' Identifies regions in a network and administers the CIST root bridge for the network, for each region and for each spanning tree instance in each region. It’sIt's also the default spanning tree instance of MSTP so that any VLAN which isn’tisn't a member of a particular MSTI, will be a member of the CIST. Furthermore, works as well as the spanning tree that runs between regions and between MST regions and Single Spanning Tree (SST) entities.

The role of the Common Spanning Tree (CST) in a network, and the Common and Internal Spanning Tree (CIST) configured on each device, is to prevent loops within a wider network that may span more than one [[Multiple Spanning Tree Protocol#MSTP Regions|MSTP Region]] and parts of the network running in legacy STP or RSTP mode.

=== MSTP Bridge Protocol Data Units (BPDU)BPDUs ===

{{Main articleFurther|BridgeSpanning Tree Protocol#Bridge protocol Datadata Unitunits}}

ItsThe main function of bridge protocol data units (BPDUs) is enabling MSTP to select its root bridges for the proper [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree .28CST.2FCIST.29|CIST]] and each MSTI. MSTP includes all its spanning tree information in a single [[Bridge Protocol Data Unit|BPDU]] format. Not only does reduce the number of BPDUs required on a LANs to communicate spanning tree information for each VLAN, but it also ensures backward compatibility with RSTP (and in effect, classic STP too).

BPDUs' general format comprises a common generic portion, ''-octets 1 to 36-'', that are based on those defined in [[Institute of Electrical and Electronics Engineers|IEEE]] Standard [[IEEE 802.1D|802.1D]], 2004,<ref>{{cite book|last = IEEE|first = Standard|title = IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges|publisher = IEEE Computer Society |year = 2004 |url = http://www.ccna-powertraining.de/wp-content/uploads/2014/10/802.1D-2004.pdf}}</ref> followed by components that are specific to CIST, octets 37 to 102. Components specific to each MSTI are added to this BPDUs data block.<ref>[https://www.alliedtelesis.com/sites/default/files/stp_feature_config_guide.pdf BPDU table info]</ref>

|year = 2004|url = http://www.ccna-powertraining.de/wp-content/uploads/2014/10/802.1D-2004.pdf}}</ref> followed by components that are specific to [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree .28CST.2FCIST.29|CIST]] ''-octets 37 to 102.'' Components specific to each [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTI]] are added to this BPDUs data block.

[https://www.alliedtelesis.com/sites/default/files/stp_feature_config_guide.pdf BPDU table info] and [[Spanning Tree Protocol#Bridge Protocol Data Unit fields|STP BPDUs]] ''' show a deeper resume of the MSTP BPDU format''' and, besides, some additional information about how was this object structured in older or different versions of this protocol as STP and RSTP, maintaining its compatibility.

=== MSTP Configuration Identification ===

In case there is an allocation of [[IEEE 802.1Q#Double tagging|VIDs (VLAN IDs)]] into a MST Region which differs within the different bridges that compound it, '''frames for some VIDs might be duplicated or even not delivered to some LANs at all'''. To avoid this, MST Bridges check that they are allocating VIDs to the same [[spanning tree]]strees as their neighboring MST Bridges in the same Region by transmitting and receiving MST Configuration Identifiers along with the spanning tree information. These MST Configuration Identifiers, while compact, '''are designed so that two matching identifiers have a very high probability of denoting the same configuration even in the absence of any supporting management practice for identifier allocation.''' Either one of this “objects”"objects" contains the following:

* '''Configuration Identifier Format Selector:''' Indicates the use which is going to be given to the following components.

* '''Configuration Name'''<ref>{{cite book

Line 60 ⟶ 61:

|publisher = IETF, D. Harrington

|year = 1998

|doi = 10.17487/RFC2271

|url = https://tools.ietf.org/html/rfc2271

}}</ref><ref>{{cite book

Line 67 ⟶ 69:

|publisher = IETF, D. Harrington

|year = 1999

|doi = 10.17487/RFC2571

|url = https://tools.ietf.org/html/rfc2571

}}</ref><ref>{{cite book

Line 74 ⟶ 77:

|publisher = IETF, D. Harrington

|year = 2002

|doi = 10.17487/RFC3411

|url = https://tools.ietf.org/html/rfc3411

}}</ref>

Line 82 ⟶ 86:

|publisher = IETF, H. Krawczyk

|year = 1997

|doi = 10.17487/RFC2104

|url = https://tools.ietf.org/html/rfc2104

}}</ref><ref>{{cite book

Line 89 ⟶ 94:

|publisher = IETF, S. Turner

|year = 2011

|doi = 10.17487/RFC2104

|url = https://tools.ietf.org/html/rfc2104

}}</ref> A 16B signature [[Hash-based message authentication code|HMAC]]-[[MD5|MD5 Algorithms]] created from the MST Configuration Table.<br />

This object is specific and unique of MSTP, neither STP or RSTP use it.

== Protocol Operation ==

MSTP configures for every VLAN a single spanning tree active topology in a manner that there’sthere's at least one data route between any two end stations, eliminating data loops. It specifies various “objects”"objects" allowing out the algorithm to operate in a proper way. The different bridges in the various VLANs start advertising their own configuration to other bridges using the MST Configuration Identifier in order to allocate frames with given VIDs (VLAN ID) to any of the different MSTI. A priority vector is utilized to construct the CIST, it connects all the bridges and LANs in a Bridged LAN and ensures that paths within each region are always preferred to paths outside the Region. Besides, there is a MSTI priority vector, this one compromises the necessary information to build up a deterministic and independently manageable active topology for any given MSTI within each region.

Additionally, comparisons and calculations done by each bridge select a CIST priority vector for each [[Port (computer networking)|Port]] (based on priority vectors, MST Configuration Identifiers and on an incremental Path Cost associated to each receiving port). This leads to one bridge been selected as the CIST Root of the Bridged LAN; then, a minimum cost path to the root is shifted out for each Bridge and LANs (thus preventing loops and ensuring full connectivity between VLANs). Subsequently, in each region, the bridge whose minimum cost path to the root doesn’tdoesn't pass through another bridge with the same MST Conf.ID will be identified as its Region’sRegion's CIST Regional Root. Conversely, each Bridge whose minimum cost path to the Root is through a Bridge using the same MST Configuration Identifier is identified as being in the same MST Region as that Bridge.

In summary, MSTP encodes some additional information in its BPDU regarding region information and configuration, each of these messages conveys the spanning tree information for each instance. Each instance can be assigned several configured VLANs, frames (packets) assigned to these VLANs operate in this spanning tree instance whenever they are inside the MST region. To avoid conveying their entire VLAN to spanning tree mapping in each BPDU, bridges encode an MD5 digest of their VLAN to instance table in the MSTP BPDU. This digest is then used by other MSTP bridges, along with other administratively configured values, to determine if the neighboring bridge is in the same MST region as itself.

Line 114 ⟶ 120:

== RSTP compatibility ==

MSTP is designed to be [[Spanning Tree Protocol|STP]] and [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] compatible and interoperable without additional operational management practice, this is due to a set of measurements based on [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] (Clause 17 of [[Institute of Electrical and Electronics Engineers|IEEE]] Std [[IEEE 802.1D|802.1D]], 2004 Edition) intending to provide the capability for frames assigned to different VLANs, to be transmitted along different paths within MST Regions.<br />

Both protocols have in common various issues such as: the selection of the [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree .28CST.2FCIST.29|CIST]] Root Bridge (it uses the same fundamental algorithm, 17.3.1 of [[Institute of Electrical and Electronics Engineers|IEEE]] Std [[IEEE 802.1D|802.1D]], 2004 Edition, but with extended priority vector components within MST Regions), the selection of the [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTI]] Root Bridge and computation of [[Port (computer networking)|Port]] roles for each [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTI]], the [[Port (computer networking)|Port]] roles used by the [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree .28CST.2FCIST.29|CIST]] are the same as those of [[Spanning Tree Protocol|STP]] and [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] (with the exception of the Master Port), and the state variables associated with each port. <br />

Into the bargain, they also share some problems as, for instance: MSTP can’t protect against temporary loops caused by the inter-connection of two LANs segments by devices other than the Bridges that operate invisibly with respect to support of the Bridges’ [[MAC address|MAC]] Internal Sublayer Service.

Both protocols have in common various issues such as: the selection of the [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree .28CST.2FCIST.29|CIST]] Root Bridge (it uses the same fundamental algorithm, 17.3.1 of [[Institute of Electrical and Electronics Engineers|IEEE]] Std [[IEEE 802.1D|802.1D]], 2004 Edition, but with extended priority vector components within MST Regions), the selection of the [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTI]] Root Bridge and computation of [[Port (computer networking)|Port]]port roles for each [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTI]], the [[Port (computer networking)|Port]]port roles used by the [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree .28CST.2FCIST.29|CIST]] are the same as those of [[Spanning Tree Protocol|STP]] and [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] (with the exception of the Master Port), and the state variables associated with each port. <br />

For all the above, it can be concluded that MSTP is fully compatible with [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] bridges, an MSTP [[Bridge Protocol Data Unit|BPDU]] can be interpreted by an [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] bridge as an [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] [[Bridge Protocol Data Unit|BPDU]]. This not only allows compatibility with [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] bridges without configuration changes, but also causes any [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] bridges outside of an [[Multiple Spanning Tree Protocol#MSTP Regions|MSTP Region]] to see the region as a single [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] bridge, regardless of the number of MSTP bridges inside the region itself.

Into the bargain, they also share some problems as, for instance: MSTP can’tcan't protect against temporary loops caused by the inter-connection of two LANs segments by devices other than the Bridges that operate invisibly with respect to support of the Bridges’Bridges' [[MAC address|MAC]] Internal Sublayer Service.

== Protocol Configuration ==

This section is mainly oriented to provide any user a proper manner of configuring a MSTP network over [[Cisco Systems|Cisco]] devices.

For all the above, it can be concluded that MSTP is fully compatible with [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] bridges, an MSTP [[Bridge Protocol Data Unit|BPDU]] can be interpreted by an [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] bridge as an [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] [[Bridge Protocol Data Unit|BPDU]]. This not only allows compatibility with [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] bridges without configuration changes, but also causes any [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] bridges outside of an [[Multiple Spanning Tree Protocol#MSTP Regions|MSTP Region]] to see the region as a single [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] bridge, regardless of the number of MSTP bridges inside the region itself.

=== Before Configuring MSTP ===

Be sure of having configured VLANs and having associated them with switch ports, afterwards determine: [[Multiple Spanning Tree Protocol#MSTP Regions|MSTP Regions]], revision level and instances; which VLANs and switch [[Port (computer networking)|Ports]] will belong to which [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTIs]] and, finally, which devices do you want to be root bridges for each [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTI]].

== Protocol Configurationconfiguration ==

This section is mainly oriented to provide any user a proper manner of configuring a MSTP network over [[Cisco Systems|Cisco]] devices.

=== Before Configuringconfiguring MSTP ===

Be sure of having configured VLANs and having associated them with switch ports, afterwards determine: [[Multiple Spanning Tree Protocol#MSTP Regions|MSTP Regions]], revision level and instances; which VLANs and switch [[Port (computer networking)|Ports]]ports will belong to which [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTIs]] and, finally, which devices do you want to be root bridges for each [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTI]].

=== Configuration guidelines for MSTP ===

[[File:MSTP config.png|thumb|Simple network topology for MSTP trials.]]

# Switches must have the same MST configuration identification elements (region name, revision level and VLAN to [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTI]] mapping) to be in the same MST region. When configuring multiple MST regions for MSTP, [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTIs]] are locally significant within an MST region. [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTIs]] will not span from one region to another region.

# Common and Internal Spanning Tree (CIST) is the default spanning tree instance for MSTP. This means that all VLANs that are not explicitly configured into another [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTI]] are members of the [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree .28CST.2FCIST.29|CIST]].

# The software supports a single instance of the MSTP Algorithm consisting of the [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree .28CST.2FCIST.29|CIST]] and up to 15 [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTIs]].

A VLAN can only be mapped to one [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTI]] or to the [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree .28CST.2FCIST.29|CIST]]. One VLAN mapped to multiple spanning trees is not allowed. All the VLANs are mapped to the [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree .28CST.2FCIST.29|CIST]] by default. Once a VLAN is mapped to a specified [[Multiple Spanning Tree Protocol#Multiple Spanning Tree Instances .28MSTI.29|MSTI]], it is removed from the [[Multiple Spanning Tree Protocol#Common and Internal Spanning Tree .28CST.2FCIST.29|CIST]].To avoid unnecessary [[Spanning Tree Protocol|STP]] processing, a [[Port (computer networking)|Port]]port that is attached to a LAN with no other bridges/switches attached, can be configured as an edge port.

An example of how to configure a simple, three switch SMTPMSTP topology wherein a layer-two access switch carries four VLANs and has two uplinks to two distribution switches, can be found here: [http://packetlife.net/blog/2010/apr/26/multiple-spanning-tree-mst/ MSTP Configuration Guide]<br />

A good configuration view, from the abovedabove-mentioned example shall be:

S3# '''show spanning-tree mst'''

Line 170 ⟶ 178:

}}</ref> AMSTP is a simplified one tree instance rooted at each edge bridge in the core to forward frames.

==== Protocol Operationoperation ====

To set up these trees, AMSTP relies in one basic tree which will be used to obtain instances (named Alternate Multiple Spanning Tree Instances – AMSTI), until one of them is built per switch for the network. The process applied to build up the main/basic tree is the same as in [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]]. In summary, firstly a bridge must be elected as the Root Bridge (this is done by the emission of [[Bridge Protocol Data Unit|BPDUs]] from each switch on the network periodically, every “Hello"Hello Time”Time", and selecting the lowest Bridge ID). Then, every switch will compute and calculate its cost to the Root Bridge and, afterwards, the root [[Port (computer networking)|Ports]]ports must be elected by selecting the one which receives the best [[Bridge Protocol Data Unit|BPDU]], this is, the one that announces minimum path cost to root bridge.

==== BPDUs ====

AMSTP [[Bridge Protocol Data Unit|BPDUs]] use the same local multicast protocol addresses than [[Spanning Tree Protocol|STP]] and have a structure that resembles MSTP [[Bridge Protocol Data Unit|BPDUs]] since both are comprised essentially of a basic [[Bridge Protocol Data Unit|BPDU]] and several AM-Records, allowing full-backwards compatibility with [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] and [[Spanning Tree Protocol|STP]] standard protocols. Each of the AM-Records contains the data used to negotiate a specific tree instance (AMSTI). Every ABridge, except for the elected root bridge, creates an AM-Record for its own spanning tree instances. They are used by connected [[Port (computer networking)|Ports]]ports of neighboring switches to negotiate the transitions of each tree instance with a proposal/agreement mechanism.

{{Main article|Bridge Protocol Data Unit}}

AMSTP [[Bridge Protocol Data Unit|BPDUs]] use the same local multicast protocol addresses than [[Spanning Tree Protocol|STP]] and have a structure that resembles MSTP [[Bridge Protocol Data Unit|BPDUs]] since both are comprised essentially of a basic [[Bridge Protocol Data Unit|BPDU]] and several AM-Records, allowing full-backwards compatibility with [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] and [[Spanning Tree Protocol|STP]] standard protocols. Each of the AM-Records contains the data used to negotiate a specific tree instance (AMSTI). Every ABridge, except for the elected root bridge, creates an AM-Record for its own spanning tree instances. They are used by connected [[Port (computer networking)|Ports]] of neighboring switches to negotiate the transitions of each tree instance with a proposal/agreement mechanism.

=== ABRIDGES ===

Line 182 ⟶ 189:

|first = Guillermo, Alberto, Arturo, Ignacio

|title = Alternative Multiple Spanning Tree Protocol (AMSTP) for Optical Ethernet Backbones

|publisher = Departamento de Ingeniería Telemática, Universidad Carlos III, Madrid, Spain, CAPITAL MEC Project

|year = 2007

|url = https://e-archivo.uc3m.es/bitstream/handle/10016/2954/COMPNW_3675_08.pdf?sequence=2&isAllowed=y

}}</ref> emphasizes in the terms of efficiency in network usage and path length. That’sThat's the main cause why it uses AMSTP, a simplified and self-configuring version of MSTP protocol.<br />

Abridges can be described as a two-tiered hierarchy of layer-two switches in which network islands running independent rapid spanning tree protocols communicate through a core formed by island root bridges (ABridges). As it has been mentioned, it is focused in terms of efficiency, this is due to the ability of AMSTP to provide optimum paths in the core mesh and the usage of [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] to aggregate efficiently the traffic at islands networks. Its convergence speed is as fast as [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]] and MSTP.

==== Architecture ====

[[File:Architecture ABridges.png|thumb|Two-layer network proposal for ABridges.]]

With the objective of enhancing the properties of Abridges protocol, a two-level hierarchical [[link layer]] infrastructure in which segmentation is performed at [[link layer]] is proposed. The core will be composed, primarily, by Abridges (Bridges using an implementation of AMSTP) and will oversee connecting the leaf access networks that are referred to as “access"access layer”layer". Besides, each of this access networks, also called islands, will be a layer-two sub-network using [[Spanning Tree Protocol|STP]] connected to one or more Abridges.

==== Protocol Operationoperation ====

Inside every island or access network a bridge is automatically elected to behave as the Root Bridge, this one bridge will behave as a gateway, allowing the forwarding of frames from the core to an island and conversely. Just one Abridge is going to perform these gateway functions, although many could be connected. Communication among [[IEEE 802.1D|802.1D]] bridges and between standard [[IEEE 802.1D|802.1D]] bridges and ABridges does not require point-to-point connections.<br />

The ABridge receiving an [[Address Resolution Protocol|ARP]] frame from an island host obtains the island in which the destination is located by asking an [[Address Resolution Protocol|ARP]] server where the host was previously registered by its island ABridge. This server stores the IP to [[MAC address|MAC]] mapping and the island ABridge ID. The [[Address Resolution Protocol|ARP]] servers distribute its load based on equal result of short hashing of the IP addresses served. The core self-configures and the operation is transparent to all hosts and standard switches at islands.

==== Protocol Operation ====

Inside every island or access network a bridge is automatically elected to behave as the Root Bridge, this one bridge will behave as a gateway, allowing the forwarding of frames from the core to an island and conversely. Just one Abridge is going to perform these gateway functions, although many could be connected. Communication among [[IEEE 802.1D|802.1D]] bridges and between standard [[IEEE 802.1D|802.1D]] bridges and ABridges does not require point-to-point connections.<br />

The ABridge receiving an [[Address Resolution Protocol|ARP]] frame from an island host obtains the island in which the destination is located by asking an [[Address Resolution Protocol|ARP]] server where the host was previously registered by its island ABridge. This server stores the IP to [[MAC address|MAC]] mapping and the island ABridge ID. The [[Address Resolution Protocol|ARP]] servers distribute its load based on equal result of short hashing of the IP addresses served. The core self-configures and the operation is transparent to all hosts and standard switches at islands.

==== ABridges functionality ====

ABridges is composed by three basic functional modules, which could be resumed in:

* '''STD Bridge:''' Performs standard bridging functions with the nodes of its island. The access functionality resides on the access [[Port (computer networking)|Ports]]ports of this module, which has an equivalent behavior to a standard bridge acting as a root bridge.

* '''AMSTP Routing:''' Routes frames between Abridges and the Gateway. It has core ports, either of them interconnect ABridges, which learn root bridge IDs from the AMSTP [[Bridge Protocol Data Unit|BPDUs]] received and store this information in a database, known as “Forwarding"Forwarding Database”Database".

* '''GateWay:''' Interconnects the above-mentioned modules.

Abridges will configure each of their [[Port (computer networking)|Ports]]ports to be part either of the core or of an island, this port self-configuration is done with very simple stipulations: if a port is not connected to another Abridge using a point-to-point link, it will turn itself an access port; on the other hand, [[Port (computer networking)|Ports]]ports directly connected to another Abridge are configured as core ports. This auto-configuration mechanism is pretty like the one used in [[Spanning Tree Protocol#Rapid Spanning Tree Protocol|RSTP]].

==== ARP and ABridge Resolutionresolution ====

As any layer-two based protocol, ABridges uses [[Address Resolution Protocol|ARP]] broadcasts to obtain the [[link layer]] address associated to an IP address at the same LAN or VLAN. That is the main cause why avoiding overflooding is a matter of paramount priority; to limit this broadcast traffic, is recommended the use of distributed load [[Address Resolution Protocol|ARP]] servers, although its use is not compulsory.

==See also==

* [[Spanning Tree Protocol]]

* [[Bridge Protocol Data Unit]]

* [[Distributed minimum spanning tree]]

* [[EtherChannel]]

Line 215 ⟶ 221:

* [[Media Redundancy Protocol]]

* [[Minimum spanning tree]]

* [[TRILL (computing)|TRILL]] (Transparent Interconnection of Lots of Links)

* [[Unidirectional Link Detection]]

* [[Virtual Link Trunking]]

Line 224 ⟶ 230:

== External links ==

{{commons category|MSTPMultiple Spanning Tree Protocol}}

* [httphttps://standards1.ieeeieee802.org/about/get/802/802.1.html IEEE "Home Page" for 802.1] (Related Standards of the 802.1 family)

* [httphttps://blog.ine.com/2008blog/2008-07/-27/-mstp-tutorial-part-i-inside-a-region/ MSTP Tutorial] (Brief Tutorial for the comprehension of SMTPMSTP)

* [http://www.postel.org/pipermail/rbridge/ RBridge]

* Cisco Implementations

** [https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24248-147.html] (Cisco Implementation and brief tutorial about SMTPMSTP)

** [http://www.cisco.com/en/US/tech/tk389/tk621/tsd_technology_support_protocol_home.html Cisco home page for the Spanning-Tree protocol family] (discusses CST, MISTP, PVST, PVST+, RSTP, STP)

** [http://www.cisco.com/image/gif/paws/10556/spanning_tree1.swf Educational explanation of STP] www.cisco.com

Line 239 ⟶ 245:

| publisher = [[University of California at Berkeley]]

| accessdate = 2011-09-01

| archiveurl = httphttps://web.archive.org/web/20110719212324/http://www.csua.berkeley.edu/~ranga/humor/algorhyme.txt

| archivedate = 2011-07-19

}}

* IEEE Standards

** [https://web.archive.org/web/20051210051119/http://standards.ieee.org/getieee802/download/802.1D-2004.pdf ANSI/IEEE 802.1D-2004 standard], section 17 discusses RSTP (Regular STP is no longer a part of this standard. This is pointed out in section 8.)

** [https://web.archive.org/web/20070913195704/http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf ANSI/IEEE 802.1Q-2005 standard], section 13 discusses MSTP

* RFCs

** RFC 2271-1998, - An Architecture for Describing SNMP Management Frameworks