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:
Redundancia box-a-box de nivel 2 con CUBE Enterprise para protocolos preservación de llamada
Las pautas de configuración proporcionadas en este artículo suponen que es 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 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 gateway local requiere IOS-XE versión 16.12.2 o posterior y es compatible en las siguientes plataformas:
Serie ISR4000: 4321, 4331, 4351, 4431, 4451, 4461 (IOS-XE 17.2.1r)
Serie CSR1000: vCUBE (configuraciones de 1, 2 y 4 vCPU)
Los comandos para mostrar 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 vCUBE (CSR1000v). |
Material de referencia
A continuación se detallan algunas guías de configuración de CUBE HA para diversas plataformas:
CSR 1000v (vCUBE):—https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Arquitectura preferida de Cisco para Cisco Webex Calling:https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling de la solución de software
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 dos PSTN diferentes para los clientes:
Proveedor de servicios PSTN Cloud Connected
Puerta de enlace local
La implementación de la puerta de enlace local (representada a continuación) es el punto central de este artículo. La puerta de enlace local es la opción Acercar PSTN propio para Cisco Webex Calling ofreciendo 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 asegura mediante el transporte TLS para SIP y SRTP para medios.
La figura a continuación muestra una implementación Webex Calling sin ninguna IP PBX existente y se aplica a una implementación única o de varios sitios. La configuración que se describe en este artículo se basa en esta implementación.
Redundancia de cuadro a cuadro de nivel 2
La redundancia box-a-box de nivel 2 de CUBE HA utiliza el protocolo de infraestructura de grupo de redundancia (RG) para formar un par de enrutadores activo/de espera. Estos pares comparten 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 de modo espera tome todas las responsabilidades del procesamiento de llamadas de CUBE con el paso inmediato si el enrutador activo queda fuera de servicio, lo que resulta en conservación stateful de señales y medios.
La función de punto de verificación está limitada a llamadas conectadas con paquetes de medios. Las llamadas en tránsito no se marcan para (por ejemplo, un estado de intento o de timbre). En este artículo, CUBE HA hará referencia a la redundancia CUBE High Availability (HA) De Nivel 2 box-to-box (B2B) para obtener información de estado preservación de llamada |
A partir de IOS-XE 16.12.2, CUBE HA se puede implementar como puerta de enlace local para implementaciones de Cisco Webex Calling y cubriremos consideraciones de diseño y configuraciones 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 Cisco Webex Calling cube.
Componente infra del grupo de redundancia
El componente del grupo de redundancia (RG) Infra proporciona soporte para la infraestructura de comunicación de cuadro a cuadro entre los dos CUBEs y negocia el estado de redundancia estable final. Este componente también proporciona:
Un protocolo HSRP-like que negocia el estado de redundancia final para cada enrutador mediante la intercambiar mensajes keepalive y hello entre los dos CUBEs (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ñales y medios para cada llamada desde el activo al enrutador de modo 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 (varias interfaces de tráfico se pueden configurar con el mismo grupo RG): GigabitEthernet 1 y 2 se consideran interfaces de tráfico.
Este componente de RG debe configurarse específicamente para admitir alta alta calidad de voz B2B.
Administración de la dirección IP virtual (VIP) para señales y medios
B2B HA depende de la VIP para lograr redundancia. La VIP y las interfaces físicas asociadas en ambos CUBEs en el par CUBE HA deben residir en la misma subred LAN. La configuración de la VIP y el enlace de la interfaz VIP para una aplicación de voz (SIP) en particular son obligatorias para la compatibilidad con alta alta calidad de voz B2B. Los dispositivos externos, como Unified CM, Webex Calling acceder al SBC, al proveedor de servicios o al proxy, usan la VIP como dirección IP de destino para las llamadas que atraviesan los enrutadores de HA de CUBE. Por lo tanto, desde Webex Calling punto de vista, los pares de HA de CUBE actúan como una única puerta de enlace local.
La información de la sesión de RTP y la 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 router Activo se cae, el enrutador de modo espera toma el control y sigue reenviando el flujo RTP que había sido enrutado anteriormente 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 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 de estado de las llamadas:
El sistema de alta disponibilidad de CUBE no puede tener interfaces TDM o analógicos ubicadas en forma coofi
A Gig1 y Gig2 se les conoce como interfaces de tráfico (SIP/RTP) y Gig3 es una interfaz de control/datos de grupos 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 RG deben pertenecer a dominios de nivel 2 diferentes (vlan, interruptor independiente)
El canal de puertos es compatible con las interfaces de control/datos y tráfico de RG
Todas las señales/medios son fuente de/a la dirección IP virtual
Cada vez que se recarga una plataforma en una relación CUBE-HA, siempre arranca en modo espera
La dirección más baja para todas las interfaces (Gig1, Gig2, Gig3) debe estar en la misma plataforma
Identificador de interfaz de redundancia, debe ser único para una combinación de par/interfaz en el mismo nivel 2
La configuración de los CUBEs debe ser idéntica, incluida la configuración física, y debe ejecutarse en el mismo tipo de plataforma y en la versión de IOS-XE
Las interfaces de bucle no se pueden utilizar como enlace ya que siempre están arriba
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 RG (Gig3)
Ambas plataformas deben ser idénticas y conectarse a través de un Interruptor físico en todas las interfaces del mismo modo para que CUBE HA funcione, es decir, GE0/0/0 de CUBE-1 y CUBE-2 deben finalizar en el mismo interruptor, y así sucesivamente.
No se puede cancelar WAN en CUBEs directamente o en la disponibilidad de datos en cualquiera de los lados
Tanto activo como en espera deben estar en el mismo centro de datos
Es obligatorio utilizar interfaz L3 independiente para la redundancia (control/datos RG, Gig3). es decir, la interfaz que se utiliza para el tráfico no se puede utilizar para mantener la disponibilidad y los puntos de control
En la recuperación de fallas, el CUBE, anteriormente activo, pasa por una recarga por diseño, preservación de las señales y los medios
Configurar redundancia en ambos CUBES
Debe configurar redundancia box-to-box de nivel 2 en ambos CUBEs pensados para ser utilizados en un par de alta alta seguridad para mostrar las IP virtuales.
1 | Configure el seguimiento de la interfaz a nivel global para realizar un seguimiento del estado de la interfaz.
El track CLI 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é abajo. |
||||||
2 | Configure un RG para utilizar con alta VoIP bajo el sub mode de redundancia de la aplicación.
Aquí se ofrece una explicación de los campos utilizados en esta configuración:
|
||||||
3 | Habilite la redundancia box-to-box para la aplicación CUBE. Configure el RG del paso anterior en voz
Redundancia-grupo 1: para agregar y eliminar este comando es necesario volver a cargarla configuración actualizada para que entre en vigencia. Volveremos a cargar las plataformas una vez que se haya aplicado toda la configuración. |
||||||
4 | Configurar las interfaces Gig1 y Gig2 con sus respectivas IP virtuales como se muestra a continuación y aplicar el identificador de la interfaz de redundancia (pliquen)
Aquí se ofrece una explicación de los campos utilizados en esta configuración:
|
||||||
5 | Guarde la configuración del primer CUBE y vuelva a cargarlo. La plataforma para volver a cargar el último es siempre el Modo espera.
Después de que VCUBE-1 se inicia completamente, guarde la configuración de VCUBE-2 y vuelva a cargarla.
|
||||||
6 | Verifique que la configuración de cuadro a cuadro 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 plataforma para volver a cargar en último lugar siempre será en modo de espera.
|
Configurar una puerta de enlace local en ambos CUBES
En nuestra configuración de ejemplo, estamos utilizando la siguiente información del Concentrador de control para desarrollar la configuración de la puerta de enlace local tanto en las plataformas, VCUBE-1 comoVCUBE-2. El nombre de usuario y la contraseña de esta configuración son los siguientes:
Usuario: Hussain1076_LGU
Contraseña: lOV12MEaZx
1 | Asegúrese de que se haya creado una clave de configuración para la contraseña con los comandos que se muestran a continuación, antes de poder utilizarse en las credenciales o en la compartición de valor. Las contraseñas del tipo 6 se cifran mediante cifrado AES y esta clave de configuración definida por el usuario.
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 mostrados arriba, guarde y vuelva a cargar. Las credenciales del Resumen de SIP de Control Hub se resaltan en negrita .
Para mostrar la salida del comando Mostrar, hemos recargado VCUBE-2 seguido de VCUBE-1 , lo que hace que VCUBE-1 el CUBE de modo espera y VCUBE-2 el CUBE activo |
2 | En un momento determinado, solo una plataforma mantendrá una inscripción activa como puerta de enlace local con el acceso de Webex Calling SBC. Mire los resultados de los siguientes comandos de la demostración. mostrar grupo de aplicación de redundancia 1 mostrar estado de registro sip-ua
A partir de la salida anterior, puede ver que VCUBE-2 es el LGW activo que mantiene el registro con el SBC de acceso de Webex Calling, mientras que la salida de "mostrar estado de registro sip-ua" está en blanco en VCUBE-1 |
3 | Ahora habilite las siguientes depuraciones en VCUBE-1
|
4 | Simule recuperación de fallas mediante la emisión del siguiente comando en LGW, VCUBE-2 activo en este caso.
El cambio del dispositivo ACTIVO al LGW de modo de espera ocurre en las siguientes situaciones, además de la CLI enumerada anteriormente.
|
5 | Compruebe si VCUBE-1 se ha registrado con Webex Calling SBC. VCUBE-2 ya se habría recargado.
VCUBE-1 ahora es el LGW activo. |
6 | Mire el registro de depuración relevante en VCUBE-1 enviando un REGISTRO SIP a Webex Calling a través de la IP virtual y recibiendo un 200 OK.
|