פתרון בעיות

מדריך פתרון הבעיות הזה יכול לעזור לכם לפתור בעיות נפוצות שאולי תיתקלו בהן במהלך השימוש ב-Cloud Interconnect:

תשובות לשאלות נפוצות על הארכיטקטורה והתכונות של Cloud Interconnect מופיעות כאן.

הגדרות של המונחים שמופיעים בדף הזה מפורטות במאמר מונחים מרכזיים ב-Cloud Interconnect.

כדי למצוא מידע על רישום ביומן ומעקב ולראות מדדים של Cloud Interconnect, אפשר לעיין במאמר מעקב אחר חיבורים.

פתרון בעיות כלליות

בדיקה של שיבושים בשירות Cloud Interconnect

  • אפשר לבדוק אם יש שיבושים ידועים בCloud de Confiance Status Dashboard. תוכלו גם להירשם לקבלת התראות שוטפות על אירועים ב-Cloud באמצעות פיד JSON או פיד RSS.

  • תקבלו הודעה על אירועי תחזוקה שמשפיעים על חיבורי Dedicated Interconnect. פרטים נוספים זמינים במאמר בנושא אירועי תחזוקה של התשתית.

  • אתם מקבלים התראה על אירועי תחזוקה שמשפיעים על קובצי ה-VLAN המצורפים של Partner Interconnect. ההתראות על Partner Interconnect נשלחות באופן דומה להתראות על חיבורי Dedicated Interconnect, עם כמה הבדלים קלים. פרטים נוספים זמינים במאמר בנושא אירועים של תחזוקת התשתית.

לא ניתן להתחבר למשאבים באזורים אחרים

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

מידע נוסף זמין במאמר מצב ניתוב דינמי במאמרי העזרה של Cloud Router.

אי אפשר לגשת למכונות וירטואליות ברשת VPC שמקושרת לרשתות שכנות

בתרחיש הזה, הגדרתם חיבור Cloud Interconnect בין הרשת המקומית לבין רשת VPC, ‏ network A. הגדרתם גם קישור בין רשתות VPC שכנות (peering) בין רשת א' לבין רשת VPC אחרת, רשת ב'. עם זאת, אתם לא יכולים להגיע למכונות וירטואליות ברשת ב' מהרשת המקומית שלכם.

ההגדרה הזו לא נתמכת, כפי שמתואר בהגבלות של סקירת הקישור בין רשתות VPC שכנות (peering).

עם זאת, אתם יכולים להשתמש בפרסומים של טווח כתובות IP בהתאמה אישית מ-Cloud Routers ברשת ה-VPC שלכם כדי לשתף מסלולים ליעדים ברשת העמיתים. בנוסף, צריך להגדיר את החיבורים שלכם ב-VPC Network Peering כדי לייבא ולייצא נתיבים מותאמים אישית.

מידע נוסף על פרסום מסלולים בין רשתות מקומיות לרשתות VPC מקושרות זמין במקורות המידע הבאים:

חסרות רשתות משנה בחיבור

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

  1. מציינים מסלולים מותאמים אישית שמוכרזים גם ב-Cloud Router וגם בסשן של Border Gateway Protocol ‏ (BGP).

    כדי להזין את המסלולים החסרים, מגדירים את הפרמטרים הבאים:

    --set-advertisement-groups = ADVERTISED_GROUPS
--set-advertisement-ranges = ADVERTISED_IP_RANGES

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫ADVERTISED_GROUPS: קבוצה שמוגדרת על ידי Google ומוכרזת באופן דינמי על ידי Cloud Router. יכול להיות לה ערך של all_subnets, שמדמה את התנהגות ברירת המחדל של Cloud Router
    • ‫ADVERTISED_IP_RANGES: התוכן של המערך החדש של טווחי כתובות IP. יכול להיות בו ערך אחד או יותר לפי בחירתכם

    פרטים נוספים ודוגמאות זמינים במאמר בנושא פרסום טווחי כתובות IP בהתאמה אישית.

  2. מפעילים את מצב הניתוב הדינמי הגלובלי.

אי אפשר לבצע פינג ל-Cloud Router

אם לא הצלחתם לבצע פינג ל-Cloud Router מהנתב המקומי, חפשו את המוצר בטבלה הבאה ובצעו את השלבים לפתרון הבעיה שרלוונטיים למוצר הזה. המכונות הווירטואליות לא יכולות להגיע אל 169.254.0.0/16.

שלבים לפתרון בעיות Dedicated Interconnect Partner Interconnect עם שותף L3 Partner Interconnect עם שותף L2
ב-Partner Interconnect, יכול להיות שאי אפשר יהיה לבצע פינג ל-Cloud Router כי חלק מהשותפים מסננים תנועה לטווח כתובות ה-IP ‏ (169.254.0.0/16) של Cloud Router. במקרה של שותפים ברמה 3 (L3), השותף מגדיר את BGP באופן אוטומטי. אם פרוטוקול BGP לא מופעל, צריך לפנות לשותף. לא רלוונטי כן לא רלוונטי
מוודאים שהמכשיר המקומי למד את כתובת ה-MAC הנכונה של צד Cloud de Confiance by S3NS של החיבור. מידע נוסף מופיע במאמר פתרון בעיות ב-ARP. כן לא רלוונטי לא רלוונטי
מוודאים שלנתב Cloud יש ממשק ועמית BGP. אי אפשר לבצע פינג ל-Cloud Router אלא אם הממשק וה-BGP peer מוגדרים באופן מלא, כולל ה-ASN המרוחק.
  • במקרה של Dedicated Interconnect, אפשר לעיין במאמר BGP session not working.
  • ב-L2 Partner Interconnect, ‏ Google הוסיפה את הממשק ואת עמית ה-BGP ל-Cloud Router באופן אוטומטי, אבל אתם צריכים להגדיר את ה-ASN המרוחק.
 כן לא רלוונטי כן

פתרון בעיות ב-ARP

ב-Dedicated Interconnect, כדי למצוא את כתובת ה-MAC הנכונה, מריצים את הפקודה הבאה של gcloud:

  gcloud compute interconnects get-diagnostics INTERCONNECT_NAME

השדה googleSystemID מכיל את כתובת ה-MAC שצריכה להופיע בטבלת ה-ARP של המכשיר עבור כתובות IP שהוקצו ל-Cloud Router.

  result:
    links:
    — circuitId: SAMPLE-0
      googleDemarc: sample-local-demarc-0
      lacpStatus:
        googleSystemId: ''
        neighborSystemId: ''
        state: DETACHED
      receivingOpticalPower:
        value: 0.0
      transmittingOpticalPower:
        value: 0.0
    macAddress: 00:00:00:00:00:00

אם המכשיר לא למד כתובת MAC, צריך לוודא שמזהה ה-VLAN וכתובת ה-IP הנכונים מוגדרים בממשק המשנה.

ב-Partner Interconnect, אם מופיעה במכשיר כתובת MAC שגויה, צריך לוודא שלא יצרתם גשר בין פלחי שכבה 2 של שני קבצים מצורפים של VLAN. הצד Cloud de Confiance של חיבור Cloud Interconnect מוגדר עם ip proxy-arp, שמשיב לכל בקשות ה-ARP ויכול לגרום לנתב המקומי ללמוד רשומות ARP שגויות.

אי אפשר ליצור צירוף ל-VLAN

אם תנסו ליצור צירוף ל-VLAN ל-Dedicated Interconnect או ל-Partner Interconnect שמפר מדיניות ארגונית, תופיע הודעת שגיאה. הנה דוגמה להודעת שגיאה שמוצגת אחרי הפעלת הפקודה gcloud compute interconnects attachments partner create:

ERROR: (gcloud.compute.interconnects.attachments.partner.create) Could not fetch resource:
- Constraint constraints/compute.restrictPartnerInterconnectUsage violated for projects/example-project. projects/example-project/global/networks/example-network is not allowed to use the Partner Interconnect.

מידע נוסף זמין במאמרים הגבלת השימוש ב-Cloud Interconnect ושימוש במדיניות ארגונית בהתאמה אישית. אפשר גם לפנות לאדמין של הארגון.

שיתוף חיבורים עם פרויקטים אחרים בארגון שלי

משתמשים ב-VPC משותף כדי לשתף חיבור, כמו צירוף ל-VLAN או חיבור Dedicated Interconnect בפרויקט מארח.

מידע נוסף על הגדרת רשת VPC משותפת זמין במאמר הקצאת VPC משותף.

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

Dedicated Interconnect

‫Google לא יכולה לשלוח פינג אליכם במהלך תהליך הקצאת החיבור

מוודאים שאתם משתמשים בהגדרות הנכונות של כתובת ה-IP ו-LACP. במהלך תהליך הבדיקה, Google שולחת לכם הגדרות שונות של כתובות IP לבדיקה עבור הנתב המקומי, בהתאם להזמנה של חבילת ערוצים מרובים או חבילת ערוץ יחיד. אל תגדירו צירופים ל-VLAN באף אחת מהבדיקות האלה.

  • קבוצת כתובות ה-IP הראשונה ש-Google שולחת מיועדת לבדיקת הקישוריות של כמה מעגלים בכל קישור בנפרד. מגדירים את כתובות ה-IP של הבדיקה בכל קישור פיזי (ללא הגדרת LACP), כמו שמפורט בהוראות באימיילים ש-Google שלחה לכם. ‫Google צריכה לשלוח פינג לכל כתובות ה-IP בהצלחה לפני שהבדיקה הראשונה הזו תעבור.
  • בבדיקה השנייה, מסירים את כל כתובות ה-IP מהבדיקה הראשונה. מגדירים את ערוץ היציאה עם LACP גם אם החיבור כולל רק קישור אחד. ‫Google שולחת פינג לכתובת של ערוץ היציאה. אל תשנו את הגדרת LACP של ערוץ היציאה אחרי שהחיבור עבר את הבדיקה הסופית. עם זאת, צריך להסיר את כתובת ה-IP של הבדיקה מממשק הערוץ של היציאה.
  • ‫Google שולחת את כתובת ה-IP הסופית של הסביבה הפרודקטיבית לצורך בדיקת קישוריות של מעגל יחיד. מגדירים את כתובת ה-IP בממשק החבילה (עם LACP מוגדר, במצב פעיל או פסיבי), לפי ההוראות באימייל שקיבלתם מ-Google. כדי שהבדיקה הזו תעבור, Google צריכה לבצע פינג לכתובת ה-IP של ממשק החבילה בהצלחה. מגדירים את ערוץ היציאה באמצעות LACP גם אם לחיבור יש רק קישור אחד.

אי אפשר לבצע פינג ל-Cloud Router

  • בודקים שאפשר לשלוח פינג לכתובת ה-IP של ערוץ היציאות של Google. כתובת ה-IP היא הערך googleIpAddress כשמציגים את פרטי החיבור.
  • בודקים שיש לכם את ה-VLAN הנכון בממשק המשנה של הנתב המקומי. פרטי ה-VLAN צריכים להיות זהים לפרטים שסופקו על ידי הצירוף ל-VLAN.
  • בודקים שיש לכם את כתובת ה-IP הנכונה בממשק המשנה של הנתב המקומי. כשיוצרים צירוף ל-VLAN, מוקצות לו זוג כתובות IP מקומיות לקישור. אחד מהם הוא לממשק ב-Cloud Router‏ (cloudRouterIpAddress), והשני הוא לתת-ממשק בערוץ היציאה של הנתב המקומי, ולא לערוץ היציאה עצמו (customerRouterIpAddress).
  • אם אתם בודקים את הביצועים של חיבורי ה-VLAN, אל תבצעו פינג ל-Cloud Router. במקום זאת, צריך ליצור מכונה וירטואלית (VM) של Compute Engine ברשת ה-VPC ואז להשתמש בה. מידע נוסף זמין במאמר בנושא בדיקת ביצועים.

סשן BGP לא פועל

  • מפעילים BGP עם כמה קפיצות בנתב המקומי עם לפחות שתי קפיצות.
  • בודקים שכתובת ה-IP של השכן מוגדרת בצורה נכונה בנתב המקומי. משתמשים בכתובת ה-IP של עמית BGP ‏ (cloudRouterIpAddress) שהוקצתה לצירוף ל-VLAN.
  • בודקים שההגדרה של ה-ASN המקומי בנתב המקומי תואמת ל-ASN של עמית ב-Cloud Router. בנוסף, צריך לוודא שהגדרת ה-ASN המקומי ב-Cloud Router זהה ל-ASN של עמית בנתב המקומי.

  • לכל קובץ מצורף מוקצה CIDR ייחודי מסוג ‎ /29 מתוך 169.254.0.0/16 ברשת ה-VPC. כתובת IP אחת ב-CIDR ‏‎ /29 מוקצית ל-Cloud Router והשנייה לנתב המקומי.

    בודקים שכתובות ה-IP הנכונות מוקצות לממשק של הנתב המקומי ולשכן ה-BGP שלו. טעות נפוצה היא להגדיר ‎ /30 בממשק הנתב המקומי במקום ‎ /29. Cloud de Confiance מערכת Cloud Interconnect שומרת את כל הכתובות האחרות ב-CIDR‏ ‎ /29.

    מוודאים שלא הקציתם כתובות IP אחרות מ-CIDR הזה לממשק של קובץ ה-VLAN בנתב.

לא ניתן לגשת למכונות וירטואליות ברשת ה-VPC

  • בודקים שאפשר לשלוח פינג לערוץ היציאה ולצירוף ל-VLAN.
  • בודקים שסשן ה-BGP פעיל.
  • בודקים שהנתב המקומי מפרסם ומקבל מסלולים.
  • בודקים שאין חפיפות בין מודעות המסלולים המקומיים לבין Cloud de Confiance טווח הרשתות.
  • מגדירים את גודל ה-MTU לאותם ערכים בנתב המקומי, ב-VPC ובצירוף ל-VLAN.

תנועת הגולשים ב-IPv6 לא עוברת דרך הצירוף ל-VLAN

אם אתם נתקלים בבעיות בחיבור למארחי IPv6, אתם יכולים לנסות את הפעולות הבאות:

  1. מוודאים שפרסום המסלולים של IPv6 מתבצע בצורה תקינה. אם לא מתבצעת פרסום של מסלולי IPv6, אפשר לעיין במאמר פתרון בעיות שקשורות למסלולי BGP ולבחירת מסלולים.
  2. בודקים את כללי חומת האש כדי לוודא שאתם מאפשרים תעבורת נתונים ב-IPv6.
  3. מוודאים שאין חפיפה בין טווחי רשתות המשנה של IPv6 ברשת ה-VPC וברשת המקומית. בדיקה של טווחי כתובות חופפים ברשתות משנה
  4. בודקים אם חרגתם ממכסות וממגבלות כלשהן של המסלולים שנלמדו ב-Cloud Router. אם חרגתם מהמכסה של מסלולים שנלמדו, קידומות IPv6 יושמטו לפני קידומות IPv4. איך בודקים מכסות ומגבלות

  5. מוודאים שכל הרכיבים שקשורים להגדרת IPv6 הוגדרו בצורה נכונה.

    • ברשת ה-VPC הופעל שימוש בכתובות IPv6 פנימיות עם הדגל --enable-ula-internal-ipv6.
    • רשת המשנה של ה-VPC מוגדרת לשימוש בסוג מחסנית IPV4_IPV6.
    • הערך של--ipv6-access-type בתת-הרשת של ה-VPC מוגדר כ-INTERNAL.
    • המכונות הווירטואליות של Compute Engine ברשת המשנה מוגדרות עם כתובות IPv6.
    • הצירוף ל-VLAN מוגדר לשימוש בסוג הערימה IPV4_IPV6.

    • הופעל IPv6 בנתב BGP, והוגדרו כתובות נכונות של הצעד הבא ב-IPv6 עבור סשן ה-BGP.

בדיקת ביצועים בצירופים ל-VLAN

אם אתם צריכים לבדוק את הביצועים של קובצי ה-VLAN המצורפים, השתמשו במכונה וירטואלית ברשת ה-VPC. מוסיפים למכונה הווירטואלית את כלי הביצועים שנדרשים. אל תשתמשו בכתובת ה-IP המקומית של Cloud Router כדי לבדוק את זמן האחזור, למשל באמצעות ICMP ping או MTU של נתיב. השימוש ב-Cloud Router עלול להניב תוצאות בלתי צפויות.

קבלת אבחון

כדי לקבל מידע טכני מפורט ועדכני על Cloud de Confiance הצד של חיבור Dedicated Interconnect לפי דרישה, אפשר לעיין במאמר בנושא קבלת אבחון.

בעיות עם ייפוי כוח (LOA)

בקטעי המשנה האלה מוסבר על בעיות שקשורות למכתב ההסמכה.

לא קיבלתם את מכתב ההרשאה תוך 3 ימי עסקים מאישור ההזמנה

בודקים את תיקיית הספאם או הדואר הזבל באימייל. אם עדיין לא הצלחתם למצוא את מכתב ההסכמה, תוכלו להשיב לאימייל order_received כדי ליצור קשר עם Cloud Customer Care לקבלת עזרה.

נדרשת הבהרה מספק שירותי קולוקציה לגבי פרטי מכתב ההרשאה

לשמש כאיש קשר בין הספק לבין Google. משיבים לאימייל עם ההתראה עם השאלות הספציפיות של הספק, וצוות Cloud Customer Care יכול לעזור לכם להבהיר פרטים.

התקנה שגויה של חיבור צולב

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

קיבלת את הודעת השגיאה 'לא זוהה אור'

כשמוצגת השגיאה 'לא זוהה אור', המשמעות היא שהבדיקה האוטומטית של Google לא זיהתה אור אופטי מספיק מהנתב המקומי באחת מהיציאות או יותר. הבעיה היא בשכבה הפיזית (שכבה 1). כדי לפתור את הבעיה:

  1. בדיקה שההתקנה של החיבור הצולב בוצעה: פונים לספק שירותי ה-colocation ומוודאים שהתנאים הבאים מתקיימים:

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

  2. בדיקת התשתית הפיזית: בודקים את הרכיבים הבאים:

    • חשוב לוודא שכבלים אופטיים מסוג Patch הם מהסוג הנכון ומחוברים בצורה מאובטחת ליציאות של הנתב, וגם לכל לוח Patch ביניים בתוך המתלה. בודקים אם יש סימני נזק, כיפופים חדים או קשרים בכבלים.
    • בודקים את המשדרים-מקלטים (transceivers) (כמו SFP ו-QSFP):
      • מוודאים שדגם המשדר-מקלט תואם לנתב ולמהירות של Dedicated Interconnect שהזמנתם.
      • מוודאים שהמשדר-מקלט מחובר היטב ליציאת הנתב.
      • נסו להוציא את המשדר ואז להחזיר אותו למקומו. אם יש לכם משדר-מקלט נוסף, אתם יכולים לנסות להחליף אותו.
    • בודקים את נוריות ה-LED של היציאה הפיזית בנתב. אם מזוהה אות, נורית הקישור אמורה להידלק (בדרך כלל בצבע ירוק). אם לא נדלק אור או אם נדלק אור ענברי, בדרך כלל יש בעיה.
    • משתמשים בכלים מתאימים לניקוי סיבים אופטיים (כמו עטים לניקוי) כדי לנקות את הקצוות של כבל הסיבים ואת הממשקים האופטיים של המשדר-מקלט. אבק ומזהמים הם סיבות נפוצות מאוד לאובדן אות.

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

    • ‫Cisco IOS/NX-OS: משתמשים בפקודה show interface [interface]. אם מופיעה ההודעה administratively down, צריך להיכנס למצב הגדרת הממשק ולהשתמש בפקודה no shutdown.
    • ‫Juniper Junos: משתמשים בפקודה show interfaces [interface]. הקישור לאדמין צריך להיות 'פעיל'. אפשר להפעיל אותו באמצעות הפקודה set interfaces [interface] enable במצב הגדרה, אם צריך.
    • ‫Arista EOS: משתמשים בפקודה show interface [interface] status. אם מוצג הכיתוב 'disabled', צריך להיכנס למצב הגדרת הממשק ולהשתמש בפקודה no shutdown.

  4. ניתוח רמות האור בנתב: ניגשים ל-CLI של הנתב כדי לבדוק את רמות העוצמה של השידור האופטי (TX) והקבלה (RX). אתם יכולים להשתמש בפקודות הבאות כדי לבדוק את רמות ההספק, בהתאם ליצרן הנתב:

    • ‫Cisco: show interface [interface] transceiver details
    • ‫Juniper: show interfaces diagnostics optics [interface]
    • ‫Arista: show interface [interface] transceiver dom

    אחרי שמשתמשים בפקודה, פועלים לפי ההנחיות הבאות כדי לפרש את המידע:

    • TX Power (עוצמת השידור): העוצמה שבה הנתב משדר. הערך צריך להיות במסגרת המפרט של המשדר-מקלט (בדרך כלל ‎-5 עד ‎+2 dBm עבור אופטיקה LR רגילה). עוצמת שידור נמוכה מאוד מצביעה על יציאה או על רכיב אופטי פגומים בצד שלכם.
    • RX Power: עוצמת האות שהנתב מקבל מצד Google. כדי להעריך את איכות הקישור, אפשר להשתמש בטווחי העוצמה הבאים:
      • טוב: בין ‎-1 dBm ל-‎-10 dBm.
      • שולי: בין ‎-10 dBm ל-‎-14 dBm. יכול להיות שהקישור לא יציב.
      • אין אות: פחות מ-15- dBm, מוצג לעיתים קרובות כ-30- dBm,‏ 40- dBm או 'נמוך'. מציין שמתקבלת כמות קטנה של אור או שלא מתקבל אור בכלל. הדבר מצביע בבירור על שבר פיזי, חיבור שגוי או בעיה בקוטביות.

  5. בדיקת הקוטביות של הסיבים האופטיים: חיבורים של סיבים אופטיים דורשים "הצלבה". כבל הסיבים האופטיים transmit מהנתב צריך להתחבר לכבל הסיבים האופטיים receive בנקודת התיחום של Google, וכבל הסיבים האופטיים transmit מנקודת התיחום של Google צריך להתחבר לכבל הסיבים האופטיים receive בנתב.

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

  6. ביצוע בדיקות של לולאת חזרה (loopback): אפשר לבצע בדיקות מקומיות ומרוחקות של לולאת חזרה כדי לבודד את הצד בחיבור שבו מתרחשות בעיות:

    • Local loopback: use a physical fiber optic loopback plug on your router port. האות הזה מכוון את אות ה-TX של הנתב בחזרה ליציאת ה-RX שלו. אם סטטוס היציאה משתנה ל-'up', סביר להניח שיציאת הנתב והמשדר-מקלט פועלים בצורה תקינה.
    • בדיקת לולאה מרחוק (עם הספק): בקשה מספק שירותי המיקום המשותף להגדיר לולאה פיזית בסיב האופטי בנקודת התיחום של Google, לכיוון הציוד שלכם. אם יציאת הנתב מופיעה, זה מצביע על כך שהנתיב מהנתב שלכם לנקודת הגבול של Google תקין, ושהבעיה עשויה להיות בצד של Google בנקודת הגבול.

  7. בדיקת האבחון: אפשר להשתמש בפקודה הבאה כדי לקבל מידע אבחוני מצד Google של החיבור:

    gcloud compute interconnects get-diagnostics INTERCONNECT_NAME
   --project=PROJECT_ID

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫INTERCONNECT_NAME: השם הייחודי שהקציתם לחיבור Dedicated Interconnect.
    • ‫PROJECT_ID: מזהה הפרויקט.

    בפלט, בודקים את הערכים receivingOpticalPower ו-transmittingOpticalPower של כל קישור במערך הקישורים. הערכים האלה מראים מה הציוד של Google רואה. משווים את עוצמת ה-RX של Google לעוצמת ה-TX של הנתב, ואת עוצמת ה-TX של Google לעוצמת ה-RX של הנתב, תוך התחשבות באובדן מסוים של אות לאורך הסיב האופטי.

  8. איסוף מידע לפנייה לצוות התמיכה: אם ניסיתם את השלבים הקודמים והבעיות נמשכות, מומלץ להשיב לאימייל של ההזמנה ולצרף את הפרטים הבאים:

    • אישור מספק שירותי המיקום המשותף שהחיבור הצולב הותקן בהתאם ל-LOA העדכני.
    • תוצאות בדיקה שסופקו על ידי הספק (כמו קריאות של מד אור בנקודת התיחום).
    • ההגדרה המלאה של הממשקים הרלוונטיים בנתב.
    • הפלט המלא של פקודות האבחון של רמת האור מהנתב (כמו הפלט של show interface transceiver details).
    • פלט ה-JSON המלא של gcloud compute interconnects get-diagnostics.
    • התוצאות המפורטות של כל בדיקות היפוך הקוטביות או בדיקות הלולאה החוזרת שבוצעו.
    • כל האזעקות או השגיאות שדווחו ביומני הנתב עבור הממשקים.

הגדרת LACP לא פועלת

כדי לבדוק אם יש בעיות בהגדרת חבילת Link Aggregation Control Protocol‏ (LACP), צריך לפעול לפי השלבים שבקטע הזה.

  1. מאמתים את הגדרות LACP בנתב: בודקים את הגדרות LACP הבאות בנתב:

    • כל הממשקים הפיזיים שמהווים חלק מחיבור Dedicated Interconnect חייבים להיות מקובצים לקבוצת צבירת קישורים (LAG) אחת.
    • צריך להגדיר את LACP למצב ACTIVE בנתב. ‫Google משתמשת במצב LACP Active. הגדרת הצד שלכם למצב PASSIVE תמנע את יצירת חבילת LACP.
    • מגדירים את טיימר ה-LACP לערך FAST (שנייה אחת) או להגדרה מקבילה במכשיר. טיימרים איטיים (30 שניות) עלולים לעכב את יצירת החבילה ולגרום לכשל בבדיקות אוטומטיות.
    • מגדירים את יציאות החברים באמצעות הפקודות הבאות או שילובים של פקודות, בהתאם לנתב:
      • ‫Cisco: interface [interface], ואז channel-group [number] mode active
      • ‫Juniper: set interfaces [interface] gigether-options 802.3ad ae[number]
      • ‫Arista: ‏interface [interface], ואז channel-group [number] mode active
    • אם משתמשים בנתב Juniper, מבצעים את הגדרת ממשק LAG באמצעות הפקודות הבאות: set interfaces ae[number] aggregated-ether-options lacp active, ואז set interfaces ae[number] aggregated-ether-options lacp periodic fast.

  2. ניתוח הסטטוס של LACP: משתמשים בפקודות הבאות או בשילובים של פקודות כדי לבדוק את מצב LACP בנתב, בהתאם ליצרן הנתב:

    • ‫Cisco: show lacp neighbor, לאחר מכן show lacp internal, ואז show etherchannel summary.
    • ‫Juniper: show lacp interfaces ae[number].

    • ‫Arista: ‏show port-channel [number] lacp neighbor, ואז ‏show etherchannel.

    • מוודאים שמזהה המערכת של Google מופיע בנתב כשותף LACP.

    • מוודאים שהיציאות של החברים צריכות להיות במצב 'איסוף והפצה' (Collecting Distributing) (לרוב מוצגות כ'מאוגדות' (Bundled), 'פעילות' (Active) או 'פועלות' (Up)). מצבים כמו Detached (מנותק), Waiting (בהמתנה), Init (הפעלה) או Suspended (בהשהיה) מצביעים על בעיה במשא ומתן של LACP.

    • מוודאים שהמונים של יחידות הנתונים של LACP ‏ (LACPDU) גדלים, מה שמצביע על כך שהודעות LACP מועברות בין הנתב לבין Google.

  3. איסוף מידע לפנייה לצוות התמיכה: אם ניסיתם את השלבים הקודמים והבעיות נמשכות, מומלץ להשיב לאימייל של ההזמנה ולצרף את הפרטים הבאים:

    • ההגדרה המלאה של LACP מהנתב.
    • הפלט המלא של פקודות סטטוס/שכנות של LACP (כמו show lacp neighbor).

הקישוריות של כתובת ה-IP לא פועלת

כדי לבדוק את הקישוריות של כתובת ה-IP:

  1. צריך להגדיר את כתובת ה-IP הזמנית לבדיקה ואת מסכה של רשת משנה שקיבלתם באימייל productionConfig ישירות בממשק ה-LAG הלוגי (כמו Port-Channel ב-Cisco/Arista, ממשק AE ב-Juniper), ולא בממשקי החברים הפיזיים. כדי לוודא שהגדרתם את כתובות ה-IP לבדיקה בצורה נכונה, משתמשים בפקודות הבאות או בשילובים של פקודות, בהתאם ליצרן הנתב:

    • ‫Cisco: show running-config interface port-channel [number], ואז show ip interface port-channel [number]
    • ‫Juniper: ‏show configuration interfaces ae[number] unit 0 family inet, ואז show interfaces terse ae[number].0
    • ‫Arista: ‏show running-config interface port-channel [number], ואז show ip interface port-channel [number]

  2. בודקים את טבלת ה-ARP בנתב כדי לראות אם כתובת ה-MAC של כתובת ה-IP לבדיקה בצד של Google בממשק LAG נפתרה. משתמשים בפקודות הבאות:

    • ‫Cisco: show arp | include [Google Test IP]
    • ‫Juniper: show arp no-resolve | match [Google Test IP]
    • ‫Arista: show arp | grep [Google Test IP]

    רשומה של ARP עם הערך 'לא מלאה' מציינת בעיה בשכבה 2, או ש-Google לא מגיבה לבקשות ARP.

  3. מבצעים בדיקת פינג מממשק ה-LAG של הנתב לכתובת ה-IP של הבדיקה של Google. משתמשים בפינג מכתובת ה-IP לבדיקה שהוקצתה לממשק LAG. אחרי שמקבלים את כתובת ה-IP, משתמשים בפקודות הבאות בהתאם ליצרן הנתב:

    • ‫Cisco/Arista: ping [Google Test IP] source [Your LAG Test IP]
    • ‫Juniper: ping [Google Test IP] source [Your LAG Test IP]

  4. מוודאים שאין חומות אש, רשימות של בקרת גישה (ACL) או מדיניות אבטחה בנתב שחוסמים את LACP (פרוטוקול LACP משתמש ב-EtherType‏ 0x8809) או את ICMP Echo/Reply (פינג).

  5. בודקים את סטטוס LACP של הנתב באמצעות הפקודה הבאה:

    gcloud compute interconnects get-diagnostics INTERCONNECT_NAME
   --project=PROJECT_ID

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫INTERCONNECT_NAME: השם הייחודי שהקציתם לחיבור Dedicated Interconnect.
    • ‫PROJECT_ID: מזהה הפרויקט.

    בודקים את השדה lacpStatus של כל אחד מהקישורים. הערכים state,‏ googleSystemId ו-neighborSystemId מציינים אם Google מזהה את הנתב שלכם כשותף LACP, ואם המצבים מסונכרנים. לאחר מכן, בודקים את המערך arpCache כדי לראות אם בצד של Google נפתרה הבעיה ב-ARP עבור כתובת ה-IP של הבדיקה.

  6. איסוף מידע לפנייה לצוות התמיכה: אם ניסיתם את השלבים הקודמים והבעיות נמשכות, מומלץ להשיב לאימייל של ההזמנה ולצרף את הפרטים הבאים:

    • הגדרת ה-IP של ממשק ה-LAG.
    • הפלט של טבלת ה-ARP ב-LAG.
    • התוצאות של בדיקת ה-ping שמבוססת על המקור מממשק LAG.
    • אישור לכך שחומות אש או רשימות ACL לא חוסמות LACP או ICMP.
    • פלט ה-JSON המלא של הפקודה gcloud compute interconnects get-diagnostics.

Partner Interconnect

סשן BGP לא פועל (חיבורים בשכבה 2)

  • בודקים שהנתב המקומי הוגדר עם סשן BGP לנתבי Cloud Router. מידע נוסף מופיע במאמר בנושא הגדרה של נתבים מקומיים ל-Partner Interconnect.
  • מפעילים BGP עם כמה קפיצות בנתב המקומי עם לפחות שתי קפיצות.
  • בודקים שכתובת ה-IP של השכן מוגדרת בצורה נכונה בנתב המקומי. משתמשים בכתובת ה-IP של עמית BGP ‏ (cloudRouterIpAddress) שהוקצתה לצירוף ל-VLAN.
  • בודקים שההגדרה של ה-ASN המקומי בנתב המקומי תואמת ל-ASN של עמית ב-Cloud Router‏ (16550). בנוסף, בודקים שההגדרה של ה-ASN המקומי ב-Cloud Router תואמת ל-ASN של עמית בנתב המקומי.

סשן BGP לא פועל (חיבורים בשכבה 3)

  • צריך להגדיר את Cloud Router עם מספר ה-ASN של ספק השירות. צריך לפנות לספק השירות לקבלת עזרה.

צירוף ל-VLAN מושבת בחיבור Partner Interconnect

הסטטוס של צירוף ל-VLAN יכול להיות 'לא פעיל' גם אם אין בעיות בהגדרה ובחיבור Partner Interconnect.Cloud de Confiance

מוודאים שהגדרתם EBGP multihop בנתב המקומי כך שיהיו לפחות ארבע קפיצות. דוגמה להגדרה מופיעה במאמר הגדרה של נתבים מקומיים.

בעיה במפתח ההתאמה בחיבור Partner Interconnect

כשמנסים להגדיר חיבור Partner Interconnect, יכול להיות שתופיע הודעת שגיאה כמו Google - Provider status not available (Google – סטטוס הספק לא זמין). כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

  1. מוודאים שמפתח הצימוד נוצר על ידי חיבור ה-VLAN בצד הלקוח (סוג PARTNER). המפתח הוא מחרוזת ארוכה ואקראית ש-Google משתמשת בה כדי לזהות את הקובץ המצורף. אזור היעד Cloud de Confiance והדומיין של הזמינות ב-Edge מוצפנים במפתח הצימוד בפורמט הבא:

    <random_string>/<region_name>/<domain>

    השדה domain מכיל את המחרוזת any אם קובץ ה-VLAN לא מוגבל לדומיין מסוים, או אם לא ציינתם את דומיין הזמינות של קצה הרשת. מידע נוסף על מפתחות ההתאמה זמין במאמר בנושא מפתח התאמה.

  2. מוודאים שדומיין הזמינות של חיבור Partner Interconnect זהה לדומיין שצוין במפתח הצימוד.

אי אפשר לבצע פינג ל-Cloud Router (חיבורים בשכבה 2)

  • צריך לוודא שיש לכם את חיבור ה-VLAN הנכון בממשק המשנה של הנתב המקומי. הפרטים של חיבור ה-VLAN צריכים להיות זהים לפרטים שספק השירות סיפק.
  • בודקים שיש לכם את כתובת ה-IP הנכונה בממשק המשנה של הנתב המקומי. אחרי שספק השירות מגדיר את ה-VLAN attachment, המערכת מקצה ל-attachment זוג של כתובות IP מקומיות. אחת מהן היא לממשק ב-Cloud Router המשויך (cloudRouterIpAddress), והשנייה היא לממשק משנה בערוץ היציאות של הנתב המקומי, ולא לערוץ היציאות עצמו (customerRouterIpAddress).
  • אם אתם בודקים את הביצועים של הקבצים המצורפים, אל תבצעו פינג ל-Cloud Router. במקום זאת, צריך ליצור מכונה וירטואלית ברשת ה-VPC ואז להשתמש בה. מידע נוסף זמין במאמר בנושא בדיקת ביצועים.

אובדן של עוצמת האות האופטי ביציאה של חיבור Partner Interconnect

אם יש אובדן של עוצמת האות האופטי ביציאה, יכול להיות שתיתקלו באחת מהבעיות הבאות:

  • אובדן קישוריות בשכבה 3 (אובדן של סשן BGP) או חוסר אפשרות לגשת למופעי מכונות וירטואליות של Cloud de Confiance .
  • ירידה בביצועים של חבילת הקישורים. הבעיה הזו מתרחשת אם מקבצים כמה יציאות 10GE ורק חלק מהקישורים בחבילה פועלים.

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

  • משדר-מקלט פגום
  • מערכת תחבורה פגומה
  • בעיה פיזית בסיבים

כדי לפתור את הבעיה, צריך לפנות לספק של Partner Interconnect או לספק המעגל. הם יכולים לבצע את השלבים הבאים:

  1. בודקים שהמשדר-מקלט שלהם פועל.
  2. מריצים לולאה קשה לחדר הפגישה (MMR) כדי לבדוק אם רמות האור במכשיר פועלות כצפוי.
  3. בודקים אם הבעיות הן בצד שלהם או בצד של Google. הדרך הכי טובה לבודד את הממשק היא ליצור לולאה דו-כיוונית בנקודת התיחום. הממשקים בכל צד ישדרו אור עד לנקודת התיחום, שם האור יחזור אל עצמו. הצד הפגום יהיה הצד של ההפרדה שלא מופיע בצורה ברורה.
  4. לנקות את כל הסיבים בצד שלהם ולהחזיר אותם למקומם.

אי אפשר לשלוח וללמוד ערכי MED דרך חיבור Partner Interconnect ברמה 3

אם אתם משתמשים בחיבור Partner Interconnect שבו ספק שירות בשכבה 3 מטפל ב-BGP בשבילכם, Cloud Router לא יכול ללמוד ערכי MED מהנתב המקומי שלכם או לשלוח ערכי MED לנתב הזה. הסיבה לכך היא שערכי MED לא יכולים לעבור דרך מערכות אוטונומיות. בחיבור מהסוג הזה, אי אפשר להגדיר עדיפויות של מסלולים למסלולים שמפורסמים על ידי Cloud Router לנתב המקומי. בנוסף, אי אפשר להגדיר עדיפויות של מסלולים למסלולים שמפורסמים על ידי הנתב המקומי ברשת ה-VPC.

תנועת ה-IPv6 לא פועלת אחרי שינוי סוג ה-stack של קובץ מצורף ל-dual stack

  1. בודקים את הסטטוס של Cloud Router ומוודאים שמוצג status: UP.

    אם פרוטוקול BGP לא פועל, צריך לבצע את הפעולות הבאות:

    1. מוודאים שהנתב המקומי (או הנתב של השותף אם אתם משתמשים בשותף בשכבה 3) מוגדר עם סשן BGP של IPv6, ושהסשן משתמש בכתובות IPv6 הנכונות.

    2. צופים בהגדרות של סשן BGP ומוודאים שהערך 'TRUE' מוצג עבור Cloud Router bgpPeers.enable.

    אם פרוטוקול BGP פועל, צופים בנתיבים של Cloud Router כדי לוודא שכתובות ה-IPv6 הצפויות best_routes מוצגות.

    אם לא מוצגים ה-best_routes הצפויים, צריך לוודא שהנתב המקומי (או הנתב של השותף אם אתם משתמשים בשותף Layer 3) מוגדר עם נתיבי IPv6 נכונים.

כל שאר הבעיות

לקבלת עזרה נוספת, אפשר לפנות אל ספק השירות. במקרה הצורך, ספק השירותים שלכם יפנה אל Google כדי לפתור בעיות שקשורות לצד של Google ברשת.

HA VPN over Cloud Interconnect

כשפורסים HA VPN דרך Cloud Interconnect, יוצרים שתי שכבות תפעוליות:

  • השכבה של Cloud Interconnect, שכוללת את חיבורי ה-VLAN ואת Cloud Router ל-Cloud Interconnect.
  • רמת השירות HA VPN, שכוללת את שערי HA VPN, מנהרות HA VPN ו-Cloud Router ל-HA VPN.

לכל רמה נדרש Cloud Router משלה:

  • ה-Cloud Router ל-Cloud Interconnect משמש אך ורק להחלפת קידומות של שער VPN בין צירופי ה-VLAN. ‫Cloud Router הזה משמש רק את חיבורי ה-VLAN של רמת Cloud Interconnect. אי אפשר להשתמש בו ברמת השירות HA VPN.
  • ה-Cloud Router ל-HA VPN מחליף קידומות בין רשת ה-VPC לרשת המקומית. מגדירים את Cloud Router ל-HA VPN ואת סשני ה-BGP שלו באותו אופן כמו בהטמעה רגילה של HA VPN.

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

כדי לפתור בעיות בפריסת HA VPN דרך Cloud Interconnect, צריך קודם לפתור בעיות ברמת Cloud Interconnect. אחרי שמוודאים ש-Cloud Interconnect פועל בצורה תקינה, פותרים בעיות בשכבת HA VPN.

לא ניתן ליצור סשן BGP עבור Cloud Router ל-Cloud Interconnect

כדי לזהות אם סשן ה-BGP שמשויך לצירוף ל-VLAN מושבת, מריצים את הפקודה הבאה:

   gcloud compute routers get-status INTERCONNECT_ROUTER_NAME

מחליפים את INTERCONNECT_ROUTER_NAME בשם של Cloud Router שיצרתם בשביל רמת השירות Cloud Interconnect של פריסת HA VPN over Cloud Interconnect.

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

  1. פועלים לפי השלבים במאמרים בדיקת חיבורים וקבלת אבחון כדי לוודא שחיבור Cloud Interconnect הבסיסי תקין.
  2. בודקים שממשק סשן ה-BGP מצביע על הקובץ המצורף הנכון.
  3. בודקים את כתובות ה-IP שהוגדרו לממשק של סשן ה-BGP ב-Cloud Router ובנתב המקומי.
  4. בודקים שמספרי ה-ASN מוגדרים בצורה נכונה גם ב-Cloud Router וגם בנתב המקומי.
  5. בודקים שהחיבור של Cloud Interconnect והחיבור ל-VLAN נמצאים במצב admin-enabled.

לא ניתן ליצור מנהרת HA VPN

כדי לבדוק את מצב המנהרה, מריצים את הפקודה:

gcloud compute vpn-tunnels describe VPN_TUNNEL_NAME

מחליפים את VPN_TUNNEL_NAME בשם של מנהרת HA VPN.

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

  1. מכיוון שמנהרת ה-VPN מנותבת דרך צירוף ל-VLAN, צריך לוודא שהסשן של BGP שמשויך לצירוף ל-VLAN נוצר. אם לא, כדאי לעיין במאמר לא ניתן ליצור סשן BGP עבור Cloud Router ל-Cloud Interconnect.
  2. בודקים אם מפתחות ה-PSK וההצפנה של המנהור מוגדרים בצורה נכונה בשערי Cloud VPN ובשערי VPN מקומיים.
  3. בודקים שהודעת ה-BGP של הנתב המקומי כוללת את כתובות שער ה-VPN המקומי. אם לא, צריך להתאים את הגדרות ה-BGP של הנתב המקומי כדי לפרסם את הכתובות.
  4. בודקים שהנתיבים לשערי VPN מקומיים לא נמחקו בגלל התנגשויות עם נתיבי BGP קיימים. אם יש התנגשויות, צריך לשנות את הכתובות של שער ה-VPN או את המסלולים שפורסמו.

  5. בודקים שההודעה של BGP מ-Cloud Router כוללת את כתובות שער ה-HA VPN. אפשר לבדוק את זה מהנתב המקומי או על ידי בדיקת השדה advertisedRoutes של עמית ה-BGP. כדי להציג את השדה advertisedRoutes, מריצים את הפקודה הבאה:

    gcloud compute routers get-status INTERCONNECT_ROUTER_NAME

    מחליפים את INTERCONNECT_ROUTER_NAME בשם של Cloud Router שיצרתם בשביל רמת השירות Cloud Interconnect של פריסת HA VPN over Cloud Interconnect.

    אם כתובות שער ה-HA VPN לא מפורסמות, צריך לוודא שחיבורי ה-VLAN משויכים לנתב Cloud Interconnect המוצפן. בודקים שכל צירוף ל-VLAN מוגדר עם כתובות IPv4 פנימיות אזוריות צפויות (--ipsec-internal-addresses).

לא ניתן ליצור סשן BGP עבור Cloud Router ל-HA VPN

כדי לבדוק אם סשן ה-BGP שמשויך לצירוף ל-VLAN מושבת, מריצים את הפקודה:

gcloud compute routers get-status VPN_ROUTER_NAME

מחליפים את VPN_ROUTER_NAME בשם של Cloud Router שיצרתם לרמת השירות HA VPN של פריסת HA VPN over Cloud Interconnect.

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

  1. מכיוון שהתנועה של BGP מנותבת דרך מנהרת ה-VPN, צריך לוודא שמנהרת ה-VPN נוצרה. אם לא, צריך לפעול לפי השלבים במאמר אי אפשר ליצור מנהרת HA VPN.
  2. בודקים שממשק סשן ה-BGP של Cloud Router מצביע על מנהרת ה-VPN הנכונה.
  3. בודקים שכתובות ה-IP של הממשק של סשן ה-BGP מוגדרות בצורה נכונה גם ב-Cloud Router וגם במכשיר ה-VPN המקומי.
  4. בודקים שמספרי ה-ASN מוגדרים בצורה נכונה גם ב-Cloud Router וגם בנתב המקומי.

תעבורת הנתונים ב-VPC לא מגיעה לרשתות מקומיות או להיפך

תעבורת הנתונים שנוצרת ממכונה וירטואלית, למשל מ-ping או מ-iperf, לא יכולה להגיע לרשת המקומית, או שהרשת המקומית לא יכולה להגיע לתעבורת הנתונים שנוצרת ממכונה וירטואלית.

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

  1. מכיוון שהתנועה במכונה הווירטואלית מנותבת דרך מנהרת ה-VPN, צריך לוודא ש-Cloud Router שולח את הנתיב מהמכונה הווירטואלית למנהרת ה-VPN.

  2. בודקים שהסשן של Cloud Router עבור HA VPN נוצר. אם לא, כדאי לעיין במאמר אי אפשר ליצור סשן BGP לנתב Cloud Router עבור HA VPN.

אובדן מנות או תפוקה נמוכה

תעבורת נתונים ממכונות וירטואליות ברשתות VPC לרשתות מקומיות או תעבורת נתונים מרשתות מקומיות לרשתות VPC נחסמת.

אתם מבחינים באובדן מנות או בנפח נתונים נמוך דרך ping, iperf וכלים אחרים לניטור רשת.

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

  1. בודקים אם יש עומס תנועה על חיבור ה-VLAN. אם כן, כדאי לפצל את התנועה בין יותר חיבורי VLAN או לעדכן את הקיבולת של החיבור.
  2. בודקים אם יש עומס תנועה ב-HA VPN. אם כן, צריך ליצור מנהרות VPN נוספות על גבי צירוף ל-VLAN כדי לחלק מחדש את תעבורת הנתונים.
  3. מוודאים שאין עליות חדות או פתאומיות בנפח התנועה או תנועה לא סדירה. יכול להיות שזרמי TCP יושפעו מזרמים אחרים, כמו תנועת UDP עם פרצי נתונים.
  4. בודקים אם מנות שגדולות מה-MTU של המנהרה מפוצלות. מוודאים שערך ה-MTU מוגדר בצורה תקינה בחיבורי ה-VLAN, ובודקים שלא מתבצעת הצמדה של תנועת ה-UDP ל-MSS.

הירידות שמוצגות במדדים של צירוף ל-VLAN נובעות מBANDWIDTH_THROTTLE

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

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

כדי לפתור את הבעיה, אפשר להקטין את השימוש בצירוף הזה, להגדיל את הקיבולת שלו או להשתמש ביותר צירופים ל-VLAN.

לא ניתן למחוק צירוף מוצפן ל-VLAN

כשמנסים למחוק צירוף ל-VLAN מוצפן ל-Dedicated Interconnect או ל-Partner Interconnect, מופיעה השגיאה הבאה:

ResourceInUseByAnotherResourceException

כדי לפתור את הבעיה הזו, צריך לוודא שמחקתם קודם את כל שערים ומנהרות ה-HA VPN שמשויכים לחיבור ה-VLAN המוצפן. מידע נוסף זמין במאמר מחיקת HA VPN דרך Cloud Interconnect.

סוגי כתובות IP שונים בצירופים מוצפנים ל-VLAN

כשמנסים ליצור שער HA VPN לשימוש בפריסת HA VPN דרך Cloud Interconnect, מקבלים את השגיאה הבאה:

One of the VLAN attachments has private IP address type, while the other one
has public IP address type; they must have same IP address type.

השגיאה הזו מתרחשת כשמציינים שני קבצים מצורפים של VLAN מוצפנים לשער HA VPN, ולממשקי מנהרות ה-HA VPN יש סכימות שונות של הקצאת כתובות IP. סוגי כתובות ה-IP צריכים להיות זהים בשני קובצי ה-VLAN.

במהלך יצירת שער VPN, צריך לציין חיבורי VLAN שמשתמשים בשתי כתובות IP פרטיות או בשתי כתובות IP ציבוריות. אם השגיאה הזו מופיעה כשיוצרים שער VPN, צריך לנסות שוב ליצור את קובץ ה-VLAN עם סוג הכתובת הנכון.

חסר צירוף ל-VLAN מממשק שער HA VPN

אם פורסים שער HA VPN דרך Cloud Interconnect, צריך לציין צירוף ל-VLAN מוצפן לשני הממשקים של שער ה-HA VPN.

אם מציינים רק צירוף אחד ל-VLAN, מופיעה השגיאה הבאה:

VPN Gateway should have VLAN attachment specified in both interfaces or in none.

כדי לפתור את הבעיה, צריך ליצור את שער ה-HA VPN ולציין שני קבצים מצורפים של VLAN.

סוג הצירוף ל-VLAN לא תקין

הסוג של צירופים מוצפנים ל-VLAN חייב להיות DEDICATED או PARTNER.

אם מציינים סוג לא תקין לצירוף ל-VLAN מוצפן, מופיעה הודעת השגיאה הבאה:

VLAN attachment should have type DEDICATED or PARTNER.

כדי לפתור את הבעיה, צריך ליצור רק צירופים מוצפנים ל-VLAN עם הסוג DEDICATED או PARTNER.

ערך MTU שגוי לצירוף ל-VLAN

כשיוצרים צירוף מוצפן ל-VLAN עבור Dedicated Interconnect, מופיעה הודעת השגיאה הבאה:

Wrong MTU value [mtuValue] for VLAN attachment.
The supported MTU for IPsec packets for HA VPN over Cloud Interconnect is 1440.

כדי לפתור את הבעיה, צריך ליצור מחדש את הקובץ המצורף עם הערך הנכון של 1440, שהוא ערך ברירת המחדל.

לצירופים ל-VLAN יש סוג שונה

כשמציינים צירופים מוצפנים ל-VLAN לממשקי שער HA VPN, מופיעה הודעת השגיאה הבאה:

VLAN attachments should both have same type DEDICATED or PARTNER.
But found one DEDICATED and one PARTNER.

כדי לפתור את הבעיה, צריך לציין שני קבצים מצורפים של VLAN מאותו סוג, DEDICATED או PARTNER.

צירופי VLAN ייעודיים לא נמצאים באותו אזור מטרופוליטני

כשמציינים צירופים מוצפנים ל-VLAN לממשקי שער HA VPN, מופיעה הודעת השגיאה הבאה:

Dedicated VLAN attachments should be in the same metropolitan area.

כדי לפתור את הבעיה, צריך ליצור שני קבצים מצורפים של VLAN מוצפנים ל-Dedicated Interconnect באותו אזור מטרופוליטני.

שער HA VPN לא נמצא באותה רשת כמו חיבור ה-VLAN

כשמציינים צירופים מוצפנים ל-VLAN לממשקי שער HA VPN, מופיעה הודעת השגיאה הבאה:

VPN Gateway should be in the same network as VLAN attachment.
VLAN attachment network: [networkName], VPN gateway network: [networkName]

כדי לפתור את הבעיה, צריך ליצור את שער ה-HA VPN באותה רשת שבה נמצאים קבצים מצורפים של VLAN מוצפנים.

סוג הצפנה שגוי לצירוף ל-VLAN

כשמציינים צירופים מוצפנים ל-VLAN לממשקי שער HA VPN, מופיעה הודעת השגיאה הבאה:

Wrong encryption type for VLAN attachment [interconnectAttachmentName],
required IPSEC.

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

האזור של הצירוף ל-VLAN לא תואם ל-interfaceId

כשמציינים צירופים מוצפנים ל-VLAN לממשקי שער HA VPN, מופיעה הודעת השגיאה הבאה:

VLAN attachment zone should match interfaceId: interface 0 - zone1,
interface 1 - zone2, but found interface [interfaceId] - [zone] for
[interconnectAttachmentName].

הממשק הראשון של שער HA VPN ‏ (interface 0) צריך להיות זהה לצירוף ה-VLAN המוצפן מאזור 1, והממשק השני (interface 1) צריך להיות זהה לצירוף ה-VLAN המוצפן מאזור 2.

כדי לפתור את הבעיה, צריך לציין צירופים מוצפנים ל-VLAN מהאזורים שתואמים בצורה נכונה לממשקי שער ה-HA VPN.

שער ה-VPN לא נמצא באותו אזור כמו צירוף ל-VLAN

כשמציינים צירופים מוצפנים ל-VLAN לממשקי שער HA VPN, מופיעה הודעת השגיאה הבאה:

VPN Gateway should be in the same region as VLAN attachment.
VLAN attachment region: [region], VPN gateway region: [region].

כדי לפתור את הבעיה, צריך ליצור שערי HA VPN וקבצים מצורפים של VLAN מוצפן באותו אזור.

הצירוף ל-VLAN של השותף לא פעיל

כשמציינים צירופים מוצפנים ל-VLAN עבור Partner Interconnect לממשקי שער HA VPN, מופיעה הודעת השגיאה הבאה:

Interconnect Attachments [name] must be in active state.

צריך להפעיל את חיבורי ה-VLAN ל-Partner Interconnect לפני שמקשרים אותם לממשקי שער HA VPN.

מידע נוסף זמין במאמר בנושא הפעלת חיבורים.

סוג שגוי של Cloud Router שצוין לצירוף ל-VLAN

כשמנסים ליצור צירוף מוצפן ל-VLAN, מופיעה הודעת השגיאה הבאה:

Router must be an encrypted interconnect router.

כדי לפתור את הבעיה, צריך ליצור Cloud Router עם הדגל --encrypted-interconnect-router. הנתב הזה של Cloud Router משמש באופן בלעדי ל-HA VPN דרך Cloud Interconnect.

לאחר מכן, יוצרים את קובץ ה-VLAN המצורף המוצפן ומספקים את Cloud Router המוצפן.

Cross-Cloud Interconnect

בקטע הזה מתוארות בעיות שיכולות לקרות עם Cross-Cloud Interconnect.

‫Google תומכת בחיבור עד שהוא מגיע לרשת של ספק שירותי הענן האחר. ‫Google לא יכולה להבטיח זמן פעולה רציף של ספק שירותי הענן האחר, ולא יכולה ליצור כרטיס תמיכה בשמכם. אם תתנו הרשאה, צוות Customer Care יוכל לתקשר ישירות עם צוות התמיכה של ספק הענן האחר שלכם כדי לזרז את פתרון הבעיה. עם זאת, צריך לפתוח כרטיס תמיכה אצל הספק השני.

חוסר התאמה בין יציאות מיותרות

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

לדוגמה, אתם יכולים לתת הוראות כמו אלה:

  • חיבור של gcp-1 אל azure-1.

  • חיבור של gcp-2 אל azure-2.

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

  • חיבור של gcp-1 אל azure-2.

  • חיבור של gcp-2 אל azure-1.

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

לדוגמה, נניח שלרשת azure-1 יש צירוף ל-VLAN עם פירינג בכתובת 169.254.0.2, ולרשת azure-2 יש צירוף ל-VLAN עם פירינג בכתובת 169.254.99.2. מחליפים את טווחי כתובות ה-IP כך שהקובץ המצורף azure-1 ישתמש בכתובת 169.254.99.2 והקובץ המצורף azure-2 ישתמש בכתובת 169.254.0.2.

אם השתמשתם במזהי VLAN שונים לחיבור בכל יציאה, תצטרכו גם להחליף את מזהי ה-VLAN שבהם נעשה שימוש בחיבורים. ב-Azure, התרחיש הזה לא אפשרי כי הוא מחייב שימוש באותו מזהה VLAN בשני הפורטים לכל חיבור.

מזהי VLAN

לפעמים בעיות בקישוריות נובעות מטעויות בערכים של מזהה VLAN. מזהה VLAN הוא שדה בצירוף ל-VLAN של Cross-Cloud Interconnect.

Azure

ב-Azure, צריך להקצות את מזהי ה-VLAN באופן זהה בשני הפורטים של זוג. כשיוצרים את ה-VLAN attachment, המסוף Cloud de Confiance אוכף את הדרישה הזו. עם זאת, אם מגדירים את הקבצים המצורפים באמצעות Google Cloud CLI או API, אפשר להקצות מזהי VLAN שונים. הסיכון הזה גדול במיוחד אם אתם מאפשרים הקצאה אוטומטית של מזהי VLAN כשאתם יוצרים את הקובץ המצורף. אם לא מגדירים את המזהה באופן מפורש, הוא מוקצה באופן אוטומטי.

AWS

כשמתחברים ל-AWS, אפשר להשתמש בהקצאה אוטומטית של מזהי VLAN. עם זאת, כשמגדירים את משאבי AWS, צריך להגדיר ידנית את מזהי ה-VLAN כך שיתאימו למזהים שהוקצו אוטומטית על ידי Cloud de Confiance . בנוסף, חשוב לא להתבלבל בין מזהי ה-VLAN שצריך להשתמש בהם לכל יציאה. אם מוגדר מזהה VLAN שגוי ביציאה, הנתבים הווירטואליים לא יכולים לתקשר.

בדיקת הקישוריות

אם עדיין לא עשיתם את זה, צריך לפעול לפי השלבים לאימות הקישוריות בין Cloud de Confiance לבין רשת הענן המרוחקת: