יסודות

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

לפני פריסת 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 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit


VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

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

2

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

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy

VCUBE-1(config-red)#application redundancy

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

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

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

VCUBE-1(config-red-app-grp)#exit

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

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

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

VCUBE-1(config-red)#exit

VCUBE-1(config)#

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

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

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

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

VCUBE-2(config-red-app-grp)#exit

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

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#exit

VCUBE-2(config)#

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

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

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

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

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

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

  • timers 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, וציון מופע הפרוטוקול שיצורף לממשק בקרה, וכניסה למצב תצורה של פרוטוקול יישום יתירות

  • data 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 מהשלב הקודם תחת voice service voip. פעולה זו מאפשרת ליישום CUBE לשלוט בתהליך היתירות. 

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

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


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#voice service voip

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


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-2(config-voi-serv)# exit

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

4

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

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# redundancy rii 1

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

VCUBE-1(config-if)# redundancy rii 2

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

VCUBE-2(config-if)# redundancy rii 1

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

VCUBE-2(config-if)# redundancy rii 2

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

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

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

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

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

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

5

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

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

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

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

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]
6

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

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


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

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

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

  • שם משתמש: Hussain1076_LGU

  • סיסמה: lOV12MEaZx

1

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


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes

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


configure terminal
crypto pki trustpoint dummyTp
revocation-check crl
exit
sip-ua
crypto signaling default trustpoint dummyTp cn-san-validate server
transport tcp tls v1.2
end


configure terminal
crypto pki trustpool import clean url
http://www.cisco.com/security/pki/trs/ios_core.p7b
end


configure terminal
voice service voip
  ip address trusted list
    ipv4 x.x.x.x y.y.y.y
    exit
   allow-connections sip to sip
  media statistics
  media bulk-stats
  no supplementary-service sip refer
  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 forced
    end


configure terminal
voice class sip-profiles 200
  rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)"
"sip:\1"
  rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 12 request ANY sip-header Contact modify "<sips:(.*)>"
"<sip:\1;transport=tls>"
  rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 15 response ANY sip-header Contact modify "<sips:(.*)"
"<sip:\1"
  rule 20 request ANY sip-header From modify ">"
";otg=hussain1076_lgu>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240
refresh-ratio 50 tcp tls
  credentials number Hussain5091_LGU username Hussain1076_LGU
password 0 lOV12MEaZx realm Broadworks 
  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm BroadWorks

  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport 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
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
  privacy-policy passthru


voice class tenant 100
  session transport udp
  url sip
  error-passthru
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp

voice class tenant 300
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp
  

voice class uri 100 sip
 host ipv4:198.18.133.3

voice class uri 200 sip
 pattern dtg=hussain1076.lgu



dial-peer voice 101 voip
 description Outgoing dial-peer to IP PSTN
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:198.18.133.3
 voice-class codec 99
 voice-class sip tenant 100
 dtmf-relay rtp-nte
 no vad

dial-peer voice 201 voip
 description Outgoing dial-peer to Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 voice-class codec 99
 voice-class stun-usage 200
 no voice-class sip localhost
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad


voice class dpg 100
 description Incoming WebexCalling(DP200) to IP PSTN(DP101)
 dial-peer 101 preference 1

voice class dpg 200
 description Incoming IP PSTN(DP100) to Webex Calling(DP201)
 dial-peer 201 preference 1





dial-peer voice 100 voip
 desription Incoming dial-peer from IP PSTN
 session protocol sipv2
 destination dpg 200
 incoming uri via 100
 voice-class codec 99
 voice-class sip tenant 300
 dtmf-relay rtp-nte
 no vad

dial-peer voice 200 voip
 description Incoming dial-peer from Webex Calling
 session protocol sipv2
 destination dpg 100
 incoming uri request 200
 voice-class codec 99
 voice-class stun-usage 200
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad

end

copy run start

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

2

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

show redundancy application group 1

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


VCUBE-1#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: Standby
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: STANDBY HOT
         Peer RF state: ACTIVE

VCUBE-1#show sip-ua register status
VCUBE-1#


VCUBE-2#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STATUS
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

VCUBE-2#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          48          yes normal
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 Out-of-Dialog tracing is enabled
VCUBE-1#debug ccsip info
SIP Call info tracing is enabled
VCUBE-1#debug ccsip message
4

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


VCUBE-2#redundancy application reload group 1 self

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

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

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

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

5

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


              VCUBE-1#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          56          yes normal
VCUBE-1#

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

6

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


VCUBE-1#show log

Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired.
Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active
Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state.
Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event

Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent: Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595044
CSeq: 2 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Content-Length: 0


Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595044
CSeq: 2 REGISTER
WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5
Content-Length: 0


Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:25 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent:Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001
Content-Length: 0


Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5
Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference
Content-Length: 0