Beantwoord

IPv6 tunnel langzaam naar overstap connect box



Toon eerste bericht

229 Reacties

Reputatie 7
Ondertussen het topic gevonden. Was toch op dit forum: https://community.ziggo.nl/internetverbinding-102/computer-bekabeld-aansluiten-op-modem-die-in-bridge-modus-staat-mogelijk-29346#post292435
Reputatie 7
@ArChie.DVB verder geloof ik niet dat WifiSpots aan staan. Wanneer ik met wavemon een scan doe en m'n laptop vlak naast m'n Connect Box zet, zie ik geen netwerken met een heel hoog zendvermogen, en ook geen BSSID's die lijken op het MAC-adres van het modem in kwestie.
Ziggo rommelt wat met de MAC adressen die gebruikt worden voor de Wifispots. Die komen niet uit de standaard set van MAC adressen van de fabrikant.
Reputatie 7
🤗 - Ik word echt heel blij van alle input die jullie geven! Super!

Zodra ik iemand intern aan de haak heb die deze materie wel goed begrijpt en hier ook tijd voor heeft probeer ik jullie te koppelen @Candy.
Reputatie 2
@Mark Ziggo Dit is vrij eenvoudig te reproduceren, zie 2 opties:

  • 2 linux machines, 1 op internet 1 achter de verschillende kabelmodems. Is de opzet zoals in mijn eerste post. Commando's om de tunnels te maken staan beschreven.
  • Tunnel opzetten naar he.net https://tunnelbroker.he.net
Voordeel van de eerste opzet is dat je hetzelfde netwerkpath hebt enkel verschillende protocollen. Tweede is iets makkelijker te realiseren gezien hier enkel een machine aan de modemkant voor nodig is.

Om te testen zijn verder enkel een connectbox en een ander modem ( bijvoorbeeld de cisco/ubee ) met dezelfde snelheid nodig om te kunnen vergelijken.
Zelfde probleem hier, helaas. Weliswaar met protocol 47 (GRE) en niet (41), maar het resultaat is hetzelfde, ik kom amper boven de 13Mbit/s uit.

Kan ik zonder problemen de helpdesk bellen om mijn oude EPC3925 weer te activeren? Ik wil kijken of dit het probleem oplost.
@TheDJVG Kan je eens traceroutes naar de tunnelserver doen, zoals ik deed? Ik ben wel benieuwd via welk pad jij er komt met hetzelfde modem. Als dat totaal anders is dan bij mij, en bij @Ern st ook, dan kunnen we wel met redelijke zekerheid zeggen dat het echt aan het modem ligt.
@TheDJVG Kan je eens traceroutes naar de tunnelserver doen, zoals ik deed? Ik ben wel benieuwd via welk pad jij er komt met hetzelfde modem. Als dat totaal anders is dan bij mij, en bij @Ern st ook, dan kunnen we wel met redelijke zekerheid zeggen dat het echt aan het modem ligt.
Het is een tunnel naar mijn eigen netwerk/AS. Verkeer loopt via Cogent. Het lijkt dus niet aan het pad te liggen.

In mijn geval gaat het dus enkel om GRE en geen IPv6/SIT.

Edit:

Bestand vanaf xs4all via Ziggo:
code:
$ wget http://download.xs4all.nl/test/100MiB.bin -O /dev/null
--2019-08-01 18:24:54-- http://download.xs4all.nl/test/100MiB.bin
Resolving download.xs4all.nl (download.xs4all.nl)... 194.109.21.67, 2001:888:0:25::43
Connecting to download.xs4all.nl (download.xs4all.nl)|194.109.21.67|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: ‘/dev/null’


/dev/null 100%[========================================================================================================================================>] 100.00M 43.4MB/s in 2.3s


2019-08-01 18:24:56 (43.4 MB/s) - ‘/dev/null’ saved [104857600/104857600]



Bestand vanaf xs4all via tunnel:
code:
#  wget http://download.xs4all.nl/test/100MiB.bin -O /dev/null
--2019-08-01 16:25:03-- http://download.xs4all.nl/test/100MiB.bin
Resolving download.xs4all.nl (download.xs4all.nl)... 194.109.21.67, 2001:888:0:25::43
Connecting to download.xs4all.nl (download.xs4all.nl)|194.109.21.67|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: ‘/dev/null’


/dev/null 100%[=======================================================================================================================================================================================>] 100.00M 1.65MB/s in 65s


2019-08-01 16:26:07 (1.55 MB/s) - ‘/dev/null’ saved [104857600/104857600]
Sorry voor de dubbel post maar ik krijg het niet voor elkaar onder het andere bericht iets te plaatsen

Net contact gehad met de helpdesk en ze hebben mijn oude modem geactiveerd. Ga het zo proberen en kijken of dat het probleem oplost!
Reputatie 3
Twee opmerkingen:

Ik heb dezelfde observaties in combinatie met een Compal Connectbox (300/40Mbps en rond de 16Mbps max met een 6in4 tunnel van HE). Het probleem beperkt zich dus niet tot de Arris.

Een traceroute laat een suboptimaal pad zien tussen Ziggo en Hurricane Electric. Het verkeer tussen deze netwerken loopt vanaf Amsterdam via Frankfurt naar Wenen en weer terug via Frankfurt naar Amsterdam. Alhoewel alle verdenking op de Connectbox ligt en de extra latency beperkt is, helpt dit niet.

code:
HOST: nuc                                                  Avg
1. AS??? _gateway 0.6
2. AS??? 10.160.106.1 9.2
3. AS6830 212.142.52.125 10.0
4. AS33915 asd-rc0001-cr101-be112-2.core.as33915.net 9.7
5. AS33915 nl-ams17b-rc1-lag61-2.core.as33915.net 9.4
6. AS6830 de-fra01b-rc1-ae40-0.aorta.net 19.8
7. AS6830 at-vie15a-rd1-ae7-0.aorta.net 21.1
8. AS6939 10ge10-2.core1.fra1.he.net 21.0
9. AS6939 100ge6-1.core1.ams1.he.net 29.5
10. AS6939 tserv1.ams1.he.net 16.8

Reputatie 7
Zelfde probleem hier, helaas. Weliswaar met protocol 47 (GRE) en niet (41), maar het resultaat is hetzelfde, ik kom amper boven de 13Mbit/s uit.
Maar dit is toch exact het tegenovergestelde van het "zelfde probleem"?
Jij hebt een Compal Connectbox (in tegenstelling tot Ernst en Candy), dat zou het verschil kunnen verklaren maar ook dat wordt alweer ontkracht door de volgende reactie van CitizenE met zijn Compal Connectbox. 🤔

Ik heb dezelfde observaties in combinatie met een Compal Connectbox (300/40Mbps en rond de 16Mbps max met een 6in4 tunnel van HE). Het probleem beperkt zich dus niet tot de Arris.

Een traceroute laat een suboptimaal pad zien tussen Ziggo en Hurricane Electric. Het verkeer tussen deze netwerken loopt vanaf Amsterdam via Frankfurt naar Wenen en weer terug via Frankfurt naar Amsterdam. Alhoewel alle verdenking op de Connectbox ligt en de extra latency beperkt is, helpt dit niet.

Hm, ik zal dit balletje eens opgooien bij de onderzoekers. Edit: gezien de eerder geposte traceroutes denk ik niet dat dit de oorzaak is. Het werkt immers goed via andere modems die dezelfde route bewandelen.


Overigens kreeg ik afgelopen donderdag een kort berichtje dat ze de oorzaak waarschijnlijk gevonden hebben, maar nog een aantal testjes moesten doen om het te bevestigen. Helaas zonder verdere uitleg of toelichting dus ik heb geen idee wat ze hebben gevonden. Die info heb ik uiteraard naar gevraagd en hoop ik snel te ontvangen.
Reputatie 3

Overigens kreeg ik afgelopen donderdag een kort berichtje dat ze de oorzaak waarschijnlijk gevonden hebben, maar nog een aantal testjes moesten doen om het te bevestigen. Helaas zonder verdere uitleg of toelichting dus ik heb geen idee wat ze hebben gevonden. Die info heb ik uiteraard naar gevraagd en hoop ik snel te ontvangen.


Ik ben erg benieuwd. Dan volgt vanzelf de vraag of het ook op te lossen valt.
Reputatie 3
V.w.b. GRE: ik heb ook nog maar even een testje gedaan met een GRE tunnel naar een VPS. Met zowel IPv4 als IPv6 over GRE zie ik precies dezelfde beroerde throughput als over m'n 6in4 HE tunnel.
Met hetzelfde testje over IPv4 buiten de tunnel om naar dezelfde VPS kom ik ruim boven de 200Mbps uit.

Conclusie: mijn Compal, in bridge mode, heeft met zowel proto-41 (6in4) als proto-47 (GRE) erg veel moeite.
Reputatie 5
Badge +4
V.w.b. GRE: ik heb ook nog maar even een testje gedaan met een GRE tunnel naar een VPS. Met zowel IPv4 als IPv6 over GRE zie ik precies dezelfde beroerde throughput als over m'n 6in4 HE tunnel.
Met hetzelfde testje over IPv4 buiten de tunnel om naar dezelfde VPS kom ik ruim boven de 200Mbps uit.

Conclusie: mijn Compal, in bridge mode, heeft met zowel proto-41 (6in4) als proto-47 (GRE) erg veel moeite.

@CitizenE @Candy

Hmmmm... er begint bij mij een (klein) lampje te branden. ZOu het te maken kunnen hebben met verschillende mtu tussen beide links van de router en die van het modem? Aan de ene kant is de mtu icm met de overhead van de tunnel net zodanig dat een pakket niet meer "lekker" past?

Hier wat meer om te lezen....

https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
Ik denk dat iedereens router wel MSS Clamping toepast eerlijk gezegd. Met 6in4 heb je sowieso een behoorlijke overhead, dus je komt daar nooit met een MTU van 1500 doorheen.
Verder zou IPv6 ook inherent alweer MTU Path Discovery moeten doen.

Maar ja, als die Connect Boxen niet echt bridgen op level 2, zou dit inderdaad wel een probleem kunnen zijn. Dat is alleen een vraag die nog niet echt beantwoord is.
Reputatie 5
Badge +4
Ik denk dat iedereens router wel MSS Clamping toepast eerlijk gezegd. Met 6in4 heb je sowieso een behoorlijke overhead, dus je komt daar nooit met een MTU van 1500 doorheen.
Verder zou IPv6 ook inherent alweer MTU Path Discovery moeten doen.

Maar ja, als die Connect Boxen niet echt bridgen op level 2, zou dit inderdaad wel een probleem kunnen zijn. Dat is alleen een vraag die nog niet echt beantwoord is.

@Candy
Nieuw voor mij, mss camping. Interessant!!

Ik lees dat mss clamping alleen werkt voor tcp en het is een taak van de ce router. Maar dat doet ie dan toch niet bij proto 41 of 47 verkeer?
Reputatie 3
Bij tunneling is het altijd van belang de MTU grootte van de tunnel interfaces zelf (de binnenkant van de tunnel dus) correct te configureren. Je bent nl. het aantal bytes dat nodig is voor de overhead kwijt. Hiermee voorkom je onnodige fragmentatie en dus een performance hit.
Bij 6in4 kom je op 1480. Bij GRE op 1476 bytes. Uitgaande van een standaard MTU van 1500 buiten de tunnel. De Connectbox heeft geen benul van wat er in de ge-encapsuleerde packets zit. Die moet alleen het gehele packet switchen die dus 1500 bytes groot zal zijn.

Dat de Connectbox in bridge mode gewoon packets van 1500 bytes doorlaat zonder fragmentatie kun je makkelijk zelf testen. Doe een ping met het DF (don't fragment) bit en een packetsize van 1472 naar bijvoorbeeld je Ziggo next-hop adres. Inclusief overhead verstuur je dan een packet van precies 1500 bytes. Als je daar een echo-reply op krijgt, komt ie er doorheen.

code:
/home/citizenE > ping -M do -s 1472 -c 1 212.142.52.125
PING 212.142.52.125 (212.142.52.125) 1472(1500) bytes of data.
1480 bytes from 212.142.52.125: icmp_seq=1 ttl=253 time=11.6 ms


--- 212.142.52.125 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

/home/citizenE > ping -M do -s 1474 -c 1 212.142.52.125
PING 212.142.52.125 (212.142.52.125) 1474(1502) bytes of data.
ping: local error: Message too long, mtu=1500


--- 212.142.52.125 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms


Reputatie 5
Badge +4
Heb nog even gekeken wat het modem aan de WAN-kant als MTU gebruikt/kan gebruiken. Dus de kabel kant. Online lees ik 1518 voor docsis3.1 Dat betekent dat pakketten van 1500 idd gewoon verstuurd kunnen worden (zelfs nog iets meer).

Een ping van 1472 gaat hier ook netjes over de lijn (Ubee).
Heb nog even gekeken wat het modem aan de WAN-kant als MTU gebruikt/kan gebruiken. Dus de kabel kant. Online lees ik 1518 voor docsis3.1 Dat betekent dat pakketten van 1500 idd gewoon verstuurd kunnen worden (zelfs nog iets meer).

Ja, voor DOCSIS 3.1 zou RFC4638 mogelijk moeten zijn inderdaad. Ik weet niet hoe dat is met DOCSIS 3.0 overigens. Maar zoals @CitizenE zegt, maakt dat voor de Connect Box in principe niet uit. Fragmentatie ontstaat tussen de server waarmee je verbindt en je client device.
Reputatie 5
Badge +4

Heb nog even gekeken wat het modem aan de WAN-kant als MTU gebruikt/kan gebruiken. Dus de kabel kant. Online lees ik 1518 voor docsis3.1 Dat betekent dat pakketten van 1500 idd gewoon verstuurd kunnen worden (zelfs nog iets meer).Ja, voor DOCSIS 3.1 zou RFC4638 mogelijk moeten zijn inderdaad. Ik weet niet hoe dat is met DOCSIS 3.0 overigens. Maar zoals @CitizenE zegt, maakt dat voor de Connect Box in principe niet uit. Fragmentatie ontstaat tussen de server waarmee je verbindt en je client device.


Klopt hoor! Maar.. als die bridge op de lan link een mtu heeft van 1500 en op de wan-zijde een kleinere... dan zijn de rapen goed gaar. Maar goed.. dat zou met alle protocollen gedoe geven...
Er is natuurlijk path mtu discovery maar dat schijnt lang niet altijd goed te werken!

ciao,
Jbr
Reputatie 3
PMTUD werkt op zich goed. Het is alleen afhankelijk van ICMP. Zolang dat hier en daar tegengehouden wordt, zal het blijven breken.
Ik kom heel regelmatig issues tegen waar de MTU een rol in speelt (don't mention the J-word! 😉 maar ik denk dat dat hier niet het geval is.
Ik ben wel echt benieuwd of @Mark Ziggo intussen al wat meer gehoord heeft over een mogelijke oorzaak. Kom er maar in... 🙂
Reputatie 7
Ik ben wel echt benieuwd of @Mark Ziggo intussen al wat meer gehoord heeft over een mogelijke oorzaak. Kom er maar in... :-)
Helaas niet, mijn contactpersoon bij deze afdeling is op vakantie (en ik binnenkort ook).
Reputatie 5
Badge +4

Ik ben wel echt benieuwd of @Mark Ziggo intussen al wat meer gehoord heeft over een mogelijke oorzaak. Kom er maar in... :-)Helaas niet, mijn contactpersoon bij deze afdeling is op vakantie (en ik binnenkort ook).



Hallo @Mark Ziggo

Ik heb een reactie in twee delen:

1) Heerlijk. Geniet ervan, lekker bijkomen en wel verdiend!
2) Nou en? Het zou toch niet uit moeten maken in de afhandeling van dit probleem dat jij/iemand anders op vakantie gaat? Net zoals er meerdere moderators zijn, zijn er toch ook meer contactpersonen (cq. ze hebben daar ook een vervanger?). Ik vind dit zo weinig professioneel (en vooral goedkoop) overkomen. Voor de duidelijkheid: dit is geen kritiek naar/op jou persoonlijk!

Los van dit alles .... geniet van je vakantie!

Ciao
Jbr
Bij dezen wil ik even aangeven dat ik helaas niet meer in staat zal zijn om verder te helpen / testen. Mijn Ziggo-abonnementsperiode is aan zijn einde gekomen, en ik ben overgestapt naar (internet-only) XS4ALL. Daar krijg ik native IPv6, kan ik mijn eigen modem in echte level 2 (MPoA) bridge mode gebruiken, en heb ik zelfs hun modemrouter in bruikleen kunnen afwijzen.

Ok, ik ben van 250/25Mbps naar 100/30Mbps gegaan, maar snelheid is voor mij niet belangrijk. IPv6 en bridge mode zijn dat wel. Gelukkig zit ik vlakbij de DSLAM, dus kan ik zulke snelheden halen. Andere mensen hebben die keuze niet, en zitten effectief vast aan Ziggo.

Ik hoop dat Ziggo hierdoor beseft dat er echt klanten zijn die vertrekken omwille van het gebrek aan IPv6 in bridge mode. Als Ziggo dit wel zou hebben aangeboden, zou ik niet zijn overgestapt.

Ik wil Ziggo absoluut niet bashen, maar het is voor mij echt pijnlijk geweest om zo lang zonder IPv6 te zitten en dan ook geen HE.net-tunnels te kunnen gebruiken. Die Connect Boxen zijn voor mij wel de doodsteek geweest in ieder geval.

Ik hoop oprecht dat Ziggo bij EuroDOCSIS 3.1 eigen modems gaat toestaan (zoals Unity Media, het Duitse zusterbedrijf ook al doet), zodat ik wellicht ooit nog eens terug kan keren. Randvoorwaarde is dan wel dat IPv6 voor iedereen beschikbaar komt; ook voor klanten met een eigen modem, en ook in bridge mode.

Tot ziens!
Reputatie 5
Badge +4
Ik hoop dat Ziggo hierdoor beseft dat er echt klanten zijn die vertrekken omwille van het gebrek aan IPv6 in bridge mode. Als Ziggo dit wel zou hebben aangeboden, zou ik niet zijn overgestapt.


@Candy
Dank voor je update! Veel plezier bij XS4all!

Gelukkig heb ik hier nog een ubee modem (he tunnels doen het gewoon) maar als ziggo om wat voor reden dan ook deze gaat vervangen door een connectbox dan volg ik je voorbeeld.

Ciao,
Jbr
Alleen jammer dat XS4ALL, net als Telfort, opgeslokt wordt door KPN.
Men zegt wel dat alles hetzelfde blijft, maar ik waag het te betwijfelen gezien mijn ervaringen met UPC/Ziggo.

Reageer