Forum général.général Suivre le chemin d'un paquet au travers des switchs

Posté par Philippe M (site web personnel) le 13 février 2024 à 07:52. Licence CC By‑SA.

Étiquettes : aucune

fév.

2024

Bonjour à tous,

J'ai une infra à basé sur 5 switchs (3 de cœurs et 2 de distributions) avec des liens redondants et le spanning-tree activé pour éviter les boucles.

En théorie la config est ok mais j'ai tout de même des doutes quant aux routes empruntés par les échanges réseaux. Par exemple entre deux serveurs connectés je plafonne à 10Mb de vitesse de transfert, ces deux serveurs sont sur deux switchs différents (les switchs ont un trunk (lacp) de 2Gb et dont cette route a le plus haut niveau de priorité pour spf). Les serveurs ont des cartes 1Gb. Alors certes il y a du trafic sur ce lien mais je suis très loin du point de saturation.

Donc je soupçonne que pour cette exemple un autre chemin soit emprunté vers des switchs de distribution.

Ne pratiquant pas assez le réseau je m'en remets à vous pour me guider ;) Est-ce qu'il y a un moyen de connaitre le chemin emprunté par un paquet ?

# traceroute

Posté par eric gerbier (site web personnel) le 13 février 2024 à 08:17. Évalué à -1 (+1/-3).

Les 2 outils de base quand on débute en réseau sont ping et traceroute. Si tu fais de l'ipv6, il y a les équivalents ping6 et traceroute6.

Répondre
- [^] # Re: traceroute
  
  Posté par Philippe M (site web personnel) le 13 février 2024 à 08:41. Évalué à 7 (+5/-0).
  
  Merci de ta réponse.
  
  Mais sauf à ce que je me trompe, traceroute et ping agissent au niveau 3. Ils vont me donner des informations IP. Traceroute va me dire que j'ai traversé tel ou tel routeur et ping va pouvoir me dire que telle ip répond ou pas dans telle délai. Mais aucun des deux ne pourront me dire que pour atteindre la machine 1 je suis passé par le switch 1 ou bien si j'ai traversé 3 switchs car mes switchs agissent au niveau 2.
  
  Je pratique pas souvent mais je ne suis pas totalement débutant non plus ;)
  
  Born to Kill EndUser !
  
  Répondre
# Tu ne peux pas

Posté par cg le 13 février 2024 à 09:19. Évalué à 7 (+5/-0).
À moins de tracer/observer les paquets directement sur les switchs, tu ne peux pas faire ça au niveau 2.

Question bête : est-ce que tous les switchs qui ont un agrégat supportent bien LACP ? Ça pourrait être une piste. Es-tu certain que c'est bien configuré ET actif sur les serveurs ?

Pour déboguer, tu peux essayer ça :
- activer LLDP pour que les switchs et les autres machines remontent l'info de qui est branché sur quel port ;
- si tu peux, essaye de débrancher (ou désactiver de façon logicielle) un des deux câbles d'un trunk.
- regarder les compteurs d'erreurs sur les machines et les switchs, (avec la commande ethtool -S bond0 par exemple sur Linux).
Répondre
- [^] # Re: Tu ne peux pas
  
  Posté par NeoX le 13 février 2024 à 13:23. Évalué à 8 (+5/-0).
  comme le suggere CG, rien ne vaut le fait de couper un port d'un trunk/lacp/bond/aggregat (different nom pour la meme chose)
  
  ca peut se faire depuis le switch directement
```
conf t
int X (ou int X/Y ou int X/Y/Z)
shutdown (ou disable)
```
  pour remettre le port
```
no shutdown (ou enable)
```
  ca devrait vite de permettre de voir si les trunks sont bien actifs
  
  tu peux aussi voir dans les logs
  show log -r (show logging -r) suivant les switchs
  
  ca pourrait te montrer que tes ports n'arretent pas de basculer entre les deux interfaces
  
  à noter, si tu as un ESX, tu n'as pas besoin de configurer le trunk sur le switch en face, ni sur l'ESX, sinon ca fout le bordel
  Répondre
- [^] # Re: Tu ne peux pas
  
  Posté par Philippe M (site web personnel) le 14 février 2024 à 08:47. Évalué à 3 (+1/-0).
  J'ai passé tout l'après midi d'hier à faire des tests complémentaires
  
  Avant de me lancer dans la coupure de port et potentiellement perturber la production j'ai opté pour une autre méthode.
  
  Sur mon pc j'ai installé un container mrtg qui graphe tout les ports de tout mes switchs.
```
version: "3.5"

services:
  mrtg:
    image: fboaventura/dckr-mrtg:latest
    hostname: mrtg
    restart: always
    ports:
      - "8880:80"
    volumes:
      - "./conf.d:/etc/mrtg/conf.d"
      - "./html:/mrtg/html"
      - "/etc/localtime:/etc/localtime:ro"
      - "/etc/timezone:/etc/timezone:ro"
    environment:
        TZ: "Europe/Paris"
        HOSTS: "public:ipswitch1:1,public:ipswitch2:1,public:ipswitch3:1,public:ipswitch4:1,public:ipswitch5:1"
        WEBDIR: "/mrtg/html"
        USERID: 1000
        GROUPID: 1000
        INDEXMAKEROPTIONS: "--title=CaGrapheOuPas --columns=2 --perhost"
    tmpfs:
      - "/run"
```
  Je l'ai laissé tourner 1 heure pour voir si tout est ok pour lui et si il n'y a rien d'anormal niveau trafic et pas de point de saturation. En première analyse je peux constater que sur les liens passés en blocking par stp, j'ai quelques Kb de trafic. Je suppose que c'est juste le protocole qui test et envoi les états aux autres switch. Sur les liens actifs là j'ai le gros du trafic.
  
  Ensuite depuis un serveur physique connecté sur un des switch du cœur j'ai généré un fichier avec dd de 10G et lancé un transfert par scp ou par rsync "over ssh" vers un autre serveur physique connecté à l'autre switch du cœur. Bien sûr la fenêtre de tir est réduite puisque mrtg se lance toutes les 5mn de mémoire donc il a fallu contrôler l'heure de dernière mise à jour des graphes.
  
  Résultat : le transfert c'est bien passé, pas de coupure. Côté mrtg j'ai suivi les piques de trafic de port en port, cela m'a permis de confirmer que le bon chemin est emprunté. Cette méthode est plus facile à mettre en œuvre à un moment de la journée où il y a peu de trafic.
  
  A la lumière de ces essais une autre question est apparu : Mais c'est quoi ce débit ?!
  
  Le serveur A dispose d'une carte 1G, il est connecté à un switch 1G, l'interconnexion entre switch est un trunk de deux liens 1G (donc 2G) et le serveur B a lui aussi une carte 1G.
  
  Les stats de rsync me donne 49,95Mb/s pour transférer un fichier de 10,74G en 0:03:24 . Pendant le transfert je contrôlais qu'il n'y avait rien d'autre qui pouvait influencer le résultat.
  
  J'ai réalisé le même test depuis le serveur A en direction de mon pc connecté sur le même switch et j'obtiens pratiquement le même résultat.
  
  D'après vous est-ce normal ?
  
  Mes switchs sont des procurves, lldp et lacp sont bien activé.
  
  Born to Kill EndUser !
  Répondre
  - [^] # Re: Tu ne peux pas
    
    Posté par Strash le 14 février 2024 à 09:32. Évalué à 3 (+1/-0).
    
    Je suis pas spécialiste, mais en passant par SSH tu n'es pas limité par ton CPU?
    
    Répondre
    - [^] # Re: Tu ne peux pas
      
      Posté par Philippe M (site web personnel) le 14 février 2024 à 09:50. Évalué à 2 (+0/-0).
      Passer par ssh aura plus d'impact sur le CPU mais pour le coups j'ai de la marge avec le CPU des serveurs.
      
      Pour l'émetteur, certes c'est pas de dernière génération mais les services installés dessus correspondent à l'ancienneté du CPU
      
      cat proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz stepping : 5 cpu MHz : 2266.806 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm bogomips : 4533.61 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: [8]
      
      Born to Kill EndUser !
      Répondre
      - [^] # Re: Tu ne peux pas
        
        Posté par Strash le 14 février 2024 à 10:14. Évalué à 2 (+0/-0).
        
        Tu peux toujours vérifier si c'est pas le problème en testant un transfert en rsync/NFS.
        
        C'est pas chiffré mais pour ton test tu n'en as pas besoin.
        
        Répondre
        
        [^] # Re: Tu ne peux pas
        
        Posté par nono14 (site web personnel) le 14 février 2024 à 16:25. Évalué à 3 (+1/-0).
        
        Iperf est un bon outil pour tester les debits tcp/udp
        
        Système - Réseau - Sécurité Open Source
        
        Répondre
  - [^] # Re: Tu ne peux pas
    
    Posté par cg le 14 février 2024 à 09:34. Évalué à 5 (+3/-0).
    Hello,
    - Fichier de 10.74 Gigaoctets -> environ 85 à 100 Gigabits sur le réseau (selon la quantité "d'emballage réseau")
    - 85 Gigabits en 3 minutes et 24 secondes, ça fait 0,42 Gigabits par seconde, soit 420 Megabits par seconde, soit environ tes 49,95 Mégaoctets par seconde qu'indique rsync (Mégaoctets == MBps et non Mégabits Mbps !).
    On peut déjà en déduire que l'interface n'est pas en 100Mbps à cause d'un mauvais câble par exemple :).
    - Le maximum théorique que tu peux avoir sur un lien GE va être de 150 Mégaoctets (1000 Megabits). En pratique c'est moins car les protocoles réseau prennent de la place aussi.
    - D'expérience, avec rsync+ssh ce n'est pas forcément aberrant comme résultat. Essaye avec un outil type speedometer ou iperf pour voir si ça fait pareil. Voire même avec un truc tout simple comme speedtest.net si tu as une bonne connexion Internet (pas forcément simple sur un serveur).
    - Enfin, dans la majorité des configs, LACP ne va pas te permettre de saturer les deux liens de l'agrégat avec une seule connexion : une connexion TCP va rester sur un seul lien. Si tu veux faire de la répartition de charge au niveau paquet et non connexion, il faudra changer le mode de répartition des paquets au niveau du bond (le mode round-robin), mais ça peut mettre le bazar si les switchs le gèrent mal, il faut bien tester avant.
    - Pour contrer ce dernier cas, tu peux essayer aussi de lancer 10 transferts en parallèle avec rsync, netcat ou iperf, tu auras ainsi plus de chance d'arriver à saturer les deux liens GE.
    Bon courage !
    Répondre
  - [^] # Re: Tu ne peux pas
    
    Posté par NeoX le 14 février 2024 à 11:31. Évalué à 4 (+1/-0).
    
    j'ai eu le cas dans un fablab,
    on change la box ADSL par une box fibre chez un operateur qui a tout compris,
    
    et on bench avec les PC du fablab, speedtest, nperf, etc
    et on atteint peniblement les 250/300Mbps en RJ45 branché au travers du mur, vers la baie, puis un switch, puis la box
    
    y a 2 PC allumés en tout.
    
    j'ai branché mon laptop sur la meme prise murale avec le meme cable, je tapes les 800Mbps/900Mbps
    
    moralité c'etait bien les PCs qui etaient trop lent (AMD dual coeur, 8Go de ram)
    
    Répondre
    - [^] # Re: Tu ne peux pas
      
      Posté par Philippe M (site web personnel) le 14 février 2024 à 14:09. Évalué à 2 (+0/-0).
      
      Effectivement cela aurait pu avoir un impact mais j'ai fais un test avec mon portable qui est un "11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz" avec 32Go de ram et du nvme connecté au même switch que le serveur émetteur et j'arrive à peu de chose prêt aux mêmes valeurs.
      
      Born to Kill EndUser !
      
      Répondre
  - [^] # Re: Tu ne peux pas
    
    Posté par Loïs Taulelle ࿋ (site web personnel) le 14 février 2024 à 15:45. Évalué à 4 (+2/-0).
    
    Pour générer du paquet entre deux machines, il y a aussi iperf.
    
    ça enlève quelques couches pour aller au plus prêt des perf cpu/eth.
    
    Mes 2c
    
    Proverbe Alien : Sauvez la terre ? Mangez des humains !
    
    Répondre
# switch port monitor & ntop

Posté par rycks le 14 février 2024 à 13:50. Évalué à 4 (+2/-0).

Hello,
à vérifier mais peut-être qu'un port passé en mode "monitor" / "duplicate all" + ntop branché sur ce port pourrait remonter des éléments intéressants il analyse du niveau 2 sans pb:

https://www.ntop.org/products/traffic-analysis/ntop/

peut-être qu'il faudra faire la manip switch par switch, je donne juste une idée a chaud

eric.linuxfr@sud-ouest.org

Répondre

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.