This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Network Automation 6.8.7 Maintenance Release is an important update that provides performance improvements and fixes for customer-reported issues.
Customers running Network Automation 6.8.6 and earlier are encouraged to update their systems to this release at the earliest opportunity.
Network Automation 6.8.7 is a cumulative release and includes all resolved issues from release 6.8.1 through 6.8.6. These Release Notes are also cumulative, and list resolved issues from releases 6.8.1 through
6.8.6, with a list of Open Issues as of the 6.8.7 Maintenance Release.
The following sections describe upgrade guidelines, additional device support, resolved issues, and known issues.
GUIDELINES FOR UPGRADING TO NETWORK AUTOMATION 6.8.7
Network Automation 6.8.7 can be applied as an upgrade to systems running Network Automation 6.6.3, 6.7.3, or 6.8.1 through 6.8.6. Customers at an earlier release version must first upgrade to one of the listed
releases, prior to applying the 6.8.7 upgrade.
Note: Even though upgrades from 6.6.3 and 6.7.3 are supported, upgrades from 6.7.1 or 6.7.2 are not. If running one of those versions, upgrade to 6.7.3 first.
Warning: Previous caveats about upgrades starting from the 6.6.3 and 6.7.3 releases still apply. A slight possibility exists that an upgrade from those releases may result in a system that requires a power-cycle during the upgrade-reboot process. Additionally, warning messages about connecting to MySQL may be displayed during the upgrade process. Corrections have been made, and upgrades from earlier versions of 6.8.x have not shown these problems.
For customers at 6.8.x with systems that connect to the AutoUpdate server, the 6.8.7 upgrade can be done automatically.
For customers at an earlier (supported) release, or for systems that do not connect to the Internet/AutoUpdate server, you will need to download the upgrade image file and SCP it to the admin
users’ directory on the appliance.
The upgrade image file is ib_network_automation-v6.8.7.75643.gpg. Run the standard
AutoUpdate utility from the Network Automation Admin Shell to perform the upgrade.
Upgrade your Sandbox Instances
Ensure that Sandboxes (either Local or Remote) are fully and properly upgraded (to the starting release version) prior to starting an upgrade to 6.8.7. If the sandbox is in an incorrect state prior to a 6.8.7 upgrade,
this may create issues while upgrading to 6.8.7.
Local sandbox instances for Network Automation will be automatically upgraded to 6.8.7.
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.
Note: Sandbox logs upgrades will display some error messages regarding RPM files. These errors are not material.
Network Automation 6.8.7 allows off-box scp operations for archive files to use SSH keys in lieu of passwords. Admin shell commands have been added to create and manage the SSH keys (for example, ssh-key create, ssh-key export, and ssh-key delete). You can create SSH keys with a variety of key types and bit sizes using the ssh-key create command. Once you have created SSH keys, you can enable the Use SSH Keys option in the Archive Database, Scheduled Archive and Remote Config Archive features (available under Settings -> Database Settings). If enabled, the SSH public key needs to be installed on the remote SCP servers in order for the operations to be successful. You can export the SSH public key from Network Automation in a variety of formats using the admin shell command ssh-key export. In a distributed setup, SSH keys are created only on the OC (archive operations that use SSH keys only run on the OC and not the
Collectors).
Support for mixed case custom field names in API calls
(NETMRI-20917) Currently custom field names must be lower case. Network Automation 6.8.7 allows custom field names in API calls to be case insensitive. Caution must still be exercised when dealing with custom field names created with spaces.
Improved Performance over high latency links
(NETMRI-21200) Operations Center platforms provide improved performance for Controller-Collector communications and batching for file transfers. Further enhancements may be provided in the future, however this would require customers to open firewall ports between OC and collectors that may currently
not but open. Therefore the additional phase of improvement is still under consideration.
NEW FEATURES IN 6.8.6
API Updates
The Network Automation API is updated to version 2.9.
Get Configs
A new Get Configs provides on-demand configuration collection through the Network Automation API, CCS Scripting and through Perl scripting:
Two new APIs: get_configs (initiates the GC request for a device and returns a TrackingID; and the
get_config_status API polls the status of the TrackingID and returns the current Status;
The CCS scripting language supports a new GET-CONFIGS directive to collect configuration data in synchronous or asynchronous mode (synchronous determines that the script stops executing until the GET-CONFIG directive completes; asynchronous determines that the script resumes execution while
the GET-CONFIGS directive executes in the background. The default mode is synchronous;
Perl scripting supports a new get_configs method in NetMRI_Easy.pm with an optional $mode parameter to specify synchronous or asynchronous mode. The default mode is synchronous.
Device Support Requests Worksheet has been improved to account for devices that time-out (or appear to timeout) while collecting SNMP Walk data. As before: if the device is reachable from Network Automation, the task runs in Automated mode, where SNMP data collection is automatically handled in the background; and if the device is not reachable from Network Automation, the tool runs in Manual mode, where the user manually uploads the SNMP walk data. Now, however, if the device times out, the Worksheet will allow the user to continue, as if in Manual mode, and provide an SNMP Walk collected through other means, or verify
that the Walk already collected is complete, and use that for the submission.
The md5sum command is available from the Network Automation Admin Shell
The md5sum command allows users to directly verify a file against a known md5sum value. It is the standard Linux command, made available within the Admin shell to allow the Admin user to verify the
integrity of file transfers, by comparing the md5 value of the transferred file.
NEW FEATURES in 6.8.5
No new features are provided in the 6.8.5 release.
Release 6.8.4 enables downloading of a previously defined config template as a text file for use in hand-configuring an undiscovered device. The Config Management –> Job Management –> Config Templates page’s Run Now feature offers a new Text File push mode. For more information, see the sub-topic Downloading a Config Template in the online Help or in the Infoblox Network Automation Administrator’s
Guide.
New Standard Report: Discovery Status
The Discovery Status Report appears in the Reports -> Report Gallery -> Assets category. You can select one or more device groups and receive a report detailing CLI and SNMP data collection status, and config collection status. It provides the following data points and the timestamps for the last actions for each device involved in the report:
IP Address and Device Name
License Status – Indicates whether device is licensed or trial, and if any feature licenses are in place
Device Type – Router, Switch-Router and other associated device types.
CLI Credential status – indicates successful or failed authentication
SNMP Credential status – indicates successful or failed authentication
SNMP Collection status – indicates successful or failed data collection through SNMP
Config Collection status – indicates whether configuration changed prior to last collection cycle
Reachable – OK indicates verified device reachability.
Discovery API Calls
Network Automation 6.8.4 provides a set of API calls in the new Discovery API category. Go to Tools -> Options -> API Documentation for more information.
New Standard Report: Config Change Audit Details
The Config Change Audit Details Report appears in the Reports -> Report Gallery -> Change and Config category. You can select one or more device groups and receive a report of summary information of config changes made to a group of network devices over a specified time period. The Detected Changes chart shows the number of changes that occurred for each date in the measurement period. A Most Changed Models pie chart shows the devices exhibiting the largest number of changes.
Improved Security Device Controller support for Nexus 6.1
Security Device Controller provides an update to Cisco Nexus device support for improved provisioning support of multiple ACLs.
Release 6.8.3 adds a new privilege for User Roles. Custom Data: Input Data enables non-SysAdmin users to edit custom field values. Previously only SysAdmin users could create custom fields and edit them. Creating customs fields still requires a SysAdmin role; with this change, other roles can be granted the
privilege to edit the data in these fields.
NEW FEATURES in 6.8.2
Juniper Flow Mode Support The Security Device Controller (SDC) feature now supports JunOS 12.1X (specifically 12.1R6.5) devices that are configured with Flow Mode.
NEW FEATURES in 6.8.1
System Health Monitoring
Network Automation offers a System Health feature to provide a detailed view of the system health of the Network Automation appliance, including status of hardware components such as RAID hard drives and power supplies, system temperatures, resource utilization, network connectivity, software versions and operating system status, and many more aspects of Network Automation health. Network Automation provides two visual inputs to notify and assist the administrator in responding to issues in the Network
Automation appliance:
• Report message banners at the top of the Network Automation screen provide quick notification of problems. The banner provides a link to immediately determine details for the issue, and to provide
issue codes to Infoblox Support.
• A Settings page, System Health, provides a more-detailed list of the problems affecting the system, including Collector appliances in an Operation Center environment (where applicable).
Platform Capacity
The Platform Capacity feature ensures that all Network Automation appliances (virtual, 1102-A, NT-1400, NT-2200 and NT-4000) maintain effective performance by enforcing capacity limits for each appliance type. Each appliance model supports a specific number of network infrastructure devices. Feature licensing is another consideration for each appliance: for example, you should determine when a feature license for Security Device Control or Switch Port Manager is fully allocated. In an Operations Center environment, you may need to verify that a Collector’s device licensing is fully used and locate other Collectors with available
capacity.
Platform Capacity enables users to know when Network Automation licensing levels and licensed device support are fully utilized. You can decide when discovery and management tasks may need to be distributed to other appliances, and when you can increase allocations on an appliance to manage more devices.
Platform capacity uses three metrics: Platform Limits, Licensing Limits and Effective Limits.
Through the System Health and Platform Capacity features, Network Automation provides system hardening features to help prevent job overloading on a Network Automation appliance. For example, if a user specifies a very large Job while the appliance is currently running a large Report or is performing a large Discovery process, the appliance may notify the user of a possible system utilization issue, and automatically reduces the system resources allocated to current tasks to prevent overloading.
Device Support Requests provides an Automated Data Collection feature for new versions, makes and models of infrastructure devices. Network Automation users may use both SNMP and command-line instructions to quickly build a custom Device Support Request package. Sending the compiled Device Support Request to Infoblox enables faster support and control for new types of infrastructure devices, new operating system
versions, and new models of existing device product lines that are not supported by Network Automation.
Though you can submit this data to Infoblox without prior coordination, Infoblox recommends that you work with your account team to coordinate all device support requests, to ensure they are properly prioritized.
NETMRI-20556 - Expand database coverage for getMySQLStats (SendTechData).
NETMRI-20423 - Policy rules fail due to "Invalid Indent" message.
NETMRI-20416 - "704 Content Delivery Failed" message in Device Viewer -> Configuration Management -> Errors page when upgrading from 6.4.
NETMRI-20407 - Missing tacacs-server lines and Hang-up in command pager prompt.
NETMRI-20413, NetMRI-20288 – The reference registration process to convert from a standalone to Operations Center fails on larger data-sets. Customers who are converting to the OC architecture should not do so without coordination with Infoblox support. Recommend that any such conversion be delayed until
after 6.8.5 is installed.
NETMRI-20379 – If a credential is guessed via SNMPv1, v1 is used for all other device interaction, instead of v2, resulting in possible gaps in data collection for some categories where v1 does not have the same data
as v2 (e.g. support for 64 bit).
NETMRI-20366 – NetMRI Device Support Collection may not complete if started close to maintenance.
NETMRI-20364 – The Device Support Request tool can fail on a NetMRI that is configured to use https only.
NETMRI-20355 – Network Automation can occasionally mistake a BGP route for a static route.
NETMRI-20351 - Add support for "&" character in Group Membership criteria (Settings -> Collectors and Groups).
NETMRI-20349 – Disable PortControl “Edit VLAN Membership” option for aggregate member interfaces in
Interface Viewer and SPM screen.
NETMRI-20336 - OC: Reference registration takes many hours for collector with restored DB archive.
NETMRI-20330 – Error when manually running Discovery Diagnostics.
NETMRI-20324 – In the Settings -> Users table, sorting is incorrect with more than one page of results.
NETMRI-20275 – DiscoveryStatuses#static fails on an OC when a UnitID value is not provided.
NETMRI-20260 - ILO ports on HP windows servers don't get discovered properly.
NETMRI-20221 – Network Automation may incorrectly set the time zone during an upgrade.
NETMRI-20046 - Discovery Diag shows incorrect timestamps in 90 Day History.
NETMRI-19959 - The application watchdog needs to ensure that there is one AnalysisBatch.pl process and another child process.
NETMRI-19919 – The dataEngine.log file may contain numbers of extraneous messages, causing an excessively large log file.
NETMRI-19876 – New Device Found will not trigger reliably in an Operations Center environment.
NETMRI-19640 – Errors in firewall serial number values when polling Cisco ASA’s for inventory information.
NETMRI-17678 – Issues do not stay suppressed after suppressing them in Network Automation.
NETMRI-20547 – Issue Viewer History graph incomplete when timeframe spans a device group add/delete.
NETMRI-20499 – OC: Undeployed policies remain in the NA>Policy Compliance Page.
NETMRI-20461 – Watchdog is restarting Skipjack and observing “system service restarting” dialog
NETMRI-20440 – Generate System health message in cases of unexpected reboot.
NETMRI-20438 – RESTful API autogenerated search method returns rows in reverse order.
NETMRI-20436, NETMRI-20437 – Reduce memory usage and improve process management of System health processes.
NETMRI-20417 – Collected configurations not visible in Operations Center.
NETMRI-20389 – Configuration consolidation sometimes fails to complete.
NETMRI-20374 – Operations Center: Collectors should overwrite existing scripts as an alternative to raising errors.
NETMRI-20368 – Operations Center: Improve backpressure tuning for configuration consolidation.
NETMRI-20363 – "Enforce this rule" field in Device Filter for Rule is not persistent between edits.
NETMRI-20360 – Incorrect interface descriptions on Juniper devices.
NETMRI-20333, NETMRI-20292 – Appliance experienced sudden stoppage, requiring power cycle to correct. Kernel change avoids deadlock on multi-CPU systems, so reboot will be automatic.
NETMRI-20281 – ACL hit data collection occurs with licenses other than Security Device Controller, impacting performance.
NETMRI-20258, – Large CCS and Perl jobs may sometimes never run for some devices, and show as ‘pending’.
NETMRI-20243 – Data Pruning occasionally failed with large tables.
NETMRI-20241 – Differences in Total Device Count following upgrade from 6.7.3 to 6.8.2.
NETMRI-20232 – Script execution sometimes stalls when executing for larger data sets.
NETMRI-20212 – User able to enter invalid characters when creating custom Policy Rule.
NETMRI-20203 – remote Config Archive does not back up all config archives from the appliance.
NETMRI-20199 – A custom Daily Config Change report could provide confusing output.
NETMRI-20192, NETMRI-20217 – API script removes a link to the user Role but does not remove the User.
NETMRI-20165 – "Error getting grid config from server" messages for deployed Custom Policy.
NETMRI-20135 – v6.8-EnableRootDiagnostic.gpg Perl script fails on Operations Center.
NETMRI-20133 – Nexus VLAN Viewer data shows wrong Root Bridge MAC address.
NETMRI-20103 – API script does not handle device_ids across multiple collectors.
NETMRI-20102 – Script processing backlogs when processing policies.
NETMRI-20095, NETMRI-19964 – XFS file system may be corrupted after power cycling an NT-2200 Network Automation appliance shortly after startup.
NETMRI-20070 – Correct occasional problem creating error message for ‘Add New User’.
NETMRI-20062 – The System Health log journal file is not being pruned, causing large log file packages.
NETMRI-20059 – Unable to view config files for some H3C devices using non-ASCII character set.
NETMRI-20031 – In Settings -> Issue Analysis -> Suppression, random Suppressed Interfaces and Suppressed Devices display N/A for data fields.
NETMRI-20023 – NT-1400 network interface error.
NETMRI-20022 – Performing a Discover Now on a device logs the same message multiple times to the User Admin Audit Log.
NETMRI-20018 – Some Health Diagnostic / System Alert info not logged.
NETMRI-20006 – Config Manager cannot correctly update status when there is a semicolon in a device
password.
NETMRI-20005 – During Juniper DeviceContext collection, if no data is collected from the current poll, the collector does not remove existing entries from the database.
NETMRI-19991 – Increase time to 15 minutes between SCP connection health check messages to the external archive storage system.
NETMRI-19989 – Nortel ERS switch has space after prompt, causing CCS scripts to fail.
NETMRI-19978 – When run over a 30-day period, the Change Audit Summary report displays an error
message.
NETMRI-19968 – Network Automation fails to configure Cisco devices if "Enter Enable Mode" is turned off.
NETMRI-19955 – Security Control not properly parsing correctly collected Fortinet device configs into Rules.
NETMRI-19948 – Some device configs are never collected when too many detected changes events occur.
NETMRI-19944 – Config Search not respecting i (case insensitive) modifier for RegEx searches.
NETMRI-19927 – Removal of a self-signed certificate from configurations to prevent running-config vs. saved-config diff issues, fails to properly remove the certificate, triggering a false "Config Running Not
Saved" issue.
NETMRI-19924 – SNMP credential guesser does not guess manually entered credentials.
NETMRI-19871 – The Hardware Status page needs to be periodically pruned for out-of-date information.
NETMRI-19870 – API call discoverNow.pl does not return correct output.
NETMRI-19827 – Performance reports fails when passing the 1-Month boundary.
NETMRI-19808, NETMRI-19809 – On an Operations Center, Scheduled and Ad Hoc jobs do not move past “Running” status on the first run, or past “Pending” for future job runs, and are not sent to the Collector.
NETMRI-19686 – Network Automation appliance could experience instability during maintenance.
NETMRI-19663 – Found New Device events that are set to trigger a Job may produce ‘Could not determine Job ID’ messages.
NETMRI-19661 – Interfaces previously showing as Available appear as Free after switch reboots.
NETMRI-19637 – Some systems may experience occasional loss of network connectivity to the Network Automation appliance. A hotfix is available for this issue. To obtain the hotfix, contact Infoblox Support and
provide this issue number.
NETMRI-19628 – Config running Not Saved Issues displays invalid Time Difference values.
NETMRI-19586 – Difference between unit scales of VLAN timers collected via SNMP and CLI.
NETMRI-19556 – Upgrade from 6.7.3 to 6.8 GA release may display an error message when running a remote archive simultaneously with the upgrade.
NETMRI-19544 – A supported device stuck at 72% Assurance level.
NETMRI-19531 – A few forwarding table data entries might not be updated on some HP 2610 devices.
NETMRI-19458 – Documentation needs updating to describe the required reboot during the Weekly Maintenance procedure.
NETMRI-19424 – Add privilege for Roles that enables non-Admin users to edit custom field values.
NETMRI-19348 – For some wireless devices, a base station name containing an apostrophe might not be fully parsed by the SNMP polling engine, causing a SQL error.
NETMRI-19346 – Users do not get notification emails regarding a needed job approval unless "Entire Network" is selected. Selection by device groups does not provide the notification emails.
NETMRI-19337 – HTTP(S) headers could disclose information that could be useful in malicious attacks.
NETMRI-19202 – Network Automation not displaying correct Root Priority for Nexus 7010 devices though correct value is polled through SNMP.
NETMRI-19030 – Occasional Rerun Batch errors on job scripts.
NETMRI-18987 - The current 2-second timeout and 3-retry count set during SNMP Polling may cause a Cisco 3750 device to not respond to other polling.
NETMRI-18900 – No VLAN information reported by Network Automation for Alcatel switch and switch-router devices.
NETMRI-18873 – Selecting "All" Issues for some date in the past, shows issues from the selected date and from 1 day ahead.
NETMRI-18695 – Some devices show No Data to Display messages on Config Archive records for some Configuration Management grids.
NETMRI-18963 – Prevent OpenSSH connection slot exhaustion attacks that could cause DoS. This issue does not cause access privileges or elevated privileges to be exposed. (CERT vulnerability for OpenSSH: CVE-2010-5107)
NETMRI-17590 – UI strips out ‘#’ characters in Device Name field.
NETMRI-16750 – Incorrect Device Memory Utilization High Issues appearing on Cisco ASR Devices.
NETMRI-16132 – Config Search not working as expected with more than two search criteria.
NETMRI-15757 – Custom Report ignores specific column sort order.
NETMRI-15194 – (Operations Center only) Hardware failure detected for Sensors Reachable: Connection to
OC Collector.
NETMRI-13579 – Disable debug outputs from Infoblox administrative interface from tools such as Ping/Traceroute.
NETMRI-19479 - (Operations Center) The “Discovery Setting Filter by Collector” drop-down menu shows “unknown” for “Device Limit” on an upgraded collector. This does not affect service. If desired, you can
reapply license on the collector to address this issue.
NETMRI-19332 - Suppress the 0.0.0.0 values in HSRP in Initial State.
NETMRI-19256 – Issue Details Report may not list all current Issues.
NETMRI-19156 – (Operations Center) Disabling JobSelfApproval causes a collector resync.
NETMRI-19010 – (Operations Center) Database size is too large to complete an upgrade or archive.
NETMRI-18978 – Whenever a sting is converted to a floating point value, a specially crafted string can cause a heap overflow. (CERT vulnerability for Ruby/Rails: CVE-2013-4164)
NETMRI-18971 - CCS/Perl Jobs are sometimes never launched due to concurrency issues.
NETMRI-18970 – Scheduled Jobs Last run shows dates in the past.
NETMRI-18914 – This release adds support for forwarding and VLAN data collection (through the CLI) for the Cisco Nexus 1000V v4.2(1)SV2(2.1) switch.
NETMRI-18894 – Undocumented non-interactive auto-clear feature for Custom Issues.
NETMRI-18874 – Network Analysis -> Changes page may show a blank page with no records when switching between Change type pages in the UI.
NETMRI-18865 – End Hosts being shown as connected to the wrong interface.
NETMRI-18824 – Script names over 80 characters will not run on a first attempt. Editing the script name to less than but close to 80 characters may continue to cause the script to display the same error.
NETMRI-18805 – Scheduled Jobs Last run shows dates in the past.
NETMRI-18794 – Failure to collect configuration on a Cisco ASA-5540.
NETMRI-18792 – NetMRI fails to detect SNMPv3 credential change on some devices, resulting in no reguessing of credentials and in disabled SNMP collection.
NETMRI-18773 – Asset Inventory Report displaying incorrect chassis serial numbers.
NETMRI-18741 – Scripts may accidentally run on multiple devices.
NETMRI-18711 – Config script file changes may not be flushed out to disk.
NETMRI-18708 – IPAM sync and other data tables not including switchport/VLAN information for some end hosts.
NETMRI-18656 - Link between access port present and connected end host displays wrong information.
NETMRI-18548 - IPAM sync incorrectly creates multiple entries for IP Addresses on a port with multiple VLANs.
NETMRI-18143 – The TLS protocol 1.2 and earlier, as used in browsers, can encrypt compressed data without obfuscating the length of the unencrypted data, which allows man-in-the-middle attackers to obtain plaintext HTTP headers by observing length differences during a series of guesses in which a string in an HTTP request potentially matches an unknown string in an HTTP header, aka a "CRIME" attack. (CERT
vulnerability for TLS: CVE-2012-4929)
NETMRI-18063 - Support for BlueCoat-ProxySG300 device configuration difference issue.
NETMRI-18031 – SPM end host reporting inconsistent MAC information.
NETMRI-18029 - Prompt detection fails with Cisco ASA device with long banner (over one screen in length).
NETMRI-18012 - Devices marked as Unmanaged show SNMP credentials failed in Network Insight -> Discovery page.
NETMRI-17990 – (Cisco ASA and IOS) If the last rule of an ACL is removed, the ACL is also deleted without warning.
NETMRI-17980 – (Operations Center) When a user opens the Issue Viewer, some IP addresses of HSRP groups are blank.
NETMRI-17957 – Settings -> Database Settings -> Scheduled Archive no longer allows “Hourly” settings. Systems with the “Hourly” configuration will automatically be adjusted to the “Daily” configuration after an
upgrade.
NETMRI-17919 – Interface performance data uses exponential notation for small performance percentages.
NETMRI-17911 – VPN Tunnel MTU Mismatch.
NETMRI-17787 – Edit and Install of DSB using Network Automation GUI fails intermittently with a "Not valid *.tgz" file message.
NETMRI-17548 – NetMRI_Easy Perl library used an uninitialized $error_message value.
NETMRI-17401 - In custom report filters, regex matching does not work against custom Job fields.
NETMRI-17395 – License installation may fail through UI by a SysAdmin-privileged user.
NETMRI-17375 – JSON Gems before 1.7.7 for Ruby on Rails could allow a denial of service attack based on crafted JSON documents. (CERT vulnerability for Ruby/Rails: CVE-2013-0269)
NETMRI-17351 – Some fields no longer present in the Report Manager CSV Export after 6.6.x release.
NETMRI-17335 – The Discover pane for the Network Insight page may show the “Existing” field greyed out for select devices.
NETMRI-17331 – Updates needed for InvalidAdminOperState and RouterInterfaceDown Issue descriptions.
NETMRI-17192 - Error message is not properly worded while adding a network with "Exclude from
Management" as Discovery mode and by enabling Discovery Ping Sweep check box.
NETMRI-20802 – Scripts run on collector can falsely return success under certain conditions.
NETMRI-20754 – OC should not process Jobs off queue if sandbox is unavailable.
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-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-20061 – Device Group with "&" in name causes devices to become UNASSIGNED.
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-19796 – Typing Cisco ASR 1000 as HSRP device prevents device discovery.
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-19674 – Juniper EX devices with Interface/Subinterface configs 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-19394 – Forwarding data not collected with SNMPv3 in Enterasys E-Series 1H152x50 and 1H582x25 devices.
NETMRI-19332 – No IP address (instead of 0.0.0.0) appears for devices in HSRP group in Initial state.
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-19044 – You may not be able to select Today’s Date in the Device Viewer’s Network Analysis ->
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-18000 – Some switch forwarding tables on trunk ports becoming too large.
NETMRI-17798 – Network Automation DNS entry 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-17796 – Executing Discover Now for a single IP address could be optimized.
NETMRI-17648 – HTTP 503 error messages when trying to view reports.
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-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-15685 – Updated Date feature does not appear in all required contexts.
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 was been 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-13970 – Unable to deploy Custom Issue Help Files.
NETMRI-11718 - Network Automation may not honor explicit router lifetime and hop limit settings in IPv6 Router Advertisement (RA) messages.
NETMRI-11206 – Scheduling the Issue Details report displays incorrectly formatted HTML notification data.
NETMRI-8038 – (Operations Center only): Collector work queue tables not being updated.
The “Get Configs” (GC) feature allows for on-demand config collection via the NetMRI API, CCS scripting and Perl scripting. The CCS and Perl scripting implementations allow for either synchronous or asynchronous
operation.
API Calls
At the API level, two new APIs (shown below) have been introduced to support the GC feature. The get_configs API is used to initiate the GC request for a specific device and returns a TrackingID, whereas, the get_config_status API is used to poll the status of the TrackingID and returns the current Status. As the GC request progresses through the system it will transition between the following states: Pending, Queued,
Running, OK and/or Error. A GC request is considered complete when the Status is either OK or Error.
URI: /api/2.9/config_revisions/get_configs
Available Since: API v2.9
Privilege Required: view_sensitive
Feature Required: None
Request on demand configuration collection for the specified device.
Inputs
DeviceID (or device_id) Required Integer
The internal Network Automation identifier for the device.
TrackingID Optional Integer, Default: 0
The Tracking ID. Used for internal purposes and ignored if user specified.
Outputs
TrackingID Integer
The TrackingID assigned to this get configs request.
URI: /api/2.9/config_revisions/get_configs_status
Available Since: API v2.9
Privilege Required: view_sensitive
Feature Required: None
Get the status of an on demand configuration collection request.
Inputs
TrackingID Required Integer
The TrackingID assigned to the get configs request.
For CCS scripting, a new GET-CONFIGS: directive has been introduced to support the GC feature. An optional [MODE] can be specified to the right of the “:” to indicate whether synchronous or asynchronous behavior is desired. Valid values for [MODE] are “synchronous” and “asynchronous”. If not specified, [MODE] defaults to “synchronous”. Synchronous behavior implies that the script will block until the GC operation has completed (i.e. the operation terminates with an OK status) or abort if an error is encountered (i.e. the operation terminates with an Error status). Asynchronous behavior implies that the script will continue processing after the GC request is initiated.
Example Script-Filter: true
Action: Get Configs Test
Action-Description: Demonstrates the Get Configs functionality via CCS
Action-Commands:
# Ensure that NetMRI has the most up-to-date configurations on file. The script
# will block until the first Get Configs operation has completed (synchronous mode).
GET-CONFIGS:
# Modify the interface description for Fa0/1.
config t
interface Fa0/1
description Get Configs Test
end
# Request another Get Configs operation to audit the above change. Since this
# is the end of the script and there is no need (for this particular use case)
# to block until this Get Configs operation has completed, the asynchronous mode
# has been chosen. Allowing the job to complete, and collection in the background.
GET-CONFIGS: asynchronous
After the script run has completed, output similar to the following can be seen in the Status Log of the Job Details Viewer: +++ 1. Action: Get Configs Test
+++ 1. [Action-Commands]
+++ Requesting on demand configuration collection (synchronous) ........ OK
+++ Received TrackingID 1 .............................................. OK
+++ Getting the status of TrackingID 1 ................................. PENDING
+++ Sending 'Keep Alive CR/LF' ......................................... OK
+++ Getting the status of TrackingID 1 ................................. QUEUED
+++ Sending 'Keep Alive CR/LF' ......................................... OK
+++ Getting the status of TrackingID 1 ................................. QUEUED
+++ Sending 'Keep Alive CR/LF' ......................................... OK
+++ Getting the status of TrackingID 1 ................................. RUNNING
+++ Sending 'Keep Alive CR/LF' ......................................... OK
+++ Getting the status of TrackingID 1 ................................. OK
+++ 1. Sending 'config t' .............................................. OK
+++ 1. Sending 'interface Fa0/1' ....................................... OK
+++ 1. Sending 'description Get Configs Test' .......................... OK
+++ 1. Sending 'end' ................................................... OK
+++ Requesting on demand configuration collection (asynchronous) ....... OK
+++ Closing session .................................................... OK
*** Successfully ran configuration command script ***
For Perl scripting, a new get_configs method has been introduced in NetMRI_Easy.pm to support the GC feature. An optional $mode parameter can be passed in to indicate whether synchronous or asynchronous behavior is desired. Valid values for $mode are “synchronous” and “asynchronous”. If not specified, $mode defaults to “synchronous”. Synchronous behavior implies that the method will block until the GC operation has completed (i.e. the operation terminates with an OK status) or abort if an error is encountered (i.e. the operation terminates with an Error status). Asynchronous behavior implies that the method will return after the GC request is initiated.
Example
# BEGIN-SCRIPT-BLOCK
# Script-Filter: true
# END-SCRIPT-BLOCK
use strict;
use warnings;
use NetMRI_Easy 0.6;
my $easy = new NetMRI_Easy({ debug => 1 });
# Ensure that NetMRI has the most up-to-date configurations on file. The script
# will block until the Get Configs operation has completed since the
# synchronous mode is used.
$easy->get_configs();
# Modify the interface description for Fa0/1.
$easy->send_command("config t");
$easy->send_command("interface Fa0/1");
$easy->send_command("description Get Configs Test");
$easy->send_command("end");
# Request another Get Configs operation to audit the above change. Since this
# is the end of the script and there is no need (for this particular use case)
# to block until the Get Configs operation has completed, the asynchronous mode
# has been chosen. That allows the job to complete, and the collection to be
# handed off to the background.
$easy->get_configs("asynchronous");
If debug has been enabled via the NetMRI_Easy.pm constructor (see example above), after the script run has completed, output similar to the following can be seen in the Status Log of the Job Details Viewer: DEBUG: Requesting on demand configuration collection (synchronous) ... OK
DEBUG: Received TrackingID 1 ... OK
DEBUG: Getting the status of TrackingID 1 ... PENDING
DEBUG: Sending 'Keep Alive CR/LF' ... OK
DEBUG: Getting the status of TrackingID 1 ... QUEUED
DEBUG: Sending 'Keep Alive CR/LF' ... OK
DEBUG: Getting the status of TrackingID 1 ... QUEUED
DEBUG: Sending 'Keep Alive CR/LF' ... OK
DEBUG: Getting the status of TrackingID 1 ... RUNNING
DEBUG: Sending 'Keep Alive CR/LF' ... OK
DEBUG: Getting the status of TrackingID 1 ... OK
DEBUG: Requesting on demand configuration collection (asynchronous) ... OK