SNMP MIB walk on jnxDomCurrentTable and jnxDomNotifications needs to be supported

SNMP MIB walk on jnxDomCurrentTable and jnxDomNotifications is enabled.

mspmand core can occur in rare conditions due to a high rate of TCP traffic

When using the CGNAT plugin on the MS-MIC or MS-MPC card the mspmand process can core in rare conditions due to a heavy volume of TCP traffic.

The kernel might crash after restarting chassisd process with dual REs

This issue might occur only in corner case where RE mastership role is interpreted differently by rpd and jsr_jsm thread in kernel. The error message is as follows: db> bt Tracing pid 27 tid 100070 td 0xc7381360 send_proto_keepalive(cad85de0,d0657964,f60dbc00,f60dbc10,0,...) at send_proto_keepalive+0x186/frame 0xf60dbbe0 ...

Cleanup at thread exit in FreeBSD kernel causing memory leaks

The FreeBSD kernel creates threads to perform various tasks when these threads exit portion of their memories are not released properly.

JSA10896 [juniper.net] 2018-10 Security Bulletin: Junos OS: Denial of service in telnetd (CVE-2018-0061)

A denial of service vulnerability in the telnetd service on Junos OS allows remote unauthenticated users to cause high CPU usage which may affect system performance.

The FPC might crash due to the IFL index corruption when IPv6 traffic goes through the IRB interface

In IPv6 scenario, if the IPv6 traffic is coming in an IRB interface and triggering ICMPv6 error packet with the error type of 'MTU exceeded' or 'redirect', and the ICMPv6 error packet is sent out a different IRB interface than the incoming IRB interface, the index of the IRB logical interface (IFL) might be corrupted. The subsequent configuration change (e.g. deactivating/activating, deleting or changing interface configuration) might cause the crash of the FPC hosting the corrupted IFL index. The traffic null route also might be seen on the affected FPC.

MX Series: L2ALD daemon may crash if a duplicate MAC is learned by two different interfaces (CVE-2018-0056)

MX Series: L2ALD daemon may crash if a duplicate MAC is learned by two different interfaces (CVE-2018-0056); Refer to https://kb.juniper.net/JSA10890 [juniper.net] for more information.

Suppressing cfmd logs : jnxSoamLmDmCfgTable_next_lookup: md 0 ma 0 md_cfg 0x0

The PR suppress the unnecessary CFMD logs like below: Mar 9 11:30:51.614 2018 MX cfmd[28796]: %DAEMON-3: jnxSoamLmDmCfgTable_next_lookup: md 0 ma 0 md_cfg 0x0 Mar 9 11:30:51.614 2018 MX cfmd[28796]: %DAEMON-3: jnxSoamLmDmCfgTable_next_lookup: md 0 ma 0 md_cfg 0x8d69160 Mar 9 11:30:51.614 2018 MX cfmd[28796]: %DAEMON-3: jnxSoamLmDmCfgTable_next_lookup: md 0 ma 0 md_cfg 0x0 Mar 9 11:30:51.614 2018 MX cfmd[28796]: %DAEMON-3: jnxSoamLmDmCfgTable_next_lookup: md 0 ma 0 md_cfg 0x8d69160 Mar 9 11:30:51.614 2018 MX cfmd[28796]: %DAEMON-3: jnxSoamLmDmCfgTable_next_lookup: md 0 ma 0 md_cfg 0x0 Mar 9 11:30:51.614 2018 MX cfmd[28796]: %DAEMON-3: jnxSoamLmDmCfgTable_next_lookup: md 0 ma 0 md_cfg 0x8d69160 Mar 9 11:30:51.614 2018 MX cfmd[28796]: %DAEMON-3: jnxSoamLmDmCfgTable_next_lookup: md 0 ma 0 md_cfg 0x0

PS over rLT doesn't work on MPC7/9; PS over LT for the same scenario works;

RLT interface setup was broken. By design, RLT interface is supposed to have a different L1 node and a different stream other than the tunnel stream. This is mentioned in the design spec of RLT and the source code as well. However, on WindSurf/Scuba, RLT interface continued to be mapped to same Tunnel stream and then on EA it did not even get setup. This issue is fixed now.

JSA10892 [juniper.net] 2018-10 Security Bulletin: Junos OS: authd allows assignment of IP address requested by DHCP subscriber logging in with Option 50 (Requested IP Address) (CVE-2018-0057)

Junos OS: authd allows assignment of IP address requested by DHCP subscriber logging in with Option 50 (Requested IP Address) (CVE-2018-0057); For more details, please refer to https://kb.juniper.net/JSA10892 [juniper.net] for more information.

The DHCPv6 binding might be stuck in "RELEASE(DHCPV6_RELAY_STATE_WAIT_SUBSCR_DELETE)" state when route-suppression is configured

On all MX-Series platforms with the route-suppression configuration, when the subscriber sends a release message, the binding remains and it might not able to be released, as a result, the DHCPv6 binding might be stuck in "RELEASE(DHCPV6_RELAY_STATE_WAIT_SUBSCR_DELETE)" state.

L2 Circuit might flap after an interface goes down even if the LDP session stays up when l2-smart-policy is configured

With l2-smart-policy configured for LDP (Label Distribution Protocol), the L2 Circuits might flap if the LDP targeted adjacency also has a link hello adjacency and the interface with the link hello adjacency goes down.

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.

JSA10889 [juniper.net] 2018-10 Security Bulletin: Junos OS: The jdhcpd process crash during processing of specially crafted DHCPv6 message (CVE-2018-0055)

The jdhcpd process crash during processing of specially crafted DHCPv6 message (CVE-2018-0055); Refer to https://kb.juniper.net/JSA10889 [juniper.net] for more information.

JSA10893 [juniper.net]: 2018-10 Security Bulletin: MX Series: In BBE configurations, receipt of a crafted IPv6 exception packet causes a Denial of Service (CVE-2018-0058)

MX Series: In BBE configurations receipt of a crafted IPv6 exception packet causes a Denial of Service (CVE-2018-0058), please refer to https://kb.juniper.net/JSA10893 [juniper.net] for more information.

ISSU could be aborted at "Timed out Waiting for protocol backup chassis primary switch to complete" with MXVC confiig

Under rare circumstances, MX Series Virtual Chassis unified ISSU might terminate with the message "Timed out Waiting for protocol backup chassis primary switch to complete".

Traffic might be dropped on third-generation FPCs on PTX

On PTX with third-generation FPCs, if optics not certified by Juniper Networks (NON-JNPR) are used and there is specific traffic pattern with congestion, traffic might be dropped.

JSA10883 [juniper.net]: Junos OS: Receipt of a specifically crafted malicious MPLS packet leads to a Junos kernel crash (CVE-2018-0049)

Junos OS: Receipt of a specifically crafted malicious MPLS packet leads to a Junos kernel crash (CVE-2018-0049). Please refer to https://kb.juniper.net/JSA10883 [juniper.net] for more information.

Memory leak observed in MS-MPC card

On MX platform with MS-MPC installed, memory leak can be observed when requesting "vty mspdbg-cli command".

All the BGP sessions will flap after switchover

With GRES and NSR enabled, if executing switchover, all the BGP session might flap

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.

BGP reset may be observed in an EPVN-MPLS scenario

In an EVPN-MPLS scenario where the device is running on certain release (16.1 or 16.2), the BGP session may be reset due to receiving unexpected EVPN type 2 updates that have an IPv6 prefix and a MAC address along with two labels.

The MS-MPC might core when mspmand receives a non-syn packet of TCP

On MX-Series platforms and when MS-MPC line card is used, if the ms/ams-interface is not configured and mspmand (Multiservices PIC management daemon) receives a non-syn packet of TCP, the MS-MPC might crash due to some NULL pointer issues of the global configuration variable.

MX480 - RR does not release EVPN Type 2 MAC+IP route from RPD when Advertise NLRI has 2 MPLS labels and Withdrawal NLRI has 1 MPLS label

The issue here is that BGP withdrawal for type-2 MAC+IP routes having a single label is not processed if the advertisement of the same MAC+IP rt had 2 levels. The reason is in evpn_sockaddr structure we have field nlri length which is included in the rt prefix. But in this case the Advertisement and Withdrawal NLRI lengths will be different as the no of labels in those 2 rts are different. As a result when withdrawal of the route is received, rt lookup fails as the advertisement and withdrawal prefix values will be different. For type-2 MAC+IP rt, the key for the prefix is rt-type + RD + mac_addr_len + mac_addr + ip_addr_len + ip_addr. ESI and labels are the rt data attributes and are not part of the key. Fix is to update the type-2 evpn_sockaddr NLRI length to have only the prefix key length instead of having the actual NLRI length.