Policy based routing to a specific destination

[richard.priest]

Is this possible?

We have a subnet (10.98.186.128/25 that  requires access to a server that is hosted on an IP that isn't controlled by us (IP is 10.212.14.98/32). 

We have multiple paths back into our network so the return traffic ends up coming back via a different route. As a result whilst pings work fine, the web access to the server fails as the route is asynchronous. I can set a static route to 10.212.14.98, but this then breaks access to the server for anyone else not on that subnet.

Is it possible to create a policy based route that states if 10.46.161.128/25 network needs to access 10.212.14.98 then it should use a specific next hop rather than the gateway of last resort?

Many thanks

[richard.priest]

I should add that I want the traffic to follow this route for this destination address (10.212.14.98), only. All other traffic from the source should follow it's normal route.

[BradEast1]

Sure, as long as the hardware/software/licensing permits it.

ip access-list 2190
  10 permit ip any 10.212.14.98/32

route-map XXXXX permit 10
  match ip address 2190
  set ip next-hop X.X.X.X

Then just apply the route map to an interface.

[Richard Burts]

I have several comments about this question.

- the original post specified that this was related to traffic from a particular subnet 10.98.186.128/25

so the access list suggested needs to be revised. It currently has

10 permit ip any 10.212.14.98/32

and it should have

10 permit ip 10.98.186.128/25 10.212.14.98/32

- the original post explains that there are several paths for return traffic from the server and that it is asymmetric paths that cause the problem. I am puzzled about how PBR to force traffic to the server over a particular path will solve a problem involving asymmetric path for return traffic.

- the original post asked whether it is possible to do PBR for a particular source subnet to a particular destination host. The answer to that question is that yes this is quite possible.

HTH

Rick

[richard.priest]

I just realised I confused some of the networks, which probably didn't help my query

the subnet that needs the PBR is 10.46.161.128/25 and the need to access 10.212.14.98/32

the routing works fine for all other users, but the site that is on 10.46.161.128/25 is a bit of a special case, hence the requirement for a PBR. the routurn route will come back the same route as the PBR, without the PBR the route out goes via a different path.

[paul driver]

Hello

Just like to add to Richards comments, That I would suggest also to add some resiliency to the policy as such if for some reason that the destination becomes unavailable via your specified next-hop then traffic between source /destination will take an alternate path, ( ie normal routing or another proffered next hop) otherwise if the next-hop is still active but the destination via is unavailable via that path then traffic could be blackhold.

One possible way would to apply some tracking to the PBR.

access-list 100 permit ip 10.10.10.128 0.0.0.127 host 10.212.14.98

ip sla schedule 5 start-time now life forever
ip sla 5

icmp-echo x.x.x.x source-ip x.x.x.x

track 10 rtr 5

route-map PBR permit 10
match ip address 100
set ip next-hop verify-availability x.x.x.x 1 track 10

res

Paul

[Richard Burts]

I wondered if PBR was sufficient to solve a problem which involved asymmetry in the return path. The original poster says that yes PBR would be a solution. So we just need to address how to implement it. The original poster says there was some confusion about the addressing that he gave us. For the purpose of this discussion it does not matter. We only need to agree on how it is done to provide special routing from the source subnet to the destination host. The example given in an earlier post shows the basic implementation of PBR. Paul makes an interesting suggestion about using the verify-availability parameter in PBR to address the possibility that some next hop in the special routing may not be available or may not work. This is a nice enhancement but I wonder if it is appropriate here. If I understand the original poster correctly if the PBR is not used then the normal path to the server will produce the asymmetry and break access to the server anyway. The original poster can decide if he wants to make use of this feature.

HTH

Rick

[richard.priest]

Many thanks for the advise everyone, it's very much appreciated.

I'm getting the following error when applying the route to an interface 

%Warning:Use P2P interface for routemap setinterface clause

I'm applying it to a Vlan, I presume that this error means that the policy won't be used / activated, as when running a debug on ip policy I don't see any entries whatsoever

Many thanks

[Richard Burts]

Perhaps you can provide information about the device, its interfaces, and the specific config commands that you are using to implement PBR?

HTH

Rick