Top NQEs

Problem OverviewHow much could I save on my Cisco support renewal, if I could just tell what devices are ‘over-licensed’?That is a question that one of my customers was struggling with.  Trying to answer this kind of question is very difficult if you have a large estate of switches that has been deployed over time.  To complicate things, there are also various generations of Nexus switches and a number of licensing models and names.  It is all very confusing.This script hopefully gives you the ability to answer this question, and in addition it calculates a  🚨 potential cost saving 🚨 based on licence prices you enter at the start.The result of this script is a report that looks like this:  If that has got you interested, read on! Cisco NXOS LicensesIn terms of licensing, Nexus mainly breaks down into two license types - a switching-only license and a dynamic routing license.  Depending on the model of Nexus, this will be ESSENTIALS (switching) / ADVANTAGE (routing/switching), or it m

File this under “ya I’ll never do that again”.  We’ve all had at least one “oops” that sticks with us.How does one find Cisco Switches or Routers that just happen to have the same Hostname or the same Management IP Address reported in LLDP and / or CDP?  What if those alleged Cisco device just happen to have the same configuration except for the out of band management address?  Accidentally of course.  Well, this happened during a rapid stand up of two new Cisco routers.  (Not me, of course.  I learned this lesson many moons ago).   To speed up the deployment, a copy / paste of config from one Router to two others occurred.  Oh, yes, some nasty stuff happened after this.  But that’s not pertinent to the resolution.NQE to the rescue.  Since the Management IP addresses were “forgotten” or unknown to those troubleshooting the issue, how does one find these near identical twins?  Remember that CDP announces Serial Numbers.  LLDP typically does not advertise the device’s Serial Number.  Thu

Identifying all the IP addresses on your network can be a complex and tedious task - and even impossible on some networks. This NQE makes it significantly easier to identify all the IP addresses in use on your network, including those that are stale or obsolete.   OverviewThis NQE identifies IPv4 and IPv6 addresses that are in use within the network. Due to the scarcity and value of IPv4 addresses, companies often seek to maximize their utilization and identify any under utilized address space. This can help to either improve the utilization of owned addresses or free up unused address space for sale. Whether you’re consolidating for financial purposes or re-IPing due to mergers, acquisitions, or network reorganizations, this NQE is essential for identifying all the IP addresses within the network. ResultsImproved IP Utilization: By identifying stale or obsolete IP addresses, this NQE enables organizations to optimize their IP space, reducing the need to purchase additional address spa

Extracting public IP data from AWS can be painful and time consuming. This NQE makes it easy to identify public IPs across all accounts and regions and can be customized for other cloud providers. OverviewStarting in February 2024, AWS began charging for public IP addresses to incentivize the migration to IPv6 due to the depletion of IPv4 space. Managing these costs can be challenging, especially with AWS’s VPC IP Address Manager (IPAM) which only works across a single account and incurs additional charges. Our NQE provides a comprehensive view across accounts and regions without extra costs, simplifying IP management. This functionality also extends to other cloud platforms like Azure and GCP, offering a unified solution for IP management.ResultsThis NQE simplifies IP management by providing a centralized dashboard to view and manage IP addresses across multiple AWS accounts and regions. The Public IP NQE identifies underutilized IP addresses, helping customers avoid unnecessary charg

OverviewSecurity Technical Implementation Guides (STIGs) are critical for ensuring that organizational devices accessing the Department of Defense Information Networks (DODIN) meet stringent security requirements. The NQE STIG compliance check makes it easier to validate that device configurations are compliant with STIG standards and verify those configurations remain compliant with each snapshot. STIG compliance involves a comprehensive list of requirements ensuring proper configuration of authentication, logging, network time protocol (NTP), and management plane. These requirements can vary significantly depending on the device type and vendor, with different configurations needed for everything from backbone routers and campus layer switches, to VPN concentrators. Given the complexity and variety of these requirements, maintaining compliance can be a daunting task. This NQE solution provides comprehensive auditing capabilities for STIG compliance as well as extensibility to validat

Managing wide area networks (WANs) efficiently is paramount for businesses. This Network Query Engine (NQE) serves as a critical tool, offering visibility into WAN circuits by integrating external data sources from service providers.OverviewIn today's digital landscape, businesses rely on wide area networks (WANs) to connect different parts of their operations. A common challenge is the lack of visibility into all WAN circuits, leading to inefficiencies and unnecessary costs. That's where this Network Query Engine (NQE) steps in, providing a solution that allows customers to use external data sources, such as CSV files, to better manage their networks. For instance, a customer can take a CSV from a service provider like AT&T, and use it to match IP addresses to devices in their network. This helps identify routers and WAN interfaces that might not be immediately visible, ensuring that only necessary circuits remain active. ResultsCustomers have found this capability invaluable for

One of the painful parts of trying to audit configurations, is accounting for the variations in the configuration that differ based on Vendor/Model/OS etc… Additionally, accounting for ‘old’ configurations/mis-configuration across these variations adds an extra (sometimes silent, sometimes not) “WTF” as one attempts to isolate the problems.With initial input from Arica , I wound up writing 2 scripts to find the ‘new’ configuration and one to find the old, then ‘xlookup-ed’ the differences in excel. Not to fun, but it was effective enough.  Then I figured, how hard could it be to combine them? It was harder than I though, so I created the shell, and then asked for some help from a colleague (thanks Ahmed).@AricaFN@AhmedKhedr The result of the script produces an easily scanned results for the problems.Model ---- DeviceName ---- GoodConfig --- BadConfig/*** @intent Ensure SNMP Communities are correct* @description 2 columns, one column showing where the "GOOD Strings are, and another colu

I’m not sure if most people check back on the built in configs in the Forward Library, but this one is pretty slick.  Are these part of release notes or anything? I looked in the NQE documentation and didn’t find anything related, but I could be looking in the wrong spot.@queryquery(Operating_Systems: List<OS>, Device_Name_Patterns: List<String>, Config_Pattern: PatternBlocks<{}>) = foreach device in network.devices where isPresent(device.files.config) where length(Operating_Systems) == 0 || device.platform.os in Operating_Systems where length(Device_Name_Patterns) == 0 || max(foreach pattern in Device_Name_Patterns select matches(device.name, pattern)) foreach match in blockMatches(device.files.config, Config_Pattern) select { Device: device.name, OS: device.platform.os, "OS Version": device.platform.osVersion, Model: device.platform.model, Match: match.blocks, Tags: device.tagNames };Regardless, these queri