Content deleted Content added
No edit summary |
m rm already linked |
||
| (48 intermediate revisions by 27 users not shown) | |||
Line 1:
{{Short description|Network protocol that builds a loop-free logical topology for Ethernet networks}}
{{IPstack}}
{{commons category|
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 Instances (MSTI)|Multiple Spanning Tree instance]] (MSTI) and in the [[#Common and Internal Spanning Tree (CST/CIST)|common and internal spanning tree]] (CIST), 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 [[switching loop]] 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 networks (LANs) and MST bridges. These regions and the other bridges and LANs are connected into a single common spanning tree (CST).
== History and motivation ==
It was originally defined in [[IEEE]] 802.1s as an amendment to [[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 [[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 ==
=== 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
Each instance defines a single forwarding topology for an exclusive set of
|last = packard
|first = Hewlett
|title = Multiple Instance Spanning-Tree Operation
|year = 2006
|url =
}}</ref>
* '''Internal Spanning-Tree Instance (IST)''': Default spanning tree instance in any MST region. All
* '''Multiple Spanning Tree Instance (MSTI)''': Unlike IST, this kind of instance comprises all static
''While each MSTI can have multiple
=== MSTP Regions ===
[[File:MST Region.png|thumb|MSTIs in different regions.]]
A set of interconnected switches that must have configured the same
* '''MST Configuration Name'''
* '''Revision Level'''
* '''Configuration Digest:''' Mapping of which
An
=== Common and Internal Spanning Tree (CST/CIST) ===
[[File:CIST.png|thumb|CIST operates links between regions and to SST devices.]]
We can
* '''Common Spanning Tree (CST):''' Administers the connectivity among MST regions,
* '''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.
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 [[
=== MSTP BPDUs ===
{{Further|Spanning Tree Protocol#Bridge protocol data units}}
The main function of bridge protocol data units (BPDUs) is enabling MSTP to select its root bridges for the proper CIST and each MSTI. MSTP includes all its spanning tree information in a single 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 IEEE Standard [[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>
=== MSTP Configuration Identification ===
In case there is an allocation of [[
* '''Configuration Identifier Format Selector:''' Indicates the use which is going to be given to the following components.
* '''Configuration Name'''<ref>{{cite book
Line 59 ⟶ 61:
|publisher = IETF, D. Harrington
|year = 1998
|doi = 10.17487/RFC2271
|url = https://tools.ietf.org/html/rfc2271
}}</ref>
|last = IETF
|first = RFC
Line 66 ⟶ 69:
|publisher = IETF, D. Harrington
|year = 1999
|doi = 10.17487/RFC2571
|url = https://tools.ietf.org/html/rfc2571
}}</ref>
|last = IETF
|first = RFC
Line 73 ⟶ 77:
|publisher = IETF, D. Harrington
|year = 2002
|doi = 10.17487/RFC3411
|url = https://tools.ietf.org/html/rfc3411
}}</ref>
Line 81 ⟶ 86:
|publisher = IETF, H. Krawczyk
|year = 1997
|doi = 10.17487/RFC2104
|url = https://tools.ietf.org/html/rfc2104
}}</ref>
|last = IETF
|first = RFC
Line 88 ⟶ 94:
|publisher = IETF, S. Turner
|year = 2011
|doi = 10.17487/RFC2104
|url = https://tools.ietf.org/html/rfc2104
}}</ref> A 16B signature [[
This object is specific and unique of MSTP, neither
== Protocol Operation ==
MSTP configures for every
Additionally, comparisons and calculations done by each bridge select a
In summary, MSTP encodes some additional information in its
== Port Roles ==
=== Common Internal Spanning Tree Ports ===
* '''Root:''' Provides the minimum cost path from the Bridge to the [[
* '''Designated:''' Provides the least cost path from the attached
* '''Alternate or Backup:''' Provides connectivity if other Bridges, Bridges [[Port (computer networking)|Ports]] or
=== Multiple Spanning Tree Instance Ports ===
* '''Root:''' Provides the minimum cost path from the Bridge to the
* '''Designated:''' Provides the least cost path from the attached
* '''Master:''' Provides connectivity from
* '''Alternate or Backup:''' Provides connectivity if other Bridges, Bridges
== RSTP compatibility ==
MSTP is designed to be
Both protocols have in common various issues such as: the selection of the CIST Root Bridge (it uses the same fundamental algorithm, 17.3.1 of IEEE Std 802.1D, 2004 Edition, but with extended priority vector components within MST Regions), the selection of the MSTI Root Bridge and computation of port roles for each MSTI, the port roles used by the CIST are the same as those of STP and RSTP (with the exception of the Master Port), and the state variables associated with each port.
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.
For all the above, it can be concluded that MSTP is fully compatible with RSTP bridges, an MSTP BPDU can be interpreted by an RSTP bridge as an RSTP BPDU. This not only allows compatibility with RSTP bridges without configuration changes, but also causes any RSTP bridges outside of an MSTP Region to see the region as a single RSTP bridge, regardless of the number of MSTP bridges inside the region itself.
== Protocol configuration ==
This section is mainly oriented to provide any user a proper manner of configuring a MSTP network over Cisco devices.
=== Before configuring MSTP ===
Be sure of having configured VLANs and having associated them with switch ports, afterwards determine: MSTP Regions, revision level and instances; which VLANs and switch ports will belong to which MSTIs and, finally, which devices do you want to be root bridges for each MSTI.
==
[[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
# Common and Internal Spanning Tree (CIST) is the default spanning tree instance for MSTP. This means that all
# The software supports a single instance of the MSTP Algorithm consisting of the
A
An example of how to configure a simple, three switch MSTP 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 above-mentioned example shall be:
S3# '''show spanning-tree mst'''
Line 133 ⟶ 148:
Bridge address 000e.8316.f500 priority 32768 (32768 sysid 0)
Root address 0013.c412.0f00 priority 0 (0 sysid 0)
port Fa0/13 path cost 0
Regional Root address 0013.c412.0f00 priority 0 (0 sysid 0)
internal cost 200000 rem hops 19
Operational hello time 2
Configured hello time 2
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Line 149 ⟶ 164:
---------------- ---- --- --------- -------- --------------------------------
Fa0/13 Altn BLK 200000 128.13 P2p
Fa0/16 Root FWD 200000 128.16 P2p
== Extensions ==
=== Alternative Multiple Spanning Tree Protocol (AMSTP) ===
The first skel of this protocol was proposed in.<ref>{{cite book
|last = Ibáñez, García, Azcorra
|first = Guillermo, Alberto, Arturo
Line 160 ⟶ 176:
|year = 2002
|url = http://e-archivo.uc3m.es/bitstream/handle/10016/2791/amstp-2004.pdf?sequence=1
}}</ref>
==== Protocol operation ====
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 RSTP. In summary, firstly a bridge must be elected as the Root Bridge (this is done by the emission of BPDUs from each switch on the network periodically, every "Hello Time", and selecting the lowest Bridge ID). Then, every switch will compute and calculate its cost to the Root Bridge and, afterwards, the root ports must be elected by selecting the one which receives the best BPDU, this is, the one that announces minimum path cost to root bridge.
==== BPDUs ====
AMSTP BPDUs use the same local multicast protocol addresses than STP and have a structure that resembles MSTP BPDUs since both are comprised essentially of a basic BPDU and several AM-Records, allowing full-backwards compatibility with RSTP and 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 ports of neighboring switches to negotiate the transitions of each tree instance with a proposal/agreement mechanism.
=== ABRIDGES ===
This protocol, developed in
|last = Ibáñez, García, Azcorra, Soto
|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,
|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.
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
==== 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 [[
==== 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 802.1D bridges and between standard 802.1D bridges and ABridges does not require point-to-point connections.
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 ARP server where the host was previously registered by its island ABridge. This server stores the IP to MAC mapping and the island ABridge ID. The 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
* '''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
* '''GateWay:''' Interconnects the above-mentioned modules.
Abridges will configure each of their
==== ARP and ABridge resolution ====
As any layer-two based protocol, ABridges uses 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 ARP servers, although its use is not compulsory.
==See also==
* [[Distributed minimum spanning tree]]
* [[EtherChannel]]
Line 201 ⟶ 221:
* [[Media Redundancy Protocol]]
* [[Minimum spanning tree]]
* [[
* [[Unidirectional Link Detection]]
* [[Virtual Link Trunking]]
Line 209 ⟶ 229:
{{reflist}}
== External
{{commons category|
* [
* [
* [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
** [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
* {{cite web
| last = Perlman
Line 225 ⟶ 245:
| publisher = [[University of California at Berkeley]]
| accessdate = 2011-09-01
| archiveurl =
| 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
| |||