Related articles:

Note

This feature is only available for the virtual SP2000 (vSP2000) platform using IPv4 addresses or IPv6 addresses.

Multihoming, one of the key features of SCTP, is the ability of an association (that is a connection) to support multiple IP addresses or interfaces at a given end point in a network. In case of a network failure, use of more than one IP address allows re-routing of packets and provides an alternate path for retransmission. Therefore, the network address redundancy provides a certain level of network-level fault tolerance.

However, issues arise with multihoming when a network tries to connect to another network hidden behind a Network Address Translation (NAT).

A NAT is designed for IP address conservation. The NAT translates private IP networks that use unregistered IP addresses in the internal network into public routable addresses before packets are forwarded to another network.  In this way, the NAT conserves public addresses because it can be configured to advertise at minimum only one public address for the entire network to the outside world.

In multihomed associations, supplementary address parameters (part of SCTP payload, not the IP header) are included in certain messages. The NAT modifies IP addresses in the IP header only and is incapable of handling the parameters. As a result, the NAT does not modify the supplementary IP addresses in the SCTP, which either causes the association to continue in a single-homed manner or immediately fail.

To avoid this problem between the SCTP payload and NAT, a set of rules are required for translating and configuring the outgoing and incoming supplementary IPs.

The SCTP NAT mapping feature enhances the SCTP to accommodate multihomed associations whose endpoints reside behind NAT entities. Using a modification to the Linux kernel SCTP code, a user can configure two sets of vSP2000 SCTP NAT tables: egress and ingress.  The data from within the tables are used by the kernel to perform real-time supplementary address translation on egress and ingress SCTP packets. 

The egress table is a simple mapping of the vSP2000 node's private addresses (3.4.5.6 and 5.6.7.8) behind the local NAT to its public addresses (33.44.55.66 and 55.66.77.88), used when packets are transmitted from the vSP2000 node (see the following figure).  

SCTP NAT Egress example

 

Similarly, the SCTP NAT ingress table is a mapping of a customer's private addresses (2.3.4.5 and 4.5.6.7) to their respective public addresses (66.77.88.99 and 88.99.11.22), see the following figure. 

Note

When a customer sends an INIT handshake, the vSP2000 uses the ingress SCTP NAT table to reverse map the embedded IP addresses, so the vSP2000 node can correctly read the remote public IP addresses. This step allows the vSP2000 ingress SCTP NAT table to also provide a multihomed NAT functionality, indirectly, for customers whose SCTP implementations and/or NAT devices are incapable of providing this functionality themselves.

SCTP NAT Ingress example

 

The mapping only affects the IP Addresses in the SCTP payload, not the IP Addresses in the IP Header. In the preceding figures, notice that the vSP2000 SCTP includes the SCTP NAT within the SCTP application. Each VM gets its own mapping table that applies to all SCTP associations that terminate on that VM. 

Note

The mapping between internal and external IPs is fixed and does not depend on the SCTP port or association state.

To provision the SCTP NAT egress and ingress mappings, login to the Web UI as a root user and click IP Networking > SCTP NAT. The SCTP NAT section allows for all management operations for the SCTP NAT mapping. For more information on how to configure the SCTP NAT, refer to vSP2000 Adding SCTP NAT Table Entries.   

For an additional example of SCTP NAT multihoming configuration with multiple customers, refer to the vSP2000 Multihoming with NAT Support Configuration Example.