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:
| <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
)
)
}
}