IPv6 problém

[cert11]

Dobrý den,

v noci na dnešek přestala fungovat IPv6 komunikace. Z virtuálních strojů nelze pingnout do světa a ze světa nelze pingnout na tyto stroje.

Ping6 a tracert6 na VPS:

Kód: Vybrat vše

C:\>ping6 2a01:430:37::0011

Příkaz ping na 2a01:430:37::11
z 2002:5f81:641e:2:310c:b39c:3ca2:fc49 s délkou 32 bajtů:

Odpověď od 2a01:430:0:fe06::2: Cílová adresa není dostupná.
Odpověď od 2a01:430:0:fe06::2: Cílová adresa není dostupná.
Odpověď od 2a01:430:0:fe06::2: Cílová adresa není dostupná.
Odpověď od 2a01:430:0:fe06::2: Cílová adresa není dostupná.

Statistika ping pro 2a01:430:37::11:
    Pakety: Odesláno = 4, Přijato = 0, Ztraceno = 4 (ztráta - 100%),

C:\>tracert6 2a01:430:37::0011

Výpis trasy k 2a01:430:37::11
od 2002:5f81:641e:2:310c:b39c:3ca2:fc49 s nejvýše 30 směrováními:

  1       < 1 ms    < 1 ms    < 1 ms  2002:5f81:641e:2::1
  2        5 ms     5 ms     7 ms  2002:c058:6301::1
  3        6 ms     6 ms     6 ms  2001:1488:800:400::ffff
  4        6 ms     7 ms     6 ms  nix-ipv6.masterinter.net [2001:7f8:14::11:1]
  5        7 ms     6 ms     6 ms  praha-sitel-c1-vl261.ipv6.masterinter.net [2a
01:430:0:e::1]
  6        9 ms    12 ms    11 ms  brno-cejl-c1-vl559.ipv6.masterinter.net [2a01
:430:0:fe06::2]
  7        *        *        *     Vypršel časový limit žádosti.
  8        *        *        *     Vypršel časový limit žádosti.
  9        *        *        *     Vypršel časový limit žádosti.

Traceroute6 z VPS:

Kód: Vybrat vše

root@localhost1:~# traceroute6 2002:5f81:641e:1::1
traceroute to 2002:5f81:641e:1::1 (2002:5f81:641e:1::1), 30 hops max, 80 byte packets
 1  2a01:430:37::2 (2a01:430:37::2)  0.047 ms  0.018 ms  0.015 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *

Můžete prosím toto prověřit?
ID stroje : 327 a 109

Petr Fojt

[4smart.cz]

Dobry den.

Po dukladnem prozkoumani situace kolem nefunkcniho IPv6 jsem dosel k zaveru, ze problem se tykal pouze Vaseho VPS ID 327.
4smart.cz, ani Vas druhy VPS ID 109 po strance komunikace pres IPv6 nevykazoval problem.

Problem se zda byt hlubsiho charakteru - zrejme nejaka anomalie v pouzivanem jadre, ktera se projevovala tak, ze ackoliv byly zadany
routovaci cesty na HW stroji, Vas VPS nebyl ze sveta dostupny a nemohl komunikovat ani opacne. Na druhou stranu byl Vas VPS 327
pres IPv6 dostupny z jinych HW stroju, ktere vyuzivaji stejne sitove rozhrani pro vzajemnou komunikaci.

Overil jsem, ze byla zavedena vsechna potrebna routovaci pravidla a dale jsem zjistil, ze v logu systemu na HW stroji nejsou zadna zvlastni hlaseni,
nebo vypisy ze zasobniku,

Nicmene jsem dale zjistil, ze Vas VPS 327 trpi nedostatkem nastavene operacni pameti. Jestli nedostatek RAM na komunikaci pres IPv6
mel vliv si nejsem jist. Vas VPS jsem totiz nerestartoval, nebot jste byl prave prihlasen a zrejme s nim i pracoval. Proto jsem tuto teorii nemohl potvrdit.

Problem jsem vyresil opetovnym zavedenim potrebnych routovacich pravidel na HW stroji, kde se Vas VPS nachazi.

Timto prozatim celou vec uzaviram.

S pozdravem,
J. Marák

[jasan]

Myslím si, že niečo nie je s IPv6 v poriadku.

Napríklad:

Kód: Vybrat vše

$ ping6 www.ripe.net
PING www.ripe.net(www.ipv6.ripe.net) 56 data bytes
64 bytes from www.ipv6.ripe.net: icmp_seq=103 ttl=48 time=18.2 ms
64 bytes from www.ipv6.ripe.net: icmp_seq=104 ttl=48 time=18.1 ms
64 bytes from www.ipv6.ripe.net: icmp_seq=105 ttl=48 time=18.1 ms
64 bytes from www.ipv6.ripe.net: icmp_seq=106 ttl=48 time=18.1 ms
64 bytes from www.ipv6.ripe.net: icmp_seq=107 ttl=48 time=18.1 ms
64 bytes from www.ipv6.ripe.net: icmp_seq=108 ttl=48 time=18.2 ms
64 bytes from www.ipv6.ripe.net: icmp_seq=109 ttl=48 time=18.2 ms
64 bytes from www.ipv6.ripe.net: icmp_seq=110 ttl=48 time=18.2 ms
64 bytes from www.ipv6.ripe.net: icmp_seq=111 ttl=48 time=18.2 ms

--- www.ripe.net ping statistics ---
111 packets transmitted, 9 received, 91% packet loss, time 110018ms
rtt min/avg/max/mdev = 18.158/18.207/18.293/0.116 ms

Problémy som si všimol len tento týždeň, neviem presne povedať ktorý deň,
keď ma často vyhadzovalo z IRC, na ktoré som sa pripájal cez IPv6. Po prepnutí
IRC na IPv4 všetko funguje správne.

Dnes (2011-09-30) pred obedom som to otestoval aj vytvorením novej IPv6-only
Debian mašiny, ktorá tak isto lagovala dokonca aj vrámci SSH spojenia z inej VPS.

[4smart.cz]

Dobrý den.

Vašemu problému jsem se věnoval již v pátek, ale nic co by vypadalo jako problém se mi najít nepodařilo.
Ve Vašem výpisu příkazu ping nevidím nic zvláštního. Měl jste-li namysli poukázat na velkou odezvu, pak musím dodat, že
měřená odezva závisí velmi na tom, jakou cestou se pakety šíří a tedy jde i o to, odkud se ke svému VPS přes IPv6 připojujete.

Zde demonstrativně přikládám výpis z programu traceroute6, který ukazuje, že zpoždění (odezva) se docela razantně navyšuje již v počátku
cesty k VPS na 4smart.cz.

Kód: Vybrat vše

1  2a01:30:100a::1  0.844 ms  0.640 ms  0.536 ms
 2  2a01:30:1e0f:1::5  21.684 ms  20.433 ms  22.075 ms
 3  2a01:138:a006::1  21.712 ms  22.869 ms  21.558 ms
 4  ge3-2.cr1.NBG1.content-core.net (2a01:138:0:1a0::1)  21.056 ms  21.676 ms  21.263 ms
 5  Tenge1-1-51.cr2.MUC1.content-core.net (2a01:138:0:112::9)  24.185 ms  24.966 ms  23.328 ms
 6  ge1-1.cr1.PRG.CZ.content-core.net (2a01:138:0:11b::7)  23.188 ms  25.259 ms  23.358 ms
 7  2001:7f8:14::11:1  39.687 ms  41.708 ms  41.342 ms
 8  * praha-sitel-c1-vl261.ipv6.masterinter.net (2a01:430:0:e::1)  42.284 ms  41.103 ms
 9  brno-cejl-c1-vl559.ipv6.masterinter.net (2a01:430:0:fe06::2)  46.925 ms  46.801 ms  45.500 ms
10  2a01:430:37::1:2  45.345 ms  45.017 ms  43.311 ms
11  2a01:430:37::2  43.954 ms  44.671 ms  43.802 ms
12  2a01:430:37::2c  43.802 ms  45.312 ms  43.076 ms

Z výpisu je vidět, že k významnému zpoždění (v případě mé cesty) dochází celkem ve dvou bodech (2 a 8).
Naopak 4smart.cz(body 10, 11, 12) celkové zpoždění nenavyšují. Bod 12 je VPS (http://www.4smart.cz).

Je třeba poznamenat, že cesta IPv6 datagramů se liší od cesty IPv4 datagramů a zpoždění se odvíjí od vytížení jednotlivých uzlů po cestě,
jak ukazuje příklad z měření výše.

POZN:
Pro měření bylo využito tohoto nástroje:
http://www.berkom.blazing.de/tools/traceroute.cgi

POZN2:
Máte-li více VPS a za předpokladu, že se nacházejí na různých HW strojích 4smart.cz, můžete si ověřit, že zpoždění získané na strojích 4smart.cz v odezvě
je opravdu malé.

J.M.

[jasan]

Dovoľujem si tvrdiť, že predposledný riadok môjho výpisu určite nie je normálny:

Kód: Vybrat vše

111 packets transmitted, 9 received, 91% packet loss, time 110018ms

Niečo "zvláštne" sa dá spozorovať už tým, že odpovede na ICMP echo začínajú až
pri poradovom čísle 103, samozrejme len v tom konkrétnom prípade:

Kód: Vybrat vše

64 bytes from www.ipv6.ripe.net: icmp_seq=103 ttl=48 time=18.2 ms

[jasan]

Naviac, z cudzieho servera, ktorému IPv6 funguje dobre (tzn. môžem pingať ripe.net
minútu a nestratím jediný paket) to vyzerá takto (pingujem VPS, ktorá je na
4smart.cz):

Kód: Vybrat vše

$ ping6 -n olej.stredstreet.eu.org
PING olej.stredstreet.eu.org(2a01:430:37::3f) 56 data bytes
64 bytes from 2a01:430:37::3f: icmp_seq=1 ttl=60 time=7.96 ms
64 bytes from 2a01:430:37::3f: icmp_seq=2 ttl=60 time=7.94 ms
64 bytes from 2a01:430:37::3f: icmp_seq=3 ttl=60 time=7.93 ms
64 bytes from 2a01:430:37::3f: icmp_seq=4 ttl=60 time=7.90 ms
64 bytes from 2a01:430:37::3f: icmp_seq=5 ttl=60 time=8.03 ms
64 bytes from 2a01:430:37::3f: icmp_seq=6 ttl=60 time=7.96 ms
64 bytes from 2a01:430:37::3f: icmp_seq=7 ttl=60 time=7.90 ms
64 bytes from 2a01:430:37::3f: icmp_seq=8 ttl=60 time=7.96 ms
64 bytes from 2a01:430:37::3f: icmp_seq=9 ttl=60 time=7.92 ms
64 bytes from 2a01:430:37::3f: icmp_seq=10 ttl=60 time=7.91 ms
64 bytes from 2a01:430:37::3f: icmp_seq=11 ttl=60 time=7.91 ms
From 2a01:430:37::1 icmp_seq=13 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=14 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=15 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=16 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=17 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=18 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=19 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=20 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=21 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=23 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=24 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=25 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=26 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=27 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=28 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=29 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=30 Time exceeded: Hop limit
From 2a01:430:37::1 icmp_seq=31 Time exceeded: Hop limit
64 bytes from 2a01:430:37::3f: icmp_seq=33 ttl=60 time=7.95 ms
64 bytes from 2a01:430:37::3f: icmp_seq=34 ttl=60 time=7.93 ms
64 bytes from 2a01:430:37::3f: icmp_seq=35 ttl=60 time=7.96 ms
64 bytes from 2a01:430:37::3f: icmp_seq=36 ttl=60 time=8.02 ms
64 bytes from 2a01:430:37::3f: icmp_seq=37 ttl=60 time=7.92 ms
^C
--- olej.stredstreet.eu.org ping statistics ---
37 packets transmitted, 16 received, +18 errors, 56% packet loss, time 36050ms
rtt min/avg/max/mdev = 7.901/7.947/8.035/0.123 ms

Ďalej som zistil, že práve keď na druhej strane vypisuje chybu Hop limit, na strane
VPS je to stratený paket (ping bežal aj na vzdialenej mašine, ktorá pingala VPS,
aj na VPS, ktorý pingal vzdialenú mašinu).

[cert11]

Dobrý den,

musím souhlasit s uživatelem jasan, problém popisuje přesně. Již na základě jeho první zprávy z 30.9. jsem přes víkend provedl podobné pingací testy a z mého stroje ID 109 se pingy chovaly stejně. Ze stroje ID 327 pingy bez problémů. Jen doplním, že výpadky byly patrné i při pingání z jednoho VPS na druhý (oba běží na jiném HW stroji).
Nyní (4.10.2011 22:30) tento problém nepozoruji (po celkem cca 6000 pingech).

Ještě pár slov k mému prvnímu problému.
-- Restart stroje jsem při hledání problému prováděl (bylo to někdy v noci).
-- Dále se nedomnívám se, že za problém může nedostatek paměti.
-- Podle přiloženého traceroutu mě první hop odpovídal. A při traceroutu z druhé strany mám nyní mezi posledním hopem v nefunkčním stavu (přiložený obrázek) a odpovědí mého stroje ve funkčním stavu další hop (2a01:430:37::2). Vzhledem k výše uvedenému a tomu, že pomohlo opětovné zavedení routovacích pravidel na HW stroji (není to náhodou 2a01:430:37::2? ), se domnívám, že byl probém právě tady u vás v routování a problém se mohl týkat i ostatních VPS na tomto stroji (pokud tam někdo IPV6 využívá a problému si stihnul všimnout). Děkuji tímto za vaši snahu problém najít a za jeho odstranění.

S pozdravem a IPv6 vstříc

Petr Fojt

ping.png (23.72 KiB) Zobrazeno 7622 x

[4smart.cz]

Dobrý den,

Předně se omlouvám uživateli s loginem jasan, nevšiml jsem si totiž při mé předchozí reakci zde toho, že ve v onom výpisu
je uvedena ztráta paketů.

Jsem vděčný za odezvu všech uživatelů v tomto vlákně. Problém se zdá být stále tentýž - tedy že zcela náhle bez zjevné předchozí příčiny
se HW stroj najednou v souvislosti s nějakou IPv6 adresou začně chovat tak, jakoby neznal cestu k cílovému VPS, který má tuto IPv6 propůjčenu.
Přitom platí, že každý HW stroj zná cestu ke každému VPS s IPv6 adresou. Na celou věc nemá vliv uptime VPS, nebo to kdy byla IPv6 adresa přidělena.
Také bez vlivu se zdá být případný nedostatek nastavené operační paměti ve VPS. Problémová VPS se také z pohledu OpenVZ chovají zcela normálně
a není u nich zaznamenán nedostatek nějakého systémového prostředku nebo jaderného prostředku. Podobně čistý je i log na HW strojích.

Problém se mi skutečně včera podařilo ověřit na VPS uživatele jasan. Neudělal jsem však žádný reload routovacích pravidel. Pouze jsem experimentoval s příkazy
ping6 a traceroute6. Zdá se, že jakoby jejich použití "protáhlo" nefungující cestu. Problém se mi ale od včerejšího dne nepodařilo znovu navodit a to
ani experimentováním se zvláštním VPS a několika tisíci ICMP ping-pong zprávami (příkaz ping6). Navíc 4smart.cz nepoužívá dynamické routování a ověřil jsem, že všechna potřebná pravidla na všech HW strojích byla v době problémů zavedena. Také jsem zkontroloval, zda nemám chybu v konfiguraci IPv6 v jádře HW strojů. Ani zde jsem, zdá se, nepochybil.

Problém tedy může být buď na straně našeho poskytovatele připojení (to zatím nevylučuji ani nepotvrzuji), nebo v jádře OpenVZ, které používáme.
Hledal jsem v bugzile a nikdo podobný problém v kernelu zatím nehlásil a ani podobný problém nebyl oštřen v některé z novějších verzí stabilních větví kernelu.

Nezbývá než počkat, než se problém znovu objeví.
Dnes se ještě pokusím o pár nesmělých pokusů a pokud se objeví nějaká cesta vedoucí k příčině, budu zde o tom informovat.

J.M.

[4smart.cz]

Dobrý den,

Problém aktivně řešíme s naším poskytovatelem konektivity. Zdá se totiž, že problém může být mimo 4smart.cz, soudě na základě experimentů, které jsem dnes prováděl.

J.M.

[jasan]

Dobrý deň!

Na MasterInternet-gw.six.sk. (2001:7f8:2f::55) a z neho
na brno-cejl-c1-te8-1.ipv6.masterinter.net (2a01:430:0:fe0e::2) sa dostanem
vždy. Cesta odtiaľ je však už nejednoznačná. Viz. traceroute6 z jednej
konkrétnej mašiny na jednu konkrétnu VPS. Príkazy som spúšťal
za sebou s maximálne niekoľko-sekundovými rozdielmi v čase.

Typ 1:

Kód: Vybrat vše

# traceroute6 -n jasan.tk
traceroute to jasan.tk (2a01:430:37::3f), 30 hops max, 80 byte packets
...snip...
 3  2001:7f8:2f::55  5.667 ms  5.632 ms  5.675 ms
 4  2a01:430:0:fe0e::2  8.273 ms  8.307 ms  8.335 ms
 5  2a01:430:37::1:2  7.748 ms  7.726 ms  7.920 ms
 6  2a01:430:37::3f  7.967 ms * *

Typ 2:

Kód: Vybrat vše

[root@hnedy ~]# traceroute6 -n jasan.tk
traceroute to jasan.tk (2a01:430:37::3f), 30 hops max, 80 byte packets
...snip...
 3  2001:7f8:2f::55  5.672 ms  5.717 ms  5.777 ms
 4  2a01:430:0:fe0e::2  8.182 ms  8.454 ms  8.411 ms
 5  2a01:430:37::3:2  7.784 ms  7.752 ms  7.900 ms
 6  2a01:430:37::1:2  7.838 ms  7.918 ms  7.881 ms
 7  2a01:430:37::3f  7.852 ms  7.897 ms  8.063 ms

Typ 3:

Kód: Vybrat vše

# traceroute6 -n jasan.tk
traceroute to jasan.tk (2a01:430:37::3f), 30 hops max, 80 byte packets
...snip...
 3  2001:7f8:2f::55  19.279 ms  17.830 ms  17.903 ms
 4  2a01:430:0:fe0e::2  8.429 ms  8.493 ms  8.473 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * 2a01:430:37::3f  8.095 ms  8.044 ms

Vysledoval som teda tri typy odpovedí.

brno-cejl-c1-te8-1.ipv6.masterinter.net. (2a01:430:0:fe0e::2)
posiela pakety občas na 2a01:430:37::3:2 (bez PTR záznamu), ktorý ich prepošle
na 2a01:430:37::1:2, a občas priamo na 2a01:430:37::1:2. Niekedy sa však ani
po zvyšovaní TTL traceroute6 nedopingá na cieľovú mašinu (viz. Typ 3).

Podobné výsledky dostávam aj pri použití príkazu tracepath6:

Ekvivalent typu 1:

Kód: Vybrat vše

# tracepath6 -n jasan.tk
...snip...
 3:  2001:7f8:2f::55                                       6.126ms 
 4:  2a01:430:0:fe0e::2                                    8.592ms 
 5:  2a01:430:37::1:2                                      8.182ms 
 6:  2a01:430:37::3f                                       8.269ms reached
     Resume: pmtu 1500 hops 6 back 60

Ekvivalent typu 2:

Kód: Vybrat vše

# tracepath6 -n jasan.tk
...snip...
 3:  2001:7f8:2f::55                                       6.098ms 
 4:  2a01:430:0:fe0e::2                                    8.841ms 
 5:  2a01:430:37::3:2                                      8.191ms 
 6:  2a01:430:37::1:2                                      8.660ms asymm  5 
 7:  2a01:430:37::3f                                       8.591ms reached
     Resume: pmtu 1500 hops 7 back 60

Ekvivalent typu 3?

Kód: Vybrat vše

# tracepath6 -n jasan.tk
...snip...
 3:  2001:7f8:2f::55                                       6.103ms 
 4:  2a01:430:0:fe0e::2                                   86.900ms 
 5:  no reply
 5:  2a01:430:37::1:2                                    2056.534ms 
 7:  2a01:430:37::3f                                       8.265ms reached
     Resume: pmtu 1500 hops 7 back 60

Celé sa to chová omnoho lepšie než predtým, ale stále sa mi zdá, že niečo
občas nie je v poriadku a nejaký ten paket z času na čas vypadne (čo sa na
inom HW stroji na natívnom IPv6 nestáva).

Ping z 4smart.cz VPS:

Kód: Vybrat vše

--- www.ripe.net ping statistics ---
200 packets transmitted, 192 received, 4% packet loss, time 199049ms
rtt min/avg/max/mdev = 18.349/22.463/464.815/39.068 ms

Ping z iného HW stroja na IPv6:

Kód: Vybrat vše

--- www.ripe.net ping statistics ---
200 packets transmitted, 200 received, 0% packet loss, time 199293ms
rtt min/avg/max/mdev = 28.778/28.964/29.344/0.245 ms