Onderwerp: ipv6 leaseweb

Ik heb voor de server die ik nog bij leaseweb heb staan native ipv6 aangevraagd.

Nu merk ik echter na het instellen dat het gewone surfen een stuk trager lijkt te zijn,
wat niet het geval was toen ik de hurricane tunnel gebruikte.

Iemand diezelfde ervaring, of tips om dit misschien op te lossen?
(kan altijd dat ik wat over het hoofd zie?)

Misschien heb je hier wat aan. (Drie IPv6-ongemakken voor de hostingklant)

Oorspronkelijk geplaatst door unchained

Ik heb voor de server die ik nog bij leaseweb heb staan native ipv6 aangevraagd.

Nu merk ik echter na het instellen dat het gewone surfen een stuk trager lijkt te zijn,
wat niet het geval was toen ik de hurricane tunnel gebruikte.

Iemand diezelfde ervaring, of tips om dit misschien op te lossen?
(kan altijd dat ik wat over het hoofd zie?)

vergelijken met een tracert of als het even kan een mtr. IPv6 heeft niet altijd de meest logische routes helaas zoals IPv4 deze wel kan hebben.

@webmeso: daar had ik ook al eens gekeken, maar echt nuttig artikeltje is dat niet he

het punt was, en is, dat ik aan mijn kant (thuis, ipv4) niets aangepast heb, en enkel op de server de tunnel heb verwijderd en het native ipv6 heb ingesteld.
daarna werd de verbinding over ipv4 trager - terwijl dit voorheen, met de tunnel, niet zo was.

wat ik me dan afvraag is waarom het (opmerkbare) verschil.

@yourwebhoster : ipv6 van de server uit naar bv google geeft een goede trace en mtr staat me ook aan.
het is dan ook niet zozeer dat ipv6 slecht reageert (de moeite om dat te testen heb ik zelfs nog niet gedaan met de native ips)

het probleem dat ik nu heb is dus dat ipv4 verbindingen sneller blijken als je een ipv6 tunnel gebruikt, dan dat je native gebruikt.
iets wat volgens mij eigenlijk niet zou mogen (ik zou zeggen, kunnen, maar alles kan tegenwoordig)?

edit: overzichtje van hoe merkbaar de vertraging is
geen vertraging: redirect naar een andere html
lichte vertraging: static site
merkbare vertraging: ajax site
enorme vertraging: webmail (roundcube)

Oorspronkelijk geplaatst door unchained

@yourwebhoster : ipv6 van de server uit naar bv google geeft een goede trace en mtr staat me ook aan.
het is dan ook niet zozeer dat ipv6 slecht reageert (de moeite om dat te testen heb ik zelfs nog niet gedaan met de native ips)

het probleem dat ik nu heb is dus dat ipv4 verbindingen sneller blijken als je een ipv6 tunnel gebruikt, dan dat je native gebruikt.
iets wat volgens mij eigenlijk niet zou mogen (ik zou zeggen, kunnen, maar alles kan tegenwoordig)?

Daar ben ik wel benieuwd naar, heb je dit gemeten dmv ping (IPv4)?

ondanks dat we er van uit gaan dat de instellingen goed zijn,
- Wat waren je tunnel IPv6 instellingen?
- Wat zijn je nieuwe (native) IPv6 instellingen?

Oorspronkelijk geplaatst door Yourwebhoster

Daar ben ik wel benieuwd naar, heb je dit gemeten dmv ping (IPv4)?

de ping voorheen (gemiddeld tussen de 25 en 28) en nu (gemiddeld tussen de 26 en 28) scheelt eigenlijk niets.
ook tracert over ipv4 toont geen opmerkelijke verschillen.

maar je merkt het enorm aan, vooral, de webmail, die voorheen ongeveer 1 seconde nodig had om een mail te openen,
tegenover nu zo'n minuut.

Ik denk dat het een vals alarm is ivm ipv6:
ik merk net in de traceroute dat 1 van de hops enorm schommelt naar mijn server toe,
terwijl diezelfde hop naar wht helemaal perfect blijft...

ondanks de geweldige timing zal het dus vast niet aan de ipv6 aanpassing liggen
(heb hem er voor de zekerheid net ook even volledig uitgegooid)

Code:

Bezig met het traceren van de route naar webmail.unchained.be [94.75.246.231] via maximaal 30 hops:
  1   <1 ms   <1 ms   <1 ms  10.0.0.1 
  2    19 ms    19 ms    19 ms  ip-83-134-88-1.dsl.scarlet.be [83.134.88.1] 
  3   237 ms   415 ms   302 ms  186.241-183-91.adsl-static.isp.belgacom.be [91.183.241.186] 
  4    22 ms    22 ms    22 ms  26.247-183-91.adsl-static.isp.belgacom.be [91.183.247.26] 
  5    29 ms    28 ms    28 ms  leaseweb.bnix.net [194.53.172.101] 
  6    28 ms    28 ms    28 ms  te9-2.sr7.evo.leaseweb.net [85.17.100.206] 
  7    28 ms    28 ms    28 ms  aeterna.unchained.be [94.75.246.231] 
De trace is voltooid.


Bezig met het traceren van de route naar webhostingtalk.nl [213.136.19.171] via maximaal 30 hops:
  1   <1 ms   <1 ms   <1 ms  10.0.0.1 
  2    20 ms    19 ms    19 ms  ip-83-134-88-1.dsl.scarlet.be [83.134.88.1] 
  3    22 ms    22 ms    22 ms  186.241-183-91.adsl-static.isp.belgacom.be [91.183.241.186] 
  4    22 ms    22 ms    22 ms  26.247-183-91.adsl-static.isp.belgacom.be [91.183.247.26] 
  5    28 ms    28 ms    28 ms  xe-0-3-0-5.r02.frnkge04.de.bb.gin.ntt.net [213.198.82.189] 
  6    28 ms    29 ms    28 ms  ae-3.r21.frnkge04.de.bb.gin.ntt.net [129.250.3.93] 
  7    44 ms    35 ms    35 ms  as-1.r23.amstnl02.nl.bb.gin.ntt.net [129.250.3.62] 
  8    35 ms    36 ms    41 ms  po-2.r01.amstnl02.nl.bb.gin.ntt.net [129.250.4.101] 
  9    31 ms    31 ms    33 ms  bit-0.r01.amstnl02.nl.bb.gin.ntt.net [81.20.69.254] 
 10    32 ms    32 ms    37 ms  webhostingtalk1.colo.bit.nl [213.136.19.171] 
De trace is voltooid.

Bezig met het traceren van de route naar webmail.unchained.be [94.75.246.231] via maximaal 30 hops:
  1   <1 ms   <1 ms   <1 ms  10.0.0.1 
  2    19 ms    19 ms    19 ms  ip-83-134-88-1.dsl.scarlet.be [83.134.88.1] 
  3   211 ms   199 ms   201 ms  186.241-183-91.adsl-static.isp.belgacom.be [91.183.241.186] 
  4    22 ms    22 ms    22 ms  26.247-183-91.adsl-static.isp.belgacom.be [91.183.247.26] 
  5    29 ms    28 ms    28 ms  leaseweb.bnix.net [194.53.172.101] 
  6    28 ms    28 ms    28 ms  te9-2.sr7.evo.leaseweb.net [85.17.100.206] 
  7    28 ms    28 ms    27 ms  aeterna.unchained.be [94.75.246.231] 
De trace is voltooid.

even afwachten zal dus de boodschap zijn

hmm, toch niet de oorzaak...

Code:

eth0      Link encap:Ethernet  HWaddr 00:30:48:88:87:10
          inet addr:94.75.246.231  Bcast:94.75.246.255  Mask:255.255.255.192
          inet6 addr: fe80::230:48ff:fe88:8710/64 Scope:Link
          inet6 addr: 2001:1af8:4400:a018:2::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25021 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14625 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6516638 (6.5 MB)  TX bytes:4145558 (4.1 MB)
          Interrupt:16

Code:

route -6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
2001:1af8:4400:a018::/64       ::                         Ue   256 0     3 eth0
fe80::/64                      ::                         U    256 0     0 eth0
::/0                           2001:1af8:4400:a018::1     UG   1   1   505 eth0
::/0                           ::                         U    1024 0     0 eth0
::/0                           ::                         !n   -1  1   809 lo
::1/128                        ::                         Un   0   1  1272 lo
2001:1af8:4400:a018:2::1/128   ::                         Un   0   1     2 lo
fe80::230:48ff:fe88:8710/128   ::                         Un   0   1   371 lo
ff00::/8                       ::                         U    256 0     0 eth0
::/0                           ::                         !n   -1  1   809 lo

Code:

ip -6 route
2001:1af8:4400:a018::/64 dev eth0  proto kernel  metric 256  expires 2584778sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:1af8:4400:a018::1 dev eth0  metric 1  mtu 1500 advmss 1440 hoplimit 4294967295
default dev eth0  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295

Code:

traceroute6 ipv6.google.com
traceroute to ipv6.google.com (2a00:1450:400c:c01::93), 30 hops max, 80 byte packets
 1  2001:1af8:4400:a018::1 (2001:1af8:4400:a018::1)  0.652 ms  0.718 ms  0.790 ms
 2  te0-0-0-5.crs.evo.leaseweb.net (2001:1af8::11)  1.633 ms  1.651 ms  1.636 ms
 3  swissix.google.com (2001:7f8:24::4a)  28.889 ms  28.897 ms  28.905 ms
 4  2001:4860::1:0:10 (2001:4860::1:0:10)  22.094 ms  22.082 ms  21.858 ms
 5  2001:4860::1:0:8 (2001:4860::1:0:8)  43.243 ms  21.554 ms  43.229 ms
 6  2001:4860::8:0:2daf (2001:4860::8:0:2daf)  21.549 ms  21.235 ms  21.190 ms
 7  2001:4860::8:0:2ac4 (2001:4860::8:0:2ac4)  32.011 ms  31.996 ms  31.980 ms
 8  2001:4860::2:0:87b (2001:4860::2:0:87b)  29.662 ms  29.638 ms  29.559 ms
 9  2001:4860:0:1::22f (2001:4860:0:1::22f)  32.429 ms  32.324 ms  32.338 ms
10  bru01m01-in-x93.1e100.net (2a00:1450:400c:c01::93)  28.508 ms  35.008 ms  28.611 ms

v6 op de server lijkt gewoon te werken, op thuiscomputer v6 disabled, en toch blijf ik merken dat als ik het op de server inschakel,
mijn verbinding sterk vertraagt...

iemand nog tips?

Oorspronkelijk geplaatst door unchained

hmm, toch niet de oorzaak...

Code:

eth0      Link encap:Ethernet  HWaddr 00:30:48:88:87:10
          inet addr:94.75.246.231  Bcast:94.75.246.255  Mask:255.255.255.192
          inet6 addr: fe80::230:48ff:fe88:8710/64 Scope:Link
          inet6 addr: 2001:1af8:4400:a018:2::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25021 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14625 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6516638 (6.5 MB)  TX bytes:4145558 (4.1 MB)
          Interrupt:16

Code:

route -6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
2001:1af8:4400:a018::/64       ::                         Ue   256 0     3 eth0
fe80::/64                      ::                         U    256 0     0 eth0
::/0                           2001:1af8:4400:a018::1     UG   1   1   505 eth0
::/0                           ::                         U    1024 0     0 eth0
::/0                           ::                         !n   -1  1   809 lo
::1/128                        ::                         Un   0   1  1272 lo
2001:1af8:4400:a018:2::1/128   ::                         Un   0   1     2 lo
fe80::230:48ff:fe88:8710/128   ::                         Un   0   1   371 lo
ff00::/8                       ::                         U    256 0     0 eth0
::/0                           ::                         !n   -1  1   809 lo

Code:

ip -6 route
2001:1af8:4400:a018::/64 dev eth0  proto kernel  metric 256  expires 2584778sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:1af8:4400:a018::1 dev eth0  metric 1  mtu 1500 advmss 1440 hoplimit 4294967295
default dev eth0  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295

Code:

traceroute6 ipv6.google.com
traceroute to ipv6.google.com (2a00:1450:400c:c01::93), 30 hops max, 80 byte packets
 1  2001:1af8:4400:a018::1 (2001:1af8:4400:a018::1)  0.652 ms  0.718 ms  0.790 ms
 2  te0-0-0-5.crs.evo.leaseweb.net (2001:1af8::11)  1.633 ms  1.651 ms  1.636 ms
 3  swissix.google.com (2001:7f8:24::4a)  28.889 ms  28.897 ms  28.905 ms
 4  2001:4860::1:0:10 (2001:4860::1:0:10)  22.094 ms  22.082 ms  21.858 ms
 5  2001:4860::1:0:8 (2001:4860::1:0:8)  43.243 ms  21.554 ms  43.229 ms
 6  2001:4860::8:0:2daf (2001:4860::8:0:2daf)  21.549 ms  21.235 ms  21.190 ms
 7  2001:4860::8:0:2ac4 (2001:4860::8:0:2ac4)  32.011 ms  31.996 ms  31.980 ms
 8  2001:4860::2:0:87b (2001:4860::2:0:87b)  29.662 ms  29.638 ms  29.559 ms
 9  2001:4860:0:1::22f (2001:4860:0:1::22f)  32.429 ms  32.324 ms  32.338 ms
10  bru01m01-in-x93.1e100.net (2a00:1450:400c:c01::93)  28.508 ms  35.008 ms  28.611 ms

v6 op de server lijkt gewoon te werken, op thuiscomputer v6 disabled, en toch blijf ik merken dat als ik het op de server inschakel,
mijn verbinding sterk vertraagt...

iemand nog tips?

Ik snap nog niet wat je nu doet, en waar iets trager wordt.

Je zet IPv6 aan op een server ergens en je IPv4 *thuis* computer gaat daar traag van surfen ?
Maar wat heeft je thuiscomputer met die server te maken, afgezien ervan dat ze beide van jou zijn ?

Of gebruik je (via remote desktop ofzo?) die server ook om vanaf te surfen ?
Of is het benaderen van jouw server vanaf jouw (ipv4) thuiscomputer trager nadat je IPv6 aanzet op die server ?

Eén pure gok die ik kan doen is kijken naar DNS; Als je server DNS resolving anders doet op moment dat IPv6 aanstaat kan dat een hoop scenario's verklaren, vooral indien je thuiscomputer ook je server als DNS resolver gebruikt.
Zie je iets nuttigs met tcpdump/wireshark ?

Oorspronkelijk geplaatst door visser

Ik snap nog niet wat je nu doet, en waar iets trager wordt.

Je zet IPv6 aan op een server ergens en je IPv4 *thuis* computer gaat daar traag van surfen ?
Maar wat heeft je thuiscomputer met die server te maken, afgezien ervan dat ze beide van jou zijn ?

Of gebruik je (via remote desktop ofzo?) die server ook om vanaf te surfen ?
Of is het benaderen van jouw server vanaf jouw (ipv4) thuiscomputer trager nadat je IPv6 aanzet op die server ?

Eén pure gok die ik kan doen is kijken naar DNS; Als je server DNS resolving anders doet op moment dat IPv6 aanstaat kan dat een hoop scenario's verklaren, vooral indien je thuiscomputer ook je server als DNS resolver gebruikt.
Zie je iets nuttigs met tcpdump/wireshark ?

het van thuis uit (ipv4) verbinden met mijn server gaat trager van zodra native ipv6 op de server ingesteld wordt.
bij de tunnel die ik voorheen had opgezet om dit allemaal te testen, was er geen verschil te merken.
zet ik op de server ipv6 weer uit, is de verbinding terug vlot.

dat mijn pc thuis fout geconfigureerd is zal het niet zijn: voorheen werkte hij vlot (toen de server een tunnel gebruikte)
en ik heb hier zelfs ipv6 ondertussen uit windows gegooid...

ik gebruik van hieruit enkel de dns van mijn isp, en het enige waar er vertraging op te merken valt is apache.
ftp, mail, ssh blijven allemaal vlot werken.

Oorspronkelijk geplaatst door unchained

het van thuis uit (ipv4) verbinden met mijn server gaat trager van zodra native ipv6 op de server ingesteld wordt.
bij de tunnel die ik voorheen had opgezet om dit allemaal te testen, was er geen verschil te merken.
zet ik op de server ipv6 weer uit, is de verbinding terug vlot.

dat mijn pc thuis fout geconfigureerd is zal het niet zijn: voorheen werkte hij vlot (toen de server een tunnel gebruikte)
en ik heb hier zelfs ipv6 ondertussen uit windows gegooid...

ik gebruik van hieruit enkel de dns van mijn isp, en het enige waar er vertraging op te merken valt is apache.
ftp, mail, ssh blijven allemaal vlot werken.

Dan denk ik nog steeds aan DNS; Heel veel server daemons doen een reverse DNS lookup voor een binnenkomende connectie.
Als die reverse lookup voor jouw connectie trager gaat bij (native) IPv6 kan dat het verschil zijn; Waarom dat eventueel zo is kun je later uitzoeken, nu zou ik eerst controleren _of_ dit de oorzaak is.
Ik zou inloggen (met ssh) op je server, en dan met tcpdump meekijken terwijl je een http connectie doet , naar alle verkeer behalve ssh;
Hoeft niet lang te duren, maar je wilt even capturen wat je server probeert te doen (en waarschijnlijk timeout) over het netwerk op moment dat je http connectie aankomt.

En ik ga ook voor de dns, zijn je services compiled met ipv6 support, heeft je server een ipv6 dns server tot zijn beschikking. Mocht dit niet het geval zijn dan zou een kleine hickup van timeouts een logische verklaring kunnen zijn (maar; niet alle services zullen daar last van hebben).

@visser: in tcpdump zie ik niet onmiddelijk iets dat de oorzaak zou zijn, ook geen enkele timeout ofzo.
@mikey: services zijn compiled met ipv6 en er is een dns server beschikbaar.

maar wel credit where it's due: visser en mikey, jullie hebben met het dns gedeelte wel de snelheid terug kunnen verbeteren.
het is nog steeds trager dan zonder ipv6, maar het is al terug doenbaar.

de ipv6 dns server stond onderaan in mijn resolv.conf ipv bovenaan.
kleine aanpassing, groot verschil
voor vandaag hou ik het bekeken, maar morgen ofzo nog wel even verderkijken waarom het nog steeds trager is,
en of het nog wat sneller kan.

Oorspronkelijk geplaatst door unchained

@visser: in tcpdump zie ik niet onmiddelijk iets dat de oorzaak zou zijn, ook geen enkele timeout ofzo.
@mikey: services zijn compiled met ipv6 en er is een dns server beschikbaar.

maar wel credit where it's due: visser en mikey, jullie hebben met het dns gedeelte wel de snelheid terug kunnen verbeteren.
het is nog steeds trager dan zonder ipv6, maar het is al terug doenbaar.

de ipv6 dns server stond onderaan in mijn resolv.conf ipv bovenaan.
kleine aanpassing, groot verschil
voor vandaag hou ik het bekeken, maar morgen ofzo nog wel even verderkijken waarom het nog steeds trager is,
en of het nog wat sneller kan.

Ik verwachtte een onbereikbare DNS server (en dus een query zonder antwoord, evt query over V6, geen antwoord, dan query over V4).
Je kunt nog even een tcpdump capture maken met IPv6 enabled en dan zonder IPv6.
DNS in relatie tot het probleem staat nu al aardig vast, dan is alleen de vraag of het puur een trager antwoord is, of dat indien IPv6 enabled is er misschien meer of andere queries gedaan worden.
Met wireshark (je kunt tcpdump een file laten schrijven, en die kopieren naar een desktop om met wireshark te openen) kun je overigens makkelijker tijdsverloop zien dan met tcpdump.

Je kunt je ook afvragen of je je server uberhaupt voor elke connectie dan blijkbaar een DNS lookup wilt laten doen; Zoals je gezien hebt geeft dat vertraging als DNS niet snel werkt.
Nog steeds wil je natuurlijk wel het probleem oplossen waarom de DNS lookups in de situatie met IPv6 enabled trager waren; Want als er een andere (v4?) DNS boven stond, werd die dan eerst geprobeerd en werkte die niet ?

Anyway, nog wat uit te zoeken maar ik denk dat nu de richting duidelijk is dat wel te vinden moet zijn.