High availability requires Gratuitous Address Resolution Protocol 1

[abtt]

Hello,

in the AVAYA prerequisites for installing an HA pair of SBCE, it is indicated:


High availability requires Gratuitous Address Resolution Protocol (GARP) support on the connected network elements.
When the primary Avaya SBC fails over, the secondary Avaya SBC broadcasts a GARP message to announce that the secondary Avaya SBC is now receiving requests.
The GARP message announces that a new MAC address is associated with the Avaya SBC IP address. Devices that do not support GARP must be on a different subnet with a GARP-aware router or L3 switch to avoid direct communication.
For example, to handle GARP, branch gateways, Medpro, Crossfire, and some PBXs/IVRs must be deployed in a different network from Avaya SBC, with a router or L3 switch.
If you do not put the Avaya SBC interfaces on a different subnet, after failover, active calls will have a one-way audio.
Devices that do not support GARP continue sending calls to the original primary Avaya SBC.

I am going to install a pair of SBCs (VMs), I have created several VLAN interfaces.
This will be in a CISCO environment, 3850 L3 switches and 2960 switches.
How to check that GARP is enabled or not?

I don't know the possible effects of enabling it or not. There are a lot of other things on these switches.

 

[JayNEC]

a GARP is just an ARP broadcast that wasn't requested. Some devices will pay attention to it and update their ARP tables, and some won't. Some may have it disabled as it can be a security risk.

So, if a Medpro has a given MAC address in it's ARP table for the SBC's IP address and a GARP is sent, a Medpro won't update the ARP table and will keep sending packets to the old MAC address. Causing one-way audio. At least until the ARP table entry expires and gets refreshed with a normal ARP.

If the medpro is in a different subnet and has to talk to a router in order to reach the SBC, it won't have an ARP entry for the SBC. It always sends to the router.

So, it's the router that needs to pay attention to a GARP in order for the change of MAC address to be learned. For L2 switches this won't matter. It's just the L3 devices that this applies to.

To be honest, I didn't know that Medpros and Gateways didn't handle GARP. I think “no ip arp inspection” in a media gateway will make GARP work there though.


New England Communications

http://www.necomm.com