Tre tusind filialer lyder som et routingproblem, men opfører sig som et bogholderiproblem. Det samlede antal præfikser er beregnet på ti minutter, og det er sjældent tallet, der gør ondt. Det, der gør ondt, er arbejdet pr. session, opdateringsbølgen når en delt komponent svigter, og den tid, der går, før videresendelsen igen passer til den nye topologi.

Så gå gennem regnestykket i den rigtige rækkefølge. Tæl relationerne, tæl præfikserne og alternativerne, tæl derefter hvad der sker i en dårlig time, og sammenlign først bagefter protokoller og platforme. I omvendt rækkefølge bliver øvelsen en diskussion om rutebegrænsninger, som ingen kan afslutte med oplysningerne på bordet.

Fire budgetter, ikke ét

Hvert budget besvarer et forskelligt spørgsmål, og hvert af dem kan være den bindende begrænsning på en forskellig platform. Når de skrives op hver for sig, kan ét stort præfikstal ikke stå i stedet for hele designet.

BudgetWhat you are really counting
SessionsPeers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count
PrefixesAlternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see
ChurnUpdates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event
RecoveryTime to detect, reselect, reinstall and restore the application, measured end to end rather than per box

De sidste to er dem, der springes over i en designgennemgang. Et netværk, der ligger godt inden for hukommelsen i stabil tilstand, kan stadig opføre sig dårligt, når fire hundrede filialer genopretter forbindelsen inden for to minutter, fordi arbejdet ankommer hurtigere, end kontrolplanet kan dræne det. Skriv bølgens størrelse ned som et tal, sammen med hvor længe tjenesten må være degraderet. Det gør en vag bekymring til en test, som nogen faktisk kan køre.

Der gemmer sig også et platforms-spørgsmål i alle fire: om kryptering, videresendelse og routing deler én CPU eller har separate veje. To enheder med identisk rutekapacitet kan opføre sig meget forskelligt under bølgen, og databladet siger sjældent, hvilken du køber.

Lav regnestykket med dine egne tal

Tag et opdigtet design: 3,000 filialer, tre præfikser hver før aggregering, og to hubs pr. filial for redundans. Hubparret skal rumme cirka 9,000 filialpræfikser før sammenfatning, og designet indebærer 6,000 sessioner mellem filial og hub, hvis hver filial peering med begge.

Tilføj nu de dele, der ikke er præfikser. Hver session bærer tilstand og periodiske beskeder, selv når intet ændrer sig. Hver hub kan holde mere end én vej pr. præfiks, hvis den forventes at skifte hurtigt, så antallet af alternativer kan overstige antallet af valgte. Og hver spokes syn er en separat politikbeslutning: at give hver filial alle de andres ruter multiplicerer arbejdet på en måde, som optællingen på hub-siden ikke afslører.

Det er planlægningstal til en designsamtale, ikke en måling af noget produkt. Det nyttige output af øvelsen er kurvens form, ikke en påstand om, hvor en bestemt router giver op.

Hvad BGP giver dig, og hvad en IGP giver dig

BGP adskiller, hvad en router modtog, hvad den valgte, og hvad den annoncerer, og hver af disse styres af politik. Det er præcis, hvad et filialnetværk har brug for, fordi en spoke normalt skal se en standardrute, de centrale tjenester og meget lidt andet. At tælle kun den endelige tabel skjuler alternativerne og annonceringerne, og det er netop de dele, der vokser, når du tilføjer redundans.

En IGP er ikke automatisk forkert. Når topologien, områdestrukturen og adjacency-modellen passer til tjenesten, konvergerer en link-state-protokol hurtigt og kræver mindre politikstillads. Fælden er at antage, at den kan udtrykke samme eksportkontrol pr. nabo som BGP: et OSPF-område er en floodingsgrænse, ikke et filter, du kan hæfte på én filial.

Under alle omstændigheder skal du først beslutte synlighedsmodellen. Standardruter, opsummeringer for centrale tjenester eller fulde filialdetaljer er tre forskellige produkter, og en opsummering, der skjuler en mere specifik fejl, er en designbeslutning, der skal skrives ned i stedet for at blive opdaget under et udfald.

Test bølgen, ikke den stabile tilstand

Byg sammenligningen omkring den fejl, du faktisk forventer: en hub der går ned, en regional WAN-hændelse eller et vedligeholdelsesvindue, der tager halvdelen af stederne offline på én gang. Mål genopretningen fra filialens synspunkt, inklusive applikationen, fordi et kontrolplan, der konvergerer på sekunder, betyder lidt, hvis sessionen tager minutter at genetablere.

show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPF

Registrér, hvad platformen gør ved bølgens top i stedet for i hvile, og gentag det med sikkerhedsfunktionerne aktiveret. Et proof of concept, der kun viser en rolig tabel, er en hukommelsestest, og hukommelse var aldrig det interessante tal.

Relaterede artikler