Resumen

  • La revisión 18 ordena las coincidencias desde dos etiquetas explícitas hasta default, pasando por combinaciones con any, una etiqueta, priority-tagged y untagged; además obliga a rechazar solapamientos dentro del mismo nivel.
  • La configuración aceptada prueba intención. Estado aplicado, deltas de contadores aislados, capturas antes y después de la reescritura, FIB o vínculo de servicio y recepción remota prueban hechos distintos.

Una trama entra con S-VLAN 10 y C-VLAN 21. Podría caber en una regla exacta de dos etiquetas, en 10/any, en una coincidencia exterior 10 y en el cajón default. Si el resultado dependiera del orden en que se crearon las subinterfaces, la configuración escondería una lotería operacional.

El borrador de NETMOD, revisión 18, elimina esa lotería. Primero están dos etiquetas explícitas o en rango. Segundo, una pareja con un lado explícito y el otro any. Tercero, una sola etiqueta exterior explícita. Luego vienen priority-tagged, untagged y default. Dos condiciones del mismo nivel que puedan capturar la misma trama no deben ser aceptadas.

La regla es valiosa porque limita la autoridad del clasificador. Permite anticipar qué entrada debe ganar. No permite saltar desde esa anticipación a la frase «el servicio está pasando tráfico».

El modelo mira dos etiquetas, no una pila infinita

La profundidad común de clasificación es dos. En la combinación definida, la etiqueta exterior es S-VLAN y la segunda C-VLAN. match-exact-tags decide si esas etiquetas deben agotar toda la cabecera 802.1Q. No cambia la precedencia. Sin esa hoja, etiquetas adicionales pueden existir, pero el modelo las considera carga opaca y no las usa para clasificar ni reescribir.

Por eso una prueba con 10/21 no cubre 10/21/300. Es necesario comparar ambos paquetes con exactitud activada y desactivada. La captura de entrada debe demostrar la pila real; la descripción del generador de tráfico no basta.

Default necesita el inventario de sus rivales

default significa que ninguna encapsulación más específica de las subinterfaces pares tomó la trama. Su causa está distribuida en todo el conjunto. Para demostrarla hacen falta la configuración completa y evidencia negativa en cada candidato específico.

También hay que separar priority-tagged de untagged. La primera conserva una etiqueta 802.1Q; la segunda carece de ella. Si el ensayo no conserva los bytes de entrada, puede afirmar haber probado una rama que nunca ejercitó.

Elegir y entregar son dos verbos

Tras clasificar, el modelo flexible puede retirar o añadir hasta dos etiquetas externas. Traducir equivale a retirar y añadir. Sólo se pueden retirar etiquetas que formaron parte de la coincidencia. La reescritura puede ser simétrica o distinta por dirección.

La existencia de esos nodos no prueba su ejecución. Más aún, el propio borrador describe una subinterfaz del ejemplo L2VPN que clasifica tráfico y retira una etiqueta, pero no está vinculada a un servicio; el tráfico termina descartado. La configuración puede haber elegido correctamente un destino lógico que no conduce a ninguna parte.

Del recibo de gestión al recibo de camino

Primero se registra el módulo, la revisión y las funciones que el dispositivo anuncia. Después, la operación NETCONF o RESTCONF completa. Luego se compara intended con operational. RFC 8342 deja claro que la intención puede no aplicarse por falta de recursos u otras condiciones.

Para probar clasificación, se toman líneas base en el padre y en todas las subinterfaces, se envía una sola clase controlada y se miden los deltas. El borrador de extensiones de interfaz añade in-discard-unknown-encaps; RFC 8343 define contadores de paquetes, octetos y descartes. El contador de la subinterfaz esperada debería moverse solo; una prueba negativa debería aumentar el descarte de encapsulación desconocida y no aparecer en la salida.

Los contadores no contienen los bytes. Una captura en la entrada prueba etiquetas y EtherTypes; otra después de la reescritura prueba lo observado en ese punto. La correlación temporal y un identificador del flujo son indispensables para separar el ensayo del tráfico de fondo.

Una ruta activa conforme a RFC 8349 informa sobre el plano de control, no sobre la tabla de reenvío del ASIC. La cadena se completa con FIB y adyacencia específicas de la plataforma, captura en la salida prevista y observación remota. En L2VPN, el vínculo con el servicio y el circuito de acceso remoto sustituyen a la inferencia basada únicamente en la subinterfaz local.

La afirmación final debe conservar sus límites: este flujo, durante esta ventana, entró con esta pila, fue contado aquí, salió con estos bytes y apareció en este extremo. La claridad del modelo hace auditable esa afirmación; no la concede.

Fuentes primarias

El conjunto primario cerrado reúne las dos representaciones publicadas de la revisión 18, su ficha e historial en Datatracker, las dos representaciones del borrador complementario de extensiones de interfaz y los RFC 6241, 7950, 7799, 8040, 8341, 8342, 8343 y 8349: https://www.ietf.org/archive/id/draft-ietf-netmod-sub-intf-vlan-model-18.txt; https://www.ietf.org/archive/id/draft-ietf-netmod-sub-intf-vlan-model-18.html; https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/; https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/history/; https://www.ietf.org/archive/id/draft-ietf-netmod-intf-ext-yang-19.txt; https://www.ietf.org/archive/id/draft-ietf-netmod-intf-ext-yang-19.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc7799.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8343.html; https://www.rfc-editor.org/rfc/rfc8349.html.