Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx> writes: > AFAIK, the connection should not "break" just because the interface has > changed unless there is some source address filtering on the links. Exactly, as far as I understand it, conntrack table should be taking care about that. Update: looks like some cases are working, and some are not, i.e. HTTP request to the host works, but ssh to that same host blocks in the middle of the inital key negotiation and then sometimes connects after a minute or so and sometimes doesn't. Then it runs for a minute and stops. At the same time I see route cache being flushed, so I don't think its a coincidence. Other things sometimes blocking are large CDNs like facebook fbcdn, akamai, sometimes even google. I've tried sending and receiving more than MTU bytes to rule out fragmentation issues, since I do have weird MTUs (pppoe connections via vlans), but if its fragmentation I should also have problems without multipath, which I don't. Any ideas what I might be missing here? >> Is there a way to say: I want every source/destination pair to >> initially get a random nexthop but then stick to it unless it doesn't >> exist any more or the cache is manually flushed. > > In any case, I'm afraid you cannot assume a cache entry is never flushed > while the connection is established (it may just be inactive for a > while). If you must ensure that a connection will keep being routed > through the initially selected interface, you could use iptables to mark > the first packet with a different mark for each interface and then use > the mark to route all subsequent packets with a normal (non multipath) > route. > > Example (uncomplete, but you get the picture) : > > iptables -t mangle -A POSTROUTING -o ppp3 -j CONNMARK --set-mark 3 > iptables -t mangle -A OUTPUT|PREROUTING -j CONNMARK --restore-mark > > ip rule add fwmark 3 table <tablenum> > ip route add default dev ppp3 table <tablenum> Yes, I understand that, and I might just take this approach, but I don't understand why should it be necessary. And its nowhere mentioned in any of the multipath tutorials on the net, and I must have read them all ;) -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
