Resumo

  • 0.0.0.0/0 e ::/0 não fixam bits de destino, mas correspondem a todo endereço que sobra depois da escolha por longest prefix. O alcance efetivo muda com as rotas mais específicas, mesmo quando a default não muda.
  • Originar, exportar, receber, aceitar, selecionar, instalar e entregar são estados diferentes. Session Established e FIB programado provam decisões locais, não a capacidade do neighbor de levar cada pacote adiante.
  • A delegação de último recurso deve existir apenas para a relação certa, usar condições próximas da promessa comercial, preservar rejeição local, medir canaries que realmente usam /0 e testar withdrawal, failover e rollback.

Considere AS 64580, uma rede que prefere não carregar full table. Seu provider AS 64520 envia alguns prefixos regionais e uma IPv4 default. Às 09h41, AS 64520 perde o transporte que o ligava ao principal upstream. O enlace com o customer permanece ativo, o peer EBGP continua Established e algumas rotas regionais sobrevivem por outro caminho.

O anúncio de 0.0.0.0/0 era incondicional. Por isso o provider continua enviando a rota, o customer continua escolhendo o mesmo next hop e o hardware mantém a entrada. Probes para o loopback do provider, um DNS regional e dois serviços cobertos por more-specifics respondem. Destinos que dependem da default entram no provider e encontram o egress ausente.

O incidente é sintético. A cadeia é realista e não exige uma mensagem BGP inválida. O control channel entre dois speakers pode permanecer saudável enquanto uma dependência distante falha. O UPDATE comprova que /0 foi anunciado; não comprova que o serviço resumido pelo anúncio ainda existe.

A autorização cobre um conjunto residual, não uma lista

RFC 1812 determina que o forwarding escolha, entre as rotas compatíveis, o prefixo mais longo. Assim, /24 vence /0 para seu bloco. /0 só participa quando não há resposta mais específica disponível para aquele destino.

Como o comprimento é zero, 0.0.0.0/0 combina com qualquer IPv4 e ::/0 com qualquer IPv6. Mas a população de pacotes que efetivamente usa a rota é móvel. Quando 198.51.100.0/24 aparece, aquele bloco sai do domínio da default. Quando o /24 é retirado, ele volta sem que /0 receba novo UPDATE.

Essa é a peculiaridade de autoridade. O anunciante publica um objeto mínimo. O receptor define seu alcance prático pela quantidade e qualidade das outras rotas na tabela. A mesma default pode passar a controlar muito mais tráfego durante uma retirada de specifics, mesmo com os mesmos atributos e o mesmo uptime.

RFC 4098 diferencia default route, default-free routing table e full default-free table. Receber só /0 reduz memória e trabalho de policy, mas concentra no provider a decisão sobre o conjunto residual. Receber full table aumenta visibilidade e decisão local, com outro custo operacional. Misturar default e routes selecionadas cria uma terceira fronteira. Nenhuma configuração deve ser descrita como se trouxesse as mesmas provas.

O anúncio interdomínio precisa ser deliberado

RFC 4632 chama 0.0.0.0/0 de prefixo default degenerado e exige que implementações o aceitem. Para evitar anúncios acidentais entre domínios, determina também que a rota só seja anunciada quando explicitamente configurada, nunca como opção implícita sem configuração.

RFC 7454 completa a regra com o contexto de relação. Fora de cenários específicos customer/provider, normalmente não se pretende aceitar ou anunciar 0.0.0.0/0 e ::/0; recomenda-se filtrar. O mesmo documento reconhece a opção legítima de um customer pedir somente default ao provider.

Não há contradição. A rota é válida, útil e bilateral. Permissão para um customer não autoriza propagação a peer, upstream, route server ou todos os tenants de um perfil compartilhado. IPv4 e IPv6 precisam de decisões separadas. VRFs também.

O provider limita export ao neighbor aprovado. O customer limita import a exact /0 vindo do papel autorizado. Os dois controles preservam autonomia: erro de uma organização encontra uma fronteira na outra.

RFC 8212 remove outra forma de permissão silenciosa ao exigir policy para propagação EBGP. Porém uma policy explícita ainda pode estar errada. Pode abranger peer-group indevido, liberar família errada ou depender de health check sem relação com o serviço. Presença de configuração não é evidência de sentido correto.

“Temos default” apaga sete fronteiras

Primeiro o anunciante cria uma candidate route, sintética, static, generated ou aprendida. Depois export policy decide se ela sai para aquele neighbor. O receptor recebe o UPDATE, aplica import policy, compara alternativas, seleciona uma rota na RIB e programa o next hop na FIB. Só então o pacote tenta atravessar o neighbor.

Cada passagem pode divergir. A candidate existe e é filtrada. O UPDATE chega e é rejeitado. A route é aceita e perde por LOCAL_PREF. A RIB muda e o hardware atrasa. A FIB aponta corretamente para uma interface ativa, mas o provider não tem caminho posterior.

AS_PATH pertence ao anúncio /0; não enumera paths reais para todos os destinos residuais. NEXT_HOP informa a próxima decisão local; sua resolução não garante entrega depois do primeiro salto. Preference escolhe em qual promessa confiar primeiro, não mede se ela continua verdadeira.

RFC 4271 permite retirar /0 com UPDATE sem derrubar a session. Se apenas o último recurso perdeu validade, a resposta de menor impacto é withdraw daquela route. Dar clear no neighbor inteiro remove routes não relacionadas e destrói evidência útil.

O mesmo nome de feature cobre modelos distintos

A documentação atual do Cisco IOS define neighbor ... default-originate por neighbor e informa que o router local não precisa conter 0.0.0.0. No Nexus, a artificial default também não precisa estar na routing table nem ser criada no BGP RIB local. Route-map opcional pode condicionar a origem a outra route instalada.

FRRouting documenta que não anuncia 0.0.0.0/0 por default mesmo quando a route está na tabela. O operador habilita neighbor ... default-originate explicitamente e pode aplicar route-map.

Junos trabalha com active route e routing policy. Rotas static, aggregate e generated podem ser exportadas a BGP quando a policy permite. Exemplos condicionais conectam estado ativo e decisão de export.

A diferença altera o failover. Remover uma static /0 pode não afetar uma artificial default incondicional. Em outro desenho, a perda da generated route ativa é exatamente o gatilho de retirada. Copiar runbook entre vendors pela semelhança de comandos pode manter uma promessa órfã.

É preciso testar a release em execução: local RIB, BGP RIB, advertised-routes, visão do receiver. Mantendo customer session ativa, remover o suporte que deveria sustentar a route. Medir reevaluation, withdrawal, best-path alternativo, FIB e pacote. Repetir no retorno.

Um predicate é testemunha limitada

Conditional advertisement só melhora o desenho quando a condição representa o serviço prometido por /0.

Loopback alcançável prova um loopback. Interface up prova carrier local. Static ativa pode provar apenas configuração ou recursion. Contagem de full table prova quantidade, não o egress selecionado. BFD prova continuidade com um peer particular. Nenhuma dessas medidas cobre sozinha o conjunto residual inteiro.

O significado deve vir antes do sensor. Se a default promete trânsito público amplo, os canaries atravessam o mesmo egress dos customers, atingem redes independentes e observam mais de uma dependência. Se representa saída WAN privada, a prova deve permanecer nesse domínio. Não se usa nome comercial amplo para aumentar artificialmente o alcance de um teste estreito.

Combinar sinais cria decisão de risco. Exigir todos pode retirar o último path útil quando um target de monitoramento falha. Exigir apenas um pode manter blackhole porque uma pequena ilha responde. Quorum, hysteresis, hold-down e recovery threshold distribuem custo entre retirada precoce e tardia.

Registrar cada entrada, o resultado combinado e os tempos: predicate false, route withdrawal, alternate selection, hardware update e packet recovery. Um snapshot depois da normalização não reconstrói o dano.

More-specifics escondem a verdade em duas direções

Os probes do exemplo passaram porque seus destinos tinham routes mais específicas. Não testaram a default quebrada. Um conjunto de monitoramento concentrado em serviços regionais ou grandes plataformas pode produzir verde enquanto a maioria do tráfego residual falha.

O inverso também acontece. Uma default saudável não salva destino coberto por /24 quebrado, pois longest match escolhe a route específica primeiro. Specific stale, next hop inválido ou leak pode derrubar um serviço isolado enquanto /0 funciona para o restante.

Cada canary deve registrar prefixo vencedor, route na RIB, next hop na FIB e egress. Sem essa atribuição, sucesso de aplicação não revela qual policy foi validada. Quando specific aparece ou desaparece, o probe muda de classe mesmo sem mudança na default.

Duas defaults também não provam dois destinos independentes. Sessions em routers diferentes podem compartilhar fibra metropolitana, trânsito superior, route controller ou targets de saúde. Desligar uma session prova session failover; não prova o cenário em que ambas sobrevivem e o upstream comum falha.

Leak de /0 entrega tudo o que o receptor não conhece

Aceitar default da relação errada transfere ao neighbor todo destino sem solução mais específica. Em core com full table o residual pode ser pequeno. Em stub customer pode ser quase todo tráfego externo.

Export filter lista apenas customers autorizados e exclui peers, providers, route servers e tenants alheios. Import filter aceita exact zero-length prefix somente do neighbor correto, no AFI/SAFI e VRF corretos. Peer-group inheritance e automação dual-stack exigem readback por destino.

Configuração mostra intenção. Adj-RIB-Out mostra o que o speaker enviou. Adj-RIB-In e accepted view do receptor separam chegada e uso. Collector público pode encontrar escape posterior, mas não observa todas as relações. Ausência no collector não prova ausência total de leak.

O ledger começa na promessa e termina no pacote

Para cada relação default, escrever o serviço: Internet público, serviços externos selecionados, saída privada ou fallback temporário. Nomear advertiser, receiver, role, família, VRF, approval owner e withdrawal owner.

Guardar generation mode, predicate, inputs, quorum, timers, hysteresis e ação de falha. Em runtime, preservar candidate, post-policy advertisement, pre-policy recebido, accepted route, selection reason, recursion, hardware FIB e alternativas.

Canaries partem do receptor, onde confiança vira forwarding. Alguns destinos devem depender somente de /0; outros devem ter more-specific intencional para testar a fronteira. Targets precisam de diversidade real e resultado deve incluir egress.

O drill mantém customer session e remove o upstream que sustenta a promessa. Mede separadamente condition failure, withdrawal, alternate RIB, FIB e recuperação. Sem alternativa, prova que o receptor para de enviar ao caminho morto.

Rollback restaura generation, condition, timers, neighbor scope, attributes, import preference e monitoramento. Só termina quando estado observado e pacotes voltam ao contrato anterior.

Coordenação mínima exige saída local forte

A default é uma forma eficiente de compartilhar pouca informação. O provider resume, o customer escolhe localmente. Nenhuma autoridade central precisa ordenar cada destino, e as duas redes mantêm decisões próprias.

Justamente por dizer pouco, o anúncio não pode receber interpretação ilimitada. O rótulo provider não certifica data plane. UPDATE não certifica SLA. Aceitação inicial não remove o direito futuro de rejeitar ou mudar preference.

Running-Code Primacy organiza as provas: contrato mostra expectativa, configuração mostra intenção, UPDATE mostra envio, RIB/FIB mostram ação local e packet mostra resultado. Cada camada é necessária; nenhuma substitui a próxima.