La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Opérateurs grand public alternatifs => 
MilkyWan => Discussion démarrée par: Leon le 27 octobre 2024 à 10:48:50
-
Hello,
Je mets en route mon tout nouveau tunnel MilkyWan L2TP.
J'ai testé avec 2 routeurs :
- Tp-Link Archer C6 , ça fonctionne bien
- Asus RT-AX53U , ça merdouille, le tunnel saute, sans doute fermé par le routeur de collecte; puis ça se reconnecte 20 secondes plus tard.
Après quelques test, j'arrive à voir que c'est très probablement un problème de MTU.
Réduire le MTU des machines derrières le routeur ASUS, ça règle le problème, mais c'est ingérable comme ça (WiFi invité).
L'Asus n'a pas de réglage MTU/MSS, en tout cas pas en mode WAN-L2TP, alors qu'il le fait en PPPoE. Pas de réglage de MTU non plus côté serveur DHCP.
Le TP-Link montre bien ce réglage MTU dans la page WAN-L2TP, et ça fonctionne.
Je préfèrerais utiliser l'Asus, car il est offre plus d'options, notamment backup 4G.
2 questions, svp :
1) est-ce que d'autres utilisateurs ou admin de MilkyWan ont constaté la même chose avec un routeur Asus? Est-ce que j'ai oublié une option quelque part? Je lis sur la page MilkyWan que L2TP a été testé avec des routeurs Asus.
2) le routeur de collecte de MilkyWan ne pourrait-il pas faire du MSS-Clamping à la place du routeur-client si celui-ci ne sait pas faire? Je dis peut-être une bêtise, dites le moi.
Merci d'avance pour votre aide; et un grand merci à l'équipe MilyWan pour le service.
Leon.
-
Hello,
Je viens de mettre du clamping sur ta session, c'est mieux ?
Je préfère que ce soit l'user qui le fasse car je ne peux pas prédire à l'avance la MTU qu'il utilisera :)
-
Merci pour la réponse rapide un Dimanche!
Malheureusement c'est pas mieux.
Mon investigation était peut-être insuffisante / foireuse; c'est peut-être pas juste un problème de MTU avec l'Asus.
Après reboot PC, routeur, attente 5 min, ça fonctionne toujours aussi mal avec MTU 1500, et ca fonctionne de manière aléatoire maintenant quand je mets un MTU réduit côté PC...
Sinon, quand l'Asus se déconnecte 20 secondes, dans le log il met
/usr/sbin/l2tpd[1498]: Too many retransmissions on tunnel (47325/662); closing down
A court terme, je reste avec le Tp-Link, ça fait le job, et je ne vois pas trop comment débugger ça.
Ca fonctionne, c'est l'essentiel. Le mieux est l'ennemi du bien.
Merci encore.
Leon.
-
Voilà les paramètres que j'ai appliqué de mon côté :
interface xxx
mtu 1450
[...]
ip tcp adjust-mss 1410
[...]
ipv6 tcp adjust-mss 1390
[...]
end
-
Hello,
Je continue ici, même si la suite dépasse le cadre de problème du routeur Asus.
J'ai 3 questions/demandes:
1) Je renonce à utiliser le routeur ASUS. Du coup, c'est possible de retirer le MSS-Clamping que tu as mis en place côté serveur-VPN MilkyWan, stp? Désolé pour le changement d'avis; Ca ne presse pas, il n'y a rien d'urgent.
2) Plus gênant, avec un accès FTTH Bouygtel, le débit max du tunnel-VPN L2TP est très bas : 32Mb/s donwload et 38Mb/s up. Testé avec plusieurs speedtests (speedtest et test-debit=nperf), avec du téléchargement.
Avec un accès SFR-Numericâble, avec exactement la même configuration et le même matériel (routeur TP-Link qui termine le VPN + PC portable relié en Ethernet 1Gb/s), j'atteins les 200Mb/s.
Avec le même matériel, sur le FTTH Bouygtel, en bypassant le VPN, je dépasse les 900Mb/s.
Est-ce que vous auriez une idée/piste sur la cause de la lenteur avec le FTTH Bouygues? Ce qui est étrange c'est que les 32Mb/s sont parfaitement répétables.
3) Depuis MilkyWan Paris, le routage IPv4 vers Google/Youtube fait un aller-retour vers Toulouse. C'est un problème de routage côté MilkyWan?
C:\Users\user_A1>tracert -w 500 172.217.20.206
Tracing route to par10s50-in-f14.1e100.net [172.217.20.206]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.22.1
2 4 ms 7 ms 7 ms bienvenue.sur.internet.ip4.milkywan.net [80.67.167.0]
3 5 ms 6 ms 7 ms lo1.a7050qxs.core.cbo.bb.ip4.milkywan.net [80.67.167.7]
4 6 ms 7 ms 7 ms lo1.a7280qr.edge.dc2.bb.ip4.milkywan.net [80.67.167.1]
5 16 ms 15 ms 15 ms lo1.a7280tr.edge.tls.bb.ip4.milkywan.net [80.67.167.4]
6 25 ms 26 ms 27 ms google2.par.franceix.net [37.49.236.2]
7 28 ms 27 ms 27 ms 108.170.238.45
8 26 ms 27 ms 27 ms 142.251.253.39
9 25 ms 27 ms 27 ms par10s50-in-f14.1e100.net [172.217.20.206]
Merci d'avance pour les réponses.
Leon.
-
Hello,
Pour les soucis de débit, y'a un bridage connu chez Orange en L2TP sur certaines plaques (ça dépend à priori du routeur de collecte de la zone) mais rien chez Bouygues. Peut-être que sur certaines vieilles box bouygues, l'UDP 1701 est passé dans un NAT Helper (cf https://lafibre.info/vpn/limitation-debit-port-1723/) , ce qui réduit le débit, je ne saurais dire.
Pour Google, c'est "normal". On a deux ports France-IX Paris : Un à Paris et un à Toulouse.
C'est lié à une promo au lancement de France-IX Toulouse où il était inclus du transport vers Paris.
Du coup on passe tout ce qui n'est pas sensible à la latence (twitch, youtube, netflix) par cette interco là. Sans ça on serait obligé d'upgrader notre commit sur notre port Parisien et c'est une équation économique pas pertinente aujourd'hui.
-
Pour les soucis de débit, y'a un bridage connu chez Orange en L2TP sur certaines plaques (ça dépend à priori du routeur de collecte de la zone) mais rien chez Bouygues. Peut-être que sur certaines vieilles box bouygues, l'UDP 1701 est passé dans un NAT Helper (cf https://lafibre.info/vpn/limitation-debit-port-1723/) , ce qui réduit le débit, je ne saurais dire.
Merci Hugues. La Bbox que je dois utiliser, c'est une Fast 5330b-r1.
Si tout ça est confirmé, alors je ne pourrais pas utiliser le VPN. Tant pis, j'aurais essayé.
Leon.
-
Au pire, tu peux passer en wireguard :)
-
J'ai pas mal de problème avec un tunnel L2TP sur une connexion Bouygues.
Au début pas de problème, j'ai commencé à transférer pas mal de données dessus (environ 1.2 Gbits/s), au bout de 64 secondes de transfert, pouf plus rien. Même en désactivant le tunnel j'ai du attendre longtemps avant de récupérer internet.
Chose encore plus étonnante c'est que là le tunnel monte correctement, j'arrive à pinger certaines IPs, d'autres ne répondent pas du tout :
ping google.com -l 1410 -f
Pinging google.com [142.250.179.110] with 1410 bytes of data:
Reply from 142.250.179.110: bytes=1410 time=27ms TTL=117
Reply from 142.250.179.110: bytes=1410 time=27ms TTL=117
Reply from 142.250.179.110: bytes=1410 time=27ms TTL=117
Ping statistics for 142.250.179.110:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 27ms, Average = 27ms
ping google.fr -l 1410 -f
Pinging google.fr [142.250.178.131] with 1410 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 142.250.178.131:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
-
J'ai pas mal de problème avec un tunnel L2TP sur une connexion Bouygues.
Au début pas de problème, j'ai commencé à transférer pas mal de données dessus (environ 1.2 Gbits/s), au bout de 64 secondes de transfert, pouf plus rien. Même en désactivant le tunnel j'ai du attendre longtemps avant de récupérer internet.
Bonjour.
Tu peux stp nous dire si tu as conservé la BBox? Si oui, c'est quel modèle? C'est un modèle plus récent que la mienne 5330b-r1, qui m'empêche quasi-totalement d'utiliser mon tunnel L2TP?
Leon.
-
C'est une F@st5688b-r2.
J'arrive plus du tout à utiliser le tunnel, que ça soit avec ou en bypassant la bbox...
-
$ iperf3 -c speedtest.milkywan.fr -t 120 -p 9201 -R -P 4
Connecting to host speedtest.milkywan.fr, port 9201
Reverse mode, remote host speedtest.milkywan.fr is sending
[ 5] local 2a0e:e701:XXXX port 46776 connected to 2a0b:cbc0:42:1::1 port 9201
[ 7] local 2a0e:e701:XXXX port 46786 connected to 2a0b:cbc0:42:1::1 port 9201
[ 9] local 2a0e:e701:XXXX port 46790 connected to 2a0b:cbc0:42:1::1 port 9201
[ 11] local 2a0e:e701:XXXX port 46794 connected to 2a0b:cbc0:42:1::1 port 9201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 37.5 MBytes 315 Mbits/sec
[ 7] 0.00-1.00 sec 37.6 MBytes 315 Mbits/sec
[ 9] 0.00-1.00 sec 43.8 MBytes 368 Mbits/sec
[ 11] 0.00-1.00 sec 39.4 MBytes 330 Mbits/sec
[SUM] 0.00-1.00 sec 158 MBytes 1.33 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 1.00-2.00 sec 35.3 MBytes 296 Mbits/sec
[ 7] 1.00-2.00 sec 30.4 MBytes 255 Mbits/sec
[ 9] 1.00-2.00 sec 34.4 MBytes 289 Mbits/sec
[ 11] 1.00-2.00 sec 33.3 MBytes 279 Mbits/sec
[SUM] 1.00-2.00 sec 133 MBytes 1.12 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 2.00-3.00 sec 53.2 MBytes 446 Mbits/sec
[ 7] 2.00-3.00 sec 31.0 MBytes 260 Mbits/sec
[ 9] 2.00-3.00 sec 37.2 MBytes 312 Mbits/sec
[ 11] 2.00-3.00 sec 35.4 MBytes 297 Mbits/sec
[SUM] 2.00-3.00 sec 157 MBytes 1.31 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 3.00-4.00 sec 46.0 MBytes 386 Mbits/sec
[ 7] 3.00-4.00 sec 41.1 MBytes 344 Mbits/sec
[ 9] 3.00-4.00 sec 34.7 MBytes 291 Mbits/sec
[ 11] 3.00-4.00 sec 43.1 MBytes 362 Mbits/sec
[SUM] 3.00-4.00 sec 165 MBytes 1.38 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 4.00-5.00 sec 53.9 MBytes 452 Mbits/sec
[ 7] 4.00-5.00 sec 33.7 MBytes 283 Mbits/sec
[ 9] 4.00-5.00 sec 35.8 MBytes 300 Mbits/sec
[ 11] 4.00-5.00 sec 34.8 MBytes 292 Mbits/sec
[SUM] 4.00-5.00 sec 158 MBytes 1.33 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 5.00-6.00 sec 54.3 MBytes 456 Mbits/sec
[ 7] 5.00-6.00 sec 34.3 MBytes 287 Mbits/sec
[ 9] 5.00-6.00 sec 49.6 MBytes 416 Mbits/sec
[ 11] 5.00-6.00 sec 24.4 MBytes 205 Mbits/sec
[SUM] 5.00-6.00 sec 163 MBytes 1.36 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 6.00-7.00 sec 39.3 MBytes 330 Mbits/sec
[ 7] 6.00-7.00 sec 42.1 MBytes 353 Mbits/sec
[ 9] 6.00-7.00 sec 41.4 MBytes 348 Mbits/sec
[ 11] 6.00-7.00 sec 23.7 MBytes 199 Mbits/sec
[SUM] 6.00-7.00 sec 146 MBytes 1.23 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 7.00-8.00 sec 36.0 MBytes 302 Mbits/sec
[ 7] 7.00-8.00 sec 49.8 MBytes 417 Mbits/sec
[ 9] 7.00-8.00 sec 36.1 MBytes 303 Mbits/sec
[ 11] 7.00-8.00 sec 21.9 MBytes 184 Mbits/sec
[SUM] 7.00-8.00 sec 144 MBytes 1.21 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 8.00-9.00 sec 53.2 MBytes 446 Mbits/sec
[ 7] 8.00-9.00 sec 45.0 MBytes 378 Mbits/sec
[ 9] 8.00-9.00 sec 39.9 MBytes 335 Mbits/sec
[ 11] 8.00-9.00 sec 25.7 MBytes 216 Mbits/sec
[SUM] 8.00-9.00 sec 164 MBytes 1.37 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 9.00-10.00 sec 33.0 MBytes 276 Mbits/sec
[ 7] 9.00-10.00 sec 49.9 MBytes 419 Mbits/sec
[ 9] 9.00-10.00 sec 29.6 MBytes 248 Mbits/sec
[ 11] 9.00-10.00 sec 21.4 MBytes 179 Mbits/sec
[SUM] 9.00-10.00 sec 134 MBytes 1.12 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 10.00-11.00 sec 40.5 MBytes 339 Mbits/sec
[ 7] 10.00-11.00 sec 34.7 MBytes 291 Mbits/sec
[ 9] 10.00-11.00 sec 44.2 MBytes 371 Mbits/sec
[ 11] 10.00-11.00 sec 31.1 MBytes 261 Mbits/sec
[SUM] 10.00-11.00 sec 150 MBytes 1.26 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[...]
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 59.00-60.00 sec 45.2 MBytes 379 Mbits/sec
[ 7] 59.00-60.00 sec 30.7 MBytes 257 Mbits/sec
[ 9] 59.00-60.00 sec 31.6 MBytes 265 Mbits/sec
[ 11] 59.00-60.00 sec 24.2 MBytes 203 Mbits/sec
[SUM] 59.00-60.00 sec 132 MBytes 1.10 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 60.00-61.00 sec 77.8 MBytes 653 Mbits/sec
[ 7] 60.00-61.00 sec 26.1 MBytes 219 Mbits/sec
[ 9] 60.00-61.00 sec 26.9 MBytes 226 Mbits/sec
[ 11] 60.00-61.00 sec 16.5 MBytes 138 Mbits/sec
[SUM] 60.00-61.00 sec 147 MBytes 1.24 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 61.00-62.00 sec 39.7 MBytes 333 Mbits/sec
[ 7] 61.00-62.00 sec 34.3 MBytes 288 Mbits/sec
[ 9] 61.00-62.00 sec 50.8 MBytes 426 Mbits/sec
[ 11] 61.00-62.00 sec 11.0 MBytes 92.2 Mbits/sec
[SUM] 61.00-62.00 sec 136 MBytes 1.14 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 62.00-63.00 sec 36.3 MBytes 305 Mbits/sec
[ 7] 62.00-63.00 sec 32.7 MBytes 274 Mbits/sec
[ 9] 62.00-63.00 sec 55.1 MBytes 462 Mbits/sec
[ 11] 62.00-63.00 sec 19.4 MBytes 163 Mbits/sec
[SUM] 62.00-63.00 sec 144 MBytes 1.20 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 63.00-64.00 sec 34.4 MBytes 288 Mbits/sec
[ 7] 63.00-64.00 sec 36.2 MBytes 303 Mbits/sec
[ 9] 63.00-64.00 sec 39.9 MBytes 335 Mbits/sec
[ 11] 63.00-64.00 sec 28.6 MBytes 240 Mbits/sec
[SUM] 63.00-64.00 sec 139 MBytes 1.17 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 64.00-65.00 sec 6.24 MBytes 52.3 Mbits/sec
[ 7] 64.00-65.00 sec 7.66 MBytes 64.2 Mbits/sec
[ 9] 64.00-65.00 sec 6.58 MBytes 55.2 Mbits/sec
[ 11] 64.00-65.00 sec 4.68 MBytes 39.2 Mbits/sec
[SUM] 64.00-65.00 sec 25.2 MBytes 211 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 65.00-66.00 sec 0.00 Bytes 0.00 bits/sec
[ 7] 65.00-66.00 sec 0.00 Bytes 0.00 bits/sec
[ 9] 65.00-66.00 sec 0.00 Bytes 0.00 bits/sec
[ 11] 65.00-66.00 sec 0.00 Bytes 0.00 bits/sec
[SUM] 65.00-66.00 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 66.00-67.00 sec 0.00 Bytes 0.00 bits/sec
[ 7] 66.00-67.00 sec 0.00 Bytes 0.00 bits/sec
[ 9] 66.00-67.00 sec 0.00 Bytes 0.00 bits/sec
[ 11] 66.00-67.00 sec 0.00 Bytes 0.00 bits/sec
[SUM] 66.00-67.00 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 67.00-68.00 sec 0.00 Bytes 0.00 bits/sec
[ 7] 67.00-68.00 sec 0.00 Bytes 0.00 bits/sec
[ 9] 67.00-68.00 sec 0.00 Bytes 0.00 bits/sec
[ 11] 67.00-68.00 sec 0.00 Bytes 0.00 bits/sec
[SUM] 67.00-68.00 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 68.00-69.00 sec 0.00 Bytes 0.00 bits/sec
[ 7] 68.00-69.00 sec 0.00 Bytes 0.00 bits/sec
[ 9] 68.00-69.00 sec 0.00 Bytes 0.00 bits/sec
[ 11] 68.00-69.00 sec 0.00 Bytes 0.00 bits/sec
[SUM] 68.00-69.00 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 69.00-70.00 sec 0.00 Bytes 0.00 bits/sec
[ 7] 69.00-70.00 sec 0.00 Bytes 0.00 bits/sec
[ 9] 69.00-70.00 sec 0.00 Bytes 0.00 bits/sec
[ 11] 69.00-70.00 sec 0.00 Bytes 0.00 bits/sec
[SUM] 69.00-70.00 sec 0.00 Bytes 0.00 bits/sec
^C- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 70.00-70.53 sec 0.00 Bytes 0.00 bits/sec
[ 7] 70.00-70.53 sec 0.00 Bytes 0.00 bits/sec
[ 9] 70.00-70.53 sec 0.00 Bytes 0.00 bits/sec
[ 11] 70.00-70.53 sec 0.00 Bytes 0.00 bits/sec
[SUM] 70.00-70.53 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-70.53 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-70.53 sec 2.60 GBytes 317 Mbits/sec receiver
[ 7] 0.00-70.53 sec 0.00 Bytes 0.00 bits/sec sender
[ 7] 0.00-70.53 sec 2.54 GBytes 309 Mbits/sec receiver
[ 9] 0.00-70.53 sec 0.00 Bytes 0.00 bits/sec sender
[ 9] 0.00-70.53 sec 2.00 GBytes 244 Mbits/sec receiver
[ 11] 0.00-70.53 sec 0.00 Bytes 0.00 bits/sec sender
[ 11] 0.00-70.53 sec 1.91 GBytes 233 Mbits/sec receiver
[SUM] 0.00-70.53 sec 0.00 Bytes 0.00 bits/sec sender
[SUM] 0.00-70.53 sec 9.05 GBytes 1.10 Gbits/sec receiver
iperf3: interrupt - the client has terminated
Voilà un example d'iperf3 qui chute aux alentours de 64 secondes. Après ça le tunnel est mort, les pings passent, c'est tout.
-
Et un test en wget... ça bloque à 6 Go téléchargés, et plus rien
$ wget https://speedtest.milkywan.fr/files/10G.iso
--2024-11-25 20:45:58-- https://speedtest.milkywan.fr/files/10G.iso
Resolving speedtest.milkywan.fr (speedtest.milkywan.fr)... 2a0b:cbc0:42:1::1, 80.67.167.93
Connecting to speedtest.milkywan.fr (speedtest.milkywan.fr)|2a0b:cbc0:42:1::1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10485760000 (9.8G) [application/x-iso9660-image]
Saving to: ‘10G.iso’
10G.iso 62%[========================================================================> ] 6.06G --.-KB/s eta 60s
-
Le trafic passe par FranceIX dans les deux sens, j'ai vérifié nos mécanismes anti-ddos et rien ne semble être déclenché, d'autres abos sur d'autres FAI ne semblent pas avoir de problèmes... je sèche un peu honnêtement.
-
Pas de soucis sans utiliser le tunnel :
wget -O /dev/null https://speedtest.milkywan.fr/files/10G.iso
--2024-11-25 22:04:30-- https://speedtest.milkywan.fr/files/10G.iso
Resolving speedtest.milkywan.fr (speedtest.milkywan.fr)... 80.67.167.93, 2a0b:cbc0:42:1::1
Connecting to speedtest.milkywan.fr (speedtest.milkywan.fr)|80.67.167.93|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10485760000 (9.8G) [application/x-iso9660-image]
Saving to: ‘/dev/null’
100%[======================================================================================================================================================================>] 10,485,760,000 179MB/s in 56s
2024-11-25 22:05:26 (180 MB/s) - ‘/dev/null’ saved [10485760000/10485760000]
-
On dirait qu'il n'y a pas de problème en upload par contre (en utilisant le tunnel). C'est juste le téléchargement qui semble déclencher quelque chose...
-
Bonjour,
J’ai hérité d’un système VPN avec Cisco chez un de mes clients.
Ils utilisent un logiciel IBM pour synchroniser des bases documentaires. Une personne était embêtée et la synchronisation se bloquait systématiquement. J’ai tout essayé, la MTU etc. Impossible.
Je suis donc passé par le VPN applicatif Cisco pour débloquer cette personne.
Les points communs sont : Bouygues FTTH (la personne m’indiquait que ça fonctionnait avant son passage en fibre) et L2TP.
Il doit y avoir quelque chose de spécifique avec Bouygues et le L2TP…
-
Perso j'ai l'impression que ça ressemble a un trigger d'antiddos, ils auraient mis en place un nouveau truc chez Bytel ?
-
Si je limite le traffic descendant à 300M, on dirait que le tunnel tient...
-
juste pour être certain, tu pourrais me faire un traceroute bytel vers l'endpoint L2TP MW stp ? Et me filer ton IPv4 en privé
-
Voilà:
Columns: ADDRESS, LOSS, SENT, LAST, AVG, BEST, WORST, STD-DEV
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV
1 192.168.1.254 0% 10 0.4ms 0.4 0.4 0.6 0.1
2 176.149.32.2 50% 10 5.9ms 65.5 3.9 305.6 120
3 100% 10 timeout
4 62.34.2.0 0% 10 5ms 5.3 5 5.8 0.2
5 100% 10 timeout
6 80.67.167.1 0% 10 5.1ms 5.2 4.9 5.5 0.2
7 80.67.167.7 0% 10 5.8ms 5.5 5.3 5.8 0.2
8 80.67.167.29 0% 10 5.9ms 6 5.9 6.3 0.2
-
Super instructif, les hops utiles ne sont pas visibles :/
Bon ça a l'air de bien passer par France-IX, c'est déjà ça...
Tu peux monter ton tunnel ? Je ne le vois pas up là
-
B3nJ1, sur quel équipement termines-tu le tunnel ? Est-il possible qu'il ne soit pas capable de tenir la charge et que le tunnel tombe après 60s du fait d'un timeout, par exemple si des LCP echo sont droppés ?
Aussi, le tunnel est-il transporté par IPv6 ou IPv4 ? Si tu l'as configuré pour v4, ca vaut le coup d'essayer en v6. Tu t'évites peut-être un CGNAT coté Bouygues.
-
Super instructif, les hops utiles ne sont pas visibles :/
Bon ça a l'air de bien passer par France-IX, c'est déjà ça...
Tu peux monter ton tunnel ? Je ne le vois pas up là
Tunnel remonté. J'utilise une instance CHR pour le moment (histoire de pas couper le reste de la maison...)
B3nJ1, sur quel équipement termines-tu le tunnel ? Est-il possible qu'il ne soit pas capable de tenir la charge et que le tunnel tombe après 60s du fait d'un timeout, par exemple si des LCP echo sont droppés ?
Aussi, le tunnel est-il transporté par IPv6 ou IPv4 ? Si tu l'as configuré pour v4, ca vaut le coup d'essayer en v6. Tu t'évites peut-être un CGNAT coté Bouygues.
Que je termine le tunnel sur mon RB5009 ou une instance CHR (sur un ryzen 3600), le comportement est le même. Je n'avais pas ces problèmes là sur une FTTH Orange.
Le tunnel est en IPv4, mais j'ai bien une IPv4 non-cgnat (j'arrive à rediriger les ports).
-
Aussi, le tunnel est-il transporté par IPv6 ou IPv4 ? Si tu l'as configuré pour v4, ca vaut le coup d'essayer en v6.
je doute que nos ASR1001-X sachent faire du L2TP avec underlay IPv6.
-
Bonjour, peut être le souci ce trouve sur la partie MAP-T de chez Bouygues https://youtu.be/6RFsA1vsi70?feature=shared&t=790
-
On parle d'archis ipv4 natives là
-
Vu "J'arrive plus du tout à utiliser le tunnel, que ça soit avec ou en bypassant la bbox..." mais avec Bybox Map-T alors ?
-
J'ai absolument rien compris
-
Je vois que ma première explication n'était pas claire, et je m'en excuse. Je n'avais pas précisé le contexte de manière suffisante. Pour résumer, penses-tu qu'il pourrait y avoir un problème avec le Map-T réalisé avec Bouygues, notamment dans le cas de l'utilisation d'une BBOX + tunnel?
C'est une F@st5688b-r2.
J'arrive plus du tout à utiliser le tunnel, que ça soit avec ou en bypassant la bbox...
-
J'avais le même comportement, que ça soit avec ou sans bbox. Donc je pense pas que ma connectivité IPv4 soit faite via MAP-T, et qu'elle est native.
-
Hello,
Je vais suivre ce topic de pres car j'ai effectivement le meme soucis. Je perds le tunnel quand je pousse du 1 Gbits regulierement (fait via cette commande iperf3 -c speedtest.milkywan.fr -t 120 -p 9201 -R -P 4).
A savoir que je n'ai pas ce souci avec Wireguard (via un autre provider de VPN). Je peux tenir du 1 Gbits sans pb avec ce type de VPN.
-
Si tu pouvais poster ici : https://lafibre.info/incidents-ftth/bridage-l2tp-chez-bouygues/ histoire d'ajouter un peu de poids :)