La Fibre
Télécom => Réseau => IPv6 => Discussion démarrée par: oyaji le 07 février 2014 à 00:40:38
-
Intéressant : j'ai le même problème (téléchargement depuis un OVH Kimsufi vers chez moi à 5 Mo/s au lieu des habituels 10~11 Mo/s) à ceci près qu'il ne concerne uniquement les transferts en IPv6.
Transferts via rsync sur un montage SSHFS
- IPv4 : ~ 10.8 Mo/s
- IPv6 : ~~ 5 Mo/s
Une capture avec tshark n'a rien remonté de suspect/foirieux dans le transfert (pas de retransmission ou fragmentation).
À noter que SFR implèmente l'IPv6 non pas en natif mais encapsulé dans un tunnel L2TP/IPv4. Une telle solution étant rarement choisie juste pour le fun (sans parler du MTU qui se fait défoncer), j'imagine que leur coeur de réseau n'est pas encore prêt ou optimisé à faire transiter l'IPv6 en natif.
PS : Confirmé avec le serveur proof.ovh.net
oyaji@heu75-sff1:~/wget$ wget http://ipv6.proof.ovh.net/files/1Gb.dat
--2014-02-07 00:43:38-- http://ipv6.proof.ovh.net/files/1Gb.dat
Resolving ipv6.proof.ovh.net (ipv6.proof.ovh.net)... 2001:41d0:2:876a::1
Connecting to ipv6.proof.ovh.net (ipv6.proof.ovh.net)|2001:41d0:2:876a::1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 125000000 (119M) [application/octet-stream]
Saving to: `1Gb.dat'
100%[============================================================================>] 125,000,000 5.16M/s in 22s
2014-02-07 00:44:00 (5.45 MB/s) - `1Gb.dat' saved [125000000/125000000]
oyaji@heu75-sff1:~/wget$ wget http://ipv4.proof.ovh.net/files/1Gb.dat
--2014-02-07 00:44:05-- http://ipv4.proof.ovh.net/files/1Gb.dat
Resolving ipv4.proof.ovh.net (ipv4.proof.ovh.net)... 188.165.12.106
Connecting to ipv4.proof.ovh.net (ipv4.proof.ovh.net)|188.165.12.106|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 125000000 (119M) [application/octet-stream]
Saving to: `1Gb.dat.1'
100%[============================================================================>] 125,000,000 34.0M/s in 3.6s
2014-02-07 00:44:09 (33.6 MB/s) - `1Gb.dat.1' saved [125000000/125000000]
-
Tu pourrais faire un traceroute en IPv6 ? Il me semble que SFR ne peer avec avec OVH en IPv6 donc, il est possible que cela soit un problème de peering (et/ou un problème de limitation de débit en IPv6)
Peut-être continuer sur le post Lenteur IPv6 chez SFR (https://lafibre.info/ipv6/ipv6-lent-sfr-6818/)
A noter que le pb du post en question est le fait que les NeufBox v4 ont un chips Broadcom qui ne sais pas router de manière efficace IPv6.
-
Traceroute en IPv4 :
My traceroute [v0.82]
heu75-sff1 (0.0.0.0) Fri Feb 7 22:08:49 2014
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 172.16.0.1 0.0% 20 0.4 0.3 0.3 0.4 0.0
2. 18.136.17.93.rev.sfr.net 0.0% 20 0.9 1.0 0.6 1.7 0.4
3. 205.55.20.93.rev.sfr.net 0.0% 20 1.2 1.3 0.8 2.0 0.4
4. ???
5. th2-g1-a9.fr.eu 0.0% 20 2.8 2.6 2.0 3.0 0.3
6. rbx-g1-a9.fr.eu 0.0% 19 6.7 7.5 6.0 16.3 2.4
7. rbx-s3-6k.fr.eu 5.3% 19 6.6 6.1 5.6 6.7 0.4
8. proof.ovh.net 0.0% 19 5.7 6.7 5.6 17.1 2.5
En IPv6
My traceroute [v0.82]
heu75-sff1 (::) Fri Feb 7 22:13:38 2014
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 2a02-8428-0087-xx00-0000-0000-0000-0001.rev.sf 0.0% 217 0.5 0.4 0.4 1.4 0.1
2. 2a02-8400-0000-0000-0000-0000-0000-0015.rev.sf 0.0% 217 8.2 7.9 7.4 8.6 0.3
3. 2a02-8400-0000-0001-0000-0000-0000-002d.rev.sf 0.0% 217 8.6 10.0 7.5 143.1 13.8
4. ???
5. gsw-g1-a9.fr.eu 32.1% 216 18.6 15.6 15.0 18.6 0.5
6. rbx-g2-a9.fr.eu 7.9% 216 18.8 20.2 18.7 66.1 5.6
7. rbx-s3-6k.fr.eu 25.9% 216 18.7 28.6 18.4 214.1 35.1
8. proof.ovh.net 0.0% 216 18.7 18.7 18.2 19.6 0.3
-
Le peering IPv6 est donc bien en place entre SFR et Orange, et c'est le même chemin en IPv4 et IPv6 (même routeurs) => je retire ce que j'ai dit.
Il y a donc un problème sur l'IPv6 de la NeufBox.
-
Le peering IPv6 est donc bien en place entre SFR et Orange, et c'est le même chemin en IPv4 et IPv6 (même routeurs) => je retire ce que j'ai dit.
Il y a donc un problème sur l'IPv6 de la NeufBox.
La valeur du load averarge te donne raison ;D un MIPS @400MHz fait un bien piètre tunnelier...
Mem: 57304K used, 67200K free, 0K shrd, 0K buff, 18880K cached
CPU: 0.3% usr 2.1% sys 0.0% nic 4.0% idle 0.0% io 0.0% irq 93.4% sirq
Load average: 4.27 2.00 0.77 1/75 26425
PID PPID USER STAT VSZ %MEM %CPU COMMAND
6 2 root SW 0 0.0 83.0 [sirq-net-rx/0]
5 2 root SW 0 0.0 1.8 [sirq-net-tx/0]
...
Par comparaison en IPv4 :
Mem: 57304K used, 67200K free, 0K shrd, 0K buff, 18880K cached
CPU: 0.1% usr 0.9% sys 0.0% nic 98.4% idle 0.0% io 0.0% irq 0.3% sirq
Load average: 0.09 0.23 0.41 1/75 26699
PID PPID USER STAT VSZ %MEM %CPU COMMAND
6 2 root SW 0 0.0 0.2 [sirq-net-rx/0]
...
Par contre Linux voit un seul CPU logique alors que Broadcom vante le SoC 63168 comme étant un dual-core :o j'espère qu'un driver miteux (genre non SMP-safe) n'est pas derrière ce choix technique ::) vu la version du kernel le doute est permis...
-
oyaji, quel est ton modèle de NeufBox ?
NeufBox NB6 ou NB6V ?
(https://lafibre.info/images/altice/201307_neuf_box_6v.png)
-
oyaji, quel est ton modèle de NeufBox ?
Une NB6V Foxconn revision 0.
D'ailleurs en y regardant de près je suis intrigué que le CPU soit noyé par les interruptions... la version du noyau est plutôt vieille mais devrait malgré tout supporter le NAPI (passage en poolling et désactivation des interruptions côté Rx du NIC en cas de charge réseau significative)... en même temps il se peut que le driver réseau soit simplement miteux :-\
Bref, côté hardware il y a clairement du potentiel inexploité ;D
-
Il y avait pas une histoire de tunnel dans un tunnel?
Cela ne suffirait pas à expliquer le soucis de performance?
-
Oui, IPv6 est encapsulé dans le PPP IPv4.
La situation est temporaire, SFr a prévu de monter deux PPP : un IPv4 et un IPv6 natif.
-
D'ailleurs la Neufbox essaye déjà de se connecter en IPv6 natif à son démarrage, le tunnel L2TP est une solution de fallback si le BAS n'est pas compatible (je ne sais pas s'il y a des BAS compatibles actuellement sur le réseau).
oyaji, pour résoudre ce problème, il y aurait sûrement la possibilité de faire fonctionner le tunnel directement sur ton PC afin de ne pas être limité par la charge CPU, sachant qu'il est à base de logiciel libre (xl2tpd).
-
D'ailleurs la Neufbox essaye déjà de se connecter en IPv6 natif à son démarrage, le tunnel L2TP est une solution de fallback si le BAS n'est pas compatible (je ne sais pas s'il y a des BAS compatibles actuellement sur le réseau).
Un moyen de regarder chez soit dans quel cas on se trouve ?
-
Ça doit bien se voir au niveau du MTU...
Ce site détecte qu'il y a un tunnel utilisé pour transporter IPv6 au-dessus d'IPv4 par exemple : http://test-ipv6.com/ (http://test-ipv6.com/)
-
test-ipv6.com indique une note de 10/10, malgré le tunnel. Le contenu d'un des paquets IPv6 entre la box et l'ONT :
No. Time Source Destination Protocol Length Info
827 9.870598000 2607:f740:0:3f::f2f 2a02:8428:87:xx00:4c:18ce:3e80:304f TCP 1507 [TCP segment of a reassembled PDU]
Frame 827: 1507 bytes on wire (12056 bits), 1507 bytes captured (12056 bits) on interface 0
Ethernet II, Src: Ericsson_19:9d:c7 (00:30:88:19:9d:c7), Dst: Sfr_73:5e:xx (24:95:04:73:5e:xx)
Destination: Sfr_73:5e:xx (24:95:04:73:5e:xx)
Source: Ericsson_19:9d:c7 (00:30:88:19:9d:c7)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 109.6.4.109 (109.6.4.109), Dst: 93.31.227.xx (93.31.227.xx)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
Total Length: 1493
Identification: 0x3530 (13616)
Flags: 0x00
Fragment offset: 0
Time to live: 250
Protocol: UDP (17)
Header checksum: 0xd41b [correct]
Source: 109.6.4.109 (109.6.4.109)
Destination: 93.31.227.xx (93.31.227.xx)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: l2f (1701), Dst Port: l2f (1701)
Source port: l2f (1701)
Destination port: l2f (1701)
Length: 1473
Checksum: 0x0000 (none)
Layer 2 Tunneling Protocol
Packet Type: Data Message Tunnel Id=62227 Session Id=4864
Tunnel ID: 62227
Session ID: 4864
Offset: 0
Point-to-Point Protocol
Address: 0xff
Control: 0x03
Protocol: Internet Protocol version 6 (0x0057)
Internet Protocol Version 6, Src: 2607:f740:0:3f::f2f (2607:f740:0:3f::f2f), Dst: 2a02:8428:87:xx00:4c:18ce:3e80:304f (2a02:8428:87:xx00:4c:18ce:3e80:304f)
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 1413
Next header: TCP (6)
Hop limit: 56
Source: 2607:f740:0:3f::f2f (2607:f740:0:3f::f2f)
Destination: 2a02:8428:87:xx00:4c:18ce:3e80:304f (2a02:8428:87:xx00:4c:18ce:3e80:304f)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Transmission Control Protocol, Src Port: http (80), Dst Port: 44162 (44162), Seq: 1, Ack: 403, Len: 1381
-
Bien sûr, le fait que l'opérateur utilise IPv6/PPP/L2TP/UDP/IPv4 n'empêche pas que du point de vue de l'utilisateur, il a accès en natif à l'Internet v6 : il envoie des paquets IPv6 qui sont reçus tels quels par un pair.
-
D'ailleurs la Neufbox essaye déjà de se connecter en IPv6 natif à son démarrage, le tunnel L2TP est une solution de fallback si le BAS n'est pas compatible (je ne sais pas s'il y a des BAS compatibles actuellement sur le réseau).
oyaji, pour résoudre ce problème, il y aurait sûrement la possibilité de faire fonctionner le tunnel directement sur ton PC afin de ne pas être limité par la charge CPU, sachant qu'il est à base de logiciel libre (xl2tpd).
Merci pour ces indications Marin ;)
Pour ceux intéressés l'article suivant est d'une très grande aide : http://wiki.openwrt.org/doc/howto/ipv6.softwire (http://wiki.openwrt.org/doc/howto/ipv6.softwire)