VLAN - Коммутация фреймов

Для общего понимания, что такое VLAN и зачем нужен, желательно ознакомиться заранее по источникам в сети. Например по данной статье - MOXA - ТЕХНОЛОГИЯ VLAN. Здесь рассмотрим лишь аспекты реализации связанные с 1923КХ028.

Самое основное:

1. Разбиение абонентов одной сети на принадлежность к различным VLAN сетям необходима чтобы Широковещательные фреймы ходили только в пределах своей VLAN сети. Абоненты из разных сетей VLAN изолированы друг от друга, потому что коммутатор пересылает сообщения от порта с заданным VLAN_ID, только портам с таким же VLAN_ID.
2. В случае НЕ широковещательных фреймов, коммутация осуществляется по МАС источника и МАС назначения, что само по себе дает локализацию такого трафика между двумя абонентами. Но если МАС таблицы еще не обучены, и не знают в каком порту находится МАС назначения, то трафик рассылается всем портам у которых VLAN_ID такой же, как у порта принявшего фрейм.
3. тегированный VLAN трафик обычно ходит лишь между коммутаторами. Устройства подключенные к коммутаторам ничего про VLAN не знают, они общаются обычным не тегированным трафиком. Т.е. сегментирование сети на виртуальные подсети (Virtual Local Area Network) происходит за счет настройки портов коммутаторов.

Коммутация пакетов в коммутаторе 1923КХ028 является VLAN-Based (Бывает еще Port-Based). Т.е. для маршрутизации фрейма ему присваивается VLAN таг, даже если фрейм пришел нетегированый. Для этого, когда какой-либо из портов микросхемы принимает нетегированный фрейм, то этому фрейму присваивается тег данного порта. Тег не вставляется непосредственно в тело пакета, а хранится где-то в заголовке принятого фрейма.

Далее пакет с тегом маршрутизируется согласно таблицам МАС и VLAN и рассылается на необходимые порты. Если порт назначения подключен к РС, принтеру или другому обычному абоненту, то фрейм уходит без тега. Если же порт назначения является TRUNC портом, т.е. портом подключенным к другому VLAN коммутатору, то необходимо передать тег в теле пакета. Это необходимо, т.к. абонент назначения подсети VLAN может находится на портах этого соседнего коммутатора.

Настроки для каждого из 16-ти портов 1923КХ029 хранятся в паре регистров классификатора PORT0_STRUC1/PORT0_STRUC2, PORT1_STRUC1/PORT1_STRUC2, и т.д. Последняя пара PORT16_STRUC1/PORT16_STRUC2 относится к порту Хоста, т.е. для классификатора Хост является 17-м портом. Биты настройки портов в данных регистрах следующие:

PORTх_STRUC1:

• 0 ..15: TPID - Идентификатор протокола тегирования, для стандарта VLAN 802.1Q значение TPID - 0x8100.
• 16..28: VID - VLAN_ID порта, идентификатор подсети VLAN. Все нетегированные фреймы, принятые из сети на данный порт, получают тег порта для последующей коммутации. Тегированные фреймы сохраняют свой собственный тег.

PORTх_STRUC2:

• 0: SHUTDOWN - выключение порта
  • 0 - порт работает (по умолчанию)
  • 1 - выключение порта
• 4..7: AFT (AcceptFrameType) - выбор какие пакеты может принимать данный порт (остальные дропаются):
  • 0 - AnyTagged - принимаются тегированные и нетегированные фреймы
  • 1 - TaggedOnly - принимаются только тегированые фреймы
  • 2 - UntaggedOnly - принимаются только НЕ тегированые фреймы
• 8..11: BLOCK_STATE - действие при приеме RSTP фрейма с данного порта
  • 0 - Forwarding - послать для обучения на Хост и переслать в остальные порты
  • 1 - Blocked - выбросить пакет, ничего не делать
  • 2 - LearnOnly - послать для обучения на Хост
• 12: CFI (CanonicalFrameIdentificator) - Не используется. Использовался раньше, для совместимости с сетями Token Ring.
• 13..15: PRI - Приоритет обработки пакета для ClassOfService (CoS)
• 16..18: TC - TrafficControl, выбор маппирования для режима MACDA2TC CoS.
• 19: TRUSTED - Указывает, что порт является доверенным. See Google! (DHCP Snooping)
• 20: VID_PREFIX - See Google!
• 21: UNTAG_FROM_BTABLE - Режим снятия тага в выходящем из порта фрейме
  • 0 - Сравниваются тег порта и тег фрейма:
    • Совпадают - фрейм посылается без тега.
    • НЕ совпадают - фрейм посылается с тегом фрейма!
  • 1 - Действие с тегом берется из VLAN таблицы для тега фрейма. Если бит порта в маске UntagList равен:
    • 0 - тег не снимается. Фрейм уходит тегированый.
    • 1 - тег снимается. Фрейм уходит нетегированый.

Жирным шрифтом выделены основные параметры, необходимые для настройки портов для реализации сетей VLAN.

• VID (VLAN_ID) задает принадлежность абонента на данном порту к той или иной VLAN сети.
• AFT и UNTAG_FROM_BTABLE необходимы для настройки одного из двух режимов работы порта VLAN:
  • ACCEPT порт - принимает и передает нетегированный трафик, но внутри коммутатора трафик маршрутизируется только с портами с таким же VLAN_ID, как у данного порта.
  • TRUNC порт - принимает и передает тегированый трафик, но только с теми тегами, которые разрешены для прохождения через данный порт.

Рассмотрим настройку коммутатора, когда он не разделяет общую сеть на подсети. Т.е. абоненты на всех портах находятся в одной VLAN сети. Из-за того, что VLAN_ID на всех портах одинаков, то коммутатор будет работать как будто никаких VLAN нет. Следовательно и настройка будет максимально простой, все порты настраиваются одинаково.

Поскольку коммутатор является VLAN-based, то какой-то общий VLAN_ID всем портам задать необходимо. Таким значением VLAN_ID по умолчанию является 1. (Cisco использует VLAN 1 как default VLAN, и management протоколы (STP, CDP, DTP, etc) используют VLAN 1.)

Рассмотрим этапы прохождения фрейма между двумя портами в настройках по умолчанию:

Пояснения:

1. Компьютер А с МАС адресом МАС_А посылает фрейм, допустим компьютеру В с МАС адресом МАС_В.
2. Фрейм от компьютера нетегированый, поэтому Port_1 при приеме фрейма присваивает ему свой VLAN_ID. Внутри коммутатора фрейм маршрутизируется с тегом VLAN_ID = 1.
3. Поиск по таблице МАС показывает, что МАС_А еще не известен коммутатору. Т.е. это первый пакет пришедший с данного порта, поэтому требуется обучение МАС таблицы.
4. Фрейм отправляется в порт, бит которого указан в регистрах классификатора CLASS_NPU_CTRL[7..0]/CLASS_NPU_CTRL1[11..0], это маска PUNT_PORT. Только один бит может быть установлен! Если хостом является РС, подключенный через PCI-Express, то для посылки в него фрейма используется Port16 и PUNT_PORT необходимо выставить в 0x10000.
5. Далее драйвер в Linux обработает запрос и добавит запись в таблицу МАС, где укажет на каком порте коммутатора находится адрес МАС_А и к какой сети VLAN он принадлежит.
6. В итоге, фрейм коммутатором никуда не пересылается. Он "тратится" на обучение таблицы МАС. Но хост при обучении может самостоятельно переслать фрейм по необходимым портам, тогда фрейм не потеряется.

Стоит отметить, что при попытке поменять PUNT_PORT на другое значение, ничего не меняется. Скорее всего 16-й порт задан по умолчанию, и в любом случае посылка фрейма на хост назначается на этот порт. Перенаправить фрейм на любой другой Ethernet порт можно настройкой блока TMU. Например, если в регистр TMU_PHY16_INQ_ADDR прописать (AXI_EGPI4_BASE_ADDR | AXI_GPI_INQ_PKTPTR) то все, что микросхема посылает в 16-й порт, будет уходить в 3-й порт (нумерация с 0). Абонент на 3-м порту получит фрейм на обучение с некоторым служебным заголовком. Но важно чтобы этот абонент был подключен к 1923КХ028 так-же и по SPI. Тогда он сможет обучить таблицу МАС через доступ по SPI. Для этого коммутатор должен работать в режиме MODE 2 (Slave SPI).

Пояснения:

1. Компьютер А не получил ответа от компьютера B, и через некоторое время снова посылает пакет. При приеме фрейму присваивается тег порта VLANID 1.
2. Классификатор коммутатора находит запись что MAC_A (Source MAC) находится в VLAN сети 1. Но не находит записей об MAC_B (Destination MAC). Поэтому он обращается в таблицу VLAN.
3. В таблице VLAN указано, что фреймы с тегом VLANID = 1 должны пересылаться в порты заданные маской ForwList = 0xFFFF. Т.е. это все порты ethernet коммутатора. Далее из таблицы извлекается действие из поля UnicastMiss, оно показывает что делать с Unicast фреймом, если для него не нашлось записи в таблице МАС. (Остальные поля таблицы VLAN и возможные действия описаны тут - VLAN Table.) По умолчанию все действия в таблице прописываются драйвером как ACT_FORWARD. Т.е. фрейм будет переслан на все порты в маске ForwList для VLAN_ID 1.
4. Фрейм пересылается на все порты, кроме того, откуда пришел данный фрейм. Тег снимается, потому что тег фрейма равен фрейму порта.
5. Теперь компьютер В получает фрейм от компьютера А и сможет послать ответ.

Но первый ответ от РС_В снова будет истрачен на обучение, т.к. MAC_B нет в таблице МАС коммутатора! Поэтому, если ПО хотса не сделает пересылку фрейма, то он пропадет. Короче, поведение будет точно такое-же как при обучении пакета от РС_А.

Когда все МАС адреса и порты известны, то общение между PC_A и PC_B идет напрямую:

Пояснения:

1. РС_В посылает фрейм, он при приеме тегируется VLAN_ID 1.
2. В МАС таблице есть записи для МАС адресов источника и назначения.
3. Оба абонента находятся в одной VLAN_ID 1, поэтому фрейм пересылается в Port0 для РС_А. Тег при выдаче снимается, т.к. тег фрейма равен фрейму порта.

Важно отметить, что при выдаче из порта, если тег фрейма не равен тегу порта, то фрейм уходит с тегом фрейма! Именно по этой причине настройка по умолчанию AFT (AcceptFrameType) выставлена в AnyTagged. Т.е. во всех рисунках выше, если бы входной фрейм был тегированый, то он так бы и был передан на остальные порты тегированым. Это важно, если порты коммутатора подключены не к компьютерам, а к TRUNK портам коммутаторов. Поскольку требуется переслать тегированный трафик так, как он есть. В итоге, VLAN_ID в таблицу МАС маршрутизации заносятся:

• из тега проходящего пакета, если пакет тегированый
• из VLAN_ID принимающего порта, если пакет НЕ тегированый

Но для того, чтобы коммутатор был прозрачным для VLAN тегированного трафика, необходимо либо при обучении МАС обновлять и таблицу VLAN, либо разрешить глобальную настройку пересылки тегированных фреймов в регистрах CLASS_GLOBAL_CFG и CLASS_GLOBAL_CFG1. Эти регистры содержат все необходимые поля, что есть в таблице VLAN, кроме самого поля VLAN_ID. Поскольку настройки этих регистров относится для VLAN_ID, для которых нет записей в таблице VLAN.

Пояснения:

• К Port0 и Port1 подключены Trunk порты соседних коммутаторов. В Port0 приходит тегированый пакет. Поскольку пакет уже тегированый, то VID порта к пакету не присваивается и в внутри коммутатора фрейм обрабатывается со своим VLAN_ID 100.
• Допустим что это уже второй пришедший фрейм, а обучение по первому фрейму прошло ранее. Тогда таблица МАС уже содержит запись для MAC_A, но записи для MAC_B пока еще нет - пересылка по МАС адресам не возможна. Поэтому происходит обращение к таблице VLAN, за поиском маски для пересылки фрейма по VLAN_ID.
• Но записи для VLAN_ID в таблице нет, поэтому идет обращение за действием над пакетом, которое задано по умолчанию в регистрах CLASS_GLOBAL_CFG и CLASS_GLOBAL_CFG1. Запись в регистрах, в поле ForwardList содержит список портов куда следует переслать фрейм.
• Пересланный фрейм уходит через порты в неизменном тегированном виде.

В расмотренных выше случаях, все порты коммутатора имели одинаковые настройки, т.е. находились в одной сети. Давайте теперь выделим два порта в отдельную сеть с помощью VLAN. Пусть это будут Port0 и Port1, идентификатор сети VLAN_ID зададим 100. Эти порты будут работать в режиме ACCESS, т.е. должны общаться со всеми другими портами, у который такой-же VLAN_ID 100. В итоге в свиче у нас получилось две сети:

1. сеть с VLAN_ID 100 на портах 0 и 1.
2. сеть с VLAN_ID по умолчанию 1 на всех остальных портах.

Допустим далее, что сеть у нас состоит не из одного свича, а из двух. И два абонента на втором свиче так-же должны быть в сети с VLAN_ID 100. Поэтому необходим TRUNK порт, который мог бы связать две сети в двух свичах между собой. В отличие от ACCESS порта, TRUNK порт пропускает сквозь себя покеты с любым VLAN_ID. Пусть TRUNK портами будут:

• PORT15 в Switch1
• PORT0 в Switch2

Необходимая настройка:

1. В таблицы VLAN свичей добавляем запись:
   • VID (VLAN_ID) = 100, для обоих свичей
   • Switch1.ForwList = 0x8003, маска портов входящих в сеть VLAN 100 и Trunk портов.
     • 0x8000 - Маска Trunk порта Port15. Сюда пересылаются пакеты для отправки в switch1, если МАС адрес фрейма назначения не находится в данном свиче.
     • 0x1, 0x2 - Маска Port0 и Port1, только между этими портами и Trunk портом могут проходить пакеты VLAN_ID 100.
   • Switch1.UntagList = 0x0003. Маска портов для которых принудительно снимать тег при посылке фреймов абонету. Для Trunk порта снимать тег не нужно, бит остается нулевым!
   • Switch2.ForwList = 0x8003
     • 0х0001 - Маска Trunk порта Port0
     • 0х8002 - маска портов входящих в сеть VLAN 100
   • Switch2.UntagList = 0x8002. Маска портов входящих в сеть VLAN 100 (без TRUNK портов)
2. Настройка Access портов на обоих коммутаторах: Switch1 Ports [0,1], Switch2 Ports [1,15]
   • VID = 100, теперь абонент на порте входит в состав подсети VLAN 100
   • AFT = UntaggedOnly. Access порты обмениваются только нетегированым трафиком. Если придет тегированый фрейм, то он будет отброшен.
   • UntagFromBTable (UNT_TBL) - принудительное снятие тега в исходящем фрейме согласно флагу порта в маске UntagList в VLAN таблице (для VLAN 100). Как уже было описано выше, по умолчанию при UNT_TBL = 0, в исходящем фрейме будет удален тег только если тег в фрейме совпадает с тегом порта. И если вдруг случится что на выход из порта придет фрейм с тегом, отличным от тега порта, то такой фрейм выйдет тегированным. Чего на Access порте быть не должно! Флаг UNT_TBL = 1 и маска в VLAN_Table.UntagList гарантируют что тег в исходящем фрейме будет удален в любом случае.
3. В VLAN таблицах коммутаторов для дефолтного VLAN_ID 1 необходимо исключить из маски ForwardList биты портов, которые мы выделили в отдельную сеть VLAN_ID 100. Иначе фреймы с данных портов будут рассылаться на порты VLAN 100, причем тегированные, т.к. тег фрейма 1 не снимется выходя из порта 100, а UntagList для VLAN_ID 1 у нас настроен в 0. (см предыдущую главу)

Итак, рассмотрим ситуацию когда абонент нашей новой сети посылает широковещательный фрейм:

Пояснения:

• Switch1:
  • PC_A посылает широковещательный фрейм. Коммутаторы Switch1 и Switch2 уже поделили своих абонентов на подсети. Поэтому данный фрейм должен дойти всем абонентам коммутаторов, на портах которых VLAN_ID равен 100. Т.к. именно этот VLAN_ID присваивается в теге, когда нетегированый пакет от РС_А принимается в PORT0. Если бы фрейм был послан тегированным, то он был бы отброшен портом, т.к. поле AFT (AcceptFrameType) порта выставлено в UntaggedOnly.
  • Допусти, что таблица МАС у нас уже обучена - МАС адрес источника есть в таблице. Но пакет широковещательный, а такого адреса назначения в таблице МАС быть не может. Поэтому обработка пакета обращается в таблицу VLAN. В этой таблице для VLAN 100 в поле ForwardList записано на какие порты необходимо переслать пакет.
  • Пакет отправляется на порты согласно маске ForwardList, за исключением порта откуда фрейм пришел.
  • На картинке видно, что PORT1 коммутатора Switch1 находится в той же сети VLAN 100, поэтому фрейм уходит абоненту PC_C. Пакет выходит нетегированным, потому что в порте включен UntagFromBTable (UNT_TBL), а в поле UntugList для VLAN 100 бит порта выставлен в "1" (0x003).
  • PORT15 тоже указан в маске ForwardList, поэтому пакет отправляется и сюда тоже. Настроки PORT15 остались по умолчанию, поэтому фрейм выходит со своим тегом VLAN_ID 100.
• Switch2:
  • Фрейм из Switch1 приходит на порт Switch2.PORT0. Настройки данного порта так-же остались по умолчанию. Порт принимает пакет, видит что тот уже тегированый, поэтому свой тег он пакету не назначает, а оставляет исходный. Далее пакет обрабатывается с тем же тегом 100, который был ему присвоен изначально при входе в Switch1 от абонента РС_А.
  • Допустим что МАС таблица в Switch2 уже настроена и запись для МАС_А уже есть. Далее всё как в Switch1 - пакет широковещательны, значит адреса назначения в таблице нет, поэтому пакет рассылается согласно ForwardList из таблицы VLAN.
  • В таблице VLAN мы прописывали, что к подсети VLAN 100 относятся порты 1 и 15. Поэтому фрейм посылается к абонентам на этих портах. Фрейм выходит нетегированый, потому что в портах включен режим UntagFromBTable (UNT_TBL) и оба порта указаны в маске UntagMask таблицы VLAN.

Таким образом, настройки коммутаторов позволяют разделить абонентов одной сети на подсети с помощью тегов VLAN. В общем и целом, поскольку абоненты не получают тегированый трафик, то они даже не знают что разделены на какие-то подсети. Точнее сказать, абоненты не знают, что есть кто-то еще за пределами их подсети. Разделение позволяет локализовать широковещательный трафик и не позволяет ему "расползаться" по всей сети.

Согласно ссылки на производителя MOXA в начале статьи, TRUNK порты могут обмениваться и нетегированым трафиком. Представим, что в рассмотренном только что примере, абонент на PORT4, который остался в дефолтной подсети 1, посылает свой фрейм. Посмотрим как это происходит:

Пояснения:

• Switch1
  • PC_X посылает широковещательный нетегированый фрейм. PORT4, принимая фрейм, тегирует его своим VLAN_ID = 1.
  • Пусть таблица МАС уже обучена, но пакет широковещательный, поэтому обработка проверяет таблицу VLAN для VLAN_ID = 1.
  • Запись ForwardList = 0х8010 говорит, что фрейм необходимо переслать на PORT4 и PORT15. (Маска 0х8010 была прописана сюда чтобы не рисовать много стрелок в Switch1, а лишь показать то, как фрейм доходит до Switch2 через Trunk порт. При другой маске, пакеты пересылается на все порты данной маски.) PORT4 - это порт откуда пришел фрейм, поэтому фрейм туда не посылается, а посылается лишь в PORT15.
  • PORT15 посылает фрейм, но при этом снимает тег, потому что тег фрейма совпал с тегом порта.
• Switch2
  • В коммутаторе Switch2 все отрабатывает точно так-же как в Switch1. Здесь только маска ForwardList портов для VLAN 1 была прописана 0х0061. Поэтому фрейм пересылается в PORT5 и PORT6.

Если есть необходимость организовать только тегированый трафик через TRUNK порты, то это можно реализовать следующей настройкой (выделено красным):

Пояснения:

• Для того чтобы трафик принимался только тегированый, в настройках TRUNK портов выставляем AFT(AcceptFrameType) в TaggedOnly.
• Чтобы порт не сверял свой тег с тегом фрейма и не манипулировал выходным тегом необходимо включить режим UntagFromBTable(UNT_TBL). То при этом в маске UntagList для VLAN_ID фрейма надо уставить 0. Тогда фрейм выходя из порта не потеряет свой тег, каким бы этот тег ни был.

Вот и все отличия от предыдущего режима с нетегировнным трафиком между TRUNK портами.

Признаться, у меня пока не сложилось ясного представления о преимуществах PVLAN и как их использовать. На мой взгляд, PVLAN позволяет выделить отдельный порт в коммутаторе, который будет выступать как провайдер или выделенная точка доступа к внешнему роутеру/серверу для остальных портов коммутатора разбитых на группы. Т.е. абоненты этих групп портов взаимодействуют с внешним миром через выделенный порт - точку доступа.

В общем случае, таких выделенных портов может быть несколько, чтобы их разделить использутся VLAN теги, которые называются Primary. В качестве примера можно представить что один порт коммутатора подключен к провайдеру интернета и трафик через этот порт тегируется тегом 10, а второй порт подключен к другому провайдеру и его трафик тегируется тегом 20. Остальные порты нужно распределить по провайдерам. Получаем, что Primary VLAN поделил порты коммутатора на первичные подсети.

Как мы уже знаем, трафик в отдельных VLAN не смешивается, поэтому за тарификацию провайдеры могут не беспокоится. :)

Выделенный порт, который коммутирует трафик от провайдера на остальные порты в своей Primary подсети, называется Promiscuous. Promiscuous переводят как неразборчивый или смешанный. Это связано с тем, что Promiscuous порт может обмениваться трафиком с любым из портов в своей подсети, не зависимо от режима работы этих портов.

Далее, порты каждого их первичных VLAN можно разбить на отдельные подсети, ограничив их взаимодействие друг с другом. Такие подсети организуются так-же за счет присвоения VLAN тегов портам, и называются они Secondary. Получаем как-бы, Secondary VLAN сети внутри Primary VLAN сети:

Для упрощения, на картинке показано только разбиение Primary VLAN 10. Primary VLAN 20 разбивается аналогично любым способом.

Порты входящие в secondary сети могут быть настроены в трех режимах :

• Isolated - Порт может обмениваться пакетами только с Promiscuous портами. Он не может обмениваться с другими Isolated портами, даже если он находится с ними в одной под сети!
• Community - Эти порты могут обмениваться пакетам с Promiscuous портами и с портами своей группы.
• Uplink - это рromiscuous trunk порт необходимый для объединения коммутаторов друг с другом для общей коммутации. Этот порт может обмениваться фреймами со всеми остальными портами. Данный порт будет представлен на картинках ниже

Стоит отметить, что в спецификации достаточно хорошо изложена глава 13 - "Приватный VLAN". Рассказано зачем это надо и как настроить, поэтому перейдем сразу к поясняющим прохождение трафика картинкам.

Необходимо подчеркнуть, что каждый порт, входящий в Secondary VLAN иденти идентифицируется двумя VLAN_ID:

1. Primary VLAN_ID - это VID Primary сети к которой принадлежит Secondary сеть. Данный параметр сохраняется в управляющем ПО и используется при обучении таблиц маршрутизации.
2. Secondary VLAN_ID - это VID Secondary сети, к которой принадлежит порт. Это значение прописывается в регистры настройки порта в поле VID. И так-же используется в ПО при обучении.

Согласно спецификации, когда новый фрейм поступает на обучение, то ПО записывает в таблицу маршрутизации следующие записи:

Если порт Isolated:

Secondary[port] - это VID порта принявшего пакет. Для изолированного порта запрещаются пересылки в порт фреймов с VID порта, поэтому прописано действие - Отбросить (ACT_DISCARD). Это нужно на тот случай, если соседний абонент, с таким же VID, каким-то образом узнал МАС адрес нашего порта и послал фрейм с нашим МАС адресом. По умочанию, МАС таблица по совпадению МАС адреса назначения и VID послала бы фрейм в изолированый порт, чего допустить нельзя. Поэтому такие фреймы отбрасываются.

Вторая запись, это разрешение пересылать в изолированный порт фреймы от провайдера.

Если порт Community:

Здесь в отличие от изолированного порта разрешается перенаправлять абоненту фреймы от соседей с таким же VLAN_ID.

Если порт Promiscuous:

Тут, первая запись разрешает перенаправлять провайдеру фреймы от соседей с таким же Primary VLAN_ID. Которые могут быть в соседнем коммутаторе, см картинки ниже. А остальные записи разрешают перенаправление абоненту фреймов от всех Secondary подсетей данного Primary VLAN. n - это количество Secondary VLAN в Primary VLAN.

Для прохождения широковещательного трафика необходимо прописать маски ForwardList и UntagList в таблицу VLAN. Маски UntagList нужны чтобы теги, присваиваемые на входе и с которым фрейм коммутируется внутри свича, снимались при выходе фрейма в порт назначения.

• Isolated VID: ForwardList = UntagList = только порты Promiscuous
• Community VID: ForwardList = UntagList = порты Promiscuous | порты группы
• Primary VID (Promiscuous): ForwardList = UntagList = все порты

Рассмотрим широковещательный трафик, исходящий из изолированного порта. Предположим что таблицы у нас уже обучены ранее. Т.е. рассмотрим почему и как фрейм проходит коммутатор:

Пояснения по посылке запроса:

• Абонент РС_А посылает широковещательный фрейм, например ARP запрос. Фрейм тегируется Secondary VLAN_ID порта, т.е. 100.
• Т.к. адрес назначения широковещательный, то фрейм пересылается по VLAN таблице.
• VLAN таблица для Secondary сети 100 содержит маску всех Promiscuous портов:
  • Port14 - это порт PromiscuousTrunk. Фрейм уходит к Server1 без тега, т.к. включен UNT_TBL и порт указан в маске UntagList.
  • Port15 - Это Uplink PromiscuousTrunk, который пересылает фрейм в неизменном виде в соседний коммутатор Switch2 на такой-же Uplink порт.
    • Switch2.Port0 принимает фрейм и т.к. он уже тегированый то, фрейм обрабатывается с тегом фрейма.
    • Фрейм широковещательный, поэтому рассылается по таблице VLAN на все Promiscuous порты коммутатора Switch2. Т.е. на Port15.
    • Switch2.Port15 - это порт PromiscuousTrunk. Фрейм уходит к Server2 без тега, т.к. включен UNT_TBL и порт указан в маске UntagList.

Пояснения по получению ответа:

• Ответ от Server1:
  • Сервер отвечает на МАС_А фреймом со своим МАС_S.
  • Порт 14 принимает фрейм и тегирует его Primary тегом 10.
  • Адреса источника и назначения есть в таблице маршрутизации. Для VLAN 10 действие - Forward, поэтому фрейм пересылается сразу на Port0.
  • Фрейм уходит к PC_A без тега, т.к. включен UNT_TBL и порт указан в маске UntagList.
• Ответ от Server2:
  • Здесь путь фрейма идет аналогично по МАС таблицам коммутаторов. Между коммутаторами фрейм идет в тегированом виде.

Путь ответа явялется уже Unicast потому что идет по двум известным адресам. Если смотреть Broadcast от севера, то он пройдет во все порты, потому что в ForwardList порта Promiscuous как раз указаны все порты для Primary VLAN_ID.

Для наглядности разрисуем Unicast трафик от РС_А. Здесь все стандартно идет через таблицы МАС. На картинке лишь уточнено какая запись в МАС таблице за что отвечает.