On 25.09.2019 05:47, Yaroslav Shvets wrote: > On Tue, 24 Sep 2019, 07:55, you wrote: > >> On 24.09.2019 11:26, Eugene Grosbein wrote: >> >> Просьба отвечать в рассылку, а то я и сам не обратил внимания и свой ответ >> не продублировал сюда. >> >>> On 24.09.2019 06:50, Yaroslav Shvets wrote: >>>> Hello Eugene. >>>> >>>> On Mon, 23 Sep 2019, 08:51, you wrote: >>>> >>>>> 23.09.2019 8:46, Yaroslav Shvets пишет: >>>>> >>>>>> Сервер, к сожалению, рабочий, и экспериментировать часто не получается. >>>>>> Но обязательно попробую, как будет возможность. >>>>>> >>>>>> Пока выяснилось, что сам lagg работает с нетегированными пакетами. >>>>>> Проблема только - с тегированными. Т.е. не работает ни один >>>>>> из vlan'ов построенных на lagg, но сам lagg - рабочий. >>>>> >>>>> Очень может быть, что дело как раз в сломанном аппаратном offload для >>>>> vlanhwtag/vlanhwfilter. >>>>> Более того, такое уже бывало в старых версиях, но с другими драйверами. >>>>> >>>>> Крайне желательно это выяснить побыстрей, пока ещё есть немного времени >>>>> успеть починить к 12.1-RELEASE. >>>>> Но времени совсем немного. >>>> >>>> Сразу скажу: результаты экспериментов у меня странные. >>>> >>>> Последовательность 1: >>>> --------------------- >>>> Если делать все руками, то все работает. >>>> Примерно так: >>>> ifconfig em0 up >>>> ifconfig em1 up >>>> ifconfig lagg0 create >>>> ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up >>>> ifconfig lagg0.11 create >>>> ifconfig lagg0.11 inet <ip/prefix> >>>> --> интерфейс lagg0.11 оказывается рабочим >>>> и это не зависит от -rxcsum -txcsum -tso4 -vlanmtu -vlanhwtag -vlanhwfilter >>>> -vlanhwcsum -vlanhwtso >>>> т.е. все работает в разных сочетаниях >>>> >>>> Последовательность 2: >>>> --------------------- >>>> Если разрешить часть работы проделать rc.conf'у, примерно так: >>>> -- rc.conf -- >>>> ifconfig_em0="up" >>>> ifconfig_em1="up" >>>> cloned_interfaces="lagg0 lagg0.11" >>>> ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up" >>>> ---------------- >>>> А потом вручную доделать: >>>> ifconfig lagg0.11 inet <ip/prefix> >>>> --> интерфейс lagg0.11 оказывается нерабочим >>>> хотя выглядит абсолютно нормальным >>>> >>>> Последовательность 3: >>>> --------------------- >>>> Аналогично последовательности 2, но убираем из cloned_interfaces >>>> создание lagg0.11, предполагая сделать его руками: >>>> -- rc.conf -- >>>> ifconfig_em0="up" >>>> ifconfig_em1="up" >>>> cloned_interfaces="lagg0" >>>> ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up" >>>> ---------------- >>>> А потом вручную доделать: >>>> ifconfig lagg0.11 create >>>> ifconfig lagg0.11 inet <ip/prefix> >>>> --> интерфейс lagg0.11 оказывается рабочим >>>> и выглядит абсолютно нормально >>>> >>>> Итого: руками все создаем - все работает, >>>> имеем cloned_interfaces="lagg0 lagg0.11" - не работает, >>>> имеем cloned_interfaces="lagg0", а потом руками досоздаем lagg0.11 - >>>> опять все работает. >>>> >>>> Создается впечатление, что в cloned_interfaces lagg0.11 как-то неправильно >>>> создается (или раньше чего-то), или как-то не так, как руками. >>>> >>>> Причем интересно, что если взять последовательность 2, при которой >>>> получился >>>> нерабочий интерфейс lagg0.11, удалить интерфейс, снова его создать: >>>> ifconfig lagg0.11 destroy >>>> ifconfig lagg0.11 create >>>> ifconfig lagg0.11 inet <ip/prefix> >>>> --> то все равно интерфейс получается нерабочий >>>> >>>> Последовательность 1 отличается от последовательности 2 >>>> очередностью создания 11-го vlan'а и "собиранием" lagg'а >>>> 'ifconfig lagg0.11 create' и >>>> 'ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up'. >>>> Но при ручном варианте (последовательность 1) очередность >>>> собирания lagg0 и создания lagg0.11 не имеет значения. >>>> Интерфейс lagg0.11 в любом случае оказывается рабочим. >>>> >>>> Вобщем, странные вещи происходят. >>> >>> Во-первых, чудес не бывает и нерабочий интерфейс наверняка можно отличить >>> по его состоянию. >>> Покажи вывод ifconfig -v lagg0.11 в "нерабочем" виде и в "рабочем" для >>> сравнения. > > Нерабочий интерфейс: > # ifconfig -v lagg0.11 > lagg0.11: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1496 > options=403<RXCSUM,TXCSUM,LRO> > ether 00:e0:81:ba:ad:90 > inet xx.xx.170.82 netmask 0xfffffff0 broadcast xx.xx.170.95 > groups: vlan > vlan: 11 vlanpcp: 0 parent interface: lagg0 > media: Ethernet autoselect > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > > Рабочий интерфейс: > # ifconfig -v lagg0.11 > lagg0.11: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > options=403<RXCSUM,TXCSUM,LRO> > ether 00:e0:81:ba:ad:90 > inet xx.xx.170.82 netmask 0xfffffff0 broadcast xx.xx.170.95 > groups: vlan > vlan: 11 vlanpcp: 0 parent interface: lagg0 > media: Ethernet autoselect > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> >
Воспроизвел проблему на 11.3 последовательностью: ifconfig lagg0 create ifconfig lagg0.11 create ifconfig lagg0 laggproto lacp laggport em0 Дело в том, что в чипах сетевых Intel есть аппаратная поддержка vlanhwfilter и она очень полезная: если сеть флудит порт фреймами с разнообразными вланами, то чип фильтрует поток и передаёт хосту только те фреймы, теги которых соответствуют созданным вланам у хоста. При создании нового влана драйвер добавляет в этот фильтр новый тег. Если создавать вланы напрямую поверх em0, то это работает всегда. Если создавать вланы на lagg поверх em0, это работает, если в момент создания влана все аппаратные сетевые уже добавлены в lagg. Теоретически при добавлении новой сетевой в агрегат в неё тоже должен прописываться фильтр, если новая и все ранее добавленные сетевые поддерживают vlanhwfilter. Практически у тебя получается в некоторых случаях, что вланы создаются до создания lagg. Пересоздание lagg должно "исправлять" проблему без ребута. _______________________________________________ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
