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 cant co-locate our web service to an ISP/Hosting-Provider at the current time. - Our current provider, UUNET (were using T1 burstable service), has a single POP in our location (Ottawa, Ontario Canada). We dont 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. --