Solution: Traffic From Specific Source Not Taking Expected Path¶

Triage¶

Review the route-map configuration:
```
show route-map POLICY-ISP-B
```
Check the match clause and set clause.
Check what ACL or prefix-list is referenced:
```
show access-lists 150
```
Verify it matches source 10.100.0.0/24.
Check route-map counters:
```
show route-map POLICY-ISP-B
```
If "matches" counter is 0, the match clause is not catching traffic.
Verify the route-map is applied to the correct interface:
```
show running-config interface GigabitEthernet0/0
```
Must see ip policy route-map POLICY-ISP-B on the LAN-facing interface where 10.100.0.0/24 traffic ingresses.

Verify the next-hop is reachable:

ping 203.0.113.1
show ip route 203.0.113.1

For Linux policy routing:

ip rule list
ip route show table 100

Root Cause¶

The route-map references ACL 150, which was supposed to match source 10.100.0.0/24. However, the ACL was configured with the wrong wildcard mask or wrong address:

access-list 150 permit ip 10.100.0.0 0.0.0.255 any     ! intended
access-list 150 permit ip 10.10.0.0 0.0.0.255 any       ! actual (typo)

Because the ACL matches 10.10.0.0/24 instead of 10.100.0.0/24, traffic from 10.100.0.0/24 never matches the route-map. When a route-map match fails, the packet falls through to normal routing table lookup, which sends it via the default route through ISP-A.

On Linux, the equivalent issue would be an ip rule with the wrong from prefix or a missing/empty custom routing table.

Fix¶

Cisco IOS:

configure terminal
no access-list 150
access-list 150 permit ip 10.100.0.0 0.0.0.255 any
end

Verify the route-map now matches:

clear route-map POLICY-ISP-B counter

Send test traffic from 10.100.0.0/24 and check:

show route-map POLICY-ISP-B

Counters should increment.

Linux:

# Fix the rule
ip rule del from 10.10.0.0/24 table 100
ip rule add from 10.100.0.0/24 table 100

# Ensure the custom table has the correct route
ip route show table 100
# Should show: default via 203.0.113.1 dev eth1

Verify with traceroute from an affected host:

traceroute -s 10.100.0.50 8.8.8.8

Rollback / Safety¶

Correcting the ACL is immediate and non-disruptive.
Keep the old ACL documented in case the typo was intentional for a different purpose.
If the route-map is shared by other match clauses, verify that changing the ACL does not affect them.
Test by tracing from the specific source subnet before and after.

Common Traps¶

ACL permit in route-map context means "match this traffic for policy routing," not "allow this traffic." A deny in the ACL means "do not apply PBR" (use normal routing), not "drop the packet."
Applying the route-map on the wrong interface or in the wrong direction -- PBR is applied inbound on the interface where the traffic enters the router.
The set next-hop being unreachable -- if the next-hop is down, the route-map match succeeds but the set action fails, and behavior varies by platform.
PBR does not affect traffic originated by the router itself (unless ip local policy route-map is configured).
Wildcard mask errors on Cisco (0.0.0.255 vs. 0.0.255.255) -- a common source of off-by-one subnet matching bugs.
On Linux, forgetting to populate the custom routing table (table 100) with the actual route -- the rule matches but there is no route to use.