Next hop inaccessible-checkpoint-all

Next hop inaccessible-checkpoint-all
0

Next hop inaccessible-checkpoint-all

Vendor: checkpoint

OS: all

Description:
Indeni will review the routing table and identify when a next hop router is showing as FAILED or INCOMPLETE in the ARP table.

Remediation Steps:
Determine why the next hops are not responding.
||Trying pinging the next hop routers in the list above and resolve any connectivity issues one by one until all pings are successful.",

chkp-asg-route-novsx

name: chkp-asg-route-novsx
description: Retrieve routing data
type: monitoring
monitoring_interval: 5 minute
requires:
    vendor: checkpoint
    asg: true
    vsx:
        neq: true
comments:
    static-routing-table:
        why: |
            To get the static routing table for the blades
        how: |
            By running the Checkpoint Command "asg_route" and geting the Static configured routes.
        can-with-snmp: false
        can-with-syslog: false

    connected-networks-table:
        swhy: |
            To get the directly connected routing table for the blades
        how: |
            By running the Checkpoint Command "asg_route" and geting the directly configured routes.
        can-with-snmp: false
        can-with-syslog: false

    routes-missing-kernel:
        why: |
            To get the missing routes between the database and the operating system  blades
        how: |
            By running the Checkpoint Command "asg_route --comp_os_db" and geting the diffrence in the routes if any
        can-with-snmp: false
        can-with-syslog: false
steps:
-   run:
        type: SSH
        command: ${nice-path} -n 15 asg_route && ${nice-path} -n 15 asg_route --compare-os-db
    parse:
        type: AWK
        file: asg-route-novsx.parser.1.awk

cross_vendor_next_hop_router_inaccessible

package com.indeni.server.rules.library.core
import com.indeni.ruleengine.InvisibleScopeKey
import com.indeni.ruleengine.expressions.conditions.Equals
import com.indeni.ruleengine.expressions.core._
import com.indeni.ruleengine.expressions.data._
import com.indeni.ruleengine.expressions.scope.ScopeValueExpression
import com.indeni.server.common.data.conditions.True
import com.indeni.server.rules._
import com.indeni.server.rules.library.{ConditionalRemediationSteps, PerDeviceRule, RuleHelper}
import com.indeni.server.sensor.models.managementprocess.alerts.dto.AlertSeverity


case class NextHopRouterInaccessibleRule() extends PerDeviceRule with RuleHelper {

  override val metadata: RuleMetadata =
    RuleMetadata.builder(
      "cross_vendor_next_hop_router_inaccessible",
      "Next hop inaccessible",
      "Indeni will review the routing table and identify when a next hop router is showing as FAILED or INCOMPLETE in the ARP table.",
      AlertSeverity.ERROR,
      categories = Set(RuleCategory.HealthChecks),
      deviceCategory = DeviceCategory.AllDevices).build()

  override def expressionTree(context: RuleContext): StatusTreeExpression = {
    StatusTreeExpression(
      // Which objects to pull (normally, devices)
      SelectTagsExpression(context.metaDao, Set(DeviceKey), True),

      // What constitutes an issue
      StatusTreeExpression(
        // The time-series we check the test condition against:
        SelectSnapshotsExpression(context.snapshotsDao, Set("arp-table", "static-routing-table")).multi(),

        // The condition which, if true, we have an issue. Checked against the time-series we've collected
        StatusTreeExpression(

          JoinSnapshotsExpression("arp-table" -> "targetip", "static-routing-table" -> "next-hop")
            .distinct(InvisibleScopeKey("next-hop", "static-routing-table")),

          Equals(
            ScopeValueExpression("success").invisible("arp-table").optional(),
            ConstantExpression(Some("0"))
          )
        ).withSecondaryInfo(
          scopableStringFormatExpression("${scope(\"static-routing-table:next-hop\")}"),
          EMPTY_STRING,
          title = "Inaccessible Next Hops",
          invisibleIdKeys = Set(InvisibleScopeKey("next-hop", "static-routing-table"))
        ).asCondition()
      ).withoutInfo().asCondition()


      // Details of the alert itself
    ).withRootInfo(
      getHeadline(),
      scopableStringFormatExpression("Some of the routes in this device have a next hop which is inaccessible."),
      ConditionalRemediationSteps("Determine why the next hops are not responding.",
        RemediationStepCondition.VENDOR_CP -> "Trying pinging the next hop routers in the list above and resolve any connectivity issues one by one until all pings are successful.",
        RemediationStepCondition.VENDOR_PANOS -> "Log into the device over SSH and review the output of \"show arp\" to identify failures.",
        RemediationStepCondition.VENDOR_CISCO ->
          """|
             |1. Execute the "show spanning-tree" and "show spanning-tree summary"  NX-OS commands to quickly identify the STP root for all the configured vlans.
             |2. Run the "show spanning-tree vlan X detail" NX-OS command to collect more info about the STP topology (X=vlanid).
             |3. Check the event history to find where the Topology Change Notifications originate from by running the next NX-OS command "show spanning-tree internal event-history tree X brief" , (X=vlanid).
             |4. Display the STP events of an interface with the next NX-OS command "show spanning-tree internal event-history tree Y interface X brief" , (X=vlanid, Y=interfaceid).
             |5. Consider to hard code the STP root and backup root to the core switches by configuring a lower STP priority.
             |6. Activate the recommended vPC "peer switch" NX-OS command to a pure peer switch topology in which the devices all belong to the vPC.
             |7. Consider to use Root Guard feature to enforce the root bridge placement in the network. If a received BPDU triggers an STP convergence that makes that designated port become a root port, that port is put into a root-inconsistent (blocked) state.
             |8. For more information please review the following links:
             | https://www.cisco.com/c/en/us/support/docs/switches/nexus-5000-series-switches/116199-technote-stp-00.html<a linkText>Spanning Tree Protocol Troubleshooting on a Nexus 5000 Series Switch</a>
             | https://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-7000-series-switches/C07-572834-00_STDG_NX-OS_vPC_DG.pdf<a linkText>Spanning Tree Design Guidelines for Cisco NX-OS Software and Virtual PortChannels</a>
          """.stripMargin,
        RemediationStepCondition.VENDOR_BLUECOAT ->
          """ARP resolve failure to the next hop of the ProxySG.
            |1. Login via SSH to the ProxySG and run the  "show arp-table" command.
            |2. Check for incomplete arp enteries.
            |3. Run the "show interface all" command and check the current status of the network interface with the incomplete arp entery.
            |4. Diagnose the layer 2 connectivity between the ProxySG to the other device.
            |5. If the problem persists, contact Symantec Technical support at https://support.symantec.com for further assistance.""".stripMargin,
        RemediationStepCondition.VENDOR_JUNIPER ->
          """|1. Log into the device over SSH and enter “show arp no-resolve” command to review next-hop MAC and IP address information in ARP table.
             |2. Check for a misconfiguration on interfaces or a physical issue.
             |3. Review the following article on Juniper tech support site: https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/show-arp.html#jd0e289<a linkText>Operational Commands</a>""".stripMargin
      )
    )
  }
}