În acest articol
Fundamente
Configurați redundanța pe ambele CUBE
Implementați disponibilitatea ridicată CUBE ca gateway local
list-menuÎn acest articol
list-menuFeedback?

Local Gateway (LGW) este soluția exclusivă pentru furnizarea accesului PSTN local clienților Cisco Webex Calling. Acest document vă ghidează în configurarea unui gateway local utilizând CUBE de înaltă disponibilitate, cu CUBE active sau de așteptare pentru a asigura failover-ul de stare al apelurilor active.

Fundamente

Cerințe preliminare

Înainte de a implementa Cisco Unified Border Element (CUBE) High Availability (HA) ca gateway local pentruWebex Calling, asigurați-vă că aveți o înțelegere aprofundată a următoarelor concepte:

Instrucțiunile de configurare furnizate în acest articol presupun o platformă dedicată de gateway local fără configurație vocală existentă. Dacă o implementare corporativă CUBE existentă este modificată pentru a utiliza și funcția gateway local pentruCisco 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ă versiunea IOS-XE 17.9.1 sau o versiune ulterioară și o platformă pe care sunt acceptate atât funcțiile CUBE HA, cât și LGW.

Comenzile de prezentare și jurnalele din acest articol se bazează pe versiunea minimă de software 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 diverse platforme:

Webex CallingPrezentare generală a soluției

Cisco Webex Callingeste o ofertă de colaborare care oferă o alternativă bazată pe cloud cu mai mulți chiriași la serviciul de telefonie PBX on-premise, 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 bazat pe premise) Webex Calling permite conectivitatea 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 comunicațiile către și dinspre cloud sunt securizate folosind transportul TLS pentru SIP și SRTP pentru media.

Local Gateway premises-based PSTN deployment

Figura de mai jos afișează o Webex Calling implementare fără niciun PBX IP existent și se aplică unei implementări unice sau cu mai multe site-uri. Configurația prezentată în acest articol se bazează pe această implementare.

Webex Calling deployment without IP PBX

Redundanță de la cutie la cutie de nivel 2

Redundanța cube HA layer 2 box-to-box utilizează protocolul de infrastructură Redundancy Group (RG) pentru a forma o pereche de routere activă/standby. Această pereche partajează aceeași adresă IP virtuală (VIP) în interfețele respective și schimbă continuu mesaje de stare. Informațiile despre sesiunea CUBE sunt verificate pe perechea de routere, permițând routerului standby să preia imediat toate responsabilitățile de procesare a apelurilor CUBE dacă routerul activ iese din funcțiune, ceea ce duce la păstrarea stării de stare a semnalării și a mediilor media.

Indicarea verificării este limitată la apelurile conectate cu pachete media. Apelurile aflate în tranzit nu sunt indicate (de exemplu, o stare de încercare sau de apel).

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

Începând cu IOS-XE 17.9.1, CUBE HA poate fi implementat ca un gateway local pentru implementări Cisco Webex Calling trunchi (PSTN bazat pe premise). Acest articol va discuta considerente de proiectare și configurații. Figura afișează o configurare tipică CUBE HA ca gateway local pentru o implementare Cisco Webex Calling trunchiului.

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

Componenta infra a grupului de redundanță

Componenta Infra Redundancy Group (RG) asigură suportul infrastructurii de comunicații box-to-box între cele două CUBE și negociază starea finală de redundanță stabilă. Această componentă oferă, de asemenea:

  • Un protocol asemănător HSRP care negociază starea finală de redundanță pentru fiecare router prin schimbul de mesaje keepalive și hello între cele două CUBE (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 routerul de așteptare (prin interfața de date) —GigabiteThernet3 în figura de mai sus.

  • Configurarea și gestionarea interfeței IP virtuale (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 configurată special pentru a sprijini vocea B2B HA.

Gestionarea adresei 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 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 vocală (SIP) sunt obligatorii pentru suportul vocal B2B HA. Dispozitivele externeUnified CM, cum ar fi, Webex Calling acces SBC, furnizor de servicii sau proxy, utilizează VIP ca adresă IP de destinație pentru apelurile care traversează routerele CUBE HA. Prin urmare, din Webex Calling punct de vedere, perechile CUBE HA acționează ca un singur gateway local.

Semnalizarea apelurilor și informațiile despre sesiunea RTP ale apelurilor stabilite sunt verificate de la routerul activ la routerul de așteptare. Când routerul activ se oprește, routerul Standby preia controlul și continuă să transmită fluxul RTP care a fost direcționat anterior de primul router.

Apelurile aflate într-o stare tranzitorie în momentul failover nu vor fi păstrate după comutare. De exemplu, apelurile care nu sunt încă pe deplin stabilite sau sunt în curs de modificare cu o funcție de transfer sau reținere. Apelurile stabilite pot fi deconectate după comutare.

Există următoarele cerințe pentru utilizarea CUBE HA ca gateway local pentru failover-ul de stare a apelurilor:

  • CUBE HA nu poate avea interfețe TDM sau analogice co-localizate

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

  • Nu mai mult de 2 perechi CUBE HA pot fi plasate în același domeniu strat 2, una cu identificatorul grupului 1 și cealaltă cu grupul id 2. Dacă configurați 2 perechi HA cu același id de grup, interfețele RG Control/Data trebuie să aparțină diferitelor domenii de nivel 2 (vlan, comutator separat)

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

  • Toate semnalule/mediile sunt furnizate de la/la adresa IP virtuală

  • Ori de câte ori o platformă este reîncărcată într-o relație CUBE-HA, aceasta pornește întotdeauna ca Standby

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

  • Identificatorul interfeței de redundanță, rii ar trebui să fie unic pentru o combinație perechi/interfață pe același strat 2

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

  • Interfețele Loopback nu pot fi utilizate ca bind, deoarece sunt întotdeauna în funcțiune

  • Interfețele de 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 legătura RG-Control/Data Link (Gig3)

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

  • Nu se poate termina WAN direct pe CUBE-uri sau Data HA pe ambele părți

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

  • Este obligatorie utilizarea unei interfețe L3 separate pentru redundanță (Control/date RG, Gig3). adică interfața utilizată pentru trafic nu poate fi utilizată pentru păstrarea HA și pentru punctajul de control

  • La failover, CUBE activ anterior trece printr-o reîncărcare prin proiectare, păstrând semnalizarea și mediile

Configurați redundanța pe ambele CUBE

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

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

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 traficului vocal, astfel încât ruta activă își va avea rolul activ după ce interfața de trafic este întreruptă.

2

Configurați un RG pentru utilizare cu VoIP HA în sub-modul 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 redund anță

  • redundanță aplicație-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

  • prioritate 100 pragul de failover 75 — Specifică prioritatea inițială și pragurile de failover pentru un RG

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

    • Temporizator de întârziere, care este perioada de timp pentru a întârzia inițializarea grupului RG și negocierea rolului după apariția interfeței - Implicit 30 de secunde. Intervalul este de 0-10000 secunde

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

    • Se recomandă temporizatoarele implicite, deși aceste cronometre pot fi ajustate pentru a se potrivi cu orice întârziere suplimentară de convergență a rețelei care poate apărea în timpul pornirii/reîncărcării routerelor, pentru a garanta că negocierea protocolului RG are loc după ce rutarea în rețea a convergent la un punct stabil. De exemplu, dacă după failover se vede că durează până la 20 de secunde pentru ca noul STANDBY să vadă primul pachet RG HELLO de la noul ACTIVE, atunci cronometrele ar trebui ajustate la „timerele întârzie 60 reload 120” pentru a lua în considerare această întârziere.

  • control GigabiteThernet3 protocol 1 —Configurează interfața utilizată pentru a schimba mesaje keepalive și hello între cele două CUBE ș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 verificarea traficului de date

  • urmărire —urmă rirea grupului RG a interfețelor

  • protocol 1 - Speci fică 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:

    • Hellotime- Interval între mesajele succesive de salut - Implicit 3 secunde. Intervalul este de 250 miliseconde-254 secunde

    • Timp de așteptare — Intervalul dintre primirea unui mesaj Hello și prezumția că routerul de trimitere a eșuat. Această durată trebuie să fie mai mare decât ora de salut — implicit 10 secunde. Intervalul este de 750 miliseconde-255 secunde

      Vă recomandăm să configurați cronometrul de așteptare 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-ul de la pasul anterior de mai jos. 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

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

4

Configurați interfețele Gig1 și Gig2 cu IP-urile virtuale respective, așa cum se arată mai jos și aplicați identificatorul interfeței 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:

  • redundanță rii — Configurează identificatorul interfeței de redundanță pentru grupul de redundanță. Necesar pentru generarea unei adrese MAC virtuale (VMAC). Aceeași valoare de identificare rii trebuie utilizată pe interfața fiecărui router (ACTIVE/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 rii unice pe interfețele respective (pentru a preveni coliziunea). Comanda Show redundancy application group all ar trebui să indice informațiile locale și de la egal la egal corecte.

  • 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 obligatorie utilizarea unei interfețe separate pentru redundanță, adică interfața utilizată pentru traficul vocal nu poate fi utilizată ca interfață de control și date specificată la Pasul 2 de mai sus. În acest exemplu, interfața Gigabit 3 este utilizată pentru control/date RG

5

Salvați configurația primului CUB și reîncărcați-l.

Platforma pentru a reîncărca ultima dată este întotdeauna Standby.

VCUBE-1#wr
Building configuration...
[OK]
VCUBE-1#reload
Proceed with reload? [confirm]

După ce VCUBE-1 pornește complet, salvați configurația VCU BE-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. Rezultatul relevant este evidențiat cu caractere aldine.

Am reîncărcat VCUBE-2 ultima dată și conform considerațiilor de proiectare; platforma de reîncărcare ultima va fi întotdeauna Standby.


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 configurația Local Gateway (bazată pe înregistrare sau pe bază de certificat) pe ambele CUBE HA. Consultați Configurarea gateway-ului local pe Cisco IOS XE pentru Webex Calling.

A fost util acest articol?
A fost util acest articol?