פרוטוקול Spanning-Tree למתקדמים
show spanning-tree מציגה את ה-Root ID ואת ה-Bridge ID של המתג הנוכחי. כשהם זהים, המתג הנוכחי הוא ה-Root.spanning-tree cost.spanning-tree vlan 1 root primary: מוריד את העדיפות אוטומטית, כך שהמתג הופך ל-Root.spanning-tree vlan 1 root secondary: מגדיר מתג גיבוי שייהפך ל-Root אם הראשי נופל.spanning-tree vlan 1 priority: קביעה ידנית של עדיפות, בכפולות של 4096.spanning-tree mode עם האפשרות Rapid (Rapid per VLAN): מעביר את המתג מ-STP המקורי ל-Rapid.פרקי ההרצאה: פרוטוקול Spanning-Tree למתקדמים
תמלול ההרצאה: פרוטוקול Spanning-Tree למתקדמים
הטקסט המלא של הדקות הראשונות בהרצאה «פרוטוקול Spanning-Tree למתקדמים» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
פרק חמש, ספאנינג טרי פרוטוקול. פרוטוקול ספאנינג טרי הוא חלק חשוב מאוד מסמסטר שלוש וכל נושא של טיפול ברשת הלאן שלי, ומופיעות לא מעט שאלות על ספאנינג טרי בבחינת ה-CCNA.
רוב השאלות מתייחסות באמת למה התכונות העיקריות של ספאנינג טרי ואיך אנחנו מיישמים אותו, או אילו החלטות מקבל הסוויץ' בהקשר של פרוטוקול ספאנינג טרי.
עכשיו אנחנו בפרק הזה נדבר קודם כל בכלל מה זה אומר ספאנינג טרי. בגדול הפרוטוקול עצמו אמור למנוע לולאות ב-layer 2 שלנו, ברשת המקומית.
אוקיי, אנחנו נדבר על התכונות השונות של הפרוטוקול עצמו, למה הוא חשוב. נכיר את הסוגים השונים של הספאנינג טרינג, נעבור על קבלת ההחלטות של הסוויצ'ים, מתי הם חוסמים פורטים מסוימים, מתי הם מאפשרים למידע לעבור, ונתמקד בעיקר בכל נושא של קבלת ההחלטות באמת.
אם אנחנו עכשיו מחברים מספר סוויצ'ים יחדיו, מתי סוויץ' בוחר לחסום פורט אחד ולשחרר פורט אחר וכולי. אז ככה. דבר ראשון, מתי או למה יש לנו בכלל ספאנינג טרי?
ברשתות הלאן, כשדיברנו בתחילת הסמסטר, דיברנו על כל הנושא של Redundancy, כלומר מתי אנחנו רוצים ליישם שרידות ברמת הלאן שלנו, שזה אומר חיבור של מספר סוויצ'ים יחדיו.
אם לדוגמה יש לי, אני רוצה לבנות טופולוגיה פשוטה. דרך אגב, אני בפאקט טרסר אשתמש בהדגמות שלי בדגם של הסוויץ' 2960. הסיבה העיקרית זה בגלל המספור של הפורטים.
כמו שאתם רואים, המספור הוא 0102 וזה אומר שאם אני ארצה עכשיו לתחום מספר פורטים, אני יכול לעשות את זה באמצעות הפקודה אינטרפייס ריינג' וזה לעומת הסוויצ'ים שהם ג'נריק, שפה הפורטים עצמם, אתם רואים הצורה שבה הם
מוספרים והם לא מאפשרים לי לעשות את זה. אוקיי, אז זה הסוויץ' שבו אנחנו נשתמש. עכשיו יש לי מספר סוויצ'ים ואני רוצה ליצור Redundancy, כלומר שרידות ברמת החיבורים.
אוקיי, בואו ניקח את הטופולוגיה הבאה. להזכירכם, אם אנחנו מחברים רכיב מאותו סוג, אנחנו משתמשים בכבל קרוס. עכשיו, חלקכם מכירים כבר או זוכרים שדיברנו על תכונה שנקראת MDAX בציוד רשתות בעצם, ומאפשר לפורט עצמו לראות איזה סוג כבל אמור להיות מחובר אליו ולעשות את השינויים אצלו פנימית, כלומר בתוך הפורט, מבחינה אלקטרונית.
כלומר, אפילו אם נתקעתי בלי כבל קרוס, אני עדיין אוכל לחבר שני רכיבים יחדיו באמצעות כבל סטרייט.
אבל עדיין מבחינת סיסקו ובבחינת ה-CCNA חשוב להכיר את הכבילה השונה, שזה אומר, אם יש לנו שני רכיבים מאותו סוג, אנחנו נשתמש בכבל קרוס, אוקיי? אז בוא נתייחס לטופולוגיה הזאת כטופולוגיה שהצהרנו לטובת שרידות. נתעלם כרגע מהתחלות השונות, זה פחות חשוב.
ונמתין כרגע, אני רוצה שנגיע למצב שכל הנוריות ירוקות, ואז הנה, אוקיי. כמו שאנחנו רואים בטופולוגיה כאן, הנוריות הירוקות מציינות בעצם את הסטטוס של הפורט.
ירוק זה אומר שהוא כרגע במצב forwarding, אנחנו נראה את זה בהמשך, מה זה אומר. ויש לנו כאן פורט כתום. עכשיו, למה הפורט הזה קיים? כשאנחנו יוצרים רידנדסי או שרידות ברמת הלאן, אז ישנה רגישות מאוד גבוהה לנושא של ברודקאסטים.
כי מספיק שיש לנו הודעת ברודקאסט אחד, ברגע שזה מגיע לסוויץ', הסוויץ' מפיץ, הוא רואה את ה-Mac Destination בהודעת ברודקאסט, שזה הכל אפי, והוא מפיץ את זה לכל שאר הסוויצ'ים.
ומה שזה יכול ליצור לנו, אחרי כמה זמן, זה יכול ליצור לנו דבר שנקרא Broadcast Storm. כלומר, יש לנו, נקרא לזה לילה אינסופית, פריימים שנעים בצורה אינסופית בתוך הטופולוגיה שלי.
אז פרוטוקול הספנינגטרי בעצם נועד למנוע את זה, שזה אומר, גם אם אני אסיים שרידות ויש לי כביכול לולאות או חיבורים כפולים ברשת המקומית שלי, הסוויצ'ים מדברים ביניהם ומחליטים לחסום את אחד הפורטים.
פשוט בגלל זה אתם רואים אותו במצב הזה, בצבע כתום, ואז המידע זורם, בוא נגיד, בכיוון אחד, ואין לי כאן לופים ואין לי כאן כל הנושא של Broadcast Tome נמנע בטופולוגיה עצמה, אוקיי?
אז בגדול הפרוטוקול עצמו נועד למנוע לולאות ב-Layer 2. כשאנחנו מדברים על ראוטרים או כשאנחנו מדברים על מניעה של לופים ב-Layer 3, אז יש את כל הנושא של השדה של ה-TTL, דיברנו על זה, החלק מהשדה שיש לנו ב-IP פאקט, וה-TTL, השדה הזה, להזכירכם, מה שזה אומר כל נתב שבו עוד דרכו עובר הפאקט הנתב מפחית מהערך של ה-TTL הראשוני 1 ככה
שהראוטר שמקבל את הפאקט עם הערך TTL 1 מפחית ממנו 1 ועכשיו הוא רואה שהערך 0 אז הוא לא יעביר את הפאקט הלאה וככה הוא בעצם עוצר את לולאת הניתוב הזו אצלו אבל מבחינת layer 2 אנחנו נשתמש בספניטרי ספאניטרי כבר עובד כברירת מחדל בנתבים, כלומר איך שאנחנו מוציאים אותם, סליחה, בסוויצ'ים, איך שאנחנו מוציאים אותם מהקופסה.
ישר אין לנו צורך להגדיר דברים מיוחדים, הספאניטרי עובד ברקע בגלל החשיבות שלו. עכשיו, יש כל מיני תופעות שיכולות להיגרם בגלל המבנה הזה של הטופולוגיה, מעבר לנושא של broadcast term.
יכול להיות מצב גם של duplicate unicast frames, מה הכוונה? אם יש לנו, שוב, אני חוזר לטופולוגיה עצמה, בואו נסתכל שנייה בקוריקולום. פה זה לדוגמה מבנה דומה למה שציינתי, שבו יש לנו שרידות בטופולוגיה עצמה, ככה שאם קישור אחד נופל, אז תהיה לנו דרך נוספת להעביר את הפריים עצמו.
עכשיו, אז כמו שאמרנו, המבנה הזה של הטופולוגיה, יש לו גם חסרונות. הדבר הראשון, ציינתי, זה נושא של Broadcast Store, ועוד רגע אנחנו נתייחס, הנה פה יש לנו את הנושא של לולאות, ואנחנו נראה את הפריים עצמו כרגע, אוקיי, פה יש לנו גם את הנושא של הברודקאסט, זה מגיע לכל הסוויצ'ים, כל סוויצ' שמקבל את
הודעת ברודקאסט מפיץ את זה לכל שאר הסוויצ'ים, ומה שקורה, נוצר לנו פה מצב אינסופי שבו הפריים נעים ומעמיסים לנו על הרשת עד שבו הרשת עצמה כל כך עמוסה, או רוחב הפס שלה כל כך עמוס ככה שהרשת לא יכולה לעבוד בצורה תקינה, כל הרוחב פס שלנו מלא או תפוס לטובת הודעת ברודקאסט הזו, אוקיי?
הנה עוד דוגמה לנושא של ברודקאסטום, קצת יותר אקטיבי כאן, אנחנו יכולים לראות מה זה עושה לרשת, עד שהרשת למעשה כל כך עמוסה מבחינת תעבורה שלא ניתן להעביר יותר מידע.
עכשיו, הנושא של דופליקט יוניקאסט פריים זה גם תוצר לוואי של התצורה הזאת, של מצב שבו יש לנו רידנדנסי. אוקיי, בואו נראה, יש לנו פה את מחשב PC1, הוא רוצה לשלוח הודעת יוניקס לפי סי ארבע, כלומר הודעת יוניקס, להזכירכם, זו הודעה ספציפית, שגם ה-IP Destination וגם ה-MAC Destination זה של תחנה ספציפית.
אוקיי, אז פי סי אחד שולח את הפריי, שמבחינת סוויץ' 2 הוא יכול להגיע, כלומר מבחינת טבלת המאק שלו, הוא יכול להגיע לאותה כתובת מאק גם בדרך הזו, כלומר דרך פורט פאסט אתרנט 0.1 וגם דרך פורט פאסט אתרנט 0.2. ומה קורה כאן?
אנחנו רואים שהפריים עצמו מגיע, יש בעצם שכפול של הפריים והוא מגיע פעמיים ל-PC4. וזה יכול ליצור לנו הרבה בעיות בכל מיני תוכנות שבהן יש לנו כפילות בפרימים עצמם.
אוקיי, לולאות, דוגמא נוספת ללולאות יכולה להיווצר בארנות התקשורת שלנו, שבהן בלי לשים לב השתמשו בכבילה לחבר מספר סוויצ'ים ויצרו לנו לולאות שיכולות לגרום לתופעות השונות שדיברנו עליהן.
אוקיי, פה הם מפרטים ממש יורדים לרמת ה... מבנה של המשרד, כל מיני עולהות שיכולות להיגרם לנו. עכשיו, stp או ה-spanning tree protocol ensures that there is only one logical path. כלומר, stp או הסוויצ'ים שמדברים יחדיו, בוחרים או מקבלים איזושהי החלטה איזה נתיב
לחסום ואז בעצם למעשה יהיה לנו נתיב לוגי אחד שרק דרכו תהיה לנו זרימת מידע. עכשיו, כל מידע או המידע שנחסם מתייחס בעצם לתעבורה רגילה, לפעמים רגילים, אבל מבחינת ההודעות שנקראות BPDU, ההודעות הללו שמי שמייצר אותן זה הסוויצ'ים, אז הן כמובן יכולות לעבור כרגיל בסוויצ'ים.
הודעות ה-BPDU כוללות כל מיני פרטים שבהם הסוויצ'ים מייעדים אחד את השני, שזה אומר אילו פורטים כרגע למעלה, למטה. ההודעות הללו קשורות לתהליך קבלת ההחלטות של הסוויצ'ים, ולכן, למרות שפורט מסוים, הוא יכול להיות חסום כרגע, במצב בלוקינג הכוונה,
שהוא לא יכול לקבל ולהעביר פריימים, אבל הוא כן יוכל לקבל הודעות bpdus ולהתעדכן ככה מה קורה בטופולוגיה. עכשיו, למה זה כל כך חשוב? כי למקרה שבו יש לי טופולוגיה שבה נתיב מסוים עכשיו הוא מנותק מאיזושהי סיבה, אז הסוויצ'ים עדיין צריכים לספר אחד לשני על זה שיש לנו נתיב שהוא למטה, ובעצם להשמיש את הנתיב שנחסם לפניכם.
עכשיו, ישנם כמה מושגים שנעבור עליהם עכשיו, אנחנו נראה אותם בהמשך, איך הם קשורים לתהליך קבלת ההחלטות. הראשון זה ה-spanning tree algorithm, זה בעצם, אנחנו נראה איזה אלגוריתם שמחליט או שבאמצעותו סוויצ'ים מחליטים אילו פורטים לחסום.
המושג הראשון בהקשר של קבלת החלטות זה הנושא של root bridge. ברידג' מבחינתנו זה הסוויץ' המרכזי שדרכו עוברת כל התעבורה.
בהתחלה כשאנחנו מחברים או משרשרים סוויצ'ים אחד לשני, הסוויצ'ים מספרים אחד לשני כל מיני פרטים על עצמם. כשהפרטים מספרים אחד לשני, בעצם הפרטים האלה נקראים ברידג' איי-די.
אנחנו נראה בדיוק מה זה אומר, אבל ברגע שסוויצ'ים מדברים אחד עם השני, באמצעות ה-BPDU כל אחד מספר על עצמו מה הברידג' איי-די שלו, ועל פי הנתונים הללו הם מקבלים החלטה מי יהיה הסוויץ' הראשי שדרכו תעבור כל התעבורה וזהו ה-Root Bridge.
אנחנו נראה את זה בדיוק על טופולוגיה ונראה איך הסוויצ'ים מקבלים את ההחלטה הזאת. עכשיו, חשוב לזכור שהסוויץ' עם ה-Bridge ID הנמוך ביותר הופך להיות ה-Root Bridge, אוקיי? זה מה שזה אומר ואנחנו נראה עוד מעט מה זה אומר ה-Bridge ID.
אז ככה, אם אמרנו שה-Bridge ID הוא החלק החשוב ב-Spanity, כלומר באמצעותו מחליטים מי ה-Root Bridge, עכשיו מה הוא כולל?
הוא כולל שני ערכים, הוא כולל, למעשה הוא כולל שלושה ערכים, הוא כולל בהתחלה, אנחנו נדבר על נושא של Priority, שזה ערך שכמובן אנחנו נוכל לשלוט עליו, ו-MAC Address, לכל ציוד יש MAC Address, ה-MAC Address הזה לא מתייחס לפורט מסוים, ל-MAC address שצרוב על החומרה עצמה או משוייך לחומרה עצמה,
וזה ערך שהסוויצ'ים מספרים אחד לשני. אז השילוב של Priority, Mac address, ואנחנו נדבר על ערך נוסף, או קוראים לזה כאן Optional Extended System ID, אנחנו נדבר על זה בהמשך.
אז שלושת הערכים הללו קובעים לי את ה-Bridge ID. עכשיו, אחרי שהסוויצ'ים מדברים ביניהם, מחליטים מי הרות ברידג', עכשיו הם צריכים לקבל החלטה כל סוויץ', מה הנתיב העדיף להגיע ממנו לרות ברידג', ובתהליך קבלת החלטות הזה בסופו של דבר אחד או יותר מאחד מהנתיבים נחסם בשביל למנוע את לולאות הניתוב.
עכשיו כשאנחנו מדברים על כל סוויץ' שאמור להחליט איזה נתיב מבחינתו הוא הנתיב הטוב ביותר, אז אם לדוגמה אנחנו לוקחים את הטופולוגיה הבאה,