Feature #3608

Support for SCTP multi-homing

My humble assumption here is that this is done entirely in the kernel. It will automatically learn about the peers' additional addresses anduse them as needed.

In OsmoSTP, the VTY would have to allow for manual specification of multiple IP addresses for each peer, so that during start up all ofthose addresses are attempted (think of the case where the normal/primary address is unreachable at link-bringup time). After the association is up, SCTP exchanges information about the additional IPs dynamically.

The actual switch between using the addresses is entirely done in the kernel, we just get notifications (SCTP_PEER_ADDR_CHANGE) about this andcan log them.

History

My humble assumption here is that this is done entirely in the kernel. It will automatically learn about the peers' additional addresses anduse them as needed.

In my experience the kernel will need a bit of help before the multi-homing works as we expect it to.

Consider a scenario where the STP runs on a server with 4 IPs (A, B, C and D). A and B are used for signaling, but C and D are firewalled and used for OAM/local SSH logins.

If we open a multi-homed SCTP connection to another host with kernel defaults, then the kernel (not knowing about our overall network design) will associate all 4 IPs (A, B, C and D) with this connection.

As a consequence, the peer will successfully communicate with our IPs A and B - but endless try (and fail) to communicate with our IPs C and D.

Therefore it can make sense to explicitly specify:1. Which peer IPs this SCTP association connects to2. Which IPs we bind on our end of the SCTP association

This explicit binding of IPs on our side can done by using sctp_bindx() on the fd before calling sctp_connectx().