Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] unicast traffic in promiscuous interface capture

From: "Jim Young" <SYSJHY@xxxxxxxxxxxxxxx>
Date: Thu, 31 Jan 2008 11:13:56 -0500
Hello Alex,

>>> "Alex Nedelcu" <alexpheno@xxxxxxxxx> 01/31/08 10:04 AM >>>
> It only has an ethernet card. I was capturing traffic to see 
> what type of protocols are in use in the network when i noticed 
> these packets that were not broadcast but unicast destined for 
> other computers, based on my knowledge in a switched network 
> these packets were not supposed to reach my NIC ...

When connected to an ethernet switch it _IS_ normal to
occasionally see unicast packets destined for other computers 
show up on the "wrong" switch port.   This is generally known 
as "flooding" and can happen for several reasons.   

When a specific MAC address for any particular system gets 
purged from the switch's forwarding database (FDB) the 
switch will (generally) flood the unicast packet to all of its ports.

I believe I've seen this happen when the switch's FDB table has 
been (intentionally) purged (for example after a network 
topology change that results in Spanning Tree or EAPS 
transition).   If you have some sort on Layer 2 problem (loop?)
you MIGHT see more then the occasional flooded unicast packet.

Be aware there are also techniques used by people for generally 
bad reasons to force switches to flood all packets.   This forced 
flooding can happen when there are too many unique MAC addresses 
seen by the switch.  Switches maintain FDB tables to map MAC 
addresses to a specific port.  Entries within these tables are aged 
out after a certain amount of time (usually 5 minutes for Cisco 
and Extreme switches but the timeout is configurable).   These 
tables also have a finite size.  I've seen specs for various switches 
report maximum FDB table size from as little as 256 to 16000 (or 
more) entries.   If and when a switch's FDB table should become 
full it will often revert to behaving like a hub and start flooding 
unicast packets to all ports.

Now in one odd case for one local (layer 2) peer machine I would 
see 15 minutes worth of unicast SNMP trap packets followed by 
five minutes of nothing.  It turns out the target of the SNMP traps 
was configured in such a way that it replied to NOTHING but 
ARP requests.   The switch's FDB table had a five minute timeout.   
But the router's ARP table had 20 minute timeout.  After 20 
minutes the router's ARP entry for the SNMP trap dest host 
would expire.   The next SNMP trap packet seen by the router 
for that host would result in the router sending an ARP request 
onto the local segment to determine the host's MAC address.   
The SNMP trap dest machine would reply to the router's ARP 
request.   As the SNMP trap dest host's ARP reply traversed the 
switching infrastructure, its MAC address would be (re)learned 
and added to the switch(es) FDB tables.   So for five minutes 
any further unicast packets for that particular machine would 
no longer be flooded.  But after five minutes the FDB entry 
would be purged from the switches FDB tables because the 
SNMP trap dest machine itself had NOT generated any further 
network traffic.   After the FDB entry was purged any subsequent 
unicast packets would again be flooded until the router's ARP 
entry expired which would start the whole 20 minute cycle all 
over (ARP, 5 minutes switched, 15 minutes flooded). 

I hope you find this info useful.

Jim Young