Fondamenti

Prerequisiti

Prima di distribuire CUBE HA come gateway locale per Webex Calling, accertarsi di avere una conoscenza approfondita dei seguenti concetti:

Le linee guida di configurazione fornite in questo articolo presuppongono una piattaforma Gateway locale dedicata senza configurazione vocale esistente. Se è in corso la modifica di una distribuzione Enterprise CUBE esistente per utilizzare anche la funzione gateway locale per Cisco Webex Calling, prestare particolare attenzione alla configurazione applicata per garantire che i flussi di chiamate e le funzionalità esistenti non vengano interrotti e accertarsi di aderire ai requisiti di progettazione del cubo HA.

Componenti hardware e software

Il cubo HA come gateway locale richiede IOS-XE versione 16.12.2 o successiva ed è supportato sulle seguenti piattaforme:

  • Serie ISR4000-4321, 4331, 4351, 4431, 4451, 4461 (IOS-XE 17.2.1 r)

  • Serie CSR1000 — vCUBE (configurazioni a 1, 2 e 4 vCPU)

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

Materiale di riferimento

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

Panoramica sulla soluzione Webex Calling

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

  • Provider PSTN cloud connected
  • Gateway locale

La distribuzione del gateway locale (rappresentata di seguito) è il punto di interesse di questo articolo. Il gateway locale è l'opzione porta PSTN personale per Cisco Webex Calling fornendo connettività a un servizio di PSTN di proprietà del cliente. Fornisce inoltre la connettività a una distribuzione IP PBX locale, ad esempio Cisco Unified CM. Tutte le comunicazioni da e verso il cloud sono protette utilizzando il trasporto TLS per SIP e SRTP per supporti.

La figura seguente mostra una distribuzione Webex Calling senza alcun IP PBX esistente ed è applicabile a una distribuzione singola o multisito. La configurazione descritta in questo articolo si basa su questa distribuzione.

Ridondanza box-casella Layer 2

La ridondanza box-to-box ad alta disponibilità CUBE HA utilizza il protocollo dell'infrastruttura del gruppo di ridondanza (RG) per formare una coppia di router attiva/standby. Questa coppia condivide lo stesso indirizzo IP virtuale (VIP) tra le rispettive interfacce e lo scambio continuo dei messaggi di stato. Le informazioni della sessione del cubo sono controllate attraverso la coppia di router consentendo al router standby di prendere tutte le responsabilità di elaborazione delle chiamate cubiche immediatamente, se il router attivo si spegne, con conseguente conservazione di segnali e supporti.


Il controllo puntato è limitato alle chiamate connesse con i pacchetti multimediali. Le chiamate in transito non vengono controllate (ad esempio, uno stato di prova o di chiamata).

In questo articolo, CUBE HA farà riferimento alla ridondanza box-to-Box (B2B) Layer 2 ad alta disponibilità (HA) per conservazione chiamata

A seguito di IOS-XE 16.12.2, CUBE HA può essere distribuito come gateway locale per le distribuzioni Cisco Webex Calling e verranno descritte le considerazioni di progettazione e le configurazioni in questo articolo. Questa figura Visualizza una configurazione tipica del cubo HA come gateway locale per una distribuzione Cisco Webex Calling.

Componente infra gruppo di ridondanza

Il componente gruppo di ridondanza (RG) infra fornisce il supporto dell'infrastruttura di comunicazione Box-Box tra i due cubi e negozia lo stato finale di ridondanza stabile. 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 cubi (attraverso l'interfaccia di controllo), GigabitEthernet3 nella figura precedente.

  • Un meccanismo di trasporto per il controllo del segnale e dello stato multimediale di ciascuna chiamata da Active al router standby (attraverso l'interfaccia dati) — GigabitEthernet3 nella figura precedente.

  • Configurazione e gestione dell'interfaccia IP virtuale (VIP) per le interfacce di traffico (è possibile configurare più interfacce di traffico utilizzando lo stesso gruppo RG) – GigabitEthernet 1 e 2 sono considerate interfacce di traffico.

Questo componente RG deve essere configurato specificamente per supportare la funzionalità Voice B2B HA.

Gestione indirizzi IP virtuale (VIP) per segnali e supporti

Il sistema HA si basa su VIP per ottenere ridondanza. Il VIP e le interfacce fisiche associate su entrambi i cubi nella coppia cubo HA devono risiedere nella stessa subnet LAN. La configurazione del VIP e l'associazione dell'interfaccia VIP a una particolare applicazione vocale (SIP) sono obbligatorie per il supporto HA di Voice B2B. Dispositivi esterni come Unified CM, Webex Calling Access SBC, provider di servizi o proxy, utilizzano VIP come indirizzo IP di destinazione per le chiamate che attraversano i router HA del cubo. Di conseguenza, da un punto di vista Webex Calling, le coppie del cubo HA agisce come singolo gateway locale.

Le informazioni sulle chiamate di chiamata e sulla sessione RTP di quelle stabilite vengono indicate dal router attivo al router standby. Quando il router attivo scende, il router standby assume il sopravvento e continua ad inoltrare il flusso RTP precedentemente indirizzato dal primo router.

Le chiamate in uno stato temporaneo al momento del failover non verranno conservate dopo il passaggio. Ad esempio, le chiamate che non sono ancora completamente consolidate o che sono in corso di modifica con una funzione di trasferimento o attesa. Le chiamate stabilite potrebbero essere disconnesse dopo il passaggio.

I seguenti requisiti per l'uso di CUBE HA come gateway locale per il failover con stato delle chiamate:

  • Il cubo HA non può disporre di interfacce TDM o analogiche

  • Gig1 e Gig2 sono denominati interfacce di traffico (SIP/RTP) e Gig3 è un gruppo di ridondanza (RG) di controllo/interfaccia dati

  • Non è possibile inserire più di 2 coppie HA cubo nello stesso dominio di livello 2, uno con ID gruppo 1 e l'altro con ID gruppo 2. Se si configurano coppie di 2 HA con lo stesso ID gruppo, le interfacce di controllo/dati di RG devono appartenere a domini di livello 2 diversi (VLAN, switch separato)

  • Canale porta supportato per entrambe le interfacce di controllo/dati e traffico RG

  • Tutti i segnali/supporti provengono da/all'indirizzo IP virtuale

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

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

  • Identificatore interfaccia di ridondanza, rii deve essere univoco per una combinazione di coppia/interfaccia sullo stesso layer 2

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

  • Non è possibile utilizzare le interfacce di loopback come BIND come sempre in alto

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

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

  • Entrambe le piattaforme devono essere identiche e essere connesse tramite uno switch fisico attraverso tutte le interfacce SIMILARMENTE per il funzionamento del cubo ha, ad esempio, GE0/0/0 di Cube-1 e Cube-2 devono terminare sullo stesso switch e così via.

  • Impossibile avere una terminazione WAN sui cubi direttamente o dati ad alta disponibilità su entrambi i lati

  • Entrambi Active/standby deve essere nello stesso centro dati

  • È obbligatorio utilizzare l'interfaccia L3 separata per la ridondanza (RG Control/Data, Gig3). ad esempio, non è possibile utilizzare l'interfaccia utilizzata per il traffico per gli HA keepalives e il Checkpoint

  • In seguito al failover, il cubo precedentemente attivo passa attraverso un reload by design, conservando segnali e supporti

Configurazione della ridondanza su entrambi i cubi

È necessario configurare la ridondanza box-to-Box Layer 2 su entrambi i cubi destinati a essere utilizzati in una coppia HA per visualizzare gli IP virtuali.

1

Configurare il tracciamento dell'interfaccia a livello globale per tenere traccia dello stato dell'interfaccia.

conf t traccia 1 Interface GigabitEthernet1 line-protocollo di traccia 2 interfaccia GigabitEthernet2 line-uscita protocollo
VCUBE-1 # conf t
VCUBE-1 (config) #Track 1 Interface GigabitEthernet1 line-protocollo
VCUBE-1 (config-Track) #traccia 2 Interface GigabitEthernet2 line-protocollo
VCUBE-1 (config-Track) #Esci
 
VCUBE-2 # conf t
VCUBE-2 (config) #traccia 1 Interface GigabitEthernet1 line-protocollo
VCUBE-2 (config-Track) #traccia 2 Interface GigabitEthernet2 line-protocollo
VCUBE-2 (config-Track) #Esci

La funzione CLI di traccia viene utilizzata in RG per tenere traccia dello stato dell'interfaccia del traffico vocale in modo che la rotta attiva abbia un ruolo attivo una volta inattivo l'interfaccia di traffico.

2

Configurare un RG da utilizzare con VoIP HA sotto la modalità secondaria di ridondanza dell'applicazione.

ridondanza applicazione ridondante gruppo 1 nome LocalGateway-HA priorità 100 soglia di failover 75 controllo GigabitEthernet3 protocollo 1 dati GigabitEthernet3 timer ritardo 30 reload 60 traccia 1 arresto traccia 2 Arresto uscita protocollo 1 timer hellotime 3 holdtime 10 Esci da Esci uscita
VCUBE-1 (config) #ridondanza
VCUBE-1 (config-Red) #ridondanza applicazione
VCUBE-1 (config-Red-app) #gruppo 1
VCUBE-1 (config-Red-app-GRP) #Name LocalGateway-ha
VCUBE-1 (config-Red-app-GRP) #priority 100 soglia di failover 75
VCUBE-1 (config-Red-app-GRP) #controllo GigabitEthernet3 protocollo 1
VCUBE-1 (config-Red-app-GRP) #dati GigabitEthernet3
VCUBE-1 (config-Red-app-GRP) #timer ritardato 30 reload 60
VCUBE-1 (config-Red-app-GRP) #arresto della traccia 1
VCUBE-1 (config-Red-app-GRP) #traccia 2 arresto
VCUBE-1 (config-Red-app-GRP) #Esci
VCUBE-1 (config-Red-app) #protocollo 1
VCUBE-1 (config-Red-app-prtcl) #timer hellotime 3 holdtime 10
VCUBE-1 (config-Red-app-prtcl) #Esci
VCUBE-1 (config-Red-app) #Esci
VCUBE-1 (config-rosso) #Esci
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) #Name LocalGateway-ha
VCUBE-2 (config-Red-app-GRP) #priority 100 soglia di failover 75
VCUBE-2 (config-Red-app-GRP) #controllo GigabitEthernet3 protocollo 1
VCUBE-1 (config-Red-app-GRP) #dati GigabitEthernet3
VCUBE-2 (config-Red-app-GRP) #timer ritardato 30 reload 60
VCUBE-2 (config-Red-app-GRP) #arresto della traccia 1
VCUBE-2 (config-Red-app-GRP) #traccia 2 arresto
VCUBE-2 (config-Red-app-GRP) #Esci
VCUBE-2 (config-Red-app) #protocollo 1
VCUBE-2 (config-rosso-app-prtcl) #timer hellotime 3 holdtime 10
VCUBE-2 (config-Red-app-prtcl) #Esci
VCUBE-2 (config-Red-app) #Esci
VCUBE-2 (config-rosso) #Esci
VCUBE-2 (config) #

Di seguito una spiegazione dei campi utilizzati in questa configurazione:

  • ridondanza— entra in modalità di ridondanza

  • ridondanza applicazione— entra in modalità di configurazione ridondanza applicazione

  • gruppo— entra in modalità di configurazione gruppo applicazioni di ridondanza

  • nome LocalGateway-HA— definisce il nome del gruppo RG

  • Priority 100 soglia di failover 75— specifica la priorità iniziale e le soglie di failover per un RG

  • ritardo timer 30 reload 60— Configura le due volte per ritardi e ricarichi

    • Timer di ritardo che è la quantità di tempo per ritardare la negoziazione di inizializzazione e ruolo di RG Group dopo che l'interfaccia è stata eseguita, ovvero 30 secondi predefinito. Intervallo di 0-10000 secondi

    • Ricarica-questa è la quantità di tempo per ritardare l'inizializzazione del gruppo RG e la negoziazione dei ruoli dopo una ricarica – 60 secondi predefiniti. Intervallo di 0-10000 secondi

    • Si consiglia un timer predefinito, anche se questi timer possono essere regolati in modo da soddisfare eventuali ritardi di convergenza della rete aggiuntivi che si possono verificare durante l'avvio/la ricarica dei router, per garantire che la negoziazione del protocollo RG avvenga dopo che il routing nella rete si è verificato in un punto stabile. Ad esempio, se viene visualizzato dopo il failover che richiede fino a 20 sec per il nuovo STANDBY per visualizzare il primo pacchetto RG HELLO dalla nuova attività, i timer devono essere regolati a' timer Delay 60 reload 120' per fattore in questo ritardo.

  • controllo GigabitEthernet3 Protocol 1— Configura l'interfaccia utilizzata per scambiare messaggi keepalive e Hello tra i due cubi e specifica l'istanza di protocollo che verrà collegata a un'interfaccia di controllo e che entrerà in modalità di configurazione protocollo applicazione di ridondanza

  • Data GigabitEthernet3— Configura l'interfaccia utilizzata per il controllo del traffico dati

  • traccia— tracciamento del gruppo RG delle interfacce

  • protocollo 1— specifica l'istanza di protocollo che verrà collegata a un'interfaccia di controllo e che entrerà in modalità di configurazione protocollo applicazione di ridondanza

  • timer hellotime 3 holdtime 10— Configura i due timer per hellotime e holdtime:

    • Hellotime — intervallo tra messaggi Hello successivi – predefinito 3 secondi. Intervallo 250 millisecondi-254 secondi

    • Holdtime — l'intervallo tra il ricevimento di un messaggio Hello e la presunzione che il router di invio non è riuscito. Questa durata deve essere maggiore di quella di Hello-Time – predefinita di 10 secondi. Intervallo 750 millisecondi-255 secondi

      Si consiglia di configurare il timer di holdtime per almeno 3 volte il valore del timer di hellotime.
3

Abilitare la ridondanza box-to-box per l'applicazione CUBE. Configurare il RG dal passaggio precedente sotto VoIP servizio vocale. Ciò consente all'applicazione CUBE di controllare il processo di ridondanza. 

ridondanza VoIP servizio vocale-uscita gruppo 1
VCUBE-1 (config) #servizio vocale VoIP
VCUBE-1 (config-voi-serv) #ridondanza-gruppo 1
% Ha creato l'associazione RG 1 con HA vocale B2B; ricaricare il router per la nuova configurazione per l'effetto
VCUBE-1 (config-voi-serv) # Esci
 
VCUBE-2 (config) #servizio vocale VoIP
VCUBE-2 (config-voi-serv) #ridondanza-gruppo 1
% Ha creato l'associazione RG 1 con HA vocale B2B; ricaricare il router per la nuova configurazione per l'effetto
VCUBE-2 (config-voi-serv) # Esci

ridondanza-gruppo 1— aggiunta e rimozione di questo comando richiede un aggiornamento per la configurazione aggiornata. Le piattaforme verranno ricaricate dopo aver applicato tutta la configurazione.

4

Configurare le interfacce Gig1 e Gig2 con i rispettivi IP virtuali come mostrato di seguito e applicare l'identificatore di interfaccia di ridondanza (rii) 

VCUBE-1 (config) #interfaccia GigabitEthernet1
VCUBE-1 (Config-if) # ridondanza rii 1
VCUBE-1 (Config-if) # ridondanza gruppo 1 IP 198.18.1.228 esclusivo
VCUBE-1 (Config-if) # Esci
VCUBE-1 (config) #
VCUBE-1 (config) #interfaccia GigabitEthernet2
VCUBE-1 (Config-if) # ridondanza rii 2
VCUBE-1 (Config-if) # ridondanza gruppo 1 IP 198.18.133.228 esclusivo
VCUBE-1 (Config-if) # Esci
 
VCUBE-2 (config) #interfaccia GigabitEthernet1
VCUBE-2 (Config-if) # ridondanza rii 1
VCUBE-2 (Config-if) # gruppo di ridondanza 1 IP 198.18.1.228 Exclusive
VCUBE-2 (Config-if) # Esci
VCUBE-2 (config) #
VCUBE-2 (config) #interfaccia GigabitEthernet2
VCUBE-2 (Config-if) # ridondanza rii 2
VCUBE-2 (Config-if) # gruppo di ridondanza 1 IP 198.18.133.228 Exclusive
VCUBE-v (Config-if) # Esci

Di seguito una spiegazione dei campi utilizzati in questa configurazione:

  • RIIdi ridondanza — configura l'identificatore dell'interfaccia di ridondanza per il gruppo di ridondanza. Richiesto per la generazione di un indirizzo MAC virtuale (VMAC). È necessario utilizzare lo stesso valore di ID rii sull'interfaccia di ciascun router (attivo/STANDBY) con lo stesso VIP.


     

    Se sono presenti più coppie B2B sulla stessa LAN, ciascuna coppia deve avere un ID rii univoco sulle rispettive interfacce (per evitare collisioni). l'opzione ' Mostra tutti i gruppi di applicazioni di ridondanza ' deve indicare le informazioni locali e peer corrette.

  • gruppo di ridondanza 1— associa l'interfaccia al gruppo di ridondanza creato al punto 2 precedente. Configurare il gruppo RG, nonché il VIP assegnato a questa interfaccia fisica.


     

    È obbligatorio utilizzare un'interfaccia separata per la 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, l'interfaccia Gigabit 3 viene utilizzata per il controllo/dati RG

5

Salvare la configurazione del primo cubo e ricaricarla.

La piattaforma per ricaricare l'ultima volta è sempre lo standby.

VCUBE-1 #WR
Configurazione edificio...
QUINDI
VCUBE-1 #reload
Procedere con reload? merà

Dopo aver riavviato completamente Vcube-1 , salvare la configurazione di Vcube-2 e ricaricarla. 

VCUBE-2 #WR
Configurazione edificio...
QUINDI
VCUBE-2 #reload
Procedere con reload? merà
6

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

L' ultimo Vcube-2 è stato ricaricato e in base alle considerazioni di progettazione; la piattaforma per ricaricare lo scorso sarà sempre in Standby. 

VCUBE-1 #Mostra gruppo applicazioni di ridondanza tutti gli Stati di errore gruppo 1 Info: Priorità di runtime: [100] RG errori RG stato: Aggiornate. Numero totale di commutatori a causa di 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 ruolo in attivo: 1 Modifica ruolo in standby: 1 Disabilita eventi: RG stato inattivo 0, RG chiuso 0 CTRL eventi INTF: in alto 1, giù 0, admin_down 0 ricarica eventi: 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 di attesa: 10000 timer Hello peer: 3000, timer di 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 di attesa: 10000 pkts 61, byte 2074, HA Seq 0, numero SEQ 69, perdita PKT 0 VCUBE-1 #
VCUBE-2 #Mostra gruppo applicazioni di ridondanza tutti gli Stati di errore gruppo 1 Info: Priorità di runtime: [100] RG errori RG stato: Aggiornate. Numero totale di commutatori a causa di 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 ruolo in attivo: 1 Modifica ruolo in standby: 1 Disabilita eventi: RG stato inattivo 0, RG chiuso 0 CTRL eventi INTF: in alto 1, giù 0, admin_down 0 ricarica eventi: 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 di attesa: 10000 timer Hello peer: 3000, timer di 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 di 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 cubi

Nella nostra configurazione di esempio, stiamo utilizzando le seguenti informazioni da Webex 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: Hussain1076_LGU

  • Password: lOV12MEaZx

1

Accertarsi che venga creata una chiave di configurazione per la password, con i comandi riportati di seguito, prima che possa essere utilizzato nelle credenziali o nei segreti condivisi. Le password di tipo 6 vengono crittografate utilizzando la crittografia AES e questa chiave di configurazione definita dall'utente. 

LocalGateway # conf t LocalGateway (config) #chiave config-password chiave-cifrare 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 di digest SIP di controllo JUB sono evidenziate in grassetto. 

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 85.119.56.128 255.255.255.192 ipv4 85.119.57.128 255.255.255.192 ipv4 185.115.196.0 255.255.255.128 ipv4 185.115.197.0 255.255.255.128 ipv4 199.59.64.0 255.255.255.128 ipv4 199.59.65.0 255.255.255.128 ipv4 199.59.66.0 255.255.255.128 ipv4 199.59.67.0 255.255.255.128 ipv4 199.59.70.0 255.255.255.128 ipv4 199.59.71.0 255.255.255.128 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 "<sip:(.*)" "<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 codec preference 3 g729r8 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:1a01.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

Per visualizzare il comando Mostra output, abbiamo ricaricato Vcube-2 seguito da Vcube-1, rendendo VCUBE-1 il cubo di standby e Vcube-2 il cubo attivo

2

In un determinato momento, solo una piattaforma manterrà una registrazione attiva come gateway locale con il Webex Calling Access SBC. Dare un'occhiata all'output dei seguenti comandi Mostra.

Mostra gruppo applicazioni ridondanza 1

Mostra stato SIP-UA-registra

VCUBE-1 #Mostra ridondanza gruppo di applicazioni 1 ID gruppo: 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 in STANDBY: VCUBE attivo-1 #Mostra stato SIP-UA Register Vcube-1 #
VCUBE-2 #Mostra ridondanza gruppo di applicazioni 1 ID gruppo: 1 nome gruppo: LOCALGATEWAY-ha stato amministrativo: Nessuno stato operativo aggregazione di arresto: 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--------------------registrar-indice 1---------------------riga peer scade (sec) reg Survival P-associ-URI = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =-= = = Hussain5091_LGU-1 48 sì normale VCUBE-2 #

Dall'output precedente, è possibile vedere che Vcube-2 è il LGW attivo che mantiene l'iscrizione con Webex Calling Access SBC, mentre l'output dello "Show SIP-UA Register status" è vuoto in Vcube-1
3

Ora abilitare i seguenti debugger su VCUBE-1

VCUBE-1 #debug ccsip non-chiamata SIP finestra di dialogo di analisi è abilitata Vcube-1 #debug Ccsip info SIP chiamata Info traccia è abilitata Vcube-1 #messaggio ccsip di debug
4

Simulare il failover emettendo il seguente comando su LGW attivo, VCUBE-2 in questo caso.

VCUBE-2 #ridondanza Application reload Group 1 auto

Il passaggio da attivo a LGW STANDBY si verifica anche nel seguente scenario oltre alla CLI elencata sopra

  • Quando il router attivo viene ricaricata
  • Quando il router attivo attiva i cicli di
  • Quando qualsiasi interfaccia configurata da RG del router attivo è in arresto per la quale è abilitato il rilevamento
5

Controllare se VCUBE-1 è stato registrato con Webex Calling Access SBC. VCUBE-2 sarebbe stato ricaricato da ora.

VCUBE-1 #Mostra SIP-UA registro stato tenant: 200--------------------registrar-indice 1---------------------riga peer scade (sec) reg Survival P-associ-URI = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =-= = = Hussain5091_LGU-1 56 sì normale Vcube-1 #

VCUBE-1 è ora il LGW attivo.
6

Esaminare il log di debug pertinente su VCUBE-1 inviando un registro SIP per Webex Calling tramite l'IP virtuale e ricevendo un 200 OK. 

VCUBE-1 # Mostra registro Jan 9 18:37:24.769: % RG_MEDIA -3-TEMPO SCADUTO: RG ID 1 Hello Time scaduto. Gen 9 18:37:24.771: % RG_PROTCOL -5-ROLECHANGE: Modifica ruolo RG ID 1 da standby a attivo 9 18:24.783: % VOICE_HA-2-SWITCHOVER_IND: AVANZAMENTO, da STANDBY_HOT allo stato attivo. Gen 9 18:37:24.783: -1/xxxxxxxxxxxx/SIP/INFO/info/4096/sip_ha_notify_active_role_event: Evento ha ricevuto notifica ruolo attivo Jan 9 18:37:25.758: -1/xxxxxxxxxxxx/SIP/msg/ccsipDisplayMsg: Data invio: Esegui iscrizione 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 contatto di iscrizione: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Scade: 240 supportato: Contenuto percorso-Lunghezza: 0
Gen 9 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-data 1578595045969: 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
Gen 9 18:37:26.000: -1/xxxxxxxxxxxx/SIP/msg/ccsipDisplayMsg: Data invio: 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 contatto di iscrizione: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Scade: 240 supportato: Autorizzazione percorso: Digest username = "Hussain1076_LGU", Realm = "BroadWorks", URI = "SIPS:40462196. Cisco-bcld. com: 5061", Response = "b6145274056437b9c07f7ecc08ebdb02", nonce = "BroadWorksXk572qd01Ti58z1iBW", cnonce = "3E0E2C4D", qop = autenticazione, algoritmo = MD5, NC = 00000001 contenuto-lunghezza: 0
Gen 9 18:37:26.190: 1/000000000000/SIP/msg/ccsipDisplayMsg: Ricevuto: SIP/2.0 200 OK tramite: 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 contatto di iscrizione: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>; scade = 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