<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic S/N/K-Series f/w 7.31.03.0010 &amp;quot;Sender Hardware Address does not match L2 source address&amp;quot; Syslog message in FAQs</title>
    <link>https://community.extremenetworks.com/t5/faqs/s-n-k-series-f-w-7-31-03-0010-quot-sender-hardware-address-does/m-p/49963#M633</link>
    <description>Article ID: 14395 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Products&lt;/B&gt;&lt;BR /&gt;
S-Series, firmware 7.21.03.0003 and higher&lt;BR /&gt;
Matrix N-Series DFE, firmware 7.21.03.0003 and higher&lt;BR /&gt;
K-Series, all firmware &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Symptoms&lt;/B&gt;&lt;BR /&gt;
The Router Arp Process reports a MAC address mismatch in Syslog. &lt;BR /&gt;
&lt;BR /&gt;
Here are Multicast and Unicast examples of this message, from different systems:&amp;lt;165&amp;gt;Jan 2 21:39:15 10.20.30.252 RtrArpProc[3]10.2.250.191 on vlan.0.189&lt;BR /&gt;
responds to ARP requests using a Sender Hardware Address [02-bf-0a-08-&lt;BR /&gt;
fa-bf] that does not match the L2 source address [02-01-0a-08-fa-bf].&lt;BR /&gt;
Additionally the Sender Hardware Address does not exist in the Filter&lt;BR /&gt;
Database. This is often caused by Network Load Balanced Servers without&lt;BR /&gt;
a corresponding switch configuration. Please consult the release notes&lt;BR /&gt;
or configuration guide to properly configure a static multicast Filter&lt;BR /&gt;
Database Entry for: 02-bf-0a-08-fa-bf on vlan.0.189&lt;BR /&gt;
 &lt;BR /&gt;
&amp;lt;165&amp;gt;Oct 17 13:46:49 10.9.235.1 RtrArpProc[7]10.9.237.11 responds to ARP&lt;BR /&gt;
requests using a Sender Hardware Address that does not match the L2&lt;BR /&gt;
source address. Additionally the Sender Hardware Address does not exist&lt;BR /&gt;
in the Filter Database. This is often caused by Network Load Balanced&lt;BR /&gt;
Servers without a corresponding switch configuration. Please create a&lt;BR /&gt;
static Filter Database Entry for: 00-50-56-af-20-c5 (see release notes&lt;BR /&gt;
or configuration guide)&lt;B&gt;Cause&lt;/B&gt;&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Solution/Workaround&lt;/B&gt;&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
Configuration of a Static Multicast MAC is discussed in &lt;A href="http://bit.ly/1pMqKNq" target="_blank" rel="nofollow noreferrer noopener"&gt;9287&lt;/A&gt;.&lt;BR /&gt;
Treatment of a Unicast MAC as a Static Multicast MAC is discussed in &lt;A href="http://bit.ly/1jIa8r4" target="_blank" rel="nofollow noreferrer noopener"&gt;10906&lt;/A&gt;.</description>
    <pubDate>Tue, 10 Dec 2013 20:23:00 GMT</pubDate>
    <dc:creator>FAQ_User</dc:creator>
    <dc:date>2013-12-10T20:23:00Z</dc:date>
    <item>
      <title>S/N/K-Series f/w 7.31.03.0010 "Sender Hardware Address does not match L2 source address" Syslog message</title>
      <link>https://community.extremenetworks.com/t5/faqs/s-n-k-series-f-w-7-31-03-0010-quot-sender-hardware-address-does/m-p/49963#M633</link>
      <description>Article ID: 14395 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Products&lt;/B&gt;&lt;BR /&gt;
S-Series, firmware 7.21.03.0003 and higher&lt;BR /&gt;
Matrix N-Series DFE, firmware 7.21.03.0003 and higher&lt;BR /&gt;
K-Series, all firmware &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Symptoms&lt;/B&gt;&lt;BR /&gt;
The Router Arp Process reports a MAC address mismatch in Syslog. &lt;BR /&gt;
&lt;BR /&gt;
Here are Multicast and Unicast examples of this message, from different systems:&amp;lt;165&amp;gt;Jan 2 21:39:15 10.20.30.252 RtrArpProc[3]10.2.250.191 on vlan.0.189&lt;BR /&gt;
responds to ARP requests using a Sender Hardware Address [02-bf-0a-08-&lt;BR /&gt;
fa-bf] that does not match the L2 source address [02-01-0a-08-fa-bf].&lt;BR /&gt;
Additionally the Sender Hardware Address does not exist in the Filter&lt;BR /&gt;
Database. This is often caused by Network Load Balanced Servers without&lt;BR /&gt;
a corresponding switch configuration. Please consult the release notes&lt;BR /&gt;
or configuration guide to properly configure a static multicast Filter&lt;BR /&gt;
Database Entry for: 02-bf-0a-08-fa-bf on vlan.0.189&lt;BR /&gt;
 &lt;BR /&gt;
&amp;lt;165&amp;gt;Oct 17 13:46:49 10.9.235.1 RtrArpProc[7]10.9.237.11 responds to ARP&lt;BR /&gt;
requests using a Sender Hardware Address that does not match the L2&lt;BR /&gt;
source address. Additionally the Sender Hardware Address does not exist&lt;BR /&gt;
in the Filter Database. This is often caused by Network Load Balanced&lt;BR /&gt;
Servers without a corresponding switch configuration. Please create a&lt;BR /&gt;
static Filter Database Entry for: 00-50-56-af-20-c5 (see release notes&lt;BR /&gt;
or configuration guide)&lt;B&gt;Cause&lt;/B&gt;&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Solution/Workaround&lt;/B&gt;&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
Configuration of a Static Multicast MAC is discussed in &lt;A href="http://bit.ly/1pMqKNq" target="_blank" rel="nofollow noreferrer noopener"&gt;9287&lt;/A&gt;.&lt;BR /&gt;
Treatment of a Unicast MAC as a Static Multicast MAC is discussed in &lt;A href="http://bit.ly/1jIa8r4" target="_blank" rel="nofollow noreferrer noopener"&gt;10906&lt;/A&gt;.</description>
      <pubDate>Tue, 10 Dec 2013 20:23:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/faqs/s-n-k-series-f-w-7-31-03-0010-quot-sender-hardware-address-does/m-p/49963#M633</guid>
      <dc:creator>FAQ_User</dc:creator>
      <dc:date>2013-12-10T20:23:00Z</dc:date>
    </item>
  </channel>
</rss>

