Valokuitusen kuitu Telian liittymällä - iPv6 usein jumissa

Tässä vielä kuva jumituksesta. Eilen illalla oli jumissa ja korjaantu yöllä ja nyt illalla alkoi taas jumittamaan. Ipv4 toimii samaan aikaan ihan normaalisti.

Tuosta en osaa sanoa muutakun kun että ei ole ainakaan vaikuttanut ipv6 itsellä jumittavan että olis näkynyt mitään faktaahan ei ole heittää ja ei ole valokuitusta itsellä vaan telian taloyhtiökuitu. Mut heitin nyt ipv6sella vesilintua ja otin pois päältä kun monet sivut väitti mun osuvan ruotsissa ipv4 näyttää edes sinnepäin.

Minulla on Valokuitusen verkossa kilpailijan liittymä ja ipv6 tuntuu toimivan oikein. Olisko jotain ruuhkaa Teilan päässä tai vastaavaa

​@Helento, tässä tilanteessa kun ilmenee toistuvaa jumitusta, niin kannattaa jättää meille siitä häiriöilmoitus. Tässä saattaa olla kyseessä vikatilanne.

Tuo tähänkin jakamasi kuva on hyvä laittaa siihen liitteeksi, ja kertoa sanallisesti tilanteesta mahdollisimman tarkasti. Kun avaat antamani linkin, niin valitse alasvetovalikosta erikseen vielä vaihtoehto “häiriöilmoitus”, niin viestisi menee käsittelyyn suoraan häiriötilanteita käsittelevälle taholle. 

Ei olisi tuota ipv6 häiriöilmoitusta pitänyt tehdä. Nyt on koko yhteys poikki ipv4 myös. Meni eilen jo yhdeltä ja edelleen vika jatkuu. Varmaan säheltäneet sen rikki kun yrittäneet korjata ipv6:sta. Chatin kautta eivät osanneet auttaa muuta kuin lisätä edelliseen häiriöilmoitukseen lisätietoja. Alkaa jo tulla vanhaa elisan kaapelimodeemiyhteyttä ikävä. Se ei koko kahdentoista vuoden aikana ollut muutamaa tunnin parin katkoa pidempään poikki.

Harmillista kuulla, että mahdollinen vikatilanne koskee nyt myös IPv4-yhteyttä. Haluaisitko vielä tarkentaa, onko tämä uusi vika yhä käynnissä? On kuitenkin hyvä, että olet tehnyt häiriöilmoituksen, ja nyt chatin kautta ilmoitukseen on lisätty lisätietoja uuden vian osalta. Toivotaan, että ilmoituksen avulla yhteytesi saadaan nopeasti kuntoon! 🙏🏻

Soitin asiakaspalveluun ja ilmeisesti saivat hätisteltyä vikapuolen kaveria, kun 10 minuutin päästä alkoi ipv4 toimia. Ipv6 edelleen tökkii, mutta pääasia ettei ole kokonaan poikki.

Mahtavaa kuulla, että ainakin IPv4-yhteys toimii! 🙏🏻 IPv6-yhteyden osalta selvitys etenee tekemäsi häiriöilmoituksen kautta, ja sinuun ollaan yhteydessä sen tiimoilta. Haluaisitko vielä palata tänne tilannepäivityksen kera, kun asia on edennyt? 😊

Eltelin asentaja kävi keskiviikkona päivällä vaihtamassa kuitumuuntimen. En ollut itse silloin kotona, mutta oli pojan kanssa jutellut ja ei silloin mittauksissa löytänyt mitään vikaa. No ei varmaan löytänyt, koska silloin vikatilanne ei ollut päällä.

IPv6 toimikin normaalisti, kunnes perjantaina kolmen maissa alkoi taas jumittamaan ja vika jatkui puoleen yöhön.

Dumppasin icmp6 liikennettä muurilta vian ollessa päällä ja huomasin, että muuri lähettää aika agressiivisesti Neighbor Unreachability Detection (NUD) kyselyä gatewaylle ja koska GW on niin jumissa kestää siltä vastata ICMP6, neighbor advertisement, tgt paketilla. Alla pätkä kaappausta jossa pommitus näkyy.

19:54:42.299761 IP6 fe80::92ec:77ff:fe34:95cc > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:42.361723 IP6 fe80::92ec:77ff:fe34:95cc > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:42.425203 IP6 fe80::92ec:77ff:fe34:95cc > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:43.344048 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:43.407203 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:43.470197 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:43.614266 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, echo reply, id 5567, seq 26644, length 9
19:54:43.725497 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:43.789218 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:43.852192 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:44.114110 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:44.175707 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:44.239197 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:44.302293 IP6 fe80::92ec:77ff:fe34:95cc > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:44.365200 IP6 fe80::92ec:77ff:fe34:95cc > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:44.428194 IP6 fe80::92ec:77ff:fe34:95cc > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:44.491381 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:44.554203 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:44.616336 IP6 2001:2062::2:e821 > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:45.198538 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, neighbor advertisement, tgt is fe80::a67b:2cff:fe2f:161f, length 32
19:54:46.322792 IP6 fe80::92ec:77ff:fe34:95cc > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:46.386246 IP6 fe80::92ec:77ff:fe34:95cc > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:46.449236 IP6 fe80::92ec:77ff:fe34:95cc > ff02::1:ff2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
19:54:47.682934 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, neighbor advertisement, tgt is fe80::a67b:2cff:fe2f:161f, length 32

Alla uusi kaappaus tältä päivää kun vika tilanne ei ole päällä. Tässä nähdään, että GW vastaa välittömästi jokaiseen neighbor solicitation pakettiin.

12:58:34.725940 IP6 fe80::92ec:77ff:fe34:95cc > fe80::a67b:2cff:fe2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
12:58:34.727532 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, neighbor advertisement, tgt is fe80::a67b:2cff:fe2f:161f, length 32
12:58:35.383366 IP6 fe80::92ec:77ff:fe34:95cc > fe80::a67b:2cff:fe2f:161f: ICMP6, echo request, id 5567, seq 56883, length 9
12:58:35.384382 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, echo reply, id 5567, seq 56883, length 9
12:58:37.420668 IP6 fe80::92ec:77ff:fe34:95cc > fe80::a67b:2cff:fe2f:161f: ICMP6, echo request, id 5567, seq 56884, length 9
12:58:37.421691 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, echo reply, id 5567, seq 56884, length 9
12:58:39.437743 IP6 fe80::92ec:77ff:fe34:95cc > fe80::a67b:2cff:fe2f:161f: ICMP6, echo request, id 5567, seq 56885, length 9
12:58:39.438767 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, echo reply, id 5567, seq 56885, length 9
12:58:39.850728 IP6 fe80::92ec:77ff:fe34:95cc > fe80::a67b:2cff:fe2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
12:58:39.852245 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, neighbor advertisement, tgt is fe80::a67b:2cff:fe2f:161f, length 32
12:58:41.439450 IP6 fe80::92ec:77ff:fe34:95cc > fe80::a67b:2cff:fe2f:161f: ICMP6, echo request, id 5567, seq 56886, length 9
12:58:41.440509 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, echo reply, id 5567, seq 56886, length 9
12:58:43.530505 IP6 fe80::92ec:77ff:fe34:95cc > fe80::a67b:2cff:fe2f:161f: ICMP6, echo request, id 5567, seq 56887, length 9
12:58:43.531535 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, echo reply, id 5567, seq 56887, length 9
12:58:45.649770 IP6 fe80::92ec:77ff:fe34:95cc > fe80::a67b:2cff:fe2f:161f: ICMP6, echo request, id 5567, seq 56888, length 9
12:58:45.650801 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, echo reply, id 5567, seq 56888, length 9
12:58:45.919768 IP6 fe80::92ec:77ff:fe34:95cc > fe80::a67b:2cff:fe2f:161f: ICMP6, neighbor solicitation, who has fe80::a67b:2cff:fe2f:161f, length 32
12:58:45.922655 IP6 fe80::a67b:2cff:fe2f:161f > fe80::92ec:77ff:fe34:95cc: ICMP6, neighbor advertisement, tgt is fe80::a67b:2cff:fe2f:161f, length 32
 

Koitin eilen kun vika oli päällä ottaa muurista NUD:n pois käytöstä wanin suuntaan ja se vaikutti auttavan ongelmaan vaikkei juuri syytä korjaakkaan. 

Muutin pfsensessä Gateway monitorin pingaamaan Googlen ipv6 DNS osoitetta ja yhdessä Neighbor Unreachability Detection (NUD) pois ottamisen kanssa ipv6 on nyt toiminut normaalisti.

Itselläni hieman vastaavaa takeltelua toisinaan Telian oman fttb -liittymän IPv6 -liikenteen kanssa.

Oireina esimerkiksi "ping -6 www.google.com -t" noin joka kymmenennen paketin katoaminen, tai kotireitittimeltäni tuleva "Destination not reachable".
Vastaavasti Youtubesta sivu ei välttämättä lataa heti, vaan jää jumittamaan ja lataa vasta painettuani f5.
Myös Katsomossa/Ruudussa ollut selittämättömiä kuvanlaadun putoamisia, joihin tämä saattaa olla syyllinen.

Destination not reachablen innoittamana vilkaisin ensin reititystaulua, useimmilla kerroilla GW:n osoite sieltä löytyikin, 
jonka jälkeen katsoin reachable timeä, että kauanko tämän GW:n osoitteen pitäisi pysyä hyvänä (eth2 minulla kotireitittimen WAN interfacena):

Käyttäjä@Reititin:~$ sudo sysctl net.ipv6.neigh.eth2.base_reachable_time_ms
net.ipv6.neigh.eth2.base_reachable_time_ms = 120

Tämän jälkeen katsoin, mitä tälläisen pitäisi olla ja suuruusluokat alkoivat hyvin monessa paikassa vähintään 1000ms:stä. Esimerkiksi Debianissa oletusarvo on 30000ms
Koitin tämän jälkeen asettaa reachable timen käsin suurempaan arvoon:
Käyttäjä@Reititin:~$ sudo sysctl -w net.ipv6.neigh.eth2.base_reachable_time_ms=60000
net.ipv6.neigh.eth2.base_reachable_time_ms = 60000

Mutta, noin vartin päästä reachable time oli uudestaan 120ms:
Käyttäjä@Reititin:~$ sudo sysctl net.ipv6.neigh.eth2.base_reachable_time_ms
net.ipv6.neigh.eth2.base_reachable_time_ms = 120

Tämän jälkeen konsultoin hieman ChatGPT:tä, josta sain tietää että Router Advertisementseissa tulee mm. reachable time mukana.
ChatGPT ohjasi minut myös rdisc6 (kuuluu pakettiin ndisc6) -ohjelman pariin, jolla voi käsin pyytää Router Advertisementin ja katsoa sen sisältöä:

Käyttäjä@Reititin:~$ sudo rdisc6 eth2
Soliciting ff02::2 (ff02::2) on eth2...
Timed out.

Hop limit                 :           64 (      0x40)
Stateful address conf.    :          Yes
Stateful other conf.      :           No
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         4500 (0x00001194) seconds
Reachable time            :          120 (0x00000078) milliseconds
Retransmit time           :           60 (0x0000003c) milliseconds
 Source link-layer address: 00:00:5E:00:01:A1
 from fe80::a67b:2cff:fe2f:161f
 
rdisc6:n käytöstä selvisi, että Telia kehoittaa router advertisementseissaan asiakkaiden reitittimiä tarkistamaan yhteyden router solicitationilla 120ms käyttämättömyyden jälkeen.

Kohdattuani vielä tuon timeoutin ensimmäistä kertaa rdisc6:tta käyttäessäni, tarkistin TCPdump:sta, kauanko vastauksen saanti kestää ja tällä kertaa ensimmäisestä pyynnöstä ensimmäiseen toimitukseen kului yli 5 sekuntia, joka tuntuu jo selainkäytössäkin.

käytäjä@Reititin:~$ sudo tcpdump -i eth2 'icmp6 and (ip6[40] == 133 or ip6[40] == 134 or ip6[40] == 135 or ip6[40] == 136)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
17:18:17.907665 IP6 fe80::d2a7:51ff:fe8f:aa13 > ff02::2: ICMP6, router solicitation, length 8
17:18:21.909721 IP6 fe80::d2a7:51ff:fe8f:aa13 > ff02::2: ICMP6, router solicitation, length 8
17:18:23.387735 IP6 fe80::a67b:2cff:fe2f:161f > fe80::d2a7:51ff:fe8f:aa13: ICMP6, router advertisement, length 24

Tein tästä 120ms reachable timestä tänään 10.12.2025 vikailmoituksen, joista ensimmäinen suljettiin koska reitittimeni katsottiin olleen väärin asennettu katsottuani asiakaspalvelun pyynnöstä toisella laitteella IPv6 RA:ta.

Tein vielä uuden pyynnön, jossa toivottavasti artikuloin tämän ongelman (120ms Reachable time), mahdollisen syyn (aikayksikön muutos jäänyt huomaamatta router lifetimen konffauksen jälkeen) ja seuraukset (Asiakkaiden reitittimet jumittavat Telian reitittimiä tarkistaessaan tarpeettoman usein näiden läsnäoloa.)

Summa summarum, mikäli vastaavia ongelmia muilla, niin tuo "rdisc6 <wan interface>" (kuuluu edelleen pakettiin ndisc6) on helppo tapa tarkistaa, voisiko tämä koskea myös itseä.

​@Helento :n kohdalla uskoisin, että kerta GW:n link-local -osoitekin on kopioitu, niin löytänet myös tuon saman reachable timen omasta liittymästäsi.

Tämä ongelma on voinut tähän asti mennä ihan laskentateholla IPv6:n ollessa harvakseltaan käytössä, mutta IPv6 -reitittimien lisääntyessä uskoisin ongelman nousevan voimakkaammin pintaan. Jos ajatellaan esimerkiksi sataa näin konfiguroidussa reitittimessä kiinni olevaa IPv6 asiakaslaitetta*, nämä tuottaa jo kuitenkin ~830 Router Solicitationia sekunnissa, joka puolestaan saattaa tuntua suoritintehoissa ja vie tarpeetta sähköä tuottamatta juuri minkäänlaista lisäarvoa.

*mikäli eivät liikenteestä passiivisesti päivitä GW:n osoitetta.

Epäilen että telian telian ipv6 reitittimessä on hallintaprosessori aivan ylikuormittunut, koska tälläkin hetkellä pingin viiveet gw:tä pingatessa ovat päälle 5000 ms ja paketteja häviää. Samaan aikaan kun pingaan googlen nimipalvelimia latenssi on millisekunnin ja paketteja ei häviä lainkaan.

Varsinainen verkkoliikennehän menee reitittimissä omien nopeiden ASIC-piirien kautta, joten hallintaprosessorin jumittaminen ei siihen juurikaan vaikuta.

Pfsensessä otin Neighbor Unreachability Detectionin pois käytöstä komennolla

/usr/sbin/ndp -i ix3 -- -nud missä ix3 on telian suuntaan oleva rajapinta.

Tämä korjasi omalta osaltani ongelmat ipv6 liikenteen jumittelun osalta.

Linuxissa ei ilmeisesti tuota openbsd:n ndp komentoa ole vaan sama pitäisi hoitaa geminin tekoälyn  mukaan alla olevan kaltaisella komennolla.

sudo ip neigh replace <IP-OSOITE> lladdr <MAC-OSOITE> dev <VERKKOLAITE> nud permanent

Telian gw ping

[25.11-RC][admin@fw.kippila.com]/root: ping fe80::a67b:2cff:fe2f:161f
PING(56=40+8+8 bytes) fe80::92ec:77ff:fe34:95cc%ix3 --> fe80::a67b:2cff:fe2f:161f
16 bytes from fe80::a67b:2cff:fe2f:161f%ix3, icmp_seq=1 hlim=255 time=5386.467 ms
16 bytes from fe80::a67b:2cff:fe2f:161f%ix3, icmp_seq=4 hlim=255 time=5392.417 ms
16 bytes from fe80::a67b:2cff:fe2f:161f%ix3, icmp_seq=6 hlim=255 time=5390.742 ms
16 bytes from fe80::a67b:2cff:fe2f:161f%ix3, icmp_seq=7 hlim=255 time=5390.719 ms
16 bytes from fe80::a67b:2cff:fe2f:161f%ix3, icmp_seq=9 hlim=255 time=5389.421 ms
16 bytes from fe80::a67b:2cff:fe2f:161f%ix3, icmp_seq=10 hlim=255 time=5389.007 ms
16 bytes from fe80::a67b:2cff:fe2f:161f%ix3, icmp_seq=11 hlim=255 time=5387.927 ms
16 bytes from fe80::a67b:2cff:fe2f:161f%ix3, icmp_seq=12 hlim=255 time=5382.632 ms
^C
--- fe80::a67b:2cff:fe2f:161f ping statistics ---
21 packets transmitted, 8 packets received, 61.9% packet loss
round-trip min/avg/max/stddev = 5382.632/5388.666/5392.417/2.852 ms

Googlen dns ping
[25.11-RC][admin@fw.kippila.com]/root: ping 2001:4860:4860::8888
PING(56=40+8+8 bytes) 2001:2062::2:e821 --> 2001:4860:4860::8888
16 bytes from 2001:4860:4860::8888, icmp_seq=0 hlim=119 time=1.370 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=1 hlim=119 time=1.207 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=2 hlim=119 time=1.174 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=3 hlim=119 time=1.204 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=4 hlim=119 time=1.201 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=5 hlim=119 time=1.198 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=6 hlim=119 time=1.185 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=7 hlim=119 time=1.192 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=8 hlim=119 time=1.182 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=9 hlim=119 time=1.182 ms
^C
--- 2001:4860:4860::8888 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.174/1.210/1.370/0.055 ms

Vastaavaa kiinteän neighbour -merkinnän tekoa tarjottiin minullekin ChatGPT:n toimesta: “sudo ip -6 neigh add <ISP_next_hop_IP> lladdr <MAC> dev ethWAN nud permanent” kokeilin tätä, mutta kaatui muistaakseni siihen, että vastaalle neighborille oli jo automaattisesti luotu merkintä. Ongelma ei minua niin paljoa kuitenkaan nykyisellään häiritse, että olisin alkanut näkemään enempää vaivaa tämän merkinnän tekemiseksi esimerkiksi katkaisemalla yhteyden ulos, poistamalla dynaamisen merkinnän ja yrittämällä sitten uudestaan.

Laitoin ongelman tällä hetkellä vain seurantaan skriptin muodossa, joka suorittaa rdisc6:n kerran vuorokaudessa ja ilmoittaa helposti saatavilla olevaan, useampia kertoja viikossa tarkastettavaan logiin, onko tilanne ennallaan vai muuttunut.

Edelliseen viestiin oli myös tullut pieni ajatusvirhe tuon automaattisen 1000ms/120ms = 8,⅓ solicitationia sekunnissa per. liikenteetön asiakas: reitittimet toki päivittävät neighbour -tauluaan “passiivisesti” liikenteestä, mutta liikenteen puuttuessa merkinnät saanevat hapantua rauhassa, jolloin solicitationeita lähtee vain liikenteen vaatiessa. Lisäksi neighboureilla on nämä tilat:  INCOMPLETE → REACHABLE → STALE → DELAY → PROBE, jolloin GW on reachable -tilassa Telian määrittämät 120ms, muuttuu happamaksi, menee viivetilaan, on siellä oletuksena 5s, jonka jälkeen lähettää neighbour-/router solicitationin ja jos tässä solicitationissa kestää esimerkiksi tuo tukkeutuneesta reitittimestä mittaamasi keskimääräinen 5388ms, on tuloksena tyypillisesti timeout.

Kaivelin vielä hieman lisää lihaa luiden ympärille, joten päivän havainnot:

• GW:n link local -osoitteen perusteella GW on Nokian laite, jonka dokumentaatiossa ei anneta suositeltua alarajaa reachable timelle. Toisaalta arvon mittayksikkö, millisekunnit on selkeästi ilmaistu. Oletusarvona tämä on tyhjä, joka ainakin omalla kohdallani tarkoittaisi Linuxista periytyvää 30 sekuntia nykyisen 0,12s sijaan.
• GW ei ainakaan kirjoitushetkellä ole erityisen tukossa
• 5s viive ennen solicitationin lähetystä löytyy myös omasta reitittimestä:

Käyttäjä@reititin:~$ ping6 fe80::a67b:2cff:fe2f:161f%eth2
PING fe80::a67b:2cff:fe2f:161f%eth2(fe80::a67b:2cff:fe2f:161f%eth2) 56 data bytes
64 bytes from fe80::a67b:2cff:fe2f:161f%eth2: icmp_seq=1 ttl=255 time=6.45 ms
64 bytes from fe80::a67b:2cff:fe2f:161f%eth2: icmp_seq=2 ttl=255 time=1.08 ms
64 bytes from fe80::a67b:2cff:fe2f:161f%eth2: icmp_seq=3 ttl=255 time=1.01 ms
^C
--- fe80::a67b:2cff:fe2f:161f%eth2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 1.015/2.851/6.459/2.551 ms

Käyttäjä@reititin:~$ sudo sysctl net.ipv6.neigh.eth2.delay_first_probe_time
net.ipv6.neigh.eth2.delay_first_probe_time = 5

Kaivelin edellisiä arvoja myös dokumentaatioista ja tämä viive on mainittu oletusarvona kohdassa “11.2.5.11. delay_first_probe_time” sivulla https://linux.die.net/HOWTO/Linux+IPv6-HOWTO/proc-sys-net-ipv6..html, jolta löytyy myös reachable timen oletusarvo kohdasta “11.2.5.8. base_reachable_time" Oletan näiden kumpienkin arvojen olevan sekunteja, koska muuta ei ole mainittu ja esimerkiksi kohdassa “11.2.3.8. router_solicitation_delay” mainitaan näiden olevan nimenomaan sekunteja. Tämä mittayksiköiden yhtäkkinen muuttuminen ja mainitsemattomuus voinee olla juurisyynä sille, miksi tätä keskustelua yleensäkin käydään. 😁

Ainakin oma ongelma korjattiin vikailmoituksen tehtyäni.
Katsotaan kuulemma läpi muuallakin, onko jäänyt tarpeettoman pieniä arvoja.

Uudet arvot:

• Reachable time: 1 800 000ms / 30min
• Retransmit time: 5000ms