Beantwoord

IPv6 tunnel langzaam naar overstap connect box



Toon eerste bericht

229 Reacties

Reputatie 3
Ook maar even het NOC van Liberty Global aangesproken. Die hebben zowaar wat gedaan:

Hi CitizenE,

As you undoubtedly know failure of complex systems can be truly bizarre but an appropriately measured kick on just the right spot often works wonders J

4. nl-ams05a-rd2-ae-5-60.aorta.net 0.0% 17 1.1 2.0 0.9 12.2 2.7
5. nl-ams17b-rc1-lag-58-0.aorta.net 0.0% 17 1.7 2.0 1.2 7.6 1.5
6. nl-ams04a-ri3-ae9-0.aorta.net 0.0% 17 1.8 4.1 1.5 11.2 3.6
7. 10ge1-4.core1.ams1.he.net 0.0% 17 2.2 3.0 1.7 11.4 2.4
8. tserv1.ams1.he.net 0.0% 17 1.4 3.2 1.2 19.1 4.2

Regards,

--Steven.


Op dit moment loopt het wel weer via Londen maar het is verbetering. 🙂
Reputatie 3
Ik heb even contact gehad met HE support hierover (daar krijg je tenminste binnen een paar uur een ter zake doend antwoord):

Hi CitizenE,

Since you're a user of AS6830 you'll want to ask them. We do peer with AS6830 at Amsterdam.

Roy
HE Support


Oftewel Ziggo (i.e. Liberty Global) is aan het k*tten.
Reputatie 5
Badge +4
En, speaking of which: de IPv6 tunnel via de Ams PoP van HE is onbruikbaar geworden. Op dit moment wordt het verkeer tussen Ziggo en HE via Washington en NYC gerouteerd. Met een latency van meer dan 100 ms tot gevolg.
Ik heb IPv6 daarom maar disabled. Het is diep treurig. Tijd voor een alternatief.


@CitizenE
Wat??? Net getest... hier precies t zelfde.... wat is dit toch voor geze*k??

Blijkt dat verkeer voor PoP dld en uk ook direct de plas worden over gejaagd??

@Mark Ziggo Kun jij hier eens duiding geven? Is dit een foutje? Want anders krijgt het toch wel trekjes van klantjes die IPv6 nodig hebben pesten...... 😞
Reputatie 3
Another one bites the dust. :-(
En, speaking of which: de IPv6 tunnel via de Ams PoP van HE is onbruikbaar geworden. Op dit moment wordt het verkeer tussen Ziggo en HE via Washington en NYC gerouteerd. Met een latency van meer dan 100 ms tot gevolg.
Ik heb IPv6 daarom maar disabled. Het is diep treurig. Tijd voor een alternatief.

code:
HOST: nuc                                                  Avg
1. AS??? _gateway 0.6
2. AS??? 10.160.106.1 8.5
3. AS6830 212.142.52.125 8.6
4. AS33915 asd-rc0001-cr101-be112-2.core.as33915.net 10.2
5. AS33915 nl-ams17b-rc1-lag61-2.core.as33915.net 9.8
6. AS6830 us-was02a-rd2-ae105-0.aorta.net 105.6
7. AS6830 us-was03a-ri1-ae10-0.aorta.net 104.2
8. AS??? 10gigabitethernet2-2.core1.ash1.he.net 100.5
9. AS6939 100ge5-1.core2.ash1.he.net 101.5
10. AS6939 100ge8-1.core1.nyc5.he.net 100.8
11. AS6939 100ge8-2.core1.dub1.he.net 101.2
12. AS6939 100ge3-2.core1.man1.he.net 99.9
13. AS6939 100ge16-1.core1.ams1.he.net 109.4
14. AS6939 tserv1.ams1.he.net 97.3
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.
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
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 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
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 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 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
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).

Een ping van 1472 gaat hier ook netjes over de lijn (Ubee).
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
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?
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
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
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 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 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
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

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!
@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]
@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.
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.

Reageer