Content deleted Content added
m -duplinks |
m -duplinks |
||
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
* '''Configuration Identifier Format Selector:''' Indicates the use which is going to be given to the following components.
* '''Configuration Name'''<ref>{{cite book
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
Both protocols have in common various issues such as: the selection of the
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
== Protocol
This section is mainly oriented to provide any user a proper manner of configuring a MSTP network over [[Cisco Systems|Cisco]] devices.
=== Before
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
=== 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
# 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
# The software supports a single instance of the MSTP Algorithm consisting of the
A VLAN can only be mapped to one
An example of how to configure a simple, three switch SMTP 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 />
Line 171:
==== 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
==== BPDUs ====
{{Main article|Bridge Protocol Data Unit}}
AMSTP [[Bridge Protocol Data Unit|BPDUs]] use the same local multicast protocol addresses than
=== ABRIDGES ===
Line 186:
|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’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
==== 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
==== 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
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.
Line 201:
* '''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]] 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]] directly connected to another Abridge are configured as core ports. This auto-configuration mechanism is pretty like the one used in
==== ARP and ABridge Resolution ====
| |||