Le troubleshooting basic sur F5 : comment et par où commencer ?

Pour que le problème soit constaté, il faut tout d’abord repérer le symptôme : un impact concret sur le service, un comportement anormal. C’est en fonction de la nature de ce comportement, que l’on va orienter les recherches. Une fois la troubleshooting « générique » effectué, une méthode d’analyse rigoureuse s’impose afin d’arriver efficacement vers la résolution de l’incident. J’écris cet article afin de vous donner une vision sur nos méthodes de travail au support. En complément, je l’ai agrémenté de quelques tips techniques afin de récupérer les informations dont nous avons besoin. Prenons l’exemple d’une problématique réseau, avec le constat d’un comportement réseau anormal sur la chaine du F5. Dans un premier temps, et avant d’utiliser des termes techniques, il nous est indispensable de comprendre le contexte dans lequel le problème se présente, comment il se manifeste, à quel moment de la journée, etc. Comprendre le rôle du F5 dans la chaine et tout aussi important: routage, load balancing, persistance de session, déchiffrement SSL, etc, … Nous pourrons alors analyser les données à notre disposition afin de déterminer quel devrait être le comportement attendu. Ces données correspondent très généralement à ces trois sources principales: la configuration, les logs, et les captures réseaux. La configuration L’analyse de la configuration permet de cibler le Virtual Server concerné dans le ticket d’incident. Cela permet également de prendre connaissance des spécificités du traitement des flux : type de VS, profiles, monitoring, pools, nodes, iRule, méthode de Load balancing, persistance, routage, NAT. Etc. Cette mise dans le contexte est indispensable pour exploiter les informations que nous allons récupérer. Les logs Les logs, comme dans n’importe quel ticket, représentent la source d’information principale. Les erreurs, alertes ou informations remontées peuvent permettre d’identifier rapidement un problème déjà rencontré, ou documenté sur les ressources online de F5. Les bases F5, tel que Knowledge Base ou Devcentral , aident à interpréter ces logs, et à les expliquer : - http://support.f5.com/ - https://devcentral.f5.com/ Nous sommes également susceptibles de demander l’augmentation du niveau de debug des logs pour un service particulier, sur une courte période de test. Plusieurs solutions sont possibles pour changer le niveau de verbosité des logs. Voici trois d’entre elles : Attention : Pensez auparavant à vérifier le niveau de log par défaut. Une fois les tests effectués, il est nécessaire de repasser le niveau de debug à ce niveau afin d’éviter une surcharge en ressource de l’équipement.

• Via l’interface graphique :

System ›› Logs : Configuration : OptionsModifier le niveau de log souhaité dans la liste disponible.

• En tmsh :

#tmsh modify sys db log.<service>.level value DebugNiveaux disponibles : Error, Warning, Notice, Information, Debug

• Edition de fichier de config pour des logs de module particulier :

Modification du fichier /etc/ts/bd/logger.cfg, et ajout des lignes suivantes à la fin du fichier :MODULE = <nom-module>; LOG_LEVEL = TS_DEBUG; FILE=2;Sauvegarde du fichierCommande à lancer : /usr/share/ts/bin/set_active.pl --update_logger_cfgLes captures réseaux Une fois ces logs activés avec le niveau de verbosité adéquat, nous pouvons passer à l’analyse réseau du trafic à l’aide d’une capture. De bons filtres doivent être utilisés afin d’isoler les transactions qui nous intéressent. Cela facilite grandement l’analyse réseau et comportemental, mais surtout, cela nous permet de gagner énormément de temps. Pour effectuer une capture réseau de type tcpdump sur F5, il faut s’appuyer sur le modèle de base suivant : #tcpdump –s0 –ni 0.0 :nnn host <IP-host> and <other-filter> -w /var/tmp/capture.pcapL’option -s0 : pas de limite de taille -ni 0.0: toute les interfaces avec résolution DNS (possible de définir un vlan à la place du nom de l’interface) host : une IP (serveur et/ou client par exemple) -w : enregistrement de la capture en local. Je n’entre pas dans les détails mais les filtres de la commande tcpdump sont génériques et peuvent être trouvés ici :http://www.tcpdump.org/manpages/tcpdump.1.html Le filtre précédant est toujours valable, mais nous serons susceptibles de vous demander d’ajouter quelques commandes supplémentaires. Je préfère insister sur la spécificité de la partie F5, qui propose des options apportant plus de verbosité à :nnn . Il est indispensable d’appliquer ces options dans toutes les traces effectuées sur le BIGIP : n: Low details : ingress, Slot, TMM, VIPnn: Low and medium details : Flow ID, Peer ID, reset Cause, Connflow Flags, Flow Type, HA unit, Ingress Slot, Ingress Portnnn: Low, medium, and high details : Peer IP Protocol, Peer VLAN, Peer Remote Address, Peer Local Address, Peer Remote Port, Peer Local Port Dans une capture réseau, ces options permettent d’analyser facilement le trafic qui nous intéresse, et d’identifier les différences par rapport au comportement que nous serions en droit d’attendre. Ces informations verbeuses peuvent être exploitées sur wireshark à l’aide d’un plug-in. Il est alors possible d’appliquer des filtres sur les paramètres spécifiques insérés par le F5. (Exemple : f5ethtrailer.tmm == 0) Ce plug-in peut être téléchargé via le lien suivant : https://devcentral.f5.com/wiki/AdvDesignConfig.F5WiresharkPlugin.ashx Il suffira d’ajouter le fichier .dll, dans le répertoire d’installation de l’application : /<path>/Wireshark/plugin/ Dans le cas où nous serions en présence de trafic chiffré, il est possible d’utiliser la commande ssldump pour decrypter le traffic SSL directement sur le F5, en utilisant la clé privée du certificat. Ceci afin de pouvoir exploiter le contenu d’une capture tcpdump chiffrée. Sans cette fonctionnalité, une capture de trafic SSL devient inutilisable. Cette dernière est disponible uniquement à partir de la version 11.2, c’est pourquoi je vais également vous proposer une autre solution pour déchiffrer la capture, qui consiste à exporter une clé de session SSL depuis la capture déchiffrée sur Wireshark, afin que nous puissions déchiffrer la capture sans utiliser la clé privée. Procédure de déchiffrement Dans un premier temps, il faut effectuer le tcpdump souhaité, en suivant le modèle précédent. Pour que la capture puisse être déchiffrée par la suite, il est conseillé de désactiver temporairement le cache de session SSL dans le profile SSL. Pour ça, nous pouvons configurer le Cache Size à 0 sur le Profile SSL client ou/et server en fonction du besoin. Ensuite, deux solutions se présentent :

• Pour les BIGIP version 11.2 et plus, utilisation du ssldump

L'option -M du ssldump permet de générer une pre-master-key, utilisée par la suite dans wireshark pour décrypter le trafic sans la private key. Génération de la clé pms : ssldump -r /path/to/capture_file -k /path/clé_privé -M /path/client.pms Télécharger la capture tcpdump ainsi que le fichier pms. Ouvrir la capture réseau sur wireshark. Ajouter le fichier pms dans : Edit > Preferences > Protocols > SSL >Master-Secret log filename

• Pour les BIGIP version inférieure à 11.2, ou autres équipements réseau

Dans ce cas de figure, il s’agit de proposer au client de déchiffrer la capture de son coté, afin de nous fournir une clé de session SSL par la suite : Déchiffrement de la capture sur Wireshark par le client Edit > Preferences > Protocols > SSL > RSA Keys list : ajout de la clé privée du serveur Paramètre : IP du serveur, port 443, protocole http, private key à Valider que le traffic HTTP est bien visible. Exporter la clé de session SSL : File > Export SSL Session Keys Nous fournir la capture tcpdump et la clé de session SSL Ouverture de la capture réseau sur wireshark. Ajouter la clé de session SSL dans : Edit > Preferences > Protocols > SSL >Master-Secret log filenameBilan Suite à ces détails techniques, laissez-moi vous résumer ce que nous pouvons attendre lors de l’ouverture de votre incident F5. Venant de la part du client:

• Un contexte précis, avec le détail des dernières modifications de configuration et architecture réseau faites (y compris hors cadre du F5).
• Un symptôme clair et précis, avec l’impact direct utilisateur
• Une description du problème, et la méthode de reproduction
• Les éléments F5 en jeu : VS, node, irules
• Un qkview : #qkview –s0 (qui contiendra les logs)
• Récupération des logs externalisés si c’est le cas.
• Une trace réseau faite lors de la reproduction du problème, avec des filtres au plus précis et une clé de session PMS, si le trafic est encrypté

(Il est nécessaire de donner les détails des IPs concernés et les échanges voulus dans la capture réseau, pour que nous puissions l’analyser) Après analyse, nous pourrons alors vous demander :

• D’activer des debug log
• D’effectuer de nouvelles captures avec différentes options
• De reproduire le problème avec des modifications de configuration
• Ou bien sûr, vous donner la solution ;-)

Ce scenario global qui s’applique aux problématiques réseaux, permet d’optimiser la résolution d’un incident et je vous recommande de toujours suivre ces points. Des éléments différents pourront bien sûr être demandés, pour des incidents hardwares, ou des modules F5 spécifiques, GTM, ASM ou APM. Vous trouverez prochainement les best practices d’ouverture d’incident pour tous les modules, dans les Solutions que nous proposons via notre portail de support : https:// nomios.force.com/support Et rappelez-vous, cette article s’inscrit dans une forte volonté de productivité et d’efficacité afin de résoudre vos incidents toujours plus rapidement !