Déployer un firmware via IMC Surpervisor est très simple encore faut-il que cela fonctionne, et c’est toujours quand on n’a pas le temps que cela se complique 🙂 . Sur Une IMC Supervisor (ver : 2.2.0.0) nous devions déployer un firmware sur un Serveur Cisco M5, mais le menu “Firmware Upgrade” en avait décidé autrement. En effet lorsque l’onglet “Firmware Upgrade” s’affichait, la liste des serveurs (tout du moins le bouton +) ne s’affichait pas, seule une barre de progression qui tournait sans fin nous tenait compagnie.
Sur la page Rack Groups, onglet “Rack Servers” on remarque une ligne avec des éléments manquants (seule le Last Inventory Update) apparaît.
Avec l’information “Last Inventory Update” nous allons regarder dans la page Physical Account (onglet “Racks Accounts”) si nous trouvons quelque chose.
Bingo on retrouve notre serveur, cette fois avec toutes ses informations
Nous avons supprimé ce serveur afin de vérifier que c’était bien la cause de notre problème (dans le menu “Firmware Upgrade”), puis nous sommes allés tester le menu “Firmware Upgrade”.
Nickel ça passe (il ne reste plus qu’à rajouter notre serveur supprimé)
Avec un titre comme ça il faut qu’on vous plante le décor au préalable ; nous avons un cluster de deux hosts dont un est en maintenance, les deux serveurs d’admin (RDSH) qui sont hébergés sur l’autre host commence à être chargés, sur un de nos serveur d’administration nous avions déjà une session en mode déconnecté depuis une vingtaine heures environ. La reconnection à notre session s’est faite sans problème (une chance car l’autre serveur refuse toute connexion) cependant lorsque nous avons essayé de lancer une connection distante (SSH) via PuTTY nous avons rencontré l’erreur ci-dessous :
Network error : No buffer space available
Notre premier bug PuTTY 🙂
Dans le journal system nous avons trouvé l’Event ID 4227 qui visiblement a un lien direct avec notre problème.
TCP/IP failed to establish an outgoing connection because the selected local endpoint was recently used to connect to the same remote endpoint. This error typically occurs when outgoing connections are opened and closed at a high rate, causing all available local ports to be used and forcing TCP/IP to reuse a local port for an outgoing connection. To minimize the risk of data corruption, the TCP/IP standard requires a minimum time period to elapse between successive connections from a given local endpoint to a given remote endpoint.
Outre le problème rencontré avec PuTTY, nous ne pouvons plus “sortir” du serveur, que ce soit via l’accès à un partage distant, un telnet, un rdp, AD etc.. etc….. . Un google plus loin nous comprenons qu’il se pourrait que notre serveur ait un problème de port dynamique (AKA “Ephemeral Port“). Afin d’afficher la liste et l’état des connexions (ce qui nous intéresses ce sont les connexions en TIME_WAIT) sur notre serveur nous avons utilisé la cmdlet “Get-NetTCPConnection” comme ci-dessous :
Get-NetTCPConnection -state timewait
Nous avons constaté un nombre conséquent (environ 200) de connexions en TIME_WAIT (malheureusement nous n’avons pas eu le temps de faire un screenshot, juste le temps de noter les PID coupables, et comme c’est de la prod on ne kill pas les PID sans savoir), on comprend mieux pourquoi PuTTY ne trouve pas un port dynamique de libre. Afin de connaître la plage des ports dynamiques il faut lancer la commande ci-dessous :
netsh int ipv4 show dynamicport tcp
Notre server a une une plage par défaut pour un Windows 2019
La solution de facilité serait de rebooter le serveur (mais nous avons toujours des utilisateurs connectés sur le serveur), nous optons pour agrandir la plage des ports dynamiques (sans redémarrer le serveur) . Afin d’agrandir la plage des ports dynamiques et réduire le temps de libération d’un port qui passe en TIME_WAIT de quatre minutes (valeur par défaut) à 30 secondes nous avons passé les clés de registre ci-dessous (qu’on expliquera plus bas) via une console PowerShell.
Nous relançons un “netsh int ipv4 show dynamicport tcp” afin de vérifier que la plage des ports dynamique a bien été agrandie.
Notre plage est désormais agrandie
On teste si PuTTY se lance bien avec la plage des ports dynamiques agrandie.
Nickel (ça passe sans reboot)
Quelques explications sur les trois clés passées plus haut.
MaxUserPort : Permet de fixer la plage des ports dynamiques, par défaut la plage sur Windows 2019 commence à 49152 et se termine à 65535
TcpTimedWaitDelay : détermine la durée pendant laquelle une connexion TCP reste dans l’état TIME_WAIT (ou 2MSL) lorsqu’elle est fermée. La valeur par défaut d’un TIME_WAIT est de 240 secondes (4 mn) soit 120 secondes pour MSL qu’on double pour avoir deux MSL (2MSL).
TcpNumConnections : nombre de connexions TCP ouvertes simultanées
Un peu de littérature autour des ports dynamiques :
Récemment nous avons reçu des Cisco CC20 M5 avec des SFP Arista 25-G et bien sûr le côté Plug-and-Play n’a pas fonctionné comme esperé :).
Honnêtement tout le monde s’y attendait chez nous et certains pensaient même à des check de type “Vendor Name” côté Cisco etc.
En échangeant avec une vielle connaissance de chez Cisco (Arnaud Bassalerpour ne pas le citer 😉 ) ce dernier nous indique que Cisco ne fait plus de check hardware sur les SFP depuis ses serveurs, le problème devrait venir de la configuration du FEC qu’il faudrait forcer en “cl74” selon lui.
Direction l’IMC du serveur afin de modifier l’Admin FEC Mode en “cl74” (allez dans Network-Adapter Card MLOM-External Eternet Interface puis cliquez sur l’onglet External Ethernet Interface)
Il ne reste plus qu’à modifier la valeur de l’Admin FEC mod en “cl74”, si toutefois le link State ne passe pas en Link Up, verifiez côté switch s’il ne faut pas forcer le port (dans notre cas un switch Arista) en “fire-code” ce qui a permis dans notre cas de passer le link du port en Up dans l’IMC.
Et oui tout arrive, nous faisons du PVS 🙂 , ce qui nous amène à mettre à jour nos exclusions anti-virus (Le billet sur les exclusions anti-virus est ici).
C’est un poil exagéré mais bon ça nous fait marrer 🙂
