Why wireshark captures foreign / non relevant traffic on my plain access switchport?

Question

On a company main switch (Cisco 3750) I have connected a simple Windows XP physical PC on a switchport (switchport mode access, switchport access vlan 30). NO monitor sessions exists on the 3750. Also, the PC has a single IP address on a single NIC. However, when I start a Wireshark promiscuous capture on the WinXP PC, several foreign conversations appear, either LAN-to-LAN or WAN-to-LAN (that is src IP and dst IP does not match the PC's IP address). This traffic is NOT broadcast (neither L2 broadcast nor L3 broadcast). The switch's configuration is a simple layer 3 and layer 2 configuration. Nothing fancy (ommited for cluttering the reasons)

I have checked the switch's MAC and ARP table and all seems normal: the PC's switchport shows only 1 MAC address and the other foreign MAC and IP addresses resolve to their normal ports (using "show ip arp" and "show mac-addr" etc.)

The whole capturing idea was initiated because we want to troubleshoot frequent application lags (according to other captures, many TCP retransmissions are the possible culprit).

Any ideas?

======================

EDIT after an IOS research it seems that there is a pretty big chance that my IOS version (12.2(25)SEB4) may have serious bugs about CAM tables and such. I will upgrade next week and revisit to update.

Answer 1

[Sorry for being late to the party, but came across this when looking for something else] When you say "several foreign conversations appear", do you mean multiple packets in both directions, or just the occasional packet?

If it is full conversations, then you definitely have a problem with your switch.

If it is occasional packets, then I'd blame spanning tree changes. Recall that a switch remembers MAC addresses for 300 seconds by default. So if your switch had NOT seen a frame from a particular device for 300 seconds, and frames were sent to that MAC address, they would be forwarded to all other ports, including your WinXP/Wireshark monitor. This would continue until the owner of the MAC address sent a frame.

For devices running modern operating systems, the chances of a device NOT sending a frame for 300 seconds is pretty slim, although other more passive devices may be silent for that kind of time.

Back to spanning tree. If there is a spanning tree topology change (such as a device connecting/disconnecting to a switch port), a Topology Change Notification event is sent to the root bridge. The root bridge then sets the TCN bit on all BPDUs for the next FWD_DELAY period (15 seconds). When bridges see BPDUs with the TCN bit set, they reduce the ageing timers for the MAC address table to FWD_DELAY (15 seconds). [This is one reason why you should always enter the global configuration command spanning-tree portfast default - to stop the creation of TCNs whenever a switch port is activated/de activated]

So IF there are spanning tree changes, you are more likely to see occasional packets to MAC addresses other than your own.

You do not specifically say if any of the packets you see were from another subnet (= another VLAN if your design is correct). BUT if you ARE seeing packets from another subnet/VLAN, then I would suggest that you look very carefully at your inter-switch cabling, and check the native vlan configuration and Trunk port status of all these links. If there is any "subnet/VLAN" leakage, then it could create multiple topology changes which in turn could keep the ageing timer to 15 seconds leading to many more unexpected frames arriving on your Wireshark capture.