Administrator Guide

1326 BGP
Limiting Phase 2 CPU Usage
In a network with a large number of prefixes, phase 2 of the decision process
can consume a significant amount of time. If the BGP hold timers are
configured to be shorter than the duration of the decision process, the timers
can expire causing a loss of adjacency. If the decision process runs frequently,
it may consume significant CPU resources, starving other processes. Two
mechanisms mitigate these potential issues. First, a hold timer prevents phase
2 from running too often. The hold time is explained in more detail in the
next paragraph. Second, phase 2 is limited to running no more than
approximately one second without yielding to other tasks.
When an event triggers phase 2, a short delay (usually 100 ms) is imposed
before the decision process runs. This delay allows other RIB changes to
complete before computing new routes. When the trigger occurs, if the
decision process was previously run within the hold time, the next decision
process is scheduled to run after the hold time expires. The initial hold time is
one second. Each time one or more new triggers occur while the hold timer is
running, the hold timer is doubled, up to a maximum of 4 seconds. When the
hold timer expires without BGP receiving a new phase 2 trigger, the hold time
is reset to the minimum hold time.
Path Attributes
Dell Networking supports all path attributes described in RFC 4271.
Dell Networking BGP sets the ORIGIN path attribute to IGP for routes
originated through the network command and to INCOMPLETE for routes
originated through route redistribution. Dell Networking BGP never sets the
ORIGIN path attribute to EGP.
Dell Networking BGP sets the AS_PATH path attribute in compliance with
RFC 4271. Dell Networking BGP does require that paths from external peers
include the configured AS number of the peer as the first AS in the path. Dell
Networking BGP enforces a configurable limit to the length of the AS_PATH
attribute in received paths. Paths that exceed the limit are discarded.
Dell Networking BGP offers a configuration option (neighbor next-hop-self)
to set the NEXT_HOP attribute to a local IP address when sending an
UPDATE message to an internal peer. Otherwise, Dell Networking BGP
follows the guidance in RFC 4271 when sending to internal peers. When
sending an UPDATE message to an external peer, Dell Networking BGP
retains the NEXT_HOP address if it is an address on the subnet used to