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

No index entries found.

Known Issues

This section lists the known issues in hardware and software in Junos OS Release 15.1F4 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.

General Routing

  • PTX Series does not support the queuing PICs but by default Junos OS will program chassis scheduler map which will generate the following logs: "fpc2 COS(cos_chassis_scheduler_pre_add_action:2140): chassis schduler ipc received for non qpic ifd et-2/1/3 with index 131 /kernel: GENCFG: op 8 (COS BLOB) failed; err 5 (Invalid)Fix: Adding check to stop sending chassis scheduler map on PTX platform." Fix: Adding check to stop sending chassis scheduler map on PTX Series platform. PR910985
  • It is reported that on PTX Series platforms, when the firewall filter is configured on the loopback interface of the device, due to bad error handling or NULL pointer, all the FPCs on the device may continuously crash and become unstable. Because the issue is not reproducible, the trigger of the issue is not clear. PR996749
  • When we have two paths for the same route, the route gets pointed to Unilist NH which inturn gets pointed to two separate Unicast NHs. The route is determined by OSPF and we have BFD enabled on one of the paths which runs through an l2circuit path. When the link on the l2circuit gets cut, the link flap is informed by BFD as well as through OSPF LSAs. Ideally the BFD should inform the link down event before the OSPF LSA. But at the current situation, the OSPF LSAs update the current event a second before BFD. Due to this reason, we do get the route to be pointing to a new UNILIST NH with the weights swapped. But the Unicast NH for which the L3 link is down, gets added to the Unilist NH, the BFD assumes the link to be up, and hence updates the weights inappropriately and hence we do see traffic loss Once the BFD link down event is processed at OSPF protocol level, now the route points to only UNICAST NH and hence we do see traffic flowing through the currently active link The traffic outage would be hardly for less than a second during FRR. Also, this can be avoided if the BFD keepalive intervals are maintained around 50 ms with multiplier as 3 as opposed to 100ms with a multiplier of 3. PR1119253
  • If a static 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
  • Interface status may not change accurately when FPC CPU usage is 100%. The problem will be seen if the following conditions are met on Gladiator. 1) Laser off/on are introduced from remote end in order to change the status of an interface on local end (Gladiator) 2) On local end (Gladiator), the FPC (with the interface for which status change is expected) CPU is 100% during this laser on/off event. An interface will not change its status from Down to Up or Up to Down triggered because of laser off/on from end, when the FPC CPU usage is 100%. The interface will correctly reflect its status as soon as FPC CPU usage drops below 100%. PR1130920
  • Using the "write coredump" vty command on FPC causes crash after the core is uploaded. PR1139370
  • For In-Line JFlow feature: When send traffic at line rate, sometimes Inactive timeouts are incrementing. PR1142977

Interfaces and Chassis

  • On PTX Series routers, TX optical threshold value is shown incorrect for the interfaces in the PIC P1-PTX-2-100G-WDM. This PR will fix only the TX power issue reported in the 2x100G DWDM OTN PIC. PR1084963
  • On PTX platform "cfp_lh_update_1sec_pm_var received" messages are periodically logged with Warning level. The severity of this message has been revised. PR1089592

Routing Protocols

  • On shmlog unsupported platforms (for example, PTX Series and T Series platforms), the following message might be seen after a configuration change: PTX-re0 rpd[42030] shmlog not initialized for PIM - not provisioned in platform manifest file The message does not indicate an error, it just indicates that shmlog is not supported on the PTX Series platform. The severity of the log has been reduced to INFO. PR1065055

Related Documentation

Modified: 2016-04-20