Re: [FRnOG] [TECH] Question pour barbus
que disent les cksum ? tu as beaucoup d'incorrect ? Le 05/10/2013 00:47, Jérémy Martin a écrit : Merci pour vos réponses public/privés. Les serveurs sont strictement identiques en hardware. On a trouvé une différence à l'instant entre les version de SSH qui pourrait peut être expliquer mais reste à trouver ce que fait le vieux sshd par rapport à l'autre. Coté MTU / Fragmentation, on est ici sur des packets perdus de 170 octets, donc pas d'atteinte de la MTU max à 1500 octets. De plus, comment expliquer que l'un passerais bien, et pas l'autre ? C'est vraiment une prise de tête incroyable, j'ai jamais vu ça. Merci encore pour vos apports, remarques et aides précieuses :) Cordialement, Jérémy Martin Le 04/10/2013 21:06, Jérémy Martin a écrit : Bonsoir, On a un cas de pertes de trame TCP sur notre réseau qui est inexplicable et sur lequel nous séchons, ainsi que SFR (pour la partie L2L). Pour faire simple, les trame TCP port 22 et 21 (a priori, celles qui ont besoins que les ACK ne soient pas perdu sous peine de forts lags) sont perdus à hauteur de 5-10 % en cas de stress important de notre L2L (et uniquement à cet endroit a priori). Ce qui est très très surprenant, c'est que j'ai 2 serveurs sur le même /24, avec le même kernel (debian), et a priori la même conf réseau. Sur l'un, on a énormément de : 152267 30.163305000AA.BB.CC.DD 192.168.1.17TCP106 [TCP Retransmission] 14558 52629 [PSH, ACK] Seq=205 Ack=365 Win=148 Len=52 Vous remarquerez de plus que j'utilise ici un port spécifique et que le problème se produit autant en 14558 qu'en port 22. Sur l'autre serveurs, vraiment les mêmes conditions de test, AUCUNE PERTE ! Le HTTP et les protocoles de jeux, ou RDP ne sont absolument pas touchés(aucune perteégalement). Là je sèche vraiment. Un paramètre dans le kernelpourrait générer les échanges en SSH ou FTP ? Ce dont je suis sur : 1) Pas de QoS sur le L2L (officiellement, après je ne sais pas ce que fait SFR dans son MPLS) 2) Pas de rate-limit ou QoS sur les routeurs d'un coté à l'autre du L2L (conf neutres). 3) Pas de pertes sur le switch Bref, si quelqu'un a déjà rencontré un cas de ce type, je suis preneur. Merci pour votre attention, --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Question pour barbus
Le 04/10/2013 21:06, Jérémy Martin a écrit : Bonsoir, Ce qui est très très surprenant, c'est que j'ai 2 serveurs sur le même /24, avec le même kernel (debian), et a priori la même conf réseau. Changer de port sur le switch ? Changer de switch ? Câble réseau fatigué ? Carte réseau qui prend l'eau ? J. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Question pour barbus
Le 04/10/2013 21:06, Jérémy Martin a écrit : Bonsoir, On a un cas de pertes de trame TCP sur notre réseau qui est inexplicable et sur lequel nous séchons, ainsi que SFR (pour la partie L2L). Peut être faire le tour des configs des MTU et jouer avec du ping -s 2000/1500. Peut être des histoires de fragmentation ... Bon courage, Julien --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Question pour barbus
Merci pour vos réponses public/privés. Les serveurs sont strictement identiques en hardware. On a trouvé une différence à l'instant entre les version de SSH qui pourrait peut être expliquer mais reste à trouver ce que fait le vieux sshd par rapport à l'autre. Coté MTU / Fragmentation, on est ici sur des packets perdus de 170 octets, donc pas d'atteinte de la MTU max à 1500 octets. De plus, comment expliquer que l'un passerais bien, et pas l'autre ? C'est vraiment une prise de tête incroyable, j'ai jamais vu ça. Merci encore pour vos apports, remarques et aides précieuses :) Cordialement, Jérémy Martin Le 04/10/2013 21:06, Jérémy Martin a écrit : Bonsoir, On a un cas de pertes de trame TCP sur notre réseau qui est inexplicable et sur lequel nous séchons, ainsi que SFR (pour la partie L2L). Pour faire simple, les trame TCP port 22 et 21 (a priori, celles qui ont besoins que les ACK ne soient pas perdu sous peine de forts lags) sont perdus à hauteur de 5-10 % en cas de stress important de notre L2L (et uniquement à cet endroit a priori). Ce qui est très très surprenant, c'est que j'ai 2 serveurs sur le même /24, avec le même kernel (debian), et a priori la même conf réseau. Sur l'un, on a énormément de : 152267 30.163305000AA.BB.CC.DD 192.168.1.17TCP106 [TCP Retransmission] 14558 52629 [PSH, ACK] Seq=205 Ack=365 Win=148 Len=52 Vous remarquerez de plus que j'utilise ici un port spécifique et que le problème se produit autant en 14558 qu'en port 22. Sur l'autre serveurs, vraiment les mêmes conditions de test, AUCUNE PERTE ! Le HTTP et les protocoles de jeux, ou RDP ne sont absolument pas touchés(aucune perteégalement). Là je sèche vraiment. Un paramètre dans le kernelpourrait générer les échanges en SSH ou FTP ? Ce dont je suis sur : 1) Pas de QoS sur le L2L (officiellement, après je ne sais pas ce que fait SFR dans son MPLS) 2) Pas de rate-limit ou QoS sur les routeurs d'un coté à l'autre du L2L (conf neutres). 3) Pas de pertes sur le switch Bref, si quelqu'un a déjà rencontré un cas de ce type, je suis preneur. Merci pour votre attention, --- Liste de diffusion du FRnOG http://www.frnog.org/
