Основы компьютерных сетей. Тема №6. Понятие VLAN, Trunk и протоколы VTP и DTP
Мы пока не будем затрагивать маршрутизаторы и разные подсети. Допустим все узлы находятся в одной подсети.
Сразу приведу список IP-адресов:
- PC1 – 192.168.1.2/24
- PC2 – 192.168.1.3/24
- PC3 – 192.168.1.4/24
- PC4 – 192.168.1.5/24
- PC5 – 192.168.1.6/24
- PC6 – 192.168.1.7/24
Кто хочет увидеть это в виде анимации, открывайте спойлер (там показан ping от PC1 до PC5).
Красиво да? Мы в прошлых статьях уже не раз говорили о работе протокола ARP, но это было еще в прошлом году, поэтому вкратце объясню. Так как PC1 не знает MAC-адрес (или адрес канального уровня) PC2, то он отправляет в разведку ARP, чтобы тот ему сообщил. Он приходит на коммутатор, откуда ретранслируется на все активные порты, то есть к PC2 и на центральный коммутатор. Из центрального коммутатора вылетит на соседние коммутаторы и так далее, пока не дойдет до всех. Вот такой не маленький трафик вызвало одно ARP-сообщение. Его получили все участники сети. Большой и не нужный трафик — это первая проблема. Вторая проблема — это безопасность. Думаю, заметили, что сообщение дошло даже до бухгалтерии, компьютеры которой вообще не участвовали в этом. Любой злоумышленник, подключившись к любому из коммутаторов, будет иметь доступ ко всей сети. В принципе сети раньше так и работали. Компьютеры находились в одной канальной среде и разделялись только при помощи маршрутизаторов. Но время шло и нужно было решать эту проблему на канальном уровне. Cisco, как пионер, придумала свой протокол, который тегировал кадры и определял принадлежность к определенной канальной среде. Назывался он ISL (Inter-Switch Link). Идея эта понравилась всем и IEEE решили разработать аналогичный открытый стандарт. Стандарт получил название 802.1q. Получил он огромное распространение и Cisco решила тоже перейти на него.
И вот как раз технология VLAN основывается на работе протокола 802.1q. Давайте уже начнем говорить про нее.
В 3-ей части я показал, как выглядит ethernet-кадр. Посмотрите на него и освежите в памяти. Вот так выглядит не тегированный кадр.
Теперь взглянем на тегированный.
Как видим, отличие в том, что появляется некий Тег. Это то, что нам и интересно. Копнем глубже. Состоит он из 4-х частей.
1) TPID (англ. Tag Protocol ID) или Идентификатор тегированного протокола — состоит из 2-х байт и для VLAN всегда равен 0x8100.
2) PCP (англ. Priority Code Point) или значение приоритета — состоит из 3-х бит. Используется для приоритезации трафика. Крутые и бородатые сисадмины знают, как правильно им управлять и оперирует им, когда в сети гуляет разный трафик (голос, видео, данные и т.д.)
3) CFI (англ. Canonical Format Indicator) или индикатор каноничного формата — простое поле, состоящее из одного бита. Если стоит 0, то это стандартный формат MAC-адреса.
4) VID (англ. VLAN ID) или идентификатор VLAN — состоит из 12 бит и показывает, в каком VLAN находится кадр.
Хочу заострить внимание на том, что тегирование кадров осуществляется между сетевыми устройствами (коммутаторы, маршрутизаторы и т.д.), а между конечным узлом (компьютер, ноутбук) и сетевым устройством кадры не тегируются. Поэтому порт сетевого устройства может находиться в 2-х состояниях: access или trunk.
- Access port или порт доступа — порт, находящийся в определенном VLAN и передающий не тегированные кадры. Как правило, это порт, смотрящий на пользовательское устройство.
- Trunk port или магистральный порт — порт, передающий тегированный трафик. Как правило, этот порт поднимается между сетевыми устройствами.
Набираю команду show vlan.
Выстраиваются несколько таблиц. Нам по сути важна только самая первая. Теперь покажу как ее читать.
1 столбец — это номер VLAN. Здесь изначально присутствует номер 1 — это стандартный VLAN, который изначально есть на каждом коммутаторе. Он выполняет еще одну функцию, о которой чуть ниже напишу. Также присутствуют зарезервированные с 1002-1005. Это для других канальных сред, которые вряд ли сейчас используются. Удалить их тоже нельзя.
При удалении Cisco выводит сообщение, что этот VLAN удалить нельзя. Поэтому живем и эти 4 VLANа не трогаем.
2 столбец — это имя VLAN. При создании VLAN, вы можете на свое усмотрение придумывать им осмысленные имена, чтобы потом их идентифицировать. Тут уже есть default, fddi-default, token-ring-default, fddinet-default, trnet-default.
3 столбец — статус. Здесь показывается в каком состоянии находится VLAN. На данный момент VLAN 1 или default в состоянии active, а 4 следующих act/unsup (хоть и активные, но не поддерживаются).
4 столбец — порты. Здесь показано к каким VLAN-ам принадлежат порты. Сейчас, когда мы еще ничего не трогали, они находятся в default.
Приступаем к настройке коммутаторов. Правилом хорошего тона будет дать коммутаторам осмысленные имена. Чем и займемся. Привожу команду.
Остальные настраиваются аналогично, поэтому покажу обновленную схему топологии.
Начнем настройку с коммутатора SW1. Для начала создадим VLAN на коммутаторе.
VLAN создан. Теперь переходим к портам. Интерфейс FastEthernet0/1 смотрит на PC1, а FastEthernet0/2 на PC2. Как говорилось ранее, кадры между ними должны передаваться не тегированными, поэтому переведем их в состояние Access.
Так как оба порта закрепляются под одинаковым VLAN-ом, то их еще можно было настроить группой.
Настроили access порты. Теперь настроим trunk между SW1 и CentrSW.
Сразу видим, что порт перенастроился. В принципе для работы этого достаточно. Но с точки зрения безопасности разрешать для передачи нужно только те VLAN, которые действительно нужны. Приступим.
Без этой команды передаваться будут все имеющиеся VLAN. Посмотрим, как изменилась таблица командой show vlan.
Появился 2-ой VLAN с именем Dir-ya и видим принадлежащие ему порты fa0/1 и fa0/2.
Чтобы вывести только верхнюю таблицу, можно воспользоваться командой show vlan brief.
Можно еще укоротить вывод, если указать определенный ID VLANа.
Вся информациях о VLAN хранится в flash памяти в файле vlan.dat.
Как вы заметили, ни в одной из команд, нет информации о trunk. Ее можно посмотреть другой командой show interfaces trunk.
Здесь есть информация и о trunk портах, и о том какие VLAN они передают. Еще тут есть столбец Native vlan. Это как раз тот трафик, который не должен тегироваться. Если на коммутатор приходит не тегированный кадр, то он автоматически причисляется к Native Vlan (по умолчанию и в нашем случае это VLAN 1). Native VLAN можно, а многие говорят, что нужно менять в целях безопасности. Для этого в режиме настройки транкового порта нужно применить команду — switchport trunk native vlan X, где X — номер присваиваемого VLAN. В этой топологии мы менять не будем, но знать, как это делать полезно.
Осталось настроить остальные устройства.
CentrSW:
Центральный коммутатор является связующим звеном, а значит он должен знать обо всех VLAN-ах. Поэтому сначала создаем их, а потом переводим все интерфейсы в транковый режим.
Не забываем сохранять конфиг. Команда copy running-config startup-config.
Обратите внимание на то, что мы подняли и настроили VLAN, но адресацию узлов оставили такой же. То есть, фактически все узлы в одной подсети, но разделены VLAN-ами. Так делать нельзя. Каждому VLAN надо выделять отдельную подсеть. Я это сделал исключительно в учебных целях. Если бы каждый отдел сидел в своей подсети, то они бы априори были ограничены, так как коммутатор не умеет маршрутизировать трафик из одной подсети в другую (плюс это уже ограничение на сетевом уровне). А нам нужно ограничить отделы на канальном уровне.
Снова отправляю ping с PC1 к PC3.
Идет в ход ARP, который нам и нужен сейчас. Откроем его.
Пока что ничего нового. ARP инкапсулирован в ethernet.
Кадр прилетает на коммутатор и тегируется. Теперь там не обычный ethernet, а 802.1q. Добавились поля, о которых я писал ранее. Это TPID, который равен 8100 и показывающий, что это 802.1q. И TCI, которое объединяет 3 поля PCP, CFI и VID. Число, которое в этом поле — это номер VLAN. Двигаемся дальше.
После тега он отправляет кадр на PC2 (т.к. он в том же VLAN) и на центральный коммутатор по транковому порту.
Так как жестко не было прописано какие типы VLAN пропускать по каким портам, то он отправит на оба коммутатора. И вот здесь коммутаторы, увидев номер VLAN, понимают, что устройств с таким VLAN-ом у них нет и смело его отбрасывают.
PC1 ожидает ответ, который так и не приходит. Можно под спойлером посмотреть в виде анимации.
Теперь следующая ситуация. В состав дирекции нанимают еще одного человека, но в кабинете дирекции нет места и на время просят разместить человека в отделе бухгалтерии. Решаем эту проблему.
Подключили компьютер к порту FastEthernet 0/3 коммутатора и присвою IP-адрес 192.168.1.8/24.
Теперь настрою коммутатор SW2. Так как компьютер должен находиться во 2-ом VLAN, о котором коммутатор не знает, то создам его на коммутаторе.
Дальше настраиваем порт FastEthernet 0/3, который смотрит на PC7.
И последнее — настроить транковый порт.
Чтобы кадры ходили красиво, подкорректирую центральный коммутатор CentrSW.
Время проверки. Отправляю ping с PC1 на PC7.
И вот он приходит на SW2. Открываем и видим, что он еще тегированный. Но следующим узлом стоит компьютер и тег надо снимать. Нажимаем на «Outbound PDU Details», чтобы посмотреть в каком виде кадр вылетит из коммутатора.
И действительно. Коммутатор отправит кадр в «чистом» виде, то есть без тегов.
Доходит ARP до PC7. Открываем его и убеждаемся, что кадр не тегированный PC7 узнал себя и отправляет ответ.
Открываем кадр на коммутаторе и видим, что на отправку он уйдет тегированным. Дальше кадр будет путешествовать тем же путем, что и пришел.
ARP доходит до PC1, о чем свидетельствует галочка на конверте. Теперь ему известен MAC-адрес и он пускает в ход ICMP.
Открываем пакет на коммутаторе и наблюдаем такую же картину. На канальном уровне кадр тегируется коммутатором. Так будет с каждым сообщением.
Видим, что пакет успешно доходит до PC7. Обратный путь я показывать не буду, так как он аналогичен. Если кому интересно, можно весь путь увидеть на анимации под спойлером ниже. А если охота самому поковырять эту топологию, прикладываю ссылку на лабораторку.
Вот в принципе самое популярное применение VLAN-ов. Независимо от физического расположения, можно логически объединять узлы в группы, там самым изолируя их от других. Очень удобно, когда сотрудники физически работают в разных местах, но должны быть объединены. И конечно с точки зрения безопасности VLAN не заменимы. Главное, чтобы к сетевым устройствам имели доступ ограниченный круг лиц, но это уже отдельная тема.
Добились ограничения на канальном уровне. Трафик теперь не гуляет где попало, а ходит строго по назначению. Но теперь встает вопрос в том, что отделам между собой нужно общаться. А так как они в разных канальных средах, то в дело вступает маршрутизация. Но перед началом, приведем топологию в порядок. Самое первое к чему приложим руку — это адресация узлов. Повторюсь, что каждый отдел должен находиться в своей подсети. Итого получаем:
- Дирекция — 192.168.1.0/24
- Бухгалтерия — 192.168.2.0/24
- Отдел кадров — 192.168.3.0/24
Раз подсети определены, то сразу адресуем узлы.
- PC1:
IP: 192.168.1.2
Маска: 255.255.255.0 или /24
Шлюз: 192.168.1.1 - PC2:
IP: 192.168.1.3
Маска: 255.255.255.0 или /24
Шлюз: 192.168.1.1 - PC3:
IP: 192.168.2.2
Маска: 255.255.255.0 или /24
Шлюз: 192.168.2.1 - PC4:
IP: 192.168.2.3
Маска: 255.255.255.0 или /24
Шлюз: 192.168.2.1 - PC5:
IP: 192.168.3.2
Маска: 255.255.255.0 или /24
Шлюз: 192.168.3.1 - PC6:
IP: 192.168.3.3
Маска: 255.255.255.0 или /24
Шлюз: 192.168.3.1 - PC7:
IP: 192.168.1.4
Маска: 255.255.255.0 или /24
Шлюз: 192.168.1.1
Осталось настроить маршрутизатор, и я открываю его CLI. По традиции дам осмысленное имя.
Далее переходим к настройке интерфейсов.
Теперь внимание! Мы включили интерфейс, но не повесили на него IP-адрес. Дело в том, что от физического интерфейса (fastethernet 0/0) нужен только линк или канал. Роль шлюзов будут выполнять виртуальные интерфейсы или сабинтерфейсы (англ. subinterface). На данный момент 3 типа VLAN. Значит и сабинтерфейсов будет 3. Приступаем к настройке.
Маршрутизатор настроен. Переходим к центральному коммутатору и настроим на нем транковый порт, чтобы он пропускал тегированные кадры на маршрутизатор.
Конфигурация закончена и переходим к практике. Отправляю ping с PC1 на PC6 (то есть на 192.168.3.3).
PC1 понятия не имеет, кто такой PC6 или 192.168.3.3, но знает, что они находятся в разных подсетях (как он это понимает описано в предыдущей статье). Поэтому он отправит сообщение через основной шлюз, адрес которого указан в его настройках. И хоть PC1 знает IP-адрес основного шлюза, для полного счастья не хватает MAC-адреса. И он пускает в ход ARP.
Обратите внимание. Как только кадр прибывает на CentrSW, коммутатор не рассылает его кому попало. Он рассылает только на те порты, где разрешен пропуск 2-го VLAN. То есть на маршрутизатор и на SW2 (там есть пользователь, сидящий во 2-ом VLAN).
Маршрутизатор узнает себя и отправляет ответ (показан стрелочкой). И обратите внимание на нижний кадр. Когда SW2 получил ARP от центрального коммутатора, он аналогично не стал рассылать его на все компьютеры, а отправил только PC7, который сидит во 2-ом VLAN. Но PC7 его отбрасывает, так как он не для него. Смотрим дальше.
ARP дошел до PC1. Теперь ему все известно и можно отправлять ICMP. Еще раз обращу внимание на то, что в качестве MAC-адреса назначения (канальный уровень), будет адрес маршрутизатора, а в качестве IP-адреса назначения (сетевой уровень), адрес PC6.
Доходит ICMP до маршрутизатора. Он смотрит в свою таблицу и понимает, что не знает никого под адресом 192.168.3.3. Отбрасывает прибывший ICMP и пускает разведать ARP.
PC6 узнает себя и отправляет ответ.
Доходит до маршрутизатора ответ и он добавляет запись в своей таблице. Посмотреть таблицу ARP можно командой show arp.
Двигаемся дальше. PC1 недоволен, что ему никто не отвечает и отправляет следующее ICMP-сообщение.
Первый пакет затерялся (в результате работы ARP), а второй дошел без проблем.
Кому интересно увидеть в анимации, добро пожаловать под спойлер.
Итак. Мы добились того, что если узлы находятся в одной подсети и в одном VLAN, то ходить они будут напрямую через коммутаторы. В случае, когда нужно передать сообщение в другую подсеть и VLAN, то передавать будут через роутер Gateway, который осуществляет «межвлановую» маршрутизацию. Данная топология получила название «router on a stick» или «роутер на палочке». Как вы поняли она очень удобна. Мы создали 3 виртуальных интерфейса и по одному проводу гоняли разные тегированные кадры. Без использования сабинтерфейсов и VLAN-ов, пришлось бы для каждой подсети задействовать отдельный физический интерфейс, что совсем не выгодно.
Кстати очень хорошо этот вопрос разобран в этом видео (видео идет около 3-х часов, поэтому ссылка с привязкой именно к тому моменту времени). Если после прочтения и просмотра видео захочется добить все собственными руками, прикладываю ссылку на скачивание.
Разобрались с VLAN-ами и переходим к одному из протоколов, работающего с ним.
DTP (англ. Dynamic Trunking Protocol) или на русском динамический транковый протокол — проприетарный протокол компании Cisco, служащий для реализации trunk режима между коммутаторами. Хотя в зависимости от состояния, они могут согласоваться и в режим access.
В DTP есть 4 режима: Dynamic auto, Dynamic desirable, Trunk, Access. Рассмотрим как они согласуются.
| Режимы | Dynamic auto | Dynamic desirable | Trunk | Access |
|---|---|---|---|---|
| Dynamic auto | Access | Trunk | Trunk | Access |
| Dynamic desirable | Trunk | Trunk | Trunk | Access |
| Trunk | Trunk | Trunk | Trunk | Отсутствие соединения |
| Access | Access | Access | Отсутствие соединения | Access |
То есть левая колонка это 1-ое устройство, а верхняя строка 2-ое устройство. По-умолчанию коммутаторы находятся в режиме «dynamic auto». Если посмотреть таблицу сопоставления, то два коммутатора в режиме «dynamic auto» согласуются в режим «access». Давайте это и проверим. Создаю я новую лабораторную работу и добавлю 2 коммутатора.
Соединять их пока не буду. Мне надо убедиться, что оба коммутатора в режиме «dynamic auto». Проверять буду командой show interfaces switchport.
Результат этой команды очень большой, поэтому я его обрезал и выделил интересующие пункты. Начнем с Administrative Mode. Эта строка показывает, в каком из 4-режимов работает данный порт на коммутаторе. Убеждаемся, что на обоих коммутаторах порты в режиме «Dynamic auto». А строка Operational Mode показывает, в каком режиме работы они согласовали работу. Мы пока их не соединяли, поэтому они в состоянии «down».
Сразу дам вам хороший совет. При тестировании какого либо протокола, пользуйтесь фильтрами. Отключайте показ работы всех ненужных вам протоколов.
Перевожу CPT в режим simulation и отфильтрую все протоколы, кроме DTP.
Думаю здесь все понятно. Соединяю коммутаторы кабелем и, при поднятии линков, один из коммутаторов генерирует DTP-сообщение.
Открываю и вижу, что это DTP инкапсулированный в Ethernet-кадр. Отправляет он его на мультикастовый адрес «0100.0ccc.cccc», который относится к протоколам DTP, VTP, CDP.
И обращу внимание на 2 поля в заголовке DTP.
1) DTP Type — сюда отправляющий вставляет предложение. То есть в какой режим он хочет согласоваться. В нашем случае он предлагает согласовать «access».
2) Neighbor MAC-address — в это поле он записывает MAC-адрес своего порта.
Отправляет он и ждет реакции от соседа.
Доходит до SW1 сообщение и он генерирует ответный. Где также согласует режим «access», вставляет свой MAC-адрес и отправляет в путь до SW2.
Успешно доходит DTP. По идее они должны были согласоваться в режиме «access». Проверю.
Как и предполагалось, согласовались они в режим «access».
Кто то говорит, что технология удобная и пользуется ею. Но я крайне не рекомендую использовать этот протокол в своей сети. Рекомендую это не только я, и сейчас объясню почему. Смысл в том, что этот протокол открывает большую дыру в безопасности. Я открою лабораторку, в которой разбиралась работа «Router on a stick» и добавлю туда еще один коммутатор.
Теперь зайду в настройки нового коммутатора и жестко пропишу на порту работу в режиме trunk.
Соединяю их и смотрю, как они согласовались.
Все верно. Режимы «dynamic auto» и «trunk» согласуются в режим trunk. Теперь ждем, когда кто- то начнет проявлять активность. Допустим PC1 решил кому то отправить сообщение. Формирует ARP и выпускает в сеть.
Пропустим его путь до того момента, когда он попадет на SW2.
И вот самое интересное.
Он отправляет его на вновь подключенный коммутатор. Объясняю, что произошло. Как только мы согласовали с ним trunk, он начинает отправлять ему все пришедшие кадры. Хоть на схеме и показано, что коммутатор отбрасывает кадры, это ничего не значит. К коммутатору или вместо коммутатора можно подключить любое перехватывающее устройство (sniffer) и спокойно просматривать, что творится в сети. Вроде перехватил он безобидный ARP. Но если взглянуть глубже, то можно увидеть, что уже известен MAC-адрес «0000.0C1C.05DD» и IP-адрес «192.168.1.2». То есть PC1 не думая выдал себя. Теперь злоумышленник знает о таком компьютере. Вдобавок он знает, что он сидит во 2-ом VLAN. Дальше он может натворить многого. Самое банальное — это подменить свой MAC-адрес, IP-адрес, согласоваться быстро в Access и и выдавать себя за PC1. Но самое интересное. Ведь сразу можно этого не понять. Обычно, когда мы прописываем режим работы порта, он сразу отображается в конфигурации. Ввожу show running-config .
Но здесь настройки порта пустые. Ввожу show interfaces switchport и проматываю до fa0/4.
А вот здесь видим, что согласован trunk. Не всегда show running-config дает исчерпывающую информацию. Поэтому запоминайте и другие команды.
Думаю понятно почему нельзя доверять этому протоколу. Он вроде облегчает жизнь, но в то же время может создать огромную проблему. Поэтому полагайтесь на ручной метод. При настройке сразу же обозначьте себе какие порты будут работать в режиме trunk, а какие в access. И самое главное — всегда отключайте согласование. Чтобы коммутаторы не пытались ни с кем согласоваться. Делается это командой «switchport nonegotiate».
Переходим к следующему протоколу.
VTP (англ. VLAN Trunking Protocol) — проприетарный протокол компании Cisco, служащий для обмена информацией о VLAN-ах.
Представьте ситуацию, что у вас 40 коммутаторов и 70 VLAN-ов. По хорошему нужно вручную на каждом коммутаторе их создать и прописать на каких trunk-ых портах разрешать передачу. Дело это муторное и долгое. Поэтому эту задачу может взвалить на себя VTP. Вы создаете VLAN на одном коммутаторе, а все остальные синхронизируются с его базой. Взгляните на следующую топологию.
Здесь присутствуют 4 коммутатора. Один из них является VTP-сервером, а 3 остальных клиентами. Те VLAN, которые будут созданы на сервере, автоматически синхронизируются на клиентах. Объясню как работает VTP и что он умеет.
Итак. VTP может создавать, изменять и удалять VLAN. Каждое такое действие влечет к тому, что увеличивается номер ревизии (каждое действие увеличивает номер на +1). После он рассылает объявления, где указан номер ревизии. Клиенты, получившие это объявление, сравнивают свой номер ревизии с пришедшим. И если пришедший номер выше, они синхронизируют свою базу с ней. В противном случае объявление игнорируется.
Но это еще не все. У VTP есть роли. По-умолчанию все коммутаторы работают в роли сервера. Расскажу про них.
- VTP Server. Умеет все. То есть создает, изменяет, удаляет VLAN. Если получает объявление, в которых ревизия старше его, то синхронизируется. Постоянно рассылает объявления и ретранслирует от соседей.
- VTP Client — Эта роль уже ограничена. Создавать, изменять и удалять VLAN нельзя. Все VLAN получает и синхронизирует от сервера. Периодически сообщает соседям о своей базе VLAN-ов.
- VTP Transparent — эта такая независимая роль. Может создавать, изменять и удалять VLAN только в своей базе. Никому ничего не навязывает и ни от кого не принимает. Если получает какое то объявление, передает дальше, но со своей базой не синхронизирует. Если в предыдущих ролях, при каждом изменении увеличивался номер ревизии, то в этом режиме номер ревизии всегда равен 0.
Начитались теории и переходим к практике. Проверим, что центральный коммутатор в режиме Server. Вводим команду show vtp status.
Видим, что VTP Operating Mode: Server. Также можно заметить, что версия VTP 2-ая. К сожалению, в CPT 3-ья версия не поддерживается. Версия ревизии нулевая.
Теперь настроим нижние коммутаторы.
Видим сообщение, что устройство перешло в клиентский режим. Остальные настраиваются точно также.
Чтобы устройства смогли обмениваться объявлениями, они должны находиться в одном домене. Причем тут есть особенность. Если устройство (в режиме Server или Client) не состоит ни в одном домене, то при первом полученном объявлении, перейдет в объявленный домен. Если же клиент состоит в каком то домене, то принимать объявления от других доменов не будет. Откроем SW1 и убедимся, что он не состоит ни в одном домене.
Убеждаемся, что тут пусто.
Теперь переходим центральному коммутатору и переведем его в домен.
Видим сообщение, что он перевелся в домен cisadmin.ru.
Проверим статус.
И действительно. Имя домена изменилось. Обратите внимание, что номер ревизии пока что нулевой. Он изменится, как только мы создадим на нем VLAN. Но перед созданием надо перевести симулятор в режим simulation, чтобы посмотреть как он сгенерирует объявления. Создаем 20-ый VLAN и видим следующую картинку.
Как только создан VLAN и увеличился номер ревизии, сервер генерирует объявления. У него их два. Сначала откроем тот, что левее. Это объявление называется «Summary Advertisement» или на русском «сводное объявление». Это объявление генерируется коммутатором раз в 5 минут, где он рассказывает о имени домена и текущей ревизии. Смотрим как выглядит.
В Ethernet-кадре обратите внимание на Destination MAC-адрес. Он такой же, как и выше, когда генерировался DTP. То есть, в нашем случае на него отреагируют только те, у кого запущен VTP. Теперь посмотрим на следующее поле.
Здесь как раз вся информация. Пройдусь по самым важным полям.
- Management Domain Name — имя самого домена (в данном случае cisadmin.ru).
- Updater Identity — идентификатор того, кто обновляет. Здесь, как правило, записывается IP-адрес. Но так как адрес коммутатору не присваивали, то поле пустое
- Update Timestamp — время обновления. Время на коммутаторе не менялось, поэтому там стоит заводское.
- MD5 Digest — хеш MD5. Оно используется для проверки полномочий. То есть, если на VTP стоит пароль. Мы пароль не меняли, поэтому хэш по-умолчанию.
Думаю здесь понятно. Отдельный заголовок для каждого типа VLAN. Список настолько длинный, что не поместился в экран. Но они точно такие, за исключением названий. Заморачивать голову, что означает каждый код не буду. Да и в CPT они тут больше условность.
Смотрим, что происходит дальше.
Получают клиенты объявления. Видят, что номер ревизии выше, чем у них и синхронизируют базу. И отправляют сообщение серверу о том, что база VLAN-ов изменилась.
Вот так в принципе работает протокол VTP. Но у него есть очень большие минусы. И минусы эти в плане безопасности. Объясню на примере этой же лабораторки. У нас есть центральный коммутатор, на котором создаются VLAN, а потом по мультикасту он их синхронизирует со всеми коммутаторами. В нашем случае он рассказывает про VLAN 20. Предлагаю еще раз глянуть на его конфигурацию.
И тут в сеть мы добавляем новый коммутатор. У него нет новых VLAN-ов, кроме стандартных и он не состоит ни в одном VTP-домене, но подкручен номер ревизии.
И перед тем как его воткнуть в сеть, переводим порт в режим trunk.
Теперь переключаю CPT в «Simulation Mode» и отфильтровываю все, кроме VTP. Подключаюсь и смотрю, что происходит.
Через какое то время до NewSW доходит VTP сообщение, откуда он узнает, что в сети есть VTP-домен «cisadmin.ru». Так как он не состоял до этого в другом домене, он автоматически в него переходит. Проверим.
Теперь он в том же домене, но с номером ревизии выше. Он формирует VTP-сообщение, где рассказывает об этом.
Первым под раздачу попадет SW1.
Заметьте, что на SW1 приходят сразу 2 VTP-сообщения (от NewSW и от CentrSW). В сообщении от NewSW он видит, что номер ревизии выше, чем его и синхронизирует свою базу. А вот сообщение от CentrSW для него уже устарело, и он отбрасывает его. Проверим, что изменилось на SW1.
Обновился номер ревизии и, что самое интересное, база VLAN. Теперь она пустая. Смотрим дальше.
Обратите внимание. До сервера доходит VTP-сообщение, где номер ревизии выше, чем у него. Он понимает, что сеть изменилась и надо под нее подстроиться. Проверим конфигурацию.
Конфигурация центрального сервера изменилась и теперь он будет вещать именно ее.
А теперь представьте, что у нас не один VLAN, а сотни. Вот таким простым способом можно положить сеть. Конечно домен может быть запаролен и злоумышленнику будет тяжелее нанести вред. А представьте ситуацию, что у вас сломался коммутатор и срочно надо его заменить. Вы или ваш коллега бежите на склад за старым коммутатором и забываете проверить номер ревизии. Он оказывается выше чем у остальных. Что произойдет дальше, вы уже видели. Поэтому я рекомендую не использовать этот протокол. Особенно в больших корпоративных сетях. Если используете VTP 3-ей версии, то смело переводите коммутаторы в режим «Off». Если же используется 2-ая версия, то переводите в режим «Transparent».
VLAN Trunking
In the previous lesson, we explained that when a broadcast frame is received on any switch port, the switch forwards it out to all its other ports. Having that in mind, if we connect two default setting switches, as shown in figure 1, any broadcast frame received by either switch is forwarded to the other one and then out all its ports. Therefore a broadcast domain is not limited to one switch only, it includes all devices that get a copy of any broadcast frame, even if they are connected to other switches. If we scale this logic to a LAN with tens of interconnected switches, we could have a broadcast domain consisting of hundred of end devices. This at some point can contest the network with BUM traffic to the point that the LAN becomes unusable. Thus splitting the single broadcast domain into multiple smaller ones is even more important in large topologies for interconnected switches.
Figure 1. Two LAN switches in one broadcast domain
VLAN on multiple switches
So if we apply the logic from the previous lesson, using virtual LANs we can split the switch topology into multiple broadcast domains as shown in figure 2. There are multiple ways of doing this but let’s start with the simplest one. This is done by configuring ports 1 through 4 of both switches to VLAN 10 and ports 5 through 9 to VLAN20. Although it is a valid design and it works, it simply does not scale very well. It requires a physical link between the switches per VLAN . If the topology has to have 10+ VLANs, it would need 10+ physical cables between the switches, and you would use 10+ switch ports (on each switch) for those links.
Figure 2. VLANs spanned on multiple switches without Trunking
Obviously, this design is applicable in topologies, where there are a few VLANs only. Nowadays in modern enterprise networks, there are tens of VLANs, so this way of spanning VLANs between switches is not applicable at scale.
VLAN Trunking
In order to overcome this scaling limitation, we can use another Ethernet technology called VLAN trunking. It creates only one link between the switches that support as many VLAN as needed . At the same time, it also keeps the VLAN traffic separate, so frames from VLAN 20 won’t go to devices in VLAN 10 and vice-versa. An example could be seen in figure 3. The link between switch 1 and switch 2 is a trunk link and you can see that both VLAN 10 and VLAN 20 pass through the link.
Figure 3. VLANs spanned on multiple switches with Trunking
Trunking protocols
Two trunking protocols have been used on Cisco switches over the years — Inter-Switch Link (ISL) and IEEE 802.1Q. ISL was a Cisco proprietary tagging protocol predecessor of 802.1Q, it has been deprecated and is not used anymore. IEEE 802.1Q is the industry-standard trunking encapsulation at present and is typically the only one supported on modern switches.
Figure 4. Ethernet frame tagged with 802.1q header
It is important to note that the tag adds 4 additional bytes to the Ethernet header of the frames. The most important field in the tag is the VLAN ID which is 12 bits long. It specifies the VLAN to which the frame belongs. Because values of 0x000 and 0xFFF are reserved, there are 4,094 possible VLAN numbers.
VLAN Tagging
VLAN trunking allows switches to forwards frames from different VLANs over a single link called trunk. This is done by adding an additional header information called tag to the Ethernet frame. The process of adding this small header is called VLAN tagging. If you look at Figure 4, end-station 1 is sending a broadcast frame. When switch 1 receives the frame, it knows that this is a broadcast frame and it has to send it out all its ports. However, switch 1 must tell switch 2 that this frame belongs to VLAN10. So before sending the frame to switch 2, SW1 adds a VLAN header to the original ethernet frame, with VLAN number 10 as shown in figure 4.
Figure 5. Example of VLANs tagging
When switch 2 receives the frame, it sees that the frame belongs to VLAN 10, then it removes the header and forwards to the original ethernet frame to all its interfaces configured in VLAN10.
So in the given examples, when the ethernet frames are sent between the switches over the trunk link, they are tagged with VLAN header. When the receiving switch gets them, removes the VLAN tag and sends them to the clients in the VLAN, the frames are untagged.
Switch interface modes
Each switch interface can operate as access or trunk port. Because in typical LAN deployment, there are hundreds or even thousands of switch ports, there is a protocol called Dynamic Trunking Protocol (DTP) that helps network administrators set the operational mode of interfaces automatically. By default, all Cisco switch ports are in operational state dynamic auto, which means that this Dynamic Trunking Protocol (DTP) is listening and trying to understand what is configured on the other side of the cable, and based on that to decide whether to become an access or trunk port. For example, if we have a link between SW1 and SW2, if we configure the interface on SW1 to be a trunk port, DTP will advertise this to the other side and the interface on SW2 will automatically set itelf in trunk mode and a trunk link will be formed between the switches.
DEFAULT MODE for layer 2 interfaces of Cisco switches
Passively waiting to convert the port into a trunk. (DTP listening for messages from the far side saying «let’s form a trunk»)
Becomes a trunk if the other side of the link is configured with trunk or dynamic desirable mode
Actively trying to convert the link to a trunk. (DTP actively sending messages to the far side saying «let’s form a trunk»)
Becomes a trunk if the other side of the link is configured with trunk or dynamic desirable or dynamic auto.
The interface becomes an access port.
DTP negotiates the link as nontrunk link.
The interface becomes a trunk port.
DTP negotiates the link as trunk link. (DTP actively sending messages to the far side saying «let’s form a trunk»)
Disables the Dynamic Trunking Protocol (DTP).
Interface mode is configured manually.
As you can see there are quite a few switchport operational modes, so there are several possible combination for both ends of a link between two switches. Depending on the configuration of both sides the switches could form a trunk link or not. All combination are shown in Figure 6.
Figure 6. Possible combinations between two switchports and the resulting link mode
Configuring Trunk ports
As we have already said, the default mode for Cisco switchports is dynamic auto. Therefore, in order to form a trunk, only one side of the link must be configured to actively negotiate it. Let’s configure Gi0/1 on SW1 to be actively trying to form a trunk and see what happens.
You can see from the output of show interface trunk command that a trunk link formed, even though we haven’t configured anything on the other side of the link on switch 2. That is the function of the dynamic trunking protocol. Let’s check what is the status of the link according to switch 2.
Note that the interface on SW2 is in operational mode auto, meaning it was waiting for SW1 to negotiate the trunk.
Записки IT специалиста
Виртуализацией сегодня уже никого не удивить. Эта технология прочно вошла в нашу жизнь и помогает более эффективно использовать имеющиеся ресурсы, а также обеспечивает достаточную гибкость в изменении существующей конфигурации, позволяя перераспределять ресурсы буквально налету. Не обошла виртуализация и локальные сети. Технология VLAN (Virtual Local Area Network) позволяет создавать и гибко конфигурировать виртуальные сети поверх физической. Это позволяет реализовывать достаточно сложные сетевые конфигурации без покупки дополнительного оборудования и прокладки дополнительных кабелей.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Прежде чем продолжить сделаем краткое отступление о работе локальных сетей. В данном контексте мы будем говорить об Ethernet-сетях описанных стандартом IEEE 802.3, куда входят всем привычные проводные сети на основе витой пары. Основой такой сети является коммутатор (свич, switch), который работает на втором уровне сетевой модели OSI (L2).
Второй уровень, он же канальный, работает в пределах одного сегмента сети и использует для адресации уникальные физические адреса оборудования — MAC-адреса. Передаваемая между узлами информация разделяется на специальные фрагменты — Ethernet-кадры (фреймы, frame), которые не следует путать с IP-пакетами, которые находятся на более высоком уровне модели OSI и передаются внутри Ethernet-кадров. Таким образом коммутатор ничего не знает об IP-адресах и никак эту информацию в работе не учитывает.
Коммутатор анализирует заголовки каждого входящего кадра и заносит соответствие MAC-адреса источника в специальную MAC-таблицу, после чего кадр, адресованный этому узлу, будет направляться сразу на определенный порт, если МАС-адрес получателя неизвестен, то кадр отправляется на все порты устройства. После получения ответа коммутатор привяжет MAC-адрес к порту и будет отправлять кадры только через него.
Этим достигается возможность одновременной передачи данных по нескольким портам одновременно и увеличивается безопасность сети, так как данные будут передаваться только на требуемый порт. Одновременно передавать данные через порт коммутатора может только один узел сети. Попытка одновременно передавать несколько кадров в одном сегменте сети называется коллизией, а такой сегмент — доменом коллизий. Чем больше устройств в домене коллизий, тем медленнее работает сеть.
Коммутатор позволяет разделять домен коллизий на отдельные домены по числу портов, таким образом каждый порт коммутатора — это отдельный домен коллизий и в каждом из них данные могут передаваться одновременно, не мешая друг другу.
Совокупность доменов коллизии, соединенных на втором уровне, является широковещательным доменом, если говорить проще, то широковещательный домен — это совокупность всех портов коммутаторов соединенных в один сегмент.
Как мы уже говорили выше, к широковещанию прибегает сам коммутатор, когда получает кадр MAC-адрес которого отсутствует в MAC-таблице, а также узлы сети, отправляя кадры на адрес FF:FF:FF:FF:FF:FF, такие кадры будут доставлены всем узлам сети в широковещательном сегменте.
А теперь вернемся немного назад, к доменам коллизий и вспомним о том, что в нем может передаваться только один кадр одновременно. Появление широковещательных кадров снижает производительность сети, так как они доставляются и тем, кому надо и тем, кому не надо. Делая невозможным в это время передачу целевой информации. Кроме того, записи в MAC-таблице имеют определенное время жизни, по окончании которого они удаляются, что снова приводит к необходимости рассылки кадра на все порты устройства.
Чем больше в сети узлов, тем острее стоит проблема широковещания, поэтому широковещательные домены крупных сетей принято разделять. Это уменьшает количество паразитного трафика и увеличивает производительность, а также повышает безопасность, так как ограничивает передачу кадров только своим широковещательным доменом.
Как это можно сделать наиболее простым образом? Установить вместо одно коммутатора два и подключить каждый сегмент к своему коммутатору. Но это требует покупки нового оборудования и, возможно, прокладки новых кабельных сетей, поэтому нам на помощь приходит технология VLAN.
Данная технология описана стандартом 802.1Q и предусматривает добавление к заголовкам кадра дополнительного поля, которое содержит в том числе определенную метку (тег) с номером виртуальной сети — VLAN ID, всего можно создать 4094 сети, для большинства применений этого достаточно.
Давайте рассмотрим, как работает коммутатор с виртуальными сетями. В нашем примере мы возьмем условный 8-портовый коммутатор и настроим на нем три порта на работу с одним VLAN, а еще три порта с другим.
Каждый VLAN обозначается собственным номером, который является идентификатором виртуально сети. Порты, которые не настроены ни для какого VLAN считаются принадлежащими Native VLAN, по умолчанию он обычно имеет номер 1 (может отличаться у разных производителей), поэтому не следует использовать этот номер для собственных сетей. Порты, настроенные нами для работы с VLAN, образуют как-бы два отдельных виртуальных коммутатора, передавая кадры только между собой. Каким образом это достигается?
Как мы уже говорили выше, каждый кадр 802.1Q содержит дополнительное поле, в котором содержится тег — номер виртуальной сети. При входе Ethernet-кадра в коммутатор с поддержкой VLAN (такой трафик называется входящим — ingres) в его состав добавляется поле с тегом. При выходе из коммутатора (исходящий трафик — egress), данное поле из кадра удаляется, т.е. тег снимается. Все кадры внутри коммутатора являются тегированными. Если трафик пришел на порт, не принадлежащий ни одному VLAN, он получает тег с номером Native VLAN.
В порт, принадлежащий определенному VLAN, могут быть отправлены только пакеты с тегом, принадлежащим этому VLAN, остальные будут отброшены. Фактически мы только что разделили единый широковещательный домен на несколько меньших и трафик из одного VLAN никогда не попадет в другой, даже если эти подсети будут использовать один диапазон IP. Для конечных узлов сети такой коммутатор нечем ни отличается от обычного. Вся обработка виртуальных сетей происходит внутри.
Такие порты коммутатора называются портами доступа или нетегированными портами (access port, untagged). Обычно они используются для подключения конечных узлов сети, которые не должны ничего знать об иных VLAN и работать в собственном сегменте.
А теперь рассмотрим другую картину, у нас есть два коммутатора, каждый из которых должен работать с обоими VLAN, при этом соединены они единственным кабелем и проложить дополнительный кабель невозможно. В этом случае мы можем настроить один или несколько портов на передачу тегированного трафика, при этом можно передавать как трафик любых VLAN, так и только определенных. Такой порт называется магистральным (тегированным) или транком (trunk port, tagged).
Магистральные порты используются для соединения сетевого оборудования между собой, к конечным узлам сети тегированный трафик обычно не доставляется. Но это не является догмой, в ряде случаев тегированный трафик удобнее доставить именно конечному узлу, скажем, гипервизору, если он содержит виртуальные машины, принадлежащие разным участкам сети.
Так как кадр 802.1Q отличается от обычного Ehternet-кадра, то работать с ним могут только устройства с поддержкой данного протокола. Если на пути тегированного трафика попадется обычный коммутатор, то такие кадры будут им отброшены. В случае доставки 802.1Q кадров конечному узлу сети такая поддержка потребуется от сетевой карты устройства. Если на магистральный порт приходит нетегированный трафик, то ему обычно назначается Native VLAN.
Кроме указанных двух портов доступа существует еще одна разновидность — гибридный порт (hybrid port), его реализация и наименование у разных производителей сетевого оборудования может быть разным, но суть от этого не меняется. Такой порт передает как тегированный, так и нетегированный трафик. Для этого в его настройках указывается Default VLAN ID и для всех кадров этого VLAN данный порт работает как порт доступа, т.е для исходящего трафика указанного VLAN тег снимается, а входящему кадру без тега, наоборот, присваивается. Трафик остальных VLAN передается с тегами.
Для чего это нужно? Наиболее частое применение — это IP-телефоны со встроенным коммутатором, которые умеют работать с тегированным трафиком, но не умеют передавать его дальше. В этом случае в качестве VLAN ID по умолчанию устанавливается номер VLAN в котором расположены пользовательские ПК, а для телефона на этот же порт добавляется тегированный трафик VLAN для телефонии.
Все это время мы говорили только о VLAN, не поднимая вопроса: как попасть из одного VLAN в другой. Если продолжать рассматривать канальный уровень — то никак. Каждый VLAN мы можем рассматривать как отдельный физический коммутатор, а магистральный канал — как жгут кабелей между ними. Только все это сделано виртуально, на более высоком уровне абстракции, чем L1 — физический уровень, который как раз представлен кабелями и физическим оборудованием.
Если мы соединим два физических коммутатора кабелем — то получим расширение широковещательного домена на все порты этих устройств, а это совсем не то, что нам нужно. В тоже время сетевые устройства работают на более высоких уровнях модели ОSI, начиная с сетевого — L3. Здесь уже появляется понятие IP-адреса и IP-сетей. Если смотреть на VLAN с этого уровня, то они ничем не отличаются от физических сегментов сетей. А что мы делаем, когда нам нужно попасть из одной сети в другую? Ставим маршрутизатор.
Маршрутизатор или роутер — устройство, работающее на третьем уровне модели OSI и умеющее выполнять маршрутизацию трафика, т.е. поиск оптимального пути для доставки его получателю. И здесь мы говорим уже не о Ethernet-кадрах, а об IP-пакетах. Маршрутизация между VLAN называется межвлановой (межвланной) маршрутизацией (InterVLAN Routing), но, по сути, она ничем не отличается от обычной маршрутизации между IP-подсетями.
Для обеспечения связи между сетями в нашей схеме появляется новая сущность — маршрутизатор, как правило к нему от одного из коммутаторов идет магистральный канал (транк), содержащий все необходимые VLAN, эта схема называется роутер на палочке (леденец, Router-on-a-Stick).
Как работает эта схема? Допустим ПК из синей сети (VLAN ID 40), хочет обратиться к другому узлу синей сети. IP-адрес адресата ему известен, но для того, чтобы отправить кадр нужно знать физический адрес устройства. Для этого ПК источник делает широковещательный ARP-запрос, передавая в нем нужный ему IP-адрес, в ответ на него обладатель этого IP сообщит ему собственный MAC-адрес.
Все кадры, попадающие с порта доступа в коммутатор, получают тег с VLAN ID 40 и могут покинуть коммутатор только через порты, принадлежащие этому VLAN или транк. Таким образом любые широковещательные запросы не уйдут дальше своего VLAN. Получив ответ узел сети формирует кадр и отправляет его адресату. Далее в дело снова вступают коммутаторы, сверившись с MAC-таблицей они отправляют кадр в один из портов, который будет либо принадлежать своему VLAN, либо будет являться магистральным. В любом случае кадр будет доставлен по назначению без использования маршрутизатора, только через коммутаторы.
Совсем иное дело, если узел одного из VLAN хочет получить доступ к узлу другого VLAN. В нашем случае узел из красной сети (VLAN ID 30) хочет получить доступ к узлу синей сети (VLAN ID 40). Узел источник знает IP-адрес адресата и также знает, что этот адрес не принадлежит его сети. Поэтому он формирует IP-пакет на адрес основного шлюза сети (роутера), помещает его в Ethernet-кадр и отправляет на порт коммутатора. Коммутатор добавляет к кадру тег с VLAN ID 30 и доставляет его роутеру.
Роутер получает данный кадр, извлекает из него IP-пакет и анализирует заголовки. Обнаружив адрес назначения, он сверяется с таблицей маршрутизации и принимает решение куда отправить данный пакет дальше. После чего формируется новый Ethernet-кадр, который получает тег с новым VLAN ID сети-получателя в него помещается IP-пакет, и он отправляется по назначению.
Таким образом любой трафик внутри VLAN доставляется только с помощью коммутаторов, а трафик между VLAN всегда проходит через маршрутизатор, даже если узлы находятся в соседних физических портах коммутатора.
Говоря о межвлановой маршрутизации нельзя обойти вниманием такие устройства как L3 коммутаторы. Это устройства уровня L2 c некоторыми функциями L3, но, в отличие от маршрутизаторов, данные функции существенно ограничены и реализованы аппаратно. Этим достигается более высокое быстродействие, но пропадает гибкость применения. Как правило L3 коммутаторы предлагают только функции маршрутизации и не поддерживают технологии для выхода во внешнюю сеть (NAT) и не имеют брандмауэра. Но они позволяют быстро и эффективно осуществлять маршрутизацию между внутренними сегментами сети, в том числе и между VLAN.
Маршрутизаторы предлагают гораздо большее число функций, но многие из них реализуются программно и поэтому данный тип устройств имеет меньшую производительность, но гораздо более высокую гибкость применения и сетевые возможности.
При этом нельзя сказать, что какое-то из устройств хуже, каждое из них хорошо на своем месте. Если мы говорим о маршрутизации между внутренними сетями, в том числе и о межвлановой маршрутизации, то здесь предпочтительно использовать L3 коммутаторы с их высокой производительностью, а когда требуется выход во внешнюю сеть, то здесь нам потребуется именно маршрутизатор, с широкими сетевыми возможностями.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Что такое транк порт
Локальные сети давно перестали состоять из нескольких абонентских устройств, расположенных внутри одного помещения. Современные сети предприятий представляют собой распределенные системы, состоящие из большего количества устройств разного назначения. Ситуация вынуждает разделять такие большие сети на автономные подсети, в итоге логические структуры сети отличаются от физических топологий. Подобные системы создаются с помощью технологии VLAN (Virtual Local Area Network – виртуальная локальная сеть), которая позволяет разделить одну локальную сеть на отдельные сегменты.
Зачем нужна технология VLAN?
Технология VLAN обеспечивает:
- Гибкое построение сети — VLAN позволяет произвести сегментацию локальной сети на подсети по функциональному признаку независимо от территориального расположения устройств. То есть устройства одной подсети VLAN могут быть подключены к разным коммутаторам, удаленным друг от друга. И наоборот, к одному коммутатору могут быть подключены устройства, относящиеся к разным подсетям VLAN
- Увеличение производительности – VLAN разделяет подсеть на отдельные широковещательные домены. Это означает, что широковещательные сообщения будут получать только устройства, находящиеся в одной VLAN-подсети. Построение системы с использованием технологии VLAN позволяет уменьшить широковещательный трафик внутри сети, тем самым снижается нагрузка на сетевые устройства и улучшается производительность системы в целом.
- Улучшение безопасности – Устройства из разных подсетей VLAN не могут общаться друг с другом, что уменьшает шансы произвести несанкционированный доступ к устройствам системы. Связь между разными подсетями возможна только через маршрутизатор. Кроме того, использование маршрутизатора позволяет настроить политики безопасности, которые могут быть применены сразу ко всей группе устройств, принадлежащей одной подсети.
Как работает технология VLAN?
У каждой VLAN-подсети есть свой идентификатор, по которому определяется принадлежность той или иной подсети. Информация об идентификаторе содержится в теге, который добавляется в тело Ethernet-фрейма сети, в которой внедрено разделение на подсети VLAN.
Самый распространенный стандарт, описывающий процедуру тегирования трафика, – это открытый стандарт 802.1 Q. Кроме него есть проприетарные протоколы, но они менее популярны.
Формат Ethernet – фрейма после тегирования:
Тег размером 4 байта состоит из нескольких полей:
- TPID (Tag Protocol Identifier) — Идентификатор протокола тегирования. Для стандарта 802.1Q значение TPID — 0x8100
- Р-тег – Определяет приоритет пакета. Используется при работе стандарта 802.1p для определения очередности обработки пакетов
- CFI (Canonical Format Indicator) – Идентификатор формата МАС-адреса, который использовался для совместимости между сетями Ethernet и Token Ring. В настоящее время поле CFI не используется в связи с отказом от сетей Token Ring
- VLAN ID – Идентификатор VLAN. Определяет, какой подсети VLAN принадлежит пакет
Именно по тегу сетевое оборудование определяет принадлежность пакета той или иной сети VLAN, осуществляет фильтрацию пакетов и определяет дальнейшие действия с ними: снять тег и передать на конечное оборудование, отбросить пакет, переслать следующему получателю с сохранением тега. Правила, определяющие действия с пакетом на основе тега, зависят от режима работы порта сетевого оборудования. В свою очередь, режим работы выбирается в соответствии с характеристиками подключаемого оборудования. В системе может присутствовать как оборудование с поддержкой технологии VLAN, так и без нее.
Режимы работы портов коммутаторов
- Access-port – порт доступа, передающий нетегированный трафик. Используется для подключения конечных устройств, не поддерживающих технологию VLAN
- Trunk-port – магистральный порт, передающий тегированные пакеты данных. Используется для подключения сетевых устройств с поддержкой VLAN, чаще всего для соединения коммутаторов между собой.
- Порты, к которым подключены устройства A и С, устанавливаем в режим access и назначаем PVID равный 10 (Порт 1 на скриншоте)
- Порты, к которым подключены устройства B и D, устанавливаем также в режим access и назначаем PVID равный 20 (Порт 3 на скриншоте)
- Коммутаторы между собой соединяются через trunk-порты. Назначаем этим портам PVID 30. Чтобы trunk-порты пропускали трафик от других VLAN-подсетей (в нашем случае 10 и 20), нужно указать VLAN 10 и 20 в качестве разрешенных. (Порт 5 на скриншоте)
- PVID (Port VLAN Identifier) – идентификатор VLAN-подсети, к которой относится оборудование, подключенное к порту
- Tagged VLAN – список разрешенных VLAN
- Входящие правила
- Если фрейм без VID, то добавить тег с идентификатором равным PVID
- Если фрейм с VID = PVID, то принять пакет. Иначе – пакет отбросить.
- Удалить тег
Правила обработки пакетов для портов Trunk
- Входящие правила
- Если фрейм без VID, то добавить тег с идентификатором равным PVID
- Если фрейм с VID = PVID или VID есть в Tagged VLAN, то принять пакет. Иначе – пакет отбросить
- Если фрейм с VID = PVID, то снять тег
- Если фрейм с VID есть в Tagged VLAN, то оставить тег
Таким образом, технология VLAN позволит создать гибкую систему предприятия с объединением удаленного оборудования и разграничением доступа между функциональными сегментами сети.
Тип Access назначается порту коммутатора, к которому подключено либо единичное абонентское устройство, либо группа устройств, находящихся в одной подсети. Кроме выбора режима работы порта Access необходимо указать идентификатор VLAN-подсети, к которой будет принадлежать оборудование, находящееся за этим портом.
Коммутатор, получив в порт Access данные от подключенных к нему абонентских устройств, добавит ко всем Ethernet-кадрам общий тег с заданным идентификатором подсети и далее будет оперировать уже тегированным пакетом. Напротив, принимая из основной сети данные, предназначенные Access-порту, коммутатор сверит идентификатор VLAN принимаемого пакета с номером VLAN-подсети этого порта. Если они совпадут, то данные будут успешно переданы в порт, а тег удалён, таким образом, подключенные к порту устройства продолжат работать без необходимости поддержки VLAN. Если же идентификатор не равен номеру подсети, кадр будет отброшен, не позволив передать пакет из «чужой» подсети VLAN.
Помимо задания режима работы и идентификатора VLAN, при конфигурировании Trunk-портов создается список разрешенных для передачи подсетей VLAN, с которым коммутатор сверяется при получении пакетов. Благодаря этому через Trunk-порты могут передаваться пакеты нескольких VLAN-подсетей.
Коммутатор, получив в порт Trunk нетегированные данные, поступит аналогично Access-порту, т.е. промаркирует пакеты идентификатором VLAN-подсети, присвоенном этому порту, и передаст дальше в сеть. При получении пакета с таким же идентификатором VLAN, как и у самого порта, тег будет снят и данные отправлены на абонентское устройство без тега. В случае получения тегированного пакета с идентификатором VLAN, отличающимся от номера, присвоенного порту, коммутатор сравнит идентификатор со списком разрешенных VLAN-подсетей. Если номер будет указан в списке, то данные будут переданы по сети на следующее устройство без изменения тега. В случае, если идентификатор указывает на принадлежность незнакомой подсети VLAN, то пакет будет отброшен.
VLAN на коммутаторах Moxa
ЗАДАЧА:
Необходимо построить общую сеть предприятия с разграничением доступа между технологической сетью, предназначеной для управления и мониторинга технологическими процессами и сетью общего назначения. Кроме того, оборудование одной подсети установлено на территориальном удалении друг от друга.
Организовать подобную систему можно с помщою технологии VLAN. Рассмотрим пример реализации данной задачи на коммутаторах Moxa EDS-510E-3GTXSFP.
Технологию VLAN поддерживают все управляемые коммутаторы Moxa.
Оборудование, которое должно находиться в технологической сети (компьютеры A и C), отнесем в подсеть с идентификатором VLAN 10. Оборудование сети общего назначения отнесем в подсеть с идентификатором VLAN 20 (компьютеры B и D). Обмен между этими подсетями происходить не будет. В то же время из-за удаленного расположения устройств оборудование одной VLAN-подсети подключено к разным коммутаторам и необходимо обеспечить обмен данными между ними. Для этого объединим коммутаторы с помощью Trunk портов и поместим их в отдельную подсеть с идентификатором VLAN 30.
Конфигурирование коммутаторов:
Кроме того, следует обратить внимание на параметр Management VLAN ID – подсеть управления коммутатором. Компьютер, с которого необходимо управлять и следить за состоянием самих коммутаторов, должен находиться в подсети управления, указанной в Management VLAN ID. По умолчанию Management VLAN но для предотвращения несанкционированного доступа к коммутаторам рекомендуется идентификатор VLAN управления менять на любой свободный.
Обмен данными в сети предприятия будет осуществляться в соответствии с правилами обработки пакетов.
Правила обработки пакетов для портов Access