Enhanced Object Tracking of BGP Routes

[youduel12]

We have been assigned by our customer to change all tracking statements to track the routing protocol rather than the line protocol.  We have a dual-homed WAN environment running BGP from both CE routers to the PE routers (Topology is attached) with HSRP configured for automatic failover.  Furthermore, we have PPP enabled on the Serial/Multilink interfaces.  Currently we have the following configured:

On the Primary CE Device:

track 1 interface (WAN_INTERFACE) line-protocol

delay up 180

!

track 5 list boolean and

object 1

object 2 --> LAN_INTERFACE line-protocol

delay up 180

!

The problem with this configuration is that while it tracks the both CE WAN_INTERFACE and the corresponding PE interface, it does not track if some

Layer 3 device “down the line” fails. 

As previously mentioned, we want to configure track commands to monitor the routing.  The new configuration would be as such:

track 5 (WAN_INTERFACE) ip routing

delay up 180

!

!

track 5 list boolean and

object 1

object 2 --> LAN_INTERFACE line-protocol

delay up 180

!

The questions are... Will this configuration function?  Should this always be the interface with the directly connected route to the WAN network?  And if this BGP route goes down, will HSRP consider the tracking object to be false per the boolean list?  Thank you.

[Vasilii Mikhailovskii · Accepted solution]

Hello, Jed.

Per my understanding, track object should be a technical representation of the measuring entity.

So, we need to understand what should trigger switchover from primary to secondary link!

Is it just no route to 0.0.0.0/0 (I guess it's a single route ISP advertises you)? What if provider lost external link or some had issue?

In such a cases, IP SLA to some external reliable resource (like google 8.8.8.8 or any other) could help.

For example, track object would look on ip sla status (echo 8.8.8.8) and it will trigger in any of the following cases:

- WAN link failed (no external routes);

- PE failed on L3 (BGP has no routes);

- ISP failed (even though you have route in RIB, ip sla is not successful).

PS: not sure why are you tracking LAN interface (on which you are running HSRP).

[youduel12]

Hello MikhailovskyVV,

Thanks for your response.  Pardon me for not including the following information in my previous post.  All sites are connected autonomously to the customer's MPLS cloud using eBGP.  There is no iBGP running between them and they have no knowledge of each other.  Their only commonality are their LAN connections to a Layer 3 Core switch at the site, which handles the HSRP failover.  IP SLA would seem like the logical solution in this case, however, the customer doesn't want to use it due to bandwidth concerns.  Thank you.

[Jon Marshall · Accepted solution]

Jed

Apologies if this seems like a tangent to your question but -

IP SLA would seem like the logical solution in this case, however, the customer doesn't want to use it due to bandwidth concerns.

To me it wouldn't. It depends on the core switch capabilites in terms of how many routes you are receiving but if it is an MPLS WAN then they should not be anywhere near the size of an internet routing table. Could you not run an IGP between the core device and the 2 CEs and redistribute BGP into the IGP. If you wanted to prefer one CE over another then if you used OSPF you could redistribute the preferred routers BGP routes as external type 1s and the backup router as external type 2s and the 1s would be preferred. If using EIGRP then you can influence the metrics with an offset list or increase the dealy on the core switch link to the backup router.

The advantage of using a routing protocol is that it reacts to a a failure all the way down the line so if some device that is passing routes to the primary PE fails the PE no longer advertises those routes to you and you then failover to the backup CE.

An alternative to the above is to use IBGP on the core device and run IBGP between the core device and the the CEs and then use local prefence on the core switch to send all traffic out to the primary CE.

Either would work and there is no extra bandwidth used on the WAN links, only on the LAN links from the core switch to the CEs and this should not be an issue i would have thought.

Is the customer against running a routing protocol on the core switch or have they just not considered it ?

Jon

[youduel12]

Jon,

Thanks for your reply.  In response to your post, at a few sites the customer does have a similar setup to the first scenario that you described, with BGP redistributed into OSPF, with the core switch serving as DR.  However, most sites are running the dual-homed autonomous BGP with HSRP for redundancy as I have previously mentioned.  Furthermore, at this time we don't have access to the core L3 devices and only manage these 2 CE routers.  So, for the most part, there is no IGP to speak of.  On each of these CEs, they have bgp deterministic-med configured, redistributing both static and connected routes.  I believe that they should while they should incorporate an IGP, they don't want to alter anything that seems tho be functioning.  Thank you.

[Vasilii Mikhailovskii · Accepted solution]

Hello, Jed.

Now it's clear.

I think it's right direction to keep HSRP and static default from LAN foward the address.

Going back to your question: I think it's fine to track only most minigful route (like summary from customer data centers - for example, 10.0.0.0/8) and there is no need for LAN interface tracking.