TSHOOT – Route-Maps, Policy Based Routing (PBR), and Local Policy Routing review and troubleshooting!


Route-Maps are used for multiple different purposes as shown in the example above, this specific Route-Map itself would never exist in a real world scenario, because the sequences demonstrate several different use cases for Route-Maps in the sequences.

Review of sequences from the Route-Map posted above

A few concepts of Route-Maps is that the “permit” and “deny” in sequences to not inherently behave the same way, as for Route Redistribution “permit” means the route(s) will be Redistributed and “deny” would mean they will not be.

With a Route-Map used for Policy Based Routing (PBR), “permit” means traffic will use the Route-Maps set (action), whereas a “deny” sequence matched on would mean that the traffic should not be routed via the PBR Policy.

All Route-Maps have an implicit “deny all” at the end, which will not necessarily drop traffic like ACL, but rather treat it as though it matched a “deny” sequence, so for example anything on a Redistribution Route-Map “deny all” would not be Redistributed and a PBR “deny all” would route that traffic normally.

Details about Route-Map “match” statements and “set” statements in sequences

ACL’s, Prefix-Lists, and Interfaces are used to “Match” on when the router is searching through sequences. With PBR a “Next-Hop” action can be set with an IP Address, but “match” statements will always use ACL’s / Prefix-Lists / Interfaces and will stop once it finds a match, even when multiple ACL’s are defined it only has to match one of them.

Any parameters for “Set” can make a Route-Map’s purpose clear pretty quickly, as any sort of “permit” or “deny” clauses for “set tags” tells me that the Route-Map is setting tags on 2 or 3 way Route Redistribution, and the “deny” sequences for certain tags are set to control routes not be shared back into the routing process they came from!

Other uses for Redistribution is for changing Metric Types and Metric #’s, and in the case of BGP it is heavily utilized for BGP Path Selection / Manipulation, and is actually the foundation of BGP MED (if you are familiar).

“sh route” will display all route maps / sequences / match and set clauses, use “sh ip access-list” or “sh prefix-list” to check the ACL’s or Prefix-Lists defined to match on, and to verify what it is being used for the running config sections like “sh run | begin router” would be a good start as it will start at the first “router (something) #” in the running config OR you can go straight to the statements with “sh run | include redistribute” and it will show each “redistribute …” line in the running config that will contain the Route-Maps however you will not have the full routing configuration to understand why the map is in use.

Policy Based Routing (PBR) review and troubleshooting

The steps to configure PBR goes as follows:

  1. “route-map EXAMPLE (permit/deny) #” to create sequence by sequence to create the Route-Map to be used for Policy Based Routing
  2. “ip policy route-map EXAMPLE” configured on the interface to be Policy Routed on all inbound traffic
  3. “sh ip policy” to view all currently configured PBR Configuration
  4. “sh route EXAMPLE” to view the Route-Map associated with the PBR configuration

One easy to overlook but critical part of PBR working is it must be applied to the Ingress interface, NOT the Egress interface, so if a PBR is applied to a WAN interface it will do no sort of Policy Based Routing.

One thing to also keep in mind is that traffic will route normally if it hits a “deny” or hits the implicit “deny all” if no match is found, so applying it to the wrong interface will NOT make traffic start routing incorrectly (it will just simply not work at all).

PBR can be verified with either a “tracert” on a PC or a “traceroute” on an IOS device, so like as it is behind the interface (so its traffic is inbound to the interface), and its source information matches a “permit” sequence in the PBR Route-Map.

Only “Local Policy Routing” can be tested from the local router via “traceroute” because the traffic for PBR must hit the assigned interface as ingress traffic.

Local Policy Routing review and troubleshooting

To configure it is about the same as PBR minus tying to an interface:

  1. “route-map EXAMPLE (permit/deny) #” to create sequence by sequence to create the Route-Map to be used for Policy Based Routing
  2. “ip local policy route-map EXAMPLE” configured in Global Configuration
  3. “sh ip local policy” to view currently configured Local Policy Routing info
  4. “sh route EXAMPLE” to view the Route-Map associated with Local Policy Routing

This works the same as PBR, however it pertains to any traffic generated by the device, think of any type of MGMT traffic that originates from the Router such as Telnet / SSH / SNMP / Etc.

Perhaps you want to make sure that the local router only uses SSH to avoid using a non-secure line protocol to connect to other devices:

Step 1 – Create ACL:

ip access-list extended 100
 permit 10 tcp eq 23 <– Permit? Whaaaat?

Step 2 – Create Route-Map to enforce the ACL:

route-map SSHonly permit 10
 match ip add 100
 set interface null0   <— Ahhhhhh!

Step 3 – Tie Route-Map to Local Policy:

ip local policy route-map SSHonly

As can be seen here that the same theory applies to VACL’s and Route-Map’s that the ACL is ONLY to match traffic, NOT to perform any action, that is what the “set” action is for!

As seen here, if we want to drop traffic, we will set the interface to route Port 23 (Telnet) traffic from ANY source to Null0 (the garbage can).

So ACL’s and Prefix-Lists will be all “Permit” to allow the traffic to be processed by the Route-Map, and we stomp it out of existence in set action line 🙂

A couple of pit falls to watch out for on Exam Day

There is a clause for “set” action that is “ip default next-hop x.x.x.x” which will use this clause only if there is not a more specific route in the route table, which means if there a longer prefix match in the IP Route table to PBR will be ignored.

I would definitely expect something tricky like this on exam day!

To resolve the “ip default next-hop …” issue simple negate it in the sequence with “no ip default next-hop” and configure that correct command “ip next-hop x.x.x.x” meaning it takes that next-hop route no matter what.

Some other kind of obvious things that just wanted to touch on:

  • Confirm the next-hop IP is correct
  • Confirm the correct ingress interface is being used for PBR
  • Confirm the correct ACL is being referenced, and that the target traffic is being defined with a ‘permit’ in the ACL referenced
  • Don’t be afraid to make changes / remove incorrect configs / add correct configs to get things working!

And that is the magic of Route-Maps and Policy Routing!

Nice to have a breather from ROUTE topics, as I really need to review those in depth for myself for TSHOOT exam day, this topic was a much needed breather 🙂

Hope that was informative and gives a clear understanding of how Route-Maps and PBR works when properly configured, and how to fix issues!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s