СУДЬБА TCP/IP ЗА РАБОЧИМ СТОЛОМ

На гребне лавинообразного роста интереса к Internet TCP/IP проник во многие настольные ПК. Однако в отличие от NetWare и AppleTalk, для TCP/IP каждый отдельный хост необходимо дополнительно конфигурировать. К счастью, эта задача значительно упрощается благодаря появлению большого числа сетевых протоколов и систем, которые позволяют централизованно управлять TCP/IP.

ПОСТАНОВКА ВОПРОСА

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

Кроме того, системы должны уметь обнаруживать основные ресурсы сети, то есть определять местонахождение файловых серверов и других сетевых ресурсов. Но большая часть сетевого программного обеспечения для сред ПК замалчивает вопросы обнаружения и управления ресурсами, из-за этого складывается ложное впечатление, что организация сети - несложное дело, простое как "plug-and-play".

Novell пытается разрешить данную проблему при помощи широковещательных сообщений. NetWare использует уникальные аппаратные адреса плат Ethernet и TokenRing как часть IPX-адреса узла (шестибайтный адрес узла имеет ту же длину, что и аппаратный адрес Ethernet). Номер сети IPX выбирается при установке сервера NetWare. Протоколы AppleTalk и LAN Manager/LAN Server, поддерживаемые Windows NT, Windows 95 и Windows for Workgroups, используют динамически распределяемые через широковещательную рассылку имени (адреса).

Исторически, протоколы NetWare для осуществления функций управления и определения клиентами местоположения файловых серверов и ресурсов опирались на широковещание при посредстве Service Advertising Protocol (SAP) и Routing Information Protocol (RIP). Но широковещание хорошо для небольших сетей: тот трафик, который они порождают, может привести к пробкам в сети больших предприятий и совершенно не допустим в Internet. В едином сетевом каталоге NetWare Directory Services (NDS) NetWare 4.x и NetWare IP предпринята попытка решить эти вопросы. NetWare IP и ее Domain SAP/RIP Server (DSS) пытаются смягчить заданный сценарий посредством замены широковещания на специфические запросы DSS Server. Однако поставленные вопросы по-прежнему остаются без ответа, когда NetWare 4.x работает в режиме эмуляции SAP.

АЛЛО, МИР!

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

Для глобальной объединенной сети важны уникальные имена и адреса. В отличие от популярных протоколов для ПК, TCP/IP снабжен схемами обеспечения уникальности IP-адресов и сетевых имен. Если администратор хочет подсоединить локальную сеть к Internet, то он должен обратиться к уполномоченному для получения IP-адреса. Чтобы зарегистрировать имя домена для сети (например, novel.com), необходимо подать отдельное заявление.

В Соединенных Штатах Министерство обороны и другие федеральные агентства имеют давно функционирующий информационный центр сети Network Information Center (NIC) - организацию, ответственную за распределение сетевых IP-адресов и регистрацию имен доменов. В настоящее время, за оказание услуг по регистрации в NIC отвечает Network Solutions Inc. (Chantilly, VA), а AT&T обслуживает каталог. В Европе аналогичный центр по обслуживанию запросов о предоставлении IP-адреса и имени домена находится в Нидерландах.

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

Кроме того, информационный центр сети распространяет документацию о предлагаемых и принятых сетевых протоколах TCP/IP. Запросы для отзыва определяют базис для организации TCP/IP сети. Эти запросы (RFC, Requests for Comments), вместе с другими проектными документами, можно получить через анонимный ftp из ds.internic.net.; они разрабатываются различными рабочими группами и отдельными разработчиками под эгидой Группы инженерной поддержки сети Internet (IETF - Internet Engineering Task Force).

TCP/IP: ЗВОНОК ДОМОЙ

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

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

Эта проблема существует и для протоколов LAN Manager/LAN Server в отношении адресации, базирующейся на 16-разрядном имени NetBIOS. Системный администратор или пользователь присваивает системе имя NetBIOS во время конфигурации. Однако данный пункт весьма сомнителен, так как исходный протокол NetBEUI не имеет никакого понятия о маршрутизации.

Большинство крупных центров LAN Manager и LAN Server используют NetBIOS над TCP/IP, так что вопросами маршрутизации занимается протокол IP. Процедура распознавания сетевых имен при помощи TCP/IP традиционно осуществляется посредством громоздкого преобразования имен NetBIOS в IP-адреса в файле LMHOSTS, который обычно создается вручную в каждом узле. Серверы имен NetBIOS - например, сервер Windows Naming Service (WINS), являющийся частью Windows NT Server 3.5 - сравнительно новы, в крупной сети они занимаются централизованным преобразованием имен NetBIOS в IP-адреса.

В AppleTalk адресация к отдельным узлам осуществляется динамически при помощи широковещания, в то время как имена зон и сетевые номера присваиваются вручную. Apple не предпринимала никаких усилий для того, чтобы гарантировать уникальность имен зон и сетевых номеров, оставляя это на откуп местным администраторам. Архитектура AppleTalk непригодна для организации больших объединенных сетей ввиду малой длины адреса (16-разрядный номер сети плюс восьмибитный номер узла).

При динамической адресации и маршрутизации, благодаря которым и стало возможным создание сети методом "plug-and-play", широковещательные сообщения передаются каждые 10 секунд. Крупную сеть широковещание может забить целиком, если только не будут приняты чрезвычайные меры для его ограничения.

КОНФИГУРИРОВАНИЕ IP ЗА РАБОЧИМ МЕСТОМ

TCP/IP эффективен в крупных сетях (таких как Internet) как средство конфигурации отдельных хостов, однако, он требует больших усилий, нежели стандартные решения для сети из ПК. Помимо своего IP-адреса настольный хост тоже должен знать - и это как минимум - свое имя, имя своего домена сети, маску подсети для своей сети, IP-адреса всех шлюзов и IP-адреса серверов Domain Name Service (DNS) (используемых для распознавания IP-адресов). Полезно также знать сетевые адреса других серверов (например, серверов печати и файловых серверов).

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

За прошедшие годы было опробовано немало протоколов для упрощения и централизации управления крупных сетей на базе TCP/IP (смотри "Что в имени твоем?"). Некоторые из этих протоколов, в частности протокол самозагрузки, Bootstrap Protocol (BOOTP), протокол обратного разрешения адреса, Reverse Adress Resolution Protocol (RARP) и элементарный протокол передачи файлов (tftp), появились уже в середине 80-х и поначалу использовались для начальной загрузки бездисковых рабочих станций. Сегодня они широко используются программным обеспечением TCP/IP на настольных ПК для централизованного управления именами и IP-адресами.

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

В Internet преобразование имен в адреса осуществляется DNS. Сетевые имена ниже корневого домена (com, edu, gov, int, mil, net, org и т.д.) должны быть зарегистрированы в информационном центре сети для обеспечения их уникальности.

Организация, имеющая первичный домен (например, sum.com) отвечает за администрирование своего адресного пространства и может делегировать управление подчиненными доменам (eng.sun.com) другим. Хост на базе ПК должен знать адреса нескольких серверов DNS для того, чтобы смочь преобразовать вводимые пользователем имена в эквивалентные IP-адреса. Если сервер имен DNS не имеет информации об имени, то он возвращает IP-адрес другого (способного ответить на запрос) сервера имен DNS.

ЗАГРУЗКА ПО НОМЕРАМ

RARP функционирует на дне сетевого стека на уровне драйверов устройств. RARP-клиент посылает специальный пакет со своим аппаратным адресом, а в ответ получает IP-адрес от RARP-сервера в той же подсети. IP-адреса, присвоенные RARP-клиентам, обычно хранятся на RARP-сервере в файле с базой данных в виде обычного текста (/ETC/ETHERS в большинстве Unix-систем), который ставит в соответствие 6-байтному аппаратному адресу четырехбайтный IP-адрес. Большинство Unix-систем поставляются вместе с демоном для RARP-сервера, а компания Sun Microsystems (Mountain View, CA) использует RARP как часть процесса загрузки своих бездисковых станций.

В настоящее время RARP обычно используется многопротокольными серверами печати, которым для работы нужно несколько больше, чем просто IP-адрес. Поскольку RAPR должен быть реализован на нижнем уровне сетевого стека, он, как правило, не поддерживается поставщиками TCP/IP для ПК.

Наибольшее распространение получил BOOTP, использующий прикладной уровень TCP/IP, что упрощает реализацию на базе ПК. Кроме того, он позволяет передавать больше данных о конфигурации в одном пакете. Впервые предложенный в 1985 году Биллом Крофтом из Стэнфордского университета (Stanford, CA) и Джоном Гилмором из Sun Microsystems, BOOTP предназначался для загрузки бездисковых рабочих станций. Вместе со своим IP-адресом бездисковая машина должна, как правило, получить копию загружаемого образа, а также найти свой файловый сервер и прикладные программы.

BOOTP использует UDP из IP, сервис по передаче пакетов без установления соединения, напоминающий протокол IPX NetWare. В отличие от RARP протокол BOOTP достаточно прост в реализации в виде прикладной программы, а промежуточные агенты в маршрутизаторах и серверах обладают средствами для препровождения пакетов по сети к единственному BOOTP-серверу.

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

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

За прошедшие годы появились дополнительные опции. Последняя редакция была опубликована в октябре 1993 года в RFC 1533, а в июне 1995 появился проект ее изменения.

BOOTP широко используется для централизованного управления такими клиентами TCP/IP, как ПК и Macintosh. Программное обеспечение MacTCP и подавляющее большинство сетевого программного обеспечения TCP/IP для ПК поддерживают BOOTP, по крайней мере, в качестве способа получения IP-адреса локального компьютера, маски подсети и IP-адресов серверов DNS и шлюзов (маршрутизаторов) по умолчанию. Помимо этих базовых возможностей поддерживаются различные опции в зависимости от реализации клиента. Стандартный BOOTP-сервер под Unix использует код, написанный Джоном Гилмором. Этот код можно получить через анонимный ftp в ftp.mercury.com (файл /PUB/BOOTP-2.4.3.TAR.Z). Hewlett-Packard (HP, Palo Alto, CA) поставляет исполняемые версии BOOTP-сервера для различных Unix-систем, включая SunOS, Solaris, SCO и HP-UX c программным обеспечением JetDirect (принтеры HP LaserJet с картами JetDirect и серверы печати JetDirect).

Novell продает BOOTP-сервер как загружаемый модуль NetWare для NetWare 3.x и 4.x вместе со своими продуктами для локальных сетей рабочих групп.

Кроме того, BOOTP-серверы для ПК выпускает IBM в комплекте TCP/IP для OS/2, а также некоторые другие поставщики, например, Beame and Whiteside (Raleigh, NC), FTP Software (North Andover, MA) и Essex Systems (Middleton, MA), в своих прикладных комплектах TCP/IP для ПК.

BOOTP может предоставить массу данных о конфигурации хоста при обмене одним пакетом, и все-таки администратору необходимо сопровождать централизованную базу данных с BOOTP-информацией об аппаратных адресах каждой сетевой платы.

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

АВТОМАТИЗАЦИЯ НАЗНАЧЕНИЯ IP-АДРЕСОВ

В 1989 году IETF создала рабочую группу Dynamic Host Configuration Working Group для разработки методики динамической конфигурации хостов. В конце концов группа решила остановиться на BOOTP. Они разработали RFC, которые затем превратились в Dynamic Host Configuration Protocol (DHCP).

DHCP поддерживает три способа распределения IP-адресов: вручную, автоматически и динамически. При распределении вручную применяется схема, используемая в BOOTP, по которой специфический аппаратный адрес Ethernet преобразуется в определенный IP-адрес. Распределение вручную может опираться и на некоторые другие уникальные идентификаторы клиентов, например, на имя пользователя. Однако при распределении вручную по-прежнему необходимо участие администратора DHCP для присвоения IP-адреса и задания другой необходимой информации о конфигурации для каждого идентификатора клиента.

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

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

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

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

ДИНАМИЧЕСКИЕ ТРУДНОСТИ

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

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

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

РАЗВЕРТЫВАНИЕ DHCP

DHCP-серверы можно пересчитать по пальцам (см. Таблицу 1). FTP Software, Microsoft и Sun продают DHCP-серверы с прошлого года, а Silicon Graphics (Mountain View, CA) в настоящее время проводит тестирования собственных DHCP-сервера и клиента. HP планирует DHCP-сервер для HP-UX и поддержку клиента для своего семейства X-терминалов. Кроме того, Network TeleSystems (Santa Clara, CA) тестирует высокопроизводительную автономную DHCP-серверную систему, которая будет устанавливаться на выделенный ПК с 386-м процессором или выше.

В то же время, многие поставщики TCP/IP для ПК предлагают поддержку DHCP-клиента в последних моделях своих продуктов (см. Таблицу 2). Поскольку DHCP не что иное, как надмножество BOOTP, DHCP-серверы, большей частью, могут обслуживать BOOTP-клиентов (например, MacTCP-клиентов).

Windows NT Server 3.5 компании Microsoft поставляется вместе с DHCP- и WINS- (присвоение имен NetBIOS) серверами. Microsoft включает 32-разрядный стек TCP/IP (Wolverine) для Windows for Workgroups 3.11, Windows NT Workstation 3.5 и Windows 95.

Инструменты DHCP Manager на базе графического интерфейса пользователя делают установку и использование DHCP-сервера в Windows NT простым и удобным. Опция DHCP может быть сделана глобальной, принятой по умолчанию для определенного класса (диапазона, на жаргоне NT) или присвоена конкретному идентификатору клиента.

DHCP-клиент в Windows for Workgroups работает, однако использование Windows for Workgroups с динамическим распределением является надежным только при выдаче долгосрочной лицензии на адрес. Работа Windows 95 и Windows NT не нарушается при истечении срока лицензии на адрес.

Sun представила DHCP как часть семейства продуктов SolarNet в октябре 1994 года. PC-Admin включает серверы Solaris 2.x, - x86 и SPARC - для DHCP, протокол отделения почтового Post Office Protocol (POP, электронная почта), РС-NFS, информационные службы сети Network Information Services (NIS+), ftp и управление лицензиями клиентов; кроме того, он имеет простые в использовании инструменты PC Windows для управления клиентами и пользователями. PC-Admin включает однопользовательскую лицензию для клиентов TCP/IP и PC-NFS компании Sun на базе кода PC-NFS 5.1. Дополнительные лицензии могут быть приобретены партией на нескольких пользователей.

Sun также продает комплект из аппаратного и прединсталлированного программного обеспечения под именем Netra System Management Server. В этом продукте сервер PC-Admin Unix и программное обеспечение DOS/Windows прединсталлированы на станцию SPARCstation 5 или 10. ПК может быть использован как системный терминал, подсоединенный к последовательному порту для начальной конфигурации при помощи любого из привычных коммуникационных пакетов PC/Windows. Помимо текстовых сообщений сервер Netra использует встроенное в SPARC устройство для воспроизведения аудио-файлов, которое извещает администратора о начале работы сервера и об успешном завершении конфигурирования.

Так как для аутентикации используется защищенный вызов удаленных процедур, первая версия Sun опирается на собственные протоколы компании NIS+ для администрирования ПК. С DHCP-сервером Solaris могут быть использованы и другие DHCP-клиенты под DOS/Windows (не от Sun), однако при этом теряются многие возможности. Например, выполнение настроенных командных файлов запуска клиента на ПК становится невозможным.

Административные инструменты на базе Windows просты в использовании, однако PC-Admin или Netra Server лучше всего управляются администратором под UNIX. Хотя Netra создавалась якобы в качестве простого в использовании надзирателя за ПК, в документации даже не упоминается, как закрыть систему Solaris 2.x. В отличие от обычного ПК, взять и просто выключить питание системы, увы, нельзя, поскольку при этом можно нанести непоправимый вред файловой системе. (То же самое относится и к Windows NT).

Компания FTP Software предлагает сетевые сервисы Services OnNet для DOS/Windows в виде дополнительного пакета к собственному пакету TCP/IP OnNet (стек и приложения TCP/IP). Дополнительный продукт включает в себя серверы для DHCP, FNS, ftp, tftp и lpd. DHCP-сервер реализован как VxD. И конкуренты DHCP-сервера, и он сам используют простой инструмент на базе графического интерфейса пользователя Windows для создания, просмотра и изменения профилей клиентов.

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

Эти DHCP-серверы поддерживают все три метода распределения IP-адресов и добавление расширений других поставщиков к информации о конфигурации DHCP-сети. Продукты от Sun и FTP Software имеют несколько дополнительных, специфичных для каждого из поставщиков расширений (в частности в такой области, как управление лицензиями).

SolarNet компании Solaris имеет расширения для поддержки управляющих файлов и автоматического перенесения файловой системы на серверы Sun. Продукт включает сервер почты POP помимо NIS+, ftp, tftp, telnet и других, стандартных для Solaris 2.x сетевых серверов. DHCP-сервер SolarNet является уникальным в том смысле, что только он поддерживает удаленное DHCP-администрирование из-под Windows или через telnet (c других ПК или Unix-систем).

Windows NT и Solaris являются более надежными рабочими средами для приложений управления, чем Windows 3.x. Для больших предприятий выбор DHCP-сервера для Unix или NT будет во многом определяться сетевой средой и опытом в работе с конкретными локальными системами.

КОЕ-ЧТО ЕЩЕ ОБ IP-УПРАВЛЕНИИ

Сетевая файловая система NFS, разработанная Sun, является стандартным способом организации совместного использования файлов разными Unix компью- терами. Обычно лицензия на NFS выдавалась поставщикам вместе с лицензией на информационные сервисы сети NIS компании Sun, что привело к широкому распространению NIS.

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

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

Некоторые из поставщиков TCP/IP для ПК поддерживают NIS. Большая их часть включает в стеки TCP/IP агента, поддерживающего SNMP.

В зависимости от поставщика SNMP-агент осуществляет мониторинг за переменными, описанными в базе управляющей информации MIB-2 (RFC 1213) или базе управляющей информации о ресурсах хоста (RFC 1514). MIB-2 содержит сведения о таких факторах, как различные IP-пакеты, широковещания и конфликты в Ethernet. База управляющей информации о ресурсах хоста может собирать данные о версиях программного обеспечения системы и приложениях, которые выполнялись на ПК. Возможность получать такого рода информацию от управляющей SNMP-станции может оказаться весьма полезной для поддержания TCP/IP-сети в добром здравии. При определенных условиях некоторые SNMP-агенты на базе ПК имеют возможность посылать предупреждения (прерывания) управляющей станции.

Несмотря на то, что немало стеков TCP/IP включают SNMP-агентов, только немногие поставщики могут предложить солидное программное обеспечение SNMP-управления для опроса этих агентов - исключениями являются NewtWatch компании NetManage (Cupertino, CA) и PC/SNMP Tools компании FTP Software. Большинство поставщиков надеется на SunNet Manager, HP OpenView или аналогичные решения по SNMP-управлению предприятием для получения подобной информации. SNMPc, мощный пакет для SNMP-управления компании Castle Rock Computing (Cupertino, CA), осуществляет SNMP-управление и работает под Windows с различными стеками TCP/IP. Эти продукты для ПК существенно дешевле, чем решения для крупных предприятий, и, стало быть, намного привлекательнее для небольших сетей.

РАСШИРЯЮЩАЯСЯ ВСЕЛЕННАЯ IP

Практический пример использования таких инструментов может быть найден в университете шт. Орегон (Eugene), где используется 6 BOOTP-серверов на рабочих станциях под Unix, обслуживающих около 6000 IP-узлов в 90 подсетях.

Этим летом большинство общежитий в студенческом городке были объединены в сеть, что резко увеличило общее число узлов. Дэйв Мейерс, администратор сети, отвечающий за управление IP-адресами и университетские маршрутизаторы, надеется воспользоваться возможностями DHCP, автоматическим размещением, как только серверы DHCP станут более доступными. Сегодня SNMP в основном используется для опроса и управления маршрутизаторами, мостами и хабами, но вскоре в студенческом городке на его долю выпадет куда больше обязанностей.

Распространение Internet скоро сделает TCP/IP просто вездесущим. Пусть сетевые технологии на базе TCP/IP уступают по своим возможностям plug-and-play как AppleTalk, NetWare, так и другим популярным протоколам для ПК, зато они обеспечивают доступ по всему земному шару. Широко поддерживаемые протоколы BOOTP, DHCP и SNMP могут существенно облегчить для вашего предприятия управление расширяющейся вселенной IP.

ПРОТОКОЛЫ TCP/IP ДЛЯ УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ

ЧТО В ИМЕНИ ТВОЕМ?

BOOTP. Протокол Bootstrap Protocol (BOOTP) создавался для обеспечения получения бездисковыми рабочими станциями от BOOTP-сервера IP-адресов, имен и местоположения загрузочных файлов, IP-адресов шлюзов и других серверов, например, серверов Domain Name Service (DNS) и принт-серверов. Запротоколированный в RFC 951 (1985), он с тех пор постоянно дополнялся предложенными поставщиками расширениями, последняя версия которых опубликована в RFC 1533 (1993).

BOOTPARAM. Этот частный протокол на базе удаленного вызова процедуры (RPC) компании Sun Microsystems (Mountain View, CA) первоначально предназначался Sun для начальной загрузки бездисковых рабочих станций в паре с Reverse Address Resolution Protocol (RARP) и trivial file transfer protocol (tftp).

DCE. Протоколы распределенной вычислительной среды Distributed Computing Environment были разработаны Open Software Foundation (OSF) с присущими DCE особенностями удаленных вызовов процедур. Несмотря на громкое имя создателя, защищенность и богатый набор других сервисов, DCE не получил широкого распространения из-за высокой стоимости лицензии и объема кода, несколько большего для ПК.

DHCP. Dynamic Host Configuration Protocol создавался как надмножество и замена для BOOTP. DHCP поддерживает автоматическое присвоение адресов и выдачу краткосрочных лицензий на IP-адреса.

DNS. Domain Name System - это иерархическая децентрализованная служба имен, используемая в Internet для определения IP-адреса по имени.

NIS. Network Information Service, ранее называвшаяся Yellow Pages, была разработана SUN с использованием собственного механизма вызова удаленных процедур. NIS предназначалась для централизованного управления используемыми файлами и базами данных, включая списки хостов, пользователи/пароли и сервисы. NIS - частная служба, но лицензия на нее вместе с Network File System была предоставлена Sun нескольким сотням поставщиков, так что она имеется на большинстве Unix-систем.

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

RARP. Этот протокол предназначен для обеспечения получения бездисковыми рабочими станциями своего IP-адреса от RARP-сервера на базе аппаратного адреса Ethernet. (RFC 903 опубликован в 1984 году.).

SNMP. Simple Network Management Protocol используется для управления самыми разными TCP/IP-устройствами и сервисами. Многие TCP/IP-стеки на ПК имеют агентов SNMP, через которых можно получить полезную статистику для IP и хостов.

tftp. Введенный в обращение в 1982 году, trivial file transfer protocol позднее стал использоваться для обеспечения получения бездисковыми рабочими станциями файла с образом загрузки от tftp-сервера. Самозагрузка с использованием tftp описана в RFC 906 (1984).

НЕКОТОРЫЕ ДОПОЛНИТЕЛЬНЫЕ ВОЗМОЖНОСТИ

ХАРАКТЕРИСТИКИ BOOTP

Общие параметры хоста

Бездисковая загрузка

IP-адреса для серверов

Параметры уровня IP для хоста

Параметры уровня IP для интерфейса

Параметры уровня канала для интерфейса

СЕРВЕРЫ DHCP

Таблица 1.

ПОДДЕРЖКА УПРАВЛЕНИЯ КЛИЕНТА TCP/IP НА ПК

Таблица 2.