RSS
 Can A Single Packet Topple Your Topology? By Bill Alderson and J. Scott Haugdah Q: We recently installed an Ethernet switch as a front end to a router. The switch breaks up the local Microsoft Windows NT workstation traffic that used to be on two Ethernet segments connected to the router. Our users are running a Visual Basic database front-end application that communicates with Banyan VINES servers. The router services a T1 circuit such for remote access. We continue to use the two segments coming from the router, but now the segments connect to ports on the switch, giving us redundancy and load-balancing. Recently, we began looking at data from our RMON probes and noticed spikes in broadcast traffic on the router's Ethernet segments. These spikes (or brief broadcast storms) occur on a regular basis and are increasing in frequency as we add more users to our network. Scott: Sometimes those broadcast packets can be as irritating as a group of gnats endlessly buzzing around your face on a hot summer day. Bill: Even though they aren't really causing any great harm, the only thing you want to do is get rid of them.
Bill: The Remote Monitoring (RMON) probes showed the first indication of such a problem. In addition to the storms, the broadcast counts were approaching 100,000 per hour, up from approximately 1,000 per hour. Scott: Our next step was to watch the switch-to-router Ethernet segments with a protocol analyzer and capture packets during one of the broadcast storms. Bill: On the surface, it appeared that a Windows NT workstation would occasionally send out a burst of broadcast pa ckets, since the destination Data Link Control (DLC) address was an "all stations" broadcast (FFFFFFFFFFFF hex) and the destination network address was an IP-subnet broadcast. Scott: On closer examination of back-to-back broadcast packets, we saw that the time to live (TTL) field in the IP header was decrementing by one in successive packets, until it reached zero in the last packet of a burst. Bill: We knew, without a doubt, that a router had to be involved in the problem because routers "decremented" the TTL by one whenever a packet was forwarded. Scott: In the case of Microsoft Windows NT 3.51, the TTL starts out at 32, thereby limiting a single instance of a broadcast storm to 32 packets, since a router will discard a packet with a TTL of zero. Bill: A closer examination of the suspect Ethernet segment on paper (our client's network documentation) gave us the answer we were searching for. Scott: The two segments from the router were IP-subnets, 47 and 48 (which are designated in the diagram "A Flattened IP Network," next page). Bill: By putting an Ethernet switch (such as a multiport transparent bridge) in front of both of these subnets, our client effectively flattened its IP address space, since it no longer mattered to which Ethernet segment a workstation connected. Scott: Since all of the packets were now transparently switched at the DLC layer, independent of the network layer, packets containing the "all stations" DLC broadcast were sent to every Ethernet segment on the switch. |
Scott:
Especially if they get worse, as was the case for our user with the periodic gnats--I mean broadcast storms.
 |
by Patricia Schnaidt FreeWire by Bill Frezza Corporate View by Brian Walsh In The Middle by Nick Gall Updated April 24, 1997 |
