Сегодняшний урок мы посвятим продвинутому изучению VLAN. Прежде чем начать, напомню еще раз, чтобы вы не забывали делиться этими видео с друзьями и ставить лайки на нашем канале YouTube и в группе на Facebook. Сегодня мы изучим три темы: Native VLAN, VTP (VLAN Trunk Protocol) и функцию VTP Pruning. Сначала вспомним, что представляет собой транкинг, и затронем темы из двух последних видеоуроков.
Итак, транк – это соединение, которое мы используем для связи одного свитча с другим свитчем. VLAN – это технология, которая применима только в отношении свитчей, однако любое устройство, говорящее на языке инкапсуляции и связанное со свитчем по протоколу .1Q, понимает всё, что касается VLAN. Компьютеры ничего не знают об этой технологии.
На приведенном рисунке компьютеры PC1, PC2 и PC4 являются частью синей VLAN, как вы помните из предыдущего урока, это VLAN10. Сама по себе линия, обозначенная синим цветом, не имеет никакого отношения к VLAN, потому что VLAN касается только порта свитча. Таким образом, оба порта левого свитча относятся к VLAN10 и любой входящий или исходящий трафик ассоциируется только с этой сетью. Свитч знает, что трафик этих синих портов не имеет никакого отношения к красному порту, потому что это две разные виртуальные линии.
VLAN это концепция для свитчей, поэтому каждый свитч поддерживает создание и хранение базы данных виртуальных сетей. Это таблица, в которой указано, какой из портов соответствует конкретной VLAN. Таким образом, если свитч получает трафик для PC1, он проверяет, является ли этот трафик частью VLAN10, и направляет его компьютеру. Если трафик с PC1 предназначен для PC4, свитч направит его по транку SW1-SW2. Как только трафик попадает в порт транка первого свитча, он снабжает фрейм заголовком VLAN TAG, в котором содержится идентификатор VLAN ID, в нашем случае это 10. Получив этот трафик, второй свитч считывает информацию фрейма, видит, что это трафик VLAN10, и направляет его на синий порт для PC4.
Таким образом, транкинг – это процесс передачи трафика между двумя свитчами, а VLAN TAGS – это заголовки фрейма, идентифицирующие конкретную виртуальную сеть и указывающие, в какую сеть должен быть направлен данный трафик. Если по ошибке синий трафик попадет к компьютеру по красной линии, тот даже не будет знать, как его прочитать. Это будто бы кто-то разговаривает на иностранном языке с человеком, который не знает этого языка. Итак, компьютер совершенно не способен распознавать теги VLAN. Компьютер PC3 подсоединен к свитчу через access – порт, а упомянутый нами трафик может пересылаться только через транк-порт.
Все это особенности 2-го уровня модели OSI, к которому относятся свитчи. Для того, чтобы лучше понять суть VLAN и тегов, мы должны думать, как свитч. Предположим, что свитч – это комната, в которой находятся 5 человек, а вы – хозяин этой комнаты. Три человека под номерами 1,2 и 4 принадлежат к одной группе, а два под номерами 3 и 5 – к другой, и ваша обязанность сделать так, чтобы разговаривать друг с другом могли только люди, принадлежащие к одной и той же группе.
Продолжим обсуждение концепции native VLAN. Как уже говорилось, каждый порт свитча ассоциируется с определенной VLAN.
Например, два порта первого свитча связаны с VLAN10, третий access-порт с VLAN20, а четвертый – это транк-порт. Точно так же SW2 связан с PC4 через порт VLAN10, с PC5- через access-порт VLAN20 и с хабом через транк-порт. Однако у нас имеется одна проблема – свитчи дорого стоят, поэтому часто используется схема, при которой два свитча связаны друг с другом через хаб. Два свитча соединены с хабом с помощью транков, но сам хаб ничего не знает о концепции VLAN, он просто копирует сигнал. Как мы уже сказали, если трафик VLAN напрямую направить к компьютеру, он его отбросит, потому что не поймет, что это такое. Как же нам быть с компьютером PC6, который соединен с хабом напрямую, если он собирается установить связь с компьютером PC4?
Компьютер PC6 отправляет трафик, который поступает на свитч SW2. Получив этот трафик, свитч видит, что фрейм не имеет тега VLAN и не знает, в какую сеть его направить – VLAN10 или VLAN20. Для такого случая компания Cisco создала технологию, которая носит название Native VLAN, и по умолчанию VLAN1 является Native VLAN.
Предположим, у нас имеется ещё один компьютер, я нарисую его над свитчем SW2, и этот ПК соединен со свитчем через порт VLAN1. Такой же компьютер расположен над SW1 и тоже соединен с ним через VLAN1. Я нарисую еще один компьютер под правым свитчем.
Два компьютера, соединенные со свитчем SW2 через VLAN1, могут общаться друг с другом, но не способны связаться с другими компьютерами. Когда свитч получает через транк нетегированный трафик, он считает, что этот трафик адресован сети VLAN1, или Native VLAN, и направляет его компьютерам, подсоединенным к портам VLAN1. Аналогичным образом, когда свитч получает нетегированный трафик PC6, он адресует его сети VLAN1.
Что произойдет, если у нас на красной линии VLAN20 имеется IP-телефон Cisco, который подсоединен к компьютеру PC5 и свитчу SW2? Это типичная схема расположения офисного сетевого оборудования. В данном случае также используется концепция Native VLAN. Как я говорил, компьютер не знает, что такое VLAN, а телефон – знает. Вопрос состоит в том, сможем ли мы отсылать данные и голосовой сигнал по одной и той же VLAN. Это очень опасная ситуация, потому что если компьютер находится на одной линии связи с IP-телефоном, хакер легко может подсоединиться к такому каналу связи и использовать Wireshark для перехвата голосовых пакетов. Далее он может конвертировать эти голосовые пакеты в звуковой файл и подслушать любой телефонный разговор. Поэтому на практике голосовой трафик и трафик с данными никогда не передаются по одной и той же линии VLAN. Как же это можно настроить?
Мы превращаем порт, к которому подсоединен IP-телефон, в транк-порт, и считаем, что любой трафик, проходящий через этот порт – это голосовой трафик сети VLAN30. Любой IP-телефон Cisco использует протокол инкапсуляции 802.1q, который принято называть сокращенно .1Q или Dot 1Q. Таким образом, когда трафик с телефона попадает в соответствующий порт, свитч понимает, что это голосовой трафик VLAN30. У нас должен иметься другой телефон, который подсоединен к свитчу SW, который тоже является частью VLAN30.
Что же в этом случае происходит с компьютером PC4, который подсоединен к свитчу через access- порт? Ведь весь трафик, которым этот компьютер обменивается со свитчем, принадлежит синей VLAN10. Однако компьютер PC5 соединен со свитчем через транк, а для транка мы не настраиваем никакой VLAN! В этом случае порт работает в режиме trunk, а не access, поэтому мы не можем использовать команду switchport access VLAN#. Здесь используется та же концепция, что и в случае с компьютером PC6 – если свитч получает нетегированный трафик, он направляет его на порт сети native VLAN, по умолчанию это VLAN1.
Возникает вопрос, можно ли изменить native VLAN. Ответ – да, вы можете это сделать, например, в случае с красной линией можно поменять native VLAN на VLAN20, и тогда свитч будет направлять красный трафик от PC5 в сеть VLAN20. Поскольку оба свитча связаны транком, свитч SW2, получив трафик VLAN20, посчитает его трафиком native VLAN и отправит свитчу SW1 как нетегированный.
Получив этот трафик, свитч SW1 распознает его как нетегированный native трафик, и поскольку его native VLAN — это VLAN1, отправит данный трафик в эту сеть. Если мы меняем native VLAN, то должны делать это с осторожностью, чтобы убедиться, что все native VLAN во всех свитчах изменились правильным образом, иначе это может вызвать множество проблем.
Это был короткий обзор native VLAN, а теперь мы перейдем к проприетарному протоколу VTP (VLAN Trunking Protocol). В первую очередь вы должны запомнить, что, не смотря на свое название, VTP не является протоколом транкинга.
Из предыдущих уроков мы знаем, что имеется всего 2 протокола транкинга: проприетарный протокол Cisco под названием ISL и общепринятый протокол 802.1q.
VTP также является проприетарным протоколом Cisco, но не занимается транкингом в смысле создания магистральных подключений. Предположим, что мы создали VLAN10 на порту первого свитча, к которому подсоединен компьютер. Далее у нас имеется транк SW1-SW2 и транк SW2-SW3. Когда транк-порт SW1 получает трафик компьютера, он знает, что это трафик VLAN10 и пересылает его второму свитчу. Однако второй свитч не знает, что такое VLAN10, потому что к нему не подсоединено ничего кроме транка, поэтому, чтобы принять этот трафик и отправить его дальше, он создает на своих портах VLAN10. Свитч 3 поступит аналогично – получив трафик по транку, он создаст VLAN10.
Можно создать на SW3 два access-порта, и оба будут VLAN10. Предположим, что на всех 3-х свитчах я хочу создать ещё одну сеть – VLAN20. Это станет возможно только после того, как будут созданы порты для VLAN20. Чем больше устройств, компьютеров и свитчей добавляется в вашу сеть, тем сложнее становится создание новых VLAN, поэтому Cisco автоматизировала данный процесс, создав VTP.
Если мы создаем новую VLAN, назовем её VLAN30, на одном из свитчей, то на всех остальных свитчах, соединенных транком, автоматически создается такая же сеть VLAN30.
Дополненная, обновленная база данных VLAN просто рассылается по всем свитчам, после чего вам остается только создать access-порт для компьютера. Без этого протокола вам придется вручную перенастраивать все свитчи. Недостатком VTP является то, что если вы вносите изменения в базу данных VLAN, у неё изменяется revision number — номер ревизии. Обычно, когда вы используете свитч прямо из коробки, все настройки имеют нулевой номер ревизии. Когда вы добавляете новую VLAN, например, десятую, база данных SW1 получает номер ревизии #1. В этом случае второй свитч говорит: «ок, у тебя ревизия 1, а у меня ревизия 0, значит я должен поменять номер своей ревизии на 1 и перекопировать все данные из твоей таблицы VLAN в свою таблицу». То же самое проделывает третий свитч.
Допустим, теперь 2 свитч добавляет себе VLAN20 и меняет номер ревизии на 2, тогда то же самое должны проделать первый и третий свитч. Каждый раз, когда вы изменяете номер ревизии, протокол проверяет, у кого этот номер выше, и меняет все остальные номера ревизии на этот номер, одновременно обновляя свою таблицу VLAN. Причем VTP безоговорочно доверяет свитчу с наибольшим номером ревизии.
Представим себе такую ситуацию. В компанию приходит новый сотрудник и обнаруживает где-нибудь в углу свитч, который используется для обучения персонала. Он ничего об этом не знает, видит, что данный свитч выглядит новее, и решает подключить его к общей сети. Он настраивает этот свитч, подключает его, например, к свитчу SW2 и создает транк. И как только он его включает, вся ваша сеть падает! Все перестает работать, потому что связь между компьютерами и свитчами полностью пропадает.
Почему же это произошло? Максимальный номер ревизии свитчей компании 50, потому что в компании имеется всего 5 VLAN – 10,20,30,40,50. Новый свитч использовался для обучения, к нему подсоединялось больше сетей, в настройки вносилось много изменений, в результате чего его revision number увеличился до 100. При этом у него в базе данных VLAN имеется всего одна сеть под номером 105.
После того, как SW Training подсоединился к SW2 через транк, второй свитч увидел, что у новичка больший номер ревизии, и принял решение изменить свой номер на высший. При этом он скопировал себе таблицу VLAN нового свитча, автоматически удалив все имеющиеся у него сети VLAN10,20,30…., заменив их одной VLAN105, которой до этого не было в существующей сети. Точно также поступили первый и третий свитч, изменив себе номер ревизии с 50 на 100 и удалив из базы данных старые сети, потому что они не содержались в таблице VLAN свитча SW Training.
У свитча SW1 были созданы access-порты для сети VLAN10, но после обновления ревизии эта сеть пропала. Свитчи устроены таким образом, что если access-порт настроен на работу с сетью, которой нет в базе данных VLAN, данный порт программно отключается. То же самое произошло с сетями VLAN20 и VLAN30 – свитчи не нашли их в обновленной базе данных виртуальных сетей и просто отключили соответствующие access-порты, после чего существующая локальная сеть компании вышла из строя.
Уверяю вас, что подобное не редко происходит на практике. Лично я дважды был свидетелем события, когда сеть прекращала работу из-за того, что кто-то подключил новый свитч. Так что будьте осторожны, потому что VTP – это очень мощная штука. Cisco считает, что из-за возможности возникновения подобной проблемы VTP лучше вообще не использовать.
Существует механизм предотвращения сбоя сети, вызванного ошибкой использования VTP. Это механизм доменов VTP, работающий таким образом: если домен одного из свитчей в сети отличается от домена других свитчей, работающих по протоколу VTP, репликация базы данных VLAN этого свитча проводиться не будет. Однако, не смотря на этот механизм, Cisco не советует пользоваться данным протоколом без особой необходимости.
Однако если вы уверены, что VTP поможет вам при создании сети и что вы сможете ответственно подойти к настройке свитчей, можете попробовать его использовать. VTP имеет 3 режима: Server, Client и Transparent.
Режим VTP Server позволяет вносить изменения в сеть, то есть создавать, удалять и изменять VLAN из командной строки свитча. По умолчанию этот режим установлен во всех свитчах Cisco.
Я нарисовал три свитча, первый из них находится в режиме Server, а два других – в режиме Client. Вы можете создать новую VLAN только на первом свитче, после чего база данных будет реплицирована на втором и третьем свитче. Если вы попробуете проделать это со вторым свитчем, то получите ответ: «Я не являюсь сервером, поэтому вы не можете внести подобные изменения в мои настройки». Вот в чем заключается механизм, предотвращающий внесение изменений. Таким образом, вы можете выбрать сервером один из свитчей, внести изменения в его настройки, и они будут повторены на свитчах – клиентах. Однако что делать, если вы не намерены использовать VTP?
Для полного отказа от использования этого протокола вам нужно перевести свитч в режим Transparent. При этом вы не отключаете режим VTP, просто свитч больше не генерирует объявления VTP, не обновляет базы данных VLAN и всегда использует configuration revision number 0.
Допустим, мы используем режим Transparent для второго свитча. При получении VTP –информации он увидит, что данный протокол на него не распространяется, и просто передаст эту информацию следующему свитчу, который находится в режиме Client, ничего не обновляя в своих собственных настройках. Таким образом, режим Transparent означает отказ от использования VTP конкретным свитчем.
Итак запомните, что режим Server позволяет вносить изменения, режим Client – получать эти изменения, а режим Transparent предотвращает применение изменений по протоколу VTP, передавая их дальше по сети.
Теперь поговорим о концепции под названием VTP Pruning. Предположим, что на свитче SW1 существует две сети VLAN30, красная сеть VLAN20 и две синих сети VLAN10.
Свитч SW2 не имеет порта для VLAN30. Однако по умолчанию SW1 передает тегированный трафик VLAN10,20 и 30 по транку. Как администратор сети вы знаете, что у свитча SW2 нет VLAN30, однако должны обеспечить корректную передачу любого трафика. Для этого вы используете дополнительную информацию для трафика, исходящего из SW1, с помощью VTP Pruning. Вы настраиваете первый свитч таким образом, что он может передать по транку только трафик сетей VLAN10 и VLAN20, исключая возможность передачи по транку трафика сети VLAN30. Вот что представляет собой концепция VTP Pruning. На следующем видеоуроке мы рассмотрим, как осуществить настройки, о которых я сегодня рассказал.
Итак, мы обсудили три концепции: Native VLAN, VTP и VTP Pruning. Надеюсь, что вы поняли все из того, что услышали. Если это не так, просмотрите урок еще столько раз, сколько посчитаете нужным, и не стесняйтесь задавать мне вопросы по электронной почте или в комментариях к данному видео.
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Автор: ua-hosting
