Dimensjonere et stort stjerne-VPN: tell før du velger BGP
Prefiksene er det enkle tallet. Sesjoner, oppdateringsbølger og gjenoppretting etter et hubbrudd avgjør om designet holder ved noen tusen filialer.
Tre tusen filialer høres ut som et ruteproblem, men oppfører seg som et regnskapsproblem. Prefikssummen er regnet ut på ti minutter, og det er sjelden tallet som gjør vondt. Det som gjør vondt, er arbeidet per sesjon, oppdateringsbølgen når en delt komponent svikter, og tiden det tar før videresendingen passer til den nye topologien igjen.
Så gå gjennom regnestykket i riktig rekkefølge. Tell relasjonene, tell prefiksene og alternativene, tell deretter hva som skjer i en dårlig time, og sammenlign først etterpå protokoller og plattformer. I motsatt rekkefølge blir øvelsen en diskusjon om rutebegrensninger som ingen kan avgjøre med informasjonen på bordet.
Fire budsjetter, ikke ett
Hvert budsjett svarer på et annet spørsmål, og hvert av dem kan være den bindende begrensningen på en annen plattform. Når de skrives hver for seg, kan ett stort prefikstall ikke stå i stedet for hele designet.
| 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 |
De to siste er dem som hoppes over i en designgjennomgang. Et nettverk som ligger godt innenfor hukommelsen i stabil tilstand, kan fortsatt oppføre seg dårlig når fire hundre filialer kobler til igjen innen to minutter, fordi arbeidet kommer raskere enn kontrollplanet klarer å tømme det. Skriv bølgens størrelse ned som et tall, sammen med hvor lenge tjenesten kan være degradert. Det gjør en vag bekymring til en test noen faktisk kan kjøre.
Det skjuler seg også et plattformspørsmål i alle fire: om kryptering, videresending og ruting deler én CPU eller har separate veier. To enheter med identisk rutekapasitet kan oppføre seg svært ulikt under en bølge, og databladet sier sjelden hvilken du kjøper.
Gjør regnestykket med dine egne tall
Ta et oppdiktet design: 3,000 filialer, tre prefikser hver før aggregering, og to huber per filial for redundans. Hubparet må holde rundt 9,000 filialprefikser før oppsummering, og designet innebærer 6,000 sesjoner mellom filial og hub hvis hver filial peeringer med begge.
Legg nå til delene som ikke er prefikser. Hver sesjon bærer tilstand og periodiske meldinger selv når ingenting endres. Hver hub kan holde mer enn én vei per prefiks hvis den forventes å svitsje raskt, så antallet alternativer kan overstige antallet valgte. Og visningen til hver spoke er en egen politikkbeslutning: å gi hver filial alle de andres ruter multipliserer arbeidet på en måte som tellingen på hub-siden ikke avslører.
Dette er planleggingstall for en designssamtale, ikke en måling av noe produkt. Det nyttige resultatet av øvelsen er formen på kurven, ikke en påstand om hvor en bestemt ruter gir opp.
Hva BGP gir deg, og hva en IGP gir deg
BGP skiller hva en ruter mottok, hva den valgte og hva den annonserer, og hver av disse styres av politikk. Det er nettopp det et filialnett trenger, fordi en spoke vanligvis skal se en standardrute, de sentrale tjenestene og svært lite annet. Å telle bare den endelige tabellen skjuler alternativene og annonseringene, og det er nettopp de delene som vokser når du legger til redundans.
En IGP er ikke automatisk feil. Når topologien, områdestrukturen og nabomodellen passer til tjenesten, konvergerer en link-state-protokoll raskt og trenger mindre politikkstillverk. Fellen er å anta at den kan uttrykke samme eksportkontroll per nabo som BGP: et OSPF-område er en flomgrense, ikke et filter du kan feste til én filial.
Uansett, bestem synlighetsmodellen først. Standardruter, oppsummeringer for sentrale tjenester eller fulle filialdetaljer er tre forskjellige produkter, og en oppsummering som skjuler en mer spesifikk feil, er en designbeslutning som må skrives ned, ikke oppdages under et avbrudd.
Test bølgen, ikke den stabile tilstanden
Bygg sammenligningen rundt feilen du faktisk forventer: en hub nede, en regional WAN-hendelse eller et vedlikeholdsvindu som tar halvparten av stedene offline på en gang. Mål gjenopprettingen fra filialens perspektiv, inkludert applikasjonen, fordi et kontrollplan som konvergerer på sekunder betyr lite hvis sesjonen bruker minutter på å gjenopprettes.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFRegistrer hva plattformen gjør på bølgens topp i stedet for i ro, og gjenta det med sikkerhetsfunksjonene på. En proof of concept som bare viser en rolig tabell, er en hukommelsestest, og hukommelse var aldri det interessante tallet.