I'm forwarding this off inet-access because there is a lot more BGP clue
here. Anyone have any comments on the particular situation below, and/or
regarding announcing different routes at multiple locations to multiple
providers with single/many different ASNs?
Thanks,
-- Tim
First, it's my understanding that I can use a single ASN for the BGP
peering at each of these networks. Am I mistaken?
if you don't care to reach one from the other.
randy
It works just fine with isolated networks. Just advertise the portions of
the address space you are using out each EBGP connections. Overlapping
this space with isolated networks falls under the category of bad mojo.
Email me off-line if you need specifics on how to set this up. Only one AS
number required.
If he was to use multihop EBGP to maintain a full BGP mesh between all of the
BGP speakers in his ASN and each POP only announced it's own networks
upstream...?
-- Tim
First, it's my understanding that I can use a single ASN for the BGP
peering at each of these networks. Am I mistaken?if you don't care to reach one from the other.
Well, you _can_, if you want to put the time and effort into performing
the evil routing voodoo. I can think of a few ways of doing it, without
even bridging over a tunnel. I wouldn't advise it, however.
i disagree strongly. i think it is a really great idea for our competitors
to deploy.
randy
If he was to use multihop EBGP to maintain a full BGP mesh between all of the
BGP speakers in his ASN and each POP only announced it's own networks
upstream...?
Close, I think.
Each POP should advertise its nets via standard EBGP.
They could then setup an IBGP mesh internally. The main point of importance
here is that their next-hop's network must be originated by the upstream
provider.
However this is probably a Bad Thing. You'd need to crank on the IBGP
session's timers to account for lossy paths.
I wonder if there's any particular reason why they're not using private AS
numbers with their immediate upstreams and letting _them_ advertise the
networks.
It works just fine with isolated networks. Just advertise the portions of
the address space you are using out each EBGP connections.
Assuming of course each block of address space is big enough to stand on
it's own when compared with other's BGP filters (see other thread). If
all the parts put together are big enough, but they're not big enough
individually, as long as you're using the same transit provider in each
location, you can ask them to aggregate the advertisement together for you
to present to the rest of the world (which you should do anyway if you can
to be a good Internet citizen).
Of course, you'll need to make sure that you have default routes pointed
out the transit connections in each site or you won't be able to get
traffic to and from your other sites due to BGP loop detection.
Overlapping this space with isolated networks falls under the category
of bad mojo.
Not necessarily, as long as you're aware of exactly what you're doing.
Brandon Ross Network Engineering 404-815-0770 800-719-4664
Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com
ICQ: 2269442
Read RFC 2644!
Stop Smurf attacks! Configure your router interfaces to block directed
broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
Unless he has a specific need for a full mesh (and yes, I know that goes
against normal practice), I would recommend to not complicate things until
his internal network is done.
If it is necessary to complicate things, then it would probably be easier
to setup GRE tunnels between the sites and run IBGP inside them.
Brandon Ross Network Engineering 404-815-0770 800-719-4664
Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com
ICQ: 2269442
Read RFC 2644!
Stop Smurf attacks! Configure your router interfaces to block directed
broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
Tim,
It's not necessary to mesh your BGP speakers - only a good idea. As long
as you don't care about sharing routing information (or even getting
decent routing), this will still work. I did it at my last ISP, and it
worked like a charm.
I don't think he can possibly establish a full iBGP mesh without either
having direct connectivity or using tunnels. As long as he just meshes the
routers in the same site, and uses seperate address space at each site,
he's fine.
This even works if you have some of the same upstreams in different sites
- I did it with both Digex and Sprint. (And I was only advertising /23s in
some cases...). I even did it with one site having Verio as an upstream.
There is an other way, strange but working - don't use ASn at all, use the ASN
of the providers with some IGP or _bgp over private AS_ protocol. It work.
(I do not advise this, btw).
It is possible to use a single ASN to do this, without
meshing them.
Here's how:
1) You can not run your bgp speakers in a default-free environment.
2) You must point default at your upstream(s) in each location.
3) Because you are using the same ASN, bgp will drop the
announcement from your other side once it sees it, to prevent
a 'routing loop'.
4) You can not have any bgp downstreams and have this work
properly.
5) This would be a higly fragile environment, and is not recommended,
but technically is possible.
- Jared
We've actually seen atleast two backbones do this. Inconsistent
announcements at various exchanges gives it away. They typically did this
sort of thing when they acquired several companies, renumbered the
acquisition's AS, and hadn't yet connected the parts.
It is possible to use a single ASN to do this, without
meshing them.
4) You can not have any bgp downstreams and have this work
properly.
As long as the customer prefixes are announced from only one segment it
should work.
5) This would be a higly fragile environment, and is not recommended,
but technically is possible.
Also, any peer that is debugging routing problems might call about your
inconsistent route announcements. Consistent route announcements are a
condition of many peering agreements.
Mike.
- Jared
>
> I'm forwarding this off inet-access because there is a lot more BGP clue
> here. Anyone have any comments on the particular situation below, and/or
> regarding announcing different routes at multiple locations to multiple
> providers with single/many different ASNs?
>
> Thanks,
>
> -- Tim
>
> --------------------------------------------------
> * Timothy M. Wolfe, Chief Network Engineer *
> * ClipperNet Corporation / It's a wireless world *
> * tim@clipper.net 800.338.2629 x 402 *
> * Sufficient for today = Inadequate for tomorrow *
> --------------------------------------------------
>
> Date: Thu, 9 Dec 1999 12:58:46 -0800 (PST)
> From: Tim Wolfe <tim@clipper.net>
> Reply-To: list@inet-access.net
> To: list@inet-access.net
> Subject: Re: Portable IP space, isolated networks, BGP, etc...
>
>
> > From: "Troy Settle" <st@i-plus.net>
> > Subject: Portable IP space, isolated networks, BGP, etc...
> >
> > > I've been thrown into a situation where I've got 8 isolated networks
> > > connected to a variety of providers. Eventually, most of these will be
> > > connected with our own backbone. I need to find a way to make the
> > > transition as seemless as possible.
> > >
> > > First, it's my understanding that I can use a single ASN for the BGP
> > peering
> > > at each of these networks. Am I mistaken?
> >
> > Yes, this is a Big Mistake(tm). One would need a unique ASN for each site,
> > but they are only numbers, and the cost is like $500 each. Think about
> > the implications of two different sites, fed by the same provider, both
> > using the same ASN. Not a pretty picture. BGP hell.
>
> Could you please clarify what exactly the problem with doing this is? Many
> huge providers have multiple peering points that exchange routes using the
> same ASN for their peering routers don't they?
>
> -- Tim
>
> --------------------------------------------------
> * Timothy M. Wolfe, Chief Network Engineer *
> * ClipperNet Corporation / It's a wireless world *
> * tim@clipper.net 800.338.2629 x 402 *
> * Sufficient for today = Inadequate for tomorrow *
> --------------------------------------------------
>
> -
> Send 'unsubscribe' in the body to 'list-request@inet-access.net' to leave.
> Eat sushi frequently. inet@inet-access.net is the human contact address.
>--
Jared Mauch | pgp key available via finger from jared@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
END OF LINE |
+------------------- H U R R I C A N E - E L E C T R I C -------------------+