Re: [freebsd] В releng-12 опять поломали lagg?
On Wed, 25 Sep 2019, 04:02, you 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 --> интерфейс 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 --> интерфейс 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 --> интерфейс 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 --> то все равно интерфейс получается нерабочий Последовательность 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 в "нерабочем" виде и в "рабочем" для сравнения. Во-вторых: что будет, если во втором варианте удалить интерфейс и снова его создать, но вместо новомодного синтаксиса lagg0.11 использовать старый синтаксис создания? ifconfig vlan11 create vlan 11 vlandev lagg0 up # проверить работу интерфейса, а затем: ifconfig vlan11 name lagg0.11 # и снова проверить работу интерфейса Только, конечно, не вручную, а через rc.conf: cloned_interfaces="lagg0 vlan11" ifconfig_vlan11="vlan 11 vlandev lagg0" #ifconfig_vlan11_name="lagg0.11" Сначала без смены имени. Со старообрядческим синтаксисом через rc.conf получается вполне рабочий интерфейс vlan11: # ifconfig -v vlan11 vlan11: flags=8843 metric 0 mtu 1500 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 Ручное переименование оставляет интерфейс рабочим: # ifconfig vlan11 name lagg0.11 # ifconfig -v lagg0.11 lagg0.11: flags=8843 metric 0 mtu 1500 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 С переименованием vlan11 через rc.conf вышло странное. vlan11 создался, переименовался и получилось: # ifconfig -v lagg0.11
Re: [freebsd] В releng-12 опять поломали lagg?
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 --> интерфейс 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 --> интерфейс 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 --> интерфейс 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 --> то все равно интерфейс получается нерабочий Последовательность 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 в "нерабочем" виде и в "рабочем" для сравнения. Во-вторых: что будет, если во втором варианте удалить интерфейс и снова его создать, но вместо новомодного синтаксиса lagg0.11 использовать старый синтаксис создания? ifconfig vlan11 create vlan 11 vlandev lagg0 up # проверить работу интерфейса, а затем: ifconfig vlan11 name lagg0.11 # и снова проверить работу интерфейса Только, конечно, не вручную, а через rc.conf: cloned_interfaces="lagg0 vlan11" ifconfig_vlan11="vlan 11 vlandev lagg0" #ifconfig_vlan11_name="lagg0.11" Сначала без смены имени. А вот если пойти по второму варианту, потом удалить нерабочий интерфейс и снова его создать через "ifconfig vlan11 create vlan 11 vlandev lagg0 up", то он все равно получается нерабочим. # ifconfig -v vlan11 vlan11: flags=8843 metric 0 mtu 1500 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 Т.е. где-то внутри "таблицы интерфейсов системы" уже что-то поломано. И удаление/пересоздание интерфейсов уже ничего не исправляет. -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
Hello Владимир Друзенко. On Wed, 25 Sep 2019, 04:38, you wrote: 25.09.2019 04:20, Yaroslav Shvets пишет: Hello. Нерабочий интерфейс: # ifconfig -v lagg0.11 lagg0.11: flags=8843 metric 0 mtu 1496 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 Рабочий интерфейс: # ifconfig -v lagg0.11 lagg0.11: flags=8843 metric 0 mtu 1500 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 А какой MTU на lagg0? А на em0 и em1? Из-за технических проблем на сервере рассылки я пока не получаю рассылку, т.е. пишу в рассылку, а читаю через гуглогрупс. По этой причине мне затруднительно отвечать на вопросы из рассылки. Прошу дублировать письма на личный e-mail. Отвечая на вопрос Владимира Друзенко: На em0,em1,lagg0 - mtu равен 1500. В обоих случаях? Да. Т.к. сервер сейчас выступает по ночам в качестве стенда для экспериментов, то я убрал ручное выставление mtu. Все mtu выставляются по дефолту. В rc.conf'е о них ни слова. -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
25.09.2019 04:20, Yaroslav Shvets пишет: Hello. Нерабочий интерфейс: # ifconfig -v lagg0.11 lagg0.11: flags=8843 metric 0 mtu 1496 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 Рабочий интерфейс: # ifconfig -v lagg0.11 lagg0.11: flags=8843 metric 0 mtu 1500 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 А какой MTU на lagg0? А на em0 и em1? Из-за технических проблем на сервере рассылки я пока не получаю рассылку, т.е. пишу в рассылку, а читаю через гуглогрупс. По этой причине мне затруднительно отвечать на вопросы из рассылки. Прошу дублировать письма на личный e-mail. Отвечая на вопрос Владимира Друзенко: На em0,em1,lagg0 - mtu равен 1500. В обоих случаях? ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
Hello. Нерабочий интерфейс: # ifconfig -v lagg0.11 lagg0.11: flags=8843 metric 0 mtu 1496 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 Рабочий интерфейс: # ifconfig -v lagg0.11 lagg0.11: flags=8843 metric 0 mtu 1500 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 А какой MTU на lagg0? А на em0 и em1? Из-за технических проблем на сервере рассылки я пока не получаю рассылку, т.е. пишу в рассылку, а читаю через гуглогрупс. По этой причине мне затруднительно отвечать на вопросы из рассылки. Прошу дублировать письма на личный e-mail. Отвечая на вопрос Владимира Друзенко: На em0,em1,lagg0 - mtu равен 1500. -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
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 --> интерфейс 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 --> интерфейс 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 --> интерфейс 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 --> то все равно интерфейс получается нерабочий Последовательность 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 в "нерабочем" виде и в "рабочем" для сравнения. Во-вторых: что будет, если во втором варианте удалить интерфейс и снова его создать, но вместо новомодного синтаксиса lagg0.11 использовать старый синтаксис создания? ifconfig vlan11 create vlan 11 vlandev lagg0 up # проверить работу интерфейса, а затем: ifconfig vlan11 name lagg0.11 # и снова проверить работу интерфейса Только, конечно, не вручную, а через rc.conf: cloned_interfaces="lagg0 vlan11" ifconfig_vlan11="vlan 11 vlandev lagg0" #ifconfig_vlan11_name="lagg0.11" Сначала без смены имени. Со старообрядческим синтаксисом через rc.conf получается вполне рабочий интерфейс vlan11: # ifconfig -v vlan11 vlan11: flags=8843 metric 0 mtu 1500 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 Ручное переименование оставляет интерфейс рабочим: # ifconfig vlan11 name lagg0.11 # ifconfig -v lagg0.11 lagg0.11: flags=8843 metric 0 mtu 1500 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 С переименованием vlan11 через rc.conf вышло странное. vlan11 создался, переименовался и получилось: # ifconfig -v lagg0.11 lagg0.11: flags=8002 metric 0 mtu 1500
Re: [freebsd] В releng-12 опять поломали lagg?
25.09.2019 01:47, Yaroslav Shvets пишет: 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 --> интерфейс 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 --> интерфейс 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 --> интерфейс 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 --> то все равно интерфейс получается нерабочий Последовательность 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 metric 0 mtu 1496 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 Рабочий интерфейс: # ifconfig -v lagg0.11 lagg0.11: flags=8843 metric 0 mtu 1500 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 А какой MTU на lagg0? А на em0 и em1? ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
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 --> интерфейс 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 --> интерфейс 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 --> интерфейс 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 --> то все равно интерфейс получается нерабочий Последовательность 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 metric 0 mtu 1496 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 Рабочий интерфейс: # ifconfig -v lagg0.11 lagg0.11: flags=8843 metric 0 mtu 1500 options=403 ether 00:e0:81:ba:ad:90 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95 groups: vlan vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29 -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
Hello Eugene Grosbein. On Tue, 24 Sep 2019, 12:09, you wrote: On 19.09.2019 23:34, Yaroslav Shvets wrote: Hello Eugene. On Thu, 19 Sep 2019, 19:27, you wrote: 18.09.2019 9:45, Yaroslav Shvets пишет: Hello All. При обновлении системы с 11.3-RELEASE-p3 на 12.0-RELEASE-p10 перестали работать сетевые интерфейсы. Т.е. выглядят как рабочие, но по ним ничто не ходит. Сеть сделана так: em0 em1 собраны в lagg0 на lagg0 делаются vlan'ы на другом конце cisco свитч с аггрегированными портами. При откате на 11.3 все начинает работать. При создании vlan'ов на em0 все начинает работать. Не работает только на vlan'ах поверх lagg0 Никто не сталкивался? В 12.0-RELEASE вообще плохо с драйверами сетевых Intel, что em, что igb. Что-то чинили в 12-STABLE. Предлагаю либо обновиться до неё, либо сидеть на 11.3 и ждать 12.1, которая уже приближается. Похоже таки нахомутали. Попробую 12-STABLE. Отпишусь потом. Спасибо. Возможно, что в 12 у тебя не настроена подгрузка if_vlan.ko нигде до начала настройки интерфейсов и его нет в ядре. Добавь if_vlan_load="YES" в /boot/loader.conf. Ядро на основе GENERIC (т.е. включает его): device vlan# 802.1Q VLAN support -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On 19.09.2019 23:34, Yaroslav Shvets wrote: > Hello Eugene. > > On Thu, 19 Sep 2019, 19:27, you wrote: > >> 18.09.2019 9:45, Yaroslav Shvets пишет: >>> Hello All. >>> >>> При обновлении системы с 11.3-RELEASE-p3 на 12.0-RELEASE-p10 >>> перестали работать сетевые интерфейсы. >>> Т.е. выглядят как рабочие, но по ним ничто не ходит. >>> >>> Сеть сделана так: >>> em0 em1 собраны в lagg0 >>> на lagg0 делаются vlan'ы >>> на другом конце cisco свитч с аггрегированными портами. >>> >>> При откате на 11.3 все начинает работать. >>> При создании vlan'ов на em0 все начинает работать. >>> Не работает только на vlan'ах поверх lagg0 >>> >>> Никто не сталкивался? >> >> В 12.0-RELEASE вообще плохо с драйверами сетевых Intel, что em, что igb. >> Что-то чинили в 12-STABLE. Предлагаю либо обновиться до неё, либо сидеть на >> 11.3 и ждать 12.1, >> которая уже приближается. > > Похоже таки нахомутали. Попробую 12-STABLE. > Отпишусь потом. Спасибо. Возможно, что в 12 у тебя не настроена подгрузка if_vlan.ko нигде до начала настройки интерфейсов и его нет в ядре. Добавь if_vlan_load="YES" в /boot/loader.conf. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
