|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical "Simple" Multi-Homing ? (was Re: CIDR Report)
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 <[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 <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. --
|