From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julian Anastasov Date: Fri, 05 Jul 2002 20:31:26 +0000 Subject: Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Hello, On Fri, 5 Jul 2002, Ard van Breemen wrote: > I am using this to differentiate between known routing, and > default routing. Or more correctly, to specify the path between each two subnets, the more specific rules and routes before the others. > # (The append is needed because else the routes will clash) > # So we have a table with two default routes wich will failover > # for eachother (takes about 10 minutes in default config) You can add note about tuning this timeout with gc_interval, gc_timeout and friends. > So what is the catch: > The only catch is that if you do not have point-to-point > connections with your provider, but a /24 for example, then > requests coming in from provider2 for the ip-eth1, will go out > from your eth2 and not from your eth1. This might be a problem if > your /24 is filtered by your ISP. This should be covered from sharing /24 subnet with the provider - the link-local networks. The most usual setups are: 1. shared /30 => routes via peer gateway 2. shared pubnet, ISP/we have one IP from pubnet => link-local routes, gateway is onlink The 2nd case can be split again in 2 cases according to the pubnet owner (ISP has the pubnet or the pubnet is yours). I.e. this explains where is the subnet, on internal or on external interface. Other alternatives? > Last thing: this failover thingie can also be a "loadbalanced" > thingie as explained in "4.2.2 Load balancing". > However: due to bugs in the equalizeing code, I recommend against Yes, equalize does not work if the ISPs filter by src. This flag is simply not in the kernel, only in user space. > it. Somewhere inside the kernel it cannot clearly come up with a > route, which results in a lot of "cannot happen 777". Fixed in 2.4.19pre8, SMP race. > Next to that: the usage counts of the devices are not correctly > incremented and decremented. You have to be very careful and craft > an extra non-multipath route before, then remove the existing > multi-path route, before bringing down a network device. Else it > ends up in an endless "device still in use, waiting". And you > will not be able to use the device anymore until you reset some > sense into the machine... This snafu is also fixed in 2.4.19pre8, it is even killed: the multipath route is deleted due to SMP locking problems. Regards -- Julian Anastasov _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/