Exibir código-fonte para Configuracao de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei

'''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 '''<u>route-filter</u>''' 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 "''<u>route-filter</u>''", ao passo que um filtro "convencional/não XPL" utiliza a palavra-chave "''<u>route-policy</u>''". 

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]
[[Categoria:Roteamento]]