cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
631
Views
5
Helpful
17
Replies
bedurand
Beginner

Design Question: Conditional BGP Advertisement via IP SLA

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
balaji.bandi
VIP Expert

before we get into the solution,

 

when the BGP goes down with ISP1, other ISP2  BGP coming online and making peer establishment and getting routes will be taking some time - in the mean time your network will be down towards internet, is this acceptable to Business?

 

 

 



BB


*** Rate All Helpful Responses ***

Thank you for the response.

 

We must maintain the BGP peering with ISP 2 as we are using it for other public subnets and egress Internet traffic.  We also want to avoid any required manual intervention.

 

- Ben

MHM Cisco World
Rising star

Spoiler
 

As i understand you the solution is

Make one neighbor not two,

Bgp depends on avainlibilty of any isp to make neighborship and hence,

If isp 1 is up then bgp neighorship use it and advertise the route,

If isp2 is up then bgp neighborship use it and advertise the route.

This way only and only one bgp work and advertise route.

Thank you for the response.

 

We must maintain the BGP peering with ISP 2 as we are using it for other public subnets and egress Internet traffic.  We also want to avoid any required manual intervention.  Obviously if we only peered with ISP 1 and manually peered with ISP 2 as needed there would not be an issue, but we must maintain our peering with ISP 2 at all times.  Conditional BGP advertisement would be a close to perfect solution if we could receive an advertisement from ISP 1, but that's not the case.  The only other way I could think of was to deploy a second router with IP SLA tracking to ISP1, attach a "bogus" null0 route to this track and feed that route via BGP to my Internet border router.  That way, if that bogus route is not received from my "tracking router", my Internet router won't advertise to ISP 2.  This means deploying a second router just for that function however.

ip sla 8

icmp-echo 8.8.8.8 source-interface GigabitEthernet0/1

threshold 800

timeout 1000

frequency 1

ip sla schedule 8 life forever start-time now

ip sla 9

icmp-echo 31.13.65.1 source-interface GigabitEthernet0/1

threshold 800

timeout 1000

frequency 1

ip sla schedule 9 life forever start-time now

track 5 list boolean or

object 8

object 9

delay down 20 up 50

!

track 8 ip sla 8 reachability

delay down 5

! track 9 ip sla 9 reachability

delay down 5

event manager applet BGP_NEIGHBOR_DIRTY

description SHUT DOWN BGP NEIGHBOR IF RTT OVER 1000 FOR 5 SECONDS

event syslog pattern "5 list boolean or Up -> Down"

action 1.0 cli command "enable"

action 1.1 cli command "configure term"

action 1.2 cli command "router bgp xxxxx"

action 1.3 cli command "neighbor xxxxxxx shutdown"

action 1.4 cli command "end"

event manager applet BGP_NEIGHBOR_Clean

description BRING UP BGP NEIGHBOR IF RTT UNDER 1000 FOR 50 SECONDS

event syslog pattern "5 list boolean or Down -> Up"

action 1.0 cli command "enable"

action 1.1 cli command "configure term"

action 1.2 cli command "router bgp xxxxx"

action 1.3 cli command "no neighbor xxxxxxx shutdown"

action 1.4 cli command "end"

 

 

EEM with IP SLA & BGP,

if no neighbor is not solve your issue try use net 1.1.1.1 mask 255.255.255.255 

 

this make detect the reachability of ISP and same time not advertise the net. 

Thank you for the response.


As I mentioned before, we do not want to use EMM as a solution as it is hard to support for junior administrators.  Additionally, as I previously mentioned, we need to maintain our BGP neighbor relationship up with ISP2.  I understand that your approach with EMM could be used to control prefix-list to that neighbor which would essentially accomplish what we need.  However we must remain with a non-EMM solution.

 

Thanks for your time.

paul driver
VIP Mentor

Hello


@bedurand wrote:
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

Why not? -

The whole basis of BGP is to utilize the attributes associated with the protocol, Advertising to either ISP won’t have any effect on your current routing path if you apply it correctly.

 

 


@bedurand wrote:
ISP 1 does not (and will not) advertise any routes to us

So whats the point of having bgp running to ISP 1?



kind regards
Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future

Hi Paul,

 

I didn't want to complicate the scenario but here goes :).  ISP 1 is our DDoS provider.  We advertise our block to them and in turn they advertise it to the Internet on our behalf.  All traffic should route to them first.  We do currently prepend towards ISP 2, but those either get stripped or the AS-path diameter of that route becomes too large, but either way this results in our route appearing in some BGP spyglasses coming directly to us via ISP 2.  Some other spyglasses show it going to DDoS.  The peer to ISP 2 is to receive the BGP routing table and send everything out directly back to Internet.  We don't want to put all our eggs in the DDoS provider basket by filtering out the advertisements to ISP2 in case something happened with their service.  So in short:

 

- Inbound traffic should go to DDoS ISP 1's advertisement of our addresses then get sent to us via GRE tunnel (through ISP 2 incidentally)

- Outbound response traffic goes out directly through ISP 2.  We don't route anything back through our DDoS provider which is why they do not provide any routes to us.

 

- B

 

Ugh,  my reply somehow got lost and I have to retype it all


Essentially to give you the bigger picture,  “ISP 1” is our DDoS provider and ISP 2 is our true “here’s your circuit” Internet service provider.  On the border router connecting / peering to ISP2, we have a GRE tunnel through ISP 2 to reach the DDoS provider’ tunnel destination, over which we advertise our public IP block via BGP.  That DDoS provider in turn advertises our network to Internet and so all inbound traffic should hit them first.  The intent is to have the following:

 

  • All inbound traffic goes to DDoS provider
  • DDoS provider sends us the inbound over GRE tunnel
  • We respond directly out ISP 2 to Internet.

 

We are currently advertising to ISP 2 with prepends, however those prepends either get stripped or go over someone’s AS path diameter maximum.  Either way, the result is that in some BGP spyglass we see our subnet routed through our ISP 2 directly while in some others route through the DDoS provider.  We need everything to go to the DDoS provider.  We do not want to put all our eggs in the DDoS provider basket by stopping filtering out the advertisements to ISP 2 in case something were to happen to the DDoS provider.  However, the prepend approach is proving to be ineffective overall.  We do not route anything back to the DDoS provider over the GRE.  It is only for the inbound traffic that passed their DDoS inspection.  This is why they are unwilling to advertise a route to us that we could use to trigger a conditional BGP advertisement to ISP 2.

 

I have considered TCL / EMM, however there is a “complexity” factor to consider where the poor soul (i.e. not me) on duty at 2am that would have to troubleshoot it would have no clue.  I’m trying to stay within the realm of IOS commands J

 

I have considered a secondary router with IP SLA locally, tracking the DDoS provider and controlling a bogus route sent via BGP to my Internet border router.  That could be used as the NO-EXIST route for the decision.  However, that means additional hardware. 

Georg Pauwen
VIP Expert

Hello,

 

not sure if this has already been asked, but what does your internal topology look like ? Are both ISPs connected to the same router, or two different routers (and in the latter case, how are both routers connected) ?

 

Either way, why don't you use an IP SLA to ISP 1, and when the SLA is down, change the networks you send to ISP 2 with an EEM script that adds a route map matching the subnet that you want to advertise ?

Hi Georg,  thanks for your time.  I'll be lazy and simply paste my response to another contributor.

 

Essentially to give you the bigger picture,  “ISP 1” is our DDoS provider and ISP 2 is our true “here’s your circuit” Internet service provider.  On the border router connecting / peering to ISP2, we have a GRE tunnel through ISP 2 to reach the DDoS provider’ tunnel destination, over which we advertise our public IP block via BGP.  That DDoS provider in turn advertises our network to Internet and so all inbound traffic should hit them first.  The intent is to have the following:

 

  • All inbound traffic goes to DDoS provider
  • DDoS provider sends us the inbound over GRE tunnel
  • We respond directly out ISP 2 to Internet.

 

We are currently advertising to ISP 2 with prepends, however those prepends either get stripped or go over someone’s AS path diameter maximum.  Either way, the result is that in some BGP spyglass we see our subnet routed through our ISP 2 directly while in some others route through the DDoS provider.  We need everything to go to the DDoS provider.  We do not want to put all our eggs in the DDoS provider basket by stopping filtering out the advertisements to ISP 2 in case something were to happen to the DDoS provider.  However, the prepend approach is proving to be ineffective overall.  We do not route anything back to the DDoS provider over the GRE.  It is only for the inbound traffic that passed their DDoS inspection.  This is why they are unwilling to advertise a route to us that we could use to trigger a conditional BGP advertisement to ISP 2.

 

I have considered TCL / EMM, however there is a “complexity” factor to consider where the poor soul (i.e. not me) on duty at 2am that would have to troubleshoot it would have no clue.  I’m trying to stay within the realm of IOS commands J

 

I have considered a secondary router with IP SLA locally, tracking the DDoS provider and controlling a bogus route sent via BGP to my Internet border router.  That could be used as the NO-EXIST route for the decision.  However, that means additional hardware. 

Hello
Possibly consider policy base routing?
PBR all you lan traffic, tracked on the gre destination or interface status of ISP1, as such if/when you lose ISP1 you push everything via ISP2.

The cause of concern  (if any) is the sngle point of failure regards ISP2 as thats being used for your logical GRE peering with ISP1



kind regards
Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future

Hi Paul,

 

As described in the updates scenario, we already send everying outbound towards ISP 2 (the true ISP).  The issue is not the oubound traffic (we never route through the DDoS provider),  the issue is controlling the inbound traffic and making sure that all of it is sent to the DDoS provider when all is well, and never directly through ISP 2 if the DDoS service is up.  I don't see how PBR would help here

 

- Ben

Hello Ben
Okay so you are concerned about ingress traffic and how you can manipulate it for ISP1 to be the preferred path.

Regards AS-Path Prepending have you contacted ISP2 about it, do they know you are wanting to do this, it may be by policy they are denying it until you have agreed it with them?

Unless you have assistance with the ISPs i cannot see how you can manipulate ingress traffic even with an additional router as you need to advertise bgp attributes (as-path, med etc..) So they can be seen by the ISPs but if they are being denied for some reason, not sure how this can be accomplished




kind regards
Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future