--- title: "High Availability of ANAPs" canonical: "https://docs.aryaka.com/space/KNOW/1299775628/High%20Availability%20of%20ANAPs" format: markdown --- Aryaka supports paired, redundant Aryaka Network Access Points (ANAPs) that use the propriety  virtual ANAP redundancy protocol  (VARP). When deployed, VARP implements two ANAPs—one in active mode and the other in standby mode. These redundant active/standby ANAPs must have identical configuration, including which POP that they connect to, what tunnels they bring up, what sizing they are configured for, and so on.  The two ANAPs deployed in a VARP configuration exchange advertisements at configurable intervals and elect one to become the active ANAP. This mechanism is also used to detect failures and swap roles when necessary. When a paired ANAP becomes active, it uses a virtual IP address and sends a gratuitous ARP declaring that it hosts the virtual IP. This causes the other paired device to update its ARP table. In addition to taking over the virtual IP, the active ANAP begins running the various engines that are required to connect to the Aryaka Cloud, to detect and identify traffic, to route traffic, and to optimize traffic. VARP with various insertion models VARP is supported for all three ANAP insertion modes: Simple Routed Mode Edge Routed Mode Inline Routed Mode These modes are described in the sections that follow. Simple Routed Mode In Simple Routed Mode, an ANAP is installed at a site by connecting its LAN interface to another L3 device—either a router or a firewall. This L3 device receives routes from the ANAP using RIP or BGP. The traffic that arrives at the ANAP from the LAN is encrypted and sent over IPSec tunnels to the POP.   To achieve redundancy for an ANAP installed in this mode, a second ANAP is installed at the site with its LAN interface wired to a port on the same L3 device, and the ports on the two ANAPs on the same VLAN. The active ANAP owns the VAIP and advertises routes to the L3 device on its LAN interface and initiates tunnels to the POP and other peers on the LAN interface. Edge and Inline Routed Modes These two modes are connected in a similar manner. In the Edge Routed Mode, the ANAP terminates the customer ISPs at the active ANAP's M1 interface and the standby ANAP's M2 interface: In the Inline Routed Mode, the ANAPs are located behind the customer's edge routers (represented by the circles on the ISP links in the following graphic): In both cases, a second ANAP is deployed at the customer site. The active ANAP owns the VAIP and advertises routes to the L3 device on its LAN interface and initiates the tunnels to the POP and other peers on its M1 and M2 interfaces. Electing an active ANAP The ANAPs that make up a VARP pair send periodic unicast advertisements to each other. If the standby ANAP detects that it has not received an advertisement from the Active ANAP for its configured timeout period, it declares the then-active ANAP to be down and takes over the active role.  Depending on your needs, your site can be configured with a fuse. The timers (two of which are shown in the following table) associated with a fuse are configurable. The fuse setting decides how quickly failover happens to the various components of Aryaka's network.  Fuse Advertisement Interval Timeout Slow Five seconds 30 seconds Fast Five seconds 30 seconds Superfast Three seconds 15 seconds Contact Aryaka Customer Support to discuss your fuse needs. When the ANAP becomes active it uses a virtual IP address and sends a gratuitous ARP declaring that it hosts the virtual IP. This causes the other paired device to update its ARP table. In addition to taking over the virtual IP, the active ANAP begins running the various engines that are required to connect to the Aryaka Cloud, to detect and identify traffic, to route traffic, and to optimize traffic. It continues to send advertisements to the standby ANAP.  Meanwhile, the standby ANAP has detected that the other ANAP in the LAN network has been elected as active and receives regular advertisements from the active ANAP. It sends its own advertisements at regular intervals to the active ANAP. The standby ANAP continues to run some of the engines required to take over traffic so that failover can be achieved quickly. In the event that the active ANAP experiences failure and the standby ANAP does not receive an advertisement from the active ANAP for a configured period of time, the standby ANAP declares that the active ANAP is down and takes over the active role. In doing so, it sends a gratuitous ARP, initiates all necessary engines, and so on. The active ANAP is always in contact with the Aryaka Provisioning Server and the Aryaka POP to which it connects. This ensures its configuration and software version are updated as required. The active ANAP also posts its interface and other health statistics and statuses to the Aryaka POP over its IPSec tunnels.  The standby ANAP does not have tunnels to the Aryaka POP. It reports its health statistics and statuses to the POP using the active ANAP. It also keeps configuration and software updates by communicating with the active ANAP.  The active ANAP—if configured to do so—performs compression and deduplication . This is done using Aryaka's proprietary Advanced Redundancy Removal . To achieve this, the ANAP stores encrypted customer traffic. This encrypted store is not replicated to the standby device. So when a device fails over to its redundant counterpart, the store is lost and is rebuild as new traffic is initiated by the site.  The active ANAP can be forced to relinquish its role if required, for example, during a maintenance window. Contact Aryaka Customer Support  if this is required. Failover scenarios The active ANAP stops sending VARP advertisements and the standby ANAP become active when any of the following events occur: The ANAP loses power. The LAN interface of the ANAP has been disconnected or is identified as down. All internet-facing interfaces (M1/F1, M2/F2, and so on) of the ANAP have been disconnected or are identified as down—this applies to ANAPs using Edge Routed Mode or Inline Routed Mode. All tunnels from the ANAP to the POP are down. The tunnels from the ANAP to the POP are up but the probes to the POP are not receiving responses. The forwarding or routing engines have failed. When an active ANAP is rebooted and it comes back up within the timeout interval, it regains the active role. Ignore internet health for VARP failover An ANAP can be configured to ignore the health of its internet-facing interfaces in favor of its MPLS connectivity if required. The topology depicted in the graphic, shows a site with two ANAPs in VARP, but only one internet service provider (ISP) wired to the M1 interface of the top ANAP. This ANAP would normally failover to the second ANAP if the ISP wired to M1 goes down.  The ANAP can be configured to ignore the M1 interface health if the site has an MPLS CE wired to the WAN interface of the ANAP.  Contact Aryaka Customer Support to discuss this requirement. In this topic Related topics SD-WAN redundancy ANAP insertion topology