Exibir código-fonte para Diferenca entre AS-OVERRIDE e ALLOWAS-IN

== 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''' <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. 

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.[[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.

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.
[[Arquivo:Bpf as override allowas in 2.png|centro|miniaturadaimagem|400x400px]]

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:''' [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]e [[Humberto Galiza]]
[[Categoria:Roteamento]]