Next hop inaccessible-checkpoint-secureplatform

Next hop inaccessible-checkpoint-secureplatform
0

Next hop inaccessible-checkpoint-secureplatform

Vendor: checkpoint

OS: secureplatform

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-splat-os-routes

name: chkp-splat-os-routes
description: Record static and directly connected routes
type: monitoring
monitoring_interval: 10 minute
requires:
    vendor: checkpoint
    os.name: secureplatform
    or:
    -   vsx:
            neq: 'true'
    -   mds: 'true'
    asg:
        neq: 'true'
comments:
    static-routing-table:
        why: |
            To get the static route table of the machine
        how: |
            By collecting the the linux command "netstat" as well from the static routes configured from the GAiA database
            "/config/active"
        can-with-snmp:
            false
        can-with-syslog:
            false

    connected-networks-table:
        why: |
            To check the connected route of the machine
        how: |
            By collecting the the linux command "netstat" as well from the static routes configured from the GAiA database
            "/config/active"
        can-with-snmp: false
        can-with-syslog: false
steps:
-   run:
        type: SSH
        command: ${nice-path} -n 15 cat /etc/sysconfig/netconf.C ; ${nice-path} -n
            15 ifconfig -a
    parse:
        type: AWK
        file: splat-routes.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:
             | <a target="_blank" href="https://www.cisco.com/c/en/us/support/docs/switches/nexus-5000-series-switches/116199-technote-stp-00.html">Spanning Tree Protocol Troubleshooting on a Nexus 5000 Series Switch</a>
             | <a target="_blank" href="https://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-7000-series-switches/C07-572834-00_STDG_NX-OS_vPC_DG.pdf">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: <a target="_blank" href="https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/show-arp.html#jd0e289">Operational Commands</a>""".stripMargin
      )
    )
  }
}