Re: [FRnOG] Saturation du lien Neuf = FreeIX ?
Pierre-Yves Maunier a écrit : Radu-Adrian Feurdean wrote: A moins que ca soit OVH. Difficile a savoir si c'est vraiment Free ou ou l'uplink/peering prive d'OVH qui sature. Regardez le mtr : aucune perte de paquet sur la destination : les routeurs intermédiaires forwardent bien l'icmp mais n'y répondent pas forcément ce qui explique les 'packets loss'. Donc aucune perte de paquet en free et ovh. Comme dit dans un précédent mail les routeurs doivent filtrer l'icmp car je suppose qu'ils ont des choses plus importantes à faire que de répondre à ce genre de paquet. Pierre-Yves Maunier Ce qui m'étonne sur ce MTR ( http://forum.paubc.info/images/neuf/SaturationNeufFreeIX.png ), ce ne sont pas les routeurs de Free qui ne répondent pas à 100% des paquets ICMP cause du icmp limit rate, mais le routeur ldcom.FreeIX.net qui répond aux requêtes ICMP entre 1ms et 2245ms (moyenne 33ms). ldcom.FreeIX.net à une IP free (AS 12322) mais je suppose qu'il est géré par Neuf. Le lien n'étant pas saturé (cf intervention de Thierry MAUPOINT), qu'est ce qui génère ce phénomène ? Vivien Guéant. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Saturation du lien Neuf = FreeIX ?
Le 22 sept. 07 à 13:58, Grégoire VILLAIN a écrit : Dans mon esprit, ping etait uniquement utilisable pour savoir di une machine est vivante (sortie host is alive de Solaris), I.e si sa stack ip est montee et routee, toute info supplementaire du ping me semble avoir un credit limite. Du loss sur de l'icmp n'a a priori pas bcp de valeur en troubleshooting puisque c' est pas du trafic courant... Je me trompe ? Dans le cas qui nous interresse ici, seuls les roundtrips et compteurs (crc, runts, giants, i/o errors) des interfaces traversees semblent judicieux a mon sens. Apres c'est discutable, mais c'est mon avis. Tout à fait ... c'est d'ailleurs assez amusant de voir que beaucoup se basent sur ICMP pour savoir si les choses fonctionnent alors que : 1/ il n'y a aucune application utilisée par un utilisateur normal qui fonctionne dans ce mode 2/ un routeur peut être correctement configuré en traitant le moins utile as time permiting et donc si besoin d'arbitrage, ICMP va trinquer ... SI les choses sont bien configurées, bien sûr On va mettre sous supervision ces jolis concerts, via un protocole un peu plus évolué que du ping et on revient vers vous pour en rediscuter si cela intéresse ... (Paul, tu gères ?) - Jean-Michel Planche blog: http://www.jmp.net Chairman and co-founder Witbe web : http://www.witbe.net Follow me http://www.twitter.com/jmplanche --- 2.0 Monitoring : relevant End to End monitoring for critical app. and carrier class services --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Saturation du lien Neuf = FreeIX ?
Bonjour, Attention sur Free Non Dégroupé il y a toujours les problèmes de débits habituels : http://aduf.org/viewforum.php?f=32 Donc faites les test avec des freenautes Dégroupés. Eric Si les freenautes (ou autres) peuvent me confirmer directement si ils streament cette video correctement ca serait trés gentil de leur part. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Saturation du lien Neuf = FreeIX ?
On Sat, 22 Sep 2007 19:33:33 +0200, Jean-Michel Planche [EMAIL PROTECTED] said: Tout à fait ... c'est d'ailleurs assez amusant de voir que beaucoup se basent sur ICMP pour savoir si les choses fonctionnent alors que : 1/ il n'y a aucune application utilisée par un utilisateur normal qui fonctionne dans ce mode 2/ un routeur peut être correctement configuré en traitant le moins utile as time permiting et donc si besoin d'arbitrage, ICMP va trinquer ... SI les choses sont bien configurées, bien sûr 1bis. l'ICMP fait partie de la suite dite TCP/IP, et son suppression donne des effets assez desagreables. continuation sur 2bis. 1ter. Pas mal d'outils de diagnostic reseau sur *nix/*nux utilisent UDP ou meme TCP, au moins dans un sens. traceroute emet de l'UDP par default. 2bis. Un routeur est plutot suppose a router des paquets IP (L3), et s'abstenir a regarder le L4 (TCP, UDP, ICMP ou autre) pour les paquets qui ne lui sont pas addresees. On peut faire autrement pour le traffic a nous, mais c'est assez embetant quand on le fait sur le transit des clients. Ou vu de l'autre cote, quand un upstream decide de re-prioritiser le trafic comme bien lui semble, pas comment ca m'arrange. 3. Pour les paquets qui lui sont addresees, un routeur qui repond avec 2000 ms (2sec) de delai, il a certainement un probleme (configuration ou charge). Un ICMP rate-limit est un assez bon facon de masquer (mais pas d'eliminer) le probleme. -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Saturation du lien Neuf = FreeIX ?
Le Sun, 23 Sep 2007 02:05:09 +0200, Wlodek Stankiewicz [EMAIL PROTECTED] a écrit : Salut, Je suis chez Free, ping est parfait mai le vidéo Médicis-Art marche pas . Bong, il est tôt ou tard mais selon les opinons : - vous aurez *AUCUNES* mesures fiables de quoi que ce soit entre vous en vous soumettant à la QoS qu'un FAI (free.fr, proxad.net pour prendre un exemple ou autres, aucune importance). - Pour faire un poil plus technique (suis admin sys pas réseau) : soit vous avez accès aux métriques des matériels des FAIs grand public entre vous et le POP (NRA ou autres) soit non (majorité des cas) et alors soit vous avez un réelle point de balance (ou nan) qui peut influer sur le cours du fil de discussion : 1) soit vos métriques sont un poil corroborées par celles d'un FAI X ou Y ... (dans la mesure ou celui çi vous donne accès à système de métrique en toute liberté) 2) soit non (et alors c'est pas la peine de me sortir que je participe à un projet qui se soumet à le QoS des FAIs, je le sais déjà), et donc SVP sortez moi vous admins réseau un système de métriques qui soit compréhensible par le grand public, et non soumis aux libertés des marchands de l'information ! a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgp3I04JbUKoi.pgp Description: PGP signature
