סקירה כללית על Bidirectional Forwarding Detection (BFD)

בדף הזה מוסבר על זיהוי העברה דו-כיוונית (BFD) ב-Cloud Router.

‫BFD‏ (RFC 5880,‏ RFC 5881) הוא פרוטוקול לזיהוי הפסקות בנתיב ההעברה, שנתמך על ידי רוב הנתבים המסחריים. עם BFD ל-Cloud Router, אתם יכולים להפעיל את הפונקציונליות של BFD בתוך סשן BGP כדי לזהות הפסקות בנתיב ההעברה, כמו אירועים של קישוריות לא זמינה. היכולת הזו משפרת את העמידות של רשתות היברידיות.

כשמבצעים פירינג עם Google Cloud מהרשת המקומית באמצעות Dedicated Interconnect או Partner Interconnect, אפשר להפעיל BFD כדי לזהות במהירות כשל בקישור ולבצע מעבר של התנועה לקישור חלופי עם סשן BGP לגיבוי. כך, BFD מספק נתיב קישוריות לרשת עם זמינות גבוהה שיכול להגיב במהירות לתקלות בקישור.

היתרונות של BFD

אם BFD מוגדר עם הגדרות ברירת המחדל, הוא מזהה כשל תוך 5 שניות, לעומת 60 שניות לזיהוי כשל שמבוסס על BGP. אם BFD מיושם ב-Cloud Router, זמן הזיהוי מקצה לקצה יכול להיות קצר עד 5 שניות.

BFD הוא פרוטוקול קבוע באורך שבו כל קצה של חיבור מעביר מנות באופן תקופתי בנתיב העברה.

BFD הוא פרוטוקול זיהוי מבוסס-UDP שמספק שיטה עם תקורה נמוכה לזיהוי כשלים בנתיב ההעברה בין שני נתבים סמוכים. הפעולות האלה כוללות זיהוי של כשלים בממשקים, בקישורי נתונים ובמישורי העברה. אפשר להפעיל את BFD ברמת פרוטוקול הניתוב.

מגבלות של BFD

אפשר להפעיל BFD רק בסשנים של BGP שמוגדרים לחיבורי VLAN ב-Dedicated Interconnect או ב-Partner Interconnect. אין תמיכה ב-BFD בסשנים של BGP שהוגדרו למנהרות HA VPN או לנתב וירטואלי, שהוא חלק מ-Network Connectivity Center.

הקמת סשן BFD

כדי ליצור סשן BFD, צריך להגדיר BFD בשני עמיתי BGP:‏ Cloud Router והנתב המקומי שבו פועל BFD. אחרי שמפעילים את BFD עבור פרוטוקול הניתוב BGP בנתב, נוצרת סשן BFD, מתבצע משא ומתן על טיימרים של BFD, ועמיתי BFD מתחילים לשלוח אחד לשני חבילות בקרה של BFD במרווח המוסכם.

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

בתרשים הבא מוצגת רשת פשוטה עם שני נתבים שמריצים BGP ו-BFD. המספרים האלה מייצגים את תהליך הקמת הסשן של BFD:

  1. הגדרתם שכן BGP.
  2. פרוטוקול BGP שולח בקשה לתהליך BFD המקומי כדי ליזום סשן BFD עם נתב BGP עמית/שכן.
  3. נוצר סשן שכנים של BFD עם נתב השכנים של BGP.
הקמת סשן BFD.
הקמת סשן BFD (לחצו כדי להגדיל)

BFD במהלך אירוע כשל

באיור הבא מוצג מה קורה כשיש כשל ברשת.

במצב שליטה בלבד של BFD, ה-Cloud Router והנתב המקומי שולחים זה לזה חבילות בקרה של BFD באופן תקופתי. אם הנתב השני לא מקבל את מספר מנות הבקרה ברצף שהוגדר בהגדרה bfd multiplier ב-Cloud Router, הסשן מוכרז כלא פעיל. אחר כך קורה הדבר הבא:

  1. הקישור נכשל בין Google Cloud לבין הנתב המקומי.
  2. סשן השכנים של BFD עם נתב השכנים של BGP מבוטל.
  3. פרוטוקול BFD מודיע לתהליך BGP המקומי שאי אפשר יותר להגיע לשכן BFD.
  4. תהליך ה-BGP המקומי מנתק את הקשר בין רשתות שכנות ב-BGP.

אם יש נתיב חלופי, הנתבים מתחילים מיד להתכנס אליו.

‫BFD במהלך אירוע כשל.
BFD במהלך אירוע כשל (לחצו כדי להגדיל)

החלשת תנודות ב-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 אלפיות השנייה * 5 = 5,000 אלפיות השנייה.
  • חישוב זמן הזיהוי בנתב העמית הוא מכפלה של מרווח השידור המוסכם של Cloud Router בערך המכפיל של BFD ב-Cloud Router. בתרחיש הזה, זמן הזיהוי הוא 1,000 ms * 5 = 5,000 ms.

‫Cloud Router מנהל משא ומתן עם נתב העמיתים ומצפה לקבל מנתב העמיתים חבילות בקרה כל 1,000 אלפיות השנייה. אם חולפות 5,000 מילישניות בלי ש-Cloud Router יקבל מנת בקרה, טיימר הזיהוי שלו יפוג והוא יכריז שהסשן של BFD לא פעיל.

BFD ללא מנות הד.
BFD בלי חבילות הד (לחצו כדי להגדיל)

מומלץ לבצע את הפעולות הבאות כשמגדירים BFD:

  • כדי למנוע חוסר התאמה במכפיל BFD, צריך להגדיר את נתב הענן ואת הנתב המקומי עם אותן הגדרות BFD.
  • כדי להימנע מבעיות ב-BFD וב-BGP, צריך להגדיר את הזמן המינימלי להמתנה עד שפג התוקף של BFD ל-5,000 מילישניות לפחות בכל כיוון.

אתחול בלי הפרעה ו-BFD

כדי למזער את ההשפעה על התנועה במהלך אירועי תחזוקה של תוכנת Cloud Router, מומלץ להפעיל הפעלה מחדש חלקה של BGP.

אם גם BGP graceful restart וגם 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 ממתין שהנתב העמית יפעיל את סשן BFD עבור עמית BGP הזה.
  • ‫Active: נתב Cloud Router יוזם את סשן ה-BFD עבור עמית ה-BGP הזה.

צריך להגדיר את הנתב לפחות בצד אחד של החיבור – Cloud Router או הנתב של הרשת השכנה – ל-Active. כשמגדירים סשן BGP בין שני נתבי Cloud, צריך להגדיר את מצב האתחול של סשן BFD של אחד מהנתבים לערך Active.

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

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

מרווח השידור המינימלי של BFD (מנות BFD לעמית)

תיאור המרווח המינימלי, באלפיות השנייה, בין חבילות בקרה של BFD שמועברות ל-BGP peer.
פקודת gcloud --bfd-min-transmit-interval
שדה API bgpPeers[].bfd.minTransmitInterval
הגדרת ברירת המחדל

‫1,000 אלפיות השנייה. אפשר לציין הגדרה בין 1,000 אלפיות השנייה לבין ‫30,000 אלפיות השנייה.

פרוטוקול 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 אלפיות השנייה. אפשר לציין הגדרה בין 1,000 אלפיות השנייה ל-30,000 אלפיות השנייה.

פרוטוקול BFD RFC 5880 מגדיר את מרווח השידור המוסכם מנתב ה-peer כערך הגבוה יותר בין מרווח השידור של ה-peer לבין מרווח הקבלה של Cloud Router. לכן, יש תמיכה ב-BFD בסשנים של BGP גם אם המכשיר המקומי שלכם תומך רק במרווח שידור מינימלי שהוא נמוך מ-1,000 ms.

מכפיל BFD

תיאור מספר מנות הבקרה הרצופות של BFD שצריך לפספס לפני ש-BFD מכריז שעמית לא זמין. מקדם ההכפלה הזה משמש לחישוב זמן הזיהוי בצד המקבל באופן הבא:

זמן הזיהוי = מרווח השידור המוסכם * מכפיל BFD
פקודת gcloud --bfd-multiplier
שדה API bgpPeers[].bfd.multiplier
הגדרת ברירת המחדל

‫5 חבילות. אפשר לציין הגדרה בין 5 חבילות ל-16 חבילות.

כדי להשיג זמני זיהוי זהים בשני הכיוונים, צריך להגדיר את אותו ערך מכפיל גם ב-Cloud Router וגם בנתב העמית.

המאמרים הבאים