Multiple Spanning Tree Protocol: Difference between revisions

Revision as of 20:52, 26 September 2017

Revision as of 21:03, 26 September 2017

Line 44:

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

{{Main article|Bridge Protocol Data Unit}}

Its main function 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 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 [[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 [[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.

Line 113:

* '''Alternate or Backup:''' Provides connectivity if other Bridges, Bridges ports or LANs fail or are erased.

== RSTP compatibility ==<!--&&&&& temporary edit aid, please delete if left in-->

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

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.

Line 121 ⟶ 122:

== Protocol configuration ==

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

=== 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]]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 170 ⟶ 171:

}}</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 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 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 BPDU, this is, the one that announces minimum path cost to root bridge.

==== BPDUs ====

{{Main article|Bridge Protocol Data Unit}}

AMSTP [[Bridge Protocol Data Unit|BPDUs]] use the same local multicast protocol addresses than STP and have a structure that resembles MSTP [[Bridge Protocol Data Unit|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 [[Port (computer networking)|Ports]]ports of neighboring switches to negotiate the transitions of each tree instance with a proposal/agreement mechanism.

=== ABRIDGES ===

Line 190 ⟶ 191:

==== 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 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 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 802.1D bridges and between standard 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 802.1D bridges and between standard 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 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 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]]