Au boulot, ce sont des routeurs Juniper J2350 qui se chargent d’acheminer les lutins de l’internet vers nos équipements. Depuis quelques temps, les routeurs en question s’occuppent entre autres d’annoncer nos plages d’IPs grâce au protocole BGP.
Si l’établissement des sessions eBGP avec nos fournisseurs d’accès n’a posé aucun problème, l’établissement de la session iBGP entre nos differents routeurs montrait une charge CPU, mais surtout une consommation mémoire anormales, jusqu’à provoquer recemment le crash de l’un d’entre eux.
J’ai toujours été fasciné par l’inutilité des services support des constructeurs ou autres grosses structures, et Juniper ne déroge pas à la règle. De fait, je décide donc d’exposer mon problème non pas au support officiel, qui mettra déjà une bonne 15aine de jours à comprendre ce que je veux bien dire par “iBGP”, mais plutot aux forums communautaires du fabriquant. Bien evidemment, comme dans tous les forums de la terre, on obtient en premier lieu quelques réponses des “know-it-all” qui vous ressortent le contenu d’une plaquette marketing: “I would agree, a J2320 is not designed to take a full set of routes.”, mais avec un minimum de patience, on finit par tomber sur quelqun qui sait de quoi il parle.
Un utilisateur catégorisé “Recognized Expert” me dit la chose suivante : “I have used also J2320 routers with 2x full feed on them. Works good. But I downgraded to the last JUNOS 9.3 that runs only in packet mode. That saves a couple of RAM.”
Et c’est là le tournant de l’histoire. En effet, lorsque je reçus mes jouets, je m’aperçus qu’ils tournaient sur une version bien ancienne de JunOS (le système d’exploitation dérivé de FreeBSD qui fait fonctionner ces routeurs), et comme tout bon administrateur impatient, je me jette sur les mises à jours. Grossière erreur. Ce que m’explique le monsieur du forum, c’est que depuis les releases 9.3R4 de JunOS, le démon en charge du forwarding de paquets n’est plus fwdd mais flowd_hm, une nouvelle mouture qui ne fonctionne plus en simple “mode paquet”, mais établit des sessions (stateful) afin d’inspecter le traffic (l’explication ici).
Le downgrade m’effrayant un peu, je tente 1001 méthodes pour alléger ce démon, mais rien n’y fait, ses 481M de taille font toujours souffrir mes routeurs. La seule solution: downgrader.
Bien évidemment, cette opération s’est réalisée dans la douleur; en effet, ce fameux mode flow based a impliqué des entrées dans la configuration du routeur qui ne sont pas backward compatibles. En particulier, une section zones qui définit des zones de sécurité, et plus précisemment, qui a le droit de “sortir” ou pas, et dans les versions supérieures à 9.3R3, sans cette section, le routeur est aveugle et ne peut pas récupérer sa mise à jour. L’espace du disque flash équipant le J2350 étant limité, il n’était pas possible de télécharger la mise à jour pour l’appliquer localement, j’étais donc obligé d’effectuer l’upgrade à travers le réseau, mais cette opération était vouée à l’échec puisque la mise à jour échouait en raison de l’incompatibilité de la configuration en place avec les versions antérieures. Quadrature du cercle.
Mais voila: JunOS est un UNIX, et Juniper a eu la bonne idée de laisser l’accès à cet UNIX (FreeBSD, donc) par le biais de la commande start shell.
Ainsi, tout en gardant la configuration running activée, je m’en vais modifier le fichier /config/juniper.conf.gz pour en retirer la section security, incompatible avec le downgrade. Un gunzip -c, vi, gzip plus tard, je peux tranquillement invoquer la commande CLI:
foo> request system software add validate no-copy unlink ftp://serveur/junos-jseries-9.3R3.8-domestic.tgz
Et constater que la “mise à jour” s’effectue parfaitement.
Notez qu’afin de ne pas générer de la charge inutile, j’ai au préalable désactivé les annonces vers mes voisins BGP grâce à la commande :
foo# deactivate protocol bgp group ma-session neighbor ip.de.mon.voisin
foo# commit
Un foo> request system reboot plus tard, j’admire :
--- JUNOS 9.3R3.8 built 2009-05-12 22:33:43 UTC
Et constate que cette pourriture de démon flowd_hm a disparu, avantageusement remplacé par fwdd, et que le routeur répond désormais au quart de tour, même avec toutes ses sessions BGP chargées.
Morale de l’histoire: avant de te jeter sur la dernière version d’un soft, vérifie que t’en as bien besoin… (version longue de “if it works, don’t fix it”).
Twitter
GooglePlus
GitHub
Recent Comments