Bonjour,
 
je rencontre un pb de coupures réseau, que l'on constate notamment en faisant un "ping -t" entre deux serveurs. Lorsqu'on lance ce ping -t pendant par exemple 2 heures, au bout de 2 heures, on se rend compte qu'on a un certain nombre de paquets qui n'arrivent pas, perdus.
 
Je précise que le ping est fait sur un serveur physique, vers un serveur virtuel hébergé par le physique, donc on ne passe ni par un câble, ni par un switch.
 
Je voudrais identifier la cause de la perte de ces paquets, connaissez-vous un outil qui permette de le faire ? Accessoirement, avez-vous une idée du pb qui pourrait se poser ?
 
Merci d'avance de vos réponses

c'est quoi ton hyperviseur ?

La console Hyper-v. Note que j'ai aussi des coupures de physique à physique et de virtuel à virtuel, le problème ne se limite pas à l'exemple que je donnais.

tu es en Hyper V serveur ou un 2008 R2 avec le role Hyper V.
Comment sont configuré tes réseaux sur ton hyperviseur?

2008 avec rôle Hyper V. C'est mes tech qui ont configuré les réseaux, pour tout te dire, je ne suis que le messager du problème
 
Je leur pose la question quand ils rentrent d'inter et je reviens vers toi. Merci en tous cas de me consacrer du temps.

Alors un élément de réponse : chaque serveur, physique ou virtuel, dispose de sa propre carte réseau physique (4 cartes réseau physiques par serveur). Sauf sur un serveur, si j'ai bien compris, on fait du teaming 2 par 2.
 
Sinon, est-ce aberrant de perdre des paquets sur un réseau ? Sachant qu'on fait du flow control pour éviter les engorgements, peut-il être normal d'avoir des paquets non reçus lors d'un ping -t ?

Non ce n'est pas aberrant, surtout avec du flow control, si celui-ci est mal interprété par l'équipement adjacent (en fait ça fonctionne globalement très mal, sauf sur des switchs pro récents).
 
En théorie il faudrait passer sur les ports de switchs et regarder les niveau de drops dans les buffers émission / réception des ports traversés.

C'est du gros procurve très cher qui date d'un an et demi, j'espère qu'il gère ça correctement
 
Regarder les niveaux de drop, d'accord on regarde ça et je reviens vous dire ce qu'il en est.

hahaha procurve c'est de la daube
 
Normalement dans les "show interface" ça donne un minimum d'infos.

Procurve c'est de la daube ? Tu veux dire par rapport à Cisco par exemple ?

Entre autres. En fait il y a des problèmes de buffering dans les ASIC broadcom low cost qu'ils utilisent.
 
Sur certains modèles quand le buffer est plein et que tu as un paquet "en trop" qui arrive, plutôt que de jeter le paquet supplémentaire, le switch jette la moitié de ce qui est stocké dans la file d'attente.

On parle de ça : Switch Procurve 5406ZL. Ca m'avait quand même l'air d'être du bon matos, non ?

oui c'est correct. à toi la joie du troubleshooting

Merci, ça me fait plaisir

on sait quand ça commence, jamais quand ça termine

dreamer18 arréte il y a trop de matracage CISCO. Ce ne sont pas les seul. Ils sont trés fort pour Hypnotiser les jeunes étudiant crédule avec les CCNA. En fais tu partie ?
j'ai des 2910al et un gros chassis 8212zl.
je fais des VLAN spanning tree, module wifi, lacp etc..
je n'ai jamais eu de problémes.
Mais c'est vrais que HP a differentes gammes.
 
Pas besoin de faire le culte du CISCO !  
 
 

mouaif, HP pour moi c'est de la daube, au niveau techno Juniper me semble plus crédible (virtual chassis, Qfabric...)
 
Non HP tout ce qu'ils savent faire c'est acheter de la puce broadcom et faire du pas cher avec 3 ans de retard sur l'innovation technologique.
 
FCOE chez HP ça fonctionne toujours pas. Le seul truc bien chez eux c'est virtual connect.