On Dec 4, 2013, at 7:23 PM, Vlad Yasevich <vyasevich@xxxxxxxxx> wrote: > On 12/04/2013 11:25 AM, Michael Tuexen wrote: >> On Dec 4, 2013, at 5:12 PM, Vlad Yasevich <vyasevich@xxxxxxxxx> wrote: >> >>> On 12/04/2013 11:01 AM, Michael Tuexen wrote: >>>> On Dec 4, 2013, at 4:41 PM, Vlad Yasevich <vyasevich@xxxxxxxxx> 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 >> That is correct. But I think you should not transfer a private address >> to another private address belonging to a different network. >> I don't think this was specified in the older IDs... >>> 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. >> Depending on the subnet masks, it might work not not. Are you >> configuring them with /8? > > No, /16 :). With that, Sys A talking to Sys C will get an abort > from Sys B when trying to talk to 10.10.0.2. With /8, it'll be > even worse since SysB and SysC will have duplicate addresses > within the subnet. :) > > The point is that you don't always know that the same private subnet > is in reality 2 different subnets with duplicate addresses. I agree, you can't do it perfectly right. But you can provide some protection. > > I've had to debug an actual production issue similar to this where > customer had a very similar configuration to above, and their > associations kept getting aborted. When I tried accessing the > system that kept sending aborts, I found it was some windows > server and not a Diameter station they were expecting. Interesting... Availability of SCTP on Windows is quite limited... But people seem to use SCTP on Windows. Best regards Michael > >>> >>> Btw, were there any IDs other then draft-stewart-tsvwg-sctp-ipv4? >> Yes, one for IPv6. >> http://tools.ietf.org/html/draft-stewart-tsvwg-sctpipv6-01 >> They need to be integrated and improved... >> > > Ok. I'll take a look. > > Thanks > -vlad > >> Best regards >> Michael >>> >>> 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@xxxxxxxxxxxxxxx >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>> >>>> >>> >>> >> > > -- 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
