Specifications

Resolved Issues: Release 13.3R6
General Routing
•
On PTX Series routers with MPLS environment (30k transit LSP), large number of
MPLS interfaces (in this case, 200 interfaces) are configured with 0 or 1 MPLS labels.
When these interfaces flap, the FPC kernel memory usage might leak. PR995893
•
The problem is seen in PTX Series routers where the composite nexthops are not
observed, for a given VPN mpls route and hence the show route output command gives
a truncated value which results in script failure. This may be due to default disabled
l3vpn-cnh in case of transit l3vpn router on PTX Series platform. If Resync blob is not
set, RPD will create indirect nexthop for transit route on PE-PE connection network on
PTX. If Resync blob is set, RPD will create composite nexthop for transit route on PE-PE
connection network on PTX Series. Using composite nexthop (cnh) can help scaled
network. However, either indirect (inh) or composite nexthops work properly in control
and forwarding planes. PR1007311
•
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 PTX 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
•
LACP on AE interfaces currently does not support unified ISSU unsupported on PTX
Series platform. A warning message is presented before performing unified ISSU if
LACP is so configured, then the user can discontinue the unified ISSU process. PR1018233
•
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 long living list-id (which can
be due to some node/link protected LSP that has not been re-optimized for 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 with one of the following protocols configuration, flapping the
protocols will trigger the Composite Next-hop change operation. In rare condition,
since it is not proper programmed, the FPC might crash. This is a day-1 issue. - LDP -
MPLS - Point-to-multipoint LSP - RSVP - Static LSPs. PR1045794
•
Fix for this PR was not available at the time of 13.2R7 release time frame. Fix is avaiable
in 13.2R8. 1)Non revertive mode is configured in PTX5000 where external clock is
connected to it. 2)Primary clock is set to gps-0-10mhz 3)Secondary clock is set to
fpc-0 4)Hence master clock will be locked to primary clock 5)When primary clock is
deleted, the master clock locked to secondary clock 6)Since non-revertive mode is
177Copyright © 2015, Juniper Networks, Inc.
Resolved Issues