QoS לכל מנהרה אינו מגביל את סך ה-uplink של ה-hub שלכם

האמונה נשמעת כמו חשבון: חמישה spokes שכל אחד מהם מעוצב ל-5 Mbit/s, ולכן ה-hub נושא 25 Mbit/s לכל היותר. המחצית הראשונה נכונה והמסקנה לא. מדיניות לכל מנהרה מוחלת פעם אחת לכל מנהרה, לא פעם אחת לכל hub, וה-uplink המשותף שכל חמשת המנהרות חוצות אותו אינו מופיע לעולם באותו חישוב. העומס על ה-uplink שורד בדיוק כפי שהיה.

מאיפה מגיעה האמונה

הבלבול מובן, מפני שמידע קבוצת NHRP מאפשר להגדרת מדיניות אחת לחול על קבוצה שלמה של spokes. זה נקרא כמו תקציב משותף בקובץ תצורה. מה שזה באמת אומר הוא שכל spoke מקבל מופע משלו של אותה הגדרה.

אז 5 Mbit/s לכל spoke הוא תקרה לכל מנהרה, ויש תקרות כמספר המנהרות.

מה מופע מדיניות אחד שולט בו

מדריך Cisco ל-QoS לכל מנהרה ב-DMVPN ב-IOS XE מתאר מדיניות יציאה מה-hub שנבחרת באמצעות מידע קבוצת NHRP ומוחלת בנפרד על כל spoke. מהמשפט הזה נובעות שתי מגבלות, ושתיהן מתעלמות. הקצב שייך ל-spoke אחד ולא לדלי משותף, והתכונה שולטת בתעבורה מה-hub אל ה-spoke, ולא ההפך.

תכננו את כיוון השליחה של ה-spoke בנפרד. שום דבר במדיניות יציאה מה-hub לא מגביל את מה שסניף מעלה.

הציבו את המגבלה המצטברת בצוואר הבקבוק המשותף

המצטבר חייב להיות מעוצב במקום שבו הוא באמת מתחרה: בממשק הפיזי שכל המנהרות חולקות. Cisco מתעדת shaper מסוג class-default בממשק הפיזי כמדיניות הפיזית המקבילה הנתמכת עבור תכונה זו, וזו אמירה צרה יותר מכל היררכיה שאתם יכולים להקליד. הניחו שהמדיניות הפיזית השנייה השרירותית שהמצאתם אינה נתמכת עד שמישהו יוכיח אחרת.

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

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

המונים משקרים בדרך מסוימת אחת

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

העתקת דוגמת traffic-shape ישנה לצד מפת מדיניות לא קשורה אינה מוכיחה ששני הקצבים שולטים באותן חבילות.

בדקו את המצטבר, לא רק את התקרה

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

התיקון בנקודה הזו הוא החלטת קיבולת או קבלה. כוונון מחדש של המספרים לכל spoke רק משנה איזה סניף מתלונן ראשון.