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