Article ID: 14395
Products
S-Series, firmware 7.21.03.0003 and higher
Matrix N-Series DFE, firmware 7.21.03.0003 and higher
K-Series, all firmware
Symptoms
The Router Arp Process reports a MAC address mismatch in Syslog.
Here are Multicast and Unicast examples of this message, from different systems:<165>Jan 2 21:39:15 10.20.30.252 RtrArpProc[3]10.2.250.191 on vlan.0.189
responds to ARP requests using a Sender Hardware Address [02-bf-0a-08-
fa-bf] that does not match the L2 source address [02-01-0a-08-fa-bf].
Additionally the Sender Hardware Address does not exist in the Filter
Database. This is often caused by Network Load Balanced Servers without
a corresponding switch configuration. Please consult the release notes
or configuration guide to properly configure a static multicast Filter
Database Entry for: 02-bf-0a-08-fa-bf on vlan.0.189
<165>Oct 17 13:46:49 10.9.235.1 RtrArpProc[7]10.9.237.11 responds to ARP
requests using a Sender Hardware Address that does not match the L2
source address. Additionally the Sender Hardware Address does not exist
in the Filter Database. This is often caused by Network Load Balanced
Servers without a corresponding switch configuration. Please create a
static Filter Database Entry for: 00-50-56-af-20-c5 (see release notes
or configuration guide)
Cause
Some load balancers respond to ARP requests with their physical MAC address in the L2 portion of the response, and a virtual MAC address in the L3 portion. This causes packets destined to those addresses to be flooded because a filter database entry will not exist for the virtual MAC address. Such flooding is undesirable from both security and network utilization perspectives.
This Syslog message reports the flooding condition once per hour (using slightly different messages for Multicast and Unicast MACs), stating that a static filter database entry should be added in order to avoid the flooding and soft forwarding.
Solution/Workaround
As desired, this message may be suppressed by lowering the logging severity level ('set logging application RtrArpProc level 4'); but the best solution is to statically configure the relevant multicast or unicast MAC address as suggested in the message.
Configuration of a Static Multicast MAC is discussed in
9287.
Treatment of a Unicast MAC as a Static Multicast MAC is discussed in
10906.
