Understanding of Policy Based routing

[tamimkushjar]

Hi,

I have a scenario for Policy based routing and I would like to have a opinion how the traffic should flow.

PBR is active on the LAN and is filtering traffic with the help of route-map which refers to a ACL. (standard configuration)

The route-map has a recursive next hop of it's neighbor which is not a direct hop but known via BGP.

Suppose that this recursive next hop is not seen anymore in BGP routing table, how should the router behave?

a) The packets are matched no matter if the recursive next hop is seen or not and is routed out over the PBR WAN interface.

b) The packets are matched even if the recursive next hop is not seen, but it sends the packets over the default WAN interface.

c) The packets are not matched due to the fact that recursive next hop is not seen in the BGP table and is routed directly over the default WAN interface.

Looking forward to hearing from someone what the right scenario should be.

[paul driver]

Hello

Are you aware of any uRPF enabled  anywhere validating the soruce addrressing?

res

Paul

Please don't forget to rate any posts that have been helpful.for verification of the socurce 

Thanks.

[tamimkushjar]

Hi Paul,

I have searched in the TFTPboot for the following syntax "verify unicast" and I didn't find any router with that particular syntax.

So should it be present or not? Since I am not very familiar with this feature

[paul driver]

Hello

I was querying if this was applied?
Basically depending on the mode its set in can prohibit the connection from a source .

What you can apply if it isn't already is under the route-map - set ip next-hop verify-availability

This may assist in verifying the validity of the recurcursive IP address

Res
Paul

Sent from Cisco Technical Support iPad App

[tamimkushjar]

Hi Paul,

I have looked in my mail and I found out I already have tried your suggestion.

So again just to summarize.

1) I have already used verify availability in the route-map as shown below

In fact the debug of the router even showed that the normal forwarding happened but my ping test failed

maybe I should perform some additional test and use a bidirectional configuration.

route-map traffic-offload permit 10

description Offloadingv2-via-Nij

match ip address traffic-offload-acl

set ip next-hop verify-availability 172.25.100.209 100 track 1

route-map traffic-offload permit 20

description Offloadingv2-via-Oud

match ip address traffic-offload-acl

set ip next-hop verify-availability 172.25.100.217 200 track 2

ip sla monitor 1

type echo protocol ipIcmpEcho 172.25.100.209 source-interface FastEthernet0/1

frequency 10

ip sla monitor schedule 1 life forever start-time now

ip sla monitor 2

type echo protocol ipIcmpEcho 172.25.100.217 source-interface FastEthernet0/1

frequency 10

ip sla monitor schedule 2 life forever start-time now

2)  I also used a default route statement in the route-map as shown below and come to think of I probably didn't used a configuration on the other end.

route-map traffic-offload permit 10

description Offloadingv2-via-Nijmegen

match ip address traffic-offload-acl

set ip next-hop recursive 172.25.100.209

set ip default next-hop 134.222.146.174

route-map traffic-offload permit 20

description Offloadingv2-via-Oudemeer

match ip address traffic-offload-acl

set ip next-hop recursive 172.25.100.217

set ip default next-hop 134.222.146.174

Bottom line, at this moment I am not sure what happened to the packets since the outgoing ACL WAN interface output are not listed  so I have to go back to the drawing board and make a new test plan and perform the 2 steps above again. I will keep you posted about the progress

[tamimkushjar]

Dear All,

I finally managed to pinpoint the problem here!

and the reason why it didn't work anymore was, that the customer was advertising a default route from the LAN, meaning the offload traffic was redirected back towards the LAN instead of the WAN interface!

Despite the fact that I had a default interface statement in my route-map!

    ••>Packets where travelling this way as it should =••>====••>

                        ---------------

router1 remote<                                         >router2 HQ   <••Reply packets received from the customer<••==<••

                      -----------------

So just to bring back the last scenario: I couldn’t remember what happened to the reply packets on the HQ! Since I didn’t had any information of the test ACL outputs!

Anyway so I was testing the situation again with the customer last evening and I found out that offload packets from the remote site was sent over the default interface after I had disabled the offload tunnel interface of the remote site. (which is good)

Then I checked on the HQ, if the packets where offered towards the LAN which went just fine as well!

However the reply packets where not seen over the WAN interfaces! (default WAN interface & offload WAN interface)

And I verified once again if I received any reply packets from the customer on the LAN interface which seemed to be the case!

So then I was thinking where could the packets lead to if it’s not been seen over the WAN interfaces!

The suspicion was that maybe the default route which was advertised by the customer could be the problem!?

And I made an incoming route-map on the BGP session with the customer, blocking the default route from the customer and immediately the traffic started to go over the default WAN interface as it should!

What have I learned from the situation?

As soon as the packet is processed by a PBR interface it doesn’t look to the actual destination route!

No!, instead the router is looking for the recursive-next-hop address which is not existing, so it tries to find an alternative route which is the default route!

Apparently the default route is more attractive than the PBR default interface statement!

route-map traffic-offload permit 50

match ip address traffic-offload-acl-Ctsy

set ip next-hop recursive X.X.83.248   <•• Route is not seen anymore

set default interface GigabitEthernet0/0.100 <•• And it doesn’t care about this statement since the default route has a higher priority… <•• (my current conclusion..?)

At this moment I am trying to find a solution for the current situation, which is that the customer is sending a default route and I have to somehow bypass this route in order to get offload work seamlessly again!

As soon as I have found any results I will post it and if you have any suggestions please let me know.