One of the neat features of the Axway API Gateway is the ability to deploy it in a multi-homed environment, so that it is associated with multiple IP addresses. The requirement is for a single API Gateway to listen on multiple IP Addresses, on the same port (usually the SSL port: port 443).

This is often done because an organization wishes to deploy API Gateways virtually in multiple places on the network, while using the same server to run the API Gateways.

To do this, the first step is to associate the multiple IP Addresses with the machine running the API Gateway. In this example, we associate two IP Addresses (with two corresponding subnets): 192.160.0.10 and 10.10.1.10. This is done at the OS layer.

Next, we use Policy Studio to setup our two listeners, corresponding to the two zones (which we'll imaginatively call "Zone 1" and "Zone 2"):

Note where the IP addresses are configured above. Users of the API Gateway might be used to seeing an asterix ('*') in the "Address" field under the port configuration. The asterix means that the API Gateway binds to every IP address available on the machine. By specifying the IP address in the "Address" field, we are saying that the API Gateway will
only bind to this port for this listener.

Also notice above that both listeners are listening on the same port, which is the SSL port 443. Normally if you have two applications listening on the same port, there is a clash. But in this case, the API Gateway is listening on two ports on two different IP addresses.

Underneath our "Zone 1" and "Zone 2" listeners, we can associate different paths. So, https://192.160.0.10/myAPI will be handled under the "Zone 1" listener.

Notice also that different certificates can be used for the different listeners. The certificates themselves can be generated using the Axway
API Management solution (under "Certificates and Keys" in Policy Studio). If you have multi-homed your API Gateway to multiple addresses which are associated with multiple machine names (e.g. "apis.mycompany.com" and "internal.mycompany.com") then you can issue certificate within Policy Studio for these names, then load them using the "X.509 Certificate" button in the "Configure HTTPS Interface" screen above.