Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Known Issues

 

This section lists the known issues in hardware and software in Junos OS Release 14.1R9 for the PTX Series.

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

Class of Service (CoS)

  • In case of member links of an aggregated Ethernet interface scattering over multiple Packet Forwarding Engines, if the FPC where member links of the aggregated Ethernet interface reside get reset or the interface is disabled, there might be a dip in the output of SNMP walk on the aggregated Ethernet related queue MIB (such as jnxCosQstatTxedPkts). The behavior is intermittent. PR1122343

General Routing

  • The logical interface (IFL) count is incorrect and will not be repaired until a PIC restart. PR882406

  • Ipv6 transit statistics are not supported yet. PR896253

  • The maximum number of ingress LSPs each Packet Forwarding Engine can support is changed from 16,000 to 10,000. If more ingress LSPs are needed, distribute them to different Packet Forwarding Engines (which can be on the same or different FPC). PR900388

  • For Step 1,"initial_connection" is one and calls the send_clear_all_chassis_alarm function, which clears the alarms database on alarmd and sends the current active alarms list to alarmd. After this, chassisd and alarmd are in sync with respect to alarms. In Step 2, chassisd loses the alarmd connection until Step 3. In between these two steps, some of the alarms are cleared on chassisd that were raised before step 2. When connection to alarmd is again established, only current active alarms list is sent to alarmd, because "initial_connection" is zero here, and the chassis_resend_alarms() is invoked. Only the list of current active alarm is sent. Alarmd is still not aware of previously cleared alarms and still displays a red or yellow alarm LED on craft-interface even though there are no alarms in the show chassis/system alarm command. PR938082

  • In rare cases, a race condition might occur, in which a duplicate SNMP index might be assigned to the same interface. As a result, the mib2d daemon might crash. This issue should not cause service impact. PR1033249

  • In certain rare conditions, FPC VoQ will wedge, which will drop packets on the ingress Packet Forwarding Engine for the PTX Series router. Because the wedge is unable to be reproduced, detection of the wedge condition is introduced so that an alarm is raised once the wedge condition is detected within 10 seconds. PR1127958

  • On a PTX Series router with a faulty power supply modeule (PSM.) The PSM might generate excessive interrupt requests. Because hardware interrupt requests are processed by the chassis process (chassisd), excessive interrupt requests might cause chassisd to restart when the condition persists more than 200 seconds. PR1226992

Interfaces and Chassis

  • On dual Routing Engine platforms, when adding the logical interfaces (IFLs) and committing, the device control process (dcd) on the backup Routing Engine might fail to process the configuration and keep it in the memory. In some cases, it might be observed that the memory of the dcd keeps increasing on the backup Routing Engine. PR1014098

  • This command shows the Tx/Rx power/thresholds and alarms incorrectly. Here are the changes to address this PR: 1. The "-18 to -5 dBm" refers to the per wavelength power, but the thresholds in the CLI are the cumulative power that can be received from multiple channels. So the change will be to keep the values as is and remove the "Laser" from the Receive power thresholds. 2. Remove the "laser output power xxxxx" thresholds because they do not have corresponding alarms. 3. Change the "laser output power alarms" to "Tx power xxx alarm/warn", these do not have corresponding thresholds. 4. Rename the "Laser rx power xxxx threshold" to "Rx power xxxx". 5. Rename "laser xxx power" to "xxx power". 6. Add the 2 los alarm/warn thresholds, which when configured will change the defaults for Rx low power warning and alarm. set interfaces et-x/y/z optics-options los-alarm-threshold"/"set interfaces et-x/y/z optics-options los-warning-threshold. PR1115135

MPLS

  • Currently configuration of both fast-reroute and link-protection/node-link-protection on a single LSP is allowed. But when you configures both types of protection on the LSPs, it might cause scaling issues in your network. There is a change requirement to restrict the configuration to either fast-reroute or link/node-link protection on a per-LSP basis. PR860960

  • When there are statically configured ingress and transit LSPs, due to a timing issue, there could be a scenario wherein the selfID used by the transit LSP might be allocated to the ingress LSP. The ingress static LSP does not reuse the same selfID during routing protocol process (rpd) restart, whereas the transit static LSP tries to reuse the same selfID. This leads to routing protocol process (rpd) crash due to the collision when the transit LSP tries to reuse the same selfID. PR1084736

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

  • In an RSVP-based P2MP scenario, if a sub-LSP switchover to bypass LSP due to a PIC being offline occurs, then when a new sub-LSP is established through setup-protection, the deletion of the old sub-LSP might result in deletion of both sub-LSPs. PR1132050

  • If RSVP link-protection optimize-timer is enabled, routing protocol process (rpd) memory might leak in "TED cross-connect" when a bypass LSP is being optimized. PR1198775

Platform and Infrastructure

  • Adaptive load-balancing functionality is supported only for unicast traffic. If the aggregate bundle contains logical interfaces for bridge or VPLS domains, flooded traffic might be dropped. PR821237

  • On PTX Series routers, parity memory errors might occur in pre-classifier engines within an MPC. Packets will be silently discarded. Because such errors are not reported, they are more difficult to diagnose. PR1059137

  • When you configure one group with a configuration of routing-instances and apply 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

  • When you have two paths for the same route, the route gets pointed to the unilist next hop, which in turn gets pointed to two separate unicast next hops. The route is determined by OSPF and BFD is enabled on one of the paths, which runs through an l2circuit path. When the link on the l2circuit gets cut, the link flap is indicated by BFD as well as through OSPF LSAs. Ideally the BFD should indicate the link-down event before the OSPF LSA. But at the current situation, the OSPF LSAs update the current event a second before BFD. As a result the route ends up pointing to a new unilist next hop with the weights swapped. However, the unicast next hop (for which the L3 link is down) added to the unilist next hop and BGP interprets the link as being up, thereby updating the weights inappropriately, resulting in traffic loss. Once the BFD link-down event is processed at the OSPF protocol level, now the route points to only the unicast next hop and therefore traffic flows through the currently active link. The traffic outage occurs for less than a second during FRR. As a workaround, this issue if the BFD keepalive intervals are maintained around 50 ms with a multiplier of 3 as opposed to 100 ms with a multiplier of 3. PR1119253

  • In a multicast environment, when the rendezvous point (RP) is a first-hop router (FHR) and has MSDP peers, when the rpf interface on the RP changes to an MSDP-facing interface, a multicast discard route is installed and traffic loss is seen because multicast traffic is still on the old rpf interface. PR1130238