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 Cap. 10 del libro (che ho già in realtà scritto).

In OSPF possiamo distinguere tre tipi di timer:

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.
 

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.): 

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 medio del tempo 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 LSP, 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. 

 

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, lo stesso 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:

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.

 

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:

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, ad 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 (NOTA: ricordo che due LSA dello stesso tipo sono considerati identici se hanno identico Link State ID e Advertising Router):

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.

 

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 e spf-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, come visto nella diapositiva precedente, 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 dovrebbe essere 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:

 

user@router# show

     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.  

 

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)# rou