במאמר זה
יסודות
הגדר יתירות בשני ה- CUBE
הטמעת זמינות גבוהה של CUBE כשער מקומי
list-menuבמאמר זה
list-menuמשוב?

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

יסודות

תנאים מוקדמים

לפני פריסת Cisco Unified Border Element (CUBE) זמינות גבוהה (HA) כש ער מקומי עבורWebex Calling, ודא שיש לך הבנה מעמיקה של המוש גים הבאים:

הנחיות התצורה המסופקות במאמר זה מניחות פלטפורמת שער מקומית ייעודית ללא תצורה קולית קיימת. אם פריסה ארגונית קיימת של 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 לפלטפורמות שונות:

Webex Callingסקירת פתרון

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

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

Local Gateway premises-based PSTN deployment

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

Webex Calling deployment without IP PBX

יתירות קופסה-לתיבה בשכבה 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 תא מטען.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

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

רכיב 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 וירטואליות.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

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

Track 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)#

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

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

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

  • קבוצה —נכנס למצב תצורה של קבוצת יישומי יתירות

  • שם מקומגטווי-הא - מגדיר את שם קבוצת RG

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

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

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

    • טעינה מחדש - זהו פרק הזמן לעיכוב אתחול קבוצת RG ומשא ומתן תפקידים לאחר טעינה מחדש - ברירת מחדל 60 שניות. טווח הוא 0-10000 שניות

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

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

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

  • מסלול —מעקב קבוצתי RG של ממשקים

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

  • טיימרים hellotime 3 זמן המתנה 10 - מגדיר את שני הטיימרים לזמן הלוי וזמן המתנה:

    • Hellotime- מרווח בין הודעות שלום רצופות - ברירת מחדל 3 שניות. הטווח הוא 250 אלפיות -254 שניות

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

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

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

קבוצת יתירות 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

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

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

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

  • קבוצת יתירות 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 מתחיל לחלוטין, שמור את התצורה של VCU BE-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#

לאחר מכן, המשך בתצורת השער המקומי (מבוסס רישום או מבוסס אישור) בשני ה- HA CUBEs. ראה ק ביעת תצורה של שער מקומי ב Cisco IOS - XE עבור Webex Calling.

האם המאמר הועיל לך?
האם המאמר הועיל לך?