|
I haven't been keeping up on this particular thread, so I don't know if this
has already been brought up, but rather than waiting for BGP to timeout,
I've built a slightly different setup that still uses routing to route the
IPs directly to the LinuxDirector.
Both LinuxDirectors have their own unique IPs... for example...
192.168.16.1
192.168.16.2
But all the VIPs are actually routed to a third address:
192.168.16.3
And the active LinuxDirector simply brings up that IP as an alias. I have a
program (like heartbeat, but I wrote ages ago called etherbeat) which runs
on both directors and elects a master between them. Once that master is
elected, the slave brings down its alias, and the master brings up its
alias. The router's cache is cleared and traffic is routed through the
master director.
When the master director dies, after a timeout easily tweakable by me in
etherbeat, the slave is elected master, brings up the alias, and routing
goes on as it was.
Now I've only *THOUGHT* about using BGP or RIP to update the routing table
automatically, but this system works great for me. I actually got the idea
from a similar implementation in my telephone switch.
I don't know if this is better or worse... simpler or more difficult... but
I know it works as a routing solution -- so I offer it.
All the best --
Ted
----- Original Message -----
From: "Kyle Sparger" <ksparger@xxxxxxxxxxxxxxxxxxxx>
To: "Joseph Mack" <mack.joseph@xxxxxxx>
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, September 14, 2000 11:20 AM
Subject: Re: Route through rather than connect to possible?
> In my last email, I said, "it will be considered to be dead, and the known
> route to the IP address through that peer will be withdrawn."
>
> I should clarify that with BGP, once a route is withdrawn, the next best
> path to the destination is selected. In our scenario, there's another
> known path to the destination -- through the secondary director -- and so
> that path will be the next chosen path.
>
> > rewriting is slow and CPU intensive for the director. However you're
> > only rewriting in one direction unlike VS-NAT. However this may not be a
> > problem if there are other advantages.
>
> True. But, if you only rewrite the MAC address -- which you could get
> away with -- this should end up being not much more expensive than the
> current DR method.
>
>
>
>
> Kyle Sparger - Senior System Administrator
> Dialtone Internet - Extremely Fast Web Systems
> (954) 581-0097 - Voice (954) 581-7629 - Fax
> ksparger@xxxxxxxxxxxxxxxxxxxx
> http://www.dialtoneinternet.net
>
>
>
>
>
>
>
|
