סקירה כללית על Bidirectional Forwarding Detection (BFD)
בדף הזה מוסבר על זיהוי העברה דו-כיוונית (BFD) ב-Cloud Router.
BFD (RFC 5880, RFC 5881) הוא פרוטוקול לזיהוי הפסקות בנתיב העברה, שנתמך ברוב הנתבים המסחריים. עם BFD ל-Cloud Router, אתם יכולים להפעיל את הפונקציונליות של BFD בתוך סשן BGP כדי לזהות הפסקות בנתיב ההעברה, כמו אירועים של קישוריות לא פעילה. היכולת הזו משפרת את העמידות של רשתות היברידיות.
כשמבצעים פירינג עם Cloud de Confiance by S3NS מהרשת המקומית באמצעות Dedicated Interconnect או Partner Interconnect, אפשר להפעיל BFD כדי לזהות במהירות כשל בקישור ולבצע מעבר לגיבוי פעיל של התנועה לקישור חלופי עם סשן BGP לגיבוי. כך, פרוטוקול BFD מספק נתיב קישוריות לרשת בזמינות גבוהה, שיכול להגיב במהירות לתקלות בקישור.
היתרונות של BFD
אם BFD מוגדר עם הגדרות ברירת המחדל, הוא מזהה כשל תוך 5 שניות, לעומת 60 שניות בזיהוי כשל מבוסס-BGP. אם BFD מיושם ב-Cloud Router, זמן הזיהוי מקצה לקצה יכול להיות קצר עד כדי 5 שניות.
BFD הוא פרוטוקול hello באורך קבוע שבו כל קצה של חיבור מעביר מנות באופן תקופתי בנתיב העברה.
BFD הוא פרוטוקול זיהוי מבוסס UDP שמאפשר לזהות תקלות בנתיב ההעברה בין שני נתבים סמוכים, עם תקורה נמוכה. הפעולות האלה כוללות זיהוי של כשלים בממשקים, בקישורי נתונים ובמישורי העברה. אפשר להפעיל את BFD ברמת פרוטוקול הניתוב.
מגבלות של BFD
אפשר להפעיל BFD רק בסשנים של BGP שמוגדרים לחיבורי VLAN ב-Dedicated Interconnect או ב-Partner Interconnect. אין תמיכה ב-BFD בסשנים של BGP שהוגדרו למנהרות HA VPN או ל-Router appliance, שהוא חלק מ-Network Connectivity Center.
הקמת סשן BFD
כדי ליצור סשן BFD, צריך להגדיר BFD בשני עמיתי BGP: Cloud Router והנתב המקומי שבו פועל BFD. אחרי שמפעילים את BFD עבור פרוטוקול הניתוב BGP בנתב, נוצרת סשן BFD, מתבצע משא ומתן על טיימרים של BFD, ועמיתי BFD מתחילים לשלוח אחד לשני חבילות בקרה של BFD במרווח המוסכם.
הפרוטוקול BFD שולח הודעות מהירות על זיהוי כשל ל-BGP בנתב המקומי כדי להתחיל את תהליך החישוב מחדש של טבלת הניתוב, וכך הוא תורם לקיצור משמעותי של זמן ההתכנסות הכולל של הרשת.
בתרשים הבא מוצגת רשת פשוטה עם שני נתבים שמריצים BGP ו-BFD. המספרים האלה מייצגים את תהליך הקמת הסשן של BFD:
- הגדרתם שכן BGP.
- פרוטוקול BGP שולח בקשה לתהליך BFD המקומי כדי ליזום סשן BFD עם נתב BGP עמית/שכן.
- נוצר סשן שכנות BFD עם נתב שכנות BGP.
BFD במהלך אירוע כשל
באיור הבא מוצג מה קורה כשמתרחשת תקלה ברשת.
ב-BFD במצב שליטה בלבד, Cloud Router והנתב המקומי שולחים זה לזה חבילות בקרה של BFD באופן תקופתי. אם הנתב השני לא מקבל את מספר מנות הבקרה ברצף שהוגדר בהגדרה bfd multiplier ב-Cloud Router, הסשן מוכרז כלא פעיל. אחר כך קורה הדבר הבא:
- הקישור נכשל בין Cloud de Confiance by S3NS לבין הנתב המקומי.
- סשן השכנים של BFD עם נתב השכנים של BGP מבוטל.
- פרוטוקול BFD מודיע לתהליך BGP המקומי שאי אפשר יותר להגיע לשכן BFD.
- תהליך ה-BGP המקומי מנתק את הקשר בין רשתות שכנות ב-BGP.
אם יש נתיב חלופי, הנתבים מתחילים מיד להתכנס אליו.
החלשת BFD
Cloud Router מטמיע שיכוך BFD באופן פנימי כדי למנוע את ההשפעה השלילית של תנודות תכופות של סשן BFD על BGP. ההחלשה של BFD משתמשת בפרמטרים שמוגדרים כברירת מחדל, והמשתמש לא יכול לשנות אותם.
ההחלשה של BFD מתבססת על מערכת ענישה. ערך העונש מתחיל ב-0 ועולה ל-1 בפעם הראשונה שמתרחשת תנודה. אחרי התנודה הראשונה, העונש מוכפל בכל פעם שמתרחשת תנודה נוספת של BFD. כשהקנס חורג מערך הסף של 4, BFD מבטל את ההתראות ל-BGP. העונש מופחת בחצי כל 10 דקות אם לא מתרחשת תנודה במהלך התקופה הזו.
פרוטוקול BFD מאפשר לשלוח שוב התראות ל-BGP אחרי שהעונש יורד מתחת לסף של 4 לשימוש חוזר.
המרווח המקסימלי לביטול של התראות BFD ל-BGP הוא שעה אחת. כך אפשר לוודא שההתראות על הפסקת הפעילות של סשן BFD לא יוסתרו לתמיד.
מצב אסינכרוני של BFD
Cloud Router תומך במצב פעולה אסינכרוני, שבו המערכות שמשתתפות בתהליך שולחות זו לזו חבילות בקרה של BFD באופן תקופתי. אם מספר מוגדר של מנות כאלה ברצף לא מתקבל במערכת השנייה, הסשן מוכרז כלא פעיל.
אין תמיכה במצב הביקוש של פעולת BFD. במצב מנות, BFD תומך במצב בקרה בלבד. אין תמיכה במצב הד.
במצב פעולה אסינכרוני עם מצב מנות לשליטה בלבד, פרוטוקול BFD פועל במישור הבקרה ויכול להוסיף תקורה קלה וזמן עיבוד של המעבד.
כברירת מחדל, פרוטוקול BFD מושבת בפעילויות BGP של Cloud Router. כדי להשתמש ב-BFD, צריך להפעיל אותו.
בתרחיש הכשל הבא, לנתבים יש את ההגדרות הבאות:
- מרווחי הזמן המינימליים של BFD לקבלה ולשידור ב-Cloud Router מוגדרים ל-1,000 אלפיות השנייה (ms).
- המרווחים המינימליים של BFD לקבלה ולשידור של נתב העמית מוגדרים ל-1,000 אלפיות השנייה.
- פרוטוקול BFD RFC 5880 מנהל משא ומתן על מרווח השידור המוסכם, כך שיהיה הגבוה מבין מרווח השידור מהצד של השולח ומרווח הקבלה מהצד של המקבל. לכן, מרווחי השידור המוסכמים בכל צד הם 1,000 אלפיות השנייה בגלל הגדרות זהות.
- חישוב זמן הזיהוי ב-Cloud Router הוא מכפלה של מרווח השידור המוסכם של נתב העמיתים בערך המכפיל של BFD של נתב העמיתים. במקרה כזה, זמן הזיהוי הוא 1,000 ms * 5 = 5,000 ms.
- חישוב זמן הזיהוי בנתב העמית הוא מכפלה של מרווח השידור המוסכם של Cloud Router בערך המכפיל של BFD ב-Cloud Router. בתרחיש הזה, זמן הזיהוי הוא 1,000 ms * 5 = 5,000 ms.
ה-Cloud Router מנהל משא ומתן עם הנתב העמית ומצפה לקבל חבילות בקרה כל 1,000 אלפיות השנייה מהנתב העמית. אם חולפות 5,000 מילישניות בלי ש-Cloud Router יקבל מנת בקרה, טיימר הזיהוי שלו יפוג והוא יכריז על סשן ה-BFD כלא פעיל.
מומלץ לבצע את הפעולות הבאות כשמגדירים BFD:
- כדי למנוע אי התאמה של מכפיל BFD, צריך להגדיר את Cloud Router ואת הנתב המקומי לאותן הגדרות BFD.
- כדי להימנע מבעיות ב-BFD וב-BGP, צריך להגדיר את הזמן הקצוב לתפוגה המינימלי של BFD ל-5,000 אלפיות השנייה לפחות בכל כיוון.
אתחול בלי הפרעה ו-BFD
כדי למזער את ההשפעה על התנועה במהלך אירועי תחזוקה של תוכנת Cloud Router, מומלץ להפעיל הפעלה מחדש חלקה של BGP.
אם גם BGP אתחול בלי הפרעה וגם BFD מופעלים, אז כש-Cloud Router מופעל מחדש הוא מנסה להשבית את BFD על ידי שליחת הודעה AdminDown לנתב המקומי. במקרה כזה, סשן ה-BGP נשאר פעיל בצד המקומי, והנתב המקומי עובר למצב אתחול בלי הפרעה. בזמן שהנתב המקומי נמצא במצב אתחול בלי הפרעה, Cloud Router יכול להפעיל מחדש בלי להשפיע על תנועת הנתונים במישור הנתונים.
באופן דומה, אם הנתב המקומי שולח הודעת AdminDown לפני הפעלה מחדש של מישור הבקרה שלו, Cloud Router נכנס למצב של אתחול בלי הפרעה.
בזמן ש-Cloud Router נמצא במצב אתחול בלי הפרעה, הנתב המקומי יכול להפעיל מחדש בלי להשפיע על התנועה במישור הנתונים.
כש-Cloud Router יוצר BFD עם נתב עמית, הוא מגדיר את הביט של מישור הבקרה העצמאי ל-0 כדי לציין שההטמעה של BFD תלויה במישור הבקרה. אם מתרחש כשל בממשק, יכול להיות שהנתב העמית לא יוכל להבחין בין כשל ב-BFD שנגרם בגלל כשל במישור הבקרה או במישור הנתונים. לדוגמה, תקלה בממשק עלולה לגרום לנתב המקומי להיכנס למצב של הפעלה מחדש מסודרת, ולעכב שלא לצורך את המעבר של התנועה לקישור המושפע.
בגלל האפשרות לפרשנות שונה של כשל ב-BFD, ספקים שונים מתייחסים לתרחיש הספציפי הזה בצורה שונה ומציעים הגדרות תצורה לשינוי התנהגות ברירת המחדל. מומלץ לעיין במסמכי התיעוד של ספק הנתב ולהגדיר את הנתב המקומי כדי לוודא שאירוע של כשל בממשק BFD עם עמית BFD שתלוי במישור הבקרה יפעיל מעבר מיידי לגיבוי כשמשתמשים בו עם הפעלה מחדש חלק של BGP.
הגדרות וטיימרים של BFD
בקטע הזה מתוארות הגדרות BFD שאפשר להגדיר ב-Cloud Router.
מצב אתחול של סשן BFD
| תיאור | מצב ההפעלה של סשן BFD עבור עמית BGP הזה. |
|---|---|
פקודה gcloud |
--bfd-session-initialization-mode |
| שדה API | bgpPeers[].bfd.sessionInitializationMode |
| הגדרת ברירת המחדל | Disabled |
יש שלוש הגדרות למצב BFD: Active, Passive ו-Disabled. אם לא מגדירים את המצב הזה, ברירת המחדל היא Disabled, כלומר נעשה שימוש במצב ללא הד (חבילות בקרה בלבד).
-
Disabled(ברירת מחדל): BFD מושבת עבור עמית ה-BGP הזה. -
Passive: Cloud Router ממתין שנתב ה-peer יפעיל את סשן ה-BFD עבור ה-BGP peer הזה. -
Active: Cloud Router יוזם את סשן ה-BFD עבור עמית ה-BGP הזה.
צריך להגדיר את הנתב לפחות בצד אחד של החיבור – Cloud Router או הנתב של הרשת השכנה – ל-Active. כשמגדירים סשן BGP בין שני נתבי Cloud Router, צריך להגדיר את מצב האתחול של סשן BFD של אחד מהנתבים לערך Active.
אם מגדירים את שני הצדדים ל-Active, שני הצדדים שולחים מנהל בקרה ראשוני כדי לנהל משא ומתן על הפרמטרים, והסשן נוצר בסופו של דבר.
אם מגדירים את מצב האתחול של סשן BFD ל-Disabled, אפשר גם להגדיר את שאר הגדרות ה-BFD. ההגדרות האלה ייכנסו לתוקף כשתפעילו מחדש את BFD.
מרווח השידור המינימלי של BFD (מנות BFD לעמית)
| תיאור | המרווח המינימלי, באלפיות השנייה, בין חבילות בקרה של BFD שמועברות ל-BGP peer. |
|---|---|
פקודה gcloud |
--bfd-min-transmit-interval |
| שדה API | bgpPeers[].bfd.minTransmitInterval |
| הגדרת ברירת המחדל | 1,000 ms. אפשר לציין הגדרה בין 1,000 ms לבין 30,000 ms. פרוטוקול BFD RFC 5880 מגדיר את מרווח השידור המוסכם כערך הגבוה יותר בין מרווח השידור של Cloud Router לבין מרווח הקבלה של ה-peer. לכן, יש תמיכה ב-BFD בסשנים של BGP גם אם המכשיר המקומי תומך רק במרווח קבלה מינימלי שהוא נמוך מ-1,000 אלפיות השנייה. |
מרווח הזמן המינימלי לקבלת נתוני BFD (מנות BFD מעמית)
| תיאור | מרווח הזמן המינימלי, באלפיות השנייה, בין מנות בקרה של BFD שמתקבלות מנקודת קצה של BGP. |
|---|---|
פקודה gcloud |
--bfd-min-receive-interval |
| שדה API | bgpPeers[].bfd.minReceiveInterval |
| הגדרת ברירת המחדל | 1,000 ms. אפשר לציין הגדרה בין 1,000 ms ל-30,000 ms. פרוטוקול BFD RFC 5880 מגדיר את מרווח השידור המוסכם מנתב העמית כערך הגבוה יותר בין מרווח השידור של העמית לבין מרווח הקבלה של Cloud Router. לכן, יש תמיכה ב-BFD בסשנים של BGP גם אם המכשיר המקומי שלכם תומך רק במרווח שידור מינימלי שהוא נמוך מ-1,000 אלפיות השנייה. |
מכפיל BFD
| תיאור | מספר חבילות הבקרה הרצופות של BFD שצריך לפספס לפני ש-BFD מכריז שעמית לא זמין. מקדם ההכפלה הזה משמש לחישוב זמן הזיהוי בצד המקבל באופן הבא:
זמן הזיהוי = מרווח השידור המוסכם * מכפיל BFD |
|---|---|
פקודה gcloud |
--bfd-multiplier |
| שדה API | bgpPeers[].bfd.multiplier |
| הגדרת ברירת המחדל | 5 חבילות. אפשר לציין הגדרה בין 5 חבילות ל-16 חבילות. כדי להשיג זמני זיהוי זהים בשני הכיוונים, צריך להגדיר את אותו ערך מכפיל ב-Cloud Router ובנתב העמית. |
המאמרים הבאים
כדי לעדכן את הגדרות BFD, אפשר לעיין במאמר עדכון או השבתה של BFD.
כדי להגדיר BFD, קראו את המאמר הגדרת BFD.
דוגמאות להגדרות של נתבים של צד שלישי שתומכות ב-BFD עבור Cloud Router זמינות במאמר בנושא שימוש בהגדרות של נתבים של צד שלישי עבור BFD.
לקבלת עזרה בנושא הודעות אבחון של BFD, מצבי סשן והודעות סטטוס, אפשר לעיין במאמר הודעות אבחון של BFD ומצבי סשן.
כדי לפתור בעיות ב-Cloud Router, אפשר לעיין במאמר בנושא פתרון בעיות.