Telenor packetloss

 ( Elbandi | 2018. június 16., szombat - 13:33 )

Udv!

Van egy kis telenor routing (?) problemam. Ez egy mobilstickes elofizetes, ahonnan nehany host szerte a nagyvilagba packetlossos. Durvan 40-50%-os, ami azert sok.
Azt mar kideritettuk hogy a kifele iranyban van valami zavar: egy "hibas" iprol pingelve, tcpdump szerint minden icmp request megerkezik, a valasz veszik el valahol.

Igy elkezdtunk kifele tracerouteolni (mtr-el).
Ez egy jo ip (jelen esetben digis ip) eredmenye:

                                         Packets               Pings
 Host                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 10.101.212.30                       0.0%    50   48.5  49.1  34.7  86.1   9.8
 2. 10.26.101.21                        0.0%    50   63.1  49.1  33.8  68.9   8.3
 3. 217.79.128.18                       0.0%    50   56.7  47.4  36.6  65.0   6.6
 4. 94.21.255.25                        0.0%    50   50.7  50.9  34.2  70.6   7.8
 5. 94.21.3.64                          0.0%    50   44.7  50.8  34.5  65.6   7.4
 6. 94.21.4.93                          0.0%    49   46.7  50.4  33.6  69.5   9.3
 7. 10.1.130.179                        0.0%    49   70.8  48.2  34.3  70.8   7.9
 8. 84.236.39.x                         0.0%    49   54.9  53.4  44.5  68.3   6.0

Ugyanaz a digis halozat de most az ip eggyel nagyobb:

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 10.101.212.30                     0.0%    70   43.3  49.6  34.0  93.0  10.8
 2. 10.26.101.21                     40.6%    70   59.1  49.5  35.7  64.4   8.3
 3. 217.79.128.18                    37.7%    70   70.8  51.9  36.3 108.3  14.0
 4. 94.21.255.25                     36.2%    70   44.2  52.2  37.4  67.9   6.9
 5. 94.21.3.72                       42.0%    70   43.5  47.9  34.5  62.8   7.2
 6. 94.21.4.93                       36.2%    70   41.2  52.9  41.0  77.8   8.1
 7. 10.1.130.178                     33.8%    69   71.6  50.6  36.2  71.6   8.3
 8. 84.236.39.x+1                    38.2%    69   52.0  52.8  43.9  64.9   5.5

A gepnek publicus ipje van, az 10.101.212.30 ip mar az elso hopnak tunik (ping ido alapjan is)
217.79.128.18 ip: nincs rev dns, whois szerint egy telenoros
94.21.255.25 ip: be-4-256.xr01.budapest.digicable.hu, ez akkor mar digis

Lathato hogy ugyanaz az utvonal de megis elveszik valami, en a 10.101.212.30 es 10.26.101.21 kozotti kapcsolat hibara gyanakszom. (pl egyik portchannel linkje hibas)
Telenoros ugyfelszolgalat persze tokhulye, le vannak ragadva az "inditsuk ujra a routert", "vigyuk be bevizsgalasra", stb notanal. Hozzaerto kollegat meg nem tudnak kapcsolni.

Valaki tud valami okosat mondani erre, esetleg van olyan telenoros ismerose aki ra is lat a halozatra es megtudja nezni mivan?

Elbandi

edit: kozben megjavult, vagy hupot olvasnak, vagy eszrevettek maguk hogy valami felrement, vagy tudtak ola, es most jott meg a csere eszkoz

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A 10.x.x.x-es címek nem privátak? Vagy routing közben mindegy, ha jó az irány, mert a cél és a forrás címe számít?

naja.. dupla natolásnál már többen panaszkodtak a telenorra, hogy kimaradnak tartalmak böngészés közben is.

a mobilstickes gepnek public ipje van. azt gyanitom az a ket 10-es ip a telenor sajat halozatan levo eszkozok ipje, nincs natolas csak siman tovabbitja a csomagokat (vagy nem mindig mint jelen esetben )

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Mostanában a telenor mobilnetjei nagyon rosszak lettek, főleg hétvégén.

Fedora 27, Thinkpad x220

Nekem csak azt magyarázzátok el, hogyan lehet az, hogy a harmadik hopon kevesebb a loss, mint a másodikon.
Nem akkor van _valódi_ csomagvesztés, ha az első lossos hop után mindegyik ezután lévő loss ugyanannyi, vagy nagyobb, mint az elsőn???
Ezt én így méréstechnikai hibának minősíteném.

mivel minden hopot mas-mas packet "tesztelt", a packetloss meg random (40-50% mikorhogy), igy en nem csodalkozom hogy mas %-ok jottek ki az egyes ipken.

De ha tudsz mondani parancsot hogy amivel lehet _jol_ merni, azt szivesen fogadom.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ha nincs icmp rate-limit a cél hoston, akkor ez többnyire támpontot adhat:
cisco#ping x.x.x.x size 1500 df rep Xezer darab
vagy linuxosan paraméterezett ping, a lényeg, hogy ne várjon a válaszüzenet megérkezésére, hanem azonnal küldjön/floodoljon újabb icmp-ket.

sok gerinchálózati router alapból rate-limitálja a traceroute/icmp csomagokat.

szerintem most égeted magad... az OP szinte ugyanezt csinálta, de a célig útba eső összes routeren.

ezt kifejtenéd bővebben...?

Az IP fejléc TTL mezője megvan? Minden útba eső router csökkenti eggyel az értékét, amelyiknél eléri a nullát, az eldobja a csomagot és visszaküld egy hibaüzenetet a forrásnak.
Szóval a te parancsodat TTL=1,2,3,... értékkel is végrehajtotta, ezáltal mindig eggyel távolabbi routerig terjedő szakasz csomagvesztését tesztelte. Persze nem minden router méltatja hibaüzenetre ezeket a csomagokat és arra sincs garancia, hogy minden esetben ugyanaz az útvonal, de az indító hozzászólás mérése szerint azért nagy valószínűséggel kiszúrható, hogy melyik router környékén van a hiba.

Nekem nem a TTL-el van bajom (ez ugye triviális alapfogalom, nem kell kifejtened), hanem a közbenső routerek
némelyike rate-limitálhatja azokat az IP csomagokat, amit a routernek címeznek, de az átmenő forgalmat nem.
Ha erre indítasz egy ciscós sokezres pinget, azt fogod látni, hogy szépen sormintát alakít ki az elveszett válaszokból.
Ez pl. egy 2x20G uplink kapcitással rendelkező routerünk pingje, amin peakben 14G a forgalom, de most összesen kb csak 10G.

#ping x.x.x.x size 9000 repeat 3000
Type escape sequence to abort.
Sending 3000, 9000-byte ICMP Echos to x.x.x.x, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!
!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!
!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!
!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!
!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!
!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!
!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.
!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!
!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!
!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!
!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!
!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!
!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!
!!!!!.!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!
!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!
!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!
!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!
!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!
!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!
!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!
!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!
!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!
!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!
!!!!!!!.!!!!!!!!!!!!!!.!
Success rate is 93 percent (1525/1634), round-trip min/avg/max = 4/5/92 ms

Csomagveszt?

De a te parancsod így is része volt az ő mérésének is.

Ha a TTL-t állítod, a csomag még nem lesz a routernek címezve és a routernek nem is kellene tudni, hogy azért annyi a TTL, mert őt célzod, vagy azért, mert ungot-berket bejárt a csomag.
Illetve a következő routerre célzott csomag az előzőnek mindenképp átmenő forgalma lesz, tehát használható eredményt kapsz, csak a hiba helyének bizonytalansága kicsit nagyobb, nem?

A rate limitről én úgy tudtam, hogy azzal az ICMP forgalmat szokták korlátozni, céltól függetlenül.

A legtöbb router máshogy kezeli azokat az ICMP csomagokat, amiket neki kell processzálni, vagy csak átengedi őket.
Amint neki kellene válaszolni rá pl. time to live exceeded-el, onnantól azt már processzálnia kell, tehát magasról leszarja a szoftver és ez lesz a legutolsó dolog a queue-ban, amivel foglakozni akar. (ritkább esetben teljesen deny)
Én ezért nem hiszek soha se traceroutenak se mtr-nek.
Valamilyen áttekintést adhat az útvonalról, azt sem pontosan, gyakori beállítás MPLS hálózatok esetében, hogy teljesen elrejti a közbenső hop-okat, de csomagvesztés kimutatására használni ezt olyan, mint a vallás. Hinni lehet benne.

Ezt nem vitatom, de amit te javasoltál az is csak ICMP csomag volt. Oké, hogy a célállomás korrektebbül válaszol rá a routernél, de a traceroute-nak ez is része, tehát kevesebb infód nem lehet, ha használod, csak több. És van értelme használni, mert mint a példa is mutatja, teljesen koherens eredményt adott a posztoló mérése: mérési hibatartományon belül ingadozik a csomagvesztés a második hopptól, míg szinte ugyanazon az útvonalon tud vesztés nélkülit is mérni. Nekem ebben az esetben nincs okom megkérdőjelezni a traceroute alkalmazhatóságát. Ha már csak annyi kiderül, hogy egy MPLS zóna határai között van valami gond, már akkor is könnyebb megkeresni a felelős egyént.
Lehet, hogy a traceroute nem tökéletes, de ilyen esetekre nincs jobb. Nem minőségbiztosítási csomagvesztés mérésről van szó, csak a csomagvesztés okozójának felderítéséről.

lehet igaza van athila-nak, de mint irtam egyszerre futott a ket traceroute, egyik hostra 50% packetlosssal, masik hostra 0% lossal, ugyanazon az utvonalon. ha a kozbenso router priorizalna akkor miert csak az egyiknel volt 50% loss egyazon idoben?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ezt így kívülről ember meg nem mondja, mi lehet, add le hibára a telenornak...

"Lehet, hogy a traceroute nem tökéletes, de ilyen esetekre nincs jobb. Nem minőségbiztosítási csomagvesztés mérésről van szó, csak a csomagvesztés okozójának felderítéséről."

- Ott a pont.

Telenor mobilnet:
/tool traceroute 8.8.8.8
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 10.101.222.30 0% 14 21.9ms 20.5 17.7 27
2 10.26.102.21 0% 14 17.9ms 20.6 17 27.9
3 217.79.128.17 0% 14 19.9ms 20.8 16.9 29.7
4 100% 14 timeout
5 209.85.248.217 0% 13 25.8ms 25.8 18.3 41.2
6 8.8.8.8 0% 13 21.9ms 18.5 16.8 21.9

Telekom kábelnet:
/tool traceroute 8.8.8.8
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 192.168.0.1 0% 30 0.2ms 0.2 0.2 0.7
2 10.229.192.1 0% 30 5.7ms 6.2 4.5 11.6
3 145.236.81.198 0% 30 6.6ms 7.3 5.4 12.7
4 100% 30 timeout
5 81.183.3.161 0% 29 12.3ms 13 11.3 17.2
6 81.183.2.217 0% 29 12.1ms 12.3 10.7 14.8
7 72.14.238.27 0% 29 12.2ms 12.3 10.6 13.8
8 8.8.8.8 0% 29 10.9ms 11.7 10 16.4

Invitel optika:
/tool traceroute 8.8.8.8
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 82.131.167.102 0% 8 4.6ms 4.7 4.4 5
2 213.163.54.98 0% 8 5.6ms 5.5 5.2 6
3 79.120.128.70 0% 8 4.4ms 4.8 4.4 5.3
4 72.14.237.182 0% 8 5.4ms 5.2 5 5.4
5 8.8.8.8 0% 8 4.3ms 4.5 4.3 4.6

Digi optika:
/tool traceroute 8.8.8.8
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 10.0.0.1 0% 7 3.2ms 3 2.6 3.8 0.4
2 10.1.128.33 0% 7 1.3ms 2.3 1.2 5.7 1.6
3 94.21.3.38 0% 7 3.7ms 3.5 2.3 4.4 0.8
4 94.21.3.6 0% 7 6ms 8 4.3 21 5.3
5 94.21.3.89 0% 7 6.3ms 6.1 4.5 6.5 0.6
6 94.21.255.2 0% 7 5.8ms 5.9 3.8 7.6 1.1
7 209.85.248.217 0% 7 6.3ms 6.1 4.2 7.3 0.9
8 8.8.8.8 0% 7 6.6ms 6.5 5.6 7.5 0.5

Digi bérelt vonal:
/tool traceroute 8.8.8.8
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 94.21.6.213 0% 7 4.4ms 4.3 3.5 5.3
2 94.21.3.38 0% 7 5.2ms 3.6 2.5 5.2
3 94.21.3.0 0% 7 4.2ms 6.7 4.1 12
4 94.21.3.93 0% 7 7.6ms 7.3 6.8 7.6
5 94.21.255.2 0% 7 7.5ms 6.2 4.6 7.5
6 72.14.239.198 0% 7 7.3ms 6.2 4.3 7.4
7 8.8.8.8 0% 7 6.5ms 6.6 4.3 7.5

probald pingelni ezeket az ipket, van packetloss?
84.236.39.15
84.236.39.32
45.76.35.149

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Útvonalban akad, pingre nincs.

Telenor mobilnet:
/tool traceroute 84.236.39.15
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 10.101.222.30 0% 60 19.7ms 23.2 16.7 41.1
2 10.26.102.21 0% 60 19.9ms 20.8 16.8 49
3 94.21.255.25 0% 60 19.9ms 22.6 17 102.2
4 94.21.3.80 0% 60 26.9ms 21.6 16.8 59.7
5 94.21.3.39 0% 60 21ms 23.8 19.9 62.5
6 10.1.128.38 0% 60 19.8ms 21.9 19.8 36.2
7 84.236.39.15 0% 60 21.1ms 22.7 19.9 33.6

/tool traceroute 84.236.39.32
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 10.101.222.30 0% 44 22.7ms 24.3 16.7 41.8
2 10.26.102.21 0% 44 18.8ms 21 16.9 29
3 94.21.255.25 0% 44 21ms 20.2 17 25.8
4 94.21.3.92 0% 44 21.7ms 20 16.9 26.9
5 94.21.3.39 0% 44 19.9ms 24.1 19.9 55.9
6 10.1.128.39 0% 44 19.9ms 22.2 19.8 31.1
7 84.236.39.32 0% 44 21.1ms 22.8 20.9 29

/tool traceroute 45.76.35.149
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 10.101.222.30 0% 12 19.9ms 20.9 16.7 36
2 10.26.102.21 0% 12 18.9ms 20.9 17 28.3
3 213.248.78.57 0% 12 20.8ms 20.8 17.8 29.2
4 213.155.137.38 0% 12 27ms 27.2 24 33.9
5 62.115.119.50 0% 12 43.9ms 44.7 43.9 48.3
6 80.91.246.200 0% 12 51.9ms 52 51.8 52.5
7 62.115.122.191 0% 12 56.1ms 52.4 46.9 73.8
8 62.115.58.194 0% 12 53.7ms 49.8 45.9 57.9
9 100% 12 timeout
10 100% 11 timeout
11 45.76.35.149 0% 11 54.6ms 49.1 44.9 54.7

Digi bérelt vonal:
/tool traceroute 84.236.39.15
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 94.21.6.213 0% 28 3.5ms 3 1.1 5.1
2 100% 28 timeout
3 84.236.39.15 0% 27 4.6ms 4.2 2.5 4.7

/tool traceroute 84.236.39.32
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 94.21.6.213 0% 9 3.1ms 3 1.2 3.9
2 100% 9 timeout
3 84.236.39.32 0% 8 4.5ms 4.8 4.2 7.4

/tool traceroute 45.76.35.149
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 94.21.6.213 0% 4 4.2ms 4.2 4.1 4.2
2 94.21.3.38 0% 4 3.6ms 3.6 2.5 4.6
3 94.21.3.6 0% 4 5.4ms 5.3 4.3 6.2
4 213.154.126.65 0% 4 6.6ms 10 5.9 20.5
5 100% 4 timeout
6 80.249.212.38 0% 4 43.4ms 42.5 41.4 43.4
7 100% 4 timeout
8 100% 4 timeout
9 45.76.35.149 0% 3 42.7ms 41.2 39.2 42.7

Telekom kábelnet:
/tool traceroute 84.236.39.15
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 192.168.0.1 0% 6 0.3ms 0.3 0.2 0.5
2 10.229.192.1 0% 6 6.6ms 6.1 4.7 7.3
3 145.236.81.198 0% 6 5.8ms 6.5 5.8 8.6
4 81.183.3.36 0% 6 10.8ms 11.6 10.8 12.9
5 81.183.3.37 0% 6 11.6ms 11.9 11.1 14.1
6 81.183.2.161 0% 6 12.8ms 13.1 12.4 14
7 78.131.3.112 0% 6 11.8ms 12.9 11.7 14.8
8 94.21.3.39 0% 6 15.1ms 15.8 14.6 16.8
9 100% 6 timeout
10 84.236.39.15 0% 5 16ms 16.6 16 16.9

/tool traceroute 84.236.39.32
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 192.168.0.1 0% 10 0.3ms 0.3 0.2 0.6
2 10.229.192.1 0% 10 4.5ms 5.9 4.5 7.3
3 145.236.81.200 0% 10 7.4ms 6.8 5.8 7.5
4 81.183.3.36 0% 10 11.6ms 11.7 11.1 13.5
5 81.183.3.145 0% 10 12.1ms 12.8 10.8 18.2
6 81.183.2.161 0% 10 15.8ms 13.2 12.2 15.8
7 94.21.3.80 0% 10 12.7ms 14 12.1 24.3
8 94.21.3.39 0% 10 16.1ms 15.8 14.5 16.9
9 100% 10 timeout
10 84.236.39.32 0% 9 15.7ms 17 14.9 21.4

/tool traceroute 45.76.35.149
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 192.168.0.1 0% 18 0.2ms 0.2 0.2 0.6
2 10.229.192.1 0% 18 4.8ms 7 4.7 21
3 145.236.81.200 0% 18 8.5ms 7.4 5.6 11.4
4 145.236.133.88 0% 18 15.7ms 11.5 9.7 15.7
5 145.236.133.88 0% 18 11.6ms 10.9 9.4 14.1
6 81.183.3.167 0% 18 11.3ms 10.9 9.5 19.7
7 80.150.169.205 0% 18 19.5ms 18.7 17.8 20
8 80.156.160.98 0% 18 17.5ms 24.4 17.5 42.4
9 4.69.203.98 94.. 18 timeout 38.1 38.1 38.1
10 213.19.196.242 0% 17 39.5ms 40.5 37.6 44.4
11 100% 17 timeout
12 100% 17 timeout
13 45.76.35.149 0% 17 38.9ms 39.8 37.7 46.3

Invitel optika:
/tool traceroute 84.236.39.32
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 82.131.167.102 0% 67 4.3ms 4.5 4 5.2
2 213.163.54.237 0% 67 18.6ms 13.4 4.8 32.1
3 94.21.255.5 0% 67 5.5ms 5.5 4.5 8.2
4 94.21.3.76 0% 67 4.3ms 5.2 4.3 13.1
5 94.21.3.39 0% 67 7.9ms 8 7.6 8.7
6 100% 67 timeout
7 84.236.39.32 0% 66 9.3ms 8.9 8.1 9.7

/tool traceroute 84.236.39.15
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 82.131.167.102 0% 70 4.8ms 4.6 4.1 5
2 213.163.54.237 0% 70 17.2ms 14.4 4.9 32.1
3 94.21.255.5 0% 70 5.7ms 5.5 4.7 7.2
4 94.21.3.88 0% 70 4.5ms 5.4 4.3 23.1
5 94.21.3.39 0% 70 8.1ms 8 7.6 9
6 100% 70 timeout
7 84.236.39.15 0% 69 8.1ms 8.7 7.9 9.5

/tool traceroute 45.76.35.149
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 82.131.167.102 0% 43 5ms 4.6 3.9 5.1
2 213.163.54.237 0% 43 5.1ms 5.1 4.8 7.1
3 80.249.212.38 0% 43 37.2ms 38.2 37 44.1
4 100% 43 timeout
5 100% 42 timeout
6 45.76.35.149 0% 42 36.8ms 36.7 36.1 38.4

ha végén 0% és bármelyik közbenső hopon >0%, akkor is a loss csak 0% lehet.

Volt valami hibás eszköz is BPen, nem tudom összefügg-e ezzel
https://prohardver.hu/tema/nagy_pannon_topic/hsz_58841-58841.html