Default MTU... Mi van?

Hálózati eszközök

Sziasztok!

Hálózatban még van mit pótolnom. Az elmúlt 4 hétben a következős problémával szembesültem.
A Router-en a WAN port MTU beállítása 1492 (maximum) érték.. A LAN MTU értéke nem állítható. A kliensek alapértelmezett beállítása 1500, de ezzel nem megy a NET. Ha visszaveszem 1300-ra akkor minden tökéletes.

Valaki el tudná magyarázni, hogy ez így most miért? Én a tűzfalhoz nem nyúltam, élek a gyanúperrel, hogy a Digi oldalon változott vmi. Ennek viszont ellentmond, hogy ha átviszek egy 1500-as MTU-ra állított laptopot a szomszédba (persze, szintén digi), tökéletesen működik.

  • 13226 megtekintés

( andrej_ v | 2016. 03. 06., v – 11:50 )

Jellemzően PPPoE vagy hasonló netkapcsolatnál szokott 1500-nál kisebb MTU előfordulni. A routerednek újra kéne csomagolnia az adatokat. Pontosan milyen routert használsz?

Nem, az már a múlt. Manapság a TCP kapcsolat végpontján illik kisebb csomagokat használni. Ehhez (működő) path MTU discovery kell (ICMP!) vagy a tűzfalon kell MSS clamping.

Tehát:
- LAN felől hagyd békén az 1500-as MTU-t
- PPPoE WAN felől legyen 1492-es MTU
- Engedélyezd a PMTUD-hez szükséges ICMP csomagokat
- Kapcsold be a routeren a MSS clamping-ot. (ip tcp adjust-mss 1452, vagy ahogy az eszközödön hívják)

Ami a diginél esetleg megváltozott, az az lehet, hogy most már izomból eldobják a fragmentált csomagokat (more fragments bit bekapcsolva, vagy fragment offset > 0)? Ha a szomszéd router-e jól van beállítva, akkor az a (pozitív eredményű) kísérlet konzisztens ezzel a (vélt) digis változással.

A WAN oldalon jelenleg is a 1492-es MTU van beállítva.
Sajnos a router-ben nincs beállítási lehetőségem sem a PMTUD, sem az MSS clamping-ra.
LAN oldalon 1500-as MTU-val nem megy a kapcsolat, csak 1300-al.
Lehet a router a hunyó, majd szabadidőmben kiiktatom és megnézem, úgy mi a helyzet.

"Értem én, hogy villanyos autó, de mi hajtja?"

( hunti v | 2016. 03. 07., h – 08:59 )

Routered nem mászik fel egészen véletlenül vpn-re?

( balazsasd | 2016. 03. 18., p – 21:05 )

Nálam is előjött valami érdekes hiba. Néhány infó nálam:
- VPN nincs
- Mikrotik RB2011U...
- 1Gbit net

konfig ide eső része:

pppoe-out :
0 R name="pppoe-out-digi" max-mtu=1480 max-mru=1480 mrru=1600 interface=bridge-wan user="yyy"
password="xxx" profile=default keepalive-timeout=60 service-name="" ac-name=""
add-default-route=yes default-route-distance=0 dial-on-demand=yes use-peer-dns=yes
allow=pap,chap,mschap1,mschap2

profile :
0 * name="default" use-mpls=default use-compression=default use-encryption=default only-one=default
change-tcp-mss=yes use-upnp=default address-list="" on-up="" on-down=""

Ami szépen működik:
- hup.hu
- google.com
- godaddy.com

Ami nem :
- speedtest.net
- jofogas.hu
- magyarorszag.hu

Jellemzően akkor volt ilyen hibám amikor kísérletezgettem cisco routerekkel, ahol erősen játszanom kellett az mtu-val, és az mss-el. Ezzel most is próbálkoztam 1300 és 1492 között állítgatva nem értem el pozitív változást.

Én ma vettem észre hogy valami nem kerek.

Van bridge konfolva, a mikrotiken ?

Mert minap futottam bele egy orbitális marhaságba. Ugyanis mikrotik a bridge interface MTU-ját leveszi a bdigben szereplő legkisebb MTU-ra, ami nem lenne gond ha mondjuk automatiksan tolná rá az TCP MSS-t nem tolta.

Fixen meg kellett mondtani, hogy márpedig a bridge legyen 1500as MTU, és ne akarja levenni ha pl egyik EoIP tunnel benne 1300-as.

Persze ez régen nem volt így, és nem tudtam eldönteni, hogy ez bug vagy feature :D

Fedora 23, Thinkpad x220

( uid_6201 v | 2016. 03. 18., p – 21:21 )

OpenWRT tűzfalát néztem:

Mangle táblában:

Chain FORWARD (policy ACCEPT 3008K packets, 2175M bytes)
pkts bytes target prot opt in out source destination
3008K 2175M mssfix all -- * * 0.0.0.0/0 0.0.0.0/0

Chain mssfix (1 references)
pkts bytes target prot opt in out source destination
415K 25M TCPMSS tcp -- * pppoe-wan 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 /* wan (mtu_fix) */ TCPMSS clamp to PMTU

IPv6-os Mangle tábla:

Chain FORWARD (policy ACCEPT 333K packets, 325M bytes)
pkts bytes target prot opt in out source destination
333K 325M mssfix all * * ::/0 ::/0

Chain mssfix (1 references)
pkts bytes target prot opt in out source destination
8235 658K TCPMSS tcp * pppoe-wan ::/0 ::/0 tcp flags:0x06/0x02 /* wan (mtu_fix) */ TCPMSS clamp to PMTU

( NevemTeve | 2016. 03. 19., szo – 06:59 )

Nem nagyon értek ezekhez a dolgokhoz, most például azt nem értem, hogy mi a kérdés? Megérkezik egy 1500 bájtos IP-csomag a rúterhez LAN-oldalról; a rúter óvatosan kettétöri (fregmentálja) a csomagot, hiszen hosszabb a maximális 1492-nél, és két darabban továbbítja WAN irányba.

A címzett aztán elgondolkozik, szereti-e ő a töredezett IP-csomagokat. Ha igen, akkor minden rendben. Ha nem, akkor így jártunk.

Nem. Pont ez a lényeg, hogy manapság nem a rúter töri ketté a csomagot, hanem a két végpontnak kell akkora darabokra törnie, hogy átférjen a csövön, viszont ennek feltétele, hogy előtte a végpont fel tudja mérni, hogy mi a legszűkebb keresztmetszet a csövön.

A rúter általi kettétöréssel, és a túloldali rúter általi összerakással nagyon sok baj keletkezik.
- nagyméretű puffereket kell használni (mert az összes fragmentnek laknia kell valahol, amíg az utolsó darabja is meg nem érkezik, hogy össze lehessen rakni)
- kezelni kell az rossz sorrendben érkező fragmenteket,
- kezelni kell az esetleg elveszett fragmenteket,
- nem lehet fastpath-t használni,
- stb.
mindezt képzeld el a mai gerinchálózatok több tíz- vagy százgigabites (csillió packet/sec) sebessége mellett.

azért ezzel vitatkoznék.
ha a céges irodai hálózatban mehetnek akár a 9000 -es MTU -k is, de az x.y. szolgáltató hálózata eldobja a (hasraütés) 800 MTU fölöttieket, akkor miért lenne jó levenni az egész belső hálózto 800 MTU-ra?!
legyen is path mtu discovery vagy a router mondja meg, hogy ha a hup.hu -hoz nyit kapcsolatot a gépem, mekkora MTU-ra állítsa magát, egyebekben meg a helyi hálón mehet akár a 9000 MTU hogy ne legyen tetu lasso mondjuk a helyi fájlátvitel.
ugyanígy, ha van egy vpn kapcsolatom is, és azon meg mondjuk csak (hasraütés megint) 592 -es MTU megy át, ne kelljen már emiatt az egész hálózatot levenni 592 -re, hanem szintén a path mtu discovery vagy a router mondja meg, hogy ha abba az irányba akar a gépem kapcsolatot nyitni, akkor 592 MTU-t használjon.