one mtu változás?

Hálózatok általános

Több szerverem van one.hu és broadband.hu IP címeken, és péntek óta problémát okoz a levélküldés. Az eddigi 1500-as mtu-t lejjebb vettem 1496-ra, és megjavult. Lehetséges, hogy módosítottak az mtu-n, csak nem szóltak? Másnak nincs ilyesmi problémája?

  • 2031 megtekintés

( wpeople v | 2025. 03. 03., h – 14:25 )

ezt egy ping-el v tracepath - al is tudod szerintem ellenőrizni (ha nem csak megerősítést keresel)

ps: milyen technológiáról beszélsz? mert PPPoE esetén azért a routernek illene a TCP MSS kérdést megoldania...

( vasla_ | 2025. 03. 03., h – 14:58 )

Szerkesztve: 2025. 03. 03., h – 14:59

Próbáld ki: 

1500 as csomagnál 20+8+1472 bájt:

Ping -t -f -l  1472 xx.hu

1496 as csomagnál 20+8+4
Ping -t -f -l 1468  xxx.hu

Szerintem nem fog átmeni az 1496 -os csomag se, csak  fragmentálva. De nem vagyok mtu-ban  ennyire otthon, majd kijavítanak.

https://blog.claryel.hu

Remélem, hogy azt, ami a "man ping"-ben le van írva :)

-M pmtudisc_opt

Select Path MTU Discovery strategy.  pmtudisc_option may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag).

Így próbáltam: ping -M do -s 1472 8.8.8.8

A 8.8.8.8-ra átmegy, de nem mindenhová. Ezért nem igazán értem.

 

Akkor a routered csomagmérete 1500 és át is megy. Legalábbis 8.8.8.8 -ra. Ahová meg nem megy ott a -M do nem engedi fragmentálni. Enélkül,  ( -M do )menni fog, csak szétbontja  az 1 csomagot 2-re.

https://blog.claryel.hu

( dorsy v | 2025. 03. 03., h – 15:16 )

Szerkesztve: 2025. 03. 03., h – 15:18

Minek allitgatod?
 

dorsy@wsl64:~$ ./mtu.sh goo.gl
Maximum MTU size: 1334
dorsy@wsl64:~$ ./mtu.sh 1.1.1.1
Maximum MTU size: 1492
dorsy@wsl64:~$ ./mtu.sh 8.8.8.8
Maximum MTU size: 1250

ugyis a koztes halon "annyi amennyi"... MSS meg - a kollega is irta fentebb - tudja mit kell csinalni.

nem a kezzel allitgatas a megoldas a vegberendezesen, hanem a rendes MSS a halozaton.
pelda fent, neked mas halozataval nem kell bajlodj, ugyis fragmentation utkozben - ha kell.
ha pedig ipv6 is van, akkor ne sporold le a megfelelo ICMP allow-t.

Hosszú ideje jól működtek azok a gépek, csak péntek reggel óta vannak problémáik. Ha fix IP címet kapsz a szolgáltatótól, amit kézzel szépen beállítasz a szerveren, és nem mondja, hogy az mtu értéke 1500-tól eltérő legyen, akkor azt a rendes mss-t hogyan is tudod meg?

MSS = MTU - TCP/IP fejlécek (20 byte IP + 20 byte TCP)

https://skminhaj.wordpress.com/2016/02/15/mtu-myth-busters/
MSS-t tudsz rakni a tcp csomagodba, ha nem akarsz sz*ni. (azert azt, mert a fizikai MTU az X, az MSS pedig a headerek fuggvenyeben "ami marad")
Egyebkent meg leszel szives megerdeklodni a szolgaltatodtol, hogy mit allits be. Mi van a drot masik vegen. (teged eddig kell erdekeljen)

az azert kurvaerdekes, ha neked kisebb MTU-val sem ment :)
de megegyszer: ez nem a vegberendezes dolga, hanem a routere. ha nem tud az eszkozuk elbanni a default 1.5k MTU-val az ethernet porton, adjanak masikat. az, hogy naluk utana mekkora az mtu a transferen, az meg ki a f*t erdekel...
hogy ertsd:
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
semmit nem befolyasol azon, hogy a ppp-n az MTU csak 1492. a router tudja mi a dolga.

az azert kurvaerdekes, ha neked kisebb MTU-val sem ment :)

Valami nem kerek eth1  mtu 1500 , ppoe mtu 1492, ezzel  nem megy, de a nagyobb 1496-tal meg igen ? 

Linux alol milyen hibát kapsz erre: ping -M do -s 1496 1.1.1.1
illetve ez ping -s 1496 1.1.1.1

Vagy win altt ping -t -f -l 1496 1.1.1.1   illetve -f nélkül (-f ne fragmentálj) 

https://blog.claryel.hu

Ha fix IP címet kapsz a szolgáltatótól, amit kézzel szépen beállítasz a szerveren

hogyan kapod a fix ipcímet? (mert erre még nem láttam választ)
PPPoE? akkor nem kell állítanod semmit sem, a szerveren (routeren?) kapsz egy MTU értéket. Amennyiben ez más a belső hálózatod felé - AKKOR gondoskodsz a TCP MSS beállításról
DHCP? eddig csak olyan implementációt láttam, ahol 1500byte-os frame-ek vannak a hálózaton (minek szopassák magukat és az ügyfeleket) de persze semmi nem lehetetlen
Static IP? kapsz egy saját prefixet (mondjuk /28)  ?

DHCP? eddig csak olyan implementációt láttam, ahol 1500byte-os frame-ek vannak a hálózaton

Nem, a Vodafone / One a kábeltévés infrastruktúráján (IPv6-os végponti profil esetén) DS-Lite-ot használ, ami a gyakorlatban natív IPv6 fölött kitunnelezett IPv4. Tehát, IPv6 esetén megvan az 1500-as MTU, de IPv4 esetén csak 1460-ig nyújtózkodhatsz.

#!/bin/bash
destination_ip="$1"

# Set initial packet size
packet_size=1200

# Loop to find the maximum MTU size
while true; do
  ping -4 -M do -c 1 -s $packet_size $destination_ip > /dev/null
  if [ $? -ne 0 ]; then
    echo "Maximum MTU size: $((packet_size + 28 - 2))"
    break
  fi
  packet_size=$((packet_size + 2))
done

Javítsál még rajta.

$ ./mtu-detect-dorsy.sh 8.8.8.8
Maximum MTU size: 1328
$ ping -4 -M do -s 1464 8.8.8.8
ПІНГ 8.8.8.8 (8.8.8.8) 1464(1492) байтів даних.
1472 байтів з 8.8.8.8: icmp_seq=1 ttl=117 час=6.26 мс
1472 байтів з 8.8.8.8: icmp_seq=2 ttl=117 час=6.37 мс
1472 байтів з 8.8.8.8: icmp_seq=3 ttl=117 час=5.71 мс
1472 байтів з 8.8.8.8: icmp_seq=4 ttl=117 час=5.85 мс
1472 байтів з 8.8.8.8: icmp_seq=5 ttl=117 час=6.44 мс
1472 байтів з 8.8.8.8: icmp_seq=6 ttl=117 час=6.37 мс
^C
--- Статистика пінгування 8.8.8.8 ---
Передано 6 пакетів, отримано 6, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 5.712/6.167/6.441/0.281 ms
$
 

[szerk] Semmi. ICMP flood, a tűzfal megfogja. :) De azt jól mutatja, hogy nem mindig működik így a dolog.

"Sose a gép a hülye."

Gyorsan megírtam magamnak egy bináris keresős változatot:

#!/bin/bash

destination_ip="$1"

lo=1200
hi=2000
while ((hi-lo>1)); do
    ((packet_size=(lo+hi)/2))
    echo "  Packet size: $packet_size, hi: $hi, lo: $lo" >&2
    if ping -4 -M do -c 1 -s "$packet_size" "$destination_ip" >&/dev/null; then
        lo="$packet_size"
    else
        hi="$packet_size"
    fi
done
if ping -4 -M do -c 1 -s "$hi" "$destination_ip" >&/dev/null; then
    lo="$hi"
fi
packet_size=$((lo+26))
echo "Maximum MTU size: $packet_size"
exit 0

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Te is javítsál még rajta. :)

$ ./mtu-detect-binary.sh 8.8.8.8
 Packet size: 1600, hi: 2000, lo: 1200
 Packet size: 1400, hi: 1600, lo: 1200
 Packet size: 1300, hi: 1400, lo: 1200
 Packet size: 1250, hi: 1300, lo: 1200
 Packet size: 1225, hi: 1250, lo: 1200
 Packet size: 1212, hi: 1225, lo: 1200
 Packet size: 1206, hi: 1212, lo: 1200
 Packet size: 1203, hi: 1206, lo: 1200
 Packet size: 1201, hi: 1203, lo: 1200
Maximum MTU size: 1226
$ ping -4 -M do -s 1464 8.8.8.8
ПІНГ 8.8.8.8 (8.8.8.8) 1464(1492) байтів даних.
1472 байтів з 8.8.8.8: icmp_seq=1 ttl=117 час=6.26 мс
1472 байтів з 8.8.8.8: icmp_seq=2 ttl=117 час=6.37 мс
1472 байтів з 8.8.8.8: icmp_seq=3 ttl=117 час=5.71 мс
1472 байтів з 8.8.8.8: icmp_seq=4 ttl=117 час=5.85 мс
1472 байтів з 8.8.8.8: icmp_seq=5 ttl=117 час=6.44 мс
1472 байтів з 8.8.8.8: icmp_seq=6 ttl=117 час=6.37 мс
^C
--- Статистика пінгування 8.8.8.8 ---
Передано 6 пакетів, отримано 6, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 5.712/6.167/6.441/0.281 ms
$
 

[szerk] Semmi. ICMP flood, a tűzfal megfogja. :)

[szerk2] Nem, ez sleep 1-gyel sem jó.

"Sose a gép a hülye."

Még szerencse, hogy nyílt forrású a script, és azzal a paranccsal dönti el, hogy az adott méret működik-e, vagy sem, amellyel te nagyobb csomagot átzavartál.

Ugyanakkor szeretném megjegyezni, hogy az 1226 az a szám, amikor az alsó értékem el sem mozdul a kezdeti 1200-ról, tehát a scripten belül egyik ping sem sikerült, míg command line-ból neked valamiért meg igen. Szóval arra kellene rájönni, miért jött vissza az összes ping nullától különböző exit code-dal. Annyit valóban javíthatnék, hogy ha minden ping hibával tér vissza, kiírhatnám hogy failed.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( hory v | 2025. 03. 03., h – 16:21 )

Nalam a pppoe setting-eknel a router konkretan anyazik, ha 1492 fole akarom tolni az MTU-t; holmi standard-re hivatkozik.

Digi uveg.

Nem neztem tuzetesebben utana, de lehet, van benne valami itt is.

( lcseh | 2025. 03. 03., h – 17:08 )

Nekem otthoni kábelnetnél jött elő, szintén One a szolgáltató.

X éve ott vagyok, sosem volt baj, amikor elkezdtem a Fiido bicikliket nézegetni, akkor tapasztaltam, hogy a fiido.com, nem nagyon működött. Volt még egy magyar oldal, az orczy.com, ami szintén nem ment. Ugyanez jött elő, hogy MTU baja van és a tűzfalban átírtam az 1500-at 1492-re, rögtön megjavult. Valahol a routerek, CMTS-ek környékén lesz egy PPPoE cucc is. Hogy minek, azt ne firtassuk....

Imádom ezt a "One a szolgáltató" definíciót. A One egy új marketing brand, ami alatt kaphatsz korábbi Vodafone (jelenlegi nevén: V-Hálózat Távközlési Zrt.) és korábbi DIGI (jelenlegi nevén: D-Infrastruktúra Kft.) által megvalósított konnektivitást.

A korábbi Vodafone hálózaton jellemzően DOCSIS van, egyre több helyen DS-Lite társaságában, míg DIGI-nél FTTH és FTTB körzetben PPPoE van, de futott DIGI alatt egy csomó "bekebelezett" kisebb szolgáltató szolgáltatása is. Totál más technológiák, teljesen eltérő MTU értékekkel.

( s_attila | 2025. 03. 03., h – 18:01 )

Péntek reggel óta (a monitoring alapján már éjjel fél 1-től) valami olyan szinten meggajdult a Vodafone-os (pardon, One-os) uplinkünkön, hogy arra nincsenek szavak.

iperf ugyanarra a távoli végpontra egyik pillanatban gigabit közel, másik pillanatban 100 Kbit/secet mér. Voda szerint minden OK, bár a negyedik körnél járva már elbizonytalanodtak (és eltűntek)...

( csardij v | 2025. 03. 04., k – 09:57 )

Elég a gépen lejjebb venni az MTU-t, vagy routeren kell? Ha szolgáltatói router van, ott lehet?

( arpi_esp v | 2025. 03. 04., k – 11:28 )

Szerkesztve: 2025. 03. 04., k – 11:34

en is tapasztaltam anomaliat, egy upc voda one berelt vonalrol (optikan jon be (nem docsis), nincs pppoe, static ip van beallitva) a doclernel servergardennel levo hostra hol megy hol nem a https post feltoltes, hol timeoutol (tcpdump alapjan az 1500-as csomagok elvesznek) hol nem, akar par percenklent valtozo modon. icmp nincs tiltva egyik vegen sem, en is szolgaltato oldali routing/mtu problemata gyanakodtam eddig.

( bennyh | 2025. 03. 04., k – 14:09 )

Szerkesztve: 2025. 03. 04., k – 14:10

Amúgy Linux vagy RouterOS alatt csak ez az MSS kalapálás működik még most is IPv4 esetén (akár a PPP stack-be épített, akár mangle)? Nincs arra mód, hogy ne kelljen TCP csomagokban matatni?

Az amúgy nem érdekelne, hogy a köztes hálón mi történik vele, az lenne a lényege az én kérdésemnek, pont hogy az én eszközeimmel ne kelljen bajlódni még a TCP MSS kalapálással sem. Hogy mi történik útközben, az már nem a dolgom, csak az, hogy minden adta oda kerüljön, ahová kell.

nem erdekel, de megis, hogy megse. hatarozatlan vagyok. vagy nem? :D
aki nofragment csomagokat kuld feled es elakad a koztes halon ez miatt, az igy jart. lesz szives rendesen kommunikalni.
ne kelljen bajlódni még a TCP MSS kalapálással sem. > erre ott az ipv6. megoldja helyetted. :)

( droszler v | 2025. 03. 07., p – 20:11 )

One válasza a hibabejelntésre, miután megoldották:

"A hiba jelensége egy nem várt, egyelőre, feltételezett szoftveres hiba a hálózati eszközünkön amely a hálózati kommunikációs csomag méretet limitálta. Ez csak bizonyos forgalmakat befolyásolt és a kisebb csomagméret miatt elérhetetlenséget és szakadozást okozott. A hiba elhárításra került és a gyártó által nyomoztatva hogy a jövőben ne történjen ilyesmi."

jah. hat a hupuk elvarjak hogy mindig pontos hw megjelolessel irjanak meg mindent! :D

nekem tok validnak tunik hogy valahol volt egy hw ami szarul mukodott, es a gyartoi support (elvegre ezen megleten szokott mindenki porogni) megoldotta.

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