פתרון בעיות

מדריך פתרון הבעיות הזה יכול לעזור לכם לפתור בעיות נפוצות שאולי תיתקלו בהן כשאתם משתמשים ב-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.

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

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

חסרות תת-רשתות בחיבור

כדי לפרסם את כל רשתות המשנה הזמינות, מציינים את המסלולים החסרים באמצעות custom advertised routes ומפרסמים את כל המסלולים של רשתות המשנה בין אזורים באמצעות global dynamic routing. לשם כך, בצע את הצעדים הבאים:

  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 הנכונה של צד Cloud de Confiance by S3NS של החיבור. מידע נוסף זמין במאמר בנושא פתרון בעיות ב-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. הצד 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 כל הכתובות האחרות ב-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 וברשת המקומית. ראו בדיקה של טווחי כתובות IP חופפים ברשתות משנה.
  4. בודקים אם חרגתם ממכסות וממגבלות כלשהן של המסלולים שנלמדו ב-Cloud Router. אם חרגתם מהמכסה של מסלולים שנלמדו, קידומות IPv6 יושמטו לפני קידומות IPv4. איך בודקים מכסות ומגבלות

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

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

    • ל-BGP peer מופעל IPv6 ומוגדרות כתובות נכונות של הצעד הבא ב-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 יעזור לכם להבהיר פרטים.

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

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

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

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

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

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

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

    • חשוב לוודא שכבל הגישור מסיבי אופטי מהסוג הנכון ומחובר היטב ליציאות של הנתב ולכל לוח גישור ביניים בתוך המתלה. בודקים אם יש סימני נזק, כיפופים חדים או פיתולים בכבלים.
    • בודקים את המשדרים-מקלט (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

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

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

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

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

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

    • 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. הגדרת הצד שלכם למצב 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], then 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, then show etherchannel.

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

    • מוודאים שהיציאות של החברים צריכות להיות במצב 'איסוף והפצה' (Collecting Distributing) (לרוב מוצג כ'חבילה' (Bundled), 'פעיל' (Active) או 'פועל' (Up)). מצבים כמו 'מנותק', 'בהמתנה', 'הפעלה' או 'בהשהיה' מצביעים על בעיה במשא ומתן של 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], then 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.
    • תוצאות בדיקת הפינג מבוססת-המקור מממשק ה-LAG.
    • אישור לכך שחומות אש או רשימות ACL לא חוסמות LACP או ICMP.
    • פלט ה-JSON המלא של הפקודה gcloud compute interconnects get-diagnostics.

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)

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

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

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

מוודאים שהגדרתם 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, החיבור מקצה זוג של כתובות 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 דרך חיבור L3 Partner Interconnect

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

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

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

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

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

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

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

    אם כתובות ה-IPv6 הצפויות 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 מצביע על ה-Attachment הנכון.
  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, צריך לוודא שהנתיב מהמכונה הווירטואלית למנהרת ה-VPN נשלח על ידי Cloud Router.

  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. הבעיה הזו מתרחשת כשנשלחת תנועה בקצב גבוה מדי דרך הקובץ המצורף, ולכן עומס תנועה קל מוגבל. זו התנהגות רגילה, ובדרך כלל היא מטופלת על ידי שידור חוזר של TCP.

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

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

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

AWS

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

אימות החיבור

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