Op zondag 24 oktober 2010 22:39:29 schreef Luca Berra: > On Sun, Oct 24, 2010 at 11:43:28AM +0200, Maarten Vanraes wrote: > >I would propose the following:
First off, the timing of this proposal is probably too soon, i just wanted to get it out there, in case i forgot later. > >A.) by default, add for every interface, a little advanced routing which > >makes packets return from the same way they came. > >This usually is only useful with incoming packets, but can still be useful > >if laptops have for example 2 gateways because the wifi is still on and > >the cable is too. That would mean that from both interfaces it'd be > >possible to use ssh or vnc or whatever. > > this is possible with incoming packets, but, how do you select the > source of a new one? this step is only for the replies of incoming packets and never has any effect on new outgoing packets; this step doesn't change anything for new outgoing packets. and this can even be used on interfaces that aren't used as default gateway. > >B.) if we have multiple gateways (like in that case), have them use both > >balancedly. ie: start a small daemon which checks which of the gateways is > >up or down; and change the default gateway accordingly, or even both in > >some kind of balanced mode. (with advanced routing.) > > This could go wrong in so many ways i would not even try: > i.e. how do you determine if a gateway is up? dont tell me icmp, many > firewall refuse it, and vrrp standard says the backup gateway should not > answer icmp echo. there are alot of different aspects to what we consider as a "working" isp connection. this isn't about having perfection; it's about improving what we have now. Consider a laptop user; the user has a network connection and also has his wifi up. You will notice that there are in fact 2 default gateways (possibly with different metric, but we cannot be sure). what i propose is to use both together balanced by default. this in itself is an improvement; the parts about detection of "up" or "down" (except the interface itself) are extras, after all, the same issues can even happen with one gateway. Balancing is even more usefull if there are ways of automatically detecting which interfaces are unwanted for routing. (TBH you assumed icmp is what would be used; we all know icmp can be blocked and is never relied on..) possible problems: A) interface down B) DHCP expired C) gateway down D) further routing down E) DNS down A is trivial, so we'll just skip that one. B seems easy to do too; however, reusing the last DHCP lease could still be usefull, it might well be only a dhcp failure; we should try with the current lease if possible. E is a bit of an extra (it's not really routing, but a DNS that's down (does not answer) could well be eliminated (not sure if this should be done separately or not)) OTOH, failure of the recursive DNS of the ISP seems to be somewhat frequent in my experience. C+D are tricky: D is even a bit of a grey area; my ISP frequently has a few routes broken. icmp can definately not be relied on in all cases. and even if you ping your gateway, you don't know if it goes any further. This could be circumvented by putting known servers that actually echo icmp in a list and ping those. but for that matter, it doesn't have to be icmp; we could easily have a list of public services that can be connected to. but is this really what we want? We could even just monitor how much packets are unreplied to per interface and choose that. Or we could try to have each retry of unreplied packet go through the next default route. Or we could just not handle that (like it is now). remember that right now only A(+B) is used; and having balanced default routes would probably mean that there is 50% packet loss, instead of 100% in most cases. also remember that if the metrics are the same for some reason, you will get much stranger things when both are working perfectly.
