Re: [FRnOG] [TECH] Pertes et latence importantes
On 4 Jan 2012, at 03:36, Michel Py wrote: >>> C'est pas évident de faire du QOS à l'intérieur du tunnel. >>> Petit retour en arrière (IOS): expliques-moi pourquoi il faut >>> mettre la crypto-map ET sur l'interface physique ET dans le >>> tunnel? Ça défie la logique. > >> Pardon ? > > Euh oui c'était vague. Je faisais la relation avec le chiffrage du tunnel. > (je passe toute la config crypto, une usine à gaz) Dans ce cas, il n'y a pas vraiment besoin de chiffrer un tunnel GRE/L2TP/IPIP fait l'affaire. Mais je suis d'accord que ce ne va pas forcement améliorer les choses. Le seul cas ou ca peut vraiment faire une différence est si tu as besoin de faire du load balancing par paquet et non par flow. Et la encore c'est un configuration qui risque d'avoir des problemes si les deux lignes ont des differences (different round-trip, ...) C'est surtout utile si tu a une IP derrière l'ADSL qui a besoin de plus d'upload qu'une seule ligne peut fournir. Pour le lecteur curieux, la config ressemble a ca : interface Tunnel1 description "Premier Tunnel" bandwidth 512 ip address 82.219.xxx.xxx 255.255.255.252 ip mtu 1436 ip load-sharing per-packet ip tcp adjust-mss 1436 keepalive 3 3 tunnel source 82.219.yyy.yyy tunnel destination 82.219.zzz.zzz tunnel path-mtu-discovery ! interface Tunnel2 description "Deuxieme Tunnel" bandwidth 512 ip address 82.219.xxx.xxx 255.255.255.252 ip mtu 1436 ip load-sharing per-packet ip tcp adjust-mss 1436 keepalive 3 3 tunnel source 82.219.yyy.yyy tunnel destination 82.219.zzz.zzz tunnel path-mtu-discovery ! (Des deux cotes : routeur DSL et routeur du "bon" cote de l'ADSL) Pour le routeur internet ip route 82.219.aaa.bbb 255.255.255.248 Tunnel1 ip route 82.219.aaa.bbb 255.255.255.248 Tunnel1 Du cote DSL tu peux meme mettre un tracker : ip route 0.0.0.0 0.0.0.0 Tunnel1 track 1 ip route 0.0.0.0 0.0.0.0 Tunnel1 track 2 track 1 interface Dialer1 ip routing track 1 interface Dialer2 ip routing avec Dialier1 et Dialer2 les interface Dialer DSL pour les deux lignes. Pour le cas de Gregoire "per packet" n'est pas la solution. > C'est pour ça que je disais qu'il fallait mettre l'interface xDSL dans le > routeur. CQFD. Nous sommes totalement d'accord. CQFD c'est que la bidouille ne marche jamais a 100% et que ce soit MPPP DSL, tunneling, QOS ou autre chose il n'y a pas de solution magique pas chere :p > La même crypto-map sur l'interface physique et sur l'interface tunnel. Il n'y > a pas de logique. La logique voudrait que soit tu chiffres soit d'IP à IP sur > l'interface physique, soit le tunnel entier sur l'interface tunnel. En plus > quand tu regardes la crypto-map et l'access-list associée tu trouves que des > adresses publiques, et pourtant si tu ne mets la crypto-map que sur f0/0 ou > que sur tu0 ça ne marche pas. Je n'ai jamais joue avec les crypto-map - je ne fais pas les config VPN (ou meme clients), je suis chanceux d'avoir des gens a qui ca pourri la vie a la place de la mienne :D > Même idée pour faire du QOS à l'intérieur du tunnel. Ton service-policy > output machin, tu le mets sur f0/0 ou sur tu0 ou les deux? Dans le cas ci-dessus le QOS va dans l'interface Tunnel. Tu peux assumer que la ligne ne sera pas utilise autrement et cela sera vrai la plupart du temps. > Malheureusement, une interface tunnel ça ne réagit pas toujours comme une > vraie Nous sommes d'accord :( Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Pertes et latence importantes
>> Michel Py a écrit: >> mais encore une fois, explique moi comment tu fais le >> flow-control entre le routeur et le modem externe? > Thomas Mangin a écrit: > Aucune idée. C'est pour ça que je disais qu'il fallait mettre l'interface xDSL dans le routeur. CQFD. >>> Je me demande même si un tunnel GRE/L2TP avec un machine cote >>> internet ce n'est pas mieux que rien. Il faudrait faire les test. >> C'est pas évident de faire du QOS à l'intérieur du tunnel. >> Petit retour en arrière (IOS): expliques-moi pourquoi il faut >> mettre la crypto-map ET sur l'interface physique ET dans le >> tunnel? Ça défie la logique. > Pardon ? Euh oui c'était vague. Je faisais la relation avec le chiffrage du tunnel. En IOS, il faut configurer: (je passe toute la config crypto, une usine à gaz) interface f0/0 ip add publique1 crypto-map machin interface tunnel 0 ip add 192.168.x.1 255.255.255.0 (au diable l'avarice) tu sou f0/0 tu dest publique2 crypto-map machin La même crypto-map sur l'interface physique et sur l'interface tunnel. Il n'y a pas de logique. La logique voudrait que soit tu chiffres soit d'IP à IP sur l'interface physique, soit le tunnel entier sur l'interface tunnel. En plus quand tu regardes la crypto-map et l'access-list associée tu trouves que des adresses publiques, et pourtant si tu ne mets la crypto-map que sur f0/0 ou que sur tu0 ça ne marche pas. Alors que il y a des trucs qui marchent logiquement, comme "tunnel key" (ça ne chiffre pas, ceci dit); tu configures sous l'interface tunnel, c'est plus naturel. Même idée pour faire du QOS à l'intérieur du tunnel. Ton service-policy output machin, tu le mets sur f0/0 ou sur tu0 ou les deux? Malheureusement, une interface tunnel ça ne réagit pas toujours comme une vraie Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
2012/1/3 Pierre Emeriaud : > Le 3 janvier 2012 09:02, Fabien VINCENT a écrit : >> >> Je pense que tu n'as pas tout lu, le NRA TRIOLO est full selon FT (Orange >> now), on a déjà mis un an pour avoir une deuxième ADSL (dé numéroté d'un >> autre NRA à l'époque), et deux ans pour avoir la SDSL ... >> > > visiblement TRI59 est dégroupé par OVH. > > => ils se sont installés dans les derniers, donc il restait de la > place au niveau equipements (donc le NRA n'est pas "full"). > => s'il n'y avait plus de place en transport pour connecter les > abonnés, ils n'auraient pas installés de dslam. > > A revoir avec FT ou ovh, mais il doit y avoir de la dispo. > > > -pierre. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ Je doute fortement que le NRA soit FULL en terme de place ou équipements (cf explication de Pierre). Le plus probable selon moi étant que le/les câbles de distribution (voir le transport arrivant du NRA vers le SR) qui alimente votre quartier,rue soit full. Et là effectivement, si il n'y a plus de cuivre dispo, tu peux attendre longtemps avant que FT finance l'extension en capa cuivre du quartier/rue (passage d'un X paires supplémentaire) surtout si c'est que pour la création d'une ligne .. My 2cts Pierre-yves --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
Le 3 janvier 2012 09:02, Fabien VINCENT a écrit : > > Je pense que tu n'as pas tout lu, le NRA TRIOLO est full selon FT (Orange > now), on a déjà mis un an pour avoir une deuxième ADSL (dé numéroté d'un > autre NRA à l'époque), et deux ans pour avoir la SDSL ... > visiblement TRI59 est dégroupé par OVH. => ils se sont installés dans les derniers, donc il restait de la place au niveau equipements (donc le NRA n'est pas "full"). => s'il n'y avait plus de place en transport pour connecter les abonnés, ils n'auraient pas installés de dslam. A revoir avec FT ou ovh, mais il doit y avoir de la dispo. -pierre. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
>> Une fois que le routeur a commencer a envoyer un gros packet de >> données, tu ne peux rien faire mais attendre pour qu'il soit sorti. > > Non. Correction: une fois que l'interface de sortie du lien faible a commencé > à envoyer un gros paquet tu ne peux rien faire que d'attendre qu'il soit > sorti. Dans le contexte du fil, c'est le modem qui envoie le paquet, pas le > routeur. C'est ce que je voulais dire :) >> C'est pour cela que pour 2Mb utiliser une interface 100 Mb limite >> a 2 Mb c'est mieux qu'une interface 10 Mb limite a 2 car le temps >> de serialisation/transfer est plus cours. > > Pas du tout d'accord. Non seulement ça ne change rien (une fois que ta > sérialisation rapide arrive dans le modem, c'est re-sérialisé à 2Mb et ça > change absolument rien au résultat de l'autre coté), mais en plus c'est > dangereux. Relis le contexte: on parlait des avantages d'avoir l'interface > physique directement dans une WIC au lieu d'avoir un modem externe en > 100-base TX. Ce que disait Jean-Michel est important: Je parlais du cas général ou la ligne est de 2 ou 10 Mb, pas du cas de l'ADSL avec une modem connecte via ethernet. Dans ce cas, une ligne plus rapide va causer plus de micro-burst et donc plus de packet loss a cause de l'exhaustion des buffers si il n'y a pas de QOS en sortie. >>> Scénario 1: >>> La mémoire tampon du modem est de 200KB, le 2ème paquet de >>> voix est reçu et stocké, mais maintenant il y a 120 paquets >>> de données avant lui dans la queue et il vient de se prendre >>> 978 ms de jitter dans la gueule. > >> Non, une seule frame devrait sortir du routeur avant que le >> packet de voip suivant sorte. Donc le temps maximum, c'est >> le temps qu'il faut pour transmettre un MTU de 1.5k donc 6ms >> pour une ligne 2Mb. > > Non. Seulement quand tu contrôles l'interface de la ligne lente, ce que tu ne > fais pas quand le modem est externe. Nous sommes d'accord. Encore une fois nous ne parlions pas de la meme chose. > Relis ce que j'ai écrit: il est ou le flow-control entre le modem et le > routeur? A t+6ms le routeur n'a pas encore reçu le prochain paquet de voix (1 > toutes les 20ms) et donc il continue à envoyer les données. Il n'était pas clair pour moi que dans l'exemple la ligne la plus lente n'etait pas connecte au routeur. >> Flow-control et QOS sont complementaire, tu veux les deux. > > Oui, mais encore une fois, explique moi comment tu fais le flow-control entre > le routeur et le modem externe? Aucune idée. >> Je me demande même si un tunnel GRE/L2TP avec un machine cote >> internet ce n'est pas mieux que rien. Il faudrait faire les test. > > Pas dans mon expérience. Merci :) > C'est pas évident de faire du QOS à l'intérieur du tunnel. Petit retour en > arrière (IOS): expliques-moi pourquoi il faut mettre la crypto-map ET sur > l'interface physique ET dans le tunnel? Ça défie la logique. Pardon ? Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
2012/1/3 Guillaume Barrot > Surtout qu'en relisant le mail d'origine, depuis Lille, trouver une Sdsl et > plusieurs Adsl pas cheres devrait pas etre trop dur. > > Mon petit doigt me dit qu'a Roubais se trouve une solution qui pourrait en > plus fournir la passerelle ToIP pour le Sip trunking ... > Je pense que tu n'as pas tout lu, le NRA TRIOLO est full selon FT (Orange now), on a déjà mis un an pour avoir une deuxième ADSL (dé numéroté d'un autre NRA à l'époque), et deux ans pour avoir la SDSL ... Enfin, bon merci quand même à ceux qui nous ont aider à comprendre le pb, dont le postulat de base est 2 ADSL et 1 SDSL ... Ca sert à rien de vouloir nous vendre quoique ce soit, ou de nous rajouter d'hypothétique lignes pour contourner le pb de QoS, les résidents veulent pas payer, et le CA freine des 2 pieds pour un autre fournisseur que Orange/FT (Ecole fondée en partie par l'opérateur canal historique :). Si on avait pu le faire, je vous assure à tous ici qu'on l'aurait déjà fait ! > Le 3 janv. 2012 08:22, "Guillaume Barrot" a > écrit : > > > > > > > Finallement, tout ca pour dire : utiliser une ligne pour la > > > > VOIP/autres services temps reels et une autre pour les données > > > > ca simplifie la vie :p > > > > > > Aucun doute, mais ça coûte plus cher :P > > > > > > Michel. > > > > Pas fondamentalement. > > Une Sdsl a 2mb, je laisse les specialistes de l'Erlang nous refaire le > > calcul, mais en G711 ca fait deja un paquet de com... > > Un NodeB mobile commence avec un E1 a 2Mb en backhaul et ca fonctionne. > Et > > dans notre cas il y a deja une Sdsl donc ca coute pas plus cher de > > l'utiliser pour ca ! > > > > Dans le contexte, tu montes un asteriks local avec la Sdsl au cul pour y > > placer le trunk sip + rtp a destination de ton fournisseur de ToIP > prefere, > > et tu stackes les ADSL pour la data. > > On est pas dans un contexte hebergeur donc on peut parier que la Data > sera > > asymetrique. > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Pertes et latence importantes
Surtout qu'en relisant le mail d'origine, depuis Lille, trouver une Sdsl et plusieurs Adsl pas cheres devrait pas etre trop dur. Mon petit doigt me dit qu'a Roubais se trouve une solution qui pourrait en plus fournir la passerelle ToIP pour le Sip trunking ... Le 3 janv. 2012 08:22, "Guillaume Barrot" a écrit : > > > > Finallement, tout ca pour dire : utiliser une ligne pour la > > > VOIP/autres services temps reels et une autre pour les données > > > ca simplifie la vie :p > > > > Aucun doute, mais ça coûte plus cher :P > > > > Michel. > > Pas fondamentalement. > Une Sdsl a 2mb, je laisse les specialistes de l'Erlang nous refaire le > calcul, mais en G711 ca fait deja un paquet de com... > Un NodeB mobile commence avec un E1 a 2Mb en backhaul et ca fonctionne. Et > dans notre cas il y a deja une Sdsl donc ca coute pas plus cher de > l'utiliser pour ca ! > > Dans le contexte, tu montes un asteriks local avec la Sdsl au cul pour y > placer le trunk sip + rtp a destination de ton fournisseur de ToIP prefere, > et tu stackes les ADSL pour la data. > On est pas dans un contexte hebergeur donc on peut parier que la Data sera > asymetrique. > --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Pertes et latence importantes
> > Finallement, tout ca pour dire : utiliser une ligne pour la > > VOIP/autres services temps reels et une autre pour les données > > ca simplifie la vie :p > > Aucun doute, mais ça coûte plus cher :P > > Michel. Pas fondamentalement. Une Sdsl a 2mb, je laisse les specialistes de l'Erlang nous refaire le calcul, mais en G711 ca fait deja un paquet de com... Un NodeB mobile commence avec un E1 a 2Mb en backhaul et ca fonctionne. Et dans notre cas il y a deja une Sdsl donc ca coute pas plus cher de l'utiliser pour ca ! Dans le contexte, tu montes un asteriks local avec la Sdsl au cul pour y placer le trunk sip + rtp a destination de ton fournisseur de ToIP prefere, et tu stackes les ADSL pour la data. On est pas dans un contexte hebergeur donc on peut parier que la Data sera asymetrique. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Pertes et latence importantes
>>> Thomas Mangin a écrit: >>> Tant qu'il y a un shaper par modem, le QOS peut faire son travail >>> car le routeur sait quand ralentir le trafic pour chaque ligne. >> Michel Py a écrit: >> Mouais là je voudrais bien des détails. > Une fois que le routeur a commencer a envoyer un gros packet de > données, tu ne peux rien faire mais attendre pour qu'il soit sorti. Non. Correction: une fois que l'interface de sortie du lien faible a commencé à envoyer un gros paquet tu ne peux rien faire que d'attendre qu'il soit sorti. Dans le contexte du fil, c'est le modem qui envoie le paquet, pas le routeur. > C'est pour cela que pour 2Mb utiliser une interface 100 Mb limite > a 2 Mb c'est mieux qu'une interface 10 Mb limite a 2 car le temps > de serialisation/transfer est plus cours. Pas du tout d'accord. Non seulement ça ne change rien (une fois que ta sérialisation rapide arrive dans le modem, c'est re-sérialisé à 2Mb et ça change absolument rien au résultat de l'autre coté), mais en plus c'est dangereux. Relis le contexte: on parlait des avantages d'avoir l'interface physique directement dans une WIC au lieu d'avoir un modem externe en 100-base TX. Ce que disait Jean-Michel est important: > Jean-Michel DILLY a écrit: > Michel, ta remarque s'applique-t-elle lorsqu'on a mis en place > un SHAPING en sortie sur l'interface externe du routeur ? Cela > permettant de ramener le goulot d'étranglement sur le routeur > et non le modem...? Oui et encore oui. Ramener le goulot d'étranglement dans le routeur ou tous les types de mémoire tampon peuvent (éventuellement) être contrôlés est important. >> Scénario 1: >> La mémoire tampon du modem est de 200KB, le 2ème paquet de >> voix est reçu et stocké, mais maintenant il y a 120 paquets >> de données avant lui dans la queue et il vient de se prendre >> 978 ms de jitter dans la gueule. > Non, une seule frame devrait sortir du routeur avant que le > packet de voip suivant sorte. Donc le temps maximum, c'est > le temps qu'il faut pour transmettre un MTU de 1.5k donc 6ms > pour une ligne 2Mb. Non. Seulement quand tu contrôles l'interface de la ligne lente, ce que tu ne fais pas quand le modem est externe. Relis ce que j'ai écrit: il est ou le flow-control entre le modem et le routeur? A t+6ms le routeur n'a pas encore reçu le prochain paquet de voix (1 toutes les 20ms) et donc il continue à envoyer les données. > Je ne parle que des frames sortantes, pour les frames > entrante (depuis l' ADSL) tu prends ce qui arrive et oui > ca peut etre le cas si il n'y a pas de QOS. Pas de désagrément ici; pour faire du QOS qui marche, il faut contrôler les deux cotés de la ligne lente, ce qui en pratique veut dire il faut être le FAI. >> Scénario 2: la mémoire tampon du modem est de 100KB, le 2ème >> paquet de voix est perdu tout comme les derniers 100KB de >> données, et à t+ 500 ms le modem s'est arrêté d'envoyer des >> donnés car sa mémoire tampon était vide et que le QOS dans le >> routeur attend l'ouverture de la prochaine fenêtre à t+ 1000 ms. >> Non seulement le paquet de voix est perdu mais la bande >> passante en sortie a diminué de moitié. > Assumes-tu une seule queue QOS Non. Relis l'exemple, une queue par type de trafic. >> 2. Pas moyen de contrôler la taille de la mémoire tampon >> dans le modem. Et même si on pouvait, ça ne servirait à >> rien tant qu'on n'a pas de flow-control. > Flow-control et QOS sont complementaire, tu veux les deux. Oui, mais encore une fois, explique moi comment tu fais le flow-control entre le routeur et le modem externe? Sur un bon vieux modem des familles t'avais DSR/DTR et CTS/RTS mais en 100-base TX FD le circuit de collision existe même plus (c'est plus du CSMA/CD). Des liens? > Il faut pouvoir appliquer le QOS des _DEUX_ cotes de la ligne lente .. Oui, oui çà on avait compris. > Je me demande même si un tunnel GRE/L2TP avec un machine cote > internet ce n'est pas mieux que rien. Il faudrait faire les test. Pas dans mon expérience. C'est pas évident de faire du QOS à l'intérieur du tunnel. Petit retour en arrière (IOS): expliques-moi pourquoi il faut mettre la crypto-map ET sur l'interface physique ET dans le tunnel? Ça défie la logique. > Finallement, tout ca pour dire : utiliser une ligne pour la > VOIP/autres services temps reels et une autre pour les données > ca simplifie la vie :p Aucun doute, mais ça coûte plus cher :P Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
>> Tant qu'il y a un shaper par modem, le QOS peut faire son travail >> car le routeur sait quand ralentir le trafic pour chaque ligne. > > Mouais là je voudrais bien des détails. Une fois que le routeur a commencer a envoyer un gros packet de données, tu ne peux rien faire mais attendre pour qu'il soit sorti. C'est pour cela que pour 2Mb utiliser une interface 100 Mb limite a 2 Mb c'est mieux qu'une interface 10 Mb limite a 2 car le temps de serialisation/transfer est plus cours. > Scénario 1: > La mémoire tampon du modem est de 200KB, le 2ème paquet de voix est reçu et > stocké, mais maintenant il y a 120 paquets de données avant lui dans la queue > et il vient de se prendre 978 ms de jitter dans la gueule. Non, une seule frame devrait sortir du routeur avant que le packet de voip suivant sorte. Donc le temps maximum, c'est le temps qu'il faut pour transmettre un MTU de 1.5k donc 6ms pour une ligne 2Mb. Je ne parle que des frames sortantes, pour les frames entrante (depuis l' ADSL) tu prends ce qui arrive et oui ca peut etre le cas si il n'y a pas de QOS. Pour le download, 1500 bytes a 2Mbps, c'est 6ms de temps de serialisation, en upload 1500 bytes a 250kbps c'est 48ms ... still argh ! > Scénario 2: la mémoire tampon du modem est de 100KB, le 2ème paquet de voix > est perdu tout comme les derniers 100KB de données, et à t+ 500 ms le modem > s'est arrêté d'envoyer des donnés car sa mémoire tampon était vide et que le > QOS dans le routeur attend l'ouverture de la prochaine fenêtre à t+ 1000 ms. > Non seulement le paquet de voix est perdu mais la bande passante en sortie a > diminué de moitié. Assumes-tu une seule queue QOS, si c'est le cas, il faut une queue par type de trafic. Il y a le FIFO de l'interface et le buffer par le type de trafic defini. Mais en effet si les valeurs sont mauvaises tu peux effectivement te retrouver avec des buffer underflow facilement. > 2. Pas moyen de contrôler la taille de la mémoire tampon dans le modem. Et > même si on pouvait, ça ne servirait à rien tant qu'on n'a pas de flow-control. Flow-control et QOS sont complementaire, tu veux les deux. Et tu veux du flow-control de point a point et de "end to end". De gros buffers sur les routeurs sans QOS cassent le flow-control end-to-end (Bufferbloat). > Donc, pour que le QOS en sortie marche avec un modem externe Ethernet, il > faut résoudre ces 4 problèmes, ou partie et trouver le config qui marche. Il faut pouvoir appliquer le QOS des _DEUX_ cotes de la ligne lente .. Je me demande même si un tunnel GRE/L2TP avec un machine cote internet ce n'est pas mieux que rien. Il faudrait faire les test. Un autre devoir ... > Voici vos devoirs: Desole c'est mes vacances, je passe :P Mon collègue Richard a fait une tres bonne presentation sur le QOS, j'en ai une copie publique. http://thomas.mangin.com/data/pdf/Linx%2065%20-%20Halfpenny%20-%20VOIP%20QOS.pdf Cela couvre le cas d'une ligne spécialisé car pour l'ADSL la présentation aurait été deux fois plus longue. Un exemple de configuration cisco a la fin. Finallement, tout ca pour dire : utiliser une ligne pour la VOIP/autres services temps reels et une autre pour les données ca simplifie la vie :p Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Pertes et latence importantes
> Jean-Michel DILLY a écrit: > Michel, ta remarque s'applique-t-elle lorsqu'on a mis en place > un SHAPING en sortie sur l'interface externe du routeur ? Cela > permettant de ramener le goulot d'étranglement sur le routeur > et non le modem...? Correct. Shaper en entrée, ça ne sert pratiquement à rien sauf quand on utilise WRED, et WRED ne marche relativement bien qu'avec TCP, pas UDP. Pour la partie de ramener le goulot d'étranglement c'est correct aussi, voir plus bas. > Thomas Mangin a écrit: > Un shaper global est assez inutile car la distribution des flows > entre les lignes ne sera jamais parfaite. Je suis d'accord. Je ne parlais pas d'un shaper global; mais lire plus bas. > Il faut aussi resister a la tentation d'utiliser de gros buffers > sur le routeur, en pensant que cela va aider les perfs. D'accord aussi. > Ceci dit, comme les caractéristiques de la ligne DSL peuvent > changer, il faut s'assurer que la configuration du routeur soit > aligne avec la condition de la ligne physique (ma ligne DSL > personnelle est mauvaise quand il pleut, bonne autrement, > par exemple). C'est précisément un des cas ou avoir l'interface physique dans le routeur est avantageuse. > Tant qu'il y a un shaper par modem, le QOS peut faire son travail > car le routeur sait quand ralentir le trafic pour chaque ligne. Mouais là je voudrais bien des détails. Hypothèse: (disclaimer: certaines mesures arrondies (du genre: 1 octet = 10 bits avec encapsulation)). Dans la réalité c'est un peu différent, mais pour l'exemple c'est suffisant. QOS simple: routeur avec 2 interfaces Ethernet (réseau interne / modem externe) 2 queues, une pour les données et l'autre pour la voix. 1 flux de voix, 1 paquet de voix de 218 octets tous les 20ms. 1 client torrent non cappé qui seede plusieurs pairs. QOS limitant la capa à 2mbps, soit 200KB/s. SDSL 2mbps réel (on enlève l'inconnue de la pluie et on considère que la limite du QOS est inférieure à la capa réellement disponible). Capa QOS mesurée 1 fois par seconde. Politique de QOS nazi, priorité absolue à la voix. Routeur connecté au modem à 100Mbps FD. Le mémoire tampon du modem (quelle que soit sa taille) ne connait pas QOS est FIFO. Si elle est pleine les paquets entrants sont jetés. Instant t: Routeur: La queue voix contient 1 paquet de 218 octets; la queue données est constamment remplie de paquets de 1.5 KB quelle que soit sa taille. La fenêtre de mesure du QOS vient de démarrer. Modem: au point mort. Du point de vue du routeur: t+ 0.1 ms : le paquet voix est sorti de l'Ethernet. t+ 0.1 ms : comme la queue voix est vide le routeur commence à vider la queue données. t+ 19.9 ms : en 19.9 ms, environ 190KB de données sont sortis de l'Ethernet vers le modem. t+ 20.0 ms : le 2ème paquet voix arrive. t+ 20.0 ms : le 2ème paquet voix est le suivant qui va être envoyé au modem, même si il y a des paquets dans la queue des données. t+ 20.1 ms : le prochain paquet données arrive et il fait basculer la limite de capa; plus de données envoyées au modem pour 979.9 ms. Situation dans le modem: t+ 0.0 ms : la mémoire tampon est vide (je suis pas vache) t+ 0.1 ms : le 1er paquet de voix arrive. t+ 0.2 ms : le paquet de voix est envoyé. Il y a déjà un paquet de données reçu, il commence à partir. t+ 0.9 ms : le premier paquet de données est envoyé. Maintenant, il y a 6 paquets de données en mémoire. t+ 20.1 ms : le 2ème paquet de voix arrive. Scénario 1: La mémoire tampon du modem est de 200KB, le 2ème paquet de voix est reçu et stocké, mais maintenant il y a 120 paquets de données avant lui dans la queue et il vient de se prendre 978 ms de jitter dans la gueule. Scénario 2: la mémoire tampon du modem est de 100KB, le 2ème paquet de voix est perdu tout comme les derniers 100KB de données, et à t+ 500 ms le modem s'est arrêté d'envoyer des donnés car sa mémoire tampon était vide et que le QOS dans le routeur attend l'ouverture de la prochaine fenêtre à t+ 1000 ms. Non seulement le paquet de voix est perdu mais la bande passante en sortie a diminué de moitié. Bon, ça c'est le scénario catastrophe, mais finalement assez courant. En analysant la situation, on trouve 4 problèmes: 1. Il n'y a pas de flow-control entre le modem et le routeur. 2. Pas moyen de contrôler la taille de la mémoire tampon dans le modem. Et même si on pouvait, ça ne servirait à rien tant qu'on n'a pas de flow-control. 3. La fenêtre de mesure de capa dans le QOS du routeur qui est de 1 seconde est trop longue. Ceci dit, si on ne résout pas le problème d'ajuster la mémoire tampon dans le modem... 4. Le modem ne fait pas de QOS. Donc, pour que le QOS en sortie marche avec un modem externe Ethernet, il faut résoudre ces 4 problèmes, ou partie et trouver le config qui marche. Voici vos devoirs: Poster des liens techniques expliquant comment: - Avoir du flow-control en
Re: [FRnOG] [TECH] Pertes et latence importantes
On 29 Dec 2011, at 09:21, Jean-Michel DILLY wrote: > Michel, ta remarque s'applique-t-elle lorsqu'on a mis en place un SHAPING en > sortie sur l'interface externe du routeur ? Cela permettant de ramener le > goulot d'étranglement sur le routeur et non le modem...? Tant qu'il y a un shaper par modem, le QOS peut faire son travail car le routeur sait quand ralentir le trafic pour chaque ligne. Un shaper global est assez inutile car la distribution des flows entre les lignes ne sera jamais parfaite. Ceci dit, comme les caractéristiques de la ligne DSL peuvent changer, il faut s'assurer que la configuration du routeur soit aligne avec la condition de la ligne physique (ma ligne DSL personnelle est mauvaise quand il pleut, bonne autrement, par exemple). Il faut aussi resister a la tentation d'utiliser de gros buffers sur le routeur, en pensant que cela va aider les perfs. http://www.bufferbloat.net/ Si quelqu'un a une experience avec du caching P2P, je suis preneur http://stargate.cnl.tuke.sk/~klimek/P2P_proxy_cache_projekt.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Pertes et latence importantes
Bonjour, Michel, ta remarque s'applique-t-elle lorsqu'on a mis en place un SHAPING en sortie sur l'interface externe du routeur ? Cela permettant de ramener le goulot d'étranglement sur le routeur et non le modem...? JMichel -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Michel Py Envoyé : jeudi 29 décembre 2011 05:25 À : Grégoire Leroy; frnog@frnog.org Objet : RE: [FRnOG] [TECH] Pertes et latence importantes > Grégoire Leroy a écrit: > [QOS] En plus des excellentes contribs (comme d'habitude) de Thomas, Jérôme et Radu, j'ajouterais ceci: dans ton cas, je pense qu'il y a une variable de plus qui va rendre tes tentatives de QOS pratiquement caduques. Si je devine correctement ta configuration, tu as un routeur qui se connecte par Ethernet à tes modems aDSL/SDSL (si je devine incorrectement, ne pas lire plus bas) Si c'est le cas, il y a un ennui considérable avec ce genre de configuration: les modems ont une mémoire tampon, l'algorithme et la taille de celle-ci sont inconnus et non-modifiables, et ça va rendre ton QOS en sortie fou, car les modems vont accepter les paquets à 10 ou à 100 Mbs, les mettre en mémoire, et décider on ne sait trop quoi quand le tampon est plein. Note que je ne te conseille pas d'y perdre de temps, mais si tu as envie de te brûler les doigts il faut se débarrasser des modems externes et avoir les cartes dans le routeur. Un exemple de matos d'occasion pas cher serait un 3640, une WIC-1SHDSL et deux WIC-1ADSL plus le/les NM Ethernet. En faisant ça tu éliminerais la mémoire tampon incontrôlable des modems externes et tu travaillerais directement au niveau ATM sur le routeur. Ceci ne s'applique qu'au trafic sortant, et si tu n'as pas la même chose dans l'autre sens ça ne sert pas à grand-chose, comme dit bien des fois. Mais bon si t'as envie de bidouiller Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Pertes et latence importantes
> Grégoire Leroy a écrit: > [QOS] En plus des excellentes contribs (comme d'habitude) de Thomas, Jérôme et Radu, j'ajouterais ceci: dans ton cas, je pense qu'il y a une variable de plus qui va rendre tes tentatives de QOS pratiquement caduques. Si je devine correctement ta configuration, tu as un routeur qui se connecte par Ethernet à tes modems aDSL/SDSL (si je devine incorrectement, ne pas lire plus bas) Si c'est le cas, il y a un ennui considérable avec ce genre de configuration: les modems ont une mémoire tampon, l'algorithme et la taille de celle-ci sont inconnus et non-modifiables, et ça va rendre ton QOS en sortie fou, car les modems vont accepter les paquets à 10 ou à 100 Mbs, les mettre en mémoire, et décider on ne sait trop quoi quand le tampon est plein. Note que je ne te conseille pas d'y perdre de temps, mais si tu as envie de te brûler les doigts il faut se débarrasser des modems externes et avoir les cartes dans le routeur. Un exemple de matos d'occasion pas cher serait un 3640, une WIC-1SHDSL et deux WIC-1ADSL plus le/les NM Ethernet. En faisant ça tu éliminerais la mémoire tampon incontrôlable des modems externes et tu travaillerais directement au niveau ATM sur le routeur. Ceci ne s'applique qu'au trafic sortant, et si tu n'as pas la même chose dans l'autre sens ça ne sert pas à grand-chose, comme dit bien des fois. Mais bon si t'as envie de bidouiller Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
Le mercredi 28 décembre 2011 à 18:00 +0100, Fabien VINCENT a écrit : > On est pas cons non plus, juste on essaye de trouver une solution à un > pb > donné (c'est moi qui ait conseillé à Grégoire de contacter FrNOG, en > me > disant qu'une bonne ame aurait peut être une idée du peu de qualité de > la > SDSL, pas de pourquoi on ne peut pas prendre de nouvelles lignes un > nouvel > opérateur et autres solutions liées à un qqconque changement). > > Mon POP est à 500m (vous le savez...On parle d'offre à 100 EUR ht /mois pour 10 Mbps symétrique) mais si vous êtes mariés, un conseil, ne courtisez pas ailleurs. ++ -- Maxence Rousseau mrouss...@ate.info ATE - Avenir télématique http://www.ate.info +33(0)3.28.800.300 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
On 28 Dec 2011, at 18:18, Fabien VINCENT wrote: > > >> Ah !! Et moi qui croyais que tu voulais faire de la magie noire :D > >> Augmenter un peu les prix pour financer le service ? > >> > > > > On a essayé en demandant aux résidents => échec > > > > Abordons le problème autrement. > > La sDSL est là pour répondre à quel besoin, qui n'est à priori pas > satisfait par les aDSL ? > > C'était plus en terme de nombre de connexions que nous voulions avancer > (+ToIP pour l'admin de la résidence, ce qui as fait qu'ils ont pris un truc > mousse mousse pro, mais qui n'est pas plus satisfaisant qu'un ADSL bien > blindé). > Définis ton besoin en terme de "nombre de connexions". Est-ce qu'il s'agit de flux qui pourraient être concentrés sur un forward proxy ? Tu pourrais avoir une approche qui serait de faire passer le browsing + mail + p2p sur les aDSL, et la voip sur sDSL. Je déconseille de faire passer le ssh dans la sDSL, les scp de 8gb vont violer ta ligne. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
Le Wednesday 28 December 2011 21:41:55, Radu-Adrian Feurdean a écrit : > On Wed, 28 Dec 2011 15:06:02 +0100, "Grégoire Leroy" > > said: > > La QoS est effectuée par résident (ip source en upload, ip de destination > > en download) et est faite des deux côtés. Si on peut réguler le trafic > > en sortie de l'interface externe, on peut aussi le réguler en sortie de > > l'interface interne non ? > > Ok, tu peux le faire, mais ca ne sert pas a grand chose : ton tuyau peut > etre deja sature avant que ca arrive chez toi. > Normalement, le Qos est effectif quand il est mis avant l'entree dans le > tuyau le plus petit. Dans ton cas c'est en uplink. Pour le downlink, il > faudra que c'est ton FAI qui le fait, mais ils doivent avoir d'autres > choses au program. Effectivement, c'était probablement ça : le trafic effectif dépasse allègrement la limite imposée à la QoS. Cette limite joue, mais elle est dépassée d'environ 30%, ce qui fait que même avec une limite à 1.2 Mbit, je saturais la ligne. Merci à toi. > > Oui, on m'avait déjà fait la remarque, et j'avais testé mtr over UDP > > (avec le flag -u), pour des résultats identiques. Visiblement pas un > > problème d'ICMP donc. De plus, le ressenti utilisateur (disons la > > réactivité du SSH, par exemple), correspond bien à la latence. > > Ca ne change rien. Seule la latence entre la source et la destination > fait foi. La latence sur les routeurs intermediaires est TOUJOURS traite > par des CPU qui plus important a faire. D'accord, merci. > > Avec une seule machine qui fait du P2P ? > > Aieee !! Tu fais tes tests en P2P ??? Essaie deja de valider le debit > sur UNE seule connexion TCP, ou avec un flux UDP, avec differentes > tailles de paquet. J'avais aussi fait des tests en utilisant une connexion HTTP, pour des résultats similaires. Cordialement, Grégoire Leroy --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
On Wed, 28 Dec 2011 18:00:22 +0100, "Fabien VINCENT" said: > > Ah !! Et moi qui croyais que tu voulais faire de la magie noire :D > > Augmenter un peu les prix pour financer le service ? > > > > On a essayé en demandant aux résidents => échec Donc ils veulent que ca marche bien, et pour pas cher, alors qu'il n'y a pas d'autre alternative Service de qualite pour clientele captive ?!?!?!?!? S'ils ont du mal a comprendre, tu peux laisser pourrir les choses. Sinon, il semble que tu est a moins de 7km en vol d'oiseau du siege OVH. Le wireless P2P/directionnel est a etudier. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
On Wed, 28 Dec 2011 15:06:02 +0100, "Grégoire Leroy" said: > La QoS est effectuée par résident (ip source en upload, ip de destination en > download) et est faite des deux côtés. Si on peut réguler le trafic en sortie > de l'interface externe, on peut aussi le réguler en sortie de l'interface > interne non ? Ok, tu peux le faire, mais ca ne sert pas a grand chose : ton tuyau peut etre deja sature avant que ca arrive chez toi. Normalement, le Qos est effectif quand il est mis avant l'entree dans le tuyau le plus petit. Dans ton cas c'est en uplink. Pour le downlink, il faudra que c'est ton FAI qui le fait, mais ils doivent avoir d'autres choses au program. > Oui, on m'avait déjà fait la remarque, et j'avais testé mtr over UDP (avec le > flag -u), pour des résultats identiques. Visiblement pas un problème d'ICMP > donc. De plus, le ressenti utilisateur (disons la réactivité du SSH, par > exemple), correspond bien à la latence. Ca ne change rien. Seule la latence entre la source et la destination fait foi. La latence sur les routeurs intermediaires est TOUJOURS traite par des CPU qui plus important a faire. > Avec une seule machine qui fait du P2P ? Aieee !! Tu fais tes tests en P2P ??? Essaie deja de valider le debit sur UNE seule connexion TCP, ou avec un flux UDP, avec differentes tailles de paquet. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
> >> Ah !! Et moi qui croyais que tu voulais faire de la magie noire :D > >> Augmenter un peu les prix pour financer le service ? > >> > > > > On a essayé en demandant aux résidents => échec > > > > Abordons le problème autrement. > > La sDSL est là pour répondre à quel besoin, qui n'est à priori pas > satisfait par les aDSL ? > C'était plus en terme de nombre de connexions que nous voulions avancer (+ToIP pour l'admin de la résidence, ce qui as fait qu'ils ont pris un truc mousse mousse pro, mais qui n'est pas plus satisfaisant qu'un ADSL bien blindé). > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
On 12/28/11 6:00 PM, Fabien VINCENT wrote: > 2011/12/28 Thomas Mangin > [snip] >> Ah !! Et moi qui croyais que tu voulais faire de la magie noire :D >> Augmenter un peu les prix pour financer le service ? >> > > On a essayé en demandant aux résidents => échec > Abordons le problème autrement. La sDSL est là pour répondre à quel besoin, qui n'est à priori pas satisfait par les aDSL ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
2011/12/28 Thomas Mangin > > Oui enfin justement, on cherche des solutions, vu que dans le cas on bute > > sur Orange et que nous ne pouvons malheureusement pas avoir d'autres > > opérateurs (Résidence Ecole Télécom, Bakchichs, et autres CA qui ne > servent > > à rien, sauf à empêcher de prendre d'autres opérateurs et des vrais > > décisions autre que "on verra") > > Tu peux toujours utiliser un P2P en sans fils et avoir les DSL autre part > :p > Pas cher : http://routerboard.com/ > > Tu as essaye d' installer un cache HTTP local ? > Plus de lignes, et moins d'utilisateur par ligne ca passe aussi :) > > > Qu'est ce qu'on aimerait une simplicité pareil, ce n'est pas une > > entreprise, mais une asso loi 1901 qui ne fait pas de bénéf > > Ah !! Et moi qui croyais que tu voulais faire de la magie noire :D > Augmenter un peu les prix pour financer le service ? > On a essayé en demandant aux résidents => échec > Ou etes-vous victimes des meme problemes de pub que les telcos :D :D ? > > > La question du prix, j'ai déjà dit pourquoi c'était pas si simple. Et si > il > > n'y avait que cette question, ca n'expliquerait pas pourquoi Orange nous > > répond qu'il est impossible d'avoir de nouvelles lignes car le NRA dde la > > DR FT (TRIOLO-59 si mes souvenirs sont bons) et full de chez full ... > Dans > > mes souvenirs ils ont du dénuméroter une ADSL sur un autre NRA car plus > de > > place à Triolo déjà à l'époque ... Et j'ai eu beau tenter des approches > > avec des contacts en interne chez FT, ils n'ont pas de solutions à ce > > problème (à part fibrer, mais on retombe dans le blème des sious sious. > > Le service a simplement un prix et essayer de le fournir a moindre cout tu > te rend compte des problemes associes. > Oui et je connais beaucoup de gens qui achètent du Chanel juste pour ne pas avoir de problème de qualité de parfum ... Si seulement on avait plus ce frein de débit, je ne sais pas si on aurait posté sur FrNOG, puisque on aurait 40Gbps en Metro xD On est pas cons non plus, juste on essaye de trouver une solution à un pb donné (c'est moi qui ait conseillé à Grégoire de contacter FrNOG, en me disant qu'une bonne ame aurait peut être une idée du peu de qualité de la SDSL, pas de pourquoi on ne peut pas prendre de nouvelles lignes un nouvel opérateur et autres solutions liées à un qqconque changement). > > Thomas > > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
> Oui enfin justement, on cherche des solutions, vu que dans le cas on bute > sur Orange et que nous ne pouvons malheureusement pas avoir d'autres > opérateurs (Résidence Ecole Télécom, Bakchichs, et autres CA qui ne servent > à rien, sauf à empêcher de prendre d'autres opérateurs et des vrais > décisions autre que "on verra") Tu peux toujours utiliser un P2P en sans fils et avoir les DSL autre part :p Pas cher : http://routerboard.com/ Tu as essaye d' installer un cache HTTP local ? Plus de lignes, et moins d'utilisateur par ligne ca passe aussi :) > Qu'est ce qu'on aimerait une simplicité pareil, ce n'est pas une > entreprise, mais une asso loi 1901 qui ne fait pas de bénéf Ah !! Et moi qui croyais que tu voulais faire de la magie noire :D Augmenter un peu les prix pour financer le service ? Ou etes-vous victimes des meme problemes de pub que les telcos :D :D ? > La question du prix, j'ai déjà dit pourquoi c'était pas si simple. Et si il > n'y avait que cette question, ca n'expliquerait pas pourquoi Orange nous > répond qu'il est impossible d'avoir de nouvelles lignes car le NRA dde la > DR FT (TRIOLO-59 si mes souvenirs sont bons) et full de chez full ... Dans > mes souvenirs ils ont du dénuméroter une ADSL sur un autre NRA car plus de > place à Triolo déjà à l'époque ... Et j'ai eu beau tenter des approches > avec des contacts en interne chez FT, ils n'ont pas de solutions à ce > problème (à part fibrer, mais on retombe dans le blème des sious sious. Le service a simplement un prix et essayer de le fournir a moindre cout tu te rend compte des problemes associes. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
Le nouveau protocole uTP de Bitorrent est tres bon pour utiliser TOUTE la capacite disponible (c'est de l'UDP) http://en.wikipedia.org/wiki/Micro_Transport_Protocol Sur un lien partage c'est un gros problème car même avec son algo de detection de saturation, quand la connexion est partage les autres utilisateurs souffrent. D'ou ma recommendation de faire sur que les paquet DNS sont prioritise sur une autre ligne. Le mieux est de separer les usages par lignes. Il faut juste passez BCP de temps a savoir ou est quoi NBAR est assez bon est c'est inclus dans l'IOS (ou ca l'etait). Utiliser en meme temps des protocole voulant toute la bande passante (uTP, FTP, HTTP, ...) et d'autre voulant une bonne latence (RTP, teamspeak, ...) c'est un desastre assure. Thomas On 28 Dec 2011, at 16:16, Paul Rolland (ポール・ロラン) wrote: > Bonjour, > > On Wed, 28 Dec 2011 13:27:21 +0100 > Grégoire Leroy wrote: > >> Un seul utilisateur était connecté et téléchargeait 2 ou 3 fichiers par >> torrents, atteignant 1.4 méga. > > Torrent... pas trop l'habitude... mais c'est pas le truc P2P qui fait que > la machine : > - elle se retrouve a charger depuis plein de sources, > - elle se retrouve a feeder aussi vers plein de monde > et du coup, la ligne DSL, elle se trouve avec du traffic dans les deux sens > plein pot... voir plus de Up que de Dn quand on n'a pas de chance ? > > En _S_DSL, je ne sais pas, mais en _A_DSL, c'est le bon moyen de tuer son > lien on ne bride pas le Up... > Du coup, la box se retrouve : > - a gerer plein de PPS (voir tous les autres posts), > - a gerer plein de sessions NAT. > > Evidemment, ca n'explique pas les chiffres du mtr de l'OP... et en > particulier le saut limite quantique dans les temps sur le 3eme (ou 4eme ?) > hop... mais peut-etre qu'il peut etre interessant de regarder si le client > torrent sait limiter : > - le debit Up servi, > - le nombre de peers > pour essayer de reduire un peu la charge sur les petites boiboites d'Orange. > > M'enfin, ce sont mes 2 sous de la fin d'annee... alors a prendre avec > precaution ;) Et pour les etrennes, on verra en 2012 ! > > Paul > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
2011/12/28 Jérôme Nicolle > Grégoire, > > Le 28 décembre 2011 13:27, Grégoire Leroy > a écrit : > > Je suis étudiant à TELECOM Lille1, et j'ai repris le réseau d'une > certaine > > résidence de 150 utilisateurs derrière 2 lignes ADSL et une ligne SDSL > (chez > > Orange). > > Quoi que tu fasses, 100 dans 2, ça rentre pas, même en tapant dessus à > grand coup de QoS. > Oui enfin justement, on cherche des solutions, vu que dans le cas on bute sur Orange et que nous ne pouvons malheureusement pas avoir d'autres opérateurs (Résidence Ecole Télécom, Bakchichs, et autres CA qui ne servent à rien, sauf à empêcher de prendre d'autres opérateurs et des vrais décisions autre que "on verra") > > Mais si c'est plus "facile" de buter contre le mur et de recommencer > que d'aller cherche le budget qui va bien pour avoir le débit dont > vous avez besoin... > Qu'est ce qu'on aimerait une simplicité pareil, ce n'est pas une entreprise, mais une asso loi 1901 qui ne fait pas de bénéf > > La QoS n'est jamais une réponse. C'est une question. La réponse est > Non, mieux vaut avoir les tuyaux adaptés. Surtout au prix auquel tu > peux les avoir... > La question du prix, j'ai déjà dit pourquoi c'était pas si simple. Et si il n'y avait que cette question, ca n'expliquerait pas pourquoi Orange nous répond qu'il est impossible d'avoir de nouvelles lignes car le NRA dde la DR FT (TRIOLO-59 si mes souvenirs sont bons) et full de chez full ... Dans mes souvenirs ils ont du dénuméroter une ADSL sur un autre NRA car plus de place à Triolo déjà à l'époque ... Et j'ai eu beau tenter des approches avec des contacts en interne chez FT, ils n'ont pas de solutions à ce problème (à part fibrer, mais on retombe dans le blème des sious sious. > > > > -- > Jérôme Nicolle > 06 19 31 27 14 > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
Bonjour, On Wed, 28 Dec 2011 13:27:21 +0100 Grégoire Leroy wrote: > Un seul utilisateur était connecté et téléchargeait 2 ou 3 fichiers par > torrents, atteignant 1.4 méga. Torrent... pas trop l'habitude... mais c'est pas le truc P2P qui fait que la machine : - elle se retrouve a charger depuis plein de sources, - elle se retrouve a feeder aussi vers plein de monde et du coup, la ligne DSL, elle se trouve avec du traffic dans les deux sens plein pot... voir plus de Up que de Dn quand on n'a pas de chance ? En _S_DSL, je ne sais pas, mais en _A_DSL, c'est le bon moyen de tuer son lien on ne bride pas le Up... Du coup, la box se retrouve : - a gerer plein de PPS (voir tous les autres posts), - a gerer plein de sessions NAT. Evidemment, ca n'explique pas les chiffres du mtr de l'OP... et en particulier le saut limite quantique dans les temps sur le 3eme (ou 4eme ?) hop... mais peut-etre qu'il peut etre interessant de regarder si le client torrent sait limiter : - le debit Up servi, - le nombre de peers pour essayer de reduire un peu la charge sur les petites boiboites d'Orange. M'enfin, ce sont mes 2 sous de la fin d'annee... alors a prendre avec precaution ;) Et pour les etrennes, on verra en 2012 ! Paul --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
Paul, Desole, je me suis trompe sur mon chiffre. Ce qui arrive quand on est a la bourre ... tu as raison - il faut compter 15k (ou 13k) pas 40,000 ... Thomas On 28 Dec 2011, at 16:02, Thomas Mangin wrote: > Paul, > > Oui, c'est exact mais je crois que le packet ethernet le plus petit est de 46 > bytes, alors on parle d'environ 13,000 > J'ai ete gentil, j'ai compte que le packet le plus petit serai de la taille > du MTU (1,5 k) > Je n'avais pas envi qu'on me dise que je suis l'avocat du diable avec des > chiffres aussi gros :p > > Et puisque j'y suis , le 3k packets par secondes, c'est 150 etudiants a 20 > packets par secondes. > > Thomas > > On 28 Dec 2011, at 15:50, Paul Rolland (ポール・ロラン) wrote: > >> Salut Thomas, >> >> On Wed, 28 Dec 2011 15:30:59 + >> Thomas Mangin wrote: >> >>> Un packet ACK c'est normellent 40 bytes. Pour remplir une ligne de >>> 600,000 bytes, if faut donc 40,000 pps. 40,000 pps c'est un chiffre >>> enorme ! >> >> Comment tu calcules ca ? 600.000 / 40 = 15.000 (ca reste enorme, mais c'est >> deja presque le tiers). >> >> Paul > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
Paul, Oui, c'est exact mais je crois que le packet ethernet le plus petit est de 46 bytes, alors on parle d'environ 13,000 J'ai ete gentil, j'ai compte que le packet le plus petit serai de la taille du MTU (1,5 k) Je n'avais pas envi qu'on me dise que je suis l'avocat du diable avec des chiffres aussi gros :p Et puisque j'y suis , le 3k packets par secondes, c'est 150 etudiants a 20 packets par secondes. Thomas On 28 Dec 2011, at 15:50, Paul Rolland (ポール・ロラン) wrote: > Salut Thomas, > > On Wed, 28 Dec 2011 15:30:59 + > Thomas Mangin wrote: > >> Un packet ACK c'est normellent 40 bytes. Pour remplir une ligne de >> 600,000 bytes, if faut donc 40,000 pps. 40,000 pps c'est un chiffre >> enorme ! > > Comment tu calcules ca ? 600.000 / 40 = 15.000 (ca reste enorme, mais c'est > deja presque le tiers). > > Paul --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
> 600kbs d'ACKs TCP ? > > Il s'est foutu de ta gueule. La taille d'un paquet IP peut varier entre 20 et 65,535 bytes, donc 600kbps d'ACK ca ne veut rien dire. http://en.wikipedia.org/wiki/IPv4 Un packet ACK c'est normellent 40 bytes. Pour remplir une ligne de 600,000 bytes, if faut donc 40,000 pps. 40,000 pps c'est un chiffre enorme ! Pour donner une idee de ce que les routeurs peuvent passer en PPS : http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf Ma machine en ne faisant "rien" (avec Chrome, Mail.app, iChat ouvert) génère 20 paquets par seconde d'activite, c'est 3k paquets d'inactivité, surement assez pour bien occuper un ligne DSL. Avec un MTU ethernet d'une machine est de 1,500 bytes, il faut environ 400 pps, ce qui est toujours un raport d'environ 100. Une ligne DSL ne permet surement pas plus de quelque millier de PPS - 2-3k PPS peut-etre, donc le nombre de PPS compte beaucoup plus que la bande passante. C'est pour cela que les DDOS, ce sont plein de petit paquets UDP et pas de GROS packets TCP, c'est invisible sur les graphes de bande passante mais ca fait super mal. >> Pourquoi la latence n'apparaitrait qu'une fois dans l'infra >> Orange ? >> > > A ta question "pourquoi ?" je réponds "parce qu'ils sont mauvais". soupir ... J'ai deja répondu. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
Grégoire, Le 28 décembre 2011 13:27, Grégoire Leroy a écrit : > Je suis étudiant à TELECOM Lille1, et j'ai repris le réseau d'une certaine > résidence de 150 utilisateurs derrière 2 lignes ADSL et une ligne SDSL (chez > Orange). Quoi que tu fasses, 100 dans 2, ça rentre pas, même en tapant dessus à grand coup de QoS. Mais si c'est plus "facile" de buter contre le mur et de recommencer que d'aller cherche le budget qui va bien pour avoir le débit dont vous avez besoin... La QoS n'est jamais une réponse. C'est une question. La réponse est Non, mieux vaut avoir les tuyaux adaptés. Surtout au prix auquel tu peux les avoir... -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
Le 28 décembre 2011 14:16, Thomas Mangin a écrit : > > Pour ta question sur mtr, les FAI limitent les resources donnees aux routeurs > pour repondre a ICMP. Oublie la latence des routeurs, le role d'un routeur > est de router, pas de répondre a des requêtes ICMP. tout à fait d'accord avec toi Thomas, les routeurs ne sont pas des boites à ping. > Si un HOP est lent mais le suivant ne l'est pas, il est clair que le routeur > ne ralenti pas les paquets qui le traverse. Justement, suis-je le seul à trouver bizarre l'augmentation de la latence entre LILP2 et NMLIL704 ? ces deux routeurs doivent se trouver quasiment back-to-back non ? La latence est constante ensuite, donc ça ne correspond pas à un icmp rate-limit sur la cpu de LILP2... - Pierre. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
> C'est effectivement ce qu'on pense en tant qu'ancien(s) pour le foutage de > gueule, le commercial Orange à l'époque ou nous avions seulement 2 ADSLs nous > a promis , un gain important avec une SDSL, qui se révéle être un échec > partiel (les résidents n'ont pas vraiment senti la différence). L'avantage des produits SDSL c'est l'upload. Le problème est que toute solution a base de plusieurs lignes DSL, c'est principalement de la bidouille :) > En fait la promesse était que la SDSL, avec un débit moindre aux ADSL, mais > garanti, permettrait de faire passer plus de sessions / conn par sec. Oui, il y a surement plus de PPS sur un produit SDSL car c'est un produit d'entreprise ou on s'attend a plus de quelques machines actives en même temps. > Ce qui se révèle être faux d'après les résultats d'utilisation ... A moins de le débrancher et de regarder la difference, il est dur de juger. Cela depend aussi de la configuration du routeur. > En même temps, j'étais étudiant, je ne savais pas encore que commercial était > un métier universel (ou comment vendre des carottes et un modem ADSL :p) Tout depend de la société :) Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
On Wed, 28 Dec 2011 15:01:38 +0100, Fabien VINCENT wrote: C'est effectivement ce qu'on pense en tant qu'ancien(s) pour le foutage de gueule, le commercial Orange à l'époque ou nous avions seulement 2 ADSLs nous a promis , un gain important avec une SDSL, qui se révéle être un échec partiel (les résidents n'ont pas vraiment senti la différence). En fait la promesse était que la SDSL, avec un débit moindre aux ADSL, mais garanti, permettrait de faire passer plus de sessions / conn par sec. Ce qui se révèle être faux d'après les résultats d'utilisation ... En même temps, j'étais étudiant, je ne savais pas encore que commercial était un métier universel (ou comment vendre des carottes et un modem ADSL :p) En passant d'un ADSL vers un SDSL, on passe souvent d'un 8M/1M mutualisé, vers du 2M/2M dédié (dans votre cas). Ainsi les débits montant et descendants sont garantis, le débit montant est multiplié par 2, mais le débit descendant est divisé par 4. Tout dépend des usages, mais si vous avez besoin de download (navigation web), un ADSL 8M ou 18M serait plus approprié, en plus de cette accès/routeur qui gère également là voix (analogique vers IP). Cordialement. -- Raphaël Durand www.ultrawaves.net Les mails postés depuis cette boite personnelle n'engagent en aucune façon mon employeur. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
On 12/28/11 1:27 PM, Grégoire Leroy wrote:
> Bonjour à tous,
>
> Je suis étudiant à TELECOM Lille1, et j'ai repris le réseau d'une certaine
> résidence de 150 utilisateurs derrière 2 lignes ADSL et une ligne SDSL (chez
> Orange).
>
> Étant donné que nous avons régulièrement des pertes et une latence très
> importante, j'ai effectué quelques tests et contacté Orange Business Services.
>
> Test : http://bpaste.net/show/21180/
>
> Un seul utilisateur était connecté et téléchargeait 2 ou 3 fichiers par
> torrents, atteignant 1.4 méga.
>
> Des tests ont été effectués, en bridant notre QoS à 1.080 méga, pour le même
> résultat.
> Il est apparu qu'à environ 800kbit/s, nous n'avions plus de problèmes.
>
> Le débit maximal mesuré, lui, allait jusqu'à environ 1.75 méga
>
> Le support d'OBS m'a tenu ce raisonnement :
> -La ligne est une ligne 2 mégas - l'overhead ATM = 1.6 méga
> -Il faut y retrancher 200 kbit/s utilisés pour la téléphonie, soit 1.4 méga
> -Il faut minorer ce débit pour laisser passer les ack TCP.
>
600kbs d'ACKs TCP ?
Il s'est foutu de ta gueule.
> J'aurais donc 2 questions :
> 1) De combien est-il habituel de réduire le débit dans ce genre de cas ? Lors
> de la mise en place de la QoS, j'avais lu entre 5 et 10%. Passer de 1.4 méga
> à
> 800kbit, c'est plutôt de l'ordre de 40%...
> 2) Quand on regarde le MTR, on s'aperçoit que la latence ne vient pas de la
> ligne elle-même, mais du troisième routeur chez Orange. OBS m'a dit que
> c'était normal ("tous nos routeurs ne vont pas à la même vitesse") Est-ce que
> ce comportement est réellement justifié, ou est ce que c'est de la mauvaise
> foi de leur part ? Pourquoi la latence n'apparaitrait qu'une fois dans
> l'infra
> Orange ?
>
A ta question "pourquoi ?" je réponds "parce qu'ils sont mauvais".
> PS : ce problème n'a _rien_ à voir avec le fait que nous soyons 150, les
> tests
> ont été menés avec un seul utilisateur.
>
> Merci d'avance pour vos réponses,
> Cordialement,
> Grégoire Leroy
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
Le Wednesday 28 December 2011 13:43:29, Pierre Jaury a écrit : > En vérité j'ai probablement lu de travers : où appliquez-vous la QOS ? > l'algorithme et les paramètres sont également importants dans ce genre > de cas (a fortiori sur de faibles débits très variables). Les filtres à > base de bucket entre autres, lorsque mal configurés, ont une tendance > malsaine à écraser la fenêtre TCP et le débit qui va avec, spécialement > si tu fais tes tests avec une connexion unique qui plafonne. La QoS est appliquée sur notre passerelle, juste avant la livebox. Il s'agit d'une QoS de type Fair-Queueing par utilisateur (réalisée à l'aide d'IPFW/Dummynet), l'algorithme est QFQ. En revanche, les flux d'un utilisateur ne sont pas régulés. Le Wednesday 28 December 2011 14:16:06, Thomas Mangin a écrit : > Ce n'est pas mon domaine de pointe, mais tes conclusion sont fausses : > - le nombre d'utilisateurs compte Par "le nombre d'utilisateurs n'a rien à voir", je voulais juste indiquer que, que ce soit avec 1 ou 15 utilisateurs (les 135 autres vont sur Facebook/Youtube et utilisent donc les lignes ADSL de toute façon), j'ai les mêmes problèmes. En faisant les tests, j'ai pris soin que rien d'autre que mon unique utilisateur qui ne fait que du P2P ne passe sur la SDSL (plus précisément cet "utilisateur" est un de mes serveurs). > Un_ etudiant utilisant BT peut causer beaucoup de paquets a entrer sur la ligne (depuis le net). Comme le QOS ne marche qu'en SORTIE d'une interface, la ligne DSL peux etre sature avant meme que ton routeur soit touche. Tu ne peux rien y faire. La QoS est effectuée par résident (ip source en upload, ip de destination en download) et est faite des deux côtés. Si on peut réguler le trafic en sortie de l'interface externe, on peut aussi le réguler en sortie de l'interface interne non ? > Avec 150 étudiants, tu risques de passer les limites en terme de PPS de ton BRAS par ligne avant de saturer ta bande passante. Je n'ai jamais vu aucune specification pour le nombre de PPS sure un produit DSL (mais je ne suis pas en France). Comme indiqué plus haut, les tests ont été réalisés avec un seul utilisateur connecté. > Utilise le QOS pour donner priorite a : > - Requête DNS vers les resolveurs utilises (sinon tu va avoir de la > retransmission que tu peux éviter) À ce niveau là, pas de problèmes, le DNS passe par les lignes ADSL. > - TCP ACK, SYN, SYN/ACK, FIN (oui, FIN aussi !!) Ça va être testé, merci. > Si tu utilise un routeur cisco, utilise NBAR. Limite tous les protocoles inconnus a pas grand chose et donne aux protocols connus ( HTTP, HTTPS, FTP, SMTP, POP, IMAP, etc.) la part du lion. La principale utilisation de la ligne c'est du protocole non connu (jeux en ligne / teamspeak), l'IMAP / POP / FTP est minoritaire (et le HTTP/HTTPS passe par les lignes ADSL). > Ceci dit, un utilisateur seul pourra toujours telecharger plus que la ligne ne permet, affectant le service de tous les autres usagers. Je ne comprends pas comment : la QoS met justement une limite à ce que les utilisateurs téléchargent et uploadent : on définit arbitrairement la bande passante (comme indiqué dans le précédent mail, j'ai testé avec 1.4 méga, 1.080 méga, 800kbit/s), et elle est équitablement répartie entre utilisateurs (en fonctions de leurs besoins). Et j'ai pu le vérifier, en aucun cas cette limite n'est dépassée. > Pour ta question sur mtr, les FAI limitent les resources donnees aux routeurs pour repondre a ICMP. Oublie la latence des routeurs, le role d'un routeur est de router, pas de répondre a des requêtes ICMP. > Si un HOP est lent mais le suivant ne l'est pas, il est clair que le routeur ne ralenti pas les paquets qui le traverse. > Si un HOP a 100% de packet loss mais que le suivant n'en a pas, il est clair que le routeur ne pert pas de paquets. Oui, on m'avait déjà fait la remarque, et j'avais testé mtr over UDP (avec le flag -u), pour des résultats identiques. Visiblement pas un problème d'ICMP donc. De plus, le ressenti utilisateur (disons la réactivité du SSH, par exemple), correspond bien à la latence. > Rapelle-toi que tu utilises un produit partage (Avec les produits DSL, il y a de la contention sur la connexion du DSLAM/BRAS au reseau) pour un grand nombre d'utilisateur. > Ce n'est pas la maniere d'utiliser ce produit. Il est aussi possible que tu arrives a atteindre des limites materielles ou du produit. Avec une seule machine qui fait du P2P ? Merci à vous et bonnes fêtes, Cordialement, Grégoire Leroy --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
Je vais me permettre d'aider Grégoire qui est un de mes successeurs dans la gestion de ce réseau ;) *Du reste, ça sent (au moins en partie) le foutage de gueule ; curieux de connaître la véritable raison lorsque vous aurez élucidé. Et quitte à avoir plusieurs lignes, autant multiplier les opérateurs, non ?* C'est effectivement ce qu'on pense en tant qu'ancien(s) pour le foutage de gueule, le commercial Orange à l'époque ou nous avions seulement 2 ADSLs nous a promis , un gain important avec une SDSL, qui se révéle être un échec partiel (les résidents n'ont pas vraiment senti la différence). En fait la promesse était que la SDSL, avec un débit moindre aux ADSL, mais garanti, permettrait de faire passer plus de sessions / conn par sec. Ce qui se révèle être faux d'après les résultats d'utilisation ... En même temps, j'étais étudiant, je ne savais pas encore que commercial était un métier universel (ou comment vendre des carottes et un modem ADSL :p) *Rapelle-toi que tu utilises un produit partage (Avec les produits DSL, il y a de la contention sur la connexion du DSLAM/BRAS au reseau) pour un grand nombre d'utilisateur. Ce n'est pas la maniere d'utiliser ce produit. Il est aussi possible que tu arrives a atteindre des limites materielles ou du produit.* C'est ce qu'on aimerait bien savoir ;) Merci d'avance pour votre aide à Grégoire ! *Fabien VINCENT* --- Twitter : @beufanet Mail : fab...@beufa.net Mail : fabvinc...@gmail.com --- 2011/12/28 Thomas Mangin > Gregoire. > > Ce n'est pas mon domaine de pointe, mais tes conclusion sont fausses : > - le nombre d'utilisateurs compte > - le QOS n'est pas une solution miracle > > Chaque machine allume fait des requêtes d'arrière plan, faire tourner > ngrep/tshark/wireshark sur une machine qui ne fait soit disant _rien_ est > toujours surprenant. > Il serait plus juste de regarder combien de PPS la ligne peux passer, plus > que la bande passante. > > Un_ etudiant utilisant BT peut causer beaucoup de paquets a entrer sur la > ligne (depuis le net). Comme le QOS ne marche qu'en SORTIE d'une interface, > la ligne DSL peux etre sature avant meme que ton routeur soit touche. Tu ne > peux rien y faire. > > Avec 150 étudiants, tu risques de passer les limites en terme de PPS de > ton BRAS par ligne avant de saturer ta bande passante. Je n'ai jamais vu > aucune specification pour le nombre de PPS sure un produit DSL (mais je ne > suis pas en France). > > Le debit maximum depend aussi de la capacite des clients a utiliser TCP > windows scaling, si tu as des pertes sur la ligne, tu n'arriveras pas a > atteindre la vitesse maximale. > > Maintenant que je t'ai bien découragé, les conseils : > > Utilise le QOS pour donner priorite a : > - Requête DNS vers les resolveurs utilises (sinon tu va avoir de la > retransmission que tu peux éviter) > - TCP ACK, SYN, SYN/ACK, FIN (oui, FIN aussi !!) > > Si tu utilise un routeur cisco, utilise NBAR. Limite tous les protocoles > inconnus a pas grand chose et donne aux protocols connus ( HTTP, HTTPS, > FTP, SMTP, POP, IMAP, etc.) la part du lion. > Ceci dit, un utilisateur seul pourra toujours telecharger plus que la > ligne ne permet, affectant le service de tous les autres usagers. > "show ip flow top-talkers" est ton ami pour trouver et chatier les > coupables. > > Pour ta question sur mtr, les FAI limitent les resources donnees aux > routeurs pour repondre a ICMP. Oublie la latence des routeurs, le role d'un > routeur est de router, pas de répondre a des requêtes ICMP. > Si un HOP est lent mais le suivant ne l'est pas, il est clair que le > routeur ne ralenti pas les paquets qui le traverse. > Si un HOP a 100% de packet loss mais que le suivant n'en a pas, il est > clair que le routeur ne pert pas de paquets. > > Rapelle-toi que tu utilises un produit partage (Avec les produits DSL, il > y a de la contention sur la connexion du DSLAM/BRAS au reseau) pour un > grand nombre d'utilisateur. > Ce n'est pas la maniere d'utiliser ce produit. Il est aussi possible que > tu arrives a atteindre des limites materielles ou du produit. > > J'espere que ca t'aide, > > Bonnes fetes, > > Thomas > > On 28 Dec 2011, at 12:27, Grégoire Leroy wrote: > > > Bonjour à tous, > > > > Je suis étudiant à TELECOM Lille1, et j'ai repris le réseau d'une > certaine > > résidence de 150 utilisateurs derrière 2 lignes ADSL et une ligne SDSL > (chez > > Orange). > > > > Étant donné que nous avons régulièrement des pertes et une latence très > > importante, j'ai effectué quelques tests et contacté Orange Business > Services. > > > > Test : http://bpaste.net/show/21180/ > > > > Un seul utilisateur était connecté et téléchargeait 2 ou 3 fichiers par > > torrents, atteignant 1.4 méga. > > > > Des tests ont été effectués, en bridant notre QoS à 1.080 méga, pour le > même > > résultat. > > Il est apparu qu'à environ 800kbit/s, nous n'avion
Re: [FRnOG] [TECH] Pertes et latence importantes
Gregoire.
Ce n'est pas mon domaine de pointe, mais tes conclusion sont fausses :
- le nombre d'utilisateurs compte
- le QOS n'est pas une solution miracle
Chaque machine allume fait des requêtes d'arrière plan, faire tourner
ngrep/tshark/wireshark sur une machine qui ne fait soit disant _rien_ est
toujours surprenant.
Il serait plus juste de regarder combien de PPS la ligne peux passer, plus que
la bande passante.
Un_ etudiant utilisant BT peut causer beaucoup de paquets a entrer sur la ligne
(depuis le net). Comme le QOS ne marche qu'en SORTIE d'une interface, la ligne
DSL peux etre sature avant meme que ton routeur soit touche. Tu ne peux rien y
faire.
Avec 150 étudiants, tu risques de passer les limites en terme de PPS de ton
BRAS par ligne avant de saturer ta bande passante. Je n'ai jamais vu aucune
specification pour le nombre de PPS sure un produit DSL (mais je ne suis pas en
France).
Le debit maximum depend aussi de la capacite des clients a utiliser TCP windows
scaling, si tu as des pertes sur la ligne, tu n'arriveras pas a atteindre la
vitesse maximale.
Maintenant que je t'ai bien découragé, les conseils :
Utilise le QOS pour donner priorite a :
- Requête DNS vers les resolveurs utilises (sinon tu va avoir de la
retransmission que tu peux éviter)
- TCP ACK, SYN, SYN/ACK, FIN (oui, FIN aussi !!)
Si tu utilise un routeur cisco, utilise NBAR. Limite tous les protocoles
inconnus a pas grand chose et donne aux protocols connus ( HTTP, HTTPS, FTP,
SMTP, POP, IMAP, etc.) la part du lion.
Ceci dit, un utilisateur seul pourra toujours telecharger plus que la ligne ne
permet, affectant le service de tous les autres usagers.
"show ip flow top-talkers" est ton ami pour trouver et chatier les coupables.
Pour ta question sur mtr, les FAI limitent les resources donnees aux routeurs
pour repondre a ICMP. Oublie la latence des routeurs, le role d'un routeur est
de router, pas de répondre a des requêtes ICMP.
Si un HOP est lent mais le suivant ne l'est pas, il est clair que le routeur ne
ralenti pas les paquets qui le traverse.
Si un HOP a 100% de packet loss mais que le suivant n'en a pas, il est clair
que le routeur ne pert pas de paquets.
Rapelle-toi que tu utilises un produit partage (Avec les produits DSL, il y a
de la contention sur la connexion du DSLAM/BRAS au reseau) pour un grand nombre
d'utilisateur.
Ce n'est pas la maniere d'utiliser ce produit. Il est aussi possible que tu
arrives a atteindre des limites materielles ou du produit.
J'espere que ca t'aide,
Bonnes fetes,
Thomas
On 28 Dec 2011, at 12:27, Grégoire Leroy wrote:
> Bonjour à tous,
>
> Je suis étudiant à TELECOM Lille1, et j'ai repris le réseau d'une certaine
> résidence de 150 utilisateurs derrière 2 lignes ADSL et une ligne SDSL (chez
> Orange).
>
> Étant donné que nous avons régulièrement des pertes et une latence très
> importante, j'ai effectué quelques tests et contacté Orange Business Services.
>
> Test : http://bpaste.net/show/21180/
>
> Un seul utilisateur était connecté et téléchargeait 2 ou 3 fichiers par
> torrents, atteignant 1.4 méga.
>
> Des tests ont été effectués, en bridant notre QoS à 1.080 méga, pour le même
> résultat.
> Il est apparu qu'à environ 800kbit/s, nous n'avions plus de problèmes.
>
> Le débit maximal mesuré, lui, allait jusqu'à environ 1.75 méga
>
> Le support d'OBS m'a tenu ce raisonnement :
> -La ligne est une ligne 2 mégas - l'overhead ATM = 1.6 méga
> -Il faut y retrancher 200 kbit/s utilisés pour la téléphonie, soit 1.4 méga
> -Il faut minorer ce débit pour laisser passer les ack TCP.
>
> J'aurais donc 2 questions :
> 1) De combien est-il habituel de réduire le débit dans ce genre de cas ? Lors
> de la mise en place de la QoS, j'avais lu entre 5 et 10%. Passer de 1.4 méga
> à
> 800kbit, c'est plutôt de l'ordre de 40%...
> 2) Quand on regarde le MTR, on s'aperçoit que la latence ne vient pas de la
> ligne elle-même, mais du troisième routeur chez Orange. OBS m'a dit que
> c'était normal ("tous nos routeurs ne vont pas à la même vitesse") Est-ce que
> ce comportement est réellement justifié, ou est ce que c'est de la mauvaise
> foi de leur part ? Pourquoi la latence n'apparaitrait qu'une fois dans
> l'infra
> Orange ?
>
> PS : ce problème n'a _rien_ à voir avec le fait que nous soyons 150, les
> tests
> ont été menés avec un seul utilisateur.
>
> Merci d'avance pour vos réponses,
> Cordialement,
> Grégoire Leroy
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes et latence importantes
En vérité j'ai probablement lu de travers : où appliquez-vous la QOS ?
l'algorithme et les paramètres sont également importants dans ce genre
de cas (a fortiori sur de faibles débits très variables). Les filtres à
base de bucket entre autres, lorsque mal configurés, ont une tendance
malsaine à écraser la fenêtre TCP et le débit qui va avec, spécialement
si tu fais tes tests avec une connexion unique qui plafonne.
On Wed, 2011-12-28 at 13:27 +0100, Grégoire Leroy wrote:
> Bonjour à tous,
>
> Je suis étudiant à TELECOM Lille1, et j'ai repris le réseau d'une certaine
> résidence de 150 utilisateurs derrière 2 lignes ADSL et une ligne SDSL (chez
> Orange).
>
> Étant donné que nous avons régulièrement des pertes et une latence très
> importante, j'ai effectué quelques tests et contacté Orange Business Services.
>
> Test : http://bpaste.net/show/21180/
>
> Un seul utilisateur était connecté et téléchargeait 2 ou 3 fichiers par
> torrents, atteignant 1.4 méga.
>
> Des tests ont été effectués, en bridant notre QoS à 1.080 méga, pour le même
> résultat.
> Il est apparu qu'à environ 800kbit/s, nous n'avions plus de problèmes.
>
> Le débit maximal mesuré, lui, allait jusqu'à environ 1.75 méga
>
> Le support d'OBS m'a tenu ce raisonnement :
> -La ligne est une ligne 2 mégas - l'overhead ATM = 1.6 méga
> -Il faut y retrancher 200 kbit/s utilisés pour la téléphonie, soit 1.4 méga
> -Il faut minorer ce débit pour laisser passer les ack TCP.
>
> J'aurais donc 2 questions :
> 1) De combien est-il habituel de réduire le débit dans ce genre de cas ? Lors
> de la mise en place de la QoS, j'avais lu entre 5 et 10%. Passer de 1.4 méga
> à
> 800kbit, c'est plutôt de l'ordre de 40%...
> 2) Quand on regarde le MTR, on s'aperçoit que la latence ne vient pas de la
> ligne elle-même, mais du troisième routeur chez Orange. OBS m'a dit que
> c'était normal ("tous nos routeurs ne vont pas à la même vitesse") Est-ce que
> ce comportement est réellement justifié, ou est ce que c'est de la mauvaise
> foi de leur part ? Pourquoi la latence n'apparaitrait qu'une fois dans
> l'infra
> Orange ?
>
> PS : ce problème n'a _rien_ à voir avec le fait que nous soyons 150, les
> tests
> ont été menés avec un seul utilisateur.
>
> Merci d'avance pour vos réponses,
> Cordialement,
> Grégoire Leroy
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
--
Pierre Jaury +33(0)1.83.64.80.90
Réalisateur, hébergeur et infogéreur indépendant
Internet hosting, outsourcing and development as a freelancer
signature.asc
Description: This is a digitally signed message part
Re: [FRnOG] [TECH] Pertes et latence importantes
Je ne vois pas ce que vient faire l'argument d'un overhead TCP si tu
fais ta mesure en amont. Quels types de mesures ont été effectués ? vous
avez une idée du débit/latence vers plusieurs AS en raw IP ?
Du reste, ça sent (au moins en partie) le foutage de gueule ; curieux de
connaître la véritable raison lorsque vous aurez élucidé. Et quitte à
avoir plusieurs lignes, autant multiplier les opérateurs, non ?
On Wed, 2011-12-28 at 13:27 +0100, Grégoire Leroy wrote:
> Bonjour à tous,
>
> Je suis étudiant à TELECOM Lille1, et j'ai repris le réseau d'une certaine
> résidence de 150 utilisateurs derrière 2 lignes ADSL et une ligne SDSL (chez
> Orange).
>
> Étant donné que nous avons régulièrement des pertes et une latence très
> importante, j'ai effectué quelques tests et contacté Orange Business Services.
>
> Test : http://bpaste.net/show/21180/
>
> Un seul utilisateur était connecté et téléchargeait 2 ou 3 fichiers par
> torrents, atteignant 1.4 méga.
>
> Des tests ont été effectués, en bridant notre QoS à 1.080 méga, pour le même
> résultat.
> Il est apparu qu'à environ 800kbit/s, nous n'avions plus de problèmes.
>
> Le débit maximal mesuré, lui, allait jusqu'à environ 1.75 méga
>
> Le support d'OBS m'a tenu ce raisonnement :
> -La ligne est une ligne 2 mégas - l'overhead ATM = 1.6 méga
> -Il faut y retrancher 200 kbit/s utilisés pour la téléphonie, soit 1.4 méga
> -Il faut minorer ce débit pour laisser passer les ack TCP.
>
> J'aurais donc 2 questions :
> 1) De combien est-il habituel de réduire le débit dans ce genre de cas ? Lors
> de la mise en place de la QoS, j'avais lu entre 5 et 10%. Passer de 1.4 méga
> à
> 800kbit, c'est plutôt de l'ordre de 40%...
> 2) Quand on regarde le MTR, on s'aperçoit que la latence ne vient pas de la
> ligne elle-même, mais du troisième routeur chez Orange. OBS m'a dit que
> c'était normal ("tous nos routeurs ne vont pas à la même vitesse") Est-ce que
> ce comportement est réellement justifié, ou est ce que c'est de la mauvaise
> foi de leur part ? Pourquoi la latence n'apparaitrait qu'une fois dans
> l'infra
> Orange ?
>
> PS : ce problème n'a _rien_ à voir avec le fait que nous soyons 150, les
> tests
> ont été menés avec un seul utilisateur.
>
> Merci d'avance pour vos réponses,
> Cordialement,
> Grégoire Leroy
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
--
Pierre Jaury +33(0)1.83.64.80.90
Réalisateur, hébergeur et infogéreur indépendant
Internet hosting, outsourcing and development as a freelancer
signature.asc
Description: This is a digitally signed message part
Re: [FRnOG] [TECH] Pertes et latence importantes
On Wed, 28 Dec 2011 13:27:21 +0100, Grégoire Leroy wrote:
Bonjour à tous,
Bonjour.
Le support d'OBS m'a tenu ce raisonnement :
-La ligne est une ligne 2 mégas - l'overhead ATM = 1.6 méga
-Il faut y retrancher 200 kbit/s utilisés pour la téléphonie, soit
1.4 méga
-Il faut minorer ce débit pour laisser passer les ack TCP.
En fait la téléphonie c'est 25 kbits/s par canal H323, et 80 par canal
SIP. Tout dépend de ton codec voix et du nombre de canaux.
J'aurais donc 2 questions :
1) De combien est-il habituel de réduire le débit dans ce genre de
cas ? Lors
de la mise en place de la QoS, j'avais lu entre 5 et 10%. Passer de
1.4 méga à
800kbit, c'est plutôt de l'ordre de 40%...
2) Quand on regarde le MTR, on s'aperçoit que la latence ne vient pas
de la
ligne elle-même, mais du troisième routeur chez Orange. OBS m'a dit
que
c'était normal ("tous nos routeurs ne vont pas à la même vitesse")
Est-ce que
ce comportement est réellement justifié, ou est ce que c'est de la
mauvaise
foi de leur part ? Pourquoi la latence n'apparaitrait qu'une fois
dans l'infra
Orange ?
Envoyez moi les références de la ligne par mail , je regarde ce que je
peux faire.
Cordialement.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
