Unsuspected traffic while sniffing

[jbuijk]

Hi,

We are experiencing sparatic slowness on our network with core/distribution 6509s and 3560, 3750 and 4006 switches at the access layer.

So we put a sniffer on one of the access layer 3560s with no spanning done on the switch and we set up a filter in wire shark to capture wire to show only tcp traffic. I expected to see no traffic as there is no IP address set up on the sniffer pc nic and it is connected to a switchport.

But... that is not the case... I am seeing tcp conversations from one server to another on the capture. All three pc's are in the same vlan/subnet but not on the same switch.

The source pc is in the same switch as the sniffer pc and the destination pc is on a different switch in the same vlan.

Any idea why we would see the conversation at all? Maybe I am just misunderstanding how the switch process works?

Thanks

[Peter Paluch]

Hello,

There has recently been a similar discussion here - see this thread:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=LAN%2C%20Switching%20and%20Routing&topicID=.ee71a04&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cd42b01

In short: the switch might not learn the MAC address on wirespeed, rather, it make take slightly longer to actually store the learned MAC address into the CAM table. Until that happens, some frames might "leak" to ports where they do not belong. If you see only sporadic TCP segments then there's nothing to worry about.

Thanks goes to Jorgemario Brenesjaikel for explaining that to us.

Best regards,

Peter

[bbaillie]

Hello John,

The traffic you are seeing is a clue to the underlying problem of sporatic slowness. Most likely you are having periodic spanning tree topology changes that cause the mac tables to age out rapidly and therfore the leakage, also network disruptions.

The best way forward is use the command "show spanning-tree details" and look for the last spanning tree event and what port it came from to track it back to the source, maybe link flaps on trunks or workstations connected to ports that do not have portfast enabled. Also identify the root switch in spanning tree and watch it closely for changes within an hour of one another. The last spanning tree event can be weeks ago if good, or in your case its either minutes or less than 3 hours, signaling a stability problem.

Cheers,

Brian

[Peter Paluch]

Brian,

Also a good idea! Spanning-tree topology change causes the MAC address tables to flush entries prematurely, thereby possibly causing leakage of frames to improper ports until the MAC addresses are learnt again.

Best regards,

Peter