UPC - GW-nél elakadt csomagok ?

Hálózatok általános

A következő jelenséget vettem észre,hogy a GW-nél "eltűnnek" csomagok, ugyan a végcélnál rendesen ott vannak de furcsállom,ennek mi lehet az oka? hálózati hiba UPC-nél ? már ha ez hiba...

https://prohardver.hu/dl/upc/2018-07/26422_asd_2.jpg

  • 1845 megtekintés

( thxer v | 2018. 07. 26., cs – 15:51 )

Általában a routerek előrébb veszik prioritásban a csomagtovábbítást / routinggal kapcsolatos feladatokat. Az icmp válasz / ttl exceeded üzenet kisebb prioritást élvez, így előfordulhat magas válaszidő vagy hogy egyáltalán nem küld választ ezekre. Ahogy a fenti képből is látszik, a célállomás az összes csomagra válaszolt, tehát az a router továbbított minden csomagot.

( bucko | 2018. 07. 26., cs – 17:29 )

UPC+GW:
Próbáld meg pingetni a gatewayt. Normál esetben 6..8ms lehet - ez tulajdonképpen az RTT.
Egyes esetekben a válaszidő elérheti az 1000..4000ms értéket. Minél nagyobb értékű a késleltetés, annál valószínűbb a csomagvesztés. A kábelmodem újraindítása után általában visszaáll a normál értékre.

Nem a kábelmodem a hibás, mert a jelenségnek volt olyan elfajult esete, amikor az újraindítás sem segített, miközben az RTT egyre csak nőtt.

A jelenség okozója valamelyik UPC eszköz lehet. "Normál internetezés" mellett eleinte csak "érezni lehet" a lassulást és a letöltés is szinte megfelelő sebességgel megy.
A mérésed alapján is az első mért pont - a gateway - mutat hosszú válaszidőt.

A speedtest.net sem mutatja ki minden esetben a hibát, mert a nyomorult csak akkor mér sebességet, amikor van forgalom. Közben a sok timeout miatt akár hosszabb időre is áll a mérés.

modem újraindítás nem segít az fix.Volt,hogy napokra ki volt kapcsolva mert nem voltam itthon utána ugyan ez volt mikor pingeltem valamit.
Csak a GW-t pingelve 160 csomagból mind ott van és sima 6-8ms. Pingelve BIX-et újra, már 20. csomagnál dropolja,jelenleg 100 csomagból GW-nél ragadt 6 :p
Szóval akkor valahol a UPC a ludas ennél ?

https://hup.hu/node/17699
http://xenia.sote.hu/docs/gurufaq/os2/f5/514.htm

Szerintem:
pingeld = végezd azt a műveletet
pingetni = végezd azt a tevékenységet
De nem vagyok nyevészprofesszor.

Az viszont tudom, hogy az elektromos szakik kicsengelik a kábelt. ;) Nyelvileg helyes a "kifeselt a nadrágom", de nem úgy hasznáják. Viszont van néhány akadémiai állásfoglalás, aminek értelme nincs, inkább csak iránymutatás.

A faszság és bassza teminus technicus választékos alkalmazásával a meggyőzőerőd eléggé degradáltnak tűnhet.

( GerzSonka | 2018. 07. 26., cs – 18:43 )

Én most azt tapasztalom, hogy a sima HTTP-s kérések a ConnectBox-on kötnek ki, a HTTPS működik... Fura, nem nagyon tudom hova tenni...
A ping percekig ment, dropot nem tapasztaltam.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Nekem még Cisco 3208-am van.

Itt az 5. kerületben volt,hogy 1 hónapig tré volt a feltöltés és csomagveszteség volt GW-nél mire javították.kb utána indult ez,hogy GW-nél fent akadnak a pingek és kétlem ez normális lenne,vagy nem zavarja az online game-t vagy egyéb mást.

( MrSealRD v | 2018. 07. 26., cs – 18:56 )

Kíváncsi lettem. Az előbb leszedtem a WinMTR-t. Pár percig ment. Nálam is hasonlóan nagy 2800 fölé ment a wrst, miközben a sent és a receive alig volt pár száz...

( Oops | 2018. 07. 26., cs – 19:07 )

Nálam volt hasonló nyűg: nagyon lassú volt egy-egy kapcsolat kiépülése, ha már kiépült, akkor rendben volt. Bejelentettem, kijött egy fazon, mért, majd csillapítót(?) tett a kábel és a modem közé, mondván, hogy túl erős a modemnek a jel(?). A gond megoldódott.

Igen ezzel nincs is gond. Szóval itt a kerületben volt 1 hónap mikor a feltöltés tré volt illetve GW-nél nagyon durván volt packet loss,de úgy hetente többször is. Végül mikor már nem tudom hányszor beszéltem velük,akkor az egyik ügyfélszolgálatos találta ki,hogy kicsit magasak a modem értékek ezért küld egy szerelőt,hogy berakjanak egy csillapítót. Nyilván ez nem oldotta meg az amúgy fejállomás / központi hibát. Végül nem tudom hány hét után hívtak,hogy mint kiderült tényleg minőségi hiba volt a fejállomás / központ körül de javították. Utána stabil lett a le/feltöltés stb,majd valamiért elkezdtem megint winmtr pingelni bix.hu-t upc.hu-t stb és akkor vettem észre,hogy csomagok elakadnak GW-nél. A kérdés még mindig az,hogy ez okozhat bármi LAG-ot online játékban illetve ytb-n bufferelést stb ? Mert a lag-ot azt érzékelem és twitch.tv-n illetve ytb-n a bufferelést is néha.

Nos valóban ahogy fent írtátok a pingelés nem mérvadó arra,hogy azaz eszköz válaszoljon is rá legalábbis ügyfélszolgálatos szerint. Viszont így,hogy a francba tudom ellenőrizni ha bármi hálózati gond van pingen kívül? honnan tudom ha pl online játszok akkor a csomagok rendesen oda-vissza érnek-e :p Holnap azért ki küldenek egy technikust bár értelmét nem látom.Olvastam,hogy a meleg is okozhat jelszínt ugrásokat. Hát meglátjuk a mókus mit fog tudni alkotni :p

Olvastam,hogy a meleg is okozhat jelszínt ugrásokat.
Ezt megjegyzem, hátha kell keresztrejtvényben. ;) Mindenesetre ne hegesszél a modemmel!

Bármit is mesélsz a játékokról, az is hálózaton megy. Tehát a normál hálózatdiagnosztikai módszerekkel elegendő információt kaphatsz egy hálózatról.

Ami lényeges lehet:
DNS - https://www.grc.com/dns/benchmark.htm
ping - Ezt inkább a routerről végezném (először)
ping -R - record route
speedtest - Ha a játék több irányba kommunikál, akkor vannak-e lassabb irányok?
A packet loss egy normális hálózaton nincsen.

A hálózatot - bármilyen szomorú is - nem a UPC fogja diagnosztizálni.

( athila v | 2018. 07. 27., p – 20:41 )

csak azt magyarázzátok már el, hogy elküldtél 1522 csomagot a bix.hu-ra és visszajött 1522, akkor hogy is van ott csomagvesztés??? az, hogy az útvonal közben található bármelyik router vagy gyári beállításokkal vagy külön konfiggal le van beszélve róla, hogy ne foglakozzon a szaros icmp-kkel, de az átmenő csomagokat késedelem nélkül továbbítja, miért is lenne hiba???

Talán az a probléma, hogy a saját gateway RTT legrosszabb értéke 4790ms, ami ugye többszörösen kimeríti a timeout, azaz a csomagvesztés értékét. A gateway hivatalból válaszol a pingre, mivel alapvetően ezzel szokták monitorozni. A hiba okát nem tudjuk, ezért ne is próbáld megmagyarázni!
Tehát a jelenség közérthetően: Néha az (első) átjáróig sem jutnak el a csomagok. Ez ugye nem túl bonyi?

Vagy épp van rajta egy icmp rate limit, és pont annyian pingelték akkor, hogy már nem fér bele. Mint korábban is írtam, a pinget hanyagolja, ha más dolga is akad, pl routing táblát számol, miközben a csomagtovábbítás teljesen jól működik.
Pingeld a célpontot kis időközzel és nagy csomagmérettel, pl -i 0.1 -s 1472, ha ott van packet loss, akkor valóban csomagvesztés van a vonalon.

Most akkor azt hiszed, hogy az ujjamból szoptam a dolgokat? Tévedsz.

Mindössze két éves SamKnows mérés, saját diagnosztika és legalább 10 hibabejelentés bizonyítja ezt a jelenséget. Nem a pinget hanyagolja, hanem a forgalmat. ;) Olyannál is előfordul, aki azt se tudja mi az a ping. Egyszerűen csak a ping segítségével lehet pontosabban mérni.
A választ a pingelésre általában nem a routing számoló program adja. De még limitálás esetén sem életszerű a >4000 ms válaszidő. Ha meg napokig, hetekig, hónapokig közel 1000 ms a válasz, akkor nyilvánvalóan más a hiba. De tegyünk fel egy ilyet, hogy van egy limit, ami hiba esetén beragad. Az miért érintené a forgalmat? Viszont a forgalom akadozása is egyértelműen mérhető. Szóval valami beragad, mégpedig a gateway. A modem újraindításával valami megváltozik, de nem mindig. A hiba fokozódik, valami "korhad", aztán egyszer csak újraindítják a központban és megjavul. Ez a hiba kb. 5 éve létezik. Gondolom, ha tudnák mi az oka, akkor kijavították volna. Vagy csak naív vagyok. ;)

És az a vicc ez a "hiba",hogy a GW-nél beragadt valami nem létezett mindaddig még szerintem eszközt nem cseréltek vagy valamit.Mióta UPC-s vagyok X éve ilyet nem láttam,hogy GW-nél nem egy át ping,mondjuk sehol máshol se,ezért furcsálltam,hogy ha a ping beakad akkor mondjuk más forgalom miért ne akadhatna be :p

A jelenség elvét, illetve a TTL fogalmát azért érted, ugye? Minden egyes eszköz, amely nem neki szóló IP datagrmot dolgoz fel (azaz gyakorlatilag továbbít, nevezzük ezt az eszközt routernek), az IP datagram fejlécében szereplő TTL értéket csökkenti eggyel, és amelyik eszköznél ez eléri a nullát, az eldobja a datagramot, és az abban szereplő forrás IP felé egy ICMP Time Exceeded (Type 11) üzenetet küld vissza. A kezdeti TTL értékét a küldő szabadon választhatja meg.

A hálózatdignosztikai eszközök (a WinMTR is) ezt használják fel. A cél cím felé küldenek valamilyen IP csomagot először 1, majd 2, aztán 3 stb. TTL értékkel mindaddig, amíg nem a célként használt IP-től érkezik vissza válasz. Ezzel a módszerrel láthatóvá válik az IP által megtett útvonal. Nem csak pinggel (ICMP Echo) tud működni, használható bármilyen IP, UDP vagy TCP is.

Ez ugye azt jelenti, hogy amikor egy routernél 0-ra csökken a TTL, akkor nem elég neki ezt csendben eldobnia, és nem is teheti azt, hogy a memóriában lévő datagramot átteszi a másik interfészére, hanem erre neki egy teljesen új ICMP csomagot kell összeállítania (benne az eredeti datagram jellemzőivel), és ezt vissza kell küldenie. Ezért (is) szokták limitálni a szolgáltatók a routereiken az ICMP-t - nem az áthaladót, amivel nincs különösebb dolga, hanem azt, amit neki kell generálnia.

Ahogy athila és thxer is említették már, az, hogy ha a megszólított IP-vel időben és csomagvesztés nélkül tudsz kommunikálni, akkor az gyakorlatilag irreleváns, hogy a közbenső routerek milyen módon generálnak ICMP Time Exceededet, miközben a csomagtovábbítást hiba nélkül elvégzik.

Akkor lehet ebből kiindulni, ha látnád a példádban, hogy a 2. hoptól kezdődően minden további hopnál legalább ekkora csomagvesztésed, és legalább ekkora megnövekedett válaszidőd van, akkor lehet azt feltételezni, hogy a csomagvesztés és késleltetés az 1. és 2. hop között került bele, és ott van valami baj.

"ha a ping beakad akkor mondjuk más forgalom miért ne akadhatna be"
Mint látod, nem akad be, sőt, a pinged sem akad be, hiszen amikor a valódi cél felé csomagtovábbítania kellett, megtette, nem nála járt le a TTL.

szóval,hogy egyszerű legyen nekem mint parasztnak,tehát ha bármi más csomag megy át pl online game,stream stb akkor azok a csomagok nem fognak "elakadni" ugyan így GW-nél?

Más: eddig ezt nem csinálta UPC Gw miért most találták ezt ki vagy nem tudom,régen 100000 csomagot is küldhettem minden átment:p
viszont így nehéz kitalálni,hogy mitől van lagom,mitől akad valami neten.Tehát nekem azt kell feltételeznem,hogy attól hogy a pingelés fent akad GW-n de a végcélra elér minden rendben a hálózatukon ? :p

"tehát ha bármi más csomag megy át pl online game,stream stb akkor azok a csomagok nem fognak "elakadni" ugyan így GW-nél?"
Ha így foglamazod meg ("nem fognak"), akkor azért ez kicsit messzebb vezet, például a torlódás és QoS témaköre felé is.

Azt fontos megértened, hogy amit te elakadásnak vélsz, az nem elakadás. Ha "elakadás" van (megáll inni a maratonfutó), akkor az a következő megállókban is látszik, és a célba is később fog beérni. Olyan nincs, hogy a célba előbb ér a futó, mint a futás közbeni megállás időpontja.

"így nehéz kitalálni,hogy mitől van lagom,mitől akad valami neten"
Nehéz, de nem mindig lehetetlen. Az a lényeg, hogy a teljes egész képet nézd, tehát azt, hogy a két egymással kommunikáló host között mi a helyzet, és ha éppen "helyzet" van, akkor abban az időpontban milyenek voltak a köztes viszonyok, és a köztes hopok közötti eltérések mire engednek következtetni.

"eddig ezt nem csinálta UPC Gw miért most találták ezt ki vagy nem tudom,régen 100000 csomagot is küldhettem minden átment"
De a példád szerint most is átmegy. 1522/1522=100% :)
A best is 6 ms, az átlag is 6 ms, szóval nem nagyon látom, hogy ezt miért érzed problémának. Az pedig egy másik dolog, hogy vélhetőleg téged nem a bix.hu érdekelne, hanem mondjuk egy játékszerver, szóval ha azzal van a gondod, akkor azt is kellene mérned (és akkor), nem a bix-et, és ott lehet hogy kiderülne, hogy nem is te internetszolgáltatód a gyanús.