Diferenca entre AS-OVERRIDE e ALLOWAS-IN - Histórico de revisão

Fernando.frediani: Adicionada categoria Roteamento

2019-09-13T15:48:03Z

Adicionada categoria Roteamento

Humbertogaliza em 20h15min de 26 de maio de 2019

2019-05-26T20:15:05Z

Humbertogaliza em 11h22min de 26 de maio de 2019

2019-05-26T11:22:57Z

Humbertogaliza em 11h10min de 26 de maio de 2019

2019-05-26T11:10:36Z

Mostrar alterações

Humbertogaliza em 08h48min de 26 de maio de 2019

2019-05-26T08:48:01Z

Humbertogaliza em 08h40min de 26 de maio de 2019

2019-05-26T08:40:33Z

Humbertogaliza em 13h40min de 25 de maio de 2019

2019-05-25T13:40:07Z

Daniel Damito em 23h58min de 15 de maio de 2019

2019-05-15T23:58:50Z

Daniel Damito em 23h56min de 15 de maio de 2019

2019-05-15T23:56:57Z

Daniel Damito em 14h22min de 3 de maio de 2019

2019-05-03T14:22:37Z

← Edição anterior		Edição das 15h48min de 13 de setembro de 2019
Linha 69:		Linha 69:

	'''Autores:''' [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]e [[Humberto Galiza]]		'''Autores:''' [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]e [[Humberto Galiza]]
		+	[[Categoria:Roteamento]]

@@ Linha 10: / Linha 10: @@
   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
+  *> 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

@@ Linha 66: / Linha 66: @@
   *> 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'''
-É possível a configuração do AS-OVERRIDE em cenários com operadoras
+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]]

@@ Linha 15: / Linha 15: @@
 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 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;
+  '''*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.
@@ Linha 25: / Linha 25: @@
 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.2.3.4, o que atenderia ao cenário do diagrama exposto anteriormente.
-Na plataforma Cisco IOS se habilitarmos o modo debug veremos com bastante clareza nas mensagens de log que o router detectou a presença do AS 20 no atributo AS_PATH no prefixo 10.0.0.0/24 e recebido do R1_Upstream (neighbor 1.1.1.1):
+Vejamos um exemplo mais completo, e como o modo debug habilitado na plataforma Cisco IOS. No terminal é possível ver com bastante clareza as mensagens BGP UPDATE e REFRESH evidenciando 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 devido ao comando allowas-in:
   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 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'''
+  '''*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
@@ Linha 41: / Linha 42: @@
   *> 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 ====
 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:

@@ Linha 17: / Linha 17: @@
   *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.
+É 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 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:
+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 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''
+  '''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.
+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.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:

@@ 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 ===
-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''' é 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.
-Quando você possui redes em lugares diferentes e necessita aprender o prefixo de ambas nos 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 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.
 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:
@@ 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.
-'''Autor:''' [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]
+'''Autores:''' [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]e [[Humberto Galiza]]

@@ Linha 17: / Linha 17: @@
 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.
-Exemplo: ''neighbor 1.2.3.4 allowas-in 1''
+Exemplo: '''R3#''' ''neighbor 1.2.3.4 allowas-in 1''
-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.
+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.
 Agora vejamos um outro exemplo de cenário:

← Edição anterior		Edição das 14h22min de 3 de maio de 2019
Linha 27:		Linha 27:
	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.

−	'''Autor:''' Daniel Damito	+	'''Autor:''' [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]