Nozioni fondamentali

Prerequisiti

Prima di distribuire CUBE HA come gateway locale per Webex Calling, accertarti di aver compreso pienamente i seguenti concetti:

Le linee guida di configurazione fornite in questo articolo presuppongono una piattaforma gateway locale dedicata che non prevede alcuna configurazione vocale esistente. Se viene modificata una distribuzione CUBE Enterprise esistente per utilizzare anche la funzione gateway locale per Cisco Webex Calling, presta attenzione alla configurazione applicata per garantire che i flussi di chiamata e le funzionalità esistenti non vengano interrotte e che stai soddisfacendo i requisiti di progettazione CUBE HA.

Componenti hardware e software

CUBE HA come gateway locale richiede IOS-XE versione 16.12.2 o successiva e una piattaforma su cui sono supportate entrambe le funzioni CUBE HA e LGW.

I comandi show e i registri in questo articolo si basano sulla release software minima di Cisco IOS-XE 16.12.2 implementata su vCUBE (CSR1000v).

Materiale di riferimento

Di seguito sono riportate alcune guide alla configurazione di CUBE HA dettagliate per diverse piattaforme:

Panoramica della soluzione Webex Calling

Cisco Webex Calling è un servizio di collaborazione che offre un'alternativa basata su cloud multi-tenant al servizio telefonico PBX locale con più opzioni PSTN per i clienti.

La distribuzione del gateway locale (rappresentata di seguito) è il fulcro di questo articolo. Il trunk del gateway locale (PSTN locale) in Webex Calling consente la connettività a un servizio PSTN di proprietà del cliente. Fornisce anche la connettività a una distribuzione PBX IP locale, ad esempio Cisco Unified CM. Tutte le comunicazioni da e verso il cloud vengono protette utilizzando il trasporto TLS per SIP e SRTP per contenuti multimediali.

La figura seguente mostra una distribuzione Webex Calling senza un PBX IP esistente ed è applicabile a una distribuzione per singolo sito o più siti. La configurazione descritta in questo articolo si basa su questa distribuzione.

Ridondanza box-to-box layer 2

La ridondanza box-to-box layer 2 CUBE HA utilizza il protocollo dell'infrastruttura RG (Redundancy Group) per formare una coppia di router attivo/standby. Questa coppia condivide lo stesso indirizzo IP virtuale (VIP) sulle relative interfacce e scambia continuamente messaggi di stato. Le informazioni di sessione CUBE vengono verificate sulla coppia di router consentendo al router standby di assumere immediatamente tutte le responsabilità di elaborazione delle chiamate CUBE se il router attivo è fuori uso, in modo da preservare segnali e contenuti multimediali.

La verifica è limitata a chiamate connesse con pacchetti multimediali. Le chiamate in transito non vengono verificate (ad esempio, tentativi di chiamata o chiamate che squillano in attesa di risposta).

In questo articolo, CUBE HA fa riferimento alla ridondanza CUBE High Availability (HA) Box-to-box (B2B) layer 2 per la conservazione delle chiamate con stato

A partire da IOS-XE 16.12.2, CUBE HA può essere distribuito come gateway locale per distribuzioni di trunk Cisco Webex Calling (PSTN locale) e in questo articolo verranno riportate alcune considerazioni di progettazione e configurazioni. L'immagine mostra una tipica impostazione di CUBE HA come gateway locale per una distribuzione di trunk Cisco Webex Calling.

Componente Infra del gruppo di ridondanza

Il componente Infra del gruppo di ridondanza (RG, Redundancy Group) fornisce il supporto dell'infrastruttura di comunicazione box-to-box tra i due CUBE e negozia lo stato di ridondanza stabile finale. Questo componente fornisce anche:

  • Un protocollo simile a HSRP che negozia lo stato di ridondanza finale per ciascun router scambiando messaggi keepalive e hello tra i due CUBE (tramite l'interfaccia di controllo), GigabitEthernet3 nella figura precedente.

  • Un meccanismo di trasporto per la verifica dello stato di segnali e contenuti multimediali per ciascuna chiamata dal router attivo al router standby (tramite l'interfaccia dati), GigabitEthernet3 nella figura precedente.

  • Configurazione e gestione dell'interfaccia IP virtuale (VIP) per le interfacce di traffico (più interfacce di traffico possono essere configurate utilizzando lo stesso gruppo RG), GigabitEthernet 1 e 2 sono considerate interfacce di traffico.

Questo componente RG deve essere configurato in modo specifico per supportare il sistema vocale B2B HA.

Gestione degli indirizzi IP virtuali (VIP) per segnali e contenuti multimediali

B2B HA si basa sull'IP virtuale per ottenere ridondanza. Il VIP e le interfacce fisiche associate su entrambi i CUBE nella coppia CUBE HA devono risiedere sulla stessa subnet LAN. La configurazione del VIP e l'associazione dell'interfaccia VIP a una determinata applicazione vocale (SIP) sono obbligatorie per il supporto vocale B2B HA. I dispositivi esterni come Unified CM, controller SBC di accesso a Webex Calling, provider di servizi o proxy, utilizzano il VIP come indirizzo IP di destinazione per le chiamate che attraversano i router CUBE HA. Pertanto, dal punto di vista di Webex Calling, le coppie di CUBE HA agiscono come un singolo gateway locale.

Le informazioni su segnale di chiamata e sessione RTP delle chiamate stabilite vengono verificate dal router attivo al router di standby. Quando il router Attivo non è attivo, il router Standby subentra e continua a inoltrare il flusso RTP precedentemente indirizzato dal primo router.

Le chiamate in uno stato temporaneo al momento del failover non verranno mantenute dopo il cambio. Ad esempio, le chiamate non ancora completamente stabilite o in corso di modifica con una funzione di trasferimento o attesa. Le chiamate stabilite possono essere disconnesse dopo il cambio.

Esistono i seguenti requisiti per l'uso di CUBE HA come gateway locale per il failover delle chiamate:

  • CUBE HA non può avere interfacce TDM o analogiche co-posizionate

  • Le interfacce Gig1 e Gig2 sono denominate interfacce di traffico (SIP/RTP) e Gig3 è l'interfaccia di controllo RG/dati

  • Non è possibile inserire più di 2 coppie CUBE HA nello stesso dominio layer 2, una con ID gruppo 1 e l'altra con ID gruppo 2. Se configuri 2 coppie HA con lo stesso ID gruppo, le interfacce di controllo RG/dati devono appartenere a domini layer 2 diversi (vlan, switch separato)

  • Il canale delle porte è supportato per entrambe le interfacce di controllo RG/dati e di traffico

  • Tutti i segnali/contenuti multimediali sono originati da/all'indirizzo IP virtuale

  • Ogni volta che una piattaforma viene ricaricata in una relazione CUBE-HA, viene sempre avviata come Standby

  • L'indirizzo inferiore per tutte le interfacce (Gig1, Gig2, Gig3) deve essere sulla stessa piattaforma

  • L'identificativo dell'interfaccia di ridondanza, rii, deve essere univoco per una combinazione di coppia/interfaccia nello stesso Layer 2

  • La configurazione su entrambi i CUBE deve essere identica, inclusa la configurazione fisica, e deve essere in esecuzione sullo stesso tipo di piattaforma e versione IOS-XE

  • Non è possibile utilizzare interfacce di loopback come associazione perché sono sempre attive

  • Più interfacce di traffico (SIP/RTP) (Gig1, Gig2) richiedono la configurazione del rilevamento dell'interfaccia

  • CUBE-HA non è supportato su una connessione via cavo crossover per il collegamento controllo RG/dati (Gig3)

  • Entrambe le piattaforme devono essere identiche e connesse tramite uno switch fisico su tutte le interfacce simili affinché CUBE HA funzioni, ossia GE0/0/0 di CUBE-1 e CUBE-2 devono terminare sullo stesso switch e così via.

  • Non è possibile impostare WAN con terminazione diretta su CUBE o Data HA su entrambi i lati

  • Entrambi i router, Attivo/Standby, devono essere nello stesso centro dati

  • È obbligatorio utilizzare un'interfaccia L3 separata per ridondanza (controllo RG/dati, Gig3), ossia l'interfaccia utilizzata per il traffico non può essere utilizzata per keepalive e verifica HA

  • Al momento del failover, il CUBE precedentemente attivo passa attraverso un ricaricamento per impostazione predefinita, preservando segnali e contenuti multimediali

Configurazione della ridondanza su entrambi i CUBE

Devi configurare la ridondanza box-to-box layer 2 su entrambi i CUBE da utilizzare in una coppia HA per visualizzare IP virtuali.

1

Configura il rilevamento dell'interfaccia a livello globale per rilevare lo stato dell'interfaccia.

conf t track 1 interfaccia 
 GigabitEthernet1 linea-protocollo traccia 2 interfaccia 
 GigabitEthernet2 uscita protocollo linea 

VCUBE-1#conf.

VCUBE-1(config)#traccia 1 interfaccia GigabitEthernet1-protocollo linea

VCUBE-1(config-track)#Interfaccia traccia 2 Protocollo linea GigabitEthernet2

VCUBE-1(config-track)#uscita

VCUBE-2#conf.

VCUBE-2(config)#Interfaccia di traccia 1 Protocollo linea GigabitEthernet1

VCUBE-2(config-track)#Interfaccia traccia 2 Protocollo linea GigabitEthernet2

VCUBE-2(config-track)#uscita

La CLI di rilevamento viene utilizzata in RG per rilevare lo stato dell'interfaccia di traffico vocale in modo che il router attivo esca dal ruolo attivo una volta disattivata l'interfaccia di traffico.

2

Configura un RG per l'uso con VoIP HA nella modalità secondaria di ridondanza dell'applicazione.

ridondanza applicazione gruppo di ridondanza 1 nome 
 
 
    LocalGateway-HA priorità 
    100 soglia di failover 75 
    controllo GigabitEthernet3 protocollo 1 dati 
    GigabitEthernet3 timer ritardo 30 ricaricamento 60 traccia 1 traccia di arresto 2 arresto protocollo 
 
    uscita 
 
 
   1 timer 
    salvetime 3 attesa 10 
 
 
 uscita uscita 

VCUBE-1(config)#ridondanza

VCUBE-1(config-red)#ridondanza applicazione

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

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

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#controllo GigabitEthernet3 protocollo 1

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

VCUBE-1(config-red-app-grp)#timer ritardo 30 reload 60

VCUBE-1(config-red-app-grp)#arresto della traccia 1

VCUBE-1(config-red-app-grp)#arresto della traccia 2

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

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

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

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

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

VCUBE-1(config-red)#uscita

VCUBE-1(config) #

VCUBE-2(config)#ridondanza

VCUBE-2(config-red)#ridondanza applicazione

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

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

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#controllo GigabitEthernet3 protocollo 1

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

VCUBE-2(config-red-app-grp)#timer ritardo 30 reload 60

VCUBE-2(config-red-app-grp)#arresto della traccia 1

VCUBE-2(config-red-app-grp)#arresto della traccia 2

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

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

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

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

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

VCUBE-2(config-red)#uscita

VCUBE-2(config) #

Di seguito una spiegazione dei campi utilizzati in questa configurazione:

  • redundancy: attiva la modalità di ridondanza

  • application redundancy: attiva la modalità di configurazione della ridondanza dell'applicazione

  • group: attiva la modalità di configurazione del gruppo di applicazioni di ridondanza

  • name LocalGateway-HA: definisce il nome del gruppo RG

  • priority 100 failover threshold 75: specifica la priorità iniziale e le soglie di failover per un RG

  • timers delay 30 reload 60: configura le due volte per il ritardo e il ricaricamento

    • Timers delay è la quantità di tempo per ritardare inizializzazione e negoziazione del ruolo del gruppo RG dopo l'attivazione dell'interfaccia – 30 secondi è il valore predefinito. L'intervallo di valori consentiti va da 0 a 10.000 secondi

    • Reload è la quantità di tempo per ritardare inizializzazione e negoziazione del ruolo del gruppo RG dopo un ricaricamento – 60 secondi è il valore predefinito. L'intervallo di valori consentiti va da 0 a 10.000 secondi

    • Si consiglia di utilizzare i timer predefiniti, sebbene questi timer possano essere regolati in base all'eventuale ritardo di convergenza della rete che può verificarsi durante l'avvio/ricaricamento dei router, al fine di garantire che la negoziazione del protocollo RG venga eseguita dopo che l'indirizzamento nella rete è confluito in un punto stabile. Ad esempio, se dopo il failover si nota che sono necessari fino a 20 secondi al nuovo router STANDBY per visualizzare il primo pacchetto RG HELLO dal nuovo router ACTIVE, i timer devono essere regolati in 'timers delay 60 reload 120' per prendere in considerazione questo ritardo.

  • control GigabitEthernet3 protocol 1: configura l'interfaccia utilizzata per scambiare messaggi keepalive e hello tra i due CUBE e specifica l'istanza del protocollo che verrà collegata a un'interfaccia di controllo e attiva la modalità di configurazione del protocollo dell'applicazione di ridondanza

  • data GigabitEthernet3: configura l'interfaccia utilizzata per la verifica del traffico dati

  • traccia: rilevamento di interfacce del gruppo RG

  • protocol 1: specifica l'istanza del protocollo che verrà collegata a un'interfaccia di controllo e attiva la modalità di configurazione del protocollo dell'applicazione di ridondanza

  • timers hellotime 3 holdtime 10: configura i due timer per hellotime e holdtime:

    • Hellotime: intervallo tra messaggi hello successivi – 3 secondi valore predefinito. L'intervallo di valori consentiti va da 250 millisecondi a 254 secondi

    • Holdtime: intervallo tra la ricezione di un messaggio Hello e il presupposto che si è verificato un errore del router di invio. Questa durata deve essere maggiore del valore di hellotime – 10 secondi valore predefinito. L'intervallo di valori consentiti va da 750 millisecondi a 255 secondi

      È consigliabile configurare il timer holdtime in modo che sia almeno 3 volte il valore del timer hellotime.

3

Abilita la ridondanza box-to-box per l'applicazione CUBE. Configurare RG dal punto precedente in servizio vocale voip. Ciò consente all'applicazione CUBE di controllare il processo di ridondanza.

servizio vocale 
   ridondanza-gruppo 1 
   uscita

VCUBE-1(config)#voip servizio vocale

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

 % Ha creato un'associazione RG 1 con Voice B2B HA; ricaricare il router per fare in modo che la nuova configurazione sia effettiva 

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

VCUBE-2(config)#voip servizio vocale

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

 % Ha creato un'associazione RG 1 con Voice B2B HA; ricaricare il router per fare in modo che la nuova configurazione sia effettiva 

VCUBE-2(config-voi-serv)# uscita

redundancy-group 1: l'aggiunta e la rimozione di questo comando richiede un ricaricamento per rendere effettiva la configurazione aggiornata. Le piattaforme verranno ricaricate una volta applicata la configurazione.

4

Configura le interfacce Gig1 e Gig2 con i relativi IP virtuali come mostrato di seguito e applica l'identificativo dell'interfaccia di ridondanza (rii)

VCUBE-1(config)#interfaccia GigabitEthernet1

VCUBE-1(config-if)# rii rii 1

VCUBE-1(config-if)# gruppo di ridondanza 1 ip 198.18.1.228 esclusivo

VCUBE-1(config-if)# uscita

VCUBE-1(config) #

VCUBE-1(config)#interfaccia GigabitEthernet2

VCUBE-1(config-if)# rii rii 2

VCUBE-1(config-if)# gruppo di ridondanza 1 ip 198.18.133.228 esclusivo

VCUBE-1(config-if)# uscita

VCUBE-2(config)#interfaccia GigabitEthernet1

VCUBE-2(config-if)# rii rii 1

VCUBE-2(config-if)# gruppo di ridondanza 1 ip 198.18.1.228 esclusivo

VCUBE-2(config-if)# uscita

VCUBE-2(config) #

VCUBE-2(config)#interfaccia GigabitEthernet2

VCUBE-2(config-if)# rii rii 2

VCUBE-2(config-if)# gruppo di ridondanza 1 ip 198.18.133.228 esclusivo

VCUBE-v(config-if)# uscita

Di seguito una spiegazione dei campi utilizzati in questa configurazione:

  • redundancy rii: configura l'identificativo dell'interfaccia di ridondanza per il gruppo di ridondanza. Richiesto per la generazione di un indirizzo MAC virtuale (VMAC). Lo stesso valore ID rii deve essere utilizzato sull'interfaccia di ciascun router (ACTIVE/STANDBY) con lo stesso VIP.

    Se sono presenti più di una coppia B2B sulla stessa LAN, ciascuna coppia DEVE disporre di ID rii univoci sulle relative interfacce (per evitare le collisioni). L'opzione 'show redundancy application group all' (mostra gruppo applicazioni di ridondanza tutti) deve indicare le informazioni locali e peer corrette.

  • redundancy group 1: associa l'interfaccia al gruppo di ridondanza creato al punto 2 precedente. Configura il gruppo RG e il VIP assegnato a questa interfaccia fisica.

    È obbligatorio utilizzare un'interfaccia separata per ridondanza, ovvero, l'interfaccia utilizzata per il traffico vocale non può essere utilizzata come interfaccia di controllo e dati specificata al punto 2 precedente. In questo esempio, viene utilizzata l'interfaccia Gigabit 3 per controllo RG/dati

5

Salva la configurazione del primo CUBE e ricaricala.

La piattaforma da ricaricare per ultima è sempre Standby.

VCUBE-1#wr

 Configurazione edificio... 

 [OK] 

VCUBE-1#ricarica

 Continuare con il ricaricamento? [conferma]

Dopo aver avviato completamente VCUBE-1, salvare la configurazione di VCUBE-2 e ricaricarla.

VCUBE-2#wr

 Configurazione edificio... 

 [OK] 

VCUBE-2#ricarica

 Continuare con il ricaricamento? [conferma]

6

Verifica che la configurazione box-to-box funzioni come previsto. L'output rilevante è evidenziato in grassetto.

VCUBE-2 è stato ricaricato per ultimo e in base alle considerazioni di progettazione; la piattaforma da ricaricare per ultima sarà sempre Standby. 

 VCUBE-1#mostra gruppo di applicazioni di ridondanza tutti gli stati degli errori Info gruppo 1:        Priorità runtime: [100] RG errori RG stato: In alto.                        N. totale di switch dovuti a errori:  0 numero totale di modifiche dello stato di Down/up a causa di errori: 0 gruppo ID: 1 nome gruppo: LocalGateway-ha stato amministrativo: Nessuno stato operativo aggregazione di arresto:  Il mio ruolo: Ruolo peer attivo:  Presenza peer di standby: Sì comm: Sì progressione peer avviata: Sì dominio RF: stato RF BtoB-One: Stato RF peer attivo: Funzione di STANDBY HOT RG Protocol RG 1------------------ruolo: Negoziazione attiva: Priorità abilitata: 100 stato protocollo: Active CTRL INTF (s) stato: Attiva peer attivo: Peer di standby locale: Indirizzo 10.1.1.2, Priority 100, contatore Gi3 INTF :                 modifica del ruolo in attivo: 1 Modifica ruolo in standby: 1 Disabilita eventi: RG stato inattivo 0, RG chiuso 0 CTRL eventi INTF: su 1, giù 0, admin_down 0 eventi di ricaricamento: richiesta locale 0, richiesta peer 0 contesto multimediale RG per RG 1--------------------------stato CTX: ID protocollo attivo: 1 tipo di supporto: Interfaccia di controllo predefinita: GigabitEthernet3 timer Salve corrente: 3000 timer Hello configurato: 3000, Timer attesa: 10000 timer Hello peer: 3000, Timer attesa peer: Statistiche 10000:             Pkts 1509, byte 93558, HA Seq 0, numero SEQ 1509, perdita PKT 0 autenticazione non configurata non riuscita: 0 ricarica peer: Nuovo segno TX 0, RX 0: TX 0, RX 0 peer Standy: Presente. Timer attesa: 10000 Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0 VCUBE-1#
 VCUBE-2#mostra gruppo di applicazioni di ridondanza tutti gli stati degli errori Info gruppo 1:        Priorità runtime: [100] RG errori RG stato: In alto.                        N. totale di switch dovuti a errori:  0 numero totale di modifiche dello stato di Down/up a causa di errori: 0 gruppo ID: 1 nome gruppo: LocalGateway-ha stato amministrativo: Nessuno stato operativo aggregazione di arresto: Il mio ruolo: Ruolo peer di STANDBY:  Presenza Active peer: Sì comm: Sì progressione peer avviata: Sì dominio RF: stato RF BtoB-One: Stato RF peer attivo: Funzione di STANDBY HOT RG Protocol RG 1------------------ruolo: Negoziazione attiva: Priorità abilitata: 100 stato protocollo: Active CTRL INTF (s) stato: Attiva peer attivo: Indirizzo 10.1.1.2, Priority 100, INTF Gi3 peer di standby: Contatori di log locali:                 modifica del ruolo in attivo: 1 Modifica ruolo in standby: 1 Disabilita eventi: RG stato inattivo 0, RG chiuso 0 CTRL eventi INTF: su 1, giù 0, admin_down 0 eventi di ricaricamento: richiesta locale 0, richiesta peer 0 contesto multimediale RG per RG 1--------------------------stato CTX: ID protocollo attivo: 1 tipo di supporto: Interfaccia di controllo predefinita: GigabitEthernet3 timer Salve corrente: 3000 timer Hello configurato: 3000, Timer attesa: 10000 timer Hello peer: 3000, Timer attesa peer: Statistiche 10000:             Pkts 1509, byte 93558, HA Seq 0, numero SEQ 1509, perdita PKT 0 autenticazione non configurata non riuscita: 0 ricarica peer: Nuovo segno TX 0, RX 0: TX 0, RX 0 peer Standy: Presente. Timer attesa: 10000 
 Pkts 61, Byte 2074, HA Seq 0, Numero Seq 69, Perdita Pkt 0 
 
 VCUBE-2 #

Configurazione di un gateway locale su entrambi i CUBE

Nella configurazione dell'esempio, stiamo utilizzando le seguenti informazioni di trunk di Control Hub per creare la configurazione del gateway locale su entrambe le piattaforme, VCUBE-1 e VCUBE-2. Il nome utente e la password per questa impostazione sono i seguenti:

  • Nome utente: Hussain1076LGU_

  • Password: lOV12MEaZx

1

Assicurati che venga creata una chiave di configurazione per la password, con i comandi shown di seguito, prima di poterla utilizzare in credenziali o segreti condivisi. Le password di tipo 6 sono crittografate utilizzando cifratura AES e questa chiave di configurazione definita dall'utente. 

 LocalGateway#conf t LocalGateway(config)#chiave config-chiave password-crittografata Password123 LocalGateway(config)#crittografia password aes

Di seguito è riportato la configurazione del gateway locale che si applicherà a entrambe le piattaforme in base ai parametri di Control Hub visualizzati sopra, Salva e ricarica. Le credenziali digest SIP di Control Hub sono evidenziate in grassetto.

 configura terminal crypto pki trustpoint trustpoint dummyTp revocation-check crl exit sip-ua crypto segnalazione default trustpoint dummyTp cn-san-validate server trasporto tcp tls v1.2 fine configura terminal crypto pki trustpool importazione URL pulito http://www.cisco.com/security/pki/trs/ios_core.p7b end configure terminal voice service voip address trusted list ipv4 x.x.x.x 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 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 regola 9 richiesta ANY sip-header Per modificare "<sips:(.*)" "<sip:\1" regola 11 richiesta ANY sip-header Da modificare "<sips:(.*)" "<sip:\1" regola 12 richiesta ANY sip-header Contatto modifica "<sips:(.*)" "<sip:\1" regola 14 risposta ANY sip-header Da modificare "<sips:(.*)" "<sip:\1" regola 15 richiesta ANY sip-header Contatto modifica "<sips:(.*)" "<sip:\1" regola 20 richiesta ANY sip-header Contatto modifica "<sips:(.*)" "<sip:\1" regola 20 richiesta ANY sip-header Da modificare "<sipshussain1076_lgu>" regola 30 richiede QUALSIASI intestazione sip P-Asserted-Identity modify "sips:(.*)" "sip:\1" codec classe vocale 99 codec preferenza 1 g711ulaw codec preferenza 2 g711ulaw uscita classe vocale srtp-crypto 200 crypto 1 AES_cm_128_hmac_sha1_80 esci da classe vocale stun-usage 200 utilizzo stun firewall-traversal flowdata esci da classe vocale tenant 200 registrar dns:40462196.cisco-bcld.com schema sips scade 240 refresh-ratio 50 numero credenziali tcp tls Hussain5091_ug nome utente Hussain1076_Password LGU 0 OV12MEaZx nome utente di autenticazione Broadworks dell'area di autenticazione Hussain5091_ug password 0 OV12MEaZx nome utente di autenticazione BroadWorks dell'area di autenticazione Hussain5091_ug password 0 OV12MEaZx area di autenticazione 40462196.cisco-bcld.com nessun server SIP con ID remoto dns:40462196.cisco-bcld.com connection-reuse srtp-crypto 200 sessioni di trasporto 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 trasporto sessione 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 classe vocale uri 200 sip pattern dtg=hussain1076.lgu dial-peer voice 101 descrizione voip Dial-peer in uscita a destinazione PSTN IP schema di destinazione BAD.BAD protocollo di sessione sipv2 sessione target ipv4:198.18.133.3 codec di classe vocale 99 voice-class sip tenant 100 dtmf-relay rtp-nte no vad dial-peer voice 201 descrizione voip Dial-peer in uscita sipv2 destinazione sip-server voice-class codec 99 voice-class stun-usage 200 no voice-class sip localhost voice-class tenant 200 dtmf-relay rtp-nte srtp no vad voice class dpg 100 descrizione In entrata WebexCalling(DP200) a IP PSTN(DP101) dial-peer 101 preferenza 1 classe vocale dpg 200 descrizione IP PSTN(DP100) a Webex Calling(DP201) dial-peer 201 preferenza 1 dial-peer voice 100 desription Dial-peer in entrata da IP PSTN protocollo di sessione sipv2 destinazione dpg 200 URI in entrata tramite 100 codec voice-class 99 voice-class SIP tenant 300 dtmf-relay rtp-nte no vad dial-peer voice 200 descrizione voip Dial-peer in entrata da Webex Calling protocollo sipv

Per visualizzare l'output del comando show, è stato ricaricato VCUBE-2 seguito da VCUBE-1, rendendo VCUBE-1 il CUBE standby e VCUBE-2 il CUBE attivo

2

In un determinato momento, solo una piattaforma manterrà una registrazione attiva come gateway locale con il controller SBC di accesso a Webex Calling. Dai un'occhiata all'output dei seguenti comandi show.

show redundancy application group 1

mostra stato registrazione sip-ua 

 VCUBE-1#show redundancy application group 1 ID gruppo:1 Nome gruppo:LocalGateway-HA Stato amministrativo: Stato operativo aggregato Nessuna chiusura: Il mio ruolo:  Ruolo peer di standby: Presenza ACTIVE peer: Sì comm: Sì progressione peer avviata: Sì dominio RF: stato RF BtoB-One: Stato RF in STANDBY: ACTIVE VCUBE-1#mostra stato di registrazione sip-ua VCUBE-1#

 VCUBE-2#show redundancy application group 1 ID gruppo:1 Nome gruppo:LocalGateway-HA Stato amministrativo: Stato operativo aggregato Nessuna chiusura: Il mio ruolo:  Ruolo peer attivo: Presenza peer di stato: Sì comm: Sì progressione peer avviata: Sì dominio RF: stato RF BtoB-One: Stato RF peer attivo: STANDBY HOT VCUBE-2 #Mostra SIP-UA registro stato tenant: 200 --------------------Registro-Indice  1 --------------------- Sopravvivenza reg peer expires (sec) P-Associ-URI ============================== ========== ============ =========== ============== Hussain5091_LGU -1 48 sì normale VCUBE-2#

Dall'output precedente, puoi vedere che VCUBE-2 è l'LGW attivo che mantiene la registrazione con l'SBC di accesso a Webex Calling, mentre l'output del comando "show sip-ua register status" è vuoto in VCUBE-1

3

Ora abilita i seguenti debug su VCUBE-1

 VCUBE-1#debug ccsip non chiamata Il tracciamento fuori finestra di dialogo SIP è abilitato VCUBE-1#debug informazioni ccsip Il tracciamento info chiamata SIP è abilitato VCUBE-1#debug messaggio ccsip

4

Simula il failover specificando il seguente comando sull'LGW attivo, VCUBE-2 in questo caso.

 VCUBE-2#ridondanza applicazione ricaricare gruppo 1 self

Il passaggio dall'LGW ACTIVE a STANDBY si verifica nei seguenti casi oltre alla CLI sopra elencata

  • Quando il router ACTIVE viene ricaricato

  • Quando si spegne e riaccende il router ACTIVE

  • Quando viene arrestata un'interfaccia configurata RG del router ACTIVE per la quale è abilitato il rilevamento

5

Controlla se VCUBE-1 è stato registrato con il controller SBC di accesso a Webex Calling. VCUBE-2 dovrebbe essere stato ricaricato ora.

 VCUBE-1#mostra stato registro sip-ua: 200 --------------------Registro-Indice  1 --------------------- Sopravvivenza reg peer expires (sec) P-Associ-URI ============================== ========== ============ =========== ============ Hussain5091_LGU -1 56 sì normale VCUBE-1#

VCUBE-1 è ora l'LGW attivo.

6

Esamina il registro di debug pertinente su VCUBE-1 inviando un SIP REGISTER a Webex Calling tramite IP virtuale e ricevendo un 200 OK.

 VCUBE-1#mostra registro 9 gen 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG ID 1 Salve Tempo scaduto.9  Gen 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: Cambio ruolo ID RG 1 da Standby a Attivo 9 gennaio 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: Cambio, dallo stato STANDBY_CALDO allo stato ATTIVO. 9 Gen 18.37.24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Ricezione notifica evento ruolo attivo 9 gen 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Inviato: REGISTRA SIP: 40462196.cisco-bcld.com:5061 SIP/2.0 tramite: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 Da: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 A: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Data: Gio 09 gennaio 2020 18:37:24 GMT chiamata-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 agente utente: Cisco-SIPGateway/IOS-16.12.02 max-forward: 70 timestamp: 1578595044 CSeq: 2 REGISTRA contatto: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Scade: 240 supportato: Contenuto percorso-Lunghezza: 0 

9 Gen 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg: Ricevuto: SIP/2.0 401 non autorizzato tramite: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 Da: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 A: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Data: Gio 09 gennaio 2020 18:37:24 GMT chiamata-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 timestamp: 1578595044 CSeq: 2 registrare WWW-Authenticate; DIGEST area di autenticazione = "BroadWorks", qop = "auth", nonce = "BroadWorksXk572qd01Ti58zliBW", algoritmo = MD5 content-length: 0 

9 Gen 18.37.26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Inviato: REGISTRATI SIP: 40462196. Cisco-bcld.com:5061 SIP/2.0 tramite: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC Da: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 A: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Data: Gio 09 gennaio 2020 18:37:25 GMT chiamata-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 agente utente: Cisco-SIPGateway/IOS-16.12.02 max-forward: 70 timestamp: 1578595045 CSeq: 3 REGISTRA contatto: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Scade: 240 supportato: Autorizzazione percorso: Digest nome utente="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 Lunghezza contenuto: 0 

9 Gen 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:  Ricevuto: SIP/2.0 200 OK Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 Da: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 A: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 ID chiamata: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 timestamp: 1578595045 CSeq: 3 REGISTRA contatto: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Consenti eventi: chiamata-info, Seize-line, finestra di dialogo, messaggio-riepilogo, As-funzione-evento, x-Broadworks-hoteling, x-Broadworks-chiamata-Center-stato, contenuto conferenza-lunghezza: 0