traffic in traces that shouldn't be there 1

[jimfixit]

Help me understand something:

if we are using switches, we should ONLY see traffic on any given port that is either a) unicast to the address(es) serviced on that port, b) broadcast within the VLAN that port belongs to or c) generated by equipment attached to that specific port.

So if I'm tacking a packet trace, even if my nic is promiscuous I should not see for example, traffic specifially bound from one server to another when the port I'm tracing is a workstation, would that not be correct?

I set up a session with the source being a workstation, and the destination being my laptop, ran ethereal and started trapping and I'm seeing all kinds of stuff I just don't think should be copied out to the source switch port...

 

[chipk]

I just ran Wireshark (which is the replacement for Ethereal) and captured a couple hundred packets and didn't see any traffic that I should not have. CAn you give some examples of source/destination and port of what you think shouldn't be in your capture? Anyway, that's not all the traffic you would see, you would also see some multicast traffic, for instance, and traffic from any other protocols on your network (appletalk, for instance).

 

[jimfixit]

Chip,

Thanks for the follow up. Okay here's the situation.

I placed a hub between a user's workstation and the switch, and put my laptop with wireshark on the hub.

I did a packet capture. 34% of the traffic is that person's station to/from the citrix server. In the rest of the traffic, much of which is broadcast, multicast and some other netbios type stuff and I expect I would see that. But then there's these TCP packets for example to and from say 10.1.8.22 and 10.1.8.122 when this person's station is 10.1.3.111! And that's not all. I'll see others like that. I see a TCP conversation between a workstation and a print spooler...and the workstation on the hub with me is none of those.

The switch should NOT be copying unicast frames for other workstations to this port. I set up the session for a source and destination port, not a vlan. So I'm really puzzled.

 

[helpdeskdan]

When traffic does not yet know the correct destination, it will be flooded out all ports as an unknown unicast till the switch receives a reply and can add it to it's mac table. Now, if you are constantly seeing the same traffic, that means some sort of problem in the switch. This can be caused by traffic taking one route to a destination and another route back leaving no way to learn a mac address. However, that's rare. More likely is that you have a cheap switch and the mac tables are full because your network is too large and requires segmentation. When this happens, the switch has no choice but to forward the packets out all ports because there's no room for another mac entry. (If memory serves me correct)

 

[chipk]

Ah, good call helpdeskdan. I guess jimfixit could test that by putting the hub/laptop with wireshark running elsewhere on the network to see if he sees the same traffic.

 

[helpdeskdan]

Thanks, chip. Again, the cure would be to segment the network or use a better switch.

 

[ADB100]

Ahh excessive unicast flooding, the downfall of a badly designed network ;o)

Unicast flooding always happens as helpdeskdan explains: if the switch receives a packet with a destination MAC address it doesn't know about it floods it to all ports in the VLAN except the port it was received on. This can be an issue on badly designed networks.
If you have multiple switches with the same VLAN spanned over them then unicast flooding can be a BIG issue. Design the network correctly and you reduce the impact it has.

I have seen entire networks brought down because of this. Have a search on CCO for 'Unicast Flooding', there is a very good explanation and description.

HTH

Andy

 

[jimfixit]

My thanks to you all. I had forgotten that small detail of how switches learn where various Mac addresses are located. Truth is, I never really witnessed a situation where many unicasts were going where they should not. My last network was heavily segmented.

I have inherited this network as a new job assignment. Boy is it a mess. I knew it needed to have some vlans introduced to help shunt traffic but, I had no idea it could be this bad. This organization has over 2500 employees and they, plus the 100 or so MS servers, are ALL on the SAME net. (Despite the investment in Catalyst 6000 series at the core and 3700s out in the access area). I knew the logical meaning of this, but had not translated it to the actual packets when they were looking me eye to eye! Thanks for the great call and, this gives me the information I need to support the job that needs to be done here.