Messages

Et pour info quel équipement utilisez vous pour regarder le contenu ? Tv connectée ? PC connecté a la TV ? Tv + smartphone/tablette + chromecast ? Smartphone ? Tablette ? Écran de PC ?

Partage de fichiers. Tu as la partie légale, et la partie illégale des choses.

Mon dieu, Usenet c'est un peu plus que ça quand même. Dans mon jeune temps, on s'en servait surtout comme ce que vous appelez un réseau social. L'avantage étant que les outils pour l'utiliser étaient amha bien plus utilisables qu'un naviguateur.

Et pour ce qui est du contenu, je suis sur qu'Optix fournit big8 en plus de alt.* si cher au coeur des Djeunz.

Arnaud, qu'est ce qui peut dégrader une liaison fibre ? Un coup de pelleteuse ?

Hummmm c'est embêtant de le formuler comme ça, mais j'aurais presque préféré un coup de pelleteuse bien franc, bien net. L'opérateur d'infra à qui nous louons la fibre noire
impose une multitude de jarretière dans son réseau de dark. Du coup, il peut s'être crée une contrainte a peu prêt n'importe ou sur les 25km de linéaire entre LB et TH2. Sans reflectométrie on n'en saura clairement pas plus.

Maintenant, vue le temps de coupure de service que ça implique, je préfère tester de monter d'un cran la puissance des optiques pour voir ce que ça donne avant de lever un ticket chez eux (ce qui impliquera obligatoirement de multiples coupures de services puisqu'ils seront obligés de faire de multiples reflecto pour localiser précisément le problème.).

Pour info on atteint les 22db d'atténuation sur ce lien de 25km, les connaisseurs apprécierons la performance du presque db d'atténuation par kilomètre qui ne nous aide pas vraiment

Quand est-ce qu'on aura plus d'info SVP ?

Les optiques ont été commandés il y a une bonne semaine maintenant. Notre fournisseur manquait d'approvisionnement sur ce modele particulier (bi directionnel et 10G et tres forte puissance). Dès reception nous vous informerons de la date d'intervention qui impliquera bien sur une coupure du lien le temps du remplacement par nos équipes techniques a chaque extrémité.

Il est a noter que ce lien de 22km est allumé actuellement avec des optiques de 40km qui se révèlent un peu juste s. Je pense que le câble a du prendre récemment une contrainte supplémentaire sur le chemin augmentant son niveau d'atténuation.  Le remplacement des optiques de production par les optiques de spare n'ont pas resolu le problème.

La pub knet pour marquer son opposition a la pub je ne sais pas mais j'ai comme un doute 

[ip route add default dev ethXX]

Comment peux-tu m'aider afin que cela fonctionne ? Pour trouver d'ou vient le problème ?

Merci d'avance de ton retour.

La réponse a déjà été donnée par Jack notamment. Si cela ne fonctionne pas, c'est très probablement parce que l'équipement que vous utilisez ne comprend pas ce qu'il
doit faire avec les informations que l'on lui donne.

Plusieurs informations sont nécessaires pour que vous puissiez vous en sortir.

  - L'utilisation du DHCP est une obligation. Si vous ne l'utilisez pas, ça ne fonctionnera pas.
  - le bail DHCP qui vous est envoyé peut ne pas être compris par votre équipement. S'il s'agit d'un PC (peut importe l'OS) il est assez étonnant qu'il ne s'en sorte pas. Cependant vous pouvez toujours en post traitement du bail que vous avez reçu forcer la default gateway sur l'interface ethernet qui vous raccorde a la Kbox.
  - la gateway ne peut pas répondre à l'ICMP.

Le plus important est que vous forciez le trafic a sortir par la bonne interface, on se moque pratiquement de l'adresse IP de la passerelle, de toutes façon le trafic lui sera remonté. Le reste est affaire d'ARP et de mécanismes particuliers dans le réseau de collecte de la plaque locale. Sous linux un ip route add default  dev ethXX devrait suffire

Je n'ai aucune espèce d'idée du type d'équipement que vous cherchez a connecter derrière la Kbox, mes réponses sont donc limitées .

Bon on va calmer le jeu, c'était distrayant quelque temps, mais je vous demande de respecter mes collaborateurs de faire attention a l'écrit si ce n'était pas votre intention, le ton d'un post  est souvent mal interprété.

Pourquoi tu mélanges IP et MAC dans ton explication ? Tu n'es pas sur la même couche OSI...
OSI ça te parle ?

OSI nous parle assez bien, mais vous placez une frontière stricte là ou un ensemble de fonctionnalités sont utilisées. Je n'ai pas, et ne vais pas, détailler précisément le fonctionnement
de notre réseau, simplement envoyer un paquet en dehors de votre subnet n'est jamais un problème du moment que le paquet arrive a la dite destination.

As-tu déjà fait personnellement ce test de bridge, je me pose des questions ?

Oui. et d'ailleurs peut importe que ce soit derrière la K-Box ou pas vu que c'est un pont. Le Bridge ne fait QUE fournir sur les ports du switch une continuité L2 entre le réseau DATA et votre LAN.

Si la Kbox s'en sort, s'est bien que cela fonctionne.

Le lance un téléchargement en torrent (ça débite pas mal, 10mb/s environ).
Deux minutes plus tard... la TV saccade complètement, l'image se fige...
Je coupe le torrent : 2 minutes après image nickel.

Oui le lien optique entre l'abonné et le NRO est un lien Fast Ethernet (100 Mbps) Full duplex (dans les 2 sens) donc la vitesse de votre téléchargement a clairement impacté la bande passante réservée pour la télévision. C'est donc bien ça la cause du problème rencontré. MAIS, il y'a un mais sinon je ne posterais pas, les flux TV sont censé être marqués pour disposer d'un traitement prioritaire (du moins ils le sont dans la collecte) donc de fait le switch qui vous collecte aurait du « déprioriser » le trafic P2P pour prioriser le trafic UDP (Télévision).

En effet, coté télévision, il n'y a pas de réémission du paquet envoyé, du coup il est impératif de le prioriser sur le réseau pour s'assurer d'une bonne qualité. 

On va prendre contact avec l'ingenierie du SIEA pour tracker ce bug et on vous tiendra au courant.

Demandez lui de nous contacter, ou qu'il contacte damien directement sur ce forum. Il fera le nécessaire.

typiquement parceque pas mal de device mobile n'ont pas d'implémentation igmp vraiment fonctionnelle, ce qui est un sérieux soucis, et surtout parceque pas mal de gens dans des environnement 802.11 polués se retrouve a bêtement et simplement perdre des paquets. Du coup, utiliser TCP dans ce cas, c'est tout de meme assez pratique.

pour le moment il faut que vous soyez sur des subnet differents. A voir si votre voisin accepte d'etre renuméroté.

coté SIEA, il me semble avoir vu passé dans un mail récemment ou il était question de mise en place des méchanismes nécessaires pour traiter ce genre de problème d'ARP. Par contre je pense que ce va etre traité plaque / plaque.

Vous êtes tous les deux dans la zone pilote ?

Globalement c'est ce que dit Frank. Quand on trace la requete (dig +trace titi pour info) tu vois bien que les root server DNS répondent correctement.

Par contre lorsqu'il s'agit d'aller parler aux serveurs autoritaires de la zone, impossible vu qu'il y'a un problème de route (que ce soit en v4 ou v6).

Du coup, pas moyen pour les resolvers de demander la définition de la zone et donc de la servir, CQFD.

Pourquoi est ce que les resolvers de google s'en sortent ? Très probablement parceque google dispose d'un PNI avec Telefonica et que donc dans leurs cas a eux, il y'a une route qui répond correctement.

Ce n'est donc pas un problème sur les DNS de K-Net, mais bien un problème de réseau. Le DNS qui ne répond n'est qu'un symptôme du problème, mais pas plus qu'un symptôme. Ce n'en est certainement pas la cause.

Sans vouloir médire titi (tu sais que ce n'est pas mon genre) de mon test de là tout de suite ils répondent bien la même chose

par contre très clairement, et là j'ai beaucoup beaucoup de mal a comprendre comment ils arrivent a ce miracle, on arrive a constater 2 comportement différents au niveau IP pour
joindre cette destination depuis 2 machines dans le même subnet et routé par la même passerelle chez nous (oui le comportement totalement irrationnel).

De fait, j'ai testé depuis d'autre réseau que le réseau K-Net et j'ai curieusement le même résultat. Donc non pas un problème de DNS mais clairement un souci coté IP chez Mediaways (ca se prononce telefonica DE).

Il semblerait que pas mal de monde remonte ce souci sur le réseau DE de telefonica.

Du peu de looking glass que l'on ai pu trouver sur leur réseau, ça semble effectivement pas glorieux. Plein de routes visiblement désapprises par une partie de leur réseau.

Du coup, j'aurais plutôt tendance a penser qu'il y'a un soucis sur la voie retour ce qui explique bien des choses sur le comportement des réponses DNS.

On va ouvrir un ticket chez Telefonica et on vous tiendra au courant si l'on a une réponse.

Alors ça c'est distrayant :

http://www.arcep.fr/index.php?id=26 cliquer sur le lien :  « 1er octobre 2013 /MARCHÉ FIXE »

MARCHÉ FIXE

L'ARCEP tient à souligner le caractère partiel et parfois inexact des annonces de Free concernant ses offres à très haut débit fixe

notamment :

L'ARCEP constate que la communication effectuée aujourd'hui par le groupe Iliad sur ses offres à très haut débit fixe à destination du grand public annonce des performances qui sont de nature à induire en erreur les utilisateurs sur le service que va leur apporter leur FAI.

et

S'agissant de la promesse d'un débit " dédié " de 1Gbit/s pour la fibre, l'ARCEP ne peut que souligner le caractère partiel de l'information donnée aux utilisateurs. En effet, le service offert aux utilisateurs est tributaire non seulement du dimensionnement du réseau d'accès sur lequel Free communique aujourd'hui, mais dépend aussi du dimensionnement de l'ensemble de son infrastructure (collecte, interconnexion...). A titre d'exemple, comme l'avait révélé l'enquête administrative menée par l'Autorité sur les relations entre YouTube et Free (communiqué du 19 juillet 2013), et sauf à ce que Free ait massivement investi, en août et septembre 2013, dans l'amélioration de ses capacités d'interconnexion, ses annonces de ce jour ne correspondent pas à l'expérience des utilisateurs qui visionneront des vidéos en ligne.

Étonnant non ?

[@Frank]

@Frank : on a décidé de tout faire pour ne pas avoir a vous renuméroter. Attention par contre, on a plusieurs phases a valider avant la mise en prod :

• le bon fonctionnement d'IPV6 sur notre firmware
• l'interop SI / Routage
• l'interop Panel client / SI

tout cela prend plein du temps pour le faire correctement.