Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

17.4R1-S6: Software Release Notification for Junos Software Service Release version 17.4R1-S6



Article ID: TSB17532 TECHNICAL_BULLETINS Last Updated: 12 Mar 2019Version: 3.0
Alert Type:
SRN - Software Release Notification
Product Affected:
ACX, EX, MX, PTX, QFX, VMX, VRR, Network Agent, NFX250
Alert Description:
Junos Software Service Release version is now available for download from the Junos software download site
Download Junos Software Service Release:
  1. Go to Junos Platforms - Download Software page
  2. Input your product in the "Find a Product" search box
  3. From the Type/OS drop-down menu, select Junos SR
  4. From the Version drop-down menu, select your version
  5. Click the Software tab
  6. Select the Install Package as need and follow the prompts

Junos Software service Release version 17.4R1-S6 is now available.

NOTE: Due to PR1331299 - PTX-series software images have been re-issues as 17.4R1-S6.2. Customers who downloaded PTX software prior to March 11th, 2019 needs to download the current PTX software identified by 17.4R1-S6.2 - See TSB17535

The following are incremental changes in 17.4R1-S6.

PR Number Synopsis Description

The enhancement of reporting total SBE errors when the corrected singlebit errors threshold of 32 is exceeded for MPC7E/MPC8E/MPC9E.

For MPC7E/MPC8E/MPC9E on MX platform, there is an enhancement to increase the threshold of corrected single-bit error from 32 to 1024 and change the alarm severity from Major to Minor for those error messages. There is no operational impact upon corrected single bit errors. 


Autonegotiation not working as expected Between ex4300 and SRX5800

Auto-negotiation (TRI SPEED 10/100) not working as expected Between mixed VCF ex4300 to other devices 


The rpd process might crash after deactivating the passive interface under ISIS

In Intermediate System to Intermediate System (ISIS) network scenario with the knob "topologies ipv4-multicast" configured, if passive and Traffic Engineering (TE) are enabled for ISIS interface level, the rpd might crash after deactivating the passive interface. 


ISIS adjacency fails to establish because of packets drop on PFE

On Junos platforms with Trio-based line cards, when disabling an AE (Aggregated Ethernet) interface and deactivating micro BFD session on the AE interface, and then enabling the AE interface up again, ISIS adjacency fails to establish (even though the AE and all its child interfaces are up). 


The rpd might crash on backup RE due to memory exhaustion

When there is an error during creation of the RSVP Path state (the PSB data structure), the data structure itself is freed but some associated memory is not freed. This is causing a memory leak. It is very unlikely that this error condition ever happens on a NSR primary RE (or when no NSR is configured). But on the NSR backup RE, there are more likely to be conditions that cause the Path state creation to fail, thus exposing the memory leak in the error handling code. Thus this memory leak was seen on the NSR backup RE. The fix went to address mitigation of memory leak due to RSVP_HOP object in this PR. 


PTX-Series: Invalid programming of interfaces during PFE initialization may lead to traffic black hole.

While a PTX-platform performs Packet Forwarding Engine (PFE) initialization, the PFE may not initialize interfaces data structure properly. This causes transit traffic drop while traffic egressing out of those interfaces. The problem is applicable only to PTX1000 ,PTX3000,PTX5000 and PTX10000. 


The IPsec rule might not work if both IPv4 ANY-ANY term and IPv6 ANY-ANY term are configured for it

When IPsec service is configured on MS-MPC/MS-MIC, the IPsec rule might not work if both IPv4 ANY-ANY term and IPv6 ANY-ANY term are configured for it. This is because of rule matching without type check. It is a day-1 issue. 


The bbe-smgd process might crash after commiting dynamic-profiles with "fast-synchronize" enabled

In subscriber environment, if commit option "fast-synchronize" is configured, the bbe-smgd process might crash in a rare condition when commiting the configuration changes related to dynamic-profiles. 


The rpd might crash when the dynamic-tunnels next-hop resolving migrates to a more specific IGP route

On MX-Series platforms, if the dynamic-tunnels is configured and the tunnel endpoint (BGP next-hop) is resolved in inet.0 table against a IGP route, and later the tunnel next-hop resolving migrates to a more specific IGP route in inet.0, rpd might crash and rpd scheduler slip could also be seen. 


IPsec tunnels might flap when SNMP walk is executed if IPsec is configured with DPD enabled

If IPsec is configured (even at a low scale of 200 tunnels) with Dead peer detection (DPD) en abled and all the IPsec tunnels are IDLE, when SNMP walk is performed, IPsec tunnels might flap. 


The rpd scheduler slip might be seen when frequently deleting/modifying/adding groups which are applied on top level

If groups are applied on top level, when these groups are deleted/modified/added, all the top level hierarchies which are referred by these groups will be set with "mark-changed" bit. Everything under these hierarchies will be considered as changed. If these groups refer to policy-options and there are policies referring to prefix-list, each prefix in prefix-list will be marked as 'changed' even though the prefix-list is actually not changed at all. This will cause the duplicate prefix to be added to prefix-list. When the groups adding/modifying/deleting operation is frequently executed, the issue will cause more CPU occupation by policy processing, and then might cause the rpd scheduler slip. 


The MS-MPC might reset continuously on MX platform

On MX platform with MS-MPC installed, the PIC might reset continuously for MS-MPC due to this issue, which will lead to core file generated as well. 


The routing-table (RIB) and the forwarding-table (FIB) might go out of sync in the multipath scenario post the route flap in high scale scenarios

In case of ECMP scenario, there is a possibility of the route not getting installed in the FIB . This can be manifested by KRT queue getting stuck with EINVAL error for the list NH in case of only one NH out of the list being installed. In case the already installed member links are more than 1, then this could be a case of misprogramming wherein the FIB goes not get updated with the new members along with no logs/errors being thrown in the system. 


Some error logs might be seen on MX2010/MX2020 routers equipped with SFB2

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. 


RSVP authentication may fail between some Junos releases and cause traffic loss during local repair

When Resource Reservation Protocol (RSVP) link or node protection is deployed and RSVP authentication is used, if the PLR (Point of Local Repair) router and the MP (Merge Point) router run different versions of Junos software during local repair, i.e. one a >= 16.1 release and the other a < 16.1 release, the RSVP authentication errors may occur for the bypass Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) and cause traffic loss. 


The traffic traversing an IRB interface might not be tagged with a VLAN if the packets go through an additional routing-instance.

On MX-Series platforms with logical tunnel interface (LT) working in trunk mode, if an IRB interface is referenced by a bridge-domain in a virtual-switch routing-instance and its traffic goes through an l2circuit between two virtual-switch routing-instances, the VLAN insertion might not work for IRB interface, as a result, the traffic could be dropped. 


The RE might crash with various core files due to the deadlock issue on the SDB STS

In the system that uses session database (SDB), the deadlock might happen when getting the lock on the SDB short term storage (STS) due to a rare timing issue. It is more likely to happen on Enhanced Subscriber Management environment with large-scale subscribers (such as 50k subscribers). The issue will cause the primary Routing Engine (RE) to crash with various core files and lose the management connectivity. And the subscriber service could be affected. The issue might happen on single RE system as well as dual RE system. In the dual RE system, the primary RE crash could trigger a RE switchover. But the issue could cause the incomplete state on the SDB in the new primary RE, which could cause the subscribers login failure. A restart of smg-service on the new primary RE will recover this login issue. 


2019-01 Security Bulletin: Junos OS: OpenSSL Security Advisories [16 Apr 2018] and [12 June 2018]

The OpenSSL project has published security advisories for vulnerabilities resolved in the OpenSSL library on April 16, 2018, and June 12, 2018. See for details. 


The rpd crash might be seen if a BGP unresolved route is withdrawn

If an import policy is applied to a BGP neighbor and the policy has indirect IPv4 next-hop for IPv4 and IPv6 routes (IPv6 routes resolved over IPv4), when BGP unresolved route is withdrawn, rpd crash might be seen. 


If FPGA on the new primary CB has a specific hardware failure, the chassid might keep crashing after GRES switchover

On MX/EX/SRX platforms, after GRES switchover, if a chassis has bent-pin or failed Field Programmable Gate Array (FPGA) on the new CB has a specific hardware failure and fails to detect FPC presence properly, the chassisd might keep crashing. 


A few VPN tunnels do not forward traffic after RG1 failover.

A few VPN tunnels do not forward traffic after RG1 failover when traffic-selector is configured in the AutoVPN. 


EVPN-VxLAN: DCPFE restarted at the _bcm_field_td_counter_last_hw_val_update routine after upgrading spine with latest image.

Within the DCPFE process, it is possible that a deadlock situation between the pfeman thread and the linkscan thread causes the watchdog event to trigger. The DCPFE saving its memory content (core file) as the result. 


The rpd soft core might be seen when L2VPN is used

RPD provides a mechanism to validate that route selection has successfully been done. When errors in route selection are detected, a soft core is dropped: RPD remains running, a single core file is dropped, it is rate limited to not do this frequently. When running L2VPN, BGP MED selection may be inappropriately run on the routes. As a result, the route selection sanity code will notice an unexpected result and leave a soft core. 


IPSEC tunnel can not be established because that the tunnel SA and rule are not installed in the PIC

On MX-Series platforms, when IPSEC is used in an interoperability scenario with other verndor`s devices (such as CISCO/HUAWEI) and peer device sends IPSEC tunnel establishment request using the port and protocol as Traffic/Flow distinguisher, the SA for the tunnel is not installed in the PIC, namely the impacted tunnels are up on the RE but these are not programmed in the PFE. It would cause that IPSEC tunnel can not be established and traffic failure. 


The L2circuit egress PE might drop the traffic in FAT+CW enabled L2circuit scenario when another FAT+CW enabled L2circuit PW flaps

On PTX1000/PTX10002/PTX10008/PTX10016 platforms, when multiple FAT+CW (FAT->flow-aware transport, CW->control-word) are enabled in L2circuit PWs (pseduo-wires) scenario, the L2circuit egress PE might drop the traffic (the affected PW is unsure/unkown) and also corrupt the PW traffic/packet received from MPLS core when another FAT+CW enabled L2circuit PW flaps (such as, link down, FPC crashes, do enable/disable of flow label on PW, etc). 


When a IPSec peers IP changes it cannot establish a new tunnel until the IPEC SA CLEAR command is run

When a IPSec peers IP changes it cannot establish a new tunnel until the IPEC SA CLEAR command is run 

Modification History:
Update to include PTX Software recall - TSB17535 on 2019-03-06
First publication date 2019-03-01
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search