This section describes ICMP failover probes.
In order to address a failure in zones #1 or #2 of the VeloCloud Gateway topology diagram, the VeloCloud Gateway supports the optional ability to send failover probes. These probes will ping a single destination IP address at the specified frequency. If the threshold for successive missed ping replies is exceeded, the Gateway will mark the VeloCloud Gateway’s routes as unreachable. While the routes are marked as unreachable due to this probe failure state, probes continue to be sent. If the same threshold is exceeded for successive successful pings replies, the VeloCloud Gateway will mark the routes as reachable again.
For example, consider the case in which a user has configured a frequency of two seconds and a threshold of three.
- VeloCloud Edges connect to the primary VeloCloud Gateway. The primary VeloCloud Gateway marks routes as reachable.
- The Primary VeloCloud Gateway fails to receive a reply for three successive probes (~6 seconds).
- The Primary VeloCloud Gateway marks routes as unreachable and communicates this to all connected Edges.
- Edges begin routing traffic via the alternate VeloCloud Gateway.
- Connectivity is restored and the primary VeloCloud Gateway receives three successive replies from probes.
- The Primary VeloCloud Gateway marks routes as reachable and communicates this to all connected Edges.
- Edges route traffic back through the primary VeloCloud Gateway.
This could be used in failure scenario #1 to ping an IP address on the Provider Edge router itself. This could be used in failure scenario #2 to ping the actual Call Controller.
Stateful Ping Responder
To address a failure in zone #2 or #3 of the Partner Gateway topology diagram, the VeloCloud Gateway supports an optional stateful ping responder. This allows the configuration of a virtual IP address (which must be different from the interface IP address) within the VeloCloud Gateway that will, based on configuration, either respond to pings always (Gateway service is running) or conditionally based on WAN connectivity (Gateway has VPN tunnels connected).
This can be used in failure scenario #1 by having the Provider Edge router ping the ping responder, as the VeloCloud Gateway becoming unreachable would cause the IP SLA on the Provider Edge router to fail. This could also be used in failure scenario #3 by having the VeloCloud Gateway only respond if VPN tunnels are connected - this is similar to the behavior with BGP (no clients connected means no client routes).
The Partner Gateway will respond back to the Provider Edge (PE) router ICMP request based on the IP SLA configured in the PE router. The Stateful Ping Responder PE router should be configured as shown below with proper VLAN tag information.
!IP-SLA configuration to send ICMP request to gateway virtual IP ip sla 1 icmp-echo 192.168.10.10 source-ip 192.168.10.1 vrf CUSTOMER1 threshold 1000 timeout 1000 frequency 2 ip sla schedule 1 life forever start-time now !tracking the IP SLA for its reachability track 1 ip sla 1 reachability !all the routes will reachable only when SLA probe succeeds ip route vrf CUSTOMER1 0.0.0.0 0.0.0.0 192.168.11.101 track 1 ip route vrf CUSTOMER2 0.0.0.0 0.0.0.0 192.168.12.101 track 1 ip route vrf CUSTOMER1 10.0.0.0 255.0.0.0 192.168.10.10 track 1 ip route vrf CUSTOMER2 10.0.0.0 255.0.0.0 192.168.10.10 track 1 ip route vrf CUSTOMER1 192.168.100.0 255.255.255.0 192.168.10.10 track 1
Caveats When Using NAT Hand-off Mode
When using NAT hand-off mode, consider the following caveats:
- For VLAN hand-off mode, the Partner Gateway can listen on any IP if it is reachable to the PE router (including its interface IP). For NAT hand-off mode, the Partner Gateway will not respond if the ICMP request comes to its own interface (WAN) IP address.
- Reverse flow is not supported in the NAT hand-off mode.