PIM-SM דרך VPN: לבדוק BSR, מיפוי RP ונתיבי RPF

המנהרה פעילה, פינגים של unicast עוברים דרכה, והמקלט עדיין מציג מסך שחור. בפריסת PIM-SM התסמין הזה כמעט תמיד אומר שאחד מארבעה נתיבי בקרה שבור, ושנתיב הנתונים מעולם לא היה הבעיה. עברו על הרשימה שלמטה לפי הסדר ועצרו בצעד הראשון שנכשל, כי כל צעד מאוחר תלוי בקודם לו. אני שומר את חמש הבדיקות האלה בקובץ טיוטה ומדביק אותן במסוף כשמגיעה תלונת multicast, וזה מונע מהאבחון להפוך לניחושים.

מתחילים במקלט, לא במנהרה

מקלט שמעולם לא ביקש את הקבוצה לא יוצר שום מצב באף נתב, לכן אשרו שההצטרפות קיימת בקטע הפונה למקלט לפני שאתם בודקים כל דבר אחר. בפלטפורמות בסגנון Cisco, show ip igmp groups בנתב הקפיצה האחרונה מדפיס את הקבוצות שהצטרפו לצד הממשק ששמע אותן. כשהקבוצה חסרה בפלט הזה, המנהרה היא הסחה: הבקשה מתה במתג הגישה, בשקע של המארח או ב-VLAN בלי querier.

שתי סיבות שגרתיות מסבירות את רוב ההצטרפויות החסרות שראיתי: אי-התאמה בגרסת IGMP בין המארח לנתב, ובחירת querier שנחתה על מתג שאינו מנתב. סיבה שלישית עדינה יותר: הקבוצה מצורפת אבל ב-VLAN הלא נכון, כי למארח יש שני כרטיסי רשת והאפליקציה נקשרה לשגוי. במקלטי IPv6 הבעיה המקבילה היא עם MLD, שם show ipv6 mld groups עונה על אותה שאלה. אף אחת מאלה לא מתוקנת בנגיעה במנהרה, וזו בדיוק הסיבה לכך שהסדר חשוב.

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

האם קבוצת BSR מגיעה לצד השני?

הודעות Bootstrap Router נעות קפיצה אחר קפיצה בתוך תחום PIM אחד, וזה הכיוון שנשבר דרך מנהרה. מועמדי RP שולחים את המודעות שלהם ל-BSR הנבחר ב-unicast, ולכן הקטע RP עד BSR שורד בדרך כלל מנהרה עובדת ללא שינוי. הצפת הודעות Bootstrap בכיוון השני תלויה בכך שכל ממשק ביניים מפעיל PIM, ובכך ששום דבר לא עוצר את ההודעות בגבול. RFC 5059 מגדיר את התפוצה הזו ואת גבולות ההיקף המנהלי שמותר לקצר אותה.

הצהרת ip pim bsr-border, ACL שמסנן פרוטוקול 103, או מנהרת IPsec מבוססת מדיניות שאינה יכולה לשאת multicast, כל אחד מהם יחתוך את ההצפה בזמן ש-unicast נשאר שלם. השילוב הזה הוא מה שגורם לתקלה להיראות כמו בעיית RP כשהיא בעצם בעיית נגישות, ולכן אני קורא את מצב BSR לפני שאני קורא את תצורת ה-RP.

בנתב בצד המרוחק, show ip pim bsr-router מציין את ה-BSR הנבחר ואת קבוצת ה-RP שנלמדה; אם הפלט ריק, הצד המרוחק יושב בתחום משלו ואף כמות של תצורת RP לא תיישב את השניים. השוו את טווחי הקבוצות ואת כתובות ה-RP ב-show ip pim rp mapping משני צדי המנהרה. מיפוי שקיים רק באופן מקומי יוצר עץ משותף שמסתיים במקום הלא נכון, והמקלט ממתין לנצח.

התאימו את מיפוי ה-RP משני צדי המנהרה

RP סטטי, BSR ו-anycast-RP הם שלוש דרכים לענות על אותה שאלה, וערבובם דרך מנהרה הוא דרך אמינה לבנות תחום שלעולם לא מתכנס. אם הקצה הראשי משתמש ב-BSR והסניף משתמש ב-ip pim rp-address סטטי שמצביע לכתובת אחרת, הסניף בונה את העץ המשותף שלו אל RP שאין לו מושג שהמקלט קיים. המיפוי חייב להתאים גם בטווח הקבוצה וגם בכתובת, שכן טווח ספציפי יותר מנצח טווח רחב יותר.

Anycast-RP קיים בדיוק כדי ששני אתרים יוכלו לחלוק כתובת RP אחת, וכדאי להזכיר אותו כאן כי הוא משנה את המשמעות של «אותו RP». שני RP שמכריזים על כתובת אחת עקביים מלכתחילה; שני RP שמכריזים על כתובות שונות לאותו טווח אינם כאלה, לא משנה כמה בריא נראה כל אתר בפני עצמו.

עבור multicast ספציפי-למקור בתוך 232.0.0.0/8, אין פונים ל-RP לעולם, ולכן מיפוי RP ריק אינו תקלה אוטומטית. החליטו באיזה מודל שירות משתמשת האפליקציה לפני שאתם רודפים אחרי RP שלא היה נחוץ מעולם.

קראו את חיפוש ה-RPF לעבר המקור

PIM בונה עץ על ידי היפוך נתיב ה-unicast, ולכן הבדיקה שחשובה היא המסלול חזרה אל המקור, או חזרה אל ה-RP עבור עץ משותף. הצטרפות שמגיעה בממשק שהנתב אינו מחשיב כמעלה נזרקת, והסיבה נרשמת ככשל RPF ולא ככשל מנהרה. בנתב סניף שיש לו מסלול ברירת מחדל דרך המנהרה ומסלול ספציפי יותר דרך ה-WAN, ממשק ה-RPF יכול בקלות להיות ה-WAN אף שהמקור נגיש רק דרך המנהרה. זו הסיבה הנפוצה ביותר להשלכה שקטה של הצטרפות.

show ip rpf 192.0.2.10 מדפיס את הממשק הנבחר, את הקפיצה הבאה ואת המסלול שיצר את ההחלטה, ובדרך כלל זה מספיק כדי לראות את אי-ההתאמה. מסלול multicast סטטי כמו ip mroute 192.0.2.0 255.255.255.0 tunnel0 עוקף את חיפוש ה-unicast עבור אותו קידומת, וזה תיקון לגיטימי כשטופולוגיית ה-multicast באמת שונה מטופולוגיית ה-unicast. התייחסו אליו כתצורה שצריך לתעד, לא כטלאי שהוחל בזמן תקלה ואחר כך נשכח.

אשרו את ההצטרפות בפקודות, לא בפינג

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

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

רשומת (S,G) מלאה עם ממשק נכנס אמיתי ורשימת יוצא לא ריקה אומרת שמישור הבקרה סיים את עבודתו. רשומה שממשק הכניסה שלה נקרא Null, או מונה עם תווית RPF failed שממשיך לטפס, מצביע חזרה לקטע הקודם ולא למנהרה.

אם כל חמש הפקודות נראות נכונות והמקלט עדיין לא רואה דבר, החשוד שנותר הוא המדיניות של המנהרה עצמה: ACL הצפנה או כלל חומת אש שמתיר את פרוטוקול הניתוב unicast אבל לא PIM, IGMP או תעבורת הקבוצה עצמה. במנהרת IPsec מבוססת מדיניות, multicast אינו נישא כלל, ולכן התשובה היא תכנון GRE או VTI ולא עוד חריג בפילטר. רשמו איזו מחמש הבדיקות נכשלה לפני שאתם משנים משהו, ואז שנו רק את השכבה הזו.