Wiki BPF - Contribuições do(a) usuário(a) [pt-br]

Humberto Galiza

2019-12-18T12:18:49Z

Humbertogaliza:

[[Arquivo:Foto amazon.jpg|miniaturadaimagem|200x200px]]
* Membro do Comitê de Programa (CP) do Brasil Peering Forum (BPF).
* Co-Chair da Task Force de Software-Defined Networking (SDN) do BPF.
** É Bacharel em Ciência da Computação pela Universidade Federal da Bahia - UFBA (2009) e Pós-graduado em Informática pela Escola de Administração do Exército - EsAEx (2010).
** Possui algumas certificações profissionais dos principais fabricantes da área de Redes/Service Provider, além de habilidades com sistemas *nix, scripting e programação voltada para a área de redes.
** Desde ~2005 tem ajudado a projetar, implantar, interconectar e operar redes das mais variadas escalas, natureza e complexidade no Brasil e ao redor do mundo.
** Tem interesse nos temas engenharia de tráfego IP/MPLS, Roteamento BGP/Peering/Interconexão, Pontos de Troca de Tráfego, Redes Definidas por Software, Automação de Redes, além do desenvolvimento e padronização para a Internet.
** Vive em Dublin, Irlanda desde 2018, onde constrói redes de escala-massiva tomando pints de Guiness (não necessariamente nessa ordem :p )

=== '''Contato''' ===
'''LinkedIn:''' https://www.linkedin.com/in/humbertogaliza<nowiki/>/

'''E-mail pessoal:''' humbertogaliza[.at.]gmail.com

Configuracao de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei

2019-12-16T18:41:00Z

Humbertogaliza:

'''Autor:''' [[Humberto Galiza]]

=== Introdução ===
<blockquote>''Huawei é o novo "bacon" dos provedores de Internet brasileiros. (Operador de rede desconhecido.)''</blockquote>O tema desse breve artigo é explicar um pouco sobre como a linguagem estendida de política de roteamento (em Inglês, Extended Routing Policy Language - XPL) da Huawei pode ajudar a construir uma política de roteamento BGP "robusta" e em ''compliance'' com as melhores práticas de filtragem/segurança na Internet (como o MANRS por exemplo).

=== Definição do problema/motivação ===
Há alguns dias atrás um colega me fez a seguinte pergunta: <blockquote>"Há alguma maneira de otimizar as configurações de filtragens de prefixos usando Huawei como roteador de borda/trânsito? Esclarecendo um pouco mais, eu sempre construi os filtros usando duas ''prefix-lists'' (quatro considerando IPv6) para cada ASN de origem que estivesse no cone do downstream que eu estou filtrando. Porém, a coisa tá ficando grande...difícil de escalar. Tem uma receita mágica para isso?"</blockquote>Exemplo de prefix-list do problema em questão:
* '''BGP_ASXYZ-v4''' - Geralmente contendo os prefixos registrados no IRR como origem daquele ASN
* '''BGP_ASXYZ-v4_BH''' - Mesma coisa da anterior, mas mudando o "LE" (menor ou igual) "GE" (maior ou igual) pra 32, e dando match combinado com community de blackhole
Explicando um pouco mais, o raciocínio do colega é baseado na utilização de uma ''route-policy'' para cada cliente de trânsito. Uma cláusula "''if-match''" nessa route-policy tentará fazer o casamento para cada uma das "''prefix-lists''" listadas acima e eventualmente fará um "''apply''" com alguma ação a ser aplicada quando ocorrer esse casamento:
route-policy ''CLIENTE-XPTO'' permit ''10''
if-match BGP_ASXYZ-v4
apply "ACAO1_XYZ"

route-policy ''CLIENTE-XPTO'' permit ''20''
if-match BGP_ASXYZ-v4_BH
if-match community-filter COMM-RTBH
apply "ACAO2_XYZ_BH"
Como se pode notar há uma duplicidade (redundância) de informações: duas ''prefix-list'' com os mesmos prefixos sendo a única diferença entre elas o tamanho do bloco. Além disso, vale lembrar que nos equipamentos da Huawei só conseguiremos aplicar uma ''route-policy'' por peer BGP (quem já trabalha com JunOS, por exemplo, cujo tem a possibilidade de usar policies encadeadas sequencialmente, isso é um balde de água fria :-( ).

Essa inflexibilidade da ''route-policy'' limita bastante a possibilidade de se construir uma política de roteamento mais robusta. Exemplos de casos de uso mais complexos incluem (mas não se limitam a) a marcação de communities condicionais para engenharia de tráfego (ex: aumentar/diminuir o Local-Pref/MED, as-path prepend) e também o Remote Triggered Blackhole (RTBH), quando o cliente anuncia um prefixo específico (/32 IPv4 ou /128 IPv6 por exemplo) e deseja que o tráfego destinado àquele prefixo seja descartado. Portanto, trata-se aqui de uma situação comum nos ambientes de ISP que fornecem trânsito IP(v4/v6).

=== eXtended routing-Policy Language - XPL ===
De acordo com a própria documentação do fabricante a linguagem extendida de política de roteamento (XPL) serve exatamente para filtrar ou modificar atributos das rotas/prefixos aprendidos via BGP.

A XPL tem as mesmas funcionalidades das "route-policies", porém utiliza métodos de edição e filtragem completamente diferentes. Essa é a diferença chave que traz a flexibilidade necessária para a construção de políticas de roteamento mais robustas.

Além dos operadores já bem conhecidos das route-policy, a XPL traz também os seguintes blocos fundamentais:
* Início/fim de bloco: demarca o início/fim de um bloco de configuração. Exemplos:
{| class="wikitable"
|+
!Início
!Fim
|-
|'''xpl global-value''': início da seção de variáveis globais.
|'''end-global-value''': final da seção de variáveis globais.
|-
|'''xpl ip-prefix-list''' ''ip-prefix-list-name'': início de uma lista de prefixos IPv4
|'''end-list''': final de uma lista de prefixos IPv4
|-
|'''xpl community-list''' ''community-list-name'': início de uma lista de community
|'''end-list''': final de uma lista de community
|-
|'''xpl route-filter''' ''route-filter-name'': início de um route-filter
|'''end-filter''': final de um route-filter
|}
* Operadores lógicos: indica relacionamentos lógicos. Exemplos:
** '''eq/ge/le''': igual a/maior ou igual a/menor ou igual a
** '''in''': incluso/presente conjunto
** '''if''': "se"/inicia um bloco condicional de comparação
** '''elseif''': "senão-se"/ condicional de comparação
** '''else''': "senão"/ condicional de comparação
** '''then''': "então"/ usada no formato '''if'''+<condição/critério>+'''then''' or '''elseif'''+<condição/critério>+'''then'''.
** '''apply''': "ação" que será implementada caso haja o casamento da <condição/critério> avaliado.
** '''endif''': "fim-se"/encerra o bloco condicional de comparação.
* Elementos de <condição/critério>: são as condições a serem "casadas" no route-filter.
A lista acima é apenas para dar ao leitor um "norte" a respeito dos blocos básicos, operadores lógicos e elementos de comparação e ações suportadas pela XPL. Uma consulta a documentação oficial (ver a seção de referências) é extremamente encorajada.

=== Exemplos práticos com XPL ===
* '''Exemplo 1''': criar uma lista de prefixos com as rotas 1.1.1.0/24, 2.2.2.0/24, e 3.3.3.3/32. Criar um filtro que aplique um valor de 900 para o local-preference para esses prefixos, e 500 caso contrário:
xpl ip-prefix-list CLIENTE-XPTO
1.1.1.0 24,
2.2.2.0 24,
3.3.3.3 32
end-list

xpl route-filter CLIENTE-XPTO-IMPORT
if ip route-destination in CLIENTE-XPTO then
apply local-preference 900
else
apply local-preference 500
endif
end-filter
* '''Exemplo 2''': criar uma as-path access-list com as rotas recebidas do AS 65501, as rotas que passaram pelo AS 65502, e as rotas que foram originadas pelo AS 65503. Criar um filtro que negue as rotas recebidas do AS65501, as rotas que passaram pelo AS 65502, e as rotas que foram originadas pelo AS 65503:
xpl as-path-list AS_PATH-NEGAR-XYZ
regular ^65501_,
regular _65502_,
regular _65503$
end-list

xpl route-filter NEGAR-XYZ
if as-path in AS_PATH-NEGAR-XYZ then
refuse
else
approve
endif
end-filter
* '''Exemplo 3:''' criar uma prefix-list e uma as-path access list para o cliente de trânsito AS65510-192.0.2.0/24. Criar um filtro que valide e aceite as rotas recebidas e o as-path do cliente, e marque-os com a community de trânsito para os upstreams.
xpl as-path-list AS65510-TRANSIT-ASPATH
regular _65510$
end-list

xpl ip-prefix-list AS65510-IPV4-NETS
192.0.2.0 24
end-list

xpl route-filter CUSTOMER-AS65510-IPV4-IMPORT
if ( ip route-destination in AS65510-IPV4-NETS ) and (as-path in AS65510-TRANSIT-ASPATH) then
apply community COMM-ALL-TRANSIT-CUSTOMERS additive
approve
endif
end-filter
* '''Exemplo 4''': criar um filtro de RTBH para o AS65400. Toda vez que receber um prefixo IPv4 /31-/32 do cliente BGP AS65510-192.0.2.0/24, alterar o ''next-hop'' para 192.0.2.1 e marcar o prefixo também como blackhole para os upstreams e IXPs. Os demais prefixos devem ser aceitos e marcados com a community de trânsito para os upstreams, ''Local-Preference'' 600 e ''MED'' 0.
xpl community-list COMM-SET-BLACKHOLE
65400:666
end-list

xpl as-path-list AS65510-TRANSIT-ASPATH
regular _65510$
end-list

xpl ip-prefix-list AS65510-IPV4-NETS
192.0.2.0 24 le 32
end-list

xpl route-filter BGP-IPV4-CUSTOMER
if ( community matches-within COMM-SET-BLACKHOLE ) and (ip route-destination in {0.0.0.0 0 ge 31 le 32} ) then
apply ip next-hop 192.0.2.1
apply community COMM-SET-BLACKHOLE-UPSTREAM-XYZ additive
approve
endif
if (ip route-destination in {0.0.0.0 0 le 24} ) then
apply community COMM-ALL-TRANSIT-CUSTOMERS additive
apply local-preference 600
apply med 0
finish
endif
end-filter

xpl route-filter CUSTOMER-AS65510-IPV4-IMPORT
if ( ip route-destination in AS65510-IPV4-NETS ) and (as-path in AS65510-TRANSIT-ASPATH) then
call route-filter BGP-IPV4-CUSTOMER
approve
endif
end-filter

### CUSTOMER BGP CONFIG
bgp 65400
peer 100.64.0.2 as-number 65510
peer 100.64.0.2 description "CLIENTE DE TRANSITO ACME - AS#65510"
#
ipv4-family unicast
peer 100.64.0.2 enable
peer 100.64.0.2 '''route-filter''' CUSTOMER-AS65510-IPV4-IMPORT import
#

=== Conclusão ===
Este artigo descreveu os elementos básicos da XPL e como utilizá-la para construir filtros mais robustos para o seu roteador de borda/trânsito. A curva de aprendizagem da linguagem é muito baixa, e os benefícios de sua utilização são imediatos. Quem já teve experiência com JunOS ou IOS-XR deve ter percebido as inúmeras semelhanças entre a XPL e as linguagens disponibilizadas por essas plataformas.

A configuração de exemplo demonstrada foi testada e validada em laboratório utilizando um roteador Huawei '''''NE40-M2K-B'''''. No entanto a documentação da Huawei cita também o suporte para o modelo NE20 (veja seção de referências). Para a linha de switches Huawei S6720/S6730 aparentemente o XPL ainda não é suportado (i.e., até a data de publicação desse artigo não encontrei nenhuma referência na documentação oficial).

Ainda sobre a configuração, há que se destacar que quando construímos um filtro usando a linguagem XPL a aplicação da mesma no peer ''BGP'' utiliza palavra-chave "''route-filter''", ao passo que um filtro "convencional/não XPL" utiliza a palavra-chave "''route-policy''".

Por fim, como se pode ver nos exemplos utilizando XPL é possível expressar de maneira clara e objetiva a política de roteamento adotada localmente. O uso da XPL abre uma outra possibilidade interessante que é a automação da construção/manutenção de listas de prefixos, as-path acl's e route-filters utilizando fontes externas de dados. No próximo artigo eu farei a cobertura dessa componente de automação utilizando o bgpq3, alguns scripts em Python e mais algumas outras opções de código aberto disponíveis na Internet. Espero que tenham gostado, e fiquem à vontade para contribuir com mais informações aqui no artigo!

=== Referências: ===
# [https://support.huawei.com/enterprise/en/doc/EDOC1100028526?section=j07v&topicName=overview NE40E V800R010C00 Configuration Guide - IP Routing 01 / XPL configuration overview]
# [https://support.huawei.com/enterprise/en/doc/EDOC1100092920/9fbe9d4b/overview-of-xpl NE20E-S V800R011C00 Feature Description - IP Routing 01]

Configuracao de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei

2019-12-15T21:21:04Z

Humbertogaliza:

'''Autor:''' [[Humberto Galiza]]

=== Introdução ===
<blockquote>''Huawei é o novo "bacon" dos provedores de Internet brasileiros. (Operador de rede desconhecido.)''</blockquote>O tema desse breve artigo é explicar um pouco sobre como a linguagem extendida de política de roteamento (em Inglês, Extended Routing Policy Language - XPL) da Huawei pode ajudar a construir uma política de roteamento BGP "robusta" e em ''compliance'' com as melhores práticas de filtragem/segurança na Internet (como o MANRS por exemplo).

=== Definição do problema/motivação ===
Há alguns dias atrás um colega me fez a seguinte pergunta: <blockquote>"Há alguma maneira de otimizar as configurações de filtragens de prefixos usando Huawei como roteador de borda/trânsito? Esclarecendo um pouco mais, eu sempre construi os filtros usando duas ''prefix-lists'' (quatro considerando IPv6) para cada ASN de origem que estivesse no cone do downstream que eu estou filtrando. Porém, a coisa tá ficando grande...difícil de escalar. Tem uma receita mágica para isso?"</blockquote>Exemplo de prefix-list do problema em questão:
* '''BGP_ASXYZ-v4''' - Geralmente contendo os prefixos registrados no IRR como origem daquele ASN
* '''BGP_ASXYZ-v4_BH''' - Mesma coisa da anterior, mas mudando o "LE" (menor ou igual) "GE" (maior ou igual) pra 32, e dando match combinado com community de blackhole
Explicando um pouco mais, o raciocínio do colega é baseado na utilização de uma ''route-policy'' para cada cliente de trânsito. Uma cláusula "''if-match''" nessa route-policy tentará fazer o casamento para cada uma das "''prefix-lists''" listadas acima e eventualmente fará um "''apply''" com alguma ação a ser aplicada quando ocorrer esse casamento:
route-policy ''CLIENTE-XPTO'' permit ''10''
if-match BGP_ASXYZ-v4
apply "ACAO1_XYZ"
route-policy ''CLIENTE-XPTO'' permit ''20''
if-match BGP_ASXYZ-v4_BH
if-match community-filter COMM-RTBH
apply "ACAO2_XYZ_BH"
Como se pode notar há uma duplicidade (redundância) de informações: duas prefix-list com os mesmos prefixos sendo a única diferença entre elas o tamanho do bloco. Além disso, vale lembrar que nos equipamentos da Huawei só conseguiremos aplicar uma ''route-policy'' por peer BGP (quem já trabalha com JunOS, cujo tem a possibilidade de usar policies encadeadas sequencialmente, isso é um balde de água fria :-( ).

Essa inflexibilidade da ''route-policy'' limita bastante a possibilidade de se construir uma política de roteamento mais robusta. Exemplos de casos de uso mais complexos incluem (mas não se limitam a) a marcação de communities condicionais para engenharia de tráfego (ex: aumentar/diminuir o Local-Pref/MED, as-path prepend) e também o Remote Triggered Blackhole (RTBH), quando o cliente anuncia um prefixo específico (/32 IPv4 ou /128 IPv6 por exemplo) e deseja que o tráfego destinado àquele prefixo seja descartado. Portanto, trata-se aqui de uma situação comum nos ambientes de ISP que fornecem trânsito IP(v4/v6).

=== eXtended routing-Policy Language - XPL ===
De acordo com a própria documentação do fabricante a linguagem extendida de política de roteamento (XPL) serve exatamente para filtrar ou modificar atributos das rotas/prefixos aprendidos via BGP.

A XPL tem as mesmas funcionalidades das "route-policies", porém utiliza métodos de edição e filtragem completamente diferentes. Essa é a diferença chave que traz a flexibilidade necessária para a construção de políticas de roteamento mais robustas.

Além dos operadores já bem conhecidos das route-policy, a XPL traz também os seguintes blocos fundamentais:
* Início/fim de bloco: demarca o início/fim de um bloco de configuração. Exemplos:
{| class="wikitable"
|+
!Início
!Fim
|-
|'''xpl global-value''': início da seção de variáveis globais.
|'''end-global-value''': final da seção de variáveis globais.
|-
|'''xpl ip-prefix-list''' ''ip-prefix-list-name'': início de uma lista de prefixos IPv4
|'''end-list''': final de uma lista de prefixos IPv4
|-
|'''xpl community-list''' ''community-list-name'': início de uma lista de community
|'''end-list''': final de uma lista de community
|-
|'''xpl route-filter''' ''route-filter-name'': início de um route-filter
|'''end-filter''': final de um route-filter
|}
* Operadores lógicos: indica relacionamentos lógicos. Exemplos:
** '''eq/ge/le''': igual a/maior ou igual a/menor ou igual a
** '''in''': incluso/presente conjunto
** '''if''': "se"/inicia um bloco condicional de comparação
** '''elseif''': "senão-se"/ condicional de comparação
** '''else''': "senão"/ condicional de comparação
** '''then''': "então"/ usada no formato '''if'''+<condição/critério>+'''then''' or '''elseif'''+<condição/critério>+'''then'''.
** '''apply''': "ação" que será implementada caso haja o casamento da <condição/critério> avaliado.
** '''endif''': "fim-se"/encerra o bloco condicional de comparação.
* Elementos de <condição/critério>: são as condições a serem "casadas" no route-filter.
A lista acima é apenas para dar ao leitor um "norte" a respeito dos blocos básicos, operadores lógicos e elementos de comparação e ações suportadas pela XPL. Uma consulta a documentação oficial (ver a seção de referências) é extremamente encorajada.

=== Exemplos práticos com XPL ===
* '''Exemplo 1''': criar uma lista de prefixos com as rotas 1.1.1.0/24, 2.2.2.0/24, e 3.3.3.3/32. Criar um filtro que aplique um valor de 900 para o local-preference para esses prefixos, e 500 caso contrário:
xpl ip-prefix-list CLIENTE-XPTO
1.1.1.0 24,
2.2.2.0 24,
3.3.3.3 32
end-list

xpl route-filter CLIENTE-XPTO-IMPORT
if ip route-destination in CLIENTE-XPTO then
apply local-preference 900
else
apply local-preference 500
endif
end-filter
* '''Exemplo 2''': criar uma as-path access-list com as rotas recebidas do AS 65501, as rotas que passaram pelo AS 65502, e as rotas que foram originadas pelo AS 65503. Criar um filtro que negue as rotas recebidas do AS65501, as rotas que passaram pelo AS 65502, e as rotas que foram originadas pelo AS 65503:
xpl as-path-list AS_PATH-NEGAR-XYZ
regular ^65501_,
regular _65502_,
regular _65503$
end-list

xpl route-filter NEGAR-XYZ
if as-path in AS_PATH-NEGAR-XYZ then
refuse
else
approve
endif
end-filter
* '''Exemplo 3:''' criar uma prefix-list e uma as-path access list para o cliente de trânsito AS65510-192.0.2.0/24. Criar um filtro que valide e aceite as rotas recebidas e o as-path do cliente, e marque-os com a community de trânsito para os upstreams.
xpl as-path-list AS65510-TRANSIT-ASPATH
regular _65510$
end-list

xpl ip-prefix-list AS65510-IPV4-NETS
192.0.2.0 24
end-list

xpl route-filter CUSTOMER-AS65510-IPV4-IMPORT
if ( ip route-destination in AS65510-IPV4-NETS ) and (as-path in AS65510-TRANSIT-ASPATH) then
apply community COMM-ALL-TRANSIT-CUSTOMERS additive
approve
endif
end-filter
* '''Exemplo 4''': criar um filtro de RTBH para o AS65400. Toda vez que receber um prefixo IPv4 /31-/32 do cliente BGP AS65510-192.0.2.0/24, alterar o ''next-hop'' para 192.0.2.1 e marcar o prefixo também como blackhole para os upstreams e IXPs. Os demais prefixos devem ser aceitos e marcados com a community de trânsito para os upstreams, ''Local-Preference'' 600 e ''MED'' 0.
xpl community-list COMM-SET-BLACKHOLE
52720:666
end-list

xpl as-path-list AS65510-TRANSIT-ASPATH
regular _65510$
end-list

xpl ip-prefix-list AS65510-IPV4-NETS
192.0.2.0 24 le 32
end-list

xpl route-filter BGP-IPV4-CUSTOMER
if ( community matches-within COMM-SET-BLACKHOLE ) and (ip route-destination in {0.0.0.0 0 ge 31 le 32} ) then
apply ip next-hop 192.0.2.1
apply community COMM-SET-BLACKHOLE-UPSTREAM-XYZ additive
approve
endif
if (ip route-destination in {0.0.0.0 0 le 24} ) then
apply community COMM-ALL-TRANSIT-CUSTOMERS additive
apply local-preference 600
apply med 0
finish
endif
end-filter

xpl route-filter CUSTOMER-AS65510-IPV4-IMPORT
if ( ip route-destination in AS65510-IPV4-NETS ) and (as-path in AS65510-TRANSIT-ASPATH) then
call route-filter BGP-IPV4-CUSTOMER
approve
endif
end-filter

### CUSTOMER BGP CONFIG
bgp 65400
peer 100.64.0.2 as-number 65510
peer 100.64.0.2 description "CLIENTE DE TRANSITO ACME - AS#65510"
#
ipv4-family unicast
peer 100.64.0.2 enable
peer 100.64.0.2 '''route-filter''' CUSTOMER-AS65510-IPV4-IMPORT import
#

=== Conclusão ===
Este artigo descreveu os elementos básicos da XPL e como utiliza-la para construir filtros mais robustos para o seu roteador de borda/trânsito. A curva de aprendizagem da linguagem é muito baixa, e os benefícios de sua utilização são imediatos. Quem já teve experiência com JunOS ou IOS-XR deve ter percebido as inúmeras semelhanças entre a XPL e as linguagens disponibilizadas por essas plataformas.

Como se pode ver nos exemplos, utilizando XPL é possível expressar de maneira clara e objetiva a política de roteamento adotada localmente. O uso da XPL abre uma outra possibilidade interessante que é a automação da construção/manutenção de listas de prefixos, as-path acl's e route-filters utilizando fontes externas de dados. No próximo artigo eu farei a cobertura dessa componente de automação utilzando o bgpq3, alguns scripts em Python e mais algumas outras opções de código aberto disponíveis na Internet. Espero que tenham gostado, e fiquem à vontade para contribuir com mais informações aqui no artigo!

=== Referências: ===
# [https://support.huawei.com/enterprise/en/doc/EDOC1100028526?section=j07v&topicName=overview NE40E V800R010C00 Configuration Guide - IP Routing 01 / XPL configuration overview]

Configuracao de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei

2019-12-15T21:14:05Z

Humbertogaliza: /* Introdução */

'''Autor:''' [[Humberto Galiza]]

=== Introdução ===
<blockquote>''Huawei é o novo "bacon" dos provedores de Internet brasileiros. (Operador de rede desconhecido.)''</blockquote>O tema desse breve artigo é explicar um pouco sobre como a linguagem extendida de política de roteamento (em Inglês, Extended Routing Policy Language - XPL) da Huawei pode ajudar a construir uma política de roteamento BGP "robusta" e em ''compliance'' com as melhores práticas de filtragem/segurança na Internet (como o MANRS por exemplo).

=== Definição do problema/motivação ===
Há alguns dias atrás um colega me fez a seguinte pergunta: <blockquote>"Há alguma maneira de otimizar as configurações de filtragens de prefixos usando Huawei como roteador de borda/trânsito? Esclarecendo um pouco mais, eu sempre construi os filtros usando duas ''prefix-lists'' (quatro considerando IPv6) para cada ASN de origem que estivesse no cone do downstream que eu estou filtrando. Porém, a coisa tá ficando grande...difícil de escalar. Tem uma receita mágica para isso?"</blockquote>Exemplo de prefix-list do problema em questão:
* '''BGP_ASXYZ-v4''' - Geralmente contendo os prefixos registrados no IRR como origem daquele ASN
* '''BGP_ASXYZ-v4_BH''' - Mesma coisa da anterior, mas mudando o "LE" (menor ou igual) "GE" (maior ou igual) pra 32, e dando match combinado com community de blackhole
Explicando um pouco mais, o raciocínio do colega é baseado na utilização de uma ''route-policy'' para cada cliente de trânsito. Uma cláusula "''if-match''" nessa route-policy tentará fazer o casamento para cada uma das "''prefix-lists''" listadas acima e eventualmente fará um "''apply''" com alguma ação a ser aplicada quando ocorrer esse casamento:
route-policy ''CLIENTE-XPTO'' permit ''10''
if-match BGP_ASXYZ-v4
apply "ACAO1_XYZ"
route-policy ''CLIENTE-XPTO'' permit ''20''
if-match BGP_ASXYZ-v4_BH
if-match community-filter COMM-RTBH
apply "ACAO2_XYZ_BH"
Como se pode notar há uma duplicidade (redundância) de informações: duas prefix-list com os mesmos prefixos sendo a única diferença entre elas o tamanho do bloco. Além disso, vale lembrar que nos equipamentos da Huawei só conseguiremos aplicar uma ''route-policy'' por peer BGP (quem já trabalha com JunOS, cujo tem a possibilidade de usar policies encadeadas sequencialmente, isso é um balde de água fria :-( ).

Essa inflexibilidade da ''route-policy'' limita bastante a possibilidade de se construir uma política de roteamento mais robusta. Exemplos de casos de uso mais complexos incluem (mas não se limitam a) a marcação de communities condicionais para engenharia de tráfego (ex: aumentar/diminuir o Local-Pref/MED, as-path prepend) e também o Remote Triggered Blackhole (RTBH), quando o cliente anuncia um prefixo específico (/32 IPv4 ou /128 IPv6 por exemplo) e deseja que o tráfego destinado àquele prefixo seja descartado. Portanto, trata-se aqui de uma situação comum nos ambientes de ISP que fornecem trânsito IP(v4/v6).

=== eXtended routing-Policy Language - XPL ===
De acordo com a própria documentação do fabricante a linguagem extendida de política de roteamento (XPL) serve exatamente para filtrar ou modificar atributos das rotas/prefixos aprendidos via BGP.

A XPL tem as mesmas funcionalidades das "route-policies", porém utiliza métodos de edição e filtragem completamente diferentes. Essa é a diferença chave que traz a flexibilidade necessária para a construção de políticas de roteamento mais robustas.

Além dos operadores já bem conhecidos das route-policy, a XPL traz também os seguintes blocos fundamentais:
* Início/fim de bloco: demarca o início/fim de um bloco de configuração. Exemplos:
{| class="wikitable"
|+
!Início
!Fim
|-
|'''xpl global-value''': início da seção de variáveis globais.
|'''end-global-value''': final da seção de variáveis globais.
|-
|'''xpl ip-prefix-list''' ''ip-prefix-list-name'': início de uma lista de prefixos IPv4
|'''end-list''': final de uma lista de prefixos IPv4
|-
|'''xpl community-list''' ''community-list-name'': início de uma lista de community
|'''end-list''': final de uma lista de community
|-
|'''xpl route-filter''' ''route-filter-name'': início de um route-filter
|'''end-filter''': final de um route-filter
|}
* Operadores lógicos: indica relacionamentos lógicos. Exemplos:
** '''eq/ge/le''': igual a/maior ou igual a/menor ou igual a
** '''in''': incluso/presente conjunto
** '''if''': "se"/inicia um bloco condicional de comparação
** '''elseif''': "senão-se"/ condicional de comparação
** '''else''': "senão"/ condicional de comparação
** '''then''': "então"/ usada no formato '''if'''+<condição/critério>+'''then''' or '''elseif'''+<condição/critério>+'''then'''.
** '''apply''': "ação" que será implementada caso haja o casamento da <condição/critério> avaliado.
** '''endif''': "fim-se"/encerra o bloco condicional de comparação.
* Elementos de <condição/critério>: são as condições a serem "casadas" no route-filter.
A lista acima é apenas para dar ao leitor um "norte" a respeito dos blocos básicos, operadores lógicos e elementos de comparação e ações suportadas pela XPL. Uma consulta a documentação oficial (ver a seção de referências) é extremamente encorajada.

=== Exemplos práticos com XPL ===
* '''Exemplo 1''': criar uma lista de prefixos com as rotas 1.1.1.0/24, 2.2.2.0/24, e 3.3.3.3/32. Criar um filtro que aplique um valor de 900 para o local-preference para esses prefixos, e 500 caso contrário:
xpl ip-prefix-list CLIENTE-XPTO
1.1.1.0 24,
2.2.2.0 24,
3.3.3.3 32
end-list

xpl route-filter CLIENTE-XPTO-IMPORT
if ip route-destination in CLIENTE-XPTO then
apply local-preference 900
else
apply local-preference 500
endif
end-filter
* '''Exemplo 2''': criar uma as-path access-list com as rotas recebidas do AS 65501, as rotas que passaram pelo AS 65502, e as rotas que foram originadas pelo AS 65503. Criar um filtro que negue as rotas recebidas do AS65501, as rotas que passaram pelo AS 65502, e as rotas que foram originadas pelo AS 65503:
xpl as-path-list AS_PATH-NEGAR-XYZ
regular ^65501_,
regular _65502_,
regular _65503$
end-list

xpl route-filter NEGAR-XYZ
if as-path in AS_PATH-NEGAR-XYZ then
refuse
else
approve
endif
end-filter
* '''Exemplo 3:''' criar uma prefix-list e uma as-path access list para o cliente de trânsito AS65510-192.0.2.0/24. Criar um filtro que valide e aceite as rotas recebidas e o as-path do cliente, e marque-os com a community de trânsito para os upstreams.
xpl as-path-list AS65510-TRANSIT-ASPATH
regular _65510$
end-list

xpl ip-prefix-list AS65510-IPV4-NETS
192.0.2.0 24
end-list

xpl route-filter CUSTOMER-AS65510-IPV4-IMPORT
if ( ip route-destination in AS65510-IPV4-NETS ) and (as-path in AS65510-TRANSIT-ASPATH) then
apply community COMM-ALL-TRANSIT-CUSTOMERS additive
approve
endif
end-filter
Exemplo 4: criar um filtro de RTBH para o AS65400. Toda vez que receber um prefixo IPv4 /31-/32 do cliente BGP AS65510-192.0.2.0/24, alterar o ''next-hop'' para 192.0.2.1 e marcar o prefixo também como blackhole para os upstreams e IXPs. Os demais prefixos devem ser aceitos e marcados com a community de trânsito para os upstreams, ''Local-Preference'' 600 e ''MED'' 0.
xpl community-list COMM-SET-BLACKHOLE
52720:666
end-list

xpl as-path-list AS65510-TRANSIT-ASPATH
regular _65510$
end-list

xpl ip-prefix-list AS65510-IPV4-NETS
192.0.2.0 24 le 32
end-list

xpl route-filter BGP-IPV4-CUSTOMER
if ( community matches-within COMM-SET-BLACKHOLE ) and (ip route-destination in {0.0.0.0 0 ge 31 le 32} ) then
apply ip next-hop 192.0.2.1
apply community COMM-SET-BLACKHOLE-UPSTREAM-XYZ additive
approve
endif
if (ip route-destination in {0.0.0.0 0 le 24} ) then
apply community COMM-ALL-TRANSIT-CUSTOMERS additive
apply local-preference 600
apply med 0
finish
endif
end-filter

xpl route-filter CUSTOMER-AS65510-IPV4-IMPORT
if ( ip route-destination in AS65510-IPV4-NETS ) and (as-path in AS65510-TRANSIT-ASPATH) then
call route-filter BGP-IPV4-CUSTOMER
approve
endif
end-filter

### CUSTOMER BGP CONFIG
bgp 65400
peer 100.64.0.2 as-number 65510
peer 100.64.0.2 description "CLIENTE DE TRANSITO ACME - AS#65510"
#
ipv4-family unicast
peer 100.64.0.2 enable
peer 100.64.0.2 '''route-filter''' CUSTOMER-AS65510-IPV4-IMPORT import
#

=== Conclusão ===
Este artigo descreveu os elementos básicos da XPL e como utiliza-la para construir filtros mais robustos para o seu roteador de borda/trânsito. A curva de aprendizagem da linguagem é muito baixa, e os benefícios de sua utilização são imediatos. Quem já teve experiência com JunOS ou IOS-XR deve ter percebido as inúmeras semelhanças entre a XPL e as linguagens disponibilizadas por essas plataformas.

Como se pode ver nos exemplos, utilizando XPL é possível expressar de maneira clara e objetiva a política de roteamento adotada localmente. O uso da XPL abre uma outra possibilidade interessante que é a automação da construção/manutenção de listas de prefixos, as-path acl's e route-filters utilizando fontes externas de dados. No próximo artigo eu farei a cobertura dessa componente de automação utilzando o bgpq3, alguns scripts em Python e mais algumas outras opções de código aberto disponíveis na Internet. Espero que tenham gostado, e fiquem à vontade para contribuir com mais informações aqui no artigo!

=== Referências: ===
# [https://support.huawei.com/enterprise/en/doc/EDOC1100028526?section=j07v&topicName=overview NE40E V800R010C00 Configuration Guide - IP Routing 01 / XPL configuration overview]

Configuracao de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei

2019-12-15T20:36:39Z

Humbertogaliza:

=== Introdução ===
<blockquote>''Huawei é o novo "bacon" dos provedores de Internet brasileiros. (Operador de rede desconhecido.)''</blockquote>O tema desse breve artigo é explicar um pouco sobre como a linguagem extendida de política de roteamento (em Inglês, Extended Routing Policy Language - XPL) da Huawei pode ajudar a construir uma política de roteamento BGP "robusta" e em ''compliance'' com as melhores práticas de filtragem/segurança na Internet (como o MANRS por exemplo).

=== Definição do problema/motivação ===
Há alguns dias atrás um colega me fez a seguinte pergunta: <blockquote>"Há alguma maneira de otimizar as configurações de filtragens de prefixos usando Huawei como roteador de borda/trânsito? Esclarecendo um pouco mais, eu sempre construi os filtros usando duas ''prefix-lists'' (quatro considerando IPv6) para cada ASN de origem que estivesse no cone do downstream que eu estou filtrando. Porém, a coisa tá ficando grande...difícil de escalar. Tem uma receita mágica para isso?"</blockquote>Exemplo de prefix-list do problema em questão:
* '''BGP_ASXYZ-v4''' - Geralmente contendo os prefixos registrados no IRR como origem daquele ASN
* '''BGP_ASXYZ-v4_BH''' - Mesma coisa da anterior, mas mudando o "LE" (menor ou igual) "GE" (maior ou igual) pra 32, e dando match combinado com community de blackhole
Explicando um pouco mais, o raciocínio do colega é baseado na utilização de uma ''route-policy'' para cada cliente de trânsito. Uma cláusula "''if-match''" nessa route-policy tentará fazer o casamento para cada uma das "''prefix-lists''" listadas acima e eventualmente fará um "''apply''" com alguma ação a ser aplicada quando ocorrer esse casamento:
route-policy ''CLIENTE-XPTO'' permit ''10''
if-match BGP_ASXYZ-v4
apply "ACAO1_XYZ"
route-policy ''CLIENTE-XPTO'' permit ''20''
if-match BGP_ASXYZ-v4_BH
if-match community-filter COMM-RTBH
apply "ACAO2_XYZ_BH"
Como se pode notar há uma duplicidade (redundância) de informações: duas prefix-list com os mesmos prefixos sendo a única diferença entre elas o tamanho do bloco. Além disso, vale lembrar que nos equipamentos da Huawei só conseguiremos aplicar uma ''route-policy'' por peer BGP (quem já trabalha com JunOS, cujo tem a possibilidade de usar policies encadeadas sequencialmente, isso é um balde de água fria :-( ).

Essa inflexibilidade da ''route-policy'' limita bastante a possibilidade de se construir uma política de roteamento mais robusta. Exemplos de casos de uso mais complexos incluem (mas não se limitam a) a marcação de communities condicionais para engenharia de tráfego (ex: aumentar/diminuir o Local-Pref/MED, as-path prepend) e também o Remote Triggered Blackhole (RTBH), quando o cliente anuncia um prefixo específico (/32 IPv4 ou /128 IPv6 por exemplo) e deseja que o tráfego destinado àquele prefixo seja descartado. Portanto, trata-se aqui de uma situação comum nos ambientes de ISP que fornecem trânsito IP(v4/v6).

=== eXtended routing-Policy Language - XPL ===
De acordo com a própria documentação do fabricante a linguagem extendida de política de roteamento (XPL) serve exatamente para filtrar ou modificar atributos das rotas/prefixos aprendidos via BGP.

A XPL tem as mesmas funcionalidades das "route-policies", porém utiliza métodos de edição e filtragem completamente diferentes. Essa é a diferença chave que traz a flexibilidade necessária para a construção de políticas de roteamento mais robustas.

Além dos operadores já bem conhecidos das route-policy, a XPL traz também os seguintes blocos fundamentais:
* Início/fim de bloco: demarca o início/fim de um bloco de configuração. Exemplos:
{| class="wikitable"
|+
!Início
!Fim
|-
|'''xpl global-value''': início da seção de variáveis globais.
|'''end-global-value''': final da seção de variáveis globais.
|-
|'''xpl ip-prefix-list''' ''ip-prefix-list-name'': início de uma lista de prefixos IPv4
|'''end-list''': final de uma lista de prefixos IPv4
|-
|'''xpl community-list''' ''community-list-name'': início de uma lista de community
|'''end-list''': final de uma lista de community
|-
|'''xpl route-filter''' ''route-filter-name'': início de um route-filter
|'''end-filter''': final de um route-filter
|}
* Operadores lógicos: indica relacionamentos lógicos. Exemplos:
** '''eq/ge/le''': igual a/maior ou igual a/menor ou igual a '''in''': incluso/presente conjunto '''if''': "se"/inicia um bloco condicional de comparação '''elseif''': "senão-se"/ condicional de comparação '''else''': "senão"/ condicional de comparação '''then''': "então"/ usada no formato '''if'''+<condição/critério>+'''then''' or '''elseif'''+<condição/critério>+'''then'''. '''apply''': "ação" que será implementada caso haja o casamento da <condição/critério> avaliado. '''endif''': "fim-se"/encerra o bloco condicional de comparação.
* Elementos de <condição/critério>: são as condições a serem "casadas" no route-filter.
A lista acima é apenas para dar ao leitor um "norte" a respeito dos blocos básicos, operadores lógicos e elementos de comparação e ações suportadas pela XPL. Uma consulta a documentação oficial (ver a seção de referências) é extremamente encorajada.

=== Exemplos práticos com XPL ===
* '''Exemplo 1''': criar uma lista de prefixos com as rotas 1.1.1.0/24, 2.2.2.0/24, e 3.3.3.3/32. Criar um filtro que aplique um valor de 900 para o local-preference para esses prefixos, e 500 caso contrário:
xpl ip-prefix-list CLIENTE-XPTO
1.1.1.0 24,
2.2.2.0 24,
3.3.3.3 32
end-list

xpl route-filter CLIENTE-XPTO-IMPORT
if ip route-destination in CLIENTE-XPTO then
apply local-preference 900
else
apply local-preference 500
endif
end-filter
* '''Exemplo 2''': criar uma AS-PATH access-list com as rotas recebidas do AS 65501, as rotas que passaram pelo AS 65502, e as rotas que foram originadas pelo AS 65503. Criar um filtro que negue as rotas recebidas do AS65501, as rotas que passaram pelo AS 65502, e as rotas que foram originadas pelo AS 65503:
xpl as-path-list AS_PATH-NEGAR-XYZ
regular ^65501_,
regular _65502_,
regular _65503$
end-list

xpl route-filter NEGAR-XYZ
if as-path in AS_PATH-NEGAR-XYZ then
refuse
else
approve
endif
end-filter

Configuracao de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei

2019-12-15T15:14:13Z

Humbertogaliza: Iniciando o artigo

Humberto Galiza

2019-05-26T21:47:24Z

Humbertogaliza:

[[Arquivo:Foto amazon.jpg|miniaturadaimagem|200x200px]]
* É Bacharel em Ciência da Computação pela Universidade Federal da Bahia - UFBA (2009) e Pós-graduado em Informática pela Escola de Administração do Exército - EsAEx (2010).
* Possui algumas certificações profissionais dos principais fabricantes da área de Redes/Service Provider, além de habilidades com sistemas *nix, scripting e programação voltada para a área de redes.
* Desde ~2005 tem ajudado a projetar, implantar, interconectar e operar redes das mais variadas escalas, natureza e complexidade no Brasil e ao redor do mundo.
* Tem interesse nos temas engenharia de tráfego IP/MPLS, Roteamento BGP/Peering/Interconexão, Pontos de Troca de Tráfego, Redes Definidas por Software, Automação de Redes, além do desenvolvimento e padronização para a Internet.
* Atua como Chair Comitê de Programa (CP) do Brasil Peering Forum (BPF).
* Atua como Co-Chair da Task Force de Software-Defined Networking (SDN) do BPF.

=== '''Contato''' ===
'''LinkedIn:''' https://www.linkedin.com/in/humbertogaliza<nowiki/>/

'''E-mail pessoal:''' humbertogaliza[.at.]gmail.com

Humberto Galiza

2019-05-26T21:43:17Z

Humbertogaliza: Criou página com '200x200px * É Bacharel em Ciência da Computação pela Universidade Federal da Bahia - UFBA (2009) e Pós-graduado em Informát...'

[[Arquivo:Foto amazon.jpg|miniaturadaimagem|200x200px]]
* É Bacharel em Ciência da Computação pela Universidade Federal da Bahia - UFBA (2009) e Pós-graduado em Informática pela Escola de Administração do Exército - EsAEx (2010).
* Possui algumas certificações profissionais dos principais fabricantes da área de Redes/Service Provider, além de habilidades com sistemas *nix, scripting e programação voltada para a área de redes.
* Desde ~2005 tem ajudado a projetar, implantar, interconectar e operar redes das mais variadas escalas, natureza e complexidade no Brasil e ao redor do mundo.
* Tem interesse nos temas engenharia de tráfego IP/MPLS, Roteamento BGP/Peering/Interconexão, Pontos de Troca de Tráfego, Redes Definidas por Software, Automação de Redes, além do desenvolvimento e padronização para a Internet.
* Atua como Chair Comitê de Programa (CP) do Brasil Peering Forum (BPF).
* Atua como Co-Chair da Task Force de Software-Defined Networking (SDN) do Brasil Peering Forum.

=== '''Contato''' ===
'''LinkedIn:''' https://www.linkedin.com/in/humbertogaliza<nowiki/>/

'''E-mail pessoal:''' humbertogaliza[.at.]gmail.com

Arquivo:Foto amazon.jpg

2019-05-26T21:38:27Z

Humbertogaliza:

Humberto Galiza

Arquivo:Foto amazon.jpg

2019-05-26T20:55:47Z

Humbertogaliza:

Diferenca entre AS-OVERRIDE e ALLOWAS-IN

2019-05-26T20:15:05Z

Humbertogaliza:

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

Diferenca entre AS-OVERRIDE e ALLOWAS-IN

2019-05-26T11:22:57Z

Humbertogaliza:

== 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.[[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 0.0.0.0 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]]

Diferenca entre AS-OVERRIDE e ALLOWAS-IN

2019-05-26T11:10:36Z

Humbertogaliza:

== 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.[[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 0.0.0.0 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'''
É possível a configuração do AS-OVERRIDE em cenários com operadoras

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

Arquivo:Bpf as override allowas in 2.png

2019-05-26T11:05:46Z

Humbertogaliza:

as-override atualizado

Arquivo:Bpf as override allowas in.png

2019-05-26T10:44:10Z

Humbertogaliza:

AS-OVERRIDE_CENARIO2

Arquivo:AS-OVERRIDE CENARIO2.png

2019-05-26T10:43:19Z

Humbertogaliza:

AS-OVERRIDE CENARIO REDE MPLS

Diferenca entre AS-OVERRIDE e ALLOWAS-IN

2019-05-26T08:48:01Z

Humbertogaliza:

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

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 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 ====
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:

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

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

Diferenca entre AS-OVERRIDE e ALLOWAS-IN

2019-05-26T08:40:33Z

Humbertogaliza:

=== 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 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 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 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):
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 ====
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:

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

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

Diferenca entre AS-OVERRIDE e ALLOWAS-IN

2019-05-25T13:40:07Z

Humbertogaliza:

=== 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:

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:

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

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