Mudanças entre as edições de "Diferenca entre AS-OVERRIDE e ALLOWAS-IN"

De Wiki BPF
Ir para navegação Ir para pesquisar
(Adicionada categoria Roteamento)
 
(8 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 1: Linha 1:
−
O BGP possui por padrão um mecanismo anti loop, que evita que um prefixo anunciado por você seja ensinado à você mesmo.
+
== Introdução ==
 +
'''ALLOWAS-IN''' e '''AS-OVERRIDE''' são duas funcionalidades similares que podem ser empregadas em um cenário onde um AS X (ex: provedor) está conectado a um outro AS Y (ex: operadora de trânsito / backbone MPLS) através de múltiplos sites/PoPs, geralmente geograficamente distintos. Para compreender melhor ambas funcionalidades é oportuno analisar como funciona o controle de loops no protocolo BGP (RFC 4271).  
  
−
Primeiramente é bom lembrar que estamos falando de eBGP, pois no iBGP a premissa é de quê a sessão BGP é fechada com um neighbor no mesmo ASN que você.
+
A especificação do protocolo BGP traz diversos mecanismos de controle e prevenção de loops. Em um cenário iBGP (i.e., sessões BGP dentro de um mesmo AS) por exemplo, a regra do '''split-horizon''' <u>é um</u> dos mecanismos de controle e prevenção de loops que evita que prefixos anunciados por um vizinho iBGP (A) ao vizinho iBGP (B) sejam re-anunciados por (B) para um terceiro vizinho iBGP (C). Existem diversas soluções disponíveis possíveis para "relaxar" essa regra (uso de Route-Reflectors é uma delas por exemplo), porém elas não serão objeto de discussão nesse artigo.  
  
−
Quando você possui redes em lugares diferentes e necessita aprender o prefixo de ambas no dois sites, necessita utilizar o AS-OVERRIDE ou o ALLOWAS-IN. Os dois recursos têm a mesma função, mas são configurados em lugares diferentes.
+
Já em cenários eBGP (i.e., sessões BGP entre ASes diferentes) o mecanismo de controle e prevenção de loops mais simples é a análise do atributo AS_PATH. Essencialmente, se o peer eBGP (A) encontrar seu próprio ASN no atributo AS_PATH do(s) prefixo(s) anunciados pelo peer eBGP (B) (e vice-versa), o roteador então descarta o prefixo com o intuito de evitar um possível loop de roteamento. ALLOWAS-IN e AS-OVERRIDE são duas soluções similares que podem ser empregadas nesse caso, e a partir desse ponto iremos detalhar em que tipo de situações podemos usar uma ou outra.
  
−
O AS-OVERRIDE é configurado no lado do provedor de serviços, seu neighbor eBGP, e tem por função modificar o seu ASN pelo ASN local de seu provedor antes de te enviar o prefixo. Vide exemplo abaixo:
+
=== '''ALLOWAS-IN''' ===
 +
Considere o cenário da Figura 1 em que o AS 20 (provedor) é cliente de trânsito do AS 10 (upstream). Topologias dessa natureza podem ocorrer com alguma frequência, por exemplo, em provedores de Internet que não tem ligação física entre seus PoPs IP e necessitam comprar trânsito IP de um Upstream para prover acesso à Internet aos seus assinantes em cada PoP/localidade.[[Arquivo:Exemplo1_ASOVERRIDE_ALLOWASIN.png|centro|450x450px|alt=Figura 1: Cliente (AS 10) conectado ao ISP (AS 20) em dois PoPs em localidades distintas.|miniaturadaimagem|Figura 1: Cliente (AS 20) conectado ao ISP/UPSTREAM (AS 10) em dois PoPs em localidades distintas.]]Nesse cenário, R2 fará o anúncio do prefixo 10.0.0.0/24 para o Upstream, e o AS_PATH desse prefixo será visto da seguinte maneira no router do Upstream:
 +
R1_Upstream#sh ip bgp 10.0.0.0/24
 +
    Network          Next Hop            Metric LocPrf Weight Path
 +
*> 10.0.0.0/24      100.64.0.2                  100        20 i
 +
Seguindo o funcionamento "normal" do protocolo BGP (isto é, ignorando filtros, políticas de roteamento, etc.), o atributo AS_PATH do prefixo será modificado em R1 antes que ele seja re-anunciado em direção aos seus peers. A "nova" lista de AS-PATH do prefixo será algo semelhante a:
 +
AS_PATH: 10 20 i
 +
No entanto, quando a mensagem de BGP UPDATE que carrega o prefixo 10.0.0.0/24 chegar a R3, R3 irá descartar essa atualização tendo em vista que notará a presença do seu próprio ASN (20 nesse caso) no atributo AS_PATH desse prefixo. Um alerta semelhante a esse pode ser visto no log do roteador R3 (plataforma Cisco IOS, modo debug):
 +
*Apr  5 11:18:03.515: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
 +
*Apr  5 11:18:03.559: BGP(0): 1.1.1.1 rcv UPDATE w/ attr: nexthop 1.1.1.1, origin i, originator 0.0.0.0, path 10 20, community , extended community
 +
'''*Apr  5 11:18:03.559: BGP(0): 1.1.1.1 rcv UPDATE about 10.0.0.0/24 -- DENIED due to: AS-PATH contains our own AS;'''
 +
É aqui que o ALLOWAS-IN entra em cena para relaxar essa restrição. O ALLOWAS-IN é configurado no roteador do provedor, nesse caso R3. O efeito é que simplesmente o BGP passará a aceitar a eventual presença do seu próprio AS no AS_PATH dos prefixos recebidos do Upstream.
  
−
[[Arquivo:Exemplo1_ASOVERRIDE_ALLOWASIN.png|centro|650x650px]]
+
Na maioria das plataformas (Cisco, Juniper, etc) o ALLOWAS-IN necessita de um parâmetro, que é o número máximo de ocorrências tolerado de seu próprio ASN no atributo AS_PATH associado aos prefixos recebidos. Por exemplo, no Cisco IOS, se quisermos permitir a ocorrência de até 2 vezes seu próprio ASN, nas atualizações de rota recebidas via peer eBGP 1.1.1.1 (R1_Upstream) a configuração é a seguinte:  
 +
'''R3#''' conf t
 +
'''R3#''' (config) router bgp 20
 +
'''R3#''' (config-router) neighbor 1.1.1.1 allowas-in 2
 +
No exemplo acima, realizamos a configuração de forma que possamos aprender prefixos que contenham no máximo 2 ocorrências de seu próprio ASN no campo do AS-PATH quando este parte do neighbor 1.1.1.1, o que atenderia ao cenário do diagrama exposto anteriormente. '''É importante salientar que o ALLOWAS-IN deve ser configurado em todos os roteadores do cliente nos quais se deseja relaxar a regra de controle de loops do BGP!''' 
  
−
No diagrama acima, o roteador R3 receberia o prefixo 10.0.0.0/24 com o AS-PATH '''''20 - 10''''', então descartaria devido ao mecanismo anti loop. Se o seu upstream, no caso o AS10, habilitasse o AS-OVERRIDE, o AS-PATH seria '''''10 - 10''''', então este prefixo não seria descartado.
+
Vejamos um exemplo mais completo (e com o modo debug habilitado na plataforma Cisco IOS). No terminal é possível ver com bastante clareza a mensagem BGP UPDATE contendo a estrutura de dados que carrega informações sobre o prefixo e máscara de subrede (Network Layer Reachability Information - NLRI). Na sequência é possível notar que o router detectou a presença do AS 20 no atributo AS_PATH do prefixo 10.0.0.0/24 anunciado pelo R1_Upstream (neighbor 1.1.1.1), porém instalou o prefixo na tabela de encaminhamento (FIB) devido ao relaxamento da restrição imposto pela configuração do "allowas-in" para o neighbor 1.1.1.1:
 +
R3(config)#router bgp 20
 +
R3(config-router)#neighbor 1.1.1.1 allowas-in 1
 +
R3(config-router)#
 +
'''*Mar  1 02:34:34.927: BGP: 1.1.1.1 sending REFRESH_REQ(5) for afi/safi: 1/1'''
 +
*Mar  1 02:34:34.927: BGP: 1.1.1.1 send message type 5, length (incl. header) 23
 +
*Mar  1 02:34:35.015: BGP(0): 1.1.1.1 rcvd '''UPDATE''' w/ attr: nexthop 1.1.1.1, origin i, path 10 20
 +
*Mar  1 02:34:35.015: BGP(0): 1.1.1.1 rcvd 10.0.0.0/24
 +
'''*Mar  1 02:34:35.019: BGP(0): Revise route installing 1 of 1 routes for 10.0.0.0/24 -> 1.1.1.1(main) to main IP table'''
 +
R3(config-router)#do sh ip bgp
 +
BGP table version is 4, local router ID is 3.3.3.3
 +
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 +
              r RIB-failure, S Stale
 +
Origin codes: i - IGP, e - EGP, ? - incomplete
 +
    Network          Next Hop            Metric LocPrf Weight Path
 +
*> 10.0.0.0/24    1.1.1.1                            0 '''10 20 i'''
 +
*> 20.0.0.0/24    0.0.0.0                  0        32768 i
 +
=== AS-OVERRIDE ===
 +
Conforme já mencionado a funcionalidade AS-OVERRIDE é bastante semelhante ao ALLOWAS-IN no tocante ao objetivo desejado que é relaxar o controle de loop do protocolo BGP. Todavia, a grande diferença entre ambas é que ela modifica o atributo AS_PATH do prefixo substituindo a presença do ASN "causador" do loop pelo ASN do próprio Upstream. Em função disso, o AS-OVERRIDE é sempre configurado no lado do Upstream (provedor de serviços) ao passo que toda a configuração do ALLOWAS-IN é realizada no lado do cliente.  
  
−
Sendo assim, entendemos que o AS-OVERRIDE é indicado no caso de você não querer exigir configurações adicionais em seu roteador, entretanto será necessário que seu upstream o faça.
+
Vale ainda ressaltar que o uso do AS-OVERRIDE está geralmente associado a cenários de VPN de camada 3 (L3VPN) em uma rede MPLS gerenciada. Nesse tipo de cenário, o cliente possui diversos sites e utiliza BGP como protocolo de roteamento entre o seu CE (Customer Edge) e o PE (Provider Edge) do Upstream. Nesse caso, o AS-OVERRIDE é aplicado nos roteadores PE, e o efeito será a substituição do ASN do CE pelo ASN do PE antes que o(s) prefixo(s) sejam reanunciados para os outros PE's da rede MPLS.
 +
[[Arquivo:Bpf as override allowas in 2.png|centro|miniaturadaimagem|400x400px]]
  
−
Já o ALLOWAS-IN é configurado de seu lado, e não do provedor de serviços. Com este recurso você simplesmente ignorará o mecanismo anti loop, colocando uma exceção em determinado peer.
+
No diagrama acima o roteador CE/R3 receberia o prefixo 10.0.0.0/24 com o atributo AS-PATH '''''"20  10"''''' e então descartaria o anúncio devido ao mecanismo de prevenção de loops do BGP já discutido anteriomente. No entanto, se efetuada a configuração do AS-OVERRIDE no PE1, o roteador CE/R3 receberá o prefixo 10.0.0.0/24 com o atributo AS-PATH '''''"10  10"''''', e a prefixo será consequentemente instalado na FIB. '''É extremamente importante ressaltar que o AS-OVERRIDE deve ser configurado em todos os roteadores PE para garantir a alcançabilidade dos prefixos do cliente dentro da L3VPN!'''
  
−
O ALLOWAS-IN necessita de um parâmetro, que é o número máximo de ocorrências de seu ASN no AS-PATH que é tolerado.
+
Do ponto de vista operacional a configuração do AS-OVERRIDE é demasiadamente simples na maioria dos roteadores atuais.Como exemplo, vejamos a configuração no Cisco IOS para o cenário acima:
 +
PE1(config)#router bgp 10
 +
PE1(config-router)#address-family ipv4 unicast vrf cliente_as20
 +
PE1(config-router-af)#neighbor 2.2.2.2 as-override
  
−
Exemplo: ''neighbor 1.2.3.4 allowas-in 1''
+
PE2(config)#router bgp 10
 +
PE2(config-router)#address-family ipv4 unicast vrf cliente_as20
 +
PE2(config-router-af)#neighbor 3.3.3.3 as-override
 +
A configuração do AS-OVERRIDE fará um reset na sessão BGP entre o PE e o CE. Na sequência será possível verificar os prefixos originados ou anunciados pelos roteadores CE dessa VPNv4 contém apenas o ASN do PE (Upstream) no atributo AS_PATH:
 +
R2#sh ip bgp | b Network
 +
 +
    Network          Next Hop            Metric LocPrf Weight Path
 +
*> 2.2.2.2/32    0.0.0.0                  0        32768 i
 +
'''*> 3.3.3.3/32    100.64.0.5                            0 10 10 i'''
 +
*> 10.0.0.0/24    0.0.0.0                  0        32768 i
 +
'''*> 10.1.0.0/24    100.64.0.5                            0 10 10 i'''
 +
A utilização do AS-OVERRIDE precisa ser bem pensada e planejada para evitar problemas ou inconsistências no encaminhamento de pacotes, afinal estamos relaxando o funcionamento de uma regra crítica do BGP. Um mecanismo auxiliar para prevenção desses problemas é a utilização da BGP extended community "Site of Origin - SoO" para identificar os prefixos IP que cada site do cliente VPN origina e anuncia aos outros CE's através da L3VPN. Todavia, nesse artigo não iremos discutir a respeito desse tema e fica como tema de pesquisa adicional para o leitor.
  
−
No exemplo acima, configuramos que podemos aprender prefixos que contenham até uma ocorrência de meu próprio ASN no AS-PATH a partir do neighbor 1.2.3.4, o que atenderia ao cenário do diagrama exposto anteriormente.
+
'''Autores:''' [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]e [[Humberto Galiza]]
−
 
+
[[Categoria:Roteamento]]
−
Agora vejamos um outro exemplo de cenário:
 
−
 
 
−
[[Arquivo:Exemplo2 ASOVERRIDE ALLOWASIN.png|centro|miniaturadaimagem|650x650px]]
 
−
 
 
−
Neste exemplo, o AS-PATH do prefixo 10.0.0.0/24 para o roteador R3 seria '''''20 - 20 - 10''''', e o comando allowas-in 1 já não seria suficiente, já que o meu ASN (20), aparece duas vezes. Neste caso, teríamos que configurar allowas-in 2.
 
−
 
 
−
'''Autor:''' [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]
 

Edição atual tal como às 12h48min de 13 de setembro de 2019

Introdução

ALLOWAS-IN e AS-OVERRIDE são duas funcionalidades similares que podem ser empregadas em um cenário onde um AS X (ex: provedor) está conectado a um outro AS Y (ex: operadora de trânsito / backbone MPLS) através de múltiplos sites/PoPs, geralmente geograficamente distintos. Para compreender melhor ambas funcionalidades é oportuno analisar como funciona o controle de loops no protocolo BGP (RFC 4271).

A especificação do protocolo BGP traz diversos mecanismos de controle e prevenção de loops. Em um cenário iBGP (i.e., sessões BGP dentro de um mesmo AS) por exemplo, a regra do split-horizon é um dos mecanismos de controle e prevenção de loops que evita que prefixos anunciados por um vizinho iBGP (A) ao vizinho iBGP (B) sejam re-anunciados por (B) para um terceiro vizinho iBGP (C). Existem diversas soluções disponíveis possíveis para "relaxar" essa regra (uso de Route-Reflectors é uma delas por exemplo), porém elas não serão objeto de discussão nesse artigo.

Já em cenários eBGP (i.e., sessões BGP entre ASes diferentes) o mecanismo de controle e prevenção de loops mais simples é a análise do atributo AS_PATH. Essencialmente, se o peer eBGP (A) encontrar seu próprio ASN no atributo AS_PATH do(s) prefixo(s) anunciados pelo peer eBGP (B) (e vice-versa), o roteador então descarta o prefixo com o intuito de evitar um possível loop de roteamento. ALLOWAS-IN e AS-OVERRIDE são duas soluções similares que podem ser empregadas nesse caso, e a partir desse ponto iremos detalhar em que tipo de situações podemos usar uma ou outra.

ALLOWAS-IN

Considere o cenário da Figura 1 em que o AS 20 (provedor) é cliente de trânsito do AS 10 (upstream). Topologias dessa natureza podem ocorrer com alguma frequência, por exemplo, em provedores de Internet que não tem ligação física entre seus PoPs IP e necessitam comprar trânsito IP de um Upstream para prover acesso à Internet aos seus assinantes em cada PoP/localidade.

Figura 1: Cliente (AS 10) conectado ao ISP (AS 20) em dois PoPs em localidades distintas.
Figura 1: Cliente (AS 20) conectado ao ISP/UPSTREAM (AS 10) em dois PoPs em localidades distintas.

Nesse cenário, R2 fará o anúncio do prefixo 10.0.0.0/24 para o Upstream, e o AS_PATH desse prefixo será visto da seguinte maneira no router do Upstream: 

R1_Upstream#sh ip bgp 10.0.0.0/24
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0/24      100.64.0.2                   100         20 i

Seguindo o funcionamento "normal" do protocolo BGP (isto é, ignorando filtros, políticas de roteamento, etc.), o atributo AS_PATH do prefixo será modificado em R1 antes que ele seja re-anunciado em direção aos seus peers. A "nova" lista de AS-PATH do prefixo será algo semelhante a: 

AS_PATH: 10 20 i

No entanto, quando a mensagem de BGP UPDATE que carrega o prefixo 10.0.0.0/24 chegar a R3, R3 irá descartar essa atualização tendo em vista que notará a presença do seu próprio ASN (20 nesse caso) no atributo AS_PATH desse prefixo. Um alerta semelhante a esse pode ser visto no log do roteador R3 (plataforma Cisco IOS, modo debug): 

*Apr  5 11:18:03.515: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
*Apr  5 11:18:03.559: BGP(0): 1.1.1.1 rcv UPDATE w/ attr: nexthop 1.1.1.1, origin i, originator 0.0.0.0, path 10 20, community , extended community
*Apr  5 11:18:03.559: BGP(0): 1.1.1.1 rcv UPDATE about 10.0.0.0/24 -- DENIED due to: AS-PATH contains our own AS;

É aqui que o ALLOWAS-IN entra em cena para relaxar essa restrição. O ALLOWAS-IN é configurado no roteador do provedor, nesse caso R3. O efeito é que simplesmente o BGP passará a aceitar a eventual presença do seu próprio AS no AS_PATH dos prefixos recebidos do Upstream.

Na maioria das plataformas (Cisco, Juniper, etc) o ALLOWAS-IN necessita de um parâmetro, que é o número máximo de ocorrências tolerado de seu próprio ASN no atributo AS_PATH associado aos prefixos recebidos. Por exemplo, no Cisco IOS, se quisermos permitir a ocorrência de até 2 vezes seu próprio ASN, nas atualizações de rota recebidas via peer eBGP 1.1.1.1 (R1_Upstream) a configuração é a seguinte: 

R3# conf t
R3# (config) router bgp 20
R3# (config-router) neighbor 1.1.1.1 allowas-in 2

No exemplo acima, realizamos a configuração de forma que possamos aprender prefixos que contenham no máximo 2 ocorrências de seu próprio ASN no campo do AS-PATH quando este parte do neighbor 1.1.1.1, o que atenderia ao cenário do diagrama exposto anteriormente. É importante salientar que o ALLOWAS-IN deve ser configurado em todos os roteadores do cliente nos quais se deseja relaxar a regra de controle de loops do BGP!

Vejamos um exemplo mais completo (e com o modo debug habilitado na plataforma Cisco IOS). No terminal é possível ver com bastante clareza a mensagem BGP UPDATE contendo a estrutura de dados que carrega informações sobre o prefixo e máscara de subrede (Network Layer Reachability Information - NLRI). Na sequência é possível notar que o router detectou a presença do AS 20 no atributo AS_PATH do prefixo 10.0.0.0/24 anunciado pelo R1_Upstream (neighbor 1.1.1.1), porém instalou o prefixo na tabela de encaminhamento (FIB) devido ao relaxamento da restrição imposto pela configuração do "allowas-in" para o neighbor 1.1.1.1: 

R3(config)#router bgp 20
R3(config-router)#neighbor 1.1.1.1 allowas-in 1
R3(config-router)#
*Mar  1 02:34:34.927: BGP: 1.1.1.1 sending REFRESH_REQ(5) for afi/safi: 1/1
*Mar  1 02:34:34.927: BGP: 1.1.1.1 send message type 5, length (incl. header) 23
*Mar  1 02:34:35.015: BGP(0): 1.1.1.1 rcvd UPDATE w/ attr: nexthop 1.1.1.1, origin i, path 10 20
*Mar  1 02:34:35.015: BGP(0): 1.1.1.1 rcvd 10.0.0.0/24
*Mar  1 02:34:35.019: BGP(0): Revise route installing 1 of 1 routes for 10.0.0.0/24 -> 1.1.1.1(main) to main IP table
R3(config-router)#do sh ip bgp
BGP table version is 4, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0/24    1.1.1.1                            0 10 20 i
*> 20.0.0.0/24    0.0.0.0                  0         32768 i

AS-OVERRIDE

Conforme já mencionado a funcionalidade AS-OVERRIDE é bastante semelhante ao ALLOWAS-IN no tocante ao objetivo desejado que é relaxar o controle de loop do protocolo BGP. Todavia, a grande diferença entre ambas é que ela modifica o atributo AS_PATH do prefixo substituindo a presença do ASN "causador" do loop pelo ASN do próprio Upstream. Em função disso, o AS-OVERRIDE é sempre configurado no lado do Upstream (provedor de serviços) ao passo que toda a configuração do ALLOWAS-IN é realizada no lado do cliente.

Vale ainda ressaltar que o uso do AS-OVERRIDE está geralmente associado a cenários de VPN de camada 3 (L3VPN) em uma rede MPLS gerenciada. Nesse tipo de cenário, o cliente possui diversos sites e utiliza BGP como protocolo de roteamento entre o seu CE (Customer Edge) e o PE (Provider Edge) do Upstream. Nesse caso, o AS-OVERRIDE é aplicado nos roteadores PE, e o efeito será a substituição do ASN do CE pelo ASN do PE antes que o(s) prefixo(s) sejam reanunciados para os outros PE's da rede MPLS.

Bpf as override allowas in 2.png

No diagrama acima o roteador CE/R3 receberia o prefixo 10.0.0.0/24 com o atributo AS-PATH "20 10" e então descartaria o anúncio devido ao mecanismo de prevenção de loops do BGP já discutido anteriomente. No entanto, se efetuada a configuração do AS-OVERRIDE no PE1, o roteador CE/R3 receberá o prefixo 10.0.0.0/24 com o atributo AS-PATH "10 10", e a prefixo será consequentemente instalado na FIB. É extremamente importante ressaltar que o AS-OVERRIDE deve ser configurado em todos os roteadores PE para garantir a alcançabilidade dos prefixos do cliente dentro da L3VPN!

Do ponto de vista operacional a configuração do AS-OVERRIDE é demasiadamente simples na maioria dos roteadores atuais.Como exemplo, vejamos a configuração no Cisco IOS para o cenário acima: 

PE1(config)#router bgp 10
PE1(config-router)#address-family ipv4 unicast vrf cliente_as20
PE1(config-router-af)#neighbor 2.2.2.2 as-override

PE2(config)#router bgp 10
PE2(config-router)#address-family ipv4 unicast vrf cliente_as20
PE2(config-router-af)#neighbor 3.3.3.3 as-override

A configuração do AS-OVERRIDE fará um reset na sessão BGP entre o PE e o CE. Na sequência será possível verificar os prefixos originados ou anunciados pelos roteadores CE dessa VPNv4 contém apenas o ASN do PE (Upstream) no atributo AS_PATH: 

R2#sh ip bgp | b Network

   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.2/32    0.0.0.0                  0         32768 i
*> 3.3.3.3/32     100.64.0.5                            0 10 10 i
*> 10.0.0.0/24    0.0.0.0                  0         32768 i
*> 10.1.0.0/24    100.64.0.5                            0 10 10 i

A utilização do AS-OVERRIDE precisa ser bem pensada e planejada para evitar problemas ou inconsistências no encaminhamento de pacotes, afinal estamos relaxando o funcionamento de uma regra crítica do BGP. Um mecanismo auxiliar para prevenção desses problemas é a utilização da BGP extended community "Site of Origin - SoO" para identificar os prefixos IP que cada site do cliente VPN origina e anuncia aos outros CE's através da L3VPN. Todavia, nesse artigo não iremos discutir a respeito desse tema e fica como tema de pesquisa adicional para o leitor.

Autores: Daniel Damitoe Humberto Galiza

Disponível em “https://wiki.brasilpeeringforum.org/index.php?title=Diferenca_entre_AS-OVERRIDE_e_ALLOWAS-IN&oldid=1107”