Sinfónica de Venezuela
domingo, 5 de julio de 2009
CCNP3. Cap3.Cont. Configuring Link Aggregation with EtherChannel
3.4 Configuring Link Aggregation with EtherChannel
3.4.1 Describing EtherChannel
Companies require greater and cheaper bandwidth to run their networks, and users are becoming more impatient with any latency that occurs. The insatiable appetite for faster networks and higher availability has intensified the competition among vendors. Some years ago, Cisco came up with a method to provide substantially higher bandwidth with lower cost overhead.
Cisco originally developed EtherChannel as a LAN switch-to-switch technique of inverse multiplexing of multiple Fast or Gigabit Ethernet switch ports into one logical channel. It is effectively cheaper than higher speed media while using existing switch ports.
EtherChannel has developed into a cross-platform method of load balancing between servers, switches, and routers. EtherChannel can bond two, four, or eight ports (Cisco Catalyst 6500) to develop one logical connection with redundancy. The major aspects of EtherChannel are:
Frame distribution
Management of EtherChannel
Logical port
EtherChannel does not do frame-by-frame forwarding in a round-robin fashion on each of the links. The load-balancing policy or frame distribution used is contingent upon the switch platform used. For instance, in a Cisco Catalyst 5500 switch platform, load balancing performs an X-OR calculation on the two lowest order bits of the source and destination MAC address. An X-OR operation between a given pair of addresses uses the same link for all frames. One of the primary benefits of the X-OR operation is to prevent out-of-order frames on the downstream switch. The other advantage is redundancy. If the active channel used by a connection is lost, the existing traffic can traverse over another active link on that EtherChannel. The one disadvantage of an X-OR operation is that the load on the channels might not be equal because the load-balancing policy is done on a specific header as defined by the platform or user configuration. On a Cisco Catalyst 6500 switch, load balancing can be performed on MAC addresses, IP addresses, or IP + TCP/UDP, depending on the type of Supervisor/PFC used. Use the show port capabilities command to check the module for EtherChannel feature.
The default frame distribution behavior for the Cisco Catalyst 6500 is IP.
EtherChannel bundles individual Ethernet links into a single logical link that provides bandwidth up to 1600 Mbps (Fast EtherChannel, full duplex) or 16 Gbps (Gigabit EtherChannel) between two Cisco Catalyst switches. All interfaces in each EtherChannel must be the same speed and duplex, and both ends of the channel must be configured as either a Layer 2 or Layer 3 interface.
If a link within the EtherChannel bundle fails, traffic previously carried over the failed link is carried over the remaining links within the EtherChannel.
The configuration applied to the individual physical interfaces that are to be aggregated by EtherChannel affects only those interfaces. Each EtherChannel has a logical port channel interface. A configuration applied to the port channel interface affects all physical interfaces assigned to that interface. 
(These can be STP commands or commands to configure a Layer 2 EtherChannel as a trunk.)
EtherChannel provides the following features and benefits: 
Allows for the creation of a very high bandwidth logical link
Load balances among the physical links involved
Provides automatic failover
Simplifies subsequent logical configuration (configuration is per logical link instead of per physical link)
3.4.2 Describing PAgP and LACP
Cisco’s proprietary Port Aggregation Protocol (PAgP) and the IEEE standard Link Aggregation Protocol (LACP) automatically create bundled Ethernet links.
PAgP packets are sent between Fast EtherChannel-capable ports to negotiate the forming of a channel. When PAgP identifies matched Ethernet links, it groups the links into an EtherChannel. The EtherChannel is then added to the spanning tree as a single bridge port.
PAgP manages EtherChannel. PAgP packets are sent every 30 seconds using multicast group MAC address 01-00-0C-CC-CC-CC with protocol value 0x0104. PAgP checks for configuration consistency and manages link additions and failures between two switches. It ensures that when an EtherChannel is created that all ports have the same type of configuration, because it is mandatory that all ports have the same speed, duplex setting, and VLAN information. Any port modification after the creation of the channel will also change all the other channel ports.
The last component of EtherChannel is the creation of the logical port. The logical port, or Agport, is composed of all the ports that make up the EtherChannel. The Agport’s functionality and behavior are no different than any other port. For instance, the spanning tree algorithm treats Agport as a single port.
LACP is part of an IEEE specification (802.3ad) that allows several physical ports to be bundled together to form a single logical channel. LACP allows a switch to negotiate an automatic bundle by sending LACP packets to the peer. It performs a similar function as PAgP with Cisco EtherChannel. Because LACP is an IEEE standard, it can be used to facilitate EtherChannels in mixed-switch environments.
Interfaces can be set in any of several modes to control EtherChannel formation. Figure shows the settings for PAgP and LACP. The following parameters are used in configuring LACP:
System priority: Each switch running LACP must have a system priority, which can be specified automatically or through the CLI. The switch uses the MAC address and the system priority to form the system ID.
Port priority: Each port in the switch must have a port priority, which can be specified automatically or through the CLI. The port priority and the port number form the port identifier. The switch uses the port priority to decide which ports to put in standby mode when a hardware limitation prevents all compatible ports from aggregating.
Administrative key: Each port in the switch must have an administrative key value, which can be specified automatically or through the CLI. The administrative key defines the ability of a port to aggregate with other ports, determined by the following:
The port’s physical characteristics, such as data rate, duplex capability, and point-to-point or shared medium
The configuration constraints that you establish
LACP attempts to configure the maximum number of compatible ports in a channel. In some instances, LACP is not able to aggregate all the ports that are compatible; for example, the remote system might have more restrictive hardware limitations. When this occurs, all the ports that cannot be actively included in the channel are put in hot standby state and used only if one of the channeled ports fails.
3.4.3 Describing EtherChannel Configuration Commands
The commands in Figures
3.4.4 Configuring Port Channels Using EtherChannel
Figure
Figure 
illustrates the configuration of Layer 3 EtherChannel. Figure 
shows the steps for configuring and verifying a Layer 3 EtherChannel interface.
Use the show running-config interface port-channel num command to display the configuration specific to the port channel. 
Use the show interfaces [interface] [num] etherchannel command to display information about the port channel and the specific EtherChannel interfaces. 
The following example demonstrates how to verify the configuration of a Layer 3 EtherChannel.
Switch#show interfaces fastethernet 5/4 etherchannel
Port state = EC-Enbld Up In-Bndl Usr-Config
Channel group = 1 Mode = Desirable Gcchange = 0
Port-channel = Po1 GC = 0x00010001 Pseudo-port-channel = Po1
Port indx = 0 Load = 0x55
Flags: S - Device is sending Slow hello. C - Device is in Consistent state.
A - Device is in Auto mode. P - Device learns on physical port.
Timers: H - Hello timer is running. Q - Quit timer is running.
S - Switching timer is running. I - Interface timer is running.
Local information:
Hello Partner PAgP Learning Group
Port Flags State Timers Interval Count Priority Method Ifindex
Fa5/4 SC U6/S7 30s 1 128 Any 55
Partner's information:
Partner Partner Partner Partner Group
Port Name Device ID Port Age Flags Cap.
Fa5/4 JAB031301 0050.0f10.230c 2/45 1s SAC 2D
Age of the port in the current state: 00h:54m:52s
The following two command outputs show how to verify the configuration of Fast Ethernet interface 5/6 for Layer 2 EtherChannel.
Switch#show running-config interface fastethernet 5/6
Building configuration...
Current configuration:
!
interface FastEthernet5/6
switchport access vlan 10
switchport mode access
channel-group 2 mode desirable
end
Switch#show interfaces fastethernet 5/6 etherchannel
Port state = EC-Enbld Up In-Bndl Usr-Config
Channel group = 1 Mode = Desirable Gcchange = 0
Port-channel = Po1 GC = 0x00010001
Port indx = 0 Load = 0x55
Flags: S - Device is sending Slow hello. C - Device is in Consistent state.
A - Device is in Auto mode. P - Device learns on physical port.
Timers: H - Hello timer is running. Q - Quit timer is running.
S - Switching timer is running. I - Interface timer is running.
Local information:
Hello Partner PAgP Learning Group
Port Flags State Timers Interval Count Priority Method Ifindex
Fa5/6 SC U6/S7 30s 1 128 Any 56
Partner's information:
Partner Partner Partner Partner Group
Port Name Device ID Port Age Flags Cap.
Fa5/6 JAB031301 0050.0f10.230c 2/47 18s SAC 2F
Age of the port in the current state: 00h:10m:57s
Use the show etherchannel command to display port-channel information after configuration.
The next example shows how to verify the configuration of port-channel interface 1 after the interfaces have been configured.
Switch#show etherchannel 1 port-channel
Channel-group listing:
----------------------
Group: 1
------------
Port-channels in the group:
----------------------
Port-channel: Po1
------------
Age of the Port-channel = 01h:56m:20s
Logical slot/port = 10/1 Number of ports = 2
GC = 0x00010001 HotStandBy port = null
Port state = Port-channel L3-Ag Ag-Inuse
Ports in the Port-channel:
Index Load Port
-------------------
1 00 Fa5/6
0 00 Fa5/7
Time since last port bundled: 00h:23m:33s Fa5/6
This example shows how to verify the configuration of port-channel interface 1 (a Layer 2 EtherChannel) after the interfaces have been configured.
Switch#show etherchannel 1 port-channel
Port-channels in the group:
----------------------
Port-channel: Po1
------------
Age of the Port-channel = 00h:23m:33s
Logical slot/port = 10/2 Number of ports in agport = 2
GC = 0x00020001 HotStandBy port = null
Port state = Port-channel Ag-Inuse
Ports in the Port-channel:
Index Load Port
-------------------
1 00 Fa5/6
0 00 Fa5/7
Time since last port bundled: 00h:23m:33s Fa5/6
Follow these guidelines and restrictions when configuring EtherChannel interfaces:
EtherChannel support: All Ethernet interfaces on all modules support EtherChannel (maximum of eight interfaces), with no requirement that interfaces be physically contiguous or on the same module.
Speed and duplex: Configure all interfaces in an EtherChannel to operate at the same speed and in the same duplex mode. Also, if one interface in the bundle is shut down, it is treated as a link failure, and traffic traverses other links in the bundle.
Switched port analyzer (SPAN) and EtherChannel: An EtherChannel will not form if one of the interfaces is a SPAN destination port.
Layer 3 EtherChannels: Assign Layer 3 addresses to the port-channel logical interface, not to the physical interfaces in the channel.
VLAN match: All interfaces in the EtherChannel bundle must be assigned to the same VLAN or be configured as a trunk.
Range of VLANs: An EtherChannel supports the same allowed range of VLANs on all the interfaces in a trunking Layer 2 EtherChannel. If the allowed range of VLANs is not the same, the interfaces do not form an EtherChannel, even when set to auto or desirable mode. For Layer 2 EtherChannels, either assign all interfaces in the EtherChannel to the same VLAN or configure them as trunks.
STP path cost: Interfaces with different STP port path costs can form an EtherChannel as long they are otherwise compatibly configured.
Port channel versus interface configuration: After you configure an EtherChannel, any configuration you apply to the port-channel interface affects the EtherChannel. Any configuration you apply to the physical interfaces affects only the specific interface you configured.
The example illustrated in Figure 
shows how to configure an EtherChannel following the guidelines.
3.4.5 Configuring Load Balancing over EtherChannel
In Figure
Use the option that provides the greatest variety in your configuration. For example, if the traffic on a channel is going only to a single MAC address, using the destination MAC address always chooses the same link in the channel; using source addresses might result in better load balancing.
EtherChannel balances the traffic load across the links in a channel by reducing part of the binary pattern formed from the addresses in the frame to a numerical value that selects one of the links in the channel. EtherChannel load balancing can use either source-MAC or destination-MAC address forwarding.
With source-MAC address forwarding, when packets are forwarded to an EtherChannel, they are distributed across the ports in the channel based on the source MAC address of the incoming packet. Therefore, to provide load balancing, packets from different hosts use different ports in the channel, but packets from the same host use the same port in the channel (and the MAC address learned by the switch does not change).
With destination-MAC address forwarding, when packets are forwarded to an EtherChannel, they are distributed across the ports in the channel based on the destination MAC address of the frame. Therefore, packets to the same destination are forwarded over the same port, and packets to a different destination are sent on a different port in the channel. You configure the load balancing and forwarding method by using the port-channel load-balance global configuration command.
EtherChannel balances traffic load across the links in a channel. The default and load balancing method varies among the Cisco Catalyst models.
Load balancing is applied globally for all EtherChannel bundles in the switch. To configure EtherChannel load balancing, use the port-channel load-balance command. Load balancing can be based on the following variables:
src-mac: Source MAC address
dst-mac: Destination MAC address
src-dst-mac: Source and destination MAC addresses
src-ip: Source IP address
dst-ip: Destination IP address
src-dst-ip: Source and destination IP addresses (default)
src-port: Source TCP/User Datagram Protocol (UDP) port
dst-port: Destination TCP/UDP port
src-dst-port: Source and destination TCP/UDP ports
This example shows an example of how to configure and verify EtherChannel load balancing.
Switch(config)# port-channel load-balance src-dst-ip
Switch(config)# exit
Switch# show etherchannel load-balance
Source XOR Destination IP address
3.5 Spanning Tree Lab Exercises
3.5.1 Lab 3-1 Spanning Tree Protocol (STP) Default Behavior
Lab Activity
Lab Exercise: Lab 3-1 Spanning Tree Protocol (STP) Default Behavior
The purpose of this lab is to observe the default behavior of STP.
3.5.2 Lab 3-2 Modifying Default Spanning Tree Behavior
Lab Exercise: Lab 3-2 Modifying Default Spanning Tree Behavior
The purpose of this lab is to observe what happens when the default spanning tree behavior is modified.
3.5.3 Lab 3-3 Per-VLAN Spanning Tree Behavior
Lab Exercise: Lab 3-3 Per-VLAN Spanning Tree Behavior
The purpose of this lab is to observe what happens when there is a separate spanning tree instance per VLAN. This lab also looks at changing spanning tree mode to rapid spanning tree.
3.5.4 Lab 3-4 Multiple Spanning Tree
Lab Activity
Lab Exercise: Lab 3-4 Multiple Spanning Tree
The purpose of this lab is to observe the behavior of MST (multiple spanning tree).
3.5.5 Lab 3-5 Configuring Etherchannel
Lab Activity
Lab Exercise: Lab 3-5 Configuring Etherchannel
The purpose of this lab is to configure and observe Etherchannel.
Summary
This module reviewed the fundamentals of the STP operation in a switched network. Many enhancements have been made to the original 802.1D STP. A switched network can quickly adapt to topology changes by implementing RSTP. MSTP implements a minimal number of STP instances in a switched environment. Recommended practices and guidelines for EtherChannel were examined.
CCNP. cap3-parte2.Cont
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
Suscribirse a:
Entradas (Atom)
