PBR object tracking with IP SLA

[ross.wiggins]

Looking at the attached diagram, we have 3 sites which are connected in a triangle for resilience.  There're different link speeds between the sites.

Site A and site B have two separate links that connect the sites together.

One link is currently operating at 500Mbps (1Gbps circuit limited by hardware on either side of the link)

The other link is currently operating at 400Mbps (1Gbps circuit limited by hardware on either side of the link)

There is a specific business requirement to route certain traffic types over the 500Mbps link and then all other traffic routes over the slower link.  

EIGRP has been implemented throughout the network to provide dynamic routing.  In order to achieve the above routing requirement, the metrics have been manipulated so that the 500Mbps circuit is the least preferred route vs the slower 400Mbps circuit.  This was achieved by setting an interface bandwidth delay of 7 (or 70) to the interfaces on either side of the 500Mbps link.

There're PBR's on the access layer, distribution layer and core layer hardware that routes the specific traffic types via the 500Mbps link.

The delay was manipulated as it seemed to be the easiest, most simplest way of achieving this routing requirement rather than opting to use offset-lists due to the number of subnets/networks that are behind (or inside) the distribution layer switches in either site.  We felt that offset-lists would create too much 'admin' in this case & in the future.

All of this has been configured and is working successfully but there is a new requirement which I'm looking for advice:

I need to ensure that if the 500Mbps circuit failed, as we have used PBR's to hard code the routing, there is no mechanism to automatically re-route traffic.

I was looking at using object tracking PBR with IP SLA to monitor an IP on either side of the link and re-route traffic if the 500Mbps circuit failed.

If I were to configure object tracking on DIST-SW02 in site B to track the loopback (for example) on CORE-R01 in site A and providing it was up; the PBR continues to send traffic to CORE-R02 in site B.  If the circuit failed, the IP SLA track would re-route the specific traffic types via CORE-R01 in site B.

This sounds like it would work up until, the monitored loopback IP would become accessible via the slower 400Mbps link and therefore the IP SLA track would consider the IP to be up & the PBR would re-route traffic back to CORE-R02 even though it doesn't realise the 500Mbps is down.

Is this theory correct?

Is there a way of getting around this?

Is there an alternative way of achieving the above requirements which I haven't thought of?

Please help

[Richard Burts · Accepted solution]

I encountered a similar situation and the solution that I used was to configure a host specific static route for the address that IP SLA was tracking. In the static route I specified both the next hop and the outbound interface which prevents using the slower link.

HTH

Rick

[ross.wiggins]

Thanks for the response Richard.

What exactly would that look like?

DIST-SW02 in site B = 10.10.10.1

CORE-R02 in site B = 10.10.10.2 (LAN interface)

CORE-R01 in site A = 20.20.20.2

Are you suggesting adding a normal static route on DIST-SW02 in site B which is specifically for the IP SLA as per:

ip route 20.20.20.2 255.255.255.255 10.10.10.2

That will force the IP SLA ICMP probes via the 500Mbps router and then setup the IP SLA:

DIST-SW02(config)# ip sla 1
DIST-SW02(config-ip-sla)# icmp-echo 20.20.20.2
DIST-SW02(config-ip-sla)# frequency 4
DIST-SW02(config-ip-sla)# timeout 2000
DIST-SW02(config-ip-sla)# threshold 100
DIST-SW02(config-ip-sla)# ip sla schedule 1 life forever start-time now

DIST-SW02(config)# track 1 ip sla 1 reachability

DIST-SW02(config)# ip access-list extended IP_SLA_Monitor
DIST-SW02(config)# permit icmp host 10.10.10.1 host 20.20.20.2

DIST-SW02(config)# route-map PBR_Failover permit 1
DIST-SW02(config-route-map)# match ip address IP_SLA_Monitor
DIST-SW02(config-route-map)# set ip next-hop verify-availability 10.10.10.2 1 track 1

I believe if 20.20.20.2 was not reachable, then the next-hop would be dropped and DIST-SW02 would use it's routing table to reach hosts/networks that would be classified in my 'type 1 traffic' class learnt via EIGRP.

Or were you thinking of static route tracking using IP SLA?

[Richard Burts · Accepted solution]

You do not need a second PBR to track the availability of the address on R01 core. You just insert the verify-availability in the route map that selects the traffic to route over the 500 link.

Your original post states that there are PBR on access, distribution, and core if I read the post correctly. If so I would assume that you need the verify-availability in all of these PBR configurations.

What you outline for setting up the IP SLA and for using verify-availability is pretty good, except for the static route. If the static route just specifies a next hop then recursive routing might allow IPSLA to find a path to 20.20.20.2 via the 400 link and you do not want that to happen. So your static route needs to specify the outbound interface as well as the next hop, perhaps something like ip route 20.20.20.2 255.255.255.255 10.10.10.2 Gig0/3 (or whatever is the interface you want it to use).

HTH

Rick

[Richard Burts]

I am glad that my suggestions have been helpful. Thank you for using the rating system to mark this question as answered. This will help other readers of the forum to identify discussions that have helpful information. These forums are an excellent place to learn about networking and I hope to see you continue to be active in the forums.

HTH

Rick

[ross.wiggins]

Thanks for your help Rick