|
|
On 10/5/05, James Yonan <jim@xxxxxxxxx> wrote:
> On Wed, 5 Oct 2005, Erich Titl wrote:
>
> > James
> >
> > James Yonan wrote:
> > > On Mon, 3 Oct 2005, Jason Keltz wrote:
> > ....
> > >
> > >
> > > I think it would be a worthwhile feature to have a native clustering
> > > capability in OpenVPN.
> > >
> > > While the basic load balancing and failover capability provided by putting
> > > multiple "remote" directives on the client is almost a clustering
> > > solution, it falls a bit short when you want (for example) a client to
> > > keep the same IP address even when connecting to a different server, or
> > > when clients are serving as a VPN gateway for a local, private LAN.
> > >
> > > To make this work, we need a dynamic routing capability so that when a
> > > user with a given VPN IP address ('IP') connects from server 'A'
> > > to server 'B', the server-side routers will be aware that return packets
> > > to IP must now be routed through server 'B' rather than server 'A'.
> > >
> > > One way to make this work would be to use a dynamic routing protocol such
> > > as RIP2 or OSPF. When the user connects to server 'B', a RIP2 message
> > > would be multicast, telling all the local routers of the new gateway for
> > > 'IP'.
> > >
> > > This would require adding some code to OpenVPN to advertise its internal
> > > routing table to local, neighboring routers using RIP2 or OSPF.
> >
> > But would it solve the seamless handover scenario? I doubt it. Basically
> > what would be needed are multiple paths to destination, advertised
> > dynamically as you pointed out.
> >
> > Right now load balancing relies on multiple remote entries which are
> > selected in a random fashion. What happens when the selected remote
> > fails during tunnel lifetime? OpenVPN will try to reconnect (after a
> > certain timeout) and might succeed finally. Will a TCP connection
> > survive such a switch in the underlying layer?
>
> It would survive if the switchover happened quickly enough. This would
> require a fast algorithm for determining when a remote goes down.
>
And require care to avoid flapping routes.
--
Leonard Isham, CISSP
Ostendo non ostento.
|