Pekka Savola wrote: > On Sun, 22 Dec 2002, Frank 'xraz' Fricke wrote: > > |On Sun, 22 Dec 2002, Frank 'xraz' Fricke wrote: > > |> What is the common practice/workaround for the > interface-selection > > |> problem with multiple ipv6-defaultroutes? I could not > find something > > |> working on the net. > > | > > |Could you be a bit more specific which issue you're > referring to? How is > > |this different from IPv4? > > > > If you have two (or more) sit-tunnels wich have a 2000::/3 or > > default route, (at least replys to incoming) packtes are always > > sent via the route last added. > > Are you sure these routes are identical? > > I recall doing some testing and noting that at least some > packets would be > load-balanced between identical routes. Yes the packets are load balanced between the two routes. And apparently if it works you either have <n> tunnels to the same uplink or your uplink(s) don't filter on source address thus allowing for spoofed packets to be distributed by them. Which is a bad thing(tm). And yes, filtering breaks some peoples idea of 'multihoming'. Note that if one tunnel breaks the traffic can't be sent back to that address unless the upstream advertises both, but this normally isn't the case. Real multihoming is in the process of being solved by amongst others IPv6MH: http://arneill-py.sacramento.ca.us/ipv6mh/ They are quite busy with it and it seems very promising. > > I cannot find a way to force sending > > the packets with the interface that matches their source address. > > The behaviour is the same as with IPv4, and circumventing it requires > so-called policy routing; I'm not sure if this is supported > in IPv6. You > may be able to get additional ideas from e.g. > http://lartc.org/howto/lartc.rpdb.html This doesn't work for IPv6 at the moment and it would be a welcome addition for many people. Currently the default route picked is also based on the matching of the prefix of the tunnel. So if you got one 6bone (3ffe::/16) prefix on the first tunnel and a RIR (2001::/16) prefix on the other one, 6bone destinations will flow over the 6bone tunnel, and RIR over the RIR tunnel. This also decides the outgoing address if the box itself is originating the packets and the application didn't bind() the socket to an address. At the moment your best 'go' for fixing this is assigning specific routes over the specific tunnels, this is not a nice thing(tm) but eh ;) (Or be nice and implement the routing policies...) Btw... 2.4.20 allows setting of a default route (0::/0), so one can drop the 2000::/3 usage. 2.4.19 and downward didn't allow this for boxes that where marked as forwarding IPv6. Greets, Jeroen - : 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
