Ethernet switch flooding packets?|
|
|
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||||||||||||||||||||
|
Posted by on February 11, 2009, 4:06 pm
Please log in for more thread options
I did a WireShark packet trace this evening on the network. I was surprised to see quite a few packets that weren't meant for me. Naturally I saw packets from my PC to the network, some replies, and broadcasts such as ARPs and Windows name registrations. However, I also recieved packets addressed to other host's IP addresses and MAC addresses. (I am, of course, the only PC connected to that particular switch port - I'm not hanging off a hub that's connected to the switch port). My understanding of networking is that as soon as I send an Ethernet packet, the switch 'knows' my MAC address is on 'my' Ethernet port. When forwarding packets, it won't bother sending me packets that aren't destined for my MAC address. I think this is a symptom of networking problems; we have a *huge* broadcast domain of thousands of Ethernet outlets spread across many buildings, and quite a few secondary VLANs that don't have anywhere near as many outlets, but still distributed across the many buildings. The network is mainly made up of HP ProCurve 26xx switches. My assessment is that we probably have more MAC addresses across all the VLANs that the HP ProCurve fabric is capable of handling, and so old learned addresses are being dropped as new ones are learned so the fabric is flooding packets. It's by no means all packets, but, say 5-10 per second. What do you think? Do we need to think about segmenting into separate Ethernet domains separated by L3 switches? Kind regards, Anwar | ||||||||||||||||||||||||||||||||||
|
Posted by Glen Herrmannsfeldt on February 11, 2009, 4:44 pm
Please log in for more thread options > Naturally I saw packets from my PC to the network, some replies, and
(snip)
> broadcasts such as ARPs and Windows name registrations. However, I > also recieved packets addressed to other host's IP addresses and MAC > addresses. (I am, of course, the only PC connected to that particular > switch port - I'm not hanging off a hub that's connected to the switch > port). > My assessment is that we probably have more MAC addresses across all
> the VLANs that the HP ProCurve fabric is capable of handling, and so > old learned addresses are being dropped as new ones are learned so the > fabric is flooding packets. It's by no means all packets, but, say > 5-10 per second. > What do you think? Do we need to think about segmenting into separate
> Ethernet domains separated by L3 switches? Certainly 5 or 10 packets/second won't overload the network software. You might check the MAC address cache size in the switches. Even if you have more hosts, it is likely that they won't all be in heavy use at the same time. It might be that the backbone links have somewhat more load, but 10 packet/sec is fairly small for networks now. I would probably suggest more study before deciding on L3 switches. -- glen | ||||||||||||||||||||||||||||||||||
|
Posted by anwarmahmood38@googlemail.com on February 12, 2009, 12:08 am
Please log in for more thread options > anwarmahmoo...@googlemail.com wrote:
> > I did a WireShark packet trace this evening on the network. =A0I was
r
> > surprised to see quite a few packets that weren't meant for me. > > Naturally I saw packets from my PC to the network, some replies, and > > broadcasts such as ARPs and Windows name registrations. =A0However, I > > also recieved packets addressed to other host's IP addresses and MAC > > addresses. =A0(I am, of course, the only PC connected to that particula= > > switch port - I'm not hanging off a hub that's connected to the switch
> > port). >
> (snip) > > > My assessment is that we probably have more MAC addresses across all
e
> > the VLANs that the HP ProCurve fabric is capable of handling, and so > > old learned addresses are being dropped as new ones are learned so the > > fabric is flooding packets. =A0It's by no means all packets, but, say > > 5-10 per second. > > What do you think? =A0Do we need to think about segmenting into separat= > > Ethernet domains separated by L3 switches?
>
> Certainly 5 or 10 packets/second won't overload the network software. > > You might check the MAC address cache size in the switches. =A0Even if > you have more hosts, it is likely that they won't all be in heavy > use at the same time. > > It might be that the backbone links have somewhat more load, but > 10 packet/sec is fairly small for networks now. > > I would probably suggest more study before deciding on L3 switches. > > -- glen So it's OK (and, I guess normal and accepted) that a switch is (probably) flooding unicast packets (that are, of course not broadcasts)? I thought this was a no-no? How common is this? | ||||||||||||||||||||||||||||||||||
|
Posted by Patrick Schaaf on February 12, 2009, 1:58 am
Please log in for more thread options
>So it's OK (and, I guess normal and accepted) that a switch is
>(probably) flooding unicast packets (that are, of course not >broadcasts)? I thought this was a no-no? How common is this? Depends. A switch will flood unicast when the destination address is not in the learned address table of the switch. An address enters those tables when it is seen as a source address, and leaves the tables after some time when not seen again as a source address of other packets. Common problem 1, in my experience: the timeout for the switch address table is shorter than the ARP timeouts used by some of the communicating hosts, and such hosts do unidirectional messaging. Initially, the destination host for such messages will show itself with an ARP reply, populating the switch address table, and messages to it will not be flooded. But with unidirectional traffic, that destination host does not send anything back. So its address will timeout in the switch address table eventually. From then on, the unidirectional messages will be flooded. A periodic ARP request from the source host, even unicast, will elicit further ARP replies from the destination, again populating the address table. I've seen two different cases of such unidirectional messaging causing flooding. One was Cisco netflow export data. The other was in the context of a load balancer setup with triangular dataflow, i.e. one VLAN transports requests from Internet through loadbalancer to some server, but the replies of the server flow back to the Internet on a different VLAN or LAN. I think that similar things could happen with host based ethernet adapter "teaming" with two host ports connected to different switches in the same switch cloud. Such problems are fixed by either making the sending hosts periodically ARP more often (the loadbalancer, in my scenario above), or by making the timeouts of the switch address tables larger (than a common timeout on all the hosts. we set it to 999 seconds). best regards Patrick | ||||||||||||||||||||||||||||||||||
|
Posted by anwarmahmood38@googlemail.com on February 12, 2009, 3:39 am
Please log in for more thread options On 12 Feb, 06:58, mailer-dae...@bof.de (Patrick Schaaf) wrote:
> >So it's OK (and, I guess normal and accepted) that a switch is
> >(probably) flooding unicast packets (that are, of course not > >broadcasts)? =A0I thought this was a no-no? =A0How common is this? >
tion
> Depends. > > A switch will flood unicast when the destination address is not in the > learned address table of the switch. > > An address enters those tables when it is seen as a source address, > and leaves the tables after some time when not seen again as a source > address of other packets. > > Common problem 1, in my experience: the timeout for the switch address > table is shorter than the ARP timeouts used by some of the communicating > hosts, and such hosts do unidirectional messaging. Initially, the destina= > host for such messages will show itself with an ARP reply, populating the
.
> switch address table, and messages to it will not be flooded. =A0But with > unidirectional traffic, that destination host does not send anything back= > So its address will timeout in the switch address table eventually.
es
> From then on, the unidirectional messages will be flooded. A periodic ARP > request from the source host, even unicast, will elicit further ARP repli= > from the destination, again populating the address table.
ts
> > I've seen two different cases of such unidirectional messaging causing > flooding. One was Cisco netflow export data. The other was in the context > of a load balancer setup with triangular dataflow, i.e. one VLAN transpor= > requests from Internet through loadbalancer to some server, but the repli=
es
> of the server flow back to the Internet on a different VLAN or LAN.
> I think that similar things could happen with host based ethernet > adapter "teaming" with two host ports connected to different switches > in the same switch cloud. > > Such problems are fixed by either making the sending hosts periodically > ARP more often (the loadbalancer, in my scenario above), or by making > the timeouts of the switch address tables larger (than a common timeout > on all the hosts. we set it to 999 seconds). > > best regards > =A0 Patrick Hi Everyone, Thanks again for your replies. Glen, I acknowledge 10 frames/sec wouldn't be considered a "flood", I was merely using the Ethernet switching terminology - if a switch doesn't know which individual port to push a frame out to, it will "flood" them to all ports. I've only done a short capture at one location at one time, so the magnitude of the problem is certainly inconclusive. Patrick, I don't think this is a switch address timeout. In the frames that I saw, I saw some packets from my PC to a server on the other end of a router, and the corresponding replies. Hence "my" switch has "learnt" that my MAC address is on my port, and the router's MAC address is on the uplink port. If I exchanged no more traffic for the timeout period, then my address would of course timeout and I would be flooded. HOWEVER, just a few packets (milliseconds) later, the switch is forwarding unicast packets on my port that aren't for me. I think this is because - the switch as 8K MAC address table. - every PC on each port gets added to the table when it transmits (as it should) - however, because there are many thousands of MAC addresses on the Ethernet fabric, they are all being added as belonging to the "uplink" port - these are replacing the entries in the MAC address table about which PCs are on the "local/edge" ports - this is happening so fast that I'm recieving unicasts addressed to other MAC addresses on my computer, even though I just transmitted milliseconds ago Hope this is making sense! Kind regards, Anwar | ||||||||||||||||||||||||||||||||||
|
Home Cabling GuideFinally, an instantly downloadable book that saves you thousands in home improvement dollars! Enjoy living in 21st century technology-advanced home while increasing its selling value and competitive advantage on the real estate market. Whether your cabling is for home office or high-tech leisure, you can wire your home yourself or learn "wirish" to speak with your cabling contractors in their language! Learn More |
> surprised to see quite a few packets that weren't meant for me.