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 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Délai d'attente de la demande dépassé. >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms 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 temps<1ms 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 temps<1ms 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 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 >>>>>>>>> Réponse de 192.168.130.5 : octets=32 temps<1ms 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é. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Des idées pour ce genre de problème s'il vous plait?? >>>>>>>>> >>>>>>>>> Merci d'avance pour votre aide >>>>>>>>> Cordialement, >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------- >>>>>>>> Liste de diffusion du FRnOG >>>>>>>> http://www.frnog.org/ >>>>>>>> >>>>>>>> --------------------------- >>>>>>> Liste de diffusion du FRnOG >>>>>>> http://www.frnog.org/ >>>>>>> >>>>>>> --------------------------- >>>>>> Liste de diffusion du FRnOG >>>>>> http://www.frnog.org/ >>>>>> >>>>> >>>>> >>>> >>> >>> -- >>> Jérôme BERTHIER >>> >>> >>> >>> --------------------------- >>> Liste de diffusion du FRnOG >>> http://www.frnog.org/ >>> >> >> >> >> -- >> >> * <http://dz.linkedin.com/pub/mehdi-badaoui/20/944/3ab/>* >> >> > -- * <http://dz.linkedin.com/pub/mehdi-badaoui/20/944/3ab/>* --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/