I have transit in 2 cities. I have a circuit connecting the 2 cities as
well. So far I've been using non-contiguous IPs, so there's been no
opportunity for aggregation. Having just received my /20 from ARIN, I'm
trying to plan my network. Lets say I split the /20 into 2 /21's, one for
each city. I'd like to announce the aggregate /20 instead of 2 /21's, as
long as the circuit connecting the 2 cities is working. If the circuit
goes down I want each city to announce the local /21. Is this
possible? (using either a Cisco router or Zebra)
Ralph Doncaster
principal, IStop.com
div. of Doncaster Consulting Inc.
If I was paying for transit, I would want THEM to do the work of
delivering it to the right city, without wasting the bandwidth of my
circuit (unless they're really close and that circuit is really cheap).
If you're using the same transit provider in both cities, how about
announcing the /20, and the 2 /21s tagged with no-export. The /20 would be
heard by the world and get the traffic to your transit provider, then the
/21s would route it to the right exit point.
Date: Sat, 11 May 2002 17:34:39 -0400 (EDT)
From: Ralph Doncaster
I have transit in 2 cities. I have a circuit connecting the
2 cities as well. So far I've been using non-contiguous IPs,
so there's been no opportunity for aggregation. Having just
received my /20 from ARIN, I'm trying to plan my network.
Lets say I split the /20 into 2 /21's, one for each city.
I'd like to announce the aggregate /20 instead of 2 /21's, as
long as the circuit connecting the 2 cities is working. If
the circuit goes down I want each city to announce the local
/21. Is this possible? (using either a Cisco router or
Zebra)
* BGP is an EGP, not an IGP
* You might want to check out OSPF if you think your net will
grow
* You don't want your IGP influencing your EGP. Flap, flap.
* Redistributing EGP into IGP isn't exactly good, either.
Are the upstreams the same in each city? Why not announce the
aggregate /20 normally, and set NO_REDISTRIBUTE and use MEDs on
the /21s? You're paying for transit, so MEDs are fair game.
* BGP is an EGP, not an IGP
* You might want to check out OSPF if you think your net will
grow
Using iBGP between the 2 cities right now. May try OSPF later.
* You don't want your IGP influencing your EGP. Flap, flap.
* Redistributing EGP into IGP isn't exactly good, either.
Are the upstreams the same in each city? Why not announce the
aggregate /20 normally, and set NO_REDISTRIBUTE and use MEDs on
the /21s? You're paying for transit, so MEDs are fair game.
Well, the assumption is that most of the time the circuit between the 2
cities will be up, so flapping should be rare. The transit is from
different providers, so only announcing the /20 won't do the trick.
> goes down I want each city to announce the local /21. Is this
> possible? (using either a Cisco router or Zebra)
If I was paying for transit, I would want THEM to do the work of
delivering it to the right city, without wasting the bandwidth of my
circuit (unless they're really close and that circuit is really cheap).
It's 2 different providers, and one is much cheaper than the
other. Therefore I want all traffic to come in through city A, unless my
circuit to city B is down.
Don't forget that if both sites use the same as even if the connection
link drops they will not be able to see each other over the upstream
provider as routers won't take the srutes from the same as. If this
isn't a problem don't worry about it. If you wish to preserve
connectivity between cities you should have a back-up link or use
different as's or gre tunnels:).
Interesting point there Scott.. we were discussing just that at a recent
IXP meeting I was at. Theres a number of different ways (well hacks) in
which you can keep connectivity between two halves of an AS network in the
event of a split.
Is anyone out there actually doing something either this or similar to
keep two halves connected in the event of a split.. and have you actually
run successfully on your backup and maintained a reasonable throughput
(say 30 or 40Mbs) ? I'd be interested if anyone has a proven technique as
I want to implement something myself and dont really want to test it by
pulling the plug on some backbone links and waiting to see what happens!
Floating statics would be a less-hassle means to continue connectivity
(with only 2 locations not much of a scaling issue). Or, if you want, a
default route (learned via BGP if possible) going to your upstream(s). An
IBGP session sharing full routing information might not be something you
want to keep established over a GRE tunnel.
Actually I ran this way for a while as a primary. I had three sites
attached via cogent entirely all announcing a /19 and the internally a
/21 each and a couple /21's out of the primary location. In the main
location was a 7507 and in the two other pops 6509's. We set ospf
internally, set up bgp for the announcements at each site and used the
no-export tag for the more specifics. Then gre tunnels:) for the
internal. It worked and I pushed probably 45 to 50mb over the internal
loops or gre tunnels. Not ideal but it worked.
Date: Sun, 12 May 2002 21:07:50 +0100 (BST)
From: Stephen J. Wilcox
Is anyone out there actually doing something either this or
similar to keep two halves connected in the event of a
split.. and have you actually run successfully on your
backup and maintained a reasonable throughput (say 30 or
40Mbs) ? I'd be interested if anyone has a proven technique
Anyone know more than myself about InterNAP who can disclose
details?
> isn't a problem don't worry about it. If you wish to preserve
> connectivity between cities you should have a back-up link or use
> different as's or gre tunnels:).
Floating statics would be a less-hassle means to continue connectivity
(with only 2 locations not much of a scaling issue). Or, if you want, a
default route (learned via BGP if possible) going to your upstream(s). An
IBGP session sharing full routing information might not be something you
want to keep established over a GRE tunnel.
Hmm... the default route idea sounds even easier than my iBGP over a
transit link. I think I'll try your idea first.
Date: Sun, 12 May 2002 22:57:42 -0400 (EDT)
From: Ralph Doncaster
Hmm... the default route idea sounds even easier than my iBGP
over a transit link. I think I'll try your idea first.
Assuming your upstream knows how to get to the other location.
You want city "A" with upstream "X" to send all inter-AS traffic
while your pipe to "X" is up. When it fails, you want location
"A" traffic to go over your internal link to location "B", which
uses upstream "Y".
If your inter-city link fails, "B" should use "Y" for all
inter-AS traffic, and you _somehow_ need "A" and "B" to
communicate.
As long as this is getting messy... I'm tempted to suggest
confederations. Or spending a few extra bucks on a second ASN,
although that doesn't scale.
My answer isn't even to close to your reasonable throughput as the example
is only T1 connected, but I have a site which we are only connected to via
a non-igp path. Everything is via the internet (well sprint.net usually).
We're announcing a /18 to sprint at our main site, and a /23 at the
"disconnected" site. The "disconnected" site points default at sprint,
and doesn't take a full routing table. Basically we have BGP up at the
disconnected site just to announce the /23 with our AS.
With some creative use of cisco routing tools including OSPF, GRE tunnels,
and some creative static routing we maintain decent connectivity between
the two sites. It works quite well. In fact, it works well enough that
we're starting to buy circuits at each of our POPs as it is cheaper to buy
circuits from sprint or similar to their internet PoPs than it is to buy
circuits around the state. In most cases we will still be maintaining
internal connectivity for backup and latency reasons.
Multiple ASNs wouldn't solve anything in this case. What was wanted was
under normal circumstances both A and B only announce a /20, and when the
link between A and B breaks announce more specifics. Multiple ASN =
inconsistent AS.. no no.
Not necessarily. If 'A' originates the aggregate route it can still be
transited via 'B', though with an additional AS hop. Not a perfect solution,
but then neither is running a gre tunnel.