Doubts on Policy Routing

Carlos Aguinaldo · ‎12-04-2014

Hi all.

I have a situation that has been keeping me up all night since yesterday and I can't get the explanation why. Here it is.

R2 --- 12.0.0.0 /24 --- R1 --- 13.0.0.0 /24 --- R3

R1 Lo0: 10.0.0.1 /24

R3 Lo0: 3.3.3.3 /24

I've disabled routing on R2 and gave it a gateway of R1's address.

R1's policy route:

route-map TEST permit 10
match ip add 1
set ip next-hop 10.0.0.1

access-l 1 permit 12.0.0.0 0.0.0.255

ip route 0.0.0.0 0.0.0.0 13.0.0.0.3

In this case, R2 not able to reach R3's loopack.

R2#ping 3.3.3.3

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
....

But when I set the next-hop of the policy route to a virtual IP in R1's loopback subnet, the pings fly.

route-map TEST permit 10

no set ip next-hop 10.0.0.1

set ip next-hop 10.0.0.10

R2#ping 3.3.3.3

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!

Why are packets routed successfully if the next hop is a virtual IP and are dropped if the next hop is the exact address of R1's loopback?

Jon Marshall · ‎12-04-2014

Carlos

I think the pings are working because R1 is simply using the IP routing table and you have a default route in the routing table pointing to R3.

In effect 10.0.0.10 is an invalid next hop and so PBR does not happen ie. it just falls back to the routing table.

Jon

Carlos Aguinaldo · ‎12-04-2014

Hey Jon.

Thanks for responding. Here are some debugs from a ping in both scenarios.

Next hop of 10.0.0.10:

*Mar 1 00:27:50.595: IP: s=12.0.0.2 (FastEthernet0/0), d=3.3.3.3, len 100, FIB policy match
*Mar 1 00:27:50.595: IP: tableid=0, s=12.0.0.2 (FastEthernet0/0), d=3.3.3.3 (FastEthernet0/1), routed via FIB
*Mar 1 00:27:50.599: IP: s=12.0.0.2 (FastEthernet0/0), d=3.3.3.3, len 100, policy match
*Mar 1 00:27:50.599:     ICMP type=8, code=0
*Mar 1 00:27:50.599: IP: route map TEST, item 10, permit
*Mar 1 00:27:50.599: IP: s=12.0.0.2 (FastEthernet0/0), d=3.3.3.3 (Loopback0), len 100, policy routed
*Mar 1 00:27:50.603:     ICMP type=8, code=0
*Mar 1 00:27:50.603: IP: FastEthernet0/0 to Loopback0 10.0.0.10
*Mar 1 00:27:50.603: IP: s=12.0.0.2 (FastEthernet0/0), d=3.3.3.3 (Loopback0), g=10.0.0.10, len 100, forward
*Mar 1 00:27:50.607:     ICMP type=8, code=0
*Mar 1 00:27:50.607: IP: tableid=0, s=12.0.0.2 (Loopback0), d=3.3.3.3 (FastEthernet0/1), routed via RIB
*Mar 1 00:27:50.611: IP: s=12.0.0.2 (Loopback0), d=3.3.3.3 (FastEthernet0/1), g=13.0.0.3, len 100, forward
*Mar 1 00:27:50.611:     ICMP type=8, code=0

Next hop of 10.0.0.1

*Mar 1 00:28:25.187: IP: s=12.0.0.2 (FastEthernet0/0), d=3.3.3.3, len 100, FIB policy match
*Mar 1 00:28:25.187: CEF-IP-POLICY: fib for address 10.0.0.1 is with flag 2
*Mar 1 00:28:25.191: IP: tableid=0, s=12.0.0.2 (FastEthernet0/0), d=3.3.3.3 (FastEthernet0/1), routed via FIB
*Mar 1 00:28:25.191: IP: s=12.0.0.2 (FastEthernet0/0), d=3.3.3.3, len 100, policy match
*Mar 1 00:28:25.191:     ICMP type=8, code=0
*Mar 1 00:28:25.191: IP: route map TEST, item 10, permit
*Mar 1 00:28:25.195: IP: s=12.0.0.2 (FastEthernet0/0), d=3.3.3.3 (Loopback0), len 100, policy routed
*Mar 1 00:28:25.195:     ICMP type=8, code=0
*Mar 1 00:28:25.195: IP: FastEthernet0/0 to Loopback0 10.0.0.1
*Mar 1 00:28:25.195: IP: s=12.0.0.2 (FastEthernet0/0), d=3.3.3.3, len 100, rcvd 4
*Mar 1 00:28:25.199:     ICMP type=8, code=0

Doesn't this mean that both are being policy routed? And, if 10.0.0.1 is a valid next hop, why are the packets dropped and not routed accordingly?

Thanks for taking the time to read this.

Jon Marshall · ‎12-04-2014

Carlos

I've edited the last post because you have got me thinking as well now.

I think the first debug does indeed show it being policy routed and then because the next hop is in effect on the same router the RIB is then used to do a route lookup.

So at the moment I'm not sure what exactly is happening.

Can see now why you got so confused.

Jon

Carlos Aguinaldo · ‎12-05-2014

Hey there Jon. Appreciate you participating here.

It is indeed getting me puzzled. As you can see from one of my replies to Ekaterina, the reason I'm testing this is because of the DOC for VPN client on a stick which uses a virtual IP as the next hop and not the real loopback IP. The idea was to use policy routing and the loopback so that client traffic will get PATed.

The following thread might help. Jennifer says,

https://supportforums.cisco.com/discussion/10895221/vpn-public-internet-stick

"Yup, it's just a virtual ip in the same subnet as your loopback interface, basically to make the traffic route through the loopback interface because the interface has "ip nat inside", and then it will be routed towards the external interface that has "ip nat outside" so it can be NATed.

For NAT to happen, it needs to go through an interface with "ip nat inside" then "ip nat outside". If we don't route it through the loopback interface, theh outside interface is just "ip nat outside", so NATing for the vpn client will not work."

But still, I couldn't see the explanation why packets will get routed upon using a non-existent next hop IP. :-)

Jon Marshall · ‎12-05-2014

Hi Carlos

Have to admit this has got me confused as well.

I have never seen this configuration before and I don't understand how using an IP from the same subnet makes the router send it to the loopback interface

I don't have any kit to test with unfortunately. I'll do a bit of reading when I get the chance but I'm not convinced i'll find anything.

Sorry I couldn't be more help.

Jon

Carlos Aguinaldo · ‎12-05-2014

Hi Jon.

No worries, I understand.

Thanks again.

Ekaterina Romanova · ‎12-04-2014

Hi Carlos

how is routing configured on R3 ? Do it has route to 10.0.0.1?? You know for successful ping both side should be reachable, because R3 should to reply to icmp packets.

In case 10.0.0.10 - route map is not working, and packets go based routing table, as Jon wrote before. We see it on debug output

*Mar 1 00:27:50.611: IP: s=12.0.0.2 (Loopback0), d=3.3.3.3 (FastEthernet0/1), g=13.0.0.3, len 100, forward

Jon Marshall · ‎12-04-2014

In case 10.0.0.10 - route map is not working, and packets go based routing table, as Jon wrote before

That's what I thought originally but if PBR wasn't applied you would expect to see a "policy rejected" line in the debug.

It looks from the debug that with 10.0.0.10 it actually is forwarded by PBR, although to where I'm not entirely sure, and then a lookup is done in the RIB which finds the default route to use.

Have to admit it is confusing because that IP doesn't exist.

I would actually have thought Carlos should be seeing the exact opposite behaviour ie. the valid loopback address works and the invalid one doesn't but that's not what the debugs show.

Jon

Ekaterina Romanova · ‎12-05-2014

Agree with you, it confused me as well.

To forward packet to IP which doesn't exist - it is magic. have not seen it before

Rajeev Sharma · ‎12-05-2014

Hey Carols,

How are you using same routers loopback0 address in the next-hop filed on the same router? It should give you an error:

#set ip next-hop 10.0.0.1
% Warning: Next hop address is our address

Regards,

RS.

Ekaterina Romanova · ‎12-05-2014

Seems like it is not real configuration.. just theoretical

set ip next-hop 10.0.0.1 is not working

As well as it s not realistic to see in debug successful packet forward to unreal 10.0.0.10 loopback 0.

May be it is not real devices, but emulators.

Carlos Aguinaldo · ‎12-05-2014

Ekaterina,

The root of all these tests is the following DOC for vpn client on a stick.

http://www.cisco.com/c/en/us/support/docs/security/vpn-client/71461-router-vpnclient-pi-stick.html

You'd see there that the next hop was set to 10.11.0.2 which is a virtual IP in the same subnet as the edge router's loopback. This is done so that packets will get "hooked" into the NAT process. If you were to use 10.11.0.1 which is the actual loopback's address, the packets will not get routed accordingly.

route-map VPN-Client permit 10
 match ip address 144
 set ip next-hop 10.11.0.2

Though I've done the tests here in my OP in GNS3, I'm 100% sure that the same results will yield in real gear for I've implemented the solution from the Cisco DOC in our organization.

Carlos Aguinaldo · ‎12-05-2014

Rajeev,

Correct. It gives that error which is why if I set the next hop to 10.0.0.1, the packets are dropped. If I set the next hop to any virtual IP in the same subnet as R1's loopback (10.0.0.2, 10.0.0.3, etc.), the packet gets routed accordingly.

Ekaterina Romanova · ‎12-05-2014

"if I set the next hop to 10.0.0.1, the packets are dropped."

Cisco IOS blocks this configurtion. You can't to set 10.0.0.1.

Which IOS version and router are you using ?