Всем привет.
Итак, имеется в наличии:
ББ - большой брат, игровая система на винде 7/8. Сетевуха на ББ имеет поддержку JF.
СБ - средний брат, система на debian, которая содержит в себе дисковый массив и систему виртуализации. Сетевуха на СБ имеет поддержку JF.
Гейт - система на дебиан, которая работает гейтом между локалкой и сетью Интернет, а также держит точку доступа для подключения к локалке по wi-fi. Сетевуха на гейте имеет поддержку JF, у wi-fi нет поддержки JF.
свитч с поддержкой jumbo frame

Задача - попробовать задействовать в локалке jumbo frame.

Если я правильно понимаю, то в цепочке
система - свитч - система
каждый из компонентов должен поддерживать jf. В противном случае кадр просто не дойдёт до получателя. То есть, например, при схеме
система MTU 9000 - свитч MTU 1500 - система MTU 9000
кадр размером более 1500, посланный любой из систем, дойдёт до свитча и там, грубо говоря, и останется. В смысле, будет отброшен.

Стало быть, начинаем включать поддержку jf по-порядку на каждом участнике локальной сети. Поехали.
В случае ББ всё просто. Идём в свойства драйвера сетевухи и включаем. Работает.
В случае свитча у меня было включено сразу.

Переходим к СБ и начинается самое интересное. Я использую qemu/kvm для виртуализации и linux bridge для обеспечения работы сети в виртуалках. То есть, я создаю бридж на этапе загрузки хост-системы и даю его виртуалкам для работы. Что такое бридж? Это просто виртуальный свитч. То есть, при включении виртуалки создается виртуальный сетевой интерфейс и включается в состав указанного бриджа. И вот здесь есть тонкость:

Цитата:

The bridge itself just seems to take the smallest MTU from it's set of hosted devices and uses that

На текущий момент мне удалось сделать так, что и физический интерфейс на СБ и бридж и интерфейсы виртуалок имеют MTU 9000. Сделано очень просто:
в файле /etc/network/interfaces указываем

Интерфейсы eth0 и wlan0 на СБ пока не задействованы. Я выключил автозагрузку у виртуалок и отправил систему в ребут. По факту загрузки системы с таким конфигом я получил следующее:

Далее, запуск виртуалок дал такую картину:

И это клёво. Они сами получили MTU 9000, без дополнительных манипуляций с конфигами. Среди виртуалок есть debian и windows 8. Проверяем пинг из одной виртуалки в другую:

Работает. Включаем автозагрузку у пары виртуалок и отправляем хост-систему в ребут. После загрузки имеем:

Вроде работает.

Остался один только гейт. Сейчас на гейте пока нет JF. Пока что есть отдельно стоящий интерфейс, смотрящий в WAN, и есть бридж, в который включены интерфейс wi-fi адаптера и интерфейс ethernet, смотрящий в локалку. То есть, клиенты wi-fi включены в локалку скозняком. Они ипользует dhcp из локалки, в том числе. Поскольку у wi-fi нет JF, то возникает вопрос, как это всё реорганизовать. Еще раз напомню, бридж берет себе значение MTU по интерфейсу, включенному в бридж, с минимальным MTU. Смотрящий в WAN интерфейс трогать не нужно. С mtu на wi-fi сделать ничего нельзя.

И здесь, внимание, вопрос.
Стало быть, что делать-то? Отрывать интерфейс wi-fi от бриджа и разруливать связь между проводной сетью и беспроводной с помощью маршрутизации? Или есть еще варианты? Подскажите, кто в курсе.

Наврал. У меня SLM2008T из серии Cisco SG200-08 8-Port Gigabit Smart Switch и потребовалось руками выставить MTU для каждого порта.

Добавлено спустя 1 час 3 минуты 40 секунд:
Пришел к мысли, что надо wlan интерфейс отрывать от бриджа с проводными подключениями и делать для него отдельный бридж. А потом уже рулить. Например, виртуальную машину с ролью "сетевой шлюз" включать в оба этих бриджа и форвардить трафик через неё. Похоже, что это самый правильный способ.

Добавлено спустя 5 часов 13 минут 40 секунд:
Надо уточнить несколько моментов.
Гейт внедрен и работает уже пару лет. Вай-фай на нем реализован на простой PCI карте. Главная особенность гейта заключается в том, что оно не поддерживает аппаратную виртуализацию. По этой причине. Зато низкое энергопотребление и сетевуха Intel на борту.
СБ был собран недавно и на нём тоже есть wi-fi. По этой причине. Машинка изначально бралась под виртуализацию. По идее, СБ заменит собой машину Гейт, в том числе.

В общем, получилось мне запустить отдельный бридж на СБ для работы wi-fi.
/etc/network/interfaces

/etc/hostapd/hostapd.conf

В результате имеем

Обращаю ваше внимание на отсутствие ip адреса у wi-fi интерфейса/бриджа. Это ключевой момент.

Добавлено спустя 1 час 38 минут 31 секунду:
Выяснился любопытный момент в работе JF на виртуалках. Напомню, на бридже в хост-системе выставлено MTU 9000

Вчера копировал с ББ (винда 8.1) на СБ (samba на debian7) файл размером 30 гигабайт и обратил внимание на интересный момент. Скорость копирования стабильно держалась на отметке 116 мегабайт в секунду. Если я правильно помню, то до перевода на MTU 9000 скорость держалась обычно в диапазоне 80-90 мегабайт в секунду.

Теперь надо на ББ и СБ сделать бондинг. Свитч у меня поддерживает 802.3ad... Сейчас в СБ стоит Intel I350-T2, вторая такая карта лежит пока, поставлю в ББ. Интересно, сколько можно выжать из аггрегации 2 линков по гигабиту при MTU 9000.

ЗЫ. Второй интересный момент. Вчера же перевел СБ на mtu 1500, для эксперимента, и скорость копирования этого же файла упала до 11 мегабайт в секунду. То есть, где-то линк срезало до 100 мегабит.

x2 от того, что есть (230 мегабайт в секунду). Если дисковая система конечно позволит.

Одна беда - баг не позволяет нормально работать бондингу в бридже. Точнее, на хост-системе оно работает, в виртуалках на этом бридже сети нет. И это пичалька...

Надо будет попробовать продвинуться дальше в этом направлении.