Skip to content
Log in Sign up My account

3.2.d Policy-Based Routing

Blueprint 3.2.d: Describe policy-based routing

  • What PBR is and why you would use it instead of destination-based routing
  • How a PBR route-map is built: match clauses, set clauses, permit and deny
  • Where it is applied (ingress interface, local policy) and what happens to traffic that does not match
  • set ip next-hop vs set ip default next-hop, and next-hop failure behaviour
  • How to verify that packets are policy routed

The verb is describe, so the exam tests understanding rather than a full configuration from memory. In practice that means reading a route-map and an interface configuration in an exhibit and predicting what happens to a given packet. You also need to know where PBR applies and where it does not. ENARSI 1.6 configures and troubleshoots it.

Why PBR exists

Normal IP routing looks at one field: the destination address. Every packet to 192.0.2.0/24 takes the same path, whoever sent it and whatever it carries. Policy-based routing lets a router choose the next hop using other fields, decided by an administrator's policy.

Typical uses:

Use Example
Source-based routing Guest VLAN to a cheap broadband link, corporate users to the MPLS or primary link
Application steering Bulk backup traffic (matched by port in an ACL) to a secondary path, interactive traffic on the primary
Cost or contract control Send one department's traffic through a firewall or proxy that the routing table would bypass
Packet size match length to send large packets one way and small packets another

PBR is static policy. It does not measure the path it sends traffic to unless you add object tracking. In modern WANs, Catalyst SD-WAN application-aware routing does the same job dynamically, using live loss, latency and jitter. PBR is still the tool on a standalone router.

graph LR
  G["Guest LAN<br/>10.3.1.0/24"] --> R1["R1<br/>Gi0/1 ip policy route-map PBR-GUEST"]
  C["Corporate LANs<br/>10.3.0.0/24 and others"] --> R1
  R1 -->|"guest: set ip next-hop 203.0.113.6"| B["Broadband link"]
  R1 -->|"everything else: routing table"| P["Primary link, BGP default"]

How PBR is built

PBR uses a route-map applied to an interface. Each route-map sequence has match clauses and set clauses.

ip access-list extended GUEST-SRC
 permit ip 10.3.1.0 0.0.0.255 any
!
route-map PBR-GUEST permit 10
 match ip address GUEST-SRC
 set ip next-hop 203.0.113.6
!
interface GigabitEthernet0/1
 description From R2, inside
 ip policy route-map PBR-GUEST

Processing rules

  1. The route-map is checked against every packet that arrives on the interface, sequence by sequence, lowest number first.
  2. If a packet matches a permit sequence, the set clauses are applied, so the packet is policy routed.
  3. If a packet matches a deny sequence, it is not dropped. It is routed normally using the routing table.
  4. If a packet matches no sequence, the implicit deny at the end applies, which again means normal routing, not a drop.
  5. A sequence with several match clauses of different types needs all of them to match (logical AND). Several values in one match clause (for example two ACL names) are a logical OR.
  6. A permit sequence with no match clause matches every packet.
graph TB
  P["Packet arrives on Gi0/1"] --> M{"Matches a<br/>route-map sequence?"}
  M -->|"permit sequence"| S{"set ip next-hop<br/>reachable and up?"}
  M -->|"deny sequence or<br/>no match at all"| RT["Normal routing<br/>table lookup"]
  S -->|"yes"| PR["Forward to<br/>PBR next hop"]
  S -->|"no"| RT

Exam trap

In PBR, "deny" and "no match" both mean route normally. They never drop the packet. This is the opposite of what a route-map does in redistribution or BGP filtering, where deny means the route is not passed. The exam swaps the two contexts to catch you. If you need to drop traffic, use an ACL, or a PBR set interface Null0.

Match clauses

Clause Matches
match ip address <acl> Standard or extended ACL: source, destination, protocol, ports. The ACL's permit means "this packet matches the sequence"; the ACL deny means "it does not". The ACL does not filter traffic here
match ip address prefix-list <name> Destination prefix only
match length <min> <max> Packet length in bytes

Set clauses and their order

Clause Behaviour
set ip next-hop <ip> Send to this next hop before the routing table is consulted. If the next hop is not up and adjacent, fall back to normal routing
set interface <if> Send out this interface. Only sensible on point-to-point links; on Ethernet the router still needs an ARP entry for the destination
set ip default next-hop <ip> Use this next hop only if the routing table has no explicit route for the destination. A default route does not count as an explicit route
set default interface <if> As above, with an interface
set ip next-hop verify-availability <ip> <seq> track <obj> Use the next hop only while the tracked object is up
set ip next-hop recursive <ip> The next hop does not need to be directly connected; it is resolved through the routing table

If more than one is configured in a sequence, IOS evaluates them in the order set ip next-hop, set interface, set ip default next-hop, set default interface.

graph LR
  subgraph NH ["set ip next-hop"]
    A1["Packet matches"] --> A2["Use PBR next hop first"]
    A2 --> A3["Routing table only if<br/>next hop is down"]
  end
  subgraph DNH ["set ip default next-hop"]
    B1["Packet matches"] --> B2["Routing table first"]
    B2 --> B3["PBR next hop only if no<br/>explicit route exists"]
  end

Exam trap

set ip default next-hop looks like a stronger version of set ip next-hop, but it is the weaker one. If R1 has a specific route to the destination, the packet follows the routing table and the "default" next hop is ignored. Expect an exhibit where the engineer used default next-hop, a specific route exists, and traffic does not go where the policy intended.

Where PBR applies

  • Inbound only. ip policy route-map acts on packets arriving on the interface. There is no outbound PBR. Apply it to the interface facing the traffic source, not the one facing the destination.
  • Transit traffic only, by default. Packets the router generates itself (pings, routing protocol packets, management traffic) are not policy routed by an interface policy. Use ip local policy route-map <name> in global configuration for those.
  • IPv6 works the same way with ipv6 policy route-map on the interface and match ipv6 address <acl>, set ipv6 next-hop.
  • PBR is switched in CEF on IOS XE, and in hardware on Catalyst switches with the right SDM template, so it does not imply process switching on modern platforms.

Exam trap

"The engineer pings from R1 and the ping does not follow the policy" is a classic. R1's own pings are locally generated, so the interface policy never sees them. Test PBR with traffic that enters the interface (for example a ping from a downstream router or host), or add ip local policy route-map.

Next-hop failure and tracking

With plain set ip next-hop, PBR checks only that the next hop is directly connected on an interface that is up. If the next hop router dies but the link stays up (a switch in between, for example), the router keeps sending matching traffic into a black hole. Object tracking fixes that.

ip sla 10
 icmp-echo 203.0.113.6 source-interface GigabitEthernet0/2
 frequency 5
ip sla schedule 10 life forever start-time now
!
track 10 ip sla 10 reachability
!
route-map PBR-GUEST permit 10
 match ip address GUEST-SRC
 set ip next-hop verify-availability 203.0.113.6 1 track 10

When track 10 goes down, the next hop is treated as unavailable and matching traffic falls back to the routing table. IP SLA and tracking are ENCOR 4.4 material; here you only need to recognise the pattern.

Verification

R1# show ip policy
Interface      Route map
Gi0/1          PBR-GUEST

R1# show route-map PBR-GUEST
route-map PBR-GUEST, permit, sequence 10
  Match clauses:
    ip address (access-lists): GUEST-SRC
  Set clauses:
    ip next-hop 203.0.113.6
  Policy routing matches: 5 packets, 570 bytes

The Policy routing matches counter is the quickest proof that traffic is hitting the policy. Exact field layout varies by release; the match and set clauses and the counter are what matter. If the counter stays at 0, check the interface (inbound on the right one?), the ACL (does it permit the real source?) and whether you are testing with router-generated traffic.

debug ip policy shows the decision per packet, with lines similar to:

IP: s=10.3.1.1 (GigabitEthernet0/1), d=192.0.2.1, len 100, FIB policy match
IP: s=10.3.1.1 (GigabitEthernet0/1), d=192.0.2.1, g=203.0.113.6, len 100, FIB policy routed

Use it only in a lab or with a tight ACL; on a busy router it is a lot of output.

Lab: steer one subnet with PBR

Topology: module lab from the eBGP baseline, plus a second link between R1 Gi0/2 (203.0.113.5/30) and ISP Gi0/1 (203.0.113.6/30), standing in for a broadband link. Do not run BGP on it. Goal: traffic from R3's Loopback1 (10.3.1.0/24, the "guest" LAN) leaves R1 on the broadband link; everything else follows the BGP default on Gi0/0.

graph LR
  R3["R3 Lo1 10.3.1.0/24 guest<br/>Lo2 10.3.2.0/24 corp"] -- "area 1" --- R2["R2"]
  R2 -- "Gi0/1 area 0" --- R1["R1<br/>Gi0/1 ip policy"]
  R1 -- "Gi0/0 203.0.113.0/30 eBGP primary" --- ISP["ISP"]
  R1 -- "Gi0/2 203.0.113.4/30 broadband" --- ISP
  1. Address the new link on R1 and ISP. On ISP, nothing else is needed: it already routes 10.0.0.0/8 back to R1 over BGP, so return traffic comes back on Gi0/0. The path is asymmetric, which is normal for PBR.
  2. Baseline: from R3, traceroute 192.0.2.1 source Loopback1. Hop 2 is R1 and hop 3 is 203.0.113.2 (primary).
  3. On R1, create the ACL and route-map from the "How PBR is built" section and apply ip policy route-map PBR-GUEST to Gi0/1, the interface facing R2.

  4. Repeat the traceroute from Loopback1. The last hop answers from 203.0.113.6, the broadband link. Repeat with source Loopback2: it still uses 203.0.113.2.

    R3# traceroute 192.0.2.1 source Loopback1 numeric
  1 10.2.3.1 2 msec 1 msec 1 msec
  2 10.1.2.1 2 msec 2 msec 2 msec
  3 203.0.113.6 3 msec *  3 msec

  5. Check show route-map PBR-GUEST on R1. The match counter has increased.

  6. From R1 itself, ping 192.0.2.1 source Loopback0. The counter does not change: the router's own traffic is not policy routed.
  7. Change the set clause to set ip default next-hop 203.0.113.6 and retrace from Loopback1. Traffic goes back to the primary, because R1 has an explicit BGP route for 192.0.2.0/24. Now retrace to an address R1 has no specific route for and note that the BGP default (0.0.0.0/0) does not count as explicit, so that traffic uses the broadband next hop.
  8. Restore set ip next-hop, add the IP SLA and tracking from the "Next-hop failure" section, then shutdown ISP Gi0/1. After the tracked object goes down, guest traffic falls back to the primary. Bring the interface back up and confirm guest traffic returns to broadband.

Quick check

A route-map used for PBR has route-map RM deny 10 matching ACL WEB, and route-map RM permit 20 with set ip next-hop 10.9.9.9 and no match clause. What happens to web traffic and to everything else entering the interface?

Web traffic matches the deny sequence, so it is routed normally by the routing table. All other traffic falls through to sequence 20, which has no match clause and therefore matches everything, so it is sent to 10.9.9.9.

PBR with set ip next-hop 203.0.113.6 is applied on the WAN-facing interface of a branch router, but traffic from the branch LAN is not affected. Why?

PBR acts on packets arriving on the interface where the policy is applied. LAN traffic enters on the LAN interface, so the policy must go there.

What is the difference between set ip next-hop and set ip default next-hop when the routing table has a specific route for the destination?

set ip next-hop overrides the routing table and uses the PBR next hop. set ip default next-hop is only used when there is no explicit route, so with a specific route present the packet follows the routing table.

References