Bug 462423
Summary: | SCTP multi-homing issue | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | schanda | ||||
Component: | lksctp-tools | Assignee: | Zdenek Prikryl <zprikryl> | ||||
Status: | CLOSED NOTABUG | QA Contact: | |||||
Severity: | urgent | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 4.4 | CC: | 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: |
|
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. |
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.