Sometimes the SCTP stack in a multi-homed environment receives a DATA chunk over one path but replies to it with a SACK (+ DATA chunk) over another path. This is in slight contrast with RFC 4960 which has the following to say in this regard (note that is is a SHOULD not a MUST):
An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, etc.) to the same destination transport address from which it received the DATA or control chunk to which it is replying. This rule should also be followed if the endpoint is bundling DATA chunks together with the reply chunk. However, when acknowledging multiple DATA chunks received in packets from different source addresses in a single SACK, the SACK chunk may be transmitted to one of the destination transport addresses from which the DATA or control chunks being acknowledged were received. When a receiver of a duplicate DATA chunk sends a SACK to a multi- homed endpoint, it MAY be beneficial to vary the destination address and not use the source address of the DATA chunk. The reason is that receiving a duplicate from a multi-homed endpoint might indicate that the return path (as specified in the source address of the DATA chunk) for the SACK is broken.
Packets are observed going out the wrong path even in situation not covered by the exceptions above (i.e. no duplicates and not SACKs of multiple DATA chunks coming over multiple paths). This situation usually happens with non default SCTP parameters, tuned to obtain faster switch-overs.
- Red Hat Enterprise Linux
- Multi-homed SCTP environment
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.