יסודות

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

לפני פריסת CUBE HA כשער מקומי עבור Webex Calling, ודא שיש לך הבנה מעמיקה של המושגים הבאים:

הנחיות התצורה המופיעות במאמר זה מבוססות על ההנחה שישנה פלטפורמת שער מקומית ייעודית ללא תצורת קול קיימת. אם פריסה ארגונית קיימת של CUBE משתנה כדי להשתמש גם בפונקציית השער המקומי עבור Cisco Webex Calling, שים לב היטב לתצורה שהוחלה כדי להבטיח שזרימות השיחות והפונקציונליות הקיימות אינן משתבשות וודא שאתה עומד בדרישות התכנון של CUBE HA.

רכיבי חומרה ותוכנה

CUBE HA כשער מקומי דורש את IOS-XE גרסה 16.12.2 ואילך ופלטפורמה שבה הפונקציות CUBE HA ו-LGW נתמכות שתיהן.

פקודות התצוגה והיומנים במאמר הזה מבוססים על מהדורת תוכנה מינימלית של Cisco IOS-XE 16.12.2 המוטמעת ב-vCUBE‏ (CSR1000v).

חומר עזר

הנה כמה מדריכי תצורה מפורטים של CUBE HA עבור פלטפורמות שונות:

סקירה כללית של הפתרון Webex Calling

Cisco Webex Calling הוא הצעת שיתוף פעולה המספקת חלופה מבוססת ענן מרובת דיירים לשירות טלפון מקומי של מרכזת פרטית (PBX) עם אפשרויות PSTN מרובות ללקוחות.

פריסת השער המקומי (המיוצגת להלן) היא הנושא המרכזי במאמר הזה. ה-trunk של השער המקומי (PSTN המבוסס על הסביבה המקומית) ב-Webex Calling מאפשר קישוריות לשירות PSTN בבעלות הלקוח. הוא גם מספק קישוריות לפריסת IP PBX מקומית כגון Cisco Unified CM. כל התקשורת אל הענן וממנו מאובטחת באמצעות תעבורת TLS עבור SIP ו-SRTP למדיה.

האיור שלהלן מציג פריסת Webex Calling ללא IP PBX קיים, והוא חל על פריסה של אתר יחיד או על פריסה מרובת אתרים. התצורה המתוארת במאמר זה מבוססת על הפריסה הזו.

יתירות מקופסה לקופסה בשכבה 2

יתירות מקופסה לקופסה בשכבה 2 של CUBE HA משתמשת בפרוטוקול התשתית של קבוצת היתירות (RG) כדי ליצור זוג נתבים במצב פעיל/מצב המתנה. זוג זה חולק את אותה כתובת IP וירטואלית (VIP) בכל הממשקים המתאימים ומחליף ללא הרף הודעות מצב. פרטי ההפעלה של CUBE עוברים בדיקה בנקודת ביקורת בין שני הנתבים, דבר מאפשר לנתב שבמצב המתנה לקחת על עצמו את כל האחריות על עיבוד שיחות ה-CUBE באופן מיידי אם הנתב הפעיל יוצא מכלל שימוש, וכתוצאה מכך מתאפשר שימור של איתות ומדיה עם מידע על המצב.

הבדיקה בנקודת הביקורת מוגבלת לשיחות מחוברות עם מנות מדיה. שיחות במעבר אינן עוברות בדיקת ביקורת (לדוגמה, מצב ניסיון או צלצול).

במאמר זה, CUBE HA יתייחס ליתירות מקופסה לקופסה בשכבה 2 של CUBE בזמינות גבוהה (HA) לצורך שימור שיחות עם מצב

החל מ-IOS-XE 16.12.2, ניתן לפרוס את CUBE HA כשער מקומי עבור פריסות trunk של של Cisco Webex Calling‏ (PSTN המבוסס על הסביבה המקומית) ואנו נסקור שיקולי תכנון ותצורות במאמר זה. איור זה מציג הגדרה טיפוסית של CUBE HA כשער מקומי לפריסת trunk של Cisco Webex Calling.

רכיב אינפרא של קבוצת יתירות

רכיב האינפרא של קבוצת היתירות (RG) מספק את התמיכה בתשתית התקשורת מקופסה לקופסה בין שני רכיבי ה-CUBE ומנהל משא ומתן על מצב היתירות היציב הסופי. הרכיב הזה מספק גם:

  • פרוטוקול דמוי HSRP שמנהל משא ומתן על מצב היתירות הסופי עבור כל נתב על-ידי החלפת הודעות keepalive ו-hello בין שני רכיבי ה-CUBE (באמצעות ממשק הבקרה) – GigabitEthernet3 באיור למעלה.

  • מנגנון תעבורה לבדיקת ביקורת של מצב האיתות והמדיה עבור כל שיחה מהנתיב הפעיל לנתב במצב המתנה (דרך ממשק הנתונים) – GigabitEthernet3 באיור למעלה.

  • התצורה והניהול של ממשק ה-IP הווירטואלי (VIP) עבור ממשקי התעבורה (ניתן לקבוע את התצורה של ממשקי תעבורה מרובים באמצעות אותה קבוצת RG) – GigabitEthernet 1 ו-2 נחשבים לממשקי תעבורה.

יש לקבוע את התצורה של רכיב ה-RG הזה באופן ספציפי כדי לתמוך בקול B2B HA.

ניהול כתובות IP וירטואלי (VIP) הן עבור איתות והן עבור מדיה

B2B HA מסתמך על VIP כדי להשיג יתירות. ממשקי ה-VIP והממשקים הפיזיים הקשורים אליהם בשני רכיבי ה-CUBE בזוג CUBE HA חייבים לשכון באותה רשת משנה של LAN. קביעת התצורה של ה-VIP ואיגוד ממשק ה-VIP ליישום קולי מסוים (SIP) היא הכרחית לתמיכה קולית ב-B2B HA. מכשירים חיצוניים כגון Unified CM, ‏SBC לגישה של Webex Calling, ספק שירות או Proxy, משתמשים ב-VIP ככתובת ה-IP המהווה יעד עבור השיחות החוצות את נתבי CUBE HA. לפיכך, מנקודת מבט של Webex Calling, זוגות ה-CUBE HA פועלים כשער מקומי יחיד.

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

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

להלן הדרישות לשימוש ב-CUBE HA כשער מקומי עבור יתירות כשל של שיחות עם פרטי מצב:

  • CUBE HA לא יכול למקם ממשקי TDM או ממשקים אנלוגיים במשותף

  • Gig1 ו-Gig2 מכונים ממשקי תעבורה (SIP/RTP) ו-Gig3 הוא ממשק בקרה/נתונים של קבוצת יתירות (RG)

  • לא ניתן למקם יותר מ-2 זוגות 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 לא יכול להסתיים ברכיבי ה-CUBE ישירות או ב-HA של הנתונים משני הצדדים

  • גם הנתב הפעיל וגם הנתב במצב המתנה חייבים להיות באותו מרכז נתונים

  • חובה להשתמש בממשק L3 נפרד ליתירות (בקרה/נתונים של RG‏, Gig3). כלומר, ממשק המשמש לתעבורה אינו יכול לשמש עבור keepalives ונקודות ביקורת של HA

  • עם יתירות כשל, רכיב ה-CUBE שהיה פעיל בעבר עובר טעינה מחדש לפי תכנון המוצר, תוך שמירה על איתות ומדיה

קביעת התצורה של יתירות בשני רכיבי ה-CUBE

עליך לקבוע את התצורה של יתירות מקופסה לקופסה בשכבה 2 בשני רכיבי -CUBE המיועדים לשימוש בזוג HA כדי להעלות כתובות IP וירטואליות.

1

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

ממשק conf t track 1 ממשק GigabitEthernet1 נתיב פרוטוקול קו 2 ממשק GigabitEthernet2 יציאה פרוטוקול קו 

VCUBE-1#conf t

פרוטוקול קו 

VCUBE-1(config)#track 1 ממשק GigabitEthernet1

VCUBE-1(config-track)#track 2 ממשק פרוטוקול קו של GigabitEthernet2

VCUBE-1(config-track)#יציאה

VCUBE-2#conf t

VCUBE-2(config)#track 1 ממשק GigabitEthernet1

VCUBE-2(config-track)#track 2 ממשק פרוטוקול קו של GigabitEthernet2

VCUBE-2(תצורה-track)#יציאה

ה-CLI של המעקב משמש ב-RG כדי לעקוב אחר מצב ממשק התעבורה הקולית, כך שהנתיב הפעיל ייצא מתפקידו הפעיל לאחר שממשק התעבורה יושבת.

2

קבע את התצורה של RG לשימוש עם VoIP HA תחת מצב המשנה של יתירות היישום.

יתירות קבוצת יתירות יישום 1 שם LocalGateway-HA עדיפות 100 יתירות כשל 75 שליטה פרוטוקול GigabitEthernet3 1 נתונים GigabitEthernet3 timers delay 30 reload 60 track 1 track 2 כיבוי פרוטוקול יציאה 1 timers hellotime 3 holdtime 10 exit exit exit 

VCUBE-1(config)#יתירות

VCUBE-1 (config-red)#יתירות יישום

VCUBE-1 (config-red-app)#קבוצה 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 יתירות כשל של סף 75

VCUBE-1(config-red-app-grp)#שליטה בפרוטוקול GigabitEthernet3 1

VCUBE-1(config-red-app-grp)#נתונים GigabitEthernet3

VCUBE-1(config-red-app-grp)#עיכוב של טיימרים 30 טעינה מחדש 60

VCUBE-1(config-red-app-grp)#track 1 כיבוי

VCUBE-1(config-red-app-grp)#track 2 כיבוי

VCUBE-1(config-red-app-grp)#יציאה

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#טיימרים hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#יציאה

VCUBE-1 (config-red-app)#יציאה

VCUBE-1 (config-red)#יציאה

VCUBE-1 (תצורה)#

VCUBE-2(config)#יתירות

VCUBE-2 (config-red)#יתירות יישום

VCUBE-2 (config-red-app)#קבוצה 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 יתירות כשל של סף 75

VCUBE-2(config-red-app-grp)#שליטה בפרוטוקול GigabitEthernet3 1

VCUBE-1(config-red-app-grp)#נתונים GigabitEthernet3

VCUBE-2(config-red-app-grp)#עיכוב של טיימרים 30 טעינה מחדש 60

VCUBE-2(config-red-app-grp)#רצועה 1 כיבוי

VCUBE-2(config-red-app-grp)#track 2 כיבוי

VCUBE-2(config-red-app-grp)#יציאה

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#טיימרים hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#יציאה

VCUBE-2 (config-red-app)#יציאה

VCUBE-2 (config-red)#יציאה

VCUBE-2 (תצורה)#

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

  • יתירות – נכנס למצב יתירות

  • יתירות יישום – נכנס למצב תצורה של יתירות יישום

  • group – נכנס למצב תצורה של קבוצת יישומים יתירות

  • name LocalGateway-HA – מגדיר את השם של קבוצת RG

  • עדיפות 100 סף יתירות כשל 75 – מציין את ערכי הסף של העדיפות הראשונית ויתירות כשל עבור RG

  • טיימרים delay 30 reload 60 – מגדיר את שתי הפעמים לעיכוב ולטעינה מחדש

    • טיימר עיכוב שהוא משך הזמן לעיכוב האתחול והמשא ומתן על התפקידים של קבוצת RG לאחר שהממשק עולה – ברירת המחדל היא 30 שניות. הטווח הוא 0-10,000 שניות

    • Reload (טעינה מחדש) – זהו משך הזמן לעיכוב האתחול והמשא ומתן על התפקידים של קבוצת RG לאחר טעינה מחדש – ברירת המחדל היא 60 שניות. הטווח הוא 0-10,000 שניות

    • טיימרים המוגדרים כברירת מחדל מומלצים, אם כי ניתן לכוונן את הטיימרים האלה כך שיתאימו לכל עיכוב נוסף בהתכנסות הרשת שעלול להתרחש במהלך אתחול/טעינה מחדש של הנתבים, על מנת להבטיח שהמשא ומתן על פרוטוקול RG יתקיים לאחר שהניתוב ברשת התכנס לנקודה יציבה. לדוגמה, אם לאחר יתירות הכשל לוקח עד 20 שניות ל-STANDBY החדש לראות את מנת RG HELLO הראשונה מה-ACTIVE החדש, יש לכוונן את הטיימרים ל-‘timers delay 60 reload 120’ כדי לקחת בחשבון את העיכוב הזה.

  • control GigabitEthernet3 protocol 1 – מגדיר את הממשק המשמש להחלפת הודעות keepalive ו-hello בין שני רכיבי ה-CUBE, ומציין את מופע הפרוטוקול שיצורף לממשק בקרה ומזין את מצב התצורה של פרוטוקול יישום יתירות

  • נתונים GigabitEthernet3 – מגדיר את הממשק המשמש לבדיקת תעבורת נתונים

  • track – מעקב של קבוצת RG של ממשקים

  • פרוטוקול 1 – מציין את מופע הפרוטוקול שיצורף לממשק בקרה וכניסה למצב תצורה של פרוטוקול יישום יתירות

  • timers hellotime 3 holdtime 10 – מגדיר את שני הטיימרים עבור hellotime ו-holdtime:

    • Hellotime – מרווח בין הודעות hello עוקבות – ברירת המחדל היא 3 שניות. הטווח הוא 250 אלפיות השנייה עד 254 שניות

    • Holdtime – המרווח בין קבלת הודעת Hello לבין ההנחה שהנתב השולח נכשל. משך זמן זה חייב להיות גדול מ-hello-time – ברירת המחדל היא 10 שניות. הטווח הוא 750 אלפיות השנייה עד 255 שניות

      אנו ממליצים להגדיר את טיימר holdtime כך שיהיה לפחות פי 3 מהערך של טיימר hellotime.

3

הפעל יתירות מקופסה לקופסה עבור יישום CUBE. קבע את התצורה של ה-RG מהשלב הקודם תחת voip של שירות קולי. פעולה זו מאפשרת ליישום CUBE לשלוט בתהליך היתירות.

יתירות ב-voip של שירות קולי ביציאה מקבוצה 1

VCUBE-1(config)#voip של שירות קולי

VCUBE-1

(config-voi-serv)#redundancy-group 1

 % נוצר שיוך RG 1 עם קול B2B HA; טען מחדש את הנתב כדי שתצורה חדשה תיכנס לתוקף

VCUBE-1

(config-voi-serv)# יציאה

VCUBE-2(config)#voip של שירות קולי

VCUBE-2

(config-voi-serv)#יתירות-group 1

 % נוצר שיוך RG 1 עם קול B2B HA; טען מחדש את הנתב כדי שתצורה חדשה תיכנס לתוקף

VCUBE-2

(config-voi-serv)# יציאה

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

4

קבע את תצורת ממשקי Gig1 ו-Gig2 עם כתובות ה-IP הווירטואליות המתאימות שלהם כפי שמוצג להלן והחל את מזהה ממשק היתירות (rii)

VCUBE-1(config)#ממשק GigabitEthernet1

VCUBE-1 (תצורה-אם)# יתירות Rii 1

VCUBE-1 (config-if) מס' יתירות קבוצת ip 1 198.18.1.228 בלעדי

VCUBE-1 (תצורה-אם)# יציאה

VCUBE-1 (תצורה)#

VCUBE-1(config)#ממשק GigabitEthernet2

VCUBE-1 (תצורה-אם)# יתירות Rii 2

VCUBE-1 (config-if) מס' יתירות קבוצת ip 1 198.18.133.228 בלעדי

VCUBE-1 (תצורה-אם)# יציאה

VCUBE-2(config)#ממשק GigabitEthernet1

VCUBE-2 (תצורה-אם)# יתירות Rii 1

VCUBE-2 (config-if) מס' יתירות קבוצת ip 1 198.18.1.228 בלעדי

VCUBE-2 (תצורה-אם)# יציאה

VCUBE-2 (תצורה)#

VCUBE-2(config)#ממשק GigabitEthernet2

VCUBE-2 (config-if)# יתירות rii 2

VCUBE-2 (config-if) מס' יתירות קבוצת ip 1 198.18.133.228 בלעדי

VCUBE-v

(config-if)# יציאה

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

  • יתירות rii – מגדיר את מזהה ממשק היתירות עבור קבוצת היתירות. נדרש ליצירת כתובת MAC וירטואלית (VMAC). יש להשתמש באותו ערך מזהה rii בממשק של כל נתב (פעיל/במצב המתנה) בעל אותו VIP.

    אם יש יותר מזוג B2B אחד באותה רשת LAN, לכל זוג חייבים להיות מזהי rii ייחודיים בממשקים המתאימים שלהם (כדי למנוע התנגשות). האפשרות 'show redundancy application group all' צריכה לציין את המידע המקומי והעמיתים הנכונים.

  • יתירות קבוצה 1 – משייכת את הממשק לקבוצת היתירות שנוצרה בשלב 2 לעיל. קבע את התצורה של קבוצת RG, כמו גם את ה-VIP שהוקצה לממשק הפיזי הזה.

    חובה להשתמש בממשק נפרד לצורך יתירות, כלומר, הממשק המשמש לתעבורה קולית אינו יכול לשמש כממשק הבקרה והנתונים שצוין בשלב 2 לעיל. בדוגמה זו, ממשק Gigabit 3 משמש לבקרה/נתונים של RG

5

שמור את התצורה של רכיב ה-CUBE הראשון וטען אותה מחדש.

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

VCUBE-1#wr

 בונה תצורה... 

 [בסדר] 

VCUBE-1#טען מחדש

 להמשיך בטעינה מחדש? [אשר]

לאחר שהאתחול של VCUBE-1 יושלם, שמור את התצורה של VCUBE-2 וטען אותה מחדש.

VCUBE-2#wr

 בונה תצורה... 

 [בסדר] 

VCUBE-2#טען מחדש

 להמשיך בטעינה מחדש? [אשר]

6

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

VCUBE-2 נטען מחדש אחרון ולפי שיקולי התכנון; הפלטפורמה שנטענת מחדש אחרונה תמיד תהיה במצב המתנה. 

 VCUBE-1#הצג קבוצת יישומים של יתירות את כל מצבי השגיאות של קבוצה 1 מידע:        עדיפות זמן ריצה: [100] תקלות RG במצב RG: למעלה.                        מספר כולל של מתגים עקב תקלות:  0 מספר כולל של שינויים במצב 'למטה/למעלה' עקב תקלות: 0 מזהה קבוצה:1 שם קבוצה:LocalGateway-HA מצב מנהלי: אין מצב תפעולי מצטבר של כיבוי: למעלה  התפקיד שלי: תפקיד עמית פעיל: נוכחות עמית במצב המתנה : כן עמית תקשורת: כן התקדמות העמיתים התחילה: כן דומיין RF: מצב RF של btob-one: מצב RF של עמית פעיל: תפקיד במצב המתנה של פרוטוקול RG חם RG 1 ------------------: משא ומתן פעיל: עדיפות מופעלת: מצב פרוטוקול 100: מצב Ctrl Intf פעיל: עמית פעיל למעלה: עמית המתנה מקומי: כתובת 10.1.1.2, עדיפות 100, מונה יומני רישום של Gi3 intf:                 שינוי תפקיד פעיל: שינוי תפקיד אחד למצב המתנה: 1 השבת אירועים: rg במצב מטה 0, rg סגור 0 אירועי intf ctrl: למעלה 1, למטה 0, admin_down 0 אירועים נטענים מחדש: בקשה מקומית 0, בקשת עמית 0 הקשר מדיה RG עבור מצב RG 1 -------------------------- Ctx: מזהה פרוטוקול פעיל: סוג מדיה אחד: ממשק ברירת מחדל בקרה: שעון עצר נוכחי של GigabitEthernet3 : 3000 טיימר 'שלום' מוגדר: 3000, טיימר החזקה: טיימר Hello של עמית 10000: 3000, טיימר להחזיק עמית: 10000 סטטיסטיקה:             Pkts 1509, בתים 93558, HA Seq 0, מספר Seq 1509, אובדן Pkt 0 אימות לא הוגדר כשל אימות: 0 עמית טען מחדש: TX 0, RX 0 התפטרות: TX 0,‏ RX 0 עמית סטנדרטי: הווה. טיימר להמתנה: 10000 Pkts 61, בתים 2074, HA Seq 0, מספר Seq 69, Pkt Loss 0 VCUBE-1#
 VCUBE-2#הצג קבוצת יישומים של יתירות את כל מצבי הפגמים של קבוצה 1 מידע:        עדיפות זמן ריצה: [100] תקלות RG במצב RG: למעלה.                        מספר כולל של מתגים עקב תקלות:  0 מספר כולל של שינויים במצב 'למטה/למעלה' עקב תקלות: 0 מזהה קבוצה:1 שם קבוצה:LocalGateway-HA מצב מנהלי: אין מצב תפעולי מצטבר של כיבוי: למעלה  התפקיד שלי: תפקיד עמית במצב המתנה: נוכחות עמית פעיל: כן עמית תקשורת: כן התקדמות העמיתים התחילה: כן דומיין RF: מצב RF של btob-one: מצב RF של עמית פעיל: תפקיד במצב המתנה של פרוטוקול RG חם RG 1 ------------------: משא ומתן פעיל: עדיפות מופעלת: מצב פרוטוקול 100: מצב Ctrl Intf פעיל: עמית פעיל למעלה: כתובת 10.1.1.2, עדיפות 100, עמית standby intf Gi3: מספרי יומן רישום מקומיים:                 שינוי תפקיד פעיל: שינוי תפקיד אחד למצב המתנה: 1 השבת אירועים: rg במצב מטה 0, rg סגור 0 אירועי intf ctrl: למעלה 1, למטה 0, admin_down 0 אירועים נטענים מחדש: בקשה מקומית 0, בקשת עמית 0 הקשר מדיה RG עבור מצב RG 1 -------------------------- Ctx: מזהה פרוטוקול פעיל: סוג מדיה אחד: ממשק ברירת מחדל בקרה: שעון עצר נוכחי של GigabitEthernet3 : 3000 טיימר 'שלום' מוגדר: 3000, טיימר החזקה: טיימר Hello של עמית 10000: 3000, טיימר להחזיק עמית: 10000 סטטיסטיקה:             Pkts 1509, בתים 93558, HA Seq 0, מספר Seq 1509, אובדן Pkt 0 אימות לא הוגדר כשל אימות: 0 עמית טען מחדש: TX 0, RX 0 התפטרות: TX 0,‏ RX 0 עמית סטנדרטי: הווה. טיימר להמתנה: 10000 Pkts 61, בתים 2074, HA Seq 0, מספר Seq 69, אובדן Pkt 0 VCUBE-2#

קביעת התצורה של שער מקומי בשני רכיבי ה-CUBE

בתצורה לדוגמה, אנו משתמשים במידע ה-trunk הבא מ-Control Hub כדי לבנות את תצורת השער המקומי בשתי הפלטפורמות, VCUBE-1 ו-VCUBE-2. שם המשתמש והסיסמה עבור הגדרה זו הם כדלקמן:

  • שם משתמש: חוסיין1076_LGU

  • סיסמה: lOV12MEaZx

1

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

 LocalGateway#conf t LocalGateway(config)#key config-key password-encrypt Password123 LocalGateway(config)#הצפנת סיסמה aes

להלן תצורת השער המקומי שתחול על שתי הפלטפורמות בהתבסס על הפרמטרים של Control Hub המוצגים לעיל, שמירה וטעינה מחדש. פרטי כניסה של SIP Digest מ-Control Hub מסומנים ב-מודגשים.

 קביעת תצורה של מסוף הצפנה pki trustpoint dummyTp ביטול-בדיקה crl יציאה sip-ua הצפנה איתות ברירת מחדל trustpoint dummyTp cn-san-validate תעבורת שרת tcp tls v1.2 end קביעת תצורה של מסוף הצפנה pki trustpool ייבוא URL נקי ⁦http://www.cisco.com/security/pki/trs/ios_core.p7b⁩ end configuration of terminal voice service voip list trusted address ip list ipv4 x.x.x.x y.y.y.y.y.y exit allow-connections sip to sip media statistics media bulk-stats no supplementary-service sip handle-replaces fax protocol pass-through g711ulaw stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123! sip g729 annexb-all early-offer forged end configuration ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1" rule 10 request ANY sip-header SIP-header לשינוי """;otg=גרביונים1076_lgu>" כלל 30 בקש כל שינוי P-Asserted-Identity header sip "sips:(.*)" "sip:\1" קודק מחלקה קולית 99 עדיפות קודק 1 g711ulaw העדפת קודק 2 g711ulaw יציאה מחלקה קולית srtp-crypto 200 הצפנה 1 AES_ס"מ_128 ש"ח_המק_שח1_80 יציאה ממעמד קולי שימוש בסטאן 200 שימוש בסטאן נתוני זרימה דרך חומת אש יציאה דייר מחלקה קולית 200 רשם dns:40462196.cisco-bcld.com sips של הערכה יפוג 240 יחס רענון 50 מספר פרטי כניסה tcp tls חוסיין5091_הלהט"ב שם משתמש Hussain1076_סיסמת LGU 0 לOV12MEaZx שם משתמש לאימות Broadworks חוסיין5091_הלהט"ב סיסמה 0 לOV12MEaZx שם משתמש של אימות BroadWorks בתחום חוסיין5091_הלהט"ב סיסמה 0 לOV12MEaZx ממלכה 40462196.cisco-bcld.com אין שרת sip-מזהה-צד מרוחק dns:40462196.cisco-bcld.com חיבור-שימוש חוזר srtp-הצפנה 200 תעבורת הפעלה tcp tls url sips error-passthru asserted-id pai bind control source-interface GigabitEthernet1 bind media source-interface GigabitEthernet1 no pass-thru content custom-sdp sip-profiles 200 יוצא-proxy כתובת: la01.sipconnect-us10.cisco-bcld.com פרטיות-מדיניות passthru דייר מחלקה קולית 100 הפעלה תעבורה udp url sip error-passthru bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class dtg=חוסיין1076.lgu קול עמית חיוג 101 תיאור עמית חיוג יוצא לתבנית יעד IP PSTN BAD.BAD פרוטוקול הפעלה SIPV2 יעד IPV4:198.18.133.3 קודק מחלקה קולית 99 דייר sip מחלקה קולית 100 dtmf-relay rtp-nte no vad dial-peer 201 תיאור עמית חיוג יוצא לתבנית יעד של Webex Calling BAD.BAD פרוטוקול הפעלה sipv2 יעד הפעלה sip-server יעד קודק קולי 99 מחלקה קולית stun-שימוש 200 ללא דייר sip מחלקה קולית localhost דייר sip מחלקה קולית 200 dtmf-relay rtp-nte srtp no vad class voice dpg 100 תיאור WebexCalling נכנס(DP200) ל IP PSTN(DP101) עמית חיוג 101 העדפה IP PSTN (DP100) ל Webex Calling(DP201) עמית חיוג 201 העדפה עמית חיוג 1 קול עמית חיוג 100 העדפה עמית חיוג נכנס מ-ip pstn פרוטוקול הפעלה sipv2 יעד dpg 200 תיאור עמית חיוג נכנס מ-Webex Calling פרוטוקול הפעלה sipv2 300 תיאור עמית חיוג נכנס מ-Webex Calling פרוטוקול הפעלה sipv2 200 תיאור עמית חיוג נכנס מ-Webex Calling פרוטוקול הפעלה sipv2 יעד dpg 100 בקשת uri נכנסת 200 קו

כדי להציג את פלט פקודת ההצגה, ביצענו טעינה מחדש של VCUBE-2 ואחריו VCUBE-1, דבר שהופך את VCUBE-1 לרכיב ה-CUBE במצב המתנה ואת VCUBE-2 לרכיב ה-CUBE הפעיל

2

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

show redundancy application group 1

הצג מצב רישום SipUa 

 VCUBE-1#הצג קבוצת יישום יתירות 1 מזהה קבוצה:1 שם קבוצה:LocalGateway-HA Administrative State: אין מצב תפעולי מצטבר של כיבוי: למעלה  התפקיד שלי: תפקיד עמית במצב המתנה: נוכחות עמית פעיל: כן עמית תקשורת: כן התקדמות העמיתים התחילה: כן דומיין RF: מצב RF של btob-one: מצב המתנה של RF של עמית חם: VCUBE פעיל-1#הצג מצב רישום sip-ua VCUBE-1#

 VCUBE-2#הצג קבוצת יישום יתירות 1 מזהה קבוצה:1 שם קבוצה:LocalGateway-HA Administrative State: מצב תפעולי מצטבר ללא כיבוי: למעלה התפקיד שלי: תפקיד עמית פעיל: נוכחות עמית במצב: כן עמית תקשורת: כן התקדמות העמיתים התחילה: כן דומיין RF: מצב RF של btob-one: מצב RF של עמית פעיל: במצב המתנה VCUBE-2#הצג מצב רישום sip-ua : 200 --------------------מרשמים  1 --------------------- עמית קו פג(שניות) reg survival P-Associ-URI ============================== ==============================================================================================================================================================================================================================================================================================_LGU -1 48 כן רגיל VCUBE-2#

מהפלט שלעיל, תוכל לראות ש-VCUBE-2 הוא ה-LGW הפעיל ששומר על הרישום עם SBC לגישה של WeBEX Calling, בעוד שהפלט של "SHOW SIP-UA REGISTER STATUS" ריק ב-VCUBE-1

3

כעת הפעל את תהליכי איתור הבאגים הבאים ב-VCUBE-1

 VCUBE-1#debug ccsip non-call SIP מתוך תיבת הדו-שיח מופעל VCUBE-1#debug ccsip info SIP פרטי שיחה SIP מופעל VCUBE-1#debug message ccsip debug

4

בצע הדמיה של יתירות כשל על-ידי הנפקת הפקודה הבאה ב-LGW הפעיל, VCUBE-2 במקרה זה.

 VCUBE-2#יתירות טעינה מחדש של קבוצה 1 עצמית

מעבר מה-LGW הפעיל ל-LGW שבמצב המתנה מתרחש גם בתרחיש הבא, מלבד ה-CLI המפורט לעיל

  • כאשר הנתב הפעיל נטען מחדש

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

  • כאשר ממשק RG מוגדר כלשהו של הנתב הפעיל הוא כיבוי שעבורו מופעל מעקב

5

בדוק אם VCUBE-1 נרשם ב-SBC לגישה של Webex Calling. VCUBE-2 היה נטען מחדש עד עכשיו.

 VCUBE-1#הצג דייר מצב רישום sip-ua: 200 --------------------מרשמים  1 --------------------- עמית קו פג (שניות) reg survival P-Associ-URI ============================== ============================================================================================================================================================================================================================================================================================== חוסיין5091_LGU -1 56 כן נורמלי מס' vcube-1

VCUBE-1 הוא עכשיו ה-LGW הפעיל.

6

הסתכל ביומן איתור הבאגים הרלוונטי ב-VCUBE-1 ששולח SIP REGISTER ל-Webex Calling דרך ה-IP הווירטואלי ומקבל תגובת ‎200 OK.

VCUBE

 -1#show log ינו 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: פג תוקף מזהה RG 1 Hello Time.9  בינואר 18:37:24.771: %_RG PROTCOL-5-rolechange: שינוי תפקיד מזהה RG 1 מ'מצב המתנה' ל'פעיל' 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: מעבר, ממצב המתנה_חם למצב פעיל. 9 בינואר 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/מידע/info/4096/sip_ha_notify_active_role_event: התקבל הודעה על אירוע תפקיד פעיל ב-9 בינואר 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: נשלח: SIP רשום: 40462196.cisco-bcld.com:5061 SIP/2.0 באמצעות: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 מ: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 עד: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> תאריך: חמישי, 09 ינואר 2020 18:37:24 GMT שיחה: FFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 סוכן משתמש: Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: חותמת זמן 70: 1578595044 קראק: 2 איש קשר להרשמה: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> פג: 240 נתמך: אורך תוכן הנתיב: 0 

ינו 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg: התקבל: SIP/2.0 401 לא מורשה דרך: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 מ: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 עד: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 תאריך: חמישי, 09 ינואר 2020 18:37:24 GMT שיחה: FFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 חותמת זמן: 1578595044 קראק: 2 רישום WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",ALGORITHM=MD5 תוכן-אורך: 0 

ינו 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: נשלח: רשום sip:40462196.cisco-bcld.com:5061 SIP/2.0 באמצעות: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC מ: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 עד: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> תאריך: חמישי, 09 ינואר 2020 18:37:25 GMT שיחה מזהה: FFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 סוכן משתמש:Cisco-SIPGateway/IOS-16.12.02 מקס-Forwards: חותמת זמן 70: 1578595045 קראק: 3 איש קשר להרשמה: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> פג: 240 נתמך: הרשאת נתיב: תקציר username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 אורך תוכן: 0 

ינו 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:  התקבל: SIP/2.0 200 OK באמצעות: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 מ: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 אל: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 שיחה-מזהה: FFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 חותמת זמן: 1578595045 קראק: 3 איש קשר להרשמה: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-Events: פרטי שיחה, תפיסת קו, תיבת דו-שיח, סיכום הודעות, as-feature-event, x-broadworks-hoteling, x-broadworks-call-center-status, אורך תוכן שיחת ועידה: 0