The following figure displays a multihomed association with a DSC/vSP2000 node and two customer nodes, all with NATs. 

Note

The following example uses a client-server scenario with the DSC endpoint acting as the server; however, the functionality is also similar to the scenario where the DSC endpoint acts as the client, and also a peer-to-peer scenario.

This example shows the initial establishment of a new association; however, the functionality is also similar to other scenarios that use embedded supplementary address parameters.


SCTP NAT Multihomed Example (Also applies to vSP2000)

In the preceding diagram, if Customer A attempts to initiate a multihomed association with the DSC node, then the 2.3.4.5 and 4.5.6.7 addresses will be included as a supplementary addresses within the INIT message. Similarly, the DSC node will include 3.4.5.6 and 5.6.7.8 as supplementary addresses within the INIT-ACK message response. Since these supplementary address are private intranet addresses behind their NATs, communication on these addresses will either fail or the association will continue in single-homed manner.

The preceding diagram also show that Customer B has the same private IP addresses as Customer A. If Customer B attempts to establish an SCTP association with the DSC node, this could lead to an immediate failure because of the conflicting nature of the addresses from the DSC node's perspective, or it could lead to ambiguity in message delivery to the two remote customers.

To avoid these scenarios, the DSC SCTP NAT tables for this example are configured as follows:

Kernel SCTP NAT Egress Table example

Local Private IPLocal Public IP
5.6.7.855.66.77.88
3.4.5.633.44.55.66

Kernel SCTP NAT Ingress Table example

Remote Source IPRemote Private IPRemote Public IP
22.33.44.554.5.6.744.55.66.77
44.55.66.774.5.6.744.55.66.77
66.77.88.994.5.6.788.99.11.22
88.99.11.224.5.6.788.99.11.22
22.33.44.552.3.4.522.33.44.55
44.55.66.772.3.4.522.33.44.55
66.77.88.992.3.4.566.77.88.99
88.99.11.222.3.4.566.77.88.99
Note

Since different remote entities behind different NAT devices may have the same private IPs, an additional field is required to resolve any ambiguity: the IP header source address of the ingress packet.  This is necessary to distinguish between multiple customers who may have configured their nodes with identical private IP addresses, as is the case between Customer A and Customer B.

After the SCTP NAT tables are properly configured, the message flow between the customer and the DSC node will proceed as follows:


Note

The columns A, B, C and D correspond to the preceding network diagram.


The green and red translations correspond to standard (legacy) NAT functionality at the DSC and customer sites respectively.  The yellow translations correspond to the SCTP NAT functionality. 

Using the SCTP NAT functionality, Customer A and the DSC node are aware of each other's public IP addresses, with the associated translation occurring transparently. 

When Customer B sends an INIT message using identical private IP addresses as Customer A, the DSC node will be able to distinguish between the two because of the different remote public addresses.

Note

All changes to the ingress and egress tables utilizing the Web UI remain persistent through reboots and the files are synced across all applicable VMs with routing functionality.