Configuración y resolución de problemas de TITAN con CURWB

Introducción

Este documento describe el uso de TITAN, su configuración y la resolución de problemas en implementaciones CURWB.

Fundamentos de TITAN

TITAN es una función crítica que ofrece alta disponibilidad con redundancia de hardware en implementaciones CURWB. Se puede configurar a través de varias funciones de la parte fija de la red de fluidez. Las aplicaciones más comunes son la habilitación de TITAN en las gateways globales de la red principal, gateways de extremo de malla local y radios de vehículos a bordo. Funciona tanto en redes de capa 2 como de capa 3.

Cuando está habilitado, TITAN proporciona conmutación por fallas rápida de un dispositivo Primario a un dispositivo Secundario, en menos de 500 milisegundos. El dispositivo secundario reanuda inmediatamente las comunicaciones MPLS CURWB.

El ejemplo que se muestra aquí muestra la conmutación por fallo TITAN en las tres condiciones.

• Gateways globales de red principal,
• Gateways de extremo de malla local y
• Radios de vehículos a bordo

 

¿Cómo actúa TITAN?

 Para comprender completamente el concepto de Titán, es esencial familiarizarse con Autotap. Es un mecanismo de prevención de loop de red que permite a los dispositivos CUWRB detectar conexiones y permitir solamente una ruta de ingreso/egreso dedicada hacia y desde el extremo de malla o el núcleo de la red.

Las radios con la misma frase de contraseña, conectadas al mismo switch de red en el mismo dominio de difusión, actúan como una sola unidad con varias antenas.

El protocolo de malla CURWB detecta las conexiones por cable entre radios, con rutas que se construyen automáticamente. El resultado es como tener un solo AP con varias interfaces inalámbricas.

La función de toque automático evita los bucles de red en estas configuraciones. Sólo la radio seleccionada como Primaria (ID de malla numérica más baja) en un grupo conectado físicamente publica información de dirección MAC. El tráfico se ve viniendo solamente de la radio elegida como la radio principal del grupo conectado.

Infraestructura fija

El usuario configura dos unidades de extremo de malla con la misma configuración y las conecta al mismo switch. Estos dispositivos comparten información para seleccionar el Primario y la otra unidad está en espera. Cuando se produce un fallo, la unidad en espera toma el control en 500 ms y conecta todos los puntos de malla al sistema. Para las redes fijas, TITAN solo se puede habilitar en las unidades de extremo de malla y los puntos establecen automáticamente una conexión con el extremo que tomó el control.

Vehículos para la movilidad   

El proceso es el mismo que en una red fija, las unidades deben estar en el mismo switch con la misma configuración. El algoritmo establece una como la unidad principal y la otra como la secundaria. En caso de que el primario falle, la unidad secundaria toma el control en 500 ms y establece una conexión con la unidad cerrada en tierra. La única diferencia con la movilidad es que TITAN se puede habilitar en las unidades de punto de malla. En ese caso, la función Fluidez sustituye al modo de funcionamiento de la radio. 

Radio en tierra 

Cuando la radio no puede comunicarse con la red troncal, el sistema obliga a los vehículos a conectarse a la pista más cercana como respuesta inmediata al fallo. Es el mismo proceso que para las redes fijas, pero con la posibilidad de más de un lado de la pista en espera activo. En el sistema de tierra, la copia de seguridad no es una radio en modo de espera, sino una completamente operativa y activa que puede cubrir la falla. 

Puerta de enlace conectada a la red corporativa

Al igual que los extremos de malla en una red fija, las puertas de enlace (FM1000 y FM10000) funcionan juntas para seleccionar un Primario y la copia de seguridad se hace cargo en caso de fallo. 

Elección primaria
Todas las unidades CURWB conectadas al mismo dominio de difusión por cable y configuradas con la misma frase de contraseña realizan un proceso de elección primaria distribuida cada pocos segundos. La unidad principal constituye un punto de borde de la red CURWB MPLS, es decir, un dispositivo en el que el tráfico de usuario puede entrar o salir de la malla. Las unidades secundarias actúan como puntos de retransmisión MPLS. Para cada vecino, el algoritmo calcula un valor de precedencia basado en la función de la unidad (mesh-end o mesh-point) y su ID de malla. A los extremos de malla se les asigna una prioridad más alta que a los puntos de malla y, entre la misma prioridad, se prefiere la unidad con el ID de malla más bajo. El mecanismo de elección se basa en un protocolo de señalización dedicado que se ejecuta constantemente en la red, y garantiza que todas las unidades elijan el mismo Primario.

Fallo de fin de malla
Durante el funcionamiento normal, las mallas Primaria y Secundaria finalizan continuamente para comunicarse entre sí acerca de su estado e intercambiar información de alcance de la red. En particular, el Primario envía periódicamente actualizaciones al Secundario con respecto a su tabla de reenvío interna y rutas multicast.

Configuración

En la configuración básica de TITAN, una implementación necesitaría dos gateways (extremo de malla): una principal y otra secundaria.

Tanto las piezas de hardware primarias como las secundarias deben tener estas configuraciones TITAN.

configure mpls fastfail status enabled

configure mpls fastfail timeout 150

config mpls unicast-flood enabled

config mpls arp-unicast disabled

config spanning-tree link-guard 40

config arp gratuitous enabled

configure arp gratuitous delay 150

En las configuraciones de Capa 3, si se requiere HA en cada extremo de malla, necesitaríamos dos extremos de malla en los que se debe ejecutar la configuración TITAN anterior.

Al configurar TITAN en la radio del vehículo, primero el vehículo necesita tener 2 radios. En el caso de que se produzca un error en el primario, el secundario asume el control de la comunicación. En este escenario, las radios del vehículo y el extremo de malla de la red de fluidez necesitan tener la configuración TITAN.

Escenario de prueba

Nuestra topología de red actual incluye siete radios. Dentro de esta configuración, las radios Mesh End tienen sus interfaces inalámbricas desactivadas. Su función se limita a servir como gateways, en lugar de funcionar como parte del sistema de radio Trackside. A la unidad de extremo de malla principal se le asigna la dirección IP 10.122.136.50 y a la unidad secundaria la dirección IP 10.122.136.47.

Tenemos 3 radios en tierra (10.122.136.9, 10.122.136.16 y 10.122.136.15). La radio en tierra con la dirección IP 10.122.136.9 está conectada por cable a la infraestructura de red principal. Esta radio pivotal también extiende un link de retorno a un par de radios de remolque con IP 10.122.136.15 y 10.122.136.16. Estos enlaces de red de retorno de infraestructura fija funcionan en la banda de frecuencia de 5240 MHz. Colectivamente, las tres radios proporcionan cobertura inalámbrica al vehículo móvil que funciona en una frecuencia de 5180 MHz con la dirección IP 10.122.136.13).

El vehículo móvil está equipado con dos radios con la dirección IP 10.122.136.13 como la principal y 10.122.136.14 como la secundaria. Ambas radios están interconectadas a través de un solo switch. La radio secundaria no se muestra aquí.

Fallo de fin de malla

Paso 1: Los extremos de malla primario y secundario están conectados a la red y están activos. Podemos ver la radio con el ID de malla inferior que actúa como extremo de malla.

Paso 2: Cuando se activa el primario, el extremo de malla secundario toma el control y actúa como el extremo de malla para toda la red. Tenga en cuenta que el extremo de malla principal fallido ahora no aparece en la lista de radios de infraestructura.

Paso 3: La radio principal fallida está de vuelta y en funcionamiento. Sin embargo, espera el retraso de la preferencia para conocer la topología de la red

Paso 4: Una vez que se alcanza el temporizador de prioridad, el ID de malla 5.246.226.200 asume el rol de primario y radio con ID de malla 5.246.227.8 nuevamente se convierte en el secundario.

Comprobación de la tolerancia a fallos en la radio del vehículo

En esta red de laboratorio, tenemos una red de fluidez con un vehículo conectado a la pista. El vehículo dispone de dos radios IP 10.122.136.13 - Malla ID 5.66.194.36 (P) y 10.122.136.14 - Malla ID 5.246.2.120 (S).

Paso 1: Las radios del vehículo primario y secundario están en línea. Podemos ver la radio con una ID de malla inferior que actúa como la radio principal y la otra como secundaria. En función de la calidad inalámbrica, tanto la radio principal como la secundaria pueden comunicarse con la radio de tierra. Pero toda la comunicación descendente a la red de a bordo siempre pasa por la radio principal. Con TITAN, la radio del vehículo secundario se convierte en Primaria durante el fallo a los 500 ms.

En esta captura de pantalla, el túnel MPLS se puede ver desde el extremo de malla hasta las radios del vehículo.

Paso 2: Cuando apagamos la radio primaria 10.122.136.13, ésta falla en la secundaria y ahora 10.122.136.14 se convierte en la primaria.

Paso 3: Fallo La radio principal de a bordo del vehículo está retroalimentada y en funcionamiento. Sin embargo, aunque esta radio se conecta a la red, espera el retraso de preferencia y no participa activamente en la red de fluidez.

Como se ve en esta captura de pantalla, 5.66.194.36 volvió a estar en línea, pero aún así, está actuando como secundario durante el retraso de la preferencia y 5.246.2.120 sigue gestionando la comunicación. El túnel MPLS también muestra que 5.246.2.120 se está comunicando con la radio de tierra.

Troubleshooting de TITAN 

• Durante la configuración de TITAN, todas las configuraciones deben ser idénticas en todas las radios requeridas.
• En función del tamaño de la implementación, es posible que sea necesario aumentar el retraso de la preferencia. Esto es para asegurar que cuando la unidad fallida entra en funcionamiento, no asuma la función demasiado pronto antes de aprender la topología.
• Configurar el tiempo de espera de falla rápido demasiado pequeño puede crear una red inestable. Se podría utilizar un valor de 150 ms en la mayoría de las implementaciones.