Bug 462423

Summary: SCTP multi-homing issue
Product: Red Hat Enterprise Linux 4 Reporter: schanda
Component: lksctp-toolsAssignee: Zdenek Prikryl <zprikryl>
Status: CLOSED NOTABUG QA Contact:
Severity: urgent Docs Contact:
Priority: medium    
Version: 4.4CC: schanda
Target Milestone: rc   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-09-23 11:38:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Etherael traces none

Description schanda 2008-09-16 05:32:00 UTC
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 15:19:21 UTC
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.