Resumen

  • Cada conjunto de LSP dispone de 256 números. RFC 5311 permite que una máquina origine más conjuntos con Additional System IDs únicos; sus Virtual IS son contenedores de capacidad, no routers independientes.
  • La aceptación exige más que recibir bytes: un LSP cero vivo, Alias TLV 24, áreas compatibles, enlaces sintéticos con costes distintos, contenido permitido, precedencia determinista y coherencia con OL del sistema original.

La alarma de inventario era correcta y estaba equivocada

El recolector encontró un system ID que no figuraba en el inventario de chasis. La alarma describía un hecho verdadero: había un origen adicional en la base de estado de enlace. La interpretación, sin embargo, era falsa: no se había instalado otro equipo.

Ese desacuerdo es la prueba de diseño que plantea RFC 5311. Un conjunto IS-IS tiene 256 números de LSP y el documento cita 1492 bytes como valor máximo de un LSP. A medida que crecen la ingeniería de tráfico, las capacidades y las topologías múltiples, un sistema puede quedarse sin espacio de publicación. Los identificadores adicionales abren conjuntos Extended LSP, cada uno representado como un Virtual IS.

El símbolo nuevo no cambia el propietario. No tiene alimentación, proceso de mantenimiento ni dominio de fallo propio. Si un lago de datos lo promueve a «router», acabará contando disponibilidad, responsabilidad y exposición sobre una unidad ficticia. El modelo debe conservar a la vez la identidad física, la identidad de capacidad y el estado topológico.

El cero no es un fragmento más

Los Extended LSP se inundan, actualizan, envejecen y purgan con las reglas ordinarias. La excepción operativa está en el número cero. Si no existe un Extended LSP cero con lifetime mayor que cero para el Additional System ID, ningún otro fragmento de ese conjunto puede procesarse.

Por tanto, los fragmentos restantes pueden seguir almacenados y ser criptográficamente auténticos, pero carecer de admisión vigente. El error más fácil consiste en consultar cada fila por separado y concluir que 1–255 siguen activos después de expirar el cero. La evidencia útil debe registrar el estado de cero en la misma generación de observación.

El cero incluye obligatoriamente IS Alias ID TLV 24, que enlaza el identificador adicional con el system ID normal del Originating System. También incluye Area Addresses que deben ser un subconjunto de las publicadas en el LSP cero normal; se prefiere identidad sintáctica. La ruta de autoridad es Virtual IS → cero vivo → alias → origen normal → nivel y área.

La unicidad tampoco es local al aparato. En nivel 1, el identificador adicional ha de ser único en toda el área; en nivel 2, en todo el dominio. Una automatización que valide sólo el archivo del equipo no ha demostrado que la identidad esté libre.

La asimetría de coste es parte de la compatibilidad

El conjunto original anuncia un vecino hacia cada Virtual IS con métrica cero. Con ello cumple la comprobación bidireccional y hace que alcanzar la identidad virtual cueste lo mismo que alcanzar a su propietario físico.

En sentido contrario, el conjunto Extended anuncia al Originating System con métrica no nula, preferiblemente MaxLinkMetric-1. Para cada topología presente en el espacio extendido deben existir los anuncios vecinos correspondientes en ambos lados.

No son lecturas duplicadas de un cable. Son enlaces sintéticos con tareas opuestas: el de coste cero incorpora capacidad al nodo real; el de coste alto impide que el hijo virtual se convierta en tránsito atractivo. Convertirlos en una arista no dirigida y «normalizada» borra la salvaguarda.

RFC 5311 obsoleta RFC 3786 precisamente porque restringe los contenidos de modo que no alteren el árbol SPF. Un router antiguo ve al Virtual IS detrás del origen y no aprende otros sistemas a través de él. Así, su SPF permanece coherente con el cálculo de un equipo que sí comprende la extensión.

Más espacio no significa permiso general

Los TLV 3, 4 y 5 están prohibidos en los Extended LSP. Un receptor que entiende la extensión debe ignorar esos TLV, debería informar del error y continúa tratando la información permitida. Esto exige conservar validación por campo: ni aceptar el TLV prohibido ni descartar sin matiz toda la procedencia.

La reachability de vecinos IS en un Extended LSP sólo puede señalar al Originating System. Los vecinos normales permanecen en el conjunto original. TLV 23 y MT TLV 223 pueden llevar atributos de un vecino, pero no fundan la relación. Si no existe TLV 22 o 222 para ese vecino en el conjunto originario, los atributos no autorizan a crear una adyacencia.

OL, ATT y P deben estar a cero en los LSP extendidos. ATT muestra la amenaza con claridad: un router heredado podría usar el Virtual IS como salida predeterminada hacia otra área, aunque el equipo físico no fuese attached. La identidad de capacidad nunca debe obtener una autoridad superior a la de su dueño.

Los prefijos convierten capacidad de base en trabajo de FIB

El estándar permite alojar información hoja en el conjunto Extended: reachability IP interna y externa, Extended IP, variantes multi-topology, IPv6 y MT IPv6. Si hay múltiples topologías, MT TLV 229 enumera todas las representadas por los anuncios hoja.

Mover un prefijo cambia la naturaleza operativa de la extensión. El receptor ya no consulta sólo metadatos; puede recalcular RIB y programar FIB. RFC 5311 advierte que esto puede aumentar la frecuencia de eventos de forwarding y recomienda mantener las hojas en el conjunto normal siempre que sea posible.

Una recepción verificable enlaza el prefijo con su fragmento, Additional System ID, cero vigente, MTID, OL del padre y generaciones de RIB y FIB. La cantidad total de LSP extendidos no revela cuál de ellos movió paquetes ni cuándo llegó esa consecuencia al hardware.

Un bit del padre puede inutilizar todos los hijos

El Virtual IS mantiene su propio bit OL en cero. Aun así, su usabilidad deriva del overload del sistema físico. Mientras el LSP normal no marca OL, la reachability del hijo coincide con la del padre. Cuando el padre sí lo marca, los routers antiguos dejan de poder alcanzar los Virtual IS asociados y los equipos modernos deben reproducir ese resultado.

La regla evita bucles cuando existen hojas en el espacio extendido. También demuestra por qué la fila virtual no es una unidad de salud. Puede mostrar lifetime positivo, alias correcto y OL cero al mismo tiempo que su propietario ha retirado efectivamente toda la familia.

Las alertas deben evaluar el conjunto compuesto: origen, alias, área, nivel, cero, enlaces y generación de overload. Separar el estado sólo porque los identificadores son distintos confunde normalización con realidad.

La precedencia forma parte del dato

Durante una migración, los atributos de vecino pueden aparecer en el espacio original y el extendido. Los valores no conflictivos se combinan. Ante un conflicto manda el Original LSP; si éste no ofrece valor, vence el Extended LSP con el Additional System ID numéricamente menor. Dentro del mismo contexto, TLV 22 supera a TLV 23 y TLV 222 supera a TLV 223 para el mismo MTID.

Publicar únicamente el valor ganador es una pérdida de evidencia. Deben conservarse todos los candidatos, LSP de origen, TLV, MTID, secuencia, lifetime y regla de selección. Sin esos elementos, un cambio legítimo de precedencia aparece como flapping sin causa.

Las extensiones futuras podrán ubicar nuevos TLV en los Extended LSP, pero un código asignado por IANA no demuestra que una flota antigua lo interprete. Hay que separar autorización del registro, capacidad de decodificación y despliegue efectivo.

El recibo operativo empieza por la máquina

Un recibo no secreto debería contener: Originating System y system ID normal; nivel y área; Additional System IDs y sus ámbitos de unicidad; secuencia, lifetime y purge de cada cero; Alias TLV 24; subconjunto de áreas; las dos aristas con sus costes; topologías; controles de TLV y bits; fragmentos hoja; candidatos y precedencia; OL del padre; generaciones RIB/FIB; pruebas con paquetes; y decisión de rollback.

Conservar esa cadena impide que una necesidad de capacidad se convierta en una ficción institucional. RFC 5311 crea más sobres para un único remitente. No crea más remitentes.

Sources