LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

iBGP? [Re: Route through rather than connect to possible?]

To: "Horms" <horms@xxxxxxxxxxxx>, <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: iBGP? [Re: Route through rather than connect to possible?]
From: "Ted Pavlic" <tpavlic@xxxxxxxxxxx>
Date: Thu, 21 Sep 2000 16:29:11 -0400
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
>
>
>
>



<Prev in Thread] Current Thread [Next in Thread>