LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 06-28-2014, 01:39 AM   #1
lamborghinione
LQ Newbie
 
Registered: Jun 2014
Posts: 3

Rep: Reputation: Disabled
SCTP Multihoming Heartbeat ACK Behavior


Hello everyone!

We are having some issues regarding SCTP multihoming and we would like to ask your opinion on this matter. We have two RHEL6.4 (2.6.32-358.el6.x86_64) machines connected by two L2 switch and a L3 switch (please see "Environment Setup" below). When we execute SCTP connection (using multihoming) between the two machines, the following behavior occurred:

Code:
      CLIENT           L2 and L3         SERVER
Secondary Primary           |      Primary Secondary
    |        |              |          |       |
    |        |              |          |       |
    |        |INIT/INIT_ACK |          |       |
    |        |<-------------|--------->|       |
    |        |COOKIE_ECHO/COOKIE_ACK   |       |
    |        |              |          |       |
    |        |<-------------|--------->|       |
    |        |HB/HB_ACK     |          |       |
    |        |              |          |       |
    |<-------|--------------|----------|       |
    |        |              |      HB  |       |
    |        |--------------|--------->|       |
    |        |HB_ACK        |          |       |
    |        |        :     |          |       |
    |        |        :     |          |       |
INIT-INIT_ACK, COOKIE_ECHO-COOKIE_ACK handshake occurred in the primary path of both machines which is expected. When a Primary path sends HEARTBEAT to another Primary, HEARTBEAT_ACK was returned to the sender. But when a Primary path sends HEARTBEAT to a Secondary path, the HEARTBEAT_ACK chunk was sent by the Primary path. We expect that the HEARTBEAT_ACK would come from the Secondary.

[Questions]
1. Is this a normal behavior with regards to SCTP multihoming?
2. Is the routing setup of the environment has something to do with this behavior? (please see "Route Setup" below)
3. Or the SCTP kernel module has something to do with this behavior?
4. Is there a solution to force Client to use its Secondary path in sending the HEARTBEAT_ACK chunk to Server's primary?


Environment Setup:

Code:
    CLIENT                        SERVER     
 172.168.39.91                172.168.40.93
 +-----------+    +------+    +-----------+
 |       eth0|----|  L2  |----|eth0       |
 |           |    +------+    |           |
 |           |       |        |           |
 |           |  +----------+  |           |
 |           |  |    L3    |  |           |
 |           |  +----------+  |           |
 |           |       |        |           |
 |           |    +------+    |           |
 |       eth1|----|  L2  |----|eth1       |
 +-----------+    +------+    +-----------+
 172.168.39.92                172.168.40.94
Route Setup:

---------- CLIENT ----------
# ip rule show
0: from all lookup local
197: from all to 172.168.39.91 lookup rt2
198: from 172.168.39.91 lookup rt2
199: from all to 172.168.39.92 lookup rt3
200: from 172.168.39.92 lookup rt3
32766: from all lookup main
32767: from all lookup default

# ip route show table rt2
172.168.40.0/24 dev eth0 scope link src 172.168.39.91
172.168.39.0/24 dev eth0 scope link src 172.168.39.91

# ip route show table rt3
172.168.40.0/24 dev eth1 scope link src 172.168.39.92
172.168.39.0/24 dev eth1 scope link src 172.168.39.92

# ip route show table main
192.168.40.0/24 dev eth1 proto kernel scope link src 192.168.40.212

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.40.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

---------- SERVER ----------
# ip rule show
0: from all lookup local
197: from all to 172.168.40.93 lookup rt2
198: from 172.168.40.93 lookup rt2
199: from all to 172.168.40.94 lookup rt3
200: from 172.168.40.94 lookup rt3
32766: from all lookup main
32767: from all lookup default

# ip route show table rt2
172.168.40.0/24 dev eth0 scope link src 172.168.40.93
172.168.39.0/24 dev eth0 scope link src 172.168.40.93

# ip route show table rt3
172.168.40.0/24 dev eth1 scope link src 172.168.40.94
172.168.39.0/24 dev eth1 scope link src 172.168.40.94

# ip route show table main
192.168.40.0/24 dev eth1 proto kernel scope link src 192.168.40.127

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.40.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1


We are hoping for your kind response and thank you in advance!

Wins
 
Old 06-30-2014, 02:37 PM   #2
nini09
Senior Member
 
Registered: Apr 2009
Posts: 1,860

Rep: Reputation: 162Reputation: 162
Do you know who change response path, server, L2 or L3 switch?
 
Old 07-01-2014, 02:20 AM   #3
lamborghinione
LQ Newbie
 
Registered: Jun 2014
Posts: 3

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by nini09 View Post
Do you know who change response path, server, L2 or L3 switch?
We usually get tcpdumps on both client and server machines. And based on the tcpdumps, its in the client machine that change the response path. We're not sure though, if the culprit is the SCTP kernel module or the routing set-up. I've already confirmed in SCTP RFC that the Heartbeat ACK sequence mentioned here is abnormal.
 
Old 07-01-2014, 02:20 PM   #4
nini09
Senior Member
 
Registered: Apr 2009
Posts: 1,860

Rep: Reputation: 162Reputation: 162
You should set host route entry on clinet and server instead of network route entry.
 
Old 07-03-2014, 10:40 AM   #5
lamborghinione
LQ Newbie
 
Registered: Jun 2014
Posts: 3

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by nini09 View Post
You should set host route entry on clinet and server instead of network route entry.
Thanks to your reply. I will try changing the routing configuration.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] IP Aliasing and Multihoming confusion jeffschips Linux - Networking 5 11-18-2011 04:57 AM
kernel version for "sctp: make sctp over IPv6 work with IPsec" patch yhclqo Linux - Kernel 2 08-27-2010 01:00 AM
Can kernel SCTP co-exist with different SCTP in user space? JohnJLewis Linux - Kernel 0 07-19-2010 01:29 PM
Multihoming dwezel Linux - Newbie 2 06-25-2008 07:39 AM
writing multihoming daemon without bind blackzone Linux - Networking 0 08-26-2004 09:40 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 06:12 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration