VLAN на свиче RTL8305SC

[dimedrol]

Добрый день! Возникла проблема с сабжем. Вкратце: у свича выведено 3 порта(0,1,2), порт 4 используется как MII для связи с микроконтроллером; с помощью VLAN в свиче и логики драйвера ОС необходимо реализовать 3 независимых сетевых карты со своими МАС и подсетями. На свиче включен VLAN и прописаны 3 сетки с "членством" портов (0-4) (1-4) (2-4), в драйвере я разбираюсь от какого порта пришел пакет по VLAN тегу, который добавил свич (port-based VLAN), из драйвера ОС (QNX 6.5.0) я посылаю пакет с добавленым VLAN тегом в порт 4 (tag-based VLAN), чтобы приказать свичу послать пакет в нужный порт(0,1,2). В результате как бы получаются три сетевых интерфейса для системы и три "дырки" на плате соответствующие им. Дополнительно на портах 0,1,2 включен фильтр, отрезающий VLAN теги, чтобы они не шли в сеть, а на порту 4, соответственно фильтр добавляющий тег с номером порта с которого пакет пришел.
Все работает замечательно, пока порты 0,1,2 включены в свои сегменты сети, однако в одном сегменте все начинает вести себя просто ужасно. Эксперимент:
Порт 0 воткнут в хаб, а хаб уже в сеть. Пингуем машину в сети - пинг идет. Включаем порт 1 в тот же хаб, по идее с работающим вышеописанным образом VLAN в свиче это эквивалентно простому подключению еще одной сетевой карточки к сетке, однако тут же загибается пинг по 0 порту и не восстанавливается вообще, пока порт 1 не будет вынут из хаба. Отладка показывает, что пакеты по 0-му порту начинаются хаотически теряться то в одну, то в другую сторону, логика не прослеживается. Есть подозрения, что виновата логика свича, работающая с МАС адресами, хотя из даташита следует, что, если включен VLAN, пакеты должны идти согласно логики VLAN, а не MAC таблицы. У кого есть соображения по этому поводу, что делать, чтобы заставить такую конфигурацию работать как 3 сетевых карты независимых?

[Dimka]

dimedrol, хаб ретранслирует сигнал. Как можно 2 порта свича воткнуть в один и тот же хаб? Это аналог короткого замыкания в электрических цепях. Чего ты оборудование с ума сводишь?

[RXL]

dimedrol, свич (коммутатор) запоминает «услышанные» MAC-адреса и ассоциирует их с портами. Включив два порта в одну физическую сеть ты некорректно применяешь свич. Хаб пора выкинуть на помойку (если только он не применяется для прослушки трафика).

[dimedrol]

Dimka, свитч (имеется ввиду микросхема, которую я программирую, а не некий черный ящик) не просто воткнут в хаб, это понятно что я бы положил всю сеть таким включением, так как получается петля, размножающая пакеты. Тут фишка в том что внутри свича включен VLAN который разделяет порты, короче пакеты могут гулять только по путям 0-4 1-4 2-4, где порт 4 смотрит в систему, где мой драйвер, а порты 0 1 2 - это дырки на плате. Получается что свитч то и не свитч теперь, рассыпался так сказать на 3 отдельных канала передачи данных короче, что-то типа http://mcmcc.bat.ru/vlan/, где такое применение метко названо "VLAN разветвителем".
RXL, по идее, когда включен VLAN, свич должен руководствоваться правилами пересылки пакетов по этим VLAN а  не МАС таблицей соответствия, и превратиться в пассивный разветвитель.

[RXL]

dimedrol, VLAN не является отдельной сетью. Это лишь протокольная обертка 802.1q для payload, вкладываемая в пакет 802.3. MAC-таблица работает с 802.3.

[dimedrol]

В свиче можно настроить 16 VLAN, для каждого прописывается 1) идентификатор 2)битовая маска членства портов в этом VLAN, если входной порт проецируется(для каждого порта можно сконфигурить соотвествие VLAN-у, которое срабатывает, если входной пакет без VLAN тега) на конкретный VLAN c маской 10001, то с этого порта пакет пойдет только на порт 4. Я так понял, в таком случае МАС вообще не проверяется, ну в крайнем случае сверяется, если по маске получается больше 1 порта назначения, если соответствия нет, то шлет бродкастом на все порты  этого VLAN.

[RXL]

Свич выполняет следующие действия с поступившим пакетом.
1. Получение пакета.
2. Фильтр пакета по untagged/VLANs для входного интерфейса.
3. Обновление MAC-таблицы для srcMAC.
4. Маршрутизация по dstMAC — выбор исходящего интерфейса. Если нет информации, отослать по всем интерфейсам с подходящим untagged/VLAN.
5. Приведение пакета в соответствие untagged/VLAN согласно настройкам исходящего интерфейса.
6. Отправка пакета.

Пункт 4 является здесь ключевым. Не знаю, стандартизировал ли он как-то.

Итоговый сценарий, который у тебя наблюдается:
Ты передал пакет {srcMAC, dstMAC, VLAN(1)} на интерфейс 4.
Свич не знает, куда надо его отправить (в MAC-table нет dstMAC) и отправляет его на все интерфейсы, где разрешен данный VLAN: интерфейс 0.
Настройки интерфейса 0 требуют отправить untagged.
Ping-пакет с интерфейса 0 достиг хост назначения.
Хост ответил.
Ответ синхронно поступает на порты 0 и 1.
Свитч пропускает их по фильтру untagged.
Свич обновляет MAC-table согласно srcMAC. Пакеты обработаны по очереди и последний (с интерфейса 1) перезаписал MAC-table на свой входной интерфейс.
Следующий ping уйдет с интерфейса 1.

Вывод: либо чип не применяет исходящий фильтр по VLAN при выборе маршрута, либо ты его не правильно настроил.

При этом я по прежнему утверждаю: «некорректное применение гранаты».

[dimedrol]

Тут фишка в том что untagged пакеты тоже машрутизуются по VLAN, тут идет port based VLAN, для каждого порта статически прописан VLAN в таком случае. Тут получил официальный ответ от realtek на свой запрос

RTL8305SC is an old chip, we do not recommend it for a new design-in project, and RTL8305SC does not support IVL( independent VLAN learning), it support SVL( share VLAN learning) only, so if a physical loop between ports, the MAC forwarding would not follow the VLAN rule due to lack of IVL feature, thx.

Похоже дело выглядит так, сначала свич ищет соотвествие МАС адресу и видит, что этот МАС для порта, который не входит в VLAN маску для порта по которому пришел пакет, и отбрасывает его. Жаль что в даташите это не прописано вообще. Я думал все-таки свич руководствуется в первую очередь VLAN ом, а не таблицой маршрутизации иначе это стремно дейтсвительно, если сети имеют между собой мостики.

[RXL]

В идеале таблица маршрутизации могла бы иметь селектор VLAN+MTU+MAC.

[dimedrol]

получается, что в случае IVL таблица маршрутизации строится для каждого VLAN в отдельности, что в принципе эквивалентно случаю таблицы по VLAN+MAC. Меня во всей этой ситуации больше удивил приоритет МАС над VLAN и то зачем резать пакеты мирно гуляющие по одному VLAN, если МАС диктует оправить его в другой.

[Dimka]

Я вообще не понимаю, почему надо замыкать хабом порты вне зависимости от VLAN или любых иных технологий, если это создаёт петлю, а потом "надеяться", что ничего не сломается.

Ладно ещё свичи, а если это атомный реактор? Что это вообще за подход к испытаниям?

[dimedrol]

Какраз нормальный подход Во первых петлю это не создает, так как порты на уровне свича не сообщаются, уже выходит просто 3-х головая сетевуха, во-вторых - а если на объекте кто так "мостик" кинет по запарке? все ляжет, хотя никак не должно.

[sss]

dimedrol, привет. Я так понял порты 0-3  не тэггируют исходящие пакеты. Или во всех сегментах только 802.1Q совместимое оборудование?
Если тэггирует, это совсем не похоже на строенную сетевую карту. Если не тэггирует - то и нет значит информации VLAN, относительно которой
можно было бы заставить работать концентратор ...

[dimedrol]

Привет. Совместимого оборудования нет, на выходе из свича порта 0 1 2 режут теги, чтобы они  не шли в сеть, изначально эти теги при передаче пакета в сеть добавляются в драйвере, чтобы свич знал куда из 4-ого порта спускать пакет. При приеме пакета на порту 0 1 2 свич сам вставляет тег в пакет или модифицирует имеющийся номером порта. Одним словом 802.1Q теги гуляют только от драйвера ОС до 4 порта. Структура потоков данных поддерживается VLAN тегами внутри самой микрухи свича.

[sss]

.. порта 0 1 2 режут теги...

Тогда о чём речь? Получается через хаб ты и "закоротил" порты... VLAN там нет..
Кстати в моём концентраторе L2 есть алгоритмы обнаружения подобных случаев. Он просто
пытается давить пакеты от одинаковых MAC в разных портах.
И не важно  VLAN не VLAN.. (не знаю, не уверен на самом деле)

[RXL]

sss, есть специальный случай, когда такое допустимо. Сразу скажу, что к задаче ТС это не относится. У разных производителей фича называется по разному: trunking, bonding и пр. Смысл в объединении нескольких портов в один логический с целью резервирования или суммирования пропускной способности.

[dimedrol]

да просто странно, я думал что при включеном VLAN свич будет первым делом глядеть на принадлежность порта VLAN и для членов этого VLAN (тут для всех портов один член - 4) рассылать пакеты, в крайнем случае посмотрит МАС таблицу соответствия портам и пошлет на какой-то один, если он в этом VLAN или пошлет на все порты VLAN, если запись не нашлась или порт назначения не принадлежит VLAN пакета. В таком случае какая разница пришло два одинаковых пакета на разные порты или нет, и какой МАС для какого порта запомнился - наверх в 4-ый порт просто две копии придут. А на деле все клинит.

[sss]

 RXL, видел возможность, но у меня руки не доходили разобраться  ...

dimedrol, честно не понял о чём ты? Вот, например исходит пакет из порта 0,  хаб его повторяет и
доставляет в порт 1. Что делать концентратору с этим пакетом?

[dimedrol]

свичу нужно увидеть что пакет пришел с порта 1, для него VLAN по умолчанию для untagged пакетов с маской 10010 по портам (4-1), ищем DST МАС, видим, что он записан для 0-ого порта например, 0-ой порт не входит в маску VLAN, порт назначения не определен в пределах VLAN - делаем широковещательную рассылку по маске, т.е. за исключением 1 порта, с которого пришел пакет - на 4 ый. Получаем копию пакета на входе.

[sss]

dimedrol, пакет исходящий из 0. DST MAC не 0 порта.. SRC MAC  0 порта.
В общем, я думаю, нормально ведёт себя устройство.. 

А, понял, DST MAC из таблицы MAC-ов 0 порта. Т.е., в случае хаба, кто успел, того и тапки?
Кто первый зарегистрировался в таблице MAC такой и VLAN ID ?

Добавлено через 1 минуту и 26 секунд:
У портов есть MAC, а я не догоняю?

[dimedrol]

нет, я имею ввиду таблицу "маршрутизации" МАС, там записи вида МАС—>номер порта

[sss]

...
Есть подозрения, что виновата логика свича, работающая с МАС адресами, хотя из даташита следует, что, если включен VLAN, пакеты должны идти согласно логики VLAN, а не MAC таблицы. У кого есть соображения по этому поводу, что делать, чтобы заставить такую конфигурацию работать как 3 сетевых карты независимых?

Да виновата логика работающая с МАС, потому что VLAN тэгов просто нет в пакетах. По моему это ответ, нет?

[dimedrol]

тегов то нет, но еще раз повторюсь, этот свич разбирает untagged пакеты на портах, как если бы они были tagged, так как за портом присвоено членство в VLAN для таких пакетов. Тут похоже виновата таблица маршрутизации, одна на все VLAN. Например в KSZ8895MQ, элемент таблицы выглядит как MAC,VLAN ID,порт, т.е. для каждого VLAN своя таблица по сути; если пакет придет одновременно на два порта, то запись его SRC MAC произойдет два раза для каждого VLAN отдельно.

[sss]

Не хочу выглядеть вредным, однако всё же термин таблица маршрутизации стандартизирован, он касается ip и никак не может так
называться, если применена некая технология. Я понимаю, что у каждого порта есть таблица сопоставления  ip<->MAC. Причём она
динамическая и обновляется с неким диапазоном. Т.е. если устройство подключено через хаб к двум портам, то равновероятно его
MAC может появиться как в MAC таблице одного порта, так и в MAC таблице другого. По моему именно это и происходит.
Теперь вопрос - эту таблицу можно жёстко задавать что ли?

Добавлено через 2 минуты и 39 секунд:
Может быть есть протокол ARP (RARP) с VLAN ID?

[Dimka]

В свич должна попать информация, чтобы что-то работало. Это присланный снаружи либо бродкаст, либо дата-фрейм на конкретный адрес. Если бродкаст, то петля - естественное явление. Если адрес конкретный, то он принадлежит какому-то из VLAN. Если замкнутые на хаб порты свича принадлежат разным VLAN, ничего не пройдёт, если одному и тому же, будет петля.

Т.е. в результате либо ничего, либо сбой. И непонятно, какую работу таким тестом хочется проверить?

[sss]

Т.е. в результате либо ничего, либо сбой. И непонятно, какую работу таким тестом хочется проверить?

Да, что именно должно сделать устройство, что бы удовлетворять реципиенту   ?

Нда.. Наверное я достал своей тупостью. Больше ничего в эту тему - я больше по ней ничего не знаю 

[RXL]

dimedrol, ситуация, которую ты получил, не является допустимой при эксплуатации. Попробуй представить ситуацию, когда от какого-либо устройства требуется включения двух ethernet-интерфейсов в один хаб. Да и хабы на сегодняшний день — экзотика.

[dimedrol]

Наконец спаяли железку на свиче KSZ8895MQ, у него поиск по МАС таблице и дет не просто по MAC адресу, а по MAC+FID, где FID суть идентификатор VLAN сети. Создал 3 VLAN сетки VIDs=[1 2 3], членство портов в сети: [15] [25] [35], порты 1 2 3 - суть независимые сетевые карты, порт 5 смотрит в контроллер. Все зашибись, работает стабильно в нескольких подсетях, даже при подключении через хабы.