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

[Julian Anastasov <ja@ssi.bg>]

	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 <ja@ssi.bg>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/