Mudanças entre as edições de "Diferenca entre AS-OVERRIDE e ALLOWAS-IN"
| Linha 1: | Linha 1: | ||
| − | + | === Introdução === | |
| + | '''AS-OVERRIDE''' e '''ALLOWAS-IN''' 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 (sendo estes 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 (mensagens BGP UPDATE) com origem no vizinho iBGP (A) e destinado ao vizinho iBGP (B) sejam re-anunciadas a 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 trivial é a análise do atributo AS_PATH. Essencialmente, se o par eBGP (A) encontrar seu próprio ASN no atributo AS_PATH relacionado ao prefixo sendo anunciado pelo par eBGP (B), ele então descarta a mensagem BGP UPDATE contendo essa informação com o intuito de evitar um possível loop de roteamento. AS-OVERRIDE e ALLOWAS-IN 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 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.]]O anúncio do prefixo 10.0.0.0/24 realizado a partir de R2 será visto com o seguinte AS_PATH 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 0.0.0.0 100 20 i | ||
| + | Ainda no R1_Upstream, já que há uma sessão eBGP entre o R1_Upstream e o R3, o atributo AS_PATH será modificado antes que o prefixo 10.0.0.0/24 seja re-anunciado em direção a R3, de modo a incluir o AS do Upstream. Teríamos nesse caso 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 notou 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): | ||
| + | *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 20.20.20.20, origin i, originator 0.0.0.0, path 1 65001, 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 nos 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 ASN no atributo AS_PATH. 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 par 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 uma ocorrência de meu próprio ASN no campo do AS-PATH quando este parte do neighbor 1.2.3.4, o que atenderia ao cenário do diagrama exposto anteriormente. | ||
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: | 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: | ||
| − | |||
| − | |||
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''''', portanto este prefixo não seria descartado. | 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''''', portanto este prefixo não seria descartado. | ||
| − | 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 | + | 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. |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Agora vejamos um outro exemplo de cenário: | Agora vejamos um outro exemplo de cenário: | ||
| Linha 27: | Linha 37: | ||
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. | 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. | ||
| − | ''' | + | '''Autores:''' [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]e [[Humberto Galiza]] |
Edição das 10h40min de 25 de maio de 2019
Introdução
AS-OVERRIDE e ALLOWAS-IN 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 (sendo estes 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 (mensagens BGP UPDATE) com origem no vizinho iBGP (A) e destinado ao vizinho iBGP (B) sejam re-anunciadas a 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 trivial é a análise do atributo AS_PATH. Essencialmente, se o par eBGP (A) encontrar seu próprio ASN no atributo AS_PATH relacionado ao prefixo sendo anunciado pelo par eBGP (B), ele então descarta a mensagem BGP UPDATE contendo essa informação com o intuito de evitar um possível loop de roteamento. AS-OVERRIDE e ALLOWAS-IN 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 assinantes em cada PoP/localidade.
O anúncio do prefixo 10.0.0.0/24 realizado a partir de R2 será visto com o seguinte AS_PATH 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 0.0.0.0 100 20 i
Ainda no R1_Upstream, já que há uma sessão eBGP entre o R1_Upstream e o R3, o atributo AS_PATH será modificado antes que o prefixo 10.0.0.0/24 seja re-anunciado em direção a R3, de modo a incluir o AS do Upstream. Teríamos nesse caso 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 notou 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):
*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 20.20.20.20, origin i, originator 0.0.0.0, path 1 65001, 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 nos 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 ASN no atributo AS_PATH. 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 par 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 uma ocorrência de meu próprio ASN no campo do AS-PATH quando este parte do neighbor 1.2.3.4, o que atenderia ao cenário do diagrama exposto anteriormente.
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:
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, portanto este prefixo não seria descartado.
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.
Agora vejamos um outro exemplo de cenário:
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.
Autores: Daniel Damitoe Humberto Galiza
