Como funciona o traffic policy no Huawei

Introdução

O Traffic Policy dos switchs e roteadores Huawei tem a função de aplicar políticas de tráfego, como o próprio nome já diz. Além de permitir o roteamento baseado em políticas (PBR), outros artifícios como o descarte ou rate-limit de tráfego também podem ser aplicados com este recurso.

O objetivo deste artigo não é esgotar o assunto, não é substituir a documentação oficial e tampouco dirimir todas as dúvidas. O único objetivo deste artigo é ajudar a comunidade a compreender melhor a lógica do traffic policy.

Existe uma chance de você ter chegado neste artigo pesquisando sobre "como fazer PBR em Huawei para CGNAT" ou tentando descobrir como direcionar o tráfego de clientes sem IP público para uma caixa que faça CGNAT, e caso seja este o teu caso, este artigo te ajudará a entender como isto funciona.

Um exemplo de PBR para CGNAT explicado

Suponhamos aqui que temos um cenário composto um BNG diretamente ligado à um roteador ou switch de camada 3 Huawei (fazendo a função de roteador para este cenário). Este equipamento Huawei possui uma interface diretamente conectada à borda do ISP e outra interface diretamente conectada à um NAT Server. Este NAT Server possui outra interface diretamente conectada também à borda do ISP. Veja abaixo um diagrama que exemplifica este cenário.

Exemplo de cenário

Poderíamos ter o NAT Server diretamente conectado ao BNG, de forma com que todo o tráfego de clientes com IPv4 públicos, IPv4 privados e IPv6 passassem pelo CGNAT, sem a necessidade do roteador Huawei entre os dois equipamentos, e consequentemente sem a necessidade do PBR. Entretanto isto traria dois problemas:

1) Aumento de custos: supondo que a rede tenha um tráfego total de 20 Gbps, onde 10 Gbps é de clientes com CGNAT, 5 Gbps de clientes com IPv6 e 5 Gbps de clientes com IPv4 público, você precisaria ter uma caixa de NAT Server com a capacidade de 20 Gbps tráfego, e não apenas 10. Neste exemplo, você necessitaria ter um gasto literalmente dobrado com equipamento para CGNAT. Onde poderia ser uma caixa de 10 Gbps, teria que ser uma caixa de 20 Gbps.

2) Ultra dependência do NAT Server: no caso de uma falha na caixa de NAT Server, todos os clientes (incluindo os que tem IPv6, IPv4 público e clientes ASNs) ficariam fora do ar, e não apenas os clientes com CGNAT.

Sendo assim, entendemos que no cenário do exemplo acima e em alguns outros, redirecionar para o NAT Server seletivamente apenas o tráfego originado por IPs contidos na rede 100.64.0.0/10 (CGNAT, RFC 6598) seja a melhor opção. E aqui iremos explicar como fazê-lo.

Considere que este ISP possua a rede pública 192.0.2.0/24. Considere também que este equipamento Huawei seja um NE20, NE40 ou NE8000.

Neste cenário nós iremos mostrar como direcionar todo o tráfego originado por IPs da rede 100.64.0.0/10 para o IP 172.20.0.2, exceto quando o destino for 192.0.2.0/24 (nossa rede pública de exemplo), outros IPs de CGNAT (100.64.0.0/10), e IPs privados da RFC1918 (192.168.0.0/16, 172.16.0.0/12 e 10.0.0.0/8).

acl number 3001

rule 5 permit ip source 100.64.0.0 0.63.255.255

acl number 3002

rule 5 permit ip destination 100.64.0.0 0.63.255.255

rule 10 permit ip destination 192.0.2.0 0.0.0.255

rule 15 permit ip destination 10.0.0.0 0.255.255.255

rule 20 permit ip destination 172.16.0.0 0.15.255.255

rule 25 permit ip destination 192.168.0.0 0.0.255.255

#

traffic classifier C-CGNAT-DstExceptions operator or

if-match acl 3002

traffic classifier C-CGNAT-ToBeNated operator or

if-match acl 3001

#

traffic behavior B-CGNATBypass

permit

traffic behavior B-ToBeNATED

redirect ip-nexthop 172.20.0.2

#

traffic policy P-CGNAT

classifier C-CGNAT-DstExceptions behavior B-CGNATBypass

classifier C-CGNAT-ToBeNated behavior B-ToBeNATED

traffic-policy P-CGNAT inbound global-acl

Explicação passo-a-passo

O traffic policy do Huawei é uma espécie de quebra cabeça, onde diversas peças, quando juntadas, formam a política que desejamos. Portanto é natural que você não compreenda com total clareza cada um dos componentes até que tenha finalizado a leitura desta seção do artigo. Caso tenha dificuldade em entender mesmo após ler toda a explicação passo-a-passo, tente ler os itens de trás para frente.

acl number 3001

rule 5 permit ip source 100.64.0.0 0.63.255.255

Esta ACL serve apenas para citar a rede 100.64.0.0/10. Aqui estamos dando match em todo tráfego cuja origem (source) seja 100.64.0.0.10. A máscara aqui está citada no formado Wildcard. No caso o /10 é escrito como "0.63.255.255". Mais pra frente esta ACL será citada por seu número 3001.

acl number 3002

rule 5 permit ip destination 100.64.0.0 0.63.255.255

rule 10 permit ip destination 192.0.2.0 0.0.0.255

rule 15 permit ip destination 10.0.0.0 0.255.255.255

rule 20 permit ip destination 172.16.0.0 0.15.255.255

rule 25 permit ip destination 192.168.0.0 0.0.255.255

Esta ACL serve apenas para citar as redes 100.64.0.0/10, 192.0.2.0/24, 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16. Aqui estamos dando match em todo tráfego cujo destino (destination) seja alguma destas redes. Assim como na ACL anterior de número 3001, as máscaras estão sendo citadas no formato wildcard.

traffic classifier C-CGNAT-ToBeNated operator and

if-match acl 3001

Como o Huawei nos permite uma grande modularidade e aninhamento de condições, nós usamos o "traffic classifier". Este classifier poderia conter um ou mais critérios, mas neste caso temos apenas uma única condição: dar match na ACL 3001, que cita IPs pertencentes à rede 100.64.0.0/10. Como ficará claro mais pra frente, o objetivo deste classifier é agrupar todos os critérios que eu quero sejam satisfeitos para que o tráfego seja redirecionado para o NAT Server.

traffic classifier C-CGNAT-DstExceptions operator and

if-match acl 3002

O objetivo deste traffic classifier é determinar quais redes de destino não deverão ter seu tráfego redirecionado, e no caso são todas as redes que criamos na ACL de número 3002. Para fins didáticos, tratemos este traffic classifier como uma exceção do que não queremos que seja redirecionado para o NAT Server.