diff options
author | Donald Sharp <sharpd@cumulusnetworks.com> | 2015-05-20 02:40:33 +0200 |
---|---|---|
committer | Donald Sharp <sharpd@cumulusnetworks.com> | 2015-05-20 02:40:33 +0200 |
commit | f188f2c424e8cf37517e68c09ca93329aa4297aa (patch) | |
tree | 645f84ac58504781ccbb89af8f4c5874e3d24052 /doc | |
parent | bgpd: bgpd-restart-bit-fix.patch (diff) | |
download | frr-f188f2c424e8cf37517e68c09ca93329aa4297aa.tar.xz frr-f188f2c424e8cf37517e68c09ca93329aa4297aa.zip |
bgpd: bgpd-update-delay.patch
COMMAND:
'update-delay <max-delay in seconds> [<establish-wait in seconds>]'
DESCRIPTION:
This feature is used to enable read-only mode on BGP process restart or when
BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode
would begin as soon as the first peer reaches Established state and a timer
for <max-delay> seconds is started.
During this mode BGP doesn't run any best-path or generate any updates to its
peers. This mode continues until:
1. All the configured peers, except the shutdown peers, have sent explicit EOR
(End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
Established is considered an implicit-EOR.
If the <establish-wait> optional value is given, then BGP will wait for
peers to reach establish from the begining of the update-delay till the
establish-wait period is over, i.e. the minimum set of established peers for
which EOR is expected would be peers established during the establish-wait
window, not necessarily all the configured neighbors.
2. max-delay period is over.
On hitting any of the above two conditions, BGP resumes the decision process
and generates updates to its peers.
Default <max-delay> is 0, i.e. the feature is off by default.
This feature can be useful in reducing CPU/network used as BGP restarts/clears.
Particularly useful in the topologies where BGP learns a prefix from many peers.
Intermediate bestpaths are possible for the same prefix as peers get established
and start receiving updates at different times. This feature should offer a
value-add if the network has a high number of such prefixes.
IMPLEMENTATION OBJECTIVES:
Given this is an optional feature, minimized the code-churn. Used existing
constructs wherever possible (existing queue-plug/unplug were used to achieve
delay and resume of best-paths/update-generation). As a result, no new
data-structure(s) had to be defined and allocated. When the feature is disabled,
the new node is not exercised for the most part.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Dinesh Dutt <ddutt@cumulusnetworks.com>
Diffstat (limited to 'doc')
-rw-r--r-- | doc/bgpd.texi | 24 |
1 files changed, 24 insertions, 0 deletions
diff --git a/doc/bgpd.texi b/doc/bgpd.texi index de709707a..10fe13ca2 100644 --- a/doc/bgpd.texi +++ b/doc/bgpd.texi @@ -223,6 +223,30 @@ Redistribute RIP route to BGP process. Redistribute OSPF route to BGP process. @end deffn +@deffn {BGP} {update-delay @var{max-delay}} {} +@deffnx {BGP} {update-delay @var{max-delay} @var{establish-wait}} {} +This feature is used to enable read-only mode on BGP process restart or when +BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode +would begin as soon as the first peer reaches Established status and a timer +for max-delay seconds is started. + +During this mode BGP doesn't run any best-path or generate any updates to its +peers. This mode continues until: +1. All the configured peers, except the shutdown peers, have sent explicit EOR +(End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached +Established is considered an implicit-EOR. + If the establish-wait optional value is given, then BGP will wait for + peers to reach established from the begining of the update-delay till the + establish-wait period is over, i.e. the minimum set of established peers for + which EOR is expected would be peers established during the establish-wait + window, not necessarily all the configured neighbors. +2. max-delay period is over. +On hitting any of the above two conditions, BGP resumes the decision process +and generates updates to its peers. + +Default max-delay is 0, i.e. the feature is off by default. +@end deffn + @node BGP Peer @section BGP Peer |