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

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

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

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

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

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

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

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

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

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

• Cisco שומרת ומקצה

  • כתובת IP של ממשק מנהרה (קישור זמני לניתוב) Cisco מקצה ממרחב כתובות משותף ייעודי (לא ניתן לנתב באופן ציבורי)

  • כתובת התפלה של תעבורת מנהרה (צד של Cisco)

  • מספרי מערכת אוטונומיים פרטיים (ASNs) עבור תצורת ניתוב 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, שאיבד את הקישוריות.

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

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

• רשימת הגישה למנהרה של IPsec מוגדרת באופן שגוי.

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

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

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

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

כמה שגיאות נפוצות במשא ומתן IKEv2 הן:

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

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

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

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

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

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

  • אמת את הגדרות הפונקציה האקראית הפסאודו.

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

  • אפשר GRE (local_tunnel_transport_ip) 255.255.255 (remote_tunnel_transport_ip) 255.255.255" (או פקודה שווה ערך)

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

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

הצד של מופע ייעודי לא תמיד יתחיל את חילופי IKEv2 ולפעמים עשוי לצפות שצד CPE של הלקוח יהיה היוזם. בדוק את תצורת הצד CPE עבור הדרישות המקדימות הבאות עבור התחלת הפעלה IKEv2: בדוק אם יש רשימת גישה הצפנה של IPsec עבור תעבורת GRE (פרוטוקול 50) מ- IP תעבורת מנהרת CPE אל IP תעבורת מנהרה מופע ייעודי. ודא שממשק מנהרת GRE מופעל עבור GRE keepalives, אם הציוד אינו תומך ב-Keepalives של GRE, Cisco מקבל הודעה משום ש-Keepalives של GRE יופעלו בצד המופע הייעודי כברירת מחדל. ודא ש-BGP מופעל ומוגדר עם כתובת השכן של ה-IP של מנהרת המופע הייעודי.

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

• GRE שומר מממשק מנהרת ה- CPE הצדדי GRE לממשק מנהרת GRE לצד המופע הייעודי.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בצד המופע הייעודי, שתי תכונות מופעלות להתאמה דינמית של MTU עבור גודל מנה גדולה. מנהרת ה-GRE מוסיפה כותרות נוספות לחבילות ה-IP הזורמות דרך הפעלת ה-VPN. מנהרת ה-IPsec מוסיפה את הכותרות הנוספות בחלק העליון של כותרות ה-GRE יפחית עוד יותר את ה-MTU הגדול ביותר שמותר מעל המנהרה.

מנהרת GRE מתאימה את תכונת MSS ואת נתיב מנהרת GRE בתכונת גילוי MTU מופעלת בצד המופע הייעודי. קבע את התצורה של "ip tcp adjust-mss 1350" או פקודה שווה ערך כמו גם "tunnel path\u0002mtu-discovery" או פקודה שווה ערך בצד הלקוח כדי לעזור עם התאמת הדינמית של MTU של תעבורה דרך מנהרת ה-VPN.