NQE

Forward Networks includes serial numbers in its model as part of the component object. So if you want to see the serial number for a device, you must iterate through the components of that device. The serial number for the device itself usually belongs to the chassis, but some vendors may have multiple controller cards. The serial numbers for line cards, power supplies, etc will also be listed as components with serial numbers.There is a build-in NQE query in the Forward Library called Device Hardware that is included in Inventory+ by default. If it has been deleted from Inventory+, you can add it back by clicking on Inventory+ > Add NQE Queries and then selecting the Device Hardware NQE and clicking add and then Add.Note the foreach component in platform.components loop and the component.serialNumber entry in the NQE query code below:/** * @intent Information about device hardware */foreach device in network.deviceslet platform = device.platformforeach component in platform.compone

I am trying to create a NQE query for all the F5 devices. The query searches for SSL profile on custom command. Custom Command is : show ltm virtual detail recursive | grep -E "Ltm::ClientSSL Profile:" -E "Virtual Server:"The NQE should return SSL Profiles and the VIPs associated with them.  

This is a script to pull switch port stats from our access switches in our network. The data pulled in this script is used for ‘right sizing’ and network planning. We can then export the results, and pivot table them to see the % of switch ports in use/not-in use. I’ll add this attachment later./*** @intent Show int counters on Arista & IOS-XE Switches * @description * 1. Check to see what switch ports have had no traffic accross the wire for sizing and planning. * 2. Match on platform.os* 3. Use the information from the custom command 'show int counters'.* 4. Get counts of switch ports on that device so we can use to calculate % in use**/// Pattern of output// Arista & Cisco Same ColumnsTraffic = ```{Port:string} {InOctets:number} {InUcastPkts:number} {InMcastPkts:number} {InBcastPkts:number}```;// Arista FunctionEOS_Stats = foreach device in network.deviceswhere device.platform.os == OS.ARISTA_EOSforeach command in device.outputs.commandswhere command.commandText == "sh int

AWS - Public IPv4 charge changes Back on Jul 28, 2023, AWS announced forthcoming changes to their billing for IPv4 public IP usage, which take effect as of Feb 1, 2024. In summary, AWS says, "Effective February 1, 2024, there will be a charge of $0.005 per IP per hour for all public IPv4 addresses, whether attached to a service or not (there is already a charge for public IPv4 addresses you allocate in your account but don’t attach to an EC2 instance).". More information can be viewed here: https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/. Update Apr. 2, 2024: In light of this, Forward Networks can assist with keeping track of your Public IP usage via an improved NQE Query located in “NQE->Library->Forward Library->Cloud->AWS->Public IPv4 Cloud Cost” that will show you what's being used: /** * @intent Shows the number and cost of AWS public IPv4 IP addresses */import "L3/IpAddressUtils";// $0.005 per hour per IPcostPerIpPerDay = 24.

Hi,I wrote an NQE query which is expected to return devices with CRITICAL severity only. The query returns almost a million results which is unlikely. Each device has so many rows with CRITICAL CVEs. foreach cveDatabase in [network.cveDatabase]foreach cve in cveDatabase.cvesforeach device in network.deviceslet platform = device.platformlet Severity = Severity.CRITICALselect {   "Device Name": device.name,  "CVE ID": cve.cveId,  "Severity": Severity.CRITICAL,  "Vendor": platform.vendor,  "Model": platform.model}    

This is a simple NQE to run a custom command to report on the ABOOT Version and Platform of Arista Devices. From Arista:In a small set of cases systems may experience an unexpected reboot. The reload is due to an uncorrectable ECC error caused by a corner case timing conflict on the CPU sub-system tracked by bugID 419257. This bug affects the range of CPU models present in these products. The affected systems are not restricted by specific serial numbers or date code ranges and the reload is unpredictable. Systems running Aboot6 BIOS revision lower than 6.1.7 or 6.0.9 and Aboot4 BIOS revision lower than 4.1.1 or 4.0.7 are susceptible to this issue. There are currently 4 release trains of Aboot across these systems: 4.0.x and 4.1.x, 6.0.x, and 6.1.x. A single common patch file will introduce the update across all release trains and is not platform or version-specific----------------------------------------------------------------------------------------------------------The custom Comma

foreach d in network.devicesforeach i in d.interfaceswhere length(i.links) != 0where i.adminStatus == AdminStatus.DOWNselect {deviceName:d.name, interface:i.name} 

An FW engineer was looking to get the results from the command, “show firewall vip”, from all Fortinet Firewalls in Forward Networks. Command: show firewall vipconfig firewall vip    edit "x-7.6.254.158-dns"        set uuid d60c0a52-2630-51eb-9d53-bc032ca5e1c0        set extip x.x.x.x        set mappedip "y.y.y.y"        set extintf "any"    next    edit "x.x.x.1/32"        set uuid 796a2ac2-2251-51ec-5c82-26b2e049a7a7        set comment "Voice LAB"        set extip x.x.x.1        set mappedip "y.y.y.1"        set extintf "any"    next    edit "x.x.x.2-y.y.y.2"        set uuid 9ea63058-47ac-51ec-2a7f-5b0d00a1d142        set comment "Cloud"        set extip x.x.x.2        set mappedip "y.y.y.2"        set extintf "any"    next  Finding the command in the data model  /** Thank you Danny Ramirez with the Smarts on this * * @intent Grap VIP's on Fortinets command.output of "show firewall vip" * @description Define VIP format, and then iterate through to pull the VIP * Name and theMapped

As network engineers, we have few tools that can help us correlate the actual state of our network devices, and our intent. In many cases maybe our intent is not clearly defined: How many EIGRP neighbors is the set of core switches really supposed to have? How many neighbors should I be learning a specific prefix from? How many entries should I have for prefix x in my EIGRP Topology or my OSPF Database? Is my intent to have all the entries installed in the Route Table as ECMP paths or should I only ever have 1 next-hop that only changes if a path becomes unavailable?  In the network engineering realm specifically, even with automation tools like Ansible - without structuring your playbook logic very specifically - there are assumptions being made about the current state of the network. Even if your Ansible repos & playbooks are structured in a declarative and idempotent fashion, they are not exactly a consumable way for a network engineer to learn about the network - and you are re

Morning folks! We recently got the opportunity to leverage Forward Networks NQE for a Cyber Security ask. They want to verify that EC2 Instances are not being assigned the default Security Group. This should be a simple enough task. AWS creates the security group with the name ‘default’ so all we need to do is create an NQE Query that checks our Cloud Objects with a type of ‘instance’ and verify that the list (I’m assuming it is a list type) of security groups does not contain ‘default’. However, after reviewing the NQE Data Model I’m not convinced the ‘Cloud Objects’ are exposed in such a way we can correlate instance to security group. Can someone confirm or deny this?I do see that the instance tags are exposed as part of the ComputeInstance data model, so a workaround would be for us to edit our Terraform code so that security groups assigned to the instance are also created as tags on the instance so we can expose that correlation for consumption in NQE.

Forward Networks parse, processes and normalizes the snapshot details gathered.  You have heard this term over and over again.  Let’s use this method to see all of the subnets across all AWS, GCP and Azure deployments.  This NQE query is based upon the example in the DataModel for network → cloudAccounts → vpcs → subnets → ifaces /** * @intent Enumerate the Routing Table for all Cloud Providers * @description Enumerate the Routing Table for all Cloud Providers. The notModeled column indicates the ipAddress is not modeled. */ipModeled(ipAddress) = foreach cloudAccount in network.cloudAccounts foreach vpc in cloudAccount.vpcs foreach subnet in vpc.subnets foreach iface in subnet.ifaces where ipAddress in iface.ipAddresses select iface.ipAddresses;foreach cloudAccount in network.cloudAccountsforeach vpc in cloudAccount.vpcsforeach routeTable in vpc.routeTablesforeach route in routeTable.routeswhere isPresent(route.nextHop)let nextHop = route.nextHoplet ipAddress = when nextHop is

Azure VNet peering and Global VNet peering routes the subnets in each VNet as defined by the VNet routing table.  In some cases the Cloud Account configured in the Forward Networks platform does not have permission to enumerate all the necessary VNets.  One needs to update the Microsoft Azure subscriptions service principals to include the missing VNets. But how does one find the VNets that are not modeled but referenced by other VNets?  NQE, of course.  The method of finding missing VNets is fairly straightforward.  Similar to using the widely used “check for missing next hop route peers” NQE query, this NQE performs a similar task./** * @intent List VPCs / Microsoft Azure VNets that are not modeled. * @description Need the Microsoft subscriptions to be added to the service principal. See the VPC / VNet values in the destinationVPCId column. */idsOfCollectedVpcs = foreach cloudAccount in network.cloudAccounts foreach vpc in cloudAccount.vpcs select distinct vpc.id;foreach cloudAcc

Forward Networks NQE is very powerful.  The information is there.  The examples are clearly written for copying and pasting to create or combine new queries.  This NQE lists the AWS Hosts / Instances with MAC address(es).  Listing the instance type (ex: t2.micro) enables sorting by size.  Or, finding whether the instance is up or down.  Or simply listing all instances across all accounts.   /** * @intent List all AWS Hosts and MAC Addresses * @description List all AWS Hosts and MAC Addresses */foreach cloudAccount in network.cloudAccountsforeach vpc in cloudAccount.vpcsforeach computeInstance in vpc.computeInstancesforeach iface in computeInstance.instanceIfacesforeach subnet in vpc.subnetswhere subnet.id == iface.subnetIdforeach subnetIface in subnet.ifaceswhere subnetIface.id == iface.ifaceIdselect { cloudAccountName: cloudAccount.name, vpcId: vpc.id, computeInstanceId: computeInstance.id, name: computeInstance.name, tags: computeInstance.tags, isUp: computeInstance.isUp, imag

The method of using the Forward Networks search bar to list all devices where a subnet is learned or advertised is very useful. This NQE lists the route, egress interface, interface description and a bit more. Displaying the next hop MAC address and associated OUI vendor is useful in determining whether the next hop is a router or firewall.  /** * @intent List IP Prefixes / Route Table entries for all Routers * @description List the Route Table and egress interfaces detailes. Useful to determine where a particular route is, and what routes egress a device or interface. */getNextHopDesc(deviceName, interfaceName) = foreach interface in deviceName.interfaces where interface.name == interfaceName select interface.description;getNextHopMac(deviceName, interfaceName, ipNextHop) = foreach interface in deviceName.interfaces foreach subinterface in interface.subinterfaces let ipv4 = subinterface.ipv4 foreach neighbor in ipv4.neighbors where neighbor.ip == ipNextHop select neighbor.li

Keeping track of IP subnet allocation across multiple AWS accounts can be challenging. With NQE you can query all the VPCs at once.The following NQE query list the root level CIDR blocks for each VPC, and then shows how the IP space is allocated across each subnet.foreach cloudAccount in network.cloudAccountsforeach vpc in cloudAccount.vpcsforeach subnet in vpc.subnetsselect { cloudAccountName: cloudAccount.name, vpcId: vpc.id, ipv4CidrBlocks: vpc.ipv4CidrBlocks, subnetId: subnet.id, name: subnet.name, tags: subnet.tags, addresses: subnet.addresses, region: subnet.region, availabilityZone: subnet.availabilityZone} This NQE goes even further, showing the UNALLOCATED IP space in each CIDR block. That is, the IP prefixes within each VPC that have NOT been assigned to a subnet:/** * @intent Find all unallocated IPv4 VPC CIDR blocks * @description An unallocated CIDR block for a VPC is a CIDR block assigned to the VPC but not used by any subnet. * The restriction to IPv4 is because

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

In this NQE Video, I am going cover and how to use let and group-by qualifiers.Join me for a look at the two NQE qualifiers, let and group-by.Code examples used in videoforeach device in network.deviceslet deviceName = device.namelet affected_interfaces = (foreach interface in device.interfaces group interface.name as interfaces_name by interface.operStatus as oper_status select { int: interfaces_name, oper: oper_status,})foreach entry in affected_interfacesselect { deviceName: deviceName, interfaceNames: entry.int, operStatus: entry.oper}LetUsing let to assign expressions that make the code more easily readable, in this case assigning the device OS version and operating system to variables and filtering on them foreach device in network.deviceslet version = device.platform.osVersionlet os = device.platform.oswhere os == OS.ARISTA_EOS && matches(version, "4.15*")select { deviceName: device.name, version: version, os: os}Grou

The MTU query that comes canned in Forward Networks was pretty cool. However, I just wanted the MTU info on links that contained an LLDP or CDP neighbor entry, b/c I just don’t care about the MTU of of access devices, just the infrastructure links.I tried to also modify to not pull MTU on Mgmt Interfaces (ma1, MA1, mgmt0)  However, I’m still pulling some ‘ma1’ interfaces! Oh well .I just sort it out later, but if anyone sees the issue, chime in./** * @intent Return the MTU of interfaces that contain a CDP or LLDP neighbor * @description rcariddi 6/30/2023 Find All links of CDP/LLDP, make sure each side of the link matches. This allows us to ignore non infrastructure links * If we want all values, remove the line: where isPresent(interface1.cdp) || isPresent(interface1.lldp) **/foreach device1 in network.devicesforeach interface1 in device1.interfaceswhere isPresent(interface1.mtu)where isPresent(interface1.cdp) || isPresent(interface1.lldp)where toLowerCase(interface1.name) not in ["m

I hope everyone had a relaxing holiday and New Year!Now that we are getting back into the swing of things, do you suspect there are rogue devices in your network, but you have no easy way to find them?  I remembered what I had to do back in the day to find rogue devices, and needless to say, it was not easy to find them.  Could Forward Networks help Mike find these rogue devices?  I had the same question, and I enlisted the help of our resident NQE expert, Jack Shen, to see if we could identify and locate where these unwanted devices are easily.  Code example used in the demoThe NQE query that was used in the video to find if there were any Huawei devices in their network is below. foreach device in network.devicesforeach host in device.hostswhere isPresent(host.macAddress)let assigneeName = ouiAssignee(host.macAddress)where isPresent(assigneeName)let vendor = toUpperCase(assigneeName)select { violation: matches(vendor, "HUAWEI*"), deviceName: device.name, deviceInterfaces: host.int

In todays NQE Video, I will show you the basics of using if expressions and how to use them when you want to create your own multi-vendor parser.Code examples used in videoThis particular parser is going to look at DNS servers and check to make sure that they are configured with the appropriate servers.dns_addresses = [ipAddress("1.1.1.1"), ipAddress("1.0.0.1")];ios_xe = ```ip name-server {dns:ipv4Address+}```;arista = ```ip name-server vrf {string} {dns:ipv4Address+}```;palo_alto = ```config devices localhost.localdomain deviceconfig system dns-setting servers primary {dns:ipv4Address+} ```;cisco_asa = ```dns server-group {string} name-server {dns:ipv4Address+}```;generic = ```dns {dns:ipv4Address+}```;foreach device in network.deviceslet os = device.platform.oslet dns_pattern = if os == OS.PAN_OS then palo_alto else if os == OS.IOS_XE then ios_xe else if os == OS.ARISTA_EOS then arista else if os == OS.ASA then cisco_as

In today's video I will introduce the NQE foreach and where statements. We explore the data model and how to start off your NQE queries as well as go into when and why you would want to use a where statement.Code examples used in videoReturn all IPsec tunnels and create a report of the peer IP address, interface status and operational statusforeach device in network.devicesforeach interface in device.interfaceswhere interface.interfaceType == IfaceType.IF_TUNNEL_IPSECselect { deviceName: device.name, tunnelName: interface.name, peerIP: interface.tunnel.dst, adminStatus: interface.adminStatus, operStatus: interface.operStatus}You could modify the above to violate if the administrative status is up but the operational status not up with the following NQE query:foreach device in network.devicesforeach interface in device.interfaceswhere interface.interfaceType == IfaceType.IF_TUNNEL_IPSECselect { deviceName: device.name, tunnelName: interface.name, peerIP: interface.tunnel.dst, v

 Join Mike on a journey to introduce a feature of the Forward Enterprise platform called the Network Query Engine (A.K.A NQE) and why it will make your job as a network or security operator much easier.   Let us know what you think about NQE; what do you see yourself using it for?  If you have any questions ask them below 👇🏻 Code example used in videoReturn a violation if an interface on a Cisco IOS XE device is administratively up but operationally downforeach device in network.devicesforeach interface in device.interfaceswhere device.platform.os == OS.IOS_XEselect { deviceName: device.name, interfaceName: interface.name, adminStatus: interface.adminStatus, operStatus: interface.operStatus, violation: interface.adminStatus == AdminStatus.UP && interface.operStatus != OperStatus.UP} 

Join me for a look at the comparisons you can use in NQE to filter out on what data you need to see in your query. Code examples used in videoUsing equals (==) to return any default routes in any VRF foreach device in network.devicesforeach networkInstance in device.networkInstanceslet afts = networkInstance.aftslet ipv4Unicast = afts.ipv4Unicastforeach ipEntry in ipv4Unicast.ipEntrieswhere ipEntry.prefix == ipSubnet("0.0.0.0/0")foreach nh in ipEntry.nextHopswhere isPresent(nh.ipAddress)select { deviceName: device.name, vrfName: networkInstance.name, RouteEntry: ipEntry.prefix, nextHop: nh.ipAddress}Using not equal to (!=), to exclude ASA’s a platform inventory reportforeach device in network.deviceswhere device.platform.model != "ASAv"select { deviceName: device.name, deviceModel: device.platform.model }Choose whether or not to report on interface MTU that is:Greater than 1500 ( > ) Greater than or equal to 1500 ( >= ) Less than 1500 ( < ) Less than or equal to 1500

In cloud environments, the complexity of network architecture, especially with the prevalent use of NAT (Network Address Translation), often obscures visibility, making the detection of duplicate subnets a challenging task. This lack of transparency can lead to network inefficiencies, conflicts, and potential security risks. The NQE query I'm sharing specifically addresses this challenge, offering a streamlined approach to uncover hidden duplicate subnets, a crucial step in maintaining a robust and efficient cloud network. To tackle the issue of detecting overlapping IPv4 CIDR blocks across different VPCs in cloud environments, I've developed a precise NQE (Network Query Engine) query. This query methodically scans through all cloud accounts and their respective VPCs, identifying any instances where IPv4 CIDR blocks overlap. The query is designed to compare each VPC within a cloud account against others, ensuring comprehensive coverage and accurate detection of duplications. Below is t

Join me on an introduction to working with Lists in NQE. We cover some of the basic list comparisons and the list function length().Code examples used in videoReturn all Arista devices, and if the device is not running the approved OS, return a violation for that deviceapproved_os = ["4.15.0F"];foreach device in network.deviceswhere device.platform.os == OS.ARISTA_EOSselect { violation: device.platform.osVersion not in approved_os, name: device.name, version: device.platform.osVersion} There is another way to write this query. We can write it so that it will only return all devices that are violating versus returning every device and violating the devices that are not compliant. This query would look like:approved_os = ["4.15.0F"]foreach device in network.deviceswhere device.platform.os == OS.ARISTA_EOSwhere device.platform.osVersion not in approved_osselect {violation: truename: device.name, version: device.platform.osVersion} We are using where only to filter devices that are run