Skip to main content

Forward Enterprise - Beginner 🟢

Beginner

A Guide to S3 Pre-Signed URLs: What They Are and How They Work

   This video explores S3 pre-signed URLs, explaining their purpose, benefits, and how they function. It also includes a demonstration of creating and using pre-signed URLs in the AWS Management Console and highlights their integration within the Forward Networks platform for secure and efficient workflows. Summary: Pre-Signed URLs in Forward NetworksPre-signed URLs enable secure, temporary access to private S3 bucket objects without exposing credentials. In Forward Networks, they are used for non-SaaS VM installations and upgrades, allowing users to download overlays and package upgrade files from Software Central.Why They Matter:Secure Access: Prevents unauthorized access while allowing necessary downloads. Time-Limited Links: URLs expire (e.g., 30 minutes), reducing security risks. Automation & Ease of Use: Clicking "Copy Command" generates a pre-signed URL for quick access via command-line tools like curl.This ensures that VM deployments and upgrades remain efficient, automated, and secure without making S3 buckets public. What Is an S3 Pre-Signed URL?An S3 pre-signed URL is a secure, time-bound link that allows temporary access to specific objects stored in a private S3 bucket. Unlike traditional access methods that rely on long-term credentials or bucket-wide permissions, a pre-signed URL leverages existing authentication credentials to create a URL that grants limited access to a single object for a specified duration. This approach enables secure sharing without exposing sensitive credentials or making the bucket public. Why Are Pre-Signed URLs Important?Private S3 buckets are the default setting in AWS, ensuring that stored objects are inaccessible to the public. While this is excellent for security, scenarios often arise where temporary access to a specific file is necessary. Conventional options for granting access include:Sharing AWS credentials. Creating temporary accounts for external users. Making the S3 bucket publicly accessible.These methods are either insecure or impractical, especially for short-term access. Pre-signed URLs resolve these issues by:Allowing users to securely share objects without exposing credentials. Maintaining the private nature of the bucket while granting temporary access. Simplifying access management through automated expiration. How Do Pre-Signed URLs Work?1. Generating a Pre-Signed URLThe process of creating a pre-signed URL in the AWS Management Console is straightforward:Navigate to the private S3 bucket and select the desired object. Choose "Share with pre-signed URL" under the object’s Actions menu. Specify an expiration time (e.g., 1 minute, 30 minutes, or a custom duration). Generate the URL, which is immediately copied to the clipboard for sharing.2. Using the URLWhen accessed within the specified timeframe, the URL provides direct access to the object, bypassing the need for authentication credentials. Once the expiration time elapses, the URL becomes invalid, ensuring secure and time-limited access.3. Key Components of the URLEach pre-signed URL contains essential elements that enable secure and temporary access:Object Location: The specific path to the file in the S3 bucket. Security Token: A temporary token that validates the request. Expiration Timestamp: The exact time at which the URL will expire. Authentication Signature: A cryptographic signature that ensures the URL can only be used as intended.4. Demonstrating ExpirationTesting a pre-signed URL involves attempting to access it after its expiration time. For example:Accessing the URL immediately shows the object. Refreshing the URL after the timer expires results in an "Access Denied" error, confirming the security mechanism. Practical Application in Forward NetworksPre-signed URLs are seamlessly integrated into Forward Networks' platform, providing critical functionality for tasks like Forward VM installations and upgrades.Use Case in Software Central PortalIn Forward Networks’ Software Central Portal, users have the option to download VM images and upgrade packages using pre-signed URLs generated through "Copy Download Command" buttons:Step 1: Clicking the button generates a unique pre-signed URL for the requested file. Step 2: The URL is valid for 30 minutes, giving users ample time to complete the download. Step 3: If the URL expires, users can simply click the button again to generate a new one.Behind-the-Scenes FunctionalityThe URLs generated in Software Central use the same principles demonstrated in AWS:They are tied to specific S3 buckets managed by Forward Networks. Security tokens, authentication signatures, and expiration timestamps ensure secure, controlled access to files.This implementation streamlines VM deployments and upgrades, providing a user-friendly and secure way to manage critical files. Advantages of S3 Pre-Signed URLs Enhanced Security:Keeps private buckets secure by avoiding public access or credential sharing. Includes built-in expiration to limit the duration of access.Ease of Use:Quick to generate and share, requiring minimal configuration. Accessible through common interfaces like the AWS Console or platform-specific integrations.Flexibility:Supports both GET (download) and PUT (upload) operations. Customizable expiration times cater to varying access needs.Practical Integration:Ideal for platforms like Forward Networks, where secure, temporary access is essential for tasks like software updates. ConclusionS3 pre-signed URLs are a robust, flexible, and secure solution for granting temporary access to private S3 objects. They address common challenges associated with sharing files securely, making them an indispensable tool in workflows that demand simplicity and security. Their integration into the Forward Networks platform exemplifies how this feature can be used to streamline operations like VM installations and upgrades while maintaining rigorous security standards. Whether for personal use or enterprise-scale applications, pre-signed URLs are a vital feature for modern cloud operations. 

Beginner

Introduction to the Forward Networks API

Introduction to the Forward Networks API As organizations scale their networks, automation and integration with existing tools become essential. Forward Networks provides a robust API that allows users to streamline bulk actions, automate workflows, and extract valuable data for reporting and analysis. In this article, we introduce the Forward Networks API, covering its basic functionalities, common use cases, and how customers can leverage it for their network operations. What is an API?API stands for Application Programming Interface. It acts as a bridge that enables different applications to communicate with each other. APIs provide a standardized way to interact with a system without needing to understand its underlying architecture. Essentially, APIs allow users to send requests and retrieve or modify data efficiently. Why Use the Forward Networks API?The Forward Networks API is a powerful tool for managing devices, automating tasks, and integrating with other network management solutions. Some key use cases include:Bulk device onboarding: Instead of manually adding devices through the GUI, users can automate the process by submitting a POST request to import multiple devices at once. Automation & network updates: The API enables administrators to dynamically update network configurations, reducing manual effort and ensuring consistency. Integration with external tools: Many organizations use tools like ServiceNow CMDB to manage device information. The API allows seamless synchronization of network data across platforms. Reporting & data extraction: Users can extract device and snapshot data for custom reporting, audits, or compliance tracking. Understanding API RequestsThe Forward Networks API supports multiple request types:GET: Retrieve information, such as device inventories or network snapshots. POST: Add new data, such as uploading device credentials. PATCH/PUT: Modify existing records, like updating device information. DELETE: Remove data when necessary. Exploring the API Through DocumentationUsers can explore and test API endpoints directly in the Forward Networks API documentation. On-prem customers can access the API documentation at https://*Your-Forward-App*/api-doc. The built-in API interface allows users to input credentials, execute queries, and view responses in real-time. Additionally, once a successful API call is executed, users can copy the corresponding cURL command or URL for use in scripts. Let’s start with an easy API call…  Retrieving a List of DevicesGo to the Forward Networks API documentation  Scroll down the Documentation page to the Credentials form     a.Provide your Username and Password or Access Key and Secret Key Once you’ve provided credentials, we’ll start with an easy API call that will list the network devices in a snapshot. Continue scrolling down to the Networks section and expand the /api/networks API endpoint.Any API calls you create in the API Documentation will automatically generate a curl script you can copy/paste into a command prompt or include in external scripts.  Let’s try something with more filtering options... Filtering Snapshots for Reporting  You can limit results to specific snapshots based on success criteria. Filtering options can also exclude snapshots with missing devices. In the Networks section, and expand the /api/networks/{networkId}/snapshots API endpoint. Provide the network ID and any success criteria you’d like to apply to the query.   You’re not limited to reading data, you can also make changes via the API… Updating Device Credentials in Bulk Instead of manually updating credentials for individual devices, users can submit a POST request with updated authentication details.  In the Networks section, and expand the /api/networks/{networkId}/deviceCredentials API endpoint. Provide the network ID and modify the values in the request body to suite your needs.  Moving Toward AutomationThe API provides a strong foundation for automation. By integrating with scripting languages like Python, users can build workflows that:Automate device discovery and credential updates. Query and analyze network snapshots for compliance. Merge snapshots for running path search queries across historical data. The Forward Networks API empowers users to automate network tasks, improve efficiency, and enhance integration with external tools. Whether you are new to APIs or an experienced developer, leveraging the API can significantly enhance your network management capabilities. Stay tuned for more in-depth guides, including advanced API queries and automation examples! What API examples would you like to see? Ask in the comments below!

Beginner

From CLI to NQE: How I Use Forward to Be a More Efficient Network Operator

Before I started using Forward Networks, I was deep in the weeds of daily network operations. Like many of you, I relied on the CLI to do everything—whether it was compliance checks, interface audits, or config validation. It worked, but it was slow, manual, and honestly, a bit exhausting. Then I discovered Network Query Engine (NQE), and everything changed. My Background: Life in the CLI Before discovering NQE, I managed networks using CLI commands across dozens or hundreds of devices every day.Logging into individual devices—one at a time   Running the same commands repeatedly (show run | include, show run | section, etc.)   Copying results into spreadsheets to figure out what was going on   Trying to get ahead of issues, but always feeling like I was behind  This approach worked for a while, but it became clear that it couldn’t scale with the needs of a modern network. The Breakthrough: Pattern and Block MatchingWhen I began exploring NQE, I realized I didn’t need to learn everything about the data model to be effective—just a few key techniques that mirrored the CLI patterns I already knew.Pattern matching in NQE acts a lot like grep. You can find exactly what you’re looking for, at scale   Block matching lets you define a context or "section" of a config to extract structured data   I created a simple formula that could be reused across different commands and operating systems  That one repeatable pattern gave me a huge boost in efficiency and saved time right away. What I Used to Do (CLI)In the past, a simple task such as checking the access VLAN for interfaces, required logging into each device and running something like:show run | include interface | switchport access vlan…and repeating that on every single device, then manually reviewing the results. What I Do Now (NQE) With NQE, I write one query and apply it across all relevant devices at once, instantly getting structured results.Match only the OS I’m targeting   Apply my pattern/block matching formula   Automatically extract exactly what I’m looking for  Here’s the NQE I use to show run | include interface | switchport access vlan on all my network devices in one query: pattern = ```interface {name:string} switchport access vlan {vlan:number}```;foreach device in network.devicesforeach interface in blockMatches(device.files.config, pattern)select { interface: interface.data.name, "Access Vlan": interface.data.vlan} It’s the same logic as my CLI commands, but now it’s automated and works across the full network. Where to Start if You’re New to NQE If you’re just getting started with NQE, it helps to start small with something you already understand and build from there.Pick a task you already know well. Something like:   Looking for open ports that haven’t seen traffic in weeks   Pulling all BGP network statements from device configs   Checking interface operational status   Use pattern/block matching. You don’t need to know the whole data model   Start with my custom command formula. It’s simple, repeatable, and works across OS types  You can find this approach in my Custom Commands article. Taking It Further: NQE via API Once you’re comfortable with NQE in the UI, you might want to run those queries elsewhere—like in a terminal or dashboard. That’s where the Forward Networks API comes in.I can schedule queries or integrate them into my own apps   I don’t have to log into the Forward Networks platform every time   I can pull NQE results directly into Power BI, Splunk, or my scripts  You can read my Intro to the Forward Networks API for a beginner-friendly walkthrough. You Don’t Have to Go It Alone You don’t have to become an expert in NQE to get value from it—there’s plenty of help available if you know where to look.Explore the Forward community where we share examples and best practices Ask your CSE (Customer Success Engineer) for help Submit a support ticket—we’re happy to assist  Even if you just want to know, “Can NQE do this?”—ask. The goal isn’t to turn everyone into a query-writing wizard. It’s to make you aware of what’s possible and know the basics to get what you need.  . Where to Go From Here If you’re ready to start experimenting with NQE, here are a few easy next steps to help guide your journey.Try a simple NQE query using my pattern matching formula   Read other community examples and many, many more. Start thinking about how you could use this in your own workflows   Keep your eye out—we’re always adding new community KB articles on custom commands and many other topics. Let us know if there’s a topics you’d like to see! Wrapping it Up If you’re like me and you came from the CLI world, I want you to know:You already have the skills you need to succeed with NQE   You don’t have to learn everything about the data model to get value fast   With just a few small changes in how you approach common tasks, you can scale your efforts across your entire network  This journey—from CLI to NQE—has been game-changing for me. And I hope it is for you, too.Let me know in the comments if you try it out or need help getting started—I’m happy to help! 

Beginner

Unlocking the Power of Network Path Search: A Quick Reference Guide

The Path Search Cheat Sheet (🔽 attached below 🔽) is a powerful resource designed to help network engineers efficiently query and analyze complex network paths with the Forward Platform. Rather than detailing every possible function, this guide gives you the tools to resolve network issues and optimize performance. This reference is more than just a list of commands—it’s a blueprint for turning raw network data into actionable intelligence. Whether you’re troubleshooting an immediate problem or planning for future growth, this cheat sheet is your guide to making the most of Forward Networks’ powerful path search capabilities.Driving Value with Path SearchBy leveraging the cheat sheet, you can:Quickly Diagnose Issues: Identify traffic bottlenecks, policy enforcement problems, or unreachable destinations. Validate Configurations: Confirm that routing, firewall policies, and other configurations align with intended network behavior. Optimize Network Performance: Gain actionable insights into traffic flows, enabling better decision-making for performance tuning or capacity planning.How to Use the Cheat SheetThe cheat sheet provides a structured approach to network path queries, enabling you to:Define the Scope of a Search: Use keywords to specify starting points, or paths through particular devices or interfaces. This flexibility allows users to narrow down search results to relevant traffic paths quickly. Refine Queries with Filters: Apply filters like VLANs, IP prefixes, or MAC addresses to target specific traffic attributes. Advanced modifiers, such as logical networks or device groups, further streamline searches in large-scale environments. Analyze Outcomes: Identify whether traffic is delivered, dropped, blackholed, or encounters other issues. This insight helps pinpoint bottlenecks, misconfigurations, or policy enforcement challenges.Key Features for Advanced UseIterative Resolution: Automatically resolves ambiguous inputs like VRFs or IP prefixes to specific network components. When necessary, prompts guide users to refine their queries. Logical Networks: Group devices or edge nodes to limit the query scope, simplifying analysis in complex setups. Flexible Query Functions: Combine functions such as ingress, egress, or bypass to trace traffic flows with precision. These can be layered to explore how traffic navigates multi-layered architectures. Advanced Traffic Attributes: Target specific behaviors with filters for Layer 2, Layer 3, or application-layer attributes, helping users uncover nuanced performance or policy-related issues. Have additional path search questions? Ask below! 

Beginner

Achieving Stress Free STIG Compliance

   What is a STIG?The Security Technical Implementation Guidelines (STIG) are device security guidelines set by the US government's Defense Information Security Agency (DISA). DISA is responsible for maintaining the security requirements necessary to access the Department of Defense Information Systems Information Networks (DODIN). Updates are released quarterly.Our focus is on visibility into your network. In our demonstration, we’re going to zero in on the STIGs applicable to your switches, routers, firewalls, and load balancers. STIGs are broken down by vendor, device type, and operating system and generally come from the best practices set by vendors to secure the OS. This is where we see some overlap with CVEs. How STIGs are typically handledWhen it comes to keeping up with STIG compliance, especially around audits, defining best practices can be painfully time-consuming.DISA provides their STIG viewer for viewing STIGs and creating checklists. For each device, you have to:Find it in the STIG viewer. Locate the STIG files that apply to that device. Make a checklist and input this device information. Go down the line for each ID running show commands to check your config for each one of these IDs. In our demonstration, you see that one router, we have to review 144 rules. That’s time-consuming in itself, but imagine the time spent on an enterprise network with hundreds to thousands of devices!How Forward Networks handles STIGsSee the NQE demonstration in the video aboveImport STIGS from DISA and reformat as NQE NQE stands for Network Query Engine and is Forward Networks’ proprietary language to interrogate your network. STIG information is available and maintained as NQE Develop Queries and QC for accuracy and usability for customersWhat about non-standard STIGs?See the NQE demonstration in the video aboveAn NDM STIG, whether it's for a router, L2 or L3 switch, has basic device configs that are easy to convert, but requirements are rarely so simple. One example we see is when looking at STIGs under Cisco IOS_XE Router RTR, ID CISC-RT-000010 says to filter "traffic for specific source and destination addresses as well as ports and protocols." This requirement can be met a number of ways and will differ from one organization to another. Without looking at your network, we have no way of knowing what the configuration looks like. The example provided shows an ACL and how the interfaces should be configured to allow traffic to pass through.When we create queries for these complex requirements, we strive to get you as close to the finish line as possible. Using this example, all you have to do is paste in your ACL and run the query. Have questions? Ask below! Recommended assets DOD/DISA STIG Viewer Tools Network Digital Twin for Cyber Command Readiness Inspections

Beginner

Default Outbound Access in Azure is Retiring — Are You Ready?

Beginner

Path Search - What to Do When Your Search Query Returns an Unexpected Result

Running a path search query in Forward Networks and getting zero results or unexpected results can be frustrating, especially when you're confident the query is correctly structured. Zero results typically indicate a mismatch between the query and the network model, incomplete data, or overly restrictive filters. Here’s a practical guide to troubleshooting and resolving these scenarios.1. Investigate the Starting PointA common reason for zero results is an issue locating the source IP:Check if the source IP was resolved correctly: Hover over the source IP to see if it was mapped to a host, device, or interface. If the system couldn’t locate the source: Search for the address used in the “from” clause. Do you see a subnet containing the source? If the gateway on which this address resides is missing from the snapshot, add it to the snapshot. If the source gateway cannot be added, consider using Edge Node and connect it to the right entry point for the subnet it represents. This will help the system locate the address and the broader subnet.    2. Verify the Destination If using the To IP clause, ensure the system correctly resolved the destination IP:Hover over the destination IP to confirm its location. If the system can’t resolve the destination, follow a similar approach as step 1 to either add the devices hosting the destination IP, or add an Edge Node.3. Use the Permit All OptionFirewalls and ACLs might block the traffic you're querying. To bypass these restrictions temporarily:Add the Permit All keyword to your query. This will allow the system to trace paths without enforcing firewall or ACL rules.4. Reevaluate To and Through FiltersFilters like To and Through restrict the results. You may expect your query to pass through a middle box, or terminate at a certain device. If that doesn’t happen, either because of network misconfiguration or missing devices in the snapshot, then your query won’t match on any computed path and returns no results. In that case:Temporarily remove these filters and re-run the query. If results appear, adjust or simplify the filters to refine your query.5. Review Traffic FiltersTraffic filters are applied by default to reduce irrelevant results. However, they can sometimes hide desired paths:Open the Filters panel in the UI. Under Traffic to Exclude, uncheck all filters, especially: Misconfigured Gateway. Glean Traffic. The query will be refreshed automatically and may produce the desired path. File a support ticket so Forward Networks can fix the filter to match your desired behavior.If you see some results, but they don’t match what you expected, there are a few additional things that need to be explored:1. Double-Check Your QueryBefore diving into deeper troubleshooting:Verify your query includes the correct source and destination IP addresses. One common mistake is understanding whether the destination IP is pre-NAT or post-NAT. This post is a great explanation on how to handle this in path search. Ensure the protocol (e.g., TCP, UDP, ICMP) is explicitly stated if needed. A common mistake is to specify HTTP as port or app-id, and leaving protocol unspecified. Since HTTP can run on both TCP and UDP in the modern era, the system will explore both and show the results for both. Include ports or application-specific details (e.g., port 443 for HTTPS).2. Check for Missing Devices in the ModelIf the path you expect is A → B → C → D, but the Forward platform returns only A → B, it could beC is missing in the snapshot. The path panel suggests when this happens and asks you to add the missing device.The link from B to C could be missing in the model. Please file a support ticket in such cases, but you can work around the issue by creating a manual link between B and C 3. Identify Drops or DivergencesIf paths terminate prematurely, check where the traffic diverges or drops: Look for the last point of agreement between the expected and Forward’s computed paths. Check sample packets at divergence points for headers that do not match what you intended the query to use (e.g., protocol is UDP, but you expected TCP. Please see step 1). File a support ticket if needed.  Seek Support if NeededIf you’ve tried these steps and still don’t see results:Document your query, expected behavior, and findings. Include external data (e.g., traceroute outputs) for comparison. Include a full or subset snapshot (if you are not on fwd.app). File a support ticket with Forward Networks to get additional help.Proactive tip for ensuring accurate path search resultsValidate Data Collection: Ensure all relevant devices, interfaces, and links are included in the snapshot. Train Your Team: Provide guidance on using Destination IP vs To and specifying protocols. Enhance the Model: Regularly update the snapshot to reflect changes in your network. 

Using different types of NQE Decorators

You can use a NQE Decorator to add additional contextual data to your search results.When adding a Decorator, you choose an Entity type. Depending on the type of Decorator you use, the contextual data will appear in a different area of your search results.For example, if you choose to apply a decorator at the Device level, the additional data will be seen in the Device Card.Here you can see the Basic Device Information query added as a Device Decorator: In the following  path search result, you can see two Decorators. There is a Path Decorator that calculates the Min and Max MTU along the entire path, as well as a Path Interface Decorator that displays the Link Speed. (The user must click on interface ge-0/0/3 in the Details card to see the Interface Decorator). The NQE query structure required for a Decorator depends on the Decorator type.For the Device Basic Info Decorator above, the standard Device Basic Info NQE query is used (/Forward Library/Devices/Device Basic Info)/** * @intent Basic information about Network Devices */formatStatus(deviceSnapshotResult) = when deviceSnapshotResult is collectionFailed(collectionError) -> "Collecting - " + replace(toString(collectionError), "DeviceCollectionError.", ""); completed -> "Completed"; processingFailed(processingError) -> "Processing - " + replace(toString(processingError), "DeviceProcessingError.", "");foreach device in network.deviceslet platform = device.platformlet snapshotInfo = device.snapshotInfoselect { Name: device.name, Location: device.locationName, Tags: device.tagNames, Vendor: platform.vendor, Model: platform.model, "Interface Count": length(device.interfaces), OS: platform.os, "OS Version": platform.osVersion, "Collection IP": snapshotInfo.collectionIp, "Management IP(s)": platform.managementIps, Status: formatStatus(device.snapshotInfo.result), Type: platform.deviceType}Notice that the output of this NQE query is a table of devices.When creating the Decorator, you choose "Name" for Device name column under Join columns. This tells the platform to look for the Device name in the Name column of the NQE query output, and display the rest of the data in that row in the Device Decorator. To create a Path or Path Interface Decorator, you have to create a Parameterized NQE query that takes in a Path parameter. The NQE query then iterates over the hops in the path to perform its calculations. For example, by using foreach hop in path.hops below:/** * @intent Gets the port speeds for interfaces on a path */import "Interfaces/Interface Utilities";getPortSpeed(deviceName, ifaceName) = max(foreach i in getInterface(deviceName, ifaceName) select i.ethernet.negotiatedPortSpeed);// Returns entries for both sides of a path hop, so that a violation// is shown on the egress out of an interface and on ingress into an// interface.@querygetPathPortSpeedInfo(path: Path) = foreach hop in path.hops let currentSpeed = getPortSpeed(hop.deviceName, hop.egressIfaceName) where isPresent(currentSpeed) && isPresent(hop.nextDeviceName) let nextSpeed = getPortSpeed(hop.nextDeviceName, hop.nextIfaceName) where isPresent(nextSpeed) let violation = currentSpeed != PortSpeed.SPEED_UNKNOWN && nextSpeed != PortSpeed.SPEED_UNKNOWN && nextSpeed != currentSpeed let egressRecord = { hopIndex: hop.index, direction: Direction.EGRESS, Speed: formatPortSpeed(currentSpeed), "Neighbor Speed": formatPortSpeed(nextSpeed), violation } let ingressRecord = { hopIndex: hop.index + 1, direction: Direction.INGRESS, Speed: formatPortSpeed(nextSpeed), "Neighbor Speed": formatPortSpeed(currentSpeed), violation } foreach record in [egressRecord, ingressRecord] select record;In the Path Interface Link Speed query (/Forward Library/Interfaces/Path Interface Link Speed), a table of interface speeds is created per hop. In this example, the Hop Index is associated with the hopIndex column to create the Path Interface Decorator.In the Path MTU query (/Forward Library/Interfaces/Path MTU) the minimum and maximum MTU for the path are calculated.Note the @query getPathMtuInfo(path: Path) function. This function is used to convert this query into a Parameterized Query, which takes a Path as an argument. /** * @intent Gets the min and max MTUs for interfaces on a path */getIface(ifaces, ifaceName) = foreach iface in ifaces where iface.name == ifaceName select iface;ifaceMtus(path) = foreach hop in path.hops foreach device in network.devices where device.name == hop.deviceName foreach iface in device.interfaces foreach iface in getIface(device.interfaces, hop.egressIfaceName) + getIface(device.interfaces, hop.ingressIfaceName) where isPresent(iface.mtu) select iface.mtu;@querygetPathMtuInfo(path: Path) = foreach mtus in [ifaceMtus(path)] let minMtu = min(mtus) let maxMtu = max(mtus) select { "Min MTU": minMtu, "Max MTU": maxMtu, violation: minMtu != maxMtu };When associating an NQE query with an Path Decorator, notice that there is no Join Columns field, because the query results are applied at the Path card level, and the Parameterized NQE query takes that Path as an argument.  

Beginner

Using Forward Enterprise for Change Control Validation

Implementing change management for network modifications has multiple benefits:Minimizes Downtime and Disruptions – Proper change management ensures that all modifications are planned, tested, and reviewed before implementation, reducing the risk of unexpected outages or performance issues.   Enhances Security and Compliance – By maintaining a structured approval process, organizations can prevent unauthorized changes that might introduce vulnerabilities and ensure compliance with industry regulations and internal security policies.   Improves Accountability and Documentation – A well-defined change management process creates a clear audit trail of network modifications, making it easier to troubleshoot issues, track performance impacts, and maintain historical records for future reference.Forward Enterprise can be used to validate if the state of the network matches its operational objectives before, during, and after a Change Control. The basic steps for this procedure are as follows: Identify the devices or cloud objects that are part of the change. It may be useful to include devices or cloud objects that are not being modified as part of the change, but have a high potential for impact.For example, suppose you are modifying the routing configuration of two routers in a remote office that has 10 networking devices and a VPN tunnel back to the main office. It would be useful to include all 10 devices at the remote site, plus devices at the central location that remote traffic uses to reach a critical application.   Identify existing intent checks or create new intent checks that will help validate the change.For example, you could create a path search intent check that verifies that an end host in the remote office can reach a critical application in the main officeIntent Verification (FWD.app Documentation)  Create a workspace network that includes all the devices and intent checks from steps 1 and 2Workspace Creation (FWD.app Documentation) Run a collection on the workspace network before starting the change.  Complete the required network changes for the Change Control.Run a second collection on the workspace network.Use Diffs and Intent Checks to validate the state of the network. Diffs (FWD.app Documentation)Intent Verification (FWD.app Documentation)Check out my other article on Diffs with Inventory+: Additional ConsiderationsWhen creating the workspace network, you can copy existing intent checks from the parent network. This way you can keep a library of often used intent checks.   Use the Diff feature to look for unexpected changes in route tables, interface states, etc.   You can create advanced intent checks that contain NQE queries to validate for complex settings. For example, you could create an NQE intent check that verified that all BGP peers on all devices are in the Established state.   You can configure alerts on your intent checks to receive an in-app banner notification or an email if an intent check fails.   Before the Change Control, you can create an intent check that will validate the expected state of the network after the change. For example, if the Change Control were to permit new traffic between two points on the network, you could create an intent check between the network locations that would fail before the change, but pass after the change is complete.

Beginner

Introduction to Forward Networks' Synthetic Nodes

A synthetic node is a user-generated construct in the Forward Networks model. It is used to represent a device or portion of the network from which data cannot be collected by the Forward platform. Most often a synthetic node represents a private service provider network (such as a layer-3 VPN) or the public Internet itself. With Forward Networks' synthetic nodes, you can gain deep insights into traffic behavior, security policy compliance, and connectivity without needing actual devices in place. Key Benefits of Synthetic NodesExtend Network Visibility: Model networks beyond physical limitations by identifying connections between devices, cloud regions, or even hypothetical network expansions. This allows teams to visualize how traffic would behave in different scenarios without deploying new hardware.   Improve Troubleshooting: Identify potential routing or connectivity issues in a controlled, testable environment without affecting live network traffic. By analyzing network behavior with synthetic nodes, engineers can diagnose problems faster and reduce mean time to resolution (MTTR).   Reduce Costs: Avoid the expense of deploying physical infrastructure for testing, validation, and network modeling. Instead of purchasing additional hardware or setting up lab environments, synthetic nodes allow teams to test changes in a cost-effective manner.  When to Use Synthetic NodesCloud Migrations: Simulate cloud regions and connectivity before migration to ensure hybrid and multi-cloud environments function correctly. This helps prevent misconfigurations that could disrupt application performance or introduce security gaps.   Mergers & Acquisitions: Model how two networks will interact before integration, allowing teams to identify potential routing conflicts, security mismatches, or performance bottlenecks. This helps ensure a seamless transition and minimizes post-merger network disruptions.   Security Policy Testing: Validate that segmentation and security policies effectively prevent unauthorized access while maintaining necessary connectivity. By identifying different attack vectors and policy changes, security teams can refine configurations to strengthen overall security posture.   Network Expansion: Test the impact of adding new devices, locations, or services on existing network infrastructure. This allows engineers to optimize network design and capacity planning while avoiding performance issues.   Compliance Audits: Verify compliance with security frameworks such as NIST, CIS, or PCI DSS by modeling potential vulnerabilities and policy enforcement. Synthetic nodes help simulate real-world traffic scenarios to ensure that security controls are operating as intended.  Getting Started with Synthetic Nodes in Forward NetworksDefine the Use Case: Identify what you want to simulate, such as new cloud regions, security policies, routing scenarios, or disaster recovery configurations. Clearly defining the objective helps ensure accurate modeling .   Create the Synthetic Node: Use Forward Networks’ interface to add a synthetic node representing the virtual device, application, or service. This node will act as a stand-in for real infrastructure, allowing for a comprehensive network analysis.   Configure Connections: Link synthetic nodes to existing network elements such as routers, firewalls, or cloud gateways to model behavior accurately. Defining how these nodes interact with real network components ensures better analysis.   Analyze Results: Review the network insights generated by the platform to validate network changes, detect misconfigurations, and optimize performance. Leveraging synthetic nodes for continuous testing helps improve network reliability and security over time. By leveraging synthetic nodes, you can make data-driven decisions, reduce risks, and streamline network operations without physical deployments. These virtual models empower networking and security teams to proactively address challenges and maintain a resilient, well-optimized network infrastructure. Want to learn more? Check out these community articles and discussions on synthetic nodes:     

Beginner

The NQE Files Tab

In todays video, we are going to go into a deeper dive on the NQE files tab. We discuss the different states the NQE queries can be in and go over the permission structure in NQE. Any questions or comments, feel free to post them below

Beginner

Confident Networks Don’t Happen by Accident — They’re Automated

When I first started working as a network engineer and later as a NOC chief, I thought the stress was just part of the job. At the time, we didn’t have network automation in place. Everything was done by hand, device by device, ACL by ACL, line by line. On paper, that sounds manageable. In practice, it was chaos.I was dealing with a global backbone—100 to 150 routers and other devices across multiple global regions and security enclaves. A single misstep could create ripple effects that spanned continents. I would triple-check my work, then pull in another engineer to look it over, then check it again before pressing “enter.” Even then, there were moments when I had no choice but to push the change and hope for the best. There’s a phrase we used back then: “full send.” It basically meant, “we’ve done everything we can—now let’s see what happens.” That’s not exactly the kind of confidence you want running critical infrastructure. But it was the reality of operating without automation. Living in the Manual EraThe manual approach created three major challenges that still stick with me today:Sheer Scale: My day-to-day involved configuring 100+ devices by hand. That’s hundreds of opportunities for typos, copy-paste errors, or mis-applied configs. Multiply that across a global network and the risk curve grows fast. Coordination Chaos: It wasn’t just my network. Often, I had to work with other teams and organizations to pass traffic across their networks too. That meant long chains of emails: “Hey, I need these ACLs applied to these interfaces by this time.” If my wording wasn’t perfect or if someone on the other side misread it, traffic didn’t flow. And when traffic didn’t flow, I was the one getting the call at 2 a.m. Endless Validation: Because every change carried so much risk, we checked and re-checked everything. Sometimes that meant hours of peer review for a single ACL change. Other times it meant frantically troubleshooting why packets were disappearing into a blackhole somewhere in the backbone or peering back through previous Technical Service Orders (approved Change Requests)As a junior engineer, it was a trial-by-fire environment. You learned quickly, but every day felt like a test you could fail spectacularly. How Automation Changed EverythingThe first time I used automation, it felt like magic. Suddenly, I wasn’t typing out the same commands over and over again. Scripts did the repetitive work for me. Instead of relying on a colleague’s gut check, I could run automated validations that confirmed my changes wouldn’t break connectivity.Here’s what shifted for me:Reliability: Automation removes human inconsistency. Configurations were applied the same way every time, no matter who was executing them. Speed: Tasks that once consumed half a day—like validating a change across dozens of devices—were done in minutes. Collaboration: Automation created a shared language. Instead of negotiating ACLs in endless email threads, we had workflows and scripts everyone could understand and trust. But the biggest change wasn’t technical—it was psychological. For the first time, I wasn’t holding my breath every time I pushed a change. I had confidence. I trusted the system to catch mistakes before they made it to production. How to Adopt Network Automation: Test Laps, Qualifying Runs, Race DayIf you’re wondering how to make this shift, my advice is simple: don’t try to win the Indy 500 on your first day behind the wheel. Think of adopting automation like preparing for a race: you start with test laps, work your way up through qualifying runs, and only then are you ready for race day.  Test Laps: Build Trust with Low-Risk TasksAt this stage, you’re still in the pit lane, running practice laps to make sure the car even stays on the track. Start with simple, low-risk automations: pulling inventory data, validating backups, and checking interface status. These early efforts don’t decide the race, but they build confidence in the “engine.” The key is to show your team and leadership that automation delivers consistent, accurate results. Every time a script catches an error or saves time, you’re proving it’s safe to let automation out of the garage. Qualifying Runs: Automate Day-to-Day OperationsOnce you’ve proven automation won’t stall out, it’s time to push harder. Now you can automate routine operational tasks like ACL updates, VLAN provisioning, or standardized config pushes. Always pair them with pre-checks and post-checks so everyone knows the lap is clean. Reality check: if you think that this is a one-man job, get that out of your head; you can’t be an automation lone wolf. At a minimum, you’re going to need three other like-minded teammates to manage what success looks like ( you don’t know everything in the beginning). This is when leadership will start to notice. Suddenly, you’re shaving minutes — even hours — off tasks. Mistakes drop, and engineers are freed up to focus on higher-value work. Just like qualifying, this stage earns you a spot on the grid. It shows the team you’re not just experimenting — you’re ready to perform. Race Day: Make Automation Mission-CriticalWhen you’ve reached this stage, automation isn’t just a tool in the trunk — it’s the engine powering the entire race. You’re orchestrating end-to-end workflows across vendors and platforms, integrating automation into monitoring, compliance, and even incident response. On race day, every decision, every pit stop, every lap is informed by automation. It’s no longer optional. It’s the only way to stay competitive at speed. Best Practices That Helped MeAlong the way, a few lessons stuck with me:Get leadership on board early. Executives respond to data. Show them concrete numbers—time saved, outages prevented, fewer escalations. Invest in training. Instead of training and coding sessions, organize happy hours and socials to share tools and playbooks, encouraging a culture of learning. Don’t boil the ocean. Incremental wins are more valuable than big, risky projects that never deliver Celebrate milestones. The first time your team successfully automates a production change? Treat it like a podium finish. Recognition fuels momentum. Why Automation Matters More Than EverBack when I was cutting my teeth, the networks were big, but nothing like what operators face today. Hybrid cloud. Multi-vendor environments. Overlapping overlays on top of overlays. The complexity curve keeps climbing, and manual operations simply can’t keep up. If you’re still managing everything by hand, you’re living on borrowed time. You might get away with it for a while, but sooner or later, the combination of scale, complexity, and human error will catch up with you.Automation isn’t just about making life easier. It’s about survival. It’s about protecting yourself, your team, and your organization from the inevitable mistakes that come with manual work. The Bottom LineLooking back, I don’t miss the trial-by-fire culture. I don’t miss holding my breath every time I hit enter on a command line. What I do value is the confidence automation gave me: the confidence that my changes would work as intended, the confidence that I could sleep through the night without worrying about a mis-typed ACL, the confidence that I was building a network I could trust. For me, automation turned chaos into confidence. And for today’s network operators, it can do the same. Don’t treat automation as a luxury. Treat it as the baseline.  Resources to Adopt Network Automation Community Articles: BooksAutomate the Boring Stuff Head First: Learn to Code Online Resourceshttps://www.geeksforgeeks.org/ - Provides tutorials, articles, coding challenges, and resources to learn programming. https://www.pluralsight.com/ - An online learning platform offering tech-focused courses and hands-on labs. 

Beginner

Find the Uptime of Your Network Devices (5 minutes or less)

Discover insightful network performance metrics—without having to write a single character of code. In this article, you'll learn how to quickly check the uptime of your network devices using the Forward Platform. It’s an easy introduction to show you how to extract network insights using Forward’s built-in capabilities.Log in to your Forward Platform In the left navigation, scroll down to the NQE section and click Library. At the top of the query window, click the New query icon When prompted, provide a unique name for your query.  Save time finding scripts - create a folder to store you new scripts in one place Your query is now open and ready to edit. Remember, you’re not writing one character of code.  On the far right side of the window, click the Data Model tab. Type uptime in the search field. This displays elements in the Forward data model that pertain to uptime.    Hover your cursor over the first result - uptime:Duration. A dialogue displays a description of this data model attribute and includes an example query. Click the copy icon above the example query.   Paste the example into the query you created earlier.   Click Execute to run the query     Boom! With a quick copy-paste, you created a network query that tells you the uptime of all your network devices. In this network, there are 146 device results and each row in the results contains the deviceName and its uptime. What if you wanted to find uptimes above or below a specified threshold?  Click Filter at the top of the uptime column. Click less than or equal to… Set the number of days, hours, weeks, minutes, and seconds on which you’d like to filter.      With an upper limit of 5 days, we now see 28 results.    You can also apply filters to the device name column to further narrow your search.     You’ve seen how effortless it can be to tap into valuable data about your network using the Forward Platform. By following these steps, you accessed the NQE Library, leveraged the data model, and ran a sample query to reveal your devices' uptime—all without writing a single line of code. As you explore these capabilities further, you'll unlock even more valuable insights, empowering you to manage and optimize your network with ease. How would you take this query further? What other columns would you add to the learn more from this query? Let me know in the comments!

Beginner

Make Critical Info Pop in NQE Tables

In Inventory, you have probably noticed how some table columns make it easy to spot issues at a glance. Green means things are healthy and red means something needs attention. The Status column in the Network devices table, located in Inventory, is a good example: “processed” shows up in green while something like “connection refused” stands out in red.Now, you can bring the same visual feedback into your own NQE queries. We’ve added a new builtin called withInfoStatus. It lets you tag any value in your result table with a label: OK, WARNING, or ERROR. The results table uses that label to color values appropriately.Here is an example. Suppose you want to flag devices whose OS support has already ended. This query checks if the support date is in the past and then labels it.  foreach device in network.deviceslet platform = device.platformlet osSupport = platform.osSupportwhere isPresent(osSupport) && isPresent(device.snapshotInfo.collectionTime)let collectionDate = date(device.snapshotInfo.collectionTime)select { Device: device.name, Vendor: platform.vendor, Model: platform.model, OS: platform.os, "End of OS support": withInfoStatus(osSupport.lastSupportDate, if osSupport.lastSupportDate < collectionDate then InfoStatus.ERROR else InfoStatus.OK)} The column “End of OS support” in the table below shows how the styling appears after the query is run:  When you run this, expired dates show up in red and current ones in green. The filter dropdown for that column will reflect the same color styling, making it easy to isolate devices with expired support.  This works with strings, numbers, IPs, dates, timestamps, and a few others. This feature was released in 25.5.0 and is controlled by the OrgProperty.NQE_INFO_STATUS flag. If you are not seeing this behavior yet, check with your Forward contact to confirm whether it’s enabled for your org.  Questions? Ask below

Beginner

Identify public IP usage in the cloud 🌥

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 charges. Customers have reported significant savings, avoiding tens of thousands of dollars in potential bills.  This comprehensive solution helps organizations maintain cost-effective and efficient IP address management across multiple cloud platforms.SolutionOur NQE collects and normalizes data on Elastic IP addresses within AWS, making it easier to spot underutilized IP addresses in a vendor-agnostic model. Customization options allow users to refine results to specific machine types or regions, enabling large organizations to manage thousands of IP addresses efficiently. Because the network data is part of our model, you could refine your results to return public IPs assigned to specific machine types, Linux for example, or find public IPs in a particular region. This helps large organizations focus their search when they have have thousands if not tens of thousands of public IP addresses. NQE Script/** * @intent Shows the number and cost of AWS public IPv4 IP addresses */import "L3/IpAddressUtils";// $0.005 per hour per IPcostPerIpPerDay = 24.0 * 0.005;isIPv4(subnet) = isPresent(patternMatch(toString(subnet), `{ipv4Subnet}`));getPublicAllocatedIps(cloudAccount) = foreach vpc in cloudAccount.vpcs let publicAllocatedIps = (foreach subnet in vpc.subnets foreach iface in subnet.ifaces foreach ip in iface.ipAddresses where isIPv4(ip) && ip not in privateIpAddressSet select ip) let numPublicIps = length(publicAllocatedIps) select { regionsOrnetworkBorderGroups: vpc.cloudRegions, vpcName: vpc.name, vpcId: vpc.id, numPublicIps };getPublicUnallocatedIps(cloudAccount) = [{ regionsOrnetworkBorderGroups: (foreach ip in cloudAccount.publicUnallocatedIps select ip.networkBorderGroup), vpcName: null : String, vpcId: null : String, numPublicIps: length(cloudAccount.publicUnallocatedIps) }];foreach cloudAccount in network.cloudAccountswhere cloudAccount.cloudType == CloudType.AWSforeach record in getPublicAllocatedIps(cloudAccount) + getPublicUnallocatedIps(cloudAccount)let numPublicIps = record.numPublicIpswhere numPublicIps > 0select { "Cloud Account": cloudAccount.name, "Regions or Network Border Groups": record.regionsOrnetworkBorderGroups, "VPC Name": record.vpcName, "VPC ID": record.vpcId, "Count of Public IPs": numPublicIps, "Daily Cost ($)": float(numPublicIps) * costPerIpPerDay, "Monthly Cost ($)": float(numPublicIps) * 30.0 * costPerIpPerDay, "Annual Cost ($)": float(numPublicIps) * 365.0 * costPerIpPerDay} Sample result  

Terms of UseCookie settingsAccessibility statement