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

Thu Apr 12 07:39:25 -03 2018

No IX Campina Grande a GVT anuncia todos os blocos dela, mas não recebem
anuncio de ninguém... um 50%-ATM kkkkk

Em 11 de abril de 2018 23:11, Diego Canton de Brito <diegocdeb at hotmail.com>
escreveu:

> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>