מנהרת RSVP-TE פעילה, אבל ל-L3VPN של הלקוח אין נתיב
הובלה ושירות הם שני החלטות נפרדות. קראו את מחסנית התוויות, בדקו בנפרד את פתרון הקפיצה הבאה ואת חיבור ה-VRF, ואז בדקו זרימת לקוח אמיתית אחת.
שני צוותים יכולים להיות צודקים בו-זמנית כאשר הלקוח מדווח שה-VPN למטה וצוות ההובלה מדווח שהמנהרה תקינה. LSP עם הנדסת תעבורה ו-MPLS L3VPN עונים על שאלות שונות: האחד מעביר מנות מתויגות דרך הליבה, האחר מחליט לאיזה הקשר ניתוב שייכת המנה. כאשר מבלבלים ביניהם, הוויכוח מסתובב במעגלים, כי כל צד מודד אובייקט אחר ושתי המדידות תקפות.
הובלה למעלה ושירות למטה הם מצב רגיל
LSP יכול להיות מוקם, לשאת תעבורה ולהיראות בכל מערכת ניטור, בעוד שירות הלקוח נשאר בלתי שמיש. אין דבר סותר בשילוב הזה, כי למנהרה אין דעה בשאלה אם קידומת מרוחקת קיימת, אם מדיניות ייבוא קיבלה אותה או אם המעגל המחובר מעביר מסגרות.
התסמין שחושף בדרך כלל את הבלבול אינו סימטרי: פינגים מה-loopback של ה-PE מצליחים בעוד שמארח ברשת ה-LAN של הלקוח לא מקבל דבר, או להפך. רשמו אילו כתובות עבדו לפני שאתם בונים תיאוריה. ברגע שאתם מבחינים שאתם בודקים שני אובייקטים שונים, הצעד הבא הוא לקרוא את מחסנית התוויות במקום להתווכח איזה גרף נכון. שתי כתובות, שני בעלים ובדרך כלל שני אנשים שונים שכל אחד מהם מאמין שהאחר שבר משהו.
קראו את המחסנית כשתי אחריויות
התווית התחתונה שייכת לשירות והתווית העליונה שייכת לנתיב. RFC 4364 מתאר את הרצף בפשטות: תחילה מוחלת תווית נתיב ה-VPN, ואז אותה מנה מתויגת מנותבת במנהרה לעבר קפיצת ה-BGP הבאה, ושם מנהרת הנדסת תעבורה דוחפת את התווית שלה מעל.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
ב-PE המרוחק תווית השירות בוחרת את הטיפול, שעשוי להיות חיפוש VRF או החלטת חיבור. לא ניתן להחליף את התווית הזו בתווית שפשוט חוצה את הליבה, ושתיהן אינן ניתנות להחלפה גם כאשר שתיהן מופיעות באותה מחסנית על אותו ממשק.
מה הצלחת RSVP מוכיחה ומה לא
RSVP-TE מקים LSP עם ניתוב מפורש, עם או בלי הזמנת משאבים, וזהו ערובה קונקרטית ושימושית לגבי הנתיב שמנה עוברת דרך הליבה. זו אינה אמירה על נתיבי הלקוח, ושם מנהרה מוגדר אינו נתיב כלל.
גם נוכחות RSVP אינה מספקת הבטחת ביצועים מקצה לקצה. הזמנת רוחב פס על LSP אחד אינה אומרת דבר על המעגל המחובר, על קו הגישה של הלקוח עצמו או על התנהגות התור בקצה המרוחק. התייחסות אליה כערובה מייצרת תשובות בטוחות לשאלות שאיש לא שאל. אם הדרישה היא באמת התחייבות לרוחב פס, יש להרכיב אותה מהחלקים שבאמת אוכפים התחייבות כזו, וה-LSP הוא רק אמצע השרשרת.
בדקו לפי הסדר, ואז עצרו
עבדו מההובלה כלפי חוץ ועצרו בצעד הראשון שנכשל, כי כל צעד מאוחר מניח שהקודמים החזיקו. ראשית אשרו שה-LSP הוקם ושהרשומה להעברה של קידומת השירות באמת מצביעה עליו. אחר כך אשרו שנתיב ה-VPN קיים בטבלה הנכונה, שקשירת התווית שלו נוכחת ושמדיניות הייבוא קיבלה אותו. אחר כך אשרו את החיבור: הממשק, הכימוס ובמקום שהוא חל, מזהה ה-VLAN ששייך לחוזה הזה.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERתחביר הפקודות משתנה לפי הפלטפורמה, לכן התייחסו לארבע השורות האלה כאל ארבע השאלות ולא כאל סקריפט. החלק החשוב הוא שכל אחת מהן חוקרת אובייקט אחר, וזה מה שגורם לכשל להצביע על בעלים מסוים.
עקבו אחר בקשה מורשית אחת ושמרו את הראיות הטובות
סיימו בבקשת לקוח אמיתית אחת, שהמדיניות מתירה, ובתשובה שלה. זרימה אחת שעובדת מקצה לקצה מכריעה יותר מעמוד של קריאות מונים, והיא מתרגלת את השילוב ולא כל חלק בנפרד.
כאשר שלב מאוחר נכשל, שמרו את תצפית ה-LSP המוצלחת במקום לבנות מחדש את ההובלה. בנייה מחדש של מנהרה עובדת אינה יכולה לתקן קידומת מרוחקת חסרה, חיבור VRF שגוי או כלל גישה ליעד, והיא הורסת את הראיה שאמרה לכם מלכתחילה שההובלה בריאה.