On Mon, Jul 9, 2018 at 7:38 PM, Martin Schröder <martin@xxxxxxxxxx> wrote: > 2018-07-06 18:34 GMT+02:00 Xin Long <lucien.xin@xxxxxxxxx>: >> Make sense? > > Yes, but it doesn't make us happy. :-) > > So we can get our setup working (but will be able to test that only in > some weeks). > > The biggest problem for us is that we only control one side and can not > really prevent such a cross connection. OK, I understand what you really want. But I think it should be something from the route, like some route's multipath policy that could detect one route gw failure and change to another gw. SCTP should not decide the route's out dev according to the incoming INIT packet only for "INIT_ACK". Sorry about that. > > Btw: Why is there a primary address (local) AND a primary peer address > (remote) if only one path is possible as primary and the local and the > remote address is fixed? There's no so-called "a primary local", but only "a primary peer" (remote) address named "a primary path or transport", the local address is always selected among the bind_addr_list, but the one also on the outdev of the route has the higher priority to be used as the src IP of the outgoing packets like INIT_ACK. Like, it got the route for the path "178.23.31.130": 178.23.31.130/25 via 195.219.193.97 dev eth0 [A] In the bind_addr_list, there are two addrs: 195.219.193.90, 195.219.193.122 If 195.219.193.122 is on eth0, which is the outdev of route [A], 195.219.193.122 will be select for this path's src IP. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
