En este artículo
Fundamentos
Configurar redundancia en ambos CUBES
Implemente la alta disponibilidad de CUBE como puerta de enlace local
list-menuEn este artículo
list-menu¿Comentarios?

Local Gateway (LGW) es la solución exclusiva para proporcionar acceso PSTN local a los clientes Cisco Webex Calling. Este documento le guía en la configuración de una puerta de enlace local mediante CUBE de alta disponibilidad, con CUBE activos o en espera para garantizar la conmutación por error de estado de las llamadas activas.

Fundamentos

Prerrequisitos

Antes de implementar Cisco Unified Border Element (CUBE) Alta Disponibilidad (HA) como puerta de enlace local paraWebex Calling, asegúrese de tener una comprensión profunda de los siguientes conceptos:

Las pautas de configuración proporcionadas en este artículo asumen una plataforma de puerta de enlace local dedicada sin configuración de voz existente. Si se está modificando una implementación empresarial de CUBE existente para que también utilice la función de puerta de enlace localCisco Webex Calling, preste mucha atención a la configuración aplicada para garantizar que los flujos de llamadas y las funcionalidades existentes no se interrumpan y asegúrese de cumplir con los requisitos de diseño de CUBE HA.

Componentes de hardware y software

CUBE HA como puerta de enlace local requiere IOS-XE versión 17.9.1 o posterior y una plataforma en la que se admitan las funciones CUBE HA y LGW.

Los comandos show y registros de este artículo se basan en la versión mínima de software de Cisco IOS -XE 17.9.1 implementada en un vCube (CSR 8000v).

Material de referencia

Aquí hay algunas guías detalladas de configuración de CUBE HA para varias plataformas:

Webex CallingDescripción general de la solución

Cisco Webex Callinges una oferta de colaboración que proporciona una alternativa multi-inquilino basada en la nube al servicio telefónico PBX local con múltiples opciones de PSTN para los clientes.

La implementación de la puerta de enlace local (representada a continuación) es el enfoque de este artículo. La entrada troncal de puerta de enlace local (PSTN basada en instalaciones) Webex Calling permite la conectividad a un servicio PSTN propiedad del cliente. También proporciona conectividad a una implementación de PBX IP local, como. Cisco Unified CM Toda la comunicación hacia y desde la nube está protegida mediante transporte TLS para SIP y SRTP para medios.

Local Gateway premises-based PSTN deployment

La siguiente figura muestra una Webex Calling implementación sin ninguna PBX IP existente y es aplicable a una implementación de uno o varios sitios. La configuración descrita en este artículo se basa en esta implementación.

Webex Calling deployment without IP PBX

Redundancia caja a caja de capa 2

La redundancia caja a caja de nivel 2 CUBE HA utiliza el protocolo de infraestructura del grupo de redundancia (RG) para formar un par de enrutadores activos/en espera. Este par comparte la misma dirección IP virtual (VIP) en sus respectivas interfaces e intercambia continuamente mensajes de estado. La información de la sesión CUBE se comprueba a través del par de enrutadores, lo que permite que el enrutador en espera asuma todas las responsabilidades de procesamiento de llamadas CUBE inmediatamente si el enrutador activo deja de funcionar, lo que resulta en una preservación estatal de la señalización y los medios.

El señalamiento de verificación se limita a las llamadas conectadas con paquetes de medios. Las llamadas en tránsito no son puntiagudas (por ejemplo, un estado de prueba o de llamada).

En este artículo, CUBE HA se referirá a la redundancia de caja a caja (B2B) de alta disponibilidad (HA) CUBE High Availability (HA) para la preservación de llamadas con estado.

A partir de IOS-XE 17.9.1, CUBE HA se puede implementar como puerta de enlace local para implementaciones Cisco Webex Calling troncales (PSTN basadas en instalaciones). Este artículo discutirá consideraciones de diseño y configuraciones. La figura muestra una configuración típica de CUBE HA como puerta de enlace local para una implementación Cisco Webex Calling troncal.

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

Componente de infraestructura del grupo de redundancia

El componente de infraestructura del grupo de redundancia (RG) proporciona el soporte de infraestructura de comunicación caja a caja entre los dos CUBE y negocia el estado de redundancia estable final. Este componente también proporciona:

  • Un protocolo similar a HSRP que negocia el estado de redundancia final para cada router mediante el intercambio de mensajes keepalive y hello entre los dos CUBE (a través de la interfaz de control) —GigabitEthernet3 en la figura anterior.

  • Un mecanismo de transporte para verificar la señalización y el estado de medios para cada llamada desde el router activo al router en espera (a través de la interfaz de datos): GigabitEthernet3 en la figura anterior.

  • Configuración y administración de la interfaz IP virtual (VIP) para las interfaces de tráfico (se pueden configurar múltiples interfaces de tráfico utilizando el mismo grupo RG): GigabitEthernet 1 y 2 se consideran interfaces de tráfico.

Este componente RG tiene que configurarse específicamente para soportar voz B2B HA.

Administración de direcciones IP virtuales (VIP) tanto para señalización como para medios

B2B HA depende de VIP para lograr redundancia. El VIP y las interfaces físicas asociadas en ambos CUBE del par CUBE HA deben residir en la misma subred LAN. La configuración del VIP y el enlace de la interfaz VIP a una aplicación de voz particular (SIP) son obligatorios para el soporte de voz B2B HA. Los dispositivos externosUnified CM, como SBC de Webex Calling acceso, proveedor de servicios o proxy, utilizan VIP como dirección IP de destino para las llamadas que atraviesan los routers CUBE HA. Por lo tanto, desde un Webex Calling punto de vista, los pares CUBE HA actúan como una única puerta de enlace local.

La señalización de llamada y la información de sesión RTP de las llamadas establecidas se verifican desde el router activo al router en espera. Cuando el router activo se apaga, el router en espera toma el control y continúa redireccionando el flujo RTP que anteriormente estaba enrutado por el primer router.

Las llamadas en estado transitorio en el momento de la conmutación por error no se conservarán después de la conmutación. Por ejemplo, llamadas que aún no están completamente establecidas o que están en proceso de ser modificadas con una función de transferencia o retención. Las llamadas establecidas pueden desconectarse después de la conmutación.

Existen los siguientes requisitos para usar CUBE HA como puerta de enlace local para la conmutación por error de estado de las llamadas:

  • CUBE HA no puede tener TDM o interfaces analógicas ubicadas conjuntamente

  • Gig1 y Gig2 se denominan interfaces de tráfico (SIP/RTP) y Gig3 es la interfaz de control/datos del grupo de redundancia (RG)

  • No se pueden colocar más de 2 pares CUBE HA en el mismo dominio de capa 2, uno con ID de grupo 1 y el otro con ID de grupo 2. Si configura 2 pares HA con el mismo ID de grupo, las interfaces de control/datos RG deben pertenecer a dominios de capa 2 diferentes (vlan, conmutador independiente)

  • El canal de puerto es compatible tanto para el control RG/datos como para las interfaces de tráfico

  • Todas las señalizaciones/medios se originan desde/hacia la dirección IP virtual

  • Cada vez que se recarga una plataforma en una relación CUBE-HA, siempre arranca como Standby

  • La dirección inferior para todas las interfaces (Gig1, Gig2, Gig3) debe estar en la misma plataforma

  • Identificador de interfaz de redundancia, rii debe ser exclusivo de una combinación de par/interfaz en la misma capa 2

  • La configuración en ambos CUBE debe ser idéntica, incluida la configuración física, y debe ejecutarse en el mismo tipo de plataforma y versión de IOS-XE

  • Las interfaces de loopback no se pueden usar como enlace, ya que siempre están en funcionamiento

  • Las interfaces de tráfico múltiple (SIP/RTP) (Gig1, Gig2) requieren que se configure el seguimiento de la interfaz

  • CUBE-HA no es compatible con una conexión de cable cruzado para el control RG-control/enlace de datos (Gig3)

  • Ambas plataformas deben ser idénticas y estar conectadas a través de un Switch físico a través de todas las interfaces del mismo modo para que CUBE HA funcione, es decir, GE0/0/0 de CUBE-1 y CUBE-2 debe terminar en el mismo interruptor y así sucesivamente.

  • No se puede terminar WAN en CUBE directamente o Data HA en ninguno de los lados

  • Ambos activos/en espera deben estar en el mismo centro de datos

  • Es obligatorio usar una interfaz L3 separada para la redundancia (RG control/datos, Gig3). Es decir, la interfaz utilizada para el tráfico no se puede usar para los keepalives de HA y los puntos de verificación

  • En caso de conmutación por error, el CUBE previamente activo pasa por una recarga por diseño, preservando la señalización y los medios

Configurar redundancia en ambos CUBES

Debe configurar la redundancia de caja a caja de capa 2 en ambos CUBE destinados a ser utilizados en un par HA para que se puedan crear IP virtuales.

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

1

Configure el seguimiento de la interfaz a nivel global para realizar un seguimiento del estado de la interfaz.

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 se utiliza en RG para rastrear el estado de la interfaz de tráfico de voz, de modo que la ruta activa cumpla su función activa después de que la interfaz de tráfico esté inactiva.

2

Configure un RG para su uso con VoIP HA en el submodo de redundancia de aplicaciones.

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

Aquí hay una explicación de los campos utilizados en esta configuración:

  • redundancia: ingresa al modo de redundancia

  • redundancia de aplicaciones: ingresa al modo de configuración de redundancia de aplicaciones

  • grupo: introduce el modo de configuración del grupo de aplicaciones de redundancia

  • nombre LocalGateway-HA —Define el nombre del grupo RG

  • Umbral de failover de prioridad 100 75: especifica la prioridad inicial y los umbrales de failover para un RG

  • temporizadores retardo 30 recarga 60: configura los dos tiempos para el retraso y la recarga

    • Temporizador de retardo, que es la cantidad de tiempo que se tarda en retrasar la inicialización del grupo RG y la negociación de roles después de que aparece la interfaz: 30 segundos predeterminados. El rango es de 0-10000 segundos

    • Recarga: esta es la cantidad de tiempo para retrasar la inicialización del grupo RG y la negociación de roles después de una recarga. Por defecto 60 segundos. El rango es de 0-10000 segundos

    • Se recomiendan temporizadores predeterminados, aunque estos temporizadores pueden ajustarse para adaptarse a cualquier retraso adicional de convergencia de red que pueda ocurrir durante el arranque/recarga de los routers, a fin de garantizar que la negociación del protocolo RG se lleve a cabo después de que el enrutamiento en la red haya convergido a un punto estable. Por ejemplo, si después de la conmutación por error se ve que el nuevo STANDBY tarda hasta 20 segundos en ver el primer paquete RG HELLO del nuevo ACTIVE, entonces los temporizadores deben ajustarse a 'los temporizadores retrasan 60 recargar 120' para tener en cuenta este retraso.

  • control GigabitEthernet3 protocolo 1: configura la interfaz utilizada para intercambiar mensajes keepalive y hello entre los dos CUBE, y especifica la instancia de protocolo que se conectará a una interfaz de control y entra en el modo de configuración del protocolo de aplicación de redundancia

  • datos GigabitEthernet3: configura la interfaz utilizada para la comprobación del tráfico de datos

  • pista: seguimiento de interfaces de grupo RG

  • protocolo 1: especifica la instancia de protocolo que se conectará a una interfaz de control y entra en el modo de configuración del protocolo de aplicación de redundancia

  • temporizadores hellotime 3 holdtime 10 —Configura los dos temporizadores para hellotime y tiempo de espera:

    • Hellotime— Intervalo entre sucesivos mensajes de saludo: 3 segundos predeterminados. El rango es de 250 milisegundos a 254 segundos

    • Tiempo de espera: el intervalo entre la recepción de un mensaje de saludo y la presunción de que el router de envío ha fallado. Esta duración tiene que ser mayor que el tiempo de hola. Por defecto 10 segundos. El rango es de 750 milisegundos a 255 segundos

      Le recomendamos que configure el temporizador de tiempo de espera para que sea al menos 3 veces el valor del temporizador hellotime.

3

Habilite la redundancia caja a caja para la aplicación CUBE. Configure el RG del paso anterior debajo voice service voip. Esto permite que la aplicación CUBE controle el proceso de redundancia.

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: agregar y eliminar este comando requiere una recarga para que la configuración actualizada surta efecto. Volveremos a cargar las plataformas después de que se haya aplicado toda la configuración.

4

Configure las interfaces Gig1 y Gig2 con sus respectivas IPs virtuales como se muestra a continuación y aplique el identificador de interfaz de redundancia (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

Aquí hay una explicación de los campos utilizados en esta configuración:

  • redundancia rii: configura el identificador de interfaz de redundancia para el grupo de redundancia. Requerido para generar una dirección MAC virtual (VMAC). Se debe usar el mismo valor de ID de rii en la interfaz de cada router (ACTIVO/EN ESPERA) que tenga el mismo VIP.

    Si hay más de un par B2B en la misma LAN, cada par DEBE tener ID rii únicos en sus respectivas interfaces (para evitar colisiones). El comando show redundancy application group all debe indicar la información local y de pares correcta.

  • grupo de redundancia 1: asocia la interfaz con el grupo de redundancia creado en el paso 2 anterior. Configure el grupo RG, así como el VIP asignado a esta interfaz física.

    Es obligatorio usar una interfaz separada para la redundancia, es decir, la interfaz utilizada para el tráfico de voz no se puede usar como interfaz de datos y control especificada en el Paso 2 anterior. En este ejemplo, la interfaz Gigabit 3 se utiliza para control/datos RG

5

Guarde la configuración del primer CUBE y vuelva a cargarlo.

La plataforma para recargar la última vez es siempre el modo de espera.

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

Después de que VCUBE-1 se inicie por completo, guarde la configuración de VCUBE-2 y vuelva a cargarla.

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

Verifique que la configuración de caja a caja esté funcionando como se esperaba. La salida relevante se resalta en negrita.

Recargamos VCUBE-2 al final y según las consideraciones de diseño; la plataforma para recargar la última siempre estará en espera.


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#

A continuación, continúe con la configuración de la puerta de enlace local (basada en el registro o basada en certificados) en ambos HA CUBE. Consulte Configurar puerta de enlace local en Cisco IOS XE para Webex Calling.

¿Ha encontrado este artículo útil?
¿Ha encontrado este artículo útil?