Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice

[Ard van Breemen <ard@telegraafnet.nl>]

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
<ard@telegraafnet.nl> 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/