As you build out your NetFoundry Network with clients, gateways, services, and AppWANs, you may want to consider High Availability options to protect your critical traffic flows from component failure. In this article we will introduce the high-level concepts of edge HA at NetFoundry.
In NetFoundry terms, the "edge" is any point on the data plane where the NetFoundry Network touches your enterprise LAN by way of a gateway endpoint. The rest of the data plane is managed by NetFoundry, and is already highly available by design.
An HA gateway is treated just like a single gateway in terms of provisioning in the console: when you assign a service to an HA gateway, both underlying gateways can serve it. And if you assign an HA gateway to an AppWAN, both underlying gateways have access to it.
When implementing edge HA you must address both traffic flow directions - ingress traffic entering the NetFoundry network from your LAN, and egress traffic that is exiting the NetFoundry network onto your LAN. Gateways can be egress, ingress, or both on demand simply by how they are configured, i.e. they do not require any separate software installs or images to perform these functions.
Network edge: The point where a NetFoundry Network connects to your LAN by way of a gateway endpoint to pass traffic to and fro.
Egress gateway: Any gateway that has one or more services assigned to it is acting as an egress point for traffic leaving the NetFoundry network toward your LAN.
Ingress gateway: Any gateway that is a member of an AppWAN is acting as an ingress point for traffic entering the NetFoundry network from your LAN.
Traffic Protection Mechanisms
|Egress Traffic Protection||Ingress Traffic Protection|
|Active/Standby||Round Robin||ECMP Routing||Cloud Routing||Default Route VIP|
|Environments||Any||Any||Enterprise network, e.g. DMZ, Datacenter||Public or Private Cloud||Branch Site|
|Max # of supported gateways||2||2||2||2||2|
|Availability||Now||2Q19||Now||AWS: Now||Manually configurable on a pair of gateways using ‘routed’ package|
|Mechanism||An HA gateway pair will protect egress traffic using a primary gateway and a hot standby gateway.||An HA gateway pair will protect egress traffic by spreading the load evenly across two gateways.||An HA gateway pair can use ECMP routing to advertise two equal-cost paths, one path toward the primary gateway and one toward the secondary, to neighboring routers.||In the cloud, the HA gateway pair can manage their routes in the cloud routing table automatically.||An HA gateway pair can share a VIP using VRRP. The VIP is designated as the default route for the local branch network.|
Egress Traffic Protection
An HA gateway pair protects egress traffic automatically. During normal operation all traffic will egress through the primary gateway. If the primary fails, egress traffic is automatically routed through the standby gateway until the primary is recovered. Once recovered, traffic flows will resume through the primary gateway. All services assigned to an HA gateway are protected automatically, it does not require any work on your part to enable.
This protection option is only available when the HA gateway has exactly 2 underlying instances. Customer traffic can originate at any NetFoundry client or any computer behind a NetFoundry gateway. Each NetFoundry client sees this protection as just another service but containing more than one gateway host. The session controller(s) will direct the traffic to the working gateway from all clients.
If the working gateway becomes unresponsive (no response from keep alive checks through WAN interface), the session controller(s) will change the status of the Standby VTC host to Active. All active sessions on the failed host will experience connection resets and will need to be restarted by each client to be forwarded through the newly activated VTC host. All subsequent new session will be forwarded to the active VTC host. When a working VTC host becomes active again, all active sessions will not be automatically moved across the working VTC host. They will be moved over time gracefully without causing connection resets.
This protection option can be used with 2 or more VTCs. Customer traffic can originate at any DVN client or Non-DVN client behind a DVN GW. Each DVN client sees this protection as just another service but containing more than one VTC host. The session controller(s) will distribute each session sequentially around the pool of active VTC hosts. For example:
Session 1 - forwarded to GW 1
Session 2 - forwarded to GW 2
Session 3 - forwarded to GW 1
...and so on.
During failures of active VTC Hosts, the active sessions on the failed host will experience connection resets and need to be restarted by each client to be forwarded through the other active VTC hosts. All subsequent new session will be forwarded to all active VTC hosts as usual. When a failed VTC host becomes active again, all active sessions will not be automatically redistributed across all active VTC hosts. They will be redistributed over time gracefully without causing connection resets.
Ingress Traffic Protection
Ingress traffic protection addresses traffic flowing from your LAN toward the NetFoundry network by way of an HA gateway pair.
You may choose one of three different mechanisms to route traffic toward your HA gateway pair. Choose the mechanism that best fits the operating environment:
Equal-cost multi-path (ECMP) is a routing strategy where next-hop packet forwarding to a single destination can occur over multiple "best paths" which tie for top place in routing metric calculations.
In a network environment where routing protocols are in use, such as a datacenter or large admin building, an HA gateway can advertise two equal-cost paths, one path toward the primary gateway and one toward the secondary, to neighboring routers. The HA gateway will propagate routes for every service in the AppWAN(s) for which it is a member.
An HA Gateway named "HA-GW-01" is a member of two AppWANs, "App A" and "App B":
|App A||10.1.50.201 TCP 80, 10.1.50.202 TCP 80|
As a member of these two AppWANs, HA-GW-01 will advertise routes for each of the three services listed above: 10.1.50.201/32, 10.1.50.202/32, and 10.2.72.0/24. Because a pair of gateways underlies HA-GW-01, neighbor routers will have two equal-cost paths toward these destinations, one toward the primary gateway and one toward the secondary. Having two equal-cost paths effectively doubles the available bandwidth provided by the gateway.
In the cloud, an HA gateway will publish their routes to the VPC routing table automatically. During normal operation, the routes will point to the primary gateway. If the primary fails, the secondary will update the route table to direct traffic toward itself. Routes are automatically pointed back to the primary once it is restored. VRRP is used for heartbeat between the two gateways. A failure of the primary takes about a second to detect and migrate routes to the secondary.
Using the example above, the cloud routing table will receive entries for the three service prefixes pointed toward the primary gateway instance. All machines in the local VPC will be able to access these services transparently without any further configuration.
Default Route VIP
At a branch site, an HA gateway pair shares a VIP using VRRP, which is designated as the default route for the local branch network. The pair operates in active/standby mode, i.e. during normal operation the primary owns the VIP. If it fails, the secondary takes over until the primary is recovered.