[GTER] Problema no IX SP Equinix SP4

Mon Dec 30 11:01:09 -03 2024

Douglas,

Estou no PIX Equinix SP4.

Em seg., 30 de dez. de 2024 às 09:21, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> 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
>