Training ...................................................................................................................... 9
RESOLVED ISSUES FOR RELEASE 6.9.1 ...................................................................... 10
KNOWN ISSUES FOR RELEASE 6.9.1.......................................................................... 13
Network Views, Scan Interfaces and VRF-Aware Devices in NetMRI ................................... 18
Making Decisions on How to Use Network Views and Scan Interfaces ................................. 20
Deploying NetMRI in VRF Network Type 1: All Devices on a Management Network ........................... 21 Deploying NetMRI in VRF Network Type 1: All Devices on a Management Network (Part 2) ................. 22 Deploying NetMRI in VRF Network Type 2: All VRFs Reachable from a Shared Services VRF ................ 23 Deploying NetMRI in VRF Network Type 2: All VRFs Reachable from a Shared Services VRF (Part 2) ...... 24 Deploying NetMRI in VRF Network Type 3: Devices Reside in Disconnected Networks........................ 25
Network Automation 6.9.1 Release is an important release that provides major feature additions to Network Automation system management for standalone Network Automation appliances and for Operations Center deployments.
Existing customers will discover that they have greater flexibility in device management and network management workflows. These changes provide significant improvements in network connectivity and network management for both standalone Network Automation systems and Operations Center deployments, including multi-network OC deployments. Existing data is unaffected for your deployment, but some of your methodologies will change as a result of this upgrade. For more details, see the section Additional Changes for 6.9.1 Release.
This release also provides general improvements and fixes for customer-reported issues.
Before upgrading to the 6.9.1 release, 6.7.3 and 6.8.x users using multiple interfaces on their NetMRI, must run a patch file from the Admin Shell CLI to determine service connectivity in preparation for the upgrade. The file is named PreUpgrade-v6.9-CheckServices.gpg. Users running an OC deployment must contact Infoblox Customer Support for more information.
Major Features in Release 6.9.1
Network Automation 6.9.1 offers the following benefits:
Network Views for Managing Multiple Networks
Network Automation 6.9.1 Release uses network views to create separate management domains for each of your networks. You manage every network, including virtual networks, through a separate network view. In previous releases, only a single network at a time could be managed. Each network view can be configured to use its own dedicated discovery settings such as ranges and seed routers. For more information, refer to Configuring Network Views in the Network Automation 6.9 Administrator’s Guide.
Multiple Scan Interfaces
Network Automation now supports multiple scan ports, both physical and virtual. For each network view, Network Automation requires connections to each network to discover, manage, and control device on the network. Scan Interfaces are the ports on Network Automation appliances and virtual appliances that perform this function. For more information, refer to Configuring Scan Interfaces in the Network Automation 6.9 Administrator’s Guide.
Virtual Routing and Forwarding (VRF) Network Discovery and Management
Network Automation 6.9.1 Release provides support for discovery and management of virtual networks that use VRF-Lite protocols.
Device Group Enhancements
Device Groups offer greater flexibility. Network Automation 6.9 now provides two types of device groups: Basic and Extended. You use Basic device groups to contain devices that do not require frequent processing or device licensing, allowing Network Automation to avoid expending valuable resources on them while supporting analysis and automation features.
During upgrades of existing deployments to 6.9.1, all existing device groups become Extended Device Groups. (Consider revisiting your Device Group configurations to see whether any groups may be converted to Basic device groups.) Other improvements are made to the Device Group Editor, Device Group Selector, and to provide higher Device Group scalability.
XML Policy Compliance Enhancements
You can define more powerful Policy rules, including a new XML schema, configuration block checking, variables support, list references, looping logic, object model access, and more. Improved debugging facilities make policy rule development easier and faster.
PCI 3.0 Policies Support
Network Automation policies now support the Payment Card Industry (PCI) 3.0 standard. PCI 3.0 policies now support Cisco IOS and Cisco NX-OS devices.
Admin Shell Command Line Changes
Some changes appear in the Admin Shell CLI:
• The route add command for adding static route configurations is no longer supported. Because Release 6.9.1 supports the use of separate MGMT and multiple SCAN ports, use the configure server command to add a default gateway to the MGMT port or SCAN ports on your appliance.
• The configure ip command is no longer supported. You use the configure server command to modify IP addresses and change routers on Network Automation appliances.
Improved Discovery Topology Analysis to Identify Trunk Port Neighbors
In earlier releases, Network Automation did not detect and report neighbor relationships between switch trunk ports and non-trunked downstream switch ports. As an example, this could present issues for discovery and inventory of ESXi and Hyper-V VM host servers. In Release 6.9.1, when NetMRI detects no switch downstream from those trunk ports, the system correctly reports all end host neighbors of switched trunk ports in Network Explorer End Host and Connected End Host tables, Device Viewer/Interface Viewer neighbor tables and in the Topology feature.
The following sections describe upgrade guidelines, additional device support, EA release limitations and UI requirements.
Additional Changes for 6.9.1 Release
Existing customers will see the following changes in their Network Automation deployment after an upgrade to the 6.9.1 Release software:
• Depending on your appliance model, additional ports will appear that allow network scanning connections to other networks;
• Customers running with active MGMT and SCAN ports configured must run the diagnostic prior to upgrade. If customers do not run the diagnostic prior to upgrade, the upgrade will abort and cause a system reboot. This reboot is normal behavior after an attempted upgrade;
• All active Ethernet interfaces on your appliance(s), including the MGMT port, support Ethernet 802.1Q encapsulation for virtual scan interfaces that may be used for network and device management. For
more information, refer to Configuring Virtual Scan Interfaces in the Network Automation 6.9 Administrator’s Guide. Infoblox recommends retaining the MGMT port exclusively for Web-interface network management, reserving scan interfaces for all discovery and device control;
• If VRF-aware devices exist on your managed network, you will eventually see a System Health banner message notifying you about unassigned VRFs. These unassigned VRFs need to be mapped to network views, which are associated to scan interfaces, to enable full discovery and control in each virtual network. For more information, refer to Configuring VRF-Aware Device Interfaces and Special Considerations for Managing VRF Virtual Networks in the Network Automation 6.9 Administrator’s Guide, and the subsection Preparing for Network Automation VRF Access in the same Guide.
• When you decide to create new network views, you will also begin to find Network View data columns and selectors throughout the GUI, including in the primary Network Explorer pages, Settings features, and Device Viewer/Interface Viewer tables.
• The Network Insight tab is renamed Network Explorer. • For efficiency, Network Automation 6.9.1 systems produce a substantially smaller system archive file.
All information remains present in the archive file. Changes to the archiving processes create smaller files but also require longer archive restore time periods.
• Installations of Operations Center Controller appliances changes in Release 6.9.1. For initial appliance setup, you run the following sequence of Admin Shell commands from the Network Automation command line:
configure server
license
configure server
configure tunserver
For Collector appliances, the command sequence is as follows: configure server
license
register
For details, refer to the chapter Installing and Deploying the Network Automation Operations Center in the Network Automation 6.9 Administrator’s Guide.
Multi-Network Operations Center Upgrades
For Operations Center deployments, existing customers will also see the following changes:
• Upgrading Multi-Network Operations Center deployments will automatically assign each managed network to a new Network View. Each network view is named based upon the original network names. Collector scan interfaces are automatically associated with those network views based on the previously defined network management settings.
• Upgrading Multi-Network Operations Center deployments automatically defines a new set of device groups for each managed network, along with the standard set of device groups. These network-specific device groups are named using the original network name as a prefix. Each network-specific group set includes the standard groups and any custom device groups previously configured in the deployment.
• During an upgrade, a Multi-Network Operations Center deployment creates a series of new network views, each of which corresponds to the networks managed under the prior software release.
• While upgrading Multi-Network Operations Center deployments, discovery settings for each network, including CIDR discovery ranges, static IPs and seed routers, are automatically associated with the newly created network views.
For details, refer to the chapter Installing and Deploying the Network Automation Operations Center in the Network Automation 6.9 Administrator’s Guide.
6.9.1 Software Upgrades vs. New Installations
This section briefly lists the effects of migrating existing platforms to the 6.9.1 release.
Many customers will see a straightforward upgrade or installation process, when their deployments do not require significant multi-network management or virtual network management configuration. Consult the following table for details on possible migration changes to your platform.
Step Number Migration of Existing Platforms New Installation
1 Upgrade your software using the Admin Shell autoupdate utility.
Install new appliance(s) and perform system configuration through the Setup Wizard.
2 Currently managed network(s) are converted to new network views using the same network name.
Configure network views (if required) for multiple network management.
3 Scan interfaces are automatically associated with the network views created from the previously defined Networks.
For more information about creating network views and how to configure NetMRI to manage multiple networks, consult the final section Network Views, Scan Interfaces and VRF-Aware Devices in NetMRI in this document.
Also refer to About Network Discovery in the Network Automation 6.9 Administrator’s Guide and its subsections Discovery with an Existing Network Automation Platform and Discovery with a New Network Automation Deployment.
Limitations for the 6.9.1 Software
• Data collection is shut down on Operations Centers during the upgrade to 6.9.1. In Operations Center Controller-to-Collector communications, all collected network data passes from the Collector to the Controller through a tunnel connection. Tunnel connections are shut down during upgrades to the 6.9.1 release.
• Inbound TFTP/HTTP File Transfers from VRF-Aware Devices. Network Automation provides Config Template and Rollback features, during which the involved devices initiate the file transfer connections. Due to the adoption of Network Views in 6.9.1, a device initiating a connection to Network Automation needs to specify the interface it has present in the correct network view. However, this is not consistently possible on supported VRF-aware devices. WORKAROUND: TFTP/HTTP file transfers on VRF-aware devices will work when the NetMRI manages the device on the device’s default VRF; when the device’s Management IP address is on an interface in the device’s default VRF (such as (default)IOS for Cisco IOS, default for Nexus and master for JunOS). If Network Automation cannot reach the VRF-aware device through the device’s default VRF, this feature will not be available.
• SNMP Credentials in Juniper VRFs. For discovery and periodic polling on Juniper devices through an interface that is not in the Juniper default VRF (master), the query must use a special “default@credential” format. This setting assumes that users do not have management interfaces in a VRF. Hence, the SNMP credentials for VRF-aware Juniper devices must use syntax similar to: “@vrfsnmp.” Enter these values for SNMP credentials under Settings icon –> Setup –> Credentials –> SNMP v1/v2c tab. (When querying VRF-aware Juniper devices via an interface that is in the default VRF, a plain community string can be used without the “@” character.)
• After upgrading to 6.9.1 customers must update existing syslog forwarding configurations. Each syslog configuration must be updated to include the network view of the destination syslog server.
GUIDELINES FOR UPGRADING TO NETWORK AUTOMATION 6.9.1
The 6.9.1 release requires Support assistance for migrating Operations Center Multi-Network deployments from earlier releases. If you are running an Operations Center Multi-Network deployment, and you are interested in running the 6.9.1 release, contact Infoblox Support or your Infoblox Sales representative.
Network Automation 6.9.1 can be applied as an upgrade to systems running NetMRI 6.7.3 or 6.8.x. Customers at an earlier release must first upgrade to NetMRI 6.8.7, prior to applying the 6.9.1 upgrade. For upgrading to 6.9.1, the upgrade image file is ib_network_automation-6.9.1.77369.gpg. Run the standard AutoUpdate utility from the Network Automation Admin Shell to perform the upgrade.
The list of upgrade paths supported in this release includes the following:
Ensure that Sandboxes (either Local or Remote) are fully and properly upgraded:
• Local sandbox instances for Network Automation will be automatically upgraded to 6.9.1.
• Remote Sandbox instances (e.g., Sandbox instances on a VM server) must be manually upgraded using the ‘sandbox reset’ command from the admin shell. See the topics Using the Network Automation Sandbox and Setting Up a Remote Sandbox in the online Help for more information.
Supported VMware Versions
Infoblox offers Network Automation in a virtual machine version. Supported VMware versions now include ESXi 5.0x and ESXi 5.1x. The following VMware releases support Network Automation 6.9.1 VM operation:
• ESXi 5.0x and ESXi 5.1x
• VMware Workstation 9.0 and 10.0
• Fusion 5.0.3 on Mac OSX 10.8
Device Support Updates
The following devices are newly supported in Network Automation 6.9.1 as noted below:
NETMRI-22833 – Hard drive status incorrectly being set to Drive Authentication Status on NT-4000.
NETMRI-22783 – Nexus 7000 - "Port not found" error in CLI response will result in failed discovery.
NETMRI-22761 – SSLv3 must be disabled in Apache and Tomcat to ensure compliance with CVE-2014-3566.
NETMRI-22750 – Inconsistent SNMP/switch port processing of ifConfig-ifTrunkStatus values cause continuous policy checking.
NETMRI-22697 – NetMRI is vulnerable to a SQL injection attack with a specifically formatted URL.
NETMRI-22652 – Exporting DSBs fails with a less than helpful error message.
NETMRI-22640, NETMRI-22330 – HARD200 system health warning even when iLO instrumentation reports normal temps.
NETMRI-22631 – Some System Health messages appear without cause, indicating that a minimum threshold is necessary.
NETMRI-22571 – UI issue when editing scheduled jobs with a large number of devices.
NETMRI-22567 – Change in Ambient temperature sensor name causes false positive system health warning.
NETMRI-22564 – Title of Storage Trend Chart is confusing.
NETMRI-22563 – No System Health displayed on standalone appliance.
NETMRI-22550 – NetMRI treats domain name text as a case-sensitive string. Domain names should be treated as case-insensitive, matching the DNS protocol.
NETMRI-22547 – NetMRI incorrectly determines OSPF is enabled, causing extra polling which triggers CPU-HOG messages on device.
NETMRI-22545 – Unexpected System Health messages after an upgrade.
NETMRI-22485 – Neighbor IP Addresses are not collected on LLDP table and config collection needs an update for Alcatel OS10000 Version 7.3.1.748.R01.
NETMRI-22470 – The Interface Broadcasts High issue’s ‘In Broadcast Rate' column uses a string sort, when it should be numeric sort.
NETMRI-22464 – Renumbering of config report tables may fail with a Duplicate Entry error.
NETMRI-22424 – Running "repair" from admin shell resets Interface Group settings.
NETMRI-22382 – Invalid JobID in API Job_Update call causes no new jobs to be created or scheduled
NETMRI-22363 – Scheduling a job based on config search results never populates the Job Wizard with the selected devices
NETMRI-22342 – Perl script showing duplicate data returned by API, and occasional timeouts.
NETMRI-22339 – Some Policies take a long time to complete, occasionally resulting in System Processing Capacity is Being Exceeded alerts.
NETMRI-22323 – GUI Error while sorting Summaries -> Ports by Type table.
NETMRI-22274 – Observed an error in SNMP collection of the SwitchPort object on a Cisco device.
NETMRI-22235 – Failing to collect configurations for BlueCoat SG900 proxy devices.
NETMRI-22234 – Nortel Config Collection script is not looking for BayStack* model devices (though they are supported for Config Collection).
NETMRI-22193 – OS version is not detected for Cisco ACE 4710K9 devices.
NETMRI-22192 – CLI route collection discards BGP routes at route limit but does not replenish with non-BGP routes up to the route limit.
NETMRI-22191 – FireEye wMPS 4310 device models not being reported properly.
NETMRI-22175 – Unable to get configurations for Nortel ERS8600 devices after a NetMRI upgrade.
NETMRI-22146 – Duplicate data in output from device->index() API call.
NETMRI-22142 – Reset admin on OC should reset admin password on collectors.
NETMRI-22141 – Device Group screen allows saving of invalid criteria.
NETMRI-22139 – VLAN STP Timers Differ Issue is firing incorrectly for Nexus 5K running 6.x NXOS.
NETMRI-22113 – Scheduled Custom report showing neighbors drops total each day.
NETMRI-22094 – NetMRI does not clear DNS cache in the appliance.
NETMRI-22093 – End-Host Expiration value type is misleading as days and not hours.
NETMRI-22089 – Web UI HTML links use wrong Device ID for some devices.
NETMRI-22087 – Interface Errors High issue table needs floating point display for percent errors values
NETMRI-22068 – Some of the logging to /var/log/messages is duplicated in other log files and not severe enough to warrant logging to /var/log/messages, making it harder to analyze valid logs.
NETMRI-22045 – NetMRI Policy Rule Sorting does not work as designed.
NETMRI-22042 – Cisco Nexus SNMP requests of specific types may contain invalid characters.
NETMRI-22038 – Unknown error occurs while trying to access Issues Viewers.
NETMRI-22029 – TLS / SSL Vulnerabilities in NA CVE-2007-1858 & CVE-2013-2566.
NETMRI-22023 – Under the Device Viewer -> Vlan -> Root Bridge column, a “No data available for this device” message appears when clicking on the value in the Root Bridge field.
NETMRI-21984 – GUI not accessible for 4k appliance, SOFT050 System Health message during weekly maintenance.
NETMRI-21971 – Online and Network Automation Application Programming Interface Version 2.9 documented examples of Perl API do not compile when using strict rules.
NETMRI-21966 – OC: Collectors with more than one subscribers’ directory will cause PROC070 health alerts
NETMRI-21949 – Unable to write logs under Job Details Viewer -> Custom Logs tab while executing a script against device groups.
NETMRI-21948 – Unable to add SNMPv3 credentials with a "?" in the password field(s).
NETMRI-21929 – The "Config Bad Password" issue is renamed to “Unknown Password Configured”, and will now only be raised when Network Automation does not have CLI credentials for a device. It will no longer be raised for login passwords that provide privileged-mode access.
NETMRI-21910 – Static Discovery Ranges added to OC not replicated to collectors
NETMRI-21891 – Scheduled Reports sent via email contain the incorrect [email protected] email alias.
NETMRI-21888 – HP8692A Error collecting Switch Port Forwarding Table – also seen with other HP models.
NETMRI-21870 – Incorrect config collection timestamps used in OC setup - should use timestamps sent from Collectors.
NETMRI-21796 – Problems with Config Templates for HP Switches.
NETMRI-21785 – Custom Report Email .CSV file Column Headings do not match On-Demand Column Headings.
NETMRI-21688 – C3750 Router typed as Router not Switch-Router.
NETMRI-21482 – Jobs show as failed but actually completing successfully.
NETMRI-21265 – Issue Viewer appears blank in rare instances.
NETMRI-21212 – OSPF Area not in Backbone - showing inaccurate data in Settings -> Issue Analysis -> Suppression
NETMRI-20913 – Scripts/run controller returns success even though sandbox is not fully up and running.
NETMRI-20897 – Excessive calls to OC from collectors for neighbor relationships.
NETMRI-20779 – Customer import of device support bundle fails with no logs to help diagnose the problem.
NETMRI-20754 – OC should not process Jobs off queue if sandbox is unavailable.
NETMRI-20669 – Misspelled descriptions in issue analysis.
NETMRI-20032 – “Large Device Count” and “Device Limit Possibly Exceeded” messages for discovery statistics are inaccurate and may not match values shown in System Health.
NETMRI-19852 – Operations Center: Noticeable latency for completed jobs and viewing their associated scripts, session logs and other files.
NETMRI-19705 – IPAM Admin password stored in NetMRI can be displayed as plain text.
NETMRI-19332 – No IP address (instead of 0.0.0.0) appears for devices in HSRP group in Initial state.
NETMRI-19044 – You may not be able to select Today’s Date in the Device Viewer’s Network Analysis -> Issues page.
NETMRI-18701 – Error registering Collector to Operations Center, if documented process is not strictly followed.
NETMRI-18141 – Custom scripts fail with errors when the task is in fact successfully performed by the script, based on specific Cisco messages that are misinterpreted as errors
NETMRI-11206 – Scheduling the Issue Details report displays incorrectly formatted HTML notification data.
NETMRI-22889 – Software changes caused removal of a Basic Device Groups feature called Include End Hosts, causing docs to be out of sync. The Include End Hosts feature is not present but is stated in the following topics: Creating Device Groups, Using Different Network Topologies and Operational and Deployment Best Practices. This information will be updated in a forthcoming maintenance release.
NETMRI-22853 – For managed virtual networks, some BGP routes are not displayed in the routing tables for the router device in the Device Viewer when route leaking is performed between multiple virtual routing and forwarding (VRF) instances on a VRF-aware device. All the leaked routes into a particular VRF should be displayed in the Device Viewer -> Router -> Route Table and Network Explorer -> Summaries -> Routes pages.
NETMRI-22842 – Scheduled Archive is failing with the message “Error: Connection to mysql child process.”
NETMRI-22834 – Device type "Comm Server" not licensed automatically by NetMRI though it is supported.
NETMRI-22832 – Juniper EX devices with Interface/subinterface configurations have the VLAN configuration on the subinterface, but the SPM Access Ports Present table displays the Interface (not the subinterface), so the VLAN information is not populated.
NETMRI-22820 – Config Templates with quotemark characters are not compatible on HP Switches.
NETMRI-22802 – Scripts run on collector can falsely return success under certain conditions.
NETMRI-22800 – Should not be able to do a restore database while the skipjack service is starting/stopping or while an archive/restore is already running.
NETMRI-22785 – ifAddr table not collected from Nexus 7010 for a long period of time.
NETMRI-22717 – Device Group data may cause unavailable Network Automation GUI.
NETMRI-22695 – NetMRI Public Key Authentication causing excessive entries in audit logs.
NETMRI-22612 – Jobs fail with 'HTTP 302 Found' when HTTP 202 Accepted is returned to the OC. changing to HTTP 200 OK works.
NETMRI-22608 – Device Restart Notification Subscription sending multiple alerts for a single reboot.
NETMRI-22594 – Incorrect XML format for config backup.
NETMRI-22570 – Cannot select all interfaces on a device or for a device group when creating a report on Interface History data.
NETMRI-22544, NETMRI-22515 – NetMRI polling interfering with CiscoWorks.
NETMRI-22500 – In the main Network Explorer -> Discovery page, the SC icon may show its status as OK with an old timestamp when the S icon shows failed status.
NETMRI-22489 – Applies only when multiple scan interfaces are being used in the deployment. In cases where a hostname is specified under Tools -> Device -> Ping/Traceroute, the hostname is always resolved against the DNS server of the MGMT interface, regardless of which Network View is selected. For systems with multiple scan interfaces, this may result in incorrect or unexpected resolution if the MGMT interface DNS does not have an entry for the host name, or if an entry exists that refers to another device on the MGMT network.
NETMRI-22468 – Threshold values not honored for "Downstream Hub or Switch" issue.
NETMRI-22455 – Issue Subscription generates an incorrect SNMP Trap issue.
NETMRI-22454 – Invalid JobID value in API Job_Update call causes no new jobs to be created or scheduled.
NETMRI-22449 – Save feature is disabled after deleting credentials for Remote System 2 in Scheduled Archive settings.
NETMRI-22446 – After upgrading a single-network Operations Center to 6.9, the Network View name in the grids may be different than the Network View name in the Settings -> Network Views table, showing the View name as the network name of the Operations Center. This value is incorrect; the correct Network View name appears in other locations in the Network Automation UI, including in Network Explorer -> Discovery. WORKAROUND: Open the Settings -> Network Views page and re-name the network view to the correct value. After doing so, the Network View names will be in sync.
NETMRI-22331 – NetMRI does not consistently detect CLI credential changes.
NETMRI-22212 – Deleted "default" SNMP credentials get repopulated after an upgrade/hotfix.
NETMRI-22200 – Applies only for migration of Operations Center deployments to the 6.9.1 release. Archive databases are not migrated during an OC migration to the 6.9.1 release. By default, a single month’s worth of data histories will be reflected in the system after the migration to 6.9.1. WORKAROUND: Under Settings -> Database Settings -> Data Retention, change your Archive After settings for Network Inventory History, Change Record History, and any other necessary data categories to values higher than the default of 30 days. Also, adjust the Delete After value should you wish to use a higher Data Retention value than the default Delete After value for each data category. Note that increasing the Archive After settings will increase the amount of disk space used by the current data categories.
NETMRI-22096 – The discover method from the Devices API says all outputs are booleans
NETMRI-21890 – Unable to Resync the collector settings from the GUI due to password de-synchronization.
NETMRI-21815 – Running maintenance from admin CLI will be killed if the ssh session is dropped
NETMRI-21779 – DB Archive and Scheduled Archive settings not preserved after tab navigation for invalid values for any single Remote System.
NETMRI-21778 – An expired certificate prevents access to Settings without the ability to reset the certificate.
NETMRI-21738 – CPD: the required block is not evaluating properly when a config file contains parentheses ( ) characters.
NETMRI-21563 – NetMRI fails to guess SNMP credentials for Corvil devices.
NETMRI-21483 – In Operations Center, using a Perl script to define static Discovery Settings with a custom field changes the UnitID of target devices’ discovery settings under Settings -> Setup -> Discovery Settings.
NETMRI-21232 – Network Explorer -> Discovery does not honor User Role settings.
NETMRI-20802 – OC: Jobs remaining in Pending after job Success is reported.
NETMRI-20799 – User can’t define the length of periods of time contained in a Config Archive.
NETMRI-20739 – User swapped out a collector, powering off the old collector and registering the new collector appliance, but when the old appliance was later turned back on, it continued data collection (both appliances were performing data collection on the same devices) and generated backpressure messages to the OC.
NETMRI-20682 – Device Group Counts in GUI may be incorrect due to Devices expiring or being rediscovered.
NETMRI-20621 – Reboot during database archive may lead to bad MySQL Trigger.
NETMRI-20577 – OC/Collector health monitoring will not detect down Collector when VPN tunnel is still established, even if Collector is no longer processing.
NETMRI-20365 – Scheduled database archives may intermittently stop working.
NETMRI-20283 – If credentials are manually entered for a device, CLI credential guessing does not consider them for bulk multi-select discovery.
NETMRI-20250 – When jobs are sent to a collector and the collector is down or goes down before job completion, the jobs may remain in varying states of completion without ever finishing.
NETMRI-20234 – Policy XML scripts may incur backlogs in execution.
NETMRI-20061 – Device Group with "&" in name causes devices to become UNASSIGNED.
NETMRI-20033 – NetMRI displaying error message while running 30 days built in reports
NETMRI-20004 – Fingerprint data causing incorrect Device Type assignment.
NETMRI-19796 – Typing Cisco ASR 1000 as HSRP device prevents device discovery.
NETMRI-19741 – Perl Job shown as running on Operations Center did not run.
NETMRI-19706 – Remote Sandbox displays 'Net-SNMP' as Vendor under Network Automation.
NETMRI-19687 – Upgrading from 6.7.3 may produce a "Lost connection to MySQL server during query" message.
NETMRI-19653 – Removal of message displayed during Discover Now operation.
NETMRI-19394 – Forwarding data not collected with SNMPv3 in Enterasys E-Series 1H152x50 and 1H582x25 devices.
NETMRI-19298 – FindIT does not indicate where Neighbor Data comes from, causes confusion in the Device Viewer
NETMRI-19231 – NetMRI using public IP space (39.0.0.0) for sandbox communications.
NETMRI-19229 – Sandbox configure command does not properly change the IP of the local sandbox.
NETMRI-19272 – Operations Center: Two distinct networks, named Custom and Default, appear in the right pane of any Device Group window when the Operations Center is configured for a single network. Workaround: Run the refresh groups command from the CLI, which will reset the device groups and begin displaying the correct network listing.
NETMRI-19229 – The “sandbox configure” command does not correctly change the IP address of the Local Sandbox.
NETMRI-19200 – Script Names should not accept a character length of greater than 80 characters.
NETMRI-18689 – DISA v8 rules are listed, but not implemented for severity Info and below.
NETMRI-18138 – Excessive change notifications reported from devices.
NETMRI-18066 – The Job Details Viewer logs do not show any information for skipped state jobs when a device is unlicensed or unmanaged, or when CLI credentials are not guessed.
NETMRI-18000 – Some switch forwarding tables on trunk ports becoming too large.
NETMRI-17798 – Network Automation DNS entry is seen in local firewall. WORKAROUND: Ensure that configuring NetMRI and changing DNS Servers correctly updates the DNS Server entries in /etc/resolv.conf on the Sandbox.
NETMRI-17991 – The Implicit Deny rule is not recognized as a rule blocking traffic, allowing warnings regarding blacklisted protocols that would be implicitly denied, but where no specific rule is present.
NETMRI-17802 – Remote Database Archive failing after upgrade.
NETMRI-17798 – NetMRI entry is seen in the Firewall.
NETMRI-17796 – Running a Discover Now on a single IP address sometimes incurs an excessive time period to complete.
NETMRI-17779 – LOGIN_FAILED message on Cisco 2960 switches when NetMRI attempts CLI authentication.
NETMRI-17648 – Occasional HTTP 503 error messages when trying to view reports.
NETMRI-17554 – Under Network Explorer -> Topology, switches and firewall devices occasionally may appear as associated with the Routing device group.
NETMRI-17060 –Reports including the Device Timestamp = Month setting can give unexpected results.
NETMRI-16775 – Changing a network name in Network Automation may result in related data not properly updating, such as End Host MAC values.
NETMRI-16655 – The chart from selecting Network Analysis -> Issues by device with historic chart does not display daily values correctly.
NETMRI-16399 – Left panels in the UI sometimes do not retain state for some Configuration Management pages.
NETMRI-16361 – Jobs run as System User do not track who originally initiated them.
NETMRI-16120 – View Members action menu option on an Operation Center’s Settings -> Collectors and Groups -> Groups table is disabled for non-Admin accounts. The option still works for the system admin.
NETMRI-15260 – An Appliance will occasionally hang during the shut-down phase of reboot, requiring that the system be manually power-cycled. Note: This was believed resolved as of 6.8.1, but subsequently an issue was found in the Linux kernel that was contributing to this issue. The kernel has been corrected as of 6.8.4 with an additional kernel patch in 6.8.7, and a hardware watchdog is added as of 6.8.6. The caveat is left open, as we want any customer who experiences this issue to immediately contact customer support.
NETMRI-14925 – NetMRI login to Cisco devices running IOS-XR firmware logging 'Terminal type not supported’ messages.
NETMRI-13970 – Unable to deploy Custom Issue Help Files.
NETMRI-13633 – Unable to change Management IP Address for devices who do not respond to SNMP on Management IP Address.
NETMRI-11964 – Allow CCS and Perl scripts to override current prompt regular expression on a per send_command basis.
NETMRI-10778 – If data synchronized with NIOS IPAM is not from very recent network discovery, IPAM may declare false conflicts.
NETMRI-10239 – Cannot adjust / redefine how long a device does not appear in ARP table entries before it is included for expiration.
NETMRI-10146 – Issue Viewer: Last Seen Time Stamp is showing current date and Time even if we selected the Previous dates for Interface Not Stable issue
NETMRI-9069 – API Calls do not handle long-running commands.
Network Views, Scan Interfaces and VRF-Aware Devices in NetMRI
The topology of your network helps determine how you will deploy and use NetMRI for VRF network management. To use NetMRI effectively in the network, you must possess some knowledge of what your network ‘looks like,’ and also where it makes sense to place NetMRI to reach all the virtual networks you want to discover and manage. In this section, we define a few of the most common VRF-related network types, which cover most possibilities for how you will deploy NetMRI for greatest effect.
In all examples, we also answer the questions of how many network views you need, and how many scan interfaces you need to reach all locations in the network.
We describe three network types in the first part of this section:
1. VRF Network Type 1: A network with a Management VRF, and several isolated production VRFs, with VRF-aware devices in the network;
2. VRF Network Type 2: A network with a Shared Service Deployment VRF (here called a “shared VRF”) and several isolated production VRFs, with VRF-aware devices in the network. The production VRFs share routes with the shared VRF, a practice also called route-leaking;
3. VRF Network Type 3: A network with several VRF-ignorant devices that reside in different L3 spaces, with no management VRF.
VRF Network Type 1, the first network type, has the following characteristics:
• A Management VRF that reaches all VRF instances throughout the network;
• Isolated Production VRFs (all VRFs can route to/from the management VRF but not to one another);
• The Management VRF has complete visibility to all VRF instances in the network.
VRF Network Type 3, the third network type, has the following characteristics:
• Devices have management IPs only inside their respective networks;
• The routers in the network are VRF-aware; the switches are VRF-ignorant.
Making Decisions on How to Use Network Views and Scan Interfaces
How do you tie NetMRI into your network?
In deployments of all three types, you need to choose whether you want one or multiple network views. The choice is based on how your network operates, as outlined in the three network types above.
• When all infrastructure devices for the network are reachable through a management VRF or a shared services VRF, and you do not need extended discovery capabilities to discover and/or manage end hosts, you can use a single network view. You also use a single virtual scan interface to connect to the same 802.1q ID as the management VRF network. You can then discover and analyze all VRF-aware devices on the management VRF. Examples follow. o If you want your devices’ end host and downstream devices information separated for viewing and
reporting, then you will want to use network views for each virtual network. Doing so is helpful for visual purposes, but it is not required.
• If you want ping sweeps, port scanning, fingerprinting and other discovery services into end hosts within each of your VRF networks, you need multiple network views, one for each of your VRF networks, each of which requires an associated virtual scan interface and discovery ranges. Examples follow.
Deploying NetMRI in VRF Network Type 1: All Devices on a Management Network
The following figure shows an example of integrating NetMRI with Network Type 1:
This initial example shows the following:
• Network Views: Create a network view in NetMRI per network (e.g., Management, Red, Yellow, Green);
• Scan Interfaces: Add the active scan interface to the Management network;
• Discovery Ranges: Define IP discovery ranges in NetMRI for the management network.
In this network deployment type, a single virtual scan interface can manage all VRF instances’ identification of ARP entries, because NetMRI needs only one scan interface into the Management VRF. The following example shows how to deploy NetMRI using multiple network views and multiple connections.
Deploying NetMRI in VRF Network Type 1: All Devices on a Management Network (Part 2)
The following figure shows the same topology as the previous example, but using multiple scan interfaces, and multiple network views:
• Network Views: Create a network view in NetMRI per network (Management, Red, Yellow, Green);
• Scan Interfaces: Create virtual scan interfaces in NetMRI for each VRF network;
• Discovery Ranges: Define IP discovery ranges in NetMRI for each VRF network.
In the above example, the switch must be configured with the trunk port ‘facing’ NetMRI to forward NetMRI’s tagged 802.1q traffic to the appropriate destination networks (VLAN 5, VLAN 10, VLAN 20 and VLAN 30 in this example).
The encapsulated subinterfaces are defined using the correct values on each port; the virtual scan interfaces on NetMRI match these values.
Deploying NetMRI in VRF Network Type 2: All VRFs Reachable from a Shared Services VRF
The following two examples illustrate the use of a Shared Service VRF between the distribution routers in the network and how NetMRI integrates into such a topology:
All virtual networks are reachable through a shared VRF, to which NetMRI may connect using a single virtual scan interface and reach all other VRFs from the one to which it is connected. Each Router in this topology also shares routes between the VRFs.
• Network Views: Use one network view in NetMRI, which is used for the shared VRF;
• Scan Interfaces: Create a virtual scan interface on the network view. Use a single virtual scan interface in NetMRI, and connect through the facing switch to the shared VRF using the tagged 802.1q value. There is a 1:1 ratio between network views and scan interfaces;
• Discovery Ranges: Define IP discovery ranges in the single network view for all VRFs.
How do you decide whether you want a single network view or separate network views for this network? If you want your devices’ end host and downstream devices information separated, then you will want to use network views for each virtual network. This is helpful for viewing and reporting but it is not required. In the figure above, only a single network view is applied.
Deploying NetMRI in VRF Network Type 2: All VRFs Reachable from a Shared Services VRF (Part 2)
In this version of the VRF Network Type 2 deployment, you use multiple network views and multiple scan interfaces in a 1:1 ratio, with the same requirements for trunking and switch VLAN subinterfaces.
• Network Views: Create a network view in NetMRI per network (e.g., Management, Red, Yellow, Green);
• Scan Interfaces: Create virtual scan interfaces in NetMRI for each VRF network;
• Discovery Ranges: Define IP discovery ranges in NetMRI for each VRF network.
Deploying NetMRI in VRF Network Type 3: Devices Reside in Disconnected Networks
In the final example, trunking is in use between NetMRI and its facing gateway switch into the managed network. This topology requires the use of multiple network views as all VRF networks are completely separate and cannot be reached through any management virtual network.
• Network Views: Create a network view in NetMRI per network (e.g., Management, Red, Yellow, Green);
• Scan Interfaces: Create virtual scan interfaces in NetMRI for each VRF network;
• Discovery Ranges: Define IP discovery ranges in NetMRI for each VRF network.
Each of the network views requires a single virtual scan interface using 802.1q tagging as indicated in the figure. When defining the virtual scan interfaces, use the 802.1q tag from the network devices. The primary differences are as follows:
• All devices do not have a management IP address in the so-called management VRF;
• The routers are VRF-aware while the switches are not;
