Seeing unicast traffic on a switchport without spanning

Apart from the cases already mentioned by Laura, there are actually a few situations in which this is "works as designed" (so much for general network "design"):

• Asymetric routing in a redundant environment: If the traffic to a host passes one switch while the traffic from the host back doesn't pass the switch AND the arp timer of the upstream router is higher than the aging timer on the switch, then the switch mentioned will lose the mac-address of the host and will start flooding traffic for this host. If this is the case, you might want to adjust your timers.

• Microsoft Network Loadbalancing: To make every member of the cluster receive all requests (so that the designated server can answer the request while the other hosts will ignore it), Microsoft deliberately makes the switch flood all incoming traffic. This is done by not sending any traffic from the virtual mac-address. Hence the switch does not know where to send it and it will flood it across the vlan. That's why you don't want to put any other servers in a vlan that is used for Microsoft Network Loadbalanced Clusters.

• Full mac-address-table: When you have one flat network and many many hosts, the switch's forwarding table might be filled. This means it starts to flood for those addresses that did not make it into the forwarding table. If this is the case, start segmenting your network into smaller parts.

I see this when Cisco Switch ages out a MAC address (mac aging time - default 5 minutes) but the device forwarding the traffic (usually UDP traffic) has a 4 hour ARP aging time.

Try pinging the ip address of the traffic from the work station and see if it disappears. The PING will cause an ARP and the arp response will place the MAC back in all the switch tables.

Are the addresses all the same subnet? We recently cleaned up a network where multiple subnets were active in the same VLAN!!!

As already pointed out ARP Cache timeout is the likely culprit. We see this a lot on networks where you have a switch pair connected to each other and each having uplinks to a router pair but they DO NOT have cross connects (an X, a bowtie, etc) between the switches and routers - kind of a horseshoe. Your device is on switch A, which is directly connected to router A. All outbound traffic will go that route, but the return traffic will possibly hit router B, which has no ARP entries for your workstation but does have an interface within the proper subnet/VLAN. So it forwards it out of that interface to Switch B which also has no ARP entry and blasts it to every port - including the cross connect, which is how the packets make it to your interface. We have argued with Cisco and Juniper about this being the result of their "best practices". You might want to keep an eye on that crosslink's utilization. There are a few remedies for this but all are dependent on your environment.

Ohh... ouch! That is not a great situation. Here are some possible reasons... (and you might want to update your Tshark version...)

1. The traffic was addressed to unknown MAC addresses so the switch forwarded the packets down all ports in hopes of finding that MAC address on one of them.
2. Your switch has a problem - it is acting like a hub either for some ports or all ports (not a good sign at all).
3. Someone set up port spanning on that port and left it running.

Make sure you look at the MAC address of those "unicast" packets you are seeing as the switch is forwarding based on that address, not the IP address. Maybe the MAC destination has the multicast or broadcast bit set for some freaky reason.

I have seen this happen a couple of times to, so here's my 2 additional cents ;-)

• Switches keep refreshing their MAC address tables and relearning MAC addresses, so I got used to getting one unicast packet every once in a while of a station that I didn't span, but usually you won't see a second because the switch had already learned the port where the MAC resides from the answer packet and will direct the next packets only to that port. No worries here.

• The second (and unfortunately not completely uncommon) reason for this behavior could be a misconfiguration of a load balancing setup. I have encountered several customer networks where servers had network cards teamed together for fail over/load balancing (which is okay so far), but then they forgot to tell the switches about it, too. I had one case where a switch constantly tried to reach the second MAC but the server always and exclusively replied with the first MAC. That way the switch could never learn the port of the second MAC and kept flooding, until by a random chance the server decided to send a packet with the second MAC.