> Какбы возможности сетевого стека ядра шикарны, и отказываться от них в угоду убогому функционалу какойто гуевины.. ну, есть винда, там 3 окошка, пользуйтесь.Я понимаю, что разговор был изначально про Wi-Fi, но ваши обобщения - признак глупости и необразованности.
Во-первых сетевой стек ядра Linux традиционный кусок дерьма, когда дело касается коммутации. Да ядро способно сделать файлвол, а роутинговые протоколы в массе своей всё равно - демоны юзерспейса, но L2 в Linux - откровенная жесть. Если вы его хвалите, значит просто никогда не видели большого развертывания.
Linux работает с VLAN и бондинг также коряво, как Windows Server 2008-2012R2. То есть у нас есть урезанный драйвер коммутатора, обеспечивающий некоторые функции, а рядом торчит драйвер бондинга, в который нужно всё это воткнуть. В современных ванильных ядрах Linux помимо прочего нельзя подать порт в Access идущий сквозь bond. RHEL-ообразные дистрибутивы выпиливают новеллы разработчиков ведра, которым это "нинужна", в остальных будьте любезны прицеплять еще и VLAN. Причем назначение IP сервера на VLAN может производиться в двух местах. Либо на VLAN (старый драйвер) либо посредством прокидывания в Linux Bridge (рекомендованный способ) уже на который нужно вешать IP.
То есть если вы подключаете LAG на Linux-хосте будет вот такая схема:
1. Драйвер адаптера
2. Virtual Switch (LVS)
3. Bonding
4. VLAN-интерфейс (L3) или Bridge (L3)
При этом вам нужно послать с коммутаторов транк, потому что не все Linux теперь это поймут.
Похожий зоопарк вокруг NIC Teaming наблюдался во времена Windows 2008 - Windows 2012 R2, когда на каждый чих нужно было иметь отдельный драйвер.
Казалось бы, а в чем проблема, ну подумаешь несколько драйверов криво спаренных друг с другом. Ан-нет, проблема подкрадывается, когда на вашем хосту виртуализации требуется сделать Offloading сетевой подсистемы виртуального коммутатора с процессора на сетевые адаптеры. Вот тут и начинается...
В Linux поддержка offloading работает только через драйверы предоставленные вендором. Все остальные надстройки с пристройкой и подстройкой ничерта не умеют. Кстати, если вы используете на KVM еще и Open Virtual Switch для программно определяемой сети, то он втыкается только в мост, напрямую вы ему ничего не отдалите...
В Windows 2016+ написали новый сетевой стек, предоставили API и там:
1. Bonding делается средствами коммутатора.
2. OVS делается средствами виртуального коммутатора
3. Коммутатор имеет API и поддерживает Offloading очередей, RDMA и VXLAN на сетевой адаптер
И есть перечень оборудования которое со всем этим работает. В Linux заставить работать offloading у меня удавалось только на сетевых картах Nvidia (mellanox), потому что у остальных драйверы - это мусор.
Просто про хороший сетевой стек Linux и еще и с упоминанием в соседнем придложении KVM... Вы просто нагло врёте! Оно ужасное, педальное и работает только с некоторыми вендорами и только в некоторых конфигурациях (очень крупных). Я это знаю, потому что разворачивал OpenStack на KVM.
Единственный способ как заставить это всё работать на Linux - отказаться от мультихоуминга через протокол LACP и перейти всей сетью на L3, организуя ECMP (упоминается в статье кстати). Реализовать EVPN-VXLAN на стороне вышестоящей сетевой инфраструктуры с использованием iBGP в качестве роутинга. В этом случае вы сможете просто не пользоваться косорылым сетевым стеком и у вас получится так:
1. Драйверы портов сетевых адаптеров
2. Мосты
3. Open Virtual Switch
Далее вы берете и настраиваете ведороспецифичный offloading, чтобы расчеты OVS перелезли с проца на чип сетевок. И да, там будет везде этот самый NetworkManager, о котором речь в новости.
А что касается трёх окошек венды... это для пользователей. Если вам нужно что-то настроить у себя в сетевом стеке, так оно только в PowerShell доступно и в интерфейс не выведено. Уверен что вы даже не знаете где всё это там есть, потому что документацию не читали.
