Unified ISSU on Inline LSQ Interfaces Overview

Unified ISSU support for inline LSQ interfaces provides backward compatibility with Junos OS releases in which this support is not available. You can perform a unified ISSU process between a Junos OS release that supports unified ISSU for inline LSQ interfaces and a Junos OS release in which unified ISSU support for inline LSQ interfaces is not available. This backward compatibility does not apply to the scenario where part of the software (such as the kernel software) is upgraded while another part (such as the Packet Forwarding Engine software) is not upgraded. Unified ISSU infrastructure provides APIs to store persistent data, perform cold boot (without resetting power), and manage post-ISSU reboot connectivity and synchronization with Routing Engine kernel and other processes. Unified ISSU is also supported for redundant LSQ (rlsq-) interfaces configured in hot-standby and warm-standby mode.

The following line cards on MX Series routers support unified ISSU for inline LSQ interfaces:

• 8-port Channelized DS3/E3 MIC (MIC-3D-8CHDS3-E3-B)

• 8-port Channelized SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP (MIC-3D-8CHOC3-4CHOC12)

• 4-port Channelized SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP1 (MIC-3D-4CHOC3-2CHOC12)

• MPC Type 1 3D Q (MX-MPC1-3D-Q)

• MPC Type 2 3D Q (MX-MPC2-3D-Q)

LSQ interfaces support the following three types of multilink data traffic:

• Complete multilink packets (for which bandwidth and encapsulation are set)—These packets do not require the reassembly memory.

• Fragmented multilink packets–These packets require reassembly memory to form a complete packets until all the fragments of all packets arrive.

• Link fragment interleaving (LFI) packets—These packets do not have any multilink header.

There are two time intervals or durations called dark windows during the unified ISSU process. These dark windows denote the brief traffic disruption and outage in handling of packets that can occur when the Packet Forwarding Engines restart owing to the upgraded software being installed on them. The duration of these traffic disconnections vary in length based on several factors, such as the platform and the Junos OS version being upgraded. The following two dark windows are observed:

• The first dark window is during the unified ISSU boot phase. During this time period, host-bound packets are affected because the new microkernel image is being initialized and the path to the host is not discovered yet. The aging calculations for reassembly and fragmentation are stopped, which causes the fragmented traffic types to be dropped. However, LFI packets and complete multilink packets are not disrupted.

• The second dark window occurs during the hardware synchronization phase. During this time period, the hardware learns all the new states from the software. ASICs reinitialize themselves with the new configurations. During this period, all kinds of traffic drops are permissible. The duration for this dark window is approximately 4–5 seconds. During the second dark window, because packets are dropped at the fragmentation side, a receive-ml-seq number mismatch occurs at the other end of the connection (reassembly or receiver side). This behavior can cause additional packet drops.

During a unified ISSU, a switchover from the primary LSQ interface to the secondary lsq interface does not occur and the bundle remains up. The impact on fragmented packets (to be reassembled) remains the same as the packets on LSQ interfaces. LFI and non-fragmented packets are traversed until the second dark window starts. The dark window duration for rlsq- interfaces is the same as that for LSQ interfaces. No particular attribute is maintained only on the local MPC hardware. All of the QoS functionalities behave in the same manner as the pre-unified ISSU phase.

During the unified ISSU process, none of the multilink counters are updated (except the multilink sequence number). The counters are reset and incremented from zero after unified ISSU is completed. The receive-ml-seq and send ml-seq counters need to be updated for reassembly to take place properly but the update of these counters is not exported to the Packet Forwarding Engine microkernel or the Routing Engine.

It is assumed that bundle links do not flap during the unified ISSU window. The following operations occur at the fragmentation and reassembly ends during a unified ISSU process:

When unified ISSU is completed, the send multilink sequence (send-ml-seq) number starts from zero and it causes the receive multilink sequence (receive-ml-seq) number mismatch at the other end of the connection, resulting in additional packet drops. Consider the case where LSQ bundles and links can be hosted on different Packet Forwarding Engines in a dual Packet Forwarding Engine setup. In this scenario, it is possible that these two Packet Forwarding Engines are in different states of the ISSU process, where dark windows for both of them might follow different timelines. This condition adds to more drops.

At the reassembly side:

1. The reassembly is stopped at the unified ISSU preparation or initialization phase, which can cause a longer dark window for fragmented packets. At the time of unified ISSU, reassembly memory is used for unified ISSU processing and is not available, starting from the unified ISSU preparation phase up to the unified ISSU hardware synchronization stage.

2. The two activities of link-load calculations and aging of fragments might impact the traversal of packets during unified ISSU.

At the fragmentation side:

1. .The ml-seq number counter, which is needed for multilink fragmentation to work, is not part of the unified ISSU counters.

2. The host-generated packets (that are Layer 2-rewrite packets) are transferred as part of the fabric header and saved as binary large objects (BLOBs).

3. For LFI traffic, hash calculation must work properly for the links to be load-balanced. If the media link state changes during unified ISSU, the bundle state might also be affected.