Lenteur au démarrage

[10352-JPFE]

Bonjour

J'ai eu l'installation d'un nouveau boîtier (je ne connais pas le nom, c'est celui entre la prise et le modem) il y a qqs mois. Depuis j'ai un problème de lenteur pour lancer certains médias. Le débit reste bon et est même je pense meilleur qu'avant mais c'est le lancement des médias qui posent souci : par exemple il faut plusieurs (10-15-30) secondes pour que la vidéo (et parfois même une simple image) sur twitter se lance. Ca charge et ça mouline dans le vide puis ça finit pas se lancer. J'avais ça sur mon Samsung GS7 et maintenant sur mon Xiaomi Redmi Note 8. Si je coupe le wifi et que je me connecte en 4G ça lit le média de manière instantanée. De la même manière, je n'arrive plus à lire du media via ma télé LG sur l'application molotov

Quelqu'un a-t-il déjà eu ces pbs ?

Merci

[Vincent O]

Essayez de désactiver l'IPv6

[10352-JPFE]

Bonjour

Parfait, c'est bien ça ! Désactiver l'ipv6 dans les paramétrages du routeur a supprimé la latence pour lancer les médias et faire la même chose sur ma TV a permis de lancer les flux médias molotov !

Merci !!

[Fyr]

Essayez de désactiver l'IPv6

IPv6 le maillon faible de K-Net.

[thedark]

Essayez de désactiver l'IPv6

IPv6 le maillon faible de K-Net.

Maillon faible des OI (Depuis 2016 aucun souci)
https://pix.milkywan.fr/vVxhWL1d.png

[Steph]

IPv6 le maillon faible de K-Net.

De SFRFTTH exCovage ex Tutor pour ce qui me concerne.
Je ne sais pas quelle pression peut mettre K-net sur un Covage.
Quand on voit le temps que prend une activation Covage, cela laisse rêveur...

[gillejeu]

IPv6 le maillon faible de K-Net.

De SFRFTTH exCovage ex Tutor pour ce qui me concerne.
Je ne sais pas quelle pression peut mettre K-net sur un Covage.
Quand on voit le temps que prend une activation Covage, cela laisse rêveur...

Sur ce coup, Covage n'est pas seul. Je suis sur un réseau Altitude infra et pas d'IPv6 non plus.

[albert91]

IPv6 le maillon faible de K-Net.

De SFRFTTH exCovage ex Tutor pour ce qui me concerne.
Je ne sais pas quelle pression peut mettre K-net sur un Covage.
Quand on voit le temps que prend une activation Covage, cela laisse rêveur...

Il sera intéressant de voir la vitesse de remise en route de l'IP V6 en liaison avec l'arrivée des grands FAI sur chaque réseau pour mesurer la différence de pression entre les petits FAI et les gros.
L'IP V6 fonctionnait sur le réseau Tutor, actuellement SFR FTTH, les installations de Covage ne laisse pas passer les requêtes DHCP IP V6 jusqu'aux serveurs de K-net, à moins que le futur fonctionnement soit fondé sur des serveurs DHCP gérés par l'OI.
De la à lier la vitesse de rétablissement de l'IP V6 à la vitesse de réparation d'une fibre cassée chez un abonné, il n'y a qu'un pas....
Wait and see !

[thedark]

Il sera intéressant de voir la vitesse de remise en route de l'IP V6 en liaison avec l'arrivée des grands FAI sur chaque réseau pour mesurer la différence de pression entre les petits FAI et les gros.

Encore une fois, les OCEN ne seront pas dépendant de Covage.(Location de fibre noires) Donc il pourront avoir de l'IPV6 sur leur infrastructure même si Covage n'est pas compatible IPV6

IPv6 le maillon faible de K-Net.

De SFRFTTH exCovage ex Tutor pour ce qui me concerne.
Je ne sais pas quelle pression peut mettre K-net sur un Covage.
Quand on voit le temps que prend une activation Covage, cela laisse rêveur...

Sur ce coup, Covage n'est pas seul. Je suis sur un réseau Altitude infra et pas d'IPv6 non plus.

Altitude c'est un peu différent de Covage
https://forum.caps.services/index.php/topic,6140.msg91566.html#msg91566

[Fyr]

Maillon faible des OI (Depuis 2016 aucun souci)

Et bah je me sens moins privilégié que toi sur leur excellence technique Sur fin juillet - debut novembre (on va dire 3 mois : aout septembre octobre) 1 mois de coupure v6 totale. Mais c'est pas ça le pire :
1 - bullshit complet du support, quand y a une réponse.
2 - absence totale de prise en compte des incidents. J'ai clôturé 4 tickets âgés de 30 à 45 jours sans réponse, à part le robot. Y en a un autre moins âgé c'est retombé en marche pas eu de réponse non plus.
3 - pour être exhaustif sur le sujet, au phone j'ai eu un interlocuteur courtois et pro qui était très demandeur d'être formé il se sentait un peu dépassé par le truc. Perso je préfère entendre "je ne sais pas", que rien du tout ou prétendre que oui.
4 - là je tourne avec un tunnel MilkyWan, qui marche bien grâce à la bonne qualité du v4 K-Net et la richesse des intercos/peering (no kidding) Le tunnel des Ukrainiens de NetAssist marche bien mais Netflix, sans te couper, te propose un catalogue plus .. exotique. HE ils filtrent le port 25 donc contre-indication totale pour mon serveur de mail.

Accessoirement si les OI sont largués, les FAI peuvent se monter des tunnels IPv6 dans de l'IPv4 avec leurs box, s'ils ont pris de "bons" modèles... ou ils font faire un firmware idoine...  Donc l'argument "c'est la faute à l'opérateur d'infra" c'est un peu light ou raccourci. Sachant qu'à la base je répondais à Vincent O qui conseillait de couper le v6 dans une box, ce que je peux entendre, mais là j'ai des signaux (ils l'ont coupé chez le voisin, m'ont conseillé de le faire...) qui me disent que c'est du systémique au lieu de l'exceptionnel.

Donc y a le v4 qui tourne bien, les peerings y a pas à rougir, la partie backbone ça ronronne. V6 ca flappe quand l'OI le propose + support pas à l'aise sur le sujet.

[Vincent O]

V6 ca flappe quand l'OI le propose

Y'en a très peu qui le supporte vraiment.

* SIEA, pas de support officiel, et on voit des bugs très "exotiques". Exemple :

Je me connecte sur la passerelle IPv6 utilisée pour les clients SIEA, et j'essaye de ping 2600:9000:2190:ae00:1b:d7a6:ee00:93a1 et vers 2600:9000:2190:ae00:1b:d7a6::. Les deux marchent.
Je lance un tcpdump sur la passerelle, je me connecte sur plusieurs routeurs de clients et lance des pings vers les mêmes IP. On voit bien passer les paquets ICMP vers 2600:9000:2190:ae00:1b:d7a6::, mais aucun n'arrive pour  2600:9000:2190:ae00:1b:d7a6:ee00:93a1. Ils se perdent quelque part chez le SIEA, avant même d'arriver à la porte de collecte.

Ce n'est pas donc pas une route manquante comme vous le pensiez, vu que les deux IP sont dans la même route (on reçoit une route avec le préfixe 2600:9000:2190::/48 par Cogent à Genève).

Bref, si une MTU plus faible ne vous gêne pas et que vous avez besoin d'IPv6, je vous conseille effectivement un tunnel.

* Covage L3 : pas supporté, même si ça marchait dans le passé. Et il y a clairement un bug avec leurs BNG. On ne reçoit aucune requête DHCPv6 pendant des jours / semaines, puis d'un coup le BNG décide d'en envoyer des milliards d'un coup...

*  Tutor L2 : ça marche, mais ça se fait migrer petit à petit en Covage.

* Altitude : leurs BNG perdent aléatoirement les routes vers les préfixes délégués.

* Axione : ça a l'air de marcher, hormis le fait que leurs BNG ne répondent pas aux requêtes NS en multicast (seulement en unicast), ce qui pose problème à certains routeurs qui après avoir reçu le RA vont redemander en NS la MAC de la gateway, et peuvent prendre un peu de temps avant d'essayer de faire les requêtes en unicast.

Sachant qu'à la base je répondais à Vincent O qui conseillait de couper le v6 dans une box, ce que je peux entendre, mais là j'ai des signaux (ils l'ont coupé chez le voisin, m'ont conseillé de le faire...) qui me disent que c'est du systémique au lieu de l'exceptionnel.

Dans le cas de 10352-JPFE, il est passé d'une collecte Tutor à une collecte Covage, et les symptômes sont très classiques du problème ("ça met 20s à charger une page chez Google / Youtube / Facebook / Twitter, mais le reste marche"). Mais je suis d'accord que le support le coupe trop systématiquement, on leur fait régulièrement la remarque.

[Xynor]

bonsoir,

Ouais, enfin pour K-Net/Altitude, il serait plus juste de noter "* Altitude : rien..." :

Code Sélectionner Étendre

20:00:43.608024 IP6 (hlim 1, next-header UDP (17) payload length: 109) fe80::xxxx:xxxx:xxxx:xxxx.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit
(xid=816aab (client-ID hwaddr/time type 1 time 627567776 xxxxxxxxxxxxxx) (IA_NA IAID:0 T1:0 T2:0) (rapid-commit) (elapsed-time 6963)
(option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/56 pltime:4294967295 vltime:4294967295)))

aucune réponse

[Fyr]

Ce n'est pas donc pas une route manquante comme vous le pensiez, vu que les deux IP sont dans la même route (on reçoit une route avec le préfixe 2600:9000:2190::/48 par Cogent à Genève).

C'est le pb des analyses le 06/01/2020, pas fin octobre

Bref, si une MTU plus faible ne vous gêne pas et que vous avez besoin d'IPv6, je vous conseille effectivement un tunnel.

Avec un uptime de 24 heures, et un ratio 1/3 en nombre de paquet ipv6/ipv4, stats de l'interface du tunnel :

Code Sélectionner Étendre

ip6 on gif0:
14045564 total input datagrams
0 datagrams with invalid header received
1508 datagrams exceeded MTU received
0 datagrams with no route received
0 datagrams with invalid dst received
0 datagrams with unknown proto received
0 truncated datagrams received
337 input datagrams discarded
1504079 datagrams delivered to an upper layer protocol
7657261 datagrams forwarded to this interface
1520842 datagrams sent from an upper layer protocol
1614 total discarded output datagrams
0 output datagrams fragmented
0 output datagrams failed on fragment
212 output datagrams succeeded on fragment
0 incoming datagrams fragmented
0 datagrams reassembled
0 datagrams failed on reassembly
0 multicast datagrams received
6 multicast datagrams sent


icmp6:
1753 calls to icmp6_error
0 errors not generated in response to an icmp6 message
0 errors not generated because of rate limitation
Output histogram:
unreach: 243
packet too big: 1508.    <= ca vient du forward LAN -> tunnel
time exceed: 2
echo reply: 256
router advertisement: 312
neighbor solicitation: 7599
neighbor advertisement: 6144
MLDv2 listener report: 12
0 messages with bad code fields
0 messages < minimum length
0 bad checksums
0 messages with bad length
Input histogram:
unreach: 1449
echo: 256
MLDv1 listener done: 2
router solicitation: 41
router advertisement: 312
neighbor solicitation: 6144
neighbor advertisement: 6774
Histogram of error messages to be generated:
0 no route
0 administratively prohibited
0 beyond scope
220 address unreachable
23 port unreachable
1508 packet too big
2 time exceed transit
0 time exceed reassembly
0 erroneous header field
0 unrecognized next header
0 unrecognized option
0 redirect
0 unknown
256 message responses generated
0 messages with too many ND options
0 messages with bad ND options
0 bad neighbor solicitation messages
0 bad neighbor advertisement messages
0 bad router solicitation messages
0 bad router advertisement messages
0 bad redirect messages
0 path MTU changes      <= aucun



=> réponse : non. MTU 1280 par défaut.

Et vu la colique globale vous aussi avez besoin de tunnel (ou du 6rd ? réseaux trop hétérogènes ?).  Une fois le dhcpv4 accordé le montage de tunnel v6 pose plus trop de soucis, vous avez la pleine maitrise de la box. Franchement, papotez avec les ingés Icotera, une feature tunnel ipv6 risque d'être apprécier worldwide. Apparement y a deja les features DHCPv6 pour choper l'ip d'interco et la délégation du préfixe, ou y a une conf statique poussée au démarrage  ? Les concentrateurs en face, y a pas de crypto ca bouffera rien en CPU ca simplifie les déploiements/provisioning et vous en finissez avec le patacaisse IPv6. Vous devenez indépendants des pires outrages et sévices des OI sur la partie v6, sachant que le socle v4 pour monter les tunnels est plutôt solide.

Pour 10352-JPFE c'est pour ça que j'ai mis "ce que je peux entendre"

[Fyr]

bonsoir,

Ouais, enfin pour K-Net/Altitude, il serait plus juste de noter "* Altitude : rien..." :

Code Sélectionner Étendre

20:00:43.608024 IP6 (hlim 1, next-header UDP (17) payload length: 109) fe80::xxxx:xxxx:xxxx:xxxx.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit
(xid=816aab (client-ID hwaddr/time type 1 time 627567776 xxxxxxxxxxxxxx) (IA_NA IAID:0 T1:0 T2:0) (rapid-commit) (elapsed-time 6963)
(option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/56 pltime:4294967295 vltime:4294967295)))

aucune réponse

Ca me fait pareil mais sur le SIEA, et j'ai testé avec 2 DHCPv6 différents (le ISC et le KAME) et testé aussi de demander un /64 au lieu d'un /56 (apparement y a un /56 alloué dans les papiers mais y a qu'un /64 utilisable/délégué de ce que j'ai cru comprendre à la lecture du forum) Et pas plus que la vision du début de l'ombre d'un RA pour choper la route par défaut (qui est hors scope DHCPv6) Y compris en mettant l'option rfc6204w3 pour faire accepter les annonces de RA à un routeur IPv6 qui est censé les ignorer.

[Vincent O]

Ca me fait pareil mais sur le SIEA

Pas de DHCPv6 sur les réseaux L2, on fait du statique. Par contre, sur Altitude, c'est du DHCPv6.