2026-04-05 09:30 - 2026-04-07 16:30 Pèrdues en Fibra Òptica amb NEBA

eXO estat del servei
1

INCIDENT: 2026-04-05 09:30 (CEST)

Resum
Tipus Incident
Inici 2026-04-05 09:30 (CEST)
Final 2026-04-07 16:30 (CEST)
Tíquet #XYZ
Alertes Sí
Reaccionen @evilham, @dyangol, @jmoles, glutec
Impacte Les persones amb connexió Fibra Òptica NEBA han tingut pèrdua de paquets durant el temps de la incidència
Reporten @evilham

Problema molt similar al de 2025-04-09, on observem pèrdues de paquets a certes connexions FTTH, però no a totes, i on la connectivitat amb Datacenter és perfecta.

Aquesta pèrdua de paquets es podia apreciar principalment amb protocols que fan servir UDP, ja que comportava pèrdua de datagrames. Protocols TCP funcionaven força correctament.

Línia de temps

image
image1042×606 93.6 KB

Tots els temps en CEST.

  • 2026-04-05 09:30 INICI INCIDÈNCIA
  • Durant el dia hi ha alertes, però no apunten a un problema concret (veure més avall, l’anàlisi sobre les alertes)
  • 14:51 Una persona sòcia reporta problemes de pèrdua de paquets
  • 21:57 Aquesta persona comenta que actualitza el seu router per descartar problemes a la seva banda
  • 2026-04-06 08:48 a més a més, ens confirma que si crea el túnel amb una màquina que no hagi de veure cap tipus de límit de recursos, observa les mateixes pèrdues de paquets
  • 2026-04-07 08:48 Fem crida a fer una reunió d’emergència per analitzar la situació, anem fent els deures d’analitzar mètriques i demés durant el dia
  • 16:00 Comença la reunió d’@exo-servers per gestionar la incidència
    • confirmem que no hem fet cap actuació recentment
    • corroborem que les connexions afectades són amb un mateix proveïdor
    • també que d’altres consumidors d’aquest proveïdor no tenen cap incidència
  • 16:15 Acabem de concloure que efectivament es tracta d’un problema “conegut” en el commutador, i comencem a preparar actuació que comportaria un zero de connectivitat
    • mentre preparem l’actuació, veiem que en alguna altra ocasió ja hem fet alguna cosa similar “en calent”
    • és possible afegir una interfície virtual en proxmox a la VM ([ ] firewall, multiqueue: 2)
    • en exo-bng2 aquesta interfície es veu automàticament, només cal configurar-hi la MTU i que les VLANs corresponents la facin servir
    • Generem la interfície i comprovem que Mikrotik les veu
    • consensuem les comandes de Mikrotik:
/interface ethernet set [ find default-name=ether3 ] disable-running-check=no mtu=1598
/interface/vlan set bstrm0 interface=ether3
  • 16:30 Executem els comandes i observem que la pèrdua de paquets s’atura directament
  • 2026-04-07 16:30 FINAL INCIDÈNCIA

Detecció

El problema ha estat detectat per les alertes, però no de manera acurada: en ser pèrdua de paquets, el que passava era que s’activava i es desactivava l’alerta d’indisponibilitat de FTTH constantment.

Gràcies a que la persona sòcia afectada ens avisa, i a les gràfiques, anem més directament a comprovar pèrdues de paquets en serveis concrets.

Possible millora d’alertes

Aquesta situació ha produït un alt volum d’alertes, sense donar gaire informació realment (“tot torna a funcionar”).

Podríem millorar les alertes de la següent manera:

  • Agrupar les FTTH per proveïdor (serà més fàcil trobar incidències)
  • Detectar els casos de pèrdues de paquets, generant alertes específiques i silenciant les altres

Conclusions

  • Hem d’aplicar els canvis d’infraestructura aprovats en AGO 2026 aviat, aquesta incidència s’ha produït a causa d’un problema conegut amb els commutadors que fem servir actualment

Què ha anat bé?

  • Era època de festius locals i no sembla que s’hagi notat molt l’efecte de la pèrdua de paquets

Què no ha anat bé?

  • D’altra banda, en ser època de festius locals, l’equip no ha reaccionat amb la celeritat que ho fa habitualment

Enllaços a documentació rellevant

Accionables

  • millora d’alertes
  • canvis de switchos