- בית
- /
- מאמר
שער מקומי (LGW) הוא הפתרון הבלעדי למתן גישה PSTN מקומית ללקוחות Cisco Webex Calling. מסמך זה מנחה אותך בקביעת תצורה של שער מקומי באמצעות זמינות גבוהה של CUBE, עם CUBEs פעילים או המתנה כדי להבטיח מעבר כשל במצב של שיחות פעילות.
יסודות
תנאים מוקדמים
לפני פריסת Cisco Unified Border Element (CUBE) זמינות גבוהה (HA) כש ער מקומי עבורWebex Calling, ודא שיש לך הבנה מעמיקה של המוש גים הבאים:
-
יתירות קופסה-לתיבה בשכבה 2 עם CUBE Enterprise לשימור שיחות במצב
הנחיות התצורה המסופקות במאמר זה מניחות פלטפורמת שער מקומית ייעודית ללא תצורה קולית קיימת. אם פריסה ארגונית קיימת של CUBE משתנה כך שתשתמש גם בפונקציית השער המקומי עבורCisco Webex Calling, שים לב היטב לתצורה המיושמת כדי להבטיח שזרימות שיחות ופונקציות קיימות לא יופרעו וודא שאתה עומד בדרישות העיצוב של CUBE HA.
רכיבי חומרה ותוכנה
CUBE HA כשער מקומי דורש IOS-XE גרסה 17.9.1 ואילך ופלטפורמה שבה נתמכות הן פונקציות CUBE HA והן LGW.
פקודות ההצגה והיומנים במאמר זה מבוססים על מהדורת תוכנה מינימלית של Cisco IOS -XE 17.9.1 המיושמת ב- vCube (CSR 8000v).
חומר עזר
להלן מספר מדריכי תצורה מפורטים של CUBE HA לפלטפורמות שונות:
-
ארכיטקטורה מועדפת של סיסקו עבור Cisco Webex Calling - https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Callingסקירת פתרון
Cisco Webex Callingהוא הצעת שיתוף פעולה המספקת אלטרנטיבה מבוססת ענן מרובת דיירים לשירות טלפוני מרכזייה מקומית עם אפשרויות PSTN מרובות ללקוחות.
פריסת השער המקומי (המיוצגת להלן) היא המוקד של מאמר זה. תא המטען של שער מקומי (PSTN מבוסס מקום) Webex Calling מאפשר קישוריות לשירות PSTN בבעלות הלקוח. הוא גם מספק קישוריות לפריסת מרכזיית IP מקומית כגון. Cisco Unified CM כל התקשורת אל הענן וממנו מאובטחת באמצעות הובלת TLS עבור SIP ו- SRTP עבור מדיה.
האיור שלהלן מציג Webex Calling פריסה ללא כל מרכזיית IP קיימת והיא חלה על פריסה אחת או פריסה מרובת אתרים. התצורה המתוארת במאמר זה מבוססת על פריסה זו.
יתירות קופסה-לתיבה בשכבה 2
יתירות קופסה-לתיבה בשכבה 2 של CUBE HA משתמשת בפרוטוקול התשתית של קבוצת יתירות (RG) ליצירת זוג נתבים פעילים/המתנה. זוג זה חולק את אותה כתובת IP וירטואלית (VIP) על פני הממשקים המתאימים שלהם ומחליפים ללא הרף הודעות סטטוס. מידע על הפעלת CUBE נבדק על פני זוג הנתבים המאפשר לנתב המתנה לקחת את כל האחריות לעיבוד שיחות CUBE באופן מיידי אם הנתב הפעיל יוצא משירות, וכתוצאה מכך שימור מצב של איתות ומדיה.
הצבת הבדיקה מוגבלת לשיחות מחוברות עם מנות מדיה. שיחות במעבר אינן מכוונות לסימון (לדוגמה, מצב ניסיון או צלצול).
במאמר זה, CUBE HA יתייחס ליתירות קופסה-לתיבה (B2B) בשכבה 2 של CUBE זמינות גבוהה (HA) לשימו ר שיחות סטטואליות.
החל מ- IOS-XE 17.9.1, ניתן לפרוס את CUBE HA כשער מקומי לפריסות תא מט Cisco Webex Calling ען (PSTN מבוסס שטח). מאמר זה ידון בשיקולי עיצוב ות צורות. האיור מציג הגדרת CUBE HA טיפוסית כשער מקומי לפריסת Cisco Webex Calling תא מטען.
רכיב אינפרא של קבוצת יתירות
רכיב Infra של קבוצת יתירות (RG) מספק תמיכה בתשתית התקשורת קופסה-לתיבה בין שני ה- CUBE ומנהל משא ומתן על מצב היתירות היציב הסופי. רכיב זה מספק גם:
-
פרוטוקול דמוי HSRP המנהל משא ומתן על מצב היתירות הסופי עבור כל נתב על ידי החלפת הודעות keepalive ו- hello בין שני ה- CUBE (באמצעות ממשק הבקרה) —GigaBiteThernet3 באיור לעיל.
-
מנגנון הובלה לבדיקת מצב האיתות והמדיה עבור כל שיחה מהנתב הפעיל למצב המתנה (דרך ממשק הנתונים) —GigaBiteThernet3 באיור לעיל.
-
תצורה וניהול של ממשק ה- IP הווירטואלי (VIP) עבור ממשקי התנועה (ניתן להגדיר ממשקי תנועה מרובים באמצעות אותה קבוצת RG) - GigaBitEthernet 1 ו -2 נחשבים ממשקי תנועה.
רכיב RG זה צריך להיות מוגדר במיוחד כדי לתמוך ב- B2B HA קולית.
ניהול כתובות IP וירטואליות (VIP) הן לאיתות והן למדיה
B2B HA מסתמך על VIP כדי להשיג יתירות. ה- VIP והממשקים הפיזיים המשויכים בשני CUBEs בצמד CUBE HA חייבים להתגורר באותה רשת משנה LAN. תצורת ה- VIP וכריכה של ממשק ה- VIP ליישום קולי מסוים (SIP) הם חובה לתמיכה קולית B2B HA. התקנים חיצוניים כגוןUnified CM, Webex Calling גישה ל- SBC, ספק שירות או פרוקסי, משתמשים ב- VIP ככתובת ה- IP היעד עבור השיחות החוצות דרך נתבי CUBE HA. מכאן שמבח Webex Calling ינה, זוגות ה- CUBE HA פועלים כשער מקומי יחיד.
איתות השיחה ומידע הפעלת RTP של שיחות שהוקמו נבדקים מהנתב הפעיל לנתב המתנה. כאשר הנתב הפעיל יורד, הנתב המתנה משתלט וממשיך להעביר את זרם ה- RTP שניתב בעבר על ידי הנתב הראשון.
שיחות במצב חולף בזמן המעבר לכישלון לא יישמרו לאחר המעבר. לדוגמה, שיחות שעדיין לא הוקמו במלואן או שנמצאות בתהליך של שינוי באמצעות פונקציית העברה או החזקה. שיחות שהוקמו עשויות להיות מנותקות לאחר המעבר.
הדרישות הבאות קיימות לשימוש ב- CUBE HA כשער מקומי למעבר כשל במצב של שיחות:
-
ל- CUBE HA לא יכולים להיות ממשקים TDM או אנלוגיים הממוקמים יחד
-
Gig1 ו- Gig2 מכונים ממשקי תנועה (SIP/RTP) ו- Gig3 הוא ממשק שליטה/נתונים של קבוצת יתירות (RG)
-
לא ניתן למקם יותר משני זוגות CUBE HA באותו תחום שכבה 2, האחד עם מזהה קבוצה 1 והשני עם מזהה קבוצה 2. אם מגדירים 2 זוגות HA עם אותו מזהה קבוצה, ממשקי בקרת RG/נתונים צריכים להשתייך לתחומים שונים בשכבה 2 (vlan, מתג נפרד)
-
ערוץ יציאה נתמך הן עבור ממשקי בקרת RG/נתונים ותנועה
-
כל האות/מדיה מקורם מ/אל כתובת ה- IP הווירטואלית
-
בכל פעם שפלטפורמה נטענת מחדש במערכת יחסים CUBE-HA, היא תמיד מופעלת כהמתנה
-
כתובת נמוכה יותר עבור כל הממשקים (Gig1, Gig2, Gig3) צריכה להיות באותה פלטפורמה
-
מזהה ממשק יתירות, rii צריך להיות ייחודי לשילוב זוג/ממשק באותה שכבה 2
-
התצורה בשני ה- CUBE חייבת להיות זהה כולל תצורה פיזית וחייבת לפעול באותו סוג של פלטפורמה וגרסת IOS-XE
-
לא ניתן להשתמש בממשקי Loopback כקישור מכיוון שהם תמיד למעלה
-
ממשקי תנועה מרובים (SIP/RTP) (Gig1, Gig2) דורשים הגדרת מעקב ממשק
-
CUBE-HA אינו נתמך באמצעות חיבור כבל מוצלב עבור קישור בקרת RG/נתונים (Gig3)
-
שתי הפלטפורמות חייבות להיות זהות ולהיות מחוברות באמצעות מת ג פיזי בכל הממשקים דומים כדי ש- CUBE HA יעבוד, כלומר. GE0/0/0 של CUBE-1 ו- CUBE-2 חייבים להסתיים באותו מתג וכן הלאה.
-
לא ניתן להפסיק את ה- WAN ישירות ב- CUBEs או Data HA משני הצדדים
-
שניהם פעילים/המתנה חייבים להיות באותו מרכז נתונים
-
חובה להשתמש בממשק L3 נפרד לצורך יתירות (בקרת RG/נתונים, Gig3). כלומר ממשק המשמש לתנועה לא יכול לשמש לשימורי HA ולמחסומים
-
לאחר גיבוי כשל, ה- CUBE הפעיל בעבר עובר טעינה מחדש על ידי תכנון, תוך שמירה על איתות ומדיה
הגדר יתירות בשני ה- CUBE
עליך להגדיר יתירות תיבה לתיבה בשכבה 2 בשני CUBEs המיועדים לשימוש בזוג HA כדי להעלות כתובות IP וירטואליות.
| 1 |
הגדר מעקב ממשק ברמה גלובלית כדי לעקוב אחר מצב הממשק.
Track CLI משמש ב- RG למעקב אחר מצב ממשק התנועה הקולית כך שהמסלול הפעיל יהיה תפקידו הפעיל למדי לאחר שממשק התנועה יורד. | ||
| 2 |
הגדר את התצורה של RG לשימוש עם VoIP HA תחת מצב המשנה של יתירות היישום.
להלן הסבר על השדות המשמשים בתצורה זו:
| ||
| 3 |
אפשר יתירות קופסה-לתיבה עבור יישום CUBE. הגדר את ה- RG מהשלב הקודם למטה.
קבוצת יתירות 1 —הוספה והסרה של פקודה זו דורשת טעינה מחדש כדי שהתצורה המעודכנת תיכנס לתוקף. נטען מחדש את הפלטפורמות לאחר יישום כל התצורה. | ||
| 4 |
הגדר את ממשקי Gig1 ו- Gig2 עם כתובות ה- IP הווירטואליות שלהם כמוצג להלן והחיל את מזהה ממשק היתירות (rii)
להלן הסבר על השדות המשמשים בתצורה זו:
| ||
| 5 |
שמור את התצורה של ה- CUBE הראשון וטען אותו מחדש. הפלטפורמה לטעינה אחרונה היא תמיד המתנה.
לאחר ש - VCUBE-1 מתחיל לחלוטין, שמור את התצורה של VCU BE-2 וטען אותה מחדש.
| ||
| 6 |
ודא שתצורת התיבה לתיבה פועלת כצפוי. הפלט הרלוונטי מודגש מוד גש. טענו מחדש את VCUBE-2 אחרון ולפי שיקולי העיצוב; הפלטפורמה לטעינה אחרונה תמיד תהיה המתנה.
לאחר מכן, המשך בתצורת השער המקומי (מבוסס רישום או מבוסס אישור) בשני ה- HA CUBEs. ראה ק ביעת תצורה של שער מקומי ב Cisco IOS - XE עבור Webex Calling. |