новые времена

[netch80]

Старый принцип: чтобы настроить сеть на не-маршрутизаторе, надо знать IP адрес, маску и шлюз.
Новый: к этому добавилось MTU.
Ибо на первом 1500, на втором 2044, на третьем 4000, на четвёртом 9200.
Кто-то, может, в этом мире живёт давно, но мы влетели на днях.

Comments

[gul-kiev.livejournal.com]

Что заставляет для IP ставить MTU больше 1500? Всё равно ведь дальше ближайшего маршрутизатора провайдера большой пакет не пройдёт, а проблемы вполне можно получить. Даже если это исключительно локальная сеть без доступа во внешний мир, всё равно от большого IP MTU проблем будет больше, чем от стандартного.
Похоже, я чего-то не понимаю. И смысл jumbo frames в ua-ix от меня ускользает - при том, что там уставом запрещено непосредственное взаимодействие между участниками.
Или в твоём случае это не IP было?

[netch80.livejournal.com]

IP.
Источником замечания была сеть HPC кластера с тотальным MTU=9000 на основной обменной сети.
Выход в мир там нужен только для техподдержки.
MTU мы не выбирали. Но я не вижу причины ограничиваться стандартным 1500.

[gul-kiev.livejournal.com]

> Но я не вижу причины ограничиваться стандартным 1500.

Давай рассмотрим варианты.
1. У меня большое MTU, а с той стороны 1500 или меньше. Самый простой случай - устанавливается сессия с MTU 1500.
2. И у меня, и на том конце большое MTU.
2a. Хотя бы на одном из маршрутизаторов по пути MTU=1500 и включен tcp mss -> устанавливается сессия с MTU 1500. Случай редкий - при стандартном MTU обычно tcp mss не включают.
2b. Хотя бы на одном из маршрутизаторов по пути MTU=1500 и icmp needfrag проходит (через все наты). MTU уменьшается и сессия продолжается, имеем лишь небольшую задержку в начале сессии по сравнению со случаем стандартного MTU.
2с. На маршрутизаторе по пути MTU=1500, icmp needfrag от него где-то потерялось -> сессия не живёт.
2d. На маршрутизаторе по пути MTU=1500, icmp needfrag к источнику проходят, но роутинг асиметричный, оттуда к тебе большие пакеты проходят, а от тебя туда нет, и к тебе за нат icmp needfrag не доходят -> сессия виснет при первом объёмном post с твоей стороны.
2e. На всех маршрутизаторах по пути MTU не меньше, чем у тебя и на том конце (например, маршрутизаторов по пути нет), один из свичей пропускает только пакеты 1536 -> сессия висит.
2f. Все маршрутизаторы по пути и все свичи по пути пропускают пакеты с MTU не ниже, чем у тебя и на том конце -> получаешь выигрыш в скорости примерно 3% (при MTU 9000) - ура!

Ты считаешь, что пункт 2f перевешивает сумму 2b+2c+2d+2e?
А если ещё и допустить, что теряется хотя бы 0.01% пакетов размером 1500, и процент потерь пропорционален размеру пакетов - выигрыша даже в варианте 2f уже, скорее всего, не получится.

К этому ещё можно добавить, что большинство сетевух по-прежнему не поддерживают MTU больше 1500, и рассогласование MTU приводит к проблемам в OSPF и некоторых других протоколах. То есть, вот живёшь ты себе в своей локалке с MTU 9000, и понадобилось добавить ещё один свич или роутер, который поддерживает только стандартное MTU - и нужно перестраивать всю сеть.

[furry.livejournal.com]

[мрачно] а когда устройство еще и не умеет правильно вычислять MSS, потому что горе-программисты чтобы заглушитить тоску по родине, постоянно курили гашиш (с) читали RFC по диагонали...;-\