Mudanças entre as edições de "Como funciona o traffic policy no Huawei"
| (4 revisões intermediárias por 2 usuários não estão sendo mostradas) | |||
| Linha 1: | Linha 1: | ||
| − | |||
| − | |||
=== Introdução === | === 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 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 (Policy Based Routing - 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. | 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. | ||
| Linha 9: | Linha 7: | ||
=== Um exemplo de PBR para CGNAT explicado === | === 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 | + | Suponhamos aqui que temos um cenário composto por 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 servidor de CGNAT. Este equipamento possui outra interface diretamente conectada também à borda do ISP. Veja abaixo um diagrama que exemplifica este cenário. |
[[Arquivo:ComoFuncionaOTrafficPolicyNoHuawei2.png|alt=Exemplo de cenário|centro|miniaturadaimagem|500x500px|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: | [[Arquivo:ComoFuncionaOTrafficPolicyNoHuawei2.png|alt=Exemplo de cenário|centro|miniaturadaimagem|500x500px|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 | + | '''1) Aumento de custos:''' supondo que a rede tenha um tráfego total de 20 Gbps, onde 10 Gbps são 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. | '''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. | ||
| Linha 22: | Linha 20: | ||
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). | 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). | ||
| + | <pre> | ||
| + | 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 | ||
| + | </pre> | ||
| − | < | + | <pre> |
| − | + | traffic classifier C-CGNAT-ToBeNated operator or | |
| − | + | if-match acl 3001 | |
| − | + | traffic classifier C-CGNAT-DstExceptions operator or | |
| − | + | if-match acl 3002 | |
| − | + | </pre> | |
| − | |||
| − | < | + | <pre> |
| + | traffic behavior B-CGNATBypass | ||
| + | permit | ||
| + | traffic behavior B-ToBeNATED | ||
| + | redirect ip-nexthop 172.20.0.2 | ||
| + | </pre> | ||
| − | < | + | <pre> |
| − | + | 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 | |
| − | + | </pre> | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==== Explicação passo-a-passo ==== | ==== 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. | 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. | ||
| − | + | <pre> | |
| − | < | + | acl number 3001 |
| − | + | rule 5 permit ip source 100.64.0.0 0.63.255.255 | |
| − | + | </pre> | |
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. | 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. | ||
| − | < | + | <pre> |
| − | + | 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 | |
| − | + | </pre> | |
| − | |||
| − | |||
| − | |||
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. | 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. | ||
| − | < | + | <pre> |
| + | traffic classifier C-CGNAT-ToBeNated operator and | ||
| + | if-match acl 3001 | ||
| + | </pre> | ||
| − | + | 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 que sejam satisfeitos para que o tráfego seja redirecionado para o NAT Server. | |
| − | + | <pre> | |
| − | + | traffic classifier C-CGNAT-DstExceptions operator and | |
| − | < | + | if-match acl 3002 |
| − | + | </pre> | |
| − | |||
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. | 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. | ||
| − | < | + | <pre> |
| − | + | traffic behavior B-CGNATBypass | |
| − | + | permit | |
| − | + | </pre> | |
| − | |||
| − | + | O traffic behavior é simplesmente um comportamento que estamos criando para ser usado posteriormente. Um traffic behavior sozinho, assim com todos os demais objetos da traffic policy, não terá nenhum efeito sobre o tráfego do roteador. Este traffic behavior tem como ação apenas permitir que o tráfego siga seu caminho padrão, sem nenhuma manipulação. | |
| − | < | + | <pre> |
| + | traffic behavior B-ToBeNATED | ||
| + | redirect ip-nexthop 172.20.0.2 | ||
| + | </pre> | ||
Este traffic behavior tem como ação redirecionar o tráfego para o IP 172.20.0.2, que em nosso exemplo é o IP de next-hop do roteador Huawei para o NAT Server. | Este traffic behavior tem como ação redirecionar o tráfego para o IP 172.20.0.2, que em nosso exemplo é o IP de next-hop do roteador Huawei para o NAT Server. | ||
| Linha 147: | Linha 131: | ||
Dar match em tudo cujo destino for 8.8.8.8/32: | Dar match em tudo cujo destino for 8.8.8.8/32: | ||
| − | < | + | <pre> |
| − | + | acl number 3001 | |
| − | + | rule 5 permit ip destination 8.8.8.8 0.0.0.0 | |
| + | </pre> | ||
Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 documentação da Huawei] explica de forma completa o assunto. | Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 documentação da Huawei] explica de forma completa o assunto. | ||
| Linha 156: | Linha 141: | ||
O traffic classifier tem a função de agrupar vários critérios diferentes para selecionar um tipo de tráfego que posteriormente será processado pelo traffic policy. Suponhamos que queremos dar match em todo tráfego com destino ao IP 8.8.8.8 cujo mac-address de origem seja aa:bb:cc:dd:ee:ff. Isto não é possível apenas fazer com ACL pois o tipo de ACL que no permite fazer filtragem por redes de destino (Advanced ACL, 3000-3999) não é o mesmo que nos permite realizar filtros por MAC-Address (Layer 2 ACL, 4000-4999), como é descrito [https://support.huawei.com/enterprise/en/doc/EDOC1000178177/4ae8136/acl-classification nesta documentação]. Além disso, o traffic classifier nos permite usar apenas uma única ACL. Sendo assim, nós precisamos trabalhar com uma ACL para dar match na rede de destino e usar um matcher nativo do traffic classifier para dar match no mac-address de origem. A configuração ficaria da seguinte forma: | O traffic classifier tem a função de agrupar vários critérios diferentes para selecionar um tipo de tráfego que posteriormente será processado pelo traffic policy. Suponhamos que queremos dar match em todo tráfego com destino ao IP 8.8.8.8 cujo mac-address de origem seja aa:bb:cc:dd:ee:ff. Isto não é possível apenas fazer com ACL pois o tipo de ACL que no permite fazer filtragem por redes de destino (Advanced ACL, 3000-3999) não é o mesmo que nos permite realizar filtros por MAC-Address (Layer 2 ACL, 4000-4999), como é descrito [https://support.huawei.com/enterprise/en/doc/EDOC1000178177/4ae8136/acl-classification nesta documentação]. Além disso, o traffic classifier nos permite usar apenas uma única ACL. Sendo assim, nós precisamos trabalhar com uma ACL para dar match na rede de destino e usar um matcher nativo do traffic classifier para dar match no mac-address de origem. A configuração ficaria da seguinte forma: | ||
| − | < | + | <pre> |
| − | + | traffic classifier FromMyDeviceToGoogle operator and | |
| − | + | if-match acl 3001 | |
| − | + | if-match source-mac aabb-ccdd-eeff | |
| − | + | </pre> | |
Veja que ao final da linha onde criamos o classifier, adicionamos o operador "and". Isto significa que para que as condições deste classifier sejam satisfeitas, todos os "if-match" precisam ser verídicos. Neste caso, significa corresponder à ACL 3001 '''e''' ao mac-address AA:BB:CC:DD:EE:FF. | Veja que ao final da linha onde criamos o classifier, adicionamos o operador "and". Isto significa que para que as condições deste classifier sejam satisfeitas, todos os "if-match" precisam ser verídicos. Neste caso, significa corresponder à ACL 3001 '''e''' ao mac-address AA:BB:CC:DD:EE:FF. | ||
| Linha 171: | Linha 156: | ||
Para criar um traffic behavior que redirecione o tráfego para um determinado next-hop você poderia usar os seguintes comandos: | Para criar um traffic behavior que redirecione o tráfego para um determinado next-hop você poderia usar os seguintes comandos: | ||
| − | < | + | <pre> |
| − | + | traffic behavior Redirect-to-Analyzer | |
| − | + | redirect ip-nexthop 172.16.0.2 | |
| + | </pre> | ||
==== traffic policy ==== | ==== traffic policy ==== | ||
| Linha 180: | Linha 166: | ||
Juntando os nossos exemplos anteriores, podemos configurar para que todo o tráfego com destino ao IP 8.8.8.8, cujo mac-address seja AA:BB:CC:DD:EE:FF seja redirecionado para o IP 172.16.0.2. Esta configuração ficaria da seguinte forma: | Juntando os nossos exemplos anteriores, podemos configurar para que todo o tráfego com destino ao IP 8.8.8.8, cujo mac-address seja AA:BB:CC:DD:EE:FF seja redirecionado para o IP 172.16.0.2. Esta configuração ficaria da seguinte forma: | ||
| − | < | + | <pre> |
| − | + | traffic policy RedirToAnalyzer | |
| − | + | classifier FromMyDeviceToGoogle behavior Redirect-to-Analyzer | |
| + | </pre> | ||
Apesar de eu não ter localizado uma documentação mais abrangente sobre o assunto, [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/8f933d1e/configuring-a-traffic-policy este link] parece explicar um pouco mais sobre o traffic policy. | Apesar de eu não ter localizado uma documentação mais abrangente sobre o assunto, [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/8f933d1e/configuring-a-traffic-policy este link] parece explicar um pouco mais sobre o traffic policy. | ||
| Linha 190: | Linha 177: | ||
* '''Aplicando globalmente em Switchs''' | * '''Aplicando globalmente em Switchs''' | ||
** '''Para tráfego entrante:''' <code>traffic-policy RedirToAnalyzer global inbound</code> | ** '''Para tráfego entrante:''' <code>traffic-policy RedirToAnalyzer global inbound</code> | ||
| − | ** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer global | + | ** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer global outbound</code> |
* '''Aplicando globalmente em roteadores''' | * '''Aplicando globalmente em roteadores''' | ||
| Linha 200: | Linha 187: | ||
Artigo por [[Usuário:Daniel Damito|Daniel Damito]] | Artigo por [[Usuário:Daniel Damito|Daniel Damito]] | ||
[[Categoria:Geral]] | [[Categoria:Geral]] | ||
| + | [[Categoria:Roteamento]] | ||
[[Categoria:Capacitação]] | [[Categoria:Capacitação]] | ||
Edição atual tal como às 23h47min de 30 de março de 2021
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 (Policy Based Routing - 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 por 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 servidor de CGNAT. Este equipamento possui outra interface diretamente conectada também à borda do ISP. Veja abaixo um diagrama que exemplifica este 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 são 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-ToBeNated operator or if-match acl 3001 traffic classifier C-CGNAT-DstExceptions operator or if-match acl 3002
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 que 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.
traffic behavior B-CGNATBypass permit
O traffic behavior é simplesmente um comportamento que estamos criando para ser usado posteriormente. Um traffic behavior sozinho, assim com todos os demais objetos da traffic policy, não terá nenhum efeito sobre o tráfego do roteador. Este traffic behavior tem como ação apenas permitir que o tráfego siga seu caminho padrão, sem nenhuma manipulação.
traffic behavior B-ToBeNATED redirect ip-nexthop 172.20.0.2
Este traffic behavior tem como ação redirecionar o tráfego para o IP 172.20.0.2, que em nosso exemplo é o IP de next-hop do roteador Huawei para o NAT Server.
traffic policy P-CGNAT
Aqui é onde as coisas começam a fazer mais sentido. Nós estamos entrando na traffic policy que aqui chamamos de "P-CGNAT" para configurá-la. Dentro desta traffic policy podemos ter um ou mais conjuntos de "classifier" e "behavior", que é semelhante à condições programáticas, onde se algo acontecer (classifier), faça tal coisa (behavior). Estas duplas de políticas são lidas sequencialmente.
classifier C-CGNAT-DstExceptions behavior B-CGNATBypass
Nesta primeira linha simplesmente estamos dizendo que se a condição descrita dentro do classifier "C-CGNAT-DstExceptions" for verdadeira, o comportamento descrito no behavior "B-CGNATBypass" deve ser aplicado. Apenas para relembrar, este classifier diz as redes de destino de exceção em nossa política de CGNAT e este Behavior tem a ação apenas de permitir o tráfego, sem nenhuma manipulação.
classifier C-CGNAT-ToBeNated behavior B-ToBeNATED
Aqui dizendo que todo o tráfego citado no classifier "C-CGNAT-TOBeNated" deve sofrer a ação descrita no behavior "B-ToBeNATED". Basicamente, todo tráfego originado pela rede 100.64.0.0/10 que não foi pré-processado na política anterior, deve ser redirecionado para o IP de next-hop do NAT Server.
traffic-policy P-CGNAT inbound global-acl
Aqui nós estamos dizendo que esta política recém criada deve ser aplicada em todo tráfego de entrada (inbound) global do roteador (global-acl).
Uma explicação um pouco mais detalhada de cada componente do traffic policy
Vale frisar aqui que o objetivo deste artigo não é esgotar o assunto nem substituir a documentação oficial da Huawei, apenas nortear seus estudos.
acl
As ACLs são usadas para selecionar determinados tipos de tráfego de acordo com os critérios escolhidos.
É possível criar ACLs baseadas em IPs de origem, IPs de destino, protocolos e outros parâmetros avançados dos cabeçalhos de um pacote como o ICMP Type.
Em nosso contexto, todo o tráfego que você quiser selecionar deverá ser definido em uma ACL. Caso você precise selecionar um tipo de tráfego que não seja possível ser definido em apenas uma ACL, você deverá criar mais de uma ACL e depois citar todas suas ACLs no traffic classifier que explicaremos mais adiante.
Exemplos:
Dar match em tudo cujo destino for 8.8.8.8/32:
acl number 3001 rule 5 permit ip destination 8.8.8.8 0.0.0.0
Esta documentação da Huawei explica de forma completa o assunto.
traffic classifier
O traffic classifier tem a função de agrupar vários critérios diferentes para selecionar um tipo de tráfego que posteriormente será processado pelo traffic policy. Suponhamos que queremos dar match em todo tráfego com destino ao IP 8.8.8.8 cujo mac-address de origem seja aa:bb:cc:dd:ee:ff. Isto não é possível apenas fazer com ACL pois o tipo de ACL que no permite fazer filtragem por redes de destino (Advanced ACL, 3000-3999) não é o mesmo que nos permite realizar filtros por MAC-Address (Layer 2 ACL, 4000-4999), como é descrito nesta documentação. Além disso, o traffic classifier nos permite usar apenas uma única ACL. Sendo assim, nós precisamos trabalhar com uma ACL para dar match na rede de destino e usar um matcher nativo do traffic classifier para dar match no mac-address de origem. A configuração ficaria da seguinte forma:
traffic classifier FromMyDeviceToGoogle operator and if-match acl 3001 if-match source-mac aabb-ccdd-eeff
Veja que ao final da linha onde criamos o classifier, adicionamos o operador "and". Isto significa que para que as condições deste classifier sejam satisfeitas, todos os "if-match" precisam ser verídicos. Neste caso, significa corresponder à ACL 3001 e ao mac-address AA:BB:CC:DD:EE:FF.
Não consegui encontrar uma documentação mais generalista sobre traffic classifier na base de conhecimento da Huawei, mas esta que explica o recurso no contexto de QoS se aplica bem em quase todos os cenários.
traffic behavior
É no traffic behavior que definimos um tipo de comportamento que adotaremos caso um determinado traffic classifier seja satisfeito. O traffic behavior, bem como as ACLs e o traffic classifier, pode ser usado em várias traffic policies diferentes, portanto é importante que seu nome seja claro e explique sua função. No traffic behavior podemos marcar pacotes com um determinado DSCP, descartá-los, permiti-los, redirecioná-los através de PBR para algum next-hop entre outras ações explicadas neste artigo.
Para criar um traffic behavior que redirecione o tráfego para um determinado next-hop você poderia usar os seguintes comandos:
traffic behavior Redirect-to-Analyzer redirect ip-nexthop 172.16.0.2
traffic policy
É no traffic policy onde juntamos todos os itens que vimos anteriormente. Aqui basicamente dizemos que se uma condição determinada (traffic classifier) acontecer, uma determinada ação deve ser executada (traffic behavior).
Juntando os nossos exemplos anteriores, podemos configurar para que todo o tráfego com destino ao IP 8.8.8.8, cujo mac-address seja AA:BB:CC:DD:EE:FF seja redirecionado para o IP 172.16.0.2. Esta configuração ficaria da seguinte forma:
traffic policy RedirToAnalyzer classifier FromMyDeviceToGoogle behavior Redirect-to-Analyzer
Apesar de eu não ter localizado uma documentação mais abrangente sobre o assunto, este link parece explicar um pouco mais sobre o traffic policy.
Aplicando o traffic policy
O traffic policy pode ser aplicado globalmente em todo o equipamento ou especificamente em uma interface. Ele também pode ser feito para todo o tráfego entrante (inbound) ou para todo o tráfego sainte (outbound) no equipamento ou na interface.
- Aplicando globalmente em Switchs
- Para tráfego entrante:
traffic-policy RedirToAnalyzer global inbound - Para tráfego sainte:
traffic-policy RedirToAnalyzer global outbound
- Para tráfego entrante:
- Aplicando globalmente em roteadores
- Para tráfego entrante:
traffic-policy RedirToAnalyzer inbound global-acl - Para tráfego sainte:
traffic-policy RedirToAnalyzer outbound global-acl
- Para tráfego entrante:
- Aplicando apenas em uma interface (switch ou roteador):
interface 100GE0/3/2traffic-policy RedirToAnalyzerinbound
Artigo por Daniel Damito