Use code with caution.
Route monitoring in Palo Alto Networks firewalls is a crucial feature for ensuring network reliability and high availability. It primarily involves two main areas: path monitoring for static routes and the monitoring of dynamic routing protocol states. Effective monitoring allows the firewall to detect reachability issues or protocol failures and take corrective actions, such as removing an invalid route or failing over to a redundant path. This ensures traffic continues to flow and minimizes network downtime. Understanding these mechanisms is vital for the PCNSE exam.
Path monitoring is specifically used for static routes to verify the reachability of a next-hop or a specific destination IP address. If the monitored destination becomes unreachable, the firewall can automatically remove the associated static route from the routing table, allowing an alternative route (perhaps another static route with a higher metric or a dynamically learned route) to take over.
The firewall sends ICMP (ping) echo requests to the specified monitored IP address at configurable intervals. If responses are not received within a certain threshold (defined by ping interval and count), the path is considered down. It's important that the monitored IP is a reliable indicator of the path's health. A single ping packet failure does not necessarily mean the path is down; it's typically based on a series of failed pings.
When path monitoring determines that the monitored destination is unreachable, the static route is flagged as invalid and removed from the firewall's Routing Information Base (RIB). This triggers the routing engine to find an alternative path. If no other specific route exists, traffic destined for that network might use a default route or be dropped if no route is available.
You can configure whether "any" monitored IP or "all" monitored IPs in a group must fail for the route to be removed.
Once a monitored path goes down, the firewall continues to send pings to check for recovery. The
The term "Wait Recover" is conceptually linked to this preemptive behavior. The firewall "waits" to "recover" the route by using the preemptive hold timer to ensure stability before making the route active again.
Path monitoring events are logged in the
Path monitoring failed
or
ROUTING_PATHTEST_FAIL
might be logged, indicating the route was removed.
Path monitoring recovered
or
ROUTING_PATHTEST_RECOVER
might be logged, indicating the route was restored after the preemptive hold time.
To find these logs:
less mp-log routed.log
to view the routing daemon log for more detailed troubleshooting.
( subtype eq 'routing' ) and ( description contains 'Path monitoring' )
or specific event IDs like
( eventid eq 'routed-path-mon-down' )
or
( eventid eq 'routed-path-mon-up' )
(Note: exact event IDs can vary slightly by PAN-OS version, always verify with current documentation or by observing logs). The messages "Path monitoring failed for static route destination
You can also use the CLI command
show routing path-monitor
to check the current status of monitored paths.
Detailed Path Monitoring Lifecycle
Palo Alto Networks firewalls support dynamic routing protocols such as OSPF and BGP. Monitoring their state, especially neighborship or peerings, is critical for network stability.
Dynamic routing protocols rely on forming neighborships (OSPF) or peerings (BGP) with adjacent routers to exchange routing information. If a neighborship fails, routes learned through that neighbor are withdrawn, potentially leading to routing black holes or suboptimal routing until convergence occurs via an alternate path.
Failures in dynamic routing protocols can be detected through several methods:
show routing protocol ospf neighbor
(to check neighbor states). Other useful OSPF commands include
show routing protocol ospf interface
and
show routing protocol ospf lsdb
.
show routing protocol bgp peer
(to check peer states and received prefixes).
routed-OSPF-neighbor-down
or messages like "OSPF adjacency with neighbor has gone down".
Search in System Logs:
( subtype eq 'routing' ) and ( description contains 'OSPF' )
or
( eventid eq 'routed-OSPF-neighbor-down' )
.
BGP_PEER_CONN_LOST
or messages like "BGP peer session left established state".
Search in System Logs:
( subtype eq 'routing' ) and ( description contains 'BGP' )
or
( eventid eq 'routed-bgp-peer-down' )
(Note: actual event IDs can vary). BGP log messages might indicate if a peer closed the session.
routed.log
on the management plane. This can be viewed via CLI:
less mp-log routed.log
or for real-time viewing:
tail follow yes mp-log routed.log
. This log provides detailed reasons for adjacency failures, such as mismatched MTU, timers, or authentication issues.
For OSPF, common reasons for adjacency issues include mismatched Area IDs, Hello/Dead timers, authentication, MTU sizes, or network type. For BGP, common issues include incorrect AS numbers, IP addresses, TCP port 179 being blocked, or authentication.
Dynamic Routing Adjacency/Peering Process
Beyond specific path monitoring or protocol neighborships, general route additions, deletions, or modifications in the routing table are also logged.
Search in System Logs:
( subtype eq 'routing' ) and ( eventid contains 'ROUTING_RT_' )
or filtering for descriptions containing "route added" or "route removed". The configuration log also tracks changes made to the firewall's configuration, which includes static route definitions.
show routing route
: Displays the entire RIB (Routing Information Base), showing all routes known to the firewall, their administrative distances, and metrics.
show routing fib
: Displays the FIB (Forwarding Information Base), which contains the actual routes installed and used for forwarding traffic.
test routing fib-lookup virtual-router [vr_name] ip [destination_ip]
: Simulates a route lookup for a specific destination.
Understanding Administrative Distance (AD) is crucial. If multiple protocols provide a route to the same destination, the route with the lowest AD is preferred. If ADs are equal, the protocol-specific metric is used.
WebUI: Monitor > Packet Capture
CLI:
debug routing pcap
Effective troubleshooting involves a systematic approach:
show interface
.
show routing route
and
show routing fib
to understand what routes are present and active.
show routing path-monitor
.
show routing protocol ospf neighbor
,
show routing protocol ospf interface
.
show routing protocol bgp peer
.
routed.log
(CLI:
less mp-log routed.log
or
tail follow yes mp-log routed.log
):
For detailed daemon-level messages.
ping
and
traceroute
from the firewall CLI (specifying source interface/IP if necessary) and from affected hosts.
routed.log
) or how to filter them effectively.