Reglas de routing de IP en Acano y Cisco Meeting Server (CMS)

Introducción

Este documento describe las reglas de IP Routing en servidores Acano o Cisco Meeting Server (CMS). Los servidores Acano o CMS pueden tener varias interfaces configuradas, cada una con su propia gateway predeterminada.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Componentes de CMS: 
  • WebBridge (WB)
  • Traversal mediante relés alrededor del servidor NAT (TURN)
  • CallBridge (CB)
• Routing IP básico

Componentes Utilizados

La información de este documento se basa en Cisco Meeting Server en la versión 2.3.x.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

La única limitación aquí es que las diferentes interfaces en el switch de 4 puertos deben estar en diferentes subredes ya que de lo contrario puede terminar con problemas de ruteo en su configuración. Como excepción a esto, los servidores X de hardware que tienen una interfaz ADMIN pueden tener esta interfaz ADMIN en la misma subred que una de las otras interfaces (A/B/C/D) como se describe en la guía de instalación de CMS y se muestra en esta nota.

Nota: dos interfaces cualesquiera de Cisco Meeting Server no deben colocarse en la misma subred. La única excepción es que la interfaz ADMIN de un servidor físico Acano serie X puede estar en la misma subred que una de las otras interfaces (A a D) y es probablemente una implementación común.

Puede encontrarse con una situación en la que necesite conocer la lógica de ruteo cuando recibiría Solicitudes de enlace en su componente de servidor TURN, por ejemplo, para verificar desde qué interfaz se envía la respuesta.

¿Qué reglas de routing IP se aplican a los servidores Acano/CMS?

La lógica de enrutamiento IP depende de si la conexión es de tipo UDP (Protocolo de datagramas de usuario) o TCP (Protocolo de control de transmisión).
En el caso de TCP, ya sea una nueva conexión o una respuesta a una entrante, puede averiguar qué lógica de IP Routing es aplicable a su caso con el uso del diagrama de flujo en la imagen.

Respuesta de conexión TCP entrante

El servidor Acano/CMS responde para una conexión TCP entrante en la interfaz en sí en la que se recibe la solicitud (puesto que ya existe una conexión TCP).

Conexión TCP saliente o cualquier paquete UDP saliente

Para ambos escenarios, estas reglas de ruteo IP se siguen según este diagrama de flujo (así como el primer paso para las respuestas de conexión TCP de entrada).

Nota: La lógica se aplica a la creación de nuevos paquetes UDP salientes o a aquellos enviados en respuesta a los paquetes recibidos.

¿Cómo se muestran todas las tablas de routing de IP (por interfaz)?

Mediante el uso del comando ipv4 <interface> en el procesador de administración de la placa base (MMP).

Con esto puede ver la dirección IP configurada y la longitud del prefijo, así como todas las rutas estáticas que se configuran para esta interfaz como se muestra en esta imagen.

Por ejemplo, aquí, las rutas a 8.8.8.8/32 y 8.8.4.4/32 se configuran para salir explícitamente en esta interfaz en particular (a):

También puede ver las rutas agregadas en el archivo live.json para la interfaz respectiva (A) que se mapea a eth4.

    "ipv4": {
        "module": {
            "interfaces": {
                "eth4": {
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "macaddress": "00:50:56:99:5A:5B",
                    "address": "10.48.54.160",
                    "prefixlen": "24",
                    "gateway": "10.48.54.200",
                    "routes": {
                        "8=8=8=8-32": {
                            "address": "8.8.8.8",
                            "prefixlen": "32"
                        },
                        "8=8=4=4-32": {
                            "address": "8.8.4.4",
                            "prefixlen": "32"
                        }
                    }

Nota: En el archivo live.json, las interfaces A-D (desde el MMP) se asignan a eth4-eth1, de modo que la interfaz A se asigna a eth4 y la interfaz D se asigna a eth1. El otro fragmento de código es un fragmento de código de un servidor de la serie X donde puede ver que la interfaz ADMIN está en la sección de mmp bajo ipv4 en lugar de module como se muestra para las otras interfaces.

    "ipv4": {
        "mmp": {
            "interfaces": {
                "eth0": {
                    "macaddress": "44:4A:65:00:13:00",
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "address": "10.48.79.72",
                    "prefixlen": "24",
                    "gateway": "10.48.79.200"
                }

Para agregar o eliminar rutas estáticas a una interfaz específica, puede utilizar el comando ipv4 <interface> route (add | del) <address>/<prefix length>.

¿Cómo se verifica y cambia la interfaz predeterminada?

De forma predeterminada, la interfaz A es la predeterminada si comienza con una configuración en blanco.

Puede verificar esto en la interfaz mediante el parámetro default resaltado en esta imagen:

Ésta es la salida del comando ipv4 <interface> en MMP.

Nota: Si este valor se establece en true, esta es la interfaz predeterminada como en la imagen.

También puede ver en el archivo live.json si la interfaz A (que se asigna a eth4) está configurada como la interfaz predeterminada.

    "ipv4": {
        "module": {
            "interfaces": {
                "eth4": {
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "macaddress": "00:50:56:99:5A:5B",
                    "address": "10.48.54.160",
                    "prefixlen": "24",
                    "gateway": "10.48.54.200",
                    "routes": {
                        "8=8=8=8-32": {
                            "address": "8.8.8.8",
                            "prefixlen": "32"
                        },
                        "8=8=4=4-32": {
                            "address": "8.8.4.4",
                            "prefixlen": "32"

Para cambiar la interfaz predeterminada, puede utilizar el comando ipv4 <interface> default, pero asegúrese de que tiene las rutas estáticas adecuadas para acomodar este cambio; de lo contrario, el ruteo se verá afectado.

Ejemplo:

La imagen representa un ejemplo de una configuración de servidor de división única con un servidor central y un servidor perimetral con estos requisitos:

• El servidor de núcleo solo se puede conectar a la interfaz DMZ (A) y no a las públicas (C y D).
• TURN server component necesita escuchar en 443 al igual que WebBridge (y por lo tanto se requieren diferentes interfaces para evitar un choque de puertos).

En este ejemplo, no se ha configurado ningún ruteo especial y no se ha especificado ninguna interfaz predeterminada diferente, por lo que se establece de forma predeterminada en la interfaz A en el servidor perimetral.

Situación:

• Los clientes WebRTC pueden iniciar sesión, pero las llamadas fallan
• El enlace y la asignación de solicitudes del CB al servidor de activación obtienen una respuesta de éxito.
• El enlace y la asignación de solicitudes de clientes WebRTC externos al servidor TURN llegan, pero no obtienen respuestas de éxito

Explicación:

• Como WB y Loadbalancer (LB) sólo responden a las conexiones TCP entrantes y no inician ellas mismas las salientes, este ruteo no plantea ningún problema.

Nota: Como ambos servicios están en el mismo servidor, el WB puede aún realizar una conexión saliente al LB, pero eso sucede internamente.

• También las solicitudes Binding y Allocate del CB al IP de DMZ del servidor TURN reciben respuesta, ya sea porque están en la misma subred (interfaz Edge A e interfaz Core A) o porque no hay una ruta estática configurada y simplemente la envía en la interfaz predeterminada (interfaz A en este caso).
• Para las solicitudes Binding y Allocate externas, no tiene rutas estáticas y, por lo tanto, utiliza la interfaz predeterminada A para rutear el tráfico (lo que resulta en no alcanzar el cliente externo).

Solución:

• Agregue la interfaz B en los servidores Edge y utilice la interfaz A para la conexión WB interna (así como la LB) y la interfaz B para la conexión de servidor TURN interna (para evitar el choque de puertos en 443 se utiliza tanto para TURN como para WB). Configure esto con los siguientes comandos en el MMP (y corrija la configuración TURN en sus callbridges en consecuencia para la nueva dirección del servidor de la interfaz B).

ipv4 b add <IP-address>/<prefix length> <default-gateway>
ipv4 b enable

turn disable
turn listen d b
turn enable

• Añada rutas estáticas para rutear el tráfico desde los servidores Edge hacia el servidor Core interno con el comando:
    
    ipv4 b route add <address>/<prefix length>

Nota: Como LB y WB sólo reaccionan en conexiones TCP entrantes, sólo necesita configurar el ruteo para los paquetes UDP para TURN y, por lo tanto, hacer esto en la interfaz B. Asegúrese también de que el gateway en la interfaz B pueda rutearlo al CB, por supuesto.

Por ejemplo, si el servidor Core tiene la dirección IP 192.168.0.100/24, el comando debe ser ipv4 b route add 192.168.0.100/24 o ipv4 b route add 192.168.0.100/32.

• Establezca la interfaz del servidor TURN (D) externa como la interfaz predeterminada para el tráfico.

ipv4 d default

Verificación 

Actualmente, no hay un procedimiento de verificación disponible para esta configuración.

Troubleshoot 

Actualmente no hay información de solución de problemas específica disponible para esta configuración.

Información Relacionada 

• Soporte Técnico y Documentación - Cisco Systems
• Herramienta Analizador de soluciones de colaboración 
• documentación de CMS