From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Sat Dec 06 2008 - 17:44:06 ARST
> That is getting into OER which is different from BGP conditional
advertisement.
Oops! I guess I thought I had earlier read/understood the post you were
replying to but apparently that wasn't the case at all. OK, I'll shut up
now...
;~)
----- 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
This archive was generated by hypermail 2.1.4 : Thu Jan 01 2009 - 12:53:07 ARST