Ils sont en recherche de résolution pour le problème de l’Icotera et ont fait quelques testes sur ma box. J’ai renvoyé divers logs de dump.
*Sigh*
De mes souvenirs, c'était une race condition qui faisait qu'une règle ebtables n'était pas appliquée dans certaines conditions très spécifiques.
Toujours de mes souvenirs, Icotera avait préparé un patch
et fournit un workaround pour les anciennes versions (activer le serveur http de l'icotera, quitte à mettre une acl y bloquant tout accès, ce qui avait été fait par Antho ; la race condition ne se produit pas dans ce cas là).
Par contre, dès qu'une Icotera leak, toutes les autres sur le même domaine de diffusion se mettent à avoir des soucis - je ne vais pas rentrer dans les détails techniques de pourquoi.
Ça impliquait deux choses :
- en cas de réaffectation d'Icotera entre abonnés différents, l'Icotera ne doit pas juste être reset mais
doit passer par Amiens pour être flashée.
- le support doit demander au NOC avant de demander à un client de faire la combinaison magique qui bascule l'Icotera sur l'autre memory bank (de toute façon ils doivent le faire pour une autre raison)
Si malheureusement le problème se produit, K-Net :
- peut limiter le problème en programmant des ACL directement en ASIC. (hint pour K-Net : en SSH, après avoir obtenu un *vrai* shell, `diag` et fouillez les commandes commençant par `rg`; il faudra bloquer un ethertype en particulier + des subnets spécifiques, j'en ai déjà mentionné un dans un autre message). Pour le NOC, si vous ne l'avez pas, demandez si quelqu'un a encore le zshrc que j'avais fait, y'avait des fonctions pour gérer ces cas.
- peut trouver l'origine du problème avec un parallel-ssh pour trouver les Icotera sans règle ebtables, puis les redémarrer
C'était assez pénible à diagnostiquer la première fois, j'espère pour les gens du NOC qu'ils n'auront pas à refaire le diagnostique une deuxième fois...
K-Net