Skip to main content

What's New and Release Notes for 26.x

Resolved Issues in NEN 2.3.10

  • Network enforcement log showed exception when switching from node 2 to the primary node (E-85609)

    On the NEN server, in the network_enforcement.log, an error was shown with an exception message when switching from Node 2 to the primary node. This issue is resolved.

  • Deleting VS policy from the F5 night leave AS3 declare in an unstable state (E-85489 )

    When deleting a VS policy from the F5, the code ignored the response from the AS3 PATCH command and deleted the policy. However, if the AS3 declare PATCH failed, this left the system in a state where subsequent AS3 PATCH commands failed due to an inconsistency with the AS3 declare and the state of the F5. This caused the policy to not be applied. This issue is resolved.

  • Failed to apply policy to a virtual server after NEN upgrade (E-85412 )

    A policy change could generate a 409 error. Policy for the virtual server would then fail to update. This happened because during policy changes, the PCE failed to detect and correct of out-of-sync F5 AS3 declarations and virtual server configuration. The NEN would therefore try to create a policy that already existed. This issue is resolved. A subsequent tamper check fixes the policy for the virtual server.

  • NEN logs DEBUG info in prod level (E-85363)

    The NEN was not setting the default log level for the production environment correctly, causing DEBUG information to be logged into the network_enforcement log.

    This issue is resolved and the NEN now works as expected.

  • Some NEN logs should be at debug level (E-85341)

    Some logs were growing very large (over 5GB) in a very short time because policy information was mistakenly added to the logs.

    This issue is resolved so that some parts of that information are added at DEBUG log level instead of INFO log level, while some parts (such as PNports info) are not added to the log.

  • Discovery loop not working on NEN 2.2.0 in production environment (E-85307 )

    The discovery job was sometimes not working properly. It did discovery, but for only one SLB. The symptom was increased Ruby gems errors in logs. The issue was caused by an insufficient number of database connections in the pool. The issue is resolved. The default number of connections in the database pool is increased from 4 to 50.

  • NEN health status could display incorrect cluster status (E-85301)

    Running the illumio-nen-ctl health command could provide incorrect information for the NEN HA cluster in the Cluster Mode field. For example, the command output could incorrectly display “Standalone (split brain)” when the NEN service on one of the nodes was stopped. The field should have displayed “Standalone (failover).” This issue is resolved and the Cluster Mode field now displays the correct information.

  • NEN - Failover not working if NEN primary freezes (E-85256)

    The NEN primary node could stop logging unexpectedly because of an unforeseen event such as a full disk. The lack of logs made the node appear frozen, but the NEN was still running, so the NEN secondary node did not take over. However, if the disk on the primary node got full and caused the database and node to fail, the primary node would fail, and then failover to the secondary node would occur. This issue is resolved. To address the disk full issue and the lack of logging, if a disk gets 95% or more full, the node will now be stopped, and the NEN fails over to the other node.

  • NEN didn't delete empty iRule and create a new non-empty rule (E-85211, E-84872)

    iRules are a feature within the F5 BIG-IP local traffic management (LTM) system. An iRule can become empty due to tampering. If the NEN detects that an iRule is empty, it's supposed to delete it and then create a new non-empty rule. In this case, the NEN failed to delete the empty iRule and create a new non-empty rule. This issue is resolved.

  • Policy updates and tampering check weren't working (E-85197)

    When the NEN service on the primary node of a NEN HA cluster was stopped, the secondary NEN node did not apply policy updates that the primary node was processing when the primary node failed. This issue is resolved. The secondary NEN node now correctly applies the policy updates from the primary node when it failed over.