כיצד פועל פרוטוקול PIM

פרוטוקול PIM הוא קבוצה של פרוטוקולים להעברת שידור מרובים ברשת בין נתבים. קשרי שכונה נבנים באותו אופן כמו במקרה של פרוטוקולי ניתוב דינמיים. PIMv2 שולח הודעות Hello כל 30 שניות לכתובת השידור השמורה 224.0.0.13 (All-PIM-Routers). ההודעה מכילה Hold Timers - בדרך כלל שווה ל-3.5*Hello Timer, כלומר 105 שניות כברירת מחדל.

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

R3 יזהה את מקור השידור הרב-שידור (מקור IP) מהודעת השידור הרב-שידור ויבדוק את שני הזרימות מ-R1 ו-R2 באמצעות טבלת ה-unicast שלו. הזרם מהממשק שאליו מצביע הטבלה (R1 עד R3) ישודר הלאה, והזרם מ-R2 יושמט, שכן על מנת להגיע למקור השידור הרב-שידור, צריך לשלוח מנות דרך S0/1.
השאלה היא, מה קורה אם יש לך שני מסלולים שווים עם אותו מדד? במקרה זה, הנתב יבחר את הקפיצה הבאה מתוך המסלולים הללו. מי שיש לו את כתובת ה-IP הגבוהה יותר מנצח. אם אתה צריך לשנות התנהגות זו, אתה יכול להשתמש ב-ECMP. פרטים נוספים כאן.
לאחר בדיקת כלל ה-RPF, הנתב שולח חבילת ריבוי שידור לכל שכני ה-PIM שלו, מלבד זה שממנו התקבלה החבילה. נתבי PIM אחרים חוזרים על תהליך זה. הנתיב שחבילת שידור מרובה לקחה מהמקור לנמענים הסופיים יוצר עץ הנקרא עץ הפצה מבוסס מקור, עץ הנתיב הקצר ביותר (SPT), עץ מקור. שלושה שמות שונים, בחר כל אחד.
איך פותרים את הבעיה שחלק מהנתבים לא ויתרו על זרם מולטיקאסט כלשהו ואין למי לשלוח אותו, אבל הנתב במעלה הזרם שולח לו. בשביל זה הומצא מנגנון Prune.
הודעת גזם.
לדוגמה, R2 ימשיך לשלוח ריבוי שידור ל-R3, למרות ש-R3, לפי כלל ה-RPF, מוריד אותו. למה לטעון את הערוץ? R3 שולח הודעת PIM Prune ו-R2, עם קבלת הודעה זו, יסיר את הממשק S0/1 מרשימת הממשקים היוצאים עבור זרימה זו, רשימת הממשקים שמהם יש לשלוח את התעבורה הזו.

להלן הגדרה רשמית יותר של הודעת PIM Prune:
הודעת PIM Prune נשלחת על ידי נתב אחד לנתב שני כדי לגרום לנתב השני להסיר את הקישור שעליו ה-Prune מתקבל מ-SPT מסוים (S,G).

לאחר קבלת הודעת Prune, R2 מכוון את טיימר ה-Prune ל-3 דקות. לאחר שלוש דקות, הוא יתחיל לשלוח שוב תנועה עד שיקבל הודעת Prune נוספת. זה ב-PIMv1.
וב-PIMv2 נוסף טיימר State Refresh (60 שניות כברירת מחדל). ברגע שנשלחה הודעת Prune מ-R3, טיימר זה מופעל ב-R3. עם פקיעת טיימר זה, R3 ישלח הודעת רענון מצב, שתאפס את טיימר הגזם של 3 דקות ב-R2 עבור קבוצה זו.
סיבות לשליחת הודעת Prune:

• כאשר חבילת שידור מרובה נכשלת בבדיקת ה-RPF.
• כאשר אין לקוחות מחוברים מקומית שביקשו קבוצת ריבוי שידורים (IGMP Join) ואין שכני PIM שאליהם ניתן לשלוח תעבורת ריבוי שידורים (Non-prune Interface).

הודעת שתל.
בואו נדמיין ש-R3 לא רצה טראפיק מ-R2, שלח את Prune וקיבל מולטי-שידור מ-R1. אבל פתאום, הערוץ בין R1-R3 נפל ו-R3 נותר ללא מולטיcast. אתה יכול להמתין 3 דקות עד שתוקף טיימר הגזם ב-R2 יפוג. 3 דקות זה המתנה ארוכה, כדי לא לחכות, צריך לשלוח הודעה שתוציא מיד את ממשק S0/1 זה ל-R2 ממצב הגזום. הודעה זו תהיה הודעת Graft. לאחר קבלת הודעת Graft, R2 יגיב עם Graft-ACK.
ביטול גזם.

הבה נתבונן בתרשים הזה. R1 משדר שידור רב לקטע עם שני נתבים. R3 קולט ומשדר תנועה, R2 קולט, אבל אין למי לשדר תנועה. זה שולח הודעת Prune ל-R1 בקטע הזה. R1 אמור להסיר את Fa0/0 מהרשימה ולהפסיק לשדר בקטע הזה, אבל מה יקרה ל-R3? ו-R3 נמצא באותו קטע, גם קיבל את ההודעה הזו מפרון והבין את הטרגדיה של המצב. לפני ש-R1 מפסיק לשדר, הוא מגדיר טיימר של 3 שניות ויפסיק לשדר לאחר 3 שניות. 3 שניות - זה בדיוק כמה זמן יש ל-R3 כדי לא לאבד את השידור שלו. לכן, R3 שולח הודעת Pim Join לקבוצה זו בהקדם האפשרי, ו-R1 כבר לא חושב להפסיק את השידור. אודות הודעות הצטרפו למטה.
הודעה טענה.

בואו נדמיין את המצב הזה: שני נתבים משדרים לרשת אחת בבת אחת. הם מקבלים את אותו זרם מהמקור, ושניהם משדרים אותו לאותה רשת מאחורי ממשק e0. לכן, הם צריכים לקבוע מי יהיה השדר האחד והיחיד עבור רשת זו. הודעות Assert משמשות לכך. כאשר R2 ו-R3 מזהים כפילות של תעבורת מולטי-שידור, כלומר, מגיעה מולטי-שידור ל-R2 ו-R3, שהם עצמם משדרים, הנתבים מבינים שמשהו כאן לא בסדר. במקרה זה, נתבים שולחים הודעות Assert, הכוללות מרחק מנהלי ומדד המסלול איתו מגיעים למקור השידור הרב-שידור - 10.1.1.10. הזוכה נקבע באופן הבא:

1. זה עם AD נמוך יותר.
2. אם AD שווים, אז למי יש המדד הנמוך יותר.
3. אם יש כאן שוויון, אז זה שיש לו את ה-IP הגבוה יותר ברשת שאליה הוא משדר את השידור הזה.

הזוכה בהצבעה זו הופך לנתב המיועד. Pim Hello משמש גם לבחירת DRs. בתחילת הכתבה הוצגה הודעת PIM Hello, ניתן לראות שם את שדה ה-DR. זה עם כתובת ה-IP הגבוהה ביותר בקישור הזה מנצח.
סימן שימושי:

טבלת MROUTE.
לאחר מבט ראשוני כיצד פועל פרוטוקול PIM, עלינו להבין כיצד לעבוד עם טבלת ניתוב ריבוי שידורים. טבלת mroute מאחסנת מידע על אילו זרמים התבקשו מלקוחות ואילו זרמים זורמים משרתי שידור מרובי.
לדוגמה, כאשר מתקבל דוח חברות IGMP או PIM Join בממשק כלשהו, ​​מתווספת רשומה מסוג (*, G ) לטבלת הניתוב:

ערך זה אומר שהתקבלה בקשת תעבורה עם הכתובת 238.38.38.38. דגל ה-DC אומר שה-multicast יפעל במצב Dense ו-C אומר שהנמען מחובר ישירות לנתב, כלומר הנתב קיבל את IGMP Membership Report ו-PIM Join.
אם יש רשומה מסוג (S,G) זה אומר שיש לנו זרם ריבוי שידור:

בשדה S - 192.168.1.11, רשמנו את כתובת ה-IP של מקור השידור הרב-שידורי, היא זו תיבדק על ידי כלל RPF. אם יש בעיות, הדבר הראשון שעליך לעשות הוא לבדוק את טבלת unicast עבור המסלול למקור. בשדה ממשק נכנס, מציין את הממשק שאליו מתקבלת השידור הרב-שידור. בטבלת ניתוב unicast, המסלול למקור חייב להתייחס לממשק שצוין כאן. הממשק היוצא מציין לאן השידור הרב-שידור יופנה מחדש. אם הוא ריק, אז הנתב לא קיבל כל בקשות לתעבורה זו. ניתן למצוא מידע נוסף על כל הדגלים כאן.
PIM Sparse-mode.
האסטרטגיה של Sparse-mode היא הפוכה מ-Dense-mode. כאשר Sparse-mode מקבל תעבורת ריבוי שידורים, הוא ישלח תעבורה רק דרך אותם ממשקים שבהם היו בקשות לזרימה זו, למשל הודעות Pim Join או IGMP Report המבקשות תעבורה זו.
אלמנטים דומים עבור SM ו-DM:

• קשרי שכונה נבנים באותו אופן כמו ב-PIM DM.
• כלל RPF עובד.
• הבחירה ב-DR דומה.
• המנגנון של הודעות Prune Overrides ו-Asert דומה.

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

בואו נדמיין טופולוגיה שבה RP הוא R3. ברגע ש-R1 מקבל תעבורה מ-S1, הוא עוטף חבילת ריבוי שידור זו להודעת unicast PIM Register ושולח אותה ל-RP. איך הוא יודע מי ה-RP? במקרה זה, הוא מוגדר באופן סטטי, ונדבר על תצורת RP דינמית מאוחר יותר.

ip pim rp-address 3.3.3.3

RP יסתכל - האם היה מידע ממישהו שהיה רוצה לקבל את התעבורה הזו? בוא נניח שזה לא היה. ואז RP ישלח ל-R1 הודעת PIM Register-Stop, מה שאומר שאף אחד לא צריך את השידור הזה, הרישום נדחה. R1 לא ישלח שידור רב. אבל מארח מקור השידור הרב-שידור ישלח אותו, כך ש-R1, לאחר קבלת Register-Stop, יתחיל טיימר רישום-דיכוי השווה ל-60 שניות. 5 שניות לפני שהטיימר יפוג, R1 ישלח הודעת Register ריקה עם סיביות Null-Register (כלומר, ללא חבילת ריבוי שידור מכוסה) לכיוון RP. RP, בתורו, יפעל כך:

• אם לא היו נמענים, הוא יגיב בהודעת הרשמה-עצירה.
• אם יופיעו נמענים, הוא לא יגיב לכך בשום אופן. R1, לאחר שלא קיבל סירוב להירשם תוך 5 שניות, ישמח וישלח הודעת Register עם שידור מולטי שידור מובלע ל-RP.

נראה שהבנו איך שידור רב-שידור מגיע ל-RP, עכשיו בואו ננסה לענות על השאלה כיצד RP מספק תעבורה לנמענים. כאן יש צורך להציג מושג חדש - עץ שורש-נתיב (RPT). RPT הוא עץ המושרש ב-RP, הגדל לעבר הנמענים, מסתעף על כל נתב PIM-SM. RP יוצר אותו על ידי קבלת הודעות PIM Join ומוסיף ענף חדש לעץ. וכך, כל נתב במורד הזרם עושה זאת. הכלל הכללי נראה כך:

• כאשר נתב PIM-SM מקבל הודעת PIM Join בכל ממשק מלבד הממשק שמאחוריו מוסתר ה-RP, הוא מוסיף ענף חדש לעץ.
• סניף נוסף גם כאשר נתב PIM-SM מקבל דוח חברות IGMP ממארח ​​מחובר ישירות.

בואו נדמיין שיש לנו לקוח מולטי-שידור בנתב R5 עבור קבוצה 228.8.8.8. ברגע ש-R5 מקבל את דוח החברות ב-IGMP מהמארח, R5 שולח PIM Join לכיוון ה-RP, ובעצמו מוסיף ממשק לעץ שמסתכל על המארח. לאחר מכן, R4 מקבל PIM Join מ-R5, מוסיף ממשק Gi0/1 לעץ ושולח PIM Join לכיוון RP. לבסוף, RP (R3) מקבל PIM Join ומוסיף Gi0/0 לעץ. לפיכך, נמען השידור הרב-שידור נרשם. אנחנו בונים עץ עם השורש R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
לאחר מכן, צירוף PIM יישלח אל R1 ו-R1 יתחיל לשלוח תעבורת שידור מרובה. חשוב לציין שאם המארח ביקש תעבורה לפני תחילת שידור השידורים הרב-שידורים, אז RP לא ישלח PIM Join ולא ישלח דבר ל-R1 בכלל.
אם פתאום בזמן שליחת multicast, המארח מפסיק לרצות לקבל אותו, ברגע ש-RP יקבל PIM Prune בממשק Gi0/0, הוא ישלח מיד PIM Register-Stop ישירות ל-R1, ולאחר מכן PIM Prune הודעה דרך ממשק Gi0/1. PIM Register-stop נשלח באמצעות unicast לכתובת שממנה הגיע ה-PIM Register.
כפי שאמרנו קודם לכן, ברגע שראוטר שולח PIM Join לאחר, למשל R5 ל-R4, אז מתווספת רשומה ל-R4:

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

נניח שתעבורה נשלחה והתקבלה לפי הסכמה הישנה R1-R2-R3-R4-R5, וכאן חיברנו והגדרנו את הממשק בין R1 ל-R5.
קודם כל, עלינו לבנות מחדש את טבלת הניתוב unicast ב-R5 וכעת מגיעים לרשת 192.168.1.0/24 דרך ממשק R5 Gi0/2. כעת R5, המקבל שידור רב בממשק Gi0/1, מבין שכלל ה-RPF אינו מרוצה וזה יהיה הגיוני יותר לקבל שידור רב ב-Gi0/2. הוא צריך להתנתק מ-RPT ולבנות עץ קצר יותר בשם Shortest-Path Tree (SPT). לשם כך, הוא שולח PIM Join ל-R0 דרך Gi2/1 ו-R1 מתחיל לשלוח שידור רב גם דרך Gi0/2. כעת R5 צריך לבטל את המנוי מ-RPT כדי לא לקבל שני עותקים. לשם כך, הוא שולח ל-Prune הודעה המציינת את כתובת ה-IP המקור ומכניס ביט מיוחד - RPT-bit. זה אומר שאתה לא צריך לשלוח לי תנועה, יש לי כאן עץ טוב יותר. RP שולח גם הודעות PIM Prune ל-R1, אך אינו שולח הודעת Register-Stop. תכונה נוספת: R5 ישלח כעת PIM Prune ברציפות ל-RP, שכן R1 ממשיך לשלוח PIM Register ל-RP בכל דקה. עד שלא יהיו אנשים חדשים שירצו את התעבורה הזו, RP יסרב לה. R5 מודיע ל-RP שהוא ממשיך לקבל שידור מרובים באמצעות SPT.
חיפוש RP דינמי.
אוטומטי-RP.
טכנולוגיה זו היא קניינית של סיסקו ואינה פופולרית במיוחד, אך עדיין חיה. פעולת RP אוטומטי מורכבת משני שלבים עיקריים:
1) RP שולח הודעות RP-Announce לכתובת השמורה - 224.0.1.39, ומצהיר על עצמו RP עבור כולם או עבור קבוצות ספציפיות. הודעה זו נשלחת כל דקה.
2) נדרש סוכן מיפוי RP, אשר ישלח הודעות RP-Discovery המציינים עבור אילו קבוצות יש להאזין ל-RP. מתוך הודעה זו נתבי PIM רגילים יקבעו בעצמם את ה-RP. סוכן המיפוי יכול להיות נתב RP עצמו או נתב PIM נפרד. RP-Discovery נשלח לכתובת 224.0.1.40 עם טיימר של דקה.
בואו נסתכל על התהליך ביתר פירוט:
בואו נגדיר את R3 כ-RP:

ip pim send-rp-announce loopback 0 scope 10

R2 כסוכן מיפוי:

ip pim send-rp-discovery loopback 0 scope 10

ובכל השאר נצפה ל-RP דרך Auto-RP:

ip pim autorp מאזין

ברגע שנגדיר את R3, הוא יתחיל לשלוח RP-Announce:

ו-R2, לאחר הגדרת סוכן המיפוי, יתחיל להמתין להודעת RP-Announce. רק כאשר הוא ימצא לפחות RP אחד הוא יתחיל לשלוח RP-Discovery:

כך, ברגע שהנתבים הרגילים (PIM RP Listener) מקבלים את ההודעה הזו, הם יידעו היכן לחפש את ה-RP.
אחת הבעיות העיקריות עם Auto-RP היא שכדי לקבל הודעות RP-Announce ו-RP-Discovery, צריך לשלוח PIM Join לכתובות 224.0.1.39-40, וכדי לשלוח, צריך לדעת לאן RP נמצא. בעיית עוף וביצה קלאסית. כדי לפתור בעיה זו, הומצא ה-PIM Sparse-Dense-Mode. אם הנתב לא יודע RP, אז הוא פועל במצב צפוף; אם כן, אז במצב Sparse. כאשר PIM Sparse-mode ופקודת ip pim autorp listener מוגדרות על ממשקים של נתבים רגילים, הנתב יפעל במצב Dense-mode רק לשידור רב ישירות מפרוטוקול Auto-RP (224.0.1.39-40).
נתב BootStrap (BSR).
פונקציה זו פועלת בדומה ל-Auto-RP. כל RP שולח הודעה לסוכן המיפוי, שאוסף מידע מיפוי ואז מודיע לכל שאר הנתבים. בואו נתאר את התהליך בדומה ל-Auto-RP:
1) ברגע שאנו מגדירים את R3 כמועמד להיות RP, עם הפקודה:

ip pim rp-candidate loopback 0

אז R3 לא יעשה כלום; כדי להתחיל לשלוח הודעות מיוחדות, הוא צריך קודם כל למצוא סוכן מיפוי. לפיכך, אנו עוברים לשלב השני.
2) הגדר את R2 כסוכן מיפוי:

ip pim bsr-candidate loopback 0

R2 מתחיל לשלוח הודעות PIM Bootstrap, שם הוא מציין את עצמו כסוכן מיפוי:

הודעה זו נשלחת לכתובת 224.0.013, שבה משתמש פרוטוקול PIM גם עבור שאר ההודעות שלו. זה שולח אותם לכל הכיוונים ולכן אין בעיה של תרנגולת וביצה כמו שהייתה באוטו-RP.
3) ברגע שה-RP יקבל הודעה מהנתב BSR, הוא ישלח מיד הודעת unicast לכתובת הנתב BSR:

לאחר מכן, ה-BSR, לאחר שקיבל מידע על ה-RPs, ישלח אותם ב-multicast לכתובת 224.0.0.13, לה מאזינים כל נתבי ה-PIM. לכן, אנלוגי של הפקודה ip pim autorp מאזין לנתבים רגילים שלא ב-BSR.
Anycast RP עם Multicast Source Discovery Protocol (MSDP).
Auto-RP ו-BSR מאפשרים לנו לחלק את העומס על RP באופן הבא: לכל קבוצת ריבוי שידור יש רק RP פעיל אחד. לא ניתן יהיה לחלק את העומס עבור קבוצת ריבוי שידור אחת על פני מספר RPs. MSDP עושה זאת על ידי הנפקת נתבי RP את אותה כתובת IP עם מסיכה של 255.255.255.255. MSDP לומד מידע באחת מהשיטות: סטטי, Auto-RP או BSR.

בתמונה יש לנו תצורת Auto-RP עם MSDP. שני ה-RPs מוגדרים עם כתובת IP 172.16.1.1/32 בממשק Loopback 1 ומשמשים עבור כל הקבוצות. עם RP-Announce, שני הנתבים מכריזים על עצמם באמצעות הפניה לכתובת זו. סוכן המיפוי של Auto-RP, לאחר שקיבל את המידע, שולח את RP-Discovery לגבי ה-RP עם הכתובת 172.16.1.1/32. אנו מספרים לנתבים על הרשת 172.16.1.1/32 באמצעות IGP ובהתאם לכך. לפיכך, נתבי PIM מבקשים או רושמים זרימות מה-RP שצוין בתור הקפיצה הבאה במסלול לרשת 172.16.1.1/32. פרוטוקול ה-MSDP עצמו מיועד ל-RPs עצמם כדי להחליף הודעות על מידע רב שידור.
שקול את הטופולוגיה הזו:

Switch6 משדר תעבורה לכתובת 238.38.38.38 ועד כה רק RP-R1 יודע על כך. Switch7 ו- Switch8 ביקשו את הקבוצה הזו. הנתבים R5 ו-R4 ישלחו את PIM Join אל R1 ו-R3, בהתאמה. למה? המסלול ל-13.13.13.13 עבור R5 יפנה ל-R1 באמצעות מדד IGP, בדיוק כמו עבור R4.
RP-R1 יודע על הזרם ויתחיל לשדר אותו לכיוון R5, אבל R4 לא יודע עליו כלום, שכן R1 לא פשוט ישלח אותו. לכן MSDP הוא הכרחי. אנו מגדירים אותו על R1 ו-R5:

ip msdp peer 3.3.3.3 connect-source Loopback1 ב-R1

ip msdp peer 1.1.1.1 connect-source Loopback3 ב-R3

הם יעלו סשן אחד לשני וכאשר יקבלו תזרים כלשהו הם ידווחו על כך לשכן ה-RP שלהם.
ברגע ש-RP-R1 יקבל זרם מ-Switch6, הוא ישלח מיד הודעת unicast MSDP Source-Active, שתכיל מידע כמו (S,G) - מידע על המקור והיעד של השידור הרב-שידור. כעת, כאשר RP-R3 יודע שמקור כגון Switch6, כאשר הוא מקבל בקשה מ-R4 לזרימה זו, הוא ישלח את PIM Join לכיוון Switch6, בהנחיית טבלת הניתוב. כתוצאה מכך, R1 שקיבל PIM Join כזה יתחיל לשלוח תנועה לכיוון RP-R3.
MSDP פועל על TCP, RPs שולחים זה לזה הודעות שמירה כדי לבדוק את החיים. הטיימר הוא 60 שניות.
הפונקציה של חלוקת עמיתים של MSDP לתחומים שונים נותרה לא ברורה, מכיוון שהודעות Keepalive ו-SA אינן מעידות על חברות באף תחום. כמו כן, בטופולוגיה זו, בדקנו תצורה המציינת תחומים שונים - לא היה הבדל בביצועים.
אם מישהו יכול להבהיר, אשמח לקרוא את זה בתגובות.

מקור: www.habr.com