[GTER] Problema no IX SP Equinix SP4

Mon Dec 30 09:21:33 -03 2024

Aoba Bruno! Bão Vinicius!?!

Bruno, sou capaz de apostar que sua conexão ao IX.BR-SP deve estar:
a- Numa porta CIX com MUITOS outros participantes
b- Onde a maioria deles usa MikroTik
c- O CIX com o IX.BR não deve usar QinQ [2]
d- O CIX deve estar ligado no Switch do IX.BR que tem capacidades limitadas
de filtragens de entrada(provavelmente um equipamento mais antigo como os
Brocade/Extreme)

Como eu estou "adivinhando" isso?
Como operador de CIX, já passei 3 ou 4 vezes por uma situação parecida....
Onde depois de 20-30 participantes, os clientes do CIX que eu ajudava a
operar começavam a reclamar de conectividade com alguns hosts da Vlan de
ATM do IX.BR-SP.
Aí, depois de muita briga, "mágicamente", os problemas dos clientes do CIX
que eu ajudava a operar, deixavam de acontecer...

O que eu imagino que aconteceu nessa solução mágica do problema?
Eu chuto que existia um rate-limit para pacotes non-unicast vindos da porta
de rede que eu operava, e esse rate-limit era global, abrangendo todas as
Vlans de dentro da porta.
Provavelmente o rate-limit usava um número que veio de análises empíricas
que serve para um CIX de uns poucos participantes...
E esse número entrou na configuração standard.
Mas conforme a coisa foi crescendo nesses CIX, esse rate-limit passou a
estourar, e a regra passou a fazer o que ela tem que fazer que é dropar
pacotes.
Aí depois de eu criar um semi-motim pedindo que todos os meus clientes
abrissem chamados e referenciassem um primeiro chamado que eu vinha lutando
há semanas/meses...
Magicamente o problema se resolveu.
Então veio uma mensagem mais ou menos assim  [1] :
 - "Favor verificar se os problemas ainda persistem."
E mesmo depois de muitos questionamentos sobre o que teria acontecido e
qual foi a solução aplicada, os atendentes dos tickets fugiam de fazer
qualquer afirmação.

Nas duas primeiras vezes, eu lutei, pelejei, me esforcei para tentar
resolver isso... Cheguei a:
- Fazer capturas de tráfego generalizadas do output da nossa interface em
direção ao Fabric do IX.BR-SP;
- Medir os rates dos pacotes com o bit que indicava não ser frames unicast;
- Entrar em contato individualmente com cada cliente pedindo para que eles
ajustassem os respectivos ARP-Timeouts para 4hs [3]
E depois de fazer isso, resolvia por um tempo e depois o problema renascia.

Da 3ª vez em diante eu já desisti de ser colaborativo. Comecei a agir no
modo Go-Horse....
- Fazendo coisas que acho condenáveis que é fazer amplificação de ruído no
ticket para escalar o problema logo para alguém que eu sabia que iria
resolver o problema.
- Ativar logo o CIX em Tipo 3 (QinQ)

Sendo assim @Bruno Vane <broonu at gmail.com> , te recomendo a fazer um
esforço conjunto com a empresa que é o Hoster do CIX através da qual você
se conecta ao IX.BR-SP, e "Pegar o touro pelo chifre, e tombar ele...".

[1] Resposta evasiva do IX.BR depois de encontrar e "resolver" o problema.
Isso é o que mais me incomoda!
E ficou mais do que claro que isso é uma definição Top-Down.
E também ficou claro que equipe técnica por lá age com certo medo de
algumas reprimendas.

[2] O CIX Tipo 3 e QinQ
Isso é uma conclusão fraca exclusivamente baseada nas minhas próprias
experiências.
Mas eu inferi que sendo um CIX tipo 3, usando QinQ, o switch do fabric ao
qual a porta do hoster do CIX é conectada tem features mais apuradas que
permitem filtragens mais granulares, e isso provavelmente permite que o
rate-limit de non-unicast seja por participante, o que evita que um
participante seja afetado pelo barulho excessivo do outro.

[3] Minha experiência ao pedir para ajustar o ARP-Timeout para 4Hrs.
Acho que vale uma menção especial a esse tema.
Eu tive/tenho a felicidade de a maioria dos clientes com que tive serem
inteligentes e colaborativos.
Mas também tive que lidar com alguns <Palavra-Ofensiva-Auto-Censurada>...
Nesse processo de pedir para os clientes dos CIX ajustarem os ARP-Timeout
para de 30 segundos para 4horas, ouvi até ofensa...
- Alguns meteram um "/ignore"
- Alguns se negaram a fazer...
- Alguns responderam "O IX.BR não obriga ser nesse tempo, então eu não vou
fazer."
- E teve 2 casos de clientes que depois viraram amigos (e devem estar lendo
a lista) que fizeram a troca de 30 segundos para 4 horas, e nos dias
subsequentes voltaram para 30 segundos... E me explicaram: Quando deixo em
4 horas, os problemas acontecem mas se resolve rápido e não preciso me
envolver na resolução... Então prefiro deixar assim.

Foi nessa época que o @Rubens Kuhl <rubensk at gmail.com> me apresentou a
https://pt.wikipedia.org/wiki/Trag%C3%A9dia_dos_comuns
E eu entendi que esse não era um problema de solução técnica e sim de
solução que dependia de arrojo dos operadores do IX.BR para impor regras
sobre a questão do ARP-Timeout.
E desde então eu meio que desisti de lutar com respeito a isso.

Em seg., 30 de dez. de 2024 às 02:45, Bruno Vane via gter <
gter at eng.registro.br> escreveu:

> Entrei lá e li seu relato.
>
> Meu problema está sendo exatamente com alguns big players: Akamai,
> Cloudflare, Edgecast, ACE CDN e Tencent.
> Nem com 300s resolve, as sessões da Akamai chegam a cair com menos de 1
> minuto (é possível que esse pessoal esteja usando arp-timeout de 30s?)
> Enfim, este problema não acontece no meu IPv6, só no IPv4.
> Agora de madrugada pra fazer um teste eu coloquei meu arp-timeout pra 30s e
> parou o problema, quase 1 hora sem quedas ou perda de pacote, porém não vou
> subir o tráfego nessas condições.
> Espero amanhã cedo conseguir falar com alguém no IX SP.
>
> Em sex., 27 de dez. de 2024 às 23:09, <viniciusgruske at gmail.com> escreveu:
>
> > Eu também tinha há muito tempo, e começou de uma hora pra outra.
> >
> > Na quarentena o problema de fato não acontece.
> >
> > Como explicado lá, o problema é que a matriz de comutação do IX.br barra
> > os ARP requests dos participantes que deveriam chegar para o teu
> roteador,
> > e, portanto, eles não conseguem completar a ARP.
> > Com um clear router arp resolve o problema pois teu roteador vai mandar
> um
> > ARP request para o participante, e, portanto, o participante vai aprender
> > tua ARP.
> >
> > Um paliativo é baixar teu ARP timeout para um valor menor do que o
> > participante. Teu ARP expirando antes que o dos participantes, vai fazer
> > com que teu roteador ativamente sempre peça a ARP deles, e eles conseguem
> > montar tua ARP sem precisar fazer o request (e ser barrado pela matriz do
> > IX). Baixar para 300s deve ser suficiente para não ter problemas com a
> > maioria dos big players do IX.br, mas ainda tem muito participante com
> > MikroTik e ARP timeout de 30s, o que daí tu teria que configurar para
> 25s.
> > Só que tu não está sozinho com esse problema, daí se todo mundo com esse
> > problema baixar para 25s, vão ter que baixar para 20s, e depois para
> 15s, e
> > assim vai.
> >
> > Então antes de um evangelizador do ARP timeout de 4h aparecer me
> > criticando por propor essa solução, eu recomendo fortemente que tu encha
> o
> > saco do IX.br para resolver o teu problema, e se for deixar o ATMv4 ativo
> > nessas condições e com ARP timeout reduzido, use as communities para
> > filtrar o tráfego só dos 3~5 players com maior tráfego enquanto espera
> uma
> > resolução por parte do IX.br.
> >
> > -----Mensagem original-----
> > De: gter <gter-bounces at eng.registro.br> Em nome de Bruno Vane via gter
> > Enviada em: sexta-feira, 27 de dezembro de 2024 22:09
> > Cc: Grupo de Trabalho de Engenharia e Operacao de Redes <
> > gter at eng.registro.br>
> > Assunto: Re: [GTER] Problema no IX SP Equinix SP4
> >
> > Vinicius,
> >
> > Obrigado pelo relato, parece sim ser o mesmo caso.
> > Só que já temos essa ligação há muito tempo, não entendo isso começar
> > agora (dia 18), inclusive fizemos com eles a quarentena hoje e foi
> aprovado.
> > Meu router é um Nokia SR-1, não consigo fazer um arp-ping nele mas
> fazendo
> > um clear router arp <IP> resolve.
> > Acredito ser o mesmo problema.
> >
> > Em sex., 27 de dez. de 2024 às 21:35, Vinicius Gruske Dorneles <
> > viniciusgruske at gmail.com> escreveu:
> >
> > > Te aconselho a leitura, para verificar se não é a mesma coisa:
> > > https://t.me/IX_BR/132257/169081
> > >
> > > Foi um inferno tratar este incidente com o IX.br, foram 5 meses com
> > > eles empurrando o problema, e depois de resolvido, o "RFO" desse meu
> > > caso foi o mais genérico possível por parte deles.
> > >
> > > Se for o mesmo caso, tem o protocolo do meu chamado lá na conversa no
> > > grupo do Telegram, deve ajudar.
> > >
> > > Em sex., 27 de dez. de 2024 às 21:16, Bruno Vane via gter <
> > > gter at eng.registro.br> escreveu:
> > >
> > >> Boa noite pessoal,
> > >>
> > >> Alguém passando por problemas no IX SP Pix Equinix SP4?
> > >>
> > >> Aqui estamos perdendo conectividade com diversos participantes, com
> > >> isso o tráfego vai e volta, participantes com grande volume de
> > >> tráfego como Akamai, Cloudflare, ACE-CDN, etc.
> > >>
> > >> Eu não consigo pingar pro destino (no caso para o roteador do
> > >> participante), isso acontece o dia inteiro. Não perco o MAC do
> > >> participante, o MAC continua na tabela do meu roteador e inclusive
> > >> renovando o expiry-time o tempo todo.
> > >>
> > >> Parece que lá não estão recebendo meu MAC.
> > >>
> > >> Com os routeservers em si não acontece, somente com diversos outros
> > >> participantes, porém afeta o tráfego no ATM, já que perco
> > >> conectividade com o participante.
> > >>
> > >> Tenho um chamado aberto lá desde o dia 18 e não encontram nada,
> > >> fizemos a quarentena hoje e nada, ligo lá para o NOC e desligam.
> > >> --
> > >> 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