Howard,
 
     Would you provide me more details about the cutover info or point
me
to those sources?  We have Cisco LDIR 416, I think I should config the
border routers and LDIRs to accept both new and old IP addresses.

Thanks a lot

After my own search and all of your help, I come up a more complete plan
to
Switch primary ISP from PacBell to Qwest.

Here is my new plan:

Using Border Gateway Protocol (BGP), our own Autonomous System (AS) 
and ISP independent Class C IP Addresses.

Benefits: 
.       True redundancy to multi-home connect to two different ISP
providers,      both of these connections are active at the same time
(not backup).   Any one provider may have huge problems at any time.
.       Load Sharing with BGP. (not load balancing)
.       A lot easier to change from one ISP to another ISP in the
future.
.       Lower tariffs at particular times of the day or night.
.       Scalable and Stable.

Requirement:
.       Apply for our own ASN Autonomous System (AS) Number from
American        Registry fro Internet Numbers. (RFC 1930)
        $500 setup fee and $30 annual fee.
.       Apply for our own blocks of IP addresses (Class C) from Internet

        Register Authorize IETF. 
        $2500 setup fee and $30 annual maintenance fee.
.       Register Maintainer Object, AS Object and Route Object with RADB

        $250 annual fee.
.       Configure BGP protocol on both Border 7204 routers.
.       BGP Peering with Qwest and PacBell, according to their BGP
Peering 
        Policies.
.       Change Web Servers and SMTP Servers to our own block of IP
addresses.      (Have the routers respond to both old and new addresses
ranges and NAT 
        to the current address, no down time when cutover.)

Optional 
.       Change the Primary or secondary DNS from PacBell to Qwest.



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Howard C. Berkowitz
Sent: Friday, March 15, 2002 6:04 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: OT: Change primary ISP from PacBell to Quest

>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
_________________________________________________________________
Commercial lab list: http://www.groupstudy.com/list/commercial.html
Please discuss commercial lab solutions on this list.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=38589&t=38589
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to