Resumo

  • O RFC 5291 permite ao receptor enviar Outbound Route Filters tipados para o peer aplicar junto de sua política local de exportação, evitando updates que seriam descartados depois.
  • ADD, REMOVE e REMOVE-ALL alteram apenas estado fornecido pelo peer e limitado à sessão; PERMIT e DENY exprimem preferência. Nenhuma ação apaga filtros locais do emissor, que pode decidir não honrar o pedido.
  • IMMEDIATE aplica a mutação com reanúncio; DEFER apenas a armazena até um commit. A evidência percorre fonte, encoding, estado recebido, export local, Adj-RIB-Out, UPDATE e RIB receptor, e é refeita após cada sessão.

O primeiro relatório parece suficiente: a tabela do cliente cai de centenas de milhares de rotas para uma visão estreita; CPU e memória melhoram. A equipe escreve que o provedor já envia apenas o feed solicitado.

Um filtro inbound comum produz a mesma tela enquanto o provedor continua enviando tudo. O cliente provou sua recusa, não a economia do vizinho. ORF permite cortar o trabalho antes, mas exige observação dos dois lados para provar isso.

O pedido viaja no sentido oposto às rotas

No BGP normal, o emissor combina Loc-RIB e política outbound para formar um Adj-RIB-Out por peer. O receptor aplica sua política inbound. Cada rede mantém sua fronteira.

ORF acrescenta um sinal reverso e limitado. O receptor envia entradas que o emissor pode incorporar ao filtro destinado àquele receptor. As rotas continuam descendo do provedor ao cliente; a preferência por menos rotas sobe do cliente ao provedor.

O RFC 5291 estabelece composição, não substituição. ORFs recebidos atuam além dos filtros configurados localmente. O cliente pode pedir menos, mas não remover segurança, contrato ou reserva de informação do provedor. REMOVE-ALL limpa o ORF remoto especificado, não toda a policy outbound.

As entradas exprimem preferência local que o peer pode ou não honrar. Capability abre uma interface, não concede execução remota. O receptor preserva proteção inbound e verifica o feed real.

Capability é uma interseção tipada e direcional

O código 3 aparece no OPEN com AFI/SAFI, tipo ORF e direção Send/Receive. Não há um único botão “ORF suportado”.

Só a interseção exata vale. Se o cliente quer enviar Address Prefix ORF para IPv4 e o provedor só recebe esse tipo em IPv6, IPv4 não está coberto. Enviar não prova receber; uma família não prova outra.

A interseção muda o início do feed. Quando não vazia, o RFC 5291 recomenda que o emissor aguarde um Route Refresh qualificado: simples ou com entradas e IMMEDIATE. Assim o receptor instala a preferência antes da primeira tabela grande.

Sem interseção, BGP segue normalmente. Uma sessão Established pode esperar em IPv4 e anunciar em IPv6. O estado da sessão não revela direção, tipo nem primeiro commit.

Guarde os OPEN reais por epoch. Configuração é intenção; capability negociada é o contrato em execução.

A prefix-list local não é o estado do peer

Cada entrada contém AFI/SAFI, tipo, ação, match e valor específico. ADD instala; REMOVE apaga uma entrada; REMOVE-ALL esvazia o ORF. PERMIT pede passagem; DENY pede retenção.

O RFC 5292 define Address Prefix ORF com Sequence, Prefix, Length, Minlen e Maxlen. Ele expressa prefixo exato e intervalos de more-specifics. Sequence controla a ordem.

Arquivo editado, compilação local, bytes do Route Refresh e lista decodificada remotamente são quatro identidades. O gerador pode trocar sequência, perder deny, escolher AFI errado ou enviar versão antiga. Hash da fonte não prova o destino.

O canário inclui prefixo exato, more-specific dentro da faixa, um logo fora, deny explícito e rota bloqueada pela policy local mesmo quando ORF permite.

Com vários tipos não vazios, a rota atravessa todos; PERMIT combinado com DENY resulta em DENY. Mostrar só um ORF pode exagerar o feed efetivo.

DEFER escreve; IMMEDIATE muda o que aparece

As mutações usam Route Refresh com decisão transacional. IMMEDIATE processa e reanuncia rotas afetadas sob o novo estado. O emissor deve reenviar as afetadas e pode incluir outras.

DEFER guarda sem alterar imediatamente o feed. Um refresh simples posterior, ou ORF com IMMEDIATE, faz o commit. Quando policy local também muda e exige reanúncio total, usa-se DEFER seguido de refresh simples.

O intervalo permite preparar uma versão coerente. Também permite que ambos vejam entradas novas enquanto o Adj-RIB-Out antigo segue ativo.

Cada DEFER precisa de ID, hash esperado, dono, commit, prazo e rollback. Estado pendente além da janela é transação incompleta.

Refresh simples não limpa ORF; ele reanuncia aplicando o estado recebido. Enhanced Route Refresh delimita o fluxo, mas não substitui a mutação.

Remover o pedido não remove a recusa local

Retirar um DENY remoto pode ampliar o feed; remover a última entrada elimina o ORF. A expansão só chega ao limite permitido pela policy local e pela decisão do emissor.

Rollback é assimétrico. O cliente restaura, limpa ou deixa de negociar. Nada disso deve enfraquecer o export do provedor. Usar ORF do cliente como única barreira confunde eficiência com autorização.

O receptor também mantém seu filtro inbound. O peer pode ignorar, perder estado ou negociar outro tipo. Otimização não substitui admission control.

Um valor desconhecido pode retirar todo o ORF

Família ou tipo não negociado é ignorado. REMOVE de entrada inexistente também.

Já um campo com valor desconhecido num ORF selecionado exige a retirada de todo o ORF previamente recebido daquele tipo. Evita-se um filtro parcialmente entendido, mas o feed pode crescer até a fronteira local.

Teste essa falha em peer isolado. Preveja se mensagem, entrada ou ORF desaparecerá e confirme no Adj-RIB-Out; log de parser não prova a rota.

Frequência, quantidade e escopo precisam de limites. Receptor comprometido pode provocar cálculo e reanúncio; emissor pode fingir conformidade. Automação ilimitada cria superfície de exaustão.

A sessão é o prazo natural

ORF vive na sessão em que foi trocado. Quando ela termina, o estado fornecido pelo peer desaparece. Screenshot anterior ao reset não prova a nova epoch.

A sessão seguinte renegocia capabilities e espera, quando aplicável, o primeiro refresh qualificado. Corrida, mensagem inicial perdida ou interseção alterada muda o feed sem mudar o arquivo local.

Session epoch deve ligar OPEN, primeiro ORF ou refresh, entradas recebidas, ativação e primeiro Adj-RIB-Out. Rota antes do pedido esperado é anomalia.

Reset limpa estado, mas impacta tudo. Rollback normal é mutação inversa observada; reconnect só com reconstrução integral prevista.

O canário comprova economia nos dois lados

Comece com peer pequeno e uma família. Meça candidatos outbound, updates, entrada remota e descartes locais.

Depois da negociação, envie IMMEDIATE estreito antes do feed. O emissor confirma decodificação e interseção com export local. Adj-RIB-Out, wire e receptor provam que o excluído nunca foi enviado.

Versão dois usa DEFER: estado muda, feed não. Refresh simples faz commit e a delta é comparada. Teste REMOVE, REMOVE ausente, REMOVE-ALL e última entrada.

Por fim, reinicie para provar que estado antigo sumiu e foi reconstruído por capability e primeiro refresh. Repita por AFI/SAFI.

Aceitação não é “ORF enabled”. É o registro de trabalho evitado e autoridade preservada: quais updates não nasceram, quais regras locais recusaram divulgação, qual pedido causou a mudança e o que o receptor observou.

ORF concede o direito limitado de pedir que o vizinho diga menos. Não permite exigir mais nem apagar suas regras. A coordenação funciona porque a fronteira continua local.