[28772] in North American Network Operators' Group
"Simple" Multi-Homing ? (was Re: CIDR Report)
daemon@ATHENA.MIT.EDU (Todd Sandor)
Tue May 16 00:45:46 2000
Message-ID: <3920D5CB.7597CBE0@home.com>
Date: Tue, 16 May 2000 00:59:55 -0400
From: Todd Sandor <tsandor@home.com>
MIME-Version: 1.0
To: Rodney L Caston <largo@megatokyo.com>
Cc: Valdis.Kletnieks@vt.edu,
Chris Williams <chris.williams@third-rail.net>, nanog@merit.edu
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: owner-nanog-outgoing@merit.edu
Gee, just when I thought I got the required answers to my "simple" multi-homing questions
to/from
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
availability.
- 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
financially
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
intermittantly
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
alternatives?
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.
ThatsAll...
>
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 <391E3098.CB2C084@home.com>, Todd Sandor <tsandor@home.com> 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
<http://www.netaxs.com/~freedman/bgp.html>.
>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
>link.
>- 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
sufficient.
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)….
>
>Questions:
>
>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
>"http://www.arin.net/regserv.html" 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.
--
