- Inicio
- /
- Artículo
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:
-
Redundancia de caja a caja de capa 2 con CUBE Enterprise para la preservación de llamadas con estado
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:
-
Arquitectura preferida de Cisco paraCisco Webex Calling: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
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.
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.
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.
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.
| 1 |
Configure el seguimiento de la interfaz a nivel global para realizar un seguimiento del estado de la interfaz.
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.
Aquí hay una explicación de los campos utilizados en esta configuración:
| ||
| 3 |
Habilite la redundancia caja a caja para la aplicación CUBE. Configure el RG del paso anterior debajo
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)
Aquí hay 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 recargar la última vez es siempre el modo de espera.
Después de que VCUBE-1 se inicie por completo, guarde la configuración de VCUBE-2 y vuelva a cargarla.
| ||
| 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.
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. |