Hello Alex, >>> "Alex Nedelcu" <[EMAIL PROTECTED]> 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 _______________________________________________ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
