Fondamenti

Prerequisiti

Prima di distribuire CUBE HA come gateway locale per Webex Calling, accertarsi di disporre di informazioni approfondite sui 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 aziendale CUBE esistente per utilizzare anche la funzione gateway locale per Cisco Webex Calling, prestare attenzione alla configurazione applicata per garantire che i flussi di chiamata e le funzionalità esistenti non vengano interrotte e che si sia soddisfatti dei 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 e i registri visualizzati 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 riportati alcune guide alla configurazione di CUBE HA per diverse piattaforme:

Webex Calling panoramica della soluzione

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

La distribuzione del gateway locale (rappresentata di seguito) è al centro di questo articolo. Trunk locale (PSTN locale) in Webex Calling consente la connettività a un servizio di assistenza PSTN cliente. Fornisce anche la connettività a una distribuzione IP PBX on-premises, ad esempio Cisco Unified CM. Tutte le comunicazioni da e verso il cloud vengono protette utilizzando il trasporto TLS per SIP e SRTP per il contenuto multimediale.

La figura seguente mostra una Webex Calling di amministrazione senza un IP PBX esistente ed è applicabile a una distribuzione singola o multi-sito. La configurazione descritta in questo articolo si basa su questa distribuzione.

Ridondanza layer 2 box-to-box

Cube HA layer 2 ridondanza box-to-box utilizza il protocollo dell'infrastruttura RG (Redundancy Group) per formare una coppia di router attivi/in standby. Questa coppia condivide lo stesso indirizzo IP virtuale (VIP) sulle relative interfacce e scambia continuamente messaggi di stato. Le informazioni della sessione CUBE sono verificate su tutta la coppia di router consentendo al router di standby di assumere tutte le responsabilità di elaborazione delle chiamate CUBE immediatamente se il router attivo esce dal servizio, determinando una conservazione dello stato dei segnali e dei supporti.

Il check pointing è limitato alle chiamate connesse con pacchetti multimediali. Le chiamate in viaggio non vengono controllate (ad esempio, uno stato di tentativo o di suoneria).

In questo articolo, CUBE HA fa riferimento a CUBE High Availability (HA) Layer 2 Box-to-box (B2B) per la ridondanza stateful conservazione chiamata

A causa di IOS-XE 16.12.2, CUBE HA può essere distribuito come gateway locale per distribuzioni di Cisco Webex Calling trunk (PSTN basato su premises) 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 Cisco Webex Calling trunk.

Componente infrastruttura gruppo di ridondanza

Il componente Infra del gruppo di ridondanza (RG) fornisce il supporto dell'infrastruttura di comunicazione box-to-box tra i due CUB 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 salve tra i dueUB (tramite l'interfaccia di controllo), GigabitEthernet3 nella figura precedente.

  • Un meccanismo di trasporto per il controllo dei segnali e dello stato multimediale per ciascuna chiamata da attivo al router di standby (tramite 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 in modo specifico per supportare il sistema vocale B2B HA.

Gestione degli indirizzi IP virtuali (VIP) per segnale e multimediale

B2B HA si basa sul VIP per ottenere la ridondanza. L'indirizzo 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, Webex Calling a SBC, 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 Webex Calling punto di vista, le coppie di CUBE HA agisce come un singolo gateway locale.

Il segnale di chiamata e le informazioni della sessione RTP delle chiamate stabilite vengono posti in punto di controllo dal router attivo al router di standby. Quando il router Attivo non è attivo, il router di standby riprende e continua a inoltrare il flusso RTP precedentemente inoltrato dal primo router.

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

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

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

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

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

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

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

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

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

  • Identificativo interfaccia di ridondanza, rii deve essere univoco per una combinazione di accoppiamento/interfaccia nello stesso livello 2

  • La configurazione su entrambi iUB 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 up

  • Interfacce con più traffico (SIP/RTP) (Gig1, Gig2) richiedono la configurazione del monitoraggio dell'interfaccia

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

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

  • Impossibile impostare LA WAN come terminata direttamente su CD O DATA HA su entrambi i lati

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

  • È obbligatorio utilizzare un'interfaccia L3 separata per ridondanza (controllo RG/dati, Gig3). e l'interfaccia utilizzata per il traffico non può essere utilizzata per ha keepalives e punto di controllo

  • Al momento del failover, il CUBE precedentemente attivo passa attraverso un ricaricamento per impostazione predefinita, conservando segnali e supporti

Configurazione della ridondanza su entrambi iUB

È necessario configurare la ridondanza di livello 2 box-to-box su entrambi iUB da utilizzare 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 track 1 interfaccia 
 GigabitEthernet1 linea-protocollo traccia 2 interfaccia 
 GigabitEthernet2 uscita protocollo linea

VCUBE-1#conf.
VCUBE-1(config)#traccia un'interfaccia GigabitEthernet1 protocollo linea
VCUBE-1(config-track)#traccia 2 interfaccia GigabitEthernet2 line-protocol
VCUBE-1(config-track)#uscita
 
VCUBE-2#conf.
VCUBE-2(config)#traccia 1 interfaccia GigabitEthernet1 line-protocol
VCUBE-2(config-track)#traccia 2 interfaccia GigabitEthernet2 line-protocol
VCUBE-2(config-track)#uscita

La traccia CLI viene utilizzata in RG per tenere traccia dello stato dell'interfaccia del traffico vocale in modo che l'instradare attivo non dia il proprio ruolo attivo una volta che l'interfaccia del traffico è in basso.
2

Configurare un RG per l'uso con VoIP HA nella sotto 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

RIDONDANZA VCUBE-1(config)#
VCUBE-1(config-red)#ridondanza dell'applicazione
VCUBE-1(config-red-app)#gruppo 1
VCUBE-1(config-red-app-grp)#nome LocalGateway-HA
VCUBE-1(config-red-app-grp)#priorità 100 soglia di failover 75
VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1
VCUBE-1(config-red-app-grp)#dati GigabitEthernet3
VCUBE-1(config-red-app-grp)# timer conritardo di 30 ricaricamento 60
VCUBE-1(config-red-app-grp)#tracciare l'arresto di 1
VCUBE-1(config-red-app-grp)#arresto track 2
VCUBE-1(config-red-app-grp)#uscita
VCUBE-1(config-red-app)#protocollo 1
VCUBE-1(config-red-app-prtcl)#timer salvetime 3 holdtime 10
VCUBE-1(config-red-app-prtcl)#uscita
VCUBE-1(config-red-app)#uscita
VCUBE-1(config-red)#uscita
VCUBE-1(config) #
 
Ridondanza VCUBE-2(config)#
VCUBE-2(config-red)#ridondanza dell'applicazione
VCUBE-2(config-red-app)#gruppo 1
VCUBE-2(config-red-app-grp)#nome LocalGateway-HA
VCUBE-2(config-red-app-grp)#priorità 100 soglia di failover 75
VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1
VCUBE-1(config-red-app-grp)#dati GigabitEthernet3
VCUBE-2(config-red-app-grp)# timer con ritardodi 30 ricaricamento 60
VCUBE-2(config-red-app-grp)#tracciare l'arresto di 1
VCUBE-2(config-red-app-grp)#arresto track 2
VCUBE-2(config-red-app-grp)#uscita
VCUBE-2(config-red-app)#protocollo 1
VCUBE-2(config-red-app-prtcl)#timer salvetime 3 holdtime 10
VCUBE-2(config-red-app-prtcl)#uscita
VCUBE-2(config-red-app)#uscita
VCUBE-2(config-red)#uscita
VCUBE-2(config) #

Di seguito una spiegazione dei campi utilizzati in questa configurazione:

  • ridondanza: attiva la modalità di ridondanza

  • ridondanzaapplicazione: inserisce la modalità di configurazione della ridondanza dell'applicazione

  • gruppo—Inserisce la modalità di configurazione del gruppo di applicazione ridondante

  • name LocalGateway-HA—Definisce il nome del gruppo RG

  • priorità 100 soglia di failover 75 —Specifica la priorità iniziale e lesoglie di failover per un RG

  • timer ritardo 30 ricaricamento 60—Configura i due tempi diritardo e ricaricamento

    • Timer di ritardo che rappresenta la quantità di tempo per ritardare l'inizializzazione e la negoziazione del ruolo del gruppo RG dopo la visualizzazione dell'interfaccia – 30 secondi predefiniti. Intervallo 0-10000 secondi

    • Ricaricamento: questo è il tempo che necessario per ritardare l'inizializzazione del gruppo RG e la negoziazione del ruolo dopo un ricaricamento– 60 secondi predefiniti. Intervallo 0-10000 secondi

    • Si consiglia il timer predefinito, sebbene questi timer possano essere regolati per regolare eventuale ritardo di convergenza della rete che si può verificare durante l'avvio/ricaricamento dei router, al fine di garantire che la negoziazione del protocollo RG venga eseguita dopo che l'instradamento nella rete è diventato un punto stabile. Ad esempio, se dopo il failover si verifica che sono necessari fino a 20 sec per il nuovo STANDBY per visualizzare il primo pacchetto RG HELLO dal nuovo ACTIVE, i timer devono essere regolati in 'timer con ritardo 60 ricaricamento 120' da prendere in conto in questo ritardo.

  • control GigabitEthernet3 protocol 1 — Configura l'interfaccia utilizzata per scambiare messaggi keepalive e salve tra i due CUB e specifica l'istanza del protocollo che verrà collegata a un'interfaccia di controllo e inserisce la modalità di configurazione del protocollo dell'applicazione di ridondanza

  • dati GigabitEthernet3: configura l'interfaccia utilizzata per il punto dicontrollo del traffico dati

  • traccia—Tracciamento gruppo RG delle interfacce

  • protocollo 1 —Specifica l'istanza del protocollo che verrà collegata a un'interfaccia di controllo e inserisce la modalità di configurazione del protocollodell'applicazione di ridondanza

  • timer salvetime 3 holdtime 10 —Configura i due timer persalvetime e holdtime:

    • Salvetime: intervallo tra messaggi salve successivi – Predefinito 3 secondi. Intervallo 250 millisecondi-254 secondi

    • Holdtime: intervallo tra la ricezione di un messaggio Salve e la presunzione che il router di invio non è riuscito. Questa durata deve essere maggiore del tempo di salve – Valore predefinito 10 secondi. Intervallo 750 millisecondi-255 secondi

      Si consiglia di configurare il timer del tempo di attesa in modo che sia almeno 3 volte il valore del timer salvetime.
3

Abilitare 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)#servizio vocale voip
VCUBE-1(config-voi-serv)#ridondanza-gruppo 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)#servizio vocale voip
VCUBE-2(config-voi-serv)#ridondanza-gruppo 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

gruppo di ridondanza 1: l'aggiunta e la rimozione di questo comando richiede un ricaricamento per l'applicazionedella configurazione aggiornata. Le piattaforme verranno ricaricate una volta applicata tutta la configurazione.
4

Configurare le interfacce Gig1 e Gig2 con i relativi IP virtuali come mostrato di seguito e applicare l'identificativo dell'interfaccia diridondanza ( rii)

VCUBE-1(config)#interfaccia GigabitEthernet1
VCUBE-1(config-if)# ridondanza 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)# ridondanza 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)# ridondanza 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)# ridondanza rii 2
VCUBE-2(config-if)# gruppo di ridondanza 1 ip 198.18.133.228 esclusivo
USCITA VCUBE-v(config-if)#

Di seguito una spiegazione dei campi utilizzati in questa configurazione:

  • Riiridondanza: 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 rii ID 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 che si verificano altri rii ID). 'mostra gruppo applicazioni ridondanza tutti' deve indicare le informazioni corrette locale e peer.

  • Gruppo di ridondanza1: associa l'interfaccia al gruppo di ridondanza creato al punto 2 precedente. Configurare il gruppo RG e il VIP assegnato a questa interfaccia fisica.


     

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

Salvare la configurazione del primo CUBE e ricaricarlo.

La piattaforma per il ricaricamento ultimo è sempre la modalità Standby.

VCUBE-1#wr

  Configurazione edificio...


  [OK]

VCUBE-1#ricaricamento

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

  Continuare con il ricaricamento? [conferma]
6

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

Il caricamento di VCUBE-2 ultimo e in base alle considerazioni di progettazione; la piattaforma per il ricaricamento ultimo sarà sempre Standby.


VCUBE-1# mostra il gruppo di applicazioni diridondanza tutti gli stati di errore Stati Gruppo 1 informazioni:
       Priorità runtime: [100] 
               Errori RG Stato RG: In alto.
                       N. totale di switch dovuti a errori:           0 
                       N. totale di modifiche di stato in down/up a causa di errori: 0 ID gruppo:1 
 Nome gruppo:Stato amministrativo LocalGateway-HA: Nessun stato 
 operativo aggregato di arresto: In alto il mio ruolo: Ruolo 
 peer ACTIVE: Presenza peer STANDBY: Sì 
 Comm peer: Sì 
 Peer Peer avviato: Sì 
 
 Dominio RF: stato 
         RF btob-one: Stato 
         ACTIVE Peer RF: Standby HOT 
 
 RG Protocollo RG 1 
 ------------------ 
 ruolo: Negoziazione 
        attiva: Priorità 
        abilitata: 100 
        Stato protocollo: Stato 
        Attivo Ctrl Intf(i): Peer 
        attivo attivo attivo: Peer standby locale: indirizzo 10.1.1.2, priorità 100, intf Gi3         Log contatori:
                modifica del ruolo in attivo: 1 
                modifica di ruolo in standby: 1 
                evento disabilitato: rg down state 0, rg shut 0 
                ctrl intf events: up 1, down 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: Timer salve corrente gigabitEthernet3: Timer Salve configurato per 3000: 3000, Timer attesa: Timer 10000 
        Peer Salve: 3000, Timer attesa peer: 10000 
        Statistiche:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 
            Authentication not configured 
            Authentication Failure: 0 
            Peer di ricaricamento: Dimettersi TX 0, RX 
            0: TX 0, RX 0 
    Peer autonomo: Presente. Timer attesa: 10000 
 Pkts 61, Byte 2074, HA Seq 0, Numero Seq 69, Perdita Pkt 0 
 
 VCUBE-1 #

VCUBE-2# mostra il gruppo di applicazioneridondanza tutti gli stati di errore Stati Gruppo 1 informazioni:
       Priorità runtime: [100] 
               Errori RG Stato RG: In alto.
                       N. totale di switch dovuti a errori:           0 
                       N. totale di modifiche di stato in down/up a causa di errori: 0 ID gruppo:1 
 Nome gruppo:Stato amministrativo LocalGateway-HA: Nessun stato 
 operativo aggregato di arresto: In alto il mio ruolo: Ruolo 
 peer STANDBY: PRESENZA peer ACTIVE: Sì 
 Comm peer: Sì 
 Peer Peer avviato: Sì 
 
 Dominio RF: stato 
         RF btob-one: Stato 
         ACTIVE Peer RF: Standby HOT 
 
 RG Protocollo RG 1 
 ------------------ 
 ruolo: Negoziazione 
        attiva: Priorità 
        abilitata: 100 
        Stato protocollo: Stato 
        Attivo Ctrl Intf(i): Peer         attivo attivo attivo: indirizzo 10.1.1.2, priorità 100, intf Gi3         Standby Peer: Contatori 
        log locali:
                modifica del ruolo in attivo: 1 
                modifica di ruolo in standby: 1 
                evento disabilitato: rg down state 0, rg shut 0 
                ctrl intf events: up 1, down 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: Timer salve corrente gigabitEthernet3: Timer Salve configurato per 3000: 3000, Timer attesa: Timer 10000 
        Peer Salve: 3000, Timer attesa peer: 10000 
        Statistiche:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 
            Authentication not configured 
            Authentication Failure: 0 
            Peer di ricaricamento: Dimettersi TX 0, RX 
            0: TX 0, RX 0 
    Peer autonomo: 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 iUB

Nella configurazione dell'esempio, stiamo utilizzando le seguenti informazioni 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: Hussain1076_LGU

  • Password: lOV12MEaZx

1

Assicurarsi che venga creata una chiave di configurazione per la password, con i comandi riportati di seguito, prima di poterla utilizzare nelle credenziali o condividere i dati. Le password di tipo 6 vengono crittografate utilizzando la crittografia AES e questa chiave di configurazione definita dall'utente.


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

Questa è la configurazione del gateway locale che verrà applicata a entrambe le piattaforme in base ai parametri di Control Hub visualizzati sopra, salvare e ricaricare. Le credenziali SIP digest di Control Hub sono evidenziate in grassetto.


configurare terminal 
 crypto pki trustpoint dummyTp revoca controllo crl uscita 
 
 
 sip-ua 
 crypto signaling predefinito trustpoint dummyTp cn-san-validate server transport tcp tls v1.2 end configure terminal crypto pki trustgu import clean url end configure terminal voice service ip address trusted list ipv4 x.x.x.x.x y.y.y uscita consenti-connessioni sip a statistiche multimediali sip statistiche multimediali statistiche multimediali nessun sip supplementale servizio SIP fare riferimento a nessun handle sip supplementario-servizio sostituisce http://www.cisco.com/security/pki/trs/ios_core.p7b pass-through del protocollo fax 
 
 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 " " " " ( " rule<sips:(.*)" "<sip:\1" rule="" 11="" request="" ANY="" sip-header="" From="" modify=""></sip:\1"><sips:(.*)" "<sip:\1" rule="" 12="" request="" ANY="" sip-header="" Contact="" modify=""></sip:\1"><sips:(.*)>13 response ANY<sip:\1;transport=tls>SIP-header To modify<sips:(.*)" "<sip:\1" rule="" 14="" response="" ANY="" sip-header="" From="" modify=""></sip:\1"><sips:(.*)" "<sip:\1" rule="" 15="" response="" ANY="" sip-header="" Contact="" modify=""></sip:\1"><sips:(.*)"
"<sip:\1" rule="" 20="" request="" ANY="" sip-header="" From="" modify="">"
";otg=<sajan index="1" />hussain1076_lgu<sajan index="2" />>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar <sajan index="3" />" " " 
 ";otg= hussain1076_lgu > regola 30 richiede QUALSIASI intestazioneSIPP-Asserzione-Identità modifica 
 "sips:(.*)" "sip:\1" codec classe vocale 
 
 
 99 
 preferenze codec 1 g711ulaw codec preferenza codec 2 g711ulaw esci da classe vocale 
 
 
 
 srtp-crypto 200 crypto 1 AES_CM_128_HMAC_SHA1_80 uscita da classe vocale 
 
 
 
 stun-usage 200 stun usage firewall-traversal flow dati uscita classe vocale 
 tenant 
 
 
 
 
 
 
 
 200 registrar dns:40462196.schema cisco-bcld.com scadenza 240 rapporto di aggiornamento 50 credenziali tcp tls numero Hussain5091_LGU nome utente Hussain1076_LGU password  0 lOV12MEaZx area di autenticazione Broadworks nome utente autenticazione Hussain5091_LGU password   0 lOV12MEaZx area di autenticazione Broad Hussain5091_LGU Works nome utente password   0 lOV12MEaZx area di autenticazione 40462196.cisco-bcld.com nessun dns    sip-server sip-server remote:40462196.cisco-bcld.com   connection-reuse 
 srtp-crypto 200 sessione transport 
 tcp tls url 
 sips 
 error-passthru 
 asserted-id pai bind control 
 source interface GigabitEthernet1 
 associazione origine multimediale GigabitEthernet1 non 
 pass-thru contenuto personalizzato-sdp 
 profili sip 200 in uscita-proxy dns:la01.sipconnect-us10.cisco-bcld.com privacy-policy passthru tenant classe vocale 2 100 sessione di trasporto udp url sip error-passthru associazione interfaccia origine di controllo GigabitEthernet2 associazione interfaccia origine multimediale   GigabitEthernet2 nessun contenuto personalizzato-sdp classe vocale 
 tenant 
 
 300 associazione control 
 source-interface GigabitEthernet2 
 bind media source-interface GigabitEthernet2 
 no pass-thru content custom-sdp 
 
 
 voice class uri 100 sip 
 host ipv4:198.18.18. 133.3 voce 
 
 class uri 200 percorso sip 
 dtg=hussain1076.lgu    dial-peer voice 101 descrizione voip 
 Dial-peer in 
 uscita a percorso di destinazione PSTN BAD. Protocollo sessione BAD 
 sipv2 destinazione sessione 
 ipv4:198.18.133.3 codec codec classe vocale 99 tenant sip classe vocale 
 
 100 
 dtmf-relay rtp-nte 
 nessun dial-peer vocale vad 
 
 201 Descrizione voip Uscita 
 dial-peer Webex Calling 
 percorso di destinazione BAD. Sessione BAD protocollo 
 sipv2 destinazione 
 sessione sip-server 
 voice-class codec 99 classe vocale 
 stun-usage 200 nessun sip localhost classe vocale sip classe vocale sip tenant 
 
 200 
 dtmf-relay rtp-nte srtp nessuna classe vocale 
 
 
 
 
 vad dpg 100 descrizione 
 Incoming WebexCalling(D Da P200) a IP PSTN(DP101) 
 dial-peer 101 preferenza 1 classe vocale 
 
 dpg 200 descrizione 
 Incoming IP PSTN(DP100) a Webex Calling(DP201) 
 dial-peer 201 preferenza 1 
 
 
 
 
 
 dial-peer voice 1 00 voip desription Dial-peer in ingresso da IP PSTN protocollo sessione sipv2 destinazione dpg 200 uri in ingresso tramite 100 codec di classe vocale 
 
 
 
 
 99 
 voice-class sip tenant 300 
 dtmf-relay rt

Per visualizzare l'output del comando di visualizzazione, è stato caricato VCUBE-2 seguito daVCUBE-1, rendendoVCUBE-1 il CUBE di standby e VCUBE-2 il CUBE attivo
2

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

mostra ridondanza gruppo applicazione 1

mostra stato registrazione sip-ua


VCUBE-1# mostra ridondanza applicazione gruppo1 ID gruppo:1 
 Nome gruppo:LocalGateway-HA 
 
 Stato amministrativo: Nessun stato 
 operativo aggregato di arresto: Up My Role: Ruolo peer standby: PRESENZA 
 peer ACTIVE: Sì 
 Comm peer: Sì 
 Peer Peer avviato: Sì 
 
 Dominio RF: stato 
         RF btob-one: STATO HOT 
         Peer RF STANDBY: ACTIVE 
 
 VCUBE-1# mostra stato iscrizioneSIP-ua VCUBE-1 #

VCUBE-2# mostra ridondanza applicazione gruppo1 ID gruppo:1 
 Nome gruppo:LocalGateway-HA 
 
 Stato amministrativo: Nessun stato 
 operativo aggregato di arresto: Up My Role: Ruolo peer ACTIVE: STATO 
 Peer Presence: Sì 
 Comm peer: Sì 
 Peer Peer avviato: Sì 
 
 Dominio RF: stato 
         RF btob-one: Stato 
         ACTIVE Peer RF: STANDBY HOT 
 
 VCUBE-2#mostra stato registrazione sip-ua  Tenant: 200 
 --------------------Registrar-Index 1 --------------------- Linea peer expire (sec) reg p-Associ-URI =================================== 
 
 =========== =========== === ======== ============ 
 Hussain5091_LGU -1 48 sì 
 VCUBE-2 normale #

Dall'output precedente, è possibile visualizzare che VCUBE-2 è l'LGW attivo che mantiene l'iscrizione con accesso Webex Calling SBC, mentre l'output dello "mostra stato di registro sip-ua" è vuoto in VCUBE-1
3

Ora abilitare i seguenti debug su VCUBE-1


VcUBE-1# debug ccsip non-call La funzionalità di analisi out-of-Dialog SIP è abilitata per la funzionalità di tracciamento ccsip di debug VCUBE-1# info ccsip di debug abilitata Funzionalità di traccia delle chiamate SIP VCUBE-1#messaggio ccsip di debug
4

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


VCUBE-2# applicazionedi ridondanza ricarica gruppo 1 auto

L'passaggio da ACTIVE a STANDBY LGW si verifica anche nel seguente scenario oltre alla CLI sopra elencata

  • Quando il router ACTIVE viene ricaricato

  • Quando l'alimentazione del router ACTIVE si cicli

  • Quando un'interfaccia configurata RG del router ACTIVE è in posizione di arresto per la quale è abilitata la verifica
5

Controllare per vedere se VCUBE-1 è stato registrato con Webex Calling accesso SBC. VCUBE-2 dovrebbe essere stato ricaricato ora.


VCUBE-1#show sip-ua register status Tenant (Tenant stato registrazione SIP-ua): 200 
 --------------------Registrar-Index 1 --------------------- Linea peer expire (sec) reg ore P-Associ-URI ================================= 
 
 =========== =========== === ========= =========== Hussain5091_LGU -1 56 sì NORMALE VCUBE-1 #

VCUBE-1 è ora l'LGW attivo.
6

Esaminare il registro di debug pertinente su VCUBE-1 in invio di un SIP REGISTER Webex Calling tramite IP virtuale e ricezione di un sistema DA 200 OK.


VCUBE-1#show log 
 
 9 gen 18:37:24.769: %RG_MEDIA-3-TIMEREX: RG ID 1 Salve Tempo scaduto.
9 gen 18.37:24.771: %RG_PROTCOL-5-ROLECHANGE: Modifica del ruolo RG ID 1 da Standby 
 a Attivo 9 gennaio 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: PASSAGGIO, da STANDBY_HOT allo stato ACTIVE.
9 gen 18.37:24.783: -1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Ricevuto notifica evento ruolo attivo 
 
 9 gennaio 18.37.25.758: -1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Data invio:
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 
 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Data: Gio 09 gen 2020 18:37:24 GMT 
 ID chiamata: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Agente 
 utente: Cisco-SIPGateway/IOS-16.12.02 
 Max-Forward: 70 Data 
 e ora: 1578595044 
 CSeq: 2 REGISTRA 
 contatto: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Scade: 240 
 supportati: percorso 
 Contenuto-Lunghezza: 0

9 gen 18.37:25.995: -1/00000000000/SIP/Msg/ccsipDisplayMsg:
Ricevuto:
SIP/2.0 401 Non autorizzato tramite: SIP/2.0/TLS 198.18.1.228:5061;ricevuto=173.38.218.1;branch=z9hG4bK0374;rport=4742 
 Da: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 
 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 
 Data: Gio 09 gen 2020 18:37:24 GMT 
 ID chiamata: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 
 Timestamp: 1578595044 
 CSeq: 2 ESEGUIRE 
 L'ISCRIZIONE WWW-Authenticate; Area di autenticazione DIGEST="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algoritmo=Lunghezza contenuto 
 MD5: 0

9 gen 18.37:26.000: -1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Data invio:
ESEGUIRE l'iscrizione a 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 
 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Data: Gio 09 gen 2020 18:37:25 GMT 
 ID chiamata: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 
 Agente-Utente:Cisco-SIPGateway/IOS-16.12.02 
 Max-inoltro: 70 Data 
 e ora: 1578595045 
 CSeq: 3 ISCRIZIONE 
 Contatto: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Scade: 240 
 supportati: percorso 
 autorizzazione: Nome utente digest="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/00000000000/SIP/Msg/ccsipDisplayMsg:

Ricevuto:
SIP/2.0 200 OK tramite: SIP/2.0/TLS 198.18.1.228:5061;ricevuto=173.38.218.1;branch=z9hG4bK16DC;rport=4742 
 Da: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 
 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 
 ID chiamata: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 
 Timestamp: 1578595045 
 CSeq: 3 ISCRIZIONE 
 Contatto: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 
 Consenti-eventi: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference 
 Content-Length: 0