פתרון בעיות

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

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

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

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

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

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

  • אפשר לבדוק אם יש שיבושים ידועים בGoogle Cloud לוח הבקרה של הסטטוס. אפשר גם להירשם לקבלת התראות שוטפות על אירועים ב-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. במקרה של שותפי L3, השותף מגדיר את BGP באופן אוטומטי. אם פרוטוקול BGP לא מופעל, צריך לפנות לשותף. לא רלוונטי כן לא רלוונטי
מוודאים שהמכשיר המקומי למד את כתובת ה-MAC הנכונה של צד Google Cloud של החיבור. מידע נוסף מופיע במאמר פתרון בעיות ב-ARP. כן לא רלוונטי לא רלוונטי
מוודאים שלנתב Cloud יש ממשק ועמית BGP. אי אפשר לבצע פינג ל-Cloud Router אלא אם הממשק וה-BGP peer מוגדרים באופן מלא, כולל ה-ASN המרוחק.
  • במקרה של Dedicated Interconnect, אפשר לעיין במאמר הסשן של BGP לא פועל.
  • ב-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. הצד Google Cloud של חיבור 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. Google Cloud מערכת שומרת את כל הכתובות האחרות ב-CIDR‏ ‎ /29.

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

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

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

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

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

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

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

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

    • ב-BGP peer מופעל IPv6 ומוגדרות כתובות נכונות של IPv6 next hop עבור סשן ה-BGP.

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

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

קבלת אבחון

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

Partner Interconnect

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

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

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

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

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

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

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

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

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

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

    <random_string>/<region_name>/<domain>

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

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

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

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

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

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

  • אובדן קישוריות בשכבה 3 (אובדן של סשן BGP) או חוסר אפשרות לגשת למופעי מכונות וירטואליות של Google Cloud .
  • ירידה בביצועים של חבילת הקישורים. הבעיה הזו מתרחשת אם כמה יציאות 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 לא פועלת אחרי שינוי סוג הערימה של קובץ מצורף לערימה כפולה

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

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

    1. מוודאים שהנתב המקומי (או הנתב של השותף אם אתם משתמשים בשותף בשכבה 3) מוגדר עם סשן IPv6 BGP, ושהסשן משתמש בכתובות 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 ואת המנהרות, וגם את 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, ויש להם סכימות שונות של הקצאת כתובות IP לממשקי מנהרות HA VPN. סוגי כתובות ה-IP צריכים להיות זהים בשני קבצים מצורפים של VLAN.

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

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

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

אם מציינים רק צירוף אחד ל-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 לא יכולה להבטיח זמן פעולה רציף מספק שירותי הענן האחר, ולא יכולה ליצור כרטיס תמיכה בשמכם. בהסכמתכם, צוות Cloud 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 עם קישור בין רשתות שכנות (peering) בכתובת 169.254.0.2, ולרשת azure-2 יש צירוף ל-VLAN עם קישור בין רשתות שכנות (peering) בכתובת 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, המסוף Google Cloud אוכף את הדרישה הזו. עם זאת, אם מגדירים את הקבצים המצורפים באמצעות Google Cloud CLI או API, אפשר להקצות מזהי VLAN שונים. הסיכון הזה גבוה במיוחד אם אתם מאפשרים הקצאה אוטומטית של מזהי VLAN כשאתם יוצרים את הקובץ המצורף. אם לא מגדירים את המזהה באופן מפורש, הוא מוקצה באופן אוטומטי.

AWS

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

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

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