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.

  • Does vlan 30 have routers with HSRP, GLBP or VRRP on them? If so, there is a pretty good chance you've got unknown unicast flooding; see this post for mitigation details. May 13, 2014 at 6:37
  • No HSRP, VRRP or any high-availability design is not present. It seems that this traffic is unknown unicast flooding, you are right. Moreover, I got suspicious and started searching in Cisco bugs section. I might have stumbled on something interesting. I will provide feedback anyways.
    – Elias Bats
    May 13, 2014 at 12:27
  • Please add the switch config, output of "sh ver", and the total number of mac addresses in the cam table. A diagram of the switches connected to it would also help. May 13, 2014 at 12:42

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.