Bug 462423 - SCTP multi-homing issue
SCTP multi-homing issue
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lksctp-tools (Show other bugs)
4.4
i686 Linux
medium Severity urgent
: rc
: ---
Assigned To: Zdenek Prikryl
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-16 01:32 EDT by schanda
Modified: 2008-09-23 07:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-23 07:38:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Etherael traces (4.35 KB, application/octet-stream)
2008-09-16 01:32 EDT, schanda
no flags Details

  None (edit)
Description schanda 2008-09-16 01:32:00 EDT
Created attachment 316810 [details]
Etherael traces

Description of problem:

SCTP multi-homing not working correctly if association is established on second interface.

Version-Release number of selected component (if applicable):
# rpm -qa |grep lksctp
lksctp-tools-doc-1.0.6-1
lksctp-tools-1.0.6-1
lksctp-tools-devel-1.0.6-1

# uname -a
Linux Linux-RHEL4 2.6.9-42.EL #1 Wed Jul 12 23:16:43 EDT 2006 i686 athlon
i386 GNU/Linux


How reproducible:

We are using sctp_darn tool shipped with lksctp rpm for testing multi-
homing.
We are encountering problem in one scenario.

Test is conducted between two nodes, one acting as client and other as
server.
Each node has two network interfaces eth0 and eth1 with IP addresses in
192.168.1.* and 193.168.1.* network respectively.

If we run following command on client side then we notice that both IP
addresses are exchanged in INIT/INIT ACK messages and become part of
association.  In this case multi-homing works correctly and single cable
pullout has no impact on association.

#sctp_darn -H 192.168.1.231 -P 3000 -B 193.168.1.231 -h 192.168.1.234 -p
3000 -s

However, if we run following command on client side then we notice that
none of the IP address is exchanged in INIT/INIT ACK messages and only
eth1 is part of association.  In this case multi-homing doesn't work and
eth1 cable pullout results into loss of association.

#sctp_darn -H 192.168.1.231 -P 3000 -B 193.168.1.231 -h 193.168.1.234 -p
3000 -s


Additional info:

Included are Ethereal traces for both cases.  First case trace is
eth0.trc while second case is eth1.trc.
Comment 1 Zdenek Prikryl 2008-09-17 11:19:21 EDT
That behaviour is not a bug but a feature. Look, when the client tries to connect to IP 192.168.1.234 he considers, that the server runs in private network and the multi-homing is established (IPs 192.168.1.231 and 193.168.1.231) with no problems. In both cases the server can send packet to the client, i.e. routers understand where to send such packets. But, when the client tries to connect to IP 193.168.1.234, he consider, that the server runs outside of private network. Private IP in packets may be replaced by NAT. So, he doesn't send private IP in INIT, because in fact, address is valid only inside private network, no any endpoints outside of that network can use those addresses (routers do not understand where to send such datagrams).

If you have the server and clients inside private network and you want to use the multi-homing, the client has to connect to private IP (192.* or 10,* or ...). If the client tries to connect to non-private IP, then all of private IPs in INIT packet will be removed.

Note You need to log in before you can comment on or make changes to this bug.