Jump to content

SCTP Multihoming Heartbeat ACK Behavior


Recommended Posts

Guest lamborghinione
Posted

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:

 

HB1.jpg

 

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?

 

ENV.jpg

Environment Setup:

 

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

Attached Images

 

Continue reading...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...