מבוא

Virtual Connect היא אפשרות תוסף נוספת עבור קישוריות ענן למופע ייעודי עבור Webex Calling (מופע ייעודי). Virtual Connect מאפשר ללקוחות להרחיב בצורה מאובטחת את הרשת הפרטית שלהם דרך האינטרנט באמצעות מנהרות IP VPN מנקודה לנקודה. אפשרות קישוריות זו מספקת הקמה מהירה של חיבור לרשת פרטית על ידי שימוש בציוד הקיים ללקוח (CPE) ובקישוריות לאינטרנט.

Cisco מארחת, מנהלת ומבטיחה מנהרות IP VPN מיותרות ואת הגישה לאינטרנט הנדרשת באזורי מרכז הנתונים הייעודיים של Cisco's Instance שבהם השירות נדרש. באופן דומה, מנהל המערכת אחראי לשירותי ה-CPE והאינטרנט התואמים שלהם, הנדרשים להקמת Virtual Connect.

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

ל-Virtual Connect מגבלת רוחב פס של 250 Mbps למנהרה ומומלצת לפריסות קטנות יותר. מכיוון שמשתמשים בשתי מנהרות VPN מנקודה לנקודה, כל התעבורה לענן צריכה לעבור דרך ה-CPE של קצה הלקוח, ולכן ייתכן שהיא לא תתאים במקומות שבהם יש הרבה אתרים מרוחקים. לאפשרויות הצצה חלופיות אחרות, עיין קישוריות בענן .

דרישות מקדימות

התנאים המוקדמים להקמת Virtual Connect כוללים:

  • הלקוח מספק

    • חיבור לאינטרנט עם רוחב פס זמין מספיק כדי לתמוך בפריסה

    • כתובת IP ציבורית עבור שתי מנהרות IPSec

    • צד הלקוח של GRE העברה של כתובות IP עבור שתי מנהרות GRE

  • שותף ולקוח

    • עבדו יחד כדי להעריך את דרישות רוחב הפס

    • ודא שהתקני התקן רשת תומכים בניתוב Border Gateway Protocol (BGP) ועיצוב מנהרת GRE over IPSec

  • שותף או לקוח מספקים

    • צוות רשת עם ידע בטכנולוגיות מנהרת VPN מאתר לאתר

    • צוות רשת עם ידע ב-BGP, eBGP ועקרונות ניתוב כלליים

  • Cisco

    • Cisco הקצתה מספרי מערכת אוטונומיים פרטיים (ASN) וכתובת IP חולפת עבור ממשקי מנהרת GRE

    • Cisco הקצתה רשת ציבורית אך לא ניתנת לניתוב אינטרנט מסוג Class C (/24) עבור כתובת ענן ייעודית למופעים


אם ללקוח יש רק מכשיר CPE אחד, אזי 2 המנהרות לכיוון מרכזי הנתונים של סיסקו (DC1 ו-DC2) בכל אזור, יהיו מאותו מכשיר CPE. ללקוח יש גם אפשרות ל-2 מכשירי CPE, ואז כל מכשיר CPE צריך להתחבר למנהרה 1 בלבד לכיוון מרכזי הנתונים של סיסקו (DC1 ו-DC2) בכל אזור. ניתן להשיג יתירות נוספת על ידי סיום כל מנהרה באתר/מיקום פיזי נפרד בתוך תשתית הלקוח.

פרטים טכניים

מודל פריסה

Virtual Connect משתמש בארכיטקטורת headend כפולה, שבה מטוסי הניתוב והבקרה של GRE מסופקים על ידי מכשיר אחד ומישור הבקרה של IPSec מסופק על ידי אחר.

עם השלמת ה חיבור וירטואלי קישוריות, שתי מנהרות GRE over IPSec ייווצרו בין הרשת הארגונית של הלקוח לבין מרכזי הנתונים של Cisco Dedicated Instance. אחד לכל מרכז נתונים מיותר באזור המתאים. רכיבי רשת נוספים הנדרשים להצצה מוחלפים על ידי השותף או הלקוח ל- Cisco באמצעות טופס ההפעלה של Control Hub Virtual Connect.

איור 1 מציג דוגמה של מודל פריסה של Virtual Connect עבור אפשרות 2 הרכזים בצד הלקוח.

Virtual Connect - VPN הוא עיצוב Hub, שבו אתרי ה-Hub של הלקוח מחוברים ל-DC1 ו-DC2 של מרכזי הנתונים של Dedicated Instance באזור מסוים.

שני אתרי Hub מומלצים עבור יתירות טובה יותר, אך אתר One Hub עם שתי מנהרות הוא גם מודל פריסה נתמך.


רוחב הפס לכל מנהרה מוגבל ל-250 Mbps.


האתרים המרוחקים של הלקוח באותו אזור יצטרכו להתחבר בחזרה לאתר/ים ה-Hub דרך ה-WAN של הלקוח, ואין זו באחריותה של Cisco לקישוריות זו.

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

איור 2 מציג את אזורי ההצצה של קישוריות ענן למופע ייעודי.

ניתוב

ניתוב עבור תוסף Virtual Connect מיושם באמצעות BGP חיצוני (eBGP) בין Instance Dedicated ל-Customer Premise Equipment (CPE). Cisco תפרסם את הרשת בהתאמה שלהם עבור כל DC מיותר בתוך אזור ל-CPE של הלקוח וה-CPE נדרש לפרסם נתיב ברירת מחדל ל- Cisco.

  • Cisco מתחזקת ומקצה

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

  • במצב של כשל בקישור ללא תקלה, ל-CPE יחיד יהיו שתי מנהרות פעילות/פעילות. עבור שני צמתי CPE, לכל CPE תהיה מנהרה פעילה אחת ושני צמתי CPE צריכים להיות פעילים ועוברים תעבורה. בתרחיש של אי כשל, התנועה חייבת להתפצל לשתי מנהרות העוברות ליעדי /25 הנכונים, אם אחת המנהרה תרד, המנהרה הנותרת יכולה לשאת את התנועה לשניהם. בתרחיש כשל כזה, כאשר רשת /25 מושבתת, רשת /24 משמשת כמסלול גיבוי. Cisco תשלח תעבורת לקוחות דרך ה-WAN הפנימי שלה לכיוון DC שאיבד את הקישוריות.

תהליך קישוריות

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

1

בצע הזמנה ב- Cisco CCW

2

הפעל חיבור וירטואלי ממרכז הבקרה

3

Cisco מבצעת תצורת רשת

4

הלקוח מבצע תצורת רשת

שלב 1: צו CCW

Virtual Connect הוא תוסף עבור מופע ייעודי ב-CCW.

1

נווט אל אתר ההזמנות של CCW ולאחר מכן לחץ על התחברות כדי להיכנס לאתר:

2

צור הערכה.

3

הוסף מק"ט "A-FLEX-3".

4

בחר אפשרויות ערוך.

5

בלשונית המנוי שמופיעה, בחר אפשרויות ותוספות.

6

תחת תוספות נוספות, סמן את תיבת סימון לצד "חיבור וירטואלי עבור מופע ייעודי". שם מק"ט הוא "A-FLEX-DI-VC".

7

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


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

כאשר אתה מרוצה מהבחירות שלך, לחץ על אמת ושמור בחלק הימני העליון של הדף.

9

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

שלב 2: הפעלה של Virtual Connect ב-Control Hub

1

היכנס ל-Control Hubhttps://admin.webex.com/login .

2

ב- שירותים סעיף, נווט אל שיחות > Instacnce ייעודי > קישוריות לענן .

3

בכרטיס Virtual Connect, הכמות של Virtual Connect שנרכשה רשומה. המנהל יכול כעת ללחוץ על הפעל כדי להתחיל את ההפעלה של Virtual Connect.


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

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


 
הטופס מספק גם מידע סטטי בצד של סיסקו, בהתבסס על האזור שנבחר. מידע זה יהיה שימושי עבור מנהלי לקוחות כדי להגדיר את ה-CPE בצד שלהם כדי ליצור את הקישוריות.
  1. כתובת IP של GRE Tunnel Transport : הלקוח נדרש לספק את כתובות ה-IP של מנהרת IP בצד של הלקוח Cisco תקצה באופן דינמי את כתובות IP לאחר השלמת ההפעלה. ה- IPSec ACL for Interesting Traffic אמור לאפשר תעבורת מנהרה מקומית IP/32 ל- IP/32 של תעבורת מנהרה מרחוק. ה-ACL צריך גם לציין רק את פרוטוקול GRE IP .


     
    כתובת IP שסופק על ידי הלקוח יכולה להיות פרטית או ציבורית.
  2. עמיתים של IPSec : הלקוח נדרש לספק את כתובות IP של מקור ה- IPSec Tunnel ו- Cisco מקצה את כתובת IP של היעד IPSec . ביצוע תרגום NAT של כתובת מנהרת IPSEC פנימית לכתובת ציבורית נתמך גם כן במידת הצורך.


     

    כתובת IP שסופק על ידי הלקוח צריכה להיות ציבורית.


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

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

6

לאחר מילוי טופס ההפעלה של חיבור וירטואלי עבור אזור מסוים, הלקוח יכול לייצא את טופס ההפעלה מ-Control Hub, Calling > Dedicated Instance > Cloud Connectivity וללחוץ על ייצוא הגדרות.


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

שלב 3: Cisco מבצעת תצורת רשת

1

לאחר השלמת טופס הפעלת החיבור הווירטואלי, הסטטוס יעודכן ל ההפעלה בעיצומה ב-Cinging > Dedicated Instance > Cloud Connectivity Virtual Connect Card.

2

Cisco תשלים את התצורות הנדרשות בציוד הצד של סיסקו בתוך 5 ימי עסקים . בסיום מוצלח, הסטטוס יעודכן ל"מופעל" עבור האזור המסוים הזה ב-Control Hub.

שלב 4: הלקוח מבצע תצורת רשת

הסטטוס משתנה ל"מופעל" כדי להודיע למנהל הלקוח שהצד של Cisco של התצורות עבור קישוריות IP VPN הושלם על סמך הקלט שסופק על ידי הלקוח. עם זאת, מנהל הלקוח צפוי להשלים את הצד שלו בתצורות ב-CPEs ולבדוק את מסלולי הקישוריות עבור מנהרת ה-Virtual Connect כדי להיות מקוונת. במקרה של בעיות כלשהן בעת הגדרת התצורה או הקישוריות, הלקוח יכול לפנות אל Cisco TAC לקבלת סיוע.

פתרון בעיות

IPsec First Phase (IKEv2 Negotiation) פתרון בעיות ואימות

המשא ומתן על מנהרת IPsec כולל שני שלבים, שלב IKEv2 ושלב IPsec. אם המשא ומתן על שלב IKEv2 לא מסתיים, אז אין התחלת שלב IPsec שני. ראשית, הפק את הפקודה "show crypto ikev2 sa" (בציוד של Cisco ) או פקודה דומה בציוד של צד שלישי כדי לוודא אם הפעלת IKEv2 פעילה. אם הפעלת IKEv2 לא פעילה, הסיבות האפשריות יכולות להיות:

  • תעבורה מעניינת לא מפעילה את מנהרת IPsec.

  • רשימת גישה למנהרת IPsec מוגדרת בצורה שגויה.

  • אין קישוריות בין הלקוח לבין נקודת הקצה של מנהרת IP של מופע ייעודי.

  • פרמטרי ההפעלה של IKEv2 אינם תואמים בין צד המופע הייעודי לצד הלקוח.

  • חומת אש חוסמת את מנות IKEv2 UDP .

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

כמה שגיאות נפוצות במשא ומתן של IKEv2 הן:
  • ההגדרות של IKEv2 בצד CPE אינן תואמות לצד של Cisco , בדוק שוב את ההגדרות שהוזכרו:

    • בדוק שגרסת ה-IKE היא גרסה 2.

    • ודא שהפרמטרים ההצפנה והאימות תואמים להצפנה הצפויה בצד המופע הייעודי.


      כאשר הצופן "GCM" נמצא בשימוש, פרוטוקול GCM מטפל באימות ומגדיר את פרמטר האימות ל-NULL.

    • ודא את הגדרת כל החיים.

    • אמת את קבוצת המודולוס של דיפי הלמן.

    • ודא את ההגדרות של פונקציית Pseudo Random Function.

  • רשימת גישה למפת ההצפנה אינה מוגדרת ל:

    • היתר GRE (local_tunnel_transport_ip ) 255.255.255.255 (remote_tunnel_transport_ip ) 255.255.255.255" (או פקודה מקבילה)


      רשימת גישה חייבת להיות ספציפית עבור פרוטוקול "GRE" ופרוטוקול "IP" לא יעבוד.

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


ייתכן שצד מופע ייעודי לא תמיד מתחיל את החלפת IKEv2 ולפעמים עשוי לצפות שצד ה-CPE של הלקוח יהיה היוזם.

בדוק את תצורת הצד של CPE עבור התנאים המוקדמים הבאים לתחילת הפעלת IKEv2:

  • בדוק אם יש רשימת גישה קריפטו של IPsec עבור תעבורת GRE (פרוטוקול 50) מ- IP של תעבורת מנהרת CPE ל- IP של תעבורת מנהרה של מופע ייעודי.

  • ודא שממשק מנהרת GRE מופעל עבור GRE keepalives, אם הציוד אינו תומך ב-GRE keepalives, Cisco מקבלת הודעה מכיוון ש-GRE keepalives יופעל בצד המופע הייעודי כברירת מחדל.

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

כאשר מוגדרים כראוי, הדברים הבאים מתחילים את מנהרת IPsec ואת המשא ומתן השלב הראשון של IKEv2:

  • GRE keepalives מממשק מנהרת GRE בצד CPE לממשק מנהרת GRE בצד Instance.

  • הפעלת TCP שכן BGP מהשכן BGP בצד CPE לשכן BGP בצד המופע היעודי.

  • פינג מכתובת ה-IP של המנהרה הצדדית של CPE כתובת IP כתובת IP של המנהרה הצדדית של מופע ייעודי.


    פינג לא יכול להיות IP של תעבורת מנהרה ל- IP של תעבורת מנהרה, זה חייב להיות IP של מנהרה IP.

אם יש צורך במעקב אחר מנות עבור תעבורת IKEv2, הגדר את המסנן עבור UDP ויציאה 500 (כאשר אין התקן NAT באמצע נקודות הקצה של IPsec) או יציאה 4500 (כאשר התקן NAT מוכנס באמצע ה-IPsec נקודות קצה).

ודא שמנות IKEv2 UDP עם יציאה 500 או 4500 נשלחות ומתקבלות אל וממנה כתובת IP של DI IPsec.


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

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

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

IPsec Second Phase (IPsec Negotiation) פתרון בעיות ואימות

ודא שהשלב הראשון של IPsec (כלומר, שיוך האבטחה של IKEv2) פעיל לפני פתרון בעיות השלב השני של IPsec. בצע "הצג crypto ikev2 sa" או פקודה מקבילה כדי לאמת את הפעלת IKEv2. בפלט, ודא שהפעלת IKEv2 הייתה למעלה מכמה שניות ושהוא לא קופץ. זמן הפעילות של ההפעלה מופיע בתור ההפעלה "זמן פעיל" או שווה ערך בפלט.

לאחר שהפעלת IKEv2 מאמת שהיא פעילה ופעילה, חקור את הפעלת IPsec. כמו בהפעלת IKEv2, בצע "הצג crypto ipsec sa" או פקודה מקבילה כדי לאמת את הפעלת IPsec. גם הפעלת IKEv2 וגם הפעלת IPsec חייבות להיות פעילות לפני הקמת מנהרת GRE. אם הפעלת IPsec אינה מופיעה כפעילה, בדוק ביומני IPsec עבור הודעות שגיאה או שגיאות משא ומתן.

כמה מהבעיות הנפוצות יותר שעלולות להיתקל במהלך משא ומתן IPsec הן:

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

  • ודא שהפרמטרים של ההצפנה והאימות תואמים להגדרות בצד המופע הייעודי.

  • ודא את ההגדרות של Perfect Forward Secrecy ואת הגדרות ההתאמה בצד המופע הייעודי.

  • אמת את הגדרות החיים.

  • ודא שה-IPsec הוגדר במצב מנהרה.

  • אמת את כתובות ה-IPsec של המקור והיעד.

פתרון תקלות ואימות ממשק המנהרה

כאשר הפעלות IPsec ו-IKEv2 מאומתות כפעילות ופעילות, מנות המנהרת GRE Keepalive מסוגלות לזרום בין המופע הייעודי ונקודות הקצה של מנהרת CPE. אם ממשק המנהרה לא מופיע, כמה בעיות נפוצות הן:

  • ה-VRF של העברת ממשק המנהרה אינו תואם את ה-VRF של ממשק הלולאה (אם נעשה שימוש בתצורת VRF בממשק המנהרה).


    אם לא נעשה שימוש בתצורת VRF בממשק המנהרה, ניתן להתעלם מבדיקה זו.

  • Keepalives אינם מופעלים בממשק המנהרה הצדדית של CPE


    אם Keepalives אינם נתמכים בציוד ה-CPE, אזי יש ליידע את Cisco כך שגם ברירת המחדל של Keepalives בצד Dedicated Instance תהיה מושבתת.

    אם Keepalives נתמכים, ודא שה- Keepalives מופעלים.

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

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

  • חומת אש חוסמת מנות GRE להישלח לתוך מנהרת IPsec או להתקבל ממנהרת IPsec (מנהרת GRE מועברת דרך מנהרת IPsec)

בדיקת ping אמורה לוודא שממשק המנהרה המקומית פועל והקישוריות טובה לממשק המנהרה המרוחקת. בצע את בדיקת הפינג מה- IP של המנהרה (לא ה- IP של התחבורה) ל- IP של המנהרה המרוחקת.


רשימת גישה לקריפטו עבור מנהרת IPsec הנושאת את תעבורת מנהרת GRE מאפשרת לחצות רק מנות GRE. כתוצאה מכך, פינגים לא יפעלו מ- IP של העברת מנהרה ל- IP של העברת מנהרה מרחוק.

בדיקת הפינג מביאה לחבילת GRE שנוצרת מ- IP תעבורת המנהרה של המקור ל- IP של תעבורת מנהרת היעד, בעוד שהמטען של חבילת ה-GRE (ה- IP הפנימי) יהיה ה- IP של מנהרת המקור והיעד.

אם בדיקת הפינג לא הצליחה והפריטים הקודמים מאומתים, ייתכן שיידרש לכידת מנה כדי להבטיח שה- icmp ping מביא לחבילת GRE אשר לאחר מכן מובלעת בחבילת IPsec ולאחר מכן נשלחת מכתובת ה-IPsec של המקור אל כתובת ה-IPsec של היעד. גם מונים בממשק מנהרת GRE ומונהי הפעלות של IPsec יכולים לעזור להראות. אם מנות השליחה והקבלה עולות.

בנוסף לתעבורת הפינג, הלכידה אמורה להראות גם מנות GRE חיות גם בזמן תנועה סרק. לבסוף, אם BGP מוגדר, מנות BGP keepalive צריכות להישלח גם כמנות GRE המובלעות במנות IPSEC גם דרך ה- VPN.

פתרון בעיות ואימות BGP

מפגשי BGP

BGP נדרש כפרוטוקול הניתוב דרך מנהרת IPsec VPN . שכן ה-BGP המקומי צריך ליצור הפעלת eBGP עם שכן ה-BGP של המופע הייעודי. כתובות IP השכנות של eBGP זהות לכתובת ה- IP המקומית והמרוחקת של המנהרה. תחילה ודא שהפעלת ה-BGP פועלת ולאחר מכן ודא שהמסלולים הנכונים מתקבלים מ-Dedicated Instance ומסלול ברירת המחדל הנכון נשלח ל-Dedicated Instance.

אם מנהרת GRE פתוחה, ודא שה-Ping הצליח בין IP המקומי של מנהרת GRE המרוחקת. אם הפינג הצליח אך הפעלת BGP לא מגיעה, בדוק את יומן BGP עבור שגיאות הקמת BGP.

כמה מהבעיות הנפוצות יותר של משא ומתן BGP הן:

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

  • מספר ה-AS המקומי אינו תואם למה שצד המופע של Dedictaed מצפה, ודא שמספר ה-AS המקומי תואם לפרמטרים הצפויים של מופע ייעודי.

  • חומת אש חוסמת מנות BGP TCP המובלעות במנות GRE להישלח למנהרת IPsec או להתקבל ממנהרת IPSEC

  • ה- IP השכן של BGP המרוחק אינו תואם ל- IP של מנהרת GRE המרוחקת.

BGP Route Exchange

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

פתרון ה-Dedicated Instance VPN מצפה שיוקמו שתי מנהרות מצד הלקוח/השותף. המנהרה הראשונה מצביעה על מרכז הנתונים של מופע ייעודי A והמנהרה השנייה מצביעה על מרכז הנתונים של מופע ייעודי B. שתי המנהרות חייבות להיות במצב פעיל והפתרון דורש פריסה פעילה/פעילה. כל מרכז נתונים של מופע ייעודי יפרסם את המסלול המקומי שלו /25 וכן מסלול גיבוי /24. בעת בדיקת מסלולי ה-BGP הנכנסים ממופע ייעודי, ודא שהפעלת BGP הקשורה למנהרה המצביעה על מרכז הנתונים של מופע ייעודי A מקבלת את נתיב מקומי של מרכז הנתונים של מופע ייעודי A /25 וכן את מסלול הגיבוי /24. בנוסף, ודא שהמנהרה הפונה למרכז הנתונים של מופע ייעודי B מקבלת את נתיב מקומי של מרכז הנתונים של מופע ייעודי B /25 וכן את מסלול הגיבוי /24. שים לב שמסלול הגיבוי /24 יהיה אותו מסלול המפורסם מתוך מרכז הנתונים של מופע ייעודי A ומרכז הנתונים של מופע ייעודי B.

יתירות מסופקת למרכז נתונים של מופע ייעודי אם ממשק המנהרה לאותו מרכז נתונים יורד. אם הקישוריות למרכז הנתונים של מופע ייעודי A אבדה, התעבורה תועבר ממרכז הנתונים של מופע ייעודי B למרכז הנתונים A. בתרחיש זה, המנהרה למרכז הנתונים B תשתמש בנתיב מרכז הנתונים B/25 כדי לשלוח תנועה למרכז הנתונים B ולמנהרה למרכז הנתונים B ישתמש במסלול הגיבוי /24 כדי לשלוח תעבורה למרכז הנתונים A דרך מרכז הנתונים B.

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

יש לפרסם את המסלול 0.0.0.0/0 מצד הלקוח לצד Dedicated Instance Datacenter. מסלולים ספציפיים יותר לא יתקבלו על ידי הצד של המופע הייעודי. ודא שהמסלול 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 .