TMS zl Module Release Notes ST.1.1.100330

Known Issues

Release ST.1.0.090213

Expected Results: The module with priority set to one (original Mater) becomes Master again.

Actual Results: Device with lower priority joins the cluster as Master and the one with higher

priority joins as Participant.

At first glance, this seems to be incorrect, but it is actually done by design. It is assumed that

there is something wrong with the module that failed, for example, an intermittent problem. As

a result, once the link is rejoined, the module that was Master joins back as a participant (standby)

in an attempt to prevent any future issues.

■ PR_10844 — When a Participant joins or leaves a cluster, there is very little detail to the

log entries describing these important events and these events must be inferred.

■ PR_14506 — When an HA configuration is configured for Active/Standby and the Master

has IPS enabled and has downloaded the latest signature file, the Participant will not show

the correct version of the signature file. The actual signatures are synchronized correctly,

but the file name is not.

Example:

Precondition: Master and Participant already on a cluster

1. Download the signatures on the Master.

2. Wait until the Participant reboots and re-joins the cluster.

3. Run sh ips command on the Participant.

In the output, the Last Signature Download field appears as None even though the signatures

were synchronized.

■ PR_14823/14916 — When using the TMS zl Module CLI, the high-availability command lists

a rebalance option that is not valid for Active/Standby mode. In the Web browser interface

for High Availability, a rebalance button is also present.

■ PR_15913 — When using High Availability in Active/Standby mode, if the connection count

is high and the connection rate is high, the transfer of TCP state information between the

Master and Participant may be too large and it doesn't complete. Once the connection rate

or count drops, the state is transferred correctly. However, should a failover from the Master

to the Participant occur at the time when TCP state information cannot be sent, there will

be an additional failover delay as applications re-establish their TCP state with the

Participant (now the Master after the failover).

Monitor Mode Only

■ PR_5928 — When in Monitor Mode, a scan of the open ports will reveal TCP port 616 and

TCP port 9999 as being open. The only way to block these ports is to setup a firewall access

policy to restrict them.