Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Open Issues

Learn about open issues in this release for ACX Series routers.

For the most complete and latest information about known Junos OS Evolved defects, use the Juniper Networks online Junos Problem Report Search application.

EVPN

  • On all Junos OS Evolved platforms that support EVPN-MPLS (Ethernet Virtual Private Networks -Multiprotocol Label Switching) services, during switchover or l2-learning restart, some EVPN next hops are not correctly associated with the routing instance in the Routing Engine impacting the traffic forwarding. PR1633344

  • On performing graceful Routing Engine swithchover on ACX7509 platform with EVPN services, some physical interfaces are missing. The physical interfaces come up post reboot.PR1646722

  • On ACX7024 ::Pseudo wire setup and tear down rate might be low. This is due to system CPU limitation.

General Routing

  • On the ACX platform running Junos OS Evolved, you cannot clear or reset the disk option specified in the scheduled request node reboot command. The node reboots with the disk option last specified. PR1517596

  • In some corner cases, traffic is not scheduled equally between strict priority queues. This can happen in the following scenario. Priority queue configured and completely utilizes the bandwidth and remaining queues are starved and traffic completely drops on those queues. In this state if we configure a second strict high priority queue, traffic is not scheduled equally between strict priority queues. This is a hardware specific issue, ACX7509 specific. If we have a shaper on priority queue this issue does not happen. Also if the traffic starts after the configurations no issues seen.PR1577035

  • ACX7509: some of the interfaces from 16x100G and 20XSFP56 does not go down after evo-pfemand restart. PR1592388

  • The timingd application cannot be successfully restarted on ACX7100 or ACX7024 with G.8275.1 profile configuration. If there are PTP streams configured and there is a timingd restart due to timingd core dump or requested application restart, the PTP streams might not be restored correctly, and changes to the PTP stream configuration after the restart might result in PTP streams that do not forward data packets correctly. It is very likely that a restart always affect the streams.PR1597120

  • G.8275.1- G.8273.2 1PPS cTE performance might be marginally outside class-C for PTP BC on ACX7100-48L, especially for mixed speed port testing with combinations of 10G / 25G channelized ports and 100G ports. On each reboot, the 1PPS cTE measurement might be within the class-C measurement threshold, or might randomly be out of threshold by a few nanoseconds.PR1607381

  • A restart of DHCP takes more time because of internal issues with the SIGTERM event. PR1610229

  • In ACX7509, 1GE interface does not come up with copper 1G SFP-T optics and this issue is specific to copper 1G cables. PR1614286

  • On ACX Series platforms, 400G DAC flap might be seen after OIR, FPC restart, device reboot enabling or disabling interface.PR1618488

  • On ACX Series devices, ungraceful removal (OIR) of FPC or an FPC fault might result in a PCIE MAJOR alarm PCI Uncorrected error on dev 0000:00:03.0 which does not get cleared. The only way to clear this alarm is reboot of the device. There are 2 situations in which this alarm can be seen:

    1. FPC is faulty: In rare FPC fault cases, the PCI Uncorrected error alarm might be seen along with FPC going to a Fault state as indicated by the show chassis fpc command. This is accompanied by other FPC major alarms. Once the faulty FPC is replaced with a good one, the alarm is still seen, and a reboot is required to clear this alarm. Post identification of the fault and FPC replacement, this alarm is harmless, and FPC state can be confirmed through the show chassis fpc command.

    2. Ungraceful OIR: The ungraceful removal of FPCs is not recommended. This operation might result in PCI Uncorrected Error alarm.

    Use one of the following two methods to do a graceful FPC OIR removal:

    • Execute the request chassis fpc slot <slot > offline command from the CLI.

    • Press the Offline Button for 1 second on the FPC to offline the FPC. Once the FPC is gracefully offlined both LEDs - PWR and STS go off. The FPC can be removed at this point.

    PR1620197

  • If a system is fully scaled across features and firewall is also scaled, CPU consumption might be more for a small window of around 5 seconds after every 18 seconds or so. Evo-pfemand might be busy collecting the scaled firewall statistics for that 5 second window and any other applications such as pfe-cli trying to execute commands might fail during it. PR1629342

  • When CLI based trigger of FPC restart is given and subsequently a Routing Engine switchover event is triggerred, before the FPC's have come back online - the FPC's might not come online after switchover. It can be stuck in offlining or Fault state.PR1645305

  • On ACX7509 platforms, interface flaps are seen on performing primary role switchover using the primary Routing Engine offline button press. Traffic drop is seen due to interface flap. PR1668509

  • ACX7024: With high scale of L3VPN VRF instances system CPU usage might continue to be high. PR1655310

  • After channelizing 100G port to 4x25G on ACX7024, channelized ports do not come up if FEC is set to FEC74. PR1684770

Routing Protocols

  • ACX7024: The rpd process might generate core file seen after removal or restoration of configuration. This occurs rarely. PR1683239

Services Applications

  • When the Paragon Active Assurance (PAA) Test Agent path trace measurement is running on the ACX7100 and ACX7509 routers, you might randomly see the error event Hardware timestamp error when the combined bandwidth of all of the running tests exceeds 140 Mbps. PR1674211

  • A Paragon Active Assurance (PAA) Test Agent running on ACX7100 and ACX7509 might report significant jitter spikes, sometimes exceeding 40ms in latency measurements, even in an idle system. These spikes might originate from the device and do not necessarily represent actual network latency. The data plane forwarding performance is not affected by this issue. PR1680309

  • When the Paragon Active Assurance (PAA) Test agent is running a UDP test at a rate exceeding 140 Mbps, packet drops might occur. Packet drops are caused by a too small receive buffer. Increase the receive buffer in the PAA UDP test settings to 1000000 to resolve the issue. PR1686327

User Interface and Configuration

  • The system might ask for your password when you are trying to save configuration file. PR1665008