Nagy csillagtopológiás VPN méretezése: számoljon, mielőtt BGP-t választ
A prefixek a könnyű szám. A munkamenetek, a frissítési hullám és egy hub kiesése utáni helyreállás dönti el, hogy a terv kibírja-e néhány ezer fióktelep mellett.
Háromezer fióktelep útválasztási problémának hangzik, de könyvelési problémaként viselkedik. A prefixek összlétszáma tíz perc alatt kiszámolható, és ritkán ez a fájó szám. Az fáj, hogy mennyi munka jut egy munkamenetre, mekkora frissítési hullám jön, amikor egy közös komponens kiesik, és mennyi időbe telik, míg a továbbítás újra illeszkedik az új topológiához.
Járja végig tehát a számítást helyes sorrendben. Számolja meg a kapcsolatokat, a prefixeket és az alternatívákat, aztán számolja meg, mi történik egy rossz órában, és csak ezután hasonlítsa össze a protokollokat és platformokat. Fordított sorrendben a gyakorlat vitává válik az útvonal-limitekről, amelyet senki nem tud lezárni az asztalon lévő információkkal.
Négy büdzsé, nem egy
Minden büdzsé más kérdésre válaszol, és mindegyik lehet a szűk keresztmetszet egy másik platformon. Külön leírásuk megakadályozza, hogy egyetlen nagy prefixszám álljon az egész terv helyett.
| 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 |
Az utolsó kettőt szokás kihagyni a tervezési átvizsgáláson. Egy hálózat, amely stabil állapotban kényelmesen elfér a memóriában, akkor is viselkedhet rosszul, amikor négyszáz fióktelep két percen belül újracsatlakozik, mert a munka gyorsabban érkezik, mint ahogy a vezérsík ki tudja üríteni. Írja fel a hullám méretét számként, azzal együtt, meddig maradhat degradált a szolgáltatás. Ez a homályos aggodalmat olyan tesztté alakítja, amelyet valaki tényleg le tud futtatni.
Mind a négyben ott lapul egy platformkérdés is: a titkosítás, a továbbítás és az útválasztás ugyanazon a CPU-n osztozik-e, vagy külön útvonalaik vannak. Két azonos útvonalkapacitású eszköz nagyon eltérően viselkedhet hullám alatt, és az adatlap ritkán árulja el, melyiket vásárolja.
Végezze el a számítást a saját számaival
Vegyen egy kitalált tervet: 3,000 fióktelep, egyenként három prefix az aggregáció előtt, és fióktelepenként két hub a redundancia miatt. A hubpárnak az összegzés előtt nagyjából 9,000 fióktelep-prefixet kell tartania, és a terv 6,000 fióktelep–hub munkamenetet feltételez, ha minden fióktelep mindkettővel peeringel.
Most adja hozzá a nem prefix részeket. Minden munkamenet állapotot és időszakos üzeneteket hordoz, akkor is, ha semmi nem változik. Minden hub egynél több útvonalat tarthat prefixenként, ha gyors átkapcsolást várnak tőle, így az alternatívák száma meghaladhatja a kiválasztottakét. És minden ág látképe külön szabálydöntés: minden fióktelepnek az összes többi útvonalát odaadni olyan módon sokszorozza a munkát, amit a hub oldali számolás nem mutat meg.
Ezek tervezési számok egy tervezési beszélgetéshez, nem bármely termék mérése. A gyakorlat hasznos kimenete a görbe alakja, nem az az állítás, hogy egy adott router hol adja fel.
Mit ad önnek a BGP, és mit ad egy IGP
A BGP szétválasztja, mit kapott, mit választott és mit hirdet egy router, és mindegyiket szabály vezérli. Pont erre van szüksége egy fióktelepes hálózatnak, mert egy ágnak általában alapértelmezett útvonalat, a központi szolgáltatásokat és nagyon kevés egyebet kell látnia. Ha csak a végső táblát számoljuk, elrejtjük az alternatívákat és a hirdetéseket, és éppen ezek nőnek, amikor redundanciát adunk hozzá.
Az IGP nem automatikusan rossz. Amikor a topológia, a területi szerkezet és a szomszédsági modell illik a szolgáltatáshoz, egy link-state protokoll gyorsan konvergál, és kevesebb szabályzati állványzatra van szüksége. A csapda azt feltételezni, hogy ugyanazt a szomszédenkénti exportvezérlést tudja kifejezni, mint a BGP: az OSPF-terület elárasztási határ, nem egy fióktelepre akasztható szűrő.
Akárhogy is, először a láthatósági modellt döntse el. Az alapértelmezett útvonalak, a központi szolgáltatások összegzései vagy a teljes fióktelep-részletek három különböző termék, és az az összegzés, amely elrejt egy konkrétabb hibát, olyan tervezési döntés, amelyet le kell írni, nem pedig egy kiesés közben felfedezni.
A hullámot tesztelje, ne a stabil állapotot
Az összehasonlítást a valóban várt hiba köré építse: egy hub leáll, egy regionális WAN-esemény, vagy egy karbantartási ablak, amely a helyszínek felét egyszerre viszi offline-ba. A fióktelep szemszögéből mérje a helyreállást, az alkalmazással együtt, mert a másodpercek alatt konvergáló vezérsík keveset ér, ha a munkamenet újraépítése percekig tart.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPF
Rögzítse, mit tesz a platform a hullám csúcsán, nem nyugalomban, és ismételje meg bekapcsolt biztonsági funkciókkal. Egy proof of concept, amely csak csendes táblát mutat, memóriateszt, és a memória soha nem volt az érdekes szám.