Tre tusen filialar høyrest ut som eit ruteproblem, men oppfører seg som eit rekneskapsproblem. Prefikssummen er rekna ut på ti minutt, og det er sjeldan talet som gjer vondt. Det som gjer vondt, er arbeidet per sesjon, oppdateringsbølgja når ein delt komponent sviktar, og tida det tek før videresendinga passar til den nye topologien igjen.

Så gå gjennom reknestykket i rett rekkjefølgje. Tel relasjonane, tel prefiksa og alternativa, tel deretter kva som skjer i ein dårleg time, og samanlikn først etterpå protokollar og plattformer. I motsett rekkjefølgje vert øvinga ein diskusjon om ruteavgrensingar som ingen kan avgjere med informasjonen på bordet.

Fire budsjett, ikkje eitt

Kvart budsjett svarar på eit anna spørsmål, og kvart av dei kan vere den bindande avgrensinga på ein annan plattform. Når dei skrivast kvar for seg, kan eitt stort prefikstal ikkje stå i staden for heile 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

Dei to siste er dei som vert hoppa over i ein designrevisjon. Eit nettverk som ligg godt innanfor minnet i stabil tilstand, kan framleis oppføre seg dårleg når fire hundre filialar koplast til att innan to minutt, fordi arbeidet kjem raskare enn kontrollplanet klarer å tøme det. Skriv bølgjestorleiken ned som eit tal, saman med kor lenge tenesta kan vere degradert. Det gjer ei vag uro til ein test nokon faktisk kan køyre.

Det skjuler seg òg eit plattformsspørsmål i alle fire: om kryptering, videresending og ruting deler éin CPU eller har separate vegar. To einingar med identisk rutekapasitet kan oppføre seg svært ulikt under ei bølgje, og databladet seier sjeldan kva du kjøper.

Gjer reknestykket med dine eigne tal

Ta eit oppdikta design: 3,000 filialar, tre prefiks kvar før aggregering, og to hubar per filial for redundans. Hubparet må halde rundt 9,000 filialprefiks før oppsummering, og designet inneber 6,000 sesjonar mellom filial og hub om kvar filial peeringar med begge.

Legg no til delane som ikkje er prefiks. Kvar sesjon ber tilstand og periodiske meldingar sjølv når ingenting endrar seg. Kvar hub kan halde meir enn éin veg per prefiks om det er venta at han skal svitsje raskt, så talet på alternativ kan overstige talet på valde. Og visinga til kvar spoke er ei eiga politikkavgjerd: å gje kvar filial rutene til alle dei andre multipliserer arbeidet på ein måte som teljinga på hub-sida ikkje avdekkjer.

Dette er planleggingstal for ein designsamtale, ikkje ei måling av noko produkt. Det nyttige resultatet av øvinga er forma på kurva, ikkje ein påstand om kvar ein bestemd ruter gjev opp.

Kva BGP gjev deg, og kva ein IGP gjev deg

BGP skil kva ein ruter tok imot, kva han valde og kva han annonserer, og kvar av desse vert styrt av politikk. Det er nettopp det eit filialnett treng, fordi ein spoke vanlegvis skal sjå ei standardrute, dei sentrale tenestene og svært lite anna. Å telje berre den endelege tabellen skjuler alternativa og annonseringane, og det er nettopp dei delane som veks når du legg til redundans.

Ein IGP er ikkje automatisk feil. Når topologien, områdestrukturen og nabomodellen passar til tenesta, konvergerer ein link-state-protokoll raskt og treng mindre politikkstillverk. Fella er å tru at han kan uttrykke same eksportkontroll per nabo som BGP: eit OSPF-område er ei flaumgrense, ikkje eit filter du kan feste til ein filial.

Uansett, avgjer synlegheitsmodellen først. Standardruter, oppsummeringar for sentrale tenester eller fulle filialdetaljar er tre ulike produkt, og ei oppsummering som skjuler ein meir spesifikk feil, er ei designavgjerd som må skrivast ned, ikkje oppdagast under eit avbrot.

Test bølgja, ikkje den stabile tilstanden

Bygg samanlikninga rundt feilen du faktisk ventar: ein hub nede, ei regional WAN-hending eller eit vedlikehaldsvindauge som tek halvparten av stadene offline på ein gong. Mål attopprettinga frå filialen sitt perspektiv, inkludert applikasjonen, fordi eit kontrollplan som konvergerer på sekund, tyder lite om sesjonen brukar minutt på å kome opp att.

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

Registrer kva plattformen gjer på toppen av bølgja i staden for i ro, og gjer det om att med tryggleiksfunksjonane på. Eit proof of concept som berre viser ein roleg tabell, er ein minnetest, og minne var aldri det interessante talet.

Relaterte artiklar