[Comm] linux vlan

[Oleg K.Artemjev]

On Fri, 19 Sep 2003 00:09:39 +1100
Dmitry Lebkov <dima на sakhalin.ru> wrote:

> > eth0.0         | 0  | eth0
> > eth2.0         | 0  | eth2
> > Но если в eth0 включить общую сеть, а в eth2 - компьютер через
> > кроссовер или хаб, то он не пожет пропинговать остальных.
> > Что я делаю не так?
На всякий случай почитайте FAQ по устройству vlan с сайта, например, cisco.
Vlan это некая обертка к фрейму (согласно 802.1q), т.е. такой фрейм без спец.
драйвера виндовым клиентом не воспрнимается (отбрасывается как нестандартной для 802.1 длины),
на unix системах роль спецдрайвера играет патч к ядру (которая затрагивает драйвера сетевух).
Соответственно завертывалку в vlan ты поставил, но один момент не учел - для того чтобы линух 
работал в качестве свитча ему нужно включить бриджинг(2х портовый свитч это бридж). То есть по
умолчанию линух работает на сетевом уровне, а форвардинг на канальном включается только после
включенного в ядре bridging'а.

> Что-то не так либо с постановкой задачи, либо с реализацией. Если
> я ничего не путаю, то идея VLAN'ов в ядре следующая:
>  - есть eth-интерфейс с ip-адресом. Все пакеты, идущие через
>    него не маркируются (un-tagged packets) как принадлежащие
>    к какому-то VLAN'у. Это так называемый managemen vlan, в
>    терминологии Cisco. Интерфейс является транком (trunk) для
>    остальных vlan'ов, привязанных к нему;
Верно. Если Вы перенесли IP адрес соответствующий management vlan на
802.1q интерфейс, то покуда Вы не попросите свитч оборачивать в 802.1q
еще и management vlan - хрен кого пропингуешь по IP с management vlan'а.

>  - есть vlan-интерфейсы, привязанные к trunk'у и имеющие свои
их еще бывает зовут "дот один ку" от ".1q"

>    ip-адреса. Пакеты, идущие через эти интерфейсы, маркируются
>    как принадлижаще vlan'у с номером, совпадающим с номером 
>    интерфейса;
Верно - фрейм увеличивается на заголовок vlan и перестает восприниматься 
"обычными" дровами для сетевух.

> Если не используются свитчи, понимающее 802.1Q VLANs, то клиенты
> в _одном физ.сегменте_ должны сами разбирать, какой из маркированых
> пакетов предназначен для них, а какой нет (принадлежность к VLAN'у
> настраивается в драйверах сетевой карты на клиенте).
Дурной вариант - любой поставивший себе "спец дрова" будет видеть все vlan.
 
> Если используется какой-либо свитч - то разбором tagged-пакетов (и
> оправкой их в соответствующий порт) занимется этот самый свитч,
> при условии, что Linux и свитч соединены через trunk-интерфейс.
верно.

> Вот, вроде бы так. Т.е. связка Linux(vlans)+Switch обеспечивает
> тебя набором _физических_ сетевых интерфейсов, равных кол-ву
> портов на свитче-1 (один занимается под trunk).
> Поправьте меня, если я где-то что-то напутал ... %)
Все правильно, разве что один момент - наглядность (физический смысл) 
появляется лишь когда объясняют работу на уровне длины фрейма.

> Ты же, привязав vlan0 к eth0 и eth2 пытаешся добиться от Linux'a
> поведения, аналогичного switch'у -- назаначить двум портам один
> влан и они будут как бы один сегмент. Если я не ошибаюсь - vlan'ы
> в Linux'е так не работают.
Нет, тут дело не в не работают, хотя и такое вероятно - совмещать бриджинг
с vlan я не пробовал и то, что это будет работать правильно нигде не 
упоминается (я не видел) - надо проверять экспериментальным путем. Он 
просто не знал что проброс на канальном уровне требует специальных усилий,
то есть чтобы они осуществлялись надо эмулировать соединение между сетевыми
картами а-ля кроссовер (на самом деле там еще деление коллизионных доменов
с отбросом битых пакетов), то есть это подразумевает, что такую эмуляцию надо
включить.

PS: Если у Вас получится (или не получится) срастить bridging с vlan, не поленитесь - мыльните мне
о результатах на <olli @ mtcm . ru> , а также в удачном варианте - о производительности. Судя по тому, что я
слышал от коллеги который игрался с бриджингом - производительность на старом железе 
(а-ля первый пень) не поднимается выше 30К/секунду, что объясняется многочисленными перекладываниями
фейма внутри PC (то есть это существенно медленне чем store and forward в cisco). Если Вам удасться получить
производительность хотя бы на уровне 300K/с, то это уже интересно.

-- 
Bye.Olli.			http://olli.digger.org.ru