This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Seeing unicast traffic on a switchport without spanning

3

I ran a packet capture on a client computer connected to a non-spanned switch port. I expected to see only broadcasts and multicast traffic. What I did get was multicast, broadcast AND - some unicast traffic to/from clients other than my capture client host. Why would I be seeing unicast traffic like this on a switched client?

The capture host is running tshark 0.99.4 on Linux 2.4.27-3-686.

asked 22 Sep '10, 12:15

Labnuke's gravatar image

Labnuke
61449
accept rate: 0%

edited 22 Sep '10, 14:22

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245

Labnuke, I updated the title of your question to make it more general and easier for people to find. Hope you don't mind :-)

(22 Sep '10, 14:22) SYN-bit ♦♦

No worries - I struggled with how to set the subject to begin with.

(24 Sep '10, 08:24) Labnuke

5 Answers:

6

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.

answered 22 Sep '10, 14:20

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

The network is a /16 network but I don't think there are very many hosts on this LAN (<500). So would full mac-address-table really be a potential cause in this case?

There is not a second router in this environment. Just a single router to outside networks.

(24 Sep '10, 08:34) Labnuke

3

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!!!

answered 29 Sep '10, 12:33

erics's gravatar image

erics
462
accept rate: 0%

+1 for erics. We had a similar issue (not really a problem) with seeing traffic we weren't supposed to see on a host. We pinged the ip addresses of the traffic from the work station and sure enough, they went away. The ARP timeouts on the different devices were set to 5000 and 300. I'm gonna try and remember this nifty troubleshooting tip. Thanks.

(25 Jan '11, 14:57) RobertM

We just had exactly the same problem on our Cisco core - massive amount of UDP packets being broadcast out to all switch ports, strange thing was that there was an entry in the ARP cache for the destination IP, pinging the detination IP from the core solved the issue, I guess we need to look at our ARP aging times as well!

Cheers erics!

(12 Jun '13, 06:55) Gaz Jones

3

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.

answered 29 Sep '10, 12:58

GeonJay's gravatar image

GeonJay
4705922
accept rate: 5%

2

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.

answered 22 Sep '10, 13:45

lchappell's gravatar image

lchappell ♦
1.2k2730
accept rate: 8%

Thanks for the feedback. This is a Nortel BayStack 470 switch. I will confirm the mac addresses in the packet and ses what they show. I know that there is no port spanning setup so that would not be the cause of this.

(24 Sep '10, 08:24) Labnuke

Are you referring to the IG bit on the destination MAC? If so, that is set to 0.

Based on what I see today on a capture on this host that your #1 suggestion is the correct one. That for some reason, the clients have an old address cached in ARP and the switch does not know where the device is so floods all ports with that traffic.

(24 Sep '10, 10:55) Labnuke

So, this then leads to the question about how often does a client on the same LAN do an ARP before communicating? I'm sure it depends on OS version and how often ARP entries timeout. But what if the traffic is coming from an external network? When will the router or layer 3 device do an ARP?

(24 Sep '10, 10:58) Labnuke
1

Local routers/layer 3 devices will ARP when their ARP cache times out and - yup - you're right - it depends on the OS. As a reminder to readers - ARP packets are non-routable because they have no IP header so any ARP traffic you see is local only.

(24 Sep '10, 12:11) lchappell ♦

2

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.

answered 25 Sep '10, 15:23

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%