Dimensionera ett stort stjärn-VPN: räkna innan du väljer BGP
Prefixen är det enkla talet. Sessioner, uppdateringsvågor och återhämtning efter ett hubhaveri avgör om designen håller vid några tusen filialer.
Tre tusen filialer låter som ett routingproblem men beter sig som ett bokföringsproblem. Prefixsumman räknas ut på tio minuter, och det är sällan talet som gör ont. Det som gör ont är arbetet per session, uppdateringsvågen när en delad komponent fallerar, och tiden innan vidarebefordran återigen stämmer med den nya topologin.
Gå därför igenom aritmetiken i rätt ordning. Räkna relationerna, räkna prefixen och alternativen, räkna sedan vad som händer under en dålig timme, och jämför först därefter protokoll och plattformar. I omvänd ordning blir övningen en diskussion om ruttbegränsningar som ingen kan avgöra med informationen på bordet.
Fyra budgetar, inte en
Varje budget svarar på en annan fråga, och var och en kan vara den bindande begränsningen på en annan plattform. När de skrivs ned separat kan ett enda stort prefixtal inte stå i stället för hela designen.
| 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 två sista är de som hoppas över i en designgenomgång. Ett nätverk som ligger bekvämt inom minnet i stabilt tillstånd kan fortfarande bete sig illa när fyrahundra filialer återansluter inom två minuter, eftersom arbetet anländer snabbare än kontrollplanet hinner tömma det. Skriv ned vågens storlek som ett tal, tillsammans med hur länge tjänsten får vara degraderad. Det gör en vag oro till ett test som någon faktiskt kan köra.
Det finns också en plattformsfråga gömd i alla fyra: om kryptering, vidarebefordran och routing delar en CPU eller har separata vägar. Två enheter med identisk ruttkapacitet kan bete sig mycket olika under en våg, och databladet säger sällan vilken du köper.
Gör aritmetiken med dina egna tal
Ta en påhittad design: 3,000 filialer, tre prefix var före aggregering, och två hubbar per filial för redundans. Hubparet måste hålla ungefär 9,000 filialprefix före sammanfattningen, och designen innebär 6,000 sessioner mellan filial och hubb om varje filial peeringar med båda.
Lägg nu till delarna som inte är prefix. Varje session bär tillstånd och periodiska meddelanden även när ingenting ändras. Varje hubb kan hålla mer än en väg per prefix om den förväntas växla snabbt, så antalet alternativ kan överstiga antalet valda. Och varje spokes vy är ett eget policybeslut: att ge varje filial alla andras rutter multiplicerar arbetet på ett sätt som räkningen på hubbsidan inte avslöjar.
Det är planeringstal för ett designsamtal, inte en mätning av någon produkt. Den användbara utdatan av övningen är kurvans form, inte ett påstående om var en viss router ger upp.
Vad BGP ger dig, och vad en IGP ger dig
BGP skiljer på vad en router tog emot, vad den valde och vad den annonserar, och var och en av dessa styrs av policy. Det är precis vad ett filialnät behöver, eftersom en spoke vanligtvis ska se en standardrutt, de centrala tjänsterna och mycket lite annat. Att bara räkna den slutliga tabellen döljer alternativen och annonseringarna, och det är just de delar som växer när du lägger till redundans.
En IGP är inte automatiskt fel. När topologin, områdesstrukturen och grannskapsmodellen passar tjänsten konvergerar ett link-state-protokoll snabbt och behöver mindre policy-ställverk. Fällan är att anta att det kan uttrycka samma exportkontroll per granne som BGP: ett OSPF-område är en översvämningsgräns, inte ett filter du hänger på en filial.
Hur som helst, bestäm synlighetsmodellen först. Standardrutter, sammanfattningar för centrala tjänster eller fullständiga filialdetaljer är tre olika produkter, och en sammanfattning som döljer ett mer specifikt fel är ett designbeslut som måste skrivas ned, inte upptäckas under ett avbrott.
Testa vågen, inte det stabila tillståndet
Bygg jämförelsen kring det fel du faktiskt förväntar dig: en hubb nere, en regional WAN-händelse eller ett underhållsfönster som tar halva antalet platser offline på en gång. Mät återhämtningen ur filialens perspektiv, inklusive applikationen, eftersom ett kontrollplan som konvergerar på sekunder betyder lite om sessionen tar minuter att återupprätta.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFRegistrera vad plattformen gör på vågens topp i stället för i vila, och upprepa med säkerhetsfunktionerna aktiverade. Ett proof of concept som bara visar en lugn tabell är ett minnestest, och minnet var aldrig det intressanta talet.