Etichetta per VRF o per prefisso? La vera bolletta della capacità

Due progetti annunciano lo stesso prefisso cliente nella stessa core del provider. Uno assegna un’etichetta per prefisso, l’altro assegna un’unica etichetta per l’intero VRF, e il secondo sembra più economico su ogni slide. Il numero di etichette è reale, ma non è il budget che di solito si esaurisce per primo. Scegliere tra i due significa contare quattro risorse, non una, e le etichette sono la più piccola tra loro.

La scelta dipende anche da ciò che il router di uscita deve fare con il pacchetto dopo aver rimosso l’etichetta. È quella differenza funzionale, non l’aritmetica delle etichette, a dover guidare la decisione.

Cosa risparmia davvero ogni allocazione

Un’allocazione per prefisso porta l’informazione di inoltro nell’etichetta. Il router di uscita può inviare il pacchetto direttamente all’adiacenza giusta senza una ricerca di destinazione, ed è per questo che scala bene con grandi insiemi di rotte VRF e che consuma un’etichetta per ogni prefisso annunciato in ogni VRF. Un’allocazione per VRF, come Junos vrf-table-label, annuncia un’etichetta per istanza di routing e usa quell’etichetta per selezionare la tabella VRF; il router esegue poi una ricerca IP dentro la tabella.

È una vera differenza architetturale, non una manopola di tuning. L’etichettatura per VRF offre uno spazio di etichette più piccolo e un annuncio delle etichette più semplice, al costo di una ricerca e di un’etichetta che non dice nulla sulla destinazione. L’etichettatura per prefisso dà alla scheda di linea di uscita più informazioni in anticipo e costa etichette in proporzione alle rotte trasportate.

Il registro delle etichette è quello piccolo

Le etichette MPLS sono finite, ma lo spazio delle etichette è abbastanza grande perché i provider ordinari non lo esauriscano con qualche migliaio di prefissi. Dove l’etichettatura per VRF aiuta davvero è sulle piattaforme con piccole tabelle hardware delle etichette, o in progetti in cui un solo VRF trasporta un feed Internet completo e le etichette per prefisso moltiplicherebbero la domanda di etichette per il numero di rotte. Sono vincoli reali, e sono il motivo per cui la funzione esiste. Nessuno di essi riguarda il numero di prefissi nella tabella.

Contate le etichette sia per il servizio sia per il trasporto prima di scegliere. Un progetto per VRF ha comunque bisogno di etichette di trasporto per i loopback e per ogni salto del percorso, e ha comunque bisogno dello stato di adiacenza. Se il brief di progetto conta solo le etichette di servizio, il risparmio viene misurato sul registro sbagliato.

I feed di rotte costano memoria prima delle etichette

Ogni percorso ricevuto consuma memoria del piano di controllo, elaborazione degli aggiornamenti e tempo di convergenza, che il VRF usi una o diecimila etichette. Un feed Internet completo dentro un VRF costa per i percorsi BGP, la RIB, le voci FIB e il trambusto dietro di essi, non per l’etichetta che sta davanti alla tabella. Lo stesso feed aumenta anche il raggio d’impatto di una fuga di rotte o di un errore di policy dentro quel tenant.

Chiedete quindi di cosa ha davvero bisogno il cliente. Se il contratto prevede siti privati più un’uscita predefinita, una tabella completa aggiunge costo senza aggiungere requisiti. È una questione commerciale, e merita una risposta scritta invece di un’ipotesi ereditata dal progetto precedente. Se il servizio ha davvero bisogno del feed per la policy o per la selezione dell’uscita locale, fatene una voce esplicita con la sua prenotazione di capacità e il suo comportamento in caso di guasto.

Quando l’etichettatura per VRF è il default giusto

È un buon default quando la piattaforma la documenta come supportata, quando il numero di rotte del VRF è elevato e quando il costo della ricerca in uscita è accettabile per il profilo di traffico. È anche la scelta naturale quando la semplicità operativa conta più che spremere l’ultimo microsecondo dall’inoltro, perché un’etichetta per tenant è più facile da spiegare e da verificare di un’etichetta per prefisso.

È il default sbagliato quando la documentazione della piattaforma lega la funzione a vincoli hardware o di release specifici, o quando il progetto dipende da decisioni di inoltro per prefisso in uscita. Leggete il riferimento statement della piattaforma prima di presumere il comportamento; il comando Junos è documentato, ma sono i limiti hardware e di release che lo circondano a decidere davvero la distribuzione.

Un budget che potete difendere

Costruite il caso di capacità come cinque numeri separati: percorsi ricevuti, rotte selezionate, voci di inoltro installate, etichette di servizio ed etichette di trasporto. Aggiungete lo stato next-hop e di adiacenza, il numero di tenant e il modello di ridondanza. L’istantanea del percorso felice di un solo VRF non è un dato di scala, e una dimensione nominale dello spazio etichette non è una tabella hardware disponibile.

Poi concordate anche la modalità di guasto, non solo lo stato stazionario. Cosa succede quando il feed cresce della metà, quando un tenant aggiunge un secondo VRF o quando la piattaforma ha bisogno di un riavvio per ridimensionare una tabella? Un budget che resiste a queste domande vale più di un conteggio di etichette che funziona solo sulla carta.

Scegliete l’allocazione in base all’azione in uscita e ai limiti della piattaforma, poi fate del feed di rotte una decisione di servizio esplicita. L’etichetta è la parte visibile del progetto; le rotte sono la parte che va pagata ogni giorno.