Unicast data sent to all ports on VLAN

[ebrandertsa]

Gurus,

I'm seeing what appears to be all data on a VLAN being set to every other port on that VLAN across multiple switches connected via dot1q trunks. A packet capture shows me that all the traffic is destined for a single MAC address, one that does not show up in any MAC address table on any of the switches. The first 6 digits of the MAC is 00-50-5a indicating something from Network Alchemy which is now owned by Nokia. We have CheckPoint firewalls on Nokia hardware so I'm thinking they are involved somehow. Am I right to assume that since it's not in the table, Cisco is going to  send it to every port in the VLAN until it learns the MAC - which looks like it will never happen?

Any suggestions as to how I find out why the traffic is destined to this MAC address yet it's not in the MAC address table?

[Chad Peterson]

Hi Eric,

You are correct, you are seeing expected behavior.  By default all switches should flood unicast traffic that is destined to an unknown mac address.

This can happen for a variety of reasons, but if you don't see the mac address anywhere, its possible that the host does not respond using that MAC address.  What I would do to find it is to put wireshark on a PC in the same vlan that you see the flooding.  Then PING the IP address that you see this flooded traffic for.  What we are looking for is the ARP Response.  Perhaps the ARP Response will be sourced from a different MAC address than where it reports the address to be.  If that holds true, you can then track down who is sending this ARP Response and figure out why.

If the process of pinging it and forcing the host to send an ARP packet fixes the problem, likely the end host just doesn't put much data on the network, and the MAC address simply times out.  In this case you have some options like increasing your CAM aging timer to be higher than ARP timeout.  Depending on the situation this may or may not work, but its a good trick to force the CAM table to be up to date w/ the ARP table.

Chad

[ebrandertsa]

Thanks for the reply.

I think I found it: Checkpoint cluster is set to use "Unicast mode" for clustering. CheckPoint then blames Cisco for not honoring it's ARP reply so I have to create static ARP entries for every address hosted by the CheckPoint.  Anyone experienced this and can speak to any gotchas I need to be concerned with?

[Chad Peterson · Accepted solution]

I'm not sure anyone is at fault here. Normally clustering device that

run in a "unicast mode" will send an ARP that binds the IP address to a

MAC address that will never be used to source a packet. Because the mac

never source a packet, we never install that mac address, causing

unicast flooding.