PBR for a locally configured router IP address

[oliv Parcell]

Hello community !

I am trying to perform a very specific thing.

I would like to perform a PBR for a subnet range located remotely. However one of the IP of this subnet is configured locally on the router (interface IP @) !

I know that PBR takes precedence on a directly connected subnet, but what about if I want to perform PBR redirection for one of the IP directly configured on the router ?

If you take a look on the network diagram, I can perform PBR and reach the IP 10.10.10.2 and 10.10.10.3, but the PbR does not work for 10.10.10.1 (loal IP @).

I tried with 'set ip next-hop' and 'set interface' but no luck => The router (C881-K9 - 15.2.4M6a) handles the packet and answers anyway.

If you have any idea or suggestion feel free to answer !

Thanks in advance.

Oliv.

[Vasilii Mikhailovskii]

Hello.

To PBR locally originated (by router) traffic, you need command "ip local policy route-map ..."

See details http://www.cisco.com/c/en/us/td/docs/ios/12_2/iproute/command/reference/fiprrp_r/1rfindp1.html#wp1017871

PS: keep in mind, that local PBR doesn't work for encapsulations done on the router, i.e. you can't PBR GRE or IPSec packets, originated on the router.

[oliv Parcell]

Hello Vasilii, 

Many thanks for your answer and precision about "ip local policy ..."

In fact I need to do PBR on flows coming from the LAN (the PC in the diagram) not from the router itself.  

My challenge is perform PbR on incoming flows for an IP @ that is already configured on the router.

I do not want the router answers on the 10.10.10.1 but instead redirect it the next-hop.

Do you think it is possible ?

Thank you!

Best regards.

Oliv.    

[Vasilii Mikhailovskii · Accepted solution]

Hello.

>>My challenge is perform PbR on incoming flows for an IP @ that is already configured on the router.

This should not be a challenge, as router never (unless you instruct it) inspects source IP-address of the packet. So I assume, the problem you face here has nothing common with PBR.

Most probably you have IP-address conflict if some other devices holds IP-address of the router; or the problem with backtrack traffic (how could the router sent traffic back to the host, that has the same IP-address as itself?).

[John Blakley]

Personally, I don't think what you're wanting to do is going to be possible. Think about the routing. If the router has the ip address on it, that means that it believes the route is locally connected and it will not route outside of that.

Can you give a reason as to why you're wanting to do this? We may be able to come up with a different workaround....

HTH,

John
 

[oliv Parcell]

John, thanks for your inputs.

Indeed I understand what you say. In fact the reason is simple : An error occured on subnets allocation.

An already used range (subnets used to address some specific GRE tunnel interfaces on multiple routers [subnet in Orange on the diagram]) has been implemented elsewhere in a DC.

PBR works well and overrides the routing table for this directly connected subnet except for the locally configured IP @ (and I perfectly understand why the router answers on its IP).

This is problematic when a station from the LAN wants to communicate with a resource in the DC which is already used (interface detail).

I understand the simplest solution would be to re-address but it is too much heavy at the time being.

Any suggestion regarding this local host route overriding would be appricated !

Thanks !

[ghostinthenet · Accepted solution]

PBR just isn't going to work in this scenario. Traffic destined to one of the router's addresses will always be punted up to the control plane for access to the CPU and will bypass anything in the data plane. Even if it did work, you would need to do the same thing at the other end in order to get return traffic.

For these sorts of applications, NAT is usually the approach taken. Local machines will see the remote network as something non-local and remote machines will do the same.

[oliv Parcell]

Hello Jody,

Sorry for my late reply but thank you very much for your confirmation and clarification.

I understand there is no way in this situation for the PbR to work => The flow will be punted to the CPU and the interface will recognize its IP anyway.

Otherwise we found an alternative to overcome this issue : I did not mention it initialy but the interface where I want the flows to be sent through PbR is a GRE tunnel interface.

To avoid dual IP adressing conflict (with local interface and remote server), we deleted the IP address under the tunnel and used 'unumbered WAN_IP' interface instead.  And it works (the device at the other end of the GRE tunnel send back the flows as well).

Anyway thank you very much for taking time to help us.

Best regards.

Oliv.

[ghostinthenet]

That's a creative workaround, Oliv.

As long as the routers in question aren't actually hosting the address, this gets by the control plane problem... so it sounds like you have things well in hand.

Jody