תכנון 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תעדו מה הפלטפורמה עושה בשיא הפרץ ולא במנוחה, וחזרו על זה עם תכונות האבטחה מופעלות. הוכחת היתכנות שמראה רק טבלה שקטה היא מבחן זיכרון, והזיכרון מעולם לא היה המספר המעניין.