Fundamentos

Requisitos previos

Antes de implementar la alta disponibilidad (HA) de Cisco Unified Border Element (CUBE) como puerta de enlace local para Webex Calling, asegúrese de comprender en profundidad los siguientes conceptos:

Las pautas de configuración proporcionadas en este artículo suponen una plataforma de puerta de enlace local exclusiva sin configuración de voz existente. Si se está modificando una implementación empresarial de CUBE existente para utilizar también la función de puerta de enlace local para Cisco 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 de CUBE HA y LGW.

Los comandos show y los 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 (CSR187 v).

Material de referencia

A continuación, se detallan algunas guías de configuración de CUBE HA para diversas plataformas:

Descripción general de la solución de Webex Calling

Cisco Webex Calling es una oferta de colaboración que proporciona una alternativa basada en la nube de varios inquilinos al servicio telefónico PBX en las instalaciones con varias opciones de PSTN para los clientes.

La implementación de la puerta de enlace local (representada a continuación) es el punto central de este artículo. El enlace troncal de la puerta de enlace local (PSTN local) en Webex Calling permite la conectividad a un servicio de PSTN propiedad del cliente. También proporciona conectividad a una implementación de IP PBX local, como Cisco Unified CM. Todas las comunicaciones hacia y desde la nube se protegen mediante el transporte TLS para SIP y SRTP para medios.

Implementación de PSTN local de la puerta de enlace local

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

Implementación de Webex Calling sin IP PBX

Redundancia entre decodificadores de nivel 2

La redundancia entre decodificadores de nivel 2 de 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 intercambian continuamente mensajes de estado. La información de la sesión de CUBE se comprueba en todo el par de enrutadores, lo que permite que el enrutador de espera asuma todas las responsabilidades de procesamiento de llamadas de CUBE inmediatamente si el enrutador activo sale de servicio, lo que resulta en la preservación con inspección de estado de la señalización y los medios.

El punto de verificación se limita a llamadas conectadas con paquetes de medios. Las llamadas en tránsito no se verifican en punto (por ejemplo, un estado de intento o de timbre).

En este artículo, CUBE HA hará referencia a la redundancia entre decodificadores (B2B) de nivel 2 de alta disponibilidad (HA) para la preservación de llamadas con inspección de estado.

A partir de IOS-XE 17.9.1, CUBE HA puede implementarse como puerta de enlace local para implementaciones del enlace troncal de Cisco Webex Calling (PSTN local). En este artículo se analizarán las consideraciones y configuraciones de diseño. En la figura se muestra una configuración típica de CUBE HA como puerta de enlace local para una implementación de enlace troncal de Cisco Webex Calling.

Una configuración típica de CUBE HA como puerta de enlace local para una implementación de enlace troncal de Cisco Webex Calling

Componente Infra del grupo de redundancia

El componente Infra del grupo de redundancia (RG) proporciona soporte para la infraestructura de comunicación entre decodificadores 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 enrutador intercambiando mensajes de actividad y bienvenida entre los dos CUBE (a través de la interfaz de control): GigabitEthernet3 en la figura anterior.

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

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

Este componente de RG debe configurarse específicamente para admitir B2B HA de voz.

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

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

La señalización de llamadas y la información de sesión RTP de las llamadas establecidas son de punto de control desde el enrutador activo al enrutador de espera. Cuando el enrutador activo se cae, el enrutador de modo de espera toma el control y continúa reenviando el flujo RTP previamente enrutado por el primer enrutador.

Las llamadas en un estado transitorio en el momento de la recuperación de fallas no se conservarán después de la conmutación. Por ejemplo, llamadas que aún no están completamente establecidas o están en proceso de modificación con una función de transferencia o espera. Las llamadas establecidas pueden desconectarse después de la conmutación.

Existen los siguientes requisitos para utilizar CUBE HA como puerta de enlace local para la recuperación de fallas con inspección de estado de las llamadas:

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

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

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

  • El canal de puertos es compatible con las interfaces de control/datos y tráfico de RG

  • Toda la señalización/los 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 en espera

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

  • El identificador de interfaz de redundancia, rii debe ser único para una combinación de par/interfaz en el mismo nivel 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 bucle no se pueden utilizar como enlace, ya que siempre están activas

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

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

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

  • No se puede terminar la WAN en los CUBE directamente ni la alta disponibilidad de datos en ninguno de los lados

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

  • Es obligatorio utilizar una interfaz L3 independiente para la redundancia (Control/datos de RG, Gig3). es decir, la interfaz utilizada para el tráfico no se puede utilizar para los keepalives y los puntos de control de alta disponibilidad

  • Tras la recuperación de fallas, el CUBE anteriormente activo pasa por una recarga por diseño, preservando la señalización y los medios

Configurar la redundancia en ambos CUBE

Debe configurar la redundancia entre decodificadores de nivel 2 en ambos CUBE que se utilizarán en un par de HA para poner en marcha las IP virtuales.

Una configuración típica de CUBE HA como puerta de enlace local para una implementación de enlace troncal de Cisco Webex Calling

1

Configure el seguimiento de la interfaz a nivel global para rastrear el 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

La CLI de seguimiento se utiliza en RG para realizar un seguimiento del estado de la interfaz de tráfico de voz, de modo que la ruta activa quite su rol activo una vez que la interfaz de tráfico esté fuera de servicio.

2

Configure un RG para usarlo 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)#

A continuación, se ofrece una explicación de los campos utilizados en esta configuración:

  • redundancia: introduce el modo de redundancia

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

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

  • name LocalGateway-HA: define el nombre del grupo de RG.

  • prioridad 100 umbral de recuperación de fallas 75: especifica los umbrales iniciales de prioridad y recuperación de fallas para un RG

  • demora de temporizadores 30 recarga 60: configura los dos tiempos para la demora y la recarga

    • Temporizador de demora, que es la cantidad de tiempo para demorar la inicialización y la negociación de funciones del grupo de RG después de que aparece la interfaz: valor predeterminado de 30 segundos. El intervalo es de 0 a 10000 segundos

    • Recarga: esta es la cantidad de tiempo para demorar la inicialización y la negociación de roles del grupo de RG después de una recarga: valor predeterminado de 60 segundos. El intervalo es de 0 a 10000 segundos

    • Se recomiendan temporizadores predeterminados, aunque estos temporizadores se pueden ajustar para adaptarse a cualquier retraso adicional de convergencia de red que pueda ocurrir durante el arranque/la recarga de los enrutadores, 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 se observa después de la recuperación de fallas que el nuevo STANDBY tarda hasta 20 segundos en ver el primer paquete RG HELLO del nuevo ACTIVE, los temporizadores deben ajustarse a “demora de temporizadores 60 recarga 120” para tener en cuenta esta demora.

  • control GigabitEthernet3 protocolo 1: configura la interfaz que se utiliza para intercambiar mensajes de actividad y bienvenida entre los dos CUBE y especifica la instancia del protocolo que se adjuntará a una interfaz de control e introduce el modo de configuración del protocolo de redundancia de la aplicación

  • GigabitEthernet3 de datos: configura la interfaz que se utiliza para el punto de control del tráfico de datos

  • seguimiento: seguimiento de interfaces del grupo de RG

  • protocolo 1: especifica la instancia del protocolo que se adjuntará a una interfaz de control e introduce el modo de configuración del protocolo de la aplicación de redundancia

  • bienvenida de temporizadores 3 espera 10: configura los dos temporizadores para la bienvenida y la espera:

    • Bienvenida: intervalo entre mensajes de bienvenida sucesivos: valor predeterminado de 3 segundos. El intervalo es de 250 milisegundos a 254 segundos

    • Holdtime (Tiempo de espera): el intervalo entre la recepción de un mensaje de bienvenida y la presunción de que el enrutador de envío ha fallado. Esta duración debe ser mayor que la hora de bienvenida (valor predeterminado de 10 segundos). El intervalo es de 750 milisegundos a 255 segundos

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

3

Habilite la redundancia entre decodificadores para la aplicación CUBE. Configure el RG en el paso anterior en 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

redundancia-grupo 1: para agregar y eliminar este comando, se requiere una recarga para que la configuración actualizada surta efecto. Volveremos a cargar las plataformas una vez que se haya aplicado toda la configuración.

4

Configure las interfaces Gig1 y Gig2 con sus respectivas IP 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

A continuación, se ofrece 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. Necesario para generar una dirección de MAC virtual (VMAC). Se debe utilizar el mismo valor de ID de rii en la interfaz de cada router (ACTIVE/STANDBY) que tenga la misma VIP.

    Si hay más de un par B2B en la misma LAN, cada par DEBE tener ID de 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 de RG, así como la VIP asignada a esta interfaz física.

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

5

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

La última plataforma en volver a cargarse es siempre la de espera.

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

Después de que VCUBE-1 se inicie completamente, 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 entre decodificadores esté funcionando como se esperaba. La salida relevante se resalta en negrita.

Hemos recargado el último VCUBE-2 y, según las consideraciones de diseño, la última plataforma que se volverá a cargar siempre será la de 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 registro o basada en certificado) en ambos CUBE de alta disponibilidad. Consulte Configurar la puerta de enlace local en Cisco IOS XE para Webex Calling.