Known Limitations

There will be drop of syslog packets seen for RT_FLOW: RT_FLOW_SESSION_CREATE_USF logs until this is fixed. This will not impact the functionality.PR1678453

This issue is caused because of the fact that peers-synchronize is configured, and master-password is configured to encrypt the config being sync'ed. However since there is no master-password configured on the peer device, the encrypted configuration cannot be decrypted (this is expected). This has not been supported from day-1, however a workaround can be done in order to get this to work. The workaround is to manually configure the same master password on the peer device manually. At a high level the problem is as follows: Consider there are two devices A and B in a peer-sync config 1. config on dev A contains secrets which need to be encrypted with the master password and synced with the device B 2. The master-password (juniper123+masterpassword) is configured on device A and the configuration is encrypted and written to /tmp/sync-peers.conf 3. The /tmp/sync-peers.conf is then synced to device B but device B does not have the same master-password configured which results in the config failing to decrypt. The master-password itself is not a part of the config-database. Additionally, it cannot be transmitted over an unencrypted HA Link, as this would lead to the master-password getting leaked. This is by design, and would be a security concern if it were to be transmitted across an unencrypted channel. Therefore, this work as designed. In order to work around this issue follow these steps: 1. configure the master-password on device B and commit the config 2. configure the same master-password on device A and commit the config and it should get sync'ed correctly.PR1805835

40g interface does not support EM policy feature, but it will still display in the CLI output of show chassis temp-threshold as it gets created as "et" interface. PR1807219

There are no registers in the MX304 PSM to find out feed is connected or not. The only thing that we have in the MX304 PSM is whether the input voltage is zero or not. But that does not confirm whether the feed is connected or not. PR1807254

We will see an extra flap of link happening whenever the link come up first time or when we do link enable or disable. This is due to limitation of the marvell device.PR1817595

The commit error "Command remap failed" observed on the dual re controller.

Workaround steps to follow to recover jnu-controller-schema.db:

• Remove /var/db/vSRX/<versionname_of_satellite_connected> directory from the controller shell.

• Remove /var/db/jnu_current_sw_version file from the satellite shell.

• Restart jnu-management from CLI of the satellite.

PR1839015

When PFE Major/Fatal errors were configured for pfe-reset, MPC7/MPC8/MPC9 FPCs gets into ?HOST LOOPBACK WEDGE? post pfe-reset action triggered by the errors. PR1839071

During LMIC Offline, occasionally we might get the following error messages and this has no functional /traffic impact. mqss_dstat_stream_wait_to_drain: Final Values: Invalid: False, Timeout: False, Timestamp: False, Queue Depth: 16 bytes) mqss_dstat_stream_wait_to_drain: Timeout while waiting for the PHY stream 130 to drain - Queue 130. PR1843705

On MX304, during the MIC offline sequence, the following error messages can be intermittently observed for a short period in /var/log/messages [Log] mqss_sched_fab_q_node_is_configured: Queue scheduler node doesn't exist - q_node_num 0 mqss_sched_fab_q_node_is_configured: Queue scheduler node doesn't exist - q_node_num 1 . mqss_sched_fab_q_node_is_configured: Queue scheduler node doesn't exist - q_node_num 255 These error messages are harmless in this context (MIC Offline) and have no functional impact. They can be safely ignored. PR1844325

The JNU's design was to bring in the committed config from satellite to controller but it doesn't include the platform-specific default configs that come from various other junos default config files. This configuration is kept local to the satellite. Application match configuration under security policy is one such config for which warning message will be seen in MX Series controller while using application match as any or any SRX default application. PR1847209

MX Series bandwidth alarms are refreshed at the configured log interval (default 06:00AM). Any usage changes within this interval which maintains license non-compliance will not raise new alarms just for the changed in license-needed value. Real time license-needed value is updated in the output of show system license. PR1853132

Due to design limitations, syncE clock status on backup Routing Engine will not be displayed properly. There is no functional issue. Use show chassis synchronization clock-module to get the correct status of the syncE clock.PR1856148

Due to design limitations, syncE clock status on backup Routing Engine will not be displayed properly. There is no functional issue. Ignore the status on backup Routing Engine. Always refer the master Routing Engine status.PR1856152

When upgrading from releases before Junos OS Release 21.2 to Junos OS Release 21.2 and onward, validation and upgrade might fail. The upgrade requires using the 'no-validate' option to complete successfully. See TSB18251. PR1568757

The issue was seen when test was done back to back GRES within 5 minutes time. This is expected behavior from the system as per current architecture. Wait for sometime before may be 10 minutes or so for subsequent GRES. PR1801234

With a sensor being subscribed via Junos Telemetry Interface (JTI), after the interface is deleted, deactivated, or disabled, the TCP connection is still established, and the CLI command of show agent sensors still shows the subscription. PR1477790

An authentication bypass by spoofing vulnerability in the RADIUS protocol of Juniper Networks Junos OS and Junos OS Evolved platforms allows an on-path attacker between a RADIUS server and a RADIUS client to bypass authentication when RADIUS authentication is in use. Refer to JSA88210 for more information.PR1850776