Re: Supporting 4 way connections in LKSCTP

[Michael Tuexen]

On Dec 5, 2013, at 10:35 AM, David Laight <David.Laight@xxxxxxxxxx> wrote:

>>>> 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.
> ...
>> 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'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.
> 
> Does seem that the addresses listed in INIT and INIT_ACK chunks
> should be ignored until a valid HB response has been received.
You are not allowed to send DATA to them until they are confirmed.
> If an abort is received before a valid HB response then the
> address should be ignored rather than the connection aborted.
No.
> Then it wouldn't matter anywhere near as much if addresses are
> advertised that are not reachable from the remote system.
> 
> All this should have been thought about when the original RFC
> was written.
Scoping wasn't considered that much, same as NAT traversal.
The assumption was that in SIGTRAN networks no NAT boxes are
deployed and you use appropriate addressing (for redundancy).

Best regards
Michael
> 
> 	David
> 
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/