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

[Leonardo Suzan]

Olá Thiago,

Pode ser também. Era minha suspeita inicialmente, mas eu depois que fiz esse ajuste em nossa caixa como falei, o problema resolveu. Agora estamos trocando tráfego com eles sem nenhum problema via IX. 

Se você quiser entrar em contato com eles, vou te mandar o telefone que eu tenho no privado, ok? 

Abraços 
Leonardo 

 

> On 11 Apr 2018, at 10:19, THIAGO AYUB <thiago.ayub at upx.com> wrote:
> 
> Olá Leonardo,
> 
> 
> Minha suspeita é o contrário: que é o router da GVT que perde a entrada ARP do endereço IPv4 do meu roteador no ATM e deixa de ser capaz de me enviar pacotes pelo IX, gerando downtime.
> 
> 
> Abraços,
> 
> 
> 
> Thiago Ayub | Network Director
> 
> +55 (11) 2626-3952 <tel:(11)%202626-3952>
> upx.com <http://upx.com/>
> 
> 
> Em 10 de abril de 2018 17:10, Leonardo Suzan via gter <gter at eng.registro.br <mailto:gter at eng.registro.br>> escreveu:
> 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 <mailto: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 <mailto: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 <http://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 <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 <http://upx.com/>
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter <https://eng.registro.br/mailman/listinfo/gter>
> >>
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter <https://eng.registro.br/mailman/listinfo/gter>
> 
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter <https://eng.registro.br/mailman/listinfo/gter>
>