Specifications

Interfaces and Chassis
•
Refer to the following topology. If we set interface ge-1/0/8 disable, interface xe-2/0/0
and xe-2/1/0 become down status because "asynchronous-notification" feature.
However after 3 or 4 seconds, ether OAM detects link-fault status changed to good.
And then, interface xe-2/0/0 and xe-2/1/0 change link status from down to up. The
conditions are the following. 1. Configure MPLS circuit with ether CCC. 2. Configure
"asynchronous-notification" on CE facing interface in both PEs. 3. Configure ether OAM
to one of PE, CE pair. 4. Use DPC 10 giga-interface on DTU. * This behavior did not occur
with MPC and DPC 1 giga-interface. << topology >>
********************************************************************* local
link remote link DPC 10ge | xe-2/0/0 V ge-1/0/6 ge-1/0/8 [ CE ]----------[ PE ]---------[
PE ]----------[ CE ] xe-2/1/0 ge-1/0/7 ge-1/0/9 (DTU) <--------> <-------> <-------->
ether CCC MPLS ether CCC asynchronous-notification asynchronous-notification
<--------> ether OAM *CE:MX240 PE:MX240
*********************************************************************
PR973840
•
With vrf-table-label configured on the routing-instances, when an FPC with Enhanced
IQ (IQE) PIC is sharing the same Forwarding Engine Board (FEB) with another FPC,
and the FEB has two core-facing interfaces configured with the family mpls on
aforementioned FPCs separately, the label-switched interface (LSI) might be removed
incorrectly on the working FPC when the other FPC with IQE PIC is set to offline.
PR1027034
•
If DPCE 20x 1GE + 2x 10GE X card is present in the chassis, BFD sessions over AE
interfaces may not be distributed.PR1032604
•
Some duplicate entries are reported in jnx-chas-defines.mib. This patch removes the
duplicate entries to fix the issue. PR1036026
•
FRR switching time is much higher than 50 ms (e.g. might be 400-900 ms) when
protected links are located on MX Series Gigabit Ethernet enhanced and hardened
MICs (i.e. MIC model name end with -E or -EH, currently, the supported MICs are
MIC-3D-20GE-SFP-E and MIC-3D-20GE-SFP-EH). PR1038999
•
Using PPP authentication with a specifically crafted PAP Authenticate-Request may
cause the Juniper Networks PPP daemon (jpppd) to crash and restart. After PPPoE
Discovery and LCP phase is successfully negotiated, when the crafted PAP
Authenticate-Request is received, jpppd crashes and no response is sent by the
broadband edge router to the subscriber. The jpppd continues to crash every time the
subscriber re-sends the PAP Authenticate-Request. PR1040665
•
In case of the IQ2 or IQ2E PIC are working in tunnel-only mode, rebooting the tunnel
PIC while the traffic is passing through the tunnel might cause the tunnel PIC to not
transfer traffic any more. PR1041811
•
jpppd daemon ran out of memory as subscribers login failed due to missing CoS
parameters. Below logs will be seen in messages when the subscribers login fail. Nov
16 12:19:21 jtac-host jpppd: Semantic check failed for profile=PPPoE-1-QoS, error=301
Nov 16 12:19:21 jtac-host jpppd: dyn_prof_send_request: add pre_processing failure,
Copyright © 2015, Juniper Networks, Inc.84
Release Notes: Junos OS Release 13.3R6 for the EX Series, M Series, MX Series, PTX Series, and T Series