Novell is now a part of Micro Focus

Source Routing and the Spanning-Tree Protocol

Articles and Tips: article

ROBERT L PERRY
Senior Technical Writer
Systems Engineering Division

PAUL TURNER
Senior Consultant
Systems Engineering Division

01 Aug 1991


This AppNote describes how source-routing bridges implement the IEEE 802.1D spanning-tree protocol. It covers both manual and automatic creation of a single route in a bridged network, and explains how bridges in automatic mode determine which role to assume: root, designated, or standby. Several examples show how to apply this information to reduce traffic on Token-Ring networks. Also included is a description of the fields in the Bridge Protocol Data Unit. This is the second AppNote in a series on source routing.

Introduction

The purpose of this AppNote is to describe important design considerations for Token-Ring networks where source routing is used. This document relies on a basic knowledge of source routing principles, which are discussed in detail in the first AppNote of the series on this subject ("Understanding Token-Ring Source Routing," in the May 1991 issue of NetWare Application Notes).

Where the first AppNote showed how source routing frames travel between stations over the network (including frame structure, route determination processes, and how bridges pass frames), this AppNote explains how to configure bridges to expand or restrict available routes and adapt to the dynamic climate of the network by using the spanning-tree protocol. It also gives several examples of bridge operation.

This information is most valuable to people who are designing, implementing, and administering complex Token­Ring networks. A future AppNote on this subject will include specific implementation notes for source routing in a NetWare environment.

The information for this AppNote came from various publications (listed at the end of the AppNote) and from interviews with engineers and consultants familiar with source routing in the Token-Ring environment.

The Importance of Network Design

Two important considerations in designing a network should be (1) the efficiency of traffic routing over the network; and (2) tolerance to failures of individual components. On a source-routing network, the work of determining routes is distributed among individual stations, with source-routing bridges passing the frames to adjoining rings when necessary. Unfortunately, the route determination process can create significant amounts of traffic, especially in poorly built networks. Source-routing bridges, when placed and configured effectively by an administrator, can help keep route determination traffic to a minimum when single-route bridges are employed on a network.

Two Methods for Route Determination

As we explained in the previous AppNote, there are two methods for route determination in source-routing networks. Both methods may be used by different stations on the same network. In the single-route method, broadcast frames designated as single-route frames are passed around the network only by single-route bridges (bridges with single-route forwarding mode set to active). This method creates only the number of broadcast frames on the destination ring as there are single-route bridge paths to that ring.

In the all-routes method, by contrast, broadcast frames designated as all-routes frames are passed around the network by all bridges. This method creates the same number of broadcast frames on a destination ring as there are routes to that destination from the sourceCas well as additional frames on the other rings on the network (this is often called a "broadcast storm").

The duplication of frames in the all-routes method can increase route determination traffic on some networks to the point of significantly degrading network performance. To reduce the route determination traffic, single-route bridges may be used in conjunction with workstations that use the single-route broadcast method.

Reducing Route Determination Traffic

The following example will show the need to restrict route determination traffic on complex networks.

Figure 1: A physical network with 9 rings and 12 bridges.

In this type of network, an all-routes route determination broadcast originating on Ring 7 would produce progressively more copies of the same broadcast frame as it traveled toward the farthest ring on the network.

To get an idea of the number of frames that can result, look at the number of unique paths between Ring 7 and Ring 3, shown in Figure 2.

Figure 2: The number of unique routes between Ring 7 and Ring 3.

As the original all-routes broadcast frame is issued, each bridge copies the frame to its other ring unless the frame has already been on that ring. The result is a frame whose copies "fan out" over the network as shown in Figure 3.

Figure 3: Copies of the original frame are duplicated on each ring.

In this example, Ring 3 receives 12 copies of the frame because there are 12 unique routes between Ring 7 and Ring 3. This number assumes the IEEE 802.1D hop count limit of 13 bridges.

The most common maximum hop count, used in bridges from IBM and other manufacturers, allows up to seven bridges. Using IBM bridges would thus reduce from 12 to 10 the number of all-routes broadcasts reaching Ring 3, since there would then be only 10 unique routes (of seven hops or fewer) between Ring 7 and Ring 3 (routes 11 and 12 in Figure 2 cross eight bridges).

That's still quite a bit of traffic for one station to merely ask for the location of another station on the network. Imagine the impact on network bandwidth when this amount of traffic is multiplied by many times on a large, busy network. Especially during the beginning of a work shift or after a power outage when workstations are reattaching to network resources, route determination traffic can create a broadcast storm that impairs throughput.

The number of copies of broadcast frames in the figure above illustrates the importance of maintaining some kind of control over the amount of route determination traffic on the network. Reducing the number of bridges is one way to control broadcast traffic, but a more flexible way is to have some of the bridges operate in single-route broadcast mode and have workstations use the single-route method of route determination.

Your goal is to configure the bridges in such a way that you have a logical single route between each ring, as shown below.

Figure 4: The goal of network design is to create a logical single route to each ring for the network in Figure 1. is to create a logical single route to each ring for the network in

This logical configuration is called a "spanning tree" configuration. Note that Bridges 4, 6, 7, and 8 (which are shown in Figure 1) aren't part of the single-route view of the network; these bridges would forward only all-routes and specifically routed broadcast frames.

Two Ways of Creating a Single-Route Network

There are two ways to configure the bridges to form a single route through the network. The manual method requires the administrator to figure out the single route and set the bridges according to that plan. The automatic method allows bridges to create the single path themselves using the spanning-tree protocol. The following sections explain the advantages and disadvantages of each method.

Creating the Single Route Manually

After deciding which bridges will participate to form a single route connecting all rings, you can manually create this logical single route through the network by configuring the bridges as follows. You can set each source routing bridge to either forward single route broadcast frames or not forward them. How this is done depends on the design of the bridge software or firmware. Since the IBM bridge is widely used in Token-Ring installations, we will use it as an example.

By default, an IBM bridge will come up in manual mode with single-route broadcast active in both directions. That is, it will forward to its other segment (in either direction) any frame marked as a single-route broadcast. The screen below shows the "Single-route broadcast selection mode" screen (the third screen) from the IBM bridge configuration program v2.1. The settings shown below reflect the default bridge settings for manual mode.

Figure 5: Settings for an IBM bridge in manual mode.

LAN Segment 001    LAN Segment 002
Single-route broadcast . . . . . [Y]   [Y]    (Y=Yes, N=No)

On a bridge set to manual mode, you can shut off single-route frame forwarding from one side of the bridge by selecting "N" in the panel shown above. When single-route broadcast is turned off for one segment, the bridge will not forward single-route frames received from that segment. If single-route broadcast is turned off for both segments, the bridge will not forward single-route frames received from either segment. In either case, the bridge will continue to forward all-routes broadcast frames and specifically routed frames received from either segment. In this AppNote, we will look only at those cases where forwarding is set the same for both segments (both "Yes" or both "No").

Bridges using manual mode do not "talk" to each other as bridges using automatic mode do. Also, bridges in automatic mode can't detect the single-route forwarding mode of manual-mode bridges. Because of these incompatibilities, you should set all bridges to manual mode if one or more need to be in manual mode. This prevents two problems:

  • having no single route where there should be one

  • having duplicate "single" routes where there should be just one (this defeats the purpose of the single-route view of the network)

In the case of IBM bridges, the second problem can be caused by letting some or all bridges come up at the default (manual mode, single-route broadcast forwarding active). In simple networks where there are no parallel bridges or parallel paths, this is not a problem. In the mesh network example in Figure 1, however, it would allow as many "single" routes through the network as an all-routes broadcast frame would follow.

When parallel bridges are used in conjunction with the manual mode, configure them so that one bridge will forward single-route broadcast frames and one bridge will not. You can do this manually on one of the bridges by selecting "N" for each segment for that bridge (see Figure 5). This method is straightforward, but requires manual intervention by an administrator when single-route bridges on the network fail. As a result, the manual method does not allow designs that tolerate bridge failure.

Creating the Single Route Automatically

The automatic mode, or spanning-tree operation, provides a more efficient and dynamic way to use the single-route broadcast selection feature, because automatic-mode bridges will reconfigure themselves automatically when other bridges fail. By configuring source-routing bridges in this way, they can automatically create a single route through the network. As other bridges go down or come up, all bridges on the network adapt to take advantage of the best available single route. There are two main advantages to using this spanning-tree mode of operation:

  • broadcast traffic is reduced to a minimum (one frame per ring for each single-route broadcast)

  • backup routes are used when primary routes go down because of failure or network maintenance

One risk of using the spanning-tree protocol is that stations on two rings that are close together can become "separated" by additional bridges if the logical single route on the network does not use the most direct path between those particular rings. (For example, look at Rings 4 and 5 in Figure 4.)

This risk can be reduced in two ways: (1) by designing your network with backbones; or (2) by having stations respond to single-route broadcast frames via all-routes broadcast, allowing the stations that have been logically separated to determine the faster, more direct routes (although in larger networks with multiple paths, the all-routes responses will increase network traffic). How the responses are sent is dependent on the implementation of the software in the stations involved.

The Spanning-Tree Protocol

The spanning-tree protocol of source-routing bridges is similar to a pecking order, or dominance hierarchy in the animal kingdom. In a sense, all source-routing bridges aspire to be single-route bridges, which forward all-routes frames, specifically routed frames, and, of course, single-route frames. But each bridge will yield according to the dynamics of the spanning-tree protocol, and stop forwarding single-route frames when required by the protocol. As in the animal kingdom, there is a dominant member of the "pack" among source-routing bridges: the root bridge. All measurements of timing on the network are made from the root bridge outward.

For the spanning-tree protocol to work, bridges must be set to automatic ingle-route broadcast selection mode. When a bridge is in automatic mode, it communicates with other bridges in the network to determine whether it should set both of its ports to single-route broadcast active or inactive. (In manual mode, by contrast, the ports may be set independently of each other.) On an IBM bridge, automatic mode is set as shown in Figure 6, taken from the IBM bridge configuration program (the third screen). The settings shown are those displayed by the program when you select "A" (Automatic) as the single-route broadcast selection mode. The settings shown for "Bridge label" and "Path cost increment" are the defaults when automatic mode is selected.

Figure 6: Settings for an IBM bridge in automatic mode.

Single-route broadcast selection mode..  [A]  (M=Manual, A=Automatic)
Bridge Label . . . . .  [8000]      (0000-FFFF Hexadecimal)
Path cost increment. .  [00000000]  (00000000-FFFFFFFF Hexadecimal)

The "bridge label" and "path cost increment" parameters determine which paths on the network will form the logical single route, or spanning-tree. Both can be adjusted by an administrator, but the network can determine a single path from the default configuration of these parameters. The two-byte "bridge label" has a default value of 8000. The default path cost appears as 0 at bridge setup time. In actual operation, this parameter will change depending on the microcode level (version) of the adapter or, for remote bridges, the speed of the line the bridges are connected to. If you change this value in the bridge configuration program to a non-zero number, that value will override the values that the bridge program would otherwise calculate and insert automatically.

Three Roles for Bridges

Depending on the combination of the values of these parameters, a bridge in automatic mode will assume one of three roles.

The Root Bridge. The root bridge has several characteristics:

  • It is unique on the network-each network has only one root bridge.

  • It is the active bridge on the network with the lowest "bridge ID" (bridge ID is a unique number, which is explained below).

  • It has single-route broadcast active in both directions.

  • It is the point from which all designated bridges (bridges designated to form the single route) are assigned on the network.

The Designated Bridge. In a larger network where automatic mode is used, a combination of root, designated, and standby bridges may exist. A designated bridge is the bridge designated to pass single-route frames between two particular rings. (A root bridge is similar in this sense, though it has the unique responsibility of coordinating all of the bridges.) The designated bridge has several characteristics:

  • It cannot be directly parallel to the root bridge (any automatic-mode bridge parallel to the root would become a standby bridge instead).

  • It has single-route broadcast active in both directions.

  • When parallel bridges or parallel paths are used, this bridge is the one "designated" to be the single-route path.

The Standby Bridge. The characteristics of a standby bridge are as follows:

  • A standby bridge has single-route forwarding inactive in both directions.

  • When parallel bridges or parallel paths are used, this bridge is in standby mode as a backup single route to a root bridge or a designated bridge.

The three kinds of bridges pass the frame types shown below.

Figure 7: Bridge roles and the frame types forwarded in each role.


BridgeRole
FrameType Forwarded

Single-Route

All-routes

Specificallyrouted

Root

YES

YES

YES

Designated

YES

YES

YES

Standby

NO

YES

YES

Determining Who's Who

The dominance hierarchy of bridges is made possible by a few numbers maintained by each bridge. The bridges simply tell each other their numbers, and the pre-programmed "instinct" takes over, putting each bridge in the correct mode. The following sections describe the most important of these numbers.

Bridge ID Number. The bridge ID is a hexadecimal number formed from a concatenation of the bridge label (shown as 8000 in the IBM bridge program screen shown above) and the adapter address of the adapter connected to the lowest-numbered ring. The example below shows how bridge IDs are formed and used to determine the pecking order of bridges.

Figure 8: Two parallel bridges use bridge ID numbers to determine which should be the root bridge and which should be a standby bridge.

In this example, both Bridge 1 and Bridge 2 are connected to Rings 1 and 2. The bridge ID for Bridge 1 is the bridge label (80 00) followed by the adapter address of the adapter connected to the lowest-numbered ring.

In Figure 8, the lowest-numbered ring is Ring 1 and the address of the adapter connected to it is 10 00 5A 60 10 6A. The complete bridge ID is, therefore,

80 00 10 00 5A 60 10 6A.

Using the same procedure, Bridge 2's bridge ID would be

80 00 10 00 5A 60 10 6B.

When the bridges come up, each initially assumes that it is the root. After broadcasting its bridge ID using the spanning-tree protocol, and listening for similar broadcasts from the other bridge, each bridge is able to determine which role to fill. Bridge 1 assumes the role of root bridge because its bridge ID is the lowest on the network (80 00 10 00 5A 60 10 6A is less than 80 00 10 00 5A 60 10 6B); it switches to single-route broadcast active mode. Bridge 2 becomes a standby bridge.

Although the bridge label is the most significant value in the bridge ID, the adapter address portion of the bridge ID can act as a tie-breaker in case the bridge labels are identical. When universal addressing is used, the adapter addresses are guaranteed by IEEE to be unique.

Because the root bridge should be centrally located on the network (to provide the shortest path to all rings), its selection should not be left to chance. If bridge labels are left to the default setting (80 00), one bridge's ID (for example, 80 00 10 00 5A 60 10 6A) is distinguished from another bridge's ID (say 80 00 10 00 5A 60 10 6B) only by the adapter address, which means the selection of the root bridge is as random as the installation of the adapters in the bridges.

One way around this randomness would be to use locally administered addresses on the network (rather than hard-coded universally administered addresses), but a more efficient way is to adjust the bridge label itself, which contains the most significant digits in the bridge ID.

Calculating Path Cost Numbers. Once the root bridge is determined, all of the other bridges will negotiate with each other to determine which will be designated and which will be standby. The role of designated bridge is assumed by (1) the bridge with the lowest path cost to the root bridge; or (2) the bridge with the lowest bridge ID (if path costs are equal).

All path cost calculations are made from root bridge outward. You can manually assign a path cost to a bridge, or the bridge software or firmware may calculate a path cost. It is up to the bridge vendor to determine what values to assign for path costs. As a general rule, though, the current path cost at any bridge is the sum of the path costs of all bridges between it and the root bridge (the path cost of the root bridge is always 0).

The Bridge Protocol Data Unit

Under the IEEE 802.1D definition, the root bridge on a network periodically sends a message from both of its adapters to the attached rings. This message is called a "Hello" Bridge Protocol Data Unit, or BPDU. It is also referred to as a Configuration BPDU, and is the basis of the spanning-tree protocol.

The IEEE specification dictates that these messages be sent every 1 to 10 seconds. (IBM bridges send this message every 2 seconds.) As a BPDU leaves the root bridge, it contains the bridge ID of the root bridge, a path cost of zero, and some timing information (timing information is explained in more detail in the appendix).

Each BPDU originated by the root bridge is received first by any designated and standby bridges also attached to the two rings connected by the root bridge.

After receiving and monitoring the BPDU, each designated bridge updates the path cost and timing information in the BPDU and transmits the updated BPDU out the adapter connected to its other ring. The reason that designated and standby bridges monitor BPDUs is so that they can assume different bridge roles if necessary: the BPDUs contain the information they need to determine whether to change roles. The example under "How Path Costs Add Up" shows how this information travels around the network.

Spanning-Tree Protocol Examples

To tie this all together, let's look at two examples of the spanning-tree protocol in action. In the first example (shown in Figure 9), we will assume that Bridge 1 has the lowest bridge ID, and that Bridge 6 has a higher path cost than Bridge 4.

Figure 9: Bridge operation with the spanning-tree protocol.

Bridge 1 becomes the root bridge because it has the lowest bridge ID on the network. If all other bridges use the default bridge label of 8000, changing Bridge 1's label to 7999 would guarantee its root bridge assignment, since the first group of digits in the bridge ID (taken from the bridge label) are the most significant. As the root bridge, Bridge 1 has the responsibility of sending a "hello" message periodically to both segments it is attached to. (In the case of IBM bridges, this occurs every 2 seconds.)

Bridge 2 becomes a standby bridge because it is parallel to the root bridge. A standby bridge is only in standby mode as far as forwarding single-route frames is concerned; it still forwards all-routes frames and specifically routed frames. A standby bridge has the responsibility to monitor the "hello" messages from the root bridge in case a change takes takes place, such as the root bridge going down. Standby bridges do not update or forward these messages to other rings, as a designated bridge does.

Bridge 3 becomes a designated bridge because it is not parallel to any bridge and because it is the only path to Ring 3. A designated bridge is responsible to receive, update, and forward the "hello" messages from the root bridge. These messages may travel from the root bridge through several designated bridges before reaching the last designated bridge.

Bridge 4 becomes a designated bridge because its path cost to Ring 4 from the root bridge is less than the higher path cost assigned to Bridge 6. (If the path cost of Bridge 4 were equal to the path cost of Bridge 6, then the bridge with the lowest bridge ID of the two would become the designated bridge.)

Bridge 5 becomes a designated bridge because it is not parallel to any bridge (the same as with Bridge 3) and because it is the only path to Ring 5.

Bridge 6 becomes a standby bridge because it was assigned a higher path cost for frames traveling from the root bridge to Ring 4.

When Bridges Go Down

The bridge roles described above assume that all bridges are functioning normally. In the case of a particular bridge being removed from the network or failing altogether, the other bridges on the network may switch roles. Figure 10 shows what happens to the logical single route if Bridges 1 through 6, in turn, are removed from the network.

Figure 10: How the bridges reconfigure themselves when one goes down.

Tracing the dynamics of what happens on a network when each bridge goes down can emphasize the strong and weak points of the network design. In the examples above, it is obvious that if either Bridge 3 or Bridge 5 goes down, Ring 3 or Ring 5, respectively, are cut off completely from the network. If the physical cabling situation permitted, adding a bridge between Rings 3 and 5 would solve this situation.

The number of hops between two given rings will also change as bridge roles change. In the example above, there is only one hop between Ring 1 and Ring 4 during normal bridge operation. However, if Bridge 4 goes down, the number of single-route hops between Ring 1 and Ring 4 doubles to 2. In this situation, the number of hops between Ring 1 and Ring 5 would also change, from 2 to 3.

In a small 4-ring, 6-bridge test network using IBM bridges (286 CPUs) with little additional traffic, we observed a network-wide bridge reconfiguration time of 8 seconds when a new root bridge was brought up or the current root was brought down. We mention this not as a benchmark, but to give a rough feel for the time involved for bridges to re-establish their pecking order when the current hierarchy is modified.

How Path Costs Add Up

In our second example of the spanning-tree protocol, we look more closely at how path costs are used by each bridge to determine which role to take.

In Figure 11, five rings (001 through 005) are joined in a network by five bridges (A through E). Each of the bridges has been assigned a specific bridge label and path cost, as shown.

Figure 11: Bridge labels and path cost assignments.

When these bridges are first brought up, they communicate using BPDUs to determine which bridge will be the root and which other bridges will be designated or standby bridges.

Figure 12 below shows (1) the direction of travel of the BPDUs; and (2) a portion of the BPDUs that are sent out once the root bridge has been established. (For simplicity, these partial BPDUs identify a bridge by its bridge number rather than its lengthy bridge ID.)

Figure 12: BPDUs travel from the root bridge outward.

The sequence of events proceeds as follows:

  1. After establishing itself as the root bridge (because it has the lowest bridge ID on the network), Bridge A sends a BPDU onto each of its connected rings. These BPDUs indicate (among other things) that Bridge A is the root bridge, that the path cost from the root to Ring 1 or 5 is zero, and that Bridge A sent this BPDU.

    In Figure 11, the path cost shown for Bridge A is 28. But when Bridge A becomes the root bridge it begins sending out a path cost of zero. This behavior can be likened to that of a human being hiding his or her age. The root bridge still knows its "real" path cost (28 in this example), in case it later needs to change roles and use that path cost again.

  2. Bridge B receives the BPDU on Ring 001. It then assumes the identity of designated bridge, adds its information to the BPDU, and sends the BPDU onto Ring 002. This new BPDU indicates that the current root bridge is Bridge A, that the cumulative path cost from the root to Ring 002 via Bridge B is 28, and that Bridge B sent the BPDU. (The new path cost is derived by adding up the path costs from Bridge B back to the root: 28 + 0 = 28).

  3. Bridge E (as with Bridge B) receives the BPDU from Bridge A on Ring 005. It also assumes a designated bridge identity, adds its information to the BPDU, and sends the BPDU onto Ring 004. This new BPDU indicates that the current root bridge is Bridge A, that the cumulative path cost from the root to Ring 004 via Bridge E is 40 (40 + 0), and that Bridge E sent the BPDU.

  4. In a similar fashion, Bridge C receives the BPDU from Bridge B on Ring 002 and becomes a designated bridge. Before passing the BPDU on to Ring 003, Bridge C adds its own path cost of 28 to the cumulative path cost. This results in a new cumulative path cost of 56 (28 + 28 + 0 = 56.)

  5. When Bridge D receives the BPDU from Bridge E, it also assumes it will be a designated bridge and adds its path cost to the cumulative total. Thus the BPDU it sends onto Ring 003 contains a cumulative path cost of 60 (20 + 40 + 0 = 60).

  6. At this point, Bridge C and Bridge D receive BPDUs from each other. When Bridge C examines the BPDU sent by Bridge D, it sees that the path cost from Ring 003 to the root through Bridge D is 60. Since this is higher than its own path cost of 56 from Ring 003 to the root, Bridge C remains in designated mode. Bridge D, however, determines from the BPDU it received from Bridge C that Bridge C has a lower path cost to Ring 003 from the root. Therefore, Bridge D puts itself into standby mode.

The logical single-route network that results from this BPDU communication between bridges is shown in Figure 13.

Figure 13: Logical single route after the bridges exchange BPDUs.

Applying What You've Learned

Although the network design in Figure 13 illustrates the mechanics of the spanning-tree protocol, it does not readily lend itself to efficient network operation. Nodes on Rings 003 and 004 must traverse four bridges to communicate with each other.

A more efficient network configuration is a single backbone or dual backbone network as shown in Figure 14.

Figure 14: Single and dual backbone networks.

The use of backbones reduces the average number of hops between all rings on a network. The single backbone is more common where network cost must be low. This configuration, though efficient, is prone to lost or interrupted network service when ring and bridge failures occur. The dual backbone configuration provides greater fault tolerance and possible load balancing. However, manual or automatic bridge configuration must be used to reduce the number of single routes through a network of this type.

By using automatic mode for the bridges and adjusting the bridge label and path cost parameters, several single-route configurations are possible with the dual backbone. Figure 15 shows two of these configurations.

Figure 15: Two possible single-route configurations.

In both configurations, Bridge 1 is configured as the root bridge by reducing its bridge label. In the first configuration, the path cost for Bridges 6, 7, 8, and 9 is increased so that these bridges become standby bridges. Consequently, Bridges 2, 3, 4, and 5 will be designated bridges. In the second configuration, Bridges 3, 5, 6, and 8 are configured for standby operation and Bridges 2, 4, 7, and 9 are configured for designated bridge operation (again by adjusting the path cost).

The advantage to both configurations shown in Figure 15 is the reduction of single-route broadcast traffic on the network. A single-route broadcast packet originating on any ring will yield only one copy of that packet on all other rings. The choice of which configuration would be best for a particular environment depends on the environment itself.

If workstations use single-route broadcasts to find servers, and servers respond with specifically routed packets, then the choice of configuration is important. With servers set to respond this way in the configuration on the left, all traffic is concentrated over Ring A. However, there is a maximum of two hops between any two rings on the network. In the configuration on the right, the traffic is split between Ring A and Ring F. The drawback to this configuration is that some rings are separated by three hops (for example, Ring B and Ring E).

On the other hand, if workstations use single-route broadcasts to find servers, and servers respond with all-routes broadcasts, the choice of configuration is not as important. With the servers configured this way, a workstation can choose the optimal route (shortest number of hops) to the server. This route might be over Ring A or Ring F, depending on which is less busy. This balances the load between the two backbones. The one drawback to having servers respond with all-routes broadcasts is the traffic that the responses create on the network.

Conclusion

Creating an effective single route for route determination broadcasts is possible for an administrator to do manually, but often requires further manual intervention when bridges on the network fail. The dynamics of automatic-mode operation can provide a network which handles route determination efficiently and forms a resilient route structure that is not paralyzed when a bridge fails.

Complexity is the price of having a network that quickly adapts to topology changes. Though most of this complexity is handled automatically by the bridges, the administrator must understand the key features of source-routing bridges presented in this AppNote. A working knowledge of bridge IDs and path costs, and how the bridges use these to communicate their status to each other, will help you keep the intended root bridge centrally located and ensure that cumbersome routes do not develop when a given bridge fails.

For additional information about source routing and the spanning-tree protocol, we recommend the following reference material (the IBM titles are available from an IBM Representative or IBM Branch Office):

Bridge Program User's Guide (this guide accompanies the IBM Token-Ring Network Bridge Program, Version 2.1). IBM part number 16F0493.

IBM Cabling System Planning and Installation Guide. IBM part number GA27-3677.

IBM Local Area Network Administrator's Guide. IBM part number GA27-3748.

IBM Local Area Network Technical Reference. IBM part number SC30-3383.

IBM Token-Ring Architecture Reference, pp. 2-5 through 3-10. IBM part number SC30-3374-02.

IBM Token-Ring Network Introduction and Planning Guide. IBM part number GA27-3677.

IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges (Std 802.1D-1990). IEEE part number SH13565, ISBN 1-55937-055-6.

IEEE Standards for Local Area Networks: Token Ring Access Method and Physical Layer Specifications (ANSI) (Std 802.5-1989). IEEE part number SH12609, ISBN 1-55937-012-2.

Appendix: Structure of the BPDU

The following figure and table provide an explanation of the individual fields of the "Hello," or Configuration BPDU used by bridges communicating with the 802.1D-1990 spanning-tree protocol.

The BPDU is held in the Information Field of the Token-Ring frame, and no source routing information is contained in a frame that holds a BPDU. The Destination Address of the MAC header of the BPDU contains the bridge functional address of C0 00 00 00 01 00, which is an address common to all bridges.

Figure 16: The Bridge Protocol Data Unit (BPDU).

Figure 17: Explanation of BPDU fields.


Field
Purpose
Explanation

Protocol Identifier

Identifiesthe spanning-tree algorithm and protocol.

Bridges operatingin automatic mode will always send BPDUsbeginning with a two-byte hexadecimal 0000.

ProtocolVersion Number

Identifiesthe protocol version number currently in use.

This fieldtakes the one-byte hexadecimal value of 00for version 0 of the 802.1D-1990 standard.

BPDU Type

Denotesthe type of a given BPDU.

There are twoBPDU types currently defined:

The Hello, or Configuration BPDU, which is denoted with the one-byte hexadecimal value of 00 in this field;

The Topology Change Notification BPDU (described below), which is denoted with the one-byte hexadecimal value of 80(binary 10 00 00 00); it is a subset of the Hello BPDU and contains onlythe first three fields used in the Hello BPDU (Protocol Identifier, Protocol Version Number, and BPDU Type).

Flags

Thisfield can be used to convey information aboutchanging conditions on the network.

The 802.1D-1990standard currently defines two kinds of informationthat may be conveyed in this field:

TheTopology Change Flag (bit 8 ofthis octet) is set to 1 when a bridge detectsan extensionto the network (that is, whena new bridge begins sending Hello BPDUs). The byte with this flag is hexadecimal 00when no extension to the network has beendetected, and hexadecimal 80 (binary 10 00 00 00)whenan extension has been detected. A Topology ChangeNotification BPDU is sent along the path towardthe root bridge, which will eventually receive it.

The Topology Acknowledgment Flag (bit5 of this octet) is set to 1 when a bridgereceives a Topology Change Notification BPDU,and sent in a Hello BPDU by the bridge receivingthe Topology Change Notification BPDU. Thebyte with this flag is hexadecima l00 whenno acknowledgment is required, and hexadecimal08 (binary 00 00 10 00) whenan acknowledgment is necessary.

Root Identifier

Givesthe bridge ID of the bridge believed to be the root bridge.

As new bridgescome up in automatic mode on the network,each starts out by using its own bridge identifierhere. Other bridges on the network willignore this if they have received recentinformation from or about the bridge withthe lowest bridge ID on the network. Afterit receives enough information to realizethat it will not be the root bridge, thenew bridge will change this field to includethe bridge ID of the current root bridge(the bridge believed to be the root bridge).

One key to interpreting BPDUs captured from thewire by protocol analyzers is to know thetransmission order of bits in MAC addresses. The IBM bridges used for this AppNote transmiteach byte of MAC addresses in reverse bitorder from the rest of the frame, whetherthose addresses are found in the MAC headeror within the Information Field as in thecase of BPDUs. Protocol analyzers can recognizethis and reformat the addresses found withinthe MAC header; however, they cannotdo this for addresses found within the InformationField. The result is that the actual MACaddress of the adapter used in Figure 1 wouldshow in the Source Address Field as 10 00 5A 7A 93 86,but in the BPDU's adapter address portionof the bridge ID, each byte is captured justas it was transmitted, so the same addressshows as 08 00 5A 5E C9 61.

Root PathCost

Givesthe path cost from the transmitting bridgeto the root bridge.

The path costbroadcast by the root bridge in the HelloBPDUs it sends out is always 0. The pathcosts added by each bridge in the networkare assigned according to the design of thesoftware or firmware in those bridges. Thevalid range is 1 to 65535.

Bridge Identifier

Givesthe bridge ID of the bridge transmitting the BPDU.

As each bridgeencodes its own BPDUs, it includes as onenumber in this field its bridge label (2bytes) and the MAC address (universal orlocal) of the adapter connected to the ringwith the lowest number (6 bytes). A bridgeconnected to Ring 1 and Ring 2 would usethe adapter address of the adapter connectedto Ring 1.

Port Identifier

Givesthe ring number and bridge number of thebridge transmitting the BPDU.

The four hexadecimaldigits in this two-byte field give the lowestring number to which one of the bridge'sadapters is connected, followed by the bridgenumber. In the example BPDU above, hexadecimal00 12 denotes Ring 1 (001), Bridge 2.

MessageAge

Givesthe time elapsed since the BPDU was sentby the root bridge.

This two-bytevalue will be hexadecimal 00 00 whenit is sent from the root bridge. It is abase from which other bridges can measurethereliability of the information they receive. Each designated bridge in the network updatesthis timer as it relays the BPDUs receivedfrom the root bridge.

Max Age

Givesthe maximum allowed age of Hello BPDUs beforethey are discarded.

This two-bytevalue is used as a limit to maintain thebest bridge information on the network. Bridges discard a Hello BPDU when its MessageAge (described above) exceeds the Max Age. The IEEE range for this value is 6 to 40seconds; the default Max Age value for IBMbridges is 6 seconds (hexadecimal 06 00).

Hello Time

Givesthe interval between transmission of HelloBPDUs by the root bridge or a bridge attemptingto become the root.

The primaryuse for this field is to allow managementfunctions (such as the IBM LAN Network ManagerCaproduct for monitoring and managing networks)to monitor the performance of the spanning-treeprotocol. The IEEE range for this valueis 1 to 10 seconds; the default value forIBM bridges is 2 seconds (hexadecimal 02 00).

ForwardDelay

Allowsbridges to prevent temporary loops in thenetwork.

This valueis set by the root bridge and used by allbridges on the network. Its purpose is toeliminate temporary loops in the networkwhen changes in the network occur. It doesthis by forcing bridges to pause for severalseconds before they begin forwarding frameson the network. The IEEE range for thisvalue is 4 to 30 seconds; the default valuefor IBM bridges is 4 seconds (hexadecimal04 00).

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates