Fundamentos

Requisitos previos

Antes de implementar CUBE HA 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 atención a la configuración aplicada para asegurarse de que los flujos de llamadas y las funcionalidades existentes no se interrumpan y asegúrese de que esté cumpliendo 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 16.12.2 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 una versión mínima de software de Cisco IOS-XE 16.12.2 implementada en un vCUBE (CSR1000v).

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 Webex Calling

Cisco Webex Calling es una oferta de colaboración que ofrece una alternativa basada en la nube de varios inquilinos al servicio telefónico PBX local 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 para 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.

La figura a continuación 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.

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 y continuamente intercambian mensajes de estado. Se comprueba la información de la sesión de CUBE en todo el par de enrutadores, lo que permite que el enrutador en modo de espera asuma todas las responsabilidades del procesamiento de llamadas de CUBE de inmediato si el enrutador activo queda fuera de servicio, lo que genera la preservación de 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 por 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 CUBE de alta disponibilidad (HA) para la preservación de llamadas con inspección de estado.

A partir de IOS-XE 16.12.2, CUBE HA se puede implementar como puerta de enlace local para implementaciones del enlace troncal de Cisco Webex Calling (PSTN local), y cubriremos las consideraciones y configuraciones de diseño en este artículo. En esta figura se muestra una configuración típica de CUBE HA como puerta de enlace local para una implementación del 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 monitoreo 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 la señalización y los medios para cada llamada desde el enrutador activo al de modo 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 (varias interfaces de tráfico se pueden configurar 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 la dirección IP virtual (VIP) para señalización y medios

B2B HA depende de la 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 para una aplicación de voz (SIP) en particular son obligatorias 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, usan la VIP como 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 información de la sesión de RTP y de señalización de llamadas de las llamadas establecidas se encuentran en punto de control desde el enrutador activo hasta el enrutador de espera. Cuando el enrutador activo se cae, el enrutador de modo de espera toma el control y sigue reenviando el flujo de RTP anteriormente 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, las llamadas que todavía no están totalmente 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 al mismo tiempo

  • A Gig1 y Gig2 se les conoce como 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

  • Todas la señalización/los medios se traslada desde/hacia la dirección IP virtual

  • Cada vez que se recarga una plataforma en una relación CUBE-HA, siempre arranca en modo de 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 amos 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 la interfaz

  • 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 deben 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.

  • WAN no puede terminar en los CUBE directamente ni en la alta disponibilidad de datos en cualquiera de los lados

  • Tanto el enrutador activo como el de 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 que se utiliza para el tráfico no se puede utilizar para mantener el monitoreo de actividad y los puntos de control de HA

  • Después de 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 recupera las IP virtuales.

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)#interfaz de seguimiento 1 GigabitEthernet1 línea-protocolo

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#salir

VCUBE-2#conf t

VCUBE-2(config)#interfaz de pista 1 GigabitEthernet1 línea-protocolo

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#salir

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 abandone su rol activo una vez que de desactive la interfaz de tráfico.

2

Configure un RG para utilizar con VoIP HA bajo el modo secundario de redundancia de la aplicación.

redundancia aplicación grupo 1 nombre LocalGateway-HA prioridad 100 umbral de recuperación de 
 
 
 
    fallas 75 
    control Protocolo GigabitEthernet3 protocolo 1 datos 
    GigabitEthernet3 temporizadores demoran 30 recarga 60 seguimiento 1 seguimiento de apagado 2 protocolo de cierre 1 temporizadores 
 
 
 
 
 
    holatime 3 holdtime 10 
 
 
 salida salida 

VCUBE-1(config)#redundancia

VCUBE-1(config-red)#redundancia de aplicaciones

VCUBE-1(config-red-app)#grupo 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#prioridad 100 umbral de conmutación por error 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocolo 1

VCUBE-1(config-red-app-grp)#datos GigabitEthernet3

VCUBE-1(config-red-app-grp)#demora de temporizadores 30 recarga 60

Apagado de VCUBE-1(config-red-app-grp)#pista 1

Cierre de VCUBE-1(config-red-app-grp)#pista 2

VCUBE-1(config-red-app-grp)#salir

VCUBE-1(config-red-app)#protocolo 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#salir

VCUBE-1(config-red-app)#salir

VCUBE-1(config-red)#salir

VCUBE-1(configuración) #

VCUBE-2(config)#redundancia

VCUBE-2(config-red)#redundancia de aplicaciones

VCUBE-2(config-red-app)#grupo 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#prioridad 100 umbral de conmutación por error 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocolo 1

VCUBE-1(config-red-app-grp)#datos GigabitEthernet3

VCUBE-2(config-red-app-grp)#demora de temporizadores 30 recarga 60

Cierre de VCUBE-2(config-red-app-grp)#pista 1

Cierre de VCUBE-2(config-red-app-grp)#pista 2

VCUBE-2(config-red-app-grp)#salir

VCUBE-2(config-red-app)#protocolo 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#salir

VCUBE-2(config-red-app)#salir

VCUBE-2(config-red)#salir

VCUBE-2(configuración) #

Aquí 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 rango es de 0 a 10 0000 segundos

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

    • Se recomiendan los temporizadores predeterminados, aunque estos temporizadores se pueden ajustar para adaptarse a cualquier demora de convergencia de red adicional que pueda ocurrir durante el arranque/la recarga de los enrutadores, a fin de garantizar que se lleve a cabo la negociación del protocolo de RG 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 demora hasta 20 segundos para que el nuevo STANDBY vea el primer paquete RG HELLO del nuevo ACTIVE, los temporizadores se deben ajustar a "demora de temporizadores 60 recarga 120" para ajustarse a 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 rango es de 250 milisegundos a 254 segundos

    • Espera: el intervalo entre la recepción de un mensaje de bienvenida y la confirmación de que el enrutador que envía ha fallado. Esta duración debe ser superior al tiempo de bienvenida (valor predeterminado de 10 segundos). El rango 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 del paso anterior en voz sobre IP del servicio de voz. Esto permite que la aplicación CUBE controle el proceso de redundancia.

salida del grupo 1 de redundancia de voz sobre 
   IP por servicio de 
   voz

VCUBE-1(config)#voip del servicio de voz

VCUBE-1(config-voi-serv)#redundancia-grupo 1

 % creó la asociación RG 1 con Voice B2B HA; volver a cargar el enrutador para que la nueva configuración entre en vigencia 

VCUBE-1(config-voi-serv)# salida

VCUBE-2(config)#voip del servicio de voz

VCUBE-2(config-voi-serv)#redundancia-grupo 1

 % creó la asociación RG 1 con Voice B2B HA; volver a cargar el enrutador para que la nueva configuración entre en vigencia 

VCUBE-2(config-voi-serv)# salida

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

VCUBE-1(config-if)# redundancia rii 1

VCUBE-1(config-if)# IP exclusiva del grupo de redundancia 1 198.18.1.228

VCUBE-1(config-if)# salida

VCUBE-1(configuración) #

VCUBE-1(config)#interfaz GigabitEthernet2

VCUBE-1(config-if)# redundancia rii 2

VCUBE-1(config-if)# IP exclusiva del grupo de redundancia 1 198.18.133.228

VCUBE-1(config-if)# salida

VCUBE-2(config)#interfaz GigabitEthernet1

VCUBE-2(config-if)# redundancia rii 1

VCUBE-2(config-if)# IP exclusiva del grupo de redundancia 1 198.18.1.228

VCUBE-2(config-if)# salida

VCUBE-2(configuración) #

VCUBE-2(config)#interfaz GigabitEthernet2

VCUBE-2(config-if)# redundancia rii 2

VCUBE-2(config-if)# IP exclusiva del grupo de redundancia 1 198.18.133.228

VCUBE-v(config-if)# salida

Aquí 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). Debe usarse el mismo valor de ID de rii en la interfaz de cada enrutador (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 la colisión). ‘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 separada 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 control/datos de RG

5

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

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

VCUBE-1#wr

 Configuración del edificio... 

 [Aceptar] 

VCUBE-1#recarga

 ¿Desea continuar con la recarga? [confirmar]

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

VCUBE-2#wr

 Configuración del edificio... 

 [Aceptar] 

VCUBE-2#recarga

 ¿Desea continuar con la recarga? [confirmar]

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, de acuerdo con las consideraciones de diseño, la última plataforma que se volverá a cargar en siempre será la de espera. 

 VCUBE-1#mostrar el grupo de aplicaciones de redundancia todos los estados de fallas información del grupo 1:        Prioridad de tiempo de ejecución: [100] RG faults estado de RG: hacia arriba.                        Cantidad total de conmutación debido a fallas:  0 total de cambios de estado abajo/arriba debido a fallas: 0 ID de Grupo: 1 grupo de nombre: LocalGateway-estado administrativo de alta disponibilidad : Estado operativo agregado sin cierre:  Mi función: Función del pares activo: Presencia en el par de espera : Sí, comunicaciones pares: Sí se inició la progresión del pares: Sí, dominio RF: BtoB-un estado RF: Estado de RF del pares activo: Rol de protocolo de RG en espera de RG 1------------------: Negociación activa: Prioridad habilitada: Estado del protocolo 100: Estado activo de Intf Ctrl (s): Configurar pares activos: Par local de espera: Dirección 10.1.1.2, prioridad 100, Intf Gi3 contadores de registro:                 cambio de función a activo: 1 cambio de función a en espera: 1 sucesos deshabilitados: RG desactivado estado 0, RG desconectar 0 Ctrl Intf eventos: 1 arriba, 0 abajo, admin_down 0 eventos de recarga: solicitud local 0, solicitud de pares 0 contexto de medios RG para RG 1--------------------------Estado de CTX: ID de protocolo activo: 1 tipo de medio: Interfaz de control predeterminada:  Temporizador de Hello actual GigabitEthernet3: 3000 ha configurado el temporizador de Hello: 3000, Temporizador de espera: 10000, temporizador de Hola de par: 3000, temporizador de espera de pares: 10000 estadísticas:             Paquetes 1509, bytes 93558, alta disponibilidad 0, SEQ número 1509, PKT Loss 0 autenticación no configurada error de autenticación: 0 volver a cargar pares: TX 0, RX 0 refirma: TRANSMISIÓN 0, RX 0 par de inactividad: Presente. Temporizador de espera: 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:        Prioridad de tiempo de ejecución: [100] RG faults estado de RG: hacia arriba.                        Cantidad total de conmutación debido a fallas:  0 total de cambios de estado abajo/arriba debido a fallas: 0 ID de Grupo: 1 grupo de nombre: LocalGateway-estado administrativo de alta disponibilidad : Estado operativo agregado sin cierre: Mi función: Función de pares de puestos en espera:  Presencia de pares activos: Sí, comunicaciones pares: Sí se inició la progresión del pares: Sí, dominio RF: BtoB-un estado RF: Estado de RF del pares activo: Rol de protocolo de RG en espera de RG 1------------------: Negociación activa: Prioridad habilitada: Estado del protocolo 100: Estado activo de Intf Ctrl (s): Configurar pares activos: Dirección 10.1.1.2, prioridad 100, Intf Gi3 par de espera: Contadores de registro local:                 cambio de función a activo: 1 cambio de función a en espera: 1 sucesos deshabilitados: RG desactivado estado 0, RG desconectar 0 Ctrl Intf eventos: 1 arriba, 0 abajo, admin_down 0 eventos de recarga: solicitud local 0, solicitud de pares 0 contexto de medios RG para RG 1--------------------------Estado de CTX: ID de protocolo activo: 1 tipo de medio: Interfaz de control predeterminada:  Temporizador de Hello actual GigabitEthernet3: 3000 ha configurado el temporizador de Hello: 3000, Temporizador de espera: 10000, temporizador de Hola de par: 3000, temporizador de espera de pares: 10000 estadísticas:             Paquetes 1509, bytes 93558, alta disponibilidad 0, SEQ número 1509, PKT Loss 0 autenticación no configurada error de autenticación: 0 volver a cargar pares: TX 0, RX 0 refirma: TRANSMISIÓN 0, RX 0 par de inactividad: Presente. Temporizador de espera: 10000 
 pkts 61, bytes 2074, ha seq 0, número de seq 69, Pkt Loss 0 
 
 VCUBE-2 #

Configurar una puerta de enlace local en ambos CUBE

En nuestra configuración de ejemplo, estamos utilizando la siguiente información de enlace troncal de Control Hub para crear la configuración de la puerta de enlace local tanto en las plataformas, VCUBE-1 como VCUBE-2. El nombre de usuario y la contraseña para esta configuración son los siguientes:

  • Usuario: Hussain1076LGU_

  • Contraseña: lOV12MEaZx

1

Asegúrese de que se haya creado una clave de configuración para la contraseña con los comandos show que se muestran a continuación, antes de poder utilizarse en las credenciales o en los secretos compartidos. Las contraseñas del tipo 6 se cifran mediante cifrado AES y esta clave de configuración definida por el usuario. 

 LocalGateway#conf t LocalGateway(config)#key config-key password-encrypt Password123 LocalGateway(config)#password encryption aes

A continuación, se muestra la configuración de la puerta de enlace local que se aplicará a ambas plataformas según los parámetros del concentrador de control mostrado anteriormente, guardar y volver a cargar. Las credenciales del Resumen de SIP de Control Hub se resaltan en negrita.

 configure terminal crypto pki trustpoint dummyTp revocation-check crl salida sip-ua crypto signaling default trustpoint dummyTp cn-san-validate server transport tcp tls v1.2 end configure terminal crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b end configure terminal voice service voip ip address trusted list ipv4 x.x.x.x y.y.y.y exit allow-connections sip to sip media statistics media bulk-stats no supplementary-service sip refer no supplementary-service sip handle-replaces fax protocol pass-through g ulaw stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123! sip g729 annexb-all early-offer forced end configure terminal voice class sip-profiles 200 rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1" rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 12 request ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 12 request ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 15 response ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 20 request ANY sip-hussain1076_lgu>" regla 30 request ANY SIP-HEADER P-asserted-identity modify "sips:(.*)" "sip:\1" códec de clase de voz 99 preferencia de códec 1 g ulaw preferencia de códec 2 g ulaw salida clase de voz srtp-crypto 200 crypto 1 AES_cm_128_hmac_sha1_80 salir de la clase de voz stun-usage 200 stun usage firewall-traversal flowdata salir del inquilino 200 registrador de la clase de voz dns:40462196.cisco-bcld.com sips de esquema caduca el número de credenciales TCP TLS de relación de actualización 50 de 240 Hussain5091_lgu nombre de usuario Hussain1076_Contraseña de LGU 0 lOV12MEaZx nombre de usuario de autenticación de Broadworks del dominio Hussain5091_lgu contraseña 0 lOV12MEaZx nombre de usuario de autenticación de BroadWorks dominio Hussain5091_lgu contraseña 0 lOV12MEaZx reino 40462196.cisco-bcld.com no hay servidor sip-de-id-remoto dns:40462196.cisco-bcld.com connection-reuse srtp-crypto 200 sesión transporte tcp tls url sips error-passthru asserted-id pai bind control fuente-interfaz GigabitEthernet1 bind media fuente-interfaz GigabitEthernet1 no pass-thru contenido custom-sdp sip-profiles 200 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com política de privacidad passthru inquilino clase de voz 100 sesión transporte udp url sip error-passthru bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 sin contenido pass-thru custom-sdp clase de voz inquilino 300 bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 sin contenido pass-thru custom-sdp clase de voz uri 100 sip host ipv4:198.18.133.3 clase de voz uri 200 sip pattern dtg=hussain1076.lgu voz de par de marcado 101 voip descripción Par de marcado saliente a patrón de destino IP PSTN BAD. protocolo de sesión BAD sipv2 destino ipv4:198.18.133.3 códec de clase de voz 99 inquilino sip de clase de voz 100 dtmf-relay rtp-nte no vad voz de par de marcado 201 voip descripción Par de marcado saliente a patrón de destino de Webex Calling BAD. protocolo de sesión sipv2 destino sip-server 99 stun-usage de clase de voz 200 sin servicio de sip local host sip de clase de voz 200 dtmf-relay rtp-nte srtp no vad clase de voz dpg 100 descripción WebexCalling entrante(DP200) a IP PSTN(DP101) par de marcado 101 preferencia 1 clase de voz dpg 200 descripción IP PSTN entrante(DP100) a Webex Calling(DP201) par de marcado 201 preferencia 1 voz de par de marcado 100 desrición de voip Par de marcado entrante desde protocolo de sesión IP PSTN sipv2 destino dpg 200 solicitud de uri entrante 200 códec de clase de voz 99 stun-usage 200 inquilino sip de clase de voz 200 dtmf-relay rtp-nte srtp no v

Para mostrar la salida del comando show, hemos recargado VCUBE-2 seguido de VCUBE-1, lo que hace que VCUBE-1 sea el CUBE de espera y VCUBE-2 el activo

2

En un momento determinado, solo una plataforma mantendrá una inscripción activa como puerta de enlace local con el SBC de acceso de Webex Calling. Mire los resultados de los siguientes comandos show.

show redundancy application group 1

mostrar el estado del registro sip-ua 

 VCUBE-1#mostrar grupo de aplicaciones de redundancia 1 ID de grupo:1 Nombre del grupo:LocalGateway-HA Estado administrativo: Sin estado operativo agregado de apagado: Mi función: Función de pares de puestos en espera : Presencia de pares activos: Sí, comunicaciones pares: Sí se inició la progresión del pares: Sí, dominio RF: BtoB-un estado RF: Estado RF en espera de pares de tráfico activo: ACTIVO VCUBE-1#mostrar el estado del registro sip-ua VCUBE-1#

 VCUBE-2#mostrar redundancia del grupo de aplicaciones 1 ID de grupo:1 Nombre del grupo:LocalGateway-HA Estado administrativo: Sin estado operativo agregado de apagado: Mi función:  Función del pares activo: Estado de presencia del pares: Sí, comunicaciones pares: Sí se inició la progresión del pares: Sí, dominio RF: BtoB-un estado RF: Estado de RF del pares activo: VCUBE activo en espera-2 #Mostrar SIP-UA inscribir estado inquilino: 200 --------------------Registrador-Índice  1 --------------------- par de línea expira(s) reg survival P-Associ-URI ============================== ========== ========================= ============ Hussain5091_LGU -1 48 sí normal VCUBE-2#

A partir de la salida anterior, puede ver que VCUBE-2 es el LGW activo que mantiene la inscripción con el SBC de acceso de Webex Calling, mientras que la salida de “show sip-ua register status” está en blanco en VCUBE-1

3

Ahora habilite las siguientes depuraciones en VCUBE-1

 VCUBE-1#debug ccsip non-call El rastreo de SIP fuera de diálogo está habilitado VCUBE-1#debug ccsip info El rastreo de información de llamadas SIP está habilitado VCUBE-1#debug ccsip message

4

Simule la recuperación de fallas mediante la emisión del siguiente comando en LGW activo, VCUBE-2 en este caso.

 VCUBE-2#auto-recarga de la aplicación de redundancia del grupo 1

El cambio del LGW ACTIVE a STANDBY ocurre en la siguiente situación, además de la CLI listada anteriormente.

  • Cuando se recarga el enrutador ACTIVE

  • Cuando se apaga y se enciende el enrutador ACTIVE

  • Cuando cualquier interfaz configurada de RG del enrutador ACTIVE para la que está habilitado el seguimiento está apagada

5

Compruebe si VCUBE-1 se ha inscrito en el SBC de acceso de Webex Calling VCUBE-2 ya debería haberse recargado.

 VCUBE-1#mostrar el estado del registro sip-ua Inquilino: 200 --------------------Registrador-Índice  1 par --------------------- de línea expira(s) reg survival (s) P-Associ-URI ============================== ========== ======================== ============ Hussain5091_LGU -1 56 sí normal VCUBE-1#

VCUBE-1 ahora es el LGW activo.

6

Mire el registro de depuración relevante en VCUBE-1 que envía un SIP REGISTER a Webex Calling a través de la IP virtual y recibe 200 OK.

 VCUBE-1#mostrar registro 9 de enero de 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG ID 1 El tiempo de saludo caducó.9  de enero de 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: Cambio de rol de ID 1 de RG de En espera a Activo, 9 de enero de 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: Cambio, de EN ESPERA_CALIENTE a ACTIVO. 9 de enero de 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Se recibió notificar el evento de rol activo 9 de enero 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Enviado: REGISTRAR sip: 40462196.cisco-bcld.com:5061 SIP/2.0 a través de: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 De: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 A: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Fecha: Jue, 09 ene 2020 18:37:24 GMT llamada-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 usuario-agente: Cisco-SIPGateway/IOS-16.12.02 Max-forwards: 70 timestamp: 1578595044 CSeq: 2 INSCRIBIR Contacto: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Caduca: 240 compatible: Contenido de la ruta: longitud: 0 

9 de enero 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg: Recibido: SIP/2.0 401 no autorizado a través de: SIP/2.0/TLS 198.18.1.228:5061;recibido=173.38.218.1;branch=z9hG4bK0374;rport=4742 De: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 A: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Fecha: Jue, 09 ene 2020 18:37:24 GMT llamada-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 timestamp: 1578595044 CSeq: 2 inscribir WWW-autenticar; Dominio implícito = "BroadWorks", qop = "auth", nonce = "BroadWorksXk572qd01Ti58zliBW", Algorithm = contenido de MD5: longitud: 0 

9 de enero 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Enviado: REGISTER SIP: 40462196. Cisco-bcld.com:5061 SIP/2.0 a través de: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC De: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 A: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Fecha: Jue, 09 ene 2020 18:37:25 GMT llamada-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 usuario-agente: Cisco-SIPGateway/IOS-16.12.02 Max-forwards: 70 timestamp: 1578595045 CSeq: 3 REGISTRAR Contacto: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Caduca: 240 compatible: Autorización de ruta: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 Content-Length: 0 

9 de enero 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:  Recibido: SIP/2.0 200 OK Vía: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 De: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 A: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 Identificador de llamada: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 timestamp: 1578595045 CSeq: 3 INSCRIBIR Contacto: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-Events: llamada-información, Asunción de línea, cuadro de diálogo, mensaje-Resumen, como-característica-evento, x-Broadworks-Hotel, x-Broadworks-estado de llamada-centro, contenido de conferencia-longitud: 0