Reset Search



ARP behavior is different in RX code 2.9

« Go Back


TitleARP behavior is different in RX code 2.9

The handling of ARP traffic and the initial packet of any Broadcast, Unknown unicast or Multicast flow (BUM traffic) is dropped.

The 2nd packet goes through and traffic forwards normally until the MAC table is flushed for any reason.

Software Release: RX 2.9x
Fixed in Version: N/A
In code 2.9 code Brocade introduced MCT. The MCT feature was ported from our existing NetIron devices.

As a consequence the L2 ARP handling of the router was changed to allow for the MCT feature to be included.

In previous releases of code, if the RX received traffic for which there was anARP entry but not a MAC entrythe router would ARP for the host and simultaneously flood the traffic in the vlan it was received in. If an ARP response came in then the MAC would be programmed and consequently traffic would be forwarded in hardware.

In code train 2.9 the RX will not flood the traffic anymore, even if there is an ARP entry.The behavior is now to delete the existing ARP entry if there is noMAC entry. This will result in unknown packet being buffered,a new ARP request to be sent anda host unreachable to be sent back to the source until such time as the destination host is resolved and programmed.
For the MAC address that has an ARP entry but not a MAC entry, the default behavior is to delete the ARP entry. However, to handle topologies that involve MicroSoft Network Load Balancing (MSNLB) servers, a new CLI commandis introduced in the config mode.

This command is:

arp-l2-mac-match-flag set

The arp-l2-mac-match-flag set command enables sending of ARP-requests instead of deleting the ARP entry for the MAC address that has an ARP entry but not the MAC entry.

The command no arp-l2-mac-match-flag set restores the default behavior.
Additional notes



Was this article helpful?



Please tell us how we can make this article more useful.

Characters Remaining: 255