Community

Hi all, We are getting “No processed Snapshot found. Please take a Snapshot and try again.” when trying to hook Forward Network with SNOW CMDB, anyone has any idea why this happen ? ( We do have snapshots already taken and processed) Thank you 

Incident Management: A Proactive Approach to Minimize Disruption Experiencing an incident can be chaotic, with alarms sounding off and urgent communications flooding in, often at the least opportune moments. The key to effective incident management is not just to respond with urgency but to anticipate and mitigate issues before they escalate. The TL;DRTo effectively manage incidents, you must first establish visibility across and baselines of your network. Know what’s normal and what’s not. Ensure robust logs are being collected in a centralized manner, and contain all relevant details to facilitate troubleshooting. Develop your response team. Know their strengths and weaknesses, and ensure everyone on the team has skin in the game. publish playbooks, runbooks, and other procedural documents so everyone knows what is expected of them during an incident. Foster relationships with your peers and other teams long before an incident eve

 No time! Skip to the demo. @nikhilhandigol demonstrates how generative A.I. unlocks network insights and shows the Tech Field Day delegates how Forward Networks seamlessly incorporates generative A.I. into its network digital twin software. Inside the most popular product feature, Network Query Engine, every user can perform natural language queries to access crucial network data in seconds. You can

  Every network engineer can associate with 7:58 In this introduction, @Mike explains Forward Network's digital twin software, Forward Enterprise, and how network digital twin benefits more than just networking people. Forward Enterprise analyzes every possible network behavior, traces where every packet could ever go, and gives every user a queryable vendor-independent data model so NetOps, SecOps, CloudOps and even Compliance teams can get a mathematically-accurate view of the network.Check out the entire Network Field Day series here

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-------------------------------------------------------------------------------------

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

Launch Podcast Join Craig Johnson (@captainpacket) and William Collins as they discuss the power of community, and then dig into the growth and adoption of Digital Twins and where they fit in today’s tech stack. Topics covered include:The Concept of Digital Twins in Networking: Drawing parallels to other industries like manufacturing. Craig explains that a digital twin is a digital representation of a real-world network, allowing for easier troubleshooting, visualization, and understanding of network components and configurations.  Evolution of Digital Twin with Cloud and Automation: Craig discusses the e

Well let me tell you something brother!  You think you know everything about Zero Trust?? You don't know diddley about network security without a network digital twin.  Watch @Mike hit viewers with the figurative folding chair of knowledge or be hit by one. Tune in to see which it is!  

Good news, you can ask it all the questions you want with Forward Enterprise's new AI Assist feature. Watch @Mike use natural language to perform Network Query Engine searches-- no matter your role or skill level, you can conduct sophisticated network queries with a minimal learning curve.  

How can federal agencies possibly comply with the HUNDREDS of complex specifications in the DISA STIG compliance checklists?  @Mike has special guest @devecis in studio to learn how a network digital twin can streamline your federal network compliance and give you full confidence heading into an audit.  

For those interested in security certifications, I wanted to pass along this hidden gem of certification training.Ben Malisow is an excellent technical editor and trainer, and is the guy behind the wannabea.. certification training programs. I would highly recommend his trainings for CISM, CISSP, CCSP, and SSCP for anyone interested in these certifications. - https://www.wannabeacism.com/

Sometimes a path search may not present the results you expect. When engaging with support regarding a path search issue, you may be asked to provide a snapshot with the relevant path search data. To capture a snapshot of a path search, first perform the path search in question. In this example, we are performing a simple path search from atl-ce01 to atl-core-pe01: Now, press and hold the Alt or Cmd key, and the icon on the far right of the query bar will change from ‘Copy Query’ to ‘Export Query’. Click on the ‘Export Query’ icon: The Export Snapshot wizard will now display all devices relevant to that path, and allow you to add any additional devices you wish

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 

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

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.route

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.cloudAccou

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,

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 = subinterf

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 un

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":

Hey Folks!I’m looking to find out if anyone has modeled their corporate VPN access - maybe using Synthetic Devices - in such a way that allows you to search for user workflows to determine if they are allowed, and have them properly modeled as coming in through the VPN Firewall instead of at the switch VLAN. We are looking to create intent checks for access through our VPN. Happy NQEing!

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 

I am working on automated resolution of failed connections.   Two questions: (1) On this page in the documentation: /docs/nqe/data-model/type_devicecollectionerror/  there is a list of errors but no descriptions.  Can someone provide? (2) I am studying a failure report and the Connect Test Status notes each of these in PHASEs which seems to imply that each is determined in a sequence.  Is there a list of PHASE order for these? AUTHENTICATION_FAILED-AUTHENTICATION PHASEAUTHORIZATION_FAILED-AUTHORIZATION PHASECONNECTION_FAILED-CONNECTION PHASEDEVICE_IS_CHILD_CONTEXT-SETUP PHASEDEVICE_TYPE_MISMATCH-TYPE_DISCOVERY PHASEDEVICE_TYPE_UNDETECTED-TYPE_DISCOVERY PHASEGUEST_MISSING_HOST_RESULTS-SETUP PHASEJUMP_SERVER_AUTHENTICATION_FAILED-CONNECTION PHASEJUMP_SERVER_CONNECTION_FAILED-CONNECTION PHASEOTHER-AUTHORIZATION PHASEPING_FAILED-CONNECTION PHASEPORT_REACHABILITY_FAILED-CONNECTION PHASEPRIV_PASSWORD_ERROR-SETU

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)