Resumo

  • O BGP normalmente lê o ASN local no AS_PATH como evidência de loop. allowas-in muda a decisão do receptor; as-override muda o caminho antes da decisão.
  • Ambos podem atender sites que compartilham ASN, mas não autenticam prefixos nem comprovam encaminhamento. Route Target, Site of Origin e autorização têm funções distintas.
  • Uma exceção verificável preserva os caminhos antes e depois, delimita vizinho, AFI/SAFI e ocorrências, valida controles de site e prefixo e segue a rota até FIB e tráfego.

A rejeição correta

Considere um exemplo didático, não um incidente. As filiais A e B usam o mesmo ASN do cliente atrás de uma rede de provedor. A anuncia um prefixo; o provedor o leva até B. O roteador de B encontra seu próprio ASN no AS_PATH e rejeita. A sessão está estabelecida e o PE tem a rota, mas a filial não a usa.

Esse resultado é a proteção normal. A RFC 4271 exclui do processo de decisão uma rota que contenha o ASN local e declara fora da especificação a operação configurada para aceitá-lo. O caminho sinaliza que a informação já atravessou aquele domínio de roteamento. RFC 4271

Há duas respostas comuns. O cliente pode tolerar um número limitado de ocorrências do próprio ASN na recepção, com allowas-in ou allow-own-as. Ou o provedor pode substituir as ocorrências do ASN do cliente antes de anunciar a rota a ele, com as-override.

Não são comandos equivalentes. O primeiro mantém o caminho e muda o veredito do receptor. O segundo muda a evidência para que o veredito padrão não seja acionado. Um coloca a exceção na borda do cliente; o outro entrega ao provedor a custódia do histórico.

AS_PATH não é assinatura

AS_PATH auxilia a prevenção de loops e a seleção, mas não assina o trajeto físico. A RFC 4272 explica que cada speaker verifica principalmente o próprio ASN, sem validar todas as transições alegadas, e que caminhos falsos ou encurtados podem alterar escolha e loop. Seu valor operacional exige cuidado justamente porque pode ser interpretado e modificado. RFC 4272

allowas-in altera a admissão. Implementações podem limitar ocorrências, vizinho, grupo, família, origem ou route-map. O FRRouting documenta várias opções. A RFC 7938 descreve a função como amplamente disponível, mas não padronizada, num Clos que reutiliza ASNs privados. A segurança daquele desenho depende da topologia; não estabelece um número universal. Documentação BGP do FRRouting, RFC 7938

as-override altera a saída. FRRouting e Junos documentam a troca das ocorrências iguais ao ASN do peer pelo ASN local do provedor. O Junos registra ainda que repetições criadas pelo prepend do cliente também são substituídas. O comprimento pode parecer igual, embora a identidade que explicava as posições tenha sido perdida. Documentação BGP do FRRouting, Junos as-override

Por isso a tela posterior à mudança não basta. É preciso conservar o anúncio original do CE, o recebimento pelo PE, a exportação prevista antes da mutação, a exportação real e a visão aceita no CE remoto. Sem essa cadeia, uma reescrita autorizada e uma perda acidental de histórico parecem iguais.

Associação, origem do site e autorização

Na RFC 4364, Route Target controla quais rotas VPN podem ser importadas. Site of Origin identifica o site de aprendizado e impede o retorno da rota a um CE daquele site, quando aplicado conforme o desenho. Autorização de prefixo responde a outra pergunta: aquela conexão tinha direito de originar a rede? RFC 4364

RT não substitui a evidência self-AS; ele pode distribuir corretamente uma rota que está circulando. SoO é mais próximo do problema do site, porém só funciona se as conexões relevantes o definirem e aplicarem sem desvio. Ele não autentica cliente nem prefixo.

A documentação atual do IOS XR alerta, no cenário L3VPN descrito, que AS override perde informação e pode provocar loops, usando SoO como compensação. É uma evidência específica daquele fluxo, não uma garantia universal. Documentação BGP do Cisco IOS XR

A RFC 9835 também modela separadamente as-override, allow-own-as, máximo de ocorrências e Site of Origin. Um YANG não garante semântica idêntica em todos os produtos, mas demonstra que são quatro controles diferentes. RFC 9835

A cadeia de custódia da rota

Comece no estado estrito: Adj-RIB-Out de A, Adj-RIB-In do PE, caminho no PE remoto antes da exportação e rota rejeitada em B com motivo self-AS. Num serviço VPN, registre RD e RT, sem chamá-los de prova de origem.

Na exceção receptora, leia a política efetiva após a herança: vizinho, AFI/SAFI, limite, possível regra origin-only e filtros. Uma rota de controle fora do conjunto deve continuar rejeitada. O escopo real é o compilado pelo equipamento.

Na reescrita emissora, compare cada item do AS_SEQUENCE antes e depois. Se o cliente fez prepend repetido, todas as correspondências podem mudar. Guarde o original fora do roteador mutável, porque o anúncio reescrito não restaura a identidade apagada.

Verifique separadamente autorização, RT, SoO e qualquer conexão paralela, refletor ou redistribuição que contorne o controle. A RFC 6368 lembra que remapeamento e aceitação do ASN próprio trazem desvantagens quando o cliente usa BGP para outras funções internas; o efeito pode ir além do PE–CE. RFC 6368

Aceitação não é entrega. Confirme Loc-RIB, resolução, FIB ou hardware e tráfego controlado nos dois sentidos. Um teste seguro de falha deve revelar reentrada sem criar circulação perigosa. A RFC 7705 mostra, em migração de ASN, que manipular histórico pode aceitar o que self-AS impediria. Não especifica as-override, mas mostra por que “a rota apareceu” não é sucesso suficiente. RFC 7705

O rollback precisa restaurar a propriedade anti-loop. O canário com ASN local volta a ser rejeitado onde previsto, e a conectividade autorizada, o FIB e os pacotes retornam ao estado desenhado. Remover uma linha sem provar isso é apenas uma ação de configuração.