On Sun, 11 Jun 2006, Andrew Warfield wrote:
> > I think there is some cisco magic you could do with 'dial backup'... you
> > may even be able to rig this up with an ibgp session (even if that goes
> > out over the external provider) to swing the routes.
> >
> > NOTE: this could make your site os
AW> Date: Sun, 11 Jun 2006 20:55:42 -0700
AW> From: Andrew Warfield
AW> I'd love a multi-ISP solution. I just assumed that anything involving
AW> more than a single upstream AS across the two links would leave me
AW> having to consider BGP convergence instead of just IGP reconfig. I
AW> didn't
> > i intended to be present for the Q&A after joao's DLV talk but
> > i was told that being there without having registered was rude.
>
> you were attending nanog without registering and paying? that is
> rude. have you offered to pay retroactively? that would be the
> honorable thing to do.
I think there is some cisco magic you could do with 'dial backup'... you
may even be able to rig this up with an ibgp session (even if that goes
out over the external provider) to swing the routes.
NOTE: this could make your site oscillate if there are connectivity issues
between the sites, it
> 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?
Absolutely. We are trying to explore
Date: Sun, 11 Jun 2006 19:34:12 -0700 (PDT)
From: [EMAIL PROTECTED]
[A] somewhat cleaner way to do this would be to advertize a less
specific route from the DR location covering the more specific route
of the primary location. If the primary route is withdrawn, voila ..
traffic starts moving
On Sun, 11 Jun 2006, Randy Bush wrote:
>
> > 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
RB> Date: Sun, 11 Jun 2006 17:02:14 -1000
RB> From: Randy Bush
RB> persistent tcp connections from clients would not fare well unless
RB> you actually did the hacks to migrate the sessions, i.e. tcp serial
RB> numbers and all the rest of the tcp state. hard to do.
Actually, the TCP goo isn't to
> a somewhat cleaner way to do this would be to advertize a less specific
> route from the DR location covering the more specific route of the primary
> location. If the primary route is withdrawn, voila .. traffic starts
> moving to the less specific route automatically without you having to
> s
> 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
You dont say who the "clients" are - I presume this is a web based application so essentially you are trying to migrate service in flight to another set of servers within the TCP/HTTP session timeout without the client missing a beat ?If another kind of client, does it also have auto reconnect/retr
I've got a bit of a network reconfiguration question that I'm
wondering if anyone on NANOG might be able to provide a bit of advice
on:
I'm working on a project to provide failover of entire cluster-based
(and so multi-host) applications to a geographically distinct backup
site. The general ide
On Sun, Jun 11, 2006 at 06:50:05AM +, Paul Vixie wrote:
>
> i intended to be present for the Q&A after joao's DLV talk but i was told
> that being there without having registered was rude.
you were attending nanog without registering and paying? that is
rude. have you offered to pay retr
my question was a bit simpler. what is the security policy
that isc plans to use over the content of the isc dlv registry?
and how will the dvl trust key roll-over and revocation be
handled?
as providing a tld key registry is tantamount to emulating the
root key responsibilities of the iana, pot
14 matches
Mail list logo
