Issue ID: I95-65908

Last Updated: 2026-09-25

Problem​

The Intel X722 Network Interface Controller (NIC) is used for ports xe0/0 through xe0/3 on SSR-1300 and SSR-1400 routers. The X722 NIC firmware scans the EEPROM for each installed optical device and checks the device against an approved optics list built into the firmware. Optical devices that are not present in the approved optics list are not allowed into service on this NIC.

Juniper partners with several optical transceiver vendors to deliver Juniper-branded optics. For the Juniper 10G LR SFP+ transceiver portfolio, Juniper part number 740-021309, the EEPROM encoding for one specific vendor is not recognized by the X722 firmware. As a result, the transceiver may not enter active service when installed in an affected X722 port.¹

Affected Products​

Affected Transceiver​

Symptom​

When this issue occurs, the affected interface remains unavailable for forwarding. The port shows an Admin Status of down and an Operational Status of unknown.

Example output:

========================================
 node1:xe-0-1
========================================
 Type:                ethernet
 Internal ID:         3
 Forwarding:          true
 PCI Address:         0000:6a:00.1
 MAC Address:

 Admin Status:        down
 Operational Status:  unknown
 Provisional Status:  up
 Redundancy Status:   non-redundant
 Speed:               0 Mb/s
 Duplex:              half

 in-octets:                           0
 in-unicast-pkts:                     0
 in-errors:                           0
 out-octets:                          0
 out-unicast-pkts:                    0
 out-errors:                          0

 Plugin Info:         unavailable

Cause​

The X722 NIC firmware does not recognize the EEPROM encoding used by one vendor variant of the Juniper 10G LR SFP+ transceiver, part number 740-021309. Because the optical device is not recognized as approved by the X722 firmware, the NIC does not allow the transceiver to enter service.

Identify The Affected Transceiver​

SFP EEPROM data is accessible via PCLI in select SSR software versions using the show device-interface node <node> name <port> optics-statistics command. If this is not available in your version of SSR software, use the Linux ethtool command.

In order to use the Linux ethtool command on X722 ports, you must complete the firmware upgrade referenced earlier.

Affected Transceiver In X722 Port After NIC Firmware Upgrade​

ethtool -m xe-0-1
Cannot get module EEPROM information: Input/output error

Affected Transceiver In A Non-X722 Port​

When the same affected transceiver is installed in a non-X722 port where EEPROM data can be read, the EEPROM output includes the following vendor information:

ethtool -m xe-2-1
    Vendor name                : JUNIPER-1W1
    Vendor OUI                 : 20:1b:c9
    Vendor PN                  : 1W1T8A

If the ethtool output aligns with either of the examples above, the transceiver is not compatible with the X722 NIC, and should be replaced with a compatible, approved Juniper transceiver.

The output below is seen when the X722 NIC firmware upgrade is needed.¹ Please upgrade the NIC firmware in order to capture the correct output, or move the transceiver to a non-X722 port to display the SFP information.

ethtool -m xe-0-1
i40e 0000:6a:00.1 xe-0-1: Module EEPROM memory read not supported. Please update the NVM image.

Workaround​

No software workaround is available.

Resolution​

Contact HPE technical support and initiate a return material authorization (RMA) request for the affected SFP only. HPE will replace the affected SFP.

When opening the support case, include the following information:

• SSR platform: SSR-1300 or SSR-1400
• Affected port: for example, xe0/0, xe0/1, xe0/2, or xe0/3
• SSR software version
• Transceiver part number: 740-021309
• Interface status output showing:
  • Admin Status: down
  • Operational Status: unknown
• ethtool -m output, if available

Issue ID: I95-66127 Last Updated: 2026-09-18
Introduced in SSR Version: 7.1.6

Problem​

When logged into the Conductor Web UI using an account configured with the admin role other than the built-in default admin account, users may encounter persistent 401 Authorization Required or 401 Unauthorized errors when viewing or refreshing router-specific monitoring and diagnostic pages.

The built-in default admin user account uses a pre-established trust session and is unaffected by this issue.

Release Notes​

Severity​

Major
Could seriously affect system operation, maintenance, administration, and related monitoring tasks.

Workaround​

Juniper provides the following workaround until the system is upgraded to a release where this issue has been resolved (see above):

• Use the Built-in admin Account: Log in to the Conductor Web UI directly using the default built-in admin user when monitoring managed routers, reviewing router logs, or inspecting FIB tables.

Issue ID: PLUGIN-2835.

Last Updated: 2024-12-12

Problem​

When upgrading to a version of IPsec plugin with the weak ciphers removed, SSR will stop offering these ciphers in its IPsec negotiation with the far end. As a result, the tunnel connection will break and will not be able to be formed again. You can verify this break in the following ways.

1. Check the output of the show plugin state command to inspect the status of the tunnel:

========================================
 combo-west:rem1
========================================
 Type:                host
 Forwarding:          true
 Mode:                host
 MAC Address:         76:78:79:fc:eb:69

 Admin Status:        up
 Operational Status:  down
 Redundancy Status:   non-redundant
 Speed:               0
 Duplex:              unknown

 in-octets:                     1962932
 in-unicast-pkts:                 32710
 in-errors:                           0
 out-octets:                    1373442
 out-unicast-pkts:                32701
 out-errors:                          6

 IPSec:
     rem1:
         Tunnel Status:Down
         Tunnel Details:
             Name:    ipsec-client-tunnel-primary-rem1
             Remote Host:172.16.4.3
         Down Reason: Tunnel settings mismatch

The above output shows the Tunnel Status: Down. Because the SSR no longer uses the weak ciphers, a Tunnel settings mismatch is identified as the cause.

2. In the 128t-ipsec@* service, the log indicates the following:

received unauthenticated v2N_NO_PROPOSAL_CHOSEN - ignored

Please see the Solution for remediation steps.

Severity​

Minor

Status​

In Progress

Resolved In​

128T-ipsce-client-4.1.0

Product​

SSR Routers

Functional Area​

IPsec

Solution​

Starting with the 128T-ipsec-client-4.1.0 version of the plugin, two changes are being made to support this remediation effort.

1. A new warning message has been added for conifgurations that rely on dh2 and dh22 algorithms. The warning message is visible when running validate or commit on the conductor.

2. Existing versions of IPsec plugin only support configuration specifying a single combination of IKE and IPsec algorithms. Beginning with 128T-ipsec-client-4.1.0, support has been added to allow multiple ciphers to be configured for IKE and IPsec. The following is an example configuration:

    ipsec-profile primary
        name primary
        ike-encryption           aes256
        ike-digest               sha2
        ike-modp                 modp1024
        authentication-protocol  esp
        phase2-encryption        aes_gcm128
        phase2-digest            sha2
        phase2-modp              modp1024
        ...
        additional-ike-algorithms algo1
            name algo1
            encryption aes128
            digest sha2
            modp modp2048
        exit
        additional-ike-algorithms algo2
            name algo2
            encryption aes256
            digest sha2
            modp dh19
        exit
    exit

The two solutions to remediate the weak algorithms are:

1. While running the existing plugin version, replace the weak cipher with a stronger one from the supported list.

• Chose a new stronger cipher supported by the server.

• Replace the weak cipher with the stronger cipher selected from the list.

  This config change will trigger a restart of the tunnels for new connections to be formed. Here's an example of sample configuration change.

  Before:

    ipsec-profile primary
        name primary
        ike-encryption           aes256
        ike-digest               sha2
        ike-modp                 modp1024
        authentication-protocol  esp
        phase2-encryption        aes_gcm128
        phase2-digest            sha2
        phase2-modp              modp1024
        ...
    exit

After:

    ipsec-profile primary
        name primary
        ike-encryption           aes256
        ike-digest               sha2
        ike-modp                 modp1024
        authentication-protocol  esp
        phase2-encryption        aes_gcm128
        phase2-digest            sha2
        phase2-modp              modp1024
        ...
        additional-ike-algorithms algo1
            name algo1
            encryption aes128
            digest sha2
            modp modp2048
        exit
        additional-ike-algorithms algo2
            name algo2
            encryption aes256
            digest sha2
            modp dh19
        exit
    exit

2. Upgrade to the IPsec plugin version 4.1.0 and configure additional supported ciphers on the server side

The SSR offers all the supported ciphers and identifies the ciphers supported on the server. It is recommended to remove the weak ciphers from the configuration once replacements have been made.

Remediating the configuration of weak ciphers ahead of their deprecation allows a seamless transition when upgrading to a new version of SSR software.

For example, the following top.sls would be impacted:

base:
  '*':
    - dummy

  'os:CentOS':
    - match: grain
    - centos_example

Issue ID: PLUGIN-2776

Last Updated: 2024-11-06

Introduced in SSR Version: 5.6.16, 6.1.12, 6.2.8, 6.3.x-r2

Impacted Plugin version: 128T-sip-alg-4.0.1 and below

Problem​

The SSR is migrating the underlying Linux distribution in an effort to remain agile and to reduce the surface area of CVEs.

Because the OS version is now reported as Oracle Linux instead of CentOS, there is an impact to the SIP ALG plugin, as well as any packages that may have an OS dependency, such as SaltStack.

Once a router is upgraded to SSR version 5.6.16+ or 6.1.12+, the 128T-SIP-ALG plugin version 4.0.1 (or earlier) is impacted by this issue. To avoid this issue, the plugin must be upgraded to 4.0.2 before upgrading the SSR.

For customer deployments implementing custom salt states that leverage OS-specific salt grains for CentOS Linux 7, those salt states may fail to apply after upgrading to 5.6.16+ and 6.1.12+.

Please see the workaround for steps to determine whether your environment is impacted and to remediate the issue.

Release Notes​

• Resolved the salt state issues for the SIP ALG plugin.
• Use the Workaround procedure below to scan salt states prior to Conductor and Router upgrades.

Severity​

Major

Status​

In Progress

Resolved In​

128T-sip-alg-4.0.2

Product​

SSR Routers

Functional Area​

SaltStack

Workaround​

Salt states are configuration files used to deploy and manage extensible behaviors on the SSR routers via the salt-minion. They are used by the product to implement certain features, by plugins, and in some cases, to implement customer specific use-cases not otherwise supported by the SSR.

For customers that implement custom salt states, use the following procedure to scan your salt states and identify issues that could arise during or after an upgrade.

1. Log in to the Conductor CLI as the admin user.

2. Enter the linux shell; type shell to suspend the CLI.

3. Run the following command to scan the custom salt states for Centos 7:

   grep -riE 'cent[-]?os' /srv/salt

4. If the above command returns no hits, none of the custom salt states leverage the OS specific salt grain features.

5. If the above command results in non-empty output, remediate the salt states to be OS agnostic.

   The exact changes will depend on the business logic of the salt state. Customers should work with their subject matter experts to properly remediate and test any changes.

Example Remediation​

Salt state found during scan:

{% set defaults = salt['grains.filter_by']({
    'CentOS Linux-7': {
        'network_routes_target_filedir': '/etc/sysconfig/network-scripts/route-',
    },
}, grain='osfinger', merge=salt['pillar.get']('repo_map:merge'), base=None) %}

The remediated salt state:

{% set defaults = {
    'network_routes_target_filedir': '/etc/sysconfig/network-scripts/route-',
    }
%}

Issue ID: I95-56628
Last Updated: 2024-05-02
Introduced in SSR Version: 6.3.0

Problem​

During an HA Conductor upgrade, the primary node upgrade completes successfully. The GUI then presents an option to continue with the secondary node upgrade. Initiating the secondary node from the GUI displays an error explaining that the resource could not be found.

This issue has not been resolved and is currently under investigation. Please use the suggested workaround below.

Release Notes​

Severity​

Major

Status​

Open

Resolved In​

Product​

SSR

Functional Area​

Installation

Workaround​

Log in to the secondary node independently and initiate the upgrade to 6.3.0. The upgrade will complete successfully. Once both nodes have been upgraded, subsequent upgrades can use the normal workflow, where either node can be upgraded from the other.

Issue ID: PLUGIN-2550

Last Updated: 2024-08-05

Introduced in Plugin Version: 128T-ipsec-client-3.6.1

Problem​

The IPSec client plugin (3.6.1) attempted to correct a run time race condition between IPSec tunnel starting before DNS was fully operational in the IPSec namespace. Two changes were made to resolve this issue:

1. A verification step was added to ensure successful DNS resolution before starting IPsec tunnel.
2. A watch dog service was added to monitor IPSec tunnel services and restart them every 30 seconds if not.

During the initial boot process of a router with the IPSec plugin enabled, the WAN interfaces can take some time to fully come up, creating two interactions with the IPSec controller:

• Each call to verify DNS resolution can take up to 6 mins 40 seconds to timeout since the network is unreachable.

• The watchdog, in an attempt to start the failed IPsec tunnel service, initiates another verify DNS resolution API call.

Due to the delayed initialization of the WAN interfaces, the IPSec controller would get backed up with health-check tasks. This backlog prevented the forwarding plane from initializing the device interfaces. In the instance of the reproduction, there was a backlog of 9 hours before the API call from the forwarding plane could be processed. This was verified by letting the reproduction system stay in the stuck state for more than 9 hours. The device interfaces eventually updated the operational status of the Broadband interfaces.

Release Notes​

Resolved the startup race condition by enforcing stricter default timeouts for DNS operations.

Severity​

Major

Status​

Resolved

Resolved In​

IPSEC Client Plugin Release 3.6.2

Product​

SSR

Functional Area​

IPSec Client Plugin

Workaround​

Disable IPSec client​

While the issue does not happen in every environment, one option is to temporarily disable the IPSec plugin for planned reboot of devices.

Monitor and restart the IPSec controller​

Once the system is in the problem state, the following steps can be performed from the linux shell to unblock the highway process:

• systemctl stop ipsec-controller
• Wait for the interfaces and peers over WAN interfaces to come up
• touch /var/lib/128technology/plugins/ipsec/config.json
  • This will restart the IPSec controller and other necessary services

Issue ID: I95-54838
Last Updated: 2024-06-25
Introduced in SSR Version: 6.2.3

Problem​

Large systems with multiple CPU's and many interfaces configured may not initialize the configured interfaces. A large system in this context is one with a core count greater than 30, and more than 10 interfaces. These systems may not initialize the configured interfaces, resulting in a MemoryAllocationException in the Device Disabled Error Reason section of the show device-interface detail command output.

Currently known systems exhibiting this issue are the SSR1500, Dell 7515, and AWS c5.18xlarge, running SSR software version 6.2.3 or greater. Currently deployed SSR1500's running earlier versions of software will experience this issue when they are upgraded to version 6.2.3 or greater.

This issue is under investigation and will be resolved in a future release.

Release Notes​

Severity​

Major

Status​

Open

Resolved In​

Product​

AWS SSR Third-party

Functional Area​

Interface Binding

Workaround​

• SSR1500: Configure 8 or fewer interfaces.
• Dell R7515: With hugepages of 31G, configure no more than 4 interfaces. With hugepages of 58G, configure no more that 8 interfaces.
• AWS c5.18xlarge: Systematically reduce the number of interaces until the remaining interfaces become active.

Issue ID: I95-56484

Last Updated: 2024-05-29

Introduced in SSR Version: 6.2.3

Problem​

The application-director has a race condition that can occur during app-id module updates, app-id database reloads, and configuration changes.

It is possible that stale connections to a database will utilize excessive memory over a long duration (application-director uptime).

The administrator might notice alarms for high system memory and an Application Director alarm with the message IP Database reload failed.

Release Notes​

Resolve application-director stale database connection memory leak.

Severity​

Major

Status​

Resolved

Resolved In​

6.2.5

Product​

SSR

Functional Area​

System Health

Workaround​

Utilizing SSR metrics data, custom charts can be used to view memory usage over time to identify processes that are increasing. Also, the PCLI provides a way to view current process memory utilization and a way to compare the current value a previous point in time.

admin@node.router# show stats process memory process-name application-director
Thu 2024-05-30 20:38:03 UTC
✔ Retrieving statistics...

Process Memory Metrics
----------------------

======== ====== ====================== ============
 Metric   Node   Process-name                Value
======== ====== ====================== ============
 rss      node   application-director     61681664
 vsz      node   application-director   1589444608

The above values will appear as bytes. Shown below is comparing the current value to 10 days prior.

admin@node.router# show stats process memory process-name application-director since 10d
Thu 2024-05-30 20:52:39 UTC
✔ Retrieving statistics...

Since: 2024-05-20 20:52:39

Process Memory Metrics
----------------------

======== ====== ====================== =========
 Metric   Node   Process-name             Value
======== ====== ====================== =========
 rss      node   application-director   1171456
 vsz      node   application-director         0

In this case, the delta is 10Mb which is normal operating behavior.

However, if the deltas over time are increasing significantly such that the current utilization has doubled or tripled, this is a good indicator that this issue is occurring.

If you have confirmed the application-director has significant memory increases over time, the service can be restarted on the offending device using systemctl restart application-director as a privileged User.

Issue ID: I95-56233
Last Updated: 2024-04-26
Introduced in SSR Version: 6.1.7

Problem​

The ENA command-queue becomes unresponsive (device not responding) and the interface no longer passes traffic.

Indications of the symptoms can be observed by viewing the output of show device-interface extended-statistics. There will be an excessive amount of rx errors indicated by the system.

 Extended Statistics:
   bw_in_allowance_exceeded:                0
   bw_out_allowance_exceeded:               0
   conntrack_allowance_exceeded:            0
   dev_start:                               0
   dev_stop:                                0
   device_port:                             4
   dpdk_port:                               0
   linklocal_allowance_exceeded:            0
   pps_allowance_exceeded:                  0
   rx_errors:                 139836994071144
   rx_good_bytes:                           0
   rx_good_packets:                         0
   rx_mbuf_allocation_errors: 139838439323150
   rx_missed_errors:          139837561586960
   rx_q0_bytes:                       1876012
   rx_q0_cnt:                               0
   rx_q0_errors:                      2734322
   rx_q0_l3_csum_bad:                       0
   rx_q0_l4_csum_bad:                       0
   rx_q0_l4_csum_good:                      0
   rx_q0_packets:                   875075952
   rx_q0_refill_partial:                    0
   rx_q1_bytes:                       1862808
   rx_q1_cnt:                               0
   rx_q1_errors:                      2100224

Additionally, the following log messages provide evidence of the failure event: DPDK.log

Apr 02 23:47:22.351 [DPDK| -- ] ERROR (deviceManagerTP) [ENA_COM: ena_com_wait_and_process_admin_cq_interrupts]Timeout waiting for comp_ctx->wait_event
Apr 02 23:47:22.351 [DPDK| -- ] ERROR (deviceManagerTP) [ENA_COM: ena_com_wait_and_process_admin_cq_interrupts]The ena device didn't send a completion for the admin cmd 11 status 0
Apr 02 23:47:22.351 [DPDK| -- ] ERROR (deviceManagerTP) [ENA_COM: ena_get_dev_stats]Failed to get stats. error: -62
Apr 02 23:47:22.351 [DPDK| -- ] ERROR (deviceManagerTP) ena_stats_get(): Could not retrieve statistics from ENA
Apr 02 23:47:25.352 [DPDK| -- ] ERROR (deviceManagerTP) [ENA_COM: ena_com_wait_and_process_admin_cq_interrupts]Timeout waiting for comp_ctx->wait_event
Apr 02 23:47:25.352 [DPDK| -- ] ERROR (deviceManagerTP) [ENA_COM: ena_com_wait_and_process_admin_cq_interrupts]The ena device didn't send a completion for the admin cmd 11 status 0
Apr 02 23:47:25.352 [DPDK| -- ] ERROR (deviceManagerTP) [ENA_COM: ena_get_dev_stats]Failed to get stats. error: -62
Apr 02 23:47:25.352 [DPDK| -- ] ERROR (deviceManagerTP) ena_stats_get(): Could not retrieve statistics from ENA
Apr 02 23:47:26.353 [DPDK| -- ] ERROR (deviceManagerTP) [ENA_COM: ena_get_dev_stats]Failed to get stats. error: -19
Apr 02 23:47:26.353 [DPDK| -- ] ERROR (deviceManagerTP) ena_stats_get(): Could not retrieve statistics from ENA
Apr 02 23:47:26.354 [DPDK| -- ] ERROR (deviceManagerTP) [ENA_COM: ena_get_dev_stats]Failed to get stats. error: -19

journal.log

Apr 03 08:26:02.642583 relayroutereast001 highway[9604]: Failed to queue packet; No ARP for x.x.x.1, interface 1.0, ex: ArpEntryPendException: Pend list max size of 5 exceeded
Apr 03 08:26:02.642595 relayroutereast001 highway[9604]: Send packet failed for session remote-host:  ip-address: x.x.x.1; local-ip x.x.x.242; local-intf: 1.0; peer-name Router11-W

highway.log

Apr 03 09:25:35.173 [LINK|BFDS] ERROR (bfdAgentTP     ) Failed to queue packet; No ARP for x.x.x.195, interface 1.0, ex: ArpEntryPendException: Pend list max size of 5 exceeded
Apr 03 09:25:35.173 [LINK|BFDS] ERROR (bfdAgentTP     ) Send packet failed for session remote-host:  ip-address: x.x.x.195; local-ip x.x.x.242; local-intf: 1.0; peer-name RelayRouter001

Release Notes​

The ENA command-queue becomes unresponsive (device not responding) and the interface no longer passes traffic.

Updated ENA device driver from DPDK/Amazon (upgrading driver from 2.6.0 to 2.9.0). ENA release notes

ENA supports health checks which can be used to detect faulty behavior of the hardware and the driver. As such, an ENA driver watchdog has been developed to check for the following reset reasons:

• HW unresponsiveness – Driver detected that the periodic keep alive signals stopped arriving from the HW through the Asynchronous Event Notification Queue (AENQ).
• Faulty admin queue behavior – The admin queue entered a faulty state.
• Faulty behavior on the IO path – The device returned invalid descriptors or caused the driver to enter the invalid state.
• Missing Tx completions exceeds a dynamically calculated threshold - Prevent Tx ring stalls in case Tx descriptors were not returned by the HW.

Severity​

Critical

Status​

Open

Resolved In​

6.2.6

Product​

SSR

Functional Area​

Datapath

Workaround​

Disable enhanced networking in AWS instance.

A restart of the SSR is necessary to remediate this condition: systemctl restart 128T

Issue ID: I95-54541
Last Updated: 2024-04-25
Introduced in SSR Version: 6.1.5

Problem​

NetVSC does not support Scatter RX, so with new changes to use 9K max RX, it is unable to span multipe 2K packet buffers. When matched with MLX in accelerated networking, the MLX device fails to initialize. During device configuration, user specified MTU exceeding 2K will cause init failure for that device interface.

Limit the MTU (also max RX size in DPDK) of NetVSC devices to SSR packet buffer size.

Release Notes​

Fixes an issue where device-interfaces configured in Azure VM would fail during initialization and port remains operationally down.

Severity​

Major

Status​

Closed

Resolved In​

6.1.8, 6.2.4

Product​

Azure SSR AMI

Functional Area​

Interface Binding

Workaround​

Disable the accelerated networking to allow the device to be bound via PCLI address instead of vmbus-id.