Tous les systèmes sont opérationnels

Stickied Incidents

mardi 15 août 2023

nitter.fdn.fr Instance Nitter : erreur « Tweet not found »

Suite à de nouveaux changements côté Twitter (encore…), toutes les instances sont bloquées car la consultation des tweets nécessite à un compte. Le problème est identifié sur le Git de Nitter, ticket 983. La recherche ne fonctionne également pas.

L'équipe adminsys

  • Service arrêté définitivement...

  • Ça n'aura pas durée très longtemps (quelques jours voire heures), les comptes invités (guest accounts) ne peuvent plus être généré via l'API X/Twitter. En attente d'une nouvelle solution, s'il y en a une…

  • Depuis hier soir, suite une mise à jour vers Debian 12 afin d'utiliser Nim 1.6.10 et l'utilisation de la branche guest_accounts, Nitter est de nouveau fonctionnel ! À voir combien de temps ce sera fonctionnel car les jetons sont limités à 500 appels / 15 minutes et les jetons ne peuvent être générés depuis la même IP qu'une fois toutes les 24 heures avant que l'instance soit limitée par X/Twitter.

  • Maintenance Planifiée
    xDSL / FTTH : maintenance pour mise à jour du logiciel d'un équipement

    Chers adhérents, chères adhérentes,

    Ielo nous fait part de cette maintenance :

    • Caractéristiques de l'opération : Mise à jour du logiciel de l'équipement
    • Référence de la maintenance : #212854
    • Début (heure locale) : 2024-02-27 23:00:00 (CET / UTC+0100)
    • Fin (heure locale) : 2024-02-28 06:00:00 (CET / UTC+0100)
    • Temps de coupure : 1 heure
    • Impact : Coupure franche xDSL / FTTH collecté par Ielo

    À noter : la collecte xDSL/FTTH Ielo est redondée sur les deux datacenters Parisiens dans lesquels est présent FDN, il n'y aura donc, normalement, pas de coupure. Nos LNS feront en sorte que le second datacenter prenne le relais mais vous êtes prévenu, au cas où ;-).

    L'équipe adminsys

    Incidents antérieurs

    lundi 26 juin 2023

    Coupures Internet xDSL / FTTH collecte Ielo

    Cher adhérents, chères adhérentes,

    Des pertes de connectivités à Internet en IPv6 ou IPv4 se sont manifestés par des déconnexions et reconnexions régulières ainsi que des possibles soucis d'accessibilité en IPv4 (routage). Nos LNS semblent être en cause et plus particulièrement la partie L2TP. Le processus nous indiquait des erreurs d'allocation mémoire mais sans en trouver la cause précise pour le moment malgré quelques heures de recherches (RAM, slabs, max_size IPv6, optmem_max, nombre de sockets, nombre de routes apprises…).

    Les messages en question :

    For generic netlink request 6 on 24, got a netlink error: No such device
    00/00 DHCPv6: could not join DHCPv6 group: Cannot allocate memory
    00/00 ICMPv6: could not join all routers group: Cannot allocate memory
    
    • 26/06/2023 23:47 : LNS11 a été rétabli pendant une dizaine de minute
    • 27/06/2023 00:00 : LNS22 est rétabli après redémarrage du processus L2TP
    • 27/06/2023 00:12 : de nouveau les dysfonctionnements mais plus d'erreur « Cannot allocate memory », seulement « For generic netlink request 6 on 24, got a netlink error: No such device »
    • 27/06/2023 00:22 : un redémarrage du serveur s'impose car les deux processus L2TP se sont suicidés après avoir voulu les relancer sans l'accélération noyau
    • 27/06/2023 00:28 : LNS22 est de nouveau opérationnel

    À noter que les erreurs « For generic netlink request 6 on 24, got a netlink error: No such device » sont toujours présentent. LNS11 étant isolé, cela va permettre d'approfondir le diagnostics et effectuer des tests.

    Désolé pour ces perturbations :/.

    L'équipe adminsys

  • RAS depuis les changements du 27/06. Ces deux actions ont sans doute permis de stabiliser : ajustement de l'option net.core.optmem_max ainsi que le blocage du compte qui avait pour conséquence de créer/supprimer des interfaces réseau et des routes en boucle.

    L'option net.core.optmem_max a été sauvegardé de façon permanente via notre outil de gestion des configurations ainsi que l'iptables pour l'ajustement du MSS, ce qui évitera les déboires causées en cas de redémarrage du serveur.

    L'équipe adminsys

  • Après quelques debug, nous avons constaté une augmentation de la table des inodes, mais ça semble être seulement du cache, sans incidence. L'erreur « For generic netlink request 6 on 24, got a netlink error: No such device » semble être une fausse piste, c'est la suppression des routes IPv6 mais IPv6CP peut ne pas être activé.

    • 27/06/2023 13:20 : augmentation de la valeur net.core.optmem_max de 1MB à 10MB et blocage des requêtes d'une ligne qui revenait sans cesse dans les logs pouvant solliciter de manière agressive les LNS et causer un effet de bord
    • 27/06/2023 ~21:00 : remontées d'accès à de nombreux sites web, ça ressemble à un problème MTU. Des comptes radius de personnes nous l'ayant remontés sont exclus de l’accélération noyau (tous ceux en %idf), ça fonctionne de nouveau.
    • 27/06/2023 ~23:20 : il ne s'agit pas d'un problème sur la MTU mais sur la MSS. Il est ajusté à 1420 sur les deux LNS et sauvegardé de façon persistante.

    Encore désolé pour ces interruptions et merci à toutes les personnes qui nous ont aidé dans le debug ;). Le sujet reste sous surveillance.

    L'équipe adminsys

  • mardi 2 mai 2023

    Coupures xDSL / FTTH et VPN

    Vous aurez probablement remarqué des coupures de l'accès Internet ces derniers temps :

    • le mardi 25 avril matin.
    • depuis dimanche 30 soir.
    • et notamment une grosse coupure ce matin entre 4h et 7h.

    Désolé pour ces coupures, cela ne devait pas se produire ainsi :/.

    Version courte : on essaie d'améliorer le débit disponible des accès Internet, s'il y a des gens qui veulent bien essuyer les plâtres de la mise en œuvre, contactez-moi, sinon jetez simplement ce mail à la poubelle : on est revenus à l'état habituel en fin d'après-midi.

    En version longue, face à l'accroissement de débit utilisé pour les abonnements internet (fibre comme VDSL), il est devenu nécessaire d'activer l'accélération du traitement des lignes par le noyau Linux, car sinon la charge de traitement plafonne et le débit disponible pour les abonné·es se retrouve alors limité.

    Youpi a fait divers tests intensifs sur une maquette, mais comme toujours c'est l'essai en grandeur nature qui montre certains problèmes (en même temps que montrer le gain effectivement énorme : de l'ordre de 10x-20x moins de charge de traitement). Youpi avait repéré un problème mardi, et laissé une seule ligne en observation avec l'accélération de mardi à dimanche, et ne constatant pas de souci, l'accélération pour tout le monde a été activée dimanche soir.

    Mais apparemment il reste un problème qui pour "certaines" lignes et sous "certaines" conditions, rend "certains" sites indisponibles (enfin, "un peu" : le trafic ne passe pas "bien").

    Autrement dit on aurait besoin de volontaires pour qu'on active l'accélération pour leur ligne, et que lorsqu'un tel problème d'accès survient contactez-nous, qu'on puisse observer à tête reposée ce qui se passe pour pouvoir corriger le souci, avant d'activer pour tout le monde.

  • Après quelques corrections de bogues avec la contribution de volontaires, aucun problème n'est constaté, l'accélération a donc été activée pour tout le monde le 27/05/2023 00:00 comme communiqué sur la liste adsl FDN. RAS depuis plus d'une semaine.

    Il est toujours possible de vous exclure de cette accélération si vous rencontrez un problème inhabituel suite à cette activation afin de revenir à l'ancien fonctionnement et constater si c'est lié.

  • Nous ne l'avons pas écrit mais l'impact était : difficulté d'accès à certains sites web (timeout, chargements lents…), micros-coupures Internet, connectivité IPv6 (DHCPv6). En revanche, si vous avez des pertes de synchronisation, ce n'est pas lié ;).

    Quelques nouvelles : l2tpns s'occupe de faire le MSS clamp, ce qui explique effectivement beaucoup les choses avec la MTU réduite par l2tp : si le SYN ou SYN+ACK passe par l2tpns sans accélération, le MSS est bien positionné et toute la connexion passe. Sinon, pas de MSS clamp, et dès que le serveur en face produit des données, ça coince.

    PS : merci à la dizaine de personnes volontaires pour l'activation de l'accélération en noyau et également à ceux nous ayant mis sur la piste de la MTU, ça va nous aider à avancer sur le sujet !

    Les adminsys

  • lundi 1 mai 2023

    LNS : coupure collecte xDSL et FTTH

    Nous avons eu une coupure de la collecte xDSL/FTTH quelques minutes, de 20:00 à 20:10 le 01/05/2023, causé par le redémarrage du serveur LNS22 lors de l'amélioration afin d'ajouter le support de l'accélération noyau dans L2TP (meilleure consommation CPU et parallélisation du traitement des données sur tous les cœurs). LNS11 ayant fait un kernel panic sur le processus L2TP (l2tp_nl_cleanup), nous nous sommes donc retrouvé sans redondance, d'où la coupure le temps du redémarrage du serveur. Veuillez nous excuser pour la gêne occasionnée.

    Amicalement, Les adminsys

    vendredi 24 février 2023

    80.67.169.12 ns0.fdn.fr : résolutions DNS KO

    Bonsoir,

    ns0.fdn.fr ne semble plus répondre aux requêtes DNS ou très difficilement depuis cet après-midi, gros pic de requêtes.

  • Tout est stable depuis les dernières modifications. L'incident qui était sous surveillance est donc clos. Les adminsys surveillent toujours et quelques ajustements pouvant encore être nécessaire prochainement (l'ouverture ayant été de plus officialisée à l'AG).

    • L'ajout d'un listener thread dnsdist semble résoudre les problèmes restants en IPv4
    • La table conntrack était pleine => iptables a été modifié pour ne plus tracker les requêtes DNS entrantes et interne au serveur
  • État des lieux :

    • La VM était injoignable par tous moyens (ping, SSH, console), un stop/start a été nécessaire
    • Des tests avec PowerDNS Recusor ont été faits (afin de remplacer Unbound) mais même symptômes (timeouts), même avec des requêtes censés être dans le cache
    • Ensuite un trop grand nombre de session a été identifié, entraînant des timeouts très réguliers, rendant la résolution DNS quasiment impossible. Contourné temporairement (désactivation des modules conntrack), en attendant une solution définitive (refonte iptables)
    • Unbound seul en frontal semble fonctionnel (donc sans dnsdist)
  • samedi 4 février 2023

    Bibliogram : arrêt du service

    Bonjour,

    Le service bibliogram n'est plus maintenu depuis septembre 2022, de nombreux dysfonctionnements étaient présents rendant le service quasiment inutile. La VM a donc été stoppée le 01/02/2023. Voir https://cadence.moe/blog/2022-09-01-discontinuing-bibliogram

    L'équipe adminsys