Determine whether your network is configured optimally for use of Luna Network HSM 7 appliances.
NOTE Always employ network security best practices. Place the Luna Network HSM 7 behind a firewall.
Bandwidth and Latency Recommendation
Bandwidth
>Minimum supported: 10 MB half duplex
>Recommended: at least 100 MB full duplex
•full Gigabit Ethernet is supported by default on all Luna Network HSM 7 7 appliances
•10 Gigabit Optical Ethernet is a Luna Network HSM 7 appliance factory-purchase option (i.e., not field upgradeable).
NOTE Ensure that your network switch is set to AUTO negotiation, as the Luna Network HSM 7 appliance negotiates at AUTO. If it is not, there is a risk that the switch and the appliance will settle on a much slower speed than is actually possible in your network conditions.
Network Latency
>Maximum supported: 500ms
>Recommended: 0.5ms
Latency and Testing Troubleshooting
Luna appliance client-server communication uses timeouts less than 30 seconds to determine failure scenarios. Thus the appliance does not tolerate network configurations or conditions that introduce a greater delay - problems can result, especially with High Availability configurations.
When you disconnect the network cable between any Luna appliance and a switch, and then reconnect, traffic should resume immediately, but with certain network switch configurations it might take 30 seconds for traffic to resume. The problem here is at the switch (not the Luna appliance).
If the switch is configured to run the Spanning Tree Protocol on the port, then there is a delay of about 30 seconds while it runs through a series of discovery commands and waits for responses. The switches can be configured to run in “PortFast” mode in which the Spanning Tree Protocol still runs on the port, but the port is placed directly into 'forwarding mode' and starts the traffic flowing immediately.
With the switch introducing a connection detection delay of 30 seconds or greater, transient network failures lasting only seconds are no longer tolerated. A simple test is to set up a ping stream and then disconnect and reconnect the network cable. The ping traffic should resume after a 1 or 2 second delay. A greater delay indicates that a switch in the network is not detecting the reconnection as quickly as is optimal. See the recommendations for network Bandwidth and Latency.
KeepAlive Setting
The Network Trust Link Service uses a keepalive function on the TCP layer, to maintain awareness of the link in low-traffic situations. The intent is to allow the Network HSM appliance to detect a dead peer (client) and respond appropriately. Response is invoked in situations where the client TCP stack has no opportunity to send a TCP reset to the NTL service on the Network HSM, like:
>client is powered down, or
>a network outage occurs
In such a situation, if ntls tcp_keepalive is set, then the NTL service (on the Network HSM appliance) recognizes a dropped connection after
(idlevalue + (intervalvalue x probesvalue)) / 60 = minuteswaiting
In the same situation without ntls tcp_keepalive enabled, a disconnected client would not be detected by NTLS (on the appliance) and the connection would be held in a Close_Wait state until NTL service was restarted.
How to decide
Many customer use-cases involve opening a session for a brief cryptographic operation or series of operations, and then closing the session. In such cases, the default values for the keepalive function are appropriate.
In the event that your application opens sessions that remain idle for long periods, with occasional bursts of activity, consider using the ntls tcp_keepalive set command with recommended values like these:
lunash:> ntls tcp_keepalive set -idle 200 -interval 150 -probes 15
Otherwise, set whatever values work best for your application's behavior/requirements and your anticipated network conditions.
