|
|
A VLAN is a logical group of LAN segments, independent of physical location, with a common set of requirements. For example, several end stations might be grouped as a department, such as engineering or accounting. If the end stations are located close to one another, they can be grouped into a LAN segment. If any of the end stations are on a different LAN segment, such as different buildings or locations, they can be grouped into a VLAN that has the same attributes as a LAN even though the end stations are not all on the same physical segment. The information identifying a packet as part of a specific VLAN is preserved across a Catalyst switch connection to a router or another switch if they are connected via trunk ports, such as ISL or ATM.
Any VLAN can participate in the Spanning-Tree Protocol. The protocol used depends on the type of VLAN and the type of bridging function used.
This chapter provides an overview of Token Ring VLANs, the Cisco VLAN Trunking Protocol, the Duplicate Ring Protocol, and the Spanning-Tree Protocols used by VLANs.
Because a VLAN is essentially a broadcast domain, a Token Ring VLAN is slightly more complex than an Ethernet VLAN. In transparent bridging there is only one type of broadcast frame and therefore only one level of broadcast domain, but in source routing there are multiple types of broadcast frames that fall into two categories:
These two categories of broadcast frames result in a broadcast domain that is hierarchical in nature, as a local ring domain can exist only within a domain of all the inter-connected rings.
In a Token Ring VLAN, logical ring domains are formed by defining groups of ports that have the same ring number. The IEEE calls such a port group a Concentrator Relay Function (CRF). On Catalyst switches, such a grouping of Token Ring ports is called a Token Ring CRF (TrCRF).
The domain of inter-connected rings is formed using an internal multiport bridge function that the IEEE calls a Bridge Relay Function (BRF). On Catalyst switches, such a grouping of logical rings is called a Token Ring BRF (TrBRF).
Figure 4-1 illustrates TrCRFs and a TrBRF within a Catalyst Token Ring switch or module.
A TrCRF is a logical grouping of ports. Within the TrCRF, source-route switching is used for forwarding based on either MAC addresses or route descriptors. Frames can be switched between ports within a single TrCRF.
A TrCRF has two global parameters: a ring number and a parent TrBRF identifier. On the Catalyst 3900, the ring number of the TrCRF can be defined or learned from external bridges. On the Catalyst 5000, the ring number must be defined.
As a rule, a TrCRF is limited to the Token Ring ports of a single Catalyst 5000 series switch, the ports of a single Catalyst 3900, or the ports within a stack of Catalyst 3900 switches. This type of TrCRF is called an undistributed TrCRF. However, if your switches are connected via ISL, the Cisco Duplicate Ring Protocol (DRiP) allows two types of TrCRFs in which the ports of a single TrCRF can be on different switches. These types of TrCRFs are the default and the backup TrCRF. For more information about DRiP, see the "Duplicate Ring Protocol" section.
The undistributed TrCRF is the standard type of TrCRF in the Catalyst 5000 series switch. The undistributed TrCRF is located on one switch and has a logical ring number associated with it. Multiple undistributed TrCRFs located on the same or separate switches can be associated with a single parent TrBRF. The parent TrBRF acts as a multiport bridge, forwarding traffic between the undistributed TrCRFs.
Figure 4-2 illustrates the undistributed TrCRF.
As a rule, TrCRFs cannot span different switches. There is one exception; the default TrCRF (1003). The default TrCRF can contain ports that are located on multiple switches. It is associated with the default TrBRF (1005), which can span switches via ISL. As the default TrCRF is the only TrCRF that can be associated with the default TrBRF, the default TrBRF does not perform any bridging functions, but uses source-route switching to forward traffic between the ports of the TrCRF.
Figure 4-3 illustrates the default TrCRF.
The backup TrCRF enables you to configure an alternate route for traffic between undistributed TrCRFs located on separate switches that are connected by a TrBRF. The backup TrCRF is only used if the ISL connection between the switches becomes inactive.
While a TrBRF can contain multiple TrCRFs, it can contain only one TrCRF that is configured as a backup TrCRF. The backup TrCRF can contain only one port from each related switch. If you have more than one TrBRF defined on a switch, you can have more than one backup TrCRF defined on a switch (one defined for each TrBRF).
To create a backup TrCRF, create the TrCRF, assign it to the TrBRF that traverses the switches, mark it as a backup TrCRF, and then assign one port on each switch to the backup TrCRF.
 | Caution If the backup TrCRF port is attached to a Token Ring MAU, it will not provide a backup path unless the ring speed and port mode are set by another device. Therefore, we recommend that you manually configure the ring speed and port mode for the port assigned to the backup TrCRF. |
Under normal circumstances only one port in the backup TrCRF is active. The active port is the port with the lowest MAC address. If the ISL connection between the switches become inactive, the port that is a part of the backup TrCRF on each affected switch will automatically become active, and will reroute traffic between the undistributed TrCRFs through the backup TrCRF. When the ISL connection is reestablished, all but one port in the backup TrCRF will be disabled.
Figure 4-4 illustrates the backup TrCRF.
A TrBRF is a logical grouping of TrCRFs. The TrBRF is used to join different TrCRFs contained within a single Catalyst 3900, a stack of Catalyst 3900s, or the Token Ring modules of a single Catalyst 5000 switch. In addition, the TrBRF can be extended across a network of switches via high-speed uplinks between the switches to join TrCRFs contained in different switches.
A TrBRF has two global parameters: a bridge number, and a bridge type. The bridge number is used to identify the logical distributed SRB, which inter-connects all logical rings that have the same parent TrBRF.
A TrBRF can function as an SRB or SRT bridge running either the IBM or IEEE Spanning-Tree Protocol. If SRB is used, duplicate MAC addresses can be defined on different logical rings.
To accommodate SNA traffic, you can use a combination of SRT and SRB modes. In a mixed mode, the TrBRF considers some ports (internal ports connected to TrCRFs) to be operating in SRB mode while others are operating in SRT mode.
When new VLANs are added to a device (a Cisco router or switch) in a management domain, VTP can be used to automatically distribute the information via trunk ports to all of the devices in the management domain. This distribution ensures VLAN naming consistency and connectivity between all devices in the domain by allowing each device in the domain to learn of any new VLANs added to other devices in the domain.
Often, VTP is not used in Ethernet environments, but it is important in Token Ring environments because it ensures the distribution of TrCRF information.
VTP advertisements are transmitted on all trunk connections, including the following:
VTP sends advertisements to a multicast address so the advertisements are received by all neighboring devices (but they are not forwarded by normal bridging procedures). The advertisement lists the sending device's VTP management domain, its configuration revision number, the VLANs known to the sending device, and parameters for each of the known VLANs. By receiving these advertisements, all devices in the same management domain learn about any new VLANs now configured in the transmitting device. Therefore, a VLAN can be created and configured on one device in the management domain and the information is automatically learned by all the other devices in the same management domain.
The switch can operate in three different VTP modes: server, client, or transparent.
In server mode, the switch permits changes to the administrative domain's global VLAN configuration from the local device. Redundancy in a network domain is created by using multiple VTP servers.
In client mode, the switch accepts configuration changes from other devices in the administrative domain, but does not permit local changes to the database.
In transparent mode, the switch forwards any VTP packets received on the default VLANs of any trunk onto the default VLANs of all other trunks. Use VTP transparent mode to enable a Catalyst switch to propagate VTP information even if it is not participating in VTP. In transparent mode, VTP packets received on one trunk are automatically propagated unchanged to all other trunks on the device but are ignored on the device itself.
To retain the VLAN information contained in VTP advertisements across reboots and network outages, a subset of the devices must be able to recover all information currently contained in advertisements after they reboot. In large, heterogeneous networks, the amount of information in the advertisements may be beyond the nonvolatile storage capabilities of some devices; however, storage of this same information in every device is normally beyond the required amount of redundancy. Therefore, each device in a VTP management domain is categorized as a VTP client or a VTP server.
VTP servers must be able to recover all the VLAN information in current VTP advertisements from nonvolatile-storage after they reboot. If they cannot, the device ceases being a VTP server and becomes a VTP client.
Under normal circumstances, VTP clients accept changes to the current VLAN information only through VTP advertisements. They do not accept changes via a console interface or SNMP. Upon boot up, the VTP client sends out periodic requests for VTP information on all of its trunks until it receives a summary advertisement from a neighbor. It uses that summary advertisement to determine whether its currently stored configuration is obsolete. If the stored configuration is obsolete, the client requests all VTP information from the neighbor.
If no VTP advertisement is received within a specified time, the VTP client can use the locally configured VLAN information, but will not issue VTP advertisements containing this information. This locally configured information is overridden (but may or may not be overwritten) as soon as the client receives a VTP advertisement. Thus, when a network is partitioned so that there are no VTP servers in a partition and all the VTP clients in that partition are rebooted, then no VTP advertisements are transmitted in that partition.
Upon boot up, the VTP server attempts to recover the information contained in VTP advertisements from nonvolatile-storage. Prior to successful recovery, the device can act only as a VTP client. The nonvolatile-storage used to hold the information can be either:
In a large heterogeneous network, only a few devices need to be VTP servers. The choice of which devices are servers should be made based on the capabilities of each device and the amount of redundancy required. In a small network, all devices are normally VTP servers.
 | Caution When a device that is configured to operate in server mode is added to a VTP domain and the configuration of the new device more current than that of the other devices in the network, all the VLAN information in the other devices will be overwritten. Therefore, exercise care when adding a device that is configured to operate in server mode to a VTP domain. |
In VTP, the following message types are defined:
All messages are sent as link-layer multicast frames.
An Advert-Request is sent after a reboot, and when any of the following occur:
After an Advert-Request is sent, a timer is started. The timer has a timeout period of a random value from 0 to 1 second. If the timer expires before a Summary-Advert is received, then another Advert-Request is sent.
An Advert-Request normally requests information on all VLANs; it can, however, request information on only a subset of the VLANs.
An advertisement is sent in the following situations:
Each advertisement consists of one Summary-Advert immediately followed by zero or more Subset-Adverts.
The number of Subset-Advert messages that follow a Summary-Advert is determined according to the reason for sending the advertisement as in the following situations:
Because the information required for each VLAN could potentially exceed 40 octets, it is impossible to contain all the information for all VLANs in a single MAC frame. It is not necessary for all the information to be sent in each advertisement. Regular, periodic advertisements only need to indicate that nothing has changed.
Occasionally, all information on all VLANs must be transmitted as a sequence of frames. This always occurs after a configuration change. It can also occur when it is requested by one of the devices, either because that device failed to receive one or more of the sequence of frames or because it has just restarted.
The following indications are used in advertisements to indicate whether the configuration has changed:
The device's VTP configuration revision number is incremented each time the device is reconfigured by management (console or SNMP) to do the following:
The current time and the local device's identity (one of its IP-addresses) are recorded and included in the next VTP advertisement.
When a device receives an advertisement, the following occurs:
| If the configuration revision number in the advertisement is | Then |
|---|---|
Less than that of the receiving device | The advertisement is ignored. |
The same as that of the receiving device |
|
Greater than that of the receiving device and the advertisement's checksum and configuration information match |
|
The time required to propagate new information across all devices is typically on the order of milliseconds, or, at most, a few seconds. However, it can be longer if some devices are temporarily partitioned (because of a break in the network). When a set of devices is partitioned for a prolonged period, a device in each partition should be updated. When the partition is repaired, the configuration in the set of devices with the greater configuration revision number takes precedence. If, however, devices in both partitions have the same configuration revision level, a configuration error is indicated.
A checksum is defined to ensure that two different configurations with the same configuration revision number (which can occur, for example, after a network partition) are recognized as being different.
The checksum is calculated using an arbitrary security value that is appended to the front end and the back end of the data in a VTP configuration. When a VTP device has received all of the parts of the VTP configuration, it recalculates the checksum using its own security value derived from the password that has been configured locally. The device will not accept the new configuration if the checksums do not match.
On all Cisco VTP devices, the default initial configuration of the security value is all zeroes. Therefore, VTP devices will always accept one another's VLAN configurations as long as none of the security values on any of the devices have been modified. To make use of the security feature, a password needs to be set. The password must be the same for the management domain on all devices in the domain. Neither the password nor the security value itself is ever advertised over the network.
 | Caution If you use passwords, the same management domain password must be assigned to each Catalyst switch in the domain. Otherwise, the management domain will not function properly. |
VTP advertisements are transmitted using a multicast destination MAC address (0100.0CCC.CCCC) and are not forwarded using normal bridging techniques. A switch regenerates a VTP advertisement to all of its other trunk ports if the advertisement contains new configuration information.
Advertisements are transmitted on the default VLAN, which corresponds to the type of trunk link. Thus, only one copy is transmitted on a trunk port, no matter how many VLANs are defined.
VTP is assigned the Cisco High-level Data Link Control (HDLC) protocol type value of 0x2003. A Cisco-proprietary SNAP value enumerates HDLC protocol type values so VTP can run on all media that support SNAP, such as LAN media, Frame Relay, and ATM.
The SNAP format is as follows:
VTP sends packets on LANs using the multicast address 0100.0CCC.CCCC.
Because VTP does not run on top of any network layer, but runs only over the data link layer, a switch can learn from an advertisement even if it does not have a Layer 3 address on that VLAN.
For more information about the format of VTP frames, see the "Frame Formats" appendix.
A VLAN Status Request message requests all devices in the management domain to respond if their response will determine some aspect of global status information about a particular VLAN. A device with such information generates a VLAN Status Response message and transmits it directly to the originator of the VLAN Status Request message. Both VLAN Status Requests and VLAN Status Responses are sent on the default VLAN (VLAN1, which is the default Ethernet VLAN). VLAN Status Requests are sent to a multicast address that is a different address than the one to which advertisements are sent, so that they are forwarded via normal bridging procedures.
A VLAN Status Request with the Ports-Assigned code requests a response from any device in the management domain that has at least one port assigned to a particular VLAN. Any device having at least one port assigned to the indicated VLAN generates a VLAN Status Response with the Ports-Assigned code.
The Cisco Duplicate Ring Protocol (DRiP) runs on Cisco devices that support switched VLAN networking and is used to identify active VLANs and to help prevent the configuration of duplicate rings (TrCRFs) across switches.
Through packet advertisements, DRiP maintains the status of TrCRFs. It then uses this information to determine whether there are multiple TrCRFs active in a TrBRF.
DRiP information is used for the following:
DRiP sends advertisements to a multicast address so the advertisements are received by all neighboring devices (but they are not forwarded by normal bridging procedures). The advertisement includes VLAN information for the source device only.
When a switch receives a DRiP advertisement, it compares the information in the advertisement with its local configuration to determine which TrCRFs have active ports and then denies any configuration that would allow a TrCRF that is already active on another box to be configured on the local switch.
In the event a TrCRF is believed to not be in use within the TrBRF and ports on two or more separate devices are simultaneously configured for the same TrCRF, each switch will send a DRiP advertisement and the advertisement with the lowest sender's MAC address will be accepted. The switch with the higher MAC address will disable the port that was just configured and will send a DuplicateRingNumberError trap.
If a trunk connection is lost, an aging process ages out all entries associated with that trunk port.
A DRiP advertisement is sent at periodic intervals (30 seconds). If no change in status or configuration has taken place, then the configuration revision number is not updated. Instead the periodic message will indicate that nothing has changed because the revision number has not changed.
A switch also generates a DRiP advertisement when one of the following occurs:
DRiP advertisements are transmitted using the same multicast destination MAC address (0100.0CCC.CCCC) used for VTP and are not forwarded using normal bridging techniques. Like VTP, a switch regenerates DRiP advertisement to all of its other trunk ports if the advertisement contains new configuration information.
Advertisements are transmitted on the default VLAN (VLAN1), which corresponds to the type of trunk link. Thus, only one copy is transmitted on a trunk port, no matter how many VLANs are defined.
DRiP is assigned the Cisco HDLC protocol type value 0x0102. A Cisco-proprietary SNAP value enumerates HDLC protocol type values so DRiP can run on all media that support SNAP, such as LAN media, Frame Relay, and ATM.
The SNAP format is as follows:
DRiP sends packets on LANs using the multicast address 0100.0CCC.CCCC.
For more information about the format of DRiP frames, see the "Frame Formats" appendix.
To accomplish this, the Spanning-Tree Protocol blocks ports that, if active, would create bridging loops. If the primary link fails, it activates one of the blocked bridge ports to provide a new path through the network.
In a traditional bridged network, there is one Spanning-Tree Protocol for each bridge connection. Each bridge maintains its own database of configuration information and transmits and receives only on those ports belonging to the bridge. The type of Spanning-Tree Protocol that runs on a bridge depends on the transmission mode of the bridge connection (whether the connection is SRB, source-route switched, or SRT).
As discussed in the "Token Ring VLANs" section, in a switched network, you can configure virtual networks. A switch can have ports that belong to different VLANs, some of which may span several switches. To prevent loops in the bridged connections between the VLANs, you should configure the Spanning-Tree Protocol.
In a Token Ring switch, there are two levels of VLANs. Therefore, in a Token Ring switched network, to ensure loops are removed from the topology you must configure a separate Spanning-Tree Protocol for the logical bridge (TrBRF) and for the port groups (TrCRF) configured for a VLAN .
The Spanning-Tree Protocol that is run at the TrCRF is used to remove the loops in the TrCRF logical ring. The Spanning-Tree Protocol that is run at the TrBRF is used to remove the loops in the bridging topology.
In general, the Spanning-Tree Protocol eliminates loops in the network as follows:
3. Each bridge determines its root port and root path cost.
4. All participating bridges elect a designated bridge from among the bridges on that LAN segment.
5. All participating bridges select ports for inclusion in the spanning tree.
6. Using the preceding steps, all but one of the bridges directly connected to each LAN segment are eliminated, thereby removing all multiple LAN loops.
The Spanning-Tree Protocol calculation requires that bridges communicate with other bridges in the network that are running the Spanning-Tree Protocol. Each bridge is responsible for sending and receiving configuration messages called bridge protocol data units (BPDUs).
BPDUs are exchanged between neighboring bridges at regular intervals (typically 1 to 4 seconds) and contain configuration information that identifies the:
If a bridge fails and stops sending BPDUs, the bridges detect the lack of configuration messages and initiate a spanning-tree recalculation.
The Catalyst Token Ring Switches support the following Spanning-Tree Protocols:
The following sections briefly describe the type of transmission mode supported by each Spanning-Tree Protocol.
The IEEE Spanning-Tree Protocol frames use a multicast destination address of x'800143000000.
The IBM Spanning-Tree Protocol frames use a multicast destination address of x'C00000000100.
One of the rules in processing source-route traffic is that a source-route frame should never be forwarded to a ring that it has previously traversed. If the RIF of a source-route frame already contains the ring number for the next hop, the bridge assumes that the frame has already been on that ring and drops the frame.
With Token Ring VLANs, however, this rule can cause a problem. With the existing Spanning-Tree Protocol, a frame that originated on one physical ring of a Token Ring VLAN and is processed by an external SRT bridge would not be forwarded to another physical ring of the same Token Ring VLAN. Therefore, the IEEE 802.1d Spanning-Tree Protocol was used as a basis to create the Cisco Spanning-Tree Protocol. The Cisco Spanning-Tree Protocol ensures that traffic from one physical ring of a VLAN is not blocked from the other physical rings that comprise the VLAN.
The Cisco BPDUs are source-routed frames with two bytes of RIF information. This ensures that BPDUs will not be source routed or transparently routed to other LANs. The Cisco BPDUs use a different multicast destination address (x'800778020200) to ensure that external bridges do not interpret the frames as IEEE or IBM Spanning-Tree Protocol frames.
Although the Catalyst 3900 switch and Catalyst 5000 Token Ring module support the three Spanning-Tree Protocols, the use of the protocols is implemented differently on each switch.
For the Catalyst 3900, you can set the Spanning-Tree Protocol for the TrBRF and the TrCRF.
Possible values for the Spanning-Tree Protocol at the TrBRF are no, IBM, IEEE, and Base on Bridging. If you select Base on Bridging, the Spanning-Tree Protocol used will be determined by the bridge mode. If the bridge mode is SRB, the IBM Spanning-Tree Protocol is used. If the bridge mode is SRT, the IEEE Spanning-Tree Protocol is used.
Possible values for the Spanning-Tree Protocol at the TrCRF are no, IEEE, and Cisco.
Recommendations for running the Spanning-Tree Protocol are as follows:
For the Catalyst 5000 Series Token Ring module, you can set the Spanning-Tree Protocol for the TrBRF only. Possible values are IBM and IEEE.
The Spanning-Tree Protocol used at the TrCRF is determined by the bridge mode.
The ISL module supports the Spanning-Tree Protocol at both the TrCRF and the TrBRF level. The Spanning-Tree Protocol that is run on the ISL link depends on the type of TrCRF:
Also, there are some combinations of Spanning-Tree Protocol and bridge mode that the Catalyst 5000 series Token Ring module considers incompatible. These combinations are as follows:
If you configure one of these combinations, no Spanning-Tree Protocol will be run at the TrBRF level and the logical ports will be placed in a blocked state. You can override the logical port state using the set spantree portstate command.
Table 4-1shows a summary of the Spanning-Tree Protocols used on the Catalyst 5000 Token Ring module.
| Spanning-Tree Protocol Specified for TrBRF | Port Type or Bridge Mode Specified for TrCRF | Spanning-Tree Protocol Used at TrBRF | Spanning Tree Protocol Used at TrCRF |
IBM
| SRB | IBM | IEEE |
SRT | None | Cisco | |
IEEE
| SRB | None | IEEE |
SRT | IEEE | Cisco |
Posted: Wed Oct 2 03:40:26 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.