Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Junos OS Release Notes: MX Series 5G Universal Routing Platforms


Review information specific to running Junos OS Release 18.2X75-D410 on the MX Series.

What’s New

Learn about new features introduced in this release for MX Series routers.

Routing Protocols

  • IPv4/IPv6 in IPv4 unicast tunneling (MX Series)— Starting in Release 18.2X75D410, Junos OS supports next-hop based tunneling with IPinIP encapsulation to allow for IP based tunneling in a WAN network. IP over IP overlay encapsulation using nexthop-based tunnel is required to allow IPv4 and IPv6 unicast forwarding across some transit devices that do not support MPLS tunnelling. Hence to support scaling, edge devices must have the capability to route traffic into and out of the tunnel without throughput reduction.

What’s Changed

There are no changes in default behavior and syntax for PTX Series routers in Junos OS Release 18.2x75-D410.

Known Limitations

Learn about known limitations in this release for MX Series routers. For the most complete and latest information about known Junos OS defects, use the Juniper Networks online Junos Problem Report Search application.

General Routing

  • please reach out to the DE for release notes PR1312047

  • Hardware watchdog does not work on QFX10008 and QFX10002-60C/PTX10002-60C. PR1343131

  • On a PTX1000 router, after the system is rebooted by issuing the request vmhost reboot command, the netproxy service might fail to start. PR1365664

  • new stanza to prevent an FPC having hw issue from periodic bouncing PR1393643

  • Could not copy files from router to FTP server when the route to reach the server is stored under mgmt_junos routing instance. PR1412033

  • The dfe tuning failing at times is a known issue on Summit, the only recovery option in this situation is to restart the FPC. PR1413233

  • In the following scenario Device 1 Remote Device summit-mx1ru-h <----------------> summit-mx3ru-i et-0/0/2 et-1/0/1 If PRBS is started on simultaneously as TX and RX on both the devices, there will be errors seen at remote device because when PRBS is started as TX on remote device, it attempts to dfe tune the line again but PRBS is already running as RX which causes the error. So first start As Tx on Device 1 and as Rx on Remote device, then stop the test on both the ends and start as TX on remote device and as Rx on Device 1. PR1416124

  • In the current scenario the ifinfo command "show interface et-0/0/3 prbs-stats" queries the pfe and displays the stats, therefore whenever the stats are being cleared, and then ifinfo command is queried, every time it fetches fresh stats so it seems that clear statistics is ineffective. This behaviour will be fixed as an added feature in 19.2 DCB release. PR1418495

  • Since creating the loopback at the MacSec port (remote end) in this specific situation, the link itself is down at the EA port hence PRBS test fails with incrementing error counts. PR1421432


  • When atleast one name-server is configured to be reached through mgmt_junos routing instance, all the configured name-servers will be tried to be reached with mgmt_junos routing instance first and then all the name-servers are iterated with default routing instance (inet.0), until DNS is resolved. With each routing-instance, order of name-servers attempted to reach is based on configuration. By default, a few datagram packets are sent to all the configured name-servers through mgmt_junos, before moving on to try with default routing-instance. So to failover to default routing instance, it might take around 4 mins. Example: Config: name-server A routing-instance mgmt_junos; name-server B; Order attempted to reach name-servers, until success : 1) Try A through mgmt_junos 2) Try B through mgmt_junos 3) Try A through inet.0 --> ~4 mins to get to this. 4) Try B through inet.0 Recommendation: If management-instance is configured, configure all the name-servers through mgmt_junos. PR1372582

Interfaces and Chassis

  • The same IP address could be configured on different logical interfaces from different physical interfaces in the same routing instance (including master routing instance), but only one logical interface was assigned with the identical address after commit. There was no warning during the commit, only syslog messages indicating incorrect configuration. PR1221993

Platform and Infrastructure

  • On all JunOS platforms, execution of Python scripts through enhanced automation does not work on veriexec images. PR1334425

  • after reboot first several packets loss might happen if the traffic passes through an FT interface. PR1431983

Open Issues

Learn about open issues in this release for MX Series routers. For the most complete and latest information about known Junos OS defects, use the Juniper Networks online Junos Problem Report Search application.


  • In EVPN Multihoming scenario, if the MTU of CE facing interface on PE (i.e., configured with ESI, 'set interfaces ae0 unit 1 esi 00:11:22:33:44:55:66:77:88:99') is changed, the MAC addresses learned from remote PE might be deleted and not added back, resulting in EVPN traffic loss. PR1382966

Forwarding and Sampling

  • This PR is to fix some hints for the cli commands to avoid confusion. With the fix, it will be like this: {master}[edit] labroot@beltway-re1# set firewall flexible-match source-ipv6-match bit-length ? Possible completions: <bit-length> Length of integer input (1..32 bits), Optional length of string input (1..128 bits) <<<< added information that for integer the limit is 32bit {master}[edit] labroot@beltway-re1# set firewall flexible-match source-ipv6-match bit-length 120 {master}[edit] labroot@beltway-re1# commit check re1: commit-check failed commit-check failed error: configuration check-out failed <<<<<< for range, added the syntax check that no "," "or" is supported. {master}[edit] labroot@beltway-re1# set firewall family inet6 filter flex-match-v6 term source-ipv6 from flexible-match-range range 0x00000001-0x00010001, 0x00010001-0x00010070 ^ syntax error. {master}[edit] labroot@beltway-re1# set firewall family inet6 filter flex-match-v6 term source-ipv6 from flexible-match-range range 0x00000001-0x00010001 ? Possible completions: <[Enter]> Execute this command + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups bit-length Length of the data to be matched in bits (1..32) bit-offset Bit offset after the (match-start + byte) offset (0..7) byte-offset Byte offset after the match start point flexible-range-name Select a flexible match from predefined template field match-start Start point to match in packet | Pipe through a command {master}[edit] labroot@beltway-re1# set firewall family inet6 filter flex-match-v6 term source-ipv6 from flexible-match-range range 0x00000001-0x00010001 or ^ syntax error. PR1389103

General Routing

  • "Pred Fail" Fan Tray chassis alarm was renamed to "Predicted Fail" to avoid any possible confusion. PR1202724

  • On yankout of MPC, Link Error column in show chassis fabric summary extended output shows YES for all fabric planes. Whereas, on offline of MPC using the CLI command, output shows correctly. PR1214611

  • This issue has not been addressed, and it?s probably not easy to address either. The problem is, when some route/NH has been created by the app, it?s assumed that it can propagate to the rest of the system. KRT asynchronously picks up this state for propagation. There’s no reverse indication to the app, if there was an error in propagating the state. The system is supposed to eventually reconcile. So, if SPRING-TE produces a <route, NH> pair that looks legal from the app standpoint, but KRT is not able to download it to the kernel, because kernel rejected the NH, the <route, NH> sort of gets stuck in RPD. In the meantime, the previous version of the route (L-ISIS in this case) that was downloaded still lingers in the kernel & PFE. PR1253778

  • Due to vendor code limitation, ungraceful removing of summit MACsec TIC from chassis might cause a crash or unpredictable result. PR1284040

  • "show dynamic-tunnels database summary" would not show accurate tunnels summary during the time anchor PFE linecard is not in up state. Use below commands as a work around: ?show dynamic-tunnels database? and ?show dynamic-tunnels database terse? PR1314763

  • This RLI 36068 was done to target Oracle use case. Oracle does not use chain-composite. This knob does nor bring in a lot of gain since TCNH is based on ingress rewrite premise. Without this knob things work just fine. PR1318984

  • When two nexthops are installed and they have the same Next hop index in kernel, an rpd crash on the master RE might happen. PR1322535

  • When cmerror disables pfe, it does not power off the ea and hmc chips. The periodic continues monitoring the temp on hmc and other devices. If the temp is overheated, the system can take proper actions, such as increase the fan speed or shutdown the systems. The periodic calls hmc_eri_config_access() to get temp readings. It is expected to get ERI timeout continuously in this case. PR1324070

  • During ISSU that warrants host upgrade, if the router is configured with 8 million v4/v6 routes or more, the ISSU may fail resulting in FPC restart. PR1348825

  • Chassisd crash observed in mx10003 during restarting chassisd. PR1354269

  • If the packets are destined to specific MAC address (such as last two octets are 0x1101, 0x1102, 0x1103, 0x1104, 0x1106, 0x1108, 0x1109, 0x110a and so on), they might be dropped on the remote-end device when going through MX104 built-in xe(10GE) ports. PR1356657

  • When MX platform is used for External Node Slicing for Enhanced Subscriber Management functionality, the both sets of links (master and backup) between the external x86 server and the BSYS go down, bbe-smgd process might stuck. PR1357252

  • For 18.2R1 "show chassis ethernet-switch" output on MX-TVP platforms is different from legacy platform Following fields are not displayed, Speed, Duplex, Autonegotiation, Flow-Control PR1358853

  • Certain CLI functions not triggering properly, due to missing libraries on the router. Affected commands include: set security ssh-known-hosts load-key-file set system master-password PR1363475

  • On MX2010/MX2020 routers equipped with SFB2 (Switch Fabric Board 2), some error messages could be occasionally seen in the logs. There is no operational impact nor an indication of a real issue caused by these messages. PR1363587

  • Traffic will dropp on PFE as "invalid L2 token" when protocol changes from VPLS to EVPN. PR1368802

  • PEM to zone mapping exported in jvision streaming has no reference to the parent zone for the J-vision data. PR1372374

  • In CoS scenario, if PS interface uses RLT as PS anchor, all traffic might be dropped on PS interface when deactivating or activating rewrite rules. PR1379530

  • In subscriber scenario, if the"service-accounting-deferred" is configured on dynamic-profile, and there is multicast to a large number of destinations on the same physical port, the FPC Errors might be seen. PR1380566

  • sflow between MX and PTX families. Oif in sflow egress sampling using IFD SNMP ifIndex instead of ae SNMP ifIndex PR1381462

  • On all Junos with Trio platforms, the unicast traffic might get dropped when it is passed from an Integrated Routing and Bridging (IRB) interface towards label switch interface (LSI) if the Aggregation Ethernet (AE) load balancing adaptive or per-packet is configured. PR1381580

  • Uninitialized EDMEM[0x400094] Read (0x6db6db6d6db6db6d) logs may be seen with sampling applied to a subscriber with routing-service applied PR1386948

  • If IP or MAC quickly move from one router to another router in a highly scaled EVPN-VXLAN environment, such as 1000+ simultaneous VMs mobility events where the VMs move to a new leaf switch and the VM MAC addresses are also changed, L3 gateway did not update ARP entries with new location of the VM and MAC. PR1395685

  • IRB (Integrated Routing and Bridging) is not supported for PS (Pseudowire Subscriber) interface. When a PS interface along with IRB in the same bridge-domain is committed, kernel might crash and reboot continuously. The fix of this PR adds commit check to prevent adding IRB to bridge-domain with PS interface. PR1396772

  • The JUNOS RPD daemon has facilities to attempt to trap certain classes of non-fatal bugs by continuing to run, but leaving a "soft" core file. Leaving a soft core is intended to be non-disruptive to routing and forwarding. This PR implements a mechanism by which users may disable soft cores being generated. PR1396935

  • Core and RPD reboot will be seen when condition-manger policy is configured for routing table xxx and the same table is repeatedly deleted+readded. Not fixed in 19.2R1, will be fixed in 19.2R2. PR1401396

  • In a BBE deployment where the RPF and MAC check is enabled, a race condition can cause software failure resulted in a FPC to restart. PR1401808

  • Configuration database can remain locked after the ssh session is halted. PR1410322

  • 1). Only in the case that all the below conditions are met, the telemetry statistics will not account correctly for the traffic on SRTE-policies(both byte count and packet count), on PTX platforms, only: a. SRTE policy is uncolored(color attribute is not enabled for the SRTE policy) b. protocols isis source-packet-routing sensor-based-stats per-interface-per-member-link configuration is enabled. c. The outgoing interface for the SRTE route is an aggregated interface (for eg. ae) Thanks and Regards, Bharath R. PR1413680

  • On MX10003 while upgrading from one JUNOS to another sometimes this causes REs to loss communication together. The symptoms are that both REs will be up but see the other as present, this mostly seen during upgrade process. The issue is due to change in mapping Where in newer versions Linux interface mapping has been changed and VLANs has been added, thus communication is broken between changed and non-changed versions. Upgrading between JUNOS that doesn't have the fix and one have the fix will trigger this issue. PR1414183

  • Changing CAK & CKN multiple times within shorter interval (~5 min) sometimes "show security macsec connection"'s inbound & outbound channel display more than one AN active. But in PFE HW side correct AN & SAK is programmed and MKA protocol from both end transmit correct & latest AN on each hello packets. User should not see any traffic drop due to this display issue. PR1418448

  • certain JNP10008-SF and JNP10016-SF manufactured between July 2018 to March 2019 may have incorrect core voltage setting. The issue can be corrected by re-programmed the core voltage and updated the setting in nvram memory. PR1420864

  • In the ECMP (Equal-Cost Multipath) environment with existing multipath for a given route, changing configuration (e.g. delete routing protocol IGP or LSP) is trying to delete a software structure which was already corrupted sometime earlier due to memory corruption, and this may cause the rpd to keep crashing. PR1424819

  • In gRIBI, programmed routes references a nexthopgroup ID which in turn points to one or more nexthopID. Each NexthopID contains details of the actual nexthop. NexthopGroupID and nexthopID are mapped to a IPv6 prefix (e.g FC01:: <GRP ID or NHOP ID>. In the case of IPv4 indirect nexthop, gRIBI needs to resolve IPv6 via IPv4 nexthop over 3 levels of indirection. Junos doesn't support IPv6 over IPv4 multi level nexthop resolution. Therefore gRIBI cannot resolve nexthopGRPID <FC01::grpid> nexthop ID <FC01::nhopid> via actual indirect IPv4 gateway address. This is a limitation in Junos. PR1434050

  • Some non-Juniper 40G SFPs may utilize 100G QSFP28 marking in their EEPROM indicating CDR bypass mode, which enables the use of 100G optics at 40G speeds. On some 40G line cards, JunOS detects an incorrect pluggable qsfp28 of type 0x11 (17 decimal) inserted into a qsfp+ of type 0x0d in the cage and reports this error to syslog. PR1434183

  • This issue is addressed by PR 1434037. PR 1434037 is only fixed for 19.4DCB. For all other releases, it will need further efforts to back port relevant features first. Therefore 18.2X75-D50 and 18.2X75-D60 scope need to close now. PR1435286

  • Egress stream flush failure and traffic blackhole could occur on a rare occasion for a repeatedly flapping link on MPC7/8/9E cards. PR1441816

  • jsd process 100% is hit when 32k inetcolor and 32k inet6color are programmed together PR1452464

High Availability (HA) and Resiliency

  • The following error is seen during early ISSU validation phase: "error: not enough space in /var on re1". As a workaround, make sure that the space available in "/var" is twice the size of the target image. This is the basic requirement for unified ISSU to proceed. PR1354069


  • The following messages are seen during FTP: "ftpd[14105]: bl_init: connect failed for `/var/run/blacklistd.sock' (No such file or directory)" messages are seen during FTP. PR1315605

  • This is a BIOS firmware issue and does not seem to impact any functionality. All systems running BIOS version earlier than 1.1 are reporting a warning message. As a workaround, upgrade the BIOS firmware on the devices. You can check for the firmware version on the device by querying the sysctl It should be later than 1.1 for this warning to be resolved. PR1345166

  • To test features like NSR, the junos-panic package can be installed, and /usr/libexec/panic can be run by root. PR1352217

Interfaces and Chassis

  • 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

  • Upgrading Junos OS Release 14.2R5 and later maintenance releases and Junos OS Release 16.1 and later mainline releases with CFM configuration might cause the cfmd process to crash after upgrade. This is because of the old version of "/var/db/cfm.db". PR1281073

  • Post GRES 1GE changes to 10GE PR1326316

  • When a maintenance association end point (MEP) is configured on a CCC-encapsulated interface, and the route to the remote MEP is resolved over an aggregated ethernet interface for the next-hop while the 'LAG Enhanced' feature is disabled, the inline packets may be programmed incorrectly. This mis-programming results in the inline connectivity fault management (CFM) session being incorrectly programmed, if some scripts running based on CFM status, it may affect data traffic. PR1417707

  • If aggregated interface(ae) has vrrp configuration, in following use cases, member ifls will not be created after member ifd comes up and ae will be in down state. 1. fpc restart (request chassis fpc restart slot <>) 2. chassis-control restart (restart chassis-control) 3. reboot both RE (request system reboot both-routing-engines) So before performing above operations, it is advisable to remove vrrp configuration from aggregated interface(ae) PR1429045

  • If VRRP group has preemption configured and corresponding logical interface has been disabled/deactivated and re-enabled/re-activated some time after, the VRRP process may crash at the moment of changing mastership for that group. PR1429906

Layer 2 Ethernet Services

  • This is in an internal change as Syslog usage is deprecated, however, there may be customer impact due to syslog usage in automation. Applications have migrated to tracing for engineering debug messages or ERRMSG for customer useful/relevant messages. The customer is advised to migrate to new ERRMSG definitions as appropriate PR1284592

  • In un-authenticated DHCP scenario (i.e., no authentication mechanism such as radius), there is no DHCP option 1 (subnet mask) in DHCPACK as the reply to a DHCPINFORM message. Hence the DHCP client can't get subnet mask in this INFORM and ACK way defined in RFC 2131. As a result, the client can't access the network. For example, if the MAC OS DHCP client configures the option "Using DHCP with manual address", the DHCPINFORM message is sent and no subnet mask is replied accordingly. PR1357291

  • If MX is running as a DHCP (Dynamic Host Configuration Protocol) server and DHCP leasequery is used, when DHCP leasequery message is received from the DHCP relay agent, MX replies it with the incorrect source address. The issue will not result in leasequery failure. However, it might lead to some unexpected issue related to the source address (e.g. impact filter base on the source address). PR1367485

  • On MX platform, if static demux interface over underlying is configured, after subscriber logout, the accounting statistics are not cleared. PR1383265


  • In a CE-CE setup, traffic loss might be observed over the secondary LSP on primary failover. PR1240892

  • If the primary link goes down immediately after bypass (say FPC containing both primary & bypass or, both primary & bypass FPCs go down simultaneously) such that primary link goes down even before the PLR sends out any Path message after bypass down, then the nodes downstream of the PLR along the LSP path will be left with stale LSP state until refresh timeout. This condition will not result in any traffic loss. PR1242558

  • With nonstop active routing (NSR), when the routing protocol process (rpd) restarts on the master Routing Engine, the rpd on the backup Routing Engine might restart. PR1282369

  • In case of CSPF-disabled LSPs, if the primary path ERO is changed to an unreachable strict hop, sometimes the primary path stays up with the old ERO. The LSP does not switch to standby secondary. PR1284138

  • For static short reach traffic engineering (SR-TE), the binding SID entry disappears after modifying binding(swapping) SID values for two SR-TE LSPs. Workaround is to delete the BSID->P1 and create BSID->P2. PR1289950

  • Executing a "restart chassisd" in a router with scaled configuration might result in rpd core. The BGP I/O thread added a soft-assert if the socket write/socket read system call returns EINVAL in order to allow investigation if the parameters passed to the system call have any issues. It appears there are scenarios where the socket write/socket read system calls return EINVAL even though the parameters are good. PR1352227

  • With NSR enabled, when master RPD is restarted, occasionally, out-of-order add and delete messages can arrive on the backup RE causing label assignment collisions leading backup RPD to crash. PR1401813

Platform and Infrastructure

  • The "Disconnected after ISSU and before switchover" error might be seen and FPC is restarted during ISSU. PR1364514

  • On MX platform, if the packet is encapsulated twice and the packet header is over 252 bytes, the packet will be dropped. PR1385585

  • Support for MAP-E encapsulation and decapsulation on Inline-service interface (MX2010) - Mx routers support MAP-E encapsulation and decapsulation on the following ICMP message types on Inline-service interface: - Time Exceeded (type 11) - Destination unreachable (type 3) - Source quench (type 4) - Parameter problem (type 12) - Address mask request/reply (type 17/18) - Redirect (type 5) PR1404239

  • On MX Series with MPC, if an AE interface is with the filter of 'shared-bandwidth-policer' and the knob 'shared-bandwidth-policer' is deactivated, after activating the knob 'shared-bandwidth-policer', the policer bandwidth might be calculated as 0 and all traffic might be dropped for the AE interface. PR1427936

  • In a Mapping of Address and Port with Encapsulation scenario (MAP-E, which can be considered as IPv4 traffic from a pure IPv4 network, which travels through a pure IPv6 network to another IPv4 network), those packets which have pre-fragmented ICMP IPv4 inside of IPv6 might fail to successfully arrive at the destination, due to the fact that MAP-E device at the ISP side cannot handle this sort of packets. PR1432506

  • When BR device transits over sized packet greater than router configured mtu-v6 parameter, BR should return ICMP Type 3 Code 4. PR1435362

Routing Protocols

  • JTASK_SCHED_SLIP for rpd may be seen on doing restart routing or ospf protocol disable with scaled bgp routes in MX104 router PR1203979

  • With BGP ORR (optimal-route-reflection) configured, if IS-IS LSP has more than one fragment and the LSP is purged (for example, a topology change after a link flap), then an rpd crash might be seen. PR1235504

  • Certain BGP traceoption flags (for example, "open", "update", and "keepalive") might result in (trace) logging of debugging messages that do not fall within the specified traceoption category, which results in some unwanted BGP debug messages being logged to the BGP traceoption file. PR1252294

  • LDP OSPF are 'in sync' state and the reason observed for this is "IGP interface down" with ldp-synchronization enabled for OSPF. user@host> show ospf interface ae100.0 extensive Interface State Area DR ID BDR ID Nbrs ae100.0 PtToPt 1 Type: P2P, Address:, Mask:, MTU: 9100, Cost: 1050 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 2, Not Stub Auth type: MD5, Active key ID: 1, Start time: 1970 Jan 1 00:00:00 UTC Protection type: None Topology default (ID 0) -> Cost: 1050 LDP sync state: in sync, for: 00:04:03, reason: IGP interface down config holdtime: infinity As per the current analysis, "IGP interface down" is observed as the reason because although LDP notified OSPF that LDP synchronization was achieved, OSPF was not able to take note of the LDP synchronization notification, because the OSPF neighbor was not up yet. The issue is under investigation. PR1256434

  • This is in an internal change as Syslog usage is deprecated, however, there may be customer impact due to syslog usage in automation. Applications have migrated to tracing for engineering debug messages or ERRMSG for customer useful/relevant messages. The customer is advised to migrate to new ERRMSG definitions as appropriate PR1284621

  • When eBGP multihop sessions exchanging EVPN routes are configured, a core can result due to an internal error. PR1304639

  • There are scenario where application allocates and caches nexthop templates. This causes NH template cache to grow continuously. But when application clears their local cache, then memory is freed to NH template cache. But the NH template cache does not have code to shrink the cache and free memory back. So the NH template memory is trapped in the cache and cannot be used for other purposes. But if same BGP routes and nexthops come up again, they will reuse the templates from cache and not consume additional memory. PR1346984

  • In EVPN+VXLAN scenario, if proxy-macip-advertisement is configured on IRB (Integrated Routing and Bridging) interface for the EVPN (Ethernet VPN), the BGP sessions might flap on backup RE even the system is shown ready for the hitless switchover, hence there might be traffic loss after GRES switchover if BGP sessions are down on backup RE at the time of GRES switchover. PR1387720

  • Rpd's route selection mechanism has multiple user-configurable mechanisms by which route ordering may be changed. To assist with debugging issues with defects in the route selection code, a function would generate a low priority soft core that didn't crash rpd when route selection was incorrect. However, there have been circumstances wherein not-best was incorrectly being determined. One such situation that is addressed in this PR involves when routes are learned or redistributed from non-BGP protocols and had an AS_PATH attribute. Using BGP route selection rules, if a BGP route and a non-BGP route had a leading AS_PATH with the same AS, BGP MED selection rules for grouping were being applied. Such MED election should only be done using BGP-only routes. Such a situation can come from various BGP carried VPN protocols wherein routes from the VPN protocol generated IPv4 routes when redistributed from one routing instance to another. An example of this would be an EVPN route. PR1391767

  • Policy based label allocation is not supported for IPV6 prefix. Commit may be successful but configuration will not take effect. There is no functional impact. PR1395040

  • Memory leak of around 300k happens under the following circumstances and when around 2000 flow-spec routes were distributed 1. remote-operations daemon is running (connect/disconnect of this daemon is causing a memory leak and has no relation with this RLI). PR submitter will file a new PR to track this issue. 2. a) Full BGP configuration is flapped (only in 18.4) (Deactivate & activate) Full BGP configuration flap means doing delete protocols bgp and set protocols bgp. The issue does not happen if only routes are flap. Full configuration flap is not usually done in a production network as it will reset all BGP routes & routing table contents in the DUT. This is expected in the maintenance window. Hence chances to hit this trigger is less likely in customer deployment. b) This issue is not seen after configuring the below workaround in 18.2X75D30 & 18.2X75 throttle. Scope for this PR has been closed for X75 branch. PR1401914

  • In a scenario with ISIS running single spf (shortest-path-first) for IPv4 and IPv6, i.e. the multi-topology is not enabled, when a new ISIS link comes up, IFA (interface address) for IPv4 comes up quickly and the route is installed, but IFA for IPv6 is not up quickly due to DAD (Duplicate Address Detection) is enabled by default. Therefore, after spf calculation, the next-hop list for IPv6 remains empty for about 11 seconds, so, ISIS ends up with deleting the route. PR1430581

  • In certain scenarios, although traffic flows correctly over 6PE tunnels with correct encapsulation, the tunnel statistics do not increment correctly. This is because we are not ignoring the 6PE label correctly in these scenarios. This is not fixed in D410 and has been fixed in D420 along with the knob for ignoring the 6PE knob. PR1450256


  • The L2circuit or the CE-facing interface might flap repeatedly and cause the packets to be dropped if the configuration "asynchronous-notification" is configured on the PE. PR1282875

  • In a dual-RE setup and running release starts from 17.2 onwards, if hot-standby is configured for l2circuit or VPLS backup-neighbor and NSR is enabled, the rpd might continuously crash on the backup RE which might lead to high CPU and then some protocols might flap on the master RE. PR1340474

  • In draft-rosen MVPN scenario with data-mdt, if performing the CLI command "show pim mdt data-mdt-limit instance <instance_name> <family>", The output might go in loop and the rpd process might use high CPU. PR1405887

Resolved Issues

Learn which issues were resolved in this release for MX Series routers. For the most complete and latest information about known Junos OS defects, use the Juniper Networks online Junos Problem Report Search application.

Forwarding and Sampling

  • If "service-filter" is configured, the device might be in Amnesiac mode after executing ISSU and error message "mgd: error: configuration check-out failed" might be seen. PR1432664


  • LDP route metric might not match IGP route metric even with "ldp track-igp-metric" configured. PR1422645

  • On MX/PTX series platforms acting as a transit router, if the "set protocol mpls sensor-based-stats" and "ldp-tunneling" are used and when an LSP is added or changed, part of its data structure might not be freed which might cause the resources to be exhausted. Once the resource is exhausted, the kernel routing table (KRT) queue will be built-up and new routes cannot be programmed in the forwarding engine, in the end, the transit packets might be lost. PR1447170

Platform and Infrastructure

  • On MX/T4000/EX9200/SRX5000 platforms, when Generic Routing Encapsulation (GRE) tunnel is configured and terminated in a routing-instance, if the routing-instance name contains dots (e.g. Example-x.x.x.x), and a firewall filter which doesn't decapsulate GRE packets is applied in the forwarding-options hierarchy, all the GRE traffic might get dropped due to this issue. It's a race condition. PR1437872

Routing Protocols

  • After the OSPF neighbor router reboot, the route received from the neighbor router via OSPF might flap during the router recovery. When this occurs, out of order packets and traffic loss might be seen. PR1348031

  • As a part of a new parallel delete of routes received from a BGP peer when the peer goes down, routes that was not received again will be deleted very slowly. The system will converge and work, but stale routes will be present longer than otherwise expected PR1435466

  • On all Junos platforms with GRES and NSR enabled, if clear BGP sessions on the master RE, the counterpart of backup RE might go out of syncronizing. Traffic loss might be seen before complete the convergence if GRES has happened. PR1439620

  • When the BGP protocol is removed it's possible for the backup RE to crash during cleanup PR1457358