Groot ster-VPN dimensioneer: tel eers voordat jy BGP kies
Prefikse is die maklike getal. Sessies, opdateringsverkeer en herstel ná 'n hub-fout bepaal of die ontwerp by 'n paar duisend takke hou.
Drieduisend takke klink na 'n roeterprobleem, maar gedra hulle soos 'n boekhouprobleem. Die prefikstotaal neem tien minute om uit te werk, en dit is selde die getal wat seermaak. Wat seermaak is die werk per sessie, die opdateringsbult wanneer 'n gedeelde komponent faal, en die tyd wat dit neem voordat aanstuur weer by die nuwe topologie pas.
Stap dus die rekenwerk in die regte volgorde deur. Tel die verwantskappe, tel die prefikse en die alternatiewe, tel dan wat in 'n slegte uur gebeur, en vergelyk eers daarna protokolle en platforms. In die ander volgorde word die oefening 'n argument oor roetelims wat niemand met die inligting op tafel kan besleg nie.
Vier begrotings, nie een nie
Elke begroting beantwoord 'n ander vraag, en elkeen kan die beperkende faktor op 'n ander platform wees. Deur hulle apart te skryf, verhoed jy dat een groot prefiksgetal vir die hele ontwerp instaan.
| 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 |
Die laaste twee is die wat in 'n ontwerphersiening oorgeslaan word. 'n Netwerk wat in die stabiele toestand gemaklik binne die geheue pas, kan steeds sleg presteer wanneer vierhonderd takke binne twee minute weer aansluit, want die werk kom vinniger as wat die beheervlak dit kan verwerk. Skryf die bultgrootte as 'n getal neer, saam met hoe lank die diens afgegradeer mag bly. Dit verander 'n vae bekommernis in 'n toets wat iemand werklik kan uitvoer.
Daar skuil ook 'n platformvraag binne al vier: of enkripsie, aanstuur en roetering dieselfde verwerker deel of aparte paaie het. Twee toestelle met identiese roetekapasiteit kan baie anders reageer tydens verkeersbultte, en die datablad sê selde watter een jy koop.
Doen die rekenwerk met jou eie syfers
Neem 'n denkbeeldige ontwerp: 3,000 takke, drie prefikse elk voor samevatting, en twee hubs per tak vir oortolligheid. Die hubpaar moet rofweg 9,000 takprefikse voor opsomming hou, en die ontwerp impliseer 6,000 tak-tot-hub-sessies as elke tak met albei peers.
Voeg nou die dele by wat nie prefikse is nie. Elke sessie dra toestand en periodieke boodskappe, selfs wanneer niks verander nie. Elke hub kan meer as een pad per prefiks hou as daar van hom verwag word om vinnig oor te skakel, so die alternatiewegetal kan die gekose getal oorskry. En elke spoke se siening is 'n aparte beleidsbesluit: om elke tak al die ander takke se roetes te gee vermenigvuldig die werk op 'n manier wat die hub-kant-telling nie openbaar nie.
Dit is beplanningsyfers vir 'n ontwerpgesprek, nie 'n meting van enige produk nie. Die nuttige uitset van die oefening is die vorm van die kurwe, nie 'n bewering oor waar 'n spesifieke roeter ingee nie.
Wat BGP vir jou koop, en wat 'n IGP vir jou koop
BGP skei wat 'n roeter ontvang het, wat hy gekies het en wat hy adverteer, en elkeen daarvan word deur beleid beheer. Dit is presies wat 'n taknetwerk nodig het, want 'n spoke moet gewoonlik 'n verstekroete, die sentrale dienste en baie min anders sien. Om net die finale tabel te tel, verberg die alternatiewe en die advertensies, wat juis die dele is wat groei wanneer jy oortolligheid byvoeg.
'n IGP is nie outomaties verkeerd nie. Wanneer die topologie, gebiedstruktuur en adjacensiemodel by die diens pas, konvergeer 'n skakeltoestandprotokol vinnig en het dit minder beleidsraamwerk nodig. Die valkuil is om te aanvaar dat dit dieselfde uitvoerbeheer per buur as BGP kan uitdruk: 'n OSPF-gebied is 'n vloedlyngrens, nie 'n filter wat jy aan een tak kan koppel nie.
Besluit in elk geval eers oor die sigbaarheidsmodel. Verstekroetes, samevattings vir sentrale dienste, of volledige takbesonderhede is drie verskillende produkte, en 'n samevatting wat 'n meer spesifieke fout verberg, is 'n ontwerpbesluit wat neergeskryf moet word eerder as om tydens 'n onderbreking ontdek te word.
Toets die bult, nie die stabiele toestand nie
Bou die vergelyking rondom die fout wat jy werklik verwag: 'n hub wat afgaan, 'n streek-WAN-gebeurtenis, of 'n onderhoudsvenster wat die helfte van die terreine gelyktydig aflyn neem. Meet die hersteltyd vanuit die tak se perspektief, insluitend die toepassing, want 'n beheervlak wat in sekondes konvergeer beteken min as die sessie minute neem om weer op te stel.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFTeken op wat die platform by die bultpiek doen eerder as in rus, en herhaal dit met die sekuriteitsfunksies geaktiveer. 'n Proefproject wat net 'n stil tabel wys, is 'n geheuetoets, en geheue was nooit die interessante getal nie.