I didn't have the correct answer for that at the time, so I looked it up, whipped up a lab and here we are :)
SPOILER ALERT: debug ip policy FTW!!!!
My co-worker was correct to assume, there is nothing in the routing table to tell you there is a policy based route installed or that packets are being forwarded in contrary to the routing table. Checking the routing table alone is not enough to determine the flow of packets. You must also check the ingress interface for policies.
To build Policy Based Routing (PBR) you need 3 basic ingredients:
- access-list (standard or extended)
- route-map
- reachable next-hop
In the graphic above we are sourcing our traffic from the Loopback0 interface: 1.1.1.1 on R1 (on the right). In the middle is our PBR router. Using the default route traffic will traverse the PBR router using the next-hop of 10.10.10.6. We want to use Policy Based Routing to route traffic sourced from: 1.1.1.1 to the next-hop 20.20.20.6.
PBR: (configuration)
route-map PBR permit 10
match ip address 1
set ip next-hop 20.20.20.6
interface FastEthernet0/0
ip policy route-map PBR
IOS: (verification)
To see if PBR is turned on or is in-use:
show ip interface fa0/0 | i Policy
show ip policy
show cef interface fa0/0
show cef interface fa0/0 | i Policy|polic
To verify the configuration elements of PBR:
show access-list PBR
NOTE: Hit counts are good indicators your policy is getting hit.
To verify the traffic is hitting the Policy as it ingresses and interface:
NOTE: Using the "debug" command on a policy which see's alot of traffic can blow up your console. Best practice to use ACL's to filter the "debug" output to a particular host or hosts.
No comments:
Post a Comment