Fondamenti
Prerequisiti
Prima di distribuire CUBE HA come gateway locale per Webex Calling, accertarsi di disporre di informazioni approfondite sui seguenti concetti:
Ridondanza box-to-box layer 2 con CUBE Enterprise per file conservazione chiamata
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:
CSR 1000v (vCUBE)–https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Architettura preferita Cisco per Cisco Webex Calling–https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
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.
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.
Di seguito una spiegazione dei campi utilizzati in questa configurazione:
|
||||||
3 | Abilitare la ridondanza box-to-box per l'applicazione CUBE. Configurare RG dal punto precedente in
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)
Di seguito una spiegazione dei campi utilizzati in questa configurazione:
|
||||||
5 | Salvare la configurazione del primo CUBE e ricaricarlo. La piattaforma per il ricaricamento ultimo è sempre la modalità Standby.
Dopo aver avviato completamente VCUBE-1, salvare la configurazione di VCUBE-2 e ricaricarla.
|
||||||
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.
|
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.
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.
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
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
|
4 | Simulare il failover emettendo il seguente comando sull'LGW attivo, VCUBE-2 in questo caso.
L'passaggio da ACTIVE a STANDBY LGW si verifica anche nel seguente scenario oltre alla CLI sopra elencata
|
5 | Controllare per vedere se VCUBE-1 è stato registrato con Webex Calling accesso SBC. VCUBE-2 dovrebbe essere stato ricaricato ora.
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.
|