Mudanças entre as edições de "Ajustes de ARP Cache para o IX"
(Adição dos comandos para VyOS) |
|||
(10 revisões intermediárias por 4 usuários não estão sendo mostradas) | |||
Linha 1: | Linha 1: | ||
=== Introdução === | === Introdução === | ||
+ | Para a troca de pacotes ocorrer entre equipamentos, é necessário mapear o MAC do IP destino, associando um endereço IPv4 (layer 3, 32 bits) a um endereço MAC (layer 2, 48 bits). O ARP é o protocolo responsável por essa "tradução". | ||
+ | |||
+ | Cada vez que um equipamento precisa enviar um pacote para outro é necessário verificar qual o MAC associado ao IP de destino do pacote, para isso o router solicita ao ARP qual o MAC associado aquele IP e um broadcast ARP é enviado a todos os equipamentos no mesmo segmento de rede. Agora imagine isso acontecendo em uma troca de dados (um download por exemplo), a quantidade de broadcast seria enorme, o que pode ser um problema. Para resolver esse isso, existe o ARP cache. É uma tabela que mantém a relação IP-MAC de uma rede. | ||
+ | |||
+ | Deste modo, sempre que um host precisa enviar um pacote para outro, ele verifica se possui a entrada MAC relacionada ao IP de destino no ARP cache, se o MAC já existir, ele não precisa enviar um broadcast para toda a rede. | ||
+ | |||
+ | As entradas ARP podem ser: | ||
+ | * Dinâmicas: O ARP cria a entrada e a mantém automaticamente, a mesma pode expirar, tendo que se ser substituída periodicamente. | ||
+ | * Estáticas: O administrador da rede cria e mantém a entrada ARP, ela não expira e não pode ser sobrescrita por entradas dinâmicas. | ||
+ | Um limite de tempo para que entradas ARP dinâmicas sejam removidas do cache pode ser definido, o mesmo leva o nome de ARP_timeout e assim que este timer é zerado, a entrada ARP não utilizada é removida do cache. | ||
+ | |||
+ | Note que a tabela ARP é diferente da tabela CAM, cada uma tem seu timer e propósito próprio. | ||
+ | |||
+ | Não existe um valor pré definido (ex: RFC) para o ARP timeout, cada vendor aplica um timer próprio. Redes de IX's no geral passam por poucas modificações, afinal ISP's trocam seus edge routers com baixa frequência, sabendo disso fica claro que: | ||
+ | * A tabela ARP de um roteador conectado ao IX deve ser dinâmica, afinal você não controla todos os routers dentro deste segmento de rede | ||
+ | * Como as trocas dos equipamentos presentes na LAN do IX são esporádicas você deve definir um ARP timeout relativamente "alto". | ||
+ | Imagine que o seu roteador esteja configurado para "limpar" o ARP cache a cada 30 segundos, neste cenário seu equipamento fará 2880 requisições '''diárias''' para o mesmo IP, agora multiplique essas requisições pela quantidade de hosts presentes na mesma LAN. | ||
+ | |||
+ | Usaremos como exemplo uma rede /24, multiplicando a quantidade de requisições diárias pela quantidade de hosts presentes na rede: | ||
+ | |||
+ | 2880 * 254 = 731.520 | ||
+ | |||
+ | Isso resulta em aproximadamente 700 mil pacotes em um único dia partindo somente do seu roteador, se considerarmos que todos os hosts presentes na rede estiverem com o ARP timeout definido em 30s seriam aproximadamente 200 milhões de pacotes por dia, cerca de 2kpps. Isso pode se tornar prejudicial pois: | ||
+ | * Consome banda; | ||
+ | * Consome processamento do plano de controle da caixa. | ||
+ | Para que os problemas acima sejam minimizados, o ARP timeout ideal na rede de um IX é de 4 horas (ou 14400 segundos), com o seu router configurado deste modo, ele fará 6 requisições diárias, utilizando o mesmo cenário anterior, o calculo seria: | ||
+ | |||
+ | 6 * 254 = 1524 | ||
+ | |||
+ | Considerando que todos os routers da rede estivessem com 4h de timeout, o total de pacotes por dia será de aproximadamente 400 mil pacotes, menos de 10pps ARP. | ||
+ | |||
+ | Também é importante observar o tamanho do ARP cache de seu router. Caso seu tamanho da tabela ARP cache seja menor do que a quantidade de hosts presentes na rede, seu router não será capaz de se comunicar com todos os equipamentos na mesma LAN, ou seja, apesar de possuir a tabela BGP correta, você não será capaz de alcançar o NEXT HOP de todas as rotas, causando falhas na entrega do serviço para os clientes. | ||
+ | |||
+ | Abaixo você encontrará exemplos de configurações em diversos vendors para que seu ARP_timeout e cache_size sejam ajustados de forma correta. | ||
=== Ajustes por Fabricante === | === Ajustes por Fabricante === | ||
Linha 10: | Linha 44: | ||
A configuração é definida por interface: | A configuração é definida por interface: | ||
<pre> | <pre> | ||
− | arp | + | set system arp interfaces <interface> unit <unit> aging-timer 240 |
</pre> | </pre> | ||
− | Defina também a police de ARP de no mínimo | + | Defina também a police de ARP de no mínimo 4m no caso do IX-SP e 1m para os outros IX: |
<pre> | <pre> | ||
− | set firewall policer limite_arp_ptt-sp if-exceeding bandwidth-limit | + | set firewall policer limite_arp_ptt-sp if-exceeding bandwidth-limit 4m |
set firewall policer limite_arp_ptt-sp if-exceeding burst-size-limit 100k | set firewall policer limite_arp_ptt-sp if-exceeding burst-size-limit 100k | ||
set firewall policer limite_arp_ptt-sp then discard | set firewall policer limite_arp_ptt-sp then discard | ||
Linha 53: | Linha 87: | ||
net.ipv6.neigh.default.gc_thresh2 = 4096 | net.ipv6.neigh.default.gc_thresh2 = 4096 | ||
net.ipv6.neigh.default.gc_thresh3 = 8192 | net.ipv6.neigh.default.gc_thresh3 = 8192 | ||
+ | </pre> | ||
+ | ==== Vyos ==== | ||
+ | Comandos válidos para a versão 1.4-rolling-release e devem ser executados no modo de configuração | ||
+ | <pre> | ||
+ | set system sysctl parameter net.ipv4.neigh.<interface>/<numero-da-vlan-ipv4>.gc_stale_time value '14400' | ||
+ | set system sysctl parameter net.ipv4.neigh.default.gc_thresh1 value '2048' | ||
+ | set system sysctl parameter net.ipv4.neigh.default.gc_thresh2 value '4096' | ||
+ | set system sysctl parameter net.ipv4.neigh.default.gc_thresh3 value '8192' | ||
+ | set system sysctl parameter net.ipv6.neigh.<interface>/<numero-da-vlan-ipv6>.gc_stale_time value '14400' | ||
+ | set system sysctl parameter net.ipv6.neigh.default.gc_thresh1 value '2048' | ||
+ | set system sysctl parameter net.ipv6.neigh.default.gc_thresh2 value '4096' | ||
+ | set system sysctl parameter net.ipv6.neigh.default.gc_thresh3 value '8192' | ||
</pre> | </pre> | ||
==== Mikrotik ==== | ==== Mikrotik ==== | ||
Linha 73: | Linha 119: | ||
<pre> | <pre> | ||
arp expire-time 14400 | arp expire-time 14400 | ||
+ | </pre> | ||
+ | Defina também a police de ARP de no mínimo 4m no caso do IX-SP e 1m para os outros IX: | ||
+ | <pre> | ||
+ | cpu-defend policy 1 | ||
+ | car arp cir 4096 | ||
+ | </pre> | ||
+ | E aplique no slot: | ||
+ | <pre> | ||
+ | slot X | ||
+ | cpu-defend-policy 1 | ||
+ | </pre>Caso a interface com o ATM ou mesmo Sessão Bilateral for a terminação de um QinQ é necessário adicionar também a seguinte configuração na interface com endereços IPv4<pre> | ||
+ | arp broadcast enable | ||
</pre> | </pre> | ||
=== Referências === | === Referências === | ||
− | https://pastebin.com/raw/Lah7jAQ5 | + | Fonte: https://pastebin.com/raw/Lah7jAQ5 |
+ | |||
+ | '''Criação e adaptação''': Erton Silva e Fernando Frediani | ||
+ | [[Categoria:Interconexão]] | ||
+ | [[Categoria:Roteamento]] |
Edição atual tal como às 11h36min de 25 de outubro de 2022
Introdução
Para a troca de pacotes ocorrer entre equipamentos, é necessário mapear o MAC do IP destino, associando um endereço IPv4 (layer 3, 32 bits) a um endereço MAC (layer 2, 48 bits). O ARP é o protocolo responsável por essa "tradução".
Cada vez que um equipamento precisa enviar um pacote para outro é necessário verificar qual o MAC associado ao IP de destino do pacote, para isso o router solicita ao ARP qual o MAC associado aquele IP e um broadcast ARP é enviado a todos os equipamentos no mesmo segmento de rede. Agora imagine isso acontecendo em uma troca de dados (um download por exemplo), a quantidade de broadcast seria enorme, o que pode ser um problema. Para resolver esse isso, existe o ARP cache. É uma tabela que mantém a relação IP-MAC de uma rede.
Deste modo, sempre que um host precisa enviar um pacote para outro, ele verifica se possui a entrada MAC relacionada ao IP de destino no ARP cache, se o MAC já existir, ele não precisa enviar um broadcast para toda a rede.
As entradas ARP podem ser:
- Dinâmicas: O ARP cria a entrada e a mantém automaticamente, a mesma pode expirar, tendo que se ser substituída periodicamente.
- Estáticas: O administrador da rede cria e mantém a entrada ARP, ela não expira e não pode ser sobrescrita por entradas dinâmicas.
Um limite de tempo para que entradas ARP dinâmicas sejam removidas do cache pode ser definido, o mesmo leva o nome de ARP_timeout e assim que este timer é zerado, a entrada ARP não utilizada é removida do cache.
Note que a tabela ARP é diferente da tabela CAM, cada uma tem seu timer e propósito próprio.
Não existe um valor pré definido (ex: RFC) para o ARP timeout, cada vendor aplica um timer próprio. Redes de IX's no geral passam por poucas modificações, afinal ISP's trocam seus edge routers com baixa frequência, sabendo disso fica claro que:
- A tabela ARP de um roteador conectado ao IX deve ser dinâmica, afinal você não controla todos os routers dentro deste segmento de rede
- Como as trocas dos equipamentos presentes na LAN do IX são esporádicas você deve definir um ARP timeout relativamente "alto".
Imagine que o seu roteador esteja configurado para "limpar" o ARP cache a cada 30 segundos, neste cenário seu equipamento fará 2880 requisições diárias para o mesmo IP, agora multiplique essas requisições pela quantidade de hosts presentes na mesma LAN.
Usaremos como exemplo uma rede /24, multiplicando a quantidade de requisições diárias pela quantidade de hosts presentes na rede:
2880 * 254 = 731.520
Isso resulta em aproximadamente 700 mil pacotes em um único dia partindo somente do seu roteador, se considerarmos que todos os hosts presentes na rede estiverem com o ARP timeout definido em 30s seriam aproximadamente 200 milhões de pacotes por dia, cerca de 2kpps. Isso pode se tornar prejudicial pois:
- Consome banda;
- Consome processamento do plano de controle da caixa.
Para que os problemas acima sejam minimizados, o ARP timeout ideal na rede de um IX é de 4 horas (ou 14400 segundos), com o seu router configurado deste modo, ele fará 6 requisições diárias, utilizando o mesmo cenário anterior, o calculo seria:
6 * 254 = 1524
Considerando que todos os routers da rede estivessem com 4h de timeout, o total de pacotes por dia será de aproximadamente 400 mil pacotes, menos de 10pps ARP.
Também é importante observar o tamanho do ARP cache de seu router. Caso seu tamanho da tabela ARP cache seja menor do que a quantidade de hosts presentes na rede, seu router não será capaz de se comunicar com todos os equipamentos na mesma LAN, ou seja, apesar de possuir a tabela BGP correta, você não será capaz de alcançar o NEXT HOP de todas as rotas, causando falhas na entrega do serviço para os clientes.
Abaixo você encontrará exemplos de configurações em diversos vendors para que seu ARP_timeout e cache_size sejam ajustados de forma correta.
Ajustes por Fabricante
A depender da configuração de fábrica do equipamento ele enviará um broadcast "arp who-has" o número de vezes abaixo:
- 30 segundos: 2880x por dia
- 20 minutos: 72x por dia
- 4 horas: 6x por dia
Juniper
A configuração é definida por interface:
set system arp interfaces <interface> unit <unit> aging-timer 240
Defina também a police de ARP de no mínimo 4m no caso do IX-SP e 1m para os outros IX:
set firewall policer limite_arp_ptt-sp if-exceeding bandwidth-limit 4m set firewall policer limite_arp_ptt-sp if-exceeding burst-size-limit 100k set firewall policer limite_arp_ptt-sp then discard
E aplique na interface:
set interfaces <interface> unit <unit> family inet policer arp limite_arp_ptt-sp
Cisco
A configuração é definida por interface:
arp timeout 14400
FreeBSD
No sysctl.conf defina:
net.link.ether.inet.max_age=14400
Linux
No sysctl.conf defina:
net.ipv4.neigh.default.gc_stale_time=14400 net.ipv6.neigh.default.gc_stale_time=14400
Ou por interface:
net.ipv4.neigh.<interface>.gc_stale_time=14400 net.ipv6.neigh.<interface>.gc_stale_time=14400
Aumente o tamanho das tabelas (padrão do Debian/Ubuntu é de 512~1024 entradas):
net.ipv4.neigh.default.gc_thresh1 = 2048 net.ipv4.neigh.default.gc_thresh2 = 4096 net.ipv4.neigh.default.gc_thresh3 = 8192 net.ipv6.neigh.default.gc_thresh1 = 2048 net.ipv6.neigh.default.gc_thresh2 = 4096 net.ipv6.neigh.default.gc_thresh3 = 8192
Vyos
Comandos válidos para a versão 1.4-rolling-release e devem ser executados no modo de configuração
set system sysctl parameter net.ipv4.neigh.<interface>/<numero-da-vlan-ipv4>.gc_stale_time value '14400' set system sysctl parameter net.ipv4.neigh.default.gc_thresh1 value '2048' set system sysctl parameter net.ipv4.neigh.default.gc_thresh2 value '4096' set system sysctl parameter net.ipv4.neigh.default.gc_thresh3 value '8192' set system sysctl parameter net.ipv6.neigh.<interface>/<numero-da-vlan-ipv6>.gc_stale_time value '14400' set system sysctl parameter net.ipv6.neigh.default.gc_thresh1 value '2048' set system sysctl parameter net.ipv6.neigh.default.gc_thresh2 value '4096' set system sysctl parameter net.ipv6.neigh.default.gc_thresh3 value '8192'
Mikrotik
Nota: O padrão do Mikrotik é de 30 segundos e o limite de neighbors em algumas versões é 1024.
Desative o discovery (versão RouterOS < 6.36):
/ip settings set arp-timeout=4h /ip settings set max-neighbor-entries=8192 /ip neighbor discovery set [find] discover=no
Para versão >= 6.36 a configuração pode ser feita por interface:
/interface ethernet set [ find default-name=<interface> ] arp-timeout=4h
Huawei
Nota: O padrão é de fábrica é de 20 minutos.
A configuração é definida por interface:
arp expire-time 14400
Defina também a police de ARP de no mínimo 4m no caso do IX-SP e 1m para os outros IX:
cpu-defend policy 1 car arp cir 4096
E aplique no slot:
slot X cpu-defend-policy 1
Caso a interface com o ATM ou mesmo Sessão Bilateral for a terminação de um QinQ é necessário adicionar também a seguinte configuração na interface com endereços IPv4
arp broadcast enable
Referências
Fonte: https://pastebin.com/raw/Lah7jAQ5
Criação e adaptação: Erton Silva e Fernando Frediani