|
|
The traditional method of connecting multiple Token Ring segments is to use a source-routing bridge. For example, bridges are often used to link workgroup rings to the backbone ring. However, the introduction of the bridge can significantly reduce performance at the user's workstation. Further problems may be introduced by aggregate traffic loading on the backbone ring.
To maintain performance and avoid overloading the backbone ring, you can locate servers on the same ring as the workgroup that needs to access the server. However, dispersing the servers throughout the network makes them more difficult to back up, administer, and secure than if they are located on the backbone ring and limits the number of servers that particular stations can access.
Collapsed backbone routers offer greater throughput than bridges, and can interconnect a larger number of rings without becoming overloaded. Routers provide both bridging and routing function between ring and have sophisticated broadcast control mechanisms. These mechanisms become increasingly important as the number of devices on the network increase.
The main drawback of using routers as the campus backbone is the relatively high price-per-port and the fact that the throughput typically does not increase as ports are added. A Token Ring switch is designed to provide wire speed throughput regardless of the number of ports in the switch. In addition, the switch can be configured to provide very low latency between Token Ring ports by using cut-through switching.
As a local collapsed backbone device, a Token Ring switch offers a lower per-port cost and can incur lower interstation latency than a router. In addition, the switch can be used to directly attach large numbers of clients or servers, thereby replacing concentrators. Typically, a Token Ring switch is used in conjunction with a router, providing a high-capacity interconnection between Token Ring segments while retaining the broadcast control and wide-area connectivity provided by the router.
The Catalyst 3900 supports the following bridging modes:
Clients or servers that support source routing typically send an explorer frame to determine the path to a given destination. There are two types of explorer frames: all-routes explorer and spanning-tree explorer. All SRB bridges copy all-routes explorer frames and add their own routing information. For frames that are received from or sent to ports that are in the spanning-tree forwarding state, bridges copy spanning-tree explorer frames and add their own routing information. Because all-routes explorer frames will traverse all paths between two devices, they are used in path determination. Spanning-tree explorer frames are used to send datagrams because the spanning tree will ensure that only one copy of an spanning-tree explorer frame is sent to each ring.
The SRT bridge only runs the IEEE STP. It does not support the IBM STP.
The key difference between SRB and source-route switching is that while a source-route switch looks at the RIF, it never updates the RIF. Therefore, all ports in a source-route switch group have the same ring number.
Source-route switching provides the following benefits:
The Catalyst 3900 supports the following forwarding modes:
While store-and-forward reduces the amount of error traffic on the LAN, it also causes a delay in frame forwarding that is dependent upon the length of the frame.
In accordance with specification ISO/IEC 10038, the Catalyst 3900 uses Access Priority 4 to gain priority access to the token on the output ring if the outgoing port is operating in half-duplex mode. This increases the proportion of packets that can be cut through and makes it possible for the Catalyst 3900 to reduce the average interstation latency.
In certain circumstances, however, the cut-through technique cannot be applied and the Catalyst 3900 must buffer frames into memory.
For example, buffering must be performed in the following circumstances:
Dedicated Token Ring, developed by the IEEE, defines a method in which the switch port can emulate a concentrator port, thereby eliminating the need for an intermediate concentrator. In addition, dedicated Token Ring defines a new full-duplex data passing mode called Transmit Immediate, which eliminates the need for a token and allows the adapter to transmit and receive simultaneously.
Dedicated Token Ring is particularly useful for providing improved access to servers. A server can be attached directly to a switch. This allows the server to take advantage of the full 16 Mbps available for sending and receiving and results in an aggregate bandwidth of 32 Mbps.
The Catalyst 3900 supports VTP Version 2, which includes provisions for the propagation of Token Ring-specific parameters associated with VLANs, such as hop count and bridge numbers.
On boot up, the Catalyst 3900 switch sends out periodic requests for VTP configuration 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 Catalyst 3900 requests all VTP information from the neighbor.
The Catalyst 3900 switch transmits VTP frames on its trunk ports, advertising its management domain name, configuration revision number, and VLAN information that it has learned. Other Catalyst switches in the domain use these advertisements to learn about any new VLANs that are configured in the transmitting switch. This process of advertising and learning allows a new VLAN to be created and configured on only one switch in the management domain. This information is then learned automatically by all of the other devices in the domain.
The Catalyst 3900 switch can operate in three different VTP modes: server, client, or transparent.
VTP pruning enhances network bandwidth use by reducing unnecessary flooded traffic, such as broadcast, multicast, unknown, and flooded unicast packets. VTP pruning increases available bandwidth by restricting flooded traffic to those ISL trunk links that the traffic must use to access the appropriate network devices. By default, VTP pruning is disabled.
Figure A-1 shows a switched network without VTP pruning enabled. Port 1 on Switch 1 and port 2 on Switch 4 are assigned to the VLAN 200. A broadcast is sent from the host connected to Switch 1. Switch 1 floods the broadcast and every switch in the network receives it, even though Switches 3, 5, and 6 have no ports in the VLAN 200.
Figure A-2 shows the same switched network with VTP pruning enabled. The broadcast traffic from Switch 1 is not forwarded to Switches 3, 5, and 6 because traffic for the VLAN 200 has been pruned on the links indicated (port 5 on Switch 2 and port 4 on Switch 4).
Enabling VTP pruning on a VTP server enables pruning for the entire administrative domain. VTP pruning takes effect several seconds after you enable it. By default, VLANs 2 through 1000 are pruning-eligible. VTP pruning does not prune traffic from VLANs that are pruning-ineligible. VLAN 1, the default TrCRF (1003), the default TrBRF (1005), and TrCRFs are always pruning-ineligible, therefore traffic from these VLANs cannot be pruned.
When a Catalyst 3900 is booted for the first time (and when it is rebooted after a nonvolatile random-access memory [NVRAM] reset), it comes up in no-domain mode. The no-domain mode means there is no domain name configured in the switch. While in no-domain mode, a switch will not attempt to advertise its own current configuration. If and when it receives an advertisement from any neighbor on any trunk, it will immediately accept the management domain name from the neighbor's advertisement as its own. After receiving all of the neighbor's configuration data, it will begin advertising this data regularly (after a reboot) on all of its trunks.
A 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 passwords are set, a management domain does not function properly if the same management domain password is not assigned to each Catalyst switch in the domain. |
The ring number of the TrCRF can be defined or learned from external bridges. Within the TrCRF, source-route switching is used for forwarding based on either MAC addresses or route descriptors. If desired, the entire VLAN can operate as a single ring.
Frames can be switched between ports within a single TrCRF.
As shown in Figure A-3, multiple TrCRFs can be interconnected using a single Token Ring Bridge Relay Function (TrBRF). For source routing, the switch appears as a single bridge between the distributed rings. The TrBRF can function as an SRB or SRT bridge running either the IBM or IEEE STP. If SRB is used, duplicate MAC addresses can be defined on different distributed 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.
The TrBRF can be extended across a network of switches via high-speed uplinks between the switches. If you have an ISL module installed in your Catalyst 3900 Token Ring switch, the following types of TrCRFs can exist in your network: undistributed, backup, and default.
The undistributed TrCRF is the standard type of TrCRF in the Catalyst 3900 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 A-4 illustrates the undistributed 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, in case 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. That backup TrCRF can contain only one port from each related switch. If, however, 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, it is recommended 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, rerouting 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 A-5 illustrates the backup TrCRF.
As a rule, TrCRFs cannot span different switches. There is one exception; the default TrCRF (1003). The default TrCRF can contains 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 simply uses source-route switching to forward traffic between the ports of the TrCRF. Figure A-6 illustrates the default TrCRF.
ATM is a hardware and software architecture that switches small units of data called cells. The latency in a cell switch is very small because of the short cell size. Short cells have a tiny store-and-forward delay. In the absence of port contention and buffering, cells are switched quickly in the hardware. In addition to the low latency, ATM is beneficial to large networks because it:
The components of the 53-byte ATM cell are the following:
The PVC is statically mapped at each ATM node. The path of the PVC is identified at each switch by an incoming VCI and VPI and an outgoing VCI and VPI.
Establishing an SVC potentially involves signaling between the following:
The UNI is defined by the ATM Forum UNI specification.
Interfaces to public ATM networks are identified by an E.164 address. Interfaces to private ATM networks are identified by a network service access point (NSAP) address. These addresses are contained in different fields of the same 20-octet address.
Once an SVC is established, it functions like a PVC. SVCs can be used in point-to-point subinterface configuration or point-to-multipoint nonbroadcast multiaccess (NBMA) configuration.
The purpose of the AAL is to receive the data from the various sources or applications and convert or adapt it to 48-byte segments that will fit into the payload of an ATM cell. Because ATM benefits from its ability to accommodate data from various sources with differing characteristics, the adaptation layer must be flexible.
There are four classes of traffic supported by the adaptation layer:
Because ATM is inherently a connection-oriented transport mechanism and because the current applications of ATM are heavily oriented toward LAN traffic, many of the current ATM products, including the Catalyst 3900, support the Class D adaptation layer with AAL5.
The building blocks of an ATM internetwork may consist of the following:
The ATM expansion module supports up to 63 VLANs (or ELANs). Each VLAN corresponds to an ELAN. Each association between the ATM expansion module and a VLAN creates a virtual ATM port. A virtual ATM port is the equivalent of an LEC.
LANE makes the ATM network transparent to LAN traffic by mapping connectionless LAN traffic over the connection-oriented ATM network. It uses point-to-multipoint connections to service the connectionless broadcast service that is required by LAN protocols.
Cisco's Token Ring implementation of LANE makes an ATM interface look like one or more Token Ring interfaces; the ELAN looks like a ring. Setting up LECs allows the Catalyst 3900 to operate in a LAN environment containing ATM devices, such as Cisco 7000 or 4500 series routers with an ATM interface or ATM port adapter connected to a LightStream 1010 ATM switch.
The Catalyst 3900 supports the LANE standard as defined by the ATM Forum specification LAN Emulation over ATM Version 1.0, ATM_FORUM 94-0035. This service emulates the following LAN-specific characteristics:
LANE service provides connectivity between ATM-attached devices and LAN-attached devices. This includes connectivity between ATM-attached stations and LAN-attached stations as well as connectivity between LAN-attached stations across an ATM network.
Because LANE connectivity is defined at the MAC layer, upper protocol layer functions of LAN applications can continue unchanged when the devices join ELANs. This feature protects corporate investments in legacy LAN applications.
An ATM network can support multiple independent ELANs. Membership of an end system in any of the ELANs is independent of the physical location of the end system.
Up to 256 ELANs can be set up in an ATM switch cloud. A Catalyst 3900 ATM module can participate in up to 63 of these ELANs.
LANE is defined on a client-server LAN model, as follows:
The Catalyst 3900 ATM module currently supports only the LEC function. A Cisco 7000, Cisco 7200, Cisco 7500, RSP 7000, Cisco 4500, Cisco 4700, or Catalyst 5000 with an ATM Interface Processor (AIP) can supply all LANE functions.
Communication among LANE components is typically handled by several types of SVCs. Some SVCs are unidirectional; others are bidirectional. Some are point-to-point and others are point-to-multipoint. Figure A-7 illustrates the various types of SVCs.
The following section describes various processes that occur, starting with a client requesting to join an ELAN.
The following process (illustrated in Figure A-7) normally occurs after an LEC has been enabled on the ATM module in a Catalyst 3900:
Step 1 The client requests to join an ELAN. The client sets up a connection to the LECS to find the ATM address of the LANE server for its ELAN. See the bidirectional, point-to-point link (link 1-7 in Figure A-7).
An LEC finds the LECS using the following methods in the listed order:
Step 2 The LECS identifies the LES. Using the same VCC, the LECS returns the ATM address and the name of the LES for the client's ELAN.
Step 3 The client tears down the configure direct VCC.
Step 4 The client contacts the server for its LAN. The client sets up a connection to the LES for its ELAN (bidirectional, point-to-point control direct VCC [link 1-7 in Figure A-7]) to exchange control traffic. Once a Control Direct VCC is established between an LEC and LES, it remains up.
Step 5 The LES verifies that the client is allowed to join the ELAN. The server for the ELAN sets up a connection to the LECS to verify that the client is allowed to join the ELAN (bidirectional, point-to-point server configure VCC [link 11-12 in Figure A-7]).
The server's configuration request contains the client's MAC address, its ATM address, and the name of the ELAN. The LECS checks its database to determine whether the client can join that LAN; then it uses the same VCC to inform the server whether or not the client is allowed to join.
Step 6 The LES allows or disallows the client to join the ELAN. If allowed, the LES adds the LEC to the unidirectional, point-to-multipoint control distribute VCC (link 2-8 in Figure A-7) and confirms the join over the bidirectional, point-to-point control direct VCC (link 1-7 in Figure A-7). If disallowed, the LES rejects the join over the bidirectional, point-to-point control direct VCC (link 1-7 in Figure A-7).
Step 7 The LEC sends LAN emulation address resolution protocol (LE-ARP) packets for the broadcast address, which is all 1s. Sending LE-ARP packets for the broadcast address returns the ATM address of the BUS. Then the client sets up the multicast send VCC (link 4-9 in Figure A-7) and the BUS adds the client to the multicast forward VCC (link 5-10 in Figure A-7) to and from the broadcast-and-unknown server.
On a LAN, packets are addressed by the MAC-layer address of the destination and the source stations. To provide similar functionality for LANE, MAC-layer addressing must be supported. Every LEC must have a MAC address. In addition, every LANE component (server, client, BUS, and configuration server) must have a unique ATM address.
All LECs on the same interface have a different, automatically assigned MAC address. That MAC address is also used as the end-system identifier part of the ATM address, as explained in the following section.
A LANE ATM address has the same syntax as an NSAP rather than E-164. It consists of the following:
The Catalyst 3900 ATM module uses ILMI registration to build its ATM address and to register this address with the ATM switch. To build its ATM address, the Catalyst 3900 obtains its ATM address prefix from the ATM switch. Then it combines the ATM address prefix with its own MAC address and the selector value. As an alternative, you can hard-code the address. Once the Catalyst ATM module has determined its ATM address, it uses ILMI to register this address with the ATM switch.
As communication occurs on the ELAN, each client dynamically builds a local LE-ARP table. The LE-ARP table maps ELAN MAC addresses (Layer 2) to ATM addresses (also Layer 2). A client's LE-ARP table can also have static, preconfigured entries. The LE-ARP table maps MAC addresses to ATM addresses.
When a client first joins an ELAN, its LE-ARP table has no dynamic entries and the client has no information about destinations on or beyond its ELAN. To learn about a destination when a packet is to be sent, the client begins the following process to find the ATM address corresponding to the known MAC address:
Step 1 The client sends an LE-ARP request to the LANE server for this ELAN (point-to-point control direct VCC [link 1-7 in Figure A-7]).
Step 2 If the MAC address is registered with the server, it returns the corresponding ATM address. If not, the LES forwards the LE-ARP request to all clients on the ELAN (point-to-multipoint control distribute VCC [link 2-8 in Figure A-7]).
Step 3 Any client that recognizes the MAC address responds with its ATM address (point-to-point control direct VCC [link 1-7 in Figure A-7]).
Step 4 The LES forwards the response (point-to-multipoint control distribute VCC [link 2-8 in Figure A-7]).
Step 5 The client adds the MAC address-ATM address pair to its LE-ARP cache.
Step 6 Now the client can establish a VCC to the desired destination and proceed to transmit packets to that ATM address (bidirectional, point-to-point data direct VCC [link 6-6 in Figure A-7]).
For unknown destinations, the client sends a packet to the BUS, which forwards the packet to all clients in the ELAN. The BUS floods the packet because the destination might be behind a bridge that has not yet learned this particular address.
The Catalyst 3900 allows you to define up to 64 traffic profiles. These profiles can be used to define the maximum rates for each traffic type. The traffic profiles are defined on the Traffic Profile Table Setup panel. Refer to "Configuring Traffic Profiles Tables" section of the "Configuring the Catalyst 3900"chapter for more information.
For each VLAN (or ELAN), a traffic profile must be mapped to each DD-VCCs. The process of mapping depends on whether the traffic is incoming or outgoing:
When an LEC has broadcast or multicast traffic, or unicast traffic with an unknown address to send, the following process occurs:
Step 1 The client sends the packet to the BUS (unidirectional, point-to-point multicast send VCC [link 4-9 in Figure A-7]).
Step 2 The BUS forwards (floods) the packet to all clients (unidirectional, point-to-multipoint multicast forward VCC [link 5-10 in Figure A-7]).
This VCC branches at each ATM switch. The switch forwards these packets to multiple outputs. (The switch does not examine the MAC addresses; it simply forwards all packets it receives.)
The Catalyst family of switches provides a means of multiplexing VLANs between switches and routers using ISL on Fast Ethernet or LAN emulation on ATM. You can use any combination of these trunk technologies to form enterprise-wide VLANs.
A trunk is a physical link that carries the traffic of multiple VLANs between two switches or between a switch and a router, thereby allowing the VLANs to be extended across switches. Trunks use high-speed interfaces such as Fast Ethernet, Fiber Data Distributed Interface (FDDI), or ATM.
ISL was originally developed for Ethernet switches. It uses a Fast Ethernet interface to provide connectivity between switches and extends the VLAN capabilities of the switch by tagging the standard Fast Ethernet frame with the necessary VLAN information. Like ATM, ISL can provide a high-speed link between switches. Unlike ATM, however, ISL forwards the data across the high-speed link without breaking the frames into cells. The frame is sent intact across the ISL connection.
The Token Ring implementation of ISL encapsulates Token Ring frames in Fast Ethernet frames.
To accomplish this, the STP 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 STP 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 STP that runs on a bridge depends on the transmission mode of the bridge connection (whether the connection is transparent, SRB, source-route switching, or SRT).
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 STP. As discussed in the "VLAN Trunking Protocol" section, in a Token Ring switch, there are two levels of VLANs. The grouping of ports (TrCRFs) is connected by logical bridges (TrBRFs).
Therefore, in a Token Ring switched network, to ensure loops are removed from the topology you must configure a separate STP for each logical bridge (TrBRF) and for each of the port groupings (TrCRF) configured for a VLAN.
The following is a general summary of how the STP eliminates loops in the network:
The first 2 bytes are a priority field, and the last 6 bytes contain one of the bridge's MAC addresses. The bridge with the lowest bridge identifier among all bridges on all LAN segments is the root bridge. The network administrator can assign a lower bridge priority to a selected bridge to control which bridge becomes the root, or the administrator can use default bridge priorities and allow the STP to determine the root.
The path cost represents the cost of transmitting a frame to a bridged segment through that port. A network administrator typically configures a cost for each port based on the speed of link (for example, the cost of a port connected to a 16-Mbps LAN could be assigned a lower path cost than a port connected to a 4-Mbps LAN).
3. Each bridge determines its root port and root path cost.
The root port is the port that represents the shortest path from itself to the root bridge. The root path cost is the total cost to the root. All ports on the root bridge have a zero cost.
4. All participating bridges elect a designated bridge from among the bridges on that LAN segment.
A designated bridge is the bridge on each LAN segment that provides the minimum root path cost. Only the designated bridge is allowed to forward frames to and from that LAN segment toward the root.
5. All participating bridges select ports for inclusion in the spanning tree.
The selected ports will be the root port plus the designated ports for the designated bridge. Designated ports are those where the designated bridge has the best path to reach the root. In cases where two or more bridges have the same root path cost, the bridge with the lowest bridge identifier becomes the designated bridge.
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 STP calculation requires that bridges communicate with other bridges in the network that are running the STP. 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.
Figure A-8 shows the format of the fields inside a BPDU.
| 2 | 1 | 1 | 1 | 8 | 4 | 8 | 2 | 2 | 2 | 2 | 2 |
|---|---|---|---|---|---|---|---|---|---|---|---|
Protocol Identifier | Version | Message Type | Flags | Root ID | Root Path Cost | Bridge ID | Port ID | Message Age | Maximum Age | Hello Time | Forward Delay |
Protocol Identifier---Identifies the protocol. This field contains the value zero.
Version---Identifies the version. This field contains the value zero.
Message Type---Identifies the message type. This field contains the value zero.
Flags---1-byte field, of which only the first two bits are used. The topology change (TC) bit signals a topology change. The topology change acknowledgment (TCA) bit is set to acknowledge receipt of a configuration message with the TC bit set.
Root ID---Identifies the root bridge by listing its 2-byte priority followed by its 6-byte ID.
Root Path Cost---Cost of the path from the bridge sending the configuration message to the root bridge.
Bridge ID---Priority and ID of the bridge sending the message.
Port ID---Port number (IEEE or Cisco STP BPDU) or the ring and bridge number (IBM STP BPDU) from which the configuration message was sent. This field allows loops created by multiple attached bridges to be detected and corrected.
Message Age---Indicates the amount of time that has elapsed since the root sent the configuration message on which the current configuration message is based.
Maximum Age---Indicates when the current configuration message should be deleted.
Hello Time---Indicates the time between root bridge configuration messages.
Forward Delay---Indicates the length of time that bridges should wait before transitioning to a new state after a topology change. If a bridge transitions too soon, it is possible that not all network links will be ready to change their state, and loops can result.
The Catalyst 3900 supports the following STPs:
The following sections briefly describe the type of transmission mode supported by each STP.
The IEEE 802.1d STP BPDU format is:
Destination Address | Source Address | SAP | BPDU |
When a bridge connection is transparent mode:
When a bridge connection is source-route switching:
When a bridge connection is source-route transparent:
When a bridge connection is source-route:
The IBM STP BPDU format is:
Destination Address | Source Address | SAP | BPDU |
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 STP, 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 STP was used as a basis to create the Cisco STP. The Cisco STP ensures that traffic from one physical ring of a VLAN is not blocked from the other physical rings that comprise the VLAN.
Table A-1 summarizes the activities occurring in the TrCRF and TrBRF when the Cisco STP is run.
| TrCRF Bridging Mode | TrCRF | TrBRF |
SRB |
|
|
SRT |
|
|
The Cisco STP BPDU format is:
Destination Address | Source Address | RIF | SAP | BPDU |
For each BPDU format:
For the Cisco STP BPDU format, the source address must have the "msp masked" on to indicate the presence of a RIF in the header. The information carried in the RIF for the Cisco STP BPDU is a 2-byte field and must be set to 0x0200.
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:
Posted: Tue Oct 12 11:57:44 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.