Wiki BPF - Contribuições do(a) usuário(a) [pt-br]

Fluxograma Simplificado para Troubleshooting de Problemas com Sites

2024-12-08T16:50:38Z

Daniel Damito:

'''Autor:''' [[Usuário:Daniel Damito]]

===Introdução===
Este fluxograma foi criado para a apresentação da palestra "Troubleshooting Like a Boss" na GTER 2024, acessível através deste link. Recomendo fortemente que você assista à esta palestra, pois nela foram ditas explicações relevantes sobre este fluxograma. Ademais, este fluxograma poderá passar por atualizações frequentes. Portanto, em vez de baixá-lo localmente em sua máquina, procure acessá-lo diretamente por aqui pela Wiki do BPF.

Eu também gostaria de lembrar que este fluxograma não deve ser considerado uma verdade absoluta em todos os casos, mas sim um guia pra te facilitar em troubleshootings.

Leia atentamente à descrição de cada etapa deste fluxograma na seção logo abaixo da imagem.

===O próprio Fluxograma===
[[Arquivo:Fluxograma de Troubleshooting.png|alt=|centro|miniaturadaimagem|800x800px]]

===Explicação sobre as etapas===

==== 1 - Site não abre ====
Este fluxograma deve ser iniciado assim que identificado que um determinado site não abre em todo o teu sistema autônomo. Considere iniciar estes testes apenas após confirmar que o problema é generalizado em toda a tua rede e não apenas em um usuário ou host específico.

==== 2 - Descartou problemas locais na rede? ====
O objetivo principal deste fluxograma é te ajudar a diagnosticar problemas externos ao seu sistema autônomo. Portanto se certifique de realizar testes que excluam problemas internos. Uma possibilidade é realizar um teste de acesso ao site problemático através de um equipamento conectado diretamente no roteador de borda para eliminar outros hosts intermediários na rede. Complementarmente, recomendo que sejam feitos testes com outros dispositivos (diferentes computadores ou smartphones) e usando outros navegadores, preferencialmente no modo anônimo.

==== 3 - O problema ocorre em outros sites também? ====
Realize o teste com outros sites em sua rede. Busque testar com mais de um navegador, com mais de um dispositivo e sempre busque realizar testes usando o modo anônimo do navegador.

==== 4 - Ocorre com muitas outras redes? ====
Algumas ferramentas podem te ajudar com este teste.

===== ISP Tools =====
Além de várias outras features interessantes, o [https://isp.tools/ ISP Tools] possui uma função de realizar [http://www.isp.tools/http testes de abertura de páginas] a partir de dezenas de origens. Para utilizar este recurso, escolha a origem desejada na lista, digite o endereço do site e clique em 'testar'. Repita este teste com várias origens para entender se o problema acontece a partir de outras redes também. O resultado mais positivo da abertura de um site é o código 200 no status, mas o número dos outros status podem indicar outras informações relevantes, conforme explico em minha palestra e conforme pode ser lido na RFC 9110.

===== Down Detector =====
O [[https://downdetector.com.br Downdetector]] é um serviço que monitora a disponibilidade de sites e aplicativos em tempo real por meio de relatos de usuários; para verificar se um serviço específico está com falhas, acesse a página inicial, utilize o campo de pesquisa para localizar o serviço desejado e observe se há um aumento significativo no número de reclamações ou no gráfico de relatos recentes.
==== 5 - Resolve nome? ====
Você pode testar de algumas maneiras se um domínio está sendo devidamente resolvido. Segue abaixo alguns exemplos:
* nslookup (Windows e Linux)
<pre>nslookup exemple.com</pre>

Saída esperada caso funcione:
<pre>
Non-authoritative answer:
Name: example.com
Address: 203.0.113.10
</pre>Se houver resposta diferente disso, espere que '''não funcionou.'''
* dig (Linux)
Para consultar:
<pre>dig +short example.com</pre>

Saída esperada caso funcione: será apenas um IP

Caso não tenha funcionado, alguma resposta de erro de comunicação ou '''output nenhum'''.
* host (Linux)
<pre>host example.com</pre>
Saída esperada caso resolva:
<pre>
example.com has address 203.0.113.10
example.com has IPv6 address 2001:db8::1234
</pre>Caso a saída seja diferente disso, espere que '''não funcionou.'''

==== 6 - Com outro DNS resolve? ====
Você pode especificar um servidor DNS alternativo, como o 1.1.1.1 (Cloudflare), 8.8.8.8 (Google) ou suas variantes IPv6 (2606:4700:4700::1111 para Cloudflare e 2001:4860:4860::8888 para Google), adicionando-o ao comando. Veja abaixo:

* nslookup (Windows e Linux):
<pre>nslookup example.com 1.1.1.1</pre>
<pre>nslookup example.com 2606:4700:4700::1111</pre>

* dig (Linux):
<pre>dig +short A example.com @8.8.8.8</pre>
<pre>dig +short AAAA example.com @2001:4860:4860::8888</pre>

* host (Linux):
<pre>host example.com 1.1.1.1</pre>
<pre>host example.com 2606:4700:4700::1111</pre>

Dessa forma, você verifica se o problema de resolução está no servidor DNS padrão ou não.

Os resultados que você espera são os mesmos do item 5.

Obs. Citei o Google e Cloudflare, mas poderia ser qualquer DNS público que você confie que através dele "deveria" funcionar.

==== 7 - O site responde ping? ====
Faça o teste de ping normalmente para verificar se responde.

<pre>ping -c 10 example.com
PING example.com (203.0.113.10) 56(84) bytes of data.

--- example.com ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9252ms</pre>

Se não responder (como aconteceu acima), você verá 100% de packet loss.
Se responder, você verá um valor que não é 100% de packet loss.

Obs. Se responder parcialmente, ou seja, se houver perdas de pacotes, o sintoma será lentidão/intermitência ao carregar o conteúdo, porém, lentidão não significa que o conteúdo não está disponível. Os problemas são diferentes.

==== 8 - Algum IP do mesmo /24 responde ping? ====

Se caso o IP do site não responder ao ping, você pode testar pingar algum IP daquele /24. Isso ajudará a entender se há algum problema de roteamento.

O comando "fping -ga" é o que recomendamos (disponível no Linux) pois você facilmente conseguira pingar o /24 inteiro para descobrir se algum IP responde.

Se outro IP responder, você verá algo assim:

<pre>fping -ga 203.0.113.0/24
203.0.113.28
203.0.113.98
203.0.113.122
203.0.113.123
203.0.113.124
203.0.113.201</pre>

Perceba que vários outros IPs pingaram do mesmo /24.

Caso nenhum IP responda ao ping, você não terá output deste comando.

==== 9 - Alterar o upload deste IP/rede para outro trânsito resolve o problema? ====
Para este item o seu conhecimento de roteamento se faz necessário.

Como esse caso é um caso que depende muito de como está sua rede, quantidade de upstreams e etc, acaba que não há como ensinarmos exatamente o que você precisará fazer, mas em suma você precisará:

'''Criar uma rota estática do IP descoberto no item 5 para outro caminho (outro upstream) e não o caminho onde ele está atualmente usando.'''

==== '''10 - O problema não é o roteamento em si (mas pode ser algum bloqueio em algum trânsito)''' ====
A conclusão desta parte é que você tem comunicação até o AS de destino deste conteúdo.

Seguiremos investigando o caso, mas já da pra saber que o problema de roteamento você não tem.

==== 11 - Anunciar o /24 de origem somente para outro trânsito resolve o problema? ====
Para este item o seu conhecimento de roteamento se faz necessário.

E além disso você '''deve''' possuir mais de um upstream para conseguir efetuar este item.

Veja qual é seu IP de origem dos testes e desvie o /24 respectivo para outro caminho. Você fará isso editando politicas de roteamento de BGP. O objetivo deste item é:
# '''Anunciar o /24 de origem respectivo para outro caminho.'''
# '''Remover o /24 (caso exista) do caminho atual. Não trabalhe com prepends aqui, faça totalmente o withdraw da rota.'''
Caso você não anuncie nenhum /24 antes do teste, você não teria como saber o caminho escolhido do lado do conteúdo até você com precisão; neste caso, verifique se a primeira manobra de anunciar o /24 para um dos caminhos resolveu e caso não tenha resolvido, tente anunciar o /24 exclusivamente para um a um dos seus upstreams até conseguir eliminar com certeza que a mudança surtiu ou não efeito.

'''''Obs. Caso você tenha apenas um upstream ou você não seja um sistema autônomo, você não poderá realizar o teste necessário e então se fará necessário você abrir um chamado com seu provedor atual para ele te ajudar com esta etapa.'''''

==== 12 - Verifique seu lado por firewalls, sistemas de manipulação de tráfego, sistemas de mitigação, dentro outras coisas ====
Alguns fatores que podem estar causando este problema podem ser: sistemas de mitigação, sistemas de detecção de ataques, regras de firewall, regras de ACL, sistemas de blacklist (como Team Cymru e outros similares), problemas relacionados à MTU, saturação de recursos computacionais (como CPU e RAM) de ativos como roteadores, problemas relacionados ao CGNAT e rotas estáticas legadas.

==== 13 - O problema está no lado do conteúdo ====
Abra um chamado com o provedor do conteúdo que você está tendo problemas. Caso não saiba como fazer isso, sugerimos procurar contatos através do Whois ou do site da hospedagem do conteúdo.

==== 14 - O DNS que você estava usando está com problemas de resolução ====
Recomendamos verificar se o DNS do seu equipamento está configurado de forma estática, pois o servidor aparenta não estar funcional. Como solução temporária, você pode usar um DNS público, como o Google DNS, Cloudflare DNS ou OpenDNS. No entanto, é importante investigar a causa da falha no DNS atual.

==== 15 - Possível problema geral na sua conexão ou bloqueio de DNS ====
Verifique sua comunicação com o seu gateway e outros possíveis problemas de rede, como falha do seu provedor. Este problema provavelmente não está do lado do conteúdo. Testar abertura com seu celular via 4G/5G também é uma opção para descartar problemas do lado do conteúdo.

==== 16 - O problema possivelmente é o trânsito eleito para a rota que te leva ao site ====
Recomendamos que você altere seu caminho para chegar ao IP do site através de políticas de roteamento BGP e notifique o seu caminho anterior (upstream) sobre o problema.

Se caso o seu caminho anterior for algum IX, valide problemas que possam estar acontecendo no IX e afetando mais conteúdos. Acessar o status page do IX respectivo é uma boa opção neste caso.

==== 17 - Possível problema no trânsito para o qual este /24 era eleito no destino (ver LG) ====
Abra um chamado com seu trânsito e também seria bom tentar contacto com o fornecedor/mantenedor do site/serviço. Se o conteúdo possuir '''looking glass''' isso vai poder te ajudar a levantar evidências para isso.

O fato é que o '''caminho''' pelo qual o conteúdo tentava chegava até você, durante o processo de acesso, '''estava prejudicando a comunicação.'''

==== 18 - Entre em contato com o fornecedor do site/serviço ====
Você precisará entrar em contato com o fornecedor/mantenedor do site/serviço. Este problema está afetando não só você como provavelmente várias outras origens.

Um bom local para encontrar onde você deve reportar algum problema é o whois ou o peeringDB.

Autores: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito] e André Almeida.

Fluxograma Simplificado para Troubleshooting de Problemas com Sites

2024-10-10T20:19:17Z

Daniel Damito:

Fluxograma Simplificado para Troubleshooting de Problemas com Sites

2024-10-10T19:38:56Z

Daniel Damito:

Fluxograma Simplificado para Troubleshooting de Problemas com Sites

2024-10-10T19:29:35Z

Daniel Damito:

Fluxograma Simplificado para Troubleshooting de Problemas com Sites

2024-10-10T19:27:04Z

Daniel Damito:

Fluxograma Simplificado para Troubleshooting de Problemas com Sites

2024-10-10T19:23:56Z

Daniel Damito:

Fluxograma Simplificado para Troubleshooting de Problemas com Sites

2024-10-10T19:18:40Z

Daniel Damito:

Fluxograma Simplificado para Troubleshooting de Problemas com Sites

2024-10-10T19:09:53Z

Daniel Damito:

'''Autor:''' [[Usuário:Daniel Damito]]

===Introdução===
www
===O próprio Fluxograma===
www

[[Arquivo:FLUXOGRAMA - TROUBLESHOOTING.jpg|centro|miniaturadaimagem|800x800px]]
===Explicação sobre as etapas===
www

Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito].

Fluxograma Simplificado para Troubleshooting de Problemas com Sites

2024-10-10T19:08:19Z

Daniel Damito:

'''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''

===Introdução===
www
===O próprio Fluxograma===
www

[[Arquivo:FLUXOGRAMA - TROUBLESHOOTING.jpg|centro|miniaturadaimagem|800x800px]]
===Explicação sobre as etapas===
www

Fluxograma Simplificado para Troubleshooting de Problemas com Sites

2024-10-10T19:05:02Z

Daniel Damito:

[[Arquivo:FLUXOGRAMA - TROUBLESHOOTING.jpg|centro|miniaturadaimagem|800x800px]]
construção

Arquivo:FLUXOGRAMA - TROUBLESHOOTING.jpg

2024-10-10T19:04:26Z

Daniel Damito:

FLUXOGRAMA - TROUBLESHOOTING

Fluxograma Simplificado para Troubleshooting de Problemas com Sites

2024-10-10T17:07:51Z

Daniel Damito: Criou página com 'construção'

construção

Como ver quais caches estou usando

2023-01-16T14:48:58Z

Daniel Damito:

=== Introdução ===
Possuir um cache (servidor de rede de CDN) em sua rede não significa necessariamente que você o esteja utilizando. É necessário que estes provedores de conteúdo elejam os servidores locais em sua rede como os melhores caminhos para entregar o conteúdo.

Existem alguns métodos, a depender do cache, para se saber qual servidor está sendo utilizado pelo usuário.

=== Google ===
Através um dispositivo dentro da rede /24 em que você deseja consultar qual cache está utilizando, acesse a URL https://redirector.googlevideo.com/report_mapping.

A primeira linha desta página deve ser algo assim:

2001:db8:0:0:1:0:0:1 => meuisp-gru (2001:db8::/32)

'''Onde:'''

2001:db8:0:0:1:0:0:1: O IP de origem do dispositivo que acessou o site

meuisp: Nome do ISP onde o cache está hospedado (se aqui estiver o nome do seu ISP, você está utilizado o seu cache local)

gru: Cidade onde o cache está hospedado

2001:db8::/32: Rede eleita, na tabela global de roteamento, para alcançar este teu IP

=== Facebook ===
w

=== Netflix ===
w

=== E se eu não estiver utilizando o cache local de meu ISP? ===
# Verifique se suas redes não estão sendo anunciadas de forma mais específica para outro destino que contenha uma rede de cache, como o teu upstream ou o próprio provedor de conteúdo no IX.
# Verifique se os seus servidores estão saudáveis e alcançáveis globalmente sem restrição pela Internet, através de ICMP, HTTPs e todos os demais protocolos.
# Verifique se os seus blocos estão cadastrados no RADB ou algum outro IRR globalmente utilizado.
# Abra um chamado com o provedor de conteúdo solicitando auxílio para investigar o problema.

Artigo por [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]
[[Categoria:Capacitação]]

Usuário:Daniel Damito

2023-01-16T14:48:18Z

Daniel Damito:

== Resumo ==
Daniel Damito é especialista na área de redes de computadores, com ênfase em roteamento e segurança.

É fundador e diretor da [https://sagenetworks.com.br/ Sage Networks], empresa de consultoria de redes.

Possui formação acadêmica de nível superior na área de Redes de Computadores, e pós graduação lato sensu também na Área de Redes de Computadores.

É um dos fundadores do projeto 3BR (ainda em desenvolvimento) e participante ativo no [https://wiki.brasilpeeringforum.org/w/Quem_Somos BPF].

É coordenador da ''Task Force'' de IPv6 do BPF.

== Artigos Escritos ==
[[Arquivo:Daniel Damito.jpg|miniaturadaimagem]]

[[Porque usar um DNS local e algumas dicas para isto]]

[[Como consultar e corrigir a geolocalizacao de seus IPs]]

[[PeeringDB - como se cadastrar e atualizar seus dados]]

[[Boas práticas de segurança para roteadores Mikrotik]]

[[Diferenca entre AS-OVERRIDE e ALLOWAS-IN]]

[https://wiki.brasilpeeringforum.org/w/Como_reportar_abusos_ao_Google Como reportar abusos ao Google]

[https://wiki.brasilpeeringforum.org/w/Como_fazer_com_que_um_determinado_conteudo_saia_por_um_link_especifico Como fazer com que um determinado conteudo saia por um link especifico]

[https://wiki.brasilpeeringforum.org/w/Como_capturar_pacotes_no_Mikrotik Como capturar pacotes no Mikrotik]

[[O Minimo que voce precisa saber sobre DDoS]]

[[Comandos de linux úteis para troubleshooting de redes]]

[[Como escolher um transito IP]]

[[Boas praticas para cenarios de DDoS]]

[[Como funciona o traffic policy no Huawei]]

[[Como ver quais caches estou usando]]

== Contatos ==
'''LinkedIn:''' https://www.linkedin.com/in/daniel-damito-3b25b8b6/

'''E-mail pessoal:''' contato@danieldamito.com.br

'''E-mail profissional:''' daniel.damito@sagenetworks.com.br

Como ver quais caches estou usando

2023-01-16T14:47:04Z

Daniel Damito: Criou página com '=== Introdução === Possuir um cache (servidor de rede de CDN) em sua rede não significa necessariamente que você o esteja utilizando. É necessário que estes provedores d...'

=== Introdução ===
Possuir um cache (servidor de rede de CDN) em sua rede não significa necessariamente que você o esteja utilizando. É necessário que estes provedores de conteúdo elejam os servidores locais em sua rede como os melhores caminhos para entregar o conteúdo.

Existem alguns métodos, a depender do cache, para se saber qual servidor está sendo utilizado pelo usuário.

=== Google ===
Através um dispositivo dentro da rede /24 em que você deseja consultar qual cache está utilizando, acesse a URL https://redirector.googlevideo.com/report_mapping.

A primeira linha desta página deve ser algo assim:

2001:db8:0:0:1:0:0:1 => meuisp-gru (2001:db8::/32)

'''Onde:'''

2001:db8:0:0:1:0:0:1: O IP de origem do dispositivo que acessou o site

meuisp: Nome do ISP onde o cache está hospedado (se aqui estiver o nome do seu ISP, você está utilizado o seu cache local)

gru: Cidade onde o cache está hospedado

2001:db8::/32: Rede eleita, na tabela global de roteamento, para alcançar este teu IP

=== Facebook ===
w

=== Netflix ===
w

=== E se eu não estiver utilizando o cache local de meu ISP? ===
# Verifique se suas redes não estão sendo anunciadas de forma mais específica para outro destino que contenha uma rede de cache, como o teu upstream ou o próprio provedor de conteúdo no IX.
# Verifique se os seus servidores estão saudáveis e alcançáveis globalmente sem restrição pela Internet, através de ICMP, HTTPs e todos os demais protocolos.
# Verifique se os seus blocos estão cadastrados no RADB ou algum outro IRR globalmente utilizado.
# Abra um chamado com o fornecedor solicitando auxílio para investigar o problema.

Como consultar e corrigir a geolocalizacao de seus IPs

2022-08-30T21:24:52Z

Daniel Damito:

= Introdução =
Manter a geolocalização dos seus IPs atualizada é fundamental devido a grande variedade de sites e sistemas que baseiam a permissão do acesso ou direcionamento de conteúdo baseado na localização dos usuários. Não ter sua geolocalização atualizada pode trazer diversos problemas, como resultados de testes de velocidade imprecisos e restrição de acesso à conteúdos.

Os problemas mais recorrentes de geolocalização acontecem com ASNs que receberam blocos recém alocados ao LACNIC/NIC, como 45.x.x.x.

Apesar de existirem diversas bases de dados de geolocalização, esse documento será focado em alguns dos serviços mais utilizados na internet para esse fim.

= Alguns exemplos de utilização da geolocalização na Internet =
'''Testadores de velocidade:''' Alguns testadores de velocidades amplamente utilizados, como o [https://www.speedtest.net/pt Speedtest da Ookla] e o [https://www.minhaconexao.com.br/ Minha Conexão], utilizam a geolocalização do IP do cliente para definir quais são os servidores mais próximos.

'''Sites de notícias:''' Muitos sites de notícia que publicam notícias sobre diversas localidades utilizam a geolocalização para direcionar os usuários para as notícias de sua região.

'''Sites institucionais:''' Diversos sites que possuem múltiplos idiomas determinam em qual língua o site deverá ser exibido para o usuário baseado na geolocalização dos IPs.

'''Sistemas de segurança:''' Sistemas de segurança por diversas vezes restringem o acesso à certos conteúdos para alguns países ou regiões específicas.

'''Empresas de marketing digital:''' Empresas que fazem marketing digital costumam sugerir ofertas ou publicar informações em redes sociais baseadas na localização dos usuários.

'''CDNs:''' Diversos provedores de conteúdos que possuem redes de CDNs também utilizam a geolocalização para restringir ou permitir acesso à determinados conteúdos. Um exemplo disto é o [https://netflix.com Netflix], que eventualmente exibe mensagens de erros relacionadas à geolocalização do assinante.

= Como consultar a geolocalização de um prefixo na Maxmind =
Uma das bases de dados de geolocalização mais utilizadas é a [https://www.maxmind.com Maxmind].

Para consultar a geolocalização de um prefixo, basta acessar [https://www.maxmind.com/en/geoip-demo este link].

No campo IP Addresses, você pode inserir vários endereços IPv4 e IPv6 ao mesmo tempo e consultar a geolocalização de cada um. Geralmente consultar alguns IPs de cada bloco já é suficiente para confirmar que a geolocalização de todo o bloco está correta. Veja o exemplo abaixo:

[[Arquivo:ExemploGeoLocalizacao-MaxMind1.png|centro|miniaturadaimagem|600x600px]]

No exemplo acima apenas o país está cadastrado, mas a cidade onde são utilizados não.

= Como corrigir a geolocalização de um prefixo na Maxmind =

Se os seus IPs estiverem cadastrados em um país diferente do real ou caso a cidade onde são utilizados não esteja especificada, você pode solicitar a correção na Maxmind [https://support.maxmind.com/geoip-data-correction-request/ através deste link].

Os campos devem ser preenchidos da seguinte forma:

'''Product:''' deixe o valor padrão - GeoIP2 or GeoIP Legacy Database.

'''IP Range:''' seu endereço ou seu bloco, IPv4 ou IPv6.

'''City:''' cidade onde este prefixo é utilizado. Caso seja utilizado em diversos lugares, não altere todo o bloco, apenas os IPs ou redes específicas ou deixe este campo em branco.

'''State/Province:''' este campo só deve ser preenchido em redes do Canadá ou Estados Unidos da América.

'''Postal code:''' este campo é opcional. Caso queira preencher, digite o CEP da cidade.

'''Country:''' o país onde o prefixo ou o IP é utilizado.

'''Email:''' o e-mail responsável pelo ASN cadastrado no [https://registro.br/2/whois whois do registro.br] ou no whois do seu [[wikipedia:National_Internet_registry|NIR]].

'''Other:''' caso queira dar algum detalhe adicional sobre o seu bloco, preencha neste campo.

[[Arquivo:Corrigindo geolocalizacao na Maxmind.png|centro|miniaturadaimagem]]

= Como corrigir a geolocalização de um prefixo na Fortinet =
A Fortinet é uma empresa que comercializa softwares, produtos e serviços de cibersegurança, como firewalls, antivírus, prevenção de intrusão etc e mantém uma base de geolocalização própria que é distribuída para seus clientes que contratam o serviço. Esta base de dados não necessariamente possui vinculação com outras como a Maxmind.

Atualmente não existe uma ferramente web para checar se a geolocalização já está atualizada nos serviços da Fortinet.

Desta forma é necessário também solicitar a atualização das informações para os administradores dessa base de dados para que elas cheguem aos equipamentos que as utilizam.

É importante destacar que esses equipamentos são utilizados também em muitas grandes empresas ou serviços públicos que, por vezes realizam bloqueios por país utilizando-se desta base de dados de geolocalização mantida pelo fabricante.

Para realizar a solicitação de atualização dos dados da base de geolocalização da Fortinet é necessário enviar um e-mail em Inglês para o e-mail: contact_geoip [em] fortinet.com

O e-mail deve conter os dados similares aos informados no procedimento da Maxmind, ou seja:
* IP Range
* City
* State
* Country
* (Outras informações - opcional)

= Como consultar dados no IPLocation =
Um site muito interessante para esse fim, é o [https://iplocation.io/ iplocation.io], onde é exibido resultado de pesquisas em databases de GeoIP em um único local (vamos indicar como corrigir nos próximos tópicos).

Ao acessar o site, ele já exibe a informação do seu ip atual, caso deseje consultar um ip diferente basta digitar um dos IPs do bloco no campo de pesquisa no topo da página, seja ele IPv4 ou IPv6.

= Como corrigir a geolocalização no IP2Location =
Para correção nesse banco de dados basta enviar um email para support@ip2location.com com as seguintes informações:

Netblock: "SEU BLOCO DE IPs"

Company: "NOME DA SUA EMPRESA"

Country: "BR" (OU O SEU PAÍS)

State: "UF" (RJ, SP, MG, etc.)

City: "CIDADE"

Zipcode: "CEP".

Não se esqueçam de ser cordiais, então não mande apenas os dados, mas diga um olá, informa que deseja atualizar e depois agradeça, texto em inglês, caso tenha dificuldade com o idioma use o google translator.

Segundo eles, a atualização é realizada poucos dias após a resposta deles, não tem um tempo preciso, mas não leva mais que 10 dias.

= Como corrigir a geolocalização no IPGeolocation =
Esse banco de dados é simples de corrigir, basta entrar em contato através do portal deles pelo [https://ipgeolocation.io/contact.html formulário de contato].

No formulário preencha os dados solicitados como Nome, Email e Telefone, e no campo de mensagem envie as seguintes informações:

Netblock: "SEU BLOCO DE IPs"

Company: "NOME DA SUA EMPRESA"

Country: "BR" (OU O SEU PAÍS)

State: "UF" (RJ, SP, MG, etc.)

City: "CIDADE"

Zipcode: "CEP".

Não se esqueçam de ser cordiais, então não mande apenas os dados, mas diga um olá, informa que deseja atualizar e depois agradeça, texto em inglês, caso tenha dificuldade com o idioma use o google translator.

Segundo o retorno deles, a publicação ocorre até 5 dias após eles analisarem os dados.

= Como corrigir a geolocalização no IPInfo =
No IPInfo o processo é simples, basta entrar em contato através do [https://ipinfo.io/contact formulário de contato].

No formulário preencha os dados solicitados como Nome, Email e no campo de mensagem envie as seguintes informações:

Netblock: "SEU BLOCO DE IPs"

Company: "NOME DA SUA EMPRESA"

Country: "BR" (OU O SEU PAÍS)

State: "UF" (RJ, SP, MG, etc.)

City: "CIDADE"

Zipcode: "CEP".

Eles também podem realizar o processamento dos dados através de GeoFeed, que basicamente é um arquivo em CSV com informações dos seus blocos de IPs, esse processo é muito interessante caso você tenha necessidade de atualizar constantemente essas informações.

O arquivo GeoFeed precisa estar hospedado na internet, nem que seja no Google Drive porém recomendamos que dentro da hospedagem do seu site crie uma pasta GeoFeed para hospedar essas informações, maiores informações podem ser consultadas através do link: <nowiki>https://ipinfo.io/blog/what-is-geofeed-how-to-it-setup</nowiki>

A RFC sobre o padrão desse arquivo você encontra em: <nowiki>https://datatracker.ietf.org/doc/html/rfc8805</nowiki>

Segundo o retorno deles, a publicação ocorre diariamente, mas o tempo médio para a informação ser exibida de forma atualizada é de 2 à 5 dias.

= Como corrigir a geolocalização no DB-IP =
No DB-IP também é um processo simples, basta entrar em contato através do [https://db-ip.com/contact/ formulário de contato].

No formulário preencha os dados Email e no campo de mensagem envie as seguintes informações:

Netblock: "SEU BLOCO DE IPs"

Company: "NOME DA SUA EMPRESA"

Country: "BR" (OU O SEU PAÍS)

State: "UF" (RJ, SP, MG, etc.)

City: "CIDADE"

Zipcode: "CEP".

Eles também podem realizar o processamento dos dados através de GeoFeed, que basicamente é um arquivo em CSV com informações dos seus blocos de IPs, esse processo é muito interessante caso você tenha necessidade de atualizar constantemente essas informações.

O arquivo GeoFeed precisa estar hospedado na internet, nem que seja no Google Drive porém recomendamos que dentro da hospedagem do seu site crie uma pasta GeoFeed para hospedar essas informações, maiores informações podem ser consultadas através do link: <nowiki>https://db-ip.com/faq.php</nowiki>

A RFC sobre o padrão desse arquivo você encontra em: <nowiki>https://datatracker.ietf.org/doc/html/rfc8805</nowiki>

Segundo o retorno deles, a publicação ocorre semanalmente.

= FAQ - Perguntas frequentes =

'''Quanto tempo demora para a minha geolocalização ser atualizada?'''

Este processo pode durar até 40 dias, depende do banco de dados que está sendo atualizado, alguns atualizam diariamente essas informações e outros como a Maxmind e o DB-IP atualizam de forma semanalmente.

'''Toda solicitação de correção é atendida?'''

Não, algumas razões para não solicitações não serem atendidas, no geral não são atendidas devido à falta de informação ou até mesmo uma informação incorreta, então é recomendado que sempre leia a solicitação e confira cada dado antes de enviar.

'''O que fazer se minha solicitação não for atendida?'''

Tente solicitar novamente a partir de seus próprios IPs, adicionando maiores detalhes sobre sua entidade ou algum detalhe adicional que seja solicitao, e retorne contato através dos meios mencionados acima.

'''Leitura recomendadas:'''

<nowiki>https://support.maxmind.com/correction-faq/</nowiki>

<nowiki>https://db-ip.com/faq.php</nowiki>

'''Saiba mais sobre GeoFeed:'''

<nowiki>https://datatracker.ietf.org/doc/html/rfc8805</nowiki>

<nowiki>https://ipinfo.io/blog/what-is-geofeed-how-to-it-setup</nowiki>

Artigo por [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]

[[Categoria:BCOPs]]
[[Categoria:Geral]]

Boas praticas para cenarios de DDoS

2022-08-30T21:20:12Z

Daniel Damito:

===Introdução===
O objetivo deste artigo é explicar algumas boas práticas que você deve adotar para amenizar o impacto de eventuais ataques de negação de serviço em sua rede.

Estas boas práticas '''não irão resolver''' os problemas de ataque em sua rede, mas sem elas, quaisquer outras medidas mais definitivas, como a contratação de um serviço de mitigação em nuvem, ou um serviço de detecção local, não surtirão todo o efeito esperado ou simplesmente serão ineficazes.

Também vale relembrar que não existe uma solução fácil, rápida e barata para ataques (D)DoS. Qualquer solução que penses em adotar exigirá também esforço e dedicação de toda a equipe da empresa envolvida nos problemas causados pelos ataques.

Antes de seguir na leitura deste artigo, recomendamos a leitura de outro, também aqui no BPF: o [[O Minimo que voce precisa saber sobre DDoS]].

=== Boas práticas propostas ===

==== Previna loops de roteamento ====
Uma das principais causas de amplificação de ataques é o loop de roteamento. Estes loops geralmente acontecem da seguinte forma:

'''Exemplo 1:'''
* Roteador A tem rota para uma rede completa, como um /22 em IPv4, tendo como next-hop/gateway o roteador B;
* Roteador B não possui toda a rede /22 em uso, mas possui uma rota default para o roteador A;
* Ataques, inclusive de pouca volumetria, chegam com destino à IPs que não estão em uso. Estes pacotes são encaminhados pelo roteador A ao roteador B. Roteador B segue a rota default e devolve o pacote ao roteador A;
* Este ciclo se repete com cada um dos pacotes até que o TTL seja expirado, amplificando o ataque internamente.

Este exemplo pode acontecer internamente entre um roteador de borda (BGP) e um roteador adjacente na própria topologia, como no exemplo descrito acima, ou até mesmo entre o roteador de borda da empresa e o roteador do upstream, como no diagrama exibido abaixo:

[[Arquivo:Ddoslooproteamento.jpg|miniaturadaimagem|centro|'''Exemplo 2''']]

No exemplo do diagrama acima, um ataque à algum IP que não está em uso, como 192.0.2.0 ou 192.0.2.100, teria um grande potencial devastador.

Uma das formas de testar loops de roteamento é através do utilitário fping. Exceto em casos de bloqueios explícitos de bloqueio, um mero teste de ping é capaz de mostrar IPs que estão em loop e portanto respondem com ICMP Time Exceeded. A linha de comando abaixo, que usa a rede 192.0.2.0/24 como exemplo, mostra todos os IPs nesta rede que supostamente estão em loops:

''fping -gae 192.0.2.0/24 2>&1 | grep -Fi time | cut -d" " -f 11''

Uma forma comum de resolver estes problemas é adicionar uma rota estática para a blackhole/null0/discard do bloco inteiro no(s) roteador(es) que recebe(m) rotas específicas dos IPs que estão realmente em uso.

No exemplo 1, os roteadores A e B deveriam ter um IGP (OSPF, IS-IS, EIGRP, IBGP etc), o roteador B deveria anunciar os prefixos em uso dinamicamente para o roteador A e o roteador A deveria ter uma rota estática do bloco inteiro tendo como next-hop uma interface de discard/blackhole.

No exemplo 2, bastaria adicionar uma rota estática do bloco 192.0.2.0/24 para a blackhole.

No caso de roteadores Mikrotik basta adicionar uma rota estática sem o parâmetro gateway, e mudando seu tipo para "Blackhole".

Um sintoma típico de loops de roteamento durante DDoS é o aumento do upload junto com o aumento do download durante o DDoS.

Recomendamos também o uso do [https://radar.qrator.net/ Radar QRATOR] para monitoramento de loops de roteamento.

==== Evite o uso de IPs públicos nas interfaces WAN ====
Um dos ataques que geralmente não terão uma contra medida específica a se adotar são os ataques nos IPs de WAN/P2P usados para entrega dos links ou estabelecimento de peerings. Quando se trata de um ataque nos seus próprios IPs, você pode simplesmente utilizar a técnica de RTBH (ou simplesmente blackhole) para descartar o tráfego externamente ou deixar de anunciar aquele bloco atacado temporariamente. Entretanto um ataque em um IP de WAN de um fornecedor não poderá ser resolvido rapidamente por você mesmo e exigirá o desligamento daquele link ou uma ação do próprio detentor daquele ASN.

Sendo assim, para evitar ataques nos IPs de WAN recomendamos que sempre peçam IPs privados, que não sejam publicamente acessíveis ou que sejam protegidos pelo fornecedor. Quando isto não for possível, sempre monitore em seus sistemas de flow e detecção de ataques também estes IPs.

Infelizmente o [http://ix.br/ IX.BR] não possui uma solução para este assunto, e ataques pelo próprio IX nos IPs do ATM não podem ser contidos, restando apenas a opção de deixar todo o tráfego entrar ou desligar a conexão com o IX. Este inclusive é um dos motivos para que você não conte apenas com a sua capacidade de tráfego no IX para suportar a operação.

==== Não use endereços IPv4 públicos em seus sistemas de detecção ====
Os sistemas de detecção de ataque são os responsáveis por orquestrar toda a proteção da rede, e por isso devem ser mantidos sob a maior segurança possível. Um ataque diretamente à um destes sistemas poderia causar uma falha nas suas funções de detecção, deixando toda a rede vulnerável, saturando os demais recursos e até possibilitando outros ataques ainda mais severos.

Sendo assim, tente acessar estes sistemas apenas por VPNs, endereços privados internamente ou com endereços IPv6 apenas.

==== Evite o uso de endereços IPv4 públicos diretamente nos roteadores ====
A maioria dos roteadores foi projetado para otimizar a função de ''forward'' (encaminhamento de pacotes) e não o ''input'' (processamento de pacotes destinados ao próprio roteador).

Desta forma, ataques à IPs dos próprios roteadores facilmente causarão travamentos ou falhas severas nos equipamentos, principalmente em ''softrouters'' como Mikrotik e VyOS. Por este motivo, evite sempre possuir IPs públicos em interfaces (físicas ou lógicas, inclusive em loopbacks) dos roteadores. Caso isto seja realmente necessário, certifique-se de proteger estes IPs devidamente.

Comumente vemos roteadores Mikrotik que fazem CGNAT possuírem todos os IPs públicos em uma interface, como loopback. Isto multiplica o problema descrito anteriormente, e por isto é importante notar que não é necessária a existência do IP em uma interface deste roteador para que ele consiga fazer o NAT. Você pode substituir esta prática por rotas estáticas à este roteador ou criar rotas locais para a blackhole, configurando o seu IGP para distribuir as rotas deste tipo dinamicamente para o resto da rede.

==== Utilize Fastpath ou Fasttrack em Mikrotiks sempre que possível ====
Roteadores Mikrotik que não precisam fazer funções de firewall, NAT, mangle, PBR ou queues podem utilizar o ''[https://wiki.mikrotik.com/wiki/Manual:Fast_Path fastpath]'', um recurso que otimiza o encaminhamento de pacotes, aumentando grandemente o seu poder de processamento e tornando-os muito mais resilientes à travamentos devido à DDoS.

Caso o fastpath não seja possível, uma alternativa ao fastpath pode ser o [https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack fasttrack]. Apesar de ele ser menos eficaz que o fastpath e um pouco mais complexo, também pode reduzir bastante os danos causados por ataques.

==== Não crie regras de firewall para tentar mitigar ataques DDoS localmente ====
Provavelmente você não conseguirá mitigar ataques DDoS com regras de firewall triviais em roteadores, sobretudo softrouters como Mikrotik e VyOS. Por este motivo, evite usar regras de firewall, principalmente na tabela ''filter'' durante ataques. Estas regras, se mal utilizadas, ao invés de resolver o seu problema, irão aumentá-lo, fazendo com que o roteador tente processar todo o ataque ao invés de apenas encaminhar o tráfego para seu destino, causando seu travamento total.

Uma alternativa barata e eficaz para mitigar alguns ataques localmente é o uso de flowspec automatizado.

==== Teste as communities de blackhole periodicamente ====
Como explicado no artigo [[O Minimo que voce precisa saber sobre DDoS]], possuir um trânsito IP que não suporte blackhole não deve ser uma opção. Qualquer trânsito IP que não possua este recurso, sob qualquer pretexto, não deve ser considerado como uma opção. Alguns alegam que possuir uma mitigação elimina a necessidade de se ''possuir'' uma comunidade para RTBH, e isto não é uma verdade. Considere a possibilidade de um IP que não está em uso ser atacado e a mitigação falhar, e neste caso você pode resolver o problema simplesmente anunciando o prefixo IPv4 /32 para seu upstream com a comunidade de blackhole.

Tendo dito isto, recomendamos que testem periodicamente a eficácia das blackholes com todos os fornecedores, pois segundo a [https://pt.wikipedia.org/wiki/Lei_de_Murphy Lei de Murphy], os ataques acontecerão justamente quando as blackholes de seus fornecedores não estiverem funcionando devidamente.

==== Faça testes de detecção e mitigação constantemente ====
Aproveitando o ensejo do tópico anterior, recomendamos que seus sistemas de detecção e mitigação sejam testados periodicamente. E estes testes devem considerar os cenários mais distópicos possíveis, como a falta do IPv6, ataques de carpet bombing, ataques de grandes volumetrias e ataques de exaustão de recursos.

Testes assim podem ser feitos com utilitários como o hping3 executados remotamente.

É importante que se tenha uma check list de itens a se testar, como:
* Tempo de detecção;
* Eficácia da blackhole;
* Eficácia da mitigação;
* Efeitos colaterais causados (falhas na abertura de página ou carregamento de conteúdos, por ex);
* Precisão da detecção;
* Quantidade de tráfego sujo vazado pela mitigação.
Além disso, após mapear os possíveis problemas num ataque, também documente contra medidas a se tomar em casos de falhas.

==== Confirme o número de prefixos em blackhole aceitos pelos seus upstreams ====
Considerando um cenário caótico, onde sua mitigação em nuvem não está operacional e um ataque de carpet bombing está a atingir toda a rede, uma opção pode ser anunciar todos os IPs que não estão em uso para a blackhole em seu fornecedor. Isto fará o ataque ser reduzido ou até cessado em alguns casos. Sendo assim, sempre confirme qual a quantidade máxima de prefixos em blackhole que pode ser aceita por seu upstream sem que tua sessão BGP seja automaticamente desligada.

Um número sugerido é 25% do total de IPs de seu ASN ou de seu cone de clientes.

==== Confirme o número de prefixos totais aceitos pelos seus upstreams ====
Em cenários de crise, você poderá ter que desviar às pressas todo seu tráfego para um caminho protegido. Sendo um ISP que não vende trânsito para outros ASNs, este número total de prefixos anunciados pode não ser grande. Sendo um ITP (provedor de trânsito), considere a possibilidade de ter que desviar centenas ou milhares de prefixos simultânea e automaticamente para um único fornecedor. Portanto, procure sempre manter um número elevado na quantidade máxima de prefixos aceitos por seus fornecedores.

==== Anuncie os prefixos mais específicos com community de no-export para todos seus fornecedores ====
Durante uma convergência de rotas, seus prefixos podem sofrer loops de roteamento na Internet, causando uma indisponibilidade temporária. Este problema, quando esporádico, não traz grandes transtornos.

Entretanto épocas de ataques constantes exigem uma constante manipulação de prefixos de forma automática para que sejam mitigados.

Para que não tenhas indisponibilidade à cada desvio ou modificação de anúncio BGP, recomendamos que todos os prefixos mais específicos sejam anunciados com a community de no-export para todos os upstreams.

==== Adotar massivamente o uso de IPv6, inclusive no DNS ====
Como já devem ter percebido pelo tom deste artigo, para termos eficácia contra ataques, devemos pensar sempre nos cenários mais caóticos possíveis. E, considerando estes cenários, imagine que um dia você poderá ter que parar de anunciar seus próprios blocos IPv4 e terá que navegar com outros IPs através de um NAT. Ou até mesmo terá alguns problemas de navegação durante a mitigação de seus ataques.

Tanto numa situação de um NAT geral e emergencial, quanto num problema de navegação causado por uma proteção, certamente utilizar IPv6 reduzirá muito os impactos do ataque. Todos os grandes provedores de conteúdo, como Netflix, Google e Facebook já adotam IPv6 massivamente, e estes conteúdos provavelmente estarão livres de problemas se tu também adotares massivamente o uso do IPv6 na rede.

Artigo originalmente escrito por [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito].
[[Categoria:BCOPs]]
[[Categoria:Capacitação]]
[[Categoria:Roteamento]]

Looking Glass

2021-06-21T11:28:41Z

Daniel Damito: remoção do LG da Algar

A ferramenta Looking Glass, ou em uma tradução livre em português "espelho", é muito utilizada por operadores de rede Internet no mundo todo para visualizar suas rotas BGP e prefixos na tabela de roteamento de outros participantes.

O uso do Looking Glass pode ser muito útil para entender como suas rotas estão sendo tratadas, anunciadas, alteradas, bloqueadas, etc. Os melhores Looking Glass são aqueles que são roteadores reais (com acesso público somente leitura). Alguns inclusive permitem o usuário dar comandos como PING e TRACEROUTE (entenda aqui como o [[traceroute]] funciona).

Esta ferramenta pode ser muito útil ao solucionar problemas de roteamento da Internet; seja para o seu site,seu ASN ou para prefixos de parceiros e clientes. Abaixo segue uma lista não extensiva dos principais Looking Glass do Brasil e alguns mundiais:

== Lista de Looking Glass ==
'''Atualizada em 16/06/2021'''
{| class="wikitable sortable"
|+
Nacionais (Brasil)
!Rede
!ASN
!Looking Glass
!IPv4
!IPv6
|-
|Net Express Brasil
|265482
|https://lg.netexpressbrasil.com
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|-
|Equinix
|16397
|https://lg.equinix.com.br
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Algar Telecom
|16735
|telnet://201.48.0.2
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|IX.br São Paulo
|Vários
|telnet://lg.sp.ptt.br
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|IX.br ALICE
|Vários
|https://lg.ix.br/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|NetBotanic
|28338
|http://lg.netbotanic.com.br/lg.php
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Não.png|semmoldura]]
|-
|BitCom
|28169
|http://lg.bitcom.com.br/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Sumicity
|28210
|http://lg.sumicity.net.br/lg
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|G8
|28329
|https://lg.g8.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Wirelink
|28368
|http://lg.wirelink.com.br/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Use Telecom
|52871
|http://lg.tascom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Commcorp
|14840
|https://lg.commcorp.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Ultrawave Telecomunicações
|262659
|https://lg.ultrawave.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|ITS Telecomunicações
|28186
|https://lg.itsbrasil.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|W8 Telecom
|267469
|http://lg.w8telecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|OpenX
|263444
|http://lg.openx.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|K2 Telecom
|53181
|https://lg.k2telecom.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|TR Telecom
|266385
|http://www.isptools.com.br/traceroute#502!
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|UPX Technologies
|52863
|http://lg.upx.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Internexa
|262589
|<nowiki>ssh bgp_view@177.84.161.226 | senha bgp_view</nowiki>
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Eletronet
|267613
|http://looking-glass.eletronet.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|GVT
|18881
|telnet://route-server.gvt.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Forte Telecom
|263009
|https://lg.fortetelecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Net&Com
|263324
|http://lg.netecom.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Adylnet
|28283
|http://lg.adyl.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Globenet
|52320
|http://lg.globenet.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|DMC Telecom
|268551
|https://lg.dmctelecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|RNV Corp
|266201
|https://lg.rnv.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Conect Internet
|265066
|https://lg.conectrj.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Netway Telecom
|262403
|https://lg.netwt.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Wixnet
|53013
|http://wixnet.com.br/lg/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Aloo
|61568
|http://lg.alootelecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Altarede
|28260
|http://lg.altarede.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|SinalBR
|262761
|http://lg.sinalbr.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Asap Telecom
|264144
|http://lg.asaptelecom.com.br:8002/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Turbozone Internet
|264479
|https://as264479.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Linkwap
|61633
|http://lg.linkwap.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|N4TELECOM
|262505
|http://looking-glass.n4telecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Junto Telecom
|262596
|http://lg.juntotelecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|NBS Telecom
|61745
|http://lg.nbstelecom.psi.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Vogel Telecom
|25933
|http://lg.vogeltelecom.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Kinghost
|28299
|https://lg.kinghost.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Infortel
|53180
|https://lg.infortel.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Telic Technologies
|61595
|http://lg.telic.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|}

*
{| class="wikitable sortable"
|+
Internacionais
!Rede
!ASN
!Looking Glass
!IPv4
!IPv6
|-
|Seabone / Sparkle
|6762
|https://gambadilegno.noc.seabone.net/lg/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Stackpath
|12989
|https://lookingglass.hwng.net/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Lumen
|3356
|https://lookingglass.centurylink.com/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|NTT
|2914
|https://www.gin.ntt.net/looking-glass-landing/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Sprint
|1239
|https://www.sprint.net/lg
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Tata
|6453
|http://lg.as6453.net
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Telia
|1299
|https://lg.telia.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|HE
|6939
|http://lg.he.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Cogent
|174
|http://www.cogentco.com/en/network/looking-glass
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Zayo
|6461
|http://lg.zayo.com
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|NLNOG
|Vários
|http://lg.ring.nlnog.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|SoftLayer
|36351
|http://lg.softlayer.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|AT&T
|7018
|telnet://12.0.1.28
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|GTT (via Ginernet)
|3257
|http://gtt.lg.ginernet.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Telxius/TIWS
|12956
|https://telxius.com/looking-glass/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Orange (Opentransit)
|5511
|https://looking-glass.opentransit.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Worldstream (IPTV)
|49981
|https://lg.worldstream.nl
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|OVH
|16276
|https://lg.ovh.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|PJSC ROSTELECOM
|12389
|http://lg.ip.rt.ru/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|G-Core Labs
|199524
|https://lg.gcorelabs.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Leaseweb (hospeda SmartOLT)
|30633
|https://lg.leasewebstatus.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Angola Cables
|37468
|https://lg.angolacables.co.ao/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|EdgeUno
|7195
|https://lg.edgeuno.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Seaborn
|13786
|https://lg.as13786.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|}

==== <big>Destaques</big> ====
* Looking Glass da Tata que mostra um mapa visual da rota (http://lg.beta.as6453.net) 

* Looking Glass ALICE do IX.br, que agrega várias tabelas de IXs em diferentes cidades (https://lg.ix.br) 

* Looking Glass da NLNOG que mostra uma visão de múltiplos route-servers (http://lg.ring.nlnog.net)

* Looking Glass da Net Express Brasil permite a busca de AS Path no BGP utilizando expressões regulares (https://lg.netexpressbrasil.com)
*
*
==== <big>Looking Glass mais aguardado</big> ====
* ISPTools em http://www.isptools.com.br/lg
* .

[[Arquivo:Kisspng-emoji-sadness-emoticon-smiley-clip-art-sad-emoji-png-clipart-5a73fc019d1bb8.4272949715175505936435.png|esquerda|semmoldura|66x66px]]

==== <big>Ausências importantes:</big> ====
Redes importantes que não disponibilizam um Looking Glass BGP:

.

* Telefônica Vivo
* Claro/Embratel
* TIM
* Oi
* Copel
* Amazon
* Google
* Microsoft
* Akamai
[[Categoria:Interconexão]]
__INDEXAR__
[[Categoria:Roteamento]]

Looking Glass

2021-06-16T23:50:35Z

Daniel Damito: /* Lista de Looking Glass */

A ferramenta Looking Glass, ou em uma tradução livre em português "espelho", é muito utilizada por operadores de rede Internet no mundo todo para visualizar suas rotas BGP e prefixos na tabela de roteamento de outros participantes.

O uso do Looking Glass pode ser muito útil para entender como suas rotas estão sendo tratadas, anunciadas, alteradas, bloqueadas, etc. Os melhores Looking Glass são aqueles que são roteadores reais (com acesso público somente leitura). Alguns inclusive permitem o usuário dar comandos como PING e TRACEROUTE (entenda aqui como o [[traceroute]] funciona).

Esta ferramenta pode ser muito útil ao solucionar problemas de roteamento da Internet; seja para o seu site,seu ASN ou para prefixos de parceiros e clientes. Abaixo segue uma lista não extensiva dos principais Looking Glass do Brasil e alguns mundiais:

== Lista de Looking Glass ==
'''Atualizada em 20/05/2021'''
{| class="wikitable sortable"
|+
Nacionais (Brasil)
!Rede
!ASN
!Looking Glass
!IPv4
!IPv6
|-
|Net Express Brasil
|265482
|https://lg.netexpressbrasil.com
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|-
|Equinix
|16397
|https://lg.equinix.com.br
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Algar Telecom
|16735
|telnet://201.48.0.2
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Algar Telecom (versão WEB legada)
|16735
|http://lg.telic.cl
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|IX.br São Paulo
|Vários
|telnet://lg.sp.ptt.br
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|IX.br ALICE
|Vários
|https://lg.ix.br/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|NetBotanic
|28338
|http://lg.netbotanic.com.br/lg.php
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Não.png|semmoldura]]
|-
|BitCom
|28169
|http://lg.bitcom.com.br/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Sumicity
|28210
|http://lg.sumicity.net.br/lg
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|G8
|28329
|https://lg.g8.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Wirelink
|28368
|http://lg.wirelink.com.br/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Use Telecom
|52871
|http://lg.tascom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Commcorp
|14840
|https://lg.commcorp.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Ultrawave Telecomunicações
|262659
|https://lg.ultrawave.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|ITS Telecomunicações
|28186
|https://lg.itsbrasil.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|W8 Telecom
|267469
|http://lg.w8telecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|OpenX
|263444
|http://lg.openx.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|K2 Telecom
|53181
|https://lg.k2telecom.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|TR Telecom
|266385
|http://www.isptools.com.br/traceroute#502!
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|UPX Technologies
|52863
|http://lg.upx.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Internexa
|262589
|<nowiki>ssh bgp_view@177.84.161.226 | senha bgp_view</nowiki>
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Eletronet
|267613
|http://looking-glass.eletronet.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|GVT
|18881
|telnet://route-server.gvt.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Forte Telecom
|263009
|https://lg.fortetelecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Net&Com
|263324
|http://lg.netecom.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Adylnet
|28283
|http://lg.adyl.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Globenet
|52320
|http://lg.globenet.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|DMC Telecom
|268551
|https://lg.dmctelecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|RNV Corp
|266201
|https://lg.rnv.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Conect Internet
|265066
|https://lg.conectrj.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Netway Telecom
|262403
|https://lg.netwt.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Wixnet
|53013
|http://wixnet.com.br/lg/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Aloo
|61568
|http://lg.alootelecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Altarede
|28260
|http://lg.altarede.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|SinalBR
|262761
|http://lg.sinalbr.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Asap Telecom
|264144
|http://lg.asaptelecom.com.br:8002/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Turbozone Internet
|264479
|https://as264479.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Linkwap
|61633
|http://lg.linkwap.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|N4TELECOM
|262505
|http://looking-glass.n4telecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Junto Telecom
|262596
|http://lg.juntotelecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|NBS Telecom
|61745
|http://lg.nbstelecom.psi.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Vogel Telecom
|25933
|http://lg.vogeltelecom.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Kinghost
|28299
|https://lg.kinghost.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Infortel
|53180
|https://lg.infortel.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|}

*
{| class="wikitable sortable"
|+
Internacionais
!Rede
!ASN
!Looking Glass
!IPv4
!IPv6
|-
|Seabone / Sparkle
|6762
|https://gambadilegno.noc.seabone.net/lg/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Stackpath
|12989
|https://lookingglass.hwng.net/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Lumen
|3356
|https://lookingglass.centurylink.com/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|NTT
|2914
|https://www.gin.ntt.net/looking-glass-landing/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Sprint
|1239
|https://www.sprint.net/lg
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Tata
|6453
|http://lg.as6453.net
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Telia
|1299
|https://lg.telia.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|HE
|6939
|http://lg.he.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Cogent
|174
|http://www.cogentco.com/en/network/looking-glass
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Zayo
|6461
|http://lg.zayo.com
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|NLNOG
|Vários
|http://lg.ring.nlnog.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|SoftLayer
|36351
|http://lg.softlayer.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|AT&T
|7018
|telnet://12.0.1.28
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|GTT (via Ginernet)
|3257
|http://gtt.lg.ginernet.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Telxius/TIWS
|12956
|https://telxius.com/looking-glass/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Orange (Opentransit)
|5511
|https://looking-glass.opentransit.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Worldstream (IPTV)
|49981
|https://lg.worldstream.nl
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|OVH
|16276
|https://lg.ovh.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|PJSC ROSTELECOM
|12389
|http://lg.ip.rt.ru/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|G-Core Labs
|199524
|https://lg.gcorelabs.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Leaseweb (hospeda SmartOLT)
|30633
|https://lg.leasewebstatus.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Angola Cables
|37468
|https://lg.angolacables.co.ao/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|EdgeUno
|7195
|https://lg.edgeuno.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Seaborn
|13786
|https://lg.as13786.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|}

==== <big>Destaques</big> ====
* Looking Glass da Tata que mostra um mapa visual da rota (http://lg.beta.as6453.net) 

* Looking Glass ALICE do IX.br, que agrega várias tabelas de IXs em diferentes cidades (https://lg.ix.br) 

* Looking Glass da NLNOG que mostra uma visão de múltiplos route-servers (http://lg.ring.nlnog.net)

* Looking Glass da Net Express Brasil permite a busca de AS Path no BGP utilizando expressões regulares (https://lg.netexpressbrasil.com)
*
*
==== <big>Looking Glass mais aguardado</big> ====
* ISPTools em http://www.isptools.com.br/lg
* .

[[Arquivo:Kisspng-emoji-sadness-emoticon-smiley-clip-art-sad-emoji-png-clipart-5a73fc019d1bb8.4272949715175505936435.png|esquerda|semmoldura|66x66px]]

==== <big>Ausências importantes:</big> ====
Redes importantes que não disponibilizam um Looking Glass BGP:

.

* Telefônica Vivo
* Claro/Embratel
* TIM
* Oi
* Copel
* Amazon
* Google
* Microsoft
* Akamai
[[Categoria:Interconexão]]
__INDEXAR__
[[Categoria:Roteamento]]

Como escolher um transito IP

2021-05-10T16:39:11Z

Daniel Damito:

==Introdução==
A escolha de um trânsito IP (''upstream)'' deve ser bastante criteriosa, e não levar em consideração apenas o preço e a disponibilidade.

Antes de discorrer sobre este assunto, vale aqui relembrar sobre o conceito popular e errado do link ''IP Puro'', que é mais explicado [https://wiki.brasilpeeringforum.org/w/Enciclopedia_e_desciclopedia_da_telecom#IP_Puro neste link]. A Internet é baseada em peerings, como [https://wiki.brasilpeeringforum.org/w/Modelos_Interconex%C3%A3o#PNI_.28Private_network_Interconnect.29 PNIs], [https://wiki.brasilpeeringforum.org/w/Modelos_Interconex%C3%A3o#Public_Peering pontos de troca de tráfego] (IX's) e [https://wiki.brasilpeeringforum.org/w/CDN_Peering_e_PNI_-_Brasil CDNs], e é isto que torna a Internet atual sustentável, acessível e de boa qualidade. Desejar que seu upstream não anuncie seus prefixos nestes peerings, além de ser uma distopia, tornaria o seu trânsito IP pior e mais caro. Sendo assim, a primeira coisa que '''não''' se deve buscar em um upstream é o fornecimento de um trânsito ''IP Puro.''

Um outro grande mito muito difundido é de que as Tiers 1 são necessariamente melhores do que Tiers 2 e Tiers 3. Apesar de as Tiers 1 serem empresas geralmente maiores e mais consolidadas no mercado, isto nem sempre reflete melhor qualidade na prestação do serviço de trânsito IP, e isto pode acontecer por diversos motivos, como por não trocarem tráfego publicamente em IXs ou por não possuírem alguns critérios técnicos básicos, como o fornecimento de uma community de blackhole. Portanto, não restrinja sua busca por um fornecedor apenas à Tiers 1, a menos que tenha um motivo muito específico para isso.

== Critérios e requisitos técnicos a se analisar ==
Mais abaixo enumerarei alguns critérios e alguns requisitos técnicos que devem ser analisados, mas antes disto é bom reforçar que toda a avaliação técnica dos candidatos à fornecimento de trânsito IP devem ser feitas por emails, chamados ou propostas comerciais formais, e não apenas por ligações, conferências ou conversas de WhatsApp. Isto para que as promessas feitas antes da contração possam ser cobradas formalmente ou até judicialmente em caso de descumprimento da oferta.

Mencionarei as perguntas abaixo, que podem ou devem ser feitas, na segunda pessoa do plural para facilitar a cópia e a colagem à quem interessar.

Considere estas perguntas apenas como um norteador para sua busca, mas não como definitivas, visto que abrangem apenas alguns poucos requisitos técnicos mais comuns.

==== Vocês possuem uma community de blackhole? ====
Caso a resposta para esta pergunta seja não, cesse imediatamente a negociação com esta empresa. Como eu explico [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_voce_precisa_saber_sobre_DDoS neste artigo], um fornecedor de trânsito que não possua suporte à blackhole pode significar a sucumbência total de sua operação durante uma crise de ataques (D)DoS.

==== Qual o número máximo de prefixos em blackhole aceitos por vocês? ====
Convém que você calcule um número médio e razoável de prefixos não utilizados por seu sistema autônomo e que potencialmente podem ser anunciados para a blackhole simultaneamente em casos de ataques distribuídos. Um número máximo muito pequeno, como 5 ou 10 pode ser insuficiente durante uma crise, portanto sempre peça um número de prefixos máximos de blackhole igual ou superior à média de IPs não utilizados por sua empresa.

==== Qual o número máximo de prefixos totais aceitos por vocês? ====
Caso você possua um prefixo IPv4 /20 e um prefixo IPv6 /32, não é difícil imaginar uma situação onde seja necessário desagregar alguns anúncios em prefixos /24 IPv4 ou /36 IPv6. Neste exemplo você poderia chegar em até 32 anúncios IPv4 simultaneamente ou 15 anúncios simultâneos em IPv6. Isto sem contar com eventuais downstreams. Portanto, coloque como requisito de prefixos máximos a quantidade necessária para sua operação.

==== Vocês possuem um Looking Glass? Se sim, qual a URL? ====
Além de sugerir uma empresa dedicada, possuir um Looking Glass também pode facilitar a conferência das adjacências informadas pela empresa e ajudar em troubleshootings futuros. Apesar de esta não ser uma condição fundamental para a contratação de um trânsito IP, considere comprar sempre de uma empresa que possua um Looking Glass.

==== Vocês possuem communities BGP informativas nas rotas que exportam à seus clientes? Se sim, podem nos informar, por favor? ====
As communities BGP informativas te ajudarão a tomar melhores decisões de upload de sua rede. Você pode ter abordagens de engenharia de tráfego mais refinadas configurando um ''local-pref'' maior em prefixos recebidos desta empresa de lugares ou peerings por onde ela tenha uma conexão privilegiada.

==== Vocês aceitam communities BGP para que possamos manipular nosso tráfego (nosso sentido de download)? Se sim, podem nos informar, por favor? ====
Este não pode ser um pré requisito técnico exigido à um fornecedor de trânsito IP, visto que para onde seus prefixos serão exportados é uma escolha exclusiva de seu fornecedor. Entretanto, caso você prefira ou necessite ser anunciado para lugares específicos, é neste ponto que o candidato à upstream deve te informar se isto será possível.

==== Quais são os upstreams (fornecedores de trânsito) de vocês para os quais vocês anunciarão nossos prefixos e de nossos outros downstreams? Se possível, descrever as conectividades de Peering também. ====
Caso seu candidato à fornecedor possua um upstream importante para você, não significa que ele te anunciará necessariamente para este ASN. O objetivo desta pergunta é confirmar para onde seus prefixos serão anunciados em caso de contratação.

==== Para quais IX's vocês exportarão nossos prefixos e de nossos clientes? ====
A explicação para esta pergunta é a mesma da pergunta anterior.

==== Vocês utilizam IRR? ====
A utilização de IRR mitiga a falha humana na confecção de filtros BGP e pode diminuir o tempo de ativação de novos prefixos se necessário. Considere este ponto como crítico caso você seja um fornecedor de trânsito IP (ITP).

==== Caso utilizem IRR, aceitam a ativação de novos prefixos exclusivamente por ele? ====
Novamente, utilizar IRR não significa que ele seja totalmente utilizado. Empresas que aceitam a ativação de novos prefixos/downstreams exclusivamente por IRR, além de agilizar a ativação de novos prefixos, também podem permitir que você faça automações no setup de novos downstreams.

==== As vossas políticas de BGP são exatamente iguais para IPv4 e IPv6? Com isto quero dizer: tudo o que fazem em IPv4, fazem igualmente em IPv6? ====
Algumas empresas possuem IPv6 apenas por ser um pré requisito técnico exigido para a aquisição de novos blocos de IPv4, e por isso não tratam o IPv6 com a mesma prioridade do IPv4. Além de questionar seu candidato à upstream com esta pergunta, você também pode conferir se ele mantém as mesmas conexões em IPv6 e em IPv4 em sites como https://bgpview.io/ e https://radar.qrator.net/.

==== Vocês possuem selo MANRS? ====
O [[MANRS]] é uma iniciativa que busca melhorar a segurança, cooperação e comunicação entre os sistemas autônomos da Internet. Aderir ao MANRS significa não só ser uma empresa competente, mas também atesta a preocupação da empresa com a segurança e cooperação global da Internet.

==== Outras perguntas relevantes para seu negócio ====
Estas perguntas foram apenas algumas sugestões de itens que geralmente não são questionados/avaliados. Convém refletir sobre quais outros pontos são fundamentais para sua operação, como a possibilidade de compra na modalidade de 95th percentile, redundância física e lógica e fornecimento de IPs públicos adicionais para estabelecimentos de túneis GRE para clean pipes, se necessário.

Sendo assim, faça um levantamento em sua organização de quais outros requisitos ou diferenciais técnicos são importantes em sua organização e questione também sobre eles.

==== Vocês oferecem a modalidade de contratação Burstable com 95th percentile? Se sim qual a razão entre o o Commit mínimo e o velocidade de Burst que vocês oferecem ? ====
Contratar um Transito IP que ofereça a modalidade Burstable com 95th percentile traz uma flexibilidade muito grande tanto para o cliente quanto para o fornecedor em momentos de uso de pico, principalmente quando há falha temporária de outro upstream ou IX, e garante a operação sem o risco de saturação de portas e sem a necessidade de solicitar ajustes temporários da velocidade para o Gerente de Contas ou NOC do fornecedor. Este assunto é bem explorado [https://www.youtube.com/watch?v=WjSps5huDGU neste painel] realizado durante o GTER 46.

== Como compilar e avaliar estas respostas ==
Como explicado [https://www.youtube.com/watch?v=Fo-cmSSC3uo nesta palestra], uma das formas de se avaliar os candidatos à fornecedor de trânsito IP é criando uma planilha de avaliação, pontuando as respostas de cada um dos fornecedores com os pesos mais importantes para você.

É importante ter uma visão realista do negócio e também considerar o preço do mega nesta avaliação, visto que ele também é um dos fatores críticos na escolha. Quando digo considerar, é apenas adicionar este como um dos itens a ser avaliado, e não o único ou principal. Muitas vezes um trânsito IP barato, mas de má qualidade, pode trazer prejuízos financeiros diretos ou indiretos maiores do que a própria economia ofertada pela empresa.

Artigo originalmente escrito por [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito].
[[Categoria:Interconexão]]

Boas Praticas para Melhorar a Seguranca de seu Provedor

2021-04-29T15:55:12Z

Daniel Damito:

__TOC__
=== Introdução ===
Aplicar boas práticas de segurança em Provedores de Internet faz parte do trabalho diário de operadores de redes e sistemas autônomos em geral como forma de assegurar, não apenas a boa operação da redes pelos quais é responsável e dos serviços prestados à seus clientes, mas também de modo a evitar que sua rede seja utilizada como fonte de problemas para redes de terceiros. Sendo a Internet uma interconexão de milhares de redes, se faz necessário a colaboração de todos os operadores de redes e sistemas autônomos em um esforço conjunto para se evitar que ocorram ataques, indisponibilidades, spam e consequentemente a perda da qualidade de navegação do usuário final e aumento de custos para todos.

Desde o surgimento da Internet a colaboração mútua de profissionais de diversas áreas tem sido essencial para se criar boas práticas para operação de redes e sistemas autônomos, sendo altamente recomendado segui-las e implementá-las, principalmente em ambientes que prestam serviço de acesso para milhares de usuários finais.

Para implementação de muitas dessas práticas nem sempre é necessário realizar grandes investimentos em equipamentos, mas apenas instruir a equipe responsável para que observem e sigam os guias de boas práticas existentes como também respondam à eventuais incidentes de segurança envolvendo a rede ou sistema autônomo pelo qual é responsável.

Nesse sentido o [https://nic.br/ Núcleo de Informação e Coordenação do Ponto BR (NIC.br)] há anos tem realizado um trabalho importante com iniciativas como a gerência da porta 25 e mais recentemente o [https://bcp.nic.br/ Programa por uma Internet mais Segura] e o [https://bcp.nic.br/manrs MARNS] para ajudar a melhorar a segurança dos sistemas autônomos Brasileiros.

=== Boas Práticas Gerais ===
Abaixo encontra-se uma lista não exaustiva de boas práticas a serem observadas por todos aqueles interessados em certifica-se de diversos aspectos de segurança na operação de um sistema autônomo. Como a lista pode receber novas recomendações é recomendado consultá-la de tempos em tempos para se certificar de que esteja operando sempre com as melhores práticas de segurança.
# '''Implementar as quatro ações do MARNS''' - https://bcp.nic.br/manrs
## Filtros de rotas de entrada e saída: evita o sequestro de prefixos (hijacking) e vazamento de rotas (leak). Verifique na ferramenta BGPStream (https://bgpstream.com/) se seu AS tem participado de sequestro de prefixos, vazamento de rotas ou ainda se houve outage envolvendo seu AS. A ferramenta dá uma visão dos últimos 180 dias.
## Implementar filtros de entrada antispoofing: evita que seus clientes gerem tráfego com endereço de origem alterado (spoofado) e iniciem ataques DoS tráfego spoofado e amplificado por destinos vulneráveis. Utilize a ferramenta CAIDA para verificar se em seu AS há medições de possibilidade de envio de tráfego spoofado e instale o software cliente do CAIDA (<nowiki>https://www.caida.org/projects/spoofer/</nowiki>) em segmentos de sua rede para verificar se ela permite tráfego spoofado.
## Atualizar os pontos de contato como mínimo no WHOIS e PeeringDB e também no RADb, como desejável.
## Publicar suas políticas de roteamento/ no RADb (desejável).
# '''Atender às notificações do [https://www.cert.br/ CERT.br]''' para serviços mal configurados que deixam portas abertas que podem ser abusadas. O CERT.br analisa 12 protocolos mensalmente (SNMP, DNS, NTP, SSDP, PORTMAP, NETBIOS, MDNS, MEMCACHED, CHARGEN, QOTD, LDAP e Service Discovery da Ubiquiti) e encaminha notificações com os IP ofensores, por AS, para o email que consta como Abuse no Whois.
# '''Implementar ações de hardening''' mapeando ameaças, mitigando riscos e tomando ações corretivas. Há várias dicas sobre autenticação, autorização, acesso, sistema e configurações na apresentação https://www.cert.br/docs/palestras/certbr-formacao-professores2019-turma01.pdf. Tópicos adicionais de hardening são apresentados nos cursos BCOP do NIC.br - https://cursoseventos.nic.br/curso/curso-bcop/
# '''Implementar gerência de porta 25''' - http://www.antispam.br/admin/porta25/

=== Boas Práticas Especificas ===
Além das boas práticas gerais apresentadas acima é também altamente recomendado acompanhar a divulgação de patches de segurança, lançamento de novas versões de firmware/software e publicação de release notes de fabricantes de equipamentos de rede e softwares, utilizados na operação do provedor, para ficar sabendo quando alguma vulnerabilidade foi encontrada e corrigida e reduzir o tempo de exposição da sua rede para a Internet.

Cada fabricante mantém diferentes sistemas e métodos para dar publicidade à esses anúncios. As URLs abaixo são uma referência para algumas dessas ferramentas utilizadas pelos diferentes fabricantes e conteúdo relacionado.

'''Cisco'''

https://tools.cisco.com/security/center/softwarechecker.x

https://tools.cisco.com/security/center/publicationListing.x

'''Juniper'''

https://kb.juniper.net/InfoCenter/index?page=content&channel=SECURITY_ADVISORIES

'''Huawei'''

https://www.huawei.com/en/psirt/all-bulletins

'''Mikrotik'''

https://blog.mikrotik.com/security/

https://wiki.mikrotik.com/wiki/Manual:Securing_Your_Router

[[Boas práticas de segurança para roteadores Mikrotik]]
[[Categoria:BCOPs]]

Como funciona o traffic policy no Huawei

2021-03-31T02:47:22Z

Daniel Damito:

=== 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.

[[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 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).
<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 ====

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.

<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.

<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.

<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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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:

<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.

==== 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 [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.

Não consegui encontrar uma documentação mais generalista sobre traffic classifier na base de conhecimento da Huawei, mas [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier 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 [https://support.huawei.com/enterprise/en/doc/EDOC1000174073/c8e4d153/configuring-a-traffic-behavior neste artigo].

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 ====
É 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:

<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.

==== 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:''' <code>traffic-policy RedirToAnalyzer global inbound</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer global outbound</code>

* '''Aplicando globalmente em roteadores'''
** '''Para tráfego entrante:''' <code>traffic-policy RedirToAnalyzer inbound global-acl</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer outbound global-acl</code>

* '''Aplicando apenas em uma interface (switch ou roteador):''' <code>interface 100GE0/3/2</code> <code>traffic-policy RedirToAnalyzerinbound</code>

Artigo por [[Usuário:Daniel Damito|Daniel Damito]]
[[Categoria:Geral]]
[[Categoria:Roteamento]]
[[Categoria:Capacitação]]

Como funciona o traffic policy no Huawei

2021-03-23T01:44:15Z

Daniel Damito:

=== 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 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 NAT Server. Este NAT Server 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:

'''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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

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 o tráfego, sem nenhuma outra manipulação.

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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:

<code>acl number 3001</code>

<code>rule 5 permit ip destination 8.8.8.8 0.0.0.0</code>

Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 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 [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:

<code>traffic classifier FromMyDeviceToGoogle operator and</code>

<code>if-match acl 3001</code>

<code>if-match source-mac aabb-ccdd-eeff</code>

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 [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier 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 [https://support.huawei.com/enterprise/en/doc/EDOC1000174073/c8e4d153/configuring-a-traffic-behavior neste artigo].

Para criar um traffic behavior que redirecione o tráfego para um determinado next-hop você poderia usar os seguintes comandos:

<code>traffic behavior Redirect-to-Analyzer</code>

<code>redirect ip-nexthop 172.16.0.2</code>

==== 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:

<code>traffic policy RedirToAnalyzer</code>

<code>classifier FromMyDeviceToGoogle behavior Redirect-to-Analyzer</code>

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.

==== 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:''' <code>traffic-policy RedirToAnalyzer global inbound</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer global outbound</code>

* '''Aplicando globalmente em roteadores'''
** '''Para tráfego entrante:''' <code>traffic-policy RedirToAnalyzer inbound global-acl</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer outbound global-acl</code>

* '''Aplicando apenas em uma interface (switch ou roteador):''' <code>interface 100GE0/3/2</code> <code>traffic-policy RedirToAnalyzerinbound</code>

Artigo por [[Usuário:Daniel Damito|Daniel Damito]]
[[Categoria:Geral]]
[[Categoria:Capacitação]]

Como funciona o traffic policy no Huawei

2021-03-21T02:45:09Z

Daniel Damito:

=== 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 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 NAT Server. Este NAT Server 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:

'''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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

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 o tráfego, sem nenhuma outra manipulação.

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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:

<code>acl number 3001</code>

<code>rule 5 permit ip destination 8.8.8.8 0.0.0.0</code>

Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 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 [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:

<code>traffic classifier FromMyDeviceToGoogle operator and</code>

<code>if-match acl 3001</code>

<code>if-match source-mac aabb-ccdd-eeff</code>

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 [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier 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 [https://support.huawei.com/enterprise/en/doc/EDOC1000174073/c8e4d153/configuring-a-traffic-behavior neste artigo].

Para criar um traffic behavior que redirecione o tráfego para um determinado next-hop você poderia usar os seguintes comandos:

<code>traffic behavior Redirect-to-Analyzer</code>

<code>redirect ip-nexthop 172.16.0.2</code>

==== 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:

<code>traffic policy RedirToAnalyzer</code>

<code>classifier FromMyDeviceToGoogle behavior Redirect-to-Analyzer</code>

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.

==== 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:''' <code>traffic-policy RedirToAnalyzer global inbound</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer global inbound</code>

* '''Aplicando globalmente em roteadores'''
** '''Para tráfego entrante:''' <code>traffic-policy RedirToAnalyzer inbound global-acl</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer outbound global-acl</code>

* '''Aplicando apenas em uma interface (switch ou roteador):''' <code>interface 100GE0/3/2</code> <code>traffic-policy RedirToAnalyzerinbound</code>

Artigo por [[Usuário:Daniel Damito|Daniel Damito]]
[[Categoria:Geral]]
[[Categoria:Capacitação]]

Como funciona o traffic policy no Huawei

2021-03-21T02:37:47Z

Daniel Damito:

=== 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

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 o tráfego, sem nenhuma outra manipulação.

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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:

<code>acl number 3001</code>

<code>rule 5 permit ip destination 8.8.8.8 0.0.0.0</code>

Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 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 [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:

<code>traffic classifier FromMyDeviceToGoogle operator and</code>

<code>if-match acl 3001</code>

<code>if-match source-mac aabb-ccdd-eeff</code>

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 [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier 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 [https://support.huawei.com/enterprise/en/doc/EDOC1000174073/c8e4d153/configuring-a-traffic-behavior neste artigo].

Para criar um traffic behavior que redirecione o tráfego para um determinado next-hop você poderia usar os seguintes comandos:

<code>traffic behavior Redirect-to-Analyzer</code>

<code>redirect ip-nexthop 172.16.0.2</code>

==== 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:

<code>traffic policy RedirToAnalyzer</code>

<code>classifier FromMyDeviceToGoogle behavior Redirect-to-Analyzer</code>

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.

==== 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:''' <code>traffic-policy RedirToAnalyzer global inbound</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer global inbound</code>

* '''Aplicando globalmente em roteadores'''
** '''Para tráfego entrante:''' <code>traffic-policy RedirToAnalyzer inbound global-acl</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer outbound global-acl</code>

* '''Aplicando apenas em uma interface (switch ou roteador):''' <code>interface 100GE0/3/2</code> <code>traffic-policy RedirToAnalyzerinbound</code>

Artigo por [[Usuário:Daniel Damito|Daniel Damito]]
[[Categoria:Geral]]
[[Categoria:Capacitação]]

Usuário:Daniel Damito

2021-03-21T02:26:46Z

Daniel Damito:

== Resumo ==
Daniel Damito é especialista na área de redes de computadores, com ênfase em roteamento e segurança.

É fundador e diretor da [https://sagenetworks.com.br/ Sage Networks], empresa de consultoria de redes.

Possui formação acadêmica de nível superior na área de Redes de Computadores, e pós graduação lato sensu também na Área de Redes de Computadores.

É um dos fundadores do projeto 3BR (ainda em desenvolvimento) e participante ativo no [https://wiki.brasilpeeringforum.org/w/Quem_Somos BPF].

É coordenador da ''Task Force'' de IPv6 do BPF.

== Artigos Escritos ==
[[Arquivo:Daniel Damito.jpg|miniaturadaimagem]]

[[Porque usar um DNS local e algumas dicas para isto]]

[[Como consultar e corrigir a geolocalizacao de seus IPs]]

[[PeeringDB - como se cadastrar e atualizar seus dados]]

[[Boas práticas de segurança para roteadores Mikrotik]]

[[Diferenca entre AS-OVERRIDE e ALLOWAS-IN]]

[https://wiki.brasilpeeringforum.org/w/Como_reportar_abusos_ao_Google Como reportar abusos ao Google]

[https://wiki.brasilpeeringforum.org/w/Como_fazer_com_que_um_determinado_conteudo_saia_por_um_link_especifico Como fazer com que um determinado conteudo saia por um link especifico]

[https://wiki.brasilpeeringforum.org/w/Como_capturar_pacotes_no_Mikrotik Como capturar pacotes no Mikrotik]

[[O Minimo que voce precisa saber sobre DDoS]]

[[Comandos de linux úteis para troubleshooting de redes]]

[[Como escolher um transito IP]]

[[Boas praticas para cenarios de DDoS]]

[[Como funciona o traffic policy no Huawei]]

== Contatos ==
'''LinkedIn:''' https://www.linkedin.com/in/daniel-damito-3b25b8b6/

'''E-mail pessoal:''' contato@danieldamito.com.br

'''E-mail profissional:''' daniel.damito@sagenetworks.com.br

Como funciona o traffic policy no Huawei

2021-03-21T02:26:11Z

Daniel Damito:

= '''ARTIGO EM CONSTRUÇÃ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 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

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 o tráfego, sem nenhuma outra manipulação.

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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:

<code>acl number 3001</code>

<code>rule 5 permit ip destination 8.8.8.8 0.0.0.0</code>

Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 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 [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:

<code>traffic classifier FromMyDeviceToGoogle operator and</code>

<code>if-match acl 3001</code>

<code>if-match source-mac aabb-ccdd-eeff</code>

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 [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier 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 [https://support.huawei.com/enterprise/en/doc/EDOC1000174073/c8e4d153/configuring-a-traffic-behavior neste artigo].

Para criar um traffic behavior que redirecione o tráfego para um determinado next-hop você poderia usar os seguintes comandos:

<code>traffic behavior Redirect-to-Analyzer</code>

<code>redirect ip-nexthop 172.16.0.2</code>

==== 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:

<code>traffic policy RedirToAnalyzer</code>

<code>classifier FromMyDeviceToGoogle behavior Redirect-to-Analyzer</code>

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.

==== 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:''' <code>traffic-policy RedirToAnalyzer global inbound</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer global inbound</code>

* '''Aplicando globalmente em roteadores'''
** '''Para tráfego entrante:''' <code>traffic-policy RedirToAnalyzer inbound global-acl</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer outbound global-acl</code>

* '''Aplicando apenas em uma interface (switch ou roteador):''' <code>interface 100GE0/3/2</code> <code>traffic-policy RedirToAnalyzerinbound</code>

Artigo por [[Usuário:Daniel Damito|Daniel Damito]]
[[Categoria:Geral]]
[[Categoria:Capacitação]]

Como funciona o traffic policy no Huawei

2021-03-21T02:04:20Z

Daniel Damito: /* Aplicando o traffic policy */

Como funciona o traffic policy no Huawei

2021-03-21T02:03:41Z

Daniel Damito:

= '''ARTIGO EM CONSTRUÇÃ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 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

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 o tráfego, sem nenhuma outra manipulação.

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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:

<code>acl number 3001</code>

<code>rule 5 permit ip destination 8.8.8.8 0.0.0.0</code>

Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 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 [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:

<code>traffic classifier FromMyDeviceToGoogle operator and</code>

<code>if-match acl 3001</code>

<code>if-match source-mac aabb-ccdd-eeff</code>

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 [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier 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 [https://support.huawei.com/enterprise/en/doc/EDOC1000174073/c8e4d153/configuring-a-traffic-behavior neste artigo].

Para criar um traffic behavior que redirecione o tráfego para um determinado next-hop você poderia usar os seguintes comandos:

<code>traffic behavior Redirect-to-Analyzer</code>

<code>redirect ip-nexthop 172.16.0.2</code>

==== 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:

<code>traffic policy RedirToAnalyzer</code>

<code>classifier FromMyDeviceToGoogle behavior Redirect-to-Analyzer</code>

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.

==== 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:''' <code>traffic-policy RedirToAnalyzer global inbound</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer global inbound</code>

* '''Aplicando globalmente em roteadores'''
** '''Para tráfego entrante:''' <code>traffic-policy RedirToAnalyzer inbound global-acl</code>
** '''Para tráfego sainte:''' <code>traffic-policy RedirToAnalyzer outbound global-acl</code>

* '''Aplicando apenas em uma interface (switch ou roteador)''' <code>interface 100GE0/3/2</code> <code>traffic-policy RedirToAnalyzerinbound</code>

Como funciona o traffic policy no Huawei

2021-03-21T02:00:23Z

Daniel Damito:

= '''ARTIGO EM CONSTRUÇÃ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 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

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 o tráfego, sem nenhuma outra manipulação.

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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:

<code>acl number 3001</code>

<code>rule 5 permit ip destination 8.8.8.8 0.0.0.0</code>

Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 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 [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:

<code>traffic classifier FromMyDeviceToGoogle operator and</code>

<code>if-match acl 3001</code>

<code>if-match source-mac aabb-ccdd-eeff</code>

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 [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier 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 [https://support.huawei.com/enterprise/en/doc/EDOC1000174073/c8e4d153/configuring-a-traffic-behavior neste artigo].

Para criar um traffic behavior que redirecione o tráfego para um determinado next-hop você poderia usar os seguintes comandos:

<code>traffic behavior Redirect-to-Analyzer</code>

<code>redirect ip-nexthop 172.16.0.2</code>

==== 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:

<code>traffic policy RedirToAnalyzer</code>

<code>classifier FromMyDeviceToGoogle behavior Redirect-to-Analyzer</code>

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.

==== 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''' <code>traffic-policy RedirToAnalyzer global inbound</code>
** '''Para tráfego sainte''' <code>traffic-policy RedirToAnalyzer global inbound</code>

'''Aplicando globalmente em roteadores'''
* '''Para tráfego entrante''' <code>traffic-policy RedirToAnalyzer inbound global-acl</code>
* '''Para tráfego sainte''' <code>traffic-policy RedirToAnalyzer outbound global-acl</code>

Como funciona o traffic policy no Huawei

2021-03-21T01:56:40Z

Daniel Damito:

= '''ARTIGO EM CONSTRUÇÃ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 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

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 o tráfego, sem nenhuma outra manipulação.

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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:

<code>acl number 3001</code>

<code>rule 5 permit ip destination 8.8.8.8 0.0.0.0</code>

Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 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 [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:

<code>traffic classifier FromMyDeviceToGoogle operator and</code>

<code>if-match acl 3001</code>

<code>if-match source-mac aabb-ccdd-eeff</code>

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 [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier 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 [https://support.huawei.com/enterprise/en/doc/EDOC1000174073/c8e4d153/configuring-a-traffic-behavior neste artigo].

Para criar um traffic behavior que redirecione o tráfego para um determinado next-hop você poderia usar os seguintes comandos:

<code>traffic behavior Redirect-to-Analyzer</code>

<code>redirect ip-nexthop 172.16.0.2</code>

==== 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:

<code>traffic policy RedirToAnalyzer</code>

<code>classifier FromMyDeviceToGoogle behavior Redirect-to-Analyzer</code>

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.

==== 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 <code>RedirToAnalyzer</code> global inbound

====== Para tráfego sainte ======
traffic-policy <code>RedirToAnalyzer</code> global inbound

Como funciona o traffic policy no Huawei

2021-03-21T01:25:23Z

Daniel Damito: /* traffic classifier */

= '''ARTIGO EM CONSTRUÇÃ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 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

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 o tráfego, sem nenhuma outra manipulação.

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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 os 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:

<code>acl number 3001</code>

<code>rule 5 permit ip destination 8.8.8.8 0.0.0.0</code>

Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 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 [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:

<code>traffic classifier FromMyDeviceToGoogle operator and</code>

<code>if-match acl 3001</code>

<code>if-match source-mac aabb-ccdd-eeff</code>

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 [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier esta] que explica o recurso no contexto de QoS se aplica bem em quase todos os cenários.

==== traffic behavior ====

==== traffic policy ====

Como funciona o traffic policy no Huawei

2021-03-21T01:15:22Z

Daniel Damito: /* traffic classifier */

= '''ARTIGO EM CONSTRUÇÃ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 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

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 o tráfego, sem nenhuma outra manipulação.

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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 os 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:

<code>acl number 3001</code>

<code>rule 5 permit ip destination 8.8.8.8 0.0.0.0</code>

Dar match em todo tráfego cujo mac-address seja AA:BB:CC:DD:EE:FF

<code>acl number 4001</code>

<code>rule 1 permit source-mac aabb-ccdd-eeff</code>

Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 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 [https://support.huawei.com/enterprise/en/doc/EDOC1000178177/4ae8136/acl-classification nesta documentação]. Sendo assim, nós precisamos trabalhar com duas ACLs diferentes, somando os critérios de ambas. A seção anterior onde explicamos sobre ACLs mostra como fazer a ACL para estes dois mesmos critérios. Sendo assim, para agrupá-las num único traffic classifier podemos fazer da seguinte forma:

Não consegui encontrar uma documentação mais generalista sobre traffic classifier na base de conhecimento da Huawei, mas [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier esta] que explica o recurso no contexto de QoS se aplica bem em quase todos os cenários.

==== traffic behavior ====

==== traffic policy ====

Como funciona o traffic policy no Huawei

2021-03-13T18:50:04Z

Daniel Damito:

= '''ARTIGO EM CONSTRUÇÃ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 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

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 o tráfego, sem nenhuma outra manipulação.

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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 os 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 cuja origem for 192.0.2.0/4:

<code>acl number 3001</code>

<code>rule 5 permit ip source 192.0.2.0 0.0.0.255</code>

Dar match em tudo cujo destino for 8.8.8.8/32

<code>acl number 3002</code>

<code>rule 5 permit ip destination 8.8.8.8 0.0.0.0</code>

Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 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

Não consegui encontrar uma documentação mais generalista sobre traffic classifier na base de conhecimento da Huawei, mas [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier esta] que explica o recurso no contexto de QoS se aplica bem em quase todos os cenários.

==== traffic behavior ====

==== traffic policy ====

Como funciona o traffic policy no Huawei

2021-03-13T18:38:55Z

Daniel Damito: /* traffic classifier */

= '''ARTIGO EM CONSTRUÇÃ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 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

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 o tráfego, sem nenhuma outra manipulação.

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

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.

<code>traffic policy P-CGNAT</code>

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.

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

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.

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

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.

<code>traffic-policy P-CGNAT inbound global-acl</code>

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 os 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 cuja origem for 192.0.2.0/4:

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

Dar match em tudo cujo destino for 8.8.8.8/32

<code>acl number 3002</code>

<code>rule 5 permit ip destination 8.8.8.8 0.0.0.0</code>

Esta [https://support.huawei.com/enterprise/br/doc/EDOC1100086647 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, exceto quando a origem for a rede 192.0.2.0/24. Isto não seria possível apenas com uma ACL, portanto devemos criar uma ACL que dê match

Não consegui encontrar uma documentação mais generalista sobre traffic classifier na base de conhecimento da Huawei, mas [https://support.huawei.com/enterprise/en/doc/EDOC1000178175/a9a36e17/configuring-a-traffic-classifier esta] que explica o recurso no contexto de QoS se aplica bem em quase todos os cenários.

==== traffic behavior ====

==== traffic policy ====

Como funciona o traffic policy no Huawei

2021-03-13T18:24:52Z

Daniel Damito:

Como funciona o traffic policy no Huawei

2021-03-13T18:15:25Z

Daniel Damito:

Como funciona o traffic policy no Huawei

2021-03-10T01:21:39Z

Daniel Damito:

Como funciona o traffic policy no Huawei

2021-03-10T01:19:06Z

Daniel Damito:

Como funciona o traffic policy no Huawei

2021-03-10T01:17:10Z

Daniel Damito: w

Como funciona o traffic policy no Huawei

2021-03-10T01:14:18Z

Daniel Damito:

Como funciona o traffic policy no Huawei

2021-03-10T01:10:41Z

Daniel Damito:

Como funciona o traffic policy no Huawei

2021-03-10T01:06:10Z

Daniel Damito:

Como funciona o traffic policy no Huawei

2021-03-10T00:52:02Z

Daniel Damito:

Looking Glass

2021-03-08T16:00:02Z

Daniel Damito: /* Lista de Looking Glass */

A ferramenta Looking Glass, ou em uma tradução livre em português "espelho", é muito utilizada por operadores de rede Internet no mundo todo para visualizar suas rotas BGP e prefixos na tabela de roteamento de outros participantes.

O uso do Looking Glass pode ser muito útil para entender como suas rotas estão sendo tratadas, anunciadas, alteradas, bloqueadas, etc. Os melhores Looking Glass são aqueles que são roteadores reais (com acesso público somente leitura). Alguns inclusive permitem o usuário dar comandos como PING e TRACEROUTE (entenda aqui como o [[traceroute]] funciona).

Esta ferramenta pode ser muito útil ao solucionar problemas de roteamento da Internet; seja para o seu site,seu ASN ou para prefixos de parceiros e clientes. Abaixo segue uma lista não extensiva dos principais Looking Glass do Brasil e alguns mundiais:

== Lista de Looking Glass ==
'''Atualizada em 08/03/2021'''
{| class="wikitable sortable"
|+
Nacionais (Brasil)
!Rede
!ASN
!Looking Glass
!IPv4
!IPv6
|-
|Equinix
|16397
|https://lg.equinix.com.br
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Algar Telecom
|16735
|http://lg.algartelecom.com.br
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|IX.br São Paulo
|Vários
|telnet://lg.sp.ptt.br
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|IX.br ALICE
|Vários
|https://lg.ix.br/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|NetBotanic
|28338
|http://lg.netbotanic.com.br/lg.php
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Não.png|semmoldura]]
|-
|BitCom
|28169
|http://lg.bitcom.com.br/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Sumicity
|28210
|http://lg.sumicity.net.br/lg
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|G8
|28329
|https://lg.g8.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Wirelink
|28368
|http://lg.wirelink.com.br/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Use Telecom
|52871
|http://lg.tascom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Commcorp
|14840
|https://lg.commcorp.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Ultrawave Telecomunicações
|262659
|https://lg.ultrawave.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|ITS Telecomunicações
|28186
|https://lg.itsbrasil.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|KingHost
|28299
|https://lg.kinghost.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|W8 Telecom
|267469
|http://lg.w8telecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|OpenX
|263444
|http://lg.openx.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|K2 Telecom
|53181
|https://lg.k2telecom.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|UPX Technologies
|52863
|http://lg.upx.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Internexa
|262589
|<nowiki>ssh bgp_view@177.84.161.226 | senha bgp_view</nowiki>
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Eletronet
|267613
|http://looking-glass.eletronet.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|GVT
|18881
|telnet://route-server.gvt.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Forte Telecom
|263009
|https://lg.fortetelecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Net&Com
|263324
|http://lg.netecom.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Adylnet
|28283
|http://lg.adyl.net.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Globenet
|52320
|http://lg.globenet.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|DMC Telecom
|268551
|https://lg.dmctelecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|RNV Corp
|266201
|https://lg.rnv.net.br
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Conect Internet
|265066
|https://lg.conectrj.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Netway Telecom
|262403
|https://lg.netwt.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Wixnet
|53013
|http://wixnet.com.br/lg/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Aloo
|61568
|http://lg.alootelecom.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Altarede
|28260
|http://lg.altarede.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|SinalBR
|262761
|http://lg.sinalbr.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Asap Telecom
|264144
|http://lg.asaptelecom.com.br:8002/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Turbozone Internet
|264479
|https://as264479.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Viva Tecnologia Telecom
|266413
|http://lg.vivatecnologia.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Linkwap
|61633
|http://lg.linkwap.com.br/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|}
*
{| class="wikitable sortable"
|+
Internacionais
!Rede
!ASN
!Looking Glass
!IPv4
!IPv6
|-
|Seabone / Sparkle
|6762
|https://gambadilegno.noc.seabone.net/lg/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Stackpath
|12989
|https://lookingglass.hwng.net/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|KPN
|286
|https://lg2.eurorings.net/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|CenturyLink
|209
|https://lookingglass.centurylink.com/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|NTT
|2914
|https://www.gin.ntt.net/looking-glass-landing/
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Sprint
|1239
|https://www.sprint.net/lg
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Tata
|6453
|http://lg.beta.as6453.net
|[[Arquivo:Sim.png|semmoldura]]
|[[Arquivo:Sim.png|semmoldura]]
|-
|Telia
|1299
|https://lg.telia.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|HE
|6939
|http://lg.he.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Cogent
|174
|http://www.cogentco.com/en/network/looking-glass
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Zayo
|6461
|http://lg.zayo.com
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|NLNOG
|Vários
|http://lg.ring.nlnog.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|SoftLayer
|36351
|http://lg.softlayer.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|AT&T
|7018
|telnet://12.0.1.28
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Deutsche Telekom
|3320
|https://s-lga1.s.de.net.dtag.de/index.php?pageid=lg
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|GTT (via Ginernet)
|3257
|http://gtt.lg.ginernet.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Telxius/TIWS
|12956
|https://telxius.com/looking-glass/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Não.png|semmoldura]]
|-
|Orange (Opentransit)
|5511
|https://looking-glass.opentransit.net/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Worldstream (IPTV)
|49981
|https://lg.worldstream.nl
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|OVH
|16276
|https://lg.ovh.net
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|PJSC ROSTELECOM
|12389
|http://lg.ip.rt.ru/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|G-Core Labs
|199524
|https://lg.gcorelabs.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Leaseweb (hospeda SmartOLT)
|30633
|https://lg.leasewebstatus.com/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Angola Cables
|37468
|https://lg.angolacables.co.ao/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|-
|Packet.net
|54825
|https://www.packet.com/resources/noc/
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|[[Arquivo:Sim.png|semmoldura|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Sim.png]]
|}

==== <big>Destaques</big> ====
* Looking Glass da Tata que mostra um mapa visual da rota (http://lg.beta.as6453.net) 

* Looking Glass ALICE do IX.br, que agrega várias tabelas de IXs em diferentes cidades (https://lg.ix.br) 

* Looking Glass da NLNOG que mostra uma visão de múltiplos route-servers (http://lg.ring.nlnog.net)
*
==== <big>Looking Glass mais aguardado</big> ====
* ISPTools em http://www.isptools.com.br/lg

[[Arquivo:Kisspng-emoji-sadness-emoticon-smiley-clip-art-sad-emoji-png-clipart-5a73fc019d1bb8.4272949715175505936435.png|esquerda|semmoldura|66x66px]]

==== <big>Ausências importantes:</big> ====
Redes importantes que não disponibilizam um Looking Glass BGP:

* Telefônica Vivo
* Claro/Embratel
* TIM
* Oi
* Copel
* Vogel
* Amazon
* Google
* Microsoft
* Akamai
[[Categoria:Interconexão]]
__INDEXAR__
[[Categoria:Roteamento]]

Como funciona o traffic policy no Huawei

2021-03-07T02:57:15Z

Daniel Damito:

= 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

Como funciona o traffic policy no Huawei

2021-03-07T02:56:50Z

Daniel Damito:

= 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

Como funciona o traffic policy no Huawei

2021-03-07T02:37:52Z

Daniel Damito:

= 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.

[[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 é 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).

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

<code>#</code>

<code>traffic classifier C-CGNAT-DstExceptions operator or</code>

<code>if-match acl 3002</code>

<code>traffic classifier C-CGNAT-ToBeNated operator or</code>

<code>if-match acl 3001</code>

<code>#</code>

<code>traffic behavior B-CGNATBypass</code>

<code>permit</code>

<code>traffic behavior B-ToBeNATED</code>

<code>redirect ip-nexthop 172.20.0.2</code>

<code>#</code>

<code>traffic policy P-CGNAT</code>

<code>classifier C-CGNAT-DstExceptions behavior B-CGNATBypass</code>

<code>classifier C-CGNAT-ToBeNated behavior B-ToBeNATED</code>

<code>traffic-policy P-CGNAT inbound global-acl</code>

==== 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.

<code>acl number 3001</code>

<code>rule 5 permit ip source 100.64.0.0 0.63.255.255</code>

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.

<code>acl number 3002</code>

<code>rule 5 permit ip destination 100.64.0.0 0.63.255.255</code>

<code>rule 10 permit ip destination 192.0.2.0 0.0.0.255</code>

<code>rule 15 permit ip destination 10.0.0.0 0.255.255.255</code>

<code>rule 20 permit ip destination 172.16.0.0 0.15.255.255</code>

<code>rule 25 permit ip destination 192.168.0.0 0.0.255.255</code>

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.

<code>traffic classifier C-CGNAT-ToBeNated operator and</code>

<code>if-match acl 3001</code>

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.

<code>traffic classifier C-CGNAT-DstExceptions operator and</code>

<code>if-match acl 3002</code>

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.

Como funciona o traffic policy no Huawei

2021-03-07T02:24:24Z

Daniel Damito:

Como funciona o traffic policy no Huawei

2021-03-07T02:19:27Z

Daniel Damito: