Configures protection and resiliency on IPv4 and IPv6 static routes.
| default | Default route. |
| ipv4_or_ipv6_network | IPv4 or IPv6 network address. |
| gateway | Gateway IP address. |
| protection | Selects the type of protection on this route (default is none). |
| bfd | Enables BFD protection on this route. |
| ping | Enables ICMP ping protection on this route. |
| none | Disables all protection on this route (default). |
No protection is the default.
For static routes configured with protection type ping, static routes are initially down. Static routes become "up" for each configured gateway/device IP when a timely ICMP Echo Reply is received from that IP within the configured ping interval. Static routes transition from up to down when no timely reply is received for the configured number of missed intervals. Severely delayed ICMP Echo Replies are ignored if received after the configured interval time elapses, because a new ICMP Echo Request has already been sent. Static routes with ping protection need not be ECMP routes. Thus when a device is unresponsive, a different route with a higher cost or shorter prefix length can route packets elsewhere.
The protection type (BFD, ping, or none) for an existing static route can be changed dynamically without deleting the route. To change the protection type, simply re-add an existing static route with a different protection type.
The following example adds a static route for 100.0.0.0/24 with ping health check monitoring to gateway IP 1.2.3.4.
# configure iproute add 100.0.0.0/24 1.2.3.4 protection ping
ExtremeXOS initiates ping health check monitoring to the adjacent device with IP address 1.2.3.4. The route for 100.0.0.0/24 is protected, meaning if ping responses are received from 1.2.3.4 in a timely manner, the static route for 100.0.0.0/24 to 1.2.3.4 is “up” in the routing table. If no ping response is received in a timely manner, the route is down.
In an example with ECMP, assuming enable iproute sharing:
# configure iproute add 100.0.0.0/24 1.2.3.5 protection ping
If ping responses are received by both 1.2.3.4 and 1.2.3.5, IP packets destined to subnet 100.0.0.0/24 are Layer-3 load balanced by hardware between 1.2.3.4 and 1.2.3.5. If for example, no ping response is received from 1.2.3.4 in a timely manner, IP packets destined to 100.0.0.0/24 are sent only to 1.2.3.5. Later, upon receiving a ping response from 1.2.3.4, packets are load balanced again.
This command was first available in ExtremeXOS 22.1.
This command is available on all platforms with an Edge or Base license or higher as described in the ExtremeXOS 32.6.1 Feature License Requirements document.