Specifications

> 64 characters. The resulted jpool
"_jpool_A_RULE_NAME_WHICH_IS_LONG_1234_A_TERM_ALSO_WITH_" will be used
wrongly in both terms. PR973465
•
In L2TP scenario, when the LNS is flooded by high rate L2TP messages from LAC, the
CPU on Routing Engine might keep too busy to bring up new sessions. PR990081
•
Softwire tunnel count management is inconsistent and incorrect, thus the output of
"show service softwire statistics" might be incorrect. PR1015365
•
L2TP LNS dropped all tunnels/sessions after a commit PR1020420
•
On MX Series router that configured as L2TP tunnel switch (LTS), after receiving a
Call-Disconnect-Notify (CDN) message on LNS interface from remote LNS, the L2TP
daemon (l2tpd) might crash and generate a core file. PR1021881
•
An MS-DPC PIC coredump may be generated if ICMP is used with EIM. PR1028142
•
Issue 1: "timeout-remaining" for some filters installed on the DFC pic. (Stream Times
out) Root cause: There was an issue with arithmetic operation that lead to wrap around
of remaining_time variable. Hence it was having a very huge value. Fix: Necessary
conditions are put in place to ensure there is no wrap around happening. Issue 2:
Problem with forwarding traffic to the CD during random DTCP ADDs. (Streams Drop)
Root cause: Whenever a DTCP ADD is received by DFC PIC, a new filter is created and
placed in a list data structure called quick-list. 5-tuples of each data packet that is
hitting DFC PIC is matched against the filters in quick-list. Whenever a match is found,
the 5-tuple(flow) is tagged/attached with the matched filter. The matching would
continue for other flows as well and it continues till the filter is moved out of quick-list.
There was a bug in this logic that made filters to move out of quick-list is a sporadic
manner. Some moved within few millisecond. So, for such filters there won't be any
flows to which they are attached. Hence the issue. Fix: With this fix, the process of filter
movement out of quick-list is streamlined. A filter would move out of quick-list only
after ensuring that all active flows got a chance to get matched against that particular
filter. PR1029004
User Interface and Configuration
•
When PIM is enabled via apply-groups to one routing-instance whose instance-type
is not defined (no-forwarding type is set), incorrect constraint check of PIM will cause
routing protocol daemon (rpd) to crash upon any configuration change later. PR915603
•
CST: chassis core generated while applying group configuration on chassis > FPC.
PR936150
VPNs
•
In the 12.3 release after issuing a "request pim multicast-tunnel rebalance" command
the software may place the default encapsulation and decapsulation devices for a
Rosen MVPN on different tunnel devices. PR1011074
•
The problem is that MSDP is periodically polling PIM for S,G's to determine if the S,G
is still active. This check helps MSDP determine if the source is active and therefore
the SA still be sent. There is a possibility that PIM will return that the S,G is no longer
active which causes MSDP to remove the MSDP state and notify MVPN to remove the
101Copyright © 2015, Juniper Networks, Inc.
Resolved Issues