ابعادسنجی یک VPN بزرگ ستارهای: پیش از انتخاب BGP بشمارید
پیشوندها عدد آسان‌اند. نشست‌ها، موج به‌روزرسانی‌ها و بازیابی پس از خرابی یک هاب تعیین می‌کنند که طراحی در چند هزار شعبه دوام می‌آورد یا نه.
سه هزار شعبه مثل یک مسئله مسیریابی به گوش می‌رسد، اما مثل یک مسئله حسابداری رفتار می‌کند. جمع پیشوندها در ده دقیقه حساب می‌شود و به‌ندرت همان عددی است که درد می‌آورد. درد واقعی کار به‌ازای هر نشست است، موج به‌روزرسانی وقتی یک مؤلفه مشترک از کار می‌افتد، و زمانی که طول می‌کشد تا ارسال دوباره با توپولوژی جدید هم‌خوان شود.
پس حساب‌وکتاب را به ترتیب درست پیش ببرید. رابطه‌ها را بشمارید، پیشوندها و گزینه‌های جایگزین را بشمارید، بعد بشمارید در یک ساعت بد چه می‌شود، و تنها پس از آن پروتکل‌ها و پلتفرم‌ها را مقایسه کنید. در ترتیب برعکس، این تمرین به بحثی درباره سقف مسیرها تبدیل می‌شود که هیچ‌کس با اطلاعات روی میز نمی‌تواند جمعش کند.
چهار بودجه، نه یکی
هر بودجه به پرسشی متفاوت پاسخ می‌دهد و هر یک می‌تواند در پلتفرمی متفاوت قید محدودکننده باشد. نوشتن جداگانه‌شان مانع می‌شود یک عدد بزرگ پیشوند جای کل طراحی را بگیرد.
| 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 |
دو مورد آخر همان‌هایی هستند که در بازبینی طراحی جا می‌افتند. شبکه‌ای که در حالت پایدار راحت در حافظه جا می‌شود، وقتی چهارصد شعبه در دو دقیقه دوباره وصل شوند می‌تواند بد رفتار کند، چون کار سریع‌تر از آن می‌رسد که سطح کنترل آن را تخلیه کند. اندازه موج را به‌عنوان یک عدد بنویسید، همراه با اینکه سرویس تا چه مدت می‌تواند تنزل داشته باشد. این کار نگرانی مبهم را به آزمونی تبدیل می‌کند که کسی واقعاً می‌تواند اجرا کند.
پرسش پلتفرمی هم در هر چهار مورد پنهان است: اینکه رمزنگاری، ارسال و مسیریابی یک پردازنده را شریک‌اند یا مسیرهای جداگانه دارند. دو دستگاهی که ظرفیت مسیر یکسانی دارند می‌توانند زیر موج بسیار متفاوت رفتار کنند، و برگه مشخصات به‌ندرت می‌گوید کدام را می‌خرید.
حساب را با اعداد خودتان انجام دهید
یک طراحی فرضی بردارید: 3,000 شعبه، سه پیشوند برای هر کدام پیش از تجمیع، و دو هاب برای هر شعبه جهت افزونگی. جفت هاب باید پیش از خلاصه‌سازی حدود 9,000 پیشوند شعبه را نگه دارد، و طراحی 6,000 نشست شعبه-به-هاب را ایجاب می‌کند اگر هر شعبه با هر دو همتا شود.
حالا بخش‌هایی را که پیشوند نیستند اضافه کنید. هر نشست حتی وقتی چیزی تغییر نمی‌کند، وضعیت و پیام‌های دوره‌ای حمل می‌کند. هر هاب اگر انتظار جابه‌جایی سریع از آن برود می‌تواند بیش از یک مسیر برای هر پیشوند نگه دارد، پس شمار گزینه‌های جایگزین می‌تواند از شمار انتخاب‌شده‌ها بیشتر شود. و دید هر شعبه یک تصمیم سیاستی جداست: دادن مسیرهای همه شعبه‌های دیگر به هر شعبه، کار را به شکلی چند برابر می‌کند که شمارش سمت هاب آن را آشکار نمی‌کند.
اینها اعداد برنامه‌ریزی برای یک گفت‌وگوی طراحی‌اند، نه اندازه‌گیری هیچ محصولی. خروجی مفید این تمرین شکل منحنی است، نه ادعایی درباره اینکه یک روتر مشخص کجا تسلیم می‌شود.
BGP چه چیزی برایتان می‌خرد و IGP چه چیزی
BGP آنچه یک روتر دریافت کرد، آنچه انتخاب کرد و آنچه اعلام می‌کند را جدا می‌کند، و هر یک از اینها با سیاست کنترل می‌شود. این دقیقاً همان چیزی است که یک شبکه شعبه لازم دارد، چون یک شعبه معمولاً باید مسیر پیش‌فرض، سرویس‌های مرکزی و بسیار کم چیز دیگری را ببیند. شمردن تنها جدول نهایی، گزینه‌های جایگزین و اعلام‌ها را پنهان می‌کند و اینها همان بخش‌هایی هستند که با افزودن افزونگی رشد می‌کنند.
IGP به‌طور خودکار غلط نیست. وقتی توپولوژی، ساختار ناحیه‌ها و مدل همسایگی با سرویس جور باشد، یک پروتکل حالت پیوند سریع همگرا می‌شود و داربست سیاستی کمتری لازم دارد. تله این است که فرض کنید می‌تواند همان کنترل صدور به‌ازای هر همسایه را مثل BGP بیان کند: ناحیه OSPF یک مرز سیلابی است، نه فیلتری که به یک شعبه بچسبانید.
در هر حال، اول مدل دید را تعیین کنید. مسیرهای پیش‌فرض، خلاصه‌ها برای سرویس‌های مرکزی یا جزئیات کامل شعبه سه محصول متفاوت‌اند، و خلاصه‌ای که خرابی مشخص‌تری را پنهان می‌کند یک تصمیم طراحی است که باید نوشته شود، نه اینکه هنگام قطعی کشف شود.
موج را بیازمایید، نه حالت پایدار را
مقایسه را حول خرابی‌ای بسازید که واقعاً انتظارش را دارید: یک هاب از کار افتاده، رویداد منطقه‌ای WAN، یا پنجره نگهداری که نیمی از سایت‌ها را یکجا آفلاین می‌کند. بازیابی را از دید شعبه اندازه بگیرید، همراه با برنامه، چون سطح کنترلی که در ثانیه‌ها همگرا می‌شود اگر نشست دقیقه‌ها طول بکشد تا دوباره برقرار شود چیز زیادی نمی‌ارزد.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFثبت کنید پلتفرم در اوج موج چه می‌کند، نه در سکون، و آن را با قابلیت‌های امنیتی فعال تکرار کنید. اثبات مفهومی که فقط یک جدول آرام نشان می‌دهد یک آزمون حافظه است، و حافظه هرگز عدد جالب نبود.