Multiple Spanning Tree Protocol: Difference between revisions

Revision as of 21:03, 26 September 2017

Revision as of 21:08, 26 September 2017

Line 8:

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.

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’twouldn't work as efficiently as it is supposed to, even letting some errors (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.

== Main Entities ==

Line 14:

=== 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 39:

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.

Line 52:

=== 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 trees 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 94:

== 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 116:

MSTP is designed to be STP and RSTP compatible and interoperable without additional operational management practice, this is due to a set of measurements based on RSTP (Clause 17 of IEEE Std 802.1D, 2004 Edition) intending to provide the capability for frames assigned to different VLANs, to be transmitted along different paths within MST Regions.

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. <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.

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.

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 [[Multiple Spanning Tree Protocol#MSTP Regions|MSTP Region]] to see the region as a single RSTP bridge, regardless of the number of MSTP bridges inside the region itself.

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 [[Multiple Spanning Tree Protocol#MSTP Regions|MSTP Region]] to see the region as a single RSTP bridge, regardless of the number of MSTP bridges inside the region itself.

== Protocol configuration ==

Line 125 ⟶ 126:

=== 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 ports will belong to which MSTIs and, finally, which devices do you want to be root bridges for each MSTI.

=== Configuration guidelines for MSTP ===

Line 172 ⟶ 173:

==== 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"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 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 ====

Line 186 ⟶ 187:

|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 RSTP to aggregate efficiently the traffic at islands networks. Its convergence speed is as fast as 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 STP connected to one or more Abridges.

==== Protocol operation ====

Line 201 ⟶ 202:

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 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 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 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, ports directly connected to another Abridge are configured as core ports. This auto-configuration mechanism is pretty like the one used in RSTP.