OVH Community, votre nouvel espace communautaire.

Débit / connectivité variant selon site et protocole / port utilisé


stevebrush
22/01/2014, 12h44
alors, une piste m'a été donnée sur la mailing liste :

ip config defragmode disabled
ip config ipv6defragmode disabled
ip config fraglimit 256
ip config ipv6fraglimit 256

j’ai réactivé la qos, saveall, redémarré et ça l’air d’aller mieux, je vais voir dans le temps...

helcaraxan
18/01/2014, 15h13
Bon les résultats de mes essais :

- J'ai bien un TG788vn V2, les ports Ethernet sont jaunes.

- La QoS éteinte semble améliorer la stabilité de mes connexions SSH sortantes et entrantes. Pour le HTTPS il faut que je l'essaie d'ailleurs, ce sera fait dès lundi. Si cela semble en effet résoudre mes soucis je ne compte pour autant pas m'en arrêter là car il reste bien le soucis de la téléphonie (qu'on aimerait bien faire passer en priorité). Du coup je vais me plonger un peu dans la configuration de la QoS par l'intermédiaire du Telnet. Je pense qu'il est bien possible de garder la QoS tout en ajoutant des reglès de filtrage pour donner une priorité plus importante aux connexions qui souffrent de la QoS de base. Si cela réussit comme je le veux je ferais un petit tutoriel sur le sujet.

Reste à contacter le support pour la reconstruction de la ligne en oubliant SFR en troisième larron, j'y vais de ce pas.

Bon weekend à tous !

stevebrush
17/01/2014, 15h04
j'ai eu dans l'ordre un tg784, tg788vn et maintenant tg788vn V2.

je n'ai jamais été embêté avec les autres à ce niveau, j'ai un ticket d'ouvert, j'attends des réponses du support... je posterai ici si une solution m'est donnée.

helcaraxan
17/01/2014, 14h56
Je suppose oui. Je ne l'ai pas sous la main là donc faudra que je confirme. Mais sachant que je suis nouvel abonné et qu'on vient de me l'envoyer je suppose que c'est bien la V2.

stevebrush
17/01/2014, 14h53
c'est bien un tg788vn V2 (pas de port gigabit wan rouge) ?

helcaraxan
17/01/2014, 14h40
J'avais déjà hésité en lisant le post en question pour savoir si c'était bien le même cas que pour moi.
Ce soir je vais essayer de désactiver la qos pour voir le résultat. Niveau mtu j'ai déjà fait des tests extensifs et cela n'a rien donné. Dès que j'ai un retour je le dirais ici.

En supposant que c'est bien l'origine des soucis je vais sérieusement réfléchir à m'acheter mon modem perso pour avoir la qos tout en ayant des connexions fonctionnels vers mon NAS.

Puis faudra que je contacte le service pour obtenir une reconstruction de la ligne pour collecte par Orange au lieu de SFR. Le réengagement demandé n'est peut-être pas au sommet d'un service client mais dans mon cas je m'en fous je viens de démarrer l'abonnement et si le reste fonctionne je veux bien m'engager pour 1 an .

stevebrush
17/01/2014, 01h25
Bonsoir, j'ai aussi ce souci.
Il semble que le nouveau modem tg788vn V2 a des problèmes de mtu ou qos : J'ai désactivé le qos et plus de problèmes pour ce forum ou ssh, scp, rsync via ssh...
mais par contre, plus de qos=téléphone qui marche mal si j'ai un download ou upload en cours. (voir post http://forum.ovh.com/showthread.php?...on-SSH-Dedi%E9)

Gaston_Phone
16/01/2014, 22h14
La solution --> Prière du connecté .

helcaraxan
16/01/2014, 22h12
Je suis bien d'accord. Malheureusement.

Cependant comme l'indique le test avec les copies avec scp la connexion est carrément coupée dans ce genre de situation, ce n'est plus du bridage...

laurentm
16/01/2014, 22h07
C'est plus facile de citer les FAI qui ne brident pas les ports (OVH dégroupé, Orange pro, Nerim, + autres FAI pros) que ceux qui le font, tellement il y en a !

helcaraxan
16/01/2014, 13h07
Comme je l'ai indiqué il semblerait que ma collecte soit effectivement faite par SFR (vu que le service indiqué sur le modem est "ldcom" et que cela correspond à SFR.

Même si cela peut tout à fait expliquer (plus que probable) la baisse du débit théorique de 17Mbps affiché par le modem vers les 4Mbps pratique cela ne peut "normalement"(1) pas expliquer les différences entre les connexions avec protocole ou port différent.

Bref, en utilisant le principe du rasoir d'Ockham inversé (copyright à moi-même), vu qu'il n'y a que des explications compliqués ou inexistantes il doit y avoir une explication plus simple.

---
(1) A moins de faire du DPI et ça Oui SFR le pratiquerait peut-être pour du mobile mais pas de preuves concrètes mais de là à passer sur le réseau ADSL... qui plus est sur les bords de leur réseau avant l'acheminement jusqu'à OVH. Cela me semblerait même irréaliste d'un point de vue pratique.

laurentm
16/01/2014, 10h51
Ca sent la collecte IP avec bridage infâme de chez SFR... ou je me trompe ???

helcaraxan
16/01/2014, 10h37
Bonjour,

Je suis nouveau client chez OVH et j'en suis donc encore en phase de "reglages" pour que tout fonctionne comme je le veux. J'héberge mon NAS derrière ma connexion ADSL et j'ai donc une flopée de services et ports que j'utilise.
Malgré une certaine expérience en réseau du point de vue théorique et pratique je suis à court d'idées pour l'instant face aux phénomènes et soucis rencontrés.

Avant toute chose : je n'ai aucun problème de connectivité en général, ma ligne physique semble très bien fonctionner, pas d'atténuation (normal c'est une ligne dans un logement nouvellement construit), pas de désync ou autre désordre de signal.

Connexion intérieur -> Internet : en navigant depuis mon PC branché en Ethernet ou connecté en Wifi sur le routeur TG788VN fourni.
---
Débit constant au cours de la journée : 4,5 Mbps / 800kbps fait par des speed-test multiples vers USA, Europe & France.
Le modem lui indique un débit théorique de 17Mbps/1Mbps (la chute du down par rapport théorique serait peut-être dû à la collecte non-OVH de mon NRA, il semblerait que ce soit SFR dont on mentionne tant les soucis sur le forum). Mais ce n'est pas le point qui me gène le plus...

Navigation vers divers sites OK (lemonde.fr, kernel.org, ...) mais au même instant la navigation vers le site et le forum OVH est quasi-impossible : page ne se chargeant pas ou alors tout à coup après 15 secondes d'attente, bizarre pour une connexion vers le FAI lui-même.

Navigation vers mon NAS sur le réseau interne : parfait, aucun défaut, tous les services sont joignables et fonctionnels.
---

Connexion Internet -> intérieur : connexion au NAS depuis divers endroits externes (FAI différents, routage différents, etc...)
---
Configuration du modem TG788VN : les bons ports ont été ouverts et redirigés vers le NAS et le pare-feu est en niveau normal

Connexion au site web en HTTP : chargement rapide et sans accroc, même les photos et autres téléchargements lourds passent au débit d'envoi maximal constaté par speedtest.

Connexion au site web en HTTPS (ports 443 et autres pour l'interface de gestion du NAS) : chargement lent, qui ne termine pas 9 fois sur 10. Si par chance j'arrive à rentrer sur le service de partage de fichiers et que j'arrive à lancer un téléchargement celui-ci se fait au débit d'envoi maximal constaté par speedtest. En essayant de récupérer les mêmes pages et objets par wget cela marche pourtant parfaitement.

Connexion par SSH : la connexion foire 2 fois sur 3 mais une fois établi elle arrive à se maintenir un peu (en moyenne 1 min avec plusieurs commandes envoyés), quand elle s'interrompt ce n'est pas une déconnexion TCP standard, mon ordinateur attend simplement les retours des commandes qui n'arrivent pas.

Transfert de fichier par SCP : envoi vers l'ordinateur distant lent (1/4 du débit d'envoi maximal), envoi vers le NAS impossible (l'envoi se bloque toujours après avoir transféré entre 100 et 200 ko).

Fichiers par GIT+SSH : les git-push se bloquent tous à la phase d'écriture distante (pas de problème de débit ici : j'utilise la bande-passante descendante...), les git clone & co se passent bien mais à débit réduit (1/4... normal, on fait du scp comme ci-dessus).
---

J'aimerais encore refaire les mêmes tests avec un autre modem mais je n'en ai pas encore à ma disposition.