North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

"Simple" Multi-Homing ? (was Re: CIDR Report)

  • From: Todd Sandor
  • Date: Tue May 16 00:46:36 2000

Gee, just when I thought I got the required answers to my "simple" multi-homing questions
the comp.protocols.tcp-ip News group, I started seeing these Nanog threads related to
multi-homing, now
I'm not so sure its "simple", or even if a "Simple" multi-homing to > 1 provider is
possible?....[I've pasted the News
posting below].

Our requirements are:
- we needs link redundancy (a single location) – our web service requires 24 x 7
- We can’t co-locate our web service to an ISP/Hosting-Provider at the current time.
- Our current provider, UUNET (we’re using T1 burstable service), has a single POP in
our location (Ottawa, Ontario Canada).  We don’t want 2 links to the same provider (POP), or
do we?
- As far as I know there is only one provider in this area that has > 1 POP. [its not
prudent for us to drop UUNET and go with them – read … we have a “contract”].
- We have been allocated a /24 from UUNET.

BTW: Since last Thursday afternoon, we've been having T1 link flaky-ness and have been
up and down (mostly down).  We replaced our router [it was delivered to the guy in charge of
our network
on Saturday night - sort-a link a pizza delivery - One router please, with a T1 for extra
topping...:-)] and the
T1 card and some cabling - the finger point is still fricken going on.....So please don't try
to tell me that us
small /24 guys don't need link redundancy and multi-homing....we do...

I basically need to be educated and told whether the configuration described below will
work.  Based upon these
Nanog threads, I'm concerned that when our primary link goes down, our IP /24 address block
will not be globably
routeable via our backup link/ISP since some ISPs filter /24s out?  Comments?  What are the

In summary, the configuration we "were" considering:
- use only default routing.
- we need to get our own ASN.
- primary T1 link will  uses local-preferece so all outgoing traffic will use this link.
- backup T1 will use AS_Path manipulation to insert bogus AS entries to pad-out the AS length

so incoming should prefer the primary T1.



Below is the response I got from a "comp.protocols.tcp-ip" news group query, the ">" are
my original questions, the other info. is from a person who responded to my questions....

In article <[email protected]>, Todd Sandor  <[email protected]> wrote:
>Hi, I need some assistance/direction in trying to determine what I need
>to do in order to multi-home to different providers.
>It sounds simple enough …please provide help/hints/references.   Cheers…
>I think the bottom line question is how to I reliably multi-home to
>multiple (2 in this case) providers without a PI (provider-independent
>IP address) and without an ASN?  Maybe someone can direct me to a
>document that described

If you're going to run BGP, you need an ASN, but you don't need PI
addresses.  You can advertise your UUNET-assigned address block to your
backup provider.  As long as you tell UUNET to export it as well, you
should be fine.

For a good description of how to configure multi-homing with BGP, see

>I've done some reading about BGP (e.g. Bassam Halabi's "Internet Routing
>Architectures"), but have no "hands on"
>experience.  What I would like to be able to do is run BGP to each
>provider and use one link as a primary link and the
>second link as a backup.  I think I would need to:
>- Use default routing [dynamically learn 0/0 from both providers]. I
>would use the BGP attribute "local" preference (or
>Cisco's weight parameter) to affect outgoing traffic to use the primary
>- Would use AS_Path manipulation to insert bogus AS entries into the
>AS_path attribute on the backup link to influence
>inbound traffic [from what I understand this need to be done all the way
>up to the NAP -- will my providers help me with
>this (tell me the # of bogus entries I'll need to add?)].

If your primary ISP is a tier-1 like UUNET, 1-2 levels of padding should be

You may also need to send a community to your backup provider, if you don't
want them using that connection for traffic from their own customers.  This
is because some providers use local-pref to prefer direct customer links
over peering links.

>- Would filter inbound routes to only accept 0/0.  Filter outbound to
>only send our address block.

You should be able to ask the providers to only send you default routes.

>- We currently have a Cisco 2610 -- is this sufficient? Is there a
>particular IOS release we should run?

For default routes, this should be fine.  Any recent IOS should be OK.

>- We have been allocated a /24 from UUNET.   We are probably not going
>to be able to justify a /20 from Arin in
>order to get PI (provider independent) IP address space.  I believe
>we'll need to use an IP address from UUNET
>or the future "other" provider.

Few organizations other than ISPs can justify /20's and larger.

>- It may be difficult to get an ASN (see question #1)….
>1) The Arin ASN request information requires verification that you are a
>multi-homed site -- if your just planning be
>become multi-homed will Arin still give you a ASN?

They want you to provide contact information for both providers.  Once you
purchase the service from the second provider, you'll be multi-homed and
they'll give you the ASN.  Until then, you don't need it.

>2) If we were to use a private ASN,  both providers would need to strip
>this  off [our IP addresses would seem to
>be part of each providers AS], then the same IP address block (say our
>/24) would have different ORIGIN
>attributes -- other then being "illegal" would this cause routing
>in-stabilities?  Do some provider allow this?

You shouldn't do this.

>3) What are some of the reasons why Arin at page
>""; specifies "Provider-independent
>(portable) addresses obtained directly from ARIN are the least likely to
>be globally Routable".

Some ISPs filter out advertisements smaller than /19.  So even though ARIN
will assign /20's, they may not be seen by everyone.