The Socket is responsible for both WAN and Internet traffic. You can assign each one of the WAN Socket’s interfaces to connect to a different ISP (Internet Service Provider) or MPLS over the last mile. This article focuses on the Socket deployment options and explains the relevant transport mechanism.
Working with Socket Interfaces and Precedence
The Cato Socket deployment defines how traffic is sent over the links. Use the Cato Management Application to configure the precedence for each Socket link to select the deployment for the site. These are the available deployments:
- Active/active – both links with the same precedence for load balancing
- Active/passive – both links with different precedence for redundancy
- More than two links – two or three different precedence for both load balancing and redundancy
For more about configuring precedence, see Configuring the Ports for X1500 and X1700 Socket Sites.
Active / Active – Interfaces with the Same Precedence
In active/active deployments, there are two active links that maintain DTLS tunnels to the Cato Cloud and both pass traffic, both links are connected to the same PoP. The Socket routes the traffic over the links based on the configured network policy. If there is a problem with one link, the Socket transfers the traffic to the other link, and keeps the flows alive and connected. Cato recommends implementing the active/active for two links deployments. In the Cato Management Application, both links are configured with the same precedence – 1 (Primary). The following diagram shows a Socket connected to the Cato Cloud with two active links:
Active / Passive – Interfaces with Different Precedence
When a Socket is configured for an active/passive deployment, the active link (primary) is the only link that passes the traffic while the passive link (secondary) is for backup. Whenever there is a failover, the Socket keeps all the flows alive and connected: the secondary link becomes active and passes the traffic instead of the primary link. Despite the fact that only one link is active, the two links maintain live DTLS tunnels to the PoPs to provide a faster recovery time during failover. The passive link sends keepalive messages to maintain a live tunnel with the PoP.
Note: The traffic over the passive link is used for monitoring link quality and performing PoP connectivity checks. If you use the passive link with an expensive LTE WAN links, the traffic affects the consumed bandwidth over that links.
In the Cato Management Application, one link is configured with a higher precedence 1 (Primary) for the active link, and a lower precedence – 2 (Secondary) for the passive link. The following diagram shows a Socket connected to the Cato Cloud with one active link and one passive link:
Working with More Than Two Links
For deployments where you have three links for transport, you can implement an active/active/active or active/active/passive deployment. For example in active/active/passive, two active links connect to different ISPs and a passive link connects to 4G/LTE network. If the active links are disconnected or exceed the link quality thresholds, the Socket then fails over to the passive link.
For this deployment, the precedence for the Socket interfaces in the Cato Management Application are configured with two active links with the same higher precedence – 1 (Primary) and the passive with a lower precedence – 2 (Secondary).
The following diagram shows one Socket with two active links and one passive link connected to the same PoP in the Cato Cloud:
Understanding Active/Active Deployment
One of the Socket’s challenges in active/active deployments is to avoid a connection flow to split between the two links. In order to do that, the Socket uses the stickiness method and distributes the traffic over the two active links based on flows instead of individual packets. Each flow is a network connection based on the following five-tuple that allows flows to stick with the initially chosen tunnel: source IP address, source port number, destination IP address, destination port number, and the protocol. When packets of a flow arrive to the Socket, they are sent over the same tunnel that was used when the flow was created. For more information about traffic distribution, see Active-Active Traffic Distribution.
For active/active deployments, the Socket considers both DTLS tunnels as one Multi-Tunnel. The Multi-Tunnel is a logical tunnel that holds all the information about the flows. If one tunnel disconnects, the Socket quickly restores the connection with the other tunnel and there is no impact for the end-user.
The Link Failover Settings window in the Cato Management Application lets you configure custom settings for the active/active failover policy. You can change the default acceptable thresholds of packet loss, latency and jitter.
When Does the Socket Move Between Interfaces?
This section describes the cases when the Cato Socket decides to move the flows from one active link to another:
The Socket fails over to the other active link if it identifies that the tunnel is disconnected, either because there is 100% packet loss, or the Socket doesn’t receive responses for the keep-alive messages. The Socket then waits a timeout of 12 seconds and only afterwards it moves all the flows to the other active link. This behavior is similar for active/passive deployments.
In the case that the Socket identifies that the physical interface is disconnected, for example if the network cable is unplugged, it immediately moves all flows to the other active link. Then the Socket fails over to the other active link until the connection is restored.
The Socket checks periodically for a better transport by calculating a score based on the health metric for each of the available transports. The metrics for the quality thresholds are: packet loss, latency and jitter. If a different transport has a better score, this means that the other link is a better transport option. The Socket then moves the flow to the link with the better transport.
Understanding Active/Passive Deployment
The active/passive deployment provides redundancy for your network traffic. This section describes how the Cato Socket transfers traffic over the primary interface and when does it fail over to the secondary interface.
Failing Over to the Passive Link
During a link failover, the Socket disconnects all the flows from the link with the higher precedence and moves them to the link with the lower precedence. Despite the fact that interface disconnects, the Socket ensures that any existing flows are not discarded, and traffic is transferred over the secondary link.
When Does the Socket Fail Over?
The Socket fails over from the active to the passive link if the tunnel is disconnected, or the link can’t maintain the configured minimum quality.
This behavior is the same as for active/active deployments.
Poor Link Quality
The poor link quality is when the link exceeds the quality thresholds, as described above, for the entire duration of the setting. For example, the default setting is one minute, this means that link quality exceeds the threshold for the entire 60 seconds. Then, the Socket disconnects all the existing flows and moves them to the secondary link.
Falling Back to the Active Link
Fallback behavior is implemented when the connection or the link quality is restored. The primary link is active again and the Socket moves all the flows from the secondary link back to the primary link. Any new flow is established over the primary link and the secondary link becomes passive again.
The active/passive fallback behavior is designed to always fall back to the primary link, and the secondary link is designated as a backup. One advantage of this behavior is that the Socket minimizes the use of the secondary link. For example, when the primary link is connected to the Cato Cloud and the secondary is connected to a 4G/LTE cellular network for redundancy. When the primary link is down, the Socket fails over to the cellular link. Once the primary link restores, then the Socket falls back and stop using the 4G/LTE network.
Continue reading Part 2 Network Rules within the Socket.