Cato Networks Knowledge Base

Monitoring Your Site with Connectivity Alerts

  • Updated

Overview of Connectivity Alerts

The Cato Management Application lets you receive alerts by email whenever there is a change in the network connection state. By creating a Health Rule, you can configure what types of connectivity alerts you want to receive. The Health Rules are supported for all types of connections: Sockets, IPSEC, and VPN users. We strongly recommend that you use connectivity alerts to monitor your site connectivity and provide the best network experience.

This article describes the types of alerts and how to enable the connectivity alerts. 

Example of a Connectivity Event and the Generated Alert:

In this example, one of the interfaces disconnects as shown in the following image:

diagram.png

The disconnection event generates a connectivity alert that is sent to the user by email, as shown in the following image:

alert1.png

Connectivity Health Alert Structure

The connectivity alert contains the following information:

  • Site status
    • Site – the site name.
    • Status - Status of the entire site considering all site interfaces.
  • Interface status
    • Interface Name – The name of the interface.
    • Status – Status of the WAN interface.
    • Time – the time that the connectivity event occurs.
    • PoP – the PoP that the interface is connected to.
    • Precedence – the interface precedence, which determines the priority in which these interfaces are used. The lower number has higher precedence.
    • Socket S/N – Socket serial number.

The following image shows an example of a connectivity alert:

connected1.png

Overview of Sites with Multiple Links

  • Active link: an active tunnel that sends packets to the Cato cloud over a physical link.
  • Passive link: a physical link that doesn’t send packets over a tunnel to the Cato Cloud. In case of a failover when the active link goes down, the passive link becomes active.
  • Active-Active: deployment with 2 physical links that have connected tunnels and both of them are sending packets to the Cato Cloud. In Active-Active, both links are configured with the same precedence.
  • Active-Passive: deployment with 2 physical WAN links that only 1 link is active and sends packets over the tunnel to the Cato Cloud. The second WAN link doesn’t send packets and acts as a backup in case of a failover. In Active-Passive, the Socket links have different precedence. The active link has higher precedence than the passive link.

Overview of Connectivity Alerts Types

The following list describes the types of connectivity alerts for Socket sites:

  • Connected: This alert is generated after a tunnel is connected to the PoP for 30 seconds. In case that the Socket connects with 2 different interfaces, 2 Connected alerts are generated. Note: The Connected alert is always generated regardless of the configured Health Rules.
  • Disconnected: This alert is generated after the tunnel to the PoP is disconnected for more than 2 ½ minutes.
  • Partially Disconnected: This alert is generated when at least one tunnel disconnects while some of the tunnels are connected. It is relevant for deployments with at least 2 interfaces with the same precedence. For example: Active/Active or Active/Passive/Passive.
  • Partially Connected: This alert is generated when at least one tunnel connects while some of the tunnels are disconnected. It is relevant for deployments with at least 2 interfaces with the same precedence. For example: Active/Active or Active/Passive/Passive.
  • Failover: This alert is generated when there is a failover between two WAN links. In case that the active link is down, there is a failover to the passive link and the passive link becomes active.

In case that the failover is from the primary interface (with the higher precedence) to the secondary interface (with the lower precedence), the following alert is generated: “Failover to secondary”.

In case that the failover is back from the secondary interface to the primary interface, the following alert is generated: “Failover to primary”. This failover alert is generated after at least 10 minutes from the first failover.

  • Passive Disconnected: This alert is generated when the passive WAN link is disconnected. It is relevant for deployments with at least 2 interfaces with different precedence.

Usually, the passive link is the link with the lower precedence but there are cases, such as in a failover from WAN1 (precedence 1) to WAN2 (precedence 2), that the link with the lower precedence (precedence 2) becomes active.

  • Passive: This alert is generated when the passive WAN link is connected. It is relevant for deployments with at least 2 interfaces with different precedence.

If the passive disconnects and reconnects again, the passive connected alert is generated again and there is no passive reconnect alert.

Enabling Connectivity Alerts

We recommend that you create a Connectivity Health Rule, In the Cato Management Application so that you start getting the connectivity alerts.

The following image shows an example of a Health Rule:

rule5.png

For creating Health Rules, see Working with Health Rules.

Whenever there is a change in the connectivity status, an event is generated and if it matches the Health Rule, an alert is sent to the members on the Mailing List.

For creating a Mailing List, see Creating Mailing Lists.

You can see the events in the Cato Management Application in Analytics>Events.

The alert Icon in the following image indicates that an alert is generated based on the event:

warning.png

Examples of Connectivity Events

This example shows events of disconnection and connection:

1. Disconnected event. The following image shows an example of a disconnected event of interface WAN1: disconnected_ev.png

Interface WAN1 disconnects and the event is generated after the link is down for more than 2 ½ minutes.

2. Connected event. The following image shows an example of a connected event of interface WAN1: connected_ev.png

Interface WAN1 connects. The connection event means that the connection is established at least 2 ½ minutes after the disconnect.

This example shows the event of a reconnection:

The following example shows a reconnection event that indicates a disconnection and a connection within 2 ½ minutes.

1. Reconnected event. The following image shows an example of a Reconnection event of the WAN1 interface: reconnect_ev.png

Interface WAN1 reconnects. The reconnection event means that the reconnection is established in less than 2 ½ minutes after the disconnection.

This example shows the event of 2 fail-overs:

The following example shows a scenario of 2 fail-overs. One failover from interface WAN1 to interface WAN2 and the second failover is back from interface WAN2 to interface WAN1. When the first failover occurs, the Failover event is generated. During the failover, interface WAN2 becomes active and interface WAN1 becomes passive. Immediately after the failover, WAN1 connects again, and the Passive Connected event is generated. The second Failover event is generated after 10 minutes to verify that the link is stable again. During the second failover, WAN1 becomes active and WAN2 becomes passive. Immediately after the failover, WAN2 connects again, and the Passive Connected event is generated.

1. Failover event. The following image shows an example of a Failover event from WAN1 to WAN2:

failover1_ev.png

2. Passive Connected event. The following image shows an example of a Passive Connected event of WAN1:

passiveConnected_ev.png

3. Failover event. The following image shows an example of a Failover event from WAN2 to WAN1:

failover2_ev.png

4. Passive Connected event. The following image shows an example of a Passive Connected event of WAN2:

passiveConnected1_ev.png

Was this article helpful?

2 out of 3 found this helpful

Comments

0 comments

Please sign in to leave a comment.