Récemment, j’ai reçu l’appel d’un collègue me demandant de l’aide pour résoudre un problème de performance générale sur des applications hébergées dans le Data Center. Dans le cadre de son diagnostic initial, il avait déjà constaté des erreurs CRC sur l’interface réseau d’un serveur. Nous avons donc mis de côté le problème global pour nous focaliser sur ce souci spécifique.
Petit rappel sur le CRC
Le CRC (pour “Cyclic Redundancy Check”) est un mécanisme de détection d’erreurs omniprésent dans les réseaux informatiques et les systèmes de stockage. Son rôle est de vérifier si les données ont été altérées ou corrompues pendant leur transmission.
En pratique, lorsqu’un appareil (votre ordinateur, par exemple) souhaite envoyer des données, il applique un algorithme basé sur des “codes cycliques”, lequel génère un nombre de longueur fixe : la valeur CRC. Ce CRC est alors ajouté aux données avant l’envoi vers un autre équipement du réseau.
À l’autre bout de la chaîne, le dispositif récepteur exécute le même algorithme sur les données reçues et compare la valeur obtenue avec le CRC fourni. Si les deux valeurs correspondent, on suppose que les données sont intactes et non corrompues. Dans le cas contraire, les données sont jugées peu fiables… et finissent généralement à la poubelle. Voilà comment le CRC fait son travail !
Diagnostic initial : erreurs CRC sur le serveur
Constater des erreurs CRC sur l’interface réseau d’un serveur signifie que celui-ci reçoit des paquets corrompus depuis le switch auquel il est connecté. Dans la plupart des cas, ce type de problème se résout en remplaçant simplement les composants physiques (SFP, jarretière, etc.). Nous avons donc procédé au changement du SFP, mais sans succès : le compteur d’erreurs continuait d’augmenter. Nous avons ensuite changé la jarretière, mais là encore, aucune amélioration. Pire encore, mon collègue m’informe alors que des erreurs CRC apparaissent sur la quasi-totalité des serveurs du Data Center. Le jeu devenait plus intéressant (du moins, pour moi) !
Grâce à un script Ansible — “Merci ChatGPT” — j’ai récupéré l’état de toutes les interfaces des switches du Data Center. Et là, c’est la douche froide : tous les switches, sans exception, présentent des erreurs CRC sur les interfaces d’accès (en sortie) et sur les interfaces uplink (en entrée). Je commençais à me poser des tas de questions : s’agissait-il d’un bug sur les switches ? Peut-être une attaque ?
Pour y voir plus clair, j’ai lancé une capture Wireshark à destination du serveur afin d’analyser le trafic. Dès le lendemain matin, reposé et avec un café à la main, j’ai commencé à scruter les “lignes rouges” indiquées dans la capture. Au milieu de cette “marée rouge”, je repère des paquets parfaitement sains. Après comparaison, je constate que ces paquets sains proviennent exclusivement d’autres serveurs du DC (trafic Est-Ouest), tandis que les paquets corrompus proviennent de l’extérieur (trafic Nord-Sud). Serait-ce un problème au niveau du firewall ?
Store-and-Forward vs. Cut-Through
En théorie, si un firewall envoie des paquets corrompus au switch, celui-ci devrait les jeter et signaler les paquets comme corrompus en entrée, et l’histoire s’arrêterait là. En vérifiant les logs, j’ai effectivement constaté que l’interface connectant le firewall présentait des erreurs CRC en entrée. Je commençais à douter de mes connaissances… jusqu’à ce que je tombe sur un article Cisco décrivant précisément la gestion des CRC sur les plateformes Nexus 9K (les mêmes que dans mon infrastructure).
Cisco explique qu’il existe deux méthodes de forwarding des trames :
- Store and Forward : le switch stocke entièrement la trame dans un buffer et effectue un contrôle CRC avant de décider du routage.
- Cut-Through : dès que le switch dispose de suffisamment d’informations pour connaître la destination (adresse MAC ou adresse IP), il transmet la trame. Il n’attend donc pas la réception complète du paquet ni la vérification du champs FCS (Frame Check Sequence).
C’était la lumière au bout du tunnel : en mode “Cut-Through”, un switch peut réémettre un paquet déjà corrompu puisqu’il ne vérifie pas son intégrité avant de le transmettre.
La solution : focus sur le firewall
Je me suis alors concentré sur le firewall. J’ai demandé à changer le SFP du lien qui le connecte au switch de distribution… et bingo : plus d’erreurs et plus de dégradation de service. Tout était enfin rentré dans l’ordre!
En résumé
1. Les erreurs CRC sur un serveur peuvent être dues à des problèmes de câblage ou de matériel (SFP, jarretière).
2. Une fois ces composants vérifiés ou remplacés, si le problème persiste, il est judicieux d’élargir le diagnostic (contrôle des logs sur l’ensemble du réseau).
3. Sur certains équipements (comme les Cisco Nexus 9K en mode Cut-Through), les paquets corrompus peuvent être transmis à travers le réseau s’ils ne sont pas contrôlés avant le routage.
4. Identifier l’origine (ici, le firewall) permet de résoudre définitivement le problème en remplaçant le composant défectueux (SFP, par exemple).
