From: Piyoush Sharma (piyoush@gmail.com)
Date: Sat Dec 06 2008 - 17:38:55 ARST
You are absolutely right! I was thinking in terms of IP SLA track object.
The idea is that should the track object return a false (no reply to echo)
it would cease the advertisement of the /32 to the local iBGP peer. The
ISP's PE router does respond to icmp requests.
However, as Jay and Wes have pointed out, it would still imply several
minutes, if not hours, of downtime, should the primary link fail.
In this case, the question is, if I were to use the ISP's community strings
to make the route through ISP2 as backup, and should the ISP link upstream
or to us fail, the convergence would still take the same amount of time...
only this time BGP would withdraw that route... the default BGP scanner
interval is 60minutes... or would this trigger an immediate update to their
directly connected peers??
However, that said, if I can show these pros and cons to my manager, maybe I
would get approval to implement OER (additional HW) <grin> - if there were
to be an outage at some stage, this would be the smoking gun
Piyoush.
On Sat, Dec 6, 2008 at 11:31 AM, Wes Stevens <wrsteve33-gsccie@yahoo.com>wrote:
> Hi Scott,
>
> Yes IPSLA would work. That is getting into OER which is different from BGP
> conditional advertisement. We do this with ethernet connectivity also to
> mpls L3 vpn's. Lot of new things there as you can us IPSLA to monitor things
> like packet drops or jitter and move routes around. Really helps move
> traffic around brownouts where the routing protocol still thinks things are
> fine, but our carriers are dropping enough packet to make a big impact on
> our clients.
>
> I still prefer using as prepend and backup route community strings out to
> the ISP's. We actually bring in full routes from two separate providers at
> each data center and advertise our prefixes out both to load balance out and
> in. We keep configs ready with as prepend and backup community strings. If
> one of the ISP's has a maintainence window we go in and make it the
> secondary before their window starts. If you do this when both are still up
> you won't have any convergence issues as you can still receive traffic on
> the secondary ISP while BGP converges. I have timed convergence out of our
> Houton data center and it takes up to 15 minutes to converge to parts of AP
> and that is not to the little ISP's but some of the larger ones. If we just
> allow the ISP to bring us down when there is still traffic routing through
> them, it is going to be considered an outage even though we have a backup
> path ready to go - convergence time is too long....
>
> Take care,
>
> Wes
>
>
>
> ----- Original Message ----
> From: Scott M Vermillion <scott_ccie_list@it-ag.com>
> To: Wes Stevens <wrsteve33-gsccie@yahoo.com>; Piyoush Sharma <
> piyoush@gmail.com>
> Cc: ccielab@groupstudy.com
> Sent: Saturday, December 6, 2008 1:10:44 PM
> Subject: RE: BGP AS-Path Prepend being ignored on the Internet routers
>
> Hi Wes,
>
> Great post. Just as an aside, though, I think what Piyoush was thinking of
> was an SLA track object to the peer IP address across the /30 or /31 (seems
> I saw that in an earlier post in this thread). That's how you get around a
> physical interface not going down/down (e.g. Ethernet!). Timers are
> tunable
> so that you can directly influence convergence time. I use this in mobile
> systems all the time because my 6" Ethernet segment between my router and
> my
> cellular data card or SATCOM device is unlikely to go down/down when the RF
> link goes to pot (some vendors are getting better, though, and are
> beginning
> to include an option whereby you can force the local Ethernet interface to
> go down when RF connectivity is lost).
>
> Of course the ideal address to target with the SLA would be the actual
> peering address, so the carrier would have to allow ICMP echo request/reply
> as appropriate. There are also more advanced options available with EEM...
>
> Cheers,
>
> Scott
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Wes
> Stevens
> Sent: Saturday, December 06, 2008 8:10 AM
> To: Piyoush Sharma
> Cc: ccielab@groupstudy.com
> Subject: Re: BGP AS-Path Prepend being ignored on the Internet routers
>
> The best way to handle this is with what Marko is suggesting. All ISP's
> that
> I have delt with (we current peer with 8 around the world) will have a
> community that you can send them that make the prefix a backup route. The
> ISP will then only use that route if there are no other routes to that
> prefix available.
>
> Also keep in mind that the currect number of prepends to use is difficult
> to
> judge. This is especially true if the primary link that you want used is
> through an ISP that is not a tier one and the backup is. As the tier 1
> provider will have much better peering you may get to some ISP's that have
> a
> hop count to you that is much better through the tier 1 ISP and a prepend
> of
> 3 may not be enough. But don't make it too long as most ISP's have a total
> path limit of around 15 and will drop any prefixes that exceed it. Best to
> just to use the tier 1 provider as your primary if you can.
>
> Your solution with conditional advertisement is complex - and more compelex
> is not good. It also has convergence issues. When you lose your primary
> connection you will have to start advertising from your secondary and it
> will take time to converge. Convergence will be better if you are always
> advertizing through your backup ISP. The last issue with it is that the
> physical /30 has to go down in order for it to work. I know that in most of
> our cases we bring in an optical interface over a ring. That rarely goes
> down. But we have had more then one case where there has been another
> problem along the path and we have lost BGP peering with the physical still
> up. You will have no failover in this case. If you are using ethernet for
> your connectivity this just get more likely.
>
>
>
>
> ----- Original Message ----
> From: Piyoush Sharma <piyoush@gmail.com>
> To: Marko Milivojevic <markom@markom.info>
> Cc: Cisco certification <ccielab@groupstudy.com>
> Sent: Friday, December 5, 2008 2:43:03 PM
> Subject: Re: BGP AS-Path Prepend being ignored on the Internet routers
>
> Hi Marko,
>
> First of all, it is a real-life (threatening) scenario. It brought traffic
> down for a few hours ( it was done around midnight by one of the
> consultants).
> Your explanation on how the ISP makes those routing decisions confirms the
> suspicions I had about the situation. Thank you for the explanation on the
> ISP routing behaviour.
> In this case, I have decided to go ahead with conditional advertisement in
> BGP. This would make the design complex, but we would still retain control
> over how the networks are routed across the internet.
>
> Here is a brief design of what I am planning, let me know if I am missing
> something...
> iBGP peering between Router 1 and Router 2
> Advertise the IP address of the interface connecting to the respective ISP
> (Router1->ISP1 ; Router2->ISP2) into BGP
> (Its a serial interface - /30 subnet, so if the line protocol goes down,
> the
> directly connected route would disappear and would also be removed from
> iBGP
> advertisement)
> Filter that route from the ebgp advertisment.
> Configure BGP conditional advertisement - if Router1's connection to the
> ISP
> goes down, its directly connected interface would no longer be in the
> routing table, it would also disappear from the iBGP advertisement - this
> would cause Router2 to start advertising the network to its eBGP peer
>
> It might sound a bit confusing... trying my best to not ramble on...
> I am open to suggestions and any holes in my theories/assumptions. One
> possibility is that if the ISP's upstream connection were to die.... but I
> do not know the probability of that happening...
>
>
>
> On Fri, Dec 5, 2008 at 12:20 PM, Marko Milivojevic
> <markom@markom.info>wrote:
>
> > First of all, is this a lab or real-life scenario?
> >
> > If it's a lab, you are doing something wrong, as this should work.
> >
> > However, if you are dealing with real, live, wild, Internet, things
> > are not that simple out there. While AS_PATH prepending is perfectly
> > valid "traffic engineering" technique, it doesn't always work. Large
> > number of carriers will always prefer "customer" routes over "peer"
> > and "transit" (upstream) ones. If you are a customer of relatively
> > large carrier, no amount of prepending will help you, as they will
> > always prefer the direct route. That route will then be announced to
> > their customers, peers and transit carriers. Depending where in the
> > "food chain" your other ISP is, you may get very little or no traffic
> > over the other link, even though prepending would suggest otherwise.
> >
> > Now, this clearly appears to be a problem. Luckily there are
> > solutions. To understand them, I will spend a minute to explain how
> > BGP in large networks usually works. Dealing with as-path filters,
> > prefix-lists, etc. is fun and interesting thing to do when you have
> > 2-3 peers. There are networks that have thousands of BGP sessions and
> > peers. Some of them peer in multiple locations and in some of these
> > locations, different policies are applied. Can you imagine doing that
> > with access-lists... of _any_ sort? No, neither can I. This is why we
> > have BGP communities.
> >
> > Prefixes are tagged with comprehensive set of communities at the
> > "routing ingress" (i.e. when received from a customer). All outbound
> > policies in the entire network act only on these communities. AS_PATH
> > and other things are not considered in the decision which prefixes to
> > announce to other networks. Customers get all, or subset, peers get
> > customer routes, etc. Now, when routes are tagged with communities,
> > they are usually assigned LOCAL_PREF, as well. This attribute is
> > assigned based on what sort of session you have. You get the idea.
> >
> > Now, the remedy for this situation is to ask your carriers to provide
> > you with the information about the communities they will accept from
> > you. Vast majority of serious SP's provide customers some control over
> > their routing, ranging from simple prepending (where your community
> > instructs them to prepend elsewhere), to region-based prepending (i.e.
> > prepend my routes to your peers in Europe) and remote-triggered
> > blackholing. Some of these communities control what sort of preference
> > your routes get in the carrier's network. This is what you need :-).
> >
> > --
> > Marko
> > CCIE #18427 (SP)
> > My network blog: http://cisco.markom.info/
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Thu Jan 01 2009 - 12:53:07 ARST