Permalänk
Medlem

Ownit i Sundsvalls-regionen

Hej!

Ser att tråden före mig är ett par månader och även den med Ownit-problem.. De har verkligen dekat ner sig... Hur som haver, Ad Rem! Till saken!

Någon som bor i / kring Sundsvall som orkar köra mtr eller liknande och se om ni också får en massa DUP! svar och blir pucko-routade mellan olika routrar? Detta är så illa att OpenSSL ( https ) blir skevt i vissa lägen, men framförallt är det irriterande och ser förjävligt ut.

Exempel på att köra

mtr ping.sunet.se

Notera vid redan hoppet utanför mig själv börjar det lekas ping-pong och skeva ur. Har skrivit till Ownit, men eftersom jag numera har lång och diger erfarenhet av hur dålig deras support är sätter jag ingen större tilltro till det, så tänkte jag börjar sondera om andra har samma bekymmer och om vi i såfall och synka för att få detta rappel löst.

Visa signatur

ASRock X870E Nova WIFI / Ryzen 9800X3D (CO: -45 AC) / Corsair Vengance 64GB DDR5 6000MHz CL30 / Crucial T705 1TB Gen5 + 5.5TB sekundära / ASUS TUF 4080 Gaming OC / Seasonic Focus GX 850W ATX 3.1 / Acer Predator XB273UGX 1440p 270 Hz G-Sync / FD Torrent Compact / Thermalright Phantom Spirit 120 SE / Evo 4 / Sennheiser IE 300 / Rode NT1-A
Synology 1621+ 6*16 / 1513+ 5*8 / LG CX 65" / XBox Series X

Permalänk
Medlem

Jag förstår inte vilket konkret problem du lider av. Det närmsta konkret du kommer är "HTTPS blir skevt i vissa lägen" vilket är flummigt och rent ut sagt omöjligt att tolka. Det enda du delar är en traceroute som i mitt tycke inte visar på något som helst fel. Det syns ingen packetloss längs vägen.

Att svarstider varierar (hopp 4 t.ex) är normalt då trafik genom en router inte är samma sak som trafik till en router. Trafik som passerar genom en router passerar direkt i hårdvaran (ASICs), men trafik där routern är slutmottagaren måste skickas till CPU. Att svara på ping har väldigt låg prio i routerns CPU, så det kan ta en bra stund (flera millisekunder) innan den väljer att svara på paketet.

Om du istället skickar en ping som bara ska passera genom routern behöver paketet inte passera CPU utan vidarebefordas direkt i linjekort/ASIC där throughput är väldigt mycket högre. Det är därför du kan se högre svarstider på hopp 4 än hopp 5. Enda gången latency är relevant är om alla hopp efter hopp 4 visar lika dålig latency som hopp 4 gör, då finns det starka indikationer på att något är knas mellan hopp 3 och hopp 4. Men eftersom hopp 5 ovan visar låg latency så är det inget fel på vägen i övrigt.

Om vi istället kollar på antalet routrar vid varje hopp så kan vi på flera hopp se flera routrar. Detta innebär att trafiken lastbalanseras mellan flera routrar längs vägen. Också detta är helt normalt, då det bästa sättet att hålla stabilitet och upptid i nätet är att ha redundans i form av flera routrar som kör parallellt. Det är också värt att nämna att du ser flera routrar på varje hopp tacke vare ICMP/MTR som i detta fallet genererar olika payloads för att sprida trafiken över så många hopp som möjligt för att visualisera alla routrar längs vägen.

Skulle du köra en ensam TCP session (HTTPS) så kommer alla paket i det TCP-flowet att passera exakt samma väg. Detta är möjligt då routern använder "ECMP 5tuple hashing (src ip, dst ip, protocol, src port, dst port)" för att bestämma vilken väg trafiken ska gå. Eftersom denna 5tuple är densamma under hela sessionen så går trafiken alltid samma väg. Så det är skillnad på att mäta med MTR (som använder ICMP) mot att skicka faktisk data med TCP/UDP.

Jag hoppas allt mitt svamlande varit till nytta för dig, att det hjälpt dig tolka den output som du skickade med när du skapade tråden. Gällande "skev HTTPS" är det svårare att vara hjälpsam, jag hoppas du kan fylla på med mer information där.

Visa signatur

CCNP Enterprise + SPCOR
FCSS Network Security

Permalänk
Medlem

Problemet är konkret att den hoppar på två olika routrar direkt efter att det lämnat mitt it-snöre och detta leder till att samtliga paket dupliceras. Det illustreas i MTR-bilden genom att du har flera intill-liggande routrar med samma TTL-värde. Detta leder till fenomen som:

$ ping ping.sunet.se PING ping.sunet.se (192.36.125.18) 56(84) bytes of data. 64 bytes from ping.sunet.se (192.36.125.18): icmp_seq=1 ttl=57 time=6.25 ms 64 bytes from ping.sunet.se (192.36.125.18): icmp_seq=1 ttl=57 time=6.33 ms (DUP!) 64 bytes from ping.sunet.se (192.36.125.18): icmp_seq=2 ttl=57 time=6.27 ms 64 bytes from ping.sunet.se (192.36.125.18): icmp_seq=2 ttl=57 time=6.28 ms (DUP!)

... samt andra sattyg som gör att HTTPS blir ledset i ögat när det kommer multipla challange/response i:

* TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20):

... flödet, som istället blir:

* Recv failure: Connection reset by peer * OpenSSL SSL_connect: Connection reset by peer in connection to xxxx.yy:443 * Closing connection 0 curl: (35) Recv failure: Connection reset by peer

... som exempel på hur "https skevar ur" när det skickas samma paket flera gånger.

Hoppas det var tydligare! Kändes onödigt att gå in så pass i detalj, när jag egentligen var intresserad av om fler hade samma problem.

Visa signatur

ASRock X870E Nova WIFI / Ryzen 9800X3D (CO: -45 AC) / Corsair Vengance 64GB DDR5 6000MHz CL30 / Crucial T705 1TB Gen5 + 5.5TB sekundära / ASUS TUF 4080 Gaming OC / Seasonic Focus GX 850W ATX 3.1 / Acer Predator XB273UGX 1440p 270 Hz G-Sync / FD Torrent Compact / Thermalright Phantom Spirit 120 SE / Evo 4 / Sennheiser IE 300 / Rode NT1-A
Synology 1621+ 6*16 / 1513+ 5*8 / LG CX 65" / XBox Series X

Permalänk
Medlem

När du säger "andra verktyg" kör du dessa mot samma adress (ping.sunet.se)? Hur är det i verkliga livet, har du samma problem oavsett vilken web-sida du besöker?

Kan det vara något åt det här hållet, med en mismatch mellan TLS-protokollversionerna?
https://stackoverflow.com/questions/27936062/connection-reset...
Du kanske kan felsöka vidare med det lilla verktyget som nämns. (analyze.pl)

Permalänk
Medlem
Skrivet av mc68000:

När du säger "andra verktyg" kör du dessa mot samma adress (ping.sunet.se)? Hur är det i verkliga livet, har du samma problem oavsett vilken web-sida du besöker?

Kan det vara något åt det här hållet, med en mismatch mellan TLS-protokollversionerna?
https://stackoverflow.com/questions/27936062/connection-reset...
Du kanske kan felsöka vidare med det lilla verktyget som nämns. (analyze.pl)

Har testat både på windows och linux, samma fel på ca. 10 hostar, det är även samma fel direkt från Ubiquiti-routern som sitter direkt kopplad, så det känns inte som "mjukvarufel" direkt, med tanke på att om jag kopplar in samma utrustning på en annan ISP (har tillgång till fler än en) så fungerar allt fofinontot. Inga DUP:s och HTTPS fungerar 100/100 istället för 1/100. Det är således relativt uteslutet att det är mjukvaru- eller hårdvaru-relaterat då jag kan förutsägbart få eller inte få dessa fel genom att byta vilket jack jag kör in routern i och Ownit är fel 100% av tiden och annan leverantör 0% av tiden.

Jag ville som sagt inte gå in alltför djupt i detta, sonderingen var om fler med Ownit i Sundsvalls-området upplevde samma sak och sedan ta det därifrån, jag sökte inte efter "hjälp" utan frågan var om andra hade samma sak.

Visa signatur

ASRock X870E Nova WIFI / Ryzen 9800X3D (CO: -45 AC) / Corsair Vengance 64GB DDR5 6000MHz CL30 / Crucial T705 1TB Gen5 + 5.5TB sekundära / ASUS TUF 4080 Gaming OC / Seasonic Focus GX 850W ATX 3.1 / Acer Predator XB273UGX 1440p 270 Hz G-Sync / FD Torrent Compact / Thermalright Phantom Spirit 120 SE / Evo 4 / Sennheiser IE 300 / Rode NT1-A
Synology 1621+ 6*16 / 1513+ 5*8 / LG CX 65" / XBox Series X