PR Number |
Synopsis |
Description |
1343680 |
i40e NVM upgrade support for PTX platforms
|
Adding support for i40e NVM upgrade in PTX3000 platforms
|
1388112 |
The FPC core might be observed when J-Insight is configured
|
J-Insight is a data-driven device monitoring solution that provides visibility and insight into the health of a running system. J-Insight is an on-premise system application that uses the Junos Telemetry Interface to continuously collect data that is reflective of the current state and health of the device component being monitored. When J-Insight is configured and telemetry is enabled with any sensor, the FPC core might be observed if deleting and reaping data happen at the same time. It is a rare timing issue.
|
1409879 |
FPC crash may be observed with scaled subscribers login attempts
|
In a subscriber management environment with scaled subscribers login such as 200k PPPoE subscribers, FPC crash may be observed.
|
1425339 |
The IFLs in EVPN routing instances might flap after committing configurations
|
When EVPN (Ethernet VPN) routing instance is created, there is an implicit bridge domain created for this EVPN. After creating another routing instance, the index of the implicit bridge domain created for EVPN is not updated properly in DCD. Therefore, the IFLs in EVPN routing instances might flap. [TSB17573]
|
1427075 |
VC split after network topology changed
|
In Virtual Chassis (VC) scenario, when the interfaces flaps or VLAN configuration is changed frequently, the network topology will be changed accordingly, then CPU utilization will be dramatically increased to very high within a short time, which might cause the failure of essential communications between VC master and members. When the failure happens, FPC will automatically restart. As a result, VC is split and traffic is lost.
|
1432023 |
fxpc core seen once during reboot due to Bad Chip ID
|
Due to Bad Chip ID, fxpc core can be encountered once during reboot of device, later it recovers by itself with no other issues.
|
1432703 |
Outer VLAN tag may not be pushed in the egress VXLAN traffic towards the host for QinQ scenario
|
In EVPN-VXLAN with QinQ scenario, if the "encapsulate-inner-vlan" knob is configured on some VXLANs but not configured on some other VXLANs, and after an interface flap OR a configuration change, the switch may stop pushing the outer VLAN tag towards host for QinQ scenario.
|
1436223 |
i40e NVM upgrade support for EX9200 platform
|
Added support for i40e NVM upgrade in EX9208 in JUNOS Software releases
|
1437295 |
The FPC might crash if both the AE boundle flapping on local device and the configuration change on peer device occur at the same time
|
On QFX platforms, the FPC might crash if both the AE (Aggregate Ethernet) boundle flapping on local device and the configuration change on peer device which can cause the interface down occur at the same time.
|
1442319 |
Traffic drop might be seen at EVPN Layer3 Gateway scenario
|
In EVPN-VXLAN Layer3 Gateway scenario, when some events occur (such as, IP/VM move, VRRP switchover and so on), the GARP (Gratuitous Address Resolution Protocol) packet is received with source Ether MAC different with inner ARP MAC, then it would move IP Route/NH (Next-Hop) into discard state in the forwarding-table. This causes traffic drop. The reason is that normally (as per design) MAC+IP is allowed to be learned after MAC is learned. But in this scenario the GARP is received before the inner MAC is learned. So it might result in reverse process and would move the ARP NH into the discard state. The fix is to drop ARP (or GARP) packets till the host/Server Mac is learned. This could avoid ARP entry moving into discard NH.
|
1446043 |
In ACX, auto exported route between VRFs might not reply for icmp echo requests
|
In ACX, auto exported route between VRFs might not reply for icmp echo requests
|
1446568 |
The high CPU utilization of l2ald is seen after replacing EVPN config
|
The l2-learning CPU utilization might get high and remain stuck forever after switching configuration files several times between EVPN and non-EVPN (e.g VRRP) by loading the corresponding configuration file. Because of that some of the data in the device is not successfully clean up, when EVPN-config (virtual-switch) is removed and the Ethernet Segment Identifier (ESI) interface is configured in a non-EVPN routing-instance.
|
1448722 |
SPC3 Talus FPGA stuck on 0x3D/0x69 golden version
|
In SRX5000 series with SPC3, at the first bootup after a Junos upgrade, if the SPC3 FPGA upgrade gets interrupted for example by another reboot, the FPGA upgrade may persistently fail and fallback to an older FPGA image (0x3D/0x69), which may cause the SPC3 card to come online, but not process traffic. The system alarm 'Talus version mismatch' will be raised in this case.
|
1449410 |
Loopback address exported into other VRF instance might not work on EX/QFX/ACX platforms
|
On EX/QFX/ACX platforms, the loopback address exported into other VRF instance might not work.
|
1452851 |
MX10003:MACSEC framing errors are seen when ever sequence number exceed 2 power 32 with XPN (Extended Packet Numbering) .
|
MX10003:MACSEC framing errors are seen when ever sequence number exceed 2 power 32 with XPN (Extended Packet Numbering) .
|
1453464 |
PPPoE holding DHCPv6 prefix causes DHCPv6 binding failure due to duplicate prefix
|
In subscriber management scenario deployed with DHCPv6 over PPPoE, if the DHCPv6 handshake process of one subscriber does not complete and fails, the prefix assigned will be freed back to the address-assignment pool and assigned to the next subscriber. But that prefix is incorrectly retained in the first subscriber's PPPoE session. Then if the first subscriber solicits DHCPv6 prefix again, the original prefix which is already assigned to the second subscriber will be requested, resulting in DHCPv6 bind failure due to duplicate prefix.
|
1456668 |
EX3400 may go a reset with vmcore by panic
|
EX3400 may go a reset with vmcore by panic. This is extremely a rare case. root@ex3400> show system core-dumps no-forwarding -rw-r--r-- 1 root wheel 283194368 Jan 1 1970 /var/crash/vmcore.direct
|
1457228 |
Few seconds of traffic drop might be seen on the existing receivers when another receiver joins/leaves
|
With "protocol igmp-snooping" configured, if some receiver joins/leaves a group, few seconds of traffic drop might be seen on the existing receivers.
|