Ohh, now I see where you're coming from. You mean the additional blackhole routes you need to add on every box that need to mimic the 'non-arp parlance' or the 'do not choose this address for reply', right?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.
I understand everything but the last sentence. You have a couple of redundant ISP links which can all act as a router to the Internet, the only difference is that if you go over some of them you need less hops. Now in order to avoid asymmetric routing you need the hidden patch? I apologise for being so narrow minded but I still don't get it.??? 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.
Only if you change your rules once every 1000 packets maybe but other than that I doubt there is a significant overhead to the hidden patch. I would denote the overhead as being something in the range of O(log N), with N being the amount of routes. The way I understand the source address selection algorithm efficiency for routing decision is that you look up the fast routing cache and if there is no hit you try to find the preferred route by walking the tree-like structure of rules and their according routes. Of course you have a worst case bounce table walking if every rule matches but no route in the according table can be selected (this would be a pretty stupid setup to begin with). This would mean a complete walk through all routing tables until you have a preferred match. In this case it is 0(N) but after that it is in the routing cache and therefore O(1) again :).More rules, more overhead, having to set up a rule per IP (which can beEither 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.Source routing takes too much overhead for lots of connections, and as I
dynamic) takes overhead.
Please anyone correct me if I'm wrong.
I actually meant that the patch didn't do this in another way, but youThe 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.recall is limited to 256 rules. I'm not sure the hidden interface patch really does this, although I just looked quickly.
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.
That is something I certainly agree with you.
You're right. After rereading my email I think I owe the original poster my apology for those rather harsh words. He even cc'd Julian who is the author and maintainer of those patches.I thought this thread had a "please don't post patches like that we don'tthe 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.
want it in the kernel" early on in the thread, but I've expired the
message and lack time to dig archives.
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
