OSPF, El camino hacia Meraki

Construir redes de capa 3 resistentes y escalables ahora es mucho más fácil.

Cuando los paquetes necesitan abandonar su propia subred para encontrar su destino, necesitan un mapa que les muestre el camino. Estas rutas pueden definirse manualmente utilizando una ruta estática que funciona muy bien hasta que un enrutador de destino definido manualmente no esté disponible, momento en el cual el flujo de tráfico cae. Los protocolos de enrutamiento dinámico abordan esta falla obvia al aprender automáticamente cómo llegar a destinos conocidos, y el más popular de estos se conoce como OSPF (Open Shortest Path First).

Como anunciamos en junio, OSPF se está implementando en nuestros conmutadores de Capa 3, por lo que ahora parece ser el momento perfecto para cubrir lo esencial de este poderoso protocolo de enrutamiento. Continuaremos explorando cómo Meraki, una vez más, ha eliminado la molestia de configurar y ejecutar un entorno de red complejo que comprende múltiples subredes.

El primer protocolo de enrutamiento dinámico popular utilizado en las redes de área local fue RIP (Protocolo de información de enrutamiento), que utilizó los criterios simples de conteo de saltos (cuántos enrutadores debo pasar para llegar a mi destino) para seleccionar una ruta, pero sufría de ineficiencias y problemas de escala. Se necesitaba una solución más inteligente, y OSPF se convirtió en esa solución. Veamos una revisión de alto nivel de los componentes fundamentales del protocolo OSPF.

Selección de ruta

En la década de 1950, un informático holandés llamado Dijkstra inventó un algoritmo que calcula el camino más corto entre cualquier número de nodos que se convierten en «vecinos» una vez que se completa un proceso de aprendizaje. Este algoritmo tiene muchos usos prácticos y se ha aplicado de varias maneras, incluidos los movimientos de robots, la planificación militar y el envío comercial. El beneficio clave es la capacidad de tener en cuenta una serie de criterios al determinar la ruta con el «costo» más bajo, por ejemplo, la velocidad de volar paquetes en un avión en comparación con el envío por barco de contenedores, el precio del combustible, el número de barcos que pueden pasar por las rutas de envío disponibles, etc.

El algoritmo Dijkstra se aplica bien al mundo de las redes, y por esta razón formó la base para la selección de rutas en OSPF cuando el protocolo surgió por primera vez a fines de la década de 1980. Las rutas a los destinos aprendidos se seleccionan en función del ancho de banda / tipo de enlace o se pueden seleccionar manualmente.

Estados de enlace y adyacencias

Cuando un enrutador (o conmutador de enrutamiento) habilita OSPF, envía un saludo en todas las interfaces con OSPF habilitado. Otros enrutadores cercanos recibirán estos y (siempre que estén configurados para llevarse bien) formarán una «adyacencia» con su nuevo vecino. Una vez que se establece esta adyacencia, los enrutadores intercambiarán anuncios de estado de enlace y aprenderán la topología de red común en la que se sientan. A partir de esto, pueden derivar una tabla de enrutamiento utilizando el algoritmo Dijkstra SPF, lo que permite una comunicación eficiente entre subredes.

Este enfoque de «estado de enlace» es un uso mucho más eficiente del ancho de banda de la red que RIP, donde las tablas de enrutamiento completas se inundan regularmente en toda la red. Con OSPF, que no sea un paquete regular de saludo (latido), solo los cambios en la disponibilidad de enrutadores (enlaces) desencadenarán una actualización de la base de datos de estado de enlace y la tabla de enrutamiento. Los temporizadores se implementan con la frecuencia con la que los enrutadores habilitados para OSPF envían un saludo, y también se puede configurar un temporizador inactivo, que muestra cuándo un enrutador debe considerarse fuera de servicio, lo que desencadena una repetición del algoritmo SPF.

Areas

Otra gran eficiencia de OSPF es su uso de áreas, esencialmente agrupaciones lógicas de enrutadores, cuyas rutas se pueden resumir antes de pasar a otras áreas. Un dominio OSPF, o sistema autónomo, siempre comienza con el Área 0, también conocida como el área troncal. En una LAN relativamente pequeña, el Área 0 puede ser todo lo que se requiere, pero a medida que una red crece, se pueden crear múltiples áreas alrededor de esta red troncal. La belleza de escalar a múltiples áreas es que las actualizaciones de estado de enlace solo necesitan proporcionar información relevante para su propia área, sin tener que conocer las rutas de todo el sistema autónomo, lo que ahorra ancho de banda y ciclos de CPU en los enrutadores. El tema de las áreas se vuelve complejo y hay varios tipos, pero esencialmente son la forma en que OSPF puede crecer a una escala considerable, potencialmente ejecutando una WAN privada global completa.

Implementando OSPF a la manera Meraki

Nuestros ingenieros y diseñadores de Interfaz de usuario (UI) se enorgullecen de la apariencia limpia y accesible del panel de Meraki. La incorporación de un protocolo complejo en una interfaz de usuario de este tipo no fue tarea fácil, y tardó un tiempo en hacerlo bien. La prioridad era proporcionar los controles que permitirían el enrutamiento dinámico de Meraki a Meraki, pero también de manera crucial, la capacidad de interactuar con enrutadores y conmutadores de enrutamiento de la familia tradicional de Cisco y otros.

Esta captura de pantalla captura todas las configuraciones de OSPF disponibles. Ahora que entendemos los fundamentos de OSPF, estos tendrán sentido:

Para nuestros lectores más expertos en OSPF, la implementación de Meraki se basa en OSPF v2 y admite los tipos de área Normal, Stub y Not-So-Stubby. Observe también la opción para la autenticación MD5, que permite a los enrutadores identificarse de forma segura entre sí antes de formar adyacencias.

Una vez que OSPF esté habilitado, el administrador de la red necesitará una forma de monitorear las cosas, por lo que hemos mejorado las herramientas de cambio en vivo que aparecen cuando el enrutamiento de Capa 3 está habilitado. En primer lugar, la tabla de enrutamiento ahora mostrará qué rutas se han aprendido a través de OSPF (en oposición a las definidas estáticamente), y la ID del enrutador de origen, un identificador único dentro de un sistema autónomo, y el interruptor del que se ha aprendido la ruta. Cuando ese interruptor sea Meraki, se mostrará como un hipervínculo, lo que permitirá al administrador saltar directamente a la vista de ese interruptor:

Finalmente, se pueden mostrar los vecinos OSPF. Tenga en cuenta la función de búsqueda que existe en todo el panel de Meraki y ayuda enormemente a localizar rápidamente un objeto deseado:

Esperamos con ansias permitir que nuestros clientes aumenten el tamaño de sus redes. Como siempre es el caso con el tablero de instrumentos Meraki, la apariencia evolucionará con el tiempo en respuesta a los comentarios que recibimos, en particular utilizando nuestra siempre popular caja Make-a-Wish.

Si desea analizar nuestra implementación de OSPF con otros, nuestra comunidad en línea de usuarios y entusiastas de Meraki es un gran lugar para probar.