Diferenca entre AS-OVERRIDE e ALLOWAS-IN

De Wiki BPF
Ir para: navegação, pesquisa

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