Re: [FRnOG] Cherche outil générant délai, gigue, pertes de paquets, ...
2008/3/4 Vivien GUEANT <[EMAIL PROTECTED]>: > Bonsoir, > > Je cherche un outil générant sur une liaison ethernet du délai, de la > gigue, des pertes de paquets, sachant réduire le débit... > > Le but est de simuler Internet sur un réseau local, de voir comment > réagit une application dans des conditions catastrophiques. Je placerais > ce logiciel sur une 3éme PC entre le client et le serveur. > > Je connais PacketStorm ( http://www.packetstorm.com/ ) mais il est > payant et c'est cher pour mon usage perso... > > Si vous connaissez un outil gratuit qui ne génère même qu'une seule de > ces perturbations je suis intéressé. > > Vivien. Pour ceux ayant un compte CCO, Wan bridge fais ca très bien (dispo sous forme de live cd). http://www.cisco.com/cgi-bin/tablebuild.pl/fe_util Sidney --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Cherche outil générant délai, g igue, pertes de paquets, ...
Le 4 mars 08 à 23:20, eberkut a écrit : Le 4 mars 08 à 23:07, Vivien GUEANT a écrit : Bonsoir, Je cherche un outil générant sur une liaison ethernet du délai, de la gigue, des pertes de paquets, sachant réduire le débit... Le but est de simuler Internet sur un réseau local, de voir comment réagit une application dans des conditions catastrophiques. Je placerais ce logiciel sur une 3éme PC entre le client et le serveur. Je connais PacketStorm ( http://www.packetstorm.com/ ) mais il est payant et c'est cher pour mon usage perso... Si vous connaissez un outil gratuit qui ne génère même qu'une seule de ces perturbations je suis intéressé. C'est typiquement le genre d'usage pour lequel dummynet(4) a été conçu sous FreeBSD. Tu utilises ipfw(8) pour classifier les paquets et après tu peux définir une bande passante, du délai, de la perte sur un pipe vers lequel les paquets sont dirigés. Ils peuvent même être redirigés avec une probabilité pour simuler du multipath. Voir http://www.freebsd.org/cgi/man.cgi?query=ipfw&sektion=8&apropos=0&manpath=FreeBSD+7.0-RELEASE#TRAFFIC_SHAPER_(DUMMYNET)_CONFIGURATION Pour la gigue, ça revient souvent et j'ai jamais trouvé. netem sous Linux apporte un peu plus que dummynet est reste une solution "kernel based". Il doit exister des lice cd pour ca Sinon a part packetstorm, y'a Anue Systems http://www.anuesystems.com/ (eux au moins ils perdent pas de packets ;-). ++ -- Olivier Warin --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Cherche outil générant délai, g igue, pertes de paquets, ...
Bonjour, Netem, sous Linux, fonctionne bien pour nous. http://www.linux-foundation.org/en/Net:Netem http://devresources.linux-foundation.org/shemminger/netem/example.html Bonne semaine, Samuel Tremblay-Cossette On 4-Mar-08, at 5:07 PM, Vivien GUEANT wrote: Bonsoir, Je cherche un outil générant sur une liaison ethernet du délai, de la gigue, des pertes de paquets, sachant réduire le débit... Le but est de simuler Internet sur un réseau local, de voir comment réagit une application dans des conditions catastrophiques. Je placerais ce logiciel sur une 3éme PC entre le client et le serveur. Je connais PacketStorm ( http://www.packetstorm.com/ ) mais il est payant et c'est cher pour mon usage perso... Si vous connaissez un outil gratuit qui ne génère même qu'une seule de ces perturbations je suis intéressé. Vivien. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Cherche outil générant délai, gigue, pertes de paquets, ...
ipfw/dummynet pour free/dragonflybsd ( http://info.iet.unipi.it/~luigi/ip_dummynet/ ) dummynet is a flexible tool originally designed for testing networking protocols, and since then (mis)used for bandwidth management. It simulates/enforces queue and bandwidth limitations, delays, packet losses, and multipath effects. It also implements a variant of Weighted Fair Queueing called WF2Q+. It can be used on user's workstations, or on FreeBSD machines acting as routers or bridges. 2008/3/4 Raphaël Jacquot <[EMAIL PROTECTED]>: > Vivien GUEANT wrote: > > Bonsoir, > > > > Je cherche un outil générant sur une liaison ethernet du délai, de la > > gigue, des pertes de paquets, sachant réduire le débit... > > > > Le but est de simuler Internet sur un réseau local, de voir comment > > réagit une application dans des conditions catastrophiques. Je placerais > > ce logiciel sur une 3éme PC entre le client et le serveur. > > > > Je connais PacketStorm ( http://www.packetstorm.com/ ) mais il est > > payant et c'est cher pour mon usage perso... > > > > Si vous connaissez un outil gratuit qui ne génère même qu'une seule de > > ces perturbations je suis intéressé. > > > > Vivien. > > suffit de prendre un cisco et de le donner a config a un tech > numéricable non ? > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > -- Jean
Re: [FRnOG] Cherche outil générant délai, g igue, pertes de paquets, ...
Le 4 mars 08 à 23:07, Vivien GUEANT a écrit : Bonsoir, Je cherche un outil générant sur une liaison ethernet du délai, de la gigue, des pertes de paquets, sachant réduire le débit... Le but est de simuler Internet sur un réseau local, de voir comment réagit une application dans des conditions catastrophiques. Je placerais ce logiciel sur une 3éme PC entre le client et le serveur. Je connais PacketStorm ( http://www.packetstorm.com/ ) mais il est payant et c'est cher pour mon usage perso... Si vous connaissez un outil gratuit qui ne génère même qu'une seule de ces perturbations je suis intéressé. C'est typiquement le genre d'usage pour lequel dummynet(4) a été conçu sous FreeBSD. Tu utilises ipfw(8) pour classifier les paquets et après tu peux définir une bande passante, du délai, de la perte sur un pipe vers lequel les paquets sont dirigés. Ils peuvent même être redirigés avec une probabilité pour simuler du multipath. Voir http://www.freebsd.org/cgi/man.cgi?query=ipfw&sektion=8&apropos=0&manpath=FreeBSD+7.0-RELEASE#TRAFFIC_SHAPER_(DUMMYNET)_CONFIGURATION Pour la gigue, ça revient souvent et j'ai jamais trouvé. Cordialement, --eberkut "you can tune a file system but you can't tune a fish" (man 8 tunefs, BUGS) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Cherche outil générant délai, gi gue, pertes de paquets, ...
Vivien GUEANT wrote: Bonsoir, Je cherche un outil générant sur une liaison ethernet du délai, de la gigue, des pertes de paquets, sachant réduire le débit... Le but est de simuler Internet sur un réseau local, de voir comment réagit une application dans des conditions catastrophiques. Je placerais ce logiciel sur une 3éme PC entre le client et le serveur. Je connais PacketStorm ( http://www.packetstorm.com/ ) mais il est payant et c'est cher pour mon usage perso... Si vous connaissez un outil gratuit qui ne génère même qu'une seule de ces perturbations je suis intéressé. Vivien. suffit de prendre un cisco et de le donner a config a un tech numéricable non ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Cherche outil générant délai, gigue, pertes de paquets, ...
Bonsoir, Je cherche un outil générant sur une liaison ethernet du délai, de la gigue, des pertes de paquets, sachant réduire le débit... Le but est de simuler Internet sur un réseau local, de voir comment réagit une application dans des conditions catastrophiques. Je placerais ce logiciel sur une 3éme PC entre le client et le serveur. Je connais PacketStorm ( http://www.packetstorm.com/ ) mais il est payant et c'est cher pour mon usage perso... Si vous connaissez un outil gratuit qui ne génère même qu'une seule de ces perturbations je suis intéressé. Vivien. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] problème/enigme TCP qui bégaye
Bonjour, Le problème me fait penser à un pb similaire que j'ai eu il y a déjà pas mal de temps, mais qui ressemble un peu à celui là. J'avais des gros lags sur une interface réseau aléatoirement sur certains services tcp/ip, la solution a été de changer l'interface réseau .. radicale mais ça a marché. Il s'agissait d'après quelques infos sur le net d'une instabilité du chip gigabit sur certains OS... A ta place j'essaierai de mettre une simple carte 10/100 avec les même config pour tester ... Bon courage .. Brice VINCENT. 2008/3/4 Gabriel Barazer <[EMAIL PROTECTED]>: On 03/04/2008 12:19:27 AM +0100, "Christophe VIAUD" > <[EMAIL PROTECTED]> wrote: > > >> - coté flux: > >> - aucun équipement de filtrage à ce niveau > >> les autres équipements n'interagissent pas avec les 3 serveurs en > >> question, et fonctionnent d'eux même très bien. > >> - Lorsque le problème survient, comme j'avais tenté de l'expliquer, > >> c'est uniquement les connexions entre un serveur web et le serveur > mysql > >> qui font ce "bégaiement" TCP. toutes les autres communications > entrantes > >> et sortantes du serveur web et mysql fonctionnent (ssh sur les 2 > >> serveurs, le http qui marche sur le web sans problème, mysql qui > >> fonctionne sans problème avec l'autre serveur). > >> > > Le fait que tu sois en ssh ne prouve pas le fait qu'il n'y ait pas de pb > > de cnx. ça m'arrive de perdre ma cnx wifi et pourtant ma cnx ssh > > refonctionne souvent le temps que le wifi revienne (parfois ok ça > > déconnecte :) ) > > le mieux c'est de faire un ping TCP à partir de tes serveurs web à > > destination de ton serveur MySQL, avec hping par exemple : > > hping3 [ip] -p 3306 -S > > Quand je parle de connexion SSH, je ne parle pas d'idler sur une > session, je parle de faire mes tests a partir de la session SSH en > question, donc non je suis sur qu'il n'y a aucun problème dessus :) > > Pour tester le TCP, et n'ayant rien d'autre sous la main a ce moment la, > j'ai utilisé telnet 3306 . Même effet, même résultat négatif. > > > > >> - la table arp n'a pas plus de 10 entrées et je controle le réseau > local > >> de bout en bout, donc pas de connexion sauvage ou de conflit d'IP. > >> > > Ne le prend pas mal, tu l'as sûrement fait mais une re-vérif des > configs, > > c'est possible ? (ça arrive à tout le monde et le plus souvent plus > c'est > > gros et moins on le voit :) ) > > J'ai bien sur revérifié tout ca. En fait c'est plutot simple puisque > j'ai simplement à jeter un coup d'oeil dans une interface et a cliquer > :). J'ai aussi vérifié manuellement sur chaque serveur (ca va encore le > pool est petit) > > > d'autant plus que c'est une nouvelle install,... (une piste est une > piste > > c'est tjrs ça de pris) > > Nouvelle install mais même architecture que plusieurs déjà existantes, > c'est ca que j'arrive pas à m'expliquer, et qui me fait penser que le > problème est lié au réseau ou a une bizarerie de ce genre plutôt qu'a un > problème applicatif (pour lequel j'ai tout vérifié) > > > > >> N'ayant aucune piste, j'ai déjà vérifié tous ces élements jusqu'au > trucs > >> les plus absurdes sans rien trouver. > >> > >> J'ajoute que lorsque le problème arrive, un netstat sur le serveur > MySQL > >> montre tout un tas de connexions venant du serveur web en état > >> "SYN_RECV" prouvant bien que le serveur est en train d'attendre que le > >> client accepte la connexion. Le client de son côté a envoyé le SYN > >> initial, recu le ACK du serveur, mais au lieu de répondre, il attend 3 > >> secondes et retransmet le SYN. Simultanément, le meme serveur accepte > >> les connexions de l'autre serveur web sans broncher. > >> > > c'est quoi qui fait les cnx vers le MySQL : du php ? python ? perl ? > > avec le ping tcp (hping), tu devrais voir des pb de cnx en même temps > que > > ton pb. Dans le cas où que le ping TCP ne pose pas de pb, mais que ton > > serv web a du mal à se connecter, il faudra regarder la partie > logicielle > > (config, voir avec les developpeurs de l'appli ...) > > du PHP, mais ce n'est pas ce qui pose le problème. Et les problèmes de > connexion sont effectivement visible en même temps. Mes captures > indiquant la retransmission TCP qui n'a pas lieu d'être de la part du > client prouve que le problème est "dessous" l'applicatif. Mais je ne > suis pas un fainéant, j'ai juste déjà passé 36h sur les points dont tu > parles :) > > > > > 400 req/s : il y a du cache ou à chaque fois tu as des cnx vers le MySQL > ? > > pour voir s'il faut travailler du côté des descripteurs de socket. > > Pour 400 requetes, on peut compter environ 200 connexions effectives au > serveur MySQL (200 sessions TCP quoi). Aucun problème de sockets, pas de > problème de backlog trop court. D'autre part, le serveur à côté fait > dans les 1500 connexions par seconde sans broncher sur _exactement_ la > même configuration matérielle et logicielle. > > J'ai eu le problème à l'instant, et j'ai réussi a raccourcir le temps > d'indisponibilité de 1 minute a en
Re: [FRnOG] Question reseau
Le Mon, Mar 03, 2008 at 02:40:18PM +0100, Youssef Ghorbal [EMAIL PROTECTED] a écrit: > Bonjour, > > J'ai deux equipements reseau a relier (un cisco 3600 et un modem > ADSL) > Le modem ADSL a une interface Fast Ethernet qui fait du 10/100 > Le Cisco a une WIC Ethernet qui ne fait que du 10 Half > > La question est simple, est ce que je dois garder le modem ADSL en > AutoNeg ou est ce que je dois force sa carte a 10 Half (pour > accomoder l'interface du Cisco) Le "défaut", normalement, si l'autoneg échoue, c'est de passer en HD. Pour le link beat à 10M, il devrait a priori se caler dessus. Mais sinon, si le WIC ne sait vraiment fait que du 10/HD, tu ne risques rien en forçant l'autre extremité en 10/HD. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 57, route de Paris 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] problème/enigme TCP qui bégaye
Salut, Tes deux serveurs fonctionne en solo ou il y a une notion de cluster ? Dans les logs du serveurs au rais tu des erreurs ? Un autre truc tout bete tes ports de switchs sont en auto ou configure ? Tes cartes sont en auto ou en full ? Qu' a tu sur tes autres ports ? As tu des pare feu sur tes serveurs ? As tu fais un chagement de conf sur tes serveurs ? Serge CARPENTIER Squale Systems Ingenieur Télécom & Réseau dCAP : DIGIUM Certified Asterisk Professional --- [EMAIL PROTECTED] Support : +33 825 627 431 Tel : +33 674886017 Tel : +33 659455493 --- Powered by BlackBerry & Zimbra -Original Message- From: Gabriel Barazer <[EMAIL PROTECTED]> Date: Mon, 03 Mar 2008 23:38:25 To:Christophe VIAUD <[EMAIL PROTECTED]> Cc:frnog@frnog.org Subject: Re: [FRnOG] problème/enigme TCP qui bég aye Salut, Alors c'est simple, dans le sens premier du terme: - effectivement les 3 serveurs sur le même switch - pas de vlan taggé, un seul global untag - pas sur le switch en question - 1 lien par serveur vers le switch (3 liens total sur un switch qui en a actuellement une quinzaine) - aucune techno software style aggregation ni HA - c'est un nouveau déploiement, mais qui fonctionne sans problèmes sur quelques autres installations du même type (web + mysql) - j'ai le problème depuis 3 jours, et c'est suite à une migration depuis une ancienne infrastructure (qui commencait à montrer des symptomes similaires, je n'ai malheuresement pas pu tester ni faire de captures sur cette ancienne installation) - coté flux: - aucun équipement de filtrage à ce niveau les autres équipements n'interagissent pas avec les 3 serveurs en question, et fonctionnent d'eux même très bien. - Lorsque le problème survient, comme j'avais tenté de l'expliquer, c'est uniquement les connexions entre un serveur web et le serveur mysql qui font ce "bégaiement" TCP. toutes les autres communications entrantes et sortantes du serveur web et mysql fonctionnent (ssh sur les 2 serveurs, le http qui marche sur le web sans problème, mysql qui fonctionne sans problème avec l'autre serveur). - la table arp n'a pas plus de 10 entrées et je controle le réseau local de bout en bout, donc pas de connexion sauvage ou de conflit d'IP. N'ayant aucune piste, j'ai déjà vérifié tous ces élements jusqu'au trucs les plus absurdes sans rien trouver. J'ajoute que lorsque le problème arrive, un netstat sur le serveur MySQL montre tout un tas de connexions venant du serveur web en état "SYN_RECV" prouvant bien que le serveur est en train d'attendre que le client accepte la connexion. Le client de son côté a envoyé le SYN initial, recu le ACK du serveur, mais au lieu de répondre, il attend 3 secondes et retransmet le SYN. Simultanément, le meme serveur accepte les connexions de l'autre serveur web sans broncher. Je n'ai par ailleurs trouvé aucun élement ou serveur qui pourrait expliquer ce déclenchement du problème à intervalles si réguliers. J'avoue que c'est le genre de problème interessant à comprendre mais ca serait bien plus agréable si on me foutait pas autant la pression pour que ca "marche" derrière :) Gabriel On 03/03/2008 11:17:11 PM +0100, "Christophe VIAUD" <[EMAIL PROTECTED]> wrote: > Salut, > > Je ne sais pas si ça intéresse tout le monde de suivre cette discussion, > si cela gêne du monde, merci de nous le faire savoir on continuera en > offline :D > > Pour ton pb, difficile d'en faire l'analyse sans qques infos > complémentaires (pour ne rien perdre au passage et afin que l'on soit au > même niveau d'info que toi ^_^) > > Côté architecture : > - Ton architecture réseau c'est bien les 2 serveurs web et le serveur > mysql sur le même switch ? > - dans le même vlan ? > - du spanning-tree ? > - question bête mais sais t'on jamais : ton serveur MySQL a combien de > lien physique vers ce switch ? fais-tu du teaming, channel bonding ou tout > autre techno d'aggrégation de lien ou de tolérance de panne (lan ha,...) ? > - lié à la question précédente : c'est un nouveau déploiement ? depuis > combien de temps que tu as le pb par rapport à la date de déploiement ? > > Côté flux : > - Pour ce flux tu passes en direct ou par un équipement de filtrage ? > - quels sont les autres équipements (serveurs compris) qui sont dans le > même segment que ton serveur et qui potentiellement pourrait nuir au > trafic ? > - lorsque le pb survient, c'est juste le flux serveur web -> MySQL qui > pose pb ou tu as des pb de connexion vers les serveurs web aussi ? > > as-tu vérifié les tables arp de tes serveurs web et de ton serveur MySQL > lorsque le pb survient ? => je pense à une machine qui a la même ip ou la > même adresse mac et qui pourrait émettre des trames de temps en temps, > provoquant un pb dans la table de forwarding du switch, le temps de la > ré-émission de paquet, ou encore un pb dans la config du teaming ou > channel bonding (p
