From: Piyoush Sharma (piyoush@gmail.com)
Date: Fri Dec 05 2008 - 18:43:03 ARST
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