Protocolo IS-IS: Combinando el Plano de Estado y el Vector de Ruta

Esta serie de lecciones continúa examinando los planos de control distribuidos, añadiendo tres protocolos de enrutamiento más a nuestro estudio. Dos de ellos son protocolos de estado de enlace, y el tercero es el único protocolo de vector de ruta ampliamente desplegado, el Border Gateway Protocol (BGP) v4.

En estas lecciones, prestaremos atención al porqué cada uno de estos protocolos está implementado de la manera en que lo está. Es muy fácil distraerse y perderse en los detalles más pequeños de cómo funcionan los protocolos, pero es mucho más importante recordar los problemas que estos protocolos fueron diseñados para resolver y el rango de soluciones posibles. Cada protocolo que estudiemos será una combinación de un conjunto moderadamente limitado de soluciones disponibles: hay muy pocas soluciones nuevas disponibles. Existen diferentes combinaciones de soluciones, implementadas a veces de maneras únicas para resolver conjuntos particulares de problemas.

Al estudiar estos principios de funcionamiento del protocolo, deberías intentar identificar las soluciones comunes que implementan. Luego, refleja estas soluciones de vuelta en el conjunto de problemas que cualquier plano de control distribuido debe resolver para mitigar los problemas en las redes del mundo real.

Breve historia de OSPF e IS-IS

El protocolo Intermediate System to Intermediate System (IS-IS) fue desarrollado en 1978.

Open Shortest Path First (OSPF) fue concebido originalmente como una alternativa a IS-IS, diseñada específicamente para interactuar con redes IPv4. En 1989, la primera especificación de OSPF fue publicada por la Internet Engineering Task Force, y OSPFv2, una especificación significativamente mejorada, fue publicada en 1998 como RFC2328. OSPF fue, sin duda, el protocolo más ampliamente utilizado, con implementaciones tempranas de IS-IS que prácticamente no se utilizaban en el mundo real. Hubo algunos argumentos a favor y en contra, y muchas funciones fueron “prestadas” de un protocolo a otro (en ambas direcciones).

En 1993, Novell, en ese momento un gran actor en el mundo de las tecnologías de red, usó el protocolo IS-IS como base para reemplazar su propio protocolo de enrutamiento Netware. El protocolo de capa de transporte de Novell, Internet Packet Exchange (IPX), funcionaba en una gran cantidad de dispositivos en ese momento, y la capacidad de usar un solo protocolo para enrutar múltiples protocolos de transporte fue una ventaja decisiva en el mercado de las redes (EIGRP, también puede enrutar IPX). Este protocolo de reemplazo se basó en IS-IS.

Para implementar el nuevo protocolo de Novell, muchos fabricantes simplemente reescribieron sus implementaciones de IS-IS, mejorándolas significativamente en el proceso. Esta reescritura hizo que IS-IS fuera atractivo para los grandes proveedores de servicios de Internet, por lo que cuando abandonaron el protocolo RIP, a menudo cambiaron a IS-IS en lugar de OSPF.

Protocolo Intermediate System to Intermediate System

En el protocolo Intermediate System to Intermediate System (IS-IS), un router se llama Sistema Intermedio (Intermediate System, IS), y un host se llama Sistema Final (End System, ES). El diseño original del conjunto era que cada dispositivo, no la interfaz, tuviera una sola dirección. Los servicios e interfaces en el dispositivo tendrían un Punto de Acceso al Servicio de Red (Network Service Access Point – NSAP), utilizado para dirigir el tráfico a un servicio o interfaz específico.

Por lo tanto, desde el punto de vista de IP, IS-IS fue originalmente diseñado dentro de un paradigma de enrutamiento de host. Los sistemas intermedios y finales se comunican directamente usando el protocolo End System to Intermediate System (ES-IS), permitiendo que IS-IS descubra los servicios disponibles en cualquier sistema final conectado, así como mapear las direcciones de interfaz de nivel inferior a las direcciones de dispositivo de nivel superior.

Otro aspecto interesante del diseño de IS-IS es que funciona en la capa de enlace. No tenía mucho sentido para los diseñadores del protocolo ejecutar el plano de control para proporcionar la disponibilidad del sistema de transporte a través del propio sistema de transporte. Los routers no reenviarían los paquetes IS-IS, ya que son paralelos a IP en la pila de protocolos y se transmiten a través de direcciones de enlace locales. Cuando se diseñó IS-IS, la velocidad de la mayoría de los enlaces era muy baja, por lo que la encapsulación adicional también se consideraba derrochadora.

Los enlaces también fallaban bastante a menudo, perdiendo y corrompiendo paquetes. Por lo tanto, el protocolo fue diseñado para resistir los errores de transmisión y la pérdida de paquetes.

Direccionamiento OSI

Como IS-IS fue diseñado para un conjunto diferente de protocolos de transporte, no utiliza direcciones de Protocolo de Internet (IP) para identificar dispositivos. En cambio, utiliza la dirección de Interconexión de Sistemas Abiertos (OSI) para identificar tanto los sistemas intermedios como los finales. El esquema de direccionamiento OSI es algo complejo, incluyendo identificadores para la autoridad que asigna el espacio de direcciones, un identificador de dominio de dos partes, un identificador de área, un identificador de sistema y un selector de servicios (N-selector). Muchas de estas partes de la dirección OSI tienen longitud variable, lo que dificulta aún más la comprensión del sistema. Sin embargo, en el mundo IP, solo se utilizan tres partes de este espacio de direcciones.

1. Authority Format Identifier (AFI), Initial Domain Identifier (IDI), High-Order Domain Specific Part (HO-DSP) y el área, donde todo se maneja como un solo campo.
2. El identificador de sistema todavía se considera el identificador de sistema.
3. El N Selector, o NSAP, generalmente se ignora (aunque hay un identificador de interfaz que es similar a un NSAP usado en algunas situaciones específicas).

Por lo tanto, las direcciones del sistema intermedio generalmente toman la forma que se muestra en la Figura 1.

En la Figura 1:

• El punto de división entre el identificador del sistema y el resto de la dirección está en el sexto octeto o si cuentas doce dígitos hexadecimales desde el lado derecho. Todo lo que está a la izquierda del sexto octeto se considera parte de la dirección del área.
• Si se incluye el N-selector, este es un octeto o dos dígitos hexadecimales a la derecha del identificador del sistema. Por ejemplo, si se incluyera el N-selector para la dirección A, podría ser 49.0011.2222.0000.0000.000A.00.
• Si se incluye un N-selector en la dirección, debes omitir el N-selector al contar más de seis octetos para encontrar el comienzo de la dirección del área.
• A y B están en el mismo dominio de inundación de reenvío, porque tienen los mismos dígitos desde el séptimo octeto hasta el octeto más a la izquierda en la dirección.
• C y D están en el mismo dominio de inundación (flooding).
• A y D representan sistemas diferentes, aunque su identificador de sistema es el mismo. Sin embargo, este tipo de direccionamiento puede ser confuso y, por lo tanto, no se utiliza en implementaciones reales de IS-IS (al menos por administradores de sistemas considerados).

Podrías considerar este esquema de direccionamiento más complejo que IP, incluso si trabajas regularmente con IS-IS como protocolo de enrutamiento. Sin embargo, hay una gran ventaja en usar un esquema de direccionamiento diferente al que se utiliza en la capa de transporte en la red. Es mucho más fácil distinguir los tipos de dispositivos en la red y es mucho más fácil separar los nodos de los destinatarios si se piensa en el algoritmo de ruta más corta de Dijkstra (SPF).

Agrupación de Datos en IS-IS

IS-IS utiliza un mecanismo bastante interesante para agrupar datos para la transmisión entre sistemas intermedios. Cada IS genera tres tipos de paquetes:

• Paquetes Hello
• Paquetes con números de secuencia (PSNP y CSNP)
• Un solo paquete de estado de enlace (LSP)

Un solo LSP contiene toda la información sobre la propia IS, cualquier sistema intermedio accesible y cualquier destinatario accesible conectado a la IS. Este único LSP se formatea en Type Length Vectors (TLV), que contienen varios bits de información. Algunos de los TLV más comunes incluyen lo siguiente:

• Tipos 2 y 22: Alcance a otro sistema intermedio
• Tipos 128, 135 y 235: Alcance al destino IPv4
• Tipos 236 y 237: Alcance al destinatario IPv6

Hay varios tipos porque, IS-IS originalmente admitía métricas de 6 bits (la mayoría de los procesadores en el momento de la aparición del protocolo solo podían almacenar 8 bits a la vez, y dos bits fueron “robados” del tamaño del campo para llevar información sobre si una ruta era interna o externa, y otra información). Con el tiempo, a medida que aumentó la velocidad de los enlaces, se introdujeron otras longitudes métricas, incluyendo métricas de 24 y 32 bits, para admitir métricas más amplias.

Un solo LSP, que lleva toda la información de alcance de IS, IPv4 e IPv6, y posiblemente etiquetas MPLS y otra información, no cabría en un solo paquete MTU. Para enviar realmente la información a través de la red, IS-IS divide el LSP en fragmentos. Cada fragmento se considera un objeto separado en el proceso de inundación. Si un solo fragmento cambia, solo el fragmento modificado se propaga a través de la red mediante inundación, no todo el LSP. Debido a este esquema, IS-IS es muy eficiente al inundar información sobre nueva topología y alcance sin usar más ancho de banda del mínimo requerido.

Detección de Vecinos y Topología

Aunque IS-IS fue diseñado originalmente para conocer la disponibilidad de la red a través del protocolo ES-IS, cuando IS-IS se usa para el enrutamiento IP, “actúa como los protocolos IP” y aprende sobre los destinos alcanzables a través de la configuración local de cada dispositivo y mediante la redistribución de otros protocolos de enrutamiento. Por lo tanto, IS-IS es un protocolo proactivo que aprende y anuncia el alcance sin esperar paquetes que se reenvíen a través de la red.

La formación de vecinos en IS-IS es bastante sencilla. La Figura 2 ilustra este proceso.

En la Figura 2:

• IS A envía un saludo hacia B. Este saludo contiene una lista de vecinos de los que se ha recibido un saludo, que estará vacía. El tiempo de espera (hold time) de B debe usarse para A y se agrega al máximo bloque de transmisión (MTU) de la interfaz local para el enlace. Los paquetes de saludo solo se complementan hasta que se completa el proceso de formación de adyacencia. No todos los paquetes de saludo se complementan con el MTU del enlace.
• IS B envía un saludo a A. Este saludo contiene una lista de vecinos de los que se ha recibido un saludo, que incluirá A. El tiempo de espera de A debe usarse para B. Se agrega al MTU de la interfaz local.
• Como A está en la lista de “vecinos escuchados” de B, A considerará a B y pasará a la siguiente etapa de la formación de vecinos.
• Tan pronto como A haya incluido a B en la lista de “vecinos escuchados” en al menos un saludo, B considerará a A y pasará a la siguiente etapa de formación de vecinos.
• B enviará una lista completa de todas las entradas que tiene en su tabla de topología local (B describe los LSP que tiene en su base de datos local). Esta lista se envía en un Complete Sequence Number Packet (CSNP).
• A verificará su tabla de topología local, comparándola con la lista completa enviada por B. Cualquier entrada en la tabla de topología (LSP) que no tenga, la solicitará a B utilizando un Partial Sequence Number Packet (PSNP).
• Cuando B recibe el PSNP, establece el indicador Send Route Message (SRM) para cualquier entrada en su tabla de topología local (LSP) solicitada por A.
• Más tarde, el proceso de inundación buscará en la tabla de topología local las entradas con el indicador SRM establecido. Rellenará estas entradas, sincronizando las bases de datos en A y B.

Nota: El proceso descrito aquí incluye cambios realizados en el RFC5303, que define un apretón de manos (handshake) de tres vías y la adición del saludo que se agregó a la mayoría de las implementaciones alrededor de 2005.

Establecer el indicador SRM marca la información para la inundación, pero ¿cómo ocurre realmente la inundación?

Inundación confiable

Para que el algoritmo SPF de Dijkstra (o cualquier otro algoritmo SPF) funcione correctamente, cada IS en el dominio de inundación debe compartir una base de datos sincronizada. Cualquier inconsistencia en la base de datos entre dos sistemas intermedios abre la posibilidad de bucles de enrutamiento. ¿Cómo garantiza IS-IS que los sistemas intermedios conectados tengan bases de datos sincronizadas? Esta lección describe el proceso para los enlaces punto a punto. Las modificaciones realizadas en el proceso para los dominios de inundación a través de enlaces de acceso múltiple (por ejemplo, Ethernet) se describirán más adelante.

IS-IS se basa en una serie de campos en el encabezado LSP para garantizar que dos sistemas intermedios tengan bases de datos sincronizadas. La Figura 3 ilustra estos campos.

En la Figura 3:

• La longitud del paquete (packet length) contiene la longitud total del paquete en octetos. Por ejemplo, si este campo contiene el valor 15, la longitud del paquete es de 15 octetos. El campo de longitud del paquete es de 2 octetos, por lo que puede describir un paquete de hasta 65 536 octetos, más que incluso los MTU de enlace más grandes.
• El campo de tiempo de vida restante (remaining lifetime) también es de dos octetos y contiene la cantidad de segundos durante los cuales este LSP es válido. Esto obliga a actualizar periódicamente la información transmitida en el LSP, lo cual es una consideración importante para las tecnologías de transmisión más antiguas, donde los bits pueden invertirse, los paquetes pueden truncarse o la información transmitida a través del enlace puede dañarse. La ventaja de un temporizador que cuenta hacia atrás en lugar de hacia arriba es que cada IS en la red puede determinar cuánto tiempo debe permanecer válida su información independientemente de cada otra IS. La desventaja es que no hay una forma clara de desactivar la funcionalidad descrita. Sin embargo, 65 536 segundos es mucho tiempo: 1092 minutos, o alrededor de 18 horas. Volver a cargar cada fragmento LSP en la red aproximadamente cada 18 horas crea una carga muy pequeña en el funcionamiento de la red.
• El LSP ID describe el LSP en sí. En realidad, este campo describe el fragmento, ya que contiene el identificador del sistema de origen, el identificador del pseudonodo (discutiremos la función de este identificador más adelante) y el número de LSP, o más bien, el número de fragmento de LSP. La información contenida en un solo fragmento LSP se considera “un bloque” en toda la red. Un fragmento LSP individual nunca se “refragmenta” por ninguna otra IS. Este campo generalmente es de 8 octetos.
• El número de secuencia (Sequence Number) describe la versión de este LSP. El número de secuencia garantiza que cada IS en la red tenga la misma información en su copia local de la tabla de topología. Esto también garantiza que un atacante (o una implementación “torcida”) no pueda reproducir información antigua para reemplazar la nueva.
• La suma de comprobación (Checksum) garantiza que la información transmitida en el fragmento LSP no se haya modificado durante la transmisión.

La inundación se describe en la Figura 4.

En la Figura 4:

• A está conectado a 2001:db8:3e8:100::/64. A crea un nuevo fragmento que describe este nuevo destino alcanzable.
• A establece el indicador SRM en este fragmento hacia B.
• El proceso de inundación en algún momento (generalmente una cuestión de milisegundos) verificará la tabla de topología y volverá a inundar todas las entradas con el indicador SRM establecido.
• Tan pronto como la nueva entrada se coloca en su tabla de topología, B creará un CSNP que describe toda su base de datos y lo enviará a A.
• Al recibir este CSNP, A borra su indicador SRM en dirección a B.
• B verifica la suma de comprobación y compara el fragmento recibido con las entradas existentes en su tabla de topología. Como no hay otra entrada que coincida con este sistema e identificador de fragmento, colocará el nuevo fragmento en su tabla de topología local. Dado que este es un nuevo fragmento, B iniciará el proceso de inundación en dirección a C.

¿Y qué pasa con la eliminación de información? Hay tres maneras de eliminar información del dominio de inundación de IS-IS:

• La IS saliente puede crear un nuevo fragmento sin la información correspondiente y con un número de secuencia más alto.
• Si todo el fragmento ya no contiene ninguna información válida, la IS saliente puede rellenar el fragmento con un tiempo de vida restante (lifetime) de 0 segundos. Esto hace que cada IS en el dominio de inundación vuelva a cargar el fragmento de edad cero y lo elimine de la consideración para futuros cálculos SPF.
• Si el temporizador de tiempo de vida en el fragmento caduca en cualquier IS, el fragmento se inunda con un tiempo de vida restante de edad cero. Cada IS que recibe este fragmento de edad cero verifica que esta sea la copia más reciente del fragmento (basado en el número de secuencia), establece el tiempo de vida restante de su copia local del fragmento en cero segundos y vuelve a cargar el fragmento. Esto se conoce como eliminación del fragmento de la red.

Cuando una IS envía un CNSP en respuesta a un fragmento recibido, en realidad está verificando toda la base de datos, no solo un fragmento recibido. Cada vez que un fragmento se inunda a través de la red, toda la base de datos se verifica entre cada par de sistemas intermedios.

Resumen de IS-IS

IS-IS puede describirse como:

• Uso de la inundación para sincronizar la base de datos en cada sistema intermedio en el dominio de inundación (protocolo de estado de enlace).
• Cálculo de rutas libres de bucles (loop-free) utilizando el algoritmo SPF de Dijkstra.
• Aprendizaje de destinos alcanzables a través de la configuración e información local (protocolo proactivo).
• Verificación de la conectividad bidireccional al formar vecinos al llevar una lista de “vecinos escuchados” en sus paquetes de saludo.
• Eliminación de información del dominio de inundación mediante una combinación de números de secuencia y campos de tiempo de vida (lifetime) restante en cada fragmento.
• Verificación del MTU de cada enlace complementando los paquetes de saludo intercambiados inicialmente.
• Verificación de la exactitud de la información en la base de datos sincronizada mediante sumas de comprobación, reinicios periódicos y descripciones de la base de datos intercambiadas por los sistemas intermedios.

IS-IS es un protocolo de enrutamiento ampliamente desplegado que ha demostrado su eficacia en una amplia gama de topologías de red y requisitos operativos.