Recently active topics

NetBrain currently skips hostname change detection and handling for devices that share a serial number with another device, such as virtual systems on a Checkpoint firewall sharing the serial number of the physical firewall. When the hostname changes on one of these devices, administrators must manually remove and rediscover it to resume configuration retrieval, which results in the loss of historical data for that device. This enhancement would extend hostname change detection and in-place hostname update support to devices with shared serial numbers, allowing NetBrain to recognize the hostname change and update the device record without requiring removal and rediscovery. Customers managing these device types would benefit from continuous configuration retrieval and preserved historical data when hostnames change.

NetBrain's OSPF Highlighting QApp currently depends on NCT subtable data that only supports the Global scope, which can cause the QApp to correctly highlight some OSPF-enabled links while failing to highlight others on the same map. This limitation reduces confidence in the completeness of OSPF topology visualization during troubleshooting. This enhancement would extend NCT subtable support to additional scopes beyond Global, allowing the OSPF Highlighting QApp to evaluate and highlight all applicable OSPF connections consistently. Consistent, complete OSPF link highlighting would give customers greater confidence in topology accuracy and reduce time spent manually verifying missed connections.

Triggered Automation Framework currently does not allow users to export task information filtered to a specific, user-selected time range, nor does it provide a count of tasks that fall within that range. Reviewing task activity for a defined period requires manual inspection of the full task list. This enhancement proposes adding two capabilities to Triggered Automation task views: an export option that generates task detail limited to a selected time range, and a count display that shows the number of tasks matching that same time range. These additions would give customers a faster way to review, report on, and audit automation activity for a specific period without manually filtering or counting task records.

NetBrain currently sends a separate email with an individual CSV attachment for each Network Intent that triggers an alert condition. When many intents trigger simultaneously across a large device set, this results in a large volume of individual emails, each requiring the recipient to open and inspect separately to review the underlying data. This enhancement proposes consolidating alert notifications so that multiple triggered Network Intents within a given cycle are combined into a single email containing an aggregated CSV, or alternatively providing configuration options to batch and control how these alert emails are sent. Customers monitoring large numbers of devices with automated intent-based checks would benefit from reduced notification volume and faster triage of alert data.

NetBrain currently does not provide a way to schedule Ansible tasks and incorporate their results into preventive automation workflows in the same manner that flash probes are scheduled and evaluated today. Customers who rely on Ansible for prechecks, such as collecting software version data, must manage that automation outside of NetBrain and cannot use it to drive conditional actions within the platform. This enhancement would allow Ansible tasks to be scheduled and integrated into preventive automation logic, so that task output, such as version compliance results, can trigger downstream actions like automated change scheduling for non-compliant devices. This would allow customers already standardized on Ansible for network validation to extend their existing automation investment into NetBrain's proactive monitoring and change workflows, reducing duplication of effort across tools.

NetBrain's discovery and benchmark drivers currently rely on the 'show running-config' command, which requires privilege level 15 access on Cisco devices. Some customers manage devices under restricted local accounts with lower privilege levels, where this command cannot be permitted, even though the more limited 'show running-config view full' command is available to them. This enhancement would introduce a driver option to retrieve device configuration using 'show running-config view full' as an alternative to the standard command, configurable in a way that does not affect other tenants or customers in shared, multi-tenant environments. This would allow customers who do not have full administrative access to devices, such as during a transition between service providers, to complete discovery and benchmarking using a reduced set of permitted commands.

When Gateway Fix-Up rules correctly resolve a path, the map visualization does not reflect this resolution and continues to display the affected end node as disconnected from the fix-up device. This creates a mismatch between the accurate underlying path calculation and what is shown to the user on the map. This enhancement would update the map rendering logic so that, when a Gateway Fix-Up rule successfully resolves a node's connection, the visualization displays the node as properly connected to the fix-up device. Consistent visualization would give customers confidence that the displayed map accurately reflects the calculated path, reducing confusion and unnecessary manual verification.

NetBrain currently requires direct network connectivity to managed devices for SNMP, CLI, ICMP, and REST API access, with no supported mechanism to route these protocols through an intermediary proxy. This enhancement would add configurable proxy support for each of these access methods, allowing NetBrain to reach devices in environments where direct connections are restricted or unavailable. Customers operating in segmented or security-restricted network environments would benefit from broader device visibility and management without requiring architectural changes to their existing access controls.

NetBrain currently allows Port-Channel interfaces to be included in a map only through the Layer 2 selection method, which does not support environments where routing occurs across the Port-Channel itself. This limits customers to viewing Port-Channel interface and neighbor relationships strictly as Layer 2 constructs. This enhancement would extend map creation to allow Port-Channel interfaces and their neighbor relationships to be selected and displayed through Layer 3 mapping methods. Customers who route traffic across Port-Channels would gain accurate topology visibility that reflects their actual network design, improving troubleshooting and reducing reliance on manual workarounds.

NetBrain currently does not provide a report identifying which devices experienced authentication failures and which specific credential was attempted during the failed connection. Customers using external authentication services such as TACACS have no visibility into failed credential attempts, which can lead to account lockouts after repeated failures without a clear audit trail. This enhancement would introduce a report that lists devices with failed authentication attempts along with the credential used in each attempt. Providing this visibility would allow administrators to proactively identify problematic credentials, avoid triggering lockouts on external authentication servers, and reduce the time spent manually troubleshooting access failures.

NetBrain currently discovers virtual systems, such as virtual appliances created on top of physical chassis or virtualized application instances, without providing a way to distinguish them from their physical counterparts. Customers must manually investigate each device type or driver to determine whether a discovered system is physical or virtual, which makes it difficult to report accurately on infrastructure composition. This enhancement would introduce a device attribute, such as a boolean flag, indicating whether a discovered device is physical or virtual, applied consistently across supported device types and drivers. Customers would benefit from the ability to quickly identify and report on the proportion of physical versus virtual devices in their environment without performing manual, per-device-type investigation.

NetBrain currently limits site map membership for Azure-based infrastructure to VMware and Azure MSEE device types, which prevents other Azure resources from being represented in site maps. This enhancement would extend site map support to include additional Azure device and resource types, allowing them to be discovered and added to site definitions alongside existing supported types. Customers managing Azure environments would gain more complete visibility into their cloud infrastructure directly within NetBrain site maps, improving overall network management for hybrid and cloud-based deployments.

NetBrain currently does not surface ACI SDN-discovered devices within Site Manager or Site Maps according to the site definition, limiting visibility into how these devices fit within the broader site topology. This enhancement would extend Site Manager and Site Map functionality to recognize and display ACI discovered devices under their associated sites. Customers managing ACI environments would gain a unified view of site-based topology that includes SDN devices alongside traditional network devices, improving overall network visibility and reducing the need for separate tracking methods.

NetBrain currently does not provide a way to automatically trigger a Benchmark task immediately upon completion of a Scheduled Discovery task. Administrators who need both tasks run in sequence must monitor Discovery completion and manually initiate the Benchmark task afterward. This enhancement proposes allowing a Benchmark task to be configured to run automatically once a linked Scheduled Discovery task concludes, without requiring manual initiation. This would reduce administrative overhead and optimize execution time for customers who routinely need Discovery and Benchmark results processed back to back.

NetBrain currently does not consistently report configuration retrieval status as "Succeeded via SNMP" when SNMP retrieval succeeds but CLI retrieval fails, differing from prior behavior customers relied on. This enhancement would restore the status display so that a successful SNMP-based configuration retrieval is clearly reflected even when CLI access fails for the same device. Customers depend on accurate status reporting to distinguish partial access success from full failure, and inconsistent labeling can lead to unnecessary troubleshooting and confusion about device accessibility.

NetBrain currently does not provide a way to export device search results directly from the search interface. Users must first add the matching devices to a Device Group before they can export the list, which adds an unnecessary manual step for simple lookups. This enhancement would add an export option directly on the search results view, allowing users to export the full list of matching devices without first creating a Device Group. Customers who search frequently would benefit from faster access to device lists for reporting, auditing, and troubleshooting purposes.

NetBrain currently allows a Benchmark task to be triggered automatically after a manual Discovery completes, but this option is not available for Scheduled Discovery tasks. Administrators running scheduled discoveries must manually initiate or schedule a separate Benchmark task rather than having it launch automatically upon discovery completion. This enhancement would extend the auto-trigger capability so that a Scheduled Discovery task can automatically initiate a Benchmark task once the discovery run finishes, consistent with the existing manual discovery workflow. This would reduce manual coordination between discovery and benchmark scheduling and help ensure benchmark data stays current without requiring an administrator to monitor scheduled discovery completion times.

NetBrain currently returns device configuration through the API as a single, complete configuration file, with no option to retrieve only a specific portion of that configuration, such as routing protocol sections, access control lists, interface settings, or global configuration blocks. This limitation requires consumers of the API to parse the full file themselves to isolate relevant sections, adding overhead to automation and integration workflows. This enhancement proposes segmenting device configuration into logical categories aligned with common configuration areas and providing an API parameter or endpoint to retrieve a specific segment rather than the entire file. Customers building automation around configuration auditing, compliance checks, or targeted analysis would benefit from more efficient data retrieval and reduced parsing effort on their end.

When a device is configured with only a Privilege password and no Privilege Username, the Privilege Username field in Shared Device Settings displays as empty, giving users no visual confirmation of which credential alias is currently selected. This enhancement would display the associated Alias in the Privilege Username field whenever no explicit username is configured, so the selected credential set remains visible. Customers troubleshooting device connectivity would gain clarity on which credentials are active without needing to modify shared settings that could affect other devices using the same profile.

NetBrain path calculation for Cisco ACI fabrics can currently include leaf switches from a data center or pod that is not part of the actual traffic path, producing a calculated path that does not reflect real forwarding behavior across multi-site or multi-pod ACI deployments. This enhancement would extend the path calculation logic to recognize pod and site boundaries within an ACI fabric, ensuring that only leaf switches within the correct data center are included in the calculated path. Customers operating multi-DC ACI environments would gain accurate path visibility, reducing confusion during troubleshooting and eliminating the need to manually verify which data center the calculated path actually traverses.

NetBrain currently does not provide detailed usage reporting that shows how individual users interact with the platform, including which QApps, Runbooks, DVTs, or features are being used, how many users rely on a given tool, or how frequently specific devices are accessed. The existing Automation Usage overview on the Domain page also lacks clarity, as it does not explain what its figures represent or how they are calculated. This enhancement would introduce detailed usage analytics and reporting covering per-user, per-feature, and per-device activity, including QApp, Runbook, DVT, and automation/diagnosis execution statistics with clearly defined metrics. This capability would help administrators demonstrate platform value to management, identify unused artifacts for cleanup, and compare usage of overlapping functionality against unique capabilities to better guide automation strategy.

NetBrain's UI upgrade process does not currently detect whether antivirus or endpoint protection software is actively running on the server before an upgrade begins. Because such software can block file replacement, executable installation, DLL updates, or Windows service operations, upgrades may fail partway through with permission or access-denied errors that are only discovered after the process has started. This enhancement would add a pre-upgrade check that detects active antivirus or endpoint protection software and displays a warning before the upgrade proceeds, giving the user the option to cancel or continue after acknowledging the risk. Providing this early visibility would help customers proactively adjust their security software settings, reducing upgrade failures, troubleshooting effort, and related support cases while improving overall upgrade reliability.

NetBrain currently does not support filtering VNet and VHub discovery by resource tags within public cloud environments. This enhancement would allow users to specify tag-based criteria when discovering VNets and VHubs, so that only resources matching the defined tags are included in the discovery scope. Customers managing large or multi-tenant Azure environments would benefit from more targeted discovery, reducing unnecessary resource inclusion and improving the efficiency of cloud network mapping.

The OneIP Table currently does not include loopback interface IP addresses, even though it includes other IP types such as Load Balancer Virtual IPs. This creates an incomplete view of all IP addresses present in the environment. This enhancement proposes updating the OneIP Table to include loopback interface IP addresses alongside existing supported IP types, so that the table represents all IP addresses in the system. Customers rely on the OneIP Table as a comprehensive reference for IP address data, and closing this gap would improve accuracy for troubleshooting, auditing, and inventory reporting.

The OneIP Table does not currently include IP addresses associated with public cloud resources, even when those IP addresses are visible within the resource's own detail view. This creates a gap for users who only have an IP address and need to identify the corresponding cloud resource. This enhancement would extend OneIP Table data collection to capture and display name-to-IP associations for public cloud resources, such as those in Azure, AWS, and GCP environments. Customers managing public cloud infrastructure would benefit from consistent IP-based lookup across their environment, reducing the need for manual cross-referencing when only an IP address is available.