IPv6 tunnel langzaam naar overstap connect box

[Ern st]

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

[Jbr67]

Candy wrote:
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?

[CitizenE]

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.

/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

[Jbr67]

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).

[Candy]

Jbr67 wrote:
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.

[Jbr67]

Candy wrote:

Jbr67 wrote:
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

[CitizenE]

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... 🙂

[Mark]

CitizenE wrote:
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).

[Jbr67]

Mark Ziggo wrote:

CitizenE wrote:
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

[Candy]

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!

[Jbr67]

Candy wrote:
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

[Verwijderd account]

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.

[CitizenE]

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.

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

[Jbr67]

CitizenE wrote:
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...... 😞

[CitizenE]

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.

[CitizenE]

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. 🙂

[CitizenE]

Nog even verder contact gehad met ze. Het verkeer blijft nu netjes binnen NL. Zo zijn we er toch op vooruit gegaan. 🙂
Nu alleen nog dat issue met die modems... 😕

HOST: nuc                                                  Avg
  1. AS???    _gateway                                     0.5
  2. AS???    10.160.106.1                                 8.4
  3. AS6830   212.142.52.125                               8.8
  4. AS33915  asd-rc0001-cr101-be112-2.core.as33915.net   10.2
  5. AS33915  nl-ams17b-rc1-lag61-2.core.as33915.net       8.1
  6. AS6830   nl-ams04a-ri3-ae9-0.aorta.net                9.8
  7. AS6939   10ge1-4.core1.ams1.he.net                   10.1
  8. AS6939   tserv1.ams1.he.net                           9.5

[Jbr67]

CitizenE wrote:
Nog even verder contact gehad met ze. Het verkeer blijft nu netjes binnen NL. Zo zijn we er toch op vooruit gegaan. 🙂
Nu alleen nog dat issue met die modems... 😕

Wow!! Knap gedaan!!!

[Mark]

N.N. wrote:
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.

Daar legt XS4ALL zich nog niet bij neer las ik vandaag. :slight_smile:

CitizenE wrote:
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.

Jeez, dat is wel een hele grote omweg. Gelukkig al hersteld lees ik, dankzij jouw melding bij LGI!

[CitizenE]

Welkom terug Mark Ziggo ! 🙂
We zitten met smart te wachten op je bevindingen m.b.t. tot de gerapporteerde 6in4 en GRE issues.
Ik vermoed zelf dat deze modems in bridge mode niet 100% transparant zijn en filtering toepassen waardoor een aantal protocollen niet in hardware maar in software worden afgehandeld. Voor die protocollen loop je dan tegen de beperkte processing capaciteit aan van de chipset.

[Mark]

CitizenE wrote:
Welkom terug Mark Ziggo ! 🙂
We zitten met smart te wachten op je bevindingen m.b.t. tot de gerapporteerde 6in4 en GRE issues.
Ik vermoed zelf dat deze modems in bridge mode niet 100% transparant zijn en filtering toepassen waardoor een aantal protocollen niet in hardware maar in software worden afgehandeld. Voor die protocollen loop je dan tegen de beperkte processing capaciteit aan van de chipset.

Ook ik wacht nog op het antwoord, ben bijna dagelijks reminders aan het sturen... :zipper_mouth: