Addendum

LACP Fast Switchover
For the fastboot functionality, the operation of LACP has been optimized. These LACP optimizations are
applicable even when fast boot mechanism is not activated 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 to LACP behavior of the local system are performed:
• The wait-while timer is not started in the ‘waiting’ state of the MUX state machine. Instead 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.
The aforementioned optimizations do not work individually to reduce the time that is required for LACP
to consider a port as aggregated to a port channel because the partner (adjacent system) is also involved
in this process to minimize the switchover time when a failover occurs from one member interface of the
LAG or port channel bundle to another member interface.
Changes to BGP Multipath
When the ToR switch becomes active after a system restart using the fast boot method, a change has
been made to the BGP multipath and ECMP behavior. The ToR 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. This method of processing occurs to ensure that the ToR is able to learn and
install at least one path to each destination as quickly as possible into the forwarding table and to avoid
delays that might potentially occur in resuming traffic to some destinations because multiple paths are
being computed and installed to other destinations. This operation also occurs to handle a few behavior
implications of the FIB application. Additional paths will be automatically computed and installed (if any)
without the need for any manual intervention after 30 seconds of the system returning online after a
restart, after all established peers have synchronized with the restarting ToR, or a combination of both the
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 ToR switch comes up. However, this brief traffic disruption is an
effective alternative to a complete or increased disconnection in traffic to some destinations for a longer
period after the ToR switch returns to the active state.
Minimized Connection Setup Time
Connection establishment is enhanced by performing a retry every second instead of performing a retry
to set up the connection at an interval between 15 and 20 seconds with a backoff timer. A faster retry
occurs only if the system comes online using the fast boot functionality and only for the initial
connection setup (first establishment for each peer). Also, this phenomenon occurs only for a maximum
of 60 retries (approximately 60 seconds with a retry every second). If the peering session is not
established, the behavior for setting up of the connection is the same as the behavior without fast boot
functionality configured.
Faster Local Route Aadvertisements
Local routes from the routing table (RTM) can be injected into BGP using either “redistribute” or “network”
configuration. For remote traffic to reach local destinations faster, these routes need to be injected into
Flex Hash and Optimized Boot-Up
141