Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
ДОМОЙПОДПИСКАГДЕ КУПИТЬСТАТЬИRambler's Top100   
 
 
 
    
ЖУРНАЛ
   
Главная
Архив новостей
Новый номер
Архив статей
Адреса в интернет

РУБРИКАТОР
   
• Колонка редактора
• Только на сервере
• Локальные сети
• Бизнес
• Корпоративные сети
• Услуги сетей связи
• Защита данных
• Системы
   учрежденческой связи

• Электронная
   коммерция

• Новые продукты

РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Тематический план
Отдел рекламы

E-MAIL


Rambler's Top100

  

Передовые технологии: Layer 3 Switching (часть II)

A. Г. Барсков, О. С. Фоминов

Мы продолжаем разговор о технологиях Layer 3 Switching, начатый в предыдущем номере журнала (см.: Сети и системы связи. 1997. № 8. С. 32). Напомним, что первая статья в основном была посвящена устройствам, выполняющим функции как коммутации, так и традиционной маршрутизации. Как правило, такие устройства "изучают" и маршрутизируют каждый пакет межсетевого трафика (трафика между подсетями или виртуальными сетями) и поддерживают по меньшей мере один стандартный протокол маршрутизации, т. е. "ведут себя" как настоящие маршрутизаторы. Их основное преимущество перед обычными маршрутизаторами — более высокая скорость при меньшей стоимости.

Однако существует и другой подход к Layer 3 Switching, его суть — разобраться со всеми маршрутными делами в начале сеанса связи (например, осуществить полноценную маршрутизацию первого пакета), а затем просто коммутировать оставшийся трафик. Примерно так работают схемы Multiprotocol Switch Services (MSS) фирмы IBM и NetFlow фирмы Cisco Systems, рассмотренные нами в первой статье. Ниже мы более подробно обсудим этот подход и расскажем о некоторых, на наш взгляд очень интересных, технологиях.

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

Запрос—ответ

Предположим, станции А (отправитель) необходимо связаться со станцией Б (адресат). Зная IP-адреса — свой и станции Б — и используя маску подсети, станция А сначала определяет, где находится станция Б (в одной с ней подсети или нет). Если обе станции находятся в одной подсети, то пакеты между ними могут передаваться напрямую*, например через коммутатор (рис. 1а). Если нет, то трафик обязательно должен пройти через маршрутизатор или несколько маршрутизаторов (рис. 1б).

Затем станция А должна получить физический (МАС) адрес устройства, которому она непосредственно будет пересылать пакеты. Если станции находятся в одной подсети, то таким устройством является сама станция Б. Определив по IP-адресу станции Б ее физический адрес (см. ниже), станция А передает ей пакеты напрямую, без привлечения маршрутизатора. Если же станции находятся в разных подсетях, станция А "понимает", что для получения пакетов адресатом их надо отправить определенному маршрутизатору, например так называемому маршрутизатору по умолчанию, IP-адрес которого она "знает" (он сконфигурирован заранее). Определив по этому IP-адресу физический адрес маршрутизатора по умолчанию, станция А направляет трафик ему. А уж маршрутизатор сам "позаботится" о том, как передать трафик станции Б: напрямую, если соответствующая подсеть "прилегает" к нему непосредственно, или через другие маршрутизаторы.

Теперь поговорим о том, как, собственно, происходит определение физического адреса узла по его сетевому адресу. Чтобы получить физический адрес станции Б (или маршрутизатора), станция А сначала просматривает собственную таблицу, куда занесены соответствия между сетевыми и физическими адресами. При отсутствии в ней необходимой информации она посылает широковещательный ARP-запрос (Address Resolution Protocol), в котором указывает свою адресную информацию (адреса IP и МАС) и IP-адрес требуемого ей узла (станции Б или маршрутизатора). Обнаружив в полученном ARP-запросе свой IP-адрес, этот узел шлет ARP-ответ (обратно станции А), где указывает свои IP- и МАС-адреса. Он также запоминает адреса станции А, чтобы по необходимости найти их у себя в таблице, а не посылать лишний раз ARP-запрос.

Как же сделать так, чтобы трафик между двумя станциями коммутировался на втором уровне, даже если они расположены в разных подсетях? Оказывается, совсем несложно. Надо "заставить" станцию "поверить" в то, что она может связаться с любой другой станцией (или сервером) без помощи маршрутизатора, иначе говоря, что все станции находятся с ней в одной подсети. Именно на таком небольшом "обмане" станций и работают схемы фирм Cabletron, Digital, R.N.D. Networks и NBase. Исторически первой здесь появилась технология Cabletron. К ее рассмотрению мы и переходим.

SecureFast Virtual Networking фирмы Cabletron

Для организации непосредственного взаимодействия рабочих станций (или станции и сервера) в сети SecureFast Virtual Network (SFVN) требуется сконфигурировать каждую из них таким образом, чтобы она "думала", что может связаться с любым другим конечным узлом без помощи маршрутизатора. В большинстве случаев это достигается установкой IP-адреса маршрутизатора по умолчанию, равным IP-адресу самой станции.

Предположим, что все конечные узлы в сети SFVN сконфигурированы подобным образом и станции А необходимо "поговорить" со станцией Б (обе они находятся в сети SFVN). Если станции А известен физический (МАС) адрес станции Б, то они сразу же могут связаться друг с другом напрямую. Если же этот адрес ей неизвестен, то для его получения она посылает ARP-запрос. Его перехватывает коммутатор SecureFast Packet Switch (SFPS) и от имени станции А передает серверу SecureFast Virtual Network Server (SFVNS) запрос на установление соединения со станцией Б. С помощью своей базы данных сервер находит физический адрес станции Б по ее IP-адресу и отправляет его обратно (через коммутатор) станции А. Кроме того, сервер передает всем находящимся на пути между станциями А и Б коммутаторам необходимые для установления соответствующего соединения (между А и Б) инструкции. После завершения всех указанных процедур между станциями может осуществляться непосредственная связь по уже подготовленному пути.

Если сеть, где находится станция Б, находится за пределами сети SFVN, то путь к ней проходит через маршрутизатор, установленный на границе сети SFVN. В таком случае сервер SFVNS вернет станции А физический адрес этого маршрутизатора.

На сегодняшний день основные функции сервера SFVNS реализованы в самих коммутаторах семейства SmartSwitch, поддерживающих технологию SFVN. Это устраняет потребность в выделенном сервере. В будущем, при необходимости задействовать дополнительные механизмы контроля и управления (Call Tapping, Connection Policy, Connection Auditing и др.), надо будет использовать специальный сервер.

IP Packet Switching фирм Digital

Для работы технологии фирмы Digital конечные станции должны быть, как и в случае с рассмотренной выше технологией фирмы Cabletron, сконфигурированы таким образом, чтобы они пытались передавать пакеты непосредственно адресатам, даже если те находятся в других подсетях. Как уже отмечалось, в большинстве случаев это достигается установкой адреса маршрутизатора по умолчанию, равным адресу самой станции. Кроме того, для эффективной работы IP Packet Switching необходимо определить соответствие между портами GIGAswitch/FDDI — коммутатора, поддерживающего эту технологию, — и определенными диапазонами адресов (диапазоны могут состоять из одного адреса, нескольких (скажем, 16.0.0.0 — 16.255.255.255) или всех адресов (0.0.0.0 — 255.255.255.255)).

Технология фирмы Digital работает следующим образом. (напомним, что мы рассматриваем простейшую ситуацию, когда рабочая станция А "намеревается" связаться со станцией Б из другой подсети.) Если станция А не находит в своем кэше физического (МАС) адреса станции Б, то она инициирует ARP-запрос. Коммутатор GIGAswitch/FDDI отвечает на этот запрос (при наличии соответствующей информации) или рассылает его дальше, но только по тем портам, для которых прописан адрес подсети (диапазона адресов) станции Б. Получив ответ на свой ARP-запрос, станция А передает пакеты непосредственно станции Б.

В настоящее время поддержка технологии IP Packet Switching обеспечена только на коммутаторе GIGAswitch/FDDI (реализуется путем загрузки нового ПО), однако Digital планирует внедрить ее и на других коммутаторах.

Кроме технологии IP Packet Switching, ориентированной на работу в традиционных сетях (отсюда и присутствие слова "пакет" (packet) в ее названии), фирма Digital поддерживает и требующую наличия сети ATM технологию IP Switching. Последняя использует протоколы, разработанные фирмой Ipsilon Networks, и реализована в продуктах Digital с августа прошлого года.

DirectIP Switching фирмы NBase Communications

Одно из основных отличий технологии DirectIP от рассмотренных выше технологий фирм Cabletron и Digital заключается в том, что необходимая для ее работы переконфигурация рабочих станций происходит с привлечением протокола DHCP. Суть этой переконфигурации состоит в следующем: маски подсетей задаются таким образом, чтобы станция "думала", будто конечный адресат ее пакетов находится с ней в одной подсети (даже если это и не так на самом деле). После такого "обмана" все происходит по уже знакомому нам сценарию: станция А посылает коммутатору DirectIP ARP-запрос на получение физического (МАС) адреса станции Б; коммутатор проверяет (по IP-адресу станции Б), разрешено ли запрашиваемое соединение, и, если оно разрешено, передает станции А физический адрес станции Б; далее связь между станциями осуществляется напрямую, без привлечения маршрутизатора.

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

PowerIP фирмы R.N.D. Networks

Основная задача, которая ставилась при разработке схемы PowerIP, — "заставить" некое устройство обеспечить прямое соединение, скажем между двумя рабочими станциями, а затем "отключить" это устройство. В качестве такого устройства можно использовать выпускаемый фирмой R.N.D. Networks маршрутизатор PowerIP Engine (фирма также предлагает коммутатор PowerIP Switch со встроенными функциями PowerIP Engine).

Как и раньше, предположим, что станции А (отправитель) необходимо связаться со станцией Б (адресат) из другой подсети IP. Первые пакеты сеанса связи станция-отправитель передает через маршрутизатор (как и в классическом случае), функции которого выполняет PowerIP Engine. Одновременно с маршрутизацией этих пакетов PowerIP Engine изменяет маршрут передачи трафика (фактически перенаправляет его в другую подсеть), делая это с помощью передачи станции А специального сообщения протокола ICMP (Internet Control Message Protocol), так называемого ICMP-redirect. В этом сообщении задаются виртуальный

IP-адрес станции Б и ее реальный физический (MAC) адрес, причем виртуальный IP-адрес принадлежит той же подсети, что и адрес станции А. Таким образом, PowerIP Engine как бы "говорит" станции А, чтобы вместо него в качестве маршрутизатора по умолчанию она использовала устройство с виртуальным IP-адресом станции Б. Станция А, "думая", что находится в одной подсети со станцией Б, устанавливает в пакетах физический адрес получателя, равным физическому адресу станции Б (а не маршрутизатора, как это было раньше) и передает трафик напрямую, через коммутатор.

В отличие от рассмотренных выше технологий фирм Cabletron и Digital технология PowerIP не требует переконфигурации конечных узлов (станций и серверов). Это достигается за счет использования виртуальных IP-адресов, выделяемых динамически. Заметим, если в маршрутизаторе PowerIP Engine таблица соответствия между

IP- и МАС-адресами закончилась, то избыточные сессии будут просто маршрутизироваться (т. е. трафик будет передаваться, хотя и медленнее).

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

IP Switching фирмы Ipsilon

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

Технология IP Switching предложена фирмой Ipsilon в рамках выпускаемой ею линии магистральных и граничных коммутаторов ATM. Появление IP Switching обусловлено в основном двумя факторами: первый — весьма большое время, затрачиваемое на создание виртуального канала в сети коммутаторов ATM; второй — возникновение очевидного узкого места при построении сетей ATM с использованием "однорукого" маршрутизатора. Кроме того, было замечено, что часть функций, выполняемых для передачи маршрутизируемого трафика по сетям коммутаторов ATM, явно избыточная, поскольку функции коммутаторов ATM и функции маршрутизаторов порой дублируют друг друга.

Так, и коммутаторы ATM, и маршрутизаторы поддерживают таблицы связей между себе подобными устройствами, используя для этого протоколы PNNI/IISP и RIP/OSPF соответственно. И коммутаторы ATM, и маршрутизаторы вычисляют маршрут: первые делают это при установлении соединения, а вторые — при передаче каждого пакета. И коммутаторы ATM, и маршрутизаторы могут выполнять функции по обеспечению заказанного качества обслуживания, используя свойственные ATM механизмы и протокол RSVP соответственно. Можно также сказать, что и коммутаторы ATM, и маршрутизаторы обрабатывают особый вид трафика, который называют потоками (flow). Каждый поток идентифицируется адресами и портами посылающей и принимающей сторон, используемым протоколом, качеством обслуживания и т. д. Важно, что технология ATM предоставляет естественный способ идентификации пакетов, пересылаемых в рамках одного потока. Для этого служат идентификаторы виртуальных путей (Virtual Path Identifier — VPI) и виртуальных каналов (Virtual Channel Identifier — VCI).

Для реализации идеи "маршрутизации потоков" компанией Ipsilon была предложена следующая довольно специфическая архитектура коммутатора ATM. Каждый такой коммутатор (часто называемый IP-коммутатором) имеет стандартный механизм коммутации ячеек ATM, поверх которого реализуются механизм сборки/разборки пакетов (Segmentation and Reassembly — SAR) уровня адаптации AAL-5 и достаточно высокопроизводительный маршрутизатор IP.

В основе технологии фирмы Ipsilon Networks лежат два предложенных ею протокола: GSMP (General Switch Management Protocol, RFC 1987) и IFMP (Ipsilon Flow Management Protocol, RFC 1953). К функциям GSMP относится, в частности, управление проверкой целостности и изменением конфигурации виртуальных путей между коммутаторами. К функциям IFMP — управление соответствием между метками путей нижнего уровня (в данном случае, идентификаторами VCI/VPI) и логическими потоками данных. Согласно протоколу IFMP вводится, в частности, некий стандартный (default) путь, по которому могут передаваться данные для любого адресата в сети (такой путь всегда существует между любыми коммутаторами).

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

Допустим далее, что все коммутаторы на всем пути передачи трафика уже обработали запросы Redirection Message и пересылают данные по заданному пути (при каждой коммутации пакета метка пути может изменяться). При этом коммутатору уже необязательно производить сборку/разборку и маршрутизацию пакетов данного потока, поскольку поток полностью характеризуется его входной и выходной метками. Все, что надо сделать, — переадресовать пакет с входного порта на выходной и заменить его метку (рис. 2г). Таким образом, мы пришли к быстрой коммутации.

Отметим, что протокол IFMP может работать не только поверх ATM-сетей, поскольку для него требуется только одна относительно нестандартная функция — возможность пометить каждый пакет меткой пути. В случае ATM для этого используются идентификаторы VCI/VPI, а в случае применения протокола IPv6 можно задействовать метки его пакетов. Кроме того, возможно использовать протокол IFMP вместе с любой другой схемой метки пакетов — ISL (Inter-Switch Link) фирмы Cisco, VLT (Virtual LAN Trunks) фирмы 3Com, IEEE 802.1q и т. д. Фактически у протокола IFMP есть шанс стать стандартом "сшивки" различных технологий Layer 3 Switching. Так, о его поддержке заявили фирмы 3Com, Cascade, IBM и Cabletron.

Описанная выше схема неплохо работает не только на продолжительных (FTP, HTTP, telnet, X.11, передача мультимедиа информации и т. д.), но и на очень коротких потоках (DNS, SNMP и т. д.). Правда, в последнем случае она не дает выигрыша в производительности, но и не требует никаких дополнительных накладных расходов, как многие другие технологии. Анализ реального трафика сети Интернет показывает, что применение IP Switching позволяет повысить ее производительность примерно в четыре-пять раз.

Недостатком технологии IP Switching является необходимость поддержки протокола IFMP (а в случае реализации фирмы Ipsilon еще и протокола GSMP) всеми устройствами сети — или по крайней мере ее ядра. Ipsilon выпускает не только IP-коммутаторы ATM, но и граничные коммутаторы (так называемые шлюзы IP-коммутации) между ATM и множеством других сред. Причем подобные шлюзы можно использовать и в качестве отдельных IP-коммутаторов даже без применения технологии ATM.

Fast IP фирмы 3Com

В технологии Fast IP фирмы 3Com идея о наличии специального протокола для описания виртуального потока, который можно коммутировать на втором уровне, доведена до логического завершения. В Fast IP агентами такого протокола являются сами сетевые адаптеры. Конечно, с одной стороны, это требует некоторого изменения их ПО, но, с другой — позволяет не трогать все остальное сетевое оборудование и, что не менее важно, сделать доступным выбор виртуальных путей посредством специальных прикладных интерфейсов (API) операционных систем. Последнее дает возможность, например, заказывать качество обслуживания для каждого сеанса связи. Здесь Fast IP в принципе отличается от технологий, построенных на сокрытии от клиентов сети всей "кухни" коммутации Layer 3 Switching, например таких, как SFVN.

Важный аспект Fast IP — использование ею в качестве служебных только тех протоколов, на которые имеются предварительные (draft) варианты стандартов. При условии поддержки технологии Fast IP сетевыми адаптерами это позволит в качестве остального сетевого оборудования применять аппаратуру практически любых производителей. Оправданно, что такой подход предложила именно компания 3Com, так как ее адаптеры — самые распространенные в мире.

Наконец, благодаря следованию стандартам технология Fast IP должна неплохо сопрягаться и с другими технологиями Layer 3 Switching. В частности, фирмы 3Com, IBM и Cascade объявили о создании общего механизма взаимодействия, который позволит объединять устройства, поддерживающие технологии Fast IP, MSS и IP Navigator. Кстати, в данном проекте большую роль играет и протокол IFMP. Успешное воплощение в жизнь инициативы этих фирм позволит, например, объединять две ЛВС, поддерживающие Fast IP, через сеть коммутаторов Frame Relay, поддерживающих IP Navigator, и при этом маршрутизировать "долго живущие" потоки максимум один раз (даже если их путь проходит через сеть Frame Relay).

Рассмотрим основные принципы работы технологии Fast IP с трафиком протокола IP (хотя, вообще говоря, она может работать с любыми маршрутизируемыми протоколами). Итак, любая рабочая станция способна взаимодействовать со станциями своей подсети при помощи обычных коммутаторов (второго уровня), в этом случае технология Fast IP не используется. При необходимости передать данные станции из другой подсети пакет должен быть послан на маршрутизатор. В этом случае в соответствии с технологией Fast IP станция направляет маршрутизатору запрос NHRP (Next Hop Resolution Protocol) на передачу данных по требуемому адресу IP. Важно, что в NHRP-запросе содержится физический (MAC) адрес станции — инициатора запроса. На основании политики администрирования маршрутизатор либо игнорирует данный запрос (тогда передача данных становится невозможной), либо маршрутизирует его обычным образом, заменяя MAC-адрес (тогда весь дальнейший трафик будет по-прежнему направляться через маршрутизатор), либо перенаправляет его станции-адресату. В последнем случае поддерживающая Fast IP станция-адресат по инкапсулированному в NHRP-запрос физическому адресу попытается установить непосредственное, чисто коммутируемое (на втором уровне) соединение со станцией — инициатором соединения. Если между ними существует маршрут, проходящий только через коммутаторы, такая попытка удается и в дальнейшем весь трафик будет передаваться минуя маршрутизатор.

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

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

Упомянутый выше маршрутизатор может являться как специализированным маршрутизатором, так и коммутатором с возможностью маршрутизации. Для фирмы 3Com последний вариант кажется гораздо более предпочтительным, если, с одной стороны, учесть довольно высокую стоимость специализированных маршрутизаторов, а с другой — большое число инсталлированных коммутаторов типа CoreBuilder 2500 и 6000, подсистема маршрутизации которых вполне удовлетворяет требованиям, предъявляемым Fast IP к маршрутизатору. Причем при внедрении технологии Fast IP каждый коммутатор CoreBuilder 2500 или 6000 может функционировать и как коммутатор, и как маршрутизатор, маршрутизируя первый пакет потока и коммутируя все остальные.

Первая коммерческая реализация технологии Fast IP появится в октябре 1997 г. в виде бесплатно распространяемых драйверов для наиболее популярных сетевых адаптеров фирмы 3Com. Месяцем позже 3Com обещает выпустить драйверы с поддержкой Fast IP и для сетевых адаптеров фирм Intel и SMC, а три перечисленные фирмы, по данным IDC на март 1997 г., удерживают ни много ни мало 81% всего рынка сетевых адаптеров.

В первом квартале 1998 г. ожидается выход следующей версии технологии Fast IP с несколькими существенно новыми возможностями: в ней намечено расширить спектр поддерживающих Fast IP сетевых адаптеров; появится возможность использовать совместно с Fast IP не только протоколы семейства IP, но и другие; будет реализована концепция Asymmetric Fast IP (или Proxy Fast IP). Последняя предусматривает специфический алгоритм обмена NHRP-сообщениями, при котором на NHRP-запрос отвечает не сама станция-адресат, а ближайший к ней коммутатор (имеющий интегрированную поддержку Fast IP). Такой режим работы дает два преимущества. Во-первых, в рамках технологии Fast IP полноценная высокопроизводительная работа станет возможной даже для станций с сетевыми адаптерами других фирм (а не только фирм 3Com, Intel и SMC). Во-вторых, резко возрастет обеспечиваемый Fast IP уровень защиты данных, поскольку коммутатор сможет следить за тем, чтобы тип передаваемого трафика соответствовал типу трафика, заказанного при посылке NHRP-запроса.

***

Большинство рассмотренных технологий и реализующих их продуктов появились на рынке совсем недавно, а технологии Fast IP фирмы 3Com еще только предстоит выйти на рынок. Поэтому, с одной стороны, их можно воспринимать как интересные новшества — и не более того. С другой стороны, развитие сетей происходит столь стремительно (и Россия здесь не исключение), что, возможно, уже очень скоро внедрение этих технологий станет абсолютно необходимым для эффективного функционирования вашей сети, а следовательно, и для успешной работы всего предприятия.





  
9 '1997
СОДЕРЖАНИЕ

колонка редактора

• Российский сетевой ландшафт в двух измерениях

локальные сети

• Двухпроцессорные серверы на базе Pentium Pro

• Восемь сетевых цветных принтеров

• Философия успешного производства (интервью Зоара Зисапеля)

корпоративные сети

• Многопротокольный удаленный доступ через Интернет

• Модернизация сети с помощью АТМ (часть I)

• Следите за маршрутизаторами!

• Передовые технологии: Layer 3 Switching (часть II)

• Ярмарка компьютерных чудес в Новом Орлеане

услуги сетей связи

• Развитие российской сети ОКС №7 - основа современных услуг связи

• Анатомия модемных "56К-технологий" (часть II)

• Конференц-связь: проблемы и решения

интернет и интрасети

• Сезам, откройся!

• Проектирование отказоустойчивых корпоративных сетей TCP/IP

• Анализ журнала регистраций узла Web, или Поиск рецепта успеха

защита данных

• Игра ва-банк с сетевыми "медвежатниками"

новые продукты

• О суеверии, коммутаторе Catalyst 5500 и лаборатории PLUS Communications, Недорогой сервер Digital в России

только на сервере

• Интернет в вопросах и ответах. Продолжение



 Copyright © 1997-2001 ООО"Антонюк Консалтинг". Тел. (095) 234-53-21. Факс (095) 974-7110. вверх