Dimensionare una grande VPN a stella: contate prima di scegliere BGP
I prefissi sono il numero facile. Le sessioni, la raffica di aggiornamenti e il recupero dopo il guasto di un concentratore decidono se il progetto regge su qualche migliaio di filiali.
Tremila filiali suonano come un problema di routing ma si comportano come un problema di contabilità. Il totale dei prefissi si calcola in dieci minuti, ed è raramente il numero che fa male. Fa male il lavoro per sessione, la raffica di aggiornamenti quando un componente condiviso cade, e il tempo che passa prima che l'inoltro torni a corrispondere alla nuova topologia.
Percorrete quindi l'aritmetica nell'ordine giusto. Contate le relazioni, contate i prefissi e le alternative, poi contate cosa succede in un'ora cattiva, e solo dopo confrontate protocolli e piattaforme. Nell'ordine inverso l'esercizio diventa una discussione sui limiti di rotta che nessuno può chiudere con le informazioni sul tavolo.
Quattro budget, non uno
Ogni budget risponde a una domanda diversa, e ciascuno può essere il vincolo limitante su una piattaforma diversa. Scriverli separatamente impedisce che un solo grande numero di prefissi tenga il posto dell'intero progetto.
| Budget | What you are really counting |
|---|---|
| Sessions | Peers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count |
| Prefixes | Alternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see |
| Churn | Updates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event |
| Recovery | Time to detect, reselect, reinstall and restore the application, measured end to end rather than per box |
Gli ultimi due sono quelli che si saltano in una revisione del progetto. Una rete che sta comodamente in memoria a regime può comunque comportarsi male quando quattrocento filiali si riconnettono in due minuti, perché il lavoro arriva più in fretta di quanto il piano di controllo riesca a smaltirlo. Annotate la dimensione della raffica come numero, insieme a quanto a lungo il servizio può restare degradato. Questo trasforma una preoccupazione vaga in un test che qualcuno può davvero eseguire.
C'è anche una domanda di piattaforma nascosta in tutte e quattro: cifratura, inoltro e routing condividono una CPU o hanno percorsi separati. Due apparati con identica capacità di rotte possono comportarsi molto diversamente sotto la raffica, e la scheda tecnica raramente dice quale state comprando.
Fate l'aritmetica con i vostri numeri
Prendete un progetto inventato: 3,000 filiali, tre prefissi ciascuna prima dell'aggregazione, e due concentratori per filiale per la ridondanza. La coppia di concentratori deve tenere circa 9,000 prefissi di filiale prima del riepilogo, e il progetto implica 6,000 sessioni filiale-concentratore se ogni filiale si connette a entrambi.
Ora aggiungete le parti che non sono prefissi. Ogni sessione porta stato e messaggi periodici anche quando nulla cambia. Ogni concentratore può tenere più di un percorso per prefisso se ci si aspetta un cambio rapido, quindi il numero di alternative può superare quello delle selezionate. E la vista di ogni branca è una decisione di politica separata: dare a ogni filiale le rotte di tutte le altre moltiplica il lavoro in un modo che il conteggio lato concentratore non rivela.
Sono cifre di pianificazione per una conversazione di progetto, non la misura di un prodotto. Il risultato utile dell'esercizio è la forma della curva, non un'affermazione su dove un router preciso cede.
Cosa vi dà BGP, e cosa vi dà un IGP
BGP separa ciò che un router ha ricevuto, ciò che ha selezionato e ciò che annuncia, e ciascuna di queste cose è controllata dalla politica. È esattamente ciò di cui ha bisogno una rete di filiali, perché una branca di solito deve vedere una rotta predefinita, i servizi centrali e molto poco altro. Contare solo la tabella finale nasconde le alternative e gli annunci, che sono proprio le parti che crescono quando aggiungete ridondanza.
Un IGP non è automaticamente sbagliato. Quando topologia, struttura delle aree e modello di adiacenza si adattano al servizio, un protocollo a stato di collegamento converge in fretta e richiede meno impalcatura di politica. La trappola è supporre che possa esprimere lo stesso controllo di esportazione per vicino di BGP: un'area OSPF è un confine di flooding, non un filtro da appendere a una filiale.
In ogni caso, decidete prima il modello di visibilità. Rotte predefinite, riepiloghi per i servizi centrali o dettagli completi delle filiali sono tre prodotti diversi, e un riepilogo che nasconde un guasto più specifico è una decisione di progetto da scrivere, non da scoprire durante un'interruzione.
Provate la raffica, non il regime
Costruite il confronto intorno al guasto che vi aspettate davvero: un concentratore giù, un evento WAN regionale o una finestra di manutenzione che mette metà delle sedi offline in una volta. Misurate il recupero dal punto di vista della filiale, applicazione inclusa, perché un piano di controllo che converge in secondi conta poco se la sessione impiega minuti a ristabilirsi.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPF
Registrate cosa fa la piattaforma al picco della raffica e non a riposo, e ripetete con le funzioni di sicurezza attive. Una prova di concetto che mostra solo una tabella tranquilla è un test di memoria, e la memoria non è mai stata il numero interessante.