Addendum

BGP Graceful Restart
The fast boot functionality operates in the following manner when the system contains one or more BGP
peerings configured for BGP graceful restart, apart from performing the other generic system-wide tasks:
When you reload the device using the fast boot capability enables, a closure of the TCP sessions is
performed on all sockets corresponding to BGP sessions on which Graceful Restart has been negotiated.
This behavior is to force the peer to perform the helper role so that any routes advertised by the
restarting system are retained and the peering session will not go down due to BGP Hold timeout (which
needs to be prevented because it does not cause graceful restart to be initiated).
Termination of TCP connections is not initiated on BGP sessions without GR because such a closure
might cause the peer to immediately purge routes learnt from the restarting ToR, thereby causing
immediate traffic loss
When BGP on the system is started, if it determines that the system has come up through a fastboot, it
sets the R-bit and F-bit in the GR capability when bringing up the session with peers for which BGP GR
has been configured. This is the standard behavior of a Restarting system and ensures that the peer
continues to retain the routes previously advertised by the system.
The system will also delay sending the BGP End-of-RIB notification to peers with whom BGP GR has
been negotiated to ensure that the local routes of the system are advertised to the peers, if required by
the configuration. This condition occurs only if the system has come up through a fastboot.
Note that if BGP GR is enabled on any peering session, the timeout values used for the BGP hold timer do
not take effect.
Cold Boot Caused by Power Cycling the System
When you perform a power-cycle operation on a system that is configured with the optimized booting
functionality, in a sequenced, planned manner by powering off the system and then turning it back on
and booting it, the system will go through its regular boot sequence as described in the Booting Process
When Optimized Boot Time Mechanism is Enabled' section occurs even if it is configured for fastboot.
When the system comes up, it is expected that there will be no dynamic ARP or ND database to restore.
Likewise, the mode of boot up of the system will not be fastboot and actions specific to this mode (listed
in earlier sections) will not be performed.
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 ás described in the 'Booting Process When Optimized Boot Time
Mechanism is Enabled' section even if it is configured for fastboot. When the system comes up, dynamic
ARP or ND database entries are not present or required to be restored. Also, the boot mode of the system
is not of fast boot type and the processes that are performed during a normal reload of the system,
without fast boot capability enabled, are run.
Software Upgrade
The system behavior when fast boot is used to upgrade the system to a Dell Networking OS release that
supports the fastboot functionality 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 the fast boot funcionality.
140
Flex Hash and Optimized Boot-Up