WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |

«1 ББК 32.973.26-018.2.75 Л42 УДК 681.3.07 Издательский дом "Вильяме" Зав. редакцией СИ. Тригуб Перевод с английского и редакция ...»

-- [ Страница 5 ] --

• netbios-name-server задает IP-адреса NetBIOS/WINS-серверов, которым NetBIOS клиенты (обычно это рабочие станции, работающие под управлением ОС Windows) могут посылать запросы относительно местонахождения ресурсов в сети;

• netbios-node-type задает рабочий режим NetBIOS-клиента в сети;

• default-router определяет IP-адреса маршрутизатора по умолчанию, которому клиенты могут переадресовывать пакеты с неизвестным пунктом назначения;

• lease задает срок, в течение которого динамически назначенные (lease — арендованные) адреса действительны без возобновления.

Каждая из субкоманд dns-server, netbios-name-sarver и default-router воспринимает в качестве параметров от одного до восьми IP-адресов, с которыми клиент может контактировать по каждой из этих функций. Параметром субкоманды domain-name является произвольная цепочка символов, представляющая имя DNS-домена для клиента. Субкоманда lease воспринимает в качестве параметров до трех целых чисел, которые задают количество дней, часов и минут, в течение которых назначенный адрес действителен. Может также быть использовано и ключевое слово infinit, свидетельствующее, что аренда адреса действительна неограниченный период времени.

Субкоманда netbios-node-type имеет параметром символьные значения b, р, m или h, которые обозначают, соответственно, широковещательный NetBIOS-узел, равноправный узел, смешанный узел и гибридный узел, чем определяется рабочий режим клиента. Если вы не знакомы с этими рабочими режимами, выбирайте гибридный режим.

Ниже показано, как следует конфигурировать маршрутизатор в Куала-Лумпуре с применением DHCP-субкоманд конфигурирования, чтобы обеспечить предоставление DHCP-клиентам информации о серверах в сети компании ZIP:

Kuala-Lumpur#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CNTL/Z.

Kuala-Lumpur(config)#ip dhcp pool kl-users Kuala-Lumpur(config-dhcp)#dns-server 131.108.101.34 131.108.101. Kuala-Lumpur(config-dhcp)#domain-name zipnet.com Kuala-Lumpur(config-dhcp)#netbios-name-server 131.108.21. Kuala-Lumpur(config-dhcp)#netbios-node-type h Kuala-Lumpur(config-dhcp)#default-router 131.108.2. Kuala-Lumpur(config-dhcp)#lease 0 Kuala-Lumpur(config-dhcp)#^Z Как упоминалось ранее, на одном DHCP-сервере ОС IOS может быть сконфигурировано несколько DHCP-пулов адресов. Группу DHCP-пулов адресов на таком сервере называют DHCP базой данных. DHCP-база данных организована по иерархической или древовидной структуре, так что один адресный пул может быть подсетью сетевого адреса другого DHCP-пула адресов.

Иерархическая структура позволяет пулу адресов, являющемуся подсетью другого пула, наследовать свойства. Свойства, которые являются общими для нескольких пулов, должны задаваться на самом высоком сетевом или подсетевом уровне конфигурируемого DHCP-сервера или сети. Вместе с тем, свойства, заданные на более высоком уровне, могут быть отменены на более низком подсетевом уровне. Рассмотрим этот аспект на примере маршрутизатора компании ZIP в Куала-Лумпуре.

В предыдущем примере был задан адресный пул kl-users для сети с адресом 131.108.2.0/25.

Отдельно были заданы такие дополнительные свойства, как DNS-серверы, маршрутизатор по умолчанию и так далее. Для создания второго пула адресов с сетевым адресом 131.108.2.128/25 в будущем пришлось бы снова задавать для него эти свойства, так как он не является подсетью ранее заданного пула. Таким образом, конфигурация маршрутизатора в Куала-Лумпуре приобрела бы следующий вид:

Kuala-Lumpur#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CNTL/Z.

Kuala-Lumpur(config)#ip dhcp excluded-address 131.108.2.129 131.108.2. Kuala-Lumpur(config)#ip dhcp pool kl-users- Kuala-Lumpur(config-dhcp)#network 131.108.2.128/ Kuala-Lumpur(config-dhcp)#dns-server 131.108.101.34 131.108.101. Kuala-Lumpur(config-dhcp)#domain-naine zipnet.com Kuala-Lumpur(config-dhcp)#netbios-name-server 131.108.21. Kuala-Lumpur(config-dhcp)#netbios-node-type h Kuala-Lumpur(config-dhcp)#default-router 131.108.2. Kuala-Lumpur(config-dhcp)#lease 0 Kuala-Lumpur(config-dhcp)#^Z При конфигурировании пула адресов kl-users-2 используется ряд команд, параметры которых совпадают с параметрами для пула kl-users, что делает назначаемые такими субкомандами свойства идентичными.

Чтобы исключить повторение субкоманд при конфигурировании пулов kl-users и kl-users-2, эти пулы адресов можно переконфигурировать так, чтобы они стали подсетями другого пула сетевых адресов. Для этого понадобятся только те субкоманды, которые задают свойства, являющиеся уникальными для каждого из этих пулов. Для маршрутизатора в Куала-Лумпуре будет задаваться пул адресов для сетевого адреса 131.108.2.0/24, при этом будут задаваться только те свойства, которые будут наследоваться подсетевыми адресными пулами. Таким образом, задание пулов адресов kl users и kl-users-2 сведется всего к двум субкомандам вместо семи.

Ниже показан пример переписанных DHCP-пулов адресов на маршрутизаторе в Куала-Лумпуре, где адресные пулы kl-users и kl-users-2 будут наследовать свойства пула адресов, названного kl common:

Kuala-Lumpur#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CNTL/Z.

Kuala-Lumpur(config)#ip dhcp pool lei-common Kuala-Lumpur(config-dhcp)#network 131.108.2.0/ Kuala-Lumpur(config-dhcp)#dns-server 131.108.101.34 131.108.101. Kuala-Lumpur(config-dhcp)#domain-name zipnet.com Kuala-Lumpur(config-dhcp)#netbios-name-server 131.108.21. Kuala-Lumpur(config-dhcp)#netbios-node-type h Kuala-Lumpur(config-dhcp)#lease 0 Kuala-Lumpur(config-dhcp)#ip dhcp pool kl-users Kuala-Lumpur(config-dhcp)#network 131.108.2.0/ Kuala-Lumpur(config-dhcp)#default-router 131.108.2. Kuala-Lumpur(config-dhcp)#ip dhcp pool kl-users- Kuala-Lumpur(config-dhcp)#network 131.108.2.128/ Kuala-Lumpur(config-dhcp)#default-router 131.108.2. Kuala-Lumpur(config-dhcp)# ^Z В этом примере благодаря тому, что сети 131.108.2.0/25 и 131.108.2.128/25 являются подсетями сети 131.108.2.0/24, соответствующие пулы адресов будут наследовать общие свойства пула более высокого уровня иерархии. И только субкоманда default-router используется для задания своего IP-адреса, соответствующего каждому подсетевому адресному пулу.

После того как пулы адресов и их свойства заданы, и DHCP-сервер ОС IOS начал присваивать IP-адреса, работу DHCP-сервера можно верифицировать с помощью нескольких команд режима EXEC ОС IOS. Верификация того, что DHCP-сервер ОС IOS производит протоколирование информации о привязках и конфликтах на занесенной в конфигурацию рабочей станции или на сервере, выполняется с помощью команды режима EXEC ОС IOS show ip dhcp database. Для вывода на экран информации о конкретной базе данных протоколирования этой команде требуется параметр URL. Если параметр не указывается, то выводится информация обо всех су ществующих узлах протоколирования. Ниже показан пример исполнения команды show ip dhcp database на маршрутизаторе компании ZIP в Куала-Лумпуре:

Kuala-Lumpur>show ip dhcp database URL : tftp://131.108.2.77/kl-dhcp-info Read : Never Written : Jun 30 2000 12:01 AM Status : Last Write Successful.

Delay : 300 seconds Timeout : 300 seconds Failures : Successes : Kuala-Lumpur> В выводимой командой show ip dhcp database информации указывается местонахождение узла с данными о привязке, дате и времени последнего чтения или записи в базе данных привязок, статусе последнего чтения или записи и количестве успешных завершений и неудач при попытке сделать запись в базе данных привязок. Информацию о конкретном назначении адреса можно просмотреть, используя команду режима EXEC ОС IOS show ip dhcp binding. Если для этой команды указать в качестве необязательного параметра IP-адрес, то будет показана информация о привязке для этого конкретного адреса. В противном случае выводится вся информация о привязках. Ниже приводится пример исполнения команды show ip dhcp binding на маршрутизаторе компании ZIP в Куала-Лумпуре, где в выводимой информации показываются текущие данные о выделенных и назначенных адресах, соответствующий МАС-адрес DHCP клиента и время истечения срока аренды адреса:

Kuala-Lumpur>show ip dhcp binding IP address Hardware address Lease expiration Type 131.108.2.89 OOaO.9802.32de Jul 01 2000 12:00 AM Automatic 131.108.2.156 OOaO.9478.43ae Jul 01 2000 1:00 AM Automatic Kuala-Lumpur> Информацию о конфликтах адресов, которые имели место, когда DHCP-сервер ОС IOS пытался назначить адрес DHCP-клиенту, можно просмотреть с помощью команды show ip dhcp conflict. Если этой команде в качестве необязательного параметра указывается IP-адрес, информация о конфликтах показывается только по этому адресу (если таковая имеется);

в противном случае выводится вся информация о конфликтах. Ниже приведен пример исполнения команды show ip dhcp conflict на маршрутизаторе компании ZIP в Куала Лумпуре, где указывается конфликтный IP-адрес, время обнаружения конфликта и метод, с помощью которого конфликт был обнаружен.

Kuala-Lumpur>show ip dhcp conflict IP address Detection Method Detection time 131.108.2.126 PingJul 02 2000 12:28 AM 131.108.2.254 Gratuitous ARP Jul 02 2000 01:12 AM Kuala-Lumpur> В столбце Detection Method (Метод обнаружения) указывается метод, использованный DHCP-сервером ОС IOS для определения конфликтности адреса. Если указан метод обнаружения ping, то это говорит о том, что перед назначением адреса DHCP-сервер сделал попытку пропинговать этот адрес и получил успешный ответ. Метод обнаружения Gratuitious ARP (метод беспричинного разрешения адреса) означает, что до выделения адреса DHCP сервер ОС IOS обнаружил в своей ARP-таблице текущую и достоверную ARP-запись для этого адреса. Наличие ссылки на любой из этих методов говорит о том, что адрес, вероятно, используется (может быть, это результат несанкционированного использования, а возможно, кто-то забыл внести адрес в список исключаемых адресов).

Верификация того, что DHCP-сервер ОС IOS принимает и отвечает на DHCP-запросы, может быть выполнена с помощью команды ОС IOS режима EXEC show ip dhcp server statistics. Эта команда поставляет такую полезную информацию, как количество сконфигурированных пулов адресов, объем памяти, занимаемый базой данных DHCP-привязок, а также данные счета количества DHCP-сообщений разных типов, которые были получены или отосланы. Ниже приведен пример результата исполнения команды show ip dhcp server statistics на маршрутизаторе компании ZIP в Куала-Лумпуре:

Kuala-Lumpur>show ip dhcp server statistics Memory usage Address pools Database agents Automatic bindings Manual bindings Expired bindings Malformed messages Message Received BOOTREQUEST DHCPDISCOVER DHCPREQUEST DHCPDECLINE О DHCPRELEASE О DHCPINFORM Message Sent BOOTREPLY DHCPOFFER DHCPACK DHCPNAK Kuala-Lumpur> Резервное дублирование в IP-сетях с помощью протокола маршрутизатора горячего резерва Многих сетевых администраторов беспокоит наличие в сети точек критических отказов. Они всеми силами пытаются обеспечить в ключевых узлах наличие как резервных путей, так и резервного оборудования, стараясь не допустить, чтобы одно устройство послужило причиной недоступности жизненно важных ресурсов сети. Маршрутизаторы (и некоторые серверы) весьма неплохо справляются с многообразием IP-путей, обмениваясь информацией динамической маршрутизации о различных путях по сети, выбирая наилучший на данный момент времени путь или пути и выполняя перемаршрутизацию, если путь изменился в результате отказа оборудования или канала.

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

Чтобы помочь сетевым администраторам справляться с подобной неприятной ситуацией, компанией Cisco Systems был разработан протокол маршрутизатора горячего резерва (Hot Standby Router Protocol — HSRP). Протокол HSRP был спроектирован для сегментов локальных сетей, в которых присутствует несколько маршрутизаторов и стоят устройства, использующие только статически задаваемый IP-адрес шлюза по умолчанию.

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

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

Рассмотрим конфигурирование протокола HSRP на маршрутизаторах компании ZIP, находящихся в Сеуле. В Сеуле два маршрутизатора (Seoul-1 и Seoul-2) подключены к одной и той же логической IP-сети 131.108.3.0. Наличие двух или нескольких маршрутизаторов, которые могут выполнять роль шлюзов по умолчанию, является первой частью критериев для конфигурирования протокола HSRP. Другой частью критериев является присутствие в сети IP устройств, которые могут поддерживать только один IP-адрес шлюза по умолчанию. В данном случае принтеры, серверы и ПК-рабочие станции удовлетворяют этому критерию.

Для базового конфигурирования протокола HSRP требуется только одна субкоманда конфигурирования интерфейсов ОС IOS standby ip. Эта команда имеет параметром IP-адрес, который будет использоваться в качестве виртуального IP-адреса шлюза по умолчанию. Команда применяется в отношении всех маршрутизаторов в одной логической IP-сети, которые будут членами одной HSRP-группы. Ниже приведен пример конфигурирования протокола HSRP на маршрутизаторах компании ZIP Seoul-1 и Seoul-2 путем задания командой standby ip виртуального IP-адреса 131.108.3.3:

Seoul-l#configrure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CNTL/Z.

Seoul-1(config)#interface ethernet Seoul-1(config-if)#standby ip 131.108.3. Seoul-1(config-if)# AZ Seoul-2#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CNTL/Z.

Seoul-2(config)#interface ethernet Seoul-2(config-if)#standby ip 131.108.3. Seoul-2(config-if)#^Z После конфигурирования резервного HSRP-адреса определяется, какой маршрутизатор будет первичным переадресующим, а какой — резервным. Оба маршрутизатора вводят в свои ARP таблицы IP-адрес и МАС-адрес для виртуального IP-адреса. Первичный переадресующий маршрутизатор начинает переадресацию трафика, посылаемого на виртуальный IP-адрес, а также отвечает на пинги и принимает сеансы виртуального терминала по этому адресу.

Заметим, что МАС-адрес для виртуального IP-адреса на интерфейсах Ethernet, Fast Ethernet, Gigabit Ethernet и FDDI имеет форму 0000. Oc07.acXX, где хх представляет собой идентификатор HSRP-группы. МАС-адрес для виртуального IP-адреса на интерфейсе Token Ring представляет собой функциональный адрес вида 1000.хххх.хххх. Ниже приведен пример исполнения команды show ip arp 131.108.3.3 на маршрутизаторе компании ZIP Seoul-1 со сконфигурированным протоколом HSRP:

Seoul-l#show ip arp 131.108.3. Protocol Address Age (min) Hardware Addr Type Interface Internet 131.108.3.3 - 0000.Oc07.acOO ARPA EthernetO Seoul-l# Совет Некоторые устройства в сетях Token Ring не воспринимают МАС-адрес IP-устройства в качестве группового функционального адреса. В этом случае следует использовать субкоманду конфигурирования интерфейса ОС IOS standby use-bia, чтобы заставить виртуальный IP-адрес протокола HSRP использовать адрес, занесенный в ППЗУ интерфейса, что ограничивает количество HSRP-rpyпп на интерфейсе до одной.

Как упоминалось ранее, администратор сети имеет несколько опций конфигурирования, которые управляют поведением в рамках протокола HSRP. Для выбора первичного переадресующего маршрутизатора используется субкоманда конфигурирования интерфейса ОС IOS standby priority. Эта команда имеет параметром значение приоритета, лежащее в пределах от 0 до 255. Маршрутизатор из HSRP-группы с наивысшим приоритетом становится переадресующим маршрутизатором. В нашем примере маршрутизатор компании ZIP Seoul-1 конфигурируется значением HSRP-приоритета 100, а маршрутизатору Seoul-2 присваивается приоритет 95, в результате чего активным переадресующим маршрутизатором становится маршрутизатор Seoul-1:

Seoul-1#configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z.

Seoul-1(config)#interface ethernet Seoul-1(config-if)#standby priority Seoul-1(config-if)#^ Seoul-2#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CNTL/Z.

Seoul-2(config)#interface ethernet Seoul-2(config-if)#standby priority Seoul-2(config-if)#^Z Если требуется, чтобы резервный маршрутизатор стал активным, то он автоматически перебирает на себя эту роль. Можно управлять и тем, становится ли бывший ранее первичным маршрутизатор активным переадресующим после того, как вновь стал доступным. Для того чтобы маршрутизатор становился активным переадресующим вместо маршрутизатора с меньшим значением приоритета, используется субкоманда конфигурирования интерфейсов ОС IOS standby preempt. В нашем примере маршрутизатор Seoul-2 имеет меньший приоритет, чем маршрутизатор Seoul-1. Если маршрутизатор Seoul-1 отказывает, то роль активного переадресующего берет на себя маршрутизатор Seoul-2. Без команды standby preempt маршрутизатору Seoul-1 маршрутизатор Seoul-2 сохранит роль активного переадресующего. В примере ниже команда standby preempt приведет к тому, что маршрутизатор компании ZIP Seoul-1 станет активным переадресующим после восстановления, так как у него более высокое значение HSRP-приоритета:

Seoul-1#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CNTL/Z.

Seoul-1 (config)#interface ethemet Seoul-1(config-if)#standby preempt Seoul-1(config-if)#^Z В некоторых ситуациях рабочий статус интерфейса непосредственно влияет на то, какой маршрутизатор должен играть роль активного переадресующего. Это происходит, когда каждый из маршрутизаторов в HSRP-группе имеет свой отличающийся путь к другим частям сети. В сети компании ZIP маршрутизатор Seoul-1 имеет соединение с маршрутизатором в Сан-Хосе, который, в свою очередь, связан с Сан-Франциско. Маршрутизатор Seoul-2 имеет прямую связь с Сан Франциско и Сан-Хосе. Если в маршрутизаторе Seoul-1 соединение через интерфейс глобальной сети деградирует или выходит из строя, то пакеты, посылаемые на маршрутизатор Seoul-1, активный переадресовывающий маршрутизатор, не могут достичь Сан-Франциско или Сан-Хосе. В конце концов, работа протоколов динамической маршрутизации приведет к тому, что маршрутизатор Seoul-1 начнет слать пакеты маршрутизатору Seoul-2 для пересылки по его работоспособному интерфейсу глобальной сети. Но такая реконвергенция может занять несколько минут и нарушить нормальный поток сетевого трафика. Однако, если бы маршрутизатор Seoul-2 смог перебрать на себя роль активного переадресующего, то он смог бы немедленно переадресовывать пакеты в Сан Франциско и Сан-Хосе через свое функционирующее соединение по интерфейсу глобальной сети.

ОС IOS имеет HSRP-функцию, которая может заставить маршрутизатор Seoul-1 отрегулировать свой HSRP-приоритет в HSRP-группе на интерфейсе Ethernet 0 так, что активным переадресующим маршрутизатором станет маршрутизатор Seoul-2. Эта функция — отслеживание интерфейса — активизируется субкомандой конфигурирования интерфейса ОС IOS standby track.

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

Ниже приведен пример конфигурирования команды standby track на маршрутизаторе компании ZIP Seoul-1 таким образом, чтобы в случае выхода из строя интерфейса глобальной сети Serial 1 активным переадресующим маршрутизатором становился маршрутизатор Seoul-2:

Seoul-l#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CNTL/Z.

Seoul-1 (config) #interface ethemet Seoul-1(config-if)#standby track serial Seoul-1(config-if) #^Z Верифицировать работу протокола HSRP можно с помощью команды режима EXEC ОС IOS show standby. Эта команда имеет необязательный параметр, в качестве которого указывается название конкретного интерфейса, для которого требуется вывести информацию о деятельности протокола HSRP. Если название интерфейса не указывается, то информация о работе протокола HSRP выводится для всех интерфейсов. Ниже показан пример информации, выводимой командой show standby на маршрутизаторах Seoul-1 и Seoul-2:

Seoul-l#show standby EthernetO - Group Local state is Active, priority 100, may preempt Hellotime 3 holdtime Next hello sent in 00:00:01. Hot standby IP address is 131.108.3.3 configured Active router is local Standby router is 131.108.3.2 expires in 00:00: Tracking interface states for 1 interface, 1 up:

Up SerialO Seoul-l# Seoul-2#show standby EthernetO - Group Local state is Standby,priority 95, may preempt Hellotime 3 holdtime Next hello sent in 00:00:01. Hot standby IP address is 131.108.3.3 configured Active router is 131.108.3.1 expires in 00:00: Standby router is local Seoul-2# Команда show standby выводит разнообразную информацию протокола HSRP, включая состояние переадресации, HSRP-приоритет и названия отслеживаемых интерфейсов на запрашиваемом маршрутизаторе. Также выводится сконфигурированный виртуальный IP адрес и IP-адрес (адреса) возможных резервных маршрутизаторов внутри каждой HSRP группы.

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

Чтобы решить эту проблему, в ОС IOS была добавлена возможность поддержки на одном интерфейсе нескольких HSRP-групп. На одном интерфейсе можно создавать несколько HSRP групп, причем каждую со своим отличающимся виртуальным IP-адресом, чтобы резервировать друг друга. Например, если взять маршрутизаторы компании ZIP Seoul-1 и Seoul-2, первая HSRP группа может иметь виртуальный IP-адрес 131.108.3.3 с маршрутизатором Seoul-1, назначенным в качестве первичного переадресуюшего из-за его более высокого HSRP-приоритета. Можно сконфигурировать вторую HSRP-группу с виртуальным IP-адресом 131.108.3.4, но с маршрутизатором Seoul-2, выделенным в качестве первичного переадресующего маршрутизатора с помощью присвоения ему во второй HSRP-группе более высокого HSRP-приоритета, чем у маршрутизатора Seoul-1. Тогда в первой HSRP- группе Seoul-1 будет активным переадресующим маршрутизатором, a Seoul-2 — резервным, и одновременно во второй HSRP- группе Seoul-2 будет активным переадресующим маршрутизатором, a Seoul-1 — резервным.

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

Несколько HSRP-групп создаются опционным заданием номера группы во всех командах standby. Например, команды standby I ip address 131.108.3.3 И standby 1 priority показывают, что эти HSRP-команды используются для групп с резервированием ПОД номером 1. Команды standby 2 ар address 131.108.3.4 и standby 2 priority 100 показывают, что эти HSRP-команды применяются в отношении группы с резервированием под номером 2.

Резюме В данной главе на примере сети компании ZIP были рассмотрены базовые конфигурации некоторых наиболее общих элементов сетевого протокола TCP/IP. Что касается всех технических особенностей ОС IOS, существуют сотни дополнительных субфункций и кнопок, которые администратор сети может конфигурировать, чтобы улучшить работу сети и маршрутизатора.

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

• IP-адреса являются десятичными представлениями 32-разрядных двоичных чисел. Они группируются в блоки сетевых адресов и делятся на категории в соответствии с конкретными классами сетей. Сетевые администраторы могут распределять адресное пространство сети между несколькими сегментами локальной или глобальной сети, используя для этого технику подсетей.

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

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

• Конфигурирование IP-маршрутизации позволяет маршрутизатору реализовывать функцию коммутации IP-пакетов. Для построения таблицы сетевых адресов пунктов назначения, называемой таблицей маршрутизации, могут использоваться статические маршруты.

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

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

Протоколы динамической маршрутизации подразделяются на две основные категории:

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

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

• Основные IP-службы удаленного доступа по коммутируемым каналам позволяют удаленным пользователям иметь доступ в сеть через модемы и ISDN-каналы, если те подключены к среде локальной сети.

• Верификация IP-взаимодействия может осуществляться с помощью таких команд, как show ip route и ping. Диагностические возможности команд trace и debug позволяют сетевому администратору обнаруживать ошибки конфигурирования и идентифицировать проблемы, возникающие как в маршрутизаторах, так и в сети.

• Такие IP-функции, как служба имен доменов, облегчают решение задачи поддержки, возложенной на плечи администратора сети. Функция переадресации широко вещательных пакетов позволяет службам с широковещательной рассылкой, например DHCP, работать в маршрутизируемых сетях. Входящий в состав ОС IOS DHCP-сервер обеспечивает для сетей малого и среднего размера реализацию функции динамического назначения адресов самим маршрутизатором или сервером доступа На рабочих станциях, которые не поддерживают протоколы динамической маршрутизации, протокол маршрутизатора горячего резерва Hot Standby Router Protocol обеспечивает устойчивость к отказам и резервное дублирование.

• В табл. 4 8 приводятся основные команды режима EXEC для протокола IP Таблица 4.8. Сводная таблица команд режима EXEC для протокола IP Команда Описание Удаляет временные записи из таблицы IP-хост-машин clear host строки списка IP-доступа Обнуляет счетчики удовлетворения критериев Clear ip access list counters каждой Очищает всю таблицу маршрутизации или удаляет конкретный маршрут clear ip route Проверяет указанный IP-адрес на предмет его достижимости и способности ping ip-адрес отвечать show {frame-relay | atm | х25 | Показывает отображения IP-адресов на адреса канального уровня для заданного типа среды глобальной сети dialer) map Показывает все списки доступа, заданные на маршрутизаторе show access-list Верифицирует конфигурацию службы DNS на маршрутизаторе и выводит на show host экран список хост-машин, именам которых были поставлены в соответствие IP-адреса show interface интерфейс Обеспечивает общую информацию об интерфейсе, включая IP-адрес и сетевую маску Показывает все списки IP-доступа, заданные на маршрутизаторе show ip access-list Выводит на экран все IP-адреса, которые маршрутизатор смог преобразовать show ip arp в МАС-адреса Выводит на экран информацию обо всех назначениях адресов, сделанных show ip dhcp binding DHCP-сервером ОС IOS Выводит на экран информацию о конфликтах IP-адресов, обнаруженных show ip dhcp conflict DHCP-сервером ОС IOS во время процесса выделения адресов Выводит на экран информацию о местонахождении и статусе базы данных, show ip dhcp database используемой DHCP-сервером ОС IOS для протоколирования DHCP привязок и конфликтов Выводит на экран информацию о статусе и результаты счета, связанные с show ip dhcp server statistics работой DHCP-сервера ОС IOS Показывает краткое резюме информации об IP-адресах и статусах всех show ip interface brief интерфейсов, имеющихся на устройстве show ip interface интерфейс Показывает все параметры, связанные с IP-конфигурацией интерфейса show ip masks сетевой адрес Дает список сетевых масок, которые были применены в отношении названной сети и количество маршрутов, использовавших каждую маску Показывает исполняемые протоколы маршрутизации и различные их show ip protocols атрибуты При использовании с ключевым словом summary показывает только названия протоколов и числа, соответствующие идентификаторам процессов Выводит данные таблицы IP-маршрутизации маршрутизатора show ip route Показывает маршруты, связанные с находящимися в рабочем состоянии и show ip route connected непосредственно подключенными интерфейсами маршрутизатора Выдает информацию о маршрутизации для заданного маршрута show ip route ip-адрес Показывает данные о маршрутах, полученных на основании команд show ip route static конфигурирования сетевых маршрутов вручную Показывает обобщенные статистические данные работы маршрутизатора в show ip traffic рамках протокола IP Выводит на экран информацию о работе протокола HSRP show standby Задает формат отображения сетевых масок, который будет использоваться во terminal ip netmask-format {decimal время текущего сеанса виртуального терминала или сеанса консоли I bit-count | hexidecimal} Выводит на экран каждый этап сетевого пути, который проходит пакет, trace ip-адрес добираясь до указанного IP-адреса В табл.

4. 9 приведены команды конфигурирования протокола IP Таблица 4.9. Сводная таблица команд конфигурирования протокола IP Команда Описание Определяет, что аутентификация в рамках протокола aaa authentication ppp метод из списка ррр должна выполняться с использованием приведен ного метода Задет что сетевые службы должны аутентифицироваться aaa authorization network метод с использованием приведенного ААА-метода Создает нумерованный список доступа и связанные с access-list ним критерии фильтрации Идентифицирует ATM ARP-сервер, который может пре arp-server образовывать IP-адреса в ATM NSAP-адреса Задает на глобальной основе IP-адрес (адреса) DNS asyn c-b oot p d ns -se rve r ip адрес сервера, который будет предоставляться удаленным клиентам при установлении связи по звонку Задает на глобальной основе IP-адрес (адреса) async-bootp nbns-server ip адрес NetBIOS/WINS-сервера имен, который будет предостав ляться удаленным клиентам при установлении связи по звонку Устанавливает метод взаимодействия с пользователями async mode {interactive | на асинхронном интерфейсе для удаленных пользова dedicated} телей, работающих с коммутируемыми каналами связи Задает выполнение процесса автовыбора во время про autoselect during-login цесса аутентификации autoselect ррр Задает автовыбор протокола РРР для асинхронной ли нии, сконфигурированной на работу в интерактивном режиме Определяет попытку переговоров относительно алго compress ритма сжатия данных во время установления удаленного соединения по коммутируемой линии при использовании протокола РРР Определяет значения метрики маршрутизации по умол default-metric чанию, которые должны использоваться при редистрибуции маршрутов между протоколами динамической маршрутизации адp ec Задает один или несколько IP-адресов маршрутизаторов default-router по умолчанию, которые поставляются DHCP-клиентам DHCP сервером ОС IOS dialer-group целочисленное Задает номер группы интерфейсов вызова по номеру, к значение которой принадлежит интерфейс, и номер списка сете вых протоколов, трафик в рамках которых следует счи тать интересным dialer-lis t номер списка Задает список, который определяет сетевые протоколы protocol типовой метод и методы, используемые для определения того, что трафик представляет интерес для сеансов удаленного доступа по коммутируемой линии Отображает IP-адрес в имя системы и номер телефона dialer map ip для ISDN-соединений Приписывает интерфейс ISDN к групповой структуре ин dialer rotary-group целочисленное значение терфейсов вызова по номеру Накладывает список доступа на задачу приема и объяв distribute-list ления сетевых маршрутов dns-server адрес Задает один или несколько IP-адресов DNS-серверов, которые поставляются DHCP-клиентам DHCP-сервером OCIOS domain-name имя домена Задает DNS-имя домена, которое поставляется DHCP клиентам DHCP-сервером ОС IOS Задает метод управления потоком в асинхронной линии flowcontrol {hardware | software) Отображает IP-адрес на DLCI-идентификаторы интер frame-relay map ip фейса Frame Relay group-range начало конец Задает асинхронные интерфейсы, включаемые в груп повой асинхронный интерфейс Накладывает указанный список доступа на задачу ip access-group list фильтрации входящих или исходящих пакетов интер (in I out} фейса Создает именованный список IP-доступа и связанные с ip access-list {extended | standard} имя ним критерии фильтрации ip address ip-адрес сетевая Назначает IP-адрес и сетевую маску интерфейсам ло маска кальных и глобальных сетей Позволяет маршрутизатору работать в бесклассовом ip classless режиме, когда IP-адреса пунктов назначения отвечают суперсетевым маршрутам или маршрутам, определяемым CIDR-блоками Заставляет протокол OSPF генерировать маршрут по ip default-information умолчанию из пограничного маршрутизатора автоном originate ной системы в остальную часть OSPF-домена ip default-network сетевой Конфигурирует заданный сетевой адрес в качестве адрес сводной сети или сети по умолчанию Активирует или деактивирует в DHCP-сервере ОС IDS {no} ip dhcp conflxct функцию протоколирования информации о конфликтах logging адресов Задает местонахождение базы данных и метод протоко ip dhcp database url лирования информации о привязках сделанных DHCP сервером и конфликтах Задает один или несколько IP-адресов которые ip dhcp excluded-address должны быть исключены из предложений DHCP-клиентам от DHCP-сервера ОС IOS i p d h c p p o o l имя Создает DHCP-пул адресов, который может быть скон фигурирован с помощью дополнительных субкоманд DHCP конфигурирования Задает IP-адрес DHCP-сервера который может динами ip d hcp -se rve r i p-a dpe c чески назначать IP-адреса удаленным клиентам рабо тающим по коммутируемым каналам связи i p d o m a i n - l x s t имя Устанавливает список имен доменов для присоединения к именам неопознанных хост-машин Активирует работу DNS-службы ip d oma in- loo kup ip domain-name имя Конфигурирует имя первичного домена которое будет присоединяться к именам неопознанных хост-машин Управляет типом широковещательных UDP-пакетов ко ip forward-protocol udp торые будут переадресовываться type ip helper-address ip адрес Переадресует широковещательные UDP-пакеты по за данному IP-адресу Конфигурирует статическое отображение имени хост ip host машины в IP-адрес (адреса) Создает пул IP-адресов для динамического ip local pool (default | pool-name} начальный назначения ip-адрес конечный ip-adpec IP-адресов удаленным клиентам работающим по коммутируемым каналам связи Конфигурирует DNS-сервер (серверы) имен ip name-server ip-adpec ip netmask-format {decxmal Конфигурирует формат отображения сетевых масок | во время сеансов виртуального терминала или bxt-count | hexxdecxmal} консольных сеансов Конфигурирует тип сети с широковещанием без ip ospf network {broadcast широковещания и из точки многим которая для | non-broadcast протокола подключена к интерфейсу |p o x n t - t o - m u l t i p o i n t } OSPF Задает номер версии протокола RIP для отправки и ip rip {send I recexve) приема через конкретный интерфейс versxon Конфигурирует маршрут по умолчанию 0.0.0. ip route 0.0.0.0 0.0.0. ip-adpec пункта назначения ip route сетевой адрес сетевая Конфигурирует статический маршрут маска ip-адрес пункта назначения ip route сетевой адрес сетевая Конфигурирует сводный маршрут используя в маска подсетевои ip-adpec качестве параметра сводный маршрут сетевую маску и неподключенную подсеть Активирует в маршрутизаторе функцию IP- маршрути ip routing зации Позволяет назначить интерфейсу первую подсеть из ip subnet-zero диапазона сетевых адресов (нулевую подсеть) ip unnumbered интерфейс Конфигурирует ненумерованный двухточечный IP интерфейс глобальной сети Назначает интерфейсу именованную группу отображе map-group ний для использования им в процессе отображения IP адресов на ATM-адреса канального уровня Создает именованный список отображений для конфи map-list гурирования отображения IP-адресов на постоянные или коммутируемые виртуальные каналы в процессе ATM адресации Задает тип автоматического конфигурирования модема modem autooonf igure {discovery | тип модема] подключенного к асинхронной линии по распознаванию или с помощью установок для названного типа модема Задает разрешенное направление асинхронных m o d e m { d ai l in | i n o ut ) вызовов по звонку Задает IP-адрес соседнего маршрутизатора для обмена neighbor ip-adpec информацией динамической маршрутизации Позволяет вводить комментарии в BGP-команде neighbor neighbor ip-adpec description Позволяет осуществлять фильтрацию для каждого од neighbor ip-adpec норангового BGP-соседа отдельно distribute-list Конфигурирует соседний маршрутизатор с neighbor ip-adpec remote-as указанным адресом в указанной автономной asn системе в качестве однорангового BGP маршрутизатора Указывает что IP-адрес источника для neighbor ip-adpec update source интерфейс установления сеанса BGP-обмена между одноранговыми маршрутизаторами следует брать из названного интерфейса адрес Задает один или несколько IP-адресов netbios-name-server NetBIOS/WINS-сервера для предоставления DHCP клиентам DHCP-сервером ОС IOS netbios-no de-type т ип Задает режим поведения NetBIOS, сообщаемый DHCP клиентам DHCP-сервером ОС IOS network сетевой адрес Указывает, что подключенные интерфейсы, адреса ко торых согласуются с заданным сетевым адресом, должны быть включены в маршрутные объявления network сетевой адрес area Указывает, что подключенные интерфейсы, адреса номер области которых согласуются с заданным сетевым адресом, должны включаться в маршрутные объявления по протоколу OSPF, и интерфейсы должны быть приписаны к заданной области network номер сети [маска | Задает диапазон IP-адресов, которые будут префикс длины} предлагаться DHCP-клиентам DHCP-сервером из заданного DHCP-пула адресов Запрещает автоматическое сведение адресов на грани no auto-summary цах класса сети и разрешает передачу информации о подсетях Отключает функцию динамического отображения IP-адре no inverse-arp сов в DLCI-идентификаторы на интерфейсе Frame Relay passive-interface интерфейс Конфигурирует маршрутизатор таким образом, чтобы он слушал, но не объявлял маршрутную информацию на заданном интерфейсе Задает метод, используемый для назначения IP-адреса peer default ip удаленной рабочей станции клиента, работающей по address {pool | dhcp | коммутируемым каналам связи ip-adpec} ррр autentication метод Указывает на то, что РРР-аутентификация должна вы полняться до начала работы сетевых служб Между сервером доступа и удаленным клиентом используется названный протокол аутентификации ррр ipcp {dns Задает поставку IP-адреса (адресов) DNS или I wins} удаленным клиентам во время NetBIOS/WINS-серверов установления РРР-сеанса на поинтерфейсной основе ррр multilink Свидетельствует о необходимости активации на интер фейсе программного мультиплексирования каналов Активирует редистрибуцию маршрутов из указанного redistribute protocol протокола Разрешает маршрутизатору исполнение заданного про router {rip | igrp | ospf токола динамической маршрутизации | eigrp | bgp) speed бит в секунду Задает скорость передачи по асинхронной линии Конфигурирует указанный IP-адрес в качестве вирту standby ip ip-adpec ального IP-адреса для HSRP-группы Заставляет маршрутизатор с более высоким значением standby preempt HSRP-приоритета перебирать на себя роль активного переадресующего после того, как он вновь становится доступным standby priority приоритет Назначает значение приоритета HSRP-маршрутизатору для управления процессом выбора первичного переад ресующего маршрутизатора standby track интерфейс Активирует динамическую регулировку HSRP-приорите та на основе рабочего статуса заданного интерфейса Осуществляет принудительное восприятие аппаратно s t a n b y u s e- b i a запрограммированного МАС-адреса интерфейса в качестве виртуального IP-адреса Активирует или отменяет требование предварительного {no} synchronization обучения маршрутизаторов через IGP-процесс маршрутизации до объявления маршрутов EBGP-соседям username имя пользователя Задает локальное значение пары имя пользовате password слово ля/пароль для использования в процессе аутентифика ции удаленного пользователя version версия протокола RIP Задает номер версии протокола RIP, использующегося на маршрутизаторе, для которого разрешено исполнение этого протокола х25 map ip Отображает IP-адрес на адрес протокола X Дополнительная литература Поставленные в данной главе вопросы более подробно рассматриваются в следующих изданиях.

1. Bellovin, S.M., and W.R. Cheswick, Firewalls and Internet Security: Repelling the Wily Hacker. Reading, Massachusetts: Addison-Wesley, 1994.

2. Comer, D.E. Internetworking with TCP/IP. Volume I, Fourth Edition. Englewood Cliffs, New Jersey: Prentice Hall, 2000. (Готовится к изданию перевод на русский язык этой книги, который выйдет в свет в ИД "Вильяме" в начале 2002 года. — Прим ред.) 3. Сэм Хелеби, Денни Мак-Ферсон. Принципы маршрутизации в Internet, 2-е изда ние. ИД "Вильяме", 2001 г.

4. Halabi В., and D. McPherson. Internet Routing Architectures, Second Edition Indianapolis, Indiana: Cisco Press, 2000.

5. Zwicky, E.D., et al. Building Internet Firewalls, Second Edition. Sebastopol, California:

O'Reilly & Associates, 2000.

Глава Ключевые темы этой главы • Система адресации и структура адресов в протоколе AppleTalk Основы структуры адресов протокола AppleTalk и структура сети • Конфигурирование адресов для протокола AppleTalk Обзор схемы адресации протокола AppleTalk, а также примеры конфигурирования адресов для интерфейсов глобальных и локальных сетей различных типов • Конфигурирование маршрутизации по протоколу AppleTalk Основы конфигурирования маршрутизации по протоколу AppleTalk с использованием статических маршрутов и верификация AppleTalk-маршрутизадии • Конфигурирование протоколов динамической маршрутизации, работающих с протоколом Характеристики протоколов динамической маршрутизации RTMP и EIGRP AppleTalk протокола AppleTalk И примеры базовых конфигураций • Конфигурирование фильтрации в протоколе AppleTalk с применением списков доступа Управление доступом в сети и защита информации с помощью команд acc ess-lis t И a pp l et alk a c c es s - group • Конфигурирование основных служб удаленного доступа по коммутируемым каналам связи протокола AppleTalk Опции конфигурирования ОС IOS для обеспечения удаленного доступа пользователям, работающим по протоколу AppleTalk на коммутируемых каналах связи • Верификация взаимодействия в сети с протоколом AppleTalk и устранение неполадок Идентификация проблем связи с помощью применения команд show, ping и debug Основы AppleTalk Протокол AppleTalk является одной из самых ранних реализаций вычислений в архитектуре клиент-сервер. Он был создан в середине 1980-х годов компанией Apple Computer для конечных пользователей семейства продуктов Macintosh, чтобы обеспечить возможность коллективного пользования ресурсами и, прежде всего, принтерами 1 и размещенными на серверах файлами.

Благодаря легкости в использовании протокол AppleTalk приобрел сторонников среди конечных пользователей, однако у инженеров-сетевиков и разработчиков он вызвал негативное отношение как немасштабируемый протокол, который трудно обслуживать в среде крупных корпораций. Усовершенствования сняли ряд критических замечаний со стороны специалистов в области сетевых систем, однако основными адвокатами протокола AppleTalk остаются конечные пользователи По иронии судьбы, некоторые функциональные особенности протокола например, динамические переговоры о AppleTalk, назначении адреса, которые и послужили причиной его критики со стороны проектировщиков за чрезмерную нагрузку на сеть, позже были реализованы в других широко применяемых протоколах, в частности, в протоколе IP в форме протокола динамического конфигурирования хост-машины Dynamic Host Configuration Protocol (DHCP) На рис. 5.1 показаны различные протоколы, входящие в набор сетевых протоколов AppleTalk. В данной главе не будет рассматриваться весь комплект Основное внимание будет уделено тем протоколам, которые используются на сетевом и транспортном уровнях, — протоколу разрешения адреса (AppleTalk Address Resolution Protocol — AARP), протоколу доставки дейтаграмм (Datagram Delivery Protocol — DDP), протоколу управления таблицами маршрутизации (Routing Table Maintenace Protocol — RTMP), протоколу привязки имен (Name Binding Protocol — NBP) и протоколу эхо-ответов (AppleTalk Echo Protocol — AEP). Дополнительно в разделе "Конфигурирование фильтрации в протоколе AppleTalk с применением списков доступа" будет рассмотрен протокол обмена зонной информацией (Zone Information Protocol — ZIP) Другие сетевые протоколы, показанные на рис. 5.1, с которыми читатель, вероятно, знаком, приведены просто для полноты картины.

Примечание Не все версии ОС IOS компании Cisco поддерживают протокол AppleTalk Следует удостовериться, что версия ОС IOS, исполняемая на вашем маршрутизаторе, под держивает набор протоколов для настольных систем Desktop Protocol Suite.

Система адресации и структура адресов в протоколе AppleTalk В отличие от протокола TCP/IP, который рассматривался в главе 4, "Основы TCP/IP", протокол AppleTalk является закрытым протоколом и контролируется компанией Apple Computers.

Он имеет уникальную структуру сетевых адресов и единственную в своем роде методологию именования сетевых служб.

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

Сетевой AppleTalk-адрес представляет собой 24-разрядный адрес, состоящий из двух различных компонентов — 16-разрядной сетевой части и 8-разрядного адреса узла. Сетевая часть идентифицирует сегмент локальной или глобальной сети, а адрес узла — рабочую станцию или сервер. Эти компоненты обычно пишутся слитно в виде сеть.узел с использованием десятичной формы представления. Например, адрес 52.6 идентифицирует рабочую станцию или сервер 6 в сети 52. В отличие от протокола TCP/IP, который обладает многоуровневой иерархией адресов и предусматривает возможность суммирования, протокол AppleTalk ограничен этими двумя уровнями.

Администрирование адресов в сети AppleTalk координирует протокол DDP, который к тому же обеспечивает доставку AppleTalk-пакетов, не устанавливая соединения.

Сетевые адреса для сегментов локальной или глобальной сети сетевой администратор задает точно так же, как для идентификации сегмента сети он задает TCP/IP-подсети. В протоколе AppleTalk существует два различных метода сетевой адресации сегментов локальной и глобальной сети: методы AppleTalk фазы 1 и 2. При методе AppleTalk фазы 1 сегменты сети идентифицируются одним номером сети.

При использовании метода AppleTalk фазы 2 сегменты сети идентифицируются величиной, называемой кабельным диапазоном (cable-range), который соответствует одному или нескольким логическим номерам сети. Кабельный диапазон может быть одним сетевым номером или непрерывной последовательностью сетевых номеров, задаваемой начальным и конечным сетевыми номерами в формате начало-конец. Например, кабельный диапазон 100- идентифицирует логическую сеть, имеющую один сетевой номер 100, тогда как кабельный диапазон 50-64 идентифицирует логическую сеть, охватывающую 15 сетевых номеров с 50 по 64.

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

Сегменты сети AppleTalk фазы 1 могут иметь до 254 адресов узлов: 127 резервируются для рабочих станций и 127 — для серверов. Каждая рабочая станция или сервер в сетевом сегменте с адресацией по методу фазы 1 должны иметь уникальный номер узла. Поэтому метод адресации AppleTalk фазы 1 мог поддерживать только 127 AppleTalk-хост-машин. Как оказалось, это вызывает проблему с масштабируемостью, решаемую в методе адресации AppleTalk фазы 2.

Сетевые сегменты с адресацией по методу AppleTalk фазы 2 классифицируются по адресам узлов на две категории, называемые расширенными сегментами и нерасширенными сегментами. В нерасширенных сетевых сегментах с адресацией по методу фазы 2 с одним сетевым адресом сегмента могут быть связаны 253 номера узла. Каждому серверу или рабочей станции присваивается уникальный номер узла, значение которого лежит в диапазоне от 1 до 253. Расширенные сетевые сегменты с адресацией по методу фазы 2 также позволяют назначать адреса узлов от 1 до 253.

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

Примечание Нерасширенные сетевые сегменты с адресацией по методу фазы 2 обычно представ ляют собой либо сети LocalTalk, либо сегменты глобальной сети. LocalTalk является первой реализацией сетевого взаимодействия на канальном и физическом уровнях с использованием телефонного кабеля в качестве физической транспортной среды и метода множественного доступа с контролем несущей и обнаружением конфликтов на канальном уровне (CSMA/CD). LocalTalk и AppleTalk фазы 1 были разработаны для приложений масштаба рабочей группы. Метод AppleTalk фазы 2 позволил улучшить масштабируемость протокола AppleTalk для поддержки работы на уровне всего пред приятия. Поскольку многие одинаковые характеристики свойственны сетевым сегментам AppleTalk фазы 1 и нерасширенным сетевым сегментам фазы 2, можно считать, что сетевой сегмент с адресацией по методу AppleTalk фазы 1 представляет собой нерасширенный сетевой сегмент с адресацией по методу фазы 2.

Маршрутизаторы компании Cisco никогда не поддерживали протокол LocalTalk, хотя сегменты глобальной сети могут адресоваться в стиле AppleTalk фазы 1 Однако ради достижения совместимости, ясности и гибкости рекомендуется при конфигурировании устройств компании Cisco использовать исключительно адресацию по методу фазы 2.

Как упоминалось ранее, переговоры по согласованию адреса узла проводятся динамически во время загрузки или перезапуска устройства, исполняющего протокол AppleTalk. Ответственным за переговоры по согласованию адресов узлов для устройств в сегменте сети является протокол AARP Динамическое назначение адреса выполняется с применением очень простого алгоритма.

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

Для того чтобы улучшить взаимодействие между пользователем и сетью AppleTalk, компания Apple избавила пользователей от изучения специфики адресации сетей и узлов. Вместо информации о том, что рабочая станция 5 в сети 10 хочет связаться с сервером 8 в сети 20, пользователю достаточно узнать имена устройств. Компания Apple создала схему именования, которая позволяет логически группировать рабочие станции и назначать индивидуальные имена отдельным рабочим станциям и серверам. Логическая группа рабочих станций или серверов называется зоной Определения зон могут задаваться исходя из любой логической характеристики организации, например, это могут быть ее производственные операции, подразделения или территориальное место расположения. Например, компания может создать маркетинговую, торговую и техническую зону, каждая из которых территориально будет находиться в нескольких местах.

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

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

Протокол NBP связывает имена и атрибуты устройств с адресами. Фактически он дирижирует процессом привязки имен, включающим регистрацию имени, его подтверждение, удаление и поиск. После того как имена будут зарегистрированы в протоколе NBP, приведенный ранее пример с рабочей станцией 10.5, желающей связаться с сервером 20. 8, может быть описан следующим образом: компьютер "Макинтош Джона" из нью-йоркской зоны хочет связаться с сервером "Финансы" из зоны "Бухгалтерия". Протокол NBP позволяет пользователям обращаться к сетевым ресурсам по именам, что во многом похоже на то, что делает служба имен домена (DNS) протокола TCP/IP.

Примечание Чтобы зарегистрироваться в протоколе NBP, работающие под управлением ОС IOS устройства используют имена, назначаемые глобальной командой hostname. Мар шрутизатор компании Cisco регистрируется в рамках протокола NBP как устройство типа ciscoRouter. Привязки, сделанные протоколом NBP, можно увидеть, воспользовавшись командой ОС IOS режима EXEC show appietalk nbp. Эта команда будет рассмотрена в разделе "Верификация взаимодействия в сети с протоколом AppleTalk и устранение неполадок".

Хотя назначение имени зоны не является частью сетевого адреса, это — неотъемлемая часть правильной работы сети AppleTalk. Конфигурирование протокола AppleTalk на маршрутизаторах требует назначения зон в дополнение к присвоению номеров сети и кабельных диапазонов.

В табл. 5.1 приведены различия между сетями и требованиями к нумерации узлов.

Таблица 5.1. Технические характеристики протоколов AppleTalk фазы 1 и фазы Характеристика AppleTalk фазы 1 AppleTalk фазы Сети, узлы и зоны Количество логических сетей 1 (кабельных сегментов) Максимальное количество 254* 253** устройств Максимальное количество Нет ограничений на количество конечных узлов конечных узлов;

общее количество узлов не более Максимальное количество Нет ограничений на количество серверов конечных узлов;

общее количество узлов не более Количество зон, в которых 1 1 (нерасширенная);

может существовать сеть (расширенная) Инкапсуляция на уровне физической среды Нерасширенная сеть Понятие отсутствует Да Расширенная сеть Понятие отсутствует Да Адресация кабельной Понятие отсутствует;

Один сетевой номер системы используются номера сетей (нерасширенная сеть);

кабельный диапазон от 1 и более (расширенная сеть) • Номера узлов 1 и 255 — резервные.

** Номера узлов 0, 254 и 255 — резервные.

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

• Каждый сегмент локальной или глобальной сети должен иметь один единственный номер сети.

• Каждый сегмент локальной или глобальной сети должен иметь свое значение кабельного диапазона;

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

• Кабельный диапазон с одним сетевым номером должен назначаться интерфейсам глобальных сетей.

• Рекомендуется следовать правилу добавления в кабельном диапазоне одного сетевого номера на каждые 50 узлов сегмента сети.

• Использование схемы адресации логических сетей может упростить устранение неполадок в будущем.

Последняя рекомендация может показаться очевидной, но давайте рассмотрим этот момент немного подробнее на примере схемы назначения адресов для сети компании ZIP, находящейся в Сан-Франциско. В табл. 5.2 показано присвоение адресов в сети AppleTalk компании ZIP, расположенной в Сан-Франциско.

В сети компании ZIP для определенных рабочих площадок были зарезервированы диапазоны сетевых адресов. В данном случае вся адресация сети в Сан-Франциско лежит в диапазоне номеров сети 1—1000. В процессе устранения неисправностей сетевые администраторы компании ZIP, основываясь на сетевом адресе устройства, могут быстро определить, что оно находится в Сан Франциско. Аналогично, диапазон 1~ 1000 был разбит на более мелкие части. Диапазон 1-10 был закреплен за серверным магистральным каналом данных, а диапазон 11—900 резервировался за этажами здания, на которых находятся пользовательские рабочие станции и принтеры. Наконец, диапазон 901—1000 был назначен для адресации каналов глобальных сетей.

Таблица 5.2. Назначение адресов в сети AppleTalk компании ZIP, расположенной в Сан-Франциско Кабельный Географическое расположение Этаж Ресурс диапазон Сан-Франциско Независимо Кольцо FDDI и серверный маги 1- стральный канал Сан-Франциско 1-й этаж Пользовательские рабочие станции 11- Сан-Франциско 2-й этаж Пользовательские рабочие 101- Сан-Франциско Резерв для Резерв для потенциального роста 201- потенциального роста Сан-Франциско -Сан-Хосе Канал глобальной сети 901-901 Сан-Франциско - Сеул Канал глобальной сети 902-902 Сан-Франциско – внешний мир Резерв для роста в Неназначенные глобальные сети 903- будущем Как видно, подобный логический подход к назначению сетевых адресов позволяет быстро распознавать функции и местонахождение устройств в сети AppleTalk.

Конфигурирование интерфейсов локальных сетей Все маршрутизаторы компании Cisco, которые осуществляют маршрутизацию с использованием протокола AppleTalk, имеют уникальный адрес сеть.узел для каждого подключенного к ним сегмента локальной сети. Адрес сеть.узел определяется динамически на основе либо номера сети системы адресации фазы 1, либо присвоенного интерфейсу кабельного диапазона системы адресации фазы 2. Назначение уникальных адресов каждому интерфейсу позволяет маршрутизатору определять, какие сети подключены к какому интерфейсу и куда следует посылать пакеты, предназначенные для этих сетей.

Аналогично протоколу TCP/IP каждый из пяти типов локальных сетей (Ethernet/IEEE 802.3, Fast Ethernet, Gigabit Ethernet, Token Ring/IEEE 802.5 и FDDI), описанных в главе 3, "Основы интерфейсов устройств Cisco", поддерживает концепцию динамического отображения МАС-адреса адаптера локальной сети на AppleTalk-адрес, назначенный интерфейсу. Этот процесс преобразования адресов поддерживается протоколом AARP, который участвует и в процедуре динамического назначения адреса узлу. Когда станция, работающая по протоколу AppleTalk, хочет вступить в контакт с другой AppleTalk-станцией, находящейся в той же логической сети, но не знает адреса канального уровня этой станции, она посылает широковещательный запрос на предоставление канального адреса для нужного AppleTalk-адреса. Каждая станция, находящаяся в этой логической сети, проверяет запрос и, если МАС-адрес станции соответствует запрашиваемому AppleTalk адресу, отвечает своим МАС-адресом.

Аналогично протоколу разрешения адреса (ARP — Address Resolution Protocol) в протоколе TCP/IP протокол AARP исключает необходимость знать МАС-адреса, принадлежащие логической сети станции, чтобы связываться с другими рабочими станциями или серверами.

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

Примечание Протокол AppleTalk работает хорошо с каждым из описанных в главе 3 интерфейсов локальных сетей. Хотя протокол канального уровня в протоколе AppleTalk одинаков для всех типов локальной сети (IEEE 802.2 SNAP LLC), компания Apple называет свою реализацию протокола AppleTalk для каждой среды различными именами. Протокол AppleTalk для локальной сети Ethernet она называет EtherTalk, для локальной сети Token Ring — TokenTalk и для локальной сети FDDI — FDDITalk.

Компанией Apple также были присвоены имена каждому из протоколов канального уровня, поддерживающих протокол AppleTalk в этих средах. Эти протоколы включают протокол доступа к каналу протокола EtherTalk (EtherTalk Link Access Protocol — ELAP), протокол доступа к каналу протокола TokenTalk (TokenTalk Link Access Protocol — TLAP) и протокол доступа к каналу протокола FDDITalk (FDDITalk Link Access Protocol — FLAP).

Основное различие между этими типами протоколов канального уровня заключается в том, как в них реализована SNAP-инкапсуляция. На интерфейсах Ethernet, FDDI и Token Ring SNAP-инкапсуляция включает заголовки, соответственно, в стандарте IEEE 802.3, в стандарте IEEE 802.5 или FDDI и заголовок протокола IEEE 802.2 SNAP LLC. Присваивание имен протоколам канального уровня упрощает обсуждение реализации протокола AppleTalk в таких средах и ссылку на драйвер, который необходим операционной системе компании Apple, чтобы поддерживать протокол AppleTalk.

Назначение номеров сетей AppleTalk фазы 1 на интерфейсах как локальных, так и глобальных сетей выполняется с помощью интерфейсной субкоманды ОС IOS appletalk address. Эта команда имеет параметром номер сети и узла в формате сеть.узел. Указываемый номер сети должен согласовываться с номером сети других активных маршрутизаторов, уже присутствующих в конфигурируемом сегменте локальной или глобальной сети. Этот номер является предлагаемым. Он может меняться в процессе динамических переговоров, который описывался ранее. Хотя компания ZIP предпочла исключительно адресацию по методу фазы 2, ниже приведен пример конфигурирования маршрутизатора SF-1 на работу неиспользуемого интерфейса ethtrnet 1 с адресом по методу протокола AppleTalk фазы 1:

SF-1#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

SF-1(config)#interface ethernet SF-1(config-if)#appletalk address 201. SF-1(config-if)#^Z В соответствии с методом адресации по протоколу AppleTalk фазы 2 кабельные диапазоны для интерфейсов локальных и глобальных сетей назначаются с помощью интерфейсной субкоманды ОС IOS appletalk cable-range. В качестве параметра эта команда воспринимает диапазон номеров в формате начало-конец, который указывает начальный и конечный номера адресов сети, подлежащих включению в кабельный диапазон. Указываемое значение кабельного диапазона должно согласовываться с аналогичными значениями других активных маршрутизаторов, входящих в конфигурируемый сегмент локальной или глобальной сети. В качестве необязательного параметра команды можно указать начальный адрес в формате сеть.узел, который будет использоваться во время динамических переговоров по согласованию адреса. В примере ниже показано конфигурирование для всех трех интерфейсов локальной сети маршрутизатора SF-2 кабельного диапазона AppleTalk фазы 2:

SF-2#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

SF-2 (config)#interface ethernet SF-2 (config-if)#appletalk cable-range 151- SF-2 (config-if)#interface ethernet SF-2 (config-if)#appletalk cable-range 101- SF-2 {config-if)#interface fddi SF-2 (config-if)#appletalk cable-range 1- SF-2 (config-if)#^Z После конфигурирования адресов для успешной установки адресации протокола AppleTalk следует сконфигурировать на интерфейсах имена зон с помощью интерфейсной субкоманды ОС IOS appletalk zone. Параметром этой команды является цепочка символов, которая и представляет собой имя зоны. Имя зоны может содержать буквенные, цифровые и специальные символы, а также символы из специального набора символов компьютеров семейства Macintosh.

Имена зон зависят от регистра символов.

Путем многократного повторения команды appletalk zone на заданном интерфейсе можно определить несколько имен зон. Имя первой заданной зоны считается первичным для этого интерфейса. Конфигурация зоны интерфейса должна точно совпадать по имени и по количеству зон с зонами, которые уже были сконфигурированы на активных и работающих с протоколом AppleTalk маршрутизаторах, расположенных в этом же сегменте сети. В примере, приведенном ниже, каждый из интерфейсов маршрутизатора SF-2 конфигурируется на одно имя зоны:

S F - 2 # c o n fi g u r e Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

SF-2 (config)#interface ethernet SF-2 (config-if)#appletalk zone Marketing SF-2 (config-if)#interface ethernet SF-2 (config-if)#appletalk zone Sales SF-2 (config-if)#interface fddi SF-2 (config-if)#appletalk zone SF Zone SF-2 (config-if)#^Z Протоколы AppleTalk и ОС IOS компании Cisco поддерживают концепцию динамического конфигурирования сетевого адреса и имени (имен) зоны на интерфейсах локальной сети.

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

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

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

Конфигурирование режима поиска протокола AppleTalk осуществляется с помощью интерфейсной субкоманды ОС IOS appletalk discovery. Обычно эта команда используется вместо команд appletalk address и appletalk cable-range. Как вариант, режим поиска можно включить, задав адрес сеть.узел 0.0 в качестве параметра команды appletalk address или appletalk cable-range. Вне зависимости от команды, включающей режим поиска, команда appletalk zone не используется. Хотя в сети компании ZIP режим поиска не применяется, ниже показан пример конфигурирования протокола AppleTalk на интерфейсе tokenring О/О маршрутизатора, расположенного в Сан-Хосе:

San-Jose#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

San-Jose(config)#interface tokenring 0/ San-Jose(config-if)#appletalk discovery San-Jose(config-if)^Z Конфигурирование интерфейсов глобальных сетей Адресация глобальных сетей в протоколе AppleTalk аналогична адресации локальных сетей, т.е. адреса конфигурируются с помощью субкоманд конфигурирования интерф ейса appl etal k address и appl etalk cable-range и команды apll etal k zone. Однако режим поиска протокола AppleTalk не поддерживается ни одним из интерфейсов глобальной сети. В данном разделе рассматриваются назначения AppleTalk-номеров сети двухточечным и многоточечным интерфейсам глобальных сетей. Заметим, что для работы интерфейса глобальной сети требуется специальный метод инкапсуляции (например, Х.25 или Frame Relay), используемый протоколом AppleTalk. Все интерфейсы глобальной сети требуют наличия уникальных AppleTalk-адресов узла, но конкретные интерфейсы в одной глобальной сети коллективно используют значение кабельного диапазона и имя зоны.

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

Конфигурирование AppleTalk-номеров сети на двухточечных интерфейсах глобальной сети выполняется с помощью интерфейсной субкоманды ОС IOS aplletalk address для адресов по методу фазы 1 или интерфейсной субкоманды ОС IOS appletalk cable-range для адресов по методу фазы 2. Каждому отдельному двухточечному соединению глобальной сети (или двухточечному подынтерфейсу) должен назначаться отдельный AppleTalk-номер сети или кабельный диапазон. Имена AppleTalk-зон также могут присваиваться двухточечным интерфейсам глобальной сети с помощью интерфейсной субкоманды ОС IOS appletalk zone. В примере, приве денном ниже, маршрутизатор Seoul-1 конфигурируется значениями кабельных диапазонов и именами зон для каждого из его двухточечных интерфейсов (два подинтерфейса Frame Relay и один интерфейс высокоуровневого протокола управления каналом передачи данных (High-Level Data Link Control — HDLC)):

Seoul-1#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

Seoul-1 (config)#interface serial 0.16 point-to-point Seoul-1 (config-if)#appletalk cable-range 2901- Seoul-1 (config-if)#appletalk zone WAN Zone Seoul-1 (config-if)#interface serial 0.17 point-to-point Seoul-1 (config-if)#appletalk cable-range 2902- Seoul-1 (config-if)#appletalk zone WAN Zone Seoul-1 (config-if)#interface serial Seoul-1 (config-if)#appletalk cable-range 1901- Seoul-1 (config-if}#appletalk zone WAN Zone Seoul-1 (config-if)#^Z Адресация многоточечного интерфейса глобальной сети Общие моменты, связанные с конфигурированием адресов сетевого протокола на многоточечных интерфейсах глобальной сети обсуждались в главе 4 на примере протокола IP. Как и протокол IP, протокол AppIeTalk может использоваться с различными интерфейсами глобальной сети, включая Frame Relay, X.25, ISDN и ATM. Каждый из этих интерфейсов конфигурируется на маршрутизацию AppleTalk-пакетов с помощью интерфейсных субкоманд ОС IOS appletalk address или appletalk cable-range. Как и для ранее рассмотренных интерфейсов, правильная работа протокола AppIeTalk на многоточечных интерфейсах требует субкоманды ЭС IOS appletalk zone.

Протоколу AppIeTalk также необходимо отображение конкретного адреса канального уровня на конкретный адрес формата сеть.узел протокола AppIeTalk. Такое отображение конфигурируется по разному для каждого протокола глобальной сети. Команды, используемые для выполнения таких отображений, требуют наличия конкретного адреса сеть.узел. Чтобы обеспечить администратору сети точное представление о том, каким маршрутизаторам многоточечной глобальной сети какие адреса узлов назначены, рекомендуется указывать адреса сеть.узел в качестве параметров команд applet al k addres s и a p p l et al k cable-ra n ge.

При работе с многоточечными интерфейсами Frame Relay маршрутизатор нуждается в отображении идентификационных номеров соединений канального уровня (DLCI идентификаторов) на многоточечном интерфейсе Frame Relay на номер сеть.узел протокола AppleTalk. Динамическое отображение DLCI-идентификатора на номер сети и узла протокола AppleTalk может выполнять функция обратного разрешения адресов Frame Relay Inverse ARP.

Для статического отображения DLCI-адреса, связанного с сетью и номером узла протокола AppleTalk, которые достижимы через многоточечный интерфейс глобальной сети, можно также воспользоваться субкомандой конфигурирования интерфейса frame-relay map appletalk.

Адресация многоточечных интерфейсов глобальной сети Х.25 похожа на адресацию интерфейсов Frame Relay тем, что в обоих случаях статическое отображение реализуется через субкоманды конфигурирования интерфейса. Интерфейсы Х.25 должны иметь отображения своих адресов сеть.узел протокола AppleTalk на адреса протокола X. 121, используемые для настройки виртуальных каналов между системами. Каждый виртуальный канал идентифицируется адресом протокола Х.121, используемым для соединения. Чтобы выполнить на многоточечном интерфейсе глобальной сети статическое отображение между адресом протокола AppleTalk и адресом протокола Х.121, используется субкоманда конфигурирования интерфейса х25 map appletalk.

Адресация многоточечных интерфейсов ISDN также требует команд статического отображения. Однако для протокола AppleTalk, в отличие от протокола IP, ISDN-команды отображения требуются для каждого устройства, которое хочет обмениваться данными с другим устройством через ISDN-соединение. Для отображения адресов сеть.узел протокола AppleTalk на имена систем и телефонные номера, используемые для соединения в ISDN-сети, применяется субкоманда конфигурирования интерфейса ОС IOS dialer map appletalk.

Отображение адресов канального уровня протокола ATM в виде идентификаторов виртуального пути/идентификаторов виртуального канала на номер сеть.узел протокола AppleTalk на многоточечном интерфейсе ATM зависит от используемых типов ATM протоколов и виртуальных каналов. При работе с протоколом AppleTalk как для постоянных виртуальных каналов, так и для коммутируемых виртуальных каналов ATM-сети можно использовать инкапсуляцию протокола логического управления связью/протокола управления доступом к сети (LLC/SNAP). В режиме работы с постоянными виртуальными каналами в ATM сети организуется постоянный виртуальный канал, и пакеты идентифицируются как направленные на AppleTalk-адрес на другом конце конкретного виртуального канала. В режиме работы с коммутируемыми виртуальными каналами AppleTalk-пакеты идентифицируются как направленные на конкретный статически заданный ATM-адрес канального уровня. ATM коммутатор устанавливает виртуальный канал по требованию, когда маршрутизатор запрашивает соединение с ATM-адресом для конкретного AppleTalk-адреса сеть.узел.

Процесс LLC/SNAP-инкапсуляции в постоянных виртуальных каналах использует субкоманду конфигурирования интерфейса ОС IOS map-group и команду глобального конфигурирования ОС IOS map-list для отображения AppleTalk-адресов сеть.узел на конкретные постоянные виртуальные каналы. Процесс LLC/SNAP-инкапсуляции в коммутируемых виртуальных каналах использует субкоманду конфигурирования интерфейса ОС IOS map-group и команду глобального конфигурирования ОС IOS map-lis t для отображения AppleTalk-адресов на адреса точек доступа к сетевой службе (Network Service Access Point — NSAP), применяемых для идентификации удаленных устройств в ATM-сети.

Проверка конфигурации AppleTalk-адресов Верификация AppleTalk-адресов и других атрибутов протокола AppleTalk, которые были присвоены интерфейсам, может выполняться с помощью команды режима :ХЕС show appletalk interface. Эта команда дает полное представление о пара-1етрах, связанных с конфигурацией протокола AppleTalk на всех интерфейсах. Если в качестве параметра команды указывается конкретный интерфейс, на экран выводится только та информация, которая относится к этому интерфейсу. Ниже приведен результат исполнения команды sho w appletalk interface ethernet 0 на маршрутизаторе компании ZIP SF-2:

F-2#show appletalk interface ethernet EthernetO is up, line protocol is up AppleTalk cable range is 151- AppleTalk address is 198.72, Valid AppleTalk zone is "Marketing " AppleTalk address gleaning is disabled AppleTalk route cache is enabled В первой строке выводимых данных показан административный и рабочий статус интерфейса. При подтверждении конфигурации протокола AppleTalk на этом интерфейсе другими активными маршрутизаторами, принадлежащими сегменту сети, информация о статусе выводится выше или в этой строке. Во второй строке приводится значение кабельного диапазона сетевого адреса AppleTalk-сети. третьей строке стоит адрес сеть.узел и указывается, конфликтует ли этот адрес с каким-либо другим адресом на этом интерфейсе.

В четвертой строке показывает имя зоны, которой этот интерфейс принадлежит. Результат может содержать и дополнительные строки, если активны какие-либо другие функции протокола AppleTalk, например, фильтры пакетов. Подобная ситуация будет рассмотрена в этой главе в разделе "Конфигурирование фильтрации в протоколе AppleTalk с применением списков доступа".

Команда ОС IOS режима EXEC show appletalk interface имеет дополнительную форму, которая позволяет увидеть краткую сводную информацию об AppleTalk-адресах и статусах всех имеющихся в устройстве интерфейсов. Такая суммирующая версия данных может быть получена с помощью команды show a p p l e t a l k i n t e r f a c e b r i e f.

Ниже показан результат исполнения команды show appletalk interface brief на маршрутизаторе компании ZIP SF-2:

SF-2#show appletalk interface brief Interface Address Config Status/LineProtocol Atalk Protocol EthernetO 198.72 Extended up up Ethernetl 120.45 Extended up up FddiO 7.12 Extended up up Loopbackl unassigned not config'd up n/a Кроме проверки конфигурации протокола AppleTalk на самом маршрутизаторе, можно просматривать как статические, так и динамические отображения AppleTalk-адресов сеть.узел на адреса канального уровня для различных сред многоточечных глобальных сетей. Для этого следует воспользоваться командами ОС IOS режима EXEC show frame-relay map, show atm map и show dialer map, что уже демонстрировалось в предыдущих главах.

Конфигурирование маршрутизации по протоколу AppleTalk Назначение AppleTalk-номеров сетей и имен зон работающим под управлением ОС IOS устройствам и интерфейсам — необходимое, но не достаточное условие для того, чтобы устройства могли обмениваться друг с другом информацией по протоколу AppleTalk. Для двусторонней передачи данных рабочие станции и серверы в сети AppleTalk должны также знать пути, по которым они могут связаться друг с другом. AppleTalk-маршрутизаторы создают и постоянно обращаются к таблицам номеров сетей, известным под названием таблиц маршрутизации. Таблицы маршрутизации протокола AppleTalk работают во многом так же, как таблицы маршрутизации протокола IP, обеспечивая информацию о сетевом пути, что позволяет маршрутизатору доставлять данные непосредственно в пункт конечного назначения или следующему маршрутизатору, стоящему по пути к пункту назначения. Для определения места нахождения AppleTalk-сетей и совместного использования этой информации маршрутизаторы применяют алгоритмы маршрутизации, также известные под названием протоколов маршрутизации.

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

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

Чтобы разрешить маршрутизацию по протоколу AppleTalk, используется команда глобального конфигурирования ОС IOS appletalk routing. В примере ниже выполняется разрешение маршрутизации по протоколу AppleTalk на маршрутизаторе компании ZIP SF-2:

SF-2#configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CTRL+Z.

SF-2 (config)#appletalk routing SF-2(config)#^Z После того как маршрутизация по протоколу AppleTalk разрешена, маршрутизатор строит таблицу маршрутизации, которая используется для коммутации пакетов. По умолчанию, когда интерфейс локальной или глобальной сети конфигурируется AppleTalk-адресом или значением кабельного диапазона, и этот интерфейс переводится в рабочее состояние, информация о AppleTalk-сети этого интерфейса помешается в таблицу маршрутизации. В таблицу маршрутизации заносится информация всех интерфейсов, подключенных к маршрутизатору.

Если в сети находится только один маршрутизатор, то он обладает информацией обо всех подключенных к нему AppleTalk-сетях. Записи таблицы динамической маршрутизации создаются только тогда, когда в сети присутствует несколько маршрутизаторов. Для записей таблицы динамической маршрутизации используется протокол управления таблицей маршрутизации (Routing Table Maintenance Protocol — RTMP).

Для просмотра таблицы маршрутизации протокола AppleTalk можно использовать команду ОС IOS режима EXEC show appletalk route. Если эта команда вводится без указания параметров, то на экран выводится вся таблица маршрутизации протокола AppleTalk. В примере ниже показана информация таблицы маршрутизации маршрутизатора SF-2 сети компании ZIP, в которой есть только данные о подключенных активных интерфейсах и нет никаких дополнительных записей:

SF-2#show appletalk route E - EIGRP derived, С -connected, A - AURP S - static Codes: R - RTMP derived, P — proxy 3 routes in internet The first zone listed for each entry is its default (primary) zone.

С Net 1-10 directly connected, FddiO, zone SF Zone С Net 101-150 directly connected, Ethernetl, zone Sales С Net 151-200 directly connected, EthernetO, zone Marketing Команда show appletalk route обеспечивает администратору сети много полезных данных.

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

Первая часть выводимой информации представляет собой легенду первого столбца таблицы. Она рассказывает о том, откуда был получен маршрут. Каждая из трех последних строк этой таблицы маршрутизации протокола AppleTalk показывает один маршрут к множеству AppleTalk-сетей, заданному кабельным диапазоном, как этот маршрут был получен, зоны, которым принадлежат сети, и интерфейс, связанный с маршрутом. Буква "С" в первом столбце указывает на то, что все маршруты определены из находящихся в рабочем состоянии подключенных AppleTalk-сетей. Более подробно команда show appletalk route будет рассмотрена в этой главе в разделе "Проверка конфигурации маршрутизации по протоколу AppleTalk".

Конфигурирование статической маршрутизации При обсуждении в главе 4 IP-маршрутизации были названы различные причины для использования статических IP-маршрутов, включая нестабильность сетевых каналов и соединений по коммутируемым линиям связи. То же применимо и к статическим AppleTalk-маршрутам. Для конфигурирования в AppleTalk-таблице маршрутизации статических AppleTalk-маршрутов можно использовать команду глобального конфигурирования appletalk static. В примере ниже маршрутизатор SF-2 компании ZIP конфигурируется статическим маршрутом, направляющим AppleTalk-пакеты, пункт назначения которых — сеть 40000-40000, в узел 5.10, находящийся на интерфейсе FDDI. В этом примере имя зоны SF Zone связывается с кабельным диапазоном 40000 40000 командой appletalk static.

SF-2#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

SF-2 (config)#appletalk static cable-range 40000-40000 to 5.10 zone SF Zone SF-2 (config)t^Z Используя команду show appletalk route, можно проверить наличие записи о статическом маршруте в таблице маршрутизации маршрутизатора SF-2:

SF-2#show appletalk route Codes: R — RTMP derived, E — EIGRP derived, С -connected, A - AURP S — static P — proxy 4 routes in internet The first zone listed for each entry is its default (primary) zone.

С Net 1-10 directly connected, FddiO, zone SF Zone С Net 101-150 directly connected, Ethernetl, zone Sales С Net 151-200 directly connected, EthernetO, zone Marketing S Net 40000-40000 [1/G ] via 5.10, 315 sec,FddiO, zone SF Zone Информацию о статических AppleTalk-маршрутах также можно просматривать с помощью команды ОС IOS режима EXEC show apple static:

SF-2#show apple static AppleTalk Static Entries:

------------------------------------------------------------- Network NextIR Zone Status 40000-40000 5.10 SF Zone A Проверка конфигурации маршрутизации по протоколу AppleTalk Как уже говорилось, конфигурация AppleTalk-маршрутизации может верифицироваться с помощью команды ОС IOS режима EXEC show appletalk route. В данном разделе рассмотрены дополнительные команды, которые помогают в верификации и управлении конфигурацией таблицы маршрутизации протокола AppleTalk.

Команда show appletalk route используется для просмотра состояния таблицы маршрутизации протокола AppleTalk. Конфигурируются ли статические маршруты или исполняются протоколы динамической маршрутизации, эта команда показывает, присутствуют ли реально на маршрутизаторе сконфигурированные ранее маршруты, или ожидается, что они будут получены в процессе обучения.

Протоколы динамической AppleTalk-маршрутизации будут рассматриваться в следующем разделе этой главы. А ниже показана выдержка из информации, выведенной командой show appletalk route на маршрутизаторе компании ZIP SF-2:

SF-2#show appletalk route Codes: R — RTMP derived, E — EIGRP derived, С -connected, A - AUR, S static, P — proxy 5 routes in internet The first zone listed for each entry is its default (primary) zone.

С Net 1-10 directly connected, FddiO, zone SF Zone С Net 101-150 directly connected, Ethernetl, zone Sales С Net 151-200 directly connected, EthernetO, zone Marketing R Net 11-100 [1/G] via 2.12, 10 sec, FddiO, zone Operations S Net 40000-40000 [1/G] via 5.10, 315 sec, FddiO, zone SF Zone В приведенной выше информации представлены данные о маршрутах к непосредственно соединенным с маршрутизатором SF-2 AppleTalk-сетям и о маршруте к AppleTalk-сети 11-100, полученном в процессе динамического обучения от маршрутизатора SF-1 с использованием протокола динамической AppleTalk-маршрутизации RTMP. Выводимые данные также предоставляют следующую информацию.

• Адрес сеть.узел AppleTalk-маршрутизатора следующего перехода и тип выходного интерфейса для показанных маршрутов (или просто выходной интерфейс для маршрутов через непосредственное подключение).

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

• Метрика протокола маршрутизации (число слева от косой черты в квадратных скобках) и состояние маршрута, которое указывается для всех маршрутов, кроме маршрутов через непосредственное подключение. Состояние маршрута обозначается буквой справа от косой черты в квадратных скобках. Для обозначения хорошего маршрута (т.е. активного и доступного), подозрительного или плохого, используются буквы G, S и В, соответственно.

Состояния маршрута контролируются отдельным процессом, проверяющим каждые секунд конкретные маршруты, которые не обновлялись. После каждого 20-секундного перерыва в обновлении маршрута его статус изменяется с хорошего (G) на подозрительный (S) и с подозрительного (S) на плохой (В). После истечения 1 минуты без обновлений маршрут удаляется. Каждый раз, когда принимается полезное обновление, статус маршрута восстанавливается до хорошего. Обновления называются полезными, если они объявляют маршрут хорошим или лучше, чем тот, что на данный момент находится в таблице.

Подобно команде show ip route, команда show appletalk route, если задать качестве параметра номер сети, позволяет просмотреть конкретный маршрут, также можно удалять AppleTalk-маршруты из таблицы маршрутизации, воспользовавшись привилегированной командой режима EXEC clear appletalk route, при устранении проблем, связанных с AppleTalk-маршрутизацией, можно сначала с помощью этой командой, удалить запись о маршруте, а затем использовать команду how appletalk route, чтобы проверить, откуда маршрутизатор первоначально шал об этом маршруте.

Конфигурацию имен зон протокола AppleTalk можно проверить, используя команду ОС 1OS режима EXEC show appletalk zone. Если в этой команде не указывается имя зоны в качестве параметра, то выводятся все имена зон. Ниже показана выдержка из результата, получаемого после выполнения команды show appletalk zone на маршрутизаторе компании ZIP SF-2:

SF-2#show appletalk zone Name Network(s) SF Zone 1-10 40000- Sales 101- Marketing 151- Operations 11- Total of 4 zones Если в сети находится несколько AppleTalk-маршрутизаторов, они обмениваются информацией динамической маршрутизации. Для того чтобы проверить, активирована ли AppleTalk маршрутизация и есть ли в сети другие AppleTalk-маршрутизаторы, используется команда ОС IOS режима EXEC show appletalk neighbors. Ниже показан фрагмент результата, получаемого после выполнения команды show appletalk neighbors на маршрутизаторе компании ZIP SF-2. Из него видно, что маршрутизатор SF-2 знает о соседнем AppleTalk маршрутизаторе SF-1 и что на маршрутизаторе SF-1 исполняется протокол динамической маршрутизации RTMP.

SF-2#show appletalk neighbors AppleTalk neighbors:

2.12 SF-l.FddiO FddiO, uptime 33:27, 2 sees Neighbor is reachable as a RTMP peer Конфигурирование протоколов динамической маршрутизации, работающих с протоколом AppleTalk Как указывалось в главе 4, на решение о том, какой протокол маршрутизации следует использовать в сети, оказывают влияние множество факторов. И эти факторы — топология сети, масштабируемость, легкость внедрения и скорость сходимости — также важны при выборе протокола динамической маршрутизации для протокола AppleTalk.

ОС IOS компании Cisco предлагает два протокола динамической маршрутизации для протокола AppleTalk: протокол управления таблицей маршрутизации (Routing Table Maintenance Protocol — RTMP) и AppleTalk EIGRP. В отличие от протокола TCP/IP, протокол AppleTalk имеет свой протокол динамической маршрутизации по умолчанию: RTMP, который работает без ручного конфигурирования администратором сети. Протокол AppleTalk EIGRP может устанавливаться на сетевых устройствах с ОС IOS на по сегментной основе. Однако, поскольку протокол EIGRP поддерживают только те устройства, которые работают под управлением ОС IOS, сегменты сети с AppleTalk-маршрутизаторами, которые не работают с ОС IOS, или сегменты со смешанными маршрутизаторами будут требовать для нормальной работы применения протокола RTMP.

Исследуемая в качестве примера сеть компании ZIP использует как протокол RTMP, так и протокол E1GRP. Протокол EIGRP реализован для уменьшения потребления полосы пропускания каналов глобальной сети, которое имеет место при применении протокола RTMP. Если AppleTalk-сеть не слишком велика и имеет приемлемую полосу пропускания глобальной сети, то одного протокола RTMP, вероятно, будет достаточно. При этом исключается необходимость в конфигурировании дополнительных команд установки протокола EIGRP.

В последующих разделах рассматривается конфигурирование маршрутизации на основе протоколов RTMP и EIGRP.

Конфигурирование протокола AppleTalk RTMP RTMP является протоколом динамической маршрутизации протокола AppleTalk по умолчанию. По своим функциям он аналогичен протоколу маршрутной информации Routing Information Protocol протокола IP (IP RIP). AppleTalk RTMP — это протокол маршрутизации, использующий метод вектора расстояния. Он формирует содержимое таблиц AppleTalk маршрутизации, управляет им в маршрутизаторах, работающих с протоколом AppleTalk.

Свойства протоколов маршрутизации на основе метода вектора расстояния и протокола IP RIP были рассмотрены в главе 4. AppleTalk RTMP относится к классу протоколов внутренних шлюзов (IGP). Протокол AppleTalk не использует протоколы маршрутизации класса протоколов внешних шлюзов (EGP), поскольку всегда применяется только во внутренних корпоративных сетях и никогда — в сетях общего пользования типа Internet. Активация протокола AppleTalk RTMP на AppleTalk-интерфейсах происходит по умолчанию в тот момент, когда вводится команда глобального конфигурирования appletalk routing.

Будучи первым протоколом динамической маршрутизации для сетей AppleTalk, протокол RTMP не обладает некоторыми усовершенствованными функциями новых протоколов динамической маршрутизации и, прежде всего, в области обеспечения масштабируемости и снижения потребления полосы пропускания. Одним из основных недостатков протокола RTMP является его чрезвычайно "болтливая" природа: он посылает пакеты актуализации маршрутизации каждые 10 секунд. Как будет видно из материала в следующем разделе, разработанные позднее протоколы динамической маршрутизации решают некоторые из этих проблем.

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

Максимальное количество переходов, поддерживаемое протоколом AppleTalk RTMP, равно 30.

Любой маршрут, который имеет более 30 переходов, отмечается как недоступный. В выводимой командой show appletalk route информации из маршрутизатора SF-2 видно, что маршрут до AppleTalk-сети 11-100 имеет метрику в 1 переход, что указывается в таблице AppleTalk-маршрутизации через обозначение [1/G]:

SF-2#show appletalk route R - RTMP derived, E - EIGRP derived, С - connected, A - AURP, Codes:

S - static, P - proxy 5 routes in internet The first zone listed for each entry is its default (primary) zone.

С Net 1-10 directly connected, FddiO, zone SF Zone С Net 101-150 directly connected, Ethernetl, zone Sales С Net 151-200 directly connected, EthernetO, zone Marketing R Net 11-100 [1/G] via 2.12, 10 sec, FddiO, zone Operations S Net 40000-40000 [1/G] via 5.10, 315 sec, FddiO, zone SF Zone По умолчанию в любой конкретный момент времени в таблице маршрутизации содержится только один маршрут до конкретной AppleTalk-сети. Такое поведение отличается от IP маршрутизации, при которой маршрутизатор автоматически сохраняет несколько путей с равной стоимостью. Чтобы разрешить маршрутизатору помещать в свою таблицу AppleTalk маршрутизации пути с равной стоимостью, используется команда глобального конфигурирования appletalk maximum-paths. Например, команда appletalk maximum-paths позволяет маршрутизатору обучиться двум равностоимостным путям до пункта назначения в сети AppleTalk. Количество путей с равной стоимостью, на сохранение которых дается разрешение маршрутизатору, зависит от топологии сети AppleTalk. Если сохраняется несколько путей с равной стоимостью, нагрузка маршрутизатора на попакетной основе разделяется между всеми параллельными равностоимостными путями до пункта назначения в сети AppleTalk.

Конфигурирование протокола AppleTalk EIGRP AppleTalk EIGRP представляет собой усовершенствованную версию исходного протокола внутренней маршрутизации между шлюзами (Interior Gateway Routing Protocol — IGRP) компании Cisco, адаптированную к использованию в AppleTalk-сетях. Протокол AppleTalk EIGRP применяет тот же транспортный механизм, алгоритм обновлений DUAL и процесс обнаружения соседей, что и протокол EIGRP для IP-маршрутизации, который обсуждался в главе 4. Протокол AppleTalk EIGRP обладает характеристиками, которые свойственны протоколам, основанным на методе учета состояния канала, например, частично инкрементальные пакеты актуализации и уменьшенное время сходимости. Протокол EIGRP посылает пакеты актуализации маршрутизации только в тех случаях, когда в топологии сети происходят изменения, и поэтому он занимает меньшую полосу пропускания, чем протокол RTMP, который посылает частые пакеты актуализации с полной таблицей маршрутизации.

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

Конфигурирование процесса маршрутизации по протоколу AppleTalk EIGRP состоит из двух этапов: разрешение маршрутизатору выполнить протокол EIGRP и идентификация интерфейсов, которые включаются в процесс EIGRP-маршрутизации.

Чтобы разрешить работу с протоколом AppleTalk EIGRP, используется команда глобального конфигурирования ОС IOS appletalk routing eigrp. В качестве параметра этой команды выступает идентификатор процесса, которым часто является номер автономной системы, используемый при конфигурировании протоколов IP EIGRP или IP BGP. В примере ниже маршрутизатору в Сингапуре разрешается работа с протоколом AppleTalk EIGRP, для чего используется номер автономной системы 25000:

Singapore#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

Singapore (config) #appletalk routing eigrp Singapore (config)#^Z После того как работа протокола AppleTalk EIGRP будет разрешена, необходимо идентифицировать интерфейсы маршрутизатора, которые включаются в EIGRP-процесс обмена актуальной маршрутной информацией. Инструкция маршрутизатору о том, какой AppleTalk-протокол динамической маршрутизации использовать на конкретном интерфейсе, выдается с помощью субкоманды конфигурирования интерфейса ОС IOS appletalk protocol.

Параметром у этой команды могут быть ключевые слова eigrp или rtmp. В сети компании ZIP работа протокола EIGRP была разрешена на всех интерфейсах глобальной сети. Ниже показан пример конфигурирования протокола EIGRP в качестве протокола маршрутизации на интерфейсе глобальной сети маршрутизатора компании ZIP в Сингапуре:

Singapore#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

Singapore(config)#interface serial 0. Singapore(config-if)#appletalk protocol eigrp Singapore(config-if)#^Z Поскольку протокол RTMP сконфигурирован на всех AppleTalk-интерфейсах по умолчанию, то на те интерфейсы, на которых активирован протокол EIGRP, посылаются пакеты актуализации маршрутной информации как протокола EIGRP, так и протокола RTMP. Это можно проверить, воспользовавшись командой show appletalk interface, что и видно на примере маршрутизатора компании ZIP в Сингапуре:

Singapore#show appletalk interface serial 0. SerialO.100 is up, line protocol is up AppleTalk cable range is 2902- AppleTalk address is 2902.2,Valid AppleTalk zone is "WAN Zone " Routing protocols enabled: RTMP EIGRP AppleTalk address gleaning is not supported by hardware AppleTalk route cache is not initialized Следует отметить, что после того, как на маршрутизаторе будет разрешена работа протокола AppleTalk EIGRP, начнется автоматическая редистрибуция маршрутной информации между протоколами AppleTalk EIGRP и RTMP. Этот процесс гарантирует взаимный обмен маршрутами, выявленными каждым протоколом динамической маршрутизации, так что и EIGRP- и RTMP-маршрутизаторам известны все доступные сетевые адреса. В конфигурацию маршрутизатора, настраиваемого на работу с протоколом AppleTalk EIGRP, автоматически вводится команда глобального конфигурирования ОС IOS appletalk route-redistribution, которая инициирует процесс редистрибуции. Преднамеренное отключение автоматической редистрибуции может привести к тому, что EIGRP-маршрутизаторы не будут знать о маршрутах, выявленных протоколом RTMP, и наоборот. Потенциальным следствием этого может быть недоступность некоторых сетевых ресурсов для определенных пользователей.

На интерфейсах, которые обслуживаются только маршрутизаторами, работающими под управлением ОС 1OS компании Cisco, RTMP-маршрутизация может быть отключена, чтобы исключить дублирующую рассылку пакетов актуализации маршрутной информации. Однако важно не отключать протоколы RTMP на тех интерфейсах, которые имеют AppleTalk-рабочие станции, серверы, принтеры или AppleTalk-маршрутизаторы, не использующие ОС IOS.

Запрещение работы протокола RTMP на интерфейсах с такими устройствами лишит их доступа к сетевым службам протокола AppleTalk. В сети компании ZIP работа протокола RTMP была запрещена на всех интерфейсах глобальной сети, имеющих только AppleTalk-маршрутизаторы, которые работают под управлением ОС IOS. Чтобы запретить работу протокола RTMP, исполь зуется субкоманда конфигурирования интерфейса ОС IOS no appletalk protocol rtmp.

Ниже приведен пример запрещения работы протокола RTMP на интерфейсе глобальной сети маршрутизатора компании ZIP в Сингапуре:

Singapore#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

Singapore(config)#interface serial 0. Singapore(config-if)#no appletalk protocol rtmp Singapore(config-if}#^z Как только что отмечалось, работа протокола RTMP не может быть полностью запрещена на AppleTalk-интерфейсах, имеющих другие AppleTalk-рабочие станции конечных пользователей и AppleTalk-маршрутизаторы, работающие не под управлением ОС 1OS. Однако, если в сегменте сети находятся только AppleTalk-станции конечных пользователей (такой сегмент известен под названием глухой сети), рассылка полноформатных RTMP-пакетов актуализации маршрутной информации может быть заменена рассылкой модифицированных укороченных пакетов обновления маршрутной информации. Укороченная форма позволяет рабочим станциям, серверам и принтерам продолжать работу и не увеличивает накладных расходов в сети, обусловленных отправкой RTMP-пакетов актуализации, содержащих полные таблицы маршрутизации.

Конфигурирование маршрутизатора так, чтобы он посылал на конфигурируемый интерфейс только пакеты актуализации для глухих сетей, осуществляется с помощью команды appletalk rtmp-stub. Хотя в сети компании ZIP было решено эту функцию не использовать, ниже показан пример конфигурирования с помощью этой команды, если бы было решено воспользоваться этой функцией на интерфейсе Ethernet маршрутизатора в Сингапуре:

Singapore#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

Singapore(config)#interface ethernet Singapore(config-if)#appletalk rtmp-stub Singapore(config-if)#^Z Работу как протокола AppleTalk EIGRP, так и протокола RTMP можно проверить с помощью ранее рассмотренной команды show appletalk route. Для более детальной проверки конфигурации и работы протокола AppleTalk EIGRP могут быть использованы дополнительные команды ОС IOS режима EXEC, которые показаны в табл. 5.3.

Таблица 5.3. Команды ОС IOS режима EXEC для протокола AppleTalk EIGRP Команда ОС IOS режима EXEC для Функция протокола EIGRP Выводит информацию об интерфейсах, show appletalk eigrp interfaces сконфигурированных на работу с протоколом AppleTalk EIGRP Выводит данные о соседях, выявленных протоко show appletalk eigrp neighbors лом AppleTalk EIGRP Выводит таблицу топологии протокола AppleTalk show appletalk eigrp topology EIGRP Выводит данные о количестве пакетов, show appletalk eigrp traffic отправленных и принятых процессом (процессами) протокола AppleTalk EIGRP Конфигурирование фильтрации в протоколе AppleTalk с применением списков доступа Средства фильтрации пакетов протокола AppleTalk в ОС IOS компании Cisco позволяют администратору сети, основываясь на различных критериях, ограничивать доступ к определенным ресурсам в AppleTalk-сети, включая отдельные серверы, принтеры, сегменты сети, диапазоны адресов и зоны целиком. Как и конфигурирование списков доступа для протокола TCP/IP, процесс конфигурирования фильтрации пакетов состоит из задания критериев фильтрации и наложения этих критериев на конкретные AppleTalk-интерфейсы.

Задание списков доступа Списки доступа для протокола AppleTalk несколько более сложны, чем списки доступа для протокола TCP/IP. Частично это обусловлено наличием логических зон, которые могут охватывать несколько интерфейсов и номеров AppleTalk-сетей. Кроме того, протокол AppleTalk пользуется зарегистрированными протоколом NBP именами устройств для доступа рабочих станций и серверов к сетевым ресурсам. Как уже рассматривалось ранее, адреса сеть. узел, связанные с этими сетевыми ресурсами, могут изменяться со временем в результате динамических переговоров об адресе узла устройства.

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

Вместо фильтрации на основе сетевых адресов протокола AppleTalk, рекомендуется использовать фильтры на основе имен служб протокола AppleTalk, которые зарегистрированы в протоколе NBP, и на базе запросов и распространения имен зон.

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

Все критерии фильтрации в протоколе AppleTalk реализуются через команду глобального конфигурирования ОС IOS access-list с использованием нумерованных списков доступа, номера которых лежат в диапазоне значений 600—699. В отличие от списков доступа протокола IP и списков доступа протокола межсетевого обмена пакетами (Internetwork Packet Exchange — IPX), порядок команд формирования списка доступа для протокола AppleTalk значения не имеет. Однако при проектировании списков доступа протокола AppleTalk следует не упускать из вида два важных критерия.

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

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

• команду глобального конфигурирования access-list other-access (при задании условий доступа к сетям и кабельным диапазонам);

• команду глобального конфигурирования access-list additional-zones (при задании условий доступа к зонам);

• команду глобального конфигурирования access-list other-nbps (при задании условий доступа к именованным сетевым ресурсам с использованием NBP-пакетов).

Эти команды могут ставиться в любом месте списка доступа. ОС IOS автоматически размещает команду access-list deny other-access в конце списка доступа. Она также размещает в конце списка команды access-list deny additional-zones и access-list deny other-nbps при задании условий доступа к зонам и NBP-именам, соответственно. Если явно не задать способ обработки пакетов с данными или пакетов обновления маршрутной информации, которые не удовлетворяют критериям операторов управления доступом, они автоматически пропущены не будут, а пакеты с данными будут уничтожены.

Для реализации фильтрации на основе имен сетевых ресурсов, зарегистрированных службой NBP, используйте в качестве параметра для нумерованного списка доступа протокола AppleTalk ключевое слово npb. Дополнительные ключевые слова позволяют осуществлять фильтрацию по типам объектов, именам объектов, по зонам, в которых размещаются объекты или по типам NBP-функции. В приведенном ниже примере задается NBP-фильтр на маршрутизаторе в Сан-Хосе, который запрещает доступ ко всем серверам, находящимся в Сан-Хосе, кроме выделенного сервера общего пользования в техническом департаменте. Заданный список доступа разрешает доступ к именованному ресурсу (в данном случае это сервер с именем "Открытый сервер технического департамента" (Engineering Public)), типу объекта (AppleTalk-файл-сервер или AFPServer) и к зоне, в которой объект размещается (зона Сан-Хосе (San Jose Zone)). Опция deny other-nbps запрещает доступ ко всем другим именованным ресурсам.

San-Jose#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+2.

San-Jose(config)#access-list 601 permit nbp 1 object Engineering Publio San-Jose(config)#access-list 601 permit nbp 1 type AFPServer San-Jose(config)#access-list 601 permit nbp 1 zone San Jose Zone San-Jose(config)#access-list 601 deny other-nbps San-Jose(config)#^Z Фильтрация по имени зоны позволяет ставить фильтр как на запросы об имени зоны, так и на распространение информации об именах зон. Как эти фильтры устанавливаются, будет показано в следующем разделе. Оба типа фильтрации по именам зон реализуются путем добавления к команде задания списка доступа протокола AppleTalk параметра в виде ключевого слова zone.

В примере ниже задается фильтр по имени зоны на маршрутизаторе в Сингапуре, который запрещает доступ к зоне с именем Operations Zone (Производственная зона), одновременно разрешая доступ к остальным зонам посредством ключевого слова additional-zones:

Singapore#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

Singapore(config)#access-list 605 deny zone Operations " Singapore(config)#access-list 605 permit additional-zones Singapore(config)#^Z Наложение списков доступа Задав критерии фильтрации списка доступа протокола AppleTalk, необходимо наложить их на один или несколько интерфейсов, чтобы могла выполняться фильтрация пакетов. Наложение списков доступа к интерфейсу может выполняться либо в выходящем направлении, либо во входящем. При входящем направлении перемещения пакетов они поступают в маршрутизатор через интерфейс. При выходящем направлении пакеты покидают маршрутизатор и поступают на интерфейс.

Списки доступа протокола AppleTalk, заданные как NBP-фильтры, накладываются с помощью субкоманды конфигурирования интерфейса ОС 1OS appletalk access-group. Параметром этой команды выступает ключевое слово in или out, при этом, если ключевое слово не указывается, по умолчанию подразумевается наличие слова out. В примере ниже выполняется наложение ранее заданного списка доступа протокола AppleTalk под номером 601 на интерфейсы глобальной сети маршрутизатора в Сан-Хосе, тем самым разрешается доступ из остальных частей сети компании ZIP только к открытому серверу технического департамента:

San-Jose#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

San-Jose(config)#interface serial 0/ San-Jose(config-if)#appletalk access-group San-Jose(config-if)#interface serial 1/ San-Jose(config-if)#appletalk access-group San-Jose(config-if)#^Z Чтобы понять, как списки доступа протокола AppleTalk, заданные в качестве фильтров имен зон, накладываются на запросы имени зоны и на распространение имен зон, рассмотрим принципы управления такими именами.

На маршрутизаторе имена зон отображаются на номера сетей с помощью протокола обмена информацией о зонах (Zone Information Protocol — ZIP). Когда маршрутизатор принимает в свою таблицу маршрутизации объявление о новой сети, протокол ZIP заносит сеть в таблицу информации о зонах (Zone Information Table — ZIT) и посылает наружу широковещательный ZIP-запрос об информации относительно зон, которые отображаются на адрес новой сети.

Подобным образом протокол ZIP может строить полный список всех зон, которые соответствуют адресам сетей, полученным из протоколов RTMP и EIGRP.

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

Примечание Не путайте протокол обмена информацией о зонах Zone Information Protocol (ZIP) со взятой в качестве примера сетью компании Zoom Integrated Products (ZIP).

Помня о роли протокола ZIP, рассмотрим применение фильтров имен зон протокола AppleTalk. Для фильтрации распространения имен зон от одного маршрутизатора к другому используется субкоманда конфигурирования интерфейса ОС IOS appletalk zip-reply-filter.

Такой фильтр работает, заставляя маршрутизатор отвечать на ZIP-запросы об отображении сети на имя зоны только теми именами зон, которые разрешены в списке доступа. В результате, команда appletalk zip-reply-filter накладывается только на ответные пакеты, которые являются выходящими для конфигурируемого интерфейса. В представленном ниже примере интерфейс Ethernet расположенного в Сингапуре маршрутизатора конфигурируется заданным ранее списком доступа 605 протокола AppleTalk так, чтобы ни один неизвестный маршрутизатор не узнал о зоне с именем Operations Zone:

Singapore #configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

Singapore(config)#interface ethernet Singapore(config-if)#appletalk zip-reply-filter Singapore(config-if)#^Z Для того чтобы пользователи не узнали об определенных зонах, используется субкоманда конфигурирования интерфейса ОС IOS appletalk getzonelist-filter. Фильтр работает, заставляя маршрутизатор отвечать на ZIP-запросы списков зон только теми именами зон, которые разрешены списком доступа. Как и для команды appletalk zip-reply-filter, единственными фильтруемыми ответными пакетами являются выходящие пакеты интерфейса, который конфигурируется командой getzonelist-filter. В показанном ниже примере интерфейс расположенного в Сингапуре маршрутизатора Ethernet конфигурируется ранее заданным списком доступа 605 протокола AppleTalk так, чтобы ни одна рабочая станция конечного пользователя при просмотре наличных ресурсов в окне выбора не узнала о зоне с именем Operations Zone:

Singapore#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

Singapore(config)#interface ethernet Singapore(config-if)#appletalk getzonelist-filter Singapore(config-if)#^Z Совет Как упоминалось выше, если в сегменте сети располагается несколько маршрутизаторов, то на ZIP-запросы списков зон типа GetZoneList может отвечать любой из них. Исходя из этого факта, важно, чтобы фильтрация имен зон накладывалась на все маршрутизаторы, принадлежащие одному сегменту сети, идентичным образом. Невыполнение условия идентичности приводит к тому, что пользователям будут предоставляться различные списки зон в зависимости от того, какое устройство отвечает на запрос. Также несовместимая фильтрация может привести к ситуации, когда зоны появляются и исчезают на рабочей станции пользователя каждые несколько секунд. Учитывая потенциальную несовместимость, как правило, следует накладывать фильтры имен зон только тогда, когда все маршрутизаторы работают под управлением ОС IOS, если только маршрутизаторы, которые не используют ОС IOS, не обладают аналогичными возможностями фильтрации.

Просмотреть поведение списков доступа и верифицировать правильность их конфигурации можно с помощью команд ОС IOS режима EXEC show access-list и show appletalk access-list.

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

Singapore#show appletalk access-lists AppleTalk access list 605:

deny zone Operations permit additional-zones Команда ОС IOS режима EXEC show appletalk interface показывает, где и для выполнения какого типа фильтрации на интерфейсе накладывается список доступа протокола AppleTalk. Последние две строчки показанного ниже результата исполнения этой команды на маршрутизаторе в Сингапуре указывают, что список доступа протокола AppleTalk под номером 605 наложен как zip-reply-фильтр и как getzonelist-фильтр:

Singapore#show appletalk interface ethernet EthernetO is up, line protocol is up AppleTalk cable range is 4001- AppleTalk address is 4008.30,Valid AppleTalk zone is "Manufacturing " AppleTalk address gleaning is disabled AppleTalk route cache is enabled AppleTalk GetZoneList filter is AppleTalk Zip Reply filter is Конфигурирование основных служб удаленного доступа по коммутируемым каналам связи протокола AppleTalk В этой главе рассматриваются возможности ОС IOS по маршрутизации с использованием протокола AppleTalk. ОС 1OS компании Cisco также позволяет осуществлять удаленный доступ AppleTalk-клиентов, что аналогично функциональным возможностям, описанным в предыдущей главе для работы на коммутируемых каналах связи протокола IP. Удаленный доступ по протоколу AppleTalk позволяет использовать службы протокола AppleTalk в условиях, когда пользователи не имеют физического соединения с выделенным каналом сегмента локальной сети.

В рамках ОС IOS возможность удаленного доступа по протоколу AppleTalk реализуется по асинхронным коммутируемым линиям и в рамках ISDN-сети. В данной главе рассматриваются специфические команды протокола AppleTalk, обычно используемые для конфигурирования служб доступа клиентов к сети по асинхронным коммутируемым каналам связи посредством AppleTalk протокола удаленного доступа (AppleTalk Remote Access Protocol — ARAP) и AppleTalk-протокола управления (AppleTalk Control Protocol — ATCP) из протокола двухточечной связи (Point-to-Point Protocol — PPP). AppleTalk-доступ в рамках стандарта ISDN обычно используется при маршрутизации по типу с запросом по вызову, но эта тема лежит за пределами предмета данной книга.

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

Только протокол ARAP требует дополнительных команд конфигурирования асинхронной линии. AppleTalk-клиенты, использующие протокол ARAP, требуют конфигурирования дополнительных ААА-служб, а пользователи, работающие с протоколом канального уровня РРР, используют конфигурацию ААА-служб, ранее рассмотренную для протокола IP и обсуждаемую в главе 7, "Основы администрирования и управления". И удаленные пользователи, работающие с протоколом ARAP, и удаленные пользователи, работающие с протоколом AppleTalk PPP, требуют наложения специфичных для протокола команд конфигурирования на групповой асинхронный интерфейс сервера доступа.

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

Субкоманда конфигурирования линии ОС IOS arap enable является первой из этих трех команд, которая разрешает работу протокола ARAP на коммутируемых линиях. Субкоманда конфигурирования линии ОС IOS arap authentication default инструктирует сервер доступа использовать метод аутентификации протокола ARAP по умолчанию, сконфигурированный через службу ААА. И наконец, субкоманда конфигурирования линии ОС IOS autoselect агар конфигурирует в сервере доступа автоматическое распознавание попытки удаленного пользователя подключиться с использованием протокола ARAP. В примере ниже показано доконфигурирование сервера доступа Sing2511, на котором ранее были сконфигурированы IP службы удаленного доступа, субкомандами конфигурирования линии протокола ARAP:

Sing2511#configure Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line. End with CTRL+Z.

Sing2511(config)#line 1 Sing2511(config-line)#arap enable Sing2511(config-line)#arap authentication default Sing2511(config-line)#autoselect arap Sing2511(config-line)#^Z Для верификации личности удаленных пользователей, обращающихся через протокол ARAP, требуются дополнительные команды ААА-аутентификации. Чтобы задать критерии идентификации ARAP-пользователей, используется команда глобального конфигурирования ааа authentication arap. В качестве параметра этой команды выступают название метода и список методов аутентификации. Как и для протокола РРР, аутентификация в рамках протокола ARAP может выполняться с использованием локального имени пользователя или сервера аутентификации, например, с помощью системы управления доступом через контроллер доступа к терминалу TACACS+ (Terminal Access Controller Access Control System).

Управление гостевыми регистрациями также может задаваться с помощью ключевого слова auth-guest, которое определяет, что гостевые регистрации в протоколе ARAP допускаются, только если пользователь во время сеанса удаленного доступа предварительно был освидетельствован для работы в режиме EXEC ОС IOS.

Удаленным пользователям, работающим с протоколом ARAP, также необходимо сообщить AppleTalk-номер сети и зоны, к которым они приписываются во время сеанса удаленного доступа по коммутируемой линии связи. Для задания ARAP-номера сети и имени зоны используется команда глобального конфигурирования ОС IOS arap network.

Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.