פתרון בעיות ב-Network Connectivity Center

מידע על שלבים לפתרון בעיות שיכולים לעזור לכם אם נתקלתם בבעיות בשימוש ב-Network Connectivity Center, ב-hybrid spokes, ב-VPC spokes, ב-NCC Gateway spokes או בהפצה של חיבור Private Service Connect.

בקטע הערות לגבי NCC בדף הסקירה הכללית מפורטות מגבלות ידועות.

בעיות נפוצות בתחביר של פקודות

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

צירוף משאבים ל-spokes

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

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

אם המסלולים לא מופצים בצורה תקינה בין האזורים, צריך לוודא שמצב הניתוב הדינמי של רשת ה-VPC מוגדר ל-global.

תנועת נתונים לא זורמת בין שתי רשתות שאינן רשתותGoogle Cloud

בהקשר הזה,Google Cloud רשת שאינה רשת Google מתייחסת למרכז נתונים מקומי, לסניף או לרשת של ספק ענן אחר.

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

שכפול של פרסום נתיבים מסשנים של BGP

אם יש פרסומים כפולים של נתיבים – חלקם מסשנים של BGP שמשתתפים בהעברת נתונים וחלקם מסשנים שלא משתתפים בהעברת נתונים – יכול להיות שתנועת העברת הנתונים תשתמש ב-ECMP כדי להפיץ את התנועה לכל ה-next hops הזמינים, גם אם ה-next hops האלה לא משתתפים באופן מפורש בהעברת הנתונים.

חיבור Interconnect למיקום שלא נתמך (רשת שאינהGoogle Cloud )

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

פתרון בעיות בקישוריות לרשת באמצעות בדיקות קישוריות

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

כדי לנתח את הגדרות הרשת, הכלי לבדיקת קישוריות מדמה את נתיב ההעברה הצפוי של חבילת נתונים דרך רשת הענן הווירטואלי הפרטי (VPC), מנהרות Cloud VPN, קובצי מצורף של VLAN או

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

לכלי לבדיקת קישוריות אין גישה להגדרות של הרשת המקומית, ולכן הוא לא יכול לאמת את ההגדרות של המסלולים ושל כללי חומת האש בנתב המקומי. לכן, תעבורה מהרשת המקומית לרשת ה-VPC תמיד נחשבת לתעבורה תקינה בניתוח ההגדרות של בדיקות הקישוריות, ורק ההגדרות בתוך Google Cloud נבדקות.

כדי להריץ בדיקות קישוריות בין שתי רשתות מקומיות שמחוברות דרך NCC, אפשר לעיין במאמר בדיקה מרשת שאינהGoogle Cloud לרשת שאינהGoogle Cloud .

מידע נוסף זמין במאמר סקירה כללית על בדיקות קישוריות.

פתרון בעיות ב-spokes היברידיים

הבעיה הבאה יכולה להתרחש בנתב וירטואלי, בצירוף ל-VLAN וב-VPN spokes.

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

אם רשתות המשנה של ה-hub שהוגדרו לא מפורסמות ברשת המקומית, כדאי לבדוק את טבלת הניתוב של ה-hub של קבוצת ה-spoke ההיברידית כדי לזהות את הבעיות הבאות:

  • אם רשתות המשנה מוצגות בטבלת הניתוב של הרכזת, צריך לבצע את הפעולות הבאות:

  • אם רשתות המשנה לא מופיעות בטבלת הניתוב של הרכזת, צריך לבצע את הפעולות הבאות:

    • בודקים את טווחי כתובות ה-IP של include-export ו-exclude-export ב-VPC spoke של רשתות המשנה. אם תת-הרשת מסוננת לפי טווחים לייצוא או טווחים להחרגה מייצוא, אפשר לעדכן את רשת ה-VPC המשנית.

פתרון בעיות בנתב וירטואלי

הבעיות והפתרונות הבאים רלוונטיים רק לנתב וירטואלי.

המסמכים לפתרון בעיות ב-Cloud Router רלוונטיים גם לנתב וירטואלי, בנוסף לבעיות שמפורטות בקטעים הבאים.

למידע נוסף, קראו את המאמרים הבאים:

סשנים של BGP נכשלים

אם לא ניתן ליצור סשנים של BGP בין Cloud Router לבין נתב וירטואלי, כדאי לבדוק את הבעיות הבאות:

  • מוודאים שמכונה וירטואלית שפועלת כמכשיר נתב מוגדרת כחלק מרשת משנית ב-Network Connectivity Center. כדי להגדיר מכשיר נתב וירטואלי כחלק מ-spoke, אפשר לעיין במאמר בנושא עבודה עם spokes.
  • בודקים את ההגדרות של חומת האש כדי לוודא שהיציאה TCP 179 מותרת. כדי להגדיר את הגדרות חומת האש עבור נתב וירטואלי, אפשר לעיין במאמר בנושא יצירת מופעים של נתב וירטואלי.
  • מוודאים שאף אחד מהם – Cloud Router או מופע של מכשיר נתב – לא משתמש בכתובות מקומיות (כלומר, 169.254.x.x) כדי ליצור קשר אחד עם השני. הוראות מפורטות מופיעות במאמר בנושא כתובות IP ומופעים של מכשירי נתב.
  • מוודאים ש-Cloud Router יצר שתי סשנים נפרדים של BGP למופע של מכשיר הנתב, אחד מכל ממשק של Cloud Router. מופע של מכשיר נתב צריך לפרסם את אותם מסלולים בשני סשנים של BGP. אם אחת מסשנים של BGP מושבתת והמכונה הווירטואלית של נתב האפליקציה מאבדת את התקשורת עם Cloud Router, צריך לבדוק את ההגדרה של הממשקים של Cloud Router. מידע נוסף זמין במאמר בנושא יצירת מופעים של מכשירי נתב.

בעיות בכתובות IP פנימיות בסשנים של BGP במכשירי נתב

אם אתם מגלים בעיות שקשורות להגדרת כתובת ה-IP שלכם עבור מופעי מכשיר נתב, ודאו שהגדרתם כתובות IP פנימיות של RFC 1918 עבור סשנים של BGP בין Cloud Router לבין מכונות וירטואליות שפועלות כמופעי מכשיר נתב.

מכונות וירטואליות של נתבים לא משתמשות בכתובות 169.254.x.x עבור סשנים של BGP. במקום זאת, הם צריכים להשתמש בכתובות IP באותה רשת משנה של VPC כמו Cloud Router. מידע נוסף זמין במאמר בנושא יצירת מופעים של מכשירי נתב.

פתרון בעיות ב-VPC spokes

הרשאות

אם נדחתה בקשת הרשאה כשניסיתם ליצור רשת מסוג Spoke בפרויקט אחר מזה של רשת ה-Hub, צריך לפנות לאדמין של רשת ה-Hub כדי לוודא שקיבלתם את networkconnectivity.groups.useההרשאה הנדרשת ברשת ה-Hub.

כשלים ביצירת רשת spoke של VPC

אם יצירת ה-VPC spoke נכשלה, יכול להיות שהסיבה לכך היא אחת מהסיבות הבאות:

  • רשת ה-VPC כבר מקושרת לאחד או יותר מה-spokes הקיימים באמצעות קישור (peering) בין רשתות VPC שכנות.
  • יש חפיפה בין תת-רשתות לבין רשתות מסוג Hub-and-Spoke קיימות של VPC.
  • יש חפיפה בין תת-רשתות לבין רשתות שכנות של רשתות VPC קיימות מסוג Hub and Spoke.
  • חרגתם מהמכסה של רשתות VPC מסוג Hub and Spoke.
  • חרגתם מהמכסה של מסלולים לכל טבלת מסלולים של רכזת.
  • צוינו יותר מ-16 מסנני ייצוא.
  • תת-הרשתות ברשת ה-VPC גדולות יותר מאחד או יותר מהמסננים שצוינו.

מידע על שגיאות שקשורות למכסות זמין במאמר מכסות ומגבלות.

כשלים ביצירת רשת spoke ב-VPC אחרי מחיקה של רשת spoke

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

כשלים ביצירת רשת משנה ברשת VPC מסוג Spoke

אם נתקלתם בכשל ביצירת רשת משנה ברשת VPC מסוג spoke, יכול להיות שהסיבה לכך היא אחת מהסיבות הבאות:

  • יש חפיפה בין תת-רשתות ב-VPC spokes אחרים או ב-VPC peers של VPC spokes.
  • חרגתם מהמכסה של מסלולים לכל טבלת מסלולים של רכזת.
  • תת-הרשתות ברשת ה-VPC גדולות יותר מאחד או יותר מהמסננים שצוינו.

ה-VPC spoke נוצר אבל חסרה קישוריות של מישור הנתונים

אם ה-VPC spoke מופיע כנוצר, אבל חסרה קישוריות של dataplane, יכול להיות שהסיבה לכך היא אחת מהסיבות הבאות:

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

חלק מרשתות המשנה ב-VPC spokes לא מוצגות בטבלת הניתוב של ה-hub

אם בטבלת המסלולים של ה-hub לא מוצגות חלק מרשתות המשנה ב-VPC spokes, יכולות להיות לכך כמה סיבות:

  • רשתות המשנה מסוננות באמצעות מסנני ייצוא.
  • רשתות המשנה נוצרו ב-5 עד 10 הדקות האחרונות, וטבלת הניתוב של הרכזת עדיין לא רעננה.

עדכון ה-VPC spoke נכשל

חשוב לוודא שהעדכונים של הרשת המקומית עומדים בכל המכסות והמגבלות של NCC, אחרת העדכון ייכשל.

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

פתרון בעיות בהפצת חיבורים של Private Service Connect

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

מכונה וירטואלית באחד מהחיבורים לא יכולה לגשת לחיבור Private Service Connect בחיבור אחר

אם מכונה וירטואלית (VM) באחד מחיבורי ה-spoke של VPC לא יכולה לגשת לנקודת הקצה של Private Service Connect בחיבור spoke אחר, צריך לוודא שהתנאים הבאים מתקיימים:

  • השדה --export_psc מופעל במרכז.

    כדי לבדוק אם השדה --export_psc מופעל ב-Hub, משתמשים בפקודה gcloud network-connectivity hubs describe.

    gcloud 

    gcloud network-connectivity hubs describe HUB_NAME \
    --project=PROJECT_ID \
    --format='get(export_psc)'

    מחליפים את הערכים הבאים:

    • ‫HUB_NAME: השם של ה-Hub
    • ‫PROJECT_ID: מזהה הפרויקט שבו נמצא ה-hub

  • כתובת ה-IP של נקודת הקצה של Private Service Connect לא נמצאת בטווח מוחרג של ייצוא של רכזת האירוח. נקודות קצה מסוג Private Service Connect שנמצאות בטווח ההחרגה של הייצוא לא מועברות.

    כדי לבדוק את טווחי הייצוא הספציפיים שמוחרגים ב-Spoke, משתמשים בפקודה gcloud network-connectivity spokes describe.

    gcloud 

    gcloud network-connectivity spokes describe SPOKE_NAME \
    --global \
    --project=PROJECT_ID \
    --format='get(linked_vpc_network.exclude_export_ranges)'

    מחליפים את הערכים הבאים:

    • ‫SPOKE_NAME: השם של הרשת המסתעפת
    • ‫PROJECT_ID: מזהה הפרויקט שבו נמצאת הרשת המסועפת

  • לא חרגתם מהמכסה של השימוש ב-NCC.

  • נקודת הקצה psc_connection_status נמצאת במצב ACCEPTED. מידע על סטטוסים של חיבורים זמין במאמר סטטוסים של חיבורים.

  • סטטוס החיבור שהועבר של נקודת הקצה ב-spoke שמכיל את מכונת ה-VM הוא READY. אם לא מוצג סטטוס, כדאי לעיין בסיבות שמפורטות בקטע לא רואים את הסטטוס של חלק מהיעדים בדף הזה. אפשר לבדוק את סטטוס החיבור שהועבר באמצעות הפקודה gcloud network-connectivity hubs query-status:

    gcloud 

    gcloud network-connectivity hubs query-status HUB_NAME\
    --filter='psc_propagation_status.source_spoke="SOURCE_SPOKE_NAME" AND psc_propagation_status.target_spoke="TARGET_SPOKE_NAME" AND psc_propagation_status.source_forwarding_rule="ENDPOINT_NAME"

    מחליפים את הערכים הבאים:

    • ‫HUB_NAME: השם של ה-hub שרוצים לבדוק את סטטוס ההפצה של החיבור שלו
    • ‫SOURCE_SPOKE_NAME: השם של ה-spoke של המקור
    • ‫TARGET_SPOKE_NAME: השם של ה-spoke של היעד
    • ‫ENDPOINT_NAME: השם של נקודת הקצה

    מידע מפורט על השימוש בדגלים האלה זמין בדף הפקודה gcloud network-connectivity hubs query-status.

  • רשת ה-VPC המארחת של נקודת הקצה של Private Service Connect (המקור) היא רשת מסוג spoke ב-VPC מרכזי.

  • כתובת ה-IP של נקודת הקצה של Private Service Connect היא כתובת RFC 1918.

הגעתם למכסת ההעלאות של היוצר

אם מוצגת הודעת השגיאה PRODUCER_QUOTA_EXHAUSTED, אפשר לבקש מהבעלים של שירות מנוהל להגיש בקשה להגדלת המכסה PSC_ILB_CONSUMER_FORWARDING_RULES_PER_PRODUCER_NETWORK. פרטים נוספים זמינים בקטע לכל רשת במסמכי התיעוד של VPC.

חרגת ממגבלת החיבורים שהועברו מהספק

אם מופיעה שגיאה לגבי חריגה ממגבלת החיבורים שהועברה של קובץ מצורף לשירות, אפשר לבקש מבעלים של שירות מנוהל להגדיל את המגבלה. כשבעלים של שירות מנוהל מעדכנים את מגבלת החיבורים שהועברה,המערכת בודקת אוטומטית אם אפשר ליצור חיבורים שהועברו וממתינים. Google Cloud

הגעתם למכסת כתובות ה-IP של NAT של היצרן

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

הגעתם למכסת הצרכנים

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

לא רואים את הסטטוס של חלק מה-spokes של היעד

אם לא מופיע הסטטוס של חלק מהמרכזים המשניים, יכול להיות שזה בגלל אחת מהסיבות הבאות:

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

  • ב-NCC מוצג רק סטטוס ההפצה של כל רשת וירטואלית פרטית (VPC) מסוג spoke. אם רשת VPC היא גם רשת מסוג spoke וגם מכילה רשתות מסוג spoke היברידיות, צריך לבדוק את סטטוס ההפצה של רשת ה-VPC מסוג spoke כדי לקבוע אם לרשתות מסוג spoke היברידיות שכלולות בה יש קישוריות לנקודות קצה של Private Service Connect שהופצו.

  • אם רשת VPC היא גם רשת VPC של ספק שירות פרטי וגם רשת VPC מסוג spoke במרכז שמפיץ את נקודות הקצה שלו, NCC לא מפיץ את נקודות הקצה שלו בחזרה לרשת ה-VPC של הספק עצמה.

  • ההפצה אסורה בגלל הטופולוגיה של הרכזת. לדוגמה, אם הרכזת מוגדרת לשימוש בטופולוגיית כוכב, התנאים הבאים מתקיימים גם הם:

    • נקודות קצה של Private Service Connect בקבוצה המרכזית מועברות לכל רשתות ה-VPC האחרות.
    • נקודות קצה מסוג Private Service Connect בקבוצת הקצה מועברות רק ל-VPC spokes בקבוצה המרכזית.

פתרון בעיות בהחלפת נתיבים בין רשתות spoke ב-VPC

רשתות מסוג spoke ורשתות היברידיות מסוג spoke מחוברות לאותו רכזת, אבל חסרה קישוריות של מישור הנתונים

אם רשתות ה-spoke של VPC ורשתות ה-spoke ההיברידיות מחוברות לאותו hub, אבל חסרה קישוריות של מישור הנתונים, יכול להיות שהסיבה לכך היא אחת מהסיבות הבאות:

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

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

יכול להיות שרשתות דינמיות לא יוצגו בצורה נכונה בטבלת הניתוב של הרכזת בגלל אחת מהסיבות הבאות:

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

יצירת spoke היברידי נכשלת

אם יצירת spoke היברידי נכשלת, יכולות להיות לכך כמה סיבות:

  • רשת ה-VPC של הניתוב יכולה להיות רשת מסוג spoke קיימת שמקושרת לאותו רכז או לרכז אחר.
  • יכול להיות שרשת ה-VPC לניתוב משויכת באופן מרומז למרכז אחר, בגלל spoke היברידי קיים שמחובר למרכז הזה. חיבורים היברידיים מרשת VPC יכולים להפוך ל-spokes של רכזת אחת בלבד.

יצירת רשת spoke ב-VPC נכשלת

יצירת רשת spoke של VPC עלולה להיכשל אם רשת ה-VPC spoke משויכת באופן מרומז לרשת hub כרשת VPC לניתוב.

הודעת השגיאה

אם אתם מנסים ליצור רכזת ומקבלים הודעת שגיאה עם הכיתוב An internal error occurred, כדי לפתור את הבעיה, פנו אל Google Cloud התמיכה.

פתרון בעיות ב-spokes של NCC Gateway

כדי לראות את השירותים והנתבים שמחוברים ל-NCC Gateway, משתמשים בפקודה gcloud network-connectivity spokes describe במשאב spoke של NCC Gateway.

gcloud 

  gcloud network-connectivity spokes describe SPOKE_NAME \
      --region REGION

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

  • ‫SPOKE_NAME: השם של רכזת NCC Gateway
  • ‫REGION: האזור שבו נמצאת הרשת המשנית

הפלט אמור להיראות כך:

createTime: '2022-11-25T06:06:11.572019860Z'
hub: projects/PROJECT/locations/REGION/hubs/HUB
gateway:
  ipRangeReservation: 10.1.2.0/24
  asn: 65123
  routers:
    projects/PROJECT/locations/REGION/routers/ROUTER

name: projects/PROJECT/locations/REGION/spokes/SPOKE
state: ACTIVE
uniqueId: 8ca10af0-ee69-43c2-b0b4-61e8f53d410b
updateTime: '2023-12-27T21:26:47.786506888Z'

אפשר להציג את טבלת הניתוב של ה-VPC של האפליקציה ואת המסלול שנוצר בטבלת הניתוב של ה-hub שמופץ לטבלת הניתוב של ה-VPC עם next hop בתור hub באמצעות הפקודה gcloud compute routes list:

gcloud 

  gcloud compute routes list \
      --filter="network=NETWORK"

מחליפים את NETWORK בשם של רשת ה-VPC.

הפלט אמור להיראות כך:

NAME                                                  NETWORK  DEST_RANGE    NEXT_HOP  PRIORITY
ncc-static-route-7296f3a4-cdc2-4560-a905-95cdb1d6833e  vpc-1    17.0.0.0/8   hub       0

אפשר להציג את טבלת הניתוב של הרכזת עבור קבוצת ה-spoke ולראות את אותו מסלול שנוצר שמצביע על ה-spoke של שער ה-NCC באמצעות הפקודה gcloud network-connectivity hubs route-tables routes list:

gcloud 

  gcloud network-connectivity hubs route-tables routes list --hub=HUB_NAME \
      --route_table

מחליפים את HUB_NAME בשם של ה-Hub.

בטבלת המסלולים של ה-hub לא מוצגים מסלולים שפורסמו על ידי שער

אם בטבלת הניתוב של הרכזת לא מוצגים חלק מהנתיבים שפורסמו בשער עם שער ה-Spoke כנקודת הקפיצה הבאה, יכול להיות שהסיבה לכך היא שנתיבים לא הותקנו במישור הנתונים. הדבר עלול לגרום לבעיות קישוריות בין רשתות spoke של VPC לבין אפליקציות מקומיות שמחוברות דרך רשת spoke של שער NCC. כדאי לנסות למחוק וליצור מסלולים שפורסמו בשער לפי השלבים הבאים:

  1. מחיקת המסלול שפורסם
  2. יצירת מסלול שפורסם ב-NCC Gateway

  3. כדי לראות את המסלול שפורסם שמשויך ל-NCC Gateway, משתמשים בפקודה gcloud beta network-connectivity spokes gateways advertised-routes list:

    gcloud 

    gcloud beta network-connectivity spokes gateways advertised-routes list
    --region=REGION

    מחליפים את REGION באזור שבו נמצאת הרשת המקומית.

  4. כדי לוודא שהנתיב שפורסם בשער מופיע בטבלת הנתיבים של הרכזת, משתמשים בפקודה gcloud network-connectivity hubs route-tables list:

    gcloud 

    gcloud network-connectivity hubs route-tables list \
    --hub=HUB_NAME

    מחליפים את HUB_NAME בשם של ה-hub שרוצים להציג את טבלת הניתוב שלו.

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

    gcloud  network-connectivity hubs route-tables routes list --hub=HUB_NAME --route_table PROD
IP_CIDR_RANGE  STATE    TYPE      NEXT_HOP   HUB       ROUTE_TABLE     PRIORITY
10.0.0.0/8     ACTIVE   NCC_GW    NCC-GW-1   HUB_NAME  PROD            100

לבעיות ב-Cloud Router, אפשר לעיין במאמר בנושא פתרון בעיות בהודעות יומן של Cloud Router.

לפתרון בעיות ב-Cloud Interconnect, אפשר לעיין בדף פתרון בעיות ב-Cloud Interconnect.