Re: [freebsd] В releng-12 опять поломали lagg?
On Thu, 26 Sep 2019, 11:48, you wrote: On 26.09.2019 05:23, Yaroslav Shvets wrote: Создал PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240825 Ещё надо упомянуть, что удаление lagg0 и пересоздание его и влана вручную (с указанием конкретных команд) даёт рабочий влан. Это исключит подозрения в проблемах окружения на твоей стороне и в твоей криворукости, о чём всегда есть подозрения у разработчиков, пока их не развеять. Упомянул. -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On 26.09.2019 05:23, Yaroslav Shvets wrote: > Создал PR: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240825 Ещё надо упомянуть, что удаление lagg0 и пересоздание его и влана вручную (с указанием конкретных команд) даёт рабочий влан. Это исключит подозрения в проблемах окружения на твоей стороне и в твоей криворукости, о чём всегда есть подозрения у разработчиков, пока их не развеять. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On 26.09.2019 06:30, Yaroslav Shvets wrote: > On Wed, 25 Sep 2019, 21:26, you wrote: > >> On 25.09.2019 23:26, Yaroslav Shvets wrote: >> >>> On Wed, 25 Sep 2019, 15:15, you wrote: >>> On 25.09.2019 18:16, Yaroslav Shvets wrote: > Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в > rc.conf? Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что ещё ломается из-за корявой последовательности, кроме vlanhwfilter. Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с rc.conf. >> >> Почти наверняка проблема действительно в драйвере lagg. >> Есть ли возможность поменять laggproto lacp на laggproto failover на время >> ребута, >> а потом уже выставить laggproto обратно, например в /etc/rc.local ? >> >> И поглядеть, с каким mtu будет в таком случае создан lagg0.11 и будет ли он >> рабочим. > > В rc.conf поставил "laggproto failover", /etc/rc.local - "laggproto lacp", > порты коммутатора в режиме lacp. > > При загрузке в console.log: > > lagg0: flags=8843 metric 0 mtu 1500 > > options=81249b > ether 00:e0:81:ba:ad:90 > laggproto failover lagghash l2,l3,l4 > laggport: em0 flags=5 > laggport: em1 flags=0<> > groups: lagg > media: Ethernet autoselect > status: active > nd6 options=29 > > 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 > > ... > Firewall rules loaded. > Starting local daemons: <в этом месте отработал '/sbin/ifconfig lagg0 > laggproto lacp laggport em0 laggport em1 up'> > ... > > После загрузки: > > # ifconfig -v lagg0 > lagg0: flags=8843 metric 0 mtu 1500 > > options=81249b > ether 00:e0:81:ba:ad:90 > laggproto lacp lagghash l2,l3,l4 > lagg options: > flags=10 > flowid_shift: 16 > lagg statistics: > active ports: 2 > flapping: 0 > lag id: [(8000,00-E0-81-BA-AD-90,01CB,,), > (0001,2C-36-F8-4E-47-93,03E8,,)] > laggport: em0 flags=1c > state=3d > [(8000,00-E0-81-BA-AD-90,01CB,8000,0003), > (0001,2C-36-F8-4E-47-93,03E8,0001,000B)] > laggport: em1 flags=1c > state=3d > [(8000,00-E0-81-BA-AD-90,01CB,8000,0004), > (0001,2C-36-F8-4E-47-93,03E8,0001,000C)] > groups: lagg > media: Ethernet autoselect > status: active > nd6 options=29 > > # 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 > > Интерфейс в нерабочем состоянии. > > tcpdump на lagg0.11 видит только исходящие пакеты, входящих - нет. Ясно, не помогло. В общем и надежда была на это не великая. В PR я призвал зубров, которые корежили lagg в последнее время и накоммитили в него тех изменений, которые отличают его от lagg в 11.3. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On 26.09.2019 04:06, Yaroslav Shvets wrote: > On Wed, 25 Sep 2019, 21:26, you wrote: > >> On 25.09.2019 23:26, Yaroslav Shvets wrote: >> >>> On Wed, 25 Sep 2019, 15:15, you wrote: >>> On 25.09.2019 18:16, Yaroslav Shvets wrote: > Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в > rc.conf? Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что ещё ломается из-за корявой последовательности, кроме vlanhwfilter. Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с rc.conf. >> >> Почти наверняка проблема действительно в драйвере lagg. >> Есть ли возможность поменять laggproto lacp на laggproto failover на время >> ребута, >> а потом уже выставить laggproto обратно, например в /etc/rc.local ? >> >> И поглядеть, с каким mtu будет в таком случае создан lagg0.11 и будет ли он >> рабочим. > > А на коммутаторе порты должны остаться в позе lacp? Да. Важно лишь чтобы изначально lagg был не с протоколом LACP, потому что в этом режиме драйвер работает иначе. Но после того, как загрузка практически завершилась, можно вернуть LACP в уже полностью сформированный lagg, чтобы он начал физически работать. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On Wed, 25 Sep 2019, 21:26, you wrote: On 25.09.2019 23:26, Yaroslav Shvets wrote: On Wed, 25 Sep 2019, 15:15, you wrote: On 25.09.2019 18:16, Yaroslav Shvets wrote: Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в rc.conf? Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что ещё ломается из-за корявой последовательности, кроме vlanhwfilter. Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с rc.conf. Почти наверняка проблема действительно в драйвере lagg. Есть ли возможность поменять laggproto lacp на laggproto failover на время ребута, а потом уже выставить laggproto обратно, например в /etc/rc.local ? И поглядеть, с каким mtu будет в таком случае создан lagg0.11 и будет ли он рабочим. В rc.conf поставил "laggproto failover", /etc/rc.local - "laggproto lacp", порты коммутатора в режиме lacp. При загрузке в console.log: lagg0: flags=8843 metric 0 mtu 1500 options=81249b ether 00:e0:81:ba:ad:90 laggproto failover lagghash l2,l3,l4 laggport: em0 flags=5 laggport: em1 flags=0<> groups: lagg media: Ethernet autoselect status: active nd6 options=29 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 ... Firewall rules loaded. Starting local daemons: <в этом месте отработал '/sbin/ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up'> ... После загрузки: # ifconfig -v lagg0 lagg0: flags=8843 metric 0 mtu 1500 options=81249b ether 00:e0:81:ba:ad:90 laggproto lacp lagghash l2,l3,l4 lagg options: flags=10 flowid_shift: 16 lagg statistics: active ports: 2 flapping: 0 lag id: [(8000,00-E0-81-BA-AD-90,01CB,,), (0001,2C-36-F8-4E-47-93,03E8,,)] laggport: em0 flags=1c state=3d [(8000,00-E0-81-BA-AD-90,01CB,8000,0003), (0001,2C-36-F8-4E-47-93,03E8,0001,000B)] laggport: em1 flags=1c state=3d [(8000,00-E0-81-BA-AD-90,01CB,8000,0004), (0001,2C-36-F8-4E-47-93,03E8,0001,000C)] groups: lagg media: Ethernet autoselect status: active nd6 options=29 # 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 Интерфейс в нерабочем состоянии. tcpdump на lagg0.11 видит только исходящие пакеты, входящих - нет. -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On Wed, 25 Sep 2019, 21:20, you wrote: On 26.09.2019 01:16, Eugene Grosbein wrote: On 25.09.2019 23:26, Yaroslav Shvets wrote: On Wed, 25 Sep 2019, 15:15, you wrote: On 25.09.2019 18:16, Yaroslav Shvets wrote: Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в rc.conf? Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что ещё ломается из-за корявой последовательности, кроме vlanhwfilter. Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с rc.conf. [attachments skipped] Прошу создать баг (PR) в https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Base%20System Описать проблему, обязательно приложить этот rc.conf и console.log, не забыть упомянуть, что device vlan есть в ядре. И прислать мне номер PR. Да, и обязательно надо указать, что это апгрейд с 11.3, в котором всё работало. Создал PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240825 -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On Wed, 25 Sep 2019, 21:26, you wrote: On 25.09.2019 23:26, Yaroslav Shvets wrote: On Wed, 25 Sep 2019, 15:15, you wrote: On 25.09.2019 18:16, Yaroslav Shvets wrote: Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в rc.conf? Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что ещё ломается из-за корявой последовательности, кроме vlanhwfilter. Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с rc.conf. Почти наверняка проблема действительно в драйвере lagg. Есть ли возможность поменять laggproto lacp на laggproto failover на время ребута, а потом уже выставить laggproto обратно, например в /etc/rc.local ? И поглядеть, с каким mtu будет в таком случае создан lagg0.11 и будет ли он рабочим. А на коммутаторе порты должны остаться в позе lacp? -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On 25.09.2019 23:26, Yaroslav Shvets wrote: > On Wed, 25 Sep 2019, 15:15, you wrote: > >> On 25.09.2019 18:16, Yaroslav Shvets wrote: >> >>> Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в >>> rc.conf? >> >> Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что >> ещё ломается >> из-за корявой последовательности, кроме vlanhwfilter. >> >> Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с >> rc.conf. Почти наверняка проблема действительно в драйвере lagg. Есть ли возможность поменять laggproto lacp на laggproto failover на время ребута, а потом уже выставить laggproto обратно, например в /etc/rc.local ? И поглядеть, с каким mtu будет в таком случае создан lagg0.11 и будет ли он рабочим. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On 26.09.2019 01:16, Eugene Grosbein wrote: > On 25.09.2019 23:26, Yaroslav Shvets wrote: > >> On Wed, 25 Sep 2019, 15:15, you wrote: >> >>> On 25.09.2019 18:16, Yaroslav Shvets wrote: >>> Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в rc.conf? >>> >>> Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что >>> ещё ломается >>> из-за корявой последовательности, кроме vlanhwfilter. >>> >>> Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с >>> rc.conf. > > [attachments skipped] > > Прошу создать баг (PR) в > https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Base%20System > Описать проблему, обязательно приложить этот rc.conf и console.log, > не забыть упомянуть, что device vlan есть в ядре. > > И прислать мне номер PR. Да, и обязательно надо указать, что это апгрейд с 11.3, в котором всё работало. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On 25.09.2019 23:26, Yaroslav Shvets wrote: > On Wed, 25 Sep 2019, 15:15, you wrote: > >> On 25.09.2019 18:16, Yaroslav Shvets wrote: >> >>> Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в >>> rc.conf? >> >> Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что >> ещё ломается >> из-за корявой последовательности, кроме vlanhwfilter. >> >> Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с >> rc.conf. [attachments skipped] Прошу создать баг (PR) в https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Base%20System Описать проблему, обязательно приложить этот rc.conf и console.log, не забыть упомянуть, что device vlan есть в ядре. И прислать мне номер PR. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On Wed, 25 Sep 2019, 15:15, you wrote: On 25.09.2019 18:16, Yaroslav Shvets wrote: Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в rc.conf? Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что ещё ломается из-за корявой последовательности, кроме vlanhwfilter. Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с rc.conf. -- Yaroslav ShvetsSep 25 18:39:00 gw1 kernel: Setting hostuuid: 0cb452fa-5734-11e5-bb0b-00e081baad90. Sep 25 18:39:00 gw1 kernel: Setting hostid: 0xef5d4ffc. Sep 25 18:39:00 gw1 kernel: Starting file system checks: Sep 25 18:39:00 gw1 kernel: /dev/gpt/disk2-gpt-root: FILE SYSTEM CLEAN; SKIPPING CHECKS Sep 25 18:39:00 gw1 kernel: /dev/gpt/disk2-gpt-root: clean, 7955823 free (1903 frags, 994240 blocks, 0.0% fragmentation) Sep 25 18:39:00 gw1 kernel: /dev/gpt/disk2-gpt-tmp: FILE SYSTEM CLEAN; SKIPPING CHECKS Sep 25 18:39:00 gw1 kernel: /dev/gpt/disk2-gpt-tmp: clean, 16240544 free (48 frags, 2030062 blocks, 0.0% fragmentation) Sep 25 18:39:00 gw1 kernel: /dev/gpt/pt_ssd250_root: FILE SYSTEM CLEAN; SKIPPING CHECKS Sep 25 18:39:00 gw1 kernel: /dev/gpt/pt_ssd250_root: clean, 51980144 free (43040 frags, 6492138 blocks, 0.1% fragmentation) Sep 25 18:39:00 gw1 kernel: /dev/ufs/raidfs: FILE SYSTEM CLEAN; SKIPPING CHECKS Sep 25 18:39:00 gw1 kernel: /dev/ufs/raidfs: clean, 72353497 free (462401 frags, 8986387 blocks, 0.1% fragmentation) Sep 25 18:39:00 gw1 kernel: /dev/gpt/disk2-gpt-var: FILE SYSTEM CLEAN; SKIPPING CHECKS Sep 25 18:39:00 gw1 kernel: /dev/gpt/disk2-gpt-var: clean, 16102996 free (7460 frags, 2011942 blocks, 0.0% fragmentation) Sep 25 18:39:00 gw1 kernel: /dev/gpt/disk2-gpt-varlog: FILE SYSTEM CLEAN; SKIPPING CHECKS Sep 25 18:39:00 gw1 kernel: /dev/gpt/disk2-gpt-varlog: clean, 29536064 free (632 frags, 3691929 blocks, 0.0% fragmentation) Sep 25 18:39:00 gw1 kernel: /dev/gpt/disk2-gpt-usr: FILE SYSTEM CLEAN; SKIPPING CHECKS Sep 25 18:39:00 gw1 kernel: /dev/gpt/disk2-gpt-usr: clean, 198834254 free (116750 frags, 24839688 blocks, 0.0% fragmentation) Sep 25 18:39:00 gw1 kernel: Mounting local filesystems:. Sep 25 18:39:00 gw1 kernel: Setting hostname: gw1. Sep 25 18:39:00 gw1 kernel: Additional TCP/IP options: rfc1323 extensions=NO. Sep 25 18:39:00 gw1 kernel: Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Sep 25 18:39:00 gw1 kernel: Feeding entropy: . Sep 25 18:39:00 gw1 kernel: Created clone interfaces: lagg0 lagg0.11. Sep 25 18:39:00 gw1 kernel: Starting Network: lo0 em0 em1 enc0 lagg0 lagg0.11. Sep 25 18:39:00 gw1 kernel: lo0: flags=8049 metric 0 mtu 16384 Sep 25 18:39:00 gw1 kernel: options=680003 Sep 25 18:39:00 gw1 kernel: inet 127.0.0.1 netmask 0xff00 Sep 25 18:39:00 gw1 kernel: inet6 ::1 prefixlen 128 Sep 25 18:39:00 gw1 kernel: inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 Sep 25 18:39:00 gw1 kernel: groups: lo Sep 25 18:39:00 gw1 kernel: nd6 options=21 Sep 25 18:39:00 gw1 kernel: em0: flags=8843 metric 0 mtu 1500 Sep 25 18:39:00 gw1 kernel: options=81249b Sep 25 18:39:00 gw1 kernel: ether 00:e0:81:ba:ad:90 Sep 25 18:39:00 gw1 kernel: media: Ethernet autoselect (1000baseT ) Sep 25 18:39:00 gw1 kernel: status: active Sep 25 18:39:00 gw1 kernel: nd6 options=29 Sep 25 18:39:00 gw1 kernel: em1: flags=8843 metric 0 mtu 1500 Sep 25 18:39:00 gw1 kernel: options=81249b Sep 25 18:39:00 gw1 kernel: ether 00:e0:81:ba:ad:90 Sep 25 18:39:00 gw1 kernel: hwaddr 00:e0:81:ba:ad:91 Sep 25 18:39:00 gw1 kernel: media: Ethernet autoselect (1000baseT ) Sep 25 18:39:00 gw1 kernel: status: active Sep 25 18:39:00 gw1 kernel: nd6 options=29 Sep 25 18:39:00 gw1 kernel: enc0: flags=0<> metric 0 mtu 1536 Sep 25 18:39:00 gw1 kernel: groups: enc Sep 25 18:39:00 gw1 kernel: nd6 options=29 Sep 25 18:39:00 gw1 kernel: lagg0: flags=8843 metric 0 mtu 1500 Sep 25 18:39:00 gw1 kernel: options=81249b Sep 25 18:39:00 gw1 kernel: ether 00:e0:81:ba:ad:90 Sep 25 18:39:00 gw1 kernel: laggproto lacp lagghash l2,l3,l4 Sep 25 18:39:00 gw1 kernel: laggport: em0 flags=0<> Sep 25 18:39:00 gw1 kernel: laggport: em1 flags=0<> Sep 25 18:39:00 gw1 kernel: groups: lagg Sep 25 18:39:00 gw1 kernel: media: Ethernet autoselect Sep 25 18:39:00 gw1 kernel: status: active Sep 25 18:39:00 gw1 kernel: nd6 options=29 Sep 25 18:39:00 gw1 kernel: lagg0.11: flags=8843 metric 0 mtu 1496 Sep 25 18:39:00 gw1 kernel: options=403 Sep 25 18:39:00 gw1 kernel: ether 00:e0:81:ba:ad:90 Sep 25 18:39:00 gw1 kernel: inet xx.xx.170.82 netmask 0xfff0 broadcast 62.80.170.95 Sep 25 18:39:00 gw1 kernel: groups: vlan Sep 25 18:39:00 gw1 kernel: vlan: 11 vlanpcp: 0 parent interface: lagg0 Sep 25 18:39:00 gw1 kernel: media: Ethernet autoselect Sep 25 18:39:00
Re: [freebsd] В releng-12 опять поломали lagg?
On 25.09.2019 18:16, Yaroslav Shvets wrote: > Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в rc.conf? Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что ещё ломается из-за корявой последовательности, кроме vlanhwfilter. Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с rc.conf. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On Wed, 25 Sep 2019, 13:35, you wrote: 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 --> интерфейс 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 Воспроизвел проблему на 11.3 последовательностью: ifconfig lagg0 create ifconfig lagg0.11 create ifconfig lagg0 laggproto lacp laggport em0 Дело в том, что в чипах сетевых Intel есть аппаратная поддержка vlanhwfilter и она очень полезная: если сеть флудит порт фреймами с разнообразными вланами, то чип фильтрует поток и передаёт хосту только те фреймы, теги которых соответствуют созданным вланам у хоста. При создании нового влана драйвер добавляет в этот фильтр новый тег. Если создавать вланы напрямую поверх em0, то это работает всегда. Если создавать вланы на lagg поверх em0, это работает, если в момент создания влана все аппаратные сетевые уже добавлены в lagg. Теоретически при
Re: [freebsd] В releng-12 опять поломали lagg?
On Wed, 25 Sep 2019, 13:35, you wrote: 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 --> интерфейс 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 Воспроизвел проблему на 11.3 последовательностью: ifconfig lagg0 create ifconfig lagg0.11 create ifconfig lagg0 laggproto lacp laggport em0 Дело в том, что в чипах сетевых Intel есть аппаратная поддержка vlanhwfilter и она очень полезная: если сеть флудит порт фреймами с разнообразными вланами, то чип фильтрует поток и передаёт хосту только те фреймы, теги которых соответствуют созданным вланам у хоста. При создании нового влана драйвер добавляет в этот фильтр новый тег. Если создавать вланы напрямую поверх em0, то это работает всегда. Если создавать вланы на lagg поверх em0, это работает, если в момент создания влана все аппаратные сетевые уже добавлены в lagg. Теоретически при
Re: [freebsd] В releng-12 опять поломали lagg?
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 --> интерфейс 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 > Воспроизвел проблему на 11.3 последовательностью: ifconfig lagg0 create ifconfig lagg0.11 create ifconfig lagg0 laggproto lacp laggport em0 Дело в том, что в чипах сетевых Intel есть
Re: [freebsd] В releng-12 опять поломали lagg?
On 25.09.2019 08:02, Yaroslav Shvets wrote: > p.s.: раньше при mtu 1500 на lagg0 на vlan'ах mtu становился 1496 Это признак того, что вланы создаются в тот момент, когда в lagg нету сетевых с аппаратной поддержкой тегов (физический MTU больше 1500). ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
On 25.09.2019 08:02, Yaroslav Shvets wrote: > С переименованием vlan11 через rc.conf вышло странное. > vlan11 создался, переименовался и получилось: > # ifconfig -v lagg0.11 > lagg0.11: flags=8002 metric 0 mtu 1500 > ether 00:00:00:00:00:00 > groups: vlan > vlan: 0 vlanpcp: 0 parent interface: > nd6 options=29 > > p.s.: раньше при mtu 1500 на lagg0 на vlan'ах mtu становился 1496 Переименование выполняется до последущей настройки интерфейса, поэтому вместо ifconfig_vlan11="..." при использовании переименования надо писать: ifconfig_lagg0_11="..." ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
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
Re: [freebsd] В releng-12 опять поломали lagg?
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" Сначала без смены имени. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
Hello Eugene Grosbein. 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. Но времени совсем немного. Попробую сегодня ночью. По результатам отпишусь. -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
23.09.2019 8:46, Yaroslav Shvets пишет: > Сервер, к сожалению, рабочий, и экспериментировать часто не получается. > Но обязательно попробую, как будет возможность. > > Пока выяснилось, что сам lagg работает с нетегированными пакетами. > Проблема только - с тегированными. Т.е. не работает ни один > из vlan'ов построенных на lagg, но сам lagg - рабочий. Очень может быть, что дело как раз в сломанном аппаратном offload для vlanhwtag/vlanhwfilter. Более того, такое уже бывало в старых версиях, но с другими драйверами. Крайне желательно это выяснить побыстрей, пока ещё есть немного времени успеть починить к 12.1-RELEASE. Но времени совсем немного. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
Hello Eugene. On Sat, 21 Sep 2019, 10:16, you wrote: 21.09.2019 3:31, Yaroslav Shvets пишет: Hello All. 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, которая уже приближается. JFYI: Увы. Переход на 12.1-PRERELEASE r352519 ничего не дал. vlan'ы поверх lagg (собранного из двух em) не работают. А не помогает ли отключение всяческих offload на em? Только это делать надо до объединения их в lagg: ifconfig em0 -rxcsum -txcsum -tso4 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwcsum -vlanhwtso И для em1 тоже. Если вдруг поможет, то было бы неплохо найти именно тот флаг из них, что решает проблему (простым перебором или дихотомией). Сервер, к сожалению, рабочий, и экспериментировать часто не получается. Но обязательно попробую, как будет возможность. Пока выяснилось, что сам lagg работает с нетегированными пакетами. Проблема только - с тегированными. Т.е. не работает ни один из vlan'ов построенных на lagg, но сам lagg - рабочий. -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
21.09.2019 3:31, Yaroslav Shvets пишет: > Hello All. > > 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, >> которая уже приближается. > > JFYI: > Увы. Переход на 12.1-PRERELEASE r352519 ничего не дал. > vlan'ы поверх lagg (собранного из двух em) не работают. А не помогает ли отключение всяческих offload на em? Только это делать надо до объединения их в lagg: ifconfig em0 -rxcsum -txcsum -tso4 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwcsum -vlanhwtso И для em1 тоже. Если вдруг поможет, то было бы неплохо найти именно тот флаг из них, что решает проблему (простым перебором или дихотомией). ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
Hello All. 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, которая уже приближается. JFYI: Увы. Переход на 12.1-PRERELEASE r352519 ничего не дал. vlan'ы поверх lagg (собранного из двух em) не работают. -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
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. Отпишусь потом. Спасибо. -- Yaroslav Shvets ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] В releng-12 опять поломали lagg?
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, которая уже приближается. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
