De bază

Cerințe preliminare

Înainte de a implementa Cisco Unified Border Element (CUBE) High Availability (HA) ca gateway local pentru Webex Calling, asigurați-vă că înțelegeți în profunzime următoarele concepte:

Instrucțiunile de configurare furnizate în acest articol presupun o platformă de gateway local dedicată, fără nicio configurație de voce existentă. Dacă o implementare existentă la nivel de întreprindere CUBE este modificată pentru a utiliza și funcția gateway local pentru Cisco Webex Calling, acordați o atenție deosebită configurației aplicate pentru a vă asigura că fluxurile de apeluri și funcționalitățile existente nu sunt întrerupte și asigurați-vă că respectați cerințele de proiectare CUBE HA.

Componente hardware și software

CUBE HA ca gateway local necesită IOS-XE versiunea 17.9.1 sau o versiune ulterioară și o platformă pe care sunt acceptate atât funcții CUBE HA, cât și LGW.

Comenzile de afișare și jurnalele din acest articol se bazează pe versiunea software minimă a Cisco IOS-XE 17.9.1 implementată pe un vCUBE (CSR 8000v).

Material de referință

Iată câteva ghiduri detaliate de configurare CUBE HA pentru diferite platforme:

Prezentare generală a soluției Webex Calling

Cisco Webex Calling este o ofertă de colaborare care oferă o alternativă bazată pe cloud cu entități găzduite multiple la serviciul de telefonie PBX local cu mai multe opțiuni PSTN pentru clienți.

Implementarea gateway-ului local (reprezentată mai jos) este punctul central al acestui articol. Trunchiul gateway local (PSTN local) din Webex Calling permite conexiunea la un serviciu PSTN deținut de client. De asemenea, oferă conectivitate la o implementare IP PBX locală, cum ar fi Cisco Unified CM. Toate comunicările către și de la cloud sunt securizate utilizând transportul TLS pentru SIP și SRTP pentru media.

Implementare PSTN locală la nivel local pentru gateway

Figura de mai jos afișează o implementare Webex Calling fără niciun IP PBX existent și se aplică pentru o implementare unică sau pentru o implementare multisite. Configurația descrisă în acest articol se bazează pe această implementare.

Implementare Webex Calling fără IP PBX

Nivelul 2 Redundanță Box-to-Box

Redundanța CUBE HA stratul 2 box-to-box utilizează protocolul de infrastructură al Grupului de redundanță (RG) pentru a forma o pereche activă/standby de routere. Această pereche are aceeași adresă IP virtuală (VIP) pe interfețele lor respective și schimbă continuu mesaje de stare. Informațiile sesiunii CUBE sunt centrate pe verificarea perechii de routere care permit routerului în așteptare să preia imediat toate responsabilitățile de procesare a apelurilor CUBE în cazul în care routerul activ iese din funcțiune, ceea ce duce la păstrarea statică a semnalizării și a fișierelor media.

Verificarea orientării este limitată la apelurile conectate cu pachete media. Apelurile aflate în tranzit nu sunt verificate punctual (de exemplu, o stare de încercare sau de sonerie).

În acest articol, CUBE HA se va referi la redundanța CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) pentru păstrarea statatoare a apelurilor.

Începând cu IOS-XE 17.9.1, CUBE HA poate fi implementat ca gateway local pentru implementările de trunchiuri Cisco Webex Calling (PSTN local). Acest articol va discuta considerațiile de proiectare și configurațiile. Figura afișează o configurație CUBE HA tipică ca gateway local pentru o implementare de trunchi Cisco Webex Calling.

O configurare CUBE HA tipică ca gateway local pentru implementarea unui trunchi Cisco Webex Calling

Componenta infra a grupului de redundanță

Componenta Infra a Grupului de Redundanță (RG) oferă suport pentru infrastructura de comunicare box-to-box între cele două CUBE-uri și negociază starea finală de redundanță stabilă. Această componentă oferă, de asemenea:

  • Un protocol asemănător cu HSRP, care negociază starea finală de redundanță pentru fiecare router prin schimbul de mesaje keepalive și de salut între cele două CUBE-uri (prin interfața de control)—GigabitEthernet3 în figura de mai sus.

  • Un mecanism de transport pentru verificarea semnalizării și a stării media pentru fiecare apel de la routerul activ la cel în așteptare (prin interfața de date)—GigabitEthernet3 în figura de mai sus.

  • Configurarea şi gestionarea interfeţei virtuale IP (VIP) pentru interfeţele de trafic (mai multe interfeţe de trafic pot fi configurate folosind acelaşi grup RG) – GigabitEthernet 1 și 2 sunt considerate interfețe de trafic.

Această componentă RG trebuie să fie configurată în mod specific pentru a accepta vocea B2B HA.

Gestionarea adreselor IP virtuale (VIP), atât pentru semnalizare, cât și pentru media

B2B HA se bazează pe VIP pentru a obține redundanță. Interfețele fizice VIP și asociate de pe ambele CUBE-uri din perechea CUBE HA trebuie să se afle pe aceeași subrețea LAN. Configurarea VIP și legarea interfeței VIP la o anumită aplicație de voce (SIP) sunt obligatorii pentru suportul de voce B2B HA. Dispozitivele externe, cum ar fi Unified CM, accesul Webex Calling la SBC, furnizorul de servicii sau proxy, utilizează VIP ca adresă IP de destinație pentru apelurile care trec prin routerele CUBE HA. Prin urmare, din punctul de vedere al Webex Calling, perechea CUBE HA acționează ca un singur gateway local.

Semnalizarea apelurilor și informațiile sesiunii RTP ale apelurilor stabilite sunt direcționate de la routerul activ la routerul în așteptare. Când routerul Activ coboară, routerul În așteptare preia și continuă să redirecționeze fluxul RTP care a fost rutat anterior de primul router.

Apelurile aflate în stare tranzitorie în momentul comutării automate nu vor fi păstrate după comutare. De exemplu, apelurile care nu sunt încă pe deplin stabilite sau care sunt în curs de modificare cu o funcție de transfer sau așteptare. Apelurile stabilite pot fi deconectate după comutare.

Există următoarele cerințe pentru utilizarea CUBE HA ca gateway local pentru reluarea statică a apelurilor:

  • CUBE HA nu poate avea interfețe TDM sau analogice localizate în comun

  • Gig1 și Gig2 sunt denumite interfețe de trafic (SIP/RTP), iar Gig3 este interfața de control/date a grupului de redundanță (RG)

  • Nu mai mult de 2 perechi HA CUBE pot fi plasate în același nivel 2 domeniu, unul cu ID-ul de grup 1 și celălalt cu ID-ul grupului 2. Dacă configurați 2 HA perechi cu același id de grup, interfețele de control/date RG trebuie să aparțină diferitelor domenii din stratul 2 (vlan, comutator separat)

  • Canalul de port este acceptat atât pentru Controlul RG/interfețele de date, cât și pentru traficul

  • Toate semnalizarea/fișierele media provin de la/la adresa IP virtuală

  • Ori de câte ori o platformă este reîncărcată într-o relație CUBE-HA, aceasta se încarcă întotdeauna în starea Standby

  • Adresa inferioară pentru toate interfețele (Gig1, Gig2, Gig3) trebuie să fie pe aceeași platformă

  • Identificator de interfață de redundanță, rii trebuie să fie unic pentru o combinație de perechi/interfață pe același nivel 2

  • Configurația pe ambele CUBE-uri trebuie să fie identică, inclusiv configurația fizică, și trebuie să ruleze pe același tip de platformă și versiune IOS-XE

  • Interfețele loopback nu pot fi utilizate atât de strâns, deoarece sunt întotdeauna în poziție

  • Interfețele pentru trafic multiplu (SIP/RTP) (Gig1, Gig2) necesită configurarea urmăririi interfeței

  • CUBE-HA nu este acceptat printr-o conexiune prin cablu încrucișat pentru linkul RG-control/date (Gig3)

  • Ambele platforme trebuie să fie identice și să fie conectate printr-un Switch fizic pe toate interfețele la fel pentru ca CUBE HA să funcționeze, adică GE0/0/0 din CUBE-1 și CUBE-2 trebuie să se termine pe același switch și așa mai departe.

  • Nu poate avea WAN închis pe CUBE direct sau HA de date pe oricare parte

  • Ambele elemente active/în așteptare trebuie să fie în același centru de date

  • Este obligatorie utilizarea unei interfețe L3 separate pentru redundanță (control RG/date, Gig3). De exemplu, interfața utilizată pentru trafic nu poate fi utilizată pentru conexiunile HA și indicațiile de verificare

  • La reluarea în caz de nereușită, CUBE-ul activ anterior trece printr-o reîncărcare prin design, păstrând semnalizarea și conținutul media

Configurați redundanța pe ambele CUBE-uri

Trebuie să configurați nivelul 2 de redundanță box-to-box pe ambele CUBE-uri destinate a fi utilizate într-o pereche HA pentru a aduce IP-uri virtuale.

O configurare CUBE HA tipică ca gateway local pentru implementarea unui trunchi Cisco Webex Calling

1

Configurați urmărirea interfeței la nivel global pentru a urmări starea interfeței.

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 este utilizat în RG pentru a urmări starea interfeței de trafic de voce, astfel încât traseul activ își va îndeplini rolul activ după ce interfața de trafic este în jos.

2

Configurați un RG pentru utilizarea cu VoIP HA în submodul de redundanță a aplicației.

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

Iată o explicație a câmpurilor utilizate în această configurație:

  • redundanță—Intră în modul de redundanță

  • redundanța aplicației- Intră în modul de configurare a redundanței aplicației

  • grup – Intră în modul de configurare a grupului de aplicații de redundanță

  • nume LocalGateway-HA—Definește numele grupului RG

  • Pragul de reluare automată a priorității 100 75- Specifică pragurile de prioritate inițială și de reluare automată pentru un RG

  • întârzierea timerilor 30 reîncărcare 60- Configurează cele două ori pentru întârziere și reîncărcare

    • Temporizator de întârziere, care este timpul necesar pentru a întârzia inițializarea grupului RG și negocierea rolului după ce interfața apare – implicit 30 de secunde. Intervalul este 0-10000 de secunde

    • Reîncărcare — aceasta este perioada de timp necesară pentru a întârzia inițializarea grupului RG și negocierea rolului după o reîncărcare - Implicit 60 de secunde. Intervalul este 0-10000 de secunde

    • Cronometre implicite sunt recomandate, deși aceste cronometre pot fi ajustate pentru a se adapta la orice întârziere suplimentară de convergență a rețelei care poate apărea în timpul încărcării/reîncărcării routerelor, pentru a garanta că negocierea protocolului RG are loc după ce rutarea din rețea a convertit la un punct stabil. De exemplu, dacă se observă după reluarea în caz de nereușită că este nevoie de până la 20 secunde pentru ca noul STANDBY să vadă primul pachet RG HELLO de la noul ACTIVE, atunci cronometrele trebuie ajustate la „întârziere cronometru 60 reîncărcare 120” pentru a calcula factorul în această întârziere.

  • control GigabitEthernet3 protocol 1— Configurează interfața utilizată pentru a face schimb de mesaje keepalive și de salut între cele două CUBE-uri și specifică instanța de protocol care va fi atașată la o interfață de control și intră în modul de configurare a protocolului aplicației de redundanță

  • date GigabitEthernet3- Configurează interfața utilizată pentru indicarea traficului de date

  • track- Urmărirea grupului RG al interfețelor

  • protocolul 1—Specifică instanța de protocol care va fi atașată la o interfață de control și intră în modul de configurare a protocolului aplicației de redundanță

  • cronometre hellotime 3 holdtime 10- Configurează cele două cronometre pentru hellotime și holdtime:

    • Timp de răspuns — Interval între mesajele de salut succesive – Implicit 3 secunde. Intervalul este de 250 milisecunde - 254 de secunde

    • Holdtime — intervalul dintre primirea unui mesaj de salut și prezumția că routerul de trimitere a eșuat. Această durată trebuie să fie mai mare decât timpul de salut – implicit 10 secunde. Intervalul este de 750 milisecunde-255 de secunde

      Vă recomandăm să configurați cronometrul holdtime pentru a fi de cel puțin 3 ori valoarea cronometrului hellotime.

3

Activați redundanța box-to-box pentru aplicația CUBE. Configurați RG de la pasul anterior de la voice service voip. Acest lucru permite aplicației CUBE să controleze procesul de redundanță.

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

redundanță-grup 1—Adăugarea și eliminarea acestei comenzi necesită o reîncărcare pentru ca configurația actualizată să fie aplicată. Vom reîncărca platformele după ce a fost aplicată toată configurația.

4

Configurați interfețele Gig1 și Gig2 cu IP-urile lor virtuale respective, după cum se arată mai jos și aplicați identificatorul de interfață de redundanță (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

Iată o explicație a câmpurilor utilizate în această configurație:

  • re redundanță—Configurează identificatorul interfeței de redundanță pentru grupul de redundanță. Necesar pentru generarea unei adrese MAC virtuale (VMAC). Aceeași valoare ID rii trebuie utilizată pe interfața fiecărui router (ACTIV/STANDBY) care are același VIP.

    Dacă există mai multe perechi B2B pe aceeași rețea LAN, fiecare pereche TREBUIE SĂ aibă ID-uri unice ale rii pe interfețele respective (pentru a preveni coliziunea). Comanda afișare grup de aplicații de redundanță toate trebuie să indice informațiile corecte locale și de la egal la egal.

  • Grupul de redundanță 1- Asociază interfața cu grupul de redundanță creat la Pasul 2 de mai sus. Configurați grupul RG, precum și VIP-ul atribuit acestei interfețe fizice.

    Este obligatoriu să utilizați o interfață separată pentru redundanță, adică interfața utilizată pentru traficul de voce nu poate fi utilizată ca interfață de control și de date specificată la pasul 2 de mai sus. În acest exemplu, interfața Gigabit 3 este utilizată pentru controlul/datele RG

5

Salvați configurația primului CUBE și reîncărcați-o.

Ultima platformă pentru reîncărcarea este întotdeauna în așteptare.

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

După ce VCUBE-1 se încarcă complet, salvați configurația VCUBE-2 și reîncărcați-o.

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]

6

Verificați dacă configurația box-to-box funcționează conform așteptărilor. Rezultatele relevante sunt evidențiate cu aldine.

Am reîncărcat VCUBE-2 ultima și în conformitate cu considerațiile de proiectare; platforma pentru a reîncărca ultima va fi întotdeauna În așteptare. 


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#

Apoi, continuați cu configurarea gateway-ului local (pe bază de înregistrare sau pe bază de certificat) pe ambele HA CUBE-uri. Consultați Configurați gateway-ul local pe Cisco IOS XE pentru Webex Calling.