Основы компьютерных сетей. Тема №6. Понятие VLAN, Trunk и протоколы VTP и DTP

[@Godless]

Поэтому порт сетевого устройства может находиться в 2-х состояниях: access или trunk.

Гибридные порты не затронуты. А так очень интересно, спасибо!

[@htol]

А что такое гибридный порт? Про native vlan вроде рассказали. Еще есть pvlan, но чего там гибридного тоже не знаю. Откуда терминология?

[@solid_93]

Терминология «гибридный порт» встречается на коммутаторах других вендоров. В частности Huawei. В циске явно такого названия нет. Но настроить его, как гибридный можно. Можете почитать здесь.

[@ksg222]

Спасибо за статью! Буквально несколько дополнений.

Хочу заострить внимание на том, что тегирование кадров осуществляется между сетевыми устройствами (коммутаторы, маршрутизаторы и т.д.), а между конечным узлом (компьютер, ноутбук) и сетевым устройством кадры не тегируются.

Если у нас сервер да ещё и с визуализацией, то очень часто мы туда закидываем сразу несколько VLANов (так как виртуальные машины могут быть в разных сетях). Поэтому тегировать трафик в сторону серверов можно и достаточно часто нужно.

VTP Client — Эта роль уже ограничена. Создавать, изменять и удалять VLAN нельзя. Все VLAN получает и синхронизирует от сервера. Сам ничего не генерирует, только ретранслирует от других.

Тут интересный момент, что подразумевается под понятием «ничего не генерирует» и «только ретранслирует». VTP клиент сообщения Summary Advertisement/Subset Advertisement не ретранслирует, а именно генерирует. Например, если мы подключим новый VTP сервер в сеть, так что он будет иметь соседом клиента, сервер будет запрашивать базу именно с соседнего клиента. И именно клиент ему её предоставит.

Вот так в принципе работает протокол VTP. Но у него есть очень большие минусы. И минусы эти в плане безопасности… Поэтому я рекомендую не использовать этот протокол.

Как раз для решения данной проблемы в VTPv3 появилась роль primary server. Только primary server может раздавать базу VLAN'ов. И устройства синхронизируют между собой эту базу только, если они имеют один общий primary server. Если primary server перезагружается/меняется на новый, он теряет свою роль. Это защищает от случайной перезаписи базы из-за нюансов с revision number.

[@inthex]

Тут интересный момент, что подразумевается под понятием «ничего не генерирует» и «только ретранслирует». VTP клиент сообщения Summary Advertisement/Subset Advertisement не ретранслирует, а именно генерирует. Например, если мы подключим новый VTP сервер в сеть, так что он будет иметь соседом клиента, сервер будет запрашивать базу именно с соседнего клиента. И именно клиент ему её предоставит.

Вы здесь правы, исправил.

Так в итоге правильно ли я понимаю, что второй коммутатор, с ролью сервера, получит от ближайшего клиента базу и перехватит роль главного сервера (так сказать primary) на себя из-за ревизии. Правильно?
P.S. Еще глубоко тему не копал, но мне она интерессна.

[@solid_93]

Второй коммутатор (с большей ревизией) получит от клиента его базу. Сравнит и поймет, что она старее его. И вышлет ему свою.В VTP версии 2 нет понятия «primary», «secondary» и прочего. Тут просто все равняются на того, кого ревизия выше (то есть новее).

[@inthex]

Ок, спасибо. Будем изучать офф-документацию.

[@solid_93]

Спасибо за такой развернутый и дельный комментарий.

Тут интересный момент, что подразумевается под понятием «ничего не генерирует» и «только ретранслирует». VTP клиент сообщения Summary Advertisement/Subset Advertisement не ретранслирует, а именно генерирует. Например, если мы подключим новый VTP сервер в сеть, так что он будет иметь соседом клиента, сервер будет запрашивать базу именно с соседнего клиента. И именно клиент ему её предоставит.

Вы здесь правы, исправил.

Как раз для решения данной проблемы в VTPv3 появилась роль primary server. Только primary server может раздавать базу VLAN'ов. И устройства синхронизируют между собой эту базу только, если они имеют один общий primary server. Если primary server перезагружается/меняется на новый, он теряет свою роль. Это защищает от случайной перезаписи базы из-за нюансов с revision number.

К сожалению 3-ей версии VTP нет в CPT.

[@pkuutn]

Можно вопрос по router-on-a-stick?
Я понимаю, выгодно использовать только один физический порт, но не станет ли узким местом:
— собственно этот порт
— процессор роутера, которому придётся заниматься inter-VLAN обаботкой
в случае, к примеру, размещения серверов и рабочих станциях в разных VLAN (неоднократно фидел такие конфигурации)?
Тот же SMB и копирование/использование приличного размера файлов?

[@solid_93]

По поводу порта. Конечно место это уязвимо. Отказ линии или порта приведет к тому, что сеть парализует.
По поводу процессора. Несколько VLAN-ов не сильно нагрузят процессор. Но тут уже зависит от ее кол-ва. Понятное дело, что если у вас сотни и тысячи VLAN-ов, то потребуется покупать более мощное и дорогостоящее оборудование.

[@pkuutn]

Нет, я про более примитивный случай. SMB сервер и клиенты в разных VLAN и подсетях.
Маршрутизатор — простенький типа 2811.
Ему простое копирование файлов процессор не перегрузит? Там, получается, необходимо маршрутизировать и плюс тегировать пакеты.

[@solid_93]

Перекинуть данные из одной канальной среды в другую, для него не составит труда. Это одна из его основных функций.

[@inthex]

Если кол-во портов позволяет, возможна агрегация каналов.

[@alk0v]

Вопрос безопасности VTP также частично решает аутентификация, штука в целом удобная, когда нужно новый влан на кучу свичей разлить, кстати, есть ли что-то похожее на Juniper?

[@satosan]

Красиво да? Мы в прошлых статьях уже не раз говорили о работе протокола ARP, но это было еще в прошлом году, поэтому вкратце объясню. Так как PC1 не знает MAC-адрес (или адрес канального уровня) PC5, то он отправляет в разведку ARP, чтобы тот ему сообщил. Он приходит на коммутатор, откуда ретранслируется на все активные порты, то есть к PC2 и на центральный коммутатор. Из центрального коммутатора вылетит на соседние коммутаторы и так далее, пока не дойдет до PC5. Вот такой не маленький трафик вызвало одно ARP-сообщение. Его получили все участники сети. Большой и не нужный трафик — это первая проблема.

Трафик очень маленький.
Один раз шлет пакет, а потом на каждом свиче есть ARP-таблицы, в которых есть нужные записи.
То, что вы рассказывается относилось к хабам, которые уже сто лет никто не видел.
Сам пакет ping доставляется непосредственно нужному компу

[@solid_93]

Это пример (чем больше устройств в одном широковещательном домене, тем больше будет пакетов). Но даже на нем видно, что при наличии 6 устройств, копию получат 5 устройств (а предназначалась только одному).

А про второе ваше утверждение - ARP таблицы заполняются как раз по первому пакету (или правильнее кадру). То есть до заполнения ARP таблицы, коммутатор ведет себя так же, как хаб. И вот как только ARP таблица заполнится - он начнет посылать пакет в "правильный" порт (на основании изученного ранее)