onderwerp Re: IPv6 tunnel langzaam naar overstap connect box in Internet

IPv6 tunnel langzaam naar overstap connect box

Ern st — Sun, 26 May 2019 08:05:05 GMT

Na overstap op de connect box (Arris TG2492LG-ZG) in bridge mode is mijn Hurrican Electric IPv6 tunnel traag. Komt nu maximaal ca. 13Mbit/s downstream doorheen. Met het vorige modem Cisco EPC3928 kwam ik hier gewoon op 200+ Mbit/s.

Om even uit te sluiten dat er problemen zijn bij Hurricane Electric heb ik een tunnel naar een machine in AWS opgezet. Als ik hier een 6in4 tunnel maak (proto 41) haal ik hier dezelfde 13Mbit/s downstream. Zet ik deze om naar GRE (proto 47) haal ik de volledige 250mbit/s. Ook IPSEC werkt gewoon naar behoren.

Is het een bekend issue dat protocol 41 verkeer geratelimit wordt op de Arris modems?

Onderstaand testje zoals uitgevoerd hierbij wordt een 6in4 en GRE tunnel opgezet tussen dezelfde machines.

#Opzetten 6in4 en GRE tunnel (ander kant heeft adres :2)

ip tunnel add 6in4 mode sit remote n.n.n.n ttl 255
ip addr add fd00:1::1/64 dev 6in4
ip link set 6in4 mtu 1480 up

ip tunnel add gre mode gre remote n.n.n.n ttl 255
ip addr add fd00:2::1/64 dev gre
ip link set gre mtu 1476 up

# test over sit tunnel ( 6in4 )
root@aws:/# iperf -V -c fd00:1::2
------------------------------------------------------------
Client connecting to fd00:1::2, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[ 3] local fd00:1::1 port 35622 connected with fd00:1::2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 16.5 MBytes 13.7 Mbits/sec

# test over gre tunnel
root@aws:/# iperf -V -c fd00:2::2
------------------------------------------------------------
Client connecting to fd00:2::2, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[ 3] local fd00:2::1 port 33472 connected with fd00:2::2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 291 MBytes 243 Mbits/sec

Re: IPv6 tunnel langzaam naar overstap connect box

KBX458 — Sun, 26 May 2019 08:49:49 GMT

Misschien dat hanh je hiermee kan helpen. Ik heb dit topic onder zijn aandacht gebracht.

Re: IPv6 tunnel langzaam naar overstap connect box

hanh — Sun, 26 May 2019 09:53:57 GMT

Tsja, ik zag het al. Hield nog wijselijk mijn mond. Lastig probleem.

De Arris staat in Bridge. Zover ik weet is een kabelModem transparant voor layer 3. Daar lijkt het mij niet aan te liggen.
Wat ik als eerste denk, is, dat het in de eigen Router moet worden gezocht.
Maar ja, als daar niks in gewijzigd werd.......

Vraag: is je externe Ip gewijzigd bij de Swap Cisco-Arris?
Zo ja, dan zou je nog kunnen denken aan een andere Routering die rare dingen teweeg brengt.

Dit ter inspiratie. Meer kan ik er niet over zeggen, anders wordt het lulkoek.

Gr Han

Re: IPv6 tunnel langzaam naar overstap connect box

hanh — Sun, 26 May 2019 10:37:41 GMT

efok heb jij een idee?

Re: IPv6 tunnel langzaam naar overstap connect box

Ern st — Sun, 26 May 2019 11:00:38 GMT

hanh , in bovenstaand testje heb ik een rechtstreeks gekoppelde linux machine aan het modem gebruikt en een machine in de AWS cloud, de endpoints/routing zijn dan exact gelijk enige verschil is de encapsulatie. ( normaal zou GRE marginaal langzamer zijn door de 4 bytes extra overhead).

Re: IPv6 tunnel langzaam naar overstap connect box

efok — Mon, 27 May 2019 19:11:27 GMT

hanh wrote:
efok heb jij een idee?

Pfoe, dit is voor mij ook geen dagelijkse kost. Als ik de post van Ern st zo lees, weet hij heel goed waar hij het over heeft. Hij heeft duidelijk vastgesteld dat de snelheden bij GRE hoger liggen dan Protocol 41.
De enige veranderde factor hierin lijkt de connectbox, als ik het zo lees.

We hebben de connectbox al van veel zaken beschuldigd. maar hoe deze in bridge modus met dergelijke IP protocollen omgaat zou ik niet durven zeggen. Ik ben het met je eens dat je verwacht dat deze volledig transparant zou moeten zijn, zodra je hem bridged. Maar dat lijkt hier dus niet het geval.

hanh kun jij dit niet bij een moderator neerleggen? Ik ben bang dat wij wat blijven gissen, naar de exacte werking van de connectbox.

Re: IPv6 tunnel langzaam naar overstap connect box

hanh — Tue, 28 May 2019 04:48:57 GMT

Ern st
Ik heb je probleem voorgelegd aan de Mods en om hulp van een specialist gevraagd.
Er komt iemand langs.

Re: IPv6 tunnel langzaam naar overstap connect box

Mark — Tue, 28 May 2019 09:31:39 GMT

Hi allemaal, ik zal beginnen met een disclaimer: dit gaat mijn kennis te boven.

Ik zat gisteren ook al naar dit topic te staren en heb een hoop Google-werk verricht, maar voor antwoorden heb ik echt hulp nodig van onze specialisten. Die heb ik een mail gestuurd en ik wacht op antwoord, zodra ik iets hoor post ik hier een update.

Re: IPv6 tunnel langzaam naar overstap connect box

Ern st — Fri, 05 Jul 2019 13:52:42 GMT

Mark Ziggo We zijn ondertussen een maandje verder, al iets terug gehoord? Zo niet is er dan in een oplosrichting te denken, bijvoorbeeld ander nieuw modem of het opnieuw activeren van mijn oude Cisco EPC3928?

Re: IPv6 tunnel langzaam naar overstap connect box

Mark — Mon, 08 Jul 2019 11:51:02 GMT

Ja, sorry dat het zo lang duurt Ern st. Degene die dit voor mij in behandeling heeft is altijd erg druk en ondanks meerdere verzoeken vanuit mij is dit nog steeds niet getest, het ligt nog op de plank.

Ik kan je oude Cisco wel weer activeren als je dat graag wilt, als je die nog in huis hebt?

Re: IPv6 tunnel langzaam naar overstap connect box

Ern st — Tue, 09 Jul 2019 09:37:25 GMT

Mark Ziggo Geen probleem, ben al lang blij dat er serieus naar gekeken wordt. Laten we het voor nu nog maar even zo houden tot iemand dit bij jullie heeft kunnen testen. Dan kan ik ook nog testen. Mochten we er met de connect box niet uitkomen ga ik graag op je aanbod in.

Re: IPv6 tunnel langzaam naar overstap connect box

Candy — Tue, 30 Jul 2019 10:34:54 GMT

Mark Ziggo Ern st Ik heb hetzelfde probleem. Ik heb ook een Arris Connect Box in bridge mode, en ik haal ook maar rond de 15-16Mbps door HE.net. Ik heb op het moment geen andere server om het naar te testen, maar ik vind het wel vrij problematisch.

Bij familie achter een ouder Ubee-modem in bridge mode haal ik met dezelfde router gewoon bijna de maximale internetsnelheid door de HE.net-tunnels.

Re: IPv6 tunnel langzaam naar overstap connect box

Candy — Tue, 30 Jul 2019 12:27:16 GMT

Ik heb ook wat testjes gedaan, en ik kan in principe alles bevestigen dat Ern st ervaart. Ik heb een 250/25Mbps-verbinding met een Arris Connect Box in bridge mode met daarachter een OpenWrt-router die een /48 van Hurricane Electric krijgt.

Eerst een simpele 256MB file download vanaf mijn server over IPv4:

$ wget -4 -O /dev/null https://quietlife.nl/speedtest.bin
--2019-07-30 13:59:17--  https://quietlife.nl/speedtest.bin
Herleiden van quietlife.nl (quietlife.nl)... 217.77.132.180, 2001:9c0:1:24:250:56ff:febc:421b
Verbinding maken met quietlife.nl (quietlife.nl)|217.77.132.180|:443... verbonden.
HTTP-verzoek is verzonden; wachten op antwoord... 200 OK
Lengte: 268435456 (256M) [application/octet-stream]
Wordt opgeslagen als: ‘/dev/null’

/dev/null                     100%[=================================================>] 256,00M  30,3MB/s    in 9,1s

2019-07-30 13:59:26 (28,3 MB/s) - '‘/dev/null’' opgeslagen [268435456/268435456]

Daar halen we 28,3MB/s, oftewel 226,4Mbps. Lijkt me keurig.

Dan maar eens hetzelfde proberen over IPv6 (dus via de Hurricane Electric-tunnel):

$ wget -6 -O /dev/null https://quietlife.nl/speedtest.bin
--2019-07-30 14:03:48-- https://quietlife.nl/speedtest.bin
Herleiden van quietlife.nl (quietlife.nl)... 2001:9c0:1:24:250:56ff:febc:421b
Verbinding maken met quietlife.nl (quietlife.nl)|2001:9c0:1:24:250:56ff:febc:421b|:443... verbonden.
HTTP-verzoek is verzonden; wachten op antwoord... 200 OK
Lengte: 268435456 (256M) [application/octet-stream]
Wordt opgeslagen als: ‘/dev/null’

/dev/null                    100%[=================================================>] 256,00M 1,88MB/s   in 2m 7s  

2019-07-30 14:05:55 (2,02 MB/s) - '‘/dev/null’' opgeslagen [268435456/268435456]

2,02MB/s, oftewel slechts 16,16Mbps. Heel erg slecht dus.

Dan maar de HE.net-tunnel uitzetten en over IPv4 met m'n VPN-server verbinden, die ook 6in4-tunnels geeft:

$ wget -6 -O /dev/null https://quietlife.nl/speedtest.bin
--2019-07-30 14:10:47-- https://quietlife.nl/speedtest.bin
Herleiden van quietlife.nl (quietlife.nl)... 2001:9c0:1:24:250:56ff:febc:421b
Verbinding maken met quietlife.nl (quietlife.nl)|2001:9c0:1:24:250:56ff:febc:421b|:443... verbonden.
HTTP-verzoek is verzonden; wachten op antwoord... 200 OK
Lengte: 268435456 (256M) [application/octet-stream]
Wordt opgeslagen als: ‘/dev/null’

/dev/null                    100%[=================================================>] 256,00M 15,0MB/s   in 14s    

2019-07-30 14:11:01 (18,0 MB/s) - '‘/dev/null’' opgeslagen [268435456/268435456]

18,0MB/s, oftewel 144Mbps. Niet gek wanneer je bedenkt dat hier nog de nodige SSL- en TCP-over-UDP-overhead in zit.

Dit laat in ieder geval wel zien dat er iets heel erg mis is met de manier waarop ik toegang heb tot HE's endpoint, en ik zie geen andere verklaring dan dat dat door die Connect Box komt, aangezien zowel de topicstarter als ikzelf dit probleem niet hebben/hadden met andere modems.

Re: IPv6 tunnel langzaam naar overstap connect box

Mark — Tue, 30 Jul 2019 15:16:04 GMT

Bedankt voor de uitgebreide info Candy!

Ik vraag me alleen af of dit voor onze engineers makkelijk te reproduceren is. Ik snap in ieder geval weinig van de door jullie geleverde voorbeelden, dat ligt aan mijn kennis vrees ik. :zipper_mouth:

Zou een test hier op kantoor mogelijk zijn en hoe? Dan heb ik een sterker verhaal om onze engineers aan het werk te krijgen.

Re: IPv6 tunnel langzaam naar overstap connect box

Jbr67 — Tue, 30 Jul 2019 16:10:42 GMT

Ern st wrote:

Om even uit te sluiten dat er problemen zijn bij Hurricane Electric heb ik een tunnel naar een machine in AWS opgezet. Als ik hier een 6in4 tunnel maak (proto 41) haal ik hier dezelfde 13Mbit/s downstream. Zet ik deze om naar GRE (proto 47) haal ik de volledige 250mbit/s. Ook IPSEC werkt gewoon naar behoren.

Is het een bekend issue dat protocol 41 verkeer geratelimit wordt op de Arris modems?

Onderstaand testje zoals uitgevoerd hierbij wordt een 6in4 en GRE tunnel opgezet tussen dezelfde machines.

#Opzetten 6in4 en GRE tunnel (ander kant heeft adres :2)

ip tunnel add 6in4 mode sit remote n.n.n.n ttl 255
ip addr add fd00:1::1/64 dev 6in4
ip link set 6in4 mtu 1480 up

ip tunnel add gre mode gre remote n.n.n.n ttl 255
ip addr add fd00:2::1/64 dev gre
ip link set gre mtu 1476 up

Ern st

Wow! Wat een mooie test! Pinpoint wat mij betreft heel duidelijk naar de Arris.

Wat ik weet is dat die Arris uit zichzelf IPv6 ondersteuning biedt... t is nogal een longshot maar zou die daarom proto 41 alsnog -ten onrechte- verder gaan uitpellen?

Overigens zijn er heel veel problemen met de Arris.. zie hier:
https://community.ziggo.nl/internetverbinding-102/overzicht-arris-connetbox-problemen-38258

Groet,
Jbr

Re: IPv6 tunnel langzaam naar overstap connect box

Candy — Tue, 30 Jul 2019 16:45:33 GMT

Mark Ziggo

Tja, op kantoor is denk ik lastig. Ik verwacht niet dat jullie voor jullie hele kantoor een Arris Connect Box gebruiken. Dat mag ik niet hopen althans. Mochten jullie wel zo'n ding hebben, is het simpel: zet er één in bridge mode, hang er een router met OpenWrt achter (ik wil er jullie best één doneren), maak een account aan op tunnelbroker.net en stel die in als 6in4 voor de WAN6-interface. Documentatie staat hier: https://openwrt.org/docs/guide-user/network/ipv6_ipv4_transitioning

Ik hoor sommige mensen op andere fora beweren dat de Arris en Compal Connect Boxen geen echte bridge mode doen (als in een OSI Level 2 switch), maar dit softwarematig uitvoeren in OSI Level 3. Men geeft daar alleen geen technische uitleg over, dus ik weet niet of het waar is.

Dat zou vraag 1 zijn: "Zitten er verschillen in de implementatie van bridge mode tussen de firmware op Connect Boxen en die op oudere modemrouters?"
Daar moeten we echt een eerlijk antwoord op hebben, anders gaan we hele verkeerde kanten op zoeken.

Ergens kan het ook bijna niet anders, want hoe kan een "domme" switch anders verantwoordelijk zijn voor zulke verschillen in throughput afhankelijk van het protocol. Zoals Ern st al liet zien, is het echt specifiek Protocol41 (de vorm van 6in4 die HE.net onder andere gebruikt) die belemmerd wordt. Dat is ook precies het ontzettend vervelende aan dit euvel, want het is al vervelend dat IPv6 in bridge mode niet werkt, en hiermee is de beste workaround voor klanten die IPv6 in bridge mode willen ook vrijwel onwerkbaar geworden.

Verder zal ik vooral moeten aantonen dat andere modems in een verder identieke configuratie het verschil maken.

Dus bij dezen een vergelijking tussen twee modems met daarachter identieke routers met identieke firmware (TP-Link TL-WDR4300 met OpenWrt 18.06.4):

Eerst bij m'n moeder thuis; een Ubee EVW 3226 met een 50/5Mbps-verbinding.

Over native IPv4:

root@eyjafjallajokull:~# date && wget -4 -O /dev/null http://ftp.bit.nl/speedtest/500mb.bin && date
Tue Jul 30 18:03:38 CEST 2019
Downloading 'http://ftp.bit.nl/speedtest/500mb.bin'
Connecting to 213.136.12.213:80
Writing to '/dev/null'
/dev/null           100% |*******************************|  476M 0:00:00 ETA
Download completed (500000000 bytes)
Tue Jul 30 18:04:56 CEST 2019

Totaal 78 seconden voor 500MB. Oftewel (500 * 8 ) / 78 = 51,28Mbps.

Dan door de HE.net-tunnel:

root@eyjafjallajokull:~# date && wget -6 -O /dev/null http://ftp.bit.nl/speedtest/500mb.bin && date
Tue Jul 30 18:06:10 CEST 2019
Downloading 'http://ftp.bit.nl/speedtest/500mb.bin'
Connecting to 2001:7b8:3:37::21:3:80
Writing to '/dev/null'
/dev/null           100% |*******************************|  476M 0:00:00 ETA
Download completed (500000000 bytes)
Tue Jul 30 18:08:01 CEST 2019

Totaal 111 seconden voor 500MB. Oftewel (500 * 8 ) / 111 = 36,04Mbps.

Dit is zo'n 70,3% van de IPv4-throughput. Klinkt allemaal zeer aannemelijk.

Dan bij mij thuis; een Arris Connect Box met een 250/25Mbps-verbinding.

Over native IPv4:

root@reykjavik:~# date && wget -4 -O /dev/null http://ftp.bit.nl/speedtest/500mb.bin && date
Tue Jul 30 18:08:14 CEST 2019
Downloading 'http://ftp.bit.nl/speedtest/500mb.bin'
Connecting to 213.136.12.213:80
Writing to '/dev/null'
/dev/null           100% |*******************************|  476M 0:00:00 ETA
Download completed (500000000 bytes)
Tue Jul 30 18:08:39 CEST 2019

Totaal 25 seconden voor 500MB. Oftewel (500 * 8 ) / 25 = 160Mbps.

Dan door de HE.net-tunnel:

root@reykjavik:~# date && wget -6 -O /dev/null http://ftp.bit.nl/speedtest/500mb.bin && date
Tue Jul 30 18:09:45 CEST 2019
Downloading 'http://ftp.bit.nl/speedtest/500mb.bin'
Connecting to 2001:7b8:3:37::21:3:80
Writing to '/dev/null'
/dev/null           100% |*******************************|  476M 0:00:00 ETA
Download completed (500000000 bytes)
Tue Jul 30 18:13:44 CEST 2019

Totaal 239 seconden voor 500MB. Oftewel (500 * 8 ) / 239 = 16,74Mbps.

Dit is slechts 10,5% van de IPv6-troughput. Dramatisch dus.

Dan nog andere verklaringen bedenken. Stel dat het niet aan de firmware ligt en dat er niets in de TCP/IP-stack van de Connect Box is dat dit veroorzaakt. Dan zou er nog iets in één van jullie routers of switches kunnen gebeuren dat bijvoorbeeld packet loss veroorzaakt op de IPv4-route van mijn router thuis naar HE's IPv4-endpoint. Het zou in theorie kunnen dat Connect Boxen met andere Ziggo ISP-routers verbinden dan oudere modems doen. Ik kan dit vrij makkelijk testen, al heb ik maar 3 routers waarvan ik het kan doen, dus echt een goede steekproef is het niet.

Eerst bij mij thuis, dus de Arris Connect Box gebridged naar mijn WDR4300 met OpenWrt:

root@reykjavik:~# traceroute -4 tserv11.ams1.ipv6.he.net
traceroute to tserv11.ams1.ipv6.he.net (216.66.84.46), 30 hops max, 38 byte packets
 1 92-109-197-1.cable.dynamic.v4.ziggo.nl (92.109.197.1) 59.552 ms 13.382 ms 14.262 ms
 2 212.142.4.9 (212.142.4.9) 11.706 ms 14.011 ms 14.751 ms
 3 asd-rc0001-cr101-be114-2.core.as33915.net (213.51.7.98) 16.834 ms 13.661 ms 18.335 ms
 4 * nl-ams17b-rc1-lag61-2.core.as33915.net (213.51.64.34) 14.608 ms 18.867 ms
 5 de-fra01b-rc1-ae40-0.aorta.net (84.116.130.10) 22.716 ms 21.897 ms 21.213 ms
 6 at-vie15a-rd1-ae7-0.aorta.net (84.116.137.34) 30.692 ms 29.874 ms 27.208 ms
 7 10ge10-2.core1.fra1.he.net (216.66.87.125) 24.527 ms 24.077 ms 21.245 ms
 8 100ge6-1.core1.ams1.he.net (72.52.92.5) 22.531 ms 25.578 ms 21.640 ms
 9 tserv1.ams1.he.net (216.66.84.46) 20.457 ms 20.092 ms 19.268 ms

Dan bij m'n moeder thuis, dus de Ubee EVW 3226 gebridged naar haar WDR4300 met OpenWrt:

root@eyjafjallajokull:~# traceroute -4 tserv11.ams1.ipv6.he.net
traceroute to tserv11.ams1.ipv6.he.net (216.66.84.46), 30 hops max, 38 byte packets
 1 dhcp-077-250-100-001.chello.nl (77.250.100.1) 13.218 ms 12.050 ms 11.280 ms
 2 212.142.53.41 (212.142.53.41) 14.902 ms 11.018 ms 11.180 ms
 3 asd-tr0021-cr101-be114-2.core.as33915.net (213.51.7.100) 12.089 ms 10.597 ms 13.070 ms
 4 * nl-ams02a-rc2-lag61-4.core.as33915.net (213.51.64.162) 8.630 ms nl-ams02a-rc2-lag60-2.core.as33915.net (213.51.64.134) 15.571 ms
 5 nl-ams17b-rc1-lag-40-0.aorta.net (84.116.130.9) 24.195 ms 27.962 ms 22.836 ms
 6 de-fra01b-rc1-ae40-0.aorta.net (84.116.130.10) 23.502 ms 20.740 ms 21.382 ms
 7 at-vie15a-rd1-ae7-0.aorta.net (84.116.137.34) 20.024 ms 24.511 ms 20.961 ms
 8 10ge10-2.core1.fra1.he.net (216.66.87.125) 19.940 ms 22.503 ms 20.989 ms
 9 100ge6-1.core1.ams1.he.net (72.52.92.5) 20.488 ms 39.939 ms 18.047 ms
10 tserv1.ams1.he.net (216.66.84.46) 18.879 ms 25.407 ms 20.894 ms

En nog bij mijn grootouders, ook een Ubee EVW 3226 gebridged naar hun WDR4300 met OpenWrt:

root@snaefellsnes:~# traceroute -4 tserv11.ams1.ipv6.he.net
traceroute to tserv11.ams1.ipv6.he.net (216.66.84.46), 30 hops max, 38 byte packets
 1 dhcp-077-249-244-001.chello.nl (77.249.244.1) 11.610 ms 12.672 ms 13.397 ms
 2 212.142.53.41 (212.142.53.41) 12.187 ms 10.318 ms 15.009 ms
 3 asd-tr0021-cr101-be114-2.core.as33915.net (213.51.7.100) 12.866 ms 10.981 ms 12.056 ms
 4 * nl-ams02a-rc2-lag60-2.core.as33915.net (213.51.64.134) 12.080 ms nl-ams02a-rc2-lag61-4.core.as33915.net (213.51.64.162) 12.090 ms
 5 nl-ams17b-rc1-lag-40-0.aorta.net (84.116.130.9) 28.808 ms 20.545 ms 21.491 ms
 6 de-fra01b-rc1-ae40-0.aorta.net (84.116.130.10) 22.952 ms 19.633 ms 21.712 ms
 7 at-vie15a-rd1-ae7-0.aorta.net (84.116.137.34) 26.813 ms 22.013 ms 22.181 ms
 8 10ge10-2.core1.fra1.he.net (216.66.87.125) 21.242 ms 22.960 ms 21.395 ms
 9 100ge6-1.core1.ams1.he.net (72.52.92.5) 21.480 ms 19.029 ms 19.707 ms
10 tserv1.ams1.he.net (216.66.84.46) 21.492 ms 17.841 ms 19.699 ms

In alle drie de gevallen zijn de eerste 4 hops van Ziggo (jullie hebben BGP AS 33915). De Ubee's komen allebei kennelijk als eerste bij 212.142.53.41, terwijl mijn Arris bij 212.142.4.9 komt. Daar zou ik dan eerst eens op kijken. Kan daar iets zijn dat Protocol41 bemoeilijkt? Komt Ern st wellicht ook via die hop Ziggo's backbone binnen?

De volgende hop voor de Ubee's is asd-tr0021-cr101-be114-2.core.as33915.net. Het PTR-record verraadt dat dat een core router in de AMS-IX is. Mijn Arris komt daarna echter bij een andere router; namelijk asd-rc0001-cr101-be114-2.core.as33915.net. Daar geldt weer hetzelfde: is daar veel packet loss te zien voor Protocol41?

Vraag twee luidt dus: "Is er een verschil in routes van nieuwere Connect Boxen en oudere modems van het huis van de klant naar de AMS-IX? En zo ja, gaat er wellicht iets mis op de routers in dat pad?"

Dan is er nog een derde optie natuurlijk: dat ik een ander modem probeer. Ik woon in voormalig UPC-gebied, dus ik weet niet of het daar makkelijk voor Mark Ziggo of collega's is om andere modems te activeren. Ik zou bijvoorbeeld best bereid zijn om op Marktplaats te zoeken naar een afgedankt modem dat gebruikt werd in fUPC-gebied en het MAC-adres daarvan door te geven. Wellicht kan ik nog wel zo'n zelfde Ubee vinden, maar over Technicolor TC7210's hoor ik ook goede dingen.

Of Ziggo moet mij een zakelijk modem willen geven, indien de TFTP-servers die kunnen provisionen voor consumentenverbindingen; dat vind ik ook best. Ik wil zelfs wel wat betalen ervoor.

Mark Ziggo Voor mijn werk heb ik echt IPv6 nodig (ik werk in de IoT). Dat IPv6 in bridge mode niet werkt, is al lastig genoeg, maar als tunnels ook zo brak zijn, is het voor mij echt onwerkbaar. Ik wil je gerust mijn contactgegevens geven en sta absoluut open om hierover direct in gesprek te gaan met netwerkengineers. Ik heb zelf ook een aantal jaren gewerkt als senior engineer voor een hostingprovider, dus ik denk dat ik absoluut kan helpen. Afhankelijk van waar jullie kantoor zit, wil ik zelfs wel een keer langskomen om alle vragen te beantwoorden en dingen te demonstreren.

Re: IPv6 tunnel langzaam naar overstap connect box

Candy — Tue, 30 Jul 2019 17:04:50 GMT

Mark Ziggo Ik had zojuist een hele uitgebreide post geschreven, maar die is kennelijk in een moderatiequeue verdwenen..

***Modedit: opgelost***

Re: IPv6 tunnel langzaam naar overstap connect box

Candy — Wed, 31 Jul 2019 08:32:30 GMT

Mark Ziggo Zijn er verdere dingen die ik kan doen om hier vaart achter te zetten? Ik denk dan aan:

In contact gebracht worden met een Ziggo-netwerkengineer en in samenspraak verdere tests doen;
Een ander modem (tweedehands) kopen en testen, als Ziggo kan aangeven welke ze nog willen activeren;
Een nieuwer modem bij Ziggo aanvragen om dat te testen, als daar een procedure voor bestaat;
Andere (beta) firmware testen op mijn Arris Connect Box, indien die er is en kan worden uitgerold.

De komende paar weken heb ik in ieder geval ruimschoots gelegenheid om hier tijd aan te besteden.

Re: IPv6 tunnel langzaam naar overstap connect box

Jbr67 — Wed, 31 Jul 2019 10:14:33 GMT

Candy

In het kader van mogelijk verdere foutisolatie heb ik een vergelijkbare test gedaan. Hier (provincie Drenthe) een Ubee in bridge modus en een ASUS3200 met Merlin

Route:

Alleen de laatste 5 hops zijn hetzelfde als die in de door jouw genoemde paden.

En performance:

Scheelt 5 seconden (t.o.v 79). Prima volgens mij.

Vraag: je had toch een test gedaan naar deZELFDE VPN-server met twee verschillende protocollen en dan had je het probleem toch ook. Waarom dan toch vermoedens over dat het aan het pad ligt?

CIao,
Jbr
PS. Ik wil OOK IPv6 in bridge mode!!

Re: IPv6 tunnel langzaam naar overstap connect box

Candy — Wed, 31 Jul 2019 10:34:22 GMT

Jbr67 Nee, ik heb het probleem niet wanneer ik IPv6 over OpenVPN doe. Alleen wanneer ik IPv6 over Protocol41 doe, en dan alleen met de Arris Connect Box.

Ik heb drie locaties waarvan ik kan testen:

Arris Connect Box gebridged naar TP-Link TL-WDR4300 met OpenWrt 18.06.4
Ubee EVW 3226 gebridged naar TP-Link TL-WDR4300 met OpenWrt 18.06.4
Ubee EVW 3226 gebridged naar TP-Link TL-WDR4300 met OpenWrt 18.06.4

In alle gevallen haal ik over IPv4 de geadverteerde snelheid. Via de HE.net-tunnels haal ik in gevallen 2 en 3 tussen de 70 en 80% van de IPv4-throughput, wat ik zeker acceptabel vind. In geval 1 (via de Arris dus), haal ik door de HE.net-tunnels maar zo'n 10% van de IPv4-throughput, ook rond de 15Mbps zoals Ern st al aangaf.

Met OpenVPN haal ik over IPv6 in gevallen 2 en 3 100% van de IPv4-throughput (maar dat zijn 50Mbps-verbindingen) en in geval 1 (een 250Mbps-verbinding) zo'n 60%. Maar dat ligt waarschijnlijk meer aan de bandbreedte van mijn VPS, de overhead van SSL en het encapsuleren van TCP-packets in UDP-datagrams.

Mijn vermoeden gaat ook sterk uit naar dat er iets met de Connect Box is dat dit veroorzaakt, al zou dat in het geval van een Level 2 bridge eigenlijk onmogelijk moeten zijn. Vandaar dus de vraag of die Arris Connect Boxen wel echt bridgen.

Als dat wel zo is, zou ik niet kunnen bedenken hoe die het verschil kunnen maken. Vandaar dat ik me toen afvroeg of er wellicht iets in de ISP-routers achter de Arris zou kunnen verschillen, en dat daar wellicht Protocol41-traffic specifiek wordt belemmerd.

Vandaar ook mijn vraag om een ander modem in bridge mode te proberen. Als de route dan hetzelfde is en het probleem verholpen, lag het duidelijk aan de Arris Connect Box.

We zouden eigenlijk nog iemand moeten vinden met hetzelfde modem in bridge mode, en dan vragen of die hetzelfde probleem heeft met Protocol41.