Static Route Removal Based on Path Monitoring
Table of Contents
Expand all | Collapse all
-
- Tap Interfaces
-
- Layer 2 and Layer 3 Packets over a Virtual Wire
- Port Speeds of Virtual Wire Interfaces
- LLDP over a Virtual Wire
- Aggregated Interfaces for a Virtual Wire
- Virtual Wire Support of High Availability
- Zone Protection for a Virtual Wire Interface
- VLAN-Tagged Traffic
- Virtual Wire Subinterfaces
- Configure Virtual Wires
- Configure an Aggregate Interface Group
- Configure Bonjour Reflector for Network Segmentation
- Use Interface Management Profiles to Restrict Access
-
- DNS Overview
- DNS Proxy Object
- DNS Server Profile
- Multi-Tenant DNS Deployments
- Configure a DNS Proxy Object
- Configure a DNS Server Profile
- Use Case 1: Firewall Requires DNS Resolution
- Use Case 2: ISP Tenant Uses DNS Proxy to Handle DNS Resolution for Security Policies, Reporting, and Services within its Virtual System
- Use Case 3: Firewall Acts as DNS Proxy Between Client and Server
- DNS Proxy Rule and FQDN Matching
-
- NAT Rule Capacities
- Dynamic IP and Port NAT Oversubscription
- Dataplane NAT Memory Statistics
-
- Translate Internal Client IP Addresses to Your Public IP Address (Source DIPP NAT)
- Enable Clients on the Internal Network to Access your Public Servers (Destination U-Turn NAT)
- Enable Bi-Directional Address Translation for Your Public-Facing Servers (Static Source NAT)
- Configure Destination NAT with DNS Rewrite
- Configure Destination NAT Using Dynamic IP Addresses
- Modify the Oversubscription Rate for DIPP NAT
- Reserve Dynamic IP NAT Addresses
- Disable NAT for a Specific Host or Interface
-
- Network Packet Broker Overview
- How Network Packet Broker Works
- Prepare to Deploy Network Packet Broker
- Configure Transparent Bridge Security Chains
- Configure Routed Layer 3 Security Chains
- Network Packet Broker HA Support
- User Interface Changes for Network Packet Broker
- Limitations of Network Packet Broker
- Troubleshoot Network Packet Broker
-
- Enable Advanced Routing
- Logical Router Overview
- Configure a Logical Router
- Create a Static Route
- Configure BGP on an Advanced Routing Engine
- Create BGP Routing Profiles
- Create Filters for the Advanced Routing Engine
- Configure OSPFv2 on an Advanced Routing Engine
- Create OSPF Routing Profiles
- Configure OSPFv3 on an Advanced Routing Engine
- Create OSPFv3 Routing Profiles
- Configure RIPv2 on an Advanced Routing Engine
- Create RIPv2 Routing Profiles
- Create BFD Profiles
- Configure IPv4 Multicast
- Create Multicast Routing Profiles
- Create an IPv4 MRoute
Static Route Removal Based on Path Monitoring
When you Configure
Path Monitoring for a Static Route, the firewall uses path
monitoring to detect when the path to one or more monitored destination
has gone down. The firewall can then reroute traffic using alternative
routes. The firewall uses path monitoring for static routes much
like path monitoring for HA or policy-based forwarding (PBF), as
follows:
- The firewall sends ICMP ping messages (heartbeat messages) to one or more monitored destinations that you determine are robust and reflect the availability of the static route.
- If pings to any or all of the monitored destinations fail, the firewall considers the static route down too and removes it from the Routing Information Base (RIB) and Forwarding Information Base (FIB). The RIB is the table of static routes the firewall is configured with and dynamic routes it has learned from routing protocols. The FIB is the forwarding table of routes the firewall uses for forwarding packets. The firewall selects an alternative static route to the same destination (based on the route with the lowest metric) from the RIB and places it in the FIB.
- The firewall continues to monitor the failed route. When the route comes back up, and (based on theAnyorAllfailure condition) the path monitor returns to Up state, the preemptive hold timer begins. The path monitor must remain up for the duration of the hold timer; then the firewall considers the static route stable and reinstates it into the RIB. The firewall then compares metrics of routes to the same destination to decide which route goes in the FIB.
Path monitoring is a desirable mechanism to avoid silently discarding
traffic for:
- A static or default route.
- A static or default route redistributed into a routing protocol.
- A static or default route when one peer does not support BFD. (The best practice is not to enable both BFD and path monitoring on a single interface.)
- A static or default route instead of using PBF path monitoring, which doesn’t remove a failed static route from the RIB, FIB, or redistribution policy.Path monitoring doesn’t apply to static routes configured between virtual routers.
In the following figure, the firewall is connected to two ISPs
for route redundancy to the internet. The primary default route
0.0.0.0 (metric 10) uses Next Hop 192.0.2.10; the secondary default
route 0.0.0.0 (metric 50) uses Next Hop 198.51.100.1. The customer
premises equipment (CPE) for ISP A keeps the primary physical link
active, even after internet connectivity goes down. With the link
artificially active, the firewall can’t detect that the link is
down and that it should replace the failed route with the secondary
route in its RIB.
To avoid silently discarding traffic to a failed link, configure
path monitoring of 192.0.2.20, 192.0.2.30, and 192.0.2.40 and if
all (or any) of the paths to these destinations fail, the firewall
presumes the path to Next Hop 192.0.2.10 is also down, removes the
static route 0.0.0.0 (that uses Next Hop 192.0.2.10) from its RIB,
and replaces it with the secondary route to the same destination
0.0.0.0 (that uses Next Hop 198.51.100.1), which also accesses the
internet.

When you Configure
a Static Route, one of the required fields is the Next Hop
toward that destination. The type of next hop you configure determines the
action the firewall takes during path monitoring, as follows:
If Next Hop Type
in Static Route is: | Firewall Action for
ICMP Ping |
---|---|
IP Address | The firewall uses the source IP address
and egress interface of the static route as the source address and
egress interface in the ICMP ping. It uses the configured Destination
IP address of the monitored destination as the ping’s destination
address. It uses the static route’s next hop address as the ping’s
next hop address. |
Next VR | The firewall uses the source IP address
of the static route as the source address in the ICMP ping. The
egress interface is based on the lookup result from the next hop’s
virtual router. The configured Destination IP address of the monitored
destination is the ping’s destination address. |
None | The firewall uses the destination IP address
of the path monitor as the next hop and sends the ICMP ping to the
interface specified in the static route. |
When path monitoring for a static or default route fails, the
firewall logs a critical event (path-monitor-failure). When the
static or default route recovers, the firewall logs another critical
event (path-monitor-recovery).
Firewalls synchronize path monitoring configurations for an active/passive
HA deployment, but the firewall blocks egress ICMP ping packets
on a passive HA peer because it is not actively processing traffic.
The firewall doesn’t synchronize path monitoring configurations
for active/active HA deployments.