On 12/04/2013 09:50 AM, David Laight wrote: >>> In normal operation, IP-A sends INIT to IP-X, IP-X returns INIT_ACK to >>> IP-A. IP-A then sends HB to IP-X, IP-X then returns HB_ACK to IP-A. In >>> the meantime, IP-B sends HB to IP-Y and IPY returns HB_ACK. >>> >>> In case of the path between IP-A and IP-X is broken, IP-B sends INIT >>> to IP-X, NODE-B uses IP-Y to return INIT_ACK to IP-B. Then IP-B sends >>> HB to IP-X, and IP-Y returns HB_ACK to IP-B. In the meantime, the HB >>> communication between IP-B and IP-Y follows the normal flow. >>> >>> Can I confirm, is it really valid? >> >> As long as NODE-B knows about both IP-A and IP-B, and NODE-A knows about >> both IP-X and IP-Y (meaning all the addresses were exchanged inside INIT >> and INIT-ACK), then this situation is perfectly valid. In fact, this >> has been tested an multiple interops. > > There are some network configurations that do cause problems. > Consider 4 systems with 3 LAN segments: > A) 10.10.10.1 on LAN X and 192.168.1.1 on LAN Y. > B) 10.10.10.2 on LAN X and 192.168.1.2 on LAN Y. > C) 10.10.10.3 on LAN X. > D) 10.10.10.4 on LAN X and 192.168.1.2 on LAN Z. > There are no routers between the networks (and none of the systems > are running IP forwarding). > > If A connects to B everything is fine - traffic can use either LAN. > > Connections from A to C are problematic if C tries to send anything > (except a HB) to 192.168.1.1 before receiving a HB response. > One of the SCTP stacks we've used did send messages to an > inappropriate address, but I've forgotten which one.
I guess that would be problematic if A can not receive traffic for 192.168.1.1 on the interface connected to LAN X. I shouldn't technically be a problem for C as it should mark the path to 192.168.1.1 as down. For A, as long as it doesn't decide to ABORT the association, it shouldn't be a problem either. It would be interesting to know more about what problems you've observed. > > Connections between A and D fail unless the HB errors A receives > for 192.168.1.2 are ignored. Yes, this configuration is very error prone, especially if system B and system D are up at the same time. Any attempts by system A to use LAN Y will result in an ABORT generated by system B. I have seen this issue well in production and we had to renumber system D to solve it. -vlad > > Of course the application could explicitly bind to only the 10.x address > but that requires the application know the exact network topology > and may be difficult for incoming calls. > > David > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
