Tag: NETSCALER

Sur des NetScaler VPX (11.0.71.18 qu’il faudra mettre à jour ASAP) nous avons créé des VIPs qui étaient pingables mais injoignables sur les ports sur lesquels elles étaient configurées (dans le cas présent TCP 443 et TCP 8085).

En regardant du côté firewall (ASA) nos collègues du réseau ont remarqué des time-out et drop.

01/09 07:37:35 <182>Sep 02 2019 20:37:17: %ASA-6-106015: Deny TCP (no connection) from xx.xxx.xx.xxx/80 to xx.xxx.xx.xxx/59968 flags SYN ACK  on interface cag_VIP978

En googlelant nous sommes tombés sur la CTX205292 extrêmement intérressante, en effet activant le MBF sur les Netscaler, les VIPs étaient joignables sans problème.

Pour activer le MBF il faut se connecter en SSH sur le Netscaler et lancer la commande ci-dessous. 

enable ns mode mbf

Le problème dans notre cas était bien un problème de routage asymétrique et pas question de toucher à la conf des firewall, donc on a activé le mode MDF sur les Netscaler.

Suite à la migration de Netscaler Vpx en 12.1.48.13 nous avons remarqué que ces derniers consommaient anormalement de la cpu dans Vcenter (avec des hosts en ESXi 6.0).

Tranquille le Vpx 🙂

En googlelant nous sommes tombé sur la CTX22955 qui explique que depuis la version 12.0 (vpx) le CPU yielding est désactivé.

Tout est dit…

Afin d’activer le CPU yeilding il faut vous connecter en ssh (ou console) sur votre Vpx et passer la commande ci-dessous.

set ns vpxparam -cpuyield YES

Reste à verifier que ça nous rend bien la cpu côté Hyperviseur

On pensait que c’était l’effet canicule mais non 🙂

Suite à un upgrade de netscaler 11.1 vers 12.1.4813 les champs utilisateur et mot de passe avaient disparu de la page d’accueil de la CAG (index.html).

Le premier qui arrive à se loguer gagne une boisson jaune 🙂

Dans pareille condition le mieux est d’ouvrir le developper de votre browser favori (dans notre cas c’est Chrome).

On constate que nous avons une erreur dans l’onglet Sources et deux erreurs 404 dans la console (en bas du deuxième screenshot).

Les erreurs 404 donnent deja un bon indice 🙂 .

Un clic sur une des erreurs nous renvoie dans l’onglet Network, encore un clic sur l’erreur (en bas à gauche) permet d’afficher une preview et donc le path du fichier manquant.

L’avantage du developper est que même sans notion de dev on arrive rapidement à trouver l’orgine d’une erreur.

Maintenant que nous connaissons l’origine du problème il ne reste plus qu’à aller en ssh sur un de nos netscaler dans le dossier ” /var/netscaler/logon/themes/Ctxblog/resources”.

Ok donc tous les fichiers de langages ont une extension .xml1 au lieu de .xml.

Afin de renommer tous les fichiers ayant l’exention .xml1 en .xml on passe la commande ci-dessous.

for f in *.xml1; do mv — “$f” “${f%.xml1}.xml”; done

Il ne reste plus qu’a vérifier que ça a bien corrigé notre problème

On va pouvoir retourner sur le transat 🙂

Suite à un upgrade de firmware sur des appliances Netscaler (firmware 11.0.55 vers 11.0.62.10 ) les nouveaux certificats SSL installés après l’upgrade n’étaient plus bindés après reboot des Netscaler.

Une fois les Netscalers rebootés les Virtual servers (avec les nouveaux certificats) passaient en Down

Sans certificat c’est sur ça ne va pas marcher

Après plusieurs tests infructueux, le passage en 11.0.64.4 a résolu le problème, en revanche on n’a rien vu dans les Releases Notes des firmware 63.16 et 64.34 sur ce sujet.

Une fois les Netscalers upgradés en 64.34 on retrouve bien nos certificats après reboot (au préalable nous avons ajouté les certificats puis bindé ces derniers)

Côté Virtual Server c’est bien Up

Le certificat reste bien bindé

Côté google on avait juste trouvé the thread https://discussions.citrix.com/topic/367451-server-certificate-lost-after-reboot-ns-110/#entry1885415