The NETWORK Configuration is used to set up servers that are being managed and servers that are managing other servers. It can also be used to set up the routing of data traffic.
Node using TCP/IP connection.
IP address of the node. Wild cards (* and ?) can be used in the node IP address string. Host name is not supported.
HPE NonStop node using HPE NonStop IPC connections.
HPE NonStop server name. No Wildcards are supported. Prefix the <server-name> with a backslash (\).
Constraints for ALLOW/DISALLOW CONNECTION and NONSTOP-CONNECTION
The Allow/Disallow logic is the same as the SECURITY Confivuration grant/revoke statements and applies only to incoming connections.
By default (if no Allow/Disallow statements are added) all connections are allowed.
ALLOWS’ by themselves will implicitly DISALLOW all other connections.
DISALLOW’s by themselves will implicitly ALLOW all other connections.
This means that you can work in either a positive or negative authorization approach. A combination of ALLOW’s and DISALLOW’s is more explicit as it forces that a connection must be allowed and not disallowed.
Any ALLOW statement for remote nodes will automatically DISALLOW the 'local' node, therefore an ALLOW statement should also be added for the local machine, e.g.
ALLOW CONNECTION (<local-node-ip-address>, UI)
ALLOW NONSTOP-CONNECTION (\<local-node>, UI)
Backward compatibility. If an older node connects from a disallowed IP address, the node connect request will be rejected and it will attempt to reconnect.
Disallow connection dynamically for the already connected nodes, by restarting the NETWORK configuration is supported.
Restarting the NETWORK Configuration with newly allowed connections will not create connections from nodes that have been previously rejected. However, restarting the NETWORK Configuration of those other nodes will cause them to re-attach their connections.
This is used to allow unencrypted connections to HPE NonStop, AIX or HP-UX servers, for further information see Encryption of Inter-Node Traffic.
Effective from version 11.0, this statement is only supported on a HPE NonStop, AIX or HP-UX servers. See Encryption of Inter-Node Traffic.
The FORCE-FIPS-ENCRYPTION () statement can be used on platforms that support the FIPS certified OpenSSL library. By adding/enabling this statement it will enable FIPS certified encryption for Network Router communications.
For details of the FIPS functionality please refer to the Data Encryption Between Servers.
This is used to statically configure a connection to a remote IRNETRTR. The target node, if connected, will be managed from the node with this token configured. Using this entry, the Managing node and each Managed node can see all machines that have been named with this entry on the Managing node.
Note the port must be the same on all nodes that wish to connect, unless a specific port is appended. The values in this entry can be specified as node names or IP addresses.
Specifies one or more nodes that will manage this node. The values in this statement can be specified as either node names or IP addresses. TCP connections are initiated to each of the nodes specified. Using this entry, the named managing node(s) can view all nodes that have this same entry added to their NETWORK Configuration, whilst each individual node can only view itself. Adding Managing-Nodes will turn off Multicast discovery.
Used for Multicast Node Discovery. It is the Multicast Group address that we listen on and multicast to. It must be in the range 22.214.171.124 to 126.96.36.199. It must be the same on all nodes. See Auto-Discovery.
A value of (NONE) indicates that Multicast discovery will not be performed.
The default is 188.8.131.52
Used for Multicast Node Discovery. It is the Interface IP address that will be used for Multicast Group multicasts. It is required where a Node has multiple Interfaces (for example, LAN Cards or Controllers). See Auto-Discovery.
A value of (NONE) indicates that Multicast discovery will not be performed.
Behaves the same as MANAGING-NODES. The values in the NONSTOP-MANAGING-NODES entry specify HPE NonStop node names and indicate that HPE NonStop IPC connections should be established to those HPE NonStop nodes. The node name values are case insensitive.
This entry only takes effect on HPE NonStop systems. The entry will not be evaluated on non-HPE NonStop systems, although its existence on non-HPE NonStop systems indicates auto-discovery via multicast is disabled.
Enables routing to a managing node using a specified route metric.
Valid Prognosis Server name.
The input range is 1 to 15 with a default value of 1.
For details of this functionality please refer to the Multi-Domain Management Configuration.
This statement is used for the Database Collection 'Store and Forward' facility (SAF) which applies when collecting data from one or more remote servers. The purpose of SAF is to store collected data temporarily on a remote server in the event that Prognosis service is shutdown 'warm' on the collecting server or a communication link goes down. In these cases, subsequent data intervals from the remote server will be stored on the remote server until Prognosis is restarted or the communication link is re-established, the data will then be forwarded through to the collecting server automatically. The SAF-SIZE statement can be added to the NETWORK Configuration of each remote server in order to set the amount of data that can be stored on that server, if the SAF-SIZE is not specified the size will default to 8 MB.
Name of the collecting server, i.e. where the database is located. One or more collecting servers can be specified, however, only the first matching entry will apply. The <server-name> can also be specified as *, meaning all servers.
Maximum amount of data hat can be stored on the remote node. This figure should be based on the maximum outage duration that is to be handled, multiplied by the average amount of data per interval flowing to all database collections on the collecting node. Maximum size is 2047 (i.e. 2GB).
Allows groups of nodes separated by non-multicast routers (or routers configured to not propagate multicast packets) to discover each other with a small amount of user configuration. This form of discovery can result in all nodes knowing of all other nodes. To discover systems on other subnets, at least one node on each subnet needs to be configured to connect to (at least) one node on each of the other subnets. The underlying TCP/IP protocols are used for communication.
For this mechanism to result in all nodes having knowledge of each other, each subnet must have a Level 2 node. Subnets containing only HPE NonStop nodes cannot be fully discovered via this mechanism. See Auto-Discovery.
Specifies the name(s) of the TCP/IP process(es) through which a Windows Client session may be established. For HPE NonStop the default process name is $ZTC0.
Base port used to communicate with other nodes, the default port is 1960.
The base port number and the next six ports are reserved for use. See the Port Requirements for full details.
On platforms other than HPE NonStop, it is not recommended to change the TCPIP-PORT setting while Prognosis is running. The TCPIP-PORT setting affects communication between all Prognosis processes and any changes to this setting will take effect only when a process is started. If the TCPIP-PORT setting is changed while Prognosis is running, new Prognosis processes that start may have a different TCPIP-PORT setting to other Prognosis processes and will be unable to communicate. This includes control interfaces, such as the IRSHUTDN program, which will be unable to shutdown Prognosis.
For this reason, it is recommended to only update the TCPIP-PORT setting while Prognosis is stopped. To update the port setting use the following options:
- On all platforms, the IRCNFUTL program may be used to list and update the NETWORK Configuration while Prognosis is stopped. See Configuration using IRCNFUTL for details.
- On UNIX, use the 'portprog' command (this will also stop the Prognosis service). If the TCPIP-PORT setting is changed while Prognosis is running, immediately shutdown and restart Prognosis on the affected node(s).
A restart of Prognosis is required if the modification of any statement results in a move from Auto-Discovery to Non Auto-Discovery, or vice versa.
The following statements require Prognosis service to be restarted for changes to take effect:
Additions or deletions of the following statements generally require only the NETWORK Configuration to be restarted, as long as the rule stated above is not invoked: