Isolamento L2 BPDU — metodologia para o operador¶

Outras línguas: English · Português · Español

Status do escopo (pós-congelamento de escopo 2026-05-10) — Isolamento L2 BPDU per ADR 0009 é a camada 1 do stack de defesa em 5 camadas: - L2: segregação de VLAN por classificação 3-plane (ARCHITECTURE.md) - L3: fabric OOBI VXLAN imutável (ADR 0019) - L4: bridge de zonas de trust RELAY.Art (ADR 0020) - L5: bloqueio de produção DOM — chain DDPB 7-layer (ADR 0014)

Resumo¶

A bancada TLSStress.Art interconecta múltiplos segmentos L2. Sem configuração explícita, nossas pontes Linux e o trunk do Nexus 9000 propagariam (ou gerariam) frames BPDU do Spanning-Tree (STP). Dois modos de falha:

Um BPDU vazando para o uplink do cliente pode corromper a topologia STP do cliente, gerando ~30s de outage na rede dele.
Um loop BPDU dentro do laboratório satura a CPU das pontes e mata a stack inteira.

Este documento explica como o lab previne ambos (defesa em 3 camadas) e como o relatório de execução atesta o isolamento (Annex G camada 5).

Para o design completo, veja ADR 0009.

A ameaça é bidirecional¶

Direção	Origem	Por que importa
Entrada (cliente → lab)	Switches do próprio cliente	BPDU entrando nas nossas pontes e propagando = corrupção de topologia
Saída (lab → cliente)	Nexus 9000 gera BPDU a cada 2s; NGFW transparent forward; pontes Linux com STP geram	BPDU saindo do lab = outage no cliente causado por nós

A defesa cobre as duas direções em todo boundary.

Defesa em 3 camadas¶

Camada 1 — Pontes Linux¶

Toda ponte Linux (Multus, macvlan parents, bridges Docker em dev) DEVE ter:

stp_state = 0 na própria ponte (não participamos de STP)
bpdu_guard on em todas as portas (descarta BPDU entrando)
root_block on em todas as portas (recusa candidatura a root bridge)

Aplicado automaticamente pelo DaemonSet privilegiado k8s/dut/47-bpdu-guard-daemonset.yaml no boot do node. É idempotente e re-roda quando uma nova ponte é criada.

Camada 2 — Trunk Nexus 9000¶

Duas classes de porta:

Classe	Configuração	Por quê
Lab-interna (Nexus → pontes Linux)	`port type edge` + `bpduguard enable`	Detecta inconsistência se nossa config interna driftar (canário)
Uplink pro cliente (Nexus → switch do cliente)	`bpdufilter enable` + `bpduguard enable`	Bloqueio bidirecional silent + err-disable se algo chegar

A diferença crítica: bpdufilter enable (Cisco NX-OS) faz bloqueio bidirecional silent — Nexus para de mandar Hello E ignora qualquer BPDU entrando. Diferente de bpduguard, que só pega entrada e err-disable. O uplink quer ambos.

Aplicado via scripts/nexus/01-apply-tuning.nxos.

Camada 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 via ConfigMap k8s/dut/45-vyos-isp-router.yaml.

Annex G — atestação da 5ª camada¶

O Annex G ("air-gap attestation") agora atesta 5 camadas (era 4 antes do v4.3.1):

Físico (interfaces listadas, sem cabeamento inesperado)
VyOS BGP (default route blackhole, 0 peers externos)
NetworkPolicy (cada namespace de persona tem default-deny + country-allow)
DNS NXDOMAIN (resolvers públicos retornam NXDOMAIN para FQDNs de persona)
Isolamento L2 BPDU (esta camada)

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

Audita stp_state de cada ponte Linux + bpdu_guard de cada porta
Audita cada porta Nexus: port type + bpduguard + bpdufilter
Roda tcpdump 60s em any filtrando frames BPDU
Emite JSON consumido por dashboard/src/lib/preflight/airgap-checks.ts

Zero BPDU em 60s = camada 5 PASS. Qualquer outro valor = FAIL.

Workflow do operador¶

Após cada mudança de cabeamento¶

scripts/airgap-l2-verify.sh
# Saída esperada:
#   Camada 5 — Isolamento L2 BPDU: PASS
#   - Pontes auditadas: 7 (todas stp_state=0, todas portas com bpdu_guard)
#   - Portas Nexus auditadas: 49 (47 internas, 2 uplink, todas configuradas)
#   - Captura BPDU 60s: 0 pacotes observados

Se FAIL, o script mostra exatamente qual check quebrou.

Antes de cada execução de teste¶

O preflight do dashboard roda o mesmo script automaticamente. Em produção (AIRGAP_GATING=production, default), uma falha na camada 5 bloqueia o início do teste. Em dev (AIRGAP_GATING=observational), loga warning e continua.

Bypass emergencial (cuidado)¶

Se PRECISAR rodar antes de validar (cenário de demo em 5 minutos), defina AIRGAP_GATING=observational na UI antes de iniciar. O Annex G marca camada 5 como SKIPPED com flag vermelha. Não use isso na frente de cliente.

Referências¶

ADR 0009 (docs/ADR/0009-l2-bpdu-isolation.md)
Template Annex 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)