cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2269
Views
5
Helpful
17
Replies

Design Question: Conditional BGP Advertisement via IP SLA

bedurand
Level 1
Level 1

Greetings and thank you for your time,

 

To summarize/simplify my issue, we have two ISP to which we need to conditionally advertise our public subnet to ISP 1 but not the ISP 2, unless ISP 1 is down.  We don't want to use AS prepend to ISP 2, we simply don't want to advertise to them unless there is a problem with the first provider.  We can't use the traditional Conditional BGP Advertisement method because ISP 1 does not (and will not) advertise any routes to us, so we can't trigger on a NON-EXIST received BGP advertisement.

 

My question:  is there a way to tie the conditional advertisement to ISP 2 based on an IP SLA result towards ISP 1?  Keep in mind that I cannot track on my local Null0 route used to inject our prefix into BGP since that would kill all BGP advertisements to all neighbors if it disappeared, not just  ISP 2.  IOS also won't let me replace a "match ip" with a "match track" in the NO-EXIST route-map because it is used for conditional BGP advertisement.  Yes, for once IOS is smart and lets me know.

 

Any insight on a possible approach would be appreciated.  Thank you.

 

- Ben

17 Replies 17

Hi Paul,

 

Understood about engaging ISP 2, however I'm trying to investigate a solution that we control ourselves at the source.

 

The approach with the secondary router would be:

 

- have the secondary router perform the IP SLA validation to the public IP of the DDoS provider (through the border router and ISP 2)

- On that secondary router, advertise a static null0 route for something bogus like "1.1.1.1/32" to the primary border router.  Attach a track statement to that route using the IP SLA to the DDoS provider, so that if SLA monitor goes down, the Null0 1.1.1.1 route disappears from the secondary.  In turn, secondary would then stop advertising that route 1.1.1./32 to the border router.  

- Border router uses standard Conditional BGP advertisement to to decide whether to advertise the block to ISP 2 based on the 1.1.1.1 route received from secondary router.

 

It's ugly, it needs an additional router, but I don't see any other way to tie an IP SLA monitor to a conditional BGP advertisement to ISP 2.

Hello
Apologies but i don’t see how that would accomplish anything unless i have totally misunderstood your request you are on about traffic engineering ingress routing towards your site via a certain ISP without without using a bgp attributes so using an additional router would have not have any bearing on this.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hi Paul,


Here is how I was able to make it work in CML:

 

Screenshot 2021-03-07 133437.jpg

 

The "IP SLA Injector" router monitors the public IP address of the DDoS provider (Lumen) used for GRE tunnel destination by the "Border" router.  The SLA Injector has a static route to Null0 for 1.1.1.0/24 (a bogus network) that is tracked by the IP SLA monitor.  If the IP SLA monitor fails, that null0 route disappears from its routing table.  Injector also feeds that 1.1.1.0/24 route to the Border router via ibgp.  Therefore when the SLA fails on the Injector and the static null0 disappears, it also disappears from the ibgp advertisement to the Border router.

 

The Border router uses the standard conditional BGP advertisement process with its ISP neighbor.  This condition for the advertise-map to the ISP neighbor is essentially "if you have subnet 1.1.1.0/24 in your BGP table, don't advertise 200.1.1.0/24" to that neighbor.  So in normal times, if the IP SLA is up with the DDoS provider's IP, Border doesn't advertise the block to the ISP at all, only to DDoS provider over GRE.  If we lose reachability to the DDoS provider from the Injector (and thus presumably the GRE tunnel on Border and its associate BGP neighbor to DDoS), the advertise-map condition on Border is no longer met (1.1.1.0.24 is no longer in the routing table), so 200.1.1.0/24 (the public block) starts being advertised to the ISP directly.

 

Ugly, but it works.  Open to suggestions on a simpler approach

Review Cisco Networking products for a $25 gift card