- Inicio
- /
- Artículo
Implemente la alta disponibilidad de CUBE como puerta de enlace local
La puerta de enlace local (LGW) es la solución exclusiva para proporcionar acceso PSTN local a los clientes de Cisco Webex Calling. Este documento lo guía para configurar una puerta de enlace local mediante la alta disponibilidad de CUBE, con CUBE activos o en espera a fin de garantizar la recuperación de fallas con inspección de estado de las llamadas activas.
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:
-
Redundancia entre decodificadores de nivel 2 con CUBE Enterprise para la preservación de llamadas con inspección de estado
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:
-
Cisco ISR 4K y Cisco Catalyst serie 8K: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-isr-g3.html
-
CSR 8000 v (vCUBE): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-csr.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
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.
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.
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.
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.
1 |
Configure el seguimiento de la interfaz a nivel global para rastrear el estado de la interfaz.
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.
A continuación, se ofrece una explicación de los campos utilizados en esta configuración:
| ||
3 |
Habilite la redundancia entre decodificadores para la aplicación CUBE. Configure el RG en el paso anterior en
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)
A continuación, se ofrece una explicación de los campos utilizados en esta configuración:
| ||
5 |
Guarde la configuración del primer CUBE y vuelva a cargarla. La última plataforma en volver a cargarse es siempre la de espera.
Después de que VCUBE-1 se inicie completamente, guarde la configuración de VCUBE-2 y vuelva a cargarla.
| ||
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. 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. |