Likes: 0
30/06/11 16:17
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?)
30/06/11 16:34
30/06/11 16:38
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.Oorspronkelijk geplaatst door unchained
Met vriendelijke groet, Yourwebhoster.eu - Managed VPS diensten met Epyc performance op 100% SSDs
Lees hier de webhostingtalk.nl forum regels en voorwaarden!
30/06/11 16:50
@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)
Laatst gewijzigd door unchained; 30/06/11 om 16:52. Reden: extra info
30/06/11 16:52
Daar ben ik wel benieuwd naar, heb je dit gemeten dmv ping (IPv4)?
Met vriendelijke groet, Yourwebhoster.eu - Managed VPS diensten met Epyc performance op 100% SSDs
Lees hier de webhostingtalk.nl forum regels en voorwaarden!
30/06/11 17:00
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?
30/06/11 17:03
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.
30/06/11 17:14
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)
even afwachten zal dus de boodschap zijnCode: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.
30/06/11 20:02
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:16Code: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 loCode: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 4294967295v6 op de server lijkt gewoon te werken, op thuiscomputer v6 disabled, en toch blijf ik merken dat als ik het op de server inschakel,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
mijn verbinding sterk vertraagt...
iemand nog tips?
30/06/11 21:27
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 ?
30/06/11 21:42
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.
30/06/11 22:12
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.
30/06/11 23:00
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).
"Zo zijn ook wij één leverancier. Dé leverancier in gedegen Linux kennis, wanneer jij dat nodig hebt."
Boek je admin vandaag nog via : www.admin.nu
Gevestigd in Nederland en Moldavië
Lees hier de webhostingtalk.nl forum regels en voorwaarden!
30/06/11 23:34
@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.
30/06/11 23:55
Ik verwachtte een onbereikbare DNS server (en dus een query zonder antwoord, evt query over V6, geen antwoord, dan query over V4).@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.
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.
Quote