So, can I get confirmation that whether we can enhance to support the
scenarios or any resolution on providing the correct routing?
On Tue, Nov 26, 2013 at 9:03 AM, Sun Paul wrote:
> Hi
>
> we have a problem on using LKSCTP to form a 4 ways multi-homing network.
>
> Configuration
> - Node-A has 2
On Dec 5, 2013, at 10:35 AM, David Laight 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
> >> 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
On Dec 4, 2013, at 7:23 PM, Vlad Yasevich wrote:
> On 12/04/2013 11:25 AM, Michael Tuexen wrote:
>> On Dec 4, 2013, at 5:12 PM, Vlad Yasevich wrote:
>>
>>> 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, D
On 12/04/2013 11:25 AM, Michael Tuexen wrote:
> On Dec 4, 2013, at 5:12 PM, Vlad Yasevich wrote:
>
>> 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 IN
On 12/04/2013 12:57 PM, Sun Paul wrote:
> As I know, the A to C and A to D case must have a router in between to form
> SCTP multihome topology.
Not necessary. I've produced proper multihoming topologies with just
VLANs and different subnet assignment. You can even remove VLANs
if you correctly
On Dec 4, 2013, at 5:48 PM, David Laight wrote:
>> 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".
>
> Y
> 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".
You might have two machines that are connected via the publ
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 r
On Dec 4, 2013, at 5:12 PM, Vlad Yasevich wrote:
> 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
> > 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.
>
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.
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
> > 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 I
On 12/03/2013 08:59 PM, Sun Paul wrote:
> This is the most puzzling area. I really not sure whether it is really
> valid or not. Is there any documented statement supporting this?
>
> Let me summarize the behavior again.
>
> NODE-A
> eth1: IP-A
> eth2: IP-B
>
> NODE-B
> eth1: IP-X
> eth2: IP-Y
>
This is the most puzzling area. I really not sure whether it is really
valid or not. Is there any documented statement supporting this?
Let me summarize the behavior again.
NODE-A
eth1: IP-A
eth2: IP-B
NODE-B
eth1: IP-X
eth2: IP-Y
In normal operation, IP-A sends INIT to IP-X, IP-X returns INIT_
On 12/03/2013 08:11 AM, Sun Paul wrote:
> But how about the HB and HB_ACK? Still valid?
As long as the source address is part of the association, then yes
it is perfectly valid.
-vlad
> On Dec 3, 2013 8:32 PM, "Vlad Yasevich" wrote:
>
>> On 12/02/2013 09:19 PM, Sun Paul wrote:
>>> so in this
On 12/02/2013 09:19 PM, Sun Paul wrote:
> so in this case, says
>
> (NODE-A) IP-B send INIT to IP-X (NODE-B), and then IP-Y (NODE-B)
> returns INIT_ACK to IP-B (NODE-A)
>
> this is also treated as a valid, am I correct?
As long as IP-X (Node-B) is present in the address list of the INIT-ACK
chun
if we do not specific the gateway, it will be a problem. One of the
reason why it is like that is due to that the server do not know which
source IP should be used to send out the query.
[root@localhost ~]# ip route get 12.1.1.1
RTNETLINK answers: Network is unreachable
[root@localhost ~]# ip rou
so in this case, says
(NODE-A) IP-B send INIT to IP-X (NODE-B), and then IP-Y (NODE-B)
returns INIT_ACK to IP-B (NODE-A)
this is also treated as a valid, am I correct?
On Tue, Dec 3, 2013 at 10:03 AM, Vlad Yasevich wrote:
> On 12/02/2013 08:39 PM, Sun Paul wrote:
>> Another question
>>
>> if a
On 12/02/2013 08:39 PM, Sun Paul wrote:
> Another question
>
> if a wrong source IP is used, does the association still classified as normal?
What do you mean my wrong source IP? As long as the address is part of
the association, it can be used.
-vlad
>
> On Tue, Dec 3, 2013 at 9:31 AM, Sun P
On 12/02/2013 08:31 PM, Sun Paul wrote:
> Thanks Vlad
>
> I checked on the route, and it looks correct.
>
> [root@localhost ~]# ip route get 11.1.1.1 from 110.1.1.1
> 11.1.1.1 from 110.1.1.1 via 110.1.1.254 dev eth1
> cache mtu 1500 advmss 1460 hoplimit 64
>
> [root@localhost ~]# ip route g
Another question
if a wrong source IP is used, does the association still classified as normal?
On Tue, Dec 3, 2013 at 9:31 AM, Sun Paul wrote:
> Thanks Vlad
>
> I checked on the route, and it looks correct.
>
> [root@localhost ~]# ip route get 11.1.1.1 from 110.1.1.1
> 11.1.1.1 from 110.1.1.1 v
Thanks Vlad
I checked on the route, and it looks correct.
[root@localhost ~]# ip route get 11.1.1.1 from 110.1.1.1
11.1.1.1 from 110.1.1.1 via 110.1.1.254 dev eth1
cache mtu 1500 advmss 1460 hoplimit 64
[root@localhost ~]# ip route get 11.1.1.1 from 120.1.1.1
11.1.1.1 from 120.1.1.1 via 120
On Mon, Dec 2, 2013 at 11:42 AM, Vlad Yasevich wrote:
> On 12/02/2013 10:45 AM, Karl Heiss wrote:
>> On Mon, Dec 2, 2013 at 9:38 AM, Vlad Yasevich wrote:
>>> On 11/27/2013 11:03 PM, Sun Paul wrote:
How LKSCTP select which source address to use for the INIT_ACK or
HB_ACK? below is the te
On 12/02/2013 10:45 AM, Karl Heiss wrote:
> On Mon, Dec 2, 2013 at 9:38 AM, Vlad Yasevich wrote:
>> On 11/27/2013 11:03 PM, Sun Paul wrote:
>>> How LKSCTP select which source address to use for the INIT_ACK or
>>> HB_ACK? below is the testing result where a router is located in the
>>> middle.
>>>
On Mon, Dec 2, 2013 at 9:38 AM, Vlad Yasevich wrote:
> On 11/27/2013 11:03 PM, Sun Paul wrote:
>> How LKSCTP select which source address to use for the INIT_ACK or
>> HB_ACK? below is the testing result where a router is located in the
>> middle.
>>
>> Before starting the application. the packet o
On 11/27/2013 11:03 PM, Sun Paul wrote:
> How LKSCTP select which source address to use for the INIT_ACK or
> HB_ACK? below is the testing result where a router is located in the
> middle.
>
> Before starting the application. the packet on eth1 and eth2 are
>
> eth1
> 0 packets dropped by kernel
How LKSCTP select which source address to use for the INIT_ACK or
HB_ACK? below is the testing result where a router is located in the
middle.
Before starting the application. the packet on eth1 and eth2 are
eth1
0 packets dropped by kernel
[root@localhost ~]# tcpdump -i eth1 -s 0 -nn
tcpdump: ve
On Wed, Nov 27, 2013 at 07:10:49AM +0800, Sun Paul wrote:
> Hi Vlad
>
> Thank for your reply. If it is based on the destination IP to find the
> best route, why the problem didn't happen on single-homing sample?
>
Because You only ever use one address from NODE A (12.1.1.1)
> In the single-homin
Hi Vlad
Thank for your reply. If it is based on the destination IP to find the
best route, why the problem didn't happen on single-homing sample?
In the single-homing sample that provided in the original email, both
of the interfaces (eth1 and eth2) are presented on NODE-B during the
test. Howeve
On 11/25/2013 08:03 PM, Sun Paul wrote:
> Hi
>
> we have a problem on using LKSCTP to form a 4 ways multi-homing network.
>
> Configuration
> - Node-A has 2 IP addresses in different subnets, known as IP-A (eth1),
> IP-B (eth2)
> - Node-B has 2 IP addresses in different subnets, known as IP-X (et
32 matches
Mail list logo