Information Technology Reference
In-Depth Information
BGP Read-Only Mode
Originally, when BGP peers came online and accepted prefixes, the path-selection process
would begin running before all the path information had been received from a peer. The
BGP process would begin advertising prefix information to peers based on the outcome of
the decision process. As more path information was received, the outcome from the
decision process for a particular prefix resulted in best-path changes. This in turn resulted
in multiple updates for the same prefix as the best path changed, which was inefficient.
Another similar issue is that the BGP process can begin advertising NLRI with a specific
attribute set, but not all NLRI has been received for that attribute combination. This reduces
the efficiency of the update packing.
This inefficiency can be removed by having a BGP peer remain in read-only mode until it
stops receiving updates. As soon as the full path information has been received from a
remote peer, the decision process can choose the best path for a prefix before sending any
BGP Updates. A BGP peer in read-only mode only receives updates; it doesn't advertise
any prefixes. An upper bound of 2 minutes is placed on a BGP peer remaining in read-only
mode, based on the session initiation.
The addition of read-only mode also allows for optimal update packing. If the BGP router
is sending updates before receiving full path information from all peers, all the NLRI for a
particular attribute combination might not have been received before the BGP router begins
sending updates. After the BGP peer finishes receiving the initial routing information from
a peer, the BGP session changes to read-write mode. This allows the BGP router to run the
decision process and send updates. You can configure the maximum amount of time that
BGP stays in read-only mode using the command
bgp update-delay
RO_Limit
.
RO_Limit
is a limit on how long a BGP peer can remain in read-only mode. The BGP
process automatically leaves read-only mode when it receives a BGP keepalive, which
indicates that the initial routing update has completed. The end of the initial routing update
can be detected because the Cisco BGP implementation sends the entire routing update
before sending a BGP keepalive. The arrival of the first BGP keepalive signals the end of
the initial routing update. As soon as the BGP decision process has completed, the IP
routing table and CEF table are appropriately updated.
Performance Optimization Interdependencies
The convergence tuning described in this section should not be deployed in a piecemeal
fashion. Each aspect is an optimization that builds on other aspects, with many
interdependencies:
•
The foundation for convergence tuning is the peer group feature or, in later versions,
update groups. The update replication behavior greatly increases the amount of BGP
update information a router can generate.
