--- title: "SD-WAN redundancy" canonical: "https://docs.aryaka.com/space/KNOW/1299972471/SD-WAN%20redundancy" format: markdown --- Aryaka's SD-WAN offering has redundancy built into it at several layers. This ensures quick failover and enables increased network uptime. Some types of redundancy are available at no additional customer cost while others are optional at an additional cost. Aryaka's SD-WAN solution offers redundancy for the following components: ANAPs POPs Site ISPs and tunnels Core links Hybrid WAN Redundancy for each of these components is described in this document. Additionally, there are other technologies that allow the network to withstand failures and other network events including packet loss, congestion, and jitter. These issues are addressed by optional Aryaka Link Assure features including loss recovery, dejitter, compression, deduplication, load balancing, and so on. For more information, see Link Assure policies . ANAP Redundancy Aryaka supports paired, redundant 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 is supported for all three ANAP insertion modes: Simple Routed Mode Edge Routed Mode Inline Routed Mode 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: EDGE ROUTED MODE 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. Contact Aryaka to discuss your ANAP redundancy needs and the associated charges.  POP Redundancy Some mission-critical sites like data centers or company headquarters require an extra level of redundancy. In these cases, POP Redundancy can be deployed at an additional cost to the customer. To achieve POP redundancy, the site must deploy a second ANAP. In this configuration, both ANAPs are active and each ANAP builds tunnels to a different POP. If the ANAPs are connected to an L3 device on the LAN side, each ANAP is configured to learn an identical route list but with different routing costs. These routes are then advertised to the local L3 device, which uses this routing information to decide which ANAP must receive the traffic that is then forwarded to the remote site. When an ANAP fails to connect to its corresponding POP, it withdraws its routes and the router at the site can choose to route to the secondary ANAP. If the ANAPs are connected to an L2 device on the LAN side, the VARP is configured between the two ANAPs. The primary ANAP becomes the active ANAP and owns the VAIP while the secondary ANAP operates as the standby. ANAPs can be configured for static routing by setting VAIP as a gateway for all clients on the site. When the primary ANAP fails to connect to its corresponding POP, the secondary ANAP becomes active and carries traffic to the remote sites.  Note that POP redundancy can be established for ANAPs deployed in any insertion mode. Site ISP Redundancy A site connecting to Aryaka can use two ISPs to achieve redundancy. The redundancy models described in this section can be enabled at no additional charge.  Sites without ANAPs Sites that do not have ANAPs can connect to an Aryaka POP using IPSec tunnels from a router or a firewall at the site. Up to two tunnels can be configured from each site connecting to an Aryaka POP. These tunnels can be configured using IPs from two different ISPs. The tunnels are configured in an active/standby mode with one tunnel designated as the primary tunnel in the Aryaka configuration. The primary tunnel is preferred over the secondary tunnel. The primary and secondary tunnels use DPD to exchange health information with the Aryaka POP. These exchanges are made at configurable intervals and when DPD determines that the primary tunnel is down, the traffic switches over to the secondary tunnel. The rate of failover between tunnels is also configurable. Sites with ANAPs For sites that include an Aryaka-provided ANAP device, there are five site ISP redundancy deployment scenarios: Site-to-POP Connectivity Internet Offload Site-to-site Connectivity Site-to-cloud Transport Vendor Connectivity Site-to-cloud Security Vendor Connectivity Each of these scenarios is described in a section that follows. Site-to-POP Connectivity Sites with ANAPs can connect to an Aryaka POP using two IPSec tunnels. These tunnels are configured from each site in active/standby mode with one tunnel designated as the primary tunnel in the Aryaka configuration. The primary tunnel is preferred over the secondary tunnel. In addition to using DPD, the ANAPs exchange ping probes to determine the health of the tunnels and when the primary tunnel is determined to be unhealthy or down, the secondary tunnel takes over. The rate of failover between tunnels is configurable. To use both ISPs in an active/active mode to achieve load balancing, ask us about our Link Assure feature. Internet Offload Sites that have ANAPs in Edge Routed Mode can terminate their ISPs on the ANAP's M1 and M2 interfaces if they have copper connections from the provider, or on F1/FM1 and F2/FM2 interfaces of the ANAP if they have fiber connections from the provider. In these cases, the ANAP runs an internal service called Internet Traffic Controller that measures the health of each ISP using ICMP to a configured IP (typically 8.8.8.8) on the internet and uses the ICMP health to determine if the local ISP is healthy. One of the ISPs can be designated as the primary ISP for internet offload and if it is found to be unhealthy, then the ANAP's Internet Traffic Controller uses the secondary ISP. Site-to-site Connectivity In addition to the tunnels to an Aryaka POP, the ANAPs can have tunnels to other ANAPs over the internet to serve as a backup network or as a hybrid network. When connecting to a remote site, the two ANAPs set up a tunnel between them that can send traffic on any of following four paths: From ANAP 1 to local internet link 1 to ANAP 2 From ANAP 1 to local internet link 1 to local internet link 2 to ANAP 2 From ANAP 1 to local internet link 2 to ANAP 2 From ANAP 1 to local internet link 2 to local internet link 1 to ANAP 2 These paths are shown in the following graphic: To use these paths in active/active mode to achieve load balancing, ask us about our Internet Link Assure feature. Site-to-cloud Transport Vendor Connectivity A site that deploys an ANAP can connect to a Cloud Transport Vendor—for example, Azure Virtual WAN. The connection to a vendor's hubs or gateway is achieved using redundant tunnels. These tunnels are deployed in an active/standby mode.  Site-to-cloud Security Vendor Connectivity A site that deploys an ANAP can connect to a cloud security vendor—for example, Zscaler or Check Point. The connection to a security vendor is achieved using redundant tunnels in an active/standby mode.  Core Link Redundancy This connection type connects two Aryaka POPs to each other using redundant layer 2 links whose health is monitored by Aryaka. These links are switched automatically in the event of a failure. Layer 3 links supplement redundant layer 2 links in the rare event that all layer 2 links at a POP experience an outage. Hybrid WAN Redundancy Aryaka includes two networks that provide site-to-site connectivity to an Aryaka POP: VPN Path Aryaka—Aryaka core network that connects a site to an Aryaka POP.  VPN Path Internet—Sites with an ANAP can achieve site-to-site connectivity using the internet. These two networks can be implemented in a Hybrid WAN configuration such that the VPN Path Internet serves as the backup to the VPN Path Aryaka. If a site's tunnels to the Aryaka POP goes down, it can automatically reach the remote site using VPN Path Internet.  The Hybrid WAN configuration can also be used where the two sites prefer to use VPN Path Internet connection for specific applications. In this case, traffic can be switched to VPN Path Aryaka in case VPN Path Internet fails. In this topic Related topics ANAP insertion topology Link Assure for VPN Path Aryaka Link Assure for VPN Path Internet