Reglas de routing IP en Acano y Cisco Meeting Server (CMS)
Contenido
Introducción
Este documento describe las reglas de IP Routing en los servidores Acano o Cisco Meeting Server (CMS). Los servidores CMS o Acano pueden tener varias interfaces configuradas, cada una con su propio gateway predeterminado.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- Componentes de CMS:
- WebBridge (WB)
- Traversal mediante retransmisiones 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.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. 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 subredes diferentes ya que de lo contrario puede terminar con problemas de ruteo en su configuración. Como excepción a esto, los servidores de hardware X 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.
Puede encontrarse con una situación en la que necesita 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 en servidores Acano/CMS?
La lógica de routing IP depende de si la conexión es de naturaleza 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 ruteo IP se aplica 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 propia interfaz en la que se recibe la solicitud (ya que ya hay una conexión TCP).
Conexión TCP saliente o cualquier paquete UDP saliente
Para ambos escenarios, estas reglas de IP Routing se siguen según este diagrama de flujo (así como el primer paso para las respuestas de conexión TCP entrante).
¿Cómo se Muestran Todas las Tablas de IP Routing (por Interfaz)?
Mediante el uso del comando ipv4 <interface> en el Procesador de administración de placa base (MMP).
Con esto puede ver la dirección IP configurada y la longitud del prefijo, así como todas las rutas estáticas configuradas 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 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"
}
}
"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 verificar y cambiar 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 por el parámetro predeterminado como se resalta en esta imagen:
Este es el resultado del comando ipv4 <interface> en MMP.
También puede ver en 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 tener las rutas estáticas adecuadas para acomodar este cambio de otra manera el ruteo se verá afectado.
Ejemplo:
La imagen representa un ejemplo de configuración de un único servidor dividido con un servidor Core y un servidor Edge con estos requisitos:
- El servidor principal solo puede conectarse a la interfaz DMZ (A) y no a las públicas (C & D).
- El componente TURN del servidor debe escuchar en 443 al igual que WebBridge (y por lo tanto, se requieren interfaces diferentes para evitar un conflicto 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 el valor predeterminado es la interfaz A en el servidor perimetral.
Situación:
- Los clientes WebRTC pueden iniciar sesión pero las llamadas fallan
- El enlace y asignación de solicitudes de CB al servidor TURN obtienen respuestas de éxito
- Llega el enlace y asignación de solicitudes de clientes WebRTC externos al servidor TURN, pero no se obtienen las respuestas Success
Explicación:
- Como WB y Loadbalancer (LB) sólo responden a las conexiones TCP entrantes y no inician las salientes por sí mismas, este routing no plantea ningún problema.
- Además, las solicitudes de enlace y asignación del CB a la IP de DMZ del servidor de activación se responden ya que se encuentran en la misma subred (interfaz de borde A y interfaz de núcleo A) o porque no hay ninguna ruta estática configurada y simplemente la envía a la interfaz predeterminada (interfaz A en este caso).
- Para las Solicitudes de Enlace y Asignación externas, no tiene rutas estáticas y, por lo tanto, utiliza la interfaz A predeterminada para rutear el tráfico (lo que da lugar a que no llegue al 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 interna del servidor TURN (para evitar la colisión de puertos en 443 se utiliza tanto para la activación como para WB). Configure esto con los siguientes comandos en el MMP (y corrija la configuración de activación en los callbridges según corresponda para la nueva dirección del servidor de la interfaz B).
ipv4 b add <IP-address>/<prefix length> <default-gateway>
ipv4 b enable
desactivar
volver a escuchar b
Activar
- Agregue rutas estáticas para rutear el tráfico desde los servidores de borde hacia el servidor de núcleo interno con el comando:
ipv4 b route add <address>/<prefix length>
Por ejemplo, si el servidor de núcleo 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.
- Haga de su interfaz de servidor TURN externa (D) 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 específica de resolución de problemas disponible para esta configuración.
Comentarios