יסודות

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

לפני פריסת 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—Enters redundancy mode

  • application redundancy—Enters application redundancy configuration mode

  • group—Enters redundancy application group configuration mode

  • name LocalGateway-HA—Defines the name of the RG group

  • priority 100 failover threshold 75—Specifies the initial priority and failover thresholds for an RG

  • timers delay 30 reload 60—Configures the two times for delay and reload

    • טיימר עיכוב שהוא משך הזמן לעיכוב האתחול והמשא ומתן על התפקידים של קבוצת 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—Configures the interface used to exchange keepalive and hello messages between the two CUBEs, and specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • data GigabitEthernet3—Configures the interface used for checkpointing of data traffic

  • track—RG group tracking of interfaces

  • protocol 1—Specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • timers hellotime 3 holdtime 10—Configures the two timers for hellotime and holdtime:

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

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

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

3

הפעל יתירות מקופסה לקופסה עבור יישום CUBE. Configure the RG from the previous step under 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—Adding and removing this command requires a reload for the updated configuration to take effect. נטען מחדש את הפלטפורמות לאחר שהתצורה תוחל במלואה.

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—Configures the redundancy interface identifier for the redundancy group. נדרש ליצירת כתובת MAC וירטואלית (VMAC). יש להשתמש באותו ערך מזהה rii בממשק של כל נתב (פעיל/במצב המתנה) בעל אותו VIP.

    If there is more than one B2B pair on the same LAN, each pair MUST have unique rii IDs on their respective interfaces (to prevent collision). ‘show redundancy application group all’ should indicate the correct local and peer information.

  • redundancy group 1—Associates the interface with the redundancy group created in Step 2 above. קבע את התצורה של קבוצת 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 המוצגים לעיל, שמירה וטעינה מחדש. SIP Digest credentials from Control Hub are highlighted in bold.

 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

show sip-ua register status 

 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#

From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in 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