[GTER] {Spam?} Re: Problema no IX SP Equinix SP4

Fri Jan 3 16:34:01 -03 2025

Resumo: defeito?

bug no firmware do equipamento onde estavam?

Limite de arp req/s atingindo?

Difícil acompanhar...

Em 31/12/2024 14:24, Bruno Vane via gter escreveu:
> Nosso problema foi resolvido pelo IX.
> Me disseram que foram até o SP4 e mudaram minha ligação para outro
> equipamento.
>
> Em ter., 31 de dez. de 2024 às 07:31, Douglas Fischer <
> fischerdouglas at gmail.com> escreveu:
>
>> Responderei abaixo, apenas separando em tópicos:
>>
>> Em seg., 30 de dez. de 2024 às 16:35, <viniciusgruske at gmail.com> escreveu:
>>
>>> 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.
>>>
>> Bom, não sou especialista nisso... Mas acho que dá pra cravar que
>> temos PELO MENOS 2 tipos de problemas aqui relacionados a ARP.
>>
>> O PRIMEIRO deles é aquele que eu mencionei antes, onde uma interconexão
>> física carregando muitas ligações lógicas às vlans de ATM e começa-se a ter
>> problemas com pacotes broadcast em geral.
>> P.S.1: No meu e-mail anterior esqueci de mencionar (e um amigo me lembrou
>>       privadamente) que um dos gatilhos do meu flip-table na minha postura
>>       frente ao ticket/problema foi termos constatado que pacotes de ARP
>>       dentro de vlans bilaterais também eram afetadas/influenciavam o
>> rate-limit
>>       geral da porta CIX. Eu e ele fizemos a prova dos 9 floodando arp numa
>>       vlan e constatando parte dos pacotes de ARP não chegando em outra.
>> P.S.2: Outra coisa que me lembrei, é que uma das formas que usei para
>> descobrir
>>       com qual vendor de equipamento do lado do IX.BR nossas portas estavam
>>       conectadas foi analisando os PDUs do LACP. #FicaADica
>>
>>
>> O SEGUNDO problema é o que você falou sobre não receber NENHUM pacote de
>> ARP-Request de certas origens.
>>       Denovo estamos no campo das especulações. Mas acho sim que isso tem
>>       sim a ver com o ARP Suppression do EVPN.
>>       Como acabo tendo um bom relacionamento com vários operadores de rede,
>>       alguns deles me compartilharam informações, inclusive gráficos, que
>>       demonstravam uma diferença no número de pacotes por segundo entre
>>       portas em PIX diferentes no IX.BR-SP. E numa proporção descomunal de
>>       diferença.
>>       Coincidência ou não (olha o vácuo de pronunciamiento dando espaço para
>>       especulação novamente), os amigos que reclamavam de não conseguirem
>>       comunicar-se com vários dos hosts eram aqueles que estavam com uma
>>       quantidade baixa de pacotes ARP-Request chegando em suas interfaces.
>>
>>       Considerando que por RFC o EVPN pode ser usado em múltiplos combos de
>>       underlay/overlay (EVPN+MPLS/VPLS, EVPN+VXLAN, EVPN+SRv6), mas que
>>       alguns vendors implementaram o EVPN ARP-Suppression apenas para alguns
>>       desses combos de underlay/overlay.
>>       Considerando que atualmente no IX.BR-SP existe um misto de protocolos
>>       undelay/overlay (Digno de nota que isso é um feito extremamente
>> inteligente e corajoso.)
>>       Isso me leva a crer (especulação minha) que esses comportamentos
>> indesejados podem
>>       ocorrendo pela falta de suporte do ARP-Suppression em alguns vendors,
>> o que não popula
>>       adequadamente as entradas ARP na tabela MP-BGP EVPN.
>>
>>
>> Existem TERCEIRO, QUARTO, QUINTO problemas relacionados a ARP no escopo do
>> IX.BR
>>       Mas acho que já enchi tanto o saco com isso que ninguém mais quer
>> ouvir sobre isso,
>>       E eu também perdi um pouco o ânimo de falar/re-falar/re-re-falar
>> disso.
>>
>>
>> Em seg., 30 de dez. de 2024 às 16:35, <viniciusgruske at gmail.com> escreveu:
>>
>>> 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?
>>>
>>>
>> Minha opinião sobre isso é que:
>> "Não! Não é difícil trabalhar com um nível razoavelmente maior de
>> transparência nas operações de um IXP."
>> Eu venho pedindo / insistindo sobre isso há muitos e muitos anos! (só
>> olhar no histórico da GTER e vão confirmar isso)
>>
>> Mas, repetindo o que eu disse no "Fale com o IX.BR" na semana da infra:
>> A melhor coisa que vai acontecer sobre isso é a chegada do DE-CIX que é um
>> concorrente de peso e uma postura de muito mais transparência nesses tipos
>> de casos.
>> Não! NÃO ESTOU DIZENDO que quero ver digladiação entre os IXPs, e nem acho
>> que isso vai acontecer (nichos bem distintos).
>> O que estou dizendo é que os quase 9 mil ASNs brasileiros que estavam
>> acostumados a ter praticamente UM ÚNICO referencial de modo de operação e
>> nível de transparência agora terão aqui por perto um IXP com outros métodos
>> operacionais.
>> E isso vai ser vir tanto para forçar o IX.BR a se aprimorar em certos
>> aspectos quanto para o DE-CIX também se aprimorar em outros aspectos.
>>
>>
>> Apenas para dar contexto de um tiquinho do tipo de transparência que o
>> IX.BR NÃO TEM, e acredito que seja devido a decisões fora da alçada
>> técnica, vou compartilhar alguns links:
>>
>> IXPDB é uma base de dados de IXPs mantida pela Internet Exchange
>> Federation.
>> O link confirma que o DE-CIX informa publicamente quais participantes
>> estão conectados a qual switch do fabric.
>>        https://ixpdb.euro-ix.net/en/explore/ixp/9/pops/
>> O link confirma que o LONAP também informa publicamente as mesmas
>> informações, e INCLUSIVE O MODELO DO SWITCH UTILIZADO.
>>        https://ixpdb.euro-ix.net/en/explore/ixp/18/pops/
>>
>> O AMS-IX mostra com um nível pequeno de detalhes a topologia e tecnologia
>> que eles usam.
>> Obs.: Achei ousada a abordagem de DWDM na camada de acesso.
>>        https://www.ams-ix.net/ams/documentation/ams-ix-topology
>>        https://www.ams-ix.net/ams/documentation/mpls-vpls
>>
>> Aqui segue o link para um Grafana que o LONAP abre publicamente com
>> algumas informações de medição de latência dentro do fabric deles.
>>         https://fabric-metrics.lonap.net/
>>         A ferramenta criada/utilizada é open source:
>>         https://github.com/lonap/ixp-xping
>>
>> Os links a seguir são de um portal PÚBLICO onde o LINX disponibiliza PARTE
>> das informações de Flow e SNMP
>>         https://portal.linx.net/services/lans-flow
>>         https://portal.linx.net/services/lans-snmp
>>
>> E no DE-CIX, além de eles publicarem que participante está em qual switch,
>> eles têm uma política de communities tanto informativas quanto de ação que
>> pode atuar por switch ou por rede metro (que seria quase o equivalente aos
>> PIX aqui do IX.BR).
>>
>> https://www.de-cix.net/en/resources/service-information/route-server-guides/informational-bgp-communities
>>
>> https://www.de-cix.net/en/resources/service-information/route-server-guides/action-bgp-communities
>>
>> "aaaaain Douglas... Então você quer que o IX.BR faça tudo isso? Quer que
>> eles escacarem tudo e exponham as técnicas e segredos deles?"
>> -> "Não! Isso é só um MONTE DE EXEMPLOS de que é possível aumentar a
>> transparência e sair do modo Kim Jong-un"
>>
>> Se o https://status.ix.br/ deixasse de passar por censura prévia, e
>> tivesse um mínimo de automatização nos reports, eu já ficaria muito feliz.
>> <Hipérbole>Não precisa abrir o SNMP dos switch e nem fazer relay do
>> syslog.</Hipérbole>
>> Apenas um mecanismo que REALMENTE mudasse alguns dos status sem a
>> intervenção humana já estaria de bom tamanho...
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter