Router Ping vs VLAN Host: Which PBR Policy Applies?

VLAN 10 should use the VPN and VLAN 20 should use the WAN, so the first test is a ping from the router with VLAN 10's interface address as its source. It succeeds, the route-map counters increment, and everyone concludes the design works. It does not. That ping was generated locally, and locally generated traffic reaches a different policy attachment point than a packet arriving on the VLAN interface.

Three conditions decide which policy you are really testing: where the packet is created, where it enters, and what it matches.

Where the packet enters decides which policy runs

An interface route-map attached with ip policy route-map applies to packets arriving on that interface, as the IOS XE PBR guide describes. A host in VLAN 10 sends its request, the frame arrives on the VLAN subinterface, and the router evaluates the policy there. The router's own packet never arrives on that interface, because it was born in the router.

Choosing the VLAN address as the source changes the header. It does not change the origin.

Why the sourced ping is still not the host

The source address matters to an ACL match, and that is exactly what makes the test so convincing. The packet matches a source clause, the counters increment, and the output looks correct. What the test cannot show is the ingress interface, the arrival context, or whether a host packet would take the same branch.

A test that reproduces the match but not the context proves half of the design, and half a proof is how designs ship with the wrong policy attached.

When a local policy is the right answer

Cisco documents ip local policy route-map for traffic the router generates itself. That is a separate scope, and it is the correct tool when the requirement genuinely concerns the router's own traffic. It is not a missing step that every VLAN-steering design needs. Broad matching there can also affect management and supporting connections, which is a much bigger change than it looks.

Locally generated TCP has an extra prerequisite: it needs an applicable destination entry in the routing table even when the policy selects another path. An ICMP result does not prove the same behaviour for TCP.

What to test on the host instead

Run the test from an authorised host in VLAN 10, with its real source address, destination, protocol and port. Record the ingress interface and the route-map match alongside the result, so the evidence names the policy that ran. Then repeat for a VLAN 20 host and confirm it takes the other path.

Both paths need working next hops, return reachability and, where applicable, VPN coverage. PBR chooses a forwarding decision; it does not create the remote service or grant the application permission.

What the result can and cannot prove

A successful host flow proves the policy matched and the chosen path worked at that moment. It does not prove that the router's own traffic is steered, and it does not prove the application was authorised, because those are different questions with different evidence.

Keep the ping in the record as evidence about a local packet. Then go and get the host-flow evidence, rather than widening the policy scope until the two tests happen to look alike.