- Home
- /
- Articolo
Implementazione di alta disponibilità CUBE come gateway locale
Il gateway locale (LGW) è la soluzione esclusiva per fornire accesso PSTN locale a clienti Cisco Webex Calling. Questo documento guida nella configurazione di un gateway locale utilizzando alta disponibilità CUBE, con CUBE attivi o in standby per garantire il failover con stato delle chiamate attive.
Nozioni fondamentali
Prerequisiti
Prima di distribuire l'alta disponibilità (HA) Cisco Unified Border Element (CUBE) come gateway locale per Webex Calling, assicurati di aver compreso approfonditamente i seguenti concetti:
-
Ridondanza box-to-box layer 2 con CUBE Enterprise per conservazione delle chiamate con stato
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 17.9.1 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 17.9.1 implementata su vCUBE (CSR v).
Materiale di riferimento
Di seguito sono riportate alcune guide alla configurazione di CUBE HA dettagliate per diverse piattaforme:
-
Cisco ISR 4K e Cisco Catalyst serie 8K— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-isr-g3.html
-
CSR430 v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-csr.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
Panoramica della soluzione Webex Calling
Cisco Webex Calling è un'offerta di collaborazione che fornisce 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 inoltre 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 sulla 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 servizio, con conseguente conservazione di segnali e contenuti multimediali.
La verifica è limitata alle chiamate connesse con pacchetti multimediali. Le chiamate in transito non vengono verificate (ad esempio, tentativi di chiamata o chiamate in arrivo).
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 17.9.1, CUBE HA può essere distribuito come gateway locale per distribuzioni di trunk Cisco Webex Calling (PSTN locale). In questo articolo vengono descritte alcune considerazioni di progettazione e configurazioni. La figura 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) 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 inoltre:
-
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 segnalazione e multimediale 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 (è 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 segnali e contenuti multimediali
B2B HA si basa su VIP 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 di segnalazione 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 transitorio 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 con stato 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'altro 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, si avvia sempre come Standby
-
L'indirizzo inferiore per tutte le interfacce (Gig1, Gig2, Gig3) deve essere sulla stessa piattaforma
-
L'identificatore 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
-
Le interfacce di loopback non possono essere utilizzate come associazione poiché sono sempre attive
-
Più interfacce di traffico (SIP/RTP) (Gig1, Gig2) richiedono la configurazione del monitoraggio 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.
-
Impossibile impostare WAN con terminazione diretta su CUBE 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), 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
Configura 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 monitoraggio dell'interfaccia a livello globale per monitorare lo stato dell'interfaccia.
La funzione CLI di rilevamento viene utilizzata in RG per monitorare lo stato dell'interfaccia di traffico vocale in modo che il percorso attivo esca dal ruolo attivo una volta inattiva l'interfaccia di traffico. | ||
2 |
Configura un RG per l'uso con VoIP HA nella modalità secondaria di ridondanza dell'applicazione.
Di seguito una spiegazione dei campi utilizzati in questa configurazione:
| ||
3 |
Abilita la ridondanza box-to-box per l'applicazione CUBE. Configura l'RG dal passaggio precedente in
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)
Di seguito una spiegazione dei campi utilizzati in questa configurazione:
| ||
5 |
Salva la configurazione del primo CUBE e ricaricala. La piattaforma da ricaricare per ultima è sempre Standby.
Dopo aver avviato completamente VCUBE-1, salva la configurazione di VCUBE-2 e ricaricala.
| ||
6 |
Verificare 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. Successivamente, continuare con la configurazione del gateway locale (basata su registrazione o basata su certificato) su entrambi i CUBE HA. Vedi Configurazione del gateway locale su Cisco IOS XE per Webex Calling. |