Mudanças entre as edições de "Configuracao de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei"
(Iniciando o artigo) |
|||
Linha 2: | Linha 2: | ||
<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). | <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 === | + | === 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 | + | 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''' - 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 | + | * '''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. | + | 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. | ||
− | Essa é | + | 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 |
Edição das 17h36min de 15 de dezembro de 2019
Índice
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/motivação
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 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:
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