Böyük ulduz tipli VPN-in ölçüsünü təyin etmək: BGP seçməzdən əvvəl sayın
Prefikslər asan rəqəmdir. Sessiyalar, yeniləmə axını və bir hub sıradan çıxdıqdan sonra bərpa dizaynın bir neçə min filialda davam edib-etmədiyini həll edir.
Üç min filial marşrutlaşdırma problemi kimi səslənir, amma mühasibat problemi kimi davranır. Prefikslərin ümumi sayını hesablamaq on dəqiqə çəkir və bu, nadir hallarda ağrı verən rəqəm olur. Ağrı verən sessiya başına iş, ortaq komponent sıradan çıxanda yeniləmə partlaması və yönləndirmənin yeni topologiyaya yenidən uyğunlaşmasına qədər keçən vaxtdır.
Yəni hesablamanı düzgün ardıcıllıqla aparın. Əlaqələri sayın, prefiksləri və alternativləri sayın, sonra pis bir saatda nə baş verdiyini sayın və yalnız bundan sonra protokolları və platformaları müqayisə edin. Əks ardıcıllıqla bu məşq, masadakı məlumatla heç kimin həll edə bilmədiyi marşrut limitləri mübahisəsinə çevrilir.
Dörd büdcə, bir deyil
Hər büdcə fərqli suala cavab verir və hər biri fərqli platformada məhdudlaşdırıcı amil ola bilər. Onları ayrı-ayrı yazmaq tək bir böyük prefiks rəqəminin bütün dizaynı əvəz etməsinin qarşısını alır.
| 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 |
Son ikisi dizayn baxışında atlananlardır. Sabit vəziyyətdə yaddaşa rahat sığan şəbəkə, dörd yüz filial iki dəqiqə ərzində yenidən qoşulanda yenə də pis davrana bilər, çünki iş nəzarət müstəvisinin onu boşaltdığından daha sürətli gəlir. Partlamanın ölçüsünü rəqəmlə, xidmətin nə qədər müddət pisləşmiş qala biləcəyi ilə birlikdə yazın. Bu, qeyri-müəyyən narahatlığı kiminsə həqiqətən işlədə biləcəyi testə çevirir.
Bütün dördünün içində gizlənən bir platforma sualı da var: şifrələmə, yönləndirmə və marşrutlaşdırma eyni prosessoru paylaşır, yoxsa ayrı yollara malikdir. Eyni marşrut tutumuna malik iki cihaz axın altında çox fərqli davrana bilər və məlumat vərəqi nadir hallarda hansını aldığınızı deyir.
Hesablamanı öz rəqəmlərinizlə aparın
Uydurma bir dizayn götürün: 3,000 filial, hər biri aqreqasiyadan əvvəl üç prefiks və ehtiyatlılıq üçün hər filiala iki hub. Hub cütü xülasələşdirmədən əvvəl təxminən 9,000 filial prefiksini saxlamalıdır və dizayn hər filial hər iki hub ilə qonşuluq qurursa 6,000 filial-hub sessiyası nəzərdə tutur.
İndi prefiks olmayan hissələri əlavə edin. Hər sessiya heç nə dəyişməsə belə vəziyyət və dövri mesajlar daşıyır. Hər hub sürətli keçid gözlənilirsə hər prefiks üçün birdən çox yol saxlaya bilər, buna görə alternativlərin sayı seçilmiş sayı üstələyə bilər. Və hər spoke-un görünüşü ayrı bir siyasət qərarıdır: hər filiala bütün digər filialların marşrutlarını vermək işi hub tərəfindəki sayğacın göstərmədiyi şəkildə çoxaldır.
Bunlar dizayn söhbəti üçün planlaşdırma rəqəmləridir, hər hansı məhsulun ölçülməsi deyil. Məşqin faydalı çıxışı əyrinin formasıdır, müəyyən bir marşrutlaşdırıcının harada təslim olduğuna dair iddia deyil.
BGP sizə nə qazandırır, IGP sizə nə qazandırır
BGP marşrutlaşdırıcının nə aldığını, nə seçdiyini və nə elan etdiyini ayırır və bunların hər biri siyasətlə idarə olunur. Bu, filial şəbəkəsinin tam ehtiyac duyduğu şeydir, çünki spoke adətən standart marşrutu, mərkəzi xidmətləri və çox az başqa şey görməlidir. Yalnız yekun cədvəli saymaq alternativləri və elanları gizlədir, ehtiyatlılıq əlavə etdikdə böyüyən hissələr məhz bunlardır.
IGP avtomatik olaraq səhv deyil. Topologiya, ərazi quruluşu və qonşuluq modeli xidmətə uyğun olduqda, link-state protokolu tez birləşir və daha az siyasət karkası tələb edir. Tələ, onun BGP ilə eyni qonşu başına ixrac nəzarətini ifadə edə biləcəyini güman etməkdir: OSPF ərazisi sel sərhədidir, bir filiala bağlaya biləcəyiniz filtr deyil.
Hər halda, görünürlük modelini əvvəlcə müəyyənləşdirin. Standart marşrutlar, mərkəzi xidmətlər üçün xülasələr və ya tam filial təfərrüatları üç fərqli məhsuldur və daha konkret nasazlığı gizlədən xülasə, kəsinti zamanı aşkar edilmək əvəzinə yazılmalı olan dizayn qərarıdır.
Partlamanı sınayın, sabit vəziyyəti deyil
Müqayisəni həqiqətən gözlədiyiniz nasazlıq ətrafında qurun: bir hub-un sıradan çıxması, regional WAN hadisəsi və ya saytların yarısını eyni anda oflayn edən texniki xidmət pəncərəsi. Bərpa vaxtını filialın baxış bucağından ölçün, tətbiq daxil olmaqla, çünki saniyələrlə birləşən nəzarət müstəvisi sessiya yenidən qurulmaq üçün dəqiqələr çəkirsə az şey ifadə edir.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFPlatformanın istirahətdə deyil, partlama zirvəsində nə etdiyini qeyd edin və bunu təhlükəsizlik funksiyaları aktiv ikən təkrarlayın. Yalnız sakit cədvəl göstərən konsepsiya sübutu yaddaş testidir və yaddaş heç vaxt maraqlı rəqəm olmayıb.