Convergenza dei Protocolli Link-State: Tuning dei Timer OSPF

In un post precedente ho iniziato a trattare il problema della convergenza dei protocolli di tipo Link-State, ossia OSPF e IS-IS, illustrando gli aspetti generali e i vari meccanismi introdotti negli anni che consentono di raggiungere tempi di convergenza molto, molto esigui (anche dell'ordine delle poche decine di msec).

In questo post cercherò di far luce sul tuning dei timer OSPF, che sono molti, e legati a vari aspetti del protocollo. Per il tuning dei timer IS-IS dovete aver pazienza, fino a quando non uscirà il Capitolo 10 del libro.

In OSPF possiamo distinguere tre tipi di timer:

• Timer associati alla generazione dei LSA.
• Timer associati al processo di flooding.
• Timer associati al ricalcolo dei percorsi ottimi.

Per ciascuna di queste tipologie, cercherò di mettere in luce, oltre al loro significato, anche i valori di best-practice e le configurazioni in ambito Cisco e Juniper.

TIMER ASSOCIATI ALLA GENERAZIONE DEI LSA

I primi due timer associati alla generazione dei LSA non hanno particolare impatto sulla convergenza per cui avrei potuto anche ometterli. Li cito solo per dovere di completezza.

Come noto, ciascun LSA generato da un processo OSPF ha un suo tempo di vita (MaxAge), pari a 60 min (valore costante non configurabile).

Per evitare l’eliminazione dai LSDB degli altri router, ogni router ritrasmette periodicamente tutti i LSA che ha originato (periodo = LSRefreshTime). Nei router Cisco questo periodo è pari a 30 min, ed è variabile solo nell’IOS XR con il comando:

RP/0/RP0/CPU0:router(config)# router ospf process-ID 

RP/0/RP0/CPU0:router(config-ospf)# timers lsa refresh secondi 

Alcuni costruttori, per ridurre la frequenza di rigenerazione dei LSA utilizzano invece un periodo più lungo. Nei router Juniper viene ad esempio utilizzato il valore 50 min, valore che può essere cambiato con il comando:

[edit protocols (ospf | ospf3)]

tt@router# show

lsa-refresh-interval minuti;

La rigenerazione contemporanea di tutti i LSA originati da un router potrebbe però causare problemi ai router adiacenti, che si potrebbero trovare ad elaborare migliaia di LSA contemporaneamente. Per questo, nella prossima sezione vedremo come mettere riparo a questo problema con dei timer che regolano il flusso dei LSA generati da un router.

Il ritardo di generazione di un LSA a fronte di un cambio di topologia (LSA-delay) e l’intervallo minimo tra due generazioni dello stesso LSA (MinLSInterval), sono invece due timer che hanno un forte impatto sulla velocità di convergenza. Infatti, quando un router deve rigenerare il suo LSA a seguito di un evento, non lo invia immediatamente ai router adiacenti, ma aspetta un determinato tempo.

Questo per evitare che l’instabilità di qualche collegamento (link flapping) si traduca in un continuo invio di LSA, sovraccaricando le risorse dei router, portando a fenomeni di instabilità della rete. La RFC 2328 ha introdotto il timer MinLSInterval, che fissa l’intervallo minimo tra due generazioni dello stesso LSA, consigliando un valore di 5 s (NOTA: due LSA dello stesso tipo sono considerati identici, se hanno identici Link State ID e Advertising Router). 

Le implementazioni più moderne di OSPF utilizzano un approccio dinamico nella regolazione dei due timer, cercando di bilanciare le due esigenze contrastanti di velocità di convergenza e stabilità. L’idea di fondo è di utilizzare valori inizialmente molto piccoli, cercando di incrementarli all’aumentare della frequenza degli eventi che comportano la rigenerazione del LSA. 

Per minimizzare l’influenza negativa sulla velocità di convergenza, e nel contempo assicurare la stabilità della rete, nelle versioni più recenti dell’IOS, IOS XE e IOS XR Cisco, i due timer possono essere configurati dinamicamente attraverso un algoritmo di Exponential Backoff, che richiede tre sub-timer (NOTA : i trigger sono segnali legati a un cambio di topologia della rete, ad esempio, caduta di un collegamento, cambio di una metrica, ecc.): 

• Start-Interval: è il tempo iniziale che intercorre tra la ricezione di un trigger e la generazione del nuovo LSA (LSA-delay).
• Hold-interval: è il tempo minimo che intercorre tra Start-Interval e la successiva generazione di un nuovo LSA.
• Max-interval: è il massimo valore permesso del timer MinLSInterval.

Gli intervalli tra generazioni successive di LSA originati dal router, vengono sempre raddoppiati fino ad arrivare al valore massimo Max-interval. La figura seguente riporta l’evoluzione temporale dell’algoritmo di Exponential Backoff, con i seguenti parametri: Start-Interval = 1; Hold-interval = 5; Max-interval = 30. (NOTA: nell’implementazione IOS, trascorsi due intervalli pari a Max-interval senza la ricezione di trigger, l’algoritmo riparte dall’inizio, mentre nell’implementazione IOS XR l’algoritmo riparte dall’inizio subito dopo un intervallo pari a Max-interval.)

La configurazione dell’algoritmo di Exponential Backoff per i timer LSA-delay e MinLSInterval avviene tramite il comando seguente, identico per tutti i tipi di IOS:

(config)# router ospf process-ID

(config-router)# timers throttle lsa all start-int hold-int max-int

dove i tre sub-timer Start-Interval (start-int), Hold-interval (hold-int) e Maximum-interval (max-int), sono tutti espressi in msec. Nell’IOS XR, il meccanismo di Exponential Backoff è sempre attivo; è possibile solo variarne i parametri, ed eventualmente ritornare ai parametri di default con il comando "no timers throttle lsa all". I valori di default sono diversi tra l’IOS e l’IOS XR e sono i seguenti:

• IOS : 0, 5000, 5000
• IOS XR : 50, 200, 5000

In entrambi i casi il valore di Maximum-interval è posto a 5.000 msec (= 5 sec), ossia il valore consigliato dalla RFC 2328.

I valori dei tre sub-timer hanno un impatto importante sulla velocità di convergenza di OSPF, per cui è bene pianificarli con cura. Il valore start-int può essere posto a valori molto piccoli senza alcun problema, ad esempio a 0 o 1 msec.  Il valore hold-int, in funzione di quanto si vuole essere conservativi, può essere posto da 20 msec a un valore pari al tempo medio di esecuzione dell’algoritmo SPF. In ogni caso dovrebbe essere sempre leggermente superiore al timer MinLSArrival dei router adiacenti (vedi la prossima sezione per il perché). Poiché quest’ultimo è di default pari a 1.000 msec nell’IOS/IOS XE e 100 msec nell’IOS XR, un valore possibile per hold-int potrebbe essere 1.020-1.030 msec nell’IOS/IOS XE e 120-150 msec nell’IOS XR. In assenza di problemi di interoperabilità con router di altri costruttori, questi valori potrebbero essere abbassati fino a poche decine di msec. Infine, max-int può essere lasciato al valore di default in assenza di Exponential Backoff, che è pari a 5.000 msec.

L'approccio seguito dal Junos nella gestione di questi timer è diverso. L’intervallo minimo tra due generazioni dello stesso LSA, a differenza dei router Cisco, non è configurabile (a volte, avere la possibilità di variare dei timer è molto buono, ma quando variarli non serve, è ancor più buono non avere la possibilità di farlo !!!). I router Juniper implementano per questo timer, un algoritmo simile all’Exponential Backoff Cisco, con timer predefiniti non configurabili. Questo algoritmo è identico a quello utilizzato per la gestione del SPF-delay che sarà visto nella sezione dedicata a questo timer. 

TIMER ASSOCIATI AL PROCESSO DI FLOODING

Un aspetto importante nel controllo del processo di flooding dei LSA, riguarda la ritrasmissione di un LSA causata dalla mancata ricezione di un messaggio LSack. 

Il protocollo OSPF, per aumentare il grado di affidabilità del processo di flooding, una volta inviato un LSA fa partire il timer RxmtInterval. Se alla scadenza di questo timer il processo OSPF non ha ancora ricevuto un riscontro (acknowledge) attraverso un messaggio LSack, il LSA viene ritrasmesso. Il modo con cui OSPF esegue questa operazione,è quello di copiare il LSA trasmesso in una Retransmit List. Se il LSack viene ricevuto prima della scadenza del timer RxmtInterval, il LSA trasmesso viene cancellato dalla Retransmit List. Viceversa, il LSA viene ritrasmesso e il timer RxmtInterval viene reinizializzato. Nel frattempo il LSA permane nella Retransmit List. 

Il timer InfTransDelay è invece una stima del tempo impiegato da un LSA per attraversare un router. Viene utilizzato per incrementare l’età del LSA, per tener conto del tempo di attraversamento della rete. Quando un LSA viene inviato dal router che lo origina, avrà il campo LS Age nell’intestazione del LSA, posto al valore 0. Nel momento in cui viene trasmesso, il campo LS Age viene aumentato di un tempo pari a InfTransDelay. Quando il LSA, durante il processo di flooding, transita attraverso un router, questi prima di inviarlo sull’interfaccia di uscita, allo stesso modo aumenta il valore di LS Age di un tempo pari a InfTransDelay. Di default i router Cisco utilizzano come valore del timer InfTransDelay 1 sec. Così, ad esempio, se un LSA generato da un ipotetico router A, attraversa un router B prima di raggiungere un ipotetico router C, quest’ultimo riceverà il LSA con LS Age aumentato di 2 sec (1 sec incrementato dal router A e 1 sec incrementato dal router B). L’aggiornamento del LS Age è necessario per tener conto del tempo trascorso tra la trasmissione del LSA e la sua ricezione.

I comandi dell'IOS Cisco tramite i quali è possibile variare i due timer RxmtInterval e InfTransDelay sono i seguenti:

IOS e IOS XE

router(config)# interface tipo numero 

router(config-if)# ip ospf retransmit-interval secondi

router(config-if)# ip ospf transmit-delay secondi

IOS XR

RP/0/RP0/CPU0:router(config)# router ospf process-ID 

RP/0/RP0/CPU0:router(config-ospf)# area area-ID

RP/0/RP0/CPU0:router(config-ospf-ar)# interface tipo numero 

RP/0/RP0/CPU0:router(config-ospf-ar-if)# retransmit-interval secondi

RP/0/RP0/CPU0:router(config-ospf-ar-if)# transmit-delay secondi

Come best-practice comunque, i valori di default sono sufficienti nelle applicazioni pratiche.

In OSPF, come in generale nei protocolli di routing Link-State, è importante, per non sovraccaricare le CPU e quindi rendere la rete più stabile, regolare il flusso di LSU che un router invia ai router adiacenti. Purtroppo OSPF, a differenza di altri protocolli, come ad esempio il TCP, non implementa meccanismi di controllo di flusso di tipo feed-back, ossia basati su un segnale di congestione da parte di un ricevitore. Per sopperire a questa mancanza, vengono utilizzati meccanismi di tipo feed-forward, basati su una regolazione “a priori” del flusso di LSU inviati. 

Le moderne implementazioni di OSPF adottano una serie di meccanismi configurabili, che consentono di rallentare opportunamente il flusso di LSU inviati. È bene che il lettore si renda conto che rallentare il flusso di LSU, in condizioni critiche transitorie di burst di LSU, è l’unica opzione disponibile che un router ha per non sovraccaricare i router adiacenti. Sono due i flussi che è possibile rallentare:

• Frequenza globale di LSU in uscita da una interfaccia: viene regolata configurando un valore minimo dell’intervallo tra due qualsiasi LSU emessi.
• Frequenza dei LSU ritrasmessi: viene regolata configurando un valore minimo dell’intervallo tra due LSU ritrasmessi da parte di un router.

Inoltre è possibile ottimizzare il refresh dei LSA, utilizzando un meccanismo di packing efficiente dei LSA in messaggi LSU. I valori di default messi a disposizione dai costruttori di apparati sono di norma sufficienti a garantire un funzionamento stabile della rete, per cui andrebbero variati solo in casi eccezionali e a fronte di uno studio sui costi/benefici che una variazione comporta.

OTTIMIZZAZIONE DEL REFRESH DEI LSA

Nelle vecchie release dell’IOS, la ritrasmissione periodica dei LSA avveniva ogni 30 min, attraverso un processo di scanning del LSDB. Alla scadenza dei 30 min, tutti i LSA generati dal router venivano ritrasmessi. Purtroppo, benché semplice, questo metodo non è molto efficiente poiché i LSA vengono inviati in burst, intervallati da lunghi periodi di «quiete», come illustrato nel grafico seguente (refresh sincronizzato):

L’unico vantaggio è la possibilità di minimizzare il numero di LSU necessari, grazie alla possibilità di effettuare un packing ottimale dei LSA. Anche l’implementazione di refresh individuali non è efficiente, come a prima vista potrebbe sembrare, poiché richiede la trasmissione di molti LSU. Questo è vero a maggior ragione in OSPF, dove ciascun LSU trasporta uno o al più pochi LSA.

Una soluzione intermedia tra i refresh sincronizzati ed individuali, è il refresh a gruppi. Se invece di trasmettere immediatamente un LSA quando il suo LSRefreshTime scade, la trasmissione venisse ritardata per un certo tempo, sarebbe possibile trasmettere contemporaneamente tutti i LSA il cui LSRefreshTime scade durante questo tempo, utilizzando pochi LSU.

L’idea del refresh a gruppi è riportata nella figura sopra. Definendo, via configurazione, un tempo inferiore al LSRefreshTime, è possibile trasmettere tutti i LSA che hanno un LSRefreshTime inferiore al valore configurato, tramite uno o al più pochi LSU. Ad esempio, si supponga di scegliere il periodo dei refresh a gruppi pari a 4 min. Tutti i LSA che nell’intervallo [a, a + 4 min] , con a=0, 4, 8, ... , avranno il loro LSRefreshTime in scadenza, ossia tutti i LSA che hanno età corrente superiore a 26 min verranno trasmessi in un unico LSU. È bene precisare che l’implementazione del refresh a gruppi non cambia il valore di LSRefreshTime di default.

Il comando per la definizione del periodo del refresh a gruppi è il seguente (identico per l’IOS, IOS XE e IOS XR): 

(config)# router ospf process-ID

(config-router)# timers pacing lsa-group secondi

Il valore di default è 240 sec (= 4 min). Si noti che come best-practice, il valore di default è più che sufficiente per tutte le applicazioni pratiche. Non vi sono linee guida per il suo tuning, per cui prima di prendere qualsiasi decisione è opportuno valutarla con cura ed eventualmente esplorare anche altre strade per ridurre il flusso di LSA, come ad esempio:

• L’aggregazione dei prefissi interni o redistribuiti, che riduce notevolmente il numero di LSA di tipo 3 e 5.
• La definizione delle aree come stub/totally stubby/NSSA/totally NSSA, che consente di ridurre notevolmente il numero di LSA sempre di tipo 3 e/o 5, e in misura minore anche 4 (in misura minore solo perché sono pochi !).
• Il tuning delle code di trasmissione (scheduling e buffering).

In ogni caso, l’importanza di questo timer è direttamente proporzionale al numero di LSA presenti nel LSDB. Ad esempio se un LSDB contiene 10.000 LSA, diminuire il periodo dei refresh a gruppi porta a un beneficio. Viceversa, per un LSDB con pochi LSA (diciamo intorno al centinaio), il beneficio non è sensibile.

Il JUNOS non ha un comando simile e non consente quindi la regolazione del periodo di refresh a gruppi (o almeno, nella documentazione JUNOS non si trova niente al riguardo). Probabilmente, come spesso accade nel JUNOS, l'ottimizzazione del refresh dei LSA utilizza un algoritmo interno con timer "hard-coded".

REGOLAZIONE DELLA FREQUENZA GLOBALE DEI LSU 

La frequenza globale di LSU in uscita da una interfaccia, se non controllata, può provocare una eccessiva occupazione dei buffer e sovraccarico della CPU dei router adiacenti, a causa della trasmissione di un elevato numero di messaggi LSU consecutivi.

La frequenza dei LSU inviati da un router su ciascuna adiacenza, viene regolata imponendo un tempo minimo tra l’invio di due (qualsiasi) LSU consecutivi. La regolazione è possibile tramite il comando "timers pacing flood msec", riportato nella figura seguente: 

Il valore di default, nell’IOS, IOS XE e IOS XR è 33 msec, pari a circa 30 LSU/s.

Allo stesso modo, è possibile imporre un tempo minimo tra l’invio di due LSU consecutivi presenti nella coda di ritrasmissione, ossia nella coda dove sono presenti LSU che contengono LSA che non hanno ancora ricevuto un LSack. La regolazione dell’invio dei LSU ritrasmessi è possibile solo nell’IOS e IOS XE, tramite il comando "timers pacing retransmission msec" riportato nella figura sopra. Il valore di default è 66 ms, pari a circa 15 LSU/s. Nell’IOS XR questo timer non è configurabile ma viene posto al doppio del valore del Pacing flood (default = 2x33 = 66 msec).

È anche possibile porre un limite alla frequenza con cui un processo OSPF elabora lo stesso LSA ricevuto dai router adiacenti, con i comandi seguenti (NOTA: ricordo che due LSA dello stesso tipo sono considerati identici se hanno identico Link State ID e Advertising Router):

• IOS : "timers lsa arrival msec".
• IOS XR : "timers lsa min-arrival msec". 

che specificano il tempo minimo che deve intercorrere tra due elaborazioni dello stesso LSA (MinLSArrival). Il valore di default è 1.000 msec nell’IOS e 100 msec nell’IOS XR.

Si noti che come best-practice, i valori di default dei timer specificati in questa sezione, sono più che sufficienti per tutte le applicazioni pratiche. Vale per questi timer quanto detto nella sezione precedente, ossia prima di prendere qualsiasi decisione è opportuno valutarla con cura ed eventualmente esplorare anche altre strade per ridurre il flusso di LSA. Ad esempio, quando si valuta il limite da porre alla frequenza con cui un processo OSPF elabora lo stesso LSA ricevuto dai router adiacenti, è importante tener conto dei valori impostati nel meccanismo di Exponential Backoff per il timer MinLSinterval. Infatti, se ad esempio si consentisse a un router di inviare due istanze dello stesso LSA, in un tempo inferiore al valore definito dal comando "timers lsa arrival msec" su un router adiacente, si correrebbe il rischio che il router che riceve i LSA, scarti il secondo. Questo comporterebbe la ritrasmissione del secondo LSA, con un impatto negativo sulla velocità di convergenza.

TIMER ASSOCIATI ALL’ALGORITMO SPF 

La determinazione dell’albero dei percorsi ottimi è forse il processo più laborioso a cui sono sottoposte le CPU dei router. Per limitare il numero di applicazioni dell’algoritmo SPF, questo non viene applicato immediatamente all’arrivo di un nuovo LSA, o di un LSA aggiornato, perché nel frattempo potrebbero arrivarne altri. Quindi, il ritardo nell’applicazione dell’algoritmo SPF (SPF-delay), permette di risparmiare il numero di ricalcoli dei percorsi ottimi, rendendo la rete più stabile.

Ad esempio, a seguito del fuori servizio di un collegamento punto-punto, i due router agli

estremi rilevano la perdita dell’adiacenza, e quindi generano entrambi un nuovo LSA (di tipo 1). I due LSA aggiornati, vengono inviati via flooding a tutti gli altri router, seguendo le note regole di propagazione. Così, ogni router riceve due LSA aggiornati, relativi alla stessa adiacenza. Se alla ,del primo, un router ricalcolasse immediatamente l’albero dei cammini minimi, sarebbe costretto a rifare la stessa operazione una seconda volta (inutilmente, poiché porterebbe esattamente allo stesso risultato della precedente !) alla ricezione del secondo LSA. 

La scelta di ritardare l’applicazione dell’algoritmo SPF, può essere considerata come un meccanismo di auto-protezione, che permette di evitare il sovraccarico della CPU del router. Il rovescio della medaglia è che il router aumenta la sua velocità di risposta ai cambi di topologia della rete (a seguito di fuori servizio di collegamenti, cambio di metriche, ecc.), e ciò si traduce in un aumento del tempo di convergenza del protocollo di routing. 

Tutto questo da luogo a quesiti molto importanti, del tipo: “Quanto breve dovrebbe essere il ritardo, affinché il tempo di convergenza non ne risenta eccessivamente ?”, e viceversa: “Quanto lungo dovrebbe essere il ritardo, affinché la rete rimanga il più stabile possibile ?”; e infine “Quale è un valore ottimo per il ritardo ?”. 

Sfortunatamente non c’è un valore universale valido in tutte le situazioni. Questa è la ragione per cui, tutte le implementazioni di OSPF prevedono un ritardo iniziale di applicazione dell’algoritmo SPF configurabile. In passato il ritardo era una costante (configurabile), generalmente posta pari a 5 sec, ma questo portava a un aumento troppo elevato dei tempi di convergenza. Recentemente, le varie implementazioni hanno introdotto dei meccanismi di tipo Exponential Backoff simili a quello descritto per il timer MinLSInterval.

Nelle varie versioni dell'IOS Cisco, l’algoritmo di Exponential Backoff è basato sui tre sub-timer spf-start, spf-hold espf-max-wait, il cui significato è riportato nella figura seguente:

Nei router Cisco la configurazione del SPF-delay avviene tramite il comando seguente (identico per l’IOS, IOS XE e IOS XR):

(config)# router ospf process-ID

(config-router)# timers throttle spf spf-start spf-hold spf-max-wait

dove i tre sub-timer spf-start, spf-hold e spf-max-wait, sono tutti espressi in msec. 

L’implementazione IOS non ha valori di default in quanto il meccanismo di Exponential Backoff non è abilitato di default. Per contro, nell’IOS XR, il meccanismo di Exponential Backoff per il timer SPF-delay è sempre attivo; è possibile solo variarne i parametri, ed eventualmente ritornare ai parametri di default con il comando "no timers throttle spf". I valori di default utilizzati dall'IOS XR sono i seguenti: 50, 200, 5000.

I valori dei tre timer hanno un impatto importante sulla velocità di convergenza di OSPF, per cui è bene pianificarli con cura. Ma come scegliere i valori ? Nella pratica tutto va valutato sulla base della grandezza della rete e le piattaforme a disposizione. Qualche regola generale è comunque possibile. 

Il valore di spf-start dovrebbe essere abbastanza piccolo in modo da velocizzare la convergenza. Per contro, dovrebbe essere sufficientemente grande da consentire il flooding dei LSA ricevuti, prima del ricalcolo dei percorsi ottimi. Non è semplice determinare il ritardo nella trasmissione dei LSA, ma un valore di riferimento esiste: il valore del timer Pacing flood, che pone un limite inferiore tra la trasmissione di due LSA. Porre il timer Pacing flood al suo valore di default di 33 msec e il valore di spf-start a 100 msec, potrebbe essere una buona soluzione.

Dopo il ricalcolo iniziale, l’algoritmo SPF non dovrebbe essere eseguito per almeno il tempo convergenza della rete dopo l’evento iniziale. Ciò significa che il valore di spf-hold dovrebbe essere più alto della somma "spf-start + SPF_Runtime + RIB_FIB_Update_Time". Un valore di 150 msec è in genere sufficiente per le applicazioni pratiche.

Infine, per il valore spf-max-wait è possibile utilizzare il valore di default in assenza del meccanismo di Exponential Backoff, pari a 5.000 msec.

L’approccio seguito dai router Juniper per regolare la frequenza dei ricalcoli dell’algoritmo SPF, è diverso da quello implementato nei router Cisco. I router Juniper permettono un certo numero configurabile di ricalcoli “veloci” (rapid runs), distanziati tra loro da un intervallo configurabile (delay, dell’ordine del centinaio di msec), e quindi successivi ricalcoli distanziati di un valore configurabile (holddown, dell’ordine di pochi secondi). Trascorso un periodo pari al valore holddown senza ricalcoli, il meccanismo viene azzerato e riparte con i ricalcoli “veloci”. Le tre quantità configurabili che regolano il meccanismo possono essere fissate tramite la seguente configurazione:

[edit protocols ospf]

user@router# show

spf-options {

  delay ritardo-in-msec;

  holddown holddown-in-msec;

  rapid-runs numero;

}

dove i valori di default sono i seguenti: delay = 200 msec, holddown = 5.000 msec, rapid-runs = 3. 

DALLA TEORIA ALLA PRATICA ...

Per concludere questa parte sul tuning dei vari timer dell’OSPF, riporto di seguito i timer configurati su un router di transito Cisco CRS-16/S di una rete in produzione di un noto ISP, e nei router CRS-4/S della rete di backbone di una grande azienda Enterprise. 

Rete ISP

RP/0/RP0/CPU0:router(config)# router ospf process-ID 

RP/0/RP0/CPU0:router(config-ospf)# timers throttle lsa all 1 1020 5000

RP/0/RP0/CPU0:router(config-ospf)# timers throttle spf 150 150 5000

Rete Enterprise

RP/0/RP0/CPU0:router(config)# router ospf process-ID 

RP/0/RP0/CPU0:router(config-ospf)# timers throttle lsa all 0 150 5000

RP/0/RP0/CPU0:router(config-ospf)# timers throttle spf 130 150 5000

RP/0/RP0/CPU0:router(config-ospf)# timers lsa min-arrival 100

RP/0/RP0/CPU0:router(config-ospf)# timers pacing flood 15

Come si può notare, gli unici timer che hanno una configurazione diversa da quella di default, sono LSA-delay,MinLSInterval e il SPF-delay, implementati con il meccanismo di Exponential Backoff. Inoltre, nella configurazione adottata nella rete Enterprise, anche il valore di "timers pacing flood" è diverso da quello di default (15 contro 33 msec).

È interessante notare i valori 1.020 msec e 150 msec del sub-timer hold-int, nel comando "timers throttle lsa all". Come visto in precedenza, il valore hold-int deve essere superiore al MinLSArrival, che di default nell’IOS XR è 100 msec, per cui il valore 1.020 msec utilizzato dall’ISP potrebbe essere abbassato notevolmente. In realtà, credo che il valore 1.020 sia frutto di un "copia-incolla" nel passaggio da piattaforme GSR 12k (basate su IOS), che avevano MinLSArrival di default pari a 1 sec, a piattaforme CRS che invece hanno MinLSArrival di default pari a 100 msec. Morale della favola, il "copia-incolla" delle configurazioni va comunque sempre valutato bene.

CONCLUSIONI

C'era una volta una certa lentezza dei protocolli Link-State a convergere. Con l'introduzione di nuovi meccanismi di gestione dei timer, insieme a meccanismi di rilevazione veloce di perdita di una adiacenza (carrier delay, BFD), è oggi possibile raggiungere tempi di convergenza dell'ordine delle poche centinaia di msec. Sempre che la rete sia stata progettata "cum grano salis" ...