3.2.4 Explaining Edge Ports
An RSTP edge port is a switch port that is never intended to be connected to another switch device. It immediately transitions to the forwarding state when enabled.
The edge port concept is well known to Cisco spanning tree users, because it corresponds to the PortFast feature in which all ports directly connected to end stations anticipate that no switch device will be connected to them. The PortFast ports immediately transition to the STP forwarding state, thereby skipping the time-consuming listening and learning stages. Neither edge ports nor PortFast-enabled ports generate topology changes when the port transitions to a disabled or enabled status.
Unlike PortFast, an edge port that receives a BPDU loses its edge port status immediately and becomes a normal spanning tree port. When a switch with an edge port receives a BPDU, it generates a TCN.
Cisco’s RSTP implementation maintains the PortFast keyword for edge port configuration, thus making an overall network transition to RSTP more seamless. Configuring an edge port to be attached to another switch can have negative implications for RSTP when it is in sync state.
3.2.5 Describing RSTP Link Types
Each port participating in RSTP is categorized with a link type. The link type can predetermine the active role that the port plays as it stands by for immediate transition to a forwarding state if certain parameters are met. These parameters are different for edge ports and non-edge ports. Non-edge ports are categorized into two link types. The link type is automatically determined but can be overwritten.
Edge ports, the equivalent of PortFast-enabled ports, and point-to-point links are candidates for rapid transition to a forwarding state. Before the link type can be considered for the purpose of expedient port transition, RSTP must determine the port role. 
and 
Root ports do not use the link type parameter. Root ports are able to make a rapid transition to the forwarding state as soon as the port is in sync. In addition, alternate and backup ports do not use the link type parameter in most cases.
Designated ports make the most use of the link type parameter. Rapid transition to the forwarding state for the designated port occurs only if the link type parameter indicates a point-to-point link.
3.2.6 Examining the RSTP BPDU
RSTP (802.1w) uses type 2, version 2 BPDUs, so an RSTP bridge can communicate with 802.1D on any shared link or with any switch running 802.1D. RSTP sends BPDUs and populates the flag byte in a slightly different manner than 802.1D:
An RSTP bridge sends a BPDU with its current information every hello time period (2 seconds by default), even if it does not receive any BPDUs from the root bridge.
Protocol information can be immediately aged on a port if hellos are not received for three consecutive hello times or if the max age timer expires.
Because BPDUs are now used as a keepalive mechanism, three consecutively missed BPDUs indicate lost connectivity between a bridge and its neighboring root or designated bridge. This fast aging of the information allows quick failure detection.
RSTP uses the flag byte of version 2 BPDU as shown in the Figure .
Bits 0 and 7 are used for TCN and acknowledgement (ACK), as they are in 802.1D.
Bits 1 and 6 are used for the proposal agreement process.
Bits 2–5 encode the role and state of the port originating the BPDU.
The Flag field in the STP BPDU packet contained a TCN and TCA. In RSTP, the Flag field, which is 1 byte long, has been modified to accommodate port designations and proposal/agreement between adjacent switches. BPDUs are sent every 2 seconds. Unlike in legacy STP, each switch generates its own BPDUs regardless if it hears BPDUs from the root. In legacy STP, BPDUs were only generated by the root and propagated throughout the spanning tree domain. As a result, when a switch did not receive a configuration BPDU, it did not know where the failure occurred. In RSTP mode, the switch needs to worry only about its immediate neighbors. Hence, BPDUs also serve as keepalive mechanisms between adjacent switches. If the switch does not hear three consecutive BPDUs from its downstream neighbor, it transitions appropriate ports to facilitate network convergence.
3.2.7 Identifying the RSTP Proposal and Agreement Process
In 802.1D, when a port has been selected by spanning tree to become a designated port, it must wait two times the forward delay before transitioning the port to a forwarding state. RSTP significantly speeds up the recalculation process after a topology change in the network, because it converges on a link-by-link basis and does not rely on timers expiring before ports can transition. Rapid transition to the forwarding state can only be achieved on edge ports and point-to-point links. In RSTP, this condition corresponds to a port with a designated role that is in a blocking state. Figure illustrates how rapid transition is achieved, as follows:
Switch A has a path to the root via switch B and switch C. A new link is then created between the root and switch A, and both ports are in designated blocking state until they receive a BPDU from their counterpart. When a designated port is in a discarding or learning state (and only in this case), it sets the proposal bit on the BPDUs it sends out. This is what happens for port P0 of the root bridge.
Switch A sees that the proposal BPDU has a superior path cost. It blocks all non-edge designated ports other than the one over which the proposal-agreement process are occurring. This operation is called sync and prevents switches below A from causing a loop during the proposal-agreement process. Edge ports do not have to be blocked and remain unchanged during sync.
Bridge A sends an agreement that allows the root bridge to put root port P0 in forwarding state. Port P1 becomes the root port for A.
After switch A and the root bridge are synchronized, the proposal or agreement process continues on switch A out of all of its downstream-designated non-edge ports, as shown in Figure :
Switch B on P5 will see that switch A is discarding and will also transition to the designated discarding state. Switch A then sends its proposal BPDU down to B with the root ID of the root bridge.
Switch B sees a proposal with the superior BPDU from A and blocks all non-edge, designated ports other than the one over which the proposal-agreement process is occurring.
Switch B sends a BPDU with the agreement bit set, and switch A P3 transitions to forwarding state. The synchronization process continues with switches downstream from B.
3.2.8 Identifying the RSTP Topology Change
In 802.1D, any port state change generates a TCN. When an 802.1D bridge detects a topology change (TC), it sends TCNs toward the root bridge. The root bridge sets the TC flag on the outbound BPDUs that are relayed to switches down from the root. When a bridge receives a BPDU with the TC flag bit set, the bridge reduces its bridge-table aging time to forward delay seconds. This ensures a relatively quick flushing of the MAC address table.
In RSTP, only non-edge ports moving to the forwarding state cause a topology change. Loss of connectivity is not considered a topology change, and a port moving to the blocking state does not generate a TC BPDU under those conditions.
When an RSTP bridge detects a TC, it performs the actions outlined in Figure .
The TCN is flooded across the entire network, one switch at a time, from the switch that is the source of the change rather than from the root bridge. The topology change propagation is now a one-step process. There is no need for each switch port to wait for the root bridge to be notified and then maintain the TC state for the value of the max age plus forward delay seconds.
If the port consistently keeps receiving BPDUs that do not correspond to the current operating mode for two periods of hello time, the port switches to the mode indicated by the BPDUs.
3.2.9 Describing Rapid PVST+ Implementation
Figure shows the most common Rapid PVST+ commands. Figure describes the commands.
3.2.10 Implementing Rapid PVST+ Commands
Figures and describe how to configure PVRST.
A variety of show commands can be used to display configuration and operation information about spanning tree. The show spanning-tree command displays information about the STP configuration. 
Without any arguments, it displays general information about all STP configurations. The complete syntax is as follows:
Switch#show spanning-tree [bridge-group | active | backbonefast | {bridge [id]}| detail | inconsistentports | {interface interface interface-number} | root | summary [total] | uplinkfast | {vlan vlan-id} | {port-channel number} | pathcost-method]
Refer to your software documentation for a complete explanation of each parameter.
3.3 Configuring PortFast
3.3.1 Explaining MSTP
The main purpose of MSTP is to reduce the total number of spanning tree instances to match the physical topology of the network and thus reduce the CPU loading of a switch. The instances of spanning tree are reduced to the number of links (that is, active paths) that are available. If the example in Figure was implemented via PVST+, there could potentially be 4094 instances of spanning tree, each with its own BPDU conversations, root bridge election, and path selections.
In this example, the goal is to achieve load distribution with VLANs 1 through 500 using one path, and with VLANs 501 through 1000 using the other path, with only two instances of spanning tree. The two ranges of VLANs are mapped to two MSTP instances. Rather than maintaining 1000 spanning trees, each switch needs to maintain only two. Implemented in this fashion, MSTP converges faster than PVST+ and is backward compatible with 802.1D STP, 802.1w RSTP, and the Cisco PVST+ architecture. MSTP is not required if the Enterprise Composite Network Model is employed, because the number of active VLAN instances, and hence the STP instances, would be small and very stable.
MSTP allows you to build multiple spanning trees over trunks by grouping VLANs and associating them with spanning tree instances. Each instance can have a topology independent of other spanning tree instances. This architecture provides multiple active forwarding paths for data traffic and enables load balancing. Network fault tolerance is improved over Common Spanning Tree (CST) because a failure in one instance (forwarding path) does not necessarily affect other instances. This VLAN-to-MSTP grouping must be consistent across all bridges within an MSTP region.
In large networks, you can administer the network more easily and use redundant paths by locating different VLAN and spanning tree assignments in different parts of the network. A spanning tree instance can exist only on bridges that have compatible VLAN instance assignments.
You must configure a set of bridges with the same MSTP configuration information, which allows them to participate in a specific set of spanning tree instances. Interconnected bridges that have the same MSTP configuration form what is called an MSTP region. Bridges with different MSTP configurations or legacy bridges running 802.1D form separate MSTP regions.
In a Cisco PVST+ environment, the spanning tree parameters are tuned so that half of the VLANs are forwarding on each uplink trunk. This is easily achieved by electing bridge D1 to be the root for VLAN1-500, and bridge D2 to be the root for VLAN501-1000. In this configuration, the following is true:
Optimum load balancing is achieved.
One spanning tree instance is created per 500 VLANs, which means 1000 VLANs are mapped to only two different logical topologies (or instances). This saves resources on all the switches in the network.
Note:
The MST implementation in Cisco IOS Release 12.2(25)SEC is based on the IEEE 802.1s standard. The MST implementations in earlier Cisco IOS releases are pre-standard. Additional commands are needed for the standard and pre-standard implementations to work together, which are discussed later in this lesson.
3.3.2 Describing MST Regions
MSTP differs from other spanning tree implementations in that it combines some, but not necessarily all, VLANs into logical spanning tree instances. This raises the problem of determining which VLAN to associate with which instance, which involves tagging BPDUs so that receiving devices can identify the instances and the VLANs to which they apply.
This issue is irrelevant with the 802.1D standard, in which all instances are mapped to a unique and common instance, CST. In the PVST+ implementation, different VLANs carry the BPDUs for their respective instances (one BPDU per VLAN), based on the VLAN tagging information.
To provide this logical assignment of VLANs to spanning trees, each switch running MSTP in the network has a single MSTP configuration that consists of three attributes:
An alphanumeric configuration name (32 bytes)
A configuration revision number (two bytes)
A 4096-element table that associates each of the potential 4096 VLANs supported on the chassis with a given instance
To be part of a common MSTP region, a group of switches must share the same configuration attributes. It is up to the network administrator to properly propagate the configuration throughout the region.
Currently, this step is only possible by using the command-line interface (CLI) or Simple Network Management Protocol (SNMP). Other methods can be implemented in the future because the IEEE specification does not explicitly mention how to accomplish this step.
To ensure a consistent VLAN-to-instance mapping, it is necessary for the protocol to be able to exactly identify the boundaries of the regions. For that purpose, the characteristics of the region are included in BPDUs. The exact VLAN-to-instance mapping is not propagated in the BPDU, because the switches only need to know whether they are in the same region as a neighbor.
Therefore, only a digest of the VLANs-to-instance mapping table is sent, along with the revision number and the name. Once a switch receives a BPDU, it extracts the digest (a numerical value derived from the VLAN-to-instance mapping table through a mathematical function) and compares it with its own computed digest. If the digests differ, the mapping must be different, so the port on which the BPDU was received is at the boundary of a region.
A port is at the boundary of a region if the designated bridge on its segment is in a different region or if it receives legacy 802.1D BPDUs. In Figure , the port on B1 is at the boundary of region A, whereas the ports on B2 and B3 are internal to region B.
3.3.3 Describing the Extended System ID
As with PVST, the 12-bit Extended System ID field is used in MSTP. In MSTP, this field carries the MSTP instance number.
The 802.1D protocol states that each bridge must have a unique bridge identifier. In PVST, each VLAN is considered a different logical bridge. Therefore, each VLAN needs a unique bridge ID. Prior to supporting 4000 VLANs, Cisco supported a maximum of 1024 VLANs, which required 1024 bridge IDs.
MAC address reduction is a feature that ensures bridge ID uniqueness for all 4000 VLANs, even when there are only 1024 or 64 MAC addresses available on the switch. It accomplishes this uniqueness by making the 16-bit Bridge Priority field in the BPDU unique for each VLAN. Prior to this feature, the Bridge Priority field was fully configurable and did not have to be unique, because the appending 48-bit MAC address was unique for each VLAN.
MAC address reduction splits the 16-bit field into two fields: a configurable 4-bit field and a nonconfigurable 12-bit field. The 12-bit field carries the VLAN ID (VID) or, with MSTP, the MSTP instance number. The two fields are merged to create the unique Bridge Priority field for a particular VLAN or MSTP instance. The appending MAC address remains the same for all instances.
3.3.4 Interacting Between MST Regions and 802.1D Networks
One issue that arises from MSTP design is interoperability with the CST implementation in 802.1D. According to the IEEE 802.1s specification, an MSTP switch must be able to handle at least one internal spanning tree (IST). The MSTP region consists of one IST and an arbitrary number of MSTP instances.
Figure shows two functionally equivalent diagrams. Notice the location of the different blocked ports. In a typical bridged network, you expect to see a blocked port between switches M and B. Instead of blocking on switch D, you expect to have the second loop broken by a blocked port somewhere in the middle of the MSTP region. However, due to the IST, the entire region appears as one virtual bridge that runs a single spanning tree (CST). This approach makes it possible to understand that the virtual bridge blocks an alternate port on switch B and that the virtual bridge causes Switch D to block its port connecting to switch C.
The MSTP instances are simple RSTP instances that exist only inside a region. The MSTP instances run RSTP automatically by default, without any extra configuration. Unlike IST instances, MSTP instances never interact with devices outside the region. (MSTP runs only one spanning tree outside the region.) Therefore, except for the IST instance, regular instances inside the region have no outside counterpart. Additionally, MSTP instances do not send BPDUs outside a region, only the IST does.
MSTP instances do not send independent individual BPDUs. Inside the MSTP region, bridges exchange MSTP BPDUs that can be seen as normal RSTP BPDUs for the IST while containing additional information for each MSTP instance.
The IST (instance 0) runs on all bridges within an MSTP region. An important characteristic of the IST is that it provides interaction at the boundary of the MSTP region with other MSTP regions. More importantly, it is responsible for providing compatibility between the MSTP regions and the spanning tree of 802.1D (CST) and PVST+ networks connected to the region.
The IST receives and sends BPDUs to the CST for compatibility with 802.1D. The IST is capable of representing the entire MSTP region as a CST virtual bridge to switched networks outside the MSTP region.
The following highlights key characteristics of MSTP interaction with a CST or PVST environment:
The MSTP region appears as a single virtual bridge to the adjacent CST and MSTP regions. The MSTP region uses RSTP port roles and operation.
MSTP switches run IST, which augments CST information with internal information about the MSTP region.
IST connects all the MSTP switches in the region and any CST switched domains.
MSTP establishes and maintains additional spanning trees within each MSTP region. These spanning trees are termed MSTP instances. The IST is numbered 0, and the MSTP instances are numbered 1, 2, 3, and so on, up to 15. Any MSTP instance is local to the MSTP region and is independent of MSTP instances in another region, even if the MSTP regions are interconnected.
The M-Record is a subfield within the BPDU of MSTP instances that contains enough information (root bridge and sender bridge priority parameters) for the corresponding instance to calculate the final topology. It does not contain any timer-related parameters (such as hello time, forward delay, and max age) that are typically found in a regular IEEE 802.1D BPDU, because these timers are derived from the IST BPDU timers. Within an MSTP region, all spanning tree instances use the same parameters as the IST.
MSTP instances combine with the IST at the boundary of the MSTP region to become the CST by encapsulating M-records within MSTP BPDUs. The original spanning trees are called M-trees, which are active only within the MSTP region. M-trees merge with the IST at the boundary of the MSTP region and form the CST.
MSTP supports the following PVST extensions:
PortFast
BPDU filter and BPDU guard
Loop guard and root guard
3.3.5 How to configure PortFast
All switches are configured with the spanning tree MSTP and extend system-id syntax. However, only the distribution switches that serve as root devices have their priority changed. The steps for configuring MST are shown in Figure .
Note:
The MST implementation in Cisco IOS Release 12.2(25)SEC is based on the IEEE 802.1s standard. The MST implementations in earlier Cisco IOS releases are pre-standard.
3.3.6 Configuring and Verifying MSTP
Use the show spanning-tree mst command to display MSTP information.
Figure shows an example of how to display MSTP configuration information, which includes the MSTP region name, revision number, and VLAN-to-MSTP instances mapping.
The next example shows how to display general MSTP information. Notice that the output below is grouped by MSTP instances, starting with the IST.
Switch#show spanning-tree mst
###### MST00 vlans mapped: 11-4094
Bridge address 00d0.00b8.1400 priority 32768 (32768 sysid 0)
Root address 00d0.004a.3c1c priority 32768 (32768 sysid 0)
port Fa4/48 path cost 203100
IST master this switch
Operational hello time 2, forward delay 15, max age 20, max hops 20
Configured hello time 2, forward delay 15, max age 20, max hops 20
Interface Role Sts Cost Prio.Nbr Status
---------------- ---- --- --------- -------- ------------------------
Fa4/4 Back BLK 1000 240.196 Point-to-point
Fa4/5 Desg FWD 200000 128.197 Point-to-point
Fa4/48 Root FWD 200000 128.240 Point-to-point Bound(STP)
###### MST01 vlans mapped: 1-10
Bridge address 00d0.00b8.1400 priority 32769 (32768 sysid 1)
Root this switch for MST01
Interface Role Sts Cost Prio.Nbr Status
Fa4/4 Back BLK 1000 240.196 Point-to-point
Fa4/5 Desg FWD 200000 128.197 Point-to-point
Fa4/48 Boun FWD 200000 128.240 Point-to-point Bound(STP)
Figure demonstrates how to display spanning tree information for a specific MSTP instance - particularly, port status, costs, and forwarding roles.
A switch running Rapid PVST+ or MSTP supports a built-in protocol migration mechanism that enables it to interoperate with legacy IEEE 802.1D switches. If a Rapid PVST+ or MSTP switch receives a legacy IEEE 802.1D configuration BPDU with the protocol version set to 0, it sends only IEEE 802.1D BPDUs on that port. An MST switch can also detect that a port is at the boundary of a region when it receives a legacy BPDU, an MST BPDU (version 3) associated with a different region, or an RST BPDU (version 2).
However, the switch does not automatically revert to Rapid PVST+ or MSTP mode if it no longer receives IEEE 802.1D BPDUs, because it cannot determine whether the legacy switch has been removed from the link unless the legacy switch is the designated switch. Use the following command in this situation :
Switch#clear spanning-tree detected-protocols
This example displays MSTP information for a specific interface.
Switch#show spanning-tree mst interface fastethernet 4/4
FastEthernet4/4 of MST00 is backup blocking
Edge port:no (default) port guard :none (default)
Link type:point-to-point (auto) bpdu filter:disable (default)
Boundary :internal bpdu guard :disable (default)
Bpdus sent 2, received 368
Instance Role Sts Cost Prio.Nbr Vlans mapped
-------- ---- --- --------- -------- ------------------------
0 Back BLK 1000 240.196 11-4094
1 Back BLK 1000 240.196 1-10
This example displays MSTP information for a specific interface and a specific MSTP instance.
Switch#show spanning-tree mst 1 interface fastethernet 4/4
FastEthernet4/4 of MST01 is backup blocking
Edge port:no (default) port guard :none (default)
Link type:point-to-point (auto) bpdu filter:disable (default)
Boundary :internal bpdu guard :disable (default)
Bpdus (MRecords) sent 2, received 364
Instance Role Sts Cost Prio.Nbr Vlans mapped
-------- ---- --- --------- -------- -------------------------
1 Back BLK 1000 240.196 1-10
This example displays detailed MSTP information for a specific instance.
Switch#show spanning-tree mst 1 detail
###### MST01 vlans mapped: 1-10
Bridge address 00d0.00b8.1400 priority 32769 (32768 sysid 1)
Root this switch for MST01
FastEthernet4/4 of MST01 is backup blocking
Port info port id 240.196 priority 240 cost 1000
Designated root address 00d0.00b8.1400 priority 32769 cost 0
Designated bridge address 00d0.00b8.1400 priority 32769 port id 128.197
Timers:message expires in 5 sec, forward delay 0, forward transitions 0
Bpdus (MRecords) sent 123, received 1188
FastEthernet4/5 of MST01 is designated forwarding
Port info port id 128.197 priority 128 cost 200000
Designated root address 00d0.00b8.1400 priority 32769 cost 0
Designated bridge address 00d0.00b8.1400 priority 32769 port id 128.197
Timers:message expires in 0 sec, forward delay 0, forward transitions 1
Bpdus (MRecords) sent 1188, received 123
FastEthernet4/48 of MST01 is boundary forwarding
Port info port id 128.240 priority 128 cost 200000
Designated root address 00d0.00b8.1400 priority 32769 cost 0
Designated bridge address 00d0.00b8.1400 priority 32769 port id 128.240
Timers:message expires in 0 sec, forward delay 0, forward transitions 1
Bpdus (MRecords) sent 78, received 0
No hay comentarios:
Publicar un comentario