- בית
- /
- מאמר
חיבור וירטואלי של מופע ייעודי
'התחברות וירטואלית' היא אפשרות תוסף נוספת עבור קישוריות ענן למופע ייעודי של Webex Calling. התחברות וירטואלית מאפשרת ללקוחות להרחיב בצורה מאובטחת את הרשת הפרטית שלהם דרך האינטרנט באמצעות מנהרות IP VPN מנקודה לנקודה. כאן אנו דנים בהזמנה, הפעלה ותצורה עבור 'התחברות וירטואלית'.
מבוא
'התחברות וירטואלית' היא אפשרות תוסף נוספת עבור קישוריות ענן למופע ייעודי עבור Webex Calling (מופע ייעודי). התחברות וירטואלית מאפשרת ללקוחות להרחיב בצורה מאובטחת את הרשת הפרטית שלהם דרך האינטרנט באמצעות מנהרות IP VPN מנקודה לנקודה. אפשרות הקישוריות הזו מספקת הגדרה מהירה של חיבור רשת פרטית באמצעות ציוד מקומי של הלקוח (CPE) וקישוריות האינטרנט הקיימים.
Cisco מארחת, מנהלת ומבטיחה מנהרות IP VPN יתירות וגישה לאינטרנט הנדרשת באזורי מרכזי הנתונים של המופע הייעודי של Cisco שבהם נדרש השירות. באופן דומה, מנהל המערכת אחראי על שירותי ה-CPE והאינטרנט המתאימים הנדרשים להקמת Virtual Connect.
כל הזמנה של התחברות וירטואלית באזור של מופע ייעודי מסוים תכלול שתי מנהרות encapsulation ניתוב גנריות (GRE) המוגדרות על ידי הצפנת IPSec (GRE מעל IPSec), אחת למרכז הנתונים של כל Cisco באזור שנבחר.
ל'התחברות וירטואלית' מגבלת רוחב פס של 250 Mbps לכל מנהרה ומומלץ לפריסות קטנות יותר. מאז שתי מנהרות VPN מנקודה לנקודה משמשים כל התעבורה לענן צריכה לעבור דרך CPE ראש הלקוח, ולכן זה לא יכול להיות מתאים איפה יש הרבה אתרים מרוחקים. לקבלת אפשרויות חלופיות אחרות, עיין בקישוריות ענן.
לפני שתשלח את בקשת העמיתים עבור 'התחברות וירטואלית', ודא ששירות המופע הייעודי מופעל באזור המתאים זה.
דרישות מקדימות
התנאים המוקדמים ליצירת 'התחברות וירטואלית' כוללים:
-
הלקוח מספק
-
חיבור לאינטרנט עם רוחב פס זמין מספיק לתמיכה בפריסה
-
כתובות IP ציבוריות עבור שתי מנהרות IPSec
-
כתובות IP של תעבורת GRE בצד הלקוח עבור שתי מנהרות GRE
-
-
שותף ולקוח
-
עבוד יחד כדי להעריך את דרישות רוחב הפס
-
ודא שמכשירי רשת תומכים בניתוב פרוטוקול שער הגבול (BGP) ו-GRE באמצעות עיצוב מנהרת IPSec
-
-
שותף או לקוח מספק
-
צוות רשת עם ידע על טכנולוגיות מנהרת VPN מאתר לאתר
-
צוות רשת עם ידע של BGP, eBGP ועקרונות ניתוב כלליים
-
-
Cisco
-
מספרי מערכת אוטונומיים פרטיים (ASN) וכתובת IP ארעית עבור ממשקי מנהרת GRE
-
Cisco הוקצתה לרשת ציבורית, אך לא ניתן לניתוב באינטרנט מסוג Class C (/24) עבור כתובת ענן מופע ייעודי
-
אם ללקוח יש מכשיר CPE אחד בלבד, שתי המנהרות לכיוון מרכזי הנתונים של CISCO (DC1 ו-DC2) בכל אזור, יהיו ממכשיר CPE זה. ללקוח יש גם אפשרות עבור 2 מכשירי CPE, ולאחר מכן כל מכשיר CPE צריך להתחבר למנהרה אחת רק לכיוון מרכזי הנתונים של Cisco (DC1 ו-DC2) בכל אזור. ניתן להשיג יתירות נוספת על ידי סיום כל מנהרה באתר/מיקום פיזי נפרד בתשתית הלקוח.
פרטים טכניים
מודל פריסה
Virtual Connect משתמש בארכיטקטורת כותרת כפולה, שבה מטוסי הניתוב ו-GRE מסופקים על-ידי מכשיר אחד ומישור הבקרה של IPSec מסופק על-ידי אחר.
עם השלמת הקישוריות של התחברות וירטואלית , ייווצרו שתי מנהרות GRE מעל IPSec בין הרשת הארגונית של הלקוח לבין מרכזי הנתונים של Cisco של המופע הייעודי. אחד לכל מרכז נתונים יתיר באזור המתאים. רכיבי רשת נוספים הנדרשים לעמית מוחלפים על-ידי השותף או הלקוח ל-Cisco דרך טופס ההפעלה של Control Hub Virtual Connect.
האיור שלהלן מציג את הדוגמה של מודל פריסת החיבור הווירטואלי עבור אפשרות 2-ריכוז בצד הלקוח.

Virtual Connect - VPN הוא עיצוב רכזת, שבו אתרי רכזת הלקוח מחוברים ל-DC1 ול-DC2 של מרכזי הנתונים של המופע הייעודי באזור מסוים.
שני אתרי Hub מומלצים ליתירות טובה יותר, אבל אתר One Hub עם שתי מנהרות הוא גם מודל פריסה נתמך.
רוחב הפס למנהרה מוגבל ל-250 Mbps.
האתרים המרוחקים של הלקוח באותו אזור, יצטרכו להתחבר בחזרה לאתרי ה-Hub דרך ה-WAN של הלקוח, ואין זו האחריות של Cisco לקישוריות הזו.
שותפים צפויים לעבוד בשיתוף פעולה הדוק עם הלקוחות, ויבטיח שהנתיב האופטימלי ביותר ייבחר עבור אזור השירות התחברות וירטואלית .
האיור הבא מציג את אזורי הקישוריות בענן של המופע הייעודי.

ניתוב
ניתוב עבור תוסף 'התחברות וירטואלית' מיושם באמצעות BGP חיצוני (eBGP) בין המופע הייעודי והציוד המקומי של הלקוח (CPE). Cisco תפרסם את הרשת המתאימה שלה עבור כל DC יתירות באזור ל-CPE של הלקוח וה-CPE יידרש לפרסם נתיב ברירת מחדל אל Cisco.
-
Cisco שומרת ומקצה
-
כתובת IP של ממשק מנהרה (קישור זמני לניתוב) Cisco מקצה ממרחב כתובת משותפת ייעודי (לא ניתן לניתוב ציבורי)
-
כתובת התייבשות של תעבורת מנהרה (הצד של Cisco)
-
מספרי מערכת אוטונומיים פרטיים (ASN) עבור תצורת ניתוב BGP של לקוח
-
Cisco מקצה טווח השימוש הפרטי הייעודי: 64512 עד 65534
-
-
-
eBGP המשמש להחלפת נתיבים בין המופע הייעודי ל-CPE
-
Cisco תפצל את רשת /24 שהוקצתה ל-2/25 לכל DC באזור המתאים.
-
ב-Virtual Connect כל רשת /25 מפרסמת בחזרה ל-CPE על-ידי Cisco באמצעות מנהרות VPN מנקודה לנקודה (קישור חולף) בהתאמה
-
יש להגדיר CPE עם שכני eBGP המתאימים. אם משתמשים ב-CPE אחד, ייעשה שימוש בשני שכנים eBGP, אחד המצביע על כל מנהרה מרוחקת. אם משתמשים בשני CPE, לכל CPE יהיה שכן eBGP אחד הפונה למנהרה המרוחקת היחידה עבור ה- CPE.
-
הצד של Cisco בכל מנהרת GRE (IP של ממשק מנהרה) מוגדר כשכן BGP ב-CPE
-
CPE נדרש לפרסם נתיב ברירת מחדל מעל כל אחת מהמנהרות
-
CPE ניתן להגיב להפצה מחדש, כנדרש, של המסלולים הנלמדים בתוך הרשת הארגונית של cutomer.
-
-
תחת מצב כשל של קישור שאינו כשל, ל-CPE יחיד יהיו שתי מנהרות פעילות/פעילות. עבור שני צמתים CPE, לכל CPE תהיה מנהרה פעילה אחת ושני צמתים CPE צריכים להיות פעילים ותעבורה חולפת. תחת תרחיש אי-כשל, התנועה חייבת להתפצל לשתי מנהרות העוברות ליעדים הנכונים /25, אם אחת המנהרה יורדת, המנהרה הנותרת יכולה לשאת את התנועה לשניהם. בתרחיש כשל כזה, כאשר רשת ה-/25 מושבתת, רשת ה-/24 משמשת כנתיב גיבוי. Cisco תשלח תעבורת לקוח דרך ה-WAN הפנימי שלה לכיוון DC שאיבדה את הקישוריות.
תהליך קישוריות
1 | |
2 | |
3 | |
4 |
שלב 1: הזמנת CCW
'התחברות וירטואלית' היא תוסף עבור מופע ייעודי ב-CCW.
1 |
נווט לאתר ההזמנה של CCW ולאחר מכן לחץ על 'התחבר' כדי להיכנס לאתר: |
2 |
צור הערכה. |
3 |
הוסף sku "A-FLEX-3". |
4 |
בחר אפשרויות עריכה. |
5 |
בלשונית המינוי שמופיעה, בחר אפשרויות ותוספים. |
6 |
תחת 'תוספים נוספים', בחר בתיבת הסימון לצד 'התחברות וירטואלית למופע ייעודי'. השם SKU הוא "A-FLEX-DI-VC". |
7 |
הזן את הכמות והמספר של האזורים שבהם נדרשת 'התחברות וירטואלית'. הכמות של 'התחברות וירטואלית' לא יכולה לחרוג מהמספר הכולל של האזורים שנרכשו עבור מופע ייעודי. כמו כן, רק הזמנת התחברות וירטואלית אחת מורשית לכל אזור. |
8 |
כאשר אתה מרוצה מהבחירות שלך, לחץ על 'אמת' ושמור בחלק הימני העליון של הדף. |
9 |
לחץ על שמור והמשך כדי לסיים את ההזמנה. ההזמנה המוגמרת שלך תופסת כעת ברשת ההזמנה. |
שלב 2: הפעלת התחברות וירטואלית ב-Control Hub
1 |
היכנס ל-Control Hub https://admin.webex.com/login. |
2 |
במקטע שירותים , נווט אל שיחות > Instacnce ייעודי > קישוריות בענן. |
3 |
בכרטיס 'התחברות וירטואלית', הכמות של 'התחברות וירטואלית' שנרכשה מופיעה. מנהל המערכת יכול כעת ללחוץ על הפעל כדי להפעיל את הפעלת החיבור הווירטואלי. ![]() תהליך ההפעלה יכול להיות מופעל רק על-ידי מנהלי מערכת בעלי תפקיד "מנהל מערכת מלא של לקוח". בעוד שמנהל מערכת עם תפקיד "מנהל מערכת לקריאה בלבד של לקוח" יכול להציג רק את המצב. |
4 |
בעת לחיצה על לחצן הפעל , טופס הפעל התחברות וירטואלית מוצג כדי שמנהל המערכת יספק את הפרטים הטכניים של ההתחברות הווירטואלית הנדרשים לתצורות העמיתים בצד של Cisco. הטופס מספק גם מידע סטטי בצד של Cisco, בהתבסס על האזור שנבחר. מידע זה יהיה שימושי למנהלי מערכת של לקוח כדי להגדיר את ה-CPE לצדם כדי ליצור את הקישוריות. |
5 |
לחץ על לחצן הפעל לאחר שכל השדות הנדרשים מתמלאים. |
6 |
לאחר השלמת טופס הפעלת התחברות וירטואלית עבור אזור חלקי, הלקוח יכול לייצא את טופס ההפעלה מ-Control Hub, 'התקשרות' > 'מופע ייעודי' > 'קישוריות ענן' ולחץ על 'ייצוא' הגדרות. ![]() מטעמי אבטחה, האימות וסיסמת ה-BGP לא יהיו זמינים במסמך הייצוא, אך מנהל המערכת יכול להציג את אותן האפשרויות ב-Control Hub על-ידי לחיצה על הצג הגדרות תחת Control Hub, תחת הלשונית 'שיחות' > 'מופע ייעודי' > 'קישוריות ענן'. |
שלב 3: Cisco מבצעת תצורת רשת
1 |
לאחר השלמת טופס הפעלת ההתחברות הווירטואלית, המצב יעודכן להפעלה מתבצעת בשיחות > מופע ייעודי > כרטיס התחברות וירטואלית לקישוריות בענן. |
2 |
Cisco תשלים את התצורות הנדרשות בציוד הצד של Cisco תוך 5 ימי עסקים. עם השלמה מוצלחת, המצב יעודכן ל'מופעל' עבור אזור מסוים זה ב-Control Hub. |
שלב 4: לקוח מבצע תצורת רשת
המצב השתנה ל'מופעל' כדי להודיע למנהל המערכת של הלקוח שצד התצורות של Cisco עבור קישוריות IP VPN הושלם בהצלחה בהתבסס על הקלט שסופק על-ידי הלקוח. אבל, מנהל המערכת של הלקוח צפוי להשלים את הצד שלו בתצורות ב-CPE ולבדוק את נתיבי הקישוריות עבור מנהרת החיבור הווירטואלי תהיה מקוונת. במקרה של בעיות כלשהן שנתקלו בזמן קביעת התצורה או הקישוריות, הלקוח יכול לפנות ל-Cisco TAC לקבלת סיוע. |
פתרון בעיות
פתרון בעיות ואימות שלב ראשון של IPsec (משא ומתן של IKEv2)
המשא ומתן על מנהרת IPsec כולל שני שלבים, שלב IKEv2 ושלב IPsec. אם המשא ומתן על שלב IKEv2 לא הושלם, לא יהיה אתחול של שלב IPsec שני. ראשית, הוצא את הפקודה "הצג הצפנה ikev2 sa" (בציוד של Cisco) או פקודה דומה בציוד של צד שלישי כדי לוודא שהפעלת IKEv2 פעילה. אם הפעלת IKEv2 אינה פעילה, הסיבות האפשריות עשויות להיות:
-
תנועה מעניינת אינה מפעילה את מנהרת ה-IPsec.
-
רשימת הגישה למנהרה של IPsec מוגדרת בצורה שגויה.
-
אין קישוריות בין הלקוח לבין ה-IP של נקודת הקצה של מנהרת IPsec של המופע הייעודי.
-
הפרמטרים של הפעלת IKEv2 לא תואמים בין הצד של המופע הייעודי לצד הלקוח.
-
חומת אש חוסמת את מנות ה-UDP של IKEv2.
ראשית, בדוק את יומני הרישום של IPsec עבור כל ההודעות המציגות את התקדמות המשא ומתן על מנהרת IKEv2. יומני הרישום עשויים לציין היכן קיימת בעיה במשא ומתן של IKEv2. חוסר ברישום הודעות עשוי גם להצביע על כך שמפגש IKEv2 לא מופעל.
כמה שגיאות נפוצות במשא ומתן עם IKEv2 הן:
-
ההגדרות של IKEv2 בצד CPE אינן תואמות לצד Cisco, בדוק שוב את ההגדרות שהוזכרו:
-
ודא שגרסת IKE היא גרסה 2.
-
ודא שפרמטרי ההצפנה והאימות תואמים להצפנה הצפויה בצד המופע הייעודי.
כאשר צופן "GCM" נמצא בשימוש, פרוטוקול GCM מטפל באימות ומגדיר את פרמטר האימות ל-NULL.
-
אמת את הגדרת אורך החיים.
-
אמת את קבוצת Diffie Hellman modulus.
-
אמת את הגדרות הפונקציה Pseudo-Random.
-
-
רשימת הגישה עבור מפת ההצפנה אינה מוגדרת ל:
-
אפשר GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255.255" (או פקודה שווה ערך)
רשימת הגישה חייבת להיות ספציפית לפרוטוקול "GRE" ופרוטוקול "IP" לא יפעל.
-
אם הודעות יומן הרישום אינן מציגות פעילות משא ומתן עבור שלב IKEv2, ייתכן שיהיה צורך בלכידת מנות.
ייתכן שצד המופע הייעודי לא יתחיל תמיד את חילופי IKEv2 וייתכן שלפעמים יצפה שצד ה-CPE של הלקוח יהיה היוזם.
בדוק את תצורת הצד של CPE עבור הדרישות המקדימות הבאות עבור הפעלת IKEv2:
-
בדוק רשימת גישה הצפנה של IPsec עבור תעבורת GRE (פרוטוקול 50) מה-IP של תעבורת מנהרת CPE אל ה-IP של תעבורת מנהרת המופע הייעודי.
-
ודא שממשק מנהרת GRE מופעל עבור KEEPALIVES של GRE, אם הציוד אינו תומך ב-keepalives של GRE, אז Cisco תקבל הודעה משום ש-keepalives של GRE יופעלו בצד המופע הייעודי כברירת מחדל.
-
ודא ש-BGP מופעל ומוגדר עם כתובת השכן של כתובת ה-IP של מנהרת המופע הייעודי.
כאשר התצורה נקבעה כראוי, השלבים הבאים מתחילים את מנהרת ה-IPsec ואת המשא ומתן הראשון של IKEv2:
-
keepalives של GRE מממשק מנהרת GRE בצד CPE לממשק מנהרת GRE בצד המופע הייעודי.
-
הפעלת BGP השכן TCP מצד CPE והשכן BGP לצד המופע הייעודי והשכן BGP.
-
איתות מכתובת ה-IP של מנהרת הצד של CPE לכתובת ה-IP של מנהרת הצד של המופע הייעודי.
איתות לא יכול להיות כתובת ה-IP של תעבורת המנהרה ל-IP של תעבורת המנהרה, הוא חייב להיות כתובת IP של מנהרה ל-IP של מנהרה.
אם נדרש מעקב מנה עבור תעבורת IKEv2, הגדר את המסנן עבור UDP ויציאה 500 (כאשר אין מכשיר NAT באמצע נקודות הקצה של IPsec) או יציאה 4500 (כאשר מכשיר NAT מוכנס באמצע נקודות הקצה של IPsec).
ודא שמנות UDP של IKEv2 עם יציאה 500 או 4500 נשלחות ומהן נשלחות ומהן כתובת ה-IP של IPsec.
ייתכן שמרכז הנתונים של המופע הייעודי לא יתחיל תמיד את חבילת ה-IKEv2 הראשונה. הדרישה היא שמכשיר ה-CPE יוכל ליזום את מנת ה-IKEv2 הראשונה לכיוון הצד של המופע הייעודי.
אם חומת האש המקומית מאפשרת זאת, נסה גם לבצע איתות לכתובת ה-IPsec המרוחקת. אם האיתות לא הצליח מכתובת IPsec מקומית למרוחקת, בצע נתיב מעקב כדי לעזור וקבע היכן המנה מושמטת.
ייתכן שחומות אש וציוד אינטרנט מסוימים לא יאפשרו נתיב מעקב.
פתרון בעיות ואימות שלב שני של IPsec (משא ומתן של IPsec)
ודא שהשלב הראשון של IPsec (כלומר, איגוד האבטחה של IKEv2) פעיל לפני פתרון הבעיות של השלב השני של IPsec. בצע "הצג הצפנה ikev2 sa" או פקודה שקולה כדי לאמת את הפעלת IKEv2. בפלט, ודא שמפגש IKEv2 עלה למעלה משניות ספורות ושהוא לא מדלג. זמן הפעילות של המפגש מוצג כמפגש "זמן פעיל" או כשווה ערך בפלט.
לאחר שמפגש IKEv2 מאומת כפעיל ופעיל, בחן את הפעלת ה-IPsec. בדומה להפעלת IKEv2, בצע "הצג הצפנה ipsec sa" או פקודה שקולה כדי לאמת את הפעלת IPsec. הן ההפעלה IKEv2 והן ההפעלה של IPsec חייבות להיות פעילות לפני שמנהרה GRE נוצרת. אם הפעלת IPsec אינה מוצגת כפעילה, בדוק את יומני ה-IPsec עבור הודעות שגיאה או שגיאות משא ומתן.
חלק מהנושאים הנפוצים יותר שעשויים להיתקל במהלך המשא ומתן של IPsec הם:
ההגדרות בצד CPE לא תואמות לצד המופע הייעודי, בדוק שוב את ההגדרות:
-
ודא שפרמטרי ההצפנה והאימות תואמים להגדרות בצד המופע הייעודי.
-
אמת את הגדרות הסודיות של Forward מושלמות וכי הגדרות ההתאמה בצד של המופע הייעודי.
-
אמת את הגדרות החיים.
-
ודא שה-IPsec הוגדר במצב מנהרה.
-
אמת את כתובות ה-IPsec של המקור והיעד.
פתרון בעיות ואימות של ממשק המנהרה
כאשר מפגשי IPsec ו-IKEv2 מאומתים כפעילים ופעילים, מנות ה-keepalive של מנהרת GRE המסוגלות לזרום בין המופע הייעודי לנקודות הקצה של מנהרת CPE. אם ממשק המנהרה אינו מציג מצב, כמה בעיות נפוצות הן:
-
ה-VRF של תעבורת ממשק המנהרה אינו תואם ל-VRF של ממשק ה-LOOPBACK (אם נעשה שימוש בתצורת VRF בממשק המנהרה).
אם תצורת ה-VRF אינה בשימוש בממשק המנהרה, ניתן להתעלם מהסימון הזה.
-
Keepalives אינם מופעלים בממשק המנהרה הצדדי CPE
אם keepalives אינם נתמכים בציוד CPE, יש להודיע ל-Cisco כך ש-keepalies המוגדרים כברירת מחדל בצד המופע הייעודי יושבתו גם כן.
אם יש תמיכה ב-keepalives, ודא שה-keepalives מופעל.
-
המסכה או כתובת ה-IP של ממשק המנהרה אינן נכונות ואינן תואמות לערכים הצפויים של המופע הייעודי.
-
כתובת תעבורת מנהרת המקור או היעד שגויה ואינה תואמת לערכים הצפויים של המופע הייעודי.
-
חומת אש חוסמת מנות GRE שנשלחות למנהרת IPsec או מתקבלות ממנהרת ה-IPsec (מנהרת ה-GRE מועברת דרך מנהרת ה-IPsec)
בדיקת איתות צריכה לוודא שממשק המנהרה המקומי פועל והקישוריות טובה לממשק המנהרה המרוחק. בצע את בדיקת האיתות מ-IP של המנהרה (לא ה-IP של תעבורה) ל-IP של המנהרה המרוחקת.
רשימת הגישה להצפנה עבור מנהרת ה-IPsec הנושאת את תעבורת מנהרת ה-GRE מאפשרת לחצות רק מנות GRE. כתוצאה מכך, פינגס לא יפעל מ-IP תעבורת מנהרה ל-IP תעבורת מנהרה מרחוק.
בדיקת האיתות גורמת לחבילת GRE הנוצרת מ-IP של תעבורת מנהרת המקור ל-IP של תעבורת מנהרת היעד בעוד שהמטען של מנת ה-GRE (ה-IP הפנימי) יהיה ה-IP של מנהרת המקור והיעד.
אם בדיקת האיתות לא הצליחה והפריטים הקודמים מאומתים, ייתכן שתידרש לכידת מנות כדי להבטיח שאיתות ה-icmp ייווצר מנת GRE שנלכדת לאחר מכן לתוך מנת IPsec ולאחר מכן נשלחת מכתובת ה-IPsec המהווה מקור לכתובת ה-IPsec המהווה יעד. מונים בממשק מנהרת GRE ודלפקי ההפעלה של IPsec יכולים גם לעזור בהצגה. אם מנות השליחה והקבלה גדלות.
בנוסף לתעבורת האיתות, לכידה צריכה גם להציג חבילות GRE keepalive גם במהלך תעבורה לא פעילה. לבסוף, אם BGP מוגדר, חבילות BGP keepalive צריכות להישלח גם כחבילות GRE המוקפות בחבילות IPSEC כמו גם דרך ה-VPN.
פתרון בעיות ואימות של BGP
הפעלות BGP
BGP נדרש כפרוטוקול הניתוב דרך מנהרת ה-IPsec של ה-VPN. השכן המקומי של BGP צריך ליצור מפגש eBGP עם השכן של המופע הייעודי BGP. כתובות ה-IP של השכן EBGP זהות לכתובות ה-IP של המנהרה המקומית והמרוחקת. תחילה ודא שמפגש BGP מופעל ולאחר מכן ודא שהנתיבים הנכונים מתקבלים מהמופע הייעודי ונתיב ברירת המחדל הנכון נשלח למופע הייעודי.
אם מנהרת ה-GRE פועלת, ודא שאיתות בוצע בהצלחה בין ה-IP המקומי וה-IP של מנהרת ה-GRE המרוחקת. אם האיתות הצליח אבל הפעלת BGP לא מתבצעת, חקור את יומן ה-BGP לאיתור שגיאות הקמת BGP.
חלק מהנושאים הנפוצים יותר במשא ומתן של BGP הם:
-
המספר המרוחק אינו תואם למספר ה-AS המוגדר בצד המופע הייעודי, בדוק מחדש את השכן כתצורה.
-
המספר המקומי AS אינו תואם למה שצד המופע הייעודי מצפה, וודא שמספר AS המקומי תואם לפרמטרי המופע הייעודי הצפויים.
-
חומת אש חוסמת מנות BGP TCP של BGP הכמוסות במנות GRE מפני שליחה למנהרת IPsec או קבלה ממנהרת IPSEC
-
ה-IP המרוחק של השכן BGP אינו תואם ל-IP המרוחק של מנהרת GRE.
החלפת ניתוב BGP
לאחר הפעלת BGP מאומתת עבור שתי המנהרות, ודא שהנתיבים הנכונים נשלחים והתקבלו מהצד של המופע הייעודי.
פתרון ה-VPN של המופע הייעודי מצפה להקמת שתי מנהרות מהצד של הלקוח/השותף. המנהרה הראשונה מצביעה על מרכז הנתונים של המופע הייעודי A והמנהרה השנייה מצביעה על מרכז הנתונים של המופע הייעודי B. שתי המנהרות חייבות להיות במצב פעיל והפתרון דורש פריסה פעילה/פעילה. כל מרכז נתונים של מופע ייעודי יפרסם את נתיב /25 המקומי וכן נתיב גיבוי /24. בעת בדיקת נתיבי BGP הנכנסים מהמופע הייעודי, ודא שמפגש BGP המשויך למנהרה המצביעה למרכז הנתונים של המופע הייעודי מקבל את הנתיב המקומי של מרכז הנתונים של המופע הייעודי A /25 וכן את נתיב הגיבוי /24. בנוסף, ודא כי המנהרה המצביעה למרכז הנתונים של המופע הייעודי B מקבלת את הנתיב המקומי של מרכז הנתונים של המופע הייעודי B /25 וכן את נתיב הגיבוי /24. שים לב שנתיב הגיבוי /24 יהיה אותו נתיב שיתפרסם ממרכז הנתונים של המופע הייעודי A וממרכז הנתונים של המופע הייעודי B.
יתירות מסופקת למרכז נתונים של מופע ייעודי אם ממשק המנהרה למרכז נתונים זה יורד. אם תאבד קישוריות למרכז הנתונים של המופע הייעודי, תעבורה תועבר ממרכז הנתונים של המופע הייעודי למרכז הנתונים B אל מרכז הנתונים A. בתרחיש זה, המנהרה למרכז הנתונים B תשתמש בנתיב B /25 כדי לשלוח תעבורה אל מרכז הנתונים B והמנהרה למרכז הנתונים B תשתמש בנתיב הגיבוי /24 כדי לשלוח תעבורה אל מרכז הנתונים A באמצעות מרכז הנתונים B.
חשוב כי כאשר שתי המנהרות פעילות, מרכז הנתונים A אינו משמש לשליחת תעבורה למרכז הנתונים B ולהיפך. בתרחיש זה, אם תעבורה נשלחת למרכז נתונים A עם יעד של מרכז נתונים B, מרכז נתונים A יעביר את התעבורה למרכז נתונים B ולאחר מכן מרכז נתונים B ינסה לשלוח תעבורה חזרה למקור דרך מנהרת מרכז הנתונים B. הדבר יגרום לניתוב לא אופטימלי ועלול גם לשבור חומות אש של תעבורה. לכן, חשוב ששתי המנהרות יהיו בתצורה פעילה/פעילה במהלך פעולה רגילה.
יש לפרסם את נתיב 0.0.0.0/0 מצד הלקוח לצד מרכז הנתונים של המופע הייעודי. נתיבים ספציפיים יותר לא יתקבלו על-ידי הצד של המופע הייעודי. ודא שהנתיב 0.0.0.0/0 יפורסם הן ממנהרת מרכז הנתונים של המופע הייעודי A והן ממנהרת מרכז הנתונים של המופע הייעודי B.
תצורת MTU
בצד המופע הייעודי, שתי תכונות מופעלות כדי להתאים באופן דינמי את MTU עבור גדלי מנות גדולים. מנהרת ה-GRE מוסיפה כותרות נוספות למנות ה-IP הזורמות דרך הפעלת ה-VPN. מנהרת IPsec מוסיפה את הכותרות הנוספות בנוסף לכותרות ה-GRE יפחיתו עוד יותר את ה-MTU הגדול ביותר המותר מעל המנהרה.
מנהרת GRE מתאימה את תכונת MSS ונתיב מנהרת GRE בתכונת גילוי MTU מופעלת בצד המופע הייעודי. הגדר את התצורה של "ip tcp adjust-mss 1350" או פקודה שקולה כמו גם "נתיב מנהרה\u0002mtu-discovery" או פקודה שקולה בצד הלקוח כדי לסייע בהתאמת דינמית של MTU של תעבורה דרך מנהרת ה-VPN.