OSPF neighbor(s) down-checkpoint-gaia,ipso

OSPF neighbor(s) down-checkpoint-gaia,ipso
0

OSPF neighbor(s) down-checkpoint-gaia,ipso

Vendor: checkpoint

OS: gaia,ipso

Description:
Indeni will alert if one or more OSPF neighbors isn’t communicating well.

Remediation Steps:
Review the cause for the neighbors being down.

How does this work?
The status of OSPF neighbors is monitored using clish command “shwo ospf neighbors”.

Why is this important?
Due to the dynamic nature of OSPF, it should be closely monitored to verify that it is working correctly. Since routing is a vital part of any network, a failure or issues in dynamic routing can cause large disruptions.

Without Indeni how would you find this?
An administrator could login and manually run the command.

chkp-clish-show-ospf-neighbors

#! META
name: chkp-clish-show-ospf-neighbors
description: Run "show ospf neighbors" over clish
type: monitoring
monitoring_interval: 5 minutes
requires:
    vendor: "checkpoint"
    or:
        -
            os.name: "gaia"
        -
            os.name: "ipso"

#! COMMENTS
ospf-state:
    why: |
        Due to the dynamic nature of OSPF, it should be closely monitored to verify that it is working correctly. Since routing is a vital part of any network, a failure or issues in dynamic routing can cause large disruptions.
    how: |
        The status of OSPF neighbors is monitored using clish command "shwo ospf neighbors".
    without-indeni: |
        An administrator could login and manually run the command.
    can-with-snmp: false
    can-with-syslog: false
    vendor-provided-management: |
        Listing OSPF neighbors is only available from the command line.

#! REMOTE::SSH
stty rows 80 ; ${nice-path} -n 15 clish -c "show ospf neighbors"

#! PARSER::AWK

# The following two sections has been added by request of Dan Shouky
# https://indeni.atlassian.net/browse/IKP-1221

# Unfortunately, the following code is duplicated in many .ind scripts.
# If you change something in the following two sections, please find all
# of the other instances of this code and make the change there also.

#Could not acquire the config lock
/Could not acquire the config lock/ {
    if (NR == 1) {
        next
    }
}

#CLINFR0829  Unable to get user permissions
#CLINFR0819  User: johndoe denied access via CLI
#CLINFR0599  Failed to build ACLs
/(CLINFR0829\s+Unable to get user permissions|CLINFR0819\s+User: .+ denied access via CLI|CLINFR0599\s+Failed to build ACLs)/ {
    exit
}

# Make sure line starts with some ID
#1.142.128.82      1     2WAY           39      10.201.134.32     10.201.134.1      0
#1.142.128.104     1     FULL/BDR       34      10.201.134.131    10.201.134.1      0
#10.0.0.50         1     INIT/DR        34      10.0.0.50         10.0.0.4          0
/^[0-9\.]{4}/ {
    # Verify we have the number of columns we thought we would
    if (NF == 7) {

        state_desc = $3

        tags["name"] = $1 " priority: " $2 " address: " $5
        tags["state"] = state_desc

        state = 0
        if (match(state_desc, /FULL|2WAY/)) {
            state = 1
        }

        writeDoubleMetricWithLiveConfig("ospf-state", tags, "gauge", "60", state, "OSPF Neighbors", "state", "name")

    }
}

cross_vendor_ospf_neighbor_down

package com.indeni.server.rules.library.templatebased.crossvendor

import com.indeni.ruleengine.expressions.conditions.EndsWithRepetition
import com.indeni.server.rules.RuleContext
import com.indeni.server.rules.library.ConditionalRemediationSteps
import com.indeni.apidata.time.TimeSpan
import com.indeni.server.common.data.conditions.Equals
import com.indeni.server.rules.library.templates.StateDownTemplateRule

/**
  *
  */
case class CrossVendorOspfNeighborIsDownRule() extends StateDownTemplateRule(
  ruleName = "cross_vendor_ospf_neighbor_down",
  ruleFriendlyName = "All Devices: OSPF neighbor(s) down",
  ruleDescription = "Indeni will alert if one or more OSPF neighbors isn't communicating well.",
  metricName = "ospf-state",
  applicableMetricTag = "name",
  alertItemsHeader = "OSPF Neighbors Affected",
  alertDescription = "One or more OSPF neighbors are down.",
  baseRemediationText = "Review the cause for the neighbors being down.",
  metaCondition = !Equals("vendor", "checkpoint"))(
  ConditionalRemediationSteps.OS_NXOS ->
          """This issue might be caused by:
            | a. L2/L3 connectivity issue
            | b. OSPF not being enabled on the interface
            | c. an interface is defined as passive
            | d. a mismatched subnet mask
            | e. a mismatched hello/dead interval
            | f. a mismatched authentication key
            | g. a mismatched area ID
            | i. a mismatched transit/stub/Not-So-Stubby Area (NSSA) option
            |Check OSPF configuration:
            |Use these commands in order to check the OSPF configuration (subnet, hello/dead interval, area ID, area type, authentication key (if any), and not-passive), and ensure that it matches on both sides.
            | a. "show run ospf"
            | b. "show ip ospf PID interface"
            | c. "show ip ospf PID"
            |
            |Troubleshooting OSPF States:
            |1. OSPF Neighbor Stuck in the Initialization (INIT) State. This issue might be caused by:
            | a. one side is blocking the hello packet with ACL
            | b. one side is translating, with Network Address Translation (NAT), the OSPF hello
            | c. the multicast capability of one side is broken (L2)
            |
            |2. OSPF Neighbor Stuck in a Two-Way State. This issue might be caused by OSPF priority set equal to zero.
            |NOTE: It is normal in broadcast network types.
            |
            |3. OSPF Neighbor Stuck in Exstart/Exchange. This issue might be caused by:
            | a. MTU mismatch
            | b. Neighbor Router ID (RID) is the same as its neighbor's
            | c. ACL blocking unicast - after two-way OSPF sends unicast packet
            |
            |4. OSPF Neighbor Stuck in a Loading State. This issue might be caused by bad Link State Advertisement (LSA). Check the OSPF-4-BADLSATYPE message with the "show ip ospf bad" and the "show log" commands.
            |
            |Further details can be found in: <a target="_blank" href="https://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/116422-technote-ospf-00.html"> CISCO Nexus OSPF troubleshooting guide|</a>.""".stripMargin,
  ConditionalRemediationSteps.VENDOR_JUNIPER ->
          """|1. Run the "show ospf neighbor" command to view the current state of OSPF neighbors.
             |2. Run the "show configuration protocol ospf" command to view OSPF configuration.
             |3. If no OSPF neighbor is shown, please check the following items:
             |  a. physical and data link connectivity
             |  b. mismatched IP subnet
             |  c. subnet mask
             |  d. area number
             |  e. area type
             |  f. authentication
             |  g. hello and dead interval
             |  i. network type
             |4. It's normal for DR-other neighbors to be stuck in two-way state.
             |5. If the OSPF neighbor is stuck in Exstart/Exchange State, check mismatched IP MTU.
             |6. Consider configuring traceoptions to track the OSPF operations.
             |7. Review the following articles on Juniper TechLibrary for more information:
             | a. <a target="_blank" href="https://www.juniper.net/documentation/en_US/junos/topics/topic-map/ospf-traceoptions.html">Example: Configuring OSPF Trace Options</a>
             | b. <a target="_blank" href="https://kb.juniper.net/InfoCenter/index?page=content&id=KB14881">OSPF is in '2 Way' state with some neighbors and "Full" with others</a>
             |8. If the problem persists, contact the Juniper Networks Technical Assistance Center (JTAC).""".stripMargin
)