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 M Series, MX Series, and T 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 a subscriber management environment with ANCP CoS adjustment, after enabling and disabling SRL service, the ANCP bandwith correction might not get adjusted properly, and the CoS "overhead adjustment mode" and "byte adjust" might not be restored. PR1114519


  • Advertising MACs with VLAN ID set to zero for the base EVPN instance is not implemented. As a workaround, use vlan-id-none to claim the RFC compliance. PR945247

  • In a multihoming EVPN scenario, if the customer-facing interface is an aggregated Ethernet interface, after moving an interface from the EVPN instance into a VPLS instance, traffic loss might be seen on CE device facing the FPC. PR1126155

  • In an EVPN scenario with active/active mode, the split horizon is broken for the PE device that has the MAC as DRC status (remote control MAC). PR1156187

Forwarding and Sampling

  • This defect is seen only when an existing child link from an aggregated Ethernet interface is moved to a newly created aggregated Ethernet interface, simultaneously from both ends. The new aggregated Ethernet interface is listed as a child link in the existing aggregated Ethernet interface in the output for the show interface ae<>.0 extensive CLI command. PR965872

  • When VRRP is configured on MX Series routers with MPC/MIC interfaces, static MAC entries are installed on the Packet Forwarding Engine in the MAC database as part of the MAC filter installations. The MIB walk on some object identifiers (OIDs) will trigger a walk over the MAC MIB entry(walk over the static MAC entries with no OIDs) , which results in an error message. During the walk, it is expected that no entries are read from static MAC database entries; however, the EODB is not set to indicate that the MAC database walk has ended. This error log does not have any functional impact on the MIB walk: mib2d[xxx]: MIB2D_RTSLIB_READ_FAILURE: check_rtsock_rc: failed in reading mac_db: 0 (Invalid argument) mib2d[xxx]: SNMP_GET_ERROR1: macStatsEntry getnext failed for interface: index1 ge-*/*/* (Invalid argument) The following oid might trigger the issue: 1/ Rpf related oid 2/ AtmCos related oid 3/ Mac related oid , such as jnxMacStatsEntry 4/ PMon related oid 5/ jnxSonetAlarmTable 6/ Scu related oid 7/ jnxCmRescueChg 8/ jnxCmCfgChgEventLog 9/ jnxIpv4AdEntReasmMaxSize PR1042610

  • On MX Series routers with MPC/MIC-based platforms, when the Layer 3 packets destined to an Integrated Routing and Bridging (IRB) interface hit the underlying Layer 2 logical interfaces (IFLs), the egress feature list of the Layer 2 logical interfaces might get skipped, and the features under the family bridge (for example, the firewall filter) on the Layer 2 interfaces might not be executed. PR1073365

  • After committing a configuration change, the following error message might be displayed in the error log: dfwc: invalid filter program pointer, dph_abst=0xffefd82c dph_comp=0x0. There should be no impact to traffic or protocols. This is an informational message about how the dfwc process is compiling the firewall filters for use on the FPCs. It can be safely ignored. PR1116538

  • If a bandwidth-percent-based policer is applied on an aggregated Ethernet bundle without the shared-bandwidth-policer configuration statement, traffic will hit the policer even if the traffic is not exceeding the configured bandwidth. As a workaround, configure the shared-bandwidth-policer configuration statement under the policer. PR1125071

  • The default-arp-policer option is applied to every relevant logical interface (IFL) to rate-limit the ARP traffic. You can disable the default-arp-policer option by running the hidden command set firewall disable-arp-policer. Note that improper application leads to the Routing Engine getting overloaded with a bulk of ARP traffic, leading to a typical DoS scenario. The issue is that even after disabling default-arp-policer, it still affects the logical interface in some scenarios, such as after DUT reboot or when a new logical interface is created. PR1198107

  • Firewall filter family "any" with shared-bandwidth-policer on an MC-AE interface does not reconfigure bandwidth or carve up the policer when standby becomes active after A/S switchover; it drops all packets. PR1232607

  • In some stress test conditions, the sampled process crashes and generates a core file when connecting to L2BSA and EVPN subscribers aggressively. PR1293237

General Routing

  • When you execute the CLI command show app-engine virtual-machine instance detail, if the virtual machine (VM) is not ACTIVE, a message should be displayed if it is waiting for secondary disk space to be available or for a particular interface to come up. PR824665

  • When both Routing Engines in a dual-Routing Engine system reboot too quickly with GRES enabled, the ipsec-key-management process requires a manual restart. PR854794

  • In a multicast scenario, when an interface that is used for multicast next hops is deactivated or deleted, the operation might cause Layer 2 (L2) descriptor memory leaking and crashing of the Flexible PIC Concentrator (FPC). PR858643

  • On M Series routers, packets are dropped upon setting the aggregated Ethernet interface LP discard-data command; however, there is no CLI command to display the drop count. PR876190

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

  • In a fabric black-hole condition in which fabric ASICs are not pulling traffic out from the queuing ASIC and unified ISSU is being performed, FPCs might crash while reinitializing the ASIC during unified ISSU reboot. This issue occurs because of residual traffic in the queuing ASIC. If the queuing ASIC does not provide a way to flush traffic, FPCs might crash. The absence of traffic is a primary requirement for successful reinitialization of the queuing ASIC during unified ISSU. PR889475

  • The traffic-drd process (daemon) might hang once after logging in to the service PIC and restarting the net-monitor process. PR889982

  • With 6000 service sets configured, when the service sets are activated and deactivated in very quick succession, the mspmand process might crash, and the service running on the service PIC might be affected. PR915784

  • With chassis maximum-ecmp 64 configured, when a route with 64 ECMP LSP next hops and CoS-based forwarding (CBF) is enabled with 8 forwarding classes (64*8=512 next hops), not all next hops will be installed on the Packet Forwarding Engine , because the number of next hops has exceeded the maximum allowed (309). PR917732

  • Removing the PD-5-10XGE-SFPP while the PIC is online can cause the FPC to crash. PR922655

  • Performance is dropped by 50 Kpps due to the addition of new functionality since the previous release. PR935393

  • 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

  • On an MX Series Virtual Chassis platform, when you restart one or both of the standby Routing Engines, the log message ksyncd_select_control_plane_proto: rhost_sysctlbyname_get: No such file or directory might be observed as the ksyncd process (daemon) attempts to select a communication protocol (UDP/TCP). After several tries, it will fall back to TCP and proceed as normal. PR945925

  • Flow control is asserted whenever the show services sessions command is executed when a large number of sessions are present in MS-MIC, resulting in traffic drop. PR947674

  • BFD session flap is expected in a scaled environment by restarting chassisd or the FPC. PR969023

  • The following actions trigger fabric errors: (1) having traffic between two FPCs and (2) offlining the destination FPC. As a result of these triggers, fabric errors like Fo: Request timeout errors will be seen on the source FPC. Because the source FPC has outstanding requests to the offlined destination FPC, the requests time out, resulting in errors. These messages are expected. PR971956

  • In a Layer 3 wholesale configuration, DHCPv6 advertise messages might be sent out with a source MAC address containing all zeroes if the subscriber is terminated on the demux interface in a non-default routing instance. For subscribers on the default instance, there is no such issue observed. PR972603

  • When inline MLPPP is configured, packets are indiscriminately dropped on the member links when the traffic is oversubscribed. PR982175

  • When a MAC address moves from one virtual tunnel endpoint (VTEP) to another VTEP, it is not learned behind the new VTEP until the old VTEP ages out this MAC address. This will cause traffic for this MAC address to be silently dropped or discarded until it ages out on the old VTEP. PR988270

  • IPsec endpoint fails to decrypt packets on some of the tunnels with NAT between IPsec endpoints. PR989054

  • The CLI command restart packet-triggered-subscribers might cause sessions to become out-of-sync between the SRC SAE and MX Series Routing Engine, which results in the failure to create new subscribers. PR990788

  • An inconsistency between JUNIPER-VPN-MIB and MPLS-L3VPN-STD-MIB with the number of interfaces for a routing instance has been identified. For example, note the following configuration: user@router-re0> show configuration routing-instances ri1 instance-type vrf; interface ge-2/0/8.10; interface lo0.10; route-distinguisher 65000:1; vrf-target target:65000:1; vrf-table-label; According to MPLS-L3VPN-STD-MIB, there are two interfaces in this routing instance: MPLS-L3VPN-STD-MIB :: mplsL3VpnVrfAssociatedInterfaces: OID: Description: Total number of interfaces connected to this VRF (independent of ifOperStatus type). {master} user@router-re0> show snmp mib walk mplsL3VpnVrfAssociatedInterfaces. = 2. However, according to JUNIPER-VPN-MIB, there are three interfaces in this VRF: JUNIPER-VPN-MIB :: jnxVpnIfStatus OID: Description: Status of a monitored VPN interface. user@router-re0> show snmp mib walk jnxVpnIfStatus. = 5 jnxVpnIfStatus. = 5 jnxVpnIfStatus. = 5 The interfaces in the example are: {master} user@router-re0> show snmp mib walk ifDescr.733 = ge-2/0/8.10 ifDescr.754 = lo0.10 ifDescr.774 = lsi.0 PR1011763

  • On MX Series routers with MPC3E, MPC4E, MPC5E, and MPC6E, Junos OS does not support short (sub-second) interface hold-time down configuration. A hidden configuration statement is introduced to ignore DFE tuning state during the hold-down timer period. This configuration statement allows sub-second hold-down timer on MPC3E, MPC4E, MPC5E, and MPC6E: set interfaces <intf name> hold-time up <U ms> down <D ms> alternative The configuration statement does not work on or support MPC5E 3D Q 2CGE+4XGE and MIC6 2X100GE CFP2 OTN, and therefore we recommend configuring a hold-time down of more than 3 seconds for these two cards. PR1012365

  • There is an existing optimization in the Routing Engine kernel where the add IPCs of interface objects (IFD/IFL/IFF/IFA) are not sent to the FPCs (that is, these IPCs get suppressed) when the corresponding physical interface (IFD) no longer has IFDF_PRESENT flag set. The idea is that because chassisd has already removed this flag from the IFD, all processes (daemons) will start cleaning up the whole hierarchy and subsequently DCD will delete IFAs/IFFs/IFLs under it, before deleting the IFD itself. The kernel keeps track of which object's add IPC was suppressed for which FPC peer (it is a per object bit vector), and it suppresses the delete IPC too if the add was suppressed. This logic does not exist for RT and next-hop objects, so sometimes FPCs might receive a next-hop IPC for which the parent logical interface (IFL) gets suppressed in the kernel; hence it complains. This is a day 1 issue. There is no workaround for this issue. These error messages are harmless because DCD deletes everything once it is scheduled. PR1015941

  • The software development kit (SDK) service process (ssd), which runs on the Routing Engine and is responsible for communications between the SDK application and Junos OS, might crash after Routing Engine switchover and following reboot of both Routing Engines. Because the ssd acts as the broker daemon for applications connecting to Juniper Distributed Application Framework (JDAF) services, the applications will lose JDAF connectivity when ssd restarts. PR1031860

  • 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 any service impact. PR1033249

  • MSDPC-HTTP redirect stops working. PR1039849

  • In a Layer 2 port-mirroring scenario with maximum-packet-length configured, packets are not getting mirrored to any of next-hop-subgroup interfaces when a new interface is added to the next-hop-subgroup. As a workaround, remove the configuration of maximum-packet-length. PR1052559

  • When the JAM package is to be un installed, the next-generation MPC cards must first be taken offline. When there is a large number of RLSQ interfaces configured, it takes a few minutes for all the interfaces to be deleted from the system. Attempting to un install the JAM package before all the interfaces are deleted can result in Routing Engine crash. To avoid such a situation, a sufficient time gap must occur between offlining the next-generation MPC and un installing the JAM package so that all the interfaces are deleted from the system. PR1052571

  • A log message that requests upgrade of VSC8248 firmware of MPC3/MPC4 is displayed during Junos OS upgrade. PR1058184

  • LACP is not supported with virtIO. PR1059231

  • Output MTU counter shows incorrect data in the show pfe statistics traffic command output. PR1061111

  • With the inline L2TP IP reassembly feature configured, MX Series routers with MPCs/MICs might crash due to a memory allocation issue. PR1061929

  • On MX Series routers with MPC2E-3D-NG/MPC3E-3D-NG/MPC5/MPC6 line cards, the Ethernet frame loss measurement (ETH-LM) feature does not work. PR1064994

  • When using the 'mpls-ipv4-template' sampling template for non-IP traffic encapsulated in MPLS, log messages such as the following can be seen frequently (depending upon the rate of traffic, it could be in the range of few messages to 2000-3000 messages per minute): Feb 18 09:28:47 Router-re0 : %DAEMON-3: (FPC Slot 2, PIC Slot 0) ms20 mspmand[171]: jflow_process_session_close: Could not get session extension: 0x939d53448 sc_pid: 5 Depending on the frequency of the messages per second the, eventd process(daemon) utilization can shoot up processing these syslogs at the Routing Engine. Eventually. high CPU utilization is observed at the Routing Engine that can by checked by the command show chassis routing-engine or the freebsd Top command under the shell. CPU states: % user, % nice, % system, % interrupt, % idle <<<<< user cpu % (top command) "show chassis routing-engine" Routing Engine status: <> CPU utilization: User percent <<<<<<<<<<<<< Background percent Kernel percent Interrupt percent Idle percent PR1065788

  • The configuration executed by customers is logically forming a loop. BGP tries to use inet.3 to perform next-hop resolution. With the current configuration (next-table), it requires to perform resolution from the inet.0 again. From a packet flow point of view, when the packet lookup occurs on inet.0, then it receives a "next-table inet.0" instruction, which means that you need to start from inet.0 to perform the lookup again, which is Step 1 of the lookup. This is causing the loop. PR1068208

  • Class 4 (32W) Optics are not supported on MPC4E (2CGE+8XGE). Upon insertion and removal of a Class 4 optic, the Tx laser will remain powered off, even when a supported optic is inserted. PR1068269

  • With MPC5E, high temperature is observed, causing the fan to rotate at a higher speed. PR1070346

  • For MX Series Virtual Chassis, performing unified ISSU in a scaled subscribers environment might cause all Virtual Chassis members to restart unexpectedly. PR1070542

  • ICMP echo_reply traffic with applications like IPsec will not work with the MS-MIC and MS-MPC cards in an asymmetric traffic environment, because these cards employ a stateful firewall by default. The packet will be dropped at the stateful firewall because it acknowledges an ICMP reply that has no matching session. PR1072180

  • In a scaled subscriber management environment (for example, 3.2K PPPoE subscribers), after heavy login/logout, the session setup rate keeps decreasing and also PAP-NAK messages are sent with "unknown terminate code". This continues until the broadband network gateway (BNG) stops accepting PPP sessions and all newly incoming sessions are stuck in PAP Authentication phase (no PAP ACK received). PR1075338

  • When a FI: Cell underflow or a FI: Aliasing on allocates error is encountered, a system only logs error messages but does not create a CMERROR to raise an alarm. PR1076299

  • TM - RPD_KRT_Q_RETRIES: Route Update: No buffer space available. PR1077576

  • Process (daemons) using synchronous API, can get stuck because these APIs are blocking in nature and do not allow mib2d or ifinfo to perform any activity during this period. For example, the NMS queries on interfaces (for which mib2d shall respond) could time out if mib2d is stuck in such a state. PR1078505

  • FPC/MIC usually performs i2c bus transactions to detect presence/absence of SFPs. When it fails to read SFP EEPROM due to i2c bus timing-related and/or i2c bus hang issues, the FPC/AFEB crashes with interface flap. The i2c bus should be held up in adverse state because faulty EEPROM SFP or non-Juniper-qualified SFP might be used. PR1080566

  • If an MX Series router is service PIC equipped but does not have any service PIC specific configurations, the CPU usage on this PIC/FPC might be high. As a workaround, create some configurations using one of the following commands to avoid this issue: system processes process-monitor traceoptions, chassis fpc <fpc-slot> pic <pic-slot>adaptive-services service-package extension-provider, or services. PR1081736

  • The MX Series routers with MPC/MIC interfaces-based line card might reboot immediately after restarting l2tp daemon at L2TP network server (LNS) during login/logout of scaled (for example, 10K) L2TP clients. PR1082321

  • If an RX OTN signal is received with non zero values in the OPU4 PSI[2:81] overhead bytes, software might report the following alarm: ODU-MSIM MOD-1-2 MAJOR SA 2015-04-16 ODU PM MSIM Multiplex Structure Identifier Mismatch . This is a false alarm, is not service-affecting, and can be safely ignored. The datapath is not affected by MSI values when OPU4 payload type is 100GBaseR (PT=0x7). PR1083141

  • IPsec performance drops while testing with one next-hop style service set and 10 sessions for PPS 600000, Framesize 1518. PR1084376

  • TCP messages do not have their MSS adjusted by the Multiservices MIC and MPC if they do not belong to an established session. PR1084653

  • On MX Series routers with MS-MPC or MS-MIC, memory leaks will be seen with jnx_msp_jbuf_small_oc object, upon sending millions of Point-to-Point Tunneling Protocol (PPTP) control connections (3-5M) alone at higher cells per second (cps) (greater than 150K cps). This issue is not seen with up to 50,000 control connections at 10,000-30,000 cps. PR1087561

  • When some actions are logged to the firewall filter log, the log might have control characters in the message. This should have no operational impact to the operation of the router. PR1093897

  • When BGP multipath is enabled in a virtual routing and forwarding (VRF) scenario, if auto-export and rib-group are configured to leak BGP routes from this VRF table to another(for example, the default routing table), then traffic coming from the default routing instance might not be properly load-balanced, because the multipath route leaked into the default routing table is not the active route. This is a random issue. As a workaround, only use auto-export to exchange the routes among the routing tables. PR1099496

  • On MX Series platforms, in a subscriber management environment, when carrying scaling subscribers, as the Packet Forwarding Engine process (pfed) memory usage grows along with the number of subscribers, the pfed memory usage might reach the limit (that is, 512M) because of the subscriber scale and number of services attached to the subscribers (for example, when carrying more than 140K single stack PPPoE subscribers per chassis, and 4 services per subscriber). As a result, the pfed might crash due to memory exhaustion. PR1102522

  • A cpcdd core file is observed in a scaled scenario. PR1103675

  • On MX Series platforms, the output of the CLI command show system subscriber-management route might not be displayed. PR1104808

  • When using write coredump to invoke a live core file on an FPC in a T Series router, the contents of R/SR ASIC memory (jtree SRAM) will get dumped. When there is a parity error present in the SRAM, the core file will abort and the FPC will crash. As a workaround, configuring set chassis pfe-debug flag disable-asic-sram-dump before write coredump will help to avoid the issue. PR1105721

  • Dynamic VLAN logical interface (IFL) is not removed with remove when-no-subscriber configuration. PR1106776

  • With IPv6 access route configured in dynamic profile, when the router receives an IPv6 SOLICIT message that requests only Prefix Delegation but no IPv6 address, the access route will not be installed successfully. PR1126006

  • Insufficient time to allow an MPC5/MPC6 card to lock on the clocking source during FPC boot time might cause a major alarm due to "PLL Error." PR1137577

  • ALG-SIP64: SIP session fails when the IPv4 SIP client in the public network initiates a SIP call with the IPv6 SIP client in the private network. PR1139008

  • On T-series and TX-series platforms, when master SPMB goes for a reboot (goes offline/online), all SIBs will get hard-restarted. As a result, the traffic will be silently dropped or discarded for more than 1 minute. PR1160658

  • After unified ISSU from Junos OS Release 13.3 to 14.1R5.5 , QSFPs in MPC3D are not shown in output for show chassis hardware: show chassis hardware Hardware inventory: Item Version Part number Serial number Description Chassis JN12306BEAFB MX480 Midplane REV 05 710-017414 ACRB8288 MX480 Midplane <....> FPC 4 REV 07 750-045372 CAAR5021 MPCE Type 3 3D CPU REV 08 711-035209 CAAS2734 HMPC PMB 2G FPC 5 REV 11 750-045372 CABX4918 MPCE Type 3 3D CPU REV 08 711-035209 CABW8604 HMPC PMB 2G MIC 0 REV 07 750-033307 CABX5746 10X10GE SFPP PIC 0 BUILTIN BUILTIN 10X10GE SFPP Xcvr 9 REV 01 740-031980 AQ72QP0 SFP+-10G-SR MIC 1 REV 08 750-036233 CAAM1171 2X40GE QSFPP PIC 2 BUILTIN BUILTIN 2X40GE QSFPP <<<<<<<<<<<<< QSFPs are not seen Fan Tray Enhanced Left Fan Tray # interfaces are created : > show interfaces terse | match et-5/2 Feb 28 06:53:20 et-5/2/0 up up et-5/2/1 up up PR1164898

  • On MX240, MX480, and MX960 platforms, due to resources contention during multiple commit processes, the kernels might display a I2C bus read/write timeout error. PR1174001

  • In a virtual tunnel (VT) tunnel environment with forwarding-class, when using an aggregated Ethernet interface to terminate subscribers on the device and the aggregated Ethernet interface has members on two different FPCs, due to a software defect, the mirrored traffic does not go to the correct forwarding class as expected. The issue is also seen when terminated subscribers and VT tunnel hosted interface are on two different FPCs (non- ae interface case). PR1174257

  • Physical interface output statistics are not updated correctly when using service accounting. PR1175074

  • OSPFv3 neighbors over IPv6 flap periodically on MS-MPC/MS-MIC. This issue has traffic impact. PR1175489

  • If the MIC-3D-4XGE-XFP is used with MPC2E-3D-NG or MPC3E-3D-NG, the interfaces on the MIC-3D-4XGE-XFP connected to a DWDM device might flap continuously. PR1180890

  • Ingress queuing configuration on next-generation MPC2E is leading to a host loopback wedge. PR1189800

  • When PIC PB-4OC3-4OC12-SON-SF (4x OC-12-3 SFP) is replaced with PB-4OC3-1OC12-SON2-SFP (4x OC-3 1x OC-12 SFP) and a CLI commit is done, the replacement PIC bounces. As a workaround, do a full commit immediately after bringing the replacement PIC online. Doing so will bounce the PIC one time, and the replacement PIC does not bounce with consecutive commits. PR1190569

  • After system boot up or after PSM reset, you might see the PSM INP1 circuit Failure error message. PR1203005

  • In certain interface scaling scenarios, during configuration commit/rollback, you might see an fpcx error message. You can safely ignore this message because of the FPGA monitor mechanism on DPC cards for logical interface mapping (ifl_map). Between the deletion of a physical interface and the monitoring event, this mechanism checks through the stored logical interfaces. While the mechanism tries to find the family of a recently deleted logical interface that was not cleaned from the the ifl_map, harmless messages might populate the log file. PR1210877

  • On MX Series devices, packet forwarding traffic is stopped when a transient memory parity error is in MPC Endpoint Mapper (EPM) port-group wedge. PR1220019

  • Unsuccessful DCE-RPC ALG sessions result in stale gates and lead to MS-MPC/MS-MIC restart when the gates cleanup occurs after timeout. PR1230868

  • A MX box running 14.1R9 version of Junos might display the error message ?_FPC: Error requesting SET BOOLEAN, illegal setting 39 [CM_BOOLEAN_ROUTE_MEMORY_ENHANCED]? PR1232626

  • FPC and Routing Engine might get stuck in high CPU usage when DDoS SCFD is turned on. PR1237486

High Availability (HA) and Resiliency

  • During a router hardware upgrade procedure, in a dual Routing Engine system, the newly installed Routing Engine might overwrite the other Routing Engine configuration with the factory-default configuration. As a result, both Routing Engines might start up in "amnesiac" mode. PR909692

  • In a rare scenario, GRES might not reach the ready state and might fail to start, because the Routing Engine does not receive the state ack message from the Packet Forwarding Engine after performing GRES. This is a timing issue. It might also stop Routing Engine resource releasing and then cause resource exhausting. As a workaround, reboot the system if this problem occurs. PR1236882


  • Executing the show multicast route CLI command with a crafted argument might cause the CLI process to crash, creating a cli.core.0.gz core file. The impact of the crash is limited to the CLI process executing the command, and therefore malicious exposure is minimal. PR939262

Interfaces and Chassis

  • When the show chassis alarms command is run, FPC X Dest Err alarm is observed, though no Dest Errors are reported in commands show chassis sibs OR show chassis fabric fpcs. This issue is commonly observed on routers where the fabric blackholing feature (enabled by default) has identified traffic being silently dropped or discarded on one or more FPCs due to errors observed on a single FPC. The feature attempts to recover the situation by rebooting the affected single FPC. To confirm, run the show chassis fabric reachability detail command and verify the output to match: Fabric reachability action: Fabric reachability action : FPC action Acting on : Single FPC error. PR890598

  • Point-to-Point Protocol (PPP) interface maximum transmission unit (MTU) changes after making any configuration changes to the system. PR897940

  • Non-existent leg in the aggregated Ethernet bundle prevents DHCP subscribers from coming up. PR918745

  • In a large scaled VPLS environment (in this case, more than 2K+ VPLS sessions), in a rare condition, when larger scale routers are updated during unified ISSU, one of the FPCs in the router might get stuck in a "Ready" state. PR986264

  • In scenario that MX Series routers serve as a L2TP network server (LNS) and Point-to-Point Protocol (PPP) sessions through established L2TP tunnels, if malformed or incomplete PPPoE packet is received, the jpppd process (daemon which is responsible for PPP based protocol) might crash while stripping HDLC header. PR1002164

  • 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, the memory of the dcd keeps increasing on the backup Routing Engine. PR1014098

  • Performing a power off by pressing the OFFLINE button on the master Routing Engine causes packet loss even though GRES/NSR is configured. FPC gets rebooted after Routing Engine switchover, which also causes traffic loss. PR1034164

  • Service name table PADI delay timer accuracy remains off by 2 more seconds than the configured delay value. PR1052632

  • After changing the MTU on the physical interface, an IPv6 link local address is missing on the static VLAN demux interface. PR1063404

  • After Routing Engine switchover with NSR enabled in Junos OS Release 14.1, VRRP sessions might flap once. PR1072086

  • MAX-ACCESS value has been changed in jnx-otn.mib for the following OIDs: jnxOtnIntervalOdu15minIntervalNumber



    The value has been changed from read-only to not-accessible to be in line with newer MIBs. PR1080802

  • In a VPLS scenario with a specific CE mesh group configured, after a Routing Engine restart or Routing Engine master switchover, the flood next hop for the mesh group might not be programmed properly. As a result, traffic for the VPLS instance is silently dropped or discarded. PR1087293

  • Deactivating or activating logical interfaces might cause BGP session flapping when BGP is using VRRP VIP as source address. This is caused by a timing issue between the dcd and VRRP overlay file. When dcd reads the overlay file, it is not the updated one or the one yet to be updated. This results in error and dcd stops parsing the VRRP overlay file. PR1089576

  • To ensure that the router or switch is reachable for management purposes while it boots or if the routing protocol process fails to start properly, you can configure a backup router, which is directly connected to the local router or switch (that is, on the same subnet) through its private management interface (for example, fxp0 or me0). When a backup router running IPv6 and a static route to reach the management network are configured, some invalid IPv6 routes are added to the default forwarding-table on the master or the backup Routing Engine. PR1100981

  • The jpppd process might crash and restart due to a stale memory reference. The jpppd process restart results in a minimal impact to system and subscribers. All connected subscribers remain connected, and only the subscribers attempting to connect during process restart will need to retry. PR1121326, PR1132373

  • In a dynamic PPPoE subscriber management scenario, when the system is overloaded with requests coming, the subscribers might fail to log in during a race condition. PR1130546

  • The jpppd might crash might crash and generate a core file due to memory heap violation associated with processing MLPPP requests. PR1187558

  • If the configuration can be scaled to have the inner list to have more than 4000 VLANS, the commit VLAN configuration operations might fail. PR1207939

  • Under a particular condition in configuring interfaces that have vlan-id/vlan-tags configured, the commit operation might fail with an error message. PR1234050

  • In a VPLS multihoming scenario, the CFM packets are forwarded over the standby PE device link, resulting in duplicate packets or a loop between the active and standby link. PR1253542

  • If one logical interface (IFL) changes virtual router state from master to backup, traffic might be silently dropped or discarded for other logical interfaces that share which shares the same group ID on a physical interface (IFD). PR1305327

Layer 2 Ethernet Services

  • xSTP with NSB is not supported on aggregated Ethernet interfaces; therefore you might observe multiple seconds of traffic drops during GRES switchover. PR1028313

  • Racing occurs between DDOS protectionand MAC pinning, when both features are configured, MAC pinning discard notifications might get blocked by DDoS protection. PR1042671

  • On a BGP peer configured between two routers over a logical tunnel (lt) interface, you deactivate and reactivate the scaled configuration a few times, the lt interface might reject all the ARP reply packets. As a result, ARP resolution does happen over this interface, so the unicast routes are not in the correct state. Pinging to such an interface will fail. PR1059662

  • There is a bug the code for handling the redistribution of periodic packet management (PPM) transmit and adjacency entries for LACP when the interface entry is in pending distribution state. This issue might cause ppmd to crash after graceful Routing Engine switchover. PR1116741

  • IPv4 and IPv6 long Virtual Router Redundancy Protocol (VRRP) convergence delay and unexpected packet loss might occur when a MAC move for the IRB interface occurs (for example, when flapping the Layer 2 interface that is the underlying interface of IRB on the master VRRP). PR1116757

  • For forced version STP, if a port receives its own BPDU, the BPDU is not processed. PR1163835

  • If a client sends a DHCP request packet, and option 55 includes PAD option (0), a DHCP ACK will not be sent back to the client. PR1201413

Layer 2 Features

  • In a high-scale VPLS configuration, modification of a tunnel interface through a restart or reconfiguration might cause the Packet Processing Engine to access an invalid interface, resulting in minor packet loss and logging of Packet Processing Engine traps. Existing traffic flows on the Packet Forwarding Engine are not affected. The router recovers quickly, and normal operation resumes with the new configuration. PR976972

  • When input-vlan-map with a push operation is enabled for dual-tagged interfaces in enhanced-IP mode, there is a probability that the broadcast, unknown unicast, and multicast (BUM) traffic might be dropped or discarded silently on some of the child interfaces of the egress aggregated Ethernet interfaces or on some of the equal-cost multipath (ECMP) core links. PR1078617


  • Given a point-to-multipoint branch LSP, the value of jnxMplsTeP2mpTunnelTotalUpTime is reported incorrectly after a new instance of the branch LSP is re-signaled at the ingress. PR543855

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

  • When soft-preemption is enabled on the ingress router and the preemption is configured with the aggressive option (to preempt RSVP sessions whenever bandwidth is lowered or a new, higher-priority session is established), if one LSP is established over the aggregated Ethernet interface, link failure might cause the bandwidth to become insufficient at the ingress. The CSPF is not triggered to establish a new path for more than 30 seconds (because data is missing from the traffic engineering database), and eventually the LSP is hard preempted. PR1030586

  • When using mpls traffic-enigneering bgp-igp-both-ribs with LDP and RSVP both enabled, CSPF for interdomain RSVP LSPs cannot find the exit area border router (ABR) when there are two or more such area border routers (ABRs). This causes interdomain RSVP LSPs to break. RSVP LSPs within the same area are not affected. As a workaround, you can either run only RSVP on OSPF ABR or IS-IS L1/L2 routers and switch RSVP off on other OSPF area 0/IS-IS L2 routers, or avoid LDP completely and use only RSVP PR1048560

  • 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. Ingress static LSP does not reuse the same selfID during rpd restart, whereas the transit static LSP tries to reuse the same selfID. This leads to rpd crash due to the collision when the transit LSP tries to reuse the same selfID. PR1084736

  • In a BGP prefix-independent convergence (PIC) edge scenario, when the ingress route (the primary route) fails, because the LDP might fail to send the session-down event to the Packet Forwarding Engine correctly, the Packet Forwarding Engine might still use the primary path to forward traffic until (in some cases, 3-5 seconds for 30,000 prefixes) the global convergence is completed by the interior gateway protocol (IGP). This issue might also be seen when the delay-delete CLI command is configured. In this scenario, the session-down event might get sent to the Packet Forwarding Engine correctly. However, due to local reversion, the primary path might also be chosen as the forwarding path when it is deleted. PR1097642

  • Due to some data structure changes of ipc messages in 64-bit rpd, some of 32-bit applications (for example lsping, lspmon) would not work normally when rpd is running in 64-bit mode. Code analysis has determined that the following applications will not work as expected when rpd is running in 64-bit mode: 1. monitor label-switched-path <rsvp_lsp> 2. monitor static-lsp <static_lsp> 3. ping mpls rsvp multipoint <p2mp_lsp> 4. ping mpls ldp p2mp root-addr lsp-id <lsp_id> 5. ping mpls lsp-end-point <lsp_prefix_address>. PR1125266

  • Bening error messages can occur when bringing up new interfaces or line cards; they can be ignored. PR1136033

  • This issue is related to RSVP-TE FRR (RFC#4090) interoperability between Juniper Networks and Cisco devices. The correct behavior would be to add sub-object RRO, which will help change of label during FRR active scenario. If Juniper Networks is the PLR (point-of-local-repair), then it does not set the "label recording desired" flag in the backup path messages. Also, Juniper as the merge point (MP)does not send the label sub-object in the RESV RRO for the backup LSPs. However, the Cisco PLR sends the backup path message with the "label recording desired" flag set and expects to see the label sub-object in the corresponding RESV RRO. So as a result, in the scenario where the Cisco device is the PLR and the Juniper device is the MP, a change in the RESV label while protection is in use at the PLR will not get propagated upstream beyond the MP. . PR1145627

  • Static MPLS LSP using VT interface as an outgoing interface would not come up. PR1151737

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

  • When using RSVP-TE protocol to establish LSPs, make before break (MBB) might not be quit and will start again when there is a failure on PSB2 (RSVP Path State Block for new LSP) in some cases where PathErr is not seen. (For example, for a PSB2 that is already up and there is PathErr processing for it in place already; in this case, no PathErr is seen owing to local-reversion and a quick flap.) As a result, no rerouting happens even if the TE metric cost is raised. This issue has more chances of occurring when there is non-default optimize switchover delay. PR1205996

Network Management and Monitoring

  • When sessions are coming at a high rate, a few syslogs are not logged. PR868812

  • A mib2d process memory leak might be seen after GRES and activating or deactivating the aggregated Ethernet interface. PR882529

  • SNMP engine-id is generated by default from default IP of the management interface. The failure in v3 authentication is due to different engine-ids on the master and backup members of the MX Series Virtual Chassis setup. If the snmp engine-id needs to be uniform across all the Routing Engines in the MX Series Virtual Chassis set up, you can configure set snmp engine-id local <local-engine-id-suffix>. PR1059569

  • In rare cases, when the mib2d process attempts connection with the snmpd process and there are pending requests waiting to be finished, the mib2d process might crash and the CPU utilization will be high around the same time as the crash occurs. PR1076643

  • A trailing newline was erroneously added to the $$.message variable. This had undesirable effects for some use cases when using the event-options policy <> then execute-commands commands <> stanza. PR1200820

Platform and Infrastructure

  • In Junos OS Release 10.0 and 10.1 versions built before April 22, 2010, the T640-FPC4-ES is not correctly initialized. This can result in packets being corrupted, and eventually the FPC might reset. PR549580

  • The old-rom-packet-count command displays information about installed line cards. A non zero number indicates that the bootrom on that line card needs to be updated. PR776703

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

  • When scripts are synchronized from one Routing Engine to the other, the destination for the scripts in the other Routing Engine should be based on the configuration used on the other Routing Engine. However, anissue prevents this from occurring, and the destination for scripts depends on the current Routing Engine from which the scripts were synchronized instead of the configuration on the other Routing Engine. PR841087

  • The audit process (auditd) handles system accounting events and tries to send them out to configured RADIUS servers. If there is any problem in sending these accounting records to RADIUS (in this case RADIUS servers are unreachable or disconnecting frequently), auditd will spend more time on each accounting record because of the retries, and during this time if there are multiple accounting events, all those records will be in the queue. Eventually, the queue exceeds its limit and auditd crashes. PR863697

  • The issue occurs on M Series, MX Series, and T Series platforms. If the GPRS tunneling protocol controller process (gtpcd) is not running (for example, you kill the gtpcd), the old Global Session Controller (GSC) card might lose contact. (Under normal circumstances, the GSC should move to the other board.) PR868342

  • After the show version detail command is executed, the syslog message UI_OPEN_TIMEOUT: Timeout connecting to peer might appear. This message is only cosmetic and can be ignored. PR895320

  • When there is huge logical interface (IFL) scaling on aggregated Ethernet interfaces (500 or more) with more than 32 member links and when all FPCs are restarted one by one, followed by member link addition to the link aggregation group (LAG), the state dependency evaluation in the kernel will take a long time given the scale involved, all the states from the Routing Engine. This is an uncommon sequence of events/conditions. PR938592

  • Backing up the configuration with transfer-on-commit does not work in an MX Series Virtual Chassis (MX-VC) environment PR947444

  • With enhanced LAG (as part of enhanced-ip mode in Junos OS Release 14.2), packets are not transported on IRB. This issue is observed under certain conditions for traffic from IRB to aggregated Ethernet. PR961685

  • Interface status by OAM-CFM action-profile does not sync up after GRES failover in an MX Series Virtual Chassis topology.The issue is observed because CFMD receives a configuration commit after the MX Series Virtual Chassis switch has occurred. This commit is deleting the cfmd session and then creating a new session, which is causing the old information of action-profile to be deleted, which in turn brings the interface back up. PR974663

  • Rate-limit value does not match between the Routing Engine and the Packet Forwarding Engine. PR1023809

  • Inactive telnet session does not time out automatically. PR1033972

  • On MX Series routers with MPCs/MICs, when the feature flow-control is disabled (enabled by default) by using the CLI command no-flow-control (for example, under the [gigether-options] hierarchy), after bringing up or rebooting the MPC, status of the hardware might not be updated correctly and the flow control on that MAC might remain enabled. PR1045052

  • Once the Traffic Offload Engine (TOE) thread is stalled due to a memory error at the lookup chip, all statistics collection from the interfaces hosted by the Packet Forwarding Engine are not updated anymore. PR1051076

  • In configurations with IRB interfaces, during times of interface deletion (for example, FPC reboot), the Packet Forwarding Engine might log errors stating nh_ucast_change:291Referenced l2ifl not found. This condition should be transient, with the system reconverging on the expected state. PR1054798

  • In an MX Series Virtual Chassis (MX-VC) scenario, there are two punt queues in the Virtual Chasis ingress host path: high and low. Currently, VCCPd packets, VCP heartbeat packets, various protocol hello packets, and TCP chassis control packets are directed to queue high. DDoS threshold for these queues defaults to 10K pps. If you deploy a large scaled route, during route change, the TCP control traffic increases. As a result, DDoS threshold is reached, leading to packets drop. Packets drop might lead to Virtual Chassis link outage. PR1058087

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

  • On MX Series routers with frame-relay (FR) CCC to connect FR passport devices , if any FR circuits carry traffic without valid FR encapsulations, the MX Series-based Packet Forwarding Engine drops those frames. PR1059992

  • In certain instances, invalid flow data gets exported on any MX Series router running. PR1068598

  • Juniper VSA length above 2K bytes is not supported. Using authorization parameters above this length would result in incorrect authorization setting for the user. PR1072356

  • On MX Series routers with MPC/MIC interfaces, when the firewall filters with prefixes are configured, a heap memory leak issue might be observed. PR1073911

  • When deleting some uncommitted configurations on the active Routing Engine, the rpd process on the backup Routing Engine might restart because of the following error: Unable to proceed with commit processing due to SIGHUP not received. Restarting to recover.PR1075089

  • On MX Series-based platforms, when learning the MAC address from the pseudo logical interface (IFL) (for example, label-switched interface), if the MAC address is aged out in the source FPC where the MAC was learned, due to the delay (2 to 3 milliseconds) in the processing of MAC address deleting message in the source FPC and the egress FPC (destination FPC of the traffic), the MAC address might be deleted first from the egress Packet Forwarding Engine but get added again during these 2-3 millisecond time intervals. Because there is continuous traffic coming on the egress FPC destined to this MAC, the MAC query is generated and sent to the Routing Engine and source FPC. Because the source FPC has not yet processed the MAC-deleted message, it sends the response, so a stale MAC will get added on the egress Packet Forwarding Engine. In this situation, no L2 flooding would occur for the "unknown" unicast becausethe MAC address is present on the egress Packet Forwarding Engine. PR1081881

  • In XM-based multi-LU systems (MX Series platform with MPC3E, MPC4E, MPC5E, MPC6E, NG-MPC3, NG-MPC2 or T4000 with T4000-FPC5-3D linecard), when you have multiple LUs representing the same Packet Forwarding Engine complex, and designate the BFD processing to a dedicated LU (LU 0), called as anchor LU, the rest of the LUs (LU 1, LU 2, and LU 3) are called non-anchor LUs. When the inline BFD packets punt from the non-anchor LU to the anchor LU, the interface-group is not populated in the packet context, so the packets might not be matched by the related filter term. PR1084586

  • Aggregated Ethernet interfaces in combination with shared-bandwith-policer might lead to Packet Forwarding Engine policer corruption if there are child member links configured on the same Packet Forwarding Engine and the aggregated Ethernet interface is being reconfigured (add/delete of logical units). This corruption could alter the policer rate programmed in hardware and lead to unexpected policer behavior. A different trigger with physical interface flap illustrating the same symptoms is tracked in PR1035845. PR1084912

  • Under large-scale setup, VPLS MAC might not be aged out from the remote Packet Forwarding Engine when the local Packet Forwarding Engine is MPC3, MPC4, MPC3E, or MPC4E, then unknown-unicast frames flood will be seen on the local Packet Forwarding Engine. PR1099253

  • The kernel next-hop acknowledgement timeout maximum interval configured (krt-nexthop-ack-timeout) under the CLI hierarchy routing-options forwarding-table has been increased to 400 seconds to avoid performance issues with scaled subscribers. PR1102346

  • The following fields have been added to v10 Sampling (IPFIX) template and data packets: - SAMPLING RATE





  • Improved VTY commands to show internal JNH memory usage. PR1103660

  • SNMP queries to retrieve jnxRpmResSumPercentLost will return the RPM/TWAMP probe loss percentage as an integer value, whereas the precise value (including decimal points) can be retrieved through the CLI by using the following commands: show services rpm probe-results and show services rpm twamp client probe-results PR1104897

  • When you configure one group with a configuration of routing instances and apply this group under the [routing-instances] hierarchy, then the rpd process will crash after executing deactivating/activating routing-instances commands. As a workaround, you can avoid using "apply-groups" under the [routing-instances] hierarchy. PR1109924

  • Applying auto-ttrace and next-hop-tracing on LMEM data errors can cause an XMCHIP DRD Command Sequence error, which can cause permanent impact on packet forwarding. There is no need to perform auto-ttrace and next-hop tracing upon LMEM parity error; because the memory is corrected, preventing DRD Command Sequence Error.. PR1157173

  • Internal fabric header corruption on Packet Forwarding Engines can lead to packet corruption on the egress Packet Forwarding Engine. This PR effort is to protect the fabric header coming to the egress Packet Forwarding Engine with a fabric CRC check. This is shown to avoid wedges due to corrupted fabric headers. PR1170527

  • The interfaces that are seen in default instance go missing from the routing instance under the logical system. You can verify that interface by using show interfaces terse routing-instance all or show route logical-system all. PR1206832

  • MX Series routers with MPCs/MICs-based line cards might crash after a firewall filter configuration change is committed. PR1220185

  • Due to transient hardware events, fabric stream might report CPQ1: Queue underrun indication - Queue <q#> continuously. For such events, all fabric traffic is queued for the Packet Forwarding Engine reporting the error, resulting in a high amount of fabric drops. PR1265385

Routing Protocols

  • When there is more then one tunnel PIC or tunnel interface on the system and after bringing down one active tunnel PIC, the pe/pd interfaces might fail to switch to another active interface in a scaled environment. PR717158

  • The multicast next hop show multicast nexthop shown for the master and backup Routing Engine for the same flow could be different if the next hop is hierarchy MCNH. During a nonstop active routing (NSR) switch, however, there is no traffic loss caused by this show difference. PR847586

  • When a Junos OS router with multicast enabled receives IGMP packets with protocol DVMRP (IGMP_PROTO_DVMRP) to the IGMP port is 0x5 (DVMRP_ASK_NEIGHBORS2), IGMP builds a neighbor list and responds to the source IP address of the sender. This source IP address can be a unicast address or a multicast address. There is no throttling of responses. The requests are answered at the highest rate possible. Secondary impacts are that the routing protocol daemon (rpd) IGMP utilization goes very high and the host path and interface network control queues can get congested. Refer to KB29553 for more information and mitigation. PR945215

  • On MX Series routers, when an instance type is changed from VPLS to EVPN, and in the same commit an interface is added to the EVPN instance, the newly added EVPN interface might not be able to come up. PR1016797

  • When configuring a router in RR mode (cluster-id or option B MP-eBGP peering), the advertise-external feature will not be applicable in local VRFs due to a different route selection/advertisement process (main bgp.l3vpn.0 vs VRF.inet.0). PR1023693

  • The multicast traffic might be pruned with a static IGMP join configuration upon receiving an IGMP leave group message when the interface is not a querier on the corresponding interface. PR1034270

  • The static/static access routes pointing to an unnumbered interface are getting added in the routing table even if the interface is down. In this case, if graceful Routing Engine switchover (GRES) is disabled, this type of route will never be added in the routing table after Routing Engine switchover. PR1064331

  • A BFD session configured with authentication of algorithm keyed-sha1 and keyed-md5 might flap occasionally due to FPC internal clock skew. PR1113744

  • Junos OS exhibits two different next-hop advertisement behaviors for MP_REACH_NLRI on a multi hop eBGP session, based on whether it is loopback peering or physical interface peering. When the routers are peering on their loopback, only the global IP of the interface (lo0) is advertised, whereas when the routers are peering through the physical interface, both global and link-local address are advertised as the next hops. PR1115097

  • When multiple addresses are configured on an interface, if the interface has interface-type p2p configured under OSPF and the router does not receive any OSPF packets from one of the IFAs, the OSPF state will not go down for the corresponding adjacency. It should have no impact on route learning, but it might cause confusion for troubleshooting, when peering with Cisco devices, which have multiple addresses configured as secondary addresses. PR1119685

  • 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

  • In a situation in which BGP is being used in combination with an interface's rfp-check, deleted routes might experience a delay in the propagation of BGP withdrawn messages. PR1135223

  • The log message: WARNING: no suitable primes in /etc/ssh/primes is generated when you log in to the router via SSH2 . These logs are generated every time you log in to the router via SSH2 using SecureCRT PR1146516

  • Generate route does not inherit the next hop from the contributing route in an L3VPN case in which the contributing route is learned via MP-BGP. The next hop remains as rejected for the generated route. PR1149970

  • In certain code versions, BGP trace options will have the Packet flag enabled with only the Open flag configured and will log every BGP packet. PR1175826

  • In some scenarios on Junos OS with OSPF and GRES/NSR, after a system routing restart, a race condition on the LSA synchronization between both Routing Engines can cause very high CPU usage on rpd on Master Routing Engine and constant rpd core files on the backup Routing Engine due to an unsynched OSPF LSDB state on the master Routing Engine. This state is replicated to the standby Routing Engine, causing the backup Routing Engine’s rpd to crash continuously. PR1195983

  • The following results are received when L1 is disabled for Lo0: {master}[edit] user@router# run show IS-IS interface IS-IS interface database: Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric lo0.0 3 0x1 Disabled Passive 0/0 Here are the results when L2 is disabled for Lo0: {master} user@router> show isis interface IS-IS interface database: Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric lo0.0 3 0x1 Passive Disabled 0/0 PR1202216

  • In a BGP scenario with the inet-mdt family configured under protocols BGP, the route table <NAME>.mdt.0 might get deleted if it has no routes. As a result, rpd might crash on the backup Routing Engine, and BGP sessions might flap on the master Routing Engine. PR1207988

  • When there are a large number of configured VPNs, routes changing in the midst of a bgp path-selection configuration change can sometimes lead to an rpd core file. This core file is generated with the removal of the always-compare-med option. PR1213131

  • In a next generation MVPN scenario with a PIM designated router (DR) and a backup designated router configured, when the designated router comes back after rebooting, it takes the designated router role back but does not create a PIM register state for some (S,G) routes due to the stale Type 5 route from the backup designated router. Traffic will be disrupted when the backup designated router withdraws the stale Type 5 route. PR1225726

  • The routing protocol process (rpd) on the backup Routing Engine might restart unexpectedly upon the addition of a new L2VPN routing instance. Following a major change in the configuration of an L2VPN routing instance (such as changing instance type on-the-fly, or routing instance rename), the routing instance and all its data structures get deleted or changed successfully on the master Routing Engine. On the backup, however, this might not get done, and therefore, the backup might still hold the routing instance with the original name (or original type), in addition to another newly created routing instance reflecting the configuration change. Due to this, one of the routing-instance parameters, the "sync-id" is freed on the master Routing Engine, but remains in use on the backup. Eventually, another routing instance gets added in an unrelated provisioning activity. If the sync-id that gets allocated for the new instance is the same as the one for the instance that was not properly deleted in the first change, then rpd on the backup Routing Engine will crash due to an assert, and then restart. PR1233514

  • If a router work as a graceful restart helper during a peering establishment, the newly established peer might lose some of the negotiated capabilities and might interpret the updates incorrectly. This can cause peer drops or invalid routes to be received. PR1293174

  • Multicast flow interruption might be observed on a transit router in a Protocol Independent Multicast (PIM) scenario, if (*,G) join is received on one interface, and (*,G) join and (S,G,RPT) prune are received on another interface, which then receives a (*,G) prune. Multicast flows on the first interface get reset and are interrupted for a short time (for example, 1 second). PR1293900

Services Applications

  • The LCP state for a tunneled subscriber is displayed incorrectly as "OPENED" (which reflects the LCP state before tunneling) by the CLI command show interfaces pp0.<unit> on the LAC. As a workaround, you can use the show ppp interface pp0.<unit> command to determine the correct LCP state for the subscriber. PR888478

  • When using clear services nat mappings to clear implicit dynamic mappings (created for NAPT44 with PCP at full scale) more than one time, SCHEDULER OINKER messages might be seen. These messages can be safely ignored. PR923166

  • For PPTP ALG, data session ports are cleared only on CTRL session destroy. Even though the data session expire, the ports are not freed PR927362

  • When you configure multiple proposals (under IKE and IPec configuration), the order in which proposals are configured, the preference are given in same order. For example, when a peer proposes multiple proposals, the first proposal that matches the configured proposal in the local device will be chosen instead of the strongest configured proposal. PR947773

  • In an L2TP scenario, when the L2TP network server (LNS) is flooded by high-rate L2TP messages from LAC, the CPU on the Routing Engine might become too busy to bring up new sessions. PR990081

  • With scaling Layer 2 Tunneling Protocol (L2TP) sessions (for example, 128K sessions), when executing theL2TP show command in one terminal and the clear command in another terminal simultaneously, pressing Ctrl-C or closing the terminal on one terminal might cause the jl2tpd process to crash. PR1063207

  • When a majority of L2TP subscribers log in with invalid credentials (75% of new login requests are invalid), low call setup rate (CSR) will be observed for the good login attempt subscribers. PR1079081

  • When polling to jnxNatSrcNumPortInuse through SNMP MIB get, information might not be displayed correctly. PR1100696

  • On MX Series platforms, when using MS-MPC or MS-MIC, the error message is filling var/log. Refer to KB30743 for details. PR1151945

  • When traffic is flowing through an MS-DPC card Service PIC and there is an active port block and some ports are assigned from that active port block, if the max-blocks-per-address setting is changed to a lower value (lower than the current value), the service line card might crash. PR1169314

  • In a Layer 2 Tunneling Protocol (L2TP) subscriber management environment, the jl2tpd process (L2TP daemon) might crash during cleanup and re-creation of L2TP tunnel or session continuously. PR1179261

  • When configuring Network Address Translation (NAT) service, the service route is still available in the route table even after the service is disabled. Any type of service interfaces (except ams- interface) that support NAT might be affected. PR1203147

Subscriber Access Management

  • On a BNG router, when the router is processing session "idle timeout", the following error message might be seen: ./../../../../src/junos/usr.sbin/authd/acc/ Failed to process the Idle Timeout for session-id:10. It should not affect any services. PR1041654

  • When using Neighbor Discovery Router Advertisement (NDRA) and DHCPv6 prefix delegation over PPPoE in the subscriber access network, if a local pool is used to allocate the NDRA prefix, when the CPE sends aDHCPv6 solicit message with both Internet Assigned Numbers Authority (IANA) and Identity Association Prefix Delegation (IAPD) options, the subscriber might an get IPv6 prefix from the NDRA pool but not the delegated pool. The CPE should send DHCPv6 solicit message with only IAPD option. PR1063889

  • In a subscriber management environment with a RADIUS server configured, when performing scaling subscribers login/logout, the device might stuck in RADIUS communication. PR1070468

  • In a subscriber management environment, when dual-stack service is activated by the Change of Authorization (CoA) request from the RADIUS Server, both families will be activated in the same profile response. The service accounting session ID is not generated properly and the service accounting messages and interim-updates are not sent out. PR1071093

  • In a large scaled DHCP subscribers environment (in this case, 110K DHCP users), the user executes logout and abort testing. In a rare condition, the DHCP subscribers get stuck in terminating state.

    - Logout testing: The traffic generator sends a DHCP Release message for a subscriber and the MX Series router deletes it from the DHCP relay table, sdb, and so on.

    - Abort testing: The traffic generator just drops the session and does not send a DHCP Release message. To the MX Series router, the DHCP subscriber is alive. PR1073541

  • On MX Series routers, when adding the LI-Action attribute for mirroring the traffic of dual-stack subscribers, due to the loop of the service requests lookup and adding, the authentication process (authd) CPU utilization might stay high indefinitely and traffic mirroring might not be occurring. PR1077940

User Interface and Configuration

  • In the J-Web interface, when you select Configure > Routing> OSPF> Add, and then click the Interface tab, you see only the following three interfaces by default: pfh-0/0/0.16383, lo0.0, and lo0.16385. As a workaround to this issue and to configure the desired interfaces to the associated OSPF area-range, set the following statements from the CLI: set protocols ospf area area-range set protocols ospf area interface fe-0/3/1. PR814171

  • On HTTPS service, J-Web is not launching the chassis viewer page on Internet Explorer 7. PR819717

  • In J-Web, on the Configure > Cli tools > Point and click > System > Advanced > Deletion of saved core page, the No option is not available. PR888714

  • Basic value entry format error check is not present at Configure >Security >IPv6 Firewall Filters, but the error check is present on the IPv4 Firewall Filters page. However, it will throw an error when trying to commit the wrong format data entered. PR1009173

  • When entering the restart r incomplete command in the CLI, the command restart routing is executed. It should throw an error: error: invalid daemon: r. PR1075746


  • BGP community 0xFF04 (65284) is a well-known community (NOPEER), but it is incorrectly displayed as mvpn-mcast-rpt in the CLI command show route. This is a show command issue only. No operational problems will be observed on the router or network. PR479156

  • In next-generation MVPN spt-only mode with a PE router acting as the rendezvous point (RP), if there are only local receivers, the unnecessary multicast traffic continuously goes to this RP and drops even though it is not in the shortest-path tree (SPT) path from source to receiver. PR1087948

  • In a dual Routing Engines scenario with NSR enabled, when L2Circuit/L2VPN/VPLS is enabled, due to race conditions in the different messages and events between master and backup Routing Engines, if label-reuse occurs in the master Routing Engine rpd, the backup Routing Engine rpd might handle messages and events unsuccessfully and crash. There is no functional impact. PR1119684