Addendum

BGP as quickly as possible and then advertised to peers as soon as the peering is established. This
rapidness in the transmission of routes is essential when BGP GR is not used because the peers will not
have the routes from the restarting ToR. The following design modifications have been performed:
Poll for routes corresponding to “networks” every 3 seconds for the first 20 seconds after BGP starts.
After that, revert to the usual FTOS behavior of checking every 30 seconds. When doing faster polling,
only poll for networks that are not already injected.
Process redistributed routes from RTM every 1 second for the first 20 seconds after BGP starts. After that
period, processing of routes occurs every 10 seconds.
To ensure that the local routes are advertised to peers quickly, any configured (or default) neighbor
advertisement interval will not be enforced for the first 60 seconds after a peering is established.
Delayed Installation of ECMP Routes Into BGP
The current FIB component of FTOS has some inherent inefficiency when handling a large number of
ECMP routes (i.e., routes with multiple equal-cost next hops). To circumvent this, for the specific target
configuration for Fastboot, changes are made in BGP to delay the install of ECMP routes. This is done
only if the system comes up through a fastboot reload. The BGP route selection algorithm only selects
one best path to each destination and delays install of additional ECMP paths until a minimum of 30s
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.
Changes for BGP Graceful Restart Processes
If BGP Graceful Restart is enabled between the restarting ToR and any adjacent peer, the ToR can take
advantage of it and trigger the peer to retain the routes advertised by the ToR even if it goes down. The
following enhancements have been made:
1. To trigger the peer router to go into the role of a GR Helper router, the BGP code registers for and
receives a notification of operator-initiated fastboot reload. Upon getting this notification, BGP will
initiate a TCP close towards every neighbor with whom GR has been negotiated which should cause
the peer to transition to the role of a GR Helper. Note that without this change, the peer would
detect a change either upon a Hold timeout or when the link to the ToR goes down and neither
event would trigger any BGP GR actions on the peer.
2. Upon BGP starting up, if it determines that the system has come up through fastboot, the R-bit and
F-bit (Restarting bit and Forwarding bit) are set in the GR capability exchanged with GR-enabled
peers. This behavior notifies the peer that the restarting ToR has preserved the forwarding state and
ensures that the peer continues to retain the routes previously advertised by the ToR.
3. For all peers that have been established with GR-enabled after a fastboot, the End-of-RIB is delayed
by 60 seconds (from the time of establishment of the first peer). This is done to ensure that the ToR
would have advertised all its local routes to the peer before sending the EoR.
Operation of LACP
A set of optimizations has been implemented in LACP to speed up the aggregation of ports. However, for
these changes to produce a material effect, the peer router also has to behave in an expedient manner
(for example, support the same changes). Therefore, these changes may result in maximum benefits
when all switches involved are Dell and run the Yakima release.
142
Flex Hash and Optimized Boot-Up