76
Clearly, this threshold level has to be high enough that the network rarely loses an important broadcast packet such as an ARP packet. It also has to be low enough so it doesnt interfere with the normal
functioning of the network.
This way of treating broadcast storms is reasonably effective. It doesnt prevent them, of course; there will still be storms of packets. But this kind of simple measure ensures that they dont represent a serious traffic
performance problem on the network.
There is an interesting trade-off in the place where the decision is made to start throwing away packets. If the decision is made on a whole switch that happens to be in a broadcast-heavy network, then throttling for
broadcast storms can actually interfere with normal network operation. On the other hand, just looking at the per-port broadcast volumes ignores the possibility that the storm has been caused by the interaction
between several different devices.
One of the most difficult types of broadcast storms to control starts with a single device sending out a broadcast packet. Then one or more other devices on the network receive this packet and respond to it by
either sending out a new broadcast such as an ARP for the originators IP address or forwarding the original broadcast back onto the network. A good example is the old RWHO protocol, which broadcasts
periodically.
Some IP stack implementations like to send an ARP packet in response to a broadcast packet from an unknown source. This way, they are able to keep a more complete ARP cache. A large number of different
devices that respond like this simultaneously, can choke the network for an instant. RWHO is still run on many network print servers by default for historical reasons although I will never understand why it is still
needed. This problem is actually rather common, and it can be extremely serious if the timeout in the ARP cache is shorter than the interval between RWHO broadcasts.
In this case, the per-port monitoring is not effective at stopping the storm. The storm originates with a single broadcast packet, which is the one that really should be stopped, but it is the response that causes the
problem, and that response comes from everywhere.
The moral of this story is that just because you implement broadcast storm controls on your switches doesnt mean that you wont have broadcast storms. However, if you have such controls in place, you will
be able to prevent this storm from migrating to another switch. The second switch will see an incoming storm on its trunk port and will block it. The problem is at least partially contained.
3.5.2.2 Redundancy in bridged networks
Redundancy in bridged networks is important for exactly the same reasons as in routed networks. The only differences are in the methods and protocols for redundancy. Just as in the router case, the first step is to
install a second switch that is capable of taking over if the first fails. Thus, it needs an automatic mechanism for this to work effectively.
The most commonly employed fault recovery mechanism in bridged networks is the Spanning Tree protocol. The other type of fault recovery system that I mentioned earlier in the case of trunks is a
multiplexed arrangement of individual connections. That type of system works well for trunks, but is very difficult to use to make the switches themselves redundant. It is difficult because the individual connection
lines must connect between two specific endpoints. If you have a Distribution level switch connecting to a Core switch, you can use this type of system.
For good redundancy, you should have the Distribution switches connected to two Core switches. If the multiplexed bundle of links is split between two switches, then the packets can be sent in two different
ways. Some trunk mechanisms treat the bundle in parallel and break up each packet into small fragments, which are each sent through different links and reassembled at the other side. Other multilink solutions,
such as Ciscos Fast EtherChannel, ensure that each packet is sent through a single link intact. In this case, the extra capacity is achieved by distributing packets among the various links in the bundle.
77
In any case, splitting one bundle among two different switches makes it much harder for the switches to effectively manage the bandwidth. It is generally simplest to think of the bundle as a single logical trunk
and connect it between the two end point switches. Just avoid splitting the bundles.
3.5.2.3 Filtering
Most organizations do little or no filtering on their switches. For most networks, this is the right amount. It is generally much easier to filter on routers than switches. However, in some cases it is more effective to
filter on the switches. In general, the same reasons for filtering on routers also apply here:
•
Security
•
Cleaning up for ill-behaved applications The other reason I listed in the router case, policy-based routing, could theoretically apply here as well. But
that sort of facility should be used sparingly at best, and where it is used, routers are a more natural place for it, so I do not include it here.
Security filtering is usually handled on switches in two ways. Many vendors offer some sort of port-level security, in which only a specified MAC address is permitted to connect to a particular port. The second
type of security filtering typically restricts packets according to their contents, usually allowing only packets with certain source MAC addresses to communicate with sensitive devices.
Port-level MAC address security features allow the switch or hub, since this feature is also available on some hubs to lock out any devices except the one specified. If a particular workstation is supposed to be
connected to a particular port, then only that workstation will function on that port. If another device is connected, it will have a different MAC address and the switch or hub will disable the port, requiring
manual intervention.
This sort of feature is provided to prevent people from putting unauthorized equipment on the network. It is not perfect because many types of devices can use a manually configured MAC address instead of their
burned-in-address BIA. But it is a useful measure if this sort of problem is a concern. Note, however, that there is significant administrative overhead comes in maintaining the table of which MAC addresses are
permitted on which ports throughout a large network. Generally, I wouldnt use this feature unless a compelling security concern warranted it.
In the second type of security filtering, you instruct the switch to look at the packet before transmitting it. If a sensitive server, for example, is only permitted to communicate with a small list of other MAC
addresses, then this information could be programmed into the switch. Not all switches allow this sort of functionality, and it can be difficult to maintain such a switch. Once again, this feature should only be used
if there is a strong overriding security concern.
I have already talked about certain broadcast storm problems. These problems are commonly handled with a simple volume filter. In some cases, it may be worthwhile to use a more specific filter. For example, I
was once responsible for a network that suffered from the RWHO problem mentioned earlier. I was able to write a special purpose filter to restrict these packets on the switch. As for the security-based filtering, it
was also a huge administrative problem. This sort of filtering should be used sparingly, and only where absolutely necessary. Bear in mind that switch manufacturers know this, so they tend not to provide
extensive filtering capabilities.
3.5.3 VLAN-Based Topologies
