הטענה שמולטי־פאת' בעלות שווה חסר תועלת עבור נתיב מארח חוזרת לעתים קרובות מספיק כדי להישמע נכונה. /32 בוחר כתובת יעד, ושום דבר בבחירה הזו אינו מגביל את החבילה לקישור פיזי אחד. כאשר היעד הוא נקודת קצה מרוחקת של מנהרת VXLAN, כמה צעדים הבאים יכולים לשאת זרמי שכבת־על שונים, והאם הם עושים זאת תלוי במה שמותר לגיבוב השידור לראות. השאר הוא אריתמטיקה על הכותרת החיצונית, לא תכונה של הקידומת.

הנתיב קובע נגישות; הגיבוב קובע פיזור.

המיתוס: /32 פירושו נתיב אחד

OSPF יכול לדווח על נגישות בעלות שווה אל loopback של VTEP בעוד טבלת השידור מתקינה קבוצה של צעדים הבאים לאותה קידומת. הפרוטוקול מספק את המועמדים; הפלטפורמה מחליטה אילו מהם שמישים וכיצד מוקצית חבילה. שום פרוטוקול ניתוב אינו מחשב גיבוב חדש לכל מסגרת עטופה. ההפרדה הזו היא הסיבה לכך ששני נתבים עם נתיבים זהים עדיין יכולים לפזר תעבורה אחרת.

הסתכלו על רשומת השידור המותקנת ולא רק על תצוגת הנתיב, מכיוון שמגבלות חומרה או מדיניות יכולות להפיל מועמדים שמישור הבקרה עדיין מפרסם.

מניין האנטרופיה חייבת לבוא

בין שני VTEP-ים כתובות המקור והיעד החיצוניות נשארות קבועות, ופורט היעד של UDP הוא 4789 בפריסה מקובלת. גיבוב שקורא רק את הערכים האלה רואה קלט קבוע ומחזיר נתיב קבוע. משהו בכותרת החיצונית חייב להשתנות, וה־VTEP הוא ההתקן שיכול לגרום לכך.

RFC 7348 מציע לגזור את פורט המקור של UDP משדות בתוך המסגרת העטופה. אז שיחות פנימיות שונות מייצרות טאפלים חיצוניים שונים, מה שנותן לגיבוב תעבורה רגיל משהו לעבוד איתו.

אם חומרת השידור יכולה להביט עמוק יותר לתוך החבילה, בדקו אילו שדות פנימיים המימוש של הגיבוב שלה תומך בהם. אין להתייחס לעומק הזה כדרישה לכל התקן underlay, שכן שוני בפורט המקור לבדו כבר חושף הבדלים שימושיים.

בדקו את הגיבוב שאתם באמת מקבלים

מדדו במקום להניח. לכדו דגימה של תעבורה עטופה והביטו בפורטי המקור החיצוניים, ואז השוו את התוצאה לרשומות השידור ולמונים לכל קישור.

show ip route 10.255.0.5/32
show ip cef 10.255.0.5 internal
ip route show 10.255.0.5
tcpdump -ni eth0 -c 200 'udp port 4789' -vv

פורט מקור אחד שמופיע בשיחות פנימיות רבות ושונות פירושו שה־VTEP אינו משנה את השדה, ושום כוונון underlay לא יפזר את העומס. פורטים נבדלים רבים עם צעד הבא אחד בשימוש מצביעים במקום על קבוצת השידור.

רשמו את המונים לפני הדגימה ואחריה, וציינו תעבורה לא קשורה שחולקת את קישורי ה־uplink, אחרת המספרים ייראו גרועים ממה שהגיבוב ראוי לו.

מה פיזור אחיד אינו אומר

גיבוב לכל זרם נועד להשאיר שיחה אחת על נתיב אחד כל עוד הקלטים שלו וקבוצת הנתיבים הזמינה נשארים ללא שינוי. לכן העברת TCP גדולה אחת אינה מאגדת כל קישור uplink, והוספת קישורים לא תאיץ את הזרם הזה. זו התנהגות רגילה, לא תקלה.

כמה זרמים יכולים גם להתנגש באותו צעד הבא במקרה. דגימה קצרה יכולה להיראות מוטה מאוד בעוד הגיבוב עושה בדיוק את מה שהוגדר לו, וכשל בקישור או שינוי בקבוצת הנתיבים יכול להעביר זרמים מבוססים באמצע העברה.

בדקו עם זוגות כתובות, תעבורות וקצבים מייצגים לפי תוכנית מאושרת, והפרידו את בחירת חברי אגירת הקישורים מבחירת מולטי־פאת' מנותב, מכיוון ששני שלבי גיבוב מרכיבים תבנית משלהם. קבוצת צעדים הבאים מלאה יחד עם אנטרופיה חיצונית גלויה מסבירות את התוצאה; אורך הקידומת לא.

מאמרים קשורים