Troubleshoot PBR

This task helps you debug PBR configuration when packets get dropped by verifying routes, monitoring metrics, and validating interface selection.

When PBR is not working as intended, you need to systematically verify the configuration components including route maps, path monitoring, and interface selection to identify the root cause of packet drops.

Before you begin

Follow these steps to troubleshoot PBR configuration when packets get dropped:

Procedure

Step 1

Check that all essential routes for recursive resolution are present by using the show route or show ipv6 route commands in the appropriate tables.

Unless the route map for the interfaces participating in PBR is updated with correct routes, PBR will not work as intended.

Step 2

Display the remote address that path-monitoring uses to monitor metrics by using the show running-config interface command.

Example:

interface GigabitEthernet0/0
nameif outside_0
security-level 0
zone-member ecmp-zone
ip address 20.0.0.3 255.255.255.0 -> This is egress interface "show running-config" output, the monitored address and cost metric value is determined in this output. 
policy-route cost 1
policy-route path-monitoring
20.0.0.4
!
int GigabitEthernet 0/3
!
interface GigabitEthernet0/3
nameif outside_3
security-level 0
ip address 11.1.1.2 255.255.255.0 -> This is ingress interface "show running-config" output, the specific route-map will be used by PBR to determine the next route.
policy-route route-map rtt-tes

This command shows the monitored address and cost metric values for path monitoring by sending ICMP packets or HTTP pings.

Step 3

Examine the show path-monitoring and show run route-map outputs for packet loss.

Example:

ciscoasa(config)# show path-monitoring
Interface: outside_0  -> The remote address used for ICMP monitoring
Remote peer: 20.0.0.4
Version: 6223
Remote peer reachable: Yes -> If this value turns "No", then the ICMPv4/v6 packet is not reaching the required remote address.
RTT average: 1920 microsecond(s)
Jitter: 394 microsecond(s)
Packet loss: 0%
MOS: 4.40
Last updated: 17 second(s) ago -> The data should be updated by path monitoring after every 30 seconds. The 'show route-map' would show the
updated metric values. 
Interface: outside_2
Remote peer: 40.0.0.4
Version: 6223
Remote peer reachable: Yes
RTT average: 1935 microsecond(s)
Jitter: 433 microsecond(s)
Packet loss: 0%
MOS: 4.40
Last updated: 17 second(s) ago

Example:

ciscoasa(config)# show route-map
route-map rtt-test, permit, sequence 10
Match clauses:
Set clauses:
adaptive-interface rtt outside_0 (1920) outside_2 (1935) outside_1 (1971) -> Displays the metric type (rtt) that is used by the policy route to select the adequate interface to send the packet. The interface list where cost of each interface is given. As the metric type is "rtt" and considering the minimum rtt value, the "outside_0" interface route will be selected by PBR. 
route-map mos-test, permit, sequence 10
Match clauses:
Set clauses:
adaptive-interface mos outside_0 (378) outside_1 (390) outside_2 (440) - > As the metric type is "mos", considering the maximum value of mos, the "outside_2" interface will be selected by PBR.

The metric types (lost, rtt, jitter, cost) should select the interface with the minimum metric value for routing.

The metric type "mos" should select the interface with the maximum metric value for routing.

Step 4

Use packet-tracer command to validate the interface selection based on the metric type defined in the PBR.

Example:

packet-tracer input <interface> icmp <src ip address> 8 0 <dst ip
address> detailed
Phase: 3
Type: PBR-LOOKUP
Subtype: policy-route
Result: ALLOW
Elapsed time: 60656 ns
Config:
route-map rtt-test permit 10
match ip address allow_101_1_1_2
set adaptive-interface rtt outside_0 outside_2
Additional Information:
Matched route-map rtt-test, sequence 10, permit
Found next-hop 40.0.0.4 using egress ifc outside_2 -> PBR selects the adequate interface from adaptiveinterface list given in "rtt-test" route-map.

Step 5

Use the packet-tracer command similar to the debug policy-route command.

When PBR successfully selects the route, the packet tracer output looks like this:

pbr: policy based route lookup called for 101.1.1.1/0 to 101.1.1.2/0 proto 1 sub_proto 8 received on
interface outside_3, NSGs, nsg_id=none
pbr: First matching rule from ACL(-1)
pbr: route map rtt-test, sequence 10, permit; proceed with policy routing
pbr: policy based routing applied; egress_ifc = outside_2 : next_hop = 20.0.0.4

When PBR is not able to find the adequate route, it falls back to normal route lookup, and the packet tracer output looks like this:

pbr: policy based route lookup called for 100.1.1.1/0 to 100.1.1.2/0 proto 1 sub_proto 8
received on interface outside_3, NSGs, nsg_id=none
pbr: First matching rule from ACL(-1)
pbr: route map mos-test, sequence 10, permit; proceed with policy routing
pbr: no route to 100.1.1.2 on adaptive-interface outside_2
pbr: no route to 100.1.1.2 on adaptive-interface outside_1
pbr: no route to 100.1.1.2 on adaptive-interface outside_0
pbr: policy based routing could not be applied; proceeding with normal route lookup

When a monitored remote address goes down, and path monitoring marks Remote peer reachable as No for that address, the PBR displays the a log that excludes the interface from adaptive-interface list.

pbr: policy based route lookup called for 100.1.1.1/0 to 101.1.1.2/0 proto 1 sub_proto 8 received on
interface outside_3, NSGs, nsg_id=none
pbr: First matching rule from ACL(-1)
pbr: route map rtt-test, sequence 10, permit; proceed with policy routing
pbr: Path Monitoring Ifc Down : adaptive-interface outside_1 Excluded from PBR routing
pbr: policy based routing applied; egress_ifc = outside_2 : next_hop = 40.0.0.4

Note	The interface becomes eligible for adaptive PBR routing when the interface is reported as reachable in the path monitoring module.