[Comm] Ядро 2.6.39-std-def-alt2.1 и vlan'ы

[Comm] Ядро 2.6.39-std-def-alt2.1 и vlan'ы

[Alexei Takaseev]

Приветствую!

А не наблюдалось ли у достопочтимой публики проблем с vlan'ами на ядре 2.6.39-std-def-alt2.1 бранча P6?

Система сервер HP DL-160, 1.1.6 Server Light догнанный до последнего бранча P6. Раньше использовалось ядро el-smp все работало нормально, решил попробовать ветку std-def и обнаружил неработающий vlan. Система просто не распознает и отбрасывает пакеты с метками 802.1q. Для меня это как бы не очень критично, вернулся обратно на el-smp, но мало ли. Может это у меня локальный закидон, а может с самим ядром не все хорошо.

Re: [Comm] Ядро 2.6.39-std-def-alt2.1 и vlan'ы

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Alexei Takaseev" <alexei@taf.ru>
> Кому: "ALT Linux Community general discussions" <community@lists.altlinux.org>
> Отправленные: Воскресенье, 10 Июль 2011 г 2:22:20
> Тема: [Comm] Ядро 2.6.39-std-def-alt2.1 и vlan'ы
> Приветствую!
> 
> А не наблюдалось ли у достопочтимой публики проблем с vlan'ами на ядре
> 2.6.39-std-def-alt2.1 бранча P6?
> 
> Система сервер HP DL-160, 1.1.6 Server Light догнанный до последнего
> бранча P6. Раньше использовалось ядро el-smp все работало нормально,
> решил попробовать ветку std-def и обнаружил неработающий vlan. Система
> просто не распознает и отбрасывает пакеты с метками 802.1q. Для меня
> это как бы не очень критично, вернулся обратно на el-smp, но мало ли.
> Может это у меня локальный закидон, а может с самим ядром не все
> хорошо.

Дополнение. Аналогичный глюк обнаружился и на другой машине.

Были мысли, что дело в модуле сетевой карты. Но в одном случае это был igb, во втором - atl1e.

Так так что что-то поломалось в районе 8021q

Re: [Comm] Ядро 2.6.39-std-def-alt2.1 и vlan'ы

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Alexei Takaseev" <alexei@taf.ru>
> Кому: "ALT Linux Community general discussions" <community@lists.altlinux.org>
> Отправленные: Воскресенье, 10 Июль 2011 г 2:43:06
> Тема: Re: [Comm] Ядро 2.6.39-std-def-alt2.1 и vlan'ы
> ----- Исходное сообщение -----
> > От: "Alexei Takaseev" <alexei@taf.ru>
> > Кому: "ALT Linux Community general discussions"
> > <community@lists.altlinux.org>
> > Отправленные: Воскресенье, 10 Июль 2011 г 2:22:20
> > Тема: [Comm] Ядро 2.6.39-std-def-alt2.1 и vlan'ы
> > Приветствую!
> >
> > А не наблюдалось ли у достопочтимой публики проблем с vlan'ами на
> > ядре
> > 2.6.39-std-def-alt2.1 бранча P6?
> >
> > Система сервер HP DL-160, 1.1.6 Server Light догнанный до последнего
> > бранча P6. Раньше использовалось ядро el-smp все работало нормально,
> > решил попробовать ветку std-def и обнаружил неработающий vlan.
> > Система
> > просто не распознает и отбрасывает пакеты с метками 802.1q. Для меня
> > это как бы не очень критично, вернулся обратно на el-smp, но мало
> > ли.
> > Может это у меня локальный закидон, а может с самим ядром не все
> > хорошо.
> 
> Дополнение. Аналогичный глюк обнаружился и на другой машине.
> 
> Были мысли, что дело в модуле сетевой карты. Но в одном случае это был
> igb, во втором - atl1e.
> 
> Так так что что-то поломалось в районе 8021q

Все еще веселее. На третьей машине, древнючем HP DL-120G2 vlan'ы на 2.6.39-std-def-alt2.1 работают!

вывод lspci с работающей системы:
16:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11)
17:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11)

с не работающий систем:

02:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)

и

05:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
05:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

в логах ядра при неудачном запуске vlan замечены такие сообщения:

================
Jul 10 01:43:40 pluto kernel: [   14.848383] NET: Registered protocol family 10
Jul 10 01:43:40 pluto kernel: [   14.850849] ADDRCONF(NETDEV_UP): eth0: link is not ready
Jul 10 01:43:40 pluto kernel: [   14.859948] Bridge firewalling registered
Jul 10 01:43:40 pluto kernel: [   14.861982] device eth0 entered promiscuous mode
Jul 10 01:43:40 pluto kernel: [   14.873847] ADDRCONF(NETDEV_UP): breth0: link is not ready
Jul 10 01:43:40 pluto kernel: [   15.287187] 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
Jul 10 01:43:40 pluto kernel: [   15.287190] All bugs added by David S. Miller <davem@redhat.com>
Jul 10 01:43:40 pluto kernel: [   15.287203] 8021q: adding VLAN 0 to HW filter on device eth0
Jul 10 01:43:40 pluto kernel: [   15.355824] ADDRCONF(NETDEV_UP): vlan9: link is not ready
Jul 10 01:43:40 pluto kernel: [   15.420566] device vlan9 entered promiscuous mode
Jul 10 01:43:40 pluto kernel: [   15.432331] ADDRCONF(NETDEV_UP): breth1: link is not ready
Jul 10 01:43:41 pluto kernel: [   16.829995] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Jul 10 01:43:41 pluto kernel: [   16.830785] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jul 10 01:43:41 pluto kernel: [   16.830824] breth0: port 1(eth0) entering forwarding state
Jul 10 01:43:41 pluto kernel: [   16.830827] breth0: port 1(eth0) entering forwarding state
Jul 10 01:43:41 pluto kernel: [   16.831562] ADDRCONF(NETDEV_CHANGE): breth0: link becomes ready
Jul 10 01:43:41 pluto kernel: [   16.832180] ADDRCONF(NETDEV_CHANGE): vlan9: link becomes ready
Jul 10 01:43:41 pluto kernel: [   16.832210] breth1: port 1(vlan9) entering forwarding state
Jul 10 01:43:41 pluto kernel: [   16.832213] breth1: port 1(vlan9) entering forwarding state
Jul 10 01:43:41 pluto kernel: [   16.832812] ADDRCONF(NETDEV_CHANGE): breth1: link becomes ready
Jul 10 01:43:42 pluto kernel: [   18.114214] ip_tables: (C) 2000-2006 Netfilter Core Team
Jul 10 01:43:43 pluto kernel: [   18.329116] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
Jul 10 01:43:43 pluto kernel: [   18.370743] ADDRCONF(NETDEV_UP): virbr0: link is not ready
Jul 10 01:43:44 pluto kernel: [   20.034113] device vnet0 entered promiscuous mode
Jul 10 01:43:44 pluto kernel: [   20.034769] breth1: port 2(vnet0) entering forwarding state
Jul 10 01:43:44 pluto kernel: [   20.034771] breth1: port 2(vnet0) entering forwarding state
Jul 10 01:43:51 pluto kernel: [   26.940349] vlan9: no IPv6 routers present
Jul 10 01:43:51 pluto kernel: [   27.275819] breth1: no IPv6 routers present
Jul 10 01:43:52 pluto kernel: [   27.507407] eth0: no IPv6 routers present
Jul 10 01:43:52 pluto kernel: [   27.770993] breth0: no IPv6 routers present
Jul 10 01:43:55 pluto kernel: [   30.598301] vnet0: no IPv6 routers present
Jul 10 01:43:56 pluto kernel: [   31.828264] breth0: port 1(eth0) entering forwarding state
================

При нормальном запуске на el-smp ничего подобного в логи не пишется.

Re: [Comm] Ядро 2.6.39-std-def-alt2.1 и vlan'ы

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

On Sat, Jul 09, 2011 at 05:22:20PM -0000, Alexei Takaseev wrote:
> А не наблюдалось ли у достопочтимой публики проблем с vlan'ами на
> ядре 2.6.39-std-def-alt2.1 бранча P6?
> 
> Система сервер HP DL-160, 1.1.6 Server Light догнанный до последнего
> бранча P6. Раньше использовалось ядро el-smp все работало нормально,
> решил попробовать ветку std-def и обнаружил неработающий vlan.
> Система просто не распознает и отбрасывает пакеты с метками 802.1q.
> Для меня это как бы не очень критично, вернулся обратно на el-smp,
> но мало ли. Может это у меня локальный закидон, а может с самим
> ядром не все хорошо.

Используется ли в этой системе комбинация bridge+vlan?  Начиная с ядра
2.6.37, поведение ядра в такой конфигурации унифицировано для всех
типов сетевых карт (независимо от наличия аппаратной поддержки VLAN) -
после добавления интерфейса в мост все входящие пакеты по умолчанию
обрабатываются именно мостом, а не модулем 8021q.  В предыдущих
версиях поведение ядра зависело от того, поддерживает ли драйвер режим
NETIF_F_HW_VLAN_RX - для карт, не умеющих обрабатывать VLAN
самостоятельно, поведение было таким же, как для всех карт в новых
ядрах, а для карт с аппаратной поддержкой VLAN модуль 8021q
перехватывал входящие пакеты до bridge.

Для восстановления работоспособности старой конфигурации необходимо
прекратить направление пакетов нужных VLAN в мост, используя ebtables:

  ebtables -t broute -A BROUTING -i $interface --vlan-id $vlan_id -j DROP

или, если в мост должны идти только пакеты без тегов VLAN:

  ebtables -t broute -A BROUTING -i $interface -p 802_1Q -j DROP

(Всегда нужно указывать имена интерфейсов, чтобы правило не
срабатывало для VLAN-интерфейсов, если они тоже включены в мосты - в
этом случае пакет после его перенаправления в модуль 8021q опять
попадёт в цепочку BROUTING уже с именем VLAN-интерфейса.)

На самом деле это описано очень давно:

  http://ebtables.sourceforge.net/misc/brnf-faq.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Ядро 2.6.39-std-def-alt2.1 и vlan'ы

[Alexei Takaseev]

> Используется ли в этой системе комбинация bridge+vlan?

Именно такая комбинация и есть.

> Для восстановления работоспособности старой конфигурации необходимо
> прекратить направление пакетов нужных VLAN в мост, используя ebtables:
> 
> ebtables -t broute -A BROUTING -i $interface --vlan-id $vlan_id -j
> DROP
> 
> или, если в мост должны идти только пакеты без тегов VLAN:
> 
> ebtables -t broute -A BROUTING -i $interface -p 802_1Q -j DROP


Спасибо большое!

В моем случае оказалось проще переместить обработку vlan-тэгов внутрь гостевых систем (а дело происходило на серверах с виртуалками). В какой-то мере это даже упростило мне всю систему.