[GTER] Problema no IX SP Equinix SP4

Tue Dec 31 07:31:45 -03 2024

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