When a Stingray fails (or I take it down for maintenance), the traffic IP address is correctly transferred to a different Stingray, but it does not receive any traffic. Why is this?
Solved! Go to Solution.
When Stingray rises a Traffic IP Address, it broadcasts a number of ARP replies to inform the attached Layer 2 network that it should update its ARP cache. This is to ensure that Ethernet frames directed to the Traffic IP Address in question are sent to the correct hardware interface (on the Stingray) via the correct LAN circuit.
By default, Stingray will send 10 of these ARP broadcasts. In some scenarios, we find that Cisco hardware will ignore ARP broadcasts for a short period of time. The result is that, after Stingray fails over, frames will be sent to the wrong LAN segment, ultimately causing connection timeouts to your Traffic IP Addresses. So far, we know that this affects the PIX 506E Firewall, but it may apply to other products as well.
To identify the problem, you can log into the Cisco device and use the 'show arp' command to view the ARP table. If you discover that a Traffic IP Address is associated with the wrong MAC address, you can use the 'clear arp' command to flush the table, which should correct the problem.
To prevent future occurrences, we have found that increasing the number of ARP broadcasts sent by Stingray from 10 to 100 works reliably. To make this change, please log into the admin interface and navigate to: System -> Global -> Traffic Manager Fault Tolerance ...and change the "flipper!arp_count" value from 10 to 100.
When Stingray rises a Traffic IP Address, it broadcasts a number of ARP replies to inform the attached Layer 2 network that it should update its ARP cache. This is to ensure that Ethernet frames directed to the Traffic IP Address in question are sent to the correct hardware interface (on the Stingray) via the correct LAN circuit.
By default, Stingray will send 10 of these ARP broadcasts. In some scenarios, we find that Cisco hardware will ignore ARP broadcasts for a short period of time. The result is that, after Stingray fails over, frames will be sent to the wrong LAN segment, ultimately causing connection timeouts to your Traffic IP Addresses. So far, we know that this affects the PIX 506E Firewall, but it may apply to other products as well.
To identify the problem, you can log into the Cisco device and use the 'show arp' command to view the ARP table. If you discover that a Traffic IP Address is associated with the wrong MAC address, you can use the 'clear arp' command to flush the table, which should correct the problem.
To prevent future occurrences, we have found that increasing the number of ARP broadcasts sent by Stingray from 10 to 100 works reliably. To make this change, please log into the admin interface and navigate to: System -> Global -> Traffic Manager Fault Tolerance ...and change the "flipper!arp_count" value from 10 to 100.