public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sun Paul <paulrbk@gmail.com>
To: linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Supporting 4 way connections in LKSCTP
Date: Fri, 6 Dec 2013 10:12:01 +0800	[thread overview]
Message-ID: <CAFXGft+2vxKnQ88988L9v+YrWB3OBxUqDwEAO4tLFH+CEyGNJA@mail.gmail.com> (raw)
In-Reply-To: <CAFXGft+CXk3W8=3w=AuYzqYtYnR8nH4Of9=668tUeT+tugD9-A@mail.gmail.com>

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 <paulrbk@gmail.com> 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),
> IP-Y (eth2)
>
> the four way paths are shown below.
> 1. IP-A (11.1.1.1) to IP-X (11.1.1.11)
> 2. IP-B (12.1.1.1) to IP-Y (12.1.1.11)
> 3. IP-A (11.1.1.1) to IP-Y (12.1.1.11)
> 4. IP-B (12.1.1.1) to IP-X (11.1.1.11)
>
> the HB/HB_ACK is normal for the paths " IP-A to IP-X" and "IP-B to
> IP-Y", but it is not correct for the rest of two.
>
> First of all, we are using iproute2 to form 2 table such that when
> IP-B arrives on IP-X, it will know how to route back to IP-B on the
> same interface, i.e (eth1). Same logic for the path "IP-A to IP-X".
>
> What we observed here is that when 12.1.1.1 sends INIT to 11.1.1.11,
> LKSCTP will send back the INIT_ACK to 12.1.1.1 using 12.1.1.11 but not
> using the IP 11.1.1.11.
>
> The above operation makes the subsequence HB/HB_ACK in using wrong IP address.
>
> TCP trace on eth1
> 18:02:41.058640 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [INIT]
> [init tag: 19933036] [rwnd: 102400] [OS: 16] [MIS: 16] [init TSN: 0]
> 18:02:41.061634 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [COOKIE ECHO]
> 18:02:41.062642 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
> 18:02:41.062846 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
> 18:02:41.361811 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
> 18:02:41.661791 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
> 18:02:41.961791 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
>
> TCP trace on eth2
> 18:02:41.058755 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [INIT ACK]
> [init tag: 424726157] [rwnd: 131072] [OS: 5] [MIS: 5] [init TSN:
> 3340756356]
> 18:02:41.061696 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [COOKIE ACK]
> 18:02:41.062663 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]
> 18:02:41.062791 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
> 18:02:41.361777 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
> 18:02:41.661772 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
> 18:02:41.961772 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
> 18:02:42.161771 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
> 18:02:42.461770 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
> 18:02:42.675770 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
>
>
> If we are using single homing, there is no problem on the SCTP
> communication. Below is the TCP trace on eth1 using sctp_test
>
> 18:09:55.356727 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [INIT]
> [init tag: 32516609] [rwnd: 102400] [OS: 16] [MIS: 16] [init TSN: 0]
> 18:09:55.356811 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [INIT ACK]
> [init tag: 3168861995] [rwnd: 131072] [OS: 10] [MIS: 16] [init TSN:
> 1877695021]
> 18:09:55.357727 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [COOKIE ECHO]
> 18:09:55.357788 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [COOKIE ACK]
> 18:09:55.358724 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
> 18:09:55.358740 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]
> 18:09:55.379715 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [DATA]
> (B)(E) [TSN: 0] [SID: 0] [SSEQ 0] [PPID 0x3]
> 18:09:55.379735 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [SACK]
> [cum ack 0] [a_rwnd 131064] [#gap acks 0] [#dup tsns 0]
> 18:09:55.657716 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
> 18:09:55.657732 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]
>
> From the observations, it seems that the LKSCTP library is not able to
> use the original local address when multi-homing is being used. Is
> there anyway can be resolved it?
>
> Thanks
>
> PS

      parent reply	other threads:[~2013-12-06  2:12 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-26  1:03 Supporting 4 way connections in LKSCTP Sun Paul
2013-11-26 15:19 ` Vlad Yasevich
     [not found]   ` <CAFXGftLsKm9a5bmXX4Fe+rnSvYVdBDOyYGwisRP7XMu+ky=DGw@mail.gmail.com>
2013-11-26 23:10     ` Sun Paul
2013-11-27 12:45       ` Neil Horman
2013-11-28  4:03         ` Sun Paul
2013-12-02 14:38           ` Vlad Yasevich
2013-12-02 15:45             ` Karl Heiss
2013-12-02 16:42               ` Vlad Yasevich
2013-12-02 17:10                 ` Karl Heiss
2013-12-03  1:31                 ` Sun Paul
2013-12-03  1:39                   ` Sun Paul
2013-12-03  2:03                     ` Vlad Yasevich
2013-12-03  2:19                       ` Sun Paul
2013-12-03 12:32                         ` Vlad Yasevich
     [not found]                           ` <CAFXGftK5tz90OzObiV7Hi+g080j3zWCNdo217CKdNkOY4JWQUg@mail.gmail.com>
2013-12-03 15:22                             ` Vlad Yasevich
2013-12-04  1:59                               ` Sun Paul
2013-12-04 14:16                                 ` Vlad Yasevich
2013-12-04 14:50                                   ` David Laight
2013-12-04 15:41                                     ` Vlad Yasevich
2013-12-04 16:01                                       ` Michael Tuexen
2013-12-04 16:12                                         ` Vlad Yasevich
2013-12-04 16:25                                           ` Michael Tuexen
2013-12-04 18:23                                             ` Vlad Yasevich
2013-12-04 19:39                                               ` Michael Tuexen
2013-12-05  9:35                                               ` David Laight
2013-12-05 13:07                                                 ` Michael Tuexen
2013-12-04 16:48                                           ` David Laight
2013-12-04 17:06                                             ` Michael Tuexen
2013-12-04 16:12                                       ` David Laight
     [not found]                                     ` <CAFXGftJsVzR8XgdEmcRKP8DePZoF+xGbaeS-RPgr2XNo7snF3g@mail.gmail.com>
2013-12-04 18:15                                       ` Vlad Yasevich
2013-12-03  2:02                   ` Vlad Yasevich
2013-12-03  2:21                     ` Sun Paul
2013-12-06  2:12 ` Sun Paul [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFXGft+2vxKnQ88988L9v+YrWB3OBxUqDwEAO4tLFH+CEyGNJA@mail.gmail.com \
    --to=paulrbk@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox