>Thank you for all the input. > >If our company applies for a block of class C IP >address, how can we won't have any down time on the >Web servers and SMTP servers when we switch current IP >addresses to the new class C IP address. After we >change the IP addresses in the DNS server, the change >will take up to 24 hours or even more. > >thank you
The only way to avoid downtime is not to switch all at once, but give the server dual addresses if they support them, or have the router respond to both address ranges and NAT to the current address. Typically, you want to do this for at least 5 days and often considerably more. Perhaps a week or two before the cutover, set the TTL in your DNS to minimum values, in order to encourage caches getting cleared of the old address. You will almost certainly have some partial downtime due to hosts that don't refresh their DNS in time. It will get much worse if any HTML applications, for example, use hard-code addresses. It's not a perfect world. Given these questions involve DNS, servers, and other things not on the lab, I suggest the discussion continue on the general list. I've copied both. > >--- "Howard C. Berkowitz" wrote: >> At 8:05 PM +0000 3/15/02, Brian Lodwick wrote: >> >We had a customer that was on our old old network. >> This network had >> >a different AS and addressing. This customer wanted >> to move to a >> >newer solution we offered, but wanted to keep the >> existing >> >addressing structure. This wasn't much an issue, >> because accoring to >> >our policy we were allowed to advertise any >> customer net above a >> >/24, and they had a /22. The old network advertised >> an aggregate so >> >this more specific range was preferred and the >> transition worked. >> >The reason I went into this whole schpeal is that >> like you said if >> >you get addressing space from one of the providers, >> and you get >> >approval to advertise that range out of the other >> provider as well, >> >you will have sort of a primary / secondary >> solution and will not be >> >able to achieve load sharing. >> >> Untrue. Now, both providers MUST agree to it. Let's >> say there is a >> /24 from provider A's space, which comes out of >> their /16. Provider >> B certainly can advertise the /24, although it >> wouldn't be done in >> usual practice without agreement with A. >> >> Now, the subtle point. Once provider A agrees to let >> provider B >> advertise the more-specific, provider A _must_ >> advertise both the /16 >> _and_ a /24 for each multihomed customer. >> Otherwise, as you suggest, >> all traffic would take the more-specific advertised >> by provider B. >> >> >Reason being is the provider you get your >> addressing space from will >> >most likely be advertising to the NAP an aggregate >> so the other one >> >that allows you to advertise the /24 will always be >> preferred over >> >the aggregate. If redundancy is the only >> requirement you would be >> >fine if you had one provider give you addressing >> space and you >> >advertised it out of the other provider as well. >> >I wasn't aware you couldn't purchase a /24 from >> ARIN. I'm not really >> >too knowledgeable on that type of thing. I only cut >> addressing space >> >from our nets when needed for our customers. I have >> never gone out >> >and tried to purchase addressing space from ARIN. >> >> "Purchase" really isn't the right word. Allocation >> is the correct >> term for handing out provider-independent address >> space. ARIN, RIPE >> NCC, and APNIC won't just hand out space to anyone >> that brings them >> money; they will need to see a justification and >> will review your >> efficient utilization if you ask for more. >> >> You can multihome to multiple POPs of the same >> provider, with >> provider-assigned address space. See RFC 1998. You >> can even do this >> with PI space and a private ASN, although it's sort >> of a kludge. See >> RFC 2270. >> >> There are also engineered solutions where two >> providers originate the > > same prefix, which is technically an "inconsistent >> AS" but is not >> uncommon and doesn't really create problems. >> >> The address registries also make no guarantees if >> your address space >> will be globally routable. There is a trend to >> reduce the number of >> prefix length filters, but that also means the >> current routing >> architecture will run out of steam in 4-8 years. >> I'm involved in the >> Internet Research Task Force effort that's just >> starting to look at >> "what comes after the BGP architecture." >> >> > >> >BTW I have a neat HSRP & BGP redundancy solution to >> fix the downfall >> >of using this combination if you'd like to hear >> about it? >> > >> > >> >>From: Vincent Lee >> >>Reply-To: Vincent Lee >> >>To: Brian Lodwick , >> [EMAIL PROTECTED] >> >>CC: [EMAIL PROTECTED] >> >>Subject: RE: OT: Change primary ISP from PacBell >> to Quest >> >>Date: Fri, 15 Mar 2002 11:09:07 -0800 (PST) >> >> >> >>Where can we apply for a class C IP address? ARIN >> >>only sell a larger block IP address. I believe if >> we >> >>want multihomed with different ISPs (AS), we need >> to >> >>setup BGP with both ISPs as peering. >> >> ARIN and the other registries will generally >> allocate /24 if you can >> show them contracts with two upstream providers, at >> least 50% >> utilization of your current address space, and >> various other >> justifications. >> >> You will probably need an AS number as well for >> general-case >> multihoming. There are requirements there. RIPE NCC, >> for example, >> requires that you write out your routing policy in >> RPSL and put it in >> the routing registry; this is optional but >> recommended for ARIN. >> >> Note that the address and routing data bases are > > separate. >> -- "What Problem are you trying to solve?" ***send Cisco questions to the list, so all can benefit -- not directly to me*** ******************************************************************************** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com "retired" Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38511&t=38511 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
