Troubleshooting Issues with the Critical Device "routed"

Background

The Critical Device A special software device on each Cluster Member, through which the critical aspects for cluster operation are monitored. When the critical monitored component on a Cluster Member fails to report its state on time, or when its state is reported as problematic, the state of that member is immediately changed to Down. The complete list of the configured critical devices (pnotes) is printed by the 'cphaprob -ia list' command or 'show cluster members pnotes all' command. Synonyms: Pnote, Problem Notification. called routed monitors the state of the Dynamic Routing on the Cluster Member Security Gateway that is part of a cluster. (see Viewing Critical Devices).

This Critical Device makes sure that traffic is not assigned to a Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. Member before it is ready State of a Cluster Member during after initialization and before promotion to the next required state - Active / Standby / VRRP Master / VRRP Backup (depending on Cluster Mode). A Cluster Member in this state does not process any traffic passing through cluster. A member can be stuck in this state due to several reasons. to handle the traffic.

The Gaia Check Point security operating system that combines the strengths of both SecurePlatform and IPSO operating systems. OS RouteD daemon handles all routing (static and dynamic) operations.

There can be an issue with Dynamic Routing with one or more of these symptoms:

• Cluster IP address connectivity problems

• Unexpected cluster failovers

• The state of the Critical Device routed is problem.

  Example:

  Device Name: routed Registration number: 2 Timeout: none Current state: problem Time since last report: 10 sec

These are some of the common causes of this issue:

• Cluster misconfiguration

• Traffic on TCP port 2010 between Cluster Members is blocked

• The RouteD daemon did not get all of its routes

• The RouteD daemon did not start correctly

Standard Behavior of the Critical Device "routed"

Typically, the Critical Device routed reports its current state as problem when:

• A Cluster Member fails over

• A Cluster Member reboots

• There is an inconsistency in the Dynamic Routing configuration on Cluster Members

the Critical Device routed reports its current state as OK when

• A ClusterXL Cluster of Check Point Security Gateways that work together in a redundant configuration. The ClusterXL both handles the traffic and performs State Synchronization. These Check Point Security Gateways are installed on Gaia OS: (1) ClusterXL supports up to 5 Cluster Members, (2) VRRP Cluster supports up to 2 Cluster Members, (3) VSX VSLS cluster supports up to 13 Cluster Members. Note: In ClusterXL Load Sharing mode, configuring more than 4 Cluster Members significantly decreases the cluster performance due to amount of Delta Sync traffic. member tells the RouteD daemon that it is a Master State of a Cluster Member that processes all traffic in cluster configured in VRRP mode.

• The RouteD daemon gets the entire routing state from the Master

Basic Troubleshooting Steps

1. Examine the cluster interfaces to make sure they are configured correctly.

   See Viewing Cluster Interfaces.

2. In ClusterXL High Availability A redundant cluster mode, where only one Cluster Member (Active member) processes all the traffic, while other Cluster Members (Standby members) are ready to be promoted to Active state if the current Active member fails. In the High Availability mode, the Cluster Virtual IP address (that represents the cluster on that network) is associated: (1) With physical MAC Address of Active member (2) With virtual MAC Address. Synonym: Active/Standby. Acronym: HA. mode, make sure that the RouteD daemon is running on the Active State of a Cluster Member that is fully operational: (1) In ClusterXL, this applies to the state of the Security Gateway component (2) In 3rd-party / OPSEC cluster, this applies to the state of the cluster State Synchronization mechanism. Cluster Member.

3. Make sure traffic on TCP port 2010 between the Cluster Members is not blocked.

4. Generate RouteD cluster messages.

   Run this command in the Expert mode on the cluster member:

   dbset routed:instance:default:traceoptions:traceoptions:Cluster

   Examine the /var/log/routed/log file.

5. In ClusterXL High Availability mode with the OSPF configuration, make sure the OSPF interface is up on the Standby State of a Cluster Member that is ready to be promoted to Active state (if the current Active Cluster Member fails). Applies only to ClusterXL High Availability Mode. Cluster Member.

6. In the OSPF configuration, look for a "router-id" mismatch.

For advanced troubleshooting procedures and more information, see sk92787.

For troubleshooting OSPF and the RouteD daemon, see sk84520.