10. BGP Timers (Timer BGP)
- BGP Timers (Timer BGP)
BGP impiega cinque timer: ConnectRetryTimer (vedere Sezione 8), HoldTimer (vedere Sezione 4.2), KeepaliveTimer (vedere Sezione 8), MinASOriginationIntervalTimer (vedere Sezione 9.2.1.2) e MinRouteAdvertisementIntervalTimer (vedere Sezione 9.2.1.1).
Due timer opzionali possono (MAY) essere supportati: DelayOpenTimer, IdleHoldTimer da BGP (vedere Sezione 8). La Sezione 8 descrive il loro utilizzo. Il funzionamento completo di questi timer opzionali è al di fuori dell'ambito di questo documento.
ConnectRetryTime è un attributo FSM obbligatorio che memorizza il valore iniziale per il ConnectRetryTimer. Il valore predefinito suggerito per ConnectRetryTime è 120 secondi.
HoldTime è un attributo FSM obbligatorio che memorizza il valore iniziale per l'HoldTimer. Il valore predefinito suggerito per l'HoldTime è 90 secondi.
Durante alcune parti della macchina a stati (vedere Sezione 8), l'HoldTimer è impostato su un valore elevato. Il valore predefinito suggerito per questo valore elevato è 4 minuti.
Il KeepaliveTime è un attributo FSM obbligatorio che memorizza il valore iniziale per il KeepaliveTimer. Il valore predefinito suggerito per il KeepaliveTime è 1/3 dell'HoldTime.
Il valore predefinito suggerito per il MinASOriginationIntervalTimer è 15 secondi.
Il valore predefinito suggerito per il MinRouteAdvertisementIntervalTimer sulle connessioni EBGP è 30 secondi.
Il valore predefinito suggerito per il MinRouteAdvertisementIntervalTimer sulle connessioni IBGP è 5 secondi.
Un'implementazione di BGP deve (MUST) consentire che l'HoldTimer sia configurabile per singolo peer, e può (MAY) consentire che gli altri timer siano configurabili.
Per ridurre al minimo la probabilità che la distribuzione dei messaggi BGP da parte di un dato BGP speaker contenga picchi, dovrebbe (SHOULD) essere applicato jitter ai timer associati a MinASOriginationIntervalTimer, KeepaliveTimer, MinRouteAdvertisementIntervalTimer e ConnectRetryTimer. Un dato BGP speaker può (MAY) applicare lo stesso jitter a ciascuna di queste quantità, indipendentemente dalle destinazioni a cui vengono inviate le aggiornamenti; cioè, il jitter non deve essere configurato per singolo peer.
La quantità predefinita suggerita di jitter deve (SHALL) essere determinata moltiplicando il valore base del timer appropriato per un fattore casuale, che è uniformemente distribuito nell'intervallo da 0,75 a 1,0. Un nuovo valore casuale dovrebbe (SHOULD) essere scelto ogni volta che il timer viene impostato. L'intervallo del valore casuale del jitter può (MAY) essere configurabile.