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

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

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

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

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

צירוף משאבים לרשתות מסוג Spoke

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אם מכונה וירטואלית באחד מחיבורי ה-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 לא נמצאת בטווח מוחרג של ייצוא ב-spoke של האירוח. נקודות קצה מסוג 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 שמכיל את המכונה הווירטואלית הוא 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.

חרגתם ממכסת כללי ההעברה של Private Service Connect

אם מוצגת הודעת שגיאה Quota limit PerProjectPerHubPscIlbConsumerForwardingRules has been exceeded יכול להיות שלא תוכלו לבצע את הפעולות הבאות:

  • יוצרים רשתות spoke של VPC או מפעילים את הדגל --export_psc ברשת ה-hub.
  • יוצרים כלל העברה של Private Service Connect ברשת VPC שהיא רשת מסוג spoke ב-VPC.

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

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

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

אי אפשר לראות את הסטטוס של חלק מהמרכזים של היעד

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יצירת רשת 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
  sacAttachment:
    projects/PROJECT/locations/REGION/sacAttachment/SAC-ATTACHMENT
name: projects/PROJECT/locations/REGION/spoke/SPOKE
state: ACTIVE
uniqueId: 8ca10af0-ee69-43c2-b0b4-61e8f53d410b
updateTime: '2023-12-27T21:26:47.786506888Z'

אפשר להציג את טבלת הניתוב של ה-VPC של האפליקציה ואת המסלול שנוצר בטבלת הניתוב של ה-Hub שמופץ לטבלת הניתוב של ה-VPC עם ה-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=ROUTE_TABLE

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

  • ‫HUB_NAME: השם של ה-hub
  • ‫ROUTE_TABLE: המזהה של טבלת הניתוב שרוצים להציג את המסלולים שלה

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

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

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

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

    gcloud 

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

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

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

    gcloud 

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

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

    • ‫HUB_NAME בשם של ה-hub שרוצים להציג את טבלת הניתוב שלו.
    • ‫ROUTE_TABLE: המזהה של טבלת הניתוב שרוצים להציג את המסלולים שלה

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

    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

נתיבים חסרים שפורסמו בשער

אם התנועה מגיעה לנקודות קצה (endpoints) ברשתות VPC מסוג Hub and Spoke, אבל התנועה שאמורה להגיע לשער לא מגיעה לשותף או לאפליקציות לנייד, צריך לבצע את הפעולות הבאות:

  1. מאשרים אילו מסלולים שפורסמו על ידי השער מוגדרים בשער.
  2. בודקים את טבלת הניתוב של קבוצת ה-spoke של המקור כדי לוודא שיש נתיב שישלח תנועה אל השער.
  3. אם לא רואים נתיב ששולח תנועה לשער, צריך ליצור נתיבים שמועברים לשער.

חסרים פרסומים של מסלולים מותאמים אישית ב-Cloud Router של השער

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

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

חסרים פרסומים של מסלולים מותאמים אישית ב-spokes היברידיים

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

  1. בודקים את המסלולים שהתקבלו בנתב.

  2. מוסיפים פרסום של מסלול בהתאמה אישית ב-Cloud Router בצדGoogle Cloud של ה-spoke ההיברידי. פרטים על הגדרת פרסום של מסלולים בהתאמה אישית זמינים במאמר יצירת Cloud Router.

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

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

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