FireMon Lumeta is pleased to announce the general availability of Lumeta 22.214.171.124, a micro-release that provides enhancements and fixes issues, described on this page. This release is recommended for all Lumeta users.
|Upgrading to Lumeta 126.96.36.199|
|Upgrade Path||Upgrade Package|
3.3.2x Command Center
|188.8.131.52 Command Center|
SHA256 checksum: sha256sum spectre_update-184.108.40.206.13495-20190402.tgz
Lumeta 220.127.116.11 Command Centers are not backward-compatible with older Scouts such as 18.104.22.168, 22.214.171.124 and 126.96.36.199. Please upgrade your Scouts to version 188.8.131.52.
This release includes the following enhancements:
|PO-9607||Any configuration message received by a Scout used to cause all collectors to reconfigure themselves. Lumeta has been made to be more granular about which collectors can act on particular messages and what exactly a particular message can reconfigure.|
|PO-9608||Scouts have been made to ignore any configuration changes for a disabled collector. When a collector is enabled or re-enabled, its configuration is then read by its associated Scout.|
|PO-9609||To optimize discovery performance, "TreeSets" were set up for every CIDR added to a List. This enhancement reduced discovery time for a 30K Avoid List from 6 minutes to less than a second.|
|PO-9551||The number of CIDRs transferred per page has been increased, thereby reducing loads on the database when Scouts request lists from collectors and eliminating associated API timeouts.|
|PO-9553||In the prior release of Lumeta, an API call from the Scout to the CC would occasionally experience a timeout due to database slowness, leaving a Collector unconfigured and preventing scan activity. Customers experienced intermittent outages of scanning. In this release, the Scout logic has been enhanced to include a "wait-retry" after a timeout, resolving the problem.|
The following issues reported by customers have been fixed:
|Case ID||Fixed Issue|
|PO-9605||Improve the way we handle collectore configuration changes at the scout level|
When the IP address of an existing device changes, the Target, Known, Internal and Eligible Lists are recalculated to reflect the correct current values for the updated IP address. This resolved an issue in which some devices present in a zone's discovery space were incorrectly reported as "false."
|PO-9835||Also in response to PO-9743, two scripts were prepared: One that identifies and reports mismatches between the device_values.target, trusted, internal and known with the Target, Eligible, Internal, and Known Lists and another that rectifies the differences. These scripts should be run before upgrading to 184.108.40.206. See Upgrading to Lumeta Spectre 220.127.116.11 for the procedure.|
When a CIDR is added to a configuration, changes to a device are now made to apply only to IP addresses contained within that CIDR and not to the parent outside the CIDR.
|PO-9083||When a collector gets archived, its configuration CIDRs are removed and table columns associated with those configuration CIDRs (Target, Eligible, Known, Internal) are recalculated to reflect those changes.|
In previous releases, when a device's IP address for parent and child were the same, only the child device's IP would be recorded in the device response table. As a result of this, Lumeta did not display scan types for the parent IP when it received snmpDiscovery responses from the child's IP address. To fix, Lumeta changed Lumeta's response processing in these instances to also include an entry in in the device response table for the parent device.
We'll make you aware of any known issues and the work-arounds here.
|Lumeta 18.104.22.168 Known Issues||Case ID|
|1||None as of 4/3/2019|
Lumeta 22.214.171.124 resolves Common Vulnerabilities & Exposures (CVEs) and incorporates a variety of security-related (and non-security-related) enhancements. No new CVEs were resolved in this 126.96.36.199 release.
Following are the changes made in preparation for this Lumeta 188.8.131.52 release. This information has been refreshed on 5/23/2019 for GA.
PO-9277 - Scouts picked up collector configuration after a long delay after upgrade
PO-9624 - Collector stops collecting because of timeout in getting a page of configuration CIDRs
PO-9679 - At NJOHS we are seeing devices with target and known=f when the device IP is in zone discovery space
PO-9704 - Device answers SNMP queries for non-interface address
PO-9743 - Identify discrepancies for target, trusted, internal and known
PO-9757 - CLONE - Archiving Collectors does not update device_values.target Port to 3.3.2-maintenance
PO-9770 - CLONE - Port to 184.108.40.206 maint branch - Disney is seeing devices where SNMP Aliases, snmpAccessible, snmpResponder is all set, yet discovery does not show snmpDiscovery
PO-9792 - CLONE - Port to branch - Identify discrepancies for target, trusted, internal and known
PO-9803 - CLONE - Port to branch - Change algorithm that picks reference ip address to not mandate that reference ip address has to be in target list
PO-9811 - Map does not work on today's netboot
PO-9835 - Write verification and rectification sqls to address target/known/trusted/internal mismatches
PO-9837 - Uploading config cidr updates parent's device values for known, target, trusted and internal
PO-9901 - CLONE - esi-current:Scan is not working for CC/Scout interfaces.Unable to discover devices in scan
PO-9721 - create upgrade to 220.127.116.11
PO-9805 - upgrade from 18.104.22.168 to 22.214.171.124 fails early at version check
PO-9828 - create esi-126.96.36.199-rcN netboot and tag
PO-9551 - Change Paging Size of getConfigCidrs in ConfigManager
PO-9553 - Retry Collector Configuration When getCollectorCidrs Fails
PO-9606 - Configuration messages should not necessarily be sent to all scouts
PO-9716 - CLONE - Port to branch - Clear cifsName upon receiving NACK for tcpPorts or cifs
PO-9897 - Bug around suppressing frequent collector updates