PBR

[sridhar ch]

I have a PBR configured between my siteA and B. Site A and B has 2 links. one link is used for data and voice and the other is for DB replication. I have configured a route map with 2 statements. Both statements has 2 IP's set in the set next hop command. problem is when the hop one is not reachable, traffic is dropping instead of routing to other hop configured in the command. Please find the configuration below ands advise what should be done to resolve the issue.

Configuration:

Site-A

route-map Key-bank permit 10
 match ip address 146
 set ip next-hop 192.168.1.2 172.168.1.2
 set ip next-hop verify-availability

route-map Key-bank permit 20
 match ip address 147
 set ip next-hop 172.168.1.2 192.168.1.2
 set ip next-hop verify-availability

Site-B

route-map Key-bank permit 10
 match ip address 146
 set ip next-hop 192.168.1.1 172.168.1.1
 set ip next-hop verify-availability

route-map Key-bank permit 20
 match ip address 147
 set ip next-hop 172.168.1.1 192.168.1.1
 set ip next-hop verify-availability

Attached the diagram.

Thanks,

Sridhar

[Kelvin Willacey]

You will need to use IP SLAs and tracking to achieve this, otherwise it will only failover if the link is physically disconnected.

[sridhar ch]

Thanks.

so the new configuration will look like below?

Site-A

route-map Key-bank permit 10
 match ip address 146
 set ip next-hop verify-availability 192.168.1.2 10 track 1
 set ip next-hop verify-availability 172.168.1.2 20 track 2
 set ip next-hop verify-availability

route-map Key-bank permit 20
 match ip address 147
 set ip next-hop verify-availability 172.168.1.2 20 track 2
 set ip next-hop verify-availability 192.168.1.2 10 track 1
 set ip next-hop verify-availability

Site-B

route-map Key-bank permit 10
 match ip address 146
 set ip next-hop verify-availability 192.168.1.1 10 track 1
 set ip next-hop verify-availability 172.168.1.1 20 track 2
 set ip next-hop verify-availability

route-map Key-bank permit 20
 match ip address 147
 set ip next-hop verify-availability 172.168.1.1 20 track 2
 set ip next-hop verify-availability 192.168.1.1 10 track 1
 set ip next-hop verify-availability

[Kelvin Willacey]

Apart from the SLAs that is not shown, yes it should look like that.

[sridhar ch]

thanks, missed to include track commands in the configuration.

one final question, what would be the case if both tracks are up? will the traffic gets load balanced between the 2 links or does the second command will be triggered only if the track1 is down. 

set ip next-hop verify-availability 192.168.1.2 10 track 1
set ip next-hop verify-availability 172.168.1.2 20 track 2

[Richard Burts]

I believe that it would not load balance. I believe that if both tracks reported as being up that PBR would do both of the set commands and the result is that you would use the second one.

HTH

Rick

[sridhar ch]

hi Joseph,

i dont want to do load balance. as i said in my post, both are backup to each other.

just want to double check if having both commands in the route map statement and if both tracks are up, how the route map will actually process? will it process the first command first or will it process both bcoz both the tracks are up.

set ip next-hop verify-availability 192.168.1.2 10 track 1
set ip next-hop verify-availability 172.168.1.2 20 track 2

[Kelvin Willacey]

It will use the first one once the track is up, if the track is down it will use the other.

[Richard Burts]

I have seen the behavior described of using the first one if track is up and using the second if track is not up when both IP addresses are specified on a single set command. With two set commands I am not convinced that the behavior is the same. Have you seen it work on actual routers where PBR specifies two set commands for two IP address and if the first one is up that PBR uses the first one and stops?

HTH

Rick

[Kelvin Willacey]

I have never had that issue, it always fails to the second next hop once the tracking goes down for the first and I do have it in production.

[Richard Burts]

If you have the PBR with two set statements and have it in production then that is very good to know. I have not tested that combination, much less put it in a live network. So it is good to have the voice of experience.

HTH

Rick

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Did you want to load balance?

If so, you might be able to do that statically, load balancing flows via routing, or dynamically using OER/PfR.  However if you did want to load balance, you'll probably want to implement QoS so VoIP gets priority and your DB replication gets "left over or available" bandwidth.

PS:

A possible advantage of using QoS, you can use both links, concurrently, for all your traffic types, and it doesn't matter which one fails.