Reglas del Routing IP en Acano y Cisco que encuentran el servidor (CMS)
Contenido
Introducción
Este documento describe las reglas del Routing IP en Acano o Cisco que resuelve los servidores del servidor (CMS). Los servidores de Acano o de CMS pueden tener interfaces múltiples configuradas, cada uno con su propio default gateway.
Prerrequisitos
Requisitos
Cisco recomienda que tenga conocimiento sobre estos temas:
- Componentes de CMS:
- WebBridge (WB)
- Traversal usando las retransmisiones alrededor del servidor NAT (VUELTA)
- CallBridge (CB)
- Routing IP básico
Componentes Utilizados
La información en este documento se basa en Cisco que resuelve el servidor 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.
Información previa
La única limitación aquí es que las diversas interfaces en la necesidad del 4-port Switch de estar en diversas subredes como usted pueden terminar de otra manera para arriba con los problemas de ruteo en su configuración. Como excepción a ese, los servidores del hardware X que tienen una interfaz ADMIN se permiten tener esta interfaz ADMIN en la misma subred como una de las otras interfaces (A/B/C/D) según lo descrito en CMS instale la guía y mostrado en esta nota.
Usted puede ejecutarse en una situación donde usted necesita conocer la lógica de la encaminamiento cuando usted recibiría las peticiones del atascamiento en su componente del servidor de la VUELTA por ejemplo de verificar de qué interfaz se envía la respuesta.
¿Qué Routing IP gobierna se aplica en los servidores Acano/CMS?
La lógica del Routing IP depende encendido si la conexión es User Datagram Protocol (UDP) o Transmission Control Protocol (TCP) en la naturaleza.
En el caso del TCP, si es una nueva conexión o una contestación entrante, usted puede descubrir que la lógica del Routing IP es aplicable a su caso con el uso del organigrama en la imagen.
Contestación de la conexión TCP de entrada
El servidor Acano/CMS contesta para una conexión TCP de entrada en la interfaz sí mismo en la cual se recibe la petición (pues hay ya una conexión TCP).
Conexión TCP saliente o cualquier paquetes UDP salientes
Para ambos escenarios, estas reglas del Routing IP se siguen según este organigrama (así como el primer paso para las contestaciones de la conexión TCP de entrada).
¿Cómo mostrar todas las tablas de IP Routing (por la interfaz)?
Por el uso del <interface> del comando ipv4 en el procesador de administración de Mainboard (MMP).
Con esto usted puede ver el IP Address configurado y la longitud del prefijo así como todas las Static rutas que se configuran para esta interfaz tal y como se muestra en de esta imagen.
Por ejemplo aquí, las rutas a 8.8.8.8/32 y a 8.8.4.4/32 se configuran para salir explícitamente en esta interfaz particular (a):
Usted puede también ver las rutas agregadas en el live.json para clasifiar para la interfaz respectiva (a) que asocia 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 borrar las Static rutas a una interfaz específica, usted puede utilizar la ruta del <interface> del comando ipv4 (agregue | length> del del) <address>/<prefix.
¿Cómo marcar y cambiar la interfaz predeterminada?
Por abandono interconecte A es la predeterminada si usted comienza con una configuración vacía.
Usted puede verificar esto en la interfaz por el parámetro predeterminado según lo resaltado en esta imagen:
Ésta es la salida del <interface> del comando ipv4 en el MMP.
Usted puede también ver del live.json si la interfaz A (que asocia 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, usted puede utilizar el valor por defecto del <interface> del comando ipv4, pero se asegura de que usted tiene la Static ruta correcta para acomodar este cambio que la encaminamiento es de otra manera afectada.
Ejemplo:
La imagen representa un ejemplo de una sola configuración de servidor de la fractura con una base y de un servidor del borde con estos requisitos:
- El servidor de la base puede conectar solamente con la interfaz DMZ (a) y no con los públicos (C y D).
- El componente del servidor de la VUELTA necesita escuchar en 443 apenas como el WebBridge (y diversas interfaces se requieren así para evitar un choque del puerto).
En este ejemplo no se ha configurado ninguna encaminamiento especial y no se ha especificado ninguna diversa interfaz predeterminada así que omite para interconectar A en el servidor del borde.
Situación:
- Los clientes de WebRTC pueden iniciar sesión solamente fall de las llamadas
- Atando y afecte un aparato las peticiones del CB al servidor de la VUELTA consiguen las respuestas de un éxito
- Atando y afecte un aparato las peticiones de los clientes externos de WebRTC al servidor de la VUELTA llegan pero no consiguen las respuestas del éxito
Explicación:
- Mientras que el WB y el Loadbalancer (LB) responden solamente a las conexiones TCP de entrada y no inician los salientes ellos mismos, esta encaminamiento no plantea un problema.
- También el atascamiento y afecta un aparato las peticiones del CB al IP del servidor DMZ de la VUELTA consigue respondido mientras que cualquiera ellas está en la misma subred (la interfaz A del borde y la base interconectan A) o porque no hay Static ruta configurada y la apenas la envía hacia fuera en la interfaz predeterminada (interconecte A en este caso).
- Para el atascamiento del externo y afecte un aparato las peticiones, no tiene ninguna Static rutas y utiliza así la interfaz predeterminada A para rutear hacia fuera el tráfico (que da lugar a no alcanzar al cliente externo).
Solución:
- Agregue la interfaz B en los servidores del borde y utilice la interfaz A para la conexión interna WB (así como el LB) e interconecte B para la conexión del servidor interna de la VUELTA (evitar el choque del puerto en 443 se utiliza para la VUELTA y el WB). Configure esto con los comandos siguientes en el MMP (y corrija la configuración de la VUELTA en sus callbridges por consiguiente para los nuevos serverAddress de la interfaz B).
ipv4 b agregan el <default-gateway> del length> <IP-address>/<prefix
permiso ipv4 b
dé vuelta a la neutralización
la vuelta escucha d b
dé vuelta al permiso
- Agregue las Static rutas para rutear el tráfico de los servidores del borde hacia fuera al servidor interno de la base con el comando:
la ruta ipv4 b agrega el length> <address>/<prefix
Por ejemplo si el servidor de la base tiene la dirección IP 192.168.0.100/24, el comando debe o ser ruta ipv4 b agrega 192.168.0.100/24 o la ruta ipv4 b agrega 192.168.0.100/32.
- Haga su Interfaz de servidor externa de la VUELTA (d) como la interfaz predeterminada para el tráfico.
valor por defecto ipv4 d
Verificación
Actualmente, no hay un procedimiento de verificación disponible para esta configuración.
Troubleshooting
No hay actualmente specifictroubleshootinginformation disponible para esta configuración.
Información Relacionada
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)