[GTER] Problema no IX SP Equinix SP4

Fri Jan 3 16:28:06 -03 2025

Novamente com problemas, e eu acredito mais uma vez que não teremos um RFO
Estou com Problemas no PIX SP4 e Eletronet em ASNs diferentes.

Em ter., 31 de dez. de 2024 às 14:25, Bruno Vane via gter
<gter at eng.registro.br> 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