Policy Routing failure (order of operation?)

[Jay47110]

 

Hi,

This question is relating the order of operation in Cisco IOS-XE for an ingress packet.

I am currently troubleshooting an issue where a Host1 with IP 192.168.1.1 is trying to ping a remote Host2 192.168.2.2 and the router in question R1 is the transit router.

The traffic is PBR'd on R1 on the ingress interface based on source IP 192.168.1.1 and destination IP 192.168.2.2 and an IP next-hop is set.

Here is the trouble, 192.168.2.2 also happens to be a directly connected interface IP address on R1 which is completely separate and has nothing to do with Host2's 192.168.2.2 that host1 is trying to ping. And Although the traffic is PBR'd on the ingress interface, it never gets Policy based routed to the correct IP next-hop specified in the PBR. Here is the "debug ip packet detail" output of the failed routing:

*Dec 15 19:22:22.190: IP: s=192.168.1.1 (GigabitEthernet0/1), d=192.168.2.2, len 100, input feature
*Dec 15 19:22:22.191: ICMP type=0, code=0, Policy Routing(103), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 15 19:22:22.191: IP: s=192.168.1.1 (GigabitEthernet0/1), d=192.168.2.2, len 100, input feature
*Dec 15 19:22:22.192: ICMP type=0, code=0, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 15 19:22:22.192: FIBipv4-packet-proc: route packet from GigabitEthernet0/1 src 192.168.1.1 dst 192.168.2.2
*Dec 15 19:22:22.193: FIBfwd-proc: Default:192.168.2.2/32 receive entry
*Dec 15 19:22:22.193: FIBipv4-packet-proc: packet routing failed
*Dec 15 19:22:22.193: IP: tableid=0, s=192.168.1.1 (GigabitEthernet0/1), d=192.168.2.2 (GigabitEthernet0/2), routed via RIB
*Dec 15 19:22:22.194: IP: s=192.168.1.1 (GigabitEthernet0/1), d=192.168.2.2, len 100, rcvd 4
*Dec 15 19:22:22.194: ICMP type=0, code=0
*Dec 15 19:22:22.195: IP: s=192.168.1.1 (GigabitEthernet0/1), d=192.168.2.2, len 100, stop process pak for forus packet
*Dec 15 19:22:22.195: ICMP type=0, code=0

However, once the directly connected interface with IP 192.168.2.2 is shutdown, PBR kicks in fine and routes traffic to the correct next-hop interface. Here is the "debug ip packet detail" output for successful routing:

*Dec 15 19:21:25.785: IP: s=192.168.1.1 (GigabitEthernet0/1), d=192.168.2.2, len 100, FIB policy match
*Dec 15 19:21:25.785: IP: s=192.168.1.1 (GigabitEthernet0/1), d=192.168.2.2, len 100, PBR Counted
*Dec 15 19:21:25.785: IP: s=192.168.1.1 (GigabitEthernet0/1), d=192.168.2.2, g=192.168.12.2, len 100, FIB policy routed

What am I missing here, isn't Policy based routing triggered before RIB or CEF in the ingress order of operations? Or is the fact that the destination is also a directly connected prefix takes precedence over the PBR?

Kind regards

 

[paul driver]

Hello @Georg Pauwen 

I wouldn’t suggest to have two directly connected rtrs  point default routes towards each other- your asking for trouble- it will cause whole lot of heartache - routing loop galore!

[paul driver]

Hello

@Georg Pauwen how would host 192.168.1.1 reach the same host on the same rtr if it needed to?

Nat would be preferable in this case not PBR

[paul driver]

Hello
FYI - Cef isn’t used in some PBR statments as such packets PBR are process switched which means every packet needs to be punted to the cpu for a forwarding decision.
Regards your PBR the set-interface and ip next- hop are roughly the same-

ip next- hop x.x.x. requires the ip to be part of a directly connected interface on the rtr
set interface x/x - requires the destination address of the packet needs be on the same segment of the interface specified or that some proxy arp is being used to forward the packet

Can you confirm what you are trying to accomplish here - Are you trying to ping a connect interface of the rtr that’s has PBR enabled?
Also have you have specified the PBR ip next hop address to point to a connected interface ip on the same rtr- If so this isnt correct.

[Jay47110]

Hi Paul,

For ease of understanding I've attached a topology diagram in the original post.

I am using ip next-hop (address) in the route-map.

Kind regards

[paul driver]

Hello

thanks for sharing - i think i see now what your trying to achieve- please correct me if i am wrong

you want policy based route towards a host in another router that has the same ip address as a host on connected interface on rtr 1 - however PBR isn’t what you need it’s NAT - Network Address Translation applied on either rtr so to enable you to reach both hosts of 192.168.2.2 successfully.

[Jay47110]

Hi Paul,

Yes, spot on that's exactly what the scenario is based upon. I agree, NAT would be the preferred choice here, but I just wanted to find out about the order of operation when the packet arrived from host1 on R1. Is the router's directly connected interface taking precedence over policy based routing?

Kind regards

[paul driver]

Hello

Then the order of preference which i have already stated when using ip next-hop would be to for the rtr to bypass the route table lookup and policy route directly to the related interface of the specified next-hop ip in the pbr

Your scenario here without using nat wouldn’t be valid in a real network as you would have a discontiguous overlapping network so PBR isnt the correct feature choice in this instance 

[Georg Pauwen]

Hello,

I am starting to think maybe this is a flaw in the simulation software you are using. I used GNS3, and as documented, your PBR configuration works flawlessly. What are you using (VIRL) ?

[MHM Cisco World]

ip route-cache policy 

try fast switch PBR enable than use CEF-PBR