[GTER] RES: Problema no IX SP Equinix SP4

Mon Dec 30 16:35:54 -03 2024

Bão.

Douglas, minha porta é CIX, mas durante minhas escovações de bit eu não
recebia sequer um ARP Request de certos participantes, mas recebia
normalmente de outros. Em minha ignorância não consigo montar na minha
cabeça como um rate limit de non-unicast estaria barrando especificamente os
requests de um participante e não de outro.

Volta e meia eu ouço uns murmuro nos corredores que o culpado é um tal de
ARP suppresion, mas não faço a mínima ideia como funciona, e também não fui
atrás para descobrir, então me abstenho de qualquer opinião sobre.

Mas falando sobre o atendimento do IX, eu também recebi um "Favor verificar
se os problemas ainda persistem.", e da mesma forma que você, isso é o que
mais me incomoda. No meu caso, foram 5 meses de um transporte de 15Gbps para
o PTT São Paulo sub-utilizado, diversas reclamações no atendimento, eu
escovando bit, para no final receber uma resposta totalmente vaga. 

Nesses 8 anos de telecom/redes/ISP que tenho, problemas complexos e que
demandam tempo (na casa das semanas), sempre foi natural aos operadores
envolvidos, ao final do incidente, debater mesmo que brevemente, sobre a
causa raiz. Foi a primeira vez que um problema complexo e que demorou 5 fkin
meses não teve sequer uma explicação da causa raiz. É um tapa na minha cara.

Antes fosse um caso isolado, e que o IX.br por motivo A ou B não quisesse
expor algum fato desse caso isolado. Mas percebo que não se trata de um caso
isolado. Pelo que percebo, o problema já existia antes do meu caso, e
continua acontecendo mesmo após meu caso, e acontece com diversos
participantes. 

Ou seja, existe um incidente recorrente na rede do IX.br, que afeta vários
participantes da comunidade a quem ela serve, e mesmo assim, ficam em
silêncio e não falam nada, não esclarecem nada para a comunidade. O que me
lembra um pouco de uma thread no caiu recente:
https://eng.registro.br/pipermail/caiu/2024-December/068489.html

Daí fica nós aqui, tentando criar causa raiz com falta de informação.

Me questiono qual o real motivo pro pessoal do IX.br não mandar um “Pessoal,
temos o problema X causado pela causa Y, que afeta os participantes W nos
casos Z. As ações A, B e C estão em curso para resolver o problema”. Será
que é difícil?

E mais, sabendo do problema, não tem como dar uma orientada melhor aos N1
para não ficar torrando a paciência e o tempo dos participantes com um
problema em uma infraestrutura crítica?

De: Douglas Fischer <fischerdouglas at gmail.com> 
Enviada em: segunda-feira, 30 de dezembro de 2024 09:22
Para: Grupo de Trabalho de Engenharia e Operacao de Redes
<gter at eng.registro.br>
Cc: Bruno Vane <broonu at gmail.com>; Vinicius Gruske Dorneles
<viniciusgruske at gmail.com>; Rubens Kuhl <rubensk at gmail.com>
Assunto: Re: [GTER] Problema no IX SP Equinix SP4

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 <http://IX.BR>  não deve usar QinQ [2]
d- O CIX deve estar ligado no Switch do IX.BR <http://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 <mailto: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 <http://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 <http://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 <mailto: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 <http://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 <mailto: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
<mailto: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
<mailto: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 <mailto: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 <mailto: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 <mailto: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>
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

-- 

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