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.1R2-S9: Software Release Notification for Junos Software Service Release version 17.1R2-S9



Article ID: TSB17444 TECHNICAL_BULLETINS Last Updated: 08 Oct 2018Version: 1.0
Alert Type:
SRN - Software Release Notification
Product Affected:
MX, PTX, VMX, VRR, NA, QFX5K/10K, EX, ACX5K/Legacy
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.1R2-S9 is now available.

The following are incremental changes in 17.1R2-S9.

PR Number Synopsis Description
1035484 Enhanced IP/enhanced-Ethernet and MS-DPC compatibility. The enhanced-IP or enhanced-Ethernet network-services mode and MS-DPC card are not compatible and should not be configured or inserted in the chassis, at the same time. The enhanced-IP or enhanced-Ethernet mode extends the range of logical interfaces (IFLs) configurable to 0-256K while MS-DPCs are limited to support 0-64K logical interfaces. The enhanced-IP or enhanced-Ethernet and MS-DPC card will become compatible only after a code change is introduced by this PR. For a new configuration statement is implemented to limit the logical interface scaling to 64,000 (default), the enhanced-IP or enhanced-Ethernet mode is configured as follows: # set chassis network-services enhanced-ip limited-ifl-scaling Note: the new configuration statement will require system to reboot if router already had configuration about network-services enhanced-IP.
1235132 FPCs offline with "FPC Incompatible with SCB" during system restart FPCs on MX series platform with two power zones (e.g. MX960, MX480) might be stuck in offline state with "FPC Incompatible with SCB" due to delayed PEM-powerup.
1243687 ACX: does not forward DHCP-RELAY requests with IRB interface after upgrade. ACX: does not forward DHCP-RELAY requests with IRB interface after upgrade.
1255973 Prolonged flow-control core observed for the TFTP ALG traffic (10K simulated users). Locking issue observed only at high scale of TFTP sessions. There is no major risk with this issue since it's observed only with TFTP ALG .
1258472 The rpd might crash during the next-hop change, if unicast reverse-path- forwarding (uRPF) is used In rare cases, if the unicast reverse path forwarding (uRPF) is used, the rpd might crash and a core file might be generated during the next-hop change.
1263012 Transit ARP packets are being punted to the RE ACX device is getting transit ARP traffic coming from IFL's that are part of a bridge-domain or l2-circuit punted to the RE. Internal coded queues are supporting a maximum of 200 pps in the (ARP + ICMPv6) queue. When hitting limits in this internal queue, other protocols that depend on ARP resolution can be affected and eventually flap. In software versions which include the fix of this PR , a new internal design will allow 200 + 200 pps in the internal ARP and ICMPv6 queues, and will avoid other protocols to flap.
1268891 A low memory condition putting the Service PIC into the red zone on the MS-MIC or MS-MPC card might cause the SIP ALG to generate a core file A low-memory condition puts the service PIC into the Red Zone on the MS-MIC or MS-MPC card when the SIP ALG is used. This can cause SIP ALG to generate a core file.
1269383 Backup RE may go to db prompt after performing configuration remove and restore vmcore on backup RE though not critical could impact NSR functionality. This can be hit in particular scenarios like: - Back to back GRES with specific configuration. - Commit and rollback the configuration Impact: This will not impact the production RE since core is on backup. Also, the issue is seen very rarely. Hence, this shouldn't impact the production.
1271100 ARP packets coming with a vlan tag not configured in ACX are hitting the default_arp_policer On ACX routers, the ARP packets being received with a vlan tag that is not configured in ACX will hit the default_arp_policer prior to being dropped. In certain scenarios where the CE device is sending a large amount of ARP packets (transit ARP) using a vlan tag that is not configured in the ACX, the default_arp_policer might be exceeded, leading to drops of legitimate ARP packets coming from other interfaces. As the default_arp_policer is applied at system level.
1279339 On MX104 platform with GRES enabled, the chassis network-services might not get set as "Enhanced-IP" On MX104 platform with graceful routing engine switchover (GRES) enabled. The chassis network-services might not get set as "Enhanced-IP" though it is specifically configured. "Disable GRES, then config enhanced-ip" is a workaround for this issue.
1285673 Administratively disabling an interface might cause high FPC CPU usage If the "admin-disabled" interfaces are connected to noisy links or remote peer devices, there is a possibility of high CPU load on XM-chip based FPCs (for example, MPC3E/4E/5E/6E/2E-NG/3E-NG on MX Series) when the interfaces on that FPC are disabled by the administrator. As a result, there are continuous MAC fault log messages and/or high FPC interrupt CPU utilization (resulting from many MAC fault interrupts).
1287086 Incorrect load-balancing on the aggregated Ethernet interface might occur if traffic goes from MS-DPC to MPC in enhanced-ip mode. This issue occurs on an MX Series router installed with both MS-DPC and data MPC cards, the network service is configured in enhanced-IP mode, and the ae interface is configured on the MPC card. If the member interfaces of the ae interface are under a different Packet Forwarding Engine, the outbound traffic from the ae interface might experience incorrect load-balancing. If the traffic is received from MS-DPC and exits from the ae interface on MPC, the egress traffic is transmitted to only one member interface of the ae interface instead of all.
1310081 SPD_CONN_OPEN_FAILURE and SPC_CONN_FAILURE log messages are seen in the log for SI interfaces when running SNMP walk on Service PIC NAT OIDs. SPD_CONN_OPEN_FAILURE and SPC_CONN_FAILURE log messages are seen in the log for SI interfaces when running SNMP walk on Service PIC NAT oids. The SNMP NAT OIDs are not used for the inline NAT solution. They are used for the NAT solution that runs on the service cards such as the MS-DPC, MS-PC or MS-MIC for example. So these info messages are displayed starting in 15.. The PR will hide these messages since they are not needed.
1314070 mspmand core due to flow-control seen while clearing CGNAT+SFW sessions. If there is frequent deletion of sessions, in a long run, this can happen due to internal memory arena churn taking more time. Fix is added to optimize memory arena free and avoids flow-control exertion by service pic.
1348027 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.
1350375 UDP checksum inserted by MS-DPC after NAT64 is not valid when incoming ipv4 packet has UDP checksum set to 0 In IPv4 Encapsulating Security Payload (ESP) packes, UDP checksum is set to 0 as UDP checksum is not a mandatory field. When MS-DPC does a NAT64 translation of such a packet, the UDP checksum inserted in the IPv6 packet is not correct. Because of this, the Internet Key Exchange Protocol Version 2 (IKEv2) VPN service with NAT-T running through NAT64 on MX with MS-DPC is not able to pass traffic after successful tunnel setup.
1353240 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.
1355270 The ae interface might flap when the link speed of the ae bundle is configured to oc192 When the link speed of the ae (Aggregated Ethernet) bundle is configured to oc192, certain sequence operation might lead to the ae interface flap which will affect traffic. First, configure the member links. And then, remove a member link from the bundle. At last, add a member link back.
1362560 The route stuck might be seen after BGP neighbor and route flapping It is route installation failure case which is not handled properly in BGP multipath scenario. It might cause traffic loss.
1368788 In dual-homed NG-MVPN the receipt of Type 5 withdrawal removes downstream join states for some routes. The issue happens only in spt-only scenario when two type 5 exists and one of them is withdrawn. The multiple type 5 exists due to both PE routers connected via MSDP mesh and gets an MSDP SA route to indicate source is active. Ideally, an SA present flag needs to be set on S,G entry when a type 5 is present. Currently, in spt-only mode, this flag is being set only when the type 5 is created. The type 5 creation happens when the traffic hits the router or in case of MSDP SA which is the scenario here. At this point it is possible that the pim S,G entry itself is not available especially in spt-only mode where type 7 is sent to ingress only after the egress PE gets a type 5. Later when the pim S,G entry is created, the flag currently is set only for rpt-spt mode and so the flag gets never set in spt-only mode. Since one of type 5 gets withdrawn later (due to MSDP SA withdrawal) and no flag is set on S,G, it assumes there is no more type 5 available and hence proceeds with deletion of the MVPN created S,G and hence the problem. Clear PIM join is a workaround to recover from this scenario.
1368986 Commit may fail in single-user mode If the device is booted into single-user mode (recovery mode), and any change in configuration is made, such as setting the root password, then commit will fail.
1386011 IPSec VPN traffic might fail when passing through CGNAT enabled on MX with MS-MPC While dynamic IP Security (IPSec) virtual private network (VPN) is re-keyed due to lifetime expiration, IPSec internet key exchange (IKE) phase 1 user datagram protocol (UDP) port 500 and phase 2 UDP port 4500 sessions would be translated into two different public internal protocol (IP) addresses while passing through a carrier-grade network address translation (CGNAT), which causes IPSec VPN traffic to fail. This behavior does not cause an issue for Juniper MX devices with MS-MIC or SRX devices since for such devices identify key is used to authenticate the sessions and it is allowed for private IP address to be translated into two different public IP addresses.
Modification History:
First publication date 2018-10-08
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