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

Thu Apr 12 16:21:59 -03 2018

De dezembro para cá andei bem atarefado com questões pessoais e de trabalho
.
Mas essa semana mesmo andei retomando a atenção a essa questão.

Pelo que fui informado, tem colegas trabalhando no HALL-OF-SHAME...
Eu já me posicionei sobre isso, falando que essa é uma medida extrema.
Sugeri pé no freio com isso para evitar embates desnecessários.

Volto a sugerir a ideia do Combo mágico
 - HoneyPot de ARP
 - Arp Sniffer
 - Reações (Quarentena continuada)

Acredito(e sei que levo comigo opinião de muito outros colegas) que o mais
coerente seria o IX.BR desencadear algumas ações contenção dessas
requisições de ARP nas VLANs de ATMv4 do IX-SP e também nas demais
localidade do IX.BR.

A primeira ação que eu acredito não ser complexa de ser implementada é a do
Honeypot.
  Basicamente é um host que responda como  IPs secundários todos os IPs não
alocados a participantes dentro do /21 do IX-SP.
  Se bem me lembro, 30% dos ARP-Requests nesse barramento são para IPs não
atribuídos.
  A atribuição desses IPs secundários poderia ser scrpitada e automatizada
com consultas às bases de dados do próprio IX.
Ao meu ver é uma ação simples e de alto impacto na redução do barulho.

As demais ações são um tanto mais complexas.
Na apresentação que o Ayub postou o link eu fiz um breve detalhamento das
sugestões.
Mas basicamente é gerar dados e estatísticas para identificar
não-conformidades nas definições de cada participante, e um encadeamento de
ações para que essas não conformidades sejam corrigidas.

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
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação