|
Another idea...
Rather than using RIP or OSPF, BGP can be configured to be an IGP.
It would be nice to use BGP because BGP keeps a session open. I'm FAIRLY
sure that BGP can be configured to IMMEDIATELY once a session dies start
routing to the open session.
Just a thought.
----- Original Message -----
From: "Ted Pavlic" <tpavlic@xxxxxxxxxxx>
To: "Horms" <horms@xxxxxxxxxxxx>; <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Monday, September 18, 2000 8:49 PM
Subject: Re: Route through rather than connect to possible?
> Abstract:
>
> I'm going to favor RIP and say why, then I'm going to favor OSPF and say
> why... :) Then I'm going to summarize.
>
> > To my mind the idea of using a routing protocol would be best if a
routing
> > protocol is already used on the network. After all if you are using
fwmark
> > to manage CIDR networks that are routed to a Linux Director managing the
> > path that this traffic takes really is a routing problem and it would
make
> > sense to make use of any existing routing infrastructure. Though would
be
> > thinking more in terms of an IGP such as OSPF rather than an EGP such as
> > BGP, though this is really an implementation issue.
>
> I agree completely -- it makes sense to use an existing routing protocol.
I
> also agree withat using an IGP rather than an EGP would be better, which
is
> why I originally suggested RIP rather than BGP. Routing CIDR networks
could
> be done with RIP2. (RIP1 doesn't support CIDR) The only reason I suggested
> RIP over OSPF was just because it is very simple to setup and might be
more
> appropriate for LVS as OSPF is more for larger networks that need a lot
more
> organization than two LVSs and a few IPs.
>
> Like RFC1723 says:
> =====
> With the advent of OSPF and IS-IS, there are those who believe that
> RIP is obsolete. While it is true that the newer IGP routing
> protocols are far superior to RIP, RIP does have some advantages.
> Primarily, in a small network, RIP has very little overhead in terms
> of bandwidth used and configuration and management time. RIP is also
> very easy to implement, especially in relation to the newer IGPs.
> =====
>
> And personally, I'd be afraid of having to deal with managing OSPF for LVS
> clusters combined with internal OSPF on a network. I'm not sure how much
I'd
> want advertised where... so I'd have to filter certain things off.
>
> HOWEVER... the timeout issue....
>
> > The question that I have is - and this shows where my knowledge of
routing
> > protocols runs out - what is the relative cost of waiting for various
> > routing protocols to converts as opposed to using a fail-over mechanism
> such
> > as heartbeat or your etherbeat?
>
> Having a heartbeat-like system is nice because you can tweak the failover
> timeouts and sensitivity.
>
> It takes 180 seconds for RIP2 to expire a route (unless the particular
> router sending the updates sets its metric to 16, but in a failover
> situation this probably won't happen). This has always been one of the
> downsides of rip -- slow convergence.
>
> OSPF2 allows more flexibility which might actually make it a good
> replacement for heartbeat. Adjusting these configuration items:
>
>
> HelloInterval
> The length of time, in seconds, between the Hello packets that the
> router sends on the interface. Advertised in Hello packets sent
> out this interface.
>
> RouterDeadInterval
> The number of seconds before the router's neighbors will declare
> it down, when they stop hearing the router's Hello Packets.
> Advertised in Hello packets sent out this interface.
>
> Hello Timer
> An interval timer that causes the interface to send a Hello
> packet. This timer fires every HelloInterval seconds. Note that
> on non-broadcast networks a separate Hello packet is sent to each
> qualified neighbor.
>
>
> Might allow for OSPF to update quick enough. On a small network, OSPF
> wouldn't send a great deal of information with each advertisement. Plus,
> OSPF adds an extra layer of security.
>
> So basically...
>
> *) Things work the way they are currently setup... hacked as it might be.
>
> *) Changing to an IGP might allow for more than two LinuxDirectors and
would
> use an existing dynamic routing protocol to do ... well ... dynamic
routing.
> :)
>
> *) RIP is very simple and would be very easy to setup... but it would take
> 180 seconds for a failover.
>
> *) OSPF is more complex -- perhaps a little too complex for something so
> simple as this -- but it has a great deal of flexibility.
>
> Now what do you think about all of this? Do you think that RIP2/OSPF2
could
> be useful for LVS? Would we gain a great deal over our current methods of
> failovers?
>
> ANOTHER THING -- Weren't we at one time talking about using something like
> heartbeat to advertise persistence information so that when one LVS died,
> the one that took over would continue routing exactly the same way causing
> virtually no donwtime for anyone? Using an IGP to handle these sort of
> failovers wouldn't share this information... However -- back in the day
when
> we were talking about this I said that using an IGP as a *MODEL* for such
an
> advertisement protocol might be a decent idea. For example, we could send
> advertisments like OSPF's LSA's and even offer authentication like OSPF.
We
> could use broadcast or multicasts to send this information... etc...
>
> And perhaps this LVS-IGP could advertise this info as well as typical IGP
> info so that routers surrounding LVS would still route correctly; the
LVS's
> would be the only ones that cared about the other information.
>
> Of course that's quite a project.
>
> I hope that inspires some imagination.
>
> All the best --
> Ted
>
>
>
>
|
