multihoming client question

multihoming client question

[tsoi andrew]

Dear Sir,

It is found that IP X haven't replied heartbeat Ack to IP A but our
client will not try another path B->Y.  Would you advise how B->Y path
can be enable?

lksctp client IP info:
Primary IP: A
Secondary IP: B

Server primary IP: X
Server secondary IP: Y

Regards,
Andrew

Re: multihoming client question

[Xin Long]

On Wed, Nov 30, 2016 at 6:48 PM, tsoi andrew <tsoiandrew@gmail.com> wrote:
> Dear Sir,
>
> It is found that IP X haven't replied heartbeat Ack to IP A but our
> client will not try another path B->Y.  Would you advise how B->Y path
> can be enable?
how about data sending, can it be sacked normally ?

asking that, as transport error_count would be cleared in
sctp_check_transmitted():

                        /* 8.2. When an outstanding TSN is acknowledged,
                         * the endpoint shall clear the error counter of
                         * the destination transport address to which the
                         * DATA chunk was last sent.
                         * The association's overall error counter is
                         * also cleared.
                         */
                        transport->error_count = 0;
                        transport->asoc->overall_error_count = 0;


>
> lksctp client IP info:
> Primary IP: A
> Secondary IP: B
>
> Server primary IP: X
> Server secondary IP: Y
>
> Regards,
> Andrew
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: multihoming client question

[tsoi andrew]

Dear Sir,

The connection is broken so that no data is sending at this moment.
While testing failover(force no heartbeat ack replied from the IP X),
I find that IP A try to send the heartbeat to IP Y but no heartbeat
ack finally.  Can lksctp client try to send heartbeat from IP B to IP
Y?     As only connection between IP B and IP Y is valid at that time.

Regards,
Andrew

On Wed, Nov 30, 2016 at 7:39 PM, Xin Long <lucien.xin@gmail.com> wrote:
> On Wed, Nov 30, 2016 at 6:48 PM, tsoi andrew <tsoiandrew@gmail.com> wrote:
>> Dear Sir,
>>
>> It is found that IP X haven't replied heartbeat Ack to IP A but our
>> client will not try another path B->Y.  Would you advise how B->Y path
>> can be enable?
> how about data sending, can it be sacked normally ?
>
> asking that, as transport error_count would be cleared in
> sctp_check_transmitted():
>
>                         /* 8.2. When an outstanding TSN is acknowledged,
>                          * the endpoint shall clear the error counter of
>                          * the destination transport address to which the
>                          * DATA chunk was last sent.
>                          * The association's overall error counter is
>                          * also cleared.
>                          */
>                         transport->error_count = 0;
>                         transport->asoc->overall_error_count = 0;
>
>
>>
>> lksctp client IP info:
>> Primary IP: A
>> Secondary IP: B
>>
>> Server primary IP: X
>> Server secondary IP: Y
>>
>> Regards,
>> Andrew
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: multihoming client question

[Xin Long]

On Thu, Dec 1, 2016 at 3:04 PM, tsoi andrew <tsoiandrew@gmail.com> wrote:
> Dear Sir,
>
> The connection is broken so that no data is sending at this moment.
> While testing failover(force no heartbeat ack replied from the IP X),
> I find that IP A try to send the heartbeat to IP Y but no heartbeat
> ack finally.  Can lksctp client try to send heartbeat from IP B to IP
> Y?     As only connection between IP B and IP Y is valid at that time.
>
I got your issue now.

http://marc.info/?l=linux-sctp&m\x143714727725657&w=2

This patch probably affect that.

after that fix, sctp asks the route oif address must be the src when
using secondary addresses

so in your case, oif's ip of that route to Y  must be A, instead of B.
that's why sctp never choose path B->Y.

if you want B->Y, I need you need to adjust your route.

Re: multihoming client question

[tsoi andrew]

Dear Sir,

Would you provide the link for download the new library? I only find
version 1.0.17 in http://lksctp.sourceforge.net/.

Regards,
Andrew

On Wed, Dec 7, 2016 at 8:37 PM, Xin Long <lucien.xin@gmail.com> wrote:
> On Thu, Dec 1, 2016 at 3:04 PM, tsoi andrew <tsoiandrew@gmail.com> wrote:
>> Dear Sir,
>>
>> The connection is broken so that no data is sending at this moment.
>> While testing failover(force no heartbeat ack replied from the IP X),
>> I find that IP A try to send the heartbeat to IP Y but no heartbeat
>> ack finally.  Can lksctp client try to send heartbeat from IP B to IP
>> Y?     As only connection between IP B and IP Y is valid at that time.
>>
> I got your issue now.
>
> http://marc.info/?l=linux-sctp&m\x143714727725657&w=2
>
> This patch probably affect that.
>
> after that fix, sctp asks the route oif address must be the src when
> using secondary addresses
>
> so in your case, oif's ip of that route to Y  must be A, instead of B.
> that's why sctp never choose path B->Y.
>
> if you want B->Y, I need you need to adjust your route.

Re: multihoming client question

[Marcelo Ricardo Leitner]

On Wed, Dec 21, 2016 at 05:10:22PM +0800, tsoi andrew wrote:
> Dear Sir,
> 
> Would you provide the link for download the new library? I only find
> version 1.0.17 in http://lksctp.sourceforge.net/.

1.0.17 is the latest release we have.
You can a devel copy (may not be stable) via git,
https://github.com/sctp/lksctp-tools
but that's not going to help with this problem. The change Xin mentioned
is on kernel level only.

  Marcelo

Re: multihoming client question

[tsoi andrew]

Dear Sir,

We have used iproute2 to set the route but lksctp client still choose
the path from IP A to IP Y.
It is still under our investigation.  Any hints for me?

Regards,
Andrew

On Wed, Dec 21, 2016 at 10:04 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Dec 21, 2016 at 05:10:22PM +0800, tsoi andrew wrote:
>> Dear Sir,
>>
>> Would you provide the link for download the new library? I only find
>> version 1.0.17 in http://lksctp.sourceforge.net/.
>
> 1.0.17 is the latest release we have.
> You can a devel copy (may not be stable) via git,
> https://github.com/sctp/lksctp-tools
> but that's not going to help with this problem. The change Xin mentioned
> is on kernel level only.
>
>   Marcelo

Re: multihoming client question

[Xin Long]

On Wed, Jan 11, 2017 at 6:24 PM, tsoi andrew <tsoiandrew@gmail.com> wrote:
> Dear Sir,
>
> We have used iproute2 to set the route but lksctp client still choose
> the path from IP A to IP Y.
> It is still under our investigation.  Any hints for me?
can you send your route entries, the NICs' names and their addresses,
peer's addresses?

>
> Regards,
> Andrew
>
> On Wed, Dec 21, 2016 at 10:04 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
>> On Wed, Dec 21, 2016 at 05:10:22PM +0800, tsoi andrew wrote:
>>> Dear Sir,
>>>
>>> Would you provide the link for download the new library? I only find
>>> version 1.0.17 in http://lksctp.sourceforge.net/.
>>
>> 1.0.17 is the latest release we have.
>> You can a devel copy (may not be stable) via git,
>> https://github.com/sctp/lksctp-tools
>> but that's not going to help with this problem. The change Xin mentioned
>> is on kernel level only.
>>
>>   Marcelo

Re: multihoming client question

[tsoi andrew]

Dear Sir,

My partner TIm will help to provide information.

Hi Tim,

Please help to provide information.

Regards,
Andrew


---------- Forwarded message ----------
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, Jan 11, 2017 at 9:19 PM
Subject: Re: multihoming client question
To: tsoi andrew <tsoiandrew@gmail.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
linux-sctp@vger.kernel.org, Neil Horman <nhorman@tuxdriver.com>


On Wed, Jan 11, 2017 at 6:24 PM, tsoi andrew <tsoiandrew@gmail.com> wrote:
> Dear Sir,
>
> We have used iproute2 to set the route but lksctp client still choose
> the path from IP A to IP Y.
> It is still under our investigation.  Any hints for me?
can you send your route entries, the NICs' names and their addresses,
peer's addresses?

>
> Regards,
> Andrew
>
> On Wed, Dec 21, 2016 at 10:04 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
>> On Wed, Dec 21, 2016 at 05:10:22PM +0800, tsoi andrew wrote:
>>> Dear Sir,
>>>
>>> Would you provide the link for download the new library? I only find
>>> version 1.0.17 in http://lksctp.sourceforge.net/.
>>
>> 1.0.17 is the latest release we have.
>> You can a devel copy (may not be stable) via git,
>> https://github.com/sctp/lksctp-tools
>> but that's not going to help with this problem. The change Xin mentioned
>> is on kernel level only.
>>
>>   Marcelo

Re: multihoming client question

[Xin Long]

On Wed, Feb 22, 2017 at 3:33 PM, Tim Tam <wctamtim2016@gmail.com> wrote:
> Dear Marcelo,
>
> As we want to setup a 2 way mutihome, we setup a Vlan config to divide 2 IP
> subnet (172.28.129.56, 172.28.129.184) and the iproute2 config as below.
> Therefore, it suppose the connection only allow 172.28.129.56 <----->
> 10.82.24.26, 172.28.129.184 <-----> 10.82.24.153
> However, during our test, it found the heatbeat send from server
> 10.82.24.153 ---> 172.28.129.184 but the heartbeat_ack always reply with
> other interface 172.28.129.56 ----> 10.82.24.153. we didn't setup any
> routing for this,  why the library always reply the ack with another
> interface?
> thanks
>
> iproute2:
>
>
> 32722:  from 172.28.129.184 to 10.82.24.153 lookup SCTP20
> 32723:  from 172.28.129.56 to 10.82.24.26 lookup SCTP19
>
> [root@lqsgwtest ~]# ip route show table SCTP19
> default via 172.28.129.1 dev em3
shouldn't it be "default via 172.28.129.1 dev em3.6" ?

> [root@lqsgwtest ~]# ip route show table SCTP20
> default via 172.28.129.129 dev em2
"default via 172.28.129.129 dev em2.5" ?

>
>
>
> interface:
>
> em2.5     Link encap:Ethernet  HWaddr 78:2B:CB:35:6D:52
>           inet addr:172.28.129.184  Bcast:172.28.129.255
> Mask:255.255.255.128
>           inet6 addr: fe80::7a2b:cbff:fe35:6d52/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:0 (0.0 b)  TX bytes:468 (468.0 b)
>
>
>
> em3.6     Link encap:Ethernet  HWaddr 78:2B:CB:35:6D:54
>           inet addr:172.28.129.56  Bcast:172.28.129.127
> Mask:255.255.255.128
>           inet6 addr: fe80::7a2b:cbff:fe35:6d54/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:0 (0.0 b)  TX bytes:468 (468.0 b)
>
> netstat route:
>
> 10.82.24.26     172.28.129.1    255.255.255.255 UGH       0 0          0 em3
> 10.82.24.153    172.28.129.129  255.255.255.255 UGH       0 0          0 em2
> 172.28.129.128  0.0.0.0         255.255.255.128 U         0 0          0
> em2.5
> 172.28.129.0    0.0.0.0         255.255.255.128 U         0 0          0
> em3.6
>
>
> Regards,
> Tim Tam
>
> On Tue, Feb 21, 2017 at 4:51 PM, tsoi andrew <tsoiandrew@gmail.com> wrote:
>>
>> Dear Sir,
>>
>> My partner TIm will help to provide information.
>>
>> Hi Tim,
>>
>> Please help to provide information.
>>
>> Regards,
>> Andrew
>>
>>
>> ---------- Forwarded message ----------
>> From: Xin Long <lucien.xin@gmail.com>
>> Date: Wed, Jan 11, 2017 at 9:19 PM
>> Subject: Re: multihoming client question
>> To: tsoi andrew <tsoiandrew@gmail.com>
>> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
>> linux-sctp@vger.kernel.org, Neil Horman <nhorman@tuxdriver.com>
>>
>>
>> On Wed, Jan 11, 2017 at 6:24 PM, tsoi andrew <tsoiandrew@gmail.com> wrote:
>> > Dear Sir,
>> >
>> > We have used iproute2 to set the route but lksctp client still choose
>> > the path from IP A to IP Y.
>> > It is still under our investigation.  Any hints for me?
>> can you send your route entries, the NICs' names and their addresses,
>> peer's addresses?
>>
>> >
>> > Regards,
>> > Andrew
>> >
>> > On Wed, Dec 21, 2016 at 10:04 PM, Marcelo Ricardo Leitner
>> > <marcelo.leitner@gmail.com> wrote:
>> >> On Wed, Dec 21, 2016 at 05:10:22PM +0800, tsoi andrew wrote:
>> >>> Dear Sir,
>> >>>
>> >>> Would you provide the link for download the new library? I only find
>> >>> version 1.0.17 in http://lksctp.sourceforge.net/.
>> >>
>> >> 1.0.17 is the latest release we have.
>> >> You can a devel copy (may not be stable) via git,
>> >> https://github.com/sctp/lksctp-tools
>> >> but that's not going to help with this problem. The change Xin
>> >> mentioned
>> >> is on kernel level only.
>> >>
>> >>   Marcelo
>
>