AS-override e allowas-in no BGP: diferença e quando usar

AS-override e allowas-in resolvem o mesmo sintoma: um cliente com o mesmo ASN em dois sites, ligados pela L3VPN do provedor, não aprende as rotas do outro site. A sessão BGP sobe, o PE anuncia o prefixo, e o CE simplesmente ignora. Não é bug. É a prevenção de loop do BGP funcionando como manda a regra.

A diferença entre os dois comandos é o lado que relaxa a regra. O as-override é configurado no PE, do provedor, e reescreve o AS_PATH antes de anunciar. O allowas-in é configurado no CE, do cliente, e aceita o próprio ASN no caminho. Este guia mostra o cenário, o AS_PATH em cada caso, a sintaxe em Cisco IOS, Huawei VRP e Junos, e os riscos de cada escolha.

Resposta rápida

Se você é o provedor e o cliente não mexe no roteador dele, use as-override no PE. Se o cliente administra o CE e prefere resolver do lado dele, use allowas-in no CE com o menor número possível, normalmente 1. Se o cliente pode usar um ASN privado diferente em cada site, essa é a saída mais limpa e dispensa os dois.

Prevenção de loop pelo AS_PATH

Cada roteador eBGP coloca o próprio ASN na frente do AS_PATH quando anuncia uma rota. O AS_PATH vira o histórico dos sistemas autônomos por onde o anúncio passou. Quando um roteador recebe uma rota e encontra o próprio ASN nesse histórico, conclui que o anúncio deu a volta e voltou para casa. A rota é descartada. É assim que o BGP evita loop entre sistemas autônomos sem precisar de nenhum outro mecanismo. Se isso ainda é novo, o guia sobre o que é BGP e como ele funciona explica a base.

Na internet essa regra é exatamente o que você quer. O problema aparece quando o mesmo ASN existe em dois lugares que não se falam diretamente. Para o CE2, um prefixo com 65001 no caminho parece o próprio anúncio voltando, mesmo tendo vindo de outro prédio, em outra cidade.

O cenário: mesmo ASN em dois sites pela L3VPN

O provedor usa o AS 64500 e entrega uma L3VPN para um cliente corporativo, na VRF CLIENTE-A. O cliente tem dois sites e usa o ASN privado 65001 nos dois, porque alguém configurou o primeiro roteador e copiou para o segundo. O site A anuncia 203.0.113.0/25 e o site B anuncia 203.0.113.128/25.

• CE1 (site A) fala eBGP com o PE1 pelo enlace 198.51.100.0/30: PE1 em .1, CE1 em .2.
• CE2 (site B) fala eBGP com o PE2 pelo enlace 198.51.100.4/30: PE2 em .5, CE2 em .6.
• Entre PE1 e PE2 a rota viaja como VPNv4 no iBGP do provedor, que não acrescenta ASN.

O caminho do prefixo do site A: o CE1 anuncia com AS_PATH 65001. O PE1 recebe e leva para o PE2 pelo iBGP. O PE2 anuncia para o CE2 colocando o próprio ASN na frente: 64500 65001. O CE2 vê o 65001 e descarta. O mesmo acontece no sentido contrário. Os dois sites ficam sem rota um para o outro, e o único sinal disso é a ausência do prefixo na tabela.

A montagem da VRF, do RD e dos route targets está no guia de L3VPN MPLS no Huawei, e a base do transporte em o que é MPLS. Aqui o foco é só a sessão PE-CE.

AS-override no PE

O as-override é a correção do lado do provedor. Antes de anunciar a rota para o vizinho, o PE procura o ASN desse vizinho no AS_PATH e troca cada ocorrência pelo próprio ASN. No cenário, o PE2 sabe que o CE2 é do AS 65001, encontra 65001 no caminho e troca por 64500. O CE2 recebe 64500 64500, não encontra o próprio ASN e aceita.

as-override no Cisco IOS

router bgp 64500
 address-family ipv4 vrf CLIENTE-A
  neighbor 198.51.100.6 remote-as 65001
  neighbor 198.51.100.6 activate
  neighbor 198.51.100.6 as-override
 exit-address-family

O comando fica dentro da address-family da VRF, por vizinho. As duas primeiras linhas do vizinho são a sessão PE-CE comum. A terceira liga a reescrita só para o CE2. Repita no PE1 para o CE1, senão o sentido contrário continua quebrado. Saída de exemplo no CE2, depois da mudança:

CE2# show ip bgp
     Network          Next Hop        Metric LocPrf Weight Path
 *>  203.0.113.0/25   198.51.100.5                         0 64500 64500 i
 *>  203.0.113.128/25 0.0.0.0              0         32768 i

O caminho 64500 64500 parece estranho, mas é o esperado: um 64500 do PE1, reescrito, e outro do PE2, que anunciou. O comprimento do AS_PATH continua igual, o que preserva a comparação de caminhos se o site tiver mais de uma saída.

substitute-as no Huawei VRP

No VRP o mesmo recurso se chama substitute-as. Em VRP8, no PE:

bgp 64500
 ipv4-family vpn-instance CLIENTE-A
  peer 198.51.100.6 as-number 65001
  peer 198.51.100.6 substitute-as
commit

O peer ... as-number cria a sessão dentro da ipv4-family vpn-instance, e o peer ... substitute-as faz a substituição do ASN do vizinho pelo ASN local. O commit aplica, porque no VRP8 nada vale antes dele.

as-override no Junos

set routing-instances CLIENTE-A protocols bgp group CE type external
set routing-instances CLIENTE-A protocols bgp group CE peer-as 65001
set routing-instances CLIENTE-A protocols bgp group CE neighbor 198.51.100.6 as-override
commit check
commit

No Junos o as-override fica no grupo ou no vizinho dentro da routing-instance. A documentação da Juniper avisa que ele vale só para o grupo onde foi configurado: outro grupo com vizinhos do mesmo ASN não é afetado. O commit check valida antes do commit.

Allowas-in no CE

O allowas-in é a correção do lado do cliente. O PE não muda nada e anuncia 64500 65001. O CE2 é que passa a aceitar rotas com o próprio ASN no caminho, até o número de vezes configurado. Com allowas-in 1, uma ocorrência é aceita. Duas, não.

allowas-in no Cisco IOS

router bgp 65001
 neighbor 198.51.100.5 remote-as 64500
 address-family ipv4
  network 203.0.113.128 mask 255.255.255.128
  neighbor 198.51.100.5 activate
  neighbor 198.51.100.5 allowas-in 1
 exit-address-family

O número vai de 1 a 10. Sem número, o Cisco usa 3, o que é mais permissivo do que o cenário precisa. Escreva o 1 explicitamente. Saída de exemplo no CE2:

CE2# show ip bgp
     Network          Next Hop        Metric LocPrf Weight Path
 *>  203.0.113.0/25   198.51.100.5                         0 64500 65001 i
 *>  203.0.113.128/25 0.0.0.0              0         32768 i

Agora o 65001 aparece no caminho e a rota é aceita mesmo assim. Esse é o efeito visível do allowas-in: o AS_PATH fica verdadeiro, mostrando que a rota nasceu no próprio AS do cliente, em outro site.

allow-as-loop no Huawei VRP

bgp 65001
 peer 198.51.100.5 as-number 64500
 ipv4-family unicast
  network 203.0.113.128 25
  peer 198.51.100.5 allow-as-loop 1

O equivalente do allowas-in no VRP é o peer ... allow-as-loop. O padrão é 1 quando você não informa o número, e a faixa também vai de 1 a 10. O bloco acima é de um roteador AR em VRP5, que aplica cada linha na hora e não tem commit. Em VRP8, feche com commit.

loops no Junos

set routing-options autonomous-system 65001 loops 2
set protocols bgp group PE type external
set protocols bgp group PE peer-as 64500
set protocols bgp group PE neighbor 198.51.100.5
commit check
commit

O Junos não tem um comando chamado allowas-in. O equivalente é o loops do autonomous-system, e a contagem é diferente. Pela documentação da Juniper, o padrão é loops 1: a rota é escondida se o ASN aparece uma vez ou mais. Com loops 2, ela só é escondida com duas ocorrências ou mais. Ou seja, o loops 2 do Junos faz o que o allowas-in 1 faz no Cisco. Outra diferença: no Cisco e no Huawei o allowas-in é configurado por vizinho, e no Junos o loops fica em routing-options e vale para todas as sessões BGP da instância, não só para a sessão com o PE.

Se o CE é Junos e já tem políticas de importação, confira se elas não descartam o prefixo antes. A lógica de policy está no guia de policy-statement no Junos.

Qual lado deve resolver o loop

Os dois funcionam, e a escolha é mais operacional do que técnica. O as-override deixa a decisão com o provedor e não exige nada do cliente. O allowas-in deixa o AS_PATH honesto, o que facilita o diagnóstico do lado do cliente, mas depende de alguém configurar cada CE.

Há também os casos em que nenhum dos dois é preciso. Se o cliente aceita usar 65001 num site e 65002 no outro, a regra de loop não dispara e nada precisa ser relaxado. E se o site só tem uma saída, o PE pode anunciar apenas a rota padrão, que já nasce no AS do provedor.

Riscos e como se proteger

As-override esconde loops de verdade

Ao trocar o ASN do cliente pelo do provedor, o PE apaga justamente a informação que o BGP usa para detectar loop. O caso clássico é o site com duas conexões à VPN. O site A anuncia o prefixo pelo PE1, a rota atravessa o backbone e chega ao PE3, que também atende o site A. Com as-override, o PE3 anuncia o prefixo de volta ao próprio site A com 64500 64500, e o CE aceita. Se o site redistribui BGP no IGP interno, o tráfego pode sair para a VPN e voltar.

A proteção é o Site of Origin (SoO), uma extended community que marca de qual site a rota veio. Você configura o mesmo valor em todas as sessões PE-CE do site A. O PE não anuncia para um vizinho uma rota que carrega o SoO desse mesmo vizinho. No Cisco:

router bgp 64500
 address-family ipv4 vrf CLIENTE-A
  neighbor 198.51.100.2 soo 64500:1
 exit-address-family

No Huawei, dentro da mesma vpn-instance:

bgp 64500
 ipv4-family vpn-instance CLIENTE-A
  peer 198.51.100.2 soo 64500:1
commit

O valor 64500:1 identifica o site A. Configure o mesmo valor na sessão do outro PE que atende o site A, e um valor diferente para cada outro site.

Allowas-in aceita mais do que o necessário

O allowas-in vale para tudo o que chega pela sessão onde foi configurado. Use só na sessão com o PE da VPN, nunca numa sessão de trânsito IP com tabela completa, e com o menor número que resolve, quase sempre 1. Um allowas-in 3 copiado do padrão do Cisco aceita caminhos que passam três vezes pelo AS do cliente, o que não tem explicação legítima nesse cenário. No Junos o loops vale para a instância inteira, então num CE Junos que também fala com uma operadora de trânsito o relaxamento atinge essa sessão também.

Em site com duas saídas, o allowas-in tem o mesmo problema do as-override: o prefixo do próprio site pode voltar pelo outro PE. Normalmente a rota local vence por ser conectada ou do IGP, mas vale filtrar na entrada os prefixos do próprio site.

Como verificar

Comece pelo PE: confirme que a rota do site A chegou na VRF e veja o que está sendo anunciado ao CE2. Depois vá ao CE e confira se a rota entrou ou foi descartada:

! Cisco, no PE: o que veio do CE1 e o que vai para o CE2
show bgp vpnv4 unicast vrf CLIENTE-A 203.0.113.0/25
show bgp vpnv4 unicast vrf CLIENTE-A neighbors 198.51.100.6 advertised-routes

# Huawei, no PE
display bgp vpnv4 vpn-instance CLIENTE-A routing-table
display bgp vpnv4 vpn-instance CLIENTE-A routing-table peer 198.51.100.6 advertised-routes

# Junos, no CE
show route receive-protocol bgp 198.51.100.5
show route hidden

1. Se o PE não tem a rota do site A na VRF, o problema é anterior: sessão com o CE1, route target ou iBGP VPNv4.
2. Se o PE tem a rota e a anuncia ao CE2, mas o CE2 não instala, é o loop do AS_PATH. Aplique uma das duas soluções.
3. Com as-override, o AS_PATH no CE2 tem só o ASN do provedor. Com allowas-in, tem o ASN do cliente no fim.
4. No Junos, a rota descartada pelo loop aparece em show route hidden.

Erros comuns

• Configurar só um PE. O as-override vale no sentido do anúncio. Se só o PE2 tiver, o site B aprende o site A, mas o site A continua sem o site B.
• Allowas-in fora da address-family certa. No Cisco, o comando entra na address-family da sessão. Configurado em outra família, não tem efeito sobre as rotas IPv4.
• Loops 1 no Junos achando que libera. Esse é o padrão. Para aceitar uma ocorrência, use loops 2.
• Esquecer de reenviar as rotas. Depois de ligar o allowas-in, as rotas descartadas antes podem só aparecer depois de pedir o reenvio ao vizinho, com clear ip bgp 198.51.100.5 soft in no Cisco.
• Allowas-in na sessão de trânsito. Fica valendo para a tabela completa da internet. Restrinja à sessão com a VPN.

Perguntas frequentes

Qual a diferença entre as-override e allowas-in?

O as-override é configurado no PE e troca o ASN do cliente pelo do provedor no AS_PATH antes de anunciar. O allowas-in é configurado no CE e faz o roteador aceitar o próprio ASN no caminho. Os dois resolvem o mesmo problema, cada um de um lado da sessão.

Preciso configurar as-override e allowas-in juntos?

Não. Um dos dois basta. Com as-override no PE, o CE já não vê o próprio ASN, e o allowas-in não tem o que fazer.

Qual número usar no allowas-in?

Use 1 no cenário de dois sites com o mesmo ASN. No Cisco, sem número o padrão é 3. No Huawei, o padrão do allow-as-loop é 1. No Junos, o equivalente é loops 2.

O as-override funciona fora de L3VPN?

Funciona em qualquer sessão eBGP, mas foi pensado para a sessão PE-CE de VPN, e é ali que faz sentido. Em sessões de trânsito ou de PTT, reescrever AS_PATH de terceiros apaga a proteção de loop e pode mascarar vazamentos.

Por que o AS_PATH com as-override mostra o ASN do provedor duas vezes?

Porque um 64500 é o ASN do cliente reescrito e o outro é o PE que anunciou. O comprimento do caminho fica igual ao original, e isso mantém a comparação de rotas coerente quando há mais de uma saída.

Conclusão

O CE que ignora a rota do outro site do mesmo cliente está seguindo a regra de loop do BGP. A correção é escolher quem relaxa essa regra: o provedor, com as-override no PE, ou o cliente, com allowas-in no CE. Em site com duas saídas, acrescente SoO. E quando der, a melhor correção é a que não precisa de nenhum dos dois: um ASN por site.

Leitura recomendada: Diferença entre AS-OVERRIDE e ALLOWAS-IN, do Brasil Peering Forum (CC BY-NC 4.0).