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
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.
> ...
>>
> >> 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
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
On Dec 5, 2013, at 10:35 AM, David Laight david.lai...@aculab.com 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
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 paul...@gmail.com wrote:
Hi
we have a problem on using LKSCTP to form a 4 ways multi-homing network.
Configuration
-
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,
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
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".
>
>
> 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
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
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.
> > 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
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
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
In normal
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
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
On 12/04/2013 11:01 AM, Michael Tuexen wrote:
On Dec 4, 2013, at 4:41 PM, Vlad Yasevich vyasev...@gmail.com 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
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
On Dec 4, 2013, at 5:12 PM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/04/2013 11:01 AM, Michael Tuexen wrote:
On Dec 4, 2013, at 4:41 PM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/04/2013 09:50 AM, David Laight wrote:
In normal operation, IP-A sends INIT to IP-X, IP-X returns
On Dec 4, 2013, at 4:41 PM, Vlad Yasevich vyasev...@gmail.com 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
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 public
On Dec 4, 2013, at 5:48 PM, David Laight david.lai...@aculab.com 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
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 12/04/2013 11:25 AM, Michael Tuexen wrote:
On Dec 4, 2013, at 5:12 PM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/04/2013 11:01 AM, Michael Tuexen wrote:
On Dec 4, 2013, at 4:41 PM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/04/2013 09:50 AM, David Laight wrote:
In normal
On Dec 4, 2013, at 7:23 PM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/04/2013 11:25 AM, Michael Tuexen wrote:
On Dec 4, 2013, at 5:12 PM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/04/2013 11:01 AM, Michael Tuexen wrote:
On Dec 4, 2013, at 4:41 PM, Vlad Yasevich
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
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
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
chunk,
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 vyasev...@gmail.com wrote:
On 12/02/2013 09:19 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
In normal operation, IP-A sends INIT to IP-X, IP-X returns
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
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
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
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
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
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
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
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
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
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
On Mon, Dec 2, 2013 at 9:38 AM, Vlad Yasevich vyasev...@gmail.com 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
On 12/02/2013 10:45 AM, Karl Heiss wrote:
On Mon, Dec 2, 2013 at 9:38 AM, Vlad Yasevich vyasev...@gmail.com 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
On Mon, Dec 2, 2013 at 11:42 AM, Vlad Yasevich vyasev...@gmail.com wrote:
On 12/02/2013 10:45 AM, Karl Heiss wrote:
On Mon, Dec 2, 2013 at 9:38 AM, Vlad Yasevich vyasev...@gmail.com wrote:
On 11/27/2013 11:03 PM, Sun Paul wrote:
How LKSCTP select which source address to use for the INIT_ACK or
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
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 paul...@gmail.com 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
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 get
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 Paul
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 vyasev...@gmail.com wrote:
On 12/02/2013 08:39 PM, Sun Paul wrote:
Another
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
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:
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
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-homing
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:
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.
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
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 (eth1),
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.
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 (eth1),
IP-Y (eth2)
the four way paths are shown below.
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 (eth1),
IP-Y (eth2)
the four way paths are shown below.
66 matches
Mail list logo
