- Home
- /
- Articolo
Local Gateway (LGW) è la soluzione esclusiva per fornire l'accesso PSTN locale ai clienti Cisco Webex Calling. Questo documento La guida nella configurazione di un gateway locale utilizzando CUBE ad alta disponibilità, con CUBE attivi o in standby per garantire il failover con stato delle chiamate attive.
Fondamenti
Prerequisiti
Prima di implementare Cisco Unified Border Element (CUBE) High Availability (HA) come gateway locale perWebex Calling, si assicuri di avere una comprensione approfondita dei seguenti concetti:
-
Ridondanza box-to-box di livello 2 con CUBE Enterprise per la conservazione stateful delle chiamate
Le linee guida di configurazione fornite in questo articolo presuppongono una piattaforma gateway locale dedicata senza configurazione vocale esistente. Se una distribuzione aziendale di CUBE esistente viene modificata per utilizzare anche la funzione gateway locale perCisco Webex Calling, presta molta attenzione alla configurazione applicata per garantire che i flussi di chiamate e le funzionalità esistenti non vengano interrotti e assicurarsi di rispettare i requisiti di progettazione di 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 siano supportate sia le funzioni CUBE HA che LGW.
I comandi show e i log in questo articolo si basano sulla versione minima del software di Cisco IOS -XE 17.9.1 implementata su un vCube (CSR 8000v).
Materiale di riferimento
Ecco alcune guide dettagliate alla configurazione di CUBE HA per varie piattaforme:
Webex CallingPanoramica della soluzione
Cisco Webex Callingè un'offerta di collaborazione che fornisce un'alternativa multi-tenant basata su cloud al servizio telefonico PBX locale con diverse opzioni PSTN per i clienti.
L'implementazione del Local Gateway (rappresentata di seguito) è al centro di questo articolo. Il trunk in del gateway locale (PSTN basato in sede) Webex Calling consente la connettività a un servizio PSTN di proprietà del cliente. Fornisce inoltre connettività a una distribuzione IP PBX locale come. Cisco Unified CM Tutte le comunicazioni da e verso il cloud sono protette utilizzando il trasporto TLS per SIP e SRTP per i media.
La figura seguente mostra una Webex Calling distribuzione 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-to-box di livello 2
La ridondanza box-to-box di livello 2 CUBE HA utilizza il protocollo di infrastruttura Redundancy Group (RG) per formare una coppia di router attivi/standby. Questa coppia condivide lo stesso indirizzo IP virtuale (VIP) tra le rispettive interfacce e si scambia continuamente messaggi di stato. Le informazioni sulla sessione CUBE vengono controllate sulla coppia di router, consentendo al router di standby di assumersi immediatamente tutte le responsabilità di elaborazione delle chiamate CUBE se il router attivo va fuori servizio, con conseguente conservazione permanente della segnalazione e dei contenuti multimediali.
Il check pointing è limitato alle chiamate connesse con pacchetti multimediali. Le chiamate in transito non sono contrassegnate (ad esempio, uno stato di tentativo o squillo).
In questo articolo, CUBE HA farà riferimento alla ridondanza box-to-box (B2B) di CUBE High Availability (HA) 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 Cisco Webex Calling le distribuzioni dei trunk (PSTN basato in sede). Questo articolo tratterà le considerazioni e le configurazioni di progettazione. La figura mostra una tipica configurazione CUBE HA come gateway locale per l'implementazione di un Cisco Webex Calling trunk.
Gruppo di ridondanza Infra Component
Il componente Redundancy Group (RG) Infra 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 ogni router scambiando messaggi keepalive e hello tra i due CUBE (tramite l'interfaccia di controllo): GigabitEthernet3 nella figura sopra.
-
Un meccanismo di trasporto per verificare lo stato della segnalazione e del supporto per ogni chiamata dal router attivo a quello di standby (tramite l'interfaccia dati): GigabitEthernet3 nella figura sopra.
-
Configurazione e gestione dell'interfaccia Virtual IP (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 voce B2B HA.
Gestione degli indirizzi IP virtuali (VIP) sia per la segnalazione che per i media
B2B HA si affida a VIP per ottenere la ridondanza. Il VIP e le interfacce fisiche associate su entrambi i CUBE della coppia CUBE HA devono risiedere sulla stessa sottorete LAN. La configurazione del VIP e l'associazione dell'interfaccia VIP a una particolare applicazione vocale (SIP) sono obbligatorie per il supporto vocale B2B HA. I dispositivi esterni come Unified CM Webex Calling l'accesso a SBC, il fornitore di servizi o il proxy utilizzano VIP come indirizzo IP di destinazione per le chiamate che attraversano i router CUBE HA. Quindi, da un Webex Calling punto di vista, le coppie CUBE HA agiscono come un unico gateway locale.
La segnalazione delle chiamate e le informazioni sulla sessione RTP delle chiamate stabilite vengono controllate dal router attivo al router di standby. Quando il router attivo non funziona, il router Standby prende il sopravvento e continua a inoltrare il flusso RTP precedentemente indirizzato dal primo router.
Le chiamate in stato transitorio al momento del failover non verranno conservate dopo il passaggio al digitale. Ad esempio, chiamate che non sono ancora completamente stabilite o che stanno per essere modificate con una funzione di trasferimento o attesa. Le chiamate stabilite possono essere disconnesse dopo il passaggio al digitale.
Esistono i seguenti requisiti per l'utilizzo di CUBE HA come gateway locale per il failover stateful delle chiamate:
-
CUBE HA non può avere interfacce TDM o analogiche co-localizzate
-
Gig1 e Gig2 sono denominate interfacce di traffico (SIP/RTP) e Gig3 è interfaccia di controllo/dati di Redundancy Group (RG)
-
Non è possibile inserire più di 2 coppie CUBE HA nello stesso dominio di livello 2, una con ID gruppo 1 e l'altra con ID gruppo 2. Se si configurano 2 coppie HA con lo stesso ID di gruppo, le interfacce RG Control/Data devono appartenere a domini di livello 2 diversi (vlan, switch separato)
-
Il canale di porta è supportato sia per le interfacce RG Control/dati che per il traffico
-
Tutti i segnali e i contenuti multimediali provengono da/verso l'indirizzo IP virtuale
-
Ogni volta che una piattaforma viene ricaricata in una relazione CUBE-HA, si avvia sempre in standby
-
L'indirizzo inferiore per tutte le interfacce (Gig1, Gig2, Gig3) dovrebbe trovarsi sulla stessa piattaforma
-
Ridundancy Interface Identifier, rii dovrebbe essere univoco per una combinazione coppia/interfaccia sullo stesso Layer 2
-
La configurazione su entrambi i CUBE deve essere identica, inclusa la configurazione fisica, e deve essere eseguita sullo stesso tipo di piattaforma e versione IOS-XE
-
Le interfacce di loopback non possono essere utilizzate come bind in quanto sono sempre attive
-
Le interfacce di traffico multiple (SIP/RTP) (Gig1, Gig2) richiedono la configurazione del tracciamento dell'interfaccia
-
CUBE-HA non è supportato tramite una connessione via cavo crossover per il collegamento RG-Control/Data (Gig3)
-
Entrambe le piattaforme devono essere identiche ed essere connesse tramite uno switch fisico su tutte le interfacce simili affinché CUBE HA funzioni, ad es. GE0/0/0 di CUBE-1 e CUBE-2 devono terminare sullo stesso interruttore e così via.
-
Non è possibile terminare direttamente la WAN sui CUBE o Data HA su entrambi i lati
-
Entrambi Active/Standby devono trovarsi nello stesso data center
-
È obbligatorio utilizzare un'interfaccia L3 separata per la ridondanza (RG Control/data, Gig3). Cioè l'interfaccia utilizzata per il traffico non può essere utilizzata per i keepalive e il checkpoint HA
-
In caso di failover, il CUBE precedentemente attivo viene ricaricato in base alla progettazione, preservando segnali e supporti
Configurare la ridondanza su entrambi i CUBE
Deve configurare la ridondanza box-to-box di livello 2 su entrambi i CUBE destinati a essere utilizzati in una coppia HA per visualizzare gli IP virtuali.
| 1 |
Configura il tracciamento dell'interfaccia a livello globale per monitorare lo stato dell'interfaccia.
Track CLI viene utilizzato in RG per tracciare lo stato dell'interfaccia del traffico vocale in modo che il percorso attivo svolga il suo ruolo attivo dopo l'interruzione dell'interfaccia di traffico. | ||
| 2 |
Configura un RG da utilizzare con VoIP HA nella sottomodalità di ridondanza dell'applicazione.
Ecco 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 affinché la configurazione aggiornata abbia effetto. Ricaricheremo le piattaforme dopo aver applicato tutta la configurazione. | ||
| 4 |
Configura le interfacce Gig1 e Gig2 con i rispettivi IP virtuali come mostrato di seguito e applica l'identificatore di interfaccia di ridondanza (rii)
Ecco una spiegazione dei campi utilizzati in questa configurazione:
| ||
| 5 |
Salva la configurazione del primo CUBO e ricaricala. La piattaforma da ricaricare per ultima è sempre la Standby.
Dopo l'avvio completo di VCUBE-1, salvi la configurazione di VCUBE-2 e ricarichi.
| ||
| 6 |
Verifichi che la configurazione box-to-box funzioni come previsto. L'output pertinente è evidenziato in grassetto. Abbiamo ricaricato VCUBE-2 per ultimo e secondo le considerazioni di progettazione; la piattaforma da ricaricare per ultima sarà sempre Standby.
Quindi, proceda con la configurazione del gateway locale (basata sulla registrazione o basata su certificati) su entrambi i CUBE HA. Vedere Configurare il gateway locale su Cisco IOS XE per Webex Calling. |