lkml.org 
[lkml]   [2002]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: hidden interface (ARP) 2.4.20
On Tue, 10 Dec 2002, Roberto Nibali wrote:

> Maybe I should first note that I am not against the hidden patch at all,
> I just accepted that it won't go in. I use it on an almost daily basis.
>
> > In spite of vast resistance from some developers, it is highly desirable
> > on some systems to force a packet with a given source IP out an interface
> > which has that IP assigned. With this capability it is possible to make a
>
> Yes, source address selection based on different rules and routing
> tables. What does it have to do with the hidden patch?

I see it as an alternative solution to the problem the hidden patch is
addressing. Perhaps a more general one, although the method of causing
such routing might not be source routing in the "ip" sense.

> > usual proxy_arp fix doesn't really address these cases. If I have multiple
> > default routes, the router on which the packet arrived is likely to be on
> > the route with the fewest hops, randomly using another route doesn't help.
>
> ??? Depends how you use those multiple default routes. If you do nexthop
> routing you do sort of RR balancing on preferred routes. If you do
> source address selection routing based on rules you have fixed default
> routes which will not match because of the fewest hops but because of
> the rule. I am a bit confused as to what you're trying to tell me.

I have in mid multiple ISPs for redundancy, perhaps a pair of OC12s or
similar. Sites would be reachable from either, but fewer hops to one or
the other. When the client connects, it avoids asymmetric routing to reply
on the same router.

> > Source routing takes too much overhead for lots of connections, and as I
>
> Either we have a different view of source routing or I have to ask you
> why you think there is too much overhead with source routing.

More rules, more overhead, having to set up a rule per IP (which can be
dynamic) takes overhead.

> > recall is limited to 256 rules. I'm not sure the hidden interface patch
> > really does this, although I just looked quickly.
>
> The hidden patch doesn't do source routing and the limit of available
> source routes is 254 but not because of the rules (you can have 2**16
> rule entries) but because of the amount of routing tables which is 256
> [0..255] minus local table minus main table which equals to 254 tables.

I actually meant that the patch didn't do this in another way, but you
have noted that the number of routing tables is limited. That may or may
not be a limitation depending on complexity. In any case a single
use-configured-interface patch avoids having tables.

> > Patches like the hidden interface will continue as long as there are
> > useful things people want to do with Linux and can't. It's one of many in
>
> Yes, that's the nice thing about patches, isn't it :).
>
> > the networking area. I don't expect them to be adopted in the main kernel,
> > but as long as they're easier than making multiple configs, particularly
> > at runtime, they will be around.
>
> Yes, definitely. And I think noone has said anything against that.

I thought this thread had a "please don't post patches like that we don't
want it in the kernel" early on in the thread, but I've expired the
message and lack time to dig archives.

--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.079 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site