Cisco Training 200-125 CCNA v3.0. יום 44: היכרות עם OSPF

היום נתחיל ללמוד על ניתוב OSPF. נושא זה, כמו פרוטוקול EIGRP, הוא הנושא החשוב ביותר בקורס ה-CCNA כולו. כפי שאתה יכול לראות, סעיף 2.4 הוא הכותרת "הגדרה, בדיקה ופתרון בעיות של OSPFv2 Single-Zone ו- Multi-Zone עבור IPv4 (לא כולל אימות, סינון, סיכום מסלול ידני, הפצה מחדש, Stub Area, VNet ו-LSA)."

הנושא של OSPF הוא די נרחב, אז זה ייקח 2, אולי 3 שיעורי וידאו. השיעור של היום יוקדש לצד התיאורטי של הנושא, אני אגיד לך מהו הפרוטוקול הזה באופן כללי ואיך הוא עובד. בסרטון הבא, נעבור למצב תצורת OSPF באמצעות Packet Tracer.

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

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

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

OSPF גרסה 2 תמכה רק ב-IPv4, ושנה לאחר מכן, ב-1989, הכריזו המפתחים על גרסה 3, שתמכה ב-IPv6. עם זאת, גרסה שלישית פונקציונלית מלאה של OSPF עבור IPv6 הופיעה רק ב-2008. למה בחרת ב-OSPF? בשיעור האחרון, למדנו שפרוטוקול שער פנימי זה מבצע התכנסות מסלולים הרבה יותר מהר מאשר RIP. זהו פרוטוקול ללא כיתות.

אם אתה זוכר, RIP הוא פרוטוקול classful, כלומר הוא לא שולח מידע מסכת רשת משנה, ואם הוא נתקל בכתובת IP class A/24, הוא לא יקבל אותו. לדוגמה, אם תציג לה כתובת IP כמו 10.1.1.0/24, היא תתפוס אותה כרשת 10.0.0.0 מכיוון שהיא לא מבינה מתי רשת תת-רשת באמצעות יותר ממסכת רשת משנה אחת.
OSPF הוא פרוטוקול מאובטח. לדוגמה, אם שני נתבים מחליפים מידע OSPF, אתה יכול להגדיר אימות כך שתוכל לשתף מידע רק עם נתב שכן לאחר הזנת סיסמה. כפי שכבר אמרנו, זהו תקן פתוח, ולכן OSPF משמש על ידי יצרני ציוד רשת רבים.

במובן הגלובלי, OSPF הוא מנגנון להחלפת פרסומות של Link State, או LSAs. הודעות LSA נוצרות על ידי הנתב ומכילות מידע רב: מזהה הנתב הייחודי של הנתב, נתונים על רשתות המוכרות לנתב, נתונים על העלות שלהן וכן הלאה. הנתב צריך את כל המידע הזה כדי לקבל החלטות ניתוב.

נתב R3 שולח את מידע ה-LSA שלו לנתב R5, והנתב R5 חולק את מידע ה-LSA שלו עם R3. LSAs אלה מייצגים את מבנה הנתונים שיוצר את Link State Data Base, או LSDB. הנתב אוסף את כל ה-LSAs שהתקבלו ומציב אותם ב-LSDB שלו. לאחר ששני הנתבים יצרו את מסדי הנתונים שלהם, הם מחליפים הודעות Hello, המשמשות לגילוי שכנים, ומתחילים בהליך של השוואת ה-LSDB שלהם.

נתב R3 שולח לנתב R5 הודעת DBD, או "תיאור מסד נתונים", ו-R5 שולח את ה-DBD שלו לנתב R3. הודעות אלו מכילות אינדקסים של LSA הזמינים בבסיסי הנתונים של כל נתב. לאחר קבלת ה-DBD, R3 שולח בקשת סטטוס רשת LSR ל-R5 ואומר "כבר יש לי הודעות 3,4 ו-9, אז שלח לי רק 5 ו-7."

R5 עושה את אותו הדבר, אומר לנתב השלישי: "יש לי מידע 3,4 ו-9, אז שלח לי 1 ו-2." לאחר קבלת בקשות LSR, הנתבים שולחים חזרה מנות עדכון מצב רשת LSU, כלומר, בתגובה ל-LSR שלו, הנתב השלישי מקבל LSU מהנתב R5. לאחר שהנתבים מעדכנים את מסדי הנתונים שלהם, לכולם, גם אם יש לך 100 נתבים, יהיו אותם LSDBs. לאחר יצירת מסדי הנתונים של LSDB בנתבים, כל אחד מהם יידע על כל הרשת כולה. פרוטוקול OSPF משתמש באלגוריתם Shortest Path First כדי ליצור את טבלת הניתוב, כך שהתנאי החשוב ביותר לפעולתו הנכונה הוא שה-LSDBs של כל ההתקנים ברשת יהיו מסונכרנים.

בתרשים למעלה יש 9 נתבים שכל אחד מהם מחליף הודעות LSR, LSU וכו' עם שכניו. כולם מחוברים זה לזה באמצעות p2p, או ממשקי "נקודה לנקודה" התומכים בפעולה באמצעות פרוטוקול OSPF, ומקיימים אינטראקציה זה עם זה ליצירת אותו LSDB.

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

לכן, כדי ש-OSPF יתפקד בעצמו, עליו לספק תחילה 3 תנאים: למצוא שכנים, ליצור ולעדכן את ה-LSDB, וליצור טבלת ניתוב. כדי למלא את התנאי הראשון, ייתכן שמנהל הרשת יצטרך להגדיר באופן ידני את מזהה הנתב, התזמונים או מסכת התווים הכלליים. בסרטון הבא נסתכל על הגדרת מכשיר לעבודה עם OSPF, לעת עתה אתה צריך לדעת שהפרוטוקול הזה משתמש במסכה הפוכה, ואם הוא לא תואם, אם רשתות המשנה שלך לא תואמות, או האימות לא תואם , שכונה של נתבים לא תוכל להיווצר. לכן, בעת פתרון בעיות OSPF, עליך לברר מדוע השכונה הזו לא נוצרת, כלומר לבדוק שהפרמטרים הנ"ל תואמים.

כמנהל רשת, אינך מעורב בתהליך יצירת LSDB. מסדי נתונים מתעדכנים אוטומטית לאחר יצירת שכונה של נתבים, וכך גם בניית טבלאות ניתוב. כל זה מבוצע על ידי המכשיר עצמו, המוגדר לעבוד עם פרוטוקול OSPF.
בואו נסתכל על דוגמה. יש לנו 2 נתבים, להם הקציתי RIDs 1.1.1.1 ו- 2.2.2.2 למען הפשטות. ברגע שנחבר אותם, ערוץ הקישור יעבור מיד למצב למעלה, מכיוון שהגדרתי לראשונה את הנתבים האלה לעבוד עם OSPF. ברגע שנוצר ערוץ תקשורת, נתב A ישלח מיד חבילת Hello לנתב A. חבילה זו תכיל מידע שהנתב הזה עדיין לא "ראה" אף אחד בערוץ הזה, מכיוון שהוא שולח Hello בפעם הראשונה, כמו גם מזהה משלו, נתונים על הרשת המחוברת אליו ומידע אחר שהוא יכול לחלוק עם שכן.

לאחר קבלת חבילה זו, נתב B יגיד: "אני רואה שיש מועמד פוטנציאלי לשכן OSPF בערוץ התקשורת הזה" ויעבור למצב Init. חבילת Hello אינה הודעת unicast או שידור, היא חבילת ריבוי שידור הנשלחת לכתובת ה-IP של OSPF מרובת שידור 224.0.0.5. יש אנשים ששואלים מהי מסכת רשת המשנה עבור שידור רב. העובדה היא שלרב-שידור אין מסכת רשת משנה; הוא מתפשט כאות רדיו, הנשמע על ידי כל המכשירים המכוונים לתדר שלו. לדוגמה, אם אתה רוצה לשמוע רדיו FM המשדר בתדר 91,0, אתה מכוון את הרדיו שלך לתדר זה.

באותו אופן, נתב B מוגדר לקבל הודעות עבור כתובת ה-multicast 224.0.0.5. בזמן האזנה לערוץ זה, הוא מקבל את חבילת Hello שנשלחה על ידי נתב A ומגיב בהודעה משלו.

במקרה זה, ניתן להקים שכונה רק אם תשובה ב' עומדת במערך קריטריונים. הקריטריון הראשון הוא שתדירות שליחת הודעות Hello ומרווח ההמתנה לתגובה להודעה זו Dead Interval חייבת להיות זהה עבור שני הנתבים. בדרך כלל מרווח המתים שווה למספר ערכי טיימר Hello. לפיכך, אם ה-Hello Timer של נתב A הוא 10 שניות, והנתב B שולח לו הודעה לאחר 30 שניות, בעוד שה-Dead Interval הוא 20 שניות, הסמיכות לא תתקיים.

הקריטריון השני הוא ששני הנתבים חייבים להשתמש באותו סוג של אימות. בהתאם לכך, גם סיסמאות אימות חייבות להתאים.

הקריטריון השלישי הוא התאמה של מזהי אזור Arial ID, הרביעי הוא התאמה של אורך קידומת הרשת. אם נתב A מדווח על קידומת /24, אז לנתב B חייב להיות גם קידומת רשת /24. בסרטון הבא נסתכל על זה ביתר פירוט, לעת עתה אציין שלא מדובר במסכת רשת משנה, כאן הנתבים משתמשים במסכת Wildcard הפוכה. וכמובן, הדגלים של אזור Stub חייבים להתאים גם אם הנתבים נמצאים באזור זה.

לאחר בדיקת הקריטריונים הללו, אם הם תואמים, נתב B שולח את חבילת Hello שלו לנתב A. בניגוד להודעה של A, נתב B מדווח שראה את נתב A ומציג את עצמו.

בתגובה להודעה זו, נתב A שוב שולח Hello לנתב B, בו הוא מאשר שראה גם את הנתב B, ערוץ התקשורת ביניהם מורכב ממכשירים 1.1.1.1 ו-2.2.2.2, והוא עצמו מכשיר 1.1.1.1 . זהו שלב חשוב מאוד בהקמת שכונה. במקרה זה נעשה שימוש בחיבור דו-כיווני דו-כיווני, אבל מה קורה אם יש לנו מתג עם רשת מבוזרת של 2 נתבים? בסביבה "משותפת" כזו, אחד הנתבים צריך לשחק את התפקיד של נתב ייעודי DR, והשני צריך לשחק את התפקיד של נתב ייעודי לגיבוי, BDR

כל אחד מהמכשירים הללו יהווה חיבור מלא, או מצב של צמידות מוחלטת, בהמשך נראה מה זה, אולם חיבור מסוג זה יווצר רק עם DR ו-BDR; שני הנתבים התחתונים D ו-B עדיין מתקשרים אחד עם השני באמצעות ערכת חיבור דו-כיוונית "נקודה לנקודה".

כלומר, עם DR ו-BDR, כל הנתבים יוצרים מערכת יחסים שכונתית מלאה, ואחד עם השני - חיבור נקודה לנקודה. זה חשוב מאוד מכיוון שבמהלך חיבור דו-כיווני בין מכשירים סמוכים, כל הפרמטרים של מנות Hello חייבים להתאים. אצלנו הכל תואם ולכן המכשירים יוצרים שכונה ללא בעיות.

ברגע שנוצרת תקשורת דו-כיוונית, נתב A שולח לנתב B חבילת Database Description, או "תיאור מסד נתונים", ונכנס למצב ExStart - תחילת ההחלפה, או המתנה לטעינה. Database Descriptor הוא מידע דומה לתוכן העניינים של ספר - הוא פירוט של כל מה שנמצא במסד הנתונים של הניתוב. בתגובה, נתב B שולח את תיאור מסד הנתונים שלו לנתב A ונכנס למצב תקשורת ערוץ Exchange. אם במצב Exchange הנתב מזהה שחסר מידע כלשהו במסד הנתונים שלו, הוא יעבור למצב טעינת LOADING ויתחיל להחליף הודעות LSR, LSU ו-LSA עם השכן שלו.

אז, נתב A ישלח LSR לשכנו, שיגיב עם חבילת LSU, אליה נתב A יגיב לנתב B עם הודעת LSA. החלפה זו תתרחש כמה פעמים שהמכשירים ירצו להחליף הודעות LSA. מצב LOADING אומר שעדיין לא התרחש עדכון מלא של מסד הנתונים של LSA. לאחר הורדת כל הנתונים, שני המכשירים יכנסו למצב סמיכות מלאה.

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

הבחירה ב-DR וב-BDR היא נושא חשוב. בואו נסתכל כיצד נבחר DR בסביבה כללית. הבה נניח שלתוכנית שלנו יש שלושה נתבים ומתג. התקני OSPF משווים תחילה את העדיפות בהודעות Hello, ולאחר מכן משווים את מזהה הנתב.

המכשיר עם העדיפות הגבוהה ביותר הופך ל-DR אם העדיפויות של שני מכשירים תואמות, אזי המכשיר עם מזהה הנתב הגבוה ביותר נבחר מבין השניים והופך ל-DR

המכשיר עם העדיפות השנייה בגובהה או מזהה הנתב השני בגובהו הופך לנתב הייעודי לגיבוי BDR. אם ה-DR ייכשל, הוא יוחלף מיד ב-BDR. הוא יתחיל לשחק את התפקיד של DR, והמערכת תבחר אחר BDR

אני מקווה שהבנתם את הבחירה ב-DR וב-BDR, אם לא, אחזור לנושא הזה באחד מהסרטונים הבאים ואסביר את התהליך הזה.

עד כה בדקנו מה זה Hello, מתאר מסד הנתונים והודעות LSR, LSU ו-LSA. לפני שנעבור לנושא הבא, בואו נדבר קצת על העלות של OSPF.

ב-Cisco, עלות מסלול מחושבת באמצעות נוסחת היחס בין רוחב הפס Reference, המוגדר כברירת מחדל ל-100 Mbit/s, לעלות הערוץ. לדוגמה, בחיבור מכשירים דרך יציאה טורית, המהירות היא 1.544 Mbps, והעלות תהיה 64. בשימוש בחיבור Ethernet במהירות של 10 Mbps, העלות תהיה 10, ועלות חיבור FastEthernet עם מהירות של 100 Mbps תהיה 1.

כשמשתמשים ב-Gigabit Ethernet יש לנו מהירות של 1000 Mbps, אבל במקרה זה המהירות היא תמיד 1. לכן, אם יש לך Gigabit Ethernet ברשת, עליך לשנות את ערך ברירת המחדל של Ref. BW ב-1000. במקרה זה, העלות תהיה 1, והטבלה כולה תחושב מחדש כאשר ערכי העלות יגדלו פי 10. לאחר שיצרנו את הסמיכות ובנינו את ה-LSDB, אנו עוברים לבניית טבלת הניתוב.

לאחר קבלת ה-LSDB, כל נתב מתחיל ליצור רשימת מסלולים באופן עצמאי באמצעות אלגוריתם SPF. בתכנית שלנו, נתב A יצור לעצמו טבלה כזו. לדוגמה, הוא מחשב את עלות המסלול A-R1 וקובע אותה כ-10. כדי להקל על הבנת הדיאגרמה, נניח שהנתב A קובע את המסלול האופטימלי לנתב B. עלות הקישור A-R1 היא 10 , הקישור A-R2 הוא 100, ועלות המסלול A-R3 שווה ל-11, כלומר סכום המסלול A-R1(10) ו-R1-R3(1).

אם נתב A רוצה להגיע לנתב R4, הוא יכול לעשות זאת גם במסלול A-R1-R4 או לאורך המסלול A-R2-R4, ובשני המקרים עלות המסלולים תהיה זהה: 10+100 =100+10=110. כביש A-R6 יעלה 100+1= 101, וזה כבר יותר טוב. לאחר מכן, נשקול את הנתיב לנתב R5 לאורך המסלול A-R1-R3-R5, שעלותו תהיה 10+1+100 = 111.

את השביל לנתב R7 ניתן להניח לאורך שני מסלולים: A-R1-R4-R7 או A-R2-R6-R7. העלות של הראשון תהיה 210, השני - 201, כלומר כדאי לבחור 201. לכן, כדי להגיע לנתב B, נתב A יכול להשתמש ב-4 מסלולים.

עלות מסלול A-R1-R3-R5-B תהיה 121. כביש A-R1-R4-R7-B יעלה 220. כביש A-R2-R4-R7-B יעלה 210, ו-A-R2- ל-R6-R7- B יש עלות של 211. על סמך זה, נתב A יבחר את המסלול בעל העלות הנמוכה ביותר, שווה ל-121, וימקם אותו בטבלת הניתוב. זהו דיאגרמה פשוטה מאוד של אופן הפעולה של אלגוריתם SPF. למעשה, הטבלה מכילה לא רק את ייעודי הנתבים שדרכם עובר המסלול האופטימלי, אלא גם את ייעודי הפורטים המחברים ביניהם וכל שאר המידע הדרוש.

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

מה קורה אם המכשיר המחובר לנתב R3 נכשל פתאום? נתב R3 יתחיל מיד לשלוח הודעה לנתבים R5 ו-R1 שהערוץ עם המכשיר הזה כבר לא עובד, וכל הנתבים יתחילו להחליף עדכונים לגבי אירוע זה.

אם יש לך 100 נתבים, כולם יעדכנו את פרטי מצב הקישור מכיוון שהם נמצאים באותו אזור משותף. אותו דבר יקרה אם אחד הנתבים השכנים ייכשל - כל המכשירים באזור יחליפו עדכוני LSA. לאחר החלפת הודעות כאלה, טופולוגיית הרשת עצמה תשתנה. ברגע שזה יקרה, SPF יחשב מחדש את טבלאות הניתוב בהתאם לתנאים שהשתנו. זהו תהליך גדול מאוד, ואם יש לך אלף מכשירים באזור אחד, אתה צריך לשלוט בגודל הזיכרון של הנתבים כך שיספיק לאחסן את כל ה-LSAs ואת מסד הנתונים הענק של מצבי ה-LSDB. ברגע שמתרחשים שינויים בחלק כלשהו של האזור, אלגוריתם ה-SPF מחשב מחדש מיד את המסלולים. כברירת מחדל, ה-LSA מתעדכן כל 30 דקות. תהליך זה אינו מתרחש בכל המכשירים בו זמנית, אך בכל מקרה, עדכונים מבוצעים על ידי כל נתב כל 30 דקות. כמה שיותר התקני רשת. ככל שייקח יותר זיכרון וזמן לעדכן את ה-LSDB.

ניתן לפתור בעיה זו על ידי חלוקת אזור משותף אחד למספר אזורים נפרדים, כלומר באמצעות ריבוי אזורים. לשם כך, עליך להיות בעל תוכנית או דיאגרמה של כל הרשת שאתה מנהל. אזור 0 הוא האזור הראשי שלך. זה המקום שבו מתבצע החיבור לרשת החיצונית, למשל גישה לאינטרנט. בעת יצירת אזורים חדשים, עליך לפעול לפי הכלל: לכל אזור חייב להיות ABR אחד, נתב גבול אזור. לנתב קצה יש ממשק אחד באזור אחד וממשק שני באזור אחר. לדוגמא, לנתב R5 יש ממשקים באזור 1 ובאזור 0. כפי שאמרתי, כל אחד מהאזורים חייב להיות מחובר לאזור אפס, כלומר יש לו נתב קצה, שאחד מהממשקים שלו מחובר ל-AREA 0.

בואו נניח שחיבור R6-R7 נכשל. במקרה זה, עדכון ה-LSA יתפשט רק דרך AREA 1 וישפיע רק על אזור זה. מכשירים באזור 2 ובאזור 0 אפילו לא יידעו על זה. נתב Edge R5 מסכם מידע על מה שקורה באזור שלו ושולח מידע מסכם על מצב הרשת לאזור הראשי AREA 0. התקנים באזור אחד אינם צריכים להיות מודעים לכל השינויים ב-LSA בתוך אזורים אחרים מכיוון שנתב ABR יעביר מידע סיכום מסלול מאזור אחד לאחר.

אם אתה לא לגמרי ברור לגבי הרעיון של אזורים, תוכל ללמוד יותר בשיעורים הבאים כשאנחנו נכנסים להגדרת ניתוב OSPF ונסתכל על כמה דוגמאות.

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, 30% הנחה למשתמשי Habr על אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2650 v4 (6 ליבות) 10GB DDR4 240GB SSD 1Gbps החל מ-$20 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com