зміна mtu : добре чи погано ?

[Volodymyrko]

добрий день ..
таке питання ..
до чого призведе зміна mtu на eth-інтерфейсі (тобто на езернеті).. ??
по замовчуванні там 1500 .. а якщо поставтити менше, 14хх... : чи якось позначиться це на сервері

[vanessa]

От мене тоже цікавить. у мене на одній краточці чисто pppoe і все. так от дсл-модем вроді має параметр mtu ~1492 чи щось таке. я доумаю якщо гнати йому пакунки по 1500 тоді модем буде їх фрагментувати, із усіма випливаючими звідчи наслідками. Я думаю що в цьому випадку можливо ї є сенс міняти mtu але це тільки мої розмірковування, сам я  досі не ризикнув це зробити.

[Oleksandr]

Памятаю що на діалапному інтернеті ця зміна деколи і давала результат, але зараз інтернет канали дуже змінились і тому я думаю що від цього вигоди не буде ніякої тим більше в локальній мережі

[Volodymyrko]

питання  не про швидкість, з нею тут більш ніж добре  ...  а вигоду для серверу ..
чи не буде він лишній раз фрагментувати пакети,  чи не збільшиться к-кь пакетів які він буде отримувати або відсилати   або ще щось таке.. сам не знаю

[Volodymyrko]

може хтось підкаже  таке:
є веб-сервер .. зі стандартинм mtu 1500 на езереті ..  і якийсь клієнт не міг відкривати сторінки з нього, при цьому всі інші без проблем, доки не змінили mtu на 1436  ??
в чому тут справа ?

[Дмитро Редчук]

може хтось підкаже  таке:
є веб-сервер .. зі стандартинм mtu 1500 на езереті ..  і якийсь клієнт не міг відкривати сторінки з нього, при цьому всі інші без проблем, доки не змінили mtu на 1436  ??
в чому тут справа ?

Справа, гадаю, в тому, що десь між сервером та клієнтом є "хтось", хто не може пропустити крізь себе MTU більше 1436. Той "хтось" має, отримавши великий пакет, кинути у відповідь icmp fragmentation-needed, але або він не кидає, або до сервера не доходить. Якщо доходить, то винен сервер :-)

Цей "хтось" може бути і клієнт.

"Навколо MTU" погано те, що часто про icmp fragmentation-needed забувають, коли малюють файрвол.

[RomadinR]

"Навколо MTU" погано те, що часто про icmp fragmentation-needed забувають, коли малюють файрвол.

Більше того, деякі розумники явно забороняють фрагментацію у файрволі (навіть рекомендують всім так чинити, кажуть є можливість атаки на фрагментах).
Як краще - відповідь неоднозначна. Дуже залежить від багатьох умов. Наприклад, від обладнання. Деяке китайське обладнання має ваду - не пропускає пакети певного розміру. Більше і менше - без проблем :-(

[Дмитро Редчук]

Як краще - відповідь неоднозначна. Дуже залежить від багатьох умов. Наприклад, від обладнання. Деяке китайське обладнання має ваду - не пропускає пакети певного розміру. Більше і менше - без проблем :-(

Краще -- обмежувати кількість фрагментів,
обмежувати "час життя" фрагмента у ядрі..

Продумати і відкрити у файрволі проходи для таки потрібних пакетів протоколу контрольних повідомлень..

[RomadinR]

Краще -- обмежувати кількість фрагментів,
обмежувати "час життя" фрагмента у ядрі..

Продумати і відкрити у файрволі проходи для таки потрібних пакетів протоколу контрольних повідомлень..

Та я ж не проти. :-) Якби ж то ще мати доступ до ядра тих залізяк... :-(
Я от мав справу із оптичним конвертором, який не пропускав пакети розміром 1460 (здається) байт. 1459 і 1461 - без проблем :-(. Довелося на маршрутизаторі з mtu гратися, хоч це і не правильно, та замінити конвертора на той момент не було можливості.