El protocolo sin base de datos
Tres clases distintas de nada: ninguna base de datos a la que unirse, una base de datos que nadie implementa, y una tabla con las respuestas pero no con las entradas
Michel Wijnberg
Los dos últimos artículos trataban de unirse con cuidado a un protocolo de estado de enlace: entrar sin convertirse en un camino, salir sin dejar un fantasma. Ambos suponen que hay algo a lo que unirse.
Este trata de los casos en los que no lo hay, y no son todos el mismo caso. Tengo tres, y fallan de tres maneras genuinamente distintas.
Uno: no hay base de datos
EIGRP es un protocolo de vector distancia avanzado. Los vecinos intercambian información de alcanzabilidad y distancia; no mantienen una base de datos de estado de enlace compartida. No hay copia sincronizada que todos los routers sostengan, así que no hay nada con lo que sincronizarse. La jugada de unirse de los dos artículos anteriores no existe aquí, porque aquello a lo que uno se uniría nunca se construyó.
Lo que sí existe es la visión propia de cada router: sus vecinos, y su tabla de topología de
destinos con las distancias que ha calculado. Eso se lee por SNMP, de CISCO-EIGRP-MIB,
router a router, y el grafo de adyacencias se reensambla a partir de lo que cada router dice
sobre sus propios vecinos.
Reensamblado, no leído. Nadie en la red sostiene la imagen. Solo existe una vez que ha preguntado a todos y ha juntado las respuestas, lo cual es una posición epistémica distinta de leer una LSDB, y merece decirse con honestidad aunque el grafo resultante tenga un aspecto idéntico.
El vecino que no quiere decir quién es
Luego un problema específico, y es de los bonitos.
Una entrada de vecino EIGRP le da la dirección del vecino. Para IPv6 esa dirección es link-local, y una dirección link-local identifica una interfaz en un enlace. No identifica un dispositivo. Dos routers en extremos opuestos de la red pueden llevar la misma dirección link-local sin conflicto alguno, porque el ámbito es el enlace.
Así que la tabla de vecinos le dice que hay algo ahí enfrente y se niega a decirle qué.
La resolución llega de una capa completamente distinta: las adyacencias LLDP y CDP ya descubiertas para ese dispositivo, indexadas por interfaz. Cruce la interfaz del vecino EIGRP con el vecino L2 de esa misma interfaz y sabrá qué dispositivo está al otro extremo.
Lo que significa que una arista EIGRP en Osprey es, por debajo, dos observaciones independientes que coinciden: el protocolo de enrutamiento diciendo que existe una adyacencia, y la capa de enlace diciendo quién está al otro lado. Cuando faltan los datos L2, el vecino queda sin resolver. No se adivina a partir del direccionamiento, no se infiere del nombrado, no se empareja por subred. Una arista que no puede atribuirse a un dispositivo no llega a ser una arista.
Dos: la tabla tiene las respuestas pero no las entradas
La tabla de topología de EIGRP es donde vive la segunda clase de nada, y es la que produjo una negativa en el producto.
La tabla tiene doce columnas accesibles. Entre ellas llevan las distancias de DUAL: la distancia factible, la distancia calculada actual, la distancia que reportó un sucesor, más recuentos de sucesores y estado del siguiente salto. Eso basta para mostrarle lo que cada router cree en este momento, y el primer artículo de este blog muestra exactamente eso: el número propio de cada router, decreciendo a lo largo de una cadena.
No basta para calcular nada nuevo.
Para recalcular una métrica tras un cambio hipotético hacen falta las componentes de las que
se derivaron las distancias reportadas, y el estado de interfaz que hay detrás. Esas están
en el router: pídale a e-ams1-cr1 un show ip eigrp topology 10.64.0.0/15 y le imprime
ancho de banda mínimo, retardo total, fiabilidad, carga, MTU y cuenta de saltos para ese
prefijo, que es como sé que existen en lugar de inferirlo.
No están en la tabla MIB que se está leyendo. Las doce columnas llevan lo que DUAL decidió. El router se queda con aquello a partir de lo cual DUAL lo decidió, y no lo publica aquí.
Así que Osprey se niega. Pídale que simule un fallo en un dominio EIGRP y declina proyectar una cadena nueva, y dice por qué: no puede predecir la reconvergencia de DUAL, porque las tablas que lee llevan las distancias y no las componentes de métrica que una recomputación necesita.
Dos cosas de esa negativa importan más que la negativa en sí.
Está acotada a lo que leemos, no al protocolo. El mensaje está redactado para decir que esto es un techo de recolección de datos, no una propiedad de EIGRP, porque un futuro enriquecedor que leyera las componentes de otro sitio lo levantaría. Un producto que dice “EIGRP no se puede simular” le está diciendo calladamente que no vuelva a preguntar, que es una afirmación distinta y mucho peor que “ahora mismo no recojo las entradas”.
Es precisa sobre cuándo se dispara. Si el cambio simulado es una eliminación pura, y lo eliminado demostrablemente no está en la cadena observada, la cadena real se sigue mostrando, con una nota diciendo que el fallo no la toca. Quitar capacidad en otro sitio no puede mejorar un camino de vector distancia que no la estaba usando. Pero un cambio de coste o un enlace nuevo pueden atraer un camino desde cualquier parte, así que esos siempre cuentan como que la tocan. El motor se niega donde tiene que negarse, no categóricamente, y esa diferencia es todo el valor de la negativa.
Tres: la base de datos existe en el estándar y en ningún otro sitio
La tercera clase de nada es la más frustrante, porque no es el bug de nadie.
IS-IS tiene una MIB estándar: RFC 4444, en .1.3.6.1.2.1.138. El descubrimiento SNMP de
Osprey sondea ese árbol primero, y solo entonces recurre al árbol de Cisco en
.1.3.6.1.4.1.9.10.118. Los dos conjuntos de OID comparten una disposición de columnas
relativa a la base y difieren solo donde las MIB difieren de verdad, que es un
desplazamiento de columna de circuito; las columnas de adyacencia son idénticas. El diseño
es deliberadamente neutral respecto al fabricante.
La ruta estándar nunca se ha demostrado contra hardware real.
No porque esté sin probar en el sentido unitario: tiene pruebas. Sino porque todos los
dispositivos que podemos alcanzar implementan solo el árbol de Cisco. Sondee un router del
laboratorio pidiendo el árbol estándar .138 y devuelve No Such Object. La ruta de código
neutral la ejercitan los fixtures y nada más, y prefiero escribir esta frase a dejar que
alguien la descubra.
Luego Arista lo empeoró, de forma instructiva. Sondeando vEOS-lab 4.29.2F en el pod de
servicios: el árbol estándar .138 devuelve No Such Object, y el árbol de Cisco
.9.10.118 también. Ninguno. El dispositivo habla IS-IS perfectamente bien y no hay
árbol SNMP alguno al que preguntarle por ello.
El mismo agente sirve OSPF-MIB sin problema, y LLDP-MIB, y registra el árbol de OSPF dinámicamente en cuanto OSPF está configurado. Así que la respuesta honesta para esos nodos no es “falló el descubrimiento de IS-IS” y desde luego no es una topología vacía. Es a este dispositivo no se le puede hacer esta pregunta, y en consecuencia las hojas del pod se descubren por OSPF.
No voy a convertir eso en una afirmación sobre el mercado, porque dos fabricantes no son una encuesta. Lo que sí puedo decir está acotado y sigue siendo útil: en todos los dispositivos que hemos podido probar, la MIB estándar no estaba implementada, y la MIB empresarial de Cisco era el único árbol que exponía los datos. Un estándar que nada de lo que alcanzamos implementa no es un estándar sobre el que construir una promesa.
El menú es la versión honesta de este artículo. Cuatro informes no se pueden abrir aquí porque leen una base de datos que no existe, y cada entrada en gris lleva su propio motivo al pasar el ratón, en vez de abrirse sobre una tabla vacía. EIGRP recibe su propia entrada, porque lo que puede responder es otra pregunta.
Tres clases de nada
Póngalas una al lado de la otra, porque un producto que las trata igual está mintiendo sobre al menos dos:
| Qué falta | La tentación | Qué hace en su lugar |
|---|---|---|
| ninguna base de datos a la que unirse | inventar una fuente de topología | reconstruir desde la visión propia de cada router, y etiquetarlo |
| las entradas, no las respuestas | suponer ancho de banda y retardo por defecto | negarse a simular, y nombrar el techo como nuestro |
| la MIB misma | devolver una topología vacía | decir que a este dispositivo no se le puede preguntar, y usar el árbol que sí sirve |
Lea la columna del medio. Cada una de ellas produce una pantalla que se parece exactamente a la pantalla que obtiene cuando los datos estaban realmente ahí. Ese es todo el problema de rellenar huecos: la salida no tiene manera de decirle qué partes de ella fueron observadas.
La idea
Los dos primeros artículos de esta serie iban sobre ser un invitado cuidadoso en el protocolo de otro. Este va sobre las habitaciones en las que no le dejan entrar.
Ser un buen invitado ahí significa otra cosa: no encontrar una manera de entrar, sino decir con precisión qué puerta estaba cerrada. Una arista EIGRP sin resolver, una simulación que declina, un dispositivo al que no se le puede preguntar. Tres negativas, cada una nombrando su propia causa, ninguna disfrazada de respuesta.
Siguiente, y última de esta serie: la única fuente que viene a usted en lugar de esperar a que le pregunten, y las dos maneras en que eso cambia lo que puede creer. Push, no poll.