Deployment Guide

Unexpected Reload of the System
When an unexpected or unplanned reload occurs, such as a reset caused by the software, the system performs the regular
boot sequence even if it is configured for fast boot. When the system comes up, dynamic ARP or ND database entries are not
present or required to be restored. The system boot up mode will not be fast boot and actions specific to this mode will not be
performed.
Software Upgrade
When fast boot is used to upgrade the system to a release that supports fast boot, the system enables the restoration of
dynamic ARP or ND databases that were maintained in the older release from when you performed the upgrade and the ARP
and ND applications identify that the system has been booted using fast boot.
LACP Fast Switchover
For fast boot, the operation of LACP has been optimized. These LACP optimizations are applicable even when fast boot is
not enabled when a system reload is performed. These enhancements are controlled using the fast-switchover option that is
available with the lacp command in Port Channel Interface Configuration mode. When LACP ‘fast-switchover’ is enabled on
the system, two optimizations are performed to the LACP behavior:
● The wait-while timer is not started in the ‘waiting’ state of the MUX state machine. The port moves directly to the
‘attached’ state.
● The local system moves to the ‘collecting’ and ‘distributing’ states on the port in a single step without waiting for the partner
to set the ‘collecting’ bit.
Changes to BGP Multipath
When the system becomes active after a fast-boot restart, a change has been made to the BGP multipath and ECMP behavior.
The system delays the computation and installation of additional paths to a destination into the BGP routing information base
(RIB) and forwarding table for a certain period of time. Additional paths, if any, are automatically computed and installed without
the need for any manual intervention in any of the following conditions:
● After 30 seconds of the system returning online after a restart
● After all established peers have synchronized with the restarting system
● A combination of the previous two conditions
One possible impact of this behavior change is that if the amount of traffic to a destination is higher than the volume of traffic
that can be carried over one path, a portion of that traffic might be dropped for a short duration (30-60 seconds) after the
system comes up.
Delayed Installation of ECMP Routes Into BGP
The current FIB component of Dell EMC Networking OS has some inherent inefficiencies when handling a large number of
ECMP routes (i.e., routes with multiple equal-cost next hops). To circumvent this for the configuration of fast boot, changes are
made in BGP to delay the installation of ECMP routes. This is done only if the system comes up through a fast boot reload. The
BGP route selection algorithm only selects one best path to each destination and delays installation of additional ECMP paths
until a minimum of 30 seconds has elapsed from the time the first BGP peer is established. Once this time has elapsed, all routes
in the BGP RIB are processed for additional paths.
While the above change will ensure that at least one path to each destination gets into the FIB as quickly as possible, it does
prevent additional paths from being used even if they are available. This downside has been deemed to be acceptable.
332
Flex Hash and Optimized Boot-Up