Resumo

  • O RFC 2260 propôs que uma empresa ligada a N provedores recebesse N prefixos e, em condições normais, anunciasse a cada ISP apenas o prefixo que ele próprio havia atribuído, preservando a agregação.
  • Na falha, o custo muda de lugar: injetar o prefixo do outro provedor acrescenta estado à zona sem rota default; usar EBGP não direto e encapsulamento leva estado e coordenação para as redes envolvidas; buscar caminhos melhores volta a exigir anúncios adicionais e limitados.
  • A especificação descreve estratégias, não resultados observados. Ela não prova que provedores aceitaram rotas, que o espaço era portável, que políticas convergiram, que a tabela global encolheu nem que houve alcance de ponta a ponta.

Vários provedores implicavam várias origens de endereço

Publicado em janeiro de 1998, o RFC 2260 é Informational. Não define um padrão da Internet e não relata um ensaio operacional. Parte de uma tensão: empresas buscavam múltiplos ISPs por confiabilidade, distribuição de carga e caminhos geográficos possivelmente melhores, mas uma rota permanente para cada empresa multihomed em todos os roteadores da zona sem default não oferecia uma escala adequada.

O desenho começa com endereços emprestados pelos provedores. Uma empresa conectada a N ISPs recebe um bloco de cada um. Dentro da rede, pode atribuir a um host o prefixo do ponto de interconexão mais próximo ou dar ao host endereços de mais de um prefixo. A escolha não é apenas administrativa. Ela influencia por qual provedor o tráfego de entrada tende a alcançar aquele host.

A agregação obtida dessa maneira cria dependência. Ao trocar de ISP, a empresa precisa renumerar a parte que usava o bloco desse provedor. Um endereço alocado por um ISP pode caber no agregado dele; isso não o transforma em endereço portável para uso depois do encerramento da relação. O RFC 2260 menciona que NAT poderia tratar aspectos da atribuição e da renumeração, mas deixa o uso de NAT em empresas multihomed fora de seu escopo.

A exceção de falha pagava pela calma do estado normal

No estado normal, o roteador de borda conectado ao ISP-A anuncia ao ISP-A somente o Pref-A, alocado por A. A borda ligada ao ISP-B faz o mesmo com Pref-B. Assim, cada rota pode permanecer coberta pelo agregado de seu provedor e não precisa circular como rota específica da empresa na zona sem default.

Quando a borda sobrevivente conclui que a conectividade pelo outro ISP caiu, a regra muda. Se o lado B falha, a borda A passa a anunciar também Pref-B ao ISP-A. Uma rota adicional e mais específica entra no sistema global durante a falha. Quando B volta e se estabiliza, o anúncio excepcional deve ser retirado.

Para decidir, o RFC 2260 sugere uma relação IBGP entre as bordas. Enquanto os conjuntos de destinos vistos pelos dois lados ainda têm interseção, A anuncia apenas Pref-A. Se a interseção fica vazia, A acrescenta Pref-B. Comparar grandes conjuntos pode custar caro; uma alternativa de implementação é vigiar um ou mais prefixos conhecidos do backbone de B e disparar a injeção quando esse sinal desaparece via IBGP.

Esse detector não observa todas as propriedades que um serviço exige. O desaparecimento do prefixo escolhido é um sinal local sobre uma visão de roteamento. O novo anúncio, por sua vez, apenas declara alcance. Outros provedores podem rejeitá-lo por comprimento de prefixo. O próprio RFC reconhece que o método pode produzir menos que conectividade integral em toda a Internet diante desses filtros.

Mesmo quando o anúncio é aceito, ainda faltam recibos para propagação, seleção como melhor caminho, encaminhamento, retorno e entrega à aplicação. A expectativa de que nem todas as empresas falhariam ao mesmo tempo sustentava a ideia de que a quantidade média de rotas extras seria uma fração do número total de empresas multihomed. Era uma hipótese de escala, não uma medição da tabela global.

A injeção automática também amplia mudanças. Uma falha empresarial pode exigir que a nova rota chegue a muitos roteadores da zona sem default. Se o enlace oscila, a rota excepcional precisa permanecer até que a conexão recuperada esteja estável; do contrário, a própria proteção cria flapping adicional.

Tirar o estado da tabela global o coloca em outro sistema

A alternativa mais ambiciosa do RFC 2260 usa EBGP não direto. A borda da empresa mantém uma sessão não só com o roteador do ISP diretamente conectado, mas também, através de múltiplos saltos, com um roteador no ISP ligado à outra borda empresarial. Cada prefixo continua sendo anunciado apenas ao ISP que o alocou. Tanto o ISP quanto a empresa preferem a rota aprendida pela sessão direta e mantêm a não direta como caminho de contingência.

O encaminhamento pelo caminho não direto depende de encapsulamento. Se o enlace empresarial de B cai, o tráfego para Pref-B ainda chega ao ISP-B. B o encapsula até a borda empresarial sobrevivente do lado A; ali, o pacote é desencapsulado e entregue à rede interna. Nesse arranjo, a falha não precisa gerar uma rota empresarial adicional na zona sem default e não enfrenta, da mesma forma, o filtro externo de uma rota mais específica.

O custo, porém, não desaparece. Passa a existir nas sessões EBGP de vários saltos, na preferência entre caminhos, nos pontos de túnel, na autenticação, na detecção de falha, na MTU e no percurso de retorno. A seção de segurança exige mecanismo apropriado de autenticação para esses pares BGP não adjacentes, mas deixa a segurança do IBGP e do EBGP de um salto fora do escopo.

Uma descrição técnica também não é consentimento operacional. O documento não mostra que duas empresas provedoras aceitaram o acordo, autorizaram anúncios, instalaram túneis, alinharam filtros ou sustentaram o serviço sob falha. A rota não direta é uma opção de arquitetura, não uma prova de execução.

Comprar um caminho melhor pode recomprar estado de rota

O EBGP não direto elimina a rota extra global, mas pode levar o tráfego por um caminho menos eficiente durante a falha. Há ainda uma ineficiência possível no estado normal: se cada borda anuncia somente o prefixo do ISP diretamente conectado, clientes de um ISP que tentem chegar a hosts numerados pelo prefixo do outro talvez não entrem pela borda mais conveniente.

A empresa pode melhorar o ingresso anunciando a um ISP prefixos atribuídos por outro. Mas a distribuição precisa ser cuidadosamente limitada; do contrário, a otimização acrescenta estado significativo à zona sem default. O RFC 2260 cita o atributo BGP Community como meio de restringir o alcance e propõe combinar anúncios limitados com EBGP não direto.

Essa combinação expõe a curva de custo. Mais visibilidade pode melhorar recuperação e escolha de entrada, mas enfraquece a agregação. Agregação rígida reduz a tabela global, mas cobra em dependência de endereço, coordenação, túneis ou caminhos mais longos.

O espaço independente de provedor desloca a conta novamente. A empresa usa um prefixo único sem vínculo topológico com os ISPs, mas sua rota não pode ser agregada sob nenhum deles. O RFC 2260 descreve um custo O(N) na zona sem default conforme cresce o número de empresas multihomed. Escolher o prefixo de um provedor e fazê-lo circular seletivamente pelos demais demanda agregação por procuração, mais coordenação entre ISPs e configuração mais complexa.

O RFC 2519 posteriormente explicou que a agregação reduz tabela, processamento e alcance de flaps e que rotas granulares podem ficar locais com no-export. O RFC 4116 classificou a abordagem baseada em endereços PA do RFC 2260 como uma forma sem carga global adicional em sua configuração básica, mas ressaltou que ela não resolve todas as motivações, em especial a sobrevivência de sessões de transporte. O RFC 8678 mostrou mais tarde que o multihoming PA também exige coordenar endereço de origem e saída. Esses documentos dão contexto; não provam adoção do RFC 2260.

Fontes e limites da evidência

As fontes oficiais abaixo sustentam o status, as estratégias e as comparações históricas. Não sustentam um deployment nomeado, uma rota aceita por determinado ISP, espaço portável, uma redução medida da tabela, alcance universal, continuidade de sessão ou resultado de negócio.