Intertwined with the issue of VLANs is the subject of the Spanning-Tree Protocol. In fact, it is the inappropriate use of VLANs (the flat earth theory) that most often leads to Spanning Tree problems in the first place. This section discusses some of the dos and don’ts of the Spanning-Tree Protocol.
One of the primary themes developed throughout this section is that although Spanning Tree can be quite manageable when used in conjunction with Layer 3 switching, it can also become very complex when used in large, flat designs like campus-wide VLANs. Combining good Spanning Tree knowledge with a good design is the key to success.
Keep Spanning Tree Domains Small
One of the most effective techniques for minimizing Spanning Tree problems is keeping Spanning Tree domains small in size. The easiest way to accomplish this is to use the multilayer design model. By automatically creating Layer 3 barriers that partition the network from a Spanning Tree point of view, most of the typical Spanning Tree problems become non-issues.
There are many benefits to constricting Spanning Tree to small pockets within your network, including the following:
- It allows you to safely tune the Spanning Tree timers.
- As a result, Spanning Tree convergence time can be significantly improved.
- It becomes very difficult for Spanning Tree problems in one section of the network to spread to other sections of the network.
- When using the switching router (Catalyst 8500) form of the multilayer design model, Spanning Tree load balancing can be eliminated. In this case, the IDF traffic creates Layer 2 V’s that are inherently loop free and therefore do not require the Spanning-Tree Protocol, although I recommend that you don’t disable Spanning Tree; see the next section.
If you enable bridging and/or IRB on Catalyst 8500 devices, they will starting bridging traffic and convert the Layer 2 V’s that they produce by default into Layer 2 triangles. This will obviously require the use of Spanning Tree (use of the Root Bridge placement technique discussed in the following bullet point is recommended).
- When using the routing switch (MLS) form of the multilayer design model, Spanning Tree load balancing can be dramatically simplified through the use of the Root Bridge placement technique. When using MLS and the multilayer model, each IDF and a pair of MDFs create Layer 2 triangles that, although not loop free, are easy to manage. For more information on the Root Bridge placement approach to Spanning Tree load balancing, see Chapter 7, “Advanced Spanning Tree,” and Chapter 17.
- Spanning Tree becomes much simpler to design, document, and understand.
- Troubleshooting becomes much easier.
Figure 15-7 illustrates the Layer 2 triangles created by MLS (Part A) and the Layer 2 V’s created by switching routers. Although MLS very often uses route-switch modules (RSMs), a logical representation has been used for Part A.
Figure 15-7. Layer 2 Topologies under Routing Switches (MLS) and Switching Routers
It is important to realize that both routing switches (MLS) and switching routers (8500s) can be used to create the designs shown in Figure 15-7. This section is merely trying to point out the default behavior and most common use of these platforms.
When using campus-wide VLANs, it is often possible to achieve some of the benefits listed in this section by manually pruning VLANs from selected trunks. However, it is not possible to create the simplicity and scalability that are available when using Layer 3 switching. Also, the pruning action can often reduce redundancy in the network.
The multilayer model allows the benefits listed in this section to be easily designed into the network. When using routing switches (MLS) as shown in Part A, this can be accomplished by pruning selected VLANs from key trunk links (such as links in the core and between MDF switches). When using switching routers such as the 8500 as shown in Part B, the benefits of having small Spanning Tree domains accrue by default.
Don’t Disable Spanning Tree
In frustration, many organizations disable the Spanning-Tree Protocol to achieve network stability (especially when using flat earth designs). However, when this is done at the expense of redundancy, it obviously introduces a whole new set of problems.
When Spanning Tree is disabled, you are not protected from the inevitable configuration mistakes that create Layer 2 loops in the network. As discussed in Chapter 6, Layer 2 protocols have no way of recovering from feedback loops without a protocol such as Spanning Tree (there is no Time To Live [TTL] field in Layer 2 headers)—the loop continues until you manually intervene.
Typically, Spanning Tree is disabled in one of three situations:
- As a last resort to achieve network stability under the campus-wide VLANs design model— However, because this also requires that redundancy be eliminated, this is not recommended.
- When using Catalyst 8500-style switching routers in the MDF/distribution layer closets— Because switching routers result in loop-free Layer 2 V’s (as shown in Part B of Figure 15-7), Spanning Tree is no longer required—at least for the intended topology. However, loops can be formed unintentionally through configuration and cabling mistakes on the part of network administrators or because end users installed devices such as hubs or switches. Therefore, an element of risk remains with this approach.
- When using a LANE backbone— Because LANE automatically creates a loop-free topology within the ATM core itself, Spanning Tree can be disabled. In fact, ATM-centric vendors such as Fore Systems disable Spanning Tree for LANE by default. However, you must be careful to not create Layer 2 loops outside the LANE backbone. Not only does this include the examples discussed in the previous bullet, it also includes such practices as using redundant Ethernet links to extend the ATM backbone to IDF wiring closets.
In general, it is better to use scalable design techniques and Spanning Tree tuning rather than to disable the Spanning-Tree Protocol altogether. As discussed in the previous section, designs such as the multilayer model can achieve network stability without having to resort to disabling Spanning Tree. Also, a carefully planned design can then allow Spanning Tree to be tuned for better performance.
Evaluate Spanning Tree Patterns
As discussed in Chapter 11 and Chapter 14, using Layer 3 switching and the multilayer design model generally results in networks that are comprised of many small “triangles” and “V’s” of Layer 2 connectivity.
As this material discussed, switching router platforms such as the Catalyst 8500s produce Layer 2 V’s by default. Although bridging and IRB can be enabled to convert these V’s into Layer 2 triangles, it is generally advisable to avoid widespread deployment of these features (see the section “Integration between Routing and Bridging” in Chapter 11). Therefore, you will usually see Layer 2 V’s in conjunction with switching router technology.
From a Spanning Tree perspective, it is important to note that these V’s are loop-free and therefore do not place any ports in the blocking state. As a result, Spanning Tree will not impact your failover performance.
Although Spanning Tree will not impact failover performance of the IDF uplink ports when using Layer 2 Vs, it is still enabled by default and may impact end-user devices. Therefore, you may wish to configure PortFast on end-user ports to facilitate start-up protocols such as DHCP and NetWare authentication.
Unlike 8500s where Layer 2 V’s are far more common, MLS (and routing switches) allow you to easily configure either Layer 2 triangles or V’s. By default, MLS allows all VLANs to transit the switch. Therefore, assuming that you have removed end-user VLANs from the network core, you will be left with Layer 2 triangles by default (Part A of Figure 15-7). However, by pruning a given VLAN from the link between the MDF/distribution switches, this VLAN can easily be converted into a V (Part B of Figure 15-7). In other words, by simply pruning the VLAN from the triangle’s base, it is converted into a V.
From a Spanning Tree perspective, it is important to evaluate the differences that this brings to your network. If you opt for using triangles, then Spanning Tree will be in full effect. The Root Bridge placement form of load balancing and features such as UplinkFast will be important. If you opt for the Layer 2 V’s, you will be left with the same “almost Spanning Tree free” situation described several paragraphs earlier in connection with the 8500s.
Be sure to consider the impact and performance of Spanning Tree where you have Layer 2 triangles in your campus network.
Consider Using Switching Routers to Virtually Eliminate Spanning Tree
Because Catalyst 8500-style switching routers in the MDF/distribution layer closets eliminates loops through the IDF switches, this results in Layer 2 V’s. Therefore, Spanning Tree can be much simpler to design, maintain, and troubleshoot. The IDF switch automatically elects itself as the Root Bridge of a one-bridge network (the Layer 3 switches prevent the bridges from learning about each other and keep the Spanning Tree separate). Timer values can be fairly aggressively tuned without risk (use the set spantree root command with a diameter of 2 or 3 hops). Also, Spanning Tree load balancing is no longer necessary.
Note that Layer 2 V’s can also be created with routing switch (MLS) platforms by pruning VLAN from selected links (in this case, the base of the triangle—the MDF-to-MDF link).
Consider Using Loop-Free Management VLANs
As discussed in the section “Use Separate Management VLANs,” exposing a Layer 2 Catalyst Supervisor to excessive broadcast traffic can lead to network-wide outages. This section recommended using a management VLAN to isolate the Catalyst SC0 interface from end-user broadcast traffic. However, even when using a separate management VLAN, some risk remains. If a loop were to form in the management VLAN itself, the Supervisors could once again find themselves crushed by a wave of traffic.
Make certain that your design minimizes the risk of braodcast storms occurring in the management VLAN.
Therefore, ensuring that the management VLAN itself is loop free can provide an additional layer of protection. In general, two techniques can be used to create a loop-free management VLAN:
- The use of Catalyst 8500-style switching routers in the MDF/distribution layer automatically creates loop-free management VLANs on the IDF/access devices by default. Notice that this also implies that you should not use IRB to merge the management VLANs back into a single VLAN. Although this can appear to simplify the management of your network by placing all of the switches in a single VLAN, it can create management problems in the long term by adding loops into the management VLAN.
- Campus-wide VLANs often require the use of an out-of-band management network. Because it is very difficult to maintain a loop free and stable environment when campus-wide VLANs are in use, you often have to resort to running separate Ethernet links from routers to a port on each Catalyst. By then assigning only this Ethernet port to the management VLAN used for SC0, a loop-free topology can be created. The ME1 (Management Ethernet) ports available on some Catalyst devices can also be used to create an out-of-band management network.
Figure 15-8 illustrates a typical network using the out-of-band approach to creating loop-free management VLANs. Assume that because the switches are deployed in a haphazard manner, it is not feasible to create loop-free management VLANs using the existing infrastructure. Instead, separate Ethernet links are pulled from the nearest available router port. Where possible, hubs can be used to reduce the number of router ports required.
Figure 15-8. Creating Loop-Free Management VLANs with an Out-Of-Band Network
As discussed in the section “Make Layer 2 Cores Loop-Free,” you should also keep an eye on VLAN 1. Although you may have carefully used Layer 3 switching to create hierarchy in your network, you can still be left with a campus-wide VLAN in VLAN 1 (especially if you are using MLS Layer 3 switching). Note that this will be true even if you followed the earlier advice (see the section “Prune VLANs from Trunks”) of pruning VLANs core VLANs from the wiring closet trunks and wiring closet VLANs from the core trunks (recall that VLAN 1 cannot be deleted and cannot be pruned from Ethernet trunk links in current code images).
Because VLAN 1 is given special priority because of the control traffic discussed in the section “Deciding What Number Should be Used for the Management VLAN,” a broadcast loop in this VLAN can be devastating to the health of your network. How, then, are you supposed to control this situation? In general, organizations have used one or more of the following techniques:
Probably the simplest and most effective option involves using non-trunk links in the core. By assigning each of these core links to a single VLAN (do not use VLAN 1 here!), the core will block the transmission of VLAN 1 information.
Consider using non-trunk links in the core. This can be an extremely simple but effective way to reduce “Sprawling VLANs” in your network.
Use “switching routers” such as the Catalyst 8500s that do not forward VLAN 1 by default.
Once it is available, use the upcoming feature that will allow VLAN 1 to be removed from trunk links (see the section “Deciding What Number Should be Used for the Management VLAN”).
If you are using an ATM core, VLAN 1 can be removed from this portion of the network (see Chapter 9).
For the record, heavy broadcast traffic can also be a problem for routers. They are no different from other devices—all broadcasts must be processed to see if they are “interesting” or not. In fact, this phenomenon can be worse for routers because, by definition, they are connected to multiple subnets and therefore must process the broadcasts from every subnet.
However, with this being said, routers (and Layer 3 switches) are still the best tools for handling broadcast problems. Although the routers themselves can be susceptible to broadcast storms, their very use can greatly reduce the risk of Layer 2 loops ever forming. The multilayer model is designed to maximize this benefit by reducing Layer 2 connectivity to many small triangles and V’s. Furthermore, although a broadcast loop can overload any directly-connected routers, the problem does not spread to other sections of the network, a huge improvement over the problems described earlier in this section and in the section “Use Separate Management VLANs.”
Always Specify Your Root Bridges
Chapter 6 discussed the problems that can arise when you do not manually specify Root Bridge locations in your network. It is highly possible (even probable if using older Cisco equipment) that a suboptimal bridge or switch wins the Root War election. Rather than leaving it to chance, always specify both a primary and a secondary Root Bridge for every VLAN (in a large and very flat network, it might be beneficial to also specify a tertiary Root Bridge). By manually setting the Root Bridges, it can not only optimize the data path, but it makes the network more deterministic and improves its stability, maintainability, and ease of troubleshooting.
All networks using groups of contiguous Layer 2 switches or transparent bridges should specify a primary and a backup Root Bridge.
Try to Use Root Bridge Placement Load Balancing
As discussed in Chapter 7, the Root Bridge placement form of Spanning Tree load balancing can be extremely effective and easy to implement if the topology supports it. In most networks that utilize campus-wide VLANs and a centralized server farm, it is very difficult to obtain any degree of load balancing with this technique.
However, when using the multilayer model in conjunction with MLS (and other types of routing switches), this form of load balancing is highly recommended. Because the multilayer model and MLS reduce the network to a series of many small Layer 2 triangles that span each IDF switch and the corresponding pair of MDF switches, the Layer 2 topology is constrained, well-defined, and deterministic.
Consequently, it is easy to make one MDF switch the Root Bridge for approximately half of the VLANs contained in that distribution block while the other switch is configured as the Root Bridge for the remaining VLANs. (As a reminder, a distribution block is comprised of a pair of MDF switches and their associated collection of IDF switches—typically this is contained within a single building.) For example, Figure 15-9 illustrates a typical distribution block where MDF-A is the Root Bridge for the odd-numbered VLANs and MDF-B is the Root Bridge for the even-numbered VLANs.
Figure 15-9. Root Bridge Placement Spanning Tree Load Balancing
This causes the odd VLANs to use the left riser link (the right IDF port is Blocking for these VLANs), whereas the even VLANs use the right link (the left IDF port is Blocking). As discussed in the following section and Chapter 11, this should be coordinated with any Hot Standby Routing Protocol (HSRP) load balancing being performed by your MDF/distribution layer devices.
The Root Bridge placement form of Spanning Tree load balancing is both simple and effective.
Root Bridge Placement Considerations
Besides influencing traffic distribution through load balancing, several other factors should be considered when determining where Root Bridges should be located. Some of the more important considerations are mentioned in the following list:
- Place the Root Bridge in the path of high-bandwidth data flows— This point is discussed in more detail in the following section.
- Use a device that is very stable— Because Spanning Tree is a protocol that constantly seeks out the most attractive Root Bridge, placing the Root Bridge on a device that reboots or fails frequently can disturb the entire network unnecessarily.
- Use a device that can carry the load— Because the Root Bridge functions as a central switching node for all of the branches of the Spanning Tree, it must be able to handle the potentially high aggregate load.
When implementing a Spanning Tree design, most organizations adopt one of two strategies:
- Distributed Root Bridges
- Centralized Root Bridges
Distributed Root Bridge placement is useful in situations where network designers want to spread the centralized switching load over more than one bridge. Besides increasing the overall available bandwidth, this technique can also improve network stability by not forcing the entire network to depend on one or two switches for Root Bridge services. However, distributing the Root Bridges can significantly increase troubleshooting complexity in your network by creating a different logical topology for every VLAN.
In general, distributed Root Bridges can add more complexity to the network than they are worth.
Centralized Root Bridges are useful in situations where the traffic flows are highly concentrated (such as in the case of a centralized server farm). Another advantage of this approach is that it can ease troubleshooting by creating identical (or at least very similar) logical topologies in all VLANs. Overall, centralized Root Bridges are more common.
Where to Put Root Bridges
In general, the most important consideration is placing Root Bridges in the path of high-bandwidth data flows. The goal is to have the Spanning Tree logical topology mirror the natural flow of traffic in your network. To do otherwise implies an inefficient path for the most bandwidth-intensive flows. As discussed in Chapter 6, this optimization is most often achieved in one of two ways:
When using very flat designs such as campus-wide VLANs, the Root Bridges should generally be placed at the point where the server farm connects to the campus core. Assuming that a pair of switches is used to link the server farm to the core (this provides redundancy as well as additional bandwidth), the Root Bridges can be alternated on a per-VLAN basis.
When using routing switches (MLS) with the multilayer model, the Root Bridge should be located in the switch that contains (or, in the case of an external router, links to) the active HSRP peer for a given VLAN. Therefore, if an MDF switch is acting as the active HSRP peer for the odd-numbered VLANs, it should also be the primary Root Bridge for these VLANs.
Your decision to utilize Spanning Tree timer tuning should be based primarily on your campus architecture. If you have utilized the campus-wide VLAN model, timer tuning is almost always an exercise in futility and frustration. Because campus-wide VLANs lead to very large Spanning Tree domains, timer tuning usually results in a network plagued by instability.
Do not attempt Spanning Tree timer tuning if your network uses the campus-wide VLAN model.
On the other hand, the Layer 3 barriers created by the multilayer model make timer tuning a very attractive option for most networks. When performing timer tuning, it is usually best to use the set spantree root macro discussed in the “Using A Macro: set spantree root” section of Chapter 6. In general, the values in Table 15-1 have been shown to be a good compromise between network stability and speed of convergence (for more information on the details of these timer values, refer to Chapters 6 and 7).
Table 15-1. Recommended Spanning Tree Timer Values
|Network Design||Specified Diameter||Specified Hello Time||Resulting Max Age||Resulting Forward Delay|
|Campus-wide VLANs||N/A||N/A||Default (20 secs)||Default (15 secs)|
|Multilayer and routing switches (MLS)||3 hops||2 secs||12 secs||9 secs|
|Multilayer and switching routers (8500s)||2 hops||2 secs||10 secs||7 secs|
Because timer tuning is not recommended for campus-wide VLANs and should therefore not be specified on the set spantree root command, these values have been omitted from Table 15-1. (Although, as discussed in Chapter 7, 802.1D assumes a diameter of 7 hops and the Hello Time defaults to 2 seconds.) The routing switch (MLS) and switching router values are based on fairly conservative assumptions about link failures and the possibility of additional bridging devices being attached to the network (these values are also used and discussed in the case studies covered in Chapter 17).
Also, if you are willing and able to incur the extra load of Spanning Tree BPDUs, the Hello Time can be reduced to 1 second to further improve convergence times. However, notice that this doubles the bandwidth consumed by BPDUs, and, more importantly, the load on the supervisor CPUs. Therefore, if each device only participates in a small number of VLANs, Hello tuning can successfully improve Spanning Tree convergence times with minimal impact on the CPU.
Conversely, if your devices participate in a large number of VLANs, changing the Hello Time can overload your CPUs. When using a large number of VLANs, only lower the Hello Time for a subset of the VLANs where you need the improved convergence time as a compromise. If lowering the Hello Time to one second, consider using the values specified in Table 15-2.
Table 15-2. Spanning Tree Timer Values When Using a Hello Time of 1 Second
|Network Design||Specified Diameter||Specified Hello Time||Resulting Max Age||Resulting Forward Delay|
|Multilayer and routing switches (MLS)||3 hops||1 secs||7 secs||5 secs|
|Multilayer and switching routers (8500s)||2 hops||1 secs||5 secs||4 secs|
Finally, be certain that you set the chosen timer values on both the primary and backup Root Bridges. You can set the values on other bridges/switches, but it has no effect (for simplicity, some organizations simply set the values on every device).
Spanning Tree and the Management VLAN
The point made earlier in the “Consider Using Loop-Free Management VLANs” section bears repeating—Layer 2 loops in the management VLAN can lead to catastrophic network failures. You should consider implementing loop-free VLANs for your management networks, especially if using a flat earth network topology.
Study Your Spanning Tree Logical Topology
The time to be learning your Spanning Tree logical topology is not during the middle of a major network outage. Instead, it is advisable to create maps of both your primary and backup Spanning Tree topologies beforehand. Most organizations are accustomed to making extensive use of diagrams that reveal the Layer 3 topology of their network (often using tools such as HP OpenView). However, very few of these same organizations go through the exercise of creating and distributing Layer 2 maps.
A picture is worth a thousand words… diagram your Layer 2 topologies (including Spanning Tree).
At a minimum, these diagrams should illustrate the extent of each VLAN, the location of the Root Bridge, and which switch-to-switch ports are Blocking or Forwarding (diagramming end-user ports is rarely beneficial). In addition, it might be useful to label the Forwarding ports as either Designated Ports or Root Ports. See Chapters 6 and 7 for more information on these ports.
CiscoWorks 2000 can create basic Spanning Tree maps.
The importance of having Layer 2 diagrams is influenced by, once again, the choice of the network’s design. They are especially important in the case of campus-wide VLANs where the combination of many VLANs and Blocking/Forwarding ports can become very complex. Fortunately, another benefit of the multilayer model is that it reduces the need for diagrams. First, the Layer 3 hierarchy created by this design makes the traditional Layer 3 maps much more useful. Second, the simplistic Layer 2 triangles and V’s created by this design allow two or three template drawings to be used to document the entire Layer 2 network.
When to Use UplinkFast and BackboneFast
Both UplinkFast and BackboneFast are significant Cisco enhancements to the Spanning-Tree Protocol. It is important to know when and when not to use them. In general, neither feature is particularly useful in a network that contains a very strong Layer 3 switching component. Because this tends to break the network into a large number of loop-free paths, there are no Blocking ports for UplinkFast and BackboneFast to perform their magic.
Don’t waste your time designing lots of Spanning Tree optimizations (such as UplinkFast and BackboneFast) into a heavily Layer 3-oriented network—they will have little or no effect.
On the other hand, UplinkFast and BackboneFast can be extremely useful in more Layer 2-oriented designs such as campus-wide VLANs and the multilayer model with routing switches (MLS). In either case, UplinkFast should be enabled only on IDF wiring closet switches while BackboneFast is enabled on every switch in each Spanning Tree domain. It is important to follow these guidelines. Although both protocols have been carefully engineered to not completely disable the network when they are used incorrectly, it causes the feature to either be completely ineffective (as is possible with BackboneFast) or to invalidate load balancing and Root Bridge placement (as is possible with UplinkFast). See Chapter 7 for more detailed information on BackboneFast and UplinkFast.
When to Use PortFast
PortFast is a tool that deserves consideration in every network. There are two main benefits to using PortFast:
End stations and some servers that use fault-tolerant NICs can gain immediate access to the network. In the case of end stations, this can help with protocols such as DHCP and initial server or directory authentication. For servers using fault-tolerant NICs that toggle link-state, PortFast can mean the difference between transparent failover and a 30–50 second outage (however, most fault-tolerant NICs do not toggle link). When using PortFast with server connections, be sure to disable PAgP on EtherChannel-capable ports. Otherwise PortFast still takes approximately 20 seconds to enable the link. For more information, please refer to the section “Disabling Port Aggregation Protocol” in Chapter 7.
Ports do not send Topology Change Notification (TCN) BPDUs when they are using PortFast. Because TCNs cause bridges and switches to use a shorter bridge aging period, an excess of these packets can destabilize a large campus network (especially with flat earth designs like campus-wide VLANs). By potentially eliminating tens of thousands of TCNs per day in the typical large campus network, the use of PortFast can have a significant impact.
Even though Catalysts allow you to enter the set spantree portfast mod_num/port_num enable command on a trunk link, the command is ignored. Despite this feature, it is best to leave PortFast disabled on trunk links and spare other administrators of the network some confusion when they see it enabled.
Although PortFast is extremely useful in Ethernet-only networks, you might wish to avoid its use in networks that employ a LANE core. Because PortFast suppresses TCN BPDUs, it can interfere with LANE’s process of learning about devices/MAC addresses that have been relocated to a different LANE-attached switch. As a result, nodes that relocate may have to wait five minutes (by default) for their connectivity to be re-established if PortFast is in use.
By disabling PortFast, LANE will receive a TCN (both when the node is initially disconnected from the original switch and when it is reconnected to the new switch) that shortens the MAC aging process to the Spanning Tree Forward Delay timer (see Chapter 6). As an alternative you can manually (and permanently) lower the bridge table aging period using the set cam agingtime command. Both techniques will cause LANE to remove the MAC address to NSAP address mapping in the LES more quickly and force it to relearn the new mapping for a device that has been relocated. See Chapter 7 for more detailed information on the operation of LANE.
When One Spanning Tree Is Not Enough
Although many people complain that one Spanning Tree per VLAN is too complex for human comprehension (by the way, this is an exaggeration), there are times when you actually want to use more than one Spanning Tree per VLAN! Other than the corner-case of using PVST+ to tunnel multiple Spanning Trees through an 802.1Q region that only utilizes a single Spanning Tree, the primary use of multiple Spanning Trees per VLAN is to successfully integrate bridging and routing between VLANs. (See the “Per-VLAN Spanning Tree Plus” section of Chapter 7 for more information on PVST+). When combining bridging and routing, the situation can arise where IP subnets become partitioned and a partial loss of connectivity occurs—for example, when bridging protocols such as NetBIOS and LAT while simultaneously routing traffic such as IP. Chapter 11 referred to this as the broken subnet problem in the “Issues and Caveats with Bridging between VLANS” section and the “How to Fix the Broken Subnet Problem” section.
Watch out for the “broken subnet problem.” It can create difficult to troubleshoot connectivity problems.
As detailed in Chapter 11, the solution is to use two versions of the Spanning-Tree Protocol. The Layer 2 Catalysts such as the 5000 and the 6000 only use the IEEE version of the Spanning-Tree Protocol. However, IOS-based devices such as the routers and Catalyst 8500s can either run the DEC version of Spanning Tree-Protocol or Cisco’s proprietary VLAN-Bridge Spanning-Tree Protocol. In both cases, the BPDUs for these two protocols are treated as normal multicast data by the Layer 2 Catalysts and flooded normally. Conversely, the IOS-based devices swallow the IEEE BPDUs when they are running a different version of the Spanning-Tree Protocol.
Consequently, the IOS-based devices partition the IEEE protocol into smaller pockets. Within each pocket, the IEEE Spanning-Tree Protocol ensures that the logical topology is loop free. The DEC or VLAN-Bridge version of the Spanning-Tree Protocol ensures that the collection of pockets remains loop free. The result is a network where both routed and non-routed protocols have full connectivity throughout the network. For more information, see the “Using Different Spanning-Tree Protocols” section in Chapter 11.