OS version mismatch across cluster members-f5-all
Indeni will identify when two devices are part of a cluster and alert if the OS installed is different.
Install the correct versions of software on each device.
How does this work?
This script uses the F5 iControl REST API to retrieve the version of the OS.
Why is this important?
Capture the device operating system version.
Without Indeni how would you find this?
An administrator could extract this data by logging in to the device, entering TMSH and issuing the command “show sys version”.
name: f5-rest-mgmt-tm-sys-version description: Determine end of software support type: monitoring monitoring_interval: 60 minutes requires: vendor: f5 product: load-balancer rest-api: 'true' comments: software-eos-date: why: | Ensuring the software being used is always within the vendor's list of supported versions is critical. Otherwise, during a critical issue, the vendor may decline to provide technical support. F5 Networks posts the list of supported software on their website (https://support.f5.com/csp/article/K5903). indeni tracks that list and updates this script to match. how: | This script uses the F5 iControl REST API to retrieve the current software version (the equivalent of running "show sys version" in TMSH) and based on the software version and the F5 Networks provided information at https://support.f5.com/csp/article/K5903 the correct end of support date is used. can-with-snmp: false can-with-syslog: false os-name: why: | Capture the device operating system name. how: | This script uses the F5 iControl REST API to retrieve the name of the OS. can-with-snmp: true can-with-syslog: false os-version: why: | Capture the device operating system version. how: | This script uses the F5 iControl REST API to retrieve the version of the OS. can-with-snmp: true can-with-syslog: false vendor: why: | Capture the device vendor name. how: | This script set the vendor value to F5. can-with-snmp: true can-with-syslog: false steps: - run: type: HTTP command: /mgmt/tm/sys/version?$select=Version parse: type: JSON file: rest-mgmt-tm-sys-version.parser.1.json.yaml
// Deprecation warning : Scala template-based rules are deprecated. Please use YAML format rules instead. package com.indeni.server.rules.library.templatebased.crossvendor import com.indeni.server.rules.RuleContext import com.indeni.server.rules.library.templates.SnapshotComparisonTemplateRule import com.indeni.server.rules.RemediationStepCondition /** * */ case class cross_vendor_compare_osversion() extends SnapshotComparisonTemplateRule( ruleName = "cross_vendor_compare_osversion", ruleFriendlyName = "Clustered Devices: OS version mismatch across cluster members", ruleDescription = "Indeni will identify when two devices are part of a cluster and alert if the OS installed is different.", metricName = "os-version", isArray = false, alertDescription = "The members of a cluster of devices must have the same OS's installed (including the same version).\n\nThis alert was added per the request of <a target=\"_blank\" href=\"http://il.linkedin.com/pub/gal-vitenberg/83/484/103\">Gal Vitenberg</a>.", baseRemediationText = """Install the correct versions of software on each device.""")( RemediationStepCondition.VENDOR_CISCO -> """| |1. Check that the vPC peers have the same NX-OS version except during the non-disruptive upgrade, that is, In-Service Software Upgrade (ISSU). |2. Execute the "show version" NX-OS command and check the installed NX-OS version across the vPC peer switches. |3. Login to the Cisco Software Download center (a CCO account is required) and check the available NX-OS releases for your devices. Further information can be found to the next link: https://software.cisco.com/download/navigator.html?mdfid=268437593&flowid=4466 |4. Select the NX-OS release highlighted with a star icon and download it. This is the currently recommended NX-OS version by Cisco. |5. Review the Release Notes for this release for any bug and unsupported feature. If this NX-OS release does not support features which are already deployed at the current configuration a more recent NX-OS release should be used. |6. Schedule a Maintenance Window for NX-OS upgrade in order the vPC peer switches have exact the same NX-OS version. |NOTE: The vPC could be established between the vPC peers with not exact the same NX-OS release but several problems will be faced when new features are configured. For instance FEX-mismatch SW log message will be generated if you try to connect a FEX via vPC to a pair of vPC switches with different SW version. In this case the FEX will be operational only from one of the vPC peer switches.""".stripMargin )