Fundamente

Cerințe preliminare

Înainte de a implementa CUBE HA ca un gateway local pentru Webex Calling, asigurați-vă că aveți o înțelegere aprofundată a următoarelor concepte:

Ghidurile de configurare furnizate în acest articol presupun o platformă dedicată de gateway locală, fără configurație vocală existentă. Dacă o implementare de întreprindere CUBE existentă este modificată pentru a utiliza și funcția de 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 16.12.2 sau o versiune ulterioară și o platformă pe care sunt acceptate funcțiile CUBE HA și LGW.


Comenzile și jurnalele de prezentare din acest articol se bazează pe versiunea minimă de software a Cisco IOS-XE 16.12.2 implementată pe un vCUBE (CSR1000v).

Material de referinta

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

Prezentare generală a soluției de apelare Webex

Cisco Webex Calling este o ofertă de colaborare care oferă o alternativă bazată pe cloud multi-chiriași 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 de gateway local (PSTN bazat pe local) în Webex Calling permite conectivitatea la un serviciu PSTN deținut de client. De asemenea, oferă conectivitate la o implementare locală a PBX IP, cum ar fi Cisco Unified CM. Toate comunicațiile către și dinspre cloud sunt securizate utilizând transportul TLS pentru SIP și SRTP pentru mass-media.

Figura de mai jos afișează o implementare Webex Calling fără IP PBX existentă și este aplicabilă unei implementări unice sau multiple. Configurarea prezentată în acest articol se bazează pe această implementare.

Redundanță 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 active / standby. Această pereche are aceeași adresă IP virtuală (VIP) pe interfețele respective și schimbă continuu mesaje de stare. Informațiile despre sesiunea CUBE sunt verificate de-a lungul perechii de routere, permițând routerului de așteptare să preia imediat toate responsabilitățile de procesare a apelurilor CUBE în cazul în care routerul activ nu mai funcționează, rezultând o conservare de stare a semnalizării și a suportului media.


Punctul de verificare este limitat la apelurile conectate cu pachete media. Apelurile în tranzit nu sunt verificate (de exemplu, o stare care încearcă sau sună).

Î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 stat

Începând cu IOS-XE 16.12.2, CUBE HA poate fi implementat ca un gateway local pentru implementări de portbagaj Cisco Webex Calling (PSTN bazate pe premise) și vom acoperi considerațiile și configurațiile de proiectare din acest articol. Această figură afișează o configurație tipică CUBE HA ca Gateway local pentru o implementare a portbagajului Cisco Webex Calling.

Redundancy Group Infra Component

Componenta Infra Redundancy Group (RG) oferă 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 de redundanță finală pentru fiecare router prin schimbul de mesaje keepalive și hello între cele două CUBE (prin interfața de control) —GigabitEthernet3 din figura de mai sus.

  • Un mecanism de transport pentru verificarea stării semnalizării și a mediului pentru fiecare apel de la routerul activ la cel de așteptare (prin interfața de date) —GigabitEthernet3 din 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 să fie configurată special pentru a suporta voce B2B HA.

Managementul 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 asistența vocală B2B HA. Dispozitivele externe, cum ar fi Unified CM, Webex Calling SBC, furnizorul de servicii sau proxy, utilizează VIP ca adresă IP de destinație pentru apelurile care traversează routerele CUBE HA. Prin urmare, din punct de vedere Webex Calling, 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 cade, routerul Standby preia și continuă să redirecționeze fluxul RTP care a fost anterior direcționat de primul router.

Apelurile într-o stare tranzitorie în momentul reluării prin eșec 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 de așteptare. Apelurile stabilite pot fi deconectate după comutare.

Următoarele cerințe există pentru utilizarea CUBE HA ca o poartă de acces locală pentru trecerea la eșec a apelurilor:

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

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

  • Nu mai mult de 2 perechi CUBE HA pot fi plasate în același domeniu layer 2, unul cu grup ID 1 și altul cu grup ID 2. Dacă se configurează 2 perechi HA cu același id de grup, interfețele RG Control / Data trebuie să aparțină unor domenii de nivel 2 diferite (vlan, switch separat)

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

  • Toate semnalizările / conținutul media provin de la / către 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ă

  • Redundancy Interface Identifier, rii ar trebui să fie unic pentru o combinație de perechi / interfețe pe același strat 2

  • Configurarea ambelor 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 legare, deoarece sunt întotdeauna sus

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

  • CUBE-HA nu este acceptat pe o conexiune de cablu crossover pentru legătura de control RG / date (Gig3)

  • Ambele platforme trebuie să fie identic și să fie conectat prin intermediul unui Comutator fizic peste 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.

  • WAN nu poate fi terminat direct pe CUBE sau Data HA de ambele părți

  • Ambele Active / Standby trebuie să se afle în același centru de date

  • Este obligatoriu să utilizați interfață L3 separată pentru redundanță (control RG / date, Gig3). adică interfața utilizată pentru trafic nu poate fi utilizată pentru păstrarea vieților și punctelor de control HA

  • La reluare, CUBE-ul 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 cutie la cutie a stratului 2 pe ambele CUBE destinate a fi utilizate într-o pereche HA pentru a afișa IP-uri virtuale.

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 vocal, astfel încât ruta activă să își îndeplinească rolul activ după interfața de trafic.

2

Configurați un RG pentru utilizare cu VoIP HA în sub-modul redundanță aplicație.

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 redundanță

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

  • grup—Introduce modul de configurare a grupului de aplicații de redundanță

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

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

  • temporizatoarele întârzie 30 reîncarcă 60—Configurează de două ori pentru întârziere și reîncărcare

    • Timer de întârziere, care este cantitatea de timp pentru a întârzia inițializarea grupului RG și negocierea rolului după ce apare interfața - 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ă temporizatoare implicite, deși aceste temporizatoare pot fi ajustate pentru a se potrivi oricărei întârzieri suplimentare 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 rutare în rețea a converg la un stabil punct. De exemplu, dacă după reluare prin eșec, este nevoie de până la 20 de secunde pentru ca noul STANDBY să vadă primul pachet RG HELLO din noul ACTIVE, atunci temporizatoarele ar trebui să fie ajustate la „temporizatoare întârziere 60 reîncărcare 120” pentru a lua în considerare acest lucru întârziere.

  • controlează protocolul GigabitEthernet3 1—Configurează interfața utilizată pentru schimbul de 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 punctele de control ale traficului de date

  • urmări— Urmărirea grupului RG a 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ță

  • timers 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 milisecunde-254 secunde

    • Holdtime — 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 timpul de salut - Implicit 10 secunde. Intervalul este de 750 milisecunde-255 secunde

      Vă recomandăm să configurați cronometrul de așteptare pentru a fi de cel puțin 3 ori valoarea temporizatorului de timp.

3

Activați redundanța cutie la cutie pentru aplicația CUBE. Configurați RG de la pasul anterior de mai jos voice service voip. Aceasta 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

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

4

Configurați interfețele Gig1 și Gig2 cu IP-urile lor 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:

  • redundanta rii—Configurează identificatorul de interfață 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 rii unice pe interfețele lor respective (pentru a preveni coliziunea). „Afișați toate grupurile de aplicații de redundanță” ar trebui să indice informațiile corecte locale și peer.

  • 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 vocal nu poate fi utilizată ca interfață de control și date specificată în pasul 2 de mai sus. În acest exemplu, interfața Gigabit 3 este utilizată pentru control / date RG

5

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

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

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

După VCUBE-1 pornește complet, salvați configurația VCUBE-2 și reîncărcați-l.

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. Ieșirea relevantă este evidențiată în îndrăzneţ.

Am reîncărcat VCUBE-2 ultimul și conform considerațiilor de proiectare; platforma pentru a reîncărca ultima va fi întotdeauna 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#

Configurați un gateway local pe ambele CUBE

În exemplul nostru de configurație, folosim următoarele informații despre trunchi de la Control Hub pentru a construi configurația Local Gateway pe ambele platforme, VCUBE-1 și VCUBE-2. Numele de utilizator și parola pentru această configurare sunt după cum urmează:

  • Nume utilizator: Hussain1076_LGU

  • Parolă: lOV12MEaZx

1

Asigurați-vă că este creată o cheie de configurare pentru parolă, cu comenzile afișate mai jos, înainte de a putea fi utilizată în acreditări sau secrete partajate. Parolele de tip 6 sunt criptate folosind cifrul AES și această cheie de configurare definită de utilizator.


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

Iată configurația gateway-ului local care se va aplica ambelor platforme bazate pe Hub de control parametrii afișați mai sus, salvați și reîncărcați. Acreditări SIP Digest de la Hub de control sunt evidențiate în îndrăzneţ.


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

Pentru a afișa ieșirea comenzii show, am reîncărcat VCUBE-2 urmată de VCUBE-1, realizarea VCUBE-1 standby-ul CUBE și VCUBE-2 CUBUL activ

2

La un moment dat, o singură platformă va menține o înregistrare activă ca Gateway local cu accesul Webex Calling SBC. Aruncați o privire la ieșirea următoarelor comenzi show.

afișați grupul de aplicații de redundanță 1

afișează starea sip-ua-register


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#

Din rezultatul de mai sus, puteți vedea asta VCUBE-2 este LGW activ care menține înregistrarea cu acces Webex Calling SBC, în timp ce ieșirea din „afișează starea registrului sip-ua” este goală în VCUBE-1

3

Acum activați următoarele depanări pe 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

Simulați trecerea la eșec prin emiterea următoarei comenzi pe LGW activ, VCUBE-2 în acest caz.


VCUBE-2#redundancy application reload group 1 self

Trecerea de la ACTIVE la STWBY LGW are loc în următorul scenariu, precum și pe lângă CLI enumerate mai sus

  • Când routerul ACTIVE se reîncarcă

  • Când ciclul de alimentare al routerului ACTIVE se activează

  • Când orice interfață configurată RG a routerului ACTIV este oprită pentru care este activată urmărirea

5

Verificați dacă VCUBE-1 s-a înregistrat la Webex Calling access SBC. VCUBE-2 ar fi reîncărcat până acum.


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 este acum LGW activ.

6

Uitați-vă la jurnalul de depanare relevant de pe VCUBE-1 trimitând un SIP REGISTER către Webex Apelând VIA IP virtual și primind un 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