Wireshark-users: Re: [Wireshark-users] unicast traffic in promiscuous interface capture
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
