Content

| 4.3 |  | Troubleshooting Switched Ethernet Networks |
| 4.3.5 |  | Troubleshooting Ethernet broadcast traffic |

One of the key performance benefits of a switch is its ability to keep local traffic local while still allowing any two devices to communicate. Switches are able to do this because switching decisions are based on the destination MAC address. Assuming VLANs are not in use, there are three instances where a switch cannot forward a frame to a single interface and will instead flood the frame out of all the ports. These situations occur when the destination MAC address is:

- The Ethernet broadcast address.
- A multicast address and the switch is not multicast aware.
- A MAC address that is not known to the switch.

In each case the behavior is required for normal network operation. However, excessive broadcasts will result in one or both of the following problems:

- Increased congestion.
- Poor host performance due each host having to examine all broadcast packets.

The amount of broadcasts present in a network can be determined using most protocol analyzers. As an alternative, the information can be determined using the show interfaces command on an IOS based switch or router. Judging whether the amount of broadcasts present is excessive can be difficult. There are no rules as to what is normal and it really depends on the applications and upper layer protocols being used. Broadcasts are used extensively by the IP protocol for addressing multiple hosts, ARP, and routing updates. It is not unusual to find up to 30% of traffic is made up of broadcasts. When encountering a situation where it appears that network performance may be degraded due to excessive broadcasts it is helpful if the network documentation baselines normal broadcast levels so a comparison can be made.

Where excessive broadcasts are observed, it is important to identify the source of the broadcasts so that appropriate steps can be taken. When analyzing traffic, keep in mind that switches are responding to broadcast frames, while traffic analyzers are usually more concerned about the Layer 3 packets. Generally this is not a problem as a broadcast packet is carried by broadcast frame but different tools will report broadcasts differently depending on whether they have a Layer 2 or Layer 3 focus.

Generally, excessive broadcasts result from one of the following situations:

- Poorly programmed or configured applications.
- Very large Layer 2 broadcast domains.
- Underlying network problems such as STP loops or route flapping.

Using a protocol analyzer, the source of the problem can be readily ascertained. Each of the above situations dictates a different solution.

Some applications such as Symantec’s Ghost server and streaming video servers use broadcast and multicast traffic. This is an attempt to reduce the number of streams of traffic sent, thereby minimizing bandwidth usage and to improving performance. While it may be possible to reconfigure the application so that it does not use multicasts or broadcasts, often this introduces other problems. If the network requires applications that are heavy producers of broadcast and multicast traffic, consider the following techniques to reduce the impact on other devices in the network:

- Create a separate VLAN for devices and hosts that are broadcast intensive.
- Configure switches to be multicast aware.
- Consider using scheduling for distribution services such as Ghost, so that broadcast traffic can be limited to off peak times.

Very large Layer 2 broadcast domains can sometimes occur where the hosts themselves do not generate much traffic and their perceived network needs are not great. It is tempting in these situations to avoid the expense of a Layer 3 hierarchy and simply adopt a flat, switched, structure. Unfortunately, modern operating systems use broadcasts extensively to discover network services and other hosts. Very large, lightly loaded, Layer 2 networks will quickly find that the majority of their traffic is made up of broadcasts. Laptop users that complain that their computer runs applications faster when they are not connected to the network are a signal that there may be excessive broadcasts. The solution is to use a proven hierarchical network structure using routers to break up the broadcast domains.

Many routing protocols, notably distance vector, use broadcasts. Link state routing protocols such as OSPF use multicasts. These mechanisms are required for exchanging routing updates. Network instability that results in routes being added and removed from routing tables can generate significant amounts of broadcast traffic.