При использовании VLAN на базе портов, каждый порт назначается в определенную VLAN, независимо от того, какой пользователь или компьютер подключен к этому порту. Это означает, что все пользователи, подключенные к этому порту, будут членами одной VLAN.

Конфигурация портов статическая и может быть изменена только вручную.

VLAN на базе портов.

Vlan на базе mac-адресов.

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

VLAN на базе МАС-адресов.

Vlan на базе меток – стандарт 802.1q.

Первые два подхода основаны только на добавлении дополнительной информации к адресным таблицам моста и не используют возможности встраивания информации о принадлежности кадра к виртуальной сети в передаваемый кадр. Метод организации VLAN на основе меток – тэгов , использует дополнительные поля кадра для хранения информации о принадлежности кадра при его перемещениях между коммутаторами сети. К кадру Ethernet добавляется метка (Tag) длиной 4 байта:

Добавляемая метка кадра включает в себя двухбайтовое поле TPID (Tag Protocol Identifier) и двухбайтовое поле TCI (Tag Control Information). Первые 2 байта с фиксированным значением 0х8100 определяют, что кадр содержит тег протокола 802.1q/802.1p. Поле TCI состоит из полей Priority, CFI и VID. Поле Priotity длиной 3 бита задает восемь возможных уровней приоритета кадра. Поле VID (VLAN ID) длиной 12 бит является идентификатором виртуальной сети. Эти 12 бит позволяют определить 4096 различных виртуальных сетей, однако идентификаторы 0 и 4095 зарезервированы для специального использования, поэтому всего в стандарте 802.1Q возможно определить 4094 виртуальные сети. Поле CFI (Canonical Format Indicator) длиной 1 бит зарезервировано для обозначения кадров сетей других типов (Token Ring, FDDI), для кадров же Ethernet оно равно 0.

После того, как кадр принят входным портом коммутатора, решение об его дальнейшей обработке принимается на основании правил входного порта (Ingress rules). Возможны следующие варианты:

прием только кадров типа Tagged;

прием только кадров типа Untagged;

по умолчанию для всех коммутаторов прием кадров обоих типов.

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

1000Base Ethernet

1000Base Ethernet или Gigabit Ethernet, как и технология Fast Ethernet, использует тот же формат кадра, метод доступа CSMA/CD, топологию звезда и управление соединением (LLC – подуровень), что и стандарт IEEE 802.3 и 10Base-T Ethernet. Принципиальная разница технологий опять заключается в реализации физического уровня ЭМВОС – реализации устройств PHY. Для реализации трансиверов PHY, подключаемых к оптоволокну, использовались разработки IEEE 802.3 и ANSI X3T11 Fibre Channel. В 1998 году был опубликован стандарт 802.3z для оптоволокна и 802.3ab для витой пары.

Если отличия между Ethernet и Fast Ethernet минимальны и не затрагивают MAC-уровня, то при разработке стандарта Gigabit Ethernet 1000Base-T разработчикам пришлось не только внести изменения в физический уровень, но и затронуть MAC-подуровень.

Физический уровень Gigabit Ethernet использует несколько интерфейсов, включая традиционную витую пару категории 5, а также многомодовое и одномодовое волокно. Всего определяются 4 различных типа физических интерфейсов среды, которые отражены в спецификациях стандарта 802.3z (1000Base-X) и 802.3ab (1000Base-T).

Поддерживаемые расстояния для стандартов 1000Base-X приведены в таблице ниже.

Стандарт	Тип волокна	Максимальное расстояние*, м
(лазерный диод 1300 нм)	Одномодовое волокно (9 мкм)
	Многомодовое волокно (50 мкм)***
Стандарт	Тип волокна/витой пары	Максимальное расстояние*, м
(лазерный диод 850 нм)	Многомодовое волокно (50 мкм)
	Многомодовое волокно (62,5 мкм)
	Многомодовое волокно (62,5 мкм)
	Экранированная витая пара: STP

Характеристики оптических приемопередатчиков могут быть значительно выше, указанных в таблице. Например, компания NBase выпускает коммутаторы с портами Gigabit Ethernet, обеспечивающими передачу на расстояния до 40 км по одномодовому волокну без ретрансляций (используются узкоспектральные DFB лазеры, работающие на длине волны 1550 нм).

Интерфейс 1000Base-T

1000Base-T - это стандартный интерфейс Gigabit Ethernet передачи по неэкранированной витой паре категории 5e и выше на расстояния до 100 метров. Для передачи используются все четыре пары медного кабеля, скорость передачи по одной паре 250 Мбит/c.

Подуровень MAC

Подуровень MAC стандарта Gigabit Ethernet использует тот же самый метод доступа к среде передачи CSMA/CD что и его предшественники Ethernet и Fast Ethernet. Основные ограничения на максимальную длину сегмента (или коллизионного домена) определяются именно этим протоколом.

Одной из проблем реализации скорости 1 Гбит/с стало обеспечение приемлемого диаметра сети при работе в полудуплексном режиме работы. Как известно, минимальный размер кадра в сетях Ethernet и Fast Ethernet составляет 64 байта. При скорости передачи 1 Гбит/с и размере кадра 64 байта для надежного распознавания коллизий необходимо, чтобы расстояние между двумя наиболее удаленными компьютерами составляло не более 25 метров. Напомним, что успешное распознавание коллизий возможно, если время передачи кадра минимальной длины больше, чем двойное время распространения сигнала между двумя максимально удаленными узлами в сети. Поэтому, чтобы обеспечить максимальный диаметр сети в 200 м (два кабеля по 100 м и коммутатор), минимальная длина кадра в стандарте Gigabit Ethernet была увеличена до 512 байт. Чтобы увеличить длину кадра до требуемого значения, сетевой адаптер дополняет поле данных до длины 448 байт так называемым расширением (carrier extention). Поле расширения - это поле, заполненное запрещенными символами, которые невозможно принять за коды данных. При этом поле контрольной суммы вычисляется только для оригинального кадра и не распространяется на поле расширения. При приеме кадра поле расширения отбрасывается. Поэтому уровень LLC даже и не знает о наличии поля расширения. Если размер кадра равен или превосходит 512 байт, то поле расширения носителя отсутствует.

Кадр Gigabit Ethernet с полем расширения носителя

Если задуматься о том, как же работают виртуальные сети, то в голову приходит Мысль, что все дело не в отправляющей машине, а в самом кадре ВЛВС. Если бы был какой-нибудь способ идентифицировать ВЛВС по заголовку кадра, отпала бы необходимость просмотра его содержимого. По крайней мере, в новых сетях tHna 802.11 или 802.16 вполне можно было бы просто добавить специальное поле заголовка. Вообще-то Идентификатор кадра в стандарте 802.16 -- это как раз нечто в этом духе. Но что делать с Ethernet -- доминирующей сетью, у которой нет никаких «запасных» полей, которые можно было бы отдать под идентификатор виртуальной сети? Комитет IEEE 802 озаботился этим вопросом в 1995 году. После долгих дискуссий было сделано невозможное -- изменен формат заголовка кадра Ethernet!? Новый формат было опубликован под именем 802.1Q, в 1998 году. В заголовок кадра был вставлен флаг ВЛВС, который мы сейчас вкратце рассмотрим. Понятно, что внесение изменений в нечто уже устоявшееся, такое как Ethernet, должно быть произведено каким-то нетривиальным образом. Встают, например, следующие вопросы:

• 1. И что, теперь надо будет выбросить на помойку несколько миллионов уже существующих сетевых карт Ethernet?
• 2. Если нет, то кто будет заниматься генерированием новых полей кадров?
• 3. Что произойдет с кадрами, которые уже имеют максимальный размер?

Конечно, комитет 802 тоже был озабочен этими вопросами, и решение, несмотря ни на что, было найдено.

Идея состоит в том, что на самом деле поля ВЛВС реально используются только мостами да коммутаторами, а не машинами пользователей. Так, скажем, сеть не очень-то волнует их наличие в каналах, идущих от оконечных станций, до тех пор, пока кадры не доходят до мостов или коммутаторов. Таким образом, чтобы была возможна работа с виртуальными сетями, про их существование должны знать мосты и коммутаторы, но это требование и так понятно. Теперь же мы выставляем еще одно требование: они должны знать про существование 802.1Q. Уже выпускается соответствующее оборудование. Что касается старых сетевых, карт Ethernet, то выкидывать их не приходится. Комитет 802.3 никак не мог заставить людей изменить поле Тип на поле Длина. Вы можете себе представить, какова была бы реакция на заявление о том, что все существующие карты Ethernet можно выбросить? Тем не менее, на рынке появляются новые модели, и есть надежда, что они теперь будут 802.1Ј)-совместимыми и смогут корректно заполнять поля идентификации виртуальных сетей.

Если отправитель не генерирует поле признака виртуальной сети, то кто же этим занимается? Ответ таков: первый встретившийся на пути мост или коммутатор, обрабатывающий кадры виртуальных сетей, вставляет это поле, а последний -- вырезает его. Но как он узнает, в какую из виртуальных сетей передать? локальная сеть маршрутизатор трафик

Для этого первое устройство, которое вставляет поле ВЛВС, может присвоить номер виртуальной сети порту, проанализировать МАС-адрес или (не дай Бог, конечно) подсмотреть содержимое поля данных. Пока все не перейдут на Ethernet-карты, совместимые со стандартом 802.1Q, все именно так и будет. Остается надеяться на то, что все сетевые платы гигабитного Ethernet будут придерживаться стандарта 802.1Q, с самого начала их производства, и таким образом всем пользователям гигабитного Ethernet этой технологии автоматически станут доступны возможности 802.1Q. Что касается проблемы кадров, длина которых превышает 1518 байт, то в стандарте 802.1Q она решается путем повышения лимита до 1522 байт. При передаче данных в системе могут встречаться как устройства, которым сокращение ВЛВС не говорит ровным счетом ни о чем (например, классический или быстрый Ethernet), так и совместимая с виртуальными сетями аппаратура (например, гигабитный Ethernet). Здесь затененные символы означают ВЛВС-совместимые устройства, а пустые квадратики -- все остальные. Для простоты мы предполагаем, что все коммутаторы ВЛВС-совместимы. Если же это не так, то первый такой ВЛВС-совместимый коммутатор добавит в кадр признак виртуальной сети, основываясь на информации, взятой из MAC- или IP-адреса.

ВЛВС-совместимые сетевые платы Ethernet генерируют кадры с флагами (то есть кадры стандарта 802.1Q), и дальнейшая маршрутизация производится уже с использованием этих флагов. Для осуществления маршрутизации коммутатор, как и раньше, должен знать, какие виртуальные сети доступны на всех портах. Информация о том, что кадр принадлежит серой виртуальной сети, еще, по большому счету, ни о чем не говорит, поскольку коммутатору еще нужно знать, какие порты соединены с машинами серой виртуальной сети. Таким образом, коммутатору нужна таблица соответствия портов виртуальным сетям, из которой также можно было бы узнать, являются ли порты ВЛВС совместимыми. Когда обычный, ничего не подозревающий о существовании виртуальных сетей компьютер посылает кадр на коммутатор виртуальной сети, последний генерирует новый кадр, вставляя в него флаг ВЛВС. Информацию для этого флага он получает с виртуальной сети отправителя (для ее определения используется номер порта, MAC- или IP-адрес.) Начиная с этого момента никто больше не переживает из-за того, что отправитель является машиной, не поддерживающей стандарт 802.1Q, Таким же образом коммутатор, желающий доставить кадр с флагом на такую машину, должен привести его к соответствующему формату. Теперь рассмотрим собственно формат 802.1Q. Единственное изменение -- это пара 2-байтовых полей. Первое называется Идентификатор протокола ВЛВС. Оно всегда имеет значение 0x8100. Поскольку это число превышает 1500, то все сетевые карты Ethernet интерпретируют его как «тип», а не как «длину». Неизвестно, что будет делать карта, несовместимая с 802.1Q, поэтому такие кадры, по идее, не должны к ней никоим образом попадать.

Во втором двухбайтовом поле есть три вложенных поля. Главным из них является идентификатор ВЛВС, который занимает 12 младших битов. Он содержит ту информацию, из-за которой все эти преобразования форматов, собственно, и были затеяны: в нем указано, какой виртуальной сети принадлежит кадр. Трехбитовое поле Приоритет не имеет совершенно ничего общего с виртуальными сетями. Просто изменение формата Ethernet-кадра -- это такой ежедекадный ритуал, который занимает три года и исполняется какой-то сотней людей. Почему бы не оставить память о себе в виде трех дополнительных бит, да еще и с таким привлекательным назначением. Поле Приоритет позволяет различать трафик с жесткими требованиями к реальности масштаба времени, трафик со средними требованиями и трафик, для которого время передачи не критично. Это позволяет обеспечить более высокое качество обслуживания в Ethernet. Оно используется также при передаче голоса по Ethernet (хотя вот уже четверть века в IP имеется подобное поле, и никому никогда не требовалось его использовать). Последний бит, CFI (Canonical Format Indicator -- индикатор классического формата), следовало бы назвать Индикатором эгоизма компании. Изначально он предназначался для того, чтобы показывать, что применяется формат МАС-адреса с прямым порядком байтов (или, соответственно, с обратным порядком), однако в пылу дискуссий об этом как-то забыли. Его присутствие сейчас означает, что поле данных содержит усохший кадр 802.5, который ищет еще одну сеть формата 802.5 и в Ethernet попал совершенно случайно. То есть на самом деле он просто использует Ethernet в качестве средства передвижения. Все это, конечно, практически никак не связано с обсуждаемыми в данном разделе виртуальными сетями. Но политика комитета стандартизации не сильно отличается от обычной политики: если ты проголосуешь за введение в формат моего бита, то я проголосую за твой бит. Как уже упоминалось ранее, когда кадр с флагом виртуальной сети приходит на ВЛВС-совместимый коммутатор, последний использует идентификатор виртуальной сети в качестве индекса таблицы, в которой он ищет, на какой бы порт послать кадр. Но откуда берется эта таблица? Если она разрабатывается вручную, это означает возврат в исходную точку: ручное конфигурирование коммутаторов. Вся прелесть прозрачности мостов состоит в том, что они настраиваются автоматически и не требуют для этого никакого вмешательства извне. Было бы очень стыдно потерять это свойство. К счастью, мосты для виртуальных сетей также являются самонастраивающимися. Настройка производится на основе информации, содержащейся во флагах приходящих кадров. Если кадр, помеченный как ВЛВС 4, приходит на порт 3, значит, несомненно, одна из машин, подключенных к этому порту, находится в виртуальной сети 4. Стандарт 802.1Q вполне четко поясняет, как строятся динамические таблицы. При этом делаются ссылки на соответствующие части алгоритма Перлмана (Perlman), который вошел в стандарт 802.ID. Прежде чем завершить разговор о маршрутизации в виртуальных сетях, необходимо сделать еще одно замечание. Многие пользователи сетей Интернет и Ethernet фанатично привязаны к сетям без установления соединения и неистово противопоставляют их любым системам, в которых есть хотя бы намек на соединение на сетевом уровне или уровне передачи данных. Однако в виртуальных сетях один технический момент как-раз-таки очень сильно напоминает установку соединения. Речь идет о том, что работа виртуальной сети невозможна без того, чтобы в каждом кадре был идентификатор, использующийся в качестве индекса таблицы, встроенной в коммутатор. По этой таблице определяется дальнейший вполне определенный маршрут кадра. Именно это и происходит в сетях, ориентированных на соединение. В системах без установления соединения маршрут определяется по адресу назначения, и там отсутствуют какие-либо идентификаторы конкретных линий, через которые должен пройти кадр.

Функциональные возможности современных коммутаторов позволяют организовывать виртуальные сети (VLAN-сетей) для создания гибкой сетевой инфраструктуры. В настоящее время VLAN-сети еще не получили широкого распространения, особенно в небольших корпоративных сетях. Во многом это связано с тем, что конфигурирование коммутаторов для организации VLAN-сетей весьма непростое дело, особенно если инфраструктура сети включает несколько коммутаторов. Кроме того, конфигурирование коммутаторов при создании VLAN-сетей, равно как и настройка других функциональных возможностей, может значительно отличаться у коммутаторов от различных фирм, вследствие чего известные производители сетевого оборудования, такие как Cisco, HP, 3Com, Allied Telesyn, Avaya, устраивают специальные курсы по работе с их оборудованием. Понятно, что упрощать конфигурирование своего оборудования, делать этот процесс интуитивно понятным и простым и уж тем более вырабатывать общие соглашения и единый интерфейс по настройке оборудования от разных производителей — явно не в интересах самих производителей, однако пользователи вполне способны самостоятельно разобраться во многих возможностях коммутаторов. Поэтому в данной статье мы рассмотрим возможности современных коммутаторов по организации виртуальных сетей и расскажем о базовых принципах их конфигурирования.

Назначение виртуальных сетей

иртуальной сетью VLAN (Virtual LAN) называют группу узлов сети, образующих домен широковещательного трафика (Broadcast Domain). Такое определение вполне корректно, но малоинформативно, так что попытаемся трактовать понятие виртуальной сети несколько иначе.

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

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

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

Типы виртуальных сетей

о появления общепризнанного стандарта по организации виртуальных сетей IEEE 802.1Q каждый производитель сетевого оборудования использовал собственную технологию организации VLAN. Такой подход имел существенный недостаток — технологии одного производителя были несовместимы с технологиями других фирм. Поэтому при построении виртуальных сетей на базе нескольких коммутаторов необходимо было использовать только оборудование от одного производителя. Принятие стандарта виртуальных сетей IEEE 802.1Q позволило преодолеть проблему несовместимости, однако до сих пор существуют коммутаторы, которые либо не поддерживают стандарт IEEE 802.1Q, либо, кроме возможности организации виртуальных сетей по стандарту IEEE 802.1Q, предусматривают и иные технологии.

Существует несколько способов построения виртуальных сетей, но сегодня в коммутаторах главным образом реализуется технология группировки портов или используется спецификация IEEE 802.1Q.

Виртуальные сети на основе группировки портов

иртуальные сети на основе группировки портов (Port-based) обычно реализуются в так называемых Smart-коммутаторах или в управляемых коммутаторах — как дополнение к возможности организации VLAN на базе стандарта IEEE 802.1Q.

Данный способ создания виртуальных сетей достаточно прост и, как правило, не вызывает проблем. Каждый порт коммутатора приписывается к той или иной виртуальной сети, то есть порты группируются в виртуальные сети. Решение о продвижении сетевого пакета в этой сети основывается на MAC-адресе получателя и ассоциированного с ним порта. Если к порту, которому назначена принадлежность к определенной виртуальной сети, например к VLAN#1, подключить ПК пользователя, то этот ПК автоматически будет принадлежать сети VLAN#1. Если же к данному порту подключается коммутатор, то все порты этого коммутатора также будут принадлежать VLAN#1 (рис. 1).

Рис. 1. Виртуальные сети, построенные с использованием технологии группировки портов на базе одного коммутатора

При использовании технологии группировки портов один и тот же порт может быть одновременно приписан к нескольким виртуальным сетям, что позволяет реализовывать разделяемые ресурсы между пользователями различных виртуальных сетей. Например, чтобы реализовать совместный доступ к сетевому принтеру или к файл-серверу пользователей виртуальных сетей VLAN#1 и VLAN#2, тот порт коммутатора, к которому подключается сетевой принтер или файл-сервер, нужно приписать одновременно к сетям VLAN#1 и VLAN#2 (рис. 2).

Рис. 2. Создание разделяемого ресурса между несколькими виртуальными сетями с использованием технологии группировки портов

Описываемая технология обладает рядом преимуществ в сравнении с использованием стандарта IEEE 802.1Q, но имеет и свои недостатки.

К достоинствам можно отнести простоту конфигурации виртуальных сетей. Кроме того, при этом не требуется, чтобы конечные узлы сети поддерживали стандарт IEEE 802.1Q, а поскольку большинство сетевых контроллеров Ethernet не поддерживают этот стандарт, то организация сети на основе группировки портов может оказаться проще. К тому же при подобной организации виртуальных сетей они могут пересекаться, что позволяет создавать разделяемые сетевые ресурсы.

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

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

Рис. 3. Реализация виртуальных сетей на основе группировки портов при использовании двух коммутаторов

Пусть необходимо, чтобы часть портов первого и второго коммутаторов относилась к VLAN#1, а другая часть — к VLAN#2. Для этого нужно, во-первых, чтобы оба коммутатора позволяли не только организовывать виртуальные сети на основе группировки портов, но и распространять такие сети на несколько коммутаторов (подобная функция реализована далеко не у всех коммутаторов), во-вторых, чтобы между коммутаторами было установлено столько физических соединений, сколько создано виртуальных сетей. Рассмотрим два шестипортовых коммутатора. Пусть в первом коммутаторе порты 1 и 2 относятся к VLAN#1, а порты 3 и 4 — к VLAN#2; во втором коммутаторе порты 1, 2 и 3 относятся к VLAN#1, а порт 4 — к VLAN#2. Чтобы пользователи VLAN#1 первого коммутатора могли общаться с пользователями VLAN#1 второго коммутатора, эти коммутаторы должны быть связаны между собой портами, относящимися к VLAN#1 (например, порт 5 первого и второго коммутаторов необходимо приписать к VLAN#1). Аналогично, для общения пользователей VLAN#2 первого коммутатора с пользователями VLAN#2 второго коммутатора следует связать эти коммутаторы через порты, приписанные к VLAN#2 (это могут быть порты 6 на обоих коммутаторах). Таким образом, проблема масштабируемости виртуальных сетей на основе технологии группировки портов решается (правда, не во всех случаях) за счет установления избыточных связей между коммутаторами.

Виртуальные сети на основе стандарта IEEE 802.1Q

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

К кадру Ethernet добавляется метка (Tag) длиной 4 байта — такие кадры называют кадрами с метками (Tagged frame). Дополнительные биты содержат информацию по принадлежности кадра Ethernet к виртуальной сети и о его приоритете (рис. 4).

Добавляемая метка кадра включает в себя двухбайтовое поле TPID (Tag Protocol Identifier) и двухбайтовое поле TCI (Tag Control Information). Поле TCI, в свою очередь, состоит из полей Priority, CFI и VID. Поле Priotity длиной 3 бита задает восемь возможных уровней приоритета кадра. Поле VID (VLAN ID) длиной 12 бит является идентификатором виртуальной сети. Эти 12 бит позволяют определить 4096 различных виртуальных сетей, однако идентификаторы 0 и 4095 зарезервированы для специального использования, поэтому всего в стандарте 802.1Q возможно определить 4094 виртуальные сети. Поле CFI (Canonical Format Indicator) длиной 1 бит зарезервировано для обозначения кадров сетей других типов (Token Ring, FDDI), передаваемых по магистрали Ethernet, и для кадров Ethernet всегда равно 0.

Изменение формата кадра Ethernet приводит к тому, что сетевые устройства, не поддерживающие стандарт IEEE 802.1Q (такие устройства называют Tag-unaware), не могут работать с кадрами, в которые вставлены метки, а сегодня подавляющее большинство сетевых устройств (в частности, сетевые Ethernet-контроллеры конечных узлов сети) не поддерживают этот стандарт. Поэтому для обеспечения совместимости c устройствами, поддерживающими стандарт IEEE 802.1Q (Tag-aware-устройства), коммутаторы стандарта IEEE 802.1Q должны поддерживать как традиционные Ethernet-кадры, то есть кадры без меток (Untagged), так и кадры с метками (Tagged).

Входящий и исходящий трафики, в зависимости от типа источника и получателя, могут быть образованы и кадрами типа Tagged, и кадрами типа Untagged — только в этом случае можно достигнуть совместимости с внешними по отношению к коммутатору устройствами. Трафик же внутри коммутатора всегда образуется пакетами типа Tagged. Поэтому для поддержки различных типов трафиков и для того, чтобы внутренний трафик коммутатора образовывался из пакетов Tagged, на принимаемом и передающем портах коммутатора кадры должны преобразовываться в соответствии с предопределенными правилами.

Правила входящего порта (Ingress rules)

Рассмотрим более подробно процесс передачи кадра через коммутатор (рис. 5). По отношению к трафику каждый порт коммутатора может быть как входным, так и выходным. После того как кадр принят входным портом коммутатора, решение о его дальнейшей обработке принимается на основании предопределенных правил входного порта (Ingress rules). Поскольку принимаемый кадр может относиться как к типу Tagged, так и к типу Untagged, то правилами входного порта определяется, какие типы кадров должны приниматься портом, а какие отфильтровываться. Возможны следующие варианты: прием только кадров типа Tagged, прием только кадров типа Untagged, прием кадров обоих типов. По умолчанию для всех коммутаторов правилами входного порта устанавливается возможность приема кадров обоих типов.

Рис. 5. Процесс продвижения кадров в коммутаторе, совместимом со стандартом IEEE 802.1Q

Если правилами входного порта определено, что он может принимать кадр Tagged, в котором имеется информация о принадлежности к конкретной виртуальной сети (VID), то этот кадр передается без изменения. А если определена возможность работы с кадрами типа Untagged, в которых не содержится информации о принадлежности к виртуальной сети, то прежде всего такой кадр преобразуется входным портом коммутатора к типу Tagged (напомним, что внутри коммутатора все кадры должны иметь метки о принадлежности к виртуальной сети).

Чтобы такое преобразование стало возможным, каждому порту коммутатора присваивается уникальный PVID (Port VLAN Identifier), определяющий принадлежность порта к конкретной виртуальной сети внутри коммутатора (по умолчанию все порты коммутатора имеют одинаковый идентификатор PVID=1). Кадр типа Untagged преобразуется к типу Tagged, для чего дополняется меткой VID (рис. 6). Значение поля VID входящего Untagged-кадра устанавливается равным значению PVID входящего порта, то есть все входящие Untagged-кадры автоматически приписываются к той виртуальной сети внутри коммутатора, к которой принадлежит входящий порт.

Правила продвижения пакетов (Forwarding Process)

После того как все входящие кадры отфильтрованы, преобразованы или оставлены без изменения в соответствии в правилами входящего порта, решение об их передаче к выходному порту основывается на предопределенных правилах продвижения пакетов. Правило продвижения пакетов внутри коммутатора заключается в том, что пакеты могут передаваться только между портами, ассоциированными с одной виртуальной сетью. Как уже отмечалось, каждому порту присваивается идентификатор PVID, который используется для преобразования принимаемых Untagged-кадров, а также для определения принадлежности порта к виртуальной сети внутри коммутатора с идентификатором VID=PVID. Таким образом, порты с одинаковыми идентификаторами внутри одного коммутатора ассоциируются с одной виртуальной сетью. Если виртуальная сеть строится на базе одного коммутатора, то идентификатора порта PVID, определяющего его принадлежность к виртуальной сети, вполне достаточно. Правда, создаваемые таким образом сети не могут перекрываться, поскольку каждому порту коммутатора соответствует только один идентификатор. В этом смысле создаваемые виртуальные сети не обладали бы такой гибкостью, как виртуальные сети на основе портов. Однако стандарт IEEE 802.1Q с самого начала задумывался для построения масштабируемой инфраструктуры виртуальных сетей, включающей множество коммутаторов, и в этом состоит его главное преимущество по сравнению с технологией образования VLAN на основе портов. Но для того, чтобы расширить сеть за пределы одного коммутатора, одних идентификаторов портов недостаточно, поэтому каждый порт может быть ассоциирован с несколькими виртуальными сетями, имеющими различные идентификаторы VID.

Если адрес назначения пакета соответствует порту коммутатора, который принадлежит к той же виртуальной сети, что и сам пакет (могут совпадать VID пакета и VID порта или VID пакета и PVID порта), то такой пакет может быть передан. Если же передаваемый кадр принадлежит к виртуальной сети, с которой выходной порт никак не связан (VID пакета не соответствует PVID/VID порта), то кадр не может быть передан и отбрасывается.

Правила выходного порта (Egress rules)

После того как кадры внутри коммутатора переданы на выходной порт, их дальнейшее преобразование зависит от правил выходного порта. Как уже говорилось, трафик внутри коммутатора создается только пакетами типа Tagged, а входящий и исходящий трафики могут быть образованы пакетами обоих типов. Соответственно правилами выходного порта (правило контроля метки — Tag Control) определяется, следует ли преобразовывать кадры Tagged к формату Untagged.

Каждый порт коммутатора может быть сконфигурирован как Tagged или Untagged Port. Если выходной порт определен как Tagged Port, то исходящий трафик будет создаваться кадрами типа Tagged с информацией о принадлежности к виртуальной сети. Следовательно, выходной порт не меняет тип кадров, оставляя их такими же, какими они были внутри коммутатора. К указанному порту может быть подсоединено только устройство, совместимое со стандартом IEEE 802.1Q, например коммутатор или сервер с сетевой картой, поддерживающей работу с виртуальными сетями данного стандарта.

Если же выходной порт коммутатора определен как Untagged Port, то все исходящие кадры преобразуются к типу Untagged, то есть из них удаляется дополнительная информация о принадлежности к виртуальной сети. К такому порту можно подключать любое сетевое устройство, в том числе коммутатор, не совместимый со стандартом IEEE 802.1Q, или ПК конечных клиентов, сетевые карты которых не поддерживают работу с виртуальными сетями этого стандарта.

Конфигурирование виртуальных сетей стандарта IEEE 802.1Q

Рассмотрим конкретные примеры конфигурирования виртуальных сетей стандарта IEEE 802.1Q.

Чтобы сформировать VLAN-сеть в соответствии со стандартом IEEE 802.1Q, необходимо проделать следующие действия:

• задать имя виртуальной сети (например, VLAN#1) и определить ее идентификатор (VID);
• выбрать порты, которые будут относиться к данной виртуальной сети;
• задать правила входных портов виртуальной сети (возможность работы с кадрами всех типов, только с кадрами Untagged или только с кадрами Tagged);
• установить одинаковые идентификаторы PVID портов, входящих в виртуальную сеть;
• задать для каждого порта виртуальной сети правила выходного порта, сконфигурировав их как Tagged Port или Untagged Port.

Далее необходимо повторить вышеперечисленные действия для следующей виртуальной сети. При этом нужно помнить, что каждому порту можно задать только один идентификатор PVID, но один и тот же порт может входить в состав различных виртуальных сетей, то есть ассоциироваться одновременно с несколькими VID.

Таблица 1. Задание характеристик портов при создании виртуальных сетей на базе одного коммутатора

Примеры построения VLAN-сетей на основе коммутаторов, совместимых со стандартом IEEE 802.1Q

А теперь рассмотрим типичные примеры построения виртуальных сетей на основе коммутаторов, поддерживающих стандарт IEEE 802.1Q.

Если имеется всего один коммутатор, к портам которого подключаются компьютеры конечных пользователей, то для создания полностью изолированных друг от друга виртуальных сетей все порты должны быть объявлены как Untagget Ports для обеспечения совместимости с сетевыми Ethernet-контроллерами клиентов. Принадлежность узлов сети к той или иной VLAN определяется заданием идентификатора порта PVID.

Возьмем восьмипортовый коммутатор, на базе которого создаются три изолированные виртуальные сети VLAN#1, VLAN#2 и VLAN#3 (рис. 7). Первому и второму портам коммутатора присваивается идентификатор PVID=1. Поскольку идентификаторы этих портов совпадают с идентификатором первой виртуальной сети (PVID=VID), то данные порты образуют виртуальную сеть VLAN#1 (табл. 1). Если портам 3, 5 и 6 присвоить PVID=2 (совпадает с идентификатором VID VLAN#2), то вторая виртуальная сеть будет образована портами 3, 4 и 8. Аналогично формируется и VLAN#3 на базе портов 5, 6 и 7. Для обеспечения совместимости с конечным оборудованием (предполагается, что к портам коммутатора подключаются ПК клиентов сети, сетевые карты которых не совместимы со стандартом IEEE 802.1Q) все порты необходимо сконфигурировать как Untagged.

Рис. 7. Организация трех сетей VLAN по стандарту IEEE 802.1Q на основе одного коммутатора

Если инфраструктура сети включает несколько коммутаторов, поддерживающих стандарт IEEE 802.1Q, то для связи коммутаторов друг с другом необходимо использовать несколько иной принцип конфигурирования. Рассмотрим два шестипортовых коммутатора, которые поддерживают стандарт IEEE 802.1Q и на основе которых необходимо сконфигурировать три изолированные друг от друга виртуальные сети VLAN#1, VLAN#2 и VLAN#3.

Пусть к первой виртуальной сети относятся клиенты, подключенные к портам 1 и 2 первого коммутатора и к портам 5 и 6 второго коммутатора. К сети VLAN#2 относятся клиенты, подключенные к порту 3 первого коммутатора и порту 1 второго коммутатора, а к сети VLAN#3 относятся клиенты, подключенные к портам 4 и 5 первого коммутатора и портам 2 и 3 второго коммутатора. Порт 6 первого коммутатора и порт 4 второго коммутатора используются для связи коммутаторов друг с другом (рис. 8).

Рис. 8. Организация трех VLAN-сетей по стандарту IEEE 802.1Q на основе двух коммутаторов

Чтобы сконфигурировать указанные виртуальные сети, необходимо прежде всего определить на каждом из коммутаторов по три виртуальные сети VLAN#1, VLAN#2 и VLAN#3, задав их идентификаторы (VID=1 для VLAN#1, VID=2 для VLAN#2 и VID=3 для VLAN#3).

На первом коммутаторе порты 1 и 2 должны входить в состав VLAN#1, для чего этим портам присваивается PVID=1. Порт 2 первого коммутатора необходимо приписать к VLAN#2, для чего идентификатору порта присваивается значение PVID=2. Аналогично, для портов 5 и 6 первого коммутатора устанавливаются идентификаторы PVID=3, так как эти порты относятся к VLAN#3. Все указанные порты первого коммутатора должны быть сконфигурированы как Untagged Port для обеспечения совместимости с сетевыми картами клиентов.

Порт 4 первого коммутатора используется для связи со вторым коммутатором и должен передавать кадры всех трех виртуальных сетей без изменения второму коммутатору. Поэтому его необходимо сконфигурировать как Tagged Port и включить в состав всех трех виртуальных сетей (ассоциировать с VID=1, VID=2 и VID=3). При этом идентификатор порта не имеет значения и может быть любым (в нашем случае PVID=4).

Аналогичная процедура конфигурации виртуальных сетей осуществляется и на втором коммутаторе. Конфигурации портов двух коммутаторов представлены в табл. 2.

Таблица 2. Задание характеристик портов при создании виртуальных сетей на основе двух коммутаторов

Автоматическая регистрация в виртуальных сетях стандарта IEEE 802.1Q

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

Существует и альтернативный способ конфигурирования виртуальных сетей, а создаваемые при этом сети называются динамическими виртуальными сетями (Dynamic VLAN). В таких сетях пользователи могут автоматически регистрироваться в сети VLAN, для чего служит специальный протокол регистрации GVRP (GARP VLAN Registration Protocol). Этот протокол определяет способ, посредством которого коммутаторы обмениваются информацией о сети VLAN, чтобы автоматически зарегистрировать членов VLAN на портах во всей сети.

Все коммутаторы, поддерживающие функцию GVRP, могут динамически получать от других коммутаторов (и, следовательно, передавать другим коммутаторам) информацию VLAN о регистрации, включающую данные об элементах текущей VLAN, о порте, через который можно осуществлять доступ к элементам VLAN и т.д. Для связи одного коммутатора с другим в протоколе GVRP используется сообщения GVRP BPDU (GVRP Bridge Protocol Data Units). Любое устройство с поддержкой протокола GVPR, получающее такое сообщение, может динамически подсоединяться к той сети VLAN, о которой оно оповещено.

802.1x - это стандарт, который используется для аутентификации и авторизации пользователей и рабочих станций в сети передачи данных. Благодаря стандарту 802.1x можно предоставить пользователям права доступа к корпоративной сети и ее сервисам в зависимости от группы или занимаемой должности, которой принадлежит тот или иной пользователь. Так, подключившись к беспроводной сети или к сетевой розетке в любом месте корпоративной сети, пользователь будет автоматически помещен в тот VLAN, который предопределен политиками группы, к которой привязана учетная запись пользователя или его рабочей станции в AD. К данному VLAN будет привязан соответствующий список доступа ACL (статический, либо динамический, в зависимости от прав пользователя) для контроля доступа к корпоративным сервисам. Кроме списков доступа, к VLAN можно привязать политики QoS для контроля полосы пропускания.

Я по большей части специалист по Cisco и хочу рассказать об одной из многих моделей функционирования IEEE 802.1x в сети передачи данных, построенной на оборудовании Cisco Systems.

Для того, чтобы реализовать данную модель потребуется минимальный набор следующих компонентов:

• коммутатор, который будет выступать в роли аутентификатора;
• сервер аутентификации (RADIUS сервер);
• DHCP сервер;
• суппликант (клиент) 802.1x на рабочей станции пользователя;

Для расширенного функционала не лишними окажутся:

• сервер хранения учетных данных пользователей (AD, Samba и пр.);
• серверы сертификатов.

Родной клиент 802.1x присутствует во многих операционных системах, таких как Windows XP/Vista/7/CE/Mobile, Linux, Solaris, Apple OS X, и др. Но, как показывает практика, зоопарк операционных систем, под управлением которых работают пользовательские рабочие станции, а следовательно и обилие встроенных разношерстных суппликантов в них не облегчает, а наоборот в несколько раз усложняет внедрение и дальнейшее использование стандарта 802.1x в компании. Чтобы облегчить свою учесть, желательно использовать унифицированный сторонний клиент, который вам больше понравится, такой, который бы работал под всеми ОС, которые установлены на рабочих станциях ваших пользователей.

Я бы не стал рекомендовать к использованию бесплатные суппликанты, которые распространяются в сети, т.к. на практике они оказались не достаточно функциональны. Что касается клиента Cisco Secure Services Client, предлагаемого компанией Cisco Systems, то он, к сожалению, более не поддерживается, о чем говорит цитата с их официального сайта: «Cisco announces the end-of-sale and end-of life dates for the Cisco Secure Services Client. The last day to order the affected product(s) is January 27, 2012 ». От себя добавлю, что мне очень понравился Juniper Networks Odyssey Access Client , используя который можно преднастроить его как вам угодно, создать файл инсталляционного пакета MSI и централизованно развернуть на пользовательских рабочих станциях.

Для демонстрации работы стандарта IEEE 802.1x, далее приведу диаграмму процесса авторизации в упрощенном виде, где цифрами указан номер шага:

В наше время сложно представить компанию, информационная инфраструктура которой не была бы управляемой. Под управляемой инфраструктурой я понимаю доменную сеть. При использовании стандарта 802.1x в доменной среде необходимо учитывать один нюанс - нельзя проводить авторизацию в сети передачи данных только по учетной записи пользователя! Все дело в том, что при загрузке, прежде чем вывести окно авторизации пользователя, рабочая станция должна пройти несколько этапов:

1. Получить IP адрес;
2. Определить сайт и контроллер домена;
3. Установить безопасный туннель до AD, используя протоколы LDAP, SMB;
4. Авторизоваться в домене, используя учетную запись рабочей станции по протоколу Kerberos;
5. Загрузить GPO;
6. Запустить скрипты, предписанные GPO на рабочую станцию.

Всего это не случиться, если проводить авторизацию только по учетной записи пользователя. А причина проста, неавторизованная рабочая станция при загрузке не будет допущена к сети передачи данных, все протоколы кроме EAPoL, которые обычно используются для нормального функционирования, будут заблокированы до момента авторизации. Следовательно, если до момента логина пользователя, станция не была авторизована в сети, групповые политики к ней применены не будут. Если вы работаете в доменной среде, обязательно нужно в первую очередь авторизовать в сети рабочую станцию, чтобы она прошла через все вышеперечисленные этапы. Что делать после авторизации рабочей станции решать уже вам, но есть два варианта:

1. Оставить как есть;
2. Провести дополнительную авторизацию по учетным данным пользователя.

Допустим вы решили сперва авторизовать рабочую станцию, а затем пользователя по его учетным данным в AD. С одной стороны подход правильный, но с другой возникают следующие проблемы:

1. Если вы используете быструю оптимизацию процедуры регистрации (Fast Logon Optimization), тогда групповые политики и скрипты не успеют примениться на рабочей станции до того, как пользователь будет авторизован и перемещен в другой VLAN с последующей сменой IP адреса.
2. Если вы отключили Fast Logon Optimization, тогда может случиться такая неприятная ситуация, когда групповых политик и скриптов достаточно много, а пользователь на столько быстр, что успел ввести свои учетные данные и попасть в свой VLAN со сменой IP адреса, тогда процесс корректного включения рабочей станции будет прерван.
3. Если вы используете авторизацию по учетным данным пользователя, то не исключены проблемы с удаленным подключением к рабочей станции администратором. Возможна смена VLAN, а с ним и IP адреса при подключении другого пользователя.

Самым беспроигрышным и безопасным вариантом будет авторизация рабочей станции в сети по сертификату без авторизации пользователя. Конечно, это не значит, что нужно навсегда отказаться от авторизации пользователя. Просто для этого необходимо подойти к процессу авторизации несколько с другой стороны – если до этого мы говорили про процедуру смены VLAN (динамический VLAN) в качестве основного разделителя прав пользователей, то в данном случае нам поможет динамический список доступа. В результате, вместо смены VLAN и IP адреса, изменятся правила ACL конкретного VLAN в соответствии с правами доступа конкретного пользователя. К сожалению, такая функция доступна не везде, но, по крайней мере, она есть на сервере контроля доступа ACS версии 5.2.

Кстати говоря, здесь я хотел бы рассмотреть некоторые логические элементы взаимосвязи между сервером контроля доступа ACS, он же Cisco Access Control Server, он же RADIUS сервер, и хранилищем учетных данных, например, Active Directory. На сервере ACS устанавливаются взаимоотношения с AD по типу:

Группа объектов ACS = Группе объектов AD

Права доступа для объектов конкретной группы устанавливаются на ACS. Логика работы получается следующая:

1. Приходит запрос на проверку авторизационных данных;
2. ACS обращается к серверу AD с вопросом кто это такой и в какой группе AD он находится;
3. AD сообщает что это такой-то объект и он находится у меня в такой-то группе;
4. ACS сопоставляет имя группы AD и локально-созданную группу с политиками доступа на ACS, которой она соответствует;
5. Если соответствие найдено, ACS сообщает коммутатору, какие правила доступа применить на порт согласно заданным критериями безопасности на ACS для этой группы.

Если соответствие не найдено или сервер AD сообщил, что авторизационные данные недействительны, коммутатор помещает порт в гостевой VLAN.

1. Не включен клиент 802.1x . В том случае, когда клиент не активен, рабочая станция не может идентифицировать себя, она автоматически помещается в гостевой VLAN с ограниченным доступом к сети передачи данных. Процесс выполнения данной функции представлен на рисунке:

2. Клиент 802.1x включен, но настроен неверно . В том случае, когда клиент не может корректно идентифицировать себя, рабочая станция автоматически помещается в гостевой VLAN с ограниченным доступом. Процесс выполнения данной функции представлен на рисунке:

3. RADIUS сервер недоступен . Для повышения отказоустойчивости в случае выхода из строя сервера аутентификации, рабочая станция помещается в Failover VLAN с минимально необходимыми для выполнения работы правами доступа к сети передачи данных:

Здесь же отмечу, что с определением недоступности сервера RADIUS компания Cisco Systems дала маху, а именно, по истечении deadtime таймера, коммутатор считает мертвый сервер RADIUS живым и, если он настроен, то запускает процесс переавторизации всех пользователей, подключенных к нему. Не трудно представить, как начинает «колбасить» пользователей, когда их заставили пройти авторизацию заново, в то время как сервер RADIUS до сих пор мертв, хотя коммутатор считает его живым. В итоге рабочие станции не могут авторизоваться вообще ни в одном VLAN-е, они остаются подвешенными в воздухе, отрезанными от сети, они не могут попасть ни в гостевой VLAN ни в Failover VLAN.
Данная ошибка официально признана Cisco, ее описание можно найти на их сайте:

"CSCir00551 - Misleading radius debug message
Description
Symptom:
The "%RADIUS-4-RADIUS_ALIVE: RADIUS server 172.27.66.89:2295,2296 has returned."
is a little misleading. It is not saying that the server has returned, in the
sense of being heard from. It is only saying that RADIUS has marked the server
as being alive because the deadtime timer has expired, and RADIUS is willing to
re-send messages to this server again.
Conditions:
None
Workaround:
None "

Подвержены данной ошибке все операционные системы коммутаторов, вплоть до самых последних версий, которые мне удалось проверить. Кроме того все они перечислены в списке affected ОС на официальном сайте Cisco. Почему до сих пор не исправили эту ошибку, остается только загадкой.

Для реализации всего вышеперечисленного необходимо проделать много работы, очень много, начиная с настройки сервера ACS, серверов сертификатов, AD, DHCP, коммутаторов доступа и заканчивая настройкой суппликантов на рабочих станциях и выдачей им сертификатов.

Здесь же остановимся на настройке только коммутаторов. Настройки будут различаться в зависимости от новизны IOS.

Старый IOS

Aaa new-model


radius-server host 192.168.20.20 auth-port 1645 acct-port 1646 key SecretSharedKey123
radius-server source-ports 1645-1646

radius-server deadtime 30
dot1x system-auth-control

1. Общие команды:

switchport mode access
dot1x pae authenticator
dot1x port-control auto


dot1x timeout tx-period 5
spanning-tree portfast
end

2. Гостевой VLAN:

Interface GigabitEthernet1/0/1



end

3. Failover VLAN:

Interface GigabitEthernet1/0/1
dot1x critical

end

Все вместе:

Interface GigabitEthernet1/0/1
switchport mode access
dot1x critical
dot1x pae authenticator
dot1x port-control auto
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x timeout reauth-period server
dot1x timeout tx-period 5
dot1x reauthentication
dot1x guest-vlan 1 //гостевой VLAN
dot1x auth-fail vlan 1 //auth-fail VLAN
dot1x auth-fail max-attempts 2
dot1x critical vlan 150 //failover VLAN
spanning-tree portfast
end

Новый IOS

Для настройки связи с сервером RADIUS необходимы следующие команды в режиме глобальной конфигурации:

Aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
radius-server dead-criteria time 5 tries 4
radius-server deadtime 30
radius-server host 192.168.20.20 key SecretSharedKey123
dot1x system-auth-control

Для настройки отдельного порта, используются следующие команды:

1. Общие команды:

Interface GigabitEthernet1/0/1
switchport mode access


dot1x pae authenticator
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x timeout tx-period 5
spanning-tree portfast
end

2. Гостевой VLAN:

authentication event no-response action authorize vlan 1

3. Failover VLAN:

Все вместе:
interface GigabitEthernet0/2
switchport mode access
authentication event fail action authorize vlan 1
authentication event server dead action authorize vlan 150
authentication event no-response action authorize vlan 1
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication violation protect
dot1x pae authenticator
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x timeout tx-period 5
spanning-tree portfast
end

В заключение, хочу отметить, что рассказывать про принципы работы стандарта 802.1x можно намного дольше, больше и глубже. В данном материале я постарался изложить самые основные, элементарные принципы работы с данным стандартом. В свое время мне бы подобный материал очень пригодился как отправная точка для его будущего изучения.

Часть IV

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

Стандарты IEEE 802.1Q и IEEE 802.1р

Задача рабочих групп, трудящихся над стандартами p и Q, - дать сетевой отрасли единый метод передачи по сети информации о приоритете кадра и его принадлежности к ВЛВС. Были разработаны две спецификации маркировки пакетов:

• первая, одноуровневая, определяет взаимодействие виртуальных сетей по магистрали Fast Ethernet;
• вторая, двухуровневая, касается маркировки пакетов в смешанных магистралях, включая Token Ring и FDDI.

Первая спецификация с самого начала нуждалась лишь в минимальной доработке, так как она, по сути, представляет собой технологию тэговой коммутации, продвигаемую на рынок усилиями Cisco. Задержки с принятием стандарта 802.1Q объясняются необходимостью детальной проработки куда более сложной «двухуровневой» спецификации.

Стандарт должен был удовлетворять следующим достаточно высоким требованиям:

• масштабируемости на уровне обмена пакетами между коммутаторами;
• преемственности на уровне существующих конечных приложений;
• адаптации на уровне существующих протоколов и таблиц маршрутизации;
• экономичности в плане утилизации высокоскоростных магистралей;
• совместимости с ATM, особенно с эмуляцией ЛВС;
• управляемости процесса маркировки пакетов.

В соответствии со стандартом 802.1Q к кадру Ethernet добавлены четыре байта. Эти 32 бита содержат информацию по принадлежности кадра Ethernet к ВЛВС и о его приоритете. Говоря точнее, тремя битами кодируется до восьми уровней приоритета, 12 бит позволяют различать трафик до 4096 ВЛВС, один бит зарезервирован для обозначения кадров сетей других типов (Token Ring, FDDI), передаваемых по магистрали Ethernet, и т. д.

Поле идентификатора уровня приоритета дает возможность использовать восемь таких уровней, соответствующих системе приоритетов стандарта 802.1p.

В заголовке кадра Ethernet поля 802.1Q размещаются между адресом отправителя и полем с информацией о длине кадра полезной нагрузки 802.3 (кадр Ethernet) или о типе протокола более высокого уровня (кадр Ethernet II).

В настоящее время практически все сетевые фирмы уже создали коммерческие версии продуктов, поддерживающие стандарты 802.1p и 802.1Q. Кроме того, многие производители коммутаторов Ethernet уже реализовали службы приоритезации собственной разработки.

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

В самом деле, из-за того что данные 802.1Q размещаются перед полем с информацией о длине полезной нагрузки (или типе протокола), традиционный сетевой продукт не обнаружит эту информацию на привычном месте и вместо нее «прочитает» число x8100 - значение по умолчанию нового поля «Тэг протокольного идентификатора» (Tag Protocol Identifier) в кадрах 802.1Q.

Источником проблем является не только изменение в размещении полей заголовка кадра Ethernet, но и увеличение максимальной длины данного кадра. Многие сетевые устройства не способны обрабатывать кадры длиннее 1518 байт. Между специалистами возникли споры по поводу того, нужно ли максимальный размер кадра Ethernet удлинять на четыре байта или следует укоротить на четыре байта максимальный размер полезной нагрузки и таким образом компенсировать увеличение заголовка. Спецификация 802.1Q предусматривает оба подхода, поэтому производителям самим предстоит обеспечивать взаимную совместимость своих продуктов.

С технической точки зрения осуществить взаимодействие старого оборудования с 802.1Q-совместимыми современными устройствами несложно, и большинство производителей сумеют реализовать такую возможность в своих продуктах на уровне их портов. Для состыковки 802.1Q-совместимого устройства с прежним коммутатором или сетевой платой потребуется просто отключить поддержку стандарта 802.1Q на нужном порте, и весь трафик будет посылаться в сеть в обычном виде.

Приоритеты и классы обслуживания

Спецификация IEEE 802.1p, создаваемая в рамках процесса стандартизации 802.1Q, определяет метод передачи информации о приоритете сетевого трафика. Хотя в большинстве ЛВС редко случаются длительные перегрузки, отдельные всплески трафика представляют собой обычное явление и могут привести к задержкам передач пакетов. Это абсолютно неприемлемо для работы сетей, предназначенных для передачи голоса и видео. Стандарт 802.1p специфицирует алгоритм изменения порядка расположения пакетов в очередях, с помощью которого обеспечивается своевременная доставка трафика, чувствительного к временным задержкам.

Рабочая группа по стандартизации интегрированного обслуживания в сетях с разными канальными уровнями (ISSLL) определила ряд классов обслуживания в зависимости от того, какое время задержки допустимо для передачи пакета того или иного типа трафика. Представьте себе сеть с разными видами трафика: чувствительного к задержкам порядка 10 мс, не допускающего задержек более 100 мс и почти не чувствительного к задержкам. Для успешной работы такой сети каждый из этих типов трафика должен иметь свой уровень приоритета, обеспечивающий выполнение требований, предъявляемых к величине задержки. Используя концепцию протокола резервирования ресурсов (Resource Reservation Protocol - RSVP) и систему классов обслуживания, можно определить схему управления приоритетами. Протокол RSVP, который будет рассмотрен ниже, поддерживается большинством коммутирующих маршрутизаторов и, в частности, моделями SSR 8000/8600 производства Cabletron.

В дополнение к определению приоритетов стандарт 802.1p вводит важный протокол GARP (Generic Attributes Registration Protocol) с двумя специальными реализациями. Первая из них - протокол GMRP (GARP Multicast Registration Protocol), позволяющий рабочим станциям делать запрос на подключение к домену групповой рассылки сообщений. Поддерживаемую этим протоколом концепцию назвали подсоединением, инициируемым «листьями». Протокол GMRP обеспечивает передачу трафика только в те порты, из которых пришел запрос на групповой трафик, и хорошо согласуется со стандартом 802.1Q.

Второй реализацией GARP является протокол GVRP (GARP VLAN Registration Protocol), похожий на GMRP. Однако, работая по нему, рабочая станция вместо запроса на подключение к домену групповой рассылки сообщений посылает запрос на доступ к определенной ВЛВС. Данный протокол связывает стандарты p и Q.

С принятием предварительных вариантов стандартов 802.1Q и 802.1p появились все возможности для широкого использования средств приоритезации трафика в сетях Ethernet. Задействуя продукты, поддерживающие механизмы приоритезации, сетевые администраторы смогут распоряжаться коммутирующей инфраструктурой своей сети таким образом, чтобы, например, высший уровень приоритета получил трафик офисного пакета Lotus Notes и электронной почты, а аудиопотоки RealAudio - низший уровень. Механизмы приоритезации трафика, основанные на спецификациях 802.1Q и 802.1p, бесспорно, стали еще одним козырем технологии Ethernet.

Но хотя упомянутые спецификации и обеспечивают приоритезацию трафика для наиболее популярных топологий второго уровня, они не гарантируют того, что вся инфраструктура сети (от одной ее конечной точки до другой) будет поддерживать обработку приоритетного трафика. В частности, спецификации 802.1Q и 802.1p бесполезны при управлении приоритетом IP-трафика (трафика третьего уровня), передаваемого через низкоскоростную распределенную сеть или каналы доступа в Интернет, то есть через наиболее вероятные «узкие места» сетевой инфраструктуры.

Чтобы в полной мере управлять трафиком во всей сети, необходимо прежде всего реализовать эффективную приоритезацию IP-трафика. В связи с этим возникает ряд вопросов. Поддерживает ли локальная сеть механизмы такой приоритезации? А оборудование распределенной сети? Поддерживает ли эти механизмы ваш поставщик услуг Интернета? Что в связи с этим можно сказать об инфраструктуре на другом конце соединения? Если хотя бы одно устройство, находящееся между двумя системами, не поддерживает механизмы приоритезации, будет невозможно реализовать передачу приоритетного трафика от одного конечного узла сети до другого.

В отличие от технологии Ethernet, протокол IP уже довольно давно обладает средствами приоритезации сетевого трафика - впервые они были предложены в версии, опубликованной в 1981 году. Каждый IP-пакет имеет восьмибитовое поле «Тип сервиса» (Type of Service, ToS), состоящее из двух подполей (см. структуру заголовка пакета IP):

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

Три первых бита поля ToS позволяют устанавливать для IP-трафика те же восемь уровней приоритета (от 0 до 7), что и спецификации 802.1Q и 802.1p, а также большинство других технологий ЛВС. Поэтому можно взаимно однозначно отображать информацию о приоритетах кадров Ethernet и пакетов IP, а значит, реализовать сквозную обработку приоритетного трафика, передаваемого из одной сети Ethernet в другую через распределенную сеть IP или инфраструктуру поставщика услуг Интернета.

Четыре других используемых бита поля ToS позволяют администратору сети осуществлять индивидуальную маршрутизацию каждого пакета в соответствии с особенностями содержащихся в нем данных. Так, например, пакетам протокола NNTP (Network News Transfer Protocol), транспортирующим новости UseNet, можно установить класс обслуживания с низкой стоимостью («low cost», а пакетам Telnet - класс обслуживания с низкой задержкой «(low latency»).

Изначально стандарт RFC 791 (первоначальный вариант протокола IP) определял только три класса обслуживания, каждому из которых ставился в соответствие отдельный бит, устанавливаемый в «1» или «0» в зависимости от потребностей в том или ином типе обслуживания. С принятием стандарта RFC 1349 был добавлен еще один класс, и теперь ранее разобщенные четыре бита стали рассматриваться как единое целое. Поэтому сегодня с их помощью можно задавать максимум 16 значений (от 0 до 15).

Сетевые администраторы, управляющие сложными сетями с множеством маршрутов, могут использовать биты определения типа обслуживания в сочетании с такими протоколами маршрутизации, как OSPF, для создания специальных служб маршрутизации. Например, пакеты с «отметкой» low latency (низкая задержка) можно посылать не по спутниковому соединению, а по высокоскоростной оптической линии, тогда как «неприхотливый» трафик (класс обслуживания «low cost») направить через Интернет, а не через корпоративную распределенную сеть.

Комбинируя биты установки типа обслуживания с битами приоритета, можно очень точно задавать режимы обработки пакетов с конкретными типами данных, например: определить правила, в соответствии с которыми сетевые фильтры будут присваивать всем пакетам приложения Lotus Notes средний уровень приоритета и назначать класс обслуживания с низкой задержкой. При этом пользователи Notes получат льготное обслуживание по сравнению с пользователями других, менее важных приложений. Можно определить иной набор фильтров, который пометит весь трафик аудиоприложения RealAudio как низкоприоритетный и установит для него класс обслуживания с высокой пропускной способностью (high throughput).

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

Однако далеко не все зависит от сетевой инфраструктуры. В настоящее время имеются значительные проблемы, связанные с установкой битов приоритета и типа обслуживания в IP-пакетах. Эти биты могут быть установлены как самим приложением по мере формирования и отправки пакетов, так и сетевым устройством с помощью специальных фильтров. И в том и в другом случае поддержка этих функций всецело зависит от производителей приложений, операционных систем и сетевого оборудования.

Но удивительно, что лишь некоторые операционные системы используют в своих IP-стеках механизмы записи в пакет информации об уровне его приоритета и требуемом для него классе обслуживания. В прикладном программном интерфейсе WINSOCK.DLL, поставляемом вместе с Windows 95 и Windows NT, такие возможности вообще отсутствуют, так что попытки вызвать функцию «setsockopt (IP_TOS)» приводят к выдаче диагностического сообщения «invalid operation» («Недопустимая операция»). В других операционных системах, например в Irix, HP-UX и Solaris, реализована лишь частичная поддержка данных функций.

Среди всех операционных систем мощная поддержка функций ToS реализована только в Linux и Digital UNIX. Причем она имеется как непосредственно в самих системах, так и в наборах их стандартных приложений. Например, обе системы предоставляют клиенты и серверы Telnet, способные устанавливать бит low latency поля ToS - ни одна другая из протестированных нами операционных систем такими важными возможностями не обладает. Клиент и сервер FTP, работающие в среде Linux и Digital UNIX, способны устанавливать бит low latency в пакетах, передаваемых по каналу управления, а бит high throughput - в пакетах, передаваемых по информационному каналу. В итоге такая команда FTP, как abort operation (прервать команду), будет передана на сервер по самому скоростному маршруту и соответственно за минимальное время (оперативно отменив при этом загрузку файла с сервера).

Почему же лишь немногие приложения поддерживают функции байта ToS? Да потому, что большая часть операционных систем, в среде которых они работают, не обеспечивает надлежащую поддержку этих функций. И до тех пор, пока Microsoft не модифицирует программный интерфейс WINSOCK.DLL системы Windows NT, поставщики приложений вроде Lotus Development, Netscape Communications и Oracle не смогут реализовать в своих приложениях механизмы управления приоритетами.

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