תווית לכל VRF או לכל prefix? חשבון הקיבולת האמיתי
תווית אחת לכל VRF נראית זולה יותר מתווית לכל prefix, אבל מספר התוויות הוא השורה הקטנה ביותר בתקציב. הנה מה שנגמר ראשון בפועל.
שני עיצובים מפרסמים את אותו prefix של לקוח באותו ליבת ספק. האחד מקצה תווית לכל prefix, השני מקצה תווית אחת לכל ה-VRF, והשני נראה זול יותר בכל שקופית. מספר התוויות הוא אמיתי, אבל הוא לא התקציב שנגמר בדרך כלל ראשון. לבחור בין השניים פירושו לספור ארבעה משאבים, לא אחד, והתוויות הן הקטנות שבהם.
הבחירה תלויה גם במה שעל נתב היציאה לעשות עם החבילה לאחר שהוא מסיר את התווית. ההבדל התפקודי הזה, ולא האריתמטיקה של התוויות, צריך להנחות את ההחלטה.
מה כל הקצאה חוסכת באמת
הקצאה לכל prefix נושאת את מידע ההעברה בתווית. נתב היציאה יכול לשלוח את החבילה ישירות לסמיכות הנכונה בלי חיפוש יעד, ולכן היא משתלבת היטב עם מערכי מסלולים גדולים של VRF, ולכן היא צורכת תווית אחת לכל prefix מפורסם בכל VRF. הקצאה לכל VRF, כמו Junos vrf-table-label, מפרסמת תווית אחת לכל מופע ניתוב ומשתמשת בתווית הזו כדי לבחור את טבלת ה-VRF; לאחר מכן הנתב מבצע חיפוש IP בתוך הטבלה.
זהו הבדל ארכיטקטוני אמיתי ולא כפתור כוונון. תיוג לכל VRF נותן מרחב תוויות קטן יותר ופרסום תוויות פשוט יותר, במחיר של חיפוש אחד ושל תווית שאינה אומרת דבר על היעד. תיוג לכל prefix נותן לכרטיס הקו של היציאה יותר מידע מראש ועולה תוויות ביחס למסלולים שאתה נושא.
ספר התוויות הוא הקטן
תוויות MPLS סופיות, אבל מרחב התוויות גדול מספיק כדי שספקי שירות רגילים לא ימצו אותו בכמה אלפי prefix-ים. המקום שבו תיוג לכל VRF עוזר באמת הוא בפלטפורמות עם טבלאות תוויות חומרה קטנות, או בעיצובים שבהם VRF אחד נושא הזנת אינטרנט מלאה ותיוג לכל prefix יכפיל את הביקוש לתוויות במספר המסלולים. אלה אילוצים אמיתיים, והם הסיבה שהתכונה קיימת. אף אחד מהם אינו עוסק במספר ה-prefix-ים בטבלה.
ספור תוויות גם לשירות וגם לתעבורה לפני שתבחר. עיצוב לכל VRF עדיין זקוק לתוויות תעבורה עבור ה-loopbacks ועבור כל קפיצה לאורך המסלול, והוא עדיין זקוק למצב סמיכות. אם תדריך העיצוב סופר רק תוויות שירות, החיסכון נמדד בספר החשבונות הלא נכון.
הזנות מסלולים עולות בזיכרון לפני תוויות
כל נתיב שמתקבל צורך זיכרון מישור בקרה, עיבוד עדכונים וזמן התכנסות, בין אם ה-VRF משתמש בתווית אחת ובין אם בעשרת אלפים. הזנת אינטרנט מלאה בתוך VRF היא יקרה בגלל נתיבי BGP, ה-RIB, רשומות ה-FIB והתזוזה שמאחוריהם, ולא בגלל התווית שלפני הטבלה. אותה הזנה גם מגדילה את רדיוס ההשפעה של דליפת מסלולים או טעות מדיניות בתוך אותו שוכר.
אז שאל מה הלקוח באמת דורש. אם החוזה הוא אתרים פרטיים ועוד יציאה ברירת מחדל, טבלה מלאה מוסיפה עלות בלי להוסיף דרישה. זו שאלה מסחרית, והיא ראויה לתשובה בכתב ולא להנחה שעברה בירושה מהעיצוב הקודם. אם השירות באמת זקוק להזנה לצורכי מדיניות או לבחירת יציאה מקומית, הפוך אותה לסעיף מפורש עם הקצאת קיבולת משלו והתנהגות כשל משלו.
מתי תיוג לכל VRF הוא ברירת המחדל הנכונה
זו ברירת מחדל טובה כאשר הפלטפורמה מתעדת אותה כנתמכת, כאשר מספר המסלולים ב-VRF גדול, וכאשר עלות החיפוש ביציאה מקובלת עבור פרופיל התעבורה. היא גם ההתאמה הטבעית כאשר פשטות תפעולית חשובה יותר מאשר לסחוט את המיקרושנייה האחרונה מההעברה, כי תווית אחת לכל שוכר קלה יותר להסבר ולביקורת מתווית לכל prefix.
זו ברירת המחדל הלא נכונה כאשר התיעוד של הפלטפורמה קושר את התכונה לאילוצי חומרה או מהדורה מסוימים, או כאשר העיצוב תלוי בהחלטות העברה לכל prefix ביציאה. קרא את הפניה ל-statement של הפלטפורמה לפני שאתה מניח את ההתנהגות; פקודת Junos מתועדת, אבל מגבלות החומרה והמהדורה שסביבה הן שקובעות בפועל את הפריסה.
תקציב שאתה יכול להגן עליו
בנה את מקרה הקיבולת כחמישה מספרים נפרדים: נתיבים שהתקבלו, מסלולים שנבחרו, רשומות העברה מותקנות, תוויות שירות ותוויות תעבורה. הוסף מצב next-hop וסמיכות, מספר השוכרים ומודל היתירות. תמונת מצב של המסלול המהיר ב-VRF אחד אינה נתון קנה מידה, וגודל נומינלי של מרחב תוויות אינו טבלת חומרה זמינה.
לאחר מכן סכם גם את מצב הכשל ולא רק את המצב היציב. מה קורה כשההזנה גדלה בחצי, כששוכר מוסיף VRF שני, או כשהפלטפורמה זקוקה לאתחול כדי לשנות את גודל הטבלה? תקציב שעומד בשאלות האלה שווה יותר ממספר תוויות שעובד רק על הנייר.
בחר את ההקצאה לפי פעולת היציאה ומגבלות הפלטפורמה, ואז הפוך את הזנת המסלולים להחלטת שירות מפורשת. התווית היא החלק הנראה לעין של העיצוב; המסלולים הם החלק שיש לשלם עליו כל יום.