Такие реальные виртуальные сети

LANE V1, V2... ЧТО ДАЛЬШЕ?
На пути к MPOA

СУЩЕСТВУЮЩИЕ АРХИТЕКТУРЫ VLAN

НЕ ТОЛЬКО АТМ
Стандарт IEEE 802.1Q

Вопрос о том, что первично: модели сетевых вычислений или архитектуры сетей, как и известный спор о курице и яйце, однозначно разрешить нельзя. Однако, конкретизируя период времени, доминирующую силу можно определить более-менее уверенно. Сегодня, например, движущей силой информационно-технического прогресса является стремление субъектов экономики к внедрению у себя на предприятиях максимально гибких структур управления производственными процессами. Усилиями выпускников передовых бизнес-школ определение (на бытовом уровне) узла информационной сети как "компьютера, определенным образом объединенного каналами передачи данных с другими компьютерами", трансформируется, скорее, в "сотрудника, определенным образом обменивающегося с коллегами потоками информации". Очевидно, что второе определение легко допускает географическое перемещение "узла сети" (как в масштабах территории предприятия, так и всего земного шара) при сохранении им своего места в служебной иерархии. Также легко допускается и то, что, оставаясь на своем рабочем месте, сотрудник может радикально изменить круг своего делового общения, уже не говоря о том, что оба случая в различных пропорциях могут иметь место одновременно. Поскольку темпы изменения организационных структур предприятий имеют тенденцию опережать технический прогресс в целом, все более и более очевидной становится необходимость отделить логическую структуру сети от физической, сделав ее (сеть) виртуальной.

Не берусь сказать точно, когда именно появилась концепция "виртуальных сетей" (VLAN) в том виде, в котором она существует сейчас, но, по-видимому, это произошло около двух с половиной лет назад, когда интеллектуальность производимых коммутаторов начала расти буквально день ото дня. Изначально коммутаторы исполняли, в основном, роль промежуточного звена между концентраторами рабочих групп и магистральными маршрутизаторами, однако благодаря своим возрастающим возможностям по сегментации и управлению трафиком они стали играть все большую роль в построении сетей. Собственно, уже в конце 1994 года администраторы могли организовывать виртуальные рабочие группы в масштабах одного коммутатора, задавая правила фильтрации пакетов. Например, когда сегодня в небольших ЛВС администратор при конфигурации коммутатора выделяет, скажем, графические станции в отдельные сегменты, он уже создает виртуальные сети, возможно, об этом и не подозревая. Организовать VLAN в крупной сети на уровне одного коммутатора также несложно при условии, что в сегменты объединяются преимущественно большие группы пользователей и предполагается, что логическая структура сети более-менее повторяет физическую. Однако в общем случае организация виртуальных сетей в масштабах предприятия накладывает на оборудование значительные требования по интероперабельности и масштабируемости и требует разработки стандартных механизмов взаимодействия коммутаторов и/или маршрутизаторов, подключенных к магистрали.

АТМ - ДВИГАТЕЛЬ VLAN

Возможно, концепция виртуальных сетей масштаба предприятия до сих пор бы не попала на знамена производителей сетевого оборудования по причине отсутствия стандартов, но, к счастью, в феврале 1995 года Форум ATM принял спецификацию LANE - эмуляции ЛВС. АТМ, как протокол, ориентированный на соединения, идеально подходит для организации коммутируемых сетей и предоставляет широкие возможности по управлению трафиком каждого отдельного соединения и всех соединений в целом, поэтому, несмотря на все трудности, сопутствующие становлению этой технологии, производители коммутаторов оказались единодушны в стремлении к ее развитию и выработке единых стандартов.

Первые предложения по LANE поступили в Форум ATM в феврале 1993 года от IBM и касались FDDI и эмуляции ЛВС на уровне транспортных протоколов. В конце 1994 года Форум принял спецификации по инкапсуляции пакетов Ethernet и Token Ring, а, как уже было сказано, в феврале 1995 года он одобрил спецификацию LANE. К концу того же года появились первые соответствующие ей устройства.

Сервис LANE эмулирует некоторые свойства "традиционных" сетей, сохраняя при этом достоинства АТМ. Эмулируемые ЛВС (ELAN) могут использовать протоколы Ethernet или Token Ring; поддержка же FDDI и Fast Ethernet осуществляется при помощи транслирующих мостов на границе ELAN. Эмулируемая сеть состоит из нескольких клиентов эмуляции сети (LEC - LAN Emulation Client) и одного сервиса эмуляции сети (LE Service). LEC - это объект конечной системы ATM, действующий либо от своего имени, либо от имени традиционного пользователя сети, идентифицируемого при помощи MAC-адреса. Таким объектом является обычно программный процесс, выполняемый на коммутаторе, маршрутизаторе или ПК. Поскольку LEC - процесс второго уровня, то наиболее экономичным в пересчете на стоимость порта решением будет выполнение LEC на коммутаторах. Сервис эмуляции также может выполняться на любом конечном устройстве АТМ, здесь решающим фактором является аппаратная и программная масштабируемость. Сервис включает в себя сервер конфигурации эмуляции (LECS), сервер эмуляции (LES) и сервер широковещательного, многоадресного и неизвестного трафика (Broadcast and Unknown Server - BUS). Эмулируя широковещательный сервис при помощи LE Service, мы получаем возможность перенаправлять такой трафик к конкретным конечным устройствам за счет выборочного установления соединений и фильтрации. Текущая версия стандарта LANE реализует упрощенный подход к перенаправлению широковещательного трафика, перекладывая фильтрацию ненужного трафика на конечные устройства, как это, собственно, происходит в обычных сетях; положение дел должно измениться с принятием стандарта LANE v2.

Одновременно с использованием шлюзовых устройств (это относится к пользователям традиционных сетей) к сервису эмуляции можно подключаться и напрямую через АТМ. Доступ к приложениям традиционных сетей достигается при помощи установки драйверов MAC - NDIS или ODI - поверх драйвера интерфейса АТМ, что обеспечивает полную прозрачность доступа.

Интерфейс взаимодействия между LEC и LE Service называется LUNI (Lan Emulation User to Network Interface). Действующий в этом интерфейсе протокол LANE определяет процедуры инициализации эмулируемой сети, регистрации конечных устройств, определения адресов и передачи данных. Интерфейс взаимодействия серверов эмуляции LNNI (LE Network-Network Interface) позволяет организовывать связи между несколькими LES или BUS. Это дает возможность одному LEC связываться с несколькими LES или BUS для повышения надежности или распределения нагрузки. Вообще, LEC может связываться еще и c LECS и, разумеется, с другим LEC. Соединения с LECS и LES устанавливаются для передачи управляющей информации, а соединения с BUS и другими LEC - для передачи данных (см. Рисунок 1).

А как происходит обмен данными между виртуальными сетями в рамках инфраструктуры ATM, когда, например, в роли LEC выступают подсоединенные к ATM коммутаторы, а в роли LES - маршрутизатор? Коммутатор, работающий с находящимися в различных эмулируемых ЛВС LEC (в случае нескольких рабочих групп), будет общаться с ними как с разными объектами 2-го уровня. Предположим, мы имеем две эмулируемых ЛВС (ELAN A и ELAN С) и соответствующие им подсети IP, а маршрутизатор, будучи центром среды эмуляции, входит в обе сети и связывает обе подсети.

Если сервер в подсети А хочет послать данные на рабочую станцию в подсети С, он маскирует IP-адрес получателя своим локальным адресом IP, определяя тем самым, что адресат находится в удаленной сети. Затем сервер пересылает пакет установленному по умолчанию маршрутизатору ELAN A. Сначала он генерирует по протоколу ARP запрос на соответствующий IP-адресу маршрутизатора MAC-адрес. Получив его (через коммутатор), сервер отправит пакет клиенту LEC, имеющему такой же MAC-адрес, как у маршрутизатора. LEC перенаправляет этот пакет на интерфейс ATM, определяя адрес NSAP маршрутизатора, соответствующий его MAC-адресу. Получив пакет, маршрутизатор проводит его обычную обработку на уровне IP, определяя выходной порт в ELAN C. Заметим, что если маршрутизатор поддерживает организацию подинтерфейсов на одном и том же физическом интерфейсе АТМ, он будет фактически перенаправлять пакет через тот же интерфейс. После того как маршрутизатор по запросу ARP на уровне IP получает MAC-адрес станции в подсети С, он перенаправляет пакет соответствующему LEC по протоколу LANE, на который ложится задача определения MAC-адреса точки назначения по NSAP-адресу.

КАК ПОСТРОИТЬ ВИРТУАЛЬНУЮ СЕТЬ СЕГОДНЯ?

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

На Рисунке 3 проиллюстрирована так называемая мобильность портов. Мы имеем все те же рабочие группы A и B, только принадлежность портов коммутатора к той или иной рабочей группе может меняться динамическим образом. Пользователь, покинув одно рабочее место, может подключиться к неназначенному порту в другом месте. Этот порт автоматически определяет принадлежность пользователя к рабочей группе по его MAC- или сетевому адресу. Как вариант, порт может быть сконфигурирован таким образом, что он будет разрешать соединения только с конкретными MAC-адресами или рабочими группами. Самая сложная форма контроля за назначением портов предполагает использование одного или нескольких конфигурационных серверов, разрешающих соединения с данным портом. Такая мобильность, как уже было сказано выше, и есть одна из основных целей развития виртуальных сетей.

Далее, принадлежность к той или иной виртуальной сети может определяться не только на основе MAC-адресов, но и адресов сетевого уровня. На Рисунке 2б одни пользователи применяют протокол IP, в то время как другие - IPX. Система управления виртуальными сетями дает пользователям обеих виртуальных сетей возможность организовывать доступ к серверам, поддерживающим IP или IPX. Как вариант, система управления может автоматически причислять пользователей к рабочим группам в зависимости от их адресов третьего или сетевого уровня. В этом случае система "разведет" серверы по отдельным рабочим группам. Согласно этому сценарию, каждый пользователь также может входить в несколько виртуальных сетей. Заметим, что такое автоматическое назначение VLAN работает лишь в случае маршрутизируемых протоколов. Если же протоколы немаршрутизируемые, виртуальные сети придется организовывать только на основе портов и MAC-адресов.

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

Продолжая разговор об управлении, отметим, что основная его задача - обеспечение необходимого уровня безопасности. В VLAN можно определить три уровня мобильности. На первом уровне пользователи ассоциируются с данной эмулируемой ЛВС в любой точке сети. Каждый физический сетевой порт каждого LEC автоматически ассоциирует себя с VLAN пользователя. При этом обеспечиваемый уровень мобильности и адаптивности весьма высок, но вероятность нарушения режима безопасности также оказывается весьма высока, особенно если нет возможности физически защитить каждый LEC. На втором уровне мобильности сетевые порты клиента LEC заранее приписаны к конкретным виртуальным сетям. Это обеспечивает лучшую защиту сети при хорошем уровне мобильности. Наконец, самый строгий уровень организации защиты виртуальной сети достигается, когда MAC-адреса заранее соотносятся с физическими портами. Мобильность при этом ограничивается очень жестко, но остальные преимущества виртуальных сетей сохраняются.

Трудности управления виртуальными сетями напрямую связаны с проблемами администрирования коммутируемых сетей (см. февральский номер LAN Magazine/Русское издание за 1997 год). Помимо этого, необходимо обеспечить наблюдаемость управляемой системы на всех уровнях эмулируемой ЛВС с первого по третий. В случае сосуществования нескольких виртуальных сетей в рамках одной инфраструктуры ATM управление должно осуществляться как в виде конфигурирования и фильтрации на MAC-уровне внутри рабочих групп, так и в виде конфигурирования и фильтрации на сетевом уровне между рабочими группами, причем эта фильтрация должна быть организована для каждого протокола третьего уровня в отдельности.

КУДА ИДУТ VLAN

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

Начнем с их видения сегодняшней ситуации. В настоящее время отрасль переживает этап практической реализации VLAN, организуемых на уровне портов коммутатора при помощи фильтрации пакетов. В целом вопрос об организации виртуальных сетей на базе нескольких коммутаторов с помощью эмуляции ЛВС в ATM или собственных разработок производителей решен успешно. По утверждению последних, бояться применять эти "не совсем стандартные" технологии не надо, поскольку они либо будут адаптированы к стандарту 802.1Q, либо смогут существовать параллельно с ним. С принятием стандарта вопрос об организации многопротокольных виртуальных сетей должен решиться окончательно, однако полной уверенности, что это произойдет в запланированные сроки, нет.

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

Конечной целью в стратегических планах производителей (по крайней мере до конца текущего тысячелетия) является создание виртуальных сетей с внутренней политикой (policy driven или policy based VLANs). Поскольку уровень автоматизации управления виртуальными сетями будет очень высоким, администраторы должны иметь возможность задавать внутреннюю политику работы сети. Под политикой понимается набор специфических параметров, определяющих приоритеты в системе доступа к ресурсам сети, обеспечении QoS и необходимого уровня безопасности. По заявлениям производителей, такие виртуальные сети возьмут на себя многие функции сегодняшних сетевых операционных систем, оставив на их долю только предоставление пользователям требуемых сервисов. Такой подход должен обеспечить множество преимуществ. Во-первых, серверу уже не нужна будет информация о работе сети, и он будет избавлен от "беспокойства" по поводу поддержки соответствующих протоколов. Во-вторых, уровень защиты информации в сети заметно повысится. Трудно представить, как можно "хакнуть" коммутатор, а ведь злоумышленнику прежде, чем добраться до ресурсов сервера, придется преодолевать "нежелание" сети предоставлять ему запрашиваемое соединение. Неизвестно только, что по этому поводу думают производители сетевого ПО. Теоретически они избавляются от излишней головной боли, а на практике их сетевые ОС могут лишиться многих акцентируемых сегодня и весьма удачных с точки зрения маркетинга, черт.

ЗАКЛЮЧЕНИЕ

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

LANE V1, V2... ЧТО ДАЛЬШЕ?

На пути к MPOA

В настоящее время Форум ATM работает над стандартом передачи по ATM любого протокола третьего уровня: MPOA (Multiprotocol Over ATM). MPOA представляет собой развитие технологии эмуляции сетей и предполагает использование LANE для пересылки пакетов на втором уровне в рамках одной подсети (в терминах IP) третьего уровня. Иными словами, MPOA - это эволюция LANE, объединяющая маршрутизацию третьего уровня с мостами второго уровня.

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

Не вдаваясь в подробности этого пока еще не принятого стандарта, отметим главное - основными единицами структуры MPOA являются подгруппы межсетевых адресов (IASG - Internet Address Sub-Group), представляющие собой неперекрывающиеся множества адресов протокола маршрутизации третьего уровня. В терминах IP, например, это будут подсети. IASG определяются для каждого действующего в сети протокола третьего уровня. В случае многопротокольных сетей группы разных протоколов могут перекрываться физически.

Подобная модель предполагает отождествление адресов ATM с адресами третьего. До недавнего времени использовалась модель многоуровневой маршрутизации, в которой маршрутизация между сетями (например OSPF) осуществляется независимо, поверх маршрутизации ATM (PNNI). Впрочем, повторимся, стандарт еще не принят, и в нем возможны любые изменения. Отметим только, что Cisco и Fore являются явными приверженцами MPOA.

СУЩЕСТВУЮЩИЕ АРХИТЕКТУРЫ VLAN

НЕ ТОЛЬКО АТМ

Стандарт IEEE 802.1Q

Разумеется, развивая технологию виртуальных сетей, отрасль не может опираться только на ATM, потому что инерция рынка достаточно велика; и через пять, и через десять лет по-прежнему будут эксплуатироваться (и строиться) сети, где в качестве магистрали используется Fast Ethernet или FDDI. Вопросом о принятии стандартного механизма взаимодействия коммутаторов и/или маршрутизаторов в виртуальных сетях занимается комитет IEEE 802.1Q. Ожидается, что уже в этом году комитет примет две спецификации маркировки пакетов: первая, одноуровневая, будет определять взаимодействие виртуальных сетей по магистрали Fast Ethernet; вторая, двухуровневая, будет касаться маркировки пакетов в смешанных магистралях, включая FDDI.

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

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