In questo articolo
Fondamenti
Configurare la ridondanza su entrambi i CUBE
Implementare l'alta disponibilità di CUBE come gateway locale
list-menuIn questo articolo
list-menuFeedback?

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:

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.

Local Gateway premises-based PSTN deployment

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.

Webex Calling deployment without IP PBX

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.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

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.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

1

Configura il tracciamento dell'interfaccia a livello globale per monitorare lo stato dell'interfaccia.

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit

VCUBE-1#conf t
VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol
VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol
VCUBE-1(config-track)#exit
VCUBE-2#conf t
VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol
VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol
VCUBE-2(config-track)#exit

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.

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy
VCUBE-1(config-red)#application redundancy
VCUBE-1(config-red-app)#group 1
VCUBE-1(config-red-app-grp)#name LocalGateway-HA
VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75
VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1
VCUBE-1(config-red-app-grp)#data GigabitEthernet3
VCUBE-1(config-red-app-grp)#timers delay 30 reload 60
VCUBE-1(config-red-app-grp)#track 1 shutdown
VCUBE-1(config-red-app-grp)#track 2 shutdown
VCUBE-1(config-red-app-grp)#exit
VCUBE-1(config-red-app)#protocol 1
VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10
VCUBE-1(config-red-app-prtcl)#exit
VCUBE-1(config-red-app)#exit
VCUBE-1(config-red)#exit
VCUBE-1(config)#

VCUBE-2(config)#redundancy
VCUBE-2(config-red)#application redundancy
VCUBE-2(config-red-app)#group 1
VCUBE-2(config-red-app-grp)#name LocalGateway-HA
VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75
VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1
VCUBE-1(config-red-app-grp)#data GigabitEthernet3
VCUBE-2(config-red-app-grp)#timers delay 30 reload 60
VCUBE-2(config-red-app-grp)#track 1 shutdown
VCUBE-2(config-red-app-grp)#track 2 shutdown
VCUBE-2(config-red-app-grp)#exit
VCUBE-2(config-red-app)#protocol 1
VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10
VCUBE-2(config-red-app-prtcl)#exit
VCUBE-2(config-red-app)#exit
VCUBE-2(config-red)#exit
VCUBE-2(config)#

Ecco una spiegazione dei campi utilizzati in questa configurazione:

  • ridondanza — Entra in modalità ridondanza

  • ridondanza delle applicazioni — Entra nella modalità di configurazione della ridondanza delle applicazioni

  • gruppo —Entra in modalità di configurazione del gruppo di applicazioni di ridondanza

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

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

  • timer delay 30 reload 60 —Configura i due orari per il ritardo e il ricaricamento

    • Timer di ritardo, che è il tempo necessario per ritardare l'inizializzazione e la negoziazione del ruolo di RG Group dopo l'avvio dell'interfaccia — Impostazione predefinita 30 secondi. L'intervallo è 0-10000 secondi

    • Ricarica: questo è il tempo necessario per ritardare l'inizializzazione del gruppo RG e la negoziazione dei ruoli dopo un ricaricamento — Impostazione predefinita 60 secondi. L'intervallo è 0-10000 secondi

    • Si consigliano timer predefiniti, sebbene questi timer possano essere regolati per far fronte a qualsiasi ulteriore ritardo di convergenza della rete che potrebbe verificarsi durante l'avvio/ricaricamento dei router, al fine di garantire che la negoziazione del protocollo RG avvenga dopo che il routing nella rete è convergente a un punto stabile. Ad esempio, se dopo il failover si vede che il nuovo STANDBY impiega fino a 20 secondi per vedere il primo pacchetto RG HELLO del nuovo ACTIVE, allora i timer devono essere regolati su «timers delay 60 reload 120" per tenere conto di questo ritardo.

  • control GigabitEthernet3 protocol 1 — Configura l'interfaccia utilizzata per lo scambio di messaggi keepalive e hello tra i due CUBE e specifica l'istanza del protocollo che verrà collegata a un'interfaccia di controllo ed entra in modalità di configurazione del protocollo applicativo di ridondanza

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

  • track —Tracciamento delle interfacce del gruppo RG

  • protocollo 1 — Specifica l'istanza del protocollo che verrà collegata a un'interfaccia di controllo ed entra in modalità di configurazione del protocollo applicativo di ridondanza

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

    • Hellotime— Intervallo tra messaggi di saluto successivi — Impostazione predefinita: 3 secondi. L'intervallo è 250 millisecondi-254 secondi

    • Tempo di attesa: l'intervallo tra la ricezione di un messaggio Hello e la presunzione che il router di invio non sia riuscito. Questa durata deve essere superiore al tempo di Hello-Time — Impostazione predefinita 10 secondi. L'intervallo è 750 millisecondi-255 secondi

      Le consigliamo di configurare il timer di attesa in modo che sia almeno 3 volte il valore di hellotime timer.

3

Abilita la ridondanza box-to-box per l'applicazione CUBE. Configura l'RG dal passaggio precedente in voice service voipbasso. Ciò consente all'applicazione CUBE di controllare il processo di ridondanza.

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip
VCUBE-1(config-voi-serv)#redundancy-group 1
% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
VCUBE-1(config-voi-serv)# exit
VCUBE-2(config)#voice service voip
VCUBE-2(config-voi-serv)#redundancy-group 1
% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
VCUBE-2(config-voi-serv)# exit

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)

VCUBE-1(config)#interface GigabitEthernet1
VCUBE-1(config-if)# redundancy rii 1
VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive
VCUBE-1(config-if)# exit
VCUBE-1(config)#
VCUBE-1(config)#interface GigabitEthernet2
VCUBE-1(config-if)# redundancy rii 2
VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive
VCUBE-1(config-if)# exit
VCUBE-2(config)#interface GigabitEthernet1
VCUBE-2(config-if)# redundancy rii 1
VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive
VCUBE-2(config-if)# exit
VCUBE-2(config)#
VCUBE-2(config)#interface GigabitEthernet2
VCUBE-2(config-if)# redundancy rii 2
VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive
VCUBE-v(config-if)# exit

Ecco una spiegazione dei campi utilizzati in questa configurazione:

  • redundancy rii —Configura l'identificatore dell'interfaccia di ridondanza per il gruppo di ridondanza. Necessario per generare un indirizzo MAC virtuale (VMAC). Lo stesso valore ID rii deve essere utilizzato sull'interfaccia di ogni router (ACTIVE/STANDBY) con lo stesso VIP.

    Se c'è più di una coppia B2B sulla stessa LAN, ogni coppia DEVE avere ID rii univoci sulle rispettive interfacce (per evitare collisioni). Il comando show redundancy application group all dovrebbe indicare le informazioni locali e peer corrette.

  • gruppo di ridondanza 1: associa l'interfaccia al gruppo di ridondanza creato nel passaggio 2 precedente. Configura il gruppo RG e 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 nella Fase 2 precedente. In questo esempio, l'interfaccia Gigabit 3 viene utilizzata per il controllo/i dati RG

5

Salva la configurazione del primo CUBO e ricaricala.

La piattaforma da ricaricare per ultima è sempre la Standby.

VCUBE-1#wr
Building configuration...
[OK]
VCUBE-1#reload
Proceed with reload? [confirm]

Dopo l'avvio completo di VCUBE-1, salvi la configurazione di VCUBE-2 e ricarichi.

VCUBE-2#wr
Building configuration...
[OK]
VCUBE-2#reload
Proceed with reload? [confirm]
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.


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

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.

Questo articolo è stato utile?
Questo articolo è stato utile?