The host on which the GridFTP door is running has several network interfaces and is supposed to accept client connections via all those interfaces. The interfaces might even belong to separate networks with no routing from one network to the other.

As long as the data connection is opened by the GridFTP server (active FTP mode), there is no problem with having more than one interface. However, when the client opens the data connection (passive FTP mode), the door (FTP server) has to supply it with the correct interface it should connect to. If this is the wrong interface, the client might not be able to connect to it, because there is no route or the connection might be inefficient.

Also, since a GridFTP server has to authenticate with an SSL grid certificate and key, there needs to be a separate certificate and key pair for each name of the host. Since each network interface might have a different name, several certificates and keys are needed and the correct one has to be used, when authenticating via each of the interfaces.

Start a separate GridFTP server cell on the host for each interface on which connections should be accepted.

The cells may be started in one domain or in separate domains. The cells have to have different names, since they are well known cells. Each cell has to be configured, only to listen on the interface it should serve with the -listen option. The locations of the grid host certificate and key files for the interface have to be specified explicitly with the -service-cert and -service-key options.

The following example shows a setup for two network interfaces with the hostnames door-a.grid.domain (111.111.111.5) and door-b.other.domain (222.222.222.5) which are served by two GridFTP door cells in one domain:

set printout default 2
set printout CellGlue none
onerror shutdown
check -strong setupFile
copy file:${setupFile} context:setupContext
import context -c setupContext
check -strong serviceLocatorPort serviceLocatorHost
check -strong sshPort ftpPort
create dmg.cells.services.RoutingManager  RoutingMgr
create dmg.cells.services.LocationManager lm \
       "${serviceLocatorHost} ${serviceLocatorPort}"

create dmg.cells.services.login.LoginManager GFTP-door-a \
            "2811 \
	     -listen=111.111.111.5 \
             -export \
             diskCacheV111.doors.GsiFtpDoorV1 \
             -prot=raw \
             -service-cert=/etc/grid-security/door-a.grid.domain-cert.pem \
             -service-key=/etc/grid-security/door-a.grid.domain-key.pem \
             ..
             ..
"

create dmg.cells.services.login.LoginManager GFTP-door-b \
            "2811 \
             -listen=222.222.222.5 \
             -export \
             diskCacheV111.doors.GsiFtpDoorV1 \
             -prot=raw \
             -service-cert=/etc/grid-security/door-b.other.domain-cert.pem \
             -service-key=/etc/grid-security/door-b.other.domain-key.pem \
             ..
             ..
"

This batch file is very similar to the batch file for the GridFTP door in the standard setup. (Comments have been left out.) It only contains an additional create command for the second cell and the emphasized changes within the two create commands: The cell names, the -listen option with the IP address of the corresponding interface and the -service-cert and -service-key options with the host certificate and key files.