[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B7460@saturn3.aculab.com>
Date: Thu, 5 Dec 2013 09:35:40 -0000
From: "David Laight" <David.Laight@...LAB.COM>
To: "Vlad Yasevich" <vyasevich@...il.com>,
"Michael Tuexen" <Michael.Tuexen@...chi.franken.de>
Cc: "Sun Paul" <paulrbk@...il.com>, <netdev@...r.kernel.org>,
<linux-sctp@...r.kernel.org>, "Karl Heiss" <kheiss@...il.com>,
"Neil Horman" <nhorman@...driver.com>,
<linux-kernel@...r.kernel.org>
Subject: RE: Supporting 4 way connections in LKSCTP
> >> 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.
If an abort is received before a valid HB response then the
address should be ignored rather than the connection aborted.
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.
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists