06-18-2010 07:12 PM
I have an MLX this won't update it's arp cache based on gratuitous arps. Here is the setup:
MLX --(layer 2)--> FESX --> lvs load balancers
When an lvs server fails, the secondary detects it within milliseconds, takes over the ips from the failed server, and sends a gratuitous arp annoucing that the ip addresses are now associated with it's mac address. This part all works fine and as mentioned is virtually instantaneous. In fact I've done tcp dumps to ensure the gratuitous arps are occuring and that this is not simply a software misconfiguration.
However, the MLX refuses to update it's arp cache and continues to send traffic to the mac address of the failed server. Once the arp entries expire, it pick up the new mac address association and everything is working again. This takes several minutes which is not acceptable.
We are running a very old version of the MLX firmware (3.3) which as far as I can tell is known to have this issue. Based on the NetIron configuration guides I've looked at this problem has been addressed. If you look at page 744 of the the guide for the 05.0.00, it seems to clearly indicate that you can configure the MLX to update it's arp cache based on gratuitous arps.
However, Brocade continues to tell us that this will not work and that the MLX will never update it's cache in response to a gratuitous arp. I'm confident that whoever our network engineer is talking to at Brocade is just plain wrong.
Does anyone else have a setup that deomonstrates the ability of the MLX to acknowledge gratuitous arps properly? I undstand why you might not always want your network gear to accept gratuitous arps as vaild, but it is commonly used for vrrp / ha set ups.
We can probably work around this issue by reconfiguring our lvs servers to fake a mac address and move it from one machine to the other when the failure occurs, but it seems silly to solve the problem in this way when there is clearly a more straight forward solution.
Maybe I'm completely of base, but I really want a better answer than "nope, can't do that" when the documentaion seems to indicate otherwise.
Thanks in advance for any help you can provide.
06-21-2010 05:32 PM
My understanding is that Brocade is correct - the MLX will not accept gratuitous arps - when in layer 2 also help to prevent
Layer 3 when using VRRP/E yes and this works.
The section on the manual Page 744 is for
Enabling dynamic ARP inspection on a VLAN
ARP and Dynamic inspection ARP entries need to be configured for hosts on untrusted ports. Otherwise, when Dynamic ARP Inspection checks ARP packets from these hosts against entries in the ARP table, it will not find any entries for them, and the device will not allow and learn ARP from
an untrusted host.
The below seems to confirm no garp for layer 2
Enabling proxy ARP
Proxy ARP allows the NetIron router to answer ARP requests from devices on one network on behalf of devices in another network. Since ARP requests are MAC-layer broadcasts, they reach only the devices that are directly connected to the sender of the ARP request. Thus, ARP requests do not
For example, if Proxy ARP is enabled on the NetIron router connected to two subnets, 10.10.10.0/24 and 126.96.36.199/24, the NetIron router can respond to an ARP request from 10.10.10.69 for the MAC address of the device with IP address 188.8.131.52. In standard ARP, a request from a device in the 10.10.10.0/24 subnet cannot reach a device in the 184.108.40.206 subnet if the subnets are on different network cables, and thus is not answered.