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

Wed Apr 11 23:11:02 -03 2018

Tive uma situação a Alguns anos com eles, foi precisos intervenção deles.
Na época reportaram ser um problema em um router deles.
Mas como faz um certo tempo, 1 ou 2 anos, talvez já tenham trocado, foi na época do início da fusão.

Pelo que me lembro, era exatamente isso, eu via o MAC, encaminhava tráfego, mas não recebia nada.

Obter o Outlook para Android<https://aka.ms/ghei36>

________________________________
From: gter <gter-bounces at eng.registro.br> on behalf of THIAGO AYUB <thiago.ayub at upx.com>
Sent: Wednesday, April 11, 2018 10:19:27 AM
To: Grupo de Trabalho de Engenharia e Operacao de Redes
Subject: Re: [GTER] AS18881 (GVT/Vivo) não alcançando destinos do ATM do IX.br de São Paulo gerando indisponibilidade

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 <(11)%202626-3952>
upx.com

Em 10 de abril de 2018 17:10, Leonardo Suzan via gter <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>
> 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
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>
--
gter list    https://eng.registro.br/mailman/listinfo/gter