From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Yasevich Subject: Re: Supporting 4 way connections in LKSCTP Date: Wed, 04 Dec 2013 11:12:34 -0500 Message-ID: <529F5472.9030207@gmail.com> References: <20131127124530.GA23369@hmsreliant.think-freely.org> <529C9B50.50002@gmail.com> <529CB859.9090904@gmail.com> <529D3BF9.3070208@gmail.com> <529DCF42.1070800@gmail.com> <529DF73E.7060604@gmail.com> <529F395B.9040308@gmail.com> <529F4D1A.3050304@gmail.com> <7A4B9BD9-B2BF-4625-A2E5-500CD4A6D399@lurchi.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David Laight , Sun Paul , netdev@vger.kernel.org, linux-sctp@vger.kernel.org, Karl Heiss , Neil Horman , linux-kernel@vger.kernel.org To: Michael Tuexen Return-path: In-Reply-To: <7A4B9BD9-B2BF-4625-A2E5-500CD4A6D399@lurchi.franken.de> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 12/04/2013 11:01 AM, Michael Tuexen wrote: > On Dec 4, 2013, at 4:41 PM, Vlad Yasevich wrote: > >> 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. > The point is that address scoping should be used. When sending an > INIT from 10.10.10.1 to 10.10.10.4 you should not list 192.168.1.1, > since you are transmitting an address to a node which might or might > not "be in the same scope". We had IDs for that in the past, but > they never made it to RFC state, because they were not progressed enough > by the authors. Maybe we should push them again... But these 2 are technically in the same scope. They are both private address types. Also, this will not solve the problem either since the configured addresses could be: System A) 10.0.0.1 on Lan X, 10.10.0.1 on Lan Y System B) 10.0.0.2 on Lan X, 10.10.0.2 on Lan Y System C) 10.0.0.3 on Lan X, 10.10.0.2 on Lan Z Same problem will occur. Btw, were there any IDs other then draft-stewart-tsvwg-sctp-ipv4? Thanks -vlad > > Best regards > Michael >> >> -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-sctp" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >