What is Socket High Availability (HA)

Socket HA sites can use two Sockets with the same Socket type X1500, X1600, X1600 LTE, or X1700. However, you can't use different Socket types, so a site with an X1600 and an X1700 Socket is not supported.

You can't use an X1600 Socket and X1600 LTE Socket in the same HA site.

The following diagrams show an example of an issue in the primary Socket that causes a failover to the secondary Socket. When the secondary Socket discovers that the primary Socket is down, it then changes its status to Master. The Cato Cloud transfers the traffic flows to the WAN links in the secondary Socket.

A split-brain condition is when both Sockets have the Master role at the same time. This can happen due to a LAN connectivity problem between the Sockets that creates a situation where the HA keepalive messages do not reach the secondary Socket.

You can identify a split-brain condition by checking the Socket page (shown above) in the Cato Management Application.

After the LAN connectivity issue is resolved, the secondary Socket identifies that the primary Socket is the Master and the secondary Socket returns to Stand-by status.

There are configurations that use a single LAN port to connect the primary and secondary Sockets to the LAN switch. With this configuration, the same port number must be used on both Sockets. The user traffic and the HA keepalive messages run over a single link. This topology doesn’t provide LAN link redundancy.

The following diagram shows a sample Socket HA topology with a single LAN port on each Socket connected to a switch:

This section discusses when both the primary and secondary Sockets are connected to the LAN switches via two or more independent LAN ports. With this configuration, the same ports must be used on both Sockets for the LAN connectivity.

By default, the LAN port with the lowest number is used both for the HA keepalive traffic and for the user traffic. The remaining LAN ports carry only the user traffic.

You can choose any LAN port for the HA keepalive traffic by changing the port Destination from LAN to LAN & VRRP.  The following screenshot shows port 3 for LAN user traffic and port 4 for the HA keepalive traffic and for the user traffic.

For more about changing the LAN port for HA keepalive traffic, see Using Sockets in a High Availability (HA) Deployment. This topology doesn’t provide LAN link redundancy.

Socket HA failover (where the secondary Socket becomes the Master) only occurs when both of these conditions are met:

If the Secondary Socket LAN port is DISCONNECTED, it will not become the Master to avoid a possible split-brain condition.

Both the primary and secondary Sockets are connected to the LAN switches via two or more LAN ports bundled in a link aggregation (LAG).  With this configuration, the same ports must be used on both Sockets for the LAN connectivity. This topology provides LAN links redundancy both for the user traffic and for the HA keepalive messages. If one of the LAG member ports fails, the other member ports will continue to carry the user traffic and the HA keepalive traffic.

This topology provides both link resiliency and Socket resiliency and is considered a best practice.

To learn more about LAN LAG, see Configuring Link Aggregation for a Socket.

The following diagram is an example of Socket HA LAN connectivity topology using a LAN LAG with a stack of switches:

In this configuration, you isolate the HA keepalive traffic from the LAN traffic. You can allocate a single port (LAN, WAN, or USB ports) only for the HA keepalive traffic while using one or more remaining LAN ports for the LAN traffic.

To set the dedicated LAN port for the HA keepalive traffic, set the Destination for the port to VRRP. Then set the HA link between sockets option to Direct or Via Switch.

These are the dedicated port configurations:

These are diagrams of the direct and via switch dedicated port configurations:

This failover scenario is caused by a failure to the primary Socket. The Socket is considered as being in a down state based on one of these reasons:

There is also a failover scenario that is caused when the secondary Socket does not receive keepalive messages from the primary Socket for a period of three seconds.

When the secondary Socket discovers that the primary Socket is down, it then changes its status to Master. The Cato Cloud transfers the traffic flows to the WAN links in the secondary Socket. The following diagram shows this scenario.

The Sockets use a probing mechanism to determine the Internet connectivity status. If the primary Socket determines that Internet connectivity is down on all the Internet links (Cato links) for more than 10 seconds, then it stops transmitting the HA keepalive messages. This causes a failover to the secondary Socket.

There are different pages in the Cato Management Application that show the status of the Socket HA for a site.

Whenever a Socket failover occurs, when the secondary Socket is active for more than 35 seconds, then a ​Socket Fail-Over​ event is generated. For example, if the primary Socket upgrades to a new Socket version, and the upgrade process takes 20 seconds, then a ​Socket Fail-Over​​ event is NOT generated because the secondary Socket was only active for 20 seconds.

You can see the event In the Cato Management Application in the Monitoring > Events page. Here is a sample event showing a failover from the primary to the secondary Socket.