This article describes the IP connectivity required for the NetYCE servers. This information is essential to determine the access permissions that should be granted between the various environments (access-lists, firewalls).

The specific portnumbers that are used between the users, the servers and the network depends to a large degree on the NetYCE architecture deployed. Since the architectures can largely be divided into three basic configurations, single server, high-availability, and multi-tier, the required connectivity is presented using these setups.

Each arrow indicates the where the call setup originates, the portnumbers used in these connections are listed beside the arrow.

When the portnumber is listed between brackets, these are either optional, or only used for testing or maintenance. The purpose and usage of each portnumber is given in the legend at the bottom of this article.

The single-server setup is for small, non-critical deployments and for development / test / acceptance environments.

In the High-availability setup, two servers providing all functions are working in tandem providing load-balancing and hot-switchover functionality. The databases are configured for master-master replication which is continually monitored to allow for immediate switchover to the secondary. (Fallback to primary will not take place until the databases are back in sync.)

This setup is recommended for all larger deployments that are deemed critical and where the NetYCE servers are located in relatively well protected environments (isolated from public or insecure networks).

In the multi-tier setup, the databases are separated from the user and network facing components allowing for either better database performance and security zoning. The front-end servers are configured to connect to a primary and secondary database as is desired by the design.

Up to seven Front-end servers are supported where some can be made dedicated to a specific network or share the load of networking change jobs. Front-end servers can be configured to provide only access to the web-GUI, but are not connected to the targeted network.

Note: This functionality requiring the use of the 'distributed scheduler' is currently under development and is targeted for the 7.1 release

Up to two (master) databases can be deployed using the master-master replication, and additional slaves (read-only) are optional.

Unless specified otherwise the protocol used is TCP.