Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
[+] Expand All
[-] Collapse All

Resolved Issues

This section lists the issues fixed in the Junos OS main release and the maintenance releases. The identifier following the description is the tracking number in the Juniper Networks Problem Report (PR) tracking system.

Resolved Issues: 14.2R8

General Routing

  • In dual Routing Engine systems, when both Routing Engines reboot and then come up, if the mastership is not established or takes time to establish, mib2d might start and exit four times in quick succession. Hence, it will not be running. PR1087428
  • On FPC-SFF-PTX-P1-A(PTX3000) or FPC-SFF-PTX-T(PTX3000) or FPC-PTX-P1-A(PTX5000) or FPC2 -PTX-P1A(PTX5000), packet loss might be observed in an ECMP or aggregated Ethernet scenario. This issue occurs in a race condition in which the unilist is created before ARP learned the MAC addresses, and then the selector table is corrupted. PR1120370
  • In a very rare cases, multiple Routing Engine switchovers might result in an SNGPMB crash. (SNGPMB is the same thing as SPMB. It is on the line card and contains the LCPU. It also manages locally discovered issues and the switch fabric (through the chassis manager thread (CM), which communicates with the fabric manager thread (FM) in chassisd). PR1176094
  • When an ARP entry is learned through the aggregated Ethernet interface, and a route is pointing to that ARP next hop, the ARP entry might not be expired even though the ARP IP is no longer reachable. This issue occurs because the route next hop on the aggregated Ethernet interface gets stuck in unicast state even if the remote end is not reachable, and the routing protocol process (rpd) never determines that ARP is invalid. The route next hop on the aggregated Ethernet interface should be shown in “hold” state when the remote end is not reachable. PR1211757
  • When the fan tray is not properly seated in PTX Series routers, the present PIN from the fan tray might not be detected and the fan tray is declared "Absent" in the output of the command show chassis environment. However, the alarm for this condition is not raised under show chassis alarms, if the alarm is to be raised during a system reboot. PR1216335
  • On PTX Series platforms, if a faulty PSM (half dead) keeps firing up H/W interrupt storms, and the chassisd thread does not get CPU resources for 200 seconds, multiple chassisd core files are continuously generated. The chassisd is just a "victim" of not getting the CPU resources for over 200 seconds. This behavior is as expected (not a bug), and the code is implemented to reset the thread that is stalled for 200 seconds. The Junos OS software is fixed for the chassisd thread not to process such H/W interrupt storms sent from the faulty PSM, so that the chassisd thread can get CPU resources. PR1226992
  • When a user configures TPID value other than 0x8100 on a single tagged interface with the configuration command vlan-tags outer <TPID>.<VLAN ID>, the TPID value 0x8100 will be used instead of the user-specified TPID value. PR1237687


  • In an RSVP scenario, provision RSVP LSP with ldp-tunneling enabled and the LSPs configured with link protection, you can see continuous kernel logs and LDP statistics timeout errors when executing show ldp traffic-statistics. PR1215452

Interfaces and Chassis

  • The TTI SAPI/DAPI of the first byte is fixed an all zero according to the G.709 recommendations. However, the first byte of SAPI/DAPI is encoded as whatever the value is configured and there is no way to set it to "0". With the fix, a Boolean configuration of first-byte-nul for the following TTI respectively is added in the CLI: 1. otu-dapi 2. otu-sapi 3. odu-dapi 4. odu-sapi 5. otu-expected-receive-dapi 6. otu-expected-receive-sapi 7. odu-expected-receive-dapi 8. odu-expected-receive-sapi. If first-byte-nul configuration is set, the first byte of the corresponding TTI will be left as NULL (00 in ASCII code). PR1176036

Multiprotocol Label Switching (MPLS)

  • In an MPLS OAM environment, a rare timing condition can result in routing protocol process (rpd) crash when a memory clean task is delayed. PR1233042
  • On PTX Series platforms, the routing protocol process (rpd) might crash when the RSVP bypass undergoes re-optimization and the re-optimized instance encounters failure before it becomes the main instance. PR1250253

Platform and Infrastructure

  • sysctl_tnp_neighbor_interface_event messages might show up in a router's messages log. PR975539
  • The bidirectional forwarding detection protocol (BFD) session fails to come up when it is configured over the sonet interface which is configured without an IP address. The IFA GET operation performed by BFD fails because there is no address configured on the interface. PR1165720

Routing Protocols

  • When multiple labels become stale in stale-label-holddown-duration (by default, 60 seconds), the timer is restarted and all stale labels are accumulated without being deleting. This might cause memory for allocating labels to be exhausted and then MPLS traffic might be affected due to abnormal or failing label allocation. PR1211010
  • On all platforms, if MPLS goes down because of link flap, FPC reboot, or restart, routing protocol process (rpd), generation of core files could be seen. PR1228388

Resolved Issues: 14.2R7

Forwarding and Sampling

  • SRRD (Sampling Route-Record Daemon) process doesn't delete routes when the DELETE is received from RPD in few configuration cases. This results in build-up of memory in SRRD daemon and once SRRD reaches the limit, it crashes and restarts itself. This happens only when one certain family is not configured on all of the FPC clients (e.g., FPC with inline jflow enabled or PIC with PIC-based sampling enabled is one client). For example, only IPv4 family is configured in all the clients, and IPv6 and MPLS families are not configured for sampling in any of the clients. PR1180158

General Routing

  • The FPC on PTX router might crash and reboot when the Packet Forwarding Engine is handling a fatal error; when the error happens, "TQCHIP0: Fatal error pqt_min_free_cnt is zero" log message will be seen. PR1084259
  • If a static or protocol learned route points to a set of interfaces, effectively resulting in static route pointing to a unilist nexthop, it is possible that the selector weights may not be initialized correctly, resulting in traffic drop. You can mitigate this issue by deactivating and then activating the static route configuration. PR1120370
  • Due to buffer size issue for FPC-SFF-PTX-P1-A (PTX3000) and FPC2-PTX-P1A (PTX5000), will be hitting "ISSU RECONNECT TIMEOUT" or "READY Message Without Reconnect" during unified ISSU (it will be hit if this fix not available in the from build). PR1155936
  • As per design, whenever configuration is committed in PTX3000 platform, chassisd tries to bring the offline SIBs online. The SIB might not have power because of hardware issues (such as seen in this scenario where the SIB couldn't be brought online because of a voltage rail failure). In such cases, software shouldn't try to online the SIB. This attempt is resulting in the software state for this SIB getting stuck in "transition" state thereby resulting in all future offline/online commands to not take effect on this SIB. Fixed software to check if there are any hard errors on that SIB before trying to bring it online. Fix comes in 14.2R7, 15.1F5-S2, 15.1F6, 15.1R4, and 16.1R1. PR1161110
  • For PTX routers, the IPv6 unilist next-hop member will become "replaced" status on Packet Forwarding Engine (PFE) after interface flapping with IPv6 ND (Neighbor Discovery) timeout. While the problem is happening, routing-table will display all right next-hop status but cannot forward traffic since forwarding next-hop in Packet Forwarding Engine is in "replaced" status and no longer active. PR1177023


  • In P2MP with NSR scenario, it might be observed about 100 ms traffic loss during Routing Engine switchover in steady state with link protection enabled. It is because the nexthops added by applications in the backup Routing Engine do not match nexthops fetched from kernel. This nexthops mismatch causes LSPs to reestablish after switchover. PR1095488

Platform and Infrastructure

  • In certain cases, with some events such as disable/enable of links followed by Routing Engine rebooting or GRES enabled switchover, below error message could be seen due to a software bug where it doesn't handle an internal flag properly: “KERNEL/Packet Forwarding Engine APP=NH OUT OF SYNC: error code 1 REASON: invalid NH add received for an already existing nh ERROR-SPECIFIC INFO:” PR1107170
  • Configuring one group with configuration of routing-instances and applying this group under routing-instances, then the rpd process will crash after executing "deactivating/activating routing-instances" commands. As a workaround, you can avoid using "apply-groups" under routing-instances hierarchy. PR1109924

Routing Protocols

  • In multicast environment, when the RP is FHR (first-hop router) and it has MSDP peers, when the rpf interface on RP changed to MSDP facing interface, due to the multicast traffic is still on the old rpf interface, a multicast discard route will be installed and traffic loss will be seen. PR1130238

Resolved Issues: 14.2R6

Class of Service (CoS)

  • This PR does optimization in AE SNMP handling. If all the links in an AE bundle go down, then any CoS SNMP query for this AE IFD/IFL will return cached values.

General Routing

  • It is reported that on PTX platforms, when the firewall filter is configured on the loopback interface of the device, due to bad error handling or NULL pointer, all the FPC on device may continuously crash and unstable. Because the issue is not reproducible, the trigger of the issue is not clear. PR996749
  • When a labeled BGP route resolves over a route with MPLS label (e.g. LDP/RSVP routes), after clearing the LDP/RSVP routes, in the short window before the LDP/RSVP routes restore, if the BGP routes resolves over a direct route (e.g. a one-hop LSP), the rpd process might crash. PR1063796
  • When hold-time Up is configured on IFDs of PTX, SyncE line clocks can fail by restarting the associated FPCs. In a paticular test scenario with relatively large hold-time Up 60,000 ms, SyncE line clock can fail by restarting the associated FPC, and it is never recovered until the IFD is dis/enabled. Both 10GbE and 100GbE interfaces indicate the same clock fail issue. PR1130084

High Availability (HA) and Resiliency

  • With NSR enabled on multiple Routing Engine systems, when a dynamic GRE tunnel is configured, performing Routing Engine switchover might causing rpd to crash repeatedly on backup the Routing Engine. PR1130203

Routing Protocols

  • In multicast environment, when the RP is FHR (first hop router) and it has MSDP peers, when the rpf interface on RP changed to MSDP facing interface, due to the multicast traffic is still on the old rpf interface, a multicast discard route will be installed and traffic loss will be seen. PR1130238


  • For Layer 2 circuit, PTX3000 uses different VCCV (Virtual Circuit Connectivity Verification) BFD control packet format from that of MX and the other PTX platforms. PTX3000 negotiates Router-alert control channel type, and uses PW Associated Channel Header of Channel Type : 0x0021. However, MX and the other PTX platforms use the Channel Type is 0x0007 without IP/UDP headers. JUNOS takes the Channel-type 0x0007 as default. MX and the other PTX platforms work as expected. This is PTX3000 specific issue. PR1116356

Resolved Issues: 14.2R5

General Routing

  • When a labeled BGP route resolves over a route with MPLS label (e.g. LDP/RSVP routes), after clearing the LDP/RSVP routes, in the short window before the LDP/RSVP routes restore, if the BGP routes resolves over a direct route (e.g. a one-hop LSP), the rpd process might crash. PR1063796
  • When a switchover is done from one Routing Engine to the other, in graceful-switchover redundancy mode, there is a brief period early in the transition of the SIB to online state, during which unsoliciited (not corresponding to an attempt by the CPU to access the SIB via PCIe) errors are received at the downstream PCIe port on the CB to the SIB. The fix is to mute the generation of such errors during this brief period of the switchover. PR1068237
  • On PTX5000 platform with FPC2 equipped, if 48x10G/12x40G PIC or 4X100G PIC is inserted into the FPC, continuous "pmbus_get_devaccess: fpc PMBUS dev table not initialized" error logs might be seen on the device due to memory corruption. These errors are mostly seen when making the OTN related configuration change (e.g. set up OTN rates). But it is not the only trigger. For example, physical interface (IFD) disable/enable may result in the issue too. The messages might disappear for some time by restarting the FPC, however, the corruption will still exist. PR1077985
  • The FPC on PTX Series router might crash and reboot when the Packet Forwarding Engine is handling a fatal error, when the error happened, "TQCHIP0: Fatal error pqt_min_free_cnt is zero" log message will be seen. PR1084259
  • On PTX Series platform with external clock synchronization interface configured, when both BITS external clocks are disconnected at the same time, the 100GbE-LR4 FINISAR interface might flap. This link flap issue is narrowed down to the operation of data-path FIFO within CFP. When both the BITS clocks are disconnected, the reference clock jumps to "free-running" mode. This transition leads to a phase shift in reference clock. Due to this phase shift, the data rates into and out of the FIFO will temporarily not match, leading to a FIFO over-run or under-run condition. This over-run or under-run condition forces a FIFO reset, and the output signal is distorted. So the far-end interface detects 'local-fault', then return 'remote-fault' back to the near-end, hence a link flap. After change for this PR: - User need to manually config FPC recovered clock port for each clock put into "chassis synchronization source". - Only one clock of each FPC can be put into "chassis synchronization source". PR1091228
  • On PTX platform, if there are scaling configurations (for example,5000 routes and each of them with 64 ECMP paths configured) on a single interface and L2 rewrite profile is applied for the interface, the FPC may crash when deactivating and then activating the CoS configuration of the interface. PR1096958
  • Entropy Label Capability is enabled by-default on all Juniper Networks PTX Series platforms. On PTX Series transit LSRs that carry LSPs with Entropy Label Capability, packet loss can be observed due to data errors when one or more labeled route entries are not properly removed from the hash table (ie. following LSP optimization or MBB event) because the 'stale' entries are pointing to corrupted route memory. As a result, when the MPLS label that is associated with the 'stale' entry is re-used, data errors are seen for packets using the corresponding label. PR1100637
  • FFP is a generic process that shall be called during commit process, and FFP calls the PDB initialization as part of its process. On the PDB-unsupported platforms , when committing configuration, some error messages will be seen. PR1103035
  • On PTX Series platform, when yanking out FPC or SIB ungracefully (for example, pulling the line card out of the chassis unintentionally when the line card is carrying the traffic), there might be small probability that it can impact any of the FPCs with Grant Scheduler (GS) and Request Table (RT) fatal interrupt occurred. PR1105079

Interfaces and Chassis

  • On PTX platform, if the configurations that have per-unit-scheduler configured on the interface, but without proper class-of-service configuration for the same interface, due to lack of commit check, the device control daemon (dcd) may fail to return "commit error" and pass the configuration. Following is an example, user@re0# set interfaces et-0/0/1 per-unit-scheduler vlan-tagging unit 0 <<<<< The configuration for interface et-0/0/1 user@re0# commit check error: per-unit-scheduler is configured but class-of-service is blank <<<<< This is correct behavior error: configuration check-out failed <<<<< .. user@re0# set class-of-service forwarding-classes queue 7 q7 <<<<< user@re0# commit check configuration check succeeds <<<<< This is wrong behavior because et-0/0/1 does not have class-of-service configuration * If reboot this router after committing, the administrator cannot access without console because the router cannot read this configuration. When deleting the above configuration after rebooting, telnet and so on could be used. PR1097829


  • In the output of the CLI command "traceroute mpls ldp", the addresses of the interfaces on transit PTX Series routers might be shown as "". PR1081274
  • When an LSP is link-protected and has no-local-reversion configured, if the primary link (link1) is down and LSP on bypass (link2), then another link (link3) is brought up, before the LSP switch to link3. If link1 is enabled and link3 is disabled, the LSP will stuck in bypass LSP forever. This is a timing issue. PR1091774

Network Management and Monitoring

  • Due to inappropriate cleanup in async library, disable multiple interfaces while SNMP is polling interface oids might cause mid2d process crashing. PR1097165

Platform and Infrastructure

  • The MIB counter or "show Packet Forwarding Engine statistics traffic" shows junk PPS and invalid total traffic output counter. PR1084515

Routing Protocols

  • In Junos OS release 14.1R1 and later, the rpd process might crash while executing CLI command "show isis backup spf results". PR1037114

Software Installation and Upgrade

  • In certain conditions, when /var is not mounted from a persistent filesystem, executing a Junos OS upgrade will have unexpected results. This is caused by an inexact check of whether we're running from an Emergency VAR. PR1112334

Resolved Issues: 14.2R4

General Routing

  • The power management feature of PTX5000 is enhanced to manage the power supplied to the FPCs by configuring the ambient temperature of the chassis. You can set the ambient temperature of the chassis at 25° C, or 40° C. On system initialization, the power manager reads the ambient temperature and allocates power to the FPCs according to the power budget policy at that temperature. If any FPC consumes more power than the configured value for more than three minutes, the PWR Range Overshoot alarm is raised for that FPC, and the power manager overrides the configured ambient temperature setting of that FPC, and resets its ambient temperature to the next higher level and reallocates power according to the new temperature setting. All the overshooting FPCs remain in the dynamic ambient temperature mode until the next reboot, or until you override it with a CLI command. The power manager then resets the power budget of the FRUs, including the overshooting FPCs, according to the configured ambient temperature setting.

    To configure the ambient temperature, include the set chassis ambient-temperature statement at the [edit] hierarchy level.

    Note: If ambient temperature is not configured, then default ambient temperature is set as 55° C.


    See Monitoring the Power Consumption of PTX5000 FPCs by Configuring the Ambient Temperature , and Managing Power Allocated to PTX5000 FPCs on the Basis of Chassis Ambient Temperature Configuration.

    CLI commands are enabled for PTX5000, which were supported earlier on MX Series only.

Resolved Issues: 14.2R3

General Routing

  • Prior to this fix "show interface diagnostics optics" command shows output for all four lanes for 10G ports of 48x10GE 12x40GE QSFP+ PIC. Normal behavior would be to display output for only the lane that the port belongs to. PR959514
  • On PTX5000, the packet drop is observed along with the parity error read from l3bnd_ht entry corresponding to certain addresses. With this SRAM parity error, ASIC will unconditionally drop the packet even if PTX Series does not use l3bnd_ht during lookup. The parity check for l3bnd_ht lookup for PTX5000 will be disabled to avoid the SRAM parity error and packet drop as a workaround. We also add new log message to report the counter value change for slu.hw_err trap count - TL[<num>]: SLU hw error count <xxx> (prev count <yyy>). PR1012513
  • A reboot might be required when chassis is powered up the first time. PR1034662
  • Using jnxoptIfOTNPMFECIntervalTable and jnxOpticsPMIntervalTable it is not possible to walk these tables from the middle before this fix. PR1039030
  • When there is link/node protection/ECMP for RSVP/LDP transit or egress LSPs with huge scaling and continuous flapping of LSPs like auto-bandwidth case, traffic might get black-holed upon LSP re-optimizations. The issue would get triggered if the same unilist list-id (unilist list-id is a unique id for unilist nexthop) is allocated for two different unilist forwarding topologies. This situation arises when the unilist list-id wraps around after max value of 65535. After the wraparound, if there is a long living list-id (which can be due to some node/link protected LSP that has not been re-optimized for a long time), the Packet Forwarding Engine assigns the same list-id during allocation (upon other LSP re-optimizations), and this will trigger the issue as the new unilist will be directed to incorrect interface. PR1043747
  • On PTX Series platform running Junos OS Release 12.1 and later, for interface connected via optical system such as DWDM, when the interface is administratively disabled, there might be a delay (300-400msec) for the system to detect the event and during which time, traffic blackhole might be seen. Note if you disable the interface by breaking the Rx or Tx link, the issue will not happen. PR1043762
  • On PTX Series platform with one of the following protocols configured, flapping the protocols will trigger the Composite Next-hop change operation. In rare condition, since it is not properly programmed, the FPC might crash. This is a day-1 issue. - LDP - MPLS - Point-to-Multipoint LSP - RSVP - Static LSPs PR1045794
  • For PTX Series router, the unilist next-hop member will have a 'replaced' status on the Packet Forwarding Engine after interface flapping with ARP timeout. While the problem is happening, the routing table will display an all right next-hop status but cannot forward traffic since the forwarding next-hop in the Packet Forwarding Engine is in 'replaced' status and no longer active. PR1046778
  • On PTX Series platform, non-revertive feature for clock synchronous sources does not work correctly. After deleting the primary clock and then adding it back, it will fallback to the primary clock but not stay in secondary. PR1052549
  • When the port on 24x 10GE(LWO) SFP+ (which never went link up since the PIC is onlined) is configured as CLI loopback, the ports will receive framing error during until the interface gets physically linked up. (that is, with real fiber instead of CLI loop). There would be no problem in normal use. This is only seen in self-loopback testing with CLI loopback. PR1057364
  • In LDP tunneling over single hop RSVP-based LSP environment, after enabling "chained-composite-next-hop", the router might fail to create the chained composite next hops if the label value of VPN is equal to the label value of LDP. PR1058146
  • On PTX Series routers, the interrupt-driven basis link-down detection (an interrupt-driven link-down notification is generated to trigger locally attached systems to declare the interface down within a few milliseconds of failure) might fail after performing unified in-service software upgrade (ISSU). The interrupt might be prevented after performing unified ISSU due to disable the interrupt registers before unified ISSU but never restored afterwards. PR1059098
  • On PTX Series routers, the interrupt-driven link-down detection might stop working. When the line card is receiving a multiple back-to-back fault in a very short duration (no matter from remote or local), it might fail to detect all the received interrupts, and this failure might cause delay of the link-down detection (for example, it might take PTX Series ~300ms to make interface down). PR1060279

Interfaces and Chassis

  • Configuring ODU FRR under otn-options for 2x100G DWDM PIC is an unsupported command on PTX Series router. Adding such configuration could result in an FPC crash and restart. PR1038551.


  • On P2MP MPLS LSP transit router with NSR enabled, when RSVP refresh reduction feature is enabled and LSP link protection is configured on all interfaces, slight P2MP traffic loss might be seen after the graceful Routing Engine switchover (GRES) is done. PR1023393
  • This is a regression issue on all Junos OS releases related to a timing factor. When LDP session flaps, over which entropy label TLV or any unknown TLV is received, the LDP speaker might not send label withdraw for some prefixes to some neighbors. As a result, these neighbors will still use stale labels for the affected prefixes. PR1062727

Platform and Infrastructure

  • In some rare conditions, setting up configuration access privilege using the "allow-configuration-regexps" or "deny-configuration-regexps” statements will crash the management daemon (mgd), which serves a central role in the user interface component of Junos OS. PR1029384

Routing Protocols

  • After adding Shared Risk Link Group (SRLG) configuration on an interface, the interface would be deleted from the TED database. If the interface is traversed by LSP optimal path, in some cases, the re-optimization that occurs selects a sub-optimal path. PR1035359
  • In MPLS TE scenario, if IS-IS shortcuts for family inet6 are enabled, the LSP flapping might cause memory leak, which could result in traffic blackhole or FPC crash. PR1049675
  • When running Simple Network Management Protocol (SNMP) polling to specific IS-IS Management Information Base (MIB) with invalid variable, it will cause the routing protocol process (rpd) to crash. PR1060485

Resolved Issues: 14.2R2

General Routing

  • LACP on AE interfaces currently does not support unified ISSU on PTX Series platform, so a warning message is present before performing unified ISSU with LACP configured. Then the user can discontinue the ISSU process. PR1018233
  • On PTX Series, route installation might fail. PR1029548
  • On PTX Series platform with equal-cost multipath (ECMP) route, bouncing the route next-hop interface hosted PIC, the Packet Forwarding Engine might get the route next-hop change message before the interface up message when the PIC is coming up, which results in the next-hop not installed in Packet Forwarding Engine leading to traffic black-holing. PR1035893
  • PCS statistics counter is now displayed for PTX Series 100GE interfaces in this command: cli > monitor interface <intf> PR1030819


  • In MPLS traffic engineering with link or node protection enabled, after adding Shared Risk Link Group (SRLG) configuration, the bypass LSP might ignore the constraint and use an unexpected path. PR1034636

Routing Protocols

  • With any single hop BFD session and MPLS OAM BFD session configured over same interface, when the interface is disabled and enabled back immediately (e.g. a delay of 10 sec between the two commit check in), the single hop BFD session might get stuck into Init-Init state due to Down packet is received from other end for MPLS BFD session on the same interface might get demultiplexed to single hop BFD session wrongly. PR1039149

User Interface and Configuration

  • Commit Error happens with load patch or load replace, while applying commit difference on backup Routing Engine as part of fast commit process. Error looks like - user@host# commit check re0: configuration check succeeds re1: /var/tmp/juniper.db-2233-patch.sync:9:(0) syntax error error: remote load-configuration failed on re1. PR1029474

Modified: 2017-12-12