MTU size korlátok?

Hálózatok általános

Helló mindenki,

felmerült egy MTU-probléma: rengeteg telephely között VPN tunnel van, sok helyen 1372 vagy akár csak 1360 az MTU. Ugyanakkor sok site meg megy csupasz interneten keresztül, 1500-as MTU-val. Az alkalmazás amit használunk UDP-n küld videót, és a videó stream-re DONTFRAGMENT-et állít be (IPv4 természetesen). A rúterek sok helyen viszont eldobják az ICMP "Fragmentation Needed" hibaüzeneteket, tehát a küldő nem tud alkalmazkodni az útközbeni v. akár az endpoint oldali alacsonyabb MTU-hoz. Az esetlegesen az endpoint-ban létező Path MTU Discovery logika így nem is tud működni.

Próba kedvéért levettük a site-on az endpoint-ok MTU-ját, mint lehetséges megoldást. Ha egy endpoint-on beállítom az MTU-t a default 1500-ról 1360-ra, akkor ezzel tudom befolyásolni mekkora csomagokat KÜLD az endpoint. De mi a helyzet a másik oldallal: az alkalmazkodni fog ehhez az MTU mérethez, illetve mi történik ha továbbra is 1500-as IPv4/UDP csomagokat küld? A fogadó oldal, HA MEGKAPJA SIKERESEN, akkor is eldobja a network stack-je a túl nagy MTU-jú csomagokat? Vagy ez már inkább buffering témakör (ugyebár egy IP csomag mérete max. 64k lehet fragmentálással).

  • 877 megtekintés

( mauzi v | 2020. 03. 05., cs – 18:13 )

Szerkesztve: 2020. 03. 05., cs – 18:15

UDP-n az alkalmazásnak (jelen esetben, a video streamernek) kell megoldania az MTU-val kapcsolatos problémákat. (fragmentálás, újraküldés, satöbbi.) TCP-n ugye ezt az IP stack out-of-box megcsinálja.

Ha az alkalmazás nem képes erre, akkor így járt. (A video "droppos" lesz)

A fogadó oldal, HA MEGKAPJA SIKERESEN, akkor is eldobja a network stack-je a túl nagy MTU-jú csomagokat?

Hö? Valami vagy átfér a csövön és akkor hurrá van, vagy nem fér át. Nem értem, mi az, hogy "megkapja sikeresen, de túl nagy MTU-jú csomagok"?

"UDP-n az alkalmazásnak (jelen esetben, a video streamernek) kell megoldania az MTU-val kapcsolatos problémákat. (fragmentálás, újraküldés, satöbbi.) TCP-n ugye ezt az IP stack out-of-box megcsinálja."

Mármint az egész fragmentálás, újraküldés dolgot nem az IP csinálja, hanem a TCP.
Az UDP ugyanúgy IP réteg felett megy, ha az IP réteg megcsinálna mindent, amit mondasz, akkor az UDP is ezt készen kapná.

Az IP réteg az irányítást végez (honnan hova kell mennie a csomagnak ha A és B között kell mennie, és ha valamerre nem mehet, van-e alternatív útvonal), a TCP meg azt, hogy a sok-sok kis egyedi csomagból (ami sokféle útvonalon elmehetett A-ból B-be) te egy bytestreamet látsz végül. Ehhez neki kezelnie kell az újraküldést, a fragmentációt stb.

Az UDP esetén nincs meg az, hogy bytestream legyen a sok-sok csomagból, de nem is erre van kitalálva az UDP.

Valamint ha az IP csomagban be van állítva a DF fejléc-flag, akkor az IP csomagot egyik router sem tudja eltörni, TCP esetén sem, és ha nem megy át, akkor a csomagméretet csökkenteni kell. Ezt az IP protokoll nem fogja neked megtenni (az IP nem végez újraküldést például), de a TCP igen, erre találták ki.

Mármint az egész fragmentálás, újraküldés dolgot nem az IP csinálja, hanem a TCP.

Ezért írtam IP stack-et, nem simán IP-t. Az IP stack nem csak az IP réteget kezeli, hanem a TCP-t is. Most fuss neki újra ennek a mondatnak: "TCP-n ugye ezt az IP stack out-of-box megcsinálja."

Az MTU egy IP layer (L3) paraméter, nem transport layer (L4)!

A PMTD pedig éppen ezért transzparensen támogatja TCP-t és UDP-t is:

PMTUD is only supported by TCP and UDP. Other protocols do not support it. If PMTUD is enabled on a host, and it almost always is, all TCP and UDP packets from the host will have the DF bit set. 

Igen, érkezhet, az UDP-s esetben biztosan. TCP-nél leegyeztetik az MSS-okat és a kisebbiket fogják használni. Hogy hogy lehetne megoldani arra nincs ötletem. Lehet érdemes lenne valami daemont írni, ami pingel no fragment bittel az endpoint felé és az ICMP errorokból belövi az jó MTU-t, amit beállít aztán. A VPN részt nem egészen értettem, az miért fontos most?

Ja értem. UDP-re nem fog menni ez a PMTU discovery, mint ahogy a TCP belövi magának az MSS-t. Manuálisan kellene valahogy kezelni ezt az egészet. Ekkora nagy cégnél nem is nagyon tudom, hogyan lenne érdemes megoldani a problémát. A videókonferencia program gondolom minden gépre központi repóból frissül, lehet érdemes lenne abban átírni, hogy mekkora üzeneteket használjon max. Zárt forráskódnál mondjuk még ha technikailag lehetséges is belehackelni, nem tudom licensz engedné-e. Még amit nem tudok, hogy a site-to-site tunnelek mit takarnak. Csak IP tunnelek, vagy TAP módban tunneleznek (így + 2xMAC cím + ethertype méretet is hozzá kell számolni a tunnel fejléchez)? IPv6 van-e, esetleg IPv6 tunnelben IPv6? Ilyen esetben már nagyon kis MTU-t kellene a tunnel interfészeken beállítani. Wiresharkban látszik-e ICMP error a videós progi DF bitet beállított csomagjaira? Azokat el lehetne kapni és valami daemont írni ami ilyen esetben felderíti az adott cím felé a korrekt MTU-t és beállítja helyileg. Ha helyileg megvan akkor szintén ez a daemon megküldi a túloldali párjának és az is beállítja. Így nem kell módosítani a konferencia progit (márha nem baj, hogy az első(néhány) csomag esélyesen kuka).

Proprietary zárt forrású kereskedelmi videó konf szoftver és hardver van szerver és kliens oldalon is, nem írkálunk át benne semmit, meg proxy-kat se kódolunk le hozzá :)

A PMTD-d meg cisco szerint TCP/UDP is támogatja, mert L3 fícsör, nem MSS.

Hello, 

Ezt az egész problémát a videokonferencia-rendszer okozza szerintem, és a problémát is alkalmazás-szinten kellene megoldani (mivel a hálózatot, főleg ha nem a sajátod, nem tudod minden alkalmazáshoz hozzáigazítani).

Voice-nál ok, hogy bebillenti a dontfragment-et, de video-stream-nél mi értelme van? Ott nem számít a jitter, és mivel írtad, hogy ez egy hardware-es megoldás, gondolom a hozzá illő árral, ezért gondolom kellene lennie benne valami intelligenciának, adaptive codec change, MOS-mérés, meg hasonlók, amikkel a hálózathoz igazítja magát (az adott session-t, mivel más irányba más paraméterek lehetnek). Ha lekorlátozod az MTU-t a videokonf-rendszeren, akkor mindenkivel max. olyan méretű csomagokkal fog tudni kommunikálni.  

Nézzetek utána, hogy ezt a DF-bitet nem lehet-e kikapcsolni a videoconf-rendszerben valahogy, mert ez elég érdekes így (gyártót érdemes lenne megkérdezni hivatalosan).

Üdv. 

Sajnos pont a kommentben amire válaszoltál írta, hogy lehetnek ICMP blackholeok a hálózatban és így normálisan sosem fog a DF flag miatti ICMP errorról értesülni. És az tényleg igaz, hogy alkalmazás szinten kéne megoldani ezt a problémát. Ekkora cégnél valid ticket lenne, hogy építsék be ezt a funkciót a programba (PMTU meghatározás valami UDP-s vagy TCP-s próbálgatással session felépítésnél) gondolom nem ingyen kapja a cég. 

( athila v | 2020. 03. 05., cs – 21:21 )

" Az alkalmazás amit használunk UDP-n küld videót, és a videó stream-re DONTFRAGMENT-et állít be"

-----------> na ez a legnagyobb baromság, hülye alkalmazásprogramozók, akiknek fingjuk sincs a hálózatok működéséről:

-mi ez a DF-bit a fejlécben?

-- add ide a söröm, beállítom 1-esre!!!

A Path MTU Discovery az úgy működik, hogy MINDEN kimenő csomag DF bitje set.

https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsula…

PMTUD is done continually on all packets because the path between sender and receiver can change dynamically. Each time a sender receives a "Can't Fragment" ICMP messages it will update the routing information (where it stores the PMTUD).

( dap | 2020. 03. 05., cs – 23:38 )

Szerkesztve: 2020. 03. 05., cs – 23:38

> Próba kedvéért levettük a site-on az endpoint-ok MTU-ját

És akkor mi történt? Ha működött, akkor ez nem megoldás?

A mi videószerverünket át tudjuk állítani, az endpointjainkat is. De össze vannak kötve számtalan más külsős videószerverekkel és endpointokkal, amikre 0 ráhatásunk van. Ha a mi rendszerünkben levesszük minden résztvevő MTU-ját egy alacsonyabb értékre, vajon okozunk ezzel a fogadó oldalunkon nagyobb bajt, mintha  mindent hagynánk a default 1500-on, és oldja meg valahogy az alkalmazás az eltérő MTU problematikáját?

Elnézést a beleszólásért, de miért kellene erre neki kikeresnie RFC-t? Őt terheli bizonyítási kényszer? Szerintem nem, csak segíteni akar.

A paraméter neve MTU: Maximum Transmission Unit. Ezen nincs mit tovább magyarázni. A párja (ami egy másik független paraméter) az MRU: Maximum Receive Unit. Ezen sincs mit tovább magyarázni szerintem.

Egy csomag (DF bit set) akkor nem megy végig egy adott vonalon, ha van olyan továbbító állomás, aminek az 1) MRU értéke kisebb a csomag méretnél, így érkezéskor eldobja, 2) MTU értéke kisebb a csomag méretnél, így nem képes tovább küldeni. Ez nem feltétlenül egyetlen állomás. Persze általában az MTU és MRU egyezik, de ez nem kötelező egyébként.

Nem RFC, de szerintem érthető: http://www.networkers-online.com/blog/2016/03/understand-mtu-and-mru-the-full-story/

Ha már így kéretlenül becsatlakoztál: nem követeltem senkitől semmilyen bizonyítási kényszert, csak rákérdeztem tudna-e mondani rá RFC-t is. Mert néha nem elég csak sejteni mi hogy működik,  Nem dolgoztál még támogatásban. Na ott az ügyfelek tudnak ám követelőzni, és az nagyon nem úgy hangzik mint amit én írtam! Abban pedig megegyezhetünk, hogy amiről networking-ben nincs RFC, az kb. nem is létezik.

A linkelt írás kb. ok színvonal, de nagyon felületes és összecsapott, főleg az MRU.

A modern hálókártyák összevonják a bejövő csomagokat és egyben adják át az oprendszernek feldolgozásra amivel sok terhet levesznek a CPU válláról, cserébe az IP layer jó nagynak látja őket. Ezt azért tehetik meg, mert IP layernek nem dolga korlátozni a fogadott csomagok méretét, csak azzal kell törődnie, hogy képes-e feldolgozni vagy nem.

Az RFC 791 annyit követel meg, hogy minden állomás minimum 68 bájtos csomagot tudjon fogadni, illetve 576 bájtos csomagot képes legyen feldolgozni. Minden ami e fölött van "best effort" alapon működik.

( ggallo | 2020. 03. 06., p – 08:26 )

Mi a videó rendszer gyártójának ajánlása erre a felhasználásra? Ők mit mondanak? Nem hiszem, ahogy akár az MTU korlátozását 1500 alá, akár garantált 1500 MTU-s linket írnának elő. Vagy alapból csak szigorúan belső Ethernet hálózatra szánták, csak Ti használnátok inter-site?

Egyébkét én, mikor muszáj egy MTU<1500 linken MTU >=1500 csomagokat átnyomnom, olyan VPN-t használok (Mikrotik EoIP, multilink L2TP, satöbbi), ami ezt megoldja (kezeli a fragmentálást-összeillesztést transzparens módon, a két végpontján a beállított MTU-t mutatja-fogadja). Az persze más kérdés, hogy real-time adatfolyam esetében ez okoz-e és milyen problémákat...

( secretx v | 2020. 03. 06., p – 16:13 )

Esetleg 

--clamp-mss-to-pmtu

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"