North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: IP failover/migration question.

  • From: Randy Bush
  • Date: Sun Jun 11 23:02:37 2006

> I'm trying to get a more clear understanding as to what is involved in
> terms of moving the IPs, and how fast it can potentially be done.

can we presume that separate ip spaces and changing dns, i.e. maybe
ten minutes at worst, is insufficiently fast?

> I'm fairly sure that what I would like to do is to arrange what is
> effectively dual-homing, but with two geographically distinct homes:

uh, that kinda inverts what we normally mean by 'multi-homing'.
that's usually two upstream providers for a single site.

> Assuming that I have an in-service primary site A, and an emergency
> backup site B, each with a distinct link into a common provider AS, I
> would configure B's link as redundant into the stub AS for A -- as if
> the link to B were the redundant link in a (traditional single-site)
> dual-homing setup.  

not clear what you mean by redundant.  as the common transit
provider will not do well with hearing the same ip space from two
sources, this type of hack might best be accomplished by B not
announcing the space until A goes off the air and stops announcing
it.  [ clever folk might try to automate this, but it would make me
nervous. ]

alternatively, you might arrange for the common transit provider to
statically route the ip space to A and swap to B on a phone call.
this would be very fast, but would require a very solid (and tested
monthly if you're paranoid, which i would be) pre-arrangement with
the provider.

i am sure others can come up with more clever hacks.  beware if
they're too clever.

> Assuming that everything works okay with the virtual machine
> migration, connections would continue as they were and clients
> would be unaware of the reconfiguration.

persistent tcp connections from clients would not fare well unless
you actually did the hacks to migrate the sessions, i.e. tcp serial
numbers and all the rest of the tcp state.  hard to do.

> I hope this is reasonably on-topic for the list.

well, you left of mention of us legislative follies and telco and
cable greed.  but maybe you can get away with a purely technical
question once if you promise not to do it again. :-)