75
every end device gets, in effect, its own token. There is never any waiting for the token, so each device can use the entire 16Mbps capacity of the ring.
If it is an Ethernet switch, on the other hand, the only times you should expect to see collisions are when both the switch and the end device try to talk at once. Even this small collision rate can be eliminated if
you go to full-duplex Ethernet. On a large shared Ethernet segment, you can only practically achieve between 30 and 50 of the capacity because of the collision overhead. On a half-duplex switch this
jumps well over 90 of capacity for every device and 100 for full-duplex switching. Thus, the net throughput of a switch is considerably higher than a hub with the same number of ports, for both Token
Ring and Ethernet.
Most Fast Ethernet and many Token Ring switches can operate in a full-duplex mode. This means that they can send and receive simultaneously without collisions. Obviously this mode only works when a single end
device is attached to each switch port. You cant have a full-duplex connection to a hub. Using a full- duplex switch has the effect of theoretically more than doubling the throughput to each device. It more
than doubles because a half-duplex port still loses some capacity due to collisions. This advantage is most significant on servers, where it is not unusual to have a high volume of traffic both sending and receiving.
3.5.2.1 Containing broadcasts
Broadcasts are an integral part of many network protocols including TCPIP and IPX. However, having too many broadcasts on a network can cause serious problems. The most obvious problem is simply bandwidth
utilization. However, it is important to remember that broadcasts are delivered to every end device. Because these broadcast packets are addressed generically, the network interface cards of these end
devices cannot tell whether they are important. So they are all passed up the protocol stack to be examined by the main CPU of the end device. Having a lot of broadcasts on a LAN segment can cause CPU loading
problems on end devices, even when they are not actively using the network. Thus, broadcasts must be controlled.
A bridge or switch is supposed to forward broadcasts. This is, in fact, one of the most fundamental differences between bridging and routing. Forwarding broadcasts allows devices that are part of the same
Layer 3 network to communicate easily. All global information on the network is shared.
A hub cant stop a broadcast without breaking the Layer 2 protocol. Those broadcast packets have to circulate, and stopping one would also throw a wrench into the congestion control mechanism token
passing or collisions. A switch or bridge, however, can choose which packets it forwards.
Normally, the way a switch or bridge makes this decision is by looking at its MAC address table. If the packet has a destination MAC address that the switch knows is on a particular port, then it sends the packet
out that port. If the packet has an unknown destination address or if it has a broadcast or multicast destination address, then the switch needs to send it out to every port.
If the network is very large, then the number of packets that need to go out every port can become a problem. Usually, in most networks, the broadcast volume is a relatively small fraction of the total number
of packets. Pathological conditions called broadcast storms see the discussion in the previous chapter can make this broadcast volume suddenly high, though. If these conditions occur frequently, then serious
performance problems may occur on the network.
Controlling broadcasts is one of the main reasons why network designers have historically gone from bridged to routed networks. With many modern switches, it is possible to push this decision further
because of broadcast control mechanisms available on these devices. Usually, the broadcast control mechanism works by simply monitoring how frequently broadcast packets are seen on a port or on the
switch as a whole. When the broadcast volume rises above this high-water mark, the switch starts to throw away broadcast packets.
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
