Re: Fwd: [FRnOG] [JOBS] Coupure de connexion SSH
Bonjour Mehdi, si jamais il s'avère que le nexus soit en cause, pourras-tu nous partager la release en cause et celle qui la corrige? Merci Le 26 mai 2015 16:05, Mehdi BADAOUI mehdiu...@gmail.com a écrit : Merci pour ta réponse Jérôme, je vais vérifier ça. Cordialement, Le 26 mai 2015 15:46, Jérôme BERTHIER j...@laposte.net a écrit : Salut, Tu as des CRC dans tes compteurs ? Si oui, petite subtilité Nexus (au moins valable pour les 5500). Ils fonctionnent en mode cut-through. Les erreurs ne sont pas comptabilisées en ingress mais en egress. Le switch fait suivre la trame pourrie avec un flag FCS modifié pour alerter l'hôte destinataire (ou le prochain switch capable de dropper en mode store and forward). Si tu veux voir où ça se dégrade, faut creuser un peu dans les compteurs internes. Exemple sur N5K : show hardware internal carmel crc : http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/troubleshooting/guide/N5K_Troubleshooting_Guide/n5K_ts_l2.html#99218 J'ai eu le cas entre deux salles reliées par des Nexus 5000. Un port Nexus reliant un pare-feu s'est mis à incrémenter des erreurs CRC. Au final, c'était un SFP d'un autre port entre les deux salles qui était pourri : les nexus forwardaient en l'état les trames erronées. Bon courage Le 26/05/2015 14:44, Mehdi BADAOUI a écrit : Hello All, Après un long week-end retour sur le problème :) Apparemment l'erreur viens du Nexus et pas de mon serveur, ce matin mon deuxième serveur commence à être impacté avec 5% de perte de paquet. On a constaté ce matin que y a une perte de paquet sur les deux Nexus 3548P alors la solution qu'on a pour le moment est de faire un upgrade des Nexus Est ce que y a d'autres propositions? Cordialement, -- Message transféré -- De : Mehdi BADAOUI mehdiu...@gmail.com Date : 22 mai 2015 09:10 Objet : Re: [FRnOG] [JOBS] Coupure de connexion SSH À : David Ponzone david.ponz...@gmail.com Merci à vous tous, Mehdi Le 21 mai 2015 18:14, David Ponzone david.ponz...@gmail.com a écrit : +1 Faut régler le problème de pertes de paquet, qui est plus qu’anormal sur un LAN. Dans l’ordre de probabilité décroissante: -défaut sur l’OS (si OS=windows) (ok je sors) -problème d’autonégo -défaut de câble -défaut de carte réseau -défaut sur l’OS (si OS=linux) -pas de chance -défaut sur Nexus Le 21 mai 2015 à 14:12, Alexis Lameire alexis.lame...@gmail.com a écrit : j'ai vue passé un truc similaire sur cette ml il y a quelque temps de ca. Envois nous un ptit ifconfig de l'interface de ton serveur, savoir si il est en 1G ou 100M (soucis d'auto nego, toussa toussa). Cordialement Alexis Lameire Le 21 mai 2015 14:08, Thomas Dubois thomas.f.dub...@gmail.com a écrit : Et pourquoi le sujet est à propos de SSH alors que c'est un problème de Layer 2? Quand tu fais des traceroutes, tu passes par le même chemin pour les 2 serveurs ? Le TTL est de 63 sur le ping donc la machine est connectée sur le même réseau. Thomas D. Le 21 mai 2015 13:56, Jeremy li...@freeheberg.com a écrit : Pourquoi ce mail atterrit sur la boite JOBS ? ... Jérémy Le 21/05/2015 13:36, Mehdi BADAOUI a écrit : Bonjour la liste, J'ai deux serveurs reliés à un même Vlan, le Vlan est connecté à un routeur Nexus. Un des deux serveurs a des coupures fréquentes de connexion ssh et pas le deuxième. Je précise que les deux serveurs ne passe pas par un FireWall. Résultat d'un Ping d'une machine X vers le serveur en question. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps=1 ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la
Re: Fwd: [FRnOG] [JOBS] Coupure de connexion SSH
Bonjour Louis, On a trouvé la source du problème hier soir, c'est un Nexus qui est sur un de nos sites en France, on l'a coupé et tout est revenu à la normale depuis. Par contre on l'a pas encore récupéré pour pouvoir faire des testes et comprendre la cause de son dysfonctionnement. Cordialement, Le 27 mai 2015 10:52, Louis luigi.1...@gmail.com a écrit : Bonjour Mehdi, si jamais il s'avère que le nexus soit en cause, pourras-tu nous partager la release en cause et celle qui la corrige? Merci Le 26 mai 2015 16:05, Mehdi BADAOUI mehdiu...@gmail.com a écrit : Merci pour ta réponse Jérôme, je vais vérifier ça. Cordialement, Le 26 mai 2015 15:46, Jérôme BERTHIER j...@laposte.net a écrit : Salut, Tu as des CRC dans tes compteurs ? Si oui, petite subtilité Nexus (au moins valable pour les 5500). Ils fonctionnent en mode cut-through. Les erreurs ne sont pas comptabilisées en ingress mais en egress. Le switch fait suivre la trame pourrie avec un flag FCS modifié pour alerter l'hôte destinataire (ou le prochain switch capable de dropper en mode store and forward). Si tu veux voir où ça se dégrade, faut creuser un peu dans les compteurs internes. Exemple sur N5K : show hardware internal carmel crc : http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/troubleshooting/guide/N5K_Troubleshooting_Guide/n5K_ts_l2.html#99218 J'ai eu le cas entre deux salles reliées par des Nexus 5000. Un port Nexus reliant un pare-feu s'est mis à incrémenter des erreurs CRC. Au final, c'était un SFP d'un autre port entre les deux salles qui était pourri : les nexus forwardaient en l'état les trames erronées. Bon courage Le 26/05/2015 14:44, Mehdi BADAOUI a écrit : Hello All, Après un long week-end retour sur le problème :) Apparemment l'erreur viens du Nexus et pas de mon serveur, ce matin mon deuxième serveur commence à être impacté avec 5% de perte de paquet. On a constaté ce matin que y a une perte de paquet sur les deux Nexus 3548P alors la solution qu'on a pour le moment est de faire un upgrade des Nexus Est ce que y a d'autres propositions? Cordialement, -- Message transféré -- De : Mehdi BADAOUI mehdiu...@gmail.com Date : 22 mai 2015 09:10 Objet : Re: [FRnOG] [JOBS] Coupure de connexion SSH À : David Ponzone david.ponz...@gmail.com Merci à vous tous, Mehdi Le 21 mai 2015 18:14, David Ponzone david.ponz...@gmail.com a écrit : +1 Faut régler le problème de pertes de paquet, qui est plus qu’anormal sur un LAN. Dans l’ordre de probabilité décroissante: -défaut sur l’OS (si OS=windows) (ok je sors) -problème d’autonégo -défaut de câble -défaut de carte réseau -défaut sur l’OS (si OS=linux) -pas de chance -défaut sur Nexus Le 21 mai 2015 à 14:12, Alexis Lameire alexis.lame...@gmail.com a écrit : j'ai vue passé un truc similaire sur cette ml il y a quelque temps de ca. Envois nous un ptit ifconfig de l'interface de ton serveur, savoir si il est en 1G ou 100M (soucis d'auto nego, toussa toussa). Cordialement Alexis Lameire Le 21 mai 2015 14:08, Thomas Dubois thomas.f.dub...@gmail.com a écrit : Et pourquoi le sujet est à propos de SSH alors que c'est un problème de Layer 2? Quand tu fais des traceroutes, tu passes par le même chemin pour les 2 serveurs ? Le TTL est de 63 sur le ping donc la machine est connectée sur le même réseau. Thomas D. Le 21 mai 2015 13:56, Jeremy li...@freeheberg.com a écrit : Pourquoi ce mail atterrit sur la boite JOBS ? ... Jérémy Le 21/05/2015 13:36, Mehdi BADAOUI a écrit : Bonjour la liste, J'ai deux serveurs reliés à un même Vlan, le Vlan est connecté à un routeur Nexus. Un des deux serveurs a des coupures fréquentes de connexion ssh et pas le deuxième. Je précise que les deux serveurs ne passe pas par un FireWall. Résultat d'un Ping d'une machine X vers le serveur en question. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps=1 ms TTL=63
Fwd: [FRnOG] [JOBS] Coupure de connexion SSH
Hello All, Après un long week-end retour sur le problème :) Apparemment l'erreur viens du Nexus et pas de mon serveur, ce matin mon deuxième serveur commence à être impacté avec 5% de perte de paquet. On a constaté ce matin que y a une perte de paquet sur les deux Nexus 3548P alors la solution qu'on a pour le moment est de faire un upgrade des Nexus Est ce que y a d'autres propositions? Cordialement, -- Message transféré -- De : Mehdi BADAOUI mehdiu...@gmail.com Date : 22 mai 2015 09:10 Objet : Re: [FRnOG] [JOBS] Coupure de connexion SSH À : David Ponzone david.ponz...@gmail.com Merci à vous tous, Mehdi Le 21 mai 2015 18:14, David Ponzone david.ponz...@gmail.com a écrit : +1 Faut régler le problème de pertes de paquet, qui est plus qu’anormal sur un LAN. Dans l’ordre de probabilité décroissante: -défaut sur l’OS (si OS=windows) (ok je sors) -problème d’autonégo -défaut de câble -défaut de carte réseau -défaut sur l’OS (si OS=linux) -pas de chance -défaut sur Nexus Le 21 mai 2015 à 14:12, Alexis Lameire alexis.lame...@gmail.com a écrit : j'ai vue passé un truc similaire sur cette ml il y a quelque temps de ca. Envois nous un ptit ifconfig de l'interface de ton serveur, savoir si il est en 1G ou 100M (soucis d'auto nego, toussa toussa). Cordialement Alexis Lameire Le 21 mai 2015 14:08, Thomas Dubois thomas.f.dub...@gmail.com a écrit : Et pourquoi le sujet est à propos de SSH alors que c'est un problème de Layer 2? Quand tu fais des traceroutes, tu passes par le même chemin pour les 2 serveurs ? Le TTL est de 63 sur le ping donc la machine est connectée sur le même réseau. Thomas D. Le 21 mai 2015 13:56, Jeremy li...@freeheberg.com a écrit : Pourquoi ce mail atterrit sur la boite JOBS ? ... Jérémy Le 21/05/2015 13:36, Mehdi BADAOUI a écrit : Bonjour la liste, J'ai deux serveurs reliés à un même Vlan, le Vlan est connecté à un routeur Nexus. Un des deux serveurs a des coupures fréquentes de connexion ssh et pas le deuxième. Je précise que les deux serveurs ne passe pas par un FireWall. Résultat d'un Ping d'une machine X vers le serveur en question. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps=1 ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32
Re: Fwd: [FRnOG] [JOBS] Coupure de connexion SSH
Salut, Tu as des CRC dans tes compteurs ? Si oui, petite subtilité Nexus (au moins valable pour les 5500). Ils fonctionnent en mode cut-through. Les erreurs ne sont pas comptabilisées en ingress mais en egress. Le switch fait suivre la trame pourrie avec un flag FCS modifié pour alerter l'hôte destinataire (ou le prochain switch capable de dropper en mode store and forward). Si tu veux voir où ça se dégrade, faut creuser un peu dans les compteurs internes. Exemple sur N5K : show hardware internal carmel crc : http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/troubleshooting/guide/N5K_Troubleshooting_Guide/n5K_ts_l2.html#99218 J'ai eu le cas entre deux salles reliées par des Nexus 5000. Un port Nexus reliant un pare-feu s'est mis à incrémenter des erreurs CRC. Au final, c'était un SFP d'un autre port entre les deux salles qui était pourri : les nexus forwardaient en l'état les trames erronées. Bon courage Le 26/05/2015 14:44, Mehdi BADAOUI a écrit : Hello All, Après un long week-end retour sur le problème :) Apparemment l'erreur viens du Nexus et pas de mon serveur, ce matin mon deuxième serveur commence à être impacté avec 5% de perte de paquet. On a constaté ce matin que y a une perte de paquet sur les deux Nexus 3548P alors la solution qu'on a pour le moment est de faire un upgrade des Nexus Est ce que y a d'autres propositions? Cordialement, -- Message transféré -- De : Mehdi BADAOUI mehdiu...@gmail.com Date : 22 mai 2015 09:10 Objet : Re: [FRnOG] [JOBS] Coupure de connexion SSH À : David Ponzone david.ponz...@gmail.com Merci à vous tous, Mehdi Le 21 mai 2015 18:14, David Ponzone david.ponz...@gmail.com a écrit : +1 Faut régler le problème de pertes de paquet, qui est plus qu’anormal sur un LAN. Dans l’ordre de probabilité décroissante: -défaut sur l’OS (si OS=windows) (ok je sors) -problème d’autonégo -défaut de câble -défaut de carte réseau -défaut sur l’OS (si OS=linux) -pas de chance -défaut sur Nexus Le 21 mai 2015 à 14:12, Alexis Lameire alexis.lame...@gmail.com a écrit : j'ai vue passé un truc similaire sur cette ml il y a quelque temps de ca. Envois nous un ptit ifconfig de l'interface de ton serveur, savoir si il est en 1G ou 100M (soucis d'auto nego, toussa toussa). Cordialement Alexis Lameire Le 21 mai 2015 14:08, Thomas Dubois thomas.f.dub...@gmail.com a écrit : Et pourquoi le sujet est à propos de SSH alors que c'est un problème de Layer 2? Quand tu fais des traceroutes, tu passes par le même chemin pour les 2 serveurs ? Le TTL est de 63 sur le ping donc la machine est connectée sur le même réseau. Thomas D. Le 21 mai 2015 13:56, Jeremy li...@freeheberg.com a écrit : Pourquoi ce mail atterrit sur la boite JOBS ? ... Jérémy Le 21/05/2015 13:36, Mehdi BADAOUI a écrit : Bonjour la liste, J'ai deux serveurs reliés à un même Vlan, le Vlan est connecté à un routeur Nexus. Un des deux serveurs a des coupures fréquentes de connexion ssh et pas le deuxième. Je précise que les deux serveurs ne passe pas par un FireWall. Résultat d'un Ping d'une machine X vers le serveur en question. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps=1 ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de
Re: Fwd: [FRnOG] [JOBS] Coupure de connexion SSH
Merci pour ta réponse Jérôme, je vais vérifier ça. Cordialement, Le 26 mai 2015 15:46, Jérôme BERTHIER j...@laposte.net a écrit : Salut, Tu as des CRC dans tes compteurs ? Si oui, petite subtilité Nexus (au moins valable pour les 5500). Ils fonctionnent en mode cut-through. Les erreurs ne sont pas comptabilisées en ingress mais en egress. Le switch fait suivre la trame pourrie avec un flag FCS modifié pour alerter l'hôte destinataire (ou le prochain switch capable de dropper en mode store and forward). Si tu veux voir où ça se dégrade, faut creuser un peu dans les compteurs internes. Exemple sur N5K : show hardware internal carmel crc : http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/troubleshooting/guide/N5K_Troubleshooting_Guide/n5K_ts_l2.html#99218 J'ai eu le cas entre deux salles reliées par des Nexus 5000. Un port Nexus reliant un pare-feu s'est mis à incrémenter des erreurs CRC. Au final, c'était un SFP d'un autre port entre les deux salles qui était pourri : les nexus forwardaient en l'état les trames erronées. Bon courage Le 26/05/2015 14:44, Mehdi BADAOUI a écrit : Hello All, Après un long week-end retour sur le problème :) Apparemment l'erreur viens du Nexus et pas de mon serveur, ce matin mon deuxième serveur commence à être impacté avec 5% de perte de paquet. On a constaté ce matin que y a une perte de paquet sur les deux Nexus 3548P alors la solution qu'on a pour le moment est de faire un upgrade des Nexus Est ce que y a d'autres propositions? Cordialement, -- Message transféré -- De : Mehdi BADAOUI mehdiu...@gmail.com Date : 22 mai 2015 09:10 Objet : Re: [FRnOG] [JOBS] Coupure de connexion SSH À : David Ponzone david.ponz...@gmail.com Merci à vous tous, Mehdi Le 21 mai 2015 18:14, David Ponzone david.ponz...@gmail.com a écrit : +1 Faut régler le problème de pertes de paquet, qui est plus qu’anormal sur un LAN. Dans l’ordre de probabilité décroissante: -défaut sur l’OS (si OS=windows) (ok je sors) -problème d’autonégo -défaut de câble -défaut de carte réseau -défaut sur l’OS (si OS=linux) -pas de chance -défaut sur Nexus Le 21 mai 2015 à 14:12, Alexis Lameire alexis.lame...@gmail.com a écrit : j'ai vue passé un truc similaire sur cette ml il y a quelque temps de ca. Envois nous un ptit ifconfig de l'interface de ton serveur, savoir si il est en 1G ou 100M (soucis d'auto nego, toussa toussa). Cordialement Alexis Lameire Le 21 mai 2015 14:08, Thomas Dubois thomas.f.dub...@gmail.com a écrit : Et pourquoi le sujet est à propos de SSH alors que c'est un problème de Layer 2? Quand tu fais des traceroutes, tu passes par le même chemin pour les 2 serveurs ? Le TTL est de 63 sur le ping donc la machine est connectée sur le même réseau. Thomas D. Le 21 mai 2015 13:56, Jeremy li...@freeheberg.com a écrit : Pourquoi ce mail atterrit sur la boite JOBS ? ... Jérémy Le 21/05/2015 13:36, Mehdi BADAOUI a écrit : Bonjour la liste, J'ai deux serveurs reliés à un même Vlan, le Vlan est connecté à un routeur Nexus. Un des deux serveurs a des coupures fréquentes de connexion ssh et pas le deuxième. Je précise que les deux serveurs ne passe pas par un FireWall. Résultat d'un Ping d'une machine X vers le serveur en question. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps=1 ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63 Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Réponse de 192.168.130.5 : octets=32
