[GTER] Problema no IX SP Equinix SP4

Tue Dec 31 14:24:32 -03 2024

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
>