[GTER] AS18881 (GVT/Vivo) não alcançando destinos do ATM do IX.br de São Paulo gerando indisponibilidade

[Leonardo Suzan]

Tivemos um problema de comunicação com o AS deles afetando vários clientes que começou no domingo de páscoa. Mas após uma analise verificamos que o ARP timeout de nossa caixa estava baixo e causando problemas de conectividades com eles em L2. Após os ajustes os problemas cessaram. 

Inclusive abrimos chamado no NOC deles e fomos muito bem atendido pelos analistas, que nos ajudaram a localizar a falha.

Se precisar, hum post fixo no grupo do IX do Telegram com os parâmetros a serem ajustados: 

ARP CACHE
* 30 segundos: arp who-has 2880x por dia
* 20 minutos: 72x por dia
* 4 horas: 6x por dia

Ajustes por fabricante:

—> Juniper – Padrão 6 horas
* Defina por interface:
arp timeout 14400

* Police de ARP de no mínimo 1M:
set firewall policer limite_arp_ptt-sp if-exceeding bandwidth-limit 1m
set firewall policer limite_arp_ptt-sp if-exceeding burst-size-limit 100k
set firewall policer limite_arp_ptt-sp then discard

* Por interface:
set interfaces <interface> unit <unit> family inet policer arp limite_arp_ptt-sp

—>  Cisco – Padrão 4 horas
* Defina por interface:
arp timeout 14400

—> FreeBSD – Padrão 20 minutos
* No sysctl.conf defina:
net.link.ether.inet.max_age=14400 

—> Linux – Padrão 20 segundos
* 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

* Aumentar o tamanho das tabelas (padrão Debian/Ubuntu é 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

—> Mikrotik – Padrão 30 segundos
* Limite de neighbors em 1024 em algumas versões;

* Desativar discover:
/ip settings set arp-timeout=4h  
/ip settings set max-neighbor-entries=8192
/ip neighbor discovery  set [find] discover=no

* Por interfaces (versões >= 6.36):
/interface ethernet set [ find default-name=<interface> ] arp-timeout=4h

—> Huawei – Padrão 20 minutos
* Defina por interface:
arp expire-time 14400


Leonardo Suzan 

> On 10 Apr 2018, at 16:44, Lucas Willian Bocchi <lucas.bocchi at gmail.com> wrote:
> 
> Não é que não tem né Tiagão... Foi agregado no ICMPv6.
> 
> Em 10 de abril de 2018 12:10, THIAGO AYUB <thiago.ayub at upx.com> escreveu:
> 
>> Olá GTER,
>> 
>> 
>> Tenho observado alguns esparços casos de clientes da GVT/Vivo que não
>> conseguem completar rotas até destinos nacionais. O traceroute morre dentro
>> do backbone da Vivo (geralmente num hop de reverso *.vivozap.com.br).
>> 
>> Como todos os destinos dos casos que chegaram para mim eram IPs do ATM do
>> IX.br de São Paulo, estou suspeitando que o roteador da GVT/Vivo que
>> participa do ATM está sofrendo dos problemas de ARP que foram alvo de uma
>> brilhante palestra no último IX Fórum do Douglas Fischer (
>> https://www.youtube.com/watch?v=DPKNs4vw0NA). Nesse caso, o AS18881
>> continua aprendendo a rota via ATM através dos route servers mas perde a
>> capacidade de enviar pacotes para o next-hop por perder a entrada dele em
>> sua tabela ARP. Ou seja, o BGP elege um caminho não alcançavel em Layer 2
>> gerando downtime.
>> 
>> Em tempo, esse problema de ARP é mais um motivo para se entregar IPv6 até o
>> cliente final já que este protocolo não possui ARP.
>> 
>> Mais algum participante do IX.br de São Paulo tem enfrentado problemas de
>> alcançabilidade (reachability) de IPs oriundos do cone do AS18881 (antiga
>> GVT, hoje Vivo)?
>> 
>> 
>> Abraços,
>> 
>> *Thiago Ayub *| Network Director
>> 
>> +55 (11) 2626-3952 <(11)%202626-3952>
>> upx.com
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>> 
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter