Fundamentele

Cerințe preliminare

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

Liniile directoare de configurare furnizate în acest articol presupune o platformă gateway local dedicat cu nici o configurație de voce existente. Dacă o implementare existentă CUBE enterprise este modificată pentru a utiliza, de asemenea, 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 16.12.2 sau o versiune ulterioară și o platformă pe care sunt acceptate atât funcțiile CUBE HA, cât și LGW.

Comenzile arată și jurnalele din acest articol se bazează pe lansarea software-ul minim de Cisco IOS-XE 16.12.2 puse în aplicare pe un vCUBE (CSR1000v).

Material de referință

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

Prezentare generală a soluției de apelare Webex

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

Implementarea Local Gateway (reprezentată mai jos) este punctul central al acestui articol. Portbagajul gateway-ului local (PSTN bazat pe premise) 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 de la cloud sunt securizate utilizând tls transport 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 descrisă în acest articol se bazează pe această implementare.

Redundanță de la cutie la nivel 2

Redundanța box-to-box CUBE HA layer 2 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) în interfețele lor respective și schimbă continuu mesajele de stare. Cube informații sesiune este check-pointed peste perechea de routere care să permită router standby pentru a lua toate responsabilitățile CUBE apel de procesare peste imediat în cazul în care router-ul activ iese din serviciu, rezultând în păstrarea statuos de semnalizare și mass-media.

Indicația de verificare este limitată la apelurile conectate cu pachete media. Apelurile în tranzit nu sunt marcate (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 conservarea apelurilor impunătoare

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

Componenta infra a grupului de redundanță

Componenta Infra a grupului de redundanță (RG) oferă suportul pentru infrastructura de comunicații box-to-box între cele două CUBEs și negociază starea finală de redundanță stabilă. 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 punctarea semnalizării și a stării media pentru fiecare apel de la routerul activ la cel standby (prin interfața de date) — GigabitEthernet3 în figura de mai sus.

  • Configurarea și gestionarea interfeței IP virtual (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 accepta voce B2B HA.

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

B2B HA se bazează pe VIP pentru a obține redundanță. Vip-ul și interfețele fizice asociate pe ambele CUBEs din perechea CUBE HA trebuie să se afle pe aceeași subrețea LAN. Configurarea VIP-ului și legarea interfeței VIP la o anumită aplicație de voce (SIP) sunt obligatorii pentru suportul vocal B2B HA. Dispozitivele externe, cum ar fi Unified CM, Webex Calling access SBC, furnizorul de servicii sau proxy-ul, 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.

Informațiile despre semnalizarea apelurilor și sesiunea RTP a apelurilor stabilite sunt punctate de la routerul activ la routerul standby. Când routerul activ coboară, routerul Standby preia controlul și continuă să redirecționeze fluxul RTP care a fost anterior direcționat 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 încă pe deplin stabilite sau sunt în curs de a fi modificate 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 reluarea impunătoare 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 redundanță Grup (RG) Control / interfață de date

  • Nu mai mult de 2 perechi CUBE HA pot fi plasate în același domeniu de nivel 2, unul cu id-ul grupului 1 și celălalt cu id-ul grupului 2. Dacă configurați 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, comutator separat)

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

  • Toate de semnalizare / mass-media este provenind 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 pereche/interfață pe 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țe loopback nu pot fi utilizate ca se leagă, deoarece acestea sunt întotdeauna în sus

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

  • CUBE-HA nu este acceptat printr-o conexiune prin cablu crossover pentru RG-control/link-ul de date (Gig3)

  • Ambele platforme trebuie să fie identice și să fie conectate printr-un switch fizic între toate interfețele de referință 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 poate avea WAN reziliat pe cubes direct sau de date HA pe fiecare parte

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

  • Este obligatorie utilizarea interfeței L3 separate pentru redundanță (RG Control/data, Gig3). adică interfața utilizată pentru trafic nu poate fi utilizată pentru păstrarea ha și punctul de control

  • În caz de nereușită, CUBE-ul activ anterior trece printr-o reîncărcare prin proiectare, păstrând semnalizarea și mass-media

Configurarea redundanței pe ambele CUB-uri

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

1

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

conf t track 1 interfață GigabitEthernet1 linie- protocol track 2 interfață GigabitEthernet2 linie- protocol ieșire 

VCUBE-1#conf t

VCUBE-1(config)#track 1 interfață GigabitEthernet1 linie-protocol

VCUBE-1(config-track)#track 2 interfață GigabitEthernet2 linie-protocol

VCUBE-1 (config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interfață GigabitEthernet1 linie-protocol

VCUBE-2(config-track)#track 2 interfață GigabitEthernet2 linie-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 ruta activă va avea un rol destul de activ după ce interfața de trafic este în jos.

2

Configurați un RG pentru utilizare cu VoIP HA sub-modul de redundanță a aplicației.

redundanță aplicație redundanță grup 1 nume LocalGateway-HA prioritate 100 prag 75 control GigabitEthernet3 protocol 1 date GigabitEthernet3 întârziere cronometru 30 reîncărcare 60 pistă 1 cronometru 2 protocol de ieșire închidere 1 cronometru hellotime 3 holdtime 10 ieșire ieșire ieșire 

VCUBE-1(config)#redundanță

VCUBE-1(config-red)#redundanță aplicație

VCUBE-1(config-red-app)#grupul 1

VCUBE-1(config-red-app-grp)#nume LocalGateway-HA

VCUBE-1(config-red-app-grp)#prioritate 100 prag de rezervă 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#date GigabitEthernet3

VCUBE-1(config-red-app-grp)#temporizatoare întârziere 30 reîncărcare 60

VCUBE-1(config-red-app-grp)#track 1 închidere

VCUBE-1(config-red-app-grp)#track 2 închidere

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#cronometre hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-roșu)#exit

VCUBE-1 (configurație)#

VCUBE-2(config)#redundanță

VCUBE-2(config-red)#redundanță aplicație

VCUBE-2(config-red-app)#grupul 1

VCUBE-2(config-red-app-grp)#nume LocalGateway-HA

VCUBE-2(config-red-app-grp)#prioritate 100 prag de rezervă 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#date GigabitEthernet3

VCUBE-2(config-red-app-grp)#temporizatoare întârziere 30 reîncărcare 60

VCUBE-2(config-red-app-grp)#track 1 închidere

VCUBE-2(config-red-app-grp)#track 2 închidere

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#cronometre hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-roșu)#exit

VCUBE-2 (configurație)#

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

    • Cronometrele implicite sunt recomandate, 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ă se vede după failover că este nevoie de până la 20 sec pentru ca noul STANDBY să vadă primul pachet RG HELLO de la noul ACTIVE, atunci cronometrele trebuie ajustate la "cronometre întârziere 60 reîncărcați 120" pentru a lua în considerare 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:

    • Hellotime- Interval între mesaje succesive salut – Implicit 3 secunde. Raza de acțiune este de 250 milisecunde-254 secunde

    • Timp de așteptare - Intervalul dintre primirea unui mesaj Hello și prezumția că ruterul de trimitere nu a reușit. Această durată trebuie să fie mai mare decât timpul de salut – Implicit 10 secunde. Raza de acțiune 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 cronometrului hellotime.

3

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

redundanță voip serviciu voce - grup 1 ieșire

VCUBE-1(config)#serviciu voip voip

VCUBE-1(config-voi-serv)#redundancy-group 1

 % A fost creată asocierea RG 1 cu Voice B2B HA; reîncărcați routerul pentru ca noua configurație să fie aplicată 

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#serviciu voip voip

VCUBE-2(config-voi-serv)#redundancy-group 1

 % A fost creată asocierea RG 1 cu Voice B2B HA; reîncărcați routerul pentru ca noua configurație să fie aplicată 

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 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)#interfață GigabitEthernet1

VCUBE-1(config-if)# redundanță ri 1

VCUBE-1(config-if)# redundanță grup 1 ip 198.18.1.228 exclusiv

VCUBE-1(config-if)# ieșire

VCUBE-1 (configurație)#

VCUBE-1(config)#interfață GigabitEthernet2

VCUBE-1(config-if)# redundanță rii 2

VCUBE-1(config-if)# redundanță grup 1 ip 198.18.133.228 exclusiv

VCUBE-1(config-if)# ieșire

VCUBE-2(config)#interfață GigabitEthernet1

VCUBE-2(config-if)# redundanță rii 1

VCUBE-2(config-if)# redundanță grup 1 ip 198.18.1.228 exclusiv

VCUBE-2(config-if)# ieșire

VCUBE-2 (configurație)#

VCUBE-2(config)#interfață GigabitEthernet2

VCUBE-2(config-if)# redundanță rii 2

VCUBE-2(config-if)# redundanță grup 1 ip 198.18.133.228 exclusiv

VCUBE-v(config-if)# ieșire

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 Virtual MAC (VMAC). Aceeasi valoare rii ID trebuie folosita si pe interfata fiecarui router (ACTIVE/STANDBY) care are acelasi 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 lor respective (pentru a preveni coliziunea). „Afișați grupul de aplicații de redundanță toți” ar trebui să indice informațiile locale și de la egal la egal 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 obligatorie utilizarea unei interfețe separate 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/datele RG

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

 Se generează configurația... 

 [ok] 

VCUBE-1#reîncărcare

 Continuați reîncărcarea? [confirmare]

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

VCUBE-2#wr

 Se generează configurația... 

 [ok] 

VCUBE-2#reîncărcare

 Continuați reîncărcarea? [confirmare]

6

Verificați că configurația box-to-box funcționează așa cum vă așteptați. Rezultatele relevante sunt evidențiate cu caractere aldine.

Am reîncărcat VCUBE-2 ultima și ca pe considerente de proiectare; platforma pentru a reîncărca ultima va fi întotdeauna standby. 

 VCUBE-1#afișează grupul de aplicații de redundanță toate stările defectelor Informații despre grupul 1:        Prioritate execuție: [100] RG nu răspunde la starea RG: În sus.                        Numărul total de comutări datorate defecțiunilor:  0 Nr. total de modificări ale stării în jos/în sus din cauza defecțiunilor: 0 ID grup:1 Nume grup:LocalGateway-HA Stare administrativă: Fără stare operațională agregată de oprire: Îmbunătățiți  Rolul meu: Rolul ACTIV al partenerului: Prezență PEER ÎN așteptare: Da Comm pentru parteneri: Da Progresia între colegi a început: Da Domeniu RF: Stare RF btob-one: Stare RF Peer ACTIV: Rol RG 1 Protocol STANDBY HOT RG ------------------: Negociere activă: Prioritate activată: 100 Stare protocol: Stare Intf(e) Ctrl activ(e): În sus Active Peer: Partener în așteptare local: adresa 10.1.1.2, prioritatea 100, intf Gi3 Contoare jurnal:                 schimbarea rolului în activ: 1 schimbare rol în standby: 1 dezactivați evenimente: rg în jos starea 0, rg închidere 0 evenimente ctrl intf: sus 1, jos 0, admin_down 0 evenimente de reîncărcare: solicitare locală 0, solicitare peer 0 RG Media Context pentru RG 1 -------------------------- Ctx State: ID protocol activ: 1 Tip fișier media: Interfață de control implicită: GigabitEthernet3 Cronometru curent Bună ziua: 3000 Cronometru Bună Configurat: 3000, Temporizator în așteptare: 10000 Peer Bună Timer: 3000, temporizator de așteptare pentru parteneri: 10000 Statistici:             Pkts 1509, octeți 93558, HA Seq 0, Număr Seq 1509, Pierdere pkt 0 Autentificare neconfigurată eroare de autentificare: 0 Reîncărcare partener: TX 0, RX 0 Renunțați: TX 0, RX 0 Peer în așteptare: Prezentați. Temporizator de așteptare: 10000 Pkts 61, octeți 2074, HA Seq 0, Număr Seq 69, Pierdere Pkt 0 VCUBE-1#
 VCUBE-2#afișați grupul de aplicații de redundanță toate stările defectelor Informații despre grupul 1:        Prioritate execuție: [100] RG nu răspunde la starea RG: În sus.                        Numărul total de comutări datorate defecțiunilor:  0 Nr. total de modificări ale stării în jos/în sus din cauza defecțiunilor: 0 ID grup:1 Nume grup:LocalGateway-HA Stare administrativă: Fără stare operațională agregată de oprire: Îmbunătățiți  Rolul meu: Rolul DE Peer în așteptare: Prezență ACTIVĂ Peer: Da Comm pentru parteneri: Da Progresia între colegi a început: Da Domeniu RF: Stare RF btob-one: Stare RF Peer ACTIV: Rol RG 1 Protocol STANDBY HOT RG ------------------: Negociere activă: Prioritate activată: 100 Stare protocol: Stare Intf(e) Ctrl activ(e): În sus Active Peer: adresa 10.1.1.2, prioritatea 100, intf Gi3 Standby Peer: Contoare pentru jurnalul local:                 schimbarea rolului în activ: 1 schimbare rol în standby: 1 dezactivați evenimente: rg în jos starea 0, rg închidere 0 evenimente ctrl intf: sus 1, jos 0, admin_down 0 evenimente de reîncărcare: solicitare locală 0, solicitare peer 0 RG Media Context pentru RG 1 -------------------------- Ctx State: ID protocol activ: 1 Tip fișier media: Interfață de control implicită: GigabitEthernet3 Cronometru curent Bună ziua: 3000 Cronometru Bună Configurat: 3000, Temporizator în așteptare: 10000 Peer Bună Timer: 3000, temporizator de așteptare pentru parteneri: 10000 Statistici:             Pkts 1509, octeți 93558, HA Seq 0, Număr Seq 1509, Pierdere pkt 0 Autentificare neconfigurată eroare de autentificare: 0 Reîncărcare partener: TX 0, RX 0 Renunțați: TX 0, RX 0 Peer în așteptare: Prezentați. Temporizator de așteptare: 10000 Pkts 61, octeți 2074, HA Seq 0, Număr Seq 69, Pierdere Pkt 0 VCUBE-2#

Configurarea unui gateway local pe ambele CUB-uri

În configurația noastră exemplu, folosim următoarele informații trunchi 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 după cum urmează:

  • Nume utilizator: Hussain1076LGU_

  • 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)#criptarea parolei aes

Iată configurația Local Gateway 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ț.

 configurați terminal cripto pki trustpoint dummyTp revocation-check crl ieșire sip-ua semnalizarea cripto implicit dummyTp cn-san-validate server transport tcp tls v1.2 end configurați terminal crypto pki trustpool import URL curat http://www.cisco.com/security/pki/trs/ios_core.p7b terminal configurați adresa IP de încredere 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-replace agent-id 1 boot-count 4 stun flowdata stun shared-secret 0 Password123! sip g729 annexb-all early-offer forțat end configurați sip-profile de voce terminal 200 regula 9 solicitare ORICE sip-header SIP-Req-URI modificare "sips:(.*)" "<sip:\1" regula 10 solicitare ORICE sip-header Să modifice "<sips:(.*)" "<sip:\1" regula 11 solicitare ORICE sip-header Să modifice "<sips:(.*)" "<sip:\1" regula 12 solicitare ORICE sip-header Să modifice contactul "<sips:(.*)" "<sip:\1" regula 13 răspuns ORICE sip-header Să modifice "<sips:(.*)" "<sip:\1" regula 14 răspuns ORICE sip-header Să modifice "<sips:hussain1076_lgu>” regula 30 solicită ORICE tip de antet sip P-asserted-identity să modifice „sips:(.*)” „sip:\1” codec clasa vocală 99 codec preferință 1 g711ulaw codec 2 g711ulaw ieșire din clasa vocală srtp-crypto 200 cripto 1 AES_centimetru_128_hmac (dezambiguizare)_șah1_80 ieșiți din clasa de voce stun-utilizare 200 firewall-traversare flux de date ieșiți din clasa de voce 200 registrator dns:40462196.cisco-bcld.com sips-uri schemă expiră 240 raport de reîmprospătare 50 tcp tls număr de date de autentificare Hussain5091_Lgu (dezambiguizare) nume utilizator Hussain1076_Parolă LGU 0 OV12MEaZx nume utilizator autentificare Broadworks Hussain5091_Lgu (dezambiguizare) parolă 0 OV12MEaZx nume utilizator autentificare BroadWorks Hussain5091_Lgu (dezambiguizare) parolă 0 OV12MEaZx tărâm 40462196.cisco-bcld.com nu există server sip-id de la distanță dns:40462196.cisco-bcld.com connection-reuse srtp-crypto 200 sesiune transport tcp tls url sips error-passthru asserted-id pai bind control sursă-interfață GigabitEthernet1 bind media-interfață GigabitEthernet1 no pass-thru content custom-sdp sip-profiles 200 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com confidențialitate-politică passthru clasă de voce entitate găzduită 100 sesiune transport udp url sip error-passthru bind control sursă-interfață GigabitEthernet2 bind media sursă-interfață GigabitEthernet2 no pass-thru conținut custom-sdp clasă de voce 300 bind control sursă-interfață GigabitEthernet2 bind media sursă-interfață GigabitEthernet2 no pass-thru conținut custom-sdp clasă de voce uri 100 sip gazdă ipv4:198.18.133.3 URI clasă de voce 200 șablon sip dtg=hussain1076.lgu voce dial-peer 101 voip descriere Dial-peer de ieșire către șablonul de destinație IP PSTN BAD.BAD protocol sesiune sipv2 țintă sesiune IPV4:198.18.133.3 codec de clasă vocală 99 entitate găzduită sip de clasă vocală 100 dtmf-relay rtp-nte nu vad voce-peer voce 201 descriere voip Protocol sesiune sipv2 entitate găzduită sip de clasă vocală codec 99 voce stun-utilizare 200 nicio clasă de voce sip locală gazdă de clasă vocală 200 dtmf-relay rtp-nte srtp nu vad clasă de voce dpg 100 descriere IP PSTN(DP100) către Webex Calling (DP201) dial-peer 201 preferință 1 voce dial-peer 100 descifrare voip Apelare peer de intrare prin protocolul de sesiune IP PSTN sipv2 destinație dpg 200 uri de intrare prin protocolul de clasă vocală 99 entitate găzduită sip de clasă vocală 300 dtmf-relay rtp-nte nu vad voce dial-peer 200 descriere URI de intrare prin protocolul de sesiune Webex Calling sipv2 de destinație dpg 100 URI de intrare prin protocolul de sesiune Webex Calling sipv2 de destinație dpg 100 URI

Pentru a afișa ieșirea comenzii de afișare, am reîncărcat VCUBE-2 urmat de VCUBE-1, făcând din VCUBE-1 CUBUL standby și VCUBE-2 CUBUL activ

2

În orice moment, o singură platformă va menține o înregistrare activă ca Gateway local cu SBC-ul de acces webex Calling. Aruncați o privire la ieșirea următoarelor comenzi de afișare.

prezintă grupul de cereri de redundanță 1

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

 VCUBE-1#afișare redundanță grup aplicație 1 ID grup:1 Nume grup:LocalGateway-HA Stare administrativă: Fără stare operațională agregată de oprire: Îmbunătățiți  Rolul meu: Rolul Peer în așteptare: Prezență ACTIVĂ Peer: Da Comm pentru parteneri: Da Progresia între colegi a început: Da Domeniu RF: Stare RF btob-one: Stare RF HOT Peer în așteptare: VCUBE-1 ACTIV#afișare stare înscriere sip-ua VCUBE-1#

 VCUBE-2#afișare redundanță grup aplicație 1 ID grup:1 Nume grup:LocalGateway-HA Stare administrativă: Fără stare operațională agregată de oprire: Îmbunătățiți Rolul meu: Rolul ACTIV al partenerului: Stare PREZENȚĂ Peer: Da Comm pentru parteneri: Da Progresia între colegi a început: Da Domeniu RF: Stare RF btob-one: Stare RF Peer ACTIV: Standby HOT VCUBE-2#afișare stare înscriere sip-ua entitate găzduită: 200 --------------------Registru-Index  1 --------------------- Linie pereche expiră (sec) reg supraviețuire P-Associ-URI ============================== ========================= ============ Hussain5091_LGU -1 48 da 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 Urmărirea în afara dialogului este activată VCUBE-1#debug ccsip info SIP Urmărirea informațiilor despre apel este activată VCUBE-1#debug ccsip message

4

Simulați reluarea prin emiterea următoarei comenzi pe LGW activ, VCUBE-2 în acest caz.

 VCUBE-2#grup de reîncărcare a aplicației redundanță 1 propriu

Trecerea de la ACTIVE la STANDBY LGW are loc în următorul scenariu, precum și în afară de CLI enumerate mai sus

  • Când routerul ACTIVE se reîncarcă

  • Când routerul ACTIVE cicluri de alimentare

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

5

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

 VCUBE-1#afișare stare Entitate găzduită Sip-ua: 200 --------------------Registru-Index  1 --------------------- Linie peer expiră (sec) reg supraviețuire P-Associ-URI ============================== ========== ============ ============= =========== Hussain5091_LGU -1 56 da normal VCUBE-1#

VCUBE-1 este acum LGW activ.

6

Uitați-vă la jurnalul de depanare relevant pe VCUBE-1 trimițând un REGISTRU SIP la Webex Apelând prin IP-ul virtual și primind un OK 200.

 VCUBE-1#afișare jurnal ian 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRAT: Id RG 1 Timpul De Bună A Expirat. Ian 9 18:37:24.771: %RG_PROTCOL-5-ROLEXCHANGE: Schimbarea rolului ID RG 1 din Standby în Ian activ 9 18:37:24.783: %VOCE_HA-2-COMUTARE_IND: Comutare, de la starea ÎN AȘTEPTARE_CALD la starea ACTIV. Ian 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: A fost primit notificare rol activ eveniment Ian 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Trimis(ă): Înscriere SIP: 40462196.cisco-bcld.com:5061 SIP/2.0 Prin: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 De la: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 La: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Dată: Joi, 09 ian 2020, 18:37:24 GMT ID apel: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Agent utilizator: Redirecționări maxime Cisco-SIPGateway/IOS-16.12.02: 70 Marca temporală: 1578595044 CSeq: 2 ÎNREGISTRARE Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expiră: 240 Acceptată: Lungime conținut cale: 0 

Ian 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg: Recepționat: SIP/2.0 401 Neautorizat Prin: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 De la: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 La: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Dată: Joi, 09 ian 2020, 18:37:24 GMT ID apel: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Marcaj temporal: 1578595044 CSeq: 2 ÎNSCRIEȚI WWW-AUTHENTICATE; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5 Conținut-lungime: 0 

Ian 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Trimis(ă): Înscrieți-VĂ SIP:40462196.cisco-bcld.com:5061 SIP/2.0 Prin: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC De la: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 La: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Dată: Joi, 09 ian 2020, 18:37:25 GMT ID apel: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Agent utilizator:Cisco-SIPGateway/IOS-16.12.02 Redirecționări maxime: 70 Marca temporală: 1578595045 CSeq: 3 ÎNREGISTRARE Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expiră: 240 Acceptată: Autorizație cale: Rezumat nume utilizator="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 Lungime conținut: 0 

Ian 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:  Recepționat: SIP/2.0 200 OK Prin: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 De la: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 La: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 ID apel: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Marcaj temporal: 1578595045 CSeq: 3 ÎNSCRIEȚI-vă Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0,5 Allow-Events: call-info,line-seize,dialog,mesaj-rezumat,ca-caracteristică-eveniment,x-broadworks-hoteling,x-broadworks-call-center-status,conferință conținut-lungime: 0