Pelipalvelut (Steam) katkovat yhteyttä, IPv6 ei toimi

  • Keskustelun aloittaja Keskustelun aloittaja svm
  • Aloitettu Aloitettu

svm

Liittynyt
29.09.2020
Viestejä
53
Mikähän vikana, kun pelipalveluista (Steam, Epic) tehtävät lataukset aiheuttavat katkoksia ja packet lossia kuituyhteyteen (Valokuitunen, Telian kuitupääte, yhteys Localnet 1000 / 1000)? Testiasetelma on seuraava:

A: Lataava kone (Verkkokortti -> ethernet-kaapeli -> Telian Kuitupääte Lan1-portti)
B: Toimeton kone (Verkkokortti -> ethernet-kaapeli -> Telian Kuitupääte Lan2-portti)
C: Testikone (WLAN -> mobiili-hotspot -> Elisan 4G-verkko)

Toisin sanoen A ja B ovat suoraan omilla kaapeleillaan kiinni kuitupäätteessä. Välissä ei ole mitään ylimääräisiä kytkentöjä, kytkimiä tai reitittimiä. Kone C on täysin eri verkossa kiinni. (Vertailun vuoksi olen myös testannut koneen ja kuitupäätteen välissä kolmea erilaista reititintä ja eri kaapeleita, mutta näillä ei ole ollut mitään vaikutusta.)

Testin aikana kuitupäätteessä ei ole kiinni mitään muita laitteita. Eli vain Lan1 ja Lan2 kiinni, joissa suoraan työasemat, muut portit vapaana.

Ainoa merkittävä kuorma on koneen A suorittama lataus. Latauksen aikana koko verkon toiminta muuttuu epävakaaksi. Kaikkein pahin on Steam. Se aiheuttaa throttlattunakin merkittäviä ongelmia. Epic aiheuttaa ongelmia myös, mutta ei samassa määrin. Sen sijaan esim. Ubuntu ISO Funetista ei aiheuta ainakaan merkittävää pätkimistä. Pääosin yhteys pysyy ihan käyttökelpoisena, mutta esim. videopalavereiden ja verkkopelien kanssa on ongelmia.

Esimerkiksi:

Laite A (kuitu): ei latausta käynnissä
Laite B (kuitu): ping -c 50 dns.google, packet loss 0 %
Laite C (4G): ping -c 50 <host B kuidun päässä>, packet loss 0 %

---

A: Ubuntu-ISOn lataus, funet.fi, n. 110 MB/s
B: ping -c 50 dns.google, packet loss 0 %
C: ping -c 50 <host B>, packet loss 0 %

---

A: Epic-lataus, ei throttlausta, toteutunut n. 90 MB/s
B: ping -c 50 dns.google, packet loss 0-1 %
C: ping -c 50 <host B>, packet loss 0-1 %

---

A: Steam-lataus, throttlaus 70 MB/s, toteutunut n. 50 MB/s
B: ping -c 50 dns.google, packet loss 2-10 %
C: ping -c 50 <host B>, packet loss 2-10 %

---

Samanlainen ilmiö havaittavissa myös vaikkapa komennolla "mtr -4tb dns.google". Idlenä missään hopissa ei tapahdu häviötä. Steam-latauksella puolestaan häviötä on joka vaiheessa.

Mielenkiintoista on myös, että kone A voi olla fyysisesti mikä tahansa laite. Käyttöjärjestelmänä voi olla Windows tai Linux. Toisin sanoen tätä ongelmaa ei aiheuta vain yksi tietty laite yhdellä tietyllä käyttöjärjestelmällä, vaan useampi laite erilaisilla käyttiksillä. Mikä tahansa niistä voi olla koneen A asemassa ja saada aikaiseksi saman ongelman käynnistämällä Steam-latauksen.

Telia on tutkinut yhteyden ja todennut, ettei vika ole heidän verkossaan tai kuitupäätteessä. Ja se onkin varmasti totta. Mutta mikä ihme tätä voi aiheuttaa? Ainoa yhdistävä tekijä koneiden A, B ja C kohdalla on kuitupääte, jonka kautta liikenne jossain vaiheessa kulkee.
 
Mikäs tuo Telian kuitupääte on tarkemmin ja onko se siltaavassa vai reitittävässä tilassa?
 
Mikäs tuo Telian kuitupääte on tarkemmin ja onko se siltaavassa vai reitittävässä tilassa?
Pääte on Genexis XG6846B
En tunne tarkemmin kun ovat sanoneet ettei saa ropeltaa. Ilmeisesti siellä on jokin SFP-portti jollain muuntimella tjsp. Ainoa asia, mitä tuolle saa tehdä, on kytkeä ethernet-kaapelit ja katkaista virran. Ja virrat onkin otettu pois pariin otteeseen, ei vaikutusta.

Laite on siltaavassa tilassa. Jokainen Lan-porttiin isketty härveli saa julkisen osoitteen (IPv4 ja IPv6). En tosin ole huomannut, että jomman kumman disabloimisella (työasemassa) olisi mitään vaikutusta.
 
Nostellaanpas tätä uusien havaintojen myötä. Rinnakkainen ongelma nimittäin näyttää olevan, ettei mikään kuitupäätteeseen suoraan kytketty laite oikeastaan toimi oikein, koska IPv6-osoitteissa on jotain häikkää. Jokainen kone saa siis peräti neljä IPv6-osoitetta:

- Link-local IPv6 fe80:...
- Temporary IPv6 2a0b:...
- IPv6 2a0b:... (Preferred)
- IPv6 2a0b:... (Deprecated)

Tuo deprecated-osoite annetaan välittömästi yhteyden muodostamisen jälkeen. Nslookupit päättyvät timeoutiin, traceroutet eivät mene läpi ja pingit IPv6-osoitteisiin tarkoittavat 100 %:n packet lossia. Näin tapahtuu sekä Windows- että Linux-laitteilla. Ainoa tapa saada yhteys toimimaan on ottaa IPv6 pois päältä tai pistää koneen ja kuitupäätteen väliin reititin, siten että reititin jakelee omia IPv6-osoitteitaan (tällöin reitittimen takana oleva tietokone saa kolme IPv6-osoitetta, koska tuo deprecated-osoite jää listalta pois). Mielenkiintoista kyllä, reitittimen takana piilossa oleva työasema pystyy tällöin pingaamaan esim. Googlen IPv6-osoitetta mutta reititin itse ei pysty.

Ei kenelläkään sattuisi olemaan mitään ajatuksia asiasta?

Operaattori on arvioinut, että kuitupäätteen softa pitäisi ehkä päivittää, mutta aikataulusta ei ole tietoa. Onko kenelläkään muulla, jolla on samanlainen setti (Valokuitusen kuitu, Genexis-pääte, LocalNetin yhteys) samanlaisia havaintoja?
 
Viimeksi muokattu:
Laittaisin jo tietoturvan takia väliin reitittimen. Nythän nuo koneet on tosiaan suoraan nettiin päin auki julkisella IP-osoitteella, eli ainakin palomuuri pitää olla kunnossa. IPv6 voi myös hyvin ottaa pois käytöstä ellet tuota välttämättä tarvitse. Nykypäivänä vieläkään läheskään kaikki palvelut ei IPv6 tarjoa, joten mikään välttämättömyys tuo ei ole.

En nyt äkkiseltään muuta keksi kun, että Steam ja Epic priorisoidaan ICMP-pakettien ohitse tai Steam/Epic luo sen verran monta yhteyttä, että vaikuttaa muuhun toimintaan.
 
Joo toki on tarkoitus käyttää reititintä välissä. Mutta LocalNet ihan erityisesti suosittelee ottamaan IPv6:n päälle. Ja Valokuitusen kytkentäohjeissa on seuraava esimerkki

ohje.png


joten mielestäni tämän kytkennän pitäisi kyllä silloin toimia, vaikka se ei paras ratkaisu olisikaan.

Sinänsä tuo IPv6 ei ole itselleni mikään ykkösprioriteetti, mutta omituista tässä on ongelmien kokonaisuus.

Valokuitunen mainostaa yhteyttä seuraavasti:
Huippunopea valokuituyhteys mahdollistaa vaativankin netinkäytön. Nettipelit tai etäpalaverit eivät pätki tärkeimmällä hetkellä eikä elokuvan huipentuma jää jumiin.

Joten ei mielestäni ihan vastaa gigaisen valokuidun tuotekuvausta, jos ainoa ratkaisu saada pätkimätön yhteys on throttlata lataukset alle 50 %:iin kapasiteetista ja ottaa IPv6 pois päältä.
 
Tuon Bufferbloat testin ajamisessa on ollut vähän ongelmia. Se jää todella usein jumiin (moniksi minuuteiksi tai pysyvästi) tuohon "warming up"-kohtaan. Tätä siis tapahtuu koneesta, kaapelista ja käyttöjärjestelmästä riippumatta. Onko tämä ihan normaalia?

Joka tapauksessa pääsääntöisesti, silloin kun testi menee loppuun asti, tuloksena on "Grade A". Mutta välillä tulee myös muuta, kuten alla. Tämä on siis ilman reititintä, eli kytkentä on
PC => Ethernet-kaapeli => Kuitupääte
Testin ajaksi otan kaikki muut laitteet päätteestä irti eikä testaavalla työasemalla ole muuta merkittävää liikennettä (käytännössä 0 / 0 kbps suurimman osan ajasta).
bb02.jpg
 
Jos tuo tosiaan antaa C:tä kummallakin koneella ja vielä kahdella eri käyttiksellä suoraan kuitupäätteestä, niin veikkaisin vikaa ISP:n puolella, joko tuossa kuitupäätteessä tai sitten jossain muualla.
 
  • Tykkää
Reactions: svm
Tuon Bufferbloat testin ajamisessa on ollut vähän ongelmia. Se jää todella usein jumiin (moniksi minuuteiksi tai pysyvästi) tuohon "warming up"-kohtaan. Tätä siis tapahtuu koneesta, kaapelista ja käyttöjärjestelmästä riippumatta. Onko tämä ihan normaalia?

Sen verta lainaan, että täällä myös yo kaltaisia ongelmia Bufferbloat testin kanssa.
Localnetin 1/1gb yhteys, pfsense riittävällä raudalla, client kone 10G lanissa kiinni.
Eli mistä lie johtuu?
 
Eli mistä lie johtuu?
En osaa kuin arvailla, mutta ehkä kyse ei vaan ole kovin tasalaatuisesta palvelusta. Ellei sitten ongelma ole LocalNetin puolella. Olen nyt jonkin verran tuota testaillut ja koneella tai selaimella, selaimen välimuistin tyhjennyksellä tai disabloimisella ei tunnu olevan vaikutusta. Elisan 4G-yhteydellä tuo testi on kyllä toiminut jo useita kertoja putkeen ilman jumiutumista. Tosin tällä hetkellä se toimii myös LocalNetillä paljon paremmin kuin aiemmin. Kummaa touhua.

Mutta mitä nyt muualta netistä katselee, niin vastaavia "warming up"-ongelmia tuntuu olevan muillakin. Ehkä tuo ei vaan ole kovin varmatoiminen testi.

Edit: Jaa-a. Juuri nyt sitten taas, kaksi konetta rinnakkain.
Elisa 4G: Useampia testikertoja läpi
LocalNet: Warming up...
 
Viimeksi muokattu:
jotain häikkää. Jokainen kone saa siis peräti neljä IPv6-osoitetta:

- Link-local IPv6 fe80:...
- Temporary IPv6 2a0b:...
- IPv6 2a0b:... (Preferred)
- IPv6 2a0b:... (Deprecated)

Ei tuo vielä vaikuta vialta. Mun Win11:ssa on aina 3 kpl 20xx-alkuista, 2 kpl fd-alkuista ja yksi fe-alkuinen ipv6-osoite.

Linuxi sai muistaakseni 2+2+1 kun kokeilin joskus.
 
En osaa kuin arvailla, mutta ehkä kyse ei vaan ole kovin tasalaatuisesta palvelusta. Ellei sitten ongelma ole LocalNetin puolella. Olen nyt jonkin verran tuota testaillut ja koneella tai selaimella, selaimen välimuistin tyhjennyksellä tai disabloimisella ei tunnu olevan vaikutusta. Elisan 4G-yhteydellä tuo testi on kyllä toiminut jo useita kertoja putkeen ilman jumiutumista. Tosin tällä hetkellä se toimii myös LocalNetillä paljon paremmin kuin aiemmin. Kummaa touhua.

Mutta mitä nyt muualta netistä katselee, niin vastaavia "warming up"-ongelmia tuntuu olevan muillakin. Ehkä tuo ei vaan ole kovin varmatoiminen testi.

Edit: Jaa-a. Juuri nyt sitten taas, kaksi konetta rinnakkain.
Elisa 4G: Useampia testikertoja läpi
LocalNet: Warming up...
Onko sulla localnetiltä julkinen ipv4 vai cgnatin privaatti-ip?
 
Ei tuo vielä vaikuta vialta.
Joo, se voi hyvinkin olla ettei vika ole tuossa. Oma IPv6-osaaminen on aika heikkoa, joten tämä oma diagnostiikkani on lähinnä arvailua.

Mutta sinänsä se IPv6-osoitteiden määrä on itselleni toissijaista. Enemmän häiritsee se, että DNS-hakukin epäonnistuu. Tai vaikkapa monet SSH-yhteydet. Ellen ota sitä IPv6:sta kokonaan pois päältä.

Onko sulla localnetiltä julkinen ipv4 vai cgnatin privaatti-ip?
Julkinen IPv4. Eli on toki mahdollisuus ottaa se IPv6 pois. Mutta sillä poistuu vain tuo IPv6-ongelma. Packet lossit, bufferbloat testin "warming up" ja muut ongelmat säilyvät. Eli olen miettinyt, onko näillä jokin yhteys.
 
Mitkä DNS-palvelimet on käytössä IPv4 ja IPv6?

Ne, jotka DHCP antaa. Esimerkiksi yksi Windows-kone ilmoittaa näin:
Koodi:
   DNS Servers . . . . . . . . . . . : 2a0b:5c80:170::170
                                       2a0b:5c80:171::171
                                       185.185.170.170
                                       185.185.171.171
                                       2a0b:5c80:170::170
                                       2a0b:5c80:171::171
En tiedä, onko normaalia, että tuossakin on IPv6-osoitteet kahdesti. Mutta tällaista sieltä operaattorin suunnalta tulee, kun kaapelin tuikkaisee kiinni puhtaaseen Win10-laitteeseen, jossa on uusimmat päivitykset, mutta ei mitään muita muutoksia, asetuksia tai ohjelmia (IPv4 ja IPv6 molemmat oletusasetuksilla eli automaattihaulla).
 
Yksi varteenotettava vaihtoehto on kun on tyrkitty winkkaria suoraan julkiseen verkkoon koneen saastuminen. Eli siellä voi olla bottia ja muuta ajossa viemässä verkkokaistaa. Lisäksi ilman nattia koneilla on rajallinen määrä IPv4 osoitteita, eli onkos ne loppuneet? Localnet saattaa tarjota vain yhden?
 
Palomuuri on Win-koneessa päällä. Lisäksi samanlaisen osoitesekamelskan saa myös Linux-kone, jossa siinäkin on palomuuri päällä. Samanlaisia kaistaongelmia on kaikilla koneilla. Lisäksi, kun kaikki koneet ovat tyhjäkäynnillä reitittimen takana, myös tämä esimerkin Win-kone joka on käynyt myös julkisessa verkossa, reititin kertoo WAN-liikenteen kokonaismääräksi 0.00 - 0.02 MB/s. Kovin raskasta bottiliikennettä ei näytä olevan.

LocalNetiltä olen tilannut palvelun, jossa on 5 kpl julkisia IPv4-osoitteita DHCP:llä. Edellisessä viestissä näkyneen testin aikana julkisessa verkossa oli kiinni reititin sekä tuo Win-kone. Lease-aika on 30 minuuttia ja useampaan tuntiin ainoa kiinni oleva laite oli tuo reititin. En missään kohtaa ole pitänyt 5 laitetta samanaikaisesti kiinni julkisesti, kuitupäätteessäkin on vain 4 porttia, mutta yön jäljiltä ei kuitenkaan olisi pitänyt olla kuin yksi lease voimassa. Edit: Niin ja reititin ei ole siltaava tms. Jokainen sen takana oleva laite saa 192.168-osoitteen, ei julkista.

----

Ja tarkennetaan nyt vielä sen verran, että ylipäätään näihin kaikenlaisiin testeihin ja IPv6-ihmettelyihin olen lähtenyt sen jälkeen, kun kotiin tuli valokuitu. Poika ilmoitti, että kavereiden kanssa pelaillessa hänellä yhteys katkeaa jatkuvasti ja hän lentää ulos sessioista. Se on se perusongelma.

Tarkoitus oli siis saada 4G-yhteyden tilalle nopeampi ja tasalaatuisempi yhteys. Kävikin päinvastoin. 4G:llä oli korkeat latenssit ym. mutta ei mitään tällaisia ongelmia. Kuriositeettina muuten mainittakoon, että alkuun verkon kokoonpano oli ihan sama reititintä myöten, sillä reitittimessä on sekä SIM-korttipaikka että WAN-ethernet-portti. Eli alkuun ainoa muutos oli vaihtaa SIM => WAN-portti. Kun reititin alkoi hakea verkkoyhteyden 4G:n sijaan kuidun kautta, ongelmat alkoivat. Valokuituun vaihtamista ennen mikään koneista ei ollut käynyt julkisessa verkossa, ei ollut yhteyden katkeamisia, ei ollut traceroute- tai nslookup-ongelmia.

Ja kyllä, myös reititin on vaihdettu, turhaan.

Julkisesti olen kytkenyt koneita verkkoon sen vuoksi, että Telian mukaan ongelma on siinä, että olen kytkenyt loopin tai reitittimen LAN-portin kuitupäätteeseen tai jokin muu vastaava ongelma. Joten vikaa ja omaa virhettä metsästäessäni olen tietenkin jättänyt koko reitittimen kokonaan välistä pois, jotta varmistun siitä, ettei ole kyse mistään tällaisesta virheellisestä kytkennästä. Mutta jos ainoa kuitupäätteelle menevä yhteys on suora yksittäinen ethernet-kaapeli yksittäisestä tietokoneesta, niin silloin ei kai syy voi olla missään loopissa.
 
Viimeksi muokattu:
Kokeilisin vaihtaa operaattorin omat DNSt vaikka nyt Googlen palveluun. Lähinnä eliminoimaan voisiko vika olla tässä. Ensin pelkkä IPv4 DNS, jättää IPv6n tyhjäksi. Sitten molemmat.

8.8.8.8
8.8.4.4
2001:4860:4860::8888
2001:4860:4860::8844
[th]
Via IPv4
[/th]​
[th]
Via IPv6
[/th]​
 
Kokeilisin vaihtaa operaattorin omat DNSt vaikka nyt Googlen palveluun. Lähinnä eliminoimaan voisiko vika olla tässä. Ensin pelkkä IPv4 DNS, jättää IPv6n tyhjäksi. Sitten molemmat.
Kokeilin vielä kertaalleen, ei valitettavasti hyötyä. Paitsi jos otan koko IPv6 pois päältä, mutta silloin toisaalta myös ISP:n oma DNS toimii ihan ok siinä missän Googlenkin.

Mutta jos IPv6 on päällä niin DNS-vaihto ei auta. Suorat IPv6-pingitkään eivät mene läpi, esim. ping 2001:4860:4860::8888. Tästä tulee 100 % packet lossia. (Ei siis mitään "no route to host", "unknown host" tms. vaan nimenomaan häviötä, lähetettyjä paketteja esim. 5 kpl, vastaanotettuja 0).
 
Se on ihan normaalia, että tulee useampi IPv6 osoite

- fe80: laite generoi tämän aina ja yrittää tämän verkon kautta löytää reitittimen (vastaa 169. alkuisia osoitteita IPv4 maailmassa)
- preferred, varsinainen ipv6 mikä generoituu verkkokortin mac osoitteen perusteella tms
- temporary, vaihtuu päivittäin, kone juttelee yleensä tällä nettiin. Tämä lisättiin jossain vaiheessa kun itkettiin yksityisyyden suojasta
- deprecated, expiroitunut osoite. Ei saa avata enää uusia yhteyksiä ulos, mutta säilytetään jos joku yrittää yhdistää koneeseen tällä.

Windowsin palomuuri muistaakseni blokkaa ainakin icmpv6 kun se on public profiilissa, mikä on aiheuttanut jonkin verran ihmettelyä kun testit failaa.

Ongelma kuulostaisi siltä kuin jossain reitittimessä matkan varrella täyttyisi puskurit tai sessiotaulut menisi täyteen. Mulla on valokuitunen, Telia 1000/500, joku genesiksen modeemi, Mikrotik RB5900 reititin ja langattomassakin tulee bufferbloat tulokseksi A.
 
  • Tykkää
Reactions: svm
Windowsin palomuuri muistaakseni blokkaa ainakin icmpv6 kun se on public profiilissa, mikä on aiheuttanut jonkin verran ihmettelyä kun testit failaa.
Ok, tätä en tiennyt ja on kyllä selkeästi oma virhe kun en tätä osannut ottaa huomioon. Toisaalta ihme kun eivät LocalNetilläkään sanoneet, että huomioithan tämän.

Mutta voikohan reititin (Asus) tehdä jotain samanlaista? Kun nimittäin sekään ei saa noita läpi. Tämä siis Asuksen diagnostiikasta:

Koodi:
PING 2001:4860:4860::8888 (2001:4860:4860::8888): 56 data bytes

--- 2001:4860:4860::8888 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
 
Ok, tätä en tiennyt ja on kyllä selkeästi oma virhe kun en tätä osannut ottaa huomioon. Toisaalta ihme kun eivät LocalNetilläkään sanoneet, että huomioithan tämän.

Mutta voikohan reititin (Asus) tehdä jotain samanlaista? Kun nimittäin sekään ei saa noita läpi. Tämä siis Asuksen diagnostiikasta:

Ei tuosta Windows palomuurihommasta ole paljoa juttua näkynyt Redditissä tai muualla. Selvisi kun olin pari tuntia hakannut päätä seinään.

On mahdollista, että se Asuksen IPv6 pino on jotenkin rikki tai solmussa. Mikä malli? Reitittimen pitäisi mielestäni hakea DHCPv6:lla isompi allokaatio esim /56 mistä reititin voi pilkkoa useamman /64 aliverkon joihin koneet tulee.

Kokeilin piuhalla vielä Bufferbloat testiä https://www.waveform.com/tools/bufferbloat, jälkimmäinen on Steam lataus päällä. Jostain syystä tuo sivusto ei saa download nopeutta yli 500Mbit, mutta Speedtest antaa sitten 900/450 Mbit. Ubuntulla kun Windows 24H2 päätti hajoittaa koneen boottaamattomaan tilaan.

bufferbloat_unloaded.pngbufferbloat_steamdownload.png
 
Viimeksi muokattu:
On mahdollista, että se Asuksen IPv6 pino on jotenkin rikki tai solmussa. Mikä malli? Reitittimen pitäisi mielestäni hakea DHCPv6:lla isompi allokaatio esim /56 mistä reititin voi pilkkoa useamman /64 aliverkon joihin koneet tulee.
RT-BE58U (RT-BE58U||ASUS Suomi). Uusin FW. Bootattu useampaan kertaan. En nyt ihan tarkkaan ymmärrä miten IPv6:ssa nämä pilkotaan mutta reitittimen prefix on juuri 56 ja työasemilla 64.

Tarkasta suorittimesta en tiedä, mutta mainostetaan "quad core" ja muistia 1 Gt. Bufferbloat testin aikana tuossa ei juuri CPU rasitu, välillä jokin ytimistä käväisee reilussa 10 %:ssa.

Kokeilin piuhalla vielä Bufferbloat testiä https://www.waveform.com/tools/bufferbloat, jälkimmäinen on Steam lataus päällä.
Olisipa itsellänikin tuollaista. Grade on maks. A ilman reititintäkin (1 kone suoraan kaapelilla kuitupäätteessä) ja silloinkin latenssit ovat tyypillisesti tuollaista + 20 ms molempiin suuntiin latauksen aikana. Joskus hyvin satunnaisesti sitten putoaa B- tai C-luokkaan. Toki nopeudet suurempia mutta DL-nopeudessa kova vaihtelu, lopullinen lukema vaihtelee 600 - 900 Mbps.
 
RT-BE58U (RT-BE58U||ASUS Suomi). Uusin FW. Bootattu useampaan kertaan. En nyt ihan tarkkaan ymmärrä miten IPv6:ssa nämä pilkotaan mutta reitittimen prefix on juuri 56 ja työasemilla 64.

Tarkasta suorittimesta en tiedä, mutta mainostetaan "quad core" ja muistia 1 Gt. Bufferbloat testin aikana tuossa ei juuri CPU rasitu, välillä jokin ytimistä käväisee reilussa 10 %:ssa.

En tuosta löytänyt muuta kuin, että suunnilleen noin IPv6 asetukset pitäisi varmaan siinä reitittimessä olla: https://kmpic.asus.com/images/2020/10/21/279c5856-18be-4b59-8e83-343d4d7da790.png

Tuosta reitittimestä ei kerrota juuri missään mikä sen firewall troughput olisi. Eipä tuossa Mikrotikissäkään ole tuon kummempaa prosessoria sen puoleen.
 
  • Tykkää
Reactions: svm
IPv6ssa hommat bugaa, jos ICMP ei toimi. Saatko pingattua default-gw:tä koneeltasi IPv6:lla?
IPv6:n default GW on Win10-koneella tuollainen fe80-alkuinen. Onkohan normaalia? Siis Win10-koneella, jolla automaattinen IPv4/IPv6 päällä ja suoraan kaapelilla kiinni kuitupäätteessä. Ei reititintä.
Joka tapauksessa tuohon default-gw:n fe80-osoitteeseen ping kulkee läpi saman tien. Ei tarvita edes mitään palomuurimuutoksia.

Enabloin ICMPv6:n. Kuten ohjeessa, mutta lisäksi myös julkisissa verkoissa. Ping verkkoon, esim. "ping 2001:4860:4860::8844" (dns.google) ei mene läpi edelleenkään. Mutta ei se mene vaikka otan koko palomuurin pois päältä. (Tiedän, ei järkevää, mutta kone tyhjennetään kuitenkin kunhan sitä ei tarvitse enää näihin testeihin.)
 

Statistiikka

Viestiketjuista
258 278
Viestejä
4 486 107
Jäsenet
74 132
Uusin jäsen
Jaakko0000000

Hinta.fi

Back
Ylös Bottom