Skip to content

Aislamiento L2 BPDU — metodología para el operador

Otros idiomas: English · Português · Español

Estado del alcance (post-congelación de alcance 2026-05-10) — Aislamiento L2 BPDU per ADR 0009 es la capa 1 del stack de defensa en 5 capas: - L2: segregación de VLAN por clasificación 3-plane (ARCHITECTURE.md) - L3: fabric OOBI VXLAN inmutable (ADR 0019) - L4: bridge de zonas de trust RELAY.Art (ADR 0020) - L5: bloqueo de producción DOM — chain DDPB 7-layer (ADR 0014)

Resumen

El banco de pruebas TLSStress.Art interconecta múltiples segmentos L2. Sin configuración explícita, nuestros bridges Linux y el trunk del Nexus 9000 propagarían (o generarían) frames BPDU del Spanning-Tree (STP). Dos modos de falla:

  1. Un BPDU fugando hacia el uplink del cliente puede corromper la topología STP del cliente, causando ~30s de outage en su red.
  2. Un loop BPDU dentro del laboratorio satura la CPU de los bridges y mata todo el stack.

Este documento explica cómo el lab previene ambos (defensa de 3 capas) y cómo el reporte de ejecución certifica el aislamiento (Anexo G capa 5).

Para el diseño completo, ver ADR 0009.

La amenaza es bidireccional

Dirección Origen Por qué importa
Entrada (cliente → lab) Switches del propio cliente BPDU entrando en nuestros bridges y propagándose = corrupción de topología
Salida (lab → cliente) Nexus 9000 genera BPDU cada 2s; NGFW transparent forward; bridges Linux con STP generan BPDU saliendo del lab = outage en el cliente causado por nosotros

La defensa cubre ambas direcciones en cada boundary.

Defensa en 3 capas

Capa 1 — Bridges Linux

Todo bridge Linux (Multus, macvlan parents, bridges Docker en dev) DEBE tener:

  • stp_state = 0 en el propio bridge (no participamos de STP)
  • bpdu_guard on en cada puerto (descarta BPDU entrante)
  • root_block on en cada puerto (rechaza candidatura a root bridge)

Aplicado automáticamente por el DaemonSet privilegiado k8s/dut/47-bpdu-guard-daemonset.yaml al boot del nodo. Es idempotente y se re-ejecuta cuando se crea un nuevo bridge.

Capa 2 — Trunk Nexus 9000

Dos clases de puerto:

Clase Configuración Por qué
Lab-interno (Nexus → bridges Linux) port type edge + bpduguard enable Detecta inconsistencia si nuestra config interna driftea (canario)
Uplink al cliente (Nexus → switch del cliente) bpdufilter enable + bpduguard enable Bloqueo bidireccional silente + err-disable si algo llega

La distinción crítica: bpdufilter enable (Cisco NX-OS) hace bloqueo bidireccional silente — Nexus deja de enviar Hello E ignora cualquier BPDU entrante. Diferente de bpduguard, que solo captura entrada y err-disable. El uplink quiere ambos.

Aplicado vía scripts/nexus/01-apply-tuning.nxos.

Capa 3 — Pod VyOS

set interfaces bridge br0 stp false
set interfaces bridge br0 member interface eth1 bpdu-guard
set interfaces bridge br0 member interface eth1 root-guard

Aplicado vía ConfigMap k8s/dut/45-vyos-isp-router.yaml.

Anexo G — atestación de la 5ª capa

El Anexo G ("air-gap attestation") ahora certifica 5 capas (era 4 antes de v4.3.1):

  1. Físico (interfaces listadas, sin cableado inesperado)
  2. VyOS BGP (default route blackhole, 0 peers externos)
  3. NetworkPolicy (cada namespace de persona tiene default-deny + country-allow)
  4. DNS NXDOMAIN (resolvers públicos devuelven NXDOMAIN para FQDNs de persona)
  5. Aislamiento L2 BPDU (esta capa)

Capa 5 verificada por scripts/airgap-l2-verify.sh, que:

  1. Audita stp_state de cada bridge Linux + bpdu_guard por puerto
  2. Audita cada puerto Nexus: port type + bpduguard + bpdufilter
  3. Corre tcpdump de 60s en any filtrando frames BPDU
  4. Emite JSON consumido por dashboard/src/lib/preflight/airgap-checks.ts

Cero BPDU en 60s = capa 5 PASS. Cualquier otro valor = FAIL.

Workflow del operador

Después de cada cambio de cableado

scripts/airgap-l2-verify.sh
# Salida esperada:
#   Capa 5 — Aislamiento L2 BPDU: PASS
#   - Bridges auditados: 7 (todos stp_state=0, todos puertos con bpdu_guard)
#   - Puertos Nexus auditados: 49 (47 internos, 2 uplink, todos configurados)
#   - Captura BPDU 60s: 0 paquetes observados

Si FAIL, el script muestra exactamente qué chequeo falló.

Antes de cada ejecución de prueba

El preflight del dashboard ejecuta el mismo script automáticamente. En producción (AIRGAP_GATING=production, default), una falla en la capa 5 bloquea el inicio de la prueba. En dev (AIRGAP_GATING=observational), loguea warning y continúa.

Bypass de emergencia (cuidado)

Si DEBES ejecutar antes de validar (escenario de demo en 5 minutos), define AIRGAP_GATING=observational en la UI antes de lanzar. El Anexo G marca capa 5 como SKIPPED con bandera roja. No uses esto delante del cliente.

Referencias

  • ADR 0009 (docs/ADR/0009-l2-bpdu-isolation.md)
  • Template Anexo G (dashboard/templates/annex-g-airgap-attestation.md.tmpl)
  • Script verifier (scripts/airgap-l2-verify.sh)
  • DaemonSet (k8s/dut/47-bpdu-guard-daemonset.yaml)
  • Tuning Nexus (scripts/nexus/01-apply-tuning.nxos)
  • Config VyOS (k8s/dut/45-vyos-isp-router.yaml)