Fundamentale

Cerințe preliminare

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

Orientările de configurare prevăzute în acest articol presupun o platformă locală de gateway dedicată, fără o configurație vocală existentă. Dacă o implementare CUBE existentă a întreprinderii 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 existente și funcționalitățile 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 16.12.2 sau o versiune ulterioară și o platformă pe care sunt acceptate atât funcțiile CUBE HA, cât și funcțiile LGW.

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

Material de referință

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

Prezentare generală Soluție Webex Calling

Cisco Webex Calling este o ofertă de colaborare care oferă o alternativă bazată pe cloud multi-tenant la serviciul de telefonie PBX prestabilit, cu mai multe opțiuni PSTN pentru clienți.

Implementarea gateway-ului local (reprezentată mai jos) se află în centrul acestui articol. Trunchiul gateway-ului local (PSTN local) din 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 din cloud sunt securizate prin intermediul transportului TLS pentru SIP și SRTP pentru mass-media.

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

Nivelul 2 Redundanță Box-to-Box

Redundanța CUBE HA strat 2 box-to-box utilizează protocolul de infrastructură Redundancy Group (RG) pentru a forma o pereche activă/standby de routere. Această pereche partajează aceeași adresă IP virtuală (VIP) pe interfețele respective și face schimb continuu de mesaje de stare. Informațiile despre sesiunea CUBE sunt verificate de-a lungul perechii de routere care permit routerului standby să preia imediat toate responsabilitățile de procesare a apelurilor CUBE în cazul în care routerul activ iese din serviciu, ceea ce duce la păstrarea constantă a semnalizării și a mass-mediei.

Verificarea punctajului este limitată la apelurile conectate cu pachete media. Apelurile în tranzit nu sunt bifate (de exemplu, o stare de încercare sau de apel).

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

Începând cu IOS-XE 16.12.2, CUBE HA poate fi implementat ca un gateway local pentru implementările trunchiului Cisco Webex Calling (PSTN local) și vom acoperi considerațiile de proiectare și configurațiile din acest articol. Această cifră afișează o configurare tipică CUBE HA ca gateway local pentru o implementare trunchi Cisco Webex Calling.

Componentă Intra Grup de redundanță

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

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

  • Un mecanism de transport pentru verificarea stării de semnalizare și media pentru fiecare apel de la router-ul activ la router-ul standby (prin interfața de date) - GigabitEthernet3 în figura de mai sus.

  • Configurarea și gestionarea interfeței Virtual 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 configurată special pentru a sprijini 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 pe ambele CUBE din perechea CUBE HA trebuie să reziste pe aceeași subrețea LAN. Configurarea VIP-ului ș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 Access 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 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 standby. Când routerul Activ coboară, routerul Standby preia și continuă să redirecționeze fluxul RTP care a fost direcționat anterior de primul router.

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

Următoarele cerințe există pentru utilizarea CUBE HA ca gateway local pentru defalcarea statică 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) și Gig3 este Redundancy Group (RG) Control/interfață de date

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

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

  • Toate semnalele/mass-media sunt obținute de la/la adresa IP virtuală

  • Oricând o platformă este reîncărcată într-o relație CUBE-HA, ea începe î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 trebuie să fie unic pentru o combinație pereche/interfață în același strat 2

  • Configurația pe ambele CUBEs 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 legături, deoarece acestea sunt întotdeauna în sus

  • Interfețele de trafic multiplu (SIP/RTP) (Gig1, Gig2) necesită configurarea monitorizării interfeței

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

  • Ambele platforme trebuie să fie identice și să fie conectate printr-o Comutator fizic pe toate interfețele 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 pe CUBEs direct sau Data HA pe nici o parte

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

  • Este obligatoriu să se utilizeze o interfață L3 separată pentru redundanță (RG Control/date, Gig3). adică interfața utilizată pentru trafic nu poate fi utilizată pentru keepalives HA și puncte de control

  • După eșec, CUBE-ul activ anterior trece printr-o reîncărcare prin proiectare, păstrând semnalizarea și mass-media

Configurați redundanța pe Ambele CUBE-uri

Trebuie să configurați redundanța de la 2 la 2 pe ambele CUBEs destinate utilizării într-o pereche HA pentru a aduce IPs 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 de voce, astfel încât traseul activ va juca destul de rolul său activ după ce interfața de trafic este în jos.

2

Configurați un RG pentru utilizare cu VoIP HA în submodul de redundanță al 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ță—Introduceți modul redundanță

  • redundanță aplicație—Introduceți modul de configurare a redundanței aplicației

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

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

  • prioritatea 100 nerespectarea pragului 75 – Specifică prioritatea inițială și nerespectarea pragurilor pentru un RG

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

    • Temporizator de întârziere, care este cantitatea de timp pentru a întârzia inițializarea grupului RG și negocierea rolului după ce interfața apare – Implicit 30 secunde. Intervalul este de 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 de 0-10000 de secunde

    • Sunt recomandate cronometre implicite, deși aceste cronometre pot fi ajustate pentru a acomoda 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 s-a convertit la un punct stabil. De exemplu, dacă se vede după eșec că este nevoie de până la 20 sec pentru noul STANDBY pentru a vedea primul pachet RG HELLO de la noul ACTIVE, atunci cronometrele ar trebui să fie ajustate la „cronometrele întârziere 60 reîncărcare 120“ la factor în această întârziere.

  • control GigabitEthernet3 protocol 1—Configurează interfața utilizată pentru a face schimb de mesaje keepalive și salut între cele două CUB-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 bifarea traficului de date

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

  • protocol 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 așteptare — Interval între mesajele de întâmpinare succesive – Implicit 3 secunde. Intervalul este de 250 milisecunde-254 secunde

    • Timp de așteptare – Intervalul dintre primirea unui mesaj de întâmpinare ș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 timp în așteptare pentru a fi de cel puțin 3 ori valoarea cronometrului de timp în așteptare.

3

Activați redundanța box-to-box pentru aplicația CUBE. Configurați RG din 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

redundanță-grup 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 toate configurațiile au fost aplicate.

4

Configurați interfețele Gig1 și Gig2 cu IP-urile lor virtuale respective, după 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 a ID-ului RII trebuie utilizată pe interfața fiecărui router (ACTIVE/STANDBY) care are același VIP.

    În cazul în care există mai mult de o pereche B2B pe același LAN, fiecare pereche TREBUIE SĂ aibă ID-uri unice IRU pe interfețele lor respective (pentru a preveni coliziunea). „afișați grupul de aplicații redundanță” trebuie să indice informațiile locale și peer corecte.

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

    Este obligatoriu să se utilizeze o interfață separată pentru redundanță, adică interfața utilizată pentru traficul de voce 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 controlul RG/date

5

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

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

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

După ce VCUBE-1 cizme 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 cutie-la-cutie funcționează conform așteptărilor. Ieșirea relevantă este evidențiată în îndrăzneală.

Am reîncărcat ultimul VCUBE-2 și conform considerațiilor de proiectare; platforma de reîncărcare 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#

Configurați un gateway local pe Ambele CUBE-uri

În configurația exemplului nostru, folosim următoarele informații despre trunchiuri din 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 următoarele:

  • 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ările sau secretele partajate. Parolele de tip 6 sunt criptate folosind AES cipher ș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 pe baza parametrilor Control Hub afișați mai sus, salvați și reîncărcați. Datele de autentificare SIP Digest din Control Hub sunt evidențiate în mod î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 de afișare, am reîncărcat VCUBE-2 urmat de VCUBE-1, făcând VCUBE-1 standby-ul CUBE și VCUBE-2 CUBE activ

2

În orice 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 din următoarele comenzi spectacol.

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

afișați starea înregistrării sip-ua


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 ieșirea de mai sus, puteți vedea că VCUBE-2 este LGW-ul activ care menține înregistrarea cu acces Webex Calling SBC, în timp ce ieșirea „afișează starea de înregistrare sip-ua” este necompletată î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 eșecul 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 STANDBY LGW are loc în scenariul următor, precum și în afara CLI enumerate mai sus

  • Când routerul ACTIV se reîncărcă

  • Când ciclurile de alimentare ACTIVE ale routerului

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

5

Verificați dacă VCUBE-1 s-a înregistrat cu Webex Calling Access SBC. VCUBE-2 s-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-ul activ.

6

Uitați-vă la jurnalul de depanare relevant din VCUBE-1 care trimite un ÎNREGISTRATOR SIP către Webex Calling PRIN IP-ul virtual și primește un OK 200.


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