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

De Wiki BPF
Revisão de 12h14min de 15 de dezembro de 2019 por Humbertogaliza (discussão | contribs) (Iniciando o artigo)
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)
Ir para: navegação, pesquisa

Introdução

Huawei é o novo "bacon" dos provedores de Internet brasileiros. (Operador de rede desconhecido.)

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

Há alguns dias atrás um colega me fez a seguinte pergunta:

"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?"

Exemplo do de prefix-list com do problema/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.

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.

Para quem já trabalha com JunOS, cujo tem a possibilidade de usar policies encadeadas sequencialmente, é um balde de água fria. de uma inflexibilidade da própria route-policy: o que limita bastante a possibilidade de se construir uma política de roteamento mais robusta. Exemplos de casos de uso mais complexos incluem: a marcação de communities condicionais para engenharia de tráfego (aumento

Essa é certamente uma situação comum nos ambientes de ISP que fornecem trânsito IP(v4/v6) e que utilizam as "route-policy" do Huawei para aplicar filtros para engenharia de tráfego dos clientes.