From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ard van Breemen Date: Mon, 08 Jul 2002 11:54:40 +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 On Fri, Jul 05, 2002 at 11:31:53PM +0000, Julian Anastasov wrote: > 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. Yes... I like. Although too complex for the users that do not know what we are talking about. > > # (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. Or refer to the page, ehhhh, oops... I remember Bert asking me to write one up :(... > > 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. Once again, I like it. This time it is also not complex. > Other alternatives? I think that covers everything: peer-to-peer, and subnets... Is there something else I did not know about? > > 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. Well, it *does* work in this framework: we only need the multipath code to select a route, and therefore a source ip. Once we got the source ip, we will not hit the multipath route anymore due to the rules... And even if we did, there is a good chance it is still cached :). > > 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. Cool! > > 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. Do you mean we cannot have multipaths anymore? Or that the fix was to remove the multipath route? -- begin ILOVEYOU.VBS 666 Telegraaf Elektronische Media Real geeks don't get viruses end _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/