Service Manual

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 congured 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 specic 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 Conguration 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 trac to a destination is higher than the volume of trac that
can be carried over one path, a portion of that trac 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 Networking OS has some inherent ineciencies when handling a large number of ECMP routes
(i.e., routes with multiple equal-cost next hops). To circumvent this for the conguration 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 rst 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.
Flex Hash and Optimized Boot-Up
289