Recently active topics

we are using below format to collect the data from Fortinet firewall for custom command. endconfig globalshow system dnsshow system ntp can anyone check and confirm ,these will not impact anything ,if i remove config gloabl , than command will not run. 

There is a specific section of the AFM config which refers to the default action of the firewall, the below query checks that the default action is Drop.F5 AFM Config to check for.}sys db tm.fw.defaultaction {    value "drop"} /** * @intent Check that all F5's that are running AFM have the default action set to deny * @description THis will check sys db tm.fw.defaultaction for the value drop and error * if it is not drop. **/// Note {} have been removed as they can not be included in the pattern.defaultPattern = ```sys db tm.fw.defaultaction value "drop"```;foreach device in network.deviceswhere device.platform.os == OS.F5foreach command in device.outputs.commands//Check for only the F5's with AFM Configwhere command.commandType == CommandType.F5_AFM_CONFIG//Extract the command response.let AFMConfig = parseConfigBlocks(OS.F5,command.response)//Match the patternlet match = blockMatches(AFMConfig,defaultPattern)let violation = if length(match) == 0 then true else falselet DropActio

 Here are a set of 3 scripts for:NXOSEOSIOS (and IOS-XE)The scripts look for configuration related to source interfaces.  Over the years, engineers have used Loopback0, dedicated management interfaces, Loopback10, or other random interfaces to source traffic from. We have an an inititiative to clean these inconsistencies up.These scripts parse through the configs looking anything related to the ‘source-interface’ or ‘local-interface’ etc. Then it finds the associated configuration of those interfaces, such as IP Address, VRF, description.I have also tuned them to ignore parts of the configuration that are not important to the effort , ex:no ip redirectsno ip route-cacheno ip unreachablesno ip proxy-arpip mtu {number}load-interval {number}ip helper-address {string}negotiation autostandbye {string}etc...Cisco NXOS/*** * @intent Source-Interface Extraction (NXOS) * @description Extracts all source-interface configs and interface details from config text.***/// --- 1. Helper Functions ---g

Forward brings in Fortinet firewalls as the device its self and the VDOM’s this becomes challenging when you need to validate the tacacs configuration for the physical device this means quite often the vdoms or even the root vdom will fail even though tacacs is configured on the device.The simple solution is to add a permitted violation list, however this needs to be maintained manually there must be a better solution surely?userTacacs =```config user tacacs+ edit "TACACS" set server [server 1 IP Address] set secondary-server [server 2 IP Address] set key ENC {string} set secondary-key ENC {string} set authorization enable nextend```;systemAdmin = ```config system admin edit "tacacs" set remote-auth enable set accprofile "no_access" set vdom {vdoms:string} set wildcard enable set remote-group "TACACS_ACCESS" set accprofile-override enable```;foreach device in network.deviceswhere device.platform.v

Managing an on-premises network intelligence platform should be straightforward — and with Forward Enterprise Appliance 16.5 and the upcoming version 17, we're making it significantly easier and more secure.Here's what's changing and why it matters.A New Way to Administer Your ApplianceStarting with version 16.4, we introduced a Text User Interface (TUI) — a guided, menu-driven environment accessible via SSH or the console. Rather than navigating the underlying Linux OS directly, administrators now have a single, purpose-built interface for every common task.The TUI covers everything from initial node configuration and cluster deployment to Forward Enterprise upgrades, security settings, and built-in diagnostics — all in one place.Version 16.5: Refinements Based on Your FeedbackForward Enterprise Appliance 16.5 (available May 2026) is the last release in the 16.x line to include open shell access. It brings vulnerability fixes and TUI improvements based on early adopter feedback. If yo

Children LinesThis document aims to improve understanding of how NQE parses Cisco-like configuration. It also provides templates for common NQE checks related to configurations.  Forward NQE takes Cisco-like configuration and parses it into a subset of “parent” and “child” lines. The “parent” and “child” relationship is based on the number of indents in front of each line. Each Cisco configuration always starts with a line with no indent in front of it. (e.g. “router bgp 65000”). Some configurations, referred to by Cisco as “global configurations” such as “feature bgp”, do not have additional parameters, and therefore they do not have “children” lines. Others, such as “router bgp 65000”, require additional parameters to configure that particular feature.  In the below example, “router bgp 65000” is the main parent line consisting of “children” that are line 2-4, 7, and 10. Furthermore, the child lines 4, 7 and 10 each have additional “children” lines of their own; line 4 has lines 5-6;