0

I hook up a laptop via gigabit Ethernet to my corporate network and run Wireshark on the interface. I expect to see all broadcast and multicast traffic and unicast traffic either originating from or destined to my laptop's IP only.

For some reason, I also see all unicast traffic destined for one other IP on the network.

Why might that happen? Has anyone seen this behavior before and know what might cause it?

IIUC, switches are supposed to note the MAC address of packets received on a port, recording them in the FIB, and route packets destined for that MAC address to just the port where something from that MAC was last received. In this case, the switch must not be receiving packets from the MAC address associated with that IP, apparently even though ARP resolved the IP to a MAC. As a result, since the MAC is not found in the FIB, it broadcasts the packet to all ports. But what kind of odd configuration would cause that?

petiepooo
  • 3
  • 2

1 Answers1

1

This means that destination MAC address is not found in FIB. It may be caused by short MAC aging timer set on a switch (shorter than default ARP TTL) or by a FIB resource exhaustion due to network size (too many MACs for FIB to store) or an active attack on a switch - software generating frames on the wire with different random source MACs to cause the above resource exhaustion filling FIB with these generated MACs and triggering the behavior you see for the attacker to exploit.

Peter Zhabin
  • 2,276
  • 8
  • 10
  • It's only one other IP, so I don't think it's FIB exhaustion. All other IPs are working correctly, including more recently added systems. Same for MAC aging, assuming that would be a global switch setting. – petiepooo Jun 16 '22 at 11:39
  • Could it be a system that has two interfaces on the network, one with the MAC it's advertising with ARP and one with another MAC that it's using for all outgoing packets? If I ping that host, I see ARP resolve to the same MAC as the source MAC on the ping response and the destination MAC on all packets I shouldn't be seeing, so I don't think that's it. – petiepooo Jun 16 '22 at 11:41
  • If you could provide a tcpdump trace for these frames it could yield some more info, but generally a stray unicast frame is what has been described above. It could be that there somewhere exists a static ARP entry that prevents source system from doing proper ARP requests and coupled with rare traffic from the destination system to update the FIB this could also trigger the behavior you're seeing – Peter Zhabin Jun 16 '22 at 12:36
  • To be clear, it's not just a couple of stray packets. It appears every port on the switch is receiving every packet destined for that one host. I see one side of every conversation it has with all other hosts no matter which port of the switch I connect to. – petiepooo Jun 16 '22 at 16:22
  • I appreciate your thoughts, PZ. Thank you for suggesting some possibilities. Unfortunately, I cannot provide traces; I can only describe them. – petiepooo Jun 16 '22 at 16:23
  • I think I am on-track with asymmetric routing. Cisco has a technote describing it at https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/23563-143.html – petiepooo Jun 16 '22 at 16:54
  • It appears whatever it was was transient. By the time the network engineer who could access switch configs and address tables was on, the problem has disappeared. I would still be interested to know what other scenarios people have seen that have caused this. – petiepooo Jun 22 '22 at 17:47