Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
^•Руководство nq «поиску‘ НЕИСПРАВНОСТЕЙ ?
«^ ОБЪЕДИНЕННЫХ СЕТЯХ
Internetworking Troubleshooting Handbook
Second Edition
Cisco Systems
Cisco Press
Cisco Press • 201 West 1O3rd Street, Indianapolis, IN,46290 USA
Руководство по поиску НЕИСПРАВНОСТЕЙ ^ОБЪЕДИНЕННЫХ СЕТЯХ
Москва •:Са^кт^Петер,б$у • Киев
2003 У'
ББК 32.973.26-018.2.75
Р85
УДК 681.3.07
Издательский дом “Вильямс”
Зав. редакцией С.Н. Тригуб
Перевод с английского и редакция К.А. Птицына
По общим вопросам обращайтесь в Издательский дом “Вильямс” по адресу:
info@williamspublishing.com, http://www.williamspublishing.com
Cisco Systems, и др.
Р85 Руководство по поиску неисправностей в объединенных сетях. : Пер. с англ. — М.: Издательский дом “Вильямс”, 2003. — 1040 с.: ил. — Парад, тит. англ.
ISBN 5-8459-0411-0 (рус.).
Данная книга предназначена для использования в качестве основного источника информации при решении задач, связанных с устранением нарушений в работе сети. Она может применяться в качестве пособия, позволяющего быстро находить решения проблем, возникающих в процессе функционирования сети.
В книге значительное внимание уделено профилактике нарушений в работе сети. В частности, описано, какие данные должны быть собраны в процессе нормальной эксплуатации сети для подготовки к устранению возможных аварийных ситуаций, и приведены рекомендации, позволяющие обеспечить бесперебойное функционирование сети.
При описании процесса поиска неисправностей в каждой конкретной сетевой среде приведены основные сведения о рассматриваемой сетевой технологии.
ББК 32.973.26-018.2.75
Все названия программных продуктов являются зарегистрированными торговыми марками соответствующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирование и запись на магнитный носитель, если на это нет письменного разрешения издательства Cisco Press.
Authorized translation from the English language edition published by Cisco Press, Copyright © 2002
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher.
Russian language edition published by Williams Puhlkhinp House according to the Agreement with R&I Enterprises International, Copyright © 2003
ISBN 5-8459-0411-0 (pyc.)ISBN 1-587O-5OO5-6 (англ.)ISBN 5-8459-0411-0 (pyc.)ISBN 1-587O-5OO5-6 (англ.)© Издательский дом “Вильямс”, 2003
ISBN 5-8459-0411-0 (pyc.)
ISBN 1-587O-5OO5-6 (англ.)
ISBN 5-8459-0411-0 (pyc.)
ISBN 1-587O-5OO5-6 (англ.)
© Cisco Press, 2002
Оглавление
Предисловие
Часть I. Основные принципы поиска неисправностей
Глава 1. Общее описание процесса поиска неисправностей
Глава 2. Инструментальные средства поиска неисправностей
Часть II. Устранение нарушений в работе аппаратных средств, средств загрузки и передающей среды
Глава 3. Устранение нарушений в работе аппаратных средств и средств загрузки
Глава 4. Устранение нарушений в работе сети Ethernet
Глава 5. Устранение нарушений в работе сети FDDI
Глава 6. Устранение нарушений в работе сети Token Ring
Часть III. Устранение нарушений в работе маршрутизирующих протоколов
Глава 7. Устранение нарушений в работе протоколов TCP/IP
Глава 8. Устранение нарушений в работе сети Novell IPX
Глава 9. Устранение нарушений в работе сети AppleTalk
Глава 10. Устранение нарушений в работе сети IBM
Глава 11. Устранение нарушений в работе сети DECnet
Глава 12. Устранение нарушений в работе сети ISO CLNS
Глава 13. Устранение нарушений в работе сети Banyan VINES
Глава 14. Устранение нарушений в работе сети XNS
Часть IV. Устранение нарушений в работе последовательных каналов и соединений распределенной сети
Глава 15. Устранение нарушений в работе последовательных каналов
Глава 16. Устранение нарушений в работе коммутируемых соединений
Глава 17. Устранение нарушений в работе соединений ISDN
Глава 18. Устранение нарушений в работе соединений Frame Relay
252931374951119137157171173205251299347373397413425427489547589605252931374951119137157171173205251299347373397413425427489547589605Глава 19. Устранение нарушений в работе соединений Х.25
25
29
31
37
49
51
119
137
157
171
173
205
251
299
347
373
397
413
425
427
489
547
589
605
25
29
31
37
49
51
119
137
157
171
173
205
251
299
347
373
397
413
425
427
489
547
589
605
619619Часть V. Устранение нарушений в работе среды маршрутизации и прозрачного мостового перенаправления
619
619
Глава 20. Устранение нарушений в работе среды прозрачного мостового перенаправления621
Глава 21. Устранение нарушений в работе сетей LANE ATM639
Глава 22. Устранение нарушений в работе постоянных виртуальных каналов ATM в среде распределенной сети661
Глава 23. Устранение нарушений в работе средств коммутации локальной сети 679
Часть VI. Устранение других нарушений в работе объединенной сети801
Глава 24. Устранение нарушений в работе приложения CiscoWorks 2000803
Глава 25. Устранение нарушений в работе средств обеспечения безопасности сети891
Часть VII. Приложения941
Приложение А. Формирование дампа ядра943
Приложение Б. Схемы распределения памяти949
Приложение В. Информация о техническойподдержке1007
Предметный указатель1014
Содержание
Предисловие25
Назначение данной книги25
Благодарности25
Соглашения, принятые в книге26
Часть I. Основные принципы поиска неисправностей29
Глава 1. Общее описание процесса поиска неисправностей31
Признаки неисправностей, проблемы и решения31
Общая модель решения проблемы поиска неисправностей32
Подготовка к возникновению сетевых отказов34
Глава 2. Инструментальные средства поиска неисправностей37
Применение диагностических команд маршрутизатора37
Применение команд show37
Применение команд debug39
Применение команд ping40
Применение команд trace41
Инструментальные средства управления сетью, предоставляемые
корпорацией Cisco41
Программа Cisco View42
Монитор производительности объединенной сети43
Приложение RMON TrafficDirector43
Приложение управления коммутатором VlanDirector44
Инструментальные средства поиска неисправностей, предоставляемые независимыми поставщиками44
Вольтомметры, цифровые мультиметры и кабельные тестеры45
Динамические рефлектометры и оптические динамические рефлектометры45
Коммутационные боксы, генераторы тестовых последовательностей
и тестеры частоты ошибочных битов/частоты ошибочных блоков46
Сетевые мониторы46
Сетевые анализаторы47
Часть II. Устранение нарушений в работе аппаратных средств, средств загрузки и передающей среды49
Глава 3. Устранение нарушений в работе аппаратных средств и средств загрузки51
Загрузка маршрутизатора52
Рекомендации по загрузке через сеть53
Надежные методы начальной загрузки53
Тайм-ауты и пакеты, поступающие с нарушением порядка следования54
Информация для службы технической поддержки55
Поиск неисправностей аппаратных средств55
Запуск маршрутизаторов ряда Cisco 750055
Запуск маршрутизаторов ряда Cisco 700058
Запуск маршрутизаторов ряда Cisco 400061
Запуск маршрутизаторов ряда Cisco 250063
Запуск коммутаторов ряда Catalyst 500066
Запуск коммутаторов ряда Catalyst 290068
Проверка и аттестация сменного оборудования69
Поиск неисправностей, которые приводят к нарушению загрузки70
Начальная загрузка: маршрутизатор не может загрузиться из флэш-памяти70
Начальная загрузка: при загрузке из флэш-памяти возникает векторная ошибка73
Начальная загрузка: маршрутизатор частично загружается из флэш-памяти и отображает приглашение процедуры начальной загрузки 75
Начальная загрузка: маршрутизатор не может загрузиться
по сети от ТЕТР-сервера77
Начальная загрузка: маршрутизатор не может загрузиться по сети от другого маршрутизатора80
Начальная загрузка: тайм-ауты и пакеты с нарушением порядка следования препятствуют выполнению загрузки по сети81
Начальная загрузка: недействительные маршруты препятствуют выполнению загрузки по сети82
Начальная загрузка: клиентские запросы ARP завершаются по тайм-ауту во время загрузки по сети83
Начальная загрузка: во время загрузки по сети возникает ошибка “неопределенный загрузочный модуль”85
Начальная загрузка: маршрутизатор зависает после инициализации режима ROMmon85
Начальная загрузка: маршрутизатор не выходит из режима ROMmon86
Начальная загрузка: искаженный вывод призагрузке из ПЗУ87
Начальная загрузка: возникновение локальных тайм-аутов при загрузке из ПЗУ88
Начальная загрузка: не функционирующее терминальное соединение с ненастроенным сервером доступа89
Запуск LAN-коммутаторов ряда Catalyst 600090
Устранение неисправности коммутатора Catalyst 6000, связанной с искажением или отсутствием загрузочногообраза90
Основные сведения, необходимые для использования процедуры устранения неисправности91
Процедуры устранения неисправности92
Загрузка образа Catalyst IOS101
Загрузка образа Catalyst OS103
Загрузка и запуск маршрутизатора Cisco 2600 попротоколу ТЕТР108
Введение108
Поиск неисправностей в системах питанияиохлаждения111
Запуск маршрутизатора Cisco 3600111
Введение111
Поиск неисправностей114
Запуск коммутатора Catalyst 4000 корпорации Cisco114
Поиск неисправностей116
Глава 4. Устранение нарушений в работе сети Ethernet119
Спецификации Ethernet и IEEE 802.3119
Дуплексный режим работы в сетях с пропускной способностью
10/100/1000 Мбит/с122
Автоматическое согласование123
Физические соединения124
Форматы фреймов126
Устранение нарушений в работе сети Ethernet127
Команда show interfaces ethernet129
Глава 5. Устранение нарушений в работе сети FDDI137
Основы технологии FDDI137
Спецификации FDDI138
Физические соединения139
Типы трафика140
Средства обеспечения отказоустойчивости140
Форматы фреймов143
Спецификация CDDI144
Устранение нарушений в работе сети FDDI145
Команда show interfaces fddi145
Глава 6. Устранение нарушений в работе сети Token Ring157
Сравнение спецификаций Token Ring и IEEE 802.5157
Эстафетная передача158
Физические соединения159
Система приоритетов160
Механизмы повышения отказоустойчивости160
Форматы фреймов161
Маркеры161
Фреймы данных/команд161
Устранение нарушений в работе сети Token Ring162
Нарушения в работе передающей среды сети Token Ring162
Команда show interfaces tokenring164
Часть III. Устранение нарушений в работе маршрутизирующих протоколов 171
Глава 7. Устранение нарушений в работе протоколов TCP/IP173
Общие сведения о протоколах TCP/IP173
Протоколы Internet174
Сетевой уровень175
Адресация176
Маршрутизация Internet178
Протокол ICMP179
Транспортный уровень180
Протокол TCP180
Протокол UDP181
Протоколы верхнего уровня181
Система доменных имен182
Инструментальные средства устранения нарушений в работе протокола IP 182
Инструментальное средство ping183
Инструментальное средство traceroute185
Отладка пакетов187
Общие рекомендации по устранению нарушений в работе протокола IP 189
Сужение проблемной области190
Устранение нарушений связи в локальной сети191
Проверка правильности конфигурации191
Проверка наличия связи в локальной сети192
Выявление наличия повторяющихся IP-адресов192
Устранение физических нарушений связи192
Выявление нарушений конфигурации193
Проверка кабельных соединений193
Проверка конфигурации193
Проверка сетевого интерфейса193
Устранение нарушений связи по протоколу 1Р и проблем маршрутизации194
Определение исходной точки для поиска неисправностей194
Проверка ресурсов195
Проверка наличия связи196
Проверка списков управления доступом197
Проверка преобразованиясетевых адресов197
Устранение нарушений в работе протоколов верхнего уровня197
Общее описание процесса поиска причин нарушения в работе198
Протокол HTTP передачи гипертекста198
Протокол FTP199
Электронная почта (IMAP, POP и SMTP)200
Протокол Telnet201
Устранение нарушений в работе сервера доменных имен201
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco203
Дополнительная информация203
Глава 8. Устранение нарушений в работе сети Novell IPX205
Основы технологии Novell205
Доступ к передающей среде207
Сетевой уровень207
Транспортный уровень209
Протоколы верхнего уровня209
Устранение нарушений в работе сети Novell IPX210
Novell IPX: клиент не может подключиться к серверу в той же локальной сети211
Novell IPX: клиент не может подключиться к серверу в другой локальной сети212
Novell IPX: клиент не может подключиться к серверу по сети PSN216
Novell IPX: клиент не может подключиться к серверу по сети ISDN218
Novell NetBIOS: приложение не может подключиться к серверу через маршрутизатор219
IPX RIP: отсутствие связи через маршрутизатор IPX RIP221
IPX RIP: обновления протокола SAP не распространяются маршрутизатором226
IPX EIGRP: отсутствие связи через маршрутизатор EIGRP протокола IPX 229
IPX EIGRP: маршрутизатор не устанавливает связь со смежными маршрутизаторами232
IPX EIGRP: обновления протокола SAP не распространяются маршрутизатором233
IPX EIGRP: маршрутизатор не выходит из активного режима236
Novell IPX: отсутствие надежной связи239
Novell IPX: низкая производительность242
Пакеты SAP корпорации Novell243
Глава 9. Устранение нарушений в работе сети AppleTalk251
Основы технологии AppleTalk252
Доступ к передаюшей среде252
Сетевой уровень253
Присваивание протокольного адреса254
Сетевые объекты254
Протокол доставки дейтаграмм256
Транспортный уровень257
Протокол RTMP257
Протокол AURP258
Протокол АЕР261
Протокол АТР261
Протоколы верхнего уровня261
Устранение нарушений в работе сети AppleTalk262
Рекомендации по настройке конфигурации и устранению нарушений в работе сети AppleTalk263
AppleTalk: пользователи не могут обратиться к зонам или службам268
AppleTalk: в программе Chooser отсутствует информация о зонах272
AppleTalk: в программе Chooser не задана информация об устройствах276
AppleTalk: периодически нарушается доступ к сетевым службам277
AppleTalk: в программе Chooser появляются старые имена зон (“фантомные” зоны)281
AppleTalk: происходит разрыв соединений со службами282
AppleTalk: все попытки инициализировать маршрутизацию AppleTalk в интерфейсе оканчиваются неудачей284
AppleTalk: порт не выходит из режима перезапуска или сбора информации о конфигурации285
AppleTalk Enhanced IGRP: клиенты не могут подключиться к серверам 286
AppleTalk Enhanced 1GRP: в маршрутизаторах не формируются таблицы смежных устройств287
AppleTalk Enhanced IGRP: в таблице маршрутизации отсутствуют маршруты288
AppleTalk Enhanced IGRP:низкая производительность289
AppleTalk Enhanced IGRP: маршрутизатор не выходит из активного режима290
AURP: маршруты не распространяются через туннель AURP292
FDDiTalk: с маршрутами не связана ни одна зона293
ARA: клиент ARA не способен подключиться к серверу ARA294
ARA: соединение зависает после поступления сообщения "Communicating At..."295
ARA: невозможно передавать или принимать данные по входящему коммутируемому соединению ARA295
ARA: низкая производительность при передаче данных по входящему коммутируемому соединению297
Глава 10. Устранение нарушений в работе сети IBM299
Протокол DLSw299
Протокол SDLC299
Основы технологии300
Формат фрейма301
Алгоритм SRB302
Основные сведения об алгоритме SRB303
Формат фрейма305
Устранение нарушений в работе сети IBM306
Локальное перенаправление SRB: хост не может подключиться к серверу 306
Локальное перенаправление SRB: не функционируют средства перенаправления310
RSRB: хост не может подключиться к серверу (одноранговые узлы
не открыты)311
RSRB: хост не может подключиться к серверу (одноранговые узлы открыты)314
RSRB: периодические нарушения связи316
RSRB: клиент NetBIOS не может подключиться к серверу317
Мостовое перенаправление с трансляцией: клиент не может подключиться к серверу319
Мостовое перенаправление SRT: клиент не может подключиться к серверу323
SDLC: маршрутизатор не может обмениваться данными
с устройством SDLC324
SDLC: отсутствие надежной связи329
SDLC: клиент не может подключиться к хосту через маршрутизатор, работающий под управлением программного обеспечения SDLLC330
Виртуальные адреса Token Ring и интерфейс SDLLC334
SDLC: сеансы, установленные через маршрутизатор, работающий под управлением программного обеспечения STUN, оканчиваются аварийно 335
С1Р: не активизируется соединение CLAW339
С1Р: не загорается светодиод Enabled339
С1Р: интерфейсный процессор не переходит в оперативный режим работы с хостом340
С1Р: маршрутизатор не может выполнить эхо-тестирование хоста или
хост не может выполнить эхо-тестирование маршрутизатора341
С1Р: хост не может установить связь с удаленными сетями342
CIP: хост, в котором функционирует демон routed, не имеет информации о маршрутах342
Глава 11. Устранение нарушений в работесети DECnet347
Сетевая структура Digital347
Сетевой уровень348
Формат фрейма маршрутизацииDECnet PhaseTV349
Адресация350
Уровни маршрутизации351
Транспортный уровень352
Протоколы верхнего уровня352
Поиск неисправностей DECnet352
Применение спецификации DECnet в мультипротокольной среде353
DECnet: попытки установления соединений с хостами DEC через маршрутизатор оканчиваются неудачей (нарушение в работе оконечного узла)354
DECnet: попытки установления соединений с хостами DEC через маршрутизатор оканчиваются неудачей (нарушение в работе маршрутизатора)357
DECnet: оконечные узлы не могут найти назначенный маршрутизатор 360 DECnet: маршрутизатор или оконечный узел обнаруживает неправильно назначенный маршрутизатор361
DECnet: маршрутизаторы не устанавливают отношения смежности364
DECnet: отношения смежности маршрутизирующего узла то устанавливаются, то разрываются366
DECnet: отсутствие связи между сетевыми устройствами Phase IV по опорной сети Phase V367
DECnet: низкая производительность369
Глава 12. Устранение нарушений в работе сети ISO CLNS373
Основы технологии ISO CLNS374
Адресация в сети ISO CLNS374
Устранение нарушений в работе сети ISO CLNS377
ISO CLNS: хост не может получить доступ к хостам в локальной или удаленной сети378
ISO CLNS: хост не может получить доступ к хостам в той же зоне381
ISO CLNS: хост не может получить доступ к хостам в другой зоне384
ISO CLNS: попытки установления соединения с использованием некоторых протоколов завершаются неудачей387
ISO CLNS: пользователи не могут устанавливать соединения по параллельному пути388
ISO CLNS: перераспределение маршрутов приводит к появлению проблем маршрутизации389
ISO CLNS: низкая производительность393
Глава 13. Устранение нарушений в работе сети Banyan VINES397
Основы технологии VIN ES397
Доступ к передающей среде всети VINES398
Сетевой уровень398
Протокол VIP398
Протокол RTP402
Протокол ARP403
Протокол ICP403
Транспортный уровень403
Протоколы верхнего уровня404
Устранение нарушений в работе сети Banyan VINES404
VINES: клиенты не могут подключиться к серверам через маршрутизатор404
VINES: клиент не может подключиться к серверу через сеть с коммутацией пакетов407
VINES: клиент бессерверной сети не может подключиться к серверу через сеть с коммутацией пакетов408
Глава 14. Устранение нарушений в работе сети XNS413
Сетевой уровень413
Транспортный уровень415
Протоколы верхнего уровня416
Устранение нарушений в работе сети XNS416
XNS: клиенты не могут подключиться к серверам через маршрутизатор417
XNS: широковещательные пакеты XNS не перенаправляются маршрутизатором420
XNS: клиент не может подключиться к серверу через сеть с коммутацией пакетов422
Часть IV. Устранение нарушений в работе последовательных каналов и соединений распределенной сети425
Глава 15. Устранение нарушений в работе последовательных каналов427
Устранение нарушений в работе с использованием команды show interfaces serial427
Последовательные каналы: сообщения в строке состояния show interfaces serial428
Последовательные каналы: увеличение количества уничтоженных выходных пакетов в последовательном канале434
Последовательные каналы: увеличение количества уничтоженных входных пакетов в последовательном канале435
Последовательные каналы: количество ошибок во входных пакетах превышает примерно 1% от общего объема трафика через интерфейс 435 Последовательные каналы: устранение ошибок ввода в последовательном канале437
Последовательные каналы: увеличение количества случаев сброса интерфейса в последовательном канале440
Последовательные каналы: увеличение количества случаев перехода на другую несущую в последовательном канале440
Применение команды show controllers442
Применение команд debug443
Методы проверки с помощью расширенной команды эхо-тестирования446
Устранение нарушений синхронизации447
Краткий обзор методов синхронизации448
Причины нарушения синхронизации449
Способы обнаружения нарушений синхронизации449
Способы определения причин нарушений синхронизации450
Решения проблем синхронизации451
Корректировка размеров буферов452
Настройка системных буферов453
Корректировка предельных размеров очереди455
Организация очередей по приоритетам для повышения производительности456
Специальные способы проверки последовательного канала457
Рекомендации по проверке петлевого интерфейсаCSU, DSU457
Подробные сведения о команде show interfaces serial460
Команда show interfaces serial460
Устранение нарушений в работе канала Т1465
Поиск неисправностей с помощью команды show controller tl465
Состояния контроллера в выводе команды show controller tl466
Контроллер остановлен администратором466
Канал не функционирует467
Канал находится в режиме использования петли обратной связи468
Контроллер выводит аварийные сигналы468
Устранение нарушений в работе, указанных в сообщениях об ошибках 471
Устранение нарушений в работе интерфейса PR1473
Устранение нарушений в работе канала Е1477
Поиск неисправностей с помощью команды show controller el477
Контроллер остановлен администратором478
Канал не функционирует478
Канал находится в режиме использования петли обратной связи480
Контроллер выводит аварийные сигналы480
Устранение нарушений в работе интерфейса PRI484
Глава 16. Устранение нарушений в работе коммутируемых соединений489
Операции модема490
Применение команды modem autoconfigure490
Установление обратного сеанса Telnet к модему490
Применение чередующихся групп493
Интерпретация вывода команды show line494
Сбор информации о производительности модема497
Команды show modem/show modem summary498
Команда show modem call-stats499
Команда show modem connect speeds500
Команда modem call-record terse (11.3AA/12.0T)500
Команда show modem operational-status501
Сбор информации о производительности работы клиента501
Анализ данных о производительности501
Характерные проблемы при эксплуатации серверных модемов определенных типов501
Нарушения в работе конкретных DSO-каналов502
Некоторые наиболее характерные нарушения связи502
Операции ISDN503
Компоненты ISDN504
Службы ISDN506
Уровень 1507
Уровень 2508
Уровень 3509
Интерпретация вывода команды show isdn status510
Маршрутизация с набором номера по требованию: операции интерфейса номеронабирателя513
Активизация набора номера514
Команды привязки номеронабирателя522
Профили номеронабирателя525
Операции РРР528
Этапы согласования параметров соединения протоколаРРР528
Другие варианты применения протокола РРР531
Пример согласования параметров протокола РРР с пояснениями541
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco543
Дополнительная информация544
Глава 17. Устраиеиие нарушений в работе соединений ISDN547
Введение547
Устранение нарушений в работе средств обработки входящих вызовов548
Устранение нарушений в работе оборудования приема входящих вызовов ISDN548
Устранение нарушений в работе оборудования приема входящих вызовов С AS550
Устранение нарушений при обработке входящих вызовов модема551
Устранение нарушений в работе средств обработки входящих вызовов565
Проверка работы номеронабирателя565
Инициализация вызова567
Асинхронный исходящий вызов — проверка функционирования сценария диалогового взаимодействия568
Обработка исходящих вызовов ISDN569
Исходящие вызовы CAS573
Устранение нарушений в работе протокола РРР575
Протокол LCP578
Аутентификация580
Протокол NCP581
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco585
Дополнительная информация586
Глава 18. Устранение нарушений в работе соединений FrameRelay589
Основы технологии Frame Relay589
Расширения LMI591
Формат фрейма591
Формат сообщения LMI593
Конфигурация сети Frame Relay595
Создание сети595
Устранение нарушений в работе сети Frame Relay597
Frame Relay: не функционирует канал FrameRelay597
Frame Relay: не может быть выполнено эхо-тестирование удаленного маршрутизатора599
Frame Relay: не может быть выполнено сквозное эхо-тестирование602
Глава 19. Устранение нарушений в работе соединений Х.25605
Основы технологии Х.25606
Формат фрейма Х.25608
Уровень 3608
Уровень 2609
Уровень 1610
Устранение нарушений в работе сети Х.25611
Применение команды show interfacesserial611
Х.25: не устанавливаются соединения по каналу Х.25612
Х.25: чрезмерное количество ошибок последовательной передачи в канале Х.25615
Часть V. Устранение нарушений в работе среды маршрутизации и прозрачного мостового перенаправления619
Глава 20. Устранение нарушений в работе среды прозрачного мостового перенаправления621
Основы технологии прозрачного мостового перенаправления621
Устранение циклов мостового перенаправления622
Алгоритм распределенного связующего дерева623
Формат фрейма626
Формат сообщения626
Различные методы мостового перенаправления, применяемые в системе IOS627
Устранение нарушений в работе средств прозрачного мостового перенаправления629
Прозрачное мостовое перенаправление: отсутствие связи630
Прозрачное мостовое перенаправление: нестабильное распределенное связующее дерево632
‘ Прозрачное мостовое перенаправление: непредвиденное завершение сеансов634
Прозрачное мостовое перенаправление: возникают циклы, и происходит лавинообразная рассылка широковещательных пакетов635
Подготовка к получению консультации в центре ТАС компании Cisco
Systems637
Дополнительные источники информации637
Литература637
Сетевые информационные ресурсы637
Глава 21. Устранение нарушений в работе сетей LANE ATM639
Введение639
Устранение нарушений в работе сети LAN Emulation641
Устранение нарушений в работе, при которых не происходит запуск LEC-кл центов641
Приложение: команды и примеры648
Описание вывода команды show lane client654
Процесс применения протокола LE_ARP656
Дополнительные команды658
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco659
Дополнительные источники информации659
Глава 22. Устранение нарушений в работе постоянных виртуальных каналов ATM в среде распределенной сети661
Введение661
Обшее описание процесса сегментации и повторной сборки фреймов AAL5 663
Основные сведения об ограничении и упорядочении трафика666
Основные сведения о методе ограничения VBR-NRT667
Установление соответствия между адресом получателя и постоянным виртуальным каналом669
Основные задачи устранения нарушенийсвязи669
Устранение нарушений в работе постоянного виртуального канала, характеризующихся полным отсутствиемсвязи671
Наиболее важные команды674
Команда pvc674
Командный режим674
Команда atm pvc676
Командный режим676
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco677
Дополнительные источники информации677
Глава 23. Устранение нарушений в работе средств коммутации локальной сети 679
Основные сведения об использовании LAN-коммутаторов680
Концентраторы и коммутаторы680
Мосты и коммутаторы680
Виртуальные локальные сети681
Алгоритм прозрачного мостового перенаправления681
Формирование магистральных каналов683
Метод создания логических каналов EtherChannel683
Многоуровневая коммутация684
Дополнительная информация с описанием средств MLS684
Общие рекомендации по устранению нарушений в работе коммутаторов685
Устранение нарушений в работе, характеризующихся отсутствием связи через порт686
Неисправности аппаратных средств686
Проблемы настройки конфигурации689
Проблемы при прохождении трафика691
Отказ аппаратных средств коммутатора692
Устранение нарушений в работе средств автоматического согласования дуплексного/полудуплексного режима передачи на скорости 10/100 Мбит/с 693
Введение693
Устранение нарушений в работе средств автоматического согласования параметров Ethernet между устройствами сетевой инфраструктуры694
Примеры настройки конфигурации и устранения нарушений в работе
средств автоматического согласования каналов Ethernet на 10/100 Мбит/с 697
Задачи настройки конфигурации порта697
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco703
Дополнительная информация703
Формирование магистральных каналов 1SL в коммутаторах семейства
Catalyst 5000 и 6000703
Введение704
Устранение нарушений в работе средств формирования магистральных каналов 1SL в коммутаторах семейства Catalyst 5000 и 6000704
Примеры настройки конфигурации и устранения нарушений в работе средств формирования магистральных каналов 1SL в коммутаторах семейства Catalyst 5000 и 6000706
Возможные сочетания конфигураций DTP711
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco712
Настройка конфигурации канала EtherChannel от коммутатора к коммутатору в устройствах ряда Catalyst 4000/5000/6000713
Содержание раздела714
Задачи настройки конфигурации EtherChannel вручную714
Поэтапная процедура715
Проверка конфигурации EtherChannel721
Применение протокола PAgP для автоматической настройки конфигурации EtherChannel (предпочтительный метод)723
Средства формирования магистральных каналов и каналов EtherChannel 728 Устранение нарушений в работе средств EtherChannel730
Команды, применяемые для настройки конфигруации738
Применение PortFast и других команд для устранения нарушений в работе, характеризующихся отсутствием связи с оконечной станцией после запуска 739
Содержание741
Общие сведения741
Способы сокращения задержек при запуске в коммутаторе Catalyst 4000/5000/6000745
Измерение продолжительности задержки с применением и без применения средств DTP, PAgP иPortFastв коммутаторе Catalyst5000748
Способы сокращения задержки при запуске в коммутаторе
Catalyst 2900XL/3500XL756
Измерение продолжительности задержки вкоммутатореCatalyst2900XL757
Способы сокращения задержек при запуске в коммутаторе
Catalyst 1900/2800761
Измерение продолжительности задержки в коммутаторе Catalyst 1900763
Дополнительные преимущества применения средства PortFast763
Команды, предназначенные для проверки конфигурации764
Команды, применяемые для выявления ошибок в конфигурации765
Настройка конфигурации и устранение нарушений в работе средств многоуровневой коммутации IP766
Введение766
Устранение нарушений в работе средств MLS IP770
Команды и снимки с экрана779
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco779
Устранение нарушений в работе средств протокола распределенного связующего дерева780
Нарушения в работе протокола распределенного связующего дерева780
Устранение нарушений в работе786
Проектирование сети для обеспечения бесперебойной работы протокола STP792
Дополнительная информация798
Часть VI. Устранение других нарушений в работе объединенной сети 801
Глава 24. Устранение нарушений в работе приложения CiscoWorks 2000803
Назначение главы803
Основные сведения803
Устранение нарушений, возникающих в процессе инсталляции и настройки программ CiscoWorks 2000 '804
Устранение нарушений в процессе инсталляции обязательного программного обеспечения сервера805
Инструментальные средства устранения нарушений в работе Essentials 805 Регистрация в системе после обновления программного обеспечения807
Проверка файлов и каталогов после инсталляции808
Анализ сообщений об ошибках, возникающих во время инсталляции 810 Доступ к серверу Essentials820
Настройка параметров броузера821
Ввод и импорт информации об устройстве821
Сбор информации о сервере822
Приложения Essentials Daemon Manager и CWSI Campus823
Устранение нарушений при регистрации на сервере AniServer824
Проверка соединения с базой данных825
Методы оценки ситуации и устранения нарушений в работе
приложения RME825
Формат сообщений об ошибках826
Средства регистрации состояния процесса826
Устранение нарушений в работе процесса827
Устранение нарушений в работе приложения CWSI Campus850
Общие сведения о фоновых процессах CWSI Campus850
Запуск приложения CWSI Campus854
Способы повышения производительности приложения CWSI Campus 857
Правила ввода обозначений групп устройств858
Применение средств обнаружения устройств Cisco859
Формирование отчетов о расхождениях863
Информация по устранению нарушений в работе приложений CWSI Campus 865
Устранение нарушений в работеприложения VlanDirector865
Настройка конфигурации службLANE867
Устранение нарушений в работеприложения AtmDirector871
Устранение нарушений в работеприложения TrafficDirector878
Устранение нарушений в работеприложения CiscoView883
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco886
Дополнительная литература887
Глава 25. Устранение нарушений в работе средств обеспечения безопасности сети891
Основные задачи892
Устранение нарушений в работе продукта CiscoSecure Scanner892
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco893
Устранение нарушений в работе продукта CiscoSecure Intrusion Detection
System (NetRanger)893
Команды, применяемые для устранения нарушений в работе приложения IDS894
Файлы журналов, применяемые для устранения нарушений в работе приложения895
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco907
Устранение нарушений в работе брандмауэра FIX Firewall907
Поиск истинной причины нарушения в работе907
Команды debug908
Этапы поиска неисправностей911
Методы поиска неисправностей914
Подготовка необходимой информации перед обращением
к специалистам центра ТАС компании Cisco Systems916
Дополнительные источники информации916
Обслуживание брандмауэра PIX916
Восстановление пароля916
Способы модернизации программного обеспечения919
Восстановление утраченного пароля920
Процедура восстановления пароля: платформы, на которых эксплуатируется текущая версия Cisco 1OS921
Процедура восстановления пароля: платформы, на которых эксплуатируются новейшие версии программного обеспечения928
Процедура восстановления пароля: платформы, на которых эксплуатируются более ранние версии программного обеспечения932
Процедура восстановления пароля: маршрутизатор IGS, на котором эксплуатируется версия программного обеспечения, предшествующая версии 9.1936
Процедура восстановления пароля: сервер связи Cisco 500-CS939
Часть VII. Приложения941
Приложение А. Формирование дампа ядра943
Основные способы настройки конфигурации943
Использование протокола FTP943
Использование протокола FTP944
Использование протокола RCP944
Применение флэш-диска944
Дополнительные команды конфигурации945
Команды exception memory945
Команда debug sanity945
Проверка результатов настройки конфигурации для формирования дампа ядра946
Приложение Б. Схемы распределения памяти949
Поиск неисправностей при аварийном завершении работы949
Типы аварийных отказов и их причины950
Ошибки шины и исключения SegV950
Принудительный аварийный отказ, активизированный программным путем951
Ошибка в адресе951
Контрольный тайм-аут951
Ошибка четности952
Другие типы аварийных отказов952
Схемы распределения памяти952
Схема распределения памяти 12000-GRP953
Схема распределения памяти линейной платы 12000954
Схема распределения памяти Catalyst 8540CSR955
Схема распределения памяти RSP958
Схема распределения памяти RSP4960
Схема распределения памяти процессора RP устройства Cisco 7000960
Схема распределения памяти NPE устройства ряда Cisco 7200961
Схема распределения памяти Cisco 7100970
Схема распределения памяти Cisco 6400-NRP971
Схема распределения памяти Cisco 6400-NSP979
Схема распределения памяти Cisco 6200980
Схема распределения памяти Cisco 6260981
Схема распределения памяти Cisco 4000982
Схема распределения памяти Cisco 4500, 4500-М,4700, 4700-М984
Схема распределения памяти Cisco 3620985
Схема распределения памяти Cisco 3640986
Схема распределения памяти Cisco 3660987
Схема распределения памяти Cisco 2600988
Схема распределения памяти Cisco 2500989
Схема распределения памяти Cisco 1720990
Схема распределения памяти Cisco 1600990
Схема распределения памяти Cisco 1400990
Схема распределения памяти AS5200992
Схема распределения памяти AS5300994
Схема распределения памяти AS5800995
Схема распределения памяти Cisco 1000, 1003/1004/10051001
Схема распределения памяти VIР21002
Приложение В. Информация о технической поддержке1007
Сбор информации об объединенной сети1007
Получение данных с маршрутизатора1009
Доступ к удаленному порту консоли и вспомогательному порту1009
Подключение модема к порту консоли1010
Подключение модема к вспомогательному порту1010
Узел ССО1011
Службы поиска неисправностей узла ССО1012
Подготовка данных для представителя службытехнической поддержки1013
Предметный указатель1014
Предисловие
Область применения компьютерных сетей постоянно расширяется, и поэтому задача поиска и устранения неисправностей в сетях становится все более актуальной. Настоящее Руководство по поиску неисправностей в объединенной сети, выпущенное издательством Cisco Press, является ценным источником информации для специалистов по сетям, работающих во всех отраслях промышленности.
Для подготовки второго издания этой книги был собран коллектив экспертов в области поиска неисправностей, которые полностью пересмотрели материал по каждой группе сетевых технологий и включили в него самые современные и точные рекомендации по поиску и устранению неисправностей. Цель этого коллектива экспертов и самого издательства состояла в создании справочного пособия, позволяющего быстро находить решения проблем, возникающих в процессе функционирования сети. Мы надеемся, что в настоящей книге эта цель достигнута.
Назначение данной книги
Руководство по поиску неисправностей в объединенной сети предназначено для использования в качестве источника информации при решении задач, связанных с устранением нарушений в работе сети. Мы полагаем, что информация, представленная в данной книге, поможет успешно справиться с проблемами, возникающими при использовании конкретных сетевых технологий в существующей сетевой среде.
Благодарности
Второе издание этого уникального руководства — результат совместных усилий коллектива талантливых экспертов в области поиска неисправностей в сети, возглавляемого Джанет Рамей (Janet Ramey), менеджером центра технической поддержки (ТАС — Technical Assistance Center) корпорации Cisco Systems. В подготовке этого издания участвовали следующие нынешние и бывшие специалисты по технической поддержке центра ТАС.
Карим Бенхабедже (Karim Benhabeje) (CCIE #5010).
Джеральд Берджесс (Gerald Burgess) (CCIE #4540).
Расс Эмерсон (Russ Emerson) (CCIE #4206).
Тим Гэйдж (Tim Gage) (CCIE #3492).
Брайен Хатчинс-Ноулз (Brian Hutchins-Knowles) (CCIE #4794).
Уильям M. Ли II (William M. Lee II).
Джеральдина Надела (Geraldine Nadela).
Нилеш Пэникер (Nilesh Panicker).
Йонгся (Энни) Ши (Yongxia (Annie) Shi).
Франсуа Талле (Francois Tallet) (CCIE #3539).
Том Тобиас (Tom Tobias) (CCIE #6257).
Роберт Виджил (Robert Vigil) (CCIE #1905).
Расс Уайт (Russ White) (CCIE #2635).
Роберт Райт (Robert Wright) (CCIE #1050).
Гильберт Йип (Gilbert Yip) (CCIE #5070).
В подготовке данной книги принимали также участие следующие специалисты.
Кевин Берджесс (Kevin Burgess).
Майк Крэйн (Mike Crane).
Стив Дассо (Steve Dussault).
Мэрион Джексон (Marion Jackson).
Джонсон Лю (Johnson Liu).
Уильям Р. Вагнер (William R. Wagner).
Коллектив специалистов, участвующий в подготовке и публикации данной книги в издательстве Cisco Press, поставил перед собой задачу предоставить практически применимую информацию сообществу заказчиков корпорации Cisco и всему сетевому сообществу в целом. Мы надеемся, что представленный здесь материал пригодится читателям в их повседневной работе.
Авторы глубоко признательны многим нынешним и бывшим сотрудникам корпорации Cisco, которые внесли свой вклад в формирование информационного наполнения этой книги. К числу основных участников этой работы принадлежат: Джим Янг (Jim Young), Эмир Хан (Amir Khan), Джон Райт (John Wright), Кэйт Редфилд (Keith Redfield), Вон Ли (Won Lee), Пасворн Бунмарк (Pasvorn Boonmark), Стив Каннингхэм (Steve Cunningham), Нга By (Nga Vu), Имран Куреши (Imran Qureshi), Атиф Хан (Atif Khan), Арун Састри (Arun Sastry), Джон Башински (John Bashinski), Дейв Катц (Dave Katz), Дино Фариначчи (Dino Farinacci), Лэрри Боуден (Larry Bowden), Правин Аккираджу (Praveen Akkiraju), Стив Расселл (Steve Russell), Сринивас Вегесна (Srinivas Vegesna), Фил Ремейкер (Phil Remaker), Присцилла Оппенхеймер (Priscilla Oppenheimer), Брюс Пински (Bruce Pinsky), Джоанна Гарднер (Joanna Gardner), Деннис Пенг (Dennis Peng), Чарли Джастес (Charlie Justus), Моррис Энджи (Morris Ng), Сью Фелан (Sue Phelan), Марк Эйлиен (Mark Alien), Айвен Чан (Ivan Chan), Деннис Винд (Dennis Wind), Раса Элена Лоренцана (Rasa Elena Lorenzana), Серафин Кастильо (Cerafin Castillo), Джон Чонг (John Chong), Джеф Шульц (Jeff Schults), Джек Николс (Jack Nichols) и Дианна Дэнлоп (Dianne Dunlap).
Характер подготовки настоящей книги требовал значительных усилий руководителей по координации работы и уточнению рассматриваемых тем, а также планированию затрат времени экспертов на сбор и оформление материала. Авторы выражают свою благодарность Джо Пайнто (Joe Pinto), Брэду Райту (Brad Wright), Дугу Оллреду (Doug Allred) и Чарльзу Баугу (Charles Baugh), осуществлявшим практическое руководство данным проектом, за то, что они раньше всех поняли важность данного материала для заказчиков и оказывали всестороннюю помощь с самого начала подготовки книги.
Авторами первого издания этой книги были X. Ким Лью (Н. Kim Lew), Спэнк Мэкой (Spank McCoy), Кэтлин Уоллес (Kathleen Wallace), Тим Стивенсон (Tim Stevenson) и Кевин Доунс (Kevin Downes).
Соглашения, принятые в книге
В настоящей книге используются следующие обозначения для выделения определенных частей материала.
Команды и ключевые слова набраны моноширинным шрифтом.
Новые, важные термины выделены курсивом.
Заголовки дополнительных, полезных рекомендаций или справок выделены полужирным шрифтом.
Часть
^ Основные принципы поиска ? неисправностей
^В этой частя...
Глава 1. “Общее описание процесса поиска неисправностей”
Глава 2. “Инструментальные средства поиска неисправностей
Глава
1
i Общее описание процесса поиска неисправностей
За последние десять лет резко возросла потребность в сетевых ресурсах. В современном мире успешная работа любой компании во многом зависит от бесперебойного функционирования применяемой в ней сети, поэтому любое нарушение в работе сети :“ считается недопустимым. В связи с этим задача поиска неисправностей в сети стала одним из самых важных направлений работы на многих предприятиях.
* В последние годы не только возросла зависимость от успешного функционирования сети, но и усложнилась структура самой сетевой среды. В сетях все чаше применяются разные типы передающей среды, многочисленные протоколы, а иногда в процессе работы устанавливаются соединения с сетями неизвестного типа. Такая необхо- ^димость возникает при использовании транзитных сетей, принадлежащих провайдерам служб Internet (ISP — Internet Service Provider) или телекоммуникационным компаниям, которые предоставляют услуги по обеспечению взаимодействия отдельных сетей. Сложность сетей и важность обеспечения их надежной работы возрастают также в связи с тем, что сети передачи данных все чаще применяются для передачи аудио- и видеоинформации.
В связи с общим усложнением сетевой среды возрастает вероятность появления , проблем нарушения связности и снижения производительности в объединенных се®' тях, но при этом первопричины таких проблем часто очень сложно обнаружить.
Признаки неисправностей, проблемы и решения .
.. Нарушения функционирования объединенных сетей характеризуются определен- S*" ными признаками. Такие признаки могут быть общими (например, нельзя получить доступ к конкретным серверам с клиентских компьютеров) или более определенными (например, отсутствие информации о маршрутах в таблице маршрутизации). Анализ каждого признака неисправности, проводимый с помощью специальных инструментальных средств и методов поиска неисправностей, может выявить одну или несколь- ч1. ко причин или проблем. А каждую причину неисправности после ее распознавания !' , можно устранить путем реализации решения, состоящего из ряда действий.
к’
В настоящей книге описано, как определять признаки неисправностей, выявлять проблемы и реализовывать решения в любой сетевой среде. В процессе поиска неисправностей в конкретной среде следует всегда учитывать условия, в которых осуществляется поиск неисправностей, что позволяет правильно определять признаки и диагностировать причины нарушения в работе.
Общая модель решения проблемы поиска неисправностей
В процессе поиска неисправностей в сетевой среде должен применяться систематический подход. Если поиск неисправностей ведется бессистемно, то могут непродуктивно затрачиваться ценные временные и материальные ресурсы, а иногда при этом положение даже ухудшается. В процессе устранения нарушений в работе сети необходимо определить конкретные признаки неисправности, выявить все потенциальные проблемы, которыми могут быть вызваны эти признаки, а затем систематически устранять все возможные причины проблем (от наиболее вероятных до наименее вероятных) до тех пор, пока все признаки неисправности не исчезнут.
На рис. 1.1 показана блок-схема обшей модели решения проблемы поиска неисправностей. Эта блок-схема не является жесткой схемой поиска неисправностей в объединенной сети, а может служить лишь основой, на которой формируется конкретный процесс устранения нарушений в работе, соответствующий конкретной сетевой среде.
Рис. 1.1. Общая модель решения проблемы поиска неисправностей
Ниже описаны конкретные этапы процесса поиска неисправностей, общая блок- схема которого приведена на рис. 1.1.
Шаг 1. При анализе нарушения работы в сети четко сформулируйте проблему. Проблема должна быть определена как набор наблюдаемых признаков неисправностей и возможных причин.
В процессе анализа проблемы необходимо определить общие признаки неисправности, а затем установить, какими причинами могли быть вызваны эти признаки. Например, предположим, что хост не отвечает на запросы к службам, поступающие от клиентов (признак неисправности). Возможными причинами этого может быть неправильная настройка конфигурации хоста, неисправные интерфейсные платы или отсутствие необходимых команд в конфигурации маршрутизатора.
Шаг 2. Соберите факты, которые позволят более точно установить возможные причины.
Необходимо провести опрос всех заинтересованных пользователей, сетевых администраторов, руководителей и других специалистов, а также собрать информацию из таких источников, как системы управления сетью, трассировки анализаторов протокола, ознакомиться с результатами выполнения команд диагностики маршрутизатора или прочитать документацию к применяемой версии программного обеспечения.
Шаг 3. Изучите возможные проблемы с учетом собранных фактов. Накопленная вами информация позволит исключить некоторые потенциальные проблемы из списка подозреваемых.
Например, полученные данные могут свидетельствовать о том, что аппаратное обеспечение работает нормально. Это позволит сосредоточиться на нарушениях в работе программного обеспечения. При любой возможности нужно стремиться сузить круг потенциальных проблем, чтобы можно было разработать эффективный план действий.
Шаг 4. Подготовьте план действий, охватывающий все оставшиеся потенциальные проблемы. Начните с наиболее вероятной неисправности и разработайте план, который предусматривает устранение только одной конкретной причины.
Если план действий направлен на устранение только одной причины, он позволит найти искомое решение конкретной проблемы. Пытаясь одновременно устранить сразу несколько причин, также можно решить проблему, но при этом сложно определить, какое именно действие привело к устранению признаков неисправности, поэтому при повторном возникновении такой же проблемы в будущем поиск решения придется начать с самого начала.
Шаг 5. Осуществите план действий, тщательно выполняя каждый этап и проверяя, удалось ли устранить признаки неисправности.
Шаг 6. После внесения каждого изменения обязательно проконтролируйте результаты. Как правило, для этого должен применяться тот же метод сбора данных, как и на шаге 2 (в частности, при этом снова привлекайте к такой работе заинтересованных специалистов и используйте диагностические инструментальные средства).
Шаг 7. Проанализируйте полученные результаты, чтобы определить, решена ли проблема. В случае положительного ответа процесс поиска неисправности заканчивается.
Шаг 8. Если проблема не решена, разработайте план действий по устранению следующей менее вероятной проблемы из списка. Возвратитесь к шагу 4, снова вносите по одному изменению и повторяйте процесс до тех пор, пока проблема не будет решена.
Примечание
Если исследованы все обычные причины и проведены все возможные действия (описанные в данной книге или определенные в конкретной сетевой среде), но неисправность не удалось устранить, следует обратиться к представителю службы технической поддержки корпорации Cisco.
Подготовка к возникновению сетевых отказов
Возобновление нормальной работы после сетевого отказа всегда проходит легче, если заранее проведена определенная подготовка. Для этого в любой сетевой среде должно соблюдаться определенное требование, которое можно считать наиболее важным: наличие своевременной и точной информации о сети, к которой может в любое время обратиться обслуживающий персонал сети. Только при наличии полной информации можно принять обоснованное решение о том, какие изменения должны быть сделаны в сети для возобновления ее работы, и только с помощью такой информации можно максимально быстро и легко провести поиск неисправностей.
В процессе поиска неисправностей в сети следует ожидать, что функционирование сети будет нарушено. Поэтому рекомендуется обязательно выделять определенный интервал времени на поиск возможных неисправностей, чтобы свести к минимуму нарушение нормальной производственной деятельности. Следует всегда документировать все внесенные изменения. Это позволяет легко вернуться к прежней конфигурации, если поиск неисправности не привел к выявлению проблемы в течение времени, отведенного на техническое обслуживание.
Чтобы определить степень готовности к устранению сетевого отказа, ответьте на следующие вопросы контрольного списка.
Есть ли точные физические и логические схемы объединенной сети?
На предприятии или в подразделении необходимо иметь схемы, которые полностью отражают современное состояние объединенной сети. На физической схеме должно быть показано местонахождение всех устройств в сети и обозначены связи между ними, а на логической схеме должны быть указаны сетевые адреса, номера сетей, подсетей и т.д.
Имеется ли список всех сетевых протоколов, реализованных в сети?
Для каждого из реализованных протоколов необходимо иметь список номеров сетей, подсетей, зон, областей, а также всю прочую информацию, касающуюся протоколов.
Имеются ли данные о том, для каких протоколов предусмотрена маршрутизация трафика?
Для каждого из маршрутизируемых протоколов должна быть собрана точная и актуальная информация о конфигурации маршрутизатора.
Известно ли, трафик каких протоколов передается с помощью мостов?
Если конфигурация каких-либо мостов предусматривает применение фильтров, то необходимо иметь копию этой информации о конфигурации.
Известны ли все точки контакта с внешними сетями, включая все соединения с Internet?
Для каждого внешнего сетевого соединения необходимо иметь информацию о применяемом протоколе маршрутизации.
Накоплены ли эталонные данные о работе сети в основных режимах?
На предприятии должны быть накоплены данные о характеристиках и производительности сети в нормальных условиях в разное время суток. Это позволяет определить, какие характеристики изменились в результате возникновения неисправности.
Если специалисты по сетям конкретного предприятия дадут положительный ответ на все эти вопросы, они смогут устранить любую неисправность быстрее и легче, чем при отсутствии соответствующей подготовки. И, наконец, после устранения любой неисправности следует обязательно документировать обнаруженные проблемы и принятые решения. Это позволяет создать базу данных проблем и решений, которой смогут воспользоваться все сотрудники предприятия при возникновении в дальнейшем подобных проблем. Такие мероприятия, безусловно, позволят сократить время на устранение неисправностей в сети и поэтому свести к минимуму их воздействие на деятельность предприятия.
Глава
| Инструментальные средства
* поиска неисправностей
, В настоящей главе представлена информация о разнообразных инструментальных средствах, которые позволяют упростить поиск неисправностей в объединенной сети. В частности, здесь приведена информация об использовании диагностических команд I маршрутизатора, инструментальных средств управления сетью корпорации Cisco и инструментальных средств поиска неисправностей других поставщиков.
Применение диагностических команд маршрутизатора
‘В маршрутизаторах Cisco предусмотрено множество встроенных команд, позволяющих контролировать работу и выполнять поиск неисправностей в объединенной сети. В следующих разделах описаны основные области применения этих команд.
". Команды show позволяют контролировать работу оборудования и определять ха/ рактеристики сети, а также выявлять проблемные области.
Команды debug позволяют диагностировать проблемы, возникающие из-за не- р •*' правильной настройки конфигурации протоколов и оборудования.
; Команды ping позволяют проверить возможность взаимодействия устройств в сети.
Команды trace дают возможность определить маршрут, по которому проходят . пакеты от одного устройства к другому на пути к месту назначения.
Применение команд show
р1'Команды show представляют собой мощное инструментальное средство текущего
контроля и поиска неисправностей. Команды show могут применяться для выполне- нйя следующих функций:
текущий контроль характеристик маршрутизатора в процессе инсталляции;
текущий контроль нормального функционирования сети;
1'!'• выявление интерфейсов, узлов, компонентов передающей среды или приложе
ний, которые являются причиной неисправности;
определение наличия заторов в сети;
определение состояния смежных серверов, клиентов или других смежных устройств.
Ниже перечислены некоторые наиболее широко применяемые команды show.
show version. Показывает конфигурацию аппаратных средств системы, версию программного обеспечения, имена файлов конфигурации, а также загрузочные образы.
show running-config. Отображает применяемую в настоящий момент конфигурацию маршрутизатора.
show startup-config. Показывает конфигурацию маршрутизатора, которая хра-' нится в энергонезависимом ОЗУ (оперативное запоминающее устройство).
show interfaces. Выводит статистические данные по всем интерфейсам, которые входят в конфигурацию маршрутизатора или сервера доступа. Отображаемые данные зависят от типа сети, для использования в которой настроен конкретный интерфейс.
show controllers. Показывает статистические данные о контроллерах интерфейсных плат.
show flash. Отображает компоновку и содержимое флэш-памяти.
show buffers. Выводит статистические данные о буферных пулах маршрутизатора.
show memory summary. Выводит статистические данные о пулах оперативной памяти и итоговую информацию о действиях программы распределения системной памяти, а также предоставляет отчет об использовании каждого блока памяти.
show process cpu. Показывает информацию об активных процессах в маршрутизаторе.
show stacks. Выводит информацию об использовании стека процессами и процедурами прерывания, а также показывает причину последней перезагрузки системы.
show cdp neighbors. Предоставляет определенную информацию о возможности доступа к непосредственно подключенным (соседним, или смежным) устройствам Cisco. Эта команда — исключительно полезное инструментальное средство, позволяющее определить состояние функционирования физического уровня и уровня передачи данных. CDP (Cisco Discovery Protocol — протокол обнаружения устройств компании Cisco) представляет собой собственный протокол уровня передачи данных.
show debugging. Выводит информацию о том, какой режим отладки разрешен для данного маршрутизатора.
Для получения списка подкоманд любых команд всегда можно ввести вопросительный знак (?) в командной строке.
Как и команды debug, некоторые команды show, перечисленные выше, доступны только в привилегированном режиме выполнения exec-команд маршрутизатора (в режиме enable). Дополнительные сведения об этом режиме приведены ниже, в разделе “Применение команд debug”.
Кроме перечисленных, имеются также сотни других команд show. Дополнительные сведения об использовании и интерпретации вывода конкретных команд show приве-
дены в справочниках по командам IOS (Internetwork Operating System — операционная система для объединенных сетей) корпорации Cisco.
Применение команд debug
Привилегированные exec-команды debug позволяют получить значительный объем информации о том, какой трафик наблюдается (или не наблюдается) в определенном интерфейсе, перехватить сообщения об ошибках, вырабатываемых узлами сети, сформировать диагностические пакеты, относящиеся к конкретному протоколу, а также ознакомиться с другими данными, необходимыми для поиска неисправностей. Чтобы получить доступ к перечню привилегированных exec-команд и ознакомиться с ним, введите следующий код:
Router> enable
Password: ХХХХХХ
Router# ?
Обратите внимание на то, как изменяется приглашение к вводу информации в маршрутизаторе. Приглашение со знаком фунта “#” (вместо обычного приглашения со знаком больше “>”) указывает, что теперь работа выполняется в режиме привилегированных exec-команд (в режиме enable).
Предостережение
Соблюдайте осторожность при использовании команд debug. Многие команды debug требуют больших затрат процессорного времени и могут вызвать серьезные нарушения в работе сети (такие как снижение производительности или нарушение связи) при их применении в маршрутизаторе, который уже испытывает значительную нагрузку. По завершении использования любой команды debug обязательно отмените ее с помощью соответствующей команды no debug (или введите команду по debug all, чтобы отменить действие всех команд отладки).
Команды debug должны применяться только для поиска причин неисправностей, а не для контроля над нормальным функционированием сети. Команды debug требуют больших затрат процессорного времени, поэтому должны применяться исключительно при анализе трафика определенного типа или при устранении неисправностей, если они позволят сузить круг поиска возможных причин неисправностей.
Формат вывода результатов зависит от конкретной команды debug. Некоторые команды вырабатывают по одной строке вывода для каждого пакета, а другие при обработке каждого пакета вырабатывают несколько строк вывода. Одни команды генерируют большой объем выходной информации, а другие выводят данные лишь время от времени. Одни команды выдают текст построчно, а другие формируют отчеты с данными, представленными в отдельных полях.
Чтобы свести к минимуму негативное влияние, связанное с использованием команд debug, соблюдайте следующие рекомендации.
Шаг 1. Используйте в маршрутизаторе глобальную команду конфигурации no logging console, которая отменяет весь вывод журнала на терминал консоли.
Шаг 2. Подключитесь по протоколу Telnet к порту маршрутизатора и введите ехес- команду enable, которая переводит маршрутизатор в режим привилегирован-
ных exec-команд. После ввода пароля enable, обеспечивающего доступ, вы получите приглашение к вводу информации, которое состоит из имени маршрутизатора и знака фунта (#).
Шаг 3. Используйте команду terminal monitor для копирования вывода команды debug и сообщений системы об ошибках на дисплей своего текущего терминала.
Перенаправив вывод на дисплей своего текущего терминала, вы сможете дистанционно просматривать вывод команды debug, не подключаясь через порт консоли.
Если команды debug выполняются через порт консоли, то при передаче каждого символа активизируется прерывание процессора, поэтому и без того значительная нагрузка процессора, вызванная использованием команды debug, возрастает до предела.
Если вывод команды debug необходимо сохранить для справок, выведите его в файл. Процедура подготовки такого файла вывода debug описана в справочнике по командам отладки Debug Command Reference.
В настоящей книге упоминаются только конкретные команды debug, необходимые для устранения определенных нарушений в работе сети. Подробные сведения о назначении и результатах применения команд debug приведены в документе Debug Command Reference.
Во многих ситуациях более полезными и менее требовательными к ресурсам по сравнению с командами debug могут оказаться диагностические инструментальные средства, предоставляемые независимыми поставщиками. Дополнительная информация о них приведена ниже, в разделе “Инструментальные средства поиска неисправностей, предоставляемые независимыми поставщиками”.
Применение команд ping
Команда ping, которая может быть вызвана на выполнение в режиме непривилегированных и привилегированных exec-команд, применяется для проверки доступности хоста и связи по сети. После регистрации на маршрутизаторе или сервере доступа автоматически устанавливается режим непривилегированных exec-команд. Доступные на непривилегированном уровне exec-команды являются подмножеством exec-команд, применяемых на привилегированном уровне. Как правило, непривилегированные exec-команды позволяют подключаться к удаленным устройствам, изменять на время установки терминала, выполнять простейшие проверки и выводить на экран информацию о системе. Команда ping позволяет выполнять простые проверки наличия связи в сетях AppleTalk, CLNS (Connectionless Network Service — сетевое обслуживание без установления соединения) по стандарту ISO, IP, Novell, Apollo, VINES, DECnet или XNS.
В сетях IP при выполнении команды ping происходит отправка запросных сообщений эхо-тестирования ICMP (Internet Control Messages Protocol — протокол управляющих сообщений Internet) . ICMP — это протокол Internet, с помощью которого передаются сообщения об ошибках и предоставляется информация, касающаяся адресации IP-пакетов. При получении запросного сообщения эхо-тестирования ICMP станция передает отправителю этого сообщения ответное сообщение эхо-тестирования ICMP.
Расширенный командный режим команды ping позволяет указать поддерживаемые опции заголовка IP-пакета. При этом в маршрутизаторе может быть выполнен ряд проверок, предусматривающих более широкий набор функций. Для перехода в рас-
ширенный командный режим ping введите yes в ответ на приглашение extended commands команды ping.
Рекомендуем воспользоваться командой ping при нормальном функционировании сети, чтобы узнать, как работает эта команда в обычных условиях, и сравнить полученные при этом результаты с результатами, характерными для нарушений в работе.
Дополнительная информация об использовании обычных и расширенных команд ping приведена в справочнике по основным командам конфигурации операционной системы Cisco IOS Configuration Fundamentals Command Reference.
Применение команд trace
Непривилегированная ехес-команда trace позволяет определить, по каким маршрутам следуют пакеты определенного маршрутизатора на пути к месту назначения. Привилегированная ехес-команда trace дает возможность указать поддерживаемые опции заголовков IP-пакетов, в результате чего в маршрутизаторе может быть применен более широкий набор опций проверки.
В команде trace используются сообщения об ошибках, вырабатываемые маршрутизаторами при достижении дейтаграммой минимального значения срока жизни (TTL — Time- To-Live). Вначале рассылаются пакеты запросов (специальные дейтаграммы) со значением TTL, равным 1. В результате первый маршрутизатор отбрасывает запросы и возвращает сообщения об ошибках "time exceeded", которые указывают, что срок жизни пакета истек. На следующем этапе выполнения команды trace передается еще несколько запросов и для каждого из них отображается время кругового обращения. После отправки каждого третьего запроса значение TTL увеличивается на 1.
Отправка каждого исходящего пакета может привести к получению одного из двух сообщений об ошибках. Сообщение об ошибке "time exceeded" указывает, что промежуточный маршрутизатор получил и отбросил запрос, поскольку истек срок жизни пакета. Сообщение об ошибке "port unreachable" указывает, что узел назначения получил и отбросил пакет, поскольку не мог доставить его приложению. А если установка таймера истекла до того, как поступил ответ, команда trace выводит символ звездочки (*).
Выполнение команды trace заканчивается после получения ответа от хоста назначения, при превышении максимального значения TTL или при вводе пользователем управляющей последовательности, которая прерывает трассировку.
Как и при использовании команды ping, рекомендуем выполнить команду trace при нормальном функционировании сети, чтобы узнать, как работает эта команда в обычных условиях, и сравнить полученные при этом результаты с результатами, характерными для нарушений в работе.
Дополнительная информация об использовании простых и расширенных команд trace приведена в справочнике по основным командам конфигурации операционной системы Cisco IOS Configuration Fundamentals Command Reference.
Инструментальные средства управления сетью, предоставляемые корпорацией Cisco
Корпорация Cisco поставляет семейство программных продуктов управления сетью CiscoWorks 2000, в состав которого входят инструментальные средства проектирова-
ния, текущего контроля и поиска неисправностей, позволяющие упростить управление объединенной сетью.
При поиске неисправностей в объединенной сети могут применяться следующие инструментальные средства управления объединенной сетью.
Программа CiscoView выполняет функции динамического текущего контроля и поиска неисправностей, в частности, позволяет получить графическую схему соединений устройств Cisco, статистические данные и исчерпывающую информацию о конфигурации.
Монитор производительности объединенной сети (IPM — Internetwork Performance Monitor) позволяет сетевым инженерам заблаговременно определять отклонения характеристик сетевого отклика от нормы с использованием отчетов, полученных в настоящее время и в прошлом.
Инструментальное средство дистанционного текущего контроля (RMON — Remote MONitoring) TrafficDirector дает возможность накапливать данные, контролировать действия, происходящие в сети, и диагностировать потенциальные проблемы.
Приложение управления коммутатором VlanDirector представляет собой инструментальное средство управления, которое позволяет получить полное представление о состоянии виртуальных локальных сетей.
Программа CiscoView
Графические средства управления программы CiscoView позволяют получить в оперативном режиме сведения о состоянии, статистические данные и исчерпывающую информацию о конфигурации продуктов корпорации Cisco для объединенных сетей (коммутаторов, маршрутизаторов, концентраторов и серверов доступа). Программа CiscoView дает возможность упростить управление сетью, поскольку схематически отображает информацию о состоянии устройств Cisco, в частности, предоставляет схему портов устройства с цветовой кодировкой, позволяющую быстро получить сведения о состоянии портов и охватить одним взглядом всю необходимую информацию. Ниже описаны основные возможности программы.
Просмотр на графическом экране из центрального пункта информации о продуктах Cisco; это средство позволяет сетевым администраторам получить полное представление о работе устройств Cisco без физической проверки каждого устройства на удаленных узлах.
Непрерывно обновляемая схема с информацией о маршрутизаторах, концентраторах, коммутаторах или серверах доступа в сети, полнота которой не зависит от их физического расположения.
Постоянное обновление данных текущего контроля в реальном времени и отслеживание основной информации и данных, характеризующих производительность устройств, объем трафика и степень загрузки. Эти данные содержат такие ключевые характеристики, как процент использования, число переданных и полученных фреймов, относительное количество ошибок, а также целый ряд других показателей, касающихся каждого конкретного устройства.
Возможность изменять такие опции конфигурации, как прерывания, IP-маршруты, параметры настройки виртуальных локальных сетей и мостов.
Монитор производительности объединенной сети
Приложение управления сетью IPM (Internetwork Performance Monitor — монитор производительности объединенной сети) обеспечивает текущий контроль над производительностью мультипротокольных сетей. Приложение IPM позволяет измерять время отклика и определять характеристики доступа сетей IP на каждом транзитном переходе (от одного маршрутизатора к другому). Это приложение позволяет также измерять время отклика на участках между маршрутизаторами и мэйнфреймом в сетях SNA (Systems Network Architecture — системная сетевая структура) .
Приложение IPM применяется для выполнения следующих задач.
Поиск неисправностей в сети путем проверки сетевой задержки на участках между устройствами.
Передача прерываний SNMP (Simple Network Management Protocol — простой протокол управления сетью) и предупреждающих сообщений SNA при превышении порогового значения, установленного пользователем, при разрыве и восстановлении соединения или при возникновении тайм-аута.
Анализ данных о потенциальных проблемах еше до их возникновения путем накопления статистических данных, которые могут использоваться для моделирования и прогнозирования характеристик будущих сетевых топологий.
Текущий контроль времени отклика на участке между двумя оконечными точками.
Программный продукт IPM состоит из трех частей: серверного и клиентского приложения IPM, а также модуля генератора отчетов о времени отклика (RTR — Response Time Reporter), который входит в состав программного обеспечения Cisco IOS.
Приложение RMON TrafficDirector
Усовершенствованные фильтры пакетов приложения TrafficDirector дают возможность пользователям контролировать сетевой трафик на всех семи уровнях протоколов. С использованием встроенных агентов RMON операционной системы Cisco IOS и средств формирования автономных запросов SwitchProbe сетевые администраторы могут просматривать сетевой трафик в масштабах всего предприятия на канальном, сетевом, транспортном или прикладном уровнях. Итоговый отчет о многоуровневом трафике приложения TrafficDirector позволяет быстро получить общую оценку степени загрузки сети и определить относительный объем трафика различных протоколов. Затем сетевые администраторы могут перейти к подробному изучению конкретного сегмента, кольца, порта коммутатора или магистрального канала и применить инструментальные средства анализа и диагностики в реальном времени для просмотра информации о хостах и конкретных сеансах обмена данными, а также для перехвата пакетов.
Средства текущего контроля пороговых значений приложения TrafficDirector позволяют создать среду управления, которая обеспечивает заблаговременное устранение возможных неисправностей. Для этого прежде всего в агенте RMON устанавливаются пороговые значения важных переменных MIB (Management Information Base — информационная база управления). При превышении этих пороговых значений на соответствующую станцию управления передаются прерывания, позволяющие предупредить сетевого администратора о потенциальной проблеме.
Приложение управления коммутатором VlanDirector
Приложение управления коммутатором VlanDirector позволяет упростить распределение портов виртуальной локальной сети и обеспечивает управление виртуальными локальными сетями. Приложение VlanDirector выполняет следующие функции.
Точное отображение физической сети, позволяющее разработать проект виртуальной локальной сети и выполнить проверку конфигурации.
Сбор информации о конфигурации виртуальной локальной сети, которая относится к конкретному устройству или канальному интерфейсу.
Формирование отчетов о несоответствиях при наличии противоречивой информации о конфигурации.
Поиск неисправностей и выявление отдельных конфигураций устройств, которые не соответствуют характеристикам виртуальных локальных сетей на уровне всей системы.
Своевременное обнаружение изменений в состоянии портов коммутаторов виртуальной локальной сети.
Проверка подлинности пользователей и защита данных.
Инструментальные средства поиска неисправностей, предоставляемые независимыми поставщиками
Диагностические инструментальные средства независимых поставщиков часто могут оказаться более полезными по сравнению с командами, встроенными в маршрутизатор. Например, применение команды debug, требующей большого объема процессорного времени, в сетевой среде с исключительно интенсивным трафиком может привести к разрушительным последствиям. Но подключение сетевого анализатора к исследуемой сети практически не нарушает ее работу и позволяет с большей вероятностью получить необходимую информацию, не препятствуя нормальному функционированию маршрутизатора. Ниже перечислены некоторые типичные инструментальные средства поиска неисправностей, предоставляемые независимыми поставщиками, которые применяются для устранения нарушений в работе объединенных сетей.
Для проверки физических характеристик кабельной сети применяются вольт- омметры, цифровые мультиметры и кабельные тестеры.
Поиск обрывов в кабелях, рассогласований импедансов и других технических неисправностей кабельной сети осуществляется с использованием динамических рефлектометров и оптических динамических рефлектометров.
Для поиска неисправностей периферийных интерфейсов применяются коммутационные боксы, генераторы тестовых последовательностей и тестеры частоты ошибочных битов/частоты ошибочных блоков.
Сетевые мониторы позволяют получить полное представление о функционировании сети на протяжении определенного периода времени путем непрерывного отслеживания пакетов, проходящих по сети.
Такие сетевые анализаторы, как перехватчики сетевых пакетов, автоматически декодируют информацию, передаваемую на всех семи уровнях эталонной модели OSI, и способствуют выявлению нарушений в работе в реальном масштабе времени, позволяя получить полное представление о функционировании сети и классифицируя проблемы по степени важности.
Вольтомметры, цифровые мультиметры и кабельные тестеры
Вольтомметры и цифровые мультиметры относятся к числу наиболее простых инструментальных средств, предназначенных для измерения физических характеристик кабельной сети. Эти устройства измеряют такие параметры, как напряжение переменного и постоянного тока, силу тока, сопротивление и емкость, а также позволяют определить наличие обрывов в кабеле. Они применяются для проверки физического состояния сети.
Кабельные тестеры (сканеры) также позволяют проверить физическое состояние сети. Для проверки экранированной витой пары (STP), неэкранированной витой пары (UTP), кабелей lOBaseT, одинарных и двойных коаксиальных кабелей применяются кабельные тестеры соответствующего типа. Как правило, кабельные тестеры обеспечивают выполнение следующих функций.
Проверка состояния кабеля и предоставление отчета, в том числе с результатами измерения перекрестной наводки на ближнем конце, затухания и шума.
Выполнение функций динамического рефлектометра, текущий контроль трафика и подготовка схемы кабельной системы.
Предоставление информации уровня MAC (Media Access Control — управление доступом к передающей среде) о трафике в локальной сети, накопление статистических данных, которые необходимы для расчета таких показателей, как коэффициент использования сети и частота ошибочных пакетов, а также выполнение некоторых функций проверки работы протокола (например, такой проверки связи по протоколу TCP/IP, как эхо-тестирование).
Аналогичное испытательное оборудование предусмотрено и для волоконно-оптических кабелей. В связи с относительно высокой стоимостью и самого кабеля, и его монтажа, волоконно-оптический кабель должен проверяться перед монтажом (на кабельном барабане) и после монтажа. Для проверки стекловолокна на обрыв требуется источник видимого света или рефлектометр. Источники света, способные излучать свет с тремя основными значениями длины волны, 850, 1300 и 1550 нанометров (нм), применяются в сочетании с измерителями мощности, позволяющими проводить измерения на той же длине волны, проверять затухание и потери на отражение в стекловолокне.
Динамические рефлектометры и оптические динамические рефлектометры
К числу наиболее сложных приборов, применяемых для проверки характеристик медного кабеля, относятся динамические рефлектометры. Эти устройства позволяют быстро находить обрывы и короткозамкнутые цепи, скрутки, петли, острые изгибы, рассогласования импедансов и другие дефекты монтажа кабелей.
Динамический рефлектометр действует по принципу приема сигнала, отраженного от противоположного конца кабеля. При наличии обрывов, короткозамкнутых цепей
и других дефектов амплитуда отраженного сигнала изменяется по-разному, в зависимости от дефекта. Динамический рефлектометр измеряет время, по истечении которого поступает отраженный сигнал, и вычисляет расстояние до дефекта в кабеле. Динамические рефлектометры могут также применяться для измерения длины кабеля. Некоторые динамические рефлектометры позволяют вычислить скорость распространения сигнала путем измерения характеристик эталонного участка кабеля.
Для измерения характеристик волоконно-оптических кабелей применяются оптические динамические рефлектометры, которые позволяют точно измерить длину стекловолокна, найти обрывы в кабеле, определить затухание сигнала в стекловолокне, а также измерить величину потерь в стыке (месте сращивания волокна) или разъеме. Оптический динамический рефлектометр может применяться для подготовки протокола испытания смонтированной кабельной системы, в котором отмечены значения затухания и указаны потери в каждом стыке. Эти эталонные результаты измерений могут затем сравниваться с результатами текущей проверки кабельной системы для обнаружения неисправностей.
Коммутационные боксы, генераторы тестовых последовательностей и тестеры частоты ошибочных битов/частоты ошибочных блоков
Коммутационные боксы, генераторы тестовых последовательностей и тестеры частоты ошибочных битов/частоты ошибочных блоков представляют собой инструментальные средства проверки с цифровым интерфейсом, которые часто применяются для измерения цифровых сигналов в интерфейсах периферийного оборудования персональных компьютеров, принтеров, модемов, модулей обслуживания канала/модулей обработки данных (CSU/DSU) и других аппаратных средств. Эти устройства позволяют контролировать характеристики каналов передачи данных, анализировать и перехватывать передаваемые данные, а также диагностировать неисправности, которые часто возникают в системах передачи данных. С их помощью можно исследовать трафик, передаваемый от терминального оборудования (DTE — Data Terminal Equipment) через терминальное оборудование канала передачи данных (DCE — Data Circuitterminating Equipment) для ускорения поиска неисправностей, выявления типичных последовательностей двоичных сигналов и проверки правильности монтажа кабельных соединений. Эти устройства не могут применяться для проверки сигналов в такой сетевой среде, как Ethernet, Token Ring или FDDI.
Сетевые мониторы
Сетевые мониторы непрерывно отслеживают пакеты, проходящие по сети, и позволяют получить точное представление о функционировании сетей в любой момент времени или сформировать хронологический отчет об активности сети за определенный период времени. Мониторы не декодируют содержимое фреймов. Они могут применяться для накопления эталонных данных. При этом в течение определенного времени фиксируются данные о характеристиках работы сети для формирования так называемого эталонного профиля производительности, т.е. данных о работе сети при нормальных условиях.
Сетевые мониторы собирают информацию о размерах и количестве пакетов, включая ошибочные. Они позволяют определить общие показатели использования соединения,
выяснить количество хостов и их МАС-адреса, а также получить подробные сведения о сеансах обмена данными между хостами и другими устройствами. Эти данные могут использоваться для создания профилей трафика локальной сети, а также для обнаружения участков с чрезмерным объемом трафика, планирования расширения сети, обнаружения нарушителей правил защиты сети, накопления эталонных данных о производительности, а также для более эффективного распределения трафика.
Сетевые анализаторы
Сетевые анализаторы (называемые также анализаторами протокола) декодируют информацию о разных уровнях протокола в зарегистрированных фреймах и представляют накопленную информацию в виде удобных для чтения кратких отчетов или сводок, по которым можно определить, на каких уровнях осуществлялась обработка данных (физическом, канальном и т.д.) и какие функции выполняет каждый байт заголовка или информационного наполнения.
Большинство сетевых анализаторов в основном выполняет следующие функции:
отбирают трафик, который соответствует определенным критериям; это позволяет, например, перехватывать все фреймы, входящие или исходящие из конкретного устройства;
регистрируют время перехвата данных;
представляют информацию об уровнях протокола в форме, удобной для чтения;
генерируют фреймы и выводят их в сеть;
предоставляют возможность воспользоваться “экспертной” системой, в которой применяется набор правил в сочетании с информацией о конфигурации и функционировании сети для диагностики и устранения нарушений в работе сети или для выработки рекомендаций по улучшению ее работы.
Часть
j Устранение нарушений ■ в работе аппаратных средств, средств загрузки и передающей среды
к В этой части...
g^ • Глава 3. “Устранение нарушений в работе аппаратных средств и средств 'загрузки”'^
Глава 4. “Устранение нарушений в работе сети Ethernet”
Глава 5. “Устранение нарушений в работе сети FDD!”
Глава 6. “Устранение нарушений в работе сети Token Ring”
Глава
3
Устранение нарушений в работе аппаратных средств и средств загрузки
i; В настоящей главе описаны процедуры поиска неисправностей аппаратных средств и устранения нарушений загрузки. Здесь представлены конкретные процедуры, относящиеся к определенным продуктам Cisco, но изложенные рекомендации всегда следует применять в соответствии с документацией по установке и техническому обслуживанию аппаратных средств, обращаясь к ней для получения более подробной информации о версии для конкретной платформы, назначении тех или иных
„ светодиодов, а также сведений о настройке конфигурации и поиске неисправностей.
Глава начинается со следующих разделов, в которых описаны возможные нарушения в работе аппаратных средств.
Запуск маршрутизаторов ряда Cisco 7500. Описаны аппаратные средства и процедуры диагностики нарушений процесса загрузки маршрутизаторов ряда Cisco 7500.
Запуск маршрутизаторов ряда Cisco 7000. Описаны аппаратные средства и процедуры . диагностики нарушений процесса загрузки маршрутизаторов ряда Cisco 7000.
>• Запуск маршрутизаторов ряда Cisco 4000. Описаны аппаратные средства и процедуры
диагностики нарушений процесса загрузки маршрутизаторов ряда Cisco 4000.
Запуск маршрутизаторов ряда Cisco 2500. Описаны аппаратные средства и процедуры диагностики нарушений процесса загрузки маршрутизаторов ряда Cisco 2500.
Запуск коммутаторов ряда Catalyst 5000. Описаны аппаратные средства и процедуры диагностики нарушений процесса загрузки LAN-коммутаторов ряда Catalyst 5000.
₽• Запуск коммутаторов ряда Catalyst 2900. Описаны аппаратные средства и процедуры
диагностики нарушений процесса загрузки LAN-коммутаторов ряда Catalyst 2900.
ь • Проверка и аттестация сменного оборудования. Описаны действия, которые ре- << комендуется осуществлять при замене аппаратных средств маршрутизатора.
$ • Запуск коммутаторов ряда Catalyst 6000. Описаны аппаратные средства и процедуры
диагностики нарушений процесса загрузки LAN-коммутаторов ряда Catalyst 6000.
Запуск маршрутизаторов ряда Cisco 2600. Описаны аппаратные средства и процедуры диагностики нарушений процесса загрузки маршрутизаторов ряда Cisco 2600.
Запуск маршрутизаторов ряда Cisco 3600. Описаны аппаратные средства и процедуры диагностики нарушений процесса загрузки маршрутизаторов ряда Cisco 3600.
Запуск коммутаторов ряда Catalyst 4000. Описаны аппаратные средства и процедуры диагностики нарушений процесса загрузки LAN-коммутаторов ряда Catalyst 4000.
В последних разделах описаны признаки неисправностей, проблемы и решения, касающиеся нарушений загрузки из флэш-памяти, загрузки по сети с помошью протокола ТЕТР, загрузки из ПЗУ, а также других нарушений начальной загрузки.
Начальная загрузка: маршрутизатор не может загрузиться из флэш-памяти.
Начальная загрузка: при загрузке из флэш-памяти возникает векторная ошибка.
Начальная загрузка: маршрутизатор частично загружается из флэш-памяти и отображает приглашение процедуры начальной загрузки.
Начальная загрузка: маршрутизатор не может загрузиться по сети от ТЕТР-сервера.
Начальная загрузка: маршрутизатор не может загрузиться по сети от другого маршрутизатора.
Начальная загрузка: тайм-ауты и пакеты с нарушением порядка следования препятствуют выполнению загрузки по сети.
Начальная загрузка: недействительные маршруты препятствуют выполнению загрузки по сети.
Начальная загрузка: клиентские запросы ARP завершаются по тайм-ауту во время загрузки по сети.
Начальная загрузка: во время загрузки по сети возникает ошибка “неопределенный загрузочный модуль”.
Начальная загрузка: маршрутизатор зависает после инициализации режима ROMmon.
Начальная загрузка: маршрутизатор не выходит из режима ROMmon.
Начальная загрузка: искаженный вывод при загрузке из ПЗУ.
Начальная загрузка: возникновение локальных тайм-аутов при загрузке из ПЗУ.
Начальная загрузка: не функционирующее терминальное соединение с ненастроенным сервером доступа.
Загрузка маршрутизатора
Для инициализации системы (начальной загрузки) маршрутизаторов Cisco предусмотрено четыре способа.
Начальная загрузка по сети. Маршрутизаторы можно загружать с сервера с помощью протокола ТЕТР (Trivial File Transfer Protocol — простейший протокол передачи файлов), протокола MOP (Maintenance Operation Protocol — протокол обслуживания) корпорации DEC или протокола RCP (Remote Copy Protocol — протокол дистанционного копирования) по любому из поддерживаемых видов
передающей среды, таким как Ethernet, Token Ring, FDDI (Fiber Distributed Data Interface — распределенный интерфейс передачи данных по волоконнооптическим каналам) , HSSI (High-Speed Serial Interface — высокоскоростной последовательный интерфейс) и по последовательным каналам.
Загрузка из флэш-памяти. Маршрутизаторы могут загружаться из флэш- памяти — энергонезависимого носителя данных, который можно стирать и перепрограммировать с помощью электронных средств.
Загрузка из ПЗУ. Начальная загрузка операционной системы маршрутизаторов может осуществляться с помощью встроенного постоянного запоминающего устройства (ПЗУ).
Загрузка с помощью платы флэш-памяти. Для начальной загрузки маршрутизаторов может применяться съемная плата флэш-памяти.
В настоящем разделе приведены общие сведения о загрузке маршрутизаторов.
Рекомендации по загрузке через сеть
Во время сеансов начальной загрузки по сети маршрутизаторы действуют как обычные хосты. Их трафик маршрутизируется с помощью информации протокола ARP (Address Resolution Protocol — протокол преобразования адресов), SLARP (Serial Line Address Resolution Protocol — протокол преобразования адресов последовательного канала), перенаправлений протокола 1СМР или с применением шлюза, заданного по умолчанию. Во время загрузки по сети маршрутизаторы игнорируют динамическую информацию маршрутизации, статические IP-маршруты и информацию о перенаправлении фреймов мостами. Поэтому успешная загрузка маршрутизатора в основном зависит от функционирования промежуточных маршрутизаторов, которые должны правильно обрабатывать запросы ARP и UDP (User Datagram Protocol — протокол пользовательских дейтаграмм). При использовании в качестве передающей среды последовательных каналов и интерфейса HSSI протокол ARP не применяется.
Перед выполнением начальной загрузки по сети с сервера необходимо выполнить эхо-тестирование сервера с помощью программного обеспечения, записанного в ПЗУ. Если эхо-тестирование сервера невозможно выполнить, обратитесь к процедурам, описанным ниже, в разделе “Начальная загрузка: маршрутизатор не может загрузиться по сети от TFTP-сервера”. Если и после этого невозможно выполнить эхо- тестирование сервера, то, вероятно, имеются ошибки в конфигурации сервера или неисправности аппаратных средств. Изучите документацию по TFTP-серверу или обратитесь за помощью к представителю службы технической поддержки.
Надежные методы начальной загрузки
Метод начальной загрузки по сети является очень удобным, но его применение может стать невозможным при нарушениях в работе сети или сервера. После установки и настройки флэш-памяти маршрутизатора необходимо правильно определить последовательность начальной загрузки маршрутизатора, чтобы свести к минимуму влияние нарушений в работе сервера или сети. Рекомендуется следующий порядок загрузки.
Загрузка образа системы из флэш-памяти.
Загрузка образа системы по сети.
Начальная загрузка с применением образа системы, записанного в ПЗУ.
Ниже приведен пример того, как нужно выполнить настройку конфигурации маршрутизатора с учетом указанной последовательности начальной загрузки.
goriot# configure terminal
Enter configuration commands, one per line. End with CNTL/Z. goriot(config)# boot system flash gsxx
goriot(config)# boot system gsxx 131.108.1.101
goriot(config)# boot system rom
goriot(config)# AZ
goriot#
%SYS-5-CONFIG I: Configured from console by console
goriot# copy running-config startup-config
[ok]
goriot#
Если применяется описанный метод, то маршрутизатор имеет три источника информации для начальной загрузки: он может загружаться из флэш-памяти, по сети, а также из ПЗУ. Предоставление альтернативных источников загрузочной информации позволяет уменьшить влияние любых нарушений в работе TFTP-сервера или сети.
Примечание
Чтобы обеспечить загрузку записанного в ПЗУ образа системы после неудачных попыток начальной загрузки по сети, необходимо выполнить настройку регистра конфигурации. Дополнительная информация приведена в руководстве по настройке конфигурации аппаратных средств для конкретной платформы.
Тайм-ауты и пакеты, поступающие с нарушением порядка следования
Во время начальной загрузки по сети клиенту может потребоваться повторно передавать запросы перед получением ответа на определенный ARP-запрос. При таких повторных передачах могут возникать тайм-ауты и появляться пакеты, поступающие с нарушением порядка следования.
Тайм-ауты (показанные точками на дисплее начальной загрузки по сети) и пакеты с нарушением порядка следования (показанные прописными буквами О) не всегда препятствуют успешной начальной загрузке по сети. Поэтому в процессе начальной загрузки по сети вполне допустимо появление тайм-аутов или пакетов с нарушением порядка следования, или тех и иных.
В следующих примерах показан вывод на консоль во время сеансов начальной загрузки по сети, которые оказались успешными, даже несмотря на появление таймаутов и пакетов с нарушением порядка следования (восклицательными знаками указаны успешно принятые пакеты):
Booting gs3-bfx from 131.108.1.123: !.!!!!!!!!!!!!!!!!!!!!!!
Booting gs3-bfx from 131.108.1.123: 10.011111111 111111111! 1111
Но если в ходе начальной загрузки по сети появляется слишком много таймаутов и пакетов с нарушением порядка следования, то могут возникнуть проблемы. Эти проблемы рассматриваются ниже в этой главе, в разделе “Начальная загрузка:
тайм-ауты и пакеты с нарушением порядка следования препятствуют выполнению загрузки по сети”.
Информация для службы технической поддержки
Если вы не можете решить проблему начальной загрузки с использованием процедур, описанных в настоящей главе, подготовьте следующую информацию для представителя службы технической поддержки.
Версии образов системы, записанных в ПЗУ. (Используйте exec-команду show version.)
Надписи на программируемых ПЗУ. (Эта информация отпечатана на корпусе микросхемы и пример ее показан на рис. 3.1.)
изо v11 1(2)RS P2-ROMMON017-2111-04Cisco Systems
Рис. 3.1. Пример надписи на ПЗУ начальной загрузки версии 11.1(2)
Конфигурации энергонезависимых ОЗУ для клиентского маршрутизатора и смежных маршрутизаторов.
Отладочный вывод, полученный со смежных маршрутизаторов с использованием следующих привилегированных ехес-команд:
debug ip packet;
debug arp;
debug ip udp;
debug tftp.
Дополнительная информация о командах debug приведена в справочнике по отладочным командам Debug Command Reference.
Поиск неисправностей аппаратных средств
В настоящем разделе описаны процедуры устранения нарушений связи между устройствами, возникающих при начальной загрузке. Здесь описаны конкретные признаки нарушений начальной загрузки, проблемы, которые могут вызвать появление каждого признака неисправности, а также представлены решения этих проблем.
Запуск маршрутизаторов ряда Cisco 7500
При запуске маршрутизаторов ряда Cisco 7500 должно произойти следующее.
Светодиод АС ОК (или DC ОК) должен немедленно загореться и продолжать гореть до тех пор, пока в систему подается питание.
Должен работать внутренний вентилятор.
Должны загореться светодиоды Normal процессора маршрутизации/коммутации (RSP — Route Switch Processor) и лицевой панели и продолжать гореть на про-
тяжении всего времени функционирования системы; светодиод CPU Halt не должен гореть.
Должен гореть светодиод Enabled на каждом интерфейсном процессоре (указывая на то, что процессор RSP выполнил инициализацию интерфейсного процессора).
После успешной инициализации системы маршрутизаторов ряда 7500 на экране консоли должна отобразиться системная заставка. Если она не отображается, убедитесь в том, что терминал консоли правильно подключен к порту RSP и настроен должным образом. Системная заставка должна выглядеть примерно так:
System Bootstrap, Version 4.6(5), SOFTWARE
Copyright (c) 1986-1995 by cisco Systems
RSP2 processor with 16384 Kbytes of memory
Ш [...] Ш
F3: 2012356+47852+194864 at 0x1000
Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 GS Software (RSP-K), Version 10.3(571) [fc3], RELEASE SOFTWARE Copyright (c) 1986-1995 by cisco Systems, Inc.
[...]
Press RETURN to get started!
При обнаружении неисправности попытайтесь выяснить, в какой именно подсистеме она возникла. Маршрутизаторы ряда Cisco 7500 имеют следующие подсистемы.
Подсистема питания. Включает блоки питания, внешний силовой кабель и объединительную плату.
Подсистема охлаждения. В зависимости от системы, включает следующее.
Cisco 7505. Плоский вентиляторный модуль, запасной плоский вентиляторный модуль с шестью отдельными вентиляторами и пультом управления вентиляторами.
Cisco 7507. Внутренний вентилятор блока.
Cisco 7513. Модуль внутреннего вентилятора, включая внутренний вентилятор, пульт регулировки скорости внутреннего вентилятора, светодиоды лицевой панели и сам модуль.
Подсистема процессора. В зависимости от системы, включает все интерфейсные процессоры, а также процессоры маршрутизации/коммутации RSP1 или RSP2.
В табл. 3.1 перечислены основные области, в которых могут возникать проблемы при запуске маршрутизаторов ряда Cisco 7500, и описаны решения этих проблем.
[Таблица 3.1.
. Аппаратные средства: проблемы запуска маршрутизаторов ;
Проблема
ряда Cisco 7500 и их решения..j
Решение
Подсистема питания
Шаг 1. Проверьте, работает ли внутренний вентилятор и горят ли светодиоды на процессорных модулях. Если внутренний вентилятор работает и светодиоды горят, а светодиод источника питания Power Supply не горит, то, вероятно, неисправен светодиод Power Supply.
Шаг 2. Убедитесь в том, что выключатель питания установлен правильно в положение “включено”.
Шаг 3. Убедитесь в том, что источник питания, силовой кабель и блок питания функционируют нормально. Заменяйте эти компоненты заведомо исправными, чтобы определить, какой из компонентов неисправен.
Шаг 4. Проверьте, установлен ли должным образом модуль внутреннего вентилятора. Убедитесь в том, что краевой соединитель блока управления внутреннего вентилятора полностью вставлен в гнездо объединительной платы.
Подсистема охлаждения
Шаг 1. Проверьте, работает ли внутренний вентилятор при запуске системы. Если внутренний вентилятор не работает, то, возможно, неисправен внутренний вентилятор или нарушена подача питания постоянным током с напряжением +24 В.
Если горит светодиод Output Fail, то, вероятно, нарушена подача питания постоянным током с напряжением +24 В к внутреннему вентилятору или к плоскому вентиляторному модулю из-за неисправности блока питания или блока управления внутренним вентилятором.
Если внутренний вентилятор не работает и не горит светодиод Output Fail, проверьте, установлен ли должным образом модуль внутреннего вентилятора. Проверьте, полностью ли вставлен в гнездо объединительной платы краевой соединитель блока управления внутренним вентилятором.
Шаг 2. Если система и внутренний вентилятор запускаются, а затем останавливаются примерно через 2 минуты, то, возможно, один или несколько вентиляторов неисправны или работают в условиях, выходящих за пределы допустимых. На экране может появиться примерно такое сообщение об ошибке:
4ENVM-2-FAN: Fan has failed, shutdown in 2 minutes
Если произошел отказ внутреннего вентилятора или блока управления внутренним вентилятором, необходимо заменить модуль внутреннего вентилятора.
Шаг 3. Если при запуске появляется следующее сообщение, это означает, что система обнаружила в корпусе состояние перегрева или выходящие за пределы допустимых характеристики питания:
Queued messages:
3ENVM-1-SHUTD0WN: Environmental Monitor initiated shutdown
Проблема
Решение
Если причиной останова из-за нарушения условий эксплуатации явились характеристики питания, выходящие за пределы допустимых, то перед остановом системы загорается светодиод Output Fail.
Приведенное выше сообщение об останове может также указывать на наличие неисправного компонента или датчика температуры. Прежде чем произойдет останов системы, воспользуйтесь командой show environment или show environment table, чтобы ознакомиться с температурными условиями внутри корпуса.
Шаг 4. Убедитесь в том, что горячий отработанный воздух от другого оборудования не попадает в воздухоприемные отверстия и вокруг корпуса имеется достаточное свободное пространство, которое обеспечивает беспрепятственное протекание охлаждающего воздуха.
Подсистема процессора
Шаг 1. Проверьте светодиод RSP (Route Switch Processor — процессор мар- шрутизации/коммутации). Если светодиоды не горят, проверьте, функционируют ли должным образом источники питания и внутренний вентилятор.
Шаг 2. Проверьте посадку в гнезде процессора RSP. Если процессор RSP не установлен должным образом, это приведет к зависанию системы.
Шаг 3. Если горит светодиод CPU Halt процессора RSP, это означает, что система обнаружила отказ аппаратных средств процессора. Обратитесь к представителю службы технической поддержки для получения дальнейших указаний.
Шаг 4. Выясните, горит ли светодиод Normal процессора RSP, который указывает, что системное программное обеспечение инициализировано успешно и что система работоспособна.
Шаг 5. Проверьте светодиод Enabled на каждом интерфейсном процессоре. Этот светодиод должен гореть, когда происходит инициализация интерфейсного процессора процессором RSP.
Шаг 6. Если не горит светодиод Enabled на отдельном интерфейсном процессоре, то, возможно, разъем интерфейсного процессора вынут из гнезда объединительной платы. Если интерфейсные процессоры не установлены должным образом, это приводит к зависанию системы.
Запуск маршрутизаторов ряда Cisco 7000
При запуске маршрутизаторов ряда Cisco 7000 должно произойти следующее.
Должен загореться светодиод DC ОК и продолжать гореть до тех пор, пока в систему подается питание от сети.
Вентиляторы должны работать.
Должен загореться светодиод Normal процессора маршрутизации (RP — Route Processor); светодиод Normal должен продолжать гореть, указывая на то, что система функционирует нормально; светодиод Halt CPU не должен гореть.
После завершения процессором RP инициализации интерфейсного процессора, процессора коммутации (SP — Switch Processor) или кремниевого процессора коммутации (SSP — Silicon Switch Processor) в ходе его подготовки к работе должен загореться светодиод Enabled процессора SP или SSP, и каждый интерфейсный процессор должен начать работать.
После успешной инициализации системы на экране консоли должна отобразиться системная заставка. Если она не отображается, убедитесь в том, что терминал консоли правильно подключен к порту RP и настроен должным образом. Системная заставка должна выглядеть примерно так:
System Bootstrap, Version 4.6(5), SOFTWARE Copyright (c) 1986-1995 by cisco Systems RP1 processor with 16384 Kbytes of memory Hi [...] Ш
F3: 2012356+47852+194864 at 0x1000
Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc.
170 West Tasman Drive■
San Jose, California 95134-1706
GS Software (GS7), Version 10.3(1) [fc3], RELEASE SOFTWARE Copyright (c) 1986-1995 by cisco Systems, Inc.
RP1 (68040) processor with 16384K bytes of memory. [...]
Press RETURN to get started!
При обнаружении неисправности попытайтесь выяснить, в какой именно подсистеме она возникла. Маршрутизаторы ряда Cisco 7000 имеют следующие подсистемы.
Подсистема питания. Включает источники питания, вентиляторы, внешний силовой кабель и внутреннюю проводку питания, подключенную к объединительной плате.
Подсистема охлаждения. В зависимости от системы, включает следующее.
Cisco 7000. Внутренний вентилятор корпуса.
Cisco 7010. Плоский вентиляторный модуль в сборе, включая шесть отдельных вентиляторов, блок управления вентиляторами и сам плоский модуль.
Подсистема процессора. Включает RP, SP (или SSP) и все интерфейсные процессоры.
В табл. 3.2 перечислены основные области, в которых могут возникать проблемы при запуске маршрутизаторов ряда Cisco 7000, и описаны решения этих проблем.
; Таблица 3.2. Аппаратные средства: проблемы запуска маршрутизаторов j
ряда Cisco 7000 и их решенияj
Проблема
Решение
Подсистема питания
Шаг 1. Выясните, горит ли светодиод DC ОК.
Шаг 2. Если этот светодиод не горит, а вентиляторы работают и горят светодиоды на модулях процессора, то, вероятно, неисправен светодиод Power Supply.
Шаг 3. Если светодиод не горит и нет других проявлений нормального функционирования маршрутизатора, убедитесь в том, что выключатель питания находится полностью в положении “включено”.
Шаг 4. Убедитесь в том, что источник питания, силовой кабель и блок питания функционируют нормально. Заменяйте эти компоненты заведомо исправными, чтобы определить, какой из компонентов неисправен.
Шаг 5. Проверьте, установлен ли должным образом плоский модуль вентилятора. Убедитесь в том, что краевой соединитель блока управления вентилятора полностью вставлен в гнездо объединительной платы
Подсистема охлаждения
Шаг 1. Выясните, работают ли вентиляторы.
Шаг 2. Если вентиляторы не работают и не горит светодиод DC ОК, то может иметь место нарушение подачи питания постоянным током с напряжением +24 В.
Шаг 3. Проверьте, установлен ли должным образом плоский вентиляторный модуль. Проверьте, полностью ли вставлен в гнездо объединительной платы краевой соединитель блока управления внутренним вентилятором.
Шаг 4. Если система и вентиляторы запускаются, а затем останавливаются примерно через 2 минуты, то, возможно, один или несколько вентиляторов неисправны или работают в условиях, выходящих за пределы допустимых. На экране может появиться примерно такое сообщение об ошибке:
4ENVM-2-FAN: Fan array has failed, shutdown in 2 minutes
Если произошел отказ одного или нескольких вентиляторов или блока управления вентиляторами, необходимо заменить плоский вентиляторный модуль.
Шаг 5. Если при запуске появляется следующее сообщение, это означает, что система обнаружила в корпусе состояние перегрева или выходящие за пределы допустимых характеристики питания: Queued messages: %ENVM-1-SHUTDOWN: Environmental Monitor initiated shutdown
Если причиной останова из-за нарушения условий эксплуатации явились характеристики питания, выходящие за пределы допустимых, то перед остановом системы гаснет светодиод DC ОК.
Проблема
Решение
Убедитесь в том, что горячий отработанный воздух от другого оборудования не попадает в воздухоприемные отверстия и вокруг корпуса имеется достаточное свободное пространство, которое обеспечивает беспрепятственное протекание охлаждающего воздуха
Приведенное выше сообщение об останове может также указывать на наличие неисправного компонента или датчика температуры. Прежде чем произойдет останов системы, воспользуйтесь командой show environment или show environment table, чтобы ознакомиться с температурными условиями внутри корпуса.
Подсистема процессора
Шаг 1. Выясните, загораются ли светодиоды RP после включения выключателя питания системы.
Шаг 2. Если ни один из светодиодов RP не загорается, убедитесь в том, что вентилятор и блок питания функционируют должным образом.
Шаг 3. Если отсутствуют видимые признаки отказа блока питания и вентиляторов, но ни один из светодиодов RP не загорается, это может означать, что в результате неправильной установки процессора RP, SP (или SSP) или интерфейсного процессора произошло зависание системной шины.
Шаг 4. Если светодиод SP Enabled (или SSP Enabled) не горит, но горит любой из светодиодов RP, убедитесь в том, что SP (или SSP) установлен в разъем должным образом.
Шаг 5. Выясните, горит ли светодиод Boot Error. Если светодиод горит, это означает, что запуск системного программного обеспечения невозможен. Если у вас имеется резервный процессор RP с установленными ПЗУ системного программного обеспечения, замените установленный процессор RP резервным, чтобы проверить, загружается ли система.■
Шаг 6. Выясните, горит ли светодиод CPU Halt процессора RP. Если светодиод горит, это означает, что система обнаружила отказ аппаратных, средств процессора. Обратитесь к представителю службы технической поддержки для получения дальнейших указаний.
Шаг 7. Выясните, горят ли светодиоды Enabled всех интерфейсных процессоров.
Шаг 8. Если не горит светодиод Enabled на отдельном интерфейсном процессоре, убедитесь в том, что разъем интерфейсного процессора плотно вставлен в гнездо объединительной платы.
Запуск маршрутизаторов ряда Cisco 4000
При запуске маршрутизаторов ряда Cisco 4000 должно произойти следующее.
Светодиод System ОК должен загореться и продолжать гореть до тех пор, пока в систему подается питание.
Вентиляторы должны работать.
После успешной инициализации системы на экране консоли отображается системная заставка, которая выглядит примерно так:
System Bootstrap, Version 4.14(9), SOFTWARE Copyright (c) 1986-1994 by cisco Systems 4000 processor with 16384 Kbytes of main memory
Loading xx-j-mz.112-0.15 at 0x4A790, size = 3496424 bytes [OK] F3: 8988+3487404+165008 at 0x12000
Self decompressing the image : H#[...]HH [OK]
Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134-1706
Cisco Internetwork Operating System Software
IOS (tm) 4000 Software (XX-J-M), Version 11.2(0.15), BETA TEST SOFTWARE
Copyright (c) 1986-1996 by cisco Systems, Inc.
Compiled Wed 03-Jul-96 01:21 by susingh
Image text-base: 0x00012000, data-base: 0x006F6494
cisco 4000 (68030) processor (revision OxAO) with 16384K/4096K bytes of memory.
Processor board ID 5007155
G.703/E1 software, Version 1.0.
Bridging software.
SuperLAT software copyright 1990 by Meridian Technology Corp).
X.25 software, Version 2.0, NET2, BFE and GOSIP compliant.
TN3270 Emulation software (copyright 1994 by TGV Inc).
Basic Rate ISDN software, Version 1.0.
2 Ethernet/IEEE 802.3 interfaces.
Serial network interfaces.
ISDN Basic Rate interfaces.
128K bytes of non-volatile configuration memory.
4096K bytes of processor board System flash (Read/Write)
Press RETURN to get started!
При обнаружении неисправности попытайтесь выяснить, в какой именно подсистеме она возникла. Маршрутизаторы ряда Cisco 4000 имеют следующие подсистемы.
Подсистема питания. Эта подсистема состоит из блока питания и внутренней проводки.
Подсистема охлаждения. Эта подсистема включает блок внутреннего вентилятора, который должен включаться после подачи питания.
Сетевые процессорные модули. Эта подсистема включает все модули NPM (Network Processor Module — сетевой процессорный модуль), установленные в корпусе маршрутизатора.
Системные кабели. Эта подсистема включает все внешние кабели, с помощью которых маршрутизатор подключается к сети.
В табл. 3.3 перечислены основные области, в которых могут возникать проблемы при запуске маршрутизаторов ряда Cisco 4000, и описаны решения этих проблем.
Таблица 3.3. Аппаратные средства: проблемы запуска маршрутизаторов ! ряда Cisco 4000 и их решения . ■।
Проблема
Решение
Подсистемы охлаждения и питания
Шаг 1. Определите, работает ли внутренний вентилятор. Если вентилятор не работает, проверьте ввод питания переменным током, источник питания переменным током, автоматический выключатель маршрутизатора и кабель питания.
Шаг 2. Если система останавливается после непродолжительной работы, проверьте питание. Если отсутствуют видимые признаки отказа системы питания, то, возможно, останов маршрутизатора произошел из-за перегрева. Проверьте, выведены ли на консоль примерно такие сообшения об ошибках.
3SYS-1-0VERTEMP: System detected OVERTEMPERATURE condition. Please resolve cooling problem immediately!
Убедитесь в том, что вентиляторы работают и ничто не препятствует поступлению охлаждающего воздуха к воздухоприемным отверстиям.
Шаг 3. Если система частично загружается, но светодиоды не загораются, обратитесь за консультацией к представителю службы технической поддержки
Процессоры NPM и кабели
Шаг 1. Убедитесь в том, что процессоры NPM подключены должным образом к соединителю системной платы.
Шаг 2. Проверьте внешние кабели.
Шаг 3. Проверьте, правильно ли выполнена настройка конфигурации процессора или программного обеспечения.
Шаг 4. Проверьте внешнее соединение с консолью и убедитесь в том, что скорость обмена данными с консолью установлена правильно
Запуск маршрутизаторов ряда Cisco 2500
При запуске маршрутизаторов ряда Cisco 2500 должно произойти следующее.
Светодиод System ОК должен немедленно загореться и продолжать гореть до тех пор, пока в систему подается питание.
Вентиляторы должны работать.
После успешной инициализации системы на экране консоли отображается системная заставка. Системная заставка должна выглядеть примерно так:
System Bootstrap, Version (3.3), SOFTWARE Copyright (c) 1986-1993 by cisco Systems 2500 processor with 16384 Kbytes of main memory
Unknown or ambiguous service arg - udp-small-servers Unknown or ambiguous service arg - tcp-small-servers Booting igs-in-1.110-9 from Flash address space F3: 3844616+90320+228904 at 0x3000060
Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134-1706
Cisco Internetwork Operating System Software
IOS (tm) 3000 Software (IGS-IN-L), Version 11.0(9), RELEASE SOFTWARE (fcl)
Copyright (c) 1986-1996 by cisco Systems, Inc.
Compiled Tue ll-Jun-96 01:15 by loreilly
Image text-base: 0x03020F8C, data-base: 0x00001000
cisco 2500 (68030) processor (revision A) with 16384K/2048K bytes of memory.
Processor board ID 01062462, with hardware revision 00000000
Bridging software.
X.25 software, Version 2.0, NET2, BFE and GOSIP compliant.
Basic Rate ISDN software, Version 1.0.
Ethernet/IEEE 802.3 interface.
Serial network interfaces.
ISDN Basic Rate interface.
32K bytes of non-volatile configuration memory.
4096K bytes of processor board System flash (Read ONLY)
Press RETURN to get started!
При обнаружении неисправности попытайтесь выяснить, в какой именно подсистеме она возникла. Маршрутизаторы ряда Cisco 2500 имеют следующие подсистемы.
Подсистема питания. Эта подсистема включает блок питания и внутреннюю проводку.
Подсистема охлаждения. В эту подсистему входит вентилятор, который должен включаться после подачи питания.
Сетевые интерфейсы. Эта подсистема включает все сетевые интерфейсы, такие как Ethernet, Token Ring, последовательный интерфейс или интерфейс BRI (Basic Rate Interface — интерфейс базовой скорости передачи) сети ISDN.
Системные кабели. Эта подсистема включает все внешние кабели, с помощью которых маршрутизатор подключается к сети.
В табл. 3.4 перечислены основные области, в которых могут возникать проблемы при запуске маршрутизаторов ряда Cisco 2500, и описаны решения этих проблем.
Таблица 3.4. Аппаратные средства: проблемы запуска маршрутизаторов . ряда Cisco 2500 и их решенияа
Проблема
Решение
Подсистемы охлаждения и питания
Шаг 1. Если светодиод Power выключен, убедитесь в том, что вилка источника питания вставлена в стенную штепсельную розетку и что кабель источника питания подключен к маршрутитзатору.
Шаг 2. Если система останавливается после непродолжительной работы, то, возможно, произошел останов из-за перегрева, вызванный неисправным вентилятором, или нарушена подача питания в систему. Убедитесь в том, что в систему подается питание и что воздухоприемные и воздуховыпускные отверстия корпуса ничем не перекрыты.
Шаг 3. Если система не загружается, но светодиоды горят, проверьте питание напряжением +12 В.
Шаг 4. Если система частично загружается, но светодиоды не горят, проверьте питание напряжением +5 В
Сетевые интерфейсы и кабели
Шаг 1. Если сетевой интерфейс не распознается системой, проверьте соединение кабеля интерфейса и светодиод на сетевом интерфейсе.
Шаг 2. Если сетевой интерфейс распознается, но не инициализируется, проверьте соединение кабеля интерфейса.
Шаг 3. Если система не загружается должным образом, или загружается только после нескольких попыток, или периодически перезагружается, то может иметь место нарушение в работе процессора или программного обеспечения. Убедитесь в том, что модули SIMM (Single In-Line Memory Module — модуль памяти с однорядным расположением выводов) динамического ОЗУ установлены должным образом.
Шаг 4. Если система загружается, но изображение на экране консоли не меняется, проверьте внешнее соединение с консолью и убедитесь в том, что скорость обмена данными с консолью установлена правильно.
Шаг 5. Если в систему поступает питание и происходит начальная загрузка, но какой-то интерфейс остается неподключенным, проверьте сетевое соединение интерфейса
Запуск коммутаторов ряда Catalyst 5000
При запуске LAN-коммутатора ряда Catalyst 5000 должно произойти следующее.
Светодиоды PS1 и PS2 на лицевой панели блока управления должны гореть зеленым светом.
Блок вентиляторов системы должен работать и должен гореть светодиод Fan на блоке управления.
Светодиоды Status на блоке управления и всех интерфейсах должны гореть оранжевым светом до тех пор, пока не закончится начальная загрузка.
После завершения начальной загрузки системы блок управления должен инициализировать коммутационные модули. Светодиод Status на каждом коммутационном модуле после завершения инициализация загорается и на экране консоли отображаются сценарий и системная заставка, примерно так:
АТЕО
ATS0=1
Catalyst 5000 Power Up Diagnostics
Init NVRAM Log
LED Test
ROM CHKSUM
DUAL PORT RAM r/w
RAM r/w
RAM address test
Byte/Word Enable test
RAM r/w 55aa
RAM r/w aa55
EARL test
B00TR0M Version 1.4, Dated Dec 5 1995 16:49:40
BOOT date: 00/00/00 BOOT time: 03:18:57
SIMM RAM address test
SIMM Ram r/w 55aa'
SIMM Ram r/w aa55
Start to Uncompress Image ...
IP address for Catalyst not configured
BOOTP will commence after the ports are online
Ports are coming online ...■
Cisco Systems Console
При обнаружении неисправности попытайтесь выяснить, в какой именно подсистеме она возникла. LAN-коммутаторы ряда Catalyst 5000 имеют следующие подсистемы.
Подсистема питания. Эта подсистема включает вентиляторы питания и источники питания.
Подсистема охлаждения. Эта подсистема включает блок вентиляторов корпуса, который должен работать, если в систему подается питание.
Подсистема процессора и интерфейсов. Эта подсистема включает блок управления (который содержит операционное программное обеспечение системы), сетевые интерфейсы и всю соответствующую кабельную систему.
В табл. 3.5 перечислены основные области, в которых могут возникать проблемы при запуске LAN-коммутатора ряда Catalyst 5000, и описаны решения этих проблем.
( таблица 3.5. Аппаратные средства: проблемы запуска LAN-коммутатора :
Проблема
ряда Catalyst 5000 и их решения
Решение
Подсистема питания
Шаг 1. Выясните, горит ли светодиод PS1. Если он не горит, убедитесь в том, что блок питания подключен должным образом и находится заподлицо с задней частью корпуса. Убедитесь в том, что невыпа- даюшие монтажные винты плотно затянуты.
Шаг 2. Проверьте источник постоянного тока и силовой кабель. Подключите кабель питания к другому источнику питания, если он имеется, и снова включите питание. Если светодиод не загорится и после подключения блока питания к другому источнику питания, замените кабель питания.
Шаг 3. Если светодиод не загорится после подключения коммутатора к другому источнику питания с помошью нового кабеля питания, то, возможно, неисправен блок питания. Если имеется запасной блок питания, установите его во втором отсеке для блока питания и обратитесь к представителю службы технической поддержки для получения дальнейших указаний.
Шаг 4. Повторите указанные шаги для второго блока питания, если он имеется
Подсистема охлаждения
Шаг 1. Выясните, горит ли зеленым светом светодиод Fan на блоке управления. Если он не горит, проверьте подсистему питания, чтобы определить, нормально ли она функционирует.
Шаг 2. Если светодиод Fan горит красным светом, блок вентиляторов не подключен должным образом к разъему объединительной платы.
Чтобы убедиться в том, что блок вентиляторов подкислен должным образом, ослабьте невыпадаюшие монтажные винты, снимите блок вентиляторов и снова его установите. Затяните все невыпадаюшие монтажные винты и перезапустите систему.
Шаг 3. Если светодиод Fan все еше горит красным светом, то система, вероятно, обнаружила отказ блока вентиляторов. Обратитесь за помо- шью к представителю службы технической поддержки
Подсистема процессора и интерфейсов
Шаг 1. Проверьте светодиоды Link и Status блока управления. Оба они должны гореть зеленым светом, если все функции диагностики и самоконтроля были выполнены успешно и порты находятся в работоспособном состоянии. Для получения дополнительной информации о назначении светодиодов блока управления обратитесь к руководству пользователя коммутатора.
Шаг 2. Проверьте светодиоды на отдельных модулях интерфейса. В большинстве случаев они должны гореть зеленым светом (или должны мерцать зеленым светом, в случае светодиодов Transmit и Receive), если интерфейс функционирует правильно. Для получения дополнительной информации о назначении светодиодов модуля интерфейса обратитесь к руководству пользователя коммутатора.
Шаг 3. Проверьте всю кабельную проводку и все соединения. Замените неисправную кабельную проводку
Запуск коммутаторов ряда Catalyst 2900
При запуске LAN-коммутатора ряда Catalyst 2900 должно произойти следующее.
Светодиод PS на лицевой панели блока управления должен загореться и продолжать гореть зеленым светом до тех пор, пока в систему подается питание.
Блок вентиляторов системы должен включиться, а светодиод Fan — загореться. Они должны оставаться в таком состоянии до тех пор, пока в систему подается питание.
Светодиоды Status на блоке управления и на каждом интерфейсе должны гореть оранжевым светом до тех пор, пока не закончится начальная загрузка.
После завершения начальной загрузки системы блок управления должен инициализировать коммутационные модули. Светодиод Status на каждом коммутационном модуле после завершения инициализации загорается и на экране консоли отображаются сценарий и системная заставка, примерно так:
BOOTROM Version 2.1, Dated May 22 1996 15:17:09
Boot date: 05/22/96 BOOT time: 15:17:09
Executing from RAM
Cisco Systems Console
Sending RARP request with address 00:40:Ob:aO:05:b8
Sending bootp request with address 00:40:0b:aO:05:b8
Sending RARP request with address 00:40:0b:a0:05:b8
Sending bootp request with address 00:40:0b:aO:05:b8
No bootp or rarp response received
Enter password:
При обнаружении неисправности попытайтесь выяснить, в какой именно подсистеме она возникла. LAN-коммутатор ряда Catalyst 2900 имеет следующие подсистемы.
Подсистема питания. Эта подсистема включает источники питания и вентиляторы источников питания.
Подсистема охлаждения. Эта подсистема включает блок вентиляторов корпуса, который должен работать, если в систему подается питание.
Подсистема процессора и интерфейсов. Эта подсистема включает блок управления (который содержит операционное программное обеспечение системы), сетевые интерфейсы и всю соответствующую кабельную систему.
В табл. 3.6 перечислены основные области, в которых могут возникать проблемы при запуске LAN-коммутатора ряда Catalyst 2900, и описаны решения этих проблем.
! Таблица 3.6.
Аппаратные средства: проблемы запуска LAN-ком мутатора ряда Catalyst 2900 и их решения,
Проблема
Решение
Подсистема питания
Шаг 1. Проверьте светодиод Power. Если он не горит, убедитесь в том, что кабель питания не поврежден и присоединен должным образом к блоку питания и к штепсельной розетке сети переменного тока.
Шаг 2. Если светодиод горит красным светом, это означает, что прервана подача электроэнергии или обнаружена неисправность блока питания и требуется его обслуживание. Для получения дальнейших указаний обратитесь к представителю службы технической поддержки
Подсистема охлаждения
Шаг 1. Выясните, горит ли зеленым светом светодиод Fan на блоке управления. Если светодиод не горит зеленым светом, проверьте подсистему питания, чтобы определить, нормально ли она функционирует.
Шаг 2. Если светодиод Fan горит красным светом, обратитесь за помощью к представителю службы технической поддержки
Подсистема процессора и интерфейсов
Шаг 1. Проверьте светодиоды Link и Status блока управления. Оба они должны гореть зеленым светом, если все функции диагностики и самоконтроля были выполнены успешно и порты находятся в работоспособном состоянии. Для получения дополнительной информации о назначении светодиодов блока управления обратитесь к руководству пользователя коммутатора.
Шаг 2. Проверьте светодиоды на отдельных модулях интерфейса. В большинстве случаев они должны гореть зеленым светом (или должны мерцать зеленым светом, в случае светодиодов Transmit и Receive), если интерфейс функционирует правильно. Для получения дополнительной информации о назначении светодиодов модуля интерфейса обратитесь к руководству пользователя коммутатора.
Шаг 3. Проверьте всю кабельную проводку и все соединения. Замените всю неисправную кабельную проводку
Проверка и аттестация сменного оборудования
Если для поиска неисправности применяется метод, предусматривающий замену компонентов или плат, выполняйте каждый раз только одну замену.
Для проверки системы выполните ее запуск в самой простой аппаратной конфигурации и постепенно добавляйте по одной плате, пока не будет обнаружен или изолирован неисправный интерфейс. Используйте простую программную конфигурацию и проверяйте наличие связи по сети с помощью команды ping.
Если будет обнаружено, что требуется замена компонента или платы, обратитесь к торговому представителю или представителю службы технической поддержки. Конкретные инструкции по монтажу компонента или платы приведены в рекомендациях по настройке, которые входят в комплект компонента или платы, предназначенных для замены.
Выполняя поиск неисправностей в модульных маршрутизаторах, следите за правильной установкой всех плат. Если система не загружается должным образом, проверьте установку плат в разъемах. С помощью эжекторного рычага приподнимите, а затем снова установите в гнезда все процессорные модули, после чего выполните перезагрузку.
Предостережение
Прежде чем приступить к работе во внутренней части корпуса и снятию каких-либо плат, отключите питание, поступающее к устройству. Соблюдайте исключительные меры предосторожности в процессе работы с устройством, чтобы избежать соприкосновения с частями, находящимися под высоким напряжением.
Предостережение
Чтобы исключить возможность повреждения компонентов, чувствительных к электростатическим разрядам, перед открытием корпуса установите средства защиты от электростатических разрядов. Убедитесь в том, что кабель питания подключен, но питание выключено. Рекомендации по предотвращению повреждения оборудования от электростатического разряда приведены в инструкции по монтажу и техническому обслуживанию аппаратных средств, которая входит в комплект маршрутизатора.
Если замена какого-либо компонента, по-видимому, привела к устранению неисправности, снова установите компонент, который рассматривается как неисправный, чтобы проверить, действительно ли снова возникнет отказ. Всегда перепроверяйте результаты ремонта.
Поиск неисправностей, которые приводят к нарушению загрузки
В настоящем разделе рассматриваются процедуры поиска неисправностей в процессе устранения проблем обеспечения связи, связанных с загрузкой. Здесь описаны конкретные признаки нарушения загрузки, перечислены неисправности, которые, скорее всего, могут вызвать конкретные признаки, и представлены решения этих проблем.
Начальная загрузка: маршрутизатор не может загрузиться из флэш-памяти
Признак неисправности. При загрузке маршрутизатора из флэш-памяти создается впечатление, что процесс загрузки завершается, но маршрутизатор не маршрутизирует трафик или не взаимодействует со смежными маршрутизаторами. Кроме того, невозможно определить, выполняются или не выполняются ехес- команды.
В табл. 3.7 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
i Таблица 3.7. Начальная загрузка: маршрутизатор не может загрузиться из j .флэш-памяти
Проблема
Решение
Неправильный или искаженный загрузочный образ системы (интерактивный командный процессор Cisco 1OS не функционирует)
Шаг 1. Проверьте регистр конфигурации с использованием ехес-команды show version. Настройте регистр на загрузку из флэш-памяти. Для получения дополнительной информации о параметрах настройки регистра конфигурации обратитесь к инструкции по монтажу и техническому обслуживанию аппаратных средств.
Шаг 2. Выключите маршрутизатор, а затем сразу же его включите.
Шаг 3. В течение первых 60 секунд загрузки нажмите клавишу <Break>, чтобы получить доступ к режиму ROMmon.
Шаг 4. После получения приглашения к вводу информации в режиме ROMmon (>) введите о/г 0x1, чтобы настроить регистр конфигурации на загрузку из ПЗУ.
Шаг 5. Введите i, чтобы повторно инициализировать маршрутизатор, в результате чего маршрутизатор перейдет в режим начальной установки.
Шаг 6. Получите правильный загрузочный образ системы. В случае необходимости обратитесь к представителю службы технической поддержки, чтобы определить, какой образ является правильным.
Шаг 7. После определения правильного загрузочного образа воспользуйтесь привилегированной exec-командой copy tftp flash в маршрутизаторе для получения загрузочного образа.
Шаг 8. Проверьте регистр конфигурации с использованием ехес-команды show version. Настройте регистр на загрузку из флэш-памяти.
Шаг 9. Воспользуйтесь привилегированной exec-командой show runningconfig, чтобы определить, содержит ли конфигурация маршрутизатора глобальную команду конфигурации boot system flash
Примечание. Если в данный момент в маршрутизаторе ряда Cisco 2500, Cisco 3000, Cisco 4000 или Cisco 7000 будет выдана команда сору running-config startup-config, то произойдет перезапись конфигурации. Предварительно убедитесь в том, что имеется резервная копия файла конфигурации.
Шаг 10. Включите команду boot system flash, если она не входит в состав конфигурации. После внесения этого изменения обязательно воспользуйтесь командой copy running-config startup-config.
Шаг 11. Введите привилегированную exec-команду reload, чтобы перезапустить маршрутизатор.
Синтаксис
Ниже показана синтаксическая структура команды reload.
reload [text] | [in [hh:]mm [text]] | [at hh:mm [month day | day month] [text]] | [cancel]
Примеры
В следующем примере показано, как воспользоваться командой reload для немедленной перезагрузки программного обеспечения маршрутизатора:
Проблема
Решение
Router# reload
В следующем примере показано, как воспользоваться командой reload для перезагрузки программного обеспечения маршрутизатора через 10 минут:
Router# reload in 10
Router# Reload scheduled for 11:57:08 PDT Eri Apr 21 1996 (in
10 minutes)
Proceed with reload? [confirm]
Router#
Неправильный или искаженный загрузочный образ системы (интерактивный командный процессор
Cisco 1OS функционирует)
Шаг 1. Получите правильный загрузочный образ системы. В случае необходимости обратитесь к представителю службы технической поддержки, чтобы определить, какой образ является правильным.
Шаг 2. Для получения загрузочного образа воспользуйтесь привилегированной exec-командой copy tftp flash.
Шаг 3. Проверьте регистр конфигурации с использованием ехес-команды show version. Настройте регистр на загрузку из флэш-памяти. Для получения дополнительной информации о параметрах настройки регистра конфигурации обратитесь к инструкции по монтажу и техническому обслуживанию аппаратных средств.
Шаг 4. Воспользуйтесь привилегированной exec-командой show runningconfig, чтобы определить, содержит ли активная конфигурация глобальную команду конфигурации boot system flash. Определите с помошью привилегированной ехес-команды show startup-config, включена ли команда boot system flash в конфигурацию, сохраненную в энергонезависимом ОЗУ.
Шаг 5. Включите команду boot system flash, если она не входит в состав конфигурации. После внесения этого изменения обязательно воспользуйтесь командой copy running-config startup-config, чтобы сохранить новую конфигурацию.
Шаг 6. Введите привилегированную exec-команду reload, чтобы перезапустить маршрутизатор.
Синтаксис
Ниже показана синтаксическая структура команды reload.
reload [text] | [in [hh:]mm [text]] | [at hh:mm [month day | day month] [text]] | [cancel]
Примеры
В следующем примере показано, как воспользоваться командой reload для немедленной перезагрузки программного обеспечения маршрутизатора:
Router# reload
В следующем примере показано, как воспользоваться командой reload для перезагрузки программного обеспечения маршрутизатора через 10 минут:
Проблема
Решение
Router# reload in 10
Router# Reload scheduled for 11:57:08 PDT Eri Apr 21 1996 (in 10 minutes)
Proceed with reload? [confirm]
Router#
Начальная загрузка: при загрузке из флэш-памяти возникает векторная ошибка
Признак неисправности. При загрузке пользователем маршрутизатора из флэш- памяти возникает векторная ошибка.
В табл. 3.8 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Таблица 3.8. Начальная загрузка: при загрузке из флэш-памяти возникает
Проблема
векторная ошибка\-
Решение
Архивированный загрузочный образ системы
Шаг J. Выключите маршрутизатор, а затем сразу же его включите.
Шаг 2. В течение первых 60 секунд загрузки нажмите клавишу <Break>, чтобы получить доступ к режиму ROMmon.
Шаг 3. После получения приглашения к вводу команд в режиме ROMmon (>) введите о/r, чтобы настроить регистр конфигурации на загрузку из ПЗУ.
Шаг 4. Введите Ь, чтобы загрузить маршрутизатор. Маршрутизатор переходит в режим начальной установки.
Шаг 5. Нажмите <Ctrl+C>, чтобы обойти этап начальной установки.
Шаг 6. Введите привилегированную exec-команду configure memory.
Шаг 7. Получите разархивированный загрузочный образ системы. Получив приглашение маршрутизатора к вводу информации, воспользуйтесь привилегированной exec-командой copy flash tftp для передачи архивированного загрузочного образа на TFTP-сервер.
Разархивируйте загрузочный образ на TFTP-сервере. Эта операция не может быть выполнена в маршрутизаторе.
Шаг 8. Воспользуйтесь в маршрутизаторе привилегированной ехес- командой copy tftp flash для получения разархивированного загрузочного образа. Ниже приведен пример использования команды copy tftp flash.
router# copy flash tftp filename
Маршрутизатор выведет приглашения к вводу IP-адреса TFTP- сервера и имени загрузочного образа, который должен быть скопирован на сервер. Ниже приведен пример вывода этой команды, в котором используются IP-адрес 131.108.10.6 и имя файла ic92130n.
ПроблемаПроблемаНеисправность аппаратных средств маршрутизатораНеисправность аппаратных средств маршрутизатораРешение
Проблема
Проблема
Неисправность аппаратных средств маршрутизатора
Неисправность аппаратных средств маршрутизатора
IP address of remote host [255.255.255.255]? 131.108.10.6
Name of file to copy []? ic92130n
writing ic92130n !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! router#
Шаг 9. Проверьте регистр конфигурации с использованием ехес-команды show version. Выполните настройку маршрутизатора на загрузку из флэш-памяти.
Шаг 10. Воспользуйтесь привилегированной exec-командой show runningconfig, чтобы определить, включает ли конфигурация маршрутизатора глобальную команду конфигурации boot system flash в правильном порядке относительно других команд начальной загрузки системы boot system.
Примечание. Глобальные команды конфигурации boot system сохраняются в порядке их ввода. Команда, введенная в последнюю очередь, находится в конце списка. Чтобы ознакомиться с рекомендациями по выбору последовательности команд, см. выше раздел “Надежные методы начальной загрузки".
Шаг 11. Выполните настройку команды boot system flash, если она отсутствует. Убедитесь в том, что команды boot system заданы в конфигурации в правильном порядке. Сохраните внесенные изменения с помощью команды copy running-config startup-config. Для этого применяется следующая синтаксическая конструкция (только для маршрутизаторов ряда Cisco 7000, Cisco 7200 и Cisco 7500): copy running-config {rep | startup-config | tftp | file-id^
Описание синтаксиса
rep. Указывает, что операция копирования на сетевой сервер должна быть выполнена с помощью протокола RCP.
startup-config. Указывает конфигурацию, используемую для инициализации в качестве адресата операции копирования. Это ключевое слово нельзя использовать в маршрутизаторах ряда Cisco 4500
tftp. Указывает TFTP-сервер в качестве адресата операции копирования.
file-id. Указывает в качестве адресата операции копирования устройство и имя файла, device: filename. Параметр device является необязательным, но при его использовании должно быть задано двоеточие (:).
Шаг 12. Введите привилегированную exec-команду reload, чтобы перезапустить маршрутизатор
Выполните поиск неисправностей аппаратных средств маршрутизатора, как было описано выше в этой главе.
Начальная загрузка: маршрутизатор частично загружается из флэш-памяти и отображает приглашение процедуры начальной загрузки
Признак неисправности. При загрузке пользователем маршрутизаторов ряда Cisco 2000, Cisco 2500, Cisco 3000 или Cisco 4000 из флэш-памяти процесс загрузки останавливается и на консоли отображается приглашение этапа загрузки router(boot )>. Кроме того, маршрутизатор не обеспечивает маршрутизацию, хотя exec-команды, по- видимому, выполняются.
В табл. 3.9 неисправности,
кратко перечислены проблемы, которые могут вызвать этот признак и описаны решения этих проблем.
| Таблица 3.9.
Начальная загрузка: маршрутизатор частично загружается из флэш-памяти и отображает приглашение процедуры;
Проблема
начальной загрузки.:
Решение
Во флэш- памяти отсутствует загрузочный образ системы
Шаг 1. Воспользуйтесь exec-командой show flash, чтобы определить, имеется ли загрузочный образ во флэш-памяти.
Шаг 2. Если загрузочный образ во флэш-памяти отсутствует, воспользуйтесь привилегированной exec-командой copy tftp flash, чтобы скопировать загрузочный образ системы с TFTP-сервера во флэш-память маршрутизатора. Ниже приведен пример использования команды copy tftp flash, router# copy flash tftp filename
Маршрутизатор выведет приглашения к вводу IP-адреса TFTP- сервера и имени загрузочного образа, который должен быть скопирован на сервер. Ниже приведен пример вывода этой команды, в котором используются IP-адрес 131.108.10.6 и имя файла 1с92130п.
IP address of remote host [255.255.255.255]? 131.108.10.6
Name of file to copy []? ic92130n
writing ic92130n 111111111111111IIII1111111111! router#
Шаг 3. Введите привилегированную ехес-команду reload, чтобы перезагрузить маршрутизатор.
Синтаксис
Ниже показана синтаксическая структура команды reload.
reload [text] | [in [hh:]mm [text]] | [at hh:mm [month day | day month] [text]] | [cancel]
Примеры
В следующем примере показано, как воспользоваться командой reload для немедленной перезагрузки программного обеспечения маршрутизатора.
Router# reload
В следующем примере показано, как воспользоваться командой reload для перезагрузки программного обеспечения маршрутизатора через 10 минут.
Проблема
Решение
Router# reload in 10
Router# Reload scheduled for 11:57:08 PDT Eri Apr 21 1996 (in 10 minutes)
Proceed with reload? [confirm]
Router#
Отсутствие глобальной команды конфигурации boot system flash
Шаг 1. Воспользуйтесь привилегированной ехес-командой show runningconfig, чтобы определить, включает ли конфигурация запись глобальной команды конфигурации boot system flash. Определите с помощью привилегированной exec-команды show startup-config, включена ли команда boot system flash в конфигурацию, сохраненную в энергонезависимом ОЗУ.
Шаг 2. Проверьте последовательность расположения команд boot system. Чтобы ознакомиться с рекомендациями по выбору последовательности команд, см. выше раздел “Надежные методы начальной загрузки".
Шаг 3. Введите дополнительно команду boot system flash или переупорядочьте команды boot system в случае необходимости.
Шаг 4. Сохраните изменения конфигурации в энергонезависимом ОЗУ с использованием привилегированной exec-команды copy runningconfig startup-config. Ниже показана применяемая для этого синтаксическая структура (только маршрутизаторы ряда Cisco 7000, Cisco 7200 и Cisco 7500).
copy running-config {rep | startup-config | tftp | file-id} Описание синтаксиса
rep. Указывает, что операция копирования на сетевой сервер должна быть выполнена с использованием протокола RCP.
startup-config. Указывает конфигурацию, используемую для инициализации в качестве адресата операции копирования. Это ключевое слово нельзя использовать в маршрутизаторах ряда Cisco 4500.
tftp. Указывает в качестве адресата операции копирования TFTP- сервер.
file-id. Указывает в качестве адресата операции копирования устройство и имя файла, device: filename. Параметр device является необязательным, но при его использовании должно быть задано двоеточие (:)
Неправильно настроенный регистр конфигурации
Используйте exec-команду show version, чтобы проверить установку регистра конфигурации. Убедитесь в том, что он настроен на загрузку из флэш- памяти. Обратитесь к инструкции по монтажу и техническому обслуживанию аппаратных средств для ознакомления с дополнительными сведениями о параметрах настройки регистра конфигурации
Начальная загрузка: маршрутизатор не может загрузиться по сети от TFTP-сервера
Признак неисправности. Маршрутизатор не может загрузиться от TFTP-сервера. Попытка получения маршрутизатором загрузочного образа системы оканчивается неудачей.
Ниже приведен пример вывода на экран консоли при завершившемся неудачей сеансе начальной загрузки по сети.
Booting gs3-bfx[failed]
В табл. 3.10 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Таблица 3.10.
Начальная загрузка: маршрутизатор не может загрузиться § ' по сети отTFTP-сервера’<
Проблема
Решение
Сеть разъединена или изолирована
Шаг 1. Загрузите маршрутизатор из ПЗУ или флэш-памяти, если это возможно.
Шаг 2. Воспользуйтесь ехес-командой ping, чтобы отправить сообше- ние по широковещательному адресу (255.255.255.255).
Шаг 3. При отсутствии ответа от сервера воспользуйтесь ехес-командой show агр, чтобы найти в таблице ARP запись, которая относится к серверу.
Шаг 4. Воспользуйтесь ехес-командой show ip route для просмотра таблицы IP-маршрутизации. Ищите в таблице запись, которая относится к сети или подсети сервера.
Пример вывода на дисплей
Ниже приведен пример вывода команды show ip route при вызове ее на выполнение без указания адреса.
Router# show ip route
Codes; I - IGRP derived, R - RIP derived, 0 - OSPF derived C - connected, S - static, E - EGP derived, В - BGP derived candidate default route, IA - OSPF inter area route Gateway of last resort is 131.119.254.240 to network 129.140.0.0
0 E2 150.150.0.0 [160/5] via 131.119.254.6, 0:01:00, Ethernet2
E 192.67.131.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2
0 E2 192.68.132.0 [160/5] via 131.119.254.6, 0:00:59, Ethernet2
0 E2 130.130.0.0 [160/5] via 131.119.254.6, 0:00:59, Ethernet2
E 128.128.0.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2
E 129.129.0.0 [200/129] via 131.119.254.240, 0:02:22, Ethernet2
Проблема
Решение
Е 192.65.129.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2
Если путь к серверу начальной загрузки существует, то причиной нарушения загрузки не является разъединенная сеть. А если путь отсутствует, то, прежде чем предпринимать повторную попытку начальной загрузки по сети, необходимо обеспечить доступ к TFTP-серверу
Остановлен
Т FTP-сервер
Шаг 1. Проверьте, работоспособен ли TFTP-сервер. Для этого установите соединение по протоколу ТЕТР с компьютера, на котором находится сервер начальной загрузки, непосредственно с этим сервером. Если TFTP-сервер функционирует, то соединение будет установлено успешно.
Шаг 2. Если TFTP-сервер не функционирует, инициализируйте его. Процесс инициализации зависит от типа сервера начальной загрузки. Для использования сервера BSD UNIX проверьте файл /etc/inetd.conf. Если в этом файле отсутствуют данные, касающиеся TFTP-сервера, введите соответствующую строку и выполните команду, которая вызывает перезагрузку сервером inetd его файла конфигурации
Неправильно указан каталог, в котором находится загрузочный образ маршрутизатора
Шаг 1. Рассмотрите файл конфигурации сервера, чтобы определить, указывает ли он на каталог, в котором находится загрузочный образ маршрутизатора.
Шаг 2. В случае необходимости переместите образ маршрутизатора в нужный каталог.
Шаг 3. Убедитесь в том, что к каталогу /tftpboot может быть получен доступ по сети
Неправильно установлены права доступа к файлу загрузочного образа системы маршрутизатора
Шаг 1. Проверьте права доступа к файлу загрузочного образа системы.
Шаг 2. В случае необходимости измените права доступа к файлу. На сервере начальной загрузки UNIX установите права доступа к файлу так, чтобы владелец имел право на чтение/запись, группа — право на чтение и все прочие пользователи — право на чтение (в системе UNIX для установки таких прав доступа применяется команда chmod 644 filename)
Неправильный протокольный адрес
Шаг 1. Проверьте файл конфигурации сервера, чтобы убедиться в том, что в нем правильно указан IP-адрес хоста.
Шаг 2. Откорректируйте файл конфигурации, если он содержит неправильную информацию
Отсутствует или неправильно задана спецификация шлюза, применяемого по умолчанию
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра конфигурации маршрутизатора. Проверьте наличие в составе конфигурации глобальной команды конфигурации ip default-gateway, которая определяет шлюз, применяемый по умолчанию.
Проблема
Решение
Синтаксис
ip default-gateway ip-address
Описание синтаксиса
• ip-address — IP-адрес маршрутизатора.
Шаг 2. Если эта команда отсутствует, введите ее в конфигурацию. А если эта команда имеется, убедитесь в том, что в ней указан правильный IP-адрес
Неправильная настройка команды начальной загрузки системы
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра конфигурации маршрутизатора. Проверьте, задан ли в маршрутизаторе адрес сервера начальной загрузки (IP- адрес TFTP-сервера или МАС-адрес МОР-сервера).
Шаг 2. Если адрес задан неправильно, введите правильный адрес сервера начальной загрузки с помощью глобальной команды конфигурации boot system
Указано неправильное имя файла
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра конфигурации маршрутизатора. Проверьте, правильно ли задано в маршрутизаторе имя файла начальной загрузки.
Шаг 2. Убедитесь в том, что имя файла указано правильно. В случае необходимости измените имя файла. Ознакомьтесь с документацией хоста, чтобы получить дополнительные сведения о том, как должно быть установлено имя загрузочного образа системы на ТЕТР-сервере.
Шаг 3. Некоторые версии ПЗУ чувствительны к регистру. Попытайтесь изменить регистр символов имени файла. Для получения дополнительной информации обратитесь к представителю службы технической поддержки
Неправильная установка регистра конфигурации
Для выполнения начальной загрузки по сети с сервера необходимо правильно установить регистр конфигурации. Конкретная настройка конфигурации для начальной загрузки по сети зависит от платформы, на которой выполняется начальная загрузка.
Шаг 1. Проверьте установку регистра конфигурации для конкретной системы.
Шаг 2. Определите, должна ли выполняться начальная загрузка по сети с TFTP-сервера вручную или автоматически.
Для выполнения начальной загрузки по сети вручную необходимо установить значение регистра конфигурации, равное 0x0; в ином случае будет выполняться автоматическая начальная загрузка по сети с использованием имени загрузочного образа системы, применяемого по умолчанию, или имени загрузочного образа, указанного в глобальной команде конфигурации boot system.
Чтобы получить дополнительные сведения о том, как выполняется настройка регистра конфигурации, обратитесь к руководствам по настройке операционной системы Cisco IOS и к справочникам по командам, а также ознакомьтесь с документацией по монтажу и техническому обслуживанию аппаратных средств
Начальная загрузка: маршрутизатор не может загрузиться по сети от другого маршрутизатора
Признак неисправности. Маршрутизатор не может загрузиться должным образом при начальной загрузке с другого маршрутизатора, который действует в качестве TFTP-сервера.
Примечание
Эта неисправность может быть вызвана любой из проблем, описанных в разделах настоящей главы, касающихся начальной загрузки по сети. В данном разделе в основном рассматриваются проблемы, возникающие при использовании маршрутизатора, действующего в качестве TFTP-сервера.
В табл. 3.11 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
| Таблица 3.11. Начальная загрузка: маршрутизатор не может загрузиться i
J; . -по сети с другого маршрутизатора. ■j
Проблема
Решение
Отсутствует или неправильно задана глобальная команда конфигурации tftp-server
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig, чтобы определить, имеется ли глобальная команда конфигурации tftp-server system и правильно ли она задана.
Шаг 2. В случае необходимости введите или откорректируйте в маршрутизаторе, действующем в качестве TFTP-сервера, глобальную команду конфигурации tftp-server system. Задайте имя файла во флэш-памяти
Неполный загрузочный образ во флэш- памяти
Воспользуйтесь exec-командой show flash, чтобы определить, является ли загрузочный образ полным. В выводе этой команды может быть указано, что загрузочный образ удален, а также может быть указана причина этого.
Ниже приведен пример вывода команды show flash, который содержит указание на то, что загрузочный образ удален.
babar# show flash
2048К bytes of flash memory sized on embedded flash.
File name/status
xx-k.914-0.16
xx3-confg
xx-k.91-4.2 [deleted] [invalid cksum] [0/2097152 bytes free/total]
Неправильный загрузочный образ во флэш-памяти
Шаг 1. При попытке выполнить начальную загрузку маршрутизатора с использованием неправильного загрузочного образа выводится сообщение "wrong system software". В этом случае загрузка маршрутизатора осуществляется с применением режима ROMmon.
Ниже приведен пример того, как выглядит вывод, полученный в режиме ROMmon, после попытки загрузить неправильный образ.
ПроблемаРешение
b gs3-klingon 131.108.9.40
Booting gs3-klingon from
131.108.9.40:!!! !!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!! । । I 111 111 11 11 111
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 11111111110111111111111111111111111111 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!
11 111 11111 111 111
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 2056792/3394950 bytes]
F3: 2011628+45132+192972 at 0x1000
Wrong system software for this hardware
Шаг 2. Получите правильный загрузочный образ. В случае необходимости обратитесь к представителю службы технической поддержки, чтобы определить, какой загрузочный образ является правильным.
Шаг 3. После определения правильного загрузочного образа воспользуйтесь привилегированной exec-командой copy tftp flash для выборки загрузочного образа
Начальная загрузка: тайм-ауты и пакеты с нарушением порядка следования препятствуют выполнению загрузки по сети
Признак неисправности. При наличии тайм-аутов или пакетов, поступающих с нарушением порядка следования, успешная начальная загрузка по сети иногда становится невозможной. Число тайм-аутов и пакетов с нарушением порядка следования, показанное на дисплее консоли маршрутизатора, может изменяться.
Ниже приведен пример, показывающий сеанс начальной загрузки по сети, в котором наблюдалось слишком много тайм-аутов и пакетов с нарушением порядка следования.
Booting gs3-bfx from 131.108.1.123: 10.О!.0..О!!!ООО.О!!.0.О
Начальная загрузка клиентского маршрутизатора может быть выполнена успешно и в такой ситуации. Тем не менее чрезмерное количество тайм-аутов и пакетов с нарушением порядка следования указывает на проблемы в сети, и при таких условиях начальная загрузка по сети (включая доступ к сетевым службам) может быть нарушена.
В табл. 3.12 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Таблица 3.12. Загрузка: тайм-ауты и пакеты с нарушением порядка следования препятствуют выполнению загрузки по сети
Проблема
Решение
Достигнут предел пропускной способности соединения
Шаг 1. Загрузите маршрутизатор из ПЗУ и выполните эхо-тестирование TFTP-сервера. Определите, наблюдаются ли тайм-ауты и пакеты с нарушением порядка следования.
Шаг 2. Проверьте концентраторы локальной сети, чтобы определить, не наблюдается ли чрезмерное число коллизий в той же сети. Если число коллизий слишком велико, то может потребоваться реорганизация топологии сети для уменьшения числа коллизий.
Шаг 3. Выполните exec-команду show interfaces в маршрутизаторах, находящихся на пути к загрузочному серверу, или поместите сетевой анализатор между клиентским маршрутизатором и сервером. Определите число потерянных пакетов и ошибок вывода.
Шаг 4. Если относительное количество потерянных пакетов составляет примерно 15% или более от общего объема трафика или наблюдаются какие-либо ошибки вывода, то проблема может быть вызвана затором в сети.
Шаг 5. Дождитесь снижения интенсивности трафика, прежде чем предпринять очередную попытку выполнить начальную загрузку маршрутизатора по сети. А если интенсивность трафика нс снижается, попытайтесь увеличить пропускную способность сети или переместить сервер ближе к загружаемому маршрутизатору
Соединение разорвано
Шаг 1. Проверьте возможность установления связи по сети между загружаемым маршрутизатором и сервером начальной загрузки с помощью exec-команд trace или ping.
Шаг 2. Если обнаружен разрыв в сети, восстановите канал и попытайтесь снова выполнить начальную загрузку по сети
Начальная загрузка: недействительные маршруты препятствуют выполнению загрузки по сети
Признак неисправности. В связи с наличием недопустимых маршрутов успешная начальная загрузка по сети становится невозможной. Если маршрутизатор передает пакеты по недействительному пути, то на его консоли отображается примерно такое сообщение:
Booting gs3-bfx!OOOO[timed out]
Booting gs3-bfx!.0.0.0.0[timedout]
Booting gs3-bfx!!!!!!!!! '0000000000[timedout]
В некоторых случаях от сервера начинает поступать ответ, но последовательность начальной загрузки по сети все равно нарушается. Загрузочное сообщение выглядит примерно так:
Booting gs3-bfx![failed]
В табл. 3.13 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
| Таблица 3.13. Начальная загрузка: недействительные маршруты
I ' препятствуют выполнению загрузки по сети
ПроблемаРешение
Недопустимые маршруты к смежным маршрутизаторамНедопустимые маршруты к смежным маршрутизаторамШаг 1. Проверьте, можно ли выполнить эхо-тестирование сервера со смежных маршрутизаторов с помощью команды ping.
Недопустимые маршруты к смежным маршрутизаторам
Недопустимые маршруты к смежным маршрутизаторам
Шаг 2. Воспользуйтесь exec-командой trace для определения маршрута к серверу.
Шаг 3. Примените привилегированную exec-команду show агр для проверки таблиц ARP или привилегированную exec-команду show ip route для просмотра таблицы 1Р-маршрутизации. Убедитесь в том, что сервер находится в списке и таблица маршрутизации содержит соответствующие записи.
Шаг 4. Воспользуйтесь привилегированными exec-командами clear агр- cache и clear ip-route, чтобы вынудить маршрутизатор вновь заполнить свои таблицы ARP и таблицы маршрутизации.
Проблемы, вызванные наличием нескольких маршрутовПроблемы, вызванные наличием нескольких маршрутовШаг 5. Снова попытайтесь выполнить начальную загрузку маршрутизатора по сети
Проблемы, вызванные наличием нескольких маршрутов
Проблемы, вызванные наличием нескольких маршрутов
Шаг 1. Закройте все лишние интерфейсы, кроме того интерфейса, через который вы намереваетесь выполнить начальную загрузку маршрутизатора по сети.
Шаг 2. Выполните команду конфигурации интерфейса no ip proxy-arp на всех смежных маршрутизаторах, чтобы лишить их способности предоставлять ответы кэширующего протокола ARP.
Соблюдайте осторожность при внесении этих изменений, поскольку они могут вызвать проблемы при прохождении другого сетевого трафика.
Если вы не хотите отменять режим формирования ответов кэширующего протокола ARP, выполните загрузку маршрутизатора из ПЗУ и настройку глобальной команды конфигурации ip default-gateway.
Шаг 3. Снова попытайтесь выполнить начальную загрузку маршрутизатора по сети
Начальная загрузка: клиентские запросы ARP завершаются по тайм-ауту во время загрузки по сети
Признак неисправности. Во время начальной загрузки по сети клиент ARP запрашивает тайм-аут. Если маршрутизатор не получает ответ ARP, то на консоли отображается примерно такое сообщение:
Booting gs3-bfx[timed out]
В табл. 3.14 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Таблица 3.14. Клиентские запросы ARP завершаются по тайм-ауту во
время начальной загрузки по сети'Z
Проблема
Рашение
В промежуточных маршрутизаторах разрешена фильтрация ARP-запросовВ промежуточных маршрутизаторах разрешена фильтрация ARP-запросовВспомогательный IP-адрес в промежуточном маршрутизаторе отсутствует или был неправильно заданВспомогательный IP-адрес в промежуточном маршрутизаторе отсутствует или был неправильно заданШаг 1. Выполните начальную загрузку маршрутизатора из ПЗУ.
В промежуточных маршрутизаторах разрешена фильтрация ARP-запросов
В промежуточных маршрутизаторах разрешена фильтрация ARP-запросов
Вспомогательный IP-адрес в промежуточном маршрутизаторе отсутствует или был неправильно задан
Вспомогательный IP-адрес в промежуточном маршрутизаторе отсутствует или был неправильно задан
Шаг 2. Убедитесь в том, что возможно эхо-тестирование сервера с маршрутизатора с помощью команды ping.
Шаг 3. Воспользуйтесь привилегированной exec-командой copy runningconfig tftp для проверки возможности установить соединение с сервером по протоколу TFTP.
Шаг 4. В случае успешного выполнения описанных выше шагов проверьте конфигурацию промежуточного маршрутизатора с помощью ехес- команды show агр.
Шаг 5. Разрешите применение привилегированной exec-команды debug агр, чтобы определить, вырабатываются ли ответы кэширующего протокола ARP.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и уменьшения числа пользователей. Проведение отладки в эти периоды способствует снижению вероятности того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 6. Если смежный маршрутизатор не передает ответы кэширующего протокола ARP и его конфигурация содержит команду конфигурации интерфейса no ip proxy-arp, отмените фильтрацию ARP, удалив соответствующую запись.
Обратите внимание на то, что ответы кэширующего протокола ARP разрешены по умолчанию.
Шаг 7. Если необходимо включить в конфигурацию смежных маршрутизаторов запись no ip proxy-arp, воспользуйтесь глобальной командой конфигурации ip default-gateway в маршрутизаторе для задания шлюза, применяемого по умолчанию
Шаг 1. Проверьте конфигурацию всех маршрутизаторов в пути между клиентским маршрутизатором и сервером. Убедитесь в том, что во всех промежуточных маршрутизаторах задан вспомогательный 1Р-адрес, который указывает на TFTP-сервер.
Синтаксис
ip helper-address address
Описание синтаксиса
• address. Широковещательный адрес или адрес хоста назначения, который должен использоваться при перенаправлении широковещательных сообщений UDP. Каждый интерфейс может иметь несколько вспомогательных адресов.
Проблема
Решение
Шаг 2. В случае необходимости введите вспомогательные адреса с помощью команды конфигурации интерфейса ip helper-address.
Если применяется одноадресатная передача запросов на сервер, то вспомогательный IP-адрес не должен использоваться, но если выполняется широковещательная рассылка по адресу 255.255.255.255 (которая происходит, если в запросе не указан IP-адрес сервера), введите команду ip helper-address в конфигурацию интерфейса смежного маршрутизатора, применяемого при широковещательной рассылке во время начальной загрузки по сети
Начальная загрузка: во время загрузки по сети возникает ошибка “неопределенный загрузочный модуль”
Признак неисправности. Во время загрузки по сети возникает ошибка “неопределенный загрузочный модуль”. На экране консоли появляется сообщение об ошибке "undefined load module", и загрузка маршрутизатора завершается неудачей.
В табл. 3.15 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
! Таблица 3.15. Начальная загрузка: во время загрузки по сети возникает '
Проблема
ошибка “неопределенный загрузочный модуль”,
Решение
Несовпадение имени файла
Шаг 1. При начальной загрузке вручную обратитесь к руководству пользователя маршрутизатора для ознакомления с допустимым форматом командной строки.
Шаг 2. Проверьте файл конфигурации маршрутизатора. Сравните имя файла, заданное в записи глобальной команды конфигурации boot system filename [address], с фактически используемым именем файла filename загрузочного образа маршрутизатора. Убедитесь в том, что они совпадают.
Шаг 3. Если имена файлов различаются, измените имя в файле конфигурации. Помните, что в спецификации глобальной команды конфигурации boot system должно использоваться имя файла загрузочного образа маршрутизатора, а в глобальных командах конфигурации boot host и boot network — имя файла конфигурации
Начальная загрузка: маршрутизатор зависает после инициализации режима ROMmon
Признак неисправности. При загрузке маршрутизаторов ряда Cisco 7000, маршрутизатора AGS+, ACS, ASM-CS, MGS, IGS или CGS из ПЗУ система зависает после инициализации режима ROMmon.
В табл. 3.16 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Таблица 3.16. Начальная загрузка: маршрутизатор зависает после :. / инициализации режима ROMmon
Проблема
Решение
Неправильно установлен объем программируемого ПЗУ
Шаг 1. Выключите питание системы.
Шаг 2. Проверьте перемычки установки объема программируемого ПЗУ. Обратитесь к документации по монтажу и техническому обслуживанию аппаратных средств маршрутизатора для определения правильной установки.
Шаг 3. В случае необходимости переставьте перемычки
Неправильно установлен регистр конфигурации
Шаг 1. Проверьте установки конфигурации (перемычки загрузочного ПЗУ и конфигурацию программного обеспечения). Если не установлена перемычка по адресу бита 0 и не определены другие поля загрузки, откорректируйте конфигурацию системы для обеспечения ее загрузки должным образом.
Шаг 2. Чтобы обеспечить надлежащую начальную загрузку маршрутизатора, выполните одно из следующих действий.
Настройте регистр конфигурации программного обеспечения маршрутизатора с помощью глобальной команды конфигурации config-register value. (Это действие относится к платформам IGS, Cisco 2500, Cisco 3000 и Cisco 7000 в программируемом ПЗУ в которых записан загрузочный образ операционной системы Cisco 1OS 10.0 или более поздних выпусков.)
Установите перемычку загрузочного ПЗУ для обеспечения начальной загрузки.
Введите соответствующие глобальные команды конфигурации boot system для загрузки системы.
Установите бит 0 в значение 1, чтобы обеспечить загрузку из ПЗУ.
Чтобы получить дополнительные сведения о том, как выполняется настройка маршрутизатора на использование различных опций начальной загрузки, обратитесь к руководствам по настройке операционной системы Cisco IOS и к справочникам по командам, а также ознакомьтесь с документацией по монтажу и техническому обслуживанию аппаратных средств
Начальная загрузка: маршрутизатор не выходит из режима ROMmon
Признак неисправности. Маршрутизатор не выходит из режима ROMmon. После начальной загрузки маршрутизатора из ПЗУ система переходит в режим ROMmon, но не загружает весь загрузочный образ системы.
В табл. 3.17 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Таблица 3.17. Начальная загрузка: маршрутизатор не выходит из режима , ; 'ROMmon
Проблема
Решение
Неправильно установлен регистр конфигурации
Шаг 1. В приглашении к вводу команд режима ROMmon (>) введите Ь, чтобы выполнить начальную загрузку системы.
Шаг 2. Если в энергонезависимом ОЗУ имеется информация о конфигурации, система отображает сообшение vacant. Нажмите клавишу <Enter>, чтобы продолжить загрузку.
Шаг 3. Если в энергонезависимом ОЗУ отсутствует информация о конфигурации, появляется меню начальной установки. Пропустите этап выполнения начальной установки.
Шаг 4. Воспользуйтесь exec-командой show version для определения значения регистра конфигурации.
Шаг 5. Проверьте правильность установки регистра конфигурации. По умолчанию применяется установка 0x101, которая отменяет действие клавиши <Вгеак> и вынуждает маршрутизатор выполнять загрузку из ПЗУ. Характерным признаком неправильной установки является наличие значения 0 в младшем бите (например, 0x100).
Для ознакомления с подробными сведениями о настройке регистра конфигурации обратитесь к документации по монтажу и техническому обслуживанию аппаратных средств маршрутизатора
В процессе выполнения загрузки была нажата клавиша <Вгсак>
В приглашении к вводу команд режима ROMmon введите с. чтобы разрешить выполнение дальнейшей загрузки маршрутизатора
В процессе загрузки был подсоединен или отсоединен кабель консоли или произошло отключение и повторное включение питания консоли
Шаг 1. Нажмите клавишу <Entcr> и дождитесь приглашения к вводу команд режима ROMmon (>).
Шаг 2. Если появится приглашение к вводу команд режима ROMmon, введите с, чтобы продолжить процесс начальной загрузки
Начальная загрузка: искаженный вывод при загрузке из ПЗУ
Признак неисправности. При загрузке из ПЗУ маршрутизатор выводит на консоль неразборчивый текст.
В табл. 3.18 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Таблица 3.18. Начальная загрузка: искаженный вывод при загрузке из ПЗУ
ПроблемаРешение
Неправильная Шаг 1. Воспользуйтесь меню начальной установки режима ROMmon, установка скоро-чтобы проверить установку скорости канала связи с терминалом,
сти терминала
Проблема
Решение
Шаг 2. Проверьте скорость терминала, установленную в маршрутизаторе в соответствии со значением регистра конфигурации (значение по умолчанию — 9600 бод, 8 битов данных, 2 стоповых бита и отсутствие контроля четности).
Шаг 3. Если скорость терминала, применяемая в режиме ROMmon, не совпадает со скоростью, заданной в маршрутизаторе, внесите соответствующие исправления.
Обратитесь к инструкции по монтажу и техническому обслуживанию аппаратных средств для ознакомления с дополнительными сведениями об установке режима ROMmon
Неисправность аппаратных средств маршрутизатора
Проверьте, исправны ли все аппаратные средства, включая соединительные кабели (обрывы проводов), разъемы (плохо закрепленные контакты), порты маршрутизатора и т.д. Дополнительную информацию см. выше, в разделе “Поиск неисправностей аппаратных средств"
Начальная загрузка: возникновение локальных таймаутов при загрузке из ПЗУ
Признак неисправности. При загрузке из ПЗУ вырабатываются сообщения об ошибках "Local timeout". Процесс начальной загрузки маршрутизатора не может быть успешно завершен, и переход в режим ROMmon не происходит.
В табл. 3.19 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
! Таблица 3.19. Начальная загрузка: возникновение локальных тайм-аутов iпри загрузке из ПЗУ:
Проблема
Решение
Нарушение в работе программируемого ПЗУ
Обычно эта проблема возникает только непосредственно после замены программируемых ПЗУ системы.
Шаг 1. Отключите питание системы.
Шаг 2. Осмотрите каждую микросхему программируемого ПЗУ и убедитесь в том, что каждая из них правильно вставлена в соответствующее гнездо (с установочными метками, выровненными должным образом).
Шаг 3. Если какой-то контакт изогнут, попытайтесь его аккуратно выпрямить. Снова установите программируемое ПЗУ и включите питание системы. Если контакт сломан, программируемое ПЗУ необходимо заменить.
Шаг 4. Если программируемое ПЗУ при установке было развернуто в противоположном направлении и на него уже подавалось питание, то оно повреждено и требует замены.
Шаг 5. Если локальные тайм-ауты не прекращаются, обратитесь к представителю службы технической поддержки
Установки управления потоком данных, применяемые на терминале, не согласуются с управляющими сигналами по стандарту EIA/TIA-232, которые поддерживаются портом консоли сервера доступа (с разъемами от RJ-45 до DB-25)Установки управления потоком данных, применяемые на терминале, не согласуются с управляющими сигналами по стандарту EIA/TIA-232, которые поддерживаются портом консоли сервера доступа (с разъемами от RJ-45 до DB-25)Неисправность аппаратных средствНеисправность аппаратных средств
Установки управления потоком данных, применяемые на терминале, не согласуются с управляющими сигналами по стандарту EIA/TIA-232, которые поддерживаются портом консоли сервера доступа (с разъемами от RJ-45 до DB-25)
Установки управления потоком данных, применяемые на терминале, не согласуются с управляющими сигналами по стандарту EIA/TIA-232, которые поддерживаются портом консоли сервера доступа (с разъемами от RJ-45 до DB-25)
Неисправность аппаратных средств
Неисправность аппаратных средств
Начальная загрузка: не функционирующее терминальное соединение с ненастроенным сервером доступа
Признак неисправности. Терминал, подключенный к ненастроенному серверу доступа, не отвечает на введенные команды. Терминал, подключенный к порту консоли ненастроенного сервера доступа Cisco, отображает заголовки начальной загрузки и показывает, что началась процедура загрузки, но пользователь не может вводить команды с клавиатуры терминала.
В табл. 3.20 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Г"" “ ~"I
Таблица 3.20. Начальная загрузка: не отвечающее терминальное .. ।
Lсоединение с ненастроенным сервером доступа\
ПроблемаРешение
Шаг 1. Проверьте, выполнена ли настройка конфигурации управления потоком данных на терминале.
Шаг 2. Отмените все средства управления потоком данных на терминале. Если средства управления потоком данных разрешены, терминал неопределенно долго ожидает сигнала CTS, поскольку порт консоли RJ-45 на сервере доступа не подтверждает сигналы CTS.
Чтобы получить информацию о том, как проверить настройку и отменить управление потоком данных на конкретном терминале, обратитесь к документации, предоставленной изготовителем терминала.
Шаг 3. Иным образом, можно подать на вывод сигнала CTS высокий потенциал, чтобы перевести его в активное состояние. Найдите неиспользуемый сигнальный вывод, на котором, как известно, имеется высокий потенциал, и соедините его перемычкой с выводом сигнала CTS. На терминал поступят данные, что сигнал CTS подтвержден (а это указывает на то, что сервер доступа готов получать данные), поэтому терминал разблокирует ввод информации.
Шаг 4. Если сервер доступа уже настроен, можно применить другое решение: подключить терминал к вспомогательному порту сервера доступа. Вспомогательный порт, в отличие от порта консоли, подтверждает сигналы CTS, и поэтому появляется возможность вводить данные с терминала. Но при использовании нового сервера доступа, не имеющего установленной конфигурации, такое решение неприемлемо, поскольку заставки режима начальной загрузки и сообщения процедуры начальной установки передаются только через порт консоли
Шаг 1. Проверьте, исправны ли все аппаратные средства, включая соединительные кабели (обрывы проводов), разъемы (плохо закрепленные контакты), порты сервера доступа и сам терминал.
Шаг 2. Замените все неисправные или чрезмерно изношенные аппаратные средства. Дополнительную информацию см. выше, в разделе “Поиск неисправностей аппаратных средств”
Запуск LAN-коммутаторов ряда Catalyst 6000
После подачи питания на LAN-коммутатор Cisco Catalyst 6000 должен произойти описанный ниже процесс загрузки.
System Bootstrap, Version 5.3(1)
Copyright (с) 1994-1999 by cisco Systems, Inc.
c6k_supl processor with 65536 Kbytes of main memory
Autoboot executing command: "boot bootflash:cat6000-sup.5-5-1.bin"
Uncompressing file:
[...]
fMiffitii
System Power On Diagnostics
DRAM Size 64 MB
Testing DRAMPassed
NVRAM Size 512 KB
Level2 Cache Present
System Power On Diagnostics Complete
Boot image: bootflash:cat6000-sup.5-5-1.bin
Running System Diagnostics from this Supervisor (Module 1)
This may take up to 2 minutes....please wait
Cisco Systems Console
2000 Jul 27 16:21:02 %SYS-1-SYS_ENABLEPS: Power supply 1 enabled
Enter password: 2000 Jul 27 16:21:05 %SYS-5-MOD_PWRON:Module 3 powered up
2000 Jul 27 16:21:11 %MLS-5-NDEDISABLED:Netflow Data Export disabled
2000 Jul 27 16:21:12 %MLS-5-MCAST_STATUS:IP Multicast Multilayer Switching is enabled
2000 Jul 27 16:21:12 %SYS-5-MOD_OK:Module 1 is online
2000 Jul 27 16:21:33 %SYS-5-MOD~OK:Module 3 is online
2000 Jul 27 16:21:45 %SYS-5-MOD_OK:Module 15 is online
Устранение неисправности коммутатора Catalyst 6000, связанной с искажением или отсутствием загрузочного образа
В настоящем разделе описано, как устранить неисправность коммутатора Catalyst 6000, связанную с искажением или отсутствием образа загрузчика (по данным с Web- узла корпорации Cisco).
Коммутаторы Catalyst 6000, работающие под управлением операционной системы Cisco IOS, имеют две области начальной загрузки из флэш-памяти. Область начальной загрузки из флэш-памяти в блоке управления содержит образ операционной системы IOS, а область в плате поддержки многоуровневой коммутации (MSFC — Multilayer Switch Feature Card) содержит образ boot loader загрузчика. Для эксплуата-
ции операционной системы IOS в коммутаторе Catalyst 6000 необходимо установить оба загрузочных образа.
Примечание
Образ загрузчика должен находиться в загрузочной флэш-памяти платы MSFC, а образ IOS может находиться в загрузочной флэш-памяти блока управления, плате флэш-памяти или на TFTP-сервере.
Если образ загрузчика в загрузочной флэш-памяти платы MSFC искажен или удален, то при следующей перезагрузке коммутатор переходит в режим ROMmon и пользователь не имеет возможности загрузить коммутатор для эксплуатации на нем программного обеспечения IOS.
Основные сведения, необходимые для использования процедуры устранения неисправности
Ниже приведены основные сведения, а также описаны ограничения, которые могут встретиться при использовании рассматриваемой процедуры. Ознакомьтесь с этими сведениями, чтобы ускорить выполнение процедуры устранения неисправности.
Операционная система коммутаторов семейства Catalyst 6000 представлена в виде одного образа операционной системы IOS, которая функционирует на коммутаторах семейства Catalyst 6000 и известна под названием собственной IOS коммутаторов Catalyst 6000. Далее эта операционная система именуется Catalyst 6000 IOS (или Cat IOS). Программное обеспечение операционной системы Catalyst 6000 OS представлено в виде образа, который поддерживает функции блока управления и все функции L2 (уровня 2) коммутатора. Этот образ при его использовании в сочетании с программным обеспечением IOS в плате MSEC часто называют гибридным образом, а в настоящей книге он именуется Catalyst 6000 OS (или Cat OS).
При начальной загрузке используются два процессора: процессор блока управления, или процессор коммутации (SP — Switch Processor), и процессор MSFC, или процессор маршрутизации (RP — Route Processor).
Если образ загрузчика отсутствует или искажен, то при каждой следующей перезагрузке или выключении, а затем включении питания коммутатор переходит в режим SP ROMmon.
Каждый процессор имеет собственный интерпретатор командного языка ROMmon (CLI — Command Language Interpreter).
В режиме SP ROMmon может быть выполнена загрузка образа Catalyst 6000 IOS или Catalyst 6000 OS из слота 0 или из загрузочной флэш-памяти. Если в системе, в которой перед этим применялся образ Cat IOS, загружается версия Cat OS, конфигурация коммутатора переустанавливается.
После загрузки образа Cat IOS на терминале появляется приглашение к вводу информации в режиме RP ROMmon. С другой стороны, после загрузки образа Cat OS можно переключиться на консоль RP ROMmon с помощью команды switch console.
Команды интерпретатора RP ROMmon CLI не позволяют обратиться к загрузочной флэш-памяти блока управления или к слоту 0.
Для загрузки образа загрузчика в загрузочную флэш-память платы MSEC можно применять два способа: с помошью маршрутизатора Cisco 4500 или 4700 или с использованием процедуры xmodem. Оба эти метода подробно рассматриваются в настоящем разделе.
При эксплуатации образа загрузчика в плате MSEC в режиме загрузки появляется приглашение к вводу информации MSEC Router (boot).
Необходимо отформатировать загрузочную флэш-память платы MSEC с применением команды, введенной после получения приглашения к вводу информации MSEC Router (boot).
После форматирования загрузочной флэш-памяти платы MSEC в память необходимо скопировать образ загрузчика. При попытке скопировать образ загрузчика необходимо учитывать предостережения, приведенные в следующем разделе.
Процедуры устранения неисправности
Для устранения описанной выше неисправности можно воспользоваться двумя методами.
Метод 1. Использование маршрутизатора Cisco 4500 или 4700 для копирования соответствующего образа загрузчика в микросхему SIMM загрузочной флэш- памяти платы MSEC.
Метод 2. Применение процедуры xmodem в сочетании с протоколом внеочередных сообщений ОО В (Out-of-Band) для загрузки образа загрузчика в загрузочную флэш-памяти платы MSEC. Для обеспечения возможности выполнения этой процедуры в блоке управления требуется образ блока управления Catalyst 6000 (Cat OS), если применяется версия загрузчика c6msfc-boot-mz. 120-7.ХЕ, или образ Catalyst IOS, если применяется версия c6msfc-boot-mz.120-7.ХЕ1. Образ загрузчика MSEC имеет объем около 1,8 Мбайт, и его загрузка занимает приблизительно 45 минут.
Второй метод должен применяться только в качестве процедуры восстановления после аварии с учетом следующих предостережений.
Если образ Cat OS эксплуатируется в блоке управления, а перед этим на коммутаторе эксплуатировался образ Cat IOS, то процедура xmodem не сохраняет текущую конфигурацию коммутатора.
Процедура xmodem не сохраняет загруженный образ в загрузочной флэш-памяти платы MSEC.
Процедура xmodem загружает и вызывает на выполнение загрузчик в плате MFSC и переводит его в режим начальной загрузки.
В загрузочном режиме необходимо отформатировать загрузочную флэш- память платы MSEC, прежде чем скопировать в нее образ загрузчика.
Необходимо правильно разместить образ загрузчика, если принято решение выполнить загрузку с помошью слота 0 блока управления.
Примечание
Подтверждено, что процедура xmodem может применяться в сочетании с программой Hyperterm системы Microsoft Windows и с программой mini.com системы Linux.
Если оба эти метода не позволяют добиться успеха, обратитесь в центр ТАС (Technical Assistance Center — центр технический поддержки) Cisco и запросите разрешение на возврат материалов (RMA — Return Material Authorization), которое дает право на получение новой микросхемы загрузочной флэш-памяти с записанным в ней необходимым загрузочным образом.
Примечание
Как было указано выше, можно использовать либо образ Cat OS, либо образ Cat IOS. Применение того или иного образа зависит от версии загрузчика, которую необходимо загрузить.
При использовании версии c6msfc-boot-mz. 120-7.ХЕ следует применять образ Cat OS, а при использовании версии загрузчика c6msfc-boot-mz.120-7.ХЕ1 или последующих версий можно применять образ Cat IOS. Применение версии c6msfc-boot-mz.120-7.XEl или последующих версий предоставляет значительные преимущества, поэтому следует в основном использовать эти версии. Во-первых, конфигурация коммутатора не будет потеряна в связи с тем, что в коммутатор придется загружать образ Cat OS. Во- вторых, не требуется выполнение нескольких лишних шагов, в результате чего процесс устранения неисправности занимает намного меньше времени.
Основное различие между этими версиями состоит в том, что одна из них предоставляет возможность обратиться к слоту 0 блока управления в режиме загрузки, а вторая— нет. После загрузки образа Cat IOS в блоке управления вы не сможете обратиться к слоту 0 до тех пор, пока не загрузите образ версии c6msfc-boot-mz.120-7.XEl или последующих версий.
Метод 1: процедура восстановления образа загрузчика с помощью маршрутизатора Cisco 4500/4700
Примечание
Плата MSEC в режиме ROMmon обеспечивает чтение данных из микросхемы флэш- памяти маршрутизатора 4500/4700. Но если эксплуатируется образ Cat IOS, плата MSEC не воспринимает формат данных в микросхеме флэш-памяти маршрутизатора 4500/4700. Прежде чем снова ввести в загрузочную флэш-память платы MSEC образ загрузчика, ее следует отформатировать в режиме загрузки. Ниже приведены типичные сообщения, возникающие при попытке чтения загрузочной флэш-памяти платы MSEC в процессе эксплуатации образа Cat IOS.
Плата MSEC в режиме ROMmon:
rommon 1 > dir bootflash:
File size Checksum File name
1597884 bytes (0xl861bc) 0x8334 c6msfc-boot-mz.120-7T.XEl.0.95.bin
Плата MSFC в режиме начальной загрузки:
Router(boot)# dir bootflash:
Directory of bootflash:/
1 -rw- 1877456 Jan 01 2000 00:08:25 c6msfc-bootdbg-mz
15990784 bytes total (14113200 bytes free)
Router (boot) if
Плата MSFC, в которой эксплуатируется образ Cat IOS:
IOS4C6K# dir bootflash:
SError opening bootflash:/ (Bad device info block)
Ниже описана процедура восстановления с применением маршрутизатора 4500/4700.
Шаг 1. Выньте микросхему загрузочной флэш-памяти из коммутатора Catalyst 6000 и поместите ее в маршрутизатор 4500/4700. Убедитесь в том, что микросхема флэш-памяти в выбранном вами слоте не содержит программное обеспечение IOS, под управлением которого работает маршрутизатор 4500/4700.
Важное примечание. После загрузки маршрутизатора 4500/4700 необходимо разбить флэш-память на разделы с учетом того, что загрузочная флэш-память в коммутаторе Catalyst 6000 имеет объем 16 Мбайт.
4500Router(config)# partition flash 2 8 16
4500Router(config)# end
4500Router#
00:07:30: %SYS-5-CONFIG I: Configured from console by console
4500Router# show flash
System flash directory, partition 1:
File Length Name/status
1 4512036 c4500-js-mz.112-17.P
2 3838296 c4500-j-mz.111-20
[8350460 bytes used, 38148 available, 8388608 total]
8192K bytes of processor board System flash (Read/Write)
System flash directory, partition 2:
No files in System flash
[0 bytes used, 16777216 available, 16777216 total]
16384K bytes of processor board System flash (Read/Write)
Шаг 2. Скопируйте образ загрузчика в соответствующий раздел системы.
4500Router# copy tftp flash
Partition Size Used Free Bank-Size State Copy Mode
1 8192K 8154K 37K 8192K Read/Write Direct
2 16384K OK 16384K 8192K Read/Write Direct
[Type ?<N0> for partition directory; ? for full directory; q to abort]
Which partition? [default = 1] 2
System flash directory, partition 2:
No files in System flash
[0 bytes used, 16777216 available, 16777216 total]
Address or name of remote host [255.255.255.255]? tftpserver
Source file name? c6msfc-boot-mz.120-7T.XEL0.95.bin
Destination file name [c6msfc-boot-mz.120-7T.XEl.0.95.bin]?
Accessing file 'c6msfc-boot-mz.120-7T.XEl.0.95.bin' on tftpserver...
Loading c6msfc-boot-mz.120-7T.XE1.0.95.bin .from 172.17.196.3 (via FastEthernetO): ! [OK]
Erase flash device before writing? [confirm]
Flash contains files. Are you sure you want to erase? [confirm]
Copy 'c6msfc-boot-mz.120-7T.XE1.0.95.bin' from server
as 'c6msfc-boot-mz.120-7T.XEl.0.95.bin' into Flash WITH erase?
[yes/no] yes
Erasing device...
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased Loading c6msfc-boot-mz.120-7T.XE1.0.95.bin from 172.17.196.3 (via FastEthernetO ):
!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 1599488/16777216 bytes]
Verifying checksum... OK (0xl3AF)
Flash copy took 00:00:08 [hh:mm:ss]
Шаг 3. Скопировав образ, снова поместите микросхему в тот же слот в коммутаторе Catalyst 6000.
Перед аварийным завершением работы системы раздел bootvar в коммутаторе Catalyst 6000 мог содержать следующую информацию:
C6000-IOS# sh bootvar
BOOT variable = sup-bootflash:c6sup-jsdbg-mz.120-6.5T.XE1.0.90.bin,1;
CONFIG_FILE variable does not exist
BOOTLDR variable = bootflash:c6msfc-boot-mz.120-6.5T.XE1.0.90.bin
Configuration register is 0x2
Если в коммутаторе не установлена переменная bootldr, то вы получите следующее сообщение и вам потребуется перевести коммутатор в рабочее состояние вручную:
System Bootstrap, Version 5.2(1)CSX
Copyright (c) 1994-1999 by cisco Systems, Inc.
c6k_supl processor with 65536 Kbytes of main memory
Autoboot: failed, BOOT string is empty rommon 1 >
Для перевода коммутатора в рабочее состояние вручную необходимо иметь образ Cat OS или Cat IOS в загрузочной флэш-памяти блока управления или в слоте 0. Для вывода на экран перечня содержимого слота 0 или загрузочной флэш-памяти введите, соответственно, команду dir slotO: или dir bootflash:. Ниже приведен пример полученных данных.
System Bootstrap, Version 5.2(1)CSX
Copyright (c) 1994-1999 by cisco Systems, Inc.
c6k_supl processor with 65536 Kbytes of main memory
rommon 1 > dir slotO:
File size Checksum File name
1603124 bytes (0x187634) 0x37e92ad5 c6msfc-boot-mz.120-7T.XEl.2.02.bin
10827684 bytes (0xa537a4) Oxcdcblae c6sup-jsdbg-mz.120-7T.XEl.2.02.bin ** Cat
IOS image **
6174451 bytes (0x5e36f3) 0xb718ee34 cat6000-sup.5-4-0-97.bin ** Cat IOS image **
1877456 bytes (0xlca5d0) 0x325c9851 c6msfc-bootdbg-mz ** MSFC boot loader image **
8235 bytes (0x202b) 0x2a825cl8 switch.cfg .
rommon 2 > dir bootflash:
File size Checksum File name
10827684 bytes (0xa537a4) Oxcdcblae c6sup-jsdbg-mz.120-7T.XEl.2.02.bin *** Cat IOS image **
1603124 bytes (0x187634) 0x37e92ad5 c6msfc-boot-mz.l20-7T.XEL2.02.bin
Определив, где находится образ, выполните указание одного из следующих двух разделов:
при использовании загрузчика версии c6msfc-boot-mz. 120-7.ХЕ1 или последующих версий перейдите к разделу “Загрузка образа Catalyst IOS";
при использовании загрузчика версии release c6msfc-boot-mz. 120-7.ХЕ перейдите к разделу “Загрузка образа Catalyst OS”.
Снова вернитесь к текущему описанию после загрузки образа Cat IOS или Cat OS.
В приглашении к вводу информации загрузки указан процессор RP, и все готово к переводу коммутатора в режим эксплуатации образа Cat IOS. Прежде чем выполнить перезагрузку, обязательно установите значение регистра конфигурации, равное 0x2. При этом может также потребоваться проверить, правильно ли установлены переменные начальной загрузки. Если они установлены неправильно, внесите в эти переменные изменения так, чтобы они указывали правильные имена образов. Ниже приведен соответствующий пример.
boot system flash sup-bootflash:c6sup-jsdbg-mz.l20-7T.XE1.2.02.bin
boot bootldr bootflash:c6msfc-bootdbg-mz
Примечание. Если загрузочные переменные вообще не установлены, то коммутатор предпринимает попытку загрузиться из первого же файла, который находится в соответствующей загрузочной флэш-памяти.
Router(boot)# sh bootvar
BOOT variable =
CONFIG FILE variable does not exist
BOOTLDR variable =
Configuration register is 0x0
Router(boot)# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(boot)(config)# conf
Router (boot) (config)# config-register 0x2
Router(boot)(config)#
Router(boot)#
00:01:14: %SYS-5-CONFIG_I: Configured from console by console
Router(boot)# reload
System configuration has been modified. Save? [yes/no]: n
Proceed with reload? [confirm]
00:01:30: %SYS-5-RELOAD: Reload requested
System Bootstrap, Version 12.0(3)XE, RELEASE SOFTWARE
Copyright (c) 1998 by cisco Systems, Inc.
Cat6k-MSFC platform with 131072 Kbytes of main memory Self decompressing the image : ################### [OK] starting download: 7813530bytes!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Chksum: Verified!
Self decompressing the image : ################################################################# [OK] Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DEARS sec. 252.227-7013.
cisco Systems, Inc..
170 West Tasman Drive
San Jose, California 95134-1706
Cisco Internetwork Operating System Software
IOS (tm) c6sup Software (c6sup-JSDBG-M), Version 12.0(7T)XEl(2.02) INTERIM TEST SOFTWARE
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Sun 09-Jan-00 21:59 by integ
Image text-base: 0x60020900, data-base: ОхбИВЕООО
cisco Catalyst 6000 (R5000) processor with 122880K/8192K bytes of memory. Processor board ID SAD03302657
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
96 FastEthernet/IEEE 802.3 interface(s)
2 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
4096K bytes of packet SRAM memory.
16384K bytes of Flash internal SIMM (Sector size 256K).[OK][OK]
Press RETURN to get started! monvar = 00:00:03: %SYS-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure
console debugging output.
00:00:03: %C6KPWR-4-PSINSERTED: power supply inserted in slot 1.
00:00:03: %C6KPWR-4-PSOK: power supply 1 turned on.
00:00:03: %C6KPWR-4-PSINSERTED: power supply inserted in slot 2.
00:00:03: %C6KPWR-4-PSOK: power supply 2 turned on.
00:00:03: %C6KPWR-4-PSREDUNDANTBOTHSUPPLY: in power-redundancy mode, system is operating on both power supplies.
00:01:02: Cannot open bootflash:?
00:04:59:Translating "derby"...domain server (255.255.255.255)
%SYS-SP-5-RESTART: System restarted —
Cisco Internetwork Operating System Software
IOS (tm) c6sup_sp Software (c6sup_sp-SPDBG-M), Version 12.0(7T)XEl(2.02)
INTERIM TEST SOFTWARE
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Sun 09-Jan-00 22:40 by integ
00:05:02: %SYS-5-CONFIG_I: Configured from memory by console
00:05:02: L3-MGR: 12 flush entry installed
00:05:02: L3-MGR: 13 flush entry installed
00:05:02: %SYS-5-RESTART: System restarted —
Cisco Internetwork Operating System Software
IOS (tm) c6sup Software (c6sup-JSDBG-M), Version 12.0(7T)XEl(2.02) INTERIM TEST SOFTWARE
Copyright (c) 1986-2000 by cisCo Systems, Inc.
Compiled Sun 09-Jan-00 21:59 by integ
00:05:06: %C6KPWR-SP-4-ENABLED: power to module inslot 3 set on
00:05:07: %C6KPWR-SP-4-ENABLED: power to module inslot 4 set on
00:05:26: WIR-SP-6-INSCARD: Card inserted in slot1, interfacesarenowonline
00:05:31: WIR-SP-6-INSCARD: Card inserted in slot3, interfacesarenowonline
00:05:32: WIR-SP-6-INSCARD: Card inserted in slot4, interfacesarenowonline
derby> en derby#
Метод 2: последовательность восстановления образа загрузчика по протоколу ООВ с использованием процедуры xmodem
Этот вариант процедуры восстановления можно применять только в том случае, если происходит восстановление после аварии и другие варианты отсутствуют.
На первом этапе должна быть выполнена загрузка образа Cat IOS или Cat OS в загрузочную флэш-память блока управления. Убедитесь в том, что образ Cat OS находится в загрузочной флэш-памяти блока управления или во флэш-памяти платы, которая вставлена в слот 0, и выполните инструкции, приведенные в разделах “Загрузка образа Catalyst IOS” или “Загрузка образа Catalyst OS” ниже в этой главе.
После выполнения процедуры загрузки образа Cat IOS или Cat OS убедитесь в том, что на терминале имеется приглашение к вводу информации в режиме ROMmon платы MSFC.
Примечание. В настоящее время плата MSFC в режиме ROMmon не имеет доступа к загрузочной флэш-памяти блока управления или к слоту 0.
Не забудьте также подготовить образ загрузчика на компьютере, с которого выполняется загрузка с помощью процедуры xmodem. Теперь можно приступить к загрузке с помощью процедуры xmodem. Для выполнения этого этапа требуется 40—45 минут.
После получения приглашения к вводу информации в режиме ROMmon платы MSFC введите следующую команду:
xmodem -s9600 -с
Опция -s9600 определяет скорость, а опция -с задает применение контрольной суммы.
System Bootstrap, Version 12.0(3)ХЕ, RELEASE SOFTWARE
Copyright (c) 1998 by cisco Systems, Inc.
Cat6k-MSFC platform with 65536 Kbytes of main memory rommon 1 >
rommon 1 > xmodem -s9600 -c
Do not start sending the image yet...
Invoke this application for disaster recovery.
Do you wish to continue? y/n [n]: у
Note, if the console port is attached to a modem, both the console port and the modem must be operating at the same baud rate. Use console speed 9600 bps for download [confirm] Download will be performed at 9600. Make sure your terminal emulator is set to this speed before sending file.
Ready to receive file ...
В эмуляторе терминала введите команду send или щелкните на соответствующей пиктограмме, чтобы начать процесс загрузки. Для завершения передачи требуется 40— 45 минут.
Авторы пришли к выводу, что первая попытка может завершиться неудачей. В таком случае снова введите команду xmodem, не переустанавливая плату MSFC. По окончании успешной загрузки появится следующее сообщение:
Download Complete!
После выполнения загрузки образ будет разархивирован и вызван на выполнение в плате MSFC. Следующим приглашением к вводу информации будет приглашение начальной загрузки платы MSFC.
Self decompressing the image : IHHHHIHHfffHHff [OK] Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DEARS sec. 252.227-7013.
cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134-1706
Cisco Internetwork Operating System Software
IOS (tm) MSFC Software (C6MSFC-BOOT-M), Version 12.0(7T)XE1(1.11) INTERIM TEST
SOFTWARE
Copyright (c) 1986-1999 by cisco Systems, Inc.
Compiled Tue 28-Dec-99 04:44 by
Image text-base: 0x60008900, data-base: 0x60382000
cisco Cat6k-MSFC (R5000) processor with 57344K/8192K bytes of memory.
Processor board ID SAD03483410
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
Last reset from power-on
X.25 software, Version 3.0.0.
123K bytes of non-volatile configuration memory.
4096K bytes of packet SRAM memory.
16384K bytes of Flash internal SIMM (Sector size 256K).
Press RETURN to get started!
00:00:04: %SYS-5-RESTART: System restarted —
Cisco Internetwork Operating System Software
IOS (tm) MSFC Software (C6MSFC-BOOT-M), Version 12.0(7T)XE1(1.11) INTERIM TEST
SOFTWARE
Copyright (c) 1986-1999 by cisco Systems, Inc.
Compiled Tue 28-Dec-99 04:44 by
Router(boot)>
В результате загрузки с помощью процедуры xmodem образ загрузчика не копируется в загрузочную флэш-память платы MSEC, а просто загружается и разархивируется для вызова на выполнение в плате MSEC.
На следующем этапе необходимо скопировать образ загрузчика из слота 0 блока управления в загрузочную флэш-память платы MSEC.
Из приглашения к вводу информации в режиме начальной загрузки платы MSEC нельзя получить доступ к слоту 0 блока управления или просмотреть содержимое вставленной в него микросхемы. Необходимо запомнить имя файла образа загрузчика, чтобы выдать следующую команду.
При эксплуатации образа Cat OS применяется команда
copy sup-slot0:<boot loader image> bootflash:<boot loader image>
При эксплуатации образа Cat IOS применяется команда
download slot0:<boot loader image> bootflash:<bootloader image>
Примечание. Следует учитывать, что плата MSFC не обеспечивает копирование образа из какого-либо иного места, кроме слота 0 блока управления.
Теперь коммутатор, в котором эксплуатируется образ Cat IOS, можно перевести в рабочее состояние. Прежде чем выполнить перезагрузку, обязательно установите значение регистра конфигурации, равное 0x2. При этом может также потребоваться проверить, правильно ли установлены переменные начальной загрузки. Для корректировки значений загрузочных переменных применяются следующие команды:
boot system flash sup-bootflash:<CatIOS image>
boot bootldr bootflash:<boot loader image>
Загрузка образа Catalyst IOS
Для загрузки образа Cat IOS необходимо ввести следующую команду:
boot <location>:c6sup-jsdbg-mz.120-7T.XE1.2.02.bin
В этой команде параметр <location> обозначает slotO или bootflash.
Примечание. После загрузки этого образа вы перейдете непосредственно к приглашению к вводу информации в режиме ROMmon платы MSEC.
rommon 3 > boot bootflash:c6sup-jsdbg-mz.l20-7T.XE1.2.02.bin Self decompressing the image :########################[OK] Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706
Cisco Internetwork Operating System Software
IOS (tm) c6sup_sp Software (c6sup_sp-SPDBG-M), Version 12.0(7T)XE1(2.02) INTERIM TEST SOFTWARE
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Sun 09-Jan-00 22:40 by integ
Image text-base: 0x60020900, data-base: 0x60588000
Start as Primary processor
00:00:03: %SYS-3-LOGGER_FLUSHING: System pausing to ensure console debugging output.
00:00:03: %OIR-6-CONSOLE: Changing console ownership to route processor
System Bootstrap, Version 12.0(3)XE, RELEASE SOFTWARE
Copyright (c) 1998 by cisco Systems, Inc.
Cat6k-MSFC platform with 131072 Kbytes of main memory rommon 1 >
В этот момент в плате MSEC должен эксплуатироваться образ загрузчика. Выведите на экран содержимое загрузочной флэш-памяти платы MSEC, чтобы убедиться в том, что в ней находится образ загрузчика. Введите следующую команду.
rommon 2 > dir bootflash:
File size Checksum File name
1877456 bytes (0xlca5d0) 0x325c9851 c6msfc-bootdbg-mz
Теперь выполните начальную загрузку платы MSFC с использованием образа загрузчика следующим образом:
rommon 3 > boot bootflash:c6msfc-bootdbg-mz
Self decompressing the image : ################ [OK]
Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706
Cisco Internetwork Operating System Software
IOS (tm) MSFC Software (C6MSFC-BOOTDBG-M), Experimental Version 12.1(20000118:211435) [slarson-cosmos_e2 321]
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 19-Jan-00 16:23 by slarson
Image text-base: 0x60008900, data-base: 0x603C4000
cisco Cat6k-MSFC (R5000) processor with 122880K/8192K bytes of memory.
Processor board ID SAD03302657
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
Last reset from power-on
X.25 software, Version 3.0.0.
123K bytes of non-volatile configuration memory.
4096K bytes of packet SRAM memory.
16384K bytes of Flash internal SIMM (Sector size 256K).
Press RETURN to get started!
00:00:04: %SYS-5-RESTART: System restarted — Cisco Internetwork Operating System Software IOS (tm) MSFC Software (C6MSFC-BOOTDBG-M), Experimental Version
12.1(20000118:211435) [slarson-cosmos_e2 321]
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 19-Jan-00 16:23 by slarson
Router(boot)> en
Router(boot)#
После этого необходимо отформатировать загрузочную флэш-память платы MSEC и скопировать образ загрузчика из слота 0 блока управления.
Примечание. Вы не сможете просмотреть содержимое микросхемы, вставленной в слот 0, поэтому должны запомнить имя файла образа загрузчика, чтобы загрузить его из слота 0 блока управления.
Router(boot)# dir slotO:
% Invalid input detected at ,A' marker.
Сначала отформатируйте загрузочную флэш-память платы MSEC.
Router(boot)# format bootflash:
Format operation may take a while. Continue? [confirm]
Format operation will destroy all data in "bootflash:".
Continue? [confirm]
Formatting sector 1
Format of bootflash: complete
Скопируйте образ загрузчика в загрузочную флэш-память платы MSEC, введя следующую команду:
download slotO:<boot loader image> bootflash:<boot loader image>
Ниже приведены результаты выполнения нескольких последних шагов.
Router(boot)# download slot0:c6msfc-bootdbg-mz bootflash:c6msfc-bootdbg-mz Starting download: 1877456
bytes!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Chksum: Verified!
Writing image to bootflash:c6msfc-bootdbg-mz !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
^Download successful
Router(boot)# dir bootflash:
Directory of bootflash:/
1 -rw- 1877456 Jan 01 2000 00:38:56 c6msfc-bootdbg-mz 15990784 bytes total (14113200 bytes free)
А теперь вернитесь к главным процедурам восстановления для завершения процесса.
Загрузка образа Catalyst OS
На первом этапе необходимо загрузить образ Cat OS, а затем переключить консоль с процессора RP на процессор SP. На новой консоли должно появиться приглашение к вводу информации в режиме ROMmon платы MSEC.
Примечание. После загрузки этого образа вы не перейдете непосредственно к приглашению к вводу информации в режиме ROMmon платы MSEC.
Загрузите образ Cat OS, введя следующую команду:
boot <location>:<Cat OS image>
В этой команде параметр <location> обозначает slotO или bootflash.
Переключитесь на консоль MSFC, введя команду switch console после перехода к приглашению к вводу информации в режиме enable системы Cat OS.
rommon 1 > boot slot0:cat6000-sup.5-4-0-97.bin
Uncompressing file: IIIIIHHtlHIHHIHHIIIIHIHIIIIIIIIIHIIIHIIIIIIHI
System Power On Diagnostics
DRAM Size 64 MB
Testing DRAMPassed
Verifying Text SegmentPassed
NVRAM Size 512 KB
Saving NVRAM Done
Testing NVRAM Passed
Restoring NVRAMDone
Level2 Cache Present
Testing Level2 Cache Passed
System Power On Diagnostics Complete
Boot image: slot0:cat6000-sup.5-4-0-97.bin
Running System Diagnostics from this Supervisor (Module 1)
This may take up to 2 minutes....please wait
IP address for Catalyst not configured
DHCP/BOOTP will commence after the ports are online
Ports are coming online ...
Cisco Systems Console
2000 Jan 01 01:16:12 %SYS-4-NVLOG:initBootNvram:Bootarea checksum failed: 0x4525(0x45A5)
Enter password: 2000 Jan 01 01:16:14 %SYS-1-SYS_NORMPWRMGMT:System in normal power management operation
2000 Jan 01 01:16:17 %SYS-5-MOD_PWRON:Module 3 powered up
2000 Jan 01 01:16:17 %SYS-5-MOD_PWRON:Module 4 powered up
2000 Jan 01 01:16:27 %MLS-5-NDEDISABLED:Netflow Data Export disabled
2000 Jan 01 01:16:27 %MLS-5-MCAST_STATUS:IP Multicast Multilayer Switching is enabled
2000 Jan 01 01:16:28 %SYS-5-MOD_OK:Module 1 is online
2000 Jan 01 01:16:45 %PAGP-5-PORTTOSTP:Port 1/2 joined bridge port 1/2
2000 Jan 01 01:17:01 %SYS-5-MOD_OK:Module 3 is online
2000 Jan 01 01:17:08 %SYS-5-MOD_OK:Module 4 is online
Console> en
Enter password:
Console> (enable) switch console
Trying Router-15...
Connected to Router-15.
Type 'exit' to switch back...
rommon 1 >
В этот момент в плате MSEC должен эксплуатироваться образ загрузчика. Выведите на экран содержимое загрузочной флэш-памяти платы MSEC, чтобы убедиться в том, что в ней присутствует образ загрузчика. Введите следующую команду:
Router(boot)# dir bootflash:
Directory of bootflash:/
-rw- 1877456 Jan 01 2000 00:38:56 c6msfc-bootdbg-mz
Теперь выполните начальную загрузку образа загрузчика в плату MSEC следующим образом:
rommon 5 > boot bootflash:c6msfc-bootdbg-mz
Self decompressing the image : НШНШНННН [OK]
Restricted Rights Legend
Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706
Cisco Internetwork Operating System Software
IOS (tm) MSFC Software (C6MSFC-BOOTDBG-M), Experimental Version
12.1(20000118:211435) [slarson-cosmos_e2 321]
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 19-Jan-00 16:23 by slarson
Image text-base: 0x60008900, data-base: 0x603C4000
cisco Cat6k-MSFC (R5000) processor with 122880K/8192K bytes of memory.
Processor board ID SAD03302657
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
Last reset from power-on
X.25 software, Version 3.0.0.
123K bytes of non-volatile configuration memory.
4096K bytes of packet SRAM memory.
16384K bytes of Flash internal SIMM (Sector size 256K).
Press RETURN to get started!
Module online.
00:00:04: 4SYS-5-RESTART: System restarted —
Cisco Internetwork Operating System Software
IOS (tm) MSFC Software (C6MSFC-BOOTDBG-M), Experimental Version
12.1(20000118:211435) [slarson-cosmos_e2 321]
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 19-Jan-00 16:23 by slarson
Router(boot)> en
download slotO:<boot loader image> bootflash:<boot loader image>
После этого необходимо отформатировать загрузочную флэш-память платы MSFC и скопировать образ загрузчика из слота 0 блока управления.
Примечание. Вы не сможете просмотреть содержимое микросхемы, вставленной в слот 0, поэтому должны запомнить имя файла образа загрузчика, чтобы загрузить его из слота 0 блока управления.
Router(boot)f dir slotO:
% Invalid input detected at ,A' marker.
Сначала отформатируйте загрузочную флэш-память платы MSFC.
Router(boot)# format bootflash:
Format operation may take a while. Continue? [confirm]
Format operation will destroy all data in "bootflash:". Continue? [confirm]
Formatting sector 1
Format of bootflash: complete
Скопируйте образ загрузчика в загрузочную флэш-памяти платы MSFC, введя следующую команду:
copy sup-slotO:<boot loader image> bootflash:<boot loader image>
Ниже приведены результаты выполнения нескольких последних шагов.
Router(boot)f copy sup-slot0:c6msfc-boot-mz bootflash:c6msfc-boot-mz
Destination filename [c6msfc-boot-mz]?
Accessing sup-slotO:c6msfc-boot-mz...
Loading slot0:c6msfc-boot-mz from 127.0.0.11 (via EOBC0): !
Loading slot0:c6msfc-boot-mz from 127.0.0.11 (via EOBC0): I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![OK - 1603124/3206144 bytes]
Router(boot)# dir bootflash:
Directory of bootflash:/
1 -rw- 1877456 Jan 01 2000 00:38:56 c6msfc-bootdbg-mz
15990784 bytes total (14113200 bytes free)
А теперь вернитесь к главным процедурам восстановления для завершения процесса.
Загрузка и запуск маршрутизатора Cisco 2600 по протоколу TFTP
Введение
В настоящем разделе описано, как устранить нарушение в работе маршрутизатора Cisco 2600, вызванное искажением или отсутствием образа IOS. Для получения доступа к интерпретатору командной строки режима ROMmon нажмите клавишу <Break> в течение первых 15 секунд с момента включения питания маршрутизатора. После получения приглашения к вводу информации rommon> можно ввести команду tftpdnld для загрузки по протоколу TFTP образа IOS в маршрутизатор.
rommon 1 > tftpdnld
Missing or illegal ip address for variable IP ADDRESS
Illegal IP address.
usage: tftpdnld [-r]
Use this command for disaster recovery only to recover an image via TFTP.
Monitor variables are used to set up parameters for the transfer.
(Syntax: "VARIABLE_NAME=value" and use "set" to show current variables.) "ctrl-c" or "break" stops the transfer before flash erase begins.
The following variables are REQUIRED to be set for tftpdnld:
IP ADDRESS: The IP address for this unit
IP_SUBNET_MASK: The subnet mask for this unit
DEFAULT_GATEWAY: The default gateway for this unit
TFTP_SERVER: The IP address of the server to fetch from
TFTP_FILE: The filename to fetch
The following variables are OPTIONAL:
TFTP_VERBOSE: Print setting. 0=quiet, l=progress(default), 2=verbose
TFTP_RETRY COUNT: Retry count .for ARP and TFTP (default=7)
TFTP_TIMEOUT: Overall timeout of operation in seconds (default=7200)
TFTP_CHECKSUM: Perform checksum test on image, 0=no, l=yes (default=l)
FE_SPEED_MODE: 0=10/hdx, l=10/fdx, 2=100/hdx, 3=100/fdx, 4=Auto(deflt)
Command line options:
-r: do not write flash, load to DRAM only and launch image
rommon 2 > IP_ADDERESS=172.18.44.1
rommon 3 > IP_SUBNET_MASK=255.255.0.0
rommon 4 > DEFAULT GATEWAYS72.18.44.44
rommon 5 > TFTP_SERVER=172.18.44.44
rommon 6 > TFTP FILE=c2600-jk2o3s-mz.121-3.T.bin rommon 7 > tftpdnld
IP_ADDRESS: 172.18.44.1
IP_SUBNET_MASK: 255.255.0.0
DEFAULT_GATEWAY: 172.18.44.44
TFTP_SERVER: 172.18.44.44
TFTP_FILE: c2600-jk2o3s-mz.121-3.T.bin
Invoke this command for disaster recovery only.
WARNING: all existing data in all partitions on flash will be lost! Do you wish to continue? y/n: [n]: у
Receiving c2600-jk2o3s-mz.121-3.T.bin from 172.18.44.44 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [...] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !7
File reception completed.
Copying file c2600-jk2o3s-mz.121-3.T.bin to flash.
Erasing flash at 0x60000000
program flash location 0x60000000 rommon 9 > dir flash:
File sizeChecksum File name_
11542120 bytes (0xb01e68) 0xaae4 c2600-jk2o3s-mz.121-3.T.bin rommon 10 > reset
System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fcl)
Copyright (c) 1999 by cisco Systems, Inc.
TAC:Home:SW:IOS:Specials for info
C2600 platform with 65536 Kbytes of main memory
program load complete, entry point: 0x80008000, size: 0xb01d4c
Self decompressing the image :
шшннинннннннннншнншнннншнннншшшнишннш#» [...]
ШШНШННННННН [OK]
Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-JK2O3S-M), Version 12.1(3)T, RELEASE SOFTWARE (fcl) Copyright (c) 1986-2000 by cisco Systems, Inc.•
Compiled Thu 20-Jul-00 01:38 by ccai
Image text-base: 0x80008088, data-base: 0x81381C5C
Compliance with U.S. Export Laws and Regulations - Encryption
This product performs encryption and is regulated for export by the U.S. Government.
This product is not authorized for use by persons located outside the United States and Canada that do not have prior approval from Cisco Systems, Inc. or the U.S. Government.
This product may not be exported outside the U.S. and Canada either by physical or electronic means without PRIOR approval of Cisco Systems, Inc. or the U.S. Government.
Persons outside the U.S. and Canada may not re-export, resell, or transfer this product by either physical or electronic means without prior approval of Cisco Systems, Inc. or the U.S. Government.
cisco 2621 (MPC860) processor (revision 0x102) with 60416K/5120K bytes of memory.
Processor board ID JAD04270DWH (2283097670)
M860 processor: part number 0, mask 49
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
Basic Rate ISDN software, Version 1.1.
2 FastEthernet/IEEE 802.3 interface(s)
Serial network interface(s)
ISDN Basic Rate interface(s)
32K bytes of non-volatile configuration memory.
16384K bytes of processor board System flash (Read/Write)
— System Configuration Dialog —
Would you like to enter the initial configuration dialog? [yes/no]: no
Would you like to terminate autoinstall? [yes]:
Press RETURN to get started!
Passed
00:00:24: 8LINK-3-UPDOWN: Interface FastEthernetO/O, changed state to up
00:00:24: 8LINK-3-UPDOWN: Interface FastEthernetO/1, changed state to up
00:00:24: SLINK-3-UPDOWN: Interface Serial0/0, changed state to down
00:00:25: 3LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
00:00:25: 8LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernetO/1, changed state to down
00:00:25: SLINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down 00:00:58: 8LINK-5-CHANGED: Interface BRI0/0, changed state to administratively down 00:00:59: 4LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0, changed state to down 00:00:59: $IP-5-WEBINST_KILL: Terminating DNS process
00:01:00: 8LINK-5-CHANGED: Interface Serial0/0, changed state to administratively down
00:01:00: 4LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
00:01:00: SLINK-5-CHANGED: Interface FastEthernetO/1, changed state to administratively down
Поиск неисправностей в системах питания и охлаждения
Проверьте следующие блоки для обнаружения конкретной неисправности.
После перевода выключателя питания в положение “включено” (1), когда загорается светодиод питания, убедитесь в том, что вентилятор работает. В противном случае проверьте вентилятор.
Если маршрутизатор останавливается после непродолжительной работы, проверьте температурные условия окружающей среды. Маршрутизатор может перегреваться, что приводит к останову, вызванному срабатыванием тепловой защиты. Убедитесь в том, что воздухоприемные и воздуховыпускные отверстия корпуса ничем не перекрыты. Диапазон рабочих температур маршрутизатора находится в пределах от 0°С до 40°С. Если маршрутизатор не загружается, а светодиод питания горит, проверьте питание.
Если маршрутизатор загружается только после нескольких попыток или периодически перезагружается, то может иметь место нарушение в работе процессора или программного обеспечения. Это может быть также вызвано неправильной установкой одной из микросхем динамического ОЗУ.
Запуск маршрутизатора Cisco 3600
Введение
В настоящем разделе описано, как устранить нарушение в работе маршрутизатора Cisco 3600, вызванное искажением или отсутствием образа IOS. Для получения доступа к интерпретатору командной строки режима ROMmon нажмите клавишу <Break> в течение первых 15 секунд с момента включения питания маршрутизатора. После по-
лучения приглашения к вводу информации rommon> можно ввести команду xmodem для передачи образа IOS в маршрутизатор через интерфейс консоли.
Ниже приведены результаты применения процедуры xmodem для загрузки кода IOS.
rommon 1 > xmodem ?
Do not start the sending program yet... device does not contain a valid magic number dir: cannot open device "flash:"
WARNING; All existing data in flash will be lostl Invoke this application only for disaster recovery. Do you wish to continue? y/n [n]: у Ready to receive file ? ...
Erasing flash at 0x30000000
program flash location 0x30000000
Download Complete!
program load complete, entry point: 0x80008000, size: 0xal0988
Self decompressing the image : шншншииинниншннншшннш#ш1111#1шшншшш#ншшн [...]
IIIIHIIIIIIIIHfffffffflfllllfffffffflffffll [OK]
Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DEARS sec. 252.227-7013.
cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134-1706
Cisco Internetwork Operating System Software
IOS (tm) 3600 Software (C3640-IK2S-M), Version 12.1(3)T, RELEASE SOFTWARE (fcl) Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 19-Jul-00 20:18 by ccai
Image text-base: 0x60008950, data-base: ОхбИбСООО
Compliance with U.S. Export Laws and Regulations - Encryption
This product performs encryption and is regulated for export by the U.S. Government.
This product is not authorized for use by persons located outside the United States and Canada that do not have prior
approval from Cisco Systems, Inc. or the U.S. Government.
This product may not be exported outside the U.S. and Canada either by physical or electronic means without PRIOR approval of Cisco Systems, Inc. or the U.S. Government.
Persons outside the U.S. and Canada may not re-export, resell, or transfer this product by either physical or electronic means without prior approval of Cisco Systems, Inc. or the U.S. Government.
cisco 3640 (R4700) processor (revision 0x00) with 60416K/5120K bytes of memory. Processor board ID 19704176
R4700 CPU at lOOMhz, Implementation 33, Rev 1.0
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
FastEthernet/IEEE 802.3 interface(s)
DRAM configuration is 64 bits wide with parity disabled.
125K bytes of non-volatile configuration memory.
16384K bytes of processor board System flash (Read/Write)
SETUP: new interface FastEthernetO/0 placed in "shutdown" state
SETUP: new interface FastEthernetO/1 placed in "shutdown" state
Press RETURN to get started!
00:00:13: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
00:00:13: 4LINK-3-UPDOWN: Interface FastEthernetO/1, changed state to up
00:00:13: %SYS-5-CONFIG_I: Configured from memory by console
00:00:14: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down_00:00:14: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernetO/1, changed state to down
00:00:18: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
00:00:28: %IP-5-WEBINST_KILL: Terminating DNS process
00:00:29: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
00:00:29: %SYS-5-RESTART: System restarted —
Cisco Internetwork Operating System Software
IOS (tm) 3600 Software (C3640-IK2S-M), Version 12.1(3)T, RELEASE SOFTWARE (fcl) Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 19-Jul-00 20:18 by ccai
00:00:30: %LINK-5-CHANGED: Interface FastEthernetO/1, changed state to administratively down
00:00:30: 4LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Поиск неисправностей
Для получения дополнительной информации о поиске неисправностей маршрутизатора Cisco 3600 обратитесь к документу www.cisco.com/univercd/cc/td/doc/product /access/acs_mod/cis3600/3600ig/3600trou.htm.
Запуск коммутатора Catalyst 4000 корпорации Cisco■
После подачи питания на коммутатор Catalyst 4000 корпорации Cisco должен произойти следующий процесс загрузки:
WS-X4013 bootrom version 5.4(1), built on 2000.04.04 10:48:54
H/W Revisions: Crumb: 5 Rancor: 8 Board: 2
Supervisor MAC addresses: 00:02:b9:ll:d4:00 through 00:02:b9:11:d7:ff (1024 addresses)
Installed memory: 64 MB
Testing LEDs.... done!
The system will autoboot in 5 seconds.
Type control-C to prevent autobooting.
rommon 1 >
The system will now begin autobooting.
Autobooting image: "bootflash:cat4000.5-5-1.bin"
Ш1НН11НН111НН11Ш1Н
Starting Off-line Diagnostics
Mapping in TempFs
Board type is WS-X4013
DiagBootMode value is "post" Telling ApkPageMan that we have 12288 pages of memory Loading diagnostics...
Power-on-self-test for Module 1:
: WS-X4013
Status:
: (. = Pass, F = Fail)
uplink
port 1: .uplink port 2: .eobc port: .
processor: .cpu sdram: .rtc: .
eprom:
.nvram: .
flash: .
temperature sensor: . enet console port: . switch 0 port 0: .
switch
0 port 1: .switch 0
port 2: .switch 0 port 3: .
switch
0 port 4: .switch 0
port 5: .switch 0 port 6: .
switch
0 port 7: .switch 0
port 8: .switch 0 port 9: .
switch
0 port 10: . switch 0
port 11: . switch 0 registers:
switch
0 sram: .switch 1
port 0: .switch 1 port 1: .
switch
1 port 2: .switch 1
port 3: .switch 1 port 4: .
switch
1 port 5: .switch 1
port 6: .switch 1 port 7: .
switch
1 port 8: .switch 1
port 9: .switch 1 port 10: .
switch
1 port 11: . switch 1
registers: . switch 1 sram: .
switch
2 port 0: .switch 2
port 1: .switch 2 port 2: .
switch
2 port 3: .switch 2
port 4: .switch 2 port 5: .
switch2port 6: .switch2port 7:.switch2port8: .
switch2port 9: .switch2port 10:.switch2port11:.
switch2registers:.switch2sram: .
Module 1 Passed
Power-on-self-test for Module 2: not present
Port status: (. = Pass, F = Fail)
Module 2 Ignored
Power-on-self-test for Module 3: WS-X4148-RJ
Port
status:
■ =
Pass, F =
Fail)
1: .
2: .
3:
.4: .
5: .
6: .
7: .
8:
9: .
10: .
11:
. 12: .
13: .
14: .
15: .
16:
17: .
18: .
19:
. 20: .
21: .
22: .
23: .
24:
25: .
26: .
27:
. 28: .
29: .
30: .
31: .
32:
33: .
34: .
35:
. 36: .
37: .
38: .
39: .
40:
41: .
42: .
43:
. 44: .
45: .
46: .
47: .
48:
Module 3 Passed
Power-on-self
-test
for Module 4:
WS-X4148-RJ
Port
status:
• =
Pass, F =
Fail)
1: .
. 2: .
3:
.4: .
5: .
6: .
7: .
8:
9: .
10: .
11:
. 12: .
13: .
14: .
15: .
16:
17: .
18: .
19:
. 20: .
21: .
22: .
23: .
24:
25: .
26: .
27:
. 28: .
29: .
30: .
31: .
32:
33: .
34: .
35:
. 36: .
37: .
38: .
39: .
40:
41: .
42: .
43:
. 44: .
45: .
46: .
47: .
48:
Module 4 Passed
Power-on-self-test for Module 5: not present Port status: (. = Pass, F = Fail)
Module 5 Ignored
Power-on-self-test for Module 6: not present Port status: (. = Pass, F = Fail)
Module 6 Ignored
Exiting Off-line Diagnostics
Cisco Systems, Inc. Console
Enter password:
Console> ena
Enter password:
Console> (enable) sh mod
Mod Slot Ports Module-Type
Model
Sub Status
1
1
2
lOOOBasex Supervisor
WS-X4013
no
ok
3
3
48
10/100BaseTx Ethernet
WS-X4148-RJ
no
other
4
4
48
10/100BaseTx Ethernet
WS-X4148-RJ
no
other
Mod Module-NameSerial-Num
1JAB0427081F
3JAB04110629
4JAE041801B5
Mod MAC-Address(es)Hw FwSw
100-02-b9-ll-d4-00 to 00-02-b9-ll-d7-ff 1.25.4(1)5.5(1)
300-01-42-f5-c5-b0 to 00-01-42-f5-c5-df 2.3
400-02-16-25-19-40 to 00-02-16-25-19-6f 2.3
Console> (enable) sh mod
Mod Slo
t Ports
Module-Type
Model
Sub
Status
1 1
2
lOOOBasex Supervisor
WS-X4013
no
ok
3 3
48
10/100BaseTx Ethernet
WS-X4148-RJ
no
ok
4 4
48
10/100BaseTx Ethernet
WS-X4148-RJ
no
ok
Mod Module-NameSerial-Num
1JAB0427081F
3JAB04110629
4JAE041801B5
Mod MAC-Address(es)Hw FwSw
100-02-b9-ll-d4-00 to 00-02-b9-ll-d7-ff 1.25.4(1)5.5(1)
00-01-42-f5-c5-b0 to 00-01-42-f5-c5-df 2.3
00-02-16-25-19-40 to 00-02-16-25-19-6f 2.3
Console> (enable)
Поиск неисправностей
Для получения дополнительной информации о поиске неисправностей коммутатора Cisco 4000 обратитесь к документу www.cisco.com/univercd/cc/td/doc/product/ lan/cat4000/inst_gd/06trblsh.htm.
ГлаваГлава44
Глава
Глава
4
4
Устранение нарушений в работе сети Ethernet
Сеть Ethernet была разработана в 1970-х годах Исследовательским центром Пало Альто (PARC — Palo Alto Research Center) корпорации Xerox. Спецификация сети , Ethernet послужила прототипом для спецификации IEEE 802.3, которая была выпущена в 1980 году. Вскоре после этого корпорации Digital Equipment Corporation, Intel ' и Xerox совместно разработали и выпустили спецификацию Ethernet (версия 2.0), ко- ■. юрая в целом совместима со спецификацией IEEE 802.3. В настоящее время сети, со- ответствуюшие спецификациям Ethernet и IEEE 802.3, составляют основную часть локальных сетей. Как правило, термин “сеть Ethernet” чаще всего служит для обозначения всех локальных сетей CSMA/CD (Carrier Sense Multiple Access with Collision f Detection — множественный доступ с контролем несущей и обнаружением коллизий), которые в целом соответствуют спецификациям, совместимым с Ethernet, включая IEEE 802.3, а для обозначения сетей, соответствующих только спецификации Ethernet, применяется термин “традиционная сеть Ethernet”.
Разработка спецификации Ethernet первоначально проводилась в целях создания сетей такого типа, которые могли бы занять промежуточное положение между существовавшими в то время низкоскоростными сетями дальней связи и специализированными сетями масштабов вычислительного центра, позволявшими передавать данные с высокими скоростями на очень ограниченные расстояния. Сеть Ethernet хорошо подходит для приложений, в которых локальная среда связи должна нести нерегулярный, временами очень напряженный трафик с высокими пиковыми скоростями передачи данных.
Спецификации Ethernet и IEEE 802.3
Спецификации Ethernet и IEEE 802.3, в той части, которая касается функционирования в полудуплексном режиме, определяют аналогичные технологии. Обе они лежат в основе локальных сетей CSMA/CD. Станции в локальной сети CSMA/CD могут передавать данные в любое время, но перед передачей данных эти станции проверяют наличие несущей в сети, чтобы определить, используется ли сеть в данный момент. । При обнаружении несущей станция, которая должна передать данные, переходит в состояние ожидания. Если же сеть в данный момент не используется, станция начи-
нает передачу. Но если наличие несущей проверяют две разные станции и, обнаружив, что сеть свободна, одновременно начинают передачу, возникает коллизия. В таком случае искажаются данные, передаваемые обеими станциями, поэтому обе станции должны снова повторить передачу через некоторое время. Для определения момента, когда станции, ставшие участниками коллизии, должны выполнить повторную передачу, применяется алгоритм отсрочки. Станции CSMA/CD способны обнаруживать коллизии (поскольку, передавая данные, продолжают прием данных, проходящих по сети, и сверяют их с переданными данными), поэтому имеют информацию о том, должна ли быть выполнена повторная передача. Такой метод доступа применяется в традиционных сетях Ethernet и сетях IEEE 802.3, функционирующих в полудуплексном режиме. (В сети Ethernet, работающей в дуплексном режиме, метод доступа CSMA/CD не используется.) Это означает, что передачу данных по разделяемой сети Ethernet может выполнять одновременно только одна станция.
Описанный выше метод доступа был разработан в целях предоставления многочисленным сетевым станциям/устройствам разделяемого и равноправного доступа к общей среде. Он обеспечивает равноправный доступ станций к сети Ethernet на основе процесса арбитража, который позволяет определить, по каким правилам станции, подключенные к сети, могут обращаться к разделяемому каналу. Этот метод доступа предусматривает проверку станциями наличия несущей в сети перед передачей, и возобновление работы только через определенное время, если происходит коллизия. Промежуток времени, в течение которого станциям предоставляется возможность возобновить передачу, определяется с учетом продолжительности передачи 64-байтового фрейма по локальной сети Ethernet, в состав аппаратных средств которой могут входить повторители. Для нормальной работы сети такого типа должно быть соблюдено важное условие: сеть должна быть устроена так, чтобы при одновременной передаче коллизию могли обнаружить даже станции, расположенные в сети на максимальном расстоянии друг от друга (это расстояние называется “диаметром сети”). Для этого необходимо установить максимально допустимый диаметр сети, который принято называть доменом коллизий. В традиционной сети Ethernet и сети 802.3, функционирующей по принципу полудуплексной передачи, допустимые размеры домена коллизий определяют физические ограничения на длину применяемой кабельной разводки. В табл. 4.1 приведен перечень доменов коллизий для сетей с пропускной способностью 10/100/1000 Мбит/с.
Таблица 4.1. Примеры доменов коллизий традиционной сети Ethernet ' .и сети IEEE 802.3' /
Домены коллизий традиционной сети Ethernet и сети 802.3
Пропускная способность Диаметр сети
lOBaseX
Приблизительно 280 метров (коаксиальный кабель)
Ethernet
I0/100 BaseX
Приблизительно 205 метров (витая пара)
IEEE 802.3b
1000 BaseX
Приблизительно 20 метров
(волоконно-оптический и медный кабели)
IEEE 802.3z
При использовании некоторых типов кабелей могут быть установлены еще более жесткие ограничения.
Продолжительность передачи 64-байтового фрейма в сетях с пропускной способностью 10/100/1000 Мбит/с изменяется почти обратно пропорционально пропускной
способности сети, поэтому при использовании фреймов с минимальным размером 64 байта сеть lOOOBaseX не может иметь диаметр свыше 20 метров. Это ограничение можно преодолеть, увеличив значение минимально допустимого размера фрейма Ethernet, поскольку при этом возрастает продолжительность передачи фрейма по сети и коллизия может быть обнаружена станциями, находящимися на большем расстоянии друг от друга. При определенном значении минимально допустимого размера фрейма размер домена коллизий сети lOOOBaseX может быть увеличен до 100 метров на один сегмент; такой диаметр сети сопоставим с диаметром сети lOOBaseT.
Для обеспечения работы такой сети все станции должны подчиняться одинаковым правилам. Ниже приведены правила для сети CSMA/CD.
. Проверка наличия несущей в сети. Каждая станция следит за сигналами, передаваемыми по кабелю. При обнаружении передаваемого сигнала (несущей) станция не должна предпринимать попыток передачи фрейма. Если станция обнаруживает другой сигнал в кабеле во время передачи первых 64 байтов фрейма, она должна распознать, что передача фрейма совпала по времени с передачей другого фрейма и возникла коллизия.
. Обнаружение коллизий. Если станция обнаружила коллизию, она должна прекратить передачу фрейма и передать его повторно через промежуток времени, определяемый с помощью алгоритма вычисления отсрочки. Алгоритм вычисления отсрочки предусматривает подсчет числа повторных коллизий, если они имеются, для определения времени ожидания, на протяжении которого станция не должна повторно передавать фрейм. Этот алгоритм предусматривает удвоение времени ожидания при обнаружении каждой очередной коллизии. Такой метод позволяет станции определить, какое число попыток передачи данных завершилось неудачей в результате коллизии, а затем принять обоснованное предположение о том, когда можно будет повторить передачу в условиях более низкой вероятности возникновения коллизии. В алгоритме вычисления отсрочки применяется способ отслеживания и корректировки установок таймеров с учетом значения 2П, где п — число попыток повторной передачи данного фрейма, при которых была обнаружена коллизия. Полученный результат служит для определения диапазона значений от нуля до определенного числа временных интервалов; в этом диапазоне должно быть выбрано время ожидания. Алгоритм предусматривает случайный выбор значения из этого диапазона, как показано в табл. 4.2.
Таблица 4.2. Ал горитм отсрочки...i
Значение 2" Действия
'Станция выбирает время начала передачи в диапазоне от нуля до одного
временного интервала
Станция выбирает время начала передачи в диапазоне от нуля до трех вре
менных интервалов
Станция выбирает время начала передачи в диапазоне от нуля до семи вре
менных интервалов
...величина диапазона выбора времени начала передачи увеличивается про
порционально степени 2
Алгоритм предусматривает случайное определение отсрочки в зависимости от числа коллизий, и станция, работающая по этому алгоритму, обычно устанавливает определенный интервал перед повторной передачей.
Значение счетчика коллизий согласно этому алгоритму наращивается вплоть до 10, после чего перед повторной передачей выбирается штрафное время ожидания в диапазоне от 0 до 1023 временнь/х интервалов. Это приводит к значительному замедлению обмена данными, но данный алгоритм к тому же требует повторения попыток передачи фрейма вплоть до 16 подряд идущих коллизий. После этого попытки повторной передачи с помощью этого алгоритма полностью прекращаются, и для повторной передачи фрейма привлекается сетевой протокол более высокого уровня, такой как TCP/IP. Подобная ситуация свидетельствует о том, что в сети имеются серьезные неисправности.
После того как станция успешно передаст фрейм, счетчик коллизий (определяющий штрафное время) очищается (для данного фрейма) и станция больше не откладывает передачу следующих фреймов на время отсрочки. (Статистические данные интерфейса не уничтожаются; сбрасывается только таймер.) Как правило, станции, при передаче которыми данных реже встречались коллизии, имеют возможность обращаться к сети быстрее по сравнению с другими станциями, поскольку для них устанавливается меньшее время ожидания.
Локальные сети Ethernet и IEEE 802.3 являются широковещательными сетями. Иными словами, в них передаваемые фреймы доступны для всех станций, независимо от того, предназначены ли фреймы для этих станций. Каждая станция должна проверять принимаемые фреймы, чтобы определить, не является ли она станцией получа- , теля. Если фрейм предназначен для этой станции, он передается на более высокий уровень протокола для соответствующей обработки.
Различия между стандартами Ethernet и IEEE 802.3 весьма невелики. Стандарт Ethernet предоставляет доступ к службам, соответствующим уровням 1 и 2 эталонной модели OSI, а стандарт IEEE 802.3 определяет физический уровень (уровень 1) и часть средств доступа к каналу канального уровня (уровня 2), но не определяет протокол управления логическим каналом. Протоколы Ethernet и IEEE 802.3 реализованы на уровне аппаратных средств. Как правило, аппаратная реализация этих протоколов осуществляется в интерфейсной сетевой плате хост-компьютера или в микросхемах объединительной платы хост-компьютера.
Выше было описано, в каком режиме работы традиционная сеть Ethernet и сеть 802.3 являются сопоставимыми, а в следующих разделах рассматриваются различия в функциональных возможностях и средствах сетей этих двух типов. Стандарт IEEE 802.3 был основан на стандарте традиционной сети Ethernet, но в него были внесены значительные усовершенствования. Описанная выше организация функционирования сети не подходит для современных сетей провайдеров служб и производственных предприятий.
Дуплексный режим работы в сетях с пропускной способностью 10/100/1000 Мбит/с
В предыдущих разделах рассматривался полудуплексный режим работы сети (именно в нем применяется метод доступа CSMA/CD, таймеры отсрочки и т.д.). Дуплексный режим позволяет станциям одновременно и передавать, и принимать данные. В результате пропускная способность сети используется более эффективно, поскольку станциям
предоставляется открытый доступ к сетевой среде. Но такой режим работы может применяться только при условии, что взаимодействующие станции оборудованы интерфейсами, поддерживающими дуплексный режим Ethernet, а также подключены к коммутаторам Ethernet или соединены непосредственно друг с другом с помощью перекрестных кабелей Ethernet. Основной предпосылкой для использования дуплексного режима является наличие каналов типа “точка-точка” между всеми интерфейсами. В дуплексном режиме осуществляется попарное взаимодействие интерфейсов, поэтому коллизии отсутствуют и режим доступа CSMA/CD больше не требуется.
Автоматическое согласование
Алгоритм автоматического согласования применяется в устройствах Ethernet для автоматической настройки интерфейсов перед их использованием. Если два сетевых интерфейса поддерживают различные скорости или режимы передачи, то при их автоматическом согласовании происходит определение скорости и режима передачи, применимых для обоих интерфейсов. Простой повторитель не может поддерживать несколько скоростей; он предназначен только для воспроизведения в одном сегменте сигналов, передаваемых по другому сегменту. Поэтому для обеспечения взаимодействия станций, поддерживающих разные скорости, применяются так называемые интеллектуальные концентраторы, которые конструктивно состоят из ряда повторителей и коммутационной матрицы. Согласование выполняется только при первоначальном подключении станции к концентратору. Но если к одному и тому же интеллектуальному концентратору подключены также более медленные системы, то необходимо выполнить настройку более быстрых систем вручную для работы на скорости 10 Мбит/с.
В сетях Ethernet и IEEE 802.3 для проверки работы соединения применяются нормальные канальные импульсы (NLP — Normal Link Pulse), которые первоначально использовались для проверки состояния канала в сетях lOBaseT. Эти импульсы представляют собой сигналы, которые показывают наличие работоспособного канала при подключении станции к концентратору, и передаются между двумя непосредственно соединенными канальными интерфейсами (от станции к концентратору или от станции к станции). Импульсы NLP позволяют проверить наличие канала между устройствами, но не могут служить полноценным показателем того, что кабельная разводка сети не содержит неисправностей.
Дальнейшим развитием метода, предусматривающего использование импульсов NLP, является метод, в котором применяются быстрые канальные импульсы. Такие импульсы служат не для проверки наличия связи, а используются в процессе автоматического согласования для передачи информации о возможностях устройства. Как правило, в сетях lOOOBaseX средства автоматического согласования функционируют только на скорости 1000 Мбит/с, поэтому процесс согласования применяется для принятия решения об использовании только одного средства: дуплексного или полудуплексного режима передачи. В последнее время на рынке появляются новые версии интерфейсных плат, способные поддерживать процесс автоматического согласования скоростей от 10 до 1000 Мбит/с, но они еще не нашли достаточно широкого распространения.
Интерфейсные платы некоторых типов, предназначенные для работы на скорости 10/100 Мбит/с, выполняют так называемую операцию параллельного обнаружения смежного интерфейса, которая может применяться, если средства автоматического согласования заблокированы или не поддерживаются. При выполнении этой операции по сути происходит переход в аварийный режим, который вступает в действие,
когда операция автоматического согласования завершается неудачей. В интерфейсе, поддерживающем автоматическое согласование, автоматически выполняется настройка для работы в обычном полудуплексном режиме на скорости 10 Мбит/с.
Физические соединения
Стандарт IEEE 802.3 определяет несколько физических уровней, а стандарт Ethernet определяет только один уровень. Каждый протокол физического уровня IEEE 802.3 имеет имя, в котором кратко закодированы его характеристики. Кодируемые компоненты имени протокола физического уровня IEEE 802.3 показаны на рис. 4.1.
10 Base 5
Рис. 4.1. Компоненты имени протокола физического уровня IEEE 802.3
В табл. 4.3 и 4.4 приведены общие сведения о характеристиках спецификаций Ethernet версии 2 и IEEE 802.3.
Предусмотрено еще несколько реализаций спецификации lOOBase/t, но они не нашли широкого распространения по различным причинам. Следует особо отметить спецификацию 100BaseT4. В этой системе применяются четыре пары медных проводов, и она может использоваться в сетях передачи голоса и данных. Системы Ю/lOOBaseT показывают приемлемые характеристики при использовании кабеля передачи данных категории 5, и для них требуются только две пары медных проводов.
Протокол Ethernet в наибольшей степени напоминает протокол 10Base5 по стандарту IEEE 802.3. Оба эти протокола определяют сеть с шинной топологией, в которой каждая станция подключается к сетевой среде с помощью соединительного кабеля. В терминологии Ethernet этот кабель именуется кабелем трансивера. Кабель трансивера подключается к трансиверу, непосредственно соединенному с физической сетевой средой. Конфигурация IEEE 802.3 по сути является аналогичной, за исключением того, что соединительный кабель называется интерфейсом подключаемого устройства (AUI — Attached Unit Interface), а трансивер — устройством подключения к передающей среде (MAU — Media Attachment Unit). В обоих случаях соединительный кабель подключается к интерфейсной плате (или к интерфейсным схемам) оконечной станции.
Характеристика Спецификация EthernetХарактеристика Спецификация EthernetI Таблица 4.3. Физические характеристики сети с медным кабелем, определяемые спецификациями Ethernet версии 2 и IEEE 802.3
Характеристика Спецификация Ethernet
Характеристика Спецификация Ethernet
10Base5
10Base2
1 Bases
WBaseT
10Broad36
Пропускная спо-
10
10
10
1
10
10
собность (Мбит/с) Метод передачи
Узкополосная
Узкополосная
Узкополосная
Узкополосная
Узкополосная
Широкополосная
сигналов
передача
передача
передача
передача
передача
передача
Максимальная
500
500
185
250
100
1800
длина сегмента (м) Передающая среда
(Толстый) коакси-
(Толстый) коакси-
(Тонкий) коакси-
Нсэкранирован-
Неэкранирован-
Коаксиальный
альный кабель с
альный кабель с
альный кабель с
ная витая пара
ная витая пара
кабель с импедан-
Топология
импедансом 50 Ом Шинная
импедансом 50 Ом Шинная
импедансом 50 Ом Шинная
Звездообразная
Звездообразная
сом 50 Ом
Звездообразная
Спецификации IEEE 802.3
I Таблица 4.4. Физические характеристики сети с волоконно-оптическим кабелем, определяемые спецификацией IEEE 802.3
ХарактеристикаСпецификации IEEE 802.3
lOOBaseFX1000BaseFX
Пропускная способность (Мбит/с)
Метод передачи сигналов
Максимальная длина сегмента (м)
1001000
Узкополосная передачаУзкополосная передача
При использовании повторителя — 150 м; При использовании повторителя — 150 м; при эксплуатации в дуплексном режиме — при эксплуатации в дуплексном режиме — 2000 м. При использовании одномодового 2000 м. При использовании одномодового кабеля — до 6-10 кмкабеля — до 6-10 км
Передающая среда
Волоконно-оптический кабель (одномодовый Волоконно-оптическийкабель
или многомодовый)(одномодовый или многомодовый)
Топология
ЗвездообразнаяЗвездообразная
Форматы фреймов
Форматы фреймов Ethernet и IEEE 802.3 показаны на рис. 4.2.
SOF — разделитель начала фрейма
FCS — контрольная последовательность фрейма
Рис. 4.2. Форматы фреймов Ethernet и IEEE 802.3
Фреймы Ethernet и IEEE 802.3 начинаются с чередующейся последовательности единиц и нулей, которая называется преамбулой. Преамбула позволяет станциям- получателям определить, что вскоре начнется передача фрейма.
Во фреймах Ethernet и IEEE 802.3 перед адресом получателя находится байт разделителя начала фрейма (SOF — Start-Of-Frame). Этот байт оканчивается двумя последовательными битами 1, которые служат для синхронизации устройств приема фреймов во всех станциях локальной сети.
Во фреймах, передаваемых в локальных сетях Ethernet и IEEE 802.3, непосредственно за преамбулой следуют поля с адресами получателя и отправителя. И в Ethernet, и в IEEE 802.3 адреса имеют длину 6 байтов. Адреса записаны в аппаратных микросхемах интерфейсных плат Ethernet и IEEE 802.3. Первые 3 байта адреса назначаются организацией IEEE конкретным поставщикам, а последние 3 байта назначаются самим поставщиком оборудования Ethernet или IEEE 802.3. Адрес отправителя всегда представляет собой одиночный адрес (адрес отдельного узла), а адрес получателя может представлять собой одиночный, групповой или широковещательный адрес (общий для всех узлов).
Во фреймах Ethernet за адресом отправителя следует двухбайтовое поле типа. В этом поле определяется протокол верхнего уровня, которому должны быть переданы данные после завершения обработки протоколом Ethernet.
Во фреймах IEEE 802.3 за адресом отправителя следует двухбайтовое поле длины, которое указывает, сколько байтов данных следует за этим полем, а за ним находится поле контрольной последовательности фрейма (FCS — Frame Check Sequence).
Вслед за полем типа/длины находятся фактические данные, содержащиеся во фрейме. После завершения обработки на физическом и канальном уровнях данные в конечном итоге передаются программному обеспечению протокола верхнего уровня. В сети Ethernet протокол верхнего уровня указан в поле типа. В сети IEEE 802.3 протокол верхнего уровня должен быть, в случае необходимости, указан в части данных фрейма. Если данных во фрейме недостаточно для дополнения фрейма до минималь-
ной длины, которая составляет 64 байта, то производится вставка байтов заполнения, позволяющих увеличить длину фрейма до 64 байтов.
Во фрейме IEEE 802.3 поле данных, кроме заголовка тела фрейма, содержит саму полезную нагрузку (область данных) фрейма. Заголовок тела фрейма соответствует подуровню управления логическим каналом модели OSI и является полностью независимым от расположенных под ним подуровня МАС и физического уровня. Этот заголовок, который выполняет функции инкапсуляции протокола 802.2, содержит информацию о точке доступа к службе получателя (DSAP — Destination Service Access Point) и точке доступа к службе отправителя (SSAP — Source Service Access Point). С помощью этого заголовка программное обеспечение протоколов верхних уровней получает информацию о том, к какому типу фактически относятся данные, передаваемые в этом фрейме. Поэтому заголовок тела фрейма выполняет функции поля типа традиционного фрейма Ethernet и применяется сетевыми протоколами верхнего уровня, такими как IPX. В сетевом программном обеспечении, разработанном в целях поддержки набора сетевых протоколов TCP/IP, поле типа используется для определения типа протокола во фрейме Ethernet. Поле типа и заголовок LLC (Logical Link Control — подуровень управления логическим соединением) не заменяют друг друга, но позволяют обеспечить обратную совместимость между реализациями сетевых протоколов без переопределения всей спецификации фрейма Ethernet.
За полем данных следует четырехбайтовое поле FCS, содержащее значение циклического избыточного кода (CRC — Cyclic Redundancy Check). Код CRC формируется устройством-отправителем и повторно вычисляется устройством-получателем для определения того, не был ли фрейм искажен во время передачи.
Устранение нарушений в работе сети Ethernet
В табл. 4.5 приведены процедуры поиска неисправностей, связанных с обычными нарушениями в работе передающей среды Ethernet.
I Таблица 4.5. Процедуры поиска неисправностей, связанных с обычными !нарушениями в работе передающей среды Etherneti
Нарушение в работе Рекомендации по устранению неисправности передающей среды
Слишком высокий Шаг 1. Воспользуйтесь exec-командой show interfaces ethernet для опре- уровень шумаделения состояния интерфейсов Ethernet маршрутизатора. На на
личие слишком высокого уровня шума указывает значительное количество ошибок CRC при небольшом количестве коллизий.
Шаг 2. Проверьте кабели, чтобы убедиться в том, что в них отсутствуют повреждения.
Шаг 3. Найдите места подключения компьютеров к кабелю, расположенные через неправильные интервалы, которые могут вызвать зеркальное отражение сигнала.
Шаг 4. При использовании протокола lOOBaseTX убедитесь в том, что применяемая кабельная разводка относится к категории 5, а не к другому типу, например, к категории 3
Нарушение в работе передающей среды
Рекомендации по устранению неисправности
Слишком высокое значение относительного количества коллизий
Шаг 1. Воспользуйтесь командой show interfaces ethernet для проверки относительного количества коллизий. Отношение количества коллизий к общему количеству принятых фреймов не должно превышать приблизительно 0,1%.
Шаг 2. Воспользуйтесь динамическим рефлектометром для поиска всех кабелей Ethernet, на которых не установлены терминаторы (заглушки).
Шаг 3. Найдите подключенный к хосту трансивер, передающий искаженные данные. (Для этого может потребоваться осмотр каждого хоста или применение анализатора протокола.)
Чрезмерное количество слишком коротких фреймов
В разделяемой среде Ethernet причиной появления слишком коротких (“карликовых”) фреймов почти всегда являются коллизии. Если относительное количество коллизий велико, обратитесь к приведенному выше в данной таблице разделу с описанием проблемы, связанной с обнаружением слишком высокого значения относительного количества коллизий.
Если “карликовые” фреймы появляются при небольшом относительном количестве коллизий или обнаруживаются в коммутируемой среде Ethernet, они могут быть вызваны недобором данных или некачественным программным обеспечением сетевой интерфейсной платы. Воспользуйтесь анализатором протокола, чтобы попытаться определить исходный адрес фреймов с размерами меньше минимально допустимого
Запоздалые коллизии
Шаг 1. Воспользуйтесь анализатором протокола, чтобы проверить наличие запоздалых коллизий. (Запоздалыми называются коллизии, возникающие за пределами первых 64 байтов фрейма.) Запоздалые коллизии никогда не должны возникать в правильно спроектированной сети Ethernet. Они обычно появляются, если кабели Ethernet имеют слишком большую длину или в сети установлено слишком много повторителей.
Шаг 2. Проверьте диаметр сети и убедитесь в том, что он соответствует спецификации
Отсутствие связи по каналу в сети lOBaseT, 100BaseT4 или lOOBaseTX
Шаг 1. Убедитесь в том, что не используется протокол 100BaseT4 при наличии в кабеле только двух пар проводов. Для протокола 100BaseT4 требуется кабель с четырьмя парами проводов.
Шаг 2. Проверьте в сети lOBaseT, 100BaseT4 или lOOBaseTX соответствие типов аппаратных средств (например, убедитесь в том, что в порту концентратора не установлена неподходящая для него плата).
Шаг 3. Определите, применяются ли там, где это требуется, перекрестные кабели. (Например, убедитесь в том, что между станцией и концентратором не установлены прямые кабели.)
Шаг 4. Проверьте, не наблюдается ли в сети слишком высокий уровень шума (см. описание проблемы, связанной с наличием слишком высокого уровня шума, приведенное выше в этой таблице)
При поиске неисправностей передающей среды Token Ring в среде маршрутизатора Cisco можно воспользоваться командой show interfaces ethernet, которая предоставляет большой объем важной информации, позволяющей легко находить причины неисправностей. В следующем разделе подробно описаны команда show interfaces ethernet, а также предоставляемая ею информация.
Команда show interfaces ethernet
Привилегированная exec-команда show interfaces ethernet применяется для вывода информации об интерфейсе Ethernet маршрутизатора.
show interfaces ethernet unit [accounting].
show interfaces ethernet [siot | port] [accounting] (для маршрутизаторов ряда Cisco 7200 и Cisco 7500).
show interfaces ethernet [type slot | port-adapter | port] (для портов плат универсального интерфейсного процессора маршрутизаторов ряда Cisco 7500).
Описание синтаксической структуры
unit. В качестве этого параметра должен быть указан номер порта на выбранном интерфейсе.
accounting. (Необязательный параметр.) При использовании этого параметра отображается число пакетов, относящихся к протоколу каждого типа, проходящих через интерфейс.
slot. Для получения информации о гнездах и портах устройства обратитесь к соответствующему руководству по аппаратным средствам.
port. Для получения информации о гнездах и портах устройства обратитесь к соответствующему руководству по аппаратным средствам.
port-adapter. Для получения информации о совместимости адаптера порта обратитесь к соответствующему руководству по аппаратным средствам.
Командный режим
Предусматривает применение привилегированной ехес-команды.
Рекомендации по использованию
Эта команда впервые появилась в выпуске Cisco IOS 10.0. Если при вызове ее на выполнение не будет приведено значение параметра unit (параметров slot и port применительно к маршрутизатору ряда Cisco 7200 или параметров slot и port-adapter применительно к маршрутизатору ряда Cisco 7500), команда отображает статистические данные по всем сетевым интерфейсам. Необязательное ключевое слово accounting означает, что должно быть показано число пакетов, передаваемых через интерфейс по протоколу каждого типа.
Пример вывода
Ниже приведен пример вывода команды show interfaces для интерфейса Ethernet 0.
Router# show interfaces ethernet 0
Ethernet 0 is up, line protocol is up
Hardware is MCI Ethernet, address is aaOO.0400.0134 (via 0000.OcOO.4369)
Internet address is 131.108.1.1, subnet mask is 255.255.255.0
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usee, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, PROBE, ARP Timeout 4:00:00
Last input 0:00:00, output 0:00:00, output hang never
Output queue 0/40, 0 drops; input queue 0/75, 2 drops
Five minute input rate 61000 bits/sec, 4 packets/sec
Five minute output rate 1000 bits/sec, 2 packets/sec
2295197 packets input, 305539992 bytes, 0 no buffer
Received 1925500 broadcasts, 0 runts, 0 giants
3 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 input packets with dribble condition detected
3594664 packets output, 436549843 bytes, 0 underruns
8 output errors, 1790 collisions, 10 interface resets, 0 restarts
В табл. 4.6 приведены описания полей в выводе команды show interfaces ethernet.
i Таблица 4.6. Описания полей в выводе команды show interfaces ethernet
Поле
Описание
Ethernet ... is up | is
Указывает, являются ли в настоящее время аппаратные сред-
administratively down
ства интерфейса активными, или интерфейс был остановлен администратором. Значение "Disabled" указывает, что маршрутизатор обнаружил более 5000 ошибок в течение интер' вала передачи тестового пакета, который по умолчанию составляет 10 секунд
line protocol is (up | down |
Указывает, имеют ли программные процессы, которые отра-
administratively down)
батывают протокол канала передачи данных, информацию о том, что интерфейс пригоден для использования (т.е. успешно ли осуществляются операции передачи тестового пакета) или остановлен администратором
Hardware
Указывает тип аппаратных средств (например, MCI Ethernet, SCI, eBus Ethernet) и адрес
Internet address
Указывает адрес Internet, за которым следует маска подсети
MTU
Предоставляет данные о величине максимальной единицы передачи данных в сети для рассматриваемого интерфейса
BW
Предоставляет данные о величине пропускной способности интерфейса в килобитах в секунду
DLY
Предоставляет данные о задержке интерфейса в микросекундах
rely
Показывает относительную надежность интерфейса в виде числителя дроби со знаменателем 255 (где 255/255 соответствует 100%-ной надежности), рассчитанную как экспоненциальное среднее за время, превышающее 5 минут
load
Показывает относительную нагрузку на интерфейс в виде числителя дроби со знаменателем 255 (где 255/255 соответствует полностью загруженному интерфейсу), рассчитанную как экспоненциальное среднее за время, превышающее 5 минут
Поле
Описание
Encapsulation
ARP type loopback keepalive Last input
Указывает метод инкапсуляции, применяемый в интерфейсе Указывает тип применяемого протокола преобразования адресов Указывает, установлена ли петля обратной связи Указывает, применяются ли средства тестового пакета Предоставляет данные о количестве часов, минут и секунд, прошедших с момента успешного получения интерфейсом последнего пакета. Эти данные позволяют определить, когда произошел отказ интерфейса, который в данный момент является неисправным
Last output
Предоставляет данные о количестве часов, минут и секунд, прошедших с момента успешной передачи интерфейсом последнего пакета. Эти данные позволяют определить, когда произошел отказ интерфейса, который в данный момент является неисправным
output
Предоставляет данные о количестве часов, минут и секунд, прошедших с момента успешной передачи интерфейсом последнего пакета
output hang
Предоставляет данные о количестве часов, минут и секунд (или содержит значение never — никогда), прошедших с того момента, как интерфейс был последний раз сброшен в связи с тем, что передача данных потребовала слишком много времени. Если число часов в любом из “последних" полей превышает 24 часа, отображается чисто суток и часов. При переполнении значения в этом поле отображаются символы звездочек
Last clearing
Предоставляет данные о времени, когда в последний раз были переустановлены в нулевые значения счетчики, которые содержат накопленные статистические данные (такие как количество переданных и полученных байтов), показанные в этом отчете. Следует отметить, что при очистке счетчиков не очищаются переменные, которые могут повлиять на маршрутизацию (например, load и reliability).
, "***■■ — указывает, что значение истекшего времени слишком велико и поэтому не может быть отображено.
• "0: 00:00" — указывает, что с момента очистки счетчиков прошло больше 231 мс (и меньше 232 мс)
Output queue, input queue, drops
В этих полях представлены данные о количестве пакетов в выходных и во входных очередях. За каждым числом следуют косая черта, значение максимального размера очереди и данные о количестве пакетов, уничтоженных в связи с переполнением очереди
Five minute input rate
Five minute output rate
В этих полях приведены данные о среднем числе битов и пакетов, переданных и принятых в секунду за последние пять минут (значения средней скорости приема и передачи). Если интерфейс не находится в неизбирательном режиме, он воспринимает только передаваемый и получаемый им сетевой трафик (а не весь сетевой трафик).
Поле
Описание
Значения средней скорости приема и передачи за последние пять минут должны использоваться только в качестве приближенной оценки интенсивности трафика, измеренной в секунду в течение данного пятиминутного периода. Эти значения скорости представляют собой экспоненциальные взвешенные средние, при вычислении которых применялась постоянная времени, равная пяти минутам. Должен пройти период, равный учетверенному значению постоянной времени, прежде чем среднее значение установится в пределах 2% мгновенной скорости однородного потока трафика за этот период
packets input
Предоставляет информацию об общем количестве пакетов, полученных системой без ошибок
bytes input
Предоставляет информацию об обшем количестве байтов, включая данные и информацию инкапсуляции МАС, в пакетах, полученных системой без ошибок
no buffers
Количество полученных пакетов, которые были отвергнуты в связи с отсутствием свободного буферного пространства в основной системе. Сравните это значение со значением в поле ignored. События, связанные с отсутствием свободных входных буферов, часто возникают при лавинообразном увеличении количества широковещательных пакетов в сетях Ethernet и пакетов ошибок в последовательных каналах
Received ... broadcasts
Показывает общее количество пакетов с широковещательным или групповым адресом, принятых интерфейсом
Runts
Предоставляет информацию об обшем количестве “карликовых” пакетов, которые были отвергнуты в связи с тем, что имели раз- эдер меньше минимально допустимого в данной передающей среде. Например, “карликовым” считается любой пакет Ethernet, который имеет размер меньше 64 байтов
giants
Предоставляет данные о количестве “гигантских” пакетов, которые были отвергнуты в связи с тем, что имели размер больше максимально допустимого в данной передающей среде. Например, “гигантским” считается любой пакет Ethernet, который имеет размер больше 1518 байтов
input error
Содержит данные об общем количестве ошибок, включая данные, приведенные в полях runts, giants, no buffer, CRC, frame, overrun и ignored. В значение, представленное в поле input error, могут также входить данные о других ошибках, обнаруженных при приеме дейтаграмм, а некоторые дейтаграммы могут иметь несколько ошибок, поэтому значение в этом поле может не совпадать с суммой значений в указанных полях
CRC
Код CRC, сформированный станцией-отправителем в локальной сети или устройством, находящимся на другом конце канала передачи данных, не совпадает с контрольной суммой, вычисленной на основе полученных данных. В локальной сети ненулевое значение в этом поле обычно указывает на наличие шума или проблем передачи в интерфейсе локальной сети или в самой шине локальной сети. Большое количество ошибок CRC обычно является результатом коллизий или передачи какой-либо станцией ошибочных данных
Поле
Описание
frame
Количество неправильно принятых пакетов, которые имеют ошибки CRC и нецелое количество октетов. В локальной сети ненулевое значение этого показателя обычно является результатом коллизий или нарушений в функционировании устройства Ethernet
overrun
Показывает количество случаев, когда аппаратные средства приемного устройства не были способны передать полученные данные в аппаратный буфер, поскольку скорость ввода данных превысила способность приемного устройства обрабатывать данные
ignored
Показывает количество полученных пакетов, которые были проигнорированы интерфейсом из-за отсутствия свободных внутренних буферов в аппаратном обеспечении интерфейса. Эти буфера отличаются от упомянутых выше буферов системы, поскольку имеют другое описание. Увеличение значения в поле ignored может быть вызвано лавинообразным возрастанием количества широковещательных пакетов или появлением пакетов ошибок
input packets with dribble condition detected
Предоставляет информацию о количестве обнаруженных ошибок dribble bit, которые возникают, если длина фрейма незначительно превышает максимальную. Значение, приведенное в этом поле, используется только для справок; маршрутизатор принимает фреймы с такими ошибками
packets output
Предоставляет информацию об общем количестве сообщений, переданных системой
bytes
Предоставляет информацию об обшем количестве байтов, включая данные и информацию инкапсуляции МАС, в пакетах, переданных системой
underruns
Предоставляет информацию о количестве случаев, когда отправка данных передатчиком выполнялась быстрее, чем ее мог обработать маршрутизатор. В интерфейсах некоторых типов информация о таких случаях может никогда не предоставляться
output errors
Предоставляет информацию об общем количестве ошибок, которые исключили возможность выполнить окончательную передачу дейтаграмм из рассматриваемого интерфейса. Следует отметить, что это значение может не совпадать с суммой подсчитанных ошибок вывода, поскольку некоторые дейтаграммы могут иметь несколько ошибок, а другие — содержать ошибки, не попадающие ни в одну из конкретных рассматриваемых категорий
collisions
Предоставляет информацию о количестве сообщений, повторно переданных из-за коллизий в сети Ethernet. Обычно причиной коллизий является расширение размеров локальной сети сверх допустимых (слишком длинный кабель Ethernet или кабель трансивера, наличие более двух повторителей между станциями или слишком большое количество каскадно включенных многопортовых трансиверов). Пакет, повторно переданный после возникновения коллизии, регистрируется в поле packets output один раз
Поле
Описание
interface resets
Предоставляет информацию о количестве случаев полного сброса интерфейса. Такие ситуации возникают, если пакеты, поставленные в очередь для передачи, не передаются в течение нескольких секунд. В интерфейсе последовательного канала это может быть вызвано сбоем в работе модема, при котором не передается сигнал синхронизации передачи transmit clock, или неисправностью кабеля. Если система обнаруживает, что сигнал обнаружения несущей последовательного интерфейса активен, а протокол канала передачи данных не функционирует, то периодически сбрасывает интерфейс в целях его перезапуска. Случаи сброса интерфейса могут также возникать, если интерфейс подключен к петле обратной связи или остановлен
restarts
Предоставляет информацию о количестве случаев перезапуска контроллера Ethernet типа 2 из-за ошибок
Глава
5
Устранение нарушений в работе сети FDDI
Стандарт FDDI был разработан комитетом по стандартам ANSI ХЗТ9.5 в середине 1980-х годов. В то время быстродействующие рабочие станции, на которых были развернуты рабочие места проектировщиков, стали предъявлять к существующим локальным сетям, в основном к Ethernet и Token Ring, требования, выходящие за пределы их возможностей. В связи с этим возникла необходимость в создании локальных сетей новых типов, которые могли бы легко поддерживать такие рабочие станции и развернутые на них современные распределенные приложения. Вместе с тем повысилась значимость проблемы обеспечения высокой надежности сети, поскольку начался перевод приложений, предъявляющих высокие требования к надежности, с мэйн- фреймов на персональные компьютеры, подключенные к сети. Для удовлетворения этих потребностей была разработана спецификация FDDI.
После завершения разработки организацией ANSI спецификация FDDI была передана в международную организацию по стандартизации (ISO — International Organization for Standardization). Организацией ISO была создана международная версия стандарта FDDI, полностью совместимая с версией стандарта ANSI.
Несмотря на то что сети, основанные на спецификации FDDI, не нашли такого широкого распространения, как сети Ethernet и Token Ring, их относительное количе- ® ство постоянно увеличивается по мере снижения стоимости интерфейсов FDDI. В настоящее время FDDI часто применяется в качестве технологии опорной сети, а также в качестве средства подключения быстродействующих компьютеров к локальной сети.
Основы технологии FDD!
Спецификация FDDI определяет локальную сеть с пропускной способностью 100 Мбит/с, с эстафетной передачей и двойным кольцом, в которой используется волоконно-оптическая передающая среда. Эта спецификация определяет физический уровень и часть доступа к передающей среде канального уровня. Она может рассматриваться в основном как аналогичная спецификациям IEEE 802.3 и IEEE 802.5 с точки зрения ее соответствия эталонной модели OSI (Open System Interconnection — взаимодействие открытых систем).
> Сеть FDD1 во многом напоминает сеть Token Ring, несмотря на то, что функционирует с более высокими скоростями. Сети этих двух типов обладают многими общи-
ми особенностями, включая топологию (кольцо), метод доступа к передающей среде (эстафетная передача) и средства обеспечения надежности (например, резервные кольца). Дополнительная информация о сетях Token Ring и связанных с ними технологиях приведена в главе 6.
Одной из наиболее важных характеристик сети FDDI является то, что в ней в качестве передающей среды используются волоконно-оптические кабели. Волоконнооптические кабели обладают несколькими преимуществами над традиционными медными кабелями; в частности, они обеспечивают более высокий уровень защиты (стекловолокно не излучает электрические сигналы, которые могут быть перехвачены), надежность (стекловолокно не восприимчиво к электромагнитным помехам) и быстродействие (волоконно-оптический кабель в принципе позволяет достичь более высокой пропускной способности, чем медный кабель).
В стандарте FDDI регламентировано применение волоконно-оптических кабелей двух типов: одномодовых и многомодовых. Мода в данном контексте может рассматриваться как пучок световых лучей, которые входят в стекловолокно под определенным углом. Одномодовый волоконно-оптический кабель обеспечивает распространение по стекловолокну только одной моды света, а многомодовый волоконно-оптический кабель обеспечивает распространение по стекловолокну нескольких мод света. Разные моды света проходят по стекловолокну различные расстояния (в зависимости от входных углов), поэтому они поступают в место назначения в разное время (это явление называется дисперсией мод). В связи с этим одномодовый волоконно-оптический кабель обладает более высокой пропускной способностью и позволяет передавать данные на большее расстояние по сравнению с многомодовым волоконно-оптическим кабелем. По указанной причине одномодовые волоконно-оптические кабели часто применяются для наружной проводки, проложенной между зданиями, а многомодовые волоконно-оптические кабели прокладываются внутри здания. В сети с многомодовыми волоконно-оптическими кабелями в качестве генераторов светового излучения применяются светодиоды, а в одномодовых волоконнооптических кабелях обычно применяются лазеры.
Спецификации FDDI
Сеть FDDI определена четырьмя отдельными спецификациями (рис. 5.1).
Управление доступом к передающей среде (МАС — Media Access Control). Определяет способ доступа к передающей среде, включая формат фрейма, обработку маркера, адресацию, алгоритм вычисления циклического избыточного кода и механизмы исправления ошибок.
Протокол физического уровня (PHY — PHYsical layer protocol). Определяет процедуры кодирования/декодирования данных, требования к синхронизации, фреймирование и другие функции.
Передающая среда физического уровня (PMD — Physical layer MeDium). Определяет характеристики передающей среды, включая волоконно-оптический канал, уровни мощности, допустимые частоты передачи ошибочных битов, оптические компоненты и соединители.
Управление станцией (SMT — Station ManagemenT). Определяет конфигурацию станции FDDI, конфигурацию кольца и средства управления кольцом, включая вставку и удаление станций, инициализацию, изоляцию и восстановление при отказах, планирование и сбор статистических данных.
Рис. 5.1. Стандарты FDDI
Физические соединения
Стандарт FDDI регламентирует использование двойных колец. Трафик передается по этим кольцам в противоположных направлениях. Каждое кольцо состоит из двух или нескольких соединений типа “точка-точка” между смежными станциями. Одно из двух колец FDDI называется первичным, а другое — вторичным. Первичное кольцо применяется для передачи данных, а вторичное в основном используется в качестве резервного.
Станции класса В, или станции с одинарным подключением (SAS — Single Attachment Station), подключены к одному кольцу, а станции класса А, или станции с двойным подключением (DAS — Dual-Attachment Station), подключены к обоим кольцам. Станции SAS подключаются к первичному кольцу через концентратор^ йбторый позволяет подключать сразу несколько станций SAS. Концентратор позволяет предотвратить нарушения в работе кольца при отказе или выключении питания любой из этих станций SAS. Это особенно удобно, если к кольцу присоединяются персональные компьютеры или аналогичные устройства, на которых периодически включается и выключается питание.
Типичная конфигурация сети FDDI со станциями DAS и SAS показана на рис. 5.2.
Рис. 5.2. Узлы FDD1: станции DAS и SAS, а также концентратор
Каждая станция DAS сети FDDI имеет два порта, обозначенные как А и В. Эти порты применяются для подключения станции к двойному кольцу FDDI. Поэтому каждый порт обеспечивает соединение и с первичным, и со вторичным кольцом, как показано на рис. 5.3.
Станция DAS FDDI
Рис. 5.3. Порты станции DAS сети FDD!
Типы трафика
Сеть FDDI обеспечивает распределение пропускной способности сети в реальном времени, поэтому является идеальной средой для множества приложений различных типов. Такая поддержка в сети FDDI обеспечивается благодаря тому, что в ней определен трафик двух типов: синхронный и асинхронный. Синхронный трафик может потреблять определенную необходимую часть общей пропускной способности сети FDDI, которая равна 100 Мбит/с, а на поддержку асинхронного трафика выделяется вся оставшаяся часть. Синхронная пропускная способность распределяется для тех станций, которые должны иметь постоянный доступ к средствам передачи. Например, такая возможность требуется для передачи аудио- и видеоинформации. Другие станции используют оставшуюся пропускную способность асинхронно, т.е. доступ к сети им может предоставляться по истечении некоторого времени. В спецификации FDDI SMT определена распределенная схема обработки заявок на выделение пропускной способности, с помощью которой приложениям предоставляется определенная часть пропускной способности FDDI.
Асинхронная пропускная способность распределяется с использованием восьмиуровневой схемы приоритетов. Каждой станции присваивается уровень приоритета выделения асинхронной пропускной способности. Сеть FDDI разрешает также применять расширенные диалоги, при которых станции могут на время занимать всю асинхронную пропускную способность. Но механизм приоритетов FDDI может по существу заблокировать станции, не способные использовать синхронную пропускную способность и имеющие слишком низкий приоритет при распределении асинхронной пропускной способности.
Средства обеспечения отказоустойчивости
Спецификация FDDI регламентирует применение целого ряда средств обеспечения отказоустойчивости. Наиболее важным из этих средств является двойное кольцо. Если происходит отказ или нарушение подачи питания одной из станций в двойном кольце, или возникает повреждение в кабеле, то двойное кольцо автоматически преобразуется в одинарное кольцо (за счет применения способа развертывания трафика в противоположном направлении), как показано на рис. 5.4. На этом рисунке видно, что при отказе станции 3 двойное кольцо автоматически
развертывает трафик в обратном направлении в станциях 2 и 4, формируя одинарное кольцо. Станция 3 больше не находится в кольце, но для оставшихся станций работа сети продолжается.
Станция 1
Рис. 5.4. Конфигурация, возникшая после отказа станции и возобновления работы кольца
На рис. 5.5 показано, как происходит автоматическое устранение неисправностей кабельной системы в сети FDD1. Станции 3 и 4 развертывают в обратном направлении трафик, проходящий по кольцу, при обнаружении неисправности кабеля, проложенного между ними.
По мере роста сети FDDI вероятность появления многочисленных отказов в кольце возрастает. При возникновении в кольце двух отказов трафик, проходящий по кольцу, развертывается в противоположном направлении в двух местах, а это фактически приводит к разделению кольца на две отдельные части, не способные взаимодействовать друг с другом. При последующих отказах кольцо делится на еще более мелкие части.
Для предотвращения такой сегментации кольца могут применяться оптические реле транзитной передачи, которые изымают отказавшие станции из кольца. Пример применения оптического реле транзитной передачи приведен на рис. 5.6.
Станция 1
Станция 3
Рис. 5.5. Конфигурация, возникшая после обнаружения неисправности кабельной системы и возобновления работы кольца
Станция 3Станция 3
Рис. 5.6. Применение оптического реле транзитной передачи
Для создания дополнительной избыточности и обеспечения надежной работы в таких важных устройствах, как маршрутизаторы или хосты мэйнфреймов, применяется еще один метод повышения отказоустойчивости, называемый двойным подключением. При использовании этого метода важное устройство подключается к двум концентраторам. Одна пара кабелей связи с концентратором применяется в качестве активного канала, а вторая пара — в качестве пассивного. Пассивный канал остается в резервном режиме до тех пор, пока не будет обнаружен отказ первичного (активного) канала или концентратора, к которому он подключен. При обнаружении такой ситуации автоматически активизируется пассивный канал.
Форматы фреймов
Форматы фреймов FDDI (показанные на рис. 5.7) аналогичны форматам фреймов Token Ring.
Фрейм данных
Преамбула
Начальный разделитель
Поле управления фреймом
Адрес получателя
Адрес отправителя
Данные
FCS
Конечный разделитель
Поле состояния фрейма
Маркер
Преамбула
Начальный разделитель
Поле управления фреймом
Конечный разделитель
Рис. 5.7. Форматы фреймов FDDI
Ниже описаны поля фреймов FDDI.
Преамбула. Применяется для подготовки каждой станции к приему следующего за ней фрейма.
Начальный разделитель. Указывает начало фрейма и состоит из характерной комбинации битов, которые позволяют отличить его от остальной части фрейма.
Поле управления фреймом. Указывает размер полей адреса, сообщает, содержит ли фрейм асинхронные или синхронные данные, и включает другую управляющую информацию.
Адрес получателя. Содержит одиночный, групповой или широковещательный адрес. Как и в сетях Ethernet и Token Ring, адреса получателя FDDI имеют длину 6 байтов.
Адрес отправителя. Обозначает отдельную станцию, с которой был отправлен фрейм. Как и в сетях Ethernet и Token Ring, адреса отправителя FDDI имеют длину 6 байтов.
Данные. Содержит информацию, предназначенную для протокола верхнего уровня, или управляющую информацию.
Поле FCS. Станция-отправитель записывает в этом поле значение CRC, зависящее от содержания фрейма (как и в сетях Token Ring и Ethernet). Станция-
получатель повторно вычисляет этот код для определения того, не был ли фрейм искажен во время передачи. Если фрейм искажен, он отбрасывается.
Конечный разделитель. Содержит символы, отличные от данных, которые обозначают конец фрейма.
Состояние фрейма. Позволяет станции-отправителю определить, произошла ли ошибка и был ли фрейм распознан и скопирован станцией-получателем.
Спецификация CDDI
Широкому применению сетей FDDI для подключения персональных компьютеров в основном препятствует высокая стоимость волоконно-оптического кабеля. В то же время медные кабели на основе экранированной витой пары (STP — Shielded TwistedPair) и неэкранированной витой пары (UTP — Unshielded Twisted-Pair) являются относительно недорогими и широко доступными. Поэтому была разработана версия стандарта FDDI, предназначенная для создания сетей на основе медного кабеля, получившая название CDDI (Copper Distributed Data Interface — распределенный проводной интерфейс передачи данных).
Но для обеспечения возможности применения стандарта FDDI для создания сетей на основе медного кабеля необходимо решить ряд проблем. При передаче по проводам витой пары сигналов, достаточно мощных для того, чтобы их можно было надежно интерпретировать как данные, провода излучают электромагнитную энергию, представляющую собой электромагнитные помехи. При любых попытках реализовать стандарт FDDI на основе витой пары необходимо учитывать, что возникающее при этом электромагнитное излучение не должно превышать пределов, установленных в Соединенных Штатах Федеральной комиссией по связи (FCC — Federal Communications Commission), а в Европе — Европейским экономическим советом (EEC — European Economic Council). Для уменьшения электромагнитного излучения могут применяться три метода.
Перемешивание. Согласно стандарту FDD1, при отсутствии передаваемых данных по сети передается холостая комбинация битов, которая представляет собой строку двоичных единиц, т.е. периодический сигнал. Если такой сигнал передается по витой паре, на частоте этого сигнала создаются мощные электромагнитные помехи. Поэтому для устранения периодически повторяющихся комбинаций на данные FDDI перед их передачей накладывается псевдослучайная последовательность, что позволяет добиться более равномерного распределения спектра электромагнитных помех и тем самым ослабить их интенсивность.
Кодирование. При передаче данных по витой паре на более низких частотах появляется возможность повысить мощность сигнала, не увеличивая при этом интенсивность электромагнитных помех. Для уменьшения частоты передаваемого сигнала применяется схема кодирования MLT3, которая определяет порядок переключения между тремя уровнями выходного напряжения. При этом пик мощности сигнала сдвигается в область частот, не превышающих 20 МГц.
Выравнивание. Метод выравнивания предусматривает усиление высокочастотных составляющих сигнала перед передачей по кабелю UTP. Выравнивание может применяться в передатчике (для предварительной компенсации искажений), в приемнике (для последующей компенсации искажений), а также в том и в другом устройстве. Одно из преимуществ использования метода выравнивания в приемнике заключается в том, что он позволяет корректировать коэффициент компенсации в зависимости от длины кабеля.
Устранение нарушений в работе сети FDDI
В настоящем разделе описаны процедуры поиска неисправностей при решении обычных проблем передающей среды FDDI.
В табл. 5.1 перечислены проблемы, которые наиболее часто встречаются в сетях FDDI, и приведены общие рекомендации по решению этих проблем.
[ таблица 5.1. Проблемы передающей среды: специфйкация FDDI < м
Нарушение в работе передающей среды
Рекомендации по устранению неисправности
Неработоспособное кольцо FDDI
Шаг 1. Воспользуйтесь exec-командой show interfaces fddi для определения состояния интерфейсов FDDI маршрутизатора.
Шаг 2. Если команда show interfaces fddi показывает, что интерфейс и протокол канала передачи данных функционируют, выполните команду ping на каждом из маршрутизаторов, чтобы проверить наличие соединения между ними.
Шаг 3. Если интерфейс и протокол канала передачи данных функционируют, убедитесь в том, что МАС-адреса предыдущего и следующего смежных устройств соответствуют установленным требованиям.
Шаг 4. Если в полях адреса одного из указанных смежных устройств присутствуют все нули, это может быть связано с неисправностью физического соединения.
В этом случае (или если строка информации о состоянии не показывает, что интерфейс и протокол канала передачи данных находятся в работоспособном состоянии) проверьте соединения коммутационной панели или воспользуйтесь оптическим динамическим рефлектометром или экспонометром, чтобы проверить наличие соединения между смежными устройствами. Убедитесь в том, что мощность сигнала соответствует требованиям спецификаций
Произошел отказ предыдущего смежного устройства и установлено реле транзитной передачи
Реле транзитной передачи могут вызывать снижение уровня сигнала, поскольку они не ретранслируют сигналы, как обычные трансиверы.
Шаг 1. Проверьте предыдущее смежное устройство, чтобы определить, работоспособно ли оно.
Шаг 2. Если этот узел не функционирует и установлено реле транзитной передачи, устраните все неисправности, обнаруженные в предыдущем смежном устройстве
Во время поиска неисправностей передающей среды FDDI, функционирующей при поддержке маршрутизатора Cisco, можно воспользоваться командой show interfaces fddi, которая предоставляет большой объем важной информации, позволяющей легко находить причины неисправностей. В следующем разделе подробно описана команда show interfaces fddi, а также указана предоставляемая ею информация.
Команда show interfaces fddi
Воспользуйтесь exec-командой show interfaces fddi для получения информации об интерфейсе FDDI:
show interfaces fddi number [accounting];
show interfaces fddi [slot | port] [accounting] (маршрутизаторы ряда Cisco 7000 и Cisco 7200);
show interfaces fddi [slot | port-adapter | port] [accounting] (маршрутизаторы ряда Cisco 7500).
Описание синтаксической структуры
number. Номер порта на выбранном интерфейсе.
accounting. (Необязательный параметр.) Отображает число пакетов, переданных через данный интерфейс по протоколу каждого типа.
slot. Для получения информации о гнездах и портах устройства обратитесь к соответствующему руководству по аппаратным средствам.
port. Для получения информации о гнездах и портах устройства обратитесь к соответствующему руководству по аппаратным средствам.
port-adapter. Для получения информации о совместимости адаптера порта обратитесь к соответствующему руководству по аппаратным средствам.
Командный режим
Предусматривает применение ехес-команды.
Рекомендации по использованию
Эта команда впервые появилась в выпуске Cisco IOS 10.0.
В выпуске Cisco IOS 11.3 внесены изменения для включения варианта вывода, касающегося дуплексных, одно- и многомодовых адаптеров порта для FDDI (PA-F/FD- SM и PA-F/FD-MM).
Примеры вывода
Ниже приведена часть вывода результатов выполнения команды show interfaces fddi с данными, касающимися конкретного интерфейса FDDI на маршрутизаторе ряда Cisco 7500.
Router> show interfaces fddi 3/0
Fddi3/0 is up, line protocol is up
Hardware is exBus Fddi, address is 0000.0c02.adfl (bia 0000.0c02.adfl)
Internet address is 131.108.33.14, subnet mask is 255.255.255.0
MTU 4470 bytes, BW 100000 Kbit, DLY 100 usee, rely 255/255, load 1/255
Encapsulation SNAP, loopback not set, keepalive not set
ARP type: SNAP, ARP Timeout 4:00:00
Phy-A state is active, neighbor is B, emt signal bits 008/20C, status ILS
Phy-B state is active, neighbor is A, emt signal bits 20C/008, status ILS
ECM is in, CFM is thru, - is ring_op
Token rotation 5000 usee, ring operational 21:32:34
Upstream neighbor 0000.0c02.ba83, downstream neighbor 0000.0c02.ba83
Last input 0:00:05, output 0:00:00, output hang never
Last clearing of "show interface" counters 0:59:10
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
Five minute input rate 69000 bits/sec, 44 packets/sec
Five minute output rate 0 bits/sec, 1 packets/sec
113157 packets input, 21622582 bytes, 0 no buffer
Received 276 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
4740 packets output, 487346 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets, 0 restarts
0 transitions, 2 traces, 3 claims, 2 beacons
Ниже приведен пример вывода команды show interfaces fddi для дуплексного адаптера порта FDDI на маршрутизаторе ряда Cisco 7500.
Router# show interfaces fddi 0/1/0
FddiO/1/0 is up, line protocol is up
Hardware is exBus FDDI, address is 0060.ЗеЗЗ.3608 (bia 0060.ЗеЗЗ.3608)
Internet address is 2.1.1.1/24
MTU 4470 bytes, BW 100000 Kbit, DLY 100 usee, rely 255/255, load 1/255
Encapsulation SNAP, loopback not set, keepalive not set
ARP type: SNAP, ARP Timeout 04:00:00
FDX supported, FDX enabled, FDX state is operation
Phy-A state is maintenance, neighbor is Unknown, status HLS
Phy-B state is active, neighbor is A, status SILS
ECM is in, CFM is c_wrap_b, - is ring_op,
Requested token rotation 5000 usee, negotiated 4997 usee
Configured tvx is 2500 usee
LER for PortA = 0A, LER for PortB = 0A ring operational 00:02:45
Upstream neighbor 0060.3e73.4600, downstream neighbor 0060.3e73.4600
Last input 00:00:12, output 00:00:13, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
minute input rate 0 bits/sec, 0 packets/sec
minute output rate 0 bits/sec, 0 packets/sec
62 packets input, 6024 bytes, 0 no buffer
Received 18 broadcasts, 0 runts, 0 giants.
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
71 packets output, 4961 bytes, 0 underruns
output errors, 0 collisions, 0 interface resets
output buffer failures, 0 output buffers swapped out
transitions, 0 traces, 100 claims, 0 beacon
В табл. 5.2 описаны поля, в которых представлены результаты выполнения команды show interfaces fddi.
Таблица 5.2. Описания полей в выводе команды show interfaces fddi
Поле
Описание
Fddi is {up | down | administratively down}
Предоставляет информацию о номере процессорного блока интерфейса и сообщает, является ли аппаратное обеспечение интерфейса в настоящее время активным и способным передавать и принимать данные, или интерфейс остановлен администратором
line protocol is {up | down}
Указывает на то, имеют ли программные процессы, которые отрабатывают протокол канала передачи данных, информацию о том, что интерфейс пригоден для использования
Hardware
Предоставляет данные о типе аппаратных средств, за которыми следует аппаратный адрес
Internet address MTU
IP-адрес, за которым следует маска подсети
Значение максимальной единицы передачи данных в сети для рассматриваемого интерфейса
BW DLY rely
Пропускная способность интерфейса в килобитах в секунду Задержка интерфейса в микросекундах
Надежность интерфейса в виде числителя дроби со знаменателем 255 (где 255/255 соответствует 100%-ной надежности), рассчитанная как экспоненциальное среднее за период времени, превышающий пять минут
load
Нагрузка на интерфейс в виде числителя дроби со знаменателем 255 (где 255/255 соответствует полностью загруженному интерфейсу), рассчитанная как экспоненциальное среднее за период времени, превышающий пять минут
Encapsulation loopback keepalive ARP type FDX
Метод инкапсуляции, применяемый в интерфейсе Указывает, установлена ли петля обратной связи Указывает, применяются ли средства поддержки соединения Тип применяемого протокола преобразования адресов
Отображает информацию о дуплексном режиме. Представленные здесь значения относятся к двум категориям: поддерживаемые и не поддерживаемые. Если значение поддерживается, то в выводе команды показано, разрешен или запрещен дуплексный режим. Если дуплексный режим разрешен, отображается состояние процесса согласования FDX. Состояния согласования относятся только к процессу согласования дуплексного режима. Необходимо также убедиться в том, что интерфейс является исправным и работоспособным, изучив другие поля вывода команды show interfaces fddi, такие как line protocol и "-". Ниже перечислены состояния согласования.
idle. Интерфейс работает, но еше не находится в дуплексном режиме. Если такое состояние остается неизменным, это может означать, что интерфейс не соответствует всем условиям согласования (например, в кольце имеется больше двух станций).
request. Интерфейс работает, но еше не находится в дуплексном режиме. Если такое состояние остается неизменным, это может означать, что удаленный интерфейс не поддерживает или в нем не разрешен дуплексный режим.
confirm. Переходное состояние.
operation. Согласование выполнено успешно и обе станции работают в дуплексном режиме
Поле
Описание
Phy—{А | В}
Показывает состояние, в котором находится соединение Physical А или Physical В; это состояние может быть одним из следующих: off, active, trace, connect, next, signal, join, verify или break
neighbor
Состояния смежного устройства (перечислены ниже).
А. Указывает, что процесс CMT (Connection Management — управление соединениями) установил соединение со смежным устройством. Биты, полученные в процессе передачи сигналов СМТ, указывают, что смежное устройство представляет собой станцию DAS (Double Attachment Station — станция с двойным подключением) типа Physical А или концентратор, который подключен к первичному кольцу IN и вторичному кольцу OUT, если предусмотрено его подключение к двойному кольцу.
S. Указывает, что процесс СМТ установил соединение со смежным устройством и что биты, полученные в процессе передачи сигналов СМТ, позволяют определить, что смежное устройство относится к одному из типов Physical в станции с одинарным подключением (SAS — Single Attachment Station).
В. Указывает, что процесс СМТ установил соединение со смежным устройством и что биты, полученные в процессе передачи сигналов СМТ, позволяют определить, что смежное устройство представляет собой станцию с двойным подключением Physical или концентратор, который подключен к вторичному кольцу IN и первичному кольцу OUT, если предусмотрено его подключение к двойному кольцу.■
М. Указывает, что процесс СМТ установил соединение со смежным устройством и что биты, полученные в процессе передачи сигналов СМТ, позволяют определить, что смежное устройство маршрутизатора представляет собой концентратор типа Physical М, который служит в качестве ведущего устройства для подключенной станции или концентратора.
unk. Указывает, что данный сетевой сервер не выполнил до конца процесс СМТ и поэтому не имеет информации о смежном устройстве
cmt signal bits
Показывает переданные/полученные биты СМТ. Переданные биты имеют значение 0x008 для типа Physical А и значение 0х20С для типа Physical В. Число, указанное вслед за косой чертой (/), обозначает полученные биты сигнала. Если соединение не активно, то полученные биты имеют значение нуль (0); найдите в выводе результатов строку, которая начинается со слова Phy-B. Эта информация относится только к интерфейсам FIP (FDDI Interface Processor — интерфейсный процессор FDDI) процессора FDDI
status
Значение status показывает фактическое состояние волоконнооптического кабеля. В стандарте FDDI определены следующие значения.
• LSU (Line State Unknown — состояние канала неизвестно). Не соблюдены критерии перехода в какое-либо иное состояние канала или пребывания в текущем состоянии.
Поле
Описание
NLS (Noise Line State — состояние зашумленного канала). Переход в это состояние происходит после обнаружения 16 событий, которые могут быть связаны с воздействием шума, но при этом не соблюдены критерии перехода в какое-либо иное состояние канала.
MLS (Master Line State — состояние ведущего канала). Переход в это состояние происходит после получения восьми или девяти подряд идуших пар символов HQ или QH.
ILS (Idle Line State — состояние простаивающего канала). Переход в это состояние происходит после получения четырех или пяти символов простоя канала.
HLS (Halt Line State — состояние остановленного канала). Переход в это состояние происходит после получения 16 или 17 подряд идуших символов Н.
QLS (Qniet Line State — состояние неактивного канала). Переход в это состояние происходит после получения 16 или 17 подряд идуших символов Q или при снижении уровня сигнала обнаружения несущей.
ALS (Active Line State — состояние активного канала). Переход в это состояние происходит после получения пары символов JK, при высоком уровне сигнала обнаружения нссушей.
OVUF (Elasticity Bnffer Overflow/Underflow — переполнение/ опустошение эластичного буфера). Для подключенного устройства типа Physical нормальным состоянием является 1LS или ALS. Если в отчете показано состояние QLS, это означает, что волоконно-оптический кабель отключен от устройства типа Physical В, или не подключен к устройству другого типа Physical, или смежная станция не функционирует
ЕСМ is...
ЕСМ (Entity Coordination Management — управление координацией объектов) представляет собой подсистему SMT (Station ManagemenT — управление станцией), которая контролирует работу средств СЕМ (ConFiguration Management — управление конфигурацией) и PCM (Physical Connection Management — управление физическим соединением). Подсистема ЕСМ может находиться в одном из следующих состояний.
out. Маршрутизатор изолирован от сети.
in. Маршрутизатор активно связан с сетью. Это — нормальное состояние для подключенного маршрутизатора.
trace. Маршрутизатор пытается обнаружить неисправность, на которую указывает постоянно присутствующий в сети кадр устройства.
leave. Маршрутизатор выделил время на разрыв всех соединений перед выходом из сети.
path_test. Маршрутизатор проверяет свои внутренние пути.
Поле
Описание
insert. Маршрутизатор выделил время на вставку оптического реле транзитной передачи.
check. Маршрутизатор проверяет правильность подключения оптического реле транзитной передачи.
deinsert. Маршрутизатор выделил время на отмену вставки в сеть оптического реле транзитной передачи
CFM is...
Содержит информацию о текущем состоянии соединения МАС- устройства (МАС-устройством называется устройство, обладающее собственным МАС-адресом). Здесь CFM (ConFiguration Management) обозначает состояние управления конфигурацией, которое может иметь одно их следующих значений.
isolated. МАС-устройство не привязано к какому-либо типу соединения Physical.
wrap_a. МАС-устройство привязано к соединению типа Physical А. Осуществляется прием данных из соединения Physical А и передача в соединение Physical А.
wrap_b. МАС-устройство привязано к соединению типа Physical В. Осуществляется прием данных из соединения Physical В и передача в соединение Physical В.
wrap_s. МАС-устройство привязано к соединению типа Physical S. Осуществляется прием данных из соединения Physical S и передача в соединение Physical S. Это — нормальный режим для станции SAS
- is...
Дефисом (-) обозначается конечный автомат SMT, применяемый при управлении соединением МАС-устройства. Конечный автомат "-' может находиться в одном из следующих состояний.
isolated. МАС-устройство не предпринимает попыток принять участие в работе кольца. Это — начальное состояние.
поп_ор. МАС-устройство участвует в восстановлении работы кольца, но кольцо не функционирует.
ring_op. МАС-устройство участвует в работе нормально функционирующего кольца. Это — нормальное состояние, наблюдаемое в тот период времени, когда МАС-устройство связано с кольцом.
detect. Кольцо находилось в нерабочем состоянии дольше, чем обычно. Проверяется ситуация, связанная с наличием повторяющегося адреса.
non_op_dup. Были получены данные, указывающие на то, что адрес данного МАС-устройства совпадает с адресом другого МАС- устройства в кольце. Кольцо не находится в рабочем состоянии.
ring_op_dup. Были получены данные, указывающие на то, что адрес данного МАС-устройства совпадает с адресом другого МАС-устройства в кольце. В этом состоянии кольцо является работоспособным.
Поле
Описание
directed. МАС-устройство передаст фреймы кадра устройства, которые служат для кольца указанием на то, что устройство не может самостоятельно выйти из нерабочего состояния.
trace. Этим МАС-устройством была инициализирована трассировка, и конечный автомат "-" ожидает ее завершения перед запуском процедуры внутренней проверки пути
token rotation
Значение периода обращения маркера представляет собой заданное по умолчанию или установленное параметрами конфигурации значение периода обращения, которое определено командой fddi token-rotation-time. Оно используется всеми станциями в кольце. По умолчанию это значение составляет 5000 микросекунд. Для дуплексного режима FDDI в поле token rotation показано значение, применявшееся до перехода в дуплексный режим
negotiated
Фактическое (согласованное) время обращения маркера для целевого устройства
ring operational
Если кольцо находится в работоспособном состоянии, то в этом поле отображается значение согласованного времени обращения маркера для всех станций в кольце. Продолжительность работы показано в виде количества часов/минут/секунд, в течение которых кольцо находилось в рабочем состоянии. Если кольцо не функционирует, отображается сообщение "ring not operational"
Configured tvx
LEK
Upstream | downstream neighbor
Таймер передачи
Значение частоты ошибок в канале (сокращение от Link Error Rate) Показывает канонический МАС-адрес предыдущего или следующего смежного устройства для исходящего интерфейса. Если адрес не известен, то значение в этом поле представляет собой адрес неизвестного устройства FDDI (0x00 00 f8 00 00 00)
Last input
Предоставляет данные о количестве часов, минут и секунд, прошедших с момента успешного получения интерфейсом последнего пакета. Эти данные позволяют определить, когда произошел отказ интерфейса, который в данный момент является неисправным
output
Предоставляет данные о количестве часов, минут и секунд, прошедших с момента успешной передачи интерфейсом последнего пакета
output hang
Предоставляет данные о количестве часов, минут и секунд (или содержит значение never — никогда), прошедших с того момента, как интерфейс был последний раз сброшен в связи с тем, что передача данных потребовала слишком много времени. Если число часов в любом из “последних" полей превышает 24 часа, отображается число суток и часов. При переполнении значения в этом поле отображаются символы звездочек
Last clearing
Предоставляет данные о времени, когда в последний раз были переустановлены в нулевые значения счетчики, которые содержат накопленные статистические данные (такие как количество переданных и полученных байтов), показанные в этом отчете. Следует отметить, что при очистке счетчиков не очищаются переменные, которые могут повлиять на маршрутизацию (например, load и reliability).
Поле
Описание
«***" _ указывает, что значение истекшего времени слишком велико и поэтому не может быть отображено.
"0:00:00" — указывает, что с момента очистки счетчиков прошло больше 231 мс (и меньше 232 мс)
Queuing strategy
Способ организации очереди. Обычно применяется способ fifo (сокращение от first-in, first-out — первым прибыл, первым обслужен). К числу других возможных способов относятся prioritylist, custom-list и weighted fair
Output queue, input queue, drops
В этих полях представлены данные о количестве пакетов в выходных и во входных очередях. За каждым числом следуют косая черта, значение максимального размера очереди и данные о количестве пакетов, уничтоженных в связи с переполнением очереди
5 minute input rate,
5 minute output rate
Среднее количество битов и пакетов, переданных и принятых в секунду за последние пять минут (значения средней скорости приема и передачи).
Значения средней скорости приема и передачи за последние пять минут должны использоваться только в качестве приближенной оценки интенсивности трафика, измеренной в секунду в течение данного пятиминутного периода. Эти значения скорости представляют собой экспоненциальные взвешенные средние, при вычислении которых применялась постоянная времени, равная пяти минутам. Должен пройти период, равный учетверенному значению постоянной времени, прежде чем среднее значение установится в пределах 2% мгновенной скорости однородного потока трафика за этот период
packets input bytes
Общее количество пакетов, полученных системой без ошибок
Общее количество байтов, включая данные и информацию инкапсуляции МАС, в пакетах, полученных системой без ошибок
no buffer
Количество полученных пакетов, которые были отвергнуты в связи с отсутствием свободного буферного пространства в системе. Сравните это значение со значением в поле ignored. События, связанные с отсутствием свободных входных буферов, часто возникают при лавинообразном увеличении количества широковещательных пакетов в сетях Ethernet и пакетов ошибок в последовательных каналах
broadcasts
Обшее количество широковещательных или многоадресатных пакетов, полученных через данный интерфейс
runts
Количество пакетов, которые были отвергнуты, поскольку имели размер меньше минимально допустимого в этой передаюшей среде
giants
Количество пакетов, которые были отвергнуты, поскольку имели размер больше максимально допустимого в этой передаюшей среде
CRC
Код CRC, сформированный станцией-отправителем в локальной сети или устройством, находящимся на другом конце канала передачи данных, не совпадает с контрольной суммой, вычисленной на основе полученных данных. В локальной сети ненулевое значение в этом поле обычно указывает на наличие шума или проблем передачи в интерфейсе локальной сети или в самой шине локальной сети. Большое количество ошибок CRC обычно является результатом коллизий или передачи какой-либо станцией ошибочных данных
Поле
Описание
frame
Количество неправильно принятых пакетов, которые имеют ошибки CRC и нецелое количество октетов. В локальной сети ненулевое значение этого показателя обычно является результатом коллизий или нарушений в функционировании устройства Ethernet. В локальной сети FDDI такие ошибки могут также возникать при наличии неисправного волоконно-оптического кабеля (содержащего дефекты в стекловолокне) или при нарушениях в работе аппаратных средств
overrun
Количество случаев, когда аппаратные средства последовательного приемного устройства не были способны передать полученные данные в аппаратный буфер, поскольку скорость ввода данных превысила способность приемного устройства обрабатывать данные
ignored
Количество полученных пакетов, которые были проигнорированы интерфейсом из-за отсутствия свободных внутренних буферов в аппаратном обеспечении интерфейса. Эти буфера отличаются от упомянутых выше буферов системы, поскольку имеют другое описание. Увеличение значения в поле ignored может быть вызвано лавинообразным возрастанием количества широковещательных пакетов или появлением пакетов ошибок
packets output bytes
Общее количество сообщений, переданных системой
Общее количество байтов, включая данные и информацию инкапсуляции МАС, переданных системой
underruns
Количество случаев аварийного завершения передачи (связанных с тем, что маршрутизатор не мог достаточно быстро отправлять данные передатчику)
output errors
Обшее количество ошибок, которые исключили возможность выполнить окончательную передачу дейтаграмм из рассматриваемого интерфейса. Следует отметить, что это значение может не совпадать с суммой подсчитанных ошибок вывода, поскольку некоторые дейтаграммы могут иметь несколько ошибок, а другие — содержать ошибки, не попадающие ни в одну из конкретных рассматриваемых категорий
collisions
Поскольку в кольце FDDI не могут возникать коллизии, в этом поле всегда проставлено значение 0
interface resets
Количество случаев, связанных со сбросом интерфейса. Интерфейс может быть сброшен вручную (администратором) или автоматически (при возникновении внутренней ошибки)
restarts
Для интерфейсов FDDI в этом поле всегда должно находиться значение 0
output buffer failures
Количество ошибок, связанных с отсутствием ресурсов и полученных при выводе
output buffers swapped out transitions
Количество пакетов, выведенных на время в динамическое ОЗУ
Количество случаев перехода кольца из работоспособного в неработоспособное состояние и наоборот. Большое количество переходов указывает на наличие неисправностей в кольце или в интерфейсе
traces
Указывает количество случаев, когда в этом интерфейсе была начата операция трассировки. Информация о количестве операций трассировки относится к блокам FCI, FC1T и FIP
Поле
Описание
claims
Относится только к блокам FCIT и FIP. Показывает количество случаев, когда данный интерфейс был в состоянии передачи требования
beacons
Относится только к блокам FCIT и F1P. Показывает количество случаев, когда интерфейс был в состоянии передачи кадра устройства
.-«4
Глава
6
Устранение нарушений
гв работе сети Token Ring
Сеть Token Ring была первоначально разработана корпорацией IBM в 1970-х годах.
Она все еще остается основной технологией локальной сети в корпорации IBM и в ,целом занимает второе место по распространенности после технологии Ethernet/IEEE ' 802.3. Спецификация IEEE 802.5 почти идентична и полностью совместима со спе- 1 цификацией сети Token Ring корпорации IBM. В действительности спецификация у, IEEE 802.5 была создана на основе спецификации Token Ring корпорации IBM, и по- ъ следующие ее версии отражают все изменения в спецификации Token Ring. Поэтому термин сеть Token Ring обычно используется для обозначения и сети Token Ring корпорации IBM, и сети IEEE 802.5.
Сравнение спецификаций Token Ring и IEEE 802.5
Сети Token Ring и IEEE 802.5 фактически полностью совместимы, но их спецификации имеют относительно небольшие отличия. Спецификация сети Token Ring корпорации IBM определяет звездообразную топологию, в которой все станции под- ^Йитючены к устройству/называемому многостанционным модулем доступа (MSAU — MultiStation Access Unit), а спецификация IEEE 802.5 не определяет топологию (но практически все реализации IEEE 802.5 также основаны на звездообразной топологии). Есть и другие отличия, включая обозначение типа передающей среды (в спецификации IEEE 802.5 не определен тип передающей среды, а в спецификации IBM Token Ring регламентируется использование кабеля на основе витой пары) и размер поля информации о маршрутизации. На рис. 6.1 приведены сводные данные о спецификациях сетей IBM Token Ring и IEEE 802.5.
Сеть IBM Token Ring
Сеть
IEEE 802.5
Скорости передачи данных
4 или
16 Мбит/с
4 или
16 Мбит/с
Количество станций в сегменте
280 (экранированная витая пара) 72 (неэкранированная витая пара)
250
Топология
Звездообразная
Не определена
Передающая среда
Витая пара
Не определена
Передача сигналов
Узкополосная
Узкополосная
Метод доступа
Эстафетная передача
Эстафетная передача
Кодировка
Дифференциальная манчестерская
Дифференциальная манчестерская
Рис. 6.1. Сравнение спецификаций сетей IBM Token Ring и IEEE 802.5
Эстафетная передача
Сети Token Ring и IEEE 802.5 представляют собой типичные примеры сетей с эстафетной передачей. В сетях с эстафетной передачей по сети постоянно циркулирует небольшой фрейм, называемый маркером. Для станций такой сети, которые называют также узлами, обладание маркером равносильно получению права на передачу. Если узел, получивший маркер, не имеет информации для отправки, он просто передает маркер следующей станции. Для каждой станции установлен максимальный период времени, в течение которого она может хранить маркер.
Если станция, обладающая маркером, имеет данные для передачи, она захватывает маркер, изменяет бит 1 его двоичного представления (в результате чего маркер превращается в последовательность начала фрейма), добавляет к нему информацию, предназначенную для передачи, и, наконец, отправляет эту информацию на следующую станцию в кольце. Пока в сети движется информационный фрейм, в ней отсутствует маркер (если только кольцо не поддерживает режим преждевременного освобождения маркера), поэтому все остальные станции, на которых имеется информация для передачи, должны ждать. Таким образом, в сетях Token Ring не могут возникать коллизии. Если же в сети поддерживается режим преждевременного освобождения маркера, то после завершения передачи фрейма станция может отправить новый маркер.
Информационный фрейм, движущийся по кольцу, достигает намеченной станции- получателя, которая копирует передаваемую в нем информацию для дальнейшей об-
работки. Затем информационный фрейм продолжает двигаться по кольцу и окончательно уничтожается после достижения станции-отправителя. Станция-отправитель может проверить возвратившийся фрейм, чтобы определить, был ли он обнаружен, а затем скопирован станцией-получателем.
В отличие от сетей с множественным доступом и обнаружением коллизий (CSMA/CD), таких как Ethernet, сети с эстафетной передачей работают в детерминированном режиме. Иными словами, всегда можно рассчитать максимальное время, которое должно пройти до того, как любая из станций сети получит возможность передавать данные. Благодаря этой особенности сети в сочетании с некоторыми средствами повышения надежности, которые рассматриваются в разделе “Механизмы повышения отказоустойчивости”, приведенном ниже в этой главе, сети Token Ring являются наиболее подходящими для приложений, в которых сетевая задержка должна быть предсказуемой и очень важна надежная работа сети. Примерами таких приложений являются системы автоматизированного производства.
Физические соединения
Станции сети IBM Token Ring непосредственно подключены к модулям MSAU, которые могут быть соединены между собой для формирования одного большого кольца (как показано на рис. 6.2). Для подключения модулей MSAU к смежным модулям MSAU применяются так называемые соединительные кабели, а для подключения станций к модулю MSAU применяются ответвительные кабели. В состав оборудования модуля MSAU входят реле транзитной передачи, позволяющие удалять станции из кольца.
Вход ЕMSAUкольцо 1234567Вход ЕMSAUкольцо 1234567Выход изВыход изВход вMSAUВыход из
Вход ЕMSAU
кольцо 1234567
Вход ЕMSAU
кольцо 1234567
Выход из
Выход из
СтанцииСтанцииСоединительные кабелиСоединительные кабелиРис. 6.2. Физические соединения в сети IBM Token RingРис. 6.2. Физические соединения в сети IBM Token Ringкольцо 12345678 кольца
Станции
Станции
Соединительные кабели
Соединительные кабели
Рис. 6.2. Физические соединения в сети IBM Token Ring
Рис. 6.2. Физические соединения в сети IBM Token Ring
Система приоритетов
В сетях Token Ring применяется сложная система приоритетов, которая позволяет конкретным высокоприоритетным станциям, назначенным сетевым администратором, использовать сеть чаше по сравнению с другими станциями. Во фреймах Token Ring имеются два поля управления приоритетом: поле приоритета и поле резервирования.
Если по сети передается маркер с установленным значением приоритета, его могут захватывать только станции, которые имеют равный или более высокий приоритет. После захвата маркера и преобразования его в информационный фрейм этот маркер могут зарезервировать для последующей передачи информации по сети только станции с более высоким значением приоритета по сравнению с передающей станцией. При формировании следующего маркера он включает более высокий приоритет зарезервировавшей его станции. Но станция, которая повысила уровень приоритета маркера, должна восстановить первоначальный приоритет после завершения передачи.
Механизмы повышения отказоустойчивости
В сетях Token Ring предусмотрено несколько механизмов обнаружения и устранения нарушений в работе сети. Например, одна из станций в сети Token Ring выбирается для использования в качестве активного монитора. Эта станция, которой может в принципе стать любая станция в сети, действует в качестве централизованного источника информации о синхронизации для других станций в кольце и выполняет ряд функций управления кольцом. Одной из этих функций является удаление из кольца непрерывно циркулирующих фреймов. В частности, при отказе передающего устройства отправленный им фрейм может не уничтожаться и продолжать циркулировать по кольцу. В результате исключается возможность передачи собственных фреймов другими станциями, и сеть фактически блокируется. Активный монитор может обнаруживать такие фреймы, удалять их из кольца и генерировать новый маркер.
Применение в сети IBM Token Ring звездообразной топологии также способствует повышению общего уровня надежности сети. Поскольку вся информация в сети Token Ring воспринимается активными блоками MSAU, эти устройства могут быть запрограммированы для контроля неисправностей и избирательного удаления станций из кольца в случае необходимости.
В сетях Token Ring применяется также так называемый алгоритм передачи кадра устройства, который позволяет обнаруживать некоторые нарушения в работе сети и предпринимать попытки их устранения. Обнаружив в сети серьезную неисправность (такую как разрыв кабеля), станция отправляет фрейм с кадром устройства, который содержит информацию о том, на каком участке сети возникла неисправность (который принято называть областью действия неисправности), в частности, указывает, какая станция сообщает об отказе, какое устройство является по отношению к ней ближайшим активным предыдущим смежным устройством (NAUN — Nearest Active Upstream Neighbor), и т.д. С передачи кадра устройства начинается так называемый процесс автореконфигурации, при котором узлы, находящиеся в области действия неисправности, автоматически выполняют диагностические процедуры и предпринимают попытки выбрать работоспособную конфигурацию сети, чтобы обойти неисправный участок. В конечном итоге реконфигурация сети осуществляется модулем MSAU с применением средств электронной коммутации.
Форматы фреймов
В сетях Token Ring определены два типа фреймов: маркеры и фреймы данных/команд.
Оба эти формата приведены на рис. 6.3.'
Фрейм данных/команды
Длина поля в байтах 11166>041
Начальный разделитель
Управление доступом
Поле управления фреймом
Адрес получателя
Адрес отправителя
Данные
FCS
Конечный разделитель
Маркер
Начальный разделитель
Управление доступом
Конечный разделитель
Рис. 6.3. Форматы фреймов сетей Token Ring и IEEE 802.5
Маркеры
Каждый маркер имеет длину 3 байта и состоит из начального разделителя, байта управления доступом и конечного разделителя.
Начальный разделитель служит для передачи каждой станции сообщения о прибытии маркера (или фрейма данных/команд). Это поле имеет формат, позволяющий отличить байт начального разделителя от остальной части фрейма, поскольку в нем нарушается схема кодирования, применяемая во всех прочих полях фрейма.
Байт управления доступом содержит поля приоритета и резервирования, а также бит маркера (позволяющий отличить маркер от фрейма данных/команд) и бит монитора (применяемый активным монитором для обнаружения фреймов, бесконечно циркулирующих по кольцу).
Конечный разделитель обозначает конец маркера фрейма или данных/команд. Он также содержит биты, обозначающие искаженный фрейм и фрейм, который завершает логическую последовательность.
Фреймы данных/команд
Размеры фреймов данных/команд зависят от размера информационного поля. Фреймы данных переносят информацию для протоколов верхнего уровня, а фреймы команд содержат управляющую информацию и не имеют данных, предназначенных для протоколов верхнего уровня.
Во фреймах данных/команд за байтом управления доступом следует служебный байт фрейма. Служебный байт фрейма показывает, содержит ли фрейм данные или управляющую информацию. В управляющих фреймах этот байт обозначает тип управляющей информации.
Вслед за служебным байтом фрейма находятся два поля адреса, которые содержат адреса получателя и отправителя. Как и в спецификации IEEE 802.3, адреса имеют длину 6 байтов.
За полями адреса находится поле данных. Длина этого поля зависит от значения времени задержки маркера в кольце, которое определяет максимально допустимую продолжительность задержки маркера станцией.
За полем данных следует поле" FCS. В это поле станция-отправитель записывает значение, вычисленное по содержимому фрейма. Станция-получатель снова вычисляет это значение, чтобы определить, не был ли фрейм искажен во время передачи. При обнаружении такого искажения фрейм отбрасывается.
Фрейм данных/команд, как и маркер, завершается конечным разделителем.
Устранение нарушений в работе сети
Token Ring
В настоящем разделе описаны процедуры поиска неисправностей при решении обычных проблем передающей среды Token Ring. Здесь рассматриваются конкретные признаки неисправностей в сети Token Ring, перечислены проблемы, которыми может быть обусловлено появление каждого признака неисправности, и показаны способы решения этих проблем.
Нарушения в работе передающей среды сети Token Ring
В табл. 6.1 перечислены проблемы, которые наиболее часто встречаются в сетях Token Ring, и приведены общие рекомендации по решению этих проблем.
Таблица 6.1. Нарушения в работе передающей среды сети Token Ring ,
Нарушение в работе _ передающей среды Рекомендации по устранению неисправности
Неработоспособное кольцо Token RingНеработоспособное кольцо Token RingШаг 1. Воспользуйтесь командой show interfaces token для определения состояния интерфейсов маршрутизатора Token Ring.
Неработоспособное кольцо Token Ring
Неработоспособное кольцо Token Ring
Шаг 2. Если строка с информацией о состоянии не указывает, что интерфейс и протокол канала передачи данных функционируют нормально, проверьте кабель от маршрутизатора к модулю многостанционного доступа MSAU (MultiStation Access Unit). Убедитесь в том, что кабель полностью исправен. Если кабель неисправен, замените его.
Несоответствие спецификаций скорости кольцаНесоответствие спецификаций скорости кольцаШаг 3. Если нарушения в работе обнаружены после установки нового сетевого оборудования, проверьте, была ли должным образом выполнена инициализация модуля MSAU. Для получения информации об инициализации модуля MSAU обратитесь к документации изготовителя
Несоответствие спецификаций скорости кольца
Несоответствие спецификаций скорости кольца
Шаг 1. Проверьте спецификацию скорости кольца на всех узлах, подключенных к опорной сети Token Ring. В параметрах конфигурации всех станций должна быть установлена одинаковая скорость кольца (4 Мбит/с или 16 Мбит/с). Воспользуйтесь привилегированной exec-командой show running-config, чтобы определить, какая скорость указана в маршрутизаторе.
Нарушение в работе передающей среды
Рекомендации по устранению неисправности
Открытый ретранслятор в модуле MSAU
Шаг 2. В случае необходимости измените спецификации скорости кольца для клиентов, серверов и маршрутизаторов. На маршрутизаторах для изменения скорости кольца воспользуйтесь командой конфигурации интерфейса ring-speed.
Если это потребуется, переставьте перемычки на модульных маршрутизаторах, которые не обеспечивают настройку скорости кольца программным путем. Для получения дополнительной информации о спецификациях скорости кольца обратитесь к руководству по монтажу и техническому обслуживанию аппаратных средств для конкретной системы
Шаг 1. Если на консоли во время включения системы появляется со- обшение "open lobe fault", проверьте кабельное соединение с модулем MSAU.
Шаг 2. Воспользуйтесь привилегированной exec-командой clear interface, чтобы выполнить сброс интерфейса Token Ring и снова вставить маршрутизатор в кольцо.
Шаг 3. Для всех плат Token Ring, кроме CTR и маршрутизаторов доступа необходимо применить команду clear interface для повторной инициализации интерфейса Token Ring, если произошел останов интерфейса.
Шаг 4. Воспользуйтесь exec-командой show interfaces token, чтобы проверить, исправно ли функционируют интерфейс и протокол канала передачи данных.
Шаг 5. Если интерфейс функционирует нормально, но сообщение "open lobe fault” продолжает появляться и маршрутизатор все еще не может соединиться с кольцом, подключите маршрутизатор к другому порту MSAU.
Шаг 6. Если и в этом случае сообщение "open lobe fault" продолжает появляться, отключите от модуля MSAU все устройства и выполните сброс ретранслятора MSAU с помощью инструментального средства, предоставленного поставщиком модуля MSAU.
Шаг 7. Снова подключите маршрутизатор и определите, может ли он соединиться с кольцом. Если сброс ретранслятора не позволил устранить неисправность, попытайтесь заменить модуль MSAU заведомо исправным.
Шаг 8. Если маршрутизатор все еще не может соединиться с кольцом, проверьте внутренние кабельные соединения плат маршрутизатора Token Ring. Убедитесь в том, что провода кабелей, относящихся к портам с соответствующими номерами, правильно подключены к разъемам и что кабели не переставлены местами.
Шаг 9. Если маршрутизатор все еше не может соединиться с кольцом, замените кабели подключения маршрутизатора к модулю MSAU заведомо исправными кабелями.
Нарушение в работе передающей среды
Рекомендации по устранению неисправности
Шаг 10. Воспользуйтесь командой clear interface, чтобы выполнить сброс интерфейса и снова вставить маршрутизатор в кольцо. Выполните команду show interfaces token, чтобы проверить, исправно ли функционируют интерфейс и протокол канала передачи данных.
Шаг 11. Еще один вариант состоит в том, что маршрутизатор может быть подключен к резервному модулю MSAU, к которому не присоединены какие-либо станции. Если маршрутизатор сможет подключиться к кольцу, замените основной модуль MSAU
Повторяющийся
МАС-адрес
Эта проблема может возникнуть, если в маршрутизаторах используются МАС-адреса, назначаемые на месте сетевым администратором.
Шаг 1. Воспользуйтесь сетевым анализатором, чтобы проверить наличие контрольного фрейма Duplicate Address, поступающего от загружаемой станции. Если станция получает ответ, то в кольце есть другая станция, в конфигурации которой определен МАС-адрес загружаемой станции.
Шаг 2. Если в кольце есть две станции с одинаковыми МАС- адресами, измените МАС-адрес одной из станций и повторно инициализируйте сетевой узел
Перегруженное
КОЛЬЦО
Шаг 1. Вставьте маршрутизатор в кольцо в тот период, когда в сети нет пиковой нагрузки.
Шаг 2. Если в период внепиковых нагрузок вставка маршрутизатора осуществляется успешно, а во время пиковой нагрузки завершается неудачей, сегментируйте объединенную сеть для достижения более равномерного распределения трафика
Конфликт между реализациями RPS
Шаг 1. Воспользуйтесь командой конфигурации интерфейса по 1пш rps, чтобы отменить функцию RPS (Ring Parameter Server — сервер параметров кольца) в маршрутизаторе, который вы пытаетесь вставить в кольцо.
Шаг 2. Попытайтесь вставить маршрутизатор в кольцо.
Шаг 3. Если попытка вставить в кольцо маршрутизатор с заблокированной функцией RPS завершается успешно, то причиной неисправности является конфликт между реализациями RPS. Обратитесь к представителю службы технической поддержки для получения дополнительной информации
Команда show interlaces tokenring
При поиске неисправностей передающей среды Token Ring в среде маршрутизатора Cisco можно воспользоваться командой show interfaces tokenring, которая предоставляет большой объем важной информации, позволяющей легко находить причины неисправностей. В настоящем разделе подробно описана команды show interfaces tokenring, а в табл. 6.2 приведена предоставляемая ею информация.
Воспользуйтесь привилегированной exec-командой show interfaces tokenring для просмотра информации об интерфейсе Token Ring и состоянии мостового перенаправления от отправителя:
show interfaces tokenring unit [accounting];
show interfaces tokenring slot | port [accounting] (для маршрутизаторов ряда Cisco 7200 и Cisco 7500);
show interfaces tokenring [slot | port-adapter | port] (для портов плат универсального интерфейсного процессора маршрутизаторов ряда Cisco 7500).
Описание синтаксической структуры
unit. В качестве этого параметра должен быть указан номер порта на выбранном интерфейсе.
accounting. (Необязательный параметр.) При использовании этого параметра отображается число проходящих через интерфейс пакетов, относящихся к протоколу каждого типа.
slot. Для получения информации о гнездах и портах устройства обратитесь к соответствующему руководству по аппаратным средствам.
port. Для получения информации о гнездах и портах устройства обратитесь к соответствующему руководству по аппаратным средствам.
port-adapter. Для получения информации о совместимости адаптера порта обратитесь к соответствующему руководству по аппаратным средствам.
Командный режим
Предусматривает применение привилегированной ехес-команды.
Рекомендации по использованию
Эта команда впервые появилась в выпуске Cisco IOS 10.0.
В выпуске Cisco IOS 11.3 определение команды изменилось с учетом необходимости поддержки новых дуплексных адаптеров порта Token Ring.
Если при вызове команды на выполнение не будут приведены значения параметров slot и port, отображаются статистические данные по всем сетевым интерфейсам. Необязательное ключевое слово accounting означает, что должно быть показано число пакетов, передаваемых через интерфейс по протоколу каждого типа.
Пример вывода
Ниже приведен пример вывода команды show interfaces tokenring.
Router# show interfaces tokenring
TokenRing 0 is up, line protocol is up
Hardware is 16/4 Token Ring, address is 5500.2000.dc27 (bia 0000.3000.072b)
Internet address is 150.136.230.203, subnet mask is 255.255.255.0
MTU 8136 bytes, BW 16000 Kbit, DLY 630 usee, rely 255/255, load 1/255
Encapsulation SNAP, loopback not set, keepalive set (10 sec)
ARP type: SNAP, ARP Timeout 4:00:00
Ring speed: 16 Mbps
Single ring node, Source Route Bridge capable
Group Address: 0x00000000, Functional Address: 0x60840000
Last input 0:00:01, output 0:00:01, output hang never
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
Five minute input rate 0 bits/sec, 0 packets/sec
Five minute output rate 0 bits/sec, 0 packets/sec
16339 packets input, 1496515 bytes, 0 no buffer
Received 9895 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
32648 packets output, 9738303 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets, 0 restarts 5 transitions
В табл. 6.2 приведены описания полей в выводе команды show interfaces tokenring.
^ Таблица 6.2. Описания полей в выводе команды show interfaces
Itokenring•■ .
Поле
Описание
Token Ring is { up | down }
Интерфейс в настояшее время активен и вставлен в кольцо (up) или не активен и не вставлен в кольцо (down).
При выполнении команды на маршрутизаторе ряда Cisco 7500 предоставляется также информация о типе интерфейсного процессора, номере гнезда и номере порта
Token Ring is Reset Token Ring is Initializing Token Ring is Administratively Down line protocol is {up | down | administratively down}
Возникла аппаратная ошибка
Аппаратные средства находятся в работоспособном состоянии, и в настояшее время происходит процесс вставки в кольцо
Аппаратные средства интерфейса были переведены в нерабочее состояние администратором
Указывает, имеют ли программные процессы, которые отрабатывают протокол канала передачи данных, информацию о том, что интерфейс пригоден для использования (т.е. успешно ли осуществляются операции поддержки соединения)
Hardware
Указывает тип аппаратных средств. Значение Hardware is Token Ring указывает, что плата относится к типу CSC-R. Значение Hardware is 16/4 Token Ring указывает, что плата относится к типу CSC-R16. Кроме того, в этом поле указан адрес интерфейса
Internet address MTU
Указывает адрес Internet, за которым следует маска подсети Предоставляет данные о величине максимальной единицы передачи данных в сети для рассматриваемого интерфейса
BW
Предоставляет данные о величине пропускной способности интерфейса в килобитах в секунду
DLY rely
Предоставляет данные о задержке интерфейса в микросекундах
Надежность интерфейса в виде числителя дроби со знаменателем 255 (где 255/255 соответствует 100%-ной надежности), рассчитанная как экспоненциальное среднее за время, превышающее 5 минут
Поле
Описание
load
Показывает относительную нагрузку на интерфейс в виде числителя дроби со знаменателем 255 (где 255/255 соответствует полностью загруженному интерфейсу), рассчитанную как экспоненциальное среднее за время, превышающее 5 минут
Encapsulation loopback keepalive ARP type:
Указывает метод инкапсуляции, применяемый в интерфейсе
Указывает, установлена ли петля обратной связи
Указывает, применяются ли средства поддержки соединения
Указывает тип применяемого протокола преобразования адресов
Ring speed:
Скорость кольца Token Ring — 4 или 16 Мбит/с
{Single ring | multiring node}
Указывает, разрешено ли узлу собирать и использовать исходную информацию маршрутизации из поля маршрутной информации (RIF — Routing Information Field) для маршрутизируемых протоколов Token Ring
Group Address:
Адрес группы интерфейса, если он имеется. Адрес группы применяется в качестве группового адреса; один и тот же адрес группы может быть назначен любому числу интерфейсов в кольце. Каждый интерфейс может иметь не больше одного адреса группы
Last input
Предоставляет данные о количестве часов, минут и секунд, прошедших с момента успешного получения интерфейсом последнего пакета. Эти данные позволяют определить, когда произошел отказ интерфейса, который в данный момент является неисправным
Last output
Предоставляет данные о количестве часов, минут и секунд, прошедших с момента успешной передачи интерфейсом последнего пакета
output hang
Предоставляет данные о количестве часов, минут и секунд (или содержит значение never — никогда), прошедших с того момента, как интерфейс был последний раз сброшен в связи с тем, что передача данных потребовала слишком много времени. Если число часов в любом из “последних” полей превышает 24 часа, отображается число суток и часов. При переполнении значения в этом поле отображаются символы звездочек
Last clearing
Предоставляет данные о времени, когда в последний раз были переустановлены в нулевые значения счетчики, которые содержат накопленные статистические данные (такие как количество переданных и полученных байтов), показанные в этом отчете. Следует отметить, что при очистке счетчиков не очищаются переменные, которые могут повлиять на маршрутизацию (например, load и reliability).
"***" — указывает, что значение истекшего времени слишком велико и поэтому не может быть отображено.
”0:00:00" — указывает, что с момента очистки счетчиков прошло больше 231 мс (и меньше 232 мс)
Output queue, drops Input queue, drops
В этих полях представлены данные о количестве пакетов в выходных и во входных очередях. За каждым числом следуют косая черта, значение максимального размера очереди и данные о количестве пакетов, уничтоженных в связи с переполнением очереди
Five minute input rate, Five minute output rate
В этих полях приведены данные о среднем числе битов и пакетов, переданных и принятых в секунду за последние пять минут (значения средней скорости приема и передачи).
Поле
Описание
Значения средней скорости приема и передачи за последние пять минут должны использоваться только в качестве приближенной оценки интенсивности трафика, измеренной в секунду в течение данного пятиминутного периода. Эти значения скорости представляют собой экспоненциальные взвешенные средние, при вычислении которых применялась постоянная времени, равная пяти минутам. Должен пройти период, равный учетверенному значению постоянной времени, прежде чем среднее значение установится в пределах 2% мгновенной скорости однородного потока трафика за этот период
packets input bytes input
Общее количество пакетов, полученных системой без ошибок
Обшее количество байтов, включая данные и информацию инкапсуляции МАС, в пакетах, полученных системой без ошибок
no buffer
Количество полученных пакетов, которые были отвергнуты в связи с отсутствием свободного буферного пространства в основной системе. Сравните это значение со значением в поле ignored. События, связанные с отсутствием свободных входных буферов, часто возникают при лавинообразном увеличении количества широковещательных пакетов в сетях Ethernet и пакетов ошибок в последовательных каналах
broadcasts
Обшее количество пакетов с широковещательным или групповым адресом, принятых интерфейсом
runts
Число пакетов, которые были отвергнуты в связи с тем, что имели размер меньше минимально допустимого в данной передающей среде
giants
Число пакетов, которые были отвергнуты в связи с тем, что имели размер больше максимально допустимого в данной передающей среде
CRC
Код CRC, сформированный станцией-отправителем в локальной сети или устройством, находящимся на другом конце канала передачи данных, не совпадает с контрольной суммой, вычисленной на основе полученных данных. В локальной сети ненулевое значение в этом поле обычно указывает на наличие шума или проблем передачи в интерфейсе локальной сети или в самой шине локальной сети. Большое количество ошибок CRC обычно является результатом передачи какой-либо станцией ошибочных данных
frame
Количество неправильно принятых пакетов, которые имеют ошибки CRC и нецелое количество октетов
overrun
Количество случаев, когда аппаратные средства последовательного приемного устройства не были способны передать полученные данные в аппаратный буфер, поскольку скорость ввода данных превысила способность приемного устройства обрабатывать данные
ignored
Количество полученных пакетов, которые были проигнорированы интерфейсом из-за отсутствия свободных внутренних буферов в аппаратном обеспечении интерфейса. Эти буфера отличаются от упомянутых выше буферов системы, поскольку имеют другое описание. Увеличение значения в поле ignored может быть вызвано лавинообразным возрастанием количества широковещательных пакетов или появлением пакетов ошибок
packets output
Обшее количество сообщений, переданных системой
Поле
Описание
bytes output
Общее количество байтов, включая данные и информацию инкапсуляции МАС, в пакетах, переданных системой
underruns
Предоставляет информацию о количестве случаев, когда отправка данных передатчиком на дальнем конце выполнялась быстрее, чем ее мог обработать приемник маршрутизатора на ближнем конце. В интерфейсах некоторых типов информация о таких случаях может никогда не предоставляться
output errors
Обшее количество ошибок, которые исключили возможность выполнить окончательную передачу дейтаграмм из рассматриваемого интерфейса. Следует отметить, что это значение может не совпадать с суммой подсчитанных ошибок вывода, поскольку некоторые дейтаграммы могут иметь несколько ошибок, а другие — содержать ошибки, не попадающие ни в одну из конкретных рассматриваемых категорий
collisions
Поскольку в кольце Token Ring не могут возникать коллизии, этот статистический показатель отличен от нуля, только если произошло какое-либо необычное событие, при котором фреймы были поставлены в очередь или изъяты из очереди системным программным обеспечением
interface resets
Количество случаев, связанных со сбросом интерфейса. Интерфейс может быть сброшен вручную администратором или автоматически при возникновении внутренней ошибки
restarts
Для интерфейсов Token Ring в этом поле всегда должно находиться значение 0
transitions
Количество случаев перехода кольца из работоспособного в неработоспособное состояние и наоборот. Большое количество переходов указывает на наличие неисправностей в кольце или в интерфейсе
ЧастьЧастьIIIIII
Часть
Часть
III
III
Устранение нарушений в работе маршрутизирующих протоколов
В этой части...
Глава 7. “Устранение нарушений в работе протоколов TCP/IP”
Глава 8. “Устранение нарушений в работе сети Novell IPX”
Глава 9. “Устранение нарушений в работе сети AppleTalk”
Глава 10. “Устранение нарушений в работе сети IBM”
Глава 11. “Устранение нарушений в работе сети DECnet”
Глава 12. “Устранение нарушений в работе сети ISO CLNS”
Глава 13. “Устранение нарушений в работе сети Banyan VINES”
Глава 14. “Устранение нарушений в работе сети XNS”
Глава
7
^Устранение нарушений ^ в работе протоколов TCP/IP
Г В настоящей главе рассматриваются основные особенности функционирования протоколов TCP/IP и описаны способы устранения наиболее распространенных на- ^рушений в их работе. Ниже перечислены темы, представленные в данной главе.
;* Общие сведемия о протоколах TCP/IP..
Инструментальные средства для устранения нарушений в работе протокола IP.
Общие принципы и рекомендации по устранению нарушений в работе прото, колаДР. ' t
' • Устранение основных нарушений связи по протоколу IP.
^"^^е Устранение нарушений связи, возникших в результате неисправности аппаратных средств.
■I • Поиск нарушений в работе программных и аппаратных средств уровня 3.
Устранение' нарушений в работе протокола HSRP (Hot Standby Router Protocol — ■ протокол резервного маршрутизатора).
$ Общие сведения о протоколах TCP/IP
В середине 1970-х годов Агентство перспективных исследовательских программ (DARPA — Defense Advanced Research Projects Agency) Министерства обороны США проявило заинтересованность в создании сети коммутации пакетов, предназначенной для обеспечения взаимодействия научно-исследовательских учреждений в Соединенных Штатах. DARPA и другие правительственные организации осознали потенциальные возможно- ^ сти технологии коммутации пакетов и впервые столкнулись с проблемой, которую в настоящее время приходится решать практически всем компаниям, использующим сети, — обеспечение взаимодействия разнородных компьютерных систем.
у DARPA поставило задачу обеспечения взаимодействия разнородных систем и финансировало исследования по созданию ряда протоколов связи, проводимые Стан- фордским университетом и компанией BBN (Bolt, Beranek, Newman). В результате W этих разработок, завершившихся в конце 1970-х годов, был создан набор межсетевых
Internet: TCP (Transmission Control Protocol — протокол управления передачей) и IP (Internet Protocol — межсетевой протокол).
Эта наиболее широко распространенная реализация протоколов TCP/IP со временем стала называться IPv4 (сокращение от IP версии 4). В 1995 году был предложен новый стандарт, RFC 1883, в котором были устранены некоторые недостатки протокола IPv4, включая ограничения адресного пространства. Эта новая версия получила название IPv6. Несмотря на то что в разработку версии IPv6 были вложены большие усилия, она до сих пор не нашла достаточно широкого распространения, поэтому в настоящей книге версия IPv6 не рассматривается.
Протоколы Internet
Протоколы Internet могут применяться для обмена данными по любой совокупности взаимосвязанных сетей. Они в равной степени приспособлены для работы в локальной и в распределенной сети. Набор протоколов Internet включает не только спецификации протоколов низкого уровня (таких как TCP и IP), но и спецификации таких массовых приложений, как электронная почта, эмуляция терминала и передача файлов. На рис. 7.1 показаны некоторые наиболее важные протоколы Internet и обозначена их взаимосвязь с семиуровневой эталонной моделью OSI.
Интересно отметить, что семиуровневая модель фактически была разработана на основе изучения протоколов TCP/IP. Агентством DARPA первоначально применялась четырехуровневая модель, которая в последующем была расширена организацией OSI до семи уровней. Именно по этой причине протоколы TCP/IP не вписываются в семиуровневую модель OS1 так, как хотелось бы.
FTP, Telnet, SMTP, SNMPNFSXDRRPCTCP, UDP| Маршрутизирующие протоколы IPICMPARP, RARPHe определенFTP, Telnet, SMTP, SNMPNFSXDRRPCTCP, UDP| Маршрутизирующие протоколы IPICMPARP, RARPHe определенНабор протоколов InternetНабор протоколов InternetРис. 7. /. Набор протоколов Internet и эталонная модель OSIРис. 7. /. Набор протоколов Internet и эталонная модель OSI
FTP, Telnet, SMTP, SNMP
NFS
XDR
RPC
TCP, UDP
| Маршрутизирующие протоколы IPICMP
ARP, RARP
He определен
FTP, Telnet, SMTP, SNMP
NFS
XDR
RPC
TCP, UDP
| Маршрутизирующие протоколы IPICMP
ARP, RARP
He определен
Набор протоколов Internet
Набор протоколов Internet
Рис. 7. /. Набор протоколов Internet и эталонная модель OSI
Рис. 7. /. Набор протоколов Internet и эталонная модель OSI
Работы по созданию и документальному оформлению набора протоколов Internet весьма напоминали работы по академическому научно-исследовательскому проекту. Протоколы формулировались и уточнялись в документах, называемых запросами на комментарии (RFC — Requests For Comment), которые публиковались, рассматривались и анализирова-
лись всем сообществом Internet. В целом документы RFC наглядно иллюстрируют историю деятельности людей и компаний, а также развитие тенденций, из которых состояла разработка наиболее популярного в наши дни набора протоколов открытых систем.
Сетевой уровень
Протокол IP является основным протоколом уровня 3 в наборе TCP/IP. Протокол IP предоставляет способ логической адресации, который обеспечивает взаимодействие компьютеров, подключенных к самым разным сетям. Кроме того, этот протокол обеспечивает фрагментацию и повторную сборку дейтаграмм, а также передачу сообщений об ошибках. Наряду с TCP протокол IP составляет основу набора протоколов Internet. Формат пакета IP приведен на рис. 7.2.
32 бита
Версия
IHL
Тип обслуживания
Общая длина
Идентификация
флажки
Смещение фрагмента
Срок жизни
Протокол
Контрольная сумма заголовка
Адрес отправителя
Адрес получателя
Опции (+ дополнение)
Данные (переменная длина)
Рис. 7.2. Формат пакета IP
Ниже описаны поля пакета IP.
Версия. Указывает версию дейтаграммы IP.
IHL (IP Header Length). Обозначает длину заголовка дейтаграммы IP в 32битовых словах.
Тип обслуживания. Указывает, как должна осуществляться обработка текущей дейтаграммы протоколом верхнего уровня. С помощью этого поля можно присвоить дейтаграмме определенный уровень приоритета.
В настоящее время это поле в основном применяется для реализации в протоколах TCP/IP средств обеспечения качества обслуживания (QoS — Quality of Service) приложений, требующих наличия определенной пропускной способности или задержки. В документе RFC 2474 описан метод, согласно которому поле, сокращенно обозначаемое ToS (Type of Service — тип обслуживания), заменяется полем DS (DiffServ), которое применяется для поддержки дифференцированных служб в сетях. Поле DS разбито на две части. Первые 6 битов применяются для обозначения точки кодирования дифференцированных служб (DSCP — Differentiated Services Code Point), которая используется для классификации трафика. Последние 2 бита, или CU (Currently Unused — не используемый в настоящее время), игнорируются узлами, совместимыми с DiffServ.
Общая длина. Обозначает длину всего пакета IP, включая данные и заголовок, в байтах.
Идентификация. Содержит целое число с идентификатором дейтаграммы. Это поле применяется при сборке фрагментов дейтаграммы.
Флажки. Состоит из 3 битов; два младших бита управляют фрагментацией. Один бит указывает, может ли быть пакет фрагментирован, а второй бит определяет, является ли пакет последним фрагментом в ряде фрагментированных пакетов.
Срок жизни. В этом поле находится счетчик, значение которого при прохождении узлов в сети постепенно уменьшается до нуля; после этого дейтаграмма отбрасывается. Данное поле позволяет предотвратить бесконечную циркуляцию пакетов.
Протокол. Указывает, какой протокол верхнего уровня должен получать входящие пакеты после их обработки протоколом IP.
Контрольная сумма заголовка. Позволяет обеспечивать целостность заголовка IP.
Адрес отправителя. Указывает адрес узла-отправителя.
Адрес получателя. Указывает адрес узла-получателя.
Опции. Позволяет применять протокол IP для поддержки различных опций, таких как защита.
Данные. Содержит информацию верхнего уровня.
Адресация
Как и во всех протоколах сетевого уровня, схема адресации протокола IP является неотъемлемой частью процесса маршрутизации дейтаграммы IP в объединенной сети. IP- адрес имеет длину 32 бита и делится на две или три части. Первая часть обозначает адрес сети, вторая (если она имеется) обозначает адрес подсети, а последняя часть — адрес хоста. Адрес подсети присутствует в пакетах IP, только если адресуемая сеть разделена на подсети. Поля с адресами сети, подсети и хоста имеют переменную длину.
В свое время адреса распределялись по классам, но в настоящее время в схеме адресации Internet понятие классов почти совсем не применяется. Разделение между сетями и подсетями фактически устранено. Тем не менее необходимо иметь представление о классах сети и понимать, в чем состоит различие между сетью и подсетью; это в основном связано с тем, что указанные понятия применяются при настройке сетевых устройств и позволяют понять их функционирование.
В схеме адресации IP поддерживается пять различных классов сети, и класс сети обозначен старшими (крайними левыми) битами адреса.
В сетях класса А отведено 8 битов для поля адреса сети. Старший (крайний левый) бит адреса равен 0.
В сетях класса В отведено 16 битов для поля адреса сети и 16 битов для поля адреса хоста. Этот класс адресов позволяет добиться приемлемого компромисса при определении адресного пространства для сетей и хостов. Первые два старших бита имеют значение 10.
В сетях класса С для поля адреса сети отведено 24 бита. Но в сетях класса С отведено только 8 битов для поля адреса хоста, поэтому в каждой сети может находиться лишь небольшое количество хостов, и это ограничение иногда является весьма существенным. Первые три старших бита имеют значение НО.
Адреса сетей класса D зарезервированы для многоадресатных групп, как формально описано в документе RFC 1112. Первые четыре старших бита имеют значение 1110.
Адреса сетей класса Е также определены в спецификации IР, но зарезервированы для использования в будущем. Первые четыре старших бита имеют значение НИ.
IP-адреса записываются в точечном десятичном формате (например, 34.10.2.1). На рис. 7.3 показаны форматы адресов для сетей IP классов А, В и С.
Рис. 7.3. Форматы адресов класса А, В и СРис. 7.3. Форматы адресов класса А, В и СКласс АКласс АКласс ВКласс ВКлассеКлассе
Рис. 7.3. Форматы адресов класса А, В и С
Рис. 7.3. Форматы адресов класса А, В и С
Класс А
Класс А
Класс В
Класс В
Классе
Классе
Сети IP могут также подразделяться на меньшие организационные единицы, называемые подсетями. Подсети предоставляют сетевым администраторам дополнительные возможности. Например, предположим, что сети был присвоен адрес класса В и адреса всех узлов в сети в настоящее время соответствуют формату адреса класса В. Предположим также, что адрес этой сети имеет точечное десятичное представление 172.16.0.0 (нули в поле хоста данного адреса указывают, что адрес обозначает всю сеть). Но если администратору потребуется развернуть еще одну сеть, то при наличии достаточного количества свободных адресов хостов он может не создавать еще одну сеть и в массовом порядке корректировать значения адреса сети, а разбить сеть на подсети. Это можно выполнить, заимствуя несколько битов из части адреса, относящейся к хосту, и используя их в качестве поля подсети, как показано на рис. 7.4.
Адрес класса В, перед выделением подсети
Класс В 1 ОКласс В 1 О
Класс В 1 О
Класс В 1 О
ХостХостСеть
Хост
Хост
Адрес класса В, после выделения подсети
Класс В 1 ОКласс В 1 ОСетьСетьПодсетьПодсетьХостХост
Класс В 1 О
Класс В 1 О
Сеть
Сеть
Подсеть
Подсеть
Хост
Хост
Рис. 7.4. Адреса подсетей
Если сетевой администратор отведет для обозначения подсетей 8 битов IP-адреса класса В, то для адресации подсетей будет применяться третий октет IP-адреса. Например, адрес 172.16.1.0 указывает на сеть 172.16, подсеть 1, адрес 172.16.2.0— на сеть 172.16, подсеть 2 и т.д. Но при использовании такой схемы адресации возникает необходимость явно указывать, какая часть адреса обозначает сеть и подсеть, а какая — хост. Для этого служит так называемая маска адреса, которая указывает, сколько битов адреса в целом применяется для обозначения адреса сети и подсети. Очевидно, что понятие маски адреса применимо и к сетям с адресацией на основе классов, поэтому можно считать, что полная маска адреса состоит из битов маски сети и маски подсети. Но в наши дни маска адреса рассматривается просто как условное обозначение той части адреса, которая относится и к сети, и к подсети. Тем не менее необходимо учитывать, что маска адреса всегда включает биты, обозначающие сеть определенного класса, поскольку маршрутизаторы иногда принимают решение о перенаправлении трафика с учетом класса сети. Например, первые 8 битов маски адреса 10.1.1.1/24 все равно относятся к обозначению класса сети, поскольку это — адрес сети класса А, даже несмотря на то, что в этом адресе указана маска адреса, состоящая из 24 битов.
В маске адреса битами 1 обозначена часть адреса, относящаяся к сети (называемая также префиксом), а часть адреса хоста обозначена битами 0. Цепочки битов 1 и О должны быть непрерывными. Маска адреса может быть представлена в двух формах: как обозначение длины префикса (например, /24) или в точечном десятичном представлении (например, 255.255.255.0), Обе формы являются равнозначными и могут быть легко преобразованы друг в друга, как показано в листинге 7.1.
i Листинг 7.1. Маска адреса, представленная в виде обозначения длины { i префикса и в точечной десятичной форме d
255.255.255.0 = ШИШ ШПШ ШПШ 00000000 = /24 (количество битов 1)
В сетевой среде определенного типа (такой как локальные сети IEEE 802) для доставки данных применяются адреса передающей среды, поэтому в процессе передачи динамически устанавливается соответствие между МАС-адресами и IP-адресами. Для этого применяются два протокола из набора протоколов Internet: ARP и RARP (Reverse Address Resolution Protocol — протокол обратного преобразования адресов). В протоколе ARP для определения аппаратного адреса уровня МАС, соответствующего конкретному IP-адресу, применяются широковещательные сообщения. Протокол ARP является достаточно универсальным, поэтому позволяет использовать протокол IP в сочетании с механизмами доступа к базовой передающей среде практически любого типа. В протоколе RARP применяются широковещательные сообщения для определения Internet-адреса, связанного с конкретным аппаратным адресом. Протокол RARP имеет особо важное значение для бездисковых сетевых узлов, которые могут не иметь информации о своем IP-адресе во время начальной загрузки.
Маршрутизация Internet
Маршрутизирующие устройства в Internet по традиции называются шлюзами, но этот термин не совсем удачен, поскольку шлюзами называют также устройства с несколько иными функциональными возможностями. Шлюзы (которые далее будут именоваться маршрутизаторами) в сети Internet объединены в иерархическую структуру.
Маршрутизаторы могут взаимодействовать друг с другом и обмениваться информацией о маршрутах, которая была ими накоплена в процессе работы, с помощью таких динамических протоколов маршрутизации, как RIP и OSPF. Кроме динамической маршрутизации, применяется также статическая маршрутизация, при которой маршруты устанавливаются сетевым администратором и не изменяются до тех пор, пока не будет проведена очередная их корректировка вручную. Таблица маршрутизации IP состоит из пар “адрес получателя/следуюшая транзитная точка перехода”. Пример записи таблицы маршрутизации, приведенный на рис. 7.5, можно интерпретировать следующим образом: “Чтобы перейти в сеть 34.1.0.0 (в подсеть 1 сети 34), вначале необходимо перейти к узлу с адресом 54.34.23.12’’.
Адрес получателя
Следующий транзитный переход
34.1.0.0
78.2.0.0
147.9.5.0
17.12.0.0
54.34.23.12
54.34.23.12
54.32.12.10
54.32.12.10
Рис. 7.5. Пример таблицы маршрутизации IP
Применяемые методы маршрутизации IP основаны на предположении, что дейтаграммы IP перемещаются по объединенной сети, переходя от одного участка маршрута к другому; весь маршрут дейтаграммы, отправляемой к месту назначения, заранее не известен. Поэтому вместо заблаговременного определения всего маршрута применяется способ маршрутизации, при котором очередное место назначения дейтаграммы определяется путем сопоставления адреса ее получателя с одной из записей в таблице маршрутизации текущего узла. Каждый узел принимает участие в процессе маршрутизации, но это участие ограничивается только перенаправлением пакетов на основе внутренней информации узла, но без учета того, по какому маршруту проходили пакеты на пути к окончательному месту назначения. Иными словами, в протоколе IP не предусмотрены средства передачи по адресу отправителя отчетов об ошибках при обнаружении нарушений процесса маршрутизации. Эта задача возложена на другие протоколы Internet, такие как ICMP и TCP.
Протокол ICMP
Протокол ICMP выполняет в объединенной сети IP целый ряд задач, но основной из них является передача по адресу отправителя дейтаграммы сообщений об ошибках маршрутизации. Кроме того, протокол ICMP служит для передачи других важных сообщений, в том числе следующих:
запросные и ответные сообщения эхо-тестирования, позволяющие проверить достижимость узла по объединенной сети;
сообщения о перенаправлении, которые способствуют повышению эффективности маршрутизации;
сообщения об истечении срока жизни, позволяющие передать по адресу отправителя информацию о том, что дейтаграмма прошла такое количество узлов, которое превышает назначенный ей срок жизни в объединенной сети;
сообщения с объявлениями о наличии маршрутизатора и с запросами на получение информации о наличии маршрутизатора, позволяющие определить адреса маршрутизаторов в непосредственно подключенных подсетях.
Транспортный уровень
Транспортный уровень Internet реализуется протоколами TCP и UDP. Протокол TCP обеспечивает передачу данных с установлением логического соединения, а протокол UDP не предусматривает установления логического соединения.
Протокол TCP
Протокол TCP предоставляет протоколам верхнего уровня доступ к дуплексной службе передачи данных, обеспечивающей подтверждение приема данных и управление потоком данных. Он обеспечивает передачу данных в виде непрерывного, неструктурированного потока байтов, в котором сохраняется первоначальная последовательность байтов. Протокол TCP способен одновременно поддерживать несколько сеансов обмена данными по протоколу верхнего уровня. Формат пакета TCP показан на рис. 7.6.
Порт отправителя
Порт получателя
Порядковый номер
Номер подтверждения
Смещение данных
Зарезервировано
Флажки
Окно
Контрольная сумма
Указатель срочности
Опции (+ дополнение)
Данные (переменная длина)
Рис. 7.6. Формат пакета TCP
Ниже описаны поля пакета TCP.
Порт отправителя и порт получателя. Обозначают дескрипторы (сокеты), через которые предоставляется доступ к службам TCP для процессов верхнего уровня на компьютере отправителя и получателя.
Порядковый номер. Обычно содержит номер, присвоенный первому байту данных в текущем сообщении. При определенных обстоятельствах это поле может также применяться для обозначения начального порядкового номера, который будет использоваться при следующей передаче.
Номер подтверждения. Содержит порядковый номер следующего байта данных, на получение которого может рассчитывать отправитель пакета.
Смещение данных. Указывает количество 32-разрядных слов в заголовке TCP.
Зарезервировано. Это поле зарезервировано для использования в будущем.
Флажки. В этом поле содержится разнообразная управляющая информация.
Окно. Поле указывает размер окна приема получателя (объем буферного пространства, доступного для входящих данных).
Контрольная сумма. Предоставляет информацию, которая применяется для определения того, не произошло ли искажение заголовка при передаче.
Указатель срочности. Указывает на первый байт срочных данных в пакете.
Опции. Содержит различные опции TCP.
Данные. Содержит информацию верхнего уровня.
Протокол UDP
Протокол UDP намного проще, чем TCP, и используется в тех ситуациях, когда не требуются механизмы обеспечения надежности TCP. Заголовок дейтаграммы UDP имеет только четыре поля: порт отправителя, порт получателя, длина и контрольная сумма UDP. Поля с обозначением порта отправителя и получателя выполняют те же функции, что и поля заголовка TCP. Поле длины указывает длину заголовка дейтаграммы UDP и данных, а поле контрольной суммы UDP позволяет проверить целостность пакета. Поле контрольной суммы UDP может оставаться незаполненным.
Протоколы верхнего уровня
Набор протоколов Internet включает множество протоколов верхнего уровня, представляющих широкий спектр приложений, включая управление сетью, передачу файлов, службы доступа к распределенным хранилищам файлов, эмуляцию терминала и электронную почту. В табл. 7.1 показано соответствие между наиболее широко применяемыми протоколами Internet верхнего уровня и приложениями, которые они поддерживают.
Таблица 7.1. Соответствие между протоколами Internet и приложениями i (суказанием обычно применяемыхномеровпортов) , j
ПриложениеПротокол
Web-броузерHTTP (порт 80 протокола TCP)
Протокол передачи гипертекста (HTTP — Hypertext Transfer Protocol) используется Web- броузсрами и серверами для передачи файлов, которые входят в состав Web-страницы Передача файловFTP (порты 20 и 21 протокола TCP)
Протокол передачи файлов (FTP — File Transfer Protocol) предоставляет способ передачи файлов с одного компьютера на другой
Эмуляция терминалаTelnet (порт 23 протокола TCP)
Протокол Telnet предоставляет доступ к службе эмуляции терминала по протоколу TCP, реализующему надежную потоковую службу. Кроме того, спецификация протокола Telnet предусматривает способ согласования между клиентом и сервером решений об использовании некоторых средств и опций
Электронная почтаSMTP (порт 25 протокола TCP), POP3 (порт
ПО протокола TCP), IMAP4 (порт 143 протокола TCP)
ПриложениеПротокол
Протокол SMTP (Simple Mail Transfer Protocol — простой протокол электронной почты) применяется для передачи электронной почты с одного почтового сервера на другой, а также служит для отправки электронной почты из программ почтовых клиентов. Для приема почты по протоколу SMTP требуется наличие постоянного соединения со службой электронной почты, поэтому почтовые клиенты, как правило, не используют протокол SMTP для получения почты. Вместо этого в почтовых клиентах используется версия 3 протокола POP (Post Office Protocol — почтовый протокол) или версия 4 протокола IMAP (Internet Message Access Protocol — протокол доступа к сообщениям в сети Internet); эта тема рассматривается более подробно ниже в этой главе
Управление сетьюSNMP (порт 161 протокола UDP)
Протокол SNMP применяется в службах управления сетью для передачи сообщений о нарушениях в работе сети и установки предельно допустимых значений параметров работы сетевых устройств
Распределенные службы доступа к файлам NFS, XDR, RPC (порт 111 протокола UDP),
X Window (порты 6000—6063 протокола UDP)
Протокол X Window широко применяется для обеспечения взаимодействия “интеллектуальных” терминалов с удаленными компьютерами в целях эмуляции режима непосредственного подключения. Протоколы NFS (Network File System — сетевая файловая система), XDR (External Data Representation — внешнее представление данных) и RPC (Remote Procedure Call — дистанционный вызов удаленных процедур) в целом позволяют обеспечить прозрачный доступ к удаленным сетевым ресурсам
В этих и других сетевых приложениях применяются службы протоколов TCP/IP и других протоколов Internet низкого уровня для предоставления пользователям доступа к основным сетевым службам.
Система доменных имен
В протоколах TCP/IP используется числовая схема адресации, согласно которой каждому узлу сети присваивается IP-адрес, применяемый для перенаправления пакетов на этот узел. Но поскольку для запоминания гораздо проще использовать символические имена, такие как ww.somedomain.com, а не числовые обозначения типа 10.1.1.1, для прямого и обратного преобразования символических обозначений в числовые адреса применяется протокол DNS (Domain Name System — система доменных имен). Система доменных имен предоставляет также много других преимуществ, например, позволяет изменять IP-адреса, не корректируя символические ссылки на Web-странице, поскольку для этого достаточно только исправить соответствующую запись в таблице DNS, чтобы она указывала на новый адрес. Поэтому ссылки на Web-страницы чаще всего оформляются в виде символических имен, и по такому же принципу оформляются ссылки на другие Web-страницы на самих Web-страницах.
Инструментальные средства устранения нарушений в работе протокола IP
В набор протоколов TCP/IP входят инструментальные средства ping и traceroute, которые намного упрощают поиск нарушений связи по протоколу IP. В большинстве
операционных систем и реализаций протокола IP эти инструментальные средства устанавливаются по умолчанию. Но на некоторых платформах UNIX может потребоваться загрузить и установить пакет traceroute отдельно.
В маршрутизаторах Cisco предусмотрен основной метод просмотра трафика IP, перенаправляемого через коммутатор, называемый отладкой пакетов. Отладка пакетов дает возможность пользователю определить, соответствует ли путь прохождения трафика по сети ожидаемому, или наблюдаются ошибки в конкретном потоке TCP. В некоторых случаях отладка пакетов позволяет устранить необходимость в использовании анализатора пакетов, но ее нельзя рассматривать в качестве замены этого важного инструментального средства.
Отладка пакетов может очень сильно повлиять на работу оборудования, причем в некоторых случаях ее применение может вызвать переход маршрутизатора в нерабочее состояние, из которого его придется выводить с помошью физического сброса. А в других случаях средства отладки пакетов могут не сообщать о некоторых пакетах, присутствующих в сети и перенаправляемых через маршрутизатор. Поэтому только на основании результатов, полученных от средств отладки пакетов, нельзя сделать обоснованный вывод, что не был отправлен какой-либо пакет; точные данные о прохождении пакетов можно получить только с помошью сетевого анализатора. Отладка пакетов может выполняться только опытными операторами, с предельной осторожностью, поскольку при использовании этого метода любые упущения могут вызвать блокировку маршрутизатора и прекращение перенаправления трафика. Опасность, связанная с применением отладки пакетов, может еше более возрасти в связи с необходимостью отмены быстрой коммутации для обеспечения возможности выполнения отладки пакетов. Как правило, отладка пакетов может выполняться в производственном маршрутизаторе, только если есть физический доступ к маршрутизатору и можно пойти на риск останова этого маршрутизатора.
Инструментальное средство ping
В инструментальном средстве ping используются передаваемые по протоколу IP запросные и ответные сообщения эхо-повтора протокола ICMP для проверки достижимости удаленной системы. Простейший способ применения утилиты ping позволяет лишь подтвердить, что IP-пакет способен достичь IP-адреса получателя, а затем успешно проделать обратный путь (рис. 7.7). Это инструментальное средство обычно возвращает два фрагмента информации: во-первых, показывает, что из хоста отправителя можно достичь хоста получателя (из чего следует вывод, что существует путь и в обратном направлении), а во-вторых, сообщает время кругового обращения (RTT — Round-Trip Time), которое обычно измеряется в миллисекундах. Значение RTT, полученное от утилиты ping, может применяться только для справок и сравнений, поскольку в значительной степени зависит от реализации программного обеспечения и характеристик аппаратных средств в той системе, где используется утилита ping. Если утилита ping завершает свою работу аварийно или возвращает нетипичное значение RTT, то для поиска причины неисправности можно воспользоваться утилитой traceroute. Иногда есть также возможность варьировать размеры части данных запросного сообщения ICMP для проверки того, не связана ли неисправность с применяемым значением максимальной единицы передачи данных в сети (MTU — Maximum Transmission Unit).
Cisco Rtr1Cisco Rtr1Cisco Rtr2Cisco Rtr2Cisco Rtr3Cisco Rtr3Cisco Rtr5Cisco Rtr5Cisco Rtr4Cisco Rtr4
Cisco Rtr1
Cisco Rtr1
Cisco Rtr2
Cisco Rtr2
Cisco Rtr3
Cisco Rtr3
Cisco Rtr5
Cisco Rtr5
Cisco Rtr4
Cisco Rtr4
Puc. 7.7. Пример использования утилиты ping
Как показано в листинге 7.2, утилита ping возвращает три значения, разделенные косой чертой (/): минимальное, среднее и максимальное значение RTT. Наличие большой разницы между этими значениями указывает на затор в сети или нарушение в работе сети. В большинстве случаев среднее значение достаточно точно отражает запаздывание сети на пути к месту назначения. По умолчанию в утилите ping для проверки возможности связи применяются небольшие пакеты; результаты измерения значений RTT зависят от размеров пакетов. Размер пакета в некоторых реализациях утилиты ping, в том числе в системе 1OS корпорации Cisco, может изменяться.
Листинг 7.2. Формат отображения минимального, среднего:
- и максимального значений RTT, разделенных косой чертой
।в вывода ynwirrw ping
CiscoRtrl>ping 10.3.1.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echoes to 10.3.1.6, timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Некоторые параметры настройки брандмауэров и маршрутизаторов позволяют исключить возможность эхо-тестирования подключенных к ним устройств, но при этом разрешить прохождение другого трафика IP. По этой причине отрицательные результаты эхо-тестирования одного устройства, выполненного с другого устройства, не следует рассматривать как подтверждение отсутствия связи по протоколу IP между этими устройствами. В табл. 7.2 приведен список некоторых кодов, возвращаемых утилитой ping корпорации Cisco, а также указаны их значения и возможные причины нарушения связи.
Таблица 7.2. Коды возврата утилиты ping корпорации Cisco
Код ЗначениеКод ЗначениеКаждый восклицательный знак указывает, что получено ответное сообшение эхо-повтора ICMP Каждая точка указывает, что сетевой сервер, не дождавшись ответа, завершил работу по тайм-аутуКаждый восклицательный знак указывает, что получено ответное сообшение эхо-повтора ICMP Каждая точка указывает, что сетевой сервер, не дождавшись ответа, завершил работу по тайм-аутуUПолученосообщение ICMP отом, чтоустройство-получательнедостижимоСПолученосообшение ICMP оподавлении источникаUПолученосообщение ICMP отом, чтоустройство-получательнедостижимоСПолученосообшение ICMP оподавлении источника4 Получено сообщение ICMP о том, что истек срок жизни пакета4 Получено сообщение ICMP о том, что истек срок жизни пакетаВозможная причина (причины) нарушения связи
Код Значение
Код Значение
Каждый восклицательный знак указывает, что получено ответное сообшение эхо-повтора ICMP Каждая точка указывает, что сетевой сервер, не дождавшись ответа, завершил работу по тайм-ауту
Каждый восклицательный знак указывает, что получено ответное сообшение эхо-повтора ICMP Каждая точка указывает, что сетевой сервер, не дождавшись ответа, завершил работу по тайм-ауту
UПолученосообщение ICMP о
том, чтоустройство-получатель
недостижимо
СПолученосообшение ICMP о
подавлении источника
UПолученосообщение ICMP о
том, чтоустройство-получатель
недостижимо
СПолученосообшение ICMP о
подавлении источника
4 Получено сообщение ICMP о том, что истек срок жизни пакета
4 Получено сообщение ICMP о том, что истек срок жизни пакета
Работа утилиты ping завершилась успешно
Это сообщение может указывать на наличие многих проблем:
утилита ping заблокирована с применением списка доступа или брандмауэра;
маршрутизатор, находящийся в пути следования пакетов, не имеет информации о маршруте к устройству-получателю и не отправил устройству- отправителю сообшение ICMP о том, что устройство-получатель недостижимо;
в пути следования пакетов где-то нарушена связь в результате возникновения неисправности
Маршрутизатор, находящийся в пути следования пакетов, не имеет информации о маршруте к устройству-получателю
Устройство, находящееся в пути следования пакетов (возможно, даже устройство-получатель), скорее всего, получает слишком большой объем трафика; проверьте входные очереди
Возможно, возник циклический маршрут
Инструментальное средство traceroute
Утилита traceroute передает ряд запросных сообщений эхо-повтора ICMP (в системе Windows) или сообщений UDP (в большинстве других реализаций), постепенно увеличивая в них значения TTL в заголовке IP для проверки пути, по которому следует пакет, проходящий по сети (см. листинг 7.3). Первый пакет со значением TTL, установленным равным 1, будет отброшен после прохождения первого участка маршрута, и первый же узел отправит по адресу отправителя пакета сообщение ICMP об истечении срока жизни TTL, указав в качестве адреса отправителя свой IP-адрес. После получения утилитой traceroute сообщения ICMP об истечении срока жизни TTL будет получена информация о первом участке маршрута, который начинается с IP- адреса отправителя. Такой процесс, предусматривающий последовательное увеличение значения TTL, продолжается до тех пор, пока не будет достигнуто устройство- получатель. После этого будет получено ответное сообщение эхо-повтора ICMP (в системе Windows) или сообщение port unreachable (порт недостижим); оба эти сообщения указывают, что пакет достиг устройства-получателя. В реализации утилиты traceroute корпорации Cisco предусмотрена отправка трех пакетов с каждым значением TTL, что позволяет использовать утилиту traceroute для получения информации о маршрутизаторах, которые имеют несколько равнозначных путей к месту назначения.
Утилита traceroute может применяться для получения полезной информации об обеспечении связи по протоколам TCP/IP в конкретной сети. В табл. 7.3 перечислены
некоторые коды, которые могут быть возвращены утилитой traceroute корпорации Cisco, а также указаны возможные причины их появления.
| Таблица 7.3. Коды возврата утилиты traceroute корпорации Cisco
Код
Значение
Возможная причина (причины)
nn msec
Этот код возврата указывает для каждого узла время кругового обращения (в миллисекундах) указанного количества тестовых пакетов
Появление этого кода возврата свидетельствует о нормальной ситуации
Время ожидания ответа на тестовый пакет истекло
Устройство, находящееся в пути следования тестового пакета, либо его не получило, либо не передало сообщение ICMP об истечении срока жизни пакета
А
Запрещено администратором
Вероятно, на одном из устройств, находящихся в пути следования тестового пакета, таком как брандмауэр или маршрутизатор, заблокирован трафик тестовых пакетов, а также, возможно, весь прочий трафик; проверьте списки доступа
0
Подавление источника
Скорее всего, одно из устройств, находящихся в пути следования пакетов, получает слишком большой объем трафика; проверьте входные очереди
Н
Получено сообщение ICMP о юм, что устройство-получатель недостижимо
Возможно, возник циклический маршрут
Листинг 7.3. Применение утилиты traceroute (результаты получены на маршрутизаторе Cisco); :
CiscoRtrl>traceroute 10.3.1.6
Type escape sequence to abort.
Tracing the route to 10.3.1.6
CiscoRtr2 (10.1.1.2) 0 msec
CiscoRtr3 (10.1.1.3) 0 msec
CiscoRtr4 (10.1.1.4) 4 msec
CiscoRtr5 (10.2.1.6) 4 msec 4 msec 0 msec
CiscoRtr6 (10.3.1.6) 4 msec 4 msec 4 msec
Если на участке между маршрутизаторами CiscoRtr5 и CiscoRtr6 возникла неисправность, то на терминале маршрутизатора Cisco появится следующая информация:
CiscoRtrl>traceroute 10.3.1.6
Type escape sequence to abort.
Tracing the route to 10.3.1.6
1 CiscoRtr2 (10.1.1.2) 0 msec
CiscoRtr3 (10.1.1.3) 0 msec
CiscoRtr4 (10.1.1.4) 4 msec
2 CiscoRtr5 (10.2.1.6) 4 msec 4 msec 0 msec
* * *
***
Путь от отправителя к получателю можно также проследить, используя утилиту ping и опцию регистрации маршрута протокола IP, но предпочтительный метод состоит в применении утилиты traceroute, поскольку опция регистрации маршрута может повлиять на способ перенаправления пакетов маршрутизаторами в сети, что приводит к получению неправильной информации о пути.
Отладка пакетов
Следующий пример относится к маршрутизаторам ряда Cisco 16хх, 25хх, 26хх, Збхх, 40хх, 45хх, 70хх и 75хх. Обратитесь к Web-странице узла ТАС корпорации Cisco по адресу ww.cisco.com/tac для получения инструкций по использованию описанной ниже команды на других платформах маршрутизаторов Cisco.
Предостережение
Команда debug ip packet должна всегда вызываться на выполнение вместе со списком доступа, позволяющим ограничить трафик, отображаемый с помощью этой команды. Несоблюдение этого требования почти наверняка приведет к блокировке маршрутизатора. Но вероятность блокировки маршрутизатора при отладке пакетов существует и при использовании списка доступа. Не применяйте указанную утилиту в маршрутизаторе, для которого недопустима ситуация останова или физического сброса.
Для использования команды debug ip packet необходимо выполнить следующее.
Перейти в режим enable.
CiscoRtr> enable
CiscoRtr#
Отменить вывод журнала на консоль. (Эта команда может выполняться и с выводом журнала на консоль, но при этом вероятность блокировки маршрутизатора увеличивается.)
CiscoRtr# configure terminal
CiscoRtr(config)# no logging console
CiscoRtr(config)# end
CiscoRtr#
Разрешить запись журнала в буфер.
CiscoRtr# configure terminal
CiscoRtr(config)# logging buffered
CiscoRtr(config)# end
CiscoRtr#
Предусмотреть вывод в журнал отметок времени с отсчетом в миллисекундах.
CiscoRtr# configure terminal
CiscoRtr(config)# service timestamps log datetime msec
CiscoRtr(config)# end CiscoRtr#
Убедиться в том, что процессор маршрутизатора не перегружен. Нагрузка процессора во многом зависит от объема перехватываемого трафика и типа маршрутизатора. Как правило, безопасной является относительная нагрузка процессора в процентах (показанная в выводе этой команды), которая не превышает 30% максимальной нагрузки.
Примечание. Блокировка маршрутизатора может возникнуть и при этих условиях!
CiscoRtr# show processes cpu
CPU utilization for five seconds: 2%/0%; one minute: 0%; five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec IMin 5Min TTY Process .
1207530838660.0040.0040.0040 Load Meter
22735549631.5540.1840.0640 Exec
[snip]
CiscoRtr#
Отменить быструю коммутацию на входящем и исходящем интерфейсах, в которых требуется перехватывать трафик.
CiscoRtr# configure terminal
CiscoRtr(config)# interface ethernet 0
CiscoRtr(config-if)# no ip route-cache
CiscoRtr(config-if)# interface ethernet 1
CiscoRtr(config-if)# no ip route-cache
CiscoRtr(config-if)# end
CiscoRtr#
Создать список доступа, который соответствует только перехватываемому трафику. В данном примере применяется список доступа 101, который соответствует всему трафику DHCP. Вместо номера 101 должен быть указан один из доступных списков доступа IP на маршрутизаторе.
CiscoRtr# configure terminal
CiscoRtr(config)#
access-list 101 permit udp any any eq bootpc
CiscoRtr(config)#
access-list 101 permit udp any any eq bootps
CiscoRtr(config)#
access-list 101 permit udp any eq bootpc any
CiscoRtr(config)#
CiscoRtr(config)#
access-list 101 permit udp any eq bootps any end
CiscoRtr#
Внимательно проверить, что список доступа действительно существует и является правильным. (Несуществующий или неправильный список доступа может заблокировать маршрутизатор.)
CiscoRtr# show ip access-lists Extended IP access list 101 permit udp any any eg bootpc permit udp any any eg bootps permit udp any eg bootpc any permit udp any eg bootps any
Начать отладку пакетов со списком доступа. (Если список доступа не будет указан в качестве параметра, это может привести к блокировке маршрутизатора.)
CiscoRtr# debug ip packet 101 detail
Прекратить отладку.
CiscoRtr# undebug all
Просмотреть результаты, выведенные в журнал.
CiscoRtr# show log
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 16 messages logged
Trap logging: level informational, 0 message lines logged
Log Buffer (4096 bytes):
*Маг
16
18:00:10.485:
IP:
s=0.0.0.0 (EthernetO), d=255.255.255.255, len 328, rcvd
2
*Маг
16
18:00:10.485:
UDP src=68, dst=67
*Маг
16
18:00:10.485:
IP:
s=10.1.1.1 (local), d=10.1.2.2 (Ethernetl), len 328, sending
*Маг
16
18:00:10.485:
UDP src=67, dst=67
*Маг
16
18:00:10.492:
IP:
s=10.1.2.2 (Ethernetl), d=10.1.1.1, len 328, rcvd 4
*Маг
16
18:00:10.492:
UDP src=67, dst=67
*Маг
16
18:00:10.492:
IP:
s=10.1.1.1 (local), d=10.1.1.10 (EthernetO), len 328, sending
*Маг
16
18:00:10.492:
UDP src=67, dst=68
*Маг
16
18:00:10.510:
IP:
s=0.0.0.0 (EthernetO), d=255.255.255.255, len 328, rcvd
2
*Маг
16
18:00:10.510:
UDP src=68, dst=67
*Маг
16
18:00:10.510:
IP:
s=10.1.1.1 (local), d=10.1.2.2 (Ethernetl), len 328, sending
*Маг
16
18:00:10.510:
UDP src=67, dst=67
*Маг
16
18:00:10.530:
IP:
s=10.1.2.2 (Ethernetl), d=10.1.1.1, len 328, rcvd 4
*Маг
16
18:00:10.530:
UDP src=67, dst=67
*Маг
16
18:00:10.530:
IP:
8=10.1.1.1 (local), d=10.1.1.10 (EthernetO), len 328, sending
*Маг
16
18:00:10.530:
UDP src=67, dst=68
Общие рекомендации по устранению нарушений в работе протокола IP
В настоящей главе процесс устранения нарушений в работе протоколов TCP/IP, касающихся отсутствия связи по сети, рассматривается в предположении, что сетевой администратор имеет доступ к клиентскому компьютеру (или к станции-отправителю) и не имеет доступа к серверному компьютеру (или к станции-получателю). Но если будет обнаружено, что нарушение работы протокола связано с неисправностью сервера, то сетевому администратору необходимо обратиться к администратору сервера. А если сетевой администратор сам является администратором сервера, он может выполнить описанный здесь
процесс поиска неисправностей в обратном направлении (от сервера к клиенту) для дальнейшего усовершенствования процесса устранения нарушений связи между этими компьютерами. В настоящей главе не рассматриваются вопросы устранения нарушений в работе серверных IP-служб; для получения информации по решению подобных проблем обратитесь к справочному руководству или к Web-странице, посвященной программному обеспечению, или службе, работающей на сервере.
Поскольку протоколы TCP/IP не предусматривают хранения информации о пути прохождения в передаваемых по ним пакетах, то возможна такая ситуация, что для пакета существует приемлемый путь от отправителя к получателю (или наоборот), но отсутствует путь в противоположном направлении. По этой причине для определения причины нарушения связи может потребоваться выполнить все этапы поиска нарушений в работе в обоих направлениях вдоль пути прохождения пакетов, передаваемых по протоколу IP.
Сужение проблемной области
Для эффективного устранения нарушений связи по протоколам TCP/IP необходимо в конечном итоге выявить единственную пару, состоящую из устройства- отправителя и устройства-получателя, между которыми нарушена связь. После обнаружения двух таких устройств необходимо убедиться в том, что связь между ними действительно невозможна.
Ниже описаны возможные проблемы нарушения связи.
Нарушение функционирования протокола физического уровня в пути следования пакетов.
Отсутствие связи по протоколу уровня 3 на первом участке маршрута и в ближайшем сегменте локальной сети.
Отсутствие связи по протоколу уровня 3 в пути следования пакетов.
Нарушение в работе службы преобразования имен.
Ниже перечислены основные этапы процедуры поиска неисправностей.
Попытайтесь выполнить эхо-тестирование устройства-получателя с устройства- отправителя по IP-адресу. Если эхо-тестирование завершается неудачей, убедитесь в том, что применяется правильный адрес, и снова выполните эхо- тестирование. Если эхо-тестирование по-прежнему завершается неудачей, перейдите к следующему разделу, “Устранение нарушений связи в локальной сети". В ином случае перейдите к шагу 2.
Попытайтесь выполнить эхо-тестирование устройства-получателя с устройства- отправителя по имени. Если утилита ping терпит неудачу, убедитесь в том, что имя введено правильно и действительно указывает на устройство-получатель, а затем снова попытайтесь выполнить эхо-тестирование. Если эхо-тестирование по-прежнему завершается неудачей, перейдите к следующему разделу, “Устранение нарушений в работе сервера доменных имен”. В ином случае перейдите к шагу 3.
Если удалось выполнить эхо-тестирование устройства-получателя и по имени, и по адресу, то возможно, что отсутствие связи вызвано нарушением в работе одного из протоколов верхнего уровня. Перейдите к разделу “Устранение нарушений в работе протоколов верхнего уровня”, приведенному далее в этой главе.
Устранение нарушений связи в локальной сети
В настоящем разделе описан процесс устранения нарушений связи в сегментах локальной сети, такой как Ethernet или Token Ring. Методика, описанная в настоящей главе, позволяет диагностировать и устранять нарушения при перемещении пакетов по сегменту локальной сети или при передаче на маршрутизатор, которым оканчивается следующий участок маршрута. Если же будет обнаружено, что причина неисправности находится за пределами сегмента локальной сети, перейдите к разделу “Устранение нарушений связи по протоколу IP и проблем маршрутизации”, приведенному ниже в этой главе. Если же устройство-отправитель подключено к сети через модем, обратитесь к главе 16.
Ниже перечислены возможные причины нарушения связи.
Ошибки в параметрах конфигурации.
Нарушения в работе протоколов DHCP или ВООТР.
Нарушения в работе протоколов физического уровня.
Повторяющиеся IP-адреса.
Проверка правильности конфигурации
На первом этапе поиска неисправностей выведите на экран и изучите информацию о конфигурации программного обеспечения IP на устройстве-отправителе. Метод получения такой информации зависит от конкретной платформы. Для получения подробных сведений о том, как ознакомиться с указанной информацией о конфигурации, обратитесь к справочному руководству по устройству или по операционной системе. Ниже показано несколько возможных способов получения такой информации.
На маршрутизаторе Cisco для этого предназначены команды show ip interface и show running-config.
В операционной системе Windows 95 или 98 применяется программа winipcfg.exe.
В операционной системе Windows 2000 или NT используется программа ipconfig.exe.
В операционной системе UNIX применяется программа ifconfig.
Изучите информацию о конфигурации, обращая особое внимание на IP-адрес и маску подсети. В операционной системе Windows 9х или Windows 2000 в состав этой информации должен также входить адрес шлюза, применяемый по умолчанию.
Если в состав информации о конфигурации не входит IP-адрес, убедитесь в том, что этот узел получает свой IP-адрес по протоколу ВООТР или DHCP. В ином случае IP-адрес должен присваиваться данному интерфейсу с помощью метода статической настройки. Настройте такой адрес, если он не задан. Если устройство-отправитель настроено на получение IP-адреса по протоколу DHCP или ВООТР, но не получает его, убедитесь в том, что вспомогательный адрес bootp (IP) настроен в интерфейсе маршрутизатора, обращенном к этому устройству-отправителю.
При наличии в составе информации о конфигурации неправильных значений IP- адреса, маски подсети или шлюза, применяемого по умолчанию, убедитесь в том, что узел получает свой IP-адрес по протоколу ВООТР или DHCP, а затем обратитесь к администратору сервера ВООТР или DHCP. Попросите администратора проверить
конфигурацию сервера ВООТР или DHCP. Если же применяется статический метод настройки адреса, введите в информацию о конфигурации правильный адрес.
Проверка наличия связи в локальной сети
Если устройство-получатель находится в той же подсети, что и устройство- отправитель, попытайтесь выполнить эхо-тестирование устройства-получателя по IP- адресу. Если же устройство-получатель находится в другой подсети, то попытайтесь выполнить эхо-тестирование шлюза, применяемого по умолчанию, или соответствующего устройства, находящегося в конце следующего участка маршрута, о котором можно узнать из таблицы маршрутизации. Если эхо-тестирование завершается неудачей, тщательно проверьте конфигурацию маршрутизатора, находящегося в конце следующего участка маршрута, чтобы убедиться в том, что обозначения подсети и маски в ней соответствуют конфигурации устройства-отправителя.
Если информация о конфигурации задана правильно, проверьте, возможно ли выполнить с устройства-отправителя или с маршрутизатора, находящегося в конце следующего участка маршрута, эхо-тестирование любого другого устройства в текущем сегменте локальной сети. Если эхо-тестирование адреса следующего участка маршрута выполнить невозможно и этот адрес представляет собой виртуальный адрес HSRP, попытайтесь выполнить эхо-тестирование одного из действительных IP-адресов маршрутизатора, находящегося в конце следующего участка маршрута. Если фактический адрес является достижимым, а виртуальный адрес — нет, то для устранения нарушений связи может потребоваться проверка функционирования средств HSRP. А если устройство не может связаться с некоторыми или со всеми устройствами в сегменте локальной сети, то это указывает на наличие физического нарушения связи, неправильной конфигурации коммутатора (или моста) или повторяющегося IP-адреса.
Выявление наличия повторяющихся IP-адресов
Для выявления наличия повторяющихся IP-адресов можно отключить проверяемое устройство от локальной сети или закрыть проверяемый интерфейс, а затем выполнить эхо-тестирование устройства-получателя с другого устройства в том же сегменте локальной сети. Если эхо-тестирование будет выполнено успешно, то в сегменте локальной сети имеется еще одно устройство с тем же IP-адресом. Для определения МАС-адреса конфликтующего устройства можно проверить таблицу ARP на устройстве, с которого было выполнено эхо-тестирование.
Но если к этому времени еще не устранено нарушение связи, которое имеет место либо на устройстве-отправителе, либо на маршрутизаторе, находящемся в конце следующего участка маршрута, перейдите к следующему разделу.
Устранение физических нарушений связи
В настоящем разделе описаны способы устранения физических нарушений связи на уровнях 1 и 2 таких локальных сетей, как Ethernet или Token Ring. Информация о поиске неисправностей в коммутируемых каналах или соединениях распределенной сети приведена в части IV.
Даже если стремление вначале приступить к поиску неисправностей на физическом уровне кажется обоснованным, как правило, причины нарушения связи могут быть обнаружены быстрее, если поиск неисправностей вначале проводится на уровне 3, а затем
происходит переход на более низкие уровни после обнаружения действительной физической неисправности или ее признаков.
Ниже перечислены возможные причины нарушения связи.
Ошибки в параметрах конфигурации.
Неисправен или неправильно подключен кабель.
Кросс коммутационного шкафа неисправен или неправильно подключен.
Неисправны аппаратные средства (интерфейс или порт).
Слишком большой объем трафика через интерфейс.
Выявление нарушений конфигурации
Проверьте, подключены ли все кабели к соответствующим портам. Убедитесь в том, что все кроссы правильно подключены к соответствующим модулям с применением подходящих для этого кабелей и методов подключения. Проследите за тем, чтобы порты коммутатора или концентратора были настроены на ту виртуальную локальную сеть или тот домен коллизий, для которых они предназначены, и для них были установлены соответствующие опции с учетом условий применения алгоритма распределенного связующего дерева и других требований.
Проверка кабельных соединений
Убедитесь в том, что применяется кабель соответствующего типа. Если между двумя оконечными системами (например, персональным компьютером и маршрутизатором) установлено прямое соединение, то может потребоваться специальный перекрещивающийся кабель. Проверьте также, что соединительный кабель интерфейса устройства-отправителя подключен правильно и находится в хорошем состоянии. Если возникают сомнения в том, что соединение между интерфейсом и кабелем находится в хорошем состоянии, отсоедините и снова присоедините кабель, при этом убедившись в том, что соединение выполнено надежно. Попытайтесь заменить кабель заведомо исправным. Если кабель подключается к стенной розетке, воспользуйтесь кабельным тестером для проверки правильности подключения проводов в розетке. Кроме того, проверьте все применяемые трансиверы, чтобы убедиться в том, что все они имеют соответствующий тип, правильно подключены и должным образом настроены. Если замена кабеля не решает проблемы, попытайтесь заменить трансивер, если он применяется в этом соединении.
Проверка конфигурации
Убедитесь в том, что интерфейс на данном устройстве настроен должным образом и не закрыт. Если устройство подключено к концентратору или к коммутатору, проверьте, правильно ли настроен порт на концентраторе или коммутаторе и не закрыт ли он. Проверьте и скорость, и режим передачи (дуплексный или полудуплексный).
Проверка сетевого интерфейса
Большинство интерфейсных (или сетевых) плат имеет индикаторный светодиод, который показывает, исправно ли соединение; этот светодиод часто называют световым индикатором. На интерфейсной плате могут быть также установлены светодиоды, которые показывают, происходит ли передача или прием трафика, сокращенно обо-
значаемые ТХ (сокращение от transmit) и RX (сокращение от receive). Если индикаторные светодиоды интерфейсной платы не показывают исправное соединение, выключите питание устройства, снимите и снова установите интерфейсную плату.
Устранение нарушений связи по протоколу IP и проблем маршрутизации
При устранении нарушений связи по протоколу IP в крупных сетях всегда рекомендуется иметь под рукой схему сети, которая позволяет понять, по какому пути должен проходить трафик, и сравнить его с фактически выбранным путем.
Если для управления прохождением IP-пакетов по сети применяется маршрутизация, то нарушения связи могут возникнуть на любом участке маршрута от отправителя к получателю, поэтому проверьте связь на каждом участке маршрута, чтобы определить, где разорван путь, с помощью описанной ниже методологии поиска неисправностей.
Нарушения связи могут возникать по следующим причинам.
В маршрутизаторе отсутствует информация о маршруте к устройству- отправителю или устройству-получателю.
В сети имеется циклический маршрут или другие нарушения в работе протокола маршрутизации.
Возникла неисправность, которая исключает возможность установить связь на физическом уровне.
Проблемы, связанные с нехваткой ресурсов на маршрутизаторе, не позволяют обеспечить нормальную работу маршрутизатора. К числу таких проблем относятся недостаточный объем памяти, нехватка буферов или перегрузка процессора.
Имеются ошибки в параметрах конфигурации маршрутизатора.
Возникло нарушение в работе программного обеспечения маршрутизатора.
Фильтр пакетов или брандмауэр препятствует прохождению трафика, соответствующего определенному IP-адресу или протоколу.
Возникла проблема, связанная с несоответствием значений MTU.
Определение исходной точки для поиска неисправностей
Наиболее детализированный способ поиска причин нарушения связи, безусловно, предусматривает принятие в качестве отправной точки следующего участка маршрута, проходящего от устройства-отправителя, и последовательное продвижение по всем участкам маршрута на пути к устройству-получателю с проверкой в этом процессе всех возможных путей. Затем необходимо проверить все основные возможности связи по протоколу IP (и в случае необходимости, по протоколу более высокого уровня) между текущим и каждым следующим маршрутизатором. Хотя в некоторых случаях этот способ поиска неисправностей является единственно возможным, обычно этот процесс можно сократить, вначале выполнив проверку маршрута от устройства- отправителя к устройству-получателю с помощью утилиты traceroute, чтобы определить первый подозреваемый участок маршрута. Если способ с применением утилиты traceroute не позволяет получить ответ, то необходимо перейти к использованию более трудоемкого способа.
Обнаружив отправную точку для поиска неисправностей, подключитесь к этому маршрутизатору по протоколу Telnet или с помощью консоли и проверьте, можно ли выполнить с него эхо-тестирование устройства-отправителя и устройства-получателя. При выполнении этой операции следует учитывать, что маршрутизатор всегда отправляет пакет эхо-тестирования из интерфейса, ближайшего к проверяемому устройству. Поэтому в некоторых случаях может потребоваться использование дополнительных опций утилиты ping для указания исходного интерфейса, поскольку в ином устройстве-получателе пакетов эхо-тестирования может отсутствовать информация о том, как достичь применяемого по умолчанию адреса отправителя; такая ситуация обычно возникает в последовательных интерфейсах, при настройке конфигурации которых применяется специальная система адресации.
Проверка ресурсов
Если создается впечатление, что маршрутизатор работает слишком медленно или не повторяет на экране (в режиме эхо-повтора) текст, который вводится администратором достаточно быстро, или возникает подозрение, что проблема связана с недостатком ресурсов, проверьте ресурсы маршрутизатора. Проверьте оперативную память с помощью команды show memory; особенно важно проверить, что в конфигурацию не входит опция terminal length 0, так как в противном случае выполнение указанной команды потребует много времени. Проанализируйте, каков объем доступной памяти, проверив величину самой крупной области свободной памяти. Если эта величина является низкой (составляет 5% от общего объема памяти маршрутизатора), воспользуйтесь командой show process memory, чтобы определить, какой процесс (процессы) “захватил” память.
Замедленный отклик маршрутизатора может быть также вызван перегрузкой процессора. Такое предположение можно проверить с помощью команды show process cpu. В результате выполнения этой команды на экране появятся два значения, выраженных в процентах (такие как 75%/24%). Первое число показывает общую загрузку процессора маршрутизатора, а второе позволяет узнать, какая часть загрузки процессора связана с обработкой прерываний. Если общая загрузка процессора превышает 90 процентов в течение продолжительного периода времени (10-15 минут), то необходимо определить, чем обусловлена вся эта загрузка процессора. Для этого применяется команда show process, которая позволяет получить перечень функционирующих процессов и определить, какая часть ресурсов процессора ими используется. Если загрузка процессора слишком велика, то может стать невозможным получение доступа к маршрутизатору с консоли и по протоколу Telnet.
В данной книге не рассматриваются все возможные процессы, функционирующие в маршрутизаторах, но некоторые из них заслуживают упоминания. В частности, процесс IP Input привязан к трафику, коммутируемому с помощью программного процесса. Некоторые категории трафика часто вызывают увеличение объема работы, выполняемой программным процессом коммутации трафика. К ним относятся трафик широковещательной и многоадресатной рассылки, информация обновления маршрутов или трафик, предназначенный для передачи по IP-адресу маршрутизатора. Например, лавинообразное увеличение объема широковещательного трафика вызывает более интенсивное функционирование процесса IP Input, в результате чего нагрузка процессора может возрасти до 99%. Ниже перечислены отдельные протоколы маршрутизации, применение которых приводит к возникновению процессов, потребляющих определенную часть ресурсов маршрутизатора:
IP BGP;
IP EIGRP;
IP OSPF.
Если протокол маршрутизации предусматривает применение рекурсивных вычислений, то возможно, что один из применяемых при этом процессов увеличил нагрузку процессора; но в большинстве случаев это — обычное явление.
Проверка наличия связи
Если с маршрутизатора невозможно выполнить эхо-тестирование устройства- отправителя или устройства-получателя, проверьте наличие в таблице маршрутизации маршрута к устройству-получателю пакетов эхо-тестирования. Следует учитывать, что желательно предусмотреть использование в маршрутизаторе предусмотренного по умолчанию маршрута к этому устройству-получателю пакетов эхо-тестирования, поэтому для соблюдения данного условия может потребоваться выполнить настройку команды ip classless. Если в маршрутизаторе отсутствует маршрут к устройству- получателю пакетов эхо-тестирования, то может потребоваться либо устранить нарушения в работе протокола маршрутизации, если он применяется в сети, либо добавить в таблицу маршрутизации статический маршрут к сети получателя. Маршрутизатор может успешно поддерживать связь только при том условии, что в нем есть информация о маршруте и к устройству-отправителю, и к устройству-получателю.
Если не все попытки выполнения эхо-тестирования оказались успешными, то проверьте наличие нескольких путей к устройству-получателю пакетов эхо- тестирования. Если таких путей несколько, то возможно, что на одном пути встречаются неисправности, а другие действуют безотказно. Это может служить признаком появления циклического маршрута или наличия неисправности на пути прохождения пакетов. Единственный способ обнаружения такой неисправности состоит в последовательном переходе ко всем устройствам, находящимся в конце очередного участка маршрута, и проверке связи с этих устройств.
Отсутствие 100%-ного успеха при выполнении команды эхо-тестирования может также указывать на наличие неисправных каналов или каналов с высокой нагрузкой. Изучите статистические показатели интерфейсов, выполнив команду show interface для всех исходящих интерфейсов, чтобы проверить, не являются ли они причинами нарушений в работе. При анализе статистических данных следует всегда учитывать, что маршрутизаторы могут накапливать информацию годами; всегда проверяйте продолжительность непрерывной работы маршрутизатора, которую можно узнать с помощью команды show version, а также время последнего сброса счетчиков, указанное в начале вывода команды show interface. Как правило, счетчики показывают процент успешно принятых или переданных пакетов достаточно точно. Но если значения счетчиков уже давно не переустанавливались в начальные значения или есть подозрение о наличии неисправности, то счетчики необходимо сбросить с использованием команды clear counters и прочитать новые показания по истечении достаточно продолжительного периода времени. Если обнаружено нарушение в работе распределенной сети или коммутируемого канала, обратитесь к части IV. А если обнаружено нарушение в работе соединения локальной сети, см. выше раздел “Устранение физических нарушений связи”.
Проверка списков управления доступом
С помощью команды ip access-group проверьте, применяются ли в маршрутизаторе к рассматриваемому интерфейсу какие-либо списки доступа, а также определите, установлены ли какие-либо иные средства брандмауэров шт и фильтры пакетов. Позволяют ли средства фильтрации пакетов выполнять необходимые операции обмена данными между устройством-отправителем и устройством-получателем с помощью применяемого протокола? Если вы не имеете ответа на этот вопрос, см. выше раздел “Устранение нарушений в работе протоколов верхнего уровня".
Проверка преобразования сетевых адресов
Проверьте, применяется ли в данном маршрутизаторе конфигурация, обеспечивающая преобразование сетевых адресов. Если она предусмотрена, то с помощью какого способа должно выполняться преобразование адресов пакетов, передаваемых от устройства-отправителя к устройству-получателю? Правильно ли выполнена настройка конфигурации средств преобразования?
Для поиска ответов на эти вопросы может потребоваться перейти к одному из маршрутизаторов, находящихся в конце очередных участков маршрута. Записывайте на бумаге сведения о том, какие маршрутизаторы вы уже проверили. Отмечайте также, какие проблемы или неясности возникли после перехода к каждому маршрутизатору. Эти записи помогут вам обнаружить циклические маршруты и будут служить источником полезной информации, если вы сочтете необходимым обратиться к службе поддержки.
Устранение нарушений в работе протоколов верхнего уровня
Даже несмотря на то, что проблемы связи между устройством-отправителем и устройством-получателем чаще всего возникают из-за нарушений в работе протокола IP, они могут также возникать в процессе функционирования конкретных протоколов верхнего уровня, таких как FTP, HTTP или Telnet. Эти протоколы опираются в своей работе на базовый транспортный уровень протокола IP, но могут служить причиной определенных нарушений связи, которые зависят от настройки брандмауэров и фильтров пакетов. Иногда возникают такие ситуации, что от устройства-отправителя к устройству-получателю успешно передается весь трафик, кроме, допустим, электронной почты. Перед поиском неисправностей на этом уровне необходимо вначале определить, возможен ли обмен данными между устройством-отправителем и устройством-получателем по протоколу IP. Если связь по протоколу IP существует, то нарушение в работе следует искать на прикладном уровне.
Ниже перечислены возможные нарушения в работе.
Неправильная настройка фильтра пакетов или брандмауэра, предназначенного для определенного протокола, соединения данных или возвратного трафика.
На сервере остановлена необходимая служба.
На сервере возникла проблема при аутентификации устройства-отправителя или исходной сети.
Имеет место несоответствие версий или несовместимость программного обеспечения сервера и клиента.
Общее описание процесса поиска причин нарушения в работе
Для поиска причин нарушения связи по протоколу верхнего уровня необходимо знать, как работает этот протокол. Как правило, эту информацию можно найти в последнем документе RFC с описанием рассматриваемого протокола или на Web- странице разработчика. Ниже перечислены некоторые вопросы, на которые необходимо ответить, чтобы убедиться в том, что вы знаете рассматриваемый протокол.
Какие сетевые протоколы нижнего уровня используются данным протоколом (TCP, UDP, ICMP, IGMP или другие)?
Какой номер порта протокола TCP или UDP используется данным протоколом?
Требуются ли для работы данного протокола какие-либо входящие соединения TCP или входящие пакеты UDP?
Предусматривает ли протокол внедрение IP-адреса в часть данных пакета?
Эксплуатируется ли вами клиент или сервер данного протокола?
Если протокол предусматривает включение IP-адресов в часть данных пакета и на пути прохождения установлены средства трансляции сетевых адресов (NAT — Network Address Translation), то шлюз NAT должен иметь информацию о том, как должны обрабатываться пакеты, передаваемые по этому протоколу, так как в противном случае попытки установить соединение окончатся неудачей. Шлюзы NAT обычно не вносят изменения в часть данных пакета, если в них не предусмотрены такие функции. К числу протоколов, предусматривающих включение IP-адресов в часть данных пакета, в частности, относятся FTP, SQLNet и Microsoft WINS.
Если возникает неопределенность в отношении того, берет ли на себя брандмауэр или маршрутизатор обработку потока данных, относящихся к конкретному приложению или протоколу, то могут быть выполнены следующие действия по определению того, что действительно происходит (следует учитывать, что в некоторых ситуациях не все эти действия являются осуществимыми).
Переместить клиент за пределы действия брандмауэра или устройства трансляции адресов.
Проверить, может ли клиент вступить во взаимодействие с сервером, находящимся в той же подсети, что и клиент.
Перехватывать информацию сетевой трассировки в локальной сети клиента и в локальной сети, ближайшей к серверу (или лучше всего, в локальной сети сервера, если это возможно).
Если служба основана на применении кода ASCII, то можно попытаться обратиться с помощью программы telnet к порту службы с маршрутизатора, наиболее близкого к серверу, а затем последовательно переходить по узлам сети все ближе и ближе к клиенту.
Протокол HTTP передачи гипертекста
HTTP (Hypertext Transfer Protocol — протокол передачи гипертекста) применяется для передачи файлов, из которых состоят Web-страницы. Хотя спецификация HTTP позволяет передавать данные по этому протоколу через порт 80 с помощью протокола
TCP или UDP, в большинстве реализаций применяется протокол TCP. В защищенной версии рассматриваемого протокола (SHTTP) используется порт TCP 443.
Возможность связи по протоколу HTTP можно проверить с помощью любого приложения Telnet, позволяющего указывать номер порта. Для этого необходимо вызвать программу telnet, указав IP-адрес сервера получателя и порт 80. При этом должно появиться вступительное сообщение, которое указывает, что с сервером имеется связь по протоколу HTTP.
Протокол FTP
В протоколе FTP используются два или несколько соединений TCP для осуществления передачи данных. В начале сеанса клиент FTP открывает соединение TCP с портом 21 на сервере FTP. Это соединение называется управляющим соединением и используется для передачи между клиентом и сервером команд и информации о результатах взаимодействия. По управляющему соединению не передаются данные, такие как файлы или листинги каталогов; вместо этого данные передаются по отдельному соединению TCP, которое создается специально для выполнения текущего запроса. Это соединение данных может быть открыто несколькими разными способами, которые перечислены ниже.
Традиционный (или активный) режим. FTP-сервер открывает обратное соединение TCP с портом 20 клиента. Этот метод не может применяться в многопользовательской системе, поскольку запросы по протоколу FTP могут отправлять одновременно несколько пользователей, и система не сможет увязать соответствующее входящее соединение данных FTP с определенным пользователем.
Многопользовательский традиционный (или активный) режим. FTP-клиент передает FTP-серверу указание открыть соединение с некоторым портом, случайно выбранным в диапазоне от 1024 до 65535. Такой метод создает довольно значительную брешь в защите, поскольку он требует, чтобы системный администратор разрешил создавать входящие соединения TCP со всеми портами, имеющими номера свыше 1023. Хотя брандмауэры, которые контролируют трафик FTP и динамически разрешают открытие входящих соединений, позволяют закрыть эту' брешь в защите, трафик такого типа запрещен во многих корпоративных сетях. В большинстве FTP-клиентов с интерфейсом командной строки этот метод передачи применяется по умолчанию и предусматривается использование команды passive (или подобной ей команды) для перехода в пассивный режим.
Пассивный режим. FTP-клиент передает FTP-серверу указание, что ему требуется пассивное соединение, а сервер в ответ передает IP-адрес и номер порта, с которыми FTP-клиент может открыть соединение для передачи данных по протоколу TCP. Этот метод является намного более безопасным, поскольку он не требует получения разрешений на установление входящих соединений TCP с FTP-клиентом. Во многих корпоративных сетях разрешен только этот тип передачи данных по протоколу FTP. Но хотя в большинстве популярных Web- броузеров по умолчанию применяется этот метод передачи FTP, не следует рассчитывать на то, что так оно и происходит в действительности.
Управляющее соединение FTP можно проверить с помощью любого приложения Telnet, позволяющего указывать номер порта. Для этого необходимо вызвать программу telnet, указав IP-адрес сервера получателя и порт 21. При этом должно появиться вступительное сообщение, которое указывает, что с сервером имеется связь по протоколу FTP.
Как правило, если клиент может установить управляющее соединение, но выборку листингов, каталогов или передачу файлов выполнить невозможно, то проблема связана с открытием соединения данных. Попытайтесь указать пассивный режим, поскольку он разрешен в большинстве брандмауэров.
Еще одна распространенная проблема при использовании протокола FTP состоит в том, что передача небольших файлов происходит успешно, а передача файлов значительных размеров обычно завершается в каждом файле примерно в одном и том же месте или через одинаковое время. Чтобы понять причины этого нарушения в работе, необходимо учитывать, что соединение данных (и передача) прекращается при закрытии управляющего соединения, и поскольку управляющее соединение при передаче больших файлов обычно простаивает, то возможно, что оно закрывается в среде NAT или РАТ, где установлен тайм-аут для простаивающих соединений TCP. Указанная проблема может быть устранена путем увеличения тайм-аута для простаивающих соединений TCP. Эта проблема обычно возникает, если программа FTP-клиента неправильно спроектирована.
Поскольку при передаче файлов по протоколу FTP обычно создаются пакеты максимального размера, то при несовпадении значений MTU на разных участках маршрута велика вероятность того, что передача файлов в одном направлении будет завершаться аварийно (например, операции передачи от сервера к клиенту могут завершаться успешно, а от клиента к серверу — оканчиваться неудачей). Такие ситуации могут возникать, если сервер находится в передающей среде локальной сети, поддерживающей большие значения MTU (например, в сети Token Ring единица MTU может иметь значение 4096 или больше). Обычно эта проблема решается автоматически путем фрагментации, но при неправильной настройке или установке опции IP Don't Fragment в дейтаграммах IP функционирование протокола может быть нарушено.
Электронная почта (IMAP, POP и SMTP)
При обработке электронной почты применяются серверы двух типов, которые предназначены для выполнения различных функций. По протоколу SMTP действуют почтовые шлюзы, которые взаимодействуют друг с другом, передавая и принимая почту. Протокол SMTP обеспечивает передачу сообщений электронной почты в формате ASCII с помощью протокола TCP; к серверу SMTP (почтовому шлюзу) можно подключиться, указав в программе telnet порт SMTP (25). Это — удобный способ проверки того, доступен ли почтовый шлюз.
При получении сообщения, предназначенного для локального клиента, почтовый шлюз записывает сообщение в энергонезависимую память, после чего управление сообщением передает почтовому серверу. Почтовый сервер ожидает запросов от клиента на получение электронной почты. Для получения электронной почты может применяться несколько разных способов. Во-первых, для непосредственного доступа к файлам почтового сервера могут использоваться обычные программы, предназначенные для работы с файлами; во-вторых, для получения почты может применяться один из нескольких сетевых протоколов. Наиболее популярными протоколами почтового клиента являются POP3 и IMAP4; в этих протоколах для передачи данных служит протокол TCP. Итак, в программах почтовых клиентов для получения почты применяются одни протоколы (например, POP3 и IMAP4), а для отправки почты — другие (как правило, SMTP). Поскольку для передачи и приема почты применяются два разных протокола и, чаще всего, два разных сервера, то иногда почтовые клиенты могут ус-
пешно выполнять одну из этих задач и не выполнять другую, поэтому поиск причин нарушений в работе при передаче и приеме почты должен осуществляться отдельно.
При проверке конфигурации почтового клиента необходимо проверять и почтовый шлюз (сервер SMTP), и почтовый сервер (сервер POP или IMAP). Протокол SMTP не поддерживает широкого набора средств защиты и не требует какой-либо аутентификации (проверки подлинности пользователя), поэтому, чтобы исключить возможность для пользователей, не имеющих на это право, отправлять почтовые сообщения на серверы, администраторы часто запрещают хостам, которые не относятся к внутренней сети, использовать серверы SMTP для передачи (или перенаправления) почты.
Для проверки возможности установить связь с сервером SMTP, IMAP или POP может применяться любое приложение Telnet, позволяющее указывать номер порта. Для этого при вызове программы Telnet необходимо указать IP-адрес сервера получателя и задать, соответственно, порт 25, 143 или ПО. Должно появиться приветственное сообщение, подтверждающее, что связь с сервером установлена успешно.
Протокол Telnet
Если попытка подключения по протоколу Telnet к конкретному серверу с одного из хостов завершилась неудачей, попытайтесь подключиться к нему с маршрутизатора или с нескольких других устройств. Если при попытке подключения по протоколу Telnet к серверу не будет получено приглашение к регистрации, то необходимо проверить следующее.
Возможно ли выполнить обратный поиск адреса клиента в системе DNS. Многие серверы Telnet отвергают попытки установить соединение с IP-адресов, не имеющих записи DNS. Такая проблема часто возникает при назначении IP-адресов по протоколу DHCP, если администратор не ввел записи DNS для пулов DHCP.
Возможно, что приложение Telnet не может согласовать с сервером соответствующие опции, поэтому не может подключиться. За таким процессом согласования можно проследить на маршрутизаторе Cisco с помощью команды debug telnet.
Возможно, что на сервере получателя доступ по протоколу Telnet запрещен или для приема запросов по этому протоколу назначен порт, отличный от порта 23.
Устранение нарушений в работе сервера доменных имен
Иногда возникают такие ситуации, когда существует возможность установить связь по протоколу IP, а попытки выполнить преобразование имен в системе DNS завершаются неудачей. Для поиска причин такого нарушения можно воспользоваться одним из следующих методов, чтобы определить, способна ли система DNS преобразовать конкретное имя в 1Р-адрес.
Выполните эхо-тестирование устройства-получателя по имени и проверьте, появляется ли при этом сообщение об ошибке, указывающее, что это имя преобразовать невозможно.
Если вы работаете на компьютере UNIX, воспользуйтесь командой nslookup <fully-qualified domain name> для выполнения поиска IP-адреса устройства- получателя с помощью системы DNS. В случае успешного выполнения этой команды на экран должен быть выведен адрес соответствующего хоста:
unixS nslookup www.somedomain.com
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name:www.somedomain.com
Address: 10.1.1.1
Если выполнение команды nslookup завершается неудачей, на экране появляются примерно такие результаты:
unixS nslookup www.somedomain.com
Server: localhost
Address: 127.0.0.1
*** localhost can't find www.notvalid.com: Non-existent host/domain
Если система DNS успешно преобразует имя хоста, вернитесь к разделу “Сужение проблемной области”, приведенному выше в данной главе, чтобы приступить к очередному этапу поиска неисправностей. В ином случае продолжайте поиск причин нарушения в работе следуюшим образом.
Определите применяемый сервер имен; способ получения соответствуюшей информации зависит от операционной системы, поэтому необходимо обратиться к справочному руководству по соответствуюшей операционной системе или устройству. Ниже приведены самые типичные способы получения такой информации.
На маршрутизаторе Cisco введите команду show run и найдите в выходных данных поле name-server.
В операционной системе Windows 95 или 98 воспользуйтесь программой winipcfg.exe.
В операционной системе Windows 2000 или NT вызовите на выполнение программу ipconfig.exe.
На платформе UNIX введите команду cat /etc/resolv.conf в приглашении ко вводу команд.
Убедитесь в том, что может быть выполнено эхо-тестирование сервера имен с использованием его IP-адреса. Если операция эхо-тестирования завершается неудачей, см. выше раздел “Сужение проблемной области", где описана процедура проверки связи между клиентом и сервером имен.
Проверьте возможность выполнения преобразования имен в конкретном домене. (Например, если хост имеет имя Hostl.test.com, то на нем должна обеспечиваться возможность преобразовывать имена других хостов в домене test.com, допустим, host2.test.com.)
Проверьте, можно ли преобразовать одно или несколько доменных имен за пределами конкретного домена.
Если имена хостов преобразуются успешно во всех доменах, кроме того, где находится устройство-получатель, то неисправность может быть связана с нарушением в
работе системы доменных имен, к которой относится устройство-получатель. Обратитесь к администратору, под чьим контролем находится устройство-получатель.
Если же не удается успешно выполнить преобразование имен в собственном домене или во многих внешних доменах, обратитесь к администратору системы DNS, поскольку могут иметь место нарушения в работе локальной системы DNS (или, возможно, на хосте применяется неправильно сконфигурированный сервер доменных имен).
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco
Прежде чем обратиться в центр Cisco ТАС, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе своей системы.
Кроме этого, выполните следующие действия и подготовьте указанные документы, которые позволят специалистам центра Cisco ТАС быстрее предоставить вам помощь.
Держите под рукой схему сети или хотя бы схему той части, в которой обнаружена неисправность. Убедитесь в том, что указаны все IP-адреса и соответствующие им маски сети или значения длины префикса.
Подготовьте для передачи инженеру ТАС всю информацию, которая была собрана к настоящему времени при поиске неисправностей.
Если создается впечатление, что нарушена работа лишь немногих маршрутизаторов (меньше четырех), перенаправьте в файл вывод команды show tech, выполненной на этих маршрутизаторах.
Возможность получения доступа извне по коммутируемому каналу или по протоколу Telnet также значительно упрощает поиск неисправностей.
Дополнительная информация
Дополнительная информация, включая материалы о поэтапной процедуре настройки и полные примеры команд, применяемых в процессе устранения нарушений в работе протокола 1Р, приведена в следующих книгах и на Web-страницах.
Web-узел центра ТАС, на который можно перейти с Web-узла Cisco (ССО — Cisco Connection Online) или непосредственно обратиться по адресу www.cisco.com/tac.
Интерактивная документация по операционной системе Cisco IOS на Web-узле Cisco, по адресу www.cisco.com.
Stevens, W. Richard. TCP/IP Illustrated, Volume 1. Addison-Wesley.
Дуглас, Э. Камер. Сети TCP/IP, Т.1,3. -Мл Издательский дом “Вильямс”, 2002-2003.
ГлаваГлава88
Глава
Глава
8
8
. Устранение нарушений № работе сети Novell IPX
у NetWare —.^сетевая операционная система и соответствующая ей система вспомогательных служб, созданная корпорацией Novell и представленная на рынке в начале 1980-х ^годов. В то вре^хети были небольшими и главным образом однородными, принципы взаимодействия рабочих групп в локальной сети еще только формулировались, а персо- k нальные компьютеру не имели такого широкого распространения, как в наши дни.
Ж Сетевая технолориясистемы NetWare в основном создана на базе сетевой операци- *онной системы XNS (Xerox Network Systems — системы сетей Xerox), которая была ^разработана корпорацией Xerox в конце 1970-х годов.
Ж^К началу/1990-х: годов доля рынка NetWare среди сетевых операционных систем ^^■стигла уровня 50—75%. Во всем мире было установлено свыше 500 тысяч сетей NetWare, и в процессе их развертывания все чаще происходило соединение с другими сетями, поэтому='Сйстема;NetWare и поддерживающие ее протоколы часто сосушество- eaiffl в одном и том же физическом канале со многими другими широко распростра- ненйыми протоколами,-включая TCP/IP, DECnet и AppleTalk. В настояшее время в сетях в основном; применяется протокол IP, но определенная доля трафика все еше относитсяк традиционному протоколу IPX корпорации Novell.
Основы технологии Novell
Сетевая операционная система NetWare определяет пять верхних уровней эталонной модели OSI. Ниже перечислены компоненты системы NetWare, которые занимают эти пять верхних уровней.
Протокол NCP (NetWare Core Protocol — базовый протокол NetWare).
-• Протокол SAP (Service Advertising Protocol — протокол анонсирования служб).
• • Протокол RIP (Routing Information Protocol — протокол маршрутной информации).
. ■ Система NetWare обеспечивает совместный доступ к файлам и принтерам, поддерживает такие разнообразные приложения, как передача электронной почты и доступ к базам данных, а также предоставляет доступ к другим службам. Систе- - ма NetWare основана на архитектуре клиент/сервер, как и многие другие сетевые , операционные системы, такие как NFS корпорации Sun Microsystems и Windows
NT корпорации Microsoft. В подобной архитектуре клиенты (иногда называемые рабочими станциями) обращаются к серверам для получения определенных услуг, например, доступа к файлам и принтерам.
Первые версии системы NetWare предусматривали использование в качестве клиентов небольших персональных компьютеров, а для развертывания серверов применялись намного более мощные персональные компьютеры серверного класса, но по мере дальнейшего распространения система NetWare была перенесена и на другие компьютерные платформы. В настоящее время клиенты и серверы NetWare могут быть развернуты практически в любой компьютерной системе, начиная от персонального компьютера и заканчивая мэйнфреймом.
Основной отличительной особенностью системы клиент/сервер является то, что в ней удаленный доступ является прозрачным для пользователя. Такая возможность достигается благодаря использованию средств дистанционного вызова удаленных процедур; так называется процесс, при котором локальная компьютерная программа, работающая на клиентском компьютере, отправляет на удаленный сервер вызов процедуры. Сервер вызывает удаленную процедуру и возвращает затребованную информацию в клиентскую программу на локальный компьютер.
На рис. 8.1 приведена упрощенная схема наиболее широко известных протоколов NetWare и их взаимосвязи с эталонной моделью OSI. При наличии соответствующих драйверов операционная система NetWare может взаимодействовать с любым протоколом доступа к передающей среде. На этом рисунке перечислены протоколы доступа к передающей среде, которые в настоящее время поддерживаются драйверами NetWare.
Рис. 8.1. Система NetWare и эталонная модель OSIРис. 8.1. Система NetWare и эталонная модель OSIПриложенияБазовый протокол NetWare (NCP)Приложение на основе RPCПоддержка LU 62Эмулятор NetBIOSКомандный интерпретатор NetWare (клиент)RPCSPXIPXEthernet/ IEEE 802.3Token Ring/ IEEE 802.5FDDIARCnetPPPПриложенияБазовый протокол NetWare (NCP)Приложение на основе RPCПоддержка LU 62Эмулятор NetBIOSКомандный интерпретатор NetWare (клиент)RPCSPXIPXEthernet/ IEEE 802.3Token Ring/ IEEE 802.5FDDIARCnetPPP
Рис. 8.1. Система NetWare и эталонная модель OSI
Рис. 8.1. Система NetWare и эталонная модель OSI
Приложения
Базовый протокол NetWare (NCP)
Приложение на основе RPC
Поддержка LU 62
Эмулятор NetBIOS
Командный интерпретатор NetWare (клиент)
RPC
SPX
IPX
Ethernet/ IEEE 802.3
Token Ring/ IEEE 802.5
FDDI
ARCnet
PPP
Приложения
Базовый протокол NetWare (NCP)
Приложение на основе RPC
Поддержка LU 62
Эмулятор NetBIOS
Командный интерпретатор NetWare (клиент)
RPC
SPX
IPX
Ethernet/ IEEE 802.3
Token Ring/ IEEE 802.5
FDDI
ARCnet
PPP
Доступ к передающей среде
Система NetWare может применяться в сетях Ethernet/IEEE 802.3, Token Ring/IEEE 802.5, FDDI, CDDI и ARCnet. Кроме того, система NetWare обеспечивает взаимодействие по синхронным каналам глобальной сети с использованием протокола PPP (Point-to-Point Protocol — протокол соединения “точка-точка”) .
Сетевой уровень
Оригинальным протоколом сетевого уровня корпорации Novell является протокол IPX (Internetwork Packet Exchange — межсетевой пакетный обмен). Если устройство, с которым должно быть огранизовано взаимодействие, находится в другой сети, протокол IPX обеспечивает перенаправление пакетов по адресу назначения через любые промежуточные сети. На рис. 8.2 показан формат пакета IPX.
Контрольная сумма
Длина пакета■
Управление транспортом Тип пакета
Сеть получателя
Узел получателя
Сокет получателя
Сеть отправителя
Узел отправителя
Сокет отправителя
Данные протокола верхнего уровня
Рис. 8.2. Формат пакета IPX
Ниже описаны поля пакета IPX.
Контрольная сумма. 16-битовое поле, которое заполнено битами 1.
Длина пакета. 16-битовое поле, которое указывает длину всей дейтаграммы IPX в байтах. Пакеты IPX могут иметь любую длину, вплоть до размера максимальной единицы передачи данных в сети (MTU — Maximum Transmission Unit), соответствующей конкретной передающей среде. Фрагментация пакетов не предусмотрена.
Управление транспортом. 8-битовое поле, содержащее информацию о количестве маршрутизаторов, через которые прошел пакет. Когда значение этого поля достигает 15, пакет уничтожается в соответствии с предположением, что мог возникнуть циклический маршрут. При использовании протокола NLSP (NetWare Link Services Protocol — протокол коммуникационных услуг в среде NetWare) пакет IPX на пути к месту назначения может пройти до 127 участков маршрута.
Тип пакета. 8-битовое поле, которое указывает, для какого протокола верхнего уровня предназначена информация данного пакета. Обычно в этом поле находится одно из двух значений: 5, которое обозначает протокол SPX (Sequenced Packet Exchange — упорядоченный пакетный обмен), и 17, которое соответствует протоколу NCP.
Сеть получателя (32-битовое поле), узел получателя (48-битовое поле) и сокет получателя (16-битовое поле). Поля, которые содержат информацию о получателе пакета.
Сеть отправителя (32-битовое поле), узел отправителя (48-битовое поле) и сокет отправителя (16-битовое поле). Поля, которые содержат информацию об отправителе пакета.
Данные протокола верхнего уровня. Информация для процессов верхнего уровня. Эту часть пакета называют также областью заголовков протокола более высокого уровня; в ней представлена информация для таких протоколов NetWare, как NCP или SPX. Указанные заголовки занимают область данных пакета IPX.
Протокол IPX создан на основе протокола сети XNS, но обладает некоторыми уникальными особенностями. Основное различие между этими двумя протоколами обнаруживается в области маршрутизации, поскольку в них применяются разные механизмы инкапсуляции. Инкапсуляцией называется процесс оформления информации и данных протокола верхнего уровня в виде фрейма. В сети Ethernet протокол XNS предусматривает применение стандартной инкапсуляции Ethernet, а пакеты IPX оформляются в виде фреймов Ethernet версии 2.0 или IEEE 802.3, без применения информации IEEE 802.2, которая обычно сопровождает эти фреймы. Схема инкапсуляции пакетов IPX в виде фреймов Ethernet и фреймов, соответствующих стандарту IEEE 802.3, приведена на рис. 8.3.
Примечание
В системе NetWare 4.0 поддерживается инкапсуляция пакетов IPX в виде стандартных фреймов IEEE 802.3. В ней также поддерживается инкапсуляция SNAP (Subnetwork Access Protocol — протокол доступа к подсети), которая предусматривает дополнение заголовков IEEE 802.2 путем предоставления кода, аналогичного заданному в спецификации Ethernet.
Ethernet
Стандарт IEEE 802.3
IPX
Адрес получателя
Ацрес получателя
Адрес получателя
Адрес отправителя
Адрес отправителя
Адрес отправителя
Тип
Длина
Длина
Данные протокола верхнего уровня
Заголовок 802.2
Данные IPX
Данные 802.2
CRC
CRC
CRC
Рис. 8.3. Форматы инкапсуляции Ethernet, IEEE 802.3 и IPX
В протоколе IPX для перенаправления пакетов в объединенной сети предусмотрено применение динамического протокола маршрутизации RIP. Как и в случае протокола IPX, в ходе разработки протокола RIP использовались результаты, полученные корпорацией Xerox при создании семейства протоколов XNS.
Корпорация Novell не только внесла изменения в применяемые механизмы инкапсуляции, но и ввела в свое семейство протоколов IPX дополнительный протокол, получивший название SAP. С помошью протокола SAP узлы, обеспечиваюшие доступ к службам, такие как файловые серверы и серверы печати, рассылают по сети информацию о своих адресах и предоставляемых услугах.
Кроме того, корпорация Novell обеспечила поддержку сетевых адресуемых модулей (NAU — Network Addressable Unit) типа LU (Logical Unit — логический модуль) версии 6.2 корпорации IBM. Модули LU 6.2 обеспечивают одноранговое взаимодействие в любой среде связи корпорации IBM. Средства поддержки модулей LU 6.2 системы NetWare позволяют обеспечить взаимодействие узлов NetWare по сети IBM. Для передачи по сети IBM пакеты NetWare инкапсулируются в пакеты LU 6.2.
Транспортный уровень
В системе NetWare в качестве транспортного протокола наиболее широко применяется SPX. Корпорация Novell разработала этот протокол на основе SPP (Sequenced Packet Protocol — протокол упорядоченной передачи пакетов) сети XNS. Как и TCP и многие другие транспортные протоколы, SPX представляет собой надежный протокол с установлением логического соединения, который дополняет дейтаграммные службы, предоставляемые протоколами уровня 3.
В документации Novell указано: “SPX представляет собой один из протоколов интерфейса IPXODI (Internetwork Packet Exchange Open Data-link Interface — открытый канальный интерфейс протокола межсетевого пакетного обмена). SPX разработан на основе протокола IPX корпорации Novell, с использованием спецификации протокола SPP корпорации Xerox. Он расширяет возможности протокола IPX, обеспечивая контроль над данными, передаваемыми по сети”.
Корпорация Novell обеспечивает также поддержку протоколов IP и UDP в форме инкапсуляции UDP/IP в других пакетах Novell, таких как пакеты SPX/IPX. Дейтаграммы IPX инкапсулируются в заголовки UDP/IP для передачи по объединенной сети, основанной на использовании протокола IP. В системе NetWare 5.0 протокол IP применяется непосредственно, но в предыдущих версиях этой системы он применялся только в описанной выше форме, которую часто сокрашенно называют NetWare/IP.
Протоколы верхнего уровня
Система NetWare поддерживает широкий набор протоколов верхнего уровня, но одни из них нашли более широкое распространение, чем другие. На клиентских компьютерах (в документации NetWare часто называемые рабочими станциями') функционирует командный интерпретатор NetWare, который перехватывает активизируемые приложениями вызовы функций ввода-вывода, чтобы определить, требуется ли для их выполнения доступ к сети. В случае положительного ответа на этот вопрос командный интерпретатор NetWare оформляет запросы в виде пакетов и передает их программному обеспечению более низкого уровня для обработки и передачи по сети. Ес-
ли же вызовы функций ввода-вывода не требуют доступа к сети, они просто передаются в локальную систему ввода-вывода. Клиентским приложениям не нужна информация о том, требуется ли доступ к сети для выполнения активизируемых ими вызовов функций ввода-вывода. Еше одним, но более общим механизмом перенаправления вызовов функций ввода-вывода, который поддерживается корпорацией Novell, является NetWare RPC.
Для выполнения прикладных запросов, которые могут поступать, например, из командного интерпретатора NetWare, предусмотрен ряд серверных процедур, доступ к которым предоставляется по протоколу NCP. К ним относятся процедуры, которые лежат в основе функционирования таких служб, как доступ к файлам и к принтерам, управление системой имен, ведение учетных записей, защита и синхронизация файлов.
Система NetWare поддерживает также спецификацию интерфейса сеансового уровня NetBIOS (Network Basic Input/Output System — сетевая базовая система ввода- вывода) корпораций IBM и Microsoft. Программное обеспечение эмуляции NetBIOS системы NetWare позволяет эксплуатировать в этой системе программы, разработанные в соответствии со стандартной спецификацией интерфейса NetBIOS.
К числу служб прикладного уровня NetWare относятся NetWare MHS (Message Handling Service — система управления сообщениями), Btrieve, NLM (NetWare Loadable Module — загружаемый модуль системы NetWare) и различные средства взаимодействия с сетевыми продуктами корпорации IBM. NetWare MHS представляет собой систему доставки сообщений, которая обеспечивает передачу электронной почты. Btrieve — это применяемая корпорацией Novell программная реализация механизма доступа к базам данных с архитектурой в виде двоичного дерева. Модули NLM представляют собой дополнительные программные компоненты, которые могут подключаться к ядру операционной системы NetWare в целях расширения ее функциональных возможностей. В настоящее время на рынке представлен широкий набор модулей NLM (для дополнительных стеков протоколов, служб связи, систем управления базами данных и многих других служб), поставляемых корпорацией Novell и независимыми разработчиками.
Устранение нарушений в работе сети Novell IPX
В настоящем разделе представлена информация, необходимая для устранения нарушений в работе программного обеспечения протокола Novell IPX, характеризующихся отсутствием связи и снижением производительности. Здесь рассматриваются конкретные признаки неисправностей в сети Novell IPX, перечислены проблемы, которыми может быть обусловлено появление каждого признака неисправности, и показаны способы решения этих проблем.
Настоящий раздел состоит из следующих подразделов, в которых описаны наиболее типичные нарушения в работе сети Novell IPX.
Novell IPX: клиент не может подключиться к серверу в той же локальной сети.
Novell IPX: клиент не может подключиться к серверу в другой локальной сети.
Novell IPX: клиент цр может подключиться к серверу по сети PSN (Packet Switched Network — сеть с коммутацией пакетов).
Novell IPX: клиент не может подключиться к серверу по сети ISDN (Integrated Services Digital Network — цифровая сеть с комплексным обслуживанием).
Novell NetBIOS: приложение не может подключиться к серверу через маршрутизатор.
IPX RIP: отсутствие связи через маршрутизатор RIP протокола IPX.
IPX RIP: обновления протокола SAP не распространяются маршрутизатором.
IPX EIGRP: отсутствие связи через маршрутизатор EIGRP (Enhanced Interior Gateway Routing Protocol — расширенный протокол маршрутизации внутреннего шлюза) протокола IPX.
IPX EIGRP: маршрутизатор не устанавливает связь со смежными маршрутизаторами.
IPX EIGRP: обновления протокола SAP не распространяются маршрутизатором.
IPX EIGRP: маршрутизатор не выходит из активного режима.
Novell IPX: отсутствие надежной связи.
Novell IPX: низкая производительность.
Novell IPX: клиент не может подключиться к серверу в той же локальной сети
Признак неисправности. Клиенты не могут устанавливать соединения с серверами, расположенными в той же локальной сети, и подключаться к серверам в удаленных сетях.
В табл. 8.1 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
^Таблица 8.1. Novell IPX: клиент не может подключиться к серверу в той же : к ■ локальной сети.J
Проблема
Решение
Неправильно
Убедитесь в том, что программное обеспечение и на клиентах, и на сер-
настроен клиент
верах имеет текущую версию, правильно настроено и загружено должным
или сервер
образом. На клиентских компьютерах проверьте сетевые драйверы и конфигурацию, заданную в файле net.cfg.
На серверах проверьте, что сообщения SAP вырабатываются правильно и что все необходимые модули NLM загружаются должным образом. Воспользуйтесь командой track on для контроля над функционированием средств маршрутизации и протокола SAP.
Проверьте, как осуществляется инкапсуляция на клиентах и серверах, чтобы убедиться в том, что применяемые при этом форматы полностью соответствуют друг другу.
Для получения дополнительной информации о настройке аппаратного обеспечения клиента или сервера обратитесь к документации, которая входит в комплект соответствующего устройства
Недостаточное
Убедитесь в том, что имеется достаточное количество доступных пользо-
количество поль-
ватсльских лицензий NetWare. Для получения информации об общем ко-
зовательских ли-
личсствс доступных соединений и просмотра используемых соединений
цензий
откройте экран утилиты Monitor на сервере NetWare
Несовпадение
Все серверы, подключенные к одному и тому же сегменту, должны быть
сетевых номеров
привязаны к одинаковому внешнему сетевому номеру. При наличии несовпадающих сетевых номеров перенаправление пакетов не выполняется должным образом.
Проблема
Решение
Проследите за появлением на системной консоли примерно таких сообщений об ошибках:
"Router configuration error detected" (Обнаружена ошибка в конфигурации маршрутизатора);
"Node address claims network x should be у" (Узел node address сообщает, что сеть с номером х должна иметь номер у).
Эти сообщения об ошибках указывают, что один из серверов в локальной сети имеет номер, конфликтующий с другими сетевыми номерами. В приведенном выше сообщении node address обозначает адрес узла сетевой платы, из которой исходят пакеты с неправильным адресом; х — сетевой номер, указанный в пакетах, полученных от этого узла, а у — сетевой номер, заданный на сервере, который является причиной ошибки.
Все серверы в одной и той же локальной сети должны иметь одинаковый внешний сетевой номер (если в них используются фреймы одинакового типа). Если сетевые номера не совпадают, перенастройте конфликтующий сервер, указав правильный внешний сетевой номер
Нарушения в работе клиентских, серверных или других аппаратных средств
Проверьте все сетевые платы, трансиверы, порты концентраторов, коммутаторы и другие аппаратные средства. Проверьте соответствующие светодиоды, чтобы убедиться в том, что не горят индикаторы ошибок. Замените все неисправные или работающие со сбоями аппаратные средства. Для получения информации об устранении нарушений в работе клиентских, серверных или других аппаратных средств, которые не относятся к маршрутизаторам Cisco, обратитесь к документации, входящей в поставку этих аппаратных средств
Нарушения в работе передаюшей среды
Шаг 1. Проверьте всю кабельную разводку и все соединения. Убедитесь в том, что кабели не повреждены, все соединения выполнены правильно и обеспечивают надежный контакт.
Шаг 2. Воспользуйтесь exec-командой show interfaces для проверки на отсутствие ошибок ввода или вывода в интерфейсах, а также других признаков нарушения в работе передаюшей среды.
Шаг 3. Если в результатах выполнения этой команды обнаруживается слишком большое количество ошибок, примените привилегированную exec-команду clear interface counter для очистки счетчиков интерфейса.
Шаг 4. Снова проверьте результаты выполнения команды show interfaces. Если количество ошибок быстро возрастает, это может указывать на нарушения в работе передаюшей среды.
Для получения более подробной информации об устранении нарушений в работе передаюшей среды обратитесь к главе данной книги, в которой рассматриваются вопросы устранения нарушений в работе передаюшей среды, применяемой в конкретной сети
Novell IPX: клиент не может подключиться к серверу в другой локальной сети
Признак неисправности. Клиенты локальной сети не могут устанавливать соединения с серверами, находящимися в другой локальной сети, через один или несколько маршрути-
заторов, соедини своей локально?
звать появление
тоших эти локальные сети. Но клиенты могут подключаться к серверам в i сети. В табл. 8.2 перечислены основные проблемы, которые могут вы- этого признака неисправности, и описаны решения этих проблем.
Примечани
Если клиенты “Novell IPX: юн денный выше расположенар необходимо та тесь к разделу протокола IPX. нийв работер
е
не могут подключиться к серверам в своей локальной сети, см. раздел 1ент не может подключиться к серверу в той же локальной сети”, приве- в этой главе. А если между местной и удаленной локальными сетями )аспределенная сеть, то в качестве одной из причин возникших проблем ,кже рассматривать нарушения в работе распределенной сети. Обрати/ с описанием нарушений в работе распределенной сети, касающихся , который приведен ниже в этой главе, или к описаниям общих наруше- аспределенной сети, приведенным в других главах данной книги.
I Таблица 8.2.
Novell IPX: клиент не может подключиться к серверу в другой
Проблема
локальной сети
Решение
Программное обеспечение интерфейса маршрутизатора остановлено
Шаг 1. Воспользуйтесь exec-командой show interfaces на маршрутизаторе для проверки состояния интерфейсов маршрутизатора. Проверьте, исправно ли функционируют интерфейс и протокол канала передачи данных.
Шаг 2. Если программное обеспечение интерфейса остановлено администратором, воспользуйтесь командой конфигурации интерфейса по shutdown, чтобы снова перевести программное обеспечение интерфейса в рабочее состояние.
Шаг 3. Если программное обеспечение интерфейса или протокола канала передачи данных остановлено, обратитесь к главе с описанием процедур устранения нарушений в работе передающей среды, используемой в конкретной сети
Применяются несовместимые методы инкапсуляции Ethernet
Шаг 1. Воспользуйтесь привилегированной exec-командой show ipx interfaces для проверки типа инкапсуляции, заданного в конфигурации маршрутизатора. По умолчанию в маршрутизаторах Cisco применяется инкапсуляция на основе фреймов типа Ethernet 802.3 корпорации Novell. (В документации Cisco этот метод инкапсуляции именуется "novell-ether".)
Шаг 2. Сравните тип инкапсуляции, заданной в конфигурации интерфейсов маршрутизатора, с типом инкапсуляции, который используется клиентами и серверами.
Шаг 3. Если в маршрутизаторе используется один тип инкапсуляции, а в клиентах и серверах — другой, то имеет место несоответствие.
Измените тип инкапсуляции, применяемый либо в клиентах и серверах, либо в маршрутизаторе, соответствующим образом, чтобы во всех устройствах использовался одинаковый метод инкапсуляции. В маршрутизаторах для задания типа инкапсуляции применяется команда конфигурации интерфейса ipx network network encapsulation encapsulation-type. Для получения информации о том, как откорректировать тип инкапсуляции в клиентах и серверах обратитесь к документации, которая входит в поставку аппаратных средств клиента и сервера
Проблема
Решение
Нарушение в работе, связанное с применением пакетов LIPXНарушение в работе, связанное с применением пакетов LIPXЕсли в сети применяется версия NetWare 3.12 или последующие версии и разрешено использование протокола LIPX (Large Internetwork Packet Exchange — межсетевой обмен крупными пакетами), то может возникнуть такая ситуация, при которой клиент и сервер согласуют между собой размер пакета, больший того размера, который способен поддерживать маршрутизатор. При такой ситуации может оказаться, что промежуточные маршрутизаторы уничтожают слишком большие пакеты. Если же применение протокола LIPX не разрешено, то сервер проверяет сетевой номер, который указан в пакете с запросом размера буфера, полученном от клиента, и если этот сетевой номер отличается от сетевого номера сервера (а это означает, что пакет с запросом поступил из другой сети через маршрутизатор), то сервер требует, чтобы клиент использовал вместо указанного им значения размера буфера размер, равный 512 байтам (жестко закодированное значение).
Нарушение в работе, связанное с применением пакетов LIPX
Нарушение в работе, связанное с применением пакетов LIPX
Для получения информации о настройке конфигурации LIPX обратитесь к документации, которая входит в поставку аппаратных средств
Возникло рассогласование между спецификациями скоростей кольцаВозникло рассогласование между спецификациями скоростей кольцаВ среде Token Ring во всех устройствах должно соблюдаться требование по поддержке установленной скорости кольца (4 или 16 Мбит/с), так как в противном случае связь между устройствами нарушается.
Возникло рассогласование между спецификациями скоростей кольца
Возникло рассогласование между спецификациями скоростей кольца
Шаг 1. Воспользуйтесь exec-командой show interfaces token в маршрутизаторе. Найдите в результатах значение скорости кольца. Сравните это значение со спецификацией скорости кольца на серверах Novell.
Шаг 2. Если значения скорости кольца не совпадают, внесите изменения в конфигурацию сервера или маршрутизатора соответствующим образом, чтобы все станции поддерживали одинаковую скорость кольца. В маршрутизаторах для изменения значения скорости кольца применяется команда конфигурации интерфейса ringspeed. Для получения информации о настройке скорости кольца на серверах Novell обратитесь к документации, которая входит в поставку аппаратных средств
В сети имеются повторяющиеся номера узлов, присвоенные маршрутизаторамВ сети имеются повторяющиеся номера узлов, присвоенные маршрутизаторамШаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для проверки текущей конфигурации каждого маршрутизатора в пути следования пакетов.
В сети имеются повторяющиеся номера узлов, присвоенные маршрутизаторам
В сети имеются повторяющиеся номера узлов, присвоенные маршрутизаторам
Шаг 2. Проверьте номер узла, указанный в глобальной команде конфигурации ipx routing node. Номер узла представляет собой либо заданный пользователем номер узла, либо МАС-адрес первой интерфейсной платы Ethernet, Token Ring или FDDI в маршрутизаторе.
Шаг 3. Номер узла, который входит в конфигурацию каждого маршрутизатора, должен быть уникальным. Если на нескольких маршрутизаторах применяется один и тот же номер, введите глобальную команду конфигурации no ipx routing для отмены маршрутизации IPX в маршрутизаторе.
Шаг 4. Снова инициализируйте маршрутизацию IPX, введя команду ipx routing (не указывая при этом номер узла). Воспользуйтесь командой show running-config, чтобы проверить, что вся остальная часть информации о конфигурации IPX все еше остается правильной
Проблема
Решение
В сети имеются повторяюшиеся сетевые номераВ сети имеются повторяюшиеся сетевые номераВозникло нарушение в работе аппаратных средств маршрутизатораВозникло нарушение в работе аппаратных средств маршрутизатораСуществует не предусмотренный проектом мост между сегментамиСуществует не предусмотренный проектом мост между сегментами
В сети имеются повторяюшиеся сетевые номера
В сети имеются повторяюшиеся сетевые номера
Возникло нарушение в работе аппаратных средств маршрутизатора
Возникло нарушение в работе аппаратных средств маршрутизатора
Существует не предусмотренный проектом мост между сегментами
Существует не предусмотренный проектом мост между сегментами
Каждый сетевой номер должен быть уникальным во всей объединенной сети Novell IPX. При наличии повторяющихся сетевых номеров перенаправление пакетов не может быть выполнено должным образом.
Шаг 1. Воспользуйтесь привилегированными exec-командами show ipx servers и show ipx route. Проверьте наличие в результатах выполнения этих команд адресов серверов, которые были получены из неисправного интерфейса.
Шаг 2. Например, если известно, что в локальной сети имеется сервер с сетевым номером Зс.0000.0с01.2345, а результаты выполнения описанной выше команды show указывают на то, что этот сервер расположен в удаленной сети, то возможно, что в удаленной сети имеется сервер, в котором используется тот же сетевой номер.
Шаг 3. Если есть основания полагать, что один из сетевых номеров повторяется, определите неправильно настроенный сервер по методу исключения. Такой подход может оказаться весьма трудоемким, особенно если у вас нет доступа к каждому сетевому устройству в объединенной сети Novell IPX. При обнаружении неправильно настроенного сервера откорректируйте конфигурацию этого сервера для исключения повторяюшегося сетевого номера
Проверьте все порты маршрутизатора, интерфейсные процессоры и другие аппаратные средства маршрутизатора. Убедитесь в том, что платы установлены должным образом и что отсутствуют неисправности аппаратных средств. Замените дефектные или работающие со сбоями аппаратные средства.
Для получения дополнительной информации об устранении нарушений в работе аппаратных средств маршрутизатора обратитесь к главе 3
Шаг 1. Вызовите на выполнение exec-команду show ipx traffic в промежуточных маршрутизаторах. По результатам этой команды определите, увеличивается ли значение в поле bad hop count, которое показывает количество неправильно заданных участков маршрута.
Шаг 2. Если показания счетчика bad hop count увеличиваются, воспользуйтесь сетевым анализатором для поиска в рассматриваемых сегментах периодически повторяющихся пакетов. Выполняйте также поиск пакетов обновлений RIP и SAP. Если между сегментами установлен мост, не предусмотренный проектом, то могут быть обнаружены пакеты со значением числа участков маршрута, возросшим до 15; в такой момент маршруты для этих пакетов исчезают, а затем вновь появляются непредсказуемым образом.
Шаг 3. Попытайтесь обнаружить появляющиеся в локальной сети пакеты, которые поступают из удаленных сетей с известными сетевыми номерами. В частности, ищите пакеты, имеющие в качестве исходного адреса МАС-адрсс удаленного узла вместо МАС-адреса маршрутизатора.
Шаг 4. Изучите пакеты, проходящие по каждому сегменту. В сегменте имеется мост, не предусмотренный проектом, если в нем появляются пакеты, имеющие в качестве исходного адреса МАС-адрес удаленного узла вместо МАС-адреса маршрутизатора.
Шаг 5. Удалите мост, не предусмотренный проектом, чтобы разорвать циклический маршрут, по которому циркулируют пакеты
Проблема
Решение
Возникло нарушение в работе протокола маршрутизации
Проблемы, характеризующиеся нарушением связи и снижением производительности, могут возникать при неправильной настройке и других нарушениях в работе протокола маршрутизации
Novell IPX: клиент не может подключиться к серверу по сети PSN
Признак неисправности. Клиент не может подключиться к серверу по сети PSN, такой как Frame Relay, Х.25 или SMDS, но может подключиться к локальным серверам.
Процедуры, применяемые при устранении нарушений в работе сети, характеризующихся отсутствием связи и не относящихся к среде PSN, описаны выше, в разделе “Novell IPX: клиент не может подключиться к серверу в другой локальной сети”.
В табл. 8.3 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 8.3. Novell IPX: клиент не может подключиться к серверу■
,' ' " ' по сети PSN ''•
Проблема
Решение
Ошибка преобразования адреса
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора.
Шаг 2. В зависимости от конкретной среды PSN, найдите записи команды конфигурации интерфейса х25 map ipx, frame-relay тар ipx1 или smds static-map ipx в результатах выполнения указанной выше команды show. Убедитесь в том, что преобразование адресов, указанное этими командами, соответствует приведенным ниже требованиям.
В сети Х.25 средства преобразования адресов обеспечивают преобразование протокольного адреса хоста в адрес хоста, соответствующий протоколу Х.121.
В сети Frame Relay средства преобразования адресов обеспечивают преобразование протокольного адреса следующего узла и идентификатора DLCI (Data-Link Connection Identifier — идентификатор подключения канального уровня), который обычно применяется для подключения к этому адресу.
В сети SMDS (Switched Multimegabit Data Service — коммутируемая мультимегабитовая служба передачи данных) средства преобразования адресов определяют статические записи для удаленных одноранговых маршрутизаторов SMDS.
1 Чтобы исключить необходимость в использовании таблиц адресов Frame Relay, вместо них можно применить протокол Inverse ARP (Inverse Address Resolution Protocol — протокол обратного преобразования адресов). Для настройки интерфейса на использование протокола Inverse ARP применяется команда конфигурации интерфейса frame-relay interface-dlci did broadcast. Для получения дополнительной информации об использовании этой команды обратитесь к руководствам Cisco IOS Wide-Area Networking Configuration Guide и Wide Area Networking Command Reference.
Проблема
Решение
Для получения дополнительной информации о настройке таблиц адресов обратитесь к документам Cisco IOS Wide Area Networking Configuration Guide и Wide Area Networking Command Reference
Несоответствие методов инкапсуляции
Шаг 1. Воспользуйтесь привилегированной ехес-командой show interfaces для определения применяемого типа инкапсуляции (такого как инкапсуляция Х.25, Frame Relay или SMDS). Найдите в результатах этой команды примерно такие строки: SerialO is up, line protocol is up
Hardware is MCI Serial
Internet address is 192.168.54.92 255.255.255.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, rely 255/255, load 1/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
Шаг 2. Если в указанных результатах отсутствует команда encapsulation, это означает, что применяется предусмотренная по умолчанию инкапсуляция HDLC (High-level Data Link Control — высокоуровневый протокол управления каналом). Но для обеспечения взаимодействия по сети PSN необходимо явно указать соответствующий тип инкапсуляции (например, для поддержки соединения Х.25 ввести команду encapsulation х25).
Выполните настройку конфигурации, задав надлежащий тип инкапсуляции, и воспользуйтесь командой show interfaces, чтобы проверить, правильно ли указан тип инкапсуляции
Неправильно присвоены идентификаторы DLCI (только в сети Frame Relay)
Шаг 1. Воспользуйтесь ехес-командой show frame-relay map в центральном маршрутизаторе дтя просмотра в составе конфигурации операторов присваивания идентификаторов Frame Relay, которые определены на данный момент.
Шаг 2. Проверьте каждый оператор преобразования Frame Relay, чтобы убедиться в том, что присваивание идентификаторов DLCI выполнено правильно. Следует учитывать, что должны обязательно применяться идентификаторы DLCI, полученные от провайдера Frame Relay. Помните, что значения DLCI играют важную роль в конфигурации локальной сети
Неправильно настроен тип LMI (только в сети Frame Relay)
Шаг 1. Воспользуйтесь привилегированной ехес-командой debug frame-relay Imi для определения типа LMI (Local Management Interface — интерфейс локального управления), применяемого в коммутаторе Frame Relay.
Шаг 2. Тип LMI установлен конкретным провайдером Frame Relay. Убедитесь в том, что применяется тип LMI, указанный провайдером
Заполнена очередь для широковещательных сообщений Frame Relay (только в сети Frame Relay)
Эта проблема чаще всего возникает в центральном маршрутизаторе сети Frame Relay со звездообразной структурой и дополнительными периферийными связями.
Шаг 1. Воспользуйтесь привилегированной ехес-командой show interfaces, чтобы проверить, есть ли данные об уничтоженных широковещательных фреймах Frame Relay.
Проблема
Решение
Шаг 2. Если количество фреймов, уничтоженных в очереди широковеша- тельных сообщений, слишком велико, увеличьте размер очереди с помощью команды конфигурации интерфейса frame-relay broadcast-queue size byte-rate packet-rate.
Синтаксис команды
frame-relay broadcast-queue size byte-rate packet-rate
Описание синтаксической структуры
size. Количество пакетов, которые могут одновременно находиться в очереди широковещательных сообщений. Значение по умолчанию — 64 пакета.
byte-rate. Максимальное количество байтов, передаваемых в секунду. Значение по умолчанию — 256 Кбайт/с.
packet-rate. Максимальное количество пакетов, передаваемых в секунду. Значение по умолчанию — 36 пакетов в секунду
Центральный маршрутизатор не перенаправляет пакеты SAP (только в сети Frame Relay)
В сети Frame Relay со звездообразной структурой и дополнительными периферийными связями пакеты SAP, полученные через один из интерфейсов центрального маршрутизатора, не перенаправляются обратно через тот же интерфейс в соответствии с правилом расшепления горизонта, которое указывает, что входяший пакет не может быть направлен в тот же сетевой интерфейс, из которого он поступил; это правило позволяет избежать возникновения бесконечного цикла маршрутизации при отказе одного из каналов. Для обеспечения правильного перенаправления пакетов SAP необходимо настроить подынтерфейсы для соответствуюшего интерфейса Frame Relay центрального маршрутизатора. Назначьте по одному подынтерфейсу для каждого периферийного узла. В центральном маршрутизаторе каждый по- дынтерфейс будет рассматриваться как физический интерфейс, что позволит выполнять в нем рассылку пакетов SAP, не нарушая правило расшепления горизонта. Дополнительная информация о настройке подынтерфейса содержится в документе Wide Area Networking Configuration Guide.
Примечание. Перенаправление пакетов SAP маршрутизатором может нарушиться в результате возникновения других проблем. Дополнительная информация представлена в разделе “IPX RIP: обновления протокола SAP не распространяются маршрутизатором" далее в этой главе
Отсутствует или неправильно настроен групповой адрес (только в сети SMDS)
Шаг 1. Воспользуйтесь привилегированной exec-командой show running-config для просмотра информации о конфигурации маршрутизатора. Проверьте запись команды конфигурации интерфейса smds multicast ipx.
Шаг 2. Если эта команда отсутствует, введите ее в конфигурацию, а если присутствует, проверьте правильность настройки группового адреса. Групповой адрес SMDS предоставляется провайдером SMDS
Novell IPX:
клиент не может подключиться к серверу
по сети ISDN
Признак неисправности. Клиент не может подключиться к серверу по каналу ISDN, но может подключиться к локальным серверам.
Процедуры, применяемые при устранении нарушений в работе сети, характеризующихся отсутствием связи и не относящихся к среде ISDN, описаны выше, в разделе “Novell IPX: клиент не может подключиться к серверу в другой локальной сети". Процедуры, применяемые при устранении нарушений при обмене данными по каналу ISDN, не относящихся к среде IPX, описаны в главе 17.
В табл. 8.4 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
' Таблица 8.4.
Novell IPX: клиент не может подключиться к серверу'
по сети ISDN.. .'. ,
Проблема
Решение
Отсутствуют или неправильно настроены статические операторы RIP и SAP
Шаг 1. Воспользуйтесь привилегированной exec-командой show running-config для просмотра информации о конфигурации маршрутизатора. Проверьте записи глобальных команд конфигурации ipx route и ipx sap.
В среде ISDN необходимы обе команды, которые задают, соответственно, статические маршруты и статические записи SAP; эти команды предоставляют клиентам и серверам в локальной сети информацию о клиентах и серверах в удаленной сети.
Шаг 2. Если не выполнена настройка статических маршрутов и статических записей SAP, введите эту информацию в конфигурацию с помощью команд ipx route и ipx sap. Дополнительная информация о настройке статических маршрутов и записей SAP приведена в документах Cisco IOS Network Protocols Configuration Guide, Part l и Network Protocols Command Reference, Part 1
Списки доступа, указанные в списках программы- номеронабирателя, неправильно настроены
Шаг 1. Воспользуйтесь привилегированной ехес-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Проверьте списки доступа, подготовленные для использования в списках программы-номеронабирателя.
Шаг 2. Убедитесь в том, что в списках доступа установлены запреты только на обновления маршрутов R1P, извещения SAP и на пакеты сериализации Novell. Если установлены запреты на прохождение других пакетов, могут возникать проблемы, характеризующиеся нарушением связи.
Шаг 3. Убедитесь в том, что списки доступа оканчиваются оператором access-list access-list-number permit -1, который позволяет активизировать программу-номеронабиратель для поддержки любого другого трафика IPX
Novell NetBIOS: приложение не может подключиться к серверу через маршрутизатор
Признак неисправности. Приложение, в котором используется протокол Novell NetBIOS (такое как Windows 95), не может подключиться к серверу через маршрутизатор. Клиент не может подключиться к серверам в той же локальной сети.
В табл. 8.5 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
i Таблица 8.5.ПроблемаОтсутствие команд ipx type-2 0- propagationi Таблица 8.5.ПроблемаОтсутствие команд ipx type-2 0- propagationОтсутствует команда ipx helper-addressОтсутствует команда ipx helper-addressNovell NetBIOS: приложение не может подключиться к серверу через маршрутизатор
i Таблица 8.5.
Проблема
Отсутствие команд ipx type-2 0- propagation
i Таблица 8.5.
Проблема
Отсутствие команд ipx type-2 0- propagation
Отсутствует команда ipx helper-address
Отсутствует команда ipx helper-address
РешениеРешениеШаг 1. Воспользуйтесь привилегированной exec-командой debug ipx packet или сетевым анализатором для просмотра пакетов Novell со спецификацией типа 20.
Решение
Решение
Предостережение. Соблюдайте осторожность, используя команду debug ipx packet. При распределении процессорного времени процессу формирования отладочного вывода присваивается один из самых высоких приоритетов, поэтому система может стать непригодной для выполнения обычной работы. По этой причине команды debug должны применяться только для диагностики конкретных проблем или проведения сеансов поиска неисправностей с участием сотрудников службы технической поддержки Cisco. Кроме того, команды debug следует использовать в период сокращения сетевого трафика и уменьшения количества пользователей. Это снижает вероятность того, что дополнительные издержки, связанные с выполнением команды debug, нарушат нормальную эксплуатацию системы.
Шаг 2. Воспользуйтесь привилегированной exec-командой show runningconfig, чтобы проверить наличие записей команды конфигурации интерфейса ipx type-20-propagation в маршрутизаторах в пути от клиента к серверу.
Шаг 3. Если команда ipx type-20-propagation отсутствует, введите ее в конфигурацию интерфейса для каждого интерфейса маршрутизатора в пути от клиента к серверу
Шаг 1. Воспользуйтесь привилегированной exec-командой debug ipx packet или сетевым анализатором для поиска пакетов Novell со спецификацией, имеющей тип, отличный от 20 (например, тип 0 или 4). Иногда приложения не соответствуют стандарту Novell, и в них применяются типы пакетов, отличные от типа 20.
Предостережение. Соблюдайте осторожность, используя команду debug ipx packet. При распределении процессорного времени процессу формирования отладочного вывода присваивается один из самых высоких приоритетов, поэтому система может стать непригодной для выполнения обычной работы. По этой причине команды debug должны применяться только для диагностики конкретных проблем или проведения сеансов поиска неисправностей с участием сотрудников службы технической поддержки Cisco. Кроме того, команды debug следует использовать в период сокращения сетевого трафика и уменьшения количества пользователей. Это снижает вероятность того, что дополнительные издержки, связанные с выполнением команды debug, нарушат нормальную эксплуатацию системы.
Шаг 2. Если обнаружены пакеты с типом, отличным от типа 20, воспользуйтесь привилегированной exec-командой show running-config для просмотра конфигурации маршрутизатора. Выясните, входит ли команда конфигурации интерфейса ipx helper-address в конфигурацию интерфейса, к которому подключен клиент.
Проблема
Решение
Шаг 3. Если команда ipx helper-address отсутствует, введите ее в конфигурацию соответствующих интерфейсов маршрутизатора. Убедитесь в том, что вспомогательный адрес (helper-address) представляет собой протокольный адрес IPX сервера NetBIOS, к которому должен подключиться клиент. Ниже показана синтаксическая структура команды ipx helper-address.
ipx helper-address network.node
Описание синтаксической структуры
network. Сеть, в которой находится целевой сервер IPX. Этот параметр представляет собой шестнадцатеричное чисто с восьмью цифрами, которое однозначно обозначает сетевой кабельный сегмент. В качестве него может быть указано число в диапазоне от 1 до FFFFFFFE. Сетевой номер, равный -1, указывает, что должна выполняться лавинная рассылка по всем сетям. В сетевом номере не нужно указывать ведущие нули. Например, для указания сетевого номера 000000AA достаточно ввести только шестнадцатеричные цифры АА.
node. Номер узла целевого сервера Novell. Этот параметр должен быть задан как 48-битовое значение, представленное в виде трех четырехразрядных шестнадцатеричных чисел, разделенных точками (в формате хххх.хххх.хххх). Номер узла FFFF.FFFF.FFFF служит для обозначения всех серверов
В рабочей станции не предусмотрена эксплуатация программного обеспечения
Убедитесь в том, что в рабочей станции предусмотрена эксплуатация программного обеспечения NetBIOS на базе IPX, а не какого-то иного протокола, например NetBEUI. Для получения информации о том, какие протоколы применяются в конкретной рабочей станции, обратитесь к документации поставщика
NetBIOS на базе IPX
IPX RIP: отсутствие связи через маршрутизатор IPX RIP
Признак неисправности. Маршрутизаторы IPX RIP блокируют соединения. Клиент не может подключиться к серверу через один или несколько маршрутизаторов, в которых эксплуатируется программное обеспечение протокола IPX RIP.
Примечание
Процедуры, применяемые при устранении нарушений в работе сети, характеризующихся отсутствием связи, и не касающиеся проблем маршрутизации IPX RIP, описаны выше, в разделе “Novell IPX: клиент не может подключиться к серверу в другой локальной сети”.
В табл. 8.6 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
j Таблица 8.6. IPX RIP: отсутствие связи через маршрутизатор IPX RIP
Проблема
Решение
Маршрутизация IPX RIP не настроена или неправильно настроена в маршрутизаторе
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора.
Шаг 2. Проверьте конфигурацию, чтобы убедиться в том, что в ней есть запись глобальной команды конфигурации ipx routing. Если эта запись отсутствует, введите команду ipx routing, чтобы разрешить маршрутизацию IPX.
После введения команды ipx routing в маршрутизаторе маршрутизация IPX RIP будет разрешена автоматически во всех интерфейсах, которым присвоен сетевой номер
Отсутствует команда ipx network в интерфейсе
Шаг 1. Воспользуйтесь привилегированной exec-командой show ipx interfaces для просмотра информации о состоянии всех интерфейсов IPX.
Шаг 2. Если результаты выполнения этой команды показывают, что нет ни одного интерфейса, в котором бы эксплуатировалось программное обеспечение IPX, или если программное обеспечение IPX не эксплуатируется в том интерфейсе, в котором следует, необходимо настроить соответствующие интерфейсы, задав адрес IPX. Сетевой номер IPX для сегмента, к которому подключен конкретный маршрутизатор, может предоставить администратор сервера Novell.
Чтобы разрешить применение программного обеспечения протокола IPX в каком-либо интерфейсе, введите команду конфигурации интерфейса ipx network number:
ipx network network [encapsulation encapsulation-type [secondary]]
Описание синтаксиса
network. Сетевой номер. Этот параметр представляет собой шестнадцатеричное число с восьмью цифрами, которое однозначно обозначает сетевой кабельный сегмент. В качестве него может быть указано число в диапазоне от 1 до FFFFFFFE. В сетевом номере не нужно указывать ведущие нули. Например, для задания сетевого номера 000000AA достаточно ввести только шестнадцатеричные цифры АА.
encapsulation encapsulation-type. (Необязательный параметр.) Тип инкапсуляции. Этот параметр может иметь одно из следующих значений.
агра. (Только для интерфейсов Ethernet.) Использовать тип инкапсуляции Ethernet II по спецификациям корпорации Novell. Эта инкапсуляция рекомендуется для сетей, которые обрабатывают и трафик IPX, и трафик TCP/IP.
hdlc. (Только для последовательных интерфейсов.) Использовать тип инкапсуляции HDLC.
Проблема
Решение
novell-ether. (Только для интерфейсов Ethernet.) Использовать тип инкапсуляции Ethernet 802.3 по спецификациям корпорации Novell. Этот тип инкапсуляции предусматривает применение заголовка МАС по стандарту 802.3, за которым непосредственно следует заголовок IPX с контрольной суммой FFFF. Применение инкапсуляции этого типа предусмотрено по умолчанию в версии 3.11 операционной системы NetWare.
sap. Для интерфейсов Ethernet использовать тип инкапсуляции Ethernet 802.2 по спецификациям корпорации Novell. Этот тип инкапсуляции предусматривает применение заголовка МАС по стандарту 802.3, за которым непосредственно следует заголовок LLC по стандарту 802.2. Применение инкапсуляции этого типа предусмотрено по умолчанию в версии 4.0 операционной системы NetWare.
Для интерфейсов Token Ring этот тип инкапсуляции предусматривает применение заголовка МАС по стандарту 802.5, за которым следует заголовок LLC по стандарту 802.2.
Для интерфейсов FDDI этот тип инкапсуляции предусматривает применение заголовка МАС по спецификации FDDI, за которым следует заголовок LLC по стандарту 802.2.
snap. Для интерфейсов Ethernet использовать тип инкапсуляции Ethernet SNAP по спецификациям корпорации Novell. Этот тип инкапсуляции предусматривает применение заголовка МАС по стандарту 802.3, за которым непосредственно следует заголовок SNAP LLC по стандарту 802.2.
Для интерфейсов Token Ring и FDDI этот тип инкапсуляции предусматривает применение заголовка МАС по стандарту 802.5 или по спецификации FDDI, за которым следует заголовок SNAP LLC по стандарту 802.2.
secondary. (Необязательный параметр.) Указывает дополнительную сеть, для которой выполнена настройка конфигурации после первой (первичной) сети
Возникло рассогласование установок таймера R1P
Значения установок таймера RIP, изменившиеся на серверах, работающих под управлением системы NetWare 4.x или более поздних версий, могут быть откорректированы. Рассогласования значений установок таймеров между маршрутизаторами и серверами могут привести к возникновению проблем, характеризующихся нарушением связи.
Шаг 1. Воспользуйтесь привилегированной exec-командой show ipx interfaces в маршрутизаторе для просмотра информации о состоянии интерфейсов IPX. Найдите в результатах выполнения этой команды примерно такие строки: C4500#show ipx interface
Updates each 60 seconds, aging multiples RIP: 3 SAP: 3
Проблема
Решение
Сравните значение таймера, настроенное в маршрутизаторе, со значением, настроенным в серверах Novell.
Шаг 2. Установки таймера в конфигурации серверов и маршрутизаторов должны быть одинаковыми во всей сети IPX.
Внесите изменения в конфигурацию маршрутизатора или серверов, чтобы привести значения таймера в соответствие с указанным требованием. В маршрутизаторе для корректировки интервала таймера RIP воспользуйтесь командой конфигурации интерфейса ipx update-time.
Для получения дополнительной информации о корректировке значения таймера в конфигурации серверов Novell обратитесь к документации сервера
Маршрутизатор не распространяет обновления
RIP
Шаг 1. Воспользуйтесь привилегированной exec-командой debug ipx routing activity в маршрутизаторе. Найдите в результатах выполнения этой команды данные об обновлениях маршрутов, отправляемые маршрутизатором через каждый интерфейс.
Шаг 2. Если данные об обновлениях RIP, отправляемых через рассматриваемые интерфейсы, не обнаружены, попытайтесь отменить маршрутизацию RIP с использованием глобальной команды конфигурации no ipx routing, а затем снова ее разрешить с помощью команды ipx routing.
Воспользуйтесь командой show running-config, чтобы проверить, что остальная часть конфигурации IPX все еше остается правильной.
Если отмена и повторное разрешение маршрутизации RIP не позволяет устранить нарушение в работе, попытайтесь перезапустить маршрутизатор
Неправильно настроены сетевые фильтры
Шаг 1. Воспользуйтесь привилегированной exec-командой show accesslists в проверяемых маршрутизаторах, чтобы определить, настроены ли списки доступа Novell IPX.
Шаг 2. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Результаты выполнения этой команды показывают, заданы ли списки доступа в команде конфигурации интерфейса ipx input-network-filter или ipx output-network-filter.
Примеры
В следующем примере список доступа 876 управляет тем, какие сети добавляются к таблице маршрутизации при получении обновлений маршрутизации IPX через интерфейс Ethernet 1: access-list 876 permit lb interface ethernet 1 ipx input-network-filter 876
Обновления маршрутизации для сети 1b будут приняты, а для всех прочих сетей обновления маршрутизации неявно запрещены и не вводятся в таблицу маршрутизации.
ПроблемаПроблемаРешениеРешениеМаршруты не перераспределяются должным образомМаршруты не перераспределяются должным образомМаршрутизатор не распространяет пакеты SAPМаршрутизатор не распространяет пакеты SAPСледующий пример является вариантом предыдущего, в котором явно запрещены обновления маршрутизации для сети 1а и явно разрешены обновления для всех прочих сетей:
Проблема
Проблема
Решение
Решение
Маршруты не перераспределяются должным образом
Маршруты не перераспределяются должным образом
Маршрутизатор не распространяет пакеты SAP
Маршрутизатор не распространяет пакеты SAP
access-list 876 deny la
access-list 876 permit -1
Шаг 3. Если в одной из этих команд используются списки доступа, отключите фильтры с помощью команды no ipx input-networkfilter или по ipx output-network-filter.
Шаг 4. Проверьте, может ли клиент подключиться к серверу должным образом. Если соединение установлено успешно, то один или несколько списков доступа требуют корректировки.
Шаг 5. Чтобы определить, какой именно список доступа содержит ошибку, последовательно вводите по одному фильтру IPX до тех пор, пока создание соединений станет невозможным.
Шаг 6. После выявления искомого списка доступа, содержащего ошибку, проверьте каждый оператор access-list, чтобы определить, не блокирует ли он трафик, поступающий из необходимых сетей. Обнаружив такой оператор, введите в конфигурацию явно заданные операторы permit для сетей, информация о которых должна распространяться обычным образом в обновлениях маршрутов.
Шаг 7. После корректировки списка доступа снова введите соответствующий фильтр, чтобы убедиться в том, что соединения между клиентом и сервером по-прежнему устанавливаются успешно. Продолжайте проверку списков доступа до тех пор, пока все фильтры не будут разрешены, притом что клиент все еще будет иметь возможность подключаться к серверу
Шаг 1. Воспользуйтесь привилегированной exec-командой show ipx route для просмотра таблицы маршрутизации IPX.
Шаг 2. Проверьте таблицу маршрутизации и убедитесь в том, что информация о маршрутах получена с помощью ожидаемого протокола и через ожидаемый интерфейс.
Шаг 3. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Проверьте каждую запись глобальной команды конфигурации ipx router и соответствующие команды redistribute, если они имеются.
Шаг 4. Убедитесь в том, что выполнена настройка перераспределения маршрутов между протоколом IPX RIP и требуемыми протоколами. Проверьте, все ли необходимые сети заданы для перераспределения маршрутов.
Примечание. Перераспределение маршрутов между IPX RIP и EIGRP, а также между IPX RIP и NLSP разрешено автоматически.
Для получения дополнительной информации о настройке перераспределения маршрутов обратитесь к документу Network Protocols Configuration Guide, Part I
Информация об устранении этого нарушения в работе сети приведена ниже, в разделе “IPX RIP: обновления протокола SAP не распространяются маршрутизатором"
IPX RIP: обновления протокола SAP не распространяются маршрутизатором
Признак неисправности. Пакеты SAP, соответствующие спецификациям Novell, не перенаправляются через маршрутизатор, в котором эксплуатируется программное обеспечение IPX RIP. При этом клиент может оказаться неспособным подключиться к серверам через один или несколько маршрутизаторов, или же возможность его подключения может появляться только время от времени.
Примечание
Процедуры, применяемые при устранении нарушений в работе протокола IPX R1P, не касающихся проблем при использовании протокола SAP, описаны выше, в разделе “IPX RIP: отсутствие связи через маршрутизатор IPX RIP". Другие нарушения в работе, характеризующиеся наличием неустойчивой связи, описаны в разделе “Novell IPX: отсутствие надежной связи” ниже в этой главе.
В табл. 8.7 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
; Таблица 8.7. IPX RIP: обновления протокола SAP не распространяются <
Проблема
маршрутизатором.[
Решение
Возникло рассогласование установок таймера SAP
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Найдите в результатах выполнения этой команды записи команды конфигурации интерфейса ipx sap-interval.
Пример
В следующем примере обновления SAP передаются (и ожидаются) в последовательном интерфейсе 0 через каждые 5 минут:
interface serial 0
ipx sap-interval 5
Шаг 2. В интерфейсах локальной сети рекомендуется использовать предусмотренный по умолчанию интервал SAP, равный 1 минуте, поскольку интервал на серверах не может быть изменен. Для восстановления этого значения, предусмотренного по умолчанию, примените команду no ipx sap-interval. Ниже показана синтаксическая структура команд ipx sap-interval и no ipx sap-interval.
ipx sap-interval minutes no ipx sap-interval
Описание синтаксиса
• minutes. Интервал между обновлениями SAP, передаваемыми сервером связи, в минутах. Значение по умолчанию — 1 минута. Если параметр minutes имеет значение 0, то периодические обновления не передаются.
Выполняя настройку конфигурации последовательных интерфейсов, следите за тем, чтобы в конфигурации на обоих концах последовательного канала были заданы одинаковые значения интервала. Для корректировки интервала SAP используйте команду конфигурации интерфейса ipx sap-interval
ПроблемаПроблемаРешениеРешениеФильтры SAP настроены неправильноФильтры SAP настроены неправильно
Проблема
Проблема
Решение
Решение
Фильтры SAP настроены неправильно
Фильтры SAP настроены неправильно
Шаг 1. Воспользуйтесь привилегированной exec-командой show accesslists в проверяемых маршрутизаторах, чтобы определить, выполнена ли в них настройка списков доступа Novell IPX. С помощью привилегированной exec-команды show running-config определите, есть ли такие фильтры SAP, в которых используется любой из списков доступа, входящих в конфигурацию. В конце данной главы приведен перечень пакетов SAP, соответствующих спецификациям Novell, в котором даны описания пакетов SAP, а также указаны шестнадцатеричные и десятичные значения.
Шаг 2. Если фильтры SAP введены в конфигурацию, отмените их, удалив соответствующим образом команды конфигурации интерфейса ipx input-sap-filter и ipx output-sap-filter (с использованием версий этих команд с префиксом по).
Шаг 3. Воспользуйтесь привилегированной exec-командой debug ipx sap activity, чтобы определить, успешно ли выполняется перенаправление трафика SAP. В результатах выполнения этой команды debug должны содержаться данные об имени сервера, сетевом номере и МАС-адресе пакетов SAP.
Предостережение. При распределении процессорного времени процессу формирования отладочного вывода присваивается один из самых высоких приоритетов, поэтому система может стать непригодной для выполнения обычной работы. По этой причине команды debug должны применяться только для диагностики конкретных проблем или проведения сеансов поиска неисправностей с участием сотрудников службы технической поддержки Cisco. Кроме того, команды debug следует использовать в период сокращения сетевого трафика и уменьшения количества пользователей. Это снижает вероятность того, что дополнительные издержки, связанные с выполнением команды debug, нарушат нормальную эксплуатацию системы.
Шаг 4. Если перенаправление информации SAP выполняется маршрутизатором правильно, это означает, что уничтожение обновлений SAP маршрутизатором вызвано одним из фильтров SAP.
Шаг 5. Чтобы определить, какой именно фильтр SAP содержит ошибку, последовательно вводите по одному фильтру до тех пор, пока не будет прекращено перенаправление пакетов SAP маршрутизатором.
Шаг 6. Откорректируйте рассматриваемый список доступа, чтобы обеспечить прохождение через маршрутизатор трафика SAP, который должен быть перенаправлен. Убедитесь в том, что настройка конфигурации всех необходимых портов выполнена с применением явно заданного оператора permit.
Шаг 7. Продолжайте последовательно вводить в действие один фильтр за другим, проверяя, продолжает ли трафик SAP по-прежнему перенаправляться должным образом, до тех пор, пока не убедитесь в том, что конфигурации всех фильтров определены правильно
Проблема
Решение
Сервер Novell не передает обновления SAP
Шаг 1. Воспользуйтесь привилегированной exec-командой debug ipx sap activity или анализатором протоката для поиска обновлений SAP, поступающих от серверов.
Предостережение. При распределении процессорного времени процессу формирования отладочного вывода присваивается один из самых высоких приоритетов, поэтому система может стать непригодной для выполнения обычной работы. По этой причине команды debug датжны применяться татько для диагностики конкретных проблем или проведения сеансов поиска неисправностей с участием сотрудников службы технической поддержки Cisco. Кроме того, команды debug следует испатьзовать в период сокращения сетевого трафика и уменьшения катичества патьзователей. Это снижает вероятность того, что дополнительные издержки, связанные с выпатнением команды debug, нарушат нормальную эксплуатацию системы.
Шаг 2. Если сервер не передает обновления SAP, убедитесь в том, что сервер подключен к сети, запушен и нормально функционирует.
Шаг 3. Проверьте, правильно ли выполнена настройка сервера для передачи обновлений SAP. Для получения дополнительной информации о том, как правильно настроить конфигурацию программного обеспечения сервера, обратитесь к документации конкретного сервера
Серверы Novell не обрабатывают обновления SAP так же быстро, как их генерирует маршрутизатор
Шаг 1. Воспатьзуйтесь привилегированной exec-командой show interfaces, чтобы проверить наличие данных об уничтоженных выходных пакетах.
Шаг 2. Если число уничтоженных пакетов слишком велико, примените в маршрутизаторе exec-команду show ipx servers. Сравните вывод этой команды с выводом команды display servers, введенной с системной консати на серверах Novell.
Шаг 3. Если результаты выпатнения команды display servers на сервере Novell показывают татько часть перечня записей SAP, отображаемых в маршрутизаторе, это может означать, что серверы Novell не способны обрабатывать обновления SAP с такой же скоростью, с какой они генерируются маршрутизатором.
Шаг 4. Воспользуйтесь командой конфигурации интерфейса ipx outputsap-delay для корректировки значения задержки между пакетами в многопакетном обновлении SAP. В документации Novell указано, что эта задержка составляет 55 мс.
Ниже показана синтаксическая структура команды ipx output-sap-delay, ipx output-sap-delay delay
Описание синтаксиса
• delay. Задержка в миллисекундах между пакетами в многопакетном обновлении SAP
IPX EIGRP: отсутствие связи через маршрутизатор EIGRP протокола IPX
Признак неисправности. Маршрутизаторы EIGRP протокола IPX блокируют соединения. Клиенты не могут подключиться к серверам через один или несколько маршрутизаторов с программным обеспечением IPX EIGRP.
Примечание
Процедуры, применяемые при устранении нарушений в работе сети, характеризующихся отсутствием связи, и не касающиеся проблем маршрутизации IPX EIGRP, описаны выше, в разделе “Novell IPX: клиент не может подключиться к серверу в другой локальной сети”.
В табл. 8.8 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 8.8. IPX EIGRP: отсутствие связи через маршрутизатор EIGRP . j . протокола IPX;
Проблема
Решение
Настройка конфигурации протокола IPX EIGRP в маршрутизаторе не выполнена или выполнена неправильно
В отличие от IPX RIP, по умолчанию при выдаче глобальной команды конфигурации ipx routing программное обеспечение протокола IPX EIGRP не вводится в действие во всех интерфейсах.
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора.
Шаг 2. Проверьте конфигурацию, чтобы убедиться в том, что в ней есть запись глобальной команды конфигурации ipx routing. Эта команда разрешает глобальное применение маршрутизации IPX.
Шаг 3. Если указанная команда в конфигурации отсутствует, воспользуйтесь глобальной командой конфигурации ipx routing, чтобы разрешить маршрутизацию IPX. Ниже показана синтаксическая структура команды ipx routing.
ipx routing [node]
Описание синтаксиса
• node. (Необязательный параметр.) Номер узла маршрутизатора. Этот параметр должен быть задан как 48-битовое значение, представленное в виде трех четырехразрядных шестнадцатеричных чисел, разделенных точками (в формате хххх.хххх.хххх). Он не должен представлять собой групповой адрес.
Если параметр node при вызове команды не будет задан, то в качестве своего адреса узла маршрутизатор использует аппаратный МАС-адрес, который присвоен ему в настоящее время. Под этим подразумевается МАС-адрес первой интерфейсной платы Ethernet, Token Ring или FDDI. Если же в маршрутизаторе отсутствуют интерфейсы, соответствующие указанному условию (например, имеются только последовательные интерфейсы), то параметр node должен быть обязательно указан.
Проблема
Решение
Шаг 4. Проверьте наличие в конфигурации маршрутизатора глобальной команды конфигурации ipx router eigrp autonomous-system-number и соответствующих команд конфигурации интерфейса ipx network.
Шаг 5. Если указанные команды в конфигурации отсутствуют, выполните настройку конфигурации процесса EIGRP, а затем назначьте его дня обслуживания соответствующих интерфейсов с помощью команд ipx network.
В следующем примере показано, как разрешить применение протокола R1P в сетях 1 и 2, а протокола EIGRP в сети 1: ipx routing
i
interface ethernet 0
ipx network 1
i
interface ethernet 1
ipx network 2
ipx router eigrp 100
network 1
Для интерфейса не задана команда ipx network
Шаг 1. Воспользуйтесь привилегированной ехес-командой show ipx interfaces для просмотра информации о состоянии всех интерфейсов IPX.
Шаг 2. Если результаты выполнения команды показывают, что программное обеспечение IPX не эксплуатируется ни в одном из интерфейсов или не эксплуатируется в одном из тех интерфейсов, где должно эксплуатироваться, то необходимо настроить конфигурацию соответствующего интерфейса с указанием адреса IPX.
Чтобы разрешить эксплуатацию программного обеспечения протокола IPX в одном из интерфейсов, введите команду конфигурации интерфейса ipx network number
Применение программного обеспечения IPX RIP не разрешено в сети с подключенными к ней серверами Novell
Серверы Novell не способны взаимодействовать с программным обеспечением IPX EIGRP, поэтому необходимо следить за тем, чтобы в интерфейсах, подключенных к сегментам локальной сети, в которых установлены серверы Novell, было разрешено применение программного обеспечения IPX RIP.
Выполните привилегированную exec-команду show running-config в рассматриваемом маршрутизаторе для просмотра информации о конфигурации маршрутизатора. Убедитесь в том, что во всех интерфейсах, подключенных к сегменту локальной сети, в которых установлены серверы Novell, разрешено применение программного обеспечения IPX RIP.
Все прочие протоколы маршрутизации запрещать необязательно, но при эксплуатации программного обеспечения IPX EIGRP и IPX RIP в одном и том же интерфейсе иногда наблюдается снижение производительности
Фильтры настроены неправильно
Шаг 1. Воспользуйтесь привилегированной ехес-командой show access-lists в рассматриваемых маршрутизаторах, чтобы определить, выполнена ли настройка конфигурации списков доступа Novell IPX.
ПроблемаРешение
Шаг 2. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Проверьте, заданы ли списки доступа в командах конфигурации интерфейса ipx input-network-filter или ipx output-network-filter.
Шаг 3. Если в одной из этих команд используются списки доступа, отключите фильтры с помощью команды no ipx input-networkfilter или по ipx output-network-filter.
Шаг 4. Проверьте, может ли клиент подключиться к серверу должным образом. Если соединение установлено успешно, то один или несколько списков доступа требует корректировки.
Шаг 5. Чтобы определить, какой именно список доступа содержит ошибку, последовательно вводите по одному фильтру IPX до тех пор, пока создание соединений станет невозможным.
Шаг 6. После выявления искомого списка доступа, содержащего ошибку, проверьте каждый оператор access-list, чтобы определить, не блокирует ли он трафик, поступающий из необходимых сетей. Обнаружив такой оператор, введите в конфигурацию явно заданные операторы permit для сетей, информация о которых должна распространяться обычным образом в обновлениях маршрутов.
Шаг 7. После корректировки списка доступа снова введите в действие соответствующий фильтр, чтобы убедиться в том, что соединения между клиентом и сервером по-прежнему устанавливаются успешно. Продолжайте проверку списков доступа до тех пор, пока все фильтры не будут разрешены, при том что клиент все еще будет иметь возможность подключаться к серверу
Маршруты не перерас пределя- ются должным образомМаршруты не перерас пределя- ются должным образомМаршрутизаторы не устанавливают связь со смежными маршрути-Маршрутизаторы не устанавливают связь со смежными маршрути-Перераспределение маршрутов между автономными системами IPX EIGRP, а также между EIGRP и другими протоколами маршрутизации по умолчанию не допускается. Поэтому необходимо вручную настроить конфигурацию перераспределения между различными автономными системами или протоколами маршрутизации.
Маршруты не перерас пределя- ются должным образом
Маршруты не перерас пределя- ются должным образом
Маршрутизаторы не устанавливают связь со смежными маршрути-
Маршрутизаторы не устанавливают связь со смежными маршрути-
Шаг 1. Вызовите на выполнение привилегированную exec-команду show running-config во всех маршрутизаторах, которые граничат с двумя автономными системами EIGRP. Найдите в конфигурации маршрутизатора IPX записи команды redistribute protocol.
Шаг 2. Если эта команда отсутствует, необходимо ввести соответствующую команду redistribute protocol, чтобы обеспечить перераспределение маршрутов между различными автономными системами или протоколами маршрутизации.
Для получения дополнительной информации о настройке перераспределения маршрутов обратитесь к документу Network Protocols Configuration Guide, Part I
Для получения дополнительной информации об устранении нарушений в работе, связанных с этой проблемой, обратитесь к следующему разделу, "IPX EIGRP: маршрутизатор не устанавливает связь со смежными маршрутизаторами"
заторами должным образом
Проблема
Решение
Обновления протокола SAP не распространяются маршрутизатором
Дополнительная информация об устранении нарушений в работе, связанных с этой проблемой, приведена ниже, в разделе “IPX EIGRP: обновления протокола SAP не распространяются маршрутизатором"
IPX EIGRP: маршрутизатор не устанавливает связь со смежными маршрутизаторами
Признак неисправности. Маршрутизаторы IPX EIGRP не устанавливают связь со смежными маршрутизаторами должным образом. В таблице смежных устройств не появляются маршрутизаторы, которые, как известно, подключены к сети.
Примечание
Процедуры устранения нарушений в работе протокола IPX EIGRP, не касающихся проблем установления связи со смежными устройствами, описаны выше, в разделе “IPX EIGRP: отсутствие связи через маршрутизатор EIGRP протокола IPX”.
В табл. 8.9 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 8.9. IPX EIGRP: маршрутизатор не устанавливает связь .- со смежными маршрутизаторами.
ПроблемаМаршрутизаторы находятся в разных автономных системахПроблемаМаршрутизаторы находятся в разных автономных системахПроизошло рассогласование таймера hello- сообщений или времени задержкиПроизошло рассогласование таймера hello- сообщений или времени задержкиРешение
Проблема
Маршрутизаторы находятся в разных автономных системах
Проблема
Маршрутизаторы находятся в разных автономных системах
Произошло рассогласование таймера hello- сообщений или времени задержки
Произошло рассогласование таймера hello- сообщений или времени задержки
Шаг 1. Маршрутизаторы, находящиеся в разных автономных системах, не считаются смежными, поэтому между ними не устанавливается связь как между смежными устройствами. Убедитесь в том, что маршрутизаторы, которые должны действовать как смежные устройства, находятся в одной и той же автономной системе.
Шаг 2. Воспользуйтесь привилегированной exec-командой show running-config для просмотра информации о конфигурации маршрутизатора. Проверьте записи команды ipx router eigrp, чтобы определить, к каким автономным системам относится данный маршрутизатор
Шаг 1. Вызовите на выполнение привилегированную exec-команду show running-config в каждом маршрутизаторе сети. Найдите записи команд конфигурации интерфейса ipx hello-interval eigrp и ipx hold-time eigrp.
Значения, введенные в конфигурацию с помошью этих команд, должны быть одинаковыми для всех маршрутизаторов IPX в сети.
Шаг 2. Если в каком-либо маршрутизаторе имеется иное значение hellointerval или hold-time, внесите изменения в конфигурацию этого маршрутизатора, чтобы она соответствовала конфигурациям всех остальных маршрутизаторов в сети.
Указанным установкам таймера можно снова присвоить значения, применяемые по умолчанию, с помощью команд конфигурации интерфейса no ipx hello-interval eigrp и по ipx hold-time interval eigrp
Проблема
Решение
Возникло нарушение в работе канала
Шаг 1. Воспользуйтесь привилегированной exec-командой show interfaces, чтобы проверить, переведен ли интерфейс в рабочее состояние и правильно ли он функционирует.
Ниже приведен пример вывода команды show interfaces.
Routerishow interface fastethernet 1/0
FastEthernetl/O is up, line protocol is up
Hardware is cyBus FastEthernet Interface, address is
0010.5498.d020 (bia 0010.
5498.d020)
Internet address is 210.84.3.33/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usee, rely
230/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec), hdx, lOOBaseTX/FX
Шаг 2. Воспользуйтесь привилегированной ехес-командой show ipx eigrp neighbors, чтобы проверить, все ли смежные устройства EIGRP показаны в таблице смежных устройств.
Шаг 3. Если в таблице смежных устройств указаны не все смежные устройства, то может иметь место нарушение в работе канала. Обратитесь к другим главам настоящей книги для получения информации об устранении нарушений в работе каналов конкретных типов
IPX EIGRP: обновления протокола SAP не распространяются маршрутизатором
Признак неисправности. Пакеты Novell SAP не перенаправляются через маршрутизатор, в котором функционирует программное обеспечение IPX EIGRP. Клиенты могут не иметь возможности подключаться к серверам через один или несколько маршрутизаторов либо могут подключаться только время от времени.
Примечание
Процедуры устранения нарушений в работе протокола IPX EIGRP, не касающиеся распространения обновлений SAP, описаны выше, в разделе “IPX EIGRP: отсутствие связи через маршрутизатор EIGRP протокола IPX”.
В табл. 8.10 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 8.10. IPX EIGRP: обновления протокола SAP
Проблема
не распространяются маршрутизатором
Решение
Фильтры SAP настроены неправильно
Шаг 1. Воспользуйтесь привилегированной exec-командой show access-lists в проверяемых маршрутизаторах, чтобы определить, выполнена ли в них настройка списков доступа Novell IPX. С помощью привилегированной exec-команды show running-config определите, есть ли такие фильтры SAP, в которых используется любой из списков доступа, входящих в конфигурацию. В конце данной главы приведен перечень пакетов SAP, соответствующих спецификациям Novell, в котором даны описания пакетов SAP, а также указаны шестнадцатеричные и десятичные значения.
Шаг 2. Если фильтры SAP введены в конфигурацию, отмените их, удалив соответствующим образом команды конфигурации интерфейса ipx input-sap-filter и ipx output-sap-filter (с использованием версий этих команд с префиксом по).
Шаг 3. Воспользуйтесь привилегированной exec-командой debug ipx sap activity, чтобы определить, успешно ли выполняется перенаправление трафика SAP. В результатах выполнения этой команды debug должны находиться данные об имени сервера, сетевом номере и МАС-адресе пакетов SAP.
Предостережение. При распределении процессорного времени процессу формирования отладочного вывода присваивается один из самых высоких приоритетов, поэтому система может стать непригодной для выполнения обычной работы. По этой причине команды debug должны применяться только для диагностики конкретных проблем или проведения сеансов поиска неисправностей с участием сотрудников службы технической поддержки Cisco. Кроме того, команды debug следует использовать в период сокращения сетевого трафика и уменьшения количества пользователей. Это снижает вероятность того, что дополнительные издержки, связанные с выполнением команды debug, нарушат нормальную эксплуатацию системы.
Шаг 4. Если перенаправление информации SAP выполняется маршрутизатором правильно, это означает, что уничтожение обновлений SAP маршрутизатором вызвано одним из фильтров SAP.
Шаг 5. Чтобы определить, какой именно фильтр SAP содержит ошибку, последовательно вводите по одному фильтру до тех пор, пока не будет прекращено перенаправление пакетов SAP маршрутизатором.
Шаг 6. Откорректируйте рассматриваемый список доступа, чтобы обеспечить прохождение через маршрутизатор трафика SAP, который должен быть перенаправлен. Убедитесь в том, что настройка конфигурации всех необходимых портов выполнена с применением явно заданного оператора permit.
Шаг 7. Продолжайте последовательно вводить в действие один фильтр за другим, проверяя, продолжает ли трафик SAP по-прежнему перенаправляться должным образом, до тех пор, пока не убедитесь в том, что конфигурации всех фильтров определены правильно
Проблема
Решение
Передаются инкрементные, а не полные обновления SAP
Нарушения связи могут возникать, если интерфейсы локальной сети настроены на передачу инкрементных (а нс полных) обновлений SAP по сегментам, к которым подключены клиенты или серверы Novell. Инкрементными называются обновления SAP, которые передаются нерегулярно, только при внесении изменений в таблицу SAP. Полные изменения передаются периодически.
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Найдите записи команды конфигурации интерфейса ipx sap- incremental eigrp в интерфейсах с подключенными клиентами или серверами Novell.
Шаг 2. Если эта команда входит в состав конфигурации и к рассматриваемому интерфейсу подключены клиенты или серверы Novell, необходимо отменить команду ipx sap-incremental eigrp. Указанная команда должна входить в состав конфигурации интерфейса, только если все узлы, подключенные к этому интерфейсу, представляют собой одноранговые устройства E1GRP
Возникло нарушение в работе канала
Шаг 1. Вызовите на выполнение привилегированную exec-команду show interfaces и найдите в результатах ее выполнения данные о количестве уничтоженных пакетов (в поле drops) и количестве случаев сброса интерфейса (в поле interface resets).
Ниже приведен пример вывода команды show interfaces.
Router#show interface fastethernet 1/0
FastEthernetl/O is up, line protocol is up
Hardware is cyBus FastEthernet Interface, address is
0010.5498.d020 (bia 0010. 5498.d020)
Internet address is 208.84.3.33/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usee, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec), hdx, lOOBaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:07, output 00:00:07, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
Шаг 2. Если количество уничтоженных пакетов и сбросов интерфейса велико, вызовите на выполнение привилегированную ехес-команду debug ipx sap activity и затем — привилегированную ехес-команду clear ipx eigrp neighbors.
ПроблемаРешение
Предостережение. При распределении процессорного времени процессу формирования отладочного вывода присваивается один из самых высоких приоритетов, поэтому система может стать непригодной для выполнения обычной работы. По этой причине команды debug должны применяться только для диагностики конкретных проблем или проведения сеансов поиска неисправностей с участием сотрудников службы технической поддержки Cisco. Кроме того, команды debug следует использовать в период сокращения сетевого трафика и уменьшения количества пользователей. Это снижает вероятность того, что дополнительные издержки, связанные с выполнением команды debug, нарушат нормальную эксплуатацию системы.
Если имеет место нарушение в работе канала, то команда debug ipx sap activity не выводит какие-либо результаты.
Шаг 3. Обратитесь к главе настоящей книги, где приведена информация об устранении нарушений в работе канала конкретного типа. Например, если возникло нарушение в работе последовательного канала, обратитесь к главе 15
IPX EIGRP: маршрутизатор не выходит из активного режима
Признак неисправности. Маршрутизатор IPX EIGRP не выходит из активного режима. Маршрутизатор неоднократно отправляет на консоль примерно такие сообщения об ошибках:
%DUAL-3-SIA: Route Зс.0800.ОсОО.4321 Stuck-in-Active
Примечание
Появление время от времени сообщений такого типа не должно служить причиной для беспокойства. Дело в том, что маршрутизатор Enhanced IGRP именно так дает знать о том, что он не получил ответы на свои запросы от всех своих смежных устройств. Но если эти сообщения об ошибках появляются часто, необходимо диагностировать описанную проблему.
Более подробно активный режим Enhanced IGRP описан ниже, в разделе “Активные/пассивные режимы Enhanced IGRP”.
В табл. 8.11 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
|^^пцца 8.11. IRXEIGRP: маршрутизатор не вы^активного режима: j
Нарушение в работе интерфейса или других аппаратных средствНарушение в работе интерфейса или других аппаратных средствПроблемаРешение
Нарушение в работе интерфейса или других аппаратных средств
Нарушение в работе интерфейса или других аппаратных средств
Неправильная настройка установки активного таймера
Шаг 1. Активный таймер определяет максимальную продолжительность времени, в течение которого маршрутизатор Enhanced IGRP должен ожидать ответов на свои запросы. Если для активного таймера определен слишком короткий тайм-аут, то может не хватить времени на то, чтобы все смежные маршрутизаторы передали свои ответы активному маршрутизатору. Настоятельно рекомендуется установить значение 3 (3 минуты — значение, предусмотренное по умолчанию), которое дает возможность всем смежным маршрутизаторам Enhanced IGRP ответить на запросы.
Шаг 2. Проверьте с помощью привилегированной exec-команды show running-config конфигурацию каждого маршрутизатора Enhanced IGRP. Найдите запись команды конфигурации маршрутизатора timers active-time.
Шаг 3. Значение, установленное командой timers active-time, должно быть одинаковым во всех маршрутизаторах одной и той же автономной системы. Настоятельно рекомендуется установить значение 3 (3 минуты — значение, предусмотренное по умолчанию), которое дает возможность всем смежным маршрутизаторам Enhanced IGRP ответить на запросы
Шаг 1. Вызовите на выполнение exec-команду show ipx eigrp neighbors и проверьте в результатах значения полей uptime (продолжительность работы) и Q Cnt (сокращение от queue count — количество сообщений в очереди). Ниже приведен пример вывода команды show ipx eigrp neighbors.
Router# show ipx eigrp neighbors
IPX EIGRP Neighbors for process 200
Н
Address
Interface
Hold (secs)
Uptime Q (h:m:s) Cnt
Seq
Num
SRTT (ms)
RTO (ms)
6
90.0000.0с02.096е
Tunnel44444
13
0:30:57 0
21
9
20
5
80.0000.0c02.34f2
FddiO
12
0:31:17 0
62
14
28
4
83.5500.2000.а83с
TokenRing2
13
0:32:36 0
626
16
32
3
98.0000.3040.а6Ь0
TokenRingl
12
0:32:37 0
43
9
20
2
80.0000.0c08.cbf9
FddiO
12
0:32:37 0
624
19
38
1
85.ааОО.0400.153с
Ethernet2
12
0:32:37 0
627
15
30
0
82.0000.0c03.4d4b
HssiO
12
0:32:38 0
629
12
24
Если счетчик рабочего времени постоянно переустанавливается
или
количество сообщений в очереди неизменно остается большим, такая ситуация может быть связана с нарушением в работе аппаратных средств.
Шаг 2. Проверьте наличие в результатах выполнения команды сообщения об ошибке "Stuck-in-Active". В выводе команды указано общее направление, в котором расположен узел, являющийся причиной неисправности, но если в этом направлении есть несколько узлов, то причиной нарушения в работе может оказаться любой из них.
ПроблемаПроблемаРешениеРешение
Проблема
Проблема
Решение
Решение
Происходит самопроизвольное изменение маршрутаПроисходит самопроизвольное изменение маршрутаШаг 3. Убедитесь в том, что маршрутизатор, который может служить причиной неисправностей, все еще находится в рабочем состоянии. Проверьте интерфейсы рассматриваемого маршрутизатора. Проверьте, находятся ли в рабочем состоянии интерфейс и протокол канала передачи данных, и определите, уничтожаются ли пакеты в этом интерфейсе. Для получения дополнительной информации об устранении нарушений в работе аппаратных средств см. главу 3
Происходит самопроизвольное изменение маршрута
Происходит самопроизвольное изменение маршрута
Шаг 1. С помощью привилегированной exec-команды show interfaces проверьте наличие самопроизвольного изменения последовательного маршрута (которое может быть вызвано слишком большим объемом трафика). Самопроизвольное изменение маршрута представляет собой одно из нарушений в работе средств маршрутизации, при котором объявленный маршрут между двумя узлами самопроизвольно переключается (перебрасывается) с одного пути на другой и обратно из-за какого-либо нарушения в работе сети, которое время от времени вызывает сбой в работе интерфейса. На наличие самопроизвольно изменяющегося маршрута указывают большие значения в полях resets и carrier transitions, которые представлены в выводе команды show interfaces.
Шаг 2. Если имеет место самопроизвольное изменение маршрута, то надежное перенаправление запросов и ответов может стать невозможным. При самопроизвольном изменении маршрута, которое вызвано превышением допустимого объема трафика в последовательном канале, может происходить потеря запросов и ответов, в результате чего по истечении установки активного таймера возникает тайм-аут. Примите меры по уменьшению объема трафика в канале или увеличению пропускной способности канала.
Для получения дополнительной информации об устранении нарушений в работе последовательных каналов обратитесь к главе 15
Активные/пассивные режимы Enhanced IGRP
Маршрутизатор Enhanced IGRP может находиться либо в пассивном, либо в активном режиме. Маршрутизатор называется пассивным по отношению к сети, если в его таблице маршрутизации установлен путь к этой сети. Маршрутизатор переходит в активное состояние, если возникает необходимость вычислить маршрут к сети. Но если в пути к требуемой сети всегда имеются смежные устройства, от которых маршрутизатор может получить необходимую информацию, он никогда не переходит в активное состояние и в нем не происходит повторное вычисление маршрута.
Если маршрутизатор Enhanced IGRP теряет соединение с какой-либо сетью, он становится активным по отношению к этой сети. Маршрутизатор рассылает запросы по всем своим смежным устройствам для поиска нового маршрута к сети. Маршрутизатор остается в активном режиме до тех пор, пока не получит ответы от всех своих смежных устройств или пока не истечет установка активного таймера, которая определяет максимальную продолжительность времени пребывания маршрутизатора в активном состоянии.
Если маршрутизатор получает ответы от всех своих смежных устройств, он вычисляет новое значение следующего участка маршрута к этой сети и становится пассивным по отношению к этой сети. Но если установка активного таймера истекает, маршрутизатор удаляет из своей таблицы смежных устройств все смежные устройства, не приславшие ответов, снова входит в активный режим и выдает на консоль сообщение "Stuck-in-Active".
Novell IPX: отсутствие надежной связи
Признак неисправности. Связь между клиентами и серверами является ненадежной. Клиенты в какой-то момент получают возможность подключаться к серверам, но в остальное время подключение к некоторым серверам или сетям становится невозможным.
В табл. 8.12 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 8.12. Novell IPX: отсутствие надежной связи .■<
Проблема
Решение
Возникло рассогласование установок таймера SAP
Шаг 1. Воспользуйтесь привилегированной схес-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Найдите в результатах выполнения этой команды записи команды конфигурации интерфейса ipx sap-interval.
Шаг 2. В интерфейсах локальной сети рекомендуется использовать предусмотренный по умолчанию интервал SAP, равный 1 минуте, поскольку интервал на серверах не может быть изменен. Для восстановления этого значения, предусмотренного по умолчанию, примените команду no ipx sap-interval.
Настраивая конфигурацию последовательных интерфейсов, следите за тем, чтобы в конфигурации на обоих концах последовательного канала были заданы одинаковые значения интервала. Для корректировки интервала SAP используйте команду конфигурации интерфейса ipx sap-interval
Возникло рассогласование установок таймера RIP
На серверах с операционной системой NetWare 4.x или более поздних версий могут быть изменены установки таймера RIP. При наличии рассогласований между установками таймера на маршрутизаторах и серверах могут возникать нарушения связи.
Шаг 1. Вызовите на выполнение привилегированную exec-команду show ipx interfaces в маршрутизаторе для просмотра состояния интерфейсов IPX. Найдите в результатах выполнения этой команды примерно такие строки:
C4500#show ipx interface
[...]
Updates each 60 seconds, aging multiples RIP: 3 SAP: 3 [...]
Сравните установки таймера конфигурации маршрутизатора с установками в конфигурациях серверов Novell.
Шаг 2. Установки таймера в составе конфигурации серверов и маршрутизаторов должны быть одинаковыми во всей сети IPX.
ПроблемаПроблемаРешениеРешениеПередаются инкрементные, а не полные обновления SAPПередаются инкрементные, а не полные обновления SAPСерверы Novell не обрабатывают обновления SAP так же быстро, как их генерирует маршрутизаторСерверы Novell не обрабатывают обновления SAP так же быстро, как их генерирует маршрутизаторОбновления SAP уничтожаются в выходной очереди центрального маршрутизатораОбновления SAP уничтожаются в выходной очереди центрального маршрутизатора
Проблема
Проблема
Решение
Решение
Передаются инкрементные, а не полные обновления SAP
Передаются инкрементные, а не полные обновления SAP
Серверы Novell не обрабатывают обновления SAP так же быстро, как их генерирует маршрутизатор
Серверы Novell не обрабатывают обновления SAP так же быстро, как их генерирует маршрутизатор
Обновления SAP уничтожаются в выходной очереди центрального маршрутизатора
Обновления SAP уничтожаются в выходной очереди центрального маршрутизатора
Внесите изменения в конфигурацию маршрутизатора или серверов, чтобы привести установки таймера в соответствие с указанным требованием. В маршрутизаторе для корректировки интервала таймера RIP воспользуйтесь командой конфигурации интерфейса ipx update-time.
Дополнительная информация о корректировке значения таймера в конфигурации серверов Novell содержится в документации сервера
В среде IPX EIGRP нарушения связи могут возникать, если интерфейсы локальной сети настроены на передачу инкрементных (а не полных) обновлений SAP по сегментам, к которым подключены клиенты или серверы Novell. Инкрементными называются обновления SAP, которые передаются нерегулярно, только при внесении изменений в таблицу SAP. Полные изменения передаются периодически.
Шаг 1. Воспользуйтесь привилегированной exec-командой show running-config для просмотра информации о конфигурации маршрутизатора. Найдите записи команды конфигурации интерфейса ipx sap-incremental eigrp в интерфейсах с подключенными клиентами или серверами Novell.
Шаг 2. Если в состав конфигурации входит команда sap-incremental и к рассматриваемому интерфейсу подключены клиенты или серверы Novell, необходимо отменить команду ipx sap-incremental eigrp с помощью версии этой команды с префиксом по. Указанная команда должна входить в состав конфигурации интерфейса, только если все узлы, подключенные к этому интерфейсу, представляют собой одноранговые устройства EIGRP
Шаг 1. Воспользуйтесь привилегированной exec-командой show interfaces, чтобы проверить наличие данных об уничтоженных выходных пакетах.
Шаг 2. Если число уничтоженных пакетов слишком велико, примените в маршрутизаторе exec-команду show ipx servers. Сравните вывод этой команды с выводом команды display servers, введенной с системной консоли на серверах Novell.
Шаг 3. Если результаты выполнения команды display servers на сервере Novell показывают только часть перечня записей SAP, отображаемых в маршрутизаторе, это может означать, что серверы Novell не способны обрабатывать обновления SAP с такой же скоростью, с какой они генерируются маршрутизатором.
Шаг 4. Воспользуйтесь командой конфигурации интерфейса ipx output-sap- delay для корректировки значения задержки между пакетами в многопакетном обновлении SAP. В документации Novell указано, что эта задержка составляет 55 мс
Применение низкоскоростных последовательных каналов может привести к тому, что маршрутизатор будет уничтожать пакеты SAP перед их передачей.
Шаг 1. Вызовите на выполнение exec-команду show interfaces serial и проверьте в ее результатах значение количества пакетов, уничтоженных в выходной очереди в поле output queue drops. Большое количество уничтоженных пакетов может указывать на то, что пакеты обновлений SAP уничтожаются еще до того, как появляется возможность передать их по последовательному каналу.
Проблема
Решение
Шаг 2. Вызовите на выполнение exec-команду show ipx servers в маршрутизаторе. Сравните вывод этой команды с выводом команды display servers, введенной с системной консоли серверов Novell.
Шаг 3. Если в результатах выполнения команды display servers на одном из серверов Novell показана только Часть перечня записей SAP, представленных в маршрутизаторе, это может означать, что маршрутизатор уничтожает пакеты SAP в выходной очереди.
Шаг 4. Отмените перенаправление всех обновлений SAP, кроме абсолютно необходимых. Выполните настройку фильтров, используя команды конфигурации интерфейса ipx input-sap-filter, ipx output-sap- filter и ipx router-sap-filter соответствующим образом.
Шаг 5. Увеличение длины выходной резервной очереди в последовательном интерфейсе также может способствовать повышению производительности. Примените команду конфигурации интерфейса hold-queue length out для увеличения длины выходной очереди. По умолчанию предельная длина выходной очереди составляет 100 пакетов. При использовании команды hold-queue необходимо руководствоваться следующими правилами: для низкоскоростных каналов следует применять небольшое значение предела длины выходной очереди. Такой подход позволяет предотвратить постановку пакетов в очередь со скоростью, превышающей пропускную способность канала. С другой стороны, для высокоскоростных каналов следует применять более высокое значение предела длины выходной очереди. Высокоскоростной канал может быть занят в течение короткого времени (и поэтому для него требуется резервная очередь), но после возобновления возможности передачи он может быстро опустошить выходную очередь.
Шаг 6. Если применение фильтров SAP и увеличение длины очереди не позволяет устранить указанное нарушение в работе, то следует увеличить доступную пропускную способность, если это возможно. Введите в действие еше один последовательный канал или получите один канал с большей пропускной способностью
Маршрутизатор не выходит из активного режима (только маршрутизаторы EIGRP)
Если маршрутизатор регулярно выводит сообщение "Stuck-in-Active", касающееся конкретной сети, то, вероятно, имеет место самопроизвольное изменение маршрута (причиной которого обычно является большой объем трафика).
Самопроизвольное изменение маршрута выражается в том, что маршруты появляются в таблице маршрутизации, а затем внезапно исчезают, в результате чего связь с некоторыми сетями становится неустойчивой.
Примите меры по уменьшению объема трафика в канале или увеличению пропускной способности канала.
Для получения дополнительной информации об устранении нарушений в работе последовательных каналов обратитесь к главе 15
Серверы Novell не обрабатывают обновления SAP так же быстро, как их генерирует маршрутизаторСерверы Novell не обрабатывают обновления SAP так же быстро, как их генерирует маршрутизаторДля передачи периодических обновлений SAP используется слишком большая часть пропускной способностиДля передачи периодических обновлений SAP используется слишком большая часть пропускной способностиВ одном и том же интерфейсе разрешено применение протоколов IPX RIP и IPX EIGRPВ одном и том же интерфейсе разрешено применение протоколов IPX RIP и IPX EIGRP
Серверы Novell не обрабатывают обновления SAP так же быстро, как их генерирует маршрутизатор
Серверы Novell не обрабатывают обновления SAP так же быстро, как их генерирует маршрутизатор
Для передачи периодических обновлений SAP используется слишком большая часть пропускной способности
Для передачи периодических обновлений SAP используется слишком большая часть пропускной способности
В одном и том же интерфейсе разрешено применение протоколов IPX RIP и IPX EIGRP
В одном и том же интерфейсе разрешено применение протоколов IPX RIP и IPX EIGRP
Novell IPX: низкая производительность
Признак неисправности. Наблюдается низкая производительность сети Novell IPX.
В табл. 8.13 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
' Таблица 8.13. Novell IPX: низкая производительность
РешениеРешениеПроблема
Решение
Решение
Шаг 1. Воспользуйтесь привилегированной exec-командой show interfaces, чтобы проверить наличие данных об уничтоженных выходных пакетах.
Шаг 2. Если число уничтоженных пакетов слишком велико, примените в маршрутизаторе exec-команду show ipx servers. Сравните вывод этой команды с выводом команды display servers, введенной с системной консоли на серверах Novell.
Шаг 3. Если результаты выполнения команды display servers на сервере Novell показывают только часть перечня записей SAP, отображаемых в маршрутизаторе, это может означать, что серверы Novell не способны обрабатывать обновления SAP с такой же скоростью, с какой они генерируются маршрутизатором.
Шаг 4. Воспользуйтесь командой конфигурации интерфейса ipx outputsap-delay для корректировки значения задержки между пакетами в многопакетном обновлении SAP. В документации Novell указано, что эта задержка составляет 55 мс
В сетевой среде, не предусматривающей применения протокола IPX RIP (например, в последовательном канале, работающем под управлением протокола EIGRP), можно уменьшить объем трафика SAP, выполнив настройку конфигурации маршрутизаторов на передачу по мере необходимости инкрементных обновлений SAP, а не на периодическую передачу полных обновлений SAP. Инкрементные обновления SAP передаются, только если в таблице SAP происходят изменения.
Инкрементные обновления SAP могут быть разрешены только в интерфейсах, к которым не подключены клиенты или серверы Novell. Для клиентов и серверов Novell требуются периодические обновления SAP.
Воспользуйтесь командой конфигурации интерфейса ipx sap-incremental eigrp, чтобы разрешить применение инкрементных обновлений SAP
В сети IPX иногда желательна или необходима эксплуатация и протокола IPX EIGRP, и протокола IPX RIP в одном и том же интерфейсе. Но в отдельных случаях применение в одном интерфейсе сразу двух протоколов маршрутизации может привести к снижению производительности, поскольку при этом создается дополнительный трафик и увеличивается нагрузка процессора.
Шаг 1. Вызовите на выполнение привилегированную exec-команду show running-config для просмотра информации о конфигурации маршрутизатора. Проверьте команды конфигурации сетевого маршрутизатора, связанные с глобальными командами конфигурации ipx router rip и ipx router eigrp, чтобы узнать, разрешено ли применение обоих протоколов маршрутизации в одном и том же интерфейсе.
Проблема
Решение
Шаг 2. Если разрешены оба протокола, определите, можно ли запретить один из них, не нарушая нормального функционирования сети. Если нет необходимости эксплуатировать оба протокола маршрутизации в одном и том же интерфейсе, удалите соответствующим образом лишние команды конфигурации
Маршрутизатор не выходит из активного режима (только маршрутизаторы EIGRP)
Если маршрутизатор регулярно выводит сообщение "Stuck-in-Active”, касающееся конкретной сети, то, вероятно, имеет место самопроизвольное изменение маршрута (причиной которого обычно является большой объем трафика).
Самопроизвольное изменение маршрута может привести к тому, что маршрутизаторы начинают использовать менее оптимальный маршрут, в результате чего производительность сети снижается.
Примите меры по уменьшению объема трафика в канале или увеличению пропускной способности канала.
Для получения дополнительной информации об устранении нарушений в работе последовательных каналов обратитесь к главе 15
Пакеты SAP корпорации Novell
В табл. 8.14 приведен перечень пакетов SAP корпорации Novell, составленный по неподтвержденным материалам из различных источников. Ни одна часть этой информации не представлена официально корпорацией Novell.
! Таблица 8.14. Пакеты SAP корпорации Novell, их описания, десятичные ;и шестнадцатеричные значения .: /
Десятичное значение
Шестнадцатеричное значение
Описание пакета SAP
0
0000
Назначение неизвестно
1
0001
Пользователь
2
0002
Группа пользователей
3
0003
Очередь печати или группа печати
4
0004
Файловый сервер (отправитель сообщений SLIST)
5
0005
Сервер заданий
6
0006
Шлюз
7
0007
Обычный сервер печати или сервер печати, не передающий сообщений
8
0008
Очередь архива
9
0009
Сервер архива
10
000А
Очередь заданий
И
000В
Администрирование
15
000F
Novell TI-RPC
23
0017
Диагностика
32
0020
NetBIOS
33
0021
Шлюз NAS SNA
35
0023
Асинхронный шлюз NACS (или шлюз Async)
Десятичное значение
Шестнадцатеричное значение
Описание пакета SAP
36
0024
Удаленный мост или служба маршрутизации
38
0026
Сервер моста или асинхронный сервер моста
39
0027
Шлюз TCP/IP
40
0028
Двухточечный сервер моста Х.25 (Eicon)
41
0029
Шлюз Eicon 3270
42
002А
CHI Corp
44
002С
Классная доска PC
45
0020
Сервер синхронизации времени или асинхронный
таймер
46
002Е
ARCserve 5.0/Palindrome Backup Director 4.x (PDB4)
69
0045
Шлюз DI 3270
71
0047
Сервер печати с рассылкой извешений об услугах
74
00 4А
Модемы NetBlazer
75
004В
Btrieve VAP/NLM 5.0
76
004С
Сервер VAP/NLM Netware SQL
77
004D
Программное обеспечение Netware XTree версии Xtree
Network
80
0050
Btrieve VAP 4.11
82
0052
QuickLink (Cubix)
83
0053
Пользователь очереди печати
88
0058
Многоточечный маршрутизатор Х.25 Eicon
96
0060
STLB/NLM
100
0064
ARCserve
102
0066
ARCserve 3.0
114
0072
Утилита копирования в распределенной сети
122
007А
TES-Netware для VMS
146
0092
Отладчик WATCOM или сервер резервного копирова-
ния на магнитную ленту Emerald
149
0095
DDA OBGYN
152
0098
Сервер доступа Netware (асинхронный шлюз)
154
009А
Сервер Netware для VMS II или сервер именованного
канала
155
009В
Сервер доступа Netware
158
009Е
Мультиплатформенный сервер Netware или SunUnk NVT
161
00А1
Powerchute АРС UPS NLM
170
00AA
LAWserve
172
00 АС
Compaq IDA Status Monitor
256
0100
PIPE STAIL
258
0102
LAN Protect Bindery
259
0103
Сервер базы данных Oracle
263
0107
Netware 386 или удаленный терминал RSPX
271
010F
Шлюз Novell SNA
273
0111
Проверочный сервер
Десятичное значение
Шестнадцатеричное значение
Описание пакета SAP
274
0112
Сервер печати (HP)
276
0114
CSA MUX (f/Communications Executive)
277
0115
CSA LCA (f/Communications Executive)
278
0116
CSA CM (f/Communications Executive)
279
0117
CSA SMA (f/Communications Executive)
280
0118
CSA DBA (f/Communications Executive)
281
0119
CSA NMA (f/Communications Executive)
282
ОНА
CSA SSA (f/Communications Executive)
283
011В
CSA STATUS (f/Communications Executive)
286
011Е
CSA APPC (f/Communications Executive)
294
0126
Профиль SNA TEST SSA
298
012А
CSA TRACE (f/Communications Executive)
299
012В
Netware для SAA
301
012Е
Антивирусная утилита IKARUS
304
0130
Исполнительный модуль связи
307
0133
Сервер домена NNS или домен службы имен Netware
309
0135
Профиль службы имен Netware
311
0137
Очередь печати Netware 386 или очередь печати NNS
321
0141
Сервер буферного каталога локальной сети (Vap, Intel)
338
0152
Шлюз I RM ALAN
340
0154
Сервер именованного канала
358
0166
Система управления NetWare
360
0168
Сервер связи Intel PICKIT или сервер обмена данными Intel CAS
369
0171
Назначение неизвестно
371
0173
Compaq
372
0174
Агент Compaq SNMP
373
0175
Compaq
384
0180
Сервер ХТгее или инструментальные средства ХТгее
394
018А
Назначение неизвестно. Применяется на сервере Novell
432
01В0
Шлюз GARP (обследование сети)
433
01В1
Binfview (группа поддержки локальной сети)
447
01BF
Intel LanDesk Manager
458
01СА
АХТЕС
459
01СВ
Shiva NetModem/E
460
01СС
Shiva LanRover/E
461
01CD
Shiva LanRover/T
472
0108
Сервер Castelle FAXPress
474
01DA
Сервер печати Castelie LANPress
476
01DC
Castelie FAX/Факсимильный сервер Xerox 7033/Excel Lan Fax
496
01F0
LEGATO
501
01F5
LEGATO
Десятичное значение
Шестнадцатеричное значение
Описание пакета SAP
563
0233
Агент NMS или агент управления Netware
567
0237
Протокол обнаружения NMS IPX или канал чтения- записи LANtern
568
0238
Протокол обнаружения NMS IP или канал прерыва- ний/предупреждений LANtern
570
023А
LABtern
572
023С
MAVERICK
574
023Е
Назначение неизвестно. Применяется на сервере Novell
575
023F
Используется 11 различными серверами Novell/SMDR (Storage Management Data Requester — программа запроса данных для управления запоминающими устройствами) Novell
590
024Е
Соединение NetWare
618
026А
Консоль службы управления сетью (NMS — Network Management Service)
619
026В
Сервер синхронизации времени (Netware 4.x)
632
0278
Сервер каталогов (Netware 4.x)
989
03DD
Модуль NLM Banyan ENS для клиента Netware
772
0304
Шлюз Novell SAA
776
0308
СОМ или VERMED 1
778
030А
Сервер Worldgroup корпорации Galacticomm
780
030С
Intel Netport 2, HP JetDirect или HP Quicksilver
800
0320
Шлюз Attachmate
807
0327
Диагностика Microsoft
808
0328
Сервер SQL WATCOM
821
0335
Сервер связи Multisynch корпорации MultiTech Systems
835
2101
Система Instant Internet корпорации Performance Technology
853
0355
Исполнительный модуль системы резервного копирования Arcada
858
0358
MSLCD1
865
0361
NETINELO
894
037Е
Двенадцать файловых серверов Novell семейства РСЗМ
895
037F
ViruSafe Notify
902
0386
Мост HP
903
0387
Концентратор HP
916
0394
Шлюз NetWare SAA
923
039В
Lotus Notes
951
03В7
Certus Anti Virus NLM
964
03С4
ARCserve 4.0 (Cheyenne)
967
03С7
LANspool 3.5 (Intel)
983
03D7
Сервер печати Lexmark (типа 4ОЗЗ-О11)
984
0308
Сервер печати Lexmark XLE (типа 4033-301)
990
03DE
Сервер Gupta Sequel Base или NetWare SQL
Десятичное значение
Шестнадцатеричное значение
Описание пакета SAP
993
03Е1
Univel UnixWare
996
03Е4
Univel UnixWare
1020
03FC
Intel Netport
1021
03FD
Очередь сервера печати
1196
04 АС
Модуль NUM On-Time Scheduler
1034
040А
ipnServer. Применяется на сервере Novell
1035
040В
Назначение неизвестно
1037
040D
LVERRMAN. Применяется на сервере Novell
1038
040Е
LVL1C. Применяется на сервере Novell
1040
0410
Назначение неизвестно. Применяется на сервере Novell
1044
0414
Kyocera
1065
0429
Site Lock Virus (Brightworks)
1074
0432
UFHELP R
1075
0433
Усовершенствованный агент SNMP Synoptics 281x
1092
0444
Сервер SNA Microsoft NT
1096
0448
Oracle
1100
044С'
ARCserve 5.01
1111
0457
Canon GP55. Применяется на сетевом принтере
Canon GP55
1114
045А
QMS Printers
1115
045В
Монитор Dell SCSI Array (DSA)
1169
0491
Модемы NetBlazer
1200
04В0
CD-Net (Meridian)
1217
04С1
Назначение неизвестно
1299
0513
Emulux NQA. Какое-то программное обеспечение корпорации Emulex
1312
0520
Проверка блокировки узла
1321
0529
Проверка блокировки узла (Brightworks)
1325
052D
Сервер приложений Citrix OS/2
1343
0535
Tektronix
1344
0536
Milan
1387
056В
Сервер модема IBM 8235
1388
056С
Shiva LanRover/E PLUS
1389
0560
Shiva LanRover/T PLUS
1408
0580
Антивирусная программа NetShield корпорации McAfee
1466
05В А
Маршрутизаторы Compatible Systems
1569
0621
IBM AntiVirus NLM
1571
0623
Назначение неизвестно. Применяется на сервере Novell
1900
076С
Xerox
1947
079В
Shiva LanRover/E 115
1958
079С
Shiva LanRover/T 115
2154
086А
Модули NLM ISSC collector
2175
087F
Агент ISSC DAS для AIX
Десятичное значение
Шестнадцатеричное значение
Описание пакета SAP
2857
0В29
Site Lock
3113
0С29
Приложения Site Lock
3116
0С2С
Сервер лицензирования
9088
2380
LAI Site Lock
9100
238С
Meeting Maker
18440
4808
Сервер Site Lock или VAP/NLM Site Lock Metering
21845
5555
Пользователь Site Lock
25362
6312
Tapeware
28416
6F00
Rabbit Gateway (3270)
30467
7703
MODEM
32770
8002
Принтеры NetPort (Intel) или LANport
32776
8008
Сетевая версия WordPerfect
34238
85ВЕ
Протокол EIGRP корпорации Cisco
34952
8888
Сетевая версия WordPerfect или средства ускоренного управления сетью
36864
9000
Антивирусная программа NetShield корпорации McAfee
38404
9604
CSA-NT_MON
46760
В6А8
Средства дистанционного управления Ocean Isle Reachout
61727
F11F
VAP/NLM Site Lock Metering
61951
F1FF
Site Lock
62723
F503
SCA-NT
64507
FBFB
Факсимильный сервер TopCall III
65535
FFFF
Любая служба или групповой символ
Глава
9
« Устранение нарушений j в работе сети AppleTalk
В начале 1980-х годов, когда Apple Computer готовилась представить на рынке компьютер Macintosh, специалисты этой корпорации предвидели, что требования ^*по обеспечению сетевого взаимодействия вскоре станут исключительно важными. Они стремились обеспечить возможность создания сетей на основе компьютеров । Macintosh, которые могли бы идеально дополнить новаторский пользовательский | интерфейс Macintosh? Стремясь к достижению этих двух целей, специалисты кор- «.порации Apple решили встроить сетевой интерфейс в каждый компьютер ' Macintosh и интегрировать этот интерфейс со средой рабочего стола. Новая сетевая архитектура и протоколы Apple получили название AppleTalk.
^ .■•‘ Все права на разработку в области архитектуры AppleTalk принадлежат корпорации Apple, но ее руководство приняло решение опубликовать спецификации AppleTalk, надеясь тем самым привлечь интерес независимых разработчиков. И действительно, в настоящее время многие компании, в том числе Novell и Microsoft, успешно поставляют на рынок свои продукты, основанные на спецификациях AppleTalk.
Йервая реализация спецификаций AppleTalk, предназначенная для локальных рабочих групп, теперь сменилась новой, поэтому в отличие от нее именуется спе- Я^ификациями AppleTalk версии 1. В течение первых пяти лет с момента выпуска продуктов на основе этйх спецификаций в мире было установлено свыше 1,5 миллиона компьютеров Macintosh с сетевой поддержкой. Тем не менее специалисты корпорации* Apple обнаружили, что ограничения, заложенные в спецификациях AppleTalk?версии I, не позволяют удовлетворить требования некоторых крупных корпораций, поэтому провели доработку спецификаций этого сетевого протокола. ^•■..Усовершенствованный протокол, получивший название AppleTalk версии 2, расширил возможности маршрутизации в сети AppleTalk и позволил обеспечить успешное применение архитектуры AppleTalk в более крупных сетях.
Основы технологии AppleTalk
Архитектура AppleTalk была разработана на основе распределенной сетевой системы типа клиент/сервер. Иными словами, эта архитектура обеспечивает совместный доступ пользователей к сетевым ресурсам (таким как файлы и принтеры). Программы, предоставляющие эти сетевые ресурсы, называются серверами, а программы, позволяющие обращаться к сетевым ресурсам сервера, — клиентами. Все действия, необходимые для обеспечения взаимодействия клиентов с серверами, фактически незаметны для пользователя, поскольку клиентская программа сама определяет местонахождение затребованных пользователем ресурсов и обращается к ним, не требуя дополнительных указаний от пользователя. Такие распределенные системы не только являются весьма удобными в использовании, но и предоставляют значительные экономические преимущества над одноранговыми системами, поскольку позволяют сосредоточить общедоступные ресурсы в одном месте, а не тиражировать их по разным компьютерам.
На рис. 9.1 показано соответствие между протоколами AppleTalk и уровнями эталонной модели OSI.
Доступ к передающей среде
Специалисты корпорации Apple разработали протоколы AppleTalk с учетом требований обеспечения независимости от канального уровня. Иными словами, эти протоколы могут применяться на основе любой реализации протоколов канального уровня. Корпорация Apple предусмотрела поддержку самых различных реализаций канального уровня, включая Ethernet, Token Ring, FDDI и LocalTalk. В корпорации Apple принято называть сеть AppleTalk на основе Ethernet сетью EtherTalk, сеть AppleTalk на основе Token Ring — сетью TokenTalk, а сеть AppleTalk на основе FDDI — сетью FDDITalk. Для обеспечения обмена данными по этим передающим средам применяются такие протоколы канального уровня, поддерживающие сеть AppleTalk, как ELAP (EtherTalk Link Access Protocol — протокол канального доступа в сети EtherTalk), LLAP (LocalTalk Link Access Protocol — протокол канального доступа в сети LocalTalk), TLAP (TokenTalk Link Access Protocol — протокол канального доступа в сети TokenTalk) и FLAP (FDDITalk Link Access Protocol — протокол канального доступа в сети FDDITalk). LocalTalk представляет собой систему доступа к передающей среде, все права на которую принадлежат корпорации Apple. Она основана на конкурентном доступе, шинной топологии и узкополосной передаче сигналов и функционирует в передающей среде на базе экранированной витой пары на скорости 230,4 Кбит/с. Применяемый физический интерфейс соответствует спецификации EIA/TIA-422 (прежнее название — RS-422), а сбалансированный электрический интерфейс соответствует спецификации EIA/TIA-449 (прежнее название — RS-449). Сегменты сети LocalTalk могут иметь длину до 300 метров и поддерживать до 32 узлов.
Эталонная модель OSIЭталонная модель OSIПротоколы AppleTalkПротоколы AppleTalk7 Прикладной7 Прикладной6 Представительский6 ПредставительскийФайловый протокол-PostScriptAppleTalk (AFP)Файловый протокол-PostScriptAppleTalk (AFP)5 Сеансовый5 СеансовыйПротокол потоковойпередачи данныхAppleTalk (ADSP)Протокол потоковойпередачи данныхAppleTalk (ADSP)Протокол зонельной информации (ZIP)Протокол зонельной информации (ZIP)Сеансовый протоколAppleTalk (ASP)Сеансовый протоколAppleTalk (ASP)Протокол доступа к принтеру(РАР)Протокол доступа к принтеру(РАР)4 Транспортный4 ТранспортныйПротокол обслуживания таблиц маршрутизации (RTMP)Протокол маршрутизации на основе обновлений AppleTalk (AURP)Эхо-протокол AppleTalk (АЕР)Протокол передачи AppleTalk (АТР)Протокол привязки имен(МВР)Протокол обслуживания таблиц маршрутизации (RTMP)Протокол маршрутизации на основе обновлений AppleTalk (AURP)Эхо-протокол AppleTalk (АЕР)Протокол передачи AppleTalk (АТР)Протокол привязки имен(МВР)Протокол доставки дейтаграмм (DDP)Протокол доставки дейтаграмм (DDP)3 Сетевой3 Сетевой
Эталонная модель OSI
Эталонная модель OSI
Протоколы AppleTalk
Протоколы AppleTalk
7 Прикладной
7 Прикладной
6 Представительский
6 Представительский
Файловый протокол
-
PostScript
AppleTalk (AFP)
Файловый протокол
-
PostScript
AppleTalk (AFP)
5 Сеансовый
5 Сеансовый
Протокол потоковойпередачи данныхAppleTalk (ADSP)
Протокол потоковойпередачи данныхAppleTalk (ADSP)
Протокол зонельной информации (ZIP)
Протокол зонельной информации (ZIP)
Сеансовый протоколAppleTalk (ASP)
Сеансовый протоколAppleTalk (ASP)
Протокол доступа к принтеру(РАР)
Протокол доступа к принтеру(РАР)
4 Транспортный
4 Транспортный
Протокол обслуживания таблиц маршрутизации (RTMP)
Протокол маршрутизации на основе обновлений AppleTalk (AURP)
Эхо-протокол AppleTalk (АЕР)
Протокол передачи AppleTalk (АТР)
Протокол привязки имен(МВР)
Протокол обслуживания таблиц маршрутизации (RTMP)
Протокол маршрутизации на основе обновлений AppleTalk (AURP)
Эхо-протокол AppleTalk (АЕР)
Протокол передачи AppleTalk (АТР)
Протокол привязки имен(МВР)
Протокол доставки дейтаграмм (DDP)
Протокол доставки дейтаграмм (DDP)
3 Сетевой
3 Сетевой
Протокол преобразования адресов (ARP)
2 Канальный2 КанальныйПротокол доступак канвлу связиEtherTalk (ELAP)Протокол доступак канвлу связиEtherTalk (ELAP)Протокол доступак канелу связиLocalTalk(LLAP)Протокол доступак канелу связиLocalTalk(LLAP)Протокол доступак каналу связиTokenTalk (TLAP)Протокол доступак каналу связиTokenTalk (TLAP)Протокол доступак каналу связиFDDITalk(FLAP)Протокол доступак каналу связиFDDITalk(FLAP)
2 Канальный
2 Канальный
Протокол доступак канвлу связиEtherTalk (ELAP)
Протокол доступак канвлу связиEtherTalk (ELAP)
Протокол доступак канелу связиLocalTalk(LLAP)
Протокол доступак канелу связиLocalTalk(LLAP)
Протокол доступак каналу связиTokenTalk (TLAP)
Протокол доступак каналу связиTokenTalk (TLAP)
Протокол доступак каналу связиFDDITalk(FLAP)
Протокол доступак каналу связиFDDITalk(FLAP)
1 Физический1 ФизическийАппаратные средства LocalTalkАппаратные средства TokenTalkАппаратные средства FDDIАппаратные средства LocalTalkАппаратные средства TokenTalkАппаратные средства FDDIАппаратные средства EthernetАппаратные средства Ethernet
1 Физический
1 Физический
Аппаратные средства LocalTalk
Аппаратные средства TokenTalk
Аппаратные средства FDDI
Аппаратные средства LocalTalk
Аппаратные средства TokenTalk
Аппаратные средства FDDI
Аппаратные средства Ethernet
Аппаратные средства Ethernet
Рис. 9.1. Соответствие между протоколами AppleTalk и уровнями эталонной модели OS1
Сетевой уровень
В настоящем разделе рассматриваются основные понятия и протоколы сетевого уровня AppleTalk. В нем описан процесс присваивания протокольных адресов, а также применения сетевых объектов и протоколов AppleTalk, предоставляющих функциональные средства уровня 3 эталонной модели OSI.
Присваивание протокольного адреса
В сети AppleTalk адреса присваиваются узлам автоматически, что позволяет свести к минимуму объем работы, выполняемой сетевым администратором. При запуске компьютера Macintosh с установленным на нем программным обеспечением AppleTalk автоматически выбирается протокольный адрес (адрес сетевого уровня) и проверяется, применяется ли этот адрес в настоящее время. Если адрес не применяется, то вновь активизированный узел успешно присваивает себе этот адрес, а если адрес в настоящее время уже используется, то узел с конфликтующим адресом передает сообщение, указывающее на то, что возникла ошибка, на активизированном узле выбирается другой адрес и процесс повторяется. Схема процесса выбора адреса в сети AppleTalk показана на рис. 9.2.
Применяемые механизмы выбора адреса в сети AppleTalk зависят от передающей среды. Для привязки адресов AppleTalk к конкретным адресам передающей среды используется протокол AARP (AppleTalk Address Resolution Protocol — протокол преобразования адресов AppleTalk). Протокол AARP обеспечивает также согласование других протокольных адресов с аппаратными адресами. При возникновении необходимости передать на другой сетевой узел пакет, сформированный протоколами AppleTalk или протоколами любого другого стека протоколов, протокольный адрес пакета передается программному обеспечению AARP. Программное обеспечение AARP сначала выполняет поиск в кэше адресов, чтобы определить, известна ли уже взаимосвязь между этим протокольным и конкретным аппаратным адресом. Если известен аппаратный адрес, соответствующий протокольному адресу, то эти сведения передаются в запросивший их стек протокола. А если такие сведения отсутствуют, то программное обеспечение AARP рассылает широковещательное или многоадресатное сообщение с запросом на получение аппаратного адреса, соответствующего рассматриваемому протокольному адресу. После того как широковещательное сообщение достигает узла с указанным протокольным адресом, этот узел передает в ответ свой аппаратный адрес. Полученная информация передается в запросивший ее стек протоколов, в котором этот аппаратный адрес в дальнейшем применяется для обмена данными с соответствующим узлом.
Сетевые объекты
В сети AppleTalk для классификации сетевых устройств применяется понятие сетевого объекта. Одним из самых простейших сетевых объектов является узел; узлом называется любое устройство, подключенное к сети AppleTalk. К числу наиболее распространенных типов узлов относятся компьютеры Macintosh и лазерные принтеры, но во взаимодействии по сети AppleTalk могут также участвовать компьютеры многих других типов, в том числе персональные компьютеры корпорации IBM, компьютеры VAX корпорации Digital Equipment Corporation и различные рабочие станции. Еще одним объектом, который определен в технологии AppleTalk, является сама сеть. Сеть AppleTalk представляет собой просто отдельный логический кабель. Чаще всего логический кабель формируется на основе одного физического кабеля, но в некоторых вычислительных центрах для соединения нескольких физических кабелей применяются мосты.
MacintoshMacintoshРис. 9.2. Процесс выбора адреса в сети AppleTalkРис. 9.2. Процесс выбора адреса в сети AppleTalk
Macintosh
Macintosh
Рис. 9.2. Процесс выбора адреса в сети AppleTalk
Рис. 9.2. Процесс выбора адреса в сети AppleTalk
И, наконец, одним из объектов AppleTalk является зона — логическая группа сетей (возможно, состоящая из нескольких несмежных участков). Эти объекты AppleTalk показаны на рис. 9.3.
Рис. 9.3. Объекты AppleTalk
Протокол доставки дейтаграмм
Основным протоколом сетевого уровня AppleTalk является DDP (Datagram Delivery Protocol — протокол доставки дейтаграмм). Протокол DDP предоставляет доступ к службе обмена дейтаграммами между сетевыми сокетами без установления логического соединения. Сокеты могут присваиваться статически или динамически.
Протокол DDP обеспечивает также управление сетевыми адресами AppleTalk, которые состоят из двух компонентов: 16-битового сетевого номера и 8-битового номера узла. Эти два компонента обычно записываются в виде десятичных чисел, разделенных точкой (например, 10.1 означает сеть 10, узел 1). Для обозначения уникального вычислительного процесса в сети к сетевому номеру и номеру узла добавляется 8-битовый номер сокета, обозначающий данный конкретный процесс.
В версии 2 спецификаций AppleTalk проводится различие между нерасширенными и расширенными сетями. В нерасширенной сети, такой как LocalTalk, каждый номер узла AppleTalk является уникальным. В спецификациях AppleTalk версии 1 был определен единственный тип сети — нерасширенные сети. В расширенной сети, такой как EtherTalk и TokenTalk, уникальной является каждая комбинация сетевого номе- ра/номера узла.
Зоны определяются сетевым администратором AppleTalk в процессе настройки конфигурации маршрутизатора. Каждый узел в сети AppleTalk принадлежит к одной конкретной зоне, а с расширенными сетями может быть связано несколько зон. Узлы в расширенных сетях могут принадлежать к любой отдельной зоне, связанной с расширенной сетью.
Транспортный уровень
Транспортный уровень AppleTalk реализуется с помощью нескольких протоколов: RTMP (Routing Table Maintenance Protocol — протокол сопровождения таблиц маршрутизации), AURP (AppleTalk Update-Based Routing Protocol — протокол маршрутизации AppleTalk на базе обновлений), АЕР (AppleTalk Echo Protocol — эхо-прото кол AppleTalk) , ATP (AppleTalk Transaction Protocol — протокол транзакций AppleTalk) и NBP (Name Binding Protocol — протокол привязки имен).
Протокол RTMP
Протокол RTMP применяется для формирования и сопровождения таблиц маршрутизации AppleTalk. Таблицы маршрутизации RTMP содержат по одной записи для каждой сети, в которую могут передаваться дейтаграммы. Каждая запись включает обозначение порта маршрутизатора, который ведет к сети назначения, идентификатор узла следующего маршрутизатора, который должен получить пакет, расстояние до сети назначения, выраженное в виде количества участков маршрута, и оценку текущего состояния данной записи (good — исправная, suspect — сомнительная или bad — неисправная). Маршрутизаторы в объединенной сети периодически обмениваются данными таблиц маршрутизации, что позволяет гарантировать наличие в этих таблицах актуальной и непротиворечивой информации. На рис. 9.4 показан пример таблицы RTMP и представлена схема соответствующей сетевой архитектуры.
СетьРасстояниеПортСледующий маршрутизаторСостояние записи1010Хорошее2020Хорошее3132Хорошее4232ХорошееСетьРасстояниеПортСледующий маршрутизаторСостояние записи1010Хорошее2020Хорошее3132Хорошее4232ХорошееРис, 9.4. Пример таблицы маршрутизации AppleTalkРис, 9.4. Пример таблицы маршрутизации AppleTalk
Сеть
Расстояние
Порт
Следующий маршрутизатор
Состояние записи
1
0
1
0
Хорошее
2
0
2
0
Хорошее
3
1
3
2
Хорошее
4
2
3
2
Хорошее
Сеть
Расстояние
Порт
Следующий маршрутизатор
Состояние записи
1
0
1
0
Хорошее
2
0
2
0
Хорошее
3
1
3
2
Хорошее
4
2
3
2
Хорошее
Рис, 9.4. Пример таблицы маршрутизации AppleTalk
Рис, 9.4. Пример таблицы маршрутизации AppleTalk
Протокол NBP сети AppleTalk позволяет установить соответствие между именами объектов AppleTalk (для обозначения которых применяется термин различимые в сети объекты, или NVE — Network-Visible Entity) и адресами. Любой объект NVE представ-
ляет одну из служб AppleTalk, адресуемых в сети, например сокет. Объектам NVE ставится в соответствие один или несколько имен объектов и списков атрибутов. Имена объектов представляют собой символьные строки, такие как printer@netl, а списки атрибутов описывают характеристики NVE.
Именованные объекты NVE сопоставляются с сетевыми адресами с применением процесса привязки имен. Привязка имен может выполняться заранее (сразу после запуска пользовательского узла) или по мере необходимости (непосредственно перед первым использованием именованного объекта NVE). Процесс привязки имен, который включает этапы регистрации имени, подтверждения имени, удаления имени и поиска имени, осуществляется под управлением протокола NBP.
Узлы распределены по зонам, что позволяет упростить поиск имен в группе логически взаимосвязанных узлов. Для поиска имен в зоне поисковый запрос NBP передается в локальный маршрутизатор, который рассылает широковещательный запрос по всем сетям, имеющим узлы, которые принадлежат к целевой зоне. Для координации этого процесса применяется протокол ZIP (Zone Information Protocol — протокол информации о зоне).
Протокол ZIP сопровождает представленные в виде таблиц ZIT данные о соответствии сетевых номеров именам зон. Таблицы ZIT (Zone Information Table — таблица с информацией о зоне) хранятся в маршрутизаторах, поскольку именно в этих устройствах наиболее широко применяется протокол ZIP, но протокол используется также конечными узлами в процессе их запуска для выбора своей зоны и получения информации о зоне объединенной сети. В протоколе ZIP применяются также таблицы маршрутизации RTMP для контроля за изменениями в топологии сети. При обнаружении программным обеспечением ZIP записи таблицы маршрутизации, отсутствующей в таблице Z1T, оно создает новую запись ZIT. Пример таблицы Z1T показан на рис. 9.5.
Номер сетиЗона
Рис. 9.5. Пример таблицы ZIT в сети AppleTalk
Протокол AURP
Протокол AURP позволяет сетевому администратору соединить две или несколько объединенных сетей AppleTalk через сеть другого типа, например, основанную на применении протоколов TCP/IP (Transmission Control Protocol/Internet Protocol — протокол управления передачей/межсетевой протокол), для формирования распределенной сети AppleTalk. Используемое при этом соединение между объединенными се-
тями AppleTalk называется туннелем", туннель функционирует как отдельный, виртуальный канал связи, как показано на рис. 9.6.
Объединенная сеть AppleTalk АОбъединенная сеть AppleTalk АМаршрутизаторМаршрутизаторМаршрутизаторМаршрутизаторОбъединенная сеть AppleTalk СРис. 9.6. Туннель AppleTalkОбъединенная сеть AppleTalk СРис. 9.6. Туннель AppleTalk
Объединенная сеть AppleTalk А
Объединенная сеть AppleTalk А
Маршрутизатор
Маршрутизатор
Маршрутизатор
Маршрутизатор
Объединенная сеть AppleTalk С
Рис. 9.6. Туннель AppleTalk
Объединенная сеть AppleTalk С
Рис. 9.6. Туннель AppleTalk
Маршрутизатор, соединяющий объединенную сеть AppleTalk с туннелем (т.е. маршрутизатор, в котором эксплуатируется программное обеспечение AURP), называется внешним маршрутизатором. Внешний маршрутизатор передает пакеты данных и информацию маршрутизации AppleTalk через сеть другого типа (транзитную сеть) путем инкапсуляции пакетов данных в виде фреймов с заголовками, соответствующими требованиям сетевой системы другого типа. Получив эти фреймы, внешний маршрутизатор, находящийся на другом конце канала, удаляет информацию заголовка транзитной сети и отправляет пакеты через соответствующий интерфейс. В первой реализации протокола AURP предусматривались инкапсуляция пакетов в виде фреймов UDP.
Если к туннелю подключены только два внешних маршрутизатора, он называется туннелем типа “точка-точка", а если подключено несколько внешних маршрутизаторов, — многоточечным туннелем. С другой стороны, если все внешние маршрутизаторы, подключенные к многоточечному туннелю, могут передавать пакеты друг другу, такой туннель называется полностью связанным, а если один или несколько внешних маршрутизаторов не имеет информации о том, что к многоточечному туннелю подключены другие внешние маршрутизаторы, такой туннель называется частично связанным. Каждый внешний маршрутизатор функционирует одновременно и как маршрутизатор AppleTalk (в своей локальной объединенной сети), и как оконечный узел (в транзитной сети, соединяющей несколько объединенных сетей AppleTalk).
Основное назначение протокола AURP состоит в постоянном сопровождении таблиц маршрутизации во всей распределенной сети AppleTalk путем обмена информацией о маршрутах между внешними маршрутизаторами. Кроме того, протокол AURP обеспечивает инкапсуляцию пакетов данных AppleTalk в виде фреймов с заголовками, которые соответствуют требованиям транзитной сети.
В протоколе AURP используется принцип расщепления горизонта (согласно которому в любом случае должна быть исключена возможность передачи информации маршрутизации в направлении, откуда она была получена) для ограничения распространения обновлений маршрутизации. По этой причине внешний маршрутизатор передает другим внешним маршрутизаторам, подключенным к туннелю, только ту информацию маршрутизации, которая относится к сетям, входящим в состав его локальной объединенной сети.
После получения информации о том, что в туннеле появился еще один внешний маршрутизатор, каждый из имеющихся внешних маршрутизаторов обменивается с ним списками сетевых номеров и соответствующей информацией о зонах. После этого любой внешний маршрутизатор передает информацию маршрутизации только при возникновении одного из следующих событий.
Добавление сети в таблицу маршрутизации.
Изменение пути доступа к сети, в результате которого внешний маршрутизатор вынужден обращаться к определенной сети либо через свою локальную объединенную сеть, а не через туннель, либо через туннель, а не через локальную объединенную сеть.
Удаление сети из таблицы маршрутизации.
Изменение расстояния до сети.
При получении внешним маршрутизатором пакетов данных AppleTalk или информации маршрутизации, которая должна быть перенаправлена по туннелю, программный модуль AURP преобразует эту информацию в пакеты AURP. Пакеты AURP инкапсулируются во фреймы с заголовками, соответствующими требованиям транзитной сети, и передаются по туннелю к внешнему маршрутизатору назначения, как показано на рис. 9.7.
К туннелюК туннелю
К туннелю
К туннелю
Маршрутная информация
К локальной объединенной сетиК локальной объединенной сетиМаршрутная информацияМаршрутная информацияМаршрутная информацияМаршрутная информацияОсновной процесс маршрутизацииОсновной процесс маршрутизацииК локальной объединенной сетиК локальной объединенной сети
К локальной объединенной сети
К локальной объединенной сети
Маршрутная информация
Маршрутная информация
Маршрутная информация
Маршрутная информация
Основной процесс маршрутизации
Основной процесс маршрутизации
К локальной объединенной сети
К локальной объединенной сети
Рис. 9.7. Схема функционирования протокола AURP
Во внешнем маршрутизаторе назначения программный модуль AURP удаляет заголовки, соответствующие требованиям транзитной системы, извлекает пакеты AURP и передает пакеты данных AppleTalk в конечный пункт назначения. Внешний маршрутизатор использует пакеты AURP, содержащие информацию маршрутизации, для обновления своих таблиц маршрутизации, но не распространяет эту информацию по каким-либо иным внешним маршрутизаторам.
Примечание
В соответствии со спецификациями корпорации Apple Computer, программное обеспечение AURP выполняет прямое и обратное преобразование пакетов RTMP и ZIP в пакеты AURP. В реализации корпорации Cisco программное обеспечение AURP преобразует не только пакеты RTMP и ZIP, но и пакеты Enhanced IGRP.
Протокол АЕР
АЕР представляет собой чрезвычайно простой протокол, который вырабатывает пакеты, применяемые для проверки достижимости различных сетевых узлов.
Протокол АТР
Протокол АТР может применяться для поддержки таких приложений, основанных на использовании неразрывных цепочек операций, называемых транзакциями, какие применяются в банках или магазинах розничной торговли. Транзакции АТР состоят из запросов (от клиентов) и ответов (от серверов). Каждая пара запрос—ответ имеет конкретный идентификатор транзакции. В процессе выполнения одной транзакции два сокета, назначенные клиенту и серверу, остаются неизменными. Протокол АТР определяет транзакции двух типов: ХО (eXactly Once — однократная) и ALO (At-Least- Опсе — многократная). Транзакции типа ХО применяются в таких ситуациях, когда выполнение транзакции более одного раза является недопустимым. В качестве примеров транзакций, неоднократное выполнение которых может привести к получению недопустимых данных, можно указать банковские транзакции.
Протокол АТР обеспечивает выполнение наиболее важных функций протокола транспортного уровня, включая подтверждение и повторную передачу данных, упорядочение пакетов, фрагментацию и повторную сборку. Кроме того, протокол АТР ограничивает сегментацию сообщений восьмью пакетами, а пакеты АТР не могут содержать больше 578 байтов данных.
Протоколы верхнего уровня
Спецификации AppleTalk определяют несколько протоколов верхнего уровня.
Протокол ADSP (AppleTalk Data Stream Protocol — протокол передачи данных AppleTalk) обеспечивает установление и поддержку дуплексных потоков данных между двумя сокетами в объединенной сети AppleTalk. Протокол ADSP является надежным протоколом; это означает, что он гарантирует доставку байтов данных в том же порядке, в каком они были отправлены, без потерь и дублирования. Протокол ADSP предусматривает нумерацию каждого байта данных, что позволяет контролировать передачу отдельных элементов потока данных. Кроме того, этот протокол определяет механизм управления потоком данных. Получатель данных имеет практическую возможность замедлить передачу данных отправителем, уменьшив размер объявленного окна приема. Этот протокол предоставляет также механизм передачи внеочередных управляющих сообщений. В качестве средства передачи внеочередных управляющих сообщений от одного объекта AppleTalk к другому используются сигнальные пакеты. Для этих пакетов применяется отдельный поток с последовательной нумерацией байтов, позволяющий отличить их от обычных пакетов данных ADSP.
Протокол ASP (AppleTalk Session Protocol — сеансовый протокол AppleTalk) позволяет устанавливать и поддерживать сеансы (неразрывные последовательности логических операций обмена данными) между клиентом и сервером AppleTalk.
Протокол PAP (Printer Access Protocol — протокол доступа к принтеру) сети AppleTalk представляет собой протокол с установлением логического соеди-
нения, позволяющий устанавливать и поддерживать соединения между клиентами и серверами. (Слово Printer в названии этого протокола сохраняется только по традиции.)
Протокол AFP (AppleTalk Filing Protocol — файловый протокол AppleTalk) предоставляет клиентам совместный доступ по сети к файлам, находящимся на сервере.
Устранение нарушений в работе сети AppleTalk
В настоящем разделе представлена информация, необходимая для устранения нарушений в работе протоколов сети AppleTalk, характеризующихся отсутствием связи и снижением производительности. Кроме основных протоколов AppleTalk, в данной главе рассматриваются также протоколы AppleTalk Enhanced IGRP, ARA (AppleTalk Remote Access — служба удаленного доступа AppleTalk), AURP и FDDITalk.
В разделе “Рекомендации по настройке конфигурации и устранению нарушений в работе сети AppleTalk” описаны профилактические меры и приведены полезные рекомендации по настройке конфигурации и устранению нарушений в работе объединенной сети AppleTalk. В остальных разделах описаны определенные нарушения в работе сети AppleTalk, перечислены проблемы, которые могут вызвать каждый из рассматриваемых признаков неисправности, и приведены решения этих проблем.
В следующих разделах описаны наиболее типичные нарушения в работе сети AppleTalk.
AppleTalk: пользователи не могут обратиться к зонам или службам.
AppleTalk: в программе Chooser отсутствует информация о зонах.
AppleTalk: в программе Chooser не задана информация об устройствах.
AppleTalk: периодически нарушается доступ к сетевым службам.
AppleTalk: в программе Chooser появляются старые имена зон (“фантомные” зоны).
AppleTalk: происходит разрыв соединений со службами.
AppleTalk: все попытки инициализировать маршрутизацию AppleTalk в интерфейсе оканчиваются неудачей.
AppleTalk: порт не выходит из режима перезапуска или сбора информации о конфигурации.
AppleTalk Enhanced IGRP: клиенты не могут подключиться к серверам.
AppleTalk Enhanced IGRP: в маршрутизаторах не формируются таблицы смежных устройств.
AppleTalk Enhanced IGRP: в таблице маршрутизации отсутствуют маршруты.
AppleTalk Enhanced IGRP: низкая производительность.
AppleTalk Enhanced IGRP: маршрутизатор не выходит из активного режима.
AURP: маршруты не распространяются через туннель AURP.
FDDITalk: с маршрутами не связана ни одна зона.
ARA: клиент ARA не способен подключиться к серверу ARA.
ARA: соединение зависает после поступления сообщения "Communicating At...".
ARA: невозможно передавать или принимать данные по входящему коммутируемому соединению ARA.
ARA: низкая производительность при передаче данных по входящему коммутируемому соединению.
Рекомендации по настройке конфигурации и устранению нарушений в работе сети AppleTalk
В настоящем разделе представлены рекомендации по настройке конфигурации и устранению нарушений в работе, которые позволяют предотвращать или быстрее устранять нарушения в работе объединенных сетей AppleTalk.
Здесь представлены сведения о том, как предотвратить возникновение неисправностей в сети AppleTalk, устранить проблемы, которые могут возникать при изменении конфигурации объединенной сети, откорректировать имена зон, применить режим обнаружения устройств AppleTalk и вызвать запуск интерфейса, чтобы обеспечить включение маршрутизатора в работу, даже если сеть неправильно настроена.
Предотвращение нарушений в работе сети AppleTalk
В табл. 9.1 приведены рекомендации, позволяющие исключить ошибки при настройке конфигурации маршрутизатора для сети AppleTalk.
[таблица 9.1. Методы предотвращения нарушений в работе сети AppleTalk \
ОписаниеОписаниеПрофилактическое мероприятие
Описание
Описание
Конфигурация каждого маршрутизатора, подключенного к сети, должна соответствовать конфигурации этой сетиКаждый сетевой номер в объединенной сети должен быть уникальным По возможности во всех объектах сети должен быть выполнен переход на версию 2 спецификаций AppleTalkКонфигурация каждого маршрутизатора, подключенного к сети, должна соответствовать конфигурации этой сетиКаждый сетевой номер в объединенной сети должен быть уникальным По возможности во всех объектах сети должен быть выполнен переход на версию 2 спецификаций AppleTalkПри внесении изменений в конфигурацию маршрутизатора или интерфейса необходимо разрешить применение привилегированной ехес-команды debug apple error для внесения в журнал информации об ошибкахПри внесении изменений в конфигурацию маршрутизатора или интерфейса необходимо разрешить применение привилегированной ехес-команды debug apple error для внесения в журнал информации об ошибкахКаждый маршрутизатор в сети AppleTalk (т.е. в отдельном ее кабельном сегменте) должен иметь конфигурацию, согласованную со всей сетью. Поэтому в каждом маршрутизаторе, подключенном к любому сегменту, должны быть заданы одинаковые сетевые номера, кабельные диапазоны, установки таймера, имензон и другие параметры
Конфигурация каждого маршрутизатора, подключенного к сети, должна соответствовать конфигурации этой сети
Каждый сетевой номер в объединенной сети должен быть уникальным По возможности во всех объектах сети должен быть выполнен переход на версию 2 спецификаций AppleTalk
Конфигурация каждого маршрутизатора, подключенного к сети, должна соответствовать конфигурации этой сети
Каждый сетевой номер в объединенной сети должен быть уникальным По возможности во всех объектах сети должен быть выполнен переход на версию 2 спецификаций AppleTalk
При внесении изменений в конфигурацию маршрутизатора или интерфейса необходимо разрешить применение привилегированной ехес-команды debug apple error для внесения в журнал информации об ошибках
При внесении изменений в конфигурацию маршрутизатора или интерфейса необходимо разрешить применение привилегированной ехес-команды debug apple error для внесения в журнал информации об ошибках
Сетевые номера по всей сети AppleTalk должны быть уникальными. Повторяющиеся сетевые номера могут вызвать нарушение связи и снижение производительности
Чтобы свести к минимуму проблемы функциональной совместимости, необходимо перевести все интерфейсы Ethernet маршрутизаторов на версию 2. Сети, в которых одновременно применяются спецификации версии 1 и версии 2, а также нерасширенные сети AppleTalk, могут стать источником проблем
Привилегированная exec-команда debug apple error обеспечивает контроль за ходом и состоянием изменений в объединенной сети и выработку предупреждающих сообщений при возникновении каких-либо ошибок. Кроме того, эту команду можно периодически вызывать на выполнение, если возникает подозрение, что в сети имеются какие-либо неисправности. Если же сеть работает устойчиво, выполнение этой команды не приводит к получению каких-либо результатов.
Профилактическое мероприятие
Описание
При проектировании сети необходимо учитывать направления потоков трафика и сводить к минимуму количество различных зон в объединенной сети
Для всех таймеров AppleTalk в объединенной сети должно быть установлено значение, предусмотренное по умолчанию
В вычислительном центре можно также установить сервер системного журнала и ввести в конфигурацию маршрутизатора команду appletalk event-logging. Эта команда обеспечивает ведение синхронного журнала наиболее важных событий в сети с отметками времени.
После завершения диагностических исследований необходимо отменить эту команду с помощью команды no debug apple error
Продуманное размещение узлов по зонам позволяет свести к минимуму ненужный трафик NBP. Такое планирование является особенно важным в распределенных сетях, где плата за прохождение трафика через транзитные каналы (такие как Х.25) может оказаться весьма высокой.
Компьютер Macintosh с установленной на нем операционной системой System 6 после открытия пользователем программы Chooser непрерывно передает пакеты BrRq по протоколу NBP. При этом в ОС System 7 применяется алгоритм вычисления отсрочки по логарифмическому закону, позволяющий свести к минимуму объем вырабатываемого трафика.
Рекомендуется также присвоить всем соединениям опор- ной/распределенной сети одно и то же имя зоны, а не помещать их все в одну зону вместе с локальной сетью.
В большинстве объединенных сетей не желательно, чтобы имена зон для всех соединений опорной или распределенной сети появлялись в списке программы Chooser. Если для всех каналов распределенной сети будет принято одинаковое имя зоны (например, ZZSerial), то в меню программы Chooser появится только эта запись
В стабильно работающей сети почти никогда не встречаются установки таймера, введенные в конфигурацию и имеющие значения, отличные от предусмотренных по умолчанию. Для всех таймеров в объединенной сети или, как минимум, для всех таймеров в опорной сети объединенной сети необходимо неуклонно устанавливать одно и то же значение. Прежде чем вносить изменения в установки таймеров AppleTalk, применяемые по умолчанию, проконсультируйтесь с представителем службы технической поддержки Cisco
Применение команд test appletalk и ping appletalk
В маршрутизаторе с установленной версией 11.1 операционной системы Cisco IOS или последующих версий для поиска узлов, характеризующихся нарушениями в работе, может применяться привилегированная exec-команда test appletalk. Для выполнения информационного поиска объектов, зарегистрированных в программном обеспечении протокола NBP, предназначены опции nbp этой команды. Информация, полученная с помощью опций nbp, требуется в тех случаях, если зоны AppleTalk перечислены в программе Chooser, но службы этих зон не доступны.
При вызове на выполнение команды test appletalk может применяться опция confirm для проверки того, зарегистрировано ли вместе с устройством имя указанного типа. Например, команда nbp confirm 24279.173 my-mac:AFPServer8engineering позволя-
ет подтвердить, что имя my-mac зарегистрировано на устройстве 24279.173 в зоне engineering. Объект имеет тип AFPServer. Ниже показана синтаксическая структура команды nbp confirm.
nbp confirm appletalk-address [:skt] object: type®zone
Ниже описана синтаксическая структура этой команды.
appletalk-address. Сетевой адрес AppleTalk в форме network.node. Параметр network представляет собой 16-разрядный сетевой номер со значением в диапазоне 1-65279. Параметр node — 8-битовый номер узла в диапазоне от 0 до 254. Оба числа являются десятичными.
:skt. (Необязательный параметр.) Имя сокета.
object:type. Имя устройства и тип службы. Двоеточие (:) между параметрами object и type является обязательным.
@zone. Название зоны AppleTalk, в которой находится объект object: type.
В выпусках программного обеспечения, предшествующих версии 11.0 операционной системы Cisco IOS, аналогичную функцию выполняет exec-команда ping appletalk. Эта команда может применяться для проверки достижимости определенного узла с рассматриваемого маршрутизатора (например, команда ping appletalk 2.24 выполняет эхо-тестирование узла 2.24 сети AppleTalk).
Ниже приведен пример вызова на выполнение команды ping и показаны полученные при этом результаты.
Router> ping appletalk 2.24
Type escape sequence to abort.
Sending 5, 100-byte AppleTalk Echoes to 2.24, timeout is 2 seconds: !!!!!
Success rate is 100 percent, round-trip min/avg/max = 4/4/8 ms
Привилегированная ехес-команда ping поддерживает также несколько опций AppleTalk, которые предоставляют дополнительные возможности поиска неисправностей. В частности, опция nbp может применяться, если в программе Chooser имеется перечень зон AppleTalk, а службы не доступны. Если конфигурация содержит глобальную команду конфигурации appletalk name-lookup-interval, опция nbp команды ping AppleTalk отображает информацию об узлах в соответствии с их регистрационными именами NBP.
Предотвращение возникновения нарушений в работе при изменении конфигурации объединенной сети
При внесении изменений в имена зон или номера кабельных диапазонов могут возникать конфликты конфигураций. В частности, нарушения в работе могут возникать, если в объединенной сети имеются маршрутизирующие устройства, не учтенные сетевым администратором.
В качестве маршрутизаторов могут действовать многие устройства (например, серверы Novell и Pathworks или рабочие станции UNIX, на которых эксплуатируется программное обеспечение САР для поддержки совместного доступа к печати и файлам). Как правило, перед изменением имен зон или номеров кабельных диапазонов в объединенной сети необходимо остановить все маршрутизаторы с тем, чтобы ни один
маршрутизатор Cisco не обнаружил конфликт и не помешал инициализировать соответствующий интерфейс в сети AppleTalk.
Перед изменением конфигурации вызовите на выполнение exec-команду show appletalk neighbors, чтобы определить, на каких маршрутизаторах необходимо отменить маршрутизацию AppleTalk. В частности, маршрутизацию AppleTalk необходимо отменить на всех маршрутизаторах, которые находятся в одном и том же сетевом сегменте и отправляли обновления RTMP в течение последних 10 секунд. Отмените маршрутизацию AppleTalk во всех соответствующих интерфейсах, подождите примерно 10 минут, а затем активизируйте исходный маршрутизатор.
Корректировка имен зон
Перед изменением имени какой-либо зоны в существующей сети выполните следующие действия.
Шаг 1. Отмените маршрутизацию AppleTalk во всех интерфейсах маршрутизаторов в данном кабеле примерно на 10 минут. Это позволяет всем маршрутизаторам в объединенной сети исключить по давности использования номер соответствующей сети из своих таблиц маршрутизации.
Шаг 2. Выполните настройку конфигурации нового списка зон.
Шаг 3. Снова разрешите маршрутизацию AppleTalk во всех интерфейсах.
Эти действия необходимы, поскольку в протоколах AppleTalk не предусмотрены средства передачи смежным устройствам в объединенной сети информации об изменениях в списке зон. Маршрутизаторы передают запросы ZIP, только если в объединенной сети появляется новая сеть (или сеть, информация о которой была исключена из таблиц маршрутизации по давности использования).
Добавление новой зоны к расширенной конфигурации кабеля не позволяет маршрутизатору снова перевести в рабочее состояние интерфейс AppleTalk после его сброса. Это связано с тем, что конфигурация маршрутизатора больше не соответствует конфигурации смежных с ним устройств (т.е. маршрутизатор обнаруживает ошибку несоответствия конфигураций).
Режим обнаружения устройств AppleTalk
При переводе в рабочее состояние любого интерфейса в существующем кабеле, где определен длинный список зон, следует использовать режим обнаружения устройств AppleTalk, позволяющий сетевому администратору сэкономить усилия и избежать ошибок.
Ниже описаны действия по переводу интерфейса в рабочее состояние в режиме обнаружения.
Шаг 1. Переведите интерфейс в режим обнаружения (с помощью команды конфигурации интерфейса appletalk cable-range 0-0). Маршрутизатор, находящийся в режиме обнаружения, изменяет свою конфигурацию в соответствии с объявленным кабельным диапазоном, если последний отличается от указанного в конфигурации маршрутизатора. Для определения того, завершился ли процесс обнаружения, можно использовать привилегированную exec-команду debug apple events, отображающую при этом сообщение "operational".
Шаг 2. После завершения процесса обнаружения, не выходя из режима настройки конфигурации интерфейса, введите команду конфигурации интерфейса no appletalk
discovery для конкретного инициализируемого интерфейса AppleTalk. В результате ее выполнения полученная информация записывается в память, а при запуске порта принудительным образом выполняется проверка конфигурации.
Маршрутизатор в ходе обычной эксплуатации не должен находиться в режиме обнаружения (рекомендуется использовать режим обнаружения только при первоначальной настройке конфигурации сетей). После первоначальной настройки конфигурации выполните настройку всех маршрутизаторов на работу в исходном режиме или режиме необнаружения. Если будет разрешен режим обнаружения устройств AppleTalk и перезапущен интерфейс, то при отсутствии в непосредственно подключенной сети другого функционирующего сервера связи или маршрутизатора запуск интерфейса не будет выполнен успешно. Не рекомендуется настраивать конфигурацию всех серверов связи и маршрутизаторов в сети на работу с разрешенным режимом обнаружения. Если возникнет такая ситуация, при которой должен быть одновременно выполнен перезапуск всех серверов связи (например, после нарушения подачи электроэнергии), то сеть станет недоступной до того момента, как будет перезапущен хотя бы один сервер связи или маршрутизатор с запрещенным режимом обнаружения.
Шаг 3. Вызовите на выполнение привилегированную exec-команду copy runningconfig startup-config, чтобы записать полученную информацию в энергонезависимое ОЗУ.
Шаг 4. Проверьте конфигурацию с помощью привилегированной exec-команды show running-config.
Принудительный перевод интерфейса в рабочее состояние
В некоторых ситуациях может потребоваться принудительно перевести какой-либо интерфейс в рабочее состояние, даже несмотря на то, что его список зон конфликтует со списком зон какого-либо иного маршрутизатора в сети. Для этого можно применить глобальную команду конфигурации appletalk ignore-verify-errors. Обычно иным маршрутизатором, о котором здесь идет речь, является маршрутизатор, над которым сетевой администратор не имеет административного контроля, но знает, что в нем определен неправильный список зон.
Команда appletalk ignore-verify-errors позволяет исключить действия, выполняемые интерфейсом AppleTalk по умолчанию. В частности, по умолчанию интерфейс AppleTalk не переходит в рабочее состояние, если его список зон конфликтует со списком зон одного из смежных устройств. Тем не менее при использовании этой команды необходимо соблюдать крайнюю осторожность, поскольку перевод в рабочее состояние интерфейса со списком зон, конфликтующим со списком зон других маршрутизаторов, может вызвать серьезные нарушения в работе сети. Кроме того, все равно когда-либо придется выполнить корректировку конфигурации упомянутого здесь иного маршрутизатора, чтобы во всех маршрутизаторах объединенной сети списки зон были согласованы.
После того как все маршрутизаторы AppleTalk в данном сетевом сегменте согласуют списки зон, отмените команду appletalk ignore-verify-errors с использованием формы этой команды с префиксом по. Для получения подробной информации о глобальной команде конфигурации appletalk ignore-verify-errors обратитесь к руководству Cisco IOS Network Protocols Command Reference, Part 1.
AppleTalk: пользователи не могут обратиться к зонам или службам
Признак неисправности. Пользователи не могут обратиться к зонам или службам, информация о которых имеется в программе Chooser. Пользователи могут или не могут обратиться к службам в своей собственной сети.
В табл. 9.2 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 9.2. AppleTalk: пользователи не могут обратиться '..
к юнш<1!ти службам-.;
Проблема
Решение
Несоответствие конфигураций
Шаг 1. Вызовите на выполнение exec-команду show appletalk interfaces. Проверьте наличие в результатах этой команды сообщения "port configuration mismatch".
Если вывод команды содержит сообщение "mismatch", это означает, что конфигурация данного маршрутизатора не согласована с конфигурацией смежного устройства, указанного в сообщении.
Если вывод команды не включает сообщение "mismatch”, вызовите на выполнение привилегированную exec-команду clear apple interface в рассматриваемом интерфейсе. Если после выполнения команды очистки clear интерфейс переходит в рабочее состояние, это означает, что несоответствия конфигураций не существует.
Снова введите exec-команду show appletalk interfaces. Если вывод этой команды все еще содержит сообщение "port configuration mismatch", убедитесь в том, что в конфигурациях всех маршрутизаторов согласованы между собой сетевой номер или кабельный диапазон, а также зона или список зон.
Шаг 2. Если в конфигурациях маршрутизаторов эти параметры не согласованы, откорректируйте конфигурации маршрутизаторов, чтобы привести все маршрутизаторы в согласованное состояние.
Шаг 3. Если описанные выше действия не позволяют устранить нарушение в работе, переведите маршрутизатор с неправильной конфигурацией в режим обнаружения, задав команду конфигурации интерфейса appletalk address 0.0 в нерасширенной сети или команду appletalk cable-range 0-0 в расширенной сети. Эта команда вынуждает маршрутизатор получить информацию о конфигурации от сети.
Дополнительная информация о несоответствиях конфигураций приведена в разделе “Несоответствия конфигураций AppleTalk"
Повторяющиеся сетевые номера или перекрывающиеся кабельные диапазоны
В технологии AppleTalk сетевые номера должны быть уникальными во всей объединенной сети. Если существуют повторяющиеся сетевые номера, то перенаправление пакетов к месту их назначения может оказаться невозможным.
Если службы AppleTalk не отображаются в составе информации программы Chooser, касающейся конкретных сетей, то, вероятно, эти сети имеют повторяющиеся сетевые номера.
Проблема
Решение
Шаг 1. Откорректируйте значение сетевого номера или кабельного диапазона рассматриваемой сети, присвоив уникальное значение с помощью команды конфигурации интерфейса appletalk cable-range.
Шаг 2. Воспользуйтесь привилегированной exec-командой show appletalk route privileged для просмотра таблицы маршрутизации. Если данный сетевой номер или кабельный диапазон продолжает появляться в таблицах маршрутизации, это означает, что обнаружено повторяющееся значение (поскольку другая сеть, в которой используется этот номер, продолжает передавать обновления маршрутизации).
Если сетевой номер или кабельный диапазон исчезает из объединенной сети через 40 секунд, это означает, что повторяющееся значение не обнаружено. Восстановите прежнее значение спецификации сетевого номера или кабельного диапазона и повторите попытку поиска повторяющегося сетевого номера.
Шаг 3. После внесения изменений в значение сетевого номера или кабельного диапазона конкретного интерфейса следует также повторно ввести имя зоны и другую информацию конфигурации интерфейса для поддержки сети AppleTalk этим интерфейсом
Нарушения правил версий Phase 1 и Phase 2
Шаг 1. Воспользуйтесь привилегированной exec-командой show appletalk globals, чтобы определить, находится ли объединенная сеть в режиме совместимости.
Шаг 2. Разрешите применение глобальной команды конфигурации appletalk name-lookup-interval и воспользуйтесь привилегированной exec-командой show appletalk neighbors, чтобы определить, какое именно смежное устройство (заданное по имени NBP) находится в режиме совместимости.
Шаг 3. Для решения данной проблемы можно выполнить одно из следующих действий.
Переведите программное обеспечение маршрутизаторов AppleTalk версии Phase 1 на программное обеспечение AppleTalk версии Phase 2 и измените конфигурацию объединенной сети.
Убедитесь в том, что все маршрутизаторы функционируют в соответствии с правилами версий Phase 1 и Phase 2.
Дополнительная информация о том, в чем состоят нарушения правил версий Phase 1 и Phase 2, приведена в разделе “Нарушения правил версий Phase 1 и Phase 2” ниже в этой главе
Неправильно настроены списки доступа или другие фильтры
Шаг 1. Вызовите на выполнение exec-команду show appletalk access-list во всех маршрутизаторах, находящихся в пути от отправителя к получателю.
Шаг 2. Отмените все списки доступа (или только списки доступа в маршрутизаторе, который с наибольшей вероятностью может служить причиной нарушения в работе) с помощью команды конфигурации интерфейса no appletalk access-group. Если в состав конфигурации входят списки рассылки или другие фильтры, отмените и их.
ПроблемаРешение
Шаг 3. После отмены списков доступа проверьте, стали ли доступными удаленные зоны и службы.
Шаг 4. Если зоны и службы теперь доступны, то проблема, по всей видимости, заключается в неправильно настроенном списке доступа. Чтобы обнаружить неправильный список доступа, последовательно вводите в действие по одному списку доступа до тех пор, пока не будет обнаружено нарушение связи.
Шаг 5. Проверьте на отсутствие ошибок списки доступа и связанные с ними команды конфигурации. Введите в конфигурацию явно заданные операторы permit для трафика, который должен проходить через маршрутизатор обычным образом.
Шаг 6. Если описанные выше действия не позволяют устранить проблемы, то могут существовать и другие неправильно настроенные списки доступа. Продолжайте последовательно вводить в действие по одному и исправлять неправильно настроенные списки доступа до тех пор, пока проблема не будет решена
Несоответствие конфигураций AppleTalk
Несоответствие конфигураций имеет место, если конфигурации всех маршрутизаторов AppleTalk в данном кабеле не соответствуют конфигурации самого кабеля. Это означает, что все маршрутизаторы должны иметь совпадающие сетевые номера, зоны, применяемые по умолчанию, и списки зон.
Для защиты от ошибок в конфигурации, которые приводят к нарушению этого правила, в маршрутизаторах Cisco для сети AppleTalk блокируется активизация любого порта, в котором обнаруживается нарушение данного правила. Если при инициализации интерфейса другие маршрутизаторы в сети не подтверждают правильность настройки данного маршрутизатора, маршрутизатор не позволяет перевести в этом интерфейсе в рабочее состояние программное обеспечение AppleTalk. Маршрутизаторы Cisco предпринимают попытки перезапуска такого интерфейса через каждые две минуты, чтобы избежать простоев, причиной которых могут стать условия, подверженные изменениям.
Но если маршрутизатор уже находится в рабочем состоянии и стал активным еще один маршрутизатор, имеющий несогласованную с ним конфигурацию, то первый маршрутизатор продолжает эксплуатировать соответствующий интерфейс до тех пор, пока не будет выполнен сброс интерфейса. После этого активизация интерфейса становится невозможной. При вызове на выполнение exec-команды show appletalk interfaces маршрутизатор сообщает о несоответствии конфигураций портов.
Ниже приведен пример вывода команды show appletalk interfaces при наличии несоответствия конфигурации.
Ethernet 0 is up, line protocol is up
AppleTalk routing disabled, Port configuration mismatch
AppleTalk cable range is 4-5
AppleTalk address is 4.252, Valid
AppleTalk zone is "Maison Vauquer"
AppleTalk port configuration conflicts with 4.156
AppleTalk discarded 8 packets due to input errors
AppleTalk discarded 2 packets due to output errors
AppleTalk route cache is disabled, port initializing
Строка 2 вывода этой команды показывает, что маршрутизация была запрещена в связи с несоответствием конфигураций портов. Строка 6 показывает адрес AppleTalk конфликтующего маршрутизатора.
В процессе проверки конфигурации можно также получить информацию о зарегистрированном имени NBP конфликтующего маршрутизатора, что позволяет упростить диагностику проблем несовпадения результатов преобразования имен портов. Для просмотра зарегистрированных имен NBP разрешите для использования глобальную команду конфигурации appletalk name-lookup-interval. После этого в выводе ехес- команды show appletalk interfaces узлы отображаются с указанием их регистрационных имен NBP.
Нарушения правил версий Phase 1 и Phase 2
Если к одной и той же объединенной сети подключены маршрутизаторы с программным обеспечением версий 1 и 2, то спецификация объединенной сети должна соответствовать следующим двум правилам.
В расширенной части объединенной сети с программным обеспечением версии 2 не должны применяться спецификации широких кабельных диапазонов. Это означает, что ни один кабельный диапазон не должен выходить за пределы одного (единственного) сетевого номера. Например, все кабельные диапазоны 22, 9-9 и 20-20 являются приемлемыми, а кабельные диапазоны 10-12 и 100104 — не приемлемы.
Единственному кабельному диапазону не может быть присвоено несколько зон.
Если эти правила не соблюдаются, то характеристики связи между нерасширенной и расширенной частями объединенной сети ухудшаются вплоть до того, что связь может быть вообще потеряна. В частности, службы, размешенные в нерасширенных сетях с использованием маршрутизаторов версии 1, не будут видны с другой стороны маршрутизатора версии I.
Примечание
В маршрутизаторах Cisco интерфейсами Ethernet маршрутизатора версии 1 называют интерфейсы, в конфигурации которых указаны один сетевой адрес и инкапсуляция Ethernet I, а не кабельный диапазон и инкапсуляция Ethernet SNAP. С другой стороны, маршрутизатор Cisco, в котором эксплуатируется программное обеспечение версии 8.2 или более поздних версий, является маршрутизатором, совместимым с версией 2 спецификаций AppleTalk, независимо от конфигурации его интерфейсов.
Еше одной проблемой совместимости версий I и 2 является обработка пакетов NBP. В версии 1 AppleTalk предусмотрены три типа пакетов NBP, а в версии 2 AppleTalk — четыре типа пакетов NBP. Это различие может привести к возникновению проблем связи между маршрутизаторами версий 1 и 2. В табл. 9.3 перечислены типы пакетов NBP для версий 1 и 2 AppleTalk.
ЬТаблицаЭ.З. Сравнение.;типов^ак№?^
Пакет NBP версии Phase 1
Пакет NBP версии Phase 2
BrRq (широковещательный запрос)
BrRq (широковещательный запрос)
-
FwdRq (прямой запрос)
LkUp (поисковый запрос)
LkUp (поисковый запрос)
LkUp-Reply (ответ на поисковый запрос)
LkUp-Reply (ответ на поисковый запрос)
Как показано в табл. 9.3, в версии Phase 1 не предусмотрено применение пакетов прямого запроса. Только в маршрутизаторах версии Phase 2 предусмотрены средства обработки этих запросов. А маршрутизаторы версии Phase 1, получая пакеты прямых запросов, их просто уничтожают.
AppleTalk: в программе Chooser отсутствует информация о зонах
Признак неисправности. Некоторые зоны не отображаются в программе Chooser. Эти зоны не видны из нескольких сетей. В некоторых случаях при открытии программы Chooser список зон изменяется.
В табл. 9.4 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 9.4. AppleTalk: в программе Chooser отсутствует информация > 1‘ - ОЗОНЭХ. - , . ■|
ПроблемаРешение
Несоответствие Шаг 1. Вызовите на выполнение exec-команду show appletalk interfaces, конфигурацийПроверьте наличие в результатах этой команды сообщения "port
configuration mismatch”.
Если вывод команды содержит сообщение "mismatch", это означает, что конфигурация данного маршрутизатора не согласована с конфигурацией смежного устройства, указанного в сообщении.
Если вывод команды не включает сообщение "mismatch", вызовите на выполнение привилегированную exec-команду clear apple interface в рассматриваемом интерфейсе. Если посте выполнения команды очистки clear интерфейс становится функционирующим, это означает, что несоответствия конфигураций не существует.
Шаг 2. Снова введите exec-команду show appletalk interfaces. Если вывод этой команды все еще содержит сообщение "port configuration mismatch", убедитесь в том, что в конфигурациях всех маршрутизаторов согласованы между собой сетевой номер или кабельный диапазон, а также зона или список зон.
Шаг 3. Если в конфигурациях маршрутизаторов эти параметры не согласованы, откорректируйте конфигурации маршрутизаторов, чтобы привести все маршрутизаторы в согласованное состояние.
Проблема
Решение
Шаг 4. Если описанные выше действия не позволяют устранить нарушение в работе, переведите маршрутизатор с неправильной конфигурацией в режим обнаружения, задав команду конфигурации интерфейса appletalk address 0.0 в нерасширенной сети или команду appletalk cable-range 0-0 в расширенной сети. Эта команда вынуждает маршрутизатор получить информацию о конфигурации от сети.
Дополнительная информация о несоответствиях конфигураций приведена выше, в разделе “Несоответствия конфигураций AppleTalk"
Неправильно настроены списки доступа или другие фильтры
Шаг 1. Вызовите на выполнение exec-команду show appletalk access-list во всех маршрутизаторах, находящихся в пути от отправителя к получателю.
Шаг 2. Отмените все списки доступа (или только списки доступа в маршрутизаторе, который с наибольшей вероятностью может служить причиной нарушения в работе) с помощью команды конфигурации интерфейса no appletalk access-group. Если в состав конфигурации входят списки рассылки или другие фильтры, отмените и их.
Шаг 3. После отмены списков доступа проверьте, стали ли доступными удаленные зоны и службы.
Шаг 4. Если зоны и службы теперь доступны, то проблема, по всей видимости, заключается в неправильно настроенном списке доступа. Чтобы обнаружить неправильный список доступа, последовательно вводите в действие по одному списку доступа до тех пор, пока не будет обнаружено нарушение связи.
Шаг 5. Проверьте на отсутствие ошибок списки доступа и связанные с ними команды конфигурации. Введите в конфигурацию явно заданные операторы permit для трафика, который должен проходить через маршрутизатор обычным образом.
Шаг 6. Если описанные выше действия не позволяют устранить проблемы, то могут существовать и другие неправильно настроенные списки доступа. Продолжайте последовательно вводить в действие по одному и исправлять неправильно настроенные списки доступа до тех пор, пока проблема не будет решена
Самопроизвольное изменение маршрута (непостоянство маршрута)
При чрезмерном объеме трафика в объединенных сетях со многими маршрутизаторами возникают ситуации, при которых некоторые маршрутизаторы не имеют возможности отправлять обновления RTMP через каждые 10 секунд, как это требуется. Поскольку маршрутизаторы начинают удалять маршруты по давности использования после пропуска двух последующих обновлений RTMP, то нерегулярное поступление обновлений RTMP может привести к постоянным изменениям маршрутов.
Шаг 1. Воспользуйтесь exec-командой show interfaces для проверки объема трафика. Проверьте нагрузку для каждого и нтерфейса.
Ниже приведен пример вывода команды show interfaces.
Проблема
Решение
EthernetO is up, line protocol is up
Hardware is Lance, address is 0000.0c32.49bl (bia 0000.0c32.49bl)
Internet address is 192.168.52.26/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usee, rely
255/255,
load 1/255
[...]
Поле load, отображаемое в выводе команды show interfaces, показывает относительную нагрузку на интерфейс в виде числителя дроби со знаменателем 255 (где 255/255 соответствует полностью загруженному интерфейсу), рассчитанную как экспоненциальное среднее за время, превышающее 5 минут.
Шаг 2. Если нагрузка составляет меньше 50%, то для решения этой проблемы можно изменить значения установок таймера в составе конфигурации, отведя больше времени на распространение обновлений RTMP по сети.
Если же нагрузка превышает 50%, то может потребоваться сегментировать сеть, чтобы уменьшить число маршрутизаторов (и поэтому уменьшить объем трафика) в каждом сетевом сегменте.
Шаг 3. Воспользуйтесь привилегированной exec-командой debug apple events, чтобы определить, не происходит ли недопустимое удаление маршрутов по давности использования. Вывод этой команды должеи выглядеть примерно так:
Routeridebug apple events
AppleTalk Events debugging is on
Routeri
4AT-6-PATHN0TIFY: EthernetO: AppleTalk RTMP path to 250250 down; reported bad by 200.41
Предостережение. При распределении процессорного времени процессу формирования отладочного вывода присваивается один из самых высоких приоритетов, поэтому система может стать непригодной для выполнения обычной работы. По этой причиие команды debug должны применяться только для диагностики конкретных проблем или проведения сеансов поиска неисправностей с участием сотрудников службы технической поддержки Cisco. Кроме того, команды debug следует использовать в период сокращения сетевого трафика и уменьшения количества пользователей. Это снижает вероятность того, *гго дополнительные издержки, связанные с выполнением команды debug, нарушат нормальную эксплуатацию системы.
Шаг 4. Если удаление маршрутов по давности использования происходит неправильно, для устранения этого нарушения в работе сети примените глобальную команду конфигурации appletalk timers. Для начала можно предложить использовать установки таймера 10, 30 и 90, но они не должны превышать значений 10, 40 и 120. Первое число всегда должно быть равно 10, а третье число должно в три раза превышать второе.
Проблема
Решение
Чтобы снова установить значения таймера, предусмотренные по умолчанию (10, 20, 60), воспользуйтесь глобальной командой конфигурации no appletalk timers.
Для всех таймеров в объединенной сети или, как минимум, для всех таймеров в опорной сети объединенной сети необходимо неуклонно устанавливать одно и то же значение
Лавинообразное увеличение количества пакетов ZIP
Лавинообразное увеличение количества пакетов ZIP происходит, если маршрутизатор распространяет информацию о маршруте, для которого он в настоящее время не имеет соответствующего имени зоны; затем информация о маршруте распространяется маршрутизаторами, находящимися на большем расстоянии от сервера.
Примечание. В качестве брандмауэров, защищающих сеть от лавинообразного увеличения количества пакетов ZIP в объединенной сети, используются сами маршрутизаторы Cisco. Если маршрутизатор Cisco получает обновление маршрутизации от смежного устройства, он не распространяет информацию о новом маршруте до тех пор, пока не получит в составе этой информации имя зоны.
Шаг 1. Вызовите на выполнение команду show appletalk traffic и проверьте поле со значением числа запросов ZIP.
Ниже приведен пример вывода команды show appletalk traffic.
Routerish apple traffic
[...]
ZIP: 44 received, 35 sent, 6 netinfo
[...]
Router#
Сравните этот вывод с выводом, полученным от той же команды через 30 секунд.
Шаг 2. Если значения счетчиков объема трафика для запросов ZIP увеличиваются очень быстро (более чем на 10 через каждые 30 секунд), то, вероятно, происходит лавинообразное увеличение количества пакетов ZIP.
Воспользуйтесь привилегированной exec-командой debug apple zip, чтобы определить, в какой сети смежные маршрутизаторы запрашивают информацию о зоне. Можно также воспользоваться exec-командой show apple private для проверки количества невыполненных запросов ZIP.
Шаг 3. Определите маршрутизатор, который вводит в объединенную сеть информацию о сетевом номере (и вызывает чрезмерный объем трафика ZIP). Для упрощения поиска маршрутизатора с неправильной конфигурацией можно воспользоваться ехес-командами show appletalk traffic и show appletalk route.
Например, для просмотра таблицы маршрутизации AppleTalk можно применить exec-команду show appletalk route. Проверьте, имеется ли информация о соответствующей сети в таблице маршрутизации, даже если на экране отображается информация о том, что никакая зона не установлена.
Проблема
Решение
Если обнаружена сеть, для которой никакая зона не установлена, то узел этой сети, вероятно, не отвечает на запросы ZIP, что приводит к лавинообразному увеличению количества пакетов ZIP.
Шаг 4. Определите, почему узел не отвечает на запросы ZIP. Причиной этого могут служить списки доступа или другие фильтры. Лавинообразное увеличение количества пакетов ZIP может быть также вызвано ошибкой в программном обеспечении, которое эксплуатируется на данном узле. Узнайте у поставщика программного обеспечения, имеется ли у него информация об этой проблеме
Слишком много зон в объединенной сети
Программа Chooser в операционной системе System 6 может показывать только ограниченное число зон, и это может привести к возникновению нарушений в работе в крупных объединенных сетей, которые имеют множество зон.
Если в рассматриваемом компьютере Macintosh эксплуатируется версия операционной системы System 6, модернизируйте его и переведите на версию System 7 или System 7.5
AppleTalk: в программе Chooser не задана информация об устройствах
Признак неисправности. В программе Chooser появляется информация о зонах, но после выбора службы (такой как AppleShare) и зоны в списке устройств не появляется ни одного устройства.
В табл. 9.5 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 9.5. AppleTalk: в программе Chooser не задана информация об :устройствах7 ■' >' '
РешениеРешениеПроблема
Решение
Решение
Неправильно настроены списки доступаНеправильно настроены списки доступаШаг 1. Вызовите на выполнение exec-команду show appletalk access-list во всех маршрутизаторах, находящихся в пути от отправителя к получателю.
Неправильно настроены списки доступа
Неправильно настроены списки доступа
Шаг 2. Отмените все списки доступа (или только списки доступа в маршрутизаторе, который с наибольшей вероятностью может служить причиной нарушения в работе) с помощью команды конфигурации интерфейса no appletalk access-group.
Шаг 3. После отмены списков доступа проверьте, появляется ли информация об устройствах в программе Chooser.
Шаг 4. Если теперь информация об устройствах появляется в программе Chooser, то проблема, по всей видимости, заключается в том, что неправильно настроенный список доступа отфильтровывает трафик NBP. Чтобы обнаружить неправильный список доступа, последовательно вводите в действие по одному списку доступа до тех пор, пока информация об устройствах не перестанет появляться.
ПроблемаПроблемаРешениеРешение
Проблема
Проблема
Решение
Решение
Шаг 5. Проверьте на отсутствие ошибок списки доступа и связанные с ними команды конфигурации. Введите в конфигурацию явно заданные операторы permit для трафика, который должен проходить через маршрутизатор обычным образом.
Шаг 6. Если описанные выше действия не позволяют устранить проблемы, то могут существовать и другие неправильно настроенные списки доступа. Продолжайте последовательно вводить в действие по одному и исправлять неправильно настроенные списки доступа до тех пор, пока проблема не будет решена.
Дополнительная информация о фильтрации трафика NBP с использованием списков доступа приведена в документе Cisco IOS Network Protocols Configuration Guide, Part 1
AppleTalk: периодически нарушается доступ к сетевым службам
Признак неисправности. Периодически нарушается доступ к сетевым службам.
Службы активизируются и переходят в неактивное состояние без предупреждения.
В табл. 9.6 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
| Таблица 9.6. AppleTalk: периодически нарушается доступ к сетевым |.• службам•
ПроблемаРешение
Повторяющиеся сетевые номера или перекрывающиеся кабельные диапазоныПовторяющиеся сетевые номера или перекрывающиеся кабельные диапазоныВ технологии AppleTalk сетевые номера должны быть уникальными во всей объединенной сети. Если существуют повторяющиеся сетевые номера, то перенаправление пакетов к месту их назначения может оказаться невозможным.
Повторяющиеся сетевые номера или перекрывающиеся кабельные диапазоны
Повторяющиеся сетевые номера или перекрывающиеся кабельные диапазоны
Если службы AppleTalk не отображаются в составе информации программы Chooser, касающейся конкретных сетей, то, вероятно, в этих сетях имеются повторяющиеся сетевые номера, поскольку другая сеть, использующая этот номер, продолжает передавать обновления маршрутов.
Шаг 1. Откорректируйте значение сетевого номера или кабельного диапазона рассматриваемой сети, присвоив уникальное значение с помощью команды конфигурации интерфейса appletalk cable-range.
Шаг 2. Воспользуйтесь привилегированной exec-командой show appletalk route privileged для просмотра таблицы маршрутизации. Если данный сетевой номер или кабельный диапазон продолжает появляться в таблицах маршрутизации, это означает, что обнаружено повторяющееся значение (поскольку другая сеть, в которой используется этот номер, продолжает передавать обновления маршрутизации).
Если сетевой номер или кабельный диапазон исчезает из объединенной сети через 40 секунд, это означает, что повторяющееся значение не обнаружено. Восстановите прежнее значение сетевого номера или спецификации кабельного диапазона и повторите попытку поиска повторяющегося сетевого номера.
Проблема
Решение
Шаг 3. После внесения изменений в значение сетевого номера или кабельного диапазона конкретного интерфейса следует также повторно ввести имя зоны и другую информацию конфигурации интерфейса для поддержки сети AppleTalk этим интерфейсом
Самопроизвольное изменение маршрута (непостоянство маршрута)
При чрезмерном объеме трафика в объединенных сетях со многими маршрутизаторами возникают ситуации, при которых некоторые маршрутизаторы не имеют возможности отправлять обновления RTMP через каждые 10 секунд, как это требуется. Поскольку маршрутизаторы начинают удалять маршруты по давности использования после пропуска двух последующих обновлений RTMP, то нерегулярное поступление обновлений RTMP может привести к постоянным изменениям маршрутов.
Шаг 1. Воспользуйтесь exec-командой show interfaces для проверки объема трафика. Проверьте нагрузку для каждого и нтерфейса.
Ниже приведен пример вывода команды show interfaces.
EthernetO is up, line protocol is up
Hardware is Lance, address is 0000.0c32.49bl (bia
0000.0c32.49bl)
Internet address is 192.168.52.26/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usee, rely 255/255, load 1/255 [-..I
Поле load, отображаемое в выводе команды show interfaces, показывает относительную нагрузку на интерфейс в виде числителя дроби со знаменателем 255 (где 255/255 соответствует полностью загруженному интерфейсу), рассчитанную как экспоненциальное среднее за время, превышающее 5 минут.
Шаг 2. Если нагрузка составляет меньше 50%, то для решения этой проблемы можно изменить значения установок таймера в составе конфигурации, отведя больше времени на распространение обновлений RTMP по сети.
Если же нагрузка превышает 50%, то может потребоваться сегментировать сеть, чтобы уменьшить число маршрутизаторов (и поэтому уменьшить объем трафика) в каждом сетевом сегменте.
Шаг 3. Воспользуйтесь привилегированной exec-командой debug apple events, чтобы определить, не происходит ли недопустимое удаление маршрутов по давности использования. Вывод этой команды должен выглядеть примерно так:
Routeridebug apple events
AppleTalk Events debugging is on
Routeri
4AT-6-PATHNOTIFY: EthernetO: AppleTalk RTMP path to 250
250 down; reported bad by 200.41
ПроблемаПроблемаРешениеРешение
Проблема
Проблема
Решение
Решение
Команда debug apple events является удобным средством устранения нарушений в работе сети AppleTalk, поскольку результаты ее выполнения однозначно характеризуют стабильность работы сети. Если сеть работает устойчиво, то команда debug apple events не возвращает никакой информации. Но если в ходе выполнения эта команда генерирует многочисленные сообщения, то они могут указывать, в чем состоит причина нарушений в работе.
Недостаточно применить только команду debug apple events, чтобы обеспечить накопление результатов выполнения команды apple event-logging в энергонезависимой памяти. Эти данные будут записываться в энергонезависимую память лишь после явного применения команды apple event-logging. Кроме того, если регистрация событий уже разрешена с помощью команды apple event- logging, то разрешение или отмена команды debug apple events не влияет на работу команды apple event-logging.
Предостережение. При распределении процессорного времени процессу формирования отладочного вывода присваивается один из самых высоких приоритетов, поэтому система может стать непригодной для выполнения обычной работы. По этой причине команды debug должны применяться только для диагностики конкретных проблем или проведения сеансов поиска неисправностей с участием сотрудников службы технической поддержки Cisco. Кроме того, команды debug следует использовать в период сокращения сетевого трафика и уменьшения количества пользователей. Это снижает вероятность того, что дополнительные издержки, связанные с выполнением команды debug, нарушат нормальную эксплуатацию системы.
Шаг 4. Если удаление маршрутов по давности использования происходит неправильно, для устранения этого нарушения в работе сети примените глобальную команду конфигурации appletalk timers. Для начала можно предложить использовать установки таймера 10, 30 и 90, но они не должны превышать значений 10, 40 и 120. Первое число всегда должно быть равно 10, а третье число должно в три раза превышать второе.
Чтобы снова установить значения таймера, предусмотренные по умолчанию (10, 20, 60), воспользуйтесь глобальной командой конфигурации no appletalk timers.
Для всех таймеров в объединенной сети или, как минимум, для всех таймеров в опорной сети объединенной сети необходимо неуклонно устанавливать одно и то же значение
Лавинообразное увеличение количества пакетов ZIPЛавинообразное увеличение количества пакетов ZIPЛавинообразное увеличение количества пакетов ZIP происходит, если маршрутизатор распространяет информацию о маршруте, для которого он в настоящее время не имеет соответствующего имени зоны; затем информация о маршруте распространяется маршрутизаторами, находящимися на большем расстоянии от сервера.
Лавинообразное увеличение количества пакетов ZIP
Лавинообразное увеличение количества пакетов ZIP
Проблема
Решение
Примечание. Сами маршрутизаторы Cisco служат в качестве брандмауэров, защищающих сеть от лавинообразного увеличения количества пакетов ZIP в объединенной сети. Если маршрутизатор Cisco получает обновление маршрутизации от смежного устройства, он не распространяет информацию об этом новом маршруте до тех пор, пока не получит имя зоны в составе этой информации.
Шаг 1. Вызовите на выполнение команду show appletalk traffic и проверьте полученные данные о количестве запросов ZIP: Routerish apple traffic [...]
ZIP: 44 received, 35 sent, 6 netinfo
[...]
Router#
Сравните этот вывод с выводом, полученным от той же команды через 30 секунд.
Шаг 2. Если значения счетчиков объема трафика для запросов ZIP увеличиваются очень быстро (более чем на 10 через каждые 30 секунд), то, вероятно, происходит лавинообразное увеличение количества пакетов ZIP.
Воспользуйтесь привилегированной exec-командой debug apple zip, чтобы определить, в какой сети запрашивается информация о зоне смежными маршрутизаторами. Можно также воспользоваться exec-командой show apple private для проверки количества невыполненных запросов ZIP.
Шаг 3. Определите маршрутизатор, который вводит в объединенную сеть информацию о сетевом номере (и вызывает чрезмерный объем трафика ZIP). Для упрощения поиска маршрутизатора с неправильной конфигурацией можно воспользоваться ехес-командами show appletalk traffic и show appletalk route.
Например, для просмотра таблицы маршрутизации AppleTalk можно применить exec-команду show appletalk route. Проверьте, имеется ли информация о соответствующей сети в таблице маршрутизации, даже если на экране отображается информация о том, что никакая зона не установлена.
Если обнаружена сеть, для которой никакая зона не установлена, то узел этой сети, вероятно, не отвечает на запросы ZIP, что приводит к лавинообразному увеличению количества пакетов ZIP.
Шаг 4. Определите, почему узел не отвечает на запросы ZIP. Причиной этого могут служить списки доступа или другие фильтры.
Лавинообразное увеличение количества пакетов ZIP может быть также вызвано ошибкой в программном обеспечении, которое эксплуатируется на данном узле. Узнайте у поставщика программного обеспечения, имеется ли у него информация об этой проблеме
Несоответствие конфигурацийНесоответствие конфигурацийНедопустимые имена зон в таблице маршрута -Недопустимые имена зон в таблице маршрута -зациизации
Несоответствие конфигураций
Несоответствие конфигураций
Недопустимые имена зон в таблице маршрута -
Недопустимые имена зон в таблице маршрута -
зации
зации
AppleTalk: в программе Chooser появляются старые имена зон (“фантомные” зоны)
Признак неисправности. В программе Chooser появляются старые имена зон AppleTalk. Даже после того как имена зоны удаляются из конфигурации, “фантомные” зоны продолжают появляться в программе Chooser.
В табл. 9.7 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 9.7. AppleTalk: в программе Chooser появляются старые имена ' _,зон .(“фантомные”зоны) . ',.
ПроблемаРешение
Шаг 1. Вызовите на выполнение exec-команду show appletalk interfaces. Проверьте наличие в результатах этой команды сообщения "port configuration mismatch". Если вывод команды содержит сообщение "mismatch", это означает, что конфигурация данного маршрутизатора не согласована с конфигурацией смежного устройства, указанного в сообщении. Если в выводе команды отсутствует сообщение "mismatch", вызовите на выполнение привилегированную exec-команду clear apple interface в рассматриваемом интерфейсе. Если после выполнения команды очистки clear интерфейс становится функционирующим, это означает, что несоответствия конфигураций не существует.
Шаг 2. Снова введите exec-команду show appletalk interfaces. Если вывод этой команды все еще содержит сообщение "port configuration mismatch”, убедитесь в том, что в конфигурациях всех маршрутизаторов согласованы между собой сетевой номер или кабельный диапазон, а также зона или список зон.
Шаг 3. Если в конфигурациях маршрутизаторов эти параметры не согласованы, откорректируйте конфигурации маршрутизаторов, чтобы привести все маршрутизаторы в согласованное состояние.
Шаг 4. Если описанные выше действия не позволяют устранить нарушение в работе, переведите маршрутизатор с неправильной конфигурацией в режим обнаружения, задав команду конфигурации интерфейса appletalk address 0.0 в нерасширенной сети или команду appletalk cable-range 0-0 в расширенной сети. Эта команда вынуждает маршрутизатор получить информацию о конфигурации от сети.
Дополнительная информация о несоответствиях конфигураций приведена выше, в разделе “Несоответствия конфигураций AppleTalk"
В спецификациях AppleTalk не предусмотрен способ автоматического обновления таблиц ZIP после корректировки данных о том, какие имена зон соответствуют сетевым номерам или кабельным диапазонам.
Например, если зона для сети с номером 200 имеет имя Twilight Zone, но принято решение изменить это имя на No Parking Zone, то имя зоны может быть изменено в интерфейсе и станет известно в местном масштабе.
Проблема
Решение
Но если сеть с номером 200 не будет отключена от объединенной сети на достаточно продолжительное время, чтобы информация о ней была полностью удалена из таблиц маршрутизации по давности использования, то в некоторых маршрутизаторах будет по-прежнему использоваться старое имя зоны (такое явление называется “фантомной” зоной). В качестве альтернативы, если не существует возможности отключить данную сеть от объединенной сети на достаточно продолжительное время, при изменении имени зоны кабеля следует также изменить соответствующий сетевой номер.
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Проверьте, какие сетевые номера заданы в конфигурации для каждого интерфейса AppleTalk.
Шаг 2. Убедитесь в том, что в конфигурации отсутствуют сетевые номера, ранее назначенные зоне, которая была удалена. Измените кабельный диапазон с помощью команды конфигурации интерфейса appletalk cable-range или отключите сеть на такое время, чтобы информация о ней была удалена по давности использования из таблиц маршрутизации.
Шаг 3. Воспользуйтесь командой show appletalk zones, чтобы убедиться в том, что эта зона больше не появляется в списке зон
AppleTalk: происходит разрыв соединений со службами
Признак неисправности. Пользователи сообщают, что проводимые ими сеансы работы в сети AppleTalk внезапно разрываются без видимых причин.
В табл. 9.8 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
кТаблица 9.8. AppleTalk: происходит разрыв соединений со службами]
Проблема
Решение
Самопроизвольное изменение маршрута (непостоянство маршрута)
При чрезмерном объеме трафика в объединенных сетях со многими маршрутизаторами возникают ситуации, при которых некоторые маршрутизаторы не имеют возможности отправлять обновления RTMP через каждые 10 секунд, как это требуется. Поскольку маршрутизаторы начинают удалять маршруты по давности использования после пропуска двух последующих обновлений RTMP, то нерегулярное поступление обновлений RTMP может привести к постоянным изменениям маршрутов.
Шаг 1. Воспользуйтесь exec-командой show interfaces для проверки объема трафика. Проверьте нагрузку для каждого интерфейса.
Ниже приведен пример вывода команды show interfaces.
EthernetO is up, line protocol is up
Hardware is Lance, address is 0000.0c32.49bl (bia
0000.0c32.49bl)
Internet address is 192.168.52.26/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usee, rely 255/
255, load 1/255
[...]
ПроблемаРешение
Поле load, отображаемое в выводе команды show interfaces, показывает относительную нагрузку на интерфейс в виде числителя дроби со знаменателем 255 (где 255/255 соответствует полностью загруженному интерфейсу), рассчитанную как экспоненциальное среднее за время, превышающее 5 минут.
Шаг 2. Если нагрузка составляет меньше 50%, то для решения этой проблемы можно изменить значения установок таймера в составе конфигурации, отведя больше времени на распространение обновлений RTMP по сети.
Если же нагрузка превышает 50%, то может потребоваться сегментировать сеть, чтобы уменьшить число маршрутизаторов (и поэтому уменьшить объем трафика) в каждом сетевом сегменте.
Шаг 3. Воспользуйтесь привилегированной exec-командой debug apple events, чтобы определить, не происходит ли недопустимое удаление маршрутов по давности использования. Вывод этой команды должен выглядеть примерно так: Routeridebug apple events AppleTalk Events debugging is on Routeri %AT-6-PATHN0TIFY: EthernetO: AppleTalk RTMP path to 250250 down; reported bad by 200.41
Предостережение. При распределении процессорного времени процессу формирования отладочного вывода присваивается один из самых высоких приоритетов, поэтому система может стать непригодной для выполнения обычной работы. По этой причине команды debug должны применяться только для диагностики конкретных проблем или проведения сеансов поиска неисправностей с участием сотрудников службы технической поддержки Cisco. Кроме того, команды debug следует использовать в период сокращения сетевого трафика и уменьшения количества пользователей. Это снижает вероятность того, что дополнительные издержки, связанные с выполнением команды debug, нарушат нормальную эксплуатацию системы.
Шаг 4. Если удаление маршрутов по давности использования происходит неправильно, для устранения этого нарушения в работе сети примените глобальную команду конфигурации appletalk timers. Для начала можно предложить использовать установки таймера 10, 30 и 90, но они не должны превышать значений 10, 40 и 120. Первое число всегда должно быть равно 10, а третье число должно в три раза превышать второе.
Чтобы снова установить значения таймера, предусмотренные по умолчанию (10, 20, 60), воспользуйтесь глобальной командой конфигурации no appletalk timers.
Для всех таймеров в объединенной сети или, как минимум, для всех таймеров в опорной сети объединенной сети необходимо неуклонно устанавливать одно и то же значение
AppleTalk: все попытки инициализировать маршрутизацию AppleTalk в интерфейсе оканчиваются неудачей
Признак неисправности. Все попытки инициализировать программное обеспечение AppleTalk в интерфейсе маршрутизатора, подключенном к сети, оканчиваются неудачей.
В табл. 9.9 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 9.9. AppleTalk: все попытки инициализировать маршрутизацию .AppleTalk в интерфейсе оканчиваются неудачей
ПроблемаРешение
Несоответствие Шаг 1. Вызовите на выполнение exec-команду show appletalk interfaces, конфигурацийПроверьте наличие в результатах этой команды сообщения "port
configuration mismatch".
Если вывод команды содержит сообщение "mismatch", это означает, что конфигурация данного маршрутизатора не согласована с конфигурацией смежного устройства, указанного в сообщении.
Если в выводе команды отсутствует сообщение "mismatch", вызовите на выполнение привилегированную exec-команду clear apple interface в рассматриваемом интерфейсе. Если после выполнения команды очистки clear интерфейс становится функционирующим, это означает, что несоответствия конфигураций не существует.
Шаг 2. Снова введите exec-команду show appletalk interfaces. Если вывод этой команды все еще содержит сообщение "port configuration mismatch", убедитесь в том, что в конфигурациях всех маршрутизаторов согласованы между собой сетевой номер или кабельный диапазон, а также зона или список зон.
Шаг 3. Если в конфигурациях маршрутизаторов эти параметры не согласованы, откорректируйте конфигурации маршрутизаторов, чтобы привести все маршрутизаторы в согласованное состояние.
Шаг 4. Если описанные выше действия не позволяют устранить нарушение в работе, переведите маршрутизатор с неправильной конфигурацией в режим обнаружения, задав команду конфигурации Интерфейса appletalk address 0.0 в нерасширенной сети или команду appletalk cable-range 0-0 в расширенной сети. Эта команда вынуждает маршрутизатор получить информацию о конфигурации от сети.
Дополнительная информация о несоответствиях конфигураций приведена выше, в разделе “Несоответствия конфигураций AppleTalk"
Нарушения пра- Шаг j. Воспользуйтесь привилегированной exec-командой show appletalk вил версий Phaseglobals, чтобы определить, находится ли объединенная сеть в ре-
1 и Phase 2 жиме совместимости.
Шаг 2. Разрешите применение глобальной команды конфигурации appletalk name-lookup-interval и воспользуйтесь привилегированной exec-командой show appletalk neighbors, чтобы определить, какое именно смежное устройство (заданное по имени NBP) находится в режиме совместимости.
РешениеРешениеПроблема
Решение
Решение
Шаг 3. Для решения данной проблемы можно выполнить одно из следующих действий.
Замените программное обеспечение маршрутизаторов AppleTalk версии Phase 1 программным обеспечением AppleTalk версии Phase 2 и откорректируйте конфигурацию объединенной сети.
Убедитесь в том, что все маршрутизаторы функционируют в соответствии с правилами версий Phase 1 и Phase 2.
Дополнительная информация о том, в чем состоят нарушения правил версий Phase 1 и Phase 2, приведена выше, в разделе “Нарушения правил версий Phase 1 и Phase 2’’
AppleTalk: порт не выходит из режима перезапуска или сбора информации о конфигурации
Признак неисправности. Порт маршрутизатора не выходит из режима перезапуска или сбора информации о конфигурации (как показывает вывод привилегированной exec-команды show apple interfaces). Маршрутизатор не способен обнаруживать маршруты или передавать запросы на получение информации о конфигурации смежным устройствам в сегменте, к которому он подключен.
В табл. 9.10 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 9.10. AppleTalk: порт не выходит из режима перезапуска или сбора информации о конфигураций -
РешениеРешениеПроблема
Решение
Решение
Маршрутизатор находится в режиме обнаружения, и в сети отсутствует исходный маршрутизаторМаршрутизатор находится в режиме обнаружения, и в сети отсутствует исходный маршрутизаторПерекрестные последовательные соединения при наличии нескольких линий связи между двумя маршрутизаторамиПерекрестные последовательные соединения при наличии нескольких линий связи между двумя маршрутизаторамиШаг 1. Переведите маршрутизатор в режим необнаружения, присвоив сетевой номер или кабельный диапазон рассматриваемому интерфейсу с помощью команды конфигурации интерфейса appletalk address или appletalk cable-range.
Маршрутизатор находится в режиме обнаружения, и в сети отсутствует исходный маршрутизатор
Маршрутизатор находится в режиме обнаружения, и в сети отсутствует исходный маршрутизатор
Перекрестные последовательные соединения при наличии нескольких линий связи между двумя маршрутизаторами
Перекрестные последовательные соединения при наличии нескольких линий связи между двумя маршрутизаторами
Шаг 2. Если описанные выше действия не позволяют устранить нарушения в работе, обратитесь за помощью к представителю службы технической поддержки
Шаг 1. Проверьте электрические соединения последовательных линий, чтобы убедиться в том, что проводная разводка этих линий выполнена правильно.
Шаг 2. В случае необходимости снова выполните проводную разводку линий и проверьте результаты выполнения команд show interfaces и show appletalk interfaces для подтверждения то, что интерфейс и протокол линии связи находятся в работоспособном состоянии.
Шаг 3. Если маршрутизатор все еше не может находить маршруты, обратитесь за помощью к представителю службы технической поддержки
Проблема
Решение
Нарушение в работе программных средств
Если маршрутизатор выдает сообщение со словами "restart port pending", обновите его программное обеспечение, перейдя на новейший выпуск исправленной версии системного программного обеспечения или обратитесь к представителю службы технической поддержки
AppleTalk Enhanced IGRP: клиенты не могут подключиться к серверам
Признак неисправности. Клиенты Macintosh не могут подключиться к серверам в среде сети AppleTalk Enhanced IGRP.
В табл. 9.11 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
g Таблица 9.11. AppleTalk Enhanced IGRP: клиенты не могут подключиться j к серверам;
Маршрутизаторы не устанавливают связь со смежными устройствами должным образомВ таблице маршрутизации отсутствуют маршруты Применение протокола AppleTalk Enhanced IGRP разрешено в сети с подключенными к ней компьютерами MacintoshМаршрутизаторы не устанавливают связь со смежными устройствами должным образомВ таблице маршрутизации отсутствуют маршруты Применение протокола AppleTalk Enhanced IGRP разрешено в сети с подключенными к ней компьютерами MacintoshПроблемаРешение
Маршрутизаторы не устанавливают связь со смежными устройствами должным образом
В таблице маршрутизации отсутствуют маршруты Применение протокола AppleTalk Enhanced IGRP разрешено в сети с подключенными к ней компьютерами Macintosh
Маршрутизаторы не устанавливают связь со смежными устройствами должным образом
В таблице маршрутизации отсутствуют маршруты Применение протокола AppleTalk Enhanced IGRP разрешено в сети с подключенными к ней компьютерами Macintosh
AppleTalk Enhanced IGRP: в маршрутизаторах не формируются таблицы смежных устройств
Признак неисправности. В маршрутизаторах AppleTalk Enhanced IGRP не формируются таблицы смежных устройств. Подключенные маршрутизаторы не появляются в таблице смежных устройств.
В табл. 9.12 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
г Таблица 9.12. AppleTalk Enhanced IGRP: в маршрутизаторахJ
! . ; не формируются таблицы смежных устройств<
Проблема
Решение
Не выполнена глобальная настройка конфигурации протокола AppleTalk Enhanced IGRP в соответствующих маршрутизаторах
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig, чтобы проверить конфигурацию маршрутизаторов, в которых должно эксплуатироваться программное обеспечение Enhanced IGRP. Найдите записи глобальной команды конфигурации appletalk routing eigrp. Эта команда разрешает применение маршрутизации AppleTalk Enhanced IGRP в маршрутизаторе.
Шаг 2. Если в маршрутизаторе не разрешено применение маршрутизации AppleTalk Enhanced IGRP, разрешите ее с помощью глобальной команды конфигурации appletalk routing eigrp router-id.
Убедитесь в том, что идентификатор маршрутизатора является уникальным в пределах всей сети.
Шаг 3. Выполните такие же действия во всех прочих маршрутизаторах, в которых должно эксплуатироваться программное обеспечение AppleTalk Enhanced IGRP. Каждый маршрутизатор должен иметь уникальный идентификатор маршрутизатора
В интерфейсах не разрешено применение протокола AppleTalk Enhanced IGRP
Вызовите на выполнение привилегированную exec-команду show runningconfig в маршрутизаторах, в которых эксплуатируется программное обеспечение Enhanced IGRP. Проверьте наличие в конфигурациях интерфейсов записей команды конфигурации интерфейса appletalk protocol eigrp. Эта команда должна присутствовать в составе конфигурации, чтобы интерфейс мог генерировать hello-сообщения протокола AppleTalk Enhanced IGRP и обновления маршрутов
Не согласованы установки таймера
Шаг 1. Вызовите на выполнение exec-команду show appletalk eigrp neighbors. Убедитесь в том, что в выводе этой команды показаны все непосредственно подключенные маршрутизаторы AppleTalk Enhanced IGRP.
Шаг 2. Проверьте в результатах выполнения команды show appletalk eigrp neighbors значение поля uptime. Если этот счетчик рабочего времени постоянно сбрасывается, это означает, что hello-пакеты от смежного маршрутизатора поступают нерегулярно. Причиной этого может быть несоответствие установок таймера или нарушения в работе аппаратных средств.
ПроблемаПроблемаРешениеРешение
Проблема
Проблема
Решение
Решение
Шаг 3. Воспользуйтесь exec-командой show interfaces, чтобы определить, находятся ли интерфейс и протокол линии связи в работоспособном состоянии. Определите, не указаны ли большие значения в полях с размерами очереди и не слишком ли велико количество уничтожаемых пакетов. Поля queue с характеристиками очереди показывают максимальный размер очереди и количество пакетов, уничтоженных из-за переполнения очереди.
Если велико число уничтоженных пакетов, много пакетов присутствует в очереди либо интерфейс или протокол линии связи находится в нерабочем состоянии, то, вероятно, имеет место нарушение в работе интерфейса или других аппаратных средств. Дополнительная информация об устранении нарушений в работе аппаратных средств приведена в главах 3 и 15.
Шаг 4. Вызовите на выполнение привилегированную exec-команду show running-config во всех маршрутизаторах AppleTalk Enhanced IGRP сети. Найдите записи команды конфигурации интерфейса appletalk eigrp-timers. Значения, введенные в конфигурацию с помощью этой команды, должны быть одинаковыми во всех маршрутизаторах AppleTalk Enhanced IGRP сети.
Шаг 5. Если в некоторых маршрутизаторах имеются иные по сравнению с другими маршрутизаторами установки таймера, откорректируйте их конфигурацию в соответствии с остальными маршрутизаторами в сети. Этим установкам можно вернуть значения, предусмотренные по умолчанию, с помощью команды конфигурации интерфейса no appletalk eigrp-timers
Старая версия программного обеспечения Cisco IOSСтарая версия программного обеспечения Cisco IOSЕсли описанные выше нарушения в работе не удается устранить, перейдите на новейшую версию программного обеспечения Cisco IOS
Старая версия программного обеспечения Cisco IOS
Старая версия программного обеспечения Cisco IOS
AppleTalk Enhanced IGRP: в таблице маршрутизации отсутствуют маршруты
Признак неисправности. В таблицах маршрутизации маршрутизаторов, в которых эксплуатируется программное обеспечение AppleTalk Enhanced IGRP, отсутствуют маршруты. Клиенты (компьютеры Macintosh) в одной сети не могут получить доступ к серверам в другой сети. Клиенты могут иметь или не иметь возможность подключиться к серверам в той же сети. Эта проблема может возникать в объединенных сетях, в которых применяется только протокол Enhanced IGRP, или в объединенных сетях, в которых эксплуатируются протоколы Enhanced IGRP и RTMP.
В табл. 9.13 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
| Таблица 9.13. AppleTalk Enhanced IGRP: в таблице маршрутизации отсутствуют маршруты
Проблема
Решение
Маршрутизаторы не устанавливают связь со смежными устройствами должным образом
В интерфейсах не разрешено применение протокола AppleTalk Enhanced IGRP
Рекомендации по устранению этого нарушения в работе приведены выше, в разделе “AppleTalk Enhanced IGRP: в маршрутизаторах не формируются таблицы смежных устройств"
Вызовите на выполнение привилегированную ехес-команду show running-config в маршрутизаторах, в которых эксплуатируется программное обеспечение Enhanced IGRP. Проверьте наличие в конфигурациях интерфейсов записей команды конфигурации интерфейса appletalk protocol eigrp.
Эта команда должна присутствовать в составе конфигурации, чтобы интерфейс мог генерировать hello-сообшения протокола AppleTalk Enhanced IGRP и обновления маршрутов
Старая версия программного обеспечения Cisco IOS
Если описанные выше нарушения в работе не удается устранить, перейдите на новейшую версию программного обеспечения Cisco IOS
AppleTalk Enhanced IGRP: низкая производительность
Признак неисправности. Производительность сети в среде AppleTalk Enhanced IGRP является слишком низкой. Соединения между клиентами и серверами работают медленно или являются ненадежными.
В табл. 9.14 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 9.14. AppleTalk Enhanced IGRP: низкая производительность
Проблема
Решение
В одном и том же интерфейсе одновременно эксплуатируются протоколы AppleTalk Enhanced IGRP и RTMP
Вызовите на выполнение привилегированную ехес-команду show running-config в сетевых маршрутизаторах. Проверьте конфигурации интерфейсов, чтобы определить, не разрешено ли применение в одном и том же интерфейсе и протокола AppleTalk Enhanced IGRP, и протокола RTMP.
Если в одном и том же интерфейсе эксплуатируется и протокол AppleTalk Enhanced IGRP, и протокол RTMP, то потребляется значительная часть пропускной способности, а также увеличивается нагрузка процессора. Определите, нужно ли эксплуатировать в этом интерфейсе оба протокола маршрутизации, и запретите применение одного из них, если это возможно
Старая версия программного обеспечения Cisco IOS
Если описанные выше нарушения в работе не удается устранить, перейдите на новейшую версию программного обеспечения Cisco IOS
AppleTalk Enhanced IGRP: маршрутизатор не выходит из активного режима
Признак неисправности. Маршрутизатор AppleTalk Enhanced IGRP не выходит из активного режима. Маршрутизатор регулярно отправляет на консоль примерно такие сообщения об ошибках:
[4DUAL-3-SIA: Route 2.24 Stuck-in-Active]
Примечание
Появление время от времени сообщений такого типа не должно служить причиной для беспокойства. Дело в том, что маршрутизатор Enhanced IGRP именно таким образом дает знать о том, что он не получил ответы на свои запросы от всех своих смежных устройств. Но если эти сообщения об ошибках появляются часто, необходимо диагностировать описанную проблему.
Активный режим Enhanced IGRP подробно описан ниже, в разделе “Активные/ пассивные режимы Enhanced IGRP”.
В табл. 9.15 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
1 Таблица 9.15. AppleTalk Enhanced IGRP: маршрутизатор не выходит
из активного режима
Проблема
Решение
Неправильная
Активный таймер определяет максимальную продолжительность времени,
настройка
в течение которого маршрутизатор Enhanced IGRP должен ожидать отве-
установки
тов на свои запросы. Если установка активного таймера является слиш-
активного
ком низкой, то может не хватить времени на то, чтобы все смежные
таймера
маршрутизаторы передали свои ответы активному маршрутизатору.
Шаг 1. Проверьте с помощью привилегированной exec-команды show running-config конфигурацию каждого маршрутизатора Enhanced IGRP. Найдите запись команды конфигурации маршрутизатора timers active-time, связанную с записью глобальной команды конфигурации appletalk routing eigrp.
Шаг 2. Значение, установленное командой timers active-time, должно быть одинаковым во всех маршрутизаторах одной и той же автономной системы. Настоятельно рекомендуется установить значение 3 (3 минуты — значение, применяемое по умолчанию), которое дает возможность всем смежным маршрутизаторам Enhanced IGRP ответить на запросы
Нарушение в
Шаг 1. Если передача и прием запросов и ответов не происходит долж-
работе интер-
ным образом, то истекают установки активного таймера, в ре-
фейса или дру-
зультате чего маршрутизатор выдает сообщение об ошибке. Вызо-
гих аппаратных
вите на выполнение exec-команду show appletalk eigrp neighbors
средств
и проверьте в результатах значения полей uptime (продолжительность работы) и Q Cnt (сокращение от queue count — количество сообщений в очереди).
Проблема
Решение
Ниже приведен пример вывода команды show appletalk eigrp neighbors.
Routerfshow appletalk eigrp neighbor
AT/EIGRP Neighbors for process 1, router id 1
H AddressInterface Hold Uptime SRTT RTO Q Seq
(sec)(ms)Cnt Num
0200.41EtO10 0:00:370 3000 0 2
Если счетчик рабочего времени постоянно переустанавливается или количество сообщений в очереди неизменно остается высоким, такая ситуация может быть связана с нарушением в работе аппаратных средств. В поле uptime приведено значение (в часах, минутах и секундах) времени, истекшего с того момента, как информация о данном локальном маршрутизаторе быта впервые получена его смежным устройством.
Шаг 2. Определите причину неисправности, проверив наличие в результатах выполнения команды сообщения об ошибке "Stuck-in-Active", которое указывает адрес AppleTalk узла с нарушениями в работе.
Шаг 3. Убедитесь в том, что маршрутизатор, который может служить причиной неисправностей, все еще находится в рабочем состоянии. Проверьте интерфейсы рассматриваемого маршрутизатора. Проверьте, находятся ли в рабочем состоянии интерфейс и протокол линии связи, и определите, уничтожаются ли пакеты в этом интерфейсе.
Дополнительная информации об устранении нарушений в работе аппаратных средств приведена в главе 3
Самопроизвольно изменяющийся маршрут
Если в сети наблюдается самопроизвольное изменение последовательного маршрута (вызванное слишком большим объемом трафика), то надежное перенаправление запросов и ответов может стать невозможным. Самопроизвольное изменение маршрутов, вызванное большим объемом трафика в последовательном канале, может привести к потере запросов и ответов, в результате чего будет наблюдаться истечение установок активного таймера.
Примите меры по уменьшению объема трафика в канале или увеличению пропускной способности канала
Старая версия программного обеспечения Cisco IOS
Если описанные выше нарушения в работе не удается устранить, перейдите на новейшую версию программного обеспечения Cisco IOS
Активные/пассивные режимы Enhanced IGRP
Маршрутизатор Enhanced IGRP может находиться либо в пассивном, либо в активном режиме. Маршрутизатор называется пассивным по отношению к сети, если в его таблице маршрутизации установлен путь к этой сети. Маршрутизатор находится в активном состоянии, если в нем происходит повторное вычисление маршрута. Если в пути к требуемой сети всегда имеются смежные устройства, от которых маршрутизатор может получить необходимую информацию, он никогда не переходит в активное состояние и в нем не происходит повторное вычисление маршрута.
Если маршрутизатор Enhanced IGRP теряет соединение с какой-либо сетью, он становится активным по отношению к этой сети. Маршрутизатор рассылает запросы по всем
своим смежным устройствам для поиска нового маршрута к сети. Маршрутизатор остается в активном режиме до тех пор, пока не получит ответы от всех своих смежных устройств или не истечет установка активного таймера, которая определяет максимальную продолжительность времени пребывания маршрутизатора в активном состоянии.
Если маршрутизатор получает ответы от всех своих смежных устройств, он вычисляет новое значение следующего участка маршрута к этой сети и становится пассивным по отношению к этой сети. Но если установка активного таймера истекает, маршрутизатор удаляет из своей таблицы смежных устройств все смежные устройства, не приславшие ответы, снова входит в активный режим и выдает на консоль сообщение "Stuck-in-Active".
AURP: маршруты не распространяются через туннель AURP
Признак неисправности. Маршруты AppleTalk не распространяются через туннель AURP. Маршруты, которые, как известно, существуют на одном конце туннеля, не появляются в таблицах маршрутизации внешнего маршрутизатора на другом конце туннеля. Внешний маршрутизатор на другом конце туннеля не получает информации об изменениях в удаленной сети (например, о закрытии какого-либо маршрута).
В табл. 9.16 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
{ таблица 9.16. AURP: маршруты не распространяются через туннель AURP j
Проблема
Решение
Неправильно настроена конфигурация туннеля AURP
Шаг 1. Вызовите на выполнение exec-команду show appletalk interfaces, чтобы убедиться в том, что интерфейс туннеля находится в работоспособном состоянии.
Шаг 2. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Проверьте записи команды конфигурации интерфейса tunnel source и tunnel destination.
Шаг 3. Выполните настройку интерфейсов туннеля внешних маршрутизаторов с помощью команд tunnel source и tunnel destination. Убедитесь в том, что в команде tunnel destination каждого маршрутизатора указан IP-адрес интерфейса туннеля удаленного внешнего маршрутизатора
Отсутствие команды appletalk routeredistribution
Шаг 1. Если информация об изменениях в удаленной сети не передается по туннелю, воспользуйтесь привилегированной ехес-командой show running-config для просмотра информации о конфигурации маршрутизатора. Проверьте наличие записи глобальной команды конфигурации appletalk route-redistribution.
Шаг 2. Если запись этой команды отсутствует, введите ее в конфигурацию
Нарушения в работе базовой сети 1Р
Если возникают нарушения в работе службы маршрутизации транзитной сети (сети IP, через которую проходит туннель AURP), то при прохождении трафика AppleTalk через туннель могут возникать трудности.
При устранении нарушений в работе в сети TCP/IP руководствуйтесь рекомендациями главы 7
FDDITalk: с маршрутами не связана ни одна зона
Признак неисправности. В маршрутизаторах в кольце FDDI имеется информация о маршрутах ко всем сетям данного кольца, но с маршрутами не связана ни одна зона. В результатах выполнения команды show appletalk route для этих маршрутов указано "no zone set".
Примечание
В другой передающей среде маршруты без установленных зон возникают под воздействием других нарушений в работе, таких как лавинообразное увеличение количества пакетов ZIP. Дополнительная информация приведена в разделах “AppleTalk: в программе Chooser отсутствует информация о зонах” и “AppleTalk: периодически нарушается доступ к сетевым службам” этой главы.
В табл. 9.17 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
( Таблица 9.17. FDDITalk: с маршрутами несвязана ни одна зона:
Проблема
Решение
Несоответствие версий программного обеспечения FDDITalk
Если в каком-либо из маршрутизаторов в объединенной сети используются выпуски программного обеспечения, предшествующие версии Cisco IOS 10.0, то существует вероятность несоответствия применяемых в разных маршрутизаторах версий программного обеспечения AppleTalk, предназначенного для работы в сети FDD1. Убедитесь в том, что во всех маршрутизаторах кольца применяется либо программное обеспечение, предшествующее выпуску версии протокола FDDITalk (сокращенно называемое программным обеспечением pre-FDDITalk), либо программное обеспечение FDDITalk, а не то и другое.
Ниже описаны реализации программного обеспечения FDDITalk для каждого выпуска системного программного обеспечения.
В выпусках программного обеспечения, предшествующих 9.0(2), предусмотрено применение в маршрутизаторах только версий pre-FDDITalk.
В выпусках программного обеспечения, предшествующих версии Cisco 1OS 10.0, предусмотрено применение в маршрутизаторах только версий FDDITalk.
Но если при этом в сети FDD1 имеется хоть один маршрутизатор pre- FDDITalk, то все маршрутизаторы переходят на версию pre-FDDITalk. Маршрутизатор может быть принудительно переведен в режим поддержки FDDITalk с помощью команды конфигурации интерфейса по appletalk pre-fdditalk.
В выпусках программного обеспечения Cisco IOS 10.0 и более поздних версий по умолчанию применяется реализация Apple FDDITalk.
Тем не менее любой маршрутизатор может быть принудительно переведен в режим поддержки pre-FDDITalk с помощью команды конфигурации интерфейса appletalk pre-fdditalk
ARA: клиент ARA не способен подключиться к серверу ARA
Признак неисправности. Клиент ARA (типа Macintosh) предпринимает попытку подключиться к серверу ARA (такому как сервер доступа Cisco) и не может инициализировать сеанс удаленного доступа. Иногда пользователь получает возможность подключиться на короткое время, но соединение вскоре обрывается.
В табл. 9.18 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
! Таблица 9.18. ARA: клиент ARA не способен подключиться к серверу ARA ;
Проблема
Решение
Отсутствие записи команды arap network
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Если в маршрутизаторе эксплуатируется программное обеспечение Cisco IOS 10.2 или более поздней версии, найдите запись глобальной команды конфигурации arap network.
Шаг 2. Выполните настройку глобальной команды конфигурации агар network, чтобы разрешить применение протокола ARAP в маршрутизаторе или сервере доступа. Синтаксическая структура команды arap network приведена ниже.
arap network [network-number] [zone-name]
Описание синтаксической структуры
network-number. (Необязательный параметр.) Сетевой номер AppleTalk. Сетевой номер должен быть уникальным во всей сети AppleTalk. Именно в этой сети происходит регистрация всех пользователей протокола ARAP (AppleTalk Remote Access Protocol — протокол удаленного доступа AppleTalk) после установления входящего коммутируемого соединения с сетью.
zone-name. (Необязательный параметр.) Имя зоны AppleTalk
Маршрутизация AppleTalk не разрешена в соответствующих интерфейсах
Шаг 1. Воспользуйтесь exec-командой show apple interfaces, чтобы определить, находятся ли интерфейсы в рабочем состоянии и разрешена ли маршрутизация AppleTalk в тех интерфейсах, где это необходимо.
Шаг 2. Если маршрутизация AppleTalk не разрешена в тех интерфейсах, где это необходимо, разрешите ее применение соответствующим образом. Дополнительная информация о настройке интерфейсов для маршрутизации AppleTalk приведена в документе Cisco IOS Network Protocols Configuration Guide, Part 1
Нарушения в работе модема, последовательной линии или аппаратных средств
Информация об устранении нарушений в работе последовательной линии приведена в главе 15, об устранении нарушений в работе модема — в главе 16, об устранении нарушений в работе аппаратных средств — в главе 3
ARA: соединение зависает после поступления сообщения "Communicating At..."
Признак неисправности. Клиент ARA (например, компьютер Macintosh) пытается подключиться к серверу ARA (такому как сервер доступа Cisco) через клиентский и серверный модемы. Клиент получает сообщение о подключении, такое как "Communicating at 14.4 Kbps", но затем зависает на 10-30 секунд и, наконец выводит сообщение "connection failed".
В табл. 9.19 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем. •~- ■■ ■■■
: Таблица 9.19. ARA: соединение зависает после поступления сообщения , |"Communicating At..."
ПроблемаРешение
На пакеты запроса канала MNP4, передаваемые клиентским стеком ARA, отвечает обслуживающий модем, а не сервер ARAНа пакеты запроса канала MNP4, передаваемые клиентским стеком ARA, отвечает обслуживающий модем, а не сервер ARAШаг 1. Проверьте номера версий программного обеспечения ARA на клиенте и программного обеспечения Cisco 1OS на сервере доступа.
На пакеты запроса канала MNP4, передаваемые клиентским стеком ARA, отвечает обслуживающий модем, а не сервер ARA
На пакеты запроса канала MNP4, передаваемые клиентским стеком ARA, отвечает обслуживающий модем, а не сервер ARA
Если применяется версия 1.0 программного обеспечения АВА или версия программного обеспечения Cisco IOS, предшествующая 10.2, то рекомендуется перейти на версию АВА 2.0 и Cisco 1OS 10.2 или на одну из последующих версий. В версии АВА 2.0 применяется другой алгоритм оформления пакетов запроса канала MNP4 в виде фреймов, и на эти запросы не отвечает обслуживающий модем.
Шаг 2. Если возможность модернизировать программное обеспечение отсутствует, попытайтесь изменить правила работы модема, чтобы в нем применялся способ смены протокола исправления ошибок с переходом от протокола LAPM к режиму работы без протокола (сокращенно обозначается LAPM-to-No) вместо способа, предусматривающего переход от LAPM к MNP4, а затем — в режим работы без протокола (сокращенно обозначается LAPM-to-MNP4-to-No). После этого модем перестанет принимать сообщения MNP4 и отвечать на них, что позволит пакетам MNP4 достичь сервера доступа.
Примечание. Во многих типах модемов не предусмотрена возможность корректировки конфигурации подобным образом.
Шаг 3. Если в конкретном модеме не используется протокол исправления ошибок LAPM, то еще один вариант может предусматривать корректировку всех сценариев клиента ARA и увеличение паузы, устанавливаемой перед выходом из сценария, до 500 мс. Внесите в конфигурацию дополнительную задержку, которая учитывает правила работы обслуживающего модема
ARA: невозможно передавать или принимать данные по входящему коммутируемому соединению ARA
Признак неисправности. Соединения ARA устанавливаются, но пользователи не могут передавать или принимать данные ARA по этому каналу.
В табл. 9.20 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
| Таблица 9.20. ARA: невозможно передавать или принимать данные по входящему коммутируемому соединению ARA
Проблема
Решение
Отсутствует запись команды arap network
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Если в маршрутизаторе эксплуатируется программное обеспечение Cisco IOS 10.2 или более поздней версии, найдите запись глобальной команды конфигурации arap network.
Шаг 2. Выполните настройку глобальной команды конфигурации агар network, чтобы разрешить применение протокола ARAP в маршрутизаторе или сервере доступа. Синтаксическая структура команды arap network приведена ниже.
arap network [network-number] [zone-name]
Описание синтаксической структуры■
network-number. (Необязательный параметр.) Сетевой номер AppleTalk. Сетевой номер должен быть уникальным во всей сети AppleTalk. Именно в этой сети происходит регистрация всех пользователей протокола ARAP после установления входящего коммутируемого соединения с сетью.
zone-name. (Необязательный параметр.) Имя зоны AppleTalk
Отсутствует запись команды autoselect
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Определите, выполнена ли настройка команды конфигурации autoselect arap line в маршрутизаторе.
Шаг 2. Если эта команда отсутствует, введите ее в конфигурацию
В приемном модеме разрешено применение протокола исправления ошибок MNP5
Шаг 1. Выясните, разрешено ли применение в приемном модеме протокола исправления ошибок MNP5.
Шаг 2. Если в приемном модеме разрешено применение протокола MNP5, запретите его. Для получения дополнительной информации о проверке или корректировке конфигурации модема обратитесь к документации модема•
Список зон пуст
Шаг 1. Воспользуйтесь привилегированными exec-командами show appletalk route и show appletalk zones, чтобы определить, имеет ли маршрутизатор информацию о своих маршрутах и зонах ARA.
Шаг 2. Вызовите на выполнение exec-команду show appletalk interfaces ethernet и убедитесь в том, что ее результаты соответствуют параметрам сети AppleTalk.
Шаг 3. В случае необходимости откорректируйте конфигурацию интерфейса
Нарушение в работе системы TACACS
Информация об устранении нарушений в работе системы TACACS (Terminal Access Controller Access Control System — система управления доступом к контроллеру терминального доступа) приведена в главе 24
ARA: низкая производительность при передаче данных по входящему коммутируемому соединению
Признак неисправности. Низкая производительность удаленных входящих коммутируемых сеансов ARA.
В табл. 9.21 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
। Таблица 9.21. ARA: низкая производительность при передаче данных по ;
| 4 ■■ входящему коммутируемому соединению’
Проблема
Решение
Управление потоком данных не разрешено, разрешено только в одном устройстве (либо DTE, либо DCE) или неправильно настроено
Шаг 1. Выполните настройку конфигурации аппаратных средств управления потоком данных канала с помощью команды конфигурации канала flowcontrol hardware. Аппаратное управление потоком данных рекомендуется для соединений между сервером доступа и модемом.
Например, для настройки аппаратного управления потоком данных в канале 2 сервера доступа введите следующие команды: C2500(config)#line 2
С2500( config-line)# flowcontrol hardware
Примечание. Если нельзя использовать средства управления потоком данных, необходимо ограничить скорость канала значением 9600 бит/с. Применение более высоких скоростей может привести к потере данных.
Шаг 2. Разрешив применение аппаратного управления потоком данных в канале сервера доступа или маршрутизатора, инициализируйте обратный сеанс Telnet с модемом через этот канал.
Инструкции по инициализации обратного сеанса Telnet приведены в разделе "Установление обратного сеанса Telnet с модемом" главы 16.
Шаг 3. Введите строку команды модема, которая включает команду управления потоком данных RTS/CTS для конкретного модема. Эта команда позволяет обеспечить применение в модеме такого же метода управления потоком данных (т.е. аппаратного управления потоком данных), как и в сервере доступа или маршрутизаторе Cisco. Для получения точной информации о синтаксисе команды конфигурации обратитесь к документации модема.
Дополнительная информация об устранении нарушений в работе соединений между сервером доступа и модемом приведена в главе 16, а информация об устранении нарушений в работе аппаратных средств — в главе 3
Глава
10
Устранение нарушений в работе сети IBM ■
В настоящей главе в основном рассматриваются нарушения в работе, характеризующиеся отсутствием связи или снижением производительности, которые зависят от - правильного функционирования средств маршрутизации и мостового перенаправле- ; ния в сетях на основе технологии IBM. При поиске неисправностей в сетях на основе ; технологии IBM необходимо знать, как работает сеть SDLC (Synchronous Data Link ' Control — синхронное управление передачей данных), как осуществляется мостовое * перенаправление от отправителя (SRB — Source-Route Bridging) и как организована канальная коммутация (DLSw — Data-Link Switching). Основные сведения о средствах DLSw, SDLC и SRB приведены в следующих разделах.
Протокол DLSw
^Методы канальной коммутации были разработаны для обеспечения поддержки функционирования протоколов SNA и NetBIOS в мультипротокольных маршрутизаторах. SNA и NetBIOS фактически представляют собой протоколы с установлением логического соединения, поэтому в этих протоколах для управления передачей дан- -дЩЫХ в локальной сети применяются средства управления логической связью LLC (Logical Link Control) типа 2 по стандарту IEEE 802.2. Канальная коммутация обеспечивает также применение протоколов SNA в каналах распределенной сети с помощью протокола SDLC. Дополнительная информация о протоколе DLSw приведена в документе RFC 1795, в котором определен этот протокол.
Для получения дополнительной информации об устранении нарушений в работе протокола DLSw обратитесь к оперативному руководству DLSw Troubleshooting Guide по адресу www.cisco.com/warp/customer/697/dlswtsl.html.
Протокол SDLC
* Протокол SDLC был разработан корпорацией IBM в середине 1970-х годов для использования в среде SNA. Протокол SDLC был первым из нового семейства протоколов канального уровня, основанных на синхронных бит-ориентированных средствах обмена данными. Синхронные бит-ориентированные протоколы являются более эф-
фективными, гибкими и во многих случаях более быстродействующими по сравнению с символьными протоколами (такими как Bisync корпорации IBM) и синхронными байт-ориентированными протоколами с контролем длины, например DDCMP (Digital Data Communications Message Protocol — протокол передачи информационных сообщений Digital) корпорации Digital Equipment Corporation.
После разработки протокол SDLC был представлен корпорацией IBM на рассмотрение нескольким организациям по стандартизации. Протокол SDLC не только показал свою высокую эффективность, но и послужил прототипом для создания новых версий протоколов. В частности, организацией ISO (International Organization for Standardization — Международная организация по стандартизации) на его основе был разработан протокол HDLC. В дальнейшем организацией ITU-T (International Telecommunication Union Telecommunication Standardization Sector — сектор стандартизации Международного телекоммуникационного союза) была проведена доработка протокола HDLC в целях создания протокола LAP (Link Access Procedure — процедура доступа к каналу), а затем протокола LAPB (Link Access Procedure, Balanced — сбалансированная процедура доступа к каналу). Протокол HDLC был также доработан организацией IEEE (Institute of Electrical and Electronic Engineers — Институт инженеров по электротехнике и электронике) для создания спецификации IEEE 802.2. Каждый из этих протоколов приобрел очень важное значение в своей области. А протокол SDLC остается протоколом канального уровня SNA для каналов распределенной сети.
Основы технологии
Протокол SDLC поддерживает целый ряд типов и топологий каналов. Он может применяться в каналах типа “точка-точка” и многоточечных каналах, в ограниченной и неограниченной передающей среде, полудуплексных и дуплексных средствах передачи, а также в сетях с коммутацией каналов и коммутацией пакетов.
В протоколе SDLC различаются сетевые узлы двух типов.
Первичный. Управляет функционированием других станций (называемых вторичными). Первичный узел опрашивает вторичные узлы в заранее определенном порядке. Затем вторичные узлы получают возможность выполнить передачу, если в них имеются исходящие данные. Первичный узел создает и уничтожает каналы, а также управляет каналами в процессе функционирования.
Вторичный. Действует под управлением первичного узла. Вторичные узлы могут передавать информацию только первичному узлу, но выполняют эту операцию исключительно с разрешения первичного узла.
Первичные и вторичные узлы SDLC соединяются между собой в виде четырех основных конфигураций.
Двухточечная. Включает только два узла — один первичный и один вторичный.
Многоточечная. Включает один первичный и несколько вторичных узлов.
Циклическая. Имеет циклическую топологию, в которой первичный узел подключен только к двум вторичным узлам — первому и последнему. Отвечая на запросы первичного узла, промежуточные вторичные узлы передают сообщения от одного к другому.
Радиально-кольцевая. Предусматривает применение входящего и исходящего каналов. В первичном устройстве исходящий канал служит для обмена данными с вторичными устройствами. Во вторичных устройствах входящий канал служит для обмена данными с первичным устройством. Во входящем канале применяется шлейфовое подключение к первичному устройству через каждое вторичное устройство.
Формат фрейма
Формат фрейма SDLC показан на рис. 10.1.
Длина поля
в байтах 11 или 21 или 2Переменная21
Флажок
Адрес
Управление
Данные
FCS
Флажок
X' Формат информационного ’*-.. фрейма
Порядковый номер принятого пакета
Конец опроса
Порядковый номер переданного пакета
0
Формат управляющего фрейма
Порядковый номер принятого пакета
Конец опроса
Код функции
0
1
Формат ненумерованного фрейма
Код функции
Конец опроса
Код функции
1
1
Рис. 10.1. Формат фрейма SDLC
Как показано на рис. 10.1, границы фреймов SDLC обозначены уникальной сигнальной последовательностью. Поле адреса всегда содержит адрес вторичного узла, который участвует в текущей операции связи. Поскольку первичный узел является либо отправителем, либо получателем передаваемых данных, во фрейм не нужно включать адрес первичного узла — он всегда известен всем вторичным узлам.
В поле управления используются три разных формата в зависимости от типа применяемого фрейма SDLC. Эти три типа фреймов SDLC описаны ниже.
Информационные фреймы (фреймы типа I — сокращение от Information). Эти фреймы передают информацию протокола верхнего уровня и некоторую управляющую информацию. Для управления потоком данных и исправления ошибок применяются порядковые номера переданных и принятых пакетов, а также бит P/F (Poll Final — конец опроса). В поле порядкового номера переданного пакета указан номер фрейма, который должен быть пе-
редан следующим. В поле порядкового номера принятого пакета указан номер фрейма, который должен быть получен следующим. За порядковыми номерами переданных и принятых пакетов следят и отправитель, и получатель. В первичном узле бит P/F применяется для передачи вторичному узлу указания на то, что от него требуется немедленный ответ. Во вторичном узле этот бит применяется для передачи первичному узлу указания на то, что текущий фрейм является последним в его текущем ответе.
Управляющие фреймы (фреймы типа S — сокращение от Supervisory). Эти фреймы содержат управляющую информацию. Они позволяют потребовать выполнения операции передачи данных и приостановить эту операцию, сообщить о состоянии и подтвердить передачу фреймов типа I. Эти фреймы не имеют поля информации.
Ненумерованные фреймы (фреймы типа U — сокращение от Unnumbered). Как указывает само их название, эти фреймы не упорядочены. Они применяются для управления. Например, эти фреймы используются для инициализации вторичных узлов. Поле управления ненумерованных фреймов может иметь длину 1 или 2 байта, в зависимости от назначения фрейма. Некоторые ненумерованные фреймы имеют поле информации.
Перед конечным сигнальным разделителем находится поле FCS. В этом поле, как правило, записывается результат вычисления CRC. Получатель обычно выполняет повторное вычисление CRC. Если полученный результат отличается от значения во фрейме, записанного отправителем, то предполагается, что фрейм принят с ошибками.
На рис. 10.2 приведена типичная конфигурация сети на основе протокола SDLC. Как показано на этом рисунке, контроллер установления связи сети IBM (который прежде именовался групповым контроллером) на удаленном участке сети подключается к терминалам ввода-вывода и к сети Token Ring. На локальном участке сети хост IBM подключается (с помощью средств подключения к каналу) к коммуникационному процессору (FEP — Front-End Processor) IBM, который может быть, в свою очередь, подключен к локальным сетям Token Ring и опорной сети SNA. Эти два участка сети соединены с помощью арендованного канала с пропускной способностью 56 Кбит/с, в котором применяется протокол SDLC.
Алгоритм SRB
Алгоритм SRB был разработан корпорацией IBM и предложен комитету IEEE 802.5 для применения в качестве средства мостового перенаправления, предназначенного для объединения любых локальных сетей. В последующем комитет IEEE 802.5 включил алгоритм SRB в спецификацию локальной сети IEEE 802.5 Token Ring.
Вслед за этим первоначальным предложением корпорация IBM представила комитету IEEE 802 новый стандарт мостового перенаправления — SRT (SourceRoute Transparent — прозрачное мостовое перенаправление от отправителя). Стандарт SRT предусматривает полный отказ от мостов, функционирующих исключительно на основе алгоритма SRB, и переход к применению мостов локальной сети двух типов: прозрачных мостов и мостов SRT. Стандарт мостового перенаправления SRT получил определенную поддержку, но в сетях все еще широко используются мосты SRB.
Локальный узел
ч Канал SDLC
Удаленный узел
Рис. 10.2. Типичная конфигурация сети, функционирующая на основе протокола SDLC
Основные сведения об алгоритме SRB
Алгоритм мостового перенаправления от отправителя SRB получил такое название потому, что он предусматривает размещение во всех фреймах, передаваемых отправителем из одной локальной сети в другую, полной информации о маршруте от отправителя к получателю. Мосты SRB накапливают и перенаправляют фреймы в соответствии с информацией о маршруте, находящейся в соответствующем поле фрейма. Пример сети SRB приведен на рис. 10.3.
Предположим, что в сети, приведенной на рис. 10.3, должна быть выполнена передача фрейма от хоста X к хосту Y. Первоначально хост X не имеет информации о том, находится ли хост Y в той же или в другой локальной сети. Для получения этой информации хост X отправляет проверочный фрейм. Если этот фрейм возвращается к хосту X без положительного подтверждения того, что обнаружен хост Y, то хост X должен в дальнейших действиях исходить из того, что хост Y находится в удаленном сегменте.
Для точного определения местонахождения хоста Y в удаленной сети хост X передает так называемый поисковый фрейм. Каждый мост, получивший поисковый фрейм (в данном примере мосты 1 и 2), отправляет копию фрейма во все исходящие порты. По мере прохождения поисковых фреймов по объединенной сети к ним добавляется информация о маршрутах. После того как поисковые фреймы,
отправленные хостом X, достигают хоста Y, последний отвечает на каждый из них отдельно с использованием накопленной информации о маршрутах. После получения всех фреймов с ответами хост X выбирает один из маршрутов на основе некоторых предопределенных критериев.
Рис. 10.3. Пример сети SRB
В примере, приведенном на рис 10.3, этот процесс приводит к получению информации о двух маршрутах.
Локальная сеть 1, мост 1, локальная сеть 3, мост 3, локальная сеть 2.
Локальная сеть 1, мост 2, локальная сеть 4, мост 4, локальная сеть 2.
Хост X должен выбрать один из этих двух маршрутов. Спецификация IEEE 802.5 не определяет критерии, которыми должен руководствоваться хост X при выборе маршрута, но в ней приведены некоторые рекомендации, в частности следующие.
Выбрать первый полученный фрейм.
Предпочесть ответ с минимальным количеством участков маршрута.
Выбрать ответ с наибольшим допустимым размером фрейма.
Применять всевозможные комбинации этих критериев.
В большинстве случаев применяется маршрут, содержащийся в первом полученном фрейме.
После выбора маршрута информация о нем вкладывается во фреймы, предназначенные для хоста Y, в виде поля маршрутной информации (RIF — Routing Information Field). Поле RJF входит в состав только тех фреймов, которые предназначены для передачи в другие локальные сети. Наличие маршрутной информации во фрейме обозначается путем
установки наиболее значимого бита в поле адреса отправителя, называемого битом индикатора маршрутной информации (RII — Routing Information Indicator).
Формат фрейма
Структура поля RIF по спецификации IEEE 802.5 показана на рис. 10.4.
Управление маршрутизациейДескриптор маршрутаДескриптор маршрутаУправление маршрутизациейДескриптор маршрутаДескриптор маршрутаТипДлинаDМаксимальная длинаНе используетсяТипДлинаDМаксимальная длинаНе используетсяРис. 10.4. Поле RTF по спецификации IEEE 802.5Рис. 10.4. Поле RTF по спецификации IEEE 802.5Номер кольцаНомер мостаНомер кольцаНомер моста
Управление маршрутизацией
Дескриптор маршрута
Дескриптор маршрута
Управление маршрутизацией
Дескриптор маршрута
Дескриптор маршрута
Тип
Длина
D
Максимальная длина
Не используется
Тип
Длина
D
Максимальная длина
Не используется
Рис. 10.4. Поле RTF по спецификации IEEE 802.5
Рис. 10.4. Поле RTF по спецификации IEEE 802.5
Номер кольца
Номер моста
Номер кольца
Номер моста
Адрес получателя
R I I
Адрес отправителя
RIF
Данные
FCS
Фрейм МАС 802.5
Ниже описаны поля, из которых состоит поле RIF.
Поле управления маршрутизацией, которое состоит из следующих подполей.
Подполе типа в поле RIF указывает, должен ли быть этот фрейм перенаправлен в один узел, в группу узлов, составляющих связующее дерево объединенной сети, или во все узлы. Фрейм первого типа называется фреймом поиска одного маршрута, фрейм второго типа — фреймом поиска связующего дерева, а фрейм третьего типа — фреймом поиска маршрутов. Фрейм поиска связующего дерева может использоваться в качестве механизма транзита для фреймов многоадресатной рассылки, а также служить для замены фрейма поиска маршрутов в исходящих запросах маршрута. В последнем случае намеченный получатель передает ответ с помощью фрейма поиска маршрутов.
Подполе длины указывает общую длину поля RIF в байтах.
Бит D обозначает направление передачи фрейма (прямое или обратное).
Подполе максимальной длины указывает максимальную длину фрейма, который может быть обработан при прохождении по этому маршруту.
Поле дескриптора маршрута может присутствовать в нескольких экземплярах. Каждое поле дескриптора маршрута содержит пару чисел (номер коль- ца/номер моста), которая обозначает определенную часть маршрута. Поэтому маршруты представляют собой просто чередующиеся последовательности номеров локальных сетей и мостов, которые начинаются и оканчиваются номерами локальных сетей.
Устранение нарушений в работе сети IBM
В настоящем разделе в основном рассматриваются нарушения в работе, характеризующиеся отсутствием связи или снижением производительности, которые зависят от правильного функционирования средств маршрутизации и мостового перенаправления в сетях на основе технологии IBM. Здесь описаны конкретные признаки неисправности в сети IBM, перечислены проблемы, которые могут вызвать появление каждого признака неисправности, и приведены решения этих проблем.
В данном разделе рассматриваются следующие наиболее распространенные нарушения в работе сети IBM.
Локальное перенаправление SRB: хост не может подключиться к серверу.
Локальное перенаправление SRB: не функционируют средства перенаправления.
RSRB: хост не может подключиться к серверу (одноранговые узлы не открыты).
RSRB: хост не может подключиться к серверу (одноранговые узлы открыты).
RSRB: периодические нарушения связи.
RSRB: клиент NetBIOS не может подключиться к серверу.
Мостовое перенаправление с трансляцией: клиент не может подключиться к серверу.
Мостовое перенаправление SRT: клиент не может подключиться к серверу.
SDLC: маршрутизатор не может обмениваться данными с устройством SDLC.
SDLC: отсутствие надежной связи.
SDLC: клиент не может подключиться к хосту через маршрутизатор, работающий под управлением программного обеспечения SDLLC.
SDLC: сеансы, установленные через маршрутизатор, работающий под управлением программного обеспечения STUN, оканчиваются аварийно.
CIP: не активизируется соединение CLAW.
CIP: не загорается светодиод Enabled.
CIP: интерфейсный процессор не переходит в оперативный режим работы с хостом.
CIP: маршрутизатор не может выполнить эхо-тестирование хоста или хост не может выполнить эхо-тестирование маршрутизатора.
CIP: хост не может установить связь с удаленными сетями.
CIP: хост, в котором функционирует демон routed, не имеет информации о маршрутах.
Локальное перенаправление SRB: хост не может подключиться к серверу
Признак неисправности. Попытки установить соединение через маршрутизатор, применяемый в качестве моста SRB, который соединяет две или несколько сетей Token Ring, оканчиваются неудачей.
В табл. 10.1 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
( Таблица 10.1. Локальное перенаправление SRB: хост не может . jподключиться к серверу ...
Проблема Решение
Несоответствие Интерфейс маршрутизатора, настроенный на использование для мостового номеров колец перенаправления, нельзя вставить в кольцо, поскольку обнаружено несоответствие номеров колец и на консоль выведено сообщение об ошибке.
Шаг 1. Получите сведения о номере кольца (заданном в виде шестнадцатеричного числа), который установлен в мостах SRB IBM (от системного администратора или из информации о конфигурации других мостов SRB).
Шаг 2. Вызовите на выполнение привилегированную exec-команду show running-config (или просто show run) для просмотра информации о конфигурации маршрутизаторов, настроенных в качестве мостов •SRB. Найдите записи команды конфигурации интерфейса sourcebridge, с помощью которых присваиваются номера колец (представленные в виде десятичных чисел) кольцам, подключенным к интерфейсам маршрутизатора.
Например, в следующей записи конфигурации показана запись для локального кольца 10, моста номер 500 и удаленного кольца 20: source-bridge 10 500 20
Примечание. Параллельные мосты, находящиеся между двумя одинаковыми кольцами, должны иметь разные номера мостов.
Шаг 3. Преобразуйте шестнадцатеричные значения номеров колец SRB IBM в десятичные числа и проверьте, совпадают ли номера колец, заданные в конфигурациях всех узлов объединенной сети.
Шаг 4. Если номера колец не совпадают, откорректируйте конфигурацию интерфейса маршрутизатора или мостов SRB IBM так, чтобы номера колец совпадали. Для внесения изменений в конфигурацию применяется команда source-bridge; синтаксическая структура этой команды приведена ниже.
source-bridge source-ring-number bridge-number target-ringnumber [conserve-ring]
Описание синтаксиса
source-ring-number. Номер кольца для интерфейса Token Ring или кольца FDDI. Он должен представлять собой десятичное число в диапазоне от 1 до 4095 и однозначно определять сетевой сегмент или кольцо в сети Token Ring или FDD1, соединенной мостами.
bridge-number. Номер, который однозначно определяет мост, соединяющий кольца отправителя и получателя. Он должен представлять собой десятичное число в диапазоне от 1 до 15.
target-ring-number. Номер кольца получателя для данного маршрутизатора. Он должен быть уникальным в данной сети Token Ring или FDDI, соединенной мостами. Кольцо получателя может также представлять собой группу колец. Номер кольца должен быть представлен в виде десятичного числа.
Проблема
Решение
• conserve-ring. (Необязательный параметр.) Ключевое слово, которое указывает, что должно быть разрешено применение средств SRB в сети Frame Relay. Если эта опция установлена, программное обеспечение SRB не вводит номер кольца, связанный с PVC Frame Relay (виртуальным кольцом взаимодействующего устройства), в исходящие поисковые пакеты. Данная опция может применяться только при настройке конфигурации подынтерфейсов Frame Relay.
Пример
В следующем примере показано, как соединить маршрутизатор кольца 129 и 130 сети Token Ring: interface tokenring 0 source-bridge 129 1 130
!
interface tokenring 1
source-bridge active 130 1 129
Оконечная система не поддерживает фреймы RIF
Шаг 1. Установите сетевой анализатор в том же кольце, к которому подключена оконечная система.
Шаг 2. Найдите фреймы RIF (Routing Information Field — поле маршрутной информации), переданные из оконечной системы (во фреймах RIF старший бит МАС-адреса отправителя установлен равным 1).
Шаг 3. Если фреймы R1F не обнаружены, это означает, что оконечная система не поддерживает фреймы R1F и не может участвовать в маршрутизации от отправителя.
Если данный протокол является маршрутизируемым, то можно применить маршрутизацию протокола или выполнить настройку прозрачного мостового перенаправления. При использовании прозрачного мостового перенаправления необходимо следить за тем, чтобы не создавались циклы между мостом SRB и доменами прозрачного мостового перенаправления.
Шаг 4. Если для конкретной сетевой среды требуется применение средств SRB, обратитесь к поставщику рабочей станции или сервера для получения драйверов SRB или информации о настройке рабочей станции или сервера для поддержки SRB
Превышено допустимое число транзитных переходов
Воспользуйтесь командой show protocol route для проверки значений числа транзитных переходов в маршрутизаторах и мостах в пути следования пакета. Пакеты, прошедшие через такое число транзитных переходов, которое превышает указанное значение, уничтожаются.
В качестве альтернативы можно разрешить применение привилегированной exec-команды debug source event для определения того, происходит ли уничтожение пакетов в связи с превышением допустимого числа транзитных переходов.
Проблема Решение
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Если допустимое число транзитных переходов меньше значения 7, заданного по умолчанию, то оно должно быть увеличено. В качестве альтернативы, необходимо перепроектировать сеть так, чтобы ни один из получателей не находился от отправителя на расстоянии, превышающем семь транзитных переходов
перенаправление связующих поисковых пакетовперенаправление связующих поисковых пакетовМаршрутизатор Связующие поисковые пакеты эквивалентны пакетам широковещательной не настроен на рассылки по одному маршруту, поэтому для их перенаправления должна быть выполнена соответствующая настройка маршрутизаторов.
перенаправление связующих поисковых пакетов
перенаправление связующих поисковых пакетов
Шаг 1. Воспользуйтесь exec-командой show source-bridge, чтобы определить, увеличивается ли количество связующих поисковых пакетов.
Шаг 2. Если количество связующих поисковых пакетов не увеличивается, вызовите на выполнение привилегированную exec-команду show running-config в маршрутизаторах, чтобы определить, выполнена ли настройка команды конфигурации интерфейса source-bridge spanning. Эта команда настраивает маршрутизатор на перенаправление связующих поисковых пакетов.
Шаг 3. Если в составе конфигурации отсутствует запись указанной команды, введите ее во все маршрутизаторы, через которые должны проходить связующие поисковые пакеты. Синтаксическая структура этой команды приведена ниже.
source-bridge spanning bridge-group [path-cost path-cost]
Описание синтаксиса
bridge-group. Номер в диапазоне от 1 до 9, выбранный для обозначения конкретной группы интерфейсов сети, соединенной мостами.
path-cost. (Необязательный параметр.) Стоимость пути для указанного интерфейса.
path-cost. (Необязательный параметр.) Конкретное значение стоимости пути для интерфейса. Допустимый диапазон — от 0 до 65535.
Пример
В следующем примере интерфейс Token Ring 0 добавляется к группе мостов 1, и ему присваивается значение стоимости пути 12:
interface tokenring О
source-bridge spanning 1 path-cost 12
ПроблемаРешение
Шаг 4. Воспользуйтесь ехес-командой show source-bridge, чтобы определить, передаются ли поисковые пакеты.
Шаг 5. Если поисковые пакеты не передаются, поместите сетевой анализатор в том же кольце, к которому подключена оконе чная система.
Шаг 6. Если обнаруживаются поисковые пакеты связующего дерева, воспользуйтесь привилегированной ехес-командой show running-config, чтобы проверить, правильно ли выполнена настройка конфигурации маршрутизатора. Если сеансы все еше не могут быть установлены через мост SRB, обратитесь за помошью к представителю службы технической поддержки
Локальное перенаправление SRB: не функционируют средства перенаправления
Признак неисправности. Пакеты маршрутизируемых протоколов не перенаправляются маршрутизаторами должным образом в локальной среде SRB. Мосты SRB нормально проводят трафик.
В табл. 10.2 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
(.Таблица 10.2
. Локальное перенаправление SRB: не функционируют' (
средства перенаправления - ..,;;
Проблема
Решение
Нарушение в работе средств маршрутизации
Для получения дополнительной информации об устранении нарушений в работе средств маршрутизации обратитесь к тем главам данной книги, где рассматриваются соответствующие маршрутизирующие протоколы. Например, если в сети применяется протокол Novell IPX, обратитесь к главе 8
Отсутствует команда multiring
Шаг 1. Вызовите на выполнение в рассматриваемом маршрутизаторе привилегированную exec-команду show running-config. Найдите запись команды конфигурации интерфейса multiring. Эта команда разрешает накопление и применение информации RIF в интерфейсах маршрутизатора.
Шаг 2. Если команда multiring отсутствует, введите ее в конфигурацию с помошью следующей команды: C4000(config-if)#multiring all
Неполная таблица ARP
Шаг 1. Определите, может ли быть выполнено эхо-тестирование хостов.
Шаг 2. Если один из хостов не отвечает, воспользуйтесь ехес-командой show агр, чтобы определить, имеется ли запись для этого хоста в таблице ARP.
Шаг 3. Если такая запись имеется, то, возможно, имеет место нарушение в работе маршрутизатора. Определите, имеется ли путь исходного маршрута к аппаратному МАС-адресу получателя. Воспользуйтесь ехес-командой show rif для определения соответствия значения поля RIF и аппаратного адреса хоста.
Проблема
Решение
Шаг 4. Если необходимая запись отсутствует, воспользуйтесь сетевым анализатором, чтобы определить, проходят ли запросы ARP к удаленному кольцу и возвращаются ли ответы
RSRB: хост не может подключиться к серверу (одноранговые узлы не открыты)
Признак неисправности. Хосты не могут устанавливать соединения с серверами через маршрутизатор, настроенный для использования в режиме дистанционного мостового перенаправления от отправителя (RSRB — Remote Source-Route Bridging). Вывод привилегированной exec-команды show source-bridge показывает, что одноранговые узлы SRB не открыты.
Примечание
Если открытие одноранговых узлов было выполнено успешно, но хосты все еще не могут подключиться к серверам, обратитесь к разделу “RSRB: хост не может подключиться к серверу (одноранговые узлы открыты)”, приведенному ниже в этой главе.
В табл. 10.3 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 10.3.
RSRB: хост не может подключиться к серверу;
Проблема
(одноранговые узлы не открыты)
Решение
Команда source-bridge remote-peer в маршрути заторе отсутствует или настроена неправильно
Шаг 1. Воспользуйтесь exec-командой show source-bridge для проверки удаленных одноранговых узлов.
Если вывод этой команды показывает, что одноранговые узлы открыты, обратитесь к разделу “RSRB: хост не может подключиться к серверу (одноранговые узлы открыты)”, приведенному ниже в этой главе.
Шаг 2. Если же вывод команды показывает, что одноранговые узлы не открыты, то вызовите на выполнение привилегированную ехес- команду show running-config для просмотра информации о конфигурации маршрутизатора. Убедитесь в том, что в состав конфигурации входят две записи глобальной команды конфигурации sourcebridge remote-peer; в одной из них должен быть указан IP-адрес локального маршрутизатора, а в другой — IP-адрес удаленного маршрутизатора.
Шаг 3. Если одна из этих команд или обе команды отсутствуют или в них указан неправильный адрес, введите или откорректируйте указанные команды соответствующим образом.
Дополнительные рекомендации по настройке маршрутизаторов для использования в качестве мостов RSRB приведены в документах Cisco IOS Bridging and IBM Networking Configuration Guide и Bridging and IBM Networking Command Reference
Проблема
Решение
Отсутствие маршрута к удаленному одноранговому узлу
Если между локальным и удаленным мостами SRB применяется инкапсуляция TCP или FST (Fast Sequenced Transport — скоростная упорядоченная передача), выполните следующие действия.
Шаг 1. Проверьте возможность связи по протоколу IP с использованием расширенной привилегированной exec-команды ping. Примените в качестве адреса отправителя идентификатор локального однорангового узла, а в качестве адреса получателя — идентификатор удаленного однорангового узла.
Шаг 2. Если выполнение указанной команды эхо-тестирования окончится неудачей, воспользуйтесь exec-командой show ip route для просмотра таблицы маршрутизации IP.
Шаг 3. Если в результатах выполнения команды show ip route не показан маршрут к намеченному удаленному одноранговому узлу, то, вероятно, имеет место нарушение в работе средств маршрутизации IP, неисправность аппаратных средств или кабельной разводки на пути от локального к удаленному мосту SRB.
Дополнительная информация об устранении нарушений в работе средств маршрутизации IP приведена в главе 7, а об устранении нарушений в работе аппаратных средств — в главе 3
Нарушение в работе последовательного канала
Если между локальным и удаленным мостами SRB установлено непосредственное соединение (т.е. если не применяется инкапсуляция FST или TCP), выполните следующие действия.
Шаг 1. Убедитесь в том, что следующий маршрутизатор является непосредственно смежным.
Шаг 2. Если маршрутизатор является смежным, проведите другие проверки, чтобы определить, функционирует ли канал должным образом. Для получения дополнительной информации обратитесь к главе 15.
Шаг 3. Если следующий маршрутизатор не является непосредственно смежным, перепроектируйте сеть таким образом, чтобы соблюдалось это условие
Оконечная система не вырабатывает трафик поисковых пакетов
Шаг 1. Вызовите на выполнение привилегированную exec-команду show source-bridge, чтобы определить, увеличивается ли количество поисковых пакетов.
Шаг 2. Если количество поисковых пакетов не увеличивается, воспользуйтесь привилегированной exec-командой show running-config для просмотра информации о конфигурации маршрутизатора. Проверьте наличие команды конфигурации интерфейса source-bridge spanning в локальном и удаленном маршрутизаторах.
Шаг 3. Если команда source-bridge spanning не входит в состав конфигурации маршрутизаторов, введите ее в конфигурацию интерфейсов, через которые соединяются локальный и удаленный мосты SRB. Эта команда необходима, если в оконечной системе используются поисковые пакеты одного маршрута. Синтаксис команды приведен ниже.
source-bridge spanning bridge-group [path-cost path-cost]
Проблема
Решение
Описание синтаксиса
bridge-group. Номер в диапазоне от 1 до 9, выбранный ДЛЯ обозначения конкретной группы интерфейсов сети, соединенной мостами.
path-cost. (Необязательный параметр.) Стоимость пути для указанного интерфейса.
path-cost. (Необязательный параметр.) Конкретное значение стоимости пущ для интерфейса. Допустимый диапазон — от 0 до 65535.
Пример
В следующем примере интерфейс Token Ring 0 добавляется к группе мостов 1, и ему присваивается значение стоимости пути 12: interface tokenring 0
source-bridge spanning 1 path-cost 12
Несоответствие типов инкапсуляции
Шаг 1. Воспользуйтесь ехес-командой show interfaces, чтобы проверить, находятся ли интерфейс и протокол канала связи в рабочем состоянии. Если в строке состояния указано какое-либо иное состояние, обратитесь к главе 15.
Шаг 2. Проверьте, соответствует ли указанный в составе конфигурации тип инкапсуляции требованиям сети, к которой подключен последовательный интерфейс.
Например, если последовательный интерфейс подключен к арендованному каналу, а в составе конфигурации указан тип инкапсуляции Frame Relay, то имеет место несоответствие типов инкапсуляции.
Шаг 3. Для устранения такого несоответствия замените тип инкапсуляции для последовательного интерфейса типом, подходящим для подключенной сети, например, укажите hdlc вместо frame-relay
Превышено допустимое число транзитных переходов
Шаг 1. Воспользуйтесь командой show protocol route для проверки значений числа транзитных переходов в маршрутизаторах и мостах в пути следования пакета. Пакеты, прошедшие через такое число транзитных переходов, которое превышает указанное значение, уничтожаются.
В качестве альтернативы можно разрешить применение привилегированной exec-команды debug source event для определения того, уничтожаются ли пакеты в связи с превышением допустимого числа транзитных переходов.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Проблема Решение
Шаг 2. Если допустимое число транзитных переходов меньше значения 7,
заданного по умолчанию, то оно должно быть увеличено. В качестве альтернативы необходимо перепроектировать сеть так, чтобы ни один из получателей не находился от отправителя на расстоянии, превышающем семь транзитных переходов
RSRB: хост не может подключиться к серверу (одноранговые узлы открыты)
Признак неисправности. Хосты не могут устанавливать соединения с серверами через маршрутизатор, настроенный для использования в режиме дистанционного мостового перенаправления от отправителя (RSRB — Remote Source-Route Bridging). Вывод привилегированной exec-команды show source-bridge показывает, что одноранговые узлы SRB открыты.
Ниже приведен пример вывода команды show source-bridge.
ionescoishow source-bridge
[...]
Peers:
state Iv pkts_rx pkts tx expl gn drops TCP
TCP 150.136.92.92
TCP 150.136.93.93
[...]
-200~ 000
open 2*1818300
В табл. 10.4 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
( :" ■<■ ■~
Таблица 10.4. RSRB: хост не может подключиться к серверу;
j(одноранговые узлы открыты)..•
Проблема
Решение
Неправильная Шаг 1. Если оконечная система Подключена к кольцу, локальному По отноше-
настройка конфигурации оконечной
системы
нию к данному маршрутизатору, вызовите на выполнение привилегированную exec-команду show Iran station в локальном маршрутизаторе. Эта команда выводит список станций в локальном кольце.
Ниже приведен пример вывода команды show Inm station.
show Inm station [address]
Описание синтаксиса
• address. (Необязательный параметр.) Адрес конкретной станции LNM (LAN Network Manager — диспетчер локальной сети).
Пример вывода
Ниже приведен пример вывода команды show Inm station при указании конкретного адреса (в данном случае 1000.5аЬс15).
Проблема
Решение
Router# show Inm station 1000.5a6f.bcl5 isolating error counts
stationintringloc.weightline inter
burst ac abort 1000.5a6f.bcl5T10001000000 - N00000 00000
00000 00000 00000 Unique ID: 0000.0000.0000NAUN:0000.3000.abc4
Functional: C000.0000.0000Group:C000.0000.0000
Physical Location: 00000EnabledClasses: 0000
Allowed Priority: 00000AddressModifier: 0000
Product ID:00000000.00000000.00000000.00000000.0000
Ucode Level:00000000.00000000.0000
Station Status: 00000000.0000 Last transmit status: 00
Шаг 2. Проверьте наличие в результатах выполнения команды МАС-адреса рабочей станции или сервера. Если МАС-адрес в этом выводе отсутствует, проверьте конфигурацию оконечной системы.
Шаг 3. Если нарушение в работе еще не устранено, воспользуйтесь сетевым анализатором для проверки сетевого трафика, генерируемого оконечной системой. Если в вашем распоряжении нет сетевого анализатора, то воспользуйтесь командами debug token-ring и debug source-bridge.
Предостережение. Вызывать на выполнение команды debug token-ring и debug source-bridge в загруженном маршрутизаторе не рекомендуется. При непродуманном использовании этих команд может произойти снижение производительности сети или полный отказ сети.
Шаг 4. Проверьте результаты выполнения указанных команд debug, чтобы определить, передает ли оконечная система трафик по правильным МАС-адресам или именам получателя (в случае NetBIOS)
Оконечная система не поддерживает фреймы RIF
Шаг 1. Установите сетевой анализатор в том же кольце, к которому подключена оконечная система.
Шаг 2. Найдите фреймы RIF, переданные из оконечной системы (во фреймах RIF старший бит МАС-адреса отправителя установлен равным 1).
Шаг 3. Если фреймы RIF не обнаружены, это означает, что оконечная система не поддерживает фреймы RIF и не может участвовать в маршрутизации от отправителя.
Если данный протокол является маршрутизируемым, то можно применить маршрутизацию протокола или выполнить настройку прозрачного мостового перенаправления. При использовании прозрачного мостового перенаправления необходимо следить за тем, чтобы не создавались циклы между мостом SRB и доменами прозрачного мостового перенаправления.
Шаг 4. Если для конкретной сетевой среды требуется применение средств SRB, обратитесь к поставщику рабочей станции или сервера для получения драйверов SRB или информации о настройке рабочей станции или сервера для поддержки SRB
Трафик поисковых пакетов не достигает удаленного кольца
Шаг 1. Понаблюдайте за сетевым трафиком с помощью сетевого анализатора или команды debug source-bridge, чтобы определить, достигают ли удаленного кольца поисковые пакеты, отправленные из оконечной системы.
Шаг 2. Если трафик успешно достигает удаленного кольца, проверьте конфигурацию оконечной системы получателя (например, сервера), чтобы определить, почему эта станция не отвечает на трафик поисковых пакетов, направленный от отправителя.
Если трафик не достигает удаленного кольца, воспользуйтесь командой show source-bridge для проверки списков колец. Если в список не вошла информация о данном кольце, проверьте конфигурации маршрутизаторов.
Шаг 3. Если применяется протокол NetBIOS, воспользуйтесь ехес-командой show netbios name-cache, чтобы проверить, передается ли трафик через данную сеть должным образом. Если этого не происходит, проверьте конфигурации маршрутизаторов.
Дополнительная информация о настройке маршрутизаторов для использования в качестве мостов RSRB приведена в документах Cisco IOS Bridging and IBM Networking Configuration Guide и Bridging and IBM Networking Command Reference
Решение
Проблема
RSRB: периодические нарушения связи
Признак неисправности. Периодически нарушается связь через маршрутизатор, настроенный для использования в качестве моста RSRB.
В табл. 10.5 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 10.5. RSRB: периодические нарушения связи
Проблема Решение
Неправильно настроенные таймеры Т1Неправильно настроенные таймеры Т1Если не применяется локальное подтверждение, то периодические таймауты могут быть вызваны неправильно настроенными таймерами Т1.
Неправильно настроенные таймеры Т1
Неправильно настроенные таймеры Т1
Шаг 1. Воспользуйтесь сетевым анализатором, чтобы определить, сколько времени требуется для прохождения пакетов от одного конца сети к другому. (Примечание. Если сетевой анализатор будет вставлен в канал Т1, это приведет к останову работы канала.)
Шаг 2. Проверьте связь с удаленным маршрутизатором с помощью команды ping и определите задержку кругового обращения. Сравните это значение с установками таймера Т1 в конфигурациях оконечных систем.
Шаг 3. Если задержка кругового обращения превышает установку таймера Т1 или приближается к ней, то, возможно, что подтверждения задерживаются или уничтожаются распределенной сетью. Если имеют место задержки, увеличьте значения установок таймера Т1 в конфигурациях оконечных систем. Если имеет место уничтожение подтверждений, проверьте буфера и очереди интерфейсов.
Проблема
Решение
Шаг 4. Разрешите применение локальных подтверждений, чтобы определить, позволяет ли это устранить нарушение в работе
Нарушение в работе канала распределенной сети
Дополнительные рекомендации по устранению нарушений в работе последовательного канала приведены в главе 15, а по устранению нарушений в работе различных вариантов среды распределенной сети — в соответствующей главе данной книги
RSRB: клиент NetBIOS не может подключиться к серверу
Признак неисправности. Клиенты NetBIOS не могут устанавливать соединения с серверами NetBIOS через маршрутизатор, настроенный для использования в качестве моста RSRB.
В табл. 10.6 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 10.6. RSRB: клиент NetBIOS не может подключиться к серверу
Проблема
Решение
Неправильное преобразование имен серверов и клиентов в МАС- адреса в кэше имен NetBIOS
Шаг 1. Вызовите на выполнение exec-команду show rif в каждом маршрутизаторе, в котором разрешено кэширование имен NetBIOS, чтобы определить, показывает ли запись R1F правильный путь от маршрутизатора и к клиенту, и к серверу.
Ниже приведен пример вывода exec-команды show rif.
cantatriceHshow rif
Codes: * interface, - static, + remote
Hardware Addr How Idle (min) Routing Information Field
5C02.0001.4322rg5-0630.0053.00B0
5A00.0000.2333TRO308B0.0101.2201.0FF0
5B01.0000.4444---
0000.1403.4800TRI0-
0000.2805.4C00TRO*-
0000.2807.4C00TRI*-
0000.28A8.4800TRO0-
0077.2201.0001rg5100830.0052.2201.0FF0
В результатах выполнения этой команды звездочкой (*) обозначены записи, в которых указаны адреса интерфейсов маршрутизатора. Записи, обозначенные дефисом (-), представляют собой статические записи. Числами обозначены кэшированные записи. Если в качестве тайм-аута RIF указано значение, отличное от предусмотренного по умолчанию значения 15 минут, этот тайм-аут отображается в верхней части вывода.
Шаг 2. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Убедитесь в том, что в конфигурацию Token Ring включена команда конфигурации интерфейса source-bridge proxy-explorer. Во всех интерфейсах, в которых используется кэширование имен NetBIOS, должно быть разрешено применение прокси-анализаторов.
Проблема
Решение
Шаг 3. Вызовите на выполнение exec-команду show netbios-cache, чтобы уточнить, определяют ли записи кэша NetBIOS правильное соответствие между именами серверов и клиентов и МАС-адресами.
Ниже приведен пример exec-команды show netbios-cache.
cantatrice# show netbios-cache
HW AddrNameHowIdleNetBIOSPacket
Savings
1000.5a89.449aIC6W06_BTRI60
1000.5a8b.14e5IC_9Q07ATRI20
1000.5a25.lbl2IC9Q19_ATRI70
1000.5a25.lbl2IC9Q19_ATRI100
1000.5a8c.7bblBKELSA1TRI40
1000.5a8b.6c7cICELSB1TRI-0
1000.5a31.df39ICASC_01TRI-0
1000.5ada.47afBKELSA2TRI100
1000.5a8f.018aICELSC1TRI10
В результатах выполнения команды show netbios-cache содержатся следующие поля.
show netbios. Описания полей кэша.
HW Addr. МАС-адрес, соответствующий имени NetBIOS в данной записи.
Name. Имя NetBIOS, соответствующее МАС-адресу в данной записи.
How. Интерфейс, через который была получена эта информация.
Idle. Продолжительность времени (в секундах) с момента последнего доступа к данной записи. Дефис в этом столбце указывает, что это — статическая запись в кэше имен NetBIOS.
NetBIOS Packet Savings. Количество пакетов, на которые поступили локальные ответы (и поэтому не требуется передача этих пакетов по сети).
Шаг 4. Вызовите на выполнение привилегированную exec-команду show running-config в каждом маршрутизаторе для проверки правильности адресов, которые заданы в записях глобальной команды конфигурации netbios name-cache.
В следующем примере показана конфигурация, предусматривающая удаленный доступ к серверу NetBIOS: source-bridge ring-group 2
rif 0110.2222.3333 0630.021.0030 ring group 2
netbios name-cache 0110.2222.3333 DEF ring-group 2
Неправильно настроена команда sourcebridge
Шаг 1. Вызовите на выполнение команду show source-bridge в каждом маршрутизаторе, в котором разрешено кэширование имен NetBIOS, для получения информации о версии удаленного соединения. Заданное здесь значение должно быть равно 2 или 3. Если же это значение равно 1, то соединения не будут устанавливаться через маршрутизатор и поэтому необходимо внести изменения в конфигурацию.
Проблема
Решение
Пример
Ниже показан пример вывода команды show source-bridge.
Router# show source-bridge
Local Interfaces:receivetransmit
srn bn trn r p s n max hopsentent
drops
TRO5 110 **739:100223:62923
Ring Group 10:
This peer: TCP 150.136.92.92
Maximum output TCP queue length, per peer: 100
Peers:state Iv pkts_rx pkts_tx expl_gn
drops TCP
TCP 150.136.92.92 -200000
TCP 150.136.93.93 open 2*18.18300
Rings:
bn: 1 m: 5 local ma: 4000.3080.844b TokenRingO fwd: 18
bn: 1 rn: 2 remote ma: 4000.3080.8473 TCP 150.136.93.93 fwd: 36
Explorers: input output
spanning all-rings totalspanning all-rings total
TRO 033358
Router#
Шаг 2. Если маршрутизатор работает под управлением программного обеспечения с версией, предшествующей Cisco 1OS 10.0, то в команде конфигурации интерфейса source-bridge remote-peer укажите версию 2 или 3. Синтаксическая структура этой команды показана ниже, source-bridge remote-peer ring-group tep ip-address [If size] [local-ack] [priority] [version number]
Если маршрутизатор работает под управлением программного обеспечения Cisco 1OS 10.0 или более поздних версий, то информация о версии в составе конфигурации игнорируется.
Дополнительная информация приведена в документах Cisco IOS Bridging and IBM Networking Configuration Guide и Bridging and IBM Networking Command Reference
Мостовое перенаправление с трансляцией: клиент не может подключиться к серверу
Признак неисправности. Клиенты не могут установить связь через маршрутизатор, настроенный в качестве моста с трансляцией.
Предостережение
В определенных ситуациях замена существующих мостов с трансляцией мостами с трансляцией Cisco может вызвать нарушение взаимодействия сетевых устройств. В частности, некоторые реализации мостов с трансляцией предусматривают преобразование функциональных адресов. При этом адрес в передающей среде (такой как функциональный адрес 0900.2B00.00FA уровня протокола LAT в сети Ethernet) преобразуется в широковещательный адрес на стороне Token Ring (такой как C000.FFFF.FFFF). Маршрутизаторы Cisco не поддерживают подобный режим работы. Кроме того, мостовое перенаправление с трансляцией не может применяться в сочетании с любым протоколом, который предусматривает внедрение МАС-адреса станции в поле данных фреймов МАС (примерами таких протоколов являются IP ARP и Novell IPX).
В табл. 10.7 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
i Таблица 10.7. Мостовое перенаправление с трансляцией: клиент не может j
Проблема
подключиться к серверуJ
Решение
Нарушение в работе передающей среды
Проверьте канал с помощью exec-команды show interfaces. Если работа интерфейса или протокола канала связи остановлена, устраните нарушение в работе передающей среды. Для получения информации об устранении нарушений в работе передающей среды локальной сети обратитесь к главе, в которой рассматривается соответствующий тип передающей среды
Неправильная настройка преобразования адресов Ethernet в адреса Token Ring
Шаг 1. Воспользуйтесь ехсс-командой show bridge, чтобы проверить наличие станции Ethernet.
В адресах Ethernet и Token Ring используются схемы с противоположным порядком битов. Адрес 0110.2222.3333 Token Ring эквивалентен адресу 8008.4444.сссс Ethernet.
Шаг 2. Вызовите на выполнение exec-команду show spanning, чтобы определить, находится ли порт Ethernet в режиме перенаправления.
Пример
Ниже приведен пример вывода команды show span.
RouterA> show span
Bridge Group 1 is executing the IBM compatible spanning tree protocol
Bridge Identifier has priority 32768, address 0000.0c0c.f68b
Configured hello time 2, max age 6, forward delay 4
Current root has priority 32768, address 0000.0c0c.f573
Root port is 001A (TokenRingO/0), cost of root path is 16 Topology change flag not set, detected flag not set Times: hold 1, topology change 30, notification 30 hello 2, max age 6, forward delay 4, aging 300
Timers: hello 0, topology change 0, notification 0 Port 001A (TokenRing0/0) of bridge group 1 is forwarding. Path cost 16
Проблема
Решение
Designated root has priority 32768, address 0000.0c0c.f573
Designated bridge has priority 32768, address 0000.0c0c.f573
Designated port is 001B, path cost 0, peer 0
Timers: message age 1, forward delay 0, hold 0
Port 002A (TokenRingO/1) of bridge group 1 is blocking. Path cost 16
Designated root has priority 32768, address 0000.0c0c.f573
Designated bridge has priority 32768, address 0000.0c0c.f573
Designated port is 002B, path cost 0, peer 0
Timers: message age 0, forward delay 0, hold 0
Port 064A (spanRSRB) of bridge group 1 is disabled. Path cost 250
Designated root has priority 32768, address 0000.0c0c.f573
Designated bridge has priority 32768, address 0000.0c0c.f68b
Designated port is 064A, path cost 16, peer 0
Timers: message age 0, forward delay 0, hold 0
Порт (spanRSRB) создается для каждой виртуальной группы колец. Этот порт остается заблокированным до тех пор, пока один или несколько одноранговых узлов в группе колец не перейдет в открытое состояние.
Шаг 3. Воспользуйтесь exec-командой show rif, чтобы определить, является ли рассматриваемая станция Token Ring видимой в объединенной сети. Если маршрутизатор настроен на работу в режиме мостового перенаправления с трансляцией, он извлекает поле RIF из каждого пакета, отправленного из сети Token Ring, и сохраняет его в таблице. Затем маршрутизатор передает пакет в сеть Ethernet. В дальнейшем маршрутизатор снова вставляет поле R1F после получения пакета, предназначенного для узла-отправителя на стороне сети Token Ring.
Пример
Ниже приведен пример вывода команды show rif.
Router# show rif
Codes: * interface, - static, + remote
Hardware Addr How Idle (min) Routing Information Field 5C02.0001.4322 rg5-0630.0053.0080
5A00.0000.2333 TRO308B0.0101.2201.0FF0
5B01.0000.4444 ---
0000.1403.4800 TRI0-
0000.2805.4C00 TRO*-
Проблема
Решение
0000.2807.4С00 TR1*-
0000.28А8.4800 TR00-
0077.2201.0001 rg5100830.0052.2201.0FF0
Шаг 4. Если оконечные системы Ethernet и Token Ring являются видимыми, то необходимо ввести постоянные изменения в конфигурации клиентов, указав все требуемые МАС-адреса серверов, чтобы клиенты могли непосредственно принимать извещения этих серверов. Введение в конфигурацию постоянной информации о соответствии адресов необходимо и в том случае, если осуществляется мостовое перенаправление трафика DEC LAT через мост с трансляцией. Анонсы об услугах LAT в сети Ethernet рассылаются по групповому адресу, который преобразуется некоторыми маршрутизаторами с трансляцией в широковещательный адрес на стороне Token Ring. Маршрутизаторы не поддерживают такое преобразование
Несоответствие кодов поставщика
В более старых реализациях протокола Token Ring код поставщика (поле OUI) заголовка SNAP имел значение 000000. Маршрутизаторы Cisco устанавливают значение этого поля равным 0000F8 для указания на то, что фрейм был преобразован из формата Ethernet версии 2 в формат Token Ring. Но это может привести к нарушению работы более старых версий сетей Token Ring.
Задайте команду конфигурации интерфейса ethernet-transit-oui, чтобы вынудить маршрутизатор устанавливать значение 000000 для поля кода поставщика. Такое изменение часто требуется, если в сети имеются устройства IBM 8209 (мосты с трансляцией из формата IBM Token Ring в формат Ethernet).
Ниже приведен пример команды ethernet-transit-oui. ethernet-transit-oui [90-compatible | standard | cisco]
Описание синтаксиса
90-compatible. В качестве OUI при взаимодействии с другими маршрутизаторами Cisco по умолчанию применяется значение 0000F8. Эта опция обеспечивает наибольшее удобство в работе.
standard. В качестве OUI при взаимодействии с мостами IBM 8209 и оборудованием других поставщиков используется значение 000000. Эта опция не обеспечивает такого же удобства в работе, как две другие опции.
cisco. В качестве OUI применяется значение 00000С, которое предусмотрено для совместимости с будущими версиями оборудования.
Пример
В следующем примере задана форма OUI для маршрутизатора Cisco:
interface tokenring 0 ethernet-transit-oui cisco
ПроблемаПроблемаРешениеРешениеПараллельное подключение мостов с трансляцией, соответствующих и не соответствующих спецификациям CiscoПараллельное подключение мостов с трансляцией, соответствующих и не соответствующих спецификациям CiscoПопытка мостового перенаправления трафикаПопытка мостового перенаправления трафикапротоколов, предусматривающих включение МАС-адресов в пале информации фрейма МАС (таких как IP ARP, Novell IPX или AARP5)протоколов, предусматривающих включение МАС-адресов в пале информации фрейма МАС (таких как IP ARP, Novell IPX или AARP5)Шаг 1. Проверьте, есть ли мосты с трансляцией, которые подключены параллельно с мостами с трансляцией Cisco. Если в сети параллельно подключены мосты с трансляцией, не соответствующие и соответствующие спецификациям Cisco, это может привести к созданию циклов.
Проблема
Проблема
Решение
Решение
Параллельное подключение мостов с трансляцией, соответствующих и не соответствующих спецификациям Cisco
Параллельное подключение мостов с трансляцией, соответствующих и не соответствующих спецификациям Cisco
Попытка мостового перенаправления трафика
Попытка мостового перенаправления трафика
протоколов, предусматривающих включение МАС-адресов в пале информации фрейма МАС (таких как IP ARP, Novell IPX или AARP5)
протоколов, предусматривающих включение МАС-адресов в пале информации фрейма МАС (таких как IP ARP, Novell IPX или AARP5)
Шаг 2. Поскольку применение мостового перенаправления с трансляцией противоречит самому назначению механизма связующего дерева в среде прозрачного мостового перенаправления и маршрутизации SRB, в сети необходимо удалить все циклы, вызванные вставкой моста с трансляцией. Мосты в составе прозрачного связующего дерева и связующего дерева с маршрутизацией от отправителя не могут взаимодействовать друг с другом
Если МАС-адреса включены в поле информации фрейма МАС, то мосты теряют способность считывать эти адреса, а следовательно, и перенаправлять соответствующий трафик.
Шаг 1. Если вы безуспешно пытаетесь осуществить мостовое перенаправление трафика протокола указанного типа, примените вместо этого маршрутизацию трафика протокола.
Шаг 2. Если вы все еще не можете установить связь через маршрутизатор, обратитесь за помощью к представителю службы технической поддержки
Мостовое перенаправление SRT: клиент не может подключиться к серверу
Признак неисправности. Клиенты не могут установить связь через маршрутизатор, настроенный на выполнение мостового перенаправления SRT. Пакеты не перенаправляются мостом SRT.
Мостовое перенаправление SRT позволяет реализовать прозрачное мостовое перенаправление в среде Token Ring. Такой метод не может служить в качестве средства трансляции между SRB в передающей среде Token Ring и прозрачной мостовой маршрутизацией в передающей среде Ethernet (или другой передающей среде).
В табл. 10.8 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
; Таблица 10.8. Мострвре перенаправление SRT: клиент не может •подключиться к серверу•
Проблема
Решение
Попытка мостового перенаправления фреймов, содержащих поля RIF, из сети Token Ring в сеть Ethernet через мост SRT
Для обеспечения трансляции из среды SRB в среду прозрачного мостового перенаправления вместо мостового перенаправления с трансляцией необходимо применять мостовое перенаправление SRT.
Поскольку мостовое перенаправление SRT обеспечивается только между сетями Ethernet и Token Ring, при ее использовании уничтожается любой пакет, содержащий поле RIF
Попытка передачи фреймов больших размеров
Если устройства Token Ring передают фреймы, превышающие по размерам значение MTU (Maximum Transmission Unit — максимальная единица передачи данных в сети) сети Ethernet, равное 1500 байтам, возникает нарушение в работе. Выполните настройку хостов сети Token Ring, чтобы они вырабатывали фреймы с размерами меньшими или равными MTU Ethernet
Попытка мостового перенаправления трафика протоколов, предусматривающих включение МАС-адресов в поле информации фрейма МАС (таких как IP ARP, Novell IPX или AARP)
Если МАС-адреса включены в поле информации фрейма МАС, то мосты теряют способность считывать эти адреса, а следовательно и перенаправлять соответствующий трафик.
Шаг 1. Если вы безуспешно пытаетесь осуществить мостовое перенаправление трафика протокола указанного типа, примените вместо этого маршрутизацию трафика протокола.
Шаг 2. Если вы все еше не можете установить связь через маршрутизатор, обратитесь к представителю службы технической поддержки
Нарушение в работе передающей среды
Проверьте канал с помощью exec-команды show interfaces. Если работа интерфейса или протокола канала связи остановлена, устраните нарушение в работе передающей среды. Для получения информации об устранении нарушений в работе передающей среды локальной сети обратитесь к главе, в которой рассматривается соответствующий тип передающей среды
SDLC: маршрутизатор не может обмениваться данными с устройством SDLC
Признак неисправности. Маршрутизатор не может обмениваться данными с устройством IBM SDLC.
В табл. 10.9 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Нарушение в работе протокола физического уровня
Шаг 1. Воспользуйтесь exec-командой show interfaces, чтобы определить, находятся ли интерфейс и протокол канала связи в рабочем состоянии.
Шаг 2. Если и интерфейс, и протокол канала связи находятся в рабочем состоянии, устраните нарушения в работе протокола канального уровня, как описано ниже в этой таблице.
Таблица 10.9. SDLC: маршрутизатор не может обмениваться данными .с устройством SDLC .
Проблема
Решение
ПроблемаПроблемаРешениеРешение
Проблема
Проблема
Решение
Решение
Шаг 3. Если же результаты выполнения приведенной выше команды не указывают, что интерфейс и протокол канала связи находятся в рабочем состоянии, убедитесь в том, что на устройства подается питание. Проверьте, чтобы вся кабельная разводка была выполнена правильно, кабели надежно подключены и не повреждены. Убедитесь в том, что длина кабелей не превышает значения, рекомендуемого для соединения с соответствующей пропускной способностью.
Шаг 4. Если интерфейс или протокол канала связи все еще не функционирует, воспользуйтесь коммутационным боксом для проверки сигналов в канале.
Примечание. На некоторых платформах Cisco, работающих под управлением новейших выпусков программного обеспечения Cisco IOS, таких как Cisco 7500, результаты выполнения команды show interfaces показывают состояние сигналов в канале.
Если маршрутизатор представляет собой дуплексное устройство DCE, проверьте состояние сигналов DTR (Data Terminal Ready — готовность терминала к передаче данных) и RTS (Request То Send — запрос на передачу). Если эти сигналы не имеют высокого потенциала, перейдите к шагу 5. Если же эти сигналы имеют высокий потенциал, то интерфейс должен находиться в рабочем состоянии. Если это не так, обратитесь к представителю службы технической поддержки.
Если при проверке маршрутизатора Cisco 7500 с помощью коммутационного бокса обнаруживается, что сигналы DTR и DTS имеют высокий потенциал, а результаты выполнения команды show interfaces показывают обратное, проверьте кабельную разводку маршрутизатора. В частности, убедитесь в том, что 60-игольный разъем с высокой плотностью монтажа не вставлен в гнездо маршрутизатора в перевернутом виде.
Если маршрутизатор представляет собой полудуплексное устройство DCE, проверьте состояние сигнала DTR. Если сигнал DTR не имеет высокого потенциала, перейдите к шагу 5. Если же сигнал DTR имеет высокий потенциал, то интерфейс должен находиться в рабочем состоянии. Если это не так, обратитесь за помощью к представителю службы технической поддержки.
Примечание. Маршрутизаторы ряда Cisco 7000 не поддерживают полудуплексный режим.
Если маршрутизатор представляет собой дуплексное или полудуплексное устройство DTE, проверьте состояние сигнала CD (Carrier Detect — обнаружение несущей). Если сигнал CD не имеет высокого потенциала, перейдите к шагу 5. Если же сигнал CD имеет высокий потенциал, то интерфейс должен находиться в рабочем состоянии. Если это не так, обратитесь к представителю службы технической поддержки.
Шаг 5. Если маршрутизатор представляет собой дуплексное устройство DCE, убедитесь в том, что это устройство настроено на постоянно высокий потенциал сигнала RTS. Если устройство не позволяет выполнить настройку на постоянное значение сигнала RTS, задайте высокий потенциал этого сигнала, установив перемычку между выводом DTR на стороне устройства и выводом RTS на стороне маршрутизатора (рис. 10.5).
Проблема
Решение
Шаг 6. Если маршрутизатор представляет собой устройство ОСЕ, то в нем может быть предусмотрена возможность регулировки тактовой частоты устройства. Убедитесь в том, что в составе конфигурации маршрутизатора присутствует команда конфигурации интерфейса clock rate. Вызовите на выполнение привилегированную ехес-команду show running-config в маршрутизаторе для просмотра информации о конфигурации интерфейса. В следующем примере показана информация о тактовой частоте для интерфейса interface serial 0.
Пример
В этом примере тактовая частота в первом последовательном интерфейсе устанавливается равной 64000 бит/с.
interface serial 0
clock rate 64000
Если маршрутизатор представляет собой устройство DTE, он должен получать синхроимпульсы от внешнего устройства. Убедитесь в том, что это устройство формирует синхроимпульсы должным образом. Проверьте, применяется ли для всех устройств один и тот же источник синхроимпульсов
Нарушение в работе канального уровня (маршрутизатор является первичным)
Шаг 1. Воспользуйтесь привилегированной exec-командой debug sdlc, чтобы проверить, передает ли маршрутизатор сообщения SNRM (Set Normal Response Mode — настройка режима нормального отклика).
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 2. Если маршрутизатор не передает сообщения SNRM, проверьте работу средств физического уровня (см. описание предыдущей проблемы в этой таблице). Если маршрутизатор передает сообщения SNRM, устройство должно передавать в ответ подтверждения UA (Unnumbered Acknowledgment — ненумерованное подтверждение).
Шаг 3. Если устройство не передает подтверждения UA, убедитесь в том, что адреса маршрутизатора и устройства заданы правильно.
Проблема
Решение
Шаг 4. Если применяется соединение V.35, проверьте, правильно ли установлен режим SCT/SCTE для данного интерфейса. Если маршрутизатор представляет собой устройство DCE, то в нем должна применяться установка SCTE (Serial Clock Transmit External — передача синхроимпульсов в последовательном канале от внешнего устройства), а если маршрутизатор представляет собой устройство DTE, то в нем должна применяться установка SCT (Serial Clock Transmit — передача синхроимпульсов в последовательном канале).
Установка SCT/SCTE может быть изменена с помощью перемычки или с применением программной команды конфигурации dce- terminal-timing enable, в зависимости от платформы. Некоторые платформы не позволяют изменять эту установку.
Пример
В следующем примере показано, как предотвратить сдвиг фаз данных по отношению к синхроимпульсам:
interface serial 0
dce-terminal-timing enable
Шаг 5. Убедитесь в том, что в устройстве и маршрутизаторе применяется один и тот же метод кодирования информации, NRZ (Non-Retum to Zero — метод кодирования информации без возврата к нулю) или NRZI (Non-Return to Zero, Inverted — метод кодирования информации без возврата к нулю, с инверсией). Применение метода NRZ разрешено в маршрутизаторе по умолчанию. Чтобы разрешить применение метода NRZI, воспользуйтесь командой конфигурации интерфейса nrzi-encoding.
Пример
В следующем примере последовательный интерфейс 1 настраивается на использование метода кодирования NRZI:
interface serial 1
nrzi-encoding
Шаг 6. Попытайтесь уменьшить скорость канала до 9600 бит/с с помощью команды конфигурации интерфейса clock rate. Команда конфигурации интерфейса clock rate применяется для установки допустимой скорости передачи информации в битах в качестве значения тактовой частоты для аппаратных соединений в таких последовательных интерфейсах, как модули NIM (Network Interface Module — сетевой интерфейсный модуль) и интерфейсные процессоры.
Синтаксис
Ниже приведен синтаксис команды clock rate.
clock rate bps
Описание синтаксиса
bps. Требуемая тактовая частота в битах в секунду: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148000, 250000, 500000, 800000, 1000000, 1300000, 2000000, 4000000 или 8000000.
Проблема
Решение
Пример
В следующем примере тактовая частота первого последовательного интерфейса устанавливается равной 64000 бит/с:
interface serial 0
clock rate 64000
Шаг 7. Проверьте, чтобы вся кабельная разводка была выполнена правильно, кабели надежно подключены и не повреждены
Нарушение в работе канального уровня (маршрутизатор является вторичным)
Шаг 1. Воспользуйтесь привилегированной exec-командой debug sdlc, чтобы проверить, принимает ли маршрутизатор сообщения SNRM.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 2. Если маршрутизатор не принимает сообщения SNRM, проверьте работу первичного устройства. Убедитесь в том, что средства физического уровня функционируют нормально (см. описание проблемы “Нарушение в работе протокола физического уровня", приведенное выше в этой таблице). Если маршрутизатор принимает сообщения SNRM, он должен передавать в ответ подтверждения UA.
Шаг 3. Если маршрутизатор не передает подтверждения UA, убедитесь в том, что адреса маршрутизатора и устройства заданы правильно.
Шаг 4. Если применяется соединение V.35, проверьте, правильно ли установлен режим SCT/SCTE для данного интерфейса. Если маршрутизатор представляет собой устройство DCE, то в нем должна применяться установка SCTE, а если маршрутизатор представляет собой устройство DTE, то в нем должна применяться установка SCT.
Установка SCT/SCTE может быть изменена с помощью перемычки или с применением программной команды конфигурации dce- terminal-timing enable, в зависимости от платформы. Некоторые платформы не позволяют изменять эту установку.
Пример
В следующем примере показано, как предотвратить сдвиг фаз данных по отношению к синхроимпульсам: interface serial 0
dce-terminal-timing enable
Шаг 5. Воспользуйтесь коммутационным боксом, чтобы проверить наличие высокого потенциала сигнала CTS в линии.
Проблема
Решение
Шаг 6. Убедитесь в том, что в устройстве и маршрутизаторе применяется один и тот же метод кодирования информации, NRZ или NRZI. Применение метода NRZ разрешено в маршрутизаторе по умолчанию. Чтобы разрешить применение метода NRZI, воспользуйтесь командой конфигурации интерфейса nrzi-encoding.
Пример
В следующем примере последовательный интерфейс 1 настраивается на использование метода кодирования NRZI: interface serial 1 nrzi-encoding
Шаг 7. Попытайтесь уменьшить скорость канала до 9600 бит/с с помощью команды конфигурации интерфейса clock rate. Команда конфигурации интерфейса clock rate применяется для установки допустимой скорости передачи информации в битах в качестве значения тактовой частоты для аппаратных соединений в таких последовательных интерфейсах, как модули NIM и интерфейсные процессоры.
Синтаксис
Ниже приведен синтаксис команды clock rate.
clock rate bps
Описание синтаксиса
• tips. Требуемая тактовая частота в битах в секунду: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148000, 250000, 500000, 800000, 1000000, 1300000, 2000000, 4000000 или 8000000.
Пример
В следующем примере тактовая частота первого последовательного интерфейса устанавливается равной 64000 бит/с: interface serial 0
clock rate 64000
Шаг 8. Проверьте, чтобы вся кабельная разводка была выполнена правильно, кабели надежно подключены и не повреждены
SDLC: отсутствие надежной связи
МаршрутизаторМаршрутизаторустройство ьишустройство ьишРис. 10.5. Создание перемычки между выводами сигналов DTR и RTSРис. 10.5. Создание перемычки между выводами сигналов DTR и RTSПризнак неисправности. Пользовательские соединения с хостами через маршрутизатор, настроенный на поддержку транспортного уровня SDLC, завершаются по тайм-ауту.
Маршрутизатор
Маршрутизатор
устройство ьиш
устройство ьиш
Рис. 10.5. Создание перемычки между выводами сигналов DTR и RTS
Рис. 10.5. Создание перемычки между выводами сигналов DTR и RTS
В табл. 10.10 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
j Таблица 10.10. SDLC: отсутствие надежной связи' г
ПроблемаРешение
Нарушения Шаг 1. Установите сетевой анализатор в последовательном канале, подсинхронизацииключенномк станции-отправителю, и следите за передаваемыми
SDLCпакетами.
Шаг 2. Если появляются дубликаты пакетов, проверьте конфигурацию маршрутизатора с помощью привилегированной exec-команды show running-config. Проверьте, имеется ли команда local-ack в составе конфигурации.
Шаг 3. Если команда local-ack отсутствует, введите ее в конфигурацию маршрутизатора для интерфейсов SDLC.
Шаг 4. Параметры локального подтверждения могут быть откорректированы в маршрутизаторе, подключенном устройстве или в том и в другом. Откорректируйте параметры протокола SDLC соответствующим образом. Эти параметры применяются для настройки транспортного уровня SDLC в соответствии с различными конфигурациями сетей. В частности, могут потребовать настройки всевозможные установки таймера LLC2.
Ниже приведен пример конфигурации, в которой применяется команда local-ack.
Interface Serial 1 mtn 4400 no ip address hold-queue 150 in encapsulation stun stun group 1 stun sdlc-role primary sdlc line-speed 19200 sdlc nl 35200 sdlc address 04 echo stun route address 4 tcp 156.28.11.1 local-ack clockrate 19200 Дополнительная информация о настройке транспортного уровня SDLC приведена в документах Cisco IOS Bridging and IBM Networking Configuration Guide и Bridging and IBM Networking Command Reference
SDLC: клиент не может подключиться к хосту через маршрутизатор, работающий под управлением программного обеспечения SDLLC
Признак неисправности. Пользователи не могут открыть соединения с хостами через маршрутизатор, настроенный на поддержку SDLLC (SDLC Logical Link Control — управление логическим каналом SDLC).
В табл. 10.11 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
i Таблица 10.11. SDLC: клиент не может подключиться к хосту через Ь' ~■ маршрутизатор, работающий под управлением
|/программного обеспечения SDLLC \
Проблема
Решение
Нарушение в работе физического или канального уровня SDLC
Шаг 1. Воспользуйтесь exec-командой show interface slot/port, чтобы проверить состояние соединения с устройством SDLC.
Шаг 2. Найдите в результатах выполнения этой команды строку USBUSY, которая указывает, что маршрутизатор пытается установить соединение LLC. Если маршрутизатор не находится в режиме USBUSY, убедитесь в том, что средства физического и канального уровней работают должным образом. Дополнительная информация приведена выше, в разделе “SDLC: маршрутизатор не может обмениваться данными с устройством SDLC".
Шаг 3. Если же маршрутизатор находится в режиме USBUSY, перейдите к описанию следующей проблемы в данной таблице
Маршрутизатор не передает проверочные фреймы процессору FEP
Шаг 1. С помощью привилегированных exec-команд debug sdllc и debug 11с2 packet, разрешенных для использования в маршрутизаторе, проверьте, передает ли маршрутизатор проверочные фреймы процессору FEP (Front-End Processor — коммуникационный процессор).
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 2. Если маршрутизатор передает проверочные фреймы процессору FEP, перейдите к описанию следующей проблемы в данной таблице.
Шаг 3. Если же маршрутизатор не передает проверочные фреймы процессору FEP, воспользуйтесь привилегированной ехес-командой show running-config для просмотра информации о конфигурации маршрутизатора. Убедитесь в том, что в состав конфигурации входит команда конфигурации интерфейса sdlc partner.
Шаг 4. Если команда sdlc partner не входит в состав конфигурации, введите ее в конфигурацию. Проверьте, указан ли в ней аппаратный адрес процессора FEP в сети Token Ring. Ниже показана синтаксическая структура команды sdlc partner: sdlc partner mac-address sdlc-address
Описание синтаксиса
mac-address. 48-битовый МАС-адрес хоста Token Ring.
sdlc-address. Адрес SDLC последовательного устройства, которое обменивается данными с хостом Token Ring. Допустимый диапазон значений — от 1 до FE
Проблема
Решение
Процессор FEP в сети Token Ring не отвечает на проверочные фреймы
Шаг 1. С помощью привилегированных exec-команд debug sdllc и debug 11с2 packet, разрешенных для использования в маршрутизаторе, проверьте, отвечает ли процессор FEP на проверочные фреймы, передаваемые маршрутизатором.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 2. Если процессор FEP отвечает на проверочные фреймы, перейдите к описанию следующей проблемы в данной таблице.
Шаг 3. Если же процессор FEP не отвечает на проверочные фреймы, проверьте МАС-адрес устройства, применяемого в сочетании с маршрутизатором (процессора FEP). Убедитесь в том, что адрес этого устройства в записи команды sdllc partner маршрутизатора указан правильно. Синтаксическая структура команды sdlc partner приведена ниже.
sdlc partner mac-address sdlc-address
Описание синтаксиса
mac-address. 48-битовый МАС-адрес хоста Token Ring.
sdlc-address. Адрес SDLC последовательного устройства, которое обменивается данными с хостом Token Ring. Допустимый диапазон значений — от 1 до FE.
Шаг 4. Проверьте, находятся ли одноранговые узлы RSRB в рабочем состоянии. Если одноранговые узлы не открыты, см. выше раздел “RSRB: хост не может подключиться к серверу (одноранговые узлы не открыты)”.
Шаг 5. Если же одноранговые узлы RSRB открыты, установите сетевой анализатор в сети Token Ring с подключенным процессором FEP и убедитесь в том, что проверочные фреймы маршрутизатора поступают в кольцо и процессор FEP отвечает на них
Фреймы XID не передаются маршрутизатором
Шаг 1. С помошью привилегированных exec-команд debug sdllc и debug 11с2 packet, разрешенных для использования в маршрутизаторе, проверьте, передает ли маршрутизатор фреймы XID (eXchange Identification — идентификация обмена) процессору FEP.
Проблема
Решение
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и со- крашения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 2. Если маршрутизатор передает фреймы XID процессору FEP, перейдите к описанию следующей проблемы в данной таблице.
Шаг 3. Если же маршрутизатор не передает фреймы XID, воспользуйтесь привилегированной exec-командой show running-config для просмотра информации о конфигурации маршрутизатора. Убедитесь в том, что в состав конфигурации входит команда конфигурации интерфейса sdlc xid.
Шаг 4. Если команда sdlc xid не входит в состав конфигурации маршрутизатора, введите ее в конфигурацию. Ниже приведена синтаксическая структура команды sdlc xid.
sdlc xid address xid
Описание синтаксиса
address. Адрес станции SDLC, связанный с данным интерфейсом.
xid. Пакеты XID, применяемые программным обеспечением Cisco IOS для передачи ответов на запросы XID, полученные маршрутизатором. Это значение должно иметь длину 4 байта (8 цифр) и должно быть задано в виде шестнадцатеричного числа.
Пример
В следующем примере задано значение XID, равное 01720002, по адресу С2:
interface serial 0
sdlc xid c2 01720002
Процессор FEP не отвечает на фреймы XID
Шаг 1. С помощью привилегированных exec-команд debug sdllc и debug 11с2 packet, разрешенных для использования в маршрутизаторе, проверьте, отвечает ли процессор FEP на фреймы XID, передаваемые маршрутизатором.
Шаг 2. Если процессор FEP отвечает на фреймы XID, перейдите к описанию следующей проблемы в данной таблице.
Проблема
Решение
Шаг 3. Если же FEP не отвечает на фреймы XID, проверьте значения XID, введенные в конфигурацию маршрутизатора с помощью команды sdllc xid. Значения параметров IDBLK и IDNUM в маршрутизаторе должны соответствовать значениям, заданным в программном обеспечении УТАМ процессора FEP. Синтаксическая структура команды sdlc xid приведена ниже.
sdlc xid address xid
Описание синтаксиса
address. Адрес станции SDLC, связанный с данным интерфейсом.
xid. Пакеты XID, применяемые программным обеспечением Cisco IOS для передачи ответов на запросы XID, полученные маршрутизатором. Это значение должно иметь длину 4 байта (8 цифр) и должно быть задано в виде шестнадцатеричного числа.
Пример
В следующем примере задано значение XID, равное 01720002, по адресу С2:
interface serial 0
sdlc xid c2 01720002
Шаг 4. Убедитесь в том, что информация XID в хостах определена правильно. Если устройство 317Х представляет собой шлюз, подключенный к каналу, то значение XID для IDBLK и IDNLJM должно быть равно 00000000
Нарушение работы хоста
Проверьте хост IBM на отсутствие неисправностей, связанных с его активизацией, с нарушениями в работе прикладных программ, неправильными настройками программ УТАМ и NCP, с несоответствиями конфигурации и другими проблемами
Виртуальные адреса Token Ring и интерфейс SDLLC
Команда sdllc traddr позволяет задать виртуальный МАС-адрес Token Ring для устройства, подключенного к интерфейсу SDLC (устройства, которое эмулирует устройство Token Ring). Две последние шестнадцатеричные цифры виртуального МАС- адреса должны быть равны 00. В этом случае маршрутизатор резервирует все виртуальные адреса в кольце, которые принадлежат к диапазону от xxxx.xxxx.xx00 до xxxx.xxxx.xxff, за последовательным интерфейсом SDLLC.
В результате может оказаться, что другие устройства IBM в объединенной сети имеют адрес LAA, который попадает в тот же диапазон. Это может привести к нарушению работы, если применяется режим локального подтверждения, поскольку маршрутизаторы проверяют только первые 10 цифр адреса LAA пакета (без двух последних, которые рассматриваются как подстановочные символы).
Если маршрутизатор обнаруживает в пакете адрес, который совпадает с назначенным адресом SDLLC LAA, он автоматически перенаправляет этот пакет процессу SDLLC. Это может привести к тому, что пакеты будут по ошибке перенаправляться процессу SDLLC и сеансы не будут устанавливаться.
Примечание
Чтобы предотвратить возможность присваивания конфликтующих адресов, обязательно ознакомьтесь с соглашением об именовании адресов LAA, применяемым в данной объединенной сети, прежде чем назначать виртуальные адреса кольца для какой-либо реализации SDLLC.
SDLC: сеансы, установленные через маршрутизатор, работающий под управлением программного обеспечения STUN, оканчиваются аварийно
Признак неисправности. Сеансы SDLC между двумя узлами оканчиваются аварийно при попытке их установления через маршрутизатор, работающий под управлением программного обеспечения STUN (Serial TUNnel — последовательный туннель).
Примечание
В настоящем разделе рассматриваются процедуры устранения нарушений в работе для туннелей STUN без локального подтверждения (LACK — Local ACKnowledgment). Для туннелей STUN с подтверждением LACK применяются фактически такие же процедуры, но следует помнить, что при этом поддерживаются два сеанса: от первичного устройства к маршрутизатору и от вторичного устройства к маршрутизатору.
В табл. 10.12 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 10.12. SDLC: сеансы, установленные через маршрутизатор,
Проблема
работающий под управлением программного обеспечения STUN, оканчиваются аварийно> '
Решение
Одноранговые узлы не открыты
Шаг 1. Вызовите на выполнение exec-команду show stun, чтобы проверить, являются ли одноранговые узлы открытыми. Если одноранговые узлы открыты, то причиной нарушения в работе является одна из остальных проблем, рассматриваемых в данной таблице.
Ниже приведен пример вывода команды show stun.
Router# show stun
This peer: 131.108.10.1
SerialO — 3174 Controller for test lab (group 1 [sdlc]) state rx-pkts tx-pkts drops poll 7[1]IF Seriallopen203348644058P
10[1]TCP 131.108.8.1open677173310
all[1]TCP 131.108.8.1open61230123385501005
В приведенных здесь результатах выполнения этой команды первая запись показывает, что опрос через посредника разрешен для адреса 7 и последовательный интерфейс 0 эксплуатируется с модулем 8 на первичном конце канала. Через канал получено 20334 пакета, передано 86440 пакетов и уничтожено 5 пакетов.
ПроблемаПроблемаРешениеРешение
Проблема
Проблема
Решение
Решение
Шаг 2. Если одноранговые узлы не открыты, вызовите на выполнение команду debug stun в центральном маршрутизаторе, чтобы проверить, предпринимаются ли попытки открыть одноранговые узлы. Одноранговые узлы не открыты, если в канале отсутствует трафик.
Предостережеиие. Не вызывайте на выполнение команды debug в загруженном маршрутизаторе. Это может привести к снижению производительности или нарушению связи. Вместо этого используйте анализатор протокола или команды show.
Шаг 3. Если результаты выполнения команды не показывают, что предпринимаются попытки открыть одноранговые узлы, воспользуйтесь ехес- командой show interfaces, чтобы убедиться в том, что и интерфейс, и протокол канала связи находятся в рабочем состоянии. Если интерфейс или протокол канала связи не находится в рабочем состоянии, то может иметь место нарушение в работе канала. Перейдите к описанию проблемы “Нарушение в работе физического или канального уровня SDLC”, приведенному ниже в данной таблице.
Шаг 4. Если предпринимаются попытки открыть одноранговые узлы, воспользуйтесь привилегированной exec-командой show running-config, чтобы убедиться в том, что настройка команды stun route и других команд конфигурации STUN выполнена правильно. В случае необходимости откорректируйте конфигурацию маршрутизатора.
Шаг 5. Вызовите на выполнение привилегированную exec-команду debug stun packet в центральном маршрутизаторе. Найдите передаваемые фреймы SNRM или XID.
Шаг 6. Если фреймы SNRM или XID не обнаружены, то нарушение в работе может быть связано с основным каналом. Обратитесь к описанию проблемы “Нарушение в работе физического или канального уровня SDLC”, приведенному ниже в данной таблице.
Не передаются фреймы SNRM или XIDНе передаются фреймы SNRM или XIDШаг 7. Проверьте, нет ли других нарушений в работе сети, таких как уничтожение пакетов интерфейсом, нехватка буферов, перегрузка маршрутизаторов Frame Relay и проблемы маршрутизации IP
Не передаются фреймы SNRM или XID
Не передаются фреймы SNRM или XID
Шаг 1. Вызовите на выполнение команду show stun, чтобы определить, открыты ли одноранговые узлы. Если одноранговые узлы не открыты, см. описание предыдущей проблемы в данной таблице.
Шаг 2. Если одноранговые узлы открыты, вызовите на выполнение привилегированную exec-команду debug stun packet в удаленном оконечном устройстве. Проверьте наличие фреймов SNRM или XID, поступающих от первичного устройства в виде пакетов NDI.
Шаг 3. Если фреймы SNRM или XID поступают, перейдите к описанию следующей проблемы в данной таблице.
Шаг 4. Если фреймы SNRM или XID не поступают, то вызовите на выполнение команду debug stun packet в центральном маршрутизаторе, чтобы проверить, передаются ли фреймы SNRM или XID.
Проблема
Решение
Шаг 5. Если центральный маршрутизатор не передает фреймы SNRM или XID, убедитесь в том, что средства физического и канального уровня функционируют должным образом. Обратитесь к описанию проблемы “Нарушение в работе физического или канального уровня SDLC", приведенному ниже в данной таблице.
Шаг 6. Если центральный маршрутизатор передает фреймы SNRM или XID, вызовите на выполнение привилегированную ехес-команду show running-config, чтобы убедиться в том, что команда stun route в составе конфигурации маршрутизатора задана правильно.
Шаг 7. Проверьте, нет ли других нарушений в работе сети, таких как уничтожение пакетов интерфейсом, нехватка буферов, перегрузка маршрутизаторов Frame Relay и проблемы маршрутизации IP
Отсутствие ответов на фреймы SNRM или XID
Шаг 1. Вызовите на выполнение команду show stun, чтобы определить, открыты ли одноранговые узлы. Если одноранговые узлы не открыты, см. первый раздел данной таблицы.
Шаг 2. Если одноранговые узлы открыты, вызовите на выполнение привилегированную ехес-команду debug stun packet в удаленном оконечном устройстве. Проверьте наличие фреймов SNRM или XID, поступающих от первичного устройства в виде пакетов NDI.
Шаг 3. Если фреймы SNRM или XID не поступают, см. предыдущий раздел данной таблицы.
Шаг 4. Если фреймы SNRM или XID поступают, убедитесь в том, что центральный маршрутизатор передает ответы UA или XID в виде пакетов SDI.
Шаг 5. Если маршрутизатор не передает ответы, то, возможно, нарушена работа канала. Обратитесь к описанию проблемы “Нарушение в работе физического или канального уровня SDLC”, приведенному ниже в данной таблице.
Шаг 6. Если маршрутизатор передает ответы, вызовите на выполнение команду debug stun packet, чтобы определить, поступают ли ответы UA или XID в первичное устройство в виде пакетов SDI.
Шаг 7. Если ответы не поступают в первичное устройство, вызовите на выполнение привилегированную ехес-команду show running-config, чтобы убедиться в том, что в конфигурацию удаленного маршрутизатора введены должным образом команда stun route и другие команды конфигурации STUN. Ниже приведена синтаксическая структура команды stun route.
stun route address address-number top ip-address [local-ack] [priority] [tcp-gueue-max]
Описание синтаксиса
address-number. Представляет собой число, соответствующее соглашениям по адресации TCP.
ip-address. Определяет IP-адрес, по которому другие одноранговые узлы STUN, использующие протокол TCP в качестве средства инкапсуляции STUN, смогут обращаться к этому одноранговому узлу STUN.
Проблема
■ Решение
local-ack. (Необязательный параметр.) Разрешает применение локального подтверждения для STUN.
priority. (Необязательный параметр.) Устанавливает четыре уровня, применяемые при организации очередей по приоритетам: низкий, средний, нормальный и высокий.
■• tcp-gueue-max. (Необязательный параметр.) Устанавливает максималь
ный размер очереди исходящих сообщений TCP для канала SDLC.
Пример
. В следующем примере фрейм с адресом маршрутизации от отправителя, равным 10, передается с использованием инкапсуляции TCP устройству с IP-адресом 131.108.8.1:
stun route address 10 top 131.108.8.1
Шаг 8. Проверьте, нет ли других нарушений в работе сети, таких как уничтожение пакетов интерфейсом, нехватка буферов, перегрузка маршрутизаторов Frame Relay и проблемы маршрутизации IP.
Шаг'9. Если пакеты передаются от начала до конца в обоих направлениях, проверьте конфигурацию оконечных станций, установки режима передачи, параметры конфигурации и т.д.
Нарушение в работе физического или канального уровня SDLC
Шаг 1. Вызовите на выполнение exec-команду show interfaces в канале, подключенном к первичному устройству. Убедитесь в том, что интерфейс и протокол канала связи находятся в рабочем состоянии.
Шаг 2. Если интерфейс или протокол канала связи не находится в рабочем состоянии, убедитесь в том, что на устройства подано питание и они подключены к сети должным образом. Проверьте канал и определите, активен ли он. Проверьте тактовую частоту, убедитесь в отсутствии неправильных настроек адреса, исправьте спецификации NRZ или NRZI и т.д.
Шаг 3. Попытайтесь уменьшить тактовую частоту соединения. Вызовите на выполнение команду конфигурации интерфейса clock rate для установки в качестве значения тактовой частоты для аппаратных соединений в таких последовательных интерфейсах, как NIM и интерфейсные процессоры, допустимой скорости передачи информации.
Ниже приведена синтаксическая структура команды clock rate.
clock rate bps
Описание синтаксиса
• bps. Требуемая тактовая частота в битах в секунду: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148000, 250000, 500000, 800000, 1000000, 1300000, 2000000, 4000000 или 8000000.
Пример
В следующем примере тактовая частота первого последовательного интерфейса устанавливается равной 64000 бит/с: interface serial 0 clock rate 64000
Проблема Решение
Дополнительная информация об устранении нарушений в работе физического и канального уровня SDLC приведена выше, в разделе “SDLC: маршрутизатор не может обмениваться данными с устройством SDLC”
CIP: не активизируется соединение CLAW
Признак неисправности. Соединения CLAW (Common Link Access for Workstations —- доступ рабочих станций к общему каналу) не устанавливаются должным образом через процессор CIP (Channel Interface Processor — процессор канального интерфейса). В выводе exec-команды show extended channel slot/port statistics для соединений CLAW приведено значение N, которое показывает, что эти соединения закрыты.
В табл. 10.13 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 10.13. CIP: не активизируется соединение CLAW 'J
ПроблемаРешение
На хосте не функционирует программное обеспечение TCP/IPУстройства С1Р не перешли в оперативный режим работы с хостомНа хосте не функционирует программное обеспечение TCP/IPУстройства С1Р не перешли в оперативный режим работы с хостомШаг 1. Проверьте, функционирует ли на хосте программное обеспечение TCP/IP.
На хосте не функционирует программное обеспечение TCP/IP
Устройства С1Р не перешли в оперативный режим работы с хостом
На хосте не функционирует программное обеспечение TCP/IP
Устройства С1Р не перешли в оперативный режим работы с хостом
Шаг 2. Если программное обеспечение TCP/IP не функционирует, запустите его на выполнение
Шаг 1. Проведите проверку на мэйнфрейме, чтобы определить, находятся ли устройства С1Р в оперативном режиме работы с хостом.
Шаг 2. Если устройства CIP не находятся в оперативном режиме, переведите их в этот режим. Если устройства не переходят в оперативный режим, обратитесь к разделу “С1Р: интерфейсный процессор не переходит в оперативный режим работы с хостом", приведенному ниже в этой главе.
Шаг 3. Проверьте, был ли выполнен запуск устройства TCP/IP.
Шаг 4. Если запуск устройства не был выполнен, сделайте это.
Примечание. Для запуска устройства может потребоваться остановить и запустить приложение TCP/IP. Но если применяются командные файлы, необходимость в этом может отсутствовать.
Шаг 5. Проверьте конфигурацию для CIP в профиле TCP/IP хоста, а также конфигурацию маршрутизатора для устройства CI Р.
Шаг 6. Вызовите на выполнение команду moretrace claw на хосте либо из командного файла, либо в профиле TCP/IP. Эта команда позволяет отслеживать установление соединений CLAW и может предоставить информацию, необходимую для определения причин нарушений связи
CIP: не загорается светодиод Enabled
Признак неисправности. На плате CIP не загорается светодиод Enabled.
В табл. 10.14 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
|.ОДли|^$1£1а!?:7ж^^ , ,. , , «^ j
ПроблемаРешение
Нарушение в работе аппаратных средствНарушение в работе аппаратных средствШаг 1. Убедитесь в том, что блок маршрутизатора вставлен в стойку и включен.
Нарушение в работе аппаратных средств
Нарушение в работе аппаратных средств
Шаг 2. Вызовите на выполнение exec-команду show version и проверьте, показана ли плата CIP в результатах выполнения этой команды.
Шаг 3. Если плата CIP показана в выводе команды, то может иметь место неисправность светодиода Enabled.
Старый выпуск Cisco IOSСтарый выпуск Cisco IOSШаг 4. Если плата CIP в выводе команды не показана, выньте и снова вставьте плату CIP, перезагрузите маршрутизатор и еще раз проверьте вывод команды show version
Старый выпуск Cisco IOS
Старый выпуск Cisco IOS
Шаг 1. Вызовите на выполнение exec-команду show version, чтобы узнать, какая версия программного обеспечения Cisco IOS эксплуатируется в маршрутизаторе.
Шаг 2. Если в маршрутизаторе используется программное обеспечение Cisco IOS, предшествующее выпуску 10.2(6), необходимо перейти на более современную версию
CIP: интерфейсный процессор не переходит в оперативный режим работы с хостом
Признак неисправности. Плата С1Р не переходит в оперативный режим работы с хостом.
В табл. 10.15 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
; Таблица 10.15. CIP: интерфейсный процессор не переходит■
[.в оперативный режим работы с хостом
ПроблемаРешение
Канал с указанным идентификатором пути (CHPID - Channel Path Identifier) не перешел в оперативный режим работы с хостомКанал с указанным идентификатором пути (CHPID - Channel Path Identifier) не перешел в оперативный режим работы с хостомШаг 1. Убедитесь в том, что на плате CIP горит светодиод Enabled. Если он не горит, см. выше раздел “CIP: не загорается светодиод Enabled”.
Канал с указанным идентификатором пути (CHPID - Channel Path Identifier) не перешел в оперативный режим работы с хостом
Канал с указанным идентификатором пути (CHPID - Channel Path Identifier) не перешел в оперативный режим работы с хостом
Шаг 2. Вызовите на выполнение команду show extended channel slot/port subchannel и проверьте наличие флажка SIGNAL в полученных результатах.
Шаг 3. Если флажок SIGNAL отсутствует, проверьте, переведен ли в оперативный режим работы с хостом канал с идентификатором пути CHPID. Если канал не находится в оперативном режиме, внесите изменения в его конфигурацию для перевода в оперативный режим.
Примечание. В шинном и теговом канале флажок SIGNAL устанавливается при поступлении от хоста сигнала OP_OUT с высоким потенциалом. В канале ESCON флажок SIGNAL устанавливается, если по каналу передается световой сигнал.
ПроблемаРешение
Шаг 4. Если канал с идентификатором пути CHPID не переходит в оперативный режим работы с хостом, проверьте физическое состояние кабельной разводки.
Шаг 5. Если процессор CIP все еше не перешел в оперативный режим, проверьте определения IOCP (Input/Output Control Program — программа управления вводом-выводом) для устройства CIP, а также конфигурацию маршрутизатора
CIP: маршрутизатор не может выполнить эхо-тестирование хоста или хост не может выполнить эхо-тестирование маршрутизатора
Признак неисправности. Попытки выполнить эхо-тестирование хоста с помощью платы CIP маршрутизатора или эхо-тестирование платы CIP маршрутизатора с помощью хоста завершаются неудачей.
В табл. 10.16 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
i Таблица 10.16. CIP: маршрутизатор не может выполнить эхо-тестирование j 'хоста ил и хост не может выполнить эхо-тестирование
[маршрутизатора
ПроблемаРешение
Нарушение Шаг 1. Проверьте, установлено ли соединение CLAW, рассмотрев результа- адресацииты выполнения exec-командыshowextendedchannelslot/port
процессораstatistics в маршрутизаторе.
CIP или хоста Шаг 2, £сли результаты выполнения командыпоказывают,чтосоединения
CLAW не установлены (обозначены как N), см. выше раздел “CIP: не активизируется соединение CLAW".
Шаг 3. Если соединения CLAW установлены (обозначены как Y), вызовите на выполнение привилегированную exec-команду clear counters. Затем попытайтесь выполнить обычную команду эхо-тестирования хоста с маршрутизатора (или маршрутизатора — с хоста).
Шаг 4. После завершения эхо-тестирования снова вызовите на выполнение exec-команду show extended channel slot/port statistics в маршрутизаторе.
Если проводилось эхо-тестирование хоста с маршрутизатора, то хост должен был прочитать пять 100-байтовых сообщений эхо-запросов ICMP, поступивших от маршрутизатора. Поле Total Blocks в выводе команды show должно показать, что считаны пять блоков. Если хост ответил, то вывод команды должен показать, что записаны пять блоков.
Если проводилось эхо-тестирование маршрутизатора с хоста, то хост должен был передать один 276-байтовый эхо-запрос ICMP в маршрутизатор. Поле Write должно показать, что записан один блок. Если маршрутизатор ответил, то в выводе должен быть показан один блок в поле Read.
ПроблемаРешение
Шаг 5. Если эти условия не соблюдаются, то может иметь место нарушение адресации между процессором CIP и хостом. Проверьте все IP- адреса в маршрутизаторе и в профиле TCP/IP хоста и убедитесь в том, что они заданы правильно
CIP: хост не может установить связь с удаленными сетями
Признак неисправности. Хост мэйнфрейма не может установить связь с сетями через маршрутизатор.
В табл. 10.17 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
1 Таблица 10.17.
, CIP: хост не может установить связь с удаленными сетями 8
Проблема
Решение
Отсутствуют
Шаг 1. Если хост мэйнфрейма не может установить связь с сетями через
или непра-
• маршрутизатор, то попытайтесь выполнить эхо-тестирование уда-
вильно на-
ленной сети с маршрутизатора.
строены маршруты IP
Если эхо-тестирование выполняется успешно, перейдите к шагу 4.
Шаг 2. Если же эхо-тестирование оканчивается неудачей, вызовите на выполнение привилегированную exec-команду show ip route, чтобы проверить, доступна ли сеть для маршрутизатора.
Шаг 3. Если маршрут к рассматриваемой сети отсутствует, проверьте правильность конфигурации сети и маршрутизатора.
Шаг 4. Убедитесь в том, что соединение с хостом является активным, выполнив эхо-тестирование IP-адреса хоста из маршрутизатора. Если попытка провести эхо-тестирование оканчивается неудачей, см. выше раздел “CIP: маршрутизатор не может выполнить эхо- тестирование хоста или хост не может выполнить эхо-тестирование маршрута затора”.
Шаг 5. Вызовите на выполнение команду netstat gate в хосте и проверьте наличие маршрута к сети.
Шаг 6. Если маршрут не существует, убедитесь в том, что хост использует адрес платы CIP маршрутизатора в качестве маршрута, заданного по умолчанию. Если это условие не соблюдается, добавьте оператор GATEWAY в профиль TCP/IP, который указывает на рассматриваемую сеть, или назначьте адрес платы CIP в маршрутизаторе в качестве маршрута, заданного по умолчанию, с использованием оператора DEFAULTNET в профиле TCP/IP
CIP: хост, в котором функционирует демон routed, не имеет информации о маршрутах
Признак неисправности. Хост, в котором функционирует демон routed, не имеет информации о маршрутах к удаленным сетям.
В табл. 10.18 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
! Таблица 10.18. CIP: хост, в котором функционирует демон routed, не имеет j информации о маршрутах •-jd
Проблема
Решение
В маршрутизаторе не выполнена должным образом настройка конфигурации RIP
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Убедитесь в том, что в маршрутизаторе выполнена настройка конфигурации RIP. Если настройка конфигурации RIP не выполнена, сделайте это.
Шаг 2. Проверьте конфигурацию, чтобы определить, имеются ли операторы network для каждой из сетей, о которых должны поступать извещения в обновлениях RIP. Если эти операторы отсутствуют, введите их в состав конфигурации.
Шаг 3. Убедитесь в том, что в конфигурацию интерфейса канала не входит команда passive-interface.
Шаг 4. Если указанная команда входит в состав конфигурации, удалите ее с помощью команды конфигурации маршрутизатора no passiveinterface.
Шаг 5. Убедитесь в том, что отсутствуют операторы distribute-list, которые отфильтровывают пакеты обновления маршрутизации RIP.
Шаг 6. Проверьте конфигурацию маршрутизатора, чтобы удостовериться, что в команде конфигурации интерфейса claw указано ключевое слово broadcast. Ниже приведена синтаксическая структура команды claw, claw path device-address ip-address host-name device-name host-app device-app [broadcast]
Пример ,
В следующем примере показано, как разрешить применение маршрутизации с подключением каналов IBM к порту 0 платы CIP, который поддерживает непосредственно подключенный канал ESCON: interface channel 3/0
ip address 198.92.0.1 255.255.255.0
claw 0100 00 198.92.0.21 CISCOVM EVAL TCPIP TCPIP
Шаг 7. Если ключевое слово broadcast не задано, введите его в состав конфигурации
Неправильная настройка конфигурации хоста
Шаг 1. Вызовите на выполнение команду netstat gate в хосте. Проверьте наличие информации о маршрутах, полученной с помощью обновлений RIP.
Шаг 2. Если маршруты RIP отсутствуют, убедитесь в том, что соединение с хостом активно, выполнив эхо-тестирование IP-адреса хоста из маршрутизатора.
Шаг 3. Если эхо-тестирование оканчивается неудачей, см. выше раздел “CIP: маршрутизатор не может выполнить эхо-тестирование хоста или хост не может выполнить эхо-тестирование маршрутизатора".
Проблема
Решение
Шаг 4. Убедитесь в том, что на хосте функционирует демон routed.
Шаг 5. Вызовите на выполнение exec-команду show extended channel slot/port stat, чтобы проверить, что в результате приема обновлений маршрутизации RIP значения счетчиков увеличиваются.
Шаг 6. Проверьте профиль TCP/IP в хосте, чтобы убедиться в том, что в нем вместо операторов GATEWAY присутствуют операторы BSDROUTINGPARMS
Глава
11
Устранение нарушений
- в работе сети DECnet
Корпорация Digital Equipment Corporation (или просто Digital) разработала семейство протоколов DECnet, реализовав тем самым тщательно продуманный способ организации взаимодействия выпускаемых ею компьютеров. Первая версия DECnet, которая была выпущена в 1975 году, позволяла обеспечить взаимодействие двух непосредственно соединенных компьютеров PDP-11. Затем корпорация Digital включила в семейство протоколов f; DECnet средства поддержки других протоколов, но собственные протоколы DECnet оста- ются наиболее важнымй из всех сетевых продуктов Digital.
К настоящему времени выпущено пять основных версий сетевых продуктов DECnet (последнюю версию иногда называют Phase V, а в литературе Digital она упоминается под ^ названием DECnet/OSI). Версия DECnet Phase V представляет собой надмножество набора протоколов OSI и поддерживает все протоколы OSI, а также несколько других собственных и стандартных протоколов, которые поддерживались и в предыдущих версиях DECnet. Как и при всех других сменах версий протоколов, версия DECnet Phase V является совместимой с предыдущей версией (в данном случае Phase IV).
Сетевая структура Digital
-у Вопреки общепринятому мнению, протоколы DECnet вообще не определяют сетевую структуру, а скорее представляют собой ряд продуктов, соответствующих спецификации DNA (Digital Network Architecture — цифровая сетевая структура) корпораций Digital. Как и большинство других всеобъемлющих спецификаций сетевых структур крупных поставщиков системного программного обеспечения, DNA поддерживает широкий набор и собственных, и стандартных протоколов. Перечень технологий, -^(‘поддерживаемых структурой DNA, постоянно расширяется по мере того, как корпо- * рация Digital реализует все новые и новые протоколы. На рис. 11.1 показана упрощенная схема DNA и представлены взаимосвязи между некоторыми ее компонентами иуровнями эталонной модели OSI.
Как показывает рис. 11.1, структура DNA поддерживает множество версий передающей среды и целый ряд реализаций протоколов канального уровня. К ним отно- сятся такие широко известные стандарты, как Ethernet, Token Ring, FDDI, IEEE 802.2 и X.25. В структуре DNA предоставляется также традиционный протокол канального
уровня DDCMP и обеспечивается возможность применения в кластерах VAX шины CI с пропускной способностью 70 Мбит/с.
Приложения DNAПриложения OSIСлужба имен DNAУправление сеансом DNAПредставительский уровень OSIСеансовый уровень OSINSP, ТРО, TP2, TP4ES-ISIS-ISБез установленияС установлениемсоединения (CLNP, CLNS)соединения (Х.25, CMNP)Различные протоколы доступа к каналуПриложения DNAПриложения OSIСлужба имен DNAУправление сеансом DNAПредставительский уровень OSIСеансовый уровень OSINSP, ТРО, TP2, TP4ES-ISIS-ISБез установленияС установлениемсоединения (CLNP, CLNS)соединения (Х.25, CMNP)Различные протоколы доступа к каналуРис. 11.1. Взаимосвязь структуры DNA и эталонной модели OSIРис. 11.1. Взаимосвязь структуры DNA и эталонной модели OSI
Приложения DNA
Приложения OSI
Служба имен DNA
Управление сеансом DNA
Представительский уровень OSI
Сеансовый уровень OSI
NSP, ТРО, TP2, TP4
ES-ISIS-IS
Без установленияС установлением
соединения (CLNP, CLNS)соединения (Х.25, CMNP)
Различные протоколы доступа к каналу
Приложения DNA
Приложения OSI
Служба имен DNA
Управление сеансом DNA
Представительский уровень OSI
Сеансовый уровень OSI
NSP, ТРО, TP2, TP4
ES-ISIS-IS
Без установленияС установлением
соединения (CLNP, CLNS)соединения (Х.25, CMNP)
Различные протоколы доступа к каналу
Рис. 11.1. Взаимосвязь структуры DNA и эталонной модели OSI
Рис. 11.1. Взаимосвязь структуры DNA и эталонной модели OSI
Сетевой уровень
Набор протоколов DECnet поддерживает и протоколы без установления логического соединения, и протоколы с установлением логического соединения. Протоколы обоих типов реализованы с помощью протоколов OSI. В реализации протоколов без установления логического соединения используется протокол CLNP (ConnectionLess Network Protocol — протокол сетевого обслуживания без установления соединения) и служба CLNS. В реализации протоколов с установлением логического соединения применяется протокол PLP (Packet-Level Protocol — протокол пакетного уровня), соответствующий спецификации Х.25, который известен также под названием Х.25 уровня 3, и протокол CONP (Connection-Oriented Network Protocol — протокол сетевого обслуживания с установлением соединения).
Основная часть структуры DNA была приведена в соответствие с эталонной моделью OSI только в версии DECnet Phase V, но маршрутизация в версии DECnet Phase IV уже была во многом аналогична маршрутизации OSI. Маршрутизация DECnet в версии Phase V состоит из средств маршрутизации OSI (ES-IS и IS-IS), но в ней по- прежнему обеспечивается поддержка протокола маршрутизации DECnet Phase IV.
Формат фрейма маршрутизации DECnet Phase IV
Протокол маршрутизации DECnet Phase IV во многом отличается от протокола ISIS. Одно из отличий заключается в том, что в них применяются разные заголовки пакетов. Заголовок пакета уровня маршрутизации DNA Phase IV показан на рис. 11.2; форматы пакета IS-IS описаны в главе 12.
Длина поля в байтах1221
Флажки
Узел
Узел
Транзитные
маршрутизации
получателя
отправителя
узлы
Рис. 11.2. Заголовок пакета уровня маршрутизации DNA Phase IV
Первое поле в заголовке маршрутизации DNA Phase IV представляет собой поле флажков маршрутизации, которое включает следующие биты.
Бит возврата к отправителю; если этот бит установлен, он указывает, что пакет возвращается к отправителю.
Бит запроса возврата к отправителю; если этот бит установлен, он указывает, что пакеты запроса должны быть возвращены к отправителю, если их невозможно доставить получателю.
Бит intraLAN, который установлен по умолчанию. Если маршрутизатор обнаруживает, что две взаимодействующие оконечные системы не находятся в одной и той же подсети, он сбрасывает этот бит.
Другие биты указывают формат заголовка, позволяют определить, используется ли дополнение, а также выполняют другие функции.
Поля узла получателя и узла отправителя задают сетевые адреса узлов получателя и отправителя.
Поле с информацией о количестве пройденных узлов показывает, через какое количество узлов прошел пакет на пути к получателю. Это поле позволяет учесть максимально допустимое число пройденных участков маршрута для выполнения операции удаления устаревших пакетов из сети.
В спецификации DECnet узлы подразделяются на два типа: оконечные и маршрутизирующие. И оконечные, и маршрутизирующие узлы могут передавать и принимать информацию по сети, но только маршрутизирующие узлы могут предоставлять услуги по маршрутизации для других узлов DECnet.
В сети DECnet решения по выбору маршрутов принимаются с учетом так называемой стоимости — произвольной величины, назначаемой сетевым администратором для использования при сравнении различных путей через среду объединенной сети. Значения стоимости обычно распределяются с учетом количества участков маршрута, пропускной способности передающей среды или других характеристик сети. Чем ниже стоимость, тем лучше путь. При возникновении неисправностей в сети программное обеспечение протокола маршрутизации DECnet Phase IV использует значения стоимости для повторного определения наилучших путей к каждому получателю. На рис. 11.3 показано, как вычисляется стоимость в среде маршрутизации DECnet Phase IV.
Наилучший маршрут к получателю
ПолучательПолучательОтправитель —►Отправитель —►Рис. 11.3. Вычисление стоимости в протоколе маршрутизации DECnet Phase IVРис. 11.3. Вычисление стоимости в протоколе маршрутизации DECnet Phase IV
Получатель
Получатель
Отправитель —►
Отправитель —►
Рис. 11.3. Вычисление стоимости в протоколе маршрутизации DECnet Phase IV
Рис. 11.3. Вычисление стоимости в протоколе маршрутизации DECnet Phase IV
Адресация
Адреса DECnet не связаны с физическими сетями, к которым подключены узлы. Вместо этого в сети DECnet положение хостов определяется с помощью пары адресов зона- узел. Номер зоны должен находиться в пределах от 1 до 63 включительно. Адрес узла должен находиться в пределах от 1 до 1023 включительно. Поэтому каждая зона может иметь 1023 узла и в сети DECnet может быть адресовано примерно 65 тысяч узлов. Зоны могут охватывать несколько маршрутизаторов, а в одном сетевом сегменте может быть определено много зон. Поэтому если узел имеет несколько сетевых интерфейсов, в нем применяется одна и та же пара адресов зона—узел для каждого интерфейса. На рис. 11.4 показан пример сети DECnet с несколькими адресуемыми объектами.
Рис. 11.4. Примеры адресов DECnetРис. 11.4. Примеры адресов DECnet
Рис. 11.4. Примеры адресов DECnet
Рис. 11.4. Примеры адресов DECnet
В хостах DECnet не применяются назначенные изготовителем адреса уровня МАС. Вместо этого адреса сетевого уровня встраиваются в адрес уровня МАС в соответствии с алгоритмом, который предусматривает умножение номера зоны на 1024 и сложение с этим произведением номера узла. Результирующий 16-битовый десятичный адрес преобразуется в шестнадцатеричное число и добавляется к адресу АА00.0400 в обратном порядке байтов, начиная с младшего байта. Например, адрес DECnet 12.75 преобразуется в число 12363 (по основанию 10), которое равно 304В (по основанию 16).
После добавления этого адреса с перестановкой байтов к стандартному префиксу МАС-адреса DECnet результирующий адрес принимает вид АА00.0400.4В30.
Уровни маршрутизации
В качестве маршрутизирующих узлов DECnet могут применяться маршрутизаторы уровня 1 или 2. Маршрутизатор уровня 1 взаимодействует с оконечными узлами и с другими маршрутизаторами уровня 1 в конкретной зоне. Маршрутизаторы уровня 2 взаимодействуют с маршрутизаторами уровня 1 в той же зоне и с маршрутизаторами уровня 2 в других зонах. Маршрутизаторы уровней 1 и 2 образуют иерархическую схему маршрутизации. Пример такой схемы приведен на рис. 11.5.
Рис. 11.5. Маршрутизаторы DECnet уровней 1 и 2
Оконечные системы передают запросы маршрутизации назначенному маршрутизатору уровня 1. В качестве назначенного маршрутизатора уровня. 1 выбирается маршрутизатор с наивысшим приоритетом. Если два маршрутизатора имеют одинаковый приоритет, то назначенным становится маршрутизатор с наибольшим номером узла. Приоритет маршрутизатора можно откорректировать в конфигурации вручную, чтобы вынудить его стать назначенным маршрутизатором.
Как показано на рис. 11.5, в любой зоне может присутствовать несколько маршрутизаторов уровня 2. Если маршрутизатор уровня 1 должен передать пакет за пределы своей зоны, он перенаправляет пакет любому маршрутизатору уровня 2 в той же зоне. В некоторых случаях маршрутизатор уровня 2 может не иметь информации об оптимальном пути к получателю, но конфигурация сети с большим количеством избыточных связей обладает высокой отказоустойчивостью, которой нельзя достичь, просто назначив по одному маршрутизатору уровня 2 в каждую зону.
Транспортный уровень
Транспортный уровень DNA реализован на основе разнообразных транспортных протоколов — и собственных, и стандартных. В эталонной модели OSI поддерживаются транспортные протоколы ТРО, ТР2 и ТР4.
Собственный протокол NSP (Network Services Protocol — протокол сетевых служб) корпорации Digital функционально аналогичен протоколу ТР4 в том отношении, что он предоставляет службу с установлением логического соединения и управлением потоком данных, которая обеспечивает фрагментацию и повторную сборку пакетов. В нем поддерживаются два подканала: один — для обычных данных, а второй — для срочных данных и информации управления потоком данных. Поддерживаются также средства управления потоком данных двух типов: простой старт-стопный механизм, с помощью которого получатель сообщает отправителю о том, что нужно приостановить или возобновить передачу данных, и более сложный метод управления потоком данных, при котором получатель сообщает отправителю, какое количество сообщений он может принять. Протокол NSP реагирует также на уведомления о заторах, полученные от программного обеспечения сетевого уровня, уменьшая количество неотправленных сообщений, которые он может поставить в очередь.
Протоколы верхнего уровня
Спецификация DECnet допускает размещение над транспортным уровнем собственных протоколов верхнего уровня Digital, а также стандартных протоколов верхнего уровня модели OSI. В прикладных протоколах DECnet применяются протокол управления сеансом DNA и служба имен DNA. Прикладные протоколы OSI поддерживаются реализациями протоколов представительского и сеансового уровней OSI.
Поиск неисправностей DECnet
В настоящем разделе описаны процедуры, позволяющие устранить нарушения в работе, характеризующиеся отсутствием связи и низкой производительностью программного обеспечения версии Phase IV DECnet. Эти процедуры могут применяться только в такой сетевой среде, в которой в маршрутизаторе разрешено применение маршрутизации DECnet, а не в среде, в которой устанавливаются мостовые соединения DECnet (иными словами, разрешено применение мостовых соединений в интерфейсах маршрутизатора и передаются фреймы типа EtherType 6003).
В настоящей главе не рассматриваются другие протоколы Digital, такие как МОР, LAT (Local-Area Transport — локальная передача), LAVC (Local-Area VAX Cluster — локальный кластер VAX) и LAST (Local-Area Systems Technology — технология локальных систем).
Примечание
Дополнительная информация об устранении нарушений в работе сети ISO CLNS (DECnet Phase V) приведена в главе 12.
Ниже, в разделе “Применение спецификации DECnet в мультипротокольной среде” рассматриваются проблемы, которые могут возникать при использовании протоколов DECnet в объединенной сети, в которой эксплуатируются и другие протоколы. В остальных разделах описаны конкретные признаки неисправностей в сети DECnet, проблемы, которые могут вызвать появление каждого признака неисправности, а также представлены решения этих проблем.
В следующих разделах кратко рассмотрены наиболее характерные нарушения в работе сетей DECnet.
DECnet: попытки установления соединений с хостами DEC через маршрутизатор оканчиваются неудачей (нарушение в работе оконечного узла).
DECnet: попытки установления соединений с хостами DEC через маршрутизатор оканчиваются неудачей (нарушение в работе маршрутизатора).
DECnet: оконечные узлы не могут найти назначенный маршрутизатор.
DECnet: маршрутизатор или оконечный узел обнаруживает неправильно назначенный маршрутизатор.
DECnet: маршрутизаторы не устанавливают отношения смежности.
DECnet: отношения смежности маршрутизирующего узла то устанавливаются, то разрываются.
DECnet: отсутствие связи между сетевыми устройствами Phase IV по опорной сети Phase V.
DECnet: низкая производительность.
Примечание
В некоторых приведенных ниже описаниях признаков неисправности для иллюстрации определенных ошибок используются сообщения ОРСОМ (OPerator Communication Manager— диспетчер операторской связи). В таких случаях предполагается, что работает программное обеспечение ОРСОМ и разрешено ведение журналов событий. Дополнительная информация о ведении журналов событий приведена ниже, в разделе “Настройка узла DECnet для работы в режиме регистрации событий DECnet”.
Применение спецификации DECnet в мультипротокольной среде
Важно помнить, что в спецификации DECnet предусмотрено изменение МАС- адресов интерфейсов маршрутизатора. Такая организация работы может привести к нарушению работы других протоколов, которые уже разрешены в маршрутизаторе.
Если после того, как в интерфейсе маршрутизатора будет разрешено применение протокола DECnet, из-за нарушения работы средств преобразования адреса теряется возможность установления связи с помощью других протоколов (таких как Novell IPX
или XNS), то проблема, вероятно, заключается в том, что программное обеспечение DECnet изменяет МАС-адрес интерфейса маршрутизатора.
Как правило, следует вначале разрешить в интерфейсах маршрутизатора применение протокола DECnet, а затем и других протоколов. Но если такой подход неприемлем, сохраните конфигурацию маршрутизатора с помощью команды copy runningconfig startup-config, после чего перезагрузите маршрутизатор.
DECnet: попытки установления соединений с хостами DEC через маршрутизатор оканчиваются неудачей (нарушение в работе оконечного узла)
Признак неисправности. Узлы DECnet не могут вступить во взаимодействие при попытке установить соединение через маршрутизаторы.
Примечание
В настоящем разделе в основном рассматриваются проблемы, связанные с нарушениями в работе оконечных узлов. Для ознакомления с проблемами и решениями, которые связаны с нарушениями в работе маршрутизатора, обратитесь к разделу “DECnet: попытки установления соединений с хостами DEC через маршрутизатор оканчиваются неудачей (нарушение в работе маршрутизатора)”, приведенному ниже в этой главе.
В табл. 11.1 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 11.1.Таблица 11.1.DECnet: попытки установления соединений с хостами DEC | через маршрутизатор оканчиваются неудачей (нарушение j в работе оконечного узла) ''j
Таблица 11.1.
Таблица 11.1.
ПроблемаПроблемаРешение
Проблема
Проблема
Неправильно настроена конфигурация оконечного узлаНеправильно настроена конфигурация оконечного узлаШаг 1. Проверьте конфигурацию оконечного узла с помощью команды show executor characteristics программы NCP.
Неправильно настроена конфигурация оконечного узла
Неправильно настроена конфигурация оконечного узла
Шаг 2. Убедитесь в том, что тип оконечного узла (немаршрутизирующий версии Phase IV, маршрутизирующий версии Phase IV, зональный), адрес узла, имя узла, а также параметры маршрутизации и канала заданы правильно.
Шаг 3. Проверьте характеристики цепей с помощью команды show known circuit characteristics программы NCP.
Шаг 4. Убедитесь в том, что назначенный маршрутизатор, таймер hello- сообщений, приоритет маршрутизатора (если узел является маршрутизирующим) и другие характеристики цепей в составе конфигурации заданы правильно.
Ниже приведены команды decnet, применяемые для установки назначенного маршрутизатора, таймера hello-сообщений и приоритета маршрутизатора в маршрутизаторе Cisco.
decnet hello-timer seconds
Проблема
Решение
seconds. Интервал, через который программное обеспечение Cisco IOS передает hello-сообшения. Он устанавливается в секундах и может представлять собой десятичное число в диапазоне от 1 до 8191 с. Значение по умолчанию 15 с.
decnet router-priority value
Команда конфигурации интерфейса decnet router-priority позволяет выбрать назначенный маршрутизатор, в который будут передаваться пакеты, если не указан адрес получателя.
value. Приоритет маршрутизатора. Он может представлять собой число в диапазоне от 0 до 127. Чем больше это число, тем выше приоритет. По умолчанию приоритет устанавливается равным 64.
Шаг 5. Откорректируйте конфигурацию оконечного узла, если какие-либо из его параметров или характеристик цепи заданы неправильно. Дополнительная информация о настройке конфигурации оконечных узлов приведена в документации поставщика
Средства управления доступом хоста отвергают попытки соединения
При возникновении этой проблемы пользователи получают сообщение "connect failed, access control rejected". Эта проблема, как правило, связана с нарушением в работе программного обеспечения сеансового уровня.
Шаг 1. Убедитесь в том, что удовлетворены следующие требования:
информация управления доступом, представленная пользователем, является правильной;
правильно установлены параметры доступа прокси-анализаторов;
правильно установлены база данных прокси-анализаторов и учетная запись прокси-анализаторов.
Шаг 2. Убедитесь в том, что параметры контролируемого доступа пользователя соответствуют спецификации доступа пользователя в удаленных системах.
Шаг 3. При обнаружении нарушений в любой из этих зон внесите необходимые изменения
Нераспознанный объект
При возникновении этой проблемы пользователи получают сообщение "connect failed, unrecognized object".
Шаг 1. Вызовите на выполнение команду tell программы NCP для получения информации о том, определен ли данный объект в целевом узле. Ниже приведена синтаксическая структура команды tell, tell target-node-name show known objects
Шаг 2. Если данный объект не определен, зарегистрируйтесь в качестве суперпользователя и вызовите на выполнение программу NCP, чтобы следующим образом определить объект с помощью команды set object программы NCP: set object object-id
Шаг 3. После определения объекта вызовите на выполнение команду tell программы NCP и проверьте следующим образом, задан ли для объекта файл: tell target-node-name show object object-id character
Проблема
Решение
Шаг 4. Выйдите из программы NCP и проверьте, существует ли файл, заданный для рассматриваемого объекта.
Шаг 5. Если файл для рассматриваемого объекта не существует, создайте этот файл.
Шаг 6. Убедитесь в том, что права доступа к указанному файлу заданы правильно
Нехватка ресурсов
Если возникает ошибка, связанная с нехваткой ресурсов, пользователи VMS (Virtual Memory System — система виртуальной памяти) получают следующее сообщение:
% system-E-REMRSC, insufficient system resource at remote node
Примечание. Это сообщение об ошибке может не указывать на наличие проблемы. Дело в том, что низкие значения параметров иногда устанавливаются преднамеренно для предотвращения создания сетевых соединений свыше определенного количества.
Попытайтесь настроить следующие параметры целевой системы DEC.
Параметры SYSGEN:
MAXPROCESSCNT.
Параметры NCP:
MAXIMUM LINKS;
ALIAS MAXIMUM LINKS.
Параметры AUTHORIZE:
MAXJOBS;
MAXACCTJOBS
Настройка узла DECnet для работы в режиме регистрации событий DECnet
Сетевая среда DECnet позволяет не только воспользоваться диагностическими инструментальными средствами маршрутизатора, но и предоставляет широкий перечень диагностической информации. Для контроля над событиями в сети DECnet на узлах DECnet можно применить средства регистрации событий (EVL — Event Logging Facility) DECnet. Средства EVL позволяют следить за такими важными событиями в сети, как потеря пакетов и отказ цепей.
Описанные ниже шаги кратко характеризуют основные задачи, которые должны быть решены для обеспечения регистрации событий в системе VMS.
Шаг 1. Определите, функционирует ли процесс ОРСОМ:
$ show system
Шаг 2. Если процесс ОРСОМ не появляется в списке функционирующих процессов, введите следующую команду для его запуска:
$ @sys$system:STARTUP.com ОРСОМ
Шаг 3. Воспользуйтесь программой NCP, чтобы разрешить применение средств регистрации событий:
$ MCR NCP
NCP> SET logging MONITOR KNOWN Events
NCP> DEFINE logging MONITOR KNOWN Events
NCP> SET logging MONITOR STATE ON
NCP> DEFINE logging MONITOR STATE ON
Шаг 4. Выйдите из программы NCP:
NCP> Exit"
Шаг 5. Для контроля за событиями в сети с терминала консоли введите следующую команду в приглашении к вводу команд системы VMS:
$ REPLY/ENABLE = NETWORK
(Эта команда эквивалентна привилегированной ехес-команде terminal monitor.)
DECnet: попытки установления соединений с хостами DEC через маршрутизатор оканчиваются неудачей (нарушение в работе маршрутизатора)
Признак неисправности. Узлы DECnet не могут обмениваться данными при попытке установить соединения через маршрутизаторы.
Примечание
В настоящем разделе в основном рассматриваются проблемы, связанные с нарушениями в работе маршрутизатора. Для ознакомления с проблемами и решениями, которые связаны с нарушениями в работе оконечных узлов, см. выше раздел “DECnet: попытки установления соединений с хостами DEC через маршрутизатор оканчиваются неудачей (нарушение в работе оконечного узла)”.
В табл. 11.2 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 11.2. DECnet: попытки установления соединений с хостами DEC ; j 1через маршрутизатор оканчиваются неудачей (нарушение
' в работе маршрутизатора)
РешениеРешениеПроблема
Решение
Решение
В маршрутизаторе не разрешена поддержка маршрутизации DECnetВ маршрутизаторе не разрешена поддержка маршрутизации DECnetШаг 1. Вызовите на выполнение привилегированную exec-команду show decnet interfaces, чтобы определить, в каких интерфейсах разрешена поддержка сети DECnet.
В маршрутизаторе не разрешена поддержка маршрутизации DECnet
В маршрутизаторе не разрешена поддержка маршрутизации DECnet
Шаг 2. Если результаты выполнения этой команды показывают, что поддержка сети DECnet не разрешена, воспользуйтесь привилегированной exec-командой show running-config для просмотра информации о конфигурации маршрутизатора. Определите, входят ли в конфигурацию маршрутизатора спецификации глобальных команд и команд конфигурации интерфейса DECnet.
Шаг 3. Разрешите применение маршрутизации DECnet в соответствующих маршрутизаторах и интерфейсах. Дополнительная информация о настройке конфигурации DECnet приведена в документе Cisco IOS Network Protocols Configuration Guide, Part 2
Проблема
Решение
Отсутствует команда decnet cost
Шаг 1. Убедитесь в том, что в конфигурации интерфейсов DECnet определена стоимость. Проверьте наличие в составе конфигурации записи команды конфигурации интерфейса decnet cost cost-value.
Шаг 2. Если эта команда отсутствует, введите команду decnet cost в конфигурацию каждого интерфейса, в котором разрешено применение маршрутизации DECnet
Несоответствие номеров оконечных узлов и номера зоны маршрутизатора
Шаг 1. Проверьте конфигурацию оконечных узлов и маршрутизаторов в рассматриваемом сетевом сегменте. Проверьте адрес зоны, заданный в оконечных узлах и маршрутизаторах.
Шаг 2. Если в оконечном узле задана иная зона по сравнению с маршрутизатором в сегменте, необходимо либо установить в качестве адреса оконечного узла такое же значение, как и в маршрутизаторе в данном сегменте, либо откорректировать конфигурацию маршрутизатора в сегменте, указав такой же номер зоны, как и в оконечном узле
Фактическая стоимость доступа к зоне получателя превышает значение стоимости, заданное в конфигурации
Шаг 1. Вызовите на выполнение exec-команду show decnet interfaces, чтобы определить значение максимальной стоимости доступа к зоне получателя в составе конфигурации.
Шаг 2. Воспользуйтесь exec-командой show decnet route, чтобы определить фактическую стоимость доступа к зоне получателя.
Шаг 3. Если фактическая стоимость превышает значение максимальной стоимости, заданное в конфигурации, увеличьте значение максимальной стоимости, заданное в составе конфигурации маршрутизатора.
В маршрутизаторах уровня 1 для увеличения максимальной стоимости доступа к зоне применяется глобальная команда конфигурации decnet max-cost.
В маршрутизаторах уровня 2 для увеличения максимальной стоимости доступа к зоне применяется глобальная команда конфигурации decnet area-max-cost
Фактическое число участков маршрута на пути к получателю превышает заданное в конфигурации максимальное число участков маршрута
Шаг 1. Вызовите на выполнение команду show decnet interface, чтобы определить максимальное число участков маршрута, которое может применяться для маршрутизации пакетов между зонами.
Шаг 2. Воспользуйтесь exec-командой show decnet route, чтобы определить фактическое число участков маршрута на пути к получателю в соответствии с данными, приведенными в таблице маршрутизации DECnet.
Шаг 3. Если фактическое число участков маршрута превышает заданное в конфигурации максимально допустимое число участков маршрута, увеличьте значение максимального числа участков маршрута в составе конфигурации маршрутизатора.
В маршрутизаторах уровня 1 для увеличения максимального числа участков маршрута применяется глобальная команда конфигурации decnet max-hops.
В маршрутизаторах уровня 2 для увеличения максимального числа участков маршрута применяется глобальная команда конфигурации decnet area-max-hops
Проблема
Решение
Неправильная
Шаг 1. Вызовите на выполнение привилегированную exec-команду show
настройка
decnet access-list, чтобы определить, выполнена ли настройка в
конфигурации
конфигурации маршрутизатора списков доступа DECnet.
списков доступа
Шаг 2. Если к интерфейсам маршрутизатора применяются какие-либо спи-
ски доступа, воспользуйтесь привилегированной ехес-командой debug decnet connects, чтобы определить, перенаправляются ли должным образом важные сетевые пакеты.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 3. Если пакеты уничтожаются, отмените использование всех списков
доступа в маршрутизаторе с помощью команды конфигурации интерфейса no decnet access-group.
Шаг 4. Определите, появилась ли теперь возможность устанавливать соеди-
нения с хостами. Если соединения устанавливаются успешно, то нарушение в работе может быть вызвано неправильной настройкой конфигурации списка доступа.
Шаг 5. Введите списки доступа в конфигурацию маршрутизатора с исполь-
зованием команды конфигурации интерфейса decnet access-group. Вводите списки по одному, до тех пор, пока создание соединений станет невозможным, и тем самым будет обнаружен список доступа, содержащий ошибку.
Шаг 6. В случае необходимости откорректируйте список доступа. Обяза-
тельно включите явно заданные операторы permit для трафика, который должен перенаправляться обычным образом.
Шаг 7. Если описанные выше действия не позволяют устранить нару-
шения в работе, продолжайте процесс поиска неисправностей до тех пор, пока не будут исправлены все неправильно настроен-
ные списки доступа
Адрес узла
Шаг 1. Воспользуйтесь привилегированной ехес-командой show running-
выходит за
config для просмотра информации о конфигурации маршрутиза-
пределы до-
тора. Проверьте, выполнена ли настройка в составе конфигура-
ции глобальной команды конфигурации decnet max-address. Эта
диапазона
команда устанавливает наибольший номер узла DECnet, разрешенный в этой зоне.
Проблема
Решение
Примечание. Команда decnet max-address задает наибольший номер узла, который может применяться в некоторой зоне, а не максимальное количество адресов узлов, разрешенных к применению в этой зоне. Например, если в состав конфигурации маршрутизатора введена команда decnet max-address 1000, а в конфигурации одного из узлов задан адрес узла 1001, этот адрес выходит за пределы диапазона.
Шаг 2. По умолчанию максимальный адрес равен 1023. Но если в конфигурацию введено другое значение, то адрес узла может превысить значение, заданное в конфигурации. Если дело обстоит таким образом, увеличьте максимальное значение адреса с помощью команды decnet max-address
Разъединенная зона
Убедитесь в том, что в топологии данной сети отсутствуют разъединенные зоны. Если в сети имеются какие-либо разъединенные зоны, измените топологию сети: откорректируйте адреса зон или введите дополнительный путь (с помощью маршрутизатора), позволяющий создать единую сеть
Нарушение в работе передающей среды
Дополнительная информация об устранении нарушений в работе последовательных каналов приведена в главе 15. Для получения более подробной информации об устранении нарушений в работе передающей среды локальной сети обратитесь к главе данной книги, в которой рассматриваются вопросы устранения нарушений в работе передающей среды, применяемой в конкретной сети
DECnet: оконечные узлы не могут найти назначенный маршрутизатор
Признак неисправности. Оконечные узлы не могут найти назначенный маршрутизатор. Оконечные узлы не могут обратиться к узлам, находящимся в других локальных сетях, но другие узлы, подключенные к той же локальной сети, доступны.
В табл. 11.3 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
I Таблица 11.3. DECnet: оконечные узлы не могут найти назначенный • г' маршрутизатор. ^ ,■I
Проблема
Решение
В маршрутизаторе не разрешена поддержка маршрутизации DECnet
Шаг 1. Вызовите на выполнение привилегированную exec-команду show running-config, чтобы ознакомиться с информацией о конфигурации маршрутизатора. Определите, входят ли в конфигурацию маршрутизатора спецификации глобальных команд и команд конфигурации интерфейса DECnet.
Шаг 2. Разрешите применение маршрутизации DECnet в соответствующих маршрутизаторах и интерфейсах. Дополнительная информация о настройке конфигурации DECnet приведена в документе Cisco 1OS Network Protocols Configuration Guide, Part 2
Проблема
Решение
Несоответствие оконечных узлов и номера зоны маршрутизатора
Шаг 1. Проверьте конфигурацию оконечных узлов и маршрутизаторов в сетевом сегменте. Проверьте адрес зоны, указанный в оконечных узлах и маршрутизаторах. Для просмотра информации о конфигурации маршрутизатора примените привилегированную ехес-команду show running-config.
Шаг 2. Если оконечный узел не находится в той же зоне, что и маршрутизатор сегмента, необходимо либо изменить адрес оконечного узла, чтобы он соответствовал маршрутизатору сегмента, либо откорректировать конфигурацию маршрутизатора сегмента, задав такой же номер зоны, как и в оконечном узле
Не происходит обмен hello-пакетам и
Шаг 1. Воспользуйтесь привилегированной exec-командой debug decnet adj, чтобы определить, происходит ли передача и прием hello-пакетов маршрутизатором.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 2. Если обмен hello-пакетами не происходит, определите с помощью команды show interfaces, не являются ли входная и выходная очереди интерфейса заполненными. Заполненная входная очередь характеризуется значением 75/75, а заполненная выходная очередь — значением 40/40.
Шаг 3. Если очереди заполнены и обмен hello-пакетами не происходит, обратитесь к представителю службы технической поддержки.
Шаг 4. Если маршрутизаторы передают hello-пакеты, проверьте оконечные узлы, чтобы определить, почему оконечные узлы отвергают hello-пакеты
Нарушения в работе передающей среды
Дополнительная информация об устранении нарушений в работе последовательных каналов приведена в главе 15. Для получения более подробной информации об устранении нарушений в работе передающей среды локальной сети обратитесь к главе данной книги, в которой рассматриваются вопросы устранения нарушений в работе передающей среды, применяемой в конкретной сети
DECnet: маршрутизатор или оконечный узел обнаруживает неправильно назначенный маршрутизатор
Признак неисправности. Маршрутизаторы и оконечные узлы обнаруживают неправильно настроенный или не предусмотренный конфигурацией назначенный маршрутизатор. Если по условиям функционирования сети требуется, чтобы в качестве на-
значенного маршрутизатора был выбран определенный маршрутизатор, то нельзя позволять, чтобы назначенным маршрутизатором стал другой маршрутизатор, поскольку это может вызвать непредсказуемое поведение сети и исключить возможность установления соединений по запросам, поступающим в зону или из зоны.
В табл. 11.4 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
• Таблица 11.4. DECnet: маршрутизатор или оконечный узел обнаруживает г ■■ / * неправильно назначенный маршрутизатор
Неправильно установлен приоритет предусмотренного конфигурацией назначенного маршрутизатора
Шаг 1. Вызовите на выполнение exec-команду show decnet interface, чтобы определить, какой маршрутизатор является назначенным. Отметьте, какой приоритет имеет маршрутизатор, показанный в выводе команды.
Шаг 2. Если назначенный маршрутизатор, который указан в результатах выполнения команды, определен неправильно, вызовите на выполнение команду show decnet interface в предусмотренном конфигурацией назначенном маршрутизаторе и фактически установленном назначенном маршрутизаторе.
Шаг 3. Сравните приоритет фактически установленного назначенного маршрутизатора и приоритет предусмотренного конфигурацией назначенного маршрутизатора. Маршрутизатор, который действительно должен стать назначенным, обязан иметь наивысший приоритет.
Шаг 4. В случае необходимости воспользуйтесь командой конфигурации интерфейса decnet router-priority для присвоения более высокого приоритета маршрутизатору, чтобы он мог быть выбран в качестве назначенного маршрутизатора.
Синтаксис
Ниже приведена синтаксическая структура команды decnet routerpriority.
decnet router-priority value
Чтобы выбрать назначенный маршрутизатор, в который будут передаваться пакеты, если не задан адрес получателя, примените команду конфигурации интерфейса decnet router-priority.
Описание синтаксиса
• value. Приоритет маршрутизатора. Он может представлять собой число в диапазоне от 0 до 127. Чем больше это число, тем выше приоритет. По умолчанию приоритет устанавливается равным 64
Несколько маршрутизаторов имеют одинаковый приоритет маршрутизатора
Шаг 1. Вызовите на выполнение exec-команду show decnet interface, чтобы определить, какой маршрутизатор является назначенным. Отметьте, какой приоритет имеет маршрутизатор, показанный в выводе команды.
Шаг 2. Вызовите на выполнение команду show decnet interface в предусмотренном конфигурацией назначенном маршрутизаторе и сравните приоритеты фактически установленного назначенного маршрутизатора и предусмотренного конфигурацией назначенного маршрутизатора.
Проблема
Решение
Проблема
Решение
Шаг 3. Если маршрутизаторы имеют одинаковый приоритет, воспользуйтесь командой конфигурации интерфейса decnet router-priority, чтобы задать более высокий приоритет в конфигурации маршрутизатора, который должен быть выбран в качестве назначенного.
Синтаксис
Ниже приведена синтаксическая структура команды decnet routerpriority.
decnet router-priority value
Чтобы выбрать назначенный маршрутизатор, в который будут передаваться пакеты, если не задан адрес получателя, примените команду конфигурации интерфейса decnet router-priority.
Описание синтаксиса
• value. Приоритет маршрутизатора. Он может представлять собой число в диапазоне от 0 до 127. Чем больше это число, тем выше приоритет. По умолчанию приоритет устанавливается равным 64.
Примечание. Если в конфигурациях двух маршрутизаторов задан одинаковый приоритет, то назначенным маршрутизатором становится маршрутизатор с более высоким номером узла
Отношения смежности между узлами не являются двухсторонними
Шаг 1. Вызовите на выполнение exec-команду show decnet route, чтобы определить, характеризуются ли отношения смежности с предусмотренным конфигурацией назначенным маршрутизатором состоянием "down" или "initializing”.
Шаг 2. Воспользуйтесь привилегированной exec-командой debug decnet adj, чтобы определить, происходит ли обмен hello-пакетами.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 3. Если маршрутизатор не передает hello-пакеты, определите с помощью команды show interfaces, не являются ли входная и выходная очереди интерфейса заполненными. Заполненная входная очередь характеризуется значением 75/75, а заполненная выходная очередь — значением 40/40.
Шаг 4. Если очереди заполнены и обмен hello-пакетами не происходит, обратитесь к представителю службы технической поддержки маршрутизатора.
Шаг 5. Если маршрутизаторы передают hello-пакеты, обратитесь к администраторам оконечных узлов, чтобы определить, почему оконечные узлы отбрасывают hello-пакеты
DECnet: маршрутизаторы не устанавливают отношения смежности
Признак неисправности. Маршрутизаторы не устанавливают отношения смежности с другими маршрутизаторами в той же локальной сети.
В табл. 11.5 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 11.5. DECnet: маршрутизаторы не устанавливают отношения . смежности '
Проблема
Решение
В сети установлено больше 32 маршрутизаторовВ сети установлено больше 32 маршрутизаторовВ сети DECnet количество отношений смежности, которые могут быть установлены маршрутизатором, ограничено значением 32.
В сети установлено больше 32 маршрутизаторов
В сети установлено больше 32 маршрутизаторов
Шаг 1. Разрешите применение привилегированной exec-команды debug decnet events, чтобы определить, отклоняются ли запросы на установление отношений смежности. Вводите эту команду в маршрутизаторах последовательно, а не сразу в нескольких.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, используюших ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 2. Если запросы на установление отношений смежности отвергаются, уменьшите число смежных маршрутизаторов или увеличьте приоритет маршрутизатора, который вы хотите сделать смежным, чтобы он имел более высокий приоритет по сравнению с одним из остальных соседних маршрутизаторов. Отношения смежности будут установлены с намеченным вами маршрутизатором, а не с маршрутизатором, которому назначен более низкий приоритет.
Синтаксис
Ниже приведена синтаксическая структура команды, позволяющая откорректировать приоритет маршрутизатора.
decnet router-priority value
Чтобы выбрать назначенный маршрутизатор, в который будут передаваться пакеты, если не задан адрес получателя, примените команду конфигурации интерфейса decnet router-priority.
Описание синтаксиса
value. Приоритет маршрутизатора. Он может представлять собой число в диапазоне от 0 до 127. Чем больше это число, тем выше приоритет. По умолчанию приоритет устанавливается равным 64
Проблема
Решение
Адрес узла выходит за пределы допустимого диапазона
Шаг 1. Воспользуйтесь привилегированной exec-командой show running-config, чтобы ознакомиться с информацией о конфигурации маршрутизатора. Проверьте, выполнена ли настройка в составе конфигурации глобальной команды конфигурации decnet max-address. Эта команда устанавливает наибольший номер узла DECnet, разрешенный в этой зоне.
Примечание. Команда decnet max-address задает наибольший номер узла, который может применяться в некоторой зоне, а не максимальное количество адресов узлов, разрешенных к применению в этой зоне. Например, если в состав конфигурации маршрутизатора введена команда decnet max-address 1000, а в конфигурации одного из умов задан адрес узла 1001, этот адрес выходит за пределы диапазона.
Шаг 2. По умолчанию максимальный адрес равен 1023. Но если в конфигурацию введено другое значение, то адрес узла может превысить значение, заданное в конфигурации. Если дело обстоит таким образом, увеличьте максимальное значение адреса с помощью команды decnet max-address
Номер зоны маршрутизатора превышает значение, введенное в конфигурацию командой decnet max-area
Если номер зоны узла DECnet (такого как маршрутизатор) превышает значение, введенное в конфигурацию с помошью команды decnet max-area, то отношения смежности будут переустановлены.
Шаг 1. Вызовите на выполнение привилегированную exec-команду show running-config для просмотра информации о конфигурации маршрутизатора. Найдите записи глобальной команды конфигурации decnet max-area. Эта команда устанавливает максимальный номер зоны DECnet для маршрутизатора.
Примечание. Команда decnet max-area задает наибольший номер зоны, который может применяться в данной сети, а не максимальное количество номеров зон, которые могут быть введены в конфигурацию. Например, если в состав конфигурации маршрутизатора введена команда decnet max-area 60, а в конфигурации одного из узлов задан номер зоны 61, этот номер выходит за пределы диапазона.
Шаг 2. Вызовите на выполнение привилегированную exec-команду show running-config, чтобы определить номер зоны в конфигурации других маршрутизаторов DECnet. Сравните значение, введенное в конфигурацию командой decnet max-area, с номерами зон других маршрутизаторов.
Шаг 3. Если номер зоны маршрутизатора превышает значение, введенное в конфигурацию глобальной командой конфигурации decnet max-area, откорректируйте команду decnet max-area в составе конфигурации таким образом, чтобы максимальный номер зоны DECnet превышал значения номера зоны во всех маршрутизаторах
Отношения смежности между узлами не являются двухсторонними
Шаг 1. Вызовите на выполнение exec-команду show decnet route, чтобы определить, характеризуются ли отношения смежности с предусмотренным конфигурацией назначенным маршрутизатором состоянием "down" или "initializing".
Проблема
Решение
Шаг 2. Если осуществляется поиск неисправностей в нешироковещательной сети коллективного доступа (такой как Frame Relay или Х.25), убедитесь в том, что операторы шар введены в конфигурацию должным образом.
Чтобы обеспечить трансляцию адресов для выбранных узлов, примените глобальную команду конфигурации decnet map.
Синтаксис
decnet first-network map virtual-address second-network real-address
Описание синтаксиса
first-network. Номер сети DECnet в диапазоне от 0 до 3.
virtual-address. Числовой адрес DECnet (например, 10.5).
second-network. Номер сети DECnet, в которой выполняется преобразование адреса; этот номер должен находиться в диапазоне от 0 до 3.
real-address. Числовой адрес DECnet (например, 10.5).
Шаг 3. Воспользуйтесь привилегированной exec-командой debug decnet adj, чтобы определить, происходит ли обмен hello-пакетами.
Шаг 4. Если маршрутизатор не передает hello-пакеты, определите с помощью команды show interfaces, не являются ли входная и выходная очереди интерфейса заполненными. Заполненная входная очередь характеризуется значением 75/75, а заполненная выходная очередь — значением 40/40.
Шаг 5. Если очереди заполнены и обмен hello-пакетами не происходит, обратитесь к представителю службы технической поддержки маршрутизатора
DECnet: отношения смежности маршрутизирующего узла то устанавливаются, то разрываются
Признак неисправности. Отношения смежности между маршрутизаторами то устанавливаются, то разрываются. На системной консоли DEC периодически появляются примерно такие сообщения:
44444444444 ОРСОМ 30-JUN-1993 1:25:07.45 444444444444
Message from user DECNET on The Bay
DECnet event 4.16, adjacency rejected
From NODE 12.1 (The Bay), 30-JUN-1993 1:25:07.45
Circuit UNA-0, Adjacent node = 1.101 (Vaxl)
44444444444 OPCOM 30-JUN-1993 1:25:07.46 444444444444
Message from user DECNET on The Bay
DECnet event 4.15, adjacency up
From NODE 12.1 (The Bay), 30-JUN-1993 1:25:07.46
Circuit UNA-0, Adjacent node =1.12 (Vax2)
Эти сообщения указывают, что постоянно происходит процесс добавления и удаления маршрутизаторов из таблицы маршрутизации. В этих сообщениях ОРСОМ указаны события DECnet 4.16 (запрос на установление отношений смежности отвергнут) и 4.15 (отношения смежности установлены) для конкретных маршрутизирующих узлов.
В табл. 11.6 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 11.6. DECnet: отношения смежности маршрутизирующего узла то > -устанавливаются, то разрываютсяj
Проблема Решение
Общее количество маршрутизирующих узлов в сетевом сегменте превышает 32Общее количество маршрутизирующих узлов в сетевом сегменте превышает 32В сети DECnet количество отношений смежности, которые могут быть установлены маршрутизатором, ограничено значением 32.
Общее количество маршрутизирующих узлов в сетевом сегменте превышает 32
Общее количество маршрутизирующих узлов в сетевом сегменте превышает 32
Шаг 1. Разрешите применение привилегированной exec-команды debug decnet events, чтобы определить, отклоняются ли запросы на установление отношений смежности. Вводите эту команду в маршрутизаторах последовательно, а не сразу в нескольких.
Шаг 2. Если запросы на установление отношений смежности отвергаются, уменьшите число смежных маршрутизаторов в сегменте
Нарушение в работе аппаратных средствНарушение в работе аппаратных средствПросмотрите выведенные на консоль сообщения об ошибках, чтобы определить маршрутизирующий узел (или узлы), который вызывает периодическое установление и разрыв отношений смежности.
Нарушение в работе аппаратных средств
Нарушение в работе аппаратных средств
Выполните процедуры, описанные в главе 3
DECnet: отсутствие связи между сетевыми устройствами Phase IV по опорной сети Phase V
Признак неисправности. Попытки установления связи между зонами DECnet Phase IV, разделенными опорной сетью ISO CENS (Phase V), оканчиваются неудачей. Узлы Phase IV не могут установить связь с другими узлами Phase IV через открытую сеть Phase V, но могут взаимодействовать друг с другом в пределах одной и той же открытой сети Phase IV.
Примечание
Дополнительная информация об устранении нарушений в работе объединенных сетей DECnet/OSI приведена в главе 12.
В табл. 11.7 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
ГТаблица 11.7. DECnet: отсутствие связи между сетевыми устройствами Phase IV по опорной сети Phase V'
ПроблемаРешение
Неправильно Шаг 1. Вызовите на выполнение команду show interfaces, чтобы проверить, настроенычто в конфигурации маршрутизаторов опорной сети ISO CLNS была
адресавыполнена настройка средств поддержки CLNS и DECnet Phase IV.
Проблема
Решение
Шаг 2. Убедитесь в том, что в состав конфигурации маршрутизаторов опорной сети введена глобальная команда конфигурации decnet conversion, обеспечивающая преобразование адресов DECnet Phase IV и ISO CLNS.
Шаг 3. Вызовите на выполнение привилегированную exec-команду show running-config в маршрутизаторах опорной сети, чтобы проверить соответствие адресов DECnet и CLNS.
При настройке конфигурации можно легко допустить ошибку, задавая значения адресов двух типов: адресов DECnet, которые должны быть заданы в виде десятичных чисел, и адресов CLNS NSAP (Network Service Access Point — точка доступа к сетевой службе), которые должны быть заданы в виде шестнадцатеричных чисел.
Дополнительная информация приведена ниже, в разделе “Адреса DECnet Phase IV и ISO CLNS".
Шаг 4. Если адреса зон не согласованы, проверьте спецификации адресов и откорректируйте значения адресов DECnet и CLNS в конфигурации маршрутизатора.
Дополнительная информация о настройке конфигурации DECnet Phase IV, CLNS и средств преобразования приведена в документе Cisco IOS Network Protocol Configuration Guide, Part 2
Не разрешено применение ISO CLNS или DECnet в соответствующих интерфейсах
Шаг 1. Вызовите на выполнение команды show clns interface и show decnet interface в маршрутизаторах Phase IV, граничащих с опорной сетью, чтобы определить, какое программное обеспечение протоколов эксплуатируется в тех или иных интерфейсах.
Проверьте, разрешено ли применение DECnet и ISO CLNS в тех интерфейсах маршрутизатора опорной сети, где должно выполняться преобразование.
Шаг 2. Если в конфигурации требуемых интерфейсов не разрешена поддержка DECnet, предусмотрите эту поддержку. Обязательно введите команду конфигурации интерфейса decnet cost, чтобы присвоить значение стоимости этому интерфейсу. Если в конфигурации требуемых интерфейсов не предусмотрены средства поддержки маршрутизации ISO CLNS, вызовите на выполнение команду конфигурации интерфейса clns router. Ниже показана полная синтаксическая структура этой команды.
tins routing
Для отмены маршрутизации CLNS применяется команда no tins routing:
по tins routing
Дополнительные рекомендации по настройке конфигурации DECnet Phase IV и ISO CLNS приведены в документе Cisco IOS Network Protocol Configuration Guide, Part 2
Адреса DECnet Phase IV и ISO CLNS
Для преобразования адресов DECnet Phase IV и ISO CLNS (Phase V) требуется, чтобы адреса NSAP были совместимыми с адресами Phase IV. Если адрес может быть преобразован в действительный адрес Phase IV, он считается совместимым со спецификацией Phase IV.
В совместимом адресе номер зоны OSI должен находиться в пределах от 1 до 63 (в десятичном представлении), а идентификатор станции OSI должен иметь формат AA00.0400.xxxx. Кроме того, номер зоны OSI и номер зоны DECnet (вычисленный по идентификатору станции OSI) должны совпадать. Это позволяет правильно извлекать адрес DECnet Phase IV из адреса NSAP.
В табл. 11.8 приведены адреса OSI NSAP и эквивалентные им адреса DECnet Phase IV и указано, какие адреса NSAP являются совместимыми или несовместимыми с адресами Phase IV и почему.
,,.^^,—
Таблица 11.8.Преобразованиеадресов OSI НЗАРи DECnet Phase IV t' -. -1
Адрес OSI NSAP (шестнадцатеричный)
Зона Адрес DECnet Совместимый с адресом Phase IV OSI (десятичный)
49.1111.0012.ААОО.0400.0149.20
49.1111.0009.AA00.0400.ВС04.20
1818.257Да
91.188Нет. Зона OSI не соответствует зоне
DECnet
49.1111.0041.AA00.0400.FFFF.20
49.1111.000Е.AA00.0400.0000.20
6563.1023Нет. Номер зоны OSI превышает 63
140.0Нет. Адрес DECnet в идентифика
торе станции NSAP является недействительным
49.1111.0009.0800.2В05.8297.20
9-Нет. Идентификатор станции NSAP
не представлен в правильном формате (AA00.0400.хххх)
DECnet: низкая производительность
Признак неисправности. Сеть DECnet характеризуется низкой производительностью, или соединения являются ненадежными. Соединения с хостами через один или несколько маршрутизаторов время от времени становятся недоступными или неожиданно разрываются.
В табл. 11.9 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
^Йбдица 11.9.
DECnet: низкая производительность। / ^£Л |
Проблема
Решение
Нарушение трафика DECnet
Шаг 1. Вызовите на выполнение exec-команду show decnet traffic и проверьте в ее результатах значения полей Received и Forwarded. В большинстве случаев эти значения должны совпадать.
Шаг 2. Если указанные значения не совпадают, проверьте содержимое полей Returned, Converted, Access Control Failed, No Route и Encapsulation Failed, чтобы определить, чем вызвано снижение прои зводительности.
Проблема
Решение
Шаг 1. Если не удается выявить причины или устранить рассматриваемую проблему, обратитесь за помощью к представителю службы технической поддержки
Несоответствие установок таймера
Шаг 1. Вызовите в сети на выполнение exec-команду show decnet interface во всех маршрутизаторах. Проверьте, применяются ли в сети во всех маршрутизаторах одинаковые установки таймеров hello-пакетов и таймеров обновлений маршрутизации.
Ниже показан пример вывода команды show decnet interface.
C4500# show decnet interface
I-..]
EthernetO is up, line protocol is up, encapsulation is ARPA Interface cost is 50, priority is 64, DECnet network: 0 We are the designated router
Sending HELLOs every 15 seconds, routing updates 40 seconds
[...]
Шаг 2. Если установки таймеров не являются одинаковыми во всех маршрутизаторах, приведите конфигурации маршрутизаторов к единообразному виду с помощью команд конфигурации интерфейса decnet hello-timer и decnet routing-timer. Для восстановления применяемой по умолчанию установки hello-таймера, равной 15 с, используется форма соответствующей команды с префиксом по
Нарушение в работе передающей среды
Шаг 1. Вызовите на выполнение exec-команду show interfaces и найдите в ее выводе информацию об ошибках CRC (Cyclic Redundancy Check — циклический избыточный код).
Шаг 2. Если в выводе этой команды имеется информация об ошибках CRC, то проблема может быть связана с нарушениями в работе передающей среды. Для получения информации об устранении нарушений в работе передающей среды конкретной сети обратитесь к главе, в которой рассматривается соответствующий тип передающей среды
Уничтожение пакетов во входной и в выходной очередях
Шаг 1. Вызовите на выполнение exec-команду show interfaces, чтобы ознакомиться с информацией о входной и выходной очередях. Найдите данные об уничтоженных пакетах. Здесь за каждым числом следует косая черта, максимальный размер очереди и данные о количестве пакетов, уничтоженных из-за того, что очередь заполнена.
Шаг 2. Если происходит уничтожение пакетов, обратитесь за помощью к представителю службы технической поддержки
Глава
12
Устранение нарушений в работе сети ISO CLNS
В настоящей главе представлена информация по устранению нарушений в работе сети, функционирующей под управлением протокола ISO CLNS, которые характеризуются на- ^рушением связи и снижением производительности. Протокол ISO CLNS представляет со* бой стандартный протокол сетевого уровня, составляющий часть набора протоколов OSI. к Программ1106 Обеспечение Cisco IOS обеспечивает перенаправление пакетов и ■ маршрутизацию для ISO CLNS в сетях, в которых применяются самые разные протоШколы канального уровня, в том числе Ethernet, Token Ring и FDDI, а также последо- щател^юш каналы. Маршрутизация CLNS может применяться в последовательных ин- ^^с^йсах с инкапсуляцией HDLC, PPP, LAPB, Х.25, SMDS или Frame Relay. Для ^^Вюльзования инкапсуляции HDLC необходимо установить маршрутизатор на обоих крицах канала. Если применяется инкапсуляция Х.25, необходимо вручную ввести данные для преобразования адресов NSAP в адреса Х.121. Средства поддержки инкап- су^ции LAPB,<X25, Frame Relay и SMDS обеспечивают функциональную совместимо^ оборудования Cisco с оборудованием других поставщиков.
Реализация протокола CLNS корпорации Cisco совместима также с протоколом GOSIR (Government Opeti Systems Interconnection Profile — поддерживаемые государ- г-«<жвом спецификации'ДЛЯ' протоколов OSI) версии 2. Средства поддержки протокола ^^LNS маршрутизаторов Cisco обеспечивают также полную поддержку следующих стандартов ISO и. ANSI (American National Standards Institute — Национальный институт стандартизации. С ША).
’ ISO:9542. Определяет протокол обмена маршрутной информацией ES-IS (End §, System-to-Intermediate System — протокол передачи маршрутной информации чт оконечной системы к промежуточной системе).
ISO 5475..О(феделяет протокол ISO CLNP.
^ ISO 8348/Ad2. Определяет адреса NSAP.
|<» ISO 10589. Определяет протокол обмена маршрутной информацией между до- & ^MbfiaMH^IS-IS (Intermediate System-to-Intermediate System — протокол обмена /' маршрутной информацией между промежуточными системами).
В составе средств динамической маршрутизации ISO CLNS обеспечивается также Жподдерзкка протокола маршрутизации IS-IS, разработанного организацией ISO, и про-
токола ISO IGRP (Interior Gateway Routing Protocol — протокол маршрутизации внутреннего шлюза) корпорации Cisco. Кроме того, поддерживается статическая маршрутизация для ISO CLNS.
Основы технологии ISO CLNS
В области организации сетей на основе модели OSI применяется уникальная терминология.
Оконечной системой (ES — End System) именуется любое немаршрутизирующее сетевое устройство.
Маршрутизатор рассматривается как промежуточная система (IS — Intermediate System).
Зоной называется группа непосредственно связанных сетей и подключенных к ним хостов, которые определены сетевым администратором как принадлежащие к одной зоне.
Домен определяется как совокупность связанных зон. Маршрутизирующие домены обеспечивают неограниченную возможность установления соединений друг с другом для всех принадлежащих к ним оконечных систем.
Адресация в сети ISO CLNS
Адреса в сетевой архитектуре ISO присваиваются точкам доступа NSAP и заголовкам NET (Network Entity Title — заголовок сетевого объекта). Каждый узел в сети OSI может иметь один или несколько адресов NET. Кроме того, каждый узел может иметь несколько адресов NSAP. Все адреса NSAP и NET в каждом конкретном узле соответствуют друг другу и отличаются только содержимым последнего байта (рис. 12.1). Этот байт называется n-селектором. По своему назначению он аналогичен номеру порта в других наборах протоколов.
В реализации Cisco поддерживаются все форматы адресов NSAP, которые определены стандартом ISO 8348/Ad2, но маршрутизаторы Cisco обеспечивают динамическую маршрутизацию (маршрутизацию ISO IGRP или IS-IS) только для адресов NSAP, которые соответствуют ограничениям адреса, определенным в стандарте ISO для протокола IS-IS (ISO 10589).
Адрес NSAP состоит из двух основных полей.
Поле IDP (Initial Domain Part — начальная часть идентификатора домена) состоит из однобайтового идентификатора AFI (Authority and Format Identifier — идентификатор полномочий и формата) и начального идентификатора домена (IDI — Initial Domain Identifier) переменной длины. Длина поля IDI и формат кодирования поля DSP (Domain-Specific Part — уточняющая часть идентификатора домена) зависят от значения идентификатора AFI.
Поле DSP состоит из старшей части идентификатора домена, идентификатора зоны, идентификатора системы и однобайтового п-селектора.
Основное различие между схемами адресации NSAP по спецификации ISO IGRP и стандарту IS-IS состоит в том, как определен адрес зоны. В обеих схемах для маршрутизации уровня 1 используется идентификатор системы, но в них применяются разные способы указания адресов для маршрутизации в зоне. Адрес ISO IGRP NSAP включает три поля (т.е. предусматривает три отдельных уровня, на которых может осуществляться маршрутизация): идентификатор домена, зоны и системы. Адрес IS-IS NSAP включает два поля: отдельное непрерывное поле идентификатора зоны, охватывающее поля идентификаторов домена и зоны, которые определены в спецификации ISO IGRP, и поле идентификатора системы.
Структура адресации ISO IGRP NSAP показана на рис. 12.1.
|IDP|DSP|
| AFI |IDI;| Зона | Идентификатор системы | s|
| 1 |Переменная|2 |6| 11
Адрес доменаАдресАдрес
ISO-IGRPзонысистемы
Рис. 12.1. Структура адресации ISO IGRP NSAP
Адрес ISO IGRP NSAP состоит из трех компонентов: часть идентификатора домена, адрес зоны и идентификатор системы. Маршрутизация в домене осуществляется с использованием компонента адреса, соответствующего части идентификатора домена. Маршрутизация в зоне, относящейся к данному домену, основана на использовании адреса зоны. В процессе маршрутизации с учетом идентификатора системы в данной зоне используется компонент адреса с обозначением идентификатора системы. Адрес NSAP имеет следующую структуру.
Компонент с обозначением домена имеет переменную длину и располагается перед адресом зоны.
Адрес зоны имеет длину 2 байта и находится перед идентификатором системы.
Идентификатор системы состоит из 6 байтов и размещается перед п-селектором.
n-селектор (S) находится в последнем байте адреса NSAP.
В реализации средств маршрутизации по спецификации ISO IGRP все байты адреса, начиная от поля AFI и заканчивая полем зоны в DSP (но не включая эти поля), рассматриваются как идентификатор домена. Поле зоны обозначает зону, а идентификатор системы обозначает систему.
Структура адресации IS-IS NSAP показана на рис. 12.2.
Адрес IS-IS NSAP состоит из двух частей: адрес зоны (АА — Area Address) и идентификатор системы. В маршрутизации уровня 2 используется поле АА. В маршрутизации уровня 1 используется поле идентификатора системы. Адрес NSAP имеет следующую структуру.
n-селектор (S) является последним байтом адреса NSAP.
Идентификатор системы находится между адресом зоны и байтом п-селектора.
Адрес зоны представляет собой адрес NSAP, из которого исключены идентификатор системы и п-селектор.
1
)Р
|DSP|
1 AFI |
IDI
; НО-DSP | Идентификатор системы | S ]
1 1 1
Переменная
1
6| 1|
Адрес зоны IS-ISАдрес системы
Рис. 12.2. Структура адресации IS-IS NSAP
В маршрутизирующем протоколе IS-IS все байты поля DSP, начиная от поля AFI и заканчивая полем идентификатора системы (но не включая эти поля), рассматриваются как идентификатор зоны. Идентификатор системы обозначает систему.
Правила адресации
Все адреса NSAP должны соответствовать следующим ограничениям.
Никакие два узла не могут иметь адреса с одинаковым адресом NET; это означает, ■ что адреса должны различаться хотя бы по значению поля n-селектора (S) в DSP.
Адрес ISO IGRP должен иметь длину не меньше 10 байтов: 1 байт предназначен для идентификатора домена, 2 — для зоны, 6 — для системы и 1 — для п-селектора.
Для реализации стандарта IS-IS корпорации Cisco требуется не меньше 8 байтов: 1 байт предназначен для идентификатора зоны, 6 — для системы и 1 — для п-селектора.
Никакие два узла, находящиеся в пределах одной и той же зоны, не могут иметь адреса, в которых совпадают поля идентификатора системы.
Ниже приведены примеры адресов сети OSI и GOSIP NSAP, в которых используется реализация ISO IGRP.
Формат адреса NSAP в сети OSI:
47.0004.004D.0003.0000.0С00.62Е6.00
|Домен|Зона| Идентификатор! S|
||| станции] S|
Формат адреса NSAP в сети GOSIP:
47.0005.80.FFFF.0000.00.FFFF.0004.0000.0C00.62E6.00
|3она| Идентификатор] S|
|| станции] S|
Ввод информации о маршрутах
Ввод информации о маршрутах осуществляется путем задания пар, состоящих из префикса NSAP и адреса NET следующего участка маршрута. Адреса NET по своему назначению аналогичны адресам NSAP. По таблице маршрутизации выполняется по-
иск наиболее подходящей записи. Таковой считается запись с префиксом NSAP наибольшей длины, который сопоставляется с началом заданного адреса назначения NSAP. В табл. 12.1 приведен пример статической таблицы маршрутизации. Здесь показаны все адреса NET следующих участков маршрута, что позволяет получить полное представление о структуре таблицы маршрутизации, но они не требуются для понимания данного алгоритма маршрутизации. В табл. 12.2 приведен пример того, как сопоставляются адреса назначения с записями таблицы маршрутизации, приведенной в табл. 12.1, с использованием наиболее длинного сопоставляемого префикса NSAP.
^Таблица 12.1. Примеры записей таблицы маршрутизации
Запись
Префикс адреса NSAP
Адрес NET следующего участка маршрута
1
47.0005.000с.0001
47.0005.000с.0001.0000.1234.00
2
47.0004
47.0005.000с.0002.0000.0231.00
3
47.0005.0003
47.0005.000с. 0001.0000.1234.00
4
47.0005.000с
47.0005.000с. 0004.0000. ООН. 00
5
47.0005
47.0005.000с.0002.0000.0231.00
Йаблица 12.2. При wrzr^A^ "SX-.v^S^ ' XV.«.Г.™
меры адресов вде|
>архич
еской системе i
маршрутизации
Адреса назначения NSAP дейтаграмм
Номер используемой записи таблицы
47.0005.000с.0001.0000.3456.01
1
47.0005.000с.0001.6789.2345.01
1
47.0004.1234.1234.1234.1234.01
2
47.0005.0003.4321.4321.4321.01
3
47.0005.000с.0004.5678.5678.01
4
47.0005.0001.0005.3456.3456.01
5
Поля адресов NSAP и NET должны занимать целое число октетов.
Устранение нарушений в работе сети ISO CLNS
В настоящем разделе представлены сведения, позволяющие устранять нарушения в работе, характеризующиеся отсутствием связи или снижением производительности сети ISO CLNS, которые зависят от правильного функционирования программного обеспечения протокола. Здесь описаны конкретные признаки неисправности в сети ISO CLNS, перечислены проблемы, которые могут вызвать появление каждого признака неисправности, и приведены решения этих проблем.
Примечание
Приведенные в настоящей главе рекомендации по устранению нарушений в работе, предусматривающие внесение изменений в конфигурацию хоста, относятся к хостам с операционной системой UNIX. Аналогичные рекомендации могут также относиться к хостам с операционными системами, отличными от UNIX, но здесь нарушения в работе оконечных станций с такими операционными системами отдельно не рассматриваются.
В перечисленных ниже разделах рассматриваются наиболее распространенные нарушения в работе сети ISO CLNS.
ISO CLNS: хост не может получить доступ к хостам в локальной или удаленной сети.
ISO CLNS: хост не может получить доступ к хостам в той же зоне.
ISO CLNS: хост не может получить доступ к хостам в другой зоне.
ISO CLNS: попытки установления соединения с использованием некоторых протоколов завершаются неудачей.
ISO CLNS: пользователи не могут устанавливать соединения по параллельному пути.
ISO CLNS: перераспределение маршрутов приводит к появлению проблем маршрутизации.
ISO CLNS: низкая производительность.
ISO CLNS: хост не может получить доступ к хостам в локальной или удаленной сети
Признак неисправности. Хосты, находяшиеся в локальной или удаленной сети, не могут вступать во взаимодействие с другими хостами. Соединения с некоторыми хостами в сети могут устанавливаться успешно, тогда как попытки связаться с другими хостами в той же сети завершаются неудачей.
В табл. 12.3 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 12.3. ISO CLNS: хост не может получить доступ к хостам в л окал ьной ил и удал енной сети, ..
Проблема
Решение
В конфигурации отсутствует или неправильно задана спецификация шлюза, применяемого по умолчанию
Шаг 1. Определите, указан ли применяемый по умолчанию шлюз в таблице маршрутизации хоста, пытающегося установить соединение. Вызовите на выполнение следующую команду UNIX: hosts netstat -rn
Проверьте в выводе этой команды наличие спецификации шлюза, применяемого по умолчанию.
Описание синтаксиса
netstat. Отображает статистические данные о работе протокола и текущие сетевые соединения TCP/IP.
г. Отображает содержимое таблицы маршрутизации.
п. Представляет адреса и номера портов в числовой форме.
Шаг 2. Если спецификация шлюза, применяемого по умолчанию, является неправильной или вообще отсутствует, откорректируйте или введите в конфигурацию локального хоста спецификацию шлюза, применяемого по умолчанию, с помошью следующей команды UNIX: hosts route add default address 1
Проблема
Решение
Здесь address — IP-адрес шлюза, применяемого по умолчанию (маршрутизатора, находящегося в той же локальной сети, что и хост). Значение 1 указывает, что заданный шлюз находится на расстоянии одного транзитного перехода.
Шаг 3. Рекомендуется задавать шлюз, применяемый по умолчанию, в процессе начальной загрузки. Задайте адрес ISO CLNS шлюза в указанном ниже файле хоста UNIX.
/etc/defaultrouter
Имя этого файла зависит от версии операционной системы UNIX
Оконечная система не имеет доступа к маршрутизатору уровня 1
Шаг 1. Вызовите на выполнение привилегированную exec-команду show tins neighbors detail, чтобы просмотреть все оконечные системы (ES — End System) и промежуточные системы (IS — Intermediate System), с которыми непосредственно связан рассматриваемый маршрутизатор.
Шаг 2. Убедитесь в том, что в той же сети, где находится оконечная система, имеется, по меньшей мере, один маршрутизатор уровня 1
Маршрутизатор уровня 1 или оконечная система имеет неправильный адрес
Шаг 1. Убедитесь в том, что маршрутизатор уровня 1 имеет тот же адрес NSAP, что и оконечная система.
Шаг 2. Проверьте, чтобы все байты в адресе NSAP вплоть до идентификатора системы, но не включая его, были одинаковыми и в маршрутизаторе, и в оконечной системе. Адреса домена и зоны должны совпадать, а идентификаторы станций должны быть уникальными. (В данном случае значение байта n-селектора не играет никакой роли.)
В хосте ES не функционирует программное обеспечение протокола ES-IS
Шаг 1. Вызовите на выполнение соответствующие команды хоста, чтобы проверить, функционирует ли процесс ES-IS. В случае необходимости инициализируйте процесс ES-IS на хосте.
Шаг 2. Проверьте базу данных смежности на хосте и убедитесь в том, что в ней есть запись для маршрутизатора, непосредственно связанного с хостом.
Шаг 3. Вызовите на выполнение привилегированную exec-команду debug tins packet в маршрутизаторе уровня 1, чтобы убедиться в том, что маршрутизатор обнаруживает и перенаправляет пакеты, поступающие от оконечной системы.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Проблема
Решение
Шаг 4. В случае необходимости внесите изменения в статическую конфигурацию маршрутизатора, позволяющие распознавать оконечную систему, с помощью команды конфигурации интерфейса tins es-neighbor. Синтаксическая структура команды tins es- neighbor показана ниже.
tins es-neighbor nsap snpa
Описание синтаксиса
nsap. Конкретный адрес NSAP, который должен быть преобразован в конкретный МАС-адрес.
snpa. Адрес (МАС-адрес) канала связи.
Пример
В следующем примере определено смежное устройство ES в интерфейсе Ethernet 0: interface ethernet 0
tins es-neighbor 47.0004.004D.0055.0000.0C00.A45B.00 0000.0C00.A45B
В данном случае в конфигурацию вводятся оконечные системы со следующим адресом NSAP (или адресом NET), соответствующим МАС-адресу Ethernet 0000.0С00.А45В:
47.0004.004D.0055.0000.0С00.А45В.00
Остановлен маршрутизатор, находящийся между хостами
Шаг 1. Вызовите на выполнение exec-команду trace, чтобы проверить наличие связи между маршрутизаторами и оконечной системой- отправителем.
Шаг 2. Если выполнение команды trace в маршрутизаторе оканчивается неудачей, воспользуйтесь exec-командой show tins neighbors, чтобы проверить, какие соседние маршрутизаторы и оконечные системы были обнаружены.
Пример аывода
Ниже приведен пример вывода команды show tins neighbors. Полученные результаты состоят из вывода команд show tins es- neighbor и show tins is-neighbor:
router# show tins neighbors
System IdSNPAInterface state Holdtime Type
Protocol
0000.0000.0007 aaOO.0400.6408 EthernetO Init 277IS
ES-IS
0000.0C00.0C35 0000.0c00.0c36 Ethernetl Up 91LI
IS-IS
0800.2B16.24EA aa00.0400.2d05 EthernetO Up29L1L2
IS-IS
0800.2B14.060E aaOO.0400.9205 EthernetO Up1698ES
ES-IS
Проблема
Решение
0000.0С00.3Е51 *HDLC*Seriall Up 28L2
IS-IS
0000.0C00.62E6 0000.0c00.62e7 Ethernetl Up 22LI
IS-IS
0A00.0400.2D05 aa00.0400.2d05 EthernetO Init 24IS
ES-IS
Шаг 3. Если соседние маршрутизаторы и оконечные системы находятся в рабочем состоянии, выполните одну из следующих процедур.
• В сети ISO IGRP проверьте таблицу маршрутизации и определите, введена ли в нее полученная информация о маршрутах. Для просмотра таблиц маршрутизации воспользуйтесь ехес- командой show tins route.
Шаг 4. В сети IS-IS проверьте базу данных LSP (Link State Packet — пакет с информацией о состоянии канала) и определите, имеется ли информация о каналах в извещениях о состоянии канала. Проверьте таблицу маршрутизации IS-IS, чтобы определить, введены ли маршруты в таблицу маршрутизации. Для просмотра таблиц маршрутизации воспользуйтесь exec-командой show isis database detail
Нарушения в процессе перераспределения маршрутов
Отсутствие связи может быть вызвано неправильной настройкой средств перераспределения маршрутов. Дополнительные рекомендации по устранению этого нарушения в работе приведены ниже, в разделе “ISO CLNS: перераспределение маршрутов приводит к появлению проблем маршрутизации”
ISO CLNS: хост не может получить доступ к хостам в той же зоне
Признак неисправности. Хосты не могут получить доступ к другим хостам в той же зоне. Хосты могут находиться в той же сети или в сети той же зоны.
В табл. 12.4 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
ЯЪблица 12.4. ISO CLNS: хост не может получить доступ к хостай^^1^/1X , в той же зоне/\ \
Проблема
Решение
В конфигурации хоста неправильно задан адрес зоны
Шаг 1. Проверьте все таблицы маршрутизации уровня 1 и базы данных о состоянии каналов.
Шаг 2. Убедитесь в том, что все хосты находятся в одной и той же зоне.
Шаг 3. Проверьте, что адреса NSAP в хостах введены правильно
Проблема
Решение
Различные адреса зон сливаются в одну зону, но конфигурация маршрутизатора задана неправильно
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Проверьте, не входит ли в конфигурацию несколько адресов зон.
Шаг 2. Если в конфигурацию входит несколько адресов зон, проверьте, выполнена ли настройка конфигурации маршрутизатора на поддержку многоадресной зоны (т.е. одной зоны, которая имеет несколько адресов зоны (рис. 12.3)).
Шаг 3. Взаимодействующие маршрутизаторы должны установить отношения смежности уровня 1. Поэтому адреса зон в многоадресной зоне во всех маршрутизаторах должны перекрываться.
Например, в многоадресной зоне, показанной на рис. 12.3, при подготовке зоны 1 и зоны 2 для использования в качестве многоадресной зоны необходимо настроить конфигурацию маршрутизаторов А и В, чтобы они находились в обеих зонах. Средства маршрутизации 1S-IS обеспечивают возможность назначения нескольких адресов зон одному и тому же маршрутизатору. Такой принцип носит название множественной адресации. Множественная адресация предоставляет механизм плавной перенастройки сетевых адресов с помощью следующих операций.
Разбиение зоны. В некоторой зоне может происходить накопление узлов до тех пор, пока ими не становится сложно управлять, возникает чрезмерно интенсивный трафик или появляется вероятность превышения допустимых пределов адресного пространства зоны. Узлам может быть назначено несколько адресов зон, что позволяет постепенно разделить сеть на отдельные зоны, не прерывая обслуживание пользователей.
Слияние зон. Для объединения в одну зону не меньше трех отдельных зон, имеющих общий адрес зоны, можно ввести временные адреса зон.
Переход на другой адрес. Для конкретной группы узлов может потребоваться изменить адрес зоны. Для обеспечения бесперебойного перенаправления входящего трафика, направленного по старому адресу зоны, к соответствующим узлам можно задать несколько адресов зон.
Для назначения маршрутизатору нескольких адресов зон необходимо внести изменения в его статическую конфигурацию. В настоящее время корпорация Cisco предоставляет возможность назначить маршрутизатору до трех адресов зон. Количество зон, которые могут быть определены в домене, не ограничено.
Все эти адреса должны иметь один и тот же идентификатор системы. Например, маршрутизатору можно назначить один адрес (зона 1 плюс идентификатор системы) и два дополнительных адреса в других зонах (зона 2 плюс идентификатор системы и зона 3 плюс идентификатор системы), где идентификатор системы является одинаковым.
Проблема
Решение
Шаг 4. Еше один вариант состоит в том, что конфигурация одного маршрутизатора может быть настроена на использование в обеих зонах, тогда как другой маршрутизатор останется подготовленным для работы в одной зоне. При условии, что номера зон в маршрутизаторах перекрываются, эти маршрутизаторы установят между собой отношения смежности уровня 1, что позволит им взаимодействовать
В хосте ES не функционирует программное обеспечение протокола ES-IS
Шаг 1. Вызовите на выполнение соответствующие команды хоста, чтобы проверить, функционирует ли процесс ES-IS. В случае необходимости инициализируйте процесс ES-IS на хосте.
Шаг 2. Проверьте базу данных смежности на хосте и убедитесь в том, что в ней есть запись для маршрутизатора, непосредственно связанного с хостом.
Шаг 3. Вызовите на выполнение привилегированную exec-команду debug clns packet в маршрутизаторе уровня 1, чтобы убедиться в том, что маршрутизатор обнаруживает и перенаправляет пакеты, поступающие от оконечной системы.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 4. В случае необходимости внесите изменения в статическую конфигурацию маршрутизатора, позволяющие распознавать оконечную систему, с помощью команды конфигурации интерфейса clns es-neighbor. Синтаксическая структура команды clns es- neighbor показана ниже.
clns es-neighbor nsap snpa
Описание синтаксиса
nsap. Конкретный адрес NSAP, который должен быть преобразован в конкретный МАС-адрес.
snpa. Адрес (МАС-адрес) канала связи.
Пример
В следующем примере определено смежное устройство ES в интерфейсе Ethernet 0: interface ethernet 0
clns es-neighbor 47.0004.004D.0055.0000.0C00.A45B.00
0000.0C00.A45B
ПроблемаПроблемаРешениеРешениеНарушения в процессе перераспределения маршрутовНарушения в процессе перераспределения маршрутовОтсутствие связи может быть вызвано неправильной настройкой средств перераспределения маршрутов. Дополнительные рекомендации по устранению этого нарушения в работе приведены ниже, в разделе “ISO CLNS: перераспределение маршрутов приводит к появлению проблем маршрутизации”Отсутствие связи может быть вызвано неправильной настройкой средств перераспределения маршрутов. Дополнительные рекомендации по устранению этого нарушения в работе приведены ниже, в разделе “ISO CLNS: перераспределение маршрутов приводит к появлению проблем маршрутизации”Зона 1Зона 1Зона 2Зона 2
Проблема
Проблема
Решение
Решение
Нарушения в процессе перераспределения маршрутов
Нарушения в процессе перераспределения маршрутов
Отсутствие связи может быть вызвано неправильной настройкой средств перераспределения маршрутов. Дополнительные рекомендации по устранению этого нарушения в работе приведены ниже, в разделе “ISO CLNS: перераспределение маршрутов приводит к появлению проблем маршрутизации”
Отсутствие связи может быть вызвано неправильной настройкой средств перераспределения маршрутов. Дополнительные рекомендации по устранению этого нарушения в работе приведены ниже, в разделе “ISO CLNS: перераспределение маршрутов приводит к появлению проблем маршрутизации”
Зона 1
Зона 1
Зона 2
Зона 2
Отдельная зона с двумя адресами зоны
Рис. 12.3. Пример сети с многоадресной зоной
ISO CLNS: хост не может получить доступ к хостам в другой зоне
Признак неисправности. Хост не может получить доступ к хостам в другой зоне. Хосты в той же зоне доступны.
В табл. 12.5 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 12.5. ISO CLNS: хост не может получить доступ к хостам
. ВДРУГОЙ.ЗОНе.:?Ьх<-
Проблема
Решение
Маршрутизаторы уровня 2 не перенаправляют пакеты в нужную зону
Шаг 1. Вызовите на выполнение команду trace, чтобы убедиться в том, что маршрутизаторы уровня 1 перенаправляют пакеты ближайшему маршрутизатору уровня 2.
Пример вывода
Ниже приведен пример вывода команды trace в сети ISO CLNS.
router# trace
Protocol [ip]: tins
Target CLNS address: thoth
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [ 30 ]:
Type escape sequence to abort.
Tracing the route to THOTH
(55.0006.0100.0000.0000.0001.8888.1112.1314.1516)
HORUS(55.0006.0100.0000.0000.0001.6666.3132.3334.3536)
ПроблемаПроблемаРешениеРешение
Проблема
Проблема
Решение
Решение
32 msec I 28 msec
28 msec I
2 1818(55.0006.0100.0000.0000.0001.7777.2122.2324.2526) 56 msec I 80 msec 56 msec I
3
THOTH(55.0006.0100.0000.0000.0001.8888.1112.1314.1516) 80 msec I 80 msec ! 8
Шаг 2. Вызовите на выполнение exec-команду trace, чтобы убедиться в том, что маршрутизаторы уровня 2 перенаправляют пакеты в нужную зону назначения.
Шаг 3. Если пакеты не перенаправляются в нужную зону, проверьте таблицы маршрутизации уровня 2 (ISO IGRP) или базы данных состояния каналов уровня 2 (IS-IS), чтобы определить, не происходит ли перенаправление пакетов в другую зону.
В хосте ES не функционирует программное обеспечение протокола ES-ISВ хосте ES не функционирует программное обеспечение протокола ES-ISШаг 4. В случае необходимости откорректируйте конфигурацию маршрутизаторов, вводя правильные адреса зон и задавая информацию о маршрутизации уровня 2 (IS-IS)
В хосте ES не функционирует программное обеспечение протокола ES-IS
В хосте ES не функционирует программное обеспечение протокола ES-IS
Шаг 1. Вызовите на выполнение соответствующие команды хоста, чтобы проверить, функционирует ли процесс ES-IS. В случае необходимости инициализируйте процесс ES-IS на хосте.
Шаг 2. Проверьте базу данных смежности на хосте и убедитесь в том, что в ней есть запись для маршрутизатора, непосредственно связанного с хостом.
Шаг 3. Вызовите на выполнение привилегированную exec-команду debug clns packet в маршрутизаторе уровня 1, чтобы убедиться в том, что маршрутизатор обнаруживает и перенаправляет пакеты, поступающие от оконечной системы.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 4. В случае необходимости внесите изменения в статическую конфигурацию маршрутизатора, позволяющие распознавать оконечную систему, с помощью команды конфигурации интерфейса clns es-neighbor
Проблема
Решение
Нарушения в процессе перераспределения маршрутов
Отсутствие связи может быть вызвано неправильной настройкой средств перераспределения маршрутов. Дополнительные рекомендации по устранению этого нарушения в работе приведены ниже, в разделе “ISO CLNS: перераспределение маршрутов приводит к появлению проблем маршрутизации”
Остановлен маршрутизатор, находящийся между хостами
Шаг 1. Вызовите на выполнение exec-команду trace, чтобы проверить наличие связи между маршрутизаторами и оконечной системой- отправителем.
Пример вывода
Ниже приведен пример вывода команды trace в сети ISO CLNS.
router# trace
Protocol [ip]: tins
Target CLNS address: thoth
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Type escape sequence to abort.
Tracing the route to THOTH
(55.0006.0100.0000.0000.0001.8888.1112.1314.1516)
HORUS(55.0006.0100.0000.0000.0001.6666.3132.3334.3536)
32 msec 1 28 msec
28 msec 1
2 ISIS(55.0006.0100.0000.0000.0001.7777.2122.2324.2526)
56 msec 1 80 msec
56 msec !
3
THOTH(55.0006.0100.0000.0000.0001.8888.1112.1314.1516) 80 msec ! 80 msec ! 8
Шаг 2. Если выполнение команды trace в маршрутизаторе оканчивается неудачей, воспользуйтесь exec-командой show tins neighbors, чтобы проверить, какие соседние маршрутизаторы и оконечные системы были обнаружены.
Шаг 3. Если соседние маршрутизаторы и оконечные системы находятся в рабочем состоянии, выполните одну из следующих процедур.
В сети ISO IGRP проверьте таблицу маршрутизации и определите, введена ли в нее полученная информация о маршрутах. Для просмотра таблиц маршрутизации воспользуйтесь ехес- командой show tins route.
В сети IS-IS проверьте базу данных LSP и определите, имеется ли информация о каналах в извещениях о состоянии канала. Проверьте таблицу маршрутизации IS-IS, чтобы определить, введены ли маршруты в таблицу маршрутизации. Для просмотра таблиц маршрутизации воспользуйтесь exec-командой show isis database detail
ISO CLNS: попытки установления соединения с использованием некоторых протоколов завершаются неудачей
Признак неисправности. Попытки установления соединения между хостами с использованием некоторых протоколов завершаются неудачей.
В табл. 12.6 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
j Таблица 12.6. ISO CLNS: попытки установления соединенияj
с использованием некоторых протоколов!
.завершаются неудачей .i
Проблема
Решение
Конфигурация хоста не настроена на поддержку данной службы
Убедитесь в том, что в системе хоста правильно установлено программное обеспечение всех необходимых протоколов и настроена его конфигурация. Для получения дополнительной информации о настройке конфигурации хостов обратитесь к документации поставщика
Неправильно Шаг 1. Воспользуйтесь exec-командой trace, чтобы определить маршрут, настроен списоквыбранный для перенаправления пакетов к удаленным хостам.
доступа
Шаг 2. Если при прохождении по этому маршруту будет обнаружен маршрутизатор, который блокирует трафик, вызовите на выполнение привилегированную exec-команду show access-lists, чтобы определить, введены ли в состав конфигурации этого маршрутизатора какие-либо списки доступа.
Шаг 3. Отмените применение всех списков доступа в маршрутизаторе, вызвав на выполнение команды конфигурации интерфейса по access-group во всех соответствующих интерфейсах.
Шаг 4. Определите, может ли теперь рассматриваемый протокол использоваться в хостах. Если маршрутизатор больше не препятствует прохождению трафика, то, вероятно, трафик протоката был заблокирован одним из списков доступа.
Шаг 5. Убедитесь в том, что данный список доступа не отфильтровывает трафик, поступающий из портов, используемых программным обеспечением рассматриваемого протокола. Введите в конфигурацию явно заданные операторы permit для трафика, который должен перенаправляться маршрутизатором обычным образом.
Шаг 6. Снова разрешите применение данного списка доступа и проверьте, продолжает ли программное обеспечение протокола функционировать правильно. Если нарушение в работе не устранено, продолжайте отыскивать, анализировать и исправлять неправильные списки доступа во всех маршрутизаторах на пути от отправителя к получателю
ISO CLNS: пользователи не могут устанавливать соединения по параллельному пути
Признак неисправности. В сетевой среде с несколькими путями от одной сети к другой отсутствует возможность установления соединений по параллельному каналу после перехода основного канала в нерабочее состояние.
Примечание '
В стандарте IS-IS предусмотрено уравновешивание нагрузки по равной стоимости для маршрутов уровней 1 и 2. Если в сети IS-IS имеются параллельные пути, то при отказе одного из них другой должен служить в качестве резервного и должен быть немедленно готов к использованию.
В табл. 12.7 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 12.7. ISO CLNS: пользователи не могут устанавливать и , . соединения по параллельному пути
Проблема
Решение
Не завершился процесс динамического накопления маршрутной информации
Шаг 1. Воспользуйтесь привилегированной exec-командой show clns route для просмотра таблицы маршрутизации CLNS. Проверьте, есть ли в этой таблице маршруты, отмеченные как "possibly down". Наличие таких маршрутов означает, что работа программного обеспечения протокола маршрутизации по динамическому накоплению маршрутной информации еще не завершена.
Шаг 2. Дождитесь завершения работы программного обеспечения протокола маршрутизации. Снова вызовите на выполнение команду show clns route, чтобы определить, готовы ли теперь маршруты к использованию.
Примечание. В спецификации ISO IGRP предусмотрено уравновешивание нагрузки исключительно для маршрутов с префиксом домена. Если же в сети ISO IGRP применяется маршрутизация уровней 1 или 2, устанавливается только один путь. А если этот путь становится недоступным, то приходится ожидать завершения работы сетевого программного обеспечения по накоплению маршрутной информации, пока не станет доступным альтернативный путь
Неправильно настроен список доступа
Шаг 1. Воспользуйтесь exec-командой trace, чтобы определить маршрут, выбранный для перенаправления пакетов к удаленным хостам.
Шаг 2. Если при прохождении по этому маршруту будет обнаружен маршрутизатор, который блокирует трафик, вызовите на выполнение привилегированную exec-команду show access-lists, чтобы определить, введены ли в состав конфигурации этого маршрутизатора какие-либо списки доступа.
Шаг 3. Отмените применение всех списков доступа в маршрутизаторе, вызвав на выполнение команды конфигурации интерфейса по access-group во всех соответствующих интерфейсах.
Проблема
Решение
Шаг 4. Определите, может ли теперь рассматриваемый протокат использоваться в хостах. Если маршрутизатор больше не препятствует прохождению трафика, то, вероятно, трафик протокола был заблокирован одним из списков доступа.
Шаг 5. Убедитесь в том, что данный список доступа не отфильтровывает трафик, поступающий из портов, используемых программным обеспечением рассматриваемого протокола. Введите в конфигурацию явно заданные операторы permit для трафика, который должен перенаправляться маршрутизатором обычным образом.
Шаг 6. Снова разрешите применение данного списка доступа и проверьте, продолжает ли программное обеспечение протокола функционировать правильно. Если нарушение в работе не устранено, продолжайте отыскивать, анализировать и исправлять неправильные списки доступа во всех маршрутизаторах на пути от отправителя к получателю
Нарушение в работе аппаратных средств или передающей средыНарушение в работе аппаратных средств или передающей средыДополнительная информация об устранении нарушений в работе аппаратных средств приведена в главе 3. Для получения дополнительной информации по устранению нарушений в работе различных вариантов передающей среды обратитесь к соответствующей главе данной книги
Нарушение в работе аппаратных средств или передающей среды
Нарушение в работе аппаратных средств или передающей среды
ISO CLNS: перераспределение маршрутов приводит к появлению проблем маршрутизации
Признак неисправности. Средства перераспределения маршрута не функционируют должным образом и вызывают нарушения маршрутизации. Трафик не проходит через маршрутизатор, который перераспределяет маршруты между Двумя различными зонами или доменами маршрутизации (как правило, IS-IS и ISO IGRP). Наблюдаемые признаки неисправности показывают либо низкую производительность, либо полное отсутствие связи.
В табл. 12.8 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
«Таблица 12.8. ISO’.CLNSinepepacnределение маршрутов приводит’
^Wr »./ ^,к>появлению проблем маршрутизации 2 >и^2:лЛ.г, i.Y I
Порядковые номера заданы непоследовательно
Порядковые номера, используемые в командах конфигурации маршрутизатора route-map, определяют последовательность проверки условий перераспределения маршрутов. Если порядковые номера заданы непоследовательно, это может привести к нарушению в работе средств перераспределения.
Шаг 1. Воспользуйтесь привилегированной exec-командой show running- ■ config для просмотра информации о конфигурации маршрутизатора.
Найдите записи команды конфигурации маршрутизатора route-map.
Проблема
Решение
Проблема
Решение
Шаг 2. Если в состав конфигурации входят команды route-map, проверьте, какие порядковые номера им присвоены. Записи с меньшими порядковыми номерами проверяются перед записями с большими порядковыми номерами, независимо от того, в какой последовательности эти записи входят в состав конфигурации.
Шаг 3. Если условия перераспределения маршрутов проверяются не в той последовательности, в которой требуется, необходимо откорректировать порядковые номера записей, чтобы изменить последовательность проверки. Синтаксическая структура команды route-map, позволяющей откорректировать порядковый номер, приведена ниже. Основное назначение этой команды, наряду с командами match и set, состоит в определении карты маршрута, которая задает условия перераспределения маршрутов от одного маршрутизирующего протокола к другому.
route-map map-tag {permit | deny} sequence-number
Описание синтаксиса
map-tag. Мнемоническое имя для данной карты маршрута. Это имя может использоваться в команде redistribute для ссылки на данную карту маршрута. Для создания набора карт маршрута нескольким картам маршрута может быть присвоено одинаковое имя. В качестве данного параметра можно также указать выражение фильтрации или набор фильтров.
permit. Если для данной карты маршрута удовлетворены критерии, заданные в команде match, и указан параметр permit, то происходит перераспределение маршрута на основе действий, заданных в команде set. Если же критерии команды match не удовлетворены и указан параметр permit, то происходит переход к следующей команде определения карты маршрута route-map с тем же мнемоническим именем. Если маршрут не соответствует ни одному из критериев, заданных в наборе команд route-map, этот набор команд не применяется для перераспределения маршрутов.
deny. Если для данной карты маршрута удовлетворены критерии, заданные в команде match, и указан параметр deny, то перераспределение маршрута не выполняется и дальнейшая обработка команд route-map с тем же значением параметра map-tag прекращается.
sequence-number. Число, которое указывает положение новой карты маршрута в наборе карт маршрута с тем же именем, уже введенных в конфигурацию. Если эта команда задана с префиксом по, она указывает, что карта маршрута с указанным по- •рядковым номером должна быть удалена
В конфигурации Шаг 1. Воспользуйтесь exec-командой show running-config для просмотра отсутствует илиинформации о конфигурации маршрутизатора. Найдите запись
неправильно на-команды конфигурации маршрутизатора default-metric,
строена команда default-metric
Проблема
Решение
Шаг 2. Если команда конфигурации маршрутизатора default-metric или distance отсутствует, введите соответствующую версию недостающей команды.
Синтаксис
Синтаксическая структура команды default-metric показана ниже.
default-metric number
Описание синтаксиса
number. Применяемое по умолчанию значение метрики, соответствующее указанному маршрутизирующему протоколу.
Синтаксис
Синтаксическая структура команды distance показана ниже.
distance value [tins]
Описание синтаксиса
value. Установленное администратором значение расстояния, которое указывает, в какой степени заслуживает доверия определенный источник маршрутной информации. Этот параметр может иметь числовое значение от 0 от 255. Если источник имеет более высокое значение параметра value по сравнению с другими источниками, это означает, что он заслуживает меньше доверия. Предпочтение отдается маршрутам с меньшими значениями. Если этот параметр не задан, он по умолчанию принимает значение 110.
tins. (Необязательный параметр.) При формировании маршрутов для протокола IS-IS применяется служба CLNS.
Дополнительная информация о настройке применяемых по умолчанию метрик ISO CLNS приведена в документах Cisco IOS Network Protocols Configuration Guide, Part 2 и Network Protocols Command Reference, Part 2
В конфигурации отсутствует или неправильно настроена команда distance
Шаг 1. Воспользуйтесь ехес-командой show running-config для просмотра информации о конфигурации маршрутизатора. Найдите запись команды конфигурации маршрутизатора distance.
Шаг 2. Если команда конфигурации маршрутизатора distance отсутствует, введите ее в конфигурацию. Команда distance позволяет ввести в состав конфигурации заданное администратором расстояние для динамически сформированных маршрутов CLNS.
Синтаксис
Синтаксическая структура команды distance показана ниже.
Distance value [tins]
Проблема
Решение
Описание синтаксиса
value. Установленное администратором значение расстояния, которое указывает, в какой степени заслуживает доверия определенный источник маршрутной информации. Этот параметр может иметь числовое значение от 0 от 255. Если источник имеет более высокое значение параметра value по сравнению с другими источниками, это означает, что он заслуживает меньше доверия. Предпочтение отдается маршрутам с меньшими значениями. Если этот параметр не задан, он по умолчанию принимает значение 110.
clns. (Необязательный параметр.) При формировании маршрутов для протокола IS-IS применяется служба CLNS.
Пример
В следующем примере динамически накопленное значение distance для маршрутов CLNS равно 90. Приоритет будет отдан этим маршрутам CLNS, а не маршрутам с применяемым по умолчанию административным значением distance, равным ПО: router isis distance 90 clns
В конфигурации средств перераспределения имеется петля обратной связи
Перераспределение маршрутов между открытыми сетями IS-IS и ISO IGRP должно осуществляться только в одной точке. В противном случае в одной из открытых сетей извещения с маршрутной информацией могут передаваться в обратном направлении, что может вызвать появление петли обратной связи при передаче маршрутной информации.
Примеры
В следующем примере показано перераспределение маршрутов сетей Michigan ISO IGRP и Ohio ISO IGRP для создания зоны IS-IS, обозначенной как USA:
router isis USA
redistribute iso-igrp Michigan
redistribute iso-igrp Ohio
В следующем примере показано перераспределение маршрутов сетей France IS-IS и Germany ISO IGRP для создания зоны ISO IGRP, обозначенной как Backbone:
router iso-igrp Backbone
redistribute isis France
redistribute iso-igrp Germany
Если перераспределение маршрутов должно осуществляться еще в одной точке, примените предусмотренные по умолчанию метрики, чтобы обеспечить перераспределение только в одном направлении.
Дополнительная информация о настройке применяемых по умолчанию метрик ISO CLNS приведена в документах Cisco IOS Network Protocols Configuration Guide, Part 2 и Network Protocols Command Reference, Part 2
В конфигурацию одного интерфейса введена поддержка нескольких процессов ISO IGRPВ конфигурацию одного интерфейса введена поддержка нескольких процессов ISO IGRPМост или повторитель подключен параллельно с маршрутизаторомМост или повторитель подключен параллельно с маршрутизатором
В конфигурацию одного интерфейса введена поддержка нескольких процессов ISO IGRP
В конфигурацию одного интерфейса введена поддержка нескольких процессов ISO IGRP
Мост или повторитель подключен параллельно с маршрутизатором
Мост или повторитель подключен параллельно с маршрутизатором
ISO CLNS: низкая производительность
Признак неисправности. Пользователи замечают, что сеть характеризуется низкой производительностью или внезапно происходит разрыв соединений. Один или несколько маршрутизаторов могут получать двойные обновления маршрутизации, а информация о маршрутизаторах и оконечных станциях поступает через несколько интерфейсов.
В табл. 12.9 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 12.9.ISO CLNS: низкая производительность
ПроблемаРешение
Шаг 1. Вызовите на выполнение exec-команду show clns interface для просмотра информации о конфигурации интерфейса. Определите, не была ли в конфигурации одного интерфейса введена поддержка нескольких процессов ISO IGRP.
Шаг 2. Если в конфигурации одного интерфейса введена поддержка нескольких процессов ISO IGRP, то через один и тот же интерфейс передаются разные обновления уровня 2.
Передача разных обновлений уровня 2 через один и тот же интерфейс может привести к возникновению затора, особенно если сеть является достаточно большой и в ней наблюдается самопроизвольное изменение маршрутов с периодичностью, превышающей продолжительность интервалов, в течение которых не допускается изменение конфигурации сети. Самопроизвольное изменение маршрутов — это нарушение процесса маршрутизации, характеризующееся тем, что из-за неисправности в сети, при которой один из интерфейсов время от времени перестает функционировать, объявленный маршрут между двумя узлами периодически заменяется другим маршрутом, а затем снова восстанавливается (происходит так называемая переброска маршрутов).
Шаг 3. Удалите команды поддержки лишних процессов ISO IGRP из конфигурации интерфейса с использованием соответствующей команды конфигурации интерфейса no clns router iso-igrp
Если параллельно с маршрутизатором подключен мост или повторитель, то в маршрутизатор из разных интерфейсов могут поступать одинаковые обновления и пакеты.
Шаг 1. Вызовите на выполнение exec-команды show clns is-neighbors detail и show clns neighbors detail, чтобы определить, из каких маршрутизаторов и по каким протоколам в данный маршрутизатор поступает информация об отношениях смежности.
Пример вывода команды show clns neighbors detail приведен ниже.
routeri show clns neighbors detail
System IdSNPAInterface State Holdtime
Type Protocol 000.0000.0007 aaOO.0400.6408 EthernetO Init 291
IS ES-IS
Area Address(es): 47.0005.80FF.F500.0000.0003.0020
0000.0C00.0C35 0000.0c00.0c36 Ethernetl Up 94 LI IS-IS
Проблема
Решение
Area Address(es): 47.0004.004D.0001 39.0001 0800.2В16.24ЕА aa00.0400.2d05 EthernetO Up 9 L1L2 IS-IS
Area Address(es): 47.0004.004D.0001
08O0.2B14.060E aaOO.0400.9205 EthernetO Up 1651
ES ES-IS
Area Address(es): 49.0040
0000.0C00.3E51 *HDLC*Seriall Up 27
L2 IS-IS
Area Address(es): 39.0004
0000.0C00.62E6 0000.0c00.62e7 Ethernetl Up 26
LI IS-IS
Area Address(es): 47.0004.004D.0001
0A00.0400.2D05 aaOO.O4OO.2dO5 EthernetO Init 29
IS ES-IS
Area Address(es): 47.0004.004D.0001
Найдите маршрутизаторы, которые, как известно, находятся в удаленной сети. Если в таблице смежности указан маршрутизатор, не находящийся в непосредственно подключенной сети, это указывает на наличие рассматриваемой проблемы.
В выводе этой команды можно также проверить, не показаны ли пути к сетям (или зонам) в нескольких интерфейсах.
Шаг 2. Если обнаружен параллельно подключенный мост или повторитель, удалите соответствующее устройство из сети или введите в конфигурацию маршрутизатора фильтры, блокирующие прием обновлений маршрутизации от этого устройства
Нарушения в процессе перераспределения маршрутов
Снижение производительности может быть вызвано неправильной настройкой средств перераспределения маршрутов. Дополнительные рекомендации по устранению этого нарушения в работе приведены выше, в разделе “ISO CLNS: перераспределение маршрутов приводит к появлению проблем маршрутизации"
Глава
13
странение нарушении аботе сети Banyan VINES
ем
Эталонная
со
14).
получ
обеспечение сети Banyan VINES (Virtual Integrated Network Service — ированная сетевая служба) представляет собой распределенную се-
ю опе^й^^удо систему, основанную на собственном семействе протоколов, номина ботоколов XNS корпорации Xerox (подробно об этом — в главе
меняется архитектура типа клиент/сервер, в которой клиенты
серве^^пределенные услуги, такие как доступ к файлам и принтерам. VINES принадлежитслу наиболее широко известных версий распределенных сисл с^й на (Основе микро- ЭВМ наряду с NetWare корпорации Novell, LAN корпорации У^и LAN Manager корпорации Microsoft.
новы технологии VINES
wtxt™ показан на рис 13 1
Протокол VINES
Файловые
Службыпечати
StreetTalk
Другиеприложения
RPC
IPC(дейтаграммный)
VIP
SPP(потоковый)
ARP RTP ICP
Протоколы доступа к передающей среде
Рис. 13.1. Стек, протоколов VINES
Доступ к передающей среде в сети VINES
В двух нижних уровнях стека VINES реализована поддержка целого ряда широко известных механизмов доступа к передаюшей среде, включая HDLC, SDLC и их производные, а также Х.25, Ethernet и Token Ring.
Сетевой уровень
Для реализации функций уровня 3 (включая межсетевую маршрутизацию) в сети VINES применяется протокол VIP (VINES Internetwork Protocol — протокол объединенной сети VINES). Кроме того, в сети VINES предусмотрена поддержка собственного протокола ARP, собственной версии протокола RIP, называемой RTP (Routing Table Protocol — протокол таблиц маршрутизации), и протокола ICP (Internet Control Protocol — межсетевой управляющий протокол), который обеспечивает обработку исключений и предоставляет специальную информацию о стоимости маршрутов. Пакеты ARP, ICP и RTP инкапсулируются в заголовок VIP.
Протокол VIP
Адреса сетевого уровня VINES представляют собой 48-битовые объекты, которые подразделяются на компоненты с обозначением сети (32 бита) и подсети (16 битов). Номер сети, по сути, представляет собой номер сервера, поскольку он непосредственно образуется с помощью ключа сервера (аппаратного модуля, который обозначает уникальный номер и опции программного обеспечения для сервера). Компонент адреса VINES, который относится к подсети, вполне можно рассматривать как номер хоста, поскольку он применяется для обозначения хостов в сетях VINES. На рис. 13.2 показан формат адреса VINES.
132 3348
Номер сети
Номер подсети
(Номер сервера) (Номер хоста)
Рис. 13.2. Формат адреса VINES
Номер сети обозначает логическую сеть VINES, которая представляет собой двухуровневое дерево, корень которого находится в сервисном узле. Сервисные узлы (как правило, серверы) обеспечивают преобразование адресов и предоставляют услуги по маршрутизации клиентам (которые условно отображаются в виде листьев дерева). Сервисный узел назначает клиентам VIP-адреса.
После включения питания и начальной загрузки клиентский узел выполняет широковещательную рассылку запроса к серверам. Ответы присылают все серверы, получившие запрос. Клиент выбирает самый первый ответ и запрашивает от соответствующего сервера адрес подсети (хоста). Сервер в ответ передает адрес, состоящий из собственного адреса сети (вычисленного на основе его ключа), за которым следует выбранный сервером адрес подсети (хоста). Клиентские адреса подсети, как правило, назначаются последовательно, начиная от 8001Н. Серверные адреса подсети всегда равны 1. Процесс выбора адреса в сети VINES показан на рис. 13.3.
Рис. 13.3. Процесс выбора адреса в сети VINESРис. 13.3. Процесс выбора адреса в сети VINES
Рис. 13.3. Процесс выбора адреса в сети VINES
Рис. 13.3. Процесс выбора адреса в сети VINES
Динамическое назначение адреса применяется не только в сети VINES (аналогичный процесс происходит и в сети AppleTalk), но такой метод, безусловно, встречается гораздо реже по сравнению со статическим присваиванием адресов. Адреса выбираются исключительно конкретным сервером (имеющим уникальный адрес, поскольку уникальным является его аппаратный ключ), поэтому вероятность появления повторяющегося адреса (а такая проблема может полностью нарушить функционирование протокола IP и других протоколов) является очень низкой.
В сетевой архитектуре VINES все серверы с несколькими сетевыми интерфейсами, по сути, выполняют функции маршрутизаторов. Клиент всегда выбирает в качестве первого маршрутизатора свой собственный сервер, даже если другой сервер в том же сетевом сегменте может предоставить лучший маршрут к окончательному месту назначения. Клиент может накопить информацию о других маршрутизаторах, получая
перенаправляющие сообщения от своего собственного сервера. Поскольку клиенты всегда обращаются к своим серверам, впервые определяя маршрут к получателю, серверы VINES поддерживают таблицы маршрутизации, позволяющие клиентам находить удаленные узлы.
Таблицы маршрутизации VINES состоят из пар элементов с обозначением хос- та/стоимости, где элемент с обозначением хоста соответствует сетевому узлу, доступ к которому может быть получен с этого сервера, а элемент с обозначением стоимости содержит данные о сетевой задержке, выраженной в миллисекундах, которая наблюдается при прохождении пакета к этому узлу. В серверах VINES для поиска соседних клиентов, серверов и маршрутизаторов применяется протокол RTP.
Время от времени все клиенты рассылают извещения о своих адресах сетевого уровня и уровня МАС с помощью пакетов, которые можно рассматривать как hello- пакеты. Получая hello-пакеты, серверы могут определить, что тот или иной клиент все еще функционирует и сеть готова к работе. Сами серверы периодически рассылают по другим серверам обновления маршрутов. В обновлениях маршрутов содержатся предупреждения другим маршрутизаторам об изменениях адресов узлов и топологии сети.
После получения пакета сервер VINES проверяет, предназначен ли пакет для другого сервера или является широковещательным. Если получателем является текущий сервер, он обрабатывает запрос соответствующим образом. Если же получателем является другой сервер, то текущий сервер либо передает пакет непосредственно ему (если сервер- получатель является по отношению к нему соседним), либо перенаправляет пакет следующему серверу по направлению к месту назначения. Если же пакет является широковещательным, то текущий сервер проверяет, прошел ли данный пакет по пути с наименьшей стоимостью. Если это не так, пакет отбрасывается, а если это условие соблюдается, то пакет перенаправляется во все интерфейсы, кроме того, из которого он был получен. Такой подход позволяет уменьшить вероятность лавинообразной рассылки широковещательных пакетов (а эта проблема часто встречается в других сетевых архитектурах). Блок-схема алгоритма маршрутизации VINES показана на рис. 13.4.
Формат пакета VIP приведен на рис. 13.5.
Ниже описаны поля пакета VIР.
Контрольная сумма. Применяется для обнаружения искаженных пакетов.
Длина пакета. Указывает длину всего пакета VIP.
Управление транспортом. Состоит из нескольких подполей. Если пакет является широковещательным, это поле включает два подполя: класс (биты от 1 до 3) и число участков маршрута (биты от 4 до 7). Если пакет не является широковещательным, данное поле подразделяется на четыре подполя: способ обработки ошибок, метрика, перенаправление и число участков маршрута. Подполе класса определяет тип узла, который должен получить этот широковещательный пакет. По этому принципу узлы подразделяются на разные категории, характеризующие тип узла и тип канала, к которому подключен узел. Подполе класса позволяет указать тип узлов, для которых предназначается широковещательный пакет, что дает возможность уменьшить отрицательное воздействие на работу сети, вызванное широковещательными рассылками. Подполе числа участков маршрута содержит данные о числе участков маршрута (о количестве промежуточных маршрутизаторов), которые были пройдены пакетом. Подполе с обозначением способа обработки ошибок содержит информацию о том, должно ли программное обеспечение протокола ICP передать пакет с извещением об ис-
ключительной ситуации отправителю пакета, если будет обнаружено, что дальнейшая маршрутизация пакета невозможна. Значение подполя метрики устанавливается равным 1, если некоторый объект транспортного уровня должен получить информацию о стоимости прохождения по маршруту при перемещении пакетов от сервисного узла к соседнему узлу. Подполе перенаправления указывает, должен ли маршрутизатор формировать сообщение о перенаправлении (если в этом возникает необходимость).
Рис. 13.4. Блок-схема алгоритма маршрутизации VINES
Контрольная сумма
Длина пакета
Управление транспортом
Тип протокола
Номер сети получателя
Номер подсети получателя
Номер сети отправителя
Номер подсети отправителя
Данные
22
2 Переменная
Длина поля в байтах
Рис. 13.5. Формат пакета VIP
Тип протокола. Указывает протокол сетевого или транспортного уровня, для которого предназначен пакет с метрикой или извещением об исключительной ситуации.
Номер сети получателя, номер подсети получателя, номер сети отправителя и номер подсети отправителя. Эти поля содержат информацию о VIP-адресе.
Протокол RTP
Протокол RTP применяется для распространения информации о топологии сети. И клиентские, и сервисные узлы время от времени выполняют широковещательную рассылку пакетов обновления маршрутов. Эти пакеты позволяют соседним узлам получить информацию о существовании других узлов и определить, является ли данный узел клиентским или сервисным. Сервисные узлы включают также в каждый пакет обновления маршрутизации список всех известных сетей и информацию о стоимости достижения этих сетей.
В каждом узле ведутся две таблицы маршрутизации: таблица всех известных сетей и таблица соседних узлов. В сервисных узлах таблица всех известных сетей содержит по одной записи для каждой известной сети, кроме собственной сети сервисного узла. Каждая запись содержит номер сети, метрику маршрутизации и указатель на запись для следующего участка маршрута к этой сети в таблице соседних узлов. Таблица соседних узлов содержит по одной записи для каждого соседнего сервисного и клиентского узла. Записи таблицы содержат номер сети, номер подсети, название протокола доступа к передающей среде (например, Ethernet), применяемого для доступа к этому узлу, адрес локальной сети (если передающей средой, через которую данный узел может связаться с соседним узлом, является локальная сеть) и метрику соседнего узла.
В спецификации протокола RTP определены четыре типа пакетов.
Обновление маршрутизации. Передается время от времени для уведомления соседних узлов о существовании данного сетевого объекта.
Запрос маршрутной информации. Передается одним сетевым объектом другому, если возникает необходимость быстро получить сведения о топологии сети.
Ответ с маршрутной информацией. Содержит информацию о топологии сети и применяется сервисными узлами для передачи ответов на пакеты с запросами маршрутной информации.
Перенаправление маршрута. Предоставляет узлам, в которых используются неэффективные маршруты, информацию о лучших маршрутах.
Каждый пакет RTP имеет четырехбайтовый заголовок, состоящий из следующих однобайтовых полей.
Тип операции. Обозначает тип пакета.
Тип узла. Указывает, поступил ли пакет из сервисного узла или несервисного узла.
Тип контроллера. Содержит информацию о том, является ли контроллер в узле, передавшим пакет RTP, мультибуферным контроллером.
Тип компьютера. Указывает, является ли процессор в узле-отправителе пакета RTP быстрым или медленным.
Поля с обозначением типа контроллера и типа компьютера предназначены для использования в будущих версиях.
Протокол ARP
Объекты ARP подразделяются на клиенты службы преобразования адресов и сами службы преобразования адресов. Клиенты службы преобразования адресов обычно реализованы в клиентских узлах, а службы преобразования адресов, как правило, предоставляются сервисными узлами.
Пакет ARP имеет восьмибайтовый заголовок, состоящий из двухбайтового поля типа пакета, четырехбайтового поля номера сети и двухбайтового поля номера подсети. Пакеты подразделяются на четыре типа: запрос к службе ARP, ответ службы на запрос, запрос присваивания, который передается службе ARP межсетевого адреса VINES, и ответ присваивания, передаваемый службой ARP в ответ на запрос присваивания. Поля с номером сети и номером подсети имеют смысл только в пакете ответа присваивания.
При запуске клиента клиенты и службы ARP реализуют определенный алгоритм. Прежде всего клиент выполняет широковещательную рассылку пакета запроса. Затем служба ARP каждого соседнего узла клиента возвращает пакет ответа службы. После этого клиент отправляет пакет запроса присваивания той службе, от которой был получен первый ответ на пакет запроса клиента. Служба возвращает пакет ответа присваивания, содержащий межсетевой адрес, присвоенный клиенту.
Протокол ICP
Спецификация ICP определяет форматы пакетов с извещением об исключительной ситуации и извещением о метрике. Пакеты с извещением об исключительной ситуации предоставляют информацию об исключениях, возникающих в процессе функционирования протокола сетевого уровня; пакеты с извещением о метрике содержат информацию о том, какая последняя операция передачи данных была выполнена для достижения клиентского узла.
Пакеты с извещением об исключительной ситуации передаются, если маршрутизация пакета VIР не может быть выполнена должным образом, а подполе с обозначением способа обработки ошибок в поле управления транспортным уровнем заголовка пакета VIР указывает, что обработка ошибок разрешена. Эти пакеты содержат также поле с обозначением конкретного исключения с помощью кода ошибки.
Объекты ICP в сервисных узлах генерируют сообщения с извещениями о метрике, если подпале метрики в поле управления транспортным уровнем заголовка пакета VIР указывает, что должна накапливаться информация о метрике, и в качестве адреса назначения в пакете сервисного узла указан адрес одного из соседних узлов данного сервисного узла.
Транспортный уровень
В сети VINES предоставляется доступ к следующим службам транспортного уровня.
Ненадежная служба передачи дейтаграмм. Обеспечивает передачу пакетов, которые маршрутизируются программным обеспечением протокола по принципу выполнения всего от него зависящего, но не более того; при этом получатель не подтверждает прием этих пакетов.
Надежная служба передачи сообщений. Служба виртуального канала, которая обеспечивает надежную упорядоченную и подтверждаемую доставку сообщений от одного сетевого узла к другому. Для надежной передачи сообщения может применяться не больше четырех пакетов VIР.
Служба потоковой передачи данных. Обеспечивает управляемую потоковую передачу данных от одного процесса к другому. Эта служба потоковой передачи данных представляет собой службу виртуального канала передачи данных с подтверждением, которая обеспечивает передачу сообщений неограниченного размера.
Протоколы верхнего уровня
В сети VINES, которая представляет собой распределенную сеть, для обеспечения взаимодействия клиентов и серверов применяется модель дистанционного вызова удаленных процедур (RPC — Remote-Procedure Call). Модель RPC является основой любой распределенной службы. Программное обеспечение протокола NetRPC (уровня 5 и 6) поддерживает язык программирования высокого уровня, позволяющий получить доступ к удаленным службам, который является прозрачным и для пользователей, и для приложений.
На уровне 7 сеть VINES предоставляет доступ к приложениям файловой службы и службы печати, а также к службе StreetTalk, которая представляет собой единую глобальную службу имен для всей объединенной сети.
Кроме того, в сети VINES обеспечивается доступ к интегрированной среде разработки приложений, предназначенных для многих разных операционных систем, включая DOS и UNIX. Эта среда разработки позволяет независимым разработчикам создавать и клиенты, и службы, которые могут эксплуатироваться в среде VINES.
Устранение нарушений в работе сети
Banyan VINES
' В настоящем разделе представлены сведения, позволяющие устранять нарушения в работе, характеризующиеся отсутствием связи в сети Banyan VINES, которые зависят от правильного функционирования программного обеспечения протокола. Здесь описаны конкретные признаки неисправности в сети VINES, перечислены проблемы, которые могут вызвать появление каждого признака неисправности, и приведены решения этих проблем.
В перечисленных ниже разделах рассматриваются наиболее распространенные нарушения в работе сети Banyan VINES.
VINES: клиенты не могут подключиться к серверам через маршрутизатор.
VINES: клиент не может подключиться к серверу через сеть с коммутацией пакетов.
VINES: клиент бессерверной сети не может подключиться к серверу через сеть с коммутацией пакетов.
VINES: клиенты не могут подключиться к серверам через маршрутизатор
Признак неисправности. Клиенты не могут подключиться к серверам VINES через один или несколько маршрутизаторов. Клиенты могут иметь или не иметь возможность подключиться к серверам в сети, с которой они непосредственно соединены.
В табл. 13.1 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 13.1. VINES: клиенты не могут подключиться к серверам через маршрутизатор
Проблема
Решение
Программное обеспечение интерфейса маршрутизатора остановлено
Шаг 1. Вызовите на выполнение ехес-команду show interfaces в маршрутизаторе, чтобы проверить состояние интерфейсов маршрутизатора.
Шаг 2. Если строка состояния указывает, что интерфейс, который должен находиться в рабочем состоянии, остановлен администратором ("administratively down"), вызовите на выполнение в интерфейсе команду конфигурации интерфейса no shutdown.
Обратитесь к главе с описанием процедур устранения нарушений в работе передающей среды, используемой в конкретной сети
Нарушение в работе аппаратных средств или передающей среды
Для получения дополнительной информации об устранении нарушений в работе аппаратных средств обратитесь к главе, в которой рассматривается передающая среда, применяемая в конкретной сети
Нарушение в работе средств адресации
Шаг 1. В бессерверном сегменте вызовите на выполнение ехес-команду show vines route, чтобы убедиться в том, что маршрутизатор имеет информацию об адресах серверов сетевого уровня.
Шаг 2. Если маршрутизатор не имеет информации об адресах серверов, проверьте, являются ли правильными адреса сервера и маршрутизатора. Синтаксическая структура команды, применяемой для корректировки адреса, приведена ниже, vines routing [address | recompute]
Описание синтаксиса
address. (Необязательный параметр.) Сетевой адрес маршрутизатора. Адрес должен быть указан для того маршрутизатора, который не имеет ни одного интерфейса Ethernet или FDDI. Кроме того, адрес может быть указан в том маловероятном случае, если два маршрутизатора отображают свой аппаратный адрес в один и тот же сетевой адрес.
recompute. (Необязательный параметр.) Параметр указывает, что сетевой адрес маршрутизатора должен переопределяться динамически при каждой начальной загрузке
Не задано значение метрики VINES
Шаг 1. Вызовите на выполнение ехес-команду show vines interface, чтобы проверить состояние интерфейсов VINES в маршрутизаторе. Убедитесь в том, что в конфигурацию всех интерфейсов VINES входит команда конфигурации интерфейса vines-metric. Команда metric обеспечивает обработку пакетов VINES в интерфейсе.
Шаг 2. Если команда конфигурации интерфейса vines-metric не входит в состав конфигурации интерфейса, задайте эту команду для данного интерфейса.
Значение параметра команды vines-metric в конфигурации зависит от того, подключен ли интерфейс к локальной или распределенной сети. Ниже приведены рекомендуемые значения метрик для различных соединений локальной и распределенной сетей.
Проблема
Решение
Сеть Token Ring с пропускной способностью 16 Мбит/с и сеть Ethernet: vines-metric 2
Сеть Token Ring с пропускной способностью 4 Мбит/с: vines- metric 4
Канал Tl: vines-metric 35
Другие каналы распределенной сети: vines-metric 45
Пропущены команды vines serverless и vines arp-enable
Настройка конфигурации сети, в которой отсутствует подключенный к ней сервер, должна быть выполнена с помощью команд конфигурации маршрутизатора vines serverless broadcast и vines arp-enable.
Примечание. Применение этих команд разрешено по умолчанию в программном обеспечении Cisco IOS 10.3 и в последующих версиях.
Шаг 1. Вызовите на выполнение привилегированную exec-команду show running-config в маршрутизаторах, установленных в сетях, к которым не подключены серверы VINES. Найдите записи команд конфигурации маршрутизатора vines serverless и vines arp-enable.
Шаг 2. Если в составе конфигурации не присутствуют одновременно команды vines serverless и vines arp-enable, задайте их для интерфейсов маршрутизатора в бессерверных сетях.
Синтаксис
При вводе команды vines serverless необходимо применять следующую синтаксическую структуру: vines serverless [dynamic | broadcast]
Описание синтаксиса
dynamic. (Необязательный параметр.) Указывает, что перенаправление широковещательных пакетов должно выполняться только в один сервер, если в сети, подключенной к данному интерфейсу, отсутствуют серверы.
broadcast. (Необязательный параметр.) Указывает, что через все остальные интерфейсы маршрутизатора должна выполняться лавинная широковещательная рассылка, чтобы широковещательные пакеты достигали всех серверов.
Синтаксис
При вводе команды vines arp-enable необходимо применять следующую синтаксическую структуру: vines arp-enable [dynamic]
Описание синтаксиса
dynamic. (Необязательный параметр.) Ответы на запросы ARP и SARP (Sequenced Address Resolution Protocol — протокол упорядоченного преобразования адресов) должны передаваться через этот интерфейс, только если в сети нет других серверов VINES
ПроблемаРешение
Неправильно Шаг 1. Вызовите на выполнение привилегированную exec-команду show настроен списокvines access-lists во всех маршрутизаторах в пути от отправителя
доступак получателю. Эта команда показывает, входят ли в состав кон
фигурации маршрутизатора какие-либо списки доступа.
Шаг 2. Отмените применение в маршрутизаторе всех списков доступа, входящих в состав его конфигурации, с помощью команды по vines access-group.
Шаг 3. Попытайтесь установить соединение от клиента к серверу, чтобы определить, появилась ли теперь возможность устанавливать соединения. Если соединение установлено успешно, это означает, что трафик блокируется под действием списка доступа.
Шаг 4. Чтобы определить список доступа, содержащий ошибку, последовательно вводите в конфигурацию по одному оператору accesslist до тех пор, не исчезнет возможность создавать соединения.
Шаг 5. После обнаружения ошибочного списка доступа внесите в него такие изменения, чтобы он не препятствовал прохождению всего необходимого трафика. При устранении нарушений в работе бессерверного сегмента убедитесь в том, что не отфильтровывается трафик, проходящий через такие общепринятые порты, как 0x06 (служба доступа к файлам VINES) и ОхОЕ (служба StreetTalk). Введите в конфигурацию явно заданные операторы permit для трафика, который должен перенаправляться маршрутизатором обычным образом.
Шаг 6. Если нарушение в работе не устранено, продолжайте отыскивать, анализировать и исправлять неправильные списки доступа во всех маршрутизаторах на пути от отправителя к получателю
VINES: клиент не может подключиться к серверу через сеть с коммутацией пакетов
Признак неисправности. Клиенты не могут подключиться к серверам VINES через сеть с коммутацией пакетов. Клиенты могут подключиться к локальным серверам VINES.
В табл. 13.2 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
: Таблица 13.2. VINES: клиент не может подключиться к серверу через сеть i ;с коммутацией пакетов ■\J
ПроблемаРешение
Ошибка преобразования адресовОшибка преобразования адресовШаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора.
Ошибка преобразования адресов
Ошибка преобразования адресов
Шаг 2. В среде Х.25 убедитесь в том, что в параметрах преобразования протокольного адреса локальной сети в адрес Х.121 записей команд конфигурации интерфейса х25 map vines используются адреса VINES и Х.121 маршрутизаторов назначения. Проверьте, правильно ли заданы адреса назначения в записях команд.
Проблема
Решение
Шаг 3. В среде Frame Relay убедитесь в том, что в параметрах преобразования протокольного адреса локальной сети в адрес DLCI записей команд конфигурации интерфейса frame-relay map используются адрес VINES маршрутизатора назначения и адрес DLCI локального интерфейса. Проверьте, правильно ли заданы адрес назначения и локальный адрес DLCI в записях команд
Не установлен постоянный виртуальный канал
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации локального и удаленного маршрутизаторов. Убедитесь в том, что в локальном и удаленном маршрутизаторах задана команда конфигурации интерфейса х25 pvc п vines address. Эта команда устанавливает постоянный виртуальный канал между двумя маршрутизаторами.
Шаг 2. Если такая команда отсутствует, введите ее в состав конфигурации маршрутизатора
VINES: клиент бессерверной сети не может подключиться к серверу через сеть с коммутацией пакетов
Признак неисправности. Клиенты в бессерверной сети (т.е. в сетевом сегменте, к которому не подключены серверы VINES) не могут открыть соединение с сервером VINES через сеть с коммутацией пакетов.
В табл. 13.3 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
[ Таблица 13.3.'VINES: клиент бессерверной сети не может подключиться
к серверу через сеть с коммутацией пакетов ,
Проблема
Решение
Ошибка преобразования адресов
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора.
Шаг 2. В среде Х.25 убедитесь в том, что в параметрах преобразования протокольного адреса локальной сети в адрес Х.121 записей команд конфигурации интерфейса х25 map vines используются адреса VINES и адреса Х.121 маршрутизаторов назначения. Проверьте, правильно ли заданы адреса назначения в записях команд.
Синтаксис
х25 map protocol address [protoco!2 address2[...[protocol? address?]]] xl21-address [option] no x25 map protocol address xl21-address
Описание синтаксиса
protocol. Тип протокола, обозначенный ключевым словом. В одной командной строке может быть указано до девяти пар параметров protocol и address.
address. Протокольный адрес.
Проблема
Решение
xl21-address. Адрес Х.121 удаленного хоста.
option. (Необязательный параметр.) Дополнительные функциональные возможности, которые могут быть указаны для исходящих вызовов.
Шаг 3. В среде Frame Relay убедитесь в том, что в параметрах преобразования протокольного адреса локальной сети в адрес DLCI записей команд конфигурации интерфейса frame-relay map используются адрес VINES маршрутизатора назначения и адрес DLCI локального интерфейса. Проверьте, правильно ли заданы адрес назначения и локальный адрес DLCI в записях команд.
Синтаксис
frame-relay map protocol protocol-address dlci [broadcast] [ietf | cisco] [payload-compress {packet-by-packet | frf9 stac [hardware-options]} ]
no frame-relay map protocol protocol-address
Описание синтаксиса
protocol. Ключевое слово, обозначающее протокол, средство установления мостового соединения или подуровень управления логической связью: appletalk, decnet, dlsw, ip, ipx, Hc2, rsrb, vines или xns.
protocol-address. Протокольный адрес назначения.
dlci. Номер DLCI, который обычно применяется для подключения к указанному протокольному адресу в данном и нтерфейсе.
broadcast. (Необязательный параметр.) Форма инкапсуляции Frame Relay по спецификации IETF (Internet Engineering Task Force — Проблемная группа проектирования Internet). Применяется, если маршрутизатор или сервер доступа подключен к оборудованию другого поставщика через сеть Frame Relay.
cisco. (Необязательный параметр.) Метод инкапсуляции Cisco.
payload-compress packet-by-packet. (Необязательный параметр.) Предусматривает поочередное сжатие пакетов с использованием метода Stacker.
compress frf 9 stac. (Необязательный параметр.) Предусматривает сжатие пакетов по алгоритму FRF.9 с использованием метода Stacker.
Если маршрутизатор содержит адаптер CSA (Compression Service Adapter — адаптер службы сжатия данных), сжатие выполняется аппаратным обеспечением CSA (аппаратное сжатие, режим csa).
Если адаптер CSA отсутствует, сжатие выполняется программным обеспечением, установленным в процессоре VIP2 (распределенное сжатие, режим distributed).
Если отсутствует процессор VIP2, сжатие выполняется центральным процессором маршрутизатора (программное сжатие, режим software).
hardware-options. (Необязательный параметр.) Одно из следующих ключевых слов: distributed, software или csa
Проблема
Решение
Не установлен ПОСТОЯННЫЙ виртуальный канал
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизаторов. Убедитесь в том, что в маршрутизаторах, взаимодействующих через сеть с коммутацией пакетов, задана команда конфигурации интерфейса х25 pvc n vines address. Эта команда устанавливает постоянный виртуальный канал между двумя маршрутизаторами.
Шаг 2. Если такая команда отсутствует, введите ее в состав конфигурации маршрутизатора
Широковещательные пакеты VINES не перенаправляются через сеть с коммутацией пакетов
Шаг 1. Воспользуйтесь командой show running-config для проверки конфигурации маршрутизатора. Убедитесь в том, что в конфигурацию последовательного интерфейса маршрутизатора, который предоставляет службу доступа к бессерверному узлу с коммутацией пакетов, входит команда конфигурации интерфейса vines propagate.
Шаг 2. Если такая команда отсутствует, введите ее в состав конфигурации
Широковещательные пакеты VINES не перенаправляются во все интерфейсы маршрутизатора
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Проверьте, входит ли в состав конфигурации маршрутизатора команда конфигурации интерфейса vines serverless broadcast.
Шаг 2. Если такая команда отсутствует, введите ее в состав конфигурации маршрутизатора с помощью команды vines serverless broadcast. Эта команда позволяет настроить конфигурацию маршрутизатора так, чтобы он всегда выполнял лавинную рассылку широковещательных пакетов VINES через все интерфейсы.
Примечание. Применение команды vines serverless broadcast разрешено по умолчанию в программном обеспечении Cisco IOS 10.3 и последующих версиях
Глава
14
^Устранение нарушений Ж работе сети XNS
й Протоколы XNS были разработаны корпорацией Xerox в конце 1970-х — начале 1980-х годов. Они предназначались для использования со многими версиями пере- ^■[даюшей среды,- процессоров и офисных приложений. Некоторые протоколы XNS напоминают протоколы IP и TCP, разработанные DARPA (Defense Advanced Research Projects Agency — Агентство перспективных исследовательских программ) для Мини-
стерства обороны США.
Ж Поскольку протоколы XNS были легко доступны и рано появились на рынке, они Детали приценяться большинством компаний, которые первыми приступили к развер- ‘тыванию локальных сетей, включая Novell, Ungermann-Bass (в настоящее время вхо- ^дит в состав корпорации Tandem Computers) и ЗСот. В дальнейшем каждая из этих компаний внесла различные изменения в протоколы XNS. Корпорация Novell дополнительно ввела протокол SAP, позволяющий рассылать по сети анонсы о доступных ресурсах, и модифицировала протоколы OSI уровня 3 (присвоив им другое название— IPX, Internetwork Packet Exchange — межсетевой пакетный обмен) для их применения в сетях IEEE 802.3, а не в сетях Ethernet. Корпорация Ungermann-Bass провела доработку протокола RIP для учета сетевой задержки и количества транзитных переходов, пройденных пакетом, а также внесла другие небольшие изменения. Со ‘■""временем реализация протоколов XNS, предназначенная для организации сети персональных компьютеров, получила более широкое распространение по сравнению с первоначальной версией протоколов XNS, разработанной корпорацией Xerox.
В документации XNS такие протоколы, как Х.25, Ethernet и HDLC, упоминаются как протоколы уровня 0, но явное определение того, что относится к протоколам уровня 0, не дано. Как и во многих других наборах протоколов, в протоколах XNS вопрос о примене- «нии тех или иных методов доступа к передающей среде остается открытым и поэтому не' явно подразумевается, что для обеспечения передачи пакетов XNS в физической передающей среде может применяться любой транспортный протокол.
Сетевой уровень
& ’ Протокол XNS сетевого уровня носит название IDP (Internet Datagram Protocol — ^межсетевой дейтаграммный протокол). Протокол IDP выполняет стандартные функ-
ции уровня 3, включая логическую адресацию и доставку дейтаграмм от отправителя к получателю по объединенной сети. Формат пакета IDP показан на рис. 14.1.
Длина поля
в байтах 2 2 1 1462 4620-546
А
В
С
D
Е
F
G
Н
I
J
Данные
А — контрольная сумма
В — длина
С — управление транспортом
D — тип пакета
Е — номер сети получателя
F — номер хоста получателя
G — номер сокета получателя
Н — номер сети отправителя I — номер хоста отправителя J — номер сокета отправителя
Рис. 14.1. Формат пакета 1DP
Ниже описаны поля пакета IDP.
Контрольная сумма. 16-битовое поле, которое позволяет проверить целостность пакета после его прохождения по объединенной сети.
Длина. 16-битовое поле, которое содержит данные о полной длине текущей дейтаграммы (включая контрольную сумму).
Управление транспортом. 8-битовое поле, которое состоит из подполей с данными о числе участков маршрута и максимальном сроке жизни пакета (MPL — Maximum Packet Lifetime). Отправитель пакета устанавливает начальное значение подполя числа участков маршрута, равное нулю, которое увеличивается на единицу при прохождении дейтаграммы через каждый маршрутизатор. После того как значение подполя числа участков маршрута достигает 16, дейтаграмма отбрасывается согласно предположению, что возник циклический маршрут. Подполе MPL указывает максимальную продолжительность времени в секундах, в течение которого пакет может оставаться в объединенной сети.
Тип пакета. 8-битовое поле, которое указывает формат поля данных.
Номер сети получателя. 32-битовое поле, которое однозначно определяет сеть получателя в объединенной сети.
Номер хоста получателя. 48-битовое поле, которое однозначно определяет хост получателя.
Номер сокета получателя. 16-битовое поле, которое однозначно определяет сокет (процесс) в хосте получателя.
Номер сети отправителя. 32-битовое поле, которое однозначно определяет сеть отправителя в объединенной сети.
Номер хоста отправителя. 48-битовое поле, которое однозначно определяет хост отправителя.
Номер сокета отправителя. 16-битовое поле, которое однозначно определяет сокет (процесс) в хосте отправителя.
Адреса IEEE 802 эквивалентны номерам хостов, поэтому хост, подключенный к нескольким сетям IEEE 802, имеет один и тот же адрес в каждом сегменте. Поэтому информация о номерах сетей становится избыточной, но она продолжает использоваться, поскольку позволяет упростить маршрутизацию. Некоторые номера сокетов являются общепринятыми, а это означает, что информация о службе, доступ к которой предоставляется программным обеспечением, может оставаться постоянно заданной в составе конфигурации. Все прочие номера сокетов присваиваются динамически.
Протоколы XNS поддерживают инкапсуляцию Ethernet версии 2.0 для сети Ethernet и три типа инкапсуляции для сети Token Ring: ЗСот, SNAP и Ungermann-Bass.
В сети XNS могут передаваться одноадресатные (доставляемые непосредственно от отправителя к получателю), многоадресатные и широковещательные пакеты с адресами соответствующего типа. Многоадресатные и широковещательные адреса дополнительно подразделяются на адреса направленного и глобального типов. При направленной многоадресатной рассылке пакеты доставляются членам многоадресатной группы в сети, указанной в многоадресатном сетевом адресе получателя. При направленной широковещательной рассылке пакеты доставляются на все хосты указанной сети. Глобальная многоадресатная рассылка предусматривает доставку пакетов всем членам определенной группы в пределах всей объединенной сети, а глобальная широковещательная рассылка предусматривает доставку пакетов на все хосты объединенной сети. Для проведения различия между одноадресатным и многоадресатным адресом служит один бит в номере хоста. Широковещательный адрес обозначается всеми единицами в поле адреса хоста.
Для маршрутизации пакетов в объединенной сети в протоколах XNS с самого начала применялся протокол динамической маршрутизации RIP. Протокол RIP все еще используется, но теперь более широкое распространение находят более масштабируемые протоколы, такие как OSPF (Open Shortest Path First — открытый протокол SPF) и BGP (Border Gateway Protocol — протокол граничного шлюза).
Транспортный уровень
Функции транспортного уровня OSI реализованы с помощью нескольких протоколов. Ниже перечислены протоколы, которые определены в спецификации XNS как протоколы уровня 2.
Протокол SPP обеспечивает надежную передачу пакетов от одного клиентского процесса к другому с установлением логического соединения и управлением потоком данных. Он аналогичен по своему назначению протоколу TCP набора протоколов TCP/IP и протоколу ТР4 (Transport Protocol 4 — транспортный протокол класса 4) набора протоколов OSI.
Каждый пакет SPP включает порядковый номер, который применяется для упорядочения пакетов и определения того, не произошло ли дублирование или потеря одного из пакетов. Кроме того, пакеты SPP содержат два 16-битовых идентификатора соединения. Эти идентификаторы представляют собой два уникальных числа, назначенных данному соединению каждым из его участников. Два идентификатора соединения, вместе взятые, однозначно определяют логическое соединение между клиентскими процессами.
Пакеты SPP не могут превышать по длине 576 байтов. Клиентские процессы могут совместно принять решение об использовании другого размера пакета во время установления соединения, но в спецификации протокола SPP не определено, каким должен быть процесс подобного согласования.
Протокол PEP (Packet Exchange Protocol — протокол пакетного обмена) представляет собой запрос-ответный протокол, предназначенный для обеспечения более высокой надежности по сравнению с простой дейтаграммной службой (которая предоставляется, например, протоколом IDP); тем не менее, этот протокол характеризуется меньшей надежностью по сравнению с протоколом SPP. По своему назначению протокол РЕР аналогичен протоколу UDP набора протоколов TCP/IP. Протокол РЕР действует по принципу передачи отдельных пакетов, обеспечивает повторную передачу, но не предусматривает обнаружение дубликатов пакетов. Как таковой, этот протокол может применяться в таких приложениях, где запрос-ответные транзакции могут выполняться повторно без искажения данных, или в тех случаях, когда надежная передача обеспечивается на другом уровне.
Протокол ЕР (Error Protocol — протокол обработки ошибок) может применяться в любом клиентском процессе для передачи другому клиентскому процессу извещения о том, что в сети возникла ошибка. Этот протокол применяется, например, в таких ситуациях, когда программное обеспечение протокола SPP обнаруживает дубликат пакета.
Протоколы верхнего уровня
Набор протоколов XNS включает несколько протоколов верхнего уровня. В частности, Printing Protocol предоставляет доступ к службам печати, Filing Protocol обеспечивает поддержку служб доступа к файлам, a Clearinghouse Protocol реализует службу имен. Каждый из этих трех протоколов опирается на Courier Protocol, который определяет средства структурирования данных и межпроцессного взаимодействия.
В наборе протоколов XNS определены также протоколы уровня 4. Это — прикладные протоколы, но поскольку они практически не участвуют в выполнении функций обмена данными, в спецификации XNS им не дано какого-либо содержательного определения.
Echo Protocol уровня 2 используется для проверки достижимости узлов сети XNS и поддержки функций, предоставляемых командой ping в UNIX и других операционных системах.
Устранение нарушений в работе сети XNS
В настоящем разделе представлены сведения, позволяющие устранять нарушения в работе, характеризующиеся отсутствием связи в сети XNS, которые зависят от правильного функционирования программного обеспечения протокола. Здесь описаны конкретные признаки неисправности в сети XNS, перечислены проблемы, которые могут вызвать появление каждого признака неисправности, и приведены решения этих проблем.
В перечисленных ниже разделах рассматриваются наиболее распространенные нарушения в работе сети XNS.
XNS: клиенты не могут подключиться к серверам через маршрутизатор.
XNS: широковещательные пакеты XNS не перенаправляются маршрутизатором.
XNS: клиент не может подключиться к серверу через сеть с коммутацией пакетов.
XNS: клиенты не могут подключиться к серверам через маршрутизатор
Признак неисправности. Клиенты не могут подключиться к серверам XNS через маршрутизатор. Клиенты могут подключиться к серверам в сети, с которой они непосредственно соединены.
В табл. 14.1 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
1 * .
[Таблица 14.1.
XNS: клиенты не могут подключиться к серверам через
маршрутизатор‘.
Проблеме
Решение
Интерфейс маршрутизатора остановлен
Шаг 1. Вызовите на выполнение exec-команду show interfaces в маршрутизаторе для проверки состояния интерфейсов маршрутизатора.
Шаг 2. Если строка состояния указывает, что интерфейс, который должен находиться в рабочем состоянии, остановлен администратором ("administratively down"), вызовите на выполнение в интерфейсе команду конфигурации интерфейса no shutdown.
Шаг 3. Если строка состояния указывает, что интерфейс или протокол линии связи находится в каком-либо ином состоянии, обратитесь к главе с описанием применяемого типа передаюшей среды
Нарушение в работе аппаратных средств или передающей среды
Дополнительная информация об устранении нарушений в работе аппаратных средств приведена в главе 3. Для получения дополнительной информации об устранении нарушений в работе различных вариантов передающей среды обратитесь к главе данной книги, где рассматривается соответствующий вариант передающей среды
В маршрутизаторе не разрешено применение маршрутизации XNS
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Проверьте, разрешено ли применение маршрутизации XNS в маршрутизаторе.
Шаг 2. Если применение маршрутизации XNS не разрешено, введите по мере необходимости команду конфигурации маршрутизатора xns routing и другие соответствующие команды.
Пример
В следующем примере показано, как осуществляется запуск маршрутизации XNS и присваивание номеров XNS физическим сетям, подключенным к двум интерфейсам Ethernet маршрутизатора: xns routing interface ethernet 0 xns network 20 interface ethernet 1 xns network 21
Дополнительная информация о настройке маршрутизации XNS приведена в документе Network Protocols Configuration Guide, Part 2
Проблема
Решение
Номер сети в маршрутизаторе не соответствует действительности
Если номер сети, указанный в маршрутизаторе, отличается от номера, заданного в конфигурации серверов XNS, программное обеспечение RIP не способно перенаправлять трафик должным образом.
Шаг 1. Проверьте номера сетей в сетевых серверах. Номер сети сервера назначает администратор локального сервера XNS.
Шаг 2. Воспользуйтесь exec-командой show xns interface для определения номера сети, заданного в том интерфейсе маршрутизатора, который подключен к сети сервера.
Шаг 3. Сравните номера сетей. Если они не совпадают, внесите изменения в конфигурацию маршрутизатора или сервера (там, где это наиболее целесообразно), введя правильный номер сети. Для корректировки конфигурации маршрутизатора применяется следующая команда: xns network number
Параметр number представляет собой номер сети в десятичном формате. Каждый интерфейс XNS в системе должен иметь уникальный номер сети XNS.
Пример
В следующем примере показано, как осуществляется запуск маршрутизации XNS и присваивание номеров сетей XNS физическим сетям, подключенным к двум интерфейсам Ethernet маршрутизатора: xns routing interface ethernet 0 xns network 20 interface ethernet 1 xns network 21
Шаг 4. Если номера сетей совпадают, проверьте интерфейс маршрутизатора со стороны клиента и убедитесь в том, что назначенный номер сети является уникальным по отношению ко всем номерам сетей в объединенной сети XNS
Неправильно настроен список доступа
Шаг 1. Вызовите на выполнение привилегированную exec-команду show xns access-lists во всех маршрутизаторах в пути от отправителя к получателю. Эта команда показывает, входят ли в состав конфигурации маршрутизатора какие-либо списки доступа.
Шаг 2. Отмените применение в маршрутизаторе всех списков доступа, входящих в состав его конфигурации, с помощью команды no xns access-group.
Шаг 3. Попытайтесь установить соединение от клиента к серверу, чтобы определить, появилась ли возможность устанавливать соединения. Если соединение установлено успешно, это означает, что трафик блокируется под действием списка доступа.
Шаг 4. Чтобы определить список доступа, содержащий ошибку, последовательно вводите в конфигурацию по одному оператору access-list до тех пор, пока не исчезнет возможность создавать соединения.
Проблема
Решение
Шаг 5. После обнаружения ошибочного списка доступа внесите в него такие изменения, чтобы он не препятствовал прохождению всего необходимого трафика. Введите в конфигурацию явно заданные операторы permit для трафика, который должен перенаправляться маршрутизатором обычным образом.
Шаг 6. Если нарушение в работе не устранено, продолжайте отыскивать, анализировать и исправлять неправильные списки доступа во всех маршрутизаторах на пути от отправителя к получателю
Существует не предусмотренный проектом мост между сегментами
Шаг 1. Вызовите на выполнение exec-команду show xns traffic, чтобы определить, увеличивается ли значение в поле bad hop count. По умолчанию в сети XNS обновление значений статистических данных происходит через каждые 30 секунд:
C4000#show xns traffic
Rec: 3968 total, 0 format errors, 0 checksum errors, 0 bad hop count,
3968 local destination, 0 multicast
[...]
Шаг 2. Если показания счетчика bad hop count увеличиваются, воспользуйтесь сетевым анализатором для поиска в рассматриваемых сегментах периодически повторяющихся пакетов. Выполняйте также поиск пакетов обновлений маршрутизации. Если между сегментами установлен мост, не предусмотренный проектом, то могут быть обнаружены пакеты со значением числа участков маршрута, возросшим до 15; в данный момент маршруты для этих пакетов исчезают, а затем вновь появляются непредсказуемым образом.
Шаг 3. Изучите трафик в каждом сегменте с помощью сетевого анализатора. Попытайтесь обнаружить появляющиеся в локальной сети пакеты, которые поступают из удаленных сетей с известными сетевыми номерами. В частности, ищите пакеты, имеющие в качестве исходного адрес удаленного узла вместо адреса маршрутизатора.
Мост, не предусмотренный проектом, находится в том сегменте, в котором появляются пакеты с исходным адресом, отличным от адреса локального маршрутизатора. Чтобы предотвратить введение в таблицу маршрутизации обновлений маршрутизации XNS, поступающих из интерфейса, подключенного к сегменту, где находится мост, не предусмотренный проектом, можно применить команду xns input-network-filter.
Пример
В следующем примере список доступа 476 управляет тем, какие сети добавляются к таблице маршрутизации при получении пакетов RIP через интерфейс Ethernet 1. В таблицу маршрутизации будет вводиться информация только о сети 16. Обновления маршрутизации для всех других сетей неявно запрещены и не вводятся в таблицу маршрутизации: access-list 476 permit 16 interface ethernet 1 xns input-network-filter 476
XNS: широковещательные пакеты XNS не перенаправляются маршрутизатором
Признак неисправности. Серверы XNS не отвечают на запросы клиентов по выполнению широковещательной рассылки.
В табл. 14.2 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
I Таблица 14.2. XNS: широковещательные пакеты XNS ',
| ч не перенаправляются маршрутизатором
Проблема
Решение
В конфигурации отсутствует или неправильно задана команда xns helper-address
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 1. Разрешите применение привилегированной exec-команды debug xns packet и проверьте, имеется ли в ее выводе информация о пакетах XNS с неизвестной спецификацией типа хх.
Шаг 2. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Проверьте конфигурацию клиентского интерфейса, чтобы определить, имеется ли запись команды конфигурации интерфейса xns helper-address.
Шаг 3. Если команда xns helper-address отсутствует, введите ее в конфигурацию клиентского интерфейса.
Синтаксис
xns helper-address network.host
Описание синтаксиса
network. Сеть, в которой находится целевой сервер XNS. Этот параметр задается как 32-битовое значение, представленное в виде десятичного числа.
host. Номер хоста целевого сервера XNS. Этот параметр должен быть задан как 48-битовое шестнадцатеричное значение, представленное в виде трех четырехразрядных шестнадцатеричных чисел, разделенных точками (хххх.хххх.хххх). Хост должен быть подключен к одной из сетей, к которой непосредственно подключен данный маршрутизатор. Номер FFFF.FFFF.FFFF обозначает все хосты в указанной сети.
Проблема
Решение
Отсутствует ко-
Пример
В следующем примере сервер, находящийся по адресу OOOO.OcOO.23fe, получает все широковещательные пакеты, проходящие по сети 51: xns helper-address 51.0000.0c00.23fe
Шаг 4. Если указанная выше команда входит в состав конфигурации, убедитесь в том, что МАС-адрес, заданный в этой команде, относится к типу широковещательного.
Ниже приведен пример широковещательной рассылки по всем сетям.
interface ethernet 0
xns helper-address -l.ffff.ffff.ffff
Спецификация вспомогательного адреса helper-address зависит от конфигурации сети. Дополнительная информация приведена в документах Cisco IOS Network Protocols Configuration Guide, Part 2 и Network Protocols Command Reference, Part 2
Предостережение. Поскольку процессы формирования отладочного вывода
манда конфигу-
имеют высокий приоритет среди процессов, использующих ресурсы про-
рации маршру-
цессора, то применение команды debug может привести к нарушению ра-
тизатора xns
боты системы. По этой причине команды debug предназначены только для
forward-protocol
диагностирования конкретных проблем или для проведения сеансов поис-
Неправильно
ка неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 1. Разрешите применение привилегированной exec-команды debug xns packet и проверьте, имеется ли в ее выводе информация о пакетах XNS с неизвестной спецификацией типа хх.
Шаг 2. Воспользуйтесь exec-командой show running-config privileged для просмотра информации о конфигурации маршрутизатора. Найдите запись глобальной команды конфигурации xns forward-protocol.
Шаг 3. Если команда xns forward-protocol отсутствует, введите ее соответствующим образом.
Синтаксис
xns forward-protocol protocol
Описание синтаксиса
• protocol. Номер протокола XNS в виде десятичного числа. Для ознакомления со списком номеров протокола обратитесь к документации, которая входит в поставку программного обеспечения XNS для конкретного хоста
Шаг 1. Вызовите на выполнение привилегированную exec-команду show
настроен список
access-lists, чтобы проверить, входят ли в состав конфигурации
доступа
маршрутизатора какие-либо списки доступа.
Проблема
Решение
Шаг 2. Отмените применение в маршрутизаторе всех списков доступа, входящих в состав его конфигурации.
Шаг 3. Попытайтесь установить соединение, чтобы определить, появилась ли возможность устанавливать соединения. Если соединение установлено успешно, это означает, что трафик блокируется под действием списка доступа.
Шаг 4. Последовательно вводите в конфигурацию по одному оператору access-list до тех пор, пока не исчезнет возможность создавать соединения.
Шаг 5. Внесите в список доступа, содержащий ошибки, такие изменения, чтобы он не препятствовал прохождению трафика. Введите в конфигурацию явно заданные операторы permit для трафика, который должен перенаправляться маршрутизатором обычным образом.
Шаг 6. Если нарушение в работе не устранено, продолжайте отыскивать, анализировать и исправлять неправильные списки доступа во всех маршрутизаторах на пути от отправителя к получателю
XNS: клиент не может подключиться к серверу через сеть с коммутацией пакетов
Признак неисправности. Клиенты не могут подключиться к серверам через сеть с коммутацией пакетов. Клиенты могут подключиться к серверам, расположенным в локальной сети.
В табл. 14.3 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
Таблица 14.3. XNS: клиент не может подключиться к серверу через сеть ; { . >. с коммутацией пакетов :|
Проблема
Решение
Ошибка преобразования адресов
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора.
Шаг 2. Если в сети применяется протокол Х.25, убедитесь в том, что команды конфигурации интерфейса х25 map xns введены в состав конфигурации должным образом. Проверьте, правильно ли указаны МАС-адреса и адреса Х.121.
Шаг 3. Если в сети применяется протокол Frame Relay, убедитесь в том, что команды конфигурации интерфейса frame-relay map xns введены в состав конфигурации должным образом. Проверьте, правильно ли указаны МАС-адреса и идентификаторы DLCI
Номер сети в маршрутизаторе не соответствует действительности
Шаг 1. Проверьте номера сетей в сетевых серверах. Эта информация может быть предоставлена администраторами локального сервера XNS.
Шаг 2. Определите номер сети, заданный в том интерфейсе маршрутизатора, который подключен к сети сервера.
Проблема
Решение
Шаг 3. Сравните номера сетей. Если они не совпадают, внесите изменения в конфигурацию маршрутизатора или сервера (там, где это наиболее целесообразно), введя правильный номер сети.
Шаг 4. Если номера сетей совпадают, проверьте интерфейс маршрутизатора со стороны клиента и убедитесь в том, что назначенный номер сети является уникальным по отношению ко всем номерам сетей в объединенной сети XNS
Несоответствие типов инкапсуляции
Шаг 1. Воспользуйтесь exec-командой show interfaces, чтобы определить применяемый тип инкапсуляции (например, encapsulation х25).
Шаг 2. Если команда encapsulation не входит в состав конфигурации, по умолчанию применяется инкапсуляция HDLC. Для обеспечения взаимодействия хостов через сеть с коммутацией пакетов необходимо явно указать тип инкапсуляции. Чтобы установить метод инкапсуляции, используемый в интерфейсе, вызовите на выполнение команду конфигурации интерфейса encapsulation.
Синтаксис
encapsulation encapsulation-type
Описание синтаксиса
encapsulation-type. Одно из следующих ключевых слов.
atm-dxi. Инкапсуляция ATM-DXI (Asynchronous Transfer Mode-Data Exchange Interface — режим асинхронной передачи — интерфейс обмена данными).
bstun. Инкапсуляция BSTUN (Block Serial Tunnel — блочный последовательный туннель).
frame-relay. Инкапсуляция Frame Relay (для последовательного интерфейса).
hdlc. Протокол HDLC для последовательного интерфейса. Этот метод инкапсуляции обеспечивает синхронное выполнение функций фреймирования и обнаружения ошибок HDLC без применения окон или повторной передачи.
lapb. Работа в режиме LAPB DTE Х.25 (для последовательного интерфейса).
ррр. Протокол РРР (дтя последовательного интерфейса).
sdlc. Режим обмена данными через последовательный интерфейс в архитектуре SNA корпорации IBM.
sdlc-primary. Режим обмена данными через последовательный интерфейс в архитектуре SNA IBM (для первичного последовательного интерфейса).
sdlc-secondary. Режим обмена данными через последовательный интерфейс в архитектуре SNA IBM (для вторичного последовательного интерфейса).
smds. SMDS (для последовательного интерфейса)
Часть
IV
^Устранение нарушений t в работе последовательных каналов и соединений распределенной сети
J
B этой части...
& Глава 15. “Устранение нарушений в работе последовательных каналов”
”* Глава 16. “Устранение нарушений в работе коммутируемых соединений” Глава 17. “Устранение нарушений в работе соединений ISDN” Глава 18. “Устранение нарушений в работе соединений Frame Relay” Глава 19- “Устранение нарушений в работе соединений Х.25”
Глава
15
Устранение нарушений < в работе последовательных каналов
^. В настоящей главе представлена общая информация по поиску неисправностей, а так- Ь же описаны инструментальные средства и методы, применяемые при устранении наруше- ’V ний в работе последовательных соединений. Глава состоит из следующих разделов.
Устранение нарушений в работе с помощью команды show interfaces serial.
'• Применение команды show controllers.
^(.• Применение команд debug.
? • Проведение проверок с использованием расширенной команды ping.
Устранение нарушений в работе средств синхронизации.
Корректировка размеров буферов.
Специальные методы проверки последовательного канала.
Подробные сведения о команде show interfaces serial.
Им •• Устранение нарушений в работе каналов Т1.
;, Устранение нарушений в работе каналов Е1.
Устранение нарушений в работе с использованием команды show interfaces serial
^ В результатах выполнения exec-команды show interfaces serial отображается информация о конкретных последовательных интерфейсах. На рис. 15.1 показан вывод exec-команды show interfaces serial для последовательного интерфейса HDLC.
: . В настоящем разделе приведены рекомендации по использованию команды show •interfaces serial для диагностирования нарушений связи по последовательным кана- ^ , лам в среде распределенной сети. В следующих разделах описаны некоторые важные ,- поля, которые присутствуют в выводе этой команды.
Остальные поля, показанные в выводе команды, подробно описаны в разделе “Подробные сведения о команде show interfaces serial”, приведенном ниже в этой главе.
Последовательные каналы: сообщения в строке состояния show interfaces serial
В строке состояния интерфейса, присутствующей в выводе команды show interfaces serial, можно встретить пять возможных сообщений о нарушениях в работе последовательного канала (рис. 15.1).
Serial х is down, line protocol is down (последовательный канал x не функционирует, протокол канала передачи данных не функционирует).
Serial х is up, line protocol is down (последовательный канал x функционирует, протокол канала передачи данных не функционирует).
Serial х is up, line protocol is up (looped) (последовательный канал x функционирует, протокол канала передачи данных функционирует, но переведен в режим использования петли обратной связи).
Serial х is up, line protocol is down (disabled) (последовательный канал x функционирует, протокол канала передачи данных не функционирует, поскольку отменено его применение).
Serial х is administratively down, line protocol is down (последовательный канал x переведен в нерабочее состояние администратором, протокол канала передачи данных не функционирует).
Следующее сообщение присутствует в строке состояния при нормальных условиях:
monet>show Interfaces serial 0| Serial 0 is up, line protocol is up |— Строка СОСТОЯНИЯ интерфейсаmonet>show Interfaces serial 0| Serial 0 is up, line protocol is up |— Строка СОСТОЯНИЯ интерфейсаHardware is MCI SerialInternet address is 131.108.156.98, subnet mask is 255.255.255.240Hardware is MCI SerialInternet address is 131.108.156.98, subnet mask is 255.255.255.240Количество-MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, rely 255/255, load 1/255 уничтоженных ErT&eftsulation HDLC, loopback not set, keepalive set (10 sec)Количество-MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, rely 255/255, load 1/255 уничтоженных ErT&eftsulation HDLC, loopback not set, keepalive set (10 sec)ВЫХОДНЫХ пакетовВЫХОДНЫХ пакетовLast inptfe-^Q:00:00 , output 0 : 00:00, output hang neverLast inptfe-^Q:00:00 , output 0 : 00:00, output hang neverLast clearingLast clearingshow interface" counters nevershow interface" counters neverКоличество. ошибок CRCКоличество. ошибок CRCOutput queue 0/40,[5762 drops) input queue 0/75, [з01 drops Five minute input rate 9000 bits/sec, 16 packets/sec .Output queue 0/40,[5762 drops) input queue 0/75, [з01 drops Five minute input rate 9000 bits/sec, 16 packets/sec .Количество уничтоженных входных пакетовКоличество уничтоженных входных пакетов.^nute output rate 9000 bits/sec, 17 packets/sec.^nute output rate 9000 bits/sec, 17 packets/sec578080578080:ets input,785841604 bytes, 0 no buffer:ets input,785841604 bytes, 0 no bufferReceived 757 brReceived 757 br.Sts, 0 runts, 0 giants.Sts, 0 runts, 0 giantsКоличество ошибок, вызывающих аварийное прекращение работыКоличество ошибок, вызывающих аварийное прекращение работы146124 input errors^ |87243 CRC^ ]d8B57 frame^ 0 overrun, 0146124 input errors^ |87243 CRC^ ]d8B57 frame^ 0 overrun, 0Количество ошибок во входных пакетахКоличество ошибок во входных пакетах5298821 packets output, 76566^98 bytes, 0 underruns0 output errors, 0 collision's, ,2941 interface resetsi 0 restarts .:—:1//r2 carrier transitions ✓/5298821 packets output, 76566^98 bytes, 0 underruns0 output errors, 0 collision's, ,2941 interface resetsi 0 restarts .:—:1//r2 carrier transitions ✓/ignored, [ 3 abort"]ignored, [ 3 abort"]Количество ошибок Количество сбросовКоличество ошибок Количество сбросовКоличество переходов фреймирования интерфейса на другую несущуюРис. 15.1. Вывод команды show interface serial с информацией о канале HDLCКоличество переходов фреймирования интерфейса на другую несущуюРис. 15.1. Вывод команды show interface serial с информацией о канале HDLCSerial х is up, line protocol is up (последовательный канал x функционирует, протокол канала передачи данных функционирует).
monet>show Interfaces serial 0
| Serial 0 is up, line protocol is up |— Строка СОСТОЯНИЯ интерфейса
monet>show Interfaces serial 0
| Serial 0 is up, line protocol is up |— Строка СОСТОЯНИЯ интерфейса
Hardware is MCI Serial
Internet address is 131.108.156.98, subnet mask is 255.255.255.240
Hardware is MCI Serial
Internet address is 131.108.156.98, subnet mask is 255.255.255.240
Количество-MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, rely 255/255, load 1/255 уничтоженных ErT&eftsulation HDLC, loopback not set, keepalive set (10 sec)
Количество-MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, rely 255/255, load 1/255 уничтоженных ErT&eftsulation HDLC, loopback not set, keepalive set (10 sec)
ВЫХОДНЫХ пакетов
ВЫХОДНЫХ пакетов
Last inptfe-^Q:00:00 , output 0 : 00:00, output hang never
Last inptfe-^Q:00:00 , output 0 : 00:00, output hang never
Last clearing
Last clearing
show interface" counters never
show interface" counters never
Количество. ошибок CRC
Количество. ошибок CRC
Output queue 0/40,[5762 drops) input queue 0/75, [з01 drops Five minute input rate 9000 bits/sec, 16 packets/sec .
Output queue 0/40,[5762 drops) input queue 0/75, [з01 drops Five minute input rate 9000 bits/sec, 16 packets/sec .
Количество уничтоженных входных пакетов
Количество уничтоженных входных пакетов
.^nute output rate 9000 bits/sec, 17 packets/sec
.^nute output rate 9000 bits/sec, 17 packets/sec
578080
578080
:ets input,785841604 bytes, 0 no buffer
:ets input,785841604 bytes, 0 no buffer
Received 757 br
Received 757 br
.Sts, 0 runts, 0 giants
.Sts, 0 runts, 0 giants
Количество ошибок, вызывающих аварийное прекращение работы
Количество ошибок, вызывающих аварийное прекращение работы
146124 input errors^ |87243 CRC^ ]d8B57 frame^ 0 overrun, 0
146124 input errors^ |87243 CRC^ ]d8B57 frame^ 0 overrun, 0
Количество ошибок во входных пакетах
Количество ошибок во входных пакетах
5298821 packets output, 76566^98 bytes, 0 underruns
0 output errors, 0 collision's, ,2941 interface resetsi 0 restarts
.:—:1//r
2 carrier transitions ✓/
5298821 packets output, 76566^98 bytes, 0 underruns
0 output errors, 0 collision's, ,2941 interface resetsi 0 restarts
.:—:1//r
2 carrier transitions ✓/
ignored, [ 3 abort"]
ignored, [ 3 abort"]
Количество ошибок Количество сбросов
Количество ошибок Количество сбросов
Количество переходов фреймирования интерфейса на другую несущую
Рис. 15.1. Вывод команды show interface serial с информацией о канале HDLC
Количество переходов фреймирования интерфейса на другую несущую
Рис. 15.1. Вывод команды show interface serial с информацией о канале HDLC
В табл. 15.1 показаны сообщения о состоянии интерфейса, перечислены проблемы, связанные с конкретными сообщениями, и приведены решения этих проблем.
«Таблица 15.1. Последовательные каналы: сообщения в строке состояния .
■ show interfaces serial * «Н'-'<••
4tti*^&J>LU^4&5U-^.--~A-x-*^aJ>=l^&U-sLLb-1i^A-Lti^a&^^
Сообщение вСообщение вПроблемаПроблемаРешениеРешение
Сообщение в
Сообщение в
Проблема
Проблема
Решение
Решение
Serial х is up, line protocol is upSerial x is down, line protocol is down (режим DTE)Serial х is up, line protocol is upSerial x is down, line protocol is down (режим DTE)Маршрутизатор не принимает сигнал CD (иными словами, сигнал CD не передается). Нарушение в работе телефонной сети — канал не функционирует или не подключен к устройству CSU/DSU1. Кабельная разводка неисправна или неправильно выполнена. Произошел отказ аппаратных средств (устройства CSU/DSU)Маршрутизатор не принимает сигнал CD (иными словами, сигнал CD не передается). Нарушение в работе телефонной сети — канал не функционирует или не подключен к устройству CSU/DSU1. Кабельная разводка неисправна или неправильно выполнена. Произошел отказ аппаратных средств (устройства CSU/DSU)
Serial х is up, line protocol is up
Serial x is down, line protocol is down (режим DTE)
Serial х is up, line protocol is up
Serial x is down, line protocol is down (режим DTE)
Маршрутизатор не принимает сигнал CD (иными словами, сигнал CD не передается). Нарушение в работе телефонной сети — канал не функционирует или не подключен к устройству CSU/DSU1. Кабельная разводка неисправна или неправильно выполнена. Произошел отказ аппаратных средств (устройства CSU/DSU)
Маршрутизатор не принимает сигнал CD (иными словами, сигнал CD не передается). Нарушение в работе телефонной сети — канал не функционирует или не подключен к устройству CSU/DSU1. Кабельная разводка неисправна или неправильно выполнена. Произошел отказ аппаратных средств (устройства CSU/DSU)
строке состояния
Никакие действия не требуются
Шаг 1. Проверьте светодиоды на устройстве CSU/DSU, чтобы определить, активен ли сигнал CD, или подключите к устройству коммутационный бокс, чтобы проверить сигнал CD.
Шаг 2. Убедитесь в том, что применяется подходящий кабель и интерфейс (руководствуясь документацией по установке аппаратных средств).
Шаг 3. Подключите к устройству коммутационный бокс и проверьте сигналы на всех управляющих контактах.
Шаг 4. Обратитесь к представителям провайдера арендованного канала или другого оператора связи, чтобы определить, не произошло ли нарушение связи по их вине.
Шаг 5. Замените неисправные компоненты.
Шаг 6. Если есть основания полагать, что неисправны аппаратные средства маршрутизатора, переключите последовательный канал на другой порт. Если соединение перейдет в рабочее состояние, это означает, что нарушение связи произошло из-за неисправности интерфейса, к которому последовательный канал был подключен ранее
Сообщение в ПроблемаРешение
строке состояния
Serial х is up,
Локальный или удален
line protocol is
ный маршрутизатор не
down (режим DTE)
правильно настроен.
Удаленный маршрути
затор не передает пакеты поддержки.
Произошло нарушение в работе арендованного канала или другой службы оператора связи (зашумленный канал; неправильно настроен или неисправен коммутатор). В кабеле возникло на
рушение синхронизации (в устройстве CSU/DSU не установлен режим SCTE). Произошел отказ локального или удаленного устройства CSU/DSU.
Произошел отказ аппаратных средств маршрутизатора (локального или удаленного)
Шаг 1. Переведите модем, устройство CSU (Channel Service Unit — модуль обслуживания канала) или устройство DSU (Data Service Unit — модуль обработки данных) в режим локальной петли обратной связи и вызовите на выполнение команду show interfaces serial, чтобы определить, перешел ли протокол канала передачи данных в рабочее состояние.
Если протокол канала передачи данных перешел в рабочее состояние, то нарушение в работе, скорее всего, вызвано неисправностью телефонной сети или выходом из строя удаленного маршрутизатора.
Шаг 2. Если есть основания полагать, что нарушение в работе возникло в удаленном конце последовательного канала, повторите шаг I для проверки удаленного модема, модуля CSU или модуля DSU.
Шаг 3. Проверьте всю кабельную разводку. Убедитесь в том, что кабель подключен к соответствующему интерфейсу, устройству CSU/DSU и оконечному оборудованию телефонной сети. Вызовите на выполнение ехес-команду show controllers, чтобы определить, какой кабель подключен к тому или иному интерфейсу.
Шаг 4. Разрешите применение ехес-команды debug serial interface.
Предостережение. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы.
Сообщение в ПроблемаРешение
строке состояния
По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 5. Если протокол канала передачи данных не перешел в рабочее состояние в режиме локальной петли обратной связи, а вывод exec-команды debug serial interface показывает, что значение счетчика пакетов поддержки соединения не увеличивается, то может иметь место нарушение в работе. аппаратных средств маршрутизатора. Замените аппаратные средства интерфейса маршрутизатора.
Шаг 6. Если протокол канала передачи данных перешел в рабочее состояние и значение счетчика пакетов поддержки соединения увеличивается, то причиной нарушения в работе не является неисправность локального маршрутизатора. Проведите диагностику неисправностей последовательного канала, как описано ниже, в разделах “Устранение нарушений синхронизации” и “Рекомендации по проверке петлевого интерфейса CSU и DSU".
Шаг 7. Если есть основания полагать, что неисправны аппаратные средства маршрутизатора, переключите последовательный канал на другой порт. Если соединение перейдет в рабочее состояние, то нарушение связи произошло из-за неисправности интерфейса, к которому последовательный канал был подключен ранее
Сообщение в строке состояния
Проблема
Решение
Serial х is up, line protocol is down (режим DCE)
Отсутствует команда конфигурации интерфейса clockrate.
Устройство DTE не поддерживает режим SCTE (синхронизация терминала) или не настроено на работу в этом режиме.
Произошел отказ удаленного модуля CSU или модуля DSU
Шаг 1. Введите команду конфигурации интерфейса clockrate в последовательном интерфейсе.
Синтаксис
clock rate bps
Описание синтаксиса
• bps. Требуемая частота синхронизации в битах в секунду: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148000, 250000, 500000, 800000, 1000000, 1300000, 2000000, 4000000 или 8000000.
Шаг 2. Переведите устройство DTE в режим SCTE, если это возможно. Если же применяемое устройство CSU/DSU не поддерживает режим SCTE, то может потребоваться отменить поддержку SCTE в интерфейсе маршрутизатора Cisco. Обратитесь к разделу “Инвертирование синхроимпульсов передачи", приведенному ниже в этой главе.
Шаг 3. Убедитесь в том, что используется кабель соответствующего типа.
Шаг 4. Если протокол канала передачи данных все еще не функционирует, то причиной нарушения в работе может явиться отказ аппаратных средств или неисправность кабельной разводки. Подключите к устройству коммутационный бокс и проверьте состояние управляющих контактов.
Шаг 5. Замените неисправные компоненты, если в этом есть необходимость
Serial x is up, line protocol is up (looped)
В цепи имеется петля. При первоначальном обнаружении петли порядковый номер в пакете поддержки соединения заменяется случайным числом. Если из канала будет возвращен пакет с таким же случайным числом, это означает, что петля действительно имеется
Шаг 1. Воспользуйтесь привилегированной exec-командой show running-config, чтобы найти какие-либо записи команды конфигурации интерфейса loopback.
Шаг 2. Обнаружив запись команды конфигурации интерфейса loopback, воспользуйтесь командой конфигурации интерфейса no loopback для удаления петли.
Сообщение в строке состояния
Проблема
Решение
Serial х is up,
Обнаруживается высо-
Шаг 3. Если команда конфигурации интерфейса loopback не обнаружена, обследуйте устройства CSU и DSU в составе устройства CSU/DSU, чтобы определить, не переключены ли они в режим использования петли обратной связи вручную. Если это действительно так, отключите вручную петлевой интерфейс.
Шаг 4. Выполните сброс модуля CSU или DSU и проверьте состояние линии. Если протокол канала передачи данных перешел в рабочее состояние, то выполнять какие-либо иные действия не требуется.
Шаг 5. Если устройство CSU или DSU не переведено в режим использования петли обратной связи вручную, обратитесь к представителям провайдера арендованного канала или другого оператора связи, которые могут оказать помошь в устранении рассматриваемого нарушения в работе
Шаг 1. Проведите диагностику канала с по-
line protocol is
кое значение коэффи-
мошью анализатора последователь-
down (disabled)
циента ошибок из-за
ных каналов и коммутационного
Serial x is
нарушения в работе телефонной сети.
Возникла неисправность аппаратных средств модуля CSU или DSU.
Аппаратные средства маршрутизатора (интерфейса) работают со сбоями
Конфигурация маршру-
бокса. Найдите сигналы CTS (Clear То Send — готовность к приему) и DSR (Data-Set Ready — готовность устройства), которые периодически переходят то в активное, то в неактивное состояние.
Шаг 2. Установите петлю обратной связи на устройстве CSU/DSU (петлю DTE). Если это не позволяет устранить неисправность, то нарушение в работе может быть связано с отказом аппаратных средств.
Шаг 3. В случае необходимости замените неисправные аппаратные средства (CSU, DSU, коммутатор, локальный или удаленный маршрутизатор)
Шаг 1. Проверьте, имеется ли в конфигура-
administratively
тизатора включает ко-
ции маршрутизатора команда
down, line protocol
манду конфигурации
shutdown.
is down
интерфейса shutdown.
РешениеРешениеСообщение в Проблема строке состояния
Решение
Решение
Имеется повторяющий- щ^ 2. Вызовите на выполнение команду ся IP-адресконфигурации интерфейса no shutdown,
чтобы удалить команду shutdown.
Шаг 3. С помощью привилегированной ехес- команды show running-config или схес- команды show interfaces проверьте, имеются ли в сети одинаковые IP- адреса.
Шаг 4. Если имеются повторяющиеся адреса, устраните конфликт адресов, изменив один из IP-адресов
Последовательные каналы: увеличение количества уничтоженных выходных пакетов в последовательном канале
Значение в поле количества уничтоженных выходных пакетов в выводе команды show interfaces serial (рис. 15.1) увеличивается, если в системе предпринимается попытка отправить пакет в буфер передачи, но свободные буфера отсутствуют.
Признак неисправности. Увеличение количества уничтоженных выходных пакетов в последовательном канале.
В табл. 15.2 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Таблица 15.2. Последовательные каналы: увеличение количества>
. ..■ уничтоженных выходных пакетов в последовательном канале j
Проблема
Решение
Объем выходного трафика через последовательный интерфейс превышает доступную пропускную способность последовательного канала
Шаг 1. Сведите к минимуму объем периодически возрастающего широковещательного трафика, такого как обновление маршрутизации и SAP, с использованием списков доступа или других средств. Например, чтобы увеличить интервал между обновлениями SAP, воспользуйтесь командой конфигурации интерфейса ipx sap-interval.
Шаг 2. Постепенно увеличивайте размер выходной очереди (например, каждый раз на 25%) с помощью команды конфигурации интерфейса hold-queue out.
Шаг 3. В тех интерфейсах, в которых наблюдается рассматриваемое нарушение в работе, отключите быструю коммутацию для интенсивно используемых протоколов. Например, чтобы отключить быструю коммутацию IP, введите команду конфигурации интерфейса no ip routecache. Для ознакомления с синтаксической структурой команд для других протоколов обратитесь к руководствам по настройке конфигурации и справочникам команд Cisco 1OS.
ПроблемаРешение
Шаг 4. Введите организацию очереди по приоритетам для более медленных последовательных каналов, предусмотрев в конфигурации списки приоритетов. Для ознакомления с дополнительной информацией о настройке конфигурации списков приоритетов обратитесь к руководствам по настройке конфигурации и справочникам команд Cisco IOS.
Примечание. Уничтожение выходных пакетов в последовательном канале при определенных условиях является вполне приемлемым. Например, если известно, что канал перегружен (и нет возможности исправить эту ситуацию), то часто рекомендуется уничтожать пакеты, а не пытаться их хранить. Эта рекомендация относится к протоколам, которые обеспечивают управление потоком данных и позволяют передавать данные повторно (т.е. к таким протоколам, как TCP/IP и Novell IPX). Но некоторые протоколы, такие как DECnet и транспортные протоколы локальной сети, восприимчивы к уничтожению пакетов и плохо приспособлены для повторной передачи (или вообше не приспособлены)
Последовательные каналы: увеличение количества уничтоженных входных пакетов в последовательном канале
В поле количества уничтоженных входных пакетов в выводе команды show interfaces serial (см. рис. 15.1) появляется ненулевое значение, если из интерфейса продолжают поступать пакеты, а в системе еше остается слишком много необработанных пакетов.
Признак неисправности. Увеличение количества уничтоженных входных пакетов в последовательном канале.
В табл. 15.3 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Последовательные каналы: количество ошибок во входных пакетах превышает примерно 1% от общего объема трафика через интерфейс
Если количество ошибок во входных пакетах в выводе команды show interfaces serial (см. рис. 15.1) не равно нулю, то необходимо рассмотреть несколько возможных причин таких ошибок. Наиболее вероятные причины перечислены в табл. 15.4.
Примечание
Если количество ошибок во входных пакетах, к которым относятся ошибки CRC, ошибки фреймирования или сообщения об аварийном завершении работы, составляют примерно 1% от общего объема трафика через интерфейс, это означает, что в работе канала возникло нарушение, которое необходимо выявить и устранить.
Признак неисправности. Количество ошибок во входных пакетах превышает примерно 1% от обшего объема трафика через интерфейс.
I Таблица 15.3. Последовательные каналы: увеличениеколичества « /к [>^-^7$^.уничтохФ^ входных пакетов в последовательном-канал!^
ПроблемаРешение
Объем входного трафика превышает пропускную способность маршрутизатора или входные очереди превышают по размерам выходные очередиОбъем входного трафика превышает пропускную способность маршрутизатора или входные очереди превышают по размерам выходные очередиПримечание. Нарушения в работе, характеризующиеся уничтожением входных пакетов, обычно наблюдаются при перенаправлении трафика от быстрых сетевых интерфейсов (таких как Ethernet, Token Ring и FDDI) к более медленным последовательным интерфейсам. При низкой интенсивности трафика нарушения в работе не возникают. Но по мере увеличения интенсивности трафика начинается поиск резервных маршрутов, характеризующийся появлением заторов. В периоды существования таких заторов маршрутизаторы уничтожают пакеты.
Объем входного трафика превышает пропускную способность маршрутизатора или входные очереди превышают по размерам выходные очереди
Объем входного трафика превышает пропускную способность маршрутизатора или входные очереди превышают по размерам выходные очереди
Шаг 1. Увеличьте размер выходной очереди во всех интерфейсах общего назначения, где происходит уничтожение пакетов. Для этого применяется команда конфигурации интерфейса hold-queue number out. Последовательно увеличивайте эти очереди на небольшую величину (например, каждый раз на 25%) до тех пор, пока в выводе команды show interfaces больше не будут обнаруживаться уничтоженные пакеты. По умолчанию предельный размер выходной очереди составляет 100 пакетов.
Шаг 2. Уменьшите размер входной очереди с помощью команды конфигурации интерфейса hold-queue number in, чтобы вызвать увеличение количества уничтоженных выходных пакетов вместо входных пакетов. Уничтожение выходных пакетов в меньшей степени влияет на производительность маршрутизатора, чем уничтожение входных пакетов. По умолчанию размер входной очереди составляет 75 пакетов
i Таблица 15.4. Последовательные каналы: количество ошибок во входных . пакетах превышает примерно 1% от общего объема трафика -.^ 7 х - через ийтерфейс,Л >'>7. . 7^;
ПроблемаРешение
Этот признак неисправности может возникнуть в результате перечисленных ниже нарушений в работе.
Неисправное оборудование телефонной сети.
Зашумленный последовательный канал.
Неправильная конфигурация средств синхронизации (не установлен режим SCTE).
Кабель неподходящего типа или слишком длинный кабель.
Неисправность кабеля или соединения.
Неисправность модуля CSU или DSU.
Примечание. Корпорация Cisco настоятельно рекомендует не использовать конвертер данных при подключении маршрутизатора к распределенной сети или к сети последовательных каналов.
Шаг 1. Воспользуйтесь анализатором последовательных каналов для поиска причин появления ошибок во входных пакетах. С наибольшей вероятностью обнаруженные ошибки могут быть обусловлены нарушениями в работе аппаратных средств или несогласованностью синхронизации в устройстве, внешнем по отношению к маршрутизатору.
Проблема
Решение
Неисправность аппаратных средств маршрутизатора.
Между маршрутизатором и модулем DSU включен конвертер данных или другое устройство
Шаг 2. Выполните проверки с помощью петли обратной связи и эхо-тестирования, чтобы найти конкретную причину неисправности. Дополнительная информация приведена ниже, в разделах “Методы проверки с применением расширенной команды эхо-тестирования" и “Рекомендации по проверке петлевого интерфейса CSU и DSU".
Шаг 3. Попытайтесь выявить закономерности. Например, если ошибки возникают через определенный интервал, то они могут быть обусловлены периодическим выполнением некоторой функции, такой как передача обновлений маршрутизации
Последовательные каналы:
устранение ошибок ввода
в последовательном канале
В табл. 15.5 описаны различные типы ошибок ввода, отображаемых в результатах выполнения команды show interfaces serial (см. рис. 15.1), а также возможные проблемы, которые могут вызвать появление этих ошибок, и решения этих проблем.
Таблица 15.5. Последовательные каналы: устранение ошибок ввода ^#-У - в последовательном канале • .-й-.йй .
РешениеРешениеТипошибки Проблема ввода (имя поля в выводе команде)
Решение
Решение
Ошибки CRC (CRC)Ошибки CRC (CRC)
Ошибки CRC (CRC)
Ошибки CRC (CRC)
Ошибки CRC возникают при несовпадении результатов вычисления циклического избыточного кода (что свидетельствует об искажении данных) по одной из следующих причин.
Последовательный канал является зашумленным.
Последовательный кабель имеет слишком большую длину или кабель от устройства CSU/DSU к маршрутизатору не экранирован.
В устройстве DSU не разрешено применение режима SCTE.
Настройка конфигурации синхронизации канала CSU выполнена неправильно
Шаг 1. Получите подтверждение того, что уровень шума в канале является достаточно низким для выполнения требуемой операции передачи данных. В случае необходимости примените экранированный кабель.
Шаг 2. Убедитесь в том, что шина кабеля не превышает допустимые пределы (нс больше 15,24 м или 7,62 м для канала Т1).
Шаг 3. Проверьте, правильно ли выполнена настройка конфигурации всех устройств для использования обшей синхронизации канала. Установите режим SCTE в локальном и удаленном устройствах DSU.
РешениеРешение
Решение
Решение
Тип ошибки Проблема ввода (имя поля в выводе команды)
• В канале Т1 нарушен процесс поддержки плотности единичных импульсов (неправильная спецификация фреймирова- ния или кодирования)• В канале Т1 нарушен процесс поддержки плотности единичных импульсов (неправильная спецификация фреймирова- ния или кодирования)Если конкретное устройство CSU/DSU не поддерживает режим SCTE, обратитесь к разделу “Инвертирование синхроимпульсов передачи", приведенному ниже в этой главе.
• В канале Т1 нарушен процесс поддержки плотности единичных импульсов (неправильная спецификация фреймирова- ния или кодирования)
• В канале Т1 нарушен процесс поддержки плотности единичных импульсов (неправильная спецификация фреймирова- ния или кодирования)
Шаг 4. Убедитесь в том, что конфигурация локального и удаленного устройств CSU/DSU настроена для использования такой же схемы фреймирова- ния и кодирования, как в арендованном канале или в другой службе оператора связи (например, ESF/B8ZS).
Шаг 5. Обратитесь к представителю провайдера арендованного канала или другой службы оператора связи и потребуйте проведения проверки целостности канала
Ошибки фреймирования (frame)Ошибки фреймирования (frame)
Ошибки фреймирования (frame)
Ошибки фреймирования (frame)
Возникла ошибка фреймирования, при которой пакет не заканчивается на границе восьмибитового байта, по одной из следующих причин.
Последовательный канал является зашумленным
Применяется кабель неподходящего типа; последовательный кабель имеет слишком большую длину; кабель от модуля CSU или DSU к маршрутизатору не экранирован.
В устройстве DSU не разрешено применение режима SCTE; неправильно настроены параметры синхронизации канала в конфигурации устройства CSU; один из генераторов синхроимпульсов настроен на локальную синхронизацию.
В канале Т1 нарушена поддержка плотности единичных импульсов (неправильная спецификация фреймирования или кодирования)
Шаг 1. Получите подтверждение того, что уровень шума в канале является достаточно низким для выполнения требуемой операции передачи данных. В случае необходимости используйте экранированный кабель. Проверьте, применяется ли кабель соответствующего типа.
Шаг 2. Убедитесь в том, что длина кабеля не превышает допустимые пределы (не больше 15,24 м или 7,62 м для канала Т1).
Шаг 3. Проверьте, правильно ли выполнена настройка конфигурации всех устройств для использования обшей синхронизации канала. Установите режим SCTE в локальном и удаленном устройствах DSU. Если конкретное устройство CSU/DSU не поддерживает режим SCTE, обратитесь к разделу “Инвертирование синхроимпульсов передачи”, приведенному ниже в этой главе.
РешениеРешение
Решение
Решение
Тип ошибки Проблема ввода (имя поля в выводе команды)
Шаг 4. Убедитесь в том, что конфигурация локального и удаленного устройств CSU/DSU настроена для использования такой же схемы фреймирова- ния и кодирования, как в арендованном канале или в другой службе оператора связи (например, ESF/B8ZS).
Шаг 5. Обратитесь к представителю провайдера арендованного канала или другой службы оператора связи и потребуйте проверить целостность канала
Аварийное завершение передачи (abort)Аварийное завершение передачи (abort)
Аварийное завершение передачи (abort)
Аварийное завершение передачи (abort)
Наличие ошибок, характеризующихся аварийным завершением передачи, указывает на появление недопустимой последовательности битов 1 (более семи битов подряд).
Ниже перечислены возможные причины возникновения указанных нарушений в работе.
В устройстве DSU не разрешено применение режима SCTE.
Неправильно настроены параметры синхронизации канала в конфигурации устройства CSU.
Последовательный кабель имеет слишком большую длину или кабель от устройства CSU/DSU к маршрутизатору не экранирован.
В канале Т1 нарушена поддержка плотности единичных импульсов (неправильная спецификация фреймирования или кодирования).
Неожиданное прекращение передачи пакета (типичной причиной является сброс интерфейса или ошибка фрей- мирования).
Шаг 1. Проверьте, правильно ли выполнена настройка конфигурации всех устройств для использования общей синхронизации канала. Установите режим SCTE в локальном и удаленном устройствах DSU. Если конкретное устройство CSU/DSU не поддерживает режим SCTE, обратитесь к разделу “Инвертирование синхроимпульсов передачи”, приведенному ниже в этой главе.
Шаг 2. В случае необходимости примените экранированный кабель. Убедитесь в том, что длина кабеля не превышает допустимые пределы (не больше 15,24 м или 7,62 м для канала Т1). Проконтролируйте, качественно ли выполнены все соединения.
Шаг 3. Проверьте аппаратные средства на обоих концах канала. В случае необходимости замените неисправное оборудование.
Шаг 4. Уменьшите скорости передачи данных и проверьте, сократилось ли количество аварийных завершений передачи.
Тип ошибки ввода (имя поля в выводе команды)
Проблема
Решение
• Возникло нарушение в работе аппаратных средств (неисправна цепь, неисправно CSU/DSU или неисправен передающий интерфейс на удаленном маршрутизаторе)
Шаг 5. Чтобы определить, по какой причине происходят аварийные завершения передачи, воспользуйтесь методами проверки с помощью локальной и удаленной петли обратной связи (обратитесь к разделу “Специальные способы проверки последовательного канала”, приведенному ниже в этой главе).
Шаг 6. Обратитесь к представителю провайдера арендованного канала или другой службы оператора связи и потребуйте проверить целостность канала
Последовательные каналы: увеличение количества случаев сброса интерфейса в последовательном канале
Ненулевое значение количества сбросов интерфейса в выводе exec-команды show interfaces serial (см. рис. 15.1) является результатом пропуска пакетов поддержки соединения.
Признак неисправности. Увеличение количества случаев сброса интерфейса в последовательном канале.
В табл. 15.6 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Последовательные каналы: увеличение количества случаев перехода на другую несущую в последовательном канале
В выводе exec-команды show interfaces serial обнаруживается ненулевое количество случаев перехода на другую несущую, если сигнал несущей время от времени прерывается (например, как при сбросе интерфейса на удаленном конце канала).
Признак неисправности. Увеличение количества случаев перехода на другую несущую в последовательном канале.
В табл. 15.7 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Таблица 15.6. Последовательные каналы: увеличение количества ■ случаев сброса интерфейса в последовательном канале
РешениеРешениеПроблема
Решение
Решение
Этот признак неисправности может быть вызван следующими проблемами.Затор в канале (который обычно обусловлен уничтожением выходных пакетов).Низкое качество канала, которое вызывает переход на другую несущую.Возможная неисправность аппаратных средств CSU, DSU или коммутатораЭтот признак неисправности может быть вызван следующими проблемами.Затор в канале (который обычно обусловлен уничтожением выходных пакетов).Низкое качество канала, которое вызывает переход на другую несущую.Возможная неисправность аппаратных средств CSU, DSU или коммутатораПри возникновении сбросов интерфейса проверьте другие поля в выводе команды show interfaces serial, чтобы определить причину возникновения проблемы. При условии, что обнаружено увеличение количества случаев сброса интерфейса, проверьте следующие поля.
Этот признак неисправности может быть вызван следующими проблемами.
Затор в канале (который обычно обусловлен уничтожением выходных пакетов).
Низкое качество канала, которое вызывает переход на другую несущую.
Возможная неисправность аппаратных средств CSU, DSU или коммутатора
Этот признак неисправности может быть вызван следующими проблемами.
Затор в канале (который обычно обусловлен уничтожением выходных пакетов).
Низкое качество канала, которое вызывает переход на другую несущую.
Возможная неисправность аппаратных средств CSU, DSU или коммутатора
Шаг 1. Если в выводе команды show interfaces serial обнаруживается большое количество уничтоженных выходных пакетов, см. выше раздел “Последовательные каналы: увеличение количества уничтоженных выходных пакетов в последовательном канале’’.
Шаг 2. Проверьте содержимое поля Carrier Transitions в выводе команды show interfaces serial. Если показанное здесь количество случаев перехода на другую несущую велико, притом что обнаруживаются случаи сброса интерфейса, то нарушение в работе может быть связано с низким качеством канала либо неисправностью CSU или DSU. Обратитесь к представителю провайдера арендованного канала или оператора связи и в случае необходимости замените неисправное оборудование.
Шаг 3. Проверьте содержимое поля Input Errors в выводе команды show interfaces serial. Если показанное здесь количество ошибок ввода велико, притом что увеличивается количество случаев сброса интерфейса, то нарушение в работе может быть связано с низким качеством канала или неисправностью CSU/DSU. Обратитесь к представителю провайдера арендованного канала или оператора связи и в случае необходимости замените неисправное оборудование
Таблица 15.7. Последовательные каналы: увеличение количества случаев й - перехода на другую несущую в последовательном канале
Этот признак неисправности может быть вызван следующими проблемами.Разрыв канала под действием внешних причин (таких как физическое повреждение кабельной разводки, красные или желтые аварийные сигналы Т1 или грозовые разряды на каком-либо участке сети).Неисправность аппаратного обеспечения коммутатора, DSU или маршрутизатораЭтот признак неисправности может быть вызван следующими проблемами.Разрыв канала под действием внешних причин (таких как физическое повреждение кабельной разводки, красные или желтые аварийные сигналы Т1 или грозовые разряды на каком-либо участке сети).Неисправность аппаратного обеспечения коммутатора, DSU или маршрутизатораШаг 1. Проверьте аппаратные средства на обоих концах канала (подключите коммутационный бокс или анализатор последовательных каналов и попытайтесь определить причины неисправности).Шаг 2. Если анализатор или коммутационный бокс не позволяют выявить какие-либо внешние причины, проверьте аппаратные средства маршрутизатора.Шаг 3. В случае необходимости замените неисправное оборудованиеШаг 1. Проверьте аппаратные средства на обоих концах канала (подключите коммутационный бокс или анализатор последовательных каналов и попытайтесь определить причины неисправности).Шаг 2. Если анализатор или коммутационный бокс не позволяют выявить какие-либо внешние причины, проверьте аппаратные средства маршрутизатора.Шаг 3. В случае необходимости замените неисправное оборудованиеПроблемаРешение
Этот признак неисправности может быть вызван следующими проблемами.
Разрыв канала под действием внешних причин (таких как физическое повреждение кабельной разводки, красные или желтые аварийные сигналы Т1 или грозовые разряды на каком-либо участке сети).
Неисправность аппаратного обеспечения коммутатора, DSU или маршрутизатора
Этот признак неисправности может быть вызван следующими проблемами.
Разрыв канала под действием внешних причин (таких как физическое повреждение кабельной разводки, красные или желтые аварийные сигналы Т1 или грозовые разряды на каком-либо участке сети).
Неисправность аппаратного обеспечения коммутатора, DSU или маршрутизатора
Шаг 1. Проверьте аппаратные средства на обоих концах канала (подключите коммутационный бокс или анализатор последовательных каналов и попытайтесь определить причины неисправности).
Шаг 2. Если анализатор или коммутационный бокс не позволяют выявить какие-либо внешние причины, проверьте аппаратные средства маршрутизатора.
Шаг 3. В случае необходимости замените неисправное оборудование
Шаг 1. Проверьте аппаратные средства на обоих концах канала (подключите коммутационный бокс или анализатор последовательных каналов и попытайтесь определить причины неисправности).
Шаг 2. Если анализатор или коммутационный бокс не позволяют выявить какие-либо внешние причины, проверьте аппаратные средства маршрутизатора.
Шаг 3. В случае необходимости замените неисправное оборудование
Применение команды show controllers
Одним из важных диагностических инструментальных средств при поиске неисправностей последовательных каналов является ехес-команда show controllers. Синтаксическая структура этой команды зависит от платформы.
В последовательных интерфейсах маршрутизаторов ряда Cisco 7000 применяется exec-команда show controllers cbus.
В серверах доступа и прочих средствах доступа Cisco применяется ехес-команда show controllers.
В устройствах AGS, CGS и MGS применяется ехес-команда show controllers mci.
На рис. 15.2 показан вывод exec-команды show controllers cbus. Эта команда применяется в маршрутизаторах ряда Cisco 7000 с платой FS1P (Fast Serial Interface Processor — быстродействующий процессор последовательного интерфейса). Проверьте вывод этой команды, чтобы убедиться в том, что кабель от устройства CSU/DSU подключен к соответствующему интерфейсу. Здесь также можно проверить версию микропрограммы и определить, является ли она текущей.
Harold>show controllers cbus
Switch Processor 5, hardware version 11.1, microcode version 10.7 1 ——' "
Microcode loaded from system'* микропрограммы
512 Kbytes of main memory, 128 Kbytes cache memory
4 256 byte buffers, 4 1024 byte buffers, 312 1520 byte buffers Информация Об
1024 byte system bufferинтерфейсе
Restarts: 0 line down, 0 hung output, 0 controller errorИ подключенном Кабеле
FSI? 0, hardware version 1.0, microcode version 175.0/
Microcode loaded from system/
Interface 0 - Serial 0/0, electrical interface is Universal (cable unattached)
22 buffer RX queue threshold, 23 buffer TX queue limit, buffer size 1520
TX queue length is 0
ift 0001, rql 12, tq 0000 0000, tql 23
Transmitter delay is 0 microseconds
Interface 1 - Serial 0/1, electrical interface is Universal (cable unattached)
22 buffer RX queue threshold, 23 buffer TX queue limit, buffer size 1520 TX queue length is 0 ift 0001, rql 12, tq 0000 0000, tql 23 Transmitter delay is 0 microseconds
Interface 2 - Serial 0/2, electrical interface is Universal (cable unattached) 22 buffer RX queue threshold, 23 buffer TX queue limit, buffer size 1520 TX queue length is 0 ift 0001, rql 12, tq 0000 0000, tql 23 Transmitter delay is 0 microseconds
Interface 3 - Serial 0/3, electrical interface is Universal (cable unattached) 22 buffer RX queue threshold, 23 buffer TX queue limit, buffer size 1520 TX queue length is 0 ift 0001, rql 12, tq 0000 0000, tql 23 Transmitter delay is 0 microseconds
Puc. 15.2. Вывод команды show controllers cbus
В сетевых средствах доступа, таких как серверы доступа и маршрутизаторы ряда Cisco 2000, Cisco 2500, Cisco 3000 и Cisco 4000, применяется ехес-команда show controllers. На рис. 15.3 приведен вывод команды show controllers, выполненной в
интерфейсе BRI и в последовательных интерфейсах сервера доступа Cisco 2503. (Следует отметить, что здесь часть вывода не показана.)
Вывод команды show controllers показывает состояние каналов интерфейса и позволяет определить, подключен ли кабель к интерфейсу. На рис. 15.3 показано, что к последовательному интерфейсу 0 подключен кабель RS-232 DTE. К последовательному интерфейсу 1 кабель не подключен.
На рис. 15.4 показан вывод команды show controllers mci. Эта команда применяется только в маршрутизаторах AGS, CGS и MGS. Если вместо обозначения типа электрического интерфейса (такого как V.35, EIA/TIA-449 или другого типа) показано UNKNOWN (неизвестный), то причиной неисправности может быть неправильно подключенный кабель, нарушение в работе прикладного программного обеспечения или неисправность платы. Если электрический интерфейс обозначен как неизвестный, то в выводе exec-команды show interfaces serial для соответствующего интерфейса будет показано, что интерфейс и протокол канала передачи данных не функционируют.
Применение команд debug
Вывод различных привилегированных exec-команд debug предоставляет диагностическую информацию о состоянии протокола и работе сети, в которой отражены многие события в объединенной сети.
Предостережение
Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и сокращения количества пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы. По завершении отладки с использованием команды debug обязательно отмените ее с помощью специализированной команды no debug или по debug all.
Maude>ahow controllers
BRI unit 0
D-канал переведен в неактивное состояниеD-канал переведен в неактивное состояниеD Chan Info:
D-канал переведен в неактивное состояние
D-канал переведен в неактивное состояние
Layer 1 is DEACTIVATED
О missed datagrams, 0 overruns, 0 bad frame addresses 0 bad datagram encapsulations, 0 memory errors 0 transmitter underruns
В-канал 1 переведен в неактивное состояниеВ-канал 1 переведен в неактивное состояниеBl Chan Info:
В-канал 1 переведен в неактивное состояние
В-канал 1 переведен в неактивное состояние
Layer 1 is DEACTIVATED
О missed datagrams, 0 overruns, 0 bad frame addresses 0 bad datagram cncapsulations, 0 memory errors 0 transmitter underruns
B2 Chan Info:
[. .
LANCE unit 0, idb 0x9515C, ds 0x96F00, regaddr = 0x2130000, reset_mask 0x2 IB at 0x40163F4: mode=0x0000, mcfilter 0000/0000/0000/0000 station address 0000.OcOa.28a7 default station address 0000.OcOa.28a7 buffer size 1524 г , . . ■ 0 missed datagrams, 0 overruns, 0 late collisions, 0 lost carrier events 0 transmitter underruns, 0 excessive collisions, 0 tdr, 0 babbles 0 memory errors, 0 spurious initialization done interrupts 0 no enp status, 0 buffer errors, 0 overflow errors 0 one_col, 0 more_col, 3 deferred, 0 tx_buff 0 throttled, 0 enabled
Lance csrO = 0x73
ED unit 0, idb = 0x98D28, driver structure at 0x9AAD0 К последовательному buffer size 1524 | HD unit 0, RS-232 DTE cable | —— 'ИНТерфеЙсуО
подключен кабель
0 missed datagrams, 0 overruns, 0 bad frame addresses
0 bad datagram encapsulations, 0 memory errors 0 transmitter underruns
HD unit 1, idb = 0x9ClB8, driver structure at 0x9DF60_ К последовательному buffer size 1524 | HD unit 1, No DCE cable [__--—" " " интерфейсу 1 кабель
не подключен
[. •
0 missed datagrams, 0 overruns, 0 bad frame addresses
0 bad datagram encapsulations, 0 memory errors
0 transmitter underruns
Puc. 15.3. Вывод команды show controllers
Тип электрического интерфейса определен как UNKNOWN. Это означает, что обнаружен отказ аппаратных средств или неправильно подключенный кабель
MCI 1, controller type 1.1, microcode version 1.8 128 Kbytes of main memory, 4 Kbytes cache memory
16 system TX buffers, largest buffer size 1520/
Restarts: 0 line down, 0 hung output, 0 controller error Interface 0 is Ethernetl, station address 0000.OdOO.3b09
22 total RX buffers, 9 buffer TX queue limit, buffer size 1520 Transmitter delay is 0 microseconds/
Interface 1 is Serial2, electrical interface is|UNKNOWN |
22 total RX buffers, 9 buffer TX queue limit, buffer size 1520 Transmitter delay is 0 microseconds High speed synchronous serial interface
Interface 3 is Serial3, electrical interface is V.35 DTE
22 total RX buffers, 9 buffer TX queue limit, buffer size 1520 Transmitter delay is 0 microseconds High speed synchronous serial interface
Puc. 15.4. Вывод команды show controllers met
Ниже описаны некоторые команды debug, которые могут применяться при поиске неисправностей в последовательных каналах и в распределенной сети. Дополнительная информация о назначении и выводе каждой из этих команд представлена в документе Debug Command Reference.
debug serial interface. Позволяет определить, происходит ли увеличение количества пакетов поддержки соединения HDLC. Если такое увеличение не наблюдается, то, возможно, нарушена синхронизация в интерфейсной плате или в сети.
debug х25 events. Позволяет обнаружить такие события в сети Х.25, как открытие и закрытие коммутируемых виртуальных каналов (SVC —- Switched Virtual Circuit). Отчет о зарегистрированных событиях содержит описание причин событий и диагностическую информацию.
debug lapb. Предоставляет информацию о работе протокола LAPB или Х.25 уровня 2.
debug агр. Показывает, передает ли конкретный маршрутизатор информацию о маршрутизаторах или получает информацию о маршрутизаторах (с помощью пакетов ARP), находящихся на другом конце открытой распределенной сети. Эта команда применяется, если некоторые узлы в сети TCP/IP отвечают, а другие — нет.
debug frame-relay Imi. Позволяет получить информацию об интерфейсе LMI, необходимую для определения того, выполняется ли передача и прием пакетов LMI каким-либо коммутатором Frame Relay или каким-либо маршрутизатором.
debug frame-relay events. Позволяет определить, происходит ли обмен информацией между маршрутизатором и коммутатором Frame Relay.
debug ppp negotiation. Показывает пакеты PPP, переданные во время запуска программного обеспечения РРР, когда происходит согласование опций РРР.
debug ppp packet. Показывает передаваемые и принимаемые пакеты PPP. Эта команда выводит дампы пакетов низкого уровня.
debug ppp errors. Предоставляет информацию об ошибках РРР (таких как недопустимые или искаженные фреймы), возникающих при согласовании опций и эксплуатации соединения РРР.
debug ppp chap. Позволяет получить информацию об обмене пакетами протоколов CHAP (Challenge Handshake Authentication Protocol — протокол аутентификации с предварительным согласованием вызова) и PAP (Password Authentication Protocol — протокол аутентификации по паролю) из набора протоколов РРР.
debug serial packet. Показывает передаваемые и принимаемые пакеты SMDS. В выводе этой команды содержатся сообщения об ошибках, которые позволяют определить, почему тот или иной пакет не передан или принят с ошибками. При обработке пакетов SMDS эта команда выводит весь заголовок SMDS и некоторую часть области данных при передаче и приеме каждого пакета SMDS.
Методы проверки с помощью расширенной команды эхо-тестирования
Команда ping является удобным средством проверки, которая может применяться в устройствах объединенной сети Cisco, а также во многих системах хостов. В наборе протоколов TCP/IP это диагностическое инструментальное средство известно также под названием запроса эхо-тестирования протокола 1СМР.
Примечание
Команда ping является особенно полезной, если в выводе команды show interfaces serial обнаруживается большое количество зарегистрированных ошибок ввода (см. рис. 15.1).
В устройствах объединенной сети Cisco предусмотрен механизм, позволяющий автоматизировать операции по последовательной передаче большого количества пакетов эхо-тестирования. На рис. 15.5 показано меню, позволяющее определить опции расширенного эхо-тестирования. В данном примере предусмотрена отправка 20 пакетов эхо-тестирования подряд. Но при тестировании компонентов в последовательном канале необходимо указывать гораздо большее количество пакетов эхо-тестирования, например 1000. Необходимо также увеличить длину дейтаграммы, например до 1500.
Как правило, проверка последовательного канала с помощью эхо-тестирования должна осуществляться следующим образом.
Шаг 1. Переведите устройство CSU или DSU в режим локальной петли обратной связи.
Шаг 2. Установите опции расширенной команды ping для передачи пакетов данных с разным содержанием и разными размерами. На рис. 15.6 и 15.7 показаны результаты двух удобных проверок с помощью команды ping: эхо- тестирование с помощью 1500-байтового пакета, состоящего из одних нулей, и эхо-тестирование с помощью 1500-байтового пакета, состоящего из одних единиц.
Шаг 3. Рассмотрите вывод команды show interfaces serial (см. рис. 15.1) и определите, увеличилось ли количество ошибок во входных пакетах. Если количество ошибок во входных пакетах не увеличилось, то локальные аппаратные средства (DSU, кабель, интерфейсная плата маршрутизатора), вероятно, находятся в хорошем состоянии.
Но если в ответ на эту тестовую последовательность появилось большое количество ошибок CRC и ошибок фреймирования, то может иметь место нарушение синхронизации. Проверьте CSU или DSU, чтобы определить, нет ли нарушения в работе средств синхронизации. Обратитесь к следующему разделу, “Устранение нарушений синхронизации”.
Betelgeuse# ping
Protocol [ip]:
Target IP address: 129.44.12.7
Repeat count [5] :| 20 | Количество запросов
Datagram size [100]: 64ЭХО-ТвСТИрОваниЯ
Timeout in seconds [2]:
Extended commands [n] : | yea| Опция применения
Source address:расширенного
Type of service [0] :формата команды
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [ OxABCD] : | Oxffff | Определение
Loose, Strict, Record, Timestamp, Verbose[none] :Шаблона данных
Sweep range of sizes [n] : Type escape sequence to abort.
Sending 20, 64-byte ICMP Echos to 129.44.12.7, timeout is 2 seconds: packet has data pattern OxFFFF i i i i i i i i i i : i i i i i i i i i
Success rate is 100 percent, round-trip min/avg/max = 1/3/4 ms
Puc. 15.5. Меню определения опций расширенного эхо-тестирования
Шаг 4. Если вы определили, что конфигурация средств синхронизации является правильной и они функционируют должным образом, переведите CSU или DSU в режим удаленной петли обратной связи.
Шаг 5. Повторите проверку с помошью команды эхо-тестирования и определите, изменилась ли статистика ошибок во входных пакетах.
Шаг 6. Если количество ошибок во входных пакетах увеличилось, то нарушение в работе может быть связано с неисправностью последовательного канала или устройства CSU/DSU. Обратитесь к провайдеру служб распределенной сети и замените CSU/DSU. Если эти мероприятия не позволяют устранить нарушение в работе, обратитесь за помошью к представителю службы технической поддержки.
Устранение нарушений синхронизации
Несогласованность средств синхронизации последовательных соединений может привести либо к нестабильной работе службы установления соединений, либо к снижению производительности. В настоящем разделе рассматриваются важные аспекты проблем синхронизации: причины, способы обнаружения, способы определения причин и рекомендации по устранению нарушений синхронизации.
yowzers#plng
Protocol [ip]:
Target IP address: 192.169.51.22
Repeat count [5]: 100
Размер пакета —]
|Datagram size [100]: 1500 |
1500 байтов
Timeout in seconds [2]: Extended commands [n]: у Source address: 192.169*51.14 Type of service [0]:
Set DF bit in IP header? [no]: Validate reply data? [no]:
Запрос1
Data pattern [OxABCD]: 0x0000|
эхо-тестирования, состоящий из одних нулей
Loose, Strict, Record, Timestamp, Sweep range of sizes [n]: Type escape sequence to abort.
Sending 100, 1500-byte ICMP Echos
Packet has data pattern 0x0000
verbose[none];
to 192.169.51.22, timeout is 2 seconds
t t ।।। । 1 1 1 । t । । । t t t > । । > t t । ■ । ।
Success rate is IOC percent (100/100), round-trip min/avg/max = 4/6/8 ms yowzers#
Puc. 15.6. Эхо-тестирование с помощью 1500-байтового пакета, состоящего из одних нулей
zounds#plng
Protocol [ip]:
Target IP address: 192.169.51.22
Repeat count [5]: 100
Размер пакета|Datagram size [100]: 1500 |
1500баЙТОВ Timeout in seconds [2]:
Extended commands [n] : у
Source address: 192.169.51.14
'Гуре of service [0] :
Set DF bit in IP header? [no]:
Validate reply data? [no]:
ЗапрОС(Data pattern”[OxABCdT: Oxffff]
ЭХО-ТеСТИровЗНИЯ, Loose, Strict, Record, Timestamp, Verbose[none]:
СОСТОЯЩИЙ ИЗSweep range of sizes [n] :
ОДНИХедИНИЦType escape sequence to abort.
Sending 100, 1500-byte ICMP Echos to 192.169.51.22, timeout is 2 seconds: Packet has data pattern OxFFFF
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/6/8 ms zounds#
Puc. 15.7. Эхо-тестирование с помощью 1500-байтового пакета, состоящего из одних единиц
Краткий обзор методов синхронизации
Устройства CSU/DSU извлекают импульсы синхронизации данных из самих данных, проходящих через эти устройства. Чтобы иметь возможность извлекать синхроимпульсы, аппаратное обеспечение CSU/DSU обязательно должно принимать, по меньшей мере, один бит со значением 1 в расчете на каждые 8 битов данных, проходящих через устройство; такой метод выборки синхроимпульсов называется поддержкой плотности единичных импульсов. Метод поддержки плотности единичных импульсов позволяет аппаратному обеспечению надежно восстанавливать импульсы синхронизации данных.
В новейших реализациях Т1 обычно применяется фреймирование ESF (Extended Superframe Format — расширенный формат суперфрейма) наряду с кодированием B8ZS (Binary Eight-Zero Substitution — подстановка кода вместо восьми двоичных нулей). В методе B8ZS предусмотрена схема, в которой вместо восьми подряд идущих нулей, передаваемых по последовательному каналу, выполняется подстановка специального кода. Этот код затем интерпретируется на удаленном конце соединения. Такой метод гарантирует поддержку плотности единичных импульсов независимо от структуры потока данных.
В более старых реализациях Т1 применяется фреймирование D4 (известное также под названием SF) и кодирование AMI (Alternate Mark Inversion — кодирование с чередованием полярности элементов). В методе AMI не используется схема кодирования, аналогичная B8ZS. Это приводит к ограничению перечня типов данных, которые могут быть переданы по каналу, поскольку в данном случае плотность единичных импульсов не может поддерживаться независимо от структуры потока данных.
Еще одним важным элементом последовательной передачи данных является синхронизация терминала в режиме SCTE. Режим SCTE предусматривает зеркальную передачу синхроимпульсов из устройства DTE (такого как маршрутизатор) в устройство DCE (такое как CSU/DSU).
При использовании устройством DCE для выборки данных из DTE синхроимпульсов, передаваемых в режиме SCTE, вместо синхроимпульсов, вырабатываемых его внутренним генератором, появляется возможность лучше организовать безошибочную выборку данных, даже если в кабеле между устройством CSU/DSU и маршрутизатором имеется сдвиг фаз. Для последовательной передачи данных на скорости, превышающей 64 Кбит/с, настоятельно рекомендуется применять режим SCTE. Если же конкретное устройство CSU/DSU не поддерживает режим SCTE, см. ниже раздел “Инвертирование синхроимпульсов передачи".
Причины нарушения синхронизации
Как правило, нарушения синхронизации в последовательных соединениях распределенной сети могут возникать по одной из следующих причин.
Неправильная конфигурация DSU.
Неправильная конфигурация CSU.
Кабели не соответствуют спецификации (превышают по длине 15,24 м или не являются экранированными).
Зашумленные или некачественные соединения коммутационной панели.
Соединение подряд нескольких кабелей.
Способы обнаружения нарушений синхронизации
Для обнаружения несогласованности в работе средств синхронизации последовательного интерфейса необходимо проанализировать ошибки ввода, как описано ниже.
Шаг 1. Вызовите на выполнение exec-команду show interfaces serial в маршрутизаторах на обоих концах канала.
Шаг 2. Проверьте наличие в выводе указанной команды информации об ошибках CRC, ошибках фреймирования и случаях аварийного завершения передачи.
Шаг 3. Если в одном из соответствующих полей находятся значения, показывающие, что количество ошибок превышает предел, который составляет приблизительно 0,5— 2,0% объема трафика через интерфейс, то, по всей вероятности, на каком-то участке рассматриваемой распределенной сети имеются нарушения синхронизации.
Шаг 4. Определите причину несогласованности в работе средств синхронизации, как описано в следующем разделе, “Способы определения причин нарушений синхронизации”.
Шаг 5. Обойдите (зашунтируйте) или отремонтируйте все неисправные коммутационные панели.
Способы определения причин нарушений синхронизации
После обнаружения несогласованности в работе средств синхронизации, которые могут явиться наиболее вероятной причиной ошибок ввода, примените следующую процедуру для обнаружения причины таких ошибок.
Шаг 1. Выполните ряд проверок по методу эхо-тестирования и с применением петли обратной связи (локальной и удаленной), как описано выше, в разделе “Рекомендации по проверке петлевого интерфейса CSU и DSU”.
Шаг 2. Определите, на каком конце соединения возникает рассматриваемая проблема, а также проверьте, не является ли причиной нарушения в работе неисправность самого канала. В режиме локальной петли обратной связи выполните проверки по методу эхо-тестирования с использованием разных последовательностей передаваемых данных и разных дейтаграмм (например, примените дейтаграммы длиной 1500 байтов). Если такие проверки будут проводиться с помощью пакетов, содержащих одинаковые данные и имеющих одинаковые размеры, то ошибки могут не обнаружиться, особенно если причиной неисправности является последовательный кабель к маршрутизатору или к устройству CSU/DSU.
Шаг 3. Вызовите на выполнение exec-команду show interfaces serial и определите, увеличивается ли количество ошибок ввода и где они накапливаются.
Если ошибки ввода накапливаются на обоих концах соединения, то, по всей вероятности, рассматриваемая проблема обусловлена нарушением синхронизации устройства CSU.
Если же ошибки ввода обнаруживаются только на одном конце соединения, то, вероятно, нарушена синхронизация DSU или неисправна кабельная разводка.
Возникновение случаев аварийного завершения передачи на одном конце свидетельствует о том, что с другого конца передается некорректная информация или имеет место нарушение в работе канала.
Примечание
Всегда сверяйтесь с результатами выполнения команды show interfaces serial (см. рис. 15.1). Регистрируйте любые изменения в данных о количестве ошибок или отмечайте, что количество ошибок не изменилось.
Решения проблем синхронизации
В табл. 15.8 приведены краткие рекомендации по решению проблем синхронизации с учетом того, что явилось причиной возникновения этих проблем.
Таблица 15.8. Последовательные каналы: проблемы синхронизации .:
Проблема
и их решения.
Решение
Неправильная конфигурация CSU
Шаг 1. Определите, задан ли в устройствах CSU на обоих концах канала одинаковый источник синхроимпульсов (локальный или канальный).
Шаг 2. Если конфигурации устройств CSU не согласованы друг с другом, внесите в них изменения, чтобы добиться полного согласования (обычно источником синхроимпульсов является канал).
Шаг 3. Проверьте параметр LBO (Line Build Out — оценка длины канала) в устройстве CSU, чтобы убедиться в том, что заданный здесь импеданс соответствует импедансу физической линии. Дополнительная информация о настройке конфигурации конкретного устройства CSU приведена в документации по аппаратным средствам CSU
Неправильная конфигурация DSU
Шаг 1. Определите, разрешено ли применение режима SCTE в устройствах DSU на обоих концах канала.
Шаг 2. Если в каком-либо из этих устройств не разрешено применение режима SCTE, разрешите его.
(Применение режима SCTE должно быть разрешено в любом интерфейсе, подключенном к каналу со скоростью передачи данных 128 Кбит/с или более высокой скоростью. Если конкретное устройство DSU не поддерживает режим SCTE, обратитесь к разделу “Инвертирование синхроимпульсов передачи", приведенному ниже в этой главе.)
Шаг 3. Убедитесь в том, что поддерживается плотность единичных импульсов. Для этого требуется, чтобы в устройстве DSU применялись такие же схемы фреймирования и кодирования (например, ESF и B8ZS), как и в арендованном канале или другой службе оператора связи.
Обратитесь к провайдеру арендованного канала для получения информации об используемых им схемах фреймирования и кодирования.
Шаг 4. Если в службе оператора связи применяется кодирование AMI, либо направьте синхроимпульсы передачи на обоих концах канала в противоположном направлении, либо переведите устройство DSU в режим вставки битов. Для получения информации о настройке конкретного устройства DSU обратитесь к документации по аппаратным средствам этого устройства
Кабель к маршрутизатору не соответствует спецификации
Если длина кабеля превышает 15,24 м, используйте более короткий кабель.
Если кабель не имеет экрана, замените его экранированным кабелем
Инвертирование синхроимпульсов передачи
Если для установления последовательных соединений со скоростью, превышающей 64 Кбит/с, применяется устройство CSU/DSU, не поддерживающее режим SCTE, то может потребоваться направить синхроимпульсы передачи в маршрутизаторе в противоположном
направлении. Такое инвертирование синхроимпульсов передачи позволяет скомпенсировать сдвиги фаз между сигналами данных и сигналами синхронизации.
Синтаксическая структура команды, применяемой для инвертирования синхроимпульсов передачи, зависит от платформы. В маршрутизаторах ряда Cisco 7000 введите команду конфигурации интерфейса invert-transmit-clock. В маршрутизаторах ряда Cisco 4000 воспользуйтесь командой конфигурации интерфейса dte-invert-txc.
Чтобы обеспечить применение правильной синтаксической структуры команды для конкретного маршрутизатора, обратитесь к руководству пользователя для применяемого маршрутизатора или сервера доступа, а также к руководствам по настройке конфигурации и справочникам команд Cisco IOS.
Примечание
На более старых платформах для инвертирования синхроимпульсов передачи может потребоваться физическая перестановка перемычки.
Корректировка размеров буферов
Если интенсивность трафика в канале слишком высока, т.е. превышает 70% пропускной способности, это может привести к снижению общей производительности и вызвать периодические отказы. Например, передача файла по протоколу DECnet может закончиться неудачей из-за потери пакетов где-либо в сети.
Если сложившаяся ситуация близка к критической, необходимо увеличить пропускную способность канала. Но увеличение пропускной способности может оказаться неоправданным или не может быть осуществлено в ближайшее время. Одним из способов решения проблемы дальнейшей эксплуатации последовательного канала, нагрузка которого приближается к пределу пропускной способности, является управление способом использования буферов данных в маршрутизаторе.
П редостережен ие
Как правило, не следует корректировать параметры системных буферов без тесной координации с представителем службы технической поддержки Cisco. Если в процессе корректировки параметров системных буферов маршрутизатора будет допущена ошибка, это может привести к существенному снижению производительности аппаратных средств и самой сети.
Для управления способом использования буферов можно применить один из следующих вариантов.
Корректировка параметров, касающихся системных буферов.
Задание числа пакетов, хранящихся во входных или выходных очередях (корректировка размеров очередей).
Применение приоритетов и размещение пакетов выходного трафика в очередях для передачи (организация выходных очередей по приоритетам).
Команды конфигурации, относящиеся к этим трем вариантам, описаны в руководствах по настройке конфигурации и справочниках команд Cisco IOS.
В следующем разделе в основном рассматриваются такие ситуации, при которых может оказаться целесообразным применение этих трех вариантов, и описаны способы их использования для решения проблем нарушения связи и снижения производительности последовательных соединений и соединений распределенной сети.
Настройка системных буферов
Буфера, предусмотренные в маршрутизаторах Cisco, подразделяются на два основных типа: аппаратные и системные. Для настройки непосредственно доступны только системные буфера. Аппаратные буфера имеют конкретное назначение: они применяются в качестве буферов приема и передачи, связанных с каждым интерфейсом, и (в отсутствии некоторых специальных параметров конфигурации) динамически управляются самим системным программным обеспечением.
Системные буфера размещаются в основной памяти системы и распределяются в виде блоков памяти переменного размера. Для определения состояния системных буферов применяется exec-команда show buffers. На рис. 15.8 показан вывод команды show buffers.
Cookie-Monster>show buffers
Buffer elements:
401 in free list (500 max allowed) 87777499 hits, 0 misses, 0 created Small buffers, 104 bytes (total 120, permanent 120):
114 in free list (20 min, 250 max allowed) 70005538 hits, 6 misses, 2 trims, 2 created Middle buffers, 600 bytes (total 90, permanent 90):
88 in free list (10 min, 200 max allowed)
25696696 hits, 27 misses, 27 trims, 27 created
Big buffers, 1524 bytes (total 90, permanent 90):„
.,.., „ .Количество
90 in free list 5 mln, 300 max arrowed
„, , , .,.',,.- уничтоженных
8214530 hits, 15 misses, 366 trims, 366 created,/
Large buffers, 5024 bytes (total 5, permanent
5 in free list (0 min, 30 max allowgd)/'^
КоличествоКоличество15017 hits, 12 misses,| 16354 trims[ (16354 created] Созданных
Количество
Количество
Huge buffers, 18024 bytes (total 3, permanent 0):буферов
2 in free list (0 min, 4 rax allowed) 297582 hits, 17 misses, 30 trims, 33 created
|o failures (0 no memory) Lr Количество отказов
Рис. 15.8. Вывод команды show buffers
Ниже описаны поля, которые представлены в выводе команды show buffers.
Поле total показывает общее количество буферов в пуле, включая используемые и неиспользуемые буфера.
Поле permanent определяет постоянное число распределенных буферов в пуле. Эти буфера всегда находятся в пуле и не могут быть удалены.
Поле in free list показывает количество буферов, находящихся в настоящее время в пуле, которые доступны для использования.
В поле min показано минимальное количество буферов, которое процессор маршрутизации должен поддерживать в списке свободных буферов. Этот параметр характеризуется следующими особенностями.
Параметр min применяется для прогнозирования потребности в буферах, получаемых из пула в любой момент времени.
Если количество буферов в списке свободных буферов становится ниже значения min, процессор RP предпринимает попытку создать дополнительные буфера для этого пула.
В поле max allowed показано максимальное количество буферов, которые могут находиться в списке свободных буферов. Этот параметр характеризуется следующими особенностями.
Параметр max allowed исключает возможность дальнейшего сохранения буферов, которые больше не требуются в пуле, и позволяет передать занимаемую ими память в систему для дальнейшего использования.
Если количество буферов в списке свободных буферов превышает значение max allowed, процессор RP предпринимает попытку удалить лишние буфера из пула.
В поле hits показано количество буферов, которые были затребованы из пула. Этот счетчик попаданий предоставляет механизм определения того, какой пул должен поддерживаться для удовлетворения наивысшей потребности в буферах.
Поле misses показывает количество случаев, когда был затребован буфер и процессор RP обнаружил, что требуются дополнительные буфера. (Иными словами, количество буферов в списке свободных буферов упало ниже значения min.) Этот счетчик неудач показывает, сколько раз процессор RP был вынужден создавать дополнительные буфера.
Поле trims показывает количество буферов, изъятых процессором RP из пула после того как количество буферов в списке свободных буферов превысило значение параметра max allowed.
В поле created показано количество буферов, которые были созданы в пуле. Процессор RP создает буфера, если потребность в них возрастает до такой степени, что количество буферов в списке свободных буферов становится меньше параметра min или попытка выделить буфер завершается неудачей, поскольку количество буферов в списке свободных буферов достигает нуля.
Поле failures показывает количество таких случаев, когда попытка предоставить буфер по запросу оканчивалась неудачей даже после попытки создать дополнительный буфер. Это количество отказов характеризует количество пакетов, которые были уничтожены из-за нехватки буферов.
Поле no memory показывает количество случаев неудачного завершения попыток создания дополнительных буферов, вызванных нехваткой памяти.
Вывод команды show buffers, приведенный на рис. 15.8, показывает, что в полях trims и created приведены высокие значения для больших буферов. Если в этих полях часто обнаруживаются данные о большом количестве уничтоженных и созданных буферов, то производительность последовательного канала можно повысить, увеличив значение параметра max free в конфигурации системных буферов. В поле trims показано количество буферов, изъятых процессором RP из пула после того, как количество буферов в списке свободных буферов превысило значение параметра max allowed.
Для увеличения количества свободных системных буферов применяется глобальная команда конфигурации buffers max free number. Значение, введенное в конфигурацию, должно составлять приблизительно 150% от числа, показанного в поле total в выводе команды show buffers. Повторяйте этот процесс до тех пор, пока в полях trims и created вывода команды show buffers перестанут обнаруживаться высокие показатели количества уничтоженных и созданных буферов.
Если в поле no memory вывода команды show buffers содержатся данные о большом количестве отказов (см. последнюю строку вывода на рис. 15.8), то необходимо уменьшить степень загрузки системных буферов или увеличить объем разделяемой или основной памяти (физической оперативной памяти) в маршрутизаторе. Обратитесь за помощью к представителю службы технической поддержки.
Корректировка предельных размеров очереди
Очереди применяются в каждом интерфейсе маршрутизатора для хранения входящих и исходящих пакетов, а пространство для них распределяется в виде системных буферов. Для увеличения количества пакетов данных, которые могут быть поставлены в очередь, служит команда конфигурации интерфейса hold-queue. Пакеты, не поместившиеся в очереди, уничтожаются маршрутизатором. Предельные размеры очереди необходимо увеличивать на небольшое значение (например, каждый раз на 25%) до тех пор, пока в выводе команды show interfaces больше не будут обнаруживаться данные об уничтоженных пакетах. По умолчанию предельный размер выходной очереди составляет 100 пакетов.
Примечание
Команда hold-queue используется для увеличения размеров очереди, в которой хранятся пакеты, коммутируемые процессом, и периодические обновления, вырабатываемые маршрутизатором.
Команду hold-queue целесообразно применять для предотвращения уничтожения пакетов и повышения производительности последовательного канала при следующих условиях.
Приложение, эксплуатируемое в сети, не допускает возможности уничтожения пакетов, а протокол способен функционировать в условиях продолжительных задержек. Примером протокола, который соответствует обоим этим критериям, является DECnet. А протокол LAT не соответствует одному из этих критериев, поскольку не допускает продолжительных задержек.
Интерфейс работает очень медленно (канал характеризуется низкой пропускной способностью, или прогнозируемая степень загрузки иногда превышает имеющуюся пропускную способность).
Примечание
При увеличении предельного размера выходной очереди может потребоваться увеличить количество системных буферов. Объем используемой памяти зависит от размеров пакетов в составе трафика, прогнозируемого для данной сети.
Организация очередей по приоритетам для повышения производительности
Организация очередей по приоритетам основана на использовании механизма управления, позволяющего распределять трафик, проходящий через отдельные интерфейсы, с учетом списков приоритетов. Для организации очереди по приоритетам необходимо выполнить следующее.
Шаг 1. Создать список приоритетов с указанием типа протокола и уровня приоритета. Шаг 2. Назначить список приоритетов для использования в определенном интерфейсе.
На обоих этих этапах применяются разные варианты глобальной команды конфигурации priority-list. Кроме того, дополнительное управление трафиком можно осуществить, введя ссылки на глобальные команды конфигурации access-list в спецификации команд priority-list. Для ознакомления с примерами определения списков приоритетов и подробными сведениями о синтаксической структуре команд, применяемых при организации очередей по приоритетам, обратитесь к руководствам по настройке конфигурации и справочникам команд Cisco IOS.
Примечание
В результате выполнения указанных выше этапов организации очередей по приоритетам автоматически создаются четыре очереди разных размеров. При этом отменяются все прочие спецификации очередей, входящие в состав конфигурации.
Организацию очередей по приоритетам целесообразно применять для предотвращения уничтожения пакетов и повышения производительности последовательного канала при следующих условиях.
Интерфейс работает медленно, передается трафик многих разных типов, поэтому необходимо повысить производительность передачи трафика оборудованием DTE.
В последовательном канале время от времени возникают очень высокие нагрузки (например, в определенные моменты времени происходит передача файлов), и организация очередей по приоритетам должна помочь определить, какого рода трафик должен быть заблокирован в периоды пиковой нагрузки.
Как правило, при переходе к применению очередей, организованных по приоритетам, следует начинать с количества очередей, предусмотренного по умолчанию. После выполнения этапов организации очередей по приоритетам контролируйте количество уничтоженных выходных пакетов с помощью exec-команды show interfaces serial. Если будет обнаружено, что уничтожение выходных пакетов происходит в очереди трафика, которой назначен высокий приоритет, увеличьте количество пакетов, которые могут быть поставлены в очередь (с использованием опции queue-limit глобальной команды конфигурации priority-list). По умолчанию значения параметров опции queue-limit составляют 20 пакетов для очереди с высоким приоритетом, 40 — со средним, 60 — с нормальным и 80 — с низким.
Примечание
Если применяется мостовое перенаправление трафика протокола LAT корпорации Digital Equipment Corporation, маршрутизатор должен уничтожать лишь очень небольшое
количество пакетов, так как в противном случае сеансы LAT могут завершаться аварийно. Как правило, если маршрутизатор уничтожает выходные пакеты, а степень загрузки последовательных каналов иногда повышается примерно до 50%, применяются очереди с высоким приоритетом, размер которых (заданный с ключевым словом queue-limit) составляет около 100. А если маршрутизатор уничтожает выходные пакеты и степень загрузки каналов достигает 100%, необходимо ввести в действие еще один канал.
Еще одним инструментальным средством, позволяющим уменьшить затор при мостовом перенаправлении трафика протокола Digital LAT, является сжатие LAT. Для реализации сжатия LAT применяется команда конфигурации интерфейса bridge-group group lat-compression.
Специальные способы проверки последовательного канала
Кроме основных диагностических средств, предусмотренных в маршрутизаторах, для определения состояния кабелей, коммутационного оборудования, модемов, хостов и удаленных аппаратных средств объединенной сети может применяться целый ряд дополнительных инструментальных средств и методов. Для ознакомления с дополнительной информацией обратитесь к документации CSU, DSU, анализатора последовательных каналов или другого оборудования.
Рекомендации по проверке петлевого интерфейса CSU, DSU
Если вывод exec-команды show interfaces serial показывает, что последовательный канал функционирует, а протокол канала передачи данных не функционирует, воспользуйтесь методами проверки CSU/DSU с применением петли обратной связи для определения причины возникновения проблем. Вначале выполните проверку в режиме локальной петли обратной связи, а затем — проверку в режиме удаленной петли обратной связи. На рис. 15.9 показана общая схема выполнения проверок CSU/DSU в режиме локальной и удаленной петли обратной связи.
Локальная петля обратной связи к маршрутизатору АЛокальная петля обратной связи к маршрутизатору АУдаленная петля обратной связи к маршрутизатору ВУдаленная петля обратной связи к маршрутизатору ВУдаленная петля обратной связи к маршрутизатору АУдаленная петля обратной связи к маршрутизатору АЛокальная петля обратной связи к маршрутизатору ВЛокальная петля обратной связи к маршрутизатору ВРис. 15.9. Схема выполнения проверок CSU/DSU в режиме локальной и удаленной петли обратной связиРис. 15.9. Схема выполнения проверок CSU/DSU в режиме локальной и удаленной петли обратной связи
Локальная петля обратной связи к маршрутизатору А
Локальная петля обратной связи к маршрутизатору А
Удаленная петля обратной связи к маршрутизатору В
Удаленная петля обратной связи к маршрутизатору В
Удаленная петля обратной связи к маршрутизатору А
Удаленная петля обратной связи к маршрутизатору А
Локальная петля обратной связи к маршрутизатору В
Локальная петля обратной связи к маршрутизатору В
Рис. 15.9. Схема выполнения проверок CSU/DSU в режиме локальной и удаленной петли обратной связи
Рис. 15.9. Схема выполнения проверок CSU/DSU в режиме локальной и удаленной петли обратной связи
Примечание
Эти методы проверки являются универсальными по своему характеру и требуют подключения аппаратных средств объединенной сети к устройству CSU или DSU. Но они остаются по сути такими же и при подключении к сетевому оборудованию мультиплексора со встроенными функциональными средствами CSU/DSU. В среде сети с коммутацией пакетов Х.25 или Frame Relay не существует понятия петли обратной
связи, поэтому в подобных сетях не могут применяться методы проверки с использованием петли обратной связи.
Методы проверки CSU и DSU с помощью локальной петли обратной связи в каналах HDLC или РРР
Ниже описана обшая процедура выполнения проверок с помощью петли обратной связи в сочетании с использованием встроенных диагностических средств системы.
Шаг 1. Переведите устройство CSU/DSU в режим локальной петли обратной связи (обратитесь к документации поставщика). В режиме локальной петли обратной связи применение синхронизации (обеспечиваемой службой Т1) прекращается, и устройство DSU принудительно переводится в режим использования локального генератора синхроимпульсов.
Шаг 2. Вызовите на выполнение exec-команду show interfaces serial, чтобы определить, произошло ли изменение состояния канала из остановленного (сообщение "line protocol is down") в рабочее (сообщение "line protocol is up (looped)"), или канал по-прежнему не функционирует.
Шаг 3. Если после переключения устройства CSU или DSU в режим локальной петли обратной связи протокол канала передачи данных перешел в рабочее состояние, то можно предположить, что неисправность имеет место на удаленном конце последовательного соединения. Если же сообщение в строке состояния не изменилось, то причиной неисправности может являться маршрутизатор, соединительный кабель или устройство CSU/DSU.
Шаг 4. Если есть основания полагать, что неисправность возникла в одном из локальных устройств, воспользуйтесь привилегированной exec-командой debug serial interface.
Шаг 5. Отмените режим локальной петли обратной связи в устройстве CSU/DSU. Если протокол канала передачи данных не функционирует, то вывод команды debug serial interface покажет, что значения счетчиков пакетов поддержки соединения (тестовых пакетов) не увеличиваются.
Шаг 6. Снова переведите устройство CSU/DSU в режим локальной петли обратной связи. Этот шаг должен привести к тому, что количество пакетов поддержки соединения начнет увеличиваться. В частности, через каждые 10 секунд должно увеличиваться количество пакетов поддержки соединения типа mineseen и yourseen. Эта информация появится в выводе команды debug serial interface. Если количество пакетов поддержки соединения не увеличивается, то может иметь место нарушение синхронизации в интерфейсной плате или в сети (см. выше раздел “Устранение нарушений синхронизации”).
Шаг 7. Проверьте аппаратные средства локального маршрутизатора и устройства CSU/DSU, а также все подключенные кабели. Убедитесь в том, что длина кабелей не превышает допустимое значение (15,24 м или 7,62 м для канала Т1). Проверьте, подключены ли кабели к соответствующим портам. В случае необходимости замените неисправное оборудование.
На рис. 15.10 показан вывод команды debug serial interface для последовательного соединения HDLC, в котором потеря тестовых пакетов (пакетов поддержки соединения) привела к переходу канала в нерабочее состояние и сбросу интерфейса.
router# debug aerial Interface
1 пропущенный тестовый пакет
3 пропущенных тестовых пакета
Seriall: HDLC myseq 636119, mineseen 636119, Seriall; HDLC myseq 6.36120, mineseen 636120, Seriall: HDLC myseq 636121, mineseen 636121, Seriall: HDLC myseq 636122, mineseen 636122, Seriall; HDLC myseq 636123, mineseen 6.36123, Seriall: HDLC myseq 636124. mineseen 636124, Seriall: HDLC myseq 636125, mineseen 636125, Seriall: HDLC myseq 636126, mineseen 636126,
Seria1 ±T*SiGLC myseq 636127, mineseen 636127, Seriall; HDLC^myseq 636128, mineseen 636127, Seriall; HDLC myseq 636129, mineseen 636129,
Seriall; HDLC myseq 636130, mineseen 636130,
yourseen 515032, line up yourseen 515033, line up yourseen 515034, line up
yourseen 515035, line up
yourseen 515036. line up
yourseen 515037, line up yourseen 515038, line up yourseen 515039, line up
yourseen 515040, line up
yourseen 515041, line up
yourseen 515042, line up Канал
разрывается,
yourseen 515043, line up ИНТврфеЙС
Seriall; HDLC myseq 636131, mineseen 636130, Seriall; HDLC myseq 636132, mineseen 636130, Seriall: HDLC myseq 63613.3, mineseen 636130,
yourseen 515044, line up сбраСЫВавТСЯ
yourseen 515045, line up
yourseen 515046, lline down
Рис. 15.10. Вывод команды debug serial interface
Методы проверки CSU и DSU с помощью удаленной петли обратной связи в каналах HDLC или РРР
Если обнаружено, что локальные аппаратные средства функционируют должным образом, но при попытках установить соединение через последовательный канал все еще обнаруживаются проблемы, попытайтесь выполнить проверку с помощью удаленной петли обратной связи для выявления причин проблемы.
Примечание
Предпосылками успешного проведения такой проверки с помощью удаленной петли обратной связи является использование инкапсуляции HDLC и проведение предыдущей проверки с помощью локальной петли обратной связи непосредственно перед данной проверкой.
Ниже перечислены этапы, необходимые для проведения проверки с помощью удаленной петли обратной связи.
Шаг 1. Переведите удаленное устройство CSU/DSU в режим удаленной петли обратной связи (обратитесь к документации поставщика).
Шаг 2. Вызовите на выполнение exec-команду show interfaces serial, чтобы определить, остался ли протокол канала передачи данных в рабочем состоянии, при котором в строке состояния указано "Serial х is up, line protocol is up (looped)" (последовательный канал x функционирует, протокол канала передачи данных функционирует, но переведен в режим использования петли обратной связи), или остановлен, на что указывает сообщение в строке состояния "line protocol is down".
Шаг 3. Если протокол канала передачи данных остался в рабочем состоянии (и переведен в режим использования петли обратной связи), то можно предположить,
что неисправность имеет место на удаленном конце последовательного соединения (между удаленным устройством CSU/DSU и удаленным маршрутизатором). Чтобы выявить причину неисправности, проверьте и локальное оборудование, и оборудование на удаленном конце канала.
Шаг 4. Если после активизации режима удаленной петли обратной связи в строке состояния появляется сообщение "line protocol is down", убедитесь в том, что поддержка плотности единичных импульсов осуществляется должным образом. Устройство CSU/DSU должно быть настроено на использование таких же схем фреймирования и кодирования, как и в арендованном канале или в другой службе оператора связи (например, ESF и B8ZS).
Шаг 5. Если нарушение в работе не удалось устранить описанным выше способом, обратитесь к администратору распределенной сети или к представителю организации, обслуживающей распределенную сеть.
Подробные сведения о команде show interfaces serial
В настоящем разделе рассматриваются параметры команды show interfaces serial, описана синтаксическая структура, приведены примеры вывода и описаны поля в выводе команды.
Команда show interfaces serial
Привилегированная exec-команда show interfaces serial применяется для получения информации о последовательном интерфейсе:
show interfaces serial [number] [accounting];
show interfaces serial [number [: channel -group] [accounting] (для маршрутизаторов ряда Cisco 4000);
show interfaces serial [slot | port [:channel-group]] [accounting] (для маршрутизаторов ряда Cisco 7500);
show interfaces serial [type slot | port-adapter | port] [serial] (для портов плат универсального интерфейсного процессора маршрутизаторов ряда Cisco 7500);
show interfaces serial [type slot | port-adapter | port] [:tl-channel] [accounting | crb] (для портов процессора CT3IP (Channelized T3 Interface Processor — многоканальный интерфейсный процессор ТЗ) маршрутизаторов ряда Cisco 7500).
Описание синтаксиса
number. (Необязательный параметр.) Номер порта.
accounting. (Необязательный параметр.) Показывает количество пакетов протокола каждого типа, которые были отправлены через интерфейс.
: channel-group. (Необязательный параметр.) При вызове команды на выполнение в устройстве ряда Cisco 4000 с модулем NPM (или ряда Cisco 7500 с про-
цессором MIP) показывает номер группы каналов Т1 в диапазоне от 0 до 23, определенный командой конфигурации контроллера channel-group.
slot. Номер гнезда. Для получения информации о номере гнезда обратитесь к соответствующему руководству по аппаратным средствам.
port. Номер порта. Для получения информации о номере порта обратитесь к соответствующему руководству по аппаратным средствам.
port-adapter. Адаптер порта. Для получения информации о совместимости адаптера порта обратитесь к соответствующему руководству по аппаратным средствам.
itl-channel. (Необязательный параметр.) Номер канала Т1. В маршрутизаторе с процессором CT3IP в качестве этого параметра может быть указан номер от 1 до 28. Каналы Т1 в маршрутизаторе CT3IP обозначаются числами от 1 до 28, а не с помощью более традиционного способа нумерации с отсчетом от нуля (т.е. от О до 27), предусмотренного в других изделиях Cisco. Дело в том, что такой способ обозначения позволяет обеспечить совместимость со схемами нумерации каналов Т1 в многоканальном оборудовании ТЗ, которые применяются телефонными компаниями.
crb. (Необязательный параметр.) Отображает информацию о маршрутизации и установлении мостовых соединений в интерфейсе.
Командный режим
Предусматривает применение привилегированной ехес-команды.
Рекомендации по использованию
Эта команда впервые появилась в программном обеспечении Cisco IOS 10.0 для устройств ряда Cisco 4000. В программном обеспечении для ряда Cisco 7000 она впервые появилась в версии Cisco IOS 11.0, а начиная с версии Cisco IOS 11.3 в эту команду была включена поддержка CT3IP.
Примеры вывода
Ниже приведен пример вывода команды show interfaces для синхронного последовательного интерфейса.
Router# show interfaces serial
Serial 0 is up, line protocol is up
Hardware is MCI Serial
Internet address is 150.136.190.203, subnet mask is 255.255.255.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 0:00:07, output 0:00:00, output hang never
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
Five minute input rate 0 bits/sec, 0 packets/sec
Five minute output rate 0 bits/sec, 0 packets/sec
16263 packets input, 1347238 bytes, 0 no buffer
Received 13983 broadcasts, 0 runts, 0 giants
2 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
carrier transitions
22146 packets output, 2383680 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets, 0 restarts
В табл. 15.9 описаны наиболее важные поля в выводе команды.
; Таблица 15.9. Описания полей в выводе команды show interfaces serial I
ПолеОписание
Serial...is {up |
Указывает, являются ли в настоящее время аппаратные средства
down}...is
интерфейса активными (есть ли сигнал обнаружения несущей),
administratively down
или интерфейс был остановлен администратором
line protocol is {up |
Указывает, имеют ли программные процессы, которые отрабаты-
down}
вают протокол канала связи, информацию о том, что интерфейс пригоден для использования (т.е. успешно ли передаются пакеты поддержки соединения) или был остановлен администратором
Hardware is
Указывает тип аппаратных средств
Internet address is
Указывает адрес Internet, за которым следует маска подсети
MTU
Предоставляет данные о величине максимальной единицы передачи данных в сети для рассматриваемого интерфейса
BW
Указывает значение параметра bandwidth, заданного в составе конфигурации интерфейса (в килобитах в секунду). Параметр bandwidth применяется только для вычисления метрик IGRP. Если интерфейс подключен к последовательному каналу с пропускной способностью, которая отличается от предусмотренной по умолчанию (1536 или 1544 для канала Т1 и 56 для стандартного синхронного последовательного канала), то для указания действительной пропускной способности этого последовательного канала применяется команда bandwidth
DLY
Предоставляет данные о задержке интерфейса в микросекундах
rely
Показывает относительную надежность интерфейса в виде числителя дроби со знаменателем 255 (где 255/255 соответствует 100%-ной надежности), рассчитанную как экспоненциальное среднее за время, превышающее 5 минут
load
Показывает относительную нагрузку на интерфейс в виде числителя дроби со знаменателем 255 (где 255/255 соответствует полностью загруженному интерфейсу), рассчитанную как экспоненциальное среднее за время, превышающее 5 минут
Encapsulation
Указывает метод инкапсуляции, применяемый в интерфейсе
loopback
Указывает, установлена ли петля обратной связи
keepalive
Указывает, применяются ли средства поддержки соединения
Last input
Предоставляет данные о количестве часов, минут и секунд, прошедших с момента успешного получения интерфейсом последнего пакета. Эти данные позволяют определить, когда произошел отказ интерфейса, который в данный момент является неисправным
Last output
Предоставляет данные о количестве часов, минут и секунд, прошедших с момента успешной передачи интерфейсом последнего пакета
Попе
Описание
output hang
Предоставляет данные о количестве часов, минут и секунд (или содержит значение never — никогда), прошедших с того момента, когда интерфейс был последний раз сброшен в связи с тем, что передача данных потребовала слишком много времени. Если количество часов в любом из “последних” полей превышает 24 часа, отображается число суток и часов. При переполнении значения в этом поле отображаются символы звездочек
Output queue, drops input queue, drops
В этих полях представлены данные о количестве пакетов в выходных и во входных очередях. За каждым числом следуют косая черта, значение максимального размера очереди и данные о количестве пакетов, уничтоженных в связи с переполнением очереди
5 minute input rate
5 minute output rate
В этих полях приведены данные о среднем числе битов и пакетов, переданных и принятых в секунду за последние пять минут.
Значения средней скорости приема и передачи за последние пять минут должны использоваться только в качестве приближенной оценки интенсивности трафика, измеренной в секунду в течение данного пятиминутного периода. Эти значения скорости представляют собой экспоненциальные взвешенные средние, при вычислении которых применялась постоянная времени, равная пяти минутам. Должен пройти период, равный учетверенному значению постоянной времени, прежде чем среднее значение установится в пределах 2% мгновенной скорости однородного потока трафика за этот период
packets input
Предоставляет информацию об общем количестве пакетов, полученных системой без ошибок
bytes
Предоставляет информацию об общем количестве байтов, включая данные и информацию инкапсуляции МАС, в пакетах, полученных системой без ошибок
no buffer
Показывает количество полученных пакетов, которые были отвергнуты в связи с отсутствием свободного буферного пространства в основной системе. Сравните это значение со значением в поле ignored. События, связанные с отсутствием свободных входных буферов, часто возникают при лавинообразном увеличении количества широковещательных пакетов в сетях Ethernet и появлении пакетов ошибок в последовательных линиях
Received...broadcasts
Показывает общее количество пакетов с широковещательным или групповым адресом, принятых интерфейсом
runts
Предоставляет информацию об общем количестве пакетов, которые были отвергнуты в связи с тем, что имели размер меньше минимально допустимого в данной передающей среде
Giants
Предоставляет данные о количестве пакетов, которые были отвергнуты в связи с тем, что имели размер больше максимально допустимого в данной передающей среде
input errors
Содержит данные об общем количестве ошибок, включая данные, приведенные в полях no buffer, runts, giants, CRC, frame, overrun, ignored и abort. В значение, представленное в поле input errors, могут также входить данные о других ошибках, обнаруженных при приеме дейтаграмм, а некоторые дейтаграммы могут иметь несколько ошибок, поэтому значение в этом поле может не совпадать с суммой значений в указанных полях
Поле
Описание
CRC
Значение счетчика CRC увеличивается, если станция-отправитель или устройство на дальнем конце канала обнаруживает, что код CRC, вычисленный по полученным данным, не совпадает с кодом CRC, содержащимся в отправленных данных. В последовательном канале ненулевое значение в поле CRC обычно указывает на наличие шума, скачков коэффициента усиления или других нарушений в процессе передачи данных по каналу
frame
Количество неправильно принятых пакетов, которые имеют ошибки CRC и нецелое количество октетов. В последовательном канале ненулевое значение этого показателя обычно является результатом воздействия шума или нарушений в процессе передачи данных
overrun
Показывает количество случаев, когда аппаратные средства последовательного приемного устройства не были способны передать полученные данные в аппаратный буфер, поскольку скорость ввода данных превысила способность приемного устройства обрабатывать данные
ignored
Показывает количество полученных пакетов, которые были проигнорированы интерфейсом из-за отсутствия свободных внутренних буферов в аппаратном обеспечении интерфейса. Увеличение значения в поле ignored может быть вызвано лавинообразным возрастанием количества широковещательных пакетов или появлением пакетов ошибок
abort
Указывает на появление недопустимой последовательности битов 1 в последовательном интерфейсе. Это обычно свидетельствует о нарушении синхронизации между последовательным интерфейсом и оборудованием канала связи
carrier transitions
Показывает количество случаев, когда изменилось состояние сигнала обнаружения несущей в последовательном интерфейсе. Например, если сигнал DCD (Data and Carrier Detect — сигнал обнаружения данных и несущей) исчезает, а затем снова появляется, то значение счетчика перехода на другую несущую увеличивается на два. Если сигнал обнаружения несущей часто меняет свое состояние, это указывает на нарушение в работе модема или канала
packets output
Предоставляет информацию об общем количестве сообщений, переданных системой
bytes output
Предоставляет информацию об общем количестве байтов, включая данные и информацию инкапсуляции МАС, в пакетах, переданных системой
underruns
Предоставляет информацию о количестве случаев, когда отправка данных передатчиком выполнялась быстрее, чем ее мог обработать маршрутизатор. В интерфейсах некоторых типов информация о таких случаях может не предоставляться
output errors
Предоставляет информацию об общем количестве ошибок, которые исключили возможность выполнить окончательную передачу дейтаграмм из рассматриваемого интерфейса. Следует отметить, что это значение может не совпадать с суммой подсчитанных ошибок вывода, поскольку некоторые дейтаграммы могут иметь несколько ошибок, а другие — содержать ошибки, не попадающие ни в одну из конкретных рассматриваемых категорий
Поле
Описание
collisions
Предоставляет информацию о количестве сообщений, повторно переданных из-за коллизий в сети Ethernet. Обычно причиной коллизий является расширение размеров локальной сети сверх допустимых (слишком длинный кабель Ethernet или кабель трансивера, наличие больше двух повторителей между станциями или слишком большое количество каскадно включенных многопортовых трансиверов). Определенное количество коллизий возникает и в нормально функционирующей сети. Но если относительное количество коллизий увеличивается примерно до 4-5%, то необходимо убедиться в отсутствии неисправного оборудования в сегменте или рассмотреть возможность перемещения некоторых существующих станций в другой сегмент. Пакет, повторно переданный после возникновения коллизии, регистрируется в поле packets output только один раз
interface resets
Предоставляет информацию о количестве случаев полного сброса интерфейса. Такие ситуации возникают, если пакеты, поставленные в очередь для передачи, не передаются в течение нескольких секунд. В последовательном канале это может быть вызвано сбоем в работе модема, при котором не передается сигнал синхронизации передачи transmit clock, или неисправностью кабеля. Если система обнаруживает, что сигнал обнаружения несущей последовательного интерфейса активен, а протокол линии передачи данных не функционирует, то периодически сбрасывает интерфейс в целях его перезапуска. Случаи сброса интерфейса могут также возникать, если интерфейс подключен к петле обратной связи или остановлен ,
restarts
Предоставляет информацию о количестве случаев перезапуска контроллера из-за ошибок
alarm indications, remote alarms, rx LOF, rx LOS
В этих полях содержатся данные о количестве активизированных аварийных сигналов CSU/DSU, а также о количестве случаев потери фрейма и потери сигнала во время приема
BER inactive, NELR inactive, FELR inactive
Эти поля показывают состояния счетчиков BER (Bit Error Rate — частота появления ошибочных битов), NELR (Near-End Loop Remote — применение команды loop remote на ближнем конце) и FELR (Far-End Loop Remote — применение команды loop remote на дальнем конце), соответствующих спецификации G.7O3-E1. Пользователь должен иметь в виду, что он не имеет возможности установить другое состояние счетчика NELR или FELR
Устранение нарушений в работе канала Т1
В настоящем разделе рассматриваются методы и процедуры устранения нарушений в работе каналов Т1, эксплуатируемых в режиме входящих коммутируемых соединений.
Поиск неисправностей с помощью команды show controller t1
С помощью exec-команды show controller tl может быть получена информация, необходимая для применения процедуры устранения нарушений в работе физиче-
ского и канального уровней. В этом разделе показано, как применить процедуру поиска неисправностей с помощью команды show controller tl.
Эта команда отображает информацию о состоянии контроллера с учетом особенностей аппаратных средств конкретного контроллера. Информация, приведенная в выводе этой команды, в основном предназначена для выполнения задач диагностики персоналом службы технической поддержки.
Устройство NPM или MIP может опрашивать адаптеры порта для определения их текущего состояния. Для получения статистических данных о работе канала Т1 вызовите на выполнение команду show controller tl.
Если в качестве параметров команды заданы номера гнезда и порта, то отображаются статистические данные за каждый 15-минутный период.
Появление ошибок в канале Т1 чаще всего бывает вызвано применением неправильной конфигурации канала. Убедитесь в том, что такие параметры, как способ фреймирования и кодирования в канале, а также источник синхроимпульсов, заданы в конфигурации в соответствии с рекомендациями оператора связи.
Состояния контроллера в выводе команды show controller И
Контроллер Tl может находиться в одном из трех состояний:
остановлен администратором;
не функционирует;
функционирует.
Контроллер остановлен администратором
Контроллер считается остановленным администратором, если он остановлен вручную. Для исправления этой ошибки необходимо перезапустить контроллер.
Шаг 1. Перейдите в режим enable.
maui-nas-03> en
Password:
maui-nas-03t
Шаг 2. Перейдите в режим ввода глобальных команд конфигурации.
maui-nas-03# configure terminal
Enter configuration commands, one per line. End with CNTL/Z. maui-nas-03(config)I
Шаг 3. Перейдите в режим настройки конфигурации контроллера.
maui-nas-03(config)t controller tl О
maui-nas-03(config-controlle)#
Шаг 4. Перезапустите контроллер.
maui-nas-03(config-controlle)I shutdown
maui-nas-03(config-controlle)t no shutdown
Канал не функционирует
Если контроллер Т1 и канал не функционируют, проверьте, есть ли в выводе ехес- команды show controller tl одно из следующих сообщений:
Receiver has loss of frame.
или
Receiver has loss of signal.
Потеря фрейма в приемной аппаратуре
Шаг 1. Проверьте, совпадает ли формат фреймирования, заданный в конфигурации порта, с форматом фреймирования канала. Формат фреймирования контроллера можно проверить, изучив текущую конфигурацию или вывод команды show controller tl.
Для изменения формата фреймирования вызовите на выполнение команду framing {SF | ESF} в режиме настройки конфигурации контроллера, как показано ниже. maui-nas-03t configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
maui-nas-03(config)I Controller tl 0
maui-nas-03(config-controlle)I framing esf
Шаг 2. Попытайтесь применить другой формат фреймирования, чтобы проверить, станет ли равным нулю содержимое поля, в котором регистрируется количество случаев аварийного завершения передачи.
Шаг 3. Откорректируйте параметр LBO с помощью команды cablelength {long | short}.
Параметр LBO позволяет учесть необходимость компенсации затухания сигнала в зависимости от расстояния между рассматриваемым устройством и первым повторителем в канале. При большом расстоянии от устройства до повторителя необходимо усиливать сигнал в канале для компенсации затухания, которое увеличивается с расстоянием.
Для настройки коэффициентов усиления приемной и передающей аппаратуры в магистральном канале Т1 с интерфейсом CSU и длиной кабеля свыше 200 м (канал рассматривается как длинный) применяется команда конфигурации контроллера cablelength long. Для настройки аппаратуры с учетом затухания в магистральном канале Т1 с интерфейсом DSX-1 и длиной кабеля меньше 200 м (канал рассматривается как короткий) применяется команда конфигурации контроллера cablelength short.
Для получения дополнительной информации о настройке параметра LBO обратитесь к провайдеру служб и ознакомьтесь со справочником команд Cisco IOS.
Если приведенные выше действия не позволяют устранить нарушения в работе, перейдите к следующему разделу.
Потеря сигнала в приемной аппаратуре
Шаг 1. Убедитесь в том, что кабель между портом интерфейса и оборудованием провайдера службы Т1 или терминальным оборудованием Т1 подключен правильно. Проверьте, подключен ли кабель к соответствующим портам. В случае необходимости исправьте кабельные соединения.
Шаг 2. Проверьте целостность кабеля. Определите, нет ли в кабеле обрывов или других физических дефектов. Убедитесь в том, что контакты разъемов находятся в хорошем состоянии. В случае необходимости замените кабель.
Шаг 3. Проверьте разъемы кабелей. Если пары передающих и приемных проводников переставлены местами или пары приемных проводников разомкнуты, то могут возникнуть ошибки. Подключите пару приемных проводников к контактам 1 и 2; пара передающих проводников должна быть подключена к контактам 4 и 5. Контакты в разъеме RJ-45 пронумерованы последовательно от 1 до 8. Номер 1 имеет самый левый контакт вилки, повернутой к наблюдателю (рис. 15.11).
Соединитель RJ-45
Рис. 15.11. Розетка и вилка разъема RJ-45
Шаг 4. Попытайтесь применить кабель с обратным расположением выводов.
Вызывайте на выполнение exec-команду show controller tl после выполнения каждого этапа, чтобы определить, продолжает ли появляться информация об ошибках контроллера в выводе этой команды.
Канал находится в режиме использования петли обратной связи
По результатам выполнения команды show controller tl проверьте, находится ли канал в режиме петли обратной связи. Канал должен находиться в режиме петли обратной связи только при выполнении проверок.
Для выхода из режима петли обратной связи необходимо вызвать на выполнение команду no loopback в режиме настройки конфигурации контроллера, как показано ниже.
maui-nas-О3(config-controlle)Ino loopback
Контроллер выводит аварийные сигналы
По результатам выполнения команды show controller проверьте, выводит ли контроллер аварийные сигналы.
Ниже описаны различные аварийные сигналы и представлены процедуры, необходимые для их устранения.
Получен сигнал AIS (синий аварийный сигнал)
Наличие в поле Rx (сокращение от receive) сообщения о получении сигнала AIS (Alarm Indication Signal — предупреждение об обнаружении ошибки) означает, что в канале, который следует за оборудованием, подключенным к рассматриваемому порту, возник аварийный сигнал. Если на вход поступил сигнал AIS о неисправности и продолжает действовать после регистрации отказа LOF (Loss Of Frame — потеря фрейма), вызванного тем, что сигнал, состоящий из одних единиц, по сути является нефреймированным, т.е. не оформ-
ленным в виде фрейма, то регистрируется отказ AIS. Состояние отказа A1S отменяется после отмены состояния отказа в связи с потерей фрейма.
Шаг 1. Проверьте, совпадает ли формат фреймирования, указанный в конфигурации порта, с форматом фреймирования канала. Если форматы не совпадают, измените формат фреймирования в контроллере в соответствии с форматом канала.
Шаг 2. Обратитесь к провайдеру служб, чтобы проверить, нет ли ошибок в конфигурации телефонной сети.
Получен сигнал RAI (желтый аварийный сигнал)
Получение сигнала RAI (Remote Alarm Indication — дистанционная индикация аварийного сигнала) свидетельствует о том, что в оборудовании на дальнем конце канала возникла проблема, обусловленная получением аварийного сигнала от предшествующего ему оборудования.
В каналах с форматом фреймирования SF отказ в связи с активизацией аварийного сигнала на дальнем конце регистрируется, если бит 6 во всех подканалах остается равным нулю, по меньшей мере, в течение 335 мс. Состояние отказа отменяется, если бит 6 хотя бы в одном подканале остается отличным от нуля в течение периода, который обычно не превышает 1 с и всегда меньше 5 с. Отказ в связи с активизацией аварийного сигнала на дальнем конце в каналах SF не регистрируется, если обнаружена потеря сигнала.
В каналах с форматом фреймирования ESF отказ в связи с активизацией аварийного сигнала на дальнем конце регистрируется, если, по меньшей мере, в семи из десяти непрерывных 16-битовых интервалов шаблона обнаруживается шаблон желтого аварийного сигнала. Состояние отказа отменяется, если шаблон желтого аварийного сигнала не встречается в десяти непрерывных 16-битовых интервалах шаблона.
Шаг 1. Подключите к порту разъем с внешней петлей обратной связи. Для получения информации о том, как подготовить разъем с петлей обратной связи, обратитесь к разделу “Применение разъема с петлей обратной связи для проверки аппаратных средств”, приведенному ниже в этой главе.
Шаг 2. Выясните, появились ли какие-либо аварийные сигналы. Если никаких аварийных сигналов не обнаружено, это означает, что, по всей вероятности, локальные аппаратные средства находятся в хорошем состоянии. В таком случае выполните следующие действия.
Проверьте кабельную разводку. Для получения дополнительной информации обратитесь к разделу “Потеря сигнала в приемной аппаратуре".
Проверьте параметры оборудования на удаленном конце канала и убедитесь в том, что они соответствуют параметрам рассматриваемого порта.
Если описанные выше действия не позволяют устранить нарушения в работе, обратитесь к провайдеру служб.
Шаг 3. Снимите разъем с петлей обратной связи и снова подключите разъем канала ТЕ
Шаг 4. Проверьте кабельную разводку. Для получения дополнительной информации обратитесь к разделу “Потеря сигнала в приемной аппаратуре”.
Шаг 5. Выключите, а затем снова включите маршрутизатор.
Шаг 6. Подключите разъем канала Т1 к другому порту. Введите в конфигурацию этого порта такие же параметры, как и в канале. Если в результате этого удается устранить нарушение в работе, то причиной неисправности является рассматриваемый порт. В таком случае выполните следующие действия.
Снова подключите канал Т1 к первоначальному порту.
Выполните инструкции раздела “Устранение нарушений в работе, указанных в сообщениях об ошибках”, приведенного ниже в этой главе.
Если описанные действия не позволяют устранить нарушение в работе, то выполните следующее.
Проверьте аппаратные средства с помощью петли обратной связи, как описано в разделе “Применение разъема с петлей обратной связи для проверки аппаратных средств”.
Замените плату контроллера ТЕ
Перейдите к следующему разделу, “Устранение нарушений в работе, указанных в сообщениях об ошибках”.
Передатчик отправляет удаленный аварийный
сигнал (красный)
Красный аварийный сигнал активизируется, если устройство CSU не может войти в режим синхронизации при использовании в канале Т1 текущего формата фрейми- рования.
Шаг 1. Проверьте, совпадает ли формат фреймирования, заданный в конфигурации порта, с форматом фреймирования канала. В противном случае измените формат фреймирования в контроллере, чтобы он стал таким же, как в канале.
Шаг 2. Проверьте параметры настройки оборудования, установленного на удаленном конце канала, и определите, соответствуют ли они параметрам настройки порта.
Шаг 3. Обратитесь за консультацией к провайдеру служб.
Передан сигнал RAI (желтый аварийный сигнал)
Если в интерфейсе передан сигнал RAI, это означает, что в интерфейсе возникли нарушения в работе при обработке сигнала, полученного от оборудования, находящегося на дальнем конце канала.
Шаг 1. Проверьте параметры настройки оборудования, установленного на удаленном конце канала, и определите, соответствуют ли они параметрам настройки порта.
Шаг 2. Сигнал Тх RAI должен сопровождаться каким-то другим аварийный сигналом, который уточняет характер нарушения в работе порта/платы Т1, возникшего при обработке сигнала, полученного от оборудования, находящегося на удаленном конце канала.
Для исправления ситуации, возникшей после получения сигнала Тх RAI, необходимо вначале устранить неисправность, на которую указывает другой аварийный сигнал.
Передан сигнал AIS (синий аварийный сигнал)
Шаг 1. Проверьте, совпадает ли формат фреймирования, заданный в конфигурации порта, с форматом фреймирования канала. Если эти форматы не совпадают, устраните несоответствие.
Шаг 2. Выключите, а затем снова включите маршрутизатор.
Шаг 3. Подключите разъем канала Т1 к другому порту. Введите в конфигурацию этого порта такие же параметры, как и в канале.
Если описанные выше действия не позволяют устранить нарушение в работе, то выполните следующее.
Проверьте аппаратные средства с помощью разъема с петлей обратной связи, как описано в разделе “Применение разъема с петлей обратной связи для проверки аппаратных средств”.
Замените плату контроллера ТЕ
Перейдите к разделу “Устранение нарушений в работе, указанных в сообщениях об ошибках”.
Устранение нарушений в работе, указанных в сообщениях об ошибках
Вывод exec-команды show controller tl может содержать сообщения об ошибках, которые позволяют диагностировать и устранять нарушения в работе. Ниже описаны некоторые сообщения об ошибках и показано, как устранить указанные в них ошибки.
Чтобы определить, увеличиваются ли показания счетчиков ошибок, несколько раз подряд вызовите на выполнение команду show controller tl. Отметьте, какие значения имели эти счетчики первоначально.
Получите у провайдера служб информацию о применяемых им параметрах фреймирования и кодирования канала. Как правило, формат фреймирования ESF применяется с форматом кодирования B8ZS, а формат фреймирования SF — с форматом кодирования АМЕ
Увеличиваются показания счетчика Slip Secs
Увеличение количества пропущенных секунд в поле Slip Secs указывает на наличие проблемы синхронизации в канале ТЕ Провайдер канала Т1 (телефонная компания) предоставляет синхронизирующий сигнал, по которому должна синхронизироваться аппаратура, установленная в помещении пользователя (CPE — Customer Premises Equipment).
Шаг 1. Убедитесь в том, что источником синхронизации является синхронизирующий сигнал, полученный из сети. Об этом свидетельствует наличие в выводе команды строки с указанием, что источником синхронизации является первичный канал: "Clock Source Is Line Primary".
Примечание. Если к серверу доступа подключено несколько каналов Т1, только один из них может быть первичным; все прочие каналы Т1 должны получать синхронизирующий сигнал от первичного канала. В таком случае про-
верьте, что канал Т1, который определен как первичный источник синхронизации, имеет правильную конфигурацию.
Шаг 2. Откорректируйте конфигурацию источника синхроимпульсов Т1 в режиме настройки конфигурации контроллера.
maui-nas-03{config-controlle)# clock source line primary
Увеличиваются показания счетчика Framing Loss Seconds
Шаг 1. Проверьте, совпадает ли формат фреймирования, заданный в конфигурации порта, с форматом фреймирования канала. Чтобы определить, какой формат фреймирования задан в конфигурации порта, найдите строку "Framing is {ESF|SF}" в выводе команды show controller tl.
Шаг 2. В случае необходимости измените формат фреймирования; для этого необходимо вызвать на выполнение команду framing {SF | ESF} в режиме настройки конфигурации контроллера.
maui-nas-03{config-controlle)# framing esf
Шаг 3. Откорректируйте значение параметра LBO с помощью команды cablelength {long | short}.
Для получения дополнительной информации о настройке параметра LBO обратитесь к провайдеру служб и ознакомьтесь со справочником команд Cisco 1OS.
Увеличиваются показания счетчика Line Code Violations
Шаг 1. Проверьте, совпадает ли формат кодирования, заданный в конфигурации порта, с форматом кодирования канала. Чтобы определить, какой формат кодирования задан в конфигурации порта, найдите строку "Line Code is {B8ZS jAMI}" в выводе команды show controller tl.
Шаг 2. В случае необходимости измените формат кодирования; для этого следует вызвать на выполнение команду linecode {ami | b8zs} в режиме настройки конфигурации контроллера.
maui-nas-03{config-controlle)# linecode b8zs
Шаг 3. Откорректируйте значение параметра LBO с помощью команды cablelength {long | short}.
Для получения дополнительной информации о настройке параметра LBO обратитесь к провайдеру служб и ознакомьтесь со справочником команд Cisco IOS.
Проверка параметров isdn switchtype и pri-group
Вызовите на выполнение команду show running-config, чтобы проверить, правильно ли заданы в конфигурации значения параметров isdn switchtype и prigroup timeslots. Для получения правильных значений параметров обратитесь к провайдеру служб.
Чтобы откорректировать значения параметров isdn switchtype и pri-group, введите следующие строки:
maui-nas-03# configure terminal
maui-nas-03(config)# isdn switch-type primary-5ess
maui-nas-03(config)# controller tl 0
maui-nas-03(config-controlle)# pri-group timeslots 1-24
Проверка канала передачи сигналов
Если показания счетчиков ошибок не увеличиваются, а неисправность устранить не удается, убедитесь в том, что канал передачи сигналов функционирует и его конфигурация настроена правильно.
Шаг 1. Вызовите на выполнение команду show interface serial х:23, указав вместо х номер интерфейса.
Шаг 2. Проверьте, функционирует ли интерфейс. Если интерфейс не находится в рабочем состоянии, вызовите на выполнение команду no shutdown, чтобы активизировать интерфейс.
maui-nas-03# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
maui-nas-03(config)# interface serial 0:23 maui-nas-03(config-if)# no shutdown
Шаг 3. Убедитесь в том, что применяется инкапсуляция пакетов протокола РРР. Если это условие не соблюдается, примените команду encapsulation ppp в режиме конфигурации интерфейса, чтобы исправить эту ошибку: maui-nas-03(config-if)# encapsulation ppp
Шаг 4. Определите, установлена ли петля обратной связи. Петля обратной связи должна быть установлена только временно, в целях проверки. Для удаления петли обратной связи воспользуйтесь командой no loopback.
maui-nas-03(config-if)# по loopback
Шаг 5. Выключите, а затем снова включите маршрутизатор.
Шаг 6. Если описанные выше действия не позволяют устранить нарушения в работе, обратитесь к провайдеру служб или в центр Cisco ТАС.
Устранение нарушений в работе интерфейса PRI
В процессе устранения нарушений в работе интерфейса PR1 необходимо проверить оборудование на обоих концах канала Т1, чтобы определить, исправно ли функционирует канал.
Поиск неисправностей с использованием команды show isdn status
Команда show isdn status позволяет получить сведения о текущем состоянии всех интерфейсов ISDN. Она отображает состояние протоколов уровней 1, 2 и 3.
Шаг 1. Проверьте, активен ли протокол уровня 1.
В информации о состоянии протокола уровня 1 должно всегда быть указано ACTIVE, при условии, что канал Т1 не находится в нерабочем состоянии.
Если в выводе команды show isdn status указано, что протокол уровня находится в состоянии DEACTIVATED, это означает, что нарушена физическая связь с каналом Т1 (см. раздел “Контроллер остановлен администратором”).
Проверьте также, не переведен ли канал Т1 в нерабочее состояние администратором. Для активизации контроллера Т1 воспользуйтесь командой по shutdown.
Шаг 2. Убедитесь в том, что протокол уровня 2 находится в состоянии MULTIPLE_FRAME_ESTABLISHED.
Состояние MULTIPLE_FRAME_ESTABLISHED протокола уровня 2 является нормальным. Сообщение о том, что протокол находится в этом состоянии, указывает, что инициализация протокола уровня 2 закончилась и происходит обмен фреймами уровня 2.
Если протокол уровня 2 не находится в состоянии MULTIPLE_FRAME_ESTABLISHED, вызовите на выполнение exec-команду show controller tl, чтобы диагностировать неисправность. Обратитесь к разделу “Поиск неисправностей с помощью команды show controller tl”.
Поскольку вывод команды show isdn status содержит сведения о текущем состоянии, возможно, что протокол уровня 2 фактически переходит то в рабочее, то в нерабочее состояние, несмотря на то, что в выводе команды указано состояние MULTIPLE_FRAME ESTABLISHED. Чтобы проверить, устойчиво ли функционирует протокол уровня 2, воспользуйтесь командой debug isdn q921.
Применение команды debug isdn q921
Команда debug isdn q921 показывает, какие процедуры доступа канального уровня (уровня 2) функционируют в D-канале маршрутизатора.
В случае необходимости выполните настройку конфигурации для просмотра отладочных сообщений с использованием команды logging console или terminal monitor.
Примечание
В производственной среде следите за тем, чтобы вывод журналов на консоль был заблокирован. Введите команду show logging. Если разрешено ведение журналов, работа сервера доступа может время от времени приостанавливаться из-за перегрузки порта консоли, в который поступает слишком интенсивный поток журнальных сообщений. Введите команду no logging console.
Примечание
Если разрешено применение команды debug isdn q921, но это не приводит к получению отладочной информации, активизируйте исходящий вызов или выполните сброс контроллера, чтобы получить отладочный вывод.
Шаг 1. Убедитесь в том, что протокол уровня 2 работает стабильно. Проконтролируйте отсутствие в выводе команды debug сообщений, указывающих на то, что служба доступа по протоколу уровня 2 попеременно переходит то в рабочее, то в нерабочее состояние. Если в выводе отладочной команды обнаруживаются примерно такие строки, это означает, что канал функционирует нестабильно:
Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface SeO:23, TEI 0 changed to down
Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface SerialO:23, changed state to down
Mar 20 10:06:21.274: SDSX1-6-CLOCK CHANGE: Controller 0 clock is now selected as clock source
Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface SeO:23, TEI 0 changed to up
Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller T1 0, changed state to up
Mar 20 10:06:24.494: SLINK-3-UPDOWN: Interface SerialO:23, changed state to up
Если есть основания полагать, что протокол уровня 2 работает нестабильно, обратитесь к разделу “Устранение нарушений в работе, указанных в сообщениях об ошибках”.
Шаг 2. Убедитесь в том, что со стороныШаг 2. Убедитесь в том, что со стороныотправителя (ТХ) и получателя (RX) наблюотправителя (ТХ) и получателя (RX) наблюдаются только сообщения SAPI.даются только сообщения SAPI.
Шаг 2. Убедитесь в том, что со стороны
Шаг 2. Убедитесь в том, что со стороны
отправителя (ТХ) и получателя (RX) наблю
отправителя (ТХ) и получателя (RX) наблю
даются только сообщения SAPI.
даются только сообщения SAPI.
Маг 2010:06:52.505:ISDNSeO:23:ТХ->Маг 2010:06:52.505:ISDNSeO:23:RX<Mar 2010:07:22.505:ISDNSeO:23:TX->Mar 2010:07:22.509:ISDNSeO:23:RX<Mar 2010:07:22.509:ISDNSeO:23:TX->Mar 2010:07:22.509:ISDNSeO:23:RX<-Маг 2010:06:52.505:ISDNSeO:23:ТХ->Маг 2010:06:52.505:ISDNSeO:23:RX<Mar 2010:07:22.505:ISDNSeO:23:TX->Mar 2010:07:22.509:ISDNSeO:23:RX<Mar 2010:07:22.509:ISDNSeO:23:TX->Mar 2010:07:22.509:ISDNSeO:23:RX<-RRf sapi = 0RRf sapi = 0RRp sapi = 0RRp sapi = 0RRf sapi = 0RRf sapi = 0RRf sapi = 0RRf sapi = 0RRp sapi = 0RRp sapi = 0RRf sapi = 0RRf sapi = 0tei = 0 tei = 0 tei = 0 tei = 0 tei = 0tei = 0tei = 0 tei = 0 tei = 0 tei = 0 tei = 0tei = 0nr = 0 nr = 0 nr = 0 nr = 0 nr = 0nr = 0nr = 0 nr = 0 nr = 0 nr = 0 nr = 0nr = 0
Маг 2010:06:52.505:ISDNSeO:23:ТХ->
Маг 2010:06:52.505:ISDNSeO:23:RX<
Mar 2010:07:22.505:ISDNSeO:23:TX->
Mar 2010:07:22.509:ISDNSeO:23:RX<
Mar 2010:07:22.509:ISDNSeO:23:TX->
Mar 2010:07:22.509:ISDNSeO:23:RX<-
Маг 2010:06:52.505:ISDNSeO:23:ТХ->
Маг 2010:06:52.505:ISDNSeO:23:RX<
Mar 2010:07:22.505:ISDNSeO:23:TX->
Mar 2010:07:22.509:ISDNSeO:23:RX<
Mar 2010:07:22.509:ISDNSeO:23:TX->
Mar 2010:07:22.509:ISDNSeO:23:RX<-
RRf sapi = 0
RRf sapi = 0
RRp sapi = 0
RRp sapi = 0
RRf sapi = 0
RRf sapi = 0
RRf sapi = 0
RRf sapi = 0
RRp sapi = 0
RRp sapi = 0
RRf sapi = 0
RRf sapi = 0
tei = 0 tei = 0 tei = 0 tei = 0 tei = 0
tei = 0
tei = 0 tei = 0 tei = 0 tei = 0 tei = 0
tei = 0
nr = 0 nr = 0 nr = 0 nr = 0 nr = 0
nr = 0
nr = 0 nr = 0 nr = 0 nr = 0 nr = 0
nr = 0
Шаг 3. Убедитесь в отсутствии сообщений SABME, которые указывают на то, что предпринимаются попытки повторной инициализации протокола уровня 2. Такие сообщения обычно возникают, если станция передает запросные сообщения (RRp), а коммутатор не передает на них ответ (RRf), или наоборот. Пример сообщений SABME приведен ниже.
Маг 20 10:06:21.702: ISDN SeO:23: RX <- SABMEp sapi = 0 tei = 0
Mar 20 10:06:22.494: ISDN SeO:23: TX -> SABMEp sapi =0 tei = 0
Если обнаруживаются сообщения SABME, выполните следующие действия.
Воспользуйтесь командой show running-config, чтобы проверить, правильно ли выполнена настройка параметров команд isdn switchtype и pri-group timeslots. Для определения правильных значений параметров обратитесь к провайдеру служб.
Чтобы откорректировать значения параметров isdn switchtype и pri-group, введите следующие строки:
maui-nas-03# configure terminal
maui-nas-03(config)# isdn switch-type primary-5ess
maui-nas-03(config)# controller tl 0
maui-nas-03(config-controlle)# pri-group timeslots 1-24
Шаг 4. С помощью команды show interfaces serial x:23 проверьте, функционирует ли D-канал.
Если D-канал не функционирует, вызовите на выполнение команду по shutdown для его активизации:
maui-nas-03(config)# interface serial 0:23 maui-nas-03(config-if)# no shutdown
Шаг 5. Убедитесь в том, что применяется инкапсуляция пакетов протокола РРР. Если это условие не соблюдается, примените команду encapsulation ppp для настройки параметров инкапсуляции.
maui-nas-03(config-if)# encapsulation ppp
Шаг 6. Определите, находится ли интерфейс в режиме использования петли обратной связи. В процессе нормальной работы интерфейс не должен находиться в режиме использования петли обратной связи.
maui-nas-03(config-if)# no loopback
Шаг 7. Выключите, а затем снова включите маршрутизатор.
Шаг 8. Если описанные выше действия не позволяют устранить нарушения в работе, обратитесь к провайдеру служб или в центр Cisco ТАС.
Применение разъема с петлей обратной связи для проверки аппаратных средств
Разъем с петлей обратной связи может применяться для проверки того, имеются ли какие-либо нарушения в работе маршрутизатора. Если проверка аппаратных средств маршрутизатора с применением разъема с петлей обратной связи показывает отсутствие неисправностей, это означает, что нарушение в работе канала возникло в другом месте.
Чтобы создать разъем с петлей обратной связи, выполните следующие действия.
Шаг 1. С помощью кусачек отрежьте от исправного кабеля RJ-45 или RJ-48 разъем вместе с куском кабеля длиной около 12 см.
Шаг 2. Зачистите концы проводников.
Шаг 3. Скрутите вместе проводники, подключенные к контактам 1 и 4.
Шаг 4. Скрутите вместе проводники, подключенные к контактам 2 и 5.
Прочие проводники должны остаться в прежнем виде.
Контакты в разъеме RJ-45/48 пронумерованы последовательно от 1 до 8. Номер 1 имеет самый левый контакт вилки, повернутой к наблюдателю.
Проверка с помощью разъема с петлей обратной связи
Шаг 1. Вставьте разъем Т1 в рассматриваемый порт.
Шаг 2. Запишите в память конфигурацию маршрутизатора с использованием команды write memory.
maui-nas-03# write memory
Building configuration...
[OK]
Шаг 3. В качестве метода инкапсуляции установите инкапсуляцию HDLC.
maui-nas-03# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
maui-nas-03(config)# interface serial 0
maui-nas-03(config-if)# enc
maui-nas-03 (config-if)# encapsulation HDLC
maui-nas-03(config-if)# AZ
Шаг 4. Вызовите на выполнение команду show running-config, чтобы проверить, имеет ли интерфейс 1Р-адрес.
Если интерфейс не имеет IP-адреса, получите уникальный адрес и присвойте его интерфейсу, указав маску подсети 255.255.255.0
maui-nas-03(config)# ip address 172.22.53.1 255.255.255.0
Шаг 5. Очистите счетчики интерфейса с помощью команды clear counters.
maui-nas-03# clear counters
Clear "show interface" counters on all interfaces [confirm] maui-nas-03#
Шаг 6. Выполните проверку с помощью расширенной команды эхо-тестирования, как описано выше, в разделе “Методы проверки с применением расширенной команды эхо-тестирования”.
Устранение нарушений в работе канала Е1
В настоящем разделе рассматриваются методы и процедуры устранения нарушений в работе каналов Е1, эксплуатируемых в режиме входящих коммутируемых соединений.
Поиск неисправностей с помощью команды show controller е1
С помощью exec-команды show controller el можно получить информацию, необходимую для применения процедуры устранения нарушений в работе физического и канального уровней. В этом разделе показано, как применить процедуру поиска неисправностей с помощью команды show controller el.
Эта команда отображает информацию о состоянии контроллера с учетом особенностей аппаратных средств конкретного контроллера. Информация, приведенная в выводе этой команды, в основном предназначена для выполнения задач диагностики персоналом службы технической поддержки.
Устройство NPM или MIP может опрашивать адаптеры порта для определения их текущего состояния. Для получения статистических данных о работе канала Е1 вызовите на выполнение команду show controller el.
Если в качестве параметров команды заданы номера гнезда и порта, отображаются статистические данные за каждый 15-минутный период.
Появление ошибок в канале Е1 чаше всего бывает вызвано применением неправильной конфигурации канала. Убедитесь в том, что такие параметры, как способ фреймирования и кодирования в канале, а также источник синхроимпульсов, заданы в конфигурации в соответствии с рекомендациями оператора связи.
Состояния контроллера в выводе команды show controller е1
Контроллер El может находиться в одном из трех состояний:
остановлен администратором;
не функционирует;
функционирует.
Контроллер остановлен администратором
Контроллер считается остановленным администратором, если он остановлен вручную. Для исправления этой ошибки необходимо перезапустить контроллер.
Шаг 1. Перейдите в режим enable.
maui-nas-03> en
Password:
maui-nas-03#
Шаг 2. Перейдите в режим ввода глобальных команд конфигурации.
maui-nas-03# configure terminal
Enter configuration commands, one per line. End with CNTL/Z. maui-nas-03(config)#
Шаг 3. Перейдите в режим настройки конфигурации контроллера.
maui-nas-03(config)# controller el О
maui-nas-03(config-controlle)#
Шаг 4. Перезапустите контроллер.
maui-nas-03(config-controlle)# shutdown
maui-nas-03(config-controlle)# no shutdown
Канал не функционирует
Если канал El не функционирует, убедитесь в том, что конфигурация канала является правильной и соответствует параметрам настройки оборудования, находящегося на дальнем конце канала.
Проверьте формат фреймирования в канале и в оборудовании, находящемся на дальнем конце канала. В каналах Е1 применяется формат фреймирования CRC4 или noCRC4.
Проверьте формат кодирования в канале и в оборудовании, находящемся на дальнем конце канала. В каналах Е1 применяется формат кодирования AMI или HDB3.
Проверьте, применяется ли уравновешенная или неуравновешенная оконечная нагрузка канала (75 Ом или 120 Ом).
Проконсультируйтесь с провайдером служб для получения дополнительной информации о правильных параметрах настройки. Внесите все необходимые изменения в конфигурацию локальных и удаленных конечных устройств.
Если контроллер Е1 и канал не находятся в рабочем состоянии, проверьте, обнаруживается ли одно из следующих сообщений в выводе exec-команды show controller el:
Receiver has loss of frame.
или
Receiver has loss of signal.
Потеря фрейма в приемной аппаратуре
Шаг 1. Проверьте, совпадает ли формат фреймирования, заданный в конфигурации порта, с форматом фреймирования канала. Формат фреймирования контроллера можно проверить, изучив текущую конфигурацию или вывод команды show controller el.
Для изменения формата фреймирования вызовите на выполнение команду framing {CRC4 | noCRC4} в режиме настройки конфигурации контроллера, как показано ниже.
maui-nas-03# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
maui-nas-03(config)# controller El 0
maui-nas-03(config-controlle)# framing CRC4
Шаг 2. Попытайтесь применить другой формат фреймирования, чтобы определить, приведет ли это к исчезновению аварийного сигнала.
Если выполнение описанных выше действий не позволяет устранить нарушение в работе, перейдите к разделу “Потеря сигнала в приемной аппаратуре”.
Шаг 3. Проверьте формат фреймирования в оборудовании, находящемся на удаленном конце канала.
Шаг 4. Проверьте формат кодирования в оборудовании, находящемся на удаленном конце канала
Потеря сигнала в приемной аппаратуре
Шаг 1. Убедитесь в том, что кабель между портом интерфейса и оборудованием провайдера службы Е1 или терминальным оборудованием Е1 подключен правильно. Проверьте, подключен ли кабель к соответствующим портам. В случае необходимости исправьте кабельные соединения.
Шаг 2. Проверьте целостность кабеля. Определите, нет ли в кабеле обрывов или других физических дефектов. Убедитесь в том, что контакты разъемов находятся в хорошем состоянии. В случае необходимости замените кабель.
Шаг 3. Проверьте разъемы кабелей. Если пары передающих и приемных проводников переставлены местами или пары приемных проводников разомкнуты, то могут возникнуть ошибки. Подключите пару приемных проводников к контактам 1 и 2; пара передающих проводников должна быть подключена к контактам 4 и 5.
Контакты в разъеме RJ-45 пронумерованы последовательно от 1 до 8. Номер 1 имеет самый левый контакт вилки, повернутой к наблюдателю. Для получения дополнительной информации обратитесь к рис. 15.12.
87654321
Соединитель RJ-45
Рис. 15.12. Кабель RJ-45
Шаг 4. Попытайтесь применить кабель с обратным расположением выводов.
Шаг 5. Определите, возникают ли в оборудовании на дальнем конце линии блочные ошибки. Если дело обстоит таким образом, то нарушение в работе связано с неисправностью кабеля, по которому поступают сигналы приема, в оборудовании на ближнем конце. Обратитесь за помощью к представителю службы технической поддержки ТАС.
Вызывайте на выполнение exec-команду show controller el после выполнения каждого шага, чтобы определить, продолжает ли появляться информация об ошибках контроллера в выводе этой команды.
Канал находится в режиме использования петли обратной связи
По результатам выполнения команды show controller el проверьте, находится ли канал в режиме петли обратной связи. Канал должен находиться в режиме петли обратной связи только при выполнении проверок.
Для выхода из режима петли обратной связи необходимо вызвать на выполнение команду no loopback в режиме настройки конфигурации контроллера, как показано ниже.
maui-nas-03(config-controlle)# no loopback
Контроллер выводит аварийные сигналы
По результатам выполнения команды show controller проверьте, выводит ли контроллер аварийные сигналы.
Ниже описаны различные аварийные сигналы и представлены процедуры, необходимые для их устранения.
Получен (Rx) удаленный аварийный сигнал
Получение удаленного аварийного сигнала означает, что в канале, который следует за оборудованием, подключенным к рассматриваемому порту, возник аварийный сигнал.
Шаг 1. Проверьте, совпадает ли формат фреймирования, указанный в конфигурации порта, с форматом фреймирования канала. Если форматы не совпадают, измените формат фреймирования в контроллере в соответствии с форматом канала.
Шаг 2. Проверьте установку формата кодирования в оборудовании на дальнем конце канала. Обратитесь к провайдеру служб для получения информации о правильных параметрах настройки. В случае необходимости откорректируйте все неправильно заданные параметры настройки.
Шаг 3. Подключите к порту разъем с внешней петлей обратной связи. Способ подготовки разъема с петлей обратной связи описан выше, в разделе “Применение разъема с петлей обратной связи для проверки аппаратных средств”.
Шаг 4. Выясните, появились ли какие-либо аварийные сигналы. Если никаких аварийных сигналов не обнаружено, это означает, что, по всей вероятности, локальные аппаратные средства находятся в хорошем состоянии. В таком случае выполните следующие действия.
Проверьте кабельную разводку. Для получения дополнительной информации обратитесь к разделу “Потеря сигнала в приемной аппаратуре”.
Проверьте параметры оборудования на удаленном конце канала и убедитесь в том, что они соответствуют параметрам рассматриваемого порта.
Если описанные выше действия не позволяют устранить нарушения в работе, обратитесь к провайдеру служб.
Шаг 5. Снимите разъем с петлей обратной связи и снова подключите разъем канала Е1.
Шаг 6. Проверьте кабельную разводку. Дополнительная информация приведена в разделе “Потеря сигнала в приемной аппаратуре”.
Шаг 7. Выключите, а затем снова включите маршрутизатор.
Шаг 8. Подключите разъем канала Е1 к другому порту. Введите в конфигурацию этого порта такие же параметры, как и в канале. Если в результате этого удается устранить нарушение в работе, то причиной неисправности является рассматриваемый порт. В таком случае выполните следующие действия.
Снова подключите канал Е1 к первоначальному порту.
Перейдите к разделу “Устранение нарушений в работе канала Е1, указанных в сообщениях об ошибках’’.
Если описанные выше действия не позволяют устранить нарушение в работе, то выполните следующее:
Проверьте аппаратные средства с помощью петли обратной связи, как описано в разделе “Применение разъема с петлей обратной связи для проверки аппаратных средств".
Замените плату контроллера Е1.
Перейдите к разделу “Устранение нарушений в работе канала Е1, указанных в сообщениях об ошибках".
Передатчик отправляет удаленный аварийный сигнал (красный)
Красный аварийный сигнал регистрируется, если устройство CSU не может войти в режим синхронизации при использовании в канале Е1 текущего формата фреймирования.
Шаг 1. Проверьте, совпадает ли формат фреймирования, заданный в конфигурации порта, с форматом фреймирования канала. В противном случае измените формат фреймирования в контроллере, чтобы он стал таким же, как в канале.
Шаг 2. Проверьте параметры настройки оборудования, установленного на удаленном конце канала, и определите, соответствуют ли они параметрам настройки порта.
Шаг 3. Подключите к порту разъем с внешней петлей обратной связи. Способ подготовки разъема с петлей обратной связи описан выше, в разделе “Применение разъема с петлей обратной связи для проверки аппаратных средств”.
Шаг 4. Выясните, появились ли какие-либо аварийные сигналы. Если никаких аварийных сигналов не обнаружено, это означает, что, по всей вероятности, локальные аппаратные средства находятся в хорошем состоянии. В таком случае выполните следующие действия.
Проверьте кабельную разводку (см. раздел “Потеря сигнала в приемной аппаратуре”).
Если описанные выше действия не позволяют устранить нарушения в работе, обратитесь к провайдеру служб.
Шаг 5. Подключите разъем канала Е1 к другому порту. Введите в конфигурацию этого порта такие же параметры, как и в канале. Если в результате этого удается устранить нарушение в работе, то причиной неисправности является рассматриваемый порт. В таком случае выполните следующие действия.
Снова подключите канал Е1 к первоначальному порту.
Перейдите к разделу “Устранение нарушений в работе канала Е1, указанных в сообщениях об ошибках”.
Если описанные действия не позволяют устранить нарушение в работе, то выполните следующие шаги.
Проверьте аппаратные средства с помощью петли обратной связи, как описано в разделе “Применение разъема с петлей обратной связи для проверки аппаратных средств”.
Замените плату контроллера Е1.
Перейдите к разделу “Устранение нарушений в работе канала Е1, указанных в сообщениях об ошибках”.
Обратитесь за консультацией к провайдеру служб.
Устранение нарушений в работе канала Е1, указанных в сообщениях об ошибках
Вывод exec-команды show controller el может содержать сообщения об ошибках, которые позволяют диагностировать и устранять нарушения в работе. Ниже описаны некоторые сообщения об ошибках и показано, как устранить указанные в них ошибки.
Чтобы определить, увеличиваются ли показания счетчиков ошибок, несколько раз подряд вызовите на выполнение команду show controller el. Отметьте, какие значения имели эти счетчики первоначально.
Получите у провайдера служб информацию о применяемых им параметрах фрей- мирования и кодирования канала.
Увеличиваются показания счетчика Slip Secs
Увеличение количества пропущенных секунд в поле Slip Secs указывает на наличие проблемы синхронизации в канале Е1. Провайдер канала Е1 (телефонная компания) предоставляет синхронизирующий сигнал, по которому должна синхронизироваться аппаратура СРЕ.
Шаг 1. Убедитесь в том, что источником синхронизации является синхронизирующий сигнал, полученный из сети. Об этом свидетельствует наличие в выводе команды строки с указанием, что источником синхронизации является первичный канал: "Clock Source Is Line Primary".
Шаг 2. Откорректируйте конфигурацию источника синхроимпульсов Е1 в режиме настройки конфигурации контроллера.
maui-nas-03(config-controlle)# clock source line primary
Примечание
Если к серверу доступа подключено несколько каналов Е1, только один из них может быть первичным; все прочие каналы Е1 должны получать синхронизирующий сигнал от первичного канала. В таком случае проверьте, что канал Е1, который определен как первичный источник синхронизации, имеет правильную конфигурацию.
Увеличиваются показания счетчика Framing Loss Seconds
Шаг 1. Проверьте, совпадает ли формат фреймирования, заданный в конфигурации порта, с форматом фреймирования канала. Чтобы определить, какой формат фреймирования задан в конфигурации порта, найдите строку "Framing is {CRC4|noCRC4}" в выводе команды ghow controller el.
Шаг 2. В случае необходимости измените формат фреймирования; для этого необходимо вызвать на выполнение команду framing {CRC4 | noCRC4} в режиме настройки конфигурации контроллера.
maui-nas-03(config-controlle)# framing crc4
Увеличиваются показания счетчика Line Code Violations
Шаг 1. Проверьте, совпадает ли формат фреймирования, заданный в конфигурации порта, с форматом фреймирования канала. Чтобы определить, какой формат фреймирования задан в конфигурации порта, найдите строку "Framing is {AMI | HDB3}" в выводе команды show controller el.
Шаг 2. В случае необходимости измените формат фреймирования; для этого необходимо вызвать на выполнение команду framing {ami | hdb3} в режиме настройки конфигурации контроллера, как показано ниже.
maui-nas-03(config-controlle)# linecode ami
Проверка параметров isdn switchtype и pri-group
Вызовите на выполнение команду show running-config, чтобы проверить, правильно ли заданы в конфигурации значения параметров isdn switchtype и pri-group timeslots. Для получения правильных значений параметров обратитесь к провайдеру служб.
Чтобы откорректировать значения параметров isdn switchtype и pri-group, введите следующие строки:
maui-nas-03# configure terminal
maui-nas-03(config)# isdn switch-type primary-nets
maui-nas-03(config)# controller el 0
maui-nas-03(config-controlle)# pri-group timeslots 1-31
Проверка канала передачи сигналов
Если показания счетчиков ошибок не увеличиваются, а неисправность устранить не удается, убедитесь в том, что канал передачи сигналов функционирует и настройка его конфигурации выполнена правильно.
Шаг 1. Вызовите на выполнение команду show interface serial х:15, указав вместо х номер интерфейса.
Шаг 2. Проверьте, функционирует ли интерфейс. Если интерфейс не находится в рабочем состоянии, вызовите на выполнение команду no shutdown, чтобы его активизировать.
maui-nas-03# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
maui-nas-03(config)# interface serial 0:15
maui-nas-03(config-if)# no shutdown
Шаг 3. Убедитесь в том, что применяется инкапсуляция пакетов протокола РРР. Если это условие не соблюдается, примените команду encapsulation ppp в режиме конфигурации интерфейса, чтобы исправить эту ошибку: maui-nas-03(config-if)# encapsulation ppp
Шаг 4. Определите, установлена ли петля обратной связи. Петля обратной связи должна быть установлена только временно, в целях проверки. Для удаления петли обратной связи воспользуйтесь командой no loopback.
maui-nas-03(config-if)# по loopback
Шаг 5. Выключите, а затем снова включите маршрутизатор.
Шаг 6. Если описанные выше действия не позволяют устранить нарушения в работе, обратитесь к провайдеру служб или в центр Cisco ТАС.
Устранение нарушений в работе интерфейса PRI
В процессе устранения нарушений в работе интерфейса PRI необходимо проверить оборудование на обоих концах канала Е1, чтобы определить, исправно ли функционирует канал. Если нарушения в работе протокола уровня 1 устранены, как описано выше, необходимо перейти к поиску неисправностей на уровнях 2 и 3.
Поиск неисправностей с использованием команды show isdn status
Команда show isdn status позволяет получить сведения о текущем состоянии всех интерфейсов ISDN. Она отображает состояние протоколов уровней 1, 2 и 3.
Шаг 1. Проверьте, активен ли протокол уровня 1.
В информации о состоянии протокола уровня 1 должно всегда быть указано ACTIVE, при условии, что канал Е1 не находится в нерабочем состоянии.
Если в выводе команды show isdn status указано, что протокол уровня находится в состоянии DEACTIVATED, это означает, что нарушена физическая связь с каналом Е1 (см. раздел “Контроллер остановлен администратором").
Проверьте также, не переведен ли канал Е1 в нерабочее состояние администратором. Для активизации контроллера Е1 воспользуйтесь командой no shutdown.
Шаг 2. Убедитесь в том, что протокол уровня 2 находится в состоянии MULTIPLE_FRAME_ESTABLISHED.
Состояние MULTIPLE_FRAME_ESTABLISHED протокола уровня 2 является нормальным. Сообщение о том, что протокол находится в этом состоянии, указывает, что завершилась отработка протокола установления соединения между коммутатором ISDN и оконечным устройством и теперь происходит обмен фреймами уровня 2.
Если протокол уровня 2 не находится в состоянии MULTIPLE FRAME ESTABLISHED, вызовите на выполнение exec-команду show controller el, чтобы диагностировать неисправность (см. разделы “Поиск неисправностей с помощью команды show controller el” и “Устранение нарушений в работе канала Е1, указанных в сообщениях об ошибках”).
Поскольку вывод команды show isdn status содержит сведения о текущем состоянии, возможно, что протокол уровня 2 фактически переходит то в рабочее, то в нерабочее состояние, несмотря на то, что в выводе команды указано состояние MULTIPLE FRAME ESTABLISHED. Чтобы проверить, устойчиво ли функционирует протокол уровня 2, воспользуйтесь командой debug isdn q921.
Применение команды debug isdn q921
Команда dehug isdn q921 показывает, какие процедуры доступа канального уровня (уровня 2) функционируют в D-канале маршрутизатора.
В случае необходимости выполните настройку конфигурации для просмотра отладочных сообщений с использованием команды logging console или terminal monitor.
Примечание
В производственной среде следите за тем, чтобы вывод журналов на консоль был заблокирован. Введите команду show logging. Если разрешено ведение журналов, работа сервера доступа может время от времени приостанавливаться из-за перегрузки порта консоли, в который поступает слишком интенсивный поток журнальных сообщений. Введите команду no logging console.
Примечание
Если разрешено применение команды debug isdn q921, но это не приводит к получению отладочной информации, активизируйте исходящий вызов или выполните сброс контроллера, чтобы получить отладочный вывод.
Шаг 1. Убедитесь в том, что протокол уровня 2 работает стабильно. Проконтролируйте отсутствие в выводе команды debug сообщений, указывающих на то, что служба доступа по протоколу уровня 2 попеременно переходит то в рабочее, то в нерабочее состояние. Если в выводе отладочной команды обнаруживаются примерно такие строки, это означает, что канал функционирует нестабильно: Маг 20 10:06:07.882: 3ISDN-6-LAYER2DOWN: Layer 2 for Interface SeO:15, TEI 0 changed to down Mar 20 10:06:09.882: SLINK-3-UPDOWN: Interface SerialO:15, changed state to down Mar 20 10:06:21.274: SDSX1-6-CLOCK CHANGE: Controller 0 clock is now selected as clock source Mar 20 10:06:21.702: SISDN-6-LAYER2UP: Layer 2 for Interface SeO:15, TEI 0 changed to up Mar 20 10:06:22.494: SCONTROLLER-5-UPDOWN: Controller El 0, changed state to up Mar 20 10:06:24.494: SLINK-3-UPDOWN: Interface SerialO:15, changed state to up Если есть основания полагать, что протокол уровня 2 работает нестабильно, см. выше раздел “Устранение нарушений в работе, указанных в сообщениях об ошибках".
Шаг 2. Убедитесь в том, что со стороны отправителя (Тх) и получателя (Rx) наблюдаются только сообщения SAPI.
RRf sapi = 0RRf sapi = 0RRp sapi = 0RRp sapi = 0RRf sapi = 0RRf sapi = 0RRf sapi = 0RRf sapi = 0RRp sapi = 0RRp sapi = 0RRf sapi = 0RRf sapi = 0tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0Mar 20 10:06:52.505: ISDN SeO:15: TX ->
RRf sapi = 0
RRf sapi = 0
RRp sapi = 0
RRp sapi = 0
RRf sapi = 0
RRf sapi = 0
RRf sapi = 0
RRf sapi = 0
RRp sapi = 0
RRp sapi = 0
RRf sapi = 0
RRf sapi = 0
tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0
tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0 tei = 0 nr = 0
Mar 20 10:06:52.505: ISDN SeO:15: RX <
Mar 20 10:07:22.505: ISDN SeO:15: TX ->
Mar 20 10:07:22.509: ISDN SeO:15: RX <
Mar 20 10:07:22.509: ISDN SeO:15: TX ->
Mar 20 10:07:22.509: ISDN SeO:15: RX <-
Шаг 3. Убедитесь в отсутствии сообщений SABME, которые указывают на то, что предпринимаются попытки повторной инициализации протокола уровня 2. Такие сообщения обычно возникают, если станция передает запросные сообщения (RRp), а коммутатор не передает на них ответ (RRf), или наоборот. Пример сообщений SABME приведен ниже. Станции должны получать ответы от коммутатора ISDN на переданные сообщения SABME (в виде фрейма UA).
Маг 20 10:06:21.702: ISDN SeO:15: RX <- SABMEp sapi = 0 tei = 0
Mar 20 10:06:22.494: ISDN SeO:15: TX -> SABMEp sapi = 0 tei = 0
Если обнаруживаются сообщения SABME, выполните следующие действия.
Воспользуйтесь командой show running-config, чтобы проверить, правильно ли выполнена настройка параметров команд isdn switchtype и pri-group timeslots. Для получения правильных значений параметров обратитесь к провайдеру служб.
Чтобы откорректировать значения параметров isdn switchtype и pri-group, введите следующие строки:
maui-nas-03# configure terminal
maui-nas-03(config)# isdn switch-type primary-nets
maui-nas-03(config)# controller el 0
maui-nas-03(config-controlle)# pri-group timeslots 1-31
Шаг 4. С помощью команды show interfaces serial x:15 проверьте, функционирует ли D-канал.
Если D-канал не функционирует, вызовите на выполнение команду по shutdown для его активизации:
maui-nas-03(config)# interface serial 0:15 maui-nas-03(config-if)# no shutdown
Шаг 5. Убедитесь в том, что применяется инкапсуляция пакетов протокола РРР. Если это условие не соблюдается, примените команду encapsulation ppp для настройки параметров инкапсуляции.
maui-nas-03(config-if)# encapsulation ppp
Шаг 6. Определите, находится ли интерфейс в режиме использования петли обратной связи. В процессе нормальной работы интерфейс не должен находиться в режиме использования петли обратной связи.
maui-nas-03 (config-if)# no loopback
Шаг 7. Выключите, а затем снова включите маршрутизатор.
Шаг 8. Если описанные выше действия не позволяют устранить нарушения в работе, обратитесь к провайдеру служб или в центр Cisco ТАС.
ГлаваГлава1616
Глава
Глава
16
16
Устранение нарушений г в работе коммутируемых соединений
а^' В настоящей главе представлены и описаны некоторые технологии, применяемые | в коммутационных сетях. Здесь также приведены рекомендации по настройке кон- $ фигурации и показано, как использовать результаты выполнения некоторых команд show для проверки правильности работы сети. Фактические сведения о поиске неисправностей приведены в главе 17.
■, В настоящей главе рассматриваются следующие основные темы.
^'1. Операции модема.
Использование команды modem autoconfigure.
. • Установление обратного сеанса Telnet к модему.
г. • Использование чередующихся групп.
• Интерпретация вывода команды show line.
-• Сбор информации о производительности модема для анализа тенденций.
2. Операции ISDN. ■
Компоненты. .
: • Службы. : ■-
Интерпретация вывода команды show isdn status.
,. 3. Операции номеронабирателя.
г • Команды привязки номеронабирателя.
Профили номеронабирателя.
Операции РРР.
.• Протокол LCP.
^, ' • Аугентификация/ААА.
• Протокол NCP.
Операции модема
В настоящем разделе рассматриваются вопросы, непосредственно касающиеся настройки, проверки и использования модемов с маршрутизаторами Cisco.
Применение команды modem autoconfigure
Если в маршрутизаторе Cisco используется операционная система Cisco IOS 11.1 или последующих версий, то настройка конфигурации маршрутизатора для обмена данными с модемом (и настройка конфигурации модема) может быть выполнена автоматически.
Ниже описана процедура, позволяющая настроить конфигурацию маршрутизатора Cisco таким образом, чтобы он автоматически предпринимал попытку обнаружить, какой модем подключен к каналу, а затем настроить конфигурацию модема.
Для обнаружения модема, подключенного к маршрутизатору, и определения его типа применяется команда конфигурации канала modem autoconfigure discovery.
После успешного обнаружения модема автоматическая настройка конфигурации модема выполняется с использованием команды конфигурации канала modem autoconfigure type modem-name.
Для просмотра списка модемов, характеристики которых записаны в маршрутизаторе, применяется команда show modemcap modem-name. Если необходимо изменить значение одной из характеристик модема, возвращаемое командой show modemcap, то для этого предназначена команда конфигурации канала modemcap edit modem-name attribute value.
Для получения подробной информации о применении указанных команд обратитесь к документации Cisco IOS Dial Solutions Configuration Guide и Dial Solutions Command Reference.
Примечание
He помещайте команду &W в запись modemcap, применяемую в команде autoconfigure, поскольку это приведет к перезаписи энергонезависимого ОЗУ после каждой операции автоматической настройки конфигурации модема, что может вызвать повреждение модема.
Установление обратного сеанса Telnet к модему
Если в маршрутизаторе эксплуатируется операционная система Cisco IOS 11.0 или более ранних версий, то для диагностических целей или первоначальной настройки конфигурации модема необходимо установить обратный сеанс Telnet, чтобы подготовить конфигурацию модема для взаимодействия с устройством Cisco. При условии, что скорость оборудования DTE модема будет зафиксирована (информация о том, как зафиксировать скорость модема, приведена в табл. 16.5), модем будет всегда взаимодействовать с сервером доступа или маршрутизатором на желаемой скорости. Следует обязательно настроить скорость устройства Cisco перед выдачей команд в модем через обратный сеанс Telnet. (Информация о настройке скорости сервера доступа или маршрутизатора приведена в табл. 16.5.)
Чтобы подготовить конфигурацию модема для работы в обратном сеансе Telnet, вызовите на выполнение команду конфигурации канала transport input telnet. Для установки чередующейся группы (в данном случае в порту 1) введите команду кон-
фигурации канала rotary 1. Размещение этих команд после определения конфигурации канала приводит к тому, что система IOS распределяет IP-приемники для входящих соединений по диапазонам портов, начиная со следующих базовых номеров.
2000ПротоколTelnet
3000ПротоколTelnet с поддержкой чередующихся групп
4000ПротоколTCP бесформатной потоковой передачи
5000ПротоколTCP бесформатной потоковой передачи с поддержкой чередую
щихся групп
6000 Протокол Telnet, двоичный режим
7000 Протокол Telnet с поддержкой чередующихся групп, двоичный режим
9000Протокол XRemote
10000Протокол XRemote с поддержкой чередующихся групп
Для инициализации обратного сеанса Telnet к модему выполните следующие действия.
Шаг 1. На терминале введите команду telnet ip-address 20уу, где ip-address — IP- адрес любого активного подключенного интерфейса устройства Cisco, а уу — номер канала, к которому подключен модем. Например, команда telnet 192.169.53.52 2001 позволяет подключить к вспомогательному порту устройство Cisco 2501 с IP-адресом 192.169.53.52. Как правило, команду Telnet такого типа можно выдать из любого места в сети, откуда есть возможность выполнить эхо-тестирование рассматриваемого IP-адреса.
Примечание
В большинстве маршрутизаторов Cisco порт 01 является вспомогательным. А на серверах доступа Cisco вспомогательный порт имеет номер, на единицу больший последнего номера порта терминала. Например, вспомогательный порт на устройстве 2511 имеет номер 17 (16 портов терминала плюс 1). Для определения номера вспомогательного порта всегда следует использовать exec-команду show line, особенно в устройствах ряда 2600 и 3600, в которых номера портов назначались непоследовательно, чтобы можно было учесть разное количество интерфейсов в асинхронных модулях.
Шаг 2. Если в этом соединении отказано, то можно предположить, что к указанному адресу и порту не подключен приемник либо к этому адресу и порту уже подключился кто-то другой. Проверьте адрес и номер порта, к которым выполняется подключение. Кроме того, убедитесь в том, что в конфигурацию каналов, к которым вы пытаетесь подключиться, введены команды modem inout или modem DTR-active, а также transport input all. Если применяется функция чередования, проверьте также, имеется ли в конфигурации канала команда rotary п (где п — номер чередующейся группы). Чтобы проверить, не подключен ли кто-то к требуемому порту, подключитесь с помощью протокола Telnet к маршрутизатору и вызовите на выполнение команду line п. Найдите символ звездочки, которая указывает, что требуемьш канал используется. Убедитесь в том, что сигнал CTS имеет высокий потенциал, а сигнал DSR — низкий. Для разрыва текущего сеанса связи с портом номер п можно воспользоваться командой clear line п. Если и после этого в соединении будет отказано, это может означать, что модем постоянно подтверждает сигнал CD. Отключите модем от канала, установите обратный сеанс Telnet, а затем снова подключите модем.
Шаг 3. После успешного установления соединения Telnet введите команду АТ и убедитесь в том, что модем в ответ передает сообщение ОК.
Шаг 4. Если модем не отвечает, обратитесь к табл. 16.1.
В табл. 16.1 кратко перечислены проблемы, которые могут вызвать признак неисправности, характеризующийся нарушением связи между модемом и маршрутизатором, и описаны решения этих проблем.
I Таблица 16.1. Набор номера: отсутствие связи между модемом i и маршрутизатором.|
Возможные причины
Рекомендуемые действия
На сервере доступа или в маршрутизаторе не разрешено применение средств управления модемом
Шаг 1. Вызовите на выполнение exec-команду show line на сервере доступа или в маршрутизаторе. В выводе этой команды для вспомогательного порта в столбце Modem должна находиться строка inout или RIisCD. Это указывает на то, что в канале сервера доступа или маршрутизатора разрешено применение средств управления модемом.
Шаг 2. Настройте конфигурацию канала на использование средств управления модемом с помошью команды конфигурации канала modem inout. Теперь на сервере доступа разрешено применение средств управления модемом.
Пример
Следующий пример показывает, как выполнить настройку конфигурации канала на прием и входящих, и исходящих вызовов: line 5 modem inout
Примечание. До тех пор, пока возможность связи с модемом находится под сомнением, обязательно используйте команду modem inout, а не modem ri-is-cd. Последняя команда позволяет принимать через канал только входящие вызовы. В обработке исходящих вызовов будет отказано, поэтому будет исключена возможность установить сеанс Telnet с модемом для настройки его конфигурации. Если есть необходимость разрешить применение команды modem ri-is-cd, это следует сделать только после проверки того, что модем функционирует правильно
Настройка конфигурации модема выполнена неправильно или он участвует в зависшем сеансе
Шаг 1. Вызовите на выполнение команду AT&FE1Q0, чтобы снова ввести в конфигурацию модема заводские установки, и убедитесь в том, что в модеме предусмотрен эхо-повтор символов. Модем может участвовать в зависшем сеансе. Воспользуйтесь командой "0, чтобы очистить канат, и "Q, чтобы активизировать средства управления потоком данных XON. Проверьте параметры контроля четности
Неправильно выполнена кабельная разводка
Шаг 1. Проверьте кабель, проложенный между модемом и сервером доступа или маршрутизатором. Убедитесь в том, что модем подключен к вспомогательному порту сервера доступа или маршрутизатора с помощью кабеля RJ-45 с обратным расположением выводов и разъемом MMOD DB-25. Эта конструкция кабеля рекомендуется и поддерживается корпорацией Cisco для портов RJ-45. (На таких соединительных кабелях обычно стоит маркировка “Modem"?)
Возможные Рекомендуемые действия причины
Нарушение в работе аппаратных средствНарушение в работе аппаратных средствШаг 2. Воспользуйтесь ехес-комацдой show line, чтобы проверить, правильно ли выполнена кабельная разводка. Описание вывода команды show line см. в разделе “Применение команд debug” главы 15
Нарушение в работе аппаратных средств
Нарушение в работе аппаратных средств
Шаг 1. Убедитесь в том, что применяются кабели подходяших типов и все разъемные соединения исправны.
Шаг 2. Проверьте, исправны ли все аппаратные средства, включая соединительные кабели (обрывы проводов), разъемы (плохо закрепленные контакты), порты сервера доступа и модем.
Шаг 3. Дополнительная информация о поиске неисправностей аппаратных средств приведена в главе 3
Применение чередующихся групп
По условиям эксплуатации некоторых приложений требуется, чтобы модемы определенного маршрутизатора совместно использовались группой пользователей. Наглядным примером такого приложения может служить программа Cisco Dialout Utility. Здесь общий принцип работы состоит в том, чтобы пользователи могли подключаться только к одному порту, через который они затем будут подключены к любому модему, оказавшемуся не занятым. Чтобы добавить асинхронный канал к чередующейся группе, просто введите команду rotary л, где п — номер чередующейся группы в конфигурации для асинхронного канала. Например, следующая конфигурация канала позволяет пользователям подключаться к чередующейся группе с помощью команды telnet 192.169.53.52 3001 (см. предыдущий пример) для установления обычного сеанса Telnet:
line 1 16
modem InOut
transport input all
rotary 1 speed 115200 flowcontrol hardware
В качестве иных вариантов могут применяться перечисленные ниже порты для установления соединений по протоколам указанных типов: порт 5001 для соединения по протоколу TCP бесформатной потоковой передачи, порт 7001 для соединения по протоколу Telnet в двоичном режиме (такое соединение применяется в утилите Cisco Dialout Utility) и порт 10001 для соединения по протоколу XRemote.
Примечание
Дпя проверки конфигурации программы Cisco Dialout Utility дважды щелкните на пиктограмме Dialout Utility в правой нижней части экрана, затем щелкните на кнопках More и Configure Ports. Убедитесь в том, что номер порта находится в диапазоне от 7000 и выше, если применяются чередующиеся группы, и от 6000 и выше, если программа Dialout Utility предназначена для работы с отдельным модемом. Рекомендуется также в целях диагностики разрешить ведение журнала сеансов модема на персональном
компьютере. Для этого необходимо выбрать команды в такой последовательности: Start^Control Panel^Modems^Properties^Connection^Advanced^Record a Log File.
Интерпретация вывода команды show line
Вывод exec-команды show line line-number может применяться при устранении нарушений в работе соединений от модема к серверу доступа или маршрутизатору. Вывод команды show line показан на рис. 16.1.
Скорость каналаРазрешеноСкорость каналаРазрешеноУправление модемом разрешено as52&Xl# show line 1 \.Управление модемом разрешено as52&Xl# show line 1 \.Tty Тур Tx/Rx A ModemTty Тур Tx/Rx A Modem] TTY 115200/115200] TTY 115200/115200Roty AccO AccI UsesNoiseOverruns Int---0C0/0Roty AccO AccI UsesNoiseOverruns Int---0C0/0аппаратное управление потоком данныхСостояние модемааппаратное управление потоком данныхСостояние модемаLocation:Location:LenBaud г г Status:LenBaud г г Status:Туре:Туре:24 lines, Width: 80 columns (TX/RX) is 115200/115200,24 lines, Width: 80 columns (TX/RX) is 115200/115200,Noties:[Hardware Flowcontro: ModetT^Ta^l^yut, Modem RI is CD Modem state: [Hanging Up]Noties:[Hardware Flowcontro: ModetT^Ta^l^yut, Modem RI is CD Modem state: [Hanging Up]modem(slot/port)=1/0, state=IDLEmodem(slot/port)=1/0, state=IDLEno parity, 1 stopbits,In, Hardware Flowcontrolno parity, 1 stopbits,In, Hardware Flowcontrol8 databitsOut |8 databitsOut |dsxl(slot/unit/channel)=N0NE, status=VDEV_STATUS_UNLOCKEDGroup codes: 0dsxl(slot/unit/channel)=N0NE, status=VDEV_STATUS_UNLOCKEDGroup codes: 0Тайм-аут EXEC, указанный в конфигурацииТайм-аут EXEC, указанный в конфигурацииModem hardware state: CTS noDSR noDTR RTSModem hardware state: CTS noDSR noDTR RTSSpecial Chars: Escape Hold ' AAx noneTimeouts:Idle EXEC0:10:00Special Chars: Escape Hold ' AAx noneTimeouts:Idle EXEC0:10:00Stop StartIdle Session neverIdle SessionStop StartIdle Session neverIdle SessionDisconnect ActivationModem Answer SessionDisconnect WarningDisconnect ActivationModem Answer SessionDisconnect WarningDispatch not setDispatch not set
Скорость канала
Разрешено
Скорость канала
Разрешено
Управление модемом разрешено as52&Xl# show line 1 \.
Управление модемом разрешено as52&Xl# show line 1 \.
Tty Тур Tx/Rx A Modem
Tty Тур Tx/Rx A Modem
] TTY 115200/115200
] TTY 115200/115200
Roty AccO AccI UsesNoiseOverruns Int
---0C0/0
Roty AccO AccI UsesNoiseOverruns Int
---0C0/0
аппаратное управление потоком данных
Состояние модема
аппаратное управление потоком данных
Состояние модема
Location:
Location:
Len
Baud г г Status:
Len
Baud г г Status:
Туре:
Туре:
24 lines, Width: 80 columns (TX/RX) is 115200/115200,
24 lines, Width: 80 columns (TX/RX) is 115200/115200,
No
ties:[Hardware Flowcontro: ModetT^Ta^l^yut, Modem RI is CD Modem state: [Hanging Up]
No
ties:[Hardware Flowcontro: ModetT^Ta^l^yut, Modem RI is CD Modem state: [Hanging Up]
modem(slot/port)=1/0, state=IDLE
modem(slot/port)=1/0, state=IDLE
no parity, 1 stopbits,
In, Hardware Flowcontrol
no parity, 1 stopbits,
In, Hardware Flowcontrol
8 databits
Out |
8 databits
Out |
dsxl(slot/unit/channel)=N0NE, status=VDEV_STATUS_UNLOCKED
Group codes: 0
dsxl(slot/unit/channel)=N0NE, status=VDEV_STATUS_UNLOCKED
Group codes: 0
Тайм-аут EXEC, указанный в конфигурации
Тайм-аут EXEC, указанный в конфигурации
Modem hardware state: CTS noDSR noDTR RTS
Modem hardware state: CTS noDSR noDTR RTS
Special Chars: Escape Hold ' AAx none
Timeouts:Idle EXEC
0:10:00
Special Chars: Escape Hold ' AAx none
Timeouts:Idle EXEC
0:10:00
Stop Start
Idle Session never
Idle Session
Stop Start
Idle Session never
Idle Session
Disconnect Activation
Modem Answer Session
Disconnect Warning
Disconnect Activation
Modem Answer Session
Disconnect Warning
Dispatch not set
Dispatch not set
Login-sequence User Response 00:00:30
Autoselect Initial Wait
not set
Modem type is unknown
Session limit is not set.
Time since activation: never
Editing is enabled.
History is enabled, history size is 10.
DNS resolution in show commands is enabled
Full user help is disabled
Allowed transports are lat pad telnet rlogin udptn vl2C lapb-ta. Preferred is 1 at pad telnet rlogin udptn vl2C lapb-ta.
No output characters are padded
No special data dispatching characters
as520C-l#
Puc. 16.1. Вывод команды show line
При возникновении нарушений связи в полях Modem State и Modem Hardware State появляется важная информация.
Примечание
Поле Modem Hardware State присутствует в выводе команды show line не на каждой платформе. В некоторых случаях информация о состоянии сигналов отображается не в этом поле, а в поле Modem State.
* Выберите модем, применяемый в утилите Cisco Dialout.
В табл. 16.2 показаны типичные строки Modem State и Modem Hardware State в выводе команды show line и описано каждое сокращенное обозначение состояния.
; Таблица 16.2. Содержимое полей Modem State и Modem Hardware State J
Iв выводе команды show line /.!
Поле Modem Поле Modem Hardware Описание
State
State
Idle
CIS noDSR DTK RTSЭто — нормальные состояния модема для соединений
между сервером доступа или маршрутизатором и модемом (когда отсутствуют входяшие вызовы). Присутствие в выводе строковых данных какого-либо иного вида обычно указывает на нарушение в работе
Ready
-Если модем находится в состоянии Ready (Готовый)
вместо Idle (Простаивающий), необходимо рассмотреть следующие три возможности.
В сервере доступа или маршрутизаторе не выполнена настройка конфигурации средств управления модемом. Настройте конфигурацию сервера доступа или маршрутизатора с помошью команды конфигурации канала modem inout.
В канале открыт сеанс. Вызовите на выполнение exec-команду show users и воспользуйтесь привилегированной exec-командой clear line, чтобы прекратить сеанс, если это необходимо.
Сигнал DSR имеет высокий потенциал. Это может быть обусловлено следующими двумя причинами.
Неправильно выполнена кабельная разводка. Если в соединительном кабеле используется контакт 6 разъема DB-25, а контакт 8 отсутствует, необходимо переместить контакт из позиции 6 в позицию 8 или приобрести подходящий соединительный кабель.
Конфигурация модема Настроена на использование всегда высокого потенциала сигнала DCD. Необходимо откорректировать конфигурацию модема таким образом, чтобы в нем сигнал DCD с высоким потенциалом использовался только после активизации сигнала CD. Для этого обычно применяется команда модема &С1, но для определения точной синтаксической структуры команды для конкретного модема обратитесь к документации модема.
Если применяемое программное обеспечение не поддерживает средства управления модемом, необходимо настроить конфигурацию канала сервера доступа, к которому подключен модем, с помошью команды конфигурации канала no ехес.
Поле Modem Поле Modem Hardware
StateState
Описание
Очистите канал с помощью привилегированной exec-команды clear line, инициализируйте обратный сеанс Telnet с модемом, и откорректируйте конфигурацию модема таким образом, чтобы высокий потенциал сигнала DCD устанавливался только после активизации сигнала CD.
Завершите сеанс Telnet, введя команду disconnect, и откорректируйте конфигурацию канала сервера доступа с помощью команды конфигурации канала ехес
ReadynoCTS noDSR DTR RTS
Строка noCTS может появиться в поле Modem Hardware State в следующих четырех случаях.
Модем выключен.
Модем не подключен к серверу доступа должным образом. Проверьте кабельные соединения от модема к серверу доступа.
Применяется неподходящий кабель (либо MDCE с обратным расположением выводов, либо MDTE с прямым расположением выводов, но без перемещения контактов). Информация о рекомендуемой конструкции кабеля приведена в табл. 16.1.
Конфигурация модема не настроена для использования аппаратных средств управления потоком данных. Отмените использование аппаратных средств управления потоком данных на сервере доступа с помощью команды конфигурации канала по flowcontrol hardware, а затем разрешите применение аппаратных средств управления потоком данных в модеме с помощью обратного сеанса Telnet. (Изучите документацию модема и обратитесь к разделу "Установление обратного сеанса Telnet к модему", приведенному выше в этой главе.)
Снова разрешите применение аппаратных средств управления потоком данных на сервере доступа с помощью команды конфигурации канала flowcontrol hardware
ReadyCTS DSR DTR RTS
Строка DSR может появиться в поле Modem Hardware State вместо строки noDSR в следующих двух случаях.
• Неподходящий тип кабеля (кабель с разъемом MDCE2 и обратным подключением выводов или кабель с разъемом MDTE3 и прямым подключением выводов, но без перестановки контактов). Информация о рекомендуемой конструкции кабеля приведена в табл. 16.1.
2 MDCE (male DCE — вилочная часть разъема к оборудованию ОСЕ).
3 МОТЕ (male ОТЕ — вилочная часть разъема к оборудованию ОТЕ).
Поле Modem Поле Modem Hardware
StateState
Описание
ReadyCTS* DSR* DTR RTS
• Конфигурация модема настроена на использование всегда высокого потенциала сигнала DCD. Необходимо откорректировать конфигурацию модема таким образом, чтобы сигнал DCD с высоким потенциалом использовался в нем только после активизации сигнала CD. Для этого обычно применяется команда модема &С1, но для определения точной синтаксической структуры команды для конкретного модема обратитесь к документации модема.
Выполните настройку конфигурации канала сервера доступа, к которому подключен модем, с помощью команды конфигурации канала no ехес. Очистите канал с помощью привилегированной ехес-команды clear line, инициализируйте обратный сеанс Telnet с модемом и откорректируйте конфигурацию модема таким образом, чтобы высокий потенциал сигнала DCD устанавливался только после активизации сигнала CD.
Завершите сеанс Telnet, введя команду disconnect. Откорректируйте конфигурацию канала сервера доступа с помощью команды конфигурации канала ехес
Если эта строка появляется в поле Modem Hardware State, то на сервере доступа, вероятно, не разрешено применение средств управления модемом. Воспользуйтесь командой конфигурации канала modem inout, чтобы разрешить применение средств управления модемом в данном канале.
Дополнительная информация о настройке средств управления модемом в канале сервера доступа или маршрутизатора приведена в табл. 16.1
Сбор информации о производительности модема
В настоящем разделе описаны способы сбора информации о производительности цифровых модемов MICA, применяемых в семействе серверов доступа Cisco AS5x00. Эти данные могут использоваться для анализа тенденций и способствовать устранению нарушений в работе, характеризующихся снижением производительности. Рассматривая представленные здесь данные, следует помнить, что реальный мир далек от идеала. Достижимое значение показателя CSR (Call Success Rate — доля успешных попыток вызова) зависит от качества электрических цепей, от того, каков круг пользователей клиентского модема, а также от состава применяемых способов модуляции. Типичное значение CSR для вызовов V.34 составляет 95%, а в отношении вызовов
V.90 можно предположить, что подключение окажется успешным в 92% случаев. Преждевременный разрыв соединений может происходить в 10% случаев.
Ниже перечислены инструментальные средства, позволяющие получить общее представление о работе модема, подключенного к серверу доступа.
show modem.
show modem summary.
show modem connect-speeds.
show modem call-stats.
При устранении нарушений в работе отдельного модемного соединения или при сборе данных для анализа тенденций может оказаться полезной следующая информация:
debug modem csm
modem call-record terse
show modem op (MICA) / AT@E1 (Microcom) while connected
show modem log - for the session of interest after disconnect.
ANI (caller's number)
Time of day
Client modem hardware / firmware revision
Interesting info from client (after disconnect)-ATI6, ATI11, AT&V, AT&V1, etc.
An audio record (.wav file) of the trainup attempt from the client modem
Эти команды описаны более подробно в следующих разделах, где также рассматриваются некоторые общие тенденции.
Команды show modem/show modem summary
Команда show modem позволяет получить информацию об отдельных модемах. Представленные ею данные помогут определить, насколько исправно работают отдельные модемы.
router# show modem
Codes:
* - Modem has an active call
C - Call in setup
T - Back-to-Back test in progress
R - Modem is being Reset
p - Download request is pending and modem cannot be used for taking calls
D - Download in progress
В - Modem is marked bad and cannot be used for taking calls
b - Modem is either busied out or shut-down
d - DSP software download is required for achieving K56flex connections
- Upgrade request is pending
Inc calls
Out calls
Busied
Failed
No
Succ
Mdm
Usage
Succ
Fail
Succ
Fail
Out
Dial
Answer
Pct.
* 1/0
17%
74
3
0
0
0
0
0
96%
* 1/1
15%
80
4
0
0
0
1
1
95%
* 1/2
15%
82
0
0
0
0
0
0
100%
1/3
21%
62
1
0
0
0
0
0
98%
1/421%495 О О О ОО 90%
* 1/518%653 О О О О 095%
Для получения сводных данных обо всех модемах в маршрутизаторе можно использовать команду show modem summary.
router# show modem summary
Incoming calls Outgoing calls Busied Failed No Succ
Usage
Succ
Fail
Avail
Succ
Fail
Avail
Out
Dial
Ans
Pct.
0%
6297
185
64
0
0
0
0
0
0
97%
В табл. 16.3 описаны различные поля в выводе команды show modem summary.
Таблица 16.3. Поля в выводе команды show modem summary •
Поле
Описание
Incoming Calls, Outgoing Calls
Количество входящих и исходящих вызовов, прошедших через модемы.
Usage. Отношение продолжительности периода, в который использовались все модемы, к общей продолжительности работы системы в процентах.
Succ. Общее количество вызовов, завершившихся успешным установлением соединения.
Fail. Общее количество вызовов, не завершившихся успешным установлением соединения.
Avail. Общее количество модемов, доступных для использования в системе
Busied Out
Общее количество случаев, когда модемы были выведены из эксплуатации с применением команды modem busy или modem shutdown
Failed Dial
Общее количество попыток, при которых модемы не разрывали соединение или отсутствовал сигнал ответа АТС
No Ans
Общее количество случаев, когда обнаруживалась посылка вызова, но модем не отвечал на вызовы
Succ Pct.
Отношение количества успешно установленных соединений к общему количеству доступных модемов в процентах
Команда show modem call-stats
Команда show modem call-stats позволяет получить данные о производительности модемов за последний период. Она может применяться при анализе тенденций и позволяет администратору выявить возможные проблемы.
compress retrain lostCarr rmtLink trainup hostDrop wdogTimr inacTout
Mdm #%#%#%#%#%#%#%#%
Total 94127132777211400
В табл. 16.4 описаны наиболее часто применяемые поля в выводе команды show modem call-stats.
Таблица 16.4. Поля в выводе команды show modem call-stats
rmtLink
Показывает, что действуют средства исправления ошибок и что соединение, установленное в данном вызове, было разорвано клиентской системой, подключенной к удаленному модему
hostDrop
Указывает на то, что соединение, установленное в данном вызове, было разорвано системой IOS хоста. К числу наиболее распространенных причин относятся следующие: истечение тайм-аута простоя, очистка канала по инициативе телефонной компании или получение сообщения PPP LCP termreq от клиента. Наилучшие способы определения причины разрыва соединения состоят в использовании команды show modem call-record terse и ознакомлении с учетными данными сервера ААА
Другие причины разъединения должны составлять не более 10% от общего количества случаев
Команда show modem connect speeds
Команда show modem connect позволяет администратору сервера доступа определить количество соединений, устанавливаемых на той или иной скорости, что дает ему возможность контролировать эффективность использования модемов сообществом пользователей. Полученные при этом данные могут применяться при анализе тенденций.
router> show modem connect 33600 0
Mdm264002800028800293333066731200320003333333600TotCnt
Tot61401053001682008226304
router> show modem connect 56000 0
Mdm480004933350000506665200053333540005466656000TotCnt
Tot178308689786160006304
Наибольшая часть соединений должна устанавливаться на скоростях, которые часто используются во время работы по протоколу V.34. Если в каналах TI используется система CAS (Channel Associated Signaling — канал-зависимая сигнализация), то максимальное количество соединений должно устанавливаться на скорости 26,4 Кбит/с. Для каналов TI ISDN (PRI) максимальное значение должно наблюдаться на скорости 31,2 Кбит/с. Кроме того, незначительная часть соединений устанавливается на скоростях, характерных для протоколов K56Flex и V.90. Если соединения V.90 отсутствуют, то нарушения в работе могут быть обусловлены недостатками топологии сети.
Команда modem call-record terse (11 .ЗАА/12.0Т)
Это скорее не exec-команда, а команда конфигурации, переведенная на системный уровень для рассматриваемого сервера доступа. При отключении пользователя отображается примерно такое сообщение:
‘Мау 31 18:11:09.558: %CALLRECORD-3-MICA_TERSE_CALL_REC: DSO slot/contr/chan=2/0/18, slot/port=l/29, call_id=378, userid=cisco, ip=0.0.0.0, calling=5205554099, called=4085553932, std=V.9O, prot=LAP-M, comp=V.42bis both, init-rx/tx b- rate=26400/41333, finl-rx/tx brate=28800/41333, rbs=0, d-pad=6.0 dB, retr=l, sq=4, snr=29, rx/tx chars=93501/94046, bad=5, rx/tx ec=1612/732, bad=0, time=337, finl-state=Steady, disc(radius)=Lost Carrier/Lost Carrier, disc(modem)=A220 Rx (line to host) data flushing - not OK/EC
condition - locally detected/received DISC frame — normal LAPM termination
Команда show modem operational-status
Рассматриваемая ехес-команда show modem operational-status показывает текущие (или последние) значения параметров, характеризующих соединение модема.
Эта команда описана в документе Cisco IOS Release 12.0 Dial Solutions Command Reference. Команда show modem operational-status предназначена только для модемов MICA (Modem ISDN Channel Aggregation — объединение модема с каналом ISDN). Эквивалентной командой для модемов Microcom является modem at-mode / АТ@Е1. Вызовите на выполнение команду modem at-mode <slot>/<port>, чтобы подключиться к модему, а затем введите команду АТ@Е1. Полное описание команды modem at-mode приведено в документе Cisco AS5300 Software Configuration Guide, а команда AT@E1 рассматривается в документах AT Command Set и Register Summary for Microcom Modem Modules Command Reference.
Чтобы определить, через какие модемы подключился пользователь, выполните следующие действия.
Шаг 1. Вызовите на выполнение команду show user и определите, к какому терминалу подключен пользователь.
Шаг 2. Воспользуйтесь командой show line, чтобы определить номер гнезда/порта модема.
Сбор информации о производительности работы клиента
Для анализа тенденций очень важно собрать данные о производительности работы клиента. В частности, необходимо получить следующую информацию.
Модель и версия встроенного программного обеспечения аппаратных средств клиента (эту информацию можно получить, вызвав на выполнение команду ATI3I7 в модеме клиента).
Причины разрыва соединения, сообщаемые клиентом (воспользуйтесь командой ATI6 ИЛИ AT&V1).
Другая информация, доступная на персональном компьютере клиента, включая файлы modemlog.txt и ppplog.txt. На персональном компьютере такие файлы формируются, только если это обусловлено конфигурацией.
Анализ данных о производительности
После сбора и упорядочения данных о производительности системы модемной связи можно приступить к поиску возможностей для усовершенствования во всех остальных подсистемах и компонентах.
Характерные проблемы при эксплуатации серверных модемов определенных типов
Вызовите на выполнение команду show modem или show modem call-stats и найдите все модемы, которые отличаются слишком высокими значениями частоты аварийного завершения подготовки к соединению или недопустимыми значениями частоты разъ-
единения. Если проблемы возникают в смежных парах модемов, то причиной нарушения в работе, вероятно, является зависший или неисправный процессор DSP (Digital Signal Processor — цифровой процессор сигналов). Для возобновления нормальной работы вызовите на выполнение команду copy flash modem в модуле НММ (Hex MICA Module — модуль, состоящий из шести модемов MICA), в котором она возникла. Проверьте, используется ли в модемах новейшая версия программного обеспечения порта.
Убедитесь в том, что настройка конфигурации всех модемов выполнена правильно. Чтобы проверить, правильно ли выполнена настройка конфигурации модема, используйте команду конфигурации modem autoconfigure type <mica/microcom_server> в конфигурации канала. Чтобы убедиться в том, что после завершения каждого вызова происходит автоматическая перенастройка конфигурации модемов, воспользуйтесь exec-командой debug confmodem. В некоторых случаях для устранения нарушений в работе модемов с неправильно настроенной конфигурацией может потребоваться проведение обратного сеанса Telnet.
Нарушения в работе конкретных DSO-каналов
Нарушения в работе DSO-каналов встречаются редко, но не могут быть исключены из рассмотрения. Чтобы узнать о наличии такой неисправности, воспользуйтесь командой show controller tl call-counters. Найдите все DSO-каналы со слишком высокими значениями показателей Totalcalls и слишком низкими TotalDuration. Чтобы направить трафик по DSO-каналу, исправное функционирование которого находится под сомнением, иногда необходимо вывести из эксплуатации другие DSO-каналы с помощью команды конфигурации isdn service dsl, dsO busyout, входящей в состав определения последовательного интерфейса для Т1. Результаты выполнения команды show controller tl call-counters выглядят следующим образом:
TimeSlot
Туре
Totalcalls
TotalDuration
1
pri
873
lw6d
2
pri
753
2w2d
3
pri
4444
00:05:22
Очевидно, что в данном случае вызывает сомнение исправное функционирование канального интервала 3.
Некоторые наиболее характерные нарушения связи
Ниже перечислены некоторые наиболее характерные проблемы, с которыми сталкиваются в своей работе специалисты центра ТАС Cisco, и указаны признаки неисправности, наблюдаемые при возникновении каждой из этих проблем.
Создаются неприемлемые пути коммутации.
Если...
возникают нарушения при обработке междугородных вызовов, но не локальных (или наоборот);
происходят сбои при обработке вызовов в определенное время суток;
возникают нарушения при обработке вызовов, поступающих из определенных удаленных АТС,
то...
причина может заключаться в том, что создаются неприемлемые пути коммутации через телефонную сеть.
Средства обработки междугородных вызовов работают со сбоями или вообще не работают, но обработка внутригородских вызовов происходит вполне успешно.
Если...
междугородные вызовы характеризуются низким качеством соединения, а внутригородские — вполне приемлемым,
то...
убедитесь в том, что цифровой канал подключен к цифровому коммутатору, а не к группе каналов;
обратитесь к телефонным компаниям, чтобы проследить пути коммутации, используемые при междугородных вызовах.
Возникают проблемы при обработке вызовов, поступающих из некоторых регионов.
Если...
возникают проблемы при обработке вызовов, поступающих из некоторых географических регионов или от некоторых АТС,
то...
получите от телефонной компании и изучите схему телефонной сети. Если в процессе передачи сигнала в рассматриваемый регион несколько раз выполняется аналого-цифровое преобразование (в связи с тем, что применяются аналоговые коммутаторы или группы каналов без встроенной цифровой аппаратуры), то создание соединений с помощью модема V.90/K56flex становится невозможным, а при использовании протокола V.34 качество связи может несколько ухудшиться.
Операции ISDN
Сеть ISDN представляет собой набор цифровых служб, доступный для конечных пользователей. Стандарты ISDN предусматривают применение в телефонной сети дискретных (цифровых) сигналов, что позволяет конечным пользователям передавать голос, данные, текст, графику, музыку, видеоинформацию и другие информационные материалы по существующей телефонной кабельной системе. Сторонники дальнейшего развития сети ISDN надеются, что со временем она превратится во всемирную сеть, во многом напоминающую современную телефонную сеть, но основанную на цифровой передаче данных и предоставляющую широкий набор новых служб.
При разработке сети ISDN была предпринята попытка стандартизировать службы подписчиков, интерфейсы между пользователем и сетью, а также средства создания абонентских и распределенных сетей. Стандартизация служб подписчиков должна
обеспечить достижение определенного уровня совместимости средств ISDN в международном масштабе. Стандартизация интерфейса между пользователем и сетью стимулирует разработку и маркетинг этих интерфейсов с участием независимых производителей. Стандартизация средств создания абонентских и распределенных сетей способствует достижению конечной цели развертывания всемирной системы связи, поскольку позволяет упростить взаимодействие сетей ISDN друг с другом.
К числу приложений ISDN относятся приложения высокоскоростной передачи изображений (таких как факсимильные изображения класса Group IV), формирования дополнительных телефонных каналов в жилых домах для обслуживания индустрии оффшорной занятости, высокоскоростной передачи файлов и проведения видеоконференций. Но одним из наиболее популярных приложений для ISDN должна стать передача голоса.
В последнее время многие провайдеры связи начинают предоставлять услуги ISDN по сниженным тарифам. Например, крупные телекоммуникационные компании в Северной Америке все чаще предлагают заказчикам применять службы ISDN вместо соединений Т1 (т.е. вместо средств провайдера цифровой связи, предоставляемых телефонными компаниями), которые в настоящее время несут основной объем нагрузки глобальной службы телефонной сети.
Компоненты ISDN
К компонентам ISDN относятся терминалы, терминальные адаптеры (ТА — terminal adapter), оконечные сетевые устройства, оконечное оборудование канала и оконечное оборудование обмена данными. Терминалы ISDN подразделяются на два типа: специализированные терминалы ISDN, которые сокращенно обозначаются как TEI (terminal equipment type 1 — терминальное оборудование типа 1), и терминалы, отличные от ISDN, такие как устройства DTE, разработанные до принятия стандарта ISDN, которые сокращенно обозначаются как ТЕ2 (terminal equipment type 2). Устройства ТЕ1 подключаются к сети ISDN с помощью цифрового канала, выполненного в виде четырехпроводного кабеля с витыми парами. Устройства ТЕ2 подключаются к сети ISDN через терминальный адаптер. Такой адаптер ISDN ТА может представлять собой автономное устройство или плату устройства ТЕ2. Если ТЕ2 выполнено в виде автономного устройства, оно подключается к адаптеру ТА через стандартный интерфейс физического уровня. К таким интерфейсам относятся EIA/TIA-232-C (который прежде назывался RS-232-C), V.24 и V.35.
Кроме устройств ТЕ1 и ТЕ2, для подключения к сети ISDN применяются устройства типа NT1 (network termination type 1 — сетевое оконечное устройство типа 1) или NT2 (network termination type 2 — сетевое оконечное устройство типа 2). Это — сетевые оконечные устройства, которые соединяют четырехпроводную абонентскую проводную разводку с обычной двухпроводной местной линией связи. В Северной Америке устройства NT1 рассматриваются как оборудование СРЕ. В большинстве других стран мира устройства NT1 рассматриваются как часть сетевого оборудования, предоставляемого оператором связи. Устройства NT2 являются более сложными и обычно входят в состав оборудования цифровых мини-АТС, которые выполняют функции поддержки протокола уровня 2 и 3 и используются в качестве концентратора. Существует также категория устройств NT1/2, которые представляют собой отдельное устройство, объединяющее функции NT1 и NT2.
В спецификации ISDN определено понятие контрольной точки. Контрольными точками называются логические интерфейсы между такими категориями устройств, различающимися по своему назначению, как терминальные адаптеры (ТА) и устройства NT1. Контрольные точки ISDN перечислены ниже.
R. Контрольная точка между оборудованием, отличным от ISDN, и адаптером ТА.
S. Контрольная точка между пользовательскими терминалами и устройством NT2.
Т. Контрольная точка между устройствами NT1 и NT2.
U. Контрольная точка между устройствами NT1 и оконечным оборудованием канала в сети оператора связи. Понятие контрольной точки U применяется только в Северной Америке, где сеть оператора связи U не предоставляет функции NT1.
Пример конфигурации ISDN приведен в листинге 16.1. В этом примере показаны три устройства, подключенные к коммутатору ISDN в центральном офисе. Два из этих устройств совместимы с ISDN, поэтому они могут быть подключены к устройствам NT2 через контрольную точку S. Третье устройство (стандартный телефон, не соответствующий спецификации ISDN) подключается к адаптеру ТА через контрольную точку R. Любое из этих устройств может быть также подключено к устройству NT1/2, которое заменяет одновременно и NT1, и NT2. Кроме того, аналогичные пользовательские станции подключены к коммутатору ISDN, хотя они здесь не показаны.
|иопГнг 16.1. Пример конфигураций ISDN
2503B# show running-config
Building configuration...
Current configuration: !
version 11.1
service timestamps debug datetime msec
service udp-small-servers
service tcp-small-servers I
hostname 2503B i i
username 2503A password 7 0822455D0A16 ip subnet-zero
isdn switch-type basic-5ess i
interface Ethernet0
ipaddress 172.16.141.11 255.255.255.192 i
interface SerialO no ip address shutdown
interface Seriall
no ip address shutdown
i
interface BRIO
description phone#5553754
ip address 172.16.20.2 255.255.255.0
encapsulation ppp
dialer idle-timeout 300
dialer map ip 172.16.20.1 name 2503A broadcast 5553759
dialer-group 1
ppp authentication chap ।
no ip classless
I
dialer-list 1 protocol ip permit i
line con 0
line aux 0
line vty 0 4 i
end
2503B#
Службы ISDN
Служба BRI ISDN предоставляет два В-канала и один D-канал (и сокращенно обозначается как 2B+D). Служба BRI В-канала функционирует на скорости 64 Кбит/с и предназначена для передачи пользовательских данных; служба BRI D-канала функционирует на скорости 16 Кбит/с и предназначена для передачи управляющей информации и сигналов, хотя при определенных обстоятельствах она также может обеспечивать передачу пользовательских данных. Протокол передачи сигналов D-канала включает уровни 1—3 эталонной модели OSI. Служба BRI обеспечивает также управление фреймированием и выполняет другие вспомогательные функции, в результате чего общая скорость передачи информации принимает значение 192 Кбит/с. Спецификация физического уровня BRI определена стандартом ITU-T 1.430.
Служба ISDN PRI (Primary Rate Interface — интерфейс основного уровня) предоставляет 23 В-канала и один D-канал в Северной Америке и Японии, что позволяет достичь общей скорости передачи информации 1,544 Мбит/с (D-канал службы PRI функционирует на скорости 64 Кбит/с). Служба ISDN PRI в Европе, Австралии и других частях света предоставляет 30 В-каналов и один D-канал со скоростью 64 Кбит/с, поэтому общая скорость передачи информации для данного интерфейса составляет 2,048 Мбит/с. Спецификация PRI физического уровня определена стандартом ITU-T 1.431.
Уровень 1
Форматы фреймов ISDN физического уровня (уровня I) зависят от того, является ли этот фрейм исходящим (направленным из терминала в сеть) или входящим (направленным из сети в терминал). Оба интерфейса физического уровня показаны на рис. 16.2.
Длина поля вбитах 11 811111 8111 8111 8
F
L
В1
L
D
L
F
L
В2
L
D
L
В1
L
D
L
В2
Фрейм NT (от сети к терминалу)
Длина поля вбитах 11 8 11111 8111 8111 8
F
L
В1
Е
D
А
F
F
В2
Е
D
S
В1
Е
D
S
В2
Фрейм ТЕ (от терминала к сети)
А — бит активизации
В1 — биты канала В1
В2 — биты канала В2
D — D-канал (4 бита х 4000 фрейм/с = 16 Кбит/с)
Е — эхо-повтор предыдущего бита D
F — бит фреймирования
L — уравновешивание нагрузки
S — резервный бит
Рис. 16.2. Форматы фреймов ISDN физического уровня
Фреймы имеют длину 48 битов, из которых 36 представляют данные. Поля фрейма ISDN физического уровня имеют следующее назначение.
F. Обеспечивает синхронизацию.
L. Служит для корректировки среднего двоичного значения.
Е. Используется для разрешения конфликтов, возникающих, если за доступ к каналу конкурируют несколько терминалов, подключенных к пассивной шине.
А. Предназначено для активизации устройств.
S. Резервный бит.
Bl, В2 и D. Применяются для пользовательских данных.
К одной цепи может быть физически подключено несколько пользовательских устройств ISDN. В рассматриваемой конфигурации при попытках одновременно передавать данных из двух терминалов могут возникать коллизии. Поэтому в сети ISDN предусмотрены средства определения ситуации, в которой возникла конкуренция за доступ к каналу. Когда устройство NT получает бит D от устройства ТЕ, оно выполняет эхо-повтор этого бита в следующей позиции фрейма — в бите Е. Устройство ТЕ ожидает, что следующий бит Е будет таким же, как и последний переданный им бит D.
Терминалы могут приступить к передаче данных в D-канал только после приема определенного количества единиц (обозначающих ситуацию отсутствия сигнала) согласно заранее установленному приоритету. Если устройство ТЕ обнаружит в эхо-канале бит, от-
личный от переданных им битов D, оно должно немедленно прекратить передачу. Этот простой метод гарантирует то, что в любой момент времени возможность передать свое D-сообщение предоставляется только одному терминалу. После успешной передачи D-сообщения приоритет терминала уменьшается, и поэтому он должен обнаружить большее количество подряд идущих битов 1 перед передачей. Терминалы не могут повысить свой приоритет до тех пор, пока все остальные устройства в том же канале не получат возможность отправить D-сообщение. Телефонные соединения имеют более высокий приоритет по сравнению со всеми остальными службами, а сигнальная информация имеет более высокий приоритет по сравнению с данными.
Уровень 2
LAPD (Link Access Procedure on the D channel — процедура доступа к D-каналу) представляет собой протокол уровня 2 в составе протоколов обмена сигналами ISDN. Протокол LAPD аналогичен протоколам HDLC и LAPB. Как показывает расшифровка аббревиатуры LAPD, этот протокол используется в D-канале для обеспечения бесперебойной передачи и приема управляющей и сигнальной информации. Формат фрейма LAPD (рис. 16.3) весьма напоминает формат фрейма HDLC; как и в HDLC, в протоколе LAPD применяются управляющие, информационные и ненумерованные фреймы. Протокол LAPD формально определен в стандартах ITU-T Q.920 и ITU-T Q.921.
Длина поляв байтах
121Переменная 11
Флажок
Адрес
Управление
Данные
FCS
Флажок
SAPI
C/R
ЕА
TEI
ЕА
SARI — идентификатор точки доступа к службе (6 бит)
C/R — бит команды/ответа
ЕА — биты расширенной адресации
TEI — идентификатор терминальной оконечной точки
Рис. 16.3. Формат фрейма LAPD
Поля флажков и управления протокола LAPD идентичны соответствующим полям протокола HDLC. Поле адреса фрейма LAPD может иметь длину 1 или 2 байта. Если установлен бит расширенного адреса первого байта, адрес имеет длину 1 байт, а если он не установлен, адрес имеет длину 2 байта. Первый байт поля адреса содержит идентификатор точки доступа к службе (SAPI — Service Access Point Identifier), обозначающий портал, в котором службы LAPD предоставляются на уровне 3. Бит C/R (Command/Response) показывает, содержит ли фрейм команду или ответ. Поле TEI (Terminal Endpoint Identifier — идентификатор терминальной оконечной точки) обозначает либо один терминал, либо несколько терминалов. Поле TEI, содержащее одни единицы, обозначает широковещательную рассылку.
Уровень 3
В составе протоколов обмена сигналами ISDN используются два протокола уровня 3, которые определены спецификациями ITU-T 1.450 (которая известна также под названием ITU-T Q.930) и ITU-T 1.451 (именуемая также ITU-T Q.931). Эти протоколы используются совместно и поддерживают соединения от пользователя к пользователю, с коммутацией пакетов и коммутацией каналов. Указанные спецификации определяют порядок установления соединения, завершения соединения, регламентируют использование информационных и прочих сообщений, в том числе SETUP, CONNECT, RELEASE, USER INFORMATION, CANCEL, STATUS и DISCONNECT. Эти сообщения по своему назначению аналогичны сообщениям, предусмотренным в соответствии с протоколом Х.25 (дополнительная информация об этом представлена в главе 19). На рис. 16.4, взятом из спецификации ITU-T 1.451, показаны типичные этапы обработки вызова ISDN с коммутацией каналов.
ВызовВызывающее Вызывающее Вызываемое Вызываемое Вызываемый
маршрутизатора устройство DTE устройство ОСЕ устройство ОСЕ устройство ОТЕ маршрутизатор
Подключение _ к каналу
Процесс подключения
Процесс подключения
Звонок
Передача ответа абонента
Подтверждение подключения
Приведение в готовность
Информация
Обработка вызова
Приведение в готовность
Прекращение передачи
Соединение
Соединение
Подключение к каналу
Подтверждение соединения
Информация
Передача
Информация
Перепача
Информация
Передача
Передача
Информация
Отключение от канала
Разьединение
Освобождение канала
Освобождение канала
Освобождение канала закончено
Освобождение канала закончено
Рис. 16.4. Этапы обработки вызова ISDN с коммутацией каналов
Интерпретация вывода команды show isdn status
Команда show isdn status позволяет определить текущее состояние соединения ISDN между маршрутизатором и коммутатором телефонной компании. Эта команда поддерживает два основных типа интерфейсов: BRI и PRI (табл. 16.5 и 16.6). 3620-2# show isdn status
Global ISDN Switchtype = basic-ni ISDN BRI0/0 interface
dsl 0, interface ISDN Switchtype = basic-ni
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 88, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
TEI = 97, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Spid Status:
TEI 88, ces = 1, state = 5(init)
spidl configured, no LDN, spidl sent, spidl valid
Endpoint ID Info: epsf = 0, usid = 0, tid = 1
TEI 97, ces = 2, state = 5(init)
spid2 configured, no LDN, spid2 sent, spid2 valid
Endpoint ID Info: epsf = 0, usid = 1, tid = 1
Layer 3 Status:
0 Active Layer 3 Call(s)
Activated dsl 0 CCBs = 0
The Free Channel Mask: 0x80000003
Поле
Описание
Layer 1 Status:
Это состояние указывает, что интерфейс BR1 не обнаруживает сигнал в канале. Ниже описаны пять возможных причин такой ситуации.
DEACTIVATED
Интерфейс BRI закрыт. Проверьте, имеется ли в составе конфигурации команда shutdown в определении интерфейса BRI, или проверьте в выводе команды show interfaces наличие указаний на то, что интерфейс остановлен администратором (administratively down). Вызовите на выполнение утилиту управления конфигурацией и введите команду no shutdown в определение интерфейса BRI. В приглашении к вводу exec-команды введите команду clear interface bri для обеспечения перезапуска интерфейса BRI.
Некачественная кабельная разводка. Убедитесь в том, что применяется кабель RJ-45 с прямым подключением выводов. Для проверки кабеля RJ- 45 расположите его разъемы рядом друг с другом. Если проводники кабеля подведены к контактам в одинаковом порядке, это означает, что кабель имеет прямое подключение. Если же проводники подведены к контактам в обратном порядке, то кабель имеет обратное подключение выводов. Проследите за тем, чтобы был установлен подходящий кабель и чтобы он работал исправно.
1 Таблица 16.5. Поля вывода команды show isdn status для BRI
Поле
Описание
Для порта ISDN BRI маршрутизатора может потребоваться устройство NTI. В сети ISDN устройство NT1 обеспечивает создание интерфейса между оборудованием СРЕ и коммутационным оборудованием центральной АТС. Если маршрутизатор не имеет внутреннего устройства NT1, необходимо приобрести и подключить устройство NT1 к порту BRI. Убедитесь в том, что интерфейс BRI или терминальный адаптер подключен к порту S/Т устройства NT1. Обратитесь к документации изготовителя, чтобы проверить, правильно ли функционирует внешнее устройство NT1.
Не функционирует канал. Обратитесь к оператору связи, чтобы подтвердить работоспособность соединения и проверить значения параметров с определением типа коммутатора.
Неисправен маршрутизатор. Убедитесь в том, что маршрутизатор функционирует правильно. Если есть неисправные или работающие со сбоями аппаратные средства, замените их по мере необходимости
Layer 2 Status:
Проверьте значения параметров, которые задают тип коммутатора и идентификаторы SPID (Service Profile Identifier — идентификатор услуги и ли-
State =
TEI_ASSIGNED
нии). Установка параметров коммутатора Interface Specific ISDN перекрывает установку параметров коммутатора Global. В строке состояния SPID может находиться значение Valid или Invalid, которое показывает, приняты ли коммутатором значения SPID.
Обратитесь к провайдеру служб, чтобы проверить значения параметров в конфигурации маршрутизатора.
Для изменения значений параметров SPID вызовите на выполнение команду конфигурации интерфейса isdn spidn, где л — 1 или 2, в зависимости от рассматриваемого канала. Для удаления указанного SPID воспользуйтесь формой этой команды с префиксом по.
isdn spidn spid-number [Idn]
no isdn spidn spid-number [Idn]
Описание синтаксиса
spid-number. Номер, обозначающий службу, абонентом которой является пользователь. Это значение присваивается провайдером служб ISDN и обычно состоит из 10 цифр (телефонный номер с дополнительными цифрами).
Idn. (Необязательный параметр.). Номер локального каталога (LDN — Local Directory Number), который представляет собой номер из семи цифр, назначенный провайдером служб. Эта информация передается коммутатором во входящем сообщении начальной установки. Если в команду не включен параметр с обозначением локального каталога, то доступ к коммутатору разрешен, но другие В-каналы могут не иметь возможности получать входящие вызовы.
Для контроля над процессами согласования уровня 2 между коммутатором и маршрутизатором применяется привилегированная exec-команда debug isdn q921. Отладочные команды q921 описаны в документе Debug Command Reference. Команды debug потребляют значительное количество ресурсов процессора, поэтому при их использовании следует соблюдать осторожность
5200-1# show isdn status
Global ISDN Switchtype = primary-5ess
ISDN SerialO:23 interface
dsl 0, interface ISDN Switchtype = primary-5ess
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Activated dsl 0 CCBs = 0
The Free Channel Mask: 0x807FFFFF
Total Allocated ISDN CCBs = 0 5200-1#
Если команда show isdn status не работает или не показывает состояние интерфейса PRI, воспользуйтесь командой show isdn service. Убедитесь в том, что в состав конфигурации включена команда pri-group в определении контроллера Т1/Е1, которое входит в эту конфигурацию. Если эта команда отсутствует, откорректируйте конфигурацию контроллера, введя в нее команду pri-group.
Ниже приведен пример конфигурации маршрутизатора Cisco с многоканальной платой Т1.
controller tl 0
framing esf
line code b8zs
pri-group timeslots 1-24
В табл. 16.6 описаны поля в выводе команды show isdn status.
Таблица 16.6. Поля вывода команды show isdn status для PRI;
Поле
Описание
Layer 1 Status: DEACTIVATED
Это состояние указывает, что интерфейс PRI не обнаруживает в канале признаков фреймирования Т1/Е1. Существует несколько возможных причин такой ситуации.
Интерфейс PRI закрыт. Проверьте, имеется ли в составе конфигурации команда shutdown в определении интерфейса serialO:23, или проверьте в выводе команды show interfaces наличие указаний на то, что интерфейс остановлен администратором (administratively down). Вызовите на выполнение утилиту управления конфигурацией и введите команду по shutdown в определение интерфейса PRI. В приглашении к вводу ехес- команды введите команду clear controller Т1/Е1 л для обеспечения перезапуска интерфейса PRI.
Некачественная кабельная разводка. Убедитесь в том, что применяется кабель RJ-45 с прямым подключением выводов. Для проверки кабеля RJ- 45 расположите его разъемы рядом друг с другом. Если проводники кабеля подведены к контактам в одинаковом порядке, это означает, что кабель имеет прямое подключение. Если же проводники подведены к контактам в обратном порядке, то кабель имеет обратное подключение выводов. Проследите за тем, чтобы был установлен подходяший кабель и чтобы он работал исправно.
Поле
Описание
He функционирует канал. Обратитесь к оператору связи, чтобы подтвердить работоспособность соединения и проверить значения параметров с определением типа коммутатора.
Неисправен маршрутизатор. Убедитесь в том, что маршрутизатор функционирует правильно. Если есть неисправные или работающие со сбоями аппаратные средства, замените их по мере необходимости
Layer 2 Status:
Проверьте значения параметров, которые задают тип коммутатора. Уста-
State =
TEI_ASSIGNED
новка параметров коммутатора Interface Specific ISDN перекрывает установку параметров коммутатора Global. Убедитесь в том, что настройка конфигурации канала Т1/Е1 выполнена в соответствии с характеристиками коммутатора оператора связи. (Нарушения в работе канала Т1/Е1 описаны в главе 15.)
Чтобы проследить за тем, как происходит согласование параметров протокола уровня 2 между коммутатором и маршрутизатором, воспользуйтесь привилегированной exec-командой debug isdn q921. Процедура отладки с применением команд debug q921 описана в документе Debug Command Reference. Выполнение команд debug требует потребления значительной части ресурсов процессора, поэтому необходимо соблюдать осторожность при их использовании
Number of Calls Call Control Blocks in Use Total Allocated ISDN Call Control Blocks
В этих полях приведены значения, которые показывают количество обрабатываемых вызовов (Number of Calls) и объем ресурсов, распределенных для их обработки. Если общее количество распределенных блоков ССВ (Total Allocated ISDN Call Control Blocks) превышает количество используемых блоков ССВ (Call Control Blocks in Use), это может указывать на нарушения в процессе освобождения блоков ССВ. Убедитесь в том, что имеется достаточное количество доступных блоков ССВ для обработки входящих вызовов
Маршрутизация с набором номера по требованию: операции интерфейса номеронабирателя
Маршрутизация с набором номера по требованию (DDR — Dial-on-Demand Routing) представляет собой экономически выгодный метод установления связи в распределенной сети по мере необходимости, который может применяться для создания первичного канала или резервирования некоммутируемого последовательного канала.
В качестве интерфейса номеронабирателя может применяться любой интерфейс маршрутизатора, способный выполнять или принимать вызовы. Этот универсальный термин следует отличать от термина интерфейс Номеронабирателя (с прописной буквой Н; в английском варианте — Dialer с прописной буквой D), который служит для обозначения логического интерфейса, предназначенного для управления одним или несколькими физическими интерфейсами маршрутизатора; такой интерфейс обозначается в конфигурации маршрутизатора как interface Dialer X. В последующем изло-
жении термин интерфейс номеронабирателя всегда используется в его первоначальном смысле, если не указано иное.
Информация о конфигурации интерфейса номеронабирателя может быть представлена в двух разновидностях: с использованием команд привязки номеронабирателя (такой метод обозначения иногда называют традиционным методом DDR) и с помощью профилей номеронабирателя. Выбор того или иного метода обозначения зависит от обстоятельств, при которых необходимо обеспечивать коммутируемую связь. Метод DDR на основе команд привязки номеронабирателя (dialer map) был впервые введен в IOS 9.0, а профили номеронабирателя были введены в IOS 11.2.
Активизация набора номера
По сути метод DDR представляет собой просто расширение способа маршрутизации, при котором пакеты, представляющие интерес для службы доставки, перенаправляются в интерфейс номеронабирателя и активизируют попытку набора номера. Ниже описаны понятия, лежащие в основе определения так называемого интересующего трафика, и рассмотрены способы маршрутизации соединений DDR.
Интересующие пакеты
При описании сетей, в которых для доставки пакетов устанавливаются коммутируемые соединения, применяется термин интересующий. Этот термин служит для обозначения пакетов, которые либо активизируют попытку набора номера, либо сбрасывают таймер простоя в интерфейсе номеронабирателя, если коммутируемый канал уже активен. Интересующим считается только такой пакет, который имеет следующие характеристики.
Пакет должен соответствовать критериям "permit", которые определены в списке доступа.
В списке номеронабирателя должна иметься ссылка на такой список доступа, или пакет должен принадлежать к трафику протокола, безусловно разрешенному командой dialer-list.
Список номеронабирателя должен быть закреплен за интерфейсом номеронабирателя с помощью команды dialer-group.
По умолчанию никакие пакеты не рассматриваются как интересующие. Определения интересующих пакетов должны быть явно заданы в конфигурации маршрутизатора или сервера доступа.
Группа номеронабирателя
В состав конфигурации каждого интерфейса номеронабирателя в маршрутизаторе или сервера доступа должна входить команда dialer-group. Если команда dialer-group в конфигурации отсутствует, то нет и логической связи между определениями интересующих пакетов и интерфейсом. Синтаксическая структура этой команды приведена ниже.
dialer-group [group number]
Здесь group-number представляет собой номер группы доступа номеронабирателя, к которой относится конкретный интерфейс. Эта группа доступа должна быть определена с помощью команды dialer-list. Допустимыми значениями этого параметра являются ненулевые положительные целые числа от 1 до 10.
Любой интерфейс может быть связан только с одной группой доступа номеронабирателя; применение нескольких присваиваний с помощью команд dialer-group не допускается. Второе присваивание группы доступа номеронабирателя отменяет первое. Группа доступа номеронабирателя может быть определена с помощью команды dialer-group. Команда dialer-list устанавливает соответствие между списком доступа и группой доступа номеронабирателя.
Пакеты, соответствующие определению указанной группы номеронабирателя, активизируют попытку установления соединения.
Адрес назначения пакета проверяется по списку доступа, заданному в соответствующей команде dialer-list. Если адрес соответствует определению списка, то либо инициализируется вызов (если коммутируемое соединение еще не установлено), либо сбрасывается таймер простоя (если коммутируемое соединение уже установлено после какого-либо вызова).
Список номеронабирателя
Для определения списка номеронабирателя DDR, предназначенного для управления набором номера с учетом типа протокола или сочетания типа протокола и списка доступа, применяется глобальная команда конфигурации dialer-list. Интересующими считаются пакеты, которые относятся к трафику протокола, разрешенного глобально, или пакеты, которые разрешены согласно списку в команде dialer-list.
dialer-list dialer-group protocol protocol-name (permit | deny | list access-list- number | access-group^
dialer-group. Номер группы доступа номеронабирателя, которая может быть определена в любой команде конфигурации интерфейса dialer-group.
protocol-name. Ключевое слово, обозначающее протокол: appletalk, bridge, tins, clns_es, clns_is, decnet, decnet_router-Ll, decnet_router-L2, decnet_node, ip, ipx, vines или xns.
permit. Разрешен неограниченный доступ к средствам протокола.
deny. Доступ к средствам протокола полностью запрещен.
list. Для определения трафика, который имеет доступ к средствам протокола, будет использоваться список доступа.
access-list-number. Номер списка доступа, применяемого в команде dialer-list для определения того, какой трафик является интересующим. Могут быть заданы номера любых стандартных или расширенных списков доступа, в том числе для протоколов DECnet, Banyan VINES, IP, Novell IPX, XNS и протоколов мостовой маршрутизации. Поддерживаемые типы и номера списков доступа приведены в табл. 16.7.
access-group. Имя списка, используемое в командах tins filter-set и tins access-group.
|Таблица 16.7. Нумерация списков доступа в соответствий с протоколом ;<|
Тип списка доступа
Диапазон номеров списков доступа (десятичные числа)
AppleTalk
600-699
Banyan VINES (стандартный)
1-100
Banyan VINES (расширенный)
101-200
DECnet
300-399
IP (стандартный)
1-99
IP (расширенный)
100-199
Novell IPX (стандартный)
800-899
Novell IPX (расширенный)
900-999
Протокол прозрачного мостового перенаправления
200-299
XNS
500-599
Список доступа
Настройка конфигурации списка доступа может быть выполнена для каждого сетевого протокола, трафик которого должен передаваться через коммутируемое соединение. Если предусмотрена повременная оплата за использование соединения, то обычно желательно определить конфигурацию списка доступа таким образом, чтобы он исключал возможность открывать или поддерживать соединения для некоторого трафика (такого как обновления маршрутизации). Следует отметить, что списки доступа создаются только в целях определения интересующего и неинтересующего трафика, и мы не утверждаем, что неинтересующие пакеты не могут проходить через коммутируемый канал, и хотим лишь подчеркнуть, что такие пакеты не могут сами сбрасывать таймер простоя или же активизировать соединение. После того как коммутируемое соединение установлено, неинтересующие пакеты также получают возможность проходить через канал.
Например, в маршрутизаторе, в котором в качестве маршрутизирующего протокола применяется EIGRP, можно выполнить настройку конфигурации списка доступа таким образом, чтобы пакеты EIGRP были объявлены как неинтересующие, а весь остальной трафик IP — как интересующий.
access-list 101 deny eigrp any any
access-list 101 permit ip any any
Настройка конфигурации списков доступа может быть выполнена для всех протоколов, трафик которых проходит через коммутируемый канал. Следует помнить, что для любого протокола при отсутствии в списке доступа оператора permit по умолчанию применяется подход, предусматривающий запрет всего трафика. Если для протокола не задан список доступа и трафик протокола не разрешен командой dialer-list, то пакеты, передаваемые по этому протоколу, рассматриваются как неинтересующие. Но фактически на практике, если для протокола не задан список номеронабирателя, его пакеты вообще не будут проходить через канал.
Итоговый пример
После рассмотрения всех понятий организации работы коммутируемого канала можно перейти к описанию всего процесса определения интересующего статуса паке-
та. В данном примере предусмотрено, что через коммутируемый канал может проходить трафик протоколов IP и IPX, но пользователь желает исключить возможность инициализации вызова или поддержки соединения под действием пакетов широковещательной рассыпки и обновлений маршрутизации.
!
interface async 1
dialer-group 7 ।
access-list 121 deny eigrp any any
access-list 121 deny ip any host 255.255.255.255
access-list121permit ip any any
access-list903deny-1FFFFFFFF0FFFFFFFF452
access-list903deny-1FFFFFFFF0FFFFFFFF453
access-list903deny-1FFFFFFFF0FFFFFFFF457
access-list 903 permit -1
I
dialer-list 7 protocol ip list 121
dialer-list 7 protocol ipx list 903 I
Если пакет при передаче через интерфейс async 1 должен рассматриваться как интересующий, вначале необходимо разрешить его передачу по каналу с помощью операторов access-list 121. В данном случае запрещена передача пакетов EIGRP, как и всех других широковещательных пакетов, а весь остальной трафик IP разрешен. Следует помнить, что такая конфигурация не исключает возможность прохождения пакетов EIGRP по каналу; просто эти пакеты не могут сбрасывать таймер простоя или инициализировать попытку набора номера.
Аналогичным образом оператор access-list 903 объявляет запросы IPX RIP, SAP и GNS как неинтересующие, тогда как весь остальной трафик IPX является интересующим. Без этих операторов deny рассматриваемое коммутируемое соединение, по-видимому, никогда бы не закрывалось, и пользователь получал бы от телефонной компании очень большие счета, поскольку пакеты такого типа постоянно движутся по сети IPX.
В конфигурацию этого асинхронного интерфейса введена команда dialer-group 7, поскольку она должна связать фильтры интересующего трафика (т.е. списки доступа) с определением интерфейса. Для каждого протокола требуется один оператор dialerlist (и только один может быть введен в конфигурацию), а это позволяет следить за тем, чтобы номер списка номеронабирателя совпадал с номером группы номеронабирателя для данного интерфейса.
Необходимо еше раз подчеркнуть, что операторы deny в списках доступа, введенных в конфигурацию для определения интересующего трафика, не исключают возможность прохождения по каналу пакетов, запрещенных этими операторами.
Команда debug dialer позволяет наблюдать за тем, какие действия приводят к активизации попытки набора номера.
Dialing cause: Asyncl: ip (s=172.16.1.111 d=172.16.2.22)
Здесь показано, что трафик IP с адресом отправителя 172.16.1.111 и адресом получателя 172.16.2.22 активизировал попытку набора номера в интерфейсе Asyncl.
Маршрутизация
Теперь, после определения категории интересующих пакетов, необходимо обеспечить их правильное перенаправление, поскольку без этого невозможно инициализировать вызов. Процесс маршрутизации может осуществляться при двух условиях: должны быть заполнены записи таблицы маршрутизации, а интерфейс, в который перенаправляются пакеты, должен находиться в рабочем состоянии.
Интерфейсы находятся в состоянии up/up (имитированном)
Пакеты могут перенаправляться в интерфейс и проходить через него, только если сам интерфейс и протокол канала связи находятся в рабочем состоянии (up/up), как показано в приведенном ниже выводе команды show interfaces. Такое состояние сокращенно обозначается как up/up.
Montecito# show interfaces ethernet 0
EthernetO is up, line protocol is up
Hardware is Lance, address is . . .
Но если соединение через интерфейс номеронабирателя еще не установлено, то в нем не может функционировать программное обеспечение протокола канала связи, поэтому не может действовать и сам интерфейс. Это означает, что маршруты, проходящие через такой интерфейс, будут исключены из таблицы маршрутизации, а трафик не будет перенаправляться в интерфейс. Таким образом, инициализация каких-либо вызовов через интерфейс становится невозможной.
С учетом такой возможности любой интерфейс, который применяется в качестве интерфейса номеронабирателя (например, последовательный или асинхронный интерфейс, в состав конфигурации которого входит команда dialer in-band или dialer dtr) или фактически является интерфейсом номеронабирателя (например, интерфейсы BRI и PRI), должен находиться в состоянии имитации готовности к работе интерфейса и протокола канала передачи данных, которое сокращенно обозначается up/up (spoofing).
Montecito# show interfaces bri 0
BRIO is up, line protocol is up (spoofing)
Hardware is BRI
Internet address is . . .
Иными словами, должно имитироваться состояние up/up интерфейса, чтобы связанные с ним маршруты оставались в силе и существовала возможность перенаправлять пакеты в этот интерфейс.
В некоторых обстоятельствах интерфейс номеронабирателя не находится в состоянии up/up (spoofing). Вывод команды show interfaces может показать, что интерфейс остановлен администратором.
Montecito# show interfaces bri О
BRIO is administratively down, line protocol is down
Hardware is BRI
Internet address is . . .
Если интерфейс обозначен как остановленный администратором (administratively down), это просто означает, что в состав его конфигурации входит команда shutdown. Это состояние установлено по умолчанию для любого интерфейса маршрутизатора
при самой первой загрузке маршрутизатора. Чтобы выйти из такой ситуации, воспользуйтесь командой конфигурации интерфейса no shutdown.
В выводе команды show interfaces может быть также показано, что интерфейс находится в режиме резервирования (standby mode):
Montecito# show interfaces bri 0
BRIO is standby mode, line protocol is down
Hardware is BRI
Internet address is . . .
Такое состояние указывает, что конфигурация интерфейса настроена на его использование в качестве резерва для другого интерфейса. Интерфейс номеронабирателя может быть настроен для использования в качестве резерва, если требуется дублирование соединения на случай отказа. Такая конфигурация может быть создана путем ввода следующих команд в конфигурацию интерфейса основного соединения:
backup interface [interface]
backup delay [enable-delay] [disable-delay]
После ввода в конфигурацию команды backup interface интерфейс, применяемый в качестве резервного, находится в режиме резервирования до тех пор, пока основной интерфейс не перейдет в состояние останова интерфейса и останова протокола канала передачи данных, которое сокращенно обозначается как down/down. В этот момент интерфейс номеронабирателя, подготовленный для использования в качестве резервного, переходит в состояние up/up (spoofing) и принимает на себя обработку события, требующего набора номера.
Статические и плавающие статические маршруты
Наиболее надежный способ перенаправления пакетов в интерфейс номеронабирателя состоит в использовании статической маршрутизации. Статические маршруты вводятся в конфигурацию маршрутизатора или сервера доступа вручную с помощью следующей команды:
ip route prefix mask {address | interface) [distance]
prefix. Префикс маршрута IP для адреса назначения.
mask. Префиксная маска для адреса назначения.
address. IP-адрес следующего транзитного перехода, который позволяет достичь сети назначения.
interface. Сетевой интерфейс, применяемый для исходящего трафика.
distance. (Необязательный параметр.) Административное расстояние. Этот параметр используется при определении плавающих статических маршрутов.
Статические маршруты применяются в тех ситуациях, когда коммутируемый канал является единственным соединением с удаленным узлом. Статический маршрут имеет административно заданное значение расстояния distance, равное 1, поэтому имеет более высокий приоритет по сравнению с динамическими маршрутами к тому же месту назначения.
С другой стороны, плавающие статические маршруты (т.е. статические маршруты, в которых расстояние distance задается явно, а не применяется значение, предусмотренное по умолчанию) обычно используются в таких конфигурациях, когда метод
маршрутизации DDR с набором номера по требованию служит в качестве резервного; в этом случае для перенаправления пакетов по основному каналу предназначен такой динамический маршрутизирующий протокол, как RIP или EIGRP. Если должен применяться обычный статический маршрут, то предусмотренное для него административное расстояние, равное 1, сделает его предпочтительным по сравнению с EIGRP (с расстоянием 75) или RIP (с расстоянием 120), поэтому пакеты маршрутизирующего протокола будут перенаправляться через коммутируемый канал, даже если основной канал является работоспособным и может передавать трафик. Но если в конфигурацию статического маршрута введено значение административного расстояния, превышающее соответствующее значение для любого из динамических маршрутизирующих протоколов, применяемых в маршрутизаторе, то плавающий статический маршрут будет использоваться только в отсутствии лучшего маршрута, т.е. маршрута с меньшим административным расстоянием.
Если же применение резервных средств маршрутизации DDR основано на использовании команды backup interface, то ситуация становится немного иной. Поскольку интерфейс номеронабирателя остается в режиме резервирования то тех пор, пока работоспособен основной интерфейс, то в его конфигурацию можно вводить и статический, и плавающий статический маршрут, но попытки подключения через интерфейс номеронабирателя не будут предприниматься до тех пор, пока основной интерфейс не перейдет в состояние down/down.
Для любого конкретного соединения количество необходимых статических (или плавающих статических) маршрутов зависит от того, как организована адресация интерфейсов номеронабирателя. В тех случаях, если два интерфейса номеронабирателя (по одному на каждом из двух маршрутизаторов) относятся к обшей сети или подсети, как правило, требуется только один статический маршрут, указывающий на другую локальную сеть, с использованием адреса интерфейса номеронабирателя удаленного маршрутизатора в качестве адреса следующего участка маршрута.
Примеры
Пример 1
Единственным соединением является коммутируемое соединение с пронумерованными интерфейсами, как показано на рис. 16.5. Достаточно иметь только один маршрут.
Е0Е0BRIOBRIOЕ0Е010.1.1.1/2410.1.1.1/24192.168.254.1192.168.254.1BRIO i 192.168.254.2BRIO i 192.168.254.2192.168.10.1/24192.168.10.1/24
Е0
Е0
BRIO
BRIO
Е0
Е0
10.1.1.1/24
10.1.1.1/24
192.168.254.1
192.168.254.1
BRIO i 192.168.254.2
BRIO i 192.168.254.2
192.168.10.1/24
192.168.10.1/24
GoletaGoletaMontecito
Goleta
Goleta
Рис. 16.5. Организация коммутируемого соединения с помощью пронумерованных интерфейсов
Montecito:
ip route 192.168.10.0 255.255.255.0 172.16.20.2
Goleta:
ip route 10.1.1.0 255.255.255.0 172.16.20.1
Пример 2
Единственным соединением является коммутируемое соединение с непронумерованными интерфейсами, как показано на рис. 16.6. Такое соединение можно настроить только с одним маршрутом, но обычно принято вводить в конфигурацию два маршрута: маршрут хоста к интерфейсу локальной сети на удаленном маршрутизаторе и маршрут к другой локальной сети через интерфейс этой локальной сети. Это позволяет предотвратить нарушение форматов при преобразовании фреймов протокола уровня 3 во фреймы протокола уровня 2, что может привести к ошибкам инкапсуляции.
Этот метод может также применяться, если интерфейсы номеронабирателя на двух устройствах являются пронумерованными, но не в одной и той же сети или подсети.
ЕОЕОMontecitoMontecito' BRIO192.168.254.2' BRIO192.168.254.2192.168.10.1/24192.168.10.1/24GoletaGoletaЕОЕО
ЕО
ЕО
Montecito
Montecito
' BRIO
192.168.254.2
' BRIO
192.168.254.2
192.168.10.1/24
192.168.10.1/24
Goleta
Goleta
ЕО
ЕО
Рис. 16.6. Организация коммутируемого соединения с помощью непронумерованных интерфейсов
Montecito:
ip route 192.168.10.0 255.255.255.0 192.168.10.1
ip route 192.168.10.1 255.255.255.255 BRIO
Goleta:
ip route 10.1.1.0 255.255.255.0 10.1.1.1
ip route 10.1.1.1 255.255.255.255 BRIO,
Пример 3
Коммутируемое соединение используется в качестве резервного с пронумерованными интерфейсами, как показано на рис. 16.7. Требуется один плавающий статический маршрут.
Рис. 16.7. Подготовка резервного соединения с помощью пронумерованных интерфейсовРис. 16.7. Подготовка резервного соединения с помощью пронумерованных интерфейсовMontecito:ip route 192.168.10.0 255.255.255.0 172.16.20.2 200Goleta:ip route 10.1.1.0 255.255.255.0 172.16.20.1 200Montecito:ip route 192.168.10.0 255.255.255.0 172.16.20.2 200Goleta:ip route 10.1.1.0 255.255.255.0 172.16.20.1 200
Рис. 16.7. Подготовка резервного соединения с помощью пронумерованных интерфейсов
Рис. 16.7. Подготовка резервного соединения с помощью пронумерованных интерфейсов
Montecito:
ip route 192.168.10.0 255.255.255.0 172.16.20.2 200
Goleta:
ip route 10.1.1.0 255.255.255.0 172.16.20.1 200
Montecito:
ip route 192.168.10.0 255.255.255.0 172.16.20.2 200
Goleta:
ip route 10.1.1.0 255.255.255.0 172.16.20.1 200
Пример 4
Коммутируемое соединение используется в качестве резервного с непронумерованными интерфейсами, как показано на рис. 16.8. Как и в примере 2, этот метод применяется также, если интерфейсы номеронабирателя на двух устройствах являются пронумерованными, но не в одной и той же сети или подсети.
Рис. 16.8. Подготовка резервного соединения с помощью непронумерованных интерфейсов
Montecito:
ip route 192.168.10.0 255.255.255.0 192.168.10.1 200
ip route 192.168.10.1 255.255.255.255 BRIO 200
Goleta:
ip route 10.1.1.0 255.255.255.0 10.1.1.1 200
ip route 10.1.1.1 255.255.255.255 BRIO 200
Команды привязки номеронабирателя
Традиционный метод DDR, основанный на использовании команд привязки номеронабирателя, является мощным и всесторонним, но имеет определенные недостатки, которые ограничивают его масштабируемость и расширяемость. Дело в том, что этот метод DDR предусматривает применение статической привязки между спецификациями вызова, соответствующими каждому адресу назначения и физической конфигурации интерфейса.
Тем не менее метод DDR, основанный на использовании команд привязки номеронабирателя, имеет много преимуществ. Он поддерживает маршрутизацию Frame Relay, ISO CLNS, LAPB, маршрутизацию с периодической фиксацией маршрутов, а также все маршрутизируемые протоколы, которые могут применяться в маршрутизаторах Cisco. По умолчанию метод DDR, основанный на использовании команд привязки номеронабирателя, поддерживает быструю коммутацию.
При настройке конфигурации интерфейса для исходящих вызовов необходимо включить в конфигурацию по одной команде привязки номеронабирателя dialer map для каждого удаленного адреса назначения и для каждого отдельного набираемого номера в этом месте назначения. Например, если необходимо подготовить многоканальное соединение РРР с использованием набора номера из одного интерфейса BRI ISDN в другой интерфейс BRI ISDN, в котором предусмотрены разные номера локального каталога для каждого из В-каналов, необходимо ввести в конфигурацию по одной команде dialer map для каждого из удаленных номеров:
interface bri 0
dialer map ip 172.16.20.1 name Montecito broadcast 5551234
dialer map ip 172.16.20.1 name Montecito broadcast 5554321 i
Может также иметь важное значение последовательность ввода команд dialer map в конфигурацию. Если на один и тот же удаленный адрес ссылаются две или несколько команд привязки номеронабирателя dialer map, то маршрутизатор или сервер доступа пытается применить команды одну за другой в порядке их присутствия в конфигурации до тех пор, пока не будет успешно установлено соединение.
Примечание
Система IOS может динамически формировать команды привязки номеронабирателя в маршрутизаторе, принимающем вызовы. Команда привязки номеронабирателя формируется с учетом имени пользователя, прошедшего проверку подлинности, и согласованного IP-адреса узла — инициатора вызова. Динамические команды привязки номеронабирателя можно обнаружить только в выводе команды show dialer map, и они не появляются в эксплуатационной конфигурации маршрутизатора или сервера доступа.
Синтаксическая структура команды
При настройке конфигурации последовательного интерфейса или интерфейса ISDN для отправки вызовов на один или несколько узлов либо для получения вызовов от нескольких узлов применяется одна из форм команды конфигурации интерфейса dialer map; все опции показаны в первой форме этой команды. В табл. 16.8 описан синтаксис команды dialer map. Для удаления конкретной записи команды dialer map применяется форма этой команды с префиксом по:
dialer map protocol next-hop-address [name hostname] [spc] [speed 56 | 64] [broadcast] [modem-script modem-regexp] [system-script system-regexp] [dial-string]:isdn- subaddress] ]
При настройке конфигурации последовательного интерфейса или интерфейса ISDN для выполнения вызова, направленного на несколько узлов, а также для аутентификации вызовов, принимаемых от нескольких узлов, используется вторая форма команды dialer map:
dialer map protocol next-hop-address [name hostname] [spc] [speed 56 | 64] [broadcast] [dial-string]:isdn-subaddress]]
При настройке конфигурации последовательного интерфейса или интерфейса ISDN для поддержки мостового соединения используется третья форма этой команды: dialer map bridge [name hostname] [spc] [broadcast] [ dial-string]:isdn-subaddress]]
При настройке конфигурации асинхронного интерфейса для выполнения вызова одного узла, требующего применения системного сценария или не имеющего назначенного сценария модема, либо нескольких узлов, подключенных к одному каналу, к нескольким каналам или к чередующейся группе номеронабирателя, применяется четвертая форма команды dialer map:
dialer map protocol next-hop-address [name hostname] [broadcast] [modem-script modemregexp] [system-script system-regexp] [dial-string]
i Таблица 16.8. Описание синтаксиса команды dialer map
Параметр
Описание
protocol
Ключевое слово, обозначающее протокол: appletalk, bridge, tins, decnet, ip, ipx, novell, snapshot, vines и xns
next-hopaddress
Протокольный адрес, сопоставляемый с адресами назначения пакетов. Этот параметр не используется с ключевым словом bridge, обозначающим протокол
name
(Необязательный параметр.) Идентификатор удаленной системы, с которой взаимодействует локальный маршрутизатор или сервер доступа. Применяется для проверки подлинности удаленной системы при обработке входящих вызовов
hostname
(Необязательный параметр.) Чувствительное к регистру имя (или идентификатор) удаленного устройства (обычно имя хоста). Если команда dialer map используется для определения конфигурации маршрутизаторов с интерфейсами ISD, то параметр hostname может содержать номер, предоставляемый идентификатором CLID (который иногда именуется идентификатором ANI), при условии, что применяется идентификация вызывного канала
spc
(Необязательный параметр.) Опция, которая указывает на наличие полупо- стоянного соединения между оборудованием клиента и АТС; используется только в Германии для соединений между интерфейсом BRI ISDN и коммутатором ITR6 ISDN и в Австралии — для соединений между интерфейсом PRI ISDN и коммутатором TS-0I4
speed 56 | 64
(Необязательный параметр.) Ключевое слово и значение, указывающее применяемую скорость канала в килобитах в секунду. Используется только для ISDN. Значение скорости, применяемое по умолчанию, равно 64 Кбит/с
broadcast
(Необязательный параметр.) Протокольный адрес, по которому должны передаваться пакеты широковещательной рассылки
modem-script
(Необязательный параметр.) Сценарий модема, который используется для данного соединения (параметр применяется для асинхронных интерфейсов)
modem-regexp
(Необязательный параметр.) Регулярное выражение, с которым сопоставляется имя сценария модема (параметр применяется для асинхронных интерфейсов)
system-script
(Необязательный параметр.) Системный сценарий, который используется дтя данного соединения (параметр применяется для асинхронных интерфейсов)
system-regexp
(Необязательный параметр.) Регулярное выражение, с которым сопоставляется имя системного сценария (параметр применяется для асинхронных интерфейсов)
dialstring: isdn- subaddress
(Необязательный параметр.) Номер телефона, передаваемый в наборное устройство при обнаружении пакетов с указанным адресом следующего участка маршрута, который соответствует определенным спискам доступа, и дополнительный номер субадреса, используемый дтя многоточечных соединений ISDN.
Если в команде используются параметры dial-string:isdn-subaddress (строка набора номера и субадрес ISDN), они должны быть заданы в командной строке в последнюю очередь
Профили номеронабирателя
Реализация профилей номеронабирателя в методе DDR, которая была впервые введена в версии IOS 11.2, основана на раздельном представлении логической и физической конфигураций интерфейса. Профили номеронабирателя позволяют также динамически связывать между собой логическую и физическую конфигурации при обработке каждого отдельного вызова.
Примечание
В отличие от предыдущих разделов, в настоящем разделе термин интерфейс номеронабирателя относится к интерфейсу, который определен в конфигурации, а не к физическому интерфейсу маршрутизатора или сервера доступа.
Метод, основанный на использовании профилей номеронабирателя, является наиболее приемлемым, если необходимо обеспечить совместное использование интерфейса (ISDN, асинхронного или синхронного последовательного) для выполнения или приема вызовов, изменения любых параметров конфигурации с учетом требований конкретных пользователей (кроме параметров инкапсуляции, применяемых на первом этапе обработки профилей номеронабирателя), создания мостовых соединений со многими адресами назначения, а также предотвращения проблем, обусловленных возникновением расщепления горизонта.
Профили номеронабирателя позволяют отделить конфигурацию физических интерфейсов от логической конфигурации, требуемой при обработке вызова, а также позволяют динамически связывать между собой логическую и физическую конфигурации при обработке каждого отдельного вызова.
Профиль номеронабирателя состоит из следующих элементов:
конфигурация интерфейса номеронабирателя (логический объект), состоящая из одной или нескольких строк набора номера (каждая из которых может применяться для достижения одной подсети назначения);
класс команд привязки номеронабирателя, который определяет все характеристики для любого набора указанной строки набора номера;
упорядоченный пул физических интерфейсов номеронабирателя, который должен применяться для данного интерфейса номеронабирателя.
Для всех вызовов, направленных или исходящих из одной и той же подсети назначения, применяется один и тот же профиль номеронабирателя.
Конфигурация интерфейса номеронабирателя включает все параметры настройки, необходимые для достижения конкретной подсети назначения (и любой сети, достижимой через нее). Для одного и того же интерфейса номеронабирателя можно указать несколько строк набора номера и сопоставить каждую строку набора номера с отдельным классом команд привязки номеронабирателя. Класс команд привязки номеронабирателя включает все характеристики, необходимые для указанной строки набора номера. Например, в классе команд привязки номеронабирателя для одного адреса назначения может быть указана скорость 56 Кбит/с в соединении ISDN, а в классе команд привязки номеронабирателя для другого адреса назначения может быть указана скорость 64 Кбит/с в соединении ISDN.
Для каждого интерфейса номеронабирателя используется пул номеронабирателя: пул физических интерфейсов, упорядоченный с учетом приоритета, назначенного ка-
ждому физическому интерфейсу. Любой физический интерфейс может принадлежать к нескольким пулам номеронабирателя, а разрешение конфликтов происходит с учетом его приоритета. Для интерфейсов BRI и PRI ISDN может быть установлено минимальное и максимальное количество В-каналов, зарезервированных для тех или иных пулов номеронабирателя. Канал, зарезервированный для пула номеронабирателя, остается свободным до тех пор, пока в этот пул не будет перенаправлен трафик.
Если для определения средств маршрутизации DDR используются профили номеронабирателя, физические интерфейсы не имеют параметров конфигурации, кроме тех, что определяют метод инкапсуляции и пулы номеронабирателя, к которым принадлежит интерфейс.
Примечание
Из правила, сформулированного в предыдущем абзаце, есть одно исключение: если перед аутентификацией выполняются какие-либо команды, то они должны быть введены в конфигурацию физического интерфейса (или BRI или PRI), а не в профиль номеронабирателя. Профили номеронабирателя не позволяют копировать команды аутентификации РРР (или команды LCP) в физический интерфейс.
На рис. 16.9 показан типичный пример применения профилей номеронабирателя. Маршрутизатор А имеет интерфейс номеронабирателя 1 для маршрутизации с набором номера по требованию с подсетью 1.1.1.0 и интерфейс номеронабирателя 2 для маршрутизации с набором номера по требованию с подсетью 2.2.2.0. IP-адрес для интерфейса номеронабирателя 1 представляет собой адрес этого интерфейса как узла в сети 1.1.1.0; в то же время этот IP-адрес служит в качестве IP-адреса физического интерфейса, используемого интерфейсом номеронабирателя 1. Аналогичным образом, IP-адрес для интерфейса номеронабирателя 2 представляет собой адрес этого интерфейса как узла в сети 2.2.2.0.
Сеть 5Сеть 5Сеть 6Сеть 6Сеть?Сеть?Сеть 8Сеть 8Сеть 4Сеть 4/ Маршрутизаторе "находится в подсети 2.2.2.0 и предоставляет доступ к сетям 6-8/ Маршрутизаторе "находится в подсети 2.2.2.0 и предоставляет доступ к сетям 6-8Маршрутизатор В X находится в подсети 1.1.1. О' и предоставляет доступ к сетям 3-5Маршрутизатор В X находится в подсети 1.1.1. О' и предоставляет доступ к сетям 3-5Интерфейс номеронабирателя для подсети 1.1.1.0 предоставляет доступ ко всем сетям.Интерфейс номеронабирателя для подсети 2.2.2.0 предоставляет доступ ко всем сетямИнтерфейс номеронабирателя для подсети 1.1.1.0 предоставляет доступ ко всем сетям.Интерфейс номеронабирателя для подсети 2.2.2.0 предоставляет доступ ко всем сетям
Сеть 5
Сеть 5
Сеть 6
Сеть 6
Сеть?
Сеть?
Сеть 8
Сеть 8
Сеть 4
Сеть 4
/ Маршрутизаторе "находится в подсети 2.2.2.0 и предоставляет доступ к сетям 6-8
/ Маршрутизаторе "находится в подсети 2.2.2.0 и предоставляет доступ к сетям 6-8
Маршрутизатор В X находится в подсети 1.1.1. О' и предоставляет доступ к сетям 3-5
Маршрутизатор В X находится в подсети 1.1.1. О' и предоставляет доступ к сетям 3-5
Интерфейс номеронабирателя для подсети 1.1.1.0 предоставляет доступ ко всем сетям.
Интерфейс номеронабирателя для подсети 2.2.2.0 предоставляет доступ ко всем сетям
Интерфейс номеронабирателя для подсети 1.1.1.0 предоставляет доступ ко всем сетям.
Интерфейс номеронабирателя для подсети 2.2.2.0 предоставляет доступ ко всем сетям
Рис. 16.9. Типичный пример применения профилей номеронабирателя
В интерфейсе номеронабирателя используется только один пул номеронабирателя. Однако физический интерфейс может быть членом одного или нескольких пулов но-
меронабирателя, а любой пул номеронабирателя может иметь в качестве членов несколько физических интерфейсов.
На рис. 16.10 иллюстрируются взаимосвязи между понятиями интерфейса номеронабирателя, пула номеронабирателя и физического интерфейса. В интерфейсе номеронабирателя 0 используется пул номеронабирателя 2. Физический интерфейс BRI 1 принадлежит пулу номеронабирателя 2 и имеет конкретный приоритет в этом пуле. Физический интерфейс BRI 2 также принадлежит пулу номеронабирателя 2. Поскольку конфликты разрешаются с учетом уровней приоритетов физических интерфейсов в пуле, интерфейсам BRI 1 и BRI 2 должны быть назначены разные приоритеты в пуле. Предположим, что в пуле номеронабирателя 2 интерфейсу BRI 1 назначен приоритет 100, а интерфейсу BRI — приоритет 50 (приоритет 50 выше, чем приоритет 100). Интерфейс BRI 2 имеет в этом пуле более высокий приоритет, и поэтому поступающие через него вызовы будут выполняться в первую очередь.
Рис. 16.10. Взаимосвязи между понятиями интерфейса номеронабирателя, пула номеронабирателя и физического интерфейсаРис. 16.10. Взаимосвязи между понятиями интерфейса номеронабирателя, пула номеронабирателя и физического интерфейса
Рис. 16.10. Взаимосвязи между понятиями интерфейса номеронабирателя, пула номеронабирателя и физического интерфейса
Рис. 16.10. Взаимосвязи между понятиями интерфейса номеронабирателя, пула номеронабирателя и физического интерфейса
1234567812345678Создать интерфейс номеронабирателяЗадать IP-адрес и маску интерфейса номеронабирателя для определения вызываемого узла в сети назначения Определить метод инкапсуляции РРРУказать аутентификационное имя CHAP удаленного маршрутизатораЗадать вызываемый удаленный адрес назначения и класс команд привязки, который определяет характеристики вызова этого адреса назначенияУказать пул наборных устройств, используемых для вызова данного адреса назначенияПрисвоить интерфейс номеронабирателя группе номеронабирателяУказать список доступа по номеру списка или по протоколу и номеру списка, чтобы определить интересующие пакеты, которые могут активизировать вызовСоздать интерфейс номеронабирателяЗадать IP-адрес и маску интерфейса номеронабирателя для определения вызываемого узла в сети назначения Определить метод инкапсуляции РРРУказать аутентификационное имя CHAP удаленного маршрутизатораЗадать вызываемый удаленный адрес назначения и класс команд привязки, который определяет характеристики вызова этого адреса назначенияУказать пул наборных устройств, используемых для вызова данного адреса назначенияПрисвоить интерфейс номеронабирателя группе номеронабирателяУказать список доступа по номеру списка или по протоколу и номеру списка, чтобы определить интересующие пакеты, которые могут активизировать вызовinterface dialer number ip address address maskinterface dialer number ip address address maskencapsulation ppp dialer remote-name usernamedialer string dial-string class class-nameencapsulation ppp dialer remote-name usernamedialer string dial-string class class-namedialer pool numberdialer pool numberdialer-group group-numberdialer-group group-numberdialer-list dialer-group protocol protocol-name {permit | deny | list access-list-number}dialer-list dialer-group protocol protocol-name {permit | deny | list access-list-number}
1
2
3
4
5
6
7
8
1
2
3
4
5
6
7
8
Создать интерфейс номеронабирателя
Задать IP-адрес и маску интерфейса номеронабирателя для определения вызываемого узла в сети назначения Определить метод инкапсуляции РРР
Указать аутентификационное имя CHAP удаленного маршрутизатора
Задать вызываемый удаленный адрес назначения и класс команд привязки, который определяет характеристики вызова этого адреса назначения
Указать пул наборных устройств, используемых для вызова данного адреса назначения
Присвоить интерфейс номеронабирателя группе номеронабирателя
Указать список доступа по номеру списка или по протоколу и номеру списка, чтобы определить интересующие пакеты, которые могут активизировать вызов
Создать интерфейс номеронабирателя
Задать IP-адрес и маску интерфейса номеронабирателя для определения вызываемого узла в сети назначения Определить метод инкапсуляции РРР
Указать аутентификационное имя CHAP удаленного маршрутизатора
Задать вызываемый удаленный адрес назначения и класс команд привязки, который определяет характеристики вызова этого адреса назначения
Указать пул наборных устройств, используемых для вызова данного адреса назначения
Присвоить интерфейс номеронабирателя группе номеронабирателя
Указать список доступа по номеру списка или по протоколу и номеру списка, чтобы определить интересующие пакеты, которые могут активизировать вызов
interface dialer number ip address address mask
interface dialer number ip address address mask
encapsulation ppp dialer remote-name username
dialer string dial-string class class-name
encapsulation ppp dialer remote-name username
dialer string dial-string class class-name
dialer pool number
dialer pool number
dialer-group group-number
dialer-group group-number
dialer-list dialer-group protocol protocol-name {permit | deny | list access-list-number}
dialer-list dialer-group protocol protocol-name {permit | deny | list access-list-number}
Ниже описаны этапы настройки конфигурации профиля номеронабирателя.
КомандаКомандаШаг Назначение
Команда
Команда
Операции PPP
PPP представляет собой наиболее широко применяемый транспортный протокол канального уровня; он почти полностью вытеснил протокол SLIP и служит основным протоколом, используемым при создании коммутируемых (и во многих случаях некоммутируемых) синхронных и асинхронных последовательных соединений. Протокол РРР был первоначально определен в 1989 году в документе RFC 1134, который с тех пор был заменен целым рядом документов RFC, из которых наиболее современным (ко времени написания этой книги) является RFC 1661. Выпущено также несколько документов RFC, определяющих элементы этого протокола; к ним относятся RFC 1990 (“The PPP Multilink Protocol"), RFC 2125 (“The PPP Bandwidth Allocation Protocol”) и многие другие. Архив документов RFC находится по адресу ftp://ftp.cisco.com/pub/rfc/RFC/.
Возможно, одно из самых лучших определений протокола РРР можно найти в документе RFC 1661, где указано следующее.
• Протокол РРР предоставляет стандартный способ транспортировки мультипро- токольных дейтаграмм по двухточечным каналам. Протокол РРР состоит из трех основных компонентов, перечисленных ниже.
Метод инкапсуляции мультипротокольных дейтаграмм.
Протокол LCP (Link Control Protocol — протокол управления каналом) для установления, настройки конфигурации и проверки соединения канала передачи данных.
Семейство протоколов NCP (Network Control Protocol — протокол управления сетью) для установления и настройки конфигурации различных протоколов сетевого уровня.
Этапы согласования параметров соединения протокола РРР
Согласование параметров соединения протокола РРР состоит из трех этапов: применение протокола LCP, аутентификация и применение протокола NCP. Каждый из этих этапов выполняется один за другим вслед за установлением асинхронного соединения или соединения ISDN.
Протокол управления каналом
Протокол РРР не соответствует модели клиент/сервер; несмотря на то, что участники соединения типа “точка-точка” выполняют разные функции (один из них — инициатор, а другой — получатель вызова), все соединения являются одноранговыми, поэтому оба участника соединения должны согласовать между собой наборы применяемых протоколов и параметров.
С началом процесса согласования каждый из одноранговых узлов, желающих установить соединение РРР, должен отправить запрос на настройку конфигурации. Этот запрос, который в дальнейшем именуется CONFREQ (сокращение от CONFigure REQuest), можно найти в выводе команды debug ppp negotiation. В запрос CONFREQ могут быть включены любые опции, не применяемые в используемом канале по умолчанию; чаше всего применяются такие опции, как Maximum Receive Unit, Async Control Character Map, Authentication
Protocol и Magic Number. Кроме того, этот запрос часто содержит опции, которые определяют функционирование многоканального протокола РРР.
На любой запрос CONFREQ могут быть получены следующие три возможных ответа.
Если второй участник соединения распознал все опции запроса CONFREQ и дал свое согласие применять указанные в нем значения, должен быть выдан ответ CONFACK (CONFigure-ACKnowledge — подтверждение запроса конфигурации).
Если любая из опций в CONFREQ (например, относящаяся к числу некоторых специализированных опций) не распознана или если значения любой из опций были явно отвергнуты в конфигурации однорангового узла, должен быть отправлен ответ CONFREJ (CONFigure-REJect — запрос конфигурации отвергнут).
Если все опции в запросе CONFREQ распознаны, но любое из значений не приемлемо для однорангового узла, должен быть передан ответ CONFNAK (CONFigure- Negative-ACKnowledge — отрицательное подтверждение запроса конфигурации).
Оба участника однорангового соединения продолжают обмениваться сообщениями CONFREQ, CONFREJ и CONFNAK до тех пор, пока каждый из них не отправит сообщение CONFACK, не произойдет разрыв коммутируемого соединения или один (или оба) участник однорангового соединения не установит, что процесс согласования не может быть успешно завершен.
Аутентификация
После успешного завершения процесса согласования LCP и совместного принятия участниками соединения решения о том, каким должен быть тип аутентификации AUTHTYPE, выполняется этап аутентификации. Согласно документу RFC 1661, этап аутентификации не является обязательным, но он настоятельно рекомендуется для всех коммутируемых соединений; в некоторых случаях он должен быть обязательно выполнен для обеспечения нормальной работы при использовании профилей номеронабирателя.
Протокол РРР предусматривает применение двух основных типов аутентификации: с помощью протокола РАР и протокола CHAP, который определен в документе RFC 1334 и уточнен в документе RFC 1994. Протокол РАР является более простым, но менее надежным, поскольку предусматривает передачу через коммутируемое соединение простых текстовых паролей. С другой стороны, протокол CHAP является более надежным и не предусматривает передачу через коммутируемое соединение простых текстовых паролей.
Возникает резонный вопрос: “Почему же тогда продолжает использоваться протокол РАР?” Специалисты центра Cisco ТАС часто приводят следующие аргументы в пользу этого протокола:
наличие большого количества установленных клиентских приложений, которые не поддерживают протокол CHAP;
несовместимость реализаций протокола CHAP различных поставщиков.
При обсуждении процесса аутентификации часто применяются термины запросчик и аутентификатор для определения ролей, выполняемых устройствами, находящимися на разных концах соединения, хотя любой одноранговый узел может выполнять и ту и иную роль. Запросчиком называют устройство, которое передает запрос на получение доступа к сети и аутентификационную информацию; в свою очередь, аутенти-
фикотор проверяет подлинность аутентификационной информации и разрешает или запрещает устанавливать соединение. При установлении соединения DDR между маршрутизаторами часто бывает так, что оба одноранговых узла выполняют обе роли.
Протокол РАР
Протокол РАР является довольно простым. После успешного завершения процесса согласования LCP запросчик снова и снова передает по каналу заданную в нем комбинацию имени пользователя/пароля до тех пор, пока аутентификатор не ответит или не будет разорвана связь по этому каналу. Аутентификатор может разорвать связь по каналу, если определит, что комбинация имени пользователя/пароля недействительна.
Протокол СПАР
Протокол CHAP является немного более сложным. Аутентификатор отправляет запросчику требование на проведение аутентификации, а запросчик в ответ передает некоторое значение. Это значение вычисляется с помощью однонаправленной функции хеширования для одновременного хеширования и вызова, и пароля CHAP. Результирующее значение передается аутентификатору наряду с именем хоста CHAP запросчика (которое может отличаться от фактического имени хоста) в ответном сообщении.
Аутентификатор считывает в ответном сообщении имя хоста, находит в базе данных пароль, соответствующий этому имени хоста, а затем с помощью такой же однонаправленной функции хеширования вычисляет по тем же исходным данным значение, которое должно совпадать со значением, переданным запросчиком в его ответе. Если полученные значения совпадают, аутентификация является успешной, а несовпадение значений должно привести к разрыву соединения.
Служба ААА
В составе средств аутентификации может применяться служба аутентификации, авторизации и учета (Authentication, Authorization, Accounting, или, сокращенно, ААА), такая как TACACS+ или RADIUS. Служба ААА не является заменой протоколов РАР и CHAP, а используется в качестве механизма их осуществления.
Протокол управления сетью
После успешной аутентификации начинается этап применения протокола NCP. Как и на этапе применения протокола LCP, участники соединения обмениваются сообщениями CONFREQ, CONFREJ, C0NFNAK и C0NFACK, но на этом этапе согласования происходит взаимное уточнение параметров протоколов более высокого уровня: IP, IPX, мостового соединения, СВР и т.д. В процессе согласования может рассматриваться один или несколько таких протоколов. В дальнейшем изложении в основном рассматривается протокол IPCP (IP Control Protocol — протокол управления межсетевым протоколом), который определен в документе RFC 1332, поскольку он используется наиболее часто, а другие протоколы действуют в основном по такому же принципу. Ниже приведен далеко не полный перечень других документов RFC, касающихся рассматриваемой темы.
RFC 1552 ("IPX Control Protocol”).
RFC 1378 (“AppleTalk Control Protocol").
RFC 1638 {“ Bridging Control Protocol’"^.
RFC 1762 {“DECnet Control Protocol").
RFC 1763 {"VINES Control Protocol”).
Кроме того, на этапе применения протокола NCP могут быть согласованы параметры протокола CDPCP (Cisco Discovery Protocol Control Protocol — протокол управления протоколом обнаружения устройств корпорации Cisco), но такое решение применяется редко, поскольку многие специалисты центра Cisco ТАС рекомендуют включать в конфигурацию всех без исключения интерфейсов номеронабирателя команду no cdp enable для предотврашения поддержки активности соединения в течение неопределенно долгого времени под действием пакетов CDP.
Основным параметром, устанавливаемым в процессе согласования параметров протокола IPCP, является адрес каждого участника соединения. Каждый из участников соединения может находиться в одном из двух возможных состояний: он может иметь или не иметь IP-адрес. Если один из участников соединения уже имеет адрес, он передает его в запросе CONFREQ другому участнику. Если этот адрес приемлем для другого участника, он в ответ посылает сообщение CONFACK. Если же адрес является неприемлемым, в качестве ответа передается сообщение C0NFNAK, содержащее адрес, предназначенный для использования первым участником.
Если участник соединения не имеет адреса, он передает сообщение CONFREQ с адресом 0.0.0.0; это сообщение по сути представляет собой запрос назначить адрес, направленный другому участнику. Запрос выполняется путем передачи сообщения CONFNAK с приемлемым адресом.
В составе параметров протокола IPCP могут быть также согласованы другие опции. В их числе часто встречаются первичный и вторичный адреса для сервера доменных имен и сервера имен NetBIOS, как описано в информационном документе RFC 1877. Кроме того, часто происходит согласование опций протокола сжатия IP {RFC 1332).
Другие варианты применения протокола РРР
Протокол РРР предоставляет широкий выбор способов его использования. Ниже описаны способы создания нескольких каналов между двумя или несколькими устройствами, а также способы масштабирования протокола РРР для большого количества входящих соединений.
Многоканальный протокол РРР
Средства протокола MLP (Multilink Point-to-Point Protocol — многоканальный протокол соединения “точка-точка”) обеспечивают уравновешивание нагрузки при передаче трафика по нескольким каналам распределенной сети, предоставляя при этом возможность совместного использования оборудования разных поставщиков, фрагментации пакетов и последующей их сборки с восстановлением исходного порядка следования пакетов, а также вычисления нагрузки по входящему и исходящему тра-
фику. В реализации многоканального протокола РРР корпорации Cisco поддерживаются спецификации фрагментации и упорядочения пакетов, которые определены в документе RFC 1717.
Многоканальный протокол РРР позволяет фрагментировать пакеты и передавать полученные фрагменты одновременно по нескольким двухточечным каналам в один и тот же удаленный адрес. Переход к использованию нескольких каналов осуществляется после достижения определяемого пользователем порога нагрузки номеронабирателя. Такая нагрузка может быть вычислена по входящему, исходящем)' трафику или тому и иному, в зависимости от характера трафика, передаваемого между конкретными узлами. Протокол MLP обеспечивает выделение пропускной способности в соответствии с потребностью и позволяет уменьшить задержку передачи по каналам распределенной сети.
Многоканальный протокол РРР предназначен для работы по одному или нескольким интерфейсам следующих типов, которые настраиваются на поддержку по требованию и чередующихся групп набора номера, и методов инкапсуляции РРР.
Асинхронные последовательные интерфейсы.
Интерфейсы BRI.
Интерфейсы PRI.
Конфигурация
Для настройки конфигурации многоканального протокола РРР в асинхронных интерфейсах необходимо настроить конфигурацию асинхронных интерфейсов на поддержку маршрутизации DDR и инкапсуляции РРР, а затем настроить конфигурацию интерфейса номеронабирателя на поддержку инкапсуляции РРР, предоставления пропускной способности по требованию и многоканального протокола РРР. Но возможности повышения производительности путем ввода в действие дополнительных асинхронных интерфейсов имеют свои пределы. При использовании размера MTU, предусмотренного по умолчанию, многоканальный протокол РРР должен поддерживать три асинхронных интерфейса с использованием модемов V.34. Но если размер MTU невелик или время от времени в канале возникают интенсивные потоки коротких фреймов, иногда могут уничтожаться пакеты.
Для обеспечения использования многоканального протокола РРР в одном интерфейсе BRI или PRI ISDN не требуется определять отдельные чередующиеся группы номеронабирателя, поскольку интерфейсы ISDN по умолчанию уже являются чередующимися группами номеронабирателя. Если в сети не используются процедуры аутентификации РРР, то информацию об идентификаторе вызывающего абонента должна передать телефонная служба.
Пороговое значение нагрузки должно быть указано в виде числа. Пример настройки конфигурации многоканального протокола РРР в одном интерфейсе BRI ISDN приведен в разделе “Пример определения конфигурации многоканального протокола РРР в одном интерфейсе ISDN”.
Если выполняется настройка конфигурации многоканального протокола РРР и необходимо обеспечивать подключение многоканальной связки в течение неопределенно долгого времени, воспользуйтесь командой dialer idle-timeout для установки очень высокого значения таймера простоя. (Команда dialer-load threshold 1 не обеспечивает подключение многоканальной связки из п каналов на неопределенно долгое
время, а команда dialer-load threshold 2 не обеспечивает подключение многоканальной связки из двух каналов на неопределенно долгое время.)
Чтобы разрешить применение многоканального протокола РРР в нескольких интерфейсах BRI или PRI ISDN, необходимо подготовить интерфейс чередующейся группы номеронабирателя и настроить его конфигурацию на использование многоканального протокола РРР. Затем необходимо отдельно определить конфигурацию каждого интерфейса BRI и ввести каждый из них в одну и ту же чередующуюся группу. Обратитесь к приведенному разделу “Пример определения конфигурации многоканального протокола РРР в нескольких интерфейсах ISDN”.
Пример определения конфигурации многоканального протокола РРР в нескольких интерфейсах ISDN
В следующем примере показано, как разрешить применение многоканального протокола РРР в интерфейсе BRI 0. Поскольку интерфейс ISDN по умолчанию представляет собой чередующуюся группу, то при настройке конфигурации одного интерфейса BRI не требуется задавать конфигурацию чередующейся группы номеронабирателя.
interface bri О
ipaddress 171.1.1.7 255.255.255.0
encapsulation ppp
dialer idle-timeout 30
dialer load-threshold 40 either
dialer map ip 172.16.20.2 name Goleta 5551212
dialer-group 1
ppp authentication pap
ppp multilink
Пример определения конфигурации многоканального протокола РРР в нескольких интерфейсах ISDN
В следующем примере показано, как выполнить настройку нескольких интерфейсов BRI ISDN, чтобы они принадлежали к одной и той же чередующейся группе номеронабирателя для многоканального протокола РРР. Для присваивания каждого из интерфейсов BRI ISDN данной чередующейся группе номеронабирателя (в данном случае группе номер 0, который должен соответствовать номеру интерфейса номеронабирателя) применяется команда dialer rotary-group.
interface BRIO
no ip address encapsulation ppp dialer rotary-group 0 ।
interface BRI1 no ip address encapsulation ppp dialer rotary-group 0 i
interface DialerO
ipaddress 172.16.20.1 255.255.255.0
encapsulation ppp
dialer in-band
dialer idle-timeout 500
dialer map ip 172.16.20.2 name Goleta broadcast 5551212
dialer load-threshold 30 either
dialer-group 1
ppp authentication chap
ppp multilink
Многоблочный многоканальный протокол PPP
Многоканальный протокол PPP предоставляет возможность фрагментировать пакеты, передаваемые по логическому каналу (который именуется также связкой), сформированному из нескольких физических каналов, а затем снова собирать их в одной оконечной системе. Многоканальный протокол РРР позволяет предоставить пропускную способность по требованию и уменьшить задержку передачи по каналам распределенной сети.
Протокол ММР (Multichassis multilink PPP — многоблочный многоканальный протокол РРР), с другой стороны, предоставляет дополнительную возможность объединять в логическую связку каналы, которые оканчиваются на нескольких маршрутизаторах с разными удаленными адресами. Протокол ММР позволяет также обрабатывать и аналоговый, и цифровой трафик.
Такие функциональные средства необходимы в тех ситуациях, когда имеется широкий круг пользователей, устанавливающих входящие коммутируемые соединения, и один сервер доступа не может предоставить достаточное количество портов для входящих коммутируемых соединений. Протокол ММР позволяет компаниям передать своим пользователям для набора единственный номер и включить в общую конфигурацию и аналоговые, и цифровые каналы. Например, это средство дает возможность провайдерам служб Internet присвоить один номер чередующейся группы ISDN нескольким интерфейсам PRI ISDN на нескольких маршрутизаторах.
Полное описание упомянутых здесь команд ММР приведено в документе Cisco Diol Solutions Command Reference. Чтобы найти документацию с описанием других команд, которые рассматриваются в этой главе, воспользуйтесь предметным указателем справочника команд или проведите поиск в интерактивном режиме.
Протокол ММР поддерживается на платформах ряда Cisco 7500, 4500 и 2500, а также в таких интерфейсах, как синхронный последовательный, асинхронный последовательный, BRI ISDN, PRI ISDN и интерфейс номеронабирателя.
По условиям применения протокола ММР реконфигурация коммутаторов телефонной компании не требуется.
Настройка конфигурации
В процессе настройки конфигурации маршрутизаторов или серверов доступа устанавливается их принадлежность к группам одноранговых устройств, называемых группами стека. Все члены группы стека являются равноправными; для групп стека не требуется постоянно назначенный ведущий маршрутизатор. Любой член группы стека может отвечать на вызовы, поступающие из одного номера доступа, который обычно относится к чередующейся группе PRI ISDN. Вызовы могут поступать от таких удаленных пользовательских устройств, как маршрутизаторы, модемы, терминальные адаптеры ISDN или платы персонального компьютера.
После установления соединения с одним членом группы стека последний становится владельцем вызова. Если от того же клиента поступит второй вызов и на него ответит другой маршрутизатор, последний устанавливает туннель и перенаправляет все пакеты, относящиеся к вызову, маршрутизатору, который владеет вызовом. Операцию установления туннеля и перенаправления через него вызовов к маршрутизатору, владеющему вызовом, иногда называют отображением канала РРР на владельца вызова.
Если имеется более мощный маршрутизатор, его конфигурацию можно настроить так, чтобы он стал членом группы стека, а другие члены группы стека могли устанавливать туннели и перенаправлять к нему все вызовы. В таком случае прочие члены группы стека просто отвечают на вызовы и перенаправляют трафик мошному разгрузочному маршрутизатору.
Примечание
Если между членами группы стека установлены каналы распределенной сети с продолжительными задержками, то функционирование группы стека может стать неэффективным.
Операции протокола ММР по обработке вызова, определению владельца вызова и перенаправлению пакетов уровня 2 в группе стека показаны на рис. 16.11 и осуществляются следующим образом.
Сразу после поступления вызова в группу стека на вызов отвечает маршрутизатор А.
В ходе борьбы за право стать владельцем вызова маршрутизатор А побеждает, поскольку он уже принял этот вызов. Маршрутизатор А становится владельцем вызова на данный сеанс с удаленным устройством. (Иногда такой маршрутизатор называют также хостом в связке интерфейса владельца.)
Если удаленному устройству, которое инициировало вызов, требуется дополнительная пропускная способность, оно выполняет второй многоканальный вызов РРР к группе.
После поступления второго вызова на него отвечает маршрутизатор D и информирует об этом группу стека. Борьбу за этот вызов снова выигрывает маршрутизатор А, поскольку он уже отрабатывает сеанс с этим удаленным устройством.
Маршрутизатор D устанавливает туннель к маршрутизатору А и перенаправляет необработанные данные РРР маршрутизатору А.
Маршрутизатор А собирает из фрагментов пакеты и переупорядочивает их.
Если в маршрутизатор D поступают дополнительные вызовы и они также касаются маршрутизатора А, туннель между маршрутизаторами А и D расширяется для обработки дополнительного трафика. Маршрутизатор D не устанавливает новые туннели к маршрутизатору А.
Если продолжают поступать вызовы и на них отвечают какие-либо иные маршрутизаторы, они также устанавливают туннель к маршрутизатору А и перенаправляют ему необработанные данные РРР.
Вновь собранные данные маршрутизатор А передает в корпоративную сеть так, как если бы все они поступили по одному физическому каналу.
Рис. 16.11. Типичный сценарий использования многоблочного многоканального протокола РРР
В отличие от предыдущего рисунка, на рис. 16.12 показана конфигурация, которая характеризуется наличием разгрузочного маршрутизатора. Серверы доступа, которые входят в состав группы стека, отвечают на вызовы, устанавливают туннели и перенаправляют вызовы на маршрутизатор Cisco 4700, который всегда выигрывает борьбу за вызовы и становится владельцем всех вызовов. Маршрутизатор Cisco 4700 собирает из фрагментов и переупорядочивает все пакеты, поступающие через группу стека.
Рис. 16.12. Сценарий использования многоблочного многоканального протокола РРР, в котором в качестве члена группы стека применяется разгрузочный маршрутизатор
Примечание
Для формирования группы стека могут применяться различные типы серверов доступа, коммутаторов и маршрутизаторов. Но такие универсальные серверы доступа, как Cisco AS5200, не следует объединять с серверами доступа, обеспечивающими поддержку только соединений ISDN, например с устройствами типа 4x00. Поскольку вызовы, поступающие из АТС, распределяются по членам группы стека произвольным образом, применение такого сочетания устройств может привести к тому, что аналоговый вызов поступит на сервер доступа, поддерживающий только цифровые вызовы, и последний не будет способен обработать вызов.
Для поддержки протокола ММР группой маршрутизаторов требуется, чтобы настройка конфигурации каждого маршрутизатора была выполнена с учетом поддержки следующих средств:
многоканального протокола PPP;
протокола SGBP (Stack Group Bidding Protocol — протокол определения владельца вызова в группе стека);.
виртуального шаблона, применяемого при формировании конфигурации интерфейса для поддержки протокола ММР.
Приложение Virtual Profiles
Virtual Profiles — это уникальное приложение протокола РРР, которое позволяет динамически создавать и настраивать конфигурацию виртуального интерфейса доступа при получении входящего коммутируемого вызова, а затем динамически уничтожать этот интерфейс по завершении обработки вызова. Приложение Virtual Profiles обеспечивает поддержку обычного протокола РРР и многоканального протокола РРР (MLP - multilink РРР).
Информация о конфигурации для виртуального интерфейса доступа приложения Virtual Profiles может поступать из интерфейса виртуального шаблона, или из специализированной пользовательской конфигурации, хранящейся на сервере ААА (Authentication, Authorization, Accounting — аутентификация, авторизация и учет), или из обоих источников.
Специализированная пользовательская конфигурация ААА, применяемая в приложении Virtual Profiles, представляет собой конфигурацию интерфейса и загружается во время согласования опций протокола LCP. Еще одно средство этого протокола, называемое конфигурацией конкретного пользователя, также основано на использовании информации о конфигурации, полученной от сервера ААА. Но в конфигурации конкретного пользователя применяется информация о конфигурации сети (такая как списки доступа и фильтры маршрутов), загруженная в ходе согласования опций протокола NCP.
Процесс настройки конфигурации виртуального интерфейса доступа с помощью интерфейсов виртуального шаблона приложения Virtual Profiles и информации о конфигурации, полученной с сервера ААА, осуществляется по следующим двум правилам.
Для формирования конфигурации любого приложения виртуального доступа нельзя использовать больше одного шаблона, но в процессе такого формирования может применяться несколько конфигураций ААА (информация сервера ААА для приложения Virtual Profiles и конфигурация ААА для конкретного пользователя, которая в свою очередь может включать конфигурацию для нескольких протоколов).
При настройке конфигурации приложения Virtual Profiles с помощью виртуального шаблона собственный шаблон этого приложения имеет более высокий приоритет по сравнению с любым другим виртуальным шаблоном.
Это приложение может эксплуатироваться на всех платформах Cisco IOS, поддерживающих протокол MLP.
Полное описание команд, упомянутых в этом разделе, приведено в главе “Virtual Profiles Commands" документа Dial Solutions Command Reference из набора документации Cisco IOS. Чтобы найти документацию с описанием других команд, которые рассматриваются в этой главе, воспользуйтесь предметным указателем справочника команд или проведите поиск в интерактивном режиме.
Общие сведения
В настоящем разделе приведены общие сведения о программе Virtual Profiles, позволяющие ознакомиться с ней перед тем, как приступить к настройке ее конфигурации.
Ограничения. Рекомендуем использовать в интерфейсах виртуального шаблона ненумерованные адреса, чтобы исключить возможность создания в интерфейсах виртуального доступа повторяющихся сетевых адресов.
Предпосылки. Для использования специализированной пользовательской информации о конфигурации интерфейса АДА в приложении Virtual Profiles требуется, чтобы маршрутизатор был настроен на работу с сервером ААА, а сервер ААА хранил пары AV (см. раздел “Терминология”) с описанием конфигурации интерфейса для конкретного пользователя. Ниже показано, с чего могут начинаться допустимые определения пар AV (на сервере RADIUS).
cisco-avpair = "lcp:interface-config=...",
В качестве информации, которая следует за знаком равенства (=), может быть задана любая команда конфигурации интерфейса Cisco IOS. Например, строка, начало которой приведено выше, может иметь следующее продолжение: cisco-avpair = "lep:interface-config=ip address 200.200.200.200 255.255.255.0", Для использования с приложением Virtual Profiles интерфейса виртуального шаблона требуется виртуальный шаблон, который определен специально для приложения Virtual Profiles.
Функциональная совместимость с другими средствами поддержки коммутируемых соединений Cisco. Приложение Virtual Profiles системы Cisco IOS обладает функциональной совместимостью с такими средствами Cisco, как маршрутизация DDR, многоканальный протокол PPP (MLP) и номеронабиратели типа ISDN.
Конфигурация DDR в физических интерфейсах
Приложение Virtual Profiles обладает полной функциональной совместимостью с физическими интерфейсами в следующих состояниях конфигурации DDR, если в конфигурации не предусмотрена поддержка других приложений интерфейса виртуального доступа.
Для интерфейса выполнена настройка конфигурации профилей номеронабирателя. Профиль номеронабирателя используется вместо конфигурации Virtual Profiles.
В интерфейсе не выполнена настройка конфигурации маршрутизации DDR. Приложение Virtual Profiles перекрывает текущую конфигурацию.
В интерфейсе не выполнена настройка конфигурации традиционного метода DDR. Приложение Virtual Profiles перекрывает текущую конфигурацию.
Примечание
Если используется интерфейс номеронабирателя (в том числе любого номеронабирателя ISDN), в физическом интерфейсе применяется его конфигурация вместо конфигурации Virtual Profiles.
Зависимость конфигурации интерфейса виртуального доступа от использования многоканального протокола РРР
Как показано в табл. 16.9, точный способ настройки интерфейса виртуального доступа зависит от следующих трех факторов.
От того, выполняется ли настройка конфигурации приложения Virtual Profiles (VP) с помощью виртуального шаблона (VT — Virtual Template), сервера AAA, того и другого или ни того ни другого. Эти варианты настройки конфигурации рассматриваются в табл. 16.9 и сокращенно обозначаются соответственно как “только VP VT”, “только VP ААА”, “VP VT и VP ААА” и “без настройки VP”.
От наличия или отсутствия интерфейса номеронабирателя.
От наличия или отсутствия поддержки протокола MLP. Столбец с надписью "MLP" служит для описания любого средства виртуального доступа, которое поддерживает протокол MLP, позволяющий формировать свою конфигурацию с помощью интерфейса виртуального шаблона.
В табл. 16.9 строка “(Многоканальный VT)” означает, что интерфейс виртуального шаблона формируется, если он определен для MLP или такого средства виртуального доступа, в котором используется MLP.
, Таблица 16.9. Последовательность формирования конфигурации iприложения Virtual Profiles ."
Конфигурация приложения Virtual Profiles
C MLP, без номеронабирателя
C MLP, c номеронабирателем
Без MLP, без номеронабирателя
Без MLP, с номеронабирателем
Только VP VT
VP VT
VP VT
VP VT
VP VT
Только VP ААА
(Многоканальный
VT)
VP AAA
(Многоканальный
VT)
VP AAA
VP AAA
VP ААА
VP VT и VP
VP VT
VP VT
VP VT
VP VT
AAA
VP AAA
VP AAA
VP AAA
VP ААА
Отсутствие VP
(Многоканальный VT)
Номеронабиратель
Интерфейс виртуального доступа не создается
Интерфейс виртуального доступа не создается
Порядок элементов в любой ячейке этой таблицы является значимым. Если строка “VT VP” находится над строкой “VP ААА”, это означает, что сначала в интерфейсе формируется виртуальный шаблон Virtual Profiles, а затем к нему применяется информация о конфигурации интерфейса ААА для данного пользователя. Информация о конфигурации интерфейса ААА для конкретного пользователя добавляется к конфигурации и перекрывает все противоречащие ей команды конфигурации физического интерфейса или виртуального шаблона.
Функциональная совместимость с другими средствами, в которых используются виртуальные шаблоны
Приложение Virtual Profiles функционально совместимо также с приложениями виртуального доступа, которые формирует интерфейс виртуального шаблона. В любом приложении виртуального доступа нельзя использовать для формирования интерфейса более одного шаблона, но в нем для формирования конфигурации можно применять несколько конфигураций АДА.
Взаимодействие приложения Virtual Profiles с другими приложениями виртуального шаблона осуществляется следующим образом.
Если разрешено применение приложения Virtual Profiles и для него определен виртуальный шаблон, используется виртуальный шаблон приложения Virtual Profiles.
Если настройка конфигурации приложения Virtual Profiles выполняется только с помошью сервера ААА (т.е. для приложения Virtual Profiles не определены какие-либо виртуальные шаблоны), то виртуальный шаблон для другого приложения виртуального доступа (например VPDN) может формироваться в виде интерфейса виртуального доступа.
Если имеется виртуальный шаблон, он формируется в виде интерфейса виртуального доступа до применения конфигурации ААА приложения Virtual Profiles или конфигурации ААА для конкретного пользователя. Если требуется конфигурация ААА для конкретного пользователя, она применяется в последнюю очередь.
Терминология
В настоящем разделе применялись следующие новые или малоизвестные термины.
Пара AV. Параметр настройки конфигурации сервера ААА; часть пользовательской конфигурации, передаваемой сервером ААА маршрутизатору в ответ на запросы авторизации конкретного пользователя. Маршрутизатор интерпретирует каждую пару AV как команду конфигурации маршрутизатора Cisco IOS и применяет эти пары AV в порядке их поступления. В настоящей главе термином пара А V обозначается параметр конфигурации интерфейса в сервере RADIUS.
Пара AV конфигурации интерфейса для приложения Virtual Profiles может принимать следующую форму:
cisco-avpair = “lep:interface-config=ip address 1.1.1.1 255.255.255.255.0",
Формирование. Создание и настройка конфигурации интерфейса виртуального доступа с помошью команд конфигурации из конкретного виртуального шаблона. Этот виртуальный шаблон является источником общей информации о пользователе и конкретном маршрутизаторе. Результатом формирования является интерфейс виртуального доступа, в конфигурацию которого входят все команды, полученные из шаблона.
Интерфейс виртуального доступа. Экземпляр уникального виртуального интерфейса, который создается динамически и существует временно. Интерфейсы виртуального доступа могут создаваться и настраиваться по-разному для различных приложений, таких как Virtual Profiles и VPDN (Virtual Private Dialup Network — виртуальная закрытая сеть коммутируемого доступа).
Интерфейс виртуального шаблона. Общая конфигурация интерфейса для конкретных пользователей или конкретных целей, которая включает информацию,
зависящую от маршрутизатора. Она принимает форму списка команд интерфейса Cisco IOS, которые должны применяться к виртуальному интерфейсу по мере необходимости.
Виртуальный профиль. Экземпляр уникального интерфейса виртуального доступа, создаваемый динамически при получении входящих коммутируемых вызовов от конкретных пользователей и уничтожаемый динамически после разрыва соединения. Для настройки конфигурации виртуального профиля конкретного пользователя может применяться интерфейс виртуального шаблона, информация о конфигурации конкретного пользователя, хранящаяся на сервере ААД, или то и другое.
Настройка конфигурации интерфейса виртуального доступа начинается с определения виртуального шаблонного интерфейса (если он имеется), за которым следуют команды, предусматривающие применение информации о конфигурации конкретного пользователя для входящего коммутируемого сеанса данного конкретного пользователя (если она имеется).
Пример согласования параметров протокола РРР с пояснениями
На рис. 16.13 показано, как устанавливается канал ISDN между маршрутизаторами Montecito и Goleta после вызова на выполнение команды ping. Следует отметить, что в данном примере не анализируются отметки времени, но в подобных случаях обычно рекомендуется использовать глобальную команду конфигурации service timestamps debug datetime msec.
MontecitoGoleta
Puc. 16.13. Соединение "маршрутизатор—ISDN—маршрутизатор"
Следующие результаты выполнения отладочных команд взяты с маршрутизатора Montecito; результаты отладки, полученные на маршрутизаторе Goleta, не должны от них значительно отличаться.
Примечание
Результаты отладки, полученные читателем, могут быть представлены в другом формате. Здесь приведен старый формат вывода отладочной информации протокола РРР, который был получен до внесения исправлений в версию IOS 11.2(8). Пример отладки РРР в новых версиях IOS приведен в главе 17.
листинге 16.2 приведена информация эхо-тестирования и отладки для канала ISDN между маршрутизаторами Montecito и Goleta.
Листинг 16.2. Маршрутизатор Montecito выполняет эхо-тестирование;
|маршрутизатора Goleta1
Montecito# show debugging
PPP:
PPP authentication debugging is on
PPP protocol negotiation debugging is on
Montecito# ping 172.16.20.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echoes to 172.16.20.2, timeout is 2 seconds:
%LINK-3-UPDOWN: Interface BRIO: В-Channel 1, changed state to up
ppp: sending CONFREQ, type = 3 (CI_AUTHTYPE), value = C223/5
ppp: sending CONFREQ, type = 5 (CIJIAGICNUMBER), value = 29EBD1A7
PPP BRIO: B-Channel 1: received config for type = 0x3 (AUTHTYPE) value = 0xC223 digest = 0x5 acked
PPP BRIO: B-Channel 1: received config for type = 0x5 (MAGICNUMBER) value = 0x28FC9083 acked
PPP BRIO: B-Channel 1: state = ACKsent fsm_rconfack(0xC021): rcvd id 0x65
ppp: config ACK received, type = 3 (CI_AUTHTYPE), value = C223
ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 29EBD1A7
PPPBRIO:B-Channel1:SendCHAP challenge id=l toremote
PPPBRIO:B-Channel1:CHAPchallenge from Goleta
PPPBRIO:B-Channel1:CHAPresponse id=l receivedfromGoleta
PPPBRIO:B-Channel1:SendCHAP success id=l to remote
PPP BRIO: B-Channel 1: remote passed CHAP authentication.
PPP BRIO: B-Channel 1: Passed CHAP authentication with remote.
N: ipcp: sending CONFREQ, type = 3 (CI_ADDRESS), Address = 172.16.20.1
P: ppp BRIO: B-Channel 1: Negotiate IP address: her address 172.16.20.2 (ACK)
Q: ppp: ipcp_reqci: returning CONFACK.
R: PPP BRIO: B-Channel 1: state = ACKsent fsm_rconfack(0x8021): rcvd id 0x25
S: ipcp: config ACK received, type = 3 (CI_ADDRESS), Address = 172.16.20.1
T: BRIO: install route to 172.16.20.2
U: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRIO: B-Channel 1, changed state to up
Генерируется трафик для инициализации попытки набора номера.
Устанавливается соединение (в данном примере не используются операторы отладки соединения ISDN).
Начало согласования опций протокола LCP
Маршрутизатор Montecito передает запросы на получение параметров AUTHTYPE и MAGICNUMBER конфигурации LCP.
Маршрутизатор Goleta передает свои запросы CONFREQ. Если значение параметра MAGICNUMBER совпадает со значением, переданным маршрутизатором Montecito, то велика вероятность того, что в канале возник цикл.
Эта строка показывает, что маршрутизатор Montecito передал подтверждения на запросы CONFREQ маршрутизатора Goleta.
Маршрутизатор Montecito получает сообщения CONFACK от маршрутизатора Goleta.
Начало этапа аутентификации
Н. Маршрутизаторы Montecito и Goleta передают друг другу вызов на проведение аутентификации.
J. Маршрутизатор Goleta отвечает на вызов.
К, L. Маршрутизатор Goleta успешно проходит аутентификацию.
М. Маршрутизатор Goleta передает маршрутизатору Montecito сообщение о том, что аутентификация была выполнена успешно.
Начало согласования опций протокола NCP
N, Р. Каждый маршрутизатор передает записанный в его конфигурации IP-адрес в виде сообщения C0NFREQ.
Q, R. Маршрутизатор Montecito передает ответ C0NFACK на сообщение CONFREQ маршрутизатора Goleta...
S... и наоборот.
Т, U. Устанавливается маршрут от маршрутизатора Montecito к маршрутизатору Goleta, и состояние протокола в интерфейсе принимает значение "up", которое указывает, что согласование опций протокола NCP выполнено успешно.
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco
Прежде чем обратиться в центр Cisco ТАС, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе своей системы.
Кроме того, выполните следующие действия и подготовьте указанные документы, которые позволят специалистам центра Cisco ТАС быстрее предоставить вам помощь.
При устранении любых неисправностей подготовьте результаты выполнения команд show running-config и show version. Обязательно введите в состав конфигурации команду service timestamps debug datetime msec.
При устранении нарушений в работе средств DDR соберите результаты выполнения команд
show dialer map;
debug dialer;
debug ppp negotiation;
debug ppp authentication.
Если нарушение в работе связано со средствами ISDN, соберите результаты выполнения команд
show isdn status;
debug isdn q931;
debug isdn events.
Если нарушение в работе связано с модемами, соберите результаты выполнения команд
show lines;
show line [x];
show modem (при наличии встроенных модемов);
show modem version (при наличии встроенных модемов);
debug modem;
debug modem csm (при наличии встроенных модемов);
debug chat (если применяется сценарий DDR).
Если нарушение в работе связано с каналами Т1 или интерфейсами PRI, соберите результаты выполнения команды
show controller tl.
Дополнительная информация
Руководство Cisco IOS Dial Solutions Guide.
Информационные страницы Technology Support Pages центра ТАС (www.cisco.com/tac/).
Глава
17
Устранение нарушений в работе соединений ISDN
Введение -
Коммутируемый доступ представляет собой одно из приложений PSTN (Public Switched L Telephone Network — открытая коммутируемая телефонная сеть), которое обеспечивает пе- 6 редачу данных от имени конечного пользователя. В процессе его функционирования оборудование С РЕ передает телефонному коммутатору телефонный номер, по которому должен быть направлен запрос на установление соединения. Некоторые маршрутизаторы позволяют эксплуатировать интерфейсы PRI наряду с группами цифровых модемов; к ним ■ относятся маршрутизаторы Cisco 3600, AS5200, AS5300 и AS5800. Другие маршрутизаторы взаимодействуют с внешними модемами; к ним относится маршрутизатор AS2511.
; Со времени выпуска издательством Cisco Press первого издания настоящей книги, Руководство по поиску неисправностей в объединенной сети, значительно вырос рынок услуг связи, и появилась необходимость повысить плотность установки модемов в оборудовании. В соответствии с такой необходимостью было разработано оборудование, обеспечивающее более высокую степень взаимодействия с оборудованием телефонной компании, а также были созданы цифровые модемы. Модемы такого типа •' обеспечивают непосредственный цифровой доступ к сети PSTN. В результате появилась возможность создания более быстрых модемов СРЕ, которые позволяют воспользоваться более высоким качеством сигнала, предоставляемого цифровыми модемами. Тот факт, что цифровые модемы, подключенные к сети PSTN через интерфейс PR1 или BR1, позволяют передавать данные со скоростью свыше 53 Кбит/с с использованием стандарта связи V.90, подтверждает успешное развитие в этом направлении.
^., К числу первых серверов доступа Cisco относятся устройства Cisco 2509 и Cisco 2511. Модель 2509 позволяет поддерживать с использованием внешних модемов 8 входящих соединений, а модель 2511 — 16. Затем на рынок была представлена модель AS5200 с двумя интерфейсами PRI, способная обеспечивать работу 48 пользователей с помощью цифровых модемов; эта модель ознаменовала собой крупный шаг в развитии технологии. Плотность установки модемов в оборудовании неуклонно увеличивалась, и в модели AS5300 была обеспечена поддержка четырех, а затем восьми интер- фейсов PRI. Недавно была представлена модель AS5800, позволяющая удовлетворить
потребность в оборудовании класса оператора связи, которое должно поддерживать десятки входящих каналов Т1 и сотни пользовательских соединений.
В этом обзоре технологий коммутируемого доступа следует упомянуть несколько устаревших технологий. К ним, в частности, относится 56К flex — предыдущая версия стандарта протокола модема со скоростью 56 Кбит/с (предшествующая появлению протокола V.90), которая была предложена корпорацией Rockwell. Корпорация Cisco все еще предоставляет возможность использовать версию 1.1 стандарта 56К flex во внутренних модемах выпускаемых ею устройств, но рекомендует как можно скорее перевести модемы СРЕ на версию V.90. Еще одним примером устаревшей технологии модемной связи является стандарт AS5100, который был совместно разработан корпорацией Cisco и одной компанией, занимающейся производством модемов. Стандарт AS5100 был создан как способ увеличения плотности размещения модемов за счет использования плат с четырьмя модемами. Этот стандарт предусматривал подключение к объединительной плате группы оформленных в виде плат устройств 2511 наряду с четырехмодемными платами и двухканальными платами Т1.
Устранение нарушений в работе средств обработки входящих вызовов
Устранение нарушений в работе средств обработки входящих вызовов необходимо начинать с низкого (физического) уровня и проводить в направлении к верхним уровням, вплоть до стека протоколов. В процессе поиска неисправностей необходимо найти ответ на ряд вопросов (и переходить к следующему вопросу только после получения положительного ответа на предыдущий).
Поступает ли вызов?
Отвечает ли приемное устройство на вызов?
Завершается ли процесс приема вызова установлением соединения?
Проходят ли данные по каналу?
Устанавливается ли сеанс (по протоколу РРР или терминальный)?
При установлении модемных соединений обработка информационного вызова выполняется так же, как вызова, предназначенного для открытия терминального сеанса, до тех пор, пока не происходит переход на этап согласования параметров протокола РРР.
Если для приема входящих вызовов используются цифровые модемы, вначале необходимо убедиться в том, что соответствующее оборудование ISDN или CAS принимает эти вызовы. Если в составе сети применяются внешние модемы, то можно не рассматривать разделы с описанием процедуры устранения нарушений в работе оборудования ISDN и CAS.
Устранение нарушений в работе оборудования приема входящих вызовов ISDN
Для наблюдения за сигнальными сообщениями q931, передаваемыми в прямом и обратном направлениях, в процессе согласования маршрутизатором соединения ISDN применяется команда debug isdn q931. Ниже приведен пример вывода, полученного при успешном установлении соединения.
Router# debug isdn q931
RX <- SETUP pd = 8 callref = 0x06
Bearer Capability i = 0x8890
Channel ID i = 0x89
Calling Party Number i = 0x0083, '5551234'
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06
Сообщение SETUP показывает, что инициатором соединения является оборудование на удаленном конце канала. Каждый вызов обозначается парой справочных номеров, относящихся к каждому концу соединения. В данном случае справочный номер вызова для входящей стороны соединения равен 0x06, а справочный номер вызова для исходящей стороны соединения равен 0x86. Параметр, характеризующий одну из особенностей канала-носителя (который часто обозначается как bearercap), сообщает маршрутизатору, к какому типу относится входящий вызов. В данном случае соединение имеет тип 0x8890. Это значение указывает, что соединение относится к типу “ISDN со скоростью 64 Кбит/с”. Если параметр bearercap равен 0х8090А2, он указывает на наличие “речевого/голосового вызова со сжатием по мю-методу".
Если сообщение SETUP не появляется, проверьте правильность телефонного номера (попытайтесь набрать его вручную, если данный канал обеспечивает передачу голоса) и состояние интерфейса ISDN (см. главу 16 “Устранение нарушений в работе коммутируемых соединений”). Если эти проверки выполняются успешно, убедитесь в том, что инициатор вызова выполняет его правильно. Обратитесь в телефонную компанию с просьбой проследить, куда перенаправляется этот вызов. Если соединение является междугородным, попытайтесь обратиться к другому оператору междугородной связи, который использует код междугородной связи 1010.
Если поступающий вызов представляет собой вызов асинхронного модема, убедитесь в том, что канал обеспечивает поддержку голосовых вызовов.
Примечание
Вызов асинхронного модема BRI представляет собой одно из средств маршрутизаторов 3600, на которых эксплуатируется система Cisco IOS 12.0(3)Т или более поздних версий. Для него требуется новейшая версия аппаратного обеспечения сетевого интерфейсного модуля BRI. Модули WIC не поддерживают вызов асинхронного модема.
Если вызов поступил, но соединение не было успешно установлено, найдите код причины (см. табл. 17.10). Об успешном установлении соединения можно узнать по наличию сообщения connect-ack.
Если это — вызов асинхронного модема, перейдите к разделу “Устранение нарушений при обработке входящих вызовов модема”.
К этому моменту должно быть установлено соединение ISDN, но сообщения о том, что по каналу передаются данные, должны отсутствовать. Вызовите на выполнение команду debug ppp negotiate, чтобы определить, передается ли по каналу какой- либо трафик РРР. Если трафик не передается, то может иметь место несогласованность скоростей. Чтобы определить, не является ли это причиной нарушения в рабо-
те, воспользуйтесь привилегированной exec-командой show running-config для просмотра информации о конфигурации маршрутизатора. Проверьте записи команды конфигурации интерфейса dialer map в локальном и удаленном маршрутизаторах. Эти записи должны выглядеть примерно так:
dialer map ip 131.108.2.5 speed 56 name C4000
Если применяются профили номеронабирателя, то для установки скорости канала должен быть определен класс команд привязки номеронабирателя. Обратите внимание, что по умолчанию в интерфейсах ISDN предпринимаются попытки использовать скорость связи 64 Кбит/с в каждом канале.
Дополнительная информация о настройке команд привязки и профилей номеронабирателя приведена в документах Cisco IOS Dial Solutions Configuration Guide, Dial Solutions Command Reference и Dial Solutions Quick Configuration Guide.
Получение действительных пакетов PPP указывает на то, что канал является исправным и работоспособным. Перейдите к разделу “Устранение нарушений в работе протокола РРР”.
Устранение нарушений в работе оборудования приема входящих вызовов CAS
Для устранения нарушений в работе группы устройств CAS, обслуживающих средства связи с модемами, применяются команды debug modem, debug modem csm и debug cas.
Примечание
Команда debug cas впервые появилась в версии Cisco IOS 12.0(7)1 для моделей AS5200 и AS5300. В более ранних версиях системы IOS наряду с ехес-командой modem-mgmt debug rbs применяется команда конфигурации системного уровня service internal. Для получения этой отладочной информации в модели AS5800 требуется подключение непосредственно к плате магистрального канала.
MODEM_REPORT(OOD1): DEV_CONNECTED at slot 1 and port 0
CSM_PR0C_IC2_WAIT_F0R_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 0
Если в выводе команды debug обнаруживается показанный здесь код, это означает, что вызов был направлен в модем. Перейдите к разделу “Устранение нарушений при обработке входящих вызовов модема".
Устранение нарушений при обработке входящих вызовов модема
При устранении нарушений в процессе обработки входящих вызовов модемов применяются следующие команды отладки:
debug modem;
debug modem csm (для интегрированных цифровых модемов).
А здесь приведены другие команды отладки, применяемые в сочетании с перечисленными выше, для получения информации о поступлении нового вызова:
debug isdn q931;
debug cas.
Если вызов достигает модема, последний должен принять этот вызов.
Рекомендации по отладке процедур работы с внешними модемами
Для упрощения отладки процедур работы с внешними модемами, подключенными к каналу терминала, рекомендуется увеличить громкость звука в динамике модема, чтобы некоторые нарушения в работе стали более заметными.
Прежде всего проверьте, раздается ли звонок в модеме-получателе при поступлении вызовов от модема — инициатора соединения. Если нет, проверьте номер и попытайтесь дозвониться вручную с удаленного узла. На приемном конце можно также попытаться проверить поступление вызовов с помощью обычного телефонного аппарата. Для этого в случае необходимости замените кабели и аппаратные средства.
Прием вызова асинхронным модемом
Если внешний модем не отвечает, проверьте кабели между модемом и сервером доступа или маршрутизатором. Убедитесь в том, что модем подключен к порту терминала или к вспомогательному порту маршрутизатора с помощью кабеля RJ-45 с обратным расположением выводов и с разъемами MMOD DB-25. Такая конструкция кабеля рекомендуется и поддерживается корпорацией Cisco для портов RJ-45. (Такие соединительные разъемы обычно обозначаются надписью "Modem".)
К числу наиболее часто применяемых типов кабелей RJ-45 относятся кабели с прямым, обратным и перекрестным подключением выводов. Чтобы узнать, к какому типу относится кабель, разместите рядом два его разъема и определите, в каком порядке расположены цветные проводники кабеля, подключенные к контактам разъема. Если проводники кабеля подведены к контактам в одинаковом порядке, это означает, что кабель имеет прямое подключение выводов. Если же проводники подведены к контактам в обратном порядке, то кабель имеет обратное подключение выводов. Ка-
бель имеет перекрестное подключение выводов, если цвета проводников показывают, что проводниками соединены между собой следующие контакты обоих разъемов:
Перекрестный кабель между разъемами RJ45
RJ45RJ45
2
5
1
4
Проследите за тем, чтобы был установлен исправный кабель подходящего типа.
Чтобы убедиться в том, что сигналы передаются по кабелю должным образом, воспользуйтесь командой show line, которая описана в главе 16.
Убедившись в том, что нарушение в работе не связано с неисправностью кабеля, проверьте, выполнена ли настройка внешнего модема для работы в режиме автоматического ответа. Проверьте внешний модем и определите, была ли выполнена его настройка на автоматический ответ. Как правило, если модем настроен на автоматический ответ, то на нем горит индикаторная лампочка АА. Переведите удаленный модем в режим автоматического ответа, если такая настройка еще не выполнена. Дополнительные рекомендации по проверке и корректировке параметров настройки модема приведены в документации модема. Для инициализации модема установите обратный сеанс Telnet (см. главу 16).
Прием вызова цифровым (встроенным) модемом
При работе с внешним модемом можно легко определить, отвечает ли он на вызов, но при использовании внутренних модемов необходимо дозвониться вручную по номеру получателя. Определите на слух наличие сигнала АВТ (Answer Back Tone — ответный тональный сигнал), а если он не прослушивается, проверьте в конфигурации следующее.
Убедитесь в том, что в определения любых интерфейсов ISDN, обрабатывающих входящие соединения модема, включена команда isdn incoming-voice modem.
Проверьте, имеется ли в составе конфигурации команда modem inout, расположенная под строкой конфигурации для терминала модема.
Возможно также, что какой-либо внутренний модем не выделен модулем CSM (Call Switching Module — модуль коммутации вызовов) для обработки входящих вызовов. Эта проблема может быть вызвана тем, что настройка конфигурации пулов модемов или других ресурсов была выполнена в расчете на слишком малое количество входящих соединений или просто в сервере доступа возникла нехватка модемов. Проверьте наличие доступных модемов и откорректируйте соответствующим образом установки диспетчера пула модемов или пула ресурсов. Если модем был выделен для обработки входящих вызовов и в конфигурации присутствует команда modem inout, соберите результаты выполнения отладочных команд и обратитесь за помощью к представителям компании Cisco.
Подготовка модема к связи
Перед установлением соединения происходит подготовка модема-получателя к связи. После успешного проведения такой подготовки модем активизирует сигнал DSR, а неудачное завершение может указывать на нарушение в работе канала или несовместимость модема.
Если возникает необходимость разобраться в самой сути отдельного нарушения в работе модема, то для этого может потребоваться использовать команды АТ в модеме, инициирующем соединение, который подключен к рассматриваемому каналу телефонной сети. Перед передачей вызова в цифровой модем, установленный в сервере доступа Cisco, предусмотрите возможность выполнить запись в файл .wav последовательности звуковых сигналов, возникающих в процессе подготовки модема к установлению соединения, которая также именуется последовательностью DIL (Digital Impairment Learning — диагностика искажений, обусловленных применением цифровых технологий). Последовательность DIL — это определенная “мелодия” (ряд ИКМ-сигналов), которую должен воспроизвести приемный цифровой модем по команде от аналогового модема V.90, инициирующего вызов. Эта последовательность позволяет аналоговому модему обнаружить наличие в канале любых искажений, обусловленных применением цифровых технологий (причинами которых является неоднократное выполнение цифро-аналоговых преобразований, применение А- и мю-методов сжатия, передача сигналов на основе заимствованных битов и вставка фрагментов дискретного сигнала). Если последовательность DIL не воспринимается на слух, это означает, что между модемами не согласовано применение протокола V.90 в канале V.8/V.8bis (т.е. возникла проблема несовместимости модемов). Если же в процессе установления соединения действительно слышна мелодия DIL, но после этого слышатся звуковые сигналы, свидетельствующие о том, что повторяется процесс подготовки к соединению, но на сей раз по протоколу V.34, это означает, что на основе полученных результатов воспроизведения последовательности DIL аналоговым модемом было принято решение отказаться от дальнейших попыток установить соединение по протоколу V.90.
Прослушивается ли шум в мелодии, которая сопровождает подготовку модема к связи? Если да, то примите меры по устранению шума в канале.
Если клиентский модем быстро прекращает дальнейшие попытки установить соединение, не выполняя процедуру подготовки к связи по протоколу V.34, это может быть обусловлено тем, что клиентский модем не имеет информации о том, какие действия должны выполняться при получении сигналов по протоколу V.Sbis. Попытайтесь отменить применение на сервере протокола V.Sbis (а следовательно, и 56К flex, если это возможно), получить новое клиентское встроенное программное обеспечение или заменить клиентский модем. Еще один вариант решения может предусматривать вставку пяти запятых в конце строки набора номера, которая применяется в клиентском модеме. При этом вызывающий модем перейдет в режим приема ответного сигнала на более продолжительное время, поэтому передача тонального сигнала протокола V.Sbis от сервера-получателя завершится по тайм-ауту, не оказав влияния на клиентский модем. Тем не менее рекомендация по использованию пяти запятых в строке набора номера основана на приблизительной оценке продолжительности тайм-аута, поэтому может потребоваться откорректировать количество запятых по месту с учетом конкретных условий.
Установление сеанса
На данном этапе рассматриваемой процедуры устранения нарушений в работе модемы должны быть подключены, и должна пройти подготовка к установлению связи. Теперь можно перейти к определению того, проходит ли какой-либо трафик через установленное соединение должным образом.
Если настройка конфигурации канала, получающего вызов, выполнена с использованием команды autoselect ppp, а асинхронного интерфейса — с помощью команды async mode interactive, вызовите на выполнение команду debug modem для проверки процесса ав-
тематического выбора параметров. По мере прохождения трафика по асинхронному каналу сервер доступа проверяет этот трафик, чтобы определить, организован ли он по принципу символьной или пакетной передачи. В зависимости от полученных при этом результатов, сервер доступа либо запускает сеанс РРР, либо не выполняет дальнейших действий, кроме организации в канале сеанса обработки ехес-команд.
Ниже приведена обычная последовательность автоматического выбора при обработке входящих пакетов PPP LCP.
*Mar 1 21:34:56.958: TTY1: DSR came up
*Mar 1 21:34:56.962: ttyl: Modem: IDLE->READY
*Mar 1 21:34:56.970: TTY1: EXEC creation
*Mar 1 21:34:56.978: TTY1: set timer type 10, 30 seconds
*Маг
1 21:34:59.722: TTY1: Autoselect)2) sample 7Е
Примечание 1
*Маг
1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF
*Маг
1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D
*Маг
1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23
*Маг
1 21:34:59.734: TTY1 Autoselect emd: ppp negotiate
Примечание 2
*Маг
1 21:34:59.746: TTY1: EXEC creation
*Маг
1 21:34:59.746: TTY1: create timer type 1, 600 seconds
*Маг
1 21:34:59.794: TTY1: destroy timer type 1 (OK)
*Маг
1 21:34:59.794: TTY1: destroy timer type 0
*Mar 1 21:35:01.798: 3LINK-3-UPDOWN: Interface Asyncl, changed state to up Примечание 3
Примечания к листингу
Примечание 1. Входящий трафик отображается в шестнадцатеричном формате с учетом того, какие двоичные данные передаются по каналу, но независимо от того, представляют ли эти двоичные данные символы ASCII или элементы пакета. Двоичные данные, приведенные в этом примере, относятся к допустимому пакету LCP. Если обнаруживаются какие-либо иные результаты, это может означать, что неправильно сформирован трафик пакетов или символов.
Примечание 2. Обнаружив, что в составе входящего трафика действительно получен пакет LCP, сервер доступа активизирует процесс согласования РРР.
Примечание 3. Асинхронный интерфейс переходит в рабочее состояние и начинается процесс согласования опций РРР (здесь не показан).
Если полученный вызов представляет собой часть сеанса РРР и в состав конфигурации асинхронного интерфейса входит команда async mode dedicated, вызовите на выполнение команду debug ppp negotiation, чтобы определить, поступают ли какие- либо пакеты запроса конфигурации (в выводе отладочной команды они обозначаются как CONFREQ) от удаленного участника соединения. Если обнаружены и входящие, и исходящие пакеты РРР, перейдите к разделу “Отладка протокола РРР”. В ином случае, с того конца соединения, где инициируется вызов, установите сеанс работы в символьном режиме (или режиме выполнения ехес-команд), другими словами, установите сеанс работы по протоколу, отличному от РРР.
Примечание
Если в составе конфигурации асинхронного интерфейса оборудования, установленного на приемном конце соединения, имеется команда async mode dedicated, то после установления входящего коммутируемого соединения с поддержкой exec-команд в выводе отладочной команды появятся только такие результаты, которые будут выглядеть как случайно сформированный набор символов (так называемый мусор) в коде ASCII. Чтобы обеспечить установление терминального сеанса и при этом иметь возможность работать по протоколу РРР, воспользуйтесь командой конфигурации асинхронного интерфейса async mode interactive. В состав конфигурации соответствующего канала введите команду autoselect ppp.
Если соединение между модемами устанавливается с применением процедуры создания терминального сеанса, но обмен данными не происходит, то необходимо проверить, не вызвано ли это причинами, которые приведены в табл. 17.1.
ТаблицаТаблицаМодем не может передавать или принимать данные
Таблица
Таблица
Возможные Рекомендуемые действия причины
Не фиксиро- Шаг 1. Вызовите на выполнение exec-команду show line на сервере доступа вана установкаили маршрутизаторе. В выводе для вспомогательного порта должны
скоростибыть указаны скорости Тх и Rx, которые в настоящее время заданы в
модемаконфигурации.
Шаг 2. Если в конфигурации канала не задано правильное значение скорости, воспользуйтесь командой конфигурации канала speed, чтобы задать скорость канала в параметрах настройки канала маршрутизатора или сервера доступа. Установите в качестве этого значения максимальную скорость, которая обычно применяется при обмене данными между модемом и портом сервера доступа или маршрутизатора.
Чтобы установить значение скорости двоичной передачи терминала, вызовите на выполнение команду конфигурации канала speed. Эта команда устанавливает и скорость передачи (на терминал), и скорость приема (от терминала).
Синтаксис
speed bps
Описание синтаксиса
• bps. Скорость двоичной передачи в битах в секунду (бит/с). Значение по умолчанию — 9600 бит/с.
Пример
В следующем примере устанавливается значение скорости каналов I и 2 сервера доступа Cisco 2509, равное 115200 бит/с: line 1 2
speed 115200
Примечание. Если по каким-то причинам нельзя использовать управление потоком данных, ограничьте скорость канала величиной 9600 бит/с. Применение более высоких скоростей может привести к потере данных.
Возможные Рекомендуемые действия причины
Шаг 3. Снова вызовите на выполнение exec-команду show line и убедитесь в том, что установлено требуемое значение скорости канала.
Шаг 4. Убедившись в том, что конфигурация канала сервера доступа или маршрутизатора настроена на использование требуемой скорости, инициализируйте через этот канал обратный сеанс Telnet к модему. Дополнительная информация приведена в разделе “Установление обратного сеанса Telnet к модему” главы 16.
Шаг 5. Введите командную строку модема, которая включает команду фиксации скорости DTE для конкретного модема. Подробные сведения о синтаксисе команд конфигурации приведены в документации конкретного модема.
Примечание. В результате выполнения АТ-команды модема, предназначенной для фиксации скорости устройства DTE (которая иногда также упоминается под названием команды корректировки скорости порта или команды перехода в режим буферизаций), часто изменяется и применяемый модемом способ исправления ошибок. Формат этой команды в значительной степени зависит от типа модема.
Фиксация скорости модема позволяет добиться того, чтобы обмен данными между модемом и сервером доступа или маршрутизатором Cisco всегда происходил на скорости, указанной в конфигурации вспомогательного порта Cisco. Если эта команда не используется, модем переходит в режим работы на скорости канала связи (телефонной линии), вместо того чтобы вести обмен данными на скорости, указанной в составе конфигурации сервера доступа
В конфигурации локального или удаленного модема или маршрутизатора не предусмотрено аппаратное управление потоком данныхВ конфигурации локального или удаленного модема или маршрутизатора не предусмотрено аппаратное управление потоком данныхШаг 1. Вызовите на выполнение exec-команду show line aux-line-number и найдите в поле Capabilities следующее (см. раздел “Интерпретация вывода команды show line" главы 16): Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out Если в этом поле нет никаких сведений о том, что используется аппаратное управление потоком данных, это означает, что в канале не разрешено аппаратное управление потоком данных. Для соединений между сервером доступа и модемом рекомендуется использовать аппаратное управление потоком данных.
В конфигурации локального или удаленного модема или маршрутизатора не предусмотрено аппаратное управление потоком данных
В конфигурации локального или удаленного модема или маршрутизатора не предусмотрено аппаратное управление потоком данных
Описание вывода команды show line приведено выше, в разделе “Применение команд debug".
Шаг 2. Выполните настройку конфигурации канала на использование средств аппаратного управления потоком данных с помошью команды конфигурации канала flowcontrol hardware.
Команда конфигурации канала flowcontrol позволяет указать метод управления потоком данных между терминалом или другим последовательным устройством и маршрутизатором. Чтобы отменить управление потоком данных, примените форму этой команды с префиксом по.
Возможные причиныВозможные причиныРекомендуемые действияРекомендуемые действия
Возможные причины
Возможные причины
Рекомендуемые действия
Рекомендуемые действия
Синтаксис
flowcontrol {none | software [lock] [in | out] | hardware
[in I out]}
Описание синтаксиса
none. Отменяет управление потоком данных.
software. Устанавливает программное управление потоком данных. Необязательная опция обозначает направление: значение in указывает, что программное обеспечение Cisco IOS должно принимать информацию управления потоком данных от подключенного устройства, а значение out указывает, что программное обеспечение должно передавать информацию управления потоком данных на подключенное устройство. Если направление не указано, предполагается, что передача информации должна происходить в обоих направлениях.
lock. Исключает возможность отменить управление потоком данных с удаленного хоста, если для подключенного устройства требуется применение средств программного управления потоком данных. Эта опция относится к соединениям, в которых используются протоколы Telnet или rlogin.
hardware. Устанавливает аппаратное управление потоком данных. Необязательная опция обозначает направление: значение in указывает, что программное обеспечение должно принимать информацию управления потоком данных от подключенного устройства, а значение out указывает, что программное обеспечение должно передавать информацию управления потоком данных на подключенное устройство. Если направление не указано, предполагается, что передача информации должна происходить в обоих направлениях. Для получения дополнительной информации об аппаратном управлении потоком данных обратитесь к руководству по аппаратным средствам, которое входит в поставку конкретного маршрутизатора.
Пример
В следующем примере показано, как установить аппаратное управление потоком данных в канале 7:
line 7
flowcontrol hardware
Примечание. Если по каким-то причинам нельзя использовать управление потоком данных, ограничьте скорость каната величиной 9600 бит/с. Применение более высоких скоростей может привести к потере данных.
Шаг 3. Разрешив применение аппаратного управления потоком данных в канале сервера доступа или маршрутизатора, инициализирйте через этот канал обратный сеанс Telnet к модему. Дополнительная информация приведена в разделе “Установление обратного сеанса Telnet к модему" главы 16.
Шаг 4. Введите командную строку модема, которая включает команду управления потоком RTS/CTS дтя конкретного модема. Эта команда обеспечивает применение в модеме такого же метода управления потоком данных (т.е. аппаратного управления), как и в сервере доступа или маршрутизаторе Cisco. Подробные сведения о синтаксисе команд конфигурации приведены в документации конкретного модема
Команды dialer шар настроены неправильно
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig дтя просмотра информации о конфигурации маршрутизатора. Проверьте записи команды dialer шар, чтобы определить, задано ли в них ключевое слово broadcast.
Шаг 2. Если это ключевое слово отсутствует, введите его в конфигурацию.
Синтаксис
dialer map protocol next-hop-address [name hostname] [broadcast] [dial-string]
Описание синтаксиса
protocol. Протокол, на который распространяется действие данной команды. К числу возможных опций относятся IP, IPX, bridge и snapshot.
next-hop-address. Протокольный адрес асинхронного интерфейса узла, находящегося на другом конце канала.
name hostname. Обязательный параметр, применяемый при аутентификации РРР. Он представляет собой имя удаленного узла, для которого в конфигурацию вводится данная команда dialer шар. Это имя чувствительно к регистру и должно представлять собой имя хоста удаленного маршрутизатора.
broadcast. Необязательное ключевое слово, которое указывает, что широковещательные пакеты (такие как обновления IP RIP или IPX RIP/SAP) должны перенаправляться по удаленному адресу назначения. Обновления маршрутизации в случае применения статических конфигураций маршрутизации являются нежелательными, и ключевое слово broadcast должно быть опушено.
dial-string. Номер телефона удаленного узла. В него должны быть включены любые необходимые коды доступа (например, цифра 9 для выхода на АТС, международный или междугородный телефонный код).
Шаг 3. Убедитесь в том, что в командах dialer map правильно указаны адреса следующего участка маршрута.
Шаг 4. Если какой-либо адрес следующего участка маршрута задан неправильно, откорректируйте его с помощью команды dialer map.
Шаг 5. Проверьте, соответствуют ли все прочие опции в командах dialer map применяемому протоколу.
Дополнительная информация о настройке конфигурации команд dialer map приведена в документах Cisco IOS Wide-Area Networking Configuration Guide и Wide-Area Networking Command Reference
Рекомендуемые действия
Возможные причиныВозможные причины
Возможные причины
Возможные причины
Возможные причины
Рекомендуемые действия
Возникло нарушение в работе вызывающего модема
Убедитесь в том, что вызывающий модем находится в работоспособном состоянии и надежно подключен к правильному порту. Проверьте, работает ли другой модем, подключенный к тому же порту
Задачи отладки процесса обработки входящего вызова на установление сеанса работы в режиме выполнения ехес-команд обычно подразделяются на несколько основных категорий. В табл. 17.2—17.5 перечислены возможные причины неисправностей и рекомендуемые действия.
Клиент коммутационной сети не получает приглашение к вводу ехес-команд.
В сеансе работы в коммутационной сети на терминал выводится бессмысленный набор символов.
Сеанс работы в коммутационной сети подключается к текущему сеансу.
Приемный модем в сеансе работы в коммутационной сети не разрывает связь должным образом.
'Таблица 17.2.
Клиент коммутационной сети не получает приглашение;
к вводу ехес-команд;
Возможная причина
Рекомендуемые действия
В канале разрешено применение режима автоматического выбора autoselect
Попытайтесь перейти в режим обработки ехес-команд, введя символ возврата каретки
В составе конфигурации канала присутствует команда no ехес
Шаг 1. Воспользуйтесь exec-командой show line для просмотра состояния соответствующего канала.
Проверьте, есть ли в поле Capabilities строка "exec suppressed". Если эта строка имеется, это означает, что разрешено применение команды конфигурации канала по ехес.
Шаг 2. Введите в конфигурацию канала команду конфигурации канала ехес, чтобы разрешить инициализацию сеансов работы в режиме обработки ехес-команд. Эта команда не имеет параметров или опций.
Пример
В следующем примере показано, как разрешить обработку ехес- команд в канале 7:
line 7
ехес
Возможная причина
Рекомендуемые действия
Применение средств управления потоком данных не разрешено, разрешено только в одном устройстве (либо DTE, либо DCE) или неправильно задана конфигурация этих средств
Шаг 1. Вызовите на выполнение exec-команду show line aux-line-number и найдите следующий текст в поле Capabilities (как описано в разделе “Интерпретация вывода команды show line" главы 16): Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out Если в этом поле нет никаких сведений о том, что используется аппаратное управление потоком данных, это означает, что в канале не разрешено аппаратное управление потоком данных. Рекомендуется использовать аппаратное управление потоком данных для соединений между сервером доступа и модемом.
Шаг 2. Выполните настройку конфигурации канала на использование средств аппаратного управления потоком данных с помощью команды конфигурации канала flowcontrol hardware.
Пример
В следующем примере показано, как установить аппаратное управление потоком данных в канале 7:
line 7
flowcontrol hardware
Примечание. Если по каким-то причинам нельзя использовать управление потоком данных, ограничьте скорость канала величиной 9600 бит/с. Применение более высоких скоростей может привести к потере данных.
Шаг 3. Разрешив применение аппаратного управления потоком данных в канале сервера доступа или маршрутизатора, инициализируйте через этот канал обратный сеанс Telnet к модему. Дополнительная информация приведена выше, в разделе “Установление обратного сеанса Telnet к модему”.
Шаг 4. Введите командную строку модема, которая включает команду управления потоком RTS/CTS для конкретного модема. Эта команда обеспечивает применение в модеме такого же метода управления потоком данных (т.е. аппаратного управления потоком данных), как в сервере доступа или маршрутизаторе Cisco. Подробные сведения о синтаксисе команд конфигурации приведены в документации конкретного модема
Не применяется фиксированное значение параметра скорости модема
Шаг 1. Вызовите на выполнение exec-команду show line на сервере доступа или маршрутизаторе. В выводе для вспомогательного порта должны быть указаны скорости Тх и Rx, которые в настоящее время заданы в конфигурации.
Описание вывода команды show line приведено выше, в разделе “Применение команд debug".
Шаг 2. Если в конфигурации канала не задано правильное значение скорости, воспользуйтесь командой конфигурации канала speed, чтобы установить скорость канала в параметрах настройки канала маршрутизатора или сервера доступа. Установите в качестве этого значения максимальную скорость, которая обычно применяется при обмене данными между модемом и портом сервера доступа или маршрутизатора.
Возможная причинаВозможная причинаРекомендуемые действияРекомендуемые действия
Возможная причина
Возможная причина
Рекомендуемые действия
Рекомендуемые действия
Чтобы установить значение скорости двоичной передачи терминала, вызовите иа выполнение команду конфигурации канала speed. Эта команда устанавливает и скорость передачи (на терминал), и скорость приема (от терминала).
Синтаксис
speed bps
Описание синтаксиса
bps. Скорость двоичной передачи в битах в секунду (бит/с). Значение по умолчанию — 9600 бит/с.
Пример
В следующем примере устанавливается значение скорости каналов 1 и 2 сервера доступа Cisco 2509, равное 115200 бит/с: line 1 2
speed 115200
Примечание. Если по каким-то причинам нельзя использовать управление потоком данных, ограничьте скорость канала величиной 9600 бит/с. Применение более высоких скоростей может привести к потере данных.
Шаг 3. Снова вызовите на выполнение exec-команду show line и убедитесь в том, что установлено требуемое значение скорости канала.
Шаг 4. Проверив, что конфигурация канала сервера доступа или маршрутизатора настроена иа использование требуемой скорости, инициализируйте через этот канал обратный сеанс Telnet к модему. Дополнительная информация приведена выше, в разделе “Установление обратного сеанса Telnet к модему".
Шаг 5. Введите командную строку модема, которая включает команду фиксации скорости DTE для конкретного модема. Подробные сведения о синтаксисе команд конфигурации приведены в документации конкретного модема.
Примечание. В результате выполнения команды фиксации скорости устройства DTE (которая иногда также упоминается под названием команды корректировки скорости порта или команды перехода в режим буферизации) часто изменяется и применяемый модемом способ исправления ошибок. Формат этой команды в значительной степени зависит от типа модема..
Фиксация скорости модема позволяет добиться того, чтобы обмен данными между модемом и сервером доступа или маршрутизатором Cisco всегда происходил на скорости, указанной в конфигурации вспомогательного порта Cisco. Если эта команда не используется, модем переходит в режим работы на скорости канала связи (телефонной линии), вместо того чтобы вести обмен данными на скорости, указанной в составе конфигурации сервера доступа
Таблица 17.3. В сеансе работы в коммутационной сети на терминал■
■ т :выводится бессмысленный набор символов ■ ■.
Возможная причина
Рекомендуемые действия
Не применя-
Шаг 1. Вызовите на выполнение exec-команду show line на сервере доступа
ется фиксиро-
или маршрутизаторе. В выводе для вспомогательного порта должны
ванное значе-
быть указаны скорости Тх и Rx, которые в настоящее время заданы в
ние параметра
конфигурации.
скорости модема
Шаг 2. Если в конфигурации канала не задано правильное значение скорости, воспользуйтесь командой конфигурации канала speed, чтобы установить скорость канала в параметрах настройки канала маршрутизатора или сервера доступа. Установите в качестве этого значения максимальную скорость, которая обычно применяется при обмене данными между модемом и портом сервера доступа или маршрутизатора.
Чтобы установить значение скорости двоичной передачи терминала, вызовите на выполнение команду конфигурации канала speed. Эта команда устанавливает и скорость передачи (на терминал), и скорость приема (от терминала).
Синтаксис
speed bps
Описание синтаксиса
bps. Скорость двоичной передачи в битах в секунду (бит/с). Значение по умолчанию — 9600 бит/с.
Пример
В следующем примере устанавливается значение скорости каналов 1 и 2 сервера доступа Cisco 2509, равное 115200 бит/с: line 1 2
speed 115200
Примечание. Если по каким-то причинам нельзя использовать управление потоком данных, ограничьте скорость канала величиной 9600 бит/с. Применение более высоких скоростей может привести к потере данных.
Шаг 3. Снова вызовите на выполнение exec-команду show line и убедитесь в том, что установлено требуемое значение скорости канала.
Шаг 4. Убедивший, в том, что конфигурация канала сервера доступа или маршрутизатора настроена на использование требуемой скорости, инициализируйте через этот канал обратный сеанс Telnet к модему (см. выше раздел “Установление обратного сеанса Telnet к модему").
Шаг 5. Введите командную строку модема, которая включает команду фиксации скорости DTE для конкретного модема. Для ознакомления с подробными сведениями о синтаксисе команд конфигурации обратитесь к документации конкретного модема.
Примечание. В результате выполнения команды фиксации скорости устройства DTE (которая иногда также упоминается под названием команды корректировки скорости порта или команды перехода в режим буферизации) часто изменяется и применяемый модемом способ исправления ошибок. Формат этой команды в значительной степени зависит от типа модема.
Возможная причина
Рекомендуемые действия
Фиксация скорости модема позволяет добиться того, чтобы обмен данными между модемом и сервером доступа или маршрутизатором Cisco всегда происходил на скорости, указанной в конфигурации вспомогательного порта Cisco. Если эта команда не используется, модем переходит в режим работы на скорости канала связи (телефонной линии), вместо того чтобы вести обмен данными на скорости, указанной в составе конфигурации сервера доступа
Признак неисправности. В результате обработки входящего запроса сеанс дистанционного коммутационного доступа подключается к уже существующему сеансу, инициализированному другим пользователем. Это означает, что вместо получения приглашения к вводу регистрационной информации пользователь входящего коммутационного соединения становится наблюдателем того, как проходит сеанс, установленный другим пользователем (который может представлять собой сеанс работы в приглашении к вводу команд UNIX, работы с текстовым редактором и т.д.).
Таблица 17.4. Сеанс работы в коммутационной сети подключается\
'■к текущему сеансу.J
Возможная причина
Рекомендуемые действия
Конфигурация модема настроена на использование всегда высокого потенциала сигнала DCD
Шаг 1. Откорректируйте конфигурацию модема таким образом, чтобы сигнал DCD с высоким потенциалом использовался в нем только после активизации сигнала CD. Для этого обычно применяется команда модема SCI, но для определения точной синтаксической структуры команды для конкретного модема обратитесь к документации модема.
Шаг 2. В случае необходимости выполните настройку конфигурации канала сервера доступа, к которому подключен модем, с помошью команды конфигурации канала no ехес. Очистите канал с помощью привилегированной exec-команды clear line, инициализируйте обратный сеанс Telnet с модемом и откорректируйте конфигурацию модема таким образом, чтобы высокий потенциал сигнала DCD устанавливался только после активизации сигнала CD.
Шаг 3. Завершите сеанс Telnet, введя команду disconnect, и откорректируйте конфигурацию канала сервера доступа с помощью команды конфигурации канала ехес
На сервере доступа или в маршрутизаторе не разрешено применение средств управления модемом
Шаг 1. Вызовите на выполнение exec-команду show line на сервере доступа или в маршрутизаторе. В выводе этой команды для вспомогательного порта в столбце Modem должна находиться строка incut или RIisCD. Это указывает на то, что в канале сервера доступа или маршрутизатора разрешено применение средств управления модемом.
Шаг 2. Выполните настройку конфигурации канала на использование средств управления модемом с помощью команды конфигурации канала modem inout. Теперь на сервере доступа разрешено применение средств управления модемом.
Возможная причина
Рекомендуемые действия
Неправильно выполнена кабельная разводка
Примечание. До тех пор пока возможность связи с модемом находится под сомнением, обязательно используйте команду modem inout, а не modem ri-is-cd. Последняя команда позволяет принимать через канал только входящие вызовы. В обработке исходящих вызовов будет отказано, и поэтому будет исключена возможность установить сеанс Telnet с модемом для настройки его конфигурации. Если есть необходимость разрешить применение команды modem ri-is-cd, это следует сделать только после проверки того, правильно ли функционирует модем
Шаг 1. Проверьте кабель, проложенный между модемом и сервером доступа или маршрутизатором. Убедитесь в том, что модем подключен к вспомогательному порту сервера доступа или маршрутизатора с помощью кабеля RJ-45 с обратным расположением выводов и разъемом MMOD DB-25. Эта конструкция кабеля рекомендуется и поддерживается корпорацией Cisco для портов RJ-45. (На таких соединительных кабелях обычно стоит маркировка "Modem".')
К числу типов кабелей RJ-45, наиболее часто применяемых при подключении модемов, относятся кабели с прямым и обратным расположением выводов. Чтобы узнать, к какому типу относится кабель RJ-45, разместите рядом два его разъема и определите, в каком порядке расположены цветные проводники кабеля, подключенные к контактам разъема. Если проводники кабеля подведены к контактам в одинаковом порядке, это означает, что кабель имеет прямое подключение выводов. Если же проводники подведены к контактам в обратном порядке, то кабель имеет обратное подключение выводов.
Стандартным кабелем для устройств Cisco 2500/CS500 является кабель с обратным подключением выводов (CAB-500RJ).
Шаг 2. Воспользуйтесь exec-командой show line, чтобы проверить, правильно ли выполнена кабельная разводка
Таблица 17.5. Прйёмн||Й модем в сеансе*работы в коммутационной сети
• - не разрывает связь должнымобразом,^
Возможные причины
Рекомендуемые действия
Модем не принимает сигнал DTR
Введите командную строку модема Hangup DTR. Эта команда указывает, что после прекращения поступления сигнала DTR в модеме должна быть прекращена генерация несущей.
В стандартных модемах для настройки конфигурации Hangup DTR обычно применяется строка SD3. Для ознакомления с точным синтаксисом этой команды обратитесь к документации конкретного модема
Возможные Рекомендуемые действия причины
На сервере доступа или в маршрутизаторе не разрешено применение средств управления модемомНа сервере доступа или в маршрутизаторе не разрешено применение средств управления модемомШаг 1. Вызовите на выполнение exec-команду show line на сервере доступа или в маршрутизаторе. В выводе этой команды для вспомогательного порта в столбце Modem должна находиться строка inout или RIisCD. Это указывает на то, что в канале сервера доступа или маршрутизатора разрешено применение средств управления модемом.
На сервере доступа или в маршрутизаторе не разрешено применение средств управления модемом
На сервере доступа или в маршрутизаторе не разрешено применение средств управления модемом
Шаг 2. Выполните настройку конфигурации канала на использование средств управления модемом с помощью команды конфигурации канала modem inout. Теперь на сервере доступа разрешено применение средств управления модемом.
Примечание. До тех пор пока возможность связи с модемом находится под сомнением, обязательно используйте команду modem inout, а не modem dialin. Последняя команда позволяет принимать в канале только входящие вызовы. В обработке исходящих вызовов будет отказано, и поэтому будет исключена возможность установить сеанс Telnet с модемом для настройки его конфигурации. Прежде чем разрешить применение команды modem dialin, обязательно убедитесь в том, что модем функционирует правильно
Устранение нарушений в работе средств обработки входящих вызовов
В процессе устранения нарушений в работе средств обработки входящих вызовов поиск неисправностей должен проводиться в направлении от нижних уровней протоколов к верхним, а устранение нарушений в работе средств обработки исходящих вызовов — в противоположном направлении. В процессе поиска неисправностей необходимо найти ответ на ряд вопросов (и переходить к следующему вопросу только после получения положительного ответа на предыдущий).
Происходит ли инициализация вызова средствами маршрутизации с набором номера по запросу?
Если применяемый модем является асинхронным, то вырабатываются ли необходимые команды сценариями диалогового взаимодействия?
Передается ли вызов в сеть PSTN?
Отвечает ли удаленный участник соединения на вызов?
Устанавливается ли соединение в результате обработки вызова?
Передаются ли данные по каналу?
Устанавливается ли сеанс (РРР или терминальный)?
Проверка работы номеронабирателя
Чтобы определить, предпринимает ли номеронабиратель попытку выполнить вызов по удаленному адресу назначения, вызовите на выполнение команду debug dialer events. Более подробную информацию можно получить с помощью команды debug dialer packet, но на выполнение этой команды затрачивается много ресурсов, и по-
этому она не должен использоваться в загруженной системе с многочисленными функционирующими интерфейсами номеронабирателя.
В следующей строке вывода команды debug dialer events, где приведены данные о передаче IP-пакета, показано имя интерфейса DDR, а также адреса отправителя и получателя пакета:
Dialing cause: Asyncl: ip (s=172.16.1.111 d=172.16.2.22)
Если номеронабиратель не предпринимает такой попытки, наиболее вероятной причиной неисправности может быть неправильная конфигурация либо в части определений интересующего трафика и состояния интерфейса номеронабирателя, либо в части маршрутизации (табл. 17.6).
i Таблица 17.6. Появление интересующего трафика не приводит |? \> к инициализации попытки набора номера ■
Возможная причинаВозможная причинаРекомендуемые действияРекомендуемые действия
Возможная причина
Возможная причина
Рекомендуемые действия
Рекомендуемые действия
Отсутствуют или неправильно заданы определения интересующего трафикаОтсутствуют или неправильно заданы определения интересующего трафикаСостояние интерфейсаСостояние интерфейсаИнтерфейс находится в режиме резервирования "standby"Интерфейс находится в режиме резервирования "standby"
Отсутствуют или неправильно заданы определения интересующего трафика
Отсутствуют или неправильно заданы определения интересующего трафика
Состояние интерфейса
Состояние интерфейса
Интерфейс находится в режиме резервирования "standby"
Интерфейс находится в режиме резервирования "standby"
Шаг 1. Вызовите на выполнение команду show running-config и убедитесь в том, что в конфигурации интерфейса задана группа номеронабирателя и имеется список номеронабирателей глобального уровня с таким же номером.
Шаг 2. Убедитесь в том, что в конфигурацию введена команда dialer-list, которая разрешает прохождение либо всего трафика протокола, либо трафика, соответствующего списку доступа.
Шаг 3. Проверьте, объявлены ли в списке доступа как интересующие те пакеты, которые должны проходить через канал. Один из удобных методов проверки состоит в использовании привилегированной ехес- команды debug ip packet [list number], в которой должен быть указан номер соответствующего списка доступа, после чего должна быть предпринята попытка выполнить эхо-тестирование или направить трафик по этому каналу каким-либо иным способом. Если фильтры интересующего трафика определены правильно, то в выводе команды debug появится информация о передаваемых пакетах. Если же в ходе этой проверки вывод команды debug не покажет наличия проходящих пакетов, это будет означать, что определения рассматриваемого списка доступа не соответствуют передаваемым пакетам
Вызовите на выполнение команду show interfaces [interface name] и убедитесь в том, что интерфейс находится в состоянии "up/up (spoofing)"
В конфигурации еще одного (основного) интерфейса в данном маршрутизаторе указано, что рассматриваемый интерфейс номеронабирателя используется в качестве резервного. Кроме того, основной интерфейс не находится в состоянии "down/down", которое требуется для вывода рассматриваемого интерфейса номеронабирателя из режима резервирования. К тому же в конфигурации основного ин-
терфейса должна быть задана задержка резервирования, так как в противном случае команда backup interface никогда не будет выполнена.
Для проверки того, переходит ли интерфейс номеронабирателя из режима standby в режим up/up (spoofing), обычно необходимо отключить кабель от основного интерфейса. Если основной интерфейс будет просто остановлен с помощью команды конфигурации shutdown, он перейдет не в состояние down/down, а в состояние administratively down, но это не одно и то же.
Возможная причина
Рекомендуемые действия
Кроме того, если основным является соединение по сети Frame Relay, то настройка конфигурации Frame Relay должна быть выполнена в последовательном подынтерфейсе связи “точка-точка”, а телефонная компания должна передавать бит “активности” (такой способ организации работы часто именуется как сквозное соединение LMI)
Интерфейс
В конфигурацию интерфейса номеронабирателя входит команда shutdown.
находится в
Кроме того, это состояние установлено по умолчанию для любого интерфей-
состоянии
са маршрутизатора при первой загрузке маршрутизатора. Чтобы выйти из та-
"administrativ
кой ситуации, воспользуйтесь командой конфигурации интерфейса по
ely down"
shutdown
Неправильная
Вызовите на выполнение exec-команду show ip route [a.b.c.d], где
конфигурация
a.b.c.d — адрес интерфейса номеронабирателя удаленного маршрутизатора.
маршрутизации
(Если на удаленном маршрутизаторе применяется команда ip unnumbered, используйте адрес интерфейса, указанный в команде ip unnumbered.)
В выводе этой exec-команды должен быть показан маршрут к удаленному адресу назначения через интерфейс номеронабирателя. Если такой маршрут отсутствует, проверьте, выполнена ли настройка статических или плавающих статических маршрутов по результатам выполнения команды show running-config.
Если отсутствует маршрут через интерфейс, отличный от интерфейса номеронабирателя, то можно предположить, что маршрутизация DDR используется в качестве резервной. Проверьте конфигурацию маршрутизатора, чтобы узнать, выполнена ли настройка статических или плавающих статических маршрутов. В данном случае самый надежный способ проверки маршрутизации — запретить использование основного соединения, а затем выполнить команду show ip route [a.b.c.d] для определения того, установлен ли подходящий маршрут в таблице маршрутизации.
Примечание. При попытке выполнить описанные выше действия во время производственной эксплуатации сети может быть активизировано событие набора номера. Поэтому проверку такого рода следует проводить в период планового обслуживания
Инициализация вызова
Если маршрутизация организована правильно и должным образом определены фильтры интересующего трафика, то должна успешно осуществляться попытка инициализации вызова. Это можно проверить с помощью команды debug dialer events:
Asyncl DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)
Asyncl DDR: Attempting to dial 5551212
Если обнаружена причина набора номера, но при этом не предпринимается попытка дозвона, то чаще всего такое нарушение в работе связано с неправильной настройкой карты вызовов абонентов или профиля номеронабирателя (табл. 17.7).
[Таблица 17.7. Не происходит инициализация вызова
Проблема
Рекомендуемые действия
Неправильно настроена карта вызовов абонентов
Вызовите на выполнение команду show running-config, чтобы убедиться в том, что в состав конфигурации интерфейса номеронабирателя включена хотя бы одна команда dialer map, в которой указан протокольный адрес и вызываемый номер удаленного узла
Неправильно настроен профиль номеронабирателя
Вызовите на выполнение команду show running-config, чтобы убедиться в том, что в состав конфигурации интерфейса номеронабирателя включена хотя бы одна команда dialer pool X, а в конфигурацию интерфейса номеронабирателя в маршрутизаторе входит соответствующая команда dialer-pool member X. Если профили номеронабирателя не настроены должным образом, то в выводе команды debug может появиться примерно такое сообщение: "Dialerl: Can't place call, no dialer pool set".
Убедитесь в том, что в конфигурации задана строка номеронабирателя
Асинхронный исходящий вызов — проверка функционирования сценария диалогового взаимодействия
Если исходящий вызов выполняется с помощью модема, то для отработки данного вызова должен применяться сценарий диалогового взаимодействия. При использовании средств маршрутизации DDR, основанных на применении карты вызовов абонентов, сценарий диалогового взаимодействия вызывается с помощью параметра modem-script команды dialer map. Если же средства маршрутизации DDR основаны на использовании профиля номеронабирателя, то описанные выше действия осуществляются с помощью команды script dialer, входящей в состав конфигурации канала терминала. В обоих случаях применяется сценарий диалогового взаимодействия, который определен в составе глобальной конфигурации маршрутизатора, например, как показано ниже.
chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
И в том и в другом случае для контроля над выполнением сценария диалогового взаимодействия применяется команда debug chat. Если предположить, что в команде dialer map или dialer string используется строка набора номера (такая как номер телефона), например 5551212, то вывод отладочной команды будет выглядеть примерно так:
СНАТ1: Attempting async line dialer script
CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTK
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
СНАТ1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success
Нарушения, связанные с использованием сценария диалогового взаимодействия, подразделяются на следующие три категории:
ошибки конфигурации;
отказы модема;
неудачное завершение попыток установления соединения.
В табл. 17.8 приведены возможные сообщения о неудачных попытках выполнения сценариев диалогового взаимодействия и предлагаемые решения.
Таблица 17.8. Нарушения, связанные с использованием сценария . диалогового взаимодействия
Вывод команды debug chat
Предлагаемое решение
No matching chat script found for [number]
В конфигурации не задан сценарий диалогового взаимодействия. Введите его в конфигурацию
Chat script dialout finished, status = Connection timed out; remote host not responding
Модем не отвечает на команды сценария диалогового взаимодействия. Проверьте связь с модемом (см. табл. 16.2)
Timeout expecting: CONNECT
Варитнт 1. Локальный модем фактически не инициализирует вызов. Проверьте, инициализируется ли вызов модемом; для этого установите обратный сеанс связи Telnet к модему и инициализируйте набор номера вручную.
Вариант 2. Не отвечает удаленный модем. Проверьте, так ли это, набрав номер удаленного модема с помощью обычного телефона.
Втриант 3. Набираемый номер является неправильным. Проверьте номер, набрав его вручную, и в случае необходимости откорректируйте конфигурацию.
Варитнт 4. Подготовка модема к установлению соединения происходит слишком долго или значение параметра TIMEOUT является слишком низким. Если локальный модем является внешним, увеличьте уровень звука в динамике модема и прослушайте тональные сигналы в процессе подготовки к установлению соединения. Если подготовка К установлению соединения внезапно обрывается, попытайтесь увеличить значение параметра TIMEOUT в команде chat-script. Если значение этого параметра уже равно 60 с или больше, см. выше раздел “Подготовка модема к установлению соединения”
Обработка исходящих вызовов ISDN
Если есть основания полагать, что возникло нарушение в работе сети ISDN, связанное с функционированием интерфейса BRI или PRI, необходимо, прежде всего, просмотреть результаты выполнения команды show isdn status. Здесь в основном необходимо проверить, чтобы протокол уровня 1 находился в состоянии
Active, а протокол уровня 2 — в состоянии MULTIPLE_FRAME_ESTABLISHED. Информация о том, какие данные приведены в выводе этой команды и как устранить обнаруженные неисправности, приведена в разделе “Интерпретация вывода команды show isdn status” главы 16.
Наилучшими инструментальными средствами, которые могут применяться при устранении нарушений в процессе обработки исходящих вызовов ISDN, являются команды debug isdn q931 и debug isdn events. К счастью, процесс отладки средств обработки исходящих вызовов в значительной степени напоминает процесс отладки средств обработки входящих вызовов. Обычно результаты успешной обработки вызова выглядят следующим образом:
*Маг 20 21:07:45.025: ISDN BRO: Event: Call to 5553759 at 64 Kb/s
*Mar 20 21:07:45.033: ISDN BRO: TX -> SETUP pd = 8 callref = 0x2C
*Mar 2021:07:45.037:Bearer Capability i=0x8890
*Mar 2021:07:45.041:Channel ID i = 0x83
*Mar 2021:07:45.041:Keypad Facility i =0x35353533373539
*Mar 2021:07:45.141: ISDN BRO: RX <- CALL_PROC pd= 8 callref= OxAC
*Mar 2021:07:45.145:Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN BRO: received HOST_PROCEEDING
Channel ID i = 0x0101
*Mar 20 21:07:45.161:
Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN BRO: RX <- CONNECT pd = 8 callref = OxAC
*Mar 20 21:07:45.325: ISDN BRO: received HOST_CONNECT
Следует отметить, что основным показателем успешного выполнения вызова является сообщение CONNECT. Если сообщение CONNECT не получено, вместо него может быть обнаружено сообщение DISCONNECT или RELEASE_COMP (сокращение от release complete — полное отключение), за которым следует код причины Cause:
*Маг 20 22:11:03.212: ISDN BRO: RX <- RELEASE_COMP pd = 8 callref = 0x8F
*Mar 20 22:11:03.216:Cause i = 0x8295 - Call rejected
Значение Cause, которое может быть представлено в виде четырех- или шестибайтового числа, позволяет получить следующую информацию. Второй байт этого числа показывает, на каком участке пути прохождения вызова от одного оконечного устройства к другому было получено сообщение DISCONNECT или RELEASE_COMP. Эта информация поможет найти причину неисправности. Третий и четвертый байты позволяют определить фактическую причину отказа. Расшифровки различных значений Cause приведены в табл. 17.9 и 17.10.
Примечание. Если в выводе команды обнаруживается строка, приведенная ниже, то наиболее вероятной причиной отказа является нарушение в работе протокола более высокого уровня.
Cause i = 0x8090 - Normal call clearing
Чаще всего нарушение в работе возникает из-за неудачного завершения процесса аутентификации РРР. Разрешите применение команд debug ppp negotiation и debug ppp authentication, чтобы определить, действительно ли причиной неудачного завершения попытки установления связи является нарушение в работе средств ISDN.
Поля кода причины Cause
В табл. 17.9 перечислены поля кода причины нарушения в работе средств ISDN, которые отображаются в выводе команд debug в следующем формате:
i=0x yl у2 zl z2 [al а2]
| Таблица 17.9. Поля кода причины нарушения в работе средств ISDN .
Поле
Значение Описание
Ох
Приведенные ниже значения представлены в шестнадцатеричном коде
yl
8Код стандарта 1TU-T
У2
0Пользователь
Закрытая сеть, обслуживающая локального пользователя
Открытая сеть, обслуживающая локального пользователя
Транзитная сеть
Открытая сеть, обслуживающая удаленного пользователя
Закрытая сеть, обслуживающая удаленного пользователя
Международная сеть
АСеть, находящаяся за пределами объединенной сети
zl
Класс причины неисправности (старший разряд шестнадцатеричного кода
причи-
ны неисправности). Подробная информация о возможных значениях кода дена в табл. 17.10
приве-
z2
Значение причины неисправности (младший разряд шестнадцатеричного кода причины неисправности). Для получения подробной информации о возможных
значениях обратитесь к табл. 17.10
al
(Необязательный параметр.) Поле диагностики состояния, которое всегда жит значение 8
содер-
а2
(Необязательный параметр.) Поле диагностики состояния, которое может одно из следующих значений:
■ иметь
ОНеизвестное
1Постоянное
2Переходное
Значения поля с описанием причин нарушения в работе
В табл. 17.10 описаны некоторые наиболее часто встречающиеся причины нарушения в работе, которые представлены в виде третьего и четвертого байтов в коде причины Cause.
Таблица 17.10. Расшифровка значений поля причины нарушения '- в работе ISDN . ■
Шестнадцатеричное ПричинаОписание
значение
81Нераспределенный Номер ISDN был передан в коммутатор в
(неприсвоенный) номер правильном формате, но не присвоен ни одному устройству назначения
Шестнадцатеричное значение
Причина
Описание
90
Нормальное завершение соединения
Произошло нормальное завершение соединения
91
Пользователь занят
Вызываемая система подтверждает запрос на соединение, но не способна принять вызов, поскольку все В-каналы заняты
92
Пользователь не отвечает
Соединение не может быть установлено, поскольку устройство назначения не отвечает на вызов
93
Не получен ответ от пользователя (пользователь предупрежден)
Устройство назначения отвечает на запрос об установлении соединения, но не может завершить процесс установления соединения в течение предписанного времени. Это нарушение в работе имеет место в удаленном конце соединения
95
Вызов отвергнут
Устройство назначения способно принять вызов, но отвергает его по неизвестным причинам
9С
Неправильный формат номера
Соединение не может быть установлено, поскольку адрес назначения был представлен в нераспознаваемом формате или задан не полностью
9F
Нормальная, но неклассифицированная ситуация
Эго значение поля указывает на возникновение нормального события, которое нельзя отнести к какой-либо стандартной категории. Не требуется выполнение каких-либо действий
А2
Отсутствует доступный канал
Соединение не может быть установлено, так как нет подходящего канала для приема вызова
Аб
Сеть неисправна
Доступ к устройству назначения отсутствует, поскольку сеть не функционирует должным образом, и это состояние может продлиться в течение значительного периода времени. Немедленное выполнение повторной попытки подключения, по-видимому, будет безуспешным
АС
Недоступен требуемый канал
Удаленное оборудование не может предоставить требуемый канал по неизвестной причине. Такое нарушение в работе может оказаться временным
В2
Не оформлена подписка на затребованное функциональное средство
Удаленное оборудование предоставляет доступ к затребованной дополнительной службе только по подписке. Такая ситуация чаще всего возникает, если требуются услуги междугородной связи
В9
Отсутствуют права доступа к средствам канала-носителя
Пользователь затребовал доступ к средствам канала-носителя, предоставляемым сетью, но не имеет права на их использование. Такое нарушение в работе может быть связано с отсутствием подписки
Шестнадцатеричное значение
Причина
Описание
D8
Несовместимое устройство назначения
Этот код ошибки указывает, что была предпринята попытка подключиться к оборудованию, отличному от ISDN, например к аналоговому каналу
ЕО
Отсутствует обязательный информационный элемент
Приемным оборудованием получено сообщение, которое не включает один из обязательных информационных элементов. Такая ситуация обычно возникает в результате ошибки в D-канале. Если такая ошибка возникает систематически, сообщите об этом своему провайдеру служб ISDN
Е4
Неправильное содержимое информационного элемента
Удаленным оборудованием получено сообщение, которое содержит недопустимые данные в информационном элементе. Такая ситуация обычно возникает в результате ошибки в D-канале
Полная информация о кодах и значениях ISDN приведена в главе “ISDN Switch Codes and Values” документа Cisco IOS Debug Command Reference для конкретной версии IOS, а также находится по адресу ww.cisco.com/univercd/home/home.htm.
Исходящие вызовы CAS
Устранение нарушений при обработке исходящих вызовов через каналы TI или Е1 системы CAS и встроенные цифровые модемы во многом осуществляется так же, как и устранение других нарушений маршрутизации DDR. (Такое утверждение остается справедливым и для исходящих вызовов, выполняемых через встроенные модемы по каналу PRI.) Тем не менее обработка вызовов, осуществляемых таким способом, характеризуется уникальными особенностями, поэтому требует специальной отладки в случае аварийного завершения вызова.
Как и в случае других нарушений процесса маршрутизации DDR, необходимо убедиться в том, что была предпринята попытка вызова; для этого может применяться команда debug dialer events (см. выше раздел “Проверка работы номеронабирателя”).
Прежде чем появится возможность инициализировать вызов, необходимо выделить модем для этого вызова. Для контроля над этим процессом и ходом последующей обработки вызова могут применяться такие команды debug:
debug modem;
debug modem csm;
debug cas.
Примечание. Команда debug cas впервые появилась в версии IOS 12.0(7)Т для устройств AS5200 и AS5300. В более ранних версиях IOS применяется команда конфигурации системного уровня service internal наряду с exec-командой modem-mgmt debug rbs, как показано ниже.
Включение режима отладки
router# conf t
Enter configuration commands, one per line. End with CNTL/Z. router(config)#service internal router(config)#Л Z router# modem-mgmt csm ?
debug-rbs enable rbs debugging
no-debug-rbs disable rbs debugging router# modem-mgmt csm debug-rbs router#
neat msg at slot 0: debug-rbs is on
neat msg at slot 0: special debug-rbs is on
Выключение режима отладки
router#
router# modem-mgmt csm no-debug-rbs
neat msg at slot 0: debug-rbs is off
Для получения такой отладочной информации на устройстве AS5800 необходимо подключиться к самой магистральной плате.
Ниже приведен пример успешно выполненного исходящего вызова по каналу Т1 CAS, выделенному и настроенному для использования в приложении FXS-Ground-Start.
Mica Modem(l/0): Rcvd Dial String(5551111) [Modem receives digits from chat script]
CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0
CSM_RX_CAS_EVENT_FROM_NEAT:(A003): EVENT_CHANNEL_LOCK at slot 1 and port 0
CSM_PROC_OC4_DIALING: CSM_EVENT_DSXO_BCHAN_ASSIGNED at slot 1, port 0
Mica Modem(1/0): Configure(0x1)
Mica Modem(1/0): Configure(0x2).
Mica Modem(l/0): Configure(0x5)
Mica Modem(l/0): Call Setup
neat msg at slot 0: (0/2): Tx RING_GROUND
Mica Modem(l/0): State Transition to Call Setup
neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING [Telco switch goes OFFHOOK]
CSM_RX_CAS_EVENT_FROM_NEAT:(A003): EVENT_START_TX_TONE at slot 1 and port 0
CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0
neat msg at slot 0: (0/2): Tx LOOP_CLOSURE [Now the router goes OFFHOOK]
Mica Modem(l/0): Rcvd Tone detected(2)
Mica Modem(l/0): Generate digits:called_party_num=5551111 len=8
Mica Modem(l/0): Rcvd Digits Generated
CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0
CSM_RX_CAS_EVENT_FROM_NEAT:(A003): EVENT_CHANNEL_CONNECTED at slot 1 and port 0
CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_DSX0_CONNECTED at slot 1, port 0
Mica Modem(l/0): Link Initiate
Mica Modem(l/0): State Transition to Connect
Mica Modem(l/0): State Transition to Link
Mica Modem(l/0): State Transition to Trainup
Mica Modem(l/0): State Transition to EC Negotiating
Mica Modem(l/0): State Transition to Steady State
Mica Modem(l/0): State Transition to Steady State Speedshifting
Mica Modem(l/0): State Transition to Steady State
Для каналов Т1 и El с другими типами сигнализации применяются аналогичные команды debug.
Если в процессе отладки достигнуто такое состояние, то можно сделать вывод, что вызывающий и приемный модемы прошли процедуру подготовки к соединению, установили соединение, а теперь могут приступить к согласованию параметров протоколов более высокого уровня. Если модем для данного исходящего вызова был выделен должным образом, но в процессе установления соединения не удалось достичь указанного состояния, то необходимо проверить работу канала Т1 (информация об устранении нарушений в работе канала Т1 приведена в главе 15).
Устранение нарушений в работе протокола РРР
Устранение нарушений в работе на этапе установления соединения, предусматривающем согласование параметров протокола РРР, начинается с того момента, когда становится очевидно, что коммутируемое соединение (ISDN или асинхронное) устанавливается успешно.
Прежде всего необходимо ознакомиться с тем, как выглядит последовательность сообщений команды debug при успешном согласовании параметров протокола РРР, и только после этого приступать к устранению нарушений в этом процессе согласования параметров. Дело в том, что, сравнив результаты сеанса выполнения команды debug при неудачном завершении согласования РРР с результатами успешного завершения согласования, вы сможете сэкономить время и усилия.
Ниже приведен пример успешно выполненной последовательности согласования параметров протокола РРР. Подробное описание полей этого вывода приведено в табл. 17.11.
Montecito#
Маг 13 10:57:13.415: 4LINK-3-UPDOWN: Interface Asyncl, changed state to up
Mar 13 10:57:15.415: Asi LCP: 0 CONFREQ [ACKrcvd] id 2 len 25
Mar 13 10:57:15.415: Asi LCP: ACCM OxOOOAOOOO (0X0206000A0000)
Mar 1310:57:15.415:AsiLCP:AuthProto CHAP(0x0305C22305)
Mar 1310:57:15.415:AsiLCP:MagicNumber 0xl084F0A2(0x05061084F0A2)
Mar 1310:57:15.415:AsiLCP:PFC (0x0702)
Mar 1310:57:15.415:AsiLCP:ACFC (0x0802)
Mar 13 10:57:15.543: Asi LCP: I CONFACK [REQsent] id 2 len 25
Mar 13 10:57:15.543: Asi LCP: ACCM OxOOOAOOOO (0x0206000A0000)
Mar 1310:57:15.543:AsiLCP:AuthProto CHAP(0x0305C22305)
Mar 1310:57:15.543:AsiLCP:MagicNumber 0x1084F0A2(0x05061084F0A2)
Mar 1310:57:15.543:AsiLCP:PFC (0x0702)
Mar 1310:57:15.547:AsiLCP:ACFC (0x0802)
Mar 13 10:57:16.919: Asi LCP: I CONFREQ [ACKrcvd] id 4 len 23
Mar 13 10:57:16.919: Asi LCP: ACCM OxOOOAOOOO (0x0206000A0000)
Mar 1310:57:16.919:AsiLCP:MagicNumber 0x001327B0 (0x0506001327B0)
Mar 1310:57:16.919:AsiLCP:PFC (0x0702)
Mar 1310:57:16.919:AsiLCP:ACFC (0x0802)
Mar 1310:57:16.919:AsiLCP:Callback 6 (0x0D0306)
Mar 13 10:57:16.919: Asi LCP: 0 CONFREJ [ACKrcvd] id 4 len 7
<SMALL>Mar 13 10:57:16.919: Asi LCP: Callback 6 (0x000306)</SMALL>
Mar 13 10:57:17.047: Asi LCP: I CONFREQ [ACKrcvd] id 5 len 20
<SMALL>Mar1310:57:17.047:AsiLCP:ACCM OxOOOAOOOO (0x0206000A0000)</SMALL>
<SMALL>Mar1310:57:17.047:AsiLCP:MagicNumber 0X001327B0
(0x0506001327B0)</SMALL>
<SMALL>Mar1310:57:17.047:AsiLCP:PFC (0x0702)</SMALL>
<SMALL>Mar1310:57:17.047:AsiLCP:ACFC (0x0802)</SMALL>
Mar 13 10:57:17.047: Asi LCP: О CONFACK [ACKrcvd] id 5 len 20
Mar1310:57:17.047:AsiLCP:ACCM OxOOOAOOOO(0x0206000A0000)
Mar1310:57:17.047:AsiLCP:MagicNumber 0x001327B0(0x0506001327B0)
Mar1310:57:17.047:AsiLCP:PFC (0x0702)
Mar1310:57:17.047:AsiLCP:ACFC (0x0802)
Mar1310:57:17.047:AsiLCP: State is Open
Mar1310:57:17.047:AsiPPP: Phase is AUTHENTICATING, bythisend
Mar 13 10:57:17.047: Asi CHAP: О CHALLENGE id 1 len 28 from "Montecito"
Mar1310:57:17.191:AsiCHAP: I RESPONSE id 1 len 30 from"Goleta"
Mar1310:57:17.191:AsiCHAP: О SUCCESS id 1 len 4
Mar1310:57:17.191:AsiPPP: Phase is UP
<SMALL>Mar 13 10:57:17.191: Asi IPCP: О CONFREQ [Closed] id 1 len 10</SMALL>
<SMALL>Mar 13 10:57:17.191: Asi IPCP: Address 172.22.66.23 (0X0306AC164217)</SMALL>
<SMALL>Mar 13 10:57:17.303: Asi IPCP: I CONFREQ [REQsent] id 1 len 40</SMALL>
Mar 13 10:57:17.303: Asi IPCP: CompressType VJ 15 slots CompressSlotID (0X0206002D0F01)
Mar 1310:57:17.303:AsiIPCP:Address 0.0.0.0 (0x030600000000)
Mar 1310:57:17.303:AsiIPCP:PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 1310:57:17.303:AsiIPCP:PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 1310:57:17.303:AsiIPCP:SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 1310:57:17.303:AsiIPCP:SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.303: Asi IPCP: О CONFREJ [REQsent] id 1 len 22
Mar 13 10:57:17.303: Asi IPCP: CompressType VJ 15 slots CompressSlotID
(0X0206002D0F01)
Маг 13 10:57:17.303: Asi IPCP:
PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:17.303: Asi IPCP:
SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.319: Asi CCP:
I CONFREQ [Not negotiated] id 1 len 15
Mar 13 10:57:17.319: Asi CCP:
MS-PPC supported bits 0x00000001 (0x120600000001)
Mar 13 10:57:17.319: Asi CCP:
Stacker history 1 check mode EXTENDED (0x1105000104)
Mar 13 10:57:17.319: Asi LCP:
0 PROTREJ [Open] id 3 len 21 protocol CCP
Mar 13 10:57:17.319: Asi LCP:
(0X80FD0101000F12060000000111050001)
Mar 13 10:57:17.319: Asi LCP:
(0x04)
Mar 13 10:57:17.319: Asi IPCP:
I CONFACK [REQsent] id 1 len 10
Mar 13 10:57:17.319: Asi IPCP:
Address 172.22.66.23 (0X0306AC164217)
Mar 13 10:57:18.191: %LINEPROTO-5-UPDOWN: Line protocol on Interface Asyncl, changed state to up
Mar 13 10:57:19.191: Asi IPCP:
TIMEout: State ACKrcvd
Mar 13 10:57:19.191: Asi IPCP:
0 CONFREQ [ACKrcvd] id 2 len 10
Mar 13 10:57:19.191: Asi IPCP:
Address 172.22.66.23 (0X0306AC164217)
Mar 13 10:57:19.315: Asi IPCP:
I CONFACK [REQsent] id 2 len 10
Mar 13 10:57:19.315: Asi IPCP: Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:20.307: Asi IPCP: I CONFREQ [ACKrcvd] id 2 len 34
Mar 1310:57:20.307:AsiIPCP:Address 0.0.0.0 (0x030600000000)
Mar 1310:57:20.307:AsiIPCP:PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 1310:57:20.307:AsiIPCP:PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 1310:57:20.307:AsiIPCP:SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 1310:57:20.307:AsiIPCP:SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.307: Asi IPCP: 0 CONFREJ [ACKrcvd] id 2 len 16
Mar 1310:57:20.307:AsiIPCP:PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 1310:57:20.307:AsiIPCP:SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.419: Asi IPCP: I CONFREQ [ACKrcvd] id 3 len 22
Mar1310:57:20.419:AsiIPCP:Address 0.0.0.0 (0x030600000000)
Mar1310:57:20.419:AsiIPCP:PrimaryDNS 0.0.0.0 (0x810600000000)
Mar1310:57:20.419:AsiIPCP:SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:20.419: Asi IPCP: 0 CONFNAK [ACKrcvd] id 3 len 22
Mar1310:57:20.419:AsiIPCP:Address 10.1.1.1 (0x03060A010101)
Mar1310:57:20.419:AsiIPCP:PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar1310:57:20.419:AsiIPCP:SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.543: Asi IPCP: I CONFREQ [ACKrcvd] id 4 len 22
Mar1310:57:20.543:AsiIPCP:Address 10.1.1.1 (0x03060A010101)
Mar1310:57:20.547:AsiIPCP:PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar1310:57:20.547:AsiIPCP:SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.547: Asi IPCP: 0 CONFACK [ACKrcvd] id 4 len 22
Mar1310:57:20.547:AsiIPCP:Address 10.1.1.1 (0x03060A010101)
Mar1310:57:20.547:AsiIPCP:PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar1310:57:20.547:AsiIPCP:SecondaryDNS 171.68.10.140 (0X8306AB440A8C)
Mar 13 10:57:20.547: Asi IPCP: State is Open
Mar 13 10:57:20.551: Asi IPCP: Install route to 10.1.1.1
Следует отметить, что в некоторых версиях 1OS могут быть получены отладочные сообщения в другом формате. Здесь приведены результаты выполнения отладки в новом формате вывода отладочных сообщений РРР, который был изменен в версии 1OS 11.2(8). Примеры отладки РРР с применением старых версий IOS приведены в главе 16.
иаблица 17.11. Подробные сведения о согласовании РРР LCP
Отметке времени
Описание
10:57:15.415
Исходящий запрос определения конфигурации (О CONFREQ). Сервер NAS передает клиенту исходящий пакет запроса конфигурации РРР
10:57:15.543
Входящее подтверждение конфигурации (I CONFACK). Клиент подтверждает запрос конфигурации РРР узла Montecito
10:57:16.919
Входящий запрос настройки конфигурации (I CONFREQ). Клиент передает запрос на согласование применения протокола обратного вызова
10:57:16.919
Исходящее сообщение об отклонении запроса конфигурации (О CONFREJ). Сервер NAS отклоняет запрос на применение опции обратного вызова
Отметка времени
Описание
10:57:17.047
Входящий запрос настройки конфигурации (I CONFREQ). Клиент запрашивает новый набор опций. Обратите внимание, что на этот раз в запросе не указана опция обратного вызова Microsoft
10:57:17.047
Исходящее подтверждение запроса настройки конфигурации (0 C0NFACK). Сервер NAS подтверждает новый набор опций
10:57:17.047
Согласование параметров PPP LCP завершено успешно (как показывает сообщение LCP: State is Open). Оба участника соединения подтвердили (C0NFACK) запросы настройки конфигурации (CONFREQ) друг друга
10:57:17.047
10:57:17.191
Аутентификация РРР выполнена успешно. После согласования параметров LCP начинается этап аутентификация. Аутентификация должна быть выполнена прежде, чем начнется доставка трафика любого сетевого протокола, такого как IP.
Оба участника соединения проводят аутентификацию с помощью метода, договоренность о применении которого достигнута во время согласования LCP. Узел Montecito проводит проверку подлинности клиента с использованием протокола CHAP
10:57:20.551
Соединение перешло в состояние, открытое для протокола IPCP. Для однорангового узла IPCP, которому присваивается IP-адрес 1.1.1.1, согласовывается и устанавливается маршрут
Протокол LCP
В процессе согласования параметров протокола LCP обычно возникают нарушения двух типов. Первый тип нарушения возникает, если один участник однорангового соединения передает запросы на настройку конфигурации, которые не могут или не должны быть подтверждены вторым участником. Хотя такая ситуация встречается часто, она может перерасти в проблему, если запросчик неуклонно требует применения определенного параметра. Типичным примером является ситуация, возникающая при согласовании параметра AUTHTYPE. В частности, в конфигурациях многих серверов доступа предусмотрено, что для аутентификации должен применяться только протокол CHAP. А если в конфигурации вызывающего устройства предусмотрено применение аутентификации исключительно по протоколу РАР, такие участники соединения будут бесцельно обмениваться сообщениями CONFREQ и CONFNAK до тех пор, пока один из них не разорвет связь.
BRO:1 LCP: I CONFREQ [ACKrcvd] id 66 len 14
BRO:1 LCP:AuthProto PAP (0X0304C023)
BRO:1 LCP:MagicNumber 0XBC6B9F91 (0X0506BC6B9F91)
BRO:1 LCP: 0 CONFNAK [ACKrcvd] id 66 len 9
BRO:1 LCP: AuthProto CHAP (0x0305C22305)
BRO:1 LCP: I CONFREQ [ACKrcvd] id 67 len 14
BRO:1 LCP:AuthProto PAP (0X0304C023)
BRO:1 LCP:MagicNumber 0XBC6B9F91 (0x0506BC6B9F91)
BRO:1 LCP: 0 CONFNAK [ACKrcvd] id 67 len 9
BRO:1 LCP: AuthProto CHAP (0x0305022305)
BRO:1 LCP: I CONFREQ [ACKrcvd] id 68 len 14
BRO:1 LCP: AuthProto PAP (0X0304C023)
BRO:1 LCP: MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BRO:1 LCP: 0 CONFNAK [ACKrcvd] id 68 len 9
BRO:1 LCP: AuthProto CHAP (0x0305C22305) ... И Т.Д.
Нарушения второго типа на этапе LCP происходят, если один или оба участника соединения воспринимают только исходящие сообщения CONFREQ, как показано в следующем примере. Такая ситуация обычно возникает в результате так называемого несоответствия скоростей на низком уровне. Она может возникнуть при использовании маршрутизации DDR и в асинхронном канале, и в канале ISDN.
Пример аварийного завершения процесса согласования LCP:
Jun 10 19:57:59.768: As5 PPP: Phase is ESTABLISHING, Active Open
Jun 10 19:57:59.768: As5 LCP: 0 CONFREQ [Closed] id 64 len 25
Jun 10 19:57:59.768: As5 LCP: ACCM OxOOOAOOOO (0x0206000A0000)
Jun 10 19:57:59.768: As5 LCP: AuthProto CHAP (0X0305C22305)
Jun 10 19:57:59.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:57:59.768: As5 LCP: PFC (0x0702)
Jun 10 19:57:59.768: As5 LCP: ACFC (0x0802)
Jun 10 19:58:01.768: As5 LCP: TIMEout: State REQsent
Jun 10 19:58:01.768: As5 LCP: 0 CONFREQ [REQsent] id 65 len 25
Jun 10 19:58:01.768: As5 LCP: ACCM OxOOOAOOOO (0x0206000A0000)
Jun 10 19:58:01.768: As5 LCP: AuthProto CHAP (0x0305C22305)
Jun 10 19:58:01.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:01.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:01.768: As5 LCP: ACFC (0x0802).
Jun 10 19:58:03.768: As5 LCP: TIMEout: State REQsent
Jun 10 19:58:03.768: As5 LCP: 0 CONFREQ [REQsent] id 66 len 25
Jun 10 19:58:03.768: As5 LCP: ACCM OxOOOAOOOO (0x0206000A0000)
Jun 10 19:58:03.768: As5 LCP: AuthProto CHAP (0x0305C22305)
Jun 10 19:58:03.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:03.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:03.768: As5 LCP: ACF.C (0x0802)
Jun 10 19:58:05.768: As5 LCP: TIMEout: State REQsent
Jun 10 19:58:05.768: As5 LCP: 0 CONFREQ [REQsent] id 67 len 25
Такой обмен сообщениями повторяется через каждые 2 секунды до тех пор, пока не произойдет следующее:
Jun 10 19:58:19.768: As5 LCP: О CONFREQ [REQsent] id 74 len 25
Jun 10 19:58:19.768: As5 LCP: ACCM OxOOOAOOOO (0x0206000A0000)
Jun 10 19:58:19.768: As5 LCP: AuthProto CHAP (0x0305C22305)
Jun 10 19:58:19.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:19.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:19.768: As5 LCP: ACFC (0x0802)
Jun 10 19:58:21.768: As5 LCP: TIMEout: State REQsent
Jun 10 19:58:21.768: TTYS: Async Int reset: Dropping DTR
Если соединение является асинхронным, то возможная причина состоит в несовпадении скоростей между маршрутизатором и модемом, которое обычно возникает в результате того, что не выполнена фиксация скорости DTE модема в соответствии со
скоростью, заданной в конфигурации канала терминала. Такая проблема может быть обнаружена на том и на другом одноранговом узле, поэтому необходимо проверить оба узла (см. табл. 17.1).
Если рассматриваемые признаки неисправности возникают при установлении соединения по каналу ISDN, то такое нарушение в работе, вероятно, возникает в связи с тем, что один одноранговый узел устанавливает соединение на скорости 56 Кбит/с, а другой — на скорости 64 Кбит/с. Хотя такая ситуация возникает редко, ее нельзя исключать из рассмотрения; нарушение в работе может возникнуть на одном или на обоих одноранговых узлах или даже в самой телефонной сети. Вызовите на выполнение команду debug isdn q931 и проверьте наличие сообщений SETUP, относящихся к каждому из одноранговых узлов. Информация о возможностях канала-носителя, переданная от одного однорангового узла, должна совпадать с информацией о возможностях канала-носителя, приведенной в сообщении SETUP, которое получено от другого однорангового узла. В качестве одной из возможных мер по исправлению этого нарушения можно ввести в конфигурацию значение скорости набора номера, равное 56К или 64К, либо в команде dialer map уровня интерфейса, либо в команде dialer isdn speed, входящей в конфигурацию в составе определения класса карт вызовов абонентов.
*Маг 2021:07:45.033: ISDN BRO: ТХ -> SETUP pd =8callref=0x2C
*Mar 2021:07:45.037:Bearer Capability i=0x8890
*Mar 2021:07:45.041:Channel ID i = 0x83
*Mar 2021:07:45.041:Keypad Facility i =0x35353533373539
В такой ситуации, как правило, следует обращаться в центр Cisco ТАС, но перед этим соберите результаты выполнения следующих команд на обоих одноранговых узлах:
show running-config;
show version;
debug isdn q931;
debug isdn events;
debug ppp negotiation.
Аутентификация
Аварийное завершение процесса согласования параметров протокола РРР чаще всего происходит в результате нарушения процесса аутентификации. При обнаружении неправильно заданных в конфигурации или не распознанных имен пользователей и паролей в выводе команды debug появляются сообщения об ошибках.
В следующем примере показано, что пользователь с именем Goleta не имеет право дозваниваться на сервер NAS (Network Access Server — сервер доступа к сети), в локальной конфигурации которого не задано имя такого пользователя. Чтобы устранить указанное нарушение в работе, можно вызвать на выполнение команду username папе password password, чтобы ввести информацию о пользователе с именем Goleta в локальную базу данных ААА сервера NAS.
Маг 13 11:01:42.399: As2 LCP: State is Open
Mar 13 11:01:42.399: As2 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:01:42.399: As2 CHAP: 0 CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:01:42.539: As2 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:01:42.539: As2 CHAP: Unable to validate Response. Username Goleta not found <SMALL>Mar 13 11:01:42.539: As2 CHAP: 0 FAILURE id 1 len 26 msg is "Authentication fail</SMALL><SMALL>ure"</SMALL>
Mar 13 11:01:42.539: As2 PPP: Phase is TERMINATING
В следующем примере показано, что в конфигурацию сервера NAS введено имя пользователя Goleta, но проверка пароля завершилась неудачей. Чтобы исправить это нарушение в работе, вызовите на выполнение команду username пате password password и укажите для пользователя Goleta правильный пароль регистрационной учетной записи.
Маг 13 11:04:06.843: As3 LCP: State is Open
Mar 13 11:04:06.843: As3 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:04:06.843: As3 CHAP: 0 CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:04:06.987: As3 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:04:06.987: As3 CHAP: 0 FAILURE id 1 len 25 msg is "MD/DES compare failed”
Mar 13 11:04:06.987: As3 PPP: Phase is TERMINATING
Протокол NCR
После успешного выполнения участниками однорангового соединения всех необходимых процедур аутентификации процесс согласования параметров переходит к этапу согласования параметров протокола NCP (Network Control Protocol — протокол управления сетью). Если настройка конфигурации обоих одноранговых узлов выполнена должным образом, то процесс согласования параметров протокола NCP может выглядеть, как в следующем примере, где показано, как клиентский компьютер дозванивается на сервер NAS и согласовывает с ним параметры:
solvang# show debug
Generic IP:
IP peer address activity debugging is on PPP:
PPP protocol negotiation debugging is on
*Mar 1 21:35:04.186: As4 PPP: Phase is UP
*Mar 1 21:35:04.190: As4 IPCP: 0 CONFREQ [Not negotiated] id 1 len 10
*Mar 1 21:35:04.194: As4 IPCP: Address 10.1.2.1 (0X03060A010201)
*Mar 1 21:35:04.282: As4 IPCP: I CONFREQ [REQsent] id 1 len 28
*Mar 1 21:35:04.282: As4 IPCP: CompressType VJ 15 slots CompressSlotID (0X0206002D0F01)
*Mar121:35:04.286:As4IPCP:Address 0.0.0.0 (0x030600000000)
*Mar121:35:04.290:As4IPCP:PrimaryDNS 0.0.0.0 (0x810600000000)
*Mar121:35:04.298:As4IPCP:SecondaryDNS 0.0.0.0 (0x830600000000)
*Mar 1 21:35:04.306: As4 IPCP: 0 CONFREJ [REQsent] id 1 len 10
*Mar121:35:04.310:As4IPCP:CompressType VJ 15 slots CompressSlotID
(0X0206002D0F01)
*Mar 1 21:35:04.314: As4 ССР: I CONFREQ [Not negotiated] id 1 len 15
*Mar 1 21:35:04.318: As4 CCP: MS-PPC supported bits 0x00000001 (0x120600000001)
*Mar 1 21:35:04.318: As4 CCP: Stacker history 1 check mode EXTENDED (0x1105000104)
*Mar 1 21:35:04.322: As4 LCP: 0 PROTREJ [Open] id 3 len 21 protocol CCP
*Mar 1 21:35:04.326: As4 LCP: (0X80FD0101000F12060000000111050001)
*Маг
1 21:35:04.330: As4 LCP:
(0x04)
*Маг
1 21:35:04.334: As4 IPCP:
I CONFACK [REQsent] id 1 len 10
*Маг
1 21:35:04.338: As4 IPCP:
Address 10.1.2.1 (0x03060A010201)
*Маг
1 21:35:05.186: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4, changed
state
to up
*Маг
1 21:35:07.274: As4 IPCP:
I CONFREQ [ACKrcvd] id 2 len 22
*Маг
1 21:35:07.278: As4 IPCP:
Address 0.0.0.0 (0x030600000000)
*Маг
1 21:35:07.282: As4 IPCP:
PrimaryDNS 0.0.0.0 (0x810600000000)
*Маг
1 21:35:07.286: As4 IPCP:
SecondaryDNS 0.0.0.0 (0x830600000000)
*Маг
1 21:35:07.294: As4 IPCP:
0 CONFNAK [ACKrcvd] id 2 len 22
*Маг
1 21:35:07.298: As4 IPCP:
Address 10.1.2.2 (0x03060A010202)
*Маг
1 21:35:07.302: As4 IPCP:
PrimaryDNS 10.2.2.3 (0x81060A020203)
*Маг
1 21:35:07.310: As4 IPCP:
SecondaryDNS 10.2.3.1 (0x83060A020301)
*Маг
1 21:35:07.426: As4 IPCP:
I CONFREQ [ACKrcvd] id 3 len 22
*Маг
1 21:35:07.430: As4 IPCP:
Address 10.1.2.2 (0x03060A010202)
*Маг
1 21:35:07.434: As4 IPCP:
PrimaryDNS 10.2.2.3 (0x81060A020203)
*Маг
1 21:35:07.442: As4 IPCP:
SecondaryDNS 10.2.3.1 (0x83060A020301)
*Маг
1 21:35:07.446: ip_get_pool: As4: validate address = 10.1.2.2
*Маг
1 21:35:07.450: ip_get_pool: As4: using pool default
*Маг
1 21:35:07.450: ip_get_pool: As4: returning address = 10.1.2.2
*Маг
1 21:35:07.454: set ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant
*Маг
1 21:35:07.458: As4 IPCP:
0 CONFACK [ACKrcvd] id 3 len 22
*Маг
1 21:35:07.462: As4 IPCP:
Address 10.1.2.2 (0x03060A010202)
*Маг
1 21:35:07.466: As4 IPCP:
PrimaryDNS 10.2.2.3 (0x81060A020203)
*Маг
1 21:35:07.474: As4 IPCP:
SecondaryDNS 10.2.3.1 (0x83060A020301)
*Маг
1 21:35:07.478: As4 IPCP:
State is Open
*Маг
1 21:35:07.490: As4 IPCP:
Install route to 10.1.2.2
I Таблица 17.12. Подробные сведения о согласовании PPP NCRJ
Отметка времени Описание
21:35:04.190
Исходящий запрос определения конфигурации (0 CONFREQ). Сервер NAS передает другому одноранговому узлу исходящий пакет запроса конфигурации РРР, содержащий его IP-адрес
21:35:04.282
Входящий запрос CONFREQ. Одноранговый узел передает запрос на использование метода сжатия заголовков VJ (Van Jacobsen header compression — метод сжатия заголовков Якобсена) и сообщает, что ему требуется IP-адрес для себя, а также нужны адреса первичного и вторичного серверов DNS
21:35:04.306
Исходящее сообщение об отклонении запроса конфигурации (CONFREJ). Запрос на применение метода сжатия заголовков VJ отвергнут
21:35:04.314
21:35:04.330
Одноранговый узел передает запрос на применение протокола ССР (Compression Control Protocol — протокол управления сжатием); сервером NAS передан отказ от применения всего этого протокола в виде сообщения PROTREJ. Одноранговый узел не должен предпринимать (и не предпринимает) попытки снова потребовать применения протокола ССР
21:35:04.334
Одноранговый узел подтверждает получение IP-адреса сервера NAS с помощью сообщения CONFACK
Отметка времени
Описание
21:35:07.274
Входящий запрос CONFREQ. Одноранговый узел больше не передает запросы на применение метода сжатия заголовков VJ, но ему все еще требуется IP- адрес для себя, а также адреса первичного и вторичного серверов DNS
21:35:07.294
Сервер NAS передает сообщение CONFNAK, содержащее адрес, назначенный им одноранговому узлу, наряду с адресами первичного и вторичного серверов DNS
21:35:07.426
Одноранговый узел снова передает эти же адреса серверу NAS; в действительности эта операция имеет своей целью лишь подтвердить, что адреса были получены правильно
21:35:07.458
Сервер NAS подтверждает правильность адресов с помощью сообщения CONFACK
21:35:07.478
Каждый из участников соединения передал сообщение CONFACK, так что согласование закончено. В выводе команды show interfaces Async4 на сервере NAS должна присутствовать строка "IPCP: Open”
21:35:07.490
В таблицу маршрутизации сервера NAS вводится запись непосредственного маршрута к удаленному одноранговому узлу
Следует отметить, что одноранговые узлы могут одновременно согласовывать между собой параметры нескольких протоколов уровня 3. Например, нередко приходится наблюдать, как происходит согласование протоколов IP и IPX. Возможно также, что согласование параметров одного протокола будет выполнено успешно, а другого — окончится неудачей. *
Как правило, любые нарушения, возникающие в процессе согласования NCP, возникают в результате каких-либо ошибок в конфигурации взаимодействующих одноранговых узлов. Если согласование РРР завершится неудачей на этапе NCP, выполните действия, описанные в табл. 17.13.
Гтаблица 17.13. Устранение нарушений в процессе согласования ^^^
Задача
Этапы
Проверить кон-
Изучите результаты выполнения привилегированной exec-команды show
фигурацию прото-
running-config. Проверьте, выполнена ли настройка конфигурации ин-
кола интерфейса
терфейса на поддержку протокола, который должен функционировать в рассматриваемом соединении
Проверить адрес
Убедитесь в том, что в конфигурации рассматриваемого интерфейса за-
интерфейса
дан адрес. Если применяется команда ip unnumbered [interface-name] или ipx ppp-client loopback [number], убедитесь в том, что адрес задан и в конфигурации интерфейса, упомянутого в этой команде
Проверить дос-
Если предусмотрена передача сервером NAS IP-адреса вызывающему
тупность клиент-
устройству, убедитесь в том, что такой адрес имеется. IP-адрес, предна-
ского адреса
значенный для передачи вызывающему устройству, может быть получен одним из следующих способов.
• Введен в конфигурацию локального интерфейса. Проверьте наличие
в конфигурации интерфейса команды peer default ip address a.b.c.d. На практике такой метод должен применяться только в интерфейсах, которые принимают запросы на установление соединения от одного пользователя, такого как интерфейс типа async (а не group-async).
ЗадачаЭтапы
Получен из пула адресов, введенного в локальную конфигурацию сервера NAS. В состав конфигурации интерфейса должна входить команда peer default ip address pool [pool-паше]. Кроме того, этот пул должен быть определен на уровне системы с помощью команды ip local pool [pool-name] [first-address] [last-address]. Диапазон адресов, определенных в пуле, должен быть достаточно большим для обслуживания вызовов, одновременно поступающих от подключаемых вызывающих устройств, которые способен принять сервер NAS.
Получен от сервера DHCP. В конфигурацию интерфейса NAS должна быть введена команда peer default ip address dhcp. Кроме того, настройка конфигурации сервера NAS должна быть выполнена таким образом, чтобы в ней содержалась ссылка на сервер DHCP, заданная с помощью глобальной команды конфигурации ip dhcp-server [address],
Получен от сервера ААА. Если в процессе авторизации применяется служба TACACS+ или RADIUS, то настройка конфигурации сервера ААА может быть выполнена таким образом, чтобы он передавал конкретный IP-адрес каждому отдельному вызывающему устройству при каждом его подключении
ПроверитьЧтобы получить адреса, заданные в конфигурации серверов доменных
конфигурацию ад- имен или серверов Windows NT, в ответ на запросы ВООТР, убедитесь в реса сервератом, что в конфигурации заданы команды глобального уровня async-
bootp dns-server [address] и async-bootp nbns-server [address]
Примечание
Несмотря на то что в конфигурацию сервера NAS может быть введена команда async- bootp subnet-mask [mask], между сервером NAS и клиентским персональным компьютером, устанавливающим входящее коммутируемое соединение РРР, не может согласовываться маска подсети subnet mask. Сама суть соединений “точка-точка” определяет то, что клиент автоматически использует IP-адрес сервера NAS (полученный им во время согласования IPCP) в качестве шлюза, применяемого по умолчанию. В этой среде связи типа “точка-точка” маска подсети не требуется, поскольку персональный компьютер имеет информацию о том, что при несовпадении в пакете адреса назначения с локальным адресом пакет должен перенаправляться в шлюз, применяемый по умолчанию (сервер NAS), который всегда является достижимым по каналу РРР.
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco
Прежде чем обратиться в центр Cisco ТАС, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе своей системы.
Кроме того, выполните следующие действия и подготовьте указанные документы, которые позволят специалистам центра Cisco ТАС быстрее предоставить вам помощь.
При устранении любых неисправностей подготовьте результаты выполнения команд show running-config и show version. Обязательно введите в состав конфигурации команду service timestamps debug datetime msec.
При устранении нарушений в работе средств DDR соберите результаты выполнения команд
show dialer map;
debug dialer;
debug ppp negotiation;
debug ppp authentication.
Если нарушение в работе связано со средствами ISDN, соберите результаты выполнения команд
show isdn status;
debug isdn q931;
debug isdn events.
Если нарушение в работе связано с модемами, соберите результаты выполнения команд
show lines;
show line [x];
show modem (при наличии встроенных модемов);
show modem version (при наличии встроенных модемов);
debug modem;
debug modem csm (при наличии встроенных модемов);
debug chat (если применяется сценарий DDR).
Если нарушение в работе связано с каналами Т1 или интерфейсами PRI, соберите результаты выполнения команды
show controller tl.
Дополнительная информация
Руководство Cisco IOS Dial Solutions Guide.
Информационные страницы Technology Support Pages центра ТАС (www.cisco.com/tac/).
Глава
18
;< Устранение нарушений в работе соединений Frame Relay
Протокол Frame Relay первоначально разрабатывался лишь для обмена данными через интерфейсы ISDN. Первые предложения такого рода были переданы на рассмотрение в организацию ITU-T в 1984 году. Работа над протоколом Frame Relay проводилась также в Соединенных Штатах в комитете по стандартам T1S1, аккреди- 1 тованном при ANSI.
Важный этап в развитии протокола Frame Relay наступил в 1990 году, когда компании Cisco Systems, StrataCbm, Northern Telecom и Digital Equipment Corporation образовали консорциум, ориентнрЬванный на разработку технологии Frame Relay и ускоренное внедрение функционально совместимых продуктов Frame Relay. Этот консорциум разработал gb спецификацию, соответствующую основному протоколу Frame Relay, рассматриваемому в комитете T1S1 и секторе ITU-T, но дополнил его средствами, которые предоставляют дополнительные возможности для сложной среды объединенной сети. Такие дополнения к протоколу Frame Relay известны под общим названием LMI.
Основы технологии Frame Relay
- Технология Егагце, Relay предоставляет средства передачи данных с пакетной ком” мутшдией, которые применяются в интерфейсах между пользовательскими устройствами (например, маршрутизаторами, мостами и хост-компьютерами) и сетевым оборудованием (например, коммутационными узлами). Пользовательские устройства часто именуются устройствами DTE, а сетевые устройства, применяемые в качестве интерфейсов к устройствам DTE, — устройствами DCE. Интерфейс Frame Relay мо
жет пре доставляться и в открытой сети провайдера связи, и в закрытой сети, обслу- 'живающей отдельное предприятие.
Протокол Frame Relay, рассматриваемый в качестве интерфейса доступа к сети, относится к такому же типу, как и протокол Х.25 (см. главу 19). Но протокол Frame Relay имеет существенные отличия от протокола Х.25 с точки зрения его функционального назначения и формата пакетов. В частности, Frame Relay является упрощенным протоколом и обеспечивает более высокую производительность и эффективность.
Протокол Frame Relay, рассматриваемый в качестве интерфейса между пользовательским и сетевым оборудованием, предоставляет средства статистического мультип-
лексирования множества логических сеансов передачи данных (называемых виртуальными каналами) по одному физическому каналу. В этом состоит его существенное отличие от систем, в которых для поддержки нескольких потоков передачи данных применяются методы мультиплексирования с разделением времени (TDM — TimeDivision Multiplexing). Средства статистического мультиплексирования Frame Relay обеспечивают более гибкое и эффективное использование имеющейся пропускной способности. Их можно применять без привлечения или с привлечением методов TDM (на основе каналов, предоставляемых системами TDM).
Еще одна важная особенность технологии Frame Relay состоит в том, что в ней реализованы новейшие достижения в области технологии передачи распределенной сети. Более ранние протоколы распределенной сети, такие как Х.25, были разработаны в то время, когда доминировали аналоговые системы передачи, а в качестве передающей среды в основном использовался медный кабель. Применяемые в то время каналы передачи были менее надежными по сравнению с доступными в наши дни цифровыми каналами передачи, в которых в качестве передающей среды применяются волоконно-оптические кабели. При использовании таких каналов можно обойтись без применения трудоемких алгоритмов исправления ошибок в протоколах канального уровня и возложить выполнение этой задачи на протоколы более высокого уровня. Это позволяет добиться повышения производительности и эффективности, не создавая предпосылок нарушения целостности данных. Протокол Frame Relay был разработан с учетом именно такого подхода. В нем предусмотрено применение CRC для обнаружения искаженных битов (после чего содержащие их данные просто отбрасываются), но отсутствуют какие-либо протокольные механизмы исправления искаженных данных (например, путем их .повторной передачи на этом уровне протокола).
Еще одно различие между протоколами Frame Relay и Х.25 состоит в том, что в первом из них отсутствуют, как таковые, средства управления потоком данных в каждом отдельном виртуальном канале. В настоящее время эффективные алгоритмы управления потоком данных реализованы во многих протоколах высокого уровня, поэтому потребность в применении этих функциональных средств на канальном уровне уменьшилась. По этой причине протокол Frame Relay не включает явные процедуры управления потоком данных, которые дублировали бы соответствующие процедуры, применяемые на более высоких уровнях. Вместо этого в нем предусмотрены лишь очень простые механизмы уведомления о заторах, которые позволяют передавать в пользовательские устройства, подключенные к сети, сообщения о том, что сетевые ресурсы вскоре могут быть исчерпаны и сеть перейдет в состояние затора. Такие уведомления могут использоваться для протоколов высокого уровня в качестве аварийных сообщений о том, что необходимо ввести в действие средства управления потоком данных.
В современных стандартах Frame Relay упоминаются так называемые постоянные виртуальные каналы (PVC — Permanent Virtual Circuit), которые настраиваются и управляются администраторами сети Frame Relay. Кроме того, в этих стандартах предложены виртуальные каналы еще одного типа — коммутируемые виртуальные каналы (SVC — Switched Virtual Circuit). В качестве средства, с помощью которого устройства DTE и DCE могут взаимодействовать для динамического установления, разрыва и управления коммутируемыми виртуальными каналами, в этих стандартах предложено использовать протокол передачи сигналов сети ISDN.
Расширения LMI
Спецификация Frame Relay, предлагаемая консорциумом, включает не только определения основных функций протокола Frame Relay, предназначенных для передачи данных, но и расширения LMI, позволяющие упростить создание крупных и сложных объединенных сетей. Некоторые расширения LMI обозначены как общепринятые, и в спецификации выражена надежда на то, что они будут реализованы всеми, кто принимает ее как руководство к действию. Другие функции LMI обозначены как необязательные. Ниже приведены общие сведения о расширениях LMI.
Сообщения о состоянии виртуальных каналов (общепринятое расширение). Обеспечивают связь и синхронизацию между сетевыми и пользовательскими устройствами, периодически сообщая о появлении новых постоянных виртуальных каналов и удалении существующих, и в целом предоставляют информацию о надежности постоянных виртуальных каналов. Сообщения о состоянии виртуальных каналов исключают возможность отправки данных в так называемые черные дыры, т.е. в постоянные виртуальные каналы, которые больше не существуют.
Многоадресатная рассылка (необязательное расширение). Позволяет отправителю передать один фрейм, но указать при этом, что он должен быть доставлен по сети нескольким получателям. Таким образом, многоадресатная рассылка обеспечивает эффективную доставку сообщений маршрутизирующего протокола и сообщений процедур преобразования адреса, которые обычно требуется передавать одновременно по нескольким адресам назначения.
Глобальная адресация (необязательное расширение). Позволяет обозначить идентификаторы соединения как глобальные, а не локальные, что дает возможность использовать их для обозначения конкретного интерфейса к сети Frame Relay. Благодаря применению глобальной адресации сеть Frame Relay с точки зрения адресации напоминает локальную сеть, поэтому протоколы преобразования адресов функционируют в сети Frame Relay точно так же, как и в локальной сети.
Простые средства управления потоком данных (необязательное расширение). Предоставляют механизм управления потоком данных XON/XOFF, который применяется ко всему интерфейсу Frame Relay. Этот механизм предназначен для таких устройств, в которых нельзя использовать биты уведомлений о заторе в протоколах более высоких уровней, и поэтому необходимо обеспечить определенный уровень управления потоком данных.
Формат фрейма
Формат фрейма Frame Relay показан на рис. 18.1. Поля флажков обозначают начало и конец фрейма. Вслед за ведущим полем флажков находятся 2 байта с информацией об адресе. Десять битов из этих 2 байтов составляют идентификатор подключения канального уровня (DLCI —Data Link Connection Identifier).
Длина поля
1
2
Переменная
2
1
в байтах
Флажки
Адрес
Данные
FCS
Флажки
Рис. 18.1. Формат фрейма Frame Relay
Это 10-битовое значение DLCI представляет собой основу заголовка Frame Relay. Оно обозначает логическое соединение, которое мультиплексируется в физическом канале. В основном режиме адресации (не расширенном с использованием средств LMI) идентификаторы DLCI имеют только локальное значение; таким образом, в оконечных устройствах, находяшихся на разных концах соединения, могут использоваться различные идентификаторы DLCI для обозначения одного и того же соединения. На рис. 18.2 приведен пример использования идентификаторов DLCI в нерасширенной системе адресации Frame Relay.
Рис. 18.2. Адресация Frame Relay
Предположим, что имеются два постоянных виртуальных канала: между узлами Atlanta и Los Angeles и между узлами San Jose и Pittsburgh (см. рис. 18.2). В узле Los Angeles для обозначения постоянного виртуального канала с узлом Atlanta используется DLCI 12, а в узле Atlanta тот же постоянный виртуальный канал обозначается с помощью DLCI 82. Аналогичным образом, в узле San Jose для обозначения постоянного виртуального канала с узлом Pittsburgh применяется DLCI 12. В сети используются собственные внутренние механизмы, позволяющие различать эти локально значимые идентификаторы постоянных виртуальных каналов.
В конце каждого байта DLCI находится бит расширенного адреса (ЕА — Extended Address). Если этот бит равен 1, то текущий байт является последним байтом DLCI. Во всех реализациях в настоящее время используется двухбайтовый DLCI, но наличие битов ЕА означает, что в будущем могут согласовываться и использоваться более длинные идентификаторы DLCI.
Бит, обозначенный как C/R, который следует за старшим байтом DLCI, в настоящее время не используется.
И, наконец, 3 бита двухбайтового идентификатора DLCI обеспечивают устранение заторов. Бит FECN (Forward Explicit Congestion Notification — прямое явное уведомление о заторе) передается сетью Frame Relay во фрейме в качестве указания получающему фрейм устройству DTE, что в пути от отправителя к получателю наблюдается затор. Бит BECN (Backward Explicit Congestion Notification — обратное явное уведомление о заторе) устанавливается сетью Frame Relay во фреймах, движущихся в направлении, противоположном
тем фреймам, которые на своем пути встретили затор. Назначение обоих этих битов состоит в том, что индикаторы FECN или BECN могут быть переданы протоколу высокого уровня, который может предпринять необходимые действия по управлению потоком данных. (Биты FECN предназначены для протоколов высокого уровня, в которых используются средства управления потоком данных, реализованные в приемном устройстве, а биты BECN необходимы для тех протоколов, в которых применяются средства управления потоком данных, реализованные в передающем устройстве.)
Бит DE (Discard Eligibility — разрешение на уничтожение) устанавливается устройством DTE для передачи сети Frame Relay указания на то, что некоторый фрейм является менее важным по сравнению с другими и должен уничтожаться прежде всех прочих фреймов, если в сети , возникнет нехватка ресурсов. Таким образом, этот бит позволяет реализовать очень простой механизм учета приоритетов. Он обычно применяется, только если в сети возникает затор.
Формат сообщения LMI
В предыдущем разделе описан основной формат пакета протокола Frame Relay, предназначенного для передачи пользовательских фреймов данных. Спецификация Frame Relay, принятая консорциумом, включает также определения процедур LMI. Сообщения LMI передаются во фреймах, отличительной особенностью которых является идентификатор DLCI, предназначенный только для сообщений LMI (он определен в спецификации консорциума как DLCI = 1023). Формат сообщения LMI показан на рис. 18.3.
Длина поля
121111Переменная21
в байтах
Флажок
LMI DLCI
Ненумерованный информационный индикатор
Определитель протокола
Ссылка на вызов
Тип сообщения
Информационные элементы
FCS
Флажок
Рис. 18.3. Формат сообщения LM1
В сообщениях LMI применяется такой же основной заголовок протокола, как и в обычных фреймах данных. Само сообщение LMI начинается с четырех обязательных байтов, за которыми следует переменное количество информационных элементов (IE — Information Element). Формат и кодировка сообщений LMI основаны на стандарте ANSI T1S1.
Первый из обязательных байтов (который именуется ненумерованным информационным индикатором') имеет такой же формат, как и ненумерованный информационный (UI — Unnumbered Information) индикатор фрейма протокола LAP В с битом P/F, равным 0. (Для получения дополнительной информации о протоколе LAPB обратитесь к главе 19.) Следующий байт называется определителем протокола, и значение этого байта служит для определения типа LMI. Третий обязательный байт (ссылка на вызов) всегда заполняется нулями.
Последним обязательным байтом является поле типа сообщения. Определены два типа сообщений. Сообщение с запросом о состоянии позволяет пользовательскому устройству передать запрос на получение информации о состоянии сети. В ответ на сообщения с запросом о состоянии передаются сообщения о состоянии. Примерами таких сообщений являются сообщения поддержки соединения (передаваемые через соединение для обеспечения того, чтобы оба участника соединения продолжали рассматривать его как активное) и сообщения о состоянии постоянного виртуального канала; они принадлежат к числу общих средств LMI, которые рассматриваются как обязательные для включения в любую реализацию, соответствующую спецификации консорциума.
Совместное использование сообщений о состоянии и сообщений с запросом о состоянии позволяет обеспечить целостность логических и физических каналов. Эта информация необходима в маршрутизирующей среде, поскольку решения, вырабатываемые с помощью алгоритмов маршрутизации, основаны на представлении о целостности каналов.
За полем типа сообщения находится определенное количество информационных элементов. Каждый информационный элемент состоит из однобайтового идентификатора IE, поля длины IE и одного или нескольких байтов, содержащих фактические данные.
Глобальная адресация
Кроме общепринятых средств LMI, предусмотрены некоторые необязательные расширения LMI, которые являются крайне важными в среде объединенной сети. Но наиболее важным необязательным расширением LMI является глобальная адресация. Как было отмечено выше, основная (нерасширенная) спецификация Frame Relay поддерживает только такие значения поля DLCI, которые определяют постоянные виртуальные каналы, имеющие локальную значимость. В этом случае не применяются адреса, которые обозначали бы сетевые интерфейсы или узлы, подключенные к этим интерфейсам. Поскольку такие адреса не существуют, их невозможно обнаружить с помощью традиционных методов обнаружения и преобразования адресов. Это означает, что при использовании обычной адресации Frame Relay необходимо создавать статические таблицы преобразования, с помощью которых маршрутизаторы могли бы определить, какой идентификатор DLCI должен применяться для поиска удаленного устройства и связанного с ним адреса в объединенной сети.
Расширение, предусматривающее глобальную адресацию, позволяет использовать идентификаторы узлов. При использовании этого расширения значения, вставленные в поле DLCI фрейма, становятся глобально значимыми адресами отдельных оконечных пользовательских устройств (например, маршрутизаторов). Эта схема реализована, как показано на рис. 18.4.
Рис. 18.4. Обмен данными с использованием глобальной адресации
На рис. 18.4 показано, что каждый интерфейс имеет свой собственный идентификатор. Предположим, что узел Pittsburgh должен отправить фрейм на узел San Jose.
Последний имеет идентификатор 12, поэтому узел Pittsburgh помещает в поле DLCI значение 12 и передает фрейм в сеть Frame Relay. На выходе из сети содержимое поля DLCI изменяется на 13 для указания на исходный узел фрейма. Каждый интерфейс маршрутизатора имеет уникальное значение идентификатора узла, поэтому отдельные устройства можно отличить друг от друга. Такой подход позволяет применять адаптивные средства маршрутизации в сложной сетевой среде.
Глобальная адресация предоставляет значительные преимущества в большой, сложной объединенной сети. После ее внедрения сеть Frame Relay представляется для маршрутизаторов, находящихся на ее периферии, как обычная локальная сеть. Для полного использования возникающих при этом возможностей не требуется вносить никаких изменений в протоколы высокого уровня.
Многоадресатная рассылка
Многоадресатная рассылка является еще одним важным необязательным средством LMI. Группы многоадресатной рассылки обозначаются с помощью ряда из четырех зарезервированных значений DLCI (от 1019 до 1022). Фреймы, передаваемые любым устройством с использованием одного из этих зарезервированных идентификаторов DLC1, тиражируются сетью и передаются во все точки выхода в установленном наборе. В спецификации такого расширения многоадресатной рассылки определены также сообщения LMI, которые предоставляют пользовательским устройствам информацию о добавлении, удалении и присутствии групп многоадресатной рассылки.
В сетях, функционирование которых основано на использовании динамической маршрутизации, необходимо обеспечить обмен маршрутной информацией между многими маршрутизаторами. Маршрутные сообщения могут эффективно передаваться с помощью фреймов, имеющих идентификаторы DLC1, которые указывают на использование многоадресатной рассылки. Это позволяет передавать сообщения в конкретные группы маршрутизаторов.
Конфигурация сети Frame Relay
При реализации средств Frame Relay (и особенно LM1) в объединенной сети во всех точках, находящихся между оконечными устройствами, должны применяться единообразные типы LM1. Тремя допустимыми типами LM1 являются ANSI, Cisco и Q.933A. Современная система Cisco IOS, применяемая в маршрутизаторах Cisco, обеспечивает автоматическое определение типа LMI с помощью информации, полученной от коммутаторов фреймов, к которым они подключены.
Еще одним важным параметром, который необходимо учитывать при организации работы сетей Frame Relay, является исходный тип инкапсуляции, применяемый при активизации протокола в интерфейсе. Этот параметр должен быть одинаковым во всех оконечных устройствах в объединенной сети. Если задача состоит в подключении к сети только устройств Cisco, может применяться инкапсуляция Cisco. Этот тип инкапсуляции предусмотрен в маршрутизаторах Cisco по умолчанию. Если же к сети должны быть подключены аппаратные средства других поставщиков, то должна применяться инкапсуляция IETF.
Создание сети
Протокол Frame Relay может служить в качестве интерфейса к открытой сети, предоставляемой провайдером связи, или к закрытой сети. Типичный подход к реализа-
ции средств Frame Relay в закрытой сети предусматривает установку на традиционных мультиплексорах Т1 интерфейсов Frame Relay для устройств обработки данных, а также интерфейсов, отличных от Frame Relay, для поддержки других приложений, например, предназначенных для передачи голоса и организации видео- и телеконференций. Такая конфигурация показана на рис. 18.5.
Рис. 18.5. Гибридная сеть Frame Relay
Общедоступная служба Frame Relay развертывается путем размещения коммутационного оборудования Frame Relay в помещениях АТС оператора связи. Такой подход к организации сети позволяет предоставить пользователям значительные преимущества: предложить им экономически выгодные тарифы, учитывающие объем передаваемого трафика, и освободить от необходимости выполнять работы по администрированию и сопровождению сетевого оборудования и служб.
В сети того или иного типа каналы, подключающие пользовательские устройства к сетевому оборудованию, могут функционировать на скорости, выбранной из широкого диапазона скоростей передачи данных. Как правило, применяются скорости от 56 Кбит/с до 2 Мбит/с, но сеть Frame Relay может поддерживать и более низкие, и более высокие скорости.
Но, независимо от того, является ли сеть открытой или закрытой, поддержка интерфейсов Frame Relay пользовательским устройством не обязательно означает, что для обмена данными между этими сетевыми устройствами должен применяться только протокол Frame Relay. В настоящее время не существует стандартов, которые определяли бы, как должно обеспечиваться взаимодействие оборудования в сети Frame Relay. Поэтому могут применяться не только традиционные технологии коммутации каналов и коммутации пакетов, но и гибридные подходы, объединяющие эти технологии.
Устранение нарушений в работе сети Frame Relay
В настоящем разделе описаны процедуры поиска неисправностей при решении обычных проблем нарушения связи по каналам Frame Relay. Здесь рассматриваются конкретные признаки неисправностей в сети Frame Relay, перечислены проблемы, которыми может быть обусловлено появление каждого признака неисправности, и показаны способы решения этих проблем.
Настоящий раздел состоит из следующих подразделов, в которых описаны наиболее типичные нарушения в работе сети Frame Relay.
Frame Relay: не функционирует канал Frame Relay.
Frame Relay: не может быть выполнено эхо-тестирование удаленного маршрутизатора.
Frame Relay: не может быть выполнено сквозное эхо-тестирование.
Frame Relay: не функционирует канал Frame Relay
Признак неисправности. Попытки установления соединения по каналу Frame Relay оканчиваются неудачей. В выводе exec-команды show interfaces serial показано, что интерфейс и протокол канала связи не функционируют или что интерфейс функционирует, а протокол канала связи не функционирует.
В табл. 18.1 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
I Таблица 18.1. Frame Relay: не функционирует канал Frame Relay:
ПроблемаРешение
Возникла неисправность кабельной разводки, аппаратных средств или оборудования провайдера связиВозникла неисправность кабельной разводки, аппаратных средств или оборудования провайдера связиВыполните следующие действия в локальном и удаленном маршрутизаторах.
Возникла неисправность кабельной разводки, аппаратных средств или оборудования провайдера связи
Возникла неисправность кабельной разводки, аппаратных средств или оборудования провайдера связи
Шаг 1. Вызовите на выполнение команду show interfaces serial, чтобы определить, находятся ли интерфейс и протокол линии связи в рабочем состоянии.
Шаг 2. Если интерфейс и протокол линии связи не функционируют, проверьте кабель, чтобы убедиться в том, "по он является последовательным кабелем DTE. Проверьте надежность подключения всех кабелей.
Шаг 3. Если применяется кабель соответствующего типа, подключите его к другому порту. Если окажется, что данный порт работает нормально, это означает, что первый порт неисправен. Замените плату или маршрутизатор.
Шаг 4. Если после подключения кабеля ко второму порту этот порт не будет работать, замените кабель. Если это не приведет к устранению нарушения в работе, то причиной неисправности может быть устройство DCE. Сообщите оператору связи об этой проблеме.
Подробные рекомендации по поиску неисправностей последовательных каналов приведены в главе 15
Проблема
Решение
Имеет место несоответствие типов LMI
Шаг 1. Вызовите на выполнение команду show interfaces serial для проверки состояния интерфейса.
Шаг 2. Если вывод этой команды покажет, что интерфейс находится в рабочем состоянии, а протокол линии связи не функционирует, воспользуйтесь exec-командой show frame-relay Imi, чтобы определить, какой тип LMI введен в конфигурацию интерфейса Frame Relay.
Шаг 3. Убедитесь в том, что тип LMI является одним и тем же во всех устройствах на пути от отправителя к получателю. Вызовите на выполнение команду конфигурации интерфейса frame-relay Imi- type {ansi | cisco | q933a}, чтобы откорректировать тип LMI в маршрутизаторе
Не передаются пакеты поддержки соединения
Шаг 1. Введите команду show interfaces, чтобы определить, предусмотрено ли в конфигурации применение пакетов поддержки соединения. Если будет обнаружена строка со словами "keepalives not set", это означает, что применение пакетов поддержки соединения не предусмотрено.
Шаг 2. Вызовите на выполнение команду конфигурации интерфейса keepalive seconds, чтобы определить в конфигурации применение пакетов поддержки соединения. Применяемое по умолчанию значение параметра для этой команды составляет 10 секунд
Несоответствие методов инкапсуляции
Шаг 1. При соединении устройств Cisco с устройствами, отличными от выпускаемых корпорацией Cisco, необходимо использовать метод инкапсуляции IETF в обоих устройствах. Проверьте тип инкапсуляции в устройстве Cisco с помошью exec-команды show framerelay map.
Шаг 2. Если в устройстве Cisco не используется инкапсуляция IETF, вызовите на выполнение команду конфигурации интерфейса encapsulation frame-relay ietf, чтобы ввести в конфигурацию интерфейса Frame Relay устройства Cisco поддержку метода инкапсуляции IETF.
Для ознакомления с дополнительной информацией о просмотре или корректировке конфигурации устройств, не выпускаемых корпорацией Cisco, обратитесь к документации поставшика
Идентификатор DLCI неактивен или удален
Шаг 1. Вызовите на выполнение exec-команду show frame-relay pvc, чтобы определить, в каком состоянии находится постоянный виртуальный канал интерфейса.
Шаг 2. Если в выводе команды показано, что постоянный виртуальный канал неактивен или удален, это означает, что возникло нарушение в работе на пути к удаленному маршрутизатору. Проверьте удаленный маршрутизатор или обратитесь к оператору связи, чтобы проверить состояние постоянного виртуального канала
Проблема
Решение
Идентификатор DLCI должен быть присвоен другому подын- терфейсу
Шаг 1. Вызовите на выполнение привилегированную exec-команду show frame-relay pvc, чтобы проверить назначенные идентификаторы DLCI. Убедитесь в том, что правильные значения идентификаторов DLCI присвоены соответствующим подынтерфейсам. Если идентификатор DLCI неверен, вызовите на выполнение команду по frame-relay map interface-dlci, чтобы удалить неправильную запись с номером DLCI в конфигурации данного интерфейса. Затем воспользуйтесь командой конфигурации интерфейса framerelay map interface-dlci, чтобы определить соответствие между адресом и правильным значением идентификатора DLCI, применяемого для подключения к этому адресу.
Синтаксис
frame-relay map protocol protocol-address dlci [broadcast] [ietf | cisco]
Описание синтаксиса
protocol. Поддерживаемые протоколы: AppleTalk, DECnet, IP, XNS, IPX и VINES.
protocol-address. Протокольный адрес.
dlci. Идентификатор DLCI для данного интерфейса.
broadcast. (Необязательный параметр.) Если не разрешена многоадресатная рассылка, то по этому адресу должны перенаправляться пакеты широковещательной рассылки.
ietf. (Необязательный параметр.) Форма инкапсуляции Frame Relay по спецификации IETF. Применяется, если сервер связи взаимодействует по сети Frame Relay с оборудованием другого поставщика.
cisco. (Необязательный параметр.) Метод инкапсуляции Cisco.
Пример
В следующем примере показано, как преобразовать IP-адрес 131.108.123.1 в идентификатор DLCI 100: interface serial 0 frame-relay map ip 131.108.123.1 100 broadcast
Шаг 2. Если есть основания полагать, что идентификаторы DLCI заданы правильно, остановите основной интерфейс с помощью команды конфигурации интерфейса shutdown, а затем снова переведите интерфейс в рабочее состояние с использованием команды no shutdown
Frame Relay: не может быть выполнено эхо-тестирование удаленного маршрутизатора
Признак неисправности. Попытки выполнить эхо-тестирование удаленного маршрутизатора через соединение Frame Relay оканчиваются неудачей.
В табл. 18.2 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Таблица 18.2
. Frame Relay: не может быть выполнено эхо-тестирование . $ удаленного маршрутизатора■ ., _ j
Решение
Проблема
Несоответствие
Шаг 1. При соединении устройств Cisco с устройствами, отличными от выпус-
методов инкап-
каемых корпорацией Cisco, необходимо использовать метод инкапсуля-
суляции
ции IETF в обоих устройствах. Проверьте тип инкапсуляции в устройстве Cisco с помощью exec-команды show frame-relay map.
Шаг 2. Если в устройстве Cisco не используется инкапсуляция IETF, вызовите на выполнение команду конфигурации интерфейса encapsulation framerelay ietf, чтобы ввести в конфигурацию интерфейса Frame Relay устройства Cisco поддержку метода инкапсуляции IETF.
Дополнительная информация о том, как осуществляется проверка или корректировка конфигурации устройств, не выпускаемых корпорацией Cisco, приведена в документации поставщика
Идентификатор
Шаг 1. Вызовите на выполнение exec-команду show frame-relay pvc, чтобы
DLCI неакти-
определить, в каком состоянии находится постоянный виртуальный
вен или удален
канал интерфейса.
Шаг 2. Если в выводе команды показано, что постоянный виртуальный канал неактивен или удален, это означает, что возникло нарушение в работе на пути к удаленному маршрутизатору. Проверьте удаленный маршрутизатор или обратитесь к оператору связи, чтобы проверить состояние постоянного виртуального канала
Идентификатор
Шаг 1. Вызовите на выполнение привилегированную exec-команду show
DLCI должен быть присвоен
frame-relay pvc, чтобы проверить назначенные идентификаторы
DLCI. Убедитесь в том, что правильные значения идентификаторов
дру!иму нидыН- терфейсу
DLCI присвоены соответствующим подынтерфейсам.
Шаг 2. Если есть основания полагать, что идентификаторы DLCI заданы правильно, остановите основной интерфейс с помощью команды конфигурации интерфейса shutdown, а затем снова переведите интерфейс в рабочее состояние с использованием команды no shutdown
Неправильно
Шаг 1. Вызовите на выполнение привилегированную exec-команду show
настроен спи-
access-lists, чтобы определить, введены ли в состав конфигурации
сок доступа
этого маршрутизатора какие-либо списки доступа.
Шаг 2. Если в конфигурацию входят списки доступа, для проверки возможности установления соединения отмените применение списков доступа с помощью глобальной команды конфигурации no access-group. Проверьте, появилась ли возможность установить соединение.
Шаг 3. Если соединения устанавливаются, последовательно вводите в конфигурацию по одному списку доступа, проверяя возможность установления соединений после ввода каждого списка доступа.
Шаг 4. Если после ввода в конфигурацию определенного списка доступа нарушается процесс установления соединений, убедитесь в том, что этот список доступа не блокирует необходимый трафик. Обязательно введите в конфигурацию явно заданные операторы permit для любого трафика, который должен проходить через соединение.
Шаг 5. Продолжайте проверять и вводить в действие списки доступа до тех пор, пока все они не будут восстановлены, притом что соединения будут по-прежнему устанавливаться успешно
Проблема
Решение
Отсутствует команда framerelay шар
Шаг 1. Воспользуйтесь привилегированной exec-командой show frame-relay map, чтобы определить, выполнена ли настройка таблицы преобразования адресов для данного идентификатора DLCI.
Шаг 2. Если в конфигурации отсутствует таблица преобразования адресов для идентификатора DLCI, введите привилегированную ехес- команду clear frame-relay-inarp, а затем снова вызовите на выполнение команду show frame-relay map, чтобы проверить, имеется ли теперь таблица преобразования для данного идентификатора DLCI.
Шаг 3. Если таблица преобразования для DLCI отсутствует, введите статическую таблицу преобразования адресов. Для этого воспользуйтесь командой конфигурации интерфейса frame-relay map.
Синтаксис
frame-relay map protocol protocol-address dlci [broadcast] [ietf | cisco]
Описание синтаксиса
protocol. Поддерживаемые протоколы: AppleTalk, DECnet, IP, XNS, IPX и VINES.
protocol-address. Протокольный адрес.
dlci. Идентификатор DLCI для данного интерфейса.
broadcast. (Необязательный параметр.) Если не разрешена много- адресатная рассылка, то по этому адресу должны перенаправляться пакеты широковещательной рассылки.
ietf. (Необязательный параметр.) Форма инкапсуляции Frame Relay по спецификации IETF. Применяется, если сервер связи взаимодействует по сети Frame Relay с оборудованием другого поставщика.
cisco. (Необязательный параметр.) Метод инкапсуляции Cisco.
Пример
В следующем примере показано, как преобразовать IP-адрес 131.108.123.1 в идентификатор DLCI 100:
interface serial 0
frame-relay map ip 131.108.123.1 100 broadcast
Шаг 4. Убедитесь в том, что в командах frame-relay map правильно заданы идентификаторы DLCI и адреса следующих транзитных точек перехода. Заданный протокольный адрес должен находиться в той же сети, что и локальный интерфейс Frame Relay.
Подробная информация о настройке таблиц преобразования адресов Frame Relay приведена в документе Cisco IOS Wide-Area Networking Configuration Guide
В операторах frame-relay map отсутствует ключевое слово broadcast
Шаг 1. Вызовите на выполнение привилегированную exec-команду show running-config в локальном и удаленном маршрутизаторах для просмотра информации о конфигурации этих маршрутизаторов. Проверьте записи команды frame-relay map, чтобы определить, задано ли в них ключевое слово broadcast.
Проблема
Решение
Шаг 2. Если ключевое слово broadcast не задано, введите его во все команды frame-relay map.
Синтаксис
frame-relay map protocol protocol-address dlci [broadcast] [ietf | cisco]
Описание синтаксиса
protocol. Поддерживаемые протоколы: AppleTalk, DECnet, IP, XNS, IPX и VINES.
protocol-address. Протокольный адрес.
dlci. Идентификатор DLCI для данного интерфейса.
broadcast. (Необязательный параметр.) Если не разрешена много- адресатная рассылка, то по этому адресу должны перенаправляться пакеты широковещательной рассылки.
ietf. (Необязательный параметр.) Форма инкапсуляции Frame Relay по спецификации IETF. Применяется, если сервер связи взаимодействует по сети Frame Relay с оборудованием другого поставщика.
cisco. (Необязательный параметр.) Метод инкапсуляции Cisco.
Пример
В следующем примере показано, как преобразовать 1Р-адрес 131.108.123.1 в идентификатор DLC1 100: interface serial 0 frame-relay map ip 131.108.123.1 100 broadcast
Примечание. По умолчанию ключевое слово broadcast вводится в динамические таблицы преобразования, сформированные с применением протокола Inverse ARP (Inverse Address Resolution Protocol — протокол обратного преобразования адресов)
Frame Relay: не может быть выполнено сквозное эхо-тестирование
Признак неисправности. Попытки выполнить эхо-тестирование устройств в удаленной сети через соединение Frame Relay оканчиваются неудачей.
В табл. 18.3 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
: Таблица 18.3. Frame Relay: не может быть выполнено сквозноеI
iэхо-тестирование
Проблема
Решение
Проблема расщепления горизонта
В среде звездообразной сети Frame Relay с дополнительными периферийными связями необходимо выполнять настройку конфигурации подынтерфейсов для предотвращения проблем, связанных с наличием растепления горизонта. Подробная информация о настройке конфигурации подынтерфейсов приведена в документах Cisco IOS Wide-Area Networking Configuration Guide и Wide-Area Networking Command Reference.
602
Часть IV. Устранение нарушений в работе последовательных...
ПроблемаПроблемаРешениеРешение
Проблема
Проблема
Решение
Решение
Подынтерфейсы Frame Relay предоставляют механизм поддержки неполносвязных сетей Frame Relay. Функционирование большинства протоколов основано на предположении, что в логической сети обеспечивается транзитивность; это означает, что если станция А может обмениваться данными со станцией В, а станция В — со станцией С, то станция А должна иметь возможность обмениваться данными непосредственно со станцией С. Требование транзитивности соблюдается в локальных сетях, но в сетях Frame Relay оно соблюдается, только если станция А непосредственно связана со станцией С.
Кроме того в неполносвязных сетях не могут поддерживаться такие протоколы, как AppleTalk и протокол прозрачного мостового перенаправления, поскольку они требуют соблюдения принципа расщепления горизонта, согласно которому пакет, полученный через определенный интерфейс, не может быть передан через тот же интерфейс, даже если пакет принимается и передается по разным виртуальным каналам.
Настройка конфигурации подынтерфейсов Frame Relay обеспечивает возможность рассматривать один физический интерфейс как несколько виртуальных интерфейсов. Такая возможность позволяет преодолеть ограничения, вытекающие из принципа расщепления горизонта. Пакеты, полученные через один виртуальный интерфейс, теперь могут быть перенаправлены в другой виртуальный интерфейс, даже если эти виртуальные интерфейсы входят в конфигурацию одного и того же физического интерфейса.
Подынтерфейсы позволяют также преодолеть ограничения нетранзитивных сетей Frame Relay, поскольку предоставляют способ разделить неполносвязную сеть Frame Relay на ряд небольших полносвязных подсетей (между всеми узлами которой установлены соединения “точка-точка"). Каждой подсети присваивается собственный номер сети, и она выглядит с точки зрения протоколов как достижимая через отдельный интерфейс. (Следует отметить, что подынтерфейсы “точка-точка” можно оставлять непронумерованными при подготовке их для использования с протоколом IP, что позволяет уменьшить объем работы по распределению адресов, который в ином случае мог бы стать весьма значительным.)
На рабочей станции отсутствует шлюз, применяемый по умолчаниюНа рабочей станции отсутствует шлюз, применяемый по умолчаниюШаг 1. С локальной рабочей станции или сервера попытайтесь выполнить эхо- тестирование удаленной рабочей станции или сервера. Сделайте еще несколько попыток эхо-тестирования этого удаленного устройства, если первая попытка выполнения команды ping окончилась неудачей.
На рабочей станции отсутствует шлюз, применяемый по умолчанию
На рабочей станции отсутствует шлюз, применяемый по умолчанию
Шаг 2. Если все попытки эхо-тестирования окончились неудачей, проверьте, можно ли выполнить с рассматриваемой локальной рабочей станции или сервера эхо-тестирование интерфейса Frame Relay локального маршрутизатора.
Шаг 3. Если не удается выполнить эхо-тестирование локального интерфейса, проверьте конфигурацию рассматриваемой локальной рабочей станции или сервера, чтобы определить, задана ли в ней спецификация шлюза, применяемого по умолчанию.
Шаг 4. Если шлюз, применяемый по умолчанию, не задан, введите в конфигурацию устройства спецификацию шлюза, применяемого по умолчанию. В качестве шлюза, применяемого по умолчанию, должен быть задан адрес интерфейса локальной сети локального маршрутизатора.
Для ознакомления с информацией о просмотре или корректировке спецификации применяемого по умолчанию шлюза в конфигурации рабочей станции или сервера обратитесь к документации поставщика
Глава
19
[Устранение нарушений |в работе соединений Х.25
В 1970-х годах возникла необходимость в создании набора протоколов, позволяющих пользователям получить доступ к службам распределенной сети, организованным ■ в виде сетей PDN (Public Data Network — открытая сеть передачи данных). Сети PDN ' (например, TYMNET) нашли достаточно широкое распространение, но со временем стало очевидно, что стандартизация протоколов в сетях такого типа будет способство- . вать увеличению количества их подписчиков, повышению функциональной совмес- Ц. тимости оборудования и снижению затрат. Были проведены соответствующие разра- - ботки, и в результате этого создана группа протоколов, из которых наибольшую известность получил протокол Х.25.
Jt Протокол Х.25 был разработан группой национальных операторов связи (т.е. фактически телефонными компаниями), а не отдельным коммерческим предприятием. Поэтому спецификация этого протокола была подготовлена с учетом требований успешной эксплуатации протокола независимо от изготовителя или типа пользовательской системы- Пользователи заключали с операторами сетей связи контракты на использование принадлежащих им сетей коммутации пакетов (PSN — Packet-Switched Network), а платежи по этим контрактам начислялись с учетом продолжительности ..работы пользователей. Контроль над составом предлагаемых служб (и тарифами на ^оплату) осуществлялся FCC.
Одной из уникальных особенностей спецификации протокола Х.25 является ее международный характер. И сам протокол Х.25, и связанные с ним протоколы разрабатываются под руководством агентства ITU1 Организации Объединенных Наций. Разработка осуществляется сектором ITU-T агентства ITU, на который возложена ответственность за проведение работ в области передачи голоса и данных. К числу член Нов ITU-T относятся FCC, европейские организации, занимающиеся стандартизацией в области почтовой связи, телефонии и телеграфии, национальные операторы связи, а также многие компании, специализирующиеся в области вычислительной техники и передачи данных. Поэтому стандарт Х.25 получил мировое признание.
г-
f*!/ International Telecommunications Union — Международный телекоммуникационный союз.
Основы технологии Х.25
Технология Х.25 определяет способ организации телефонной сети для передачи данных. Чтобы приступить к обмену данными, один компьютер передает другому по телефону запрос на установление сеанса связи. Вызываемый компьютер может принять этот запрос или отказать в соединении. Если вызов принят, эти две системы могут приступить к передаче информации в дуплексном режиме. Любой из участников соединения может разорвать его в любое время.
Спецификация Х.25 определяет взаимодействие типа “точка-точка” между оборудованием DTE и ВСЕ. Устройства DTE (терминалы и хосты в составе аппаратных средств пользователя) подключаются к устройствам DCE (модемам, коммутаторам пакетов и другим портам в сети PDN, как правило, находящимся в составе средств оператора сети связи). Устройства DCE, в свою очередь, подключаются к пунктам коммутации пакетов (PSE — Packet-Switching Exchange) и другим устройствам DCE, входящим в состав сети PSN, и в конечном итоге к другим устройствам DTE. Схема взаимодействия объектов в сети Х.25 показана на рис. 19.1.
Устройство DTE может представлять собой терминал, в котором не реализован полный набор функциональных средств Х.25. Устройство DTE подключается к устройству DCE через преобразующее устройство, называемое сборщиком/разборщиком пакетов (PAD — Packet Assembler/Disassembler). Функционирование интерфейса между терминалом и устройством PAD, службы, предоставляемые устройством PAD, и взаимодействие между устройством PAD и хостом, соответственно, определены рекомендациями Х.28, Х.З и Х.29 организации ITU-T.
Спецификация Х.25 соответствует уровням 1-3 эталонной модели OSI. Уровень 3 спецификации Х.25 определяет форматы пакетов и процедуры обмена пакетами между одноранговыми объектами уровня 3. Уровень 2 спецификации Х.25 реализован с
помощью протокола LAPB. Протокол LAPB обеспечивает фреймирование пакетов для канала DTE/DCE. Уровень 1 спецификации Х.25 определяет электронные и механические процедуры перевода в активное и пассивное состояние физической передающей среды, соединяющей устройства DTE и ВСЕ. Это соответствие уровней показано на рис. 19.2. Следует отметить, что спецификации уровней 2 и 3 определены также стандартами ISO 1116 (протокол LAPB) и ISO 8208 (уровень пакетного обмена Х.25).
Эталонная модель
Х.25Х.2576543217654321ОпределяемыйпользователемпроцессОпределяемыйпользователемпроцессУровеньпередачипакетов Х.25Уровеньпередачифреймов Х.25Уровеньпередачипакетов Х.25Уровеньпередачифреймов Х.25Физическийуровень Х.25Физическийуровень Х.25Интерфейс передачи пакетовИнтерфейс передачи пакетовИнтерфейс передачи фреймовИнтерфейс передачи фреймовФизический интерфейсФизический интерфейсСетьс коммутациейпакетовСетьс коммутациейпакетовOSI ,
Х.25
Х.25
7
6
5
4
3
2
1
7
6
5
4
3
2
1
Определяемыйпользователемпроцесс
Определяемыйпользователемпроцесс
Уровеньпередачипакетов Х.25
Уровеньпередачифреймов Х.25
Уровеньпередачипакетов Х.25
Уровеньпередачифреймов Х.25
Физическийуровень Х.25
Физическийуровень Х.25
Интерфейс передачи пакетов
Интерфейс передачи пакетов
Интерфейс передачи фреймов
Интерфейс передачи фреймов
Физический интерфейс
Физический интерфейс
Сетьс коммутациейпакетов
Сетьс коммутациейпакетов
DTEDTEОСЕОСЕИнтерфейсDTE/DCE
DTE
DTE
ОСЕ
ОСЕ
Рис. 19.2. Соотношение между протоколом Х.25 и эталонной моделью 081
В сети Х.25 между устройствами DTE создаются сквозные каналы связи; для этого применяются двунаправленные соединения, называемые виртуальными каналами. Виртуальные каналы обеспечивают связь между различными сетевыми элементами через любое количество промежуточных узлов без постоянного выделения для этой цели частей физической передающей среды, состоящей из электронных цепей. Виртуальные каналы могут быть постоянными или коммутируемыми (временными). Постоянные виртуальные каналы обычно применяются, если между определенными сетями передача данных происходит часто, а коммутируемые виртуальные каналы устанавливаются для единоразовой передачи данных. Уровень 3 спецификации Х.25 определяет правила сквозного взаимодействия с применением и постоянных, и коммутируемых виртуальных каналов.
После установления виртуального канала устройство DTE передает пакеты другому участнику соединения; для этого пакеты передаются в устройство DCE с указанием соответствующего виртуального канала. Устройство DCE проверяет номер виртуального канала и определяет, по какому маршруту должен пройти данный пакет через сеть Х.25. Протокол уровня 3 спецификации Х.25 определяет очередность передачи данных для всех устройств DTE, обслуживаемых конкретным устройством DCE на приемной стороне сети, и пакет доставляется на устройство DTE, указанное в адресе назначения.
Формат фрейма Х.25
На рис. 19.3 показаны поля фрейма Х.25. Фрейм, передаваемый на уровне 3 спецификации Х.25, называется пакетом Х.25 и состоит из заголовка и пользовательских данных. Фрейм, передаваемый на уровне 2 спецификации Х.25 (называемый фреймом LAPB), состоит из нескольких полей, в том числе полей управления и адресации на уровне фрейма, поля с вложенным пакетом уровня 3 и поля FCS.
Примечание. Информация о длине полей и их информационном наполнении была получена из следующих книг: Mark A. Miller, RE., Internetworking, M&TBooks, 1991; William Stallings, Data and Computercommunications, Prentice Hall, 1994.
Puc. 19.3. Структура фрейма LAPB
Уровень 3
Заголовок фрейма уровня 3 спецификации Х.25 состоит из идентификатора общего формата (GFI — General Format Identifier), идентификатора логического канала (LCI — Logical Channel Identifier) и идентификатора типа пакета (PTI — Packet Type Identifier). Идентификатор GFI представляет собой 4-битовое поле, которое обозначает общий формат заголовка пакета. Идентификатор LCI представляет собой 12-битовое поле, которое обозначает виртуальный канал, и является локально значимым в интерфейсе DTE/DCE. Иными словами, для установления виртуального канала сеть PDN соединяет два логических канала с независимыми идентификаторами LCI, которые определены в двух интерфейсах DTE/DCE. Поле PTI определяет один из 17 типов пакетов Х.25.
Поля адресации в пакетах установления коммутируемого вызова содержат адрес передающего и приемного устройств DTE. Они используются для формирования виртуальных каналов, на основе которых организована связь по сети Х.25. Форматы адресов отправителя и получателя определены в рекомендации X. 121 ITU-T. Адреса X. 121 (именуемые также международными номерами данных) изменяются по длине и могут иметь длину до 14 десятичных цифр. Значение длины адреса передающего и приемного устройств DTE определяет четвертый байт в пакете установления коммутируе-
мого вызова. Первые четыре цифры номера IDN именуются идентификационным кодом сетевых данных (DNIC — Data Network Identification Code). Код DNIC подразделяется на две части; первые три его цифры указывают страну, а последняя цифра — саму сеть PSN. Остальные цифры именуются региональным номером оконечного устройства (NTN — National Terminal Number) и служат для обозначения определенного устройства DTE в сети PSN. Формат адреса Х.121 показан на рис. 19.4.
DNIC,NTN, до
4 цифры10 цифр
Длина адреса вызываемого устройства DTE
Длина адреса вызывающего устройства DTE
Страна
PSN
Региональный номер оконечного устройства
Международный номер данных
Рис. 19.4. Формат адреса Х.121
Поля адресации, из которых состоит адрес Х.121, необходимы, только если применяется коммутируемый виртуальный канал (и при этом лишь на время установления соединения). После установления соединения в сети PSN для указания конкретного виртуального канала к удаленному устройству DTE применяется только поле LCI в заголовке пакета данных.
В протоколе Х.25 уровня 3 используются три функциональные процедуры виртуального канала: установление соединения, передача данных и разрыв соединения. Применение этих процедур зависит от типа используемого виртуального канала. При использовании постоянного виртуального канала протокол Х.25 уровня 3 всегда находится в режиме передачи данных, поскольку уже установлен постоянный канал. Если применяется коммутируемый виртуальный канал, то необходимо использовать все три процедуры.
Передача данных осуществляется с помощью пакетов. Протокол Х.25 уровня 3 обеспечивает сегментацию и повторную сборку пользовательских сообщений, если их длина превышает максимально допустимый размер пакета для рассматриваемого канала. Каждому пакету данных присваивается порядковый номер, поэтому в интерфейсе DTE/DCE может осуществляться процесс контроля ошибок и управления потоком данных.
Уровень 2
Протокол Х.25 уровня 2 реализуется с помощью протокола LAPB, который позволяет каждому участнику соединения (устройствам DTE и DCE) инициализировать обмен данными друг с другом. Во время обмена информацией протокол LAPB обеспечивает контроль над тем, чтобы фреймы поступали в приемное устройство в правильной последовательности и без ошибок.
Как и в других аналогичных протоколах канального уровня, в протоколе LAPB используются три типа форматов фрейма.
Информационные фреймы (I — Information). Эти фреймы передают информацию протокола высокого уровня и некоторую управляющую информацию (необходимую для работы в дуплексном режиме). Для управления потоком дан-
ных и исправления ошибок применяются порядковые номера переданных и принятых фреймов и бит конца опроса (P/F — Poll/Final). Порядковым номером переданного фрейма называют номер текущего фрейма. Порядковый номер принятого фрейма соответствует номеру фрейма, который должен быть получен следующим. Если обмен данными осуществляется в дуплексном режиме, то порядковые номера переданных и принятых фреймов контролируются и отправителем, и получателем. Бит конца опроса применяется для обозначения последнего сообщения в ответе; он служит для распознавания и исправления ошибок.
Управляющие фреймы (S — Supervisory). Эти фреймы содержат управляющую информацию. С их помощью можно активизировать и приостановить передачу, получить отчет о состоянии и подтвердить получение фреймов типа I. Эти фреймы не имеют поля данных.
Ненумерованные фреймы (U — Unnumbered). Эти фреймы,"как следует из их названия, не имеют порядковых номеров. Они используются в целях управления. Например, с их помошью можно инициализировать обмен данными с использованием стандартного или расширенного окна (соответственно, с последовательной нумерацией фреймов по модулю 8 или 128), закрыть канал, сообщить об ошибке протокола или выполнить аналогичные функции.
Фрейм LAPB показан на рис. 19.5.
Длина поля
1
1
1
Переменная
2
1
в байтах
Флажок
Адрес
Управляющая информация
Данные
FCS
Флажок
Рис. 19.5. Фрейм LAPB
Ниже описаны поля фрейма LAPB.
Флажки. Эти поля содержат определенную последовательность битов и обозначают начало и конец фрейма LAPB. Для обеспечения того, чтобы такая же последовательность битов не появилась в теле фрейма, применяется вставка битов.
Адрес. Указывает, содержит ли фрейм команду или ответ.
Управляющая информация. Обеспечивает возможность дополнительного уточнения содержимого фреймов команды и ответа, а также обозначает формат фрейма (I, S или U), назначение фрейма (например, в этом поле может быть указано, что приемное устройство готово к приему данных или соединение должно быть разорвано) и порядковый номер переданного/принятого фрейма.
Данные. В этом поле находятся данные протокола высокого уровня. Размер и формат этого поля зависят от типа пакета уровня 3. Максимальная длина данного поля устанавливается в соответствии с соглашением между администратором сети PSN и подписчиком во время оформления подписки на услугу.
FCS. Обеспечивает целостность передаваемых данных.
Уровень 1
В протоколе Х.25 уровня I используется протокол физического уровня X.2l bis, который можно приближенно рассматривать как эквивалентный протоколу EIA/TIA- 232-С (прежнее название — RS-232-C). Протокол X.2I bis соответствует рекомендаци-
ям V.24 и V.28 ITU-T, которые определяют, соответственно, характеристики цепей обмена данными и электрические характеристики интерфейса между устройствами DTE и DCE. Протокол Х.21 bis поддерживает соединения типа “точка-точка” и регламентирует синхронную, дуплексную передачу данных по четырехпроводной передающей среде со скоростью 19,2 Кбит/с. Максимальное расстояние между устройствами DTE и DCE составляет 15 метров.
Устранение нарушений в работе сети Х.25
В настоящем разделе представлены основные сведения по поиску неисправностей, характеризующихся нарушением связи в сети Х.25. В разделе “Применение команды show interfaces serial” рассматривается применение команды show interfaces serial в среде Х.25 и описаны некоторые наиболее важные поля вывода этой команды.
В остальных разделах описаны конкретные признаки неисправностей в сети Х.25, перечислены проблемы, которыми может быть обусловлено появление каждого признака неисправности, и показаны способы решения этих проблем.
Применение команды show interfaces serial
В настоящем разделе описана информация, предоставляемая exec-командой show interfaces serial в среде Х.25. Для ознакомления с дополнительными сведениями о том, какие данные представлены в выводе exec-команды show interfaces serial, обратитесь к главе 15 и изучите документ Cisco IOS Configuration Fundamentals Command Reference.
Команда show interfaces serial предоставляет важную информацию, которая может применяться при устранении нарушений в работе объединенных сетей Х.25. Особенно важные сведения содержатся в следующих полях вывода этой команды.
REJs. Количество отвергнутых фреймов.
SABMs. Количество запросов SABM (Set Asynchronous Balanced Mode — установление асинхронного уравновешенного режима).
RNRs. Количество случаев неготовности получателя.
FRMRs. Количество ошибок во фреймах протокола.
RESTARTS. Количество случаев перезапуска.
Discs. Количество случаев разъединения.
Во всех полях, кроме RESTARTS, регистрируется количество событий LAPB. Поскольку для нормального функционирования протокола Х.25 требуется устойчивый канал связи, нарушения в работе протокола LAPB обычно вызывают перезапуск программного обеспечения протокола Х.25, при котором неявно происходит закрытие всех виртуальных соединений. Если возникают необъяснимые случаи перезапуска Х.25, определите, исправно ли функционирует основное соединение LAPB. Воспользуйтесь exec-командой debug lapb для просмотра всего трафика через интерфейсы, в которых используется инкапсуляция LAPB. Для отмены вывода отладочной информации применяется форма этой команды с префиксом по:
[по] debug lapb
Команда debug lapb отображает информацию о протоколе Х.25 уровня 2. Чтобы иметь возможность в полной мере использовать эту информацию, необходимо изучить работу протокола LAPB. С помощью команды debug lapb можно определить, почему интерфейсы Х.25 или соединения LAPB постоянно переходят то в рабочее, то в нерабочее состояние. Эта команда применяется также при выявлении нарушений в работе канала, на которые указывают представленные в выводе команды show interfaces данные о большом количестве отвергнутых фреймов или фреймов с ошибками при передаче по каналу Х.25.
Предостережение
Соблюдайте осторожность при использовании команд debug. Многие команды debug требуют большого объема процессорного времени и могут вызвать серьезные нарушения в работе сети (такие как снижение производительности или разрыв связи) при их применении в маршрутизаторе, который уже испытывает значительную нагрузку. По завершении использования любой команды debug обязательно отмените ее с помощью соответствующей команды no debug (или введите команду по debug all, чтобы отменить действие всех команд отладки).
На рис. 19.6 показан вывод версии exec-команды show interfaces serial для Х.25 и отмечены наиболее важные поля.
LAPBLAPBSerialO is Hardware Internet MTU 1500SerialO is Hardware Internet MTU 1500up, line protocol is up is MCI Serialaddress is 131.63.125.14 255.255.255.0up, line protocol is up is MCI Serialaddress is 131.63.125.14 255.255.255.01 12056, N2 201 12056, N2 20bytes, BW 1544 Kbit, DLY 20000 useebytes, BW 1544 Kbit, DLY 20000 useeКоличество повторно переданных запросовКоличество повторно переданных запросовrely 255/255, load 1/255rely 255/255, load 1/255Encapsulation X25, loopback not set LAPB DTE? state~CONNECT,] modulo 8, k 7,T1 3000, interface outage (parti^ T3) 0, T4 0VS 1, VR 1, Remote VR 1, Retr remissions 0IFRAMEs 1/1| rNRs 0/c||REJs 0/p]|sABM/Es l/o||FRMRs o/o]|PISCs 0/0Encapsulation X25, loopback not set LAPB DTE? state~CONNECT,] modulo 8, k 7,T1 3000, interface outage (parti^ T3) 0, T4 0VS 1, VR 1, Remote VR 1, Retr remissions 0IFRAMEs 1/1| rNRs 0/c||REJs 0/p]|sABM/Es l/o||FRMRs o/o]|PISCs 0/0Количество случаев ~ ^^~' DTE7 address 170093 , stateR^ modulo 8,Количество случаев ~ ^^~' DTE7 address 170093 , stateR^ modulo 8,регистрации состояния "Not ready" в процессе управления потоком данныхрегистрации состояния "Not ready" в процессе управления потоком данныхDefaults: cisco encapsulateDefaults: cisco encapsulateКоличество случаевКоличество случаевинициализации службы Х.25инициализации службы Х.25idle О,idle О,sizes 128/128\180, TH 05-1024, Outgoing-only nonesizes 128/128\180, TH 05-1024, Outgoing-only noneimer 0imer 0input/output window siinput/output window siу none, Two-wу none, Two-wTimers: Т20 180, Т21 2Channels: Incoming-оTimers: Т20 180, Т21 2Channels: Incoming-о[ RESTARTS 1/1JCALLs -""'East input 0 : 37?35 ,[ RESTARTS 1/1JCALLs -""'East input 0 : 37?35 ,s 2/2, packe , T22 180, T2s 2/2, packe , T22 180, T2Last clearing of " ow interface" Output queue C/4Q/ 0 drops; inputLast clearing of " ow interface" Output queue C/4Q/ 0 drops; input0/0+0/0+0 DIAUs 0/0 tpuc 0:37:33, output hang never0/0+0/0+0 DIAUs 0/0 tpuc 0:37:33, output hang never5555minute inputminute inputminute 014 packe'minute 014 packe'input, 13 bytes.input, 13 bytes.nters never eue 0/75, 0 dropsnters never eue 0/75, 0 dropsate 0 blts/sec, 0/packecs/secate 0 blts/sec, 0/packecs/secООReceived 0 broadcasts, 0 r^nts.Received 0 broadcasts, 0 r^nts.input errors, 0 CRC, 0 ckets output, 33 byoutput errors, 0 col carrier transitionsinput errors, 0 CRC, 0 ckets output, 33 byoutput errors, 0 col carrier transitionspackets/secbuffer0 giants0 overrun, 0 ignored,packets/secbuffer0 giants0 overrun, 0 ignored,Количество попыток подключенияКоличество попыток подключенияКоличество случаев разъединенияКоличество случаев разъединения0 abort0 aborts, 0 underruns sions, 85547 interface resets, 0 restartss, 0 underruns sions, 85547 interface resets, 0 restartsКоличество ошибок во фреймах протоколаКоличество ошибок во фреймах протокола
LAPB
LAPB
SerialO is Hardware Internet MTU 1500
SerialO is Hardware Internet MTU 1500
up, line protocol is up is MCI Serial
address is 131.63.125.14 255.255.255.0
up, line protocol is up is MCI Serial
address is 131.63.125.14 255.255.255.0
1 12056, N2 20
1 12056, N2 20
bytes, BW 1544 Kbit, DLY 20000 usee
bytes, BW 1544 Kbit, DLY 20000 usee
Количество повторно переданных запросов
Количество повторно переданных запросов
rely 255/255, load 1/255
rely 255/255, load 1/255
Encapsulation X25, loopback not set LAPB DTE? state~CONNECT,] modulo 8, k 7,
T1 3000, interface outage (parti^ T3) 0, T4 0
VS 1, VR 1, Remote VR 1, Retr remissions 0
IFRAMEs 1/1| rNRs 0/c||REJs 0/p]|sABM/Es l/o||FRMRs o/o]|PISCs 0/0
Encapsulation X25, loopback not set LAPB DTE? state~CONNECT,] modulo 8, k 7,
T1 3000, interface outage (parti^ T3) 0, T4 0
VS 1, VR 1, Remote VR 1, Retr remissions 0
IFRAMEs 1/1| rNRs 0/c||REJs 0/p]|sABM/Es l/o||FRMRs o/o]|PISCs 0/0
Количество случаев ~ ^^~' DTE7 address 170093 , stateR^ modulo 8,
Количество случаев ~ ^^~' DTE7 address 170093 , stateR^ modulo 8,
регистрации состояния "Not ready" в процессе управления потоком данных
регистрации состояния "Not ready" в процессе управления потоком данных
Defaults: cisco encapsulate
Defaults: cisco encapsulate
Количество случаев
Количество случаев
инициализации службы Х.25
инициализации службы Х.25
idle О,
idle О,
sizes 128/128\
180, TH 0
5-1024, Outgoing-only none
sizes 128/128\
180, TH 0
5-1024, Outgoing-only none
imer 0
imer 0
input/output window si
input/output window si
у none, Two-w
у none, Two-w
Timers: Т20 180, Т21 2
Channels: Incoming-о
Timers: Т20 180, Т21 2
Channels: Incoming-о
[ RESTARTS 1/1JCALLs -""'East input 0 : 37?35 ,
[ RESTARTS 1/1JCALLs -""'East input 0 : 37?35 ,
s 2/2, packe , T22 180, T2
s 2/2, packe , T22 180, T2
Last clearing of " ow interface" Output queue C/4Q/ 0 drops; input
Last clearing of " ow interface" Output queue C/4Q/ 0 drops; input
0/0+0/0+0 DIAUs 0/0 tpuc 0:37:33, output hang never
0/0+0/0+0 DIAUs 0/0 tpuc 0:37:33, output hang never
5
5
5
5
minute input
minute input
minute 01
4 packe'
minute 01
4 packe'
input, 13 bytes.
input, 13 bytes.
nters never eue 0/75, 0 drops
nters never eue 0/75, 0 drops
ate 0 blts/sec, 0/packecs/sec
ate 0 blts/sec, 0/packecs/sec
О
О
Received 0 broadcasts, 0 r^nts.
Received 0 broadcasts, 0 r^nts.
input errors, 0 CRC, 0 ckets output, 33 by
output errors, 0 col carrier transitions
input errors, 0 CRC, 0 ckets output, 33 by
output errors, 0 col carrier transitions
packets/sec
buffer
0 giants
0 overrun, 0 ignored,
packets/sec
buffer
0 giants
0 overrun, 0 ignored,
Количество попыток подключения
Количество попыток подключения
Количество случаев разъединения
Количество случаев разъединения
0 abort
0 abort
s, 0 underruns sions, 85547 interface resets, 0 restarts
s, 0 underruns sions, 85547 interface resets, 0 restarts
Количество ошибок во фреймах протокола
Количество ошибок во фреймах протокола
Puc. 19.6. Вывод версии ехес-команды show interfaces serial для X.25
Х.25: не устанавливаются соединения по каналу Х.25
Признак неисправности. Попытки установления соединения по каналу Х.25 оканчиваются неудачей.
В табл. 19.1 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
(таблица 19.1. Х.25: не устанавливаются соединения ло каналу Х.25 .»
ПроблемаРешение
Канал не функционируетНеправильно выполнена кабельная разводка или неисправно аппаратное обеспечение маршрутизатораКанал не функционируетНеправильно выполнена кабельная разводка или неисправно аппаратное обеспечение маршрутизатораВызовите на выполнение exec-команду show interfaces serial, чтобы определить, функционирует ли канал. Если канал не функционирует, см. главу 15
Канал не функционирует
Неправильно выполнена кабельная разводка или неисправно аппаратное обеспечение маршрутизатора
Канал не функционирует
Неправильно выполнена кабельная разводка или неисправно аппаратное обеспечение маршрутизатора
Шаг 1. Вызовите на выполнение exec-команду show interfaces serial, чтобы определить состояние интерфейса.
Шаг 2. Если интерфейс не функционирует, см. главу 15. Если интерфейс находится в рабочем состоянии, но протокол линии связи не функционирует, проверьте состояние LAPB в выводе команды show interfaces serial.
Шаг 3. Если состояние LAPB отлично от CONNECT, воспользуйтесь привилегированной exec-командой debug lapb (или подключите анализатор последовательных каналов) для просмотра передаваемых сообщений SABM и пакетов UA (Unnumbered Acknowledgment — ненумерованное подтверждение), которые передаются в ответ на сообщения SABM. Если пакеты UA не передаются, то причиной нарушения в работе может быть какая-либо иная проблема, рассматриваемая в настоящей таблице.
Предостережение. Соблюдайте осторожность при использовании команд debug. Многие команды debug требуют большого объема процессорного времени и могут вызвать серьезные нарушения в работе сети (такие как снижение производительности или нарушение связи) при их применении в маршрутизаторе, который уже испытывает значительную нагрузку. По завершении использования любой команды debug обязательно отмените ее с помошью соответствующей команды no debug (или введите команду по debug all, чтобы отменить действие всех команд отладки).
Команды debug должны применяться только для поиска причин неисправностей, а не для контроля над нормальным функционированием сети. Команды debug требуют большого объема процессорного времени, поэтому должны применяться только при анализе трафика определенного типа или при устранении неисправностей, если они позволят сузить круг поиска возможных причин неисправностей.
Шаг 4. Если результаты выполнения exec-команды show interfaces serial показывают, что интерфейс и протокол канала связи находятся в рабочем состоянии, но невозможно установить соединение, то, вероятно, имеет место ошибка в конфигурации маршрутизатора или коммутатора. Ознакомьтесь с описаниями других возможных проблем, приведенными в этой таблице.
Шаг 5. Проверьте всю кабельную разводку и все аппаратные средства на отсутствие повреждений и износа. В случае необходимости замените кабельную разводку или аппаратные средства. Дополнительная информация приведена в главе 3
Проблема
Решение
Неправильно настроены параметры протокола
Шаг 1. Разрешите применение привилегированной exec-команды debug lapb и определите, происходит ли отправка сообщений SABM. Если сообщения SABM передаются, отмените команду debug lapb и разрешите применение привилегированной exec-команды debug х25 events.
Шаг 2. Найдите сообщения RESTART (для постоянных виртуальных каналов) или сообщения CLEAR REQUESTS с ненулевыми кодами завершения (для коммутируемых виртуальных каналов).
Дополнительная информация о том, как должны интерпретироваться причины нарушений в работе сети Х.25 и диагностические коды, показанные в выводе команды debug х25 events, приведена в документе Debug Command Reference.
Шаг 3. Проверьте, соответствуют ли все наиболее важные параметры LAPB (modulo, Tl, Nl, N2 и k) и X.25 (modulo, адреса Х.121, диапазоны коммутируемых виртуальных каналов, определения постоянных виртуальных каналов, а также применяемые по умолчанию размеры окон и пакетов) параметрам, соблюдения которых требует провайдер служб
В составе конфигурации имеется неправильно введенная команда х25 тар
Шаг 1. Воспользуйтесь привилегированной exec-командой show runningconfig для просмотра информации о конфигурации маршрутизатора. Найдите записи команд конфигурации интерфейса х25 тар.
Шаг 2. Убедитесь в том, что в командах х25 тар заданы правильные преобразования адресов.
Чтобы удалить применявшиеся ранее преобразования, вызовите на выполнение команду х25 тар с префиксом по, задав соответствующие параметры сетевого протокола (протоколов) и адреса Х.121: no х25 map protocol address xl21-address
Чтобы обеспечить преобразование протокольных адресов локальной сети в адреса удаленных хостов, вызовите на выполнение команду конфигурации интерфейса х25 тар:
х25 тар protocol address [protoco!2 address2[...[protocols addressS]]] xl21-address [option]
Описание синтаксиса
protocol. Тип протокола, обозначенный ключевым словом. В одной командной строке может быть задано до девяти пар с обозначением протокола и адреса.
address. Протокольный адрес.
хШ-address. Адрес Х.121 удаленного хоста.
option. (Необязательный параметр.) Дополнительные функциональные возможности, которые могут быть указаны для исходящих вызовов.
Проблема
Решение
Шаг 3. Убедитесь в том, что все опции конфигурации Х.25 маршрутизатора соответствуют параметрам подключенных коммутаторов. В случае необходимости внесите изменения в конфигурацию маршрутизатора или коммутатора.
Шаг 4. Разрешите применение команды debug х25 events и найдите сообщения RESTART (для постоянных виртуальных каналов) или сообщения CLEAR REQUESTS с ненулевыми кодами причины (для коммутируемых виртуальных каналов).
Дополнительная информация о том, как должны интерпретироваться причины нарушений в работе сети Х.25 и диагностические коды, показанные в выводе команды debug х25 events, приведена в документе Debug Command Reference
Х.25: чрезмерное количество ошибок последовательной передачи в канале Х.25
Признак неисправности. Вывод команды show interfaces serial показывает, что количество ошибок, зарегистрированное в полях REJs, RNRs, FRMRs, RESTARTS или DISCs, превышает 0,5% от количества информационных фреймов (IFRAMEs).
Примечание
Если значения в любом из этих полей увеличиваются и составляют больше 0,5% от количества информационных фреймов, приведенного в поле IFRAMEs, то, вероятно, имеется неисправность на каком-то участке сети Х.25. Должен быть всегда зарегистрирован, по меньшей мере, один запрос SABM. Но если количество таких запросов превышает 10, то, вероятно, не поступают ответы от коммутатора пакетов.
В табл. 19.2 перечислены основные проблемы, которые могут вызвать появление этого признака неисправности, и описаны решения этих проблем.
[таблица 19.2. Х.25: чрезмерное количество ошибок последовательной ।
Iпередачи в канале Х.25.’
Проблема
Решение
Неправильно выполнена кабельная разводка или не исправны аппаратные средства маршрутизатора
Шаг 1. Вызовите на выполнение exec-команду show interfaces serial, чтобы определить состояние интерфейса.
Шаг 2. Если интерфейс остановлен, см. главу 15. Если интерфейс находится в рабочем состоянии, а протокол линии связи не функционирует, проверьте состояние протокола LAPB в выводе команды show interfaces serial.
Шаг 3. Если состояние протокола LAPB отлично от CONNECT, вызовите на выполнение привилегированную exec-команду debug lapb (или подключите анализатор последовательных каналов), чтобы найти передаваемые запросы SABM и пакеты UA, которые передаются в ответ на запросы SABM.
Проблема
Решение
Шаг 4.
Если результаты выполнения exec-команды show interfaces serial показывают, что интерфейс и протокол канала связи находятся в рабочем состоянии, но невозможно установить соединение, то, вероятно, имеет место ошибка в конфигурации маршрутизатора или коммутатора.
Шаг 5.
Проверьте всю кабельную разводку и все аппаратные средства на отсутствие повреждений и износа. В случае необходимости замените кабельную разводку или аппаратные средства (см. главу 3)
Часть
V
^Устранение нарушений ^'в работе среды маршрутизации
и прозрачного мостового перенаправления
^ ! В этой части...
Глава 20. “Устранение нарушений в работе среды прозрачного мостового перенаправления”
Глава 21. “Устранение нарушений в работе сетей LANE ATM”
Глава 22. “Устранение нарушений в работе постоянных виртуальных рканалов ATM в среде распределенной сети”
Глава 23. “Устранение нарушений в работе средств коммутации
. локальной сети”
Глава
20
странение нарушении работе среды прозрачного
мегового перенаправления
' ^ррозраЧйые^иос.— были впервые разработаны корпорацией Digital Equipment Corj^ration| в йЙЙйе 1980-х годов, а теперь широко применяются в сетях Ethern^^EE 802.А
В^^але нас^й&ей главы определено понятие прозрачного моста как самообу- ’ ющегося к тр^в котором реализован алгоритм распределенного связующего 'деревалЗатем^ъ ней более подробно описан протокол распределенного связую- шего де^евау S
На первыхдфрах Устройства Cisco, обеспечивающие прозрачное мостовое перена- правление^Подрадделялись на две категории: маршрутизаторы, работающие под управлени ! я сиси; я IOS, и коммутаторы ряда Catalyst, в которых эксплуатировалось сйециально^тфограммное обеспечение. Но в настоящее время дело обстоит иначе, поскфгы^Йекоторые продукты ряда Catalyst теперь функционируют под ениелгсйстайы IOS. В настоящей главе представлены различные методы мостового перенаправления, применяемые в устройствах с системой IOS. Для ознакомления с.конкретными сведениями о настройке конфигурации и об устранении нарушений вработ программного обеспечения Catalyst обратитесь к главе 23.
И, на^р^г, Ой главе описаны некоторые этапы устранения нарушений в работе, классифицированные по возможным признакам неисправностей, кото- ^йе обычноувозникают в реализациях сетей, основанных на использовании У*прозрачного ^тестового перенаправления.
Основы^ехнологии прозрачного мостового перенаправления
Прозрачные мосты получили такое название в связи с тем, что они присутствуют в сети и функционируют незаметно для сетевых хостов. После подачи на него питания прозрачный мост изучает топологию сети, анализируя адреса отпра-
к
вителей фреймов, которые поступают из всех подключенных к нему сетей. Например, если мост обнаруживает фрейм, поступающий по каналу 1 от хоста А, он при этом получает информацию о том, что хост А доступен через сеть, подключенную к каналу 1. В процессе такого обучения прозрачный мост формирует таблицу, подобную приведенной в табл. 20.1.
; Таблица 20.1. Таблица прозрачного мостового перенаправления■ }
Адрес хостаНомерсети
0000.0000.00011
0000.b07e.ee0e7
0050.50el.9b804
0060.b0d9.2e3d2
0000.0с8с.70881
Мост использует эту таблицу как основу для перенаправления трафика. После получения фрейма через один из своих интерфейсов мост выполняет поиск адреса назначения этого фрейма во внутренней таблице. Если в таблице имеется информация о соответствии между адресом назначения и одним из портов моста, не совпадающем с тем, из которого был получен фрейм, этот фрейм перенаправляется в указанный порт. Если такая информация о соответствии отсутствует, то фрейм рассылается лавинообразно во все порты, кроме того, через который был получен фрейм. Перенаправление трафика широковещательной и многоадресатной рассылки осуществляется таким же образом.
Прозрачные мосты успешно изолируют внутрисегментный трафик в пределах самого сегмента, что способствует сокращению общего объема трафика, проходящего по каждому отдельному сегменту. В результате время отклика сети заметно уменьшается. Степень сокращения объема трафика и уменьшения времени отклика зависит от того, какую долю составляет межсегментный трафик в общем объеме трафика, а также от объема трафика широковещательной и многоадресатной рассылки.
Устранение циклов мостового перенаправления
При наличии в объединенной сети нескольких путей между любыми двумя локальными сетями алгоритм прозрачного мостового перенаправления перестает функционировать, поскольку возникает зацикливание пакетов. В этом случае для восстановления нормальной работы сети необходимо обеспечить взаимодействие между мостами с помощью определенного протокола. На рис. 20.1 показан пример подобного цикла мостового перенаправления.
Предположим, что хост А передает фрейм хосту В. Фрейм поступает в оба моста, которые делают правильный вывод, что хост А находится в сети 2. К сожалению, после получения хостом В двух копий фрейма от хоста А оба моста снова получают этот фрейм через свои интерфейсы в сети 1, поскольку в широковещательных локальных сетях все хосты получают все сообщения. В некоторых случаях после этого мосты корректируют свои внутренние таблицы, внося в них информацию о том, что хост А находится в сети 1. Если дело обстоит таким образом, то при передаче хостом В ответа на фрейм хоста А оба моста получают, а затем уничтожают эти ответы, так как в их
таблицах указано, что получатель (хост А) находится в том же сетевом сегменте, что и отправитель фрейма.
Сеть 1
Рис. 20.1. Пример непродуманной организации мостового перенаправления и обучения мостов в среде прозрачного мостового перенаправления
В сети, содержащей циклы между мостами, возникают не только нарушения связи, подобные только что описанным, но и стремительное увеличивается количество передаваемых по сети широковещательных сообщений, что может привести к серьезному нарушению в работе сети. Снова рассмотрим рис. 20.1 и предположим, что хостом А был первоначально отправлен широковещательный фрейм. Оба моста будут до бесконечности перенаправлять этот фрейм, и его копии займут всю доступную пропускную способность сети и заблокируют передачу других пакетов в обоих сегментах.
Топология сети, содержащая циклы (рис. 20.2), может не только создавать предпосылки нарушений в работе, но и способствовать улучшению характеристик сети. Если в объединенной сети имеются циклы, это означает, что в ней есть несколько разных маршрутов. А поскольку в сети имеется несколько маршрутов от отправителя к получателю, это способствует повышению обшей отказоустойчивости сети благодаря улучшению топологической гибкости.
Алгоритм распределенного связующего дерева
Алгоритм распределенного связующего дерева (STA — Spanning-Tree Algorithm) был разработан корпорацией Digital, основным поставщиком продуктов Ethernet, в целях использования преимуществ циклов и наряду с этим устранения связанных с ними проблем. Алгоритм, предложенный корпорацией Digital, был в последующем пересмотрен комитетом IEEE 802 и опубликован в виде спецификации IEEE 802.Id. Но алгоритмы Digital и IEEE 802. Id — не одинаковы и не совместимы.
Алгоритм STA предусматривает выделение части топологической схемы сети, не содержащей циклов, путем перевода в заблокированное (зарезервированное) состояние тех портов мостов, которые создавали бы циклы, если бы находились в активном состоянии. Заблокированные порты мостов могут быть активизированы в случае отказа основного канала для создания нового пути через объединенную сеть.
В алгоритме STA для поиска части топологической схемы сети, не содержащей циклов, используются некоторые положения теории графов. В частности, теория графов позволяет обосновать следующее утверждение: “Для любого связного графа, состоящего из узлов и ребер, соединяющих пары узлов, существует связующее дерево, которое также является связным графом, но не содержит циклов”.
На рис. 20.2 показано, как происходит устранение циклов с помощью алгоритма STA. По условиям применения этого алгоритма требуется, чтобы каждому мосту был присвоен уникальный идентификатор. Как правило, такой идентификатор создается путем конкатенации одного из МАС-адресов моста и обозначения приоритета. Каждому порту каждого моста присваивается также уникальный (в пределах этого моста) идентификатор; как правило, в качестве такого идентификатора используется собственный МАС-адрес порта. И, наконец, каждому порту моста присваивается значение стоимости пути. Это значение условно показывает объем затрат на передачу фрейма в локальную сеть через рассматриваемый порт. На рис. 20.3 стоимость пути проставлена на линиях, исходящих из каждого моста. Значения стоимости пути обычно устанавливаются по умолчанию, но сетевые администраторы могут присваивать их вручную.
LANZLANZLANYLANYLANXLANXD — назначенный портR — корневой портБуквами N-Z обозначены локальные сетиD — назначенный портR — корневой портБуквами N-Z обозначены локальные сети
LANZ
LANZ
LANY
LANY
LANX
LANX
D — назначенный порт
R — корневой порт
Буквами N-Z обозначены локальные сети
D — назначенный порт
R — корневой порт
Буквами N-Z обозначены локальные сети
Рис. 20.2. Сеть с прозрачными мостами перед выполнением алгоритма STA
Исходной операцией в процессе вычисления распределенного связующего дерева является выбор корневого моста; таковым становится мост с наименьшим значением идентификатора моста. На рис. 20.2 корневым является мост 1. После этого назначается корневой порт на каждом из остальных мостов. Корневым становится порт некорневого моста, через который проходит путь к корневому мосту, характеризующийся наименьшей суммарной стоимостью. Значение наименьшей суммарной стоимости пути к корневому мосту называется стоимостью корневого пути.
И, наконец, определяются назначенные мосты и их назначенные порты. Назначенным мостом в каждой локальной сети является мост, который характеризуется минимальной стоимостью корневого пути. Назначенный мост локальной сети является единственным мостом, которому разрешено перенаправлять фреймы в локальную сеть и из локальной сети, для которой он служит назначенным мостом. Назначенным портом локальной сети является порт, подключающий ее к назначенному мосту.
В некоторых случаях одинаковую стоимость корневого пути могут иметь два или несколько мостов. Например, как показано на рис. 20.3, и мост 4, и мост 5 могут достичь моста 1 (корневого) по пути со стоимостью 10. В этом случае снова рассматриваются идентификаторы мостов, но на сей раз для определения назначенных мостов. Предпочтительным является меньший идентификатор, поэтому выбирается не порт LAN V моста 5, а порт LAN V моста 4.
С помощью такого процесса из рассмотрения устраняются все мосты, кроме непосредственно подключенных к каждой локальной сети, и поэтому уничтожаются все циклы, возникающие при подключении двух разных мостов к одной локальной сети. Алгоритм STA позволяет также устранять циклы, в которых могут участвовать больше двух локальных сетей, но при этом все равно обеспечивает возможность связи между всеми узлами объединенной сети. На рис. 20.3 показаны результаты применения алгоритма STA к сети, представленной на рис. 20.2, и более отчетливо просматривается древовидная топология. Сравнение этих двух рисунков позволяет сделать вывод, что согласно алгоритму STA порты мостов 3 и 5 к сети LAN V переведены в режим резервирования.
Рис. 20.3. Сеть с прозрачными мостами после выполнения алгоритма STA
Вычисление по алгоритму распределенного связующего дерева происходит после включения питания моста и при обнаружении любого изменения схемы сети. Для такого вычисления требуется взаимодействие мостов распределенного связующего дерева, которое осуществляется с помощью конфигурационных сообщений (иногда их называют BPDU). Конфигурационные сообщения содержат данные о том, какой мост рассматривается как корневой (идентификатор корневого моста), и указывают расстояние от моста-отправителя до корневого моста (стоимость корневого пути). Конфигурационные сообщения содержат также идентификаторы моста и порта, которые служат для обозначения моста-отправителя и продолжительности существования информации, содержащейся в конфигурационном сообщении.
Мосты обмениваются конфигурационными сообщениями через регулярные интервалы (которые обычно составляют от 1 до 4 секунд). Если мост перестает функционировать (что приводит к изменению схемы сети), соседние мосты вскоре обнаруживают отсутствие поступающих от него конфигурационных сообщений и инициализируют повторное применение алгоритма распределенного связующего дерева.
Все решения по определению схемы сети, соединенной прозрачными мостами, принимаются локально. Обмен конфигурационными сообщениями происходит между соседними мостами; какой-либо центральный административный орган, который управлял бы формированием схемы сети, не требуется и поэтому отсутствует.
Формат фрейма
Прозрачные мосты обмениваются конфигурационными сообщениями и сообщениями об изменении топологии. Конфигурационные сообщения передаются от одного моста к другому для формирования топологии сети. Сообщения об изменении топологии передаются после обнаружения изменений в топологии для указания на то, что требуется повторное применение алгоритма STA.
Формат конфигурационного сообщения IEEE 802.Id показан на рис. 20.4.
Рис. 20.4. Конфигурационное сообщение прозрачного моста
Формат сообщения
Ниже перечислены поля конфигурационных сообщений прозрачного моста.
Идентификатор протокола. Содержит значение 0.
Версия. Содержит значение 0.
Тип сообщения. Содержит значение 0.
Флажки. Однобайтовое поле, в котором используются только первые 2 бита. Бит ТС (Topology Change — изменение топологии) сообщает об изменении топологии. Бит ТСА (Topology Change Acknowledgment — подтверждение изменения топологии) устанавливается для подтверждения того, что получено конфигурационное сообщение с установленным битом ТС.
Идентификатор корневого моста. Поле с обозначением корневого моста, состоящее из двухбайтового поля приоритета, за которым следует шестибайтовое поле идентификатора моста.
Стоимость корневого пути. Содержит значение стоимости пути от моста, передающего конфигурационное сообщение, до корневого моста.
Идентификатор моста. Поле, состоящее из подполей приоритета и идентификатора моста, передающего сообщение.
Идентификатор порта. Обозначает порт, из которого было отправлено конфигурационное сообщение. Это поле позволяет обнаруживать циклы, создающиеся при наличии между сегментами нескольких мостов, и принимать меры по их устранению.
Продолжительность существования сообщения. Указывает, сколько времени прошло с тех пор, как корневой мост отправил конфигурационное сообщение, на котором основано текущее конфигурационное сообщение.
Максимальная продолжительность существования сообщения. Указывает, когда должно быть удалено текущее конфигурационное сообщение.
Интервал между hello-сообщениями. Показывает периодичность передачи конфигурационных сообщений корневым мостом.
Прямая задержка. Задает продолжительность времени, в течение которого мосты должны оставаться в прежнем состоянии перед переходом в новое состояние, вызванное изменением топологии. Если мосты сразу же переходят в новое состояние, не все сетевые каналы успевают изменить свое состояние, а это может привести к появлению циклов.
Сообщения об изменении топологии состоят только из 4 байтов. Они включают поле идентификатора протокола, которое содержит значение 0, поле версии, которое содержит значение 0, и поле типа сообщения, которое содержит значение 128.
Различные методы мостового перенаправления, применяемые в системе IOS
В маршрутизаторах Cisco предусмотрены три различных метода осуществления мостового перенаправления.
Метод, применяемый по умолчанию. До появления средств IRB и CRB (они описаны ниже) вариант, при котором осуществлялось либо мостовое перенаправление, либо маршрутизация трафика какого-либо протокола, выбирался только для всей платформы. Это означает, что после включения в конфигурацию устройства, например команды ip route, во всех интерфейсах этого устройства выполнялась только маршрутизация трафика IP. При этом была исключена возможность выполнять мостовое перенаправление трафика IP в каком-либо из интерфейсов того же маршрутизатора.
Метод CRB (Concurrent Routing and Bridging — параллельная маршрутизация и мостовое перенаправление). Метод CRB позволяет определить для каждого отдельного интерфейса, следует ли в нем осуществлять мостовое перенаправление или маршрутизацию трафика какого-либо протокола. Это означает, что такой метод позволяет маршрутизировать трафик определенного протокола в одних интерфейсах и выполнять мостовое перенаправление трафика того же протокола в интерфейсах мостов того же маршрутизатора, объединенных в группу. Таким образом, отдельное устройство может одновременно выполнять функции и маршрутизатора, и моста для трафика определенного протокола, но не предусмотрена возможность осуществлять какую-либо связь между интерфейсами, предназначенными для маршрутизации, и интерфейсами группы мостов. Для каждого конкретного протокола данное физическое устройство можно фактически рассматривать как несколько независимых логических устройств (например, как один маршрутизатор и один или несколько мостов, как показано на рис. 20.5).
Мост CRBМост CRBИнтерфейс EO IP-адрес X
Мост CRB
Мост CRB
Интерфейс 1 IP-адрес Y
Интерфейс Е2
Группа мостов 1
Интерфейс ЕЗ
Мост 1, протокол IEEE
При использовании такой конфигурации устройство Cisco, обрабатывающее трафик протокола IP, выполняет для интерфейсов ЕО и Е1 функции маршрутизатора, а для интерфейсов Е2 и ЕЗ — функции моста. Следует учитывать, что между этими группами интерфейсов нет никакой связи (хост, подключенный к ЕО, не сможет получить через маршрутизатор с этой конфигурацией доступ к хосту, подключенному к Е2).
Рис. 20.5. Физический маршрутизатор, рассматриваемый как несколько различных независимых логических устройств
Метод IRB (Integrated Routing and Bridging — совместная маршрутизация и мостовое перенаправление). Метод IRB предоставляет возможность осуществлять маршрутизацию трафика между группой мостов и маршрутизирующим интерфейсом на основе концепции, получившей название виртуального интерфейса группы мостов (ВVI — Bridge-Group Virtual Interface). Поскольку мостовое перенаправление осуществляется на канальном уровне, а маршрутизация — на сетевом, эти два метода управления трафиком имеют различные модели конфигурации протокола. Например, при управлении трафиком IP интерфейсы группы мостов принадлежат к одной и той же сети и имеют общий сетевой IP-адрес, тогда как каждый маршрутизирующий интерфейс представляет отдельную сеть и имеет свой собственный сетевой IP- адрес. Концепция виртуального интерфейса группы мостов была разработана в целях обеспечения возможности выполнять обмен пакетами определенного протокола через эти интерфейсы. Поэтому маршрутизатор Cisco, в котором применяется данный метод, по существу можно рассматривать как маршрутизатор, подключенный к одной или нескольким группам мостов, как показано на рис. 20.6.
Мост IRB
Интерфейс ЕО
IP-адрес X
Интерфейс Е1
1Р-адресУ
Интерфейс Е2
Группа мостов 1
Интерфейс ЕЗ
Группа мостов 1
Интерфейс BV11
IP-адрес Z Мост 1, протокол IEEE
Виртуальный интерфейс группы мостов позволяет обеспечить маршрутизацию трафика группы мостов 1. С его помощью можно присвоить IP-адрес всей группе мостов и организовать связь по маршрутизируемому протоколу, например, между хостом, подключенным к ЕО, и хостом, подключенным к Е2.
Рис. 20.6. Виртуальный интерфейс группы мостов, обеспечивающий маршрутизацию трафика группы мостов
Интерфейс BVI можно рассматривать как виртуальный интерфейс маршрутизатора, действующий как обычный маршрутизирующий интерфейс, который является представителем соответствующей группы мостов по отношению к другим маршрутизирующим интерфейсам маршрутизатора. Номер интерфейса, присвоенный интерфейсу BVI, является номером группы мостов, которую представляет этот виртуальный интерфейс. Данный номер служит для установления соответствия между интерфейсом BVI и группой мостов. Примером применения этой концепции является модуль RSM (Route Switch Module — модуль коммутатора маршрутов) коммутатора Catalyst, как показано на рис. 20.7.
Метод IRB используется также (но неявно) в модуле коммутатора маршрутов (RSM — Route Switch Module) Catalyst. Интерфейсы VLAN представляют собой виртуальные интерфейсы, соединяющие различные группы мостов (виртуальные локальные сети).
Рис. 20.7. Модуль RSM коммутатора Catalyst
Устранение нарушений в работе средств прозрачного мостового перенаправления
В настоящем разделе представлена информация по поиску неисправностей, характеризующихся нарушением связи в объединенных сетях с прозрачным мостовым перенаправлением. Здесь описаны конкретные признаки нарушений в работе средств прозрачного мостового перенаправления, перечислены проблемы, которые могут вызвать каждый признак неисправности, и приведены решения этих проблем.
Примечание
Проблемы, связанные с нарушениями в работе средств мостового перенаправления от отправителя (SRB — Source-Route Bridging), мостового перенаправления с трансляцией и прозрачного мостового перенаправления от отправителя (SRT — SourceRoute Transparent), рассматриваются в главе 10.
Для обеспечения эффективного поиска неисправностей в сети, соединенной мостами, необходимо иметь следующую основную информацию о ее структуре, особенно если для организации ее работы применяется алгоритм распределенного связующего дерева.
Топологическая схема сети, соединенной мостами.
Местонахождение корневого моста.
Местонахождение избыточных каналов (и заблокированных портов).
В процессе поиска неисправностей, характеризующихся нарушением связи, следует стремиться сузить до минимума количество рассматриваемых хостов (и в идеальном случае рассматривать только один клиент и один сервер).
В следующих разделах описаны наиболее распространенные нарушения в работе сетей, соединенных прозрачными мостами.
Прозрачное мостовое перенаправление: отсутствие связи.
Прозрачное мостовое перенаправление: нестабильное распределенное связующее дерево.
Прозрачное мостовое перенаправление: непредвиденное завершение сеансов.
Прозрачное мостовое перенаправление: возникают циклы, и происходит лавинообразная рассыпка широковещательных пакетов.
Прозрачное мостовое перенаправление: отсутствие связи
Признак неисправности. Клиент не может подключиться к хостам по сети, соединенной прозрачными мостами.
В табл. 20.2 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
| Таблица 20.2. Прозрачное мостовое перенаправление: отсутствие связи
Проблема
Решение
Возникло нарушение в работе аппаратных средств или передающей среды
Шаг 1. Вызовите на выполнение exec-команду show bridge, чтобы определить, не возникло ли нарушение связи. Если это действительно так, то в выводе команды не будут показаны какие-либо МАС-адреса из таблицы мостового перенаправления.
Шаг 2. Воспользуйтесь exec-командой show interfaces, чтобы определить, находятся ли интерфейс и протокол линии связи в рабочем состоянии.
Шаг 3. Если интерфейс не функционирует, устраните нарушения в работе аппаратных средств или передающей среды (см. главу 3).
Шаг 4. Если не функционирует протокол линии связи, проверьте физическое соединение между интерфейсом и сетью. Убедитесь в том, что соединение выполнено надежно и кабели нс повреждены.
Если протокол линии связи функционирует, но значения счетчиков входных и выходных пакетов не наращиваются, проверьте состояние передающей среды и связь с хостом. Для получения более подробной информации об устранении нарушений в работе передающей среды обратитесь к главе данной книги, в которой рассматриваются вопросы устранения нарушений в работе передающей среды, применяемой в конкретной сети
Хост не функционирует
Шаг 1. Вызовите на выполнение exec-команду show bridge в мостах, чтобы убедиться в том, что таблица мостового перенаправления содержит МАС-адреса подключенных оконечных узлов.
Таблица мостового перенаправления содержит МАС-адреса передающих и приемных хостов, а заполнение этой таблицы происходит при прохождении через мост пакетов, передаваемых отправителем или получателем.
ПроблемаПроблемаРешениеРешениеНарушен путь мостового перенаправленияНарушен путь мостового перенаправленияНеправильно настроены фильтры мостового перенаправленияНеправильно настроены фильтры мостового перенаправления
Проблема
Проблема
Решение
Решение
Нарушен путь мостового перенаправления
Нарушен путь мостового перенаправления
Неправильно настроены фильтры мостового перенаправления
Неправильно настроены фильтры мостового перенаправления
Шаг 2. Если в таблице отсутствует информация о каких-либо оконечных узлах, которые должны находиться в сети, проверьте состояние этих узлов, чтобы убедиться в том, что они подключены к сети и в них соответствующим образом выполнена настройка конфигурации.
Шаг 3. В случае необходимости снова инициализируйте оконечные узлы или откорректируйте их конфигурацию, а затем опять проверьте таблицу мостового перенаправления с помощью команды show bridge
Шаг 1. Определите, по какому пути должны проходить пакеты от одного оконечного узла к другому. Если в этом пути находится маршрутизатор, то разделите процедуру поиска неисправностей на два этапа: от узла 1 к маршрутизатору и от маршрутизатора к узлу 2.
Шаг 2. Подключитесь к каждому мосту в пути и проверьте состояние портов, которые используются в пути между оконечными узлами, как описано в предыдущем разделе, посвященном устранению нарушений в работе аппаратных средств или передающей среды.
Шаг 3. С помощью команды show bridge проверьте, накапливается ли информация о МАС-адресах узлов при прохождении трафика через соответствующие порты. Если дело обстоит иначе, то может иметь место нестабильность топологии распределенного связующего дерева (см. табл. 20.3).
Шаг 4. Проверьте состояние портов с помощью команды show span. Если порты, которые должны передавать трафик между оконечными узлами, не находятся в состоянии перенаправления, то может оказаться, что произошло неожиданное изменение топологии дерева (см. табл. 20.3.)
Шаг 1. Вызовите на выполнение привилегированную exec-команду show running-config, чтобы определить, выполнена ли настройка конфигурации фильтров моста.
Шаг 2. Отмените фильтры моста в интерфейсах, которые могут явиться причиной неисправности, и определите, восстановилась ли связь.
Шаг 3. Если связь нс восстановилась, то причиной се нарушения нс являются фильтры. Если же связь после удаления фильтров восстанавливается, то причиной нарушения связи является один или несколько неправильно заданных фильтров.
Шаг 4. Если имеется несколько фильтров или в фильтре заданы списки доступа с несколькими операторами, вводите каждый фильтр по отдельности, чтобы определить, в каком из них имеется ошибка. Проверьте конфигурацию для входных и выходных фильтров LSAP и TYPE, которые могут применяться одновременно для блокировки трафика разных протоколов. Например, фильтр LSAP (F0F0) может применяться для блокировки трафика NetBIOS, a TYPE (6004) — для блокировки трафика транспортного протокола локальной сети.
Проблема
Решение
Шаг 5. Откорректируйте все фильтры или списки доступа, которые блокируют трафик. Продолжайте проверять и вводить в действие фильтры до тех пор, пока не будут разрешены все фильтры, а соединения будут по-прежнему устанавливаться успешно
Заполнены входные и выходные очереди
Чрезмерные объемы трафика многоадресатной или широковещательной рассылки приводят к переполнению входной и выходной очередей, что влечет за собой уничтожение пакетов.
Шаг 1. Вызовите на выполнение команду show interfaces, чтобы определить, происходит ли уничтожение входных и выходных пакетов. Если количество уничтоженных пакетов слишком велико, это означает, что через данную передающую среду проходит слишком интенсивный трафик. Если текущее количество пакетов во входной очереди неизменно составляет или превышает 80% от текущего размера входной очереди, то размер входной очереди может потребовать корректировки в соответствии с интенсивностью поступления входящих пакетов. Даже если создается впечатление, что текущее количество пакетов во входной очереди никогда не приближается к размеру входной очереди, в сети может происходить лавинообразное увеличение количества пакетов, что приводит к переполнению очереди.
Шаг 2. Уменьшите трафик широковещательной и многоадресатной рассылки в подключенных сетях с помощью фильтров мостового перенаправления, увеличьте количество сегментов в сети, установив дополнительное количество устройств, применяемых для создания объединенных сетей.
Шаг 3. Если соединение представляет собой последовательный канал, увеличьте его пропускную способность, примените организацию очередей по приоритетам, увеличьте размер резервной очереди или откорректируйте размеры системных буферов (см. главу 15)
Прозрачное мостовое перенаправление: нестабильное распределенное связующее дерево
Признак неисправности. Периодическое нарушение связи между хостами. Это нарушение в работе затрагивает одновременно несколько хостов.
В табл. 20.3 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Таблица 20.3. Прозрачное мостовое перенаправление: нестабильное .Vраспределенное связующее дерево
Проблема
Решение
Периодически закрывается канал
Шаг 1. Вызовите на выполнение команду show span, чтобы определить, не происходит ли постоянное увеличение количества зарегистрированных случаев изменения топологии.
Шаг 2. Если это действительно так, проверьте канал между мостами с помощью команды show interface. Если пока не удается найти периодически закрывающийся канал между мостами, вызовите на выполнение в мостах привилегированную exec-команду debug spantree event.
Эта команда позволяет записать в журнал все изменения, касающиеся распределенного связующего дерева; если топология является стабильной, то таких изменений быть не должно. Но остается необходимость контролировать только каналы, которые соединяют устройства, обеспечивающие мостовое перенаправление, поскольку переходные процессы в канале к оконечной станции не должны воздействовать на сеть.
Предостережение. Соблюдайте осторожность, используя команду debug spantree event. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и уменьшения числа пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы
Определение корневого моста постоянно изменяется;
сразу несколько мостов объявляют себя корневыми
Шаг 1. Проверьте единообразие информации о корневом мосте во всей сети, соединенной мостами; для этого вызовите на выполнение команды show span на разных мостах.
Шаг 2. Если несколько мостов объявляют, что они корневые, проверьте, применяется ли один и тот же протокол распределенного связующего дерева во всех мостах (см. раздел “Несовпадение алгоритмов распределенного связующего дерева" в табл. 20.5).
Шаг 3. Вызовите на выполнение команду bridge <group> priority <пшпЬег> в корневом мосте, чтобы вынудить требуемый мост стать корневым. Чем ниже значение приоритета priority, тем выше вероятность того, что данный мост станет корневым.
Шаг 4. Проверьте диаметр сети. Если заданы стандартные параметры настройки распределенного связующего дерева, количество транзитных переходов мостового перенаправления между двумя хостами никогда не должно превышать семи
Не происходит обмен hello- фреймами
Шаг 1. Проверьте, взаимодействуют ли хосты друг с другом. Воспользуйтесь сетевым анализатором или привилегированной ехес-командой debug spantree tree, чтобы определить, происходит ли обмен hello- фреймами распределенного связующего дерева.
Проблема
Решение
Предостережение. Соблюдайте осторожность, используя команду debug spantree tree. Поскольку процессы формирования отладочного вывода имеют высокий приоритет среди процессов, использующих ресурсы процессора, то применение команды debug может привести к нарушению работы системы. По этой причине команды debug предназначены только для диагностирования конкретных проблем или для проведения сеансов поиска неисправностей с участием персонала службы технической поддержки корпорации Cisco. Кроме того, команды debug следует использовать в периоды снижения интенсивности сетевого трафика и уменьшения числа пользователей. Проведение отладки в эти периоды снижает вероятность того, что повышенные издержки, связанные с выполнением команд debug, отразятся на работоспособности системы.
Шаг 2. Если обмен hello-фреймами не происходит, проверьте физические соединения и конфигурацию программного обеспечения в мостах
Прозрачное мостовое перенаправление: непредвиденное завершение сеансов
Признак неисправности. Соединения в сети, объединенной прозрачными мостами, устанавливаются успешно, но сеансы иногда заканчиваются без какой-либо очевидной причины.
В табл. 20.4 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
i Таблица 20.4. Прозрачное мостовое перенаправление: непредвиденное *
Проблема
завершение сеансов ..]
Решение
Слишком много случаев повторной передачи фреймов
Шаг 1. Воспользуйтесь сетевым анализатором для определения количества случаев повторной передачи фреймов хостом.
Шаг 2. Если случаи повторной передачи обнаруживаются в медленных последовательных каналах, увеличьте установки таймеров передачи в хосте. Для получения информации о настройке конфигурации хостов обратитесь к документации поставщика. Информация о нарушении в работе последовательных каналов приведена в главе 15.
Если случаи повторной передачи обнаруживаются в высокоскоростной передающей среде локальной сети, проверьте, не происходит ли нарушение порядка следования передаваемых и принимаемых пакетов или их уничтожение каким-либо промежуточным устройством, например мостом или коммутатором. В случае необходимости устраните нарушение в работе передающей среды локальной сети. Для получения дополнительной информации обратитесь к главе, в которой рассматривается тип передающей среды, применяемой в конкретной сети.
Шаг 3. Воспользуйтесь сетевым анализатором, чтобы определить, уменьшилось ли количество случаев повторной передачи
Проблема
Решение
Чрезмерная задержка при передаче по последовательному каналу
Увеличьте пропускную способность, примените организацию очередей по приоритетам, увеличьте размер резервной очереди или откорректируйте размеры системных буферов (см. также главу 15)
Прозрачное мостовое перенаправление: возникают циклы, происходит лавинообразная рассылка широковещательных пакетов
Признак неисправности. В среде прозрачного мостового перенаправления происходит зацикливание пакетов и лавинообразная рассылка широковещательных пакетов. На оконечных станциях приходится слишком часто выполнять повторную передачу, что приводит к завершению сеансов по тайм-ауту или их разрыву.
Примечание
Зацикливание пакетов обычно возникает по причинам, обусловленным самим проектом сети, или из-за нарушений в работе аппаратных средств.
В табл. 20.4 кратко перечислены проблемы, которые могут вызвать этот признак неисправности, и описаны решения этих проблем.
Циклы мостового перенаправления в сети, соединенной мостами, являются наиболее опасной причиной неисправностей, поскольку они способны нарушить работу буквально всех пользователей. В экстренных случаях наилучший способ быстрого восстановления связи — закрытие вручную всех интерфейсов, создающих избыточный путь в сети. К сожалению, если устранение нарушения в работе осуществляется таким образом, то в дальнейшем очень сложно определить причину возникновения цикла мостового перенаправления. Если это возможно, вначале попытайтесь выполнить действия, рекомендуемые в табл. 20.5.
I Таблица 20.5.
Прозрачное мостовое перенаправление: возникают циклы, j происходит лавинообразная рассылка широковещательных | пакетов . .
Проблема
Решение
Не реализован алгоритм распределенного связующего дерева
Шаг 1. Изучите схему топологии объединенной сети, чтобы определить наличие возможных циклов.
Шаг 2. Устраните все существующие циклы или убедитесь в том, что соответствующие каналы (которые могут образовать циклы) находятся в режиме резервирования.
Шаг 3. Если по-прежнему наблюдаются случаи лавинообразного увеличения количества широковещательных пакетов и зацикливания пакетов, вызовите на выполнение exec-команду show interfaces, чтобы получить статистические данные о количестве входных и выходных пакетов. Если показания этих счетчиков увеличиваются слишком быстро (по сравнению с тем, как они увеличиваются при обычных нагрузках по потоку сообщений), то в сети, вероятно, все еще присутствует цикл.
Проблема
Решение
Несоответствие версий алгоритма распределенного связующего дереваНесоответствие версий алгоритма распределенного связующего дереваНастройка конфигурации нескольких доменов мостового перенаправления выполнена неправильноНастройка конфигурации нескольких доменов мостового перенаправления выполнена неправильноОшибка канала (однонаправленный канал), несовпадение дуплексного и полудуплексного режима передачи, высокий уровень ошибок в портуОшибка канала (однонаправленный канал), несовпадение дуплексного и полудуплексного режима передачи, высокий уровень ошибок в порту
Несоответствие версий алгоритма распределенного связующего дерева
Несоответствие версий алгоритма распределенного связующего дерева
Настройка конфигурации нескольких доменов мостового перенаправления выполнена неправильно
Настройка конфигурации нескольких доменов мостового перенаправления выполнена неправильно
Ошибка канала (однонаправленный канал), несовпадение дуплексного и полудуплексного режима передачи, высокий уровень ошибок в порту
Ошибка канала (однонаправленный канал), несовпадение дуплексного и полудуплексного режима передачи, высокий уровень ошибок в порту
Шаг 4. Примените алгоритм распределенного связующего дерева, чтобы предотвратить образование циклов
Шаг 1. Вызовите на выполнение exec-команду show span в каждом мосте для определения применяемого в нем алгоритма распределенного связующего дерева.
Шаг 2. Убедитесь в том, что во всех мостах эксплуатируется один и тот же алгоритм распределенного связующего дерева (либо DEC, либо IEEE). Применение алгоритмов распределенного связующего дерева и DEC, и IEEE может потребоваться только в некоторых сетях с очень необычной конфигурацией (как правило, в сочетании с применением метода IRB). Если несоответствие протоколов распределенного связующего дерева возникло непреднамеренно, необходимо откорректировать конфигурацию мостов соответствующим образом, чтобы во всех мостах применялся один и тот же алгоритм распределенного связующего дерева.
Примечание. Алгоритмы распределенного связующего дерева DEC и IEEE являются несовместимыми
Шаг 1. Вызовите на выполнение exec-команду show span в мостах, чтобы убедиться в том, что все номера групп доменов для конкретных доменов мостового перенаправления совпадают.
Шаг 2. Если в конфигурации рассматриваемого моста определено несколько групп доменов, убедитесь в том, что все спецификации доменов заданы правильно. Воспользуйтесь глобальной командой конфигурации bridge <group> domain <domain-nuinber> для внесения всех необходимых изменений.
Шаг 3. Убедитесь в том, что не существует циклов между доменами мостового перенаправления. Среда междоменного мостового перенаправления не обеспечивает предотвращения циклов на основе распределенного связующего дерева. Каждый домен имеет собственное распределенное связующее дерево, независимое от распределенного связующего дерева другого домена
Если порт, который должен быть заблокирован, переходит в состояние перенаправления, возникают циклы. Чтобы оставаться заблокированным, порт должен получать сообщения BPDU от соседнего моста. Поэтому любые нарушения в работе, которые приводят к потере сообщений BPDU, могут стать причиной возникновения цикла мостового перенаправления.
Шаг 1. Определите по схеме сети, какие порты должны быть заблокированы.
Шаг 2. В конкретной сети, соединенной мостами, проверьте состояние портов, которые должны быть заблокированы, с помощью ехес- команд show interface и show bridge.
ПроблемаРешение
Шаг 3. Если будет обнаружен порт, который должен быть заблокирован, но фактически осуществляет перенаправление (или вскоре будет его осуществлять, поскольку находится в состоянии накопления информации или приема пакетов), это означает, что действительно обнаружена причина проблемы. Проверьте, получает ли порт сообщения BPDU. В случае отрицательного ответа, вероятно, имеется нарушение в работе канала, подключенного к этому порту (поэтому проверьте наличие ошибок в канале, правильность установок дуп- лексного/полудуплексного режима и т.д.). Если же порт все еше получает сообщения BPDU, перейдите к мосту, который по вашим предположениям должен быть назначенным для данной локальной сети. С этого моста проверьте все каналы в пути к корневому мосту. Нарушение в работе должно иметь место в одном из этих каналов (при условии, что схема сети, которой вы руководствовались с самого начала, была правильной)
Подготовка к получению консультации в центре ТАС компании Cisco Systems
Рекомендуем собрать максимально возможный объем информации о топологии конкретной сети заблаговременно, пока не возникли нарушения в ее работе.
В процессе подготовки к устранению возможного нарушения в работе сети необходимо, как минимум, собрать следующую информацию.
Физическая топология сети.
Предполагаемое местонахождение корневого моста (и резервного корневого моста).
Местонахождение заблокированных портов.
Дополнительные источники информации
Литература
Кларк К., Гамильтон К., Принципы коммутации в локальных сетях Cisco — М. : Издательский дом “Вильямс", 2003 г.
Perlman, Radia. Interconnections, Bridges and Routers. Boston: Addison-Wesley, 1998.
Сетевые информационные ресурсы
Документация по прозрачному мостовому перенаправлению (ww.cisco.com/ univercd/cc/td/doc/product/software/iosl20/12cgcr/ibm_c/bcprtl/bctb.htm)
Страницы технологической поддержки на узле ССО (ww.cisco.com/tac/); часть, посвященная локальным сетям, в разделе Technology Home Page.
Глава
21
Устранение нарушений в работе сетей LANE ATM
В настоящей главе приведен общий обзор методов устранения нарушений в работе сетей LANE (LAN Emulation — эмуляция локальной сети).
В начале этой главы кратко описано назначение технологии LANE, которая представляет собой технологию локальной сети, предназначенную для эмуляции традиционной сети Ethernet на основе средств ATM. Затем рассматривается процедура устранения наиболее характерных нарушений в работе сети LANE, состоящая из следую. ших двух этапов. . .
Устранение нарушений в работе сети LANE, при которых не происходит запуск клиента.
Устранение нарушений связи в сети LANE (после перехода клиента LANE в рабочее состояние).
Введение
Протокол LANE определен организацией ATM Forum. Он предоставляет станциям, подключенным к сети ATM, такие же возможности, какие обычно предусмотрены ' в традиционных локальных сетях Ethernet. Как подразумевает само его название, протокол LANE предназначен для эмуляции локальной сети на основе средств сети ATM. Протокол LANE позволяет представить интерфейс ATM как один или несколько отдельных интерфейсов Ethernet, что дает возможность пользователям локальной сети обращаться ко всем средствам ATM, не внося изменений в аппаратное или программное обеспечение оконечной станции.
ATM — это служба с установлением логических соединений, которая основана на создании соединений между устройствами, передающими и принимающими информацию. В отличие от этого, протоколы, основанные на использовании локальной сети, не предусматривают установления логического соединения, а для обеспечения возможности поиска устройствами-отправителями одного или нескольких устройств-получателей в этих протоколах часто применяется широковещательная рассылка. Поэтому основное назначение протокола LANE состоит в предоставлении доступа к службам, которые поддерживает такая широковещательная передающая среда, как Ethernet.
Протокол LANE предусматривает преобразование МАС-адресов в ATM-адреса для того, чтобы оконечные системы LANE могли устанавливать между собой непосредственные соединения, а затем передавать данные. Программное обеспечение протокола LANE может быть развернуто на подключенных к сети ATM устройствах следующих двух типов.
Хосты или маршрутизаторы с сетевыми платами ATM. В сетевых платах ATM реализованы протокол LANE и интерфейс к сети ATM и в то же время представлен текущий интерфейс служб Ethernet к драйверам протоколов высокого уровня. Протоколы сетевого уровня продолжают функционировать так же, как и в сети Ethernet, поскольку в них могут применяться известные процедуры. В то же время в этих протоколах может использоваться основная часть развитых служб сети ATM.
Ко второму типу сетевых устройств, в которых реализована спецификация LANE, относятся коммутаторы и маршрутизаторы локальной сети, подключенной к сети ATM. Эти устройства наряду с непосредственно подключенными хостами ATM, оборудованными сетевыми платами ATM, применяются для предоставления доступа к службе виртуальной локальной сети, в которой определяется принадлежность всех портов к конкретным виртуальным локальным сетям, независимо от их физического местонахождения.
В спецификации LANE определено несколько компонентов, которые дают возможность использовать данный протокол для предоставления доступа к службам широковещательной рассылки и преобразования адресов, которые требуются для эмуляции традиционных локальных сетей. Эти компоненты перечислены ниже.
ЕЕС^клиент. Это такой объект, как рабочая станция, коммутатор локальной сети или маршрутизатор, который обеспечивает перенаправление и прием данных, преобразование адресов и другие функции управления для отдельной оконечной точки в отдельной эмулируемой локальной сети. LEC-клиент предоставляет доступ к стандартным службам локальной сети для любых сопряженных с ним протоколов более высокого уровня. В любом маршрутизаторе или коммутаторе может быть размещено несколько LEC-клиентов, подключенных к различным эмулируемым локальным сетям. Такой клиент протокола LANE регистрирует свой МАС- и ATM-адрес в LES-сервере.
ЕЕ5-сервер. Сервер, предоставляющий доступ к средствам регистрации для клиентов, которые должны быть подключены к эмулируемой локальной сети. Кроме всего прочего, LES-сервер обрабатывает запросы протокола LE_ARP (LAN Emulation Address Resolution Protocol — протокол преобразования адресов в эмулированной LAN) и ведет список (или поисковую таблицу) МАС-адресов локальной сети назначения. LES-сервер должен быть установлен в каждой эмулируемой локальной сети.
BUS-cepeep. Сервер, который выполняет лавинообразную рассылку трафика с неизвестным адресом получателя, а также перенаправляет многоадресатный и широковещательный трафик клиентам эмулируемой локальной сети. BUS- сервер должен быть установлен в каждой эмулируемой локальной сети.
LEC (LAN Emulation Client — клиент LAN Emulation).
Примечание
реализации спецификации LANE корпорации Cisco LES- и BUS-серверы объединены в одном устройстве.
LECS-cepBep. Сервер, который распределяет отдельных клиентов по конкретным эмулируемым локальным сетям, направляя их к LES-серверу, соответствующему эмулируемой локальной сети. LECS-сервер позволяет обеспечить защиту, контролируя распределение LEC-клиентов по конкретным эмулируемым сетям с учетом их МАС-адресов. Тем не менее данный компонент, т.е. LECS- сервер, является необязательным в технологии LANE, поскольку клиент для подключения к конкретной эмулируемой локальной сети может обращаться непосредственно к LES-серверу.
Устранение нарушений в работе сети
LAN Emulation
Теоретические основы технологии сети LANE нельзя назвать слишком сложными, но в процессе развертывания этой сети необходимо выполнить настройку ее конфигурации в нескольких разных устройствах и ввести в эту конфигурацию много длинных адресов ATM. В процессе ввода такой информации можно легко допустить опечатку, в результате чего весь процесс начальной установки оканчивается неудачей. Поэтому чаше всего слова “устранить нарушения в работе сети LANE” означают просто “заставить ее работать”! По этой причине настоящий раздел разбит на две части.
В начале раздела “Устранение нарушений в работе, при которых не происходит запуск LEC-клиентов” рассматриваются задачи первоначальной настройки конфигурации, необходимой для запуска LEC-клиента.
Добившись успешного подключения к сети всех LEC-клиентов, можно перейти ко второй части, представленной в табл. 21.2, в которой более подробно рассматривается устранение нарушений в работе уже действующей сети.
Устранение нарушений в работе, при которых не происходит запуск LEC-клиентов
На рис. 21.1 приведена блок-схема процедуры устранения нарушений в работе, рассматриваемых в настоящем разделе. Вызовите на выполнение exec-команду show lane client в устройстве, на котором развернут LEC-клиент. Прочитайте в выводе этой команды содержимое поля Last Fail Reason (Причина последнего отказа), проанализируйте сложившуюся ситуацию и перейдите к соответствующему разделу в табл. 21.1 (команда show lane client подробно рассматривается ниже, в разделе “Описание вывода команды show lane client”). Если нарушение в работе не удалось устранить с помощью процедуры, представленной в блок-схеме, обратитесь к разделу “Все действия по устранению нарушений в работе оказались безрезультатными” табл. 21.1.
Рис. 21.1. Блок-схема устранения нарушений в работе, при которых не происходит запуск LEC-клиента
Таблица 21.1. Устранение нарушений в работе LEC-клиентов
Проблема
Решение
Невозможно подключиться к LECS-серверу (сообщение "Config VC being released"): не может быть получен префикс. Неудачно завершена настройка конфигурации виртуального канала:
Шаг 1. Введите команду show lane default. Проверьте, показаны ли в выводе этой команды полные адреса ATM. Если префикс присваивается должным образом, в выводе этой команды, как правило, отображается примерно следующее:
ok# sh lane default
interface ATM2/0:
LANE Client:
47.00918100000001604799FD01.0050A219F038.**
LANE Server:
47.00918100000001604799FD01.0050A219F039.**
LANE Bus:
47.00918100000001604799FD01.0050A219F03A.**
невозможно создать сообщение SETUP для передачи на LECS- сервер
LANE Config Server:
47.00918100000001604799FD01.0050A219F03B. 00
Примечание. Символами ** обозначен байт номера подынтерфейса в шестнадцатеричном коде
В противном случае в начале каждого адреса отображается многоточие (...). При этом вывод команды выглядит примерно так:
notok#sh lane default
interface ATM1/0:
LANE Client:...00000C409820.**
LANE Server:...00000C409821.**
LANE Bus:...00000C409822.**
LANE Config Server: ...00000C409823.00 Примечание. Символами ** обозначен байт номера подынтерфейса в шестнадцатеричном коде
Шаг 2. Проверьте, выполнена ли настройка в интерфейсе ATM интерфейса ILMI постоянного виртуального канала. В конфигурацию интерфейса должна быть включена команда atm pvc <х> 0 16 ilmi (где х обозначает номер постоянного виртуального канала; следует учитывать, что значение VPI может быть отлично от 0). Проверьте также с помощью команды atm pvc <Х> 0 5 qsaal, выполнена ли настройка конфигурации постоянного виртуального канала, применяемого для передачи сигналов.
Шаг 3. Вызовите на выполнение команду show atm ilmi-status, чтобы проверить, находится ли интерфейс ILMI в исправном и работоспособном состоянии
Проблема
Решение
Невозможно подключиться к LECS-серверу (сообщение "Config VC being released11): неправильный адрес LECS- сервера
Шаг 1. Проверьте ATM-адрес LECS-сервера, приведенный в выводе команды show lane client. Если он равен
47.007900000000000000000000.00А03Е000001.00, но в сети не должен был применяться этот общепринятый адрес, то, вероятно, он присвоен в связи с тем, что устройство не могло получить адрес LECS-сервера через интерфейс ILMI.
Если удаленный коммутатор ATM не является устройством Cisco, необходимо соблюдать осторожность, поскольку некоторые поставщики не поддерживают анонсирование адресов LECS-серверов через интерфейс ILMI. В этом случае, например, можно попытаться применить в LECS-сервере указанный выше общепринятый адрес.
Проверьте в коммутаторе ATM, к которому подключен клиент, задан ли с помощью команды atm lecs-address-default адрес LECS-сервера.
Шаг 2. Если в составе конфигурации жестко закодирован АТМ-адрес LECS-сервера или имеется АТМ-адрес LECS-сервера, который отличается от общепринятого адреса, представленного в выводе команды show lane client, перейдите к устройству, на котором развернут LECS-сервер. Вызовите на выполнение команду show lane config, чтобы сравнить значение адреса LECS-сервера с тем значением, которое было представлено в выводе команды show на клиентском устройстве, а также проверьте, находится ли сервер в исправном и работоспособном состоянии
LECS-сервер не выполняет запросы на установление соединения (сообщение "Receiving negative config response")
Шаг 1. Проверьте в конфигурации информацию о типе (Ethemet/Token Ring) и имени эмулируемой локальной сети, к которой вы пытаетесь подключиться. Установите соединение с устройством, на котором развернут LECS-сервер, и проверьте, заданы ли в его конфигурации такие же значения имени и типа эмулируемой локальной сети.
Шаг 2. Проверьте, может ли быть выполнено соединение LES- и LECS- сервера. На устройстве, на котором развернут LES-сервер, вызовите на выполнение команду show lane server и проверьте, показывает ли ее вывод, что LECS-сервер подключен (connected). LES- серверу для подключения к LECS-серверу требуется такая же информация, как и обычному клиенту. Обратитесь к предыдущему разделу таблицы, “Невозможно подключиться к LECS-серверу"
Невозможно подключиться к LES-серверу (сообщение "Control Direct VC being released”)
Шаг 1. Если в конфигурации жестко закодирован адрес LES-сервера, проверьте компьютер, на котором развернут LES-сервер, чтобы определить, полностью ли совпадает его адрес с адресом, введенным в конфигурацию.
Шаг 2. На устройстве, на котором развернут LECS-сервер, проверьте, была ли введена в базу данных LECS-сервера запись для данной эмулируемой локальной сети с правильным адресом LES-сервера. Для получения такой информации перейдите на устройство, на котором развернут LES-сервер, и введите команду show lane default
Проблема
Решение
LES-сервер не выполняет запросы на установление соединения (сообщение "Receiving negative join response")LES-сервер не выполняет запросы на установление соединения (сообщение "Receiving negative join response")Шаг 1. Если доступ к эмулируемой локальной сети, к которой вы пытаетесь подключиться, является ограниченным и если вы пытаетесь подключиться к LES-серверу непосредственно, минуя LECS- сервер, такая попытка является нарушением защиты. Проверьте конфигурацию базы данных LANE на LECS-сервере, чтобы убедиться в том, что она включает ATM-адрес клиента, пытающегося подключиться к LES-серверу.
LES-сервер не выполняет запросы на установление соединения (сообщение "Receiving negative join response")
LES-сервер не выполняет запросы на установление соединения (сообщение "Receiving negative join response")
Все действия по устранению нарушений в работе оказались безрезультатнымиВсе действия по устранению нарушений в работе оказались безрезультатнымиШаг 2. Если в одном и том же подынтерфейсе выполнена настройка конфигурации LEC-клиента и LES-сервера, а также с помощью команды lane server-atm-address задан ATM-адрес для LES- сервера, то LEC-клиент может попытаться обратиться к резервному LES-серверу (который отказывает в соединении). Причина этого заключается в том, что LEC-клиент также использует команду lane server-atm-address, чтобы определить, к какому LES- серверу необходимо подключиться. Затем клиент обязательно подключается к локальному LES-серверу, который в настоящее время может находиться в режиме резервирования. Для устранения такого нарушения в работе проще всего выполнить настройку конфигурации LES-сервера в другом подынтерфейсе
Все действия по устранению нарушений в работе оказались безрезультатными
Все действия по устранению нарушений в работе оказались безрезультатными
РешениеРешениеЗа несложной ошибкой в конфигурации может фактически скрываться более серьезное нарушение в работе самой сети. Разрешите применение команды debug lane client all на своем компьютере и обратитесь к разделу “Пример подключения клиента LANE при использовании команды debug lane client all”, чтобы сравнить полученные данные с результатами успешно выполненного подключения. Соблюдайте осторожность, используя команду debug lane client all. При распределении процессорного времени процессу формирования отладочного вывода присваивается один из самых высоких приоритетов, поэтому система может стать непригодной для выполнения обычной работы. Команды debug следует использовать в период сокращения сетевого трафика и уменьшения количества пользователей. Нельзя допускать вывода подробной отладочной информации на консоль (с использованием команды logging console info). Вместо этого направьте вывод команды debug в буфер журнала с помощью' команды logging buffer <buffer-size> debug
Решение
Решение
Не может быть выполнен процесс, предусмотренный протоколом LE_ARP
Шаг 1. Найдите IP-адрес, с которым невозможно установить соединение (иными словами, адрес, эхо-тестирование которого выполнить невозможно).
Шаг 2. Запишите действительный МАС-адрес, соответствующий этому IP-адресу. Такая информация может быть получена непосредственно на самой станции.
Проблема
Проблема
Решение
При использовании средств повышения избыточности SSRP7 эмулируемая локальная сеть разбивается на две частиПри использовании средств повышения избыточности SSRP7 эмулируемая локальная сеть разбивается на две частиПри использовании HSRP8 нарушилась работа шлюза, применяемого по умолчаниюПри использовании HSRP8 нарушилась работа шлюза, применяемого по умолчанию
При использовании средств повышения избыточности SSRP7 эмулируемая локальная сеть разбивается на две части
При использовании средств повышения избыточности SSRP7 эмулируемая локальная сеть разбивается на две части
При использовании HSRP8 нарушилась работа шлюза, применяемого по умолчанию
При использовании HSRP8 нарушилась работа шлюза, применяемого по умолчанию
Шаг 3. Убедитесь в том, что действительно не определено соответствие между этим МАС-адресом и ATM-адресом получателя. Для такой проверки можно применить команду show lane le-arp. Обратитесь к разделу “Описание процесса применения протокола LE_ARP", приведенному ниже в этой главе.
Шаг 4. Вероятно, отсутствует связь с LEC-клиентом назначения. Вызовите на выполнение команду show lane client и проверьте, действительно ли LEC-клиент назначения находится в состоянии ”up/operational”. Обратитесь к следующей возможной проблеме, которая возникает, если эмулируемая локальная сеть разбивается на две части
Такая ситуация возникает, если после перехода двух клиентов в рабочее состояние они должны были войти в состав одной и той же эмулируемой локальной сети, но в действительности подключились к разным LES- серверам. Подобная проблема является серьезным нарушением связи в сети. Она возникает, если некоторые LEC-клиенты перешли в нерабочее состояние, а затем подключились к резервному LECS-серверу, LES- или BUS-серверу. В результате оба рассматриваемых LEC-клиента перешли в рабочее состояние, но не могут вступить во взаимодействие друг с другом.
Шаг 1. Найдите два клиента LANE, между которыми отсутствует связь.
Эти клиенты LANE должны находиться в состоянии "up/operational".
Шаг 2. Вызовите на выполнение команду show lane client name <elanname> на обоих клиентах.
Шаг 3. Проверьте ATM-адрес в строке с указанием соединения непосредственного типа (direct). Если в выводе команды на разных клиентах показаны различные ATM-адреса, то действительно сформировались две отдельные эмулируемые локальные сети. Это означает, что в одной из эмулируемых локальных сетей основной LES-сервер не доступен и поэтому клиенты устанавливают соединение с резервным LES-сервером.
Шаг 4. В базе данных LECS-сервера найдите LES-сервер с наивысшим приоритетом (таковым является LES-сервер, находящийся в этой базе данных на первом месте). Затем найдите клиент, который подключается к резервному адресу и не может установить соединение с этим основным LES-сервером. Примите во внимание, что может иметь место серьезное нарушение физической связи между этим LEC-клиентом и основным LES-сервером
Создается впечатление, что нарушения связи полностью отсутствуют, но некоторые пользователи сообщают, что несколько раз в сутки не удается выполнить эхо-тестирование шлюза, применяемого по умолчанию. Такие перерывы в работе продолжаются несколько минут. Применяемый по умолчанию шлюз определен виртуальным IP-адресом HSRP. Подобные ситуации часто возникают, если пользователи для подключения к сети ATM применяют устройства, отличные от устройств Cisco.
Проблема
Решение
Шаг 1. Необходимо модернизировать программное обеспечение всех устройств и установить его новейшие версии.
Шаг 2. Настоятельно рекомендуется также использовать в предусмотренном по умолчанию шлюзе действительный МАС-адрес. Для этого в конфигурационном интерфейсе маршрутизатора введите следующую команду:
RouterName(config-if)# standby use-bia
Здесь параметр use-bia означает, что должен применяться прошитый адрес (BIA — Burned-In Address), а не виртуальный МАС- адрес. Прошитый адрес маршрутизатора можно определить, вызвав на выполнение в маршрутизаторе команду show interface
Нарушение в работе VP’-туннелей с ограничением трафика
Иногда для создания канала между двумя удаленными территориальными сетями ATM применяется VP-туннель с ограничением трафика. Проектировщик сети должен проследить за тем, чтобы для такого канала была зарезервирована достаточная пропускная способность. Если объем трафика между узлами двух территориальных сетей превышает возможности VP- туннеля, часть ячеек будет отброшена, что приведет к потере фрейма.
При использовании проектов такого рода дтя организации трафика между подобными узлами настоятельно рекомендуется применять маршрутизацию. Устранение рассматриваемого нарушения в работе часто становится затруднительным. Для ознакомления с дополнительной информацией обратитесь к главе 22. При устранении рассматриваемого нарушения в работе применяются процедуры поиска неисправностей, описанные в этой главе
Нарушение процесса передачи сигналов ATM
Такое нарушение в работе принадлежит к числу наиболее сложных. Связь между двумя клиентами LANE отсутствует. Оба они находятся в состоянии "up/operational". Даже несмотря на то, что в конфигурации имеется соответствующая запись 1е-агр, непосредственное соединение передачи данных по виртуальному каналу не устанавливается.
Шаг 1. Найдите два клиента сети LANE, между которыми отсутствует связь.
Шаг 2. Проверьте, содержат ли записи 1е-агр в конфигурации обоих клиентов все необходимые параметры и правильный АТМ-адрес.
Шаг 3. Убедитесь в том, что между этими клиентами сети LANE не устанавливается непосредственное соединение для передачи данных. Выполните такую проверку с помощью команды show lane client и удостоверьтесь, что в ее выводе отсутствует виртуальный канал типа data.
Шаг 4. Разрешите применение команд debug atm sig-error и debug atm errors. Проверьте, не появляется ли ошибка сигнализации ATM при попытке выполнить эхо-тестирование. Ишите сообщения с кодом причины "cause code".
Шаг 5. Такие проблемы обычно возникают в сетевой среде, созданной с применением оборудования многих поставщиков. Если после выполнения шагов 1~4 нарушение в работе не удается устранить, модернизируйте программное обеспечение всех устройств, переведя его на новейшую версию
9 VP (Virtual Path — виртуальный маршрут).
Приложение: команды и примеры
В настоящем разделе приведены примеры команд debug и show, наиболее часто применяемых при устранении нарушений в работе сети LANE.
Пример подключения клиента LANE при использовании команды debug lane client all
На рис. 21.2 показано, какие виртуальные каналы (ВК) необходимы для работы сети LANE.
1-7 — непосредственный управляющий ВК 2-8 — распределенный управляющий ВК 3-11 — непосредственныйуправляющий ВК (клиент)1-7 — непосредственный управляющий ВК 2-8 — распределенный управляющий ВК 3-11 — непосредственныйуправляющий ВК (клиент)4-9—ВК многоадресатной передачи5-10 — ВК многоадресатного перенаправления6-6—ВК непосредственной передачи данных11-12 — непосредственныйуправляющий ВК (сервер)4-9—ВК многоадресатной передачи5-10 — ВК многоадресатного перенаправления6-6—ВК непосредственной передачи данных11-12 — непосредственныйуправляющий ВК (сервер)
1-7 — непосредственный управляющий ВК 2-8 — распределенный управляющий ВК 3-11 — непосредственный
управляющий ВК (клиент)
1-7 — непосредственный управляющий ВК 2-8 — распределенный управляющий ВК 3-11 — непосредственный
управляющий ВК (клиент)
4-9—ВК многоадресатной передачи
5-10 — ВК многоадресатного перенаправления
6-6—ВК непосредственной передачи данных
11-12 — непосредственный
управляющий ВК (сервер)
4-9—ВК многоадресатной передачи
5-10 — ВК многоадресатного перенаправления
6-6—ВК непосредственной передачи данных
11-12 — непосредственный
управляющий ВК (сервер)
Рис. 21.2. Схема виртуальных каналов, необходимых для работы сети LANE
Ниже перечислена последовательность событий, которые должны произойти при переходе LEC-клиента в рабочее состояние (цифровые обозначения каналов показаны на рис. 21.2). Эти события отображаются в выводе команды debug lane client all, вызванной на выполнение в LEC-клиенте.
Событие Configure direct (Открытие непосредственного конфигурационного виртуального канала) (3-11).
Событие Control direct (Открытие непосредственного управляющего виртуального канала) (1-7).
Событие Control distribute (Открытие распределенного управляющего виртуального канала) (2-8).
Событие Multicast send (Открытие виртуального канала многоадресатной передачи) (4-9).
Событие Multicast forward (Открытие виртуального канала многоадресатного перенаправления) (5-10).
Событие Data direct (Открытие виртуального канала непосредственной передачи данных) (6-6), в результате которого появляется возможность передавать данные от одного LEC-клиента к другому; в выводе команды debug не отображается.
Применяемые АТМ-адреса, которые представлены в выводе команды debug
Ниже перечислены АТМ-адреса LECS-сервера, LES-сервера, BUS-сервера и LEC- клиента, применяемые в данном примере.
LECS-сервер:47.00918100000000603Е899601.00Е01Е2ЕЕ8ВЗ.00
LES-сервер:47.00918100000000603Е899601.00Е01Е2ЕЕ8В1.01
BUS-сервер:47.00918100000000603Е899601.00Е01Е2ЕЕ8В2.01
LEC-сервер:47.00918100000000603Е899601.00Е01Е2ЕЕ8В0.01
Имя сети ELAN: Elanl
Регистрация адреса с помощью интерфейса ILMI
Сначала LEC-клиент регистрирует свой АТМ-адрес в сети ATM.
LEG АТМ0.1: action A_REGISTER_ADDR
LEG ATM0.1: predicate PRED_LEC_NSAP TRUE
LEG ATM0.1: state IDLE event LEC_LOCAL_ACTIVATE => REGISTER_ADDR
LEG ATM0.1: action A_POST_LISTEN"
LEG ATM0.1: sending LISTEN
LEG ATM0.1: listen on 47.00918100000000603E899601.00E01E2EE8B0.01
LEG ATM0.1: state REGISTER_ADDR event LEC_CTL_ILMI_SET_RSP_POS => POSTING_LISTEN
LECATM0.1: received LISTEN- -- - --
LEG ATM0.1: action A_ACTIVATE_LEC
LEG ATM0.1: predicate PRED_CTL_DIRECT_NSAP FALSE
LEG ATM0.1: predicate PRED_LECS_NSAP FALSE
LEG ATM0.1: state POSTING_LISTEN event LEC_SIG_LISTEN_POS => GET_LECS_ADDR
LEG ATM0.1: action A_ALLOC_LECS_ADDR""
LEG ATM0.1: state GET LECS-ADDR""event LEG CTL ILMI SET RSP POS => GET LEGS ADDR
Подключение к LECS-серверу (открытие непосредственного конфигурационного виртуального канала)
LEC-клиент устанавливает соединение с LECS-сервером (двунаправленный виртуальный канал типа “точка-точка"), чтобы определить АТМ-адрес LES-сервера для своей эмулируемой локальной сети. После выполнения данного шага этот виртуальный канал к LECS-серверу освобождается.
LEC-клиент определяет АТМ-адрес LECS-сервера, предпринимая попытки применить следующие три метода в указанном порядке.
Использование жестко закодированного АТМ-адреса.
Получение адреса LECS-сервера с помощью параметров VPI = 0, VCI = 16 интерфейса ILMI (не поддерживается в оборудовании некоторых поставщиков).
Фиксация адреса, который определен организацией ATM Forum:
(47.007900000000000000000000.00А03Е000001.00).
Используя то же соединение по виртуальному каналу, LECS-сервер возвращает АТМ-адрес LES-сервера для эмулируемой локальной сети LEC-клиента.
В приведенном ниже выводе команды debug показано, что LEC-клиент получает адрес LECS-сервера через интерфейс ILMI.
LEC АТМ0.1: action A_SEND_LECS_SETUP
LEG АТМ0.1: sending SETUP "
LEC ATM0.1:callid0x40518C04
LEC ATM0.1:called party47.00918100000000603E899601.00E01E2EE8B3.00LEGS address
LEC ATM0.1:calling_party47.00918100000000603E899601.00E01E2EE8B0.01LEC address
LEC ATM0.1: state GET_LECS_ADDR event LEC_CTL_ILMI_SET RSP_NEG => LECS_CONNECT
LEC ATM0.1: received CONNECT
LEC ATM0.1:callid0x40518C04
LECATM0.1:vcd884
LEC ATM0.1: action A_SEND_CFG_REQ
LEC ATM0.1: sending LANE_CONFIG_REQ on VCD 884
LEC ATM0.1: SRC MAC address 00e0.le2e.e8b0 LEG'S MAC address
LEC ATM0.1:SRCATM address47.00918100000000603E899601.00E01E2EE8B0.01
LEC ATM0.1:LANType 1
LEC ATM0.1:Frame size1
LEC ATM0.1: LAN Name elanl elan LEC is trying to join
LEC ATM0.1:LANName size5
LEC ATM0.1: state LEGS CONNECT event LEC SIG CONNECT => GET LES ADDR
LEC ATM0.1: received LANE CONFIG RSP on VCD 884
LEC АТМ0.1:
SRC MAC address
00e0.le2e.e8b0
LEG АТМ0.1:
SRC ATM address
47.00918100000000603E899601.00E01E2EE8B0.01
LEC АТМ0.1:
LAN Type 1
LEG АТМ0.1:
Frame size
1
LEG АТМ0.1:
LAN Name elanl
LEC АТМ0.1:
LAN Name size
5
LEC ATM0.1:
LEC ATM0.1:
LEC ATM0.1:
LEC ATM0.1:
action A_PROCESS_CFG_RSP
sending RELEASE
callid0x40518C04
cause code31
LEC ATM0.1: state GET_LES_ADDR event LEC_CTL_CONFIG_RSP_POS => LEGS RELEASE
LECATM0.1: received RELEASE_COMPLETE -- --
LECATM0.1:callid0x40518C04
LEC ATM0.1:cause code16
Прямое подключение к LES-серверу (непосредственное управляющее соединение) и обратное подключение от LES-сервера (распределенное управляющее соединение)
На следующем этапе LEC-клиент устанавливает виртуальный канал к LES-серверу (называемый непосредственным управляющим виртуальным каналом). Затем он переходит в состояние ожидания на тот период времени, пока LES-сервер присоединяется к
многоточечному виртуальному каналу между самим LES-сервером и всеми LEC- клиентами (этот виртуальный канал называется распределенным управляющим виртуальным каналом').
LEC-клиент устанавливает соединение с LES-сервером своей эмулируемой локальной сети (двунаправленный виртуальный канал типа “точка-точка”).
LES-сервер поддерживает виртуальный канал (конфигурационное соединение сервера) с LECS-сервером (информация об этом канале в выводе данной команды debug отсутствует, поскольку он не имеет отношения к функционированию LEC-клиента) и выполняет проверку того, разрешено ли конкретному LEC-клиенту войти в состав рассматриваемой эмулируемой локальной сети. Следует отметить, что запрос на присоединение к сети содержит МАС-адрес LEC-клиента, его ATM-адрес и имя эмулируемой локальной сети.
Получив от LECS-сервера соответствующее разрешение, LES-сервер подключает данного LEC-клиента к распределенному управляющему многоточечному однонаправленному виртуальному каналу и по непосредственному управляющему виртуальному каналу подтверждает его включение в состав сети.
LEG АТМ0.1: action A SEND LES SETUP
LEG ATM0.1: sending SETUP
LECATM0.1: callid
LEG ATM0.1:called party
LEG ATM0.1:calling_party
LEG ATM0.1: state LECS_RELEASE
Control Direct (LEG to LES)
0x40518E74
47.00918100000000603E899601.00E01E2EE8Bl.01
47.00918100000000603E899601.00E01E2EE8B0.01
event LEC_SIG_RELEASE_COMP => CTL_DIRECT_CONN
LES address
LEG address
LEG
ATM0.1: received CONNECT
LEG
ATMO.1: callid
0x40518E74
LEG
ATM0.1: vcd
889
LEG АТМ0.1: action A_SEND_JOIN_REQ
LEG АТМ0.1: sending LANE_JOIN_REQ on VCD 889
LEG
ATM0.1:
Status
0
LEG
ATM0.1:
LECID
0
LEG
ATM0.1:
SRC MAC address
00e0.le2e.e8b0
LEG
ATM0.1:
SRC ATM address
47.00918100000000603E899601.00E01E2EE8B0.01
LEG
ATM0.1:
LAN Type 1
LEG
ATM0.1:
Frame size
1
LEG
ATM0.1:
LAN Name elanl
LEG
ATM0.1:
LAN Name size
5
LEG ATM0.1:
state CTL DIRECT CONN event LEG SIG CONNECT => JOIN CTL DIST CONN
LEG ATM0.1: received SETUP Control Distribute (LES to LEG)
LEG ATM0.1:callid0x404DC0A8
LEG ATM0.1:called party47.00918100000000603E899601.00E01E2EE8B0.01
LEG ATM0.1:calling_party47.00918100000000603E899601.00E01E2EE8B1.01
LEG ATMO.l: action A_PROCESS_CTL_DIST_SETUP
LEG ATMO.l: sending CONNECT
LEG ATMO.l:callid0x404DC0A8
LEG ATMO.l:vcd890
LEG ATMO.l: state JOIN_CTL_DIST_CONN event LEC_SIG_SETUP => JOIN
LEG ATMO.l: received CONNECT_ACK
LEG ATMO.l: state JOIN event LEG SIG CONNECT ACK => JOIN
LEG ATMO.l: received LANE_JOIN_RSP on VCD 889
LEG ATMO.l:
Status
0
LEG ATMO.l:
LECID
1
LEG ATMO.l:
SRC MAC address
00e0.le2e.e8b0
LEG ATMO.l:
SRC ATM address
47.00918100000000603E899601.00E01E2EE8B0.01
LEG ATMO.l:
LAN Type 1
LEG ATMO.l:
Frame size
1
LEG ATMO.l:
LAN Name elanl
LEG ATMO.l:
LAN Name size
5
Получение адреса BUS-сервера
На следующем этапе LEC-клиент устанавливает виртуальный канал (называемый виртуальным каналом многоадресатной передачи) к BUS-серверу. Затем он переходит в состояние ожидания на тот период времени, пока BUS-сервер присоединяется к многоточечному виртуальному каналу (называемому виртуальным каналом многоадре- сатного перенаправления) между самим BUS-сервером и всеми LEC-клиентами.
LEC-клиент передает LES-серверу запрос протокола LE_ARP на преобразование широковещательного адреса (состоящего из одних единиц).
LES-сервер возвращает ответ протокола LE_ARP с АТМ-адресом BUS-сервера.
После этого LEC-клиент устанавливает виртуальный канал многоадресатной передачи к BUS-серверу.
BUS-сервер присоединяет LEC-клиента к виртуальному каналу многоадресат- ного перенаправления.
LEG ATMO.l: action A_PROCESS_JOIN_RSP_SEND_REQ
LEG ATMO.l: sending LANE_ARP_REQ on VCD 889
LEG ATMO.l:SRC MAC address00e0.le2e.e8b0
LEG ATMO.l:SRC ATM address47.00918100000000603E899601.00E01E2EE8B0.01LES address
LEG ATMO.l:TARGET MAC addressffff.ffff.ffffBroadcast
address LEG ATMO.l:TARGET ATM address00.000000000000000000000000.000000000000.00NSAP address
is empty
LEG ATMO.l: state JOIN event LEC_CTL_JOIN_RSP_POS => GET_BUS_ADDR
LEG ATMO.l: received LANE ARP RSP on VCD 890
LEG ATMO.l:SRC MAC address00e0.le2e.e8b0
LEG ATMO.l:SRC ATM address47.00918100000000603E899601.00E01E2EE8B0.01
LEG ATMO.l:TARGET MAC addressffff.ffff.ffff
LEG ATMO.l:TARGET ATM address47.00918100000000603E899601.00E01E2EE8B2.01 BUS address
is filled in
LEG ATMO.l: action A_SEND_BUS_SETUP
LEG ATMO.l: predicate PRED_MCAST_SEND_NSAP FALSE
LEG ATMO.l: sending SETUP Mulitcast Send (LEG to BUS)
LEG ATMO.l:callid
LEG ATMO.l:called party
LEG ATMO.l:calling_party
0x40506F14
47.00918100000000603E899601.00E01E2EE8B2.01
47.00918100000000603E899601.00E01E2EE8B0.01
LEG ATMO.l: State GET BUS ADDR
event LEG CTL ARP RSP => MCAST SEND FORWARD CONN
——
——————
LEG ATMO.l: received CONNECT
LEG ATMO.l: callid
0x40506F14
LEG ATMO.l: vcd
893
LEG ATMO.l: action A PROCESS BUS CONNECT
LEG ATMO.l: state MCAST_SEND_FORWARD_CONN event LEC_SIG_CONNECT => MCAST_FORWARD_CONN
LEG ATMO.l: received SETUP Mulitcast Forward (BUS to LEG) ■
LEG ATMO.l:callid0x4051B580
LEG ATMO.l:called party47.00918100000000603E899601.00E01E2EE8B0.01
LEG ATMO.l:callingj>arty47.00918100000000603E899601.00E01E2EE8B2.01
LEG ATMO.l: action A_SEND_BUS_CONNECT
LEG ATMO.l: sending CONNECT
LEG ATMO.l:callid0x4051B580
LEG ATMO.l:vcd894
LEG ATMO.l: state MCAST_FORWARD_CONN event LEC_SIG_SETUP => ACTIVE
LEG ATMO.l: received CONNECT_ACK
LEG ATMO.l: action A_PROCESS_CONNECT_ACK
LEG ATMO.l: state ACTIVE event LEG SIG CONNECT ACK => ACTIVE
Клиент сети LANE находится в рабочем состоянии
После выполнения всех этих этапов LEC-клиент должен находиться в состоянии "up/operational". В этом можно убедиться, выполнив следующую команду:
Cat5000_LANE># show lane client
LE Client ATMO.l ELAN name: elanl Admin: up State: operational
Client ID: 1LEG up for 10 minutes 0 second
Join Attempt: 759
HW Address: 00e0.le2e.e8b0 Type: ethernetMax Frame Size: 1516
VLANID: 100
ATM Address: 47.00918100000000603E899601.00E01E2EE8B0.01
VCD rxFrames txFrames0008891289040893031789490VCD rxFrames txFrames0008891289040893031789490Type ATM Address
VCD rxFrames txFrames
000
88912
89040
8930317
89490
VCD rxFrames txFrames
000
88912
89040
8930317
89490
configure 47.00918100000000603E899601.00E01E2EE8B3.00
direct47.00918100000000603E899601.00E01E2EE8B1.01
distribute47.00918100000000603E899601.00E01E2EE8Bl. 01
send47.00918100000000603E899601.00E01E2EE8B2.01
forward47.00918100000000603E899601.00E01E2EE8B2.01
Описание вывода команды show lane client
Эта команда представляет собой одно из наиболее важных инструментальных средств устранения нарушений в работе сети LANE. На Web-странице ТАС приведена ссылка на интерпретатор вывода Output Interpreter, с помощью которого можно расшифровать вывод этой команды, а здесь описаны наиболее важные поля вывода.
Рассмотрим следующие результаты:
Gambrinus# sh lane client
LE Client ATM2/0/0 ELAN name: default Admin: up State: operational
Client ID: 2LEG up for 15 minutes 39 seconds
ELAN ID: 1
Join Attempt: 691
Last Fail Reason: Control Direct VC being released
HW Address: 0060.4750.8402 Type: ethernetMax Frame Size: 1516
ATM Address: 47.009181000000006047508401.006047508402.00
VCD
0
256
257
258
259
263
rxFrames txFramesTypeATM Address
00configure47.009181000000006047508401.006047508405.00
110direct47.009181000000006047508401.000000000002.01
4760distribute47.009181000000006047508401.000000000002.01
056send47.009181000000006047508401.000000000003.01
20forward47.009181000000006047508401.000000000003.01
118data47.009181000000006047508401.006047508402.00
1. LE Client ATM2/0/0 ELAN name: default Admin: up State: operational
Эта строка показывает, что клиент переведен администратором в рабочее состояние (Admin: up) и исправно функционирует (State: operational). Как было описано выше в данной главе, это — нормальное состояние; клиент находится в исправном и работоспособном состоянии.
Client ID: 2 LEC up for 15 minutes, 39 seconds
В этой строке заслуживает внимание только то, что LEC-клиент находился в рабочем состоянии лишь в течение 15 минут. Необходимо определить, указывает ли это на то, что клиент работает нормально. Может быть, 15 минут назад был выполнен сеанс технического обслуживания?
Join Attempt: 691
Хотя эта информация о количестве попыток подключения настораживает, она не обязательно означает, что данный LEC-клиент переходил в нерабочее состояние 691 раз. Возможно, что LECS- или LES-сервер оставался недоступным в течение продолжительного времени.
Last Fail Reason: Control Direct VC being released
Это важное поле показывает, что последней причиной отказа, из-за которой LEC-клиент не мог перейти в состояние "up/operational", явилось то, что он не смог подключиться к LES-серверу.
ATM Address: 47.009181000000006047508401.006047508402.0
Эта строка представляет интерес только в том случае, если проверяется вывод команды sh lane client на других LEC-клиентах для определения того, что вторым участником непосредственного соединения передачи данных является именно эта станция.
0 0 0 configure 47.009181000000006047508401.006047508405.00
Данная строка предоставляет подробные сведения о соединении с LECS-сервером; рассматриваемый виртуальный канал называется непосредственным конфигурационным виртуальным каналом, как показывает поле типа Туре. Значение VCD равно 0, поскольку это соединение разорвано согласно спецификации.
7.256 1 10 direct 47.009181000000006047508401.000000000002.01
Данная строка предоставляет подробные сведения о соединении с LES- сервером; рассматриваемый виртуальный канал называется непосредственным управляющим виртуальным каналом-, это и указано в поле типа Туре.
257 476 0 distribute 47.009181000000006047508401.000000000002.01
Данная строка предоставляет подробные сведения о многоточечном соединении между LES-сервером и всеми LEC-клиентами. Этот виртуальный канал называется распределенным управляющим виртуальным каналом. Очевидно, что в этом распределенном управляющем виртуальном канале применяется такой же адрес LES-сервера, как и в непосредственном управляющем виртуальном канале, но так и должно быть.
258 0 56 send 47.009181000000006047508401.000000000003.01
Данная строка предоставляет подробные сведения о соединении с BUS- сервером; рассматриваемый виртуальный канал называется виртуальным каналом многоадресатной передачи; это и указано в поле типа Туре.
10.259 2 0 forward 47.009181000000006047508401.000000000003.01
Данная строка предоставляет подробные сведения о многоточечном соединении между BUS-сервером и всеми LEC-клиентами. Этот виртуальный канал называется виртуальным каналом многоадресатного перенаправления. Очевидно, что в этом распределенном управляющем виртуальном канале применяется такой же адрес BUS-сервера, как и в виртуальном канале многоадресатной передачи, но так и должно быть.
263 1 18 data 47.009181000000006047508401.006047508402.00
Остальные строки содержат подробные сведения о каждом непосредственном соединении передачи данных по виртуальному каналу (дополнительные сведения приведены в разделе “Процесс применения протокола LE_ARP”).
Процесс применения протокола LE_ARP
Протокол LE ARP представляет собой один из наиболее важных протоколов в технологии LANE. Если LEC-клиент должен перенаправить одноадресатный фрейм (иными словами, фрейм с МАС-адресом получателя, представляющим собой действительный МАС-адрес), протокол LE_ARP не должен перенаправлять этот фрейм BUS-серверу.
В действительности будет выполнена попытка определить соответствие между этим МАС-адресом получателя и АТМ-адресом LEC-клиента, с которым необходимо связаться, чтобы достичь определенной станции. Такой LEC-клиент может представлять собой модуль LANE, маршрутизатор или непосредственно подключенную станцию. Такой процесс носит название “применение протокола LE_ARP”. Ожидая завершения этого процесса, LEC-клиент, передающий фреймы, будет направлять этот трафик BUS-серверу по типу трафика с неизвестным адресом.
Рассмотрим этот процесс более подробно. Допустим, что имеется следующая топология:
Станция с IP-адресом—(соединение Ethernet)—Catalyst(модуль ATM LANE)
10.200.10.61IslOlO
К тому же, проверка показывает, что клиент LANE находится в исправном и работоспособном состоянии:
Gambrinus# sh lane client
LE Client ATM2/0/0 ELAN name: default Admin: up State: operational
Client ID: 2LEG up for 12 minutes 26 seconds
ELAN ID: 1
Join Attempt: 10
Last Fail Reason: Control Direct VC being released
HW Address: 0060.4750.8402 Type: ethernetMax Frame Size: 1516
ATM Address: 47.009181000000006047508401.006047508402.00
VCD
rxFrames
txFrames
Type
ATM Address
0
0
0
configure
47.009181000000006047508401.006047508405.00
94
15
109
direct
47.009181000000006047508401.000000000002.01
95
1015
0
distribute
47.009181000000006047508401.000000000002.01
96
0
202
send
47.009181000000006047508401.000000000003.01
97
105
0
forward
47.009181000000006047508401.000000000003.01
Допустим, что нужно обратиться к станции с адресом 10.200.10.62:
Gambrinus# ping 10.200.10.62
С точки зрения пользователя эта команда будет выполнена успешно, без каких- либо отклонений:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.200.10.62, timeout is 2 seconds:
11111
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
Разрешив применение команды debug lane client packet, можно рассмотреть данный процесс более подробно. Это означает, что LEC-клиент передает запрос LE_ARP LES-серверу и ожидает ответа, в котором будет указан предназначенный для него АТМ-адрес.
♦Mar
22
02:32:46.499: LEG
ATM2/0/0:
sending LANE ARP REQ on VCD 94
♦Mar
22
02:32:46.499: LEG
ATM2/0/0:
LECID
2
♦Mar
22
02:32:46.499: LEG
ATM2/0/0:
SRC MAC address
0060.4750.8402
♦Mar
22
02:32:46.499: LEG
ATM2/0/0:
SRC ATM address
47.0091810000000060470
♦Mar
22
02:32:46.499: LEG
ATM2/0/0:
TARGET
MAC address
00e0.b012.17ff
♦Mar
22
02:32:46.499: LEG
ATM2/0/0:
TARGET
ATM address
00.0000000000000000000
♦Mar
22
02:32:46.499: LEG
ATM2/0/0:
Flags
0x0
♦Mar
22
02:32:46.499: LEG
ATM2/0/0:
num of
TLVs
0
♦Mar
22
02:32:46.515: LEG
ATM2/0/0:
received
LANE_ARP_RSP
on VCD 95
♦Mar
22
02:32:46.515: LEG
ATM2/0/0:
LECID
2
♦Mar
22
02:32:46.515: LEG
ATM2/0/0:
SRC MAC address
00e0.b012.17ff
♦Mar
22
02:32:46.515: LEG
ATM2/0/0:
SRC ATM address
47.0091810000000060471
♦Mar
22
02:32:46.515: LEG
ATM2/0/0:
TARGET MAC address
0060.4750.8402
♦Mar
22
02:32:46.515: LEG
ATM2/0/0:
TARGET ATM address
47.0091810000000060470
♦Mar
22
02:32:46.515: LEG
ATM2/0/0:
Flags
0x0
♦Mar
22
02:32:46.515: LEG
ATM2/0/0:
num of
TLVs
0
После получения ответа LEC-клиент устанавливает соединение по виртуальному каналу с использованием этого ATM-адреса. Такое соединение называется непосредственным соединением передачи данных по виртуальному каналу. Любые фреймы, которые должны быть отправлены по этому МАС-адресу назначения, будут перенаправляться в данное соединение по виртуальному каналу.
Для обеспечения того, чтобы в пути доставки через BUS-сервер не осталось ни одного фрейма после перехода в активное состояние этого непосредственного соединения передачи данных по виртуальному каналу, применяется так называемый механизм сброса FLUSH. Команда debug lane client packet позволяет также получить дополнительные подробности о процессе FLUSH.
♦Маг 22 02:32:46.627: LEG АТМ2/0/0: sending LANE_FLUSH_REQ on VCD 96
♦Mar 22 02:32:46.633: LEG ATM2/0/0: received LANE_FLUSH_RSP on VCD 95
Результаты выполнения процесса LE_ARP сохраняются в памяти и могут быть проверены:
Gambrinusi sh lane le-arp
Active le-arp entries: 1
Hardware Addr ATM AddressVCD Interface
00e0.b012.17ff 47.009181000000006047508401.000000000001.01 100 ATM2/0/0
Проверка таблицы ARP на станции с IP-адресом отправителя показывает, что применяется правильный МАС-адрес.
Gambrinustsh агр
Protocol AddressAge (min) Hardware Addr Type Interface
Internet 10.200.10.622000e0.b012.17ff ARPA ATM2/0/0
И что самое интересное, изменяется вывод команды show lane client. Он показывает, что установилось новое соединение по виртуальному каналу и что трафик теперь передается по нему. Соединение будет оставаться в рабочем состоянии до тех пор, пока через него будет проходить трафик. По умолчанию тайм-аут составляет 300 секунд, и если виртуальный канал простаивает в течение этого промежутка времени, регистрируется истечение тайм-аута.
Gambrinus# sh lane client
LE Client ATM2/0/0 ELAN name: default Admin: up State: operational
Client ID: 2LEG up for 13 minutes 15 seconds
ELAN ID: 1
Join Attempt: 10
Last Fail Reason: Control Direct VC being released
HW Address: 0060.4750.8402 Type: ethernetMax Frame Size: 1516
ATM Address: 47.009181000000006047508401.006047508402.00
VCD
0
rxFrames
0
txFrames
0
Type configure
ATM Address
47.009181000000006047508401.006047508405.00
94
15
115
direct
47.009181000000006047508401.000000000002.01
95
1384
0
distribute
47.009181000000006047508401.000000000002.01
96
0
232
send
47.009181000000006047508401.000000000003.01
97
112
0
forward
47.009181000000006047508401.000000000003.01
99
1
2
data
47.009181000000006047508401.000000000001.01
Дополнительные команды
Для устранения нарушений в работе средств LANE наиболее часто применяются следующие команды show:
show lane;
show lane client;
show lane server;
show lane config;
show lane default;
show atm ilmi-status.
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco
Прежде чем обратиться в центр Cisco ТАС, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе своей системы.
Кроме того, выполните следующие действия и оформите полученные результаты в виде документов.
Если проблема состоит в том, что клиентское приложение LANE Client не может перейти в состояние "up/operational" (т.е. клиентское приложение LANE Client не функционирует или не может войти в состав эмулируемой локальной сети), определите, какая служба (LES-, LECS- или BUS-сервер) препятствует запуску LEC-клиента.
Подготовьте схему сети, на которой наглядно показано, где находятся LECS-, LES- и BUS-сервер.
Вызовите на выполнение команду show lane на каждом важном устройстве и сохраните ее результаты. Таковыми считаются все устройства, на которых развернуты активные компоненты LECS-, LES-, BUS-сервера и обнаруживаются проблемы при запуске клиентского приложения LANE Client.
Если для доступа к удаленному узлу применяется VP-туннель, соберите все сведения, которые относятся к соглашению о трафике для этого VP-туннеля.
Дополнительные источники информации
Кларк К., Гамильтон К., Принципы коммутации в локальных сетях Cisco.— М. : Издательский дом “Вильямс”, 2003 г.
www.cisco.com/tac (необходимая информация находится в разделе ATM на странице Technology Home Page).
www.atmforum.com/ (на этом узле приведено много стандартов, которые могут быть загружены бесплатно).
www.techfest.com/networking.
www.protocols.сот/.
cell-relay.indiana.edu/.
news:comp.dcom/cell-relay (архив этой группы новостей находится по адресу http://cell-relay.indiana.edu/).
ГлаваГлава2222
Глава
Глава
22
22
^Устранение нарушений ^ работе постоянных виртуальных каналов ATM 4 среде распределенной сети
В настоящей главе;рассматриваются способы устранения нарушений в работе сети ATM, возникающихпри передаче фреймов уровня 2 и пакетов уровня 3 по опорным •сетям.распределенных седей. Здесь представлены следующие темы.
„ t • Способы разбиения фреймов или пакетов на ячейки ATM.
%-' • Наиболее важные команды show и способы их интерпретации.
^* Способы $6наруЖвйия и устранения нарушений в работе средств ограничения '<, и упорядочения трафика.
Введение
г‘' Технология ATM (Asynchronous Transfer Mode — режим асинхронной передачи) Стандартизирована организацией ITU-T в начале 1990-х годов. В соответст
вующих стандартах описана технология сетевого транспорта, предусматривающая первачу ин^зрмакгйй- в виде небольших фрагментов данных постоянной длины, назйваемыХ* ячейкДгЙ?
В сетевой среде. ATM необходимо четко различать устройства, которые обеспечивают работу приложений и называются оконечными системами (ES — End System), и устройства, в задачу которых входит только обработка ячеек. В настоящей главе устройства, обрабатывающие ячейки, именуются промежуточными системами (IS — Intermediate;System), или ATM-коммутаторами. В качестве примеров оконечных систем можно назвать маршрутизаторы или модули LANE. Примерами промежуточных систем являются устройства IslOlO, 8540MSR и ВРХ. Поэтому сеть ATM можно схематически представить, как показано на рис. 22.1.
ES1 IS1 IS 2 ES2
Рис. 22.1. Схема сети А ТМ
Технология ATM обеспечивает выполнение многих важных функций, но одной из наиболее важных является функция сегментации и повторной сборки данных различного типа. Сети ATM могут передавать видео-, аудиоинформацию и другие данные. Они позволяют резервировать и гарантированно предоставлять пользователям каналы передачи данных с определенными характеристиками, которые известны под общим названием характеристик качества обслуживания (QoS — Quality Of Service). Поскольку соответствующие стандарты позволяют сегментировать (разбивать на ячейки) информацию любых типов, технология ATM представляет собой очень гибкое инструментальное средство. Поэтому она может применяться во многих сетевых средах. В настоящей главе рассматриваются следующие две основные области применения этой технологии.
Коммутируемая среда локальной сети, в которой наиболее часто применяются стандарты LANE. Как правило, в этой динамической среде показатели качества обслуживания не имеют большого значения. (Соединения ATM устанавливаются и разрываются по требованию.)'
Среда распределенной локальной сети, в развитии которой заинтересованы предприятия следующих двух типов.
Телефонные компании, которые обычно предлагают свои услуги с очень точным соблюдением показателей качества обслуживания в статической среде. Такая сеть ATM состоит из ATM-коммутаторов. Телефонные компании, предоставляющие доступ к службам ATM, в настоящей главе именуются провайдерами служб ATM.
Предприятия, которые получают доступ к службам ATM в сети провайдера служб ATM.
В настоящей главе рассматриваются только соединения ATM последнего типа в сетевой среде предприятия. В подобной среде оконечные системы на 99% состоят из маршрутизаторов. Поэтому во всей этой главе для обозначения оконечной системы будет применяться только термин маршрутизатор. Такие маршрутизаторы обмениваются между собой пакетами (см. следующее примечание). В качестве эталонного протокола применяется IP, поэтому все приведенные здесь сведения действительны и для других протоколов уровня 3, таких как IPX и ATALK. С точки зрения пользователя сама сеть выглядит таким образом, как показано на рис. 22.2.
ГоетеваяЛ
Маршрутизатор 14Маршрутизатор 2
Рис. 22.2. Схема сети с точки зрения пользователя
Примечание
Поскольку технология ATM представляет собой гибкое инструментальное средство, она позволяет сегментировать в виде ячеек данные практически любого типа. В настоящей главе уже упоминались пакеты и фреймы: блоки данных уровней 3 и 2. Безусловно, здесь можно было применять термин протокольный блок данных, который позволил бы излагать материал более обобщенно, не упоминая конкретный уровень (по такому же принципу, как и в спецификации OSI). Но в целях упрощения здесь применяется только термин пакет, а в соответствующих обстоятельствах под этим подразумевается фрейм.
Функционирование сети ATM должно регламентироваться соглашением о трафике между пользователем и провайдером служб, в котором обусловлена необходимость соблюдения определенных показателей качества обслуживания в процессе функционирования всего сетевого оборудования. На первый взгляд это требование кажется довольно простым, если рассматриваются только два взаимодействующих устройства (как на рис. 22.2), и пользователь просто не принимает во внимание все нюансы внутреннего функционирования сетевой среды провайдера ATM. К сожалению, пользователь не может полностью игнорировать возникающие в этой среде проблемы лишь потому, что не имеет полного представления о том, как действует оборудование провайдера ATM.
Общее описание процесса сегментации и повторной сборки фреймов AAL5
Для преобразования (адаптации) пользовательской информации (данных, аудио-, видеоинформации и т.д.) в формат, который позволяет в дальнейшем легко распределять эту информацию по ячейкам ATM, применяется протокол AAL (ATM Adaptation Layer — уровень адаптации ATM). Схема функционирования этого протокола уровня 5 (AAL5 —• ATM Adaptation Layer 5) приведена на рис. 22.3.
В маршрутизаторе получателя происходит обратный процесс. В этом маршрутизаторе можно легко определить, какая ячейка находится в конце пакета AAL5, поскольку в ней значение некоторого специального бита установлено равным 1.
Весь этот процесс обычно реализуется на аппаратном уровне, поэтому осуществляется очень эффективно. А в настоящей главе рассматриваются следующие две основные проблемы, которые могут возникнуть в ходе этого процесса.
Искажение содержимого одной или нескольких ячеек, поступивших к получателю, которое произошло либо в передающем устройстве, либо в одном из устройств сети ATM. Единственным полем в ячейке, которое обеспечивает определенную степень контроля по CRC, является поле контрольной суммы заголовка (НЕС — HEader Checksum). Как подразумевается самим его именем, это поле обеспечивает проверку только заголовка ячейки.
Одна или несколько ячеек могут быть отброшены в сети провайдера.
Пользовательские /
^цанные
Управляющая информация
Длина области
CRC-32
(CPInUU)
данных
AAL5 CPCS - фрейм PDU = n x 48 байтов
0-65535 байтов
Трейлер AAL5 CPCS PDUТрейлер AAL5 CPCS PDUОбласть данных SAR PDU = 48 байтовОбласть данных SAR PDU = 48 байтовОбласть данных ячейки AAL5 SAR PDU 1
Трейлер AAL5 CPCS PDU
Трейлер AAL5 CPCS PDU
Область данных SAR PDU = 48 байтов
Область данных SAR PDU = 48 байтов
ФреймФреймПодуровеньсовмещенияПодуровеньсовмещенияПодуровеньSARПодуровеньSARОбласть данных CS PDUОбласть данных CS PDUОбласть д анныхОбласть данныхSARPDUSARPDUОбласть д анныхОбласть данныхSARPDUSARPDUОбласть данныхSARPDUОбласть данныхSARPDUОбласть данныхSARPDUОбласть данныхSARPDUБолее высокиеуровни
Фрейм
Фрейм
Подуровеньсовмещения
Подуровеньсовмещения
ПодуровеньSAR
ПодуровеньSAR
Область данных CS PDU
Область данных CS PDU
Область д анныхОбласть данных
SARPDUSARPDU
Область д анныхОбласть данных
SARPDUSARPDU
Область данныхSARPDU
Область данныхSARPDU
Область данныхSARPDU
Область данныхSARPDU
] № I] № IУ|д™НЬ ВИ Область данных! ИН I №
] № I
] № I
Ячейка ATM
Рис. 22.3. Схема функционирования протокола AAL5
Ниже описано, какое влияние могут оказать эти две проблемы на маршрутизатор получателя, и показано, каким образом их можно обнаружить.
Если одна ячейка искажена, то количество переданных и принятых ячеек остается неизменным. После его сборки фрейм CPCS-PDU (Common Part Convergence Sublayer Protocol Data Unit — протокольная единица обмена подуровня сходимости общей части) имеет правильный размер. Проверка, выполненная маршрутизатором, показывает, что значение в поле длины соответствует действительности. Но поскольку одна ячейка искажена, то фактически искажен и весь фрейм. Поэтому значение в поле CRC во фрейме CPCS-PDU по спецификации AAL5 будет отличаться от значения в первоначально отправленном фрейме.
Если одна из ячеек не получена маршрутизатором получателя, то различия будут обнаружены и в поле размера, и в поле CRC после их проверки во фрейме CPCS-PDU.
Примечание
В таких случаях анализ вывода команды show interface показывает, что количество ошибок CRC равно количеству ошибок во входных данных. Но в некоторых оконечных системах, таких как модули LANE типа Catalyst 5000, регистрируются лишь ошибки во входных данных, поэтому рекомендуется рассматривать в выводе этой команды только количество ошибок во входных данных. Как правило, если в маршрутизаторе не эксплуатируется новейшая версия программного обеспечения, то рекомендуется также анализировать вывод команды sh controller, поскольку он позволяет получить больший объем статистических данных о функционировании самой платы ATM.
Таким образом, при возникновении любого нарушения в работе на устройстве получателя обнаруживается изменение значения в поле CRC. Администратор сети предприятия может обнаружить это, проверяя статистические данные о работе интерфейсов маршрутизаторов. При обнаружении каждой ошибки CRC значение в поле ошибок во входных данных увеличивается на 1 (см. предыдущее примечание). Ниже приведен вывод команды show interface atm [module/port], который иллюстрирует рассматриваемое явление.
Medina# sh int atm 3/0
ATM3/0 is up, line protocol is up
Hardware is ENHANCED ATM PA
MTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usee,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM, loopback not set
Keepalive not supported
Encapsulation(s): AAL5
4096 maximum active VCs, 2 current VCCs
VC idle disconnect time: 300 seconds Signalling vc = 1, vpi = 0, vci = 5
UNI Version =4.0, Link Side = user 0 carrier transitions
Last input 00:00:07, output 00:00:07, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: Per VC Queueing
minute input rate 0 bits/sec, 0 packets/sec
minute output rate 0 bits/sec, 0 packets/sec
104 packets input, 2704 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
32 input errors, 32 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
106 packets output, 2353 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 output buffer failures, 0 output buffers swapped out
Если настройка конфигурации маршрутизатора выполнена для поддержки нескольких постоянных виртуальных каналов, то изучение данных в поле, содержащем общие статистические данные о работе интерфейса, не позволяет получить полное представление о происходящем, поскольку поле ошибок во входных данных показывает итоговые данные о трафике, проходящем через несколько постоянных виртуальных каналов. При таких обстоятельствах рекомендуется использовать данные, предоставляемые командой sh atm pvc vpi/vci.
Medina# sh atm pvc 0/36
ATM3/0.1: VCD: 4, VPI: 0, VCI: 36
VBR-NRT, PeakRate: 2000, Average Rate: 1000, Burst Cells: 32
AAL5-LLC/SNAP, etype:0x0, Flags: 0x20, VCmode: 0x0
0AM frequency: 0 second(s), OAM retry frequency: 1 second(s), OAM retry frequen)
0AM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Disabled
0AM VC state: Not Managed
ILMI VC state: Not Managed
InARP frequency: 15 minutes(s)
Transmit priority 2
InPkts: 24972, OutPkts: 25032, InBytes: 6778670, OutBytes: 6751812
InPRoc: 24972, OutPRoc: 25219, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
CAM cells received: 0
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0 0AM cells sent: 0
F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutRDI: 0
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0
0AM cell drops: 0
Status: UP
В выводе этой команды (см. следующее примечание) поле CrcErrors показывает количество ошибок CRC во фреймах CPCS-PDU. И эта, и приведенная выше команда была введена в одном и том же маршрутизаторе; поскольку в статистических данных для постоянного виртуального канала PVC 0/36 не было информации о количестве ошибок CrcErrors, то можно предположить, что ошибки во входных данных, представленные в выводе команды sh int, возникли в другом постоянном виртуальном канале.
Примечание
Состав полей в выводе команды sh atm pvc зависит от состава функциональных средств платы и версии кода. Приведенные выше данные получены в устройстве РА- АЗ с версией кода IOS 12.1.
Следует также отметить, что одна ошибка во входных данных не всегда равнозначна потере одного пакета. Ячейка, отброшенная в сети провайдера ATM, может оказаться последней ячейкой во фрейме, в которой значение специального бита установлено равным I. Единственный способ определения границ между фреймами в маршрутизаторе получателя состоит в проверке этого бита. Поэтому в случае потери такой ячейки в маршрутизаторе получателя во время повторной сборки все ячейки будут соединяться до тех пор, пока не будет обнаружена ячейка со специальным битом, равным I. Таким образом, если в сети отбрасывается последняя ячейка фрейма, то происходит потеря двух фреймов CPCS-PDU, но регистрируется только одна ошибка CRC и одна ошибка длины.
Основные сведения об ограничении и упорядочении трафика
В настоящей главе используются еще два важных термина: ограничение и упорядочение трафика. Ограничением трафика называются действия, выполняемые отправителем трафика ATM. Упорядочением трафика называются действия, выполняемые ATM-коммутаторами, обычно в оборудовании провайдера.
Ограничение трафика заключается в том, что создается поток ячеек, соответствующий конкретному соглашению о трафике. Этот процесс проиллюстрирован на рис. 22.4.
Происходит ограничение трафика
Рис. 22.4. Ограничение трафика: создание потока ячеек, соответствующего конкретному соглашению о трафике
Упорядочение трафика представляет собой процесс проверки потока ячеек на соответствие определенному соглашению о трафике. Этот процесс проиллюстрирован на рис. 22.5.
Рис. 22.5. Упорядочение трафика: проверка потоке ячеек на соответствие определенному соглашению о трафике
Как показано на рис. 22.4 и 22.5, нет никаких оснований предполагать, что применяемые способы ограничения и упорядочения трафика всегда относятся к одному и тому же соглашению и основаны на использовании одинакового алгоритма. Соблюдение разных способов упорядочения или ограничения часто приводит к тому, что ячейки отбрасываются тем устройством, на котором выполняется проверка их соответствия соглашению о трафике. Такая ситуация может возникнуть и в том случае, если применяются согласованные способы ограничения и упорядочения; т.е. происходит отбрасывание ячеек упорядочивающим устройством. Обычно это происходит при неправильном ограничении или некорректном упорядочении трафика.
Основные сведения о методе ограничения VBR-NRT1
В настоящей главе приведена только вводная информация об ограничении трафика. В случае необходимости с дополнительными сведениями можно ознакомиться в спецификации Traffic Management, которая находится на Web-узле организации ATM Forum.
В сети ATM ограничение трафика осуществляется путем вставки одинаковых временных интервалов между ячейками. Например, если соединение OC-3c/STM-1 имеет пропу-
/ VBR-NRT (Variable Bit Rate Nonreoi Time — класс переменной битовой скорости вне режима реального времени).
скную способность 155 Мбит/с, то для перенаправления ячеек ATM используется только около 149 Мбит/с. (В сети SONET/SDH подобные издержки составляют примерно 3%.) В результате максимальная скорость передачи в этом соединении составляет 353,208 ячейки в секунду (таким образом, в области данных фреймов ОС-Зс/STM-l может передаваться 353,208x53x8 бит/с). Если пользователь запрашивает соединение с пропускной способностью 74,5 Мбит/с (которая составляет половину пропускной способности канала), то между каждой парой ячеек будут вставлены одинаковые интервалы времени, составляющие 2,83 мкс. Интервал времени, равный 2,83 мкс, необходим для передачи одной ячейки через соединение OC-3c/STM-l (1/353,208 с). Поскольку затребована пропускная способность, составляющая половину пропускной способности канала, то через такое соединение можно передать одну ячейку, перейти в состояние ожидание на время, равное продолжительности ее передачи, а затем снова приступить к передаче.
Теперь, после описания основного принципа передачи, кратко рассмотрим наиболее широко применяемый способ ограничения трафика с использованием переменной битовой скорости (VBR — Variable Bit-Rate), проиллюстрированный на рис. 22.6.
§1MBS
Рис. 22.6. Ограничение трафика с применением переменной битовой скорости
Ограничение трафика VBR является эффективным способом организации обмена данными в сети, отличительной особенностью которой являются резкие изменения интенсивности трафика. При использовании этого способа для определения характеристик трафика применяются такие параметры, как пиковая скорость передачи ячеек (PCR — Peak Cell Rate), стабильная скорость передачи ячеек (SCR — Sustainable Cell Rate) и максимальный размер всплеска (MBS — Maximum Burst Size). В соглашении о трафике должно быть указано, что сеть ATM гарантирует передачу ячеек с соблюдением параметров VBR. Параметр MBS устанавливает количество ячеек, которые могут быть переданы с превышением параметра SCR, а максимальная скорость передачи ячеек регламентируется параметром PCR
Ниже приведены определения трех рассматриваемых параметров соглашения о трафике.
PCR. Максимальная скорость, с которой отправитель может передавать ячейки.
SCR. Согласованная средняя скорость передачи ячеек в течение продолжительного времени.
MBS. Максимальное количество ячеек, которые могут быть переданы с превышением скорости SCR, т.е. на скорости PCR
Установление соответствия между адресом получателя и постоянным виртуальным каналом
Одной из основных причин нарушений в работе сети ATM является неправильная настройка конфигурации преобразования ATM-адресов. По существу, после настройки конфигурации самого постоянного виртуального канала необходимо ввести в маршрутизатор информацию о том, какой постоянный виртуальный канал должен применяться для передачи данных по определенному адресу получателя. Для обеспечения правильного преобразования адресов могут применяться следующие три способа.
Если постоянный виртуальный канал помещен в подынтерфейс “точка-точка”, маршрутизатор будет функционировать на основе предположения, что это — единственный постоянный виртуальный канал “точка-точка”, входящий в конфигурацию подынтерфейса. Поэтому в данный виртуальный канал будут перенаправляться все IP-пакеты с IP-адресом получателя, находящимся в той же подсети. Такой способ настройки конфигурации преобразования является наиболее простым, и поэтому рекомендуется использовать именно его.
Если постоянный виртуальный канал помещен в многоточечный подынтерфейс или в главный интерфейс, то может потребоваться применить статическое преобразование. Пример такой конфигурации приведен ниже, в разделе “Командный режим".
Для автоматического создания таблицы преобразования может применяться обратный протокол ARP. Для ознакомления с рекомендациями по настройке конфигурации обратитесь к соответствующей документации.
Основные задачи устранения нарушений связи
Пользователь часто сталкивается с такой проблемой, что часть передаваемой им информации на пути между двумя маршрутизаторами теряется. При этом чаще всего возникают следующие признаки неисправности.
Соединения TCP работают медленно, поскольку в сетевой среде ATM отбрасываются ячейки. В связи с этим отбрасываются IP-пакеты и часто происходит повторная передача. Само программное обеспечение TCP функционирует с учетом предположения, что потеря IP-пакетов возникает из-за затора, поэтому предпринимается попытка уменьшить размер передающего окна, что приводит к весьма значительному замедлению работы соединения TCP. Безусловно, такая ситуация отражается на работе всех протоколов, основанных на протоколе TCP, включая Telnet и FTP.
Передача крупных IP-пакетов, как правило, оканчивается неудачей, а небольшие пакеты проходят по сети ATM без каких-либо проблем. Такая ситуация также возникает в связи с уничтожением в сети ячеек.
Рассмотрим второй признак неисправности, который позволяет лучше проанализировать рассматриваемую проблему. Предположим, что из каждых 100 ячеек,
последовательно передаваемых маршрутизатором отправителя, сетевая среда ATM отбрасывает последнюю, поскольку такая необходимость возникает в процессе упорядочения. Это означает, что если в пакете эхо-тестирования область данных составляет 100 байтов, то для его передачи потребуется 3 ячейки ATM (так как для размещения этого запроса эхо-тестирования ICMP потребуется 3x48 байтов). На практике это означает, что первые 33 пакета эхо-тестирования будут переданы успешно (а точнее, в соответствии с соглашением с провайдером о трафике будут успешно переданы первые 99 ячеек), но передача 34-го пакета окончится неудачей, поскольку одна из его ячеек будет отброшена.
А теперь предположим, что применяются те же исходные данные, но вместо небольших запросов эхо-тестирования ICMP используются пакеты размером 1500 байтов. В этом случае для передачи каждого такого пакета потребуется 32 ячейки (32x48 = 1536 байтов, где 32 — наименьшее кратное 48, превышающее размер пакета). Если сеть отбрасывает одну ячейку из 100, то в ней будет отброшен примерно один пакет из трех или четырех. Поэтому увеличение размеров пакета — это наиболее простой и эффективный способ проверить, не является ли нарушение в работе следствием применения упорядочения.
На практике можно формировать крупные пакеты эхо-тестирования непосредственно в самом маршрутизаторе:
Medina# ping
Protocol [ip]:
Target IP address: 10.2.1.2
Repeat count [5]: 100
Datagram size [100]: 1500
Timeout in seconds [2]: 2
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 1500-byte ICMP Echos to 10.2.1.2, timeout is 2 seconds:
!!!.!!.!!!.! I.!!!.!!. И !.!!.!!!.!!.!!!.!!. I! I.! I. I!!.!!. 111.1!.!!!.!!. I!!.!!.!!!. I!.!!
!.!!.!!!.! I.!
Success rate is 72 percent (72/100)
Если проблема действительно связана с применением упорядочения, то выполнение той же проверки с использованием более крупных пакетов приведет к получению совершенно иного результата:
Medina# ping
Protocol [ip]:
Target IP address: 10.2.1.2
Repeat count [5]: 100
Datagram size [100]: 3000
Timeout in seconds [2]: 2
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 3000-byte ICMP Echos to 10.2.1.2, timeout is 2 seconds:
iii iii ii ii i iii i i i i i i i i i I,,.!..1.1.!. iii iii I,
Illi IIlli III
Illi I
Illi I
I
I
Success rate is 42 percent (42/100)
Если после выполнения указанных выше проверок можно сделать вывод, что причиной нарушения в работе является применение средств упорядочения, то следует немедленно обратиться к провайдеру ATM и получить ответы на следующие вопросы.
Действительно ли в сети провайдера происходит уничтожение ячеек? Провайдер должен быть в состоянии ответить на этот вопрос.
Если ответ на предыдущий вопрос был положительным, то в чем именно состоит причина такой ситуации? Обычно ответ заключается в том, что применяется упорядочение, но иногда причиной является просто возникновение заторов в сети.
Если причиной является применение упорядочения, то каковы параметры трафика? Соответствуют ли они параметрам настройки маршрутизатора?
Если и в маршрутизаторе, и в оборудовании провайдера применяются одинаковые параметры трафика, то в этом и нужно искать действительную причину проблемы. Иными словами, происходит либо неправильное ограничение трафика маршрутизатором, либо в оборудовании провайдера не совсем точно соблюдаются правила упорядочения. Если возникает такая ситуация, обратитесь к документации платы ATM, чтобы ознакомиться с тем, какие известные лимиты накладывают характеристики этой платы, а также узнать обо всех известных дефектах в ее программном обеспечении. Следует также учитывать, что не существует двух одинаковых реализаций алгоритмов ограничения трафика, которые приводили бы к созданию одного и того же результирующего трафика; всегда приходится мириться с небольшими отклонениями, но такие отклонения должны приводить лишь к пренебрежимо малому объему потерь трафика.
На рынке имеются некоторые анализаторы трафика, позволяющие проверить, соответствует ли трафик указанному набору параметров трафика. К числу устройств такого типа, получивших широкое признание, относятся устройства, выпускаемые компаниями GN Nettest и HP. Эти устройства позволяют определить, насколько точно осуществляется ограничение трафика, поступающего от маршрутизатора.
Если обнаружено, что маршрутизатор Cisco не совсем точно выполняет ограничение трафика, но при этом в документации не будут найдены какие-либо указания на наличие дефектов программного обеспечения или лимитов платы, рекомендуется сообщить об этом в центр ТАС.
Устранение нарушений в работе постоянного виртуального канала, характеризующихся полным отсутствием связи
В предыдущем разделе в основном рассматривались нарушения в работе, характеризующиеся потерей части пакетов, а здесь рассматриваются проблемы, при которых связь полностью отсутствует (табл. 22.1).
ПроблемаПроблема.1. Полное отсутствие связи между двумя маршрутизаторами, К подключенными к сети ATM#
Проблема
Проблема
Рашаниа
Постоянный виртуальный канал разорван в сетевой среде провайдераПостоянный виртуальный канал разорван в сетевой среде провайдераОдин из интерфейсов находится в состоянии down/downОдин из интерфейсов находится в состоянии down/downЭта проблема возникает наиболее часто. Если неисправность возникла' внутри сетевой среды провайдера ATM, то от внешнего оборудования провайдера может по-прежнему поступать качественный сигнал. В результате этого интерфейс маршрутизатора будет по-прежнему находиться в режиме up/up. При этом все ячейки, передаваемые маршрутизатором, будут приниматься оборудованием провайдера, но так и не достигнут устройства получателя.
Постоянный виртуальный канал разорван в сетевой среде провайдера
Постоянный виртуальный канал разорван в сетевой среде провайдера
Один из интерфейсов находится в состоянии down/down
Один из интерфейсов находится в состоянии down/down
Обычно о возникновении такой ситуации можно сразу же узнать, обратившись к провайдеру. Но поскольку при этом интерфейс не переходит в нерабочее состояние, маршрут уровня 3 не удаляется из таблицы маршрутизации и поэтому отсутствует возможность использовать альтернативные или резервные маршруты. Наилучшее решение в этой среде состоит в том, чтобы разрешить применение средств управления ОАМ (Operation, Administration, Maintenance — эксплуатация, администрирование, обслуживание) для автоматизации процесса восстановления связи. Обратитесь к руководству по настройке конфигурации распределенной сети, которое находится на узле ССО.
Чтобы проверить, исправна ли плата ATM, можно использовать петлю обратной связи. Обратитесь к разделу с описанием решения следующей проблемы в данной таблице
Шаг 1. Определите интерфейс ATM, который находится в состоянии down/down. Убедитесь в том, что он не переведен в нерабочее состояние администратором (т.е. в том, что этот интерфейс или по- дынтерфейс не был закрыт).
Шаг 2. Проверьте, правильно ли выполнена настройка фреймирования и перемешивания.
Применяемый способ фреймирования, который должен быть согласован с провайдером, можно проверить с помошью команды sh atm int atm. Для настройки конфигурации способа фреймирования вызовите на выполнение команду atm framing ххх в режиме конфигурации интерфейса.
При использовании каналов DS-3 важное значение имеет применяемый способ перемешивания передаваемого потока данных. Для настройки его конфигурации вызовите на выполнение команду atm ds3-scramble или atm еЗ-scramble в режиме конфигурации интерфейса.
Шаг 3. Проверьте состояние кабеля.
Шаг 4. Определите, имеется ли информация о физических ошибках в выводе команды show controller, вызванной на выполнение в устройстве ATM, а также команды show atm pvc. Проверьте состояние постоянного виртуального канала. Например, проверьте, не поступают ли сигналы AIS.
Продолжение табл. 22.1
Проблема
Решение
Шаг 5. Если есть основания полагать, что оборудование находится в хорошем физическом состоянии, а значение в полях со статистическими данными об исходящем трафике постоянно возрастает, проверьте, действительно ли происходит перенаправление трафика, исходящего из этого интерфейса, установив петлю обратной связи на физическом интерфейсе. Для этого могут применяться следующие два способа.
Установка физического контура, который передает по петле обратной связи сигнал с разъемов Тх (сокращение от transmit — передача) на разъемы Rx (сокращение от receive — прием).
Применение средств самой платы ATM для выполнения такой проверки. Для этого в режиме конфигурации интерфейса введите следующую команду:
Sevilla(config-if )# loopback diagnostic
После установки петли обратной связи интерфейс должен снова перейти в состояние up/up, если его аппаратные средства являются исправными.
Шаг 6. После установки петли обратной связи попытайтесь выполнить эхо-тестирование устройством собственного адреса. Если плата работает исправно, она должна обеспечить выполнение такой проверки. Убедитесь в том, что обеспечивается правильное преобразование адресов
Имеет место проблема маршрутизации уровня 3
Шаг 1. Оба интерфейса находятся в состоянии up/up. Проверьте соответствующую таблицу маршрутизации (в случае IP — с помощью команды show ip route).
Введите команду show ip route a.b.c.d, где a.b.c.d — IP-адрес получателя, которого пока не удается достигнуть. Этот IP-адрес должен быть достижимым только через постоянный виртуальный канал ATM.
Шаг 2. Проверьте, доступен ли одноранговый маршрутизатор (маршрутизатор, который находится на другом конце постоянного виртуального канала).
Шаг 3. Если одноранговый маршрутизатор представляет собой доступное соседнее устройство, а в таблице маршрутизации не указан подын- терфейс ATM, в котором был бы определен постоянный виртуальный канал для данного маршрута, то проблема, по всей видимости, состоит в нарушении процесса маршрутизации (см. главу 7)
Неправильно задана информация отображения адреса уровня 3 в одноранговом маршрутизаторе
Не применяются средства автоматического установления соответствия между постоянным виртуальным каналом и адресом уровня 3 маршрутизатора, достижимого через этот постоянный виртуальный канал.
Это можно проверить с помощью команды sh atm map:
Ema# sh atm map
Map list test : PERMANENT
ip 164.48.227.142 maps to VC 140
Наиболее важные команды
В настоящем разделе рассматриваются различия между старой и новой синтаксической структурой. Под старой синтаксической структурой подразумевается структура команд sh atm vc и atm pvc, а под новой (которая применяется начиная с версии 11. ЗТ) — структура команд sh atm pvc и pvc.
Команда pvc
Команда конфигурации интерфейса pvc применяется для выполнения одной или нескольких из следующих функций (полное описание этих функций приведено в справочнике по этой команде).
Создание постоянного виртуального канала ATM в главном интерфейсе или подынтерфейсе.
Присвоение имени постоянному виртуальному каналу ATM.
Задание протоколов ILMI, QSAAL или SMDS, которые должны применяться в рассматриваемом постоянном виртуальном канале.
Переход в режим конфигурации интерфейса interface-atm-pvc.
Командный режим
В настоящем разделе показано, какие основные способы можно применять для настройки конфигурации, а также перечислены наиболее важные команды show, применяемые при устранении нарушений в работе постоянных виртуальных каналов ATM в среде распределенной сети.
Пример вывода
Ниже приведен простой пример конфигурации VBR-NRT постоянного виртуального канала. Обратите внимание, что вывод информации о конфигурации по отдельным подынтерфейсам поддерживается с версии 12.ОТ.
Medinalsh running-config int atm 3/0.1
Building configuration...
Current configuration:
I
interface ATM3/0.1 multipoint
ip address 10.2.1.1 255.255.255.252
no ip directed-broadcast
pvc 0/36
protocol ip 10.2.1.1 broadcast
protocol ip 10.2.1.2 broadcast
vbr-nrt 2000 1000 32
encapsulation aalSsnap ।
end
Как указано выше, состояние этого виртуального канала можно проверить с помощью команды sh atm pvc 0/36 или упомянутой выше команды show atm vc.
Medina# sh atm vc
Peak Avg/Min Burst
VCD /
Interface
Name
VPI
VCI
Type
Encaps
SC
Kbps
Kbps
Cells
Sts
3/0
1
0
5
PVC
SAAL
UBR
149760
UP
3/0
2
0
16
PVC
ILMI
UBR
149760
UP
3/0.1
4
0
36
PVC
SNAP
VBR
2000
1000
32
UP
Once you located the
right VCD number,
you can
display
the VC
statistics:
Medina# sh atm vc 4
ATM3/0.1: VCD: 4, VPI:.O, VCI: 36
VBR-NRT, PeakRate: 2000, Average Rate: 1000, Burst Cells: 32
AAL5-LLC/SNAP, etype:0x0, Flags: 0x20, VCmode: 0x0
0AM frequency: 0 second(s)
InARP frequency: 15 minutes(s)
Transmit priority 2
InPkts: 24972, OutPkts: 25137, InBytes: 6778670, OutBytes: 6985152
InPRoc: 24972, OutPRoc: 25419, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
0AM cells received: 0
0AM cells sent: 0
Status: UP
Рекомендуем сравнить результаты, полученные с помощью новой команды sh atm pvc, с результатами, полученными с помощью старой команды show atm vc. Безусловно, следует применять новую команду.
Настройка конфигурации средств преобразования здесь выполнена таким образом, как если бы это был многоточечный интерфейс, а ее проверка может быть выполнена следующим образом:
Medina# sh atm map
Map list ATM3/0.1pvc4 : PERMANENT
ip 10.2.1.1 maps to VC 4, VPI 0, VCI 36, ATM3/0.1
, broadcast
ip 10.2.1.2 maps to VC 4, VPI 0, VCI 36, ATM3/0.1
, broadcast
Очевидно, что в данном случае предусмотрен подынтерфейс многоточечного типа, поэтому применение средств преобразования является обязательным. А в случае по- дынтерфейса типа “точка-точка” строка с обозначением протокола конфигурации постоянного виртуального канала может быть пропущена, поскольку в маршрутизаторе может быть принято предположение, что все IP-пакеты с адресом получателя в одной и той же подсети должны быть перенаправлены в этот постоянный виртуальный канал. В конфигурации постоянного виртуального канала могут также применяться средства протокола Inverse ARP для автоматизации процесса преобразования.
Команда atm pvc
Если в пользовательском устройстве эксплуатируется версия программного обеспечения 11.3 (без суффикса Т) или более ранняя версия, то команда конфигурации постоянного виртуального канала еще не доступна, поэтому должна применяться старая синтаксическая структура. Очевидно, что в таком случае вся настройка конфигурации постоянного виртуального канала выполняется с помощью лишь одной строки команды и это в значительной степени ограничивает возможности определения конфигурации. (Полное описание можно найти в справочнике по этой команде.)
Командный режим
В настоящем разделе показано, какие основные способы можно применять для настройки конфигурации маршрутизатора, в котором эксплуатируется более ранняя версия программного обеспечения IOS по сравнению с версией 11.3Т, а также указаны наиболее важные команды show, применяемые при устранении нарушений в работе постоянных виртуальных каналов ATM в среде распределенной сети.
Пример вывода
Ниже приведен простой пример конфигурации VBR-NRT постоянного виртуального канала. Обратите внимание, что вывод информации о конфигурации по отдельным подынтерфейсам поддерживается с версии 12.ОТ.
Medina# sh run interface atm 3/0.1
Building configuration...
Current configuration: i
interface ATM3/0.1 multipoint
no ip directed-broadcast
map-group MyMap
atm pvc 4 0 36 aal5snap 2000 1000 32 end
При этом подразумевается, что в конфигурации имеется определение списка преобразования, соответствующего имени группы преобразования, как показано в следующем фрагменте конфигурации:
map-list МуМар
ip 10.2.1.1 atm-vc 4 broadcast
ip 10.2.1.2 atm-vc 4 broadcast
Для проверки этого преобразования можно применить такую же команду, как и для проверки команд с новой синтаксической структурой:
Medina# sh atm map
Map list MyMap : PERMANENT
ip 10.2.1.1 maps to VC 4
, broadcast
ip 10.2.1.2 maps to VC 4
, broadcast
Данный пример также показывает, что новая синтаксическая структура является более простой и наглядной.
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco
Прежде чем обратиться в центр Cisco ТАС, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе конкретной системы.
Кроме того, выполните следующие действия и оформите полученные результаты в виде документов.
Вызовите на выполнение команду show tech в обоих маршрутизаторах, чтобы помочь специалисту по технической поддержке проанализировать поведение маршрутизаторов.
Выполните команду sh atm pvc в обоих маршрутизаторах и команду sh atm pvc vpi/vci в постоянном виртуальном канале, который является причиной нарушения в работе, чтобы помочь специалисту по технической поддержке понять, в чем состоит проблема.
Объясните специалисту по технической поддержке, какова точка зрения на эту проблему провайдера ATM, особенно если провайдер считает, что причиной нарушения в работе является маршрутизатор.
Дополнительные источники информации
http://cell-relay.indiana.edu/.
http://www.atmforum.com/ (на этом узле приведено много стандартов, которые можно загрузить бесплатно).
http://www.itu.int/ (для просмотра материалов на этом узле необходимо иметь учетную запись).
http://www.protocols.com/.
http://www.techfest.com/networking/.
news:comp.dcom.cell-relay (архив этой группы новостей находится по адресу http://www.techfest.сот/networking/).
Глава
23
; Устранение нарушений уМработе средств коммутации локальной сети
В настоящей главе описаны основные сведения о работе LAN-коммутаторов и приведены’решения наиболее распространенных проблем, возникающих в среде коммутации локальной сети. Здесь рассматриваются следующие темы.
Основные сведения об использовании LAN-коммугаторов.
Общие рекомендации по устранению нарушений в работе коммутаторов.
Устранение нарушений в работе, характеризующихся отсутствием связи через порт.
Устранение нарушений в работе средств автоматического согласования дуп- лексного/полудуплексного режима передачи на скорости 10/100 Мбит/с.
Формирование магистральных каналов ISL в коммутаторах семейства Catalyst 5000 и 6000.
Примеры настройки конфигурации и устранения нарушений в работе средств автоматического согласования параметров каналов Ethernet на 10/100 Мбит/с.
Настройка конфигурации канала EtherChannel от коммутатора к коммутатору в устройствах ряда Catalyst 4000/5000/6000.
®®Применение PortFast и других команд для устранения нарушений в работе, характеризующихся отсутствием связи с оконечной станцией после ее запуска.
®
®
Настройка конфигурации и устранение нарушений в работе средств многоуров-
^у"невой коммутации IP
^ Устранение нарушений в работе средств протокола распределенного связую- щего дерева,
Основные сведения об использовании LAN-ком мутаторов
В следующих разделах приведены основные сведения о работе LAN-коммутаторов, необходимые для устранения нарушений в их работе. За последние несколько лет коммутаторы получили весьма широкое распространение, в результате чего их конструкция стала намного сложнее. Ниже описаны основные принципы работы коммутаторов.
Концентраторы и коммутаторы
Наряду со значительным возрастанием объемов трафика в локальных сетях наблюдается переход от сетей с разделяемой пропускной способностью, в которых используются концентраторы и коаксиальный кабель, к сетям с выделенной пропускной способностью, в которых используются коммутаторы. Концентратор служит для подключения нескольких устройств к одному и тому же сетевому сегменту. Устройства, установленные в таком сегменте, совместно используют его пропускную способность. Например, если применяется концентратор на 10 Мбит/с и к шести его портам подключено шесть устройств, то пропускную способность, равную 10 Мбит/с, разделяют все эти шесть устройств. При использовании концентратора на 100 Мбит/с все подключенные к нему устройства разделяют пропускную способность в 100 Мбит/с. С точки зрения эталонной модели OSI концентратор можно рассматривать как устройство уровня 1 (физического уровня). Он принимает электрический сигнал из одного порта и передает его во все другие порты, поэтому любой фрейм принимается всеми хостами, несмотря на то, что он предназначен только для одного хоста.
Концентратор в локальной сети со звездообразной топологией может быть физически заменен коммутатором. Коммутатор, как и концентратор, позволяет подключить к нему несколько устройств одной и той же сети, но на этом аналогия заканчивается. Коммутатор позволяет каждому подключенному устройству использовать всю пропускную способность передающей среды, а не разделять ее с другими устройствами. Вся пропускная способность кабеля, соединяющего устройство с коммутатором, зарезервирована для связи только между коммутатором и этим устройством. Если к шести портам коммутатора на 10 Мбит/с подключено шесть различных устройств, то все они смогут обмениваться данными по сети с пропускной способностью 10 Мбит/с, а не разделять эту пропускную способность с другими устройствами. Коммутатор позволяет значительно увеличить доступную пропускную способность сети, что способствует повышению производительности.
Мосты и коммутаторы
Простейший коммутатор можно рассматривать как устройство уровня 2. Здесь под словом уровень подразумевается термин, который определен в семиуровневой модели OSI. Концентратор просто передает электрические сигналы, а коммутатор собирает их во фреймы (выполняет функции протокола уровня 2), а затем определяет, какие действия должны быть выполнены с каждым фреймом. В коммутаторе для обработки фреймов применяется такой же алгоритм, как и в другом широко известном сетевом устройстве — прозрачном мосте. По принципу функционирования коммутатор полностью аналогичен прозрачному мосту, но способен обрабатывать фреймы намного быстрее, чем прозрачный мост (благодаря специ-
альному аппаратному обеспечению и архитектуре). После принятия решения о том, куда должен быть передан фрейм, коммутатор выводит этот фрейм через соответствующий порт (или порты). Коммутатор можно рассматривать как устройство, способное мгновенно создавать виртуальные соединения между различными портами с учетом свойств каждого отдельного фрейма.
Виртуальные локальные сети
Поскольку коммутатор определяет, через какие порты должен осуществляться обмен данными с учетом свойств каждого отдельного фрейма, то вполне естественным дополнением к его функциям стало обеспечение возможности выбирать определенные порты коммутатора для создания специальных групп. Такие группы портов получили название виртуальных локальных сетей. Коммутатор позволяет обеспечить, чтобы трафик между портами одной группы никогда не достигал портов другой группы (что можно рассматривать как маршрутизацию). Такие группы портов (виртуальные локальные сети) аналогичны отдельным сегментам локальной сети.
Виртуальные локальные сети иногда называют также широковещательными доменами. Такое название отражает принцип действия алгоритма прозрачного мостового перенаправления, согласно которому все широковещательные пакеты (в которых в качестве адреса получателя указано “для всех устройств") должны передаваться во все порты одной и той же группы (иными словами, одной и той же виртуальной локальной сети). Поэтому все порты, относящиеся к одной и той же виртуальной локальной сети, относятся также к одному и тому же широковещательному домену.
Алгоритм прозрачного мостового перенаправления
Алгоритм прозрачного мостового перенаправления и протокол распределенного связующего дерева более подробно рассматриваются в главе 20. После получения фрейма коммутатор должен определить, какие действия необходимо выполнить с этим фреймом: игнорировать его, передать через один из остальных портов или отправить во все остальные порты.
Чтобы иметь информацию о том, какие действия должны выполняться с фреймом, коммутатор накапливает данные о местонахождении всех прочих устройств в этом сегменте. Такие данные о местонахождении устройств помещаются в таблицу САМ (Content Addressable Memory — ассоциативная память; эти таблицы получили свое название в соответствии с типом памяти, применяемой для их хранения). В таблице САМ для каждого устройства указаны МАС-адрес устройства, порт, через который можно обратиться к этому МАС-адресу, и обозначена виртуальная локальная сеть, к которой относится этот порт. Коммутатор продолжает постоянно накапливать такую информацию, извлекая ее из каждого полученного фрейма, поэтому таблица САМ коммутатора непрерывно обновляется.
Информация в таблице САМ применяется для определения способа обработки полученного фрейма. Для получения сведений о том, куда отправить фрейм, коммутатор проверяет МАС-адрес получателя в полученном фрейме, а затем ищет этот МАС- адрес получателя в своей таблице САМ. В таблице САМ показано, через какой порт должен быть отправлен фрейм, чтобы он достиг указанного МАС-адреса получателя.
Коммутатор, выполняя функции по перенаправлению фреймов, руководствуется следующими основными правилами.
Если МАС-адрес получателя обнаружен в таблице САМ, то коммутатор передает фрейм через порт, связанный с этим МАС-адресом получателя в таблице САМ. Эта операция называется перенаправлением.
Если соответствующий порт, через который должен быть отправлен фрейм, является тем же портом, через который был получен этот фрейм, то нет необходимости передавать фрейм обратно через тот же порт, поэтому фрейм игнорируется. Эта операция называется фильтрацией.
Если МАС-адреса получателя нет в таблице САМ (т.е. адрес неизвестен), то коммутатор рассылает фрейм через все остальные порты, находящиеся в той же виртуальной локальной сети, что и полученный фрейм. Эта операция называется лавинной рассылкой. В процессе лавинной рассылки фрейм не передается в тот же порт, из которого он был получен.
Если МАС-адрес получателя в принятом фрейме представляет собой широковещательный адрес (FFFF.FFFF.FFFF), то фрейм рассылается во все порты, находящиеся в той же виртуальной локальной сети, что и полученный фрейм. При этом также применяется лавинная рассылка, и фрейм не передается в тот же порт, через который он был получен.
Протокол распределенного связующего дерева
Как было описано выше, алгоритм прозрачного мостового перенаправления предусматривает выполнение лавинной рассылки фреймов с неизвестным и широковещательным адресом через все порты, находящиеся в той же виртуальной локальной сети, откуда был получен фрейм. Такой подход может оказаться причиной возникновения проблем. Если сетевые устройства, в которых применяется этот алгоритм, соединены в физический цикл, то лавинно рассылаемые фреймы (такие как фреймы с широковещательным адресом) будут до бесконечности передаваться по циклу от коммутатора к коммутатору. В зависимости от применяемых при этом физических соединений, под действием алгоритма лавинной рассылки может даже происходить экспоненциальное увеличение количества фреймов, что может привести к возникновению серьезных нарушений в работе сети.
Хотя наличие физических циклов в сети является предпосылкой нарушения в работе, оно имеет свои преимущества, поскольку позволяет обеспечить избыточность. Дело в том, что при отказе одного канала должна быть предусмотрена возможность перейти к использованию другого, дублирующего канала для передачи трафика к месту его назначения. Поэтому был разработан так называемый протокол распределенного связующего дерева, позволяющий воспользоваться преимуществами, связанными с избыточностью, не нарушая работу сети из-за лавинной рассылки. Этот протокол стандартизирован в спецификации IEEE 802.Id.
Протокол распределенного связующего дерева действует по принципу обнаружения и временного блокирования в сетевом сегменте или виртуальной локальной сети таких портов, при использовании которых создаются циклы. В коммутаторах применяется протокол распределенного связующего дерева, который предусматривает определение корневого моста или коммутатора. Другие коммутаторы определяют, на каком расстоянии от корневого коммутатора они находятся. Если для достижения корневого коммутатора можно воспользоваться несколькими путями, то в сети имеется цикл. Коммутаторы с помощью определенного алгоритма определяют, какие порты
необходимо заблокировать, чтобы разорвать цикл. Протокол STP (Spanning-Tree Protocol — протокол распределенного связующего дерева) является динамическим; если происходит отказ одного из каналов в сегменте, то порты, которые первоначально были заблокированы, могут быть снова переведены в режим перенаправления.
Формирование магистральных каналов
Формирование магистрального канала представляет собой механизм, который наиболее часто применяется для обеспечения возможности независимой эксплуатации нескольких виртуальных локальных сетей, охватывающих несколько коммутаторов. Механизм формирования магистральных каналов может также применяться в маршрутизаторах и серверах, что обеспечивает функционирование этих устройств одновременно в нескольких виртуальных локальных сетях. Если на предприятии имеется только одна виртуальная локальная сеть, то применение механизма формирования магистральных каналов может никогда не потребоваться, но если на предприятии насчитывается несколько виртуальных локальных сетей, то для него может оказаться целесообразным применение всех преимуществ формирования магистральных каналов.
Любой отдельно взятый порт коммутатора обычно относится только к одной виртуальной локальной сети; при этом подразумевается, что любой трафик, принимаемый или передаваемый через этот порт, относится только к этой виртуальной локальной сети, которая определена в конфигурации порта. С другой стороны, магистральным является порт, конфигурация которого может быть настроена так, чтобы он передавал и принимал трафик для многих виртуальных локальных сетей. Этот процесс осуществляется путем присоединения к каждому фрейму информации о виртуальной локальной сети; такой процесс называется маркировкой фрейма. К тому же механизм формирования магистрального канала должен быть активизирован на обоих концах канала; устройство, находящееся на другом конце канала, должно быть способно обрабатывать фреймы, которые включают информацию о виртуальной локальной сети, так как без этого обмен данными по магистральному каналу становится невозможным.
Существует несколько разных методов формирования магистральных каналов, которые зависят от используемой передающей среды. В сетях Fast Ethernet или Gigabit Ethernet применяются методы формирования магистральных каналов ISL (Inter-Switch Link — межкоммутаторный канал) или 802. lq. В сетях ATM для формирования магистральных каналов используются средства LANE. В сетях FDDI для формирования магистральных каналов применяется спецификация 802.10.
Метод создания логических каналов EtherChannel
Метод создания логических каналов EtherChannel применяется, если имеется несколько соединений с одним и тем же устройством. Метод EtherChannel позволяет отказаться от такой организации сети, при которой каждый из дублирующихся каналов функционирует независимо, и сгруппировать соответствующие порты, чтобы они работали как одно устройство. Это позволяет равномерно распределить трафик по всем каналам и обеспечить избыточность при отказе одного или нескольких каналов. Параметры настройки EtherChannel должны быть одинаковыми на обоих концах каналов, объединенных в группу. В обычных условиях в результате применения протокола распределенного связующего дерева все эти параллельные соединения между устройствами были бы заблокированы, поскольку они порождают циклы, но программное обеспечение EtherChannel функционирует на более низком уровне по сравнению с
программным обеспечением протокола распределенного связующего дерева, поэтому с точки зрения данного протокола STP все порты, относящиеся к конкретному каналу EtherChannel, рассматриваются как один порт.
Многоуровневая коммутация
Многоуровневой коммутацией (MLS — MultiLayer Switching) называется способность коммутатора перенаправлять фреймы с учетом информации заголовка уровня 3 (а иногда и уровня 4). Обычно этот метод распространяется на IP-пакеты, но может также применяться для обработки IPX-пакетов. Коммутатор получает информацию о том, как должны обрабатываться эти пакеты, взаимодействуя с одним или несколькими маршрутизаторами. Упрощенно этот процесс можно описать таким образом: коммутатор наблюдает за тем, как маршрутизатор обрабатывает пакет, а затем берет на себя функции по обработке очередных пакетов такого же типа. Коммутаторы всегда перенаправляют фреймы намного быстрее, чем маршрутизаторы, поэтому передача части функций по обработке трафика с маршрутизаторов на коммутаторы позволяет добиться значительного повышения производительности. А если в сети происходят какие-то изменения, то маршрутизатор может сообщить коммутатору, что необходимо уничтожить кэш коммутатора уровня 3 и снова сформировать его с нуля по мере дальнейшего развития ситуации. Для взаимодействия с маршрутизаторами применяется протокол MLSP (MultiLayer Switching Protocol — протокол многоуровневой коммутации).
Дополнительная информация с описанием средств MLS
Выше описаны лишь самые основные возможности современных коммутаторов, но перечень их функций постоянно расширяется. Для устранения нарушений в работе сети необходимо знать, как работают установленные в ней коммутаторы, какие средства этих коммутаторов применяются на практике и как эти средства должны работать. Одним из наилучших источников такой информации о коммутаторах Cisco является Web-узел Cisco.
Перейдите по адресу www.cisco.com; в разделе Service & Support выберите ссылку Technical Documents. На открывшейся странице выберите ссылку Documentation Home Раде, чтобы получить доступ к наборам документации по всем продуктам Cisco. По ссылке Multilayer LAN Switches вы сможете перейти к документации обо всех LAN- коммутаторах Cisco. Для получения информации о средствах определенного коммутатора прочитайте документ Software Configuration Guide для конкретной версии применяемого программного обеспечения. Такие руководства по настройке конфигурации программного обеспечения предоставляют основную информацию о возможностях применяемого средства, а также о том, какие команды позволяют выполнить настройку конфигурации коммутатора для использования средств MLS. Вся информация на данном Web-узле доступна без каких-либо ограничений; для получения документации не требуется даже учетная запись, поскольку она предоставлена во всеобщее пользование.
Часть Web-узла Cisco передана в распоряжение сотрудников центра Cisco ТАС. Здесь вы найдете ценную информацию, с помощью которой сможете развернуть собственную сеть, обеспечить ее сопровождение и устранить нарушения в работе. Перейдите на Web-узел ТАС по адресу www.cisco.com/tac; здесь вы сможете выбрать страницу Products Home Page для получения подробной информации по технической поддержке, организованной по конкретным продуктам, или перейти на страницу Technologies Home Page, чтобы получить информацию по технической поддержке конкретной технологии (Fast Ethernet, протокол распределенного связующего дерева,
формирование магистральных каналов и т.д.). Документы ТАС и оперативные инструментальные средства, касающиеся LAN-коммутаторов, находятся по адресу www.cisco.com/warp/customer/473/. Некоторые ресурсы на Web-узле ТАС (в частности, оперативные инструментальные средства) доступны только для пользователей, имеющих контракт по технической поддержке с корпорацией Cisco.
Общие рекомендации по устранению нарушений в работе коммутаторов
Для устранения нарушений в работе коммутаторов предусмотрен целый ряд способов. По мере увеличения количества функций коммутаторов расширяется и круг предпосылок для возникновения нарушений в работе. Следует учитывать, что если разработан общий подход или план проверок для устранения нарушений в работе, то в долговременном аспекте он принесет намного большую пользу по сравнению с методом проб и ошибок. Ниже приведены основные рекомендации, позволяющие повысить эффективность процесса устранения нарушений в работе.
Найдите время, чтобы ознакомиться с тем, как работает коммутатор при нормальных условиях. На Web-узле Cisco имеется огромный объем технической информации с описанием работы коммутаторов Cisco (об этом уже упоминалось в предыдущем разделе). В частности, очень полезными являются руководства по настройке конфигурации. Многие заявки пользователей на устранение неисправностей, полученные специалистами центра Cisco ТАС, были выполнены с использованием информации, приведенной в руководствах по настройке конфигурации конкретного изделия.
На случай возникновения более сложных ситуаций подготовьте точную физическую и логическую схему конкретной сети. На физической схеме должно быть показано, как соединены устройства и кабели, а логическая схема показывает, какие сегменты (виртуальные локальные сети) имеются в сети и какие маршрутизаторы предоставляют услуги по маршрутизации для этих сегментов. В сложных случаях очень важную помощь в устранении нарушений в работе может оказать схема распределенного связующего дерева. Поскольку коммутаторы обладают способностью создавать несколько сегментов путем реализации виртуальных локальных сетей, изучение одних лишь физических соединений не позволяет разобраться в работе сети. Чтобы определить, какие существуют сегменты (виртуальные локальные сети) и как они логически связаны между собой, необходимо знать, как была выполнена настройка конфигурации коммутаторов.
Разработайте план. Некоторые проблемы и решения являются очевидными, а другие — нет. Признаки неисправности, наблюдаемые в конкретной сети, могут явиться следствием проблем, возникающих в другой проблемной области или на другом уровне. Прежде чем переходить к конкретным выводам, проведите целенаправленную проверку того, что в сети работает, а что — нет. Поскольку сети могут быть весьма сложными, часто имеет смысл рассматривать разные возможные проблемные области отдельно. Одним из способов осуществления этого является использование семиуровневой модели OSI. Например, проверьте соответствующие физические соединения (уровень 1), а затем — возможность связи в пределах одной виртуальной локальной сети (уровень 2), определите наличие связи между разными
виртуальными локальными сетями (уровень 3) и т.д. Если есть основания полагать,, что коммутатор имеет правильную конфигурацию, то большинство обнаруженных проблем будет касаться нарушений в работе физического уровня (физические порты и кабельная разводка). В настоящее время коммутаторы выполняют ряд функций протоколов уровня 3 и уровня 4; в частности, в них реализуются логические средства коммутации пакетов на основе информации, полученной от маршрутизаторов, или даже предусматривается физическое размещение маршрутизаторов внутри коммутаторов (коммутация уровня 3 или уровня 4).
Не предполагайте, что какой-то компонент или функция работает, предварительно их не проверив. Такой подход позволяет сэкономить много времени. Например, если персональный компьютер не способен передать информацию в журнал сервера по сети, то могут возникнуть многие нарушения в работе. Не пропускайте ни одной мелочи, полагая, что все и так работает; дело в том, что многие изменения могут быть внесены без вашего ведома. Достаточно потратить лишь одну минуту для проверки некоторых простейших вещей (например, подключены ли рассматриваемые кабели к нужным портам и активны ли эти порты), но такая проверка позволит избежать бесполезной потери целых часов.
Устранение нарушений в работе, характеризующихся отсутствием связи через порт
Если порт не работает, то ничего не работает! Порты являются основой коммутируемой сети. Но некоторые порты имеют особое значение в связи с тем, какое место они занимают в сети и какой объем трафика передают. К ним относятся порты, через которые устанавливаются соединения с другими коммутаторами, маршрутизаторами и серверами. Процесс устранения нарушений в работе таких портов может оказаться более сложным, поскольку в них часто используются специальные средства, например для формирования магистральных каналов и каналов EtherChannel. Но важными являются и остальные порты, так как через них пользователи фактически подключаются к сети.
Порт может не работать по многим причинам, в том числе из-за неисправности аппаратных средств, ошибок в конфигурации и проблем, связанных с трафиком. Эти основные категории нарушений подробно описаны ниже.
Неисправности аппаратных средств
В настоящем разделе рассматриваются вопросы, касающиеся общих требований к аппаратным средствам, в том числе на основе медного и волоконно-оптического кабеля.
Общие сведения
Для обеспечения работы порта необходимо соединить два исправных порта с помощью исправного кабеля соответствующего типа. Для большинства коммутаторов Cisco по умолчанию принято предположение, что свободный порт находится в неподключенном состоянии; это означает, что свободный порт в настоящее время не подключен к какому-то иному порту, но готов к подключению. Если к двум неподключенным портам коммутаторов присоединяется исправный кабель, то на обоих портах должен загореться зеленый индикатор канала, а в информации о состоянии порта
должно быть указано "connected"; такое сообщение указывает на то, что порт находится в рабочем состоянии, по крайней мере, если речь идет о протоколе уровня 1. Ниже описаны действия, которые позволяют проверить, в чем состоит нарушение в работе, если протокол уровня 1 не переходит в рабочее состояние.
Проверьте состояние обоих рассматриваемых портов. Убедитесь в том, что ни один порт, подключенный к каналу, не остановлен. Дело в том, что один или оба порта могли быть закрыты вручную администратором. Порт коммутатора мог быть также остановлен программным обеспечением коммутатора в связи с обнаружением ошибок в конфигурации (эта тема подробно рассматривается ниже). Если порт на одном конце канала остановлен, а на другом — нет, то и порт, применение которого разрешено, находится в неподключенном состоянии (поскольку он не получает информации о соседнем устройстве, находящемся на другом конце кабеля). В информации о состоянии остановленного порта должно быть указано, что он закрыт ("disable") или закрыт из-за ошибки ("errDisable"), в зависимости от того, по какой причине он фактически был остановлен. Канал не перейдет в рабочее состояние до тех пор, пока не будет разрешено применение обоих портов.
После подключения исправного кабеля (еще раз подчеркнем, что он должен иметь соответствующий тип) между двумя портами, разрешенными для применения, через несколько секунд должны загореться зеленым светом индикаторы обоих портов. Кроме того, в интерфейсе командной строки (CLI — Command-Line Interface) состояние обоих портов должно быть указано как "connected". Если же в этот момент канал не установится, то потенциальная область поиска неисправностей распадается на три части: порт на одном конце канала, порт на другом конце канала или соединяющий их кабель. В некоторых случаях приходится также рассматривать другие устройства: преобразователи сигналов передающей среды (от волоконно-оптического к медному кабелю и т.д.), соединители гигабитового интерфейса (GBIC — Gigabit Interface Connector), если применяются каналы Gigabit Ethernet и т.д. Тем не менее область поиска неисправностей все еще остается ограниченной.
Преобразователи сигналов передающей среды могут стать источником шума в канале или ослабить сигнал, если они не функционируют должным образом. Кроме того, при их использовании создаются дополнительные соединения, которые могут вызвать проблемы, поэтому приходится проверять еще один компонент.
Проверьте качество разъемных соединений. Иногда создается впечатление, что кабель надежно подключен к разъему, но фактически качественное электрическое соединение отсутствует; в таком случае кабель нужно вынуть из разъема и снова вставить. Необходимо также следить за тем, чтобы в разъемах не было загрязненных, поломанных или отсутствующих контактов. Такую проверку необходимо выполнить в обоих портах, соединенных друг с другом.
Иногда кабель подключается к неправильному порту. Убедитесь в том, что оба конца кабеля действительно подключены к требуемым портам.
Кроме того, в некоторых случаях канал создается только в одном направлении. Проверьте, действительно ли канал является двунаправленным. Проблема такого типа может возникнуть в случае неисправности одного проводника или контакта кабеля.
Иногда зеленый индикатор канала загорается и в том случае, если кабель не полностью пригоден к работе. Такая ситуация может возникнуть, если на кабель воздействует физическая нагрузка, в результате чего он функционирует на пределе своих характеристик. Обычно в этих случаях в порту обнаруживается большое количество пакетных ошибок.
Чтобы определить, не является ли кабель причиной нарушения в работе, замените его заведомо исправным кабелем подходящего типа.
Если соединительный кабель имеет большую длину (например, проложен под землей через широкий участок территории), то для его проверки рекомендуется использовать сложный кабельный тестер. Если же в вашем распоряжении нет кабельного тестера, то можно выполнить следующее.
Подключите этот длинный кабель к другим портам, чтобы определить, перейдут ли они в рабочее состояние.
Соедините рассматриваемый порт с другим портом того же коммутатора, чтобы просто узнать, перейдет ли порт в рабочее состояние при использовании такого локального соединения.
На время расположите рядом оба рассматриваемых коммутатора, чтобы можно было проверить их работу с заведомо исправным кабелем.
Медный кабель
Убедитесь в том, что для создания соединений используется кабель подходящего типа. Для соединений UTP на 10 Мбит/с необходимо использовать кабель категории 3, а для соединений 10/100 — кабель категории 5.
Для подключения оконечных станций, маршрутизаторов или серверов к коммутатору или концентратору применяется прямой кабель RJ-45. Для соединений между коммутаторами или между коммутаторами и концентраторами применяется перекрестный кабель Ethernet. Ниже приведена схема подключения контактов для перекрестного кабеля Ethernet. Максимальная длина прокладки для медных кабелей Ethernet или Fast Ethernet составляет 100 метров. При выборе кабеля можно руководствоваться следующим простым правилом: для соединения двух устройств, например коммутатора и маршрутизатора, на которых реализованы разные уровни OSI, применяется прямой кабель, а для соединения двух устройств, функционирующих на одном и том же уровне OSI, например двух маршрутизаторов или двух коммутаторов, применяется перекрестный кабель. В рамках только этого правила рабочая станция рассматривается как маршрутизатор.
На рис. 23.1 показана схема подключения контактов перекрестного кабеля, предназначенного для соединения коммутаторов.
1234567
Концентратор Концентратор
3TD+ 6TD-1 RD+ 2RD-3TD+ 6TD-1 RD+ 2RD-3TD+ 6TD-1 RD+ 2RD-3TD+ 6TD-1 RD+ 2RD-
3TD+ 6TD-
1 RD+ 2RD-
3TD+ 6TD-
1 RD+ 2RD-
3TD+ 6TD-
1 RD+ 2RD-
3TD+ 6TD-
1 RD+ 2RD-
Рис. 23.1. Схема подключения контактов перекрестного кабеля, предназначенного для соединения коммутаторов
Волоконно-оптический кабель
При использовании волоконно-оптических кабелей необходимо следить за тем, чтобы они соответствовали требованиям к допустимому расстоянию прокладки и типу используемых портов (одномодовый, многомодовый). Убедитесь в том, что оба соединяемых порта являются либо одномодовыми, либо многомодовыми. Одномодовый волоконно-оптический кабель, как правило, может иметь длину до 10 км, а многомодовый — до 2 км, но в отдельных случаях многомодовый кабель стандарта 100BaseFX, применяемый в полудуплексном режиме, может иметь длину только 400 м.
При создании соединений с помощью волоконно-оптического кабеля необходимо следить за тем, чтобы передающий вывод одного порта был подключен к приемному выводу другого порта и наоборот; соединение передающего вывода с передающим и приемного — с приемным не будет работать.
При создании гигабитовых соединений необходимо следить за тем, чтобы на обоих концах соединения применялись соединители GBIC одинакового типа. Тип соединителя GBIC зависит от типа кабеля и длины прокладки: коротковолновый (SX — short wavelength), длинноволновый/удлиненный (LX/LH — long wavelength/long haul) и сверхдлинный (ZX — extended distance). Соединитель SX GBIC должен подключаться к соединителю SX GBIC; применение соединителей разных типов для создания каналов не допускается. Кроме того, для некоторых гигабитовых соединений требуются уравновешивающие кабели, в зависимости от длины прокладки. Обратитесь к руководствам по установке соединителей GBIC (в качестве примера можно указать руководство, находящееся по адресу www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/ cnfg_nts/ethernet/5399_01.htm).
Если гигабитовый канал не переходит в рабочее состояние, убедитесь в том, что параметры управления потоком данных и автоматического согласования характеристик портов совместимы на обоих концах канала. Дело в том, что при соединении коммутаторов разных поставщиков могут обнаруживаться различия в реализации этих средств. Если невозможно достичь полной определенности в этом вопросе, отключите указанные средства в обоих коммутаторах.
Проблемы настройки конфигурации
Еще одной причиной нарушения связи через порт может стать неправильная конфигурация программного обеспечения коммутатора. Если световой индикатор порта постоянно горит оранжевым светом, то это означает, что порт закрыт по команде от программного обеспечения коммутатора, выполненной либо через пользовательский интерфейс, либо в результате функционирования внутренних процессов.
Убедитесь в том, что порт не закрыт администратором (как было упомянуто выше). Администратор мог закрыть вручную порт на одном конце канала. Такой канал не перейдет в состояние готовности до тех пор, пока не будет снова разрешено применение порта; проверьте состояние порта.
Некоторые коммутаторы, например Catalyst 4000/5000/6000, могут закрыть порт, если функционирующие в них программные процессы обнаруживают ошибку. При просмотре состояния такого порта можно видеть сообщение "errDisable". В таком случае необходимо исправить ошибку конфигурации, а затем вывести порт из состояния errDisable вручную. В некоторых новейших версиях программного обеспечения (начиная с Catalyst OS 5.4(1)) предусмотрена возможность автоматически переводить порт в рабочее состояние после того, как он будет находиться в состоянии errDisable
определенное время, заданное в конфигурации. Ниже перечислены некоторые причины перехода порта в состояние errDisable.
Неправильная настройка режима EtherChannel. Если в конфигурации на одном конце канала предусмотрено применение режима EtherChannel, а на другом — нет, это может привести к тому, что программное обеспечение протокола распределенного связующего дерева закроет порт на конце канала, настроенного на использование режима EtherChannel. Если предпринимается попытка настроить конфигурацию режима EtherChannel, но применяемые при этом порты не имеют одинаковых параметров настройки (скорость, режим передачи, режим формирования магистрального канала и т.д.) как и в других портах во всем канале, это может вызвать переход порта в состояние errDisable. Поэтому, если есть необходимость в использовании режима EtherChannel, то следует настраивать порты на работу в этом режиме на обоих концах канала. Вопросы настройки конфигурации EtherChannel подробно рассматриваются ниже, в разделе “Настройка конфигурации канала EtherChannel от коммутатора к коммутатору в устройствах ряда Catalyst 4000/5000/6000”.
Несоответствие режимов передачи. Если в порту коммутатора возникает слишком много запоздалых коллизий, это обычно указывает на несоответствие режимов передачи. Запоздалые коллизии могут возникать и по другим причинам (например, из-за неисправной сетевой платы или слишком длинных кабельных сегментов), но в настоящее время наиболее распространенной причиной является несоответствие режимов передачи. Программное обеспечение, функционирующее на том конце канала, где применяется дуплексный режим передачи, может передавать данные в тот же момент, когда они к нему поступают, а программное обеспечение, функционирующее на том конце канала, где применяется полудуплексный режим передачи, ожидает, что пакеты будут поступать только в определенное время.
Защита порта от пакетов BPDU. Некоторые новые версии программного обеспечения коммутатора способны контролировать, разрешен ли в порту режим PortFast. Порт, в котором применяется режим PortFast, должен быть подключен к оконечной станции, а не к устройству, вырабатывающему пакеты формирования распределенного связующего дерева, называемые пакетами BPDU. Если коммутатор обнаруживает поступление пакета BPDU в порт, в котором разрешен режим PortFast, он переводит порт в режим errDisable.
Обнаружение однонаправленного канала. В некоторых новых версиях программного обеспечения применяется протокол UDLD (Uni-Directional Link Detection — обнаружение однонаправленного канала), который позволяет определить, является ли связь по каналу односторонней. Связь может стать таковой только при использовании волоконно-оптического кабеля со сломанным оптическим волокном или при наличии других неисправностей кабельной разводки или портов. Такие каналы, функционирование которых нарушено лишь частично, могут стать причинами проблем, если соединенные через них коммутаторы не имеют информации о том, что канал не является полностью работоспособным. При наличии такой проблемы в распределенном связующем дереве могут возникать циклы. Настройка конфигурации программного обеспечения протокола UDLD может быть выполнена таким образом, чтобы порт при обнаружении однонаправленного канала переключался в состояние errDisable.
Несоответствие параметров исходной виртуальной локальной сети. Если в порту не разрешено применение средств формирования магистрального канала, он
относится только к одной виртуальной локальной сети. А после формирования в нем магистрального канала порт может передавать трафик для многих виртуальных локальных сетей. Но порт все еще имеет информацию о том, к какой виртуальной локальной сети он относился до перехода к использованию магистрального канала; такая виртуальная локальная сеть называется исходной. Понятие исходной виртуальной локальной сети является основой метода формирования магистрального канала по спецификации 802. lq. Если информация об исходной виртуальной локальной сети на обоих концах канала не совпадает, порт переходит в состояние errDisable.
Другие причины. Порт может быть переведен в состояние errDisable любым другим процессом, функционирующим в коммутаторе, который обнаружит нарушение в его работе.
Еще одна причина перехода портов в неактивное состояние может быть связана с исчезновением виртуальной локальной сети, к которой относится порт. Каждый порт в коммутаторе относится к определенной виртуальной локальной сети. А после удаления такой виртуальной локальной сети порт становится неактивным. На некоторых коммутаторах постоянно горит оранжевый свет на каждом порту, в котором возникла такая ситуация. Если, придя однажды утром на работу, вы обнаружите сотни оранжевых огоньков, не волнуйтесь: это может быть связано с тем, что все эти порты относились к одной и той же виртуальной локальной сети и кто-то накануне случайно удалил эту сеть. После повторного ввода такой сети в таблицу виртуальных локальных сетей порты снова станут активными, поскольку в каждом из них сохраняется информация о том, к какой виртуальной локальной сети они относятся.
Если при поиске причин нарушений в работе некоторого канала обнаруживается, что его порты перешли в подключенное состояние (connected), но возможность взаимодействия с другим устройством отсутствует, такая ситуация может показаться особенно непонятной. Она обычно указывает на то, что неисправность возникла не на физическом, а на более высоком уровне (2 или 3). Процесс устранения таких неисправностей описан ниже.
Проверьте режим формирования магистрального канала на каждом конце канала. Убедитесь в том, что на обоих концах канала применяется одинаковый режим. Если для одного порта будет установлено значение режима формирования магистрального канала, равное on (а не auto или desirable), а для другого — значение этого режима, равное off, порты не смогут обмениваться данными. При использовании режима формирования магистрального канала изменяется формат пакета; в обоих портах канала должен применяться одинаковый формат, так как в противном случае они не смогут обмениваться данными.
Убедитесь в том, что все устройства находятся в одной и той же виртуальной локальной сети. Если они не относятся к одной и той же виртуальной локальной сети, то необходимо выполнить настройку конфигурации маршрутизатора так, чтобы он обеспечивал взаимодействие этих устройств.
Проверьте, правильно ли выполнена настройка адресации уровня 3.
Проблемы при прохождении трафика
В настоящем разделе описано, какие сведения о функционировании сети можно получить, изучая статистические данные о трафике через порт. В большинстве коммутаторов предусмотрен определенный способ отслеживания пакетов, поступающих в порт или исхо-
дящих из порта. Для вывода такой информации в коммутаторах Catalyst 4000/5000/6000 применяются команды show port и show mac. Структура вывода этих команд в коммутаторах 4000/5000/6000 описана в справочниках по командам коммутатора.
Некоторые из полей в выводе данных о трафике через порт показывают, какой объем данных был передан и получен через порт. Другие поля показывают, сколько фреймов с ошибками было обнаружено в порту. Если обнаруживается большое количество ошибок выравнивания, ошибок FCS или запоздалых коллизий, это может свидетельствовать о несоответствии режимов передачи с обоих концов канала. Другими причинами ошибок такого типа могут служить неисправности сетевых интерфейсных плат или нарушения в работе кабеля. Если в канале обнаруживается большое количество задержанных фреймов, это служит признаком того, что трафик в сегменте является слишком интенсивным; коммутатор не имеет возможности отправлять по кабелю объем трафика, достаточный для опустошения его буферов. Рассмотрите возможность перемещения части сетевых устройств в другой сегмент.
Отказ аппаратных средств коммутатора
Если в результате проведения всех возможных действий порт по-прежнему не работает, это может означать, что неисправны аппаратные средства.
Иногда порты повреждаются под действием электростатического разряда. Свидетельства этого могут быть явно обнаружены, но могут и остаться незамеченными.
Просмотрите результаты самопроверки после включения питания (POST — Power- On Self-Test) в коммутаторе, чтобы определить, обнаруживаются ли какие-либо отказы в любой части коммутатора.
Если некоторые признаки поведения коммутатора кажутся “странными”, это может указывать на нарушения в работе аппаратных средств, но нельзя также исключать возможность нарушения в работе программных средств. Обычно проще перезагрузить программу, чем заниматься ремонтом аппаратных средств, поэтому вначале следует проверить работу программных средств коммутатора.
Возможно, в операционной системе есть дефект, поэтому следует перейти к использованию новой версии операционной системы. Чтобы узнать о выявленных дефектах в программном обеспечении, рекомендуем прочитать примечания к выпуску той версии кода, которая используется в коммутаторе, или обратиться к инструментальному средству Bug Navigator корпорации Cisco (www.cisco.com/support/bugtools).
Могут также возникать искажения в коде программного обеспечения операционной системы, загруженном в оперативную память. Иногда возникшую проблему позволяет устранить перезагрузка той же версии операционной системы.
Если индикатор состояния коммутатора мерцает оранжевым светом, это обычно означает, что возникла какая-то неисправность аппаратных средств порта, модуля или самого коммутатора. На это также указывает наличие строки "faulty" в информации о состоянии порта или модуля.
Но перед заменой аппаратных средств такого коммутатора можно попытаться выполнить следующие действия.
Выньте и снова вставьте модуль в коммутатор. Такую операцию при включенном питании можно выполнять только в том случае, если модуль допускает оперативную замену. Если же у вас нет информации о том, допускает ли модуль такую замену, выключите коммутатор перед повторной вставкой модуля или об-
ратитесь к руководству по установке аппаратных средств. Если порт встроен в коммутатор, не рассматривайте эту рекомендацию.
Перезагрузите коммутатор. Иногда после этого нарушение в работе на время исчезает; но тем самым вы просто вышли из сложившегося положения, а не устранили неисправность.
Проверьте программное обеспечение коммутатора. Если это — новая инсталляция, помните, что некоторые аппаратные компоненты могут применяться только с определенными выпусками программного обеспечения. Проверьте примечания к выпуску или ознакомьтесь с руководствами по установке аппаратных средств и по настройке конфигурации устанавливаемого компонента.
Заменяйте неисправный компонент, только если вы полностью уверены в том, что нарушение в работе связано с отказом аппаратных средств.
Устранение нарушений в работе средств автоматического согласования дуплексного/полудуплексного режима передачи на скорости 10/100 Мбит/с
В настоящем разделе приведена общая информация о поиске неисправностей и описаны методы устранения нарушений в работе средств автоматического согласования Ethernet.
Здесь показано, как определить текущий режим функционирования канала. Затем в этом разделе описаны методы, позволяющие пользователям контролировать режим функционирования канала, а также рассмотрены ситуации, в которых процесс автоматического согласования может завершиться неудачей.
Средства автоматического согласования поддерживаются многими коммутаторами модели Catalyst и маршрутизаторами модели Cisco, выпускаемыми корпорацией Cisco. В настоящем разделе в основном рассматривается процесс автоматического согласования параметров соединения между коммутаторами Catalyst 5000, однако приведенные здесь концепции могут относиться и к устройствам других типов.
Введение
Автоматическое согласование — это необязательное средство технологии Fast Ethernet, регламентированное стандартом IEEE 802.3u, которое позволяет устройствам автоматически обмениваться по каналу информацией о таких параметрах соединения, как скорость и режим передачи.
Режим автоматического согласования предназначен для использования в портах, находящихся на тех участках сети, где к ней подключаются разные пользователи или устройства. Например, во многих компаниях предусмотрены совместно используемые помещения (или отдельные кабинки) для администраторов учетных записей и системных инженеров, обслуживающих большую территорию, чтобы они могли здесь работать, находясь в центральном офисе, а не в пути. В каждом помещении имеются порты Ethernet, постоянно подключенные к сети предприятия. Поскольку обычно невозможно добиться того, чтобы каждый пользователь имел в своем переносном компьютере плату одинакового типа (скажем, плату Ethernet на 10 Мбит/с, 100 Мбит/с или 10/100
Мбит/с), то порты коммутатора, которые поддерживают такие соединения, должны быть способны согласовать с платами параметры скорости и режима передачи. Иное решение может состоять в том, чтобы в каждом помещении были установлены порты и на 10 Мбит/с, и на 100 Мбит/с, обозначенные соответствующими надписями.
Автоматическое согласование не должно применяться в портах, которые обеспечивают подключение таких устройств сетевой инфраструктуры, как коммутаторы и маршрутизаторы, а также постоянное подключение таких оконечных устройств, как серверы и принтеры. Хотя автоматическое согласование скорости и режима передачи обычно применяется по умолчанию в тех портах коммутатора, которые способны поддерживать этот режим, порты, постоянно подключенные к определенным устройствам, должны всегда иметь параметры конфигурации, соответствующие наиболее подходящему режиму работы, т.е. нельзя допускать, чтобы в них происходило согласование таких параметров. Это позволяет устранить любые потенциальные проблемы, связанные с автоматическим согласованием, и гарантировать то, что всегда будет точно известно, как должен работать каждый порт. Например, канал между коммутаторами в сети 10/100BaseTX Ethernet, настроенный на работу в дуплексном режиме со скоростью 100 Мбит/с, должен всегда работать только на этой скорости и в этом режиме передачи. Поэтому порты этих двух коммутаторов никогда не переведут канал на более низкую скорость после сброса одного из портов или перезагрузки одного из коммутаторов. А если порты не смогут функционировать в соответствии с конфигурацией, они просто прекратят передавать какой-либо трафик. С другой стороны, если портам канала между коммутаторами будет разрешено согласовывать режимы своей работы, то может оказаться, что сеть перестала нормально функционировать только потому, что канал между коммутаторами перешел к работе в полудуплексном режиме со скоростью 10 Мбит/с. Обычно легче обнаружить нефункционирующий канал, чем канал, который работает, но не на нужной скорости или не в том режиме передачи, какой требуется.
Одной из наиболее распространенных причин снижения производительности каналов сети Ethernet на 10/100 Мбит/с является то, что один порт канала работает в полудуплексном режиме, а другой — в дуплексном. Такие ситуации иногда возникают, если произошел сброс одного или обоих портов в канале и процесс автоматического согласования не привел к установке одинаковой конфигурации для обоих портов канала. Это может также произойти, если пользователи вносят изменения в конфигурацию на одном конце канала и забывают о том, что такие же изменения необходимо внести и на другом конце. На любом предприятии можно было бы избежать многих обращений в службу поддержки по вопросам, связанным со снижением производительности, разработав правила, требующие настройки конфигурации всех постоянно подключенных устройств в соответствии с предъявляемыми к ним требованиями, и следя за соблюдением этих правил с помощью соответствующих средств контроля.
Устранение нарушений в работе средств автоматического согласования параметров Ethernet между устройствами сетевой инфраструктуры
На рис. 23.2 приведена блок-схема процесса устранения нарушений в работе средств автоматического согласования параметров Ethernet между устройствами сетевой инфраструктуры.
Рис. 23.2. Устранение нарушений в работе средств автоматического согласования параметров Ethernet
Процедуры и сценарии
На рис. 23.3 показан пример применения средств автоматического согласования параметров между двумя коммутаторами Catalyst 5000 Catalyst 5000, установленными в сети Fast Ethernet.
Коммутатор АКоммутатор АКанал Fast EthernetКанал Fast EthernetКоммутатор ВКоммутатор В
Коммутатор А
Коммутатор А
Канал Fast Ethernet
Канал Fast Ethernet
Коммутатор В
Коммутатор В
Рис. 23.3. Пример Г. автоматическое согласование параметров между двумя коммутаторами Catalyst 5000, установленными в сети Fast Ethernet
Таблица 23.1.
Проблема
Нарушения связи, обусловленные применением средств ’ :. автоматического согласования' ^
Решение
В канале не предусмотрено применение средств автоматического согласования
Шаг 1. Вызовите на выполнение команду show port mod_numlport_num, чтобы определить текущие значения параметров автоматического согласования. Если в выводе этой команды, касающемся интерфейсов, находящихся на обоих концах канала, в полях информации о состоянии Duplex и Speed имеется префикс "а-", то автоматическое согласование должно быть проведено успешно
Не поддерживается автоматическое согласование
Шаг 1. Воспользуйтесь командой show port capabilities mod_num/port_num, чтобы проверить, поддерживают ли модули автоматическое согласование
Средства автоматического согласования не функционируют в коммутаторе Catalyst
Шаг 1. Вызовите на выполнение команду set port speed mod_num/port_nuin auto в коммутаторе Catalyst, чтобы выполнить настройку конфигурации автоматического согласования.
Шаг 2. Примените другие порты или модули.
Шаг 3. Выполните сброс портов.
Шаг 4. Подключите другие соединительные кабели.
Шаг 5. Выключите и снова включите устройство
Средства автоматического согласования не функционируют в маршрутизаторе Cisco
Шаг 1. Вызовите на выполнение соответствующую команду IOS, чтобы разрешить применение средств автоматического согласования (если такая команда имеется).
Шаг 2. Примените другие интерфейсы.
Шаг 3. Выполните сброс интерфейсов.
Шаг 4. Подключите другие соединительные кабели.
Шаг 5. Выключите и снова включите устройство
Примеры настройки конфигурации и устранения нарушений в работе средств автоматического согласования каналов Ethernet на 10/100 Мбит/с
В настоящем разделе приведены основные сведения по обеспечению функционирования порта Ethernet на 10/100 Мбит/с, который поддерживает автоматическое согласование. Здесь также показано, как откорректировать заданные по умолчанию параметры работы порта и как восстановить значения параметров, предусмотренные по умолчанию.
Задачи настройки конфигурации порта
В настоящем разделе рассматриваются следующие темы, касающиеся настройки конфигурации порта.
Проверка возможностей портов.
Настройка конфигурации автоматического согласования для порта 1/1 обоих коммутаторов.
Определение того, предусмотрено ли автоматическое согласование скорости и режима передачи.
Установка значения скорости порта 1/1 коммутатора А, равного 10 Мбит/с.
Проверка назначения префикса "а-" в полях Duplex и Speed с информацией о состоянии.
Определение режима передачи, применяемого в порту 1/1 коммутатора В.
Описание нарушений в работе, возникающих при несоответствии режимов передачи.
Анализ сообщений об ошибках, возникающих при формировании распределенного связующего дерева.
Переход порта 1/1 коммутатора А из дуплексного режима передачи в полудуплексный.
Настройка параметров дуплексного режима передачи и скорости для порта 1/1 коммутатора В.
Восстановление заданных по умолчанию значений параметров режима передачи и скорости в портах 1/1 обоих коммутаторов.
Анализ изменений состояния портов обоих коммутаторов.
Ниже описаны действия, выполняемые с помощью консоли коммутатора Catalyst 5000.
Шаг 1. Вызовите на выполнение команду show port capabilities 1/1, которая позволяет определить возможности порта 1/1 (сети Ethernet 10/100BaseTX) коммутатора А. Введите эту команду для обоих рассматриваемых портов. Если в этих портах должны использоваться средства автоматического согласования, то оба они должны поддерживать одинаковые возможности установления скорости и применения режима передачи.
В приведенном ниже выводе этой команды курсивом показано, где находится информация о возможностях установления скорости и применения режима передачи.
Switch-A> (enable) show port capabilities 1/1
Model WS-X5530
Port 1/1
Type 10/lOOBaseTX
Speed auto,10,100
Duplex half,full
Шаг 2. Выполните настройку конфигурации средств автоматического согласования и скорости, а также режима передачи в порту 1/1 обоих коммутаторов с помощью команды set port speed 1/1 auto (где auto — значение по умолчанию для портов, которые поддерживают автоматическое согласование).
Switch-A> (enable) set port speed 1/1 auto
Port(s) 1/1 speed set to auto detect.
Switch-А (enable)
Примечание
Команда set port speed lmod_num/port_numt auto устанавливает также опцию auto для режима передачи. Такой команды, как set port duplex {mod_num/port_num} auto, не существует.
Шаг 3. Приведенная ниже команда show port 1/1 отображает состояние портов 1/1
коммутаторов А и В.
Switch-A> (enable) show port 1/1
Level
Duplex Speed Type
Port Name
Status
Vian
1/1
connected
1
normal
а-full a-100
10/lOOBaseTX
Switch-B> (enable)
show port 1/1
Port Name
Status
Vian
Level
Duplex Speed Type
1/1
10/lOOBaseTX
connected
1
normal
а-full a-100
В приведенном выше выводе этой команды курсивом показано, где находится информация о текущем состоянии порта. Обратите внимание, что здесь основная часть обычного вывода команды show port {mod_num/port_num} была опущена.
Префиксы "а-" перед строками "full" и "100" указывают на то, что данный порт не был жестко закодирован (сконфигурирован) на использование конкретной скорости или режима передачи. Поэтому он будет способен выполнить автоматическое согласование скорости и режима передачи, если устройство, к которому он подключен (находящееся на другом конце канала), также будет готово выполнить автоматическое согласование скорости и режима передачи.
Следует также отметить, что в строке состояния обоих портов приведено значение "connected", которое указывает на то, что обнаружены канальные им-
пульсы, поступающие от другого порта. В строке состояния может быть указано значение "connected", даже если режим передачи был неправильно согласован или имеется ошибка в конфигурации.
Шаг 4. Для демонстрации того, что произойдет, если устройство на одном конце канала выполняет процедуру автоматического согласования, а на другом конце канала — нет, установим скорость в порту 1/1 коммутатора А равной 10 Мбит/с с помошью команды set port speed 1/1 10.
Switch-A> (enable) set port speed 1/1 10
Port(s) 1/1 speed set to 10Mbps.
Switch-A> (enable)
Примечание
Жесткое кодирование скорости порта (ввод в конфигурацию соответствующего значения) приводит к отмене всех функциональных средств автоматического согласования скорости и режима для этого порта.
При настройке в конфигурации порта определенной скорости режим передачи автоматически настраивается на применение того режима, который был согласован перед этим, в данном случае — дуплексного. Поэтому ввод команды set port speed 1/1 10 обеспечивает настройку конфигурации порта 1/1 на использование дуплексного режима таким образом, как если бы была введена команда set port duplex 1/1 full. Описание этого процесса приведено в следующем шаге.
Шаг 5. Теперь должно стать очевидным значение префикса "а-" в полях с описанием состояний Duplex и Speed.
Отсутствие префикса "а-" в полях состояния вывода команды show port 1/1 коммутатора А означает, что теперь выполнена настройка конфигурации режима передачи на работу в дуплексном режиме и в конфигурации задано значение скорости 10 Мбит/с.
Switch-A> (enable) show port 1/1
Port NameStatusVianLevel Duplex Speed Type
1/1connected 1normal full 1010/lOOBaseTX
Шаг 6. Результаты выполнения команды show port 1/1 в коммутаторе В показывают, что этот порт теперь работает в полудуплексном режиме на скорости 10 Мбит/с.
Switch-B> (enable) show port 1/1
Port NameStatusVianLevel Duplex Speed Type
1/1connected 1normal a-half a-10 10/100BaseTX
Этот шаг показывает, что устройство на другом конце канала способно определить, на какой скорости работает взаимодействующее с ним по каналу устройство, даже несмотря на то, что в конфигурации взаимодействующего устройства не предусмотрено применение средств автоматического согласования.
Для этого применяются средства определения типа поступающего электрического сигнала, которые позволяют определить, передается ли он на скорости 10 или 100 Мбит/с. С их помощью коммутатор в определил, что порт 1/1 должен работать на скорости 10 Мбит/с.
Но возможность правильно определить режим передачи по такому же принципу, как определяется скорость, полностью отсутствует. В этом случае, если конфигурация порта 1/1 коммутатора В настроена на применение автоматического согласования, а конфигурация коммутатора А — нет, порт 1/1 коммутатора В был принудительно установлен на использование предусмотренного по умолчанию режима передачи. В портах Ethernet коммутатора Catalyst по умолчанию применяется режим автоматического согласования, а если процесс автоматического согласования оканчивается неудачей, то устанавливается полудуплексный режим передачи.
Этот пример также подтверждает, что канал может успешно перейти в рабочее состояние (как показывают значения connected), несмотря на рассогласование режимов передачи. Конфигурация порта 1/1 коммутатора А настроена на работу в дуплексном режиме, а порт 1/1 коммутатора В по умолчанию перешел в полудуплексный режим передачи. Для предотвращения такой ситуации необходимо всегда выполнять настройку конфигурации не в одном, а в обоих устройствах, находящихся на двух концах канала.
Наличие префикса "а-" в полях состояния Duplex и Speed не всегда означает, что текущие параметры были согласованы. Иногда его появление свидетельствует только о том, что не была выполнена настройка конфигурации порта на определенную скорость или режим передачи.
В приведенном выше выводе для коммутатора В показано, что в поле Duplex содержится значение "a-half", а в поле Speed — значение "а-10", а это указывает на то, что порт работает в полудуплексном режиме на скорости 10 Мбит/с. Но в данном примере порт, соединенный с помощью канала с этим портом (порт 1/1 коммутатора А), настроен на использование дуплексного режима передачи со скоростью 10 Мбит/с. Поэтому порт 1/1 коммутатора В не мог выполнить автоматическое согласование текущих параметров соединения. На этом основании можно сделать вывод, что префикс "а-" указывает только на готовность к выполнению автоматического согласования, а не на то, что это согласование фактически будет выполнено.
Шаг 7. После изменения значения скорости в порту 1/1, в результате которого оно составило 10 Мбит/с, в коммутаторе А отображается следующее сообщение о несоответствии режимов передачи. Это несоответствие вызвано тем, что порт 1/1 коммутатора В перешел в полудуплексный режим передачи, применяемый по умолчанию, поскольку получил информацию о том, что порт, соединенный с ним по каналу, больше не поддерживает автоматическое согласование. %CDP-4-DUPLEXMISMATCH:Full/half duplex mismatch detected ol
Важно отметить, что это сообщение формируется протоколом CDP, а не с помощью протокола автоматического согласования 802.3. Протокол CDP позволяет передавать информацию об обнаруженных нарушениях в работе, но он, как правило, не обеспечивает их автоматическое исправление.
Рассогласование режимов передачи может привести к активизации сообщений об ошибках. На несоответствие режимов передачи указывает также то, что количество ошибок PCS и ошибок выравнивания быстро увеличивается в порту, работающем в полудуплексном режиме, а в порту, работающем в дуплексном режиме, появляется большое количество “карликовых” фреймов (как показывает значение в поле Runts в выводе команды sh port {mod_num/port_num^).
Шаг 8. Кроме сообщений об ошибках, связанных с рассогласованием режимов передачи, при изменении скорости канала могут быть также обнаружены следующие сообщения, касающиеся формирования распределенного связующего дерева. Описание протокола распределенного связующего дерева выходит за рамки настоящего раздела. Дополнительную информацию см. выше, в разделе “Устранение нарушений в работе средств протокола распределенного связующего дерева и связанные с этим проектные соображения”.
%PAGP-5-PORTFROMSTP:Port 1/1 left bridge port 1/1 %PAGP-5-PORTTOSTP;Port 1/1 joined bridge port 1/1
Шаг 9. Чтобы показать, что происходит при настройке конфигурации режима передачи, установим полудуплексный режим передачи для порта 1/1 коммутатора А с помощью команды set port duplex 1/1 half.
Switch-A> (enable) set port duplex 1/1 half
Port(s) 1/1 set to half-duplex.
Switch-A> (enable)
Команда show port 1/1 показывает изменение режима передачи этого порта.
Switch-A> (enable) sh port 1/1
Port NameStatusVianLevel Duplex Speed Type
1/1connected 1normal half 10 10/100BaseTX
Теперь порты 1/1 обоих коммутаторов работают в полудуплексном режиме. Но конфигурация порта 1/1 коммутатора В все еще настроена на использование автоматического согласования, как показывает приведенный ниже вывод команды show port 1/1.
Switch-B> (enable) show port 1/1
Port NameStatusVianLevel Duplex Speed Type
1/1connected 1normal a-half a-10 10/100BaseTX
В следующем шаге показано, как выполнить настройку конфигурации полудуплексного режима передачи для порта 1/1 коммутатора В. Этот шаг выполняется в соответствии с рекомендациями, согласно которым для настройки конфигурации обоих устройств, подключенных к каналу, должен применяться одинаковый способ.
Шаг 10. Теперь, согласно тому правилу, что всегда необходимо выполнять одинаковую настройку конфигурации обоих устройств, подключенных к каналу, на этом этапе порт 1/1 коммутатора В будет переведен из дуплексного режима передачи в полудуплексный и для него будет установлена скорость 10 Мбит/с.
Ниже приведены результаты, полученные при выполнении команды set port duplex 1/1 half в коммутаторе В.
Switch-B> (enable) set port duplex 1/1 half
Port 1/1 is in auto-sensing mode.
Switch-B> (enable)
Выполнение команды set port duplex 1/1 half окончилось неудачей, поскольку она не работает, если разрешено применение автоматического согласования. Это также означает, что рассматриваемая команда не отменяет автоматическое согласование. Автоматическое согласование можно отменить только с помошью команды set port speed ^mod_num/port_num {10 | 100}}.
Ниже приведены результаты, полученные при выполнении команды set port speed 1/1 10 в коммутаторе В.
Switch-B> (enable) set port speed 1/1 10
Port(s) 1/1 speed set to 10 Mbps.
Switch-B> (enable)
Теперь команда set port duplex 1/1 half в коммутаторе В будет выполнена успешно:
Switch-A> (enable) set port duplex 1/1 half
Port(s) 1/1 set to half-duplex.
Switch-A> (enable)
Результаты выполнения команды show port 1/1 в коммутаторе В показывают, что конфигурация обоих портов уже настроена на использование полудуплексного режима передачи со скоростью 10 Мбит/с.
Switch-B> (enable) show port 1/1
Port NameStatusVianLevel Duplex Speed Type
1/1connected 1normal half 1010/100BaseTX
Примечание
Команда set port duplex ^mod_num/port_num {half | full}} не может быть выполнена независимо от команды set port speed {mod_num/port_num {10 | 100}}. Иными словами, необходимо вначале установить скорость, а затем — режим передачи.
Шаг 11. После завершения экспериментов выполните настройку конфигурации портов 1/1 обоих коммутаторов на использование автоматического согласования с помощью команды set port speed 1/1 auto.
Switch-A> (enable) set port speed 1/1 auto
Port(s) 1/1 speed set to auto detect.
Switch-A> (enable)
Примечание
Если настройка конфигурации режима передачи порта была выполнена с использованием опции, отличной от auto, то единственный способ настройки конфигурации порта, обеспечивающей автоматическое определение режима передачи, состоит в использовании ко-
манды set port speed {mod_num/port_num) auto. Такой команды, как set port duplex ^mod_num/port_num} auto, не существует. Иными словами, в результате выполнения команды set port speed ^modjium/port_num} auto происходит переустановка параметров автоматического определения и скорости порта, и режима передачи в значение auto.
Шаг 12. Проверьте состояние портов 1/1 в обоих коммутаторах с помощью команды show port 1/1.
Switch-A> (enable) show port 1/1
Port NameStatus Vian Level Duplex Speed Type
1/1connected
Switch-B> (enable) show port 1/1
1
normal
а-full a-100 10/100BaseTX
Port Name
Status
Vian
Level
Duplex Speed Type
1/1
connected
1
normal
а-full a-100 10/100BaseTX
Теперь в обоих портах применяются средства автоматического согласования, предусмотренные по умолчанию. После их сброса оба эти порта согласуют между собой применение дуплексного режима и скорости 100 Мбит/с.
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco
Прежде чем обратиться в центр Cisco ТАС, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе своей системы.
Кроме того, выполните следующие действия и подготовьте указанные документы, которые позволят специалистам центра Cisco ТАС быстрее предоставить вам помощь.
Вызовите на выполнение команду show version во всех устройствах, с которыми может быть связано рассматриваемое нарушение в работе, и сохраните полученные результаты.
Вызовите на выполнение команду show port mod_num/port_num во всех портах, с которыми может быть связано рассматриваемое нарушение в работе, и сохраните полученные результаты.
Вызовите на выполнение команду show port modjium/portjium capabilities во всех портах, с которыми может быть связано рассматриваемое нарушение в работе, и сохраните полученные результаты.
Дополнительная информация
См. Web-узел IEEE ( www.ieee.org/).
Формирование магистральных каналов ISL в коммутаторах семейства Catalyst 5000 и 6000
В настоящем разделе рассматриваются способы формирования магистрального канала ISL между двумя коммутаторами. Магистральные порты позволяют передавать
через одно соединение между коммутаторами трафик нескольких виртуальных локальных сетей. Канал между двумя коммутаторами, в котором не применяются средства формирования магистрального канала, способен нести трафик только одной виртуальной локальной сети.
Здесь показано, как определить текущий режим функционирования канала. Затем описаны методы, позволяющие пользователям контролировать режим функционирования канала, а также рассмотрены ситуации, в которых процесс автоматического согласования может завершиться неудачей.
Средства автоматического согласования поддерживаются многими коммутаторами модели Catalyst и маршрутизаторами модели Cisco, выпускаемыми корпорацией Cisco. В настоящем разделе в основном рассматривается процесс автоматического согласования между коммутаторами Catalyst 5000, но приведенные здесь концепции могут относиться и к устройствам других типов.
Введение
Применение магистральных каналов не требуется только в очень простых коммутируемых сетях, где имеется лишь одна виртуальная локальная сеть (один широковещательный домен). В большинстве локальных сетей определенная часть трафика состоит из фреймов специальных протоколов, применяемых для управления сетью. Даже неполный перечень таких протоколов включает CDP, VTP (Virtual Trunking Protocol — протокол формирования магистральных каналов виртуальных сетей), DTP (Dynamic Trunking Protocol — протокол динамического формирования магистральных каналов), STP и PAgP (Port Aggregation Protocol — протокол агрегирования портов). Поэтому целесообразно направлять этот трафик по специальной виртуальной локальной сети управления (назовем ее VLAN 1). Такая сеть используется также при эхо- тестировании или создании соединения Telnet непосредственно к коммутатору или от коммутатора (такую виртуальную локальную сеть и IP-адрес коммутатора можно сформировать путем настройки конфигурации интерфейса scO, как описано ниже). В среде, характеризующейся наличием большого количества виртуальных локальных сетей, большинство сетевых администраторов рекомендуют направить весь трафик управления по отдельной виртуальной локальной сети, обычно VLAN 1. Затем выполняется настройка конфигурации пользовательского трафика на передачу по виртуальным локальным сетям, отличным от этой виртуальной локальной сети, применяемой по умолчанию.
Одним из двух возможных протоколов формирования магистральных каналов для сети Ethernet является протокол ISL (собственный протокол корпорации Cisco). Другой протокол определен стандартом IEEE 802. lq.
Устранение нарушений в работе средств формирования магистральных каналов ISL в коммутаторах семейства Catalyst 5000 и 6000
В настоящем разделе приведено несколько простых сценариев формирования магистральных каналов ISL. Изучение этого раздела позволяет приобрести основные навыки настройки конфигурации и устранения нарушений в работе средств формирования магистральных каналов ISL (рис. 23.4).
НетНетВ портахВ портахсозданысозданымагистральныемагистральныеканалы?каналы?ДаДаДаДаДаДаДаДаНетНетДаДаНетНетНастроить конфигурацию доменаVTPНастроить конфигурацию доменаVTPНастроить конфигурацию портов для создания магистральных каналовНастроить конфигурацию портов для создания магистральных каналовМодернизировать портыМодернизировать портыПроблемаПроблемас паролемс паролемдомена VTP?домена VTP?ВыполненаВыполненанастройканастройкаконфигурацииконфигурациидоменадоменаыполненаыполненанастройканастройкаконфигурацииконфигурациидоменадоменаVTP?VTP?В портахВ портахсозданысозданымагистральныемагистральныеканалы?каналы?В портахВ портахсозданысозданымагистральныемагистральныеканалыканалыПортыПортыоддерживаюоддерживаюсозданиесозданиемагистральныхмагистральныхналов?налов?ации порто обеспечивают создаации порто обеспечивают создание магистральние магистральных кана-ных кана-НетНетНетНетНетНетНетНетДаДаВыполнить сброс портоаВыполнить сброс портоаВвести а конфигурацию общий парольVTPВвести а конфигурацию общий парольVTPПроблемаПроблемас паролемс паролемдомена VTP?домена VTP?В портахВ портахсозданысозданымагистральныемагистральныеканалы?каналы?Ввести в конфигурациюВвести в конфигурациюВ портахВ портахсозданысозданымагистральныемагистральныеканалы?каналы?НетНетВ портахВ портахсозданысозданымагистральныемагистральныеканалы?каналы?ДаДаДаДаДаДаПолучить вывод команд show version,show port mod_num/port_num,show trunk mod_num/port_num, show vtp domainи обратиться за помощью
Нет
Нет
В портах
В портах
созданы
созданы
магистральные
магистральные
каналы?
каналы?
Да
Да
Да
Да
Да
Да
Да
Да
Нет
Нет
Да
Да
Нет
Нет
Настроить конфигурацию доменаVTP
Настроить конфигурацию доменаVTP
Настроить конфигурацию портов для создания магистральных каналов
Настроить конфигурацию портов для создания магистральных каналов
Модернизировать порты
Модернизировать порты
Проблема
Проблема
с паролем
с паролем
домена VTP?
домена VTP?
Выполнена
Выполнена
настройка
настройка
конфигурации
конфигурации
домена
домена
ыполнена
ыполнена
настройка
настройка
конфигурации
конфигурации
домена
домена
VTP?
VTP?
В портах
В портах
созданы
созданы
магистральные
магистральные
каналы?
каналы?
В портах
В портах
созданы
созданы
магистральные
магистральные
каналы
каналы
Порты
Порты
оддерживаю
оддерживаю
создание
создание
магистральных
магистральных
налов?
налов?
ации порто обеспечивают созда
ации порто обеспечивают созда
ние магистраль
ние магистраль
ных кана-
ных кана-
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Да
Да
Выполнить сброс портоа
Выполнить сброс портоа
Ввести а конфигурацию общий парольVTP
Ввести а конфигурацию общий парольVTP
Проблема
Проблема
с паролем
с паролем
домена VTP?
домена VTP?
В портах
В портах
созданы
созданы
магистральные
магистральные
каналы?
каналы?
Ввести в конфигурацию
Ввести в конфигурацию
В портах
В портах
созданы
созданы
магистральные
магистральные
каналы?
каналы?
Нет
Нет
В портах
В портах
созданы
созданы
магистральные
магистральные
каналы?
каналы?
Да
Да
Да
Да
Да
Да
Рис. 23.4. Блок-схема процесса устранения нарушений в работе средств формирования магистральных каналов ISL в коммутаторах семейства Catalyst 5000 и 6000
Процедуры и сценарии
Сценарий 1. Формирование магистрального канала ISL от коммутатора Catalyst 5000 к коммутатору Catalyst 5000 с использованием канала Fast Ethernet (рис. 23.5).
Коммутатор АКоммутатор АКоммутатор ВКоммутатор ВПорт 1/1Порт 1/1Порт 1/1Порт 1/1
Коммутатор А
Коммутатор А
Коммутатор В
Коммутатор В
Порт 1/1
Порт 1/1
Порт 1/1
Порт 1/1
Канал Fast Ethernet
Рис. 23.5. Формирование магистрального канала ISL от коммутатора Catalyst 5000 к коммутатору Catalyst 5000 с использованием канала Fast Ethernet
[ Таблица 23.2. Проблемы формирования магистрального канала ISL>
ПроблемаРешение
В портах не предусмотрено применение средств формирования магистрального каналаВ портах не предусмотрено применение средств формирования магистрального каналаШаг 1. Вызовите на выполнение команду show trunk mod_num/port_nuin, чтобы определить, предусмотрено ли в портах применение средств формирования магистрального канала
В портах не предусмотрено применение средств формирования магистрального канала
В портах не предусмотрено применение средств формирования магистрального канала
Обмен данными по магистральному каналу не поддерживается
Шаг 1. Воспользуйтесь командой show port capabilities tnod_numl port_num, чтобы определить, поддерживаются ли модулями средства формирования магистрального канала
Не выполнена настройка конфигурации на использование средств формирования магистрального канала
Шаг 1. Вызовите на выполнение в коммутаторе Catalyst команду set trunk tnod_nuni/port_nuni desirable, чтобы выполнить настройку конфигурации средств формирования магистрального канала
Необходимо проверить, что в конфигурацию введено доменное имя УТР
Шаг 1. Вызовите на выполнение команду show vtp domain, чтобы определить, введено ли доменное имя в конфигурацию.
Все коммутаторы в домене должны иметь в составе конфигурации одно и то же имя. Это имя чувствительно к регистру
Не выполнена настройка конфигурации на использование доменного имени УТР
Шаг 1. Вызовите на выполнение команду vtp domain dotnain_natne
Возникло нарушение в работе, связанное с применением пароля домена УТР
Шаг 1. Воспользуйтесь командой show vtp domain, чтобы определить, установлен ли пароль. Все коммутаторы должны иметь одинаковый пароль. Пароль домена чувствителен к регистру
Примеры настройки конфигурации и устранения нарушений в работе средств формирования магистральных каналов ISL в коммутаторах семейства Catalyst 5000 и 6000
В настоящем разделе поэтапно описан процесс настройки конфигурации и устранения нарушений в работе средств формирования магистральных каналов ISL.
Задачи настройки конфигурации средств формирования магистральных каналов
В настоящем разделе рассматриваются следующие темы, касающиеся настройки конфигурации средств формирования магистральных каналов.
Проверка средств ISL в портах.
Подключение коммутаторов.
Проверка работоспособности портов.
Присвоение IP-адресов управляющим портам.
Проверка того, что в физическом канале между коммутаторами не сформирован магистральный канал.
Выполнение эхо-тестирования одного коммутатора с другого коммутатора.
Создание сети VLAN 2 в каждом коммутаторе.
Перемещение управляющего интерфейса (scO) в сеть VLAN 2.
Подтверждение того, что нельзя выполнить эхо-тестирование одного коммутатора с другого.
Ввод в конфигурацию каждого коммутатора одного и того же доменного имени VTP.
Формирование магистрального канала между коммутаторами.
Проверка того, что на базе физического канала между коммутаторами создан магистральный канал.
Выполнение эхо-тестирования одного коммутатора с другого.
Поэтапное описание процедуры
Ниже описаны действия, выполняемые с помощью консоли коммутатора Catalyst 5000.
Шаг 1. Убедитесь в том, что выбранные порты поддерживают формирование магистральных каналов 1SL. Формирование магистральных каналов ISL поддерживают интерфейсы Ethernet нескольких типов. Порты lOBaseT (обычная сеть Ethernet) не поддерживают формирование магистральных каналов, а большинство портов lOOBaseT (сеть Fast Ethernet) поддерживают.
Вызовите на выполнение команду show port capabilities {module_nmnber} | {module_number/port_number} в обоих коммутаторах, чтобы определить, поддерживаются ли средства 1SL рассматриваемыми портами. Обратите внимание, что в данном примере в конце команды указан порт 1/1. Это позволяет ограничить объем отображаемой информации только тем, что непосредственно относится к порту 1/1.
Switch-A> show port capabilities 1/1
ModelWS-X5530
Port1/1
Type10/lOOBaseTX
Speedauto,10,100
Duplexhalf,full
Trunk encap type Trunk mode ChannelBroadcast suppression Flow control Security Membership Fast start QOS Rewrite UDLD Switch-A>Trunk encap type Trunk mode ChannelBroadcast suppression Flow control Security Membership Fast start QOS Rewrite UDLD Switch-A>ISL
Trunk encap type Trunk mode Channel
Broadcast suppression Flow control Security Membership Fast start QOS Rewrite UDLD Switch-A>
Trunk encap type Trunk mode Channel
Broadcast suppression Flow control Security Membership Fast start QOS Rewrite UDLD Switch-A>
on,off,desirable,auto,nonegotiate
1/1-2
percentage(0-100)
no
yes
static,dynamic
yes .
noNot capablenoNot capablen/a
no
Not capable
no
Not capable
Шаг 2. Соедините два порта коммутатора с помощью перекрестного кабеля Ethernet. В данном примере порт 1/1 коммутатора А подключается к порту 1/1 коммутатора в.
Шаг 3. Проверьте готовность к работе обоих портов, введя команду show port 1/1 в коммутаторе А. В поле состояния этого порта должно быть показано значение "connected".
Switch-A> (enable) show port 1/1
Port NameStatus Vian Level Duplex Speed Type
1/1connected1 normal а-full a-100 10/100BaseTX
Switch-A> (enable)
Шаг 4. Вызовите на выполнение команду set interface scO 172.16.84.17 255.255.255.0 172.16.84.255 в коммутаторе А и команду set interface scO 172.16.84.18 255.255.255.0 172.16.84.255 в коммутаторе В, чтобы присвоить IP-адреса из одной и той же подсети этим управляющим портам обоих коммутаторов. В этой команде должна быть также указана виртуальная локальная сеть для интерфейса scO (управляющая виртуальная локальная сеть), если она отличается от применяемой по умолчанию сети VLAN 1.
Switch-A> (enable) set int scO 172.16.84.17 255.255.255.0 172.16.84.255 Interface scO IP address, netmask, and broadcast set.
Switch-A> (enable)
Шаг 5. Убедитесь в том, что рассматриваемый канал между коммутаторами А и В не является магистральным, введя команду show trunk 1/1 в коммутаторе А.
Switch-A> (enable) show trunk 1/1
Port ModeEncapsulation Status Native vlan
1/11/1autoautoislislnot-trunking 1not-trunking 1
1/1
1/1
auto
auto
isl
isl
not-trunking 1
not-trunking 1
PortVians allowedon trunk
1/11-1005
PortVians allowedand activein management domain
1/11
Port Vians in spanning tree forwarding state and not pruned
1/11
Switch-A> (enable)
Примечание
Значение Native vlan в выводе этой команды указывает на виртуальную локальную сеть, в которую помещается этот порт, когда он не находится в режиме формирования магистрального канала. Если же настройка конфигурации этого порта будет выполняться для формирования не магистрального канала ISL, а магистрального канала 802.1 q, значение Native vlan показывает также виртуальную локальную сеть для тех фреймов, которые остаются неотмеченными; все прочие фреймы будут отмечены (с другой стороны, при использовании средств формирования магистрального канала ISL каждый фрейм данных отмечен соответствующим идентификатором виртуальной локальной сети).
В поле Status, которое позволяет определить, применяются ли средства формирования магистрального канала, должно быть указано значение "not-trunking", поскольку по умолчанию для протокола DTP применяется режим Auto. Протокол DTP создан во исполнение стратегического замысла, направленного на постепенное вытеснение протокола DISL (Dynamic ISL — динамическое формирование межкоммутаторного канала), так как в нем предусмотрена поддержка согласования средств формирования магистральных каналов 802. lq. Протокол DTP доступен с версии 4.x программного обеспечения Catalyst, но для его поддержки должны быть установлены некоторые аппаратные модули. Ниже описано пять различных состояний, для которых может быть выполнена настройка конфигурации протокола DTP.
auto. Порт принимает фреймы DTP от соседнего коммутатора. Если соседний коммутатор показывает, что возникла необходимость создать магистральный канал или магистральный канал уже создан, то порт, находящийся в состоянии auto, формирует магистральный канал с соседним коммутатором. В режиме auto порт не может стать инициатором формирования магистрального канала; он лишь выполняет указания по формированию магистрального канала, полученные от соседнего коммутатора.
desirable. Происходит обмен сообщениями по протоколу DTP с соседним коммутатором. Порт сообщает соседнему коммутатору, что способен сформировать магистральный канал ISL и хотел бы, чтобы соседний коммутатор также принял участие в формировании магистрального канала ISL.
on. Происходит обмен сообщениями по протоколу DTP с соседним коммутатором. Это приводит к автоматическому разрешению применения средств формирования магистрального канала ISL в его порту, независимо от состояния соседнего коммутатора. Этот порт останется магистральным портом ISL, если только не получит пакет ISL, который явно запрещает применение данного магистрального порта ISL.
nonegotiate. Обмен сообщениями по протоколу DTP с соседним коммутатором DTP не происходит. Это приводит к автоматическому разрешению применения средств формирования магистрального канала ISL в его порту, независимо от состояния соседнего коммутатора.
off. Применение средств ISL в этом порту не разрешено, независимо от настройки конфигурации режима DTP в другом коммутаторе.
В случае создания отдельного магистрального канала корпорация Cisco, как правило, рекомендует задавать режим формирования магистрального канала desirable в конфигурации порта, расположенного ближе к ядру сети, и режим формирования магистрального канала auto — на другом конце канала. Чтобы жестко закодировать режим формирования магистрального канала, необходимо задать в конфигурации портов на обоих концах канала значение этого режима, равное on; для этого потребуется также вручную создать виртуальные локальные сети, трафик которых будет перенаправляться по этому магистральному каналу (с помощью команды set trunk с полным набором опций), и проследить за тем, чтобы на обоих концах физического канала применялись совместимые параметры магистрального канала.
Шаг 6. Выполните эхо-тестирование коммутатора В с коммутатора А, чтобы убедиться в том, что эти коммутаторы могут обмениваться данными по каналу.
Switch-A> ping 172.16.84.18
172.16.84.18 is alive
Switch-A>
Шаг 7. Создайте виртуальную локальную сеть VLAN 2 в коммутаторе А, введя команду set vlan 2 в коммутаторе А. Коммутатор В получит информацию о сети VLAN 2 после формирования домена DTP на шаге 11.
Switch-A> (enable) set vlan 2
Vian 2 configuration successful
Switch-A> (enable)
Шаг 8. Переместите управляющий интерфейс коммутаторов А и В в сеть VLAN 2, созданную на предыдущем шаге. Для этого воспользуйтесь командой set interface scO 2. Ниже показан пример выполнения этой команды в коммутаторе А.
Switch-A> (enable) set int scO 2
Interface scO vlan set.
Switch-A> (enable)
Вызовите на выполнение команду show interface, чтобы просмотреть результаты только что сделанных изменений. Ниже показан пример выполнения этой команды в коммутаторе А.
Switch-A> (enable) sh int
si 0: flags=5KUP, POINTOPOINT, RUNNINO
slip 0.0.0.0 dest 0.0.0.0
scO: flags=6 3<UP, BROADCAST, RUNNINO
vlan 2 inet 172.16.84.17 netmask 255.255.255.0 broadcast 172.16.84.255
Switch-A> (enable)
Шаг 9. Попытайтесь выполнить эхо-тестирование коммутатора в с коммутатора А. Выполнение этой команды должно закончиться неудачей, поскольку управляющие порты теперь находятся в сети VLAN 2, а канал между коммутаторами находится в сети VLAN 1.
Switch-A> (enable) ping 172.16.84.18 no answer from 172.16.84.18
Switch-A> (enable)
Шаг 10. Установите один и тот же домен УТР с именем Cookbook для обоих коммутаторов, введя команду set vtp domain Cookbook в обоих коммутаторах. Switch-A> (enable) set vtp domain Cookbook VTP domain Cookbook modified Switch-A> (enable)
Шаг 11. Разрешите применение средств обмена данными по магистральному каналу между коммутаторами, указав в конфигурации порта 1/1 коммутатора А режим desirable; для этого введите команду set trunk 1/1 desirable в коммутаторе А. Коммутатор в переведет свой порт 1/1 в режим обмена данными по магистральному каналу после завершения согласования опций протокола DTP между двумя коммутаторами.
Switch-A> (enable) set trunk 1/1 desirable
Port(s) 1/1 trunk mode set to desirable.
Switch-A> (enable)
После активизации средств ISL появится следующее сообщение:
1999 Aug 10 15:33:10 %DTP-5-TRUNKPORTON:Port 1/1 has become isl trunk
Возможные сочетания конфигураций DTP
В табл. 23.3 приведено 15 возможных уникальных сочетаний режимов DTP и показано, приводит ли их применение к формированию активного двунаправленного магистрального канала. Хотя теоретически возможно создание магистрального канала только в одном направлении передачи данных по физическому каналу, но не в другом, это не рекомендуется.
^Таблица 23.3. Пятнадцать
возможных уникальных сочетаний режимов. DTP: j
Порт 1/1 коммутатора А
Порт 1/1 коммутатора В
Состояние магистрального канала ISL
Режим auto протокола DTP
Режим auto протокола DTP
Средства формирования магистрального канала не применяются
Режим desirable протокола DTP
Режим auto протокола DTP
Магистральный канал сформирован
Режим on протокола DTP
Режим auto протокола DTP
Магистральный канал сформирован
Режим nonegotiate протокола
DTP
Режим auto протокола DTP
Средства формирования магистрального канала не применяются
Окончание табл. 23.3
Порт 1/1 коммутатора А
Порт 1/1 коммутатора В
Состояние магистрального канала ISL
Режим off протокола DTP
Режим auto протокола DTP
Средства формирования магистрального канала не применяются
Режим desirable протокола
Режим desirable протокола
Магистральный канал сфор-
DTP
DTP
мирован
Режим on протокола DTP
Режим desirable протокола DTP
Средства формирования магистрального канала не применяются
Режим nonegotiate протокола
Режим desirable протокола
Средства формирования ма-
DTP
DTP
гистрального канала не применяются
Режим off протокола DTP
Режим desirable протокола DTP
Средства формирования магистрального канала не применяются
Режим on протокола DTP
Режим on протокола DTP
Магистральный канал сформирован
Режим nonegotiate протокола DTP
Режим on протокола DTP
Магистральный канал сформирован
Режим off протокола DTP
Режим on протокола DTP
Средства формирования магистрального канала не применяются
Режим nonegotiate протокола
Режим nonegotiate протокола
Магистральный канал сфор-
DTP
DTP
мирован
Режим off протокола DTP
Режим nonegotiate протокола DTP
Средства формирования магистрального канала не применяются
Режим off протокола DTP
Режим off протокола DTP
Средства формирования магистрального канала не применяются
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco
Прежде чем обратиться в центр Cisco ТАС, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе своей системы.
Кроме того, выполните следующие действия и подготовьте указанные документы, которые позволят специалистам центра Cisco ТАС быстрее предоставить вам помощь.
Вызовите на выполнение команду show version во всех коммутаторах, с которыми может быть связано рассматриваемое нарушение в работе, и сохраните полученные результаты.
Вызовите на выполнение команду show vtp domain во всех коммутаторах, с которыми может быть связано рассматриваемое нарушение в работе, и сохраните полученные результаты.
Вызовите на выполнение команду show trunk mod_numlport_num во всех портах, с которыми может быть связано рассматриваемое нарушение в работе, и сохраните полученные результаты.
Вызовите на выполнение команду show port mod пит/port num capabilities во всех портах, с которыми может быть связано рассматриваемое нарушение в работе, и сохраните полученные результаты.
Настройка конфигурации канала EtherChannel от коммутатора к коммутатору в устройствах ряда Catalyst 4000/5000/6000
Средства формирования каналов EtherChannel позволяют объединить несколько физических каналов Fast Ethernet или Gigabit Ethernet в один логический канал. Это дает возможность распределить нагрузку по передаче трафика между физическими каналами логического канала, а также обеспечить избыточность на случай выхода из строя одного или нескольких физических каналов логического канала. Каналы EtherChannel могут применяться для соединения LAN-коммутаторов, маршрутизаторов, серверов и клиентов с помощью неэкранированной кабельной разводки на основе витой пары (UTP — Unshielded Twisted-Pair) или одномодовых и многомодовых волоконно-оптических кабелей.
Средства формирования каналов EtherChannel предоставляют удобный способ повышения пропускной способности соединений между важными сетевыми устройствами. На платформе Catalyst 5000 канал может быть сформирован с применением двух портов, в результате чего создается канал на 200 Мбит/с (400 Мбит/с в дуплексном режиме передачи), или с применением четырех портов, в результате чего создается канал на 400 Мбит/с (800 Мбит/с в дуплексном режиме передачи). Некоторые платы и платформы обеспечивают также создание каналов Gigabit EtherChannel и дают возможность использовать для формирования канала EtherChannel от двух до восьми портов. Но общий принцип остается тем же, независимо от скорости передачи или количества применяемых физических каналов. В обычных условиях программные средства протокола распределенного связующего дерева восприняли бы эти избыточные физические каналы между двумя устройствами как предпосылку появления циклов и перевели их в заблокированный режим, в результате чего эти физические каналы стали бы неактивными (предназначенными только для применения в качестве резерва на случай отказа основного физического канала). Но если в коммутаторе эксплуатируется система IOS 3.1.1 или последующих версий, то программное обеспечение протокола распределенного связующего дерева воспринимает логический канал как один мощный физический канал, поэтому все порты логического канала одновременно находятся в активном режиме.
В настоящем разделе описана процедура настройки конфигурации канала EtherChannel между двумя коммутаторами Catalyst 5000 и показан вывод команд, полученный по мере их выполнения. В сценариях, рассматриваемых в настоящей главе, для выполнения тех же действий можно было бы использовать коммутаторы Catalyst 4000 и 6000. В коммутаторах Catalyst 2900XL и 1900/2820 применяются команды с другой синтаксической структурой, но принципы формирования каналов EtherChannel остаются такими же.
Настройка конфигурации канала EtherChannel может быть выполнена вручную, путем ввода соответствующих команд, или автоматически, путем предоставления коммутатору возможности согласовать параметры логического канала с другим уст-
ройством с применением протокола PAgP. Для настройки конфигурации EtherChannel рекомендуется при любой возможности использовать режим desirable протокола PAgP, поскольку настройка конфигурации EtherChannel вручную может быть связана с определенными осложнениями. В настоящем разделе приведены примеры настройки конфигурации EtherChannel вручную и с использованием протокола PAgP. Здесь также описаны способы устранения нарушений в работе каналов EtherChannel и показаны основные способы использования магистральных каналов в сочетании с каналами EtherChannel. В настоящей главе термины EtherChannel, Fast EtherChannel, Gigabit EtherChannel и логический канал относятся к каналу EtherChannel.
Содержание раздела
В настоящем разделе рассматриваются следующие темы.
Задачи настройки конфигурации EtherChannel вручную.
Проверка конфигурации EtherChannel.
Применение протокола PAgP для автоматической настройки конфигурации EtherChannel (предпочтительный метод).
Совместное применение магистральных каналов и каналов EtherChannel.
Устранение нарушений в работе каналов EtherChannel.
Команды, применяемые в настоящем разделе.
На рис. 23.6 приведена схема испытательной среды. Конфигурация коммутаторов очищена с помощью команды clear config all. Затем изменен формат приглашения к вводу команд с использованием команды set system name. После этого коммутаторам присвоены IP-адрес и маска для применения в целях управления; для этого в коммутаторе А выполнена команда set int scO 172.16.84.6 255.255.255.0, а в коммутаторе В — команда set int scO 172.16.84.17 255.255.255.0, Для обоих коммутаторов назначен шлюз, применяемый по умолчанию, с помощью команды set ip route default 172.16.84.1.
Конфигурации коммутаторов очищены для того, чтобы можно было приступить к работе с исходных позиций. Коммутаторам присвоены разные имена, чтобы можно было различать их по приглашению к вводу команд в командной строке. IP-адреса были назначены с тем, чтобы иметь возможность выполнять взаимное эхо-тестирование коммутаторов в целях проверки связи. Шлюз, заданный по умолчанию, не использовался.
Коммутатор АКоммутатор В
172.16.84.6/24172.16.84.17/24
Рис. 23.6. Испытательная среда
Многие из рассматриваемых команд выводят больше результатов, чем требуется для данного описания, поэтому лишний вывод был удален.
Задачи настройки конфигурации EtherChannel вручную
Для настройки конфигурации EtherChannel вручную необходимо выполнить следующие действия.
Определить версию IOS и состав модулей, применяемых в испытательной среде.
Проверить, поддерживают ли порты средства EtherChannel.
Убедиться в том, что порты соединены между собой и работоспособны.
Проверить, имеют ли группируемые порты одинаковые параметры настройки.
Определить допустимые группы портов.
Создать логический канал.
Поэтапная процедура
На консоли коммутаторов А и В выполните следующие действия.
Шаг 1. Вызовите на выполнение команду show version, чтобы определить версию программного обеспечения, эксплуатируемого в коммутаторе. Для получения перечня модулей, установленных в коммутаторе, введите команду show module.
Switch-А show version
WS-C5505 Software, Version McpSW: 4.5(1) NmpSW: 4.5(1)
Copyright (c) 1995-1999 by Cisco Systems
Switch-А show module
Mod Module-NamePorts Module-TypeModel Serial-Num Status
10Supervisor IIIWS-X5530 006841805 ok
22410/100BaseTX Ethernet WS-X5225R 012785227 ok
Шаг 2. Проверьте, поддерживают ли порты средства EtherChannel. Команда show port capabilities предусмотрена в версиях 4.x и последующих версиях. Если у вас имеется система IOS с версией, предшествующей 4.x, пропустите этот шаг. Поддержка средств EtherChannel обеспечивается не во всех модулях Fast Ethernet. Одни из первых модулей с поддержкой EtherChannel имели надпись "Fast EtherChannel" в левом нижнем углу (на лицевой панели модуля, установленного в коммутаторе), которая свидетельствовала о том, что это средство поддерживается. Но в следующих версиях модулей от применения этих надписей отказались. Модули, применяемые в данной испытательной среде, не имеют надписи "Fast EtherChannel", но поддерживают это средство.
Switch-А show port capabilities
ModelPortTypeSpeedDuplexTrunk encap typeTrunk modeChannelBroadcast suppressionFlow controlModelPortTypeSpeedDuplexTrunk encap typeTrunk modeChannelBroadcast suppressionFlow controlWS-X5225R
Model
Port
Type
Speed
Duplex
Trunk encap type
Trunk mode
Channel
Broadcast suppression
Flow control
Model
Port
Type
Speed
Duplex
Trunk encap type
Trunk mode
Channel
Broadcast suppression
Flow control
2/1
10/lOOBaseTX
auto,10,100
half,full
802.1Q,ISL
on,off,desirable,auto,nonegotiate
2/1-2,2/1-4
percentage(0-100)
receive-(off,on),send-(off,on)
Security
yes
Membership
static,dynamic
Fast start
yes
Rewrite
yes
Switch-В show port capabilities
Model
WS-X5234
Port
2/1
Type
10/100BaseTX
Speed
auto,10,100
Duplex
half,full
Trunk encap type
802.1Q,ISL
Trunk mode
on,off,desirable,auto,nonegotiate
Channel
2/1-2,2/1-4
Broadcast suppression
percentage(O-lOO)
Flow control
receive-(off,on),send-(off,on)
Security
yes
Membership
static,dynamic
Fast start
yes
Rewrite
no
Если порт не поддерживает средства EtherChannel, то вывод команды show port capabilities выглядит примерно так:
Switch show port capabilities
Model
Port
Type
Speed
Duplex
Trunk encap type
Trunk mode
Channel
Broadcast suppression
Flow control
Security
Membership Fast start
WS-X5213A
2/1
10/lOOBaseTX
10,100,auto
half,full ISL
on,off,desirable,auto,nonegotiate no
pps(0-150000) no
yes
static,dynamic yes
Шаг 3. Убедитесь в том, что порты соединены между собой и работоспособны. Перед подключением кабелей каждый порт находится в таком состоянии:
Switch-А show port
Port Name
Status
Vian
Level Duplex Speed Type
2/1
notconnect
1
normal
auto
auto 10/100BaseTX
2/2
notconnect
1
normal
auto
auto 10/100BaseTX
2/3
notconnect
1
normal
auto
auto 10/100BaseTX
2/4
notconnect
1
normal
auto
auto 10/100BaseTX
После установки кабелей между двумя коммутаторами каждый порт находится в следующем состоянии:
1999Dec1420:32:44%PAGP-5-PORTTOSTP:Port2/1joinedbridgeport2/1
1999Dec1420:32:44%PAGP-5-PORTTOSTP:Port2/2joinedbridgeport2/2
1999Dec1420:32:44%PAGP-5-PORTTOSTP:Port2/3joinedbridgeport2/3
1999Dec1420:32:44%PAGP-5-PORTTOSTP:Port2/4joinedbridgeport2/4
Switch-А show port
Port
Name
Status
Vian
Level
Duplex Speed Type
2/1
connected
1
normal
а-full a-100 10/100BaseTX
2/2
connected
1
normal
а-full a-100 10/lOOBaseTX
2/3
connected
1
normal
а-full a-100 10/100BaseTX
2/4
connected
1
normal
а-full a-100 10/100BaseTX
Switch-В show port
Port
Name
Status
Vian
Level
Duplex Speed Type
2/1
connected
1
normal
а-full a-100 10/100BaseTX
2/2
connected
1
normal
а-full a-100 10/100BaseTX
2/3
connected
1
normal
а-full a-100 10/100BaseTX
2/4
connected
1
normal
а-full a-100 10/100BaseTX
Поскольку конфигурации коммутаторов были очищены перед началом этой проверки, порты находятся в состоянии, предусмотренном по умолчанию. Все они относятся к сети vlanl, а параметры скорости и режима передачи имеют значения auto. После подключения кабелей порты согласуют между собой скорость 100 Мбит/с и дуплексный режим передачи. Они переходят в подключенное состояние (connected), поэтому может быть выполнено эхо- тестирование другого коммутатора.
Switch-А ping 172.16.84.17
172.16.84.17 is alive
В конкретной сети может потребоваться установить вручную значения параметров скорости, равные 100 Мбит/с, и задать применение дуплексного режима передачи, а не рассчитывать на то, что эти параметры будут установлены в результате автоматического согласования, поскольку это позволяет добиться того, чтобы порты всегда работали на максимальной скорости. Процесс автоматического согласования рассматривается в разделе “Устранение нарушений в работе средств автоматического согласования дуплексного/полудуплексного режима передачи на скорости 10/100 Мбит/с”.
Шаг 4. Проверьте, имеют ли группируемые порты одинаковые параметры настройки. Эта задача является очень важной и будет рассматриваться более подробно в разделе с описанием процедуры устранения нарушений в работе канала EtherChannel. Если выполнение команды по формированию канала EtherChannel оканчивается неудачей, то причина этого обычно связана с тем, что порты, применяемые для формирования логического канала, имеют разные конфигурации. Это относится не только к портам, находящимся на раз-
ных концах физических каналов, но и к локальным портам. В данном случае конфигурации коммутаторов были очищены до начала эксперимента, поэтому порты находятся в состояниях, предусмотренных по умолчанию. Все они относятся к сети VLAN 1, параметрам скорости и режима передачи присвоены значения auto, и все параметры распределенного связующего дерева для каждого порта являются одинаковыми. Как показывает приведенный выше вывод команды, после подключения кабелей порты согласуют между собой применение скорости 100 Мбит/с и дуплексного режима передачи. Поскольку протокол распределенного связующего дерева применяется для каждой виртуальной локальной сети, проще всего выполнить лишь настройку конфигурации логического канала и ответить на сообщения об ошибках, чем пытаться проверять соответствие полей диагностики распределенного связующего дерева для каждого порта и каждой виртуальной локальной сети в логическом канале.
Шаг 5. Определите допустимые группы портов. В коммутаторе Catalyst 5000 в логический канал могут быть объединены только некоторые порты. Такие ограничительные зависимости не распространяются на все платформы. В частности, порты логического канала в коммутаторе Catalyst 5000 должны быть смежными. Как показывают результаты выполнения команды show port capabilities для порта 2/1, допустимыми сочетаниями являются следующие:
Switch-А show port capabilities
ModelWS-X5225R
Port2/1
Channel2/1-2,2/1-4
Обратите внимание, что этот порт может входить в группу из двух портов (2/1—2) или в группу из четырех портов (2/1—4). Соблюдение этих ограничений, налагаемых на конфигурацию каналов, обеспечивается с помощью контроллера ЕВС (Ethernet Bundling Controller — контроллер формирования логических каналов Ethernet) данного модуля. Рассмотрим еще один порт.
Switch-А show port capabilities 2/3
ModelWS-X5225R
Port2/3
Channel2/3-4,2/1-4
Этот порт может входить в группу из двух портов (2/3—4) или в группу из четырех портов (2/1-4).
Примечание
Некоторые версии аппаратных средств налагают дополнительные ограничения. При использовании определенных модулей (WS-X5201 и WS-X5203) невозможно сформировать канал EtherChannel, включив последние два порта в так называемую “группу портов", если первые два порта в группе еще не образуют канал EtherChannel. Гоуп- пой портов называется ряд портов, которые могут применяться для формирования канала EtherChannel (в предыдущем примере допустимую группу портов составляли порты 2/1-4). Например, если создаются отдельные каналы EtherChannel только с двумя портами в каждом логическом канале, невозможно назначить порты 2/3-4 логи-
ческому каналу, не выполнив вначале настройку конфигурации портов 2/1-2 для использования в логическом канале в модулях, имеющих это ограничение. Аналогичным образом, перед настройкой конфигурации портов 2/6-7 необходимо настроить конфигурацию портов 2/5-6. Это ограничение не распространяется на модули, рассматриваемые в настоящей главе (WS-X5225R, WS-X5234).
Поскольку в данном случае выполняется настройка конфигурации группы из четырех портов (2/1—4), они имеют допустимый состав группы. Но в группу из четырех портов нельзя включить порты 2/3—6. Эти порты расположены смежно, но не начинаются с допустимого начального номера, как показывает вывод команды show port capabilities (допустимые группы могут составлять порты 1—4, 5—8, 9—12, 13—16, 17—20 и 21—24).
Шаг 6. Создайте логический канал. Для создания канала необходимо вызвать на выполнение команду set port channel <mod/port> в каждом коммутаторе. Перед тем как разрешить применение канала EtherChannel вручную, рекомендуется отключить порты на одном конце логического канала с помощью команды set port disable. Это позволит избежать в процессе настройки конфигурации проблем, связанных с функционированием протокола распределенного связующего дерева. Программное обеспечение протокола распределенного связующего дерева может закрыть некоторые порты (перевести их в состояние errdisable), если сначала будет выполнена настройка конфигурации портов на использование в качестве логического канала с одного конца физического канала, и только после этого появится возможность выполнить настройку конфигурации портов на применение в составе логического канала портов, находящихся на другом конце физического канала. В связи с тем, что возможно такое развитие ситуации, для создания каналов EtherChannel гораздо проще применить протокол PAgP, как будет описано в разделе “Применение протокола PAgP для автоматической настройки конфигурации EtherChannel (предпочтительный метод)’’, приведенном ниже в данной главе. Для предотвращения развития такой ситуации при настройке конфигурации канала EtherChannel вручную здесь будут закрыты порты в коммутаторе А, выполнена настройка конфигурации логического канала в коммутаторе А, затем — настройка конфигурации логического канала в коммутаторе В, и только после этого будет разрешено применение портов коммутатора А.
Вначале следует убедиться в том, что средства формирования логических каналов не используются.
Switch-А (enable) show port channel No ports channelling
Switch-В (enable) show port channel No ports channelling
Теперь закроем порты коммутатора А и оставим их в этом состоянии до тех пор, пока не будет выполнена настройка конфигурации обоих коммутаторов на использование канала EtherChannel, для того, чтобы программное обеспечение протокола распределенного связующего дерева не активизировало сообщения об ошибках и не закрыло эти порты.
Switch-А (enable) set port disable 2/1-4
Ports 2/1-4 disabled.
[Эти строки выведены на коммутаторе SwitchA после закрытия портов]
1999
Dec 15 00:06:40 %PAGP-5-PORTFROMSTP:Port 2/1 left bridgl
1999
Dec 15 00:06:40 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/2
1999
Dec 15 00:06:40 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
1999
Dec 15 00:06:40 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4
Для
коммутатора А установите значение режима использования логического
канала, равное on.
Switch-А (enable) set port channel 2/1-4 on
Port(s) 2/1-4 channel mode set to on.
Проверьте состояние канала. Следует отметить, что значение режима использования логического канала было установлено равным on, но порты находятся в состоянии disabled (поскольку их применение перед этим было запрещено). В данный момент логический канал не функционирует, но станет работоспособным после того, как будет разрешено применение портов.
Switch-А (enable) show port channel
Port StatusChannel Channel
Neighbor
Neighbor
modestatus
device
port
2/1
disabled
on
channel
2/2
disabled
on
channel
2/3
disabled
on
channel
2/4
disabled
on
channel
Поскольку порты коммутатора А были (на время) запрещены для применения, порты коммутатора в больше не участвуют в соединении. После запрета применения портов коммутатора А на консоли коммутатора в отображается следующее сообщение.
Switch-В (enable)
2000 Jan 13 22:30:03 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1
2000 Jan 13 22:30:04 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/2
2000 Jan 13 22:30:04 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
2000 Jan 13 22:30:04 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4
Для коммутатора в установите параметр режима применения логического ка-
нала в значение on.
Switch-В (enable) set port channel 2/1-4 on
Port(s) 2/1-4 channel mode set to on.
Проверьте, установлено ли значение on режима применения логического канала для коммутатора В.
Switch-В (enable) show port channel
Port Status Channel Channel NeighborNeighbor
mode status deviceport
2/1
notconnect on
channel
2/2
notconnect on
channel
2/3
notconnect on
channel
2/4
notconnect on
channel
Обратите внимание, что режим применения логического канала для коммутатора В имеет значение on, но порты находятся в состоянии notconnect (не подключены). Это связано с тем, что порты коммутатора А все еще отключены.
Наконец, на последнем этапе необходимо разрешить применение портов коммутатора А.
Switch-А (enable) set port enable 2/1-4
Ports 2/1-4 enabled.
1999 Dec
15
00:08:40
%PAGP-5-PORTTOSTP:Port
2/1
joined bridge port
2/1-4
1999 Dec
15
00:08:40
%PAGP-5-PORTTOSTP:Port
2/2
joined bridge port
2/1-4
1999 Dec
15
00:08:40
%PAGP-5-PORTTOSTP:Port
2/3
joined bridge port
2/1-4
1999 Dec
15
00:08:40
%PAGP-5-PORTTOSTP:Port
2/4
joined bridge port
2/1-4
Проверка конфигурации EtherChannel
Чтобы убедиться в том, что настройка конфигурации логического канала выполнена правильно, вызовите на выполнение команду show port channel.
Switch-А (enable) show port channel
Port
Status
Channel mode
Channel status
Neighbor device
Neighbor port
2/1
connected
on
channel
WS-C5505
066509957(Sw
2/1
2/2
connected
on
channel
WS-C5505
066509957(Sw
2/2
2/3
connected
on
channel
WS-C5505
066509957(Sw
2/3
2/4
connected
on
channel
WS-C5505
066509957(Sw
2/4
Switch-В (enable) show port channel
Port
Status
Channel mode
Channel status
Neighbor device
Neighbor port
2/1
connected
on
channel
WS-C5505
066507453(Sw
2/1
2/2
connected
on
channel
WS-C5505
066507453(Sw
2/2
2/3
connected
on
channel
WS-C5505
066507453(Sw
2/3
2/4
connected
on
channel
WS-C5505
066507453(Sw
2/4
Как показывают результаты выполнения следующей команды, программным обеспечением протокола распределенного связующего дерева все эти порты воспринимаются как один логический порт. В приведенном выше выводе порт обозначен как 2/1—4, а это означает, что программное обеспечение протокола распределенного связующего дерева обрабатывает трафик, проходящий через порты 2/1, 2/2, 2/3 и 2/4, таким образом, как если бы этот трафик проходил через один порт.
Switch-А (enable) show spantree
VLAN 1
Spanning tree enabled
Spanning tree type
ieee
Designated Root
00-10-0d-b2-8c-00
Designated Root Priority
32768
Designated Root Cost
8
Designated Root Port
2/1-4
Root Max Age 20 sec
Hello Time 2 sec Forward Delay 15 sec
Bridge ID MAC ADDR
00-90-92-b0-84-00
Bridge ID Priority
32768
Bridge Max Age 20 sec
Hello Time 2 sec Forward Delay 15 sec
Port Vian Port-State Cost Priority Fast-Start Group-Method
2/1-4 1 forwarding 8 32 disabled channel
Канал EtherChannel может быть реализован с применением разных способов распределения трафика по портам канала. Спецификация EtherChannel не содержит никаких указаний в отношении того, как должен распределяться трафик по физическим каналам одного логического канала. В коммутаторе Catalyst 5000 используется последний бит или последние 2 бита (в зависимости от того, сколько физических каналов входит в логический канал) МАС-адресов отправителя и получателя фрейма, чтобы определить, какой порт в канале должен использоваться. Поэтому должны наблюдаться примерно одинаковые объемы трафика через каждый из портов логического канала, при условии, что трафик вырабатывается с нормальным распределением МАС-адресов на каждом конце канала. Чтобы проверить, проходит ли трафик через все порты канала, примените команду show mac. А если порты были активными до настройки конфигурации EtherChannel, то счетчики трафика необходимо сбросить в нулевое значение с помощью команды clear counters. После этого показатели объема трафика будут показывать, как действительно распределяется трафик в канале EtherChannel.
В рассматриваемой испытательной среде нельзя получить реальное распределение, поскольку в ней отсутствуют рабочие станции, серверы или маршрутизаторы, которые вырабатывали бы разнообразный трафик. Единственными устройствами, создающими трафик, являются сами коммутаторы. Было выполнено несколько команд эхо- тестирования коммутатора В с коммутатора А, и результаты выполнения следующей команды показывают, что для этого одноадресатного трафика используется первый порт канала. В данном случае информация о количестве полученных фреймов (Rcv- Unicast) показывает, каким образом коммутатор В распределял трафик по логическому каналу к коммутатору А. В приведенных здесь результатах есть таблица с информацией о количестве переданных фреймов (Xmit-Unicast), которая позволяет определить, каким образом коммутатор А распределял трафик по портам логического канала к коммутатору В. Вывод этой команды также показывает, что через все четыре порта проходит небольшой объем многоадресатного трафика, вырабатываемого коммутаторами (трафик протоколов Dynamic ISL, CDP). Широковещательные пакеты представляют собой запросы ARP (направленные к шлюзу, предусмотренному по умолчанию,
который в данной конкретной испытательной среде не используется). Если бы к получателям, находящимся на другом конце логического канала, отправляли свои пакеты через коммутатор рабочие станции, то вероятность того, что трафик будет проходить через все четыре физических канала данного логического канала, была бы выше. Вы можете проследить за распределением пакетов в своей сети с помощью команды show mac.
Switch-А (enable) clear counters
This command will reset all MAC and port counters reported in CLI and SNMP.
Do you want to continue (y/n) [nJ? у MAC and Port counters cleared.
Switch-А (enable) show mac
Port
Rcv-Unicast
Rcv-Multicast
Rcv-Broadcast
2/1
9
320
183
2/2
0
51
0
2/3
0
47
0
2/4 (...)
0
47
0
Port
Xmit-Unicast
Xmit-Multicast
Xmit-Broadcast
2/1
8
47
184
2/2
0
47
0
2/3
0
47
0
2/4 (...)
0
47
0
Port
Rcv-Octet
Xmit-Octet
2/1
35176
17443
2/2
5304
4851
2/3
5048
4851
2/4
5048
4851
(...)
Last-Time-Cleared
Wed Dec 15 1999, 01:05:33
Применение протокола PAgP для автоматической настройки конфигурации EtherChannel (предпочтительный метод)
Протокол PAgP обеспечивает автоматическое создание каналов EtherChannel путем обмена пакетами между портами, способными участвовать в создании логических ка-
налов. Этот протокол предусматривает динамическое определение возможностей групп портов и передачу необходимой информации соседним портам.
При обнаружении программным обеспечением PAgP правильно составленных пар физических каналов, которые могут применяться для формирования логического канала, оно группирует соответствующие порты в виде одного логического канала. Затем этот логический канал добавляется к распределенному связующему дереву как один порт моста. Каждый конкретный исходящий широковещательный или многоад- ресатный пакет передается только через один физический порт логического канала, а не через каждый его порт. Кроме того, исходящие широковещательные и многоадре- сатные пакеты, передаваемые через один порт канала, блокируются таким образом, чтобы не происходил их возврат через любой другой порт того же канала.
Предусмотрено четыре режима настройки конфигурации логического канала, определяемые пользователем: on, off, auto и desirable. Обмен пакетами PAgP между портами осуществляется только в режимах auto и desirable. Порты с конфигурацией, настроенной на использование режимов on или off, не обмениваются пакетами PAgP. Рекомендуемые значения параметров настройки для коммутаторов, между которыми должен быть сформирован канал EtherChannel, предусматривают перевод обоих коммутаторов в режим desirable. Такое режим обеспечивает наиболее надежное функционирование логического канала в том случае, если в устройстве, находящемся на одном его конце, обнаружатся аварийные ситуации, или если это устройство будет перезагружено. По умолчанию для режима формирования логического канала устанавливается значение auto.
И режим auto, и режим desirable позволяют портам проводить согласование параметров с подключенными к ним портами, чтобы определить, могут ли они сформировать логический канал с учетом таких критериев, как скорость порта, состояние поддержки магистрального канала, исходная виртуальная локальная сеть и т.д.
Порты могут сформировать канал EtherChannel и в том случае, если они находятся в разных режимах формирования логического канала, при условии, что эти режимы совместимы. Примеры совместимых и несовместимых режимов приведены ниже.
Порт в режиме desirable может успешно сформировать канал EtherChannel с другим портом, который находится в режиме desirable или auto.
Порт в режиме auto может сформировать канал EtherChannel с другим портом, находящимся в режиме desirable.
Порт в режиме auto не может сформировать канал EtherChannel с другим портом, который также находится в режиме auto, поскольку ни один из этих портов не может инициализировать согласование параметров канала.
Порт в режиме on может сформировать канал только с портом, который также находится в режиме on, поскольку порты в режиме on не обмениваются пакетами PAgP.
Порт в режиме off не может сформировать канал с любым другим портом.
Если при использовании средств EtherChannel отображается сообщение системного журнала "SPANTREE-2: Channel misconfig - х/х-х will be disabled" или аналогичное сообщение, оно указывает на несоответствие режимов EtherChannel в подключенных портах. В таких случаях рекомендуется откорректировать конфигурацию и снова разрешить применение портов путем ввода команды set port enable. Ниже перечислены допустимые конфигурации EtherChannel.
Режим порта логического каналаРежим порта логического каналаДопустимый ражим (режимы) сосаднего порта логического канала
Режим порта логического канала
Режим порта логического канала
desirable или auto desirable или autoonoffdesirable или auto desirable или autoonoffdesirable
desirable или auto desirable или auto
on
off
desirable или auto desirable или auto
on
off
auto (значение по умолчанию)
on
off
В табл. 23.4 приведены сводные данные по всем возможным вариантам применения режимов формирования логического канала. При некоторых сочетаниях режимов программное обеспечение протокола распределенного связующего дерева переводит порты на одном из концов канала в состояние errdisable (иными словами, закрывает эти порты).
, Таблица 23.4.Сводные данныепо е
РежимРежим
геем возможным вариантам
Состояние логического канала
формирования логического канала коммутатором А
формирования логического канала коммутатором В
on
on
Логический канал формируется
on
off
Логический канал не формируется (errDisable)
on
auto
Логический канал не формируется (errDisable)
on
desirable
Логический канал не формируется (errDisable)
off
on
Логический канал не формируется (errDisable)
off
off
Логический канал не формируется
off
auto
Логический канал не формируется
off
desirable
Логический канал не формируется
auto
on
Логический канал не формируется (errDisable)
auto
off
Логический канал не формируется
auto
auto
Логический канал не формируется
auto
desirable
Логический канал формируется
desirable
on
Логический канал не формируется (errDisable)
desirable
off
Логический канал не формируется
desirable
auto
Логический канал формируется
desirable
desirable
Логический канал формируется
В предыдущем примере логический канал был отключен в результате выполнения следующей команды в коммутаторах А и В:
Switch-А (enable) set port channel 2/1-4 auto
Port(s) 2/1-4 channel mode set to auto.
По умолчанию для порта, способного сформировать логический канал, применяется режим auto формирования логического канала. Для проверки этого введите следующую команду:
Switch-А (enable) show port channel 2/1
Port Status Channel Channel NeighborNeighbor
mode status deviceport
2/1 connected auto not channel
Приведенная выше команда показывает также, что в настоящее время порты не образуют канала. Еще один способ проверки состояния логического канала заключается в следующем:
Switch-А (enable) show port channel
No ports channelling
Switch-В (enable) show port channel
No ports channelling
Способ формирования логического канала с помощью протокола PAgP фактически является наиболее простым. К этому моменту оба коммутатора переведены в режим auto, а это означает, что они сформируют между собой логический канал, если через один из соединенных портов будут передаваться запросы PAgP на формирование логического канала. Если коммутатор А будет переведен в режим desirable, это приведет к тому, что он начнет передавать другому коммутатору пакеты PAgP с запросами на формирование логического канала.
Switch-А (enable) set port channel 2/1-4 desirable Port(s) 2/1-4 channel mode set to desirable.
1999
Dec
15
22:03:18
%PAGP-5-PORTFROMSTP:Por t
2/1
left
bridgl
1999
Dec
15
22:03:18
%PAGP-5-PORTFROMSTP:Port
2/2
left
bridge port
2/2
1999
Dec
15
22:03:18
%PAGP-5-PORTFROMSTP:Port
2/3
left
bridge port
2/3
1999
Dec
15
22:03:18
%PAGP-5-PORTFROMSTP:Port
2/4
left
bridge port
2/4
1999
Dec
15
22:03:19
%PAGP-5-PORTFROMSTP:Port
2/2
left
bridge port
2/2
1999
Dec
15
22:03:19
%PAGP-5-PORTFROMSTP:Port
2/3
left
bridge port
2/3
1999
Dec
15
22:03:20
%PAGP-5-PORTFROMSTP:Port
2/4
left
bridge port
2/4
1999
Dec
15
22:03:23
%PAGP-5-PORTTOSTP:Port 2/1 joined bridge port
2/1-4
1999
Dec
15
22:03:23
%PAGP-5-PORTTOSTP:Port 2/2 joined bridge port
2/1-4
1999
Dec
15
22:03:23
%PAGP-5-PORTTOSTP:Port 2/3 joined bridge port
2/1-4
1999
Dec
15
22:03:24
%PAGP-5-PORTTOSTP:Port 2/4 joined bridge port
2/1-4
Для просмотра состояния этого логического канала выполните
следующее:
Switch-A (enable) show port channel
Port StatusChannel Channel
Neighbor
Neighbor
modestatus
device
port
2/1
connected
desirable channel
WS-C5505
066509957(Sw
2/1
2/2
connected
desirable channel
WS-C5505
066509957(Sw
2/2
2/3
connected
desirable channel
WS-C5505
066509957(Sw
2/3
2/4
connected
desirable channel
WS-C5505
066509957(Sw
2/4
Поскольку коммутатор В находился в режиме auto, он ответил на пакеты PAgP и сформировал логический канал с коммутатором А.
Switch-В (enable)
2000 Jan1420:26:41%PAGP-5-PORTFROMSTP:Port2/1leftbridgl
2000 Jan1420:26:41%PAGP-5-PORTFROMSTP:Port2/2leftbridgeport2/2
2000 Jan1420:26:41%PAGP-5-PORTFROMSTP:Port2/3leftbridgeport2/3
2000 Jan1420:26:41%PAGP-5-PORTFROMSTP:Port2/4leftbridgeport2/4
2000 Jan1420:26:45%PAGP-5-PORTFROMSTP:Port2/2leftbridgeport2/2
2000 Jan1420:26:45%PAGP-5-PORTFROMSTP:Port2/3leftbridgeport2/3
2000 Jan1420:26:45%PAGP-5-PORTFROMSTP:Port2/4leftbridgeport2/4
2000 Jan1420:26:47%PAGP-5-PORTTOSTP:Port2/1joinedbridgeport2/1-4
2000 Jan1420:26:47%PAGP-5-PORTTOSTP:Port2/2joinedbridgeport2/1-4
2000 Jan1420:26:47%PAGP-5-PORTTOSTP:Port2/3joinedbridgeport2/1-4
2000 Jan1420:26:48%PAGP-5-PORTTOSTP:Port2/4joinedbridgeport2/1-4
Switch-В (enable) show port channel
Port
Status
Channel mode
Channel status
Neighbor device
Neighbor port
2/1
connected
auto
channel
WS-C5505
066507453(Sw
2/1
2/2
connected
auto
channel
WS-C5505
066507453(Sw
2/2
2/3
connected
auto
channel
WS-C5505
066507453(Sw
2/3
2/4
connected
auto
channel
WS-C5505
066507453(Sw
2/4
Примечание
Рекомендуется переводить в режим desirable коммутаторы, находящиеся на обоих концах канала, чтобы оба эти устройства предпринимали попытки инициировать создание канала в том случае, если одно из устройств перейдет на какое-то время в нерабочее состояние. Порты EtherChannel коммутатора В можно перевести в режим desirable без каких-либо затруднений, даже если канал в настоящее время является активным и находится в режиме auto. Ниже показана применяемая для этого команда.
Switch-В (enable) set port channel 2/1-4 desirable Port(s) 2/1-4 channel mode set to desirable.
Switch-В (enable) show port channel
Port
StatusChannel ChannelNeighborNeighbor
modestatusdeviceport
2/1
2/2
2/3
2/4
connecteddesirablechannelWS-C5505066507453(Sw2/1
connecteddesirablechannelWS-C5505066507453(Sw2/2
connecteddesirablechannelWS-C5505066507453(Sw2/3
connecteddesirablechannelWS-C5505066507453(Sw2/4
Если теперь работа коммутатора А по какой-либо причине будет прервана или он будет заменен новым устройством, то попытки снова восстановить логический канал будут предприниматься коммутатором В. А если новое устройство не способно сфор-
мировать логический канал, то коммутатор В будет рассматривать его порты 2/1—4 как обычные порты, не поддерживающие средства EtherChannel. В этом состоит одно из преимуществ использования режима desirable. Если настройка конфигурации логического канала была выполнена с использованием режима on протокола PAgP и в устройстве, находящемся на одном конце канала, возникла какая-то ошибка или произошел сброс, это может вызвать переход устройства, находящегося на другом конце канала, в состояние errDisable (останов этого устройства). Если же в обоих устройствах, соединенных каналом, установлен режим desirable протокола PAgP, то в логическом канале вновь будет выполнено согласование характеристик соединения EtherChannel и он перейдет в устойчивое состояние.
Средства формирования магистральных каналов и каналов EtherChannel
Функционирование средств EtherChannel не зависит от функционирования средств формирования магистральных каналов. При использовании логических каналов магистральные каналы могут по-прежнему применяться для обмена данными. Можно также разрешить применение средств формирования магистральных каналов для всех портов перед созданием логического канала или после создания логического канала (как показано в настоящем разделе). Если речь идет о каналах EtherChannel, то для них это не имеет никакого значения; средства формирования магистральных каналов и каналов EtherChannel являются полностью независимыми. Имеет значение лишь то, что все рассматриваемые при этом порты должны находиться в одном и том же режиме: до начала выполнения настройки конфигурации логического канала во всех этих портах должны либо применяться, либо не применяться средства формирования магистральных каналов. Перед созданием логического канала все применяемые при этом порты должны находиться в одном и том же состоянии поддержки магистрального канала.
После формирования логического канала любые изменения, происходящие в одном порту, отражаются на других портах этого логического канала. Модули, применяемые в данной испытательной среде, позволяют формировать магистральные каналы ISL или 802. lq. По умолчанию эти модули переведены в режим auto формирования магистрального канала и режим negotiate, а это означает, что они формируют магистральный канал, если порт, находящийся на другом конце физического канала, передает им запрос на формирование магистрального канала, и что они проводят согласование того, должен ли применяться метод ISL или 802. lq формирования магистрального канала. Если эти порты не получают запрос на формирование магистрального канала, они функционируют как обычные порты, не обмениваясь данными по магистральному каналу.
Switch-А (enable) show trunk 2
Native vlan
Port
Mode
Encapsulation
Status
2/1
auto
negotiate
not-trunking
1
2/2
auto
negotiate
not-trunking
1
2/3
auto
negotiate
not-trunking
1
2/4
auto
negotiate
not-trunking
1
Предусмотрено несколько разных способов разрешить применение средств формирования магистральных каналов. В данном примере коммутатор А, который находится в режиме negotiate, будет переведен в режим desirable. В результате применения со-
четания режимов desirable/negotiate коммутатор А вынужден передать коммутатору В запрос на формирование магистрального канала и согласование метода формирования магистрального канала (ISL или 802. lq). Поскольку в коммутаторе В по умолчанию применяется режим автоматического согласования autonegotiate, коммутатор В отвечает на запрос коммутатора А. Ниже приведены полученные при этом результаты.
Switch-А (enable) set trunk 2/1 desirable
Port(s) 2/1-4 trunk mode set to desirable.
Switch-А (enable)
1999 Dec 18 20:46:25 %DTP-5-TRUNKPORTON:Port 2/1 has become isl trunk
1999 Dec 18 20:46:25 %DTP-5-TRUNKPORTON:Port 2/2 has become isl trunk
1999 Dec 18 20:46:25 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1-4
1999 Dec 18 20:46:25 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/1-4
1999 Dec 18 20:46:25 %DTP-5-TRUNKPORTON:Port 2/3 has become isl trunk
1999 Dec 18 20:46:26 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/1-4
1999 Dec 18 20:46:26 %DTP-5-TRUNKPORTON:Port 2/4 has become isl trunk
1999 Dec 18 20:46:26 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/1-4
1999 Dec 18 20:46:28 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1-4
1999 Dec 18 20:46:29 %PAGP-5-PORTTOSTP:Port 2/2 joined bridge port 2/1-4
1999 Dec 18 20:46:29 %PAGP-5-PORTTOSTP:Port 2/3 joined bridge port 2/1-4
1999 Dec 18 20:46:29 %PAGP-5-PORTTOSTP:Port 2/4 joined bridge port 2/1-4
Switch-А (enable) show trunk 2
Port
Mode
Encapsulation
Status
Native vlan
2/1
desirable
n-isl
trunking
1
2/2
desirable
n-isl
trunking
1
2/3
desirable
n-isl
trunking
1
2/4
desirable
n-isl
trunking
1
Установлен режим формирования магистрального канала desirable. Результатом этого стало то, что с соседним коммутатором был согласован режим формирования магистрального канала и совместно было принято решение использовать метод ISL (n-isl). Теперь текущим состоянием стало trunking. Ниже показано, что происходит в коммутаторе В в результате выдачи команды в коммутаторе А.
Switch-В (enable)
2000 Jan 17 19:09:52 %DTP-5-TRUNKPORTON:Port 2/1 has become isl trunk
2000 Jan 17 19:09:52 %DTP-5-TRUNKPORTON:Port 2/2 has become isl trunk
2000 Jan 17 19:09:52 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1-4
2000 Jan 17 19:09:52 %DTP-5-TRUNKPORTON:Port 2/3 has become isl trunk
2000 Jan 17 19:09:52 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/1-4
2000 Jan 17 19:09:53 %DTP-5-TRUNKPORTON:Port 2/4 has become isl trunk
2000 Jan 17 19:09:53 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/1-4
2000 Jan 17 19:09:53 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/1-4
2000 Jan1719:09:55%PAGP-5-PORTTOSTP:Port2/1joinedbridgeport2/1-4
2000 Jan1719:09:55%PAGP-5-PORTTOSTP:Port2/2joinedbridgeport2/1-4
2000 Jan1719:09:55%PAGP-5-PORTTOSTP:Port2/3joinedbridgeport2/1-4
2000 Jan1719:09:55%PAGP-5-PORTTOSTP:Port2/4joinedbridgeport2/1-4
Switch-В (enable) show trunk 2
Port
Mode
Encapsulation
Status
Native vlan
2/1
auto
n-isl
trunking
1
2/2
auto
n-isl
trunking
1
2/3
auto
n-isl
trunking
1
2/4
auto
n-isl
trunking
1
Обратите внимание, что во всех четырех портах (2/1—4) сформировались магистральные каналы, даже несмотря на то, что мы намеренно перевели в режим desirable только один порт (2/1). Это — пример того, как изменение состояния одного порта в логическом канале влияет на все порты.
Устранение нарушений в работе средств EtherChannel
Основные сложности, с которыми приходится сталкиваться при использовании средств EtherChannel, можно разделить на две категории: устранение нарушений, возникающих на этапе настройки конфигурации, и устранение нарушений в процессе эксплуатации. Ошибки в конфигурации обычно возникают из-за несогласованности параметров применяемых портов (разные скорости, разные режимы передачи, различные значения портов распределенного связующего дерева и т.д.). Но ошибки в процессе настройки конфигурации могут также появляться, если после настройки логического канала на одном конце соединения возникает слишком продолжительная пауза до начала настройки конфигурации логического канала на другом конце соединения. При таких обстоятельствах в распределенном связующем дереве создаются циклы, в результате чего активизируются ошибки и порт закрывается.
При обнаружении любой ошибки в процессе настройки конфигурации EtherChannel обязательно проверьте состояние портов после исправления ошибочной ситуации, связанной с применением средств EtherChannel. Если порт находится в состоянии errdisable, это означает, что он был закрыт программным обеспечением и не будет работать до тех пор, пока не будет выполнена команда set port enable.
Примечание
Если порт перешел в состояние errdisable, необходимо специально разрешить применение этого порта, выполнив для этого порта команду set port enable, чтобы перевести его в активное состояние. Текущие версии программного обеспечения позволяют исправить нарушения в работе средств EtherChannel, но порты не активизируются и не формируют логический канал до тех пор, пока не будут снова разрешены для применения. В будущих версиях операционной системы должна быть предусмотрена периодическая автоматическая проверка того, следует ли разрешить применение портов, переведенных в состояние errdisable.
Ниже описан ряд проверок, при которых будет отменено использование магистральных каналов и каналов EtherChannel, и рассматриваются следующие темы.
Применение несогласованных параметров конфигурации.
Возникновение слишком продолжительной паузы до начала настройки конфигурации устройства на другом конце канала.
Выход из состояния errdisable. .
Анализ ситуации, возникающей при разрыве и восстановлении физического канала.
Применение несогласованных параметров конфигурации
В настоящем разделе рассматривается пример применения несогласованных параметров. Здесь будет задана принадлежность порта 2/4 к сети VLAN 2, в то время как другие порты будут по-прежнему находиться в сети VLAN 1. Для создания новой виртуальной локальной сети необходимо назначить домен VTP для коммутатора, а затем создать эту виртуальную локальную сеть.
Switch-А (enable) show port channel
No ports channelling
Switch-А (enable) show port
Port Name
Status
Vlan
Level
Duplex Speed Type
2/1
connected
1
normal
a-full
a-100
10/lOOBaseTX
2/2
connected
1
normal
a-full
a-100
10/100BaseTX
2/3
connected
1
normal
a-full
a-100
10/100BaseTX
2/4
connected
1
normal
a-full
a-100
10/100BaseTX
Switch-А (enable) set vlan 2
Cannot add/modify VLANs on a VTP server without a domain name.
Switch-А (enable) set vtp domain testDomain
VTP domain testDomain modified
Switch-А (enable) set vlan 2 name vlan2
Vian 2 configuration successful
Switch-А (enable) set vlan 2 2/4
VLAN 2 modified.
VLAN 1 modified.
VLAN Mod/Ports
22/4
Switch-А (enable)
1999 Dec 19 00:19:34 %PAGP-5-PORTFROMSTP:Port 2/4 left bridg4
Switch-А (enable) show port
Level
Duplex Speed Type
Port Name
Status
Vlan
2/1
connected
1
normal
a-full a-100 10/100BaseTX
2/2
connected
1
normal
a-full a-100 10/100BaseTX
2/3
connected
1
normal
a-full a-100 10/100BaseTX
2/4
connected
2
normal
a-full a-100 10/100BaseTX
Switch-А (enable) set port channel 2/1-4 desirable
Port(s) 2/1-4 channel mode set to desirable.
Switch-А (enable)
1999Dec1900:20:19%PAGP-5-PORTFROMSTP:Port2/1leftbridgeport2/1
1999Dec1900:20:19%PAGP-5-PORTFROMSTP:Port2/2leftbridgeport2/2
1999Dec1900:20:19%PAGP-5-PORTFROMSTP:Port2/3leftbridgeport2/3
1999Dec1900:20:20%PAGP-5-PORTFROMSTP:Port2/4leftbridgeport2/4
1999Dec1900:20:20%PAGP-5-PORTFROMSTP:Port2/2leftbridgeport2/2
1999Dec1900:20:22%PAGP-5-PORTFROMSTP:Port2/3leftbridgeport2/3
1999Dec1900:20:22%PAGP-5-PORTFROMSTP:Port2/4leftbridgeport2/4
1999Dec1900:20:24%PAGP-5-PORTTOSTP:Port2/1joinedbridgeport2/1-2
1999Dec1900:20:25%PAGP-5-PORTTOSTP:Port2/2joinedbridgeport2/1-2
1999Dec1900:20:25%PAGP-5-PORTTOSTP:Port2/3joinedbridgeport2/3
1999Dec1900:20:25%PAGP-5-PORTTOSTP:Port2/4joinedbridgeport2/4
Neighbor portNeighbor portSwitch-А (enable) show port channel
Neighbor port
Neighbor port
Port Status Channel Channel Neighbor mode status device
2/1connecteddesirable channelWS-C5505066509957(Sw2/1
2/2connecteddesirable channelWS-C5505066509957(Sw2/2
Обратите внимание, что канал сформирован только между портами 2/1 и 2/2. Порты 2/3 и 2/4 не вошли в его состав, поскольку порт 2/4 находится в другой виртуальной локальной сети. Сообщение об ошибке не появилось; просто программное обеспечение PAgP выполнило все от него зависящее для обеспечения работы логического канала. Это означает, что после создания логического канала следует всегда контролировать полученные результаты, чтобы убедиться в том, что было выполнено все, что задумано.
Теперь попытаемся установить логический канал вручную при том условии, что порт 2/4 находится в другой виртуальной локальной сети, и проверим, что при этом произойдет. Вначале снова установим режим auto логического канала, чтобы стереть существующий логический канал, а затем установим вручную режим on логического канала.
Switch-А (enable) set port channel 2/1-4 auto
Port(s) 2/1-4 channel mode set to auto.
Switch-А (enable)
1999Dec1900:26:08%PAGP-5-PORTFROMSTP:Port2/1leftbridgeport2/1-2
1999Dec1900:26:08%PAGP-5-PORTFROMSTP:Port2/2leftbridgeport2/1-2
1999Dec1900:26:08%PAGP-5-PORTFROMSTP:Port2/3leftbridgeport2/3
1999Dec1900:26:08%PAGP-5-PORTFROMSTP:Port2/4leftbridgeport2/4
1999Dec1900:26:18%PAGP-5-PORTTOSTP:Port2/1joinedbridgeport2/1
1999Dec1900:26:19%PAGP-5-PORTTOSTP:Port2/2joinedbridgeport2/2
1999Dec1900:26:19%PAGP-5-PORTTOSTP:Port2/3joinedbridgeport2/3
1999Dec1900:26:19%PAGP-5-PORTTOSTP:Port2/4joinedbridgeport2/4
Switch-А (enable) show port channel
No ports channelling
Switch-А (enable) set port channel 2/1-4 on
Mismatch in vlan number.
Failed to set port(s) 2/1-4 channel mode to on.
Switch-А (enable) show port channel
No ports channelling
В коммутаторе В режим on логического канала устанавливается успешно; обратите внимание, что результаты выполнения команд показывают, что порты готовы к формированию логического канала, но нам известно, что настройка конфигурации коммутатора А выполнена неправильно.
Switch-В (enable) show port channel
No ports channelling
Switch-В (enable) show port
Port Name
Status
Vian
Level
Duplex Speed Type
2/1
connected
1
normal
a-full
a-100
10/100BaseTX
2/2
connected
1
normal
a-full
a-100
10/100BaseTX
2/3
connected
1
normal
a-full
a-100
10/100BaseTX
2/4
connected
1
normal
a-full
a-100
10/100BaseTX
Switch-В (enable) set port channel 2/1-4 on
Port(s) 2/1-4 channel mode set to on.
Switch-В (enable)
2000 Jan1722:54:59%PAGP-5-PORTFROMSTP:Port2/1leftbridgeport2/1
2000 Jan1722:54:59%PAGP-5-PORTFROMSTP:Port2/2leftbridgeport2/2
2000 Jan1722:54:59%PAGP-5-PORTFROMSTP:Port2/3leftbridgeport2/3
2000 Jan1722:54:59%PAGP-5-PORTFROMSTP:Port2/4leftbridgeport2/4
2000 Jan1722:55:00%PAGP-5-PORTTOSTP:Port2/1joinedbridgeport2/1-4
2000 Jan1722:55:00%PAGP-5-PORTTOSTP:Port2/2joinedbridgeport2/1-4
2000 Jan1722:55:00%PAGP-5-PORTTOSTP:Port2/3joinedbridgeport2/1-4
2000 Jan1722:55:00%PAGP-5-PORTTOSTP:Port2/4joinedbridgeport2/1-4
Switch-В (enable) show port channel
Port
Status
Channel mode
Channel status
Neighbor device
Neighbor port
2/1
connected
on
channel
WS-C5505
066507453(Sw
2/1
2/2
connected
on
channel
WS-C5505
066507453(Sw
2/2
2/3
connected
on
channel
WS-C5505
066507453(Sw
2/3
2/4
connected
on
channel
WS-C5505
066507453(Sw
2/4
Приведенная выше проверка показывает, что при настройке конфигурации логического канала вручную необходимо проверить устройства на обоих концах канала, чтобы
убедиться в том, что оба они готовы к работе, а не ограничиваться проверкой одного устройства. Приведенные выше результаты свидетельствуют о том, что коммутатор В готов к созданию логического канала, а коммутатор А не способен его сформировать, поскольку один из портов находится не в той виртуальной локальной сети, в какой следует.
Возникновение слишком продолжительной паузы до начала настройки конфигурации устройства на другом конце канала
Выше описана ситуация, в которой коммутатор В был готов к формированию канала EtherChannel, а коммутатор А не был к этому подготовлен, поскольку в его конфигурации была ошибка, связанная с определением принадлежности портов к виртуальной локальной сети (порты 2/1—3 находятся в сети VLAN 1, а порт 2/4 — в сети VLAN 2). Ниже показано, что происходит, если в устройстве на одном конце соединения будет установлен режим on канала EtherChannel, а устройство на другом конце соединения все еще будет находиться в режиме auto: через несколько минут коммутатор В закроет свои порты, поскольку в распределенном связующем дереве обнаружится цикл. Это связано с тем, что порты 2/1—4 коммутатора В действуют как один большой порт, а порты 2/1—4 коммутатора А все еще остаются полностью независимыми портами. Широковещательный пакет, переданный из коммутатора В в коммутатор А через порт 2/1, будет отправлен назад в коммутатор В через порты 2/2, 2/3, и 2/4, поскольку коммутатор А рассматривает эти порты как независимые. Именно поэтому программное обеспечение коммутатора В определит, что в распределенном связующем дереве возникли циклы. Обратите внимание, что порты коммутатора В теперь закрыты и имеют состояние errdisable.
Switch-В (enable)
2000 Jan 17 22:55:48 %SPANTREE-2-CHNMISCFG: STP loop - channel 2/1-4 is disabled in vlan 1.
2000 Jan1722:55:49%PAGP-5-PORTFROMSTP:Port2/1leftbridgeport2/1-4
2000 Jan1722:56:01%PAGP-5-PORTFROMSTP:Port2/2leftbridgeport2/1-4
2000 Jan1722:56:13%PAGP-5-PORTFROMSTP:Port2/3leftbridgeport2/1-4
2000 Jan1722:56:36%PAGP-5-PORTFROMSTP:Port2/4.leftbridgeport2/1-4
Switch-В (enable) show port channel
Port
Status
Channel mode
Channel status
Neighbor device
Neighbor port
2/1
errdisable
on
channel
2/2
errdisable
on
channel
2/3
errdisable
on
channel
2/4
errdisable
on
channel
Switch-В (enable) show port
Port Name
StatusVianLevel Duplex Speed Type
2/1
2/2
2/3
2/4
errdisable 1 normal auto auto 10/lOOBaseTX errdisable 1 normal auto auto 10/100BaseTX errdisable 1 normal auto auto 10/100BaseTX errdisable 1 normal auto auto 10/100BaseTX
Выход из состояния errdisable
Иногда при попытке настроить конфигурацию EtherChannel, притом что не все применяемые для этого порты имеют одинаковую конфигурацию, может возникнуть такая ситуация, что все порты на одном конце соединения логического канала закроются. В таком порту индикатор канала горит желтым светом. Состояние такого порта можно также определить с консоли, введя команду show port. Закрытые порты будут указаны, как имеющие состояние errdisable. Для выхода из этой ситуации необходимо исправить несогласованные параметры рассматриваемых портов, а затем снова разрешить их применение. Но следует учитывать, что повторное разрешение применения этих портов — это отдельный этап, который должен быть выполнен для того, чтобы порты снова перешли в рабочее состояние.
В рассматриваемом примере известно, что в коммутаторе А имеется несоответствие применяемых виртуальных локальных сетей, поэтому необходимо перейти к коммутатору А и снова включить порт 2/4 в состав сети VLAN 1. После этого можно установить режим on для логического канала, в который входят порты 2/1—4. Коммутатор А не покажет, что он подключен, до тех пор, пока снова не будет разрешено применение портов коммутатора В. Таким образом, после исправления конфигурации коммутатора А и перевода его в режим поддержки логического канала необходимо перейти к коммутатору В и снова разрешить применение его портов.
Switch-А (enable) set vlan 1 2/4
VLAN 1 modified.
VLAN 2 modified.
VLAN Mod/Ports
12/1-24
Switch-А (enable) set port channel 2/1-4 on
Port(s) 2/1-4 channel mode set to on.
Switch-А (enable) sh port channel
Port
StatusChannel ChannelNeighborNeighbor
modestatusdeviceport
2/1
2/2
2/3
2/4
notconnect on channel notconnect on channel notconnect on channel notconnect on channel
Switch-В (enable) show port channel
Port
StatusChannel ChannelNeighborNeighbor
modestatusdeviceport
2/1
2/2
2/3
2/4
errdisable on channel errdisable on channel errdisable on channel errdisable on channel
Switch-В (enable) set port enable 2/1-4
Ports 2/1-4 enabled.
Switch-В(enable) 2000 Jan 17 23:15:22 %PAGP-5-PORTTOSTP:Port2/1joined bridg4
2000 Jan1723:15:22%PAGP-5-PORTTOSTP:Port2/2joinedbridgeport2/1-4
2000 Jan1723:15:22%PAGP-5-PORTTOSTP:Port2/3joinedbridgeport2/1-4
2000 Jan1723:15:22%PAGP-5-PORTTOSTP:Port2/4joinedbridgeport2/1-4
Switch-В (enable) show port channel
Port
StatusChannel ChannelNeighborNeighbor
modestatusdeviceport
2/1
2/2
2/3
2/4
connected on channel connected on channel connected on channel connected on channel
Анализ ситуации, возникающей при разрыве и восстановлении физического канала
Если отключается один из портов логического канала, то любые пакеты, которые при обычных обстоятельствах были бы переданы через этот порт, перебрасываются на следующий порт в канале. С помощью команды show mac можно убедиться в том, что это действительно происходит. В применяемой испытательной среде на первом этапе будет предусмотрена передача пакетов эхо-тестирования с коммутатора А на коммутатор в, чтобы определить, какой физический канал применяется для этого трафика. Вначале очистим все счетчики, затем вызовем на выполнение команду show mac, передадим три пакета эхо-тестирования, после чего снова выполним команду show mac, чтобы определить, по какому физическому каналу были получены ответы на пакеты эхо-тестирования.
Switch-А (enable) clear counters
This command will reset all MAC and port counters reported in CLI and SNMP.
Do you want to continue (y/n) [n]? у MAC and Port counters cleared.
Switch-А (enable) show port channel
Port
Status
Channel mode
Channel status
Neighbor device
Neighbor port
2/1
connected
on
channel
WS-C5505
066509957(Sw
2/1
2/2
connected
on
channel
WS-C5505
066509957(Sw
2/2
2/3
connected
on
channel
WS-C5505
066509957(Sw
2/3
2/4
connected
on
channel
WS-C5505
066509957(Sw
2/4
Switch-А (enable) show mac
Port Rcv-Unicast
Rcv-Multicast
Rcv-Broadcast
2/1
0
18
0
2/2
0
2
0
2/3
0
2
0
2/4
0
2
0
Switch-А (enable) ping 172.16.84.17 is alive
172.16.84.17
Switch-А (enable) ping 172.16.84.17 is alive
172.16.84.17
Switch-А (enable) ping 172.16.84.17 is alive
172.16.84.17
Switch-А (enable) show
mac
Port Rcv-Unicast
Rcv-Multicast
Rcv-Broadcast
2/1
3
24
0
2/2
0
2
0
2/3
0
2
0
2/4
0
2
0
Итак, к данному моменту получены три ответа на пакеты эхо-тестирования через порт 3/1, поэтому при передаче ответа от коммутатора В коммутатору А по каналу EtherChannel применяется порт 2/1. Теперь закроем порт 2/1 в коммутаторе В. На коммутаторе А еще раз вызовем на выполнение команду эхо-тестирования ping и проверим, по какому физическому каналу поступают назад ответы. (Коммутатор А передает запросы через тот же порт, к которому подключен коммутатор В. Здесь показаны только пакеты, полученные от коммутатора В, поскольку информация о переданных пакетах находится гораздо ниже в этом выводе команды show mac.)
1999 Dec 19 01:30:23 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1-4
Switch-А (enable) ping 172.16.84.17
172.16.84.17 is alive
Switch-А (enable) show mac
Port Rcv-UnicastPort Rcv-Unicast2/12/22/32/42/12/22/32/4Rcv-Multicast Rcv-Broadcast
Port Rcv-Unicast
Port Rcv-Unicast
2/1
2/2
2/3
2/4
2/1
2/2
2/3
2/4
3370
1270
070
070
Обратите внимание, что теперь, когда порт 2/1 закрыт, канал EtherChannel автоматически переходит к использованию следующего порта канала, 2/2. Теперь снова разрешим применение порта 2/1 и подождем, пока он присоединится к этой группе мостовых соединений; затем вызовем на выполнение еще две команды ping.
1999 Dec 19 01:31:33 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1-4
Switch-А (enable) ping 172.16.84.17
172.16.84.17 is alive
Switch-А (enable) ping 172.16.84.17
172.16.84.17 is alive
Switch-А (enable) show mac
Port Rcv-UnicastRcv-Multicast Rcv-Broadcast
2/15500
2/21490
2/30120
2/40120
Здесь заслуживает внимания тот факт, что и эти пакеты эхо-тестирования передавались через порт 2/1, поэтому после восстановления физического канала средства EtherChannel снова добавили его к связке физических каналов и ввели в эксплуатацию, причем все эти действия были выполнены незаметно для пользователя.
Команды, применяемые для настройки конфигруации
Ниже перечислены команды, применяемые для настройки конфигурации, и описано их назначение.
set port channel on. Разрешает использование средств EtherChannel.
set port channel auto. Применяется для переустановки портов в заданный по умолчанию режим auto.
set port channel desirable. Обеспечивает передачу другому участнику пакетов PAgP с запросами на создание канала.
set port enable. Разрешает применение портов после выполнения команды set port disable или после их перехода в состояние errdisable.
set port disable. Предназначена для отключения портов на время выполнения настройки других параметров конфигурации.
set trunk desirable. Разрешает применение средств магистрального канала и обеспечивает передачу портом на другой коммутатор запроса на формирование магистрального канала, и если для этого порта установлен режим negotiate (применяемый по умолчанию), обеспечивает согласование применяемого в канале метода обмена данными по магистральному каналу (1SL или 802. lq).
Ниже перечислены команды, применяемые для проверки конфигурации.
show version. Позволяет определить версию программного обеспечения, эксплуатируемую в коммутаторе.
show module. Служит для проверки состава модулей, установленных в коммутаторе.
show port capabilities. Позволяет получить информацию о том, обладают ли предназначенные для использования порты способностью сформировать канал EtherChannel.
show port. Позволяет определить состояние порта (неподключенный, подключенный), а также параметры настройки скорости и режима передачи.
ping. Применяется для проверки связи с другим коммутатором.
show port channel. Позволяет определить текущее состояние логического канала EtherChannel.
show port channel mod/port. Предназначена для получения более подробных сведений о состоянии логического канала отдельного порта.
show spantree. Позволяет проверить, рассматривается ли данный логический канал программным обеспечением протокола распределенного связующего дерева как один физический канал.
show trunk. Применяется для проверки состояния средств поддержки магистрального канала в портах.
Ниже перечислены команды, предназначенные для устранения нарушений в работе, связанных с ошибками в конфигурации.
show port channel. Позволяет определить текущее состояние логического канала EtherChannel.
show port. Позволяет определить состояние порта (неподключенный, подключенный), а также параметры настройки скорости и режима передачи.
clear counters. Применяется для переустановки счетчиков пакетов коммутатора в нулевые значения. Для просмотра показаний счетчиков предназначена команда show mac.
show mac. Позволяет просматривать информацию о пакетах, полученных и переданных коммутатором.
ping. Предназначена для проверки связи с другим коммутатором и выработки трафика, прохождение которого может быть обнаружено с помощью команды show mac.
Применение PortFast и других команд для устранения нарушений в работе, характеризующихся отсутствием связи с оконечной станцией после запуска
Если рабочие станции, подключенные к коммутаторам, либо не способны зарегистрироваться в сетевом домене (NT или Novell), либо не могут получить адрес DHCP, то для устранения такого нарушения в работе следует вначале попытаться воспользоваться рекомендациями, приведенными в настоящей главе, и только после этого принимать другие меры. Эти рекомендации можно выполнить относительно просто, и они чаще всего позволяют полностью устранить причины нарушений связи, возникающих на этапе инициализации или запуска рабочей станции.
В последнее время широкое распространение получает такая организация локальных сетей, при которой хосты подключаются непосредственно к коммутаторам, а концентраторы, создающие домены коллизий, больше не применяются. Но в процес-
се создания канала между хостом и коммутатором может возникать более значительная задержка, поэтому представители службы технической поддержки все чаше сталкиваются с проблемами, возникающими в среде клиент/сервер из-за такой первоначальной задержки. При этом наиболее серьезная проблема состоит в том, что клиенты Windows 95/98/NT, Novell, VINES, IBM NetworkStation/IBM Thin Clients и AppleTalk не могут подключиться к серверам. Причина этого заключается в следующем: если программное обеспечение этих хостов не рассчитано на то, что при выполнении процедуры запуска могут возникать значительные задержки, оно отказывается от дальнейших попыток установить соединение с сервером еще до того, как коммутатор даже просто откроет путь для прохождения трафика.
Примечание
Такая первоначальная задержка при установлении связи часто проявляет себя как ошибка, которая обнаруживается при первоначальной загрузке рабочей станции. Ниже приведено несколько примеров сообщений об ошибках и наблюдаемых при этом ошибок.
Сетевой клиент Microsoft выводит сообщение "No Domain Controllers Available".
Программное обеспечение протокола DHCP сообщает: "No DHCP Servers Available".
После начальной загрузки сетевой рабочей станции, работающей по протоколу Novell IPX, не отображается окно регистрации "Novell Login Screen".
Сетевой клиент AppleTalk выводит сообщение об ошибке "Access to your AppleTalk network has been interrupted. To re-establish your connection, open and close the AppleTalk control panel" (Доступ к сети AppleTalk был прерван. Чтобы восстановить соединение, откройте и закройте панель управления AppleTalk). Возможна также ситуация, когда приложение Chooser клиента AppleTalk либо не отображает список зон, либо отображает неполный список зон.
Кроме того, первоначальная задержка при установлении связи часто наблюдается в коммутируемой среде, в которой сетевой администратор обновляет программное обеспечение или драйверы. В таком случае может оказаться, что поставщик драйвера настолько оптимизировал его работу, что процедуры инициализации сети выполняются еще до того, как начнется процесс запуска клиента (притом что коммутатор даже еще не перешел в состояние готовности к обработке пакетов).
В некоторых коммутаторах теперь предусмотрено так много разных средств, что для них может потребоваться почти целая минута для подготовки к обслуживанию вновь подключенной рабочей станции. Эта задержка отражается на функционировании рабочей станции после каждого ее включения или перезагрузки. Ниже перечислены четыре основные процедуры, которые могут вызвать указанную задержку.
Применение средств протокола распределенного связующего дерева.
Согласование параметров канала EtherChannel.
Согласование параметров магистрального канала.
Согласование скорости канала и режима передачи между коммутатором и рабочей станцией.
Эти четыре процедуры перечислены в порядке уменьшения продолжительности задержки; применение средств протокола распределенного связующего дерева вызывает наибольшую задержку, а согласование скорости и режима передачи — наимень-
шую. Подключение рабочей станции к коммутатору обычно не вызывает появления циклов в распределенном связующем дереве, для нее, как правило, не требуется создавать канал EtherChannel и чаще всего не нужно согласовывать метод формирования магистрального канала. (Отмена согласования скорости канала и режима передачи может также способствовать уменьшению задержки порта, если поставлена задача свести время запуска к минимуму.)
В настоящем разделе показано, как применяются команды оптимизации скорости запуска на трех платформах коммутатора Catalyst. В разделах с описанием результатов измерения времени показано, как и насколько можно уменьшить задержку порта коммутатора.
Содержание
В настоящем разделе рассматриваются следующие темы.
Общие сведения.
Способы сокращения задержек при запуске в коммутаторе Catalyst 4000/5000/6000.
Измерение продолжительности задержки в коммутаторе Catalyst 5000.
Способы сокращения задержек при запуске в коммутаторе Catalyst 29OOXL/35OOXL.
Измерение продолжительности задержки в коммутаторе Catalyst 2900XL.
Способы сокращения задержек при запуске в коммутаторе Catalyst 1900/2800.
Измерение продолжительности задержки в коммутаторе Catalyst 1900.
Дополнительные преимущества применения средства PortFast.
В настоящем разделе термины хост, рабочая станция, оконечная станция и сервер используются как взаимозаменяемые для обозначения любого устройства, непосредственно подключенного к коммутатору с помощью одной сетевой платы. Этими терминами могут также обозначаться устройства с несколькими сетевыми платами, в которых дополнительные сетевые платы используются только для обеспечения избыточности, иными словами, конфигурация рабочей станции или сервера не настроена на применение этого устройства в качестве моста; в них несколько сетевых плат установлено для резервирования.
Примечание .
Некоторые серверные сетевые платы поддерживают средства формирования магистральных каналов или каналов EtherChannel. В определенных ситуациях сервер должен находиться одновременно в нескольких виртуальных локальных сетях (для этого нужен магистральный канал) или должна быть увеличена пропускная способность канала, соединяющего сервер с коммутатором (для этого необходимо создать канал EtherChannel). В подобных случаях не следует отключать средства РАдР, а также средства формирования магистральных каналов. Кроме того, такие устройства, как серверы, выключаются или перезагружаются очень редко. Инструкции, приведенные в настоящей главе, не распространяются на устройства подобного типа.
Общие сведения
В настоящем разделе рассматриваются четыре средства, предусмотренные в некоторых коммутаторах, которые могут вызывать первоначальные задержки при подключении определенных устройств к коммутатору. Обычно подключение рабочей станции не становится причиной появления проблем с распределенным связующим деревом
(циклов), а также не требует применения некоторых средств (PAgP, DTP), поэтому существует возможность исключить появление соответствующих задержек.
Распределенное связующее дерево
Пользователи сети, в которой начался переход от сетевой среды, основанной на использовании концентраторов, к среде, в основе которой лежит применение коммутаторов, иногда сталкиваются с проблемами нарушения связи, поскольку коммутатор функционирует во многом иначе, чем концентратор. Коммутатор обеспечивает связь на уровне канала передачи данных, а не на физическом уровне. В коммутаторе для определения того, какие пакеты, полученные через некоторый порт, должны быть переданы через другой порт, должен применяться алгоритм мостового перенаправления. Но при наличии физических циклов в сетевой топологии работа алгоритма мостового перенаправления нарушается. Поскольку циклы нарушают работу сети, в коммутаторах должен эксплуатироваться так называемый протокол распределенного связующего дерева, который обеспечивает устранение циклов в топологии сети. В результате функционирования этого протокола активизация всех портов, охваченных процессом формирования распределенного связующего дерева, происходит намного медленнее, чем обычно, поскольку на выявление и блокирование циклов с помощью этого протокола затрачивается время. Без формирования распределенного связующего дерева работа сети, соединенной мостами, в которой имеются физические циклы, становится невозможной. Поэтому применение протокола распределенного связующего дерева является необходимым, несмотря на все связанные с этим затраты времени. Процесс формирования распределенного связующего дерева, осуществляемый в коммутаторах Catalyst, регламентируется спецификацией, принятой в качестве промышленного стандарта (IEEE 802.Id).
После создания канала передачи данных с портом коммутатора и его присоединения к группе мостов в этом порту выполняется алгоритм протокола распределенного связующего дерева. Порт, в котором выполняется алгоритм распределенного связующего дерева, может находиться в одном из пяти состояний: заблокированный, принимающий данные, обучающийся, перенаправляющий и закрытый. Согласно определению протокола распределенного связующего дерева, порт должен начинать работу с заблокированного состояния, а затем немедленно переходить к выполнению этапов приема пакетов и обучения. По умолчанию примерно 15 секунд затрачивается на прием пакетов и 15 секунд — на обучение.
Находясь в состоянии приема пакетов, коммутатор пытается определить, не нарушает ли он топологию распределенного связующего дерева. На этом этапе особенно важно определить, не составляет ли конкретный порт часть физического цикла. Если порт наряду с другими портами образует цикл, то именно он может быть выбран для перевода в блокирующий режим. Блокирующий режим предусматривает, что порт ради устранения циклов не должен передавать или принимать пользовательские данные. Если же порт не входит в состав цикла, то он переходит в состояние обучения, при котором в порту происходит сбор данных о том, какие МАС-адреса имеют пакеты, передаваемые через этот порт. Таким образом, весь процесс инициализации распределенного связующего дерева занимает около 30 секунд.
Если к порту коммутатора подключается рабочая станция или сервер с одной сетевой платой, то такое соединение вообще не может явиться причиной создания физического цикла. Устройства, с которыми создаются такие соединения, рассматриваются как лист-узлы графа сети. Для подобной рабочей станции не имеет смысла ожидать в течение 30 секунд, пока коммутатор выполнит проверку на наличие циклов, посколь-
ку рабочая станция не может создать цикл. Поэтому корпорация Cisco ввела дополнительное средство под названием PortFast (или Fast-Start), которое позволяет указать программному обеспечению алгоритма распределенного связующего дерева, что данный порт не может стать причиной возникновения цикла и поэтому должен немедленно переходить в состояние перенаправления, минуя заблокированное состояние, состояние приема пакетов и обучения. Это позволяет сэкономить очень много времени. Применяемая при этом команда не отменяет использование алгоритма распределенного связующего дерева. Она просто указывает, что при выполнении алгоритма распределенного связующего дерева в выбранном порту необходимо с самого начала пропустить несколько этапов (которые не требуются в этих обстоятельствах).
Примечание
Средство PortFast ни в коем случае не должно применяться в портах коммутатора, подключенных к другим коммутаторам, концентраторам или маршрутизаторам. Такие соединения могут стать причиной возникновения физических циклов, поэтому очень важно, чтобы в подобных ситуациях процесс формирования распределенного связующего дерева прошел через начальную процедуру инициализации. При наличии в распределенном связующем дереве единственного цикла работа сети может полностью прекратиться. Если применение средства PortFast разрешено для порта, который входит в состав физического цикла, это можвт вызвать на время появление такой ситуации, что пакеты будут непрерывно перенаправляться по циклу (и даже дублироваться) таким образом, что нормальная работа сети не может быть восстановлена. В новейших выпусках программного обеспечения операционной системы Catalyst (например 5.4(1)) предусмотрено так называемое средство PortFast BPDU-Guard, которое позволяет обнаружить поступление пакетов BPDU в порты, для которых разрешено применение средства PortFast. Поскольку такая ситуация не должна возникать, средство BPDU-Guard переводит подобный порт в состояние errDisable.
Средство формирования каналов EtherChannel
Еще одно средство, которое может быть предусмотрено в коммутаторе, носит название EtherChannel (Fast EtherChannel или Gigabit EtherChannel). Это средство позволяет обеспечить работу нескольких физических каналов между одними и теми же двумя устройствами по такому принципу, как если бы они представляли собой один быстрый канал, с уравновешиванием трафика между физическими каналами. Коммутатор может формировать такие логические каналы с соседним устройством автоматически с помощью так называемого протокола PAgP. Порты коммутатора, в котором эксплуатируется программное обеспечение PAgP, обычно переведены по умолчанию в пассивный режим, называемый auto, а это означает, что эти порты готовы сформировать логический канал, если соответствующий запрос будет получен от соседнего устройства, с которым они соединены с помощью нескольких физических каналов. Вызов на выполнение программного обеспечения этого протокола в режиме auto может вызвать появление задержки в порту на время, достигающее 15 секунд, перед передачей управления программному обеспечению алгоритма распределенного связующего дерева (программное обеспечение PAgP должно выполнить в порту необходимые операции еще до вызова на выполнение программного обеспечения алгоритма распределенного связующего дерева). Но в порту, подключенном к рабочей станции, нет никакой необходимости вызывать на выполнение программное обеспечение PAgP, по-
этому рекомендуется устранить связанную с этим задержку, установив значение off режима PAgP для соответствующего порта коммутатора. ■
Средство формирования магистрального канала
Еще одно средство коммутатора позволяет использовать порт для формирования магистрального канала. Магистральный канал между двумя устройствами устанавливается в тех случаях, если по этому каналу должен проходить трафик многих виртуальных локальных сетей. Виртуальная локальная сеть формируется коммутаторами для определения группы рабочих станций, входящих в состав отдельного сегмента или широковещательного домена. Магистральные порты позволяют создавать виртуальные локальные сети устройств, подключенных к нескольким коммутаторам, что дает возможность покрыть одной виртуальной локальной сетью всю территорию, охваченную одной объединенной сетью. Функционирование виртуальных локальных сетей основано на использовании специальных маркеров, прикрепляемых к пакетам, которые указывают, к какой виртуальной локальной сети относится каждый пакет.
Предусмотрено несколько типов протоколов обмена данными по магистральным каналам. Если порт может использоваться в качестве магистрального, то в нем может быть также предусмотрена возможность сформировать магистральный канал автоматически, а в некоторых случаях даже согласовать способ поддержки обмена данными по магистральному каналу для использования в данном порту. Такая способность согласовывать способ поддержки магистрального канала с другим устройством основана на использовании протокола DTP, предшественником которого был протокол DISL. Если применяются такие протоколы, то в порту коммутатора перед переходом его в активное состояние может возникнуть задержка.
Как правило, порт, подключенный по каналу к рабочей станции, относится только к одной виртуальной локальной сети, поэтому для него не нужно создавать магистральный канал. А если порт обладает способностью участвовать в согласовании параметров формирования магистрального канала, он обычно по умолчанию переводится в режим auto. Но если для порта, подключенного к рабочей станции, для режима формирования магистрального канала установлено значение off, это приводит к дальнейшему уменьшению задержки перед переходом порта коммутатора в активное состояние.
Согласование скорости и режима передачи
Обычно достаточно разрешить применение средства PortFast и запретить применение средства PAgP (если оно предусмотрено) для того, чтобы решить проблему, но если приходится экономить каждую секунду, то еще одна возможность состоит в установке на коммутаторе вручную скорости порта и режима передачи, если этот порт поддерживает несколько скоростей (10/100). Средство автоматического согласования является очень удобным, но его отмена позволяет сэкономить только 2 секунды при использовании коммутатора Catalyst 5000 (и почти ничего не дает, если применяется коммутатор 2800 или 2900XL).
Если средство автоматического согласования будет отключено в коммутаторе, но останется активным в рабочей станции, могут возникнуть сложности. Поскольку коммутатор не сможет согласовывать режим передачи с клиентской станцией, в последней может быть выбран иной режим передачи, чем в коммутаторе. (Описание проблем, связанных с применением средства автоматического согласования, приведе-
но выше, в разделе “Устранение нарушений в работе средств автоматического согласования дуплексного/полудуплексного режима передачи на скорости 10/100 Мбит/с’’.)
Способы сокращения задержек при запуске в коммутаторе Catalyst 4000/5000/6000
Ниже перечислены пять команд, позволяющих разрешить применение средства PortFast, отменить согласование опций PAgP, согласование опций формирования магистрального канала (DISL, DTP) и согласование скорости и режима передачи. Команда set spantree portfast может быть вызвана на выполнение сразу для целого ряда портов (set spantree portfast 2/1-12 enable). Обычно в команде set port channel для отмены средств формирования логических каналов должна указываться допустимая группа портов, способных к формированию логических каналов. В приведенном ниже примере модуль 2 обладает способностью формировать логический канал с применением портов 2/1—2 или портов 2/1—4, поэтому в качестве параметра команды отмены допускается применение любой из этих групп портов.
Примечание
В версии 5.2 операционной системы Catalyst OS для коммутатора Catalyst 4000/5000 предусмотрена новая команда set port host, которая представляет собой макрокоманду, объединяющую в одной команде три команды: set spantree portfast, set port channel off, set trunk off.
Настройка конфигурации
Для сокращения задержки при запуске рабочих станций, которые подключаются к коммутаторам Catalyst 4000/5000/6000, применяются следующие команды:
Switch-А (enable) set spantree portfast 2/1 enable
Warning: Spantree port fast start should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc. to a fast start port can cause" temporary spanning tree loops. Use with caution.
Spantree port 2/1 fast start enabled.
Switch-А (enable) set port channel 2/1-2 off
Port(s) 2/1-2 channel mode set to off.
Switch-А (enable) set trunk 2/1 off
Port(s) 2/1 trunk mode set to off.
Введенные при этом изменения в конфигурации автоматически записываются в энергонезависимое ОЗУ.
Проверка
В настоящей главе приведены примеры для версии 4.5(1) программного обеспечения коммутатора. Полное описание вывода команд show version и show module приведено ниже в этой главе, в разделе “Измерение продолжительности задержки с применением и без применения средств DTP, PAgP и PortFast в коммутаторе Catalyst 5000”.
Switch-А (enable) show version
WS-C5505 Software, Version McpSW: 4.5(1) NmpSW: 4.5(1)
Следующая команда представляет собой один из способов просмотра текущего состояния порта в распределенном связующем дереве. В настоящее время данный порт находится в распределенном связующем дереве в состоянии перенаправления (передает и принимает пакеты), а столбец Fast-Start показывает, что средство PortFast на данный момент отменено. Иными словами, для этого порта требуется, по меньшей мере, 30 секунд, чтобы перейти в состояние перенаправления после его инициализации.
Switch-А (enable) show port spantree 2/1
Port Vian Port-State Cost Priority Fast-Start Group-Method
2/11 forwarding 1932 disabled
Теперь рассмотрим пример, в котором для данного порта коммутатора будет разрешено применение средства PortFast. Коммутатор выводит предупреждающее сообщение, что эта команда должна применяться только в портах, подключенных к одному хосту (к рабочей станции, серверу и т.д.), и не должна ни в коем случае использоваться в портах, подключенных к другим концентраторам или коммутаторам. Применение средств PortFast в этом порту было разрешено по тем соображениям, чтобы порт мог перенаправлять пакеты сразу после запуска. Это вполне допустимо, поскольку рабочая станция или сервер не создает в сети циклов, поэтому нет смысла тратить время на проверку. Но в состав цикла может войти другой концентратор или коммутатор, поэтому при подключении устройств такого типа необходимо всегда проходить через обычные стадии приема и обучения.
Switch-А (enable) set spantree portfast 2/1 enable
Warning: Spantree port fast start should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc. to a fast start port can cause temporary spanning tree loops. Use with caution.
Spantree port 2/1 fast start enabled.'
Чтобы убедиться в том, что для этого порта разрешено применение средства PortFast, вызовите на выполнение следующую команду:
Switch-А (enable) show port spantree 2/1
Port Vian Port-State Cost Priority Fast-Start Group-Method
2/11 forwarding 1932 enabled
Еще один способ просмотра установок PortFast для одного или нескольких портов состоит в ознакомлении с информацией о распределенном связующем дереве для конкретной виртуальной локальной сети. Ниже, в разделе “Измерение продолжительности задержки с применением и без применения средств DTP, PAgP и PortFast в коммутаторе Catalyst 5000”, показано, как обеспечить вывод коммутатором отчета о прохождении каждого этапа формирования распределенного связующего дерева в реальном времени. Приведенный ниже вывод команды показывает также время задержки перед переходом
в режим перенаправления (15 секунд), которое характеризует продолжительность этапов приема и обучения в процессе формирования распределенного связующего дерева, охватывающего каждый порт в виртуальной локальной сети.
Switch-А (enable) show
VLAN 1
Spanning tree enabled
spantree 1spantree 1ieeeieeeDesignated Designated Designated DesignatedDesignated Designated Designated DesignatedRoot Root Root RootRoot Root Root RootRoot Max AgeRoot Max Age. Priority . Cost . Port 20 sec. Priority . Cost . Port 20 sec00-e0-4f-94-b5-008189192/24Hello Time 2 sec Forward Delay00-e0-4f-94-b5-008189192/24Hello Time 2 sec Forward Delay15 sec15 secBridge ID MAC ADDR Bridge ID PriorityBridge ID MAC ADDR Bridge ID Priority00-90-92-b0-84-003276800-90-92-b0-84-0032768Bridge Max AgeBridge Max Age20 sec20 secHelloHelloTime 2 sec Forward DelayTime 2 sec Forward Delay15 sec15 secPortPortVianVianPort-StatePort-StateCost PriorityCost PriorityFast-StartFast-StartGroup-MethodGroup-Method2/12/111forwardingforwarding19193232enabledenabledSpanning tree type
spantree 1
spantree 1
ieee
ieee
Designated Designated Designated Designated
Designated Designated Designated Designated
Root Root Root Root
Root Root Root Root
Root Max Age
Root Max Age
. Priority . Cost . Port 20 sec
. Priority . Cost . Port 20 sec
00-e0-4f-94-b5-00
8189
19
2/24
Hello Time 2 sec Forward Delay
00-e0-4f-94-b5-00
8189
19
2/24
Hello Time 2 sec Forward Delay
15 sec
15 sec
Bridge ID MAC ADDR Bridge ID Priority
Bridge ID MAC ADDR Bridge ID Priority
00-90-92-b0-84-00
32768
00-90-92-b0-84-00
32768
Bridge Max Age
Bridge Max Age
20 sec
20 sec
Hello
Hello
Time 2 sec Forward Delay
Time 2 sec Forward Delay
15 sec
15 sec
Port
Port
Vian
Vian
Port-State
Port-State
Cost Priority
Cost Priority
Fast-Start
Fast-Start
Group-Method
Group-Method
2/1
2/1
1
1
forwarding
forwarding
19
19
32
32
enabled
enabled
Для проверки того, действительно ли отменено применение средств PAgP, предназначена команда show port channel, показанная ниже. В качестве опции этой команды следует обязательно указывать номер модуля (в данном случае 2), чтобы эта команда показала режим формирования логического канала, даже если не создано ни одного логического канала. Если команда show port channel вызывается на выполнение в коммутаторе, притом что не сформировано ни одного логического канала, она просто выдает сообщение "No ports channeling" (В формировании логического канала не участвует ни один порт). Но обычно требуется более подробная информация, позволяющая узнать текущий режим формирования логического канала.
Switch-А (enable) show port channel"
No ports channeling
Switch-А (enable) show port channel 2
Port Status Channel Channel NeighborNeighbor
mode status deviceport
2/1 notconnect autonot channel
2/2 notconnect autonot channel
Switch-А (enable) set port channel 2/1-2 off
Port(s) 2/1-2 channel mode set to off.
Switch-А (enable) show port channel 2
Port StatusPort StatusChannel Channel mode statusChannel Channel mode statusNeighbor deviceNeighbor deviceNeighbor portNeighbor port
Port Status
Port Status
Channel Channel mode status
Channel Channel mode status
Neighbor device
Neighbor device
Neighbor port
Neighbor port
not channel not channelnot channel not channel2/1 connected off
not channel not channel
not channel not channel
2/2 connected off
Для проверки того, что средства согласования опций формирования магистрального канала действительно отключены, применяется команда set trunk. В данном случае при этом отображается состояние, предусмотренное по умолчанию. Затем вызовите на выполнение команду отключения режима формирования магистрального канала set trunk off и проверьте результирующее состояние. В вызове этой команды указан номер модуля 2 для просмотра текущего режима формирования логического канала для портов этого модуля.
Switch-А (enable) show trunk 2
Port ModeEncapsulation Status Native vlan
2/1autonegotiatenot-trunking 1
2/2autonegotiatenot-trunking 1
Switch-А (enable) set trunk 2/1-2 off
Port(s) 2/1-2 trunk mode set to off.
Switch-А (enable) show trunk 2
Port
Mode
Encapsulation
Status
Native vlan
2/1
off
negotiate
not-trunking
1
2/2
off
negotiate
not-trunking
1
Здесь не показан пример отмены средств автоматического согласования скорости и режима передачи путем непосредственной установки в коммутаторе скорости и режима передачи; такая необходимость возникает лишь в самых редких случаях. Но если такие действия должны быть выполнены в конкретной ситуации, то пример выполнения подобной настройки конфигурации приведен в следующем разделе (шаг 10).
Измерение продолжительности задержки с применением и без применения средств DTP, PAgP и PortFast в коммутаторе Catalyst 5000
Следующая проверка показывает, как изменяется продолжительность задержки при инициализации порта коммутатора в результате применения различных команд. Вначале была измерена продолжительность задержки при значениях параметров этого порта, применяемых по умолчанию, для получения эталонных данных. Такие значения параметров предусматривают отмену средства PortFast, применение режима auto средства PAgP EtherChannel (в соответствии с которым порт будет участвовать в формировании логического канала при получении соответствующего запроса) и режима
auto средства формирования магистрального канала DTP (согласно которому порт формирует магистральный канал при получении соответствующего запроса). После этого проверка выполняется следующим образом: порту разрешается применение средства PortFast и измеряется продолжительность задержки, затем запрещается применение средства PAgP и измеряется продолжительность задержки, и, наконец, отменяется применение средства формирования магистрального канала и измеряется продолжительность задержки. В последнюю очередь запрещается применение средств автоматического согласования и измеряется продолжительность задержки. Все эти проверки выполняются в коммутаторе Catalyst 5000 с платой Fast Ethernet 10/100, которая поддерживает протоколы DTP и PAgP.
Примечание
Разрешение применять средство PortFast не равносильно запрещению применять средства протокола распределенного связующего дерева (как отмечено выше в этой главе). Если даже применение средства PortFast разрешено, программное обеспечение протокола распределенного связующего дерева все еще продолжает функционировать в рассматриваемом порту; в нем просто пропускаются этапы блокирования, приема и обучения, после чего происходит переход непосредственно в состояние перенаправления. Запрещать применение протокола распределенного связующего дерева не рекомендуется, поскольку такое действие распространяется на всю виртуальную локальную сеть, в результате чего сеть может стать незащищенной по отношению к физическим топологическим циклам, что может вызвать серьезные нарушения в ее работе.
Шаг 1. Просмотрите данные о версии системы IOS коммутатора и о его конфигурации (команды show version, show module).
Switch-А (enable) show version
WS-C5505 Software, Version McpSW: 4.5(1) NmpSW: 4.5(1)
Copyright (c) 1995-1999 by Cisco Systems
NMP S/W compiled on Mar 29 1999, 16:09:01
MCP S/W compiled on Mar 29 1999, 16:06:50
System Bootstrap Version: 3.1.2
Hardware Version: 1.0 Model: WS-C5505 Serial ♦: 066507453
Mod Port Model Serial I Versions
10WS-X5530006841805 Hw : 1.3
Fw : 3.1.2
Fwl: 3.1(2)
Sw : 4.5(1)
2 24 WS-X5225R 012785227 Hw : 3.2
Fw : 4.3(1)
Sw : 4.5(1)
DRAMFLASHNVRAM
Module Total Used Free Total Used Free Total Used Free
132640K 13648K 18992K 8192K 4118K 4074K 512K 119K 393K
Uptime is 28 days, 18 hours, 54 minutes
Switch-А (enable) show module
Model Serial-Num StatusModel Serial-Num StatusMod Module-Name Ports Module-Type
Model Serial-Num Status
Model Serial-Num Status
10Supervisor IIIWS-X5530 006841805 ok
22410/100BaseTX Ethernet WS-X5225R 012785227 ok
Mod MAC-Address(es)HwFwSw
100-90-92-b0-84-00to00-90-92-b0-87-ff1.33.1.24.5(1)
2 00-50-0f-b2-e2-60to00-50-0f-b2-e2-773.24.3(1)4.5(1)
Mod Sub-Type Sub-Model Sub-Serial Sub-Hw
1 NFFC WS-F5521 0008728786 1.0
Шаг 2. Установите наиболее подробный режим ведения журнала для сообщений протокола распределенного связующего дерева (команда set logging level spantree 7). Ниже показаны результаты применения заданного по умолчанию уровня ведения журнала (2) для распределенного связующего дерева, которые показывают, что происходит вывод только сообщений о критических ситуациях.
Switch-А (enable) show logging
Logging buffer size:
500
timestamp option:
enabled
Logging history size:
1
Logging console:
enabled
Logging server:
disabled
server facility: server severity:
LOCAL7 warnings)4)
FacilityDefault SeverityCurrent Session Severity
spantree
22
0(emergencies) 3(errors)
6(information)
1(alerts)2(critical)
4(warnings)5(notifications)
7(debugging)
В данном случае уровень 7 (уровень вывода результатов отладочных команд debug) для сообщений распределенного связующего дерева устанавливается для того, чтобы можно было обнаружить изменения состояния распределенного свя-
зующего дерева в данном порту. Это изменение конфигурации распространяется только на текущий терминальный сеанс, после чего уровень вывода сообщений снова возвращается к обычному значению.
Switch-А (enable) set logging level spantree 7
System logging facility <spantree for this session set to severity
7(debugging)
Switch-А (enable) show logging
Current Session SeverityCurrent Session SeverityFacilityDefault Severity
Current Session Severity
Current Session Severity
spantreespantree2277
spantree
spantree
2
2
7
7
Шаг 3. В самом начале проверки закройте порт коммутатора Catalyst.
Switch-А (enable) set port disable 2/1
Port 2/1 disabled.
Шаг 4. Теперь необходимо проверить время и разрешить применение порта. Задача состоит в том, чтобы узнать, как долго порт будет находиться в каждом состоянии.
Switch-А (enable) show time
Fri Feb 25 2000, 12:20:17
Switch-А (enable) set port enable 2/1
Port 2/1 enabled.
Switch-А (enable)
2000 Feb 25 12:20:39 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1
2000 Feb 25 12:20:39 %SPANTREE-6-PORTBLK: port 2/1 state in vlan 1 changed to blocking.
2000 Feb 25 12:20:3-9 %SPANTREE-6-PORTLISTEN: port 2/1 state in vlane 1 changed to Listening.
2000 Feb 25 12:20:53 %SPANTREE-6-PORTLEARN: port 2/1 state in vlan 1 changed to Learning.
2000 Feb 25 12:21:08 %SPANTREE-6-PORTFWD: port 2/1 state in vlan 1 changed to forwarding.
Как показывает приведенный выше вывод, для перехода на этап блокирования в процессе формирования распределенного связующего дерева порту потребовалось около 22 секунд (от 20:17 до 20:39). Это время было затрачено на согласование параметров канала и подготовку к использованию протоколов DTP и PAgP. С этапа блокирования начинается реализация алгоритма распределенного связующего дерева. С этого этапа немедленно происходит переход к этапу приема пакетов (от 20:39 до 20:39). Переход с этапа приема пакетов на этап обучения занимает приблизительно 14 секунд (от 20:39 до 20:53).
Переход с этапа обучения на этап перенаправления потребовал примерно 15 секунд (от 20:53 до 21:08). Поэтому общая продолжительность времени до то-
го, как порт действительно перешел в состояние готовности к обработке трафика, составила около 51 секунды (от 20:17 до 21:08).
Примечание
Этапы приема пакетов и обучения теоретически должны составлять по 15 секунд, и именно таким образом параметр задержки перенаправления установлен для данной виртуальной локальной сети. При более точных измерениях продолжительность этапа обучения, вероятно, будет приближаться к 15, а не к 14 секундам. Ни одно из проведенных здесь измерений не было идеально точным; задача состояла в том, чтобы просто оценить продолжительность каждого этапа.
Шаг 5. Как показывают приведенные выше данные, а также результаты выполнения команды show spantree, к этому моменту программное обеспечение распределенного связующего дерева в данном порту уже перешло в активное состояние. Рассмотрим другие факторы, которые могут замедлить переход рассматриваемого порта в состояние перенаправления. Результаты выполнения команды show port capabilities показывают, что данный порт обладает способностью формировать магистральный канал и создавать канал EtherChannel. Команда show trunk показывает, что рассматриваемый порт находится в режиме auto и что он подготовлен для согласования способа формирования магистрального канала с помощью протокола DTP (ISL или 802. lq).
Switch-А (enable) show port capabilities 2/1
Model Port Type
WS-X5225R
2/1
10/lOOBaseTX
Speed Duplex Trunk encap type Trunk mode Channel
Broadcast suppression Flow control
Security
• Membership Fast start Rewrite
auto,10,100
half,full
802.IQ,ISL
on,off,desirable,auto,nonegotiate 2/1-2,2/1-4.
percentage(0-100) receive-(off,on),send-(off,on) yes static,dynamic yes■
yes.
Switch-А (enable) show trunk 2/1
PortMode
Encapsulation StatusNative vlan
2/1 auto negotiate not-trunking 1
Шаг 6. Вначале в этом порту будет разрешено применение средства PortFast. Параметр согласования способа формирования магистрального канала (DTP) все еще соответствует режиму auto, кроме того, в режиме auto еще находятся средства EtherChannel (PAgP).
Switch-А (enable) set port disable 2/1
Port 2/1 disabled.
Switch-А (enable) set spantree portfast 2/1 enable
Warning: Spantree port fast start should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc. to a fast start port can cause temporary spanning-tree loops. Use with caution.
Spantree port 2/1 fast start enabled.
Switch-А (enable) show time
Fri Feb 25 2000, 13:45:23
Switch-А (enable) set port enable 2/1
Port 2/1 enabled.
Switch-А (enable)
Switch-А (enable)
2000 Feb 25 13:45:43 %PAGP-5-PORTTOSTP:Port 2/1 joined bridgeport 2/1
2000 Feb 25 13:45:44 %SPANTREE-6-PORTFWD: port 2/1 state in vlan 1 change to forwarding.
Теперь общее время сократилось до 21 секунды! Порту потребовалось 20 секунд на то, чтобы войти в состав группы мостов (от 45:23 до 45:43). Но затем ему потребовалась только 1 секунда для перехода на этап перенаправления по протоколу STP (вместо 30 секунд), поскольку было разрешено средство PortFast. Разрешив применение средства PortFast, мы смогли сэкономить 29 секунд. Рассмотрим, можно ли еще уменьшить продолжительность задержки.
Шаг 7. Теперь будет отменен режим PAgP. Результаты выполнения команды show port channel показывают, что установлено значение auto режима PAgP, а это означает, что рассматриваемый порт сформирует логический канал, если получит соответствующий запрос PAgP от порта, находящегося на другом конце канала. Средство формирования логического канала должно быть отключено, по меньшей мере, для группы из двух портов; такая операция не может быть выполнена только для одного порта.
Switch-А (enable) show port channel 2/1
Port Status Channel Channel NeighborNeighbor
mode status deviceport
2/1 connected auto not channel
Switch-А (enable) set port channel 2/1-2 off . Port(s) 2/1-2 channel mode set to off.
Шаг 8. Теперь закроем порт и повторим проверку.
Switch-А (enable) set port disable 2/1
Port 2/1 disabled.
Switch-А (enable) show time
Fri Feb 25 2000, 13:56:23
Switch-А (enable) set port enable 2/1
Port 2/1 enabled.
Switch-А (enable)
2000 Feb 25 13:56:32 %PAGP-5-PORTTOSTP:Port 2/1 joined bridgeport 2/1
2000 Feb 25 13:56:32 3SPANTREE-6-PORTFWD: port 2/1 state in vlan 1 changed to forwarding.
Здесь заслуживает внимания то, что для перехода в состояние перенаправления потребовалось только 9 секунд (от 56:23 до 56:32), а не 21 секунда, как при проверке, описанной выше. Текущая проверка показала, что переход от режима auto к режиму off применения средств PAgP позволяет сэкономить около 12 секунд.
Шаг 9. Установим режим поддержки средств формирования магистрального канала off (вместо auto) и рассмотрим, как это повлияет на продолжительность перехода порта в состояние перенаправления. Здесь порт снова будет закрыт, а затем открыт, и будет зарегистрировано время.
Switch-А (enable) set trunk 2/1 off
Port(s) 2/1 trunk mode set to off.
Switch-А (enable) set port disable 2/1
Port 2/1 disabled.
Начнем проверку с установки режима формирования магистрального канала off (вместо auto).
Switch-А (enable) show time
Fri Feb 25 2000, 14:00:19
Switch-А (enable) set port enable 2/1
Port 2/1 enabled.
Switch-А (enable)
2000 Feb 25 14:00:22 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1
2000 Feb 25 14:00:23 %SPANTREE-6-PORTFWD: port 2/1 state in vlan 1 change for forwarding.,
Очевидно, что с самого начала сэкономлено несколько секунд, поскольку для перехода программного обеспечения распределенного связующего дерева в состояние перенаправления потребовалось только 4 секунды (от 00:19 до 00:22). Благодаря переходу от использования режима формирования магистрального канала auto в режим off сэкономлено примерно 5 секунд.
Шаг 10. (Необязательный.) Если проблема состояла в том, что инициализация порта коммутатора занимала слишком много времени, то к этому моменту она должна быть решена. Но если требуется сократить это время еще на пару секунд, то можно установить для этого порта скорость и режим передачи вручную, а не использовать автоматическое согласование.
Если скорость и режим передачи на одном конце канала устанавливаются вручную, то такая же операция должна быть выполнена и на другом конце канала. Это связано с тем, что в результате установки скорости и режима передачи порта отменяется применение средств автоматического согласования в этом порту и устройство, подключающееся к порту, не обнаруживает пара-
метров автоматического согласования. Поэтому при подключении к порту коммутатора устройство сформирует соединение только в полудуплексном режиме передачи и возникшее в результате несоответствие режимов передачи станет причиной низкой производительности и ошибок в порту. Следует помнить, что для предотвращения таких проблем необходимо соблюдать следующее правило: если устанавливаются скорость и режим передачи на одном конце канала, необходимо установить также скорость и режим передачи в подключающемся устройстве на другом конце канала.
Для просмотра состояния порта после установки скорости и режима передачи применяется команда show port.
Switch-А (enable) set port speed 2/1 100
Port(s) 2/1 speed set to 100 Mbps.
Switch-А (enable) set port duplex 2/1 full
Port(s) 2/1 set to full-duplex.
Switch-А (enable) show port
Port NameStatus Vian Level Duplex Speed Type
2/1connected 1normal full 100
Ю/lOOBaseTX
Ниже приведены результаты измерения времени.
Switch-А (enable) show time
Fri Feb 25 2000, 140528 Eastern
Switch-А (enable) set port enable 2/1
Port 2/1 enabled.
Switch-А (enable)
2000 Feb 25 140529 Eastern -0500 %PAGP-5-PORTTOSTP:Port 2/1 joined bridgeport 2/1
2000 Feb 25 140530 Eastern -0500 %SPANTREE-6-PORTFWD: port 2/1 state in vlan 1 changed to forwarding.
Окончательные результаты показывают, что затраты времени составляют 2 секунды (от 05:28 до 05:30).
Шаг 11. Была проведена еще одна наглядная проверка затрат времени (с контролем по показаниям часов). Для этого была вызвана на выполнение команда непрерывного эхо-тестирования (ping -t) коммутатора с персонального компьютера, подключенного к коммутатору. Затем кабель был отсоединен от коммутатора. Запросы эхо-тестирования стали завершаться неудачей. А после подключения кабеля к коммутатору по показаниям часов было проверено, сколько времени потребовалось коммутатору, чтобы ответить на запросы эхо- тестирования, поступающие от персонального компьютера. Как оказалось, требовалось примерно 5 или 6 секунд, если было разрешено применение средств автоматического согласования скорости и режима передачи, и примерно 4 секунды, если автоматическое согласование скорости и режима передачи было запрещено.
На результаты такой проверки могут повлиять многие факторы (скорость инициализации персонального компьютера, состав программного обеспечения компьютера, быстродействие порта консоли коммутатора, отвечающего на запросы, и т.д.), но цель последнего эксперимента состояла просто в оценке того, сколько времени потребуется для получения на персональном компьютере ответа от коммутатора. Все остальные эксперименты проводились с использованием сообщений встроенной команды debug коммутатора.
Способы сокращения задержки при запуске в коммутаторе Catalyst 2900XL/3500XL
Настройка конфигурации моделей 2900XL и 3500XL может быть выполнена с помощью Web-броузера, протокола SNMP или интерфейса командной строки. В настоящем разделе показано применение интерфейса командной строки. Ниже приведен пример эксперимента, при котором выполняется просмотр состояния программного обеспечения распределенного связующего дерева в порту, переход к использованию средств PortFast, а затем проверка работы порта. Модели 2900XL/3500XL поддерживают средства формирования каналов EtherChannel и магистральных каналов, но проверяемая здесь версия программного обеспечения, т.е. версия 11.2(8.2)SA6, не поддерживает динамическое создание каналов EtherChannel (PAgP) или динамическое согласование параметров магистральных каналов (DTP), поэтому в данном эксперименте эти средства не потребовалось отменять. К тому же, после того как было разрешено применение средства PortFast, затраты времени на переход порта в рабочее состояние составляли меньше 1 секунды, поэтому не было смысла пытаться изменить параметры настройки автоматического согласования скорости и режима передачи для дальнейшего сокращения затрат времени. Очевидно, что задержка, равная 1 секунде, уже является вполне приемлемой! По умолчанию применение средства PortFast в портах коммутатора рассматриваемого типа отключено. Команды, позволяющие разрешить использование средства PortFast, рассматриваются ниже.
Настройка конфигурации
Ниже приведены команды, позволяющие сократить задержку при запуске платформ Catalyst 3500XL и 2900XL.'
2900XL# conf t
2900XL(config)# interface fastEthernet 0/1 2900XL(config-if)# spanning-tree portfast 2900XL(config-if)# exit 2900XL(config)# exit 2900XL# copy run start
Формат команд в системе IOS на этих платформах аналогичен формату команд маршрутизатора; для записи конфигурации в ПЗУ ее необходимо сохранить (с помощью команды copy run start).
Проверка
Чтобы проверить, разрешено ли применение средств PortFast, можно вызвать на выполнение следующую команду:
2900XL# show spanning-tree interface fastEthernet 0/1
Interface FaO/1 (port 13) in Spanning tree 1 is FORWARDING
Port path cost 19, Port priority 128
Designated root has priority 8192, address 0010.Odbl.7800
Designated bridge has priority 32768, address 0050.8039.ec40
Designated port is 13, path cost 19
Timers: message age 0, forward delay 0, hold 0
BPDU: sent 2105, received 1
The port is in the portfast mode
Для той же цели можно просто просмотреть информацию о конфигурации коммутатора.
2900XL# show running-config
Building configuration...
Current configuration: ।
version 11.2
।
interface VLAN1
ip address 172.16.84.5 255.255.255.0
no ip route-cache i
interface FastEthernetO/1 spanning-tree portfast ।
interface FastEthernetO/2
Измерение продолжительности задержки в коммутаторе Catalyst 2900XL
Ниже приведен пример измерения результатов применения средства PortFast в коммутаторе 2900XL.
Шаг 1. Для проведения следующих проверок в коммутаторе 2900XL применялась версия программного обеспечения 11.2(8.2)SA6. Switch# show version Cisco Internetwork Operating System Software
IOS (tm) C2900XL Software (C2900XL-C3H2S-M), Version 11.2(8.2)SA6, MAINTENANCE INTERIM SOFTWARE
Copyright (c) 1986-1999 by cisco Systems, Inc.
Compiled Wed 23-Jun-99 16:25 by boba
Image text-base: 0x00003000, data-base: 0x00259AEC
ROM: Bootstrap program is C2900XL boot loader
Switch uptime is 1 week, 4 days, 22 hours, 5 minutes
System restarted by power-on
System image file is "flash:c2900XL-c3h2s-mz-112.8.2-SA6.bin", booted via console
cisco WS-C2924-XL (PowerPC403GA) processor (revision Oxll) with 8192K/1024K bytes of memory.
Processor board ID OxOE, with hardware revision 0x01
Last reset from power-on
Processor is running Enterprise Edition Software
Cluster command switch capable
Cluster member switch capable 24 Ethernet/IEEE 802.3 interface(s)
32K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address: 00:50:80:39:EC:40
Motherboard assembly number: 73-3382-04
Power supply part number: 34-0834-01
Motherboard serial number: FAA02499G7X
Model number: WS-C2924-XL-EN
System serial number: FAA0250U03P
Configuration register is OxF
Шаг 2. Для получения информации о том, какие действия выполняет коммутатор и в какой момент времени, предназначены следующие команды:
2900XL(config)# service timestamps debug uptime
2900XL(config)# service timestamps log uptime
2900XL# debug spantree events
Spanning Tree event debugging is on
2900XL# show debug
General spanning tree:
Spanning Tree event debugging is on
Шаг 3. Рассматриваемый порт закрывается.
2900XL# conf t
Enter configuration commands, one per line. End with CNTL/Z.
2900XL(config)# interface fastEthernet 0/1
2900XL(config-if)# shut
2900XL(config-if)#
00:31:28: ST: sent Topology Change Notice on FastEthernetO/6
00:31:28: ST: FastEthernetO/1 - blocking
00:31:28: 3LINK-5-CHANGED: Interface FastEthernetO/1, changed state to administratively down
00:31:28: 3LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernetO/1, changed state to down
2900XL(config-if)#exit
2900XL(config)#exit 2900XL#
Шаг 4. На этом этапе выполняется вставка следующих команд из буфера Clipboard в интерфейс коммутатора. Эти команды показывают текущее время в коммутаторе 2900XL и снова разрешают применение порта, show clock conf t int f0/1•
no shut
Шаг 5. По умолчанию применение средства PortFast запрещено. Чтобы убедиться в этом, можно использовать два следующих способа. Первый состоит в проверке того, что в выводе команды show spanning-tree interface не упоминается средство PortFast, а второй способ состоит в просмотре информации о действующей конфигурации, где отсутствует команда spanning-tree portfast в составе конфигурации интерфейса. 2900XL# show spanning-tree interface fastEthernet 0/1 Interface FaO/1 (port 13) in Spanning tree 1 is FORWARDING Port path cost 19, Port priority 128 Designated root has priority 8192, address 0010.Odbl.7800 Designated bridge has priority 32768, address 0050.8039.ec40 Designated port is 13, path cost 19 Timers: message age 0, forward delay 0, hold 0 BPDU: sent 887, received 1 [Примечание. В этом фрагменте отсутствует сообщение об использовании режима PortFast...]
2900XL# show running-config Building configuration... । interface FastEthernetO/1 [Примечание. В конфигурации этого интерфейса отсутствует команда spanning-tree portfast...]
Шаг 6. Ниже приведены первые результаты измерения времени без использования средства PortFast. 2900XL# show clock *00:27:27.632 UTC Mon Mar 1 1993 2900XL# conf t Enter configuration commands, one per line. End with CNTL/Z. 2900XL(config)# int f0/l 2900XL(config-if)# no shut 2900XL(config-if )# 00:27:27: ST: FastEthernetO/1 - listening 00:27:27: 4LINK-3-UPDOWN: Interface FastEthernetO/1, changed state to up
00:27:28: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernetO/1, changed state to up
00:27:42: ST: FastEthernetO/1 - learning
00:27:57: ST: sent Topology Change Notice on FastEthernetO/6
00:27:57: ST: FastEthernetO/1 - forwarding
Общие затраты времени от отмены закрытия порта до начала перенаправления портом трафика составили 30 секунд (от Т1;Т1 до 27:57).
Шаг 7. Чтобы разрешить применение средства PortFast, необходимо вызвать на выполнение следующие команды: 2900XL# conf t
Enter configuration commands, one per line. End with CNTL/Z.
2900XL(config)# interface fastEthernet 0/1
2900XL(config-if)# spanning-tree portfast
2900XL(config-if)# exit
2900XL(config)# exit
2900XL#
Для проверки того, разрешено ли средство PortFast, воспользуемся командой show spanning-tree interface. Следует отметить, что в конце вывода этой команды указано, что применение средства PortFast разрешено.
2900XL# show spanning-tree interface fastEthernet 0/1
Interface Fa0/l (port 13) in Spanning tree 1 is FORWARDING
Port path cost 19, Port priority 128
Designated root has priority 8192, address 0010.Odbl.7800
Designated bridge has priority 32768, address 0050.8039.ec40
Designated port is 13, path cost 19
Timers: message age 0, forward delay 0, hold 0
BPDU: sent 1001, received 1
The port is in the portfast mode
Можно также определить, что средство PortFast разрешено, просмотрев информацию о конфигурации порта..
2900XL# sh ru
Building configuration...
interface FastEthernetO/1 spanning-tree portfast
Шаг 8. Теперь определим затраты времени после перехода к использованию средства PortFast.
2900XL# show clock
*00:23:45.139 UTC Mon Mar 1 1993
2900XL# conf t
Enter configuration commands, one per line. End with CNTL/Z.
2900XL(config)# int f0/l
2900XL(config-if)# no shut
2900XL(config-if)#
00:23:45: ST: FastEthernetO/1 -jump to forwarding from blocking 00:23:45: 4LINK-3-UPDOWN: Interface FastEthernetO/1, changed state to up 00:23:45: 4LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernetO/1, changed state to up
В данном случае общие затраты времени не превышали 1 секунды. Если проблема состояла в том, что задержка при инициализации порта коммутатора была слишком продолжительной, то применение средства PortFast должно ее полностью решить.
Следует учитывать, что данный коммутатор в настоящее время не поддерживает согласование параметров магистрального канала, поэтому это средство не требуется отменять. Он также не поддерживает применение протокола PAgP для формирования логических каналов, поэтому не требуется отменять и это средство. Коммутатор поддерживает автоматическое согласование скорости и режима, но поскольку задержка и так достаточно мала, то нет смысла запрещать такое согласование.
Шаг 9. Была также проведена проверка с помощью эхо-тестирования коммутатора с рабочей станции (так же, как и в шаге 11, приведенном в примере для коммутатора Catalyst 5000). Для поступления ответа с коммутатора требовалось приблизительно от 5 до 6 секунд, независимо от того, было ли разрешено автоматическое согласование скорости и режима передачи.
Способы сокращения задержек при запуске в коммутаторе Catalyst 1900/2800
В документации коммутаторов 1900/2820 средство PortFast упоминается под названием "spantree start-forwarding" (запуск программного обеспечения распределенного связующего дерева с этапа перенаправления). В версии программного обеспечения, применяемой для проведения экспериментов (V8.01.05), в коммутаторах этого типа средство PortFast было по умолчанию разрешено в портах Ethernet (на 10 Мбит/с) и запрещено в портах Fast Ethernet (соединение с устройствами сетевой инфраструктуры). Поэтому, если при использовании команды show run для "просмотра информации о конфигурации порта Ethernet нет никаких упоминаний о средстве PortFast, то это средство разрешено. Если же в состав конфигурации входит команда no spantree start-forwarding, то средство PortFast запрещено. А когда речь идет о портах Fast Ethernet (на 100 Мбит/с), справедливо обратное: для порта Fast Ethernet средство PortFast разрешено, только если в составе конфигурации порта присутствует команда spantree start-forwarding.
Настройка конфигурации
Ниже приведен пример использования средства PortFast в порту Fast Ethernet. Во всех примерах данной главы применяется версия 8 программного обеспечения производственного выпуска Enterprise Edition. В коммутаторе 1900 предусмотрено автоматическое сохранение конфигурации после внесения изменений. Следует помнить, что нельзя разрешать применение средства PortFast в любом порту, через который данный коммутатор подключается к другому коммутатору или концентратору; это средство может применяться только в порту, подключенному к оконечной станции. После внесения изменений конфигурация автоматически сохраняется в энергонезависимом ОЗУ.
1900# show version
Cisco Catalyst 1900/2820 Enterprise Edition Software
Version V8.01.05
Copyright (c) Cisco Systems, Inc. 1993-1998
1900 uptime is 0day(s) 01hour(s) 10minute(s) 42second(s)
cisco Catalyst 1900 (486sxl) processor with 2048K/1024K bytes of memory
Hardware board revision is 5
Upgrade Status: No upgrade currently in progress.
Config File Status: No configuration upload/download is in progress
27 Fixed Ethernet/IEEE 802.3 interface(s)
Base Ethernet Address: 00-50-50-E1-A4-80 1900# conf t
Enter configuration commands, one per line. End with CNTL/Z
1900(config)# interface FastEthernet 0/26 1900(config-if)# spantree start-forwarding 1900(config-if)# exit 1900(config)# exit
1900#
Проверка
Один из способов проверки того, разрешено ли применение средства PortFast, состоит в просмотре информации о конфигурации. Напомним, что в порту Fast Ethernet должно быть явно указано, что это средство разрешено, а в порту Ethernet средство PortFast разрешено, если конфигурация не показывает, что оно запрещено. В приведенной ниже конфигурации средство PortFast в интерфейсе Ethernet 0/1 запрещено (здесь находится команда его отмены), в интерфейсе Ethernet 0/2 средство PortFast разрешено (здесь нет команды отмены, а это означает, что оно разрешено), в интерфейсе Fast Ethernet 0/26 (порт А в системе меню) средство PortFast также разрешено (поскольку задана команда для его разрешения).
1900# show running-config
Building configuration...'
।
interface Ethernet 0/1
no spantree start-forwarding ।
interface Ethernet 0/2
i
interface FastEthernet 0/26
spantree start-forwarding ।
Для просмотра состояния средств PortFast можно проще всего воспользоваться системой меню. После выбора команды Р (сокращение от Port Configuration — кон-
фигурация порта) в главном меню, а затем выбора порта на экран выводится информация, которая позволяет узнать, разрешен ли режим ускоренной загрузки порта. Ниже приведен вывод для порта Fast Ethernet 0/26 (который обозначается в этом коммутаторе как порт "А").
Catalyst 1900 - Port A Configuration
Built-in 100Base-FX
802.Id STP State: Blocking Forward Transitions: 0
Settings
[D] Description/name of port
[S] Status of port
Suspended-no-1inkbeat
[I] Port priority (spanning tree)
128 (80 hex)
[C] Path cost (spanning tree)
10
[H] Port fast mode (spanning tree)
Enabled
[E] Enhanced congestion control
Disabled
[F] Full duplex / Flow control
Half duplex
[A] Port addressing
[N] Next port
[P] Previous port
Related Menus
[V] View port statistics
[G] Goto port
[X] Exit to Main Menu
Enter Selection:
Измерение продолжительности задержки в коммутаторе Catalyst 1900
В коммутаторах 1900/2820 проверка продолжительности выполнения различных этапов инициализации усложняется, так как в них отсутствует инструментальное средство отладки, поэтому для этой цели проводилось просто эхо-тестирование коммутатора с подключенного к нему персонального компьютера. Мы отключали, а затем снова подключали кабель и регистрировали время, которое требовалось для получения от коммутатора ответов на запросы эхо-тестирования с применением и без применения средства PortFast. Если в порту Ethernet было разрешено применение средства PortFast (состояние, предусмотренное по умолчанию), то персональный компьютер получал ответ в течение 5-6 секунд. А если средство PortFast было отключено, то персональный компьютер получал ответ в течение 34-35 секунд.
Дополнительные преимущества применения средства PortFast
Применение средства PortFast в конкретной сети предоставляет еще одно преимущество, которое касается функционирования программного обеспечения алгоритма распределенного связующего дерева. Каждый раз, когда один из каналов в распределенном связующем дереве становится активными и переходит в состояние перенаправления, коммутатор передает специальный пакет с извещением о состоянии распределенного связующего дерева, называемый TCN (Topology Change Notification —
извещение об изменении топологии). Извещение TCN передается корневому коммутатору в распределенном связующем дереве, который распространяет его по всем другим коммутаторам в виртуальной локальной сети. В результате этого все коммутаторы устанавливают сокращенный срок обновления своих таблиц МАС-адресов с использованием параметра задержки перенаправления, который обычно составляет 15 секунд. Поэтому при подключении каждой рабочей станции к группе мостов МАС- адреса всех коммутаторов обновляются через 15 секунд, а не через 300, как обычно.
Рабочая станция после активизации фактически не изменяет топологию сети, поэтому, если речь идет обо всех коммутаторах в виртуальной локальной сети, нет никакой необходимости устанавливать сокращенный режим обновления таблиц с помощью пакетов TCN. А если применение средства PortFast разрешено, коммутатор не рассылает пакеты TCN после перехода соответствующего порта в активное состояние.
Команды, предназначенные для проверки конфигурации
Ниже перечислены команды, применяемые для проверки конфигурации в коммутаторах ряда 4000/5000/6000.
show port spantree 2/1. Позволяет определить, разрешено ли применение средства "Fast-Start" (PortFast).
show spantree 1. Служит для просмотра всех портов сети VLAN 1 и определения того, разрешено ли для них применение средства "Fast-Start".
show port channel. Позволяет определить, имеются ли какие-либо активные логические каналы.
show port channel 2. Применяется для просмотра режима формирования логического канала (auto, off и т.д.) для каждого порта в модуле 2.
show trunk 2. Предназначена для просмотра режима формирования магистрального канала (auto, off и т.д.) для каждого порта в модуле 2.
show port. Позволяет определить состояние (подключенный, неподключенный и т.д.), а также параметры настройки скорости и режима передачи для всех портов коммутатора.
Ниже приведены команды, предназначенные для использования в устройствах ряда 2900XL/3500XL.
show spanning-tree interface FastEthernet 0/1. Позволяет определить, разрешено ж применение средства PortFast в этом порту (если в выводе этой команды отсутствует какое-либо упоминание о средстве PortFast, это означает, что оно не разрешено).
show running-config. Позволяет получить информацию о конфигурации порта. Если в составе конфигурации присутствует команда spanning-tree portfast, то применение средства PortFast разрешено.
Ниже приведены команды, предназначенные для использования в устройствах ряда 1900/2800.
show running-config. Позволяет просматривать текущие параметры настройки (некоторые команды не отображаются, если они представляют значения параметров, применяемых для данного коммутатора по умолчанию).
Для просмотра экрана состояния порта применяется система меню.
Команды, применяемые для выявления ошибок в конфигурации
Ниже перечислены команды, которые применяются в процессе устранения нарушений в работе коммутаторов ряда 4000/5000/6000.
show port spantree 2/1. Позволяет определить, разрешено ли применение средства "Fast-Start" (PortFast).
show spantree 1. Служит для просмотра всех портов сети VLAN 1 и определения того, разрешено ли для них применение средства "Fast-Start".
show port channel. Позволяет определить, имеются ли какие-либо активные логические каналы.
show port channel 2. Предназначена для просмотра режима формирования логического канала (auto, off и т.д.) для каждого порта в модуле 2.
show trunk 2. Применяется для просмотра режима формирования магистрального канала (auto, off и т.д.) для каждого порта в модуле 2.
show port. Позволяет определить состояние (подключенный, неподключенный и т.д.), а также параметры настройки скорости и режима передачи для всех портов коммутатора.
show logging. Служит для определения типов сообщений, которые приводят к формированию записей в журнале.
set logging level spantree 7. Позволяет перевести коммутатор в режим вывода на консоль в реальном времени сообщений об изменении состояния порта, в котором функционирует алгоритм распределенного связующего дерева.
set port disable 2/1. Применяется для закрытия порта программным путем (аналогично команде shutdown маршрутизатора).
set port enable 2/1. Применяется для открытия порта программным путем (аналогично команде no shutdown маршрутизатора).
show time. Позволяет определить значение текущего времени в секундах (используется в начале проверки продолжительности задержки).
show port capabilities. Предназначена для определения средств, реализованных в данном порту.
set trunk 2/1 off. Применяется для установки значения off режима формирования магистрального канала (что позволяет сократить время инициализации порта).
set port channel 2/1-2 off. Применяется для установки значения off режима EtherChannel (PAgP) (что позволяет сократить время инициализации порта).
set port speed 2/1 100. Предназначена для установки скорости порта на 100 Мбит/с и отключения автоматического согласования.
set port duplex 2/1 full. Позволяет установить для порта дуплексный режим передачи.
Ниже приведены команды, предназначенные для использования в устройствах ряда 2900XL/3500XL.
service timestamps debug uptime. Позволяет указать, что в отладочные сообщения должны быть включены данные о времени.
service timestamps log uptime. Позволяет указать, что в сообщения, записываемые в журнал, должны быть включены данные о текущем значении времени.
debug spantree events. Предназначена для получения информации о том, когда порт переходит с одного этапа формирования распределенного связующего дерева на другой.
show clock. Служит для получения значений текущего времени (при проведении проверок продолжительности задержки).
show spanning-tree interface FastEthernet 0/1. Позволяет определить, разрешено ли применение средства PortFast в этом порту (если в выводе этой команды отсутствует какое-либо упоминание о средстве PortFast, это означает, что оно не разрешено).
shut. Предназначена для отключения порта программным путем.
no shut. Используется для включения порта программным путем.
Ниже приведены команды, предназначенные для использования в устройствах ряда 1900/2800:
show running-config. Позволяет просматривать текущие параметры настройки (некоторые команды не отображаются, если они представляют значения параметров, применяемых для данного коммутатора по умолчанию).
Настройка конфигурации и устранение нарушений в работе средств многоуровневой коммутации IP
В настоящем разделе приведены основные сведения по устранению нарушений в работе средств многоуровневой коммутации MLS (MultiLayer 'Switching) трафика протокола 1Р. Эти средства оказались весьма перспективными для повышения производительности маршрутизации за счет применения специализированных интегральных микросхем (ASIC — Application-Specific Integrated Circuit). Маршрутизация первоначально осуществлялась с использованием центрального процессора и программного обеспечения; средства MLS позволяют выполнять один из важных этапов процесса маршрутизации (перезапись пакетов) с помощью аппаратных средств, поэтому применение для их обозначения термина “коммутация” становится еще более оправданным. Необходимо подчеркнуть, что термины коммутация MLS и коммутация уровня 3 эквивалентны. Средство NetFlow системы IOS имеет иное назначение и в настоящем разделе не рассматривается. Средства MLS включают также поддержку протокола IPX (IPX MLS) и многоадресатной рассылки (MMLS), но данный раздел посвящен исключительно вопросам устранения основных нарушений в работе средств MLS IP.
Введение
Чем более высокие требования предъявляются к сетям, тем больше возрастает потребность в повышении производительности. К локальным, распределенным сетям и
к Internet подключается все больше персональных компьютеров, пользователи которых требуют, чтобы им предоставлялся быстрый доступ к базам данных, файлам и Web-страницам, сетевым приложениям, к другим персональным компьютерам и к видеоинформации, передаваемой в потоковом режиме. Для того чтобы соединения были быстрыми и надежными, сети должны быстро приспосабливаться к изменениям топологии и отказам, а также формировать наилучшие пути доступа, оставаясь при этом в максимально возможной степени незаметными для конечных пользователей. Если конечные пользователи обнаруживают, что поток информации между их персональными компьютерами и сервером протекает с минимальным сетевым замедлением, это их вполне устраивает. Основное назначение протоколов маршрутизации состоит в определении наилучшего пути доступа, но этот процесс может потребовать больших затрат ресурсов процессора, поэтому передача части этих функций аппаратному обеспечению коммутатора позволяет добиться значительного повышения производительности. В этом и состоит смысл применения средств MLS.
Средства MLS состоят из трех основных компонентов; двумя из них являются устройства MLS-RP и MLS-SE. Устройство MLS-RP представляет собой маршрутизатор с поддержкой MLS, который выполняет традиционные функции маршрутизации пакетов, передаваемых из одной подсети или виртуальной локальной сети в другую. А устройство MLS-SE представляет собой коммутатор с поддержкой MLS, для нормального функционирования которого обычно требуется, чтобы маршрутизация пакетов, передаваемых из одной подсети или виртуальной локальной сети в другую, осуществлялась с помощью маршрутизатора, но благодаря использованию специального аппаратного и программного обеспечения способен сам выполнить перезапись некоторых пакетов. Дело в том, что часть пакета, не содержащая данных, корректируется (перезаписывается) при его прохождении через маршрутизирующие интерфейсы на пути к получателю после перехода по каждому транзитному участку маршрута.
Здесь может возникнуть путаница, поскольку создается такое впечатление, будто устройство уровня 2 берет на себя выполнение функций уровня 3. Но фактически коммутатор только перезаписывает информацию уровня 3 и “коммутирует” пакеты, передаваемые из одной подсети или виртуальной локальной сети в другую, а за вычисление маршрутов на основе стандартов и определение наилучшего пути по- прежнему отвечает маршрутизатор. Чтобы избежать такой путаницы, необходимо мысленно разделять функции маршрутизации и коммутации, особенно в тех случаях, если они выполняются в одном и том же устройстве (как при использовании встроенного маршрутизатора MLS-RP). Средства MLS можно рассматривать просто как более развитую форму кэширования информации о маршрутах, при которой кэш находится в коммутаторе, отдельно от маршрутизатора. Для работы средств MLS наряду с соответствующими минимальными объемами аппаратного и программного обеспечения требуются и MLS-RP, и MLS-SE.
Устройство MLS-RP может быть внутренним (установленным в корпусе коммутатора) или внешним (подключенным с помощью кабеля к магистральному порту коммутатора). Примерами внутренних устройств MLS-RP являются модуль RSM и плата RSFC (Route-Switch Feature Card — плата поддержки средств маршрутизации в коммутаторе), которые устанавливаются соответственно в гнездо или супервизорный блок коммутатора семейства Catalyst 5ххх; то же относится и к плате MSFC (Multilayer Switch Feature Card — плата поддержки многоуровневой коммутации) для коммутатора семейства Catalyst бххх. В качестве примеров внешних устройств MLS-RP можно указать любой маршрутизатор ряда Cisco 7500, 7200, 4700, 4500 или 3600. Как прави-
ло, для поддержки средства MLS IP для всех устройств MLS-RP требуется, как минимум, версия IOS, принадлежащая к ряду 11.3WA или 12.0WA (для ознакомления с конкретными сведениями обратитесь к документации по конкретному выпуску). Кроме того, маршрутизатор может выполнять функции MLS-RP, только если в нем разрешено применение средств MLS.
Устройство MLS-SE представляет собой коммутатор со специальным аппаратным обеспечением. Для использования средств MLS в коммутаторах семейства Catalyst 5ххх необходимо установить супервизорный блок коммутатора в плату NFFC (NetFlow Feature Card — плата поддержки средства NetFlow); в блоках Supervisor IIG и III G такая плата установлена по умолчанию. Кроме того, должно применяться программное обеспечение хотя бы с минимальным объемом средств Catalyst OS 4.1.1. Следует отметить, что версия 4.x, в соответствии с тем, как принято обозначать такую степень распространения программного обеспечения в документации Cisco, “gone General Deployment (GD)” (прошла широкую проверку на практике), т.е. подтвердила свое соответствие жестким требованиям конечных пользователей и показала стабильную работу в производственных условиях (обращайтесь на Web-узел компании Cisco для получения информации о ее последних выпусках). Средства MLS IP поддерживаются и автоматически разрешены для применения в аппаратном и программном обеспечении коммутаторов Catalyst бххх с установленной платой MSFC/PFC (в других маршрутизаторах средства MLS запрещены по умолчанию). Обратите внимание, что поддержка средств MLS IPX и MLS для многоадресатной рассылки может предъявлять иные требования к аппаратному и программному обеспечению (к системам IOS и Catalyst OS). В целом средства MLS поддерживают или будут поддерживать многие платформы Cisco. Еше раз подчеркнем, что коммутатор может выполнять функции устройства MLS-SE, только если в нем разрешено применение средств MLS.
Третьим важным компонентом средств MLS является протокол MLSP. Поскольку протокол MLSP составляет основу средств MLS и без понимания принципов его работы невозможно эффективно заниматься устранением нарушений в работе средств MLS, мы подробно рассмотрим его ниже. Протокол MLSP используется устройствами MLS-RP и MLS-SE для обмена данными друг с другом; с его помошью осуществляются такие задачи, как переход к применению средств MLS, установка, обновление или удаление потоков (информации кэша), а также управление и экспортирование статистических данных о потоках (средства NetFlow Data Export в настоящем разделе не рассматриваются). Протокол MLSP позволяет также устройству MLS-SE накапливать информацию о МАС-адресах интерфейсов маршрутизатора с поддержкой MLS, проверять маску потока MLS-RP (как описано ниже в этой главе) и контролировать работоспособность устройства MLS-RP. Устройство MLS-RP через каждые 15 секунд рассылает с помощью протокола MLSP многоадресатные hello-пакеты; если будут пропущены подряд три таких пакета, то устройство MLS-SE определит, что произошел отказ устройства MLS-RP или связь с ним потеряна.
На рис. 23.7 показаны три основных этапа, которые должны быть выполнены для создания сокращенного пути с помощью протокола MLSP: обработка инициализирующего пакета, разрешающего пакета и кэширование. В устройстве MLS-SE выполняется проверка наличия кэшированной записи MLS; если информация в кэше MLS и в пакете совпадает (такая ситуация называется попаданием в кэш), то пакет перезаписывается непосредственно в самом коммутаторе (что называется созданием сокращенного пути или обходом маршрутизатора), а не передается, как обычно, в маршрутизатор. Пакеты, для которых не обнаруживается соответствующая запись в кэше, пе-
редаются в устройство MLS-RP; такие пакеты называются инициализирующими, и это название принято в связи с тем, что указанные пакеты инициализируют процесс подготовки к их маршрутизации непосредственно в коммутаторе.
После прохождения инициализирующего пакета через маску потока MLS (как описано ниже, в шаге 7) и перезаписи информации, содержащейся в заголовке пакета (часть, содержащая данные, остается неизменной), маршрутизатор передает этот пакет на следующий участок маршрута по пути к получателю. Теперь этот пакет называется разрешающим. После того как такой пакет возвращается в то же устройство MLS-SE, из которого он исходил, создается сокращенный путь MLS и информация об этом пути помещается в кэш MLS. Теперь перезапись такого пакета и всех следующих за ним аналогичных пакетов (называемых потоком') выполняется непосредственно аппаратным обеспечением коммутатора, а не программным обеспечением маршрутизатора. Создание сокращенного пути MLS для конкретного потока в устройстве MLS-SE возможно только при том условии, что через устройство MLS-SE проходят и инициализирующий, и разрешающий пакеты. (Вот почему при использовании средств MLS необходимо соблюдать определенные требования к сетевой топологии.) Следует помнить, что основное назначение средств MLS состоит в создании пути связи между двумя устройствами, находящимися в разных виртуальных локальных сетях, но подключенных к одному и тому же коммутатору, с целью обойти маршрутизатор и тем самым повысить производительность сети.
Рис. 23.7. Три основных этапа создания сокращенного пути с помощью протокола MLSP: обработка инициализирующего пакета, разрешающего пакета и кэширование
Степень подобия пакетов, входящих в один поток, а значит, и содержание самих потоков может устанавливаться с использованием маски потока (которая, по сути, представляет собой список доступа). При этом можно регламентировать применение адреса получателя, ааресов отправителя и получателя или адресов отправителя и получателя наряду с информацией уровня 4. Следует отметить, что первый пакет потока всегда проходит через маршрутизатор, а в дальнейшем осуществляется локальная коммутация пакетов этого потока. Каждый поток является однонаправленным, поэтому, например, для обеспечения взаимодействия между двумя персональными компьютерами необходимо ввести в кэш и использовать два сокращенных пути. Основное назначение протокола MLSP состоит в подготовке, создании и сопровождении таких сокращенных путей.
Применение этих трех компонентов (устройств MLS-RP и MLS-SE, а также протокола MLSP) позволяет освободить исключительно важные ресурсы маршрутизатора, передав часть его функций другим сетевым устройствам. Средства MLS предоставляют простой и высокоэффективный способ повышения производительности локальной сети, применение которого зависит от топологии и конфигурации сети.
Устранение нарушений в работе средств MLS IP
На рис. 23.8 приведена общая блок-схема процесса устранения нарушений в работе средств MLS IP. Она была составлена на основе изучения зафиксированных к моменту подготовки настоящего раздела наиболее типичных случаев нарушений в работе средств MLS IP, которые рассматривались в центре Cisco ТАС и с которыми сталкивались заказчики Cisco и специалисты ТАС. Средства MLS являются весьма надежными, и при их эксплуатации, как правило, не возникает никаких проблем. Но при возникновении какого-либо нарушения следует руководствоваться приведенным ниже описанием, чтобы определить, к какому типу относятся проблемы MLS IP, с которыми вы столкнулись. Ниже перечислены некоторые основные требования, которые должны быть выполнены до начала процедуры устранения неисправности.
Необходимо изучить основные этапы настройки конфигурации, с помощью которых можно разрешить применение средств MLS IP в маршрутизаторе и коммутаторах, и успешно их выполнить. Превосходные источники информации по этой теме перечислены в конце настоящей главы.
Необходимо разрешить применение IP-маршрутизации в устройстве MLS-RP (применение этих средств разрешено по умолчанию). Если результаты выполнения команды show run показывают, что в состав глобальной конфитурации входит команда no ip routing, это означает, что IP-маршрутизация отменена, и поэтому средства MLS IP не будут функционировать.
Должна существовать связь по протоколу IP между устройствами MLS-RP и MLS-SE. Для проверки этого можно выполнить эхо-тестирование IP-адресов маршрутизатора с коммутатора и определить, отображаются ли в ответ восклицательные знаки.
Интерфейсы MLS-RP маршрутизаторы должны находиться в состоянии "up/up". Для проверки этого введите в маршрутизаторе команду show ip interface brief.
Предостережение
После внесения в конфигурацию маршрутизатора любых изменений, которые должны стать постоянными, обязательно сохраните эти изменения с помощью команды сору running-config starting-config (у этой команды есть такие сокращенные версии, как copy run start и wr mem). Любые другие изменения в конфигурации будут потеряны после перезагрузки или сброса маршрутизатора. Следует учитывать, что устройства RSM, RSFC и MSEC представляют собой маршрутизаторы, а не коммутаторы. В отличие от этого, изменения, внесенные в строке приглашения к вводу команд коммутатора семейства Catalyst 5ххх или бххх, сохраняются автоматически.
Рис. 23.8. Блок-схема основных этапов устранения нарушений в работе средств MLS IP
Шаг 1. Проверка соблюдения требований к минимальному составу аппаратных и программных средств.
Модернизируйте устройства MLS-RP и MLS-SE с тем, чтобы они соответствовали минимальным требованиям к программным и аппаратным средствам. Для устройства MLS-RP не требуется дополнительное аппаратное обеспечение. Хотя настройка конфигурации MLS может быть выполнена и с помощью интерфейсов, не обеспечивающих формирование магистральных каналов, подключение к устройству MLS-SE обычно осуществляется через интерфейсы виртуальной локальной сети (как при использовании модуля RSM) или предусматривает поддержку магистральных каналов (конфигурация которых может быть подготовлена для передачи информации нескольких виртуальных локальных сетей путем настройки методов ISL или 802. lq).
Следует также учитывать, что ко времени написания настоящего раздела внешняя поддержка MLS осуществлялась только в маршрутизаторах семейств 7500, 7200, 4700, 4500 и 3600. В настоящее время функции устройств MLS-RP могут выполнять только эти внешние маршрутизаторы, а также маршрутизаторы, которыми может быть укомплектовано семейство коммутаторов Catalyst 5ххх или бххх (такие как модули RSM и платы RSFC для семейства Catalyst 5ххх и платы MSEC для семейства Catalyst бххх). Для работы платы MSEC требуется также плата РЕС (Policy Feature Card — плата поддержки правил), и обе эти платы должны быть установлены в блоке Supervisor коммутатора Catalyst бххх. В настоящее время средства MLS IP являются стандартными для IOS 12.0 и последующих версий программного обеспечения маршрутизатора. Для программного обеспечения IOS с версиями ниже IOS 12.0 обычно требуется специальная модификация; для поддержки MLS IP установите новейшие образы системы IOS 11.3, которые имеют в именах файлов буквы “WA”.
Для использования коммутатора семейства Catalyst 5ххх в качестве устройства MLS-SE в нем должна быть установлена плата NFFC; эта плата устанавливается в модуле Supervisor коммутатора Catalyst и включена в стандартную поставку нового ряда модулей Supervisor коммутаторов Catalyst 5ххх (с 1999 года). Плата NFFC не поддерживается в модулях Supervisor ! или II и может устанавливаться дополнительно в первых версиях модулей Supervisor III. Кроме того, для поддержки средств MLS IP требуется, как минимум, версия Catalyst OS 4.1.1. В отличие от этого, в семействе Catalyst бххх необходимые аппаратные средства поставляются в качестве стандартного оборудования, и поддержка MLS IP обеспечивается с первого выпуска программного обеспечения Catalyst OS, т.е. с версии 5.1.1 (фактически средства MLS IP являются существенной и предусмотренной по умолчанию составляющей, обеспечивающей высокую производительность этого коммутатора). Поскольку поддержка MLS IP предусмотрена во всех новых выпускаемых платформах и программных средствах, необходимо проверять документацию и примечания к выпуску и, как правило, устанавливать новейшие версии программного обеспечения в той модификации, которая соответствует требованиям к характеристикам конкретной сети. Всегда просматривайте примечания к выпуску и консультируй. тесь с торговым представителем Cisco по поводу новых возможностей поддержки MLS и направлений их дальнейшего развития.
Для проверки установленного аппаратного и программного обеспечения в маршрутизаторе применяется команда show version, а в коммутаторе — команда show module.
Примечание
Ко времени написания этой книги семейство коммутаторов Catalyst бххх не поддерживало внешние устройства MLS-RP. В качестве устройства MLS-RP должна применяться одна из плат MSEC.
Шаг 2. Проверка того, доступны ли все устройства, выполняющие функции отправителей и получателей в составе различных виртуальных локальных сетей, с одного и того же устройства MLS-SE, которое обращается к единственному общему устройству MLS-RP.
В соответствии с основным требованием к топологии сети, в которой применяются средства MLS, маршрутизатор должен иметь путь к каждой из виртуальных локальных сетей. Напомним, что задачей MLS является создание сокращенного пути между двумя виртуальными локальными сетями, чтобы “маршрутизацию” пакетов, которые передаются между двумя оконечными устройствами, мог выполнять коммутатор, что позволило бы освободить маршрутизатор для выполнения других задач. Коммутатор фактически не выполняет маршрутизацию, а просто перезаписывает фреймы таким образом, чтобы для оконечных устройств эти фреймы не отличались от фреймов, проходящих через маршрутизатор. Если отправитель и получатель находятся в одной и той же виртуальной локальной сети, то устройство MLS-SE передает этот фрейм из одного порта в другой (не перезаписывая его и не используя средства MLS), точно так же, как передают фреймы обычные коммутаторы в среде сети, соединенной прозрачными мостами, и сокращенный путь MLS не создается. В сети может быть установлено несколько коммутаторов и маршрутизаторов, и на пути какого-то потока может даже находиться несколько коммутаторов, но если маршрут между двумя оконечными устройствами, в состав которого требуется включить сокращенные пути MLS, проходит через несколько виртуальных локальных сетей, то в каждой из них должно находиться единственное устройство MLS-RP, применяемое для формирования сокращенного пути.
Иными словами, сокращенный путь MLS создается в том случае, если поток от отправителя к получателю должен в каком-то устройстве MLS-RP пересечь границу между виртуальными локальными сетями, а пара пакетов, состоящая из инициализирующего и разрешающего пакетов, проходит через устройство MLS-SE, связанное с тем же устройством MLS-RP. Если эти критерии не соблюдаются, то маршрутизация пакета будет осуществляться обычным образом, без использования средств MLS. В конце данной главы приведен перечень документов, содержащих схемы и описания поддерживаемых и неподдерживаемых сетевых топологий.
Шаг 3. Проверка того, содержится ли оператор mis гр ip и в глобальной конфигурации, и в конфигурации интерфейса устройства MLS-RP.
Если такой оператор mis гр ip отсутствует, введите его соответствующим образом в глобальную конфигурацию или в конфигурацию интерфейса MLS-RP. Этот этап настройки конфигурации является обязательным для всех марщру-
тизаторов, кроме тех, для которых применение средств MLS IP разрешено автоматически (таких как плата MSFC коммутатора Catalyst бххх). В большинстве устройств MLS-RP (маршрутизаторов, подготовленных для использования средств MLS IP) этот оператор должен одновременно входить в состав глобальной конфигурации и присутствовать в конфигурации интерфейса.
Примечание
При настройке конфигурации MLS-RP не забудьте также включить команду mis гр management-interface в конфигурацию одного из интерфейсов MLS IP такого устройства. Этот обязательный этап настройки выполняется для того, чтобы устройство MLS- RP имело информацию о том, через какой интерфейс оно должно передавать сообщения MLSP для взаимодействия с устройством MLS-SE. Следует подчеркнуть, что эту команду необходимо включить в конфигурацию только одного интерфейса.
Шаг 4. Определение того, не выполнена ли в устройстве MLS-RP настройка конфигурации таких средств, которые автоматически отменяют применение средств MLS в рассматриваемом интерфейсе.
Некоторые опции конфигурации маршрутизатора не совместимы со средствами MLS. К ним относится поддержка учетных записей IP, шифрование, сжатие, защита на уровне IP, преобразование сетевых адресов (NAT — Network Address Translation) и применение согласованной скорости доступа (CAR — Committed Access Rate). Для получения дополнительной информации перейдите по ссылкам, приведенным в конце этой главы, к ресурсам, касающимся настройки конфигурации MLS IP. Пакеты, проходящие через интерфейс маршрутизатора, настройка конфигурации которого была выполнена с использованием одного из этих средств, должны маршрутизироваться обычным образом; при этом сокращенный путь MLS не создается. Для обеспечения функционирования MLS необходимо отменить применение этих средств в интерфейсе MLS-RP.
Еще одним важным средством, влияющим на работу MLS, являются входные и выходные списки доступа. Дополнительная информация об этой опции приведена в описании масок потока (шаг 7).
Шаг 5. Проверка того, распознает ли устройство MLS-SE адрес устройства MLS-RP.
Для обеспечения функционирования MLS коммутатор должен распознать маршрутизатор как устройство MLS-RP. Внутренние устройства MLS-RP (еще раз отметим, что к ним относится модуль RSM или плата RSFC коммутатора семейства Catalyst 5ххх и плата MSFC коммутатора семейства Catalyst бххх) распознаются автоматически устройством MLS-SE, в котором они установлены. При использовании внешнего устройства MLS-RP необходимо явно задать в коммутаторе адрес маршрутизатора. Этот адрес фактически не является IP-адресом, хотя адреса внешних устройств MLS-RP выбираются из списка IP-адресов, входящих в конфигурацию интерфейсов маршрутизатора, т.е. он просто представляет собой идентификатор маршрутизатора, MLS-ID. При использовании внутренних устройств MLS-RP идентификатор MLS-ID фактически не является обычно даже IP-адресом, входящим в конфигурацию маршрутизатора. Поскольку внутренние устройства MLS-RP вносятся в конфигурацию автоматически, этот адрес обычно представляет собой адрес петли
обратной связи (127.0.0.x). Для обеспечения функционирования MLS необходимо включить в конфигурацию устройства MLS-SE идентификатор MLS-ID, который можно найти в конфигурации устройства MLS-RP.
Чтобы найти идентификатор MLS-ID, необходимо вызвать на выполнение команду show mis гр в маршрутизаторе, а затем ввести этот идентификатор в конфигурацию маршрутизатора с помощью команды set mis include <MLS-ID>. Это — обязательный этап настройки конфигурации при использовании внешних устройств MLS-RP.
Предостережение
Смена IP-адреса интерфейсов MLS-RP, а затем перезагрузка маршрутизатора может привести к выбору процессом MLS в маршрутизаторе нового идентификатора MLS-ID. Этот новый идентификатор может отличаться от того идентификатора MLS-ID, который был включен в конфигурацию устройства MLS-SE вручную, а это может вызвать прекращение функционирования MLS. Это — не дефект программного обеспечения, а просто результат попытки коммутатора вступить во взаимодействие с использованием идентификатора MLS-ID, который больше не является действительным. Обязательно включите этот новый идентификатор MLS-ID в конфигурацию коммутатора для возобновления нормальной работы средств MLS. Для этого может также потребоваться запретить, а затем снова разрешить применение средств MLS IP.
Примечание
Если устройство MLS-SE не подключено непосредственно к устройству MLS-RP, то адрес, который должен быть включен в конфигурацию устройства MLS-SE, может выглядеть как адрес петли обратной связи, упомянутый выше: адрес коммутатора, подключенного между устройствами MLS-SE и MLS-RP. Идентификатор MLS-ID необходимо ввести в состав конфигурации, даже если устройство MLS-RP является внутренним. По отношению ко второму (промежуточному) коммутатору устройство MLS-RP представляется как внешний маршрутизатор, поскольку устройства MLS-RP и MLS-SE не установлены в одном и том же корпусе.
Шаг 6. Проверка того, находятся ли интерфейс MLS-RP и устройство MLS-SE в одном и том же разрешенном домене VTP.
Для работы средств MLS требуется, чтобы компоненты MLS, в том числе оконечные станции, находились в одном и том же домене VTP. Протокол VTP представляет собой протокол уровня 2, применяемый для управления виртуальными локальными сетями в нескольких коммутаторах Catalyst из центрального коммутатора; он позволяет администратору создать или удалить любую виртуальную локальную сеть сразу во всех коммутаторах домена, не выполняя такую операцию в каждом отдельном коммутаторе домена. Для взаимодействия устройств MLS-SE и MLS-RP применяется протокол MLSP, который не может функционировать за пределами одного домена VTP. Если сетевой администратор разрешил применение протокола VTP в коммутаторах (применение протокола VTP в коммутаторах семейства Catalyst 5ххх и бххх разрешено по умолчанию), необходимо вызвать на выполнение в коммутаторе команду show vtp domain, чтобы он определил, в какой домен VTP было поме-
щено устройство MLS-SE. Во всех устройствах MLS-RP, кроме платы MSEC коммутатора Catalyst бххх, в которой средства MLS, по сути, реализованы как средства, ориентированные на простое включение, введите на следующих этапах настройки информацию о домене VTP в конфигурацию каждого из интерфейсов MLS маршрутизатора. Такая подготовка позволяет обеспечить передачу многоадресатных пакетов MLSP между устройствами MLS-RP и MLS- SE и тем самым обеспечить функционирование MLS.
Для этого в режиме настройки конфигурации интерфейса устройства MLS-RP необходимо ввести следующие команды.
no mis гр ip. Позволяет отменить применение средств MLS в рассматриваемом интерфейсе MLS-RP перед внесением изменений в домен VTP.
mis гр vtp-domain <VTP domain пате>. Позволяет задать в каждом интерфейсе с поддержкой MLS имя домена VTP, <VTP domain пате», которое совпадает с именем, заданным в коммутаторе.
mis гр vlan-id <VLAN #>. Требуется только для внешних интерфейсов MLS-RP, не поддерживающих средства формирования магистральных каналов ISL.
mis гр management-interface. Выполняется только в одном интерфейсе устройства MLS-RP. Этот этап настройки является обязательным и позволяет ввести в устройство MLS-RP информацию о том, через какой интерфейс должны передаваться сообщения MLSP.
mis гр ip. Позволяет снова разрешить применение средств MLS в рассматриваемом интерфейсе устройства MLS-RP.
Для изменения имени домена VTP в конфигурации устройства MLS-SE введите следующую команду в приглашении к вводу команд enable системы Catalyst OS коммутатора:
set vtp domain name <VTP domain name»
Для обеспечения работы средств MLS необходимо разрешить применение средств VTP в коммутаторе:.
set vtp enable
Шаг 7. Проверка того, соответствуют ли друг другу маски потоков в устройствах MLS-RP и MLS-SE.
Маска потока представляет собой фильтр, применяемый средствами MLS для определения того, должен ли быть создан сокращенный путь для данного потока. Маска потока должна быть введена в конфигурацию сетевым администратором. Маска потока полностью аналогична списку доступа в том отношении, что позволяет определить критерии выбора пакетов с разной степенью детализации, и чем подробнее определены эти критерии, тем больше сведений, содержащихся в пакете, должно быть проверено процессом MLS для определения соответствия пакета этим критериям. Чтобы уточнить, к какой части трафика относятся сокращенные пути, создаваемые средствами MLS, маску потока можно задать как более общую или более конкретную; по сути, маска потока — это механизм фильтрации.
Предусмотрены три разных режима фильтрации MLS IP: destination-ip, source-destination-ip и full-flow-ip. Режим фильтрации destination-ip ис-
пользуется по умолчанию, если к интерфейсу маршрутизатора с поддержкой MLS не применяется какой-либо список доступа. Режим source-destination-ip используется в случае применения стандартного списка доступа, а режим full-flow-ip вступает в действие, если применяется расширенный список доступа. Режим MLS работы устройства MLS-RP неявно определяется в зависимости от типа списка доступа, применяемого к определенному интерфейсу. В отличие от этого, в устройстве MLS-SE режим MLS должен быть явно введен в состав конфигурации. Итак, выбор подходящего режима фильтрации позволяет настроить конфигурацию средств MLS таким образом, чтобы при создании сокращенного пути MLS выполнялась только проверка адреса получателя, или адресов отправителя и получателя, или даже наряду с адресами проверялась такая информация уровня 4, как номера портов TCP/UDP.
Настройка конфигурации режима MLS может быть выполнена и в устройстве MLS-RP, и в устройстве MLS-SE, причем, как правило, соответствующие конфигурации должны совпадать. Но если предполагается, что со временем возникнет необходимость в использовании такого режима MLS, как sourcedestination-ip или full-flow-ip, то лучше всего выполнить настройку их конфигурации в маршрутизаторе с помощью соответствующего списка доступа. В процессе функционирования средств MLS всегда осуществляется выбор наиболее конкретной маски; при этом маске потока, входящей в конфигурацию MLS-RP, отдается предпочтение перед маской потока, заданной в устройстве MLS-SE. Но следует соблюдать осторожность при установке в коммутаторе режима MLS, отличного от применяемого по умолчанию режима destination-ip, поскольку если этот режим не будет совпадать с режимом MLS маршрутизатора, то функционирование средств MLS будет нарушено. При использовании режимов source-destination-ip и full-flow-ip обязательно примените список доступа к соответствующему интерфейсу маршрутизатора. Без применения списка доступа режим MLS устанавливается по умолчанию равным destination-ip, даже если в конфигурации задано другое значение.
Предостережение •
При внесении каждого изменения в определение маски потока все кэшированные данные о потоках MLS уничтожаются, независимо от того, было ли такое изменение внесено в конфигурацию устройства MLS-RP или MLS-SE, и происходит перезапуск процесса MLS. Очистка кэша может также произойти при выполнении команды clear ip route-cache в маршрутизаторе. Кроме того, очистка кэша и отмена средств MLS происходит после вызова на выполнение глобальной команды конфигурации маршрутизатора no ip routing, которая отменяет IP-маршрутизацию и фактически превращает маршрутизатор в прозрачный мост (напомним, что маршрутизация является предпосылкой применения средств MLS). Каждая из описанных выше ситуаций может на время (но в очень значительной степени) снизить производительность маршрутизатора в производственной сети, поскольку маршрутизатор будет испытывать пиковую нагрузку в течение всего периода создания новых сокращенных путей. Не следует забывать, что теперь маршрутизатор вынужден обрабатывать все те потоки, которые перед этим обрабатывались коммутатором.
Примечание
Рекомендуется не злоупотреблять применением масок потока, настройка конфигурации которых выполнена с учетом информации уровня 4, особенно если в качестве устройства MLS-SE применяется один из коммутаторов семейства Catalyst 5000. Дело в том, что при этом маршрутизатору приходится подробно анализировать каждый пакет, проходящий через интерфейс, поэтому значительная часть преимуществ MLS теряется. Но при использовании в качестве устройства MLS-SE одного из коммутаторов семейства Catalyst бххх эта проблема становится менее значимой, поскольку даже сами порты этого коммутатора способны распознавать информацию уровня 4.
Примечание
До недавнего времени средства MLS не поддерживали настройку конфигурации масок потоков, входящих в интерфейс MLS-RP; поддерживались только маски исходящих потоков. Теперь появилась возможность поддерживать и маски входящих потоков; для этого кроме обычных команд настройки конфигурации MLS-RP необходимо ввести в конфигурацию интерфейса маршрутизатора команду mis гр ip input-acl.
Шаг 8. Проверка того, не обнаруживаются ли в коммутаторе постоянно вырабатываемые сообщения об ошибках MLS "Too many moves".
Как было указано в приведенном выше предупреждении, изменение маски потока, очистка кэша маршрутов или глобальная отмена применения IP- марщругизации может вызвать очистку кэща. При других обстоятельствах может также произойти уничтожение всех или большинства записей в кэше, и это приведет к появлению сообщений об ошибках MLS "Too many moves". Такое сообщение может принимать несколько различных форм, но во всех этих фермах содержатся три указанных слова. Кроме уже упомянутых, наиболее распространенной причиной этой ошибки является ситуация, в которой коммутатор накапливает информацию о многих одинаковых МАС-адресах Ethernet в одной и той же виртуальной локальной сети; стандарты Ethernet не допускают появления одинаковых МАС-адресов в одной виртуальной локальной сети. Если указанное сообщение появляется редко или только несколько раз подряд, то нет причин для беспокойства. Средства MLS являются вполне надежными, и это сообщение иногда может появляться при таких обычных событиях в сети, как создание в портах соединений с персональными компьютерами. Но если указанное сообщение непрерывно появляется в течение нескольких минут, оно может оказаться признаком более серьезного нарушения в работе.
Основная причина возникновения такой ситуации обычно заключается в наличии двух устройств с одинаковыми МАС-адресами, фактически подключенных к виртуальной локальной сети, или в появлении физического цикла в определенной виртуальной локальной сети (или в нескольких виртуальных локальных сетях, если применяется мостовое перенаправление трафика, передаваемого между этими широковещательными доменами). Для поиска такого цикла и его устранения воспользуйтесь рекомендациями по устранению нарушений в работе алгоритма распределенного связующего дерева, которые приведены в разделе “Устранение нарушений в работе средств протокола распределенного связующего дерева и
связанные с этим проектные соображения” ниже в этой главе, а также в следующем совете. Кроме того, временное нарушение стабильности работы сети (и средств MLS) могут вызвать любые резкие изменения топологии (периодически самопроизвольно закрывающиеся и открывающиеся интерфейсы маршрутизатора, неисправные сетевые платы и т.д.).
Совет
Вызвав на выполнение в коммутаторе команды show mis notification и show looktable, вы сможете определить правильное направление поиска повторяющегося МАС-адреса или физического цикла. Первая команда позволяет получить значение параметра ТА, а вторая команда, show looktable <ТА value>, возвращает МАС-адрес, который может оказаться причиной этой проблемы.
Команды и снимки с экрана
Описания и подробные примеры применения команд MLS IP для настройки конфигурации маршрутизатора и коммутатора содержатся в превосходной документации, перечисленной в разделе “Дополнительная информация”.
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco
Прежде чем обратиться в центр Cisco ТАС, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе своей системы.
Кроме того, выполните следующие действия и подготовьте указанные документы, которые позволят специалистам центра Cisco ТАС быстрее предоставить вам помощь.
Вызовите на выполнение команду show module во всех коммутаторах, с которыми может быть связано рассматриваемое нарушение в работе, и сохраните полученные результаты.
Вызовите на выполнение команду show vtp domain во всех коммутаторах, с которыми может быть связано рассматриваемое нарушение в работе, и сохраните полученные результаты.
Вызовите на выполнение команду show trunk <mod_num/port_num> во всех портах, с которыми может быть связано рассматриваемое нарушение в работе, и сохраните полученные результаты.
Вызовите на выполнение команду show port <mod_num/port_num> capabilities во всех портах, с которыми может быть связано рассматриваемое нарушение в работе, и сохраните полученные результаты.
Вызовите на выполнение команду show tech-support в устройстве MLS-RP и сохраните полученные результаты.
Вызовите на выполнение команду show mis гр в устройстве MLS-RP, команды show mis и sh mis include во всех устройствах MLS-SE, и сохраните полученные результаты.
Может потребоваться вызов на выполнение дополнительных команд и сохранение полученных результатов, в зависимости от характера проблемы.
Эффективному решению проблемы может способствовать также наличие четкой топологии сети и возможность получения доступа по коммутируемой линии или по протоколу Telnet.
Устранение нарушений в работе средств протокола распределенного связующего дерева
Примечание
Текст настоящего раздела полностью взят из документа www.cisco.com/warp/customer/ 473/16.html, находящегося на Web-узле Cisco.
Основное назначение алгоритма STA состоит в удалении циклов, возникающих при наличии избыточных каналов в сетях, соединенных мостами. Основанный на этом алгоритме протокол STP функционирует на уровне 2 модели OSI и обеспечивает выбор таких портов, через которые будет в конечном итоге перенаправляться трафик, и таких портов, которые будут заблокированы в результате взаимодействия мостов с помощью сообщений BPDU. Но функционирование этого протокола в некоторых особых случаях может быть нарушено, и в создавшейся ситуации устранение этих нарушений может оказаться в конкретной сети очень сложным. Специфика данной конкретной области поиска неисправностей такова, что можно даже утверждать, что наиболее важная часть работы по устранению нарушений в работе протокола должна быть выполнена еще до возникновения самой проблемы.
Этот раздел не является полным руководством по проектированию локальных сетей и содержит только перечень рекомендаций, которые помогут создать надежную, бесперебойно функционирующую сеть, по меньшей мере, в той части, которая касается мостового перенаправления. В настоящем разделе не приведены подробные сведения о самом протоколе, а рассматриваются только следующие темы.
Причины, которые могут вызвать нарушения в работе протокола STP.
Информация, необходимая для определения причины возникновения проблем.
Рекомендации по проектированию сети, позволяющие свести к минимуму риск нарушений в работе алгоритма распределенного связующего дерева и упростить устранение таких нарушений.
Нарушения в работе протокола распределенного связующего дерева
Нарушения в работе алгоритма STA обычно приводят к появлению цикла мостового перенаправления (а не цикла в распределенном связующем дереве, поскольку такой цикл не может появиться при использовании протокола STP). Многие заказчики, обращаясь в ТАС за помощью в устранении нарушений в работе алгоритма распределенного связующего дерева, высказывают мнение, что причиной является ошибка в программном обеспечении STP, но опыт показывает, что такая ситуация возникает очень редко. Даже если причиной нарушения является сбой в работе программного обеспечения, цикл мостового перенаправ-
ления в среде STP всегда начинается с порта, который должен быть заблокирован, а вместо этого перенаправляет трафик.
Необходимо разобраться в том, что может заставить заблокированный порт перейти в режим перенаправления. Для этого вначале необходимо вспомнить, по каким причинам тот или иной порт переходит в заблокированное состояние. В каждой локальной сети имеется один назначенный мост, который отвечает за проведение трафика своей локальной сети по направлению к корневому мосту.
На рис. 23.9 мост В был выбран в качестве назначенного, а мост С заблокирован, поскольку он предоставляет лишь альтернативный путь к корневому мосту. Разберемся в том, почему был заблокирован мост С, а не В. На практике для этого применяются сообщения BPDU, которыми обмениваются мосты В и С локальной сети. В данном случае сообщение BPDU, передаваемое мостом В, показывает, что этот мост имеет более высокий приоритет по сравнению с мостом С. Мост В непрерывно рассылает сообщения BPDU, подтверждающие его более высокий приоритет по сравнению с другими мостами в данной локальной сети. Но если мост С по каким-то причинам не получает такие сообщения BPDU в течение определенного времени (называемого максимальным сроком существования информации), которое по умолчанию составляет 20 секунд, он переходит в режим перенаправления.
Рис. 23.9. Заблокированный порт моста С постоянно получает сообщения BPDU от моста В
Важное примечание
Для того чтобы порт оставался заблокированным, он должен постоянно принимать сообщения BPDU от порта с более высоким приоритетом.
В следующих подразделах описаны различные ситуации, которые могут привести к нарушениям работы алгоритма STA. Основная часть этих нарушений фактически обусловлена потерей значительной части сообщений BPDU, что приводит к переходу заблокированных портов в режим перенаправления.
Несоответствие режимов передачи
Одной из самых распространенных ошибок в конфигурации является несоответствие режимов передачи в канале типа “точка-точка”. Такая ситуация особенно часто возникает, если конфигурация устройства, находящегося на одном конце канала, жестко закодирована на использование дуплексного режима передачи. Если в конфигурации устройства на другом конце канала будет по-прежнему предусмотрен режим автоматического согласования, это устройство в конечном итоге перейдет в полудуплексный режим передачи (поскольку порт с жестко закодированным режимом передачи не может больше принимать участия в согласовании режима передачи).
Самый неблагоприятный сценарий развития событий возникает в том случае, если мост, передающий сообщения BPDU, настраивается на использование в канале полудуплексного режима передачи, а конфигурация взаимодействующего с ним устройства настроена на использование дуплексного режима передачи. Как показано на рис. 23.10, несоответствие режимов передачи в канале между мостами А и В может легко привести к циклу мостового перенаправления. Поскольку конфигурация моста в настроена на работу в дуплексном режиме, этот мост не выполняет операцию контроля несущей перед доступом к каналу. Поэтому мост В приступает к передаче фреймов, даже если этот канал уже используется мостом А. Это нарушение в работе воспринимается мостом А, который обнаруживает коллизию и выполняет алгоритм отсрочки перед попыткой повторной передачи своего фрейма. В результате возникает такая ситуация, что при наличии достаточного объема трафика между мостами В и А каждый отдельный пакет (включая сообщения BPDU), отправленный мостом А, будет задержан или попадет в коллизию и в конечном итоге будет уничтожен. Согласно спецификации протокола STP, мост В, больше не получающий сообщения BPDU от моста А, обнаружит, что потеряна связь с корневым мостом. Это приведет к тому, что мост В разблокирует свой порт канала к мосту С и тем самым создаст цикл.
А (корневой) Полудуплексный режим: всеА (корневой) Полудуплексный режим: всеВВРис. 23.10. Создание цикла мостового перенаправления из-за несоответствия режимов передачиРис. 23.10. Создание цикла мостового перенаправления из-за несоответствия режимов передачи
А (корневой) Полудуплексный режим: все
А (корневой) Полудуплексный режим: все
В
В
Рис. 23.10. Создание цикла мостового перенаправления из-за несоответствия режимов передачи
Рис. 23.10. Создание цикла мостового перенаправления из-за несоответствия режимов передачи
Однонаправленный канал
Эта причина возникновения цикла мостового перенаправления встречается очень часто. Однонаправленные каналы возникают, например, из-за не обнаруженной вовремя неисправности волоконно-оптического кабеля или из-за нарушения в работе трансивера. Любые причины, приводящие к тому, что канал остается в рабочем состоянии, но обеспечивает только одностороннюю связь, являются очень опасными, так как могут нарушить работу протокола STP. На рис. 23.11 приведен самый простой пример такого нарушения.
Рис. 23.11. Возникновение цикла мостового перенаправления при наличии однонаправленного канала
Предположим, что канал между мостами А и В является однонаправленным и уничтожает трафик от А к В, передавая при этом трафик от В к А. Допустим, что мост В должен быть заблокирован. Как уже было сказано, порт может оставаться заблокированным, только если он получает сообщения BPDU от моста, имеющего более высокий приоритет. В данном случае происходит потеря всех сообщений BPDU, поступающих от моста А, и поэтому мост В в конечном итоге приступает к перенаправлению трафика, создавая цикл. Следует отметить, что в данном случае формирование распределенного связующего дерева по протоколу STP не будет выполнено должным образом, если такая неисправность обнаружится во время запуска сети. Это означает, что при таких обстоятельствах устранить нарушения в работе путем перезагрузки мостов абсолютно невозможно (хотя такая перезагрузка могла бы на время помочь в предыдущей ситуации).
Корпорация Cisco предусмотрела возможность применения протокола UDLD в коммутаторах высокого класса. Это средство позволяет обнаружить неисправную кабельную разводку или однонаправленные каналы на уровне 2 и автоматически разорвать возникающие при этом циклы, закрыв нескольких портов. В среде сети, соединенной мостами, этот протокол следует применять при любой возможности.
Искажение содержимого пакетов
К такому же нарушению в работе может также привести искажение содержимого пакетов. Если в каком-то канале слишком часто возникают физические ошибки, то может быть потеряно определенное количество подряд идущих сообщений BPDU, что может привести к переходу заблокированного порта в режим перенаправления. Такая ситуация встречается довольно редко, поскольку предусмотренные по умолчанию параметры STP выбраны весьма предусмотрительно. В частности, заблокированный порт должен не получать сообщения BPDU в течение 50 секунд и только после этого переходить в режим перенаправления, и даже единственное успешно переданное сообщение BPDU вызовет раз-
рыв цикла. Поэтому такая ситуация возникает в основном в тех случаях, если корректировка параметров STP была выполнена без должного обоснования (например, уменьшено значение максимального срока существования информации).
Ошибки, связанные с нехваткой ресурсов
Даже в коммутаторах высокого класса, выполняющих основную часть своих функций коммутации в аппаратном обеспечении с использованием специализированных микросхем, протокол STP реализован в программном обеспечении. Это означает, что при перегрузке по каким-то причинам процессора моста может возникнуть нехватка ресурсов для рассылки сообщений BPDU. Алгоритм STA обычно не требует больших затрат процессорного времени и имеет приоритет над другими процессами. Но как указано в одном из приведенных ниже разделов, “Поиск ошибок, связанных с нехваткой ресурсов”, при определении допустимого количества экземпляров программного обеспечения STP, которые могут поддерживаться определенной платформой, необходимо руководствоваться соответствующими рекомендациями.
Ошибка в настройке конфигурации средства PortFast
Средство PortFast предназначено для использования в порту, соединенном с хостом. При активизации канала, связанного с этим портом, пропускаются первые этапы алгоритма STA, и порт сразу же переходит в режим перенаправления. Но такое средство, безусловно, может оказаться опасным при неправильном применении. Если порт, который перед этим предназначался для подключения к рабочей станции, после перестановки кабеля будет использоваться для создания соединения с устройством сетевой инфраструктуры, возникнет цикл, а такие циклы необходимо сразу же устранять.
Как показано на рис. 23.12, порт pl моста А уже находится в режиме перенаправления, а конфигурация порта р2 настроена на использование средства PortFast. Мост В выполняет функции концентратора. Сразу после подключения второго кабеля к мосту А порт р2 переходит в режим перенаправления и создает цикл между портами pl и р2. Этот цикл будет разорван, как только порт pl или р2 получит сообщение BPDU, которое переведет один из этих двух портов в заблокированный режим. Но при появлении таких временных циклов возникает еще одна проблема, которая связана с тем, что трафик в цикле является очень интенсивным, поэтому мост может столкнуться с затруднениями при отправке сообщения BPDU, успешная доставка которого позволила бы разорвать цикл. Это может намного замедлить процесс восстановления распределенного связующего дерева. В последних выпусках программного обеспечения коммутаторов Catalyst высокого класса реализовано средство BPDU-Guard, которое позволяет даже закрыть такой порт, конфигурация которого настроена на использование средства PortFast, но он получает сообщения BPDU.
Непродуманная настройка параметров STP и превышение допустимого диаметра сети
Как уже было сказано, ввод в конфигурацию недопустимого значения параметра максимального срока существования информации может привести к очень нестабильной работе протокола STP. Дело в том, что в этом случае к появлению цикла может привести потеря даже нескольких подряд идущих сообщений BPDU. Еще одна проблема, которая не слишком хорошо известна, относится к диаметру сети, соединенной мостами. Предусмотренные по умолчанию параметры STP, обоснованные соот-
Подключен кабельПодключен кабельВВВременная петля: трафик перенаправляют и р1, и р2Временная петля: трафик перенаправляют и р1, и р2ветствующими расчетами, были выбраны с учетом максимального диаметра сети, равного 7. Это означает, что любые два отдельно взятых моста в сети не должны быть отделены друг от друга более чем семью мостами. Это ограничение отчасти обосновано тем, как используется поле Аде (период ожидания) в составе сообщения BPDU: по мере того как сообщение BPDU распространяется от корневого моста к листьям дерева, значение в поле Аде увеличивается после прохождения через каждый мост. В конечном итоге, после того, как значение в поле Аде сообщения BPDU превысит значение в поле максимального срока существования, это сообщение отбрасывается. Как правило, это происходит, если корневой мост находится слишком далеко от некоторых других мостов в сети. Такая проблема может снизить эффективность процесса формирования распределенного связующего дерева.
Подключен кабель
Подключен кабель
В
В
Временная петля: трафик перенаправляют и р1, и р2
Временная петля: трафик перенаправляют и р1, и р2
Р2
В
Порт р2 принял блок BPDU, которыйего немедленно заблокировал
Рис. 23.12. Временный цикл "мостового перенаправления, возникающий при неправильной настройке конфигурации средства PortFast
Ошибки в программном обеспечении
Как было указано во введении к данной главе, протокол STP принадлежит к числу самых первых средств, которое было реализованы в продуктах Cisco. Поэтому вполне можно рассчитывать на то, что оно достигло весьма высокой степени стабильности. Нарушения в работе программного обеспечения STP возникают только в очень специфичных случаях при взаимодействии с такими новыми средствами, как формирование каналов EtherChannel, но эти проблемы вскоре будут решены. Ошибка в программном обеспечении может вызвать самые различные последствия, поэтому фактически нет смысла рассматривать все ситуации, которые могут при этом возникнуть. Достаточно только еще раз подчеркнуть, что наиболее опасная ситуация состоит в неполучении портом некоторых сообщений BPDU или, вообще говоря, в переходе заблокированного порта в режим перенаправления.
Устранение нарушений в работе
К сожалению, невозможно предложить какую-либо систематическую процедуру устранения нарушений в работе протокола STP, поэтому настоящий раздел оформлен в виде контрольного списка действий, выполняемых для устранения таких нарушений. Основная часть приведенных здесь указаний касается устранения нарушений в работе, связанных с появлением цикла мостового перенаправления. Другие нарушения в работе протокола STP, которые приводят к потере связи, можно выявить традиционным способом: изучая путь, по которому должен был пройти трафик, но фактически при его прохождении возникли проблемы.
Следует отметить, что для выполнения большинства описанных здесь этапов устранения нарушений в работе необходимо иметь возможность подключаться к различным устройствам сети, соединенной мостами. Это означает, что необходимо иметь доступ к консоли. Дело в том, что, например, при устранении цикла мостового перенаправления, вероятно, не будет возможности использовать протокол Telnet.
Применение схемы сети
При устранении нарушения в работе, связанного с формированием цикла мостового перенаправления, необходимо иметь некоторые основные сведения о рассматриваемой сети.
Необходимо знать, по меньшей мере, следующее:
топологию сети, соединенной мостами;
местонахождение корневого моста;
местонахождение заблокированных портов (и избыточных каналов). '
Эти знания важны по следующим двум причинам:
устранение нарушений в работе сети возможно только в том случае, если известно, как она должна функционировать в нормальных условиях;
основная часть работы по устранению неисправностей состоит в использовании команд show для определения причин возникших ошибок, поэтому знание структуры конкретной сети позволяет сосредоточить свое внимание на наиболее важных портах ключевых устройств.
Выявление цикла мостового перенаправления
В свое время резкое увеличение объема широковещательной рассылки могло оказывать такое же влияние на сеть, как и цикл мостового перенаправления. Но в наши дни, когда применяются высокоскоростные каналы и устройства, обеспечивающие коммутацию на аппаратном уровне, уже почти невозможно, например, такое развитие событий, когда отдельный сервер выводит из строя сеть, инициировав широковещательную рассылку. Поэтому о наличии цикла мостового перенаправления теперь нельзя судить по увеличению объема трафика, и единственный способ надежного выявления таких циклов состоит в перехвате трафика, проходящего по насыщенному каналу, и проверке того, не появляются ли в нем много раз одинаковые пакеты.
Тем не менее, если все пользователи в определенном домене мостового перенаправления начинают одновременно сталкиваться с нарушениями связи, это дает основание полагать, что возник цикл мостового перенаправления.
Проверьте загрузку портов во всех устройствах сети и определите, не встречаются ли какие-либо значения, которые отличаются от обычных. Для получения дополнительной информации обратитесь к одному из следующих разделов, “Проверка степени загрузки порта”.
При использовании коммутаторов Catalyst, в которых эксплуатируется система Catalyst OS, можно легко проверить общую загрузку устройства с помощью команды show system. Эта команда очень удобна, поскольку она не только позволяет определить текущую степень загрузки объединительной платы коммутатора, но и указывает, какова была пиковая нагрузка (и в какое время она возникла). По таким моментам пиковой нагрузки можно определить, возникали ли когда-либо циклы мостового перенаправления, в которые входило данное устройство.
Быстрое восстановление связи и подготовка к устранению нарушений в будущем
Циклы мостового перенаправления оказывают исключительно неблагоприятное влияние на работу сети, соединенной мостами. При этом администраторы обычно не имеют времени на поиск причины возникновения такого цикла и предпочитают просто принять меры по скорейшему восстановлению связи. Но такой образ действий не позволяет найти реальную причину проблемы и подготовиться к ее полному устранению, когда она возникнет в будущем.
Устранение цикла путем закрытия портов
Наиболее простой способ устранения цикла мостового перенаправления состоит в закрытии вручную каждого отдельного порта, который создает избыточный канал в сети. Если есть возможность определить, в какой части сети возникли наиболее серьезные нарушения, начните закрытие портов с этого участка. А лучше всего, если это возможно, начните с закрытия портов, которые должны быть заблокированы в соответствии с алгоритмом формирования распределенного связующего дерева. После закрытия каждого порта проверяйте, восстановилась ли связь по сети на том же уровне, на каком она была к моменту возникновения цикла мостового перенаправления, поскольку действие цикла должно немедленно прекратиться после его разрыва. А определив порт, закрытие которого привело к прекращению цикла, можно со всей уверенностью предположить, что нарушение в работе возникло в том избыточном пути, в котором находится данный порт. Если этот порт должен быть заблокирован алгоритмом STA, то, вероятно, обнаружен физический канал, в котором возникла неисправность.
Регистрация событий STP в устройствах, где находятся заблокированные порты
Если невозможно точно определить первопричину проблемы (или, например, нарушение в работе возникает только на время), то необходимо разрешить регистрацию событий STP в мостах и коммутаторах сети, в которой возникает такая неисправность. Если же приходится ограничивать количество устройств, конфигурация которых должна при этом модифицироваться, то следует предусмотреть ведение журналов хотя бы в тех устройствах, где находятся заблокированные порты, поскольку цикл всегда создается только в результате перехода заблокированного порта в режим перенаправления.
IOS. Вызовите на выполнение exec-команду debug spantree events, чтобы разрешить выработку отладочной информации STP. Воспользуйтесь командой general config mode logging buffered, чтобы сохранить эту отладочную информацию в памяти устройства.
Catalyst OS. Вызовите на выполнение команду set logging level spantree 7 default, чтобы повысить применяемый по умолчанию уровень регистрации событий, относящихся к функционированию протокола STP, требующих отладки. Обязательно предусмотрите регистрацию максимального количества сообщений в памяти коммутатора с помощью команды set logging buffer 500.
Можно также попытаться направить этот вывод на устройство, где ведется системный журнал syslog. Но к сожалению, обычно при возникновении цикла мостового перенаправления теряется связь с сервером системного журнала.
Проверка портов
Как было сказано выше, необходимо прежде всего проверить работу заблокированных портов. В следующем разделе приведен список параметров, проверка которых должна быть выполнена в различных портах, а также кратко описаны команды, которые применяются на устройствах с системой IOS и компьютерах с системой Catalyst OS.
Проверка поступления сообщений BPDU в заблокированные порты
Сначала необходимо проверить, продолжают ли периодически поступать сообщения BPDU в заблокированные порты и порты корневого моста. Порт может не получать пакеты и сообщения BPDU по нескольким причинам, которые указаны ниже.
Если в устройстве эксплуатируется программное обеспечение IOS 12.0 или более поздних версий, то в выводе команды show spanning-tree bridge-group # имеется поле BPDU, которое позволяет определить количество сообщений BPDU, полученных в каждом интерфейсе. Вызвав на выполнение эту команду два-три раза подряд, вы сможете легко узнать, получает ли устройство сообщения BPDU.
Если поле BPDU в выводе команды show spanning-tree отсутствует, для проверки того, получает ли устройство сообщения BPDU, можно проще всего разрешить применение средств отладки STP с помощью команды debug spantree tree.
Если применяется система Catalyst OS, то для определения количества многоадре- сатных пакетов, полученных конкретным портом, можно выполнить команду show mac <module/port>. Но проще всего использовать для этой цели команду show span tree statistic <modulet/portt> <vlanl>. Эта команда отображает точное количество конфигурационных сообщений BPDU, полученных для определенного порта в указанной виртуальной локальной сети (если сформирован магистральный канал, то порт может относиться к нескольким виртуальным локальным сетям). Дополнительная информация приведена ниже, в разделе “Дополнительные команды системы Catalyst OS”.
Проверка соответствия режимов передачи
Чтобы определить, имеется ли несоответствие режимов передачи, безусловно, необходимо проверить устройства на обоих концах канала типа “точка-точка".
IOS. Просто вызовите на выполнение команду show interface для проверки значения скорости и режима передачи для указанного порта.
Catalyst OS. Просмотрите первые строки вывода команды show port <modulet/portt>, чтобы определить, какие значения скорости и режима передачи введены в конфигурацию рассматриваемого порта.
Проверка степени загрузки порта
Как было описано выше, перегрузка интерфейса может вызвать нарушение при передаче исключительно важных сообщений BPDU. А слишком интенсивная нагрузка канала может также указывать на наличие цикла мостового перенаправления.
IOS. Вызовите на выполнение команду show interface для определения степени загрузки интерфейса. Здесь представляют интерес несколько полей (Load, Packets Input/Output и т.д.).
Catalyst OS. Для просмотра статистических данных о пакетах, передаваемых и принимаемых через порт, воспользуйтесь командой show mac «module!/port!>. Команда show top автоматически оценивает загрузку порта за период времени, равный 30 секундам, и отображает данные об использовании пропускной способности, выраженные в процентах (возможны также другие опции организации вывода). Кроме того, команда show system позволяет получить данные о степени загрузки объединительной платы, несмотря на то, что она не предоставляет сведения о конкретных портах, которые также важны.
Проверка наличия искаженных пакетов
IOS. Проверьте, не содержатся ли слишком высокие значения в полях с данными об ошибках вывода в результатах выполнения команды show interface.
Catalyst OS. Вызовите на выполнение команду show port «module!/porti>, чтобы получить более подробные сведения о трафике, которые представлены в полях Aling-Err, FCS-Err, Xmit-Err, Rcv-Err и Undersize. Еще более подробные статистические данные можно получить с помощью команды show counters «module!/рог t!>.
Дополнительные команды системы Catalyst OS
Программное обеспечение, предназначенное для коммутатора Catalyst, предоставляет более подробную информацию по устранению нарушений в работе протокола STP, чем система IOS. Команда show spantree statistics «module!/port!> «vlan!> позволяет получить очень точную информацию о конкретном порте. Вызовите на выполнение эту команду в портах, которые могут явиться причиной нарушения в работе, и обратите особое внимание на следующие поля.
Forward trans count. В этом счетчике накапливается информация о том, сколько раз порт переходил из режима обучения в режим перенаправления. В стабильной топологии этот счетчик должен всегда быть равен 1. Он переустанавливается в 0, если соответствующий порт был закрыт, а затем открыт. Поэтому если значение этого счетчика превышает 1, это означает, что переходы между указанными режимами, которые произошли в этом порту, являются результатом повторных вычислений распределенного связующего дерева по протоколу STP, а не сбоя в работе самого канала.
Max age expiry count. Этот счетчик накапливает информацию о количестве случаев, когда для данного канала истекло значение максимального срока существования. Как правило, порт ожидает возобновления поступления внезапно прекратившихся сообщений BPDU в течение периода времени, называемого максимальным сроком существования (значение которого по умолчанию составляет
20 секунд), и только после этого начинает рассматривать назначенный мост как прекративший свое функционирование. Каждый раз при возникновении такого события значение счетчика наращивается. Поэтому, если значение этого счетчика не равно нулю, это означает, что по каким-то причинам в этой локальной сети назначенный мост работает нестабильно или возникают проблемы при передаче от него сообщений BPDU.
Поиск ошибок, связанных с нехваткой ресурсов
Как было описано выше, высокая степень загрузки процессора может вызвать нарушение работы системы, в которой эксплуатируется алгоритм STA. Ниже описаны способы, с помощью которых можно проверить, не испытывает ли соответствующее устройство нехватку ресурсов процессора.
IOS. Вызовите на выполнение команду show processes cpu. Проверьте, не подходит ли степень загрузки процессора слишком близко к 100%.
Catalyst OS. Найдите поле RsrcErrors (сокращение от resource error) в выводе команды show inband (в некоторых супервизорах эта команда называется show biga). В целом следует отметить, что значение этого счетчика наращивается, если процессор становится слишком перегруженным и не может выполнить некоторые свои задачи. Предусмотрено определенное ограничение на количество различных экземпляров программного обеспечения STP, которое может поддерживаться машиной супервизора. (Дополнительная информация об этом содержится в примечаниях к выпуску применяемого программного обеспечения.)
Ниже приведены сводные данные по ограничениям, которые относятся к ряду Catalyst 4000/5000/6000.
Убедитесь в том, что общее количество логических портов во всех экземплярах программного обеспечения STP для различных виртуальных локальных сетей не превышает максимального количества, поддерживаемого для каждого типа машины супервизора и конфигурации памяти. Для вычисления суммы логических портов в коммутаторе применяется команда show spantree summary и следующая формула:
(количество отличных от ATM магистральных каналов х количество активных виртуальных локальных сетей в каждом таком магистральном канале)
+ 2 * (количество магистральных каналов ATM х количество активных виртуальных локальных сетей в каждом таком магистральном канале)
+ количество портов, в которых не функционирует магистральный канал.
Суммарное количество логических портов, рассчитанных по этой формуле, должно быть меньше или равно указанным ниже значениям.
В коммутаторах ряда Catalyst 4000:
1500, если коммутатор укомплектован блоком Supervisor Engine I или II.
В коммутаторах ряда Catalyst 5000:
200, если коммутатор укомплектован блоком Supervisor Engine I (с динамическим ОЗУ на 8 Мбайт);
400, если коммутатор укомплектован блоком Supervisor Engine I (с динамическим ОЗУ на 20 Мбайт);
1500, если коммутатор укомплектован блоком Supervisor Engine II или III F;
1800, если коммутатор укомплектован блоком Supervisor Engine II G или III G;
4000, если коммутатор укомплектован блоком Supervisor Engine III.
В коммутаторах ряда Catalyst 6000:
4000, если коммутатор укомплектован блоком Supervisor.
Отмена ненужных средств
В основе методов поиска неисправностей лежит выявление нарушений в работе, возникших в настоящее время в сети. Поэтому отмена максимально возможного количества средств, без которых можно обойтись в данный момент, позволяет упростить структуру сети и облегчить поиск проблемы. Например, логические каналы EtherChannel представляют собой развитое средство, которое функционирует на более низком уровне по сравнению с протоколом STP и позволяет связать несколько различных физических каналов в один логический канал. Но на период поиска неисправностей вполне целесообразно отменить это средство. Еще раз подчеркнем, что это просто пример, но в целом максимально возможное упрощение конфигурации позволяет ускорить работу по устранению неисправностей.
Полезные команды
В настоящем разделе перечислены команды для систем Catalyst IOS и Catalyst OS.
Команды Catalyst IOS
show interface.
show spanning-tree.
show bridge.
show processes cpu.
debug spantree.
logging buffered. "
Команды Catalyst OS
show port.
show mac.
show spantree.
show spantree statistics.
show spantree blockedports.
show spantree summary.
show top.
show inband/show biga.
show system.
show counters.
set spantree root [secondary].
set spantree uplinkfast.
set logging level.
set logging buffered.
Проектирование сети для обеспечения бесперебойной работы протокола STP
Как было описано выше, при некоторых исключительных обстоятельствах формирование распределенного связующего дерева может окончиться неудачей, и выявление причин такого нарушения в работе в действующей сети может оказаться весьма сложным. В настоящем разделе приведены некоторые рекомендации по снижению риска, связанного с нарушением процесса формирования распределенного связующего дерева.
Определение местонахождения корневого моста
Эта задача может показаться легко выполнимой, но в процессе поиска неисправностей часто отсутствует информация о местонахождении корневого моста. Не возлагайте на протокол STP задачу определения корневого моста. В зависимости от проекта сети вы должны сами иметь возможность определить для каждой виртуальной локальной сети, какой коммутатор в наибольшей степени подходит для выполнения функций корневого моста. Как правило, для этого лучше всего выбрать мощный мост примерно в центре сети. Размещение корневого моста, непосредственно подключенного к серверам и маршрутизаторам, в центральной части сети обычно позволяет уменьшить среднее расстояние от клиентов до серверов и маршрутизаторов.
На рис. 23.13 наглядно показано, что при назначении моста В корневым канал между мостами А и С должен быть заблокирован в мосту А или С. В таком случае хосты, которые подключаются к коммутатору В, могут обратиться к серверу и маршрутизатору через два транзитных перехода, а хосты, которые подключаются к мосту С, — через три транзитных перехода. Таким образом, среднее расстояние от хостов до корневого моста составляет 2,5 транзитных перехода."
Если же корневым является мост А, то и маршрутизатор, и сервер достижимы через два транзитных перехода для обоих хостов, подключенных к мостам Вис. Теперь среднее расстояние для них составляет два транзитных перехода.
Этот пример является очевидным, но такие же принципы остаются в силе и для более сложной топологии.
Важное примечание
Дпя каждой виртуальной локальной сети жестко закодируйте в конфигурации критерий выбора корневого моста и резервного корневого моста, уменьшив значение параметра приоритета STP (ипи применив для этой цели макрокоманду set spantree root).
Информация о местонахождении избыточных каналов
Тщательно продумывайте способ организации использования избыточных каналов. И в этом также не рассчитывайте только на средства STP, ориентированные на простое включение. Сами выберите порты, которые должны быть заблокированы, разре-
шив использование параметра стоимости STP. Но, к счастью, обычно этого не требуется, если иерархическая структура сети хорошо спроектирована и удачно выбрано местонахождение корневого моста.
Рис. 23.13. Варианты выбора местонахождения корневого моста
Примечание
Дпя каждой виртуальной локальной сети необходимо определить, какие порты должны быть заблокированы в стабильной сети. Подготовьте схему сети, на которой четко указан каждый физический цикл в сети и каждый порт, который должен быть заблокирован дпя устранения таких циклов.
Если вы будете точно знать, где находятся избыточные каналы, то при случайном возникновении циклов мостового перенаправления сможете быстро выявить цикл и его причину. Зная, где находятся заблокированные порты, вы также сможете быстро определить, в чем заключается причина неисправности (проведя простое сравнение).
Уменьшение количества заблокированных портов до минимума
Наиболее важной задачей протокола STP является блокирование портов. Переход единственного заблокированного порта в состояние перенаправления в результате какой-либо неисправности может полностью нарушить работу значительной части сети. Один из наилучших способов ограничения риска, связанного с использованием протокола STP, состоит в максимальном уменьшении количества заблокированных портов.
Устранение неиспользуемых виртуальных локальных сетей
Обычно не требуется создавать больше двух избыточных каналов между двумя узлами в сети, соединенной мостами. Но конфигурация, подобная приведенной на рис. 23.14, возникает довольно часто.
Рис. 23.14. Типичный проект сети с виртуальными локальными сетями, охватывающими слишком много каналов
Такой проект реализован во многих сетях. Каждый распределительный коммутатор, обеспечивающий работу хостов, подключен двумя каналами к двум коммутаторам, которые составляют ядро сети. Пользователи, подключенные к распределительным коммутаторам, находятся только в определенном подмножестве виртуальных локальных сетей, имеющихся в этой сети (в данном случае все пользователи, подключенные к коммутатору Dist2 находятся в сети VLAN 2, а коммутатор Dist3 подключает только пользователей сети VLAN 3). По умолчанию магистральные каналы переносят трафик всех виртуальных локальных сетей, которые определены в рассматриваемом домене VTP. Теперь только коммутатор Dist2 получает ненужный широковещательный и многоадресатный трафик, предназначенный для сети VLAN 3, но также блокирует один из своих портов, направленных в сторону сети VLAN 3. В результате возникает такая ситуация, что между коммутаторами Core А и Core В имеются три избыточных пути. Это означает, что приходится блокировать больше портов и вероятность возникновения циклов увеличивается.
Важное примечание
Не допускайте прохождения по магистральным каналам ненужного трафика виртуальных локальных сетей.
Для удаления ненужного трафика можно применить в коммутаторах ядра сети средства протокола VTP, ориентированные на простое включение, но лучше все же реализовать такой проект сети, который исключает необходимость в их использовании.
Рассмотрим пример, аналогичный приведенному на рис. 23.14. Но на этот раз для подключения распределительных коммутаторов к ядру сети применяется виртуальная локальная сеть доступа, как показано на рис. 23.15.
Рис. 23.15. Уменьшение количества заблокированных портов и предотвращение ненужной рассылки путем удаления лишних виртуальных локальных сетей
В таком проекте для каждой виртуальной локальной сети необходимо заблокировать только один порт. Следует также отметить, что этот проект позволяет быстро удалить все избыточные каналы, остановив коммутатор Core А или Core В.
Применение коммутации уровня 3
Коммутацию уровня 3 можно образно назвать маршрутизацией на скорости коммутации. Маршрутизатор выполняет следующие две основные функции.
Создает таблицу перенаправления, в основном обмениваясь информацией со смежными устройствами по маршрутизирующим протоколам.
Принимает пакеты и перенаправляет их в нужный интерфейс с учетом адреса получателя.
Теперь вторую функцию могут выполнять высококлассные коммутаторы уровня 3 корпорации Cisco с таким же быстродействием, с каким осуществляются функции коммутации уровня 2. Это позволяет избежать потерь скорости, связанных с введением транзитного перехода маршрутизации и созданием дополнительных сегментов сети. На рис. 23.16 показана схема сети, которая может служить продолжением рассматриваемого примера (см. рис. 23.14 и 23.15).
Как показано на рис. 23.16, теперь в качестве коммутаторов Core А и Core В применяются коммутаторы уровня 3 определенного типа. Следует отметить, что здесь уже не предусмотрено мостовое перенаправление трафика сетей VLAN 2 и VLAN 3 между коммутаторами Core А и Core В, поэтому больше не возникают циклы, которые нужно было бы уничтожать с помощью протокола STP. Данный проект имеет следующие преимущества.
Избыточные каналы по-прежнему используются, но на этот раз они поддерживаются с помощью маршрутизирующих протоколов уровня 3 (причем теперь эти каналы включаются в работу еще быстрее, чем при использовании протокола STP).
VLAN 10
Core A \/Core В
\ VlAN3\VLAN 2//
\VLANS /
VLAN 2 \\/
Puc. 23.16. Предотвращение возможности появления заблокированных портов с помощью коммутации уровня 3
Нет больше ни одного порта, заблокированного протоколом STP, поэтому отсутствует какая-либо возможность появления цикла мостового перенаправления.
Нет никаких потерь скорости, поскольку переброска пакетов из одной виртуальной локальной сети в другую с помощью средств коммутации уровня 3 выполняется так же быстро, как и мостовое перенаправление в пределах одной виртуальной локальной сети.
Единственный недостаток этого решения состоит в том, что для перехода к подобному проекту обычно требуется переработка схемы адресации.
Необходимость в использовании протокола STP
Даже если в сети удалось успешно устранить все заблокированные порты, а какие- либо избыточные физические каналы полностью отсутствуют, не следует отказываться от применения протокола STP. Этот протокол, как правило, не требует больших затрат процессорного времени (и к тому же в большинстве коммутаторов Cisco процессор не участвует в коммутации пакетов), а небольшое количество сообщений BPDU, передаваемых по каждому каналу, не столь существенно уменьшает доступную пропускную способность. С другой стороны, соединенная мостами сеть, в которой не используется протокол STP, может полностью выйти из строя за доли секунды, если, например, оператор допустит ошибку при подключении кабелей на коммутационной панели и случайно создаст цикл. Как правило, риск, связанный с отменой протокола STP в сети, соединенной мостами, является неоправданным.
Условия применения административной виртуальной локальной сети
Рекомендуется сосредоточить весь управляющий трафик в единственной административной виртуальной локальной сети, а также избегать возникновения такой ситуации, когда единственная виртуальная локальная сеть охватывает всю сеть. Эти две рекомендации являются взаимосвязанными.
В коммутаторе Cisco обычно имеется один IP-адрес, привязанный к некоторой виртуальной локальной сети (которую часто называют административной виртуальной локальной сетью'). В этой виртуальной локальной сети коммутатор ведет себя как обычный хост IP. В частности, каждый отдельно взятый широковещательный или многоадресатный пакет перенаправляется его процессору. Наличие интенсивного трафика широковещательных и многоадресатных пакетов в административной виртуальной локальной сети может потребовать больших затрат ресурсов процессора коммутатора и отрицательно повлиять на его способность обрабатывать исключительно важные сообщения BPDU. Поэтому рекомендуется всегда исключать возможность прохождения пользовательского трафика по административной виртуальной локальной сети.
До недавнего времени в реализации Cisco отсутствовал способ удаления сети VLAN 1 из магистрального канала. Эта виртуальная локальная сеть обычно применяется в качестве административной сети, которая позволяет получить доступ ко всем коммутаторам в одной и той же подсети IP. Хотя такая возможность очень удобна, она может стать опасной, поскольку возникновение цикла мостового перенаправления в сети VLAN 1 может повлиять на все магистральные каналы, а в некоторых случаях нарушить функционирование всей сети. Безусловно, такая же проблема может возникнуть и в любой другой виртуальной локальной сети. По возможности вместо этого следует применять сегментирование доменов мостового перенаправления с помощью быстродействующих коммутаторов уровня 3.
Начиная с версии 5.4 программное обеспечение Catalyst OS позволяет удалять трафик сети VLAN 1 из магистральных каналов (в действительности, сеть VLAN 1 продолжает существовать, но блокирует трафик, и поэтому любая вероятность появления циклов исключается).
Недопустимость необоснованной настройки параметров STP
Соблюдайте особую осторожность, намереваясь ввести в конфигурацию другие установки таймеров STP вместо значений, применяемых по умолчанию. (Еще один вариант подобных действий состоит в использовании макрокоманд Catalyst OS.) Например, очень опасной может стать попытка ускорить процесс формирования распределенного связующего дерева, поскольку в результате этого может измениться значение максимально допустимого диаметра сети и нарушиться стабильность работы протокола STP. Единственными параметрами STP, корректировка которых вполне оправдана, являются приоритеты мостов (с помощью чего можно указать, какой мост должен быть корневым), а также стоимость или приоритет порта (что позволяет управлять избыточностью и уравновешиванием нагрузки).
Корпорация Cisco включила в состав программного обеспечения коммутатора Catalyst следующие макрокоманды, позволяющие упростить точную настройку наиболее важных параметров STP.
Макрокоманда set spantree root [secondary] позволяет уменьшить приоритет моста до такой степени, чтобы он стал корневым (или альтернативным корневым) мостом. Имеется также возможность выполнить настройку таймеров STP, указав диаметр сети. Но даже если все будет сделано правильно, настройка таймеров не позволяет существенно сократить продолжительность формирования распределенного связующего дерева, особенно по сравнению с такими средствами повышения быстродействия, как Uplink Fast (Ускорение работы каналов сетевой инфраструктуры) и Backbone Fast (Ускорение работы опорной сети), а также заменить хорошо спроектированную коммутацию уровня 3, к тому же неправильная настройка способствует повышению вероятности возникновения нестабильности сети. Кроме того, такие параметры настройки приходится корректировать после ввода в сеть каждого нового устройства. Поэтому лучше всего сохранить значения, предусмотренные по умолчанию, поскольку они выбраны на основе глубокого анализа и ими привыкли пользоваться сетевые инженеры.
Макрокоманда set spantree uplinkfast позволяет увеличить приоритет коммутатора до такой степени, чтобы он не мог стать корневым. Эта макрокоманда обычно применяется для установки приоритета распределительного коммутатора, который подключен не менее чем к двум коммутаторам ядра сети. Дополнительная информация о том, к каким последствиям приводит применение этой команды, приведена в документации по средству Uplink Fast.
Необходимость в использовании средства UDLD
Если канал с заблокированным портом переходит в режим однонаправленной передачи, это означает, что в сети с вероятностью 50% может появиться цикл мостового перенаправления. Рассматриваемый сценарий возникновения отказа STP является наиболее опасным, поскольку алгоритм STA не способен справиться с подобной ситуацией. В новейших версиях программного обеспечения Catalyst реализовано средство UDLD, которое позволяет обнаружить это опасное нарушение в работе, но его действие распространяется только на каналы типа “точка- точка” между устройствами Cisco.
Дополнительная информация
Для ознакомления с дополнительной информацией, включая подробные инструкции по настройке конфигурации и полные примеры команд, применяемых в устройствах MLS-RP и MLS-SE, настоятельно рекомендуем обратиться к следующим источникам информации (зарегистрируйтесь в своей учетной записи, чтобы иметь доступ к максимальному объему материала).
Web-узел ТАС в составе Web-узла ССО (ww.cisco.com/tac).
Страница MLS Technology Pages на Web-узле ТАС ССО (ww.cisco.com/cgi- bin/Support/PSP/psp_view.pl?p=Internetworking:Multi-layer_Switching).
Информация по сетевым топологиям, поддерживаемым и неподдерживаемым технологией MLS (ww.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5_2/ lay er 3/ml s. htmi х toeid 11019 5 8).
Руководство Layer 3 Switching Software Configuration Guide (www.cisco.com/univercd/ cc/td/doc/product/lan/cat5000/rel_5_2/layer3/index.htm).
Примечания к выпуску Catalyst 5xxx (www.cisco.com/univercd/cc/td/doc/product/ lan/cat5000/c5krn/index.htm).
Примечания к выпуску Catalyst бххх (www.cisco.com/univercd/cc/td/doc/product/ lan/cat6000/relnotes/index.htm).
Часть
VI
нарушений в работе приложения CiscoWorks 2000 нарушений в работе средств обеспечениясети”нарушений в работе приложения CiscoWorks 2000 нарушений в работе средств обеспечениясети”
нарушений в работе приложения CiscoWorks 2000 нарушений в работе средств обеспечения
сети”
нарушений в работе приложения CiscoWorks 2000 нарушений в работе средств обеспечения
сети”
странение других шенийв работе именной сети
Глава
24
Устранение нарушений в работе приложения CiscoWorks 2000
Назначение главы
а Основное назначение настоящей главы состоит в предоставлении информации по устранению нарушенийв работе, которые часто возникают при установке и эксплуатации семейства продуктов CiscoWorks 2000 (в частности, приложений RME 2.2 и
' CWSI 2.4). Ниже перечислены основные разделы этой главы.
- • Общие сведения о семействе программных продуктов управления сетью
CiscoWorks 2000.,
Устранение, нарушений, возникающих в процессе инсталляции и настройки - программ CiscoWorks 2000.
Методы оценки ситуации и устранения нарушений в работе приложения RME.
• Информация по устранению нарушений в работе набора приложений CWS1 Campus.,
? Информация по устранению нарущений в работе приложений, входящих в состав с: набора CWSI Campus (VlanDirector, AtmDirector, TrafficDirector и CiscoView).
Основные сведения
CiscoWorks 2000 — семейство программных продуктов управления сетью, которое сочетает в себе наилучшие функциональные средства управления маршрутизаторами и коммутаторами в производственной сети и удобство развертывания на основе технологий Web. В семействе продуктов CiscoWorks 2000 осуществлен новый подход к созданию программ управления сетью, предназначенных для крупных, быстро изменяющих производственных сетей. В основе семейства продуктов CiscoWorks 2000 лежат такие приложения, как Resource Manager Essentials и CWSI Campus. В этом новом поколении инструментальных средств управления в полной мере используются возможности Internet по привлечению к
процессу управления всей информации, доступной по сети, и по предоставлению пользователям доступа к функциональным средствам управления через стандартный Web- броузер. Продукты CiscoWorks 2000 объединяют в себе средства управления маршрутизаторами и коммутаторами, обеспечивают интеграцию инструментальных средств управления на основе приложения Cisco Management Connection, которое обеспечивает доступ с помощью броузера, и предусматривают совместное использование общих служб различными функциональными модулями.
Свой первый программный продукт (Resource Manager), основанный на использовании средств Internet, корпорация Cisco представила на рынке в 1997 году, а затем объединила несколько отдельных приложений в единый набор программ, получивший название CWSI (CiscoWorks for Switched Internetworks — CiscoWorks для коммутируемых объединенных сетей). Семейство продуктов CiscoWorks 2000 стало очередным этапом развития этих программ. Корпорацией Cisco в него были внесены следующие изменения: добавлены функциональные средства управления, выходящие за рамки отдельных коммутаторов и маршрутизаторов, значительно увеличено количество средств, доступных через Web, а функционирование всех программных продуктов организовано на основе единого набора фоновых служб, обеспечивающего доступ к общему интерфейсу управления.
Система CWSI Campus, которая входит в набор программ CiscoWorks 2000, обеспечивает выполнение сложных функций управления трафиком, управления сетями ATM, управления виртуальными локальными сетями и сопровождения конфигураций устройств. Эти функции приложения CWSI Campus дополняют средства автоматизированного обновления программного обеспечения, управления учетной информацией и управления конфигурацией приложения Resource Manager Essentials. В этих двух приложениях применяются некоторые общие серверные процессы, что позволяет использовать приложение Resource Manager Essentials в режиме автономной эксплуатаций, но для обеспечения полноценного функционирования обоих приложений необходимо установить также приложение CWSI Campus, в котором реализован необходимый набор базовых функций.
Программный продукт управления сетью CiscoWorks Classic был заменен приложением CiscoWorks 2000 Resource Manager Essentials. Для ознакомления с подробными сведениями о том, как перейти от использования приложения CiscoWorks Classic Essentials к приложению Essentials, обратитесь на узел ССО по адресу ww.cisco.сот/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000e/rme_ltu/ug_appb.htm. Семейство продуктов CiscoWorks 2000 (сокращенно CW 2000) выпускается в четырех различных версиях, которые соответствуют четырем разновидностям операционных систем. К ним относятся CW 2000 для NT, CW 2000 для Solaris, CW 2000 для HPUX и CW 2000 для AIX. Вся информация по поиску неисправностей, представленная в этой главе, относится ко всем разновидностям семейства продуктов CW 2000, если не дано конкретное указание, о какой разновидности идет речь.
Устранение нарушений, возникающих в процессе инсталляции и настройки программ CiscoWorks 2000
В настоящем разделе рассматриваются следующие темы.
Устранение нарушений в процессе инсталляции обязательного программного обеспечения сервера.
Инструментальные средства устранения нарушений в работе Essentials.
Регистрация в системе после обновления программного обеспечения.
Проверка файлов и каталогов после инсталляции.
Анализ сообщений об ошибках, возникающих во время инсталляции.
Доступ к серверу Essentials.
Настройка параметров броузера.
Добавление и импорт информации об устройствах.
Сбор информации о сервере.
Приложения Essentials Daemon Manager и CWSI Campus.
Устранение нарушений при регистрации на сервере AniServer.
Проверка соединения с базой данных.
Устранение нарушений в процессе инсталляции обязательного программного обеспечения сервера
Перед инсталляцией версии CiscoWorks 2000 для Windows NT на компьютере должны быть установлены компоненты пакета Windows NT 4.0 Option Pack. Если при первоначальной установке этой операционной системы не были инсталлированы перечисленные ниже обязательные компоненты пакета Windows NT 4.0 Option Pack, их можно установить позже.
Internet Service Manager (диспетчер служб Internet).
Microsoft Management Console (консоль управления Microsoft).
Windows Scripting Host (сервер сценариев Windows).
Чтобы установить один или несколько из этих компонентов после первоначальной инсталляции системы, выполните следующие действия.•
Шаг 1. Выберите пункт меню Start^Program^Windows NT 4.0 Option Pack^Windows NT 4.0 Option Pack setup. Появится диалоговое окно Windows NT 4.0 Option Pack Setup.
Шаг 2. Щелкните на кнопке Next. Откроется диалоговое окно, в котором можно выбрать опции программы Add/Remove или Remove All Installation.
Шаг 3. Выберите пункт меню Add/Remove. Появится диалоговое окно Select Components.
Шаг 4. Выберите недостающие обязательные компоненты.
Шаг 5. Щелкните на кнопке Next. Появится диалоговое окно Completing Installation.
Шаг 6. Щелкните на кнопке Finish, чтобы завершить инсталляцию.
Инструментальные средства устранения нарушений в работе Essentials
Приложение Essentials предоставляет несколько опций поиска неисправностей, доступ к которым можно получить с помощью иерархического меню. Чтобы обратиться к этим инструментальным средствам, выберите пункты меню Admin ^Troubleshooting.
Сбор информации о сервере. Для получения информации о состоянии сервера, которая необходима при поиске неисправностей, применяется опция Collect Server Info. Чтобы собрать информацию о сервере, выполните следующие действия.
Шаг 1. Выберите пункт меню AdminoTroubleshootingoCollect Server Info. Появится диалоговое окно Collect Server Info.
Шаг 2. Выберите отчет из хронологического списка Reports.
Шаг 3. Щелкните на кнопке Display. На экране появится отчет, содержащий такую информацию, как данные о программных продуктах, операционной системе, а также статистические данные об использовании диска.
Шаг 4. Для создания нового отчета щелкните на кнопке Create. В хронологическом списке Reports появится новый отчет.
Примечание. Для сбора этой информации может потребоваться до 5 минут.
Шаг 5. Для удаления отчетов выберите их из хронологического списка Reports, а затем щелкните на кнопке Delete.
Просмотр информации об аварийном завершении процессов. Для проверки информации о возможном аварийном завершении серверных процессов примените опцию Process Failures. Таблица Process Failures предоставляет информацию только о следующих двух возможных вариантах аварийного завершения работы.
Failed to run. Завершена работа процесса или отправлено сообщение об аварийном завершении.
Administrator has shut down the server. Процесс закрыт другой программой или администратором.
Для просмотра информации о причинах аварийного завершения процессов выполните следующие действия.
Шаг 1. Выберите пункт меню Admin^Troubleshooting^Process Failures. Столбцы таблицы Process Failures перечислены в табл. 24.1.
Шаг 2. Для просмотра дополнительных сведений щелкните на имени любого процесса. Появится таблица Process Details. Щелкните на кнопке Back, чтобы вернуться к таблице Process Failures.
Шаг 3. Щелкните на элементе с информацией о состоянии любого процесса для просмотра системного журнала. Откроется системный журнал. Щелкните на кнопке Back, чтобы вернуться к таблице Process Failures.
Шаг 4. Для обновления полей щелкните на кнопке Update.
Сбор информации самопроверки. Опция SelfTest позволяет повторно вызвать на выполнение программы самопроверки и получить отчет с результатами. Для сбора информации самопроверки выполните следующие действия.
Шаг 1. Выберите пункт меню Admin^TroubleshootingoSelfTest. Появится диалоговое окно Server Selftest Info.
Шаг 2. Щелкните на кнопке Run Tests, чтобы повторно запустить программы самопроверки и сформировать отчет. Выполняются проверки, и в хронологическом списке Reports появляется отчет.
Примечание. Для выполнения проверок может потребоваться до 5 минут.
Шаг 3. Выберите отчет из хронологического списка Reports.
Шаг 4. Щелкните на кнопке Display. На экране отображается отчет с информацией о том, была ли проверка выполнена успешно или завершилась неудачей.
Шаг 5. После этого можно удалить отчеты, выбрав их из хронологического списка Reports, а затем щелкнув на кнопке Delete.
• Таблица 24.1. Описание столбцов таблицы Process Failures
Столбец
Описание
Process Name
State
Pid
Имя процесса
Состояние процесса: "Failed to run" или "Administrator has shut down this server" Идентификатор процесса. Уникальный ключ, который применяется для обозначения всех программ, функционирующих под управлением операционной системы
RC
Код возврата. Код "0" указывает на то, что программа работает нормально. Любое другое значение обычно указывает на ошибку. Обратитесь к файлу регистрации ошибок
Signo
Номер сигнала. Код "0" указывает на то, что программа работает нормально. Любое другое значение представляет собой номер последнего сигнала, переданного программе перед завершением ее работы
Start Time Stop Time
Core
Время и дата запуска процесса
Время и дата останова процесса
Значение "Not applicable" показывает, что программа работает нормально. Значение "CORE FILE CREATED" свидетельствует о том, что программа работает со сбоями и что операционная система создала файл, называемый дампом ядра. Дамп ядра содержит важные данные об условиях аварийного завершения процесса
Information
Причина для отказа. Значение "Not applicable" показывает, что программа работает со сбоями
Регистрация в системе после обновления программного обеспечения
После модернизации программного обеспечения с переходом от версии Cisco Resource Manager 1.1 к версии Essentials 2.1, или от версии Essentials 2.0 к версии Essentials 2.1, или от версии Essentials 2.1 к версии Essentials 2.2 может потребоваться очистить кэш броузера, чтобы зарегистрироваться в программе Essentials.
Если во время попытки впервые зарегистрироваться в этой программе после обновления на рабочем столе Essentials не появляется диалоговое окно Login Manager, очистите кэш броузера как описано ниже, а затем снова введите URL сервера Essentials в броузере.
В программе Microsoft Internet Explorer выполните следующие действия.
Шаг 1. Выберите пункт меню View Internet Options. Появится диалоговое окно Internet Options.
Шаг 2. Выберите вкладку General.
Шаг 3. Щелкните на кнопке Delete Files.
В программе Netscape Navigator выполните следующие действия.
Шаг 1. Выберите пункт меню Edit Preferences. Появится диалоговое окно Preferences.
Шаг 2. Выберите пункт меню Advanced Cache.
Шаг 3. Щелкните на кнопке Clear Memory Cache, а затем щелкните на кнопке ОК в диалоговом окне Memory Cache.
Шаг 4. Щелкните на кнопке Clear Disk Cache, а затем щелкните на кнопке ОК в диалоговом окне Disk Cache.
Проверка файлов и каталогов после инсталляции
Если возникли проблемы при установке приложения Essentials, убедитесь в том, что на компьютере в соответствующих каталогах установлены следующие подкаталоги.
При инсталляции набора программ CW 2000 в системе NT должны быть установлены следующие подкаталоги в каталоге C:\Program Files\CSCOpx (или в каталоге, который указан для инсталляции):
bin;
cgi-bin (программы, выполняемые Web-сервером);
collect;
conf (файлы конфигурации);
etc (системные файлы Essentials);
example (примеры файлов импорта);
htdocs (файлы Web-сервера);
lib;
man;
objects (подсистемы Essentials);
selftest;
ww;
upgrade (обновления MIB);
setup (информация установки);’
shared (системные файлы);
temp (временные файлы);
tftpboot (файлы, экспортируемые программой tftpboot);
dbupgrade;
files;
log (журналы);
proxy (временные файлы).
Инструментальное средство инсталляции Essentials устанавливает следующие подкаталоги в каталоге C:\Program Files\CSCOpx\objects (или каталоге, предназначенном для инсталляции):
availability (средства обеспечения доступа);
cmf (общая инфраструктура управления Common Management Framework);
config (управление конфигурацией);
data (файлы конфигурации средств анализа системного журнала);
db (база данных Essentials);
inventory (управление учетной информацией);
mngconnection (средства управления доступом Management Connection);
рег15 (интерпретатор Perl и библиотеки приложения Essentials);
proxy (информация прокси-сервера);
share (общедоступные программные файлы);
swim (средства управления программным обеспечением Software Management);
sysloga (средства анализа системного журнала);
web (программы и утилиты Web-сервера).
При инсталляции приложения CW 2000 в системе Solaris, HPUX и AIX убедитесь в том, что в каталогах /opt/CSCOpx, /opt/CSCOpx и /usr/CSCOpx были установлены следующие подкаталоги:
bin;
cgi-bin (программы, выполняемые Web-сервером);
collect;
conf (файлы конфигурации);
etc (системные файлы Essentials);
example (примеры файлов импорта);
htdocs (файлы Web-сервера);
lib;
man;
objects (подсистемы Essentials);
selftest;
WWW.
Кроме того, инструментальное средство инсталляции Essentials устанавливает в системах Solaris, HPUX и AIX следующие подкаталоги в каталогах /opt/CSCOpx/objects, /opt/CSCOpx/objects и /usr/CSCOpx/objects:
availability (средства обеспечения доступа);
cmf (общая инфраструктура управления Common Management Framework);
config (управление конфигурацией);
data (файлы конфигурации средств анализа системного журнала);
db (база данных Essentials);
dmgt (управление демонами);
inventory (управление учетной информацией);
mngconnect (средства управления доступом Management Connection);
perl (интерпретатор Perl и библиотеки приложения Essentials);
share (общедоступные программные файлы);
swim (средства управления программным обеспечением Software Management);
tcltk (администрирование Web);
util (утилиты и сценарии);
web (программы и утилиты Web-сервера).
Примечание
В системе AIX отсутствуют каталоги config (средства управления конфигурацией) или util (утилиты и сценарии).
Кроме того, в системе Solaris необходимо дополнительно разместить в каталоге /etc следующие файлы:
rc2.d/K90dmgtd;
init.d/dmgtd;
rc3.d/S10dmgtd;
rc.config.d/CiscoRMCtrl.
В системе HPUX необходимо дополнительно разместить следующие файлы:
/sbin/rc2.d/K90dmgtd;
/sbin/init.d/dmgtd;
/sbin/rc3.d/S10dmgtd;
/etc/rc.config.d/CiscoRMCtrl.
В системе AIX необходимо дополнительно разместить в каталоге /etc файл rc.dmgtd.
Анализ сообщений об ошибках, возникающих во время инсталляции
После проведения инсталляции необходимо убедиться в том, что установка требуемых файлов выполнена успешно, а затем проверить на отсутствие ошибок файл c:\rme_in001.log (или файл журнала с самым старшим номером, например, rme_in003.log) в системе NT или файл /var/tmp/ciscoinstall.log в системах Solaris, HPUX и AIX. В файл журнала записываются сообщения следующих типов.
Информационные сообщения, которые позволяют получить важные дополнительные сведения о ходе процесса установки.
Предупреждающие сообщения, которые указывают, что при выполнении какого-то конкретного процесса возникали нестандартные ситуации, но процесс был выполнен до конца.
Сообщения об ошибках, которые указывают, что выполнение какого-то конкретного процесса был прекращено преждевременно.
В табл. 24.2 приведены сообщения об ошибках, которые могут произойти в процессе инсталляции в системе NT, и описаны причины этих ошибок.
—,„<^_-^^_—^_^_^^
Таблица 24.2. Сообщения об ошибках в процессе инсталляции в системеЖ’«^
Сообщение об ошибке
Причина ошибки
Действия пользователя
"Administrator privileges are
Пользователь не зарегистри-
Войдите в систему Windows
needed to install or
ровался в системе Windows
NT с привилегиями админи-
uninstall this package.
NT с привилегиями админи-
стратора и повторите попыт-
Please log in as administrator and try again." (“Для инсталляции или деинсталляции этого пакета требуются привилегии администратора. Зарегистрируйтесь в качестве администратора и повторите попытку”)
стратора
ку провести инсталляцию
"Decompression failed on
Если дистрибутив приложе-
Повторите загрузку дистри-
<file>. The error was for
ния Essentials был загружен
бутива. Если для инсталля-
<error code per
по сети, то, возможно, про-
ции используется CD-ROM
CompressGet>. " (“Распаковка
изошла ошибка передачи. В
программного продукта,
файла <file> окончилась не-
ином случае, поврежден ин-
проверьте инсталляционный
удачей. Возникла ошибка с кодом <error code per CompressGet>”)
сталляционный носитель
носитель, чтобы убедиться в том, что он не поврежден
"General file transmission
Если дистрибутив приложе-
Повторите загрузку дистри-
error. Please check your target location and try again. Error number: <error code>." (“Обшая ошибка передачи файла. Проверьте устройство назначения и повторите попытку. Ошибка с кодом: <error code>”)
ния Essentials был загружен по сети, то, возможно, произошла ошибка передачи
бутива
"Unable to write <infoFile>“
Операция записи файла
Вызовите на выполнение
или "Unable to create <infoFile>". (“Невозможно записать <infoFile>” или “Невозможно создать <infoFile>”)
окончилась неудачей
утилиту проверки файловой системы, а затем повторите инсталляцию
"Cannot stop service
В процессе инсталляции
Выберите пункты меню Con-
<servicename>."
(или деинсталляции) прило-
trol Panel^Services и попы-
(“Невозможно остановить
жения Essentials была пред-
тайтесь остановить службу
службу <servicename>”)
принята попытка остановить службу <servicename>, но останов не произошел
<servicename> вручную. После этого продолжите инсталляцию (деинсталляцию)
Сообщение об ошибке
Причина ошибки
"UseDLL failed for <dll>." (“Обработка библиотеки <dll> утилитой UseDLL окончилась неудачей”)
"<function> failed: DLL function not found." (“Попытка выполнить функцию <function> окончилась неудачей: функция DLL не найдена”)
"OpenFile failed: <pathname>." ("Операция OpenFile окончилась неудачей: файл <pathname>”) "ProtectFile failed: <file>: error. WWW admin security may be incomplete." (“Операция ProtectFile окончилась неудачей: <file>: ошибка. Установленная администратором конфигурация защиты WWW может оказаться неполной”) "Installing in root directory is not allowed. Please choose nonroot directory." (“Инсталляция в корневом каталоге ие разрешена. Выберите некорневой каталог”) “Resource Manager Essentials can be installed only on NT Workstation or NT Server. It is not supported on PDC/BDC." (“Программа Resource Manager Essentials может быть установлена только на рабочей станции NT или на сервере NT. Вариант инсталляции на первичном или резервном контроллере домена не поддерживается”)
Предполагается, что указанная библиотека <dll> должна быть доступна в любое время и для любого процесса, но ее загрузка в системе NT завершилась неудачей
Предполагается, что указанная библиотека <dll> должна быть доступна в любое время и для любого процесса, но ее загрузка в системе NT завершилась неудачей
Операция открытия файла окончилась неудачей
Операция корректировки прав доступа к файлу окончилась неудачей, поскольку пользователю не было разрешено их изменять
Была предпринята попытка установить приложение Essentials в корневом каталоге диска (например, с:\ или d:\), но такой вариант инсталляции не поддерживается Инсталляционная программа определила одну из следующих ситуаций:
На компьютере не установлена система Windows NT.
Конфигурация системы настроена на ее использование в качестве первичного контроллера домена (PDC — Primary Domain Controller) или резервного контроллера домена (BDC — Backup Domain Controller)
Проверьте права доступа в системе Windows NT System 32. Если в качестве библиотеки <dll> указана secure.dll, проверьте инсталляционный носитель данного программного продукта на отсутствие ошибок или повторно установите систему Windows NT Проверьте права доступа в системе Windows NT System 32. Если в качестве библиотеки <dll> указана secure.dll, проверьте инсталляционный носитель данного программного продукта на отсутствие ошибок или повторно установите систему Windows NT Вызовите на выполнение утилиту проверки файловой системы. После этого повторите инсталляцию
Зарегистрируйтесь в системе в качестве администратора. Примечание. Если для инсталляции используется файловая система FAT, приложение Essentials не может обеспечить зашиту файлов
Для инсталляции приложения Essentials выберите некорневой каталог
Установите приложение Essentials в системе Windows NT 4.0 Workstation или Windows NT 4.0 Server, конфигурация которой не настроена на использование в качестве первичного или резервного контроллера домена
"You have less than 1 M free space on <drive name>. Please free up some space and try again." (“Объем свободного пространства на диске <drive name> составляет меньше 1 Мбайт. Выделите дополнительное пространство и повторите попытку”) "This program requires to run on Window NT." (“Эта программа предназначена для работы в системе Window NT)
Объем свободного пространства на диске является недостаточным для размещения временных инсталляционных файлов
Выделите дополнительный объем пространства на диске, а затем повторно запустите инсталляционную программу
Была предпринята попытка выполнить инсталляцию на компьютере, на котором не установлена система Windows NT 4.0
"Unable to determine the type of operating system. Resource Manager Essentials can be installed only on NT Workstation or NT Server." (“Невозможно определить тип операционной системы. Программа Resource Manager Essentials может быть установлена только на рабочей станции NT или на сервере NT’) "Physical memory is <...>M Paging File Size is:
<.,.>M(initial), <...>M(max). It is recommended that initial paging file size is bigger than physical memory and that max paging file size is at least twice bigger than physical memory." (“Объем оперативной памяти: <...> Мбайт. Размер файла подкачки: <...> Мбайт (начальный), <...> Мбайт (максимальный). Рекомендуется установить начальный размер файла подкачки, превышающий объем оперативной памяти, а максимальный размер файла подкачки — не менее чем вдвое превышающий объем оперативной памяти”)
Инсталляционная программа не могла определить, какая операционная система эксплуатируется на компьютере
Установите приложение Essentials в системе Windows NT 4.0 Workstation или Windows NT 4.0 Server, конфигурация которой не настроена на ее использование в качестве первичного или резервного контроллера домена Установите приложение Essentials в системе Windows NT 4.0 Workstation или Windows NT 4.0 Server, конфигурация которой не настроена на использование в качестве первичного или резервного контроллера домена
Файл подкачки имеет размер меньше рекомендуемого
Закончите инсталляцию, а затем увеличьте размер файла подкачки
Сообщение об ошибке
Причина ошибки
Действия пользователя
"The Resource Manager
В системе установлена вер-
Установите версию IIS или
Essentials installation found
сия 2 или 3 сервера PWS или
PWS 4.0 и другое необходи-
the IIS/PWS v2/v3. Internet Information Server 4.0 is required."
(“Инсталляционная программа Resource Manager Essentials обнаружила версию IIS/PWS v2/v3. Требуется версия Internet Information Server 4.0”)
IIS, но требуется версия 4.0
мое программное обеспечение Microsoft. После этого снова вызовите на выполнение инсталляционную программу. Для ознакомления с дополнительной информацией обратитесь к руководству по инсталляции приложения Essentials
"The Resource Manager
В системе не установлен сер-
Установите сервер сценариев
Essentials installation could not find Windows Scripting Host. Windows Scripting Host is required for IIS 4.0." (“Инсталляционная программа Resource Manager Essentials не обнаружила сервер сценариев Windows. Для сервера IIS 4.0 требуется сервер сценариев Windows Scripting Host”)
вер сценариев Windows
Windows Scripting Host (и все другие необходимые компоненты пакета Windows NT 4.0 Option Pack). После этого снова вызовите на выполнение инсталляционную программу
"Downgrade to FCS version is
Инсталляционная программа
Для повторной установки
not supported. If you wish to
обнаружила, что установлены
версии FCS программного
revert to FCS, back up your
некоторые исправления или
продукта выполните еле-
data, then uninstall the
обновления Essentials. В этом
дующие действия.
current version and do a new
случае отсутствует возмож-
Шаг 1. Подготовьте резерв-
install of this version.
ность перейти на версию
ную копию своих
Exiting." ("Переход на преды-
FCS этого программного
файлов данных
дущую версию FCS не под-
продукта с использованием
Essentials.
держивается. Для того чтобы
данной инсталляционной
Шаг 2. Деинсталлируйте
снова установить версию FCS, подготовьте резервную копию своих данных, затем деинсталлируйте текущую версию и повторно инсталлируйте предыдущую. Работа программы окончена”)
npui раммы
приложение Essentials.
Шаг 3. Снова установите версию FCS приложения Essentials.
Шаг 4. Восстановите данные из резервной копии
Отведите дополнительное свободное пространство на том же диске или установите программный продукт на другом дискеОтведите дополнительное свободное пространство на том же диске или установите программный продукт на другом дискеЕсли есть необходимость в использовании приложения CWSI Campus, то его необходимо установить после установки приложения EssentialsЕсли есть необходимость в использовании приложения CWSI Campus, то его необходимо установить после установки приложения EssentialsЕсли есть необходимость в использовании приложения CWSI Campus, то его необходимо установить после установки приложения EssentialsЕсли есть необходимость в использовании приложения CWSI Campus, то его необходимо установить после установки приложения EssentialsЕсли установлена версия CWSI 2.1, то после установки приложения Essentials необходимо перейти на версию CWSI Campus 2.3, чтобы и дальше использовать программный продукт CWSI CampusЕсли установлена версия CWSI 2.1, то после установки приложения Essentials необходимо перейти на версию CWSI Campus 2.3, чтобы и дальше использовать программный продукт CWSI Campus
Отведите дополнительное свободное пространство на том же диске или установите программный продукт на другом диске
Отведите дополнительное свободное пространство на том же диске или установите программный продукт на другом диске
Если есть необходимость в использовании приложения CWSI Campus, то его необходимо установить после установки приложения Essentials
Если есть необходимость в использовании приложения CWSI Campus, то его необходимо установить после установки приложения Essentials
Если есть необходимость в использовании приложения CWSI Campus, то его необходимо установить после установки приложения Essentials
Если есть необходимость в использовании приложения CWSI Campus, то его необходимо установить после установки приложения Essentials
Если установлена версия CWSI 2.1, то после установки приложения Essentials необходимо перейти на версию CWSI Campus 2.3, чтобы и дальше использовать программный продукт CWSI Campus
Если установлена версия CWSI 2.1, то после установки приложения Essentials необходимо перейти на версию CWSI Campus 2.3, чтобы и дальше использовать программный продукт CWSI Campus
"There is not enough space available on the disk <drive>: This drive has <...> bytes in a cluster. Total required <...> clusters (<...> bytes), only <...> clusters (<...> bytes) available. Please free up some space and rerun installation." (“На диске <drive> отсутствует достаточный объем доступного пространства: кластеры этого диска имеют размер <...> байтов. Всего требуется <...> кластеров (<...> байтов), доступно только <...> кластеров (<...> байтов). Выделите дополнительное пространство и повторно запустите инсталляционную программу”)
"INFO: You must now install Campus CWSI 2.3 to continue using CWSI." (“Информационное сообщение: теперь необходимо установить версию Campus CWSI 2.3, чтобы и дальше использовать CWSI”) "You must now install CWSI 2.3 if you want to use the Campus product. CWSI 2.1 will not work correctly with Essentials 2.1." (“Теперь необходимо установить версию CWSI 2.3, если планируется дальнейшее использование программного продукта Campus. Версия CWSI 2.1 не может правильно работать с приложением Essentials 2.1 ”) "You have CWSI 2.1 installed and will need to upgrade to CWSI 2.3 when Resource Manager Essentials install completes to continue to use CWSI." (“Установлена версия CWSI 2.1, но после завершения установки приложения Resource Manager Essentials необходимо перейти на версию CWSI 2.3, чтобы по-прежнему использовать приложение CWSI”)
Объем свободного пространства на диске <drive> является недостаточным для инсталляции данного программного продукта
Это сообшение не указывает на наличие ошибки; оно является информационным и отображается лишь в том случае, если установлена предыдущая версия CWSI
Это сообшение не указывает на наличие ошибки; оно является информационным и отображается лишь в том случае, если установлена предыдущая версия CWSI
Это сообшение не указывает на наличие ошибки; оно является информационным и отображается лишь в том случае, если установлена предыдущая версия CWSI
"Cannot determine the local Administrators group." (“Невозможно определить местонахождение локальной группы Administrators”)
"Cannot determine the local Everyone group."
(“Невозможно определить местонахождение локальной группы Everyone”)
"Failed to set file
permissions." (“Операция корректировки прав доступа к файлу завершилась неудачей")
"Unable to uninstall Resource Manager Essentials because the following components are shared: CWSI 2.x. You need to uninstall these dependent applications then run the Resource Manager Essentials uninstallation again." (“Деинсталляцию приложения Resource Manager Essentials выполнить невозможно, поскольку следующие компоненты находятся в совместном использовании: CWSI 2.x. Необходимо деинсталлировать эти зависимые приложения, после чего снова приступить к деинсталляции приложения Resource Manager Essentials”)
Инсталляционная программа не может найти одну из встроенных групп пользователей Windows NT. В связи с этим отсутствует возможность установить средства зашиты Essentials
Инсталляционная программа не может найти одну из встроенных групп пользователей Windows NT. В связи с этим отсутствует возможность установить средства зашиты Essentials
В процессе работы инсталляционной программы не была выполнена операция корректировки прав доступа к файлу. Ниже перечислены наиболее вероятные причины такой ситуации.
Учетная запись, с помощью которой была выполнена регистрация в системе, имеет недостаточные привилегии.
Инсталляция программного продукта происходит на диске с файловой системой FAT
До тех пор, пока установлены компоненты CWSI или CWSI Campus, деинсталляцию приложения Essentials выполнить невозможно
Проверьте операционную систему Windows NT. В случае необходимости повторно установите Windows NT, а затем снова вызовите на выполнение программу инсталляции Essentials
Проверьте операционную систему Windows NT. В случае необходимости повторно установите Windows NT, а затем снова вызовите на выполнение программу инсталляции Essentials
Устраните причину, по которой не выполняется операция корректировки прав доступа, а затем повторно запустите инсталляционную программу
Деинсталлируйте компоненты CWSI или CWSI Campus на данном компьютере. После этого появится возможность деинсталлировать приложение Essentials
"FSSupportsACLs failed: <0S error message:»." (“Операция FSSupportsACLs завершилась неудачей с сообшением об ошибке: <0S error message>")
"<...> is already runningl Wait for it to finish and press the OK button below." (“Задача <...> уже выполняется! Дождитесь ее окончания и щелкните на расположенной ниже кнопке ОК") "Unable to create/open log file." (“Невозможно соз- дать/открыть журнал")
"Web Server Configuration Failed, see installation log." (“Операция настройки конфигурации Web-сервера окончилась неудачей; см. журнал инсталляции")
"Error creating user bin <... логе info here>. See the troubleshooting section in user manual." (“Ошибка при создании учетной записи пользователя bin <... здесь даны дополнительные уточне- ння>. См. раздел по поиску неисправностей в руководстве пользователя")
Была предпринята попытка выполнить инсталляцию в файловой системе, отличной от NTFS. В таком случае отсутствует возможность использовать средства защиты на уровне файлов в приложении Essentials
Одна из подзадач инсталляционной программы все еще выполняется
Попытка создать или открыть журнал инсталляции (находящийся в корневом каталоге диска, на котором устанавливается приложение, и имеющий имя nne_inxxx.log, где ххх — последовательный номер, начинающийся с 001) в процессе работы инсталляционной программы завершилась неудачей
Попытка выполнить настройку конфигурации Web- сервера окончилась неудачей
В процессе работы инсталляционной программы не удалось создать учетную запись пользователя bin
Если должны применяться средства зашиты на уровне файлов, установите приложение Essentials в файловой системе NTFS
Подождите, пока закончится выполнение подзадачи инсталляционной программы, а затем щелкните на кнопке ОК, чтобы продолжить работу
Определите, почему нельзя было создать или открыть файл, устраните эту проблему, а затем повторно запустите инсталляционную программу. Наиболее распространенными причинами этой проблемы является отсутствие свободного дискового пространства или применение средств защиты файла от записи
Для получения дополнительной информации обратитесь к журналу инсталляции (файл rme_inxxx.log).
Попытайтесь деинсталлировать пакет Windows NT 4.0 Option Pack, а затем снова его инсталлировать и повторно запустить программу инсталляции Essentials
Устраните проблему, из-за которой не удалось создать учетную запись пользователя bin, а затем повторно запустите инсталляционную программу
Сообщение об ошибкеПричина ошибки
Действия пользователя
"Setup detected a previouslyПриложение TrafficDirector
installed version ofбыло установлено после ин-
CiscoWorks... Please uninstallсталляции приложения
the previous version andCWSI/CWSI Campus
restart Setup."
(“Инсталляционная программа обнаружила ранее установленную версию приложения CiscoWorks... Деинсталлируйте предыдущую версию и перезапустите инсталляционную программу”)
"INFO: ComponentError returnedПродолжается выполнение
the following data transferприложений TrafficDirector,
error... Setup will now abort. поэтому некоторые файлы Media Name:... Component:...все еще используются, и в
File Group:... File:... Errorсвязи с этим невозможно
Number:..." (“Информационноепровести инсталляцию или
сообщение: от программыобновление
ComponentError получено следующее сообщение об ошибке при передаче данных... Теперь будет выполнено аварийное завершение инсталляционной
программы. Наименование информационного носителя:... Компонент:... Группа фай-
Установите приложение TrafficDirector в составе инсталляции CWSI Campus
Убедитесь в том, что закрыты все приложения и окна приложений TrafficDirector, а также проследите за тем, чтобы были остановлены все выполняемые программы, включая процессы базы данных
лов:... Файл:... Код ошибки:...”)
В табл. 24.3 приведены сообщения об ошибках, которые могут произойти в процессе инсталляции в системе UNIX, и описаны причины этих ошибок.
I Таблица 24.3. Сообщения об ошибках в процессе инсталляции в системе ч ; - . . soiaris/HPuxnAix/Xr'
Сообщение об ошибкеПричина ошибки
Действия пользователя
"<sub-package> did not install." Инсталляция указанного (“Не установлен пакет <sub-пакета не была выполнена
package>”)должным образом
(Это сообщение не возникает в процессе инсталляции на платформе AIX.)
Убедитесь в том, что имеется достаточный объем дискового пространства, и повторно проведите инсталляцию приложения Essentials, как описано в руководстве Installing Essentials, которое находится на узле ССО
"pkgchk <pkg_name> failed."Инструментальным средст-
(“Работа программы pkgchkвом проверки пакетов UNIX
<pkg_name> завершилась неудачей”) (pkgchk) была обнаружена (Это сообщение не возникает в ошибка в процессе провер- процессе инсталляции на плат- 131 указанного каталога
Повторно установите приложение Essentials
форме А1Х.)
Сообщение об ошибке
Причина ошибки
Действия пользователя
"WARNING: RAM in system is
Объем оперативной памяти
Установите на компьютере
SRAM. $MIN_RAM recommended."
на компьютере меньше ре-
дополнительный объем one-
(“Предупреждающее сообщение: объем ОЗУ на компьютере равен SRAM. Рекомендуемое значение — $MIN_RAM”)
комендуемого
ративной памяти
"WARNING: SWAP in system is less than 2x RAM." (“Предупреждающее сообщение: объем области подкачки в системе меньше удвоенного объема ОЗУ”)
Объем области подкачки в системе меньше рекомендуемого, который равен удвоенному значению объема ОЗУ
Увеличьте область подкачки
"ERROR: You must be root to run
Не была выполнена регист-
Зарегистрируйтесь в качест-
Unix install. Exiting."
рация в учетной записи
ве пользователя root и вве-
(“Сообщение об ошибке: ин-
пользователя root. Инстал-
дите правильный пароль
сталляция системы UNIX должна выполняться только пользователем root. Работа программы окончена”)
ляция прекращена
root
"Insufficient disk space in
Объем доступного дискового
Обеспечьте наличие в фай-
/var/adm." (“Недостаточный
пространства в файловой сис-
левой системе /var/adm не
объем дискового пространства
теме /var/adm должен состав-
меньше 5 Мбайт доступного
в файловой системе /var/adm”)
лять не меньше 5 Мбайт
дискового пространства, а затем снова вызовите на выполнение инсталляционную программу
"Insufficient disk space in
Объем доступного дискового
Обеспечьте наличие в фай-
/var/tmp." (“Недостаточный
пространства в файловой сис-
левой системе /var/tmp не
объем дискового пространства
теме /var/tmp должен состав-
меньше 1 Мбайт доступного
в файловой системе /var/tmp")
лять не меньше 1 Мбайт
дискового пространства, а затем снова вызовите на выполнение инсталляционную программу
"Insufficient disk space on any
Для работы инсталляционной
Обеспечьте наличие не мень-
local volume."
программы требуется локаль-
ше 250 Мбайт доступного
(“Недостаточный объем диско-
ный том с объемом дискового
дискового пространства на
вого пространства на любом локальном томе”)
пространства, достаточным для установки данного программного продукта
локальном дисковом томе
Сообщение об ошибке"ERROR: The patch bos.libpthreads4.3.0.2 has to be installed for the product to work correctly. Install bos.libpthreads patch 4.3.0.2 and retry installation.Exiting." (“Сообщение об ошибке: для обеспечения правильной работы данного программного продукта должно быть установлено исправление bos.libpthreads4.3.0.2. Установите исправление bos.libpthreads4.3.0.2 и повторите инсталляцию. Работа программы окончена")(Это сообщение появляется только в процессе инсталляции на платформе AIX.) "WARNING: The patch xlC.rte3.1.4.8 has to be installed for the product to work correctly." (“Предупреждающее сообщение: для обеспечения правильной работы данного программного продукта должно быть установлено исправление xlC.rte3.1.4.8”)(Это сообщение появляется только в процессе инсталляции на платформе AIX.)Сообщение об ошибке"ERROR: The patch bos.libpthreads4.3.0.2 has to be installed for the product to work correctly. Install bos.libpthreads patch 4.3.0.2 and retry installation.Exiting." (“Сообщение об ошибке: для обеспечения правильной работы данного программного продукта должно быть установлено исправление bos.libpthreads4.3.0.2. Установите исправление bos.libpthreads4.3.0.2 и повторите инсталляцию. Работа программы окончена")(Это сообщение появляется только в процессе инсталляции на платформе AIX.) "WARNING: The patch xlC.rte3.1.4.8 has to be installed for the product to work correctly." (“Предупреждающее сообщение: для обеспечения правильной работы данного программного продукта должно быть установлено исправление xlC.rte3.1.4.8”)(Это сообщение появляется только в процессе инсталляции на платформе AIX.)Причина ошибкиНа компьютере не установлено исправление bos.libpthreads4.3.0.2, которое требуется для системы AIX 4.3Причина ошибкиНа компьютере не установлено исправление bos.libpthreads4.3.0.2, которое требуется для системы AIX 4.3Исправление xlC.rte3.1.4.8 не установлено. Это может привести к нарушениям в работе приложения EssentialsИсправление xlC.rte3.1.4.8 не установлено. Это может привести к нарушениям в работе приложения EssentialsДействия пользователяУстановите исправление bos.libpthreads4.3.0.2, а затем повторно запустите инсталляционную программу. Для получения дополнительной информации обратитесь к руководству Installing Essentials, находящемуся на узле ССОДействия пользователяУстановите исправление bos.libpthreads4.3.0.2, а затем повторно запустите инсталляционную программу. Для получения дополнительной информации обратитесь к руководству Installing Essentials, находящемуся на узле ССОЗавершите инсталляционную программу, а затем установите исправление xlC.rte3.1.4.8. Для получения дополнительной информации обратитесь к руководству Installing Essentials, находящемуся на узле ССОЗавершите инсталляционную программу, а затем установите исправление xlC.rte3.1.4.8. Для получения дополнительной информации обратитесь к руководству Installing Essentials, находящемуся на узле ССО
Сообщение об ошибке
"ERROR: The patch bos.libpthreads4.3.0.2 has to be installed for the product to work correctly. Install bos.libpthreads patch 4.3.0.2 and retry installation.
Exiting." (“Сообщение об ошибке: для обеспечения правильной работы данного программного продукта должно быть установлено исправление bos.libpthreads4.3.0.2. Установите исправление bos.libpthreads4.3.0.2 и повторите инсталляцию. Работа программы окончена")
(Это сообщение появляется только в процессе инсталляции на платформе AIX.) "WARNING: The patch xlC.rte3.1.4.8 has to be installed for the product to work correctly." (“Предупреждающее сообщение: для обеспечения правильной работы данного программного продукта должно быть установлено исправление xlC.rte3.1.4.8”)
(Это сообщение появляется только в процессе инсталляции на платформе AIX.)
Сообщение об ошибке
"ERROR: The patch bos.libpthreads4.3.0.2 has to be installed for the product to work correctly. Install bos.libpthreads patch 4.3.0.2 and retry installation.
Exiting." (“Сообщение об ошибке: для обеспечения правильной работы данного программного продукта должно быть установлено исправление bos.libpthreads4.3.0.2. Установите исправление bos.libpthreads4.3.0.2 и повторите инсталляцию. Работа программы окончена")
(Это сообщение появляется только в процессе инсталляции на платформе AIX.) "WARNING: The patch xlC.rte3.1.4.8 has to be installed for the product to work correctly." (“Предупреждающее сообщение: для обеспечения правильной работы данного программного продукта должно быть установлено исправление xlC.rte3.1.4.8”)
(Это сообщение появляется только в процессе инсталляции на платформе AIX.)
Причина ошибки
На компьютере не установлено исправление bos.libpthreads4.3.0.2, которое требуется для системы AIX 4.3
Причина ошибки
На компьютере не установлено исправление bos.libpthreads4.3.0.2, которое требуется для системы AIX 4.3
Исправление xlC.rte3.1.4.8 не установлено. Это может привести к нарушениям в работе приложения Essentials
Исправление xlC.rte3.1.4.8 не установлено. Это может привести к нарушениям в работе приложения Essentials
Действия пользователя
Установите исправление bos.libpthreads4.3.0.2, а затем повторно запустите инсталляционную программу. Для получения дополнительной информации обратитесь к руководству Installing Essentials, находящемуся на узле ССО
Действия пользователя
Установите исправление bos.libpthreads4.3.0.2, а затем повторно запустите инсталляционную программу. Для получения дополнительной информации обратитесь к руководству Installing Essentials, находящемуся на узле ССО
Завершите инсталляционную программу, а затем установите исправление xlC.rte3.1.4.8. Для получения дополнительной информации обратитесь к руководству Installing Essentials, находящемуся на узле ССО
Завершите инсталляционную программу, а затем установите исправление xlC.rte3.1.4.8. Для получения дополнительной информации обратитесь к руководству Installing Essentials, находящемуся на узле ССО
Доступ к серверу Essentials
Для работы с сервером Essentials используется порт 1741. Следите за тем, что при обращении к серверу применялся правильный формат URL:
ht tp: / / server_ name: 17 41
Здесь server_name — имя сервера Essentials.
Если доступ к серверу все еще не получен, введите следующую команду в приглашении к вводу команд DOS, чтобы убедиться в том, что сервер функционирует: ping server_name•
Если отображается сообщение, что сервер находится в состоянии "alive" (функционирующий), но при попытке подключиться к серверу активизируется ошибка прокси-сервера, убедитесь в том, что настройка конфигурации прокси-сервера выполнена правильно. Если конфигурация сервера предусматривает использование прокси-сервера за пределами брандмауэра (и в программе Netscape Navigator установлены
соответствующие параметры с помощью пунктов меню Options^Network Prefer- ences^Proxies), то ошибки прокси-сервера возникают, если конфигурация проксисервера настроена неправильно в той части, которая касается фильтрации запросов, относящихся к определенному компьютеру, набору компьютеров или домену.
Настройка прокси-сервера выполнена неправильно, если возникает одна из следующих ситуаций.
Отображается сообщение об ошибке, в котором указано, что прокси-сервер используется за пределами брандмауэра.
Прокси-сервер воспринимает сервер www-int как внутренний сервер и не передает ему запросы прокси-сервера.
Выполнена настройка нового внутреннего сервера, www-nms, но при выполнении запроса к этому прокси-серверу он не распознает www-nms как внутренний сервер и формирует запросы от имени прокси-сервера.
Прокси-сервер, находящийся за пределами брандмауэра, предпринимает попытку запросить данные от сервера, который находится в сети, защищенной брандмауэром, и этот запрос блокируется.
От прокси-сервера поступает сообщение от ошибке "Connection Refused" (В соединении отказано).
Настройка параметров броузера
Если кнопки приложения Essentials не реагируют на щелчки мышью, это означает, что не разрешено применение языков Java и JavaScript. Разрешите применение Java и JavaScript, как описано в разделе Configuring Client Systems руководства Installing Essentials, которое находится на Web-узле ССО. Убедитесь в том, что настройка параметров кэша не предусматривает его установки в нулевое значение. Если возникают проблемы при использовании броузера, увеличьте значение параметров кэша, как описано в том же разделе руководства Installing Essentials.
Не корректируйте размеры окна броузера, если в данный момент выполняется загрузка рабочего стола или главной страницы. Это может вызвать ошибку Java.
Ввод и импорт информации об устройстве
В настоящем разделе рассматриваются некоторые нарушения в работе, которые могут возникнуть при попытке ввода или импорта информации об устройстве.
Ввод информации об устройстве. Если для добавления устройства применяются команды Admin^lnventory^Add Devices и отображается диалоговое окно Add/lmport Status Summary с указанием, что состояние устройства не изменилось и устройство остается зависшим ("pending") в течение 15 минут, проверьте состояние всех процессов, чтобы убедиться в том, что они функционируют нормально, как описано в следующих разделах.
Шаг 1. Для просмотра наиболее актуальной информации о состоянии устройства щелкните на кнопке Update диалогового окна Add/lmport Status Summary (Admin^lnventory^lmport Status).
Шаг 2. Чтобы определить, функционирует ли процесс DiServer, выберите пункты меню Admin^System Admin^Process Status. (DiServer представляет
собой процесс, который отвечает за проверку устройств и вывод их из состояния "pending".)
Даже если процесс DiServer отображает сообщения о состоянии "Running Normally" (Нормальное функционирование), может сохраняться состояние ошибки. Необходимо остановить и перезапустить устройство следующим образом.
Чтобы остановить процесс DiServer, выполните следующие действия.
Выберите пункты меню Admin^System Admin^Stop Process. Появится диалоговое окно Stop Process. Щелкните на переключателе Process.
В поле Process Name выберите DiServer, а затем щелкните на кнопке Finish.
Чтобы перезапустить процесс DiServer, выполните следующие действия.
Перейдите в папку System Admin и щелкните на кнопке Start Processes. Появится диалоговое окно Start Process.
Щелкните на переключателе Process.
В поле Process Name выберите DiServer, а затем щелкните на кнопке Finish.
Шаг 3. Возвратитесь на экран Add/lmport Status Summary, выбрав в меню команды lnventory=>lmport Status, а затем щелкните на кнопке Update. Через несколько минут устройство должно перейти в состояние "managed” (управляемое).
Импорт информации об устройстве. Если во время импорта информации об устройстве возникают затруднения, выполните следующие рекомендации.
Увеличьте установку тайм-аута SNMP. Для получения дополнительной информации обратитесь к оперативному справочному руководству.
Убедитесь в том, что для рассматриваемых устройств правильно введены определения групп устройств чтения.
Сбор информации о сервере
В состав приложения Essentials входит утилита, которая позволяет устранить нарушения в работе сервера. Для получения информации о сервере Essentials можно воспользоваться одним из следующих способов.
Выберите пункт меню Admin^Troubleshooting^Collect Server Info. В появившемся диалоговом окне Collect Server Information щелкните на кнопке Display, чтобы собрать информацию о сервере. После того как информация будет собрана, появится диалоговое окно, в котором будет указано, как получить доступ к информации о сервере в конкретном Web-броузере.
На сервере в окне командного интерпретатора введите следующую команду: collect.info filename.html
Здесь filename — ранее выбранное имя файла.
Если collect.info не распознается как команда, добавьте следующее имя пути к переменной среды PATH:
В системе NT:C:\Program Files\CSCOpx\cgi-bin\admin\perl
В системе Solarisи HPUX:/opt/CSCOpx/bin
В системе AIX:/usr/CSCOpx/bin
На компьютерах с операционной системой UNIX информация о сервере будет собрана в файл /var/tmp/px_status.info. Отправьте этот файл по электронной почте в корпорацию Cisco, если получите соответствующее указание от представителя службы технической поддержки.
Приложения Essentials Daemon Manager и CWSI Campus
Приложение CWSI Campus в своей работе использует средства приложения Essentials Daemon Manager. Поэтому для обеспечения нормальной работы приложения CWSI Campus в системе должно быть установлено приложение Essentials Daemon Manager. Кроме того, если приложение Essentials Daemon Manager перестало нормально функционировать, его необходимо остановить и перезапустить.
Чтобы остановить работу приложения Essentials Daemon Manager с помощью графического интерфейса пользователя в системе Windows NT, выполните следующие действия.
Шаг 1. В меню Windows NT выберите команды Start^Settings^Control Panels.
Шаг 2. Дважды щелкните на кнопке Services.
Шаг 3. В появившемся диалоговом окне выберите элемент Essentials Daemon Manager.
Шаг 4. Щелкните на кнопке Stop.
Чтобы перезапустить приложение Essentials Daemon Manager с помощью графического интерфейса пользователя, выполните следующие действия.
Шаг 1. На рабочем столе Windows NT выберите команды Start^Settings^Control Panels.
Шаг 2. Дважды щелкните на кнопке Services.
Шаг 3. В появившемся диалоговом окне выберите элемент Essentials Daemon Manager.
Шаг 4. Щелкните на кнопке Start.
Чтобы остановить и запустить приложение Essentials Daemon Manager с помощью интерфейса командной строки, выполните следующие действия.
Шаг 1. Зарегистрируйтесь в системе в качестве администратора.
Шаг 2. Перейдите в строку приглашения к вводу команд или откройте окно командного интерпретатора.
Шаг 3. Остановите сервер, набрав следующую команду в приглашении к вводу команд: net stop crmdmgtd
Шаг 4. Запустите сервер, набрав следующую команду в приглашении к вводу команд: net start crmdmgtd
Чтобы остановить и перезапустить приложение Essentials Daemon Manager в системе Solaris, выполните следующие действия.
Шаг 1. Зарегистрируйтесь в качестве пользователя root.
Шаг 2. Перейдите в строку приглашения к вводу команд или откройте окно командного интерпретатора.
Шаг 3. Остановите сервер, набрав следующую команду в приглашении к вводу команд:
I /etc/init.d/dmgtd stop
Шаг 4. Запустите сервер, набрав следующую команду в приглашении к вводу команд:
I /etc/init.d/dmgtd start
Устранение нарушений при регистрации на сервере AniServer
Если только что был выполнен перезапуск компьютера, но пользователь не может зарегистрироваться в приложении <№stname>AniServer, то, возможно, сервер ANI не перешел в состояние готовности к получению сообщений. Необходимо подождать несколько минут, а затем снова попытаться зарегистрироваться.
Если все еще не удается зарегистрироваться, выполните следующие действия.
Шаг 1. Перейдите в строку приглашения к вводу команд или откройте окно командного интерпретатора.
Шаг 2. Проверьте, функционируют ли демоны; для этого вызовите на выполнение утилиту с интерфейсом командной строки pdshow, которая находится в каталоге C:\Program Files\CSCOpx\bin в системе Windows NT или в каталоге /opt/CSCOpx/bin в системе Solaris.
pdshow RmeOrb AniServer
Результаты выполнения этой утилиты позволяют определить, функционируют ли демоны OSAgent и AniServer и подключен ли сервер AniServer к базе данных.
Шаг 3. Вызовите на выполнение утилиту osfind.
Присвойте переменной среды OSAGENT_PORT значение 42342. Это — номер порта, используемый программой OSAgent приложения Essentials.
Присвойте значение параметру OSAGENT_PORT=42342 (в системе Windows NT).
I setenv OSAGENT_PORT 42342 (в системе Solaris)
Вызовите на выполнение утилиту osfind, чтобы проверить, зарегистрирован ли сервер AniServer в программе OSAgent. Это инструментальное средство можно найти в каталоге C:\Program Files\CSCOpx\lib\visigenics\bin в системе Windows NT или в каталоге /opt/CSCOpx/lib/visigenics/bin в системе Solaris.
Если сервер <№stname>AniServer зарегистрирован в программе OSAgent, убедитесь в том, что в окне регистрации указано такое же имя <Sostname>AniServer, какое зарегистрировано в программе OsAgent.
Если имя <№stname>AniServer зарегистрировано, попытайтесь войти в приложение CWSI Campus.
А если имя <Sostname>AniServer не зарегистрировано, остановите и перезапустите приложение CWSI Campus.
Шаг 4. Введите следующую команду, чтобы остановить процессы CWSI Campus: Stopcwsiserver
Повторное появление на экране приглашения к вводу команд означает, что все демоны остановлены.
Шаг 5. Введите следующую команду, чтобы запустить процессы CWS1 Campus: Startcwsiserver
Ожидайте, пока не появится приглашение к вводу команд.
Шаг 6. Вызовите на выполнение утилиту osfind.
Если имя <№stname>AniServer зарегистрировано, попытайтесь войти в приложение CWSI Campus.
А если имя <Hostname>kniServer не зарегистрировано, перейдите к следующему шагу.
Шаг 7. С помощью утилиты pdreg проверьте, была ли выполнена должным образом регистрация имени <№stname>AniServer в программе диспетчера демонов Daemon Manager во время инсталляции.
pdreg -1 AniServer
Эта команда позволяет проверить, зарегистрировано ли приложение AniServer в программе Essentials Daemon Manager.
Если приложение AniServer зарегистрировано в программе Essentials Daemon Manager, но не выполняется, проверьте журнал ani.log, чтобы определить, до какого этапа был выполнен процесс инициализации.
Если имя сервера AniServer не зарегистрировано, появится следующее сообщение об ошибке:
ERROR AniServer is not a registered server name.
Если имя AniServer не зарегистрировано в программе Essentials Daemon Manager, то эта программа не сможет инициализироваться при запуске. Обратитесь за дополнительными указаниями к представителю Cisco ТАС.
Проверка соединения с базой данных
Чтобы определить, можно ли подключиться к базе данных CWSI Campus, вызовите на выполнение утилиту testdbconn.
Шаг 1. Найдите утилиту testdbconn в каталоге <CWSIROOT>\bin, где <CWSIROOT> — каталог, в котором установлена система CWSI Campus.
Шаг 2. Вызовите на выполнение утилиту testdbconn.
Если эта программа будет выполнена успешно и на экране снова появится приглашение к вводу команд, это означает, что соединение с базой данных устанавливается нормально.
Методы оценки ситуации и устранения нарушений в работе приложения RME
В приложении Essentials предусмотрены определенные методы оценки состояния и устранения нарушений в работе.
В настоящем разделе рассматриваются следующие темы.
Формат сообщений об ошибках.
Средства регистрации состояния процесса.
Устранение нарушений в работе процесса.
Формат сообщений об ошибках
В приложении Essentials отображаются сообщения об ошибках двух типов:
сообщения об ошибках в интерфейсе;
сообщения об ошибках в серверной части, которые записываются в системный журнал.
Сообщения об ошибках в интерфейсе отображаются в диалоговых окнах с описаниями вероятных причин и с перечнем рекомендуемых действий по их устранению, если такие действия предусмотрены.
Ниже перечислены три типа сообщений об ошибках в интерфейсе.
USER. Указывает на ошибку пользователя или неправильный ввод данных.
SYSTEM. Указывает на отказ системы.
INTERNAL. Содержит информацию о неправильно заданном коде программного продукта.
В некоторых окнах с сообщениями об ошибках в интерфейсе имеется кнопка Details, щелкнув на которой можно ознакомиться с дополнительной информацией и рекомендациями по устранению нарушений в работе. Появится информационное диалоговое окно.
Сообщения об ошибках в серверной части возникают при обнаружении нарушений в работе процессов, функционирующих на сервере Essentials. Сообщения об ошибках в серверной части записываются в системный журнал syslog.
Обратитесь к соответствующему руководству по инсталляции приложения Essentials для получения информации о том, где находятся журналы с сообщениями об ошибках. Формат сообщения об ошибке, которое записывается в журнал syslog, показан на рис. 24.1.
Дата^время СерверИмя идентификатор процесса
Jan 01 12:00:00 CRM servername DiServer [26744] :
PGM_NM=DIServer : 2631 : TYPE=WARNING: :System
Error *Could not
Puc. 24.1. Формат сообщения об ошибке, которое записывается в журнал syslog
Средства регистрации состояния процесса
Для просмотра информации о нарушениях в работе процессов и устранения этих нарушений можно применить следующие два интерфейса:
рабочий стол программы Essentials (иерархическое меню);
интерфейс командной строки.
Для просмотра информации о состоянии процесса и устранения нарушений в работе процесса применяются опции Process Status, Start Process и Stop Process меню System Admin. Для работы с процессами, контроль за состоянием которых не может осуществляться с помощью интерфейса рабочего стола (например, syslogd), применяется интерфейс командной строки.
В табл. 24.4 перечислены средства управления процессом, доступ к которым может быть получен с помощью графического интерфейса рабочего стола Essentials, и соответствующие им утилиты с интерфейсом командной строки.
^Таблица 24.4. Средствауправления процессомJ
Команды меню рабочего стопа EssentialsЭквивалентные команды командной строки
Process Statuspdshow
Start Processpdexec
Stop Processpdtenn
Полное описание процессов интерфейса рабочего стола содержится в оперативном справочном руководстве по приложению RME.
Аварийное завершение процесса может быть вызвано многими факторами. Например, отказ в работе машины базы данных может возникнуть по одной из следующих причин.
В системах UNIX для базы данных используется определенный объем пространства в файловой системе /tmp. Если это пространство заполняется, база данных больше не принимает запросы на установление соединений из клиентского кода и ее работа завершается аварийно.
Заполнена файловая система, в которой находится файл базы данных.
В случае аварийного завершения одного из прикладных процессов проверьте, не возникла ли в системе какая-либо из этих аварийных ситуаций или какие-либо иные нарушения в работе, и попытайтесь их исправить.
Устранение нарушений в работе процесса
Информация о возможных нарушениях в работе процессов предоставляется пользователю в виде таблицы Process Failures. В ней содержатся данные о том, завершилась ли работа процесса аварийно или останов процесса был выполнен администратором.
Если процесс функционирует не так, как обычно, и необходимо определить возможную причину такой ситуации, выполните поиск нарушений в работе процесса с помощью следующих действий.
Шаг 1. Выберите пункт меню Admin^Troubleshooting^Process Failures.
Шаг 2. Щелкните на имени процесса, чтобы вывести на экран таблицу Process Details.
Шаг 3. Щелкните на кнопке Back, чтобы вернуться к таблице Process Failures.
Шаг 4. Щелкните на любой записи о состоянии процесса, чтобы вывести на экран окно системного журнала System Log.
Шаг 5. Щелкните на кнопке Back, чтобы вернуться к таблице Process Failures.
Шаг 6. Для обновления значений полей щелкните в любое время на кнопке Update.
Запуск процесса
Сценарий. Проверено состояние процесса и обнаружено, что в таблице Process Status для процесса DbServer указано состояние "Failed to run". Необходимо попытаться перезапустить процесс.
Чтобы перезапустить процесс с помощью иерархического меню интерфейса рабочего стола, выполните следующие действия.
Шаг 1. Выберите пункты меню Admin^System Admin^Start Process.
Появится диалоговое окно Start Process.
Шаг 2. Щелкните на кнопке Process, выберите процесс DbServer из раскрывающегося списка Process Name, а затем щелкните на кнопке Finish.
Появится таблица Process Status. Если теперь сообщение о состоянии имеет вид "Running Normally", это означает, что проблема решена.
Если же процесс все еще не функционирует должным образом, то может потребоваться собрать дополнительную информацию о сервере и процессе, чтобы продолжить поиск неисправностей.
Для перезапуска процесса с помощью интерфейса командной строки выполните следующее.
Шаг 1. Введите команду pdexec DbServer.
Шаг 2. Снова введите команду pdshow DbServer, чтобы определить, нормально ли функционирует данный процесс.
Если процесс работает нормально, появится следующее сообщение:
Process2 DbServer
State = Running normally Pid= 21473
RC=0
Signo = 0 Start = 19:16:15 06/02/1999 Stop = Not applicable Core = Not applicable
Info = Data server (dbeng50) invoked
Если все еще не удалось добиться нормальной работы процесса, просмотрите журнал ошибок, чтобы продолжить поиск неисправностей.
Останов процесса
Сценарий. Необходимо создать резервную копию всех данных, хранящихся на жестком диске, поэтому выполняется останов процесса DbServer.
Чтобы остановить процесс DbServer с помощью иерархического меню интерфейса рабочего стола, выполните следующие действия.
Шаг 1. Выберите пункты меню Admin^System Admin^Stop Process.
Шаг 2. Появится диалоговое окно Stop Process.
Шаг 3. Щелкните на переключателе Process.
Шаг 4. Выберите элемент DbServer в раскрывающемся списке Process Name, а затем щелкните на кнопке Finish.
Процесс остановится, и в таблице Process Status появится сообщение "Administrator has shut down this server" (Этот сервер остановлен администратором).
Чтобы остановить процесс DbServer с помощью интерфейса командной строки, выполните следующие действия.
Шаг 1. Введите команду pdterm DbServer.
Шаг 2. Введите команду pdshow DbServer.
Появится следующее сообщение о состоянии с указанием, что процесс был остановлен:
Process2 DbServer
State = Administrator has shut down this server
Pid= 0
RC=0
Signo = 0
Start = 19:16:15 06/02/97
Stop = 11:27:05 06/03/97
Core = Not applicable
Info = Not applicable
Рекомендации по устранению нарушений в работе приложения Essentials
Рекомендации по устранению нарушений в работе приложения Essentials приведены в табл. 24.5. Если рекомендуемые здесь действия не позволяют устранить ошибку, просмотрите примечания к выпуску, соответствующие конкретной платформе, чтобы ознакомиться с возможными альтернативными предложениями.
Таблица 24.5. Рекомендации по устранению нарушений в работе «приложения Essentials „,./-‘ * , >*а<- т^ ■/S&W^.
ПризнакПричина ошибкиДействия пользователя
неисправности/сообщение об ошибке
"Admin: unable to log on to Essentials." (“Admin: невозможно зарегистрироваться в приложении Essentials”) (Относится только к системе Windows NT.)"Authorization required. Please log in with your username and password." (Требуется авторизация. Зарегистрируйтесь co своим именем пользователя и паролем”)"Admin: unable to log on to Essentials." (“Admin: невозможно зарегистрироваться в приложении Essentials”) (Относится только к системе Windows NT.)"Authorization required. Please log in with your username and password." (Требуется авторизация. Зарегистрируйтесь co своим именем пользователя и паролем”)Установлен несовместимый сервер IIS (Internet Information Server — информационный сервер Internet) компании MicrosoftПрименяется несовместимая версия броузера, которая вызывает сбой при обработке cookie- файла (невозможно выполнить выборку cookie-файла)Установлен несовместимый сервер IIS (Internet Information Server — информационный сервер Internet) компании MicrosoftПрименяется несовместимая версия броузера, которая вызывает сбой при обработке cookie- файла (невозможно выполнить выборку cookie-файла)Просмотрите инструкцию по инсталляции, выгрузите имеющийся сервер Microsoft IIS, а затем в случае необходимости загрузите сервер Microsoft IIS с подходящей версиейОбратитесь к документации по инсталляции, чтобы определить поддерживаемую версию программного обеспечения Internet Explorer/Netscape NavigatorПросмотрите инструкцию по инсталляции, выгрузите имеющийся сервер Microsoft IIS, а затем в случае необходимости загрузите сервер Microsoft IIS с подходящей версиейОбратитесь к документации по инсталляции, чтобы определить поддерживаемую версию программного обеспечения Internet Explorer/Netscape Navigator
"Admin: unable to log on to Essentials." (“Admin: невозможно зарегистрироваться в приложении Essentials”) (Относится только к системе Windows NT.)
"Authorization required. Please log in with your username and password." (Требуется авторизация. Зарегистрируйтесь co своим именем пользователя и паролем”)
"Admin: unable to log on to Essentials." (“Admin: невозможно зарегистрироваться в приложении Essentials”) (Относится только к системе Windows NT.)
"Authorization required. Please log in with your username and password." (Требуется авторизация. Зарегистрируйтесь co своим именем пользователя и паролем”)
Установлен несовместимый сервер IIS (Internet Information Server — информационный сервер Internet) компании Microsoft
Применяется несовместимая версия броузера, которая вызывает сбой при обработке cookie- файла (невозможно выполнить выборку cookie-файла)
Установлен несовместимый сервер IIS (Internet Information Server — информационный сервер Internet) компании Microsoft
Применяется несовместимая версия броузера, которая вызывает сбой при обработке cookie- файла (невозможно выполнить выборку cookie-файла)
Просмотрите инструкцию по инсталляции, выгрузите имеющийся сервер Microsoft IIS, а затем в случае необходимости загрузите сервер Microsoft IIS с подходящей версией
Обратитесь к документации по инсталляции, чтобы определить поддерживаемую версию программного обеспечения Internet Explorer/Netscape Navigator
Просмотрите инструкцию по инсталляции, выгрузите имеющийся сервер Microsoft IIS, а затем в случае необходимости загрузите сервер Microsoft IIS с подходящей версией
Обратитесь к документации по инсталляции, чтобы определить поддерживаемую версию программного обеспечения Internet Explorer/Netscape Navigator
Признак
неисправности/сообщение об ошибке
Причина ошибкиДействия пользователя
"Database: inaccessible." (“База данных недоступна”) Это сообщение может появиться в окне Process Status, в котором показано одно из следующих сообщений.
"ICServer not running" (“Не функционирует приложение ICServer”)
"DiServer not running" (“He функционирует приложение DiServer”)
"AvLoader not running" ("He функционирует приложение AvLoader”)
"DbMonitor not running" (“He функционирует приложение DbMonitor”)
"Observer not running” (“He функционирует приложение DbServer”)
"EssentialsOSG not running" (“He функционирует приложение EssentialsOSG”) Возможно также, что при выполнении операции добавления устройства Add Device появится сообщение об ошибке “failed to get complete list of domains" (“не удалось получить полный список доменов”) База данных: ошибка ODBC при работе с приложением Essentials (относится только к системе Windows NT)
Сервер не может подклю-Шаг 1. Войдите в систему
читься к базе данных, кото-Essentials в качестве
рая повреждена или недос-пользователя admin.
Шаг 2. Выберите пункты меню Admins Troubleshooting Proc- ess^ Failures, чтобы получить список ава. 'рийно завершивших
ся серверных процессов Essentials.
Шаг 3. Выберите пункты меню Admins Troubleshooting^ Self Test.
Шаг 4. Щелкните на кнопке Create, чтобы сформировать отчет.
Шаг 5. Щелкните на кнопке Display, чтобы вывести отчет на экран.
Шаг 6. Выберите пункты меню Admins Troubleshooting^ Collect Server Info.
Шаг 7. Щелкните на ссыпке Product Database Status, чтобы получить подробную информацию о состоянии базы данных
Библиотека .dll ресурсовУстановите средства под-
ODBC и диспетчер драйвера держки интерфейса ODBC с ODBC имеют разные версии дистрибутивного CD-ROM системы Windows NT (выбрав установку сервера SQL)
Конфигурация устройства: из архива невозможно выбрать конфигурации модулей для устройств Catalyst
При добавлении или импор- Введите правильные пароли те информации об устройст- Telnet и режима enable для ве был введен неправильныйустройств Catalyst в базе
парольданных Essentials.
В архиве конфигураций для сбора конфигураций модулей для устройств Catalyst используется протокол Telnet.
Признак
неисправности/сообщение об ошибке
Причина ошибки
Действия пользователя
Конфигурация устройства: из
При добавлении или импорте
Для того чтобы в архив конфигураций были успешно собраны конфигурации модулей ATM и RSM, для этих модулей должны применяться такие же пароли Telnet, как и для блоков управления устройств семейства Catalyst 5000.
Дополнительная информация о вводе паролей приведена в оперативном руководстве по приложению Essentials Введите в базу данных
архива невозможно выбрать
устройства были заданы не-
Essentials правильные опре-
текущую конфигурацию для
правильные определения
деления групп устройств
устройства
групп устройств чтения и за-
чтения и записи.
писи
Измените последователь-
Конфигурация устройства:
При добавлении или импорте
ность применения протоколов для выборки информации о конфигурации. (Загрузка конфигураций из устройств в архив конфигураций выполняется с помо- шью трех различных транспортных протоколов — ТЕТР, Telnet и RCP, обычно в таком порядке).
Для ознакомления с дополнительной информацией об определении последовательности транспортных протоколов, применяемых для сбора конфигураций, обратитесь к оперативному справочному руководству по приложению Essentials Введите правильные пароли
невозможно выполнить вы-
информации об устройстве был
протокола Telnet и режима
борку в архив пусковой кон-
введен неправильный пароль
enable для устройства в базе
фигурации для устройства
данных Essentials.
Если настройка конфигурации устройства выполнена с учетом использования аутентификации TACACS, то при импорте устройства в базу данных Essentials введите имя пользователя и пароль TACACS (а не пароль Telnet).
Признак
неисправности/сообщение об ошибке
Причина ошибки
Действия пользователя
Конфигурация устройства: несовпадение имен хостов DNS. В системе DNS не известен IP-адрес
Конфигурация устройства: при вызове на выполнение команд Tasks^Device Configuration или Admin^Device Configuration возникает ошибка сервера времени выполнения
Не выполнена настройка сервера DNS для преобразования' имени хоста устройства
Приложение CMLogger не функционирует
Если настройка конфигурации устройства выполнена с учетом использования аутентификации локального пользователя, введите в базу данных Essentials имя и пароль локального пользователя.
Если настройка конфигурации устройства выполнена с учетом использования аутентификации Telnet, убедитесь в том, что применяется пароль протокола Telnet, пароль режима enable, секретный пароль режима enable (если он предусмотрен в конфигурации), а также имя и пароль локального пользователя (если они предусмотрены в конфигурации). Если это не предусмотрено в конфигурации, не вводите имя и пароль локального пользователя или имя и пароль пользователя TACACS. Для ознакомления с дополнительной информацией о вводе паролей и аутентификационных данных TACACS, данных о локальном пользователе и опций протокола RCP обратитесь к оперативному справочному руководству по приложению Essentials
Проверьте, распознает ли сервер DNS имя хоста устройства. В качестве иного варианта вместо имени хоста укажите IP-адрес
Шаг 1. Войдите в систему Essentials в качестве пользователя admin.
Шаг 2. Выберите пункты меню Admin^System Admin^Start Process.
Признак
неисправности/сообщение об ошибке
Причина ошибки
Действия пользователя
Конфигурация устройства: выборка текущей конфигурации для устройства по протоколу ТЕТР невозможна из-за тайм-аутов SNMP
Программным обеспечением SNMP не отведено достаточное время на выполнение указанной операции
Шаг 3. Запустите систему. Если выполнение указанных задач настройки конфигурации все еше завершается неудачей, выберите пункты меню Admins Troubleshootlng=*Proce ss Failures, чтобы получить список серверных процессов Essentials, завершившихся аварийно.
Шаг 4. Выберите пункты меню Admins Troubleshooting1* Self Test.
Шаг 5. Щелкните на кнопке Create, чтобы сформировать отчет.
Шаг 6. Щелкните на кнопке Display, чтобы вывести отчет на экран.
Шаг 7. Выберите пункты меню Admin1* Troubleshooting1* Collect Server Info.
Шаг 8. Щелкните на ссылке Product Database Status, чтобы получить подробную информацию о состоянии базы данных
Увеличьте установки таймаута SNMP путем настройки параметров повторных попыток и тайм-аутов SNMP. Для ознакомления с дополнительной информацией о настройке конфигурации общесистемных тайм-аутов SNMP и повторных попыток SNMP обратитесь к оперативному справочному руководству по приложению Essentials
Признак неисправности/сообщение об ошибке
Причина ошибки
Действия пользователя
Дисплей: невозможен запуск
В файле httpd.conf не указа-
Укажите имя сервера в фай-
аплета, поскольку не найден класс browserserver
(относится только к системе Solaris)
но имя сервера
ле httpd.conf
Дисплей: отображается толь-
Несовместимое программное
Обратитесь к документации
ко правая сторона окна Essentials
обеспечение броузера
Рабочий стол не зарегистрирован в системе DNS
по инсталляции для получения информации о поддерживаемом программном обеспечении Internet Explorer/Netscape Navigator Зарегистрируйте рабочий стол в системе DNS
Учетная информация: им-
Пользователь bin не является
Введите пользователя в со-
порт устройства из локальной базы данных завершается аварийно (относится только к системе Solaris)
членом группы CiscoWorks
Неправильное преобразование имен
став группы перед запуском приложения Essentials
Откорректируйте преобразование имен. Если это невозможно, то будут применяться дистанционные правила импорта; поместите файл .rhosts в исходный каталог пользователя bin
Учетная информация: им- ■
Приложение Essentials и уда-
Поместите станции с уста-
порт устройства с удаленного
ленный сервер NMS нахо-
новленным приложением
сервера NMS завершается аварийно
дятся в разных доменах DNS
Essentials и удаленным сервером NMS в одни и те же домены DNS
Учетная информация: поряд-
В отчеты по аппаратным
Никакие действия не требу-
ковый номер устройства или
средствам поступают данные
ются, но может быть выпол-
номер шасси маршрутизатора
из определяемого пользовате-
йена корректировка порядке-
отличается от указанного на
лем необязательного поля по-
вого номера вручную, чтобы
внешних бирках
рядкового номера при вводе информации о маршрутизаторе или другом устройстве в базу данных Essentials (или с помощью команды Change Device Attributes), а не из переменной с порядковым номером шасси базы данных SNMP. Порядковый номер, откорректированный вручную, имеет более высокий приоритет по сравнению с внешним номером
он снова совпадал с номером, указанным на шасси
ПризнакПричина ошибки
неисправности/сообщение об ошибке
Действия пользователя
Учетная информация: уст-База данных повреждена
ройство остается в приостановленном состоянии
Остановите приложение Essentials. Инсталлируйте резервную базу данных, если она имеется; в ином случае вместо поврежденной базы данных установите исходную базу данных px.db
Не функционирует процесс DiServer
Проверьте состояние процесса. Если процесс DiServer не функционирует, перезапустите его
Импортирован широковещательный адрес и используется для записи по протоколу SNMP
Приостановите работу устройства. Проверьте это устройство с помощью инструментального средства проверки адреса (Tools1^ Connectivity Tools^Validate Device Addresses), чтобы убедиться в том, что не используется широковещательный адрес или адрес сети
Учетная информация: не К конфигурации групп уст- происходит импорт уст- ройств сервера SNMP при- ройств меняется список доступа
Произошел тайм-аут SNMP
Введите операторы permit во все списки доступа на всех маршрутизаторах
Увеличьте значение таймаута замедления SNMP и повторите попытку выборки параметров
Произошел сбой при выполнении обратного поиска DNS
Введите запись для данного устройства в локальный файл hosts
Имя устройства не введено в конфигурацию DNS или в локальный файл hosts
Введите запись для данного устройства в базу данных DNS или в локальный файл hosts
Учетная информация: невоз-В программном обеспечении
можно ввести устройство вHP OpenView/SNMP имеется
базу данныхстарая версия файлов wsnmp.dll
Производительность: прило-Несовместимое программное
жение Essentials медленнообеспечение
работает при импорте устройства (относится только к системе Windows NT)
Удалите или переименуйте файлы wsnmp.dll версии HP OpenView
Обратитесь к документации по инсталляции. Проверьте, правильно ли загружено программное обеспечение протокола SP и сервера Microsoft IIS. В случае необходимости выгрузите и снова загрузите приложение Essentials
Признак неисправности/сообщение об ошибке
Причина ошибкиДействия пользователя
Печать: невозможно вывести на печать графики в приложении Essentials
Программное обеспечениеЧтобы вывести на печать со-
броузера накладывает огра- держимое окна Essentials, ничения на функции печати воспользуйтесь функциями печати экрана или перехвата экрана конкретной операционной системы
Отчеты: при вызове на выполнение команд формирования отчетов броузер зависает
Несовместимое программное Обратитесь к документации обеспечение броузерапо инсталляции для получе
ния информации о поддерживаемом программном обеспечении броузера
Управление программным обеспечением: функция утверждения не способна изменить запланированное время выполнения заданий по распространению образов с использованием средств Software Management
Для заданий Distribute Images Если для заданий Distribute предписано применениеImages требуется утвержде-
функции подготовки и про- ние, то средства Software веркиManagement не позволяют
изменить запланированное время выполнения заданий с помощью диалоговых окон Browse Job Status.
Создайте новое задание и передайте его на утверждение
Управление программным обеспечением: невозможно выполнить операцию отмены обновления на устройствах Microcom и Catalyst
Операция отмены обновле- Для ознакомления с поддер- ния программного обеспече- живаемыми устройствами и ния не поддерживается навыпусками программного
устройствеобеспечения, а также со
средствами Software Management обратитесь к оперативному справочному руководству и изучите таблицу поддерживаемых устройств Supported Device Matrix
Управление программным обеспечением: задания Distribute Images и Image Import завершаются на устройстве аварийно
На устройстве эксплуатиру- Перейдите на узел ССО и ется некачественное про-проверьте версию приме-
граммное обеспечениеняемого образа программ
ного обеспечения. Если данная версия программного обеспечения все еще поддерживается, разрешите применение режима отладки и отметьте флажок Enable Debugging (Admin^Software Management^Edit Preferences). Снова вызовите задание на выполнение, а затем воспользуйтесь опцией Mail or Copy Log File, чтобы извлечь информацию об отладке Software Management.
ПризнакПричина ошибкиДействия пользователя
неисправности/сообщение об ошибке
Управление программным обеспечением: задание остается в приостановленном состоянии по истечении запланированного времениУправление программным обеспечением: задание остается в приостановленном состоянии по истечении запланированного времениСервер Essentials не функционирует, выключен или перезагружен до наступления запланированного времени выполнения заданияСервер Essentials не функционирует, выключен или перезагружен до наступления запланированного времени выполнения заданияУправление программным обеспечением: задание остается в рабочем состоянии, а отчет Job Details показывает отсутствие изменений в ходе выполнения заданияУправление программным обеспечением: задание остается в рабочем состоянии, а отчет Job Details показывает отсутствие изменений в ходе выполнения заданияСервер Essentials не функционирует, выключен или перезагружен во время выполнения задания, в результате чего задание завершилось аварийноСервер Essentials не функционирует, выключен или перезагружен во время выполнения задания, в результате чего задание завершилось аварийноУправление программным обеспечением: после ввода образов программного обеспечения модема или образов микропрограмм CIP в библиотеку управления программным обеспечением тип соответствующего образа характеризуется как “Unknown" (Неизвестный).Средства управления программным обеспечением не могут выполнить выборку атрибутов из образовУправление программным обеспечением: после ввода образов программного обеспечения модема или образов микропрограмм CIP в библиотеку управления программным обеспечением тип соответствующего образа характеризуется как “Unknown" (Неизвестный).Средства управления программным обеспечением не могут выполнить выборку атрибутов из образовОбразы для цифровых модемов Cisco 3640 не поддерживаются в виде файлов формата AS5300.В образе встроенного программного обеспечения Microcom не содержится сочетание кода встроенного программного обеспече- ния/кода DSP.Микропрограмма CIP имеет более старую версию, чем версия 22.0Образы для цифровых модемов Cisco 3640 не поддерживаются в виде файлов формата AS5300.В образе встроенного программного обеспечения Microcom не содержится сочетание кода встроенного программного обеспече- ния/кода DSP.Микропрограмма CIP имеет более старую версию, чем версия 22.0Отправьте эту информацию в центр Cisco ТАС илн в службу технической поддержки вместе с полным описанием возникшей проблемы Средства Software Management переводят задание в аварийное состояние через 1 час после истечения запланированного времени выполнения задания.Не вносите изменения в задание, если оно приостановлено ("pending"); эта задача возложена на систему. В случае необходимости создайте другое задание Средства Software Management переводят задание в аварийное состояние через 1 час после истечения запланированного времени выполнения задания.Не вносите изменения в задание, если оно приостановлено ("pending"); эта задача возложена на систему. В случае необходимости создайте другое задание Загрузите с узла ССО поддерживаемую версию программного обеспече- ния/встроенного программного обеспечения.Для ознакомления с информацией о поддерживаемых устройствах и выпусках программного обеспечения обратитесь к таблице поддерживаемых устройств Supported Device Matrix оперативного справочного руководстваОтправьте эту информацию в центр Cisco ТАС илн в службу технической поддержки вместе с полным описанием возникшей проблемы Средства Software Management переводят задание в аварийное состояние через 1 час после истечения запланированного времени выполнения задания.Не вносите изменения в задание, если оно приостановлено ("pending"); эта задача возложена на систему. В случае необходимости создайте другое задание Средства Software Management переводят задание в аварийное состояние через 1 час после истечения запланированного времени выполнения задания.Не вносите изменения в задание, если оно приостановлено ("pending"); эта задача возложена на систему. В случае необходимости создайте другое задание Загрузите с узла ССО поддерживаемую версию программного обеспече- ния/встроенного программного обеспечения.Для ознакомления с информацией о поддерживаемых устройствах и выпусках программного обеспечения обратитесь к таблице поддерживаемых устройств Supported Device Matrix оперативного справочного руководства
Управление программным обеспечением: задание остается в приостановленном состоянии по истечении запланированного времени
Управление программным обеспечением: задание остается в приостановленном состоянии по истечении запланированного времени
Сервер Essentials не функционирует, выключен или перезагружен до наступления запланированного времени выполнения задания
Сервер Essentials не функционирует, выключен или перезагружен до наступления запланированного времени выполнения задания
Управление программным обеспечением: задание остается в рабочем состоянии, а отчет Job Details показывает отсутствие изменений в ходе выполнения задания
Управление программным обеспечением: задание остается в рабочем состоянии, а отчет Job Details показывает отсутствие изменений в ходе выполнения задания
Сервер Essentials не функционирует, выключен или перезагружен во время выполнения задания, в результате чего задание завершилось аварийно
Сервер Essentials не функционирует, выключен или перезагружен во время выполнения задания, в результате чего задание завершилось аварийно
Управление программным обеспечением: после ввода образов программного обеспечения модема или образов микропрограмм CIP в библиотеку управления программным обеспечением тип соответствующего образа характеризуется как “Unknown" (Неизвестный).
Средства управления программным обеспечением не могут выполнить выборку атрибутов из образов
Управление программным обеспечением: после ввода образов программного обеспечения модема или образов микропрограмм CIP в библиотеку управления программным обеспечением тип соответствующего образа характеризуется как “Unknown" (Неизвестный).
Средства управления программным обеспечением не могут выполнить выборку атрибутов из образов
Образы для цифровых модемов Cisco 3640 не поддерживаются в виде файлов формата AS5300.
В образе встроенного программного обеспечения Microcom не содержится сочетание кода встроенного программного обеспече- ния/кода DSP.
Микропрограмма CIP имеет более старую версию, чем версия 22.0
Образы для цифровых модемов Cisco 3640 не поддерживаются в виде файлов формата AS5300.
В образе встроенного программного обеспечения Microcom не содержится сочетание кода встроенного программного обеспече- ния/кода DSP.
Микропрограмма CIP имеет более старую версию, чем версия 22.0
Отправьте эту информацию в центр Cisco ТАС илн в службу технической поддержки вместе с полным описанием возникшей проблемы Средства Software Management переводят задание в аварийное состояние через 1 час после истечения запланированного времени выполнения задания.
Не вносите изменения в задание, если оно приостановлено ("pending"); эта задача возложена на систему. В случае необходимости создайте другое задание Средства Software Management переводят задание в аварийное состояние через 1 час после истечения запланированного времени выполнения задания.
Не вносите изменения в задание, если оно приостановлено ("pending"); эта задача возложена на систему. В случае необходимости создайте другое задание Загрузите с узла ССО поддерживаемую версию программного обеспече- ния/встроенного программного обеспечения.
Для ознакомления с информацией о поддерживаемых устройствах и выпусках программного обеспечения обратитесь к таблице поддерживаемых устройств Supported Device Matrix оперативного справочного руководства
Отправьте эту информацию в центр Cisco ТАС илн в службу технической поддержки вместе с полным описанием возникшей проблемы Средства Software Management переводят задание в аварийное состояние через 1 час после истечения запланированного времени выполнения задания.
Не вносите изменения в задание, если оно приостановлено ("pending"); эта задача возложена на систему. В случае необходимости создайте другое задание Средства Software Management переводят задание в аварийное состояние через 1 час после истечения запланированного времени выполнения задания.
Не вносите изменения в задание, если оно приостановлено ("pending"); эта задача возложена на систему. В случае необходимости создайте другое задание Загрузите с узла ССО поддерживаемую версию программного обеспече- ния/встроенного программного обеспечения.
Для ознакомления с информацией о поддерживаемых устройствах и выпусках программного обеспечения обратитесь к таблице поддерживаемых устройств Supported Device Matrix оперативного справочного руководства
Признак
неисправности/сообщение об ошибке
Причина ошибкиДействия пользователя
Управление программным обеспечением: невозможно запланировать задания по распределению образов Image Import и импорту образов
Не функционирует служба at Если приложение Essentials или конфигурация этойэксплуатируется в системе
службы настроена непра-Window NT, то пройдите по
вильнопунктам меню Control
Panel^Services, чтобы проверить, функционирует ли служба at. Если она не функционирует, запустите ее вручную. Если приложение Essentials эксплуатируется в системе Solaris, проверьте, есть ли в этой системе команда /usr/bin/at.
Проверьте, не содержится ли в файле at.deny каталога /usr/lib/cron имя пользователя bin
Управление программным обеспечением: приложение Essentials не может выгрузить образы из устройства Управление программным обеспечением: функция Mail or Copy Log File не обеспечивает передачу журнала по электронной почте (относится только к системе Windows NT)
Управление программным обеспечением: средства Software Management не распознают платы MICA/Microcom/CIP на устройстве AS5x00 или 7x00
Для приложения EssentialsВведите в конфигурацию
требуется доступ к устройст- устройства определение ву для чтения и записи погруппы устройств чтенияи
протоколу SNMPзаписи
Неправильный адрес эле к-Используйте правильныйад-
тронной почтырес электронной почты в
подменю Mail or Copy Log File
В устройствах эксплуатирует- Для ознакомления с инфор- ся неподдерживаемая версиямацией о поддерживаемых
системного программногоустройствах и выпусках
обеспечения Cisco IOSпрограммного обеспечения
обратитесь к таблице поддерживаемых устройств Supported Device Matrix оперативного справочного руководства
Управление программным обеспечением: для передачи образов программного обеспечения между приложением Essentials и устройствами не используется протокол RCP
Устройство не поддерживает Проверьте, применяется ли в протокол RCP (этот прото- устройстве программное обес- кол поддерживают толькопечение Cisco IOS. Убедитесь в
устройства с программнымтом, что RCP определен как
обеспечением IOS).предпочтительный протокол.
В сервере Essentials не была Проконтролируйте также, что- должным образом выполнена бы была выполнена правиль- настройка конфигурацииная настройка конфигурации с
протокола RCPуказанием имени пользователя
RCP (Admin^System Admins System Configuration).
Признак
неисправности/сообщение об ошибке
Причина ошибкиДействия пользователя
Управление программным обеспечением: появление сообщения "Internal Error: Can't resolve address for proxy" ("Внутренняя ошибка: невозможно преобразовать адрес для прокси-сервера") при вызове функций "Browse Bugs by Device" (“Просмотр ошибок, отсортированных по устройствам") или "Locate Devices by Bugs" (“Поиск устройств, в которых обнаружены конкретные ошибки”)
Если приложение Essentials эксплуатируется на компьютере с операционной системой Windows NT, проверьте, правильно ли функционирует служба CRMrsh на сервере Essentials (для этой проверки используются пункты меню Control Panel^Services). Если эта служба остановлена ("stopped"), запустите ее вручную.
Проверьте журнал событий Event Viewer, чтобы убедиться в том, что запуск службы произошел должным образом. (Обратитесь к приложению Event Viewer из группы Administrative Tools, а затем просмотрите журнал приложения, выбрав команду Log Application.) Если приложение Essentials функционирует в системе Solaris, убедитесь в том, что в исходном каталоге учетной записи пользователя RCP находится файл .rhosts и что в этот файл разрешено выполнять запись пользователю bin
Неправильно выполнена на- Проверьте URL проксистройка прокси-сервера илисервера с помощью пунктов
системы DNSменю Admin^System
Admin=>System Configuration. Если в процессе настройки конфигурации проксисервера применялось имя хоста, проверьте конфигурацию DNS на сервере Essentials.
Убедитесь в том, что настройка конфигурации прокси-сервера не выполнена так, чтобы требовалась регистрация при выполнении каждой операции доступа.
ПризнакПричина ошибкиДействия пользователя
неисправности/сообщение об ошибке
Управление программным обеспечением: по электронной почте не передается отчет Schedule Synchronization Job (относится только к системе Windows NT)Управление программным обеспечением: по электронной почте не передается отчет Schedule Synchronization Job (относится только к системе Windows NT)Неправильный адрес электронной почтыНеправильный адрес электронной почтыЕсли эти действия не позволяют решить проблему, вызовите броузер на выполнение на сервере, где установлено приложение Essentials, настройте конфигурацию прокси-сервера в броузере, а затем проверьте, можно ли получить доступ к узлу www.cisco.comОткорректируйте адрес электронной почты в подменю Schedule Synchronization JobЕсли эти действия не позволяют решить проблему, вызовите броузер на выполнение на сервере, где установлено приложение Essentials, настройте конфигурацию прокси-сервера в броузере, а затем проверьте, можно ли получить доступ к узлу www.cisco.comОткорректируйте адрес электронной почты в подменю Schedule Synchronization Job
Управление программным обеспечением: по электронной почте не передается отчет Schedule Synchronization Job (относится только к системе Windows NT)
Управление программным обеспечением: по электронной почте не передается отчет Schedule Synchronization Job (относится только к системе Windows NT)
Неправильный адрес электронной почты
Неправильный адрес электронной почты
Если эти действия не позволяют решить проблему, вызовите броузер на выполнение на сервере, где установлено приложение Essentials, настройте конфигурацию прокси-сервера в броузере, а затем проверьте, можно ли получить доступ к узлу www.cisco.com
Откорректируйте адрес электронной почты в подменю Schedule Synchronization Job
Если эти действия не позволяют решить проблему, вызовите броузер на выполнение на сервере, где установлено приложение Essentials, настройте конфигурацию прокси-сервера в броузере, а затем проверьте, можно ли получить доступ к узлу www.cisco.com
Откорректируйте адрес электронной почты в подменю Schedule Synchronization Job
Не выполнена настройка конфигурации сервера SMTPНе выполнена настройка конфигурации сервера SMTPУправление программным обеспечением: невозможно загрузить образ Cisco IOS (ошибка 4151)Управление программным обеспечением: экраны ССО Upgrade Analysis и Recommend Image Upgrade (открытые с помощью пун к- та Distribute Images) закрываются по тайм-аутуУправление программным обеспечением: невозможно загрузить образ Cisco IOS (ошибка 4151)Управление программным обеспечением: экраны ССО Upgrade Analysis и Recommend Image Upgrade (открытые с помощью пун к- та Distribute Images) закрываются по тайм-аутуВ файловой системе /var/tmp отсутствует достаточный объем пространства для размещения образов IOS Соединение с узлом ССО, установленное с сервера Essentials, работает медленно. Остановлен серверный компьютер ССО.Не выполнена настройка параметров фильтров ССО с указанием правильных критериевВ файловой системе /var/tmp отсутствует достаточный объем пространства для размещения образов IOS Соединение с узлом ССО, установленное с сервера Essentials, работает медленно. Остановлен серверный компьютер ССО.Не выполнена настройка параметров фильтров ССО с указанием правильных критериевВыполните настройку конфигурации сервера SMTP с помощью пунктов меню Admins System Admin^System ConfigurationУвеличьте объем доступного пространства в файловой системе /var/tmpПри выполнении этих операций требуется доступ к узлу ССО для получения информации об образе программного обеспечения. Убедитесь в том, что сервер ССО исправен и работоспособен. Выберите правильные критерии фильтрации и повторите операцию. Отметьте меньшее количество устройств, чем перед этим, и повторите операцию. Если эти действия не позволяют решить проблему, проверьте конфигурацию проксисервера, как описано в других разделах этой таблицы, касающихся управления программным обеспечениемВыполните настройку конфигурации сервера SMTP с помощью пунктов меню Admins System Admin^System ConfigurationУвеличьте объем доступного пространства в файловой системе /var/tmpПри выполнении этих операций требуется доступ к узлу ССО для получения информации об образе программного обеспечения. Убедитесь в том, что сервер ССО исправен и работоспособен. Выберите правильные критерии фильтрации и повторите операцию. Отметьте меньшее количество устройств, чем перед этим, и повторите операцию. Если эти действия не позволяют решить проблему, проверьте конфигурацию проксисервера, как описано в других разделах этой таблицы, касающихся управления программным обеспечением
Не выполнена настройка конфигурации сервера SMTP
Не выполнена настройка конфигурации сервера SMTP
Управление программным обеспечением: невозможно загрузить образ Cisco IOS (ошибка 4151)
Управление программным обеспечением: экраны ССО Upgrade Analysis и Recommend Image Upgrade (открытые с помощью пун к- та Distribute Images) закрываются по тайм-ауту
Управление программным обеспечением: невозможно загрузить образ Cisco IOS (ошибка 4151)
Управление программным обеспечением: экраны ССО Upgrade Analysis и Recommend Image Upgrade (открытые с помощью пун к- та Distribute Images) закрываются по тайм-ауту
В файловой системе /var/tmp отсутствует достаточный объем пространства для размещения образов IOS Соединение с узлом ССО, установленное с сервера Essentials, работает медленно. Остановлен серверный компьютер ССО.
Не выполнена настройка параметров фильтров ССО с указанием правильных критериев
В файловой системе /var/tmp отсутствует достаточный объем пространства для размещения образов IOS Соединение с узлом ССО, установленное с сервера Essentials, работает медленно. Остановлен серверный компьютер ССО.
Не выполнена настройка параметров фильтров ССО с указанием правильных критериев
Выполните настройку конфигурации сервера SMTP с помощью пунктов меню Admins System Admin^System Configuration
Увеличьте объем доступного пространства в файловой системе /var/tmp
При выполнении этих операций требуется доступ к узлу ССО для получения информации об образе программного обеспечения. Убедитесь в том, что сервер ССО исправен и работоспособен. Выберите правильные критерии фильтрации и повторите операцию. Отметьте меньшее количество устройств, чем перед этим, и повторите операцию. Если эти действия не позволяют решить проблему, проверьте конфигурацию проксисервера, как описано в других разделах этой таблицы, касающихся управления программным обеспечением
Выполните настройку конфигурации сервера SMTP с помощью пунктов меню Admins System Admin^System Configuration
Увеличьте объем доступного пространства в файловой системе /var/tmp
При выполнении этих операций требуется доступ к узлу ССО для получения информации об образе программного обеспечения. Убедитесь в том, что сервер ССО исправен и работоспособен. Выберите правильные критерии фильтрации и повторите операцию. Отметьте меньшее количество устройств, чем перед этим, и повторите операцию. Если эти действия не позволяют решить проблему, проверьте конфигурацию проксисервера, как описано в других разделах этой таблицы, касающихся управления программным обеспечением
Признак
неисправности/сообщение об ошибке
Причина ошибкиДействия пользователя
Управление программным обеспечением: аварийное завершение операции обновления
Средства SoftwareВначале переведите программ-
Management не допускаютное обеспечение устройства на
непосредственного обновле- версию 4.1 (с любым набором ния с переходом от версиисредств), а затем обновите его
4.0 к версии 4.2 Х.25 про-с переходом на версию 4.2
граммного обеспечения вХ.25 образа программного
устройствах ряда Cisco 7000обеспечения
Анализатор системного журнала: фильтры не начинают действовать непосредственно после их корректировки
Фильтры должны начатьЕсли есть необходимость,
действовать примерно через чтобы фильтры немедленно 5 минутвступили в действие, переза
пустите функцию сбора Syslog Analyzer
Анализатор системного журнала: отсутствуют какие-либо сообщения в любом отчете, сформированном по системному журналу
Сетевые устройства не от-Откройте окно Syslog
правляют сообщения на сер- Analyzer Collector Status вер Essentials(Admin^Syslog Analysis1^
Collector Status). Если в этом окне во всех полях стоят нули, проверьте, передают ли сетевые устройства свои сообщения на сервер Essentials. Для ознакомления с информацией о настройке конфигурации устройства Catalyst с операционной системой Cisco IOS обратитесь к оперативному справочному руководству
Анализатор системного журнала: в файле /var/syslog_info отправитель сообщения обозначается как "???" (относится только к системе Solaris)
Обнаруживается ошибка вВведите в систему DNS, в
системе Solaris; демонфайл /etc/hosts или в службу
syslogd не может преобразо- имен информацию, необхо- вать адрес отправителя — се- димую для преобразования тевого устройства, послав-имени этого устройства,
шего это сообщениеЕще один вариант решения
состоит в установке исправления 103291-02 для системы Solaris. В результате вместо строки “???" будет отображаться IP-адрес в квадратных скобках ([171.69.219.72.1.2]). После этого появится возможность провести синтаксический анализ данного формата при выполнении процесса Syslog Analyzer
Признак неисправности/сообщение об ошибке
Причина ошибкиДействия пользователя
Анализатор системного журнала: сообщения системного журнала добавляются в файл /var/log/syslog_info (в системе Solaris) или к файлу c:\Program
Files\CSCOpx\log\syslog.log (в системе Windows NT), но все отчеты Syslog Reports остаются пустыми
Процессы не функциониру- Проверьте, функционирует ют должным образомли процесс Syslog Analyzer
должным образом (Admin*System Admin1* Process Status); если он не функционирует, запустите его. Проверьте, функционируют ли процессы CM Logger, RmeOrb и DBServer; если они не функционируют, перезапустите систему Возникло нарушение в рабо- Если значение счетчика те, связанное с использова- Messages Processed отлично нием тайм-аутаот нуля, проверьте отметки
времени сообщений в файле syslog. Если имеются две отметки времени и вторая отметка является текущей, то процесс Syslog Analyzer использует вторую отметку времени. Если вторая отметка времени отстоит от текущей даты на 7 дней, то соответствующая запись не отображается в отчетах. Если значение счетчика Messages Processed равно нулю, а значение счетчика Messages Filtered не равно нулю, откорректируйте фильтры. Если значения счетчиков Messages Processed и Messages Filtered равны нулю, а значение счетчика Invalid Messages не равно нулю, обратитесь в центр Cisco ТАС или к представителю службы технической поддержки
Анализатор системного журнала: удаленный процесс сбора данных не функционирует должным образом при установке и запуске на компьютере без программного обеспечения Essentials
Неправильные параметрыПроверьте в таблице удален-
конфигурацииного процесса сбора данных
имя и состояние удаленного процесса сбора данных (Admin*Syslog Analysis* Collector Status). Откройте файл SAEnvProperties.ini и проверьте, было ли указано в качестве значения параметра BGSERVER имя хоста сервера Essentials.
Признак
неисправности/сообщение об ошибке
Причина ошибки
Действия пользователя
Анализатор системного жур-
Применяется неправильная
Вызовите на выполнение команду ping с использованием в качестве параметра этого имени хоста, чтобы убедиться в том, что оно может быть преобразовано и доступно с этого компьютера.
В системе Windows NT необходимо также проконтролировать, чтобы параметру PORT было присвоено значение 514 Установите программное
нала: удаленный процесс
версия программного обе с-
обеспечение Java 1.1.5 или
сбора данных — сообщения
печения Java
последующих версий
появляются в файле syslog, но не в отчетах
Остановлен удаленный процесс сбора данных
Инсталляция удаленного процесса сбора данных не была выполнена должным образом
В системе Solaris проверьте функционирование этого процесса с помощью команды /usr/bin/ps -ef | grep java. Перезапустите процесс с помощью команды sh /opt/CSCOsac/lib/sacStart.sh В системе Windows NT для проверки этого воспользуйтесь пунктами меню Control Panel^Services.
Если в списке процессов не указан процесс
Syslog_Collector, переустановите его с использованием команды
SacNTService/install.
Если программное обеспечение процесса сбора данных установлено, но не функционирует, перезапустите удаленный процесс сбора данных с помощью пунктов меню Control Panel^Services. (Необходимо указать файл свойств с использованием опции -рг.)
Признак
неисправности/сообщание об ошибке
Причина ошибки
Дайствия пользователя
Анализатор системного журнала: средства ведения журнала на устройстве Catalyst с программным обеспечением IOS имеют разрешение на передачу сообщений в приложение Essentials, но эта функция не работает
Сообщения, передаваемые сетевыми устройствами на сервер Essentials, записываются в журнал процессом, независимым от процесса Syslog Analyzer.
В системе Solaris таким процессом записи в журнал является syslogd. В системе Windows NT он представляет собой службу ведения системного журнала Essentials. Эта проблема может быть связана с тем, что указанные демоны записи в системный журнал не функционируют должным образом
Подключитесь к сетевому устройству и сформируйте сообщение для записи в системный журнал следующим образом.
Шаг 1. Подключитесь с помощью протокола Telnet к устройству и войдите в систему. Приглашение к вводу команд примет вид host>.
Шаг 2. Введите команду enable и укажите пароль режима enable. Приглашение к вводу команд изменится на host#.
Шаг 3. Введите команду configure terminal. После этого будет выполнен переход в режим конфигурации и приглашение к вводу команд изменится на host (config)#.
Шаг 4. Разрешите запись в журнал, введя команду logging on.
Шаг 5. Укажите IP-адрес сервера Essentials, который должен получать для ввода в системный журнал сообщения с этого маршрутизатора; например, введите logging 123.45.255.90.
Шаг 6. Введите команду end.
ПризнакПричина ошибки
неисправности/сообщение об ошибке
Действия пользователя
Возможно, что настройка конфигурации устройства не была выполнена должным образом
В системе Solaris просмотрите файл, на который указывает строка "local?.info" в файле /etc/syslog.conf (по умолчанию это — файл /var/log/syslog_info). Если этот файл не существует, создайте его и убедитесь в том, что к нему может получить доступ демон syslogd.
В системе Windows NT просмотрите файл C:\Program Files\CSCOpx\log\syslog.log. Отправьте демону syslogd сигнал HUP (kill -HUP 'cat /etc/syslog.pid1).
Если соответствующее сообщение не появилось в системном журнале, убедитесь в том, что демоны записи в системный журнал функционируют должным образом.
В системе Solaris введите команду /usr/ucb/ps -aux | grep syslogd.
В системе Windows NT перейдите в окно Control Panel и убедитесь в том, что служба ведения системного журнала приложения Essentials находится в состоянии "Started"
Убедитесь в том, что для записи устройством сообщений в журнал применяется соответствующий сервер Essentials. (Подробные сведения о том, как разрешить запись сообщений в системный журнал, приведены в документации по операционной системе устройства.)
Признак неисправности/сообщение об ошибке
Причина ошибки
Действия пользователя
Анализатор системного журнала: при использовании удаленного процесса сбора данных в системе Windows NT в журнале событий Windows NT Event Viewer появляется следующее сообщение об ошибке: "Could not start the Syslog Collector service on the server_name. ERROR 0002: The system cannot find the file specified." (“Невозможно выполнить запуск службы Syslog Collector на сервере server_name. Сообщение об ошибке с кодом 0002: в системе не может быть найден указанный файл”) После смены файла сообщений syslog (с помощью команд меню Admin^Syslog Analysis^Change Storage Options) в отчетах не появляются новые сообщения
Анализатор системного журнала: при использовании удаленного устройства сбора данных Windows NT в окне Windows NT Event Viewer отображаются следующие сообщения об ошибках: "Could not start the Syslog Collector service on the server_name. ERROR 1067: The process terminated unexpectedly". (“Невозможно запустить службу Syslog Collector на сервере serverjiame. Сообщение об ошибке с кодом 1067: неожиданное завершение процесса”) "SacNTService: The service cannot be started without the properties file specified, please specify the properties file you want to use"
Во время инсталляции возникла ошибка
Во время настройки конфигурации возникла ошибка
При инсталляции программного обеспечения процесса сбора данных на удаленном компьютере Windows NT применяется команда SacNTService/install (а не SacNTService.exe/install)
После установки службы SacNTService на удаленном устройстве сбора данных Windows NT необходимо выполнить настройку ее конфигурации, выбрав пункты меню Control PaneHServices.
Убедитесь в том, что в поле Startup Parameters содержится информация о местонахождении файла SaenvProperties.ini (например, -pr c:\\temp\\ SaenvProperties.ini)
(Следует учитывать, что в качестве разделителя компонентов полного имени каталога используются символы \\.)
Признак
неисправности/сообщение об ошибке
Причина ошибкиДействия пользователя
(“SacNTService: невозможно выполнить запуск службы без указанного файла свойств, укажите используемый файл свойств”) Анализатор системного журнала: в отчетах не появляются новые сообщения после перехода к использованию другого файла сообщений системного журнала (который определен с помощью пунктов меню Ad- min^Syslog Analysis^Change Storage Options)
Новое имя файла должноВ системе Windows NT вызо-
быть также определено в ин- виге на выполнение редактор формации о конфигурациисистемного реестра Regedit. За
тем перейдите к записи HKEY_LOCAL_SYSTEM\System\Curren tControlSet\Services\cnnlog. В качестве значения поля Parameters укажите имя файла, в который должны записываться сообщения системного журнала.
В системе Solaris внесите изменения в файл /etc/syslog.conf. (Для получения дополнительной информации обратитесь к справочным руководствам по системе Solaris.)
Анализатор системного журнала: ошибка сервера времени выполнения при вызове на выполнение заданий Tasks^Syslog Analyzer
Приложение CMLogger неШаг 1. Войдите в приложение
функционируетEssentials в качестве
пользователя admin.
Шаг 2. Выберите пункты меню Admin^System Admin^Start Processes.
Шаг 3. Запустите систему. Если эта задача все еще завершается аварийно, выберите пункты меню Admins
Т roubleshooting^Proces s Failures для получения списка завершившихся аварийно серверных процессов Essentials.
Шаг 4. Выберите пункты меню Admins Troubleshooting^ Self Test.
Шаг 5. Щелкните на кнопке Create, чтобы сформировать отчет.
Действия пользователяДействия пользователя
Действия пользователя
Действия пользователя
ПризнакПричина ошибки
неисправности/сообщение об ошибке
Анализатор системного журнала: отчет Unexpected Device Report (Tasks^Syslog Analy- sis^Unexpected Device Report) содержит сообщения системного журнала, которые не должны находиться в стандартном отчете Standard Report (Tasks =*Syslog Analy- sis*Standard Report)Анализатор системного журнала: отчет Unexpected Device Report (Tasks^Syslog Analy- sis^Unexpected Device Report) содержит сообщения системного журнала, которые не должны находиться в стандартном отчете Standard Report (Tasks =*Syslog Analy- sis*Standard Report)
Анализатор системного журнала: отчет Unexpected Device Report (Tasks^Syslog Analy- sis^Unexpected Device Report) содержит сообщения системного журнала, которые не должны находиться в стандартном отчете Standard Report (Tasks =*Syslog Analy- sis*Standard Report)
Анализатор системного журнала: отчет Unexpected Device Report (Tasks^Syslog Analy- sis^Unexpected Device Report) содержит сообщения системного журнала, которые не должны находиться в стандартном отчете Standard Report (Tasks =*Syslog Analy- sis*Standard Report)
В стандартном отчете об устройствах Syslog Standard Device Report отображаются сообщения по всем выбранным устройствам за указанную дату. Эти устройства должны находиться под управлением службы учета устройств Essentials. Такая ошибка может возникнуть, если устройство не находится под управлением службы учета устройств Essentials
Если устройство находится под управлением службы учета устройств Essentials, то может иметь место нарушение преобразования имен. (В анализаторе системного журнала используются все IP- адреса, связанные с именем устройства, и осуществляется попытка сопоставить это имя с устройством, управляемым подсистемой Essentials Inventory.)
Шаг 6. Щелкните на кнопке Display, чтобы вывести отчет на экран.
Шаг 7. Выберите пункты меню Admin1* Т roubleshooting^Colle ct Server Info.
Шаг 8. Щелкните на ссылке Product Database Status, чтобы получить подробную информацию о состоянии базы данных
Введите данные об устройстве в состав учетной информации, выбрав пункты меню Admin^lnventory^Add Device. После добавления устройства те сообщения, которые перед этим вошли в состав отчета Unexpected Device Report, не будут переданы в отчет Standard Report, но новые сообщения, относящиеся к данному устройству, будут отображаться в отчете Standard Report
Проверьте преобразование имени устройства в 1Р-адрес, как описано ниже.
Шаг 1. В системе Windows NT просмотрите файл syslog.log в каталоге C:\Program Files \CSCOpx\log. В системе Solaris просмотрите файл syslog_info в каталоге /var/log.
Шаг 2. Определите отправителя сообщений системного журнала, поступивших от этого устройства (на отправителя сообщения указывает имя хоста, которое следует непосредственно за отметкой времени).
Признак неисправности/сообщение об ошибке
Причина ошибки
Дайствия пользователя
Конфигурация системы: ошибка сервера времени выполнения при вызове задачи Admin*System Admin^Device Configuration
Во время эксплуатации системы на устройствах ряда Cisco 7000 отображается ошибка "ТЕТР server on the device timed out” (“Работа сервера TFTP на устройстве завершена по тайм-ауту”)
Приложение CMLogger не функционирует
К клиенту ТЕТР невозможно обратиться с сервера Essentials
Шаг 3. Получите список IP- адресов (выполните преобразование с помощью программы nslookup, указав имя устройства в приглашении ко вводу команд).
Шаг 4. Сформируйте подробный отчет об устройстве (Tasks1* lnventory=*Detailed Device Report) для данного устройства.
Шаг 5. Проверьте столбец Network Address и убедитесь в том, что IP- адреса, возвращенные программой nslookup, находятся в этом списке.
Шаг 6. Если в списке отсутствуют какие-либо IP- адреса, это означает, что настройка конфигурации преобразования имени устройства в IP-адрес выполнена неправильно. Откорректируйте информацию служб имен (DNS, /etc/hosts и т.д.), введя в нее недостающие IP-адреса
Применяются такие же действия, как описано выше в данной таблице, где в качестве возможной причины указано “Приложение CMLogger не функционирует”
Проверьте следующим образом, доступен ли клиент ТЕТР на сервере Essentials: Solaris: /usr/bin/tftp;
Windows NT:
nnt\system32\tftp.exe
Устранение нарушений в работе приложения CWSI Campus
В настоящем разделе рассматривается следующие темы, касающиеся устранения нарушений в работе приложения CWSI Campus.
Общие сведения о фоновых процессах CWSI Campus.
Запуск приложения CWSI Campus.
Способы повышения производительности приложения CWSI Campus.
Правила ввода обозначений групп устройств.
Применение средств обнаружения устройств Cisco.
Формирование отчетов о расхождениях.
Общие сведения о фоновых процессах CWSI Campus
Многие из рассматриваемых здесь методов устранения нарушений в работе требуют понимания принципов функционирования фоновых процессов CWSI Campus. Для ознакомления с информацией об организации фоновых процессов CWSI Campus обратитесь к разделам “Применение команд trace и debug" и “Останов и запуск процессов CWSI Campus”.
Система CWSI Campus включает следующие основные технологические компоненты, позволяющие повысить общую производительность приложения.
Многопотоковый процесс обнаружения устройств, позволяющий определять ■ наличие сетевых устройств и обращаться к информации SNMP и RMON.
Соответствующая машина базы данных, которая обеспечивает высокую производительность доступа и хранения данных, не требуя внешнего администрирования со стороны сетевых операторов.
Объектно-ориентированная технология обеспечения межпроцессной связи между программными компонентами и базами данных.
Эти фоновые процессы описаны в табл. 24.6. Серверными процессами называются процессы, работающие под управлением программного обеспечения CWSI Campus; для клиентских процессов они выглядят как фоновые процессы. Клиентские процессы обеспечивают взаимодействие с пользователем.
Для проверки функционирования этих процессов можно вызвать команду pdshow из любого приглашения к вводу команд. Для этой цели можно также использовать утилиту Task Manager в системе Windows NT или ps (в системах UNIX).
Таблица 24.6. Процессы CWSI Campus
Процесс
ОписаниеТипКомандаКоманда Task
pdshowManager или ps
Process
Manager
Этот диспетчер демонов запускает иdmgtd
контролирует многие процессы CWSI Campus, включая ANI, RTPoller, Event Channel и OSAgent. Process Manager является одним из процессов Essentials, которые контролируют работу системы CWSI Campus
AniServer
ANI представляет собой многопо- Сервер AniServerjre.exe
токовую программу Java. Она устанавливается в качестве демона и функционирует в фоновом режиме, начиная с запуска рабочей станции. Процесс ANI отвечает за обнаружение устройств в сети и обеспечивает всю связь по протоколу SNMP
CWSI Campus Database
Эта машина базы данных отвечает Сервер DbCwsidbeng50
за прием всей информации, кото-(относится(машина базы
рая записывается сервером ANI втолько кданных
базу данных. В процессе функцио-системеEssentials име-
нирования сервер ANI используетUNIX)ет такое же
базу данных только для записи ин-имя> поэтому в
формации, а все необходимые дан-системе должные считывает из оперативной па-но находиться
мяти. База данных хранит введен-два процесса с
ную пользователем информацию иэтим именем)
позволяет серверу ANI быстро загружать его модель данных в память после очередного перезапуска
OSAgent
OSAgent представляет собой агент Сервер RmeOrbosagent
CORBA (Common Object Broker Architecture — общая архитектура брокера объектных запросов), который передает в прямом и обратном направлении сообщения между сервером AniServer и клиентами. Все серверы должны регистрироваться в процессе OsAgent, а все клиенты, которым требуется доступ к определенной службе, находят ее с помощью агента OsAgent. Для регистрации клиента CWSI Campus в процессе OsAgent и для указания того, что выполняется поиск сервера ANI с именем AniServer, применяется окно регистрации CWSI Campus.
OSAgent представляет собой один из процессов Essentials, который контролирует работу системы CWSI Campus
Процесс
ОписаниеТипКомандаКоманда Taak
pdahowManagar или pa
RTPoller
Этот процесс используется прило- Сервер RTPollerjre.exe
жением AtmDirector для периодического опроса сети и получения информации о состоянии устройств и каналов
Event
Channel
Этот процесс передает сообщения о Сервер EventChann jre.exe событиях всем серверам и клиентам,е1
которые в нем зарегистрированы
CWSI Campus Client
Этот процесс обеспечивает загрузку Клиент — полной схемы топологии сети таким образом, чтобы выбор и просмотр информации об устройствах мог выполняться на месте. Он принимает от сервера ANI сообщения о событиях, связанные с изменениями о состоянии сети или указывающие на обнаружение устройств
UserTracking
Этот процесс предоставляет графи- Клиент ——
ческий интерфейс пользователя для приложения UserTracking
VlanDirector Client
Этот процесс предоставляет графи- Клиент ——
ческий интерфейс пользователя для приложения VlanDirector
Topology Client
Этот процесс предоставляет данные Клиент ——
о сетевой топологии и используется в качестве основной отправной точки для других приложений
AtmDirector
Этот процесс подключается к процессу OSAgent и базе данных CWSI Campus для выполнения определенных функций обработки
CiscoView
Этот процесс подключается к про- — цессу OSAgent для обеспечения связи с устройствами, которые входят в схему CWSI Campus и относятся к сфере его действия
TrafficDirector
Процесс TrafficDirector не подключается непосредственно к какому-либо из фоновых процессов. Запуск процесса TrafficDirector может быть выполнен с помощью схемы CWSI Campus
Применение команд trace и debug
На некоторых этапах устранения нарушений в работе может потребоваться разрешить применение команд trace или debug в сервере ANI для сбора дополнительной
информации. После того как вы обратитесь за помощью к представителю центра Cisco ТАС, вам могут также порекомендовать разрешить использование команд trace или debug для конкретных подсистем системы CWSI Campus.
Чтобы разрешить использование команд trace и debug, выполните следующие действия.
Шаг 1. Перейдите в строку приглашения к вводу команд или откройте окно командного интерпретатора.
Шаг 2. Введите команду stopcwsiserver, чтобы остановить процессы сервера CWSI Campus.
Шаг 3. Запустите сервер ANI и разрешите применение команд trace и debug, введя следующую команду:
ani -trace <subsystem* -debug «.subsystem* -logfile «logfile name*
Соответствующее имя подсистемы subsystem может быть приведено в рекомендациях по устранению неисправностей или в ответе представителя ТАС. Здесь также может быть указано любое имя для файла журнала, и этот файл журнала появится в каталоге <CWSIROOT>, где <CWSIROOT> — это каталог, в котором установлена система CWSI Campus.
Шаг 4. Для останова этого процесса нажмите клавиши <Ctrl+C> в приглашении к вводу команд или в окне командного интерпретатора.
Шаг 5. Обратитесь к представителю Cisco ТАС и передайте ему полученный файл журнала.
Останов и запуск процессов CWSI Campus
Для управления процессами системы CWSI Campus применяются следующие сценарии командной строки.
Сценарий stopcwsiserver останавливает демоны CWSI.
Сценарий startcwsiserver запускает демоны CWSI.
Для вызова этих сценариев на выполнение необходимо зарегистрироваться в качестве администратора в системе Windows NT или пользователя root в операционных системах UNIX. Перейдите в строку приглашения к вводу команд или откройте окно командного интерпретатора. Введите команду stopcwsiserver, чтобы остановить серверные процессы CWSI Campus. После останова всех демонов на экране снова появится приглашение к вводу команд. Для перезапуска процессов введите команду startcwsiserver и ожидайте, пока не появится приглашение к вводу команд.
Потеря соединения с подсистемой Eventchannel
Если появится сообщение об ошибке с указанием, что потеряно соединение с подсистемой EventChannel, выполните следующие действия.
Шаг 1. В приглашении к вводу команд или в окне командного интерпретатора введите команду pdshow AniServer, чтобы определить, функционирует ли еще процесс AniServer. Если он уже не функционирует, перейдите к шагу 3.
Шаг 2. Проверьте время запуска и останова, чтобы определить, был ли перезапущен процесс AniServer в то время, когда продолжалось функционирование системы
CWSI Campus. Если останов процесса AniServer произошел без вашего ведома, откройте файл ani.log, чтобы определить причину.
Шаг 3. В приглашении к вводу команд или в окне командного интерпретатора введите команду pdshow Eventchannel, чтобы определить, функционирует ли процесс EventChannel. Если процесс EventChannel не функционирует, перейдите к шагу 5.
Шаг 4. Проверьте время запуска и останова, чтобы определить, был ли перезапущен процесс EventChannel во время функционирования системы CWSI Campus. Если происходит перезапуск процесса AniServer, то состояние процесса EventChannel изменяется и в результате этого разрывается соединение между клиентом CWSI Campus и процессом Event Channel.
Шаг 5. Если не работают ни процесс AniServer, ни процесс EventChannel, выполните следующее.
Выйдите из системы CWSI Campus.
Введите команду startcwsiserver.
Запустите систему CWSI Campus.
Запуск приложения CWSI Campus
Если во время запуска приложений CWSI Campus возникают затруднения, обратитесь к рекомендациям, приведенным в этом разделе.
Если только что был перезапущен компьютер, но пользователь не может зарегистрироваться в приложении <Hostname>AniServer, то, возможно, сервер ANI еще не перешел в состояние готовности к получению сообщении. Необходимо подождать несколько минут, а затем снова попытаться зарегистрироваться.
Если все еще отсутствует возможность зарегистрироваться в системе, обратитесь к предыдущему разделу “Устранение нарушений, возникающих в процессе инсталляции и настройки программ CiscoWorks 2000", в котором подробно описаны этапы процедуры устранения указанного нарушения в работе в системах Windows NT и UNIX.
Выявление поврежденной базы данных
Определить, что база данных повреждена, довольно сложно. В предыдущих версиях системы CWSI Campus об этом можно было догадаться по появлению таких признаков неисправности, как зависание соединения с базой данных или нестабильная работа соединения. Но теперь эти недостатки устранены. В настоящее время единственный способ достоверного определения того, что база данных повреждена, является просмотр файла ani.log. Если в этом файле обнаруживается много исключений и ошибок SQL, это означает, что база данных может быть повреждена.
Замена поврежденной базы данных
Сервер ANI не может эффективно работать, если база данных повреждена. Если установлено, что база данных повреждена, то необходимо инициализировать новую базу данных.
Примечание
Если в приложении UserTracking была введена информация, то при удалении поврежденной базы данных эта информация будет потеряна.
Для замены поврежденной базы данных можно воспользоваться двумя разными методами:
выполнить сценарий;
заменить поврежденную базу данных вручную.
Эти методы рассматриваются ниже.
Выполнение сценария
Если для замены поврежденной базы данных применяется сценарий, то останов всех серверов CWSI Campus выполняется этим сценарием автоматически. После останова машины базы данных сценарий стирает старую базу данных, устанавливает соответствующие права доступа и заменяет старую базу данных пустой, повторно инициализированной базой данных. Затем сценарий автоматически перезапускает серверы CWSI Campus.
Для использования сценария выполните следующие действия.
Шаг 1. Вызовите на выполнение сценарий reinitdb.
В системе Windows NT выберите команду Run в меню Start и введите команду reinitdb.
В системах UNIX зарегистрируйтесь в качестве пользователя root и вызовите на выполнение сценарий reinitdb, находящийся в каталоге <CWSIROOT>/bin.
Шаг 2. Прочитайте информацию, которая появится на экране.
Шаг 3. Нажмите любую клавишу, чтобы начать выполнение сценария, или нажмите клавиши <Ctrl+C>, чтобы выйти из сценария без его выполнения.
Шаг 4. После завершения сценария подождите несколько минут перед запуском системы CWSI Campus, чтобы сначала произошел полный запуск серверов CWSI Campus.
Замена поврежденной базы данных вручную
Заменять поврежденную базу данных вручную нет необходимости, поскольку все требуемые при этом действия сценарий выполняет автоматически. Но данный метод можно использовать, если требуется сохранить копию старой базы данных.
Примечание
Если эксплуатация системы CWSI Campus осуществляется в операционной системе UNIX, то перед заменой базы данных может потребоваться изменить для нее владельца и группу. При копировании файла cwsi_ini.db для него в качестве владельца и группы устанавливаются параметры текущего пользователя. Если эти параметры не откорректированы, то система CWSI Campus не будет функционировать должным образом. Для предотвращения такой ситуации необходимо убедиться в том, что в качестве и владельца, и группы для базы данных указано значение bin.
Для создания новой базы данных выполните следующие действия.
Шаг 1. Вызовите на выполнение сценарий stopcwsiserver.
Шаг 2. Найдите файл текущей базы данных: <CWSIROOT>\db\data\cwsi.db.
Шаг 3. Создайте резервную копию текущей базы данных под другим именем. Например, ее можно назвать cwsiold.db.
Шаг 4. Создайте копию файла cwsi ini.db (который также находится в каталоге data).
Примечание
Не удаляйте и не переименовывайте первоначальный файл cwsi ini.db (который также находится в каталоге data).
Шаг 5. Переименуйте копию файла cwsi_ini.db в cwsi.db. Этот файл будет представлять собой новый файл базы данных.
Шаг 6. Удалите файл cwsi.log.
Шаг 7. Вызовите на выполнение сценарий startcwsiserver.
Применение одной и той же базы данных на нескольких рабочих станциях
Возможность установить систему CWSI Campus на нескольких рабочих станциях и предоставить им совместный доступ к одной и той же базе данных отсутствует. Кроме того, если в сети должно быть установлено несколько экземпляров системы CWSI Campus, то для каждого экземпляра необходимо использовать отдельную копию сервера AniServer с другим именем.
Применение нескольких экземпляров системы CWSI Campus
Чтобы использовать в одной сети несколько экземпляров системы CWSI Campus, необходимо знать, как в такой среде функционирует процесс обнаружения устройств системы CWSI Campus. В процессе обнаружения устройств применяется программа ANI, которая функционирует как серверный процесс и обменивается информацией с другими приложениями CWSI Campus, работающими как клиенты. Каждый сервер AniServer предназначен для управления одним доменом. Поэтому, если в сети установлен еще один экземпляр системы CWSI Campus, конфигурация которого настроена на использование сервера ANI с таким же именем (по умолчанию AniServer), то поведение системы становится непредсказуемым, поскольку невозможно определить заранее, какой сервер AniServer будет выбран клиентом в качестве сервера, применяемого по умолчанию.
В зависимости от системных ресурсов, доступных для первоначальной системы CWSI Campus, применение клиентами не соответствующих им серверов AniServer может привести к снижению производительности всех систем CWSI Campus, которые обращаются к применяемому по умолчанию серверу AniServer и используют его ресурсы.
Если необходимо установить еще один экземпляр системы CWSI Campus для управления другим доменом, то необходимо выполнить настройку конфигурации этих экземпляров вручную, чтобы в них эксплуатировались разные процессы AniServer.
Для настройки конфигурации экземпляров системы выполните следующие действия. Шаг 1. Закройте все приложения CWSI Campus.
Шаг 2. Вызовите на выполнение сценарий stopcwsiserver.
Шаг 3. Найдите и откройте файл ani.properties с помощью текстового редактора.
Файл ani.propert es находится в каталоге <CWSIROOT>/etc/cwsi/.
Шаг 4. Откорректируйте следующую строку, чтобы присвоить другое имя процессу AniServer, работающему на локальной рабочей станции: AniName = AniServer_Name
Например, если установлена версия системы CWSI Campus для операционной системы Solaris, то можно переименовать AniServer в SOLAniServer.
Шаг 5. После внесения этих изменений сохраните файл и закройте текстовый редактор.
Шаг 6. Вызовите на выполнение сценарий startcwsiserver.
Способы повышения производительности приложения CWSI Campus
Основным способом повышения производительности системы CWSI Campus является сокращение объема ресурсов, потребляемых рабочей станцией CWSI Campus. Чтобы сократить потребление системой CWSI Campus ресурсов процессора, выполните следующие действия.
Шаг 1. Уменьшите количество потоков (подпроцессов) обнаружения устройств. Такое действие позволяет уменьшить затраты процессорного времени на обнаружение устройств, но сам процесс при этом становится более продолжительным. Чтобы изменить количество потоков обнаружения устройств, выполните следующие действия.
Примечание
Функционирование сервера ANI и клиентов CWSI Campus зависит от параметров в файле ani. proper ties. Функционирование приложения CWSI Campus может быть нарушено, если этот файл свойств содержит хотя бы одну неправильную запись. Тщательно соблюдайте инструкции и не пытайтесь редактировать другую информацию.
Вызовите на выполнение сценарий stopcwsiserver.
Найдите файл ani.properties в каталоге CWSI.
Найдите следующую строку:
Discovery.threads=l2
Откорректируйте эту строку так, чтобы она выглядела следующим образом: Discovery.threads=5
Вызовите на выполнение сценарий startcwsiserver.
Шаг 2. В приложении UserTracking увеличьте параметры формирования временных графиков VMPSMajor и VMPSMinor.
Шаг 3. Увеличьте интервал планирования времени обнаружения устройств.
Шаг 4. Откорректируйте интервал планирования времени обнаружения устройств таким образом, чтобы он был постоянным (например, один раз в сутки, два раза в сутки и т.д.), в зависимости от того, насколько своевременной должна быть полученная информация.
Шаг 5. Выполните настройку системы для достижения высокой производительности.
Установите достаточный объем оперативной памяти для того, чтобы на компьютере можно было одновременно эксплуатировать систему CWSI Campus и все другие программы. Следует избегать применения средств подкачки.
Обеспечьте создание быстрого сетевого соединения; его скорость должна быть не ниже 10 Мбит/с в разделяемой передающей среде.
При использовании системы Windows NT установите диски SCSI с интерфейсом Ultra-Fast Wide. Кроме того, если есть такая возможность, поместите файл подкачки в отдельный раздел или следите за тем, чтобы он оставался нефраг- ментированным.
Правила ввода обозначений групп устройств
Для того чтобы система CWSI Campus могла применяться для настройки конфигурации устройств в сети, необходимо обеспечить ввод правильных обозначений групп устройств. В настоящем разделе приведены рекомендации по устранению нарушений в работе, с которыми можно столкнуться при выполнении этой операции.
Правила ввода определений групп устройств
При вводе определений групп устройств необходимо руководствоваться конкретными правилами и уметь различать правильно и неправильно введенные определения (см. листинги 24.1 и 24.2).
| Листинг 24.1. Неправильно заданные определения группы устройств ;
*:subl::::::subl:
*:sub2::::::sub2:
|;Листинг 24,2. Правильно заданные определения группы устройств
*.*.*.*:subl::::::subl:
*:sub2::::::sub2:
В листинге 24.1 определение является неправильным, поскольку одному и тому же вложенному адресу присвоены разные определения групп устройств. В данном случае может возникнуть такая ситуация, что система CWSI Campus перекроет первую запись второй. Но возможны также и непредсказуемые результаты.
В листинге 24.2 приведено правильное определение, поскольку в нем адрес 172.26.1.* является вложенным по отношению к адресу *.*.*.*,
Результаты ввода неправильного определения группы устройств записи
Если случайно введено неправильное определение группы устройств записи, то возможность выполнять обнаружение устройств в сети все еще сохраняется (при условии, что введено правильное определение группы устройств, допускающих только чтение). Но выполнение каких-либо операций записи остается невозможным до тех порт, пока не введено правильное определение группы устройств чтения и записи.
Применение средств обнаружения устройств Cisco
Если при интерпретации результатов обнаружения устройств в сети возникают сложности, то при решении наиболее часто возникающих проблем руководствуйтесь рекомендациями, приведенными в этом разделе.
Причины отображения на схеме сети каналов в виде штриховых линий
Если на схеме сети какой-либо канал между устройствами обозначен штриховой линией, это означает, что во время последнего периода активизации процессов обнаружения устройств система CWSI Campus не имела возможности выполнить процедуру полного обнаружения одного из устройств на том или ином конце канала. Такая ситуация может возникнуть, если канал по какой-либо причине был неработоспособен, например, на время удален из сети.
Наиболее вероятная причина появления таких штриховых линий состоит в применении тайм-аутов SNMP. Как правило, для операционной системы устройства Cisco процесс SNMP имеет самый низкий приоритет среди всех фоновых процессов. Например, на работе SNMP может отрицательно сказаться то, что в период активизации процессов обнаружения устройств происходит создание новой виртуальной локальной сети, поскольку повторно формируется распределенное связующее дерево, а этот процесс имеет приоритет над процессом SNMP.
Для каждого отдельного устройства может быть увеличен тайм-аут SNMP. Для увеличения значения тайм-аута выполните следующие действия.
Шаг 1. Выберите команды Edit^SNMP Communities в окне со схемой CWSI Campus.
Шаг 2. Введите строку определения группы устройств с использованием следующей синтаксической структуры:
target:read:UNUSED:timeout:retries:UNUSED:UNUSED:write:
По умолчанию тайм-аут составляет 3 секунды.
Шаг 3. Если для настройки конфигурации каждого отдельного устройства применяются разные определения групп устройств, вводите определение для каждого устройства на отдельной строке.
Любые изменения, внесенные в определения групп устройств, немедленно вступают в силу.
Причины появления на схеме устройств, отмеченных красным значком X
Устройства, обозначенные на схеме красным значком X, не были правильно обнаружены. Для того чтобы любое устройство могло быть обнаружено системой CWSI Campus, должны соблюдаться следующие критерии.
В системе CWSI Campus должны быть правильно заданы определения групп устройств SNMP.
Должна существовать возможность выполнить эхо-тестирование устройства.
Устройство должно функционировать как сервер SNMP.
Должна существовать возможность получить доступ к устройству по протоколу CDP или через интерфейс ILMI с соседних устройств.
Должна существовать возможность получить доступ с устройства к его соседним устройствам по протоколу CDP или через интерфейс ILMI.
Если в устройстве имеется список разрешений permit, то в него должен быть включен IP-адрес рабочей станции управления сетью.
Версия программного обеспечения, эксплуатируемая на устройстве, должна поддерживать протокол CDP или интерфейс ILMI.
Причины появления на схеме сети устройств, обозначенных пустым прямоугольником с красным значком X
Если на схеме сети появляются устройства, обозначенные пустым прямоугольником с красным значком X, это означает, что устройство доступно, но его тип неизвестен в системе CWSI Campus. Такой пиктограммой обычно обозначаются устройства, отличные от выпускаемых корпорацией Cisco. Она может также отображаться при обнаружении устройства Cisco нового типа, которое было выпущено позже текущей версии системы CWSI Campus.
Причины продолжительного выполнения операции обнаружения устройства
Продолжительность выполнения операции обнаружения устройства зависит от многих факторов, таких как:
количество недостижимых устройств;
количество считываемых объектов LANE;
количество потоков, распределенных в процессе обнаружения устройств.
Если операция обнаружения устройств занимает слишком много времени, выполните следующие действия.
Шаг 1. Ограничьтесь обнаружением устройств только в тех доменах УТР, которыми необходимо управлять.
Шаг 2. Убедитесь в том, что для всех устройств правильно введены строки определения групп устройств.
Шаг 3. Увеличьте количество потоков, применяемых для обнаружения устройств, если есть необходимость обеспечить обнаружение большого количества устройств. По умолчанию в системе CWSI Campus для обнаружения устройств распределяется 12 потоков. Если в сети имеется много недостижимых устройств или устройств с низким быстродействием, то они могут исчерпать весь пул потоков и замедлить процесс обнаружения других устройств.
Шаг 4. Чтобы уменьшить или увеличить количество потоков обнаружения, выполните следующие действия.
Примечание
Работа сервера ANI и клиентов CWSI Campus зависит от информации в файле ani.properties. Функционирование приложения CWSI Campus может быть нарушено при наличии в этом файле свойств даже единственной неправильной записи. Тщательно выполняйте инструкции и не пытайтесь редактировать другую информацию.
Вызовите на выполнение сценарий stopcwsiserver.
Найдите файл ani.properties в каталоге CWSI.
Найдите следующую строку:
Discovery.threads=12
Измените строку так, чтобы она выглядела следующим образом: Discovery.threads=60
Вызовите на выполнение сценарий startcwsiserver.
Способы отмены функции обнаружения устройств
Невозможно полностью отменить функции обнаружения устройств. Дело в том, что функционирование системы CWSI Campus основано на использовании модели данных, полученных в реальном времени, которая базируется на результатах обнаружения устройств.
Единственная возможность состоит в использовании такого крайне продолжительного интервала обнаружения устройств, чтобы этот процесс происходил только при запуске сервера ANI или при проведении операции обнаружения устройств в сети вручную.
Способы удаления устройств
Если система CWSI Campus обнаружила устройство, которое не должно отображаться на схеме сети, то это устройство нельзя удалить из схемы. Для решения такой проблемы воспользуйтесь следующими рекомендациями.
Удалите со схемы каналы к устройству и перетащите пиктограмму устройства в удаленную часть схемы таким образом, чтобы она не была видна в главном окне схемы.
Такой вариант является вполне приемлемым, если в сети есть устройство, которое не должно быть показано на схеме CWSI Campus.
Замените базу данных CWSI Campus и активизируйте процесс первоначального обнаружения устройств.
Такой вариант в наибольшей степени подходит для тех ситуаций, если на схеме имеются ошибочно обнаруженные устройства, которых фактически нет в сети, или со времени первоначального обнаружения из сети физически удалено какое-то устройство.
Причины отображения сети ATM в виде облака
Если система CWSI Campus не может правильно интерпретировать информацию о каналах ATM, то на схеме сети сеть ATM отображается в виде так называемого облака ATM. Ниже описаны возможные причины этой проблемы и соответствующие решения.
В данной сети ATM не активизировано программное обеспечение интерфейса ILMI.
Убедитесь в том, что программное обеспечение интерфейса ILMI активизировано на всех устройствах ATM в сети.
Не была выполнена должным образом настройка конфигурации, предусмотренной по умолчанию в сети ATM-VLAN.
В качестве исходной точки в процессе обнаружения устройств не используется одно из устройств ATM.
Программное обеспечение интерфейса ILMI не возвращает правильную информацию об IP-адресах.
Программное обеспечение интерфейса ILMI не вносит автоматически обновления при изменении IP-адресов. Выполните сброс АТМ-коммутатора LightStream 1010, чтобы очистить таблицу ILMI.
Записи ILMI в устройствах, находящихся на разных концах любого конкретного канала ATM, не являются актуальными.
Убедитесь в том, что все записи ILMI являются актуальными и содержат непротиворечивую информацию.
В модулях LANE применяются устаревшие версии образов программного обеспечения.
Если в каком-либо устройстве имеется один или несколько модулей LANE и в них эксплуатируются версии образов программного обеспечения с версией, предшествующей 3.2(7) или 11.3(3a)WA4(5), то обнаружение устройств в сети ATM не выполняется должным образом. Используйте версии образов программного обеспечения 3.2(7), 11.3(3a)WA4(6) или последующие версии.
Причины отсутствия обозначений скорости на некоторых каналах Ethernet
При обработке некоторых устройств (как правило, неизвестного типа) система CWSI Campus может выполнить только выборку таблицы передающей среды из таблицы IF, введенной согласно RFC 1213 (MIB ifType). В таких случаях соответствующий канал отображается как канал Ethernet. Но при обработке большинства устройств система CWSI Campus считывает базы MIB с информацией о конфигурации, введенной на данном конкретном предприятии, которая содержит более подробную информацию о типе порта. Поэтому на схеме сети отображается обозначение скорости 10 Мбит/с или 100 Мбит/с.
Причины появления неправильно обнаруженных устройств или соединений
Убедитесь в том, что в маршрутизаторах сети не задано одинаковое значение параметра sysName. Маршрутизаторы анонсируют значение параметра sysName для его использования в качестве идентификатора соответствующего им кэша CDP, а в системе CWSI Campus для обнаружения устройств применяется информация CDP. Поэтому, если в сети имеются два или несколько устройств с одинаковыми параметрами sysName, то результаты, полученные системой CWSI Campus, могут оказаться непредсказуемыми.
Ддя проверки того, не было ли обнаружено большое количество устройств с одинаковыми идентификаторами, которые были распознаны и отвергнуты как дубликаты, можно также просмотреть журнал системы.
Причины появления некоторых устройств неизвестного типа с указанием OID в качестве имени устройства
Устройства, не поддерживаемые системой CWSI Campus, обозначены на схеме не именем устройства, а идентификатором объекта (OID — Object Identifier). Система CWSI Campus предпринимает попытку преобразовать такой OID в строку MIB в иерархической схеме классификации продуктов Cisco. Если соответствующий OID относится к иерархической схеме классификации CiscoProducts или к схеме рабочих групп, то вместо него отображается имя устройства.
Причины, по которым не обнаруживаются каналы СОР сети Frame Relay
Некоторые каналы CDP сети Frame Relay могут не обнаруживаться системой CWSI Campus, даже несмотря на то, что подключенные к ним устройства можно обнаружить, вызвав на выполнение команду show cdp с помощью интерфейса командной строки. Это вызвано ошибкой в программном обеспечении IOS, из-за которой многоточечные каналы распределенной сети Frame Relay не появляются в списке соседних устройств CDP протокола SNMP, даже если их можно обнаружить с помощью команд интерфейса командной строки.
Формирование отчетов о расхождениях
Отчеты о расхождениях позволяют обнаружить несоответствия в конфигурации сети. В настоящем разделе приведены основные рекомендации по использованию отчетов о расхождениях. Для формирования и вывода отчетов об обнаруженных несоответствиях в схеме сети выполните следующие действия.
Шаг 1. В окне CWSI Campus Мар выберите команды Reports^Discrepancies.
Откроется окно Discrepancy.
Шаг 2. Для вывода отчета о расхождениях выберите команды File^Export.
Отчет сохраняется в виде файла. Его можно напечатать из программы, в которой он был сохранен.
Интерпретация отчета о расхождениях
В отчете о расхождениях отображается информация о несоответствиях или противоречивых данных о конкретной сети.
В табл. 24.7 показано, каким образом такие несоответствия могут быть отображены в полученном отчете.
При интерпретации отчета о несоответствиях следует учитывать, что в системе как несоответствующие стандартным требованиям могут рассматриваться конфигурации, настройка которых в таком виде была выполнена намеренно. Если известно, что настройка конфигурации сети должна быть выполнена именно так, то не следует придавать слишком большого значения обнаруженным несоответствиям.
Обнаруженное несоответствие
Описвние
Несоответствие виртуальных локальных сетей в магистральном канале Несоответствие собственных виртуальных локальных сетей
На разных концах магистрального канала указаны различные виртуальные локальные сети
На разных концах одного канала виртуальной локальной сети указаны различные виртуальные локальные сети (определены различные собственные виртуальные локальные сети)
Несовпадение имен виртуальных локальных сетей
Несовпадение индексов виртуальных локальных сетей
Несовпадение индексов SAID виртуальной локальной сети
Виртуальные локальные сети с разными номерами ISL имеют одно и то же имя в различных доменах Виртуальные локальные сети с разными именами имеют один и тот же номер ISL в различных доменах Для одной и той же виртуальной локальной сети в различных доменах заданы разные идентификаторы в системе зашиты (SAID — Security Association ID)
Отсутствует ATM-адрес сервера конфигурации LANE
Неправильное согласование адресов клиента LANE в виртуальной локальной сети и сети ATM-VLAN
Клиент LANE не привязан к сети ATM-VLAN
Широковещательный сервер LANE не привязан к сети ATM-VLAN Несоответствие значений режима передачи в канале
Несоответствие значений скорости в канале
В коммутаторе ATM не обнаружены ATM-адреса LANE
Сеть ATM-VLAN согласована с виртуальной локальной сетью, имеющей другое имя
Для клиента LANE не указаны сети ATM-VLAN, к которым он относится
Для широковещательного сервера LANE не указаны сети ATM-VLAN, к которым он относится
В устройстве на одном конце канала установлен дуплексный режим передачи, а на другом конце — полудуплексный
В устройстве на одном конце канала установлено одно значение скорости, а на другом конце — другое (для портов на 10/100 Мбит/с или для любой группы каналов)
Несоответствие протоколов магистральных каналов виртуальной локальной сети
Несоответствие режимов поддержки магистрального канала
В одном и том же магистральном канале применяются разные средства инкапсуляции протокола (и ISL, и 802.1q)
В портах устройств на разных концах физического канала применяются разные режимы поддержки магистрального канала
Разъединенный домен VTP
Конфигурация одного из каналов в домене VTP не настроена на использование средств формирования магистрального канала. В этом домене есть устройства, с которыми отсутствует связь через какой-либо магистральный канал
В домене отсутствует сервер VTP
В порту EtherChannel не отменено применение алгоритма распределенного связующего дерева
В этом домене нет ни одного сервера VTP
Алгоритм распределенного связующего дерева не поддерживается в версии 2.3 программного обеспечения коммутатора Catalyst и в предыдущих версиях, поэтому необходимо отменить его применение в коммутаторах с активными виртуальными локальными сетями, каналы которых проходят через соединения Fast EtherChannel. Для программного обеспечения Catalyst 3.1 и последующих версий настройку конфигурации каналов Fast EtherChannel можно выполнить с учетом возможности применения алгоритма распределенного связующего дерева
Настройка параметров отчета о расхождениях
Настройка параметров отчета о расхождениях может быть выполнена таким образом, чтобы в нем отображались только те несоответствия, о которых вам необходимо знать.
Шаг 1. В окне CWSI Campus Мар выберите команды Options=i>Properties. Откроется окно CWSI Properties.
Шаг 2. В окне Properties выберите команду Discrepancy. На экране появится список несоответствий.
Шаг 3. Выберите только те несоответствия, которые необходимо включить в отчет.
Информация по устранению нарушений в работе приложений CWSI Campus
В данном разделе рассматриваются следующие темы:
Устранение нарушений в работе приложения VlanDirector.
Устранение нарушений в работе приложения AtmDirector.
Устранение нарушений в работе приложения TrafficDirector.
Устранение нарушений в работе приложения CiscoView.
Устранение нарушений в работе приложения VlanDirector
В настоящем разделе приведены рекомендации по устранению нарушений в работе приложения VlanDirector.
Необходимость разрешить применение протокола УТР
Корпорация Cisco рекомендует для получения наиболее предсказуемых результатов выполнить настройку конфигурации хотя бы одного коммутатора в качестве сервера УТР, а остальные коммутаторы настроить в качестве клиентов УТР.
Определение сервера УТР, в конфигурацию которого будут внесены изменения с помощью приложения VlanDirector, если в домене УТР имеется несколько серверов УТР
Если в одном и том же домене имеются два сервера УТР, которые соединены магистральными каналами УТР, то не имеет значения, на каком коммутаторе будут внесены изменения с помощью приложения VlanDirector. Протокол VTP гарантирует, что информация на всех серверах и клиентах VTP в одном домене VTP остается скоординированной и все они будут использовать одну и ту же конфигурацию.
Если же серверы находятся в разных доменах УТР, то для них не определяются одинаковые состояния виртуальной локальной сети, но они остаются известными для приложения VlanDirector. Поэтому необходимо выбрать домен VTP, в котором будут внесены изменения параметров виртуальной локальной сети, и соответствующие серверы VTP будут отображать эти изменения.
Если же в сети имеются два сервера, которые не соединены магистральными каналами, но обозначены как принадлежащие к одному и тому же домену VTP, то кон-
фигурации, управляемые этими двумя серверами, могут отличаться друг от друга. Такая структура сети не поддерживается приложением VlanDirector и может стать причиной расхождений.
Наличие в разных доменах VTP виртуальных локальных сетей с одинаковыми именами
В разных доменах УТР могут быть определены виртуальные локальные сети с одинаковыми именами, при том условии, что они будут также иметь другие одинаковые характеристики, такие как индекс виртуальной локальной сети и значение идентификатора SAID. Расхождения возникают, если в сети имеются одинаково названные виртуальные локальные сети, другие атрибуты которых (такие как индекс и т.д.) являются разными. Если две разные виртуальные локальные сети имеют полностью одинаковые определения, то расхождения не обнаруживаются.
Возможность перетаскивания портов прозрачных коммутаторов VTP, находящихся в прозрачном режиме, из одной виртуальной локальной сети в другую
Попытка перетащить порт в другую виртуальную локальную сеть может оказаться успешной или окончиться неудачей, в зависимости от того, как определена данная конкретная виртуальная локальная сеть и на сервере УТР, и в данном коммутаторе, находящемся в прозрачном режиме. Если эти определения идентичны (включая имя, индекс виртуальной локальной сети и т.д.), то процесс перетаскивания вполне может завершиться успешно. Но если эти определения не идентичны, то результаты нельзя предсказать заранее, т.е. исход этого процесса является неопределенным. Поэтому для введения коммутаторов УТР, находящих в прозрачном режиме, в те же виртуальные локальные сети, которые работают под управлением сервера УТР, необходимо обеспечить единообразие определений виртуальных локальных сетей.
Возможность отображения в приложении VlanDirector информации о виртуальной локальной сети, которая относится к коммутатору, находящемуся в прозрачном режиме
Приложение VlanDirector не обнаруживает какие-либо виртуальные локальные сети, конфигурация которых определена в коммутаторе, работающем в режиме прозрачного перенаправления. Поэтому если состояние виртуальной локальной сети в коммутаторе, находящемся в прозрачном режиме, отличается от того состояния, о котором сообщает сервер, находящийся в том же домене, то приложение VlanDirector не может должным образом отрабатывать изменения в виртуальной локальной сети, которая определена в коммутаторе, находящемся в прозрачном режиме.
Причины подсветки пиктограммы коммутатора при выборе любой виртуальной локальной сети
Если во время работы в приложении VlanDirector отмечается как выбранная какая- либо виртуальная локальная сеть, то на схеме в окне CWSI Campus подсвечивается пиктограмма коммутатора, относящегося к этой виртуальной локальной сети. На схеме CWSI Campus можно также подсветить пиктограмму коммутатора, чтобы узнать, какие виртуальные локальные сети развернуты на этом коммутаторе. Но если с этим коммута-
тором связаны магистральные каналы, которые несут трафик всех виртуальных локальных сетей, то подсветка пиктограммы коммутатора выполняется в любом случае, независимо от того, какая виртуальная локальная сеть отмечается как выбранная.
Причины появления изображения молнии на пиктограмме порта
Появление изображения молнии на пиктограмме порта означает, что этот порт входит в состав канала (либо канала от устройства к устройству, либо соединения с разделяемой передающей средой).
Изображение молнии служит для обозначения различия между портом, подключенным к другому коммутатору (входящему в состав канала), и портом, конфигурация которого настроена на применение в качестве пользовательского порта. Программным обеспечением протокола CDP исходя из этого порта было обнаружено одноранговое устройство CDP.
Изображение молнии указывает, что в процессе корректировки конфигурации виртуальной локальной сети нельзя отдельно изменять параметры этого порта; его конфигурацию необходимо корректировать в составе конфигурации соответствующего канала. Для этого можно выбрать канал на схеме CWSI Campus и перетащить его в соответствующую виртуальную локальную сеть.
Настройка конфигурации служб LANE
Приложение VlanDirector позволяет выполнить настройку конфигурации служб LANE. В табл. 24.8—24.11 представлена подробная информация по устранению нарушений в работе в процессе решения проблем настройки конфигурации LANE.
[таблица 24.8. В окне имен приложения VlanDirector отсутствуют Iопределения сетей ATM-VLAN.
Возможная причина Предлагаемое решение
В устройствах отсутствуют необходимые версии программного обеспечения
Убедитесь в том, что во всех устройствах эксплуатируются образы программного обеспечения с версиями, необходимыми для служб LANE. Информация о правильных версиях образов программного обеспечения для применяемых устройств приведена в примечаниях к выпуску CWSI Campus
В системе CWS1 Campus были введены неправильные определения групп устройств чтения
Проверьте, соответствуют ли определения групп устройств SNMP, введенные в систему CWSI Campus, фактическим определениям для всех устройств, для которых была выполнена настройка конфигурации компонентов LANE.
Для проверки определений групп устройств выберите команды Edit^SNMP Communities в окне CWSI Campus. Для ознакомления с подробными инструкциями по вводу определений групп устройств обратитесь к разделу Preparing for Network Discovery документа Getting Started with CWSI Campus
Между устройствами LANE отсутствует связь по протоколу
Убедитесь в том, что ко всем устройствам LANE может быть получен доступ по протоколу SNMP
SNMP
Возможная причина
Предлагаемое решение
При работе с устройствами возникают тайм-ауты SNMP
Проверьте схему CWSI Campus, чтобы определить, нет ли в ней устройств, обозначенных красным значком X.
Увеличьте установку тайм-аута SNMP для таких устройств и снова выполните процесс обнаружения устройств или всей сети.
Для увеличения тайм-аута выберите команды Edit^SNMP Communities в окне CWSI Campus. Подробные инструкции по увеличению тайм-аута SNMP приведены в разделе Preparing for Network Discovery документа Getting Started with CWSI Campus
Серверы LANE, эксплуатируемые в устройствах, не имеют достаточного объема памяти
Невозможно провести процесс обнаружения серверов конфигураций
Если сервер конфигураций развернут в коммутаторе ряда Catalyst 5000, убедитесь в том, что это устройство имеет объем памяти не меньше 16 Мбайт "
Проверьте, был ли обнаружен ведущий сервер конфигураций, выбрав команды Edit^Conflgure Config Server в окне VlanDlrector Names.
Корпорация Cisco не рекомендует использовать больше одного ведущего сервера конфигураций в составе коммутационной структуры ATM. Если имеется несколько ведущих серверов конфигураций, то система CWSI Campus выбирает случайным образом для использования при обнаружении устройств только один из них, а остальные серверы игнорируются
Невозможно выполнить процесс обнаружения серверов LE
В каждой сети ATM-VLAN должен быть хотя бы один активный сервер LE.
База данных сервера конфигураций должна отражать сложившуюся на данный момент иерархию серверов LE.
Для проверки базы данных сервера конфигураций применяется интерфейс командной строки. Содержимое исправной базы данных сервера конфигураций должно выглядеть примерно так:
at-5000-4atml# sh lane database
LANE Config Server database table 'cwsiLecsDb' no default elan
elan 'vlanElanTest': un-restricted server
47.00918100000000603E899701.00E01431A421.01
(prio 0)
LANE Config Server database table
'lecsdb_57_87.3' bound to interface/s: ATMO
default elan: default
elan 'default': un-restricted server
47.00918100000000603E899701.00E01431A421.01
(prio 0) active
elan 'vlan9': un-restricted server
47.00918100000000603E899701.00E01431A421.09
(prio 0) active
Возможная причина
Предлагаемое решение
Возможно, что сеть ATM-VLAN соответствует сети VTP VLAN с другим именем
Сеть VTP VLAN, которой соответствует некоторая сеть ATM-VLAN, представлена в папке VTP Domain окна приложения VlanDirector как одна запись с изображенной рядом с ней пиктограммой сетевой среды ATM. Например, если сеть VTP VLAN с именем X соответствует сети ATM-VLAN с именем Y, эти две сети представлены в папке VTP Domain в виде одной записи, обозначенной именем X с пиктограммой сетевой среды ATM рядом с ней. Имя У больше нигде не появляется
Описанные выше рекомендации не позволяют устранить проблему
Вызовите на выполнение следующую команду, чтобы разрешить применение команд trace и debug:
ani -trace frontend -debug vlad -debug lane -debug ilmi -trace pnni
-debug vmpsadmin -trace devices -debug devices.C5K -debug
devices.C5K.C5500 -debug devices.LSlOlO -debug devices.Router -debug
devices.C3K -debug devices.C2800 -logfile ani.log
Таблица 24.9. Неправильно определенное или неопределенное , ■, . ,
Возможная причина
Предлагаемое решение
Здесь рассматривается такая же возможная причина, как и в строках 1-4 табл. 24.7 Не существуют клиенты LANE для сети ATM-VLAN
Ознакомьтесь с соответствующими решениями, приведенными в тех же строках табл. 24.7
Выполните настройку конфигурации клиентов LANE для соответствующих сетей ATM-VLAN.
Дополнительная информация представлена в разделе Configuring and Monitoring LANE Services документа Getting Started with CWSI Campus.
Ознакомьтесь с руководством по настройке конфигурации программного обеспечения для конкретного устройства
Клиенты LANE существуют, но обнаружение их не происходит Серверы LANE развернуты на устройствах, не имеющих достаточного объема памяти
Не происходит процесс обнаружения устройств после настройки конфигурации виртуальных локальных сетей с разрешенными службами LANE
Убедитесь в том, что процесс обнаружения устройств не завершается по тайм-ауту
Если сервер конфигурации установлен в коммутаторе ряда Catalyst 5000, убедитесь в том, что это устройство имеет объем памяти не меньше 16 Мбайт
Шаг 1. В окне CWSI Campus Мар выберите команды View=> Rediscover Map.
Шаг 2. Вызовите на выполнение приложение VlanDirector, выбрав Команды Tools^VlanDirector в окне CWSI Campus Мар.
Шаг 3. В окне VlanDirector Names выберите команды File^Refresh.
Для ознакомления с дополнительной информацией обратитесь к документу Using the Campus VlanDirector Application
Возможная причина
Предлагаемое решение
Описанные выше рекомендации не позволяют устранить проблему
Вызовите на выполнение следующую команду, чтобы разрешить применение команд trace и debug:
ani -trace frontend -debug vlad -debug lane -debug ilmi -trace pnni
-debug vmpsadmin -trace devices -debug devices.C5K -debug
devices.C5K.C5500 -debug devices.LS1010 -debug devices.Router -debug
devices.C3K -debug devices.C2800 -logfile ani.log
I Таблица 24.10. Отсутствие возможности создать или модифицировать Iвиртуальную локальную сеть с разрешенными
1 службами LANE• v
Возможная причина
Предлагаемое решение
Здесь рассматривается такая же
Ознакомьтесь с соответствующими решениями, приведен-
возможная причина, как и в строках 1-4 табл. 24.7
ными в тех же строках табл. 24.7
Не был создан сервер LE
Увеличьте тайм-аут для устройства, на котором выполнена настройка конфигурации сервера LE
Невозможно выполнить на-
В базе данных сервера конфигураций уже имеется ATM-
стройку конфигурации сервера
адрес сервера LE.
конфигураций
Убедитесь в том, что ATM-адрес вновь созданного сервера LE еще не введен в базу данных сервера конфигураций
Описанные выше рекоменда-
Вызовите на выполнение следующую команду, чтобы раз-
ции не позволяют устранить
решить применение команд trace и debug:
проблему
ani -trace frontend -debug vlad -debug lane -debug ilmi - trace pnni -debug vmpsadmin -trace devices -debug devices.C5K -debug devices.C5K.C5500 -debug devices.LS1010 -debug devices.Router -debug devices.C3K -debug devices.C2800 -logfile ani.log
I Таблица 24.11. Отсутствие возможности выполнить настройку : • •конфигурации сервера конфигураций
Возможная причина
Предлагаемое решение
Здесь рассматривается такая же возможная причина, как и в строках 1-4 табл. 24.7
Не выполнена настройка конфигурации базы данных сервера конфигураций
Сервер конфигураций уже существует
Ознакомьтесь с соответствующими решениями, приведенными в тех же строках табл. 24.7
Увеличьте тайм-аут для устройства, на котором выполняется настройка конфигурации сервера конфигураций
С помощью интерфейса командной строки удалите существующую базу данных сервера конфигураций. Ниже приведен пример конфигурации.
Возможная причина
Предлагаемое решение
interface АТМО mat 1500
atm pvc 105 qsaal
atm pvc 2 0 16 ilmi
atm ilmi-keepalive 5 lange config database xxxx Удалите следующую строку: Lange config database xxxx
Серверу конфигураций не могли быть присвоены АТМ-адреса
С помощью интерфейса командной строки удалите соответствие между ATM-адресами, если оно уже существует. Пример конфигурации приведен ниже.
interface АТМО
mtu 1500
atm pvc 105 qsaal
atm pvc 2 0 16 ilmi
atm ilmi-keepalive 5
lane config fixed-config-atm-address
lane config auto-config-atm-address
lane config config-atm-address
lane config database xxxx
Удалите следующие строки:
lane config fixed-config-atm-address
lane config auto-config-atm-address
lane config config-atm-address lane config database xxxx
Невозможно выполнить настройку конфигурации АТМ- адреса сервера конфигураций в коммутаторах ATM
Проверьте определения групп устройств и увеличьте таймаут SNMP.
Для проверки определений групп устройств и увеличения тайм-аута SNMP выберите команды Edit^SNMP Communities в окне CWSI Campus. Подробные инструкции по вводу определений групп устройств и значений тайм-аута приведены в разделе Preparing for Network Discovery документа Getting Started with CWSI Campus
Описанные выше рекомендации не позволяют устранить проблему
Вызовите на выполнение следующую команду, чтобы разрешить применение команд trace и debug:
ani -trace frontend -debug vlad -debug lane -debug ilmi - trace pnni -debug vmpsadmin -trace devices -debug
devices.C5K -debug devices.C5K.C5500 -debug devices.LS1010
-debug devices.Router -debug devices.C3K -debug
devices.C2800 -logfile ani.log
Устранение нарушений в работе приложения AtmDirector
В настоящем разделе описаны способы использования инструментальных средств приложения AtmDirector для устранения нарушений в работе и повышения производительности сети.
Регистрация сообщений
В приложении AtmDirector предусмотрена возможность регистрировать сообщения об ошибках и отладочные сообщения, которые могут оказаться полезными в тех случаях, если возникает необходимость устранять нарушения в работе сети или решать какие-либо иные проблемы. Сообщения об ошибках и отладочные сообщения регистрируются автоматически (по умолчанию) в файле $CWSIROOT/log/atmd.log.
Чтобы разрешить или запретить применение таких средств регистрации, выполните следующие действия.
Шаг 1. Выберите команды Preferences^Options в главном окне приложения AtmDirector. Откроется окно Global Preferences.
Шаг 2. Выберите индексированную вкладку Miscellaneous. На экране будут отображены опции Miscellaneous.
Шаг 3. Щелкните на кнопке On, чтобы разрешить регистрацию сообщений об ошибках и отладочных сообщений, или щелкните на кнопке Off, чтобы запретить запись в журнал таких сообщений. В журнал автоматически записываются также сообщения об изменении топологии и об обнаружении устройств, если выбрана кнопка On. Эта функция предусмотрена по умолчанию.
Примечание
Если в данный момент происходит опрос устройств в процессе обнаружения, регистрация сообщений осуществляется после завершения этого процесса.
Шаг 4. Щелкните на кнопке ОК.
Шаг 5. Разрешить или запретить запись в журнал сообщений об ошибках и отладочных сообщений можно также во время эксплуатации приложения AtmDirector. Выбранная опция (On или Off) вступает в силу только после перезапуска приложения.
Примечание
Рекомендуется постоянно применять значение On этой отладочной опции.
Анализ журнала
Процесс устранения нарушений в работе сети и решения любых проблем можно начать с анализа сообщений об ошибках и отладочных сообщений, записанных в журнал приложения AtmDirector. Журнал с сообщениями об ошибках и отладочными сообщениями хранится в файле $CWSIROOT/log/atmd.log.
Примечание
Если в файле журнала отсутствуют какие-либо сообщения об ошибках и отладочные сообщения, это означает, что опция ведения соответствующего журнала не установлена равной On.
Сообщения об ошибках и отладочные сообщения в файле $CWSIROOT/log/atmd.log представлены в следующем формате:
<timestamp> AtmDirector:<severity>:<component>:<message>
Примеры сообщений об ошибках и отладочных сообщений приведены ниже.
1998/07/29 17:09:15.55 AtmDirector:Info:GUI:Started AtmDirector Initialization...
1998/07/29 17:09:15.56 AtmDirector:Debug:Topology:Running in Debug All mode.
1998/07/29 17:09:17.08 AtmDirector:Debug:ORB:EVENTCHANNEL CONNECTED...
1998/07/29 17:09:30.37 AtmDirector:Info:GUI:Finished AtmDirector Initialization.
Проверка состояния устройств и каналов
Приложение AtmDirector контролирует состояние устройств и каналов через заданные интервалы и отображает полученную информацию о состоянии в топологической схеме, изменяя цвета пиктограмм соответствующих устройств и обозначая состояние каналов.
Для переопределения интервалов контроля состояния можно изменить параметры опроса SNMP. Параметры опроса (Timeout, Retries, Data Collection Polling Interval и Utilization Polling Interval) отображаются в окне Global Preferences.
Параметр Timeout по умолчанию составляет 5 секунд. Если в процессе опроса от устройства не получен ответ в течение указанного времени, то устройство считается недоступным.
Значение параметра Retries (Количество повторных попыток) по умолчанию равно трем. Если процесс обнаружения не может обратиться к какому-то устройству за указанное число попыток, то устройство считается недоступным.
Параметр Data Collection Polling Interval по умолчанию составляет 30 минут. Этот интервал опроса используется приложением RMON.
Параметр Utilization Polling Interval по умолчанию составляет 10 секунд. Этот интервал опроса используется при расчете данных, отображаемых в перечне виртуальных каналов.
Проверка сетей ATM
Для устранения нарушений в работе сети ATM, а также контроля над трафиком и степенью загрузки виртуальных каналов этой сети применяются специальные отчеты и графические экраны, предусмотренные в приложении AtmDirector. Для ознакомления с необходимой для этого информацией обратитесь к следующим разделам оперативного руководства по приложению AtmDirector (http://cio.cisco.com/univercd/cc/ td/doc/product/rtrmgmt/cw2000/camp_mgr/cwsi_2x/c2si_2 2/atmd_c/vcs.htmtxtocid2851315).
List Virtual Channels (Формирование перечня виртуальных каналов).
Selecting Virtual Channels (Выбор виртуальных каналов).
Checking Link Utilization (Проверка степени загрузки каналов).
Checking Virtual Channel Utilization (Проверка степени загрузки виртуальных каналов).
Plotting Utilization (Составление графика загрузки).
Tracing Virtual Channels (Трассировка виртуальных каналов).
Display Trace Reports in Tabular Form (Отображение отчетов о трассировке в табличной форме).
Display Trace Reports Graphically (Отображение отчетов о трассировке в графической форме).
Clearing Trace Reports (Очистка отчетов о трассировке).
Display Virtual Channels Between Devices (Отображение виртуальных каналов между устройствами).
Checking Virtual Channel Connectivity (Проверка связи по виртуальному каналу).
Triggering ОАМ Pings (Активизация запросов эхо-тестирования ОАМ).
Display ап ОАМ Ping Report (Отображение отчета о результатах эхо-тестирования ОАМ).
Setting Up Soft Permanent Virtual Channels or Paths (Установка программных постоянных виртуальных каналов или маршрутов).
Setting the Interface Configuration (Настройка конфигурации интерфейса).
Проверка сети ATM-VLAN
Для устранения нарушений в работе сети ATM-VLAN, а также контроля над трафиком и степенью загрузки компонентов LANE и виртуальных каналов этой сети применяются специальные отчеты и графические экраны, предусмотренные в приложении AtmDirector. Для ознакомления с необходимой для этого информацией обратитесь к следующим разделам оперативного руководства по приложению AtmDirector (http://cio.cisco.com/unviercd/cc/td/doc/product/rtrmgmt/cw2000/camp_mgr/cwsi_2x/cwsi 2_2 /atmd_c/lanetopo.htm).
Displaying ATM-VLAN Information for Fabric Devices (Отображение информации ATM-VLAN, относящейся к устройствам коммутационной структуры).
Displaying Summary Information for an ATM-VLAN (Отображение итоговой информации по сети ATM-VLAN).
Viewing Client Summary Information (Просмотр итоговой информации о клиенте).
Viewing LE Server/Broadcast Server Summary Information (Просмотр итоговой информации о сервере LE/широковешательном сервере).
Viewing Configuration Server Summary Information (Просмотр итоговой информации о сервере конфигураций).
Viewing the Configuration Server Database (Просмотр базы данных сервера конфигураций).
Viewing the Configuration Server ATM-VLAN Configuration Table (Просмотр таблицы конфигурации ATM-VLAN на сервере конфигураций).
Monitoring Control Connections for a LANE Component (Текущий контроль управляющих соединений для компонента LANE).
Monitoring Data Direct Connections for a Client (Текущий контроль непосредственных соединений передачи данных для клиента).
Monitoring Client Status and Control Parameters (Текущий контроль состояния клиентов и параметров управления).
Monitoring the LE_ARP Table (Текущий контроль таблицы LE_ARP).
Monitoring LE Server Status (Текущий контроль состояния сервера LE).
Monitoring Configuration Server Addresses (Текущий контроль адресов сервера конфигураций).
Graphing Client Performance Information (Графическое представление данных о производительности клиента).
Graphing Broadcast Server Performance Information (Графическое представление данных о производительности широковещательного сервера).
Проверка сети PNNI
Приложение AtmDirector может применяться для устранения нарушений в работе сети PNNI путем проверки конфигурации узла (включая таймеры PNNI), контроля состояния каналов соседних одноранговых узлов, в том числе адресов PNNI, а также настройки параметров PNNI. Для ознакомления с необходимой информацией обратитесь к перечисленными ниже разделам интерактивного руководства AtmDirector, к которым можно получить доступ в Web по следующим адресам.
http://cio.cisco.com/unviercd/cc/td/doc/product/rtrmgmt/cw2000/cainp_mgr/cwsi_2x/ cwsi_2_2/atmd_c/pnnicfg.htm.
http://cio.cisco.com/unviercd/cc/td/doc/product/rtrmgmt/cw2000/camp_mgr/cwsi_2x/ cwsi_2_2/atmd_c/pnniaddr.htm.
http://cio.cisco.com/unviercd/cc/td/doc/product/rtrmgmt/cw2000/camp_mgr/cwsi_2x/ cwsi_2_2/atmd_c/pnnimgmt.htm.
Displaying the Node Configuration and Information (Отображение конфигурации узла и информации об узле).
Modifying the Node Configuration (Корректировка конфигурации узла).
Displaying Link Information (Отображение информации о канале).
Displaying the Values of the PNNI Timers (Отображение значений таймеров PNNI).
Modifying the Values of the PNNI Timers (Корректировка значений таймеров PNNI).
Displaying Neighboring Peer Link and Status Information (Отображение информации о каналах к соседним одноранговым узлам и информации о состоянии).
Display Address Summaries (Отображение итоговых данных об адресах).
Modify an Address Summary (Корректировка итоговых данных об адресах).
Add an Address Summary (Пополнение итоговых данных об адресах).
Delete an Address Summary (Удаление итоговых данных об адресах).
Displaying Reachable Addresses (Отображение доступных адресов).
Modify a Reachable Address (Корректировка доступных адресов).
Add a Reachable Address (Пополнение доступных адресов).
Delete a Reachable Address (Удаление доступных адресов).
Display Address Scope Mapping (Вывод на экран информации об области определения адресов).
Modify Address Scope Mapping (Корректировка области определения адресов).
Display PNNI Interface Parameters (Отображение параметров интерфейса PNNI).
Modify PNNI Interface Parameters (Корректировка параметров интерфейса PNNI).
Сбор данных, необходимых для поиска неисправностей
В приложении AtmDirector предусмотрены некоторые средства, при использовании которых необходимо разрешить сбор данных в целях поиска неисправностей. Собранные данные могут применяться для решения следующих задач.
Определение В наиболее активных хостов в коммутационной структуре или клиентов в сети ATM-VLAN.
Получение информации о характеристиках трафика между хостами или между клиентами.
Отображение результатов анализа случаев аварийного завершения в коммутационной структуре или сети ATM-VLAN вызовов, направленных на устройство и от устройства, в графической форме.
Чтобы ознакомиться с информацией, необходимой для сбора данных, обратитесь к следующим разделам оперативного руководства по программе AtmDirector (http://cio/ cisco/com/univercd/cc/td/doc/product/rtrmgmt/cw2000/camp_mgr/cwsi_2x/cwsi_2_2/atmd_c/ enable2.htm#xtocid56365).
Enabling Data Collection (Применение средств сбора данных).
Setting Up Port Select Groups (Определение групп выбора порта).
Viewing Enabled Switches (Просмотр применяемых коммутаторов).
Graphing Top N Active Hosts (Оформление данных об У наиболее активных хостах в виде диаграммы).
Graphing Traffic Between Hosts (Оформление в виде диаграммы данных о трафике между хостами).
Graphing Call Failures (Оформление в виде диаграммы данных о количестве случаев аварийного завершения вызовов).
Graphing a Broadcast Server Frame Analysis (Оформление в виде диаграммы результатов анализа фреймов широковещательного сервера).
Disabling Data Collection (Отмена средств сбора данных).
Решение практических задач
В табл. 24.12 перечислены нарушения в работе, возникающие при использовании приложения AtmDirector, указаны причины, которые могут вызвать эти проблемы, и описаны решения этих проблем.
Таблица 24.12. Устранение нарушений в работе . г.;fy,;v У J
Проблема
Возможная причина
Предлагаемое решение
Невозможно обнаружить оконечный хост
Не разрешено применение интерфейса ILMI
Разрешите применение интерфейса ILMI в соответствующем оконечном хосте
Проблема
Возможная причина
Предлагаемое решение
Не существует соединение SNMP с оконечным хостом
Выполните настройку конфигурации соединения SNMP с оконечным хостом. Убедитесь в том, что соблюдены все требования к устройству
LEC-клиент не
К устройству, на ко-
Проверьте, существует ли данный LEC-клиент в
появляется в
тором расположен
эмулированной локальной сети и можно ли по-
схеме эмулированной локальной сети
LEC-клиент, невозможно получить доступ по протоколу SNMP или это устройство невозможно было присоединить к эмулированной локальной сети
лучить доступ к устройству по протоколу SNMP
Невозможно
LEC-клиент не был
Убедитесь в том, что к устройству, на котором
присоединить
обнаружен как дейст-
развернут LEC-клиент, можно получить доступ
LEC-клиент к эмулированной локальной сети
вительный LEC- клиент
В свое время данный LEC-клиент был обнаружен, но затем остановлен, поэтому его не удалось вновь ввести в состав эмулированной локальной сети
по протоколу SNMP
Проверьте состояние LEC-клиента; убедитесь в том, что его адрес задан правильно в конфигурации коммутатора LigfitStream 1010
Проверьте последнее состояние отказа LEC- клиента
Отсутствует
Клиенты относятся к
Убедитесь в том, что оба клиента относятся к
связь между клиентами
разным эмулированным локальным сетям Один клиент неизвестен для другого Клиент (клиенты) не зарегистрирован на LES-сервере
одной и той же эмулированной локальной сети
Проверьте информацию ARP о клиенте, чтобы определить, известен ли он другому LEC-клиенту Проверьте окно параметров состояния LES- сервера
График произ-
Какой-то клиент ис-
Определите, какой LEC-клиент в настоящее
водительности
пользует подавляю-
время характеризуется интенсивным использо-
BUS-сервера
щую часть пропуск-
ванием широковещательного трафика. Проверь-
показывает высокую степень его загрузки
ной способности сети
те, какие клиенты относятся к категории TopN (N клиентов с наибольшими показателями)
Относительное
Неправильно задана
Перейдите к пункту меню Graphing Client Perform-
количество управляющих фреймов чрезмерно велико
конфигурация
апсе Information (Графическое представление данных о производительности клиента) для получения информации об управляющих фреймах и внесения в конфигурацию соответствующих изменений. Например, если велик относительный объем запросов OUT ARP, то, возможно, существует необходимость откорректировать время отклика ARP
Проблема
Возможная причина Предлагаемое решение
Устройство необходимо перевести в автономный режим для обслуживания
Узел PNNI не появляется на топологической схеме
Это может отразиться Проверьте каталог сетей ATM-VLAN на схеме на работе эмулирован- коммутационной структуры для получения спи- ных локальных сетей ска всех компонентов эмулированных локальных сетей, развернутых на этом устройстве
Этот узел PNNI неВоспользуйтесь интерфейсом CiscoView или ин-
разрешен для исполь- терфейсом командной строки, чтобы проверить, зованияразрешено ли применение данного узла PNNI
(индекс узла равен 1). Затем выберите коммутатор LightStream 1010, который включает этот узел, и повторно выполните процесс обнаружения данного устройства
Узел PNN1 изолирован от сети PNNI
Сервер ANI не нашел Выберите узел PNNI на топологической схеме ссылку PNNI для PNNI. Затем определите, имеет ли данный узел этого узла во время PNNI такой же уровень, как и другие узлы, предыдущего периода Проверьте также, выполнена ли настройка кон- выполнения процесса фигурации этого узла для использования в кана- обнаружения ле PNNI.
Примечание. Если уровень узла и конфигурация интерфейса заданы правильно, то необходимо вновь провести процесс обнаружения данного устройства. Для синхронизации канала PNN1 с соседними узлами требуется примерно от 2 до 3 минут, и сервер ANI, возможно, мог не найти исходящий из этого узла канал PNN1 во время предыдущего периода выполнения процесса обнаружения ■
Устранение нарушений в работе приложения TrafficDirector
В некоторых случаях среда TrafficDirector не функционирует, как это требуется. В настоящем разделе приведены рекомендации по устранению нарушений в работе среды TrafficDirector. В нем рассматриваются следующие темы.
Влияние параметров зашиты на функционирование консоли управления TrafficDirector и устройства SwitchProbe.
Инсталляция средств защиты SwitchProbe и Network Analysis Module, а также файла свойств.
Способы проверки режима работы агентов локальной сети, агентов Frame Relay и коммутаторов.
Обеспечение доступа к устройствам SwitchProbe
Поскольку в установке и настройке конфигурации устройств SwitchProbe могут принимать участие сотрудники, не выполняющие функции администратора приложения TrafficDirector, ниже приведен краткий обзор тех последствий, которые могут быть вызваны применением определенных параметров конфигурации устройства SwitchProbe, что позволит упростить поиск возможных нарушений в работе.
Прежде чем приложение TrafficDirector сможет обратиться к данным SwitchProbe, требуется должным образом настроить параметры с использованием утилиты настройки конфигурации агента SwitchProbe, включая те специальные параметры, которые применяются для контроля статистических данных в сети Frame Relay, ATM и распределенной сети.
Для получения дополнительной информации обратитесь к следующим разделам.
Опции приложений VLAN Monitor, SMON MIB и ART MIB.
Опции приложений NetFlow и Resource Monitor — устройства SwitchProbe.
Средства защиты SwitchProbe и Network Analysis Module.
Опции приложений VLAN Monitor, SMON MIB и ART MIB.
Примечание
Опция ART MIB доступна только на устройствах SwitchProbe.
Для того чтобы приложение TrafficDirector получило доступ к соответствующим данным, которые требуются для работы приложений VLAN Monitor или ART Monitor, необходимо разрешить применение опции виртуальной локальной сети на устройстве SwitchProbe или в модуле Network Analysis Module для поддержки VLAN Monitor, а также разрешить в нем применение опции ART MIB для поддержки приложения ART Monitor.
Опции приложений NetFlow и Resource Monitor — устройства SwitchProbe
Чтобы приложение TrafficDirector могло контролировать активность приложений NetFlow и Resource Monitor, необходимо разрешить применение опции NetFlow в устройстве SwitchProbe для поддержки просмотра данных прокси-сервера SNMP и данных о задержке кругового обращения (только с помощью приложения Resource Manager), а также статистических данных NetFlow.
Опция NetFlow — модуль Network Analysis Module
Для того чтобы приложение TrafficDirector могло поддерживать просмотр статистических данных NetFlow в модуле Network Analysis Module, необходимо обеспечить, чтобы в этом устройстве было разрешено применение опции NetFlow.
Защита устройства SwitchProbe и модуля
Network Analysis Module
Чтобы администратор приложения TrafficDirector имел права доступа к локальной консоли устройства SwitchProbe с помощью приложения TrafficDirector Remote Login, необходимо предоставить ему необязательные административные привилегии (доступ для чтения и записи).
Пользовательские права доступа, если они установлены на устройстве SwitchProbe, позволяют просматривать параметры настройки консоли, но не редактировать их. Такие параметры защиты пользовательского уровня являются удобными, если имеется много узлов, для контроля за работой которых быть привлечен эксплуатационный персонал, но на этот персонал не должна быть обязательно возложена задача устранения нарушений в работе агента SwitchProbe.
Если для устройства SwitchProbe установлен административный пароль, то приложение Remote Login могут использовать только те, кто знает этот пароль. Это средство зашиты SwitchProbe не зависит от опций защиты, которые разрешены для контроля доступа к приложениям администратора Traffic Director.
Дополнительная информация приведена в следующем разделе.
Инсталляция файла свойств
Для обеспечения автоматической переинсталляции файлов свойств при перезагрузке устройств SwitchProbe выполните следующие действия.
Шаг 1. Воспользуйтесь предусмотренными по умолчанию сценариями для вызова на выполнение программы dvcfg (либо сценарием startup для большинства агентов, либо fstartup для агентов Frame Relay).
Шаг 2. Укажите в качестве адреса сервера SwitchProbe IP-адрес станции управления Traffic Director.
Шаг 3. Убедитесь в том, что демон dvtrap приложения TrafficDirector функционирует.
Если эти условия соблюдаются, то нет необходимости переинсталлировать файлы свойств вручную с помошью программы Configuration Manager.
Доступ по сети к устройствам SwitchProbe
Для проверки того, имеется ли связь по сети с устройством SwitchProbe, используется приложение Test Agents. Это инструментальное средство проверки агентов показывает, является ли агент работоспособным и какие опции поддерживает, а также позволяет определить общее состояние соединения с этим устройством по протоколам UDP/IP.
Дополнительная информация о настройке конфигурации агента приведена в руководстве Cisco SwitchProbe Installation and Configuration Guide.
Проверка агентов, коммутаторов и агентов Frame Relay
Примечание
Средство Test Agent не обновляет информацию порта SPAN в разделе Roving Information, если настройка параметров порта SPAN в коммутаторе выполнялась с помощью интерфейса командной строки. Это средство всегда отражает информацию о порте, который был выведен из сферы действия приложения TrafficDirector и не обновлен. Для проверки агента, агента Frame Relay или коммутатора выполните следующие действия.
Шаг 1. Выберите агент, который необходимо проверить, из списка агентов в главном окне приложения TrafficDirector или в программе Configuration Manager.
Шаг 2. Выполните одно из следующих действий.
В главном окне приложения TrafficDirector щелкните на пиктограмме Test Agent.
В программе Configuration Manager щелкните на элементе Test.
Если агент является работоспособным, откроется окно Agent Test.
Интерпретация сообщений инструментального средства Test Agent
Если проверка завершится успешно, отобразится информация, приведенная в табл. 24.13. По окончании просмотра этой информации щелкните на кнопке ОК, чтобы закрыть окно Agent Test.
Таблица 24.13. Информация, отображаемая в окне Agent Test после *успешного выполнения проверки
Поле
Описание
IP Address
Ping
IP-адрес интерфейса управления агентом
Результаты эхо-тестирования (запроса).
Passed. Соединение полностью работоспособно.
Not Supported. Соединение полностью работоспособно, но не поддерживается опцией Resource Monitor
Read Community
Имя группы устройств чтения данного агента (заданное в приложении Configuration Manager) и информация о том, совпадает это имя с установленным именем группы устройств чтения агента (ОК) или не совпадает (Failed)
Write Community
Имя группы устройств записи данного агента (заданное в приложении Configuration Manager) и информация о том, совпадает это имя с установленным именем группы устройств записи агента (ОК) или не совпадает (Failed)
Protocol Monitoring Application Monitoring High Capacity Monitoring VLAN Monitoring Application Response Time Resource Monitoring
Информация о том, поддерживает ли агент контроль протокола RMON2 сетевого уровня
Информация о том, поддерживает ли агент контроль протокола RMON2 прикладного уровня
Информация о том, поддерживается ли агентом HCRMON как быстродействующее устройство
Информация о том, разрешена ли в агенте опция VLAN Monitor
Информация о том, разрешена ли в агенте опция ARTMIB
Информация о том, разрешено ли в агенте использование средств приложения Resource Monitor. Приложение Resource Monitor требуется для настройки конфигурации задержек RT и выборок по протоколу SNMP с кэшированием
Interface Number
Description
Interface Type
Номер интерфейса агента, применяемого для контроля над функционированием сетевого сегмента
Тип передающей среды интерфейса, указанного в поле Interface Number
Тип интерфейса, различаемый в соответствии с протоколом физического уровня, как описано в документе RFC 1213
Physical Address
Number of Interfaces
Net Speed
МАС-адрес агента
Количество сетевых интерфейсов на устройстве, на котором развернут агент
Ориентировочная пропускная способность текущего интерфейса в битах в секунду (бит/с)
DTE Speed
Ориентировочная скорость цепи DTE (бит/с).
Относится только к дуплексным каналам
Поле
Описание
DCE Speed
Ориентировочная скорость цепи DCE (бит/с).
Относится только к дуплексным каналам
Description
Модель устройства, указанная сетевым администратором
Contact
Имя лица, ответственного за функционирование агента, и способ взаимодействия с этим лицом
SysName
Имя агента, назначенное административным путем
Location
Физическое местонахождение агента, указанное системным администратором в приложении Configuration Manager
UpSince
Дата и время начала эксплуатации агента в сети, а также время последней загрузки агента
Интерпретация сообщений о проверке агента коммутатора
Результаты проверки, вырабатываемые при взаимодействии с коммутатором, немного отличаются от информации, вырабатываемой при проверке агента.
При проверке коммутатора программное обеспечение TrafficDirector опрашивает коммутатор и информирует пользователя, был ли запрос выполнен успешно или потерпел неудачу. После этого открывается окно Switch Test.
Если проверка выполнена успешно, отображается информация, приведенная в табл. 24.14.
1 Таблица 24.14. Информация, отображаемая в окне Switch Test после।
Iуспешного выполнения проверки
Поле
Описание
IP Address
Ping
Read Community
Write Community
IP Address Description Contact
SysName Location
UpSince
IP-адрес интерфейса управления коммутатора
Результаты эхо-тестирования (запроса).
Passed. Соединение полностью работоспособно.
Not Supported. Соединение полностью работоспособно, но не поддерживается опцией Resource Monitor
Имя группы устройств чтения коммутатора (заданное в приложении Configuration Manager) и информация о том, совпадает это имя с установленным именем группы устройств чтения агента (ОК) или не совпадает (Failed)
Имя группы устройств записи коммутатора (заданное в приложении Configuration Manager) и информация о том, совпадает это имя с установленным именем группы устройств записи агента (ОК) или не совпадает (Failed)
Адрес IP интерфейса управления коммутатора
Модель устройства, указанная сетевым администратором
Имя лица, ответственного за функционирование коммутатора, и способ взаимодействия с этим лицом
Имя коммутатора, которое определено в системе
Физическое местонахождение коммутатора, указанное системным администратором в приложении Configuration Manager
Дата и время начала эксплуатации коммутатора в сети, а также время последней загрузки агента
Поле
Описание
Roving Agent
Analyzer Port
Monitor Port
Имя мобильного агента, назначенного для данного коммутатора, если таковой существует
Имя порта коммутатора, с которым физически связан мобильный агент, если таковой существует
Применяемый в настоящее время порт подключения мобильного агента, если таковой существует. Этот порт монитора содержит имя порта коммутатора, контролируемого в настоящее время мобильным агентом
В случае неудачного завершения проверки отображается такое же сообщение, как и при использовании агента локальной сети или агента сети Frame Relay.
Устранение нарушений в работе приложения CiscoView
В настоящем разделе приведена информация по устранению нарушений в работе приложения CiscoView и описаны способы выявления неисправностей устройств при использовании этого приложения.
Зависимость производительности системы от состава файлов CVinstall.cshrc и CVinstall.sh
Файлы CVinstall.cshrc и CVinstall.sh автоматически устанавливают все переменные среды, необходимые для приложения CiscoView. Если при запуске приложения CiscoView возникают ошибки, то их причиной является применение недопустимых параметров в одном из этих файлов.
По умолчанию приложение CiscoView открывает список параметров каждого устройства в отдельном окне. В больших сетях это может привести к использованию слишком большого объема оперативной памяти и снижению производительности. Для уменьшения потребления оперативной памяти можно открыть списки параметров нескольких устройств в одном и том же окне; для этого необходимо изменить эксплуатационные характеристики. Выберите пункты меню Options^Properties и отметьте значение Same Window опции Launch CiscoView In.
Кроме того, производительность системы может снизиться при одновременном использовании нескольких сеансов работы приложения CiscoView в связи с увеличением объема потребления ресурсов сервера X. Уменьшите количество сеансов, выполняемых на сервере X, выбрав пункты меню Options^Properties и отметив опцию Same Window. В результате при последующих вызовах приложения CiscoView на сервере X будет повторно использоваться один и тот же сеанс.
Устранение проблем, возникающих при выводе информации
Если в приложении CiscoView попытка вывести информацию об устройстве оканчивается неудачей, появляется следующее сообщение:
"<hostname>: unmanageable"
Это сообщение свидетельствует о возникновении одного из следующих условий.
На устройстве не работает агент SNMP, несмотря на то, что это устройство доступно в сеансе управления.
Должна существовать возможность эхо-тестирования устройства в сеансе управления.
Неправильно введено одно из определений группы устройств.
Чтобы повторно ввести определение группы устройств, выберите пункты меню Options=i>Properties.
Управляющая станция не может обратиться к устройству и успешно выполнить его эхо-тестирование.
Проверьте программный пакет, установленный на устройстве, и сравните дату его выпуска с датой выпуска пакета программного обеспечения устройства в версии, указанной на узле ССО. В случае необходимости модернизируйте пакет программного обеспечения устройства и установите новейшую версию.
Обнаружена ошибка, связанная с применением неподдерживаемой платы.
Если пакет программного обеспечения устройства не поддерживает установленную в нем плату, то в приложении CiscoView вместо содержимого платы отображается сообщение об ошибке "Unsupported Card" или "Unknown Card". В этом случае может потребоваться обратиться на узел ССО и изучить планы модернизации пакета программного обеспечения устройства. Если предполагается, что в пакете программного обеспечения устройства должна быть предусмотрена поддержка этой платы, попытайтесь обновить программное обеспечение, получив его новейшую версию с узла ССО.
Получено сообщение об ошибке "Can't read DD(...) not set".
Приложение CiscoView вырабатывает это сообщение об ошибке, если возникает одно из следующих условий.
Применяемая версия IOS не поддерживается пакетом программного обеспечения устройства.
Само физическое устройство не содержит необходимый компонент, т.е. соответствующую плату, или настройка его конфигурации не была проведена должным образом.
В системе IOS не реализовано средство поддержки платы. В этом случае может потребоваться провести модернизацию IOS и установить подходящую версию.
Нарушения в работе связаны с применением пакета программного обеспечения устройства.
Если имеет место одно из описанных выше условий, убедитесь в том, что пакет программного обеспечения устройства поддерживает версию IOS рассматриваемого устройства. Обновите версию IOS или замените коммутатор.
Приложение CiscoView выполняет откат к предыдущей конфигурации после инсталляции или деинсталляции пакета программного обеспечения устройства.
После инсталляции очередного пакета программного обеспечения устройства приложение CiscoView вызывает на выполнение утилиту статической проверки (cvtest) всех существующих пакетов программного обеспечения устройства, чтобы определить, приводит ли их инсталляция или деинсталляция к дестабилизации работы приложения CiscoView.
Откат к предыдущей конфигурации после инсталляции пакета программного обеспечения устройства может возникнуть по следующим двум причинам:
пакет был установлен без инсталляции обязательного пакета программного обеспечения устройства, от которого он зависит. Например, перед инсталляцией пакета AS5800 должен быть установлен пакет 3600, а для пакета CPW1420.pkg требуется инсталляция пакета Cat2820;
Примечание
Если такая проблема возникает во время последовательного проведения инсталляций, проверьте список установленных пакетов и убедитесь в том, что инсталлированы все необходимые пакеты.
инсталляция пакета программного обеспечения устройства не прошла контроль с помощью утилиты статической проверки. Обратитесь в центр Cisco ТАС и передайте файл $NMSROOT/CVinstall.log.
Получите список пакетов, установленных в системе, с номерами их версий. Отметьте имя пакета программного обеспечения устройства, к которому относится сообщение об ошибке, и номер его версии.
Выявление нарушений в работе устройства (монитор инструментальной панели)
Для определения причины нарушения в работе выполните любую из следующих задач в приложении CiscoView.
Проверьте надпись с цветовой кодировкой для определения состояния порта.
Просмотрите информацию о конфигурации порта и определите, активен ли данный порт (для этого применяется команда меню Displaying Configuration).
Ознакомьтесь с информацией о производительности, просмотрев содержимое окна инструментальной панели.
Ознакомьтесь с информацией о степени загрузки и наличии ошибок, относящейся к портам, и с информацией об использовании памяти, относящейся к устройствам.
Проверьте строку состояния, чтобы узнать о наличии сообщений об ошибках SNMP или о других ошибках.
Интерпретация сообщений об ошибках SNMP
В области сообщений строки состояния приложения CiscoView отображаются следующие сообщения об ошибках SNMP, возникающие при неудачном выполнении запросов команд (табл. 24.15).
| Таблица 24.15. Сообщения об ошибках SNMP .
Сообщение Описание
timeoutНевозможно обратиться к устройству за время, указанное в окне CiscoView
Properties
Сообщение Описание
tooBigСформированный запрос нельзя разместить в одном пакете. Как правило,
приложение CiscoView делит запросы на получение информации о физическом состоянии на части таким образом, чтобы устройство могло на них успешно ответить. В некоторых случаях в приложении CiscoView принимается гипотеза, что если агент завершил работу по тайм-ауту после получения запроса, который включает больше 20 переменных, то агент не способен ответить на такой запрос, поскольку он слишком велик. В таком случае приложение CiscoView делит запрос на части и передает его повторно. Проследите за тем, чтобы в интерфейсе SNMP был задан максимально возможный размер MTU; это позволяет не расходовать напрасно пропускную способность, передавая в приложении CiscoView несколько запросов вместо одного
genErrПод таким именем поступает сообщение о нарушениях в работе, для которых
не предусмотрено отдельное сообщение об ошибке
noSuchName В переданном запросе указана недоступная переменная. Такая ситуация возникает при использовании неправильного определения группы устройств
badValue Агент не ответил в течение временного интервала, заданного в поле Timeout/Retries в окне CiscoView Properties. Это сообщение может также указывать, что применяется неправильное определение группы устройств.
При выполнении операции установки в объекте MIB значение, заданное для записи, не имеет синтаксическую структуру, подходящую для данного объекта MIB. Это может быть связано с использованием недопустимого типа или значений, выходящих за пределы недопустимого диапазона
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco
Прежде чем обратиться в центр Cisco ТАС, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе своей системы.
Кроме того, выполните следующие действия и подготовьте указанные документы, которые позволят специалистам центра Cisco ТАС быстрее предоставить вам помощь.
Определите применяемую версию CiscoWorks 2000 (RME2.2/CWSI2.4, RME2.1/CWSI2.3, RME2.0/CWSI2.2 или др.).
Укажите, в какой операционной системе она установлена (Windows NT 4.0, Solaris 2.5.1/2.6, HPUX10.20/11.0, IBM AIX 4.2.1/4.3.2).
Подготовьте данные о составе аппаратных средств системы: модель и быстродействие процессора, доступный объем ОЗУ, объем свободного пространства на жестком диске.
Если возникает нарушение в работе приложения на основе Web (такого как RME), предоставьте информацию о типе и версии броузера.
Укажите, какая операция оканчивается неудачно или приводит к появлению сообщения об ошибке.
Приведите полный текст сообщения об ошибке и опишите характер нарушения в работе или обстоятельства появления сообщения об ошибке.
Укажите, к какому устройству применялась рассматриваемая операция.
Определите версию IOS или версию программного обеспечения коммутатора.
Подготовьте описание способа воспроизведения рассматриваемого нарушения в работе.
Дополнительная литература
Ниже перечислена литература по рассматриваемым темам, изданная типографским способом и предоставленная для просмотра в оперативном режиме на узле ССО.
Addendum: Using the Campus Traffic Director Application— http://cio.cisco.com/ univercd/cc/td/doc/product/rtrmgmt/sw_ntman/td_main/td_5_7/td57add.htm.
Getting Started with CiscoView 4.2(1) — http://cio.cisco.com/univercd/cc/td/doc/ product/rtrmgmt/cvparnt/cview/cvovr42/index.htm.
Getting Started with CWSI Campus— http://cio.cisco.com/univercd/cc/td/doc/ product/rtrmgmt/cw2000/camp mgr/cwsi_2x/cwsi_2 2/gsg_cwsi/index.htm.
Getting Started with Resource Manager Essentials— http://cio.cisco.com /univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000e/e_2_x/rm_2_0/rme_gs/index.htm.
Installing Resource Manager Essentials/CWSl Campus on AIX — http://cio.cisco.com /univercd/cc/td/doc/product/rtrmgmt/cw2000/camp_mgr/cwsi_2x/cwsi_2_3/mgr_aix/ index.htm.
Installing Resource Manager Essentials/CWSl Campus on HP-UX— http:// cio.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/camp_mgr/cwsi_2x/cwsi_2_3/ mgr_hpux/index.htm.
Installing Resource Manager Essentials/CWSl Campus on Solaris— http:// cio.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/camp mgr/cwsi_2x/cwsi 2 3/ mgr_sol/index.htm.
Installing Resource Manager Essentials/CWSl Campus on Windows— http:// cio.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/camp_mgr/cwsi_2x/cwsi_2_4/mg r_winZindex.htm.
Release Notes for Resource Manager Essentials 2.2/CWS1 Campus 2.4 — http:// cio.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/camp_mgr/cwsi 2x/cwsi_2 _4/relnt2_3/index.htm.
Supported Devices for CWSI Campus 2.4— http://www.cisco.com/univercd/cc/td/ doc/product/rtrmgmt/cw2000/c2_4.htm.
Supported Devices in Essentials 2.1/2.2 — http://cio.cisco.com/univercd/cc/td/doc/ product/rtrmgmt/cw2000/cw2000e/dev sup/index.htm.
Using the Campus Atm Director Application — http://cio.cisco.com/univercd/cc/td/ doc/product/rtrmgmt/cw2000/camp_mgr/cwsi_2x/cwsi_2_2/atmd_c/index.htm.
Using the Campus Traffic Director Application — http://cio.cisco.com/univercd/cc/td/ doc/product/rtrmgmt/sw_ntman/td_main/td_5_6/traf5_6Zindex.htm.
Using the Campus UserTracking Application — http://cio.cisco.com/univercd/cc/td/ doc/product/rtrmgmt/cw2000/camp_mgr/cwsi_2x/cwsi_2_2/us_c/index.htm.
Using the Campus VlanDirector Application — http://cio.cisco.com/univercd/cc/td/ doc/product/rtrmgmt/cw2000/camp_mgr/cwsi_2x/cwsi_2_2/vd_c/index.htm.
ГлаваГлава2525
Глава
Глава
25
25
Устранение нарушений в работе средств обеспечения безопасности сети
'’ В настоящей главе рассматриваются некоторые средства обеспечения безопасно
сти, предназначенные для защиты сети. К ним относится сканирующее программное обеспечение (CiscoSecure Scanner, прежнее название NetSonar), программное обеспе-
‘ чение обнаружения вторжения (CiscoSecure Intrusion Detection System, прежнее название NetRanger), программное обеспечение брандмауэра (Cisco FIX Firewall), а также средства восстановления.паролей маршрутизаторов и коммутаторов.
., , По мере дальнейшего роста Internet расширяется и сфера проявления злонамеренных ‘ действий. Такие действия могут оказаться весьма разнообразными, начиная от нападений по;принципу отказа в обслуживании и заканчивая компрометацией конфиденциальных данных. Для защиты сети было разработано много средств обеспечения безопасности.
•■К числу первых средств обеспечения безопасности, предназначенных для предотвращения несанкционированного проникновения в защищенную сеть, принадлежат брандмауэры. Онипрёдоставляют доступ к сети только с помощью специально сконфигурированных протоколов и сетевых объектов. Вслед за брандмауэрами были раз- Цработаны программные продукты обнаружения вторжения. Такие программы позво- ляютконтролировать санкционированный трафик, проходящий через брандмауэр, и одновременно с этим отыскивать следы неправомочной деятельности, такой как полый® взлома и нападения по принципу отказа в обслуживании. И, наконец, разработано сканирующее пррграминое обеспечение, которое позволяет администраторам находить уязвимые места' в защите сети.
v^N настоящей главе приведены сведения, позволяющие сетевым администраторам устранять нарушения в работе упомянутых здесь средств обеспечения безопасности, установленных® еети. Предполагается, что читатель знаком с процедурой инсталля- цйи и эксплуатации рассматриваемых программных продуктов.
г' В этой главе рассматриваются только отладочные команды debug. Для получения дополнительной информации о синтаксисе команд и ознакомления с описанием каждого программного продукта обратитесь к руководству пользователя. Описание этих команд можно также найти в рубрике Service and Support раздела Technical Documentation на узле ССО.
При подготовке этой главы рассматривались только новейшие версии программного обеспечения. Для ознакомления с работой предыдущих версий рассматриваемого здесь программного обеспечения обратитесь к руководству пользователя по конкретному продукту, где описаны соответствующие команды и их синтаксис.
Основные задачи
Основное назначение данной главы состоит в предоставлении пользователям, уже знакомым с работой установленных программных средств защиты, дополнительной информации об устранении нарушений в их работе или отладке.
Устранение нарушений в работе продукта CiscoSecure Scanner
Основная часть (75%) проблем, возникающих при эксплуатации программы CiscoSecure Scanner (NetSonar), связана с лицензированием. Проблемы лицензирования уже приняты к рассмотрению, и ситуация изменится со следующим выпуском.
В табл. 25.1 описаны остальные 25% наиболее распространенных проблем.
1 Таблица 25.1. Основные проблемы, возникающие в процессе. , с , ; -эксплуатации программы NetSonar , ,,
Признак неисправности
Проблема
Решение
В HTML-броузере не обна-
В программе NetSonar не за-
Проверьте вкладку HTML
руживаются следующие ком-
дан правильный путь к бро-
Browser на вкладке Prefer-
поненты NetSonar: report, grid, chart и NSDB
Узеру
ences и убедитесь в том, что путь к программе броузера задан правильно
Получено следующее сооб-
Недействительная лицензия
Убедитесь в том, что имеется
щение об ошибке: "Not
NetSonar или некорректно
действительный файл лицеи-
enough room for axis.”
заданные пользовательские правила
зии. Проверьте файл user.rules и определите, все ли введенные в него правила имеют правильную синтаксическую структуру
Сервер запускается, а кли-
Программа NetRanger экс-
Обязательно останавливайте
ент — нет
плуатируется на том же компьютере, что и программа NetSonar
работу программы NetRanger перед выполнением любых сканирований или проверок с помощью программы NetSonar
Пользователь со своего компь-
Пользователь работает за ком-
Просматривать результаты
ютера не может просматривать
пьютером, отличным от того,
сканирования и проверять
данные, полученные програм-
на котором установлена про-
данные можно только на том
мой NetSonar после запланиро-
грамма NetSonar и с которого
компьютере, где установлена
ванного сканирования
выполнялось сканирование
программа NetSonar и с которого выполнялось сканирование или проверка
Признак неисправности
ПроблемаРешение
Неожиданно возникает ситуация, при которой пользователю разрешается сканировать только один хост
Истек срок лицензии илиЕсли у вас имеется только
лицензия стала недействи-лицензия на пробную вертельной. Программасию, перейдите по адресу
NetSonar перешла к исполь-www.cisco.com/go/netsonar-
зованию первоначальной ли-eval, чтобы обновить ее, или
цензии на демонстрацион-обратитесь к коммерческому
ную версиюпредставителю для приобре
тения полной лицензии
Графический интерфейс пользователя NetSonar был закрыт, а после его повторного открытия работа программы NetSonar оказалась нарушенной
Остался открытым один изОбязательно закрывайте все
броузеров NetSonarброузеры NetSonar перед вы
ходом из программы NetSonar
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco
Прежде чем обратиться в центр Cisco ТАС Systems, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе своей системы.
Кроме того, выясните и запишите следующие данные, что позволит специалистам центра Cisco ТАС быстрее предоставить вам помощь.
Версия операционной системы (Solaris или Windows NT).
Версия программы CiscoSecure Scanner.
Устранение нарушений в работе продукта CiscoSecure Intrusion Detection System (NetRanger)
Основная задача этого раздела состоит в предоставлении помощи в диагностировании проблем, которые могут возникать при эксплуатации системы CiscoSecure Intrusion Detection System (IDS). Система IDS состоит из трех модулей: Director, Sensor и Post Office. Модуль Sensor, рассматриваемый в настоящем разделе, представляет собой прибор, а не средство, которое в настоящее время поставляется в составе системы IOS. С другой стороны, Post Office — это опорная сеть связи, которая позволяет службам и хостам NetRanger обмениваться данными друг с другом. Вся связь поддерживается с помощью специализированного протокола с установлением логического соединения, позволяющего переключаться с одного альтернативного маршрута на другой для поддержки соединений типа “точка-точка”.
Команды, применяемые для устранения нарушений в работе приложения IDS
При эксплуатации системы CiscoSecure IDS можно пользоваться несколькими командами и журналами, которые являются очень полезными при устранении нарушений в работе этого программного обеспечения. В настоящем разделе приведено краткое описание каждой команды и каждого журнала с примерами, а в следующих разделах описано применение каждой команды.
При устранении нарушений в работе применяются следующие команды.
nrvers. Предназначена для определения номера версии каждого из эксплуатируемых процессов. Такая информация особенно необходима после обновления данного программного обеспечения.
netrangr?director> nrvers
Application Versions for director.rtp
postofficed v2.2.1
(release)
99/07/19-22:30
loggerd v2.2.1
(release)
99/07/19-22:31
packetd v2.2.1
(release)
99/07/19-22:44
managed v2.2.1
(release)
99/07/19-22:29
configd v2.2.1
(release)
99/07/19-22:29
sapd v2.2.1
(release)
99/07/19-22:31
fileXfer v2.2.1
(release)
99/07/19-22:36
nrstatus. Применяется для определения текущего состояния всех демонов. Эта команда отображает информацию обо всех демонах, которые в настоящее время функционируют в системе.
netrangr?director> nrstatus
netrangr 28906
1 99
Feb 05 ?
8295:01 /usr/nr/bin/nr.managed
netrangr 28921
1 0
Feb 05 ?
0:04 /usr/nr/bin/nr.configd
netrangr 28948
1 0
Feb 05 ?
0:09 /usr/nr/bin/nr.fileXferd
netrangr 28936
1 0
Feb 05 ?
0:04 /usr/nr/bin/nr.sapd
netrangr 28877
1 0
Feb 05 ?
0:29 /usr/nr/bin/nr.loggerd
netrangr 28891
1 0
Feb 05 ?
6:17 /usr/nr/bin/nr.packetd
netrangr 28217
1 0
Feb 05 ?
6:47 /usr/nr/bin/nr.postofficed
nrconns. Применяется для
: определения
соединений, сконфигурированных в на-
стоящее время, и их состояния. В выводе этой команды заслуживают внимание такие данные, как IP-адрес этого хоста, а также информация, приведенная в квадратных скобках ([]). В следующем примере строка [Established] означает, что соеди
нение находится в состоянии рабочей готовности, а строка [SynSent] показывает, что модуль Director отправил пакет модулю sensor2 и не получил ответа.
netrangrWirector> nrconns
Connection Status for director.rtp
sensor.rtp Connection 1: 171.68.120.21445000 1 [Established]
sto:0002 with Version 1
sensor2.rtp Connection 1: 171.68.120.21345000 1 [SynSent]
sto:0002 with Version 1
nrest. Эта команда аналогична команде nrconns, но показывает только установленные соединения. В выводе данной команды не отображаются какие-либо иные соединения, кроме уже установленных.
netrangr?director> nrest
Established Connections for director,rtp
sensor.rtp Connection 1: 171.68.120.21445000 1 [Established]
sto:0002 with Version 1
nrstop. Применяется для того, чтобы вынудить все демоны IDS корректно завершить свою работу.
netrangr?director> nrstop done
• nrstart. Служит для запуска всех демонов IDS. Эта команда считывает файл /usr/nr/etc/daemons и запускает все указанные в нем демоны IDS.
netrangr?director> nrstart
starting netranger services:
netrangr 16711 0 09:28:49 pts/0 0:00 /usr/nr/bin/nr.postofficed
netrangr 17811 0 09:28:51 ?0:00 /usr/nr/bin/nr.configd
netrangr 17411 0 09:28:50 ?0:00 /usr/nr/bin/nr.loggerd
netrangr 18231 0 09:28:51 pts/0 0:00 /usr/nr/bin/nr.fileXferd
netrangr 17511 0 09:28:50 ?0:00 /usr/nr/bin/nr.packetd
netrangr 17661 0 09:28:50 ?0:00 /usr/nr/bin/nr.managed
netrangr 17961 0 09:28:51 ?0:00 /usr/nr/bin/nr.sapd
netranger startup done.
Файлы журналов, применяемые для устранения нарушений в работе приложения
Ниже перечислены файлы каталога /usr/nr/etc. Эти файлы создаются при первом запуске приложения. Если такие файлы будут удалены, а затем выполнен останов и запуск приложения, то они будут снова восстановлены. Но пока эти файлы существуют, в них постоянно записывается информация. Каждый файл содержит журнал с регистрацией ошибок, возникших в процессе функционирования соответствующего демона. Например, ошибки связи регистрируются в файле errors.postoffice.
Ниже перечислены файлы, находящиеся в модуле Sensor или в измерительном приборе.
errors.fileXferd. Ошибки при передаче файлов между модулями Sensor и Director. Операции передачи файлов такого типа обычно выполняются при настройке конфигурации модуля Sensor.
errors.managed. Ошибки, возникающие при создании списка доступа в маршрутизаторе или при попытке установления связи с маршрутизатором.
errors.packetd. Ошибки, возникающие при перехвате трафика в сети.
errors.postofficed. Ошибки, возникающие в инфраструктуре связи.
errors.sapd. Ошибки, возникающие в процессе управления файлами.
Файлы в модуле Director.
errors.postofficed. Ошибки, возникающие в инфраструктуре связи.
errors.sapd. Ошибки, возникающие в процессе управления файлами. К ним относятся файлы Oracle, которые находятся во внешней памяти модуля Director.
errors.configd. Ошибки, возникающие в процессе настройки конфигурации модулей Sensor.
errors.smid. Ошибки, возникающие в модуле OpenView.
errors.eventd. Ошибки, возникающие при попытке активизировать событие. Обычно такие попытки возникают при использовании процесса опроса, но событие может быть связано с любым сценарием, который должен быть вызван на выполнение.
errors.fileXferd. Ошибки при передаче файлов между модулями Sensor и Director. Операции передачи файлов такого типа обычно выполняются при настройке конфигурации модуля Sensor.
errors.loggerd. Ошибки, возникающие при попытке регистрации данных в журнале.
errors.nrConfigure. Ошибки, возникающие при настройке конфигурации графического интерфейса пользователя.
В табл. 25.2 перечислены признаки неисправности, возможные проблемы и предлагаемые действия по устранению нарушений в работе системы CiscoSecure IDS.
Таблица 25.2. Устранение нарушении в работе программы NetRanger
Признак неисправностиПризнак неисправностиПроблемаПроблемаРешениеРешение
Признак неисправности
Признак неисправности
Проблема
Проблема
Решение
Решение
Не функционирует модуль DirectorОтображается сообщение об ошибке "Cannot write message to Director, errno =2."Не функционирует модуль DirectorОтображается сообщение об ошибке "Cannot write message to Director, errno =2."Появляется следующее сообщение об ощибке: "Cannot write message to Director, errno = 233."Появляется следующее сообщение об ощибке: "Cannot write message to Director, errno = 233."Эта ошибка возникает, если демон smid предпринимает попытку выполнить запись в несуществующий сокет. Такая ситуация может произойти в связи с тем, что приложением nrdirmap модуля Director не был создан свой сокет связи в каталоге /usr/nr/tmp, поскольку не был запущен пользовательский интерфейс HP OpenView (ovw)Это сообщение об ошибке вырабатывается, если демон smid выводит данные в сокет, буфер которого переполнен. Такая ситуация может возникнуть, если не работает приложение nrdirmap модуля DirectorЭта ошибка возникает, если демон smid предпринимает попытку выполнить запись в несуществующий сокет. Такая ситуация может произойти в связи с тем, что приложением nrdirmap модуля Director не был создан свой сокет связи в каталоге /usr/nr/tmp, поскольку не был запущен пользовательский интерфейс HP OpenView (ovw)Это сообщение об ошибке вырабатывается, если демон smid выводит данные в сокет, буфер которого переполнен. Такая ситуация может возникнуть, если не работает приложение nrdirmap модуля DirectorВначале следует убедиться в том, что функционируют соответствующие службы NetRanger, такие как postofficed и smid; для этого необходимо в командной строке ввести команду nrstatus. Если эти службы не функционируют, введите команду nrstart, чтобы запустить их вручную. Затем вызовите на выполнение программу HP OpenView, введя команду ovw & в командной строке Обязательно вызывайте на выполнение пользовательский интерфейс HP OpenView (ovw), вводя команду ovw s. При этом автоматически происходит запуск программы nrdirmapВначале следует убедиться в том, что функционируют соответствующие службы NetRanger, такие как postofficed и smid; для этого необходимо в командной строке ввести команду nrstatus. Если эти службы не функционируют, введите команду nrstart, чтобы запустить их вручную. Затем вызовите на выполнение программу HP OpenView, введя команду ovw & в командной строке Обязательно вызывайте на выполнение пользовательский интерфейс HP OpenView (ovw), вводя команду ovw s. При этом автоматически происходит запуск программы nrdirmap
Не функционирует модуль Director
Отображается сообщение об ошибке "Cannot write message to Director, errno =2."
Не функционирует модуль Director
Отображается сообщение об ошибке "Cannot write message to Director, errno =2."
Появляется следующее сообщение об ощибке: "Cannot write message to Director, errno = 233."
Появляется следующее сообщение об ощибке: "Cannot write message to Director, errno = 233."
Эта ошибка возникает, если демон smid предпринимает попытку выполнить запись в несуществующий сокет. Такая ситуация может произойти в связи с тем, что приложением nrdirmap модуля Director не был создан свой сокет связи в каталоге /usr/nr/tmp, поскольку не был запущен пользовательский интерфейс HP OpenView (ovw)
Это сообщение об ошибке вырабатывается, если демон smid выводит данные в сокет, буфер которого переполнен. Такая ситуация может возникнуть, если не работает приложение nrdirmap модуля Director
Эта ошибка возникает, если демон smid предпринимает попытку выполнить запись в несуществующий сокет. Такая ситуация может произойти в связи с тем, что приложением nrdirmap модуля Director не был создан свой сокет связи в каталоге /usr/nr/tmp, поскольку не был запущен пользовательский интерфейс HP OpenView (ovw)
Это сообщение об ошибке вырабатывается, если демон smid выводит данные в сокет, буфер которого переполнен. Такая ситуация может возникнуть, если не работает приложение nrdirmap модуля Director
Вначале следует убедиться в том, что функционируют соответствующие службы NetRanger, такие как postofficed и smid; для этого необходимо в командной строке ввести команду nrstatus. Если эти службы не функционируют, введите команду nrstart, чтобы запустить их вручную. Затем вызовите на выполнение программу HP OpenView, введя команду ovw & в командной строке Обязательно вызывайте на выполнение пользовательский интерфейс HP OpenView (ovw), вводя команду ovw s. При этом автоматически происходит запуск программы nrdirmap
Вначале следует убедиться в том, что функционируют соответствующие службы NetRanger, такие как postofficed и smid; для этого необходимо в командной строке ввести команду nrstatus. Если эти службы не функционируют, введите команду nrstart, чтобы запустить их вручную. Затем вызовите на выполнение программу HP OpenView, введя команду ovw & в командной строке Обязательно вызывайте на выполнение пользовательский интерфейс HP OpenView (ovw), вводя команду ovw s. При этом автоматически происходит запуск программы nrdirmap
Признак неисправности
Проблема
Решение
Появляется следующее со-
Это сообщение об ошибке
Убедитесь в том, что процесс
общение об ошибке: "Cannot
возникает, если программы
smid принадлежит пользова-
write message to Director,
smid и nrdirmap не имеют со-
телю netrangr и что про-
errno = 239."
ответствующих прав на обмен данными через сокеты, находящиеся в каталоге /usr/nr/tmp
грамма nrdirmap работает под идентификатором SUID netrangr
Появляется следующее co-
Переменная среды
Выполните указания, приве-
общение об ошибке:
LD LIBRARY PATH в операцион-
денные в разделе документа-
"nrdirmap: fatal:
ной среде не установлена
ции Installation and
libovw.so.l: can't open file:
должным образом. Это мо-
Configuration, чтобы выпол-
errno=2."
жет означать, что пользователь зарегистрировался на платформе Director в неправильной учетной записи
нить настройку среды HP OpenView на применение учетных записей пользователей, отличных от netrangr.
Если учетная запись пользователя предназначена для командного интерпретатора Bourne или Korn, то в файле пользователя $НОМЕ/.profile должны присутствовать следующие строки: if [ -d /opt/OV ] ; then
/opt/OV/bin/ov.enwars.sh PATH=$OV_BIN:$PATH export PATH
LD_LIBRARY_PATH=$OV_LIB: $ ED _LIBRARY_PATH
export LD_LIBRARY_PATH
fi
Если пользователь должен применять командный интерпретатор, отличный от ksh, то приведенные выше строки необходимо перевести на соответствующий язык сценариев и поместить в соответствующий файл запуска
Функционирует модуль Director
В схеме защиты модуля Director содержится пиктограмма модуля Sensor, но не отображаются какие-либо события, относящиеся к этому модулю Sensor
Атрибутам Severity Status модуля Director присвоены более высокие значения по сравнению со значениями уровней аварийных сигналов, вырабатываемых модулем Sensor
В схеме защиты модуля Director содержится пиктограмма модуля Sensor, но не отображаются какие-либо события, относящиеся к этому модулю Sensor
Снизился уровень аварийных сигналов, активизируемых системой Sensor, и стал ниже порога маршрутизации, установленного в файле /usr/nr/etc/destinations
Появляется следующее сообщение об ошибке: "Application AppId.Hostld.Orgld has reached maximum number of alarms."
Для приложения, указанного в этом сообщении об ошибке, в соответствующей дочерней подсхеме зашиты HP OpenView уже представлено 1000 пиктограмм аварийных сигналов. Модуль Director не создает свыше 1000 пиктограмм в подсхеме (окне), поскольку после этого поведение приложения HP OpenView может стать непредсказуемым
В интерфейсе модуля Director подсветите пиктограмму для системы Sensor, а затем либо нажмите клавиши <Ctrl+O>, либо выберите команду Describe/Modify в меню Edit. Затем выберите элемент NetRanger/Director и щелкните на пункте View/Modify. Убедитесь в том, что пороговые уровни состояний Minimum Marginal и Minimum Critical имеют достаточно низкие значения для того, чтобы выполнялась регистрация событий, активизируемых рассматриваемым модулем Sensor Если пороговые значения атрибутов Severity Status модуля Director установлены правильно, убедитесь в том, что в файле /usr/nr/etc/destinations модуля Sensor задан достаточно низкий порог маршрутизации для того, чтобы обеспечивалась маршрутизация информации, передаваемой в модуль Director Удалите пиктограммы аварийных сигналов в переполненной подсхеме. Модуль Director возобновит создание пиктограмм аварийных сигналов в подсхеме при активизации любых новых событий.
Для просмотра пиктограммных представлений событий, информация о которых была преобразована приложением nrdirmap в файлы каталога /usr/nr/var, удалите пиктограммы в схеме, а затем остановите и перезапустите пользовательский интерфейс.
Служба loggerd модуля Director не указана в качестве получателя в файлах конфигурации модулей Sensor и DirectorСлужба loggerd модуля Director не указана в качестве получателя в файлах конфигурации модулей Sensor и DirectorУтилита обработки текущих событий продолжает выбирать информацию из журналов Director до тех пор, пока окно находится в рабочем состоянииУтилита обработки текущих событий продолжает выбирать информацию из журналов Director до тех пор, пока окно находится в рабочем состоянииСлужбы модуля Sensor не функционируют должным образомСлужбы модуля Sensor не функционируют должным образомПредпринимается попытка вызвать эти утилиты на выполнение из учетной записи, не имеющей прав доступа к демонам модуля SensorПредпринимается попытка вызвать эти утилиты на выполнение из учетной записи, не имеющей прав доступа к демонам модуля Sensor
Служба loggerd модуля Director не указана в качестве получателя в файлах конфигурации модулей Sensor и Director
Служба loggerd модуля Director не указана в качестве получателя в файлах конфигурации модулей Sensor и Director
Утилита обработки текущих событий продолжает выбирать информацию из журналов Director до тех пор, пока окно находится в рабочем состоянии
Утилита обработки текущих событий продолжает выбирать информацию из журналов Director до тех пор, пока окно находится в рабочем состоянии
Службы модуля Sensor не функционируют должным образом
Службы модуля Sensor не функционируют должным образом
Предпринимается попытка вызвать эти утилиты на выполнение из учетной записи, не имеющей прав доступа к демонам модуля Sensor
Предпринимается попытка вызвать эти утилиты на выполнение из учетной записи, не имеющей прав доступа к демонам модуля Sensor
Аварийные сигналы модуля Sensor отображаются в схеме защиты Director должным образом, но информация об этих аварийных сигналах не появляется в окне Show Current Events, а файл журнала событий в каталоге /usr/nr/var модуля Director не содержит каких-либо записей, полученных от рассматриваемого модуля Sensor
Информация отображается в окне Director Show Current Events правильно, но курсор принимает вид песочных часов и больше не изменяется
Обеспечение связи
Не может быть получен доступ к модулю Sensor или к какой-либо из служб NetRanger, работающих в системе
Модуль Sensor
Процессы демонов NetRanger не могут быть запущены или остановлены путем вызова на выполнение программы nrstart или nrstop
Примечание. Модуль Director сохраняет все дополнительные данные аварийных сигналов для рассматриваемого приложения в файле nrdirmap.buffer.ovw_map_name, находящемся в каталоге /usr/nr/var, где ovw_map_name — имя схемы ovw
Вызовите на выполнение программу nrConfigure, чтобы создать запись в файле /usr/nr/etc/destinations модуля Sensor для данной службы loggerd модуля Director, или создайте запись DupDestination в файле /usr/nr/etc/smid.conf модуля Director для перенаправления данных о событиях от демона smid к демону loggerd Щелкните на кнопке Stop, чтобы завершить работу этого фильтрующего приложения. После этого появится возможность использовать линейки прокрутки и опции меню для просмотра данных. Щелкните на кнопке Close, чтобы выйти из этого окна
Откройте соединение Telnet с модулем Sensor и вызовите на выполнение программу nrstop. Изучите файлы ошибок в каталоге /usr/nr/var. Перезапустите модуль Sensor, введя команду nrstart
Убедитесь в том, что регистрация в системах Sensor или Director была выполнена под теми же учетными записями, которые использовались для запуска демонов их служб. (По умолчанию применяется учетная запись netrangr.)
База данных Oracle
Невозможно определить, установлена ли база данных Oracle
Невозможно определить, работает ли программное обеспечение Oracle
Инсталлятор Oracle (orainst) не может найти какие-либо программные продукты, предназначенные для установки
Отображается одно из следующих сообщений: "sqlplus: not found" "sqlldr: not found”
При попытке вызвать на выполнение программу sqlplus отображается следующее сообщение об ошибке:
" /oracle/product/7.3.2/bin /sqlplus: cannot open.”
Работа программ sqlplus, sqlldr или sapx завершается аварийно со следующим сообщением об ошибке SID: “ERROR: ORA-01034: ORACLE not available”
"ORA-07200: slsid: oracle_sid not set”
Перед запуском программы orainst не был выполнен сценарий start.sh
Каталог bin базы данных Oracle не указан или не задан должным образом в переменной среды $РАТН
Командный интерпретатор находит программу sqlplus, но не может вызвать ее на выполнение. Такая ситуация может возникнуть, если переменная среды $РАТН включает ссылки на неправильные версии программ Oracle. Например, на файловом сервере были смонтированы неправильные каталоги Oracle. Поэтому, допустим, предпринимаются попытки вызвать на выполнение программы HPUX в системе SPARC
Переменная среды ORACLE_SID, которая указывает применяемый экземпляр базы данных, не была определена должным образом перед запуском программы sqlplus
Проверьте локальные и дистанционно смонтированные файловые системы с помощью команд df, mount н find. Найдите каталоги oracle и product/ Введите команду ps -ef | grep ora в командной строке, чтобы проверить, работает ли программное обеспечение Oracle Вызовите на выполнение сценарий /cdrom/cdromO/orainst/start.s h, чтобы подготовить конкретную среду для работы с программой orainst Выполните настройку переменной среды $РАТН, чтобы включить в нее ссылку на каталог $ORACLE_HOME/bin
Убедитесь в том, что каталог $ORACLE_HOME содержит программы, предназначенные для применяемой платформы. Обратитесь к разделу Installing an Oracle RDBMS в документе RDBMS Reference
Откорректируйте значение переменной среды ORACLE_SID, присвоив ей имя экземпляра базы данных. Имя экземпляра базы данных можно узнать, выполнив команду ps -ef | grep ora. Строка, находящаяся за последним символом подчеркивания в возвращенном тексте, представляет собой имя экземпляра базы данных
Признак неисправности
ПроблемаРешение
Работа программ sqlplus, sqlldr или sapx завершается аварийно со следующим сообщением об ошибке libc:
В переменной средыВведите ссылку на каталог
LD_LIBRARY_PATH не задана$ORACLE_HOME/lib в состав пе-
ссылка на каталогременной среды
$ORACLE_HOME/libLD_LIBRARY_PATH. Если приме-
"libc.so.xxx: can't do something"
няется командный интерпретатор Bourne или Korn, убедитесь в том, что файл $ВОМЕ/. profile содержит следующие записи:
LD_LIBRARY_PATH=$LD_LIBRAR Y_PATH:$0КАСЬЕ_Н0Ме711Ь export LD_LIBRARAY_PATH
Работа программ sqlplus, sqlldr или sapx завершается аварийно со следующим сообщением об ошибке TNS:
Программное обеспечениеУбедитесь в том, что файл
Oracle не может распознатьtnsnames.ora базы данных
имя, указанное в строке под- Oracle находится в соответст- ключениявующем каталоге (как прави-
"ERROR: ORA-12154: TNS: could not resolve service name”
ло, таковым является каталог $ORACLE_HOME/admin/network) и имеет правильный формат. Затем вызовите на выполнение утилиту tnsping для проверки связи с удаленной базой данных по протоколу sqlnet
Приложение sqlplus, sqlldr или sapx возвращает сообщение об ошибке TNS или USER/PASSWORD
Неправильная строка под-Проверьте синтаксическую
ключенияструктуру строки подключе
ния. Если пароль задается в командной строке, вводите его в формате sqlplus user/passwordtoost.
В ином случае вводите команду sqlplus user@host, после чего программа sqlplus будет запрашивать пароль
Пакет управления данными Проверка показывает, что конфигурация является правильной, но никакие действия не выполняются
Если в файле sapd.conf от-Скопируйте вручную файл
сутствуют элементыsapd.conf .nsx или
FM_Action, это означает, чтоsapd.conf .director из каталога
процедурой инсталляции не/usr/nr/etc/wgc/templates в ка-
были скопированы должным талог /usr/nr/etc/, переимено- образом файлы для создания дав его в файл sapd.conf. файла sapd.conf, поскольку происходит переход с версии NetRanger 1.2.x на версию 1.3.x или 2.x
Признак неисправности
Проблема
Решение
В структуре каталога
Выполнена модернизация
Примечание. Файл /usr/nr/etc/wgc/templates/sap d.conf содержит описания лексем, применяемых демоном sapd, но не включает каких-либо действительных значений лексем. Он предназначен для использования в качестве эталона при установке опций trigger в файле sapd.conf каталога /usr/nr/etc
Уничтожьте посторонние
/usr/nr/var имеются посто-
программного обеспечения с
файлы, удалите каталог
ронние файлы и существует
переходом от версии
/usr/nr/var/old и архивируй-
каталог /usr/nr/var/old
NetRanger 1.2.x на версию
те каталог /usr/nr/var/dump
Запросы SQL не отображают
1.3.x или 2.x, в результате чего был уничтожен каталог /usr/nr/var/old. После этой модернизации осталось также много файлов в каталоге /usr/nr/var
Не был введен знак процента
Используйте в запросах SQL
данные
(%) в качестве подстановоч-
знак процента (%) в качестве
При вводе команд @event1,
ного символа
Применяется неправильный
подстановочного символа В версии SAP 1.3.x требуется,
@spacel, @timel или @systeml в
параметр командной строки
чтобы команды были введе-
приглашении к вводу команд SQLPLUS не могут быть получены соответствующие данные
При вводе запросов не ото-
Была проведена модерниза-
ны в форме @event, @space, Stime или ^system. После этого появится приглашение к вводу значения желаемого уровня детализации (например, 1, 2 или 3) Обновите структуру таблицы
бражаются новые сигнатуры
ция с переходом от версии
nr^sigs с помощью сценария
событий
NetRanger 1.2.x к версии
/usr/nr/etc/signatures, а
Проверка показывает, что
1.3.x или 2.x без обновления структуры таблиц nr_orgs и nr_sigs
Средство nailx не может
структуру таблицы nr_orgs с помощью сценария /usr/nr/etc/organizations. Для этой цели применяется код в конце сценария nrdb_master_create
Чтобы убедиться в том, что
передача извещений проис-
быть вызвано через интер-
почта может быть отправ-
ходит успешно, но фактиче-
фейс командной строки
лена из командной строки,
ски почтовые извещения не отправляются
воспользуйтесь утилитой mailx для отправки письма по электронной почте самому себе.
Признак неисправности
ПроблемаРешение
Работа загрузчика базы данных sapx завершается аварийно с сообщением об ошибке, связанным с JDBC (ORA-1461)
Если почта не отправляется, выполните настройку имени домена, введя команду domainname your_domain_name в командной строке (в системе Solaris имя домена можно ввести в файл /etc/defaultdomain). Затем дополните файл /etc/hosts, введя в него информацию о почтовом сервере в следующем формате: ip_address server_name mailhost, где IP_address — это IP-адрес почтового сервера, а server_name — имя его сервера DNS
Применяется сервер базыЧтобы исключить возмож-
данных NT Oracle 8ность возникновения этой
ошибки, можно воспользоваться одним из следующих трех методов.
Обойтись без применения по умолчанию загрузчика sapx с использованием альтернативных шаблонов загрузкивфайле
/usr/nr/bin/sap/sql/skel.
Применить для системы UNIX сервер Oracle 7 или Oracle 8. Корпорацией Cisco была выполнена успешная проверка программного обеспечения сервера в системах Solaris Sparc, х86, HP-UX и AIX.
Модернизировать программное обеспечение, перейдя с версии NT Oracle 8.0.4.0.0 на версию 8.O.4.O.4. В результате такой модернизации нарушения в работе интерфейса JDBC должны быть устранены, но подобная проверка корпорацией Cisco еще не проведена
Признак неисправности
Проблема
Решение
Утилита nrConfigure
Во время первоначального запуска утилита nrConfigure вызывает дамп ядра Проблемы производительности в системе HP-UX
На некоторых компьютерах HP версии утилиты nrConfigure для системы HP- UX работают медленно
Проблемы при передаче файлов
При передаче файлов между модулями Sensor и Director иногда появляется следующее сообщение об ошибке: "Error transferring file from source_file to destination_file."
В системе HP-UX отсутствует надежный JIT-компилятор Java. Такая проблема производительности может иногда привести к полной дезорганизации работы, поскольку пользовательский интерфейс реагирует медленно и пользователи инициализируют одни и те же операции несколько раз, думая, что команда на их выполнение не была получена системой. Причем непредсказуемое поведение утилиты nrConfigure могут вызвать, например, даже быстрые последовательные щелчки мышью. Еше одним характерным примером является просмотр на консоли сообщений об ошибках Java с прокруткой изображения, при котором может произойти аварийное завершение работы экранного интерфейса Java
Ошибки при передаче файлов между модулями Sensor и Director время от времени могут появляться. Но если такие ошибки возникают слишком часто, то имеет место нарушение в работе демона fileXferd
Перезапустите утилиту nrConfigure. Теперь ее запуск должен пройти без ошибок
Попытайтесь повторно выполнить все предыдущие действия. В большинстве случаев вторая или третья попытка оказывается успешной
Чтобы убедиться в том, что связь между модулями имеется, вызовите на выполнение команды nrstatus и nrvers и в модуле Sensor, и в модуле Director. В выводе обеих команд, nrvers и nrstatus, должно быть указано, что демон fileXferd работает. Если вывод одной из команд показывает, что демон fileXferd не функционирует (например, информация о нем отсутствует в списке процессов), вызовите на выполнение команды nrstop и nrstart в модулях Sensor и Director.
Решение
Если демон fileXferd функционирует, то еше одна причина нарушения в работе может состоять в том, что в базах данных nrConfigure неправильно указаны права доступа к файлам.
Чтобы проверить права владения базами данных nrConfigure, можно вызвать на выполнение следующую команду в модуле Director: Is -1
/usr/nr/var/nrConfigure
Если же владельцем каких-либо подкаталогов является пользователь root, выполните следующие действия.
Шаг 1. Воспользуйтесь командой su, чтобы перейти в учетную запись пользователя root.
Шаг 2. Введите следующую команду: rm -rf /usr/nr/var/ nrConfigure
Шаг 3. Воспользуйтесь командой su, чтобы перейти в учетную запись пользователя netrangr.
Шаг 4. Откройте интерфейсную программу модуля Director с помощью команды ovw s.
Шаг 5. Выберите команды Advanced ^nrConfigure DB^Create в меню Security. Если ни один из подкаталогов не принадлежит пользователю root, выполните следующие действия.
Шаг 1. Откройте интерфейсную программу модуля Director с помощью команды ovw S.
Признак неисправности
ПроблемаРешение
При запуске модуля NSDB или интерактивной справки запускается новая копия броузера HTML, а не обновляется существующее окно броузера HTML
Предостережение. Прежде чем перейти к следующим действиям проследите за тем, чтобы не была выбрана ни одна пиктограмма компьютера. Если выбраны какие-либо пиктограммы компьютеров, то утилита nrConfigure удаляет и создает базы данных только на выбранных компьютерах.
Шаг 2. Выберите команды Advanced^nrConfigure DB^Delete в меню Security.
Шаг 3. Выберите команды Advanced^nrConfigure DB^Create в меню Security.
Еще одна проблема может возникнуть, если вы ответите "по" на вопрос утилиты nrConfigure, нужно ли загрузить новейшие файлы конфигурации. Для решения этой проблемы необходимо удалить, а затем создать новые базы данных nrConfigure, как было описано выше
Если применяется программа Netscape, то может быть выполнена настройка конфигурации NetRanger на загрузку всех HTML-страниц в одно окно броузера. Для этого выполните следующие действия.
Шаг 1. Откройте файл /usr/nr/ etc/nrConfigure.conf в текстовом редакторе.
Шаг 2. Откорректируйте лексему Browser, указав в ней следующее значение:
Browser=/usr/nr/bin/direct or/nrSingleBrowser
Признак неисправности ПроблемаРешение
Шаг 3. Откорректируйте лексему NetscapeLocation, указав в ней следующее значение:
NetscapeLocation=/opt/nets cape/netscape
Сохраните изменения и закройте сеанс редактирования
Подготовка необходимой информации перед обращением в центр технической поддержки Cisco
Прежде чем обратиться в центр Cisco ТАС, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе своей системы.
Кроме того, выясните и запишите следующие данные, что позволит специалистам центра Cisco ТАС быстрее предоставить вам помошь.
Определите версии каждого демона. Воспользуйтесь командой nrvers.
Определите версии операционных систем, установленных во всех устройствах. Это особенно важно при устранении нарушений в работе модуля Director.
Выполните сжатие файлов в каталоге /usr/nr/etc и файлов с журналами ошибок в каталоге /usr/nr/var.
Устранение нарушений в работе брандмауэра PIX Firewall
Прежде чем приступить к устранению нарушений в работе брандмауэра PIX Firewall, необходимо проанализировать предстоящие задачи. Ниже приведен примерный перечень задач, а затем рассматриваются решения возможных проблем, коды ошибок и команды отладки. Признаки неисправностей и предлагаемые решения перечислены в табл. 25.3. Приведенные здесь коды ошибок и их определения должны позволить успешно интерпретировать ошибки, обнаруженных в различных журналах. Здесь также перечислены команды отладки и приведены примеры их использования.
Поиск истинной причины нарушения в работе
Брандмауэр Р1Х применяется в качестве шлюза для выхода из локальной сети в Internet, и обычно именно его считают основной причиной неисправностей, если пользователь не может выйти в Internet. Безусловно, брандмауэр PIX может быть причиной возникновения проблем, но нарушения в работе могут также возникнуть во многих других модулях. Ниже приведен перечень других возможных причин неисправностей с указанием краткого контрольного списка.
Хост-компьютер пользователя.
Можно ли выполнить с этого хост-компьютера эхо-тестирование каких-либо других компьютеров во внутренней сети?
Правильно ли назначен шлюз, применяемый по умолчанию?
Можно ли выполнить с хост-компьютера эхо-тестирование внутреннего интерфейса брандмауэра PIX?
Защищенный внутренний маршрутизатор.
Можно ли выполнить с этого маршрутизатора эхо-тестирование внутреннего интерфейса брандмауэра PIX?
Можно ли выполнить с этого маршрутизатора эхо-тестирование хоста пользователя?
Можно ли обратиться с этого маршрутизатора к какому-либо объекту во внешней сети?
Брандмауэр PIX.
Можно ли выполнить с брандмауэра PIX эхо-тестирование внешнего маршрутизатора?
Можно ли с брандмауэра PIX обратиться к внешнему узлу, находящемуся за внешним маршрутизатором?
Определен ли адрес хоста в команде nat?
Определено ли достаточное количество адресов для всех внутренних хостов в глобальном пуле?
Незащищенный внешний маршрутизатор.
Можно выйти в Internet с внешнего маршрутизатора?
Получает ли внешний маршрутизатор пакеты, передаваемые из брандмауэра PIX?
' Очевидно, что при устранении нарушений в работе брандмауэра PIX Firewall приходится также учитывать много других факторов.
Команды debug
При устранении нарушений в работе брандмауэра PIX Firewall могут применяться следующие команды.
show debug. Позволяет узнать, включена ли отладка.
show debug.
debug icmp trace off.
debug packet off.
debug sqlnet off.
debug icmp trace. При эхо-тестировании хоста с брандмауэра PIX Firewall через любой интерфейс на консоли отображается вывод трассировки. В следующем примере показаны результаты успешного выполнения эхо-тестирования внешнего интерфейса (200.200.200.1) брандмауэра PIX Firewall с внешнего хоста (192.150.50.42),
router# debug icmp trace
Inbound ICMP echo reply (len 32 id 1 seq 256) 192.150.50.1 > 192.150.50.42 Outbound ICMP echo request (len 32 id 1 seq 512) 192.150.50.42 > 192.150.50.1 Inbound ICMP echo reply (len 32 id 1 seq 512) 192.150.50.1 > 192.150.50.42 Outbound ICMP echo request (len 32 id 1 seq 768) 192.150.50.42 > 192.150.50.1 Inbound ICMP echo reply (len 32 id 1 seq 768) 192.150.50.1 > 192.150.50.42 Outbound ICMP echo request (len 32 id 1 seq 1024) 192.150.50.42 > 192.150.50.1 Inbound ICMP echo reply (len 32 id 1 seq 1024) 192.150.50.1 > 192.150.50.42
debug packet if_name. Применяется при отладке для контроля за содержимым пакетов. В следующем примере показана информация, которая имеется в пакете: router# debug packet inside PACKET
— IP —
==>255.3.2.1
ver = 0x4
hlen = 0x5
tos = 0x0tlen = 0x60
id = 0x3902
flags = 0x0
frag off=0x0
ttl = 0x20
proto=0xll
chksum = 0x5885
—UDP —
source
port = 0x89
dest port = 0x89
len = 0x4c checksum = ОхабаО
—DATA —
00000014:00 01 00 001
00000024: 00 00 00 01 20 45 49 45 50 45 47 45 47 45 46 46| ..
.. EIEPEGEGEFF
00000034: 43 43 4e 46 41 45 44 43 41 43 41 43 41 43 41 43| CC NFAEDCACACACAC
00000044: 41 43 41 41 41 00 00 20 00 01 CO 0c 00 20 00 01| AC
AAA
00000054: 00 04 93 eO 00 06 60 00 01 02 03 04 00| ..
...Л0
END of packet
debug packet if_name [src source_ip [netmask mask]] [dst dest_ip [netmask mask]] [[proto icmp] | [proto tcp [sport src_port] [dport dest_port]] | [proto udp [sport src_port] [dport dest_port]] [rx|tx|both]. Применяется для просмотра содержимого пакетов, проходящих от указанного отправителя к указанному получателю.
Описание синтаксиса
if_name. Имя интерфейса, из которого поступают пакеты; например, для просмотра пакетов, поступающих в брандмауэр FIX Firewall извне, установите в качестве значения параметра if_name строку outside.
src source_ip. IP-адрес отправителя.
netmask mask. Маска сети.
dst dest_ip. IP-адрес получателя.
proto icmp. Отображать только содержимое пакетов ICMP.
proto top. Отображать только содержимое пакетов TCP.
sport src_port. Порт отправителя.
dport dest_port. Порт получателя.
proto udp. Отображать только содержимое пакетов UDP.
гх. Отображать только содержимое пакетов, полученных брандмауэром PIX Firewall.
tx. Отображать только содержимое пакетов, переданных брандмауэром PIX Firewall.
both. Отображать содержимое и полученных, и переданных пакетов.
В следующем примере показано, как просмотреть содержимое пакетов tcp с адресом отправителя 200.200.200.20 и адресом получателя 100.100.100.10, проходящих через порт 25:
debug packet outside src 200.200.200.20 dst 100.100.100.10 proto tcp dport 25 both
Примечание
Вызов на выполнение команды debug packet в брандмауэре FIX Firewall, испытывающем тяжелую нагрузку, может вызвать настолько быстрый вывод ее результатов, что его нельзя будет остановить путем ввода команды no debug packet с консоли. В таком случае можно ввести команду no debug packet в сеансе Telnet.
Дополнительные сведения о командах debug
Теперь команда debug icmp trace направляет свой вывод в канал трассировки Trace Channel. Местонахождение канала Trace Channel зависит от того, открыт ли сеанс консоли по протоколу Telnet одновременно с текущим сеансом консоли, или применяется только последовательная консоль PIX Firewall.
Если используется только последовательная консоль PIX Firewall, то весь вывод команд debug отображается на последовательной консоли.
Если же одновременно открыт и сеанс последовательной консоли, и сеанс консоли по протоколу Telnet с доступом к данной консоли, то независимо от того, где введена команда debug icmp trace или debug sqlnet, ее вывод отображается в сеансе консоли по протоколу Telnet.
Если открыто несколько сеансов консоли по протоколу Telnet, то первым сеансом является сеанс канала Trace Channel. А если этот сеанс закрывается, то каналом Trace Channel становится сеанс последовательной консоли. Но следующий сеанс консоли по протоколу Telnet, который обращается к этой консоли, снова становится каналом Trace Channel.
Вывод команды debug packet отображается только на последовательной консоли. Но применение этой команды можно разрешить или запретить и с последовательной консоли, и в сеансах консоли по протоколу Telnet.
Во всех сеансах по протоколу Telnet и в сеансе последовательной консоли обеспечивается совместный доступ к командам debug.
Примечание
Недостатком средства Trace Channel является то, что при использовании одним администратором последовательной консоли и запуске другим администратором сеанса консоли по протоколу Telnet вывод команд debug icmp trace и debug sqlnet на последовательную консоль внезапно прекращается без предупреждения. Кроме того, перед глазами администратора, работающего в сеансе консоли по протоколу Telnet, внезапно появляется вывод команды debug, что может оказаться для него неожиданным. Если вы работаете с последовательной консолью и не видите вывода команды debug, вызовите на выполнение команду who, чтобы определить, не открыт ли кем-либо иным сеанс консоли по протоколу Telnet.
Примечание
Чтобы пользователи могли выполнять эхо-тестирование через брандмауэр FIX Firewall, введите в конфигурацию команду conduit permit icmp any. Эта команда разрешает прохождение запросов эхо-тестирования извне и изнутри.
Этапы поиска неисправностей
В первом примере рассматривается пользователь внутренней сети, который не может получить доступ к Internet. Ниже описаны рекомендуемые этапы устранения этого нарушения в работе, но следует учитывать, что они не позволяют решить все проблемы такого рода.
Шаг 1. Перейдите на компьютер конечного пользователя и выполните эхо- тестирование внутреннего интерфейса брандмауэра PIX. Если ответ получен, перейдите к следующему шагу. Если ответ не получен, то попытайтесь найти решение, выполнив следующие проверки.
Пользователь не может выполнить эхо-тестирование ни одного внутреннего адреса. Проверьте интерфейсную плату на компьютере пользователя.
Пользователь может выполнить эхо-тестирование других хостов в той же сети, но не может выполнить эхо-тестирование брандмауэра PIX. Такая ситуация может возникнуть, если между хостом пользователя и брандмауэром PIX находится маршрутизатор. Выполните следующие проверки:
определите, какой маршрут применяется по умолчанию на хосте пользователя;
проверьте применяемый по умолчанию или статический маршрут во внутреннем маршрутизаторе. Убедитесь в том, что настройка конфигурации внутреннего маршрутизатора выполнена так, чтобы он маршрутизировал трафик в обоих направлениях.
• Невозможно выполнить эхо-тестирование хоста пользователя с брандмауэра PIX. Если эти два устройства находятся в разных сетях, проверьте внутренний маршрутизатор. А если брандмауэр PIX может выполнить эхо- тестирование только внутреннего маршрутизатора, но не расположенных за ним хостов, убедитесь в том, что в брандмауэре PIX имеется информация о том, как перейти к этой подсети, следующим образом:
проверьте применяемый по умолчанию внутренний маршрут в брандмауэре Р1Х. В следующем примере в качестве применяемого по умолчанию маршрута задано значение 100.100.100.2:
Route inside 0.0.0.0 0.0.0.0 100.100.100.2 1
Route inside 0.0.0.0 0.0.0.0 100.100.100.2 1
проверьте таблицу маршрутизации во внутреннем маршрутизаторе, чтобы удостовериться, что во внутреннем маршрутизаторе имеется информация о том, как следует правильно маршрутизировать пакеты.
Шаг 2. В брандмауэре Р1Х разрешите применение команды debug icmp trace.
Разрешите прохождение трафика ICMP через брандмауэр PIX. Для этого введите следующую команду: conduit permit icmp any any
Примечание
Вызов на выполнение команды debug packet в брандмауэре FIX Firewall, испытывающем тяжелую нагрузку, может вызвать настолько быстрый вывод ее результатов, что его нельзя будет остановить путем ввода команды no debug packet с консоли. В таком случае можно ввести команду по debug packet в сеансе Telnet.
Теперь определите, имеет ли хост пользователя оттранслированный адрес. Для этого применяется следующая команда: show xlate local ip_address
Если имеется оттранслированный адрес, его необходимо очистить. Для этого воспользуйтесь следующей командой:
clear xlate local ip address
Шаг 3. Попытайтесь обратиться к Web-узлу с хоста пользователя.
Шаг 4. Проверьте таблицу трансляции, чтобы убедиться в том, что в ней имеется строка, обеспечивающая трансляцию адресов для хоста пользователя. Воспользуйтесь командой, приведенной в шаге 2.
Шаг 5. Если такая строка не предусмотрена, выполните с хоста пользователя эхо- тестирование внешней системы, а затем проверьте, появится ли вывод команды debug. Если вывод этой команды не будет обнаружен, это означает, что пакет запроса эхо-тестирования не достиг брандмауэра PIX. Если же пакет был получен брандмауэром PIX, то проверьте вывод команды syslog и убедитесь в том, что в этой глобальной команде задано достаточное количество адресов. Проверьте, включен ли адрес хоста пользователя в перечень адресов команды nat. Проконтролируйте также другие параметры настройки брандмауэра PIX и хоста пользователя. Убедитесь в том, что задан допустимый маршрут, применяемый по умолчанию.
Шаг 6. Если запись в таблице трансляции подготовлена, разрешите применение отладки на уровне пакетов и проверьте, проходит ли пакет через брандмауэр PIX.
Шаг 7. Если пакет проходит, но ответ на него не поступает, это означает, что внешний маршрутизатор не имеет информации о том, как возвратить этот трафик. Проверьте таблицу маршрутизации внешнего маршрутизатора.
Пользователи не могут получить доступ извне к внутренней системе (Web-серверу, почтовому серверу)
Ниже описан способ устранения наиболее часто возникающих нарушений в работе, характеризующихся тем, что пользователи сталкиваются с затруднениями при попытке получить доступ извне к Web-серверам и почтовым серверам, установленным во внутренней сети компании.
Шаг 1. При проведении отладки такого типа необходимо, прежде всего, разрешить прохождение пакетов эхо-тестирования от внешнего отправителя в целях проверки. Для этого воспользуйтесь следующей командой: conduit permit icmp any any
Шаг 2. Разрешите применение команды debug icmp trace.
Примечание
Вызов на выполнение команды debug packet в брандмауэре FIX Firewall, испытывающем тяжелую нагрузку, может вызвать настолько быстрый вывод ее результатов, что его нельзя будет остановить путем ввода команды no debug packet с консоли. В таком случае можно ввести команду по debug packet в сеансе Telnet.
Шаг 3. Выполните с внешнего узла эхо-тестирование внутренней системы через оттранслированный адрес. Например, если Web-сервер имеет внутренний адрес 10.10.10.1 и оттранслированный адрес 200.200.200.1, выполните с внешнего узла эхо-тестирование адреса 200.200.200.1,
Шаг 4. Если пакеты эхо-тестирования не будут обнаружены в брандмауэре PIX, проверьте внешний маршрутизатор, чтобы убедиться в том, что они на него поступают. Если результат такой проверки будет положительным, то проверьте таблицу маршрутизации внешнего маршрутизатора, чтобы убедиться в том, что в ней имеется информация о том, как должен маршрутизироваться такой пакет. Если таблица маршрутизации является правильной, то проверьте таблицу ARP в маршрутизаторе, чтобы определить, указан ли в ней правильный МАС-адрес для данного пакета. Он должен быть таким же, как и внешний МАС-адрес брандмауэра PIX.
Шаг 5. Проверьте в конфигурации брандмауэра PIX операторы static и conduit, соответствующие рассматриваемому серверу, и убедитесь в том, что они заданы правильно. Такая проверка может быть также выполнена с помощью следующих двух команд.
show static. Эта команда показывает все назначенные в настоящее время статические адреса.
show conduit. Эта команда позволяет получить перечень всех применяемых в настоящее время операторов conduit.
Шаг 6. Если пакет проходит нормально, снова попытайтесь выполнить эхо- тестирование с внешнего узла, но на этот раз используйте порт 80 (применяемый для Web-просмотра). Но если пользователь внешнего узла не может получить доступ к серверу, найдите в журнале сервера его адрес. Проверьте, не отвергает ли сервер запросы с этим адресом.
Методы поиска неисправностей
В табл. 25.3 описаны действия, которые могут быть выполнены для устранения двух наиболее распространенных проблем нарушения связи через брандмауэр PIX.
j Таблица 25.3. Методы поиска неисправностей;
Признак неисправности ПроблемаРешение
Внутренний хост не может получить доступ к хосту в InternetВнутренний хост не может получить доступ к хосту в InternetТаблица трансляции сетевых адресов не содержит информацию о сети, в которой находится этот хостТаблица трансляции сетевых адресов не содержит информацию о сети, в которой находится этот хостВ операторе global не предусмотрено достаточное количество адресов для обработки пакетов, поступающих от всех внутренних хостовВ операторе global не предусмотрено достаточное количество адресов для обработки пакетов, поступающих от всех внутренних хостовВ шлюзе хоста, применяемом по умолчанию, не задан соответствующий адресВ шлюзе хоста, применяемом по умолчанию, не задан соответствующий адресМаршрутизатор, находящийся на внешней стороне брандмауэра PIX, не имеет информации о том, как маршрутизировать адреса, определенные в глобальном пуле, в обратном направлении — к брандмауэру PIX. Такая ситуация обычно возникает при использовании в глобальном пуле определений адресов, которые находятся в иной сети, чем внешний интерфейс брандмауэра PIXМаршрутизатор, находящийся на внешней стороне брандмауэра PIX, не имеет информации о том, как маршрутизировать адреса, определенные в глобальном пуле, в обратном направлении — к брандмауэру PIX. Такая ситуация обычно возникает при использовании в глобальном пуле определений адресов, которые находятся в иной сети, чем внешний интерфейс брандмауэра PIXУбедитесь в том, что команда nat включает информацию о сети, в которой находится хост. Например:Host address 171.68.101.1 nat (inside,outside) 1 171.68.0.0 255.255.0.0Предусмотрите достаточное количество глобальных адресов для всех внутренних хостов.global (outside) 1 200.200.200.2200.200.200.250В качестве альтернативного решения примените метод трансляции адресов портов (РАТ — Port Address Translation): global (outside) 1 200.200.200.2200.200.200.2Если хост находится в той же сети, что и брандмауэр PIX, то для него в качестве шлюза, заданного по умолчанию, должен быть указан адрес внутреннего интерфейса PIX Предусмотрите применение во внешнем маршрутизаторе статического маршрута для этих глобальных адресовУбедитесь в том, что команда nat включает информацию о сети, в которой находится хост. Например:Host address 171.68.101.1 nat (inside,outside) 1 171.68.0.0 255.255.0.0Предусмотрите достаточное количество глобальных адресов для всех внутренних хостов.global (outside) 1 200.200.200.2200.200.200.250В качестве альтернативного решения примените метод трансляции адресов портов (РАТ — Port Address Translation): global (outside) 1 200.200.200.2200.200.200.2Если хост находится в той же сети, что и брандмауэр PIX, то для него в качестве шлюза, заданного по умолчанию, должен быть указан адрес внутреннего интерфейса PIX Предусмотрите применение во внешнем маршрутизаторе статического маршрута для этих глобальных адресов
Внутренний хост не может получить доступ к хосту в Internet
Внутренний хост не может получить доступ к хосту в Internet
Таблица трансляции сетевых адресов не содержит информацию о сети, в которой находится этот хост
Таблица трансляции сетевых адресов не содержит информацию о сети, в которой находится этот хост
В операторе global не предусмотрено достаточное количество адресов для обработки пакетов, поступающих от всех внутренних хостов
В операторе global не предусмотрено достаточное количество адресов для обработки пакетов, поступающих от всех внутренних хостов
В шлюзе хоста, применяемом по умолчанию, не задан соответствующий адрес
В шлюзе хоста, применяемом по умолчанию, не задан соответствующий адрес
Маршрутизатор, находящийся на внешней стороне брандмауэра PIX, не имеет информации о том, как маршрутизировать адреса, определенные в глобальном пуле, в обратном направлении — к брандмауэру PIX. Такая ситуация обычно возникает при использовании в глобальном пуле определений адресов, которые находятся в иной сети, чем внешний интерфейс брандмауэра PIX
Маршрутизатор, находящийся на внешней стороне брандмауэра PIX, не имеет информации о том, как маршрутизировать адреса, определенные в глобальном пуле, в обратном направлении — к брандмауэру PIX. Такая ситуация обычно возникает при использовании в глобальном пуле определений адресов, которые находятся в иной сети, чем внешний интерфейс брандмауэра PIX
Убедитесь в том, что команда nat включает информацию о сети, в которой находится хост. Например:
Host address 171.68.101.1 nat (inside,outside) 1 171.68.0.0 255.255.0.0
Предусмотрите достаточное количество глобальных адресов для всех внутренних хостов.
global (outside) 1 200.200.200.2200.200.200.250
В качестве альтернативного решения примените метод трансляции адресов портов (РАТ — Port Address Translation): global (outside) 1 200.200.200.2200.200.200.2
Если хост находится в той же сети, что и брандмауэр PIX, то для него в качестве шлюза, заданного по умолчанию, должен быть указан адрес внутреннего интерфейса PIX Предусмотрите применение во внешнем маршрутизаторе статического маршрута для этих глобальных адресов
Убедитесь в том, что команда nat включает информацию о сети, в которой находится хост. Например:
Host address 171.68.101.1 nat (inside,outside) 1 171.68.0.0 255.255.0.0
Предусмотрите достаточное количество глобальных адресов для всех внутренних хостов.
global (outside) 1 200.200.200.2200.200.200.250
В качестве альтернативного решения примените метод трансляции адресов портов (РАТ — Port Address Translation): global (outside) 1 200.200.200.2200.200.200.2
Если хост находится в той же сети, что и брандмауэр PIX, то для него в качестве шлюза, заданного по умолчанию, должен быть указан адрес внутреннего интерфейса PIX Предусмотрите применение во внешнем маршрутизаторе статического маршрута для этих глобальных адресов
Окончание табл. 25.3
Признак неисправности
Проблема
Решение
Брандмауэр PIX недавно был
Вызовите на выполнение ко-
модернизирован или заме-
манду clear агр во внешнем
нен, и таблица ARP внешнего маршрутизатора еще не очищена
маршрутизаторе
В шлюзе хоста, применяв-
Проверьте применяемый по
мом по умолчанию, не задан
умолчанию шлюз в хосте
соответствующий адрес
пользователя
Внешний хост не может по-
Отсутствует информация о
Убедитесь в том, что маршру-
лучить доступ к хосту в ЛО-
том, как маршрутизировать
тизатор, подключенный к
кальной сети (например, к
пакеты для данного внеш-
внешнему интерфейсу данного
Web-серверу)
него адреса
маршрутизатора, имеет информацию о том, как маршрутизировать пакеты по статическому адресу сервера
Для сервера не предусмотрен
Независимо от того, является ли
оператор static или conduit
сервер Web-сервером или почтовым сервером, для него в конфигурации брандмауэра PIX должны быть предусмотрены операторы static и conduit.
Оператор static обеспечивает статическое преобразование внутренних адресов во внешний адрес.
Команда conduit обеспечивает возможность прохождения трафика через брандмауэр PIX и поступление его на сервер.
Ниже приведен пример для Web-сервера с внутренним адресом 10.10.10.20 и внешним (оттранслированным) адресом 200.200.200.20:
static (inside,outside) 200.200.200.20 10.10.10.20 netmask 255.255.255.255 conduit permit tcp host 200.200.200.20 eq ww any
Брандмауэр PIX не имеет
Такая ситуация может возник-
информации о том, как
нуть, только если сервер нахо-
маршрутизировать трафик к
дится в иной сети, чем бранд-
серверу
мауэр PIX.
Проверьте оператор inside route и убедитесь в том, что брандмауэр PIX имеет информацию о том, как маршрутизировать трафик. Для этого воспользуйтесь командой show route
Подготовка необходимой информации перед обращением к специалистам центра ТАС компании Cisco Systems
Прежде чем обратиться в центр Cisco ТАС, прочитайте эту главу и выполните все рекомендуемые действия по устранению нарушений в работе своей системы.
Кроме того, выясните и запишите следующие данные, что позволит специалистам центра Cisco ТАС быстрее предоставить вам помошь.
Определите версию программного обеспечения IOS брандмауэра PIX.
Получите максимально возможный объем информации об аппаратных средствах.
Дополнительные источники информации
Литература
Atkins, Derek. Internet Security Professional Reference, Second Edition. Indianapolis: New Riders Publishing, 1997.
Kaeo, Merike. Designing Network Security. Indianapolis: Cisco Press, 1999.
Информационные ресурсы
Internet: www.securityfocus.com, (Узел SecurityFocus.com представляет в Internet единую организацию или скорее сообщество пользователей; на этом узле и частные лица, и представители предприятий могут найти информацию по обеспечению безопасности и получить ответы на вопросы, касающиеся защиты, от ведущих специалистов в этой области. На этом узле даны ссылки на ресурсы, посвященные вопросам защиты, в том числе представлены архивы групп новостей, книги, списки рассылки, инструментальные средства и продукты, а также службы защиты.)
Internet: www.finjan.com. (Компания Finjan разрабатывает фильтры и другие средства, позволяющие заблокировать сценарии JavaScript, которые применяются для взлома или воспроизведения сеанса, а также для организации других видов нападения с использованием "мобильного кода”.)
Группы новостей: alt.2600. (Эта группа новостей представляет интерес для специалистов по программному обеспечению и защите. С ее помощью можно получить большой объем информации о способах вторжения в сеть и методах зашиты.)
Обслуживание брандмауэра PIX
Обслуживание брандмауэра PIX связано с выполнением следующих двух важных процедур:
восстановление паролей;
модернизация программного обеспечения.
Восстановление пароля
Для восстановления пароля в модели брандмауэра PIX 515 требуется загрузка в него необходимых данных с TFTP-сервера, поскольку в этой модели отсутствует дис-
ковод для гибких дисков. Для других моделей брандмауэра Р1Х применяется описанная ниже процедура.
Должен быть доступен образ восстановления пароля. Этот образ необходимо скопировать по протоколу TFTP в брандмауэр PIX точно так же, как и любой новый образ, предназначенный для обновления программного обеспечения брандмауэра.
Протокол TFTP предоставляет возможности, полностью аналогичные средствам загрузчика информации с гибких дисков, поэтому все функции, которые прежде выполнялись с использованием гибких дисков, теперь могут быть выполнены с помощью протокола TFTP.
При выполнении этих операций руководствуйтесь следующими рекомендациями.
Перед применением протокола TFTP в брандмауэре PIX необходимо перезагрузить этот брандмауэр.
После вызова на выполнение программы монитора ПЗУ приложение PIX прекращает свою работу, поэтому в ходе выполнения рассматриваемой операции по сети не проходит трафик.
TFTP-сервер должен находиться на наиболее безопасном участке сети (лучше всего, во внутренней ее части).
При использовании протокола TFTP для загрузки нового образа или восстановления пароля сеть должна находиться в автономном режиме до тех пор, пока не будет завершена эта операция.
После перезагрузки системы адреса, которые применялись в процессе передачи информации по протоколу TFTP, не остаются в конфигурации или в памяти.
Процедура восстановления пароля брандмауэра PIX 520
Ниже приведены рекомендации по восстановлению утраченного пароля брандмауэра PIX 520.
Шаг 1. Загрузите файлы Nppix.bin и rawrite.exe с узла www.cisco.com/warp/customer/ 110/34 .shtml в один и тот же каталог на персональном компьютере. (Для загрузки этих файлов необходимо иметь учетную запись на узле ССО.)
Шаг 2. После получения этих двух файлов вызовите на выполнение программу RAWRITE:
С:\ТЕМР> RAWRITE
RaWrite 1.2-Write the disk file to a raw floppy disk.
Шаг 3. Введите имя исходного файла: Nppix.bin.
Шаг 4. Введите имя диска назначения: А.
Шаг 5. Вставьте отформатированный диск в дисковод А и нажмите клавишу <Enter>.
После этого программа Rawrite запишет на диск образ программы восстановления пароля.
Шаг 6. Загрузите брандмауэр PIX с этого диска, после чего старый пароль будет удален.
Загрузка образа FIX 515 по протоколу TFTP
Поскольку брандмауэр PIX 515 не имеет дисковода для гибких дисков, то единственный возможный метод восстановления пароля состоит в загрузке программы восстановления с TFTP-сервера. Протокол TFTP предоставляет возможности, полностью аналогичные средствам загрузчика информации с гибких дисков, поэтому все функции, которые прежде выполнялись с использованием гибких дисков, теперь могут быть выполнены с помощью протокола TFTP.
При выполнении этих операций руководствуйтесь следующими рекомендациями.
Перед применением протокола TFTP в брандмауэре PIX необходимо перезагрузить этот брандмауэр.
После вызова на выполнение программы монитора ПЗУ приложение PIX прекращает свою работу, поэтому в ходе выполнения рассматриваемой операции по сети не проходит трафик.
TFTP-сервер должен находиться на наиболее безопасном участке сети (лучше всего, во внутренней ее части).
При использовании протокола TFTP для загрузки нового образа или восстановления пароля сеть должна находиться в автономном режиме до тех пор, пока не будет завершена эта операция.
После перезагрузки системы адреса, которые применялись в процессе передачи информации по протоколу TFTP, не остаются в конфигурации или в памяти.
Брандмауэр PIX 515 считывает загрузочный образ из флэш-памяти или загружается из образа, полученного от TFTP-сервера.
В настоящем разделе описаны команды монитора, который может быть вызван в процессе загрузки брандмауэра PIX 515 путем отправки с терминала символа Break или нажатия клавиши <Esc>.
Поскольку в модели PIX 515 отсутствует дисковод для гибких дисков, необходимо ввести двоичный образ в брандмауэр PIX 515 с помощью протокола TFTP.
В брандмауэре PIX 515 предусмотрен специальный режим работы, называемый ROMmon, который позволяет получить двоичный образ по сети. После включения питания или перезагрузки брандмауэр PIX 515 находится в состоянии ожидания в течение 10 секунд; в это время можно отправить с терминала символ Break или нажать клавишу <Esc> для активизации режима ROMmon.
Если брандмауэр не нужно переводить в режим ROMmon, нажмите клавишу пробела, чтобы немедленно началась обычная начальная загрузка, или подождите 10 секунд, после чего брандмауэр PIX 515 начнет загружаться обычным образом.
Если брандмауэр находится в режиме ROMmon, в нем можно вводить команды, позволяющие указать местонахождение двоичного образа, получить его по сети, а затем перезагрузить брандмауэр PIX 515 с помощью этого нового образа. Если режим ROMmon не активизирован, то брандмауэр PIX 515 загружается обычным образом из флэш-памяти.
Режим ROMmon позволяет также выполнить эхо-тестирование TFTP-сервера для определения того, находится ли он в оперативном режиме, и указать IP-адрес ближайшего маршрутизатора, если образ не находится в той же подсети, что и интерфейс PIX 515.
Режим ROMmon реализован только в модели PIX 515 и отсутствует в предыдущих моделях брандмауэра PIX Firewall. TFTP-сервер не проводит аутентификацию пользо-
вателя перед передачей файлов, поэтому имя пользователя и пароль для ТЕТР-сервера не требуются.
Во время работы в программе Windows Hyperterminal можно нажать клавишу <Esc> или отправить символ Break, нажав клавиши <Ctrl+Break>.
В сеансе Telnet с сервером терминала, который имеет последовательный доступ к брандмауэру PIX 515, нажмите клавиши <Ctrl+]> для получения приглашения к вводу команд Telnet, а затем введите команду send break.
Если служба ТЕТР перестает получать запросы к данным во время передачи файла, она переходит в состояние ожидания на время, равное 4 секундам, а затем закрывает соединение.
Для загрузки образа по протоколу ТЕТР применяется следующая процедура.
Шаг 1. Сразу после включения питания брандмауэра PIX Firewall и появления сообщений запуска отправьте с терминала символ Break или нажмите клавишу <Esc>.
Появится приглашение к вводу команд ROMmon.
Шаг 2. В случае необходимости введите вопросительный знак (?) для получения списка доступных команд.
Шаг 3. Воспользуйтесь командой interface, чтобы указать, какой интерфейс должен использоваться для трафика эхо-тестирования. Если брандмауэр PIX 515 имеет только два интерфейса, то команды ROMmon по умолчанию относятся к внутреннему интерфейсу.
Шаг 4. Воспользуйтесь командой address, чтобы указать IP-адрес интерфейса брандмауэра PIX Firewall.
Шаг 5. Воспользуйтесь командой server, чтобы указать IP-адрес удаленного сервера.
Шаг 6. Воспользуйтесь командой file, чтобы указать имя файла образа брандмауэра PIX Firewall.
Шаг 7. В случае необходимости введите команду gateway, чтобы указать IP-адрес шлюза маршрутизатора, через который может быть получен доступ к серверу.
Шаг 8. В случае необходимости воспользуйтесь командой ping для проверки достижимости сервера. Если выполнение этой команды окончится неудачей, перед переходом к дальнейшим действиям выполните настройку конфигурации доступа к серверу.
Шаг 9. Введите команду ТЕТР, чтобы приступить к приему загрузочного образа.
Шаг 10. По окончании приема перезагрузите брандмауэр PIX и установите новый пароль.
Способы модернизации программного обеспечения
Выбор применяемой процедуры модернизации программного обеспечения зависит от того, есть ли необходимость сохранить в неизменном виде файлы конфигурации или их можно перезаписать. В первом случае применяется процедура, описанная в табл. 25.4.
I Таблица 25.4. Модернизация программного обеспечения|
Версия, установленная в Рекомендации по установке следующей версии брандмауэре PIX Firewall
2.7хУстановить версию 3.0, а затем выполнить модернизацию с
переходом на следующую версию
3.0Установить версию 4.0.7, а затем выполнить модернизацию с
переходом на следующую версию
4.0.7Установить версию 4.1(7), а затем выполнить модернизацию с
переходом на следующую версию
(5) или последующая Установить версию 4.2(х), а затем выполнить модернизацию спереходом на следующую версию
(х)Установить версию 4.4
Если же нет необходимости сохранять информацию о конфигурации, то можно перейти непосредственно с текущей версии на новейшую.
Восстановление утраченного пароля
В настоящем разделе описаны процедуры, необходимые для восстановления утраченного пароля входа в систему или пароля enable. Конкретная процедура зависит от платформы и применяемого программного обеспечения, но во всех случаях для восстановления пароля необходимо, чтобы маршрутизатор был выведен из эксплуатации и выключен.
Если вам потребуется выполнить одну из следующих процедур, предусмотрите возможность использования вспомогательных систем для временного выполнения функций маршрутизатора, для которого необходимо провести процедуру восстановления пароля. Если же это невозможно, то сообщите о перерыве в работе всем потенциальным пользователям, и если возможно, проведите ее в период низкой нагрузки.
Примечание
Запишите пароль и храните его в безопасном месте.
При выполнении всех процедур по восстановлению утраченных паролей изменяется содержимое регистра конфигурации маршрутизатора. В зависимости от платформы и применяемого программного обеспечения такая операция выполняется путем изменения конфигурации программного обеспечения маршрутизатора, физической перестановки перемычки или изменения положения DIP- переключателей в маршрутизаторе.
В табл. 25.5 показано, на каких платформах регистры конфигурации реализованы в программном обеспечении и на каких для внесения изменений в регистр конфигурации требуется перестановка перемычки или изменение положения DIP-переключателей.
■ Таблица 25.5. Варианты исполнения регистров конфигурации:
Iдля конкретных платформ и версий программного
।■ обеспечения Ciscoi
Платформа (и версия программного обеспачения, если оно применяется)
Программный регистр конфигурации
Аппаратный регистр конфигурации (перемычка)
Аппаратный регистр конфигурации (DIP- переключатель)
Устройство ряда Cisco 2000
Да
—
—
Устройство ряда Cisco 2500
Да
—
—
Устройство ряда Cisco 3000
Да
—
—
Устройство ряда Cisco 4000
Да
—
—
Устройство ряда Cisco 7000, работающее под управлением программного обеспечение версии 9.17(4) или последующих версий (флэш-память) либо системы Cisco IOS 10.0 или последующих версий (ПЗУ)
Да
Устройство ряда Cisco 7000, загружаемое из ПЗУ, в кото-
—
Да
—
ром эксплуатируется программное обеспечение версии 9.21 или предыдущих версий Cisco 7200
Да
Cisco 7500
Да
—
—
Устройство ряда Cisco IGS, работающее под управлением программного обеспечения версии 9.1 или последующих
Да
—
—
версий
Устройство Cisco IGS, в котором эксплуатируется программное обеспечение версии, предшествующей 9.1
—
Да
Cisco CGS
—
Да
—
Cisco MGS
—
Да
—
Cisco AGS
—
Да
—
Cisco AGS+
—
Да
—
Процедура восстановления пароля: платформы, на которых эксплуатируется текущая версия Cisco IOS
Новейшие платформы Cisco могут эксплуатироваться под управлением программного обеспечения, находяшегося во флэш-памяти, или загружаться по сети, а также могут в процессе загрузки игнорировать содержимое энергонезависимого ОЗУ. (Такая возможность предусмотрена также в маршрутизаторах ряда Cisco 7000, которые загружаются из флэш-памяти или по сети; маршрутизатор Cisco 7000, который загружается из ПЗУ, обладает такой способностью, если в нем эксплуатируется система Cisco IOS 10.0 или последующих версий.) Способ загрузки, при котором игнорируется содержи-
мое энергонезависимого ОЗУ, позволяет обойти файл конфигурации (который содержит пароли) и получить полный доступ к маршрутизатору. После этого появляется возможность восстановить утраченный пароль или ввести в конфигурацию новый.
Примечание
Если пароль зашифрован, возможность его восстановления не предусмотрена. Необходимо ввести в конфигурацию новый пароль.
На рис. 25.1 приведена блок-схема, которая описывает процедуру восстановления пароля для следующих платформ:
серверы доступа и маршрутизаторы ряда Cisco 2000, Cisco 2500, Cisco 3000 и Cisco 4000;
маршрутизаторы ряда Cisco 7000, загружаемые из флэш-памяти, в которых эксплуатируется программное обеспечение версии 9.17(4) или последующих версий, либо загружаемые из ПЗУ, в которых эксплуатируется система Cisco IOS 10.0 или последующих версий;
маршрутизаторы Cisco IGS, работающие под управлением программного обеспечения версии 9.1 или последующих версий;
маршрутизаторы Cisco CGS, MGS, AGS и AGS+, работающие под управлением программного обеспечения версии 9.1(7) или последующих версий;
маршрутизаторы ряда Cisco 7000, работающие под управлением программного обеспечения версий от 9.17(4) до 9.21, загружаемого из ПЗУ.
На некоторых из этих платформ информация о конфигурации хранится в программном обеспечении. Для настройки других платформ требуется физически изменить позицию перемычки регистра конфигурации на плате процессора. На рис. 25.1 показана блок-схема процедуры восстановления пароля с учетом применяемой платформы и программного обеспечения.
Обратитесь к табл. 25.5, чтобы определить, можно ли выполнить настройку конфигурации применяемой платформы с помощью программного обеспечения, или для этого требуется физическое перемещение перемычки.
Приведенная ниже процедура описывает процесс восстановления пароля только для следующих платформ.
Маршрутизаторы ряда Cisco 2000, Cisco 2500, Cisco 3000 и Cisco 4000.
Маршрутизаторы ряда Cisco 7000, загружаемые из флэш-памяти или по сети, в которых эксплуатируется программное обеспечение версии 9.17(4) или последующих версий, либо загружаемые из ПЗУ, в которых эксплуатируется система Cisco IOS 10.0 или последующих версий.
Устройства Cisco IGS, в которых эксплуатируется программное обеспечение версии 9.1 или последующих версий.
Устройство ряда Cisco 2000, 2500,3000,4000; устройство ряда Cisco 7000 с программным обеспечением 9.17(4) или более поздней версии (загружаемым из флэш- памяги или по сети), с системой IOS Cisco 10.0 или более поздней версии (загружаемой из ПЗУ); устройство Cisco IGS с программным обеспечением 9.1 или более поздней версии
Выключитененовавключитемаршрутизатор
Нажимайтекомбинациюклавишпрерыванияв течение60 секунд
Введите e/s 2000002 в приглашении (>) у к вводу команд ROMmon (не относится к устройству
Cisco 7000)
Запишитевыведенноена экранзначение(например, 2102)Это - програм-мный регистрконфигурации
Устройство Cisco CGS, MGS, AGS, AGS+ с программным
Рис. 25.1. Восстановление пароля: платформы, на которых эксплуатируются текущие выпуски Cisco IOS и новейшие версии программного обеспечения
При проведении процедуры восстановления пароля на одной из перечисленных платформ обязательно пройдите по пути в блок-схеме (см. рис. 25.1), который обозначен следующим образом: “Устройства ряда Cisco 2000, 2500, 3000, 4000; устройства ряда Cisco 7000, загружаемые из флэш-памяти, в которых эксплуатируется программное обеспечение версии 9.17(4) или последующих версий, либо загружаемые из ПЗУ, в которых эксплуатируется система Cisco IOS 10.0 или последующих версий; устройства IGS, в которых эксплуатируется программное обеспечение версии 9.1 или последующих версий”.
Поэтапные процедуры восстановления пароля для других платформ описаны в следующих разделах:
Процедура восстановления пароля: платформы, на которых эксплуатируются новейшие версии программного обеспечения.
Процедура восстановления пароля: платформы, на которых эксплуатируются более ранние версии программного обеспечения.
Процедура восстановления пароля: маршрутизатор 1GS, на котором эксплуатируется версия программного обеспечения, предшествующая версии 9.1.
Процедура восстановления пароля: сервер связи Cisco 500-CS.
Примечание
Для выполнения этой процедуры необходимо иметь терминал или персональный компьютер (на котором работает программное обеспечение эмуляции терминала), связанный с консольным портом маршрутизатора. Кроме того, необходимо определить, какая комбинация клавиш применяется для передачи символа Break.
Ниже приведена процедура восстановления пароля для платформ Cisco, на которых эксплуатируется текущая версия программного обеспечения Cisco 1OS.
Шаг 1. Выключите и снова включите маршрутизатор.
Шаг 2. Введите комбинацию клавиш <Ctrl+Break> на терминале или в программном обеспечении эмуляции терминала в течение 60 секунд с момента включения питания.
Появится приглашение к вводу информации монитора ПЗУ (>).
Шаг 3. Введите команду e/s 2000002. (При работе с маршрутизатором ряда Cisco 7000 введите команду e/s ХХХХХХХХ.) Эта команда позволяет проверить наличие программного регистра конфигурации в соответствующем коротком (16битовом) слове в оперативной памяти.
Запишите вывод, полученный в результате выполнения этой команды. Он представляет собой значение программного регистра конфигурации.
Шаг 4. Введите q (сокращение от quit — выход), чтобы вернуться в строку приглашения к вводу команд монитора ПЗУ (>).
Шаг 5. Введите команду о/г 0x42. Значение 42 устанавливает в 1 шестой бит программного регистра конфигурации, что позволяет маршрутизатору во время начальной загрузки игнорировать содержимое энергонезависимого ОЗУ. (Обязательно введите Ох перед указанным значением регистра конфигурации.)
Шаг 6. Введите i (сокращение от initialize — инициализация) в приглашении к вводу команд монитора ПЗУ (>). В результате этого будет перезагружен маршрутизатор.
Шаг 7. Введите по в ответ на все вопросы, заданные в процессе установки.
Шаг 8. Введите ехес-команду enable в приглашении к вводу команд Router.
Шаг 9. Введите привилегированную ехес-команду show startup-config или show configuration, чтобы определить, задан ли пароль открытым текстом (не зашифрован) или зашифрован.
Шаг 10. Если пароль задан открытым текстом, перейдите к шагу 14. Если пароль зашифрован, перейдите к шагу 11.
Шаг 11. Если пароль зашифрован, введите привилегированную ехес-команду configure memory. Эта команда передает хранимую информацию конфигурации в оперативную память.
Шаг 12. Введите привилегированную ехес-команду configure terminal, чтобы перейти в режим настройки конфигурации маршрутизатора.
Шаг 13. Если утрачен пароль enable, вызовите на выполнение глобальную команду конфигурации enable password, чтобы ввести в конфигурацию новый пароль, и нажмите клавиши <Ctrl+Z>, чтобы выйти из режима настройки конфигурации. Ниже показана синтаксическая структура команды enable password: enable password [level levels {password | encryption-type encrypted-password} Описание синтаксиса
level level. (Необязательный параметр.) Уровень, к которому относится этот пароль. Может быть указано до 16 уровней привилегий с номерами от 0 до 15. Уровень 1 относится к обычным привилегиям пользователя в режиме ввода exec-команд. Если этот параметр не указан в команде или применяется форма этой команды с префиксом по, то уровень привилегий по умолчанию устанавливается равным 15 (традиционные привилегии режима enable).
password. Пароль, вводимый пользователем для перехода в режим enable.
encryption-type. (Необязательный параметр.) Собственный алгоритм корпорации Cisco, применяемый для шифрования пароля. В настоящее время единственным доступным типом шифрования является 7. Если задан тип шифрования, то в качестве следующего параметра необходимо указать зашифрованный пароль (пароль, который уже зашифрован маршрутизатором Cisco).
encrypted-password. Зашифрованный вводимый пароль, который скопирован из конфигурации другого маршрутизатора.
Пример
В следующем примере показано, как разрешить применение пароля pswd2 для уровня привилегий 2:
enable password level 2 pswd2
Если утрачен пароль входа в систему, выполните настройку конфигурации канала консоли с использованием команд конфигурации канала пароля login и password. Введите <Ctrl+Z>, чтобы выйти из режима настройки конфигурации, и перейдите к шагу 15.
Синтаксис
Чтобы разрешить проверку паролей при входе в систему, воспользуйтесь командой конфигурации канала login:
login [local | tacacs]
Описание синтаксиса
local. (Необязательный параметр.) Позволяет выбрать режим локальной проверки паролей. Аутентификация осуществляется по имени пользователя, указанному в глобальной команде конфигурации username.
tacacs. (Необязательный параметр.) Выбрать механизм проверки идентификатора и пароля пользователя в стиле TACACS.
Примеры
В следующем примере устанавливается пароль letmein в канале виртуального терминала 4:
line vty 4
password letmein
login
Синтаксис
Для задания пароля в канале применяется команда конфигурации канала password:
password password
Описание синтаксиса
password. Символьная строка, в которой задан пароль канала. Первый символ не может быть цифрой. Строка может содержать любые алфавитноцифровые символы, включая пробелы, и иметь длину до 80 символов. Пароль не может быть задан в формате “число — пробел — какие-либо иные символы”. Если в пароле после цифр стоит пробел, то при его обработке возникают проблемы. Например, hello 21 — допустимый пароль, а 21 hello — нет. При проверке пароля учитывается регистр. Например, пароль Secret считается иным по сравнению с паролем secret.
При запуске процесса обработки ехес-команд в канале, который защищен паролем, интерпретатор exec-команд запрашивает пароль. Если пользователь вводит правильный пароль, интерпретатор exec-команд отображает свое обычное приглашение к вводу привилегированных exec-команд. Пользователь может три раза попытаться ввести пароль; после третьей неудачной попытки интерпретатор exec-команд завершает свою работу, и терминал возвращается в неактивное состояние.
Пример
В следующем примере показано, как отменить защиту паролем для каналов виртуального терминала 1-4:
line vty 1 4 no password
Шаг 14. Если утрачен пароль enable, найдите в конфигурации запись глобальной команды конфигурации enable-password и запишите пароль.
Если утрачен пароль входа в систему, найдите в конфигурации записи для канала консоли и запишите пароль, который задан в команде конфигурации канала password.
Шаг 15. Вызовите на выполнение привилегированную exec-команду copy runningconfig startup-config или write memory, чтобы записать конфигурацию в энергонезависимое ОЗУ.
Примечание
Если на этом этапе в устройстве Cisco 2500, 3000 или 4000 будет выполнена команда copy running-config startup-config или write memory, то конфигурация этого устройства будет перезаписана. Убедитесь в том, что имеется резервная копия файла конфигурации.
Теперь маршрутизатор является полностью работоспособным, и пользователь может, как обычно, применять свои восстановленные или реконфигурированные пароли.
Примечание
Восстановите первоначальное состояние программного регистра конфигурации как можно скорее. Если не будет восстановлено значение, записанное в шаге 3, то маршрутизатор после начальной загрузки будет всегда игнорировать содержимое энергонезависимого ОЗУ и переходить к выполнению процедуры setup. Перейдите к шагу 17, где показано, как вернуть программный регистр конфигурации в первоначальное состояние.
Шаг 16. В режиме ввода привилегированных exec-команд перейдите в режим конфигурации маршрутизатора с помощью привилегированной ехес-команды configure terminal.
Шаг 17. Введите первоначальное значение в программный регистр конфигурации с помощью глобальной команды конфигурации config-register. Для этого необходимо ввести Ох, а затем значение программного регистра конфигурации, записанное в шаге 3. Например, если было записано значение 2102, то нужно ввести команду config-register 0x2102.
Синтаксис
Ниже показана синтаксическая структура команды config-register.
config-register value
Описание синтаксиса
value. Шестнадцатеричное или десятичное значение, представляющее содержимое 16-битового регистра конфигурации, которое должно использоваться при следующей перезагрузке маршрутизатора. Это значение может находиться в диапазоне от 0x0 до OxFFFF (от 0 до 65535 в десятичном коде).
Шаг 18. Выйдите из режима настройки конфигурации маршрутизатора, введя <Ctrl+Z>.
При следующем выключении и включении питания маршрутизатора или его перезапуске с помощью привилегированной exec-команды reload процесс начальной загрузки будет происходить обычным образом. Воспользуйтесь новым или восстановленным паролем для получения доступа к маршрутизатору после его перезагрузки.
Процедура восстановления пароля: платформы, на которых эксплуатируются новейшие версии программного обеспечения
На платформах Cisco CGS, MGS, AGS и AGS+, а также маршрутизаторах ряда Cisco 7000, в которых эксплуатируется программное обеспечение Cisco IOS 10.0, загружаемое из ПЗУ, регистры конфигурации реализованы в аппаратном обеспечении, поэтому в процессе восстановления пароля необходимо изменить положение перемычки регистра конфигурации.
Для получения доступа к перемычке аппаратного регистра конфигурации может потребоваться удалить плату процессора из блока маршрутизатора. Подробные инструкции по удалению из блока маршрутизатора и последующей вставке платы процессора приведены в документации по конкретным аппаратным средствам.
Перемещение аппаратной перемычки регистра конфигурации в позицию бита 6 позволяет маршрутизатору игнорировать содержание энергонезависимого ОЗУ при загрузке. Это позволяет обойти файл конфигурации (который содержит также пароли) и получить полный доступ к маршрутизатору. После этого появляется возможность восстановить утраченный пароль или ввести в конфигурацию новый.
Примечание
Если пароль зашифрован, возможность его восстановления не предусмотрена. Необходимо ввести в конфигурацию новый пароль.
На рис. 25.1 приведена блок-схема, которая описывает процедуру восстановления пароля для следующих платформ:
серверы доступа и маршрутизаторы ряда Cisco 2000, 2500, 3000 и 4000;
маршрутизаторы ряда Cisco 7000, загружаемые из флэш-памяти или по сети, в которых эксплуатируется программное обеспечение версии 9.17(4) или последующих версий, либо загружаемые из ПЗУ, в которых эксплуатируется система Cisco IOS 10.0 или последующих версий;
маршрутизаторы Cisco IGS, работающие под управлением программного обеспечения версии 9.1 или последующих версий;
маршрутизаторы Cisco CGS, MGS, AGS и AGS+, работающие под управлением программного обеспечения версии 9.1(7) или последующих версий;
маршрутизаторы ряда Cisco 7000, работающие под управлением программного обеспечения версий от 9.17(4) до 9.21, загружаемого из ПЗУ.
На некоторых из этих платформ информация о конфигурации хранится в программном обеспечении и для них не требуется вносить изменения в конфигурацию с помощью аппаратных средств. Для настройки других платформ требуется физически изменить позицию перемычки регистра конфигурации на плате процессора.
Обратитесь к табл. 25.5, чтобы определить, можно ли выполнить настройку конфигурации применяемой платформы с помощью программного обеспечения, или для этого требуется физическое перемещение перемычки.
Приведенная ниже процедура описывает процесс восстановления пароля только для следующих платформ:
маршрутизаторы Cisco CGS, MGS, AGS и AGS+, в которых эксплуатируется программное обеспечение версии 9.1(7) или последующих версий;
маршрутизаторы ряда Cisco 7000, загружаемые из ПЗУ, в которых эксплуатируется программное обеспечение версий от 9.17(4) до 9.21.
При проведении процедуры восстановления пароля на одной из перечисленных платформ пройдите по пути в блок-схеме (см. рис. 25.1), который обозначен следующим образом: “Устройства Cisco CGS, MGS, AGS и AGS+, в которых эксплуатируется программное обеспечение версии 9.1(7) или последующих версий; устройства ряда Cisco 7000, загружаемые из ПЗУ, в которых эксплуатируется программное обеспечение версий от 9.17(4) до 9.21”.
Для ознакомления с поэтапной процедурой восстановления пароля для других платформ обратитесь к одному из следующих разделов.
Процедура восстановления пароля: платформы, на которых эксплуатируется текущая версия Cisco IOS.
Процедура восстановления пароля: платформы, на которых эксплуатируются более ранние версии программного обеспечения.
Процедура восстановления пароля: маршрутизатор IGS, на котором эксплуатируется версия программного обеспечения, предшествующая версии 9.1.
Процедура восстановления пароля: сервер связи Cisco 500-CS.
Примечание
Для выполнения этой процедуры необходимо иметь терминал или персональный компьютер (на котором работает программное обеспечение эмуляции терминала), связанный с консольным портом маршрутизатора.
Ниже приведена процедура восстановления пароля для платформ Cisco, на которых эксплуатируется новейшая версия программного обеспечения Cisco IOS.
Шаг 1. Выключите маршрутизатор.
Шаг 2. Чтобы изменить установку аппаратного регистра конфигурации, переместите перемычку с позиции бита 0 или 1 в позицию бита 6. В результате маршрутизатор после загрузки операционной системы принудительно переводится в со-
стояние, при котором он игнорирует содержимое энергонезависимого ОЗУ, а следовательно, и файл конфигурации. Запишите, в каком положении перемычка находилась первоначально.
Примечание
Для перемещения перемычки аппаратного регистра конфигурации может потребоваться удалить плату процессора из блока маршрутизатора. Необходимость в этом возникает при использовании платы RP (Route Processor— процессор маршрутизации). Подробные инструкции по удалению и последующей вставке платы процессора приведены в документации по конкретным аппаратным средствам. Если пришлось удалить плату процессора, вставьте ее снова, прежде чем перейти к дальнейшим действиям.
Шаг 3. Включите маршрутизатор.
Маршрутизатор загрузится, но будет игнорировать содержимое энергонезависимого ОЗУ и не перейдет в подпрограмму Setup.
Шаг 4. Введите по в ответ на все вопросы, заданные в процессе установки.
Появится приглашение к вводу информации Router.
Шаг 5. Введите exec-команду enable.
Шаг 6. Введите привилегированную exec-команду show configuration, чтобы определить, задан ли пароль открытым текстом (не зашифрован) или зашифрован.
Если пароль задан открытым текстом, перейдите к шагу 10. Если пароль зашифрован, перейдите к шагу 7.
Шаг 7. Если пароль зашифрован, введите привилегированную exec-команду configure memory. Эта команда записывает хранимую конфигурацию в оперативную память.
Шаг 8. Введите привилегированную exec-команду configure terminal, чтобы перейти в режим настройки конфигурации маршрутизатора.
Шаг 9. Если утрачен пароль enable, вызовите на выполнение глобальную команду конфигурации ena'ble-password, чтобы ввести в конфигурацию новый пароль.
Если утрачен пароль входа в систему, настройте конфигурацию канала консоли, введя новый пароль входа в систему с использованием команд конфигурации канала пароля login и password. Нажмите <Ctrl+Z>, чтобы выйти из режима настройки конфигурации. Перейдите к шагу 11.
Синтаксис
Чтобы разрешить проверку паролей при входе в систему, воспользуйтесь командой конфигурации канала login:
login [local | tacacs]
Описание синтаксиса
local. (Необязательный параметр.) Позволяет выбрать режим локальной проверки паролей. Аутентификация осуществляется по имени пользователя, указанного в глобальной команде конфигурации username.
tacacs. (Необязательный параметр.) Выбрать механизм проверки идентификатора и пароля пользователя в стиле TACACS.
Примеры
В следующем примере устанавливается пароль letmein в канале виртуального терминала 4: line vty 4 password letmein login
Синтаксис
Для задания пароля в канале применяется команда конфигурации канала password:
password password
Описание синтаксиса
password. Символьная строка, в которой задан пароль канала. Первый символ не может быть цифрой. Строка может содержать любые алфавитноцифровые символы, включая пробелы, и иметь длину до 80 символов. Пароль не может быть задан в формате “число — пробел — какие-либо иные символы”. Если в пароле после цифр стоит пробел, то при его обработке возникают проблемы. Например, hello 21 — допустимый пароль, а 21 hello — нет. При проверке пароля учитывается регистр. Например, пароль Secret считается иным по сравнению с паролем secret.
При запуске процесса обработки exec-команд в канале, который защищен паролем, интерпретатор exec-команд запрашивает пароль. Если пользователь вводит правильный пароль, интерпретатор exec-команд отображает свое обычное приглашение к вводу привилегированных exec-команд. Пользователь может три раза попытаться ввести пароль; после третьей неудачной попытки интерпретатор exec-команд завершает свою работу и терминал возвращается в неактивное состояние.
Пример
В следующем примере показано, как отменить защиту паролем для каналов виртуального терминала 1-4:
line vty 1 4 no password
Шаг 10. Если утрачен пароль enable, найдите в конфигурации запись глобальной команды конфигурации enable-password и запишите пароль.
Если утрачен пароль входа в систему, найдите записи конфигурации для канала консоли и запишите пароль, заданный в команде конфигурации канала password.
Шаг 11. Вызовите на выполнение привилегированную exec-команду write memory, чтобы записать конфигурацию в оперативную память.
Шаг 12. Теперь маршрутизатор является полностью работоспособным, и пользователь может, как обычно, применять свои восстановленные или реконфигурированные пароли.
Примечание
Верните перемычку аппаратного регистра конфигурации в первоначальное положение как можно скорее. Если перемычка не будет возвращена в позицию бита, записанную в шаге 2, то маршрутизатор после начальной загрузки будет всегда игнорировать содержимое энергонезависимого ОЗУ и переходить к выполнению процедуры Setup. Перейдите к шагу 13, где описано, как возвратить перемычку в ее первоначальную позицию.
Шаг 13. Выключите маршрутизатор.
Шаг 14. Переместите аппаратную перемычку регистра конфигурации из позиции бита 6 в первоначальную позицию (позицию, которая была отмечена в шаге 2). Для получения доступа к перемычке аппаратного регистра конфигурации может потребоваться удалить плату процессора. Подробные инструкции по удалению и последующей вставке платы процессора приведены в документации по конкретным аппаратным средствам. Если пришлось удалить плату процессора, вставьте ее снова, прежде чем перейти к дальнейшим действиям.
Шаг 15. Включите маршрутизатор. Воспользуйтесь новым или восстановленным паролем для получения доступа к маршрутизатору.
Процедура восстановления пароля: платформы, на которых эксплуатируются более ранние версии программного обеспечения
На платформах Cisco CGS, MGS, AGS и AGS+, а также маршрутизаторах ряда Cisco 7000, в которых эксплуатируется программное обеспечение версий, предшествующих Cisco IOS 10.0, загружаемое из ПЗУ, регистры конфигурации реализованы в аппаратном обеспечении, поэтому в процессе восстановления пароля необходимо физически изменить положение перемычки регистра конфигурации.
Для получения доступа к перемычке аппаратного регистра конфигурации может потребоваться удалить плату процессора из блока маршрутизатора. Подробные инструкции по удалению и последующей вставке платы процессора приведены в документации по конкретным аппаратным средствам.
Примечание
Если пароль зашифрован, возможность его восстановления не предусмотрена. Необходимо ввести в конфигурацию новый пароль.
На рис. 25.2 приведена блок-схема, которая описывает процедуру восстановления пароля для следующих платформ:
маршрутизаторы Cisco CGS, MGS, AGS и AGS+, работающие под управлением программного обеспечения версии 9.1 (6) или предыдущих версий;
маршрутизаторы ряда Cisco 7000, загружаемые из ПЗУ, в которых эксплуатируется программное обеспечение версий, предшествующих версии 9.17(3).
Описанная ниже поэтапная процедура и блок-схема восстановления пароля, показанная на рис. 25.2, относятся только к указанным платформам, на которых эксплуатируется перечисленное выше программное обеспечение. Если на этих платформах эксплуатируется более современное программное обеспечение, то на них для восстановления пароля применяется другая процедура (см. раздел “Процедура восстановления пароля: платформы, на которых эксплуатируются новейшие версии программного обеспечения”).
Рис. 25.2. Процедура восстановления пароля: платформы, на которых эксплуатируются более ранние версии программного обеспечения
Примечание
Для выполнения этой процедуры необходимо иметь терминал или персональный компьютер (на котором работает программное обеспечение эмуляции терминала), связанный с консольным портом маршрутизатора.
Ниже приведена процедура восстановления пароля для платформ Cisco, на которых эксплуатируется более ранняя версия программного обеспечения Cisco IOS.
Шаг 1. Выключите маршрутизатор.
Шаг 2. Измените состояние аппаратного регистра конфигурации, переместив перемычку из позиции бита 0 или 1 в позицию бита 15.
Запишите, в каком положении перемычка находилась первоначально.
Примечание
Для перемещения перемычки аппаратного регистра конфигурации может потребоваться удалить плату процессора из корпуса маршрутизатора. Необходимость в этом возникает при использовании платы RP в маршрутизаторе ряда Cisco 7000. Для ознакомления с подробными инструкциями по удалению и последующей вставке платы процессора обратитесь к документации по конкретным аппаратным средствам. Если пришлось удалить плату процессора, вставьте ее снова, прежде чем перейти к дальнейшим действиям.
Шаг 3. Включите маршрутизатор. Появится приглашение к вводу информации монитора ROMmon (>).
Шаг ,4. Введите Ь (сокращение от bootstrap — начальная загрузка) в приглашении к вводу информации (>).
Шаг 5. Нажимайте клавишу <Return> до тех пор, пока не появится приглашение к вводу информации Test-System.
Шаг 6. Вызовите на выполнение ехес-команду enable и перейдите в режим ввода привилегированных ехес-команд.
Шаг 7. Введите привилегированную ехес-команду show configuration, чтобы определить, задан ли пароль открытым текстом (не зашифрован) или зашифрован. Если пароль задан открытым текстом, перейдите к шагу 12. Если пароль зашифрован, перейдите к шагу 8.
Шаг 8. Если пароль зашифрован, введите привилегированную ехес-команду configure memory, которая записывает хранимую конфигурацию в оперативную память.
Шаг 9. Введите привилегированную ехес-команду configure terminal, чтобы перейти в режим настройки конфигурации маршрутизатора.
Шаг 10. Если утрачен пароль enable, вызовите на выполнение глобальную команду конфигурации enable-password, чтобы ввести в конфигурацию новый пароль, и нажмите клавиши <Ctrl+Z>, чтобы выйти из режима настройки конфигурации.
Если утрачен пароль входа в систему, выполните настройку конфигурации канала консоли, введя в нее новый пароль с использованием команд конфигурации канала пароля login и password. Нажмите <Ctrl+Z>, чтобы выйти из режима настройки конфигурации.
Синтаксис
Чтобы разрешить проверку паролей при входе в систему, воспользуйтесь командой конфигурации канала login:
login [local | tacacs]
Описание синтаксиса
local. (Необязательный параметр.) Позволяет выбрать режим локальной проверки паролей. Аутентификация осуществляется по имени пользователя, указанного в глобальной команде конфигурации username.
tacacs. (Необязательный параметр.) Выбрать механизм проверки идентификатора и пароля пользователя в стиле TACACS.
Примеры
В следующем примере устанавливается пароль letmein в канале виртуального терминала 4:
line vty 4
password letmein
login
Синтаксис
Для задания пароля в канале применяется команда конфигурации канала password:
password password
Описание синтаксиса
password. Символьная строка, в которой задан пароль канала. Первый символ не может быть цифрой. Строка может содержать любые алфавитноцифровые символы, включая пробелы, и иметь длину до 80 символов. Пароль не может быть задан в формате “число — пробел — какие-либо иные символы”. Если в пароле после цифр стоит пробел, то при его обработке возникают проблемы. Например, hello 21 — допустимый пароль, а 21 hello — нет. При проверке пароля учитывается регистр. Например, пароль Secret считается иным по сравнению с паролем secret.
При запуске процесса обработки exec-команд в канале, который защищен паролем, интерпретатор exec-команд запрашивает пароль. Если пользователь вводит правильный пароль, интерпретатор exec-команд отображает свое обычное приглашение к вводу привилегированных exec-команд. Пользователь может три раза попытаться ввести пароль; после третьей неудачной попытки интерпретатор exec-команд завершает свою работу и терминал возвращается в неактивное состояние.
Пример
В следующем примере показано, как отменить защиту паролем для каналов виртуального терминала 1-4:
line vty 1 4
no password
Шаг 11. Вызовите на выполнение привилегированную exec-команду write memory, чтобы записать конфигурацию в оперативную память. Перейдите к шагу 13.
Шаг 12. Если утрачен пароль enable, найдите в составе конфигурации строку глобальной команды конфигурации enable-password и запишите пароль.
Если утрачен пароль входа в систему, найдите записи конфигурации для канала консоли и запишите пароль, заданный в команде конфигурации канала password. В это время не вносите изменения в конфигурацию и не используйте команду write memory.
Шаг 13. Выключите маршрутизатор.
Шаг 14. Удалите плату процессора и переместите аппаратную перемычку регистра конфигурации из позиции бита 15 в первоначальную позицию (позицию, которая была отмечена в шаге 2).
Шаг 15. Включите маршрутизатор. Воспользуйтесь новым или восстановленным паролем для получения доступа к маршрутизатору.
Процедура восстановления пароля: маршрутизатор IGS, на котором эксплуатируется версия программного обеспечения, предшествующая версии 9.1
В маршрутизаторах Cisco IGS имеется блок DIP-переключателей, расположенных на задней панели. Эти DIP-переключатели предназначены для настройки аппаратного регистра конфигурации и должны использоваться в процессе восстановления пароля, если в маршрутизаторе эксплуатируется версия системного программного обеспечения, предшествующая версии 9.1.
Примечание
Если пароль зашифрован, возможность его восстановления не предусмотрена. Необходимо ввести в конфигурацию новый пароль.
На рис. 25.3 показана процедура восстановления пароля для устройства Cisco IGS, на котором эксплуатируется версия программного обеспечения, предшествующая версии 9.1. Если на платформе IGS эксплуатируется версия программного обеспечения 9.1 или более поздняя, то для нее применяется другая процедура (см. раздел “Процедура восстановления пароля: платформы, на которых эксплуатируется текущая версия Cisco IOS”).
Примечание
Для выполнения этой процедуры необходимо иметь терминал или персональный компьютер (на котором работает программное обеспечение эмуляции терминала), связанный с консольным портом маршрутизатора.
Ниже приведена процедура восстановления пароля для маршрутизаторов IGS, на которых эксплуатируется версия программного обеспечения, предшествующая версии 9.1.
Шаг 1. Выключите маршрутизатор.
Шаг 2. Запишите, какие положения имеют контакты DIP-переключателей, находящихся на задней панели маршрутизатора. После восстановления пароля необходимо возвратить все контакты этих переключателей в первоначальное положение.
Шаг 3. Переведите контакт 7 в положение ON (вниз).
Шаг 4. Переведите контакты 0-3 в положение OFF (вверх).
Шаг 5. Включите маршрутизатор. Маршрутизатор загрузится, и на терминале появится приглашение к вводу информации монитора ROMmon (>).
Рис. 25.3. Процедура восстановления пароля: маршрутизатор 1GS, версия программного обеспечения, предшествующая версии 9.1Рис. 25.3. Процедура восстановления пароля: маршрутизатор 1GS, версия программного обеспечения, предшествующая версии 9.1на котором эксплуатируетсяна котором эксплуатируется
Рис. 25.3. Процедура восстановления пароля: маршрутизатор 1GS, версия программного обеспечения, предшествующая версии 9.1
Рис. 25.3. Процедура восстановления пароля: маршрутизатор 1GS, версия программного обеспечения, предшествующая версии 9.1
на котором эксплуатируется
на котором эксплуатируется
Шаг 6. Введите Ь (сокращение от bootstrap — начальная загрузка) в приглашении к вводу информации (>).
Шаг 7. Нажимайте клавишу <Return> до тех пор, пока не появится приглашение к вводу информации Test-System.
Шаг 8. Введите привилегированную ехес-команду enable в приглашении к вводу информации Test-System.
Шаг 9. Если пароль задан открытым текстом (не зашифрован), перейдите к шагу 14. Если пароль зашифрован, перейдите к шагу 10.
Шаг 10. Если пароль зашифрован, введите привилегированную ехес-команду configure memory. Эта команда записывает хранимую конфигурацию в оперативную память.
Шаг 11. Введите привилегированную ехес-команду configure terminal, чтобы перейти в режим настройки конфигурации маршрутизатора.
Шаг 12. Если утрачен пароль enable, вызовите на выполнение глобальную команду конфигурации enable-password, чтобы ввести в конфигурацию новый пароль, и нажмите клавиши <Ctrl+Z>, чтобы выйти из режима настройки конфигурации.
Если утрачен пароль входа в систему, выполните настройку конфигурации канала консоли, введя новый пароль с использованием команд конфигурации канала пароля login и password. Нажмите <Ctrl+Z>, чтобы выйти из режима настройки конфигурации.
Синтаксис
Чтобы разрешить проверку паролей при входе в систему, воспользуйтесь командой конфигурации канала login:
login [local | tacacs]
Описание синтаксиса
local. (Необязательный параметр.) Позволяет выбрать режим локальной проверки паролей. Аутентификация осуществляется по имени пользователя, указанного в глобальной команде конфигурации username.
tacacs. (Необязательный параметр.) Выбрать механизм проверки идентификатора и пароля пользователя в стиле TACACS.
Примеры
В следующем примере устанавливается пароль letmein в канале виртуального терминала 4:
line vty 4
password letmein
login
Синтаксис
Для задания пароля в канале применяется команда конфигурации канала password:
password password
Описание синтаксиса
password. Символьная строка, в которой задан пароль канала. Первый символ не может быть цифрой. Строка может содержать любые алфавитно-цифровые символы, включая пробелы, и иметь длину до 80 символов. Пароль не может быть задан в формате “число — пробел — какие-либо иные символы”. Если в пароле после цифр стоит пробел, то при его обработке возникают проблемы. Например, hello 21 — допустимый пароль, а 21 hello — нет. При проверке пароля учитывается регистр. Например, пароль Secret считается иным по сравнению с паролем secret.
При запуске процесса обработки exec-команд в канале, который защищен паролем, интерпретатор exec-команд запрашивает пароль. Если пользователь вводит правильный пароль, интерпретатор exec-команд отображает свое обычное приглашение к вводу привилегированных exec-команд. Пользователь может три раза попытаться ввести пароль; после третьей неудачной попытки интерпретатор exec-команд завершает свою работу и терминал возвращается в неактивное состояние.
Пример
В следующем примере показано, как отменить защиту паролем для каналов виртуального терминала 1—4:
line vty 1 4
no password
Шаг 13. Введите привилегированную exec-команду write memory, чтобы записать изменения конфигурации в ПЗУ. Перейдите к шагу 16.
Шаг 14. Если пароль задан открытым текстом (не зашифрован), введите привилегированную exec-команду show configuration.
Шаг 15. Если утрачен пароль enable, найдите в составе конфигурации строку глобальной команды конфигурации enable-password и запишите пароль.
Если утрачен пароль входа в систему, найдите записи конфигурации для канала консоли и запишите пароль, заданный в команде конфигурации канала password. В это время не вносите изменения в конфигурацию и не используйте команду write memory.
Шаг 16. Выключите маршрутизатор.
Шаг 17. Верните контакты DIP-переключателя аппаратного регистра конфигурации, находящегося на задней панели маршрутизатора, в первоначальные положения (положения, которые были записаны в шаге 2).
Шаг 18. Включите маршрутизатор. Воспользуйтесь новым или восстановленным паролем для получения доступа к маршрутизатору.
Процедура восстановления пароля: сервер связи Cisco 500-CS
В сервере связи Cisco 500-CS не предусмотрена возможность восстановления утраченных паролей. Единственный способ ввода в этом сервере связи нового пароля вместо утраченного состоит в восстановлении заводских установок конфигурации с использованием кнопки Reset, находящейся в верхней части корпуса.
Ниже описана процедура, применяемая для восстановления в устройстве Cisco 500-CS конфигурации, заданной по умолчанию.
Предостережение
После выполнения этой процедуры текущая конфигурация будет потеряна.
Шаг 1. Выключите сервер связи.
Шаг 2. Нажмите и удерживайте кнопку Reset в верхней части корпуса во время включения питания на сервере связи.
Шаг 3. В устройстве 500-CS будут восстановлены заводские установки конфигурации.
После этого необходимо снова выполнить настройку конфигурации сервера связи.
Часть
VII
риложенияриложенияожени.ожени.
риложения
риложения
ожени.
ожени.
“Формирование дампа ядра”
“Схемы распределения памяти”
^Информация о технической поддержке
Приложение
А
t Формирование дампа ядра
" После аварийного завершения работы маршрутизатора иногда возникает необходимость получить полную копию образа его оперативной памяти (называемую дампом ядраУ^ля определения причины неисправности. Дамп ядра обычно оказывает весьма значительную помощь в работе представителя службы технической поддержки. Дамп ядра формируется не во всех случаях аварийного завершения работы. Различные типы ._ i аварийного завершения работы рассматриваются более подробно в приложении Б I. “Схемы распределения памяти”.
. Предостережение
„ Команды, описанные в настоящем приложении, следует применять только под руко-
* водством представителя службы технической поддержки. Формирование дампа ядра А в процессе работы маршрутизатора в сети может нарушить функционирование сети.
Основные способы настройки конфигурации
Для настройки конфигурации маршрутизатора в целях формирования дампа ядра могут применяться следующие четыре основных способа.
; Использование протокола TFTP.
)’^‘" , Использование протокола FTP (File Transfer Protocol — протокол передачи файлов).
■ Использование протокола RCP.
Применение флэш-диска.
Использование протокола FTP
^^^''Дсли для вывода дампа ядра на TFTP-сервер применяется протокол TFTP, то а маршрутизатор выводит только первые 16 Мбайт файла дампа ядра. Это ограничение распространяется на большую часть приложений TFTP. Поэтому если объем оперативной памяти маршрутизатора превышает 16 Мбайт, то применение протокола TFTP нё рекомендуется.
- Ниже приведена команда конфигурации маршрутизатора, необходимая для полу- < чения дампа ядра с использованием протокола TFTP.
exception dump a.b.c.d
Здесь a.b.c.d — IP-адрес TFTP-сервера.
Дамп ядра записывается на TFTP-сервере в файл с именем hostname-core, где hostname — имя маршрутизатора. Для изменения имени этого файла дампа ядра можно дополнительно ввести команду конфигурации exception core-file filename.
В зависимости от применяемого приложения TFTP-сервера может потребоваться создать на TFTP-сервере пустой файл, в который дамп ядра будет записываться маршрутизатором. Кроме того, необходимо проверить, имеется ли на TFTP-сервере достаточный объем памяти для хранения всего дампа ядра.
Использование протокола FTP
Для настройки конфигурации маршрутизатора в целях передачи дампа ядра с использованием протокола FTP предназначены следующие команды конфигурации:
ip ftp usename username;
ip ftp password password;
exception protocol ftp;
exception dump a.b.c.d.
Здесь a.b.c.d — IP-адрес FTP-сервера. Если в конфигурации не заданы имя пользователя и пароль, то маршрутизатор предпримет попытку использовать анонимную учетную запись FTP.
Использование протокола RCP
Для передачи дампа ядра на другое устройство может также применяться протокол RCP. Но в настоящем приложении не показано, как разрешить применение протокола RCP в маршрутизаторе. Информация по настройке протокола RCP содержится в документе Cisco IOS Software Configuration.
После того как в маршрутизаторе будет разрешено применение протокола RCP, необходимо ввести следующие команды, чтобы обеспечить передачу дампа ядра по протоколу RCP:
exception protocol RCP;
exception dump a.b.c.d.
Здесь a.b.c.d — IP-адрес хоста, для которого разрешено применение протокола RCP.
Применениефлэш-диска
На некоторых платформах маршрутизаторов вместо линейной флэш-памяти или флэш-платы PCMCIA могут применяться флэш-диски. Поскольку такие флэш-диски отличаются большой емкостью, они хорошо подходят для использования в качестве альтернативного средства записи дампа ядра. Дополнительная информация о платформах маршрутизаторов и версиях IOS, которые поддерживают флэш-диски, приведена в документе Cisco IOS Release Notes.
Ниже приведена команда конфигурации маршрутизатора, необходимая для настройки средств записи дампа ядра с использованием флэш-диска.
exception flash <procmem|iomem] all> <device_name[:partition_number]> <erase | no erase>
Для получения списка устройств, которые могут быть указаны в команде exception flash, предназначена команда show flash all.
Дополнительные команды конфигурации
В настоящем разделе описаны команды конфигурации, которые могут применяться в качестве дополнения к командам конфигурации, приведенным в разделе “Основные способы настройки конфигурации”.
Команды exception memory
В процессе отладки некоторые действия пользователя могут вызвать формирование маршрутизатором дампа ядра и перезагрузку в случае выхода за пределы допустимых параметров определения объема памяти. Для активизации процесса формирования дампа ядра применяются следующие команды exception memory:
exception memory minimum size
Приведенная выше команда используется для определения минимального объема пула свободной памяти.
exception memory fragment size
Приведенная выше команда используется для определения минимального количества смежных блоков памяти в пуле свободной памяти.
Значение параметра size задается в байтах и проверяется через каждые 60 секунд. Если в этой команде будет указано значение, превышающее объем свободной памяти, и в состав конфигурации входит команда exception dump, то через каждые 60 секунд будет формироваться дамп ядра и перезагружаться маршрутизатор. Если же команда exception dump не входит в состав конфигурации, то маршрутизатор перезагружается без формирования дампа ядра.
Команда debug sanity
В некоторых случаях представитель службы технической поддержки может потребовать, чтобы в процессе настройки конфигурации для формирования дампа ядра было разрешено применение команды debug sanity. В большинстве версий IOS эта команда скрыта, но иногда возникает необходимость в ее использовании для устранения нарушений в работе, связанных с искажением содержимого памяти. Если применение команды debug sanity разрешено, то выполняется проверка правильности содержимого каждого буфера в системе в процессе его распределения и освобождения.
Команда debug sanity должна быть вызвана на выполнение в режиме привилегированных exec-команд (в режиме enable) и требует расхода определенного объема ресурсов процессора. Но в целом она почти не ухудшает функциональные характеристики маршрутизатора.
Необходимость в использовании команды debug sanity возникает не при всех типах аварийного завершения работы. Эта команда должна применяться, только если соответствующее требование получено от представителя службы технической поддержки.
Чтобы отменить применение команды debug sanity, воспользуйтесь привилегированной exec-командой undebug sanity.
Проверка результатов настройки конфигурации для формирования дампа ядра
Иногда после настройки конфигурации маршрутизатора на формирование дампа ядра может потребоваться проверка того, успешно ли выполнена такая настройка.
В системе IOS предусмотрена специальная команда для проверки или активизации вывода дампа ядра:
write core
Эта команда применяется в режиме выполнения привилегированных ехес-команд (в режиме enable). Она вызывает аварийное завершение работы маршрутизатора и, соответственно, дамп содержимого его памяти. Если же дамп ядра не формируется, то необходимо еще раз проверить настройку конфигурации.
Предостережение
Команда write core может нарушить функционирование производственной сети. Она вызывает аварийное завершение работы маршрутизатора и замедление перехода в рабочий режим (так как сначала должен быть выполнен вывод содержимого его памяти). Это может потребовать определенных затрат времени, в зависимости от объема динамического ОЗУ маршрутизатора. Поэтому эту команду следует применять весьма осмотрительно.
Приложение
Б
Схемы распределения памяти
В настоящем приложении представлены схемы распределения памяти для отдельных выпускаемых платформ, процессоров и интерфейсных плат. Такие схемы могут применяться подготовленными пользователями, которые обладают знаниями по организации-работы операционных систем, структурам шин и преобразованию адресов в „комп ьюте^ных ^стемах.
Поиск^ейеИравностей при аварийном завЙ^ен&работы
В
При аварийном- завершении работы системы программное обеспечение режима OMmon обнаруживает^ошибку, выводит сообщение на консоль и записывает в па- (^мять информацию стекала момент аварийного отказа. Такую информацию, полученную во время аварийного завершения работы, принято называть трассировкой стека,
1 г1 ги -для ее просмотра используется команда show stack. Эти данные при перезагрузке системы стираются, поэтому необходимо сразу же проверять значения регистров конфиГурации изыскать способы предотвращения дальнейших аварийных отказов системы.1 Трассирбвки’-стекЬв^огут применяться квалифицированными представителями службы ТехническийПоддержки, которые имеют доступ к таблицам символических гр.»имен, объектным файлам и исходному коду, необходимому для декодирования стека. Л" При использовании настоящего приложения следует учитывать различия между значениями счетчика команд и адресами операндов. На рис. Б.1 показана часть вывода команды show "stacks-которая позволяет проиллюстрировать это различие.
1 г
1 г
Тип аварийного отказа — ошибка шины
System wfeiJtestarted by bus error at PC 0xD31CA, address 0xl84E0006
Счетчик программы — PC 0xD31CA Адрес операнда — 0x184E006
Рис. Б^. Вывод команды show stack, который позволяет подчеркнуть разли- . чие между значениями счетчика команд и адресами операндов
Примечание
Адреса, приведенные в данном приложении, представляют собой адреса операндов, и их не следует путать со значениями счетчика команд. Если не указано иное, то все адреса памяти приведены в виде шестнадцатеричных чисел.
Схемы распределения памяти могут применяться при определении того, возникло ли нарушение в работе программного или аппаратного обеспечения. Системное программное обеспечение может предоставить информацию о причинах аварийного завершения работы системы.
Следует всегда сохранять результаты выполнения команд show stack, show version и show run, а также журналы. Дополнительную информацию может также предоставить вывод команды show tech, особенно на платформах ряда Cisco 7500 и 7200.
Типы аварийных отказов и их причины
Основные типы аварийных отказов перечислены ниже.
Ошибки шины и исключения SegV.
Аварийные отказы, возникшие в результате работы программного обеспечения.
Ошибки адресации.
Контрольные тайм-ауты.
Ошибки контроля четности.
Другие типы аварийных отказов.
Эти типы аварийных отказов подробно рассматриваются в следующих разделах.
Ошибки шины и исключения SegV
Ошибки шины и исключения SegV относятся к наиболее распространенным типам аварийных отказов. Они возникают, если процессор пытается обратиться к адресу, отображенному на память, который либо не существует (ошибка программного обеспечения), либо не обеспечивает своевременное формирование ответа (нарушение в работе аппаратных средств). Исключения SegV возникают только в процессорах RISC, если не существует адрес, отображенный на память.
Тип процессора (RISC или 68000) можно определить с помощью команды show version.
На рис. Б.2 показана важная информация, которая представлена в выводе команды show version, полученном на двух разных маршрутизаторах.
cisco 3640 (R4700) processor (revision 0x00) with 49152K/16384K bytes of memory.
t
R указывает на процессор RISC
cisco 2500 (68030) processor (revision D) with 8192K/2048K bytes of memory.
t
Это значение указывает на процессор, отличный от RISC
Рис. Б.2. Важная информация в выводе команды show version, полученном на двух разных маршрутизаторах
Определенную информацию о том, произошел ли сбой в программном или аппаратном обеспечении, предоставляет адрес, к которому процессор пытался обратиться, когда произошел аварийный отказ системы.
Что касается процессоров 68000, то если адрес операнда представляет собой действительный адрес физической памяти в схеме распределения памяти, то нарушение в работе скорее всего возникло в аппаратном обеспечении. Ошибки шины, возникающие при попытке обратиться по адресу, который отсутствует в схеме распределения памяти, обычно указывают на ошибку программного обеспечения. Для анализа причин отказа получите декодированный вывод команды show stack.
На процессоры RISC не распространяется правило, которое гласит, что если адрес действителен, то причиной ошибок адресации являются аппаратные средства. Это связано с тем, что при использовании таких процессоров некоторые области памяти не поддерживают все типы доступа процессора, и аппаратные средства вполне оправданно активизируют исключение, если в программном обеспечении по ошибке применяется недопустимый режим доступа. В системах с процессорами RISC не предусмотрен непосредственный доступ к физическим адресам, т.е. используются виртуальные адреса. Прежде чем заменять аппаратные средства на основании того, что возникла ошибка адресации, получите от опытного специалиста подтверждение такой необходимости.
Принудительный аварийный отказ, активизированный программным путем
В системе IOS маршрутизатора предусмотрены некоторые процедуры проверки работоспособности, которые часто используются для защиты от различных искажений.. информации и бесконечных циклов. Обнаружив искажение данных или кода В"памяти или определив, что возник бесконечный цикл, система IOS инициирует собственное аварийное завершение, вызывая процедуры crashdump, и предпринимает попытку записи файла ядра. Для анализа причин отказа получите декодированный вывод команды show stack. Если декодированные результаты показывают, что произошло искажение информации в памяти, то для определения причины такого искажения могут потребоваться дополнительные данные, такие как дамп ядра. Дополнительные сведения о том, как выполнить настройку конфигурации маршрутизатора для формирования дампа ядра, приведены в приложении А “Формирование дампа ядра”.
Ошибка в адресе
Ошибки адресации возникают при попытке программного обеспечения обратиться к данным с использованием неправильно выровненных границ в памяти. Например, доступ с применением команд, имеющих двух- и четырехбайтовый форматы операндов, разрешается только с использованием четных адресов. Ошибки адресации обычно указывают на дефект в программном обеспечении.
Контрольный тайм-аут
Процессоры Cisco оборудованы таймерами, которые служат для защиты системы от зависаний некоторых типов. Процессор периодически сбрасывает контрольный таймер. Если своевременный сброс таймера не происходит, то возникает прерывание. Процессор не способен обслуживать контрольный таймер, только если есть дефект в аппаратном или программном обеспечении.
Ошибка четности
Ошибки контроля четности указывают, что внутренняя проверка аппаратных ошибок окончилась неудачно. Неудачное завершение операции контроля четности почти всегда возникает из-за нарушения в работе аппаратных средств. Воспользуйтесь схемами распределения памяти, перечисленными ниже, чтобы определить, в каком аппаратном компоненте возникла соответствующая ошибка.
Другие типы аварийных отказов
В процессе работы могут также возникать аварийные отказы многих других типов, но они встречаются гораздо реже. Некоторые из них могут быть вызваны сбоями в работе аппаратных средств, а другие — искажением в памяти кода и вызовом его на выполнение еще до того, как это искажение было обнаружено процедурами IOS. Для поиска программных процедур, которые вызвали аварийный отказ, необходимо использовать упомянутые выше результаты расшифровки стека.
Схемы распределения памяти
В следующих таблицах приведена общая информация по схемам распределения памяти на различных платформах Cisco.
В табл. Б.1 представлена схема распределения памяти Cisco 12000-GRP.
В табл. Б.2 представлена схема распределения памяти линейной платы Cisco 12000.
В табл. Б.З представлена схема распределения памяти Cisco 8540CSR.
. В табл. Б.4 представлена схема распределения памяти Cisco RSP.
В табл. Б.5 представлена схема распределения памяти Cisco RSP4.
В табл. Б.6 представлена схема распределения памяти Cisco 7000 ряда RP.
В табл. Б.7 представлена схема распределения памяти Cisco 7200 ряда NPE.
В табл. Б.8 представлена схема распределения памяти Cisco 7100.
В табл. Б.9 представлена схема распределения памяти Cisco 6400-NRP.
В табл. Б. 10 представлена схема распределения памяти Cisco 6400-NSP.
В табл. Б.11 представлена схема распределения памяти Cisco 6200.
В табл. Б. 12 представлена схема распределения памяти Cisco 6260.
В табл. Б. 13 представлена схема распределения памяти Cisco 4000-М.
В табл. Б. 14 представлена схема распределения памяти Cisco 4500-4700.
В табл. Б. 15 представлена схема распределения памяти Cisco 3620.
В табл. Б. 16 представлена схема распределения памяти Cisco 3640.
В табл. Б. 17 представлена схема распределения памяти Cisco 3660.
В табл. Б. 18 представлена схема распределения памяти Cisco 2600.
В табл. Б. 19 представлена схема распределения памяти Cisco 2500.
В табл. Б.20 представлена схема распределения памяти 1720 Cisco.
В табл. Б.21 представлена схема распределения памяти Cisco 1600.
В табл. Б.22 представлена схема распределения памяти Cisco 1400.
В табл. Б.23 представлена схема распределения памяти Cisco AS5200.
В табл. Б.24 представлена схема распределения памяти Cisco AS5300.
В табл. Б.25 представлена схема распределения памяти Cisco AS5800.
В табл. Б.26 представлена схема распределения памяти Cisco 1000, 1003/1004/1005.
В табл. Б.27 представлена схема распределения памяти Cisco VIР2.
Общая адресация MIPS
Большинство отображенных адресов представляет собой виртуальные адреса, которые должны интерпретироваться в соответствии со схемой распределения виртуальной памяти на определенной платформе. Но в некоторых сообщениях содержатся не виртуальные, а физические адреса. В качестве примера можно привести сообщение об ошибках шины. Надежного способа определения по самому адресу, является ли он виртуальным или физическим, не существует; необходимо знать, в каком контексте были получены представленные результаты.
I Таблица Б.1. Схема распределения виртуальной памяти GRP •
Адрес
Описание
BFC00000-BFC7FFFF
Загрузочное ППЗУ
B7000000-B7FFFFFF
Плата PCMCIA
A0000000-A7FFFFFF
Альтернативное отображение первых 128 Мбайт динамического ОЗУ, используемого в режиме ROMmon
60000000-7FFFFFFF
Динамическое ОЗУ, представляющее до 512 Мбайт оперативной памяти
3E850000-3E857FFF
Интерфейс Ethernet
3E84A000-3E84BFFF
Приемные регистры коммутационной структуры
3E848000-3E849FFF
Передающие регистры коммутационной структуры
3E840000-3E841FFF
Регистры ввода-вывода
3E000000-3E07FFFF
Энергонезависимое ОЗУ конфигурации
38000000-39FFFFFF
Внутренняя микросхема SIMM флэщ-памяти
28090000-28097FFF
Программируемая логическая матрица интерфейса коммутационной структуры
28000000-2807FFFF
Память интерфейса коммутационной структуры
> ‘" ^ „ >* • --;--<. ^ • г- • ’ v#- ^- K"*s’ "’/' '-'
Таблйца Б.1,а. Физическая схема распределения памяти GRP
Адрес
Описание
60000000-7FFFFFFF
Динамическое ОЗУ, представляющее до 512 Мбайт оперативной памяти
1FC00000-1FC7FFFF
Загрузочное ППЗУ
1E850000-1E857FFF
Интерфейс Ethernet
1E84A000-1E84BFFF
Приемные регистры коммутационной структуры
1E848000-1E849FFF
Передающие регистры коммутационной структуры
1E840000-1E841FFF
Регистры ввода-вывода
1E000000-1E07FFFF
Энергонезависимое ОЗУ конфигурации
18000000-19FFFFFF
Внутренняя микросхема SIMM флэщ-памяти
17000000-17FFFFFF
Плата PCMCIA
08090000-08097FFF
Программируемая логическая матрица интерфейса коммутационной структуры
08000000-0807FFFF
Память интерфейса коммутационной структуры
00000000-07FFFFFF
Первые 128 Мбайт динамического ОЗУ оперативной памяти
Схема распределения памяти линейной платы 12000
Сокращения
FIA (switch Fabric Interface ASIC — специализированная микросхема интерфейса коммутационной структуры).
ВМА (Buffer Management ASIC — специализированная микросхема управления буферизацией данных).
L3 (Layer 3 ASIC — специализированная микросхема уровня 3).
MBUS (Maintenance BUS — шина обслуживания).
PLIM (Physical Layer Interface Module — модуль интерфейса физического уровня).
Таблица Б.2. Схема распределения виртуальной памяти линейной плата
Адрес
Описание
BFCOOOOO-BFCFFFFF
Загрузочное ПЗУ
A0000000-B7FFFFFF
Альтернативное отображение первых 128 Мбайт динамического ОЗУ, используемого в режиме ROMmon
80000000-87FFFFFF
Альтернативное отображение первых 128 Мбайт динамического ОЗУ, используемого процедурой поддержки режима ROMmon и планировщиком IOS
40000000-7FFFFFFF
Вплоть до 512 Мбайт оперативной памяти
30000000-3FFFFFFF
Синхронное динамическое ОЗУ приема (область памяти для хранения пакетов)
20000000-2FFFFFFF
Синхронное динамическое ОЗУ передачи (область памяти для хранения пакетов)
12000000-17FFFFFF
Адресное пространство PLIM
11C00000-11FFFFFF
Адресное пространство MBUS
11800000-11BFFFFF
Адресное пространство специализированной микросхемы FIA приема
11400000-117FFFFF
Адресное пространство специализированной микросхемы FIA передачи
10C00000-113FFFFF
Адресное пространство специализированной микросхемы ВМА приема
10400000-10BFFFFF
Адресное пространство специализированной микросхемы ВМА передачи
10000000-103FFFFF
Адресное пространство специализированной микросхемы L3
[ Таблица Б.2,а. Физическая схема распределения памяти линейной платы И
Адрес
Описание
EOOOOOOO-EFFFFFFF
Синхронное динамическое ОЗУ приема (область памяти для хранения пакетов)
COOOOOOO-CFFFFFFF
Синхронное динамическое ОЗУ передачи (область памяти для хранения пакетов)
40000000-7FFFFFFF
Вплоть до 1 Гбайт оперативной памяти
1FC00000-1FFFFFFF
Загрузочное ПЗУ
12000000-17FFFFFF
Адресное пространство РЫМ
11C00000-11FFFFFF
Адресное пространство MBUS
11800000-11BFFFFF
Адресное пространство специализированной микросхемы FIA приема
Адрес
Описание
11400000-117FFFFF 10C00000-113FFFFF 10400000-10BFFFFF 10000000-103FFFFF O00O0000-0FFFFFFF
Адресное пространство специализированной микросхемы FIA передачи Адресное пространство специализированной микросхемы ВМА приема Адресное пространство специализированной микросхемы ВМА передачи
Адресное пространство специализированной микросхемы L3 Первые 256 Мбайт оперативной памяти (EDO динамического ОЗУ)
Схема распределения памяти Catalyst 8540CSR
^Таблица Б.З. Схема распределения памяти Catalyst 8540CSRj
Имя адресного пространства
Байтовый адрес начало/ конец
Объем
Примечание
Назначение
Динамическое
0000
0000
128
Псевдоним ад-
Применяется в качестве основного
ОЗУ
07FF
FFFF
Мбайт
реса 6000 0000
динамического ОЗУ, в котором хранятся данные и программы
Запоминающее
0800
0000
16
Псевдоним адре-
Содержит данные сообщений, пере-
устройство
MEMD
08FF
0900
0FFF
FFFF
ОООО
FFFF
Мбайт
112 Мбайт
сов 4000 0000 и 5000 0000
даваемых в прямом и обратом направлении из процессора и коммутационной структуры
Недопустимый адрес; доступ вызывает ошибку шины или прерывание
Область памяти
1000
0000
256
Псевдоним адре-
ввода-вывода
1FFF
FFFF
Мбайт
са 3000 0000
Пустая область
2000
0000
256
Недопустимый адрес; доступ вызы-
памяти
2FFF
FFFF
Мбайт
вает ошибку шины или прерывание
Область памяти
3000
0000
256
Псевдоним адре-
ввода-вывода
3FFF
FFFF
Мбайт
са 1000 0000
Запоминающее
4000
0000
16
Псевдоним адре-
Содержит данные сообщений, пере-
устройство
MEMD
40FF
4100
4FFF
FFFF
0000
FFFF
Мбайт
240
Мбайт
сов 0800 0000 и 5000 0000
даваемых в прямом и обратом направлении из процессора и коммутационной структуры
Недопустимый адрес; доступ вызывает ошибку шины или прерывание
5000
0000
16
Псевдоним адре-
Содержит данные сообщений, пере-
50FF
5100
5FFF
FFFF
0000
FFFF
Мбайт
240
Мбайт
сов 0800 0000 и 4000 0000
даваемых в прямом и обратом направлении из процессора и коммутационной структуры
Недопустимый адрес; доступ вызывает ошибку шины или прерывание
Динамическое
6000
0000
128
Псевдоним адре-
Применяется в качестве основного
ОЗУ
67FF
FFFF
Мбайт
са 0000 0000
динамического ОЗУ, в котором хранятся данные и программы
Имя адресного Байтовый Объем Примечание Назначение пространства адрес начало/ конец
6800 0000
7FFF FFFF
384
Мбайт
Это пространство не доступно по адресу 0000 0000
Пустая область
8000 0000
2048
Недопустимый адрес; доступ вызы-
памяти
FFFF FFFF
Мбайт
вает ошибку шины или прерывание
Ьгаблйца Б.З,а. Таблица физическжадресфвпространстваMEMO
Физическое устройство
Байтовый адрес начало/ конец
Объем
Разрядность (бит)
Назначение
SARSRAM
0800 0000
1 Мбайт
64
08OF FFFF
Отсутствует
0810 0000
14 Мбайт
64
08DF FFFF
Программируемая
08Е0 0000
1 Мбайт
64
Управляющие регистры и ре-
логическая матри-
08EF FFFF
гистры состояния программи-
ца CUBI
руемой логической матрицы
CUBI
Программируемая
08F0 0000
1 Мбайт
64
Управляющие регистры и ре-
логическая матри-
08FF FFFF
гистры состояния программи-
ца CUBI
руемой логической матрицы
CUBI
ГОмжЙД^^ физических адресов пространства ввода-вывода
Физическое устройство
Байтовый адрес начало/ конец
Объем
Разрядность (бит)
Назначение
Отсутствует
1000 0000
16FF FFFF
Платы PCMCIA
1700 0000
17FF FFFF
16 Мбайт
16
Доступ к содержимому плат, вставленных в гнезда PCMCIA
Точный адрес, по которому будет представлено содержимое плат, должен быть запрограммирован с помощью контроллера PCMCIA. Пространства адресов плат, превышающие по объему 16 Мбайт, могут использоваться с помощью схемы организации окон, которая поддерживается контроллером PCMCIA
Физическое устройство
Байтовый адрес начало/ конец
Объем
Разрядность (бит)
Назначение
Флэш-память
1800 0000
64 Мбайт
32
Сокет SIMM с проводной раз-
на микросхеме
1BFF FFFF
водкой для одной микросхемы
SIMM
флэш-памяти SIMM на 32 бита. Эта проводная разводка поддерживает объем памяти 32 Мбайт, но фактически во время изготовления данного изделия в него может быть вставлена микросхема, выбранная пользователем. Эта микросхема SIMM может содержать загрузочный образ системы, информацию о конфигурации и т.д. иными словами, любое программное обеспечение, которое пожелает разместить в ней пользователь
Шина РАМ
1С00 0000
1CFF FFFF
16 Мбайт
32
См. таблицу пространства РАМ
Шина SWC
1D00 0000
1DFF FFFF
16 Мбайт
16
См. таблицу пространства SWC
Энергонезави-
1Е00 0000
512 Кбайт-1
8
Энергонезависимое статиче-
симое ОЗУ
1Е07 FFFE
ское ОЗУ, которое может применяться для хранения любого необходимого программного обеспечения
Истинное время
1Е07 FFFF
1 байт
1
Это энергонезависимое ОЗУ предоставляет доступ для чтения к функции TOD (Time Of Day — истинное время) через
то же адресное пространство, что и к самому энергонезависимому ОЗУ
Отсутствует
1Е08 0000
1Е83 FFFF
Специализиро-
1Е84 0000
256 байт
16
Управляющие регистры и ре-
ванная микро-
1Е84 00FF
гистры состояния типа Tiger
схема
типа Tiger
CI DR FPGA
1E84 0100
512 байт
16
Различные управляющие реги-
1E84 02FF
стры и регистры состояния
Отсутствует
1E84 0300
1E84 03DF
Физическое устройство
БайтовыйОбъемРазрядность Назначение
адрес(бит)
начало/ конец
Контроллер
PCMCIA
1Е84 03Е02 байт8Управляющие регистры и ре-
(индекс)гистры состояния для на-
1Е84 03Е1стройки конфигурации плат
(данные)PCMCIA. Это — одна из тех
замечательных микросхем, в которую можно записать содержимое индексного регистра, а затем обращаться к регистру данных с использованием содержимого этого индексного регистра в качестве адреса
Отсутствует
1Е84 03Е2
1Е84 03FF
Сдвоенный универсальный асинхронный приемопередатчик (DUART) Отсутствует
1Е84 0400128 байт8Сдвоенный приемопередатчик
1Е84 047FUART для поддержки порта
консоли и обмена внеочередными сообщениями между процессорами RP
1Е84 0480
1Е84 FFFF
Контроллер
Ethernet
1Е85 000064 Кбайт 16Интерфейс Ethernet на 10
1Е85 FFFFМбит/с
Ethernet SRAM
1Е86 0000128 Кбайт 32
1Е87 FFFF
Модуль сетевых часов
1Е88 0000256 байт8
1Е88 00FF
Отсутствует
1Е88 0100
1FBF FFFF
Загрузочное флэш-ППЗУ
1FC0 0000 512 Кбайт 8 Пространство памяти для на- 1FC7 FFFF чального кода запуска R5000.
Эта часть реализована в виде флэш-памяти и может быть перезаписана в системе
Отсутствует
1FC8 0000
1FFF FFFF
Схема распределения памяти RSP
! Таблица Б.4. Схема распределения памяти RSP
Адрес
Разрядность (бит)
Описание
80000000-FFFFFFFF
Доступно для расширения
60000000-77FFFFFF
Оперативная память
Обшая область памяти
Адрес
Разрядность (бит)
Описание
40000000-5FFFFFFF
Биты упорядочения битов канонического адреса памяти для хранения пакетов с перестановкой байтов
Общая область памяти
38000000-3FFFFFFF
Загрузочное ППЗУ и пространство ввода-вывода
30000000-37FFFFFF
Системная флэш-память
20000000-2FFFFFFF
Зарезервированное адресное пространство, зависящее от платформы
18000000-1FFFFFFF
Загрузочное ППЗУ и пространство ввода-вывода
10000000-17FFFFFF
Системная флэш-память
08000000-0FFFFFFF
Область памяти для хранения пакетов
00000000-07FFFFFF
Оперативная память
Отдельные адреса:
11110000
16
Системная управляющая информация
11110100
32
Информация о состоянии системы
11120000
8
Таймер счетчика
11120040
8
Управляющий регистр счетчика
11120100-1112013F
8
Последовательные порты ввода-вывода
11120200
16
Управляющая информация датчика контроля внешней среды
11120300
32
Информация о состоянии датчика контроля внешней среды
1115FFFF
1
Календарь (один бит, обозначенный как “бит 0”)
111104000
8
Информация о состоянии платы флэш памяти
Виртуальные адреса:
Е00000
Гнездо 0
Е20000
Гнездо 1
Е40000
Гнездо 2
Е60000
Гнездо 3
Е80000
Гнездо 4
EA0000
Гнездо 5
EC0000
Гнездо 6
EE0000
Гнездо 7
F00000
Гнездо 8
F20000
Гнездо 9
F40000
Гнездо 10
F600O0
Гнездо 11
F80000
Гнездо 12
Схема распределения памяти RSP4
Табл!
^'AMS- <4
хца Б.5.
Схема
распред
эления памяти Ft^$P4e
Базовый адрес памяти
Максимальный адрес памяти
ОбъемУстройство
0x0000
0000
0X07FF
FFFF
ДоОперативная память
128 Мбайт
0x0800
0000
0X0F00
0000
До 128Область памяти для хранения пакетов
Мбайт
0x1000
0000
0X16FF
FFFF
Системная флэш-память
0x1700
0000
0X17FF
FFFF
Гнезда PCMCIA
0x1800
0000
OxlBFF
FFFF
Загрузочная флэш-память Rx
0х1С00
0000
OxlDFF
FFFF
Гнездо для микросхемы управления вводом-выводом
OxlEOO
0000
0X1E7F
FFFF
Энергонезависимое ОЗУ
0Х1Е80
0000
OxlEFF
FFFF
Регистры ввода-вывода
OxlFOO
0000
OxlFFF
FFFF
Загрузочное ППЗУ
0x2000
0000
0x2FFF
FFFF
Зарезервировано. Адресное пространство, зависящее от платформы
0x3000
0000
0x37FF
FFFF
128 Мбайт Системная флэш-память
0x3800
0000
0x3FFF
FFFF
Загрузочное стираемое ППЗУ и пространство ввода-вывода
0x4000
0000
0x5FFF
FFFF
Область памяти для хранения пакетов
0x6000
0000
0x7FFF
FFFF
Оперативная память
0x8000
0000
OxFFFF
FFFF
Доступно для расширения
Схема распределения памяти процессора RP устройства Cisco 7000
Таблицам. Схема распределения памяти процессора RP устройства
л-Ли^ШжйИШ2лОЬжла^^и«^л«Л--^®мДМи.«^х^^
Адрес
Разрядность ОписаниеПримечание
(бит)
00000000-0FFFFFFF
10000000-100FFFFF
10400000-104FFFFF
11000000-110FFFFF
Динамическое ОЗУ
ROML
ROMU
Область памяти шины
MULTIBUS
11100000-1110FFFF
Область ввода-вывода шины MULTIBUS
11110000-1112FFFF
11130000-11130FFF
11131000-111314FF
11140000-1115FFFF
Локальный ввод-вывод Диагностическая шина ППЗУ идентификатора Энергонезависимое ОЗУ
Адрес
Разрядность (бит)
ОписаниеПримечание
12000000-13FFFFFF
14000000-15FFFFFF
Внутренняя флэш-память
Внешняя плата флэш-памяти
11110000
16
Системная управляющая информация
11110100
11110400
11110С00
32
Системный регистр состояния
Состояние платы флэш-памяти
Базовый адрес области ввода- Адресное пространство выводаSwitchBus. Каждый мо
дуль занимает 64 байта (0x40)
11120000
8
Таймер счетчика
11120040
8
Управляющий регистр счетчика
11120100-1112013F
11120200
11120300
11130000
11131000
11140000
1115FC00
8
Последовательные порты ввода- вывода
Управляющая информация дат- 16 битов чика контроля внешней среды
Информация о состоянии дат- 32 бита чика контроля внешней среды
Диагностическая шина
ППЗУ идентификатора
Энергонезависимое ОЗУ
Базовый адрес энергонезависимого ОЗУ датчика контроля внешней среды
1115FFFF
11200000-11FFFFFF
12000000
14000000
1
Бит управления календарем в Один бит (бит 0) реальном времени
ЗарезервированоЗарезервировано
14 Мбайт
Встроенная флэш-память
Внешняя флэш-память
Схема распределения памяти NPE устройства ряда Cisco 7200
। Таблица Б.7. Схема распределения памяти N^ycirpotiiCT^/]
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 0000 0000
0x0 07FF FFFF
128 Мбайт
Системное динамическое ОЗУ
0x0 0800 0000
0x0 0FFF FFFF
128 Мбайт
Системное динамическое
ОЗУ (rsvd)
0x0 1000 0000
0x0 13FF FFFF
62 Мбайт
Зарезервировано
0x0 1400 0000
0x0 141F FFFF
2 Мбайт
Регистры GT-64010
0x0 1420 0000
0x0 19FF FFFF
94 Мбайт
Зарезервировано
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 1А00 0000
0x0 1A3F FFFF
4 Мбайт
Внутренняя микросхема
SIMM флэш-памяти
Ввода- вывода
0x0 1А40 0000
0x0 1BFF FFFF
28 Мбайт
Зарезервировано: дополнительный объем флэш-памяти
Ввода- вывода
0x0 КОО 0000
0x0 1DFF FFFF
32 Мбайт
Зарезервировано
0x0 1Е00 0000
0x0 1E1F FFFF
2 Мбайт
Энергонезависимое ОЗУ
Ввода- вывода
0x0 1Е20 0000
0x0 1E7F FFFF
6 Мбайт
Зарезервировано
0x0 1Е80 0000
0x0 1E9F FFFF
2 Мбайт
Регистры ввода-вывода
Ввода- вывода
0x0 1ЕА0 0000
0x0 1EFF FFFF
6 Мбайт
Зарезервировано
0x0 1F00 0000
0x0 1FBF FFFF
12 Мбайт
Зарезервировано
0x0 1FC0 0000
0x0 1FDF FFFF
2 Мбайт
Загрузочное ППЗУ
0x0 IFEO 0000
0x0 3FFF FFFF
х Мбайт
Зарезервировано
0x0 4000 0000
0x0 43FF FFFF
64 Мбайт
Интерфейс от PCI к PCMCIA (верхнее гнездо)
0x0 4400 0000
0x0 47FF FFFF
64 Мбайт
Интерфейс от PCI к PCMCIA (нижнее гнездо)
0x0 4800 0000
0x0 487F FFFF
8 Мбайт
Fast Ethernet — ввод-вы вод с отображением на память
0x0 4880 0000
0x0 48FF FFFF
8 Мбайт
РА1 — в вод-вывод с отображением на память
0x0 4900 0000
0x0 497F FFFF
8 Мбайт
РАЗ — ввод-вывод с отображением на память
0x0 4800 0000
0x0 49FF FFFF
8 Мбайт
РА5 — ввод-вывод с отображением на память
0x0 4А00 0000
0x0 4A7F FFFF
8 Мбайт
РА7 — ввод-вывод с отображением на память
0x0 4А80 0000
0x0 4AFF FFFF
8 Мбайт
РА9 — ввод-вывод с отображением на память
0x0 4В00 0000
0x0 4B0F FFFF
1 Мбайт
PCI РМ, первый 1 Мбайт, без перестановки байтов
0x0 4В10 0000
0x0 4B7F FFFF
7 Мбайт
PCI РМ, больший РМ, без перестановки байтов (rsvd)
0x0 4В80 0000
0x0 4B8F FFFF
1 Мбайт
PCI РМ, первый 1 Мбайт, с перестановкой байтов
0x0 4В90 0000
0x0 4BFF FFFF
7 Мбайт
PCI РМ, больший РМ, с перестановкой байтов (rsvd)
0x0 4С00 0000
0x0 4C0F FFFF
1 Мбайт
Псевдоним PCI, первый 1
Мбайт, без перестановки байтов
0x0 4С10 0000
0x0 4C7F FFFF
7 Мбайт
Псевдоним PCI, больший РМ, без перестановки байтов (rsvd)
0x0 4С80 0000
0x0 4C8F FFFF
1 Мбайт
Псевдоним PCI, первый 1
Мбайт, с перестановкой байтов
0x0 4С90 0000
0x0 4CFF FFFF
7 Мбайт
Псевдоним PCI, больший РМ, с перестановкой байтов (rsvd)
Базовый адрес Конечный адрес Объем УстройствоШина
0x0 4D00
0000
0x0 4D7F
FFFF
8 Мбайт
РА2 — в вод-вы вод с отображением на память
0x0 4D80
0000
0x0 4DFF
FFFF
8 Мбайт
РА4 — ввод-вывод с отображением на память
0x0 4Е00
0000
0x0 4E7F
FFFF
8 Мбайт
РА6 — ввод-вывод с отображением на память
0x0 4Е80
0000
0x0 4EFF
FFFF
8 Мбайт
РА8 — ввод-вывод с отображением на память (rsvd)
0x0 4F00
0000
0x0 4F7F
FFFF
8 Мбайт
РАЮ — ввод-вывод с отображением на память (rsvd)
0x0 4F80
0000
0x0 4FFF
FFFF
8 Мбайт
Микросхема ввода-вывода с отображением на память (rsvd)
0x0 5000
0000
0x0 FFFF
FFFF
х Мбайт
Зарезервировано
0x1 0000
0000
0x0 001F
FFFF
2 Мбайт
Адресное пространство ввода-вывода PCI
0x1 0020
0000
0x1 4B7F
FFFF
Около
1 Гбайт
Зарезервировано
0x1 4В00
0000
0x1 4B0F
FFFF
1 Мбайт
CPU РМ, первый 1 Мбайт, без перестановки байтов
0x1 4В10
0000
0x1 4B7F
FFFF
7 Мбайт
CPU РМ, больший РМ, без перестановки байтов (rsvd)
0x1 4В80
0000
0x1 FFFF
FFFF
Около 0 Гбайт
Зарезервировано
0x2 0000
0000
0x3 FFFF
FFFF
8 Гбайт
Заблокированный кэш L2 (псевдоним) для младших 8 Гбайт
0x4 0000
0000
0x7 FFFF
FFFF
16 Гбайт
Операция Ор 0 дескриптора контроллера кэш-памяти
0x8 0000
0000
OxF FFFF
FFFF
32 Гбайт
Операция Ор 1 дескриптора
контроллера кэш-памяти
Таблица Б.7,а. Схема распределения памяти Cisco 7200 NPE-200 , Базовый адрес Конечный адрес Объем УстройствоШина
0x0 0000 0000
0x0
07FF
FFFF
128 Мбайт
Системное динамическое ОЗУ
0x0 0000 0000
0x0
0FFF
FFFF
128 Мбайт
Системное динамическое ОЗУ (rsvd)
0x0 1000 0000
0x0
13FF
FFFF
62 Мбайт
Зарезервировано
0x0 1400 0000
0x0
141F
FFFF
2 Мбайт
Регистры GT-64010
0x0 1420 0000
0x0
19FF
FFFF
94 Мбайт
Зарезервировано
0x0 1А00 0000
0x0
1A3F
FFFF
4 Мбайт
Внутренняя микросхема SIMM флэш-памяти
0x0 1А40 0000
0x0
1BFF
FFFF
28 Мбайт
Микросхема SIMM флэш-
памяти большего объема
(rsvd)
Базовый адрес
Конечный адрес ОбъемУстройствоШина
0x0 1С00 0000
0x0 1Е00 0000
0x0 1D00 000032 МбайтЗарезервировано
0x0 1E1F FFFF2 МбайтЭнергонезависимое ОЗУ
(TOD)
0x0 1Е20 0000
0x0 1Е80 0000
0x0 1ЕА0 0000
0x0 1F00 0000
0x0 1E7FFFFF6МбайтЗарезервировано
0x0 1E9FFFFF2МбайтРегистры ввода-вывода
0x0 1EFFFFFF6МбайтЗарезервировано
0x0 1FBFFFFF12 МбайтБитоприемник (устройство
null для чтения-записи)
0x0 1FC0 0000
0x0 1FE0 0000 0x0 4000 0000
0x0 1FDFFFFF2МбайтЗагрузочное ППЗУ
0x0 3FFFFFFFхМбайтЗарезервировано
0x0 43FFFFFF64МбайтИнтерфейс от PCI к
PCMCIA (верхнее гнездо)
0x0 4400 0000
0x0 47FF FFFF64 МбайтИнтерфейс от PCI к
PCMCIA (нижнее гнездо)
0x0 4800 0000
0x0 487F FFFF8 МбайтFast Ethernet — ввод-вывод с
отображением на память
0x0 4880 0000
0x0 48FF FFFF8 МбайтРА1 — ввод-вывод с отобра
жением на память
0x0 4900 0000
0x0 497F FFFF8 МбайтРАЗ — ввод-вывод с отобра
жением на память
0x0 4980 0000
0x0 49FF FFFF8 МбайтРА5 — ввод-вывод с отобра
жением на память
0x0 4А00 0000
0x0 4A7F FFFF8 МбайтРА7 — ввод-вывод с отобра
жением на память (rsvd)
0x0 4А80 0000
0x0 4AFF FFFF8 МбайтРА9 — ввод-вывод с отобра
жением на память (rsvd)
0x0 4В00 0000
0x0 4B3F FFFF4 МбайтPCI РМ, первые 4 Мбайт,
без перестановки байтов
0x0 4В40 0000
0x0 4B7F FFFF4 МбайтPCI РМ, больший РМ, без
перестановки байтов (rsvd)
0x0 4В80 0000
0x0 4BBF FFFF4 МбайтPCI РМ, первые 4 Мбайт, с
перестановкой байтов
0x0 4ВС0 0000
0x0 4BFF FFFF4 МбайтPCI РМ, больший РМ, с пе
рестановкой байтов (rsvd)
0x0 4С00 0000
0x0 4C3F FFFF4 МбайтПсевдоним PCI РМ, первые
4 Мбайт, без перестановки байтов
0x0 4С40 0000
0x0 4C7F FFFF4 МбайтПсевдоним PCI РМ, боль
ший РМ, без перестановки байтов (rsvd)
0x0 4С80 0000
0x0 4CBF FFFF4 МбайтПсевдоним PCI РМ, первые
4 Мбайт, с перестановкой байтов
0x0 4СС0 0000
0x0 4CFF FFFF4 МбайтПсевдоним PCI РМ, боль
ший РМ, с перестановкой байтов (rsvd)
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 4D00 0000
0x0 4D7F FFFF
8 Мбайт
РА2 — ввод-вывод с отображением на память
0x0 4D80 0000
0x0 4DFF FFFF
8 Мбайт
РА4 — ввод-вывод с отображением на память
0x0 4Е00 0000
0x0 4E7F FFFF
8 Мбайт
РА6 — ввод-вывод с отображением на память
0x0 4Е80 0000
0x0 4EFF FFFF
8 Мбайт
РА8 — ввод-вывод с отображением на память (rsvd)
0x0 4F00 0000
0x0 4F7F FFFF
8 Мбайт
РАЮ — ввод-вывод с отображением на память (rsvd)
0x0 4F80 0000
0x0 4FFF FFFF
8 Мбайт
Микросхема ввода-вывода с отображением на память (rsvd)
0x0 5000 0000
0x0 FFFF FFFF
х Мбайт
Зарезервировано
0x1 0000 0000
0x0 001F FFFF
2 Мбайт
Адресное пространство ввода-вывода PCI
0x1 0020 0000
0x1 4B7F FFFF
Около
1 Гбайт
Зарезервировано
0x1 4В00 0000
0x1 4B3F FFFF
4 Мбайт
CPU РМ, первые 4 Мбайт, без перестановки байтов
0x1 4В40 0000
0x1 4B7F FFFF
4 Мбайт
CPU РМ, больший РМ, без перестановки байтов (rsvd)
0x1 4В80 0000
0x1 FFFF FFFF
Около О Гбайт
Зарезервировано
0x2 0000 0000
0x3 FFFF FFFF
8 Гбайт
Заблокированный кэш L2 (псевдоним) для младших 8 Гбайт
0x4 0000 0000
0x7 FFFF FFFF
16 Гбайт
Операция Ор 0 дескриптора контроллера кэш-памяти
0x8 0000 0000
OxF FFFF FFFF
32 Гбайт
Операция Ор 1 дескриптора контроллера кэш-памяти
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 0000 0000
0x0 0FFF FFFF
256 Мбайт
Системное синхронное динамическое ОЗУ; с перестраиваемой конфигурацией
0x0 1000 0000
0x0 13FF FFFF
64 Мбайт
Зарезервировано
0x0 1400 0000
0x0 141F FFFF
2 Мбайт
Регистры GT-64120
0x0 1420 0000
0x0 14FF FFFF
14 Мбайт
Зарезервировано
0x0 1500 0000
0x0 151F FFFF
2 Мбайт
Регистры GT-64120
0x0 1520 0000
0x0 19FF FFFF
78 Мбайт
Зарезервировано
0x0 1А00 0000
0x0 1A3F FFFF
4 Мбайт
Внутренняя микросхема
SIMM флэш-памяти
0x0 1А40 0000
0x0 1BFF FFFF
28 Мбайт
Микросхема SIMM флэш- памяти большего объема (rsvd)
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 1С00 0000
0x0 1D00 0000
32 Мбайт
Зарезервировано
0x0 1Е00 0000
0x0 1E1F FFFF
2 Мбайт
Энергонезависимое ОЗУ (TOD)
0x0 1Е20 0000
0x0 1E7F FFFF
6 Мбайт
Зарезервировано
0x0 1Е80 0000
0x0 1E9F FFFF
2 Мбайт
Регистры ввода-вывода
0x0 1ЕА0 0000
0x0 1EFF FFFF
6 Мбайт
Зарезервировано
0x0 1F00 0000
0x0 1FBF FFFF
12 Мбайт
Битоприемник (устройство null для чтения-записи)
0x0 1FC0 0000
0x0 1FDF FFFF
2 Мбайт
Загрузочное ППЗУ
0x0 1FE0 0000
0x0 1FFF FFFF
2 Мбайт
Зарезервировано
0x0 2000 0000
0x0 2 IFF FFFF
32 Мбайт
Системное синхронное динамическое ОЗУ (память ввода-вывода); постоянное
0x0 2200 0000
0x0 2FFF FFFF
224 Мбайт
Системное синхронное динамическое ОЗУ (rsvd)
0x0 3000 0000
0x0 3FFF FFFF
256 Мбайт
Зарезервировано
0x0 4000 0000
0x0 43FF FFFF
64 Мбайт
Интерфейс от PCI к
PCMCIA (верхнее гнездо)
0x0 4400 0000
0x0 47FF FFFF
64 Мбайт
Интерфейс от PCI к PCMCIA (нижнее гнездо)
0x0 4800 0000
0x0 487F FFFF
8 Мбайт
Плата ввода-вывода Fast Ethernet — ввод-вывод с отображением на память
0x0 4880 0000
0x0 48FF FFFF
8 Мбайт
РА1 — ввод-вывод с отображением на память
0x0 4900 0000
0x0 497F FFFF
8 Мбайт
РАЗ — ввод-вывод с отображением на память
0x0 4980 0000
0x0 49FF FFFF
8 Мбайт
РА5 — ввод-вывод с отображением на память
0x0 4А00 0000
0x0 4A7F FFFF
8 Мбайт
РА7 — ввод-вывод с отображением на память (rsvd)
0x0 4А80 0000
0x0 4AFF FFFF
8 Мбайт
РА9 — ввод-вывод с отображением на память (rsvd)
0x0 4В00 0000
0x0 4CFF FFFF
32 Мбайт
Зарезервировано
0x0 4D00 0000
0x0 4D7F FFFF
8 Мбайт
РА2 — ввод-вывод с отображением на память
0x0 4D80 0000
0x0 4DFF FFFF
8 Мбайт
РА4 — ввод-вывод с отображением на память
0x0 4Е00 0000
0x0 4E7F FFFF
8 Мбайт
РАб — ввод-вывод с отображением на память
0x0 4Е80 0000
0x0 4EFF FFFF
8 Мбайт
РА8 — ввод-вывод с отображением на память (rsvd)
0x0 4F00 0000
0x0 4F7F FFFF
8 Мбайт
РАЮ — ввод-вывод с отображением на память (rsvd)
0x0 4F80 0000
0x0 4FFF FFFF
8 Мбайт
Микросхема ввода-вывода с отображением на память (rsvd)
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0
5000
0000
0x0
BFFF
FFFF
1792 Мбайт
Зарезервировано
0x0
сооо
0000
0x0
CFFF
FFFF
256 Мбайт
Младшие адреса системного синхронного динамического ОЗУ, PCI с перестановкой байтов
0x0
D000
0000
0x0
DFFF
FFFF
256 Мбайт
Зарезервировано
0x0
Е000
0000
0x0
EFFF
FFFF
256 Мбайт
Старшие адреса системного синхронного динамического ОЗУ, PCI с перестановкой байтов
0x0
F000
0000
0x0
FFFF
FFFF
256 Мбайт
Зарезервировано
0x1
0000
0000
0x1
001F
FFFF
2 Мбайт
Адресное пространство ввода-вывода PCI
0x1
0020
0000
OxF
FFFF
FFFF
Зарезервировано
|Таблица. Б.7,в. Схема распределения памяти Cisco 7200 NPE-175
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0
0000
0000
0x0
0FFF
FFFF
256 Мбайт
Системное синхронное динамическое ОЗУ и память
для хранения пакетов
0x0
1000
0000
0x0
13FF
FFFF
64 Мбайт
Зарезервировано
0x0
1400
0000
0x0
141F
FFFF
2 Мбайт
Регистры GT-64120
0x0
1420
0000
0x0
14FF
FFFF
14 Мбайт
Зарезервировано
0x0
1А00
0000
0x0
1A3F
FFFF
4 Мбайт
Внутренняя микросхема SIMM флэш-памяти
0x0
1А40
0000
0x0
1BFF
FFFF
28 Мбайт
Микросхема SIMM флэш- памяти большего объема (rsvd)
0x0
1С00
0000
0x0
1DFF
FFFF
32 Мбайт
Зарезервировано
0x0
1Е00
0000
0x0
1E1F
FFFF
2 Мбайт
Энергонезависимое ОЗУ (TOD)
0x0
1Е20
0000
0x0
1E7F
FFFF
6 Мбайт
Зарезервировано
0x0
1Е80
0000
0x0
1E9F
FFFF
2 Мбайт
Регистры ввода-вывода
0x0
1ЕА0
0000
0x0
1EFF
FFFF
6 Мбайт
Зарезервировано
0x0
1F00
0000
0x0
1FBF
FFFF
12 Мбайт
Битоприемник (устройство null для чтения-записи)
0x0
1FC0
0000
0x0
1FDF
FFFF
2 Мбайт
Загрузочное ППЗУ
0x0
1FE0
0000
0x0
1FFF
FFFF
2 Мбайт
Зарезервировано
0x0
2000
0000
0x0
2FFF
FFFF
256 Мбайт
Зарезервировано
0x0
3000
0000
0x0
3FFF
FFFF
256 Мбайт
Зарезервировано
0x0
4000
0000
0x0
43FF
FFFF
64 Мбайт
Интерфейс от PCI к PCMCIA (верхнее гнездо)
0x0
4400
0000
0x0
47FF
FFFF
64 Мбайт
Интерфейс от PCI к
PCMCIA (нижнее гнездо)
0x0
4800
0000
0x0
487F
FFFF
8 Мбайт
Fast Ethernet — ввод-вывод с отображением на память
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 4880 0000
0x0 48FF FFFF
8 Мбайт
РА1 — ввод-вывод с отобра-
жением на память
0x0 4900 0000
0x0 497F FFFF
8 Мбайт
РАЗ — ввод-вывод с отобра-
жением на память
0x0 4980 0000
0x0 49FF FFFF
8 Мбайт
РА5 — ввод-вывод с отобра-
жением на память
0x0 4А00 0000
0x0 4A7F FFFF
8 Мбайт
РА7 — ввод-вывод с отобра-
жением на память (rsvd)
0x0 4А80 0000
0x0 4AFF FFFF
8 Мбайт
РА9 — ввод-вывод с отобра-
жением на память (rsvd)
0x0 4В00 0000
0x0 4CFF FFFF
32 Мбайт
Зарезервировано
0x0 4D00 0000
0x0 4D7F FFFF
8 Мбайт
РА2 — ввод-вывод с отобра-
жением на память
0x0 4D80 0000
0x0 4DFF FFFF
8 Мбайт
РА4 — ввод-вывод с отобра-
жением на память
0x0 4Е00 0000
0x0 4E7F FFFF
8 Мбайт
РАб — ввод-вывод с отобра-
жением на память
0x0 4Е80 0000
0x0 4EFF FFFF
8 Мбайт
РА8 — ввод-вывод с отобра-
жением на память (rsvd)
0x0 4F00 0000
0x0 4F7F FFFF
8 Мбайт
РАЮ — ввод-вывод с ото-
бражением на память (rsvd)
0x0 4F80 0000
0x0 4FFF FFFF
8 Мбайт
Микросхема ввода-вывода с
отображением на память
(rsvd)
0x0 5000 0000
0x0 7FFF FFFF
768 Мбайт
Зарезервировано
0x0 8000 0000
0x0 8FFF FFFF
256 Мбайт
Системное синхронное ди-
намическое ОЗУ, PCI с пе-
рестановкой байтов
0x0 9000 0000
0x0 9FFF FFFF
256 Мбайт
Зарезервировано
0x0 А000 0000
0x0 AFFF FFFF
256 Мбайт
Зарезервировано
0x0 В000 0000
0x0 FFFF FFFF
1280 Мбайт
Зарезервировано
0x1 0000 0000
0x1 001F FFFF
2 Мбайт
Адресное пространство вво-
да-вывода PCI
0x1 0020 0000
0x1 FFFF FFFF
2 Мбайт
Зарезервировано
кТаблицаБ.7,г.Схемараспределения памяти Cisco 7200 NPE-225 . ,
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 0000 0000
0x0 OFFF FFFF
256 Мбайт
Системное синхронное ди-
намическое ОЗУ и память
для хранения пакетов
0x0 1000 0000
0x0 13FF FFFF
64 Мбайт
Зарезервировано
0x0 1400 0000
0X0 14IF FFFF
2 Мбайт
Регистры GT-64120
0x0 1420 0000
0x0 19FF FFFF
14 Мбайт
Зарезервировано
0x0 1A00 0000
0x0 1A3F FFFF
4 Мбайт
Внутренняя микросхема
SIMM флэш-памяти
Базовый адрес
Конечный адрес ОбъемУстройствоШина
0x0 1А40 0000
0x0 1BFF FFFF28 МбайтМикросхема SIMM флэш-
памяти большего объема (rsvd)
0x0 КОО 0000
0x0 1D00 000032 МбайтЗарезервировано
0x0 lEOO 0000
0x0 1E1F FFFF2 МбайтЭнергонезависимое ОЗУ
(TOD)
0x0 1Е20 0000
0x0 1Е80 0000
0x0 1ЕА0 0000
0x0 1F00 0000
0x0 1E7FFFFF6МбайтЗарезервировано
0x0 1E9FFFFF2МбайтРегистры ввода-вывода
0x0 1EFFFFFF6МбайтЗарезервировано
0x0 1FBFFFFF12 МбайтБитоприемник (устройство
null для чтения-записи)
0x0 1FC0 0000
0x0 IFEO 0000
0x0 2000 0000
0x0 3000 0000
0x0 4000 0000
0x0 1FDFFFFF2 МбайтЗагрузочное ППЗУ
0x0 1FFFFFFF2 МбайтЗарезервировано
0x0 2FFFFFFF256 МбайтЗарезервировано
0x0 3FFFFFFF256 МбайтЗарезервировано
0x0 43FF FFFF64 МбайтИнтерфейс от PCI к
PCMCIA (верхнее гнездо)
0x0 4400 0000
0x0 47FF FFFF64 МбайтИнтерфейс от PCI к
PCMCIA (нижнее гнездо)
0x0 4800 0000
0x0 487F FFFF8 МбайтFast Ethernet — ввод-вывод с
отображением на память
0x0 4880 0000
0x0 48FF FFFF8 МбайтРА1 — ввод-вывод с отобра
жением на память
0x0 4900 0000
0x0 497F FFFF8 МбайтРАЗ — ввод-вывод с отобра
жением на память
0x0 4980 0000
0x0 49FF FFFF8 МбайтРА5 — ввод-вывод с отобра
жением на память
0x0 4А00 0000
0x0 4A7F FFFF8 МбайтРА7 — ввод-вывод с отобра
жением на память (rsvd)
0x0 4А80 0000
0x0 4AFF FFFF8 МбайтРА9 — ввод-вывод с отобра
жением на память (rsvd)
0x0 4В00 0000
0x0 4D00 0000
0x0 4CFF FFFF32 МбайтЗарезервировано
0x0 4D7F FFFF8 МбайтРА2 — ввод-вывод с отобра
жением на память
0x0 4D80 0000
0x0 4DFF FFFF8 МбайтРА4 — ввод-вывод с отобра
жением на память
0x0 4Е00 0000
0x0 4E7F FFFF8 МбайтРА6 — ввод-вывод с отобра
жением на память
0x0 4Е80 0000
0x0 4EFF FFFF8 МбайтРА8 — ввод-вывод с отобра
жением на память (rsvd)
0x0 4F00 0000
0x0 4F7F FFFF8 МбайтРАЮ — ввод-вывод с ото
бражением на память (rsvd)
0x0 4F80 0000
0x0 4FFF FFFF8 МбайтМикросхема ввода-вывода с
отображением на память (rsvd)
0x0 5000 0000
0x0 7FFF FFFF768 Мбайт Зарезервировано
Базовый адрес
Конечный адрес ОбъемУстройствоШина
0x0 8000 0000
0x0 8FFF FFFF256 Мбайт Системное синхронное ди
намическое ОЗУ, PCI с перестановкой байтов
0x0 9000 0000
0x0 А000 0000
0x0 В000 0000
0x1 0000 0000
0x0 9FFFFFFF256МбайтЗарезервировано
0x0 AFFFFFFF256МбайтЗарезервировано
0x0 FFFFFFFF256МбайтЗарезервировано
0x1 001FFFFF2 МбайтАдресное пространство вво
да-вывода PCI
0x1 0020 0000
OxF FFFF FFFFЗарезервировано
Схема распределения памяти Cisco 7100
^Таблица Б.8. С
Базовый адрес памяти
?хема распределения памяти Cisco 7100' г
Максимальный адрес памяти
Объем
Устройство
0x0 0000 0000
0x0 0FFF FFFF
256 Мбайт
Зарезервировано
0x0 1000 0000
0x0 13FF FFFF
62 Мбайт
Зарезервировано
0x0 1400 0000
>0x0 141F FFFF
2 Мбайт
Регистры GT-64120
0x0 1420 0000
0x0 19FF FFFF
94 Мбайт
Зарезервировано
0x0 1А00 0000
0x0 1A3F FFFF
4 Мбайт
Внутренняя микросхема SIMM флэш-
памяти
0x0 1А40 0000
0x0 1BFF FFFF
28 Мбайт
Микросхема SIMM флэш-памяти
большего объема (rsvd)
0x0 ICOO 0000
0x0 1DFF FFFF
32 Мбайт
Зарезервировано
0x0 1Е00 0000
0x0 1E3F FFFF
4 Мбайт
Энергонезависимое ОЗУ (первый со-
кет)
0x0 1Е40 0000
0x0 1E47 FFFF
512 Кбайт
Энергонезависимое ОЗУ/TOD (второй
сокет)
0x0 1Е48 0000
0x0 1E7F FFFF
Зарезервировано
0x0 1Е80 0000
0x0 1E9F FFFF
2 Мбайт
Регистры ввода-вывода
0x0 1ЕА0 0000
0x0 1EFF FFFF
6 Мбайт
Зарезервировано
0x0 1F00 0000
0x0 1FBF FFFF
12 Мбайт
Битоприемник (устройство null для
чтения-записи)
0x0 1FC0 0000
0x0 1FDF FFFF
2 Мбайт
Загрузочное ППЗУ
0x0 1FE0 0000
0x0 1FFF FFFF
х Мбайт
Зарезервировано
0x0 4D00 0000
0x0 4E7F FFFF
24М
L0 локальная шина PCI
0x0 4D00 0000
0x0 4D7F FFFF
8 Мбайт
Гнездо 1, адаптер распределенной сети
1
0x0 4D80 0000
0x0 4DFF FFFF
8 Мбайт
Гнездо 3, адаптер порта 1
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x0 4Е00 0000
0x0 4E7F FFFF
8 Мбайт
Гнездо 5, сервисный адаптер
0x0 4000 0000
0x0 497F FFFF
24M
L1 локальная шина PCI
0x0 4000 0000
0x0 47FF FFFF
128 Мбайт
Гнездо 0, PCMCIA
0x0 4800 0000
0x0 487F FFFF
8 Мбайт
Гнездо 0, FEO, FE1
0x0 4880 0000
0x0 48FF FFFF
8 Мбайт
Гнездо 2, адаптер распределенной сети 2
0x0 4900 0000
0x0 497F FFFF
8 Мбайт
Гнездо 4, адаптер порта 2
0x0 5000 0000
0x0 5FFF FFFF
512 Мбайт
Зарезервировано
Синхронное динамическое ОЗУ для хранения пакетов
0x0 6000 0000
0x067FF FFFF
128 Мбайт
Синхронное динамическое ОЗУ для хранения пакетов
0x0 6800 0000
0x0 7FFF FFFF
384 Мбайт
Синхронное динамическое ОЗУ для хранения пакетов, зарезервированная область Синхронное динамическое ОЗУ для хранения программ и данных Синхронное динамическое ОЗУ для хранения программ и данных Синхронное динамическое ОЗУ для хранения программ и данных, зарезервированная область
0x0 5000 0000
OxOFFFF FFFF
2816 Мбайт
Зарезервировано
0x1 0000 0000
0x0 001F FFFF
2 Мбайт
Адресное пространство ввода-вывода PCI
Схема распределения памяти Cisco 6400-NRP
Существуют четыре категории недопустимых операций доступа: к зарезервированному устройству, зарезервированной памяти, неопределенной области памяти и зарезервированной области ввода-вывода. При обращении процессора к зарезервированному адресу генерируется либо ошибка шины (при чтении), либо прерывание системного контроллера (при записи). Для активизации ошибок обоих типов применяется системный контроллер. При обращении процессора к неопределенному адресу ошибки не активизируются и происходит возврат неопределенных данных при чтении или прием любых данных при записи. Поэтому запись по неопределенному адресу может вызвать нежелательный побочный эффект. Доступ к зарезервированной области ввода-вывода приводит к тому, что генерируется прерывание из-за ошибки в адресе ввода-вывода либо при чтении, либо при записи. Следует отметить, что ниже приведены только схемы распределения памяти плат версии 1, поскольку платы версии 2 еще не введены повсеместно в действие и не заменили платы версии 1. Все регистры имеют обратный порядок следования байтов.
Таблица Б.9. Схема распределения памяти Cisco 6400-NRP \„,|
Базовый адрес Максимальный ' Объем Устройство памятиадрес памяти
0x0
0000
0000
0x0
07FF
FFFF
128 Мбайт
Системное динамическое ОЗУ
0x0
0800
0000
0x0
13FF
FFFF
128 Мбайт
Зарезервировано
0x0
1400
0000
0x0
141F
FFFF
2 Мбайт
Регистры Galileo GT-64010A
0x0
1420
0000
0x0
19FF
FFFF
94 Мбайт
Зарезервировано
0x0
1А00
0000
0x0
1AFF
FFFF
16 Мбайт
Флэш-память на микросхеме SIMM
0x0
1В00
0000
0x0
1BFF
FFFF
16 Мбайт
Не определено (адреса декодируются в адреса сокета микросхемы флэш- памяти SIMM)
0x0
1С00
0000
0x0
1C1F
FFFF
2 Мбайт
Пространство ввода-вывода
0x0
1С20
0000
0x0
1DFF
FFFF
30 Мбайт
Не определено
0x0
1Е00
0000
0x0
1E1F
FFFF
2 Мбайт
Энергонезависимое ОЗУ (TOD)
0x0
1Е20
0000
0x0
1E7F
FFFF
6 Мбайт
Зарезервировано
0x0
1Е80
0000
0x0
1EBF
FFFF
4 Мбайт
Загрузочная флэш-память
0x0
1ЕА0
0000
0x0
1FBF
FFFF
18 Мбайт
Зарезервировано
0x0
1FC0
0000
0x0
1FDF
FFFF
2 Мбайт
Пространство загрузочного ППЗУ
0x0
1FE0
0000
0x0
47FF
FFFF
642 Мбайт
Зарезервировано
0x0
4800
0000
0x0
487F
FFFF
8 Мбайт
Контроллер Ethernet ВРЕ
0x0
4880
0000
0x0
48FF
FFFF
8 Мбайт
Контроллер Ethernet NME
0x0
4900
0000
0x0
497F
FFFF
8 Мбайт
Контроллер Ethernet CSE
0x0
4980
0000
0x0
49FF
FFFF
8 Мбайт
Не определено (тайм-аут шины PCI)
0x0
4А00
0000
0x0
4A7F
FFFF
8 Мбайт
SAR
0x0
4А80
0000
0x0
4AFF
FFFF
8 Мбайт
Не определено (тайм-аут шины PCI)
0x0
4В00
0000
0x0
4B3F
FFFF
4 Мбайт
Память для хранения пакетов PCI, без перестановки байтов
0x0
4В40
0000
0x0
4B7F
FFFF
4 Мбайт
Не определено (тайм-аут шины PCI)
0x0
4В80
0000
0x0
4BBF
FFFF
4 Мбайт
Память для хранения пакетов PCI, с перестановкой байтов
0x0
4ВС0
0000
0x0
4BFF
FFFF
4 Мбайт
Не определено (тайм-аут шины PCI)
0x0
4С00
0000
0x0
5FFF
FFFF
320 Мбайт
Зарезервировано
0x0
6000
0000
0x0
601F
FFFF
2 Мбайт
Адресное пространство ввода-вывода PCI
0x0
6020
0000
0x0
BFFF
FFFF
Около
1,5 Гбайт
Зарезервировано
0x0
сооо
0000
0x0
C7FF
FFFF
128 Мбайт
Доступ шины PCI к динамическому ОЗУ с перестановкой байтов
0x0
С800
0000
0x1
4AFF
FFFF
Около
2 Гбайт
Зарезервировано
0x1
4В00
0000
0x1
4B3F
FFFF
4 Мбайт
Память процессора для хранения пакетов, без перестановки байтов
0x1
4В40
0000
0x1
8AFF
FFFF
Около
1 Гбайт
Зарезервировано
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x1
8В00
0000
0x1
8C3F
FFFF
4 Мбайт
Диапазон проверки дескриптора кэша L2. (Действителен, только если установлен бит проверки дескриптора кэша L2. В ином случае это пространство зарезервировано.)
0x1
8С40
0000
0x1
FFFF
FFFF
Около 2 Гбайт
Зарезервировано
0x2
0000
0000
0x3
FFFF
FFFF
8 Гбайт
Заблокированный псевдоним кэша L2 для пространства памяти
0x4
0000
0000
0x7
FFFF
FFFF
16 Гбайт
Операция Ор 0 с дескриптором контроллера кэш-памяти L2 (объявление недействительными элементов кэша, отмена обратной записи) TagOp[0]:l, TagOp[l]: 0
0x8
0000
0000
OxF
FFFF
FFFF
32 Гбайт
Операция Ор 1 с дескриптором кон- троллера кэш-памяти L2 (вывод всех элементов кэша, отмена обратной записи) TagOp[0]:0, TagOp[lj: 1
i Таблица Б.9,а. Подробная схема распределения системной памяти >
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x0 0000 0000
0x0 07FF FFFF
128 Мбайт
Системное динамическое ОЗУ
0x0 0800 0000
0x0 13FF FFFF
128 Мбайт
Зарезервировано
0x0 1400 0000
0x0 141F FFFF
2 Мбайт
Регистры Galileo GT-64010A
0x0 1400 0000
0x0 1400 0007
8 байт
Конфигурация интерфейса процессора
0x0 1400 0008
0x0 1400 000F
8 байт
Младший адрес декодирования RAS[1:O]
0x0 1400 0010
0x0 1400 0017
8 байт
Старший адрес декодирования RAS[ 1:0]
0x0 1400 0018
0x0 1400 001F
8 байт
Младший адрес декодирования RAS[3:2]
0x0 1400 0020
0x0 1400 0027
8 байт
Старший адрес декодирования RAS[3:2]
0x0 1400 0028
0x0 1400 002F
8 байт
Младший адрес декодирования CS[2:0]
0x0 1400 0030
0x0 1400 0037
8 байт
Старший адрес декодирования CS[2:0]
0x0 1400 0038
0x0 1400 003F
8 байт
Младший адрес декодирования CS[3] и BootCS
0x0 1400 0040
0x0 1400 0047
8 байт
Старший адрес декодирования CS[3] и BootCS
0x0 1400 0048
0x0 1400 004F
8 байт
Младший адрес декодирования адресов ввода-вывода PCI
0x0 1400 0050
0x0 1400 0057
8 байт
Старший адрес декодирования адресов ввода-вывода РС1
0x0 1400 0058
0x0 1400 005F
8 байт
Младший адрес декодирования адресов памяти PCI
0x0 1400 0060
0x0 1400 0067
8 байт
Старший адрес декодирования адресов памяти PCI
Базовый адрес памяти
Максимальный ОбъемУстройство
адрес памяти
0x0 1400 0068
0x0 1400 006F8 байтАдрес декодирования адресов внутрен
него пространства памяти
0x0 1400 0070 0x0 1400 0078 0x0 1400 0080 0x0 1400 0400- 0x0 1400 0404 0x0 1400 0408 0x0 1400 040С 0x0 1400 0410 0x0 1400 0414 0x0 1400 0418 0x0 1400 041С 0x0 1400 0420 0x0 1400 0424 0x0 1400 0428 0x0 1400 042С 0x0 1400 0430 0x0 1400 0434 0x0 1400 0438 0x0 1400 043С 0x0 1400 0440 0x0 1400 0444 0x0 1400 0448 0x0 1400 044С 0x0 1400 0450 0x0 1400 0454 0x0 1400 0458 0x0 1400 045С 0x0 1400 0460 0x0 1400 0464 0x0 1400 0468 0x0 1400 046С
0x0 140000778 байтМладший байт адреса ошибки BUS
0x0 1400007F8 байтСтарший байт адреса ошибки BUS
0x0 140003FF896 байтНе определено
0x0 140004034байтМладший адрес декодирования RAS[0]
0x0 140004074байтСтарший адрес декодирования RAS[0]
0x0 1400040В4байтМладший адрес декодирования RAS[1]
0x0 1400040F4байтСтарший адрес декодирования RAS[1]
0x0 140004134байтМладший адрес декодирования RAS[2]
0x0 140004174байтСтарший адрес декодирования RAS[2]
0x0 1400041В4байтМладший адрес декодирования RAS[3]
0x0 1400041F4байтСтарший адрес декодирования RAS[3]
0x0 140004234байтМладший адрес декодирования CS[0]
0x0 140004274байтСтарший адрес декодирования CS[0]
0x0 1400042В4байтМладший адрес декодирования CS[1]
0x0 1400042F4байтСтарший адрес декодирования CS[1]
0x0 140004334байтМладший адрес декодирования CS[2]
0x0 140004374байтСтарший адрес декодирования CS[2]
0x0 1400043В4байтМладший адрес декодирования CS[3]
0x0 1400043F4байтСтарший адрес декодирования CS[3]
0x0 140004434байтМладший адрес декодирования BootCS
0x0 140004474байтСтарший адрес декодирования BootCS
0x0 1400044В4байтКонфигурация динамического ОЗУ
0x0 1400044F4байтПараметры динамического ОЗУBankO
0x0 140004534байтПараметры динамического ОЗУBankl
0x0 140004574байтПараметры динамического ОЗУBank2
0x0 1400045В4байтПараметры динамического ОЗУВапкЗ
0x0 1400045F4 байтПараметры ВапкОустройства
0x0 140004634 байтПараметры Banklустройства
0x0 140004674 байтПараметры Вапк2устройства
0x0 1400046В4 байтПараметры ВапкЗустройства
0x0 1400046F4 байтПараметры блоканачальной загрузки
устройства
0x0 1400 0470 0x0 1400 0474 0x0 1400 0800 0x0 1400 0804 0x0 1400 0808 0x0 1400 080С
0x0 1400 0810 0x0 1400 0814
0x0 1400 04734 байтОшибка декодирования адреса
0x0 1400 07FF908 байтНе определено
0x0 140008034 байтКоличество байтов DMA канала 0
0x0 140008074 байтКоличество байтов DMA канала 1
0x0 1400080В4 байтКоличество байтов DMA канала 2
0x0 1400080F4 байтКоличество байтов DMA канала 3
0x0 140008134 байтАдрес отправителя DMA канала 0
0x0 140008174 байтАдрес отправителя DMA канала 1
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x0 1400 0818
0x0 1400 081В
4 байт
Адрес отправителя DMA канала 2
0x0 1400 081С
0x0 1400 081F
4 байт
Адрес отправителя DMA канала 3
0x0 1400 0820
0x0 1400 0823
4 байт
Адрес получателя DMA канала 0
0x0 1400 0824
0x0 1400 0827
4 байт
Адрес получателя DMA канала 1
0x0 1400 0828
0x0 1400 082В
4 байт
Адрес получателя DMA канала 2
0x0 1400 082С
0x0 1400 082F
4 байт
Адрес получателя DMA канала 3
0x0 1400 0830
0x0 1400 0833
4 байт
Указатель на следующую запись DMA канала 0
0x0 1400 0834
0x0 1400 0837
4 байт
Указатель на следующую запись DMA канала 1
0x0 1400 0838
0x0 1400 083В
4 байт
Указатель на следующую запись DMA канала 2
0x0 1400 083С
0x0 1400 083F
4 байт
Указатель на следующую запись DMA канала 3
0x0 1400 0840
0x0 1400 0843
4 байт
Область управления DMA канала 0
0x0 1400 0844
0x0 1400 0847
4 байт
Область управления DMA канала 1
0x0 1400 0848
0x0 1400 084В
4 байт
Область управления DMA канала 2
0x0 1400 084С
0x0 1400 084F
4 байт
Область управления DMA канала 3
0x0 1400 0850
0x0 1400 0853
4 байт
Таймер/счетчик 0
0x0 1400 0854
0x0 1400 0857
4 байт
Таймер/счетчик 1
0x0 1400 0858
0x0 1400 085В
4 байт
Таймер/счетчик 2
0x0 1400 085С
0x0 1400 085F
4 байт
Таймер/счетчик 3
0x0 1400 0860
0x0 1400 0863
4 байт
Область управления схемой разрешения конфликтов DMA
0x0 1400 0864
0x0 1400 0867
4 байт
Область управления тайме- ром/счетчиком
0x0 1400 0868
0x0 1400 0BFF
920 байт
Не определено
0x0 1400 0С00
0x0 1400 0С03
4 байт
Команда PCI
0x0 1400 0С04
0x0 1400 0С07
4 байт
Область управления завершением по тайм-ауту и повторением операций PCI
0x0 1400 0С08
0x0 1400 ОСОБ
4 байт
Объем блока PCI RAS[1:O]
0x0 1400 0C0C
0x0 1400 0C0F
4 байт
Объем блока PCI RAS[3:2]
0x0 1400 ОСЮ
0x0 1400 0С13
4 байт
Объем блока PCI CS[2:0]
0x0 1400 0С14
0x0 1400 0С17
4 байт
Объем блока PCI CS[3] и CS начальной загрузки
0x0 1400 ОСЮ
0x0 1400 OCIB
4 байт
Причина прерывания
0x0 1400 ОСЮ
0x0 1400 OCIF
4 байт
Маска процессора
0x0 1400 0С20
0x0 1400 0С23
4 байт
Не определено
0x0 1400 0С24
0x0 1400 0С27
4 байт
Маска PCI
0x0 1400 0С28
0x0 1400 0С2В
4 байт
Маска PCI SErr
0x0 1400 0С2С
0x0 1400 ОСЗЗ
8 байт
Не определено
0x0 1400 0С34
0x0 1400 0С37
4 байт
Подтверждение прерывания PCI
0x0 1400 0С38
0x0 1400 0CF7
192 байт
Не определено
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x0 1400 0CF8
0x0 1400 0CFB
4 байт
Адрес конфигурации PCI
0x0 1400 0CFC
0x0 1400 0CFF
4 байт
Данные конфигурации PCI
0x0 1400 0D00
0x0 141F FFFF
Около 2044 Кбайт
Не определено
0x0 1420 0000
0x0 19FF FFFF
94 Мбайт
Зарезервировано
0x0 1А00 0000
0x0 1BFF FFFF
32 Мбайт
Флэш-память на микросхеме SIMM
0x0 1С00 0000
0x0 1C1F FFFF
2 Мбайт
Пространство ввода-вывода
0x0 1С00 0000
0x0 1С00 0003
4 байт
Регистр конфигурации NRP-1
0x0 1С00 0004
0x0 1С00 0007
4 байт
Регистр управления NRP-1
0x0 1С00 0008
0x0 1C00 000B
4 байт
Регистр причины сброса
0x0 1С00 ооос
0x0 1C00 000F
4 байт
Регистр состояния прерывания
0x0 1С00 0010
0x0 1C00 0013
4 байт
Регистр маски прерывания
0x0 1С00 0014
0x0 1C00 0017
4 байт
Регистр EHSA
0x0 1С00 0018
0x0 1C00 001B
4 байт
Контрольный регистр
0x0 1С00 001С
0x0 1C00 001F
4 байт
Регистр управления светодиодом
0x0 1С00 0020
0x0 1C00 0023
4 байт
Регистр MICE
0x0 1С00 0024
0x0 1C00 0027
4 байт
Программный регистр PMPCI FPGA
0x0 1С00 0028
0x0 1C00 002F
4 байт
Регистр управления сетевым интерфейсом
0x0 1С00 0030
0x0 1C00 FFFF
64 Кбайт
Зарезервированная область ввода- вывода
0x0 1С01 0000
0x0 1C01 1FFF
8 Кбайт
IDPROM (объемом 2 Кбайт, доступ к байту на границе слова)
0x0 1С01 2000
0x0 1C02 FFFF
119 Кбайт
Зарезервированная область ввода- вывода
0x0 1С03 0000
0x0 1C03 1FFF
8 Кбайт
Память почтового яшика шины РАМ (объем 2 Кбайт, доступ к байту на границе слова)
Диапазон адресов, доступный только с процессора NRP-1, а не NSP
0x0 1С03 2000
>0x0 1C03 FFFF
55 Кбайт
Зарезервированная область ввода- вывода
0x0 1С04 0000
0x0 1C04 0003
4 байт
Не определено
0x0 1С04 0000
0x0 1C04 003F
64 байт
Микросхема UART консоли (8-битовое устройство на 64-битовой границе)
0x0 1С04 0004
0x0 1C04 0004
1 байт
Регистр режима микросхемы UART консоли (MR1A, MR2A)
0x0 1С04 0005
0x0 1C04 000B
7 байт
Не определено
0x0 1С04 000С
0x0 1C04 000C
1 байт
Микросхема UARTRead консоли: регистр состояния (SRA)
Запись: регистр выбора часов (CSRA)
0x0 1С04 000D
0x0 1C04 0013
7 байт
Не определено
0x0 1С04 0014
0x0 1C04 0014
1 байт
Микросхема UARTRead консоли: не определено
Запись: регистр команды (CRA)
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x0 1С04 0015
0x0 1С04 001В
7 байт
Не определено
0x0 1С04 001С
0x0 1С04 001С
1 байт
Микросхема UART Read консоли: регистр временного хранения информации Rx (RHRA)
Запись: регистр временного хранения информации Тх (THRA)
0x0 1С04 001D
0x0 1С04 0023
7 байт
Не определено
0x0 1С04 0024
0x0 1С04 0024
1 байт
Микросхема UART Read консоли: регистр изменения входного порта (IPCR) Запись: вспомогательный регистр управления (ACR)
0x0 1С04 0025
0x0 1С04 002В
7 байт
Не определено
0x0 1С04 002С
0x0 1С04 002С
1 байт
Микросхема UARTRcad консоли: регистр состояния прерывания (ISR)
Запись: регистр маски прерывания (IMR)
0x0 1С04 002D
0x0 1С04 0033
7 байт
Не определено
0x0 1С04 0034
0x0 1С04 0034
1 байт
Микросхема UARTRcad консоли: регистр старших адресов счетчика/таймера (CTU) Запись: регистр старших адресов счетчика/таймера (CRUR)
0x0 1С04 0035
0x0 1С04 003В
7 байт
Не определено
0x0 1С04 003С
0x0 1С04 003С
1 байт
Микросхема UARTRcad консоли: регистр младших адресов счетчика/таймера (CTL)
Запись: регистр младших адресов счетчика/таймера (CTLR)
0x0 1С04 003D
0x0 1С04 0043
7 байт
Не определено
0x0 1С04 0044
0x0 1С04 007F
64 байт
Микросхема UART модема
0x0 1С04 0044
0x0 1С04 0044
1 байт
Регистр режима микросхемы UART модема (MR1B, MR2B)
0x0 1С04 0045
0x0 1С04 004В
7 байт
Не определено
0x0 1С04 004С
0x0 1С04 004С
1 байт
Микросхема UARTRead модема: регистр состояния (SRB)
Запись: регистр выбора часов (CSRB)
0x0 1С04 004D
0x0 1С04 0053
7 байт
Не определено
0x0 1С04 0054
0x0 1С04 0054
1 байт
Микросхема UARTRead модема: не определено
Запись: регистр команды (CRB)
0x0 1С04 0055
0x0 1С04 005В
7 байт
Не определено
0x0 1С04 005С
0x0 1С04 005С
1 байт
Микросхема UARTRead модема: регистр временного хранения информации Rx (RHRB)
Запись: регистр временного хранения информации Тх (THRB)
0x0 1С04 005D
0x0 1С04 0063
7 байт
Не определено
Базовый адрес памяти
Максимальный ОбъемУстройство
адрес памяти
0x0 1С04 0064
0x0 1С04 00641 байтМикросхема UARTRead модема: не оп
ределено
Запись: не определено
0x0 1С04 0065
0x0 1С04 006В7 байтНе определено
0x0 1С04 006С
0x0 1С04 006С1 байтМикросхема UARTRead модема: вход
ной порт
Запись: регистр конфигурации выходного порта (OPCR)
0x0 1С04 006D
0x0 1С04 00737 байтНе определено
0x0 1С04 0074
0x0 1С04 00741 байтМикросхема UARTRead модема: коман
да запуска счетчика
Запись: команда установки скорости выходного порта
0x0 1С04 0075
0x0 1С04 007С
0x0 1С04 007В7 байтНе определено
0x0 1С04 007С1 байтМикросхема UARTRead модема: коман
да останова счетчика
Запись: команда сброса установки скорости выходного порта
0x0 1С04 007D
0x0 1С04 0080
0x0 1С04 0100
0x0 1С04007F3 байтНеопределено
0x0 1С0400FF64 байтНеопределено
0x0 1С04FFFF64 КбайтНеопределено
0x0 1С05 0000
0x0 1С05 00034 байтРегистр управления передачей от NRP к
NSP
0x0 1С05 0004
0x0 1С05 00074 байтРегистр управления передачей от NSP к
NRP
0x0 1С05 0008
0x0 1С05 000В4 байтСемафор прерывания передачи от NRP
к NSP
0x0 1С05 000С
0x0 1С05 000F4 байтСемафор прерывания передачи от NRP
к NSP
0x0 1С05 0010
0x0 1С05 0014
0x0 1С05 00134 байтСемафор GP 0
0x0 1С05 00174 байтСемафор GP 1
0x0 1С05 0018
0x0 1С05 001В4 байтСемафор GP 2
0x0 1С05 001С
0x0 1С05 001F4 байтСемафор GP 3
0x0 1С05 0020
0x0 1С05 00234 байтРазрешение/запрешение записи в
IDPROM
0x0 1С05 0024
0x0 1C1F FFFF1,8 Мбайт Зарезервированная область ввода-вывода
0x0 1С02 0000
0x0 1DFF FFFF32 Мбайт Зарезервировано
0x0 1Е00 0000
0x0 1Е01 FFFF128 Кбайт Энергонезависимое ОЗУ
0x0 1Е02 0000
0x0 1E7F FFFF8 МбайтЗарезервировано
0x0 1Е80 0000
0x0 1ЕВ FFFF4 МбайтЗагрузочная флэш-память
0x0 1ЕС0 0000
0x0 1FBF FFFF16 Мбайт Зарезервировано
0x0 1FC0 0000
0x0 1FC7 FFFF512 Кбайт Загрузочное ППЗУ
0x0 1FC8 0000
0x0 1FDF FFFF1536 Кбайт Не определено (декодирование адресов
загрузочного ППЗУ)
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x0
1FE0
0000
0x0
3FFF
FFFF
514 Мбайт
Зарезервировано
0x0
4800
0000
0x0
487F
FFFF
8 Мбайт
Контроллер Ethernet ВРЕ
0x0
4880
0000
0x0
48FF
FFFF
8 Мбайт
Контроллер Ethernet NME
0x0
4900
0000
0x0
497F
FFFF
8 Мбайт
Контроллер Ethernet CSE
0x0
4980
0000
0x0
49FF
FFFF
8 Мбайт
Не определено (тайм-аут шины PCI)
0x0
4А00
0000
0x0
4A7F
FFFF
8 Мбайт
SAR
0x0
4А80
0000
0x0
4AFF
FFFF
8 Мбайт
Не определено (тайм-аут шины PCI)
0x0
4В00
0000
0x0
4B3F
FFFF
4 Мбайт
Память для хранения пакетов PCI, без перестановки байтов
0x0
4В40
0000
0x0
4B7F
FFFF
4 Мбайт
Не определено (тайм-аут шины PCI)
0x0
4В80
0000
0x0
4BBF
FFFF
4 Мбайт
Память для хранения пакетов PCI, с перестановкой байтов
0x0
4С00
0000
0x0
4CFF
FFFF
16 Мбайт
Не определено (тайм-аут шины PCI)
0x0
4D00
0000
0x0
5FFF
FFFF
320 Мбайт
Зарезервировано
0x0
6000
0000
0x0
601F
FFFF
2 Мбайт
Адресное пространство ввода-вывода PCI
0x0
6020
0000
0x0
BFFF
FFFF
Около
1,5 Гбайт
Зарезервировано
0x0
сооо
0000
0x0
C7FF
FFFF
128 Мбайт
Доступ шины PCI к динамическому ОЗУ с перестановкой байтов
0x0
С800
0000
0x1
4AFF
FFFF
Около
2 Гбайт
Зарезервировано
0x1
4В00
0000
0x1
4B3F
FFFF
4 Мбайт
Память процессора для хранения пакетов, без перестановки байтов
0x1
4В40
0000
0x1
FFFF
FFFF
Около
3 Гбайт
Зарезервировано
0x2
0000
0000
0x3
FFFF
FFFF
8 Гбайт
Заблокированный псевдоним кэша L2 для пространства памяти
0x4
0000
0000
0x7
FFFF
FFFF
16 Гбайт
Операция Ор 0 с дескриптором контроллера кэш-памяти L2 (объявление недействительными элементов кэша)
0x8
0000
0000
OxF
FFFF
FFFF
32 Гбайт
Операция Ор 1 с дескриптором контроллера кэш-памяти L2 (вывод всех элементов кэша)
Схема распределения памяти Cisco 6400-NSP
Все регистры и блоки памяти на плате коммутатора NSP постоянно находятся в пространстве MEMO (шина “процессор-коммутатор”) платы процессора NSP. В табл. Б. 10 представлен перечень всех адресов, декодируемых контроллером NSP-SC для себя или для других плат, с которыми он взаимодействует. Следует отметить, что операнды во всех операциях доступа имеют размер 32 бита.
Таблица Б. 10. Схема распределения памяти Cisco 6400-NSP , Адрес МЕМООписаниеОбъем (бит)
0800
0000
0800
007С
Регистры контроллера коммутатора ММС
31:0
0800
0080
0800
00FC
Зарезервировано
0800
0100
0800
оюс
Регистры Accordian
31:0
0800
ОНО
0800
01FC
Зарезерви ровано
0800
0200
0800
02D4
Регистры NSP-SC
0800
0200
Управление средствами резервирования
31:16
0800
0204
Активизация средств резервирования
31:16
0800
0208
Обнаружение линейной платы
31:16
0800
020С
Информация о готовности линейной платы
31:16
0800
0210
Обнаружение компонентов NSP, РЕМ и вентилятора
19:16
0800
0214
Информация о готовности компонентов NSP, РЕМ и вентилятора
19:16
0800
0280
Идентификатор гнезда
16
0800
0284
Управление регистром EHSA
19:16
0800
0288
Информация о ведущем компоненте
16
0800
028С
Количество случаев сброса процессора NRP
31:16
0800
0290
Синхронизация сети
17:16
0800
0294
Получатель синхросигнала BITS
18:16
0800
0298
Корректировка параметров питания
17:16
0800
029С
0807
FFFC
Зарезервировано
0808
0000
0808
1FFC
ППЗУ идентификатора NSP-SC (2 Кбаитх8)
31:24
0808
2000
0817
FFFC
Зарезервировано
0818
0000
0818
007С
Контроллер Ethernet ВРЕ
31:0
0818
0080
0827
FFFC
Зарезервировано
0828
0000
0829
FFFC
Статическое ОЗУ для буферов пакетов Ethernet ВРЕ
31:0
082А
0000
082F
FFFC
Зарезервировано
0830
0000
087F
FFFC
Плата поддержки NSP
31:0
0880
0000
08BF
FFFC
Шина РАМ X (линейные платы / процессоры NRP от 0 до 7)
31:0
08С0
0000
08FF
FFFC
Шина РАМ У (линейные платы / процессоры NRP от 8 до 15)
31:0
0900
0000
0FFF
FFFC
Зарезервировано
Схема распределения памяти Cisco 6200
‘ Таблица Б.11. Схема распределения памяти Cisco 6200
ТипДиапазон адресов Описание
Системная память
0x00000000-0x007FFFFF Системное динамическое ОЗУ (8 Мбайт)
0x00800000-0x01FFFFFF Зарезервировано (24 Мбайт)
0x02000000-0x0FFFFFFF Зарезервировано
Тип
Диапазон адресов
Описание
Пространство ввода-вывода PCI
0x10000000-0x10000003
Контроллер PCMCIA
0xl0000004-0xllFFFFFF
Зарезервировано
Пространство памяти PCI
0xl2000000-0xl200001F
Ethernet 1 (lOBaseT)
0xl2000020-0xl200003F
Ethernet 2 (10Base2)
0xl2000040-0xl20FFFFF
Зарезервировано
0xl2100000-0xl21FFFFF
TN ETA 1570 (SAR)
0x12200000-0x13FFFFFF
Зарезервировано
GT64011
0xl4000000-0xl41FFFFF
Системный контроллер
Гнездо PCMCIA 0
0xl5000000-0xl5FFFFFF
Спаренный адрес
0x16000000-0x17400000
Пространство памяти
0x17400000-0x17FFFFFF
Зарезервировано
Гнездо 1 PCMCIA
OxlSOOOOOO-OxlSFFFFFF
Спаренный адрес
0xl9000000-0xlA3FFFFF
Пространство памяти
OxlBOOOOOO-OxlBFFFFFF
Зарезервировано
Локальная шина GT
0xlC000000-0xlC7FFFFF
(CSO) DUART
OxlCBOOOOO-OxlCFFFFFF
Энергонезависимое ОЗУ/микросхема TOD (CS1)
OxlDOOOOOO-OxlDFFFFFF
Внутренняя микросхема SIMM флэш-памяти (CS2)
OxlFOOOOOO-OxlFBFFFFF
Программируемая логическая матрица ввода-вывода (CS3)
OxlFCOOOOO-OxlFFFFFFF
ППЗУ начальной загрузки (BootCS)
0x20000000-0x3FFFFFFF
Зарезервировано
Пространство PCMCIA с отображением на память
0x40000000-0x43FFFFFF
Гнездо PCMCIA 0
0x44000000-0x47FFFFFF
Гнездо PCMCIA 1
0x48000000-0xFFFFFF
Зарезерви ровано
Схема распределения памяти Cisco 6260
[ Таблица Б.12. Схема распределения памяти Cisco 6260।
Тип
Диапазон адресов
Описание
Системная память
0x00000000-0x03F00000
Системное динамическое ОЗУ (64 Мбайт)
0x04000000-0x07F00000
Зарезервировано (64 Мбайт)
Пространство памя-
OxOSOOOOOO-OxOBFFFFFF
Буферная память коммутатора для хранения
ти 2 шины PCI
ячеек (64 Мбайт)
OxOCOOOOOO-OxOCFFFFFF
Память коммутатора для хранения таблицы заголовков (16 Мбайт)
0x0D000000-0x0D7FFFFF
Память коммутатора для хранения информации о каналах (8 Мбайт)
0x0D800000-0x0D8000FF
Регистры коммутатора (64 Мбайт)
Тип
Диапазон адресов
Описание
0x0D900000-0x0D9027FF
Область памяти для хранения очереди
OxODAOOOOO-OxODAOlFFF
Область памяти для хранения данных о количестве записей во входной очереди модема
0x0DB00000-0x0DB003FF
Область памяти для ограничителя трафика
OxODBOO4OO-OxOFFFFFFF
Зарезервировано
Пространство
ввода-вывода PCI
OxlOOOOOOO-OxllFFFFFF
Зарезервировано
Пространство памяти 1 шины РС1
0xl2000000-0xl200001F
АМ79С970А (lOBaseT Ethernet)
0xl2000020-0xl2000FFF
Зарезервировано
0xl2001000-0xl2001FFF
Внутренние регистры IDT77252 SAR
0xl2100000-0xl24FFFFF
Внешнее статическое ОЗУ IDT77252 SAR
0xl3000000-0xl37FFFFF
Предыдущая программируемая логическая матрица
0xl3800000-0xl3FFFFFF
Следующая программируемая логическая матрица
GT64121
0xl4000000-0xl41FFFFF
Системный контроллер
0xl4200000-0xlBFFFFFF
Зарезервировано
Локальная шина GT
0xlC000000-0xlC7FFFFF
Микросхема DUART — консоли и вспомогательная (CSO)
OxlCSOOOOO-OxlCFFFFFF
Энергонезависимое ОЗУ/микросхема TOD (CS1)
OxlDOOOOOO-OxlDFFFFFF
Микросхема SIMM флэш-памяти (CS2)
OxlEOOOOOO-OxlEFFFFFF
Зарезервировано
OxlFOOOOOO-OxlFlFFFFF
СР EPLD (CS3)
0X1F200000-0X1F200007
Контроллер PCF8584 I2C (CS3)
0xlF200008-0xlF3FFFFF
Зарезервировано
0X1F400000-0X1F7FFFFF
Загрузочная флэш-память (CS3)
OxlFSOOOOO-OxlFBFFFFF
Зарезервировано
OxlFCOOOOO-OxlFFFFFFF
ППЗУ начальной загрузки — ROMmon (BootCS)
0x20000000-0xFFFFFFFF
Зарезервировано
Схема распределения памяти Cisco 4000
| Таблица Б.13. Схема распределения памяти Cisco 4000
Адрес
Разрядность (бит)
Описание
Примечание
00000000-0003FFFF
32
Системное статическое ОЗУ
Постоянная память на 256 Кбайт; ожидание чтения — 0, ожидание записи — 1
00040000-00FFFFFF
32
Область памяти системы на динамическом ОЗУ (микросхемы SIMM)
Поддерживается доступ без выравнивания по границе 8-, 16-, 32-битового слова;
4, 8, 16 или 32 Мбайт
Адрес
Разрядность ОписаниеПримечание
(бит)
00040000-003FFFFF
4 Мбайт
00040000-00FFFFFF
16 Мбайт
01000000-01FFFFFF
16Загрузочное ППЗУПостоянная память на
2 Мбайт
01000000-010FFFFF
1 Мбайт
01000000-011FFFFF
2 Мбайт
01000000-013FFFFF
4 Мбайт
01000000-017FFFFF
8 Мбайт
02000000-02FFFFFF
8 или 32Встроенные ресурсы системы
02020000
Системный ввод-вывод
03000000-03FFFFFF
32Флэш-СППЗУ или СППЗУ 32-битовый доступ для
чтения-записи
03000000-031FFFFF
03000000-033FFFFF
2 Мбайт
4 Мбайт
03000000-037FFFFF
8 Мбайт
05000000
Системное динамическоеВерхние 16 Мбайт области
ОЗУпамяти на 32 Мбайт
06000000-06FFFFFF
32Разделяемая памятьПоддерживается доступ без
(ввод-вывод)выравнивания по границе
8-, 16-, 32-битового слова;
1-16 Мбайт
06000000-060FFFFF
1 Мбайт
06000000-063FFFFF
06000000-067FFFFF
4 Мбайт
8 Мбайт
04000000-05FFFFFF
07000000-07FFFFFF
Не определено
Не определено
08000000-08FFFFFF
32Расширение области памя- Гнезда для модулей N1M
ти для ввода-вывода
08000000-080FFFFF
16Модуль NIM в гнезде 1Доступ только с выравни-
расширения области памя- ванием по границе 16- ти ввода-выводабитового слова
08100000-081FFFFF
16Модуль NIM в гнезде 2Доступ только с выравни-
расширения области памя- ванием по границе 16- ти ввода-вывода 2битового слова
08200000-082FFFFF
16Модуль NIM в гнезде 3Доступ только с выравни-
расширения области памя- ванием по границе 16- ти ввода-выводабитового слова
Примечания
Динамическое ОЗУ с объемом 32 Мбайт поддерживается только в устройстве Cisco 4000-М. Область памяти с объемом 32 Мбайт разбита на две отдельные части, причем отображение верхних 16 Мбайт начинается с адреса 05000000.
Поддержка флэш-памяти с объемом 8 Мбайт предусмотрена только в устройстве Cisco 4000-М.
Таблица Б.13,а. Схема распределения памяти для встроенных ресурсов i• Cisco4000
Адрес
Разрядность (бит)
Описание
Примечание
02000000-0201FFFF
8
Микросхема КМОП стати-
Объем 128 Кбайт, ста-
02110000
32
чсского ОЗУ с резервным питанием от аккумулятора энергонезависимого ОЗУ
Регистры состояния систе-
ционарная установка;
может также применяться для установки 32 Кбайтх8 и 8 Кбайтх8
02110002
02110040-0211005F
8
мы и регистры управления Версия аппаратного обеспечения
Ключевая информация
24 байт
02110100
32
ППЗУ с системным идентификатором Разделяемый регистр
02120000
8
управления памятью
Таймер счетчика
02120040
8
Регистр управления преры-
02120100-0212013F
8
ванием счетчика
Регистр управления после-
довательным вводом - выводом
Схема распределения памяти Cisco 4500, 4500-М, 4700, 4700-М
Таблица Б.14. Схема распределения памяти Cisco 4500,4500-М, 4700,4700-М.~)
Адрес
Разрядность (бит)
Описание
Примечание
60000000-61FFFFFF
64
Системное динамическое
Обеспечивает выборку
ОЗУ
одновременно от 8 до 64
битов, кэшируемое
60000000-607FFFFF
8 Мбайт
60000000-60FFFFFF
16 Мбайт
60000000-61FFFFFF
32 Мбайт
BFC00000-BFC7FFFF
8
Загрузочное ППЗУ
BFC00000-BFC1FFFF
128 Кбайт
BFC00000-BFC7FFFF
512 Кбайт
3E000000-3EFFFFFF
8
Встроенные ресурсы сис-
темы
30000000-30FFFFFF
32
Системное флэш-ППЗУ
30000000-303FFFFF
4 Мбайт
30000000-307FFFFF
8 Мбайт
Адрес
Разрядность (бит)
Описание
Примечание
30000000-30FFFFFF
16 Мбайт
38000000-387FFFFF
32
Загрузочное флэш-ППЗУ
38000000-383FFFFF
4 Мбайт
38000000-387FFFFF
8 Мбайт
40000000-40FFFFFF
32
Разделяемая память
8-, 16-, 32-битовый доступ
40000000-403FFFFF
4 Мбайт
40000000-40FFFFFF
16 Мбайт
(Таблица Б.14,а.
Схема распределения памяти для встроенных ресурсов j
Cisco 4500, 4500 М, 4700, 4700 М
Адрес
Разрядность (бит)
Описание
Примечание
3E000000-3E07FFFF
8
Энергонезависимое ОЗУ
Статическое ОЗУ с резервным питанием от аккумулятора
3E000000-3E01FFFF
8
128 Кбайт
3E000000-3E07FFFF
8
512 Кбайт
3E000000
8
Часы истинного времени
ЗЕ800400
8
Ключевая информация ППЗУ с системным идентификатором
Схема распределения памяти Cisco 3620
I Таблица Б.15. Схема распределения памяти Cisco 3620
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x0 0000 0000
0x0 03FF FFFF
Вплоть до 32
Мбайт
Главное динамическое ОЗУ (четыре 72- контактные микросхемы SIMM)
0x0 0400 0000
0x0 0FFF FFFF
Зарезервировано
0x0 1400 0000
0x0 14FF FFFF
Регистры GT64010
0x0 1Е80 0000
0x0 1E9F FFFF
Вплоть до 1
Мбайт
Регистры на плате, DUART
0x0 1ЕС0 0000
0x0 1EFF FFFF
Вплоть до 1
Мбайт
Битоприемник
0x0 1FC0 0000
0x0 1FDF FFFF
Вплоть до 1
Мбайт
Поддержка режима ROMmon
0x0 1FE0 0000
0x0 1FFF FFFF
Вплоть до 64
Кбайт
Энергонезависимое ОЗУ
0x0 3000 0000
0x0 3FFF FFFF
Вплоть до 48
Мбайт
Главная флэш-память (две 80- контактные микросхемы SIMM)
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x0 4000 0000
0x0 43FF FFFF
Вплоть до 64
Мбайт
Гнездо 1 PCMCIA
0x0 4400 0000
0x0 47FF FFFF
Вплоть до 64
Мбайт
Гнездо PCMCIA 2
0x0 4D00 0000
0x0 4D7F FFFF
Вплоть до 8
Мбайт
РМ 0, память PCI
0x0 4D80 0000
0x0 4DFF FFFF
Вплоть до 8
Мбайт
PM 1, память PCI
0x1 0000 0000
0x1 0000 7FFF
Вплоть до 32
Кбайт
Основная область ввода-вывода РС1
0x1 0000 8000
0x1 0000 9FFF
Вплоть до 8
Кбайт
РМ 0, ввод-вывод PCI
0x1 0000 А000
0x1 0000 BFFF
Вплоть до 8
Кбайт
РМ 1, ввод-вывод PCI
Схема распределения памяти Cisco 3640
I Таблица Б.16. Схема распределения памяти Cisco 3640• q
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x0
0000
0000
0x0
07FF
FFFF
Вплоть
до
64
Главное динамическое ОЗУ (четыре 72-
Мбайт
контактные микросхемы SIMM)
0x0
0800
0000
0x0
0FFF
FFFF
Зарезервировано
0x0
1400
0000
0x0
14FF
FFFF
Регистры GT64010
0x0
1Е80
0000
0x0
1E9F
FFFF
Вплоть
до
1
Регистры на плате, CS для проверки
Мбайт
DUART
0x0
1ЕС0
0000
0x0
1EFF
FFFF
Вплоть Мбайт
до
1
Битоприемник
0x0
1FC0
0000
0x0
1FDF
FFFF
Вплоть
Мбайт
до
1
Поддержка режима ROMmon
0x0
1FE0
0000
0x0
1FFF
FFFF
Вплоть
Мбайт
до
1
Энергонезависимое ОЗУ
0x0
3000
0000
0x0
3FFF
FFFF
Вплоть
до
48
Главная флэш-память (две 80-
Мбайт
контактные микросхемы SIMM)
0x0
4000
0000
0x0
43FF
FFFF
Вплоть
Мбайт
до
64
Гнездо PCMCIA 0
0x0
4400
0000
0x0
47FF
FFFF
Вплоть Мбайт
до
64
Гнездо 1 PCMCIA
0x0
4D00
0000
0x0
4D7F
FFFF
Вплоть
Мбайт
до
8
РМ 0, память РС1
0x0
4D80
0000
0x0
4DFF
FFFF
Вплоть
Мбайт
до
8
РМ 2, память PCI
0x0
4Е00
0000
0x0
4E7F
FFFF
Вплоть Мбайт
до
8
РМ 1, память РС1
0x0
4Е80
0000
0x0
4EFF
FFFF
Вплоть
Мбайт
до
8
РМ 3, память PCI
Базовый
Максимальный
Объем
Устройство
адрес памяти
адрес памяти
0x1
0000
0000
0x1
0000
7FFF
Вплоть до 32
Кбайт
Основная область ввода-вывода PCI
0x1
0000
8000
0x1
0000
9FFF
Вплоть до 8
Кбайт
РМ 0, ввод-вывод PCI
0x1
0000
А000
0x1
0000
BFFF
Вплоть до 8
Кбайт
РМ 2, ввод-вывод PCI
0x1
0000
сооо
0x1
0000
DFFF
Вплоть до 8
Кбайт
РМ 1, ввод-вывод PCI
0x1
0000
Е000
0x1
0000
FFFF
Вплоть до 8
Кбайт
РМ 3, ввод-вывод PCI
Схема распределения памяти Cisco 3660
Таблица Б.17. Схема распределения памяти Cisco 3660 .]
Базовый
Максимальный
Объем
Устройство
адрес памяти
адрес памяти
0x0
0000
0000
0x0
0FFF
FFFF
Вплоть до
Главное синхронное динамическое ОЗУ
128 Мбайт
(две 168-контактные микросхемы DIMM)
0x0
1400
0000
0x0
14FF
FFFF
Регистры GT64120
0x0
1Е00
0000
0x0
1E7F
FFFF
Вплоть до 8
Мбайт
Битоприемник
0x0
1Е80
0000
0x0
1Е83
FFFF
Вплоть до 1
Мбайт
Регистры на плате
0x0
1Е84
0000
0x0
1Е84
FFFF
Вплоть до 1
Сдвоенный универсальный асинхрон-
Мбайт
ный приемопередатчик (DUART)
0x0
1FC0
0000
0x0
1FDF
FFFF
Вплоть до 1
Мбайт
Поддержка режима ROMmon
0x0
1FE0
0000
0x0
1FFF
FFFF
Вплоть до 64
Кбайт
Энергонезависимое ОЗУ
0x0
3000
0000
0x0
33FF
FFFF
Вплоть до 64
Главная флэш-память (две 80-
Мбайт
контактные микросхемы SIMM)
0x0
3C00
0000
0x0
3C0F
FFFF
Вплоть до 1
Мбайт
Коммутатор TDM
0x0
4000
0000
0x0
43FF
FFFF
Вплоть до 64
Мбайт
Гнездо PCMCIA 0
0x0
4400
0000
0x0
47FF
FFFF
Вплоть до 64
Мбайт
Гнездо 1 PCMCIA
0x0
4800
0000
0x0
487F
FFFF
Вплоть до 8
Мбайт
ЕЕ 0/0, память PCI
0x0
4880
0000
0x0
48FF
FFFF
Вплоть до 8
Мбайт
ЕЕ 0/1, память PCI
0x0
4А00
0000
0x0
4A7F
FFFF
Вплоть до 8
Мбайт
AIM 0, память PCI
0x0
4А80
0000
0x0
4AFF
FFFF
Вплоть до 8
Мбайт
AIM 1, память PCI
Базовый
Максимальный
Объем
Устройство
адрес памяти
адрес памяти
0x0
4D00
0000
0x0
4D7F
FFFF
Вплоть до 8
Мбайт
NM 1, память PCI
0x0
4D80
0000
0x0
4DFF
FFFF
Вплоть до 8
Мбайт
NM 3, память PCI
0x0
4Е00
0000
0x0
4E7F
FFFF
Вплоть до 8 Мбайт
NM 2, память PCI
0x0
4Е80
0000
0x0
4EFF
FFFF
Вплоть до 8 Мбайт
NM 4, память PCI
0x0
4F00
0000
0x0
4F7F
FFFF
Вплоть до 8 Мбайт
NM 5, память PCI
0x0
4F80
0000
0x0
4FFF
FFFF
Вплоть до 8
Мбайт
NM 6, память PCI
0x1
0000
0000
0x1
0000
7FFF
Вплоть до 32
Кбайт
Основная область ввода-вывода PCI
0x1
0000
8000
0x1
0000
9FFF
Вплоть до 8
Кбайт
AIM 0, ввод-вывод PCI
0x1
0000
А000
0x1
0000
BFFF
Вплоть до 8
Кбайт
AIM 1, ввод-вывод PCI
0x1
0020
0000
0x1
0020
1FFF
Вплоть до 8
Кбайт
NM 1, ввод-вывод PCI
0x1
0020
2000
0x1
0020
3FFF
Вплоть до 8 Кбайт
NM 3, ввод-вывод PCI
0x1
0020
4000
0x1
0020
5FFF
Вплоть до 8
Кбайт
NM 2, ввод-вывод PCI
0x1
0020
6000
0x1
0020
7FFF
Вплоть до 8 Кбайт
NM 4, ввод-вывод PCI
0x1
0020
8000
0x1
0020
9FFF
Вплоть до 8
Кбайт
NM 5, ввод-вы вод PCI
0x1
0020
А000
0x1
0020
BFFF
Вплоть до 8
Кбайт
NM 6, ввод-вывод PCI
Схема распределения памяти Cisco 2600
Таблица Б.18. Схема распределения памяти Cisco 2600
БазовыйМаксимальный
адрес памяти адрес памяти
ОбъемУстройство
0x0000 00000x03FF FFFF
Вплоть до 64 Физическое адресное пространство Мбайт
0x4000 00000x4FFF FFFF
0x6000 00000x60FF FFFF
16 МбайтПространство памяти PCI
Вплоть до 16Флэш-память
Мбайт
0x6700 00000x67FF FFFF
64 КбайтЭнергонезависимое ОЗУ, WIC, внут
ренние регистры
0x6800 00000x6800 FFFF
Конфигурация PCI/область ввода-вывода
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x6801 0000
0x^801 FFFF
64 Кбайт
Регистры PowerQUICC
0x8000 0000
0x83FF FFFF
Вплоть до 64
Мбайт
Виртуальное адресное пространство
Схема распределения памяти Cisco 2500
[таблица Б.19. Схема распределения памяти Cisco 2500»]
Адрес
Разрядность (бит)
Описание
Примечание
00000000-00FFFFFF
32
Динамическое ОЗУ
2, 4, 8 или 16 Мбайт
00000000-001FFFFF
32
Динамическое ОЗУ на 2 Мбайт
00000000-003FFFFF
32
Динамическое ОЗУ на 4 Мбайт
00000000-007FFFFF
32
Динамическое ОЗУ на 8 Мбайт
00000000-00FFFFFF
32
Динамическое ОЗУ на 16 Мбайт
00000000-001FFFFF
8/16
Загрузочная флэш-память
1 или 2 Мбайт, если плата флэш-памяти PCMCIA не установлена
00000000-001FFFFF
16
Плата PCMCIA флэш-
Режим начальной загруз-
памяти
ки
01000000-011FFFFF
16
Загрузочные П ПЗУ для об-
ПЗУ на 1 или 2 Мбайт;
разов ROMmon и RXBOOT
флэш-память на 2 Мбайт
01000000-011FFFFF
16
Плата PCMCIA флэш-
Время установки
памяти
02000000-0201FFFF
8
Энергонезависимое ОЗУ конфигурации
32 или 128 Кбайт
02000000-02007FFF
8
Энергонезависимое ОЗУ конфигурации (32 Кбайт)
02000000-0201FFFF
8
Энергонезависимое ОЗУ конфигурации (128 Кбайт)
02100000-0213FFFF
8/16
Встроенные регистры ввода- вывода и микросхемы
03000000-03FFFFFF
32
Флэш-ОЗУ (микросхемы SIMM)
4, 8 или 16 Мбайт
03000000-033FFFFF
32
Флэш-ОЗУ (4 Мбайт)
03000000-037FFFFF
32
Флэш-ОЗУ (8 Мбайт)
03000000-03FFFFFF
32
Флэш-ОЗУ (16 Мбайт)
08000000-081FFFFF
8/16
Встроенные загрузочные
1 или 2 Мбайт, если ус-
ППЗУ (с повторным ото-
тановлена плата флэш-
бражением на память)
памяти PCMCIA
! Таблица Б.20. Схема распределения памяти Cisco 1720/']
Базовый адрес памяти
Максимальный адрес памяти
Объем
Устройство
0x0000 0000
0X027F FFFF
40 Мбайт
Динамическое ОЗУ
0x4000 0000
0x4FFF FFFF
64 Мбайт
Пространство памяти PCI
0x5000 0000
0x5000 0FFF
Сжатие
0x5008 0000
0x5008 0FFF
Шифрование
0x6000 0000
0X63FF FFFF
Зарезервировано 64 Мбайт; Флэш-память
используется
16 Мбайт
0x6800 0000
0x68FF FFFF
64 Кбайт
Энергонезависимое ОЗУ,
WIC, внутренние регистры
0x7000 0000
0x7000 FFFF
4 Кбайт
Регистры Q-SPAN
OxFFOO 0000
OxFFOO 3FFF
16 Кбайт
Регистры PowerQUICC
OxFFFO 0000
OxFFFF FFFF
1 Мбайт
Загрузочное ПЗУ
Схема распределения памяти Cisco 1600
| Таблица Б.21. Схема распределения памяти Cisco 1600
Компонент
Начальный адрес
Конечный адрес
ПЗУ
0x00000000
0X03FFFFFF
ОЗУ
0x20000000
0X03FFFFFF
ПЗУ (флажок -d)
0x04000000
0X043FFFFF
Плата PC Card (флэш-память)
0x08000000
0X08FFFFFF
Плата PC Card (атрибут)
0x09000000
0X09FFFFFF
Различные регистры
0x00000000
OxODFFFFFF
Энергонезависимое ОЗУ
ОхОЕОООООО
0X0E007FFF
DPR
OxOFFOOOOO
0X0FF00FFF
Схема распределения памяти Cisco 1400
| Таблица Б.22. Схема распределения памяти Cisco 1400< ' i
Начальный адрес
Конечный адрес
Разрядность
CS
Источник прерываний DSACK
Описание
0x02000000
0X03FFFFFF
Длинное
CS1
Внутренний
Микросхема SIMM
СЛОВО
динамического ОЗУ
0x05000000
0X07FFFFFF
CS2
Микросхема SIMM динамического ОЗУ
CS5
Встроенное динамическое ОЗУ
CS6
Встроенное динамическое ОЗУ
Начальный адрес
Конечный адрес
Разрядность
CS
Источник прерываний DSACK
Описание
0x04000000
0X043FFFFF
Слово
CSO
Внутренний
ПЗУ
0x08000000
0X08FFFFFF
Байт/слово
CS4
Внешний
Общая память на плате PC Card
0x09000000
0X09FFFFFF
Байт/слово
CS4
Внешний
Память для хранения атрибутов на плате PC Card
ОхОАОООООО
OxOAFFFFFF
Байт/слово
CS4
Внешний
Плата PC Card
0x08000000
OxOBFFFFFF
Байт/слово
CS4
Внешний
Плата PC Card
0x00000000
OxODFFFFFF
Байт
CS3
Внешний
Общее распределение адресного пространства CS3
0x00010000
OxODOlFFFF
Байт
CS3
Внешний
Адрес формирования холостых циклов
0x00020000
0x0D02FFFF
Байт
CS3
Внешний
Зарезервировано
0x00030000
0x0003FFFF
Байт
CS3
Внешний
Регистры управления платы PC Card
0x00040000
0x0D04FFFF
Байт
CS3
Внешний
Зарезервировано
0x00050000
0X0D05FFFF
Байт
CS3
Внешний
Зарезервировано для регистров WIC"
0x00060000
0X0D06FFFF
Байт
CS3
Внешний
Зарезервировано
0x00070000
0x0D07FFFF
Байт
CS3
Внешний
Зарезервировано
0x00080000
0x00080000
Байт
CS3
Внешний
Регистр состояния
0x00080001
0x00080001
Байт
CS3
Внешний
Регистр управления (светодиоды)
0x00080004
0x00080004
Байт
CS3
Внешний
Внешняя маска прерывания
0x00080005
0x00080005
Байт
CS3
Внешний
Чтен ие/оч истка внешнего прерывания
(wr)
0x00080006
0x00080006
Байт
CS3
Внешний
Защита энергонезависимого ОЗУ (запись разрешена при шестнадцатеричном значении 05)
0x0D08000F
0x0D08000F
Байт
CS3
Внешний
Зарезервировано для сброса регистра WIC
0x00880000
0x0D88FFFF
Байт
CS3
Внешний
Энергонезависимое ОЗУ
ОхОЕОООООО
0x0E7FFFFF
Длинное слово
CS7
Внешний
Пространство памяти регистра PCI
0Х0Е800000
0X0E8FFFFF
Длинное слово
CS7
Внешний
Пространство памяти PCI
Таблица Б.23. Схема распределения памяти AS5200 .,
Начальный адрес
Конечный адрес
Имя блока
Количество битов
00000000
001FFFFF
Динамическое ОЗУ на 2 Мбайт
х32
00000000
003FFFFF
Динамическое ОЗУ на 4 Мбайт
х32
00000000
007FFFFF
Динамическое ОЗУ на 8 Мбайт
х32
00000000
00FFFFFF
Динамическое ОЗУ на 16 Мбайт
х32
00000000
001FFFFF
Флэш-память на плате PCMCIA Режим начальной загрузки
х16
00000000
000FFFFF
Загрузочная флэш-память на 1 Мбайт
Режим начальной загрузки, плата флэш-памяти отсутствует
х8/16
00000000
001FFFFF
Загрузочная флэш-память на 2 Мбайт
Режим начальной загрузки, плата флэш-памяти отсутствует
х8/16
01000000
011FFFFF
Флэш-память на плате PCMCIA Время установки
х16
01000000
010FFFFF
Загрузочная флэш-память на 1 Мбайт
При отсутствии платы флэш-памяти в гнезде
х8/16
01000000
011FFFFF
Загрузочная флэш-память на 2 Мбайт
При отсутствии платы флэш-памяти в гнезде
х8/16
02000000
02007FFF
ОЗУ конфигурации на 32 Кбайт
х8
02000000
0201FFFF
ОЗУ конфигурации на 128 Кбайт
х8
02100000
0218FFFF
Ввод-вывод с отображением на память
х8/16
03000000
033FFFFF
Флэш-память на 4 Мбайт
х32
03000000
037FFFFF
Флэш-память на 8 Мбайт
х32
03000000
03FFFFFF
Флэш-память на 16 Мбайт
х32
04000000
041FFFFF
Зарезервировано, если установлена микросхема SIMM динамического ОЗУ на 16 Мбайт
х32
08000000
080FFFFF
Загрузочная флэш-память на 1 Мбайт Если установлена плата флэш-памяти
х8/16
Таблица Б.23,а. Схема распределения пространства памяти ввода-вывода
Начальный
Конечный
Имя блока
Количество
адрес
адрес
битов
02100000
021001FF
Зарезервировано
Х16
02110000
02110001
SCR 1
х!6
02110002
02110003
SCR2
х!6
02110004
02110005
SCR3
х!6
02110006
02110007
SCR4
х!6
0211000А
0211000В
ASIC REG
х!6
02110010
02110013
Старшие/младшие адреса регистра адреса ВР
Х16
Начальный адрес
Конечный адрес
Имя блока
Количество битов
02110014
02110017
Старшие/младшие адреса регистра маски ВР
х16
02110018
02110018
Регистр FC/регистр маски
х8
02110019
02110019
Регистр управления ВР
х8
02110060
02110060
Регистр ключевой информации
х8
02120040
02120040
Регистр управления счетчиком
х8
02120050
02120051
Счетчик 0
х!6
02120060
02120061
Счетчик 1
х16
02120070
02120071
Счетчик 2
х16
02120100
0212013F
DUART 2681 (консоль)
х8
Е 021300
02130003
Канал A Ethernet
х16
R 021310
0213100F
Канал A Token Ring
х16
02131010
02131011
Канал A Token Ring regO
х!6
02131012
02131013
Канал A Token Ring regl
х16
Т 021320
021320FF
Последовательный канал В DUAL
х16
02132100
02132101
Регистр модема Serial 0
х16
02132102
02132103
Регистр модема Serial 1
х16
02132104
02132105
SO ack(RD)/LED(wr)
х16
02132106
02132107
SI ack(RD)/LED(wr)
х16
02134000
02134001
Регистр состояния COPAN
х16
02135000
02135001
Идентификатор системной платы
х16
02135002
02135003
Версия системной платы
х16
02135004
02135005
Конфигурация Мбайт
х16
02135006
02135007
Регистр MB Cntl #1
х16
02135008
02135009
Регистр состояния МВ
х16
0213500А
0213500В
Регистр MB ISR #1
х16
0213500С
0213500D
Регистр MB ISR #2
х16
0213500Е
0213500F
Регистр MB Cntl #2
х16
02135010
02135011
Регистр MB Cntl #3
х16
02135012
02135013
Регистр MB Cntl #4
х!6
02135014
02135015
Регистр вектора MB IRQ
х16
02135016
021350FF
Зарезервировано
х16
02135100
0213517F
Блок TDM I/F системной платы
х16
02135180
02135181
Блокировка вывода TDM
х!6
02135182
02135183
Регистр TDM PLL
х16
02135184
02135FFF
Зарезервировано
х16
02136000
02136001
Идентификатор микросхемы сжатия
х16
02136002
02136003
Версия микросхемы сжатия
х16
02136004
02137FFF
Зарезервировано для модуля С.М.
х16
02138000
02138001
Идентификатор платы в гнезде 0
х16
02138002
02138003
Версия платы в гнезде 0
Х16
02138004
021380FF
Относится к гнезду 0
х16
Приложение Б. Схемы распределения памяти
993
Начальный адрес
Конечный адрес
Имя блока
Количество битов
02138100
0213817F
Блок TDM I/F в гнезде 0
Х16
02138180
02139FFF
Относится к гнезду 0
Х16
0213А000
0213А001
Идентификатор платы в гнезде 1
Х16
0213А002
0213А003
Версия платы в гнезде 1
Х16
0213А004
0213A0FF
Относится к гнезду 1
Х16
0213А100
0213A17F
Блок TDM I/F в гнезде 1
Х16
0213А180
0213BFFF
Относится к гнезду 1
Х16
0213С000
0213С001
Идентификатор платы в гнезде 2
Х16
0213С002
0213С003
Версия платы в гнезде 2
Х16
0213С004
0213C0FF
Относится к гнезду 2
Х16
0213С100
0213C17F
Блок TDM I/F в гнезде 2
Х16
0213С180
021DFFFF
Относится к гнезду 2
Х16
Схема распределения памяти AS5300
Таблица Б.24. Схема распределения памяти AS5300
KUSEG
Виртуальный адрес
Физический адрес
Описание
Количество битов
6000.0000-7FFF.FFFF
6000.0000-7FFF.FFFF
Главное динамическое ОЗУ
64
4000.0000-4FFF.FFFF
4000.0000-4FFF.FFFF
Разделяемое динамическое ОЗУ
32
3000.0000-37FF.FFFF
3000.0000-37FF.FFFF
Системная флэш-память
32
3800.0000-3BFF.FFFF
3800.0000-3BFF.FFFF
Флэш-память RxBoot
32
3C00.0000-3DFF.FFFF
3C00.0000-3DFF.FFFF
Ввод-вывод с применением постоянного сетевого интерфейсного модуля / съемной платы
16
3E00.0000-3E7F.FFFF
3E00.0000-3E7F.FFFF
Энергонезависимое ОЗУ
8
3E80.0000-3EFF.FFFF
3E80.0000-3EFF.FFFF
Ввод-вывод с применением процессора
16
3F00.0000-3FFF.FFFF
3F00.0000-3FFF.FFFF
Загрузочное ППЗУ
8
KSEGO
Виртуальный адрес
Физический адрес
Описание
Количество битов
8000.0000-87FF.FFFF
0000.0000-07FF.FFFF
Главное динамическое ОЗУ
64
5000.0000-5FFF.FFFF
0800.0000-0FFF.FFFF
Разделяемое динамическое ОЗУ
32
9000.0000-97FF.FFFF
1000.0000-17FF.FFFF
Системная флэш-память
32
9800.0000-9BFF.FFFF
1800.0000-1BFF.FFFF
Флэш-память RxBoot
32
9C00.0000-9DFF.FFFF
1C00.0000-1DFF.FFFF
Ввод-вывод с применением постоянного сетевого интерфейсного модуля / съемной платы
16
9E00.0000-9E7F.FFFF
1Е00.0000-1E7F.FFFF
Энергонезависимое ОЗУ
8
KSEG0
Виртуальный адрес
Физический адрес
Описание
Количество битов
9E80.0000-9EFF.FFFF
1E80.0000-1EFF.FFFF
Ввод-вывод с применением процессора
16
9F00.0000-9FFF.FFFF
1F00.0 000-1FFF.FFFF
Загрузочное ППЗУ
8
KSEG 1
Виртуальный
Физический адрес
Описание
Количество
адрес
битов
A000.0000-A7FF.FFFF
0000.0000-07FF.FFFF
Главное динамическое ОЗУ
64
A800.0000-AFFF.FFFF
0800.0000-0FFF.FFFF
Разделяемое динамическое ОЗУ
32
B000.0000-B7FF.FFFF
1000.0000-17FF.FFFF
Системная флэш-память
32
B800.0000-BBFF.FFFF
1800.0000-1BFF.FFFF
Флэш-память RxBoot
32
BC00.0000-BDFF.FFFF
1C00.0000-1DFF.FFFF
Ввод-вывод с применением постоянного сетевого интерфейсного мо- дуля/съемной платы
16
BE00.0000-BE7F.FFFF
1E00.0000-1E7F.FFFF
Энергонезависимое ОЗУ
8
BE80.0000-BEFF.FFFF
1E80.0000-1EFF.FFFF
Ввод-вывод с применением процессора
16
BF00.0000-BFFF.FFFF
1F00.0000-1FFF.FFFF
Загрузочное ППЗУ
8
Схема распределения памяти AS5800
( Таблица Б.25. Схема распределения памяти AS5800 — схемаi
|■распределения памяти NPE-200i
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 0000 0000
0x0 07FF FFFF
128 Мбайт
Системное динамическое ОЗУ
0x0 0800 0000
0x0 0FFF FFFF
128 Мбайт
Системное динамическое ОЗУ (rsvd)
0x0 1000 0000
0x0 13FF FFFF
62 Мбайт
Зарезервировано
0x0 1400 0000
0x0 141F FFFF
2 Мбайт
Регистры GT-64010
0x0 1420 0000
0x0 19FF FFFF
94 Мбайт
Зарезервировано
0x0 1А00 0000
0x0 1A3F FFFF
4 Мбайт
Внутренняя микросхема SIMM флэш-памяти
0x0 1А40 0000
0x0 1BFF FFFF
28 Мбайт
Микросхема SIMM флэш-памяти большего объема (rsvd)
0x0 1С00 0000
0x0 1D00 0000
32 Мбайт
Зарезервировано
0x0 1Е00 0000
0x0 1E1F FFFF
2 Мбайт
Энергонезависимое ОЗУ (TOD)
0x0 1Е20 0000
0x0 1E7F FFFF
6 Мбайт
Зарезервировано
0x0 1Е80 0000
0x0 1E9F FFFF
2 Мбайт
Регистры ввода-вывода
0x0 1ЕА0 0000
0x0 1EFF FFFF
6 Мбайт
Зарезервировано
0x0 1F00 0000
0x0 1FBF FFFF
12 Мбайт
Битоприемник (устройство null для чтения-записи)
Базовый адрес
КонечныйОбъемУстройствоШина
адрес
0x0 1FC0 0000
0x0 1FE0 0000
0x0 4000 0000
0x0 1FDFFFFF2 МбайтЗагрузочное ППЗУ
0x0 3FFFFFFFх МбайтЗарезервировано
0x0 43FFFFFF64 МбайтИнтерфейс от PCI кPCMCIA
(верхнее гнездо)
0x0 4400 0000
0x0 47FF FFFF 64 МбайтИнтерфейс от PCI к PCMCIA
(нижнее гнездо)
0x0 4800 0000
0x0 487F FFFF 8 МбайтFast Ethernet — ввод-вывод с ото
бражением на память
0x0 4880 0000
0x0 48FF FFFF 8 МбайтРА1 — ввод-вывод с отображением
на память
0x0 4900 0000
0x0 497f FFFF 8 МбайтРАЗ — ввод-вывод с отображением
на память
0x0 4980 0000
0x0 49FF FFFF 8 МбайтРА5 — ввод-вывод с отображением
на память
0x0 4А00 0000
0x0 4A7F FFFF 8 МбайтРА7 — ввод-вывод с отображением
на память (rsvd)
0x0 4А80 0000
0x0 4AFF FFFF 8 МбайтРА9 — ввод-вывод с отображением
на память (rsvd)
0x0 4В00 0000
0x0 4B3F FFFF 4 МбайтPCI РМ, первые 4 Мбайт, без пе
рестановки байтов
0x0 4В40 0000
0x0 4B7F FFFF 4 МбайтPCI РМ, больший РМ, без пере
становки байтов (rsvd)
0x0 4В80 0000
0x0 4BBF FFFF 4 МбайтPCI РМ, первые 4 Мбайт, с пере
становкой байтов
0x0 4ВС0 0000
0x0 4BFF FFFF 4 МбайтPCI РМ, больший РМ, с переста
новкой байтов (rsvd)
0x0 4С00 0000
0x0 4C3F FFFF 4 МбайтПсевдоним PCI РМ, первые 4
Мбайт, без перестановки байтов
0x0 4С40 0000
0x0 4C7F FFFF 4 МбайтПсевдоним PCI РМ, больший РМ,
без перестановки байтов (rsvd)
0x0 4С80 0000
0x0 4CBF FFFF 4 МбайтПсевдоним PCI РМ, первые 4
Мбайт, с перестановкой байтов
0x0 4СС0 0000
0x0 4CFF FFFF 4 МбайтПсевдоним PCI РМ, больший РМ,
с перестановкой байтов (rsvd)
0x0 4D00 0000
0x0 4D7F FFFF 8 МбайтРА2 — ввод-вывод с отображением
на память
0x0 4D80 0000
0x0 4DFF FFFF 8 МбайтРА4 — ввод-вывод с отображением
на память
0x0 4Е00 0000
0x0 4E7F FFFF 8 МбайтРА6 — ввод-вывод с отображением
на память
0x0 4Е80 0000
0x0 4EFF FFFF 8 МбайтРА8 — ввод-вывод с отображением
на память (rsvd)
0x0 4F00 0000
0x0 4F7F FFFF 8 МбайтРАЮ — ввод-вывод с отображени
ем на память (rsvd)
0x0 4F80 0000
0x0 4FFF FFFF 8 МбайтМикросхема ввода-вывода с ото
бражением на память (rsvd)
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 5000 0000
0x0 FFFF FFFF
x Мбайт
Зарезервировано
0x1 0000 0000
0x0 001F FFFF
2 Мбайт
Адресное пространство ввода- вывода PCI
0x1 0020 0000
0x1 4B7F FFFF
Около
1 Гбайт
Зарезерви рован о
0x1 4В00 0000
0x1 4B3F FFFF
4 Мбайт
CPU РМ, первые 4 Мбайт, без перестановки байтов
0x1 4В40 0000
0x1 4B7F FFFF
4 Мбайт
CPU РМ, больший РМ, без перестановки байтов (rsvd)
0x1 4В80 0000
0x1 FFFF FFFF
Около 0 Гбайт
Зарезерви рован о
0x2 0000 0000
0x3 FFFF FFFF
8 Гбайт
Кэш второго уровня заблокирован (с помошью псевдонима) для доступа к младшим адресам области объемом 8 Гбайт
0x4 0000 0000
0x7 FFFF FFFF
16 Гбайт
Операция Ор 0 дескриптора контроллера кэш-памяти
0x8 0000 0000
OxF FFFF FFFF
32 Гбайт
Операция Op I дескриптора контроллера кэш-памяти
; Таблица Б.25,а. Схема распределения памяти AS5800 — схема ‘' распределения памяти DSC . '
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 0000 0000
0x0 03FF FFFF
64 Мбайт
Системное динамическое ОЗУ
0x0 0400 0000
0x0 0FFF FFFF
192 Мбайт
Зарезервировано для динамического ОЗУ большего объема
0x0 1000 0000
0x0 13FF FFFF
62 Мбайт
Зарезервирован о
0x0 1400 0000
0x0 141F FFFF
2 Мбайт
Регистры GT-64010
0x0 1420 0000
0x0 19FF FFFF
94 Мбайт
Зарезервировано
0x0 1А00 0000
0x0 1A3F FFFF
8 Мбайт
Внутренняя микросхема SIMM флэш-памяти
Ввода- вывода
0x0 1А40 0000
0x0 1BFF FFFF
24 Мбайт
Зарезервировано: дополнительный объем флэш-памяти
Ввода- вывода
0x0 1С00 0000
0x0 1DFF FFFF
32 Мбайт
Зарезервирован о
0x0 1Е00 0000
0x0 1E01 FFFF
128 Кбайт
Применяемая по умолчанию конфигурация энергонезависимого ОЗУ
Ввода- вывода
0x0 1Е02 0000
0x0 1E1F FFFF
Около 2 Мбайт
Зарезервировано для большего энергонезависимого ОЗУ
Ввода- вывода
0x0 1Е20 0000
0x0 1E7F FFFF
6 Мбайт
Зарезервировано
0x0 1Е80 0000
0x0 1E9F FFFF
2 Мбайт
Регистры ввода-вывода
Ввода- вывода
0x0 1ЕА0 0000
0x0 1EFF FFFF
6 Мбайт
Зарезервировано
0x0 1F00 0000
0x0 1FBF FFFF
12 Мбайт
Зарезерви рован о
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 1FC0 0000
0x0 1FC7 FFFF
512 Кбайт
Загрузочное ППЗУ
0x0 1FC8 0000
0x0 1FDF FFFF
1536 Кбайт
Зарезервировано: дополнительный объем ППЗУ
0x0 1FE0 0000
0x0 3FFF FFFF
x Мбайт
Зарезервировано
0x0 4000 0000
0x0 43FF FFFF
64 Мбайт
Интерфейс от PCI к PCMCIA (верхнее гнездо)
МВО
0x0 4400 0000
0x0 47FF FFFF
64 Мбайт
Интерфейс от PCI к PCMCIA (нижнее гнездо)
МВО
0x0 4800 0000
0x0 4800 07FF
2 Кбайт
Соединительный провод объединительной платы: Fast Ethernet 0
МВО
0x0 4800 0800
0x0 4800 OFFF
2 Кбайт
Соединительный провод объединительной платы: Fast Ethernet 1
МВО
0x0 4800 1000
0x0 4800 17FF
2 Кбайт
Соединительный провод объединительной платы: Fast Ethernet 2 (между платами DSC)
МВО
0x0 4800 1800
0x0 4800 1FFF
2 Кбайт
Лицевая панель lOBaseT МАС
МВО
0x0 4800 2000
0x0 487F FFFF
Около 8 Кбайт
Зарезервировано: устройство PCI с отображением на память
МВО
0x0 4880 0000
0x0 4BFF FFFF
56 Мбайт
PCI устройство с отображенной памятью (МВ1 в магистральных платах)
МВО
0x0 4С00 0000
0x0 4F7F FFFF
56 Мбайт
PCI устройство с отображенной памятью (МВ2 в плате СЕ1)
МВО
0x0 4F80 0000
0x0 4FFF FFFF
8 Мбайт
Зарезервировано: устройство PCI с отображением на память
МВО
0x0 5000 0000
0x0 FFFF FFFF
х Мбайт
Зарезервировано
0x1 0000 0000
0x0 001F FFFF
2 Мбайт
Адресное пространство ввода- вывода PCI
МВО
0x1 0020 0000
0x1 FFFF FFFF
Около 4 Гбайт
Зарезервировано
0x2 0000 0000
0x3 FFFF FFFF
8 Гбайт
Псевдоним — младшие 8 Гбайт, кэш L2 заблокирован
0x4 0000 0000
0x7 FFFF FFFF
16 Гбайт
Операция Ор 0 дескриптора контроллера кэш-памяти*
0x8 0000 0000
OxF FFFF FFFF
32 Гбайт
Операция Ор 1 дескриптора контроллера кэш-памяти
[ Таблица Б.25,б. Схема распределения памяти AS5800 — схема .
Шина
Базовый адрес
■' распределения памяти платы модема
Конечный адрес
Объем
Устройство
0x0 0000 0000
0x0 03FF FFFF
64 Мбайт
Системное динамическое ОЗУ
0x0 0400 0000
0x0 OFFF FFFF
192 Мбайт
Зарезервировано для динамического ОЗУ большего объема
0x0 1000 0000
0x0 13FF FFFF
62 Мбайт
Зарезервировано
0x0 1400 0000
0x0 141F FFFF
2 Мбайт
Регистры GT-64010
0x0 1420 0000
0x0 19FF FFFF
94 Мбайт
Зарезервировано
0x0 1А00 0000
0x0 1BFF FFFF
32 Мбайт
Зарезервировано (флэш-память на плате DSC)
Ввода- вывода
0x0 1С00 0000
0x0 1DFF FFFF
32 Мбайт
Зарезервировано
0x0 1Е00 0000
0x0 1E01 FFFF
128 Кбайт
Зарезервировано
(энергонезависимое ОЗУ на плате DSC)
Ввода- вывода
0x0 1Е02 0000
0x0 1E1F FFFF
Около 2 Мбайт
Зарезервирован о
Ввода- вывода
0x0 1Е20 0000
0x0 1E7F FFFF
6 Мбайт
Зарезервировано
0x0 1Е80 0000
0x0 1E9F FFFF
2 Мбайт
Регистры ввода-вывода
Ввода- вывода
0x0 1ЕА0 0000
0x0 1EFF FFFF
6 Мбайт
Зарезервировано
0x0 1F00 0000
0x0 1FBF FFFF
12 Мбайт
Зарезервировано
0x0 1FC0 0000
0x0 1FC7 FFFF
512 Кбайт
Загрузочное ППЗУ
Ввода- вывода
0x0 1FC8 0000
0x0 1FDF FFFF
1536 Кбайт
Зарезервировано: дополнительный объем ППЗУ
Ввода- вывода
0x0 1FE0 0000
0x0 3FFF FFFF
х Мбайт
Зарезервировано
0x0 4000 0000
0x0 47FF FFFF
128 Мбайт
Зарезервировано (микросхема PCMCIA на плате DSC)
мво
0x0 4800 0000
0x0 4800 07FF
2 Кбайт
Соединительный провод объединительной платы: Fast Ethernet Тх МАС
мво
0x0 4800 0800
0x0 4800 OFFF
2 Кбайт
Соединительный провод объединительной платы: Fast Ethernet Rx MAC
мво
0x0 4800 1000
0x0 4800 18FF
Около 2 Кбайт
Зарезервировано
мво
0x0 4800 1900
0x0 4800 19FF
256 Кбайт
Доступ в памяти к оперативным регистрам PLX9060SD
мво
0x0 4800 1А00
0x0 49FF FFFF
Около 32
Кбайт
Зарезервировано: устройство PCI с отображением на память
мво
0x0 4А00 0000
0x0 4BFF FFFF
32 Мбайт
Устройство PCI с отображением на память для конкретной платы модема
мво
0x0 4С00 0000
0x0 4FFF FFFF
64 Мбайт
Зарезервированное устройство PCI с отображением на память
мво
0x0 5000 0000
0x0 FFFF FFFF
х Мбайт
Зарезервировано
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x1
0000
0000
0x0
001F
FFFF
2 Мбайт
Адресное пространство ввода- вывода PCI
мво
0x1
0020
0000
0x1
FFFF
FFFF
Около 4 Гбайт
Зарезервировано
0x2
0000
0000
0x3
FFFF
FFFF
8 Гбайт
Псевдоним — младшие 8 Гбайт, кэш L2 заблокирован
0x4
0000
0000
0x7
FFFF
FFFF
16 Гбайт
Операция Ор 0 дескриптора контроллера кэш-памяти3
0x8
0000
0000
OxF
FFFF
FFFF
32 Гбайт
Операция Ор 1 дескриптора контроллера кэш-памяти4
1 Таблица Б.25,в. Схема распределения памяти AS5800 — схема'
г'
распределения памяти магистральной платы
Базовый
Конечный
Объем
Устройство
Шина
адрес
адрес
0x0
0000
0000
0x0
03FF
FFFF
64 Мбайт
Системное динамическое ОЗУ
0x0
0400
0000
0x0
0FFF
FFFF
192 Мбайт
Зарезервировано для динамического ОЗУ большего объема
0x0
1000
0000
0x0
13FF
FFFF
62 Мбайт
Активизируется ошибка шины — неправильный адрес
0x0
1400
0000
0x0
141F
FFFF
2 Мбайт
Регистры Gt64010A
0x0
1420
0000
0x0
14FF
FFFF
х Мбайт
Контрольный тайм-аут декодиро-
Внутрен-
вания допустимого адреса
няя
0x0
1500
0000
0x0
1E7F
FFFF
х Мбайт
Активизируется ошибка шины — неправильный адрес
0x0
1Е80
0000
0x0
1E8F
FFFF
2 Мбайт
Регистры ввода-вывода
Ввода-
вывода
0x0
1Е90
0000
0x0
1FBF
FFFF
Активизируется ошибка шины — неправильный адрес
0x0
1FC0
0000
0x0
1FC7
FFFF
512 Кбайт
Загрузочное ППЗУ
Ввода-
вывода
0x0
1FC8
0000
0x0
1FDF
FFFF
1536 Кбайт
Зарезервировано для большего
Ввода-
ППЗУ
вывода
0x0
1FE0
0000
0x0
47FF
FFFF
128 Мбайт
Активизируется ошибка шины — неправильный адрес
0x0
4800
0000
0x0
4800
07FF
2 Кбайт
Контроллер магистрального интерфейса Fast Ethernet 0
мво
0x0
4800
0800
0x0
4800
0FFF
2 Кбайт
Контроллер магистрального интерфейса Fast Ethernet 1
мво
3 Если происходит обращение к этому пространству, выводится кэш L2 для его псевдонима в младших адресах области памяти 8 Гбайт, а соответствующий дескриптор объявляется недействительным.
4 Если происходит обращение к этому пространству, выводится и объявляется недействительным весь кэш L2.
Базовый адрес
Конечный адрес
Объем
Устройство
Шина
0x0 4800 1000
0x0 4800 18FF
2 Кбайт
Зарезервировано
МВО
0x0 4800 2000
0x0 4800 2FFF
4 Кбайт
Регистры Gt64011 с отображением на память PCI
МВО
0x0 4820 0000
0x0 482F FFFF
1 Мбайт
Динамическое ОЗУ FDL с отображением на память PCI
МВО
0x0 4830 0000
0x0 487F FFFF
5 Мбайт
Динамическое ОЗУ типа Future с отображением на память PCI
МВО
0x0 487F FFFF
0x0 48BF FFFF
4 Мбайт
Микросхема М32х 0 с отображением на память PCI
МВ1
0x0 48С0 0000
0x0 48FF FFFF
4 Мбайт
Микросхема М32х 1 с отображением на память PCI
МВ1
0x0 4900 0000
0x0 493F FFFF
4 Мбайт
Микросхема М32х 2 с отображением на память PCI
МВ1
Схема распределения памяти Cisco 1000,1003/1004/1005
|^а6л^^Х26;
Схема распределения памяти Cisco 10ОО, 1003/1004/1005j
Адрес
Объем
Вариант микросхемы
Описание
0000000-00FFFFF
I Мбайт
CS0
ПЗУ
2000000-2FFFFFF
16 Мбайт
CS1, 2
Динамическое ОЗУ до 16 Мбайт
6000000-600FFFF
64 Кбайт
CS6
Пространство ввода-вывода PCMCIA
8000000-800FFFF
16 Мбайт
CS5
Память для хранения атрибутов платы PCMCIA/платы PC Card
8010000-8FFFFFF
16 Мбайт
CS5
Обшая память платы PCMCIA/платы PC Card
С0003Е0-С0003Е1
64 Кбайт
CS4
Регистр индекса и регистр данных контроллера PCMCIA
E000000-E007FFF
32 Кбайт
CS7
Энергонезависимое ОЗУ
FF00000-FF00FFF
1 Мбайт
36ODPR
Двухпортовая микросхема памяти 68360 (верхний 1 Мбайт)
Пространство процессора:
003FF00-003FF03
4 байт
Блок МВАКдля микросхемы 68360
Схема распределения памяти VIP2
s Таблица Б.27. Схема распределения памяти VIP2
Физический адрес
Сегмент
Объем
Режим Reno
Контроль четности процессором
Описание
0000
0000-07FF
FFFF
kseg 0/1
128 Мбайт
0
Да
64-битовое глав-
ное динамическое
ОЗУ (64 бита)
0800
0000-0FFF
FFFF
128 Мбайт
1+3
Да
Не используется (32-битовая область назначения)
1000
0000-1003
FFFF
kseg 0/1
256 Кбайт
2+3
Пространство конфигурации специализированн ой микросхемы РМА (32 бита)
1004
0000-1003
FFFF
kseg 0/1
256 Кбайт
2+3
Пространство конфигурации специализированн ой микросхемы CYA (32 бита)
1008
0000-10FF
FFFF
15,5 Мбайт
2+3
Не используется (32-битовая область назначения)
1100
0000-11FF
FFFF
kseg 0/1
16 Мбайт
2+3
Память
Cbus/MEMD (32 бита)
1200
0000-12FF
FFFF
kseg 0/1
16 Мбайт
2+3
Память PCI/SRAM (32 бита)
1300
0000-13FF
FFFF
kseg 0/1
16 Мбайт
2+3
Шина PCI: пространство ввода- вывода (32 бита)
1400
0000-17FF
FFFF
kseg 0/1
64 Мбайт
2+3
Шина PCI: пространство памяти (32 бита)
1800
0000-1BFF
FFFF
64 Мбайт
2+3
Не используется (32-битовая область назначения)
1С00
0000-1С03
FFFF
kseg 0/1
256 Кбайт
1+3
Контроллер прерываний (16 битов)
1С04
0000-1DFF
FFFF
Около 32
1+3
Не используется
Мбайт
(16-битовая область назначения)
1Е00
0000-1E7F
FFFF
8 Мбайт
2+3
Не используется (8-битовая область назначения)
Физический адрес
Сегмент
Объем
Режим Reno
Контроль четности процессором
Описание
1Е80
0000-1EBF
FFFF
4 Мбайт
2+3
Не используется (32-битовая область назначения)
1ЕС0
0000-1ECF
FFFF
kseg 0/1
1 Мбайт
0
32-битовый регистр исключения адреса: динамическое ОЗУ типа Reno
1ED0
0000-1EFF
FFFF
kseg 0/1
1 Мбайт
1+3
32-битовый регистр исключения адреса: устройство ввода-вывод типа Reno
1F00
0000-1FBF
FFFF
kseg 0
12 Мбайт
2+3
Не используется (8-битовая область назначения)
1FC00 0000-1FFF
kseg 0
4 Мбайт
2+3
8-битовое ППЗУ
FFFF
начальной загрузки
2000
0000-27FF
FFFF
128 Мбайт
1+3
Не используется (32-битовая область назначения)
2800
0000-2FFF
FFFF
128 Мбайт
2+3
Не используется (32-битовая область назначения)
3000
0000-3003
FFFF
kuseg
256 Кбайт
2+3
Пространство конфигурации специализированн ой микросхемы РМА (32 бита)
3004
0000-3007
FFFF
kuseg
256 Кбайт
2+3
Пространство конфигурации специализированн ой микросхемы CYA (32 бита)
3008
0000-30FF
FFFF
kuseg
15,5 Мбайт
2+3
Не используется (32-битовая область назначения)
3100
0000-31FF
FFFF
kuseg
16 Мбайт
2+3
Память ■
Cbus/MEMD (32 бита)
3200
0000-32FF
FFFF
kuseg
16 Мбайт
2+3
Память PCI/SRAM (32 бита)
3300
0000-33FF
FFFF
kuseg
16 Мбайт
2+3
Шина PCI: про-
странство ввода- вывода (32 бита)
Физический адрес Сегмент ОбъемРежим
Reno
КонтрольОписание
четности процессором
3400 0000-37FF FFFF kuseg64 Мбайт2+3
Шина PCI: пространство памяти (32 бита)
3800 0000-3BFF FFFF kuseg64 Мбайт2+3
Не используется (32-битовая область назначения)
ПриложениеПриложениевв
Приложение
Приложение
в
в
Информация о технической поддержке
При возникновении проблемы, которую заказчик не может решить собственными силами, необходимо обратиться к представителю службы технической поддержки ' корпорации Cisco Systems. Для анализа проблемы представителю службы технической 1,1 поддержки требуется определенная информация о сложившейся ситуации и наблю- # даемых признаках неисправности. Чтобы ускорить процесс поиска и устранения на- рушенйй.в работе,соберите необходимые данные, прежде чем обращаться в службу « технической поддержки.
^, В настоящем приложении описаны способы сбора необходимой информации об объединенной сети ■ и подготовки этой информации для передачи представителю ^ . службы технической поддержки. Дополнительные сведения о том, какую конкретную информацию необходимо собрать для каждой определенной сетевой технологии, приведены в соответствующих главах этой книги. Там же описано, как использовать Web- узел ССО — основной канал технической поддержки корпорации Cisco, доступный в реальном масштабе времени в World Wide Web (WWW), и поставляемую на CD-ROM библиотеку документов у с информацией о продуктах Cisco, Cisco Connection Documentation. Оба эти Информационных источника предоставляют важные сведения по устранению нарушений в работе сети. Прежде чем обращаться в службу технической поддержки, необходимо выполнить на узле ССО поиск документации по рассматриваемой проблеме^
Сбор информации об объединенной сети
Прежде чем приступать к сбору каких-либо конкретных данных, составьте список Всех признаков неисправностей, наблюдаемых в сети (например, разрыв соединений или"замедленное поступление ответа от хоста).
gHa следующем этапе необходимо собрать конкретную информацию. Как правило, для устранения нарушений в работе объединенной сети необходимо собрать информацию, которая относится к двум основным категориям: информация, необходимая •ВО всех ситуациях, и информация, относящаяся к конкретной топологии, технологии, .протоколу или неисправности.
Ниже перечислена информация, которая всегда требуется специалистам службы технической поддержки.
Листинги файлов конфигурации со всех рассматриваемых маршрутизаторов.
Полный перечень характеристик всех рассматриваемых маршрутизаторов.
Описание всех изменений, выполненных в сети перед появлением нарушения в работе или признака неисправности (если таковые были сделаны).
Описание характера проблемы (возникает ли эта проблема периодически, какие при этом наблюдаются сообщения об ошибках, и т.д.).
Данные о номерах версий программного обеспечения (полученные с помощью команды show version) и встроенного программного обеспечения (полученные с помощью команды show controllers) всех рассматриваемых маршрутизаторов.
Топологическая схема сети.
Список хостов и серверов (тип хоста и сервера, количество и назначение хостов и серверов каждого типа в данной сети, перечень типов применяемых операционных систем хостов).
Список протоколов сетевого уровня, версий и поставщиков.
Для упрощения процесса сбора этих необходимых данных в программное обеспечение Cisco IOS 11.1(4) и последующих версий введена exec-команда show tech-support. Эта команда предоставляет общую информацию о маршрутизаторе, которая может быть передана представителю службы технической поддержки вместе с описанием проблемы.
Команда show tech-support выводит данные, эквивалентные данным ехес-команд show version, show running-config, show controllers, show stacks, show interfaces, show buffers, show process memory и show process cpu, вместе взятым. Во многих случаях вывод команды show tech-support может оказаться весьма объемным и поэтому на время снижает производительность маршрутизатора.
При определенных условиях может потребоваться получить результаты выполнения следующих команд.
Вывод команд show общего назначения.
show interfaces.
show controllers.
show processes {cpu | mem).
show buffer.
show mem summary.
Вывод команд show для конкретного протокола.
show protocol route.
show protocol traffic.
show protocol interfaces.
show protocol arp.
show appletalk globals (только для AppleTalk).
show ipx servers (только для Novell IPX).
Вывод соответствующих привилегированных exec-команд debug.
В случае необходимости, вывод результатов диагностических проверок с помощью команд ping и trace, относящихся к конкретным протоколам.
В случае необходимости, данные трассировки, полученные с помощью сетевого анализатора.
В случае необходимости, дампы ядра, полученные с помощью команды конфигурации маршрутизатора exception dump или команды конфигурации маршрутизатора write core, если система работоспособна.
Получение данных с маршрутизатора
Способ получения информации с маршрутизатора зависит от платформы, применяемой для сбора этой информации. Ниже приведены некоторые рекомендации, касающиеся различных платформ.
Персональные компьютеры и компьютеры Macintosh. Подключите персональный компьютер или компьютер Macintosh к порту консоли маршрутизатора и выведите все полученные данные в файл журнала на диске (с помощью программы эмуляции терминала). Применяемая при этом процедура зависит от того, какой программный пакет связи установлен в системе.
Терминал, подключенный к порту консоли, или удаленный терминал. Единственный способ получения информации с помощью терминала, подключенного к порту консоли, или удаленного терминала состоит в присоединении принтера к вспомогательному порту терминала (если он существует) и применении принудительного вывода всех данных, отображаемых на экране, на этот принтер. Но такой метод не рекомендуется, поскольку он не позволяет вывести полученные данные в файл.
Рабочая станция UNIX. В приглашении к вводу команд UNIX введите команду script filename, где filename — имя файла назначения для журнала, а затем установите сеанс связи с маршрутизатором по протоколу Telnet. Команда script системы UNIX применяется для перехвата информации, выводимой на экран, в указанный файл. Чтобы остановить перехват выходных данных и закрыть файл, введите обозначение конца файла (как правило, <Ctrl+D>) для конкретной системы UNIX.
Примечание
Для обеспечения автоматического вывода в конкретной системе сообщений об ошибках или эксплуатационной информации в журнал, который ведется на сервере системного журнала UNIX, применяется команда конфигурации маршрутизатора logging internet-address. Для получения дополнительной информации об использовании команды logging и о настройке сервера системного журнала обратитесь к руководствам по настройке конфигурации и справочникам команд Cisco IOS.
Доступ к удаленному порту консоли и вспомогательному порту
Дистанционный доступ к маршрутизатору без подключения маршрутизатора к сети может быть получен путем непосредственного установления коммутируемого сеанса
связи с портом консоли или вспомогательным портом маршрутизатора. Как правило, рекомендуется использовать порт консоли, поскольку через него отображаются сообщения о запуске маршрутизатора, а через вспомогательный порт эта информация не предоставляется. Кроме того, если маршрутизатор зависает в процессе работы в режиме ROMmon, то подключение с помощью порта консоли позволяет перезагрузить систему. Но если к консоли уже подключен локальный терминал, то не остается иного выхода, кроме подключения к вспомогательному порту. Ниже описаны общие требования, которые должны быть выполнены для дистанционного подключения к маршрутизатору Cisco через порт консоли или вспомогательный порт.
Подключение модема к порту консоли
Для дистанционного подключения к порту консоли маршрутизатора Cisco необходимо следующее:
кабель нуль-модема;
персональный компьютер или эквивалентное устройство с подходящим программным обеспечением связи;
модем со скоростью передачи 14,4 Кбит/с.
При инсталляции программного обеспечения связи выполните настройку конфигурации последовательного порта персонального компьютера (или эквивалентного устройства) на скорость 9600 бод (программная установка).
Настройку конфигурации модема, подключенного к порту консоли маршрутизатора, необходимо выполнить следующим образом.
Установить постоянную скорость устройства DTE, равную 9600 бод.
Отменить применение средств управления потоком данных.
Установить режим автоматического ответа.
Отменить эхо-повтор.
Отменить вывод результатов.
Примечание
Обратитесь к документации по конкретному модему, чтобы определить, какие команды требуются для установки в модеме соответствующих опций. Изучите документацию к модему и аппаратным средствам маршрутизатора для ознакомления с требованиями по применению кабелей.
Подключение модема к вспомогательному порту
Для дистанционного подключения к порту консоли маршрутизатора Cisco необходимо следующее:
последовательный кабель с прямым подключением выводов (прямой кабель);
персональный компьютер или эквивалентное устройство с подходящим программным обеспечением связи;
модем со скоростью передачи 14,4 Кбит/с.
Чтобы выполнить настройку вспомогательного порта маршрутизатора для удаленного доступа, необходимо включить в его конфигурацию следующие команды:
line aux 0;
modem inout.
При использовании программного обеспечения с версией, предшествующей Cisco IOS 11.1, необходимо установить опции модема, как указано в описании, относящемся к порту консоли.
Если же используется программное обеспечение Cisco IOS 11.1 или последующих версий, то нет необходимости выполнять настройку конфигурации модема вручную, но требуется включить в состав конфигурации канала подкоманду modem autoconfigure discovery.
Примечание
Дополнительная информация по этой теме приведена также в главе 16.
Узел ССО
Узел ССО, который прежде назывался CIO (Cisco Information Online — центр оперативной информации Cisco), является основным каналом технической поддержки корпорации Cisco Systems в реальном масштабе времени. Клиенты, заключившие договора на техническое обслуживание, а также партнеры этой компании имеют право самостоятельно регистрироваться на узле ССО для получения дополнительной информации и услуг.
Узел ССО работает круглосуточно, семь дней в неделю; он предоставляет заказчикам и деловым партнерам Cisco доступ к широкому набору стандартных и дополнительных услуг. В частности, на узле ССО можно получить информацию о продуктах и обновления программного обеспечения, ознакомиться с примечаниями к выпускам, техническими рекомендациями, руководствами по настройке конфигурации, рекламными проспектами и описаниями сервисных предложений, воспользоваться инструментальными средствами Bug Navigator и Troubleshooting Engine, а также получить доступ к файлам, предназначенным для общего и ограниченного использования, и загрузить их.
Узел ССО обслуживает широкий круг пользователей с помощью двух интерфейсов, которые обновляются и совершенствуются одновременно: мультимедийной версии, которая основана на использовании средств WWW, и символьной версии. Версия WWW узла ССО предоставляет доступ к качественно отформатированным документам с фотографиями, рисунками, диаграммами и видеоданными, а также содержит ссылки на соответствующую информацию, официальную документацию и технические рекомендации. Символьная версия ССО поддерживает опции загрузки с помощью протоколов Zmodem, Kermit, Xmodem, FTP, электронной почты Internet, а также факс- аппаратов, и является незаменимым средством быстрого доступа к информации по каналам с низкой пропускной способностью.
К узлу ССО можно обратиться:
с помощью протоколов WWW: www.cisco.com;
с применением протокола Telnet: cco.cisco.com;
с помощью модема: из Северной Америки — по телефону 408-526-8070, из Европы — по телефону 33 1 64 46 40 82. При этом должны применяться следую-
шие параметры настройки терминала: эмуляция VT100, 8 битов данных, 1 столовый бит, без контроля четности, скорость передачи данных — до 14,4 Кбит/с.
Чтобы получить по электронной почте с узла ССО копии файла с ответами на часто задаваемые вопросы (FAQ — Frequently Asked Questions), отправьте письмо по адресу cco-help@cisco.com. Для получения дополнительной информации отправьте по электронной почте письмо по адресу cco-team@cisco.com.
Службы поиска неисправностей узла ССО
Зарегистрированные пользователи ССО могут воспользоваться целым рядом служб технической поддержки, основанных на применении средств WWW, которые предоставляются организацией Customer Support Engineering корпорации Cisco. Эти службы могут применяться при диагностировании и устранении нарушений в работе сети. Доступ к соответствующим инструментальным средствам предоставляется зарегистрированным пользователям узла ССО после перехода на страницу ТАС этого узла. Ниже приведен перечень служб и инструментальных средств поиска неисправностей с интерфейсом WWW.
Open Q&A Forum. Это интерактивное инструментальное средство обеспечивает быстрый поиск в базе данных ответов на часто возникающие технические вопросы. Если эти вопросы окажутся более сложными по сравнению с теми, что представлены в базе данных, то к обслуживанию заказчика привлекаются квалифицированные эксперты CCIE, которые помогают решить конкретную проблему.
Automated ТАС Case Management. Инструментальные средства отслеживания проблемных ситуаций узла ССО позволяют регистрировать конкретные проблемные ситуации (оформлять их как технические дела), вести и контролировать соответствующие дела.
Troubleshooting Assistant. Данное инструментальное средство позволяет устранить очень многие нарушения в работе объединенной сети с помощью удобного Web- интерфейса. Оно поддерживает широкий перечень технологий и протоколов.
Stack Decoder. Это инструментальное средство позволяет анализировать и диагностировать неисправности по трассировке стека, полученной с маршрутизатора Cisco IOS. В окно этого инструментального средства можно скопировать выходные данные exec-команды show stack и просмотреть результаты на экране или получить их по электронной почте.
Hardware/Software Compatibility Matrix. Это инструментальное средство может применяться для определения совместимости между кодами аппаратных продуктов и версиями программного обеспечения.
Software Bug Toolkit. Это инструментальное средство используется для поиска обнаруженных ошибок в программном обеспечении с учетом версии и применяемых наборов программных средств.
Все пользователи узла ССО (и зарегистрированные пользователи, и обычные посетители) могут получить ответы на часто задаваемые вопросы, ознакомиться с результатами анализа примеров практической реализации, изучить технические рекомендации, процедуры реализации и примеры конфигурации, обратившись на общедоступный узел ССО (www.cisco.com/public/Support_root.shtml).
Чтобы стать зарегистрированным пользователем узла ССО, перейдите по адресу www.cisco.com/public/registration.shtml.
Подготовка данных для представителя службы технической поддержки
Если необходимо получить техническую поддержку продукта Cisco, на который распространяется гарантия или контракт по техническому сопровождению, обратитесь в центр Cisco ТАС и оформите заявку на получение технической помощи. Для этого необходимо позвонить по телефону или отправить сообщение по электронной почте.
Северная Америка — 800-553-2447; электронная почта — tac@cisco.com.
Европа — 32 2 704 5555; электронная почта — euro-tac@cisco.com.
Азиатско-тихоокеанский регион — 61 2 8448 7107; электронная почта — asiapac-tac@cisco.com.
Чтобы получить дополнительную информацию о том, как обратиться на ближайший центр ТАС, перейдите на Web-страницу ТАС на узле ССО.
При передаче информации представителю службы технической поддержки наиболее удобными являются данные в электронном виде. Такой способ представления данных намного упрощает передачу информации между персоналом службы технической поддержки и разработчиками. К числу наиболее часто применяемых для этого электронных форматов относятся форматы данных, предназначенные для передачи данных по электронной почте и пересылки файлов по протоколу FTP.
При подготовке данных для их передачи представителю службы технической поддержки руководствуйтесь следующим списком для выбора наиболее подходящего метода передачи.
Наилучший способ пересылки информации по Internet состоит в использовании протокола FTP. Если у вас есть возможность использовать протокол FTP, поместите свой файл во входяший каталог на хосте cco.cisco.com.
Менее приемлемым способом является передача данных по электронной почте. Прежде чем им воспользоваться, обязательно проконсультируйтесь с представителем службы технической поддержки, особенно перед передачей двоичных дампов ядра или других крупных файлов.
При использовании электронной почты не применяйте такие методы кодирования, как BINHEX или ZIP. Должны применяться только методы кодирования, совместимые со стандартом MIME.
Для выгрузки файлов на узел ССО могут также применяться такие протоколы связи для персонального компьютера, как Kermit. Еще раз отметим, что перед передачей любых данных следует обратиться к представителю службы технической поддержки.
Данные могут быть переданы на диске или на ленте.
Наименее удобным способом является передача твердой копии по факсу или по обычной почте.
Предметный указатель
А
АА
Area Address, 375
адрес зоны, 375
ААА
Authentication, Authorization, Accounting, 537 аутентификация, авторизация и учет, 537
AAL
ATM Adaptation Layer, 663
уровень адаптации ATM, 663
AAL5
ATM Adaptation Layer 5, 663
уровень 5 адаптации ATM, 663
AARP
AppleTalk Address Resolution
Protocol, 254; 323
протокол преобразования адресов
AppleTalk, 254; 323
АВТ
Answer Back Tone, 553
ответный тональный сигнал, 553
ADSP
AppleTalk Data Stream Protocol, 261
протокол передачи данных
AppleTalk, 261
AEP
AppleTalk Echo Protocol, 257
эхо-протокол AppleTalk, 257
AFI
Authority and Format Identifier, 374
идентификатор полномочий и формата, 374
AFP
AppleTalk Filing Protocol, 262
файловый протокол AppleTalk, 262
AIS
Alarm Indication Signal, 468 предупреждение об обнаружении ошибки, 468
ALO
At-Least-Once, 261
многократная транзакция, 261
ALS
Active Line State, 150
состояние активного канала, 150 AMI
Alternate Mark Inversion, 449 кодирование с чередованием полярности элементов, 449 AN I
Automatic Number Identification, 524 автоматическая идентификация номера, 524
ANSI
American National Standards Institute, 373
Национальный институт стандартизации США, 373 ARA
AppleTalk Remote Access, 262 служба удаленного доступа
AppleTalk, 262 ARAP
AppleTalk Remote Access Protocol, 294
протокол удаленного доступа AppleTalk, 294
ARP
Address Resolution Protocol, 53 протокол преобразования адресов, 53
ASP
AppleTalk Session Protocol, 261 сеансовый протокол AppleTalk, 261
ATM
Asynchronous Transfer Mode, 661
режим асинхронной передачи, 661 ATM-DXI
Asynchronous Transfer Mode-Data Exchange Interface, 423 режим асинхронной передачи — интерфейс обмена данными, 423 АТР
AppleTalk Transaction Protocol, 257
протокол транзакций AppleTalk, 257 ALII
Attached Unit Interface, 124 интерфейс подключаемого устройства, 124
AURP
AppleTalk Update-Based Routing Protocol, 257
протокол маршрутизации AppleTalk на базе обновлений, 257
В
B8ZS
Binary Eight-Zero Substitution, 449 подстановка кода вместо восьми двоичных нулей, 449
BDC
Backup Domain Controller, 812 резервный контроллер домена, 812
BECN
Backward Explicit Congestion Notification, 592
обратное явное уведомление о заторе, 592
BER
Bit Error Rate, 465
частота появления ошибочных битов, 465
BGP
Border Gateway Protocol, 415
протокол граничного шлюза, 415 BIA
Burned-In Address, 647 прошитый адрес, 647
В МА
Buffer Management ASIC, 954 специализированная микросхема управления буферизацией данных, 954
BPDU
Bridge Protocol Data Unit, 625 блок данных мостового протокола, 625
BRI
Basic Rate Interface, 65 интерфейс базовой скорости передачи, 65
BSTUN
Block Serial Tunnel, 423
блочный последовательный туннель, 423
BUS
Broadcast-and-Unknown Server, 640 сервер трафика с широковещательным и неизвестным адресом, 640
BUS-сервер, 640
BVI
Bridge-Group Virtual Interface, 628 виртуальный интерфейс группы мостов, 628
С
САМ
Content Addressable Memory, 681 ассоциативная память, 681
CAR
Committed Access Rate, 774 согласованная скорость доступа, 774
CAS
Channel Associated Signaling, 500 канал-зависимая сигнализация, 500 сев
Call Control Block, 514
блок управления вызовами, 514
ССО
Cisco Connection Online, 203
Web-узел Cisco, 203
CCP
Compression Control Protocol, 583 протокол управления сжатием, 583 CD
Carrier Detect, 325
обнаружение несущей, 325
CDDI
Copper Distributed Data Interface, 144 распределенный проводной интерфейс передачи данных, 144
CDP
Cisco Discovery Protocol, 38 протокол обнаружения устройств компании Cisco, 38
CDPCP
Cisco Discovery Protocol Control Protocol, 531
протокол управления протоколом обнаружения устройств корпорации Cisco, 531
СЕМ
Configuration Management, 150 управление конфигурацией, 150
CHAP
Challenge Handshake Authentication Protocol, 446
протокол аутентификации с предварительным согласованием вызова, 446
СЮ
Cisco Information Online, 1011 центр оперативной информации
Cisco, 1011
CIP
Channel Interface Processor, 339 процессор канального интерфейса, 339
CLAW
Common Link Access for Workstations, 339
доступ рабочих станций к общему каналу, 339
CLI
Command Language Interpreter, 91
интерпретатор командного языка, 91 CLID
Calling Line Identification, 524 идентификация вызывного канала, 524
CLNP
ConnectionLess Network Protocol, 348
протокол сетевого обслуживания без установления соединения, 348
CLNS
Connectionless Network Service, 40
сетевое обслуживание без установления соединения, 40
СМТ
Connection Management, 149
управление соединениями, 149 CON PACK
CONFigure-ACKnowledge, 529 подтверждение запроса конфигурации, 529
CONFNAK
CONFigure-Negative-ACKnowledge, 529
отрицательное подтверждение запроса конфигурации, 529 CONFREJ
CONFigure-REJect, 529
запрос конфигурации отвергнут, 529 CONP
Connection-Oriented Network Protocol, 348
протокол сетевого обслуживания с установлением соединения, 348
CORBA
Common Object Broker Architecture, 851
общая архитектура брокера объектных запросов, 851
CPCS-PDU
Common Part Convergence Sublayer Protocol Data Unit, 664
протокольная единица обмена подуровня сходимости общей части, 664
СРЕ
Customer Premises Equipment, 471 аппаратура в помещении пользователя, 471
CRB
Concurrent Routing and Bridging, 627 параллельная маршрутизация и мостовое перенаправление, 627
CRC
Cyclic Redundancy Check, 370 циклический избыточный код, 370
CSA
Compression Service Adapter, 409 адаптер службы сжатия данных, 409
CSM
Call Switching Module, 553
модуль коммутации вызовов, 553 CSMA/CD
Carrier Sense Multiple Access with Collision Detection, 119 множественный доступ с контролем несущей и обнаружением коллизий, 119
CSR
Call Success Rate, 498
доля успешных попыток вызова, 498 CSU
Channel Service Unit, 430
модуль обслуживания канала, 430 CSU/DSU
Channel Service Unit/Data Service Unit, 429
адаптер цифрового канала, 429
CT3IP
Channelized ТЗ Interface Processor, 460 многоканальный интерфейсный процессор ТЗ, 460
CTS
Clear То Send, 433 готовность к приему, 433
си
Currently Unused, 175
не используемый в настоящее время, 175
CWSI
CiscoWorks for Switched Internetworks, 804
CiscoWorks для коммутируемых объединенных сетей, 804
D
DARPA
Defense Advanced Research Projects Agency, 413
Агентство перспективных исследовательских программ, 413
DAS
Double Attachment Station, 149
Dual-Attachment Station, 139 станция с двойным подключением, 139; 149
DCD
Data and Carrier Detect, 464 сигнал обнаружения данных и несущей, 464
DCE
Data Circuit-terminating Equipment, 46 терминальное оборудование канала передачи данных, 46
DDCMP
Digital Data Communications Message Protocol, 300 протокол передачи информационных сообщений Digital, 300
DDP
Datagram Delivery Protocol, 256
протокол доставки дейтаграмм, 256 DDR
Dial-on-Demand Routing, 514 маршрутизация с набором номера по требованию, 514
DE
Discard Eligibility, 593
разрешение на уничтожение, 593 DIL
Digital Impairment Learning, 554 диагностика искажений, обусловленных применением цифровых технологий, 554
D1SL
Dynamic ISL, 709
динамическое формирование межкоммутаторного канала, 709
DLCI
Data-Link Connection Identifier, 216 идентификатор подключения канального уровня, 216
DLSw
Data-Link Switching, 299
канальная коммутация, 299
DNA
Digital Network Architecture, 347
цифровая сетевая структура, 347 DNIC
Data Network Identification Code, 609 идентификационный код сетевых данных, 609
DNS
Domain Name System, 182
система доменных имен, 182
DSACK
Dynamic Service Acknowledgement, 990; 991
динамическое подтверждение обслуживания, 990; 991
DSAP
Destination Service Access Point, 127 точка доступа к службе получателя, 127
DSCP
Differentiated Services Code Point, 175
точка кодирования дифференцированных служб, 175
DSP
Digital Signal Processor (цифровой процессор сигналов), 502
Domain-Specific Part (уточняющая часть идентификатора домена), 374
DSR
Data-Set Ready, 433
готовность устройства, 433
DSU
Data Service Unit, 430
модуль обработки данных, 430
DTE
Data Terminal Equipment, 46 терминальное оборудование, 46
DTP
Dynamic Trunking Protocol, 704 протокол динамического формирования магистральных каналов, 704
DTR
Data Terminal Ready, 325
готовность терминала к передаче данных, 325
Е
ЕВС
Ethernet Bundling Controller, 718
контроллер формирования логических каналов Ethernet, 718
ЕСМ
Entity Coordination Management, 150
управление координацией объектов, 150
EIGRP
Enhanced Interior Gateway Routing Protocol, 211
расширенный протокол маршрутизации внутреннего шлюза, 211
ELAP
EtherTalk Link Access Protocol, 252 протокол канального доступа в сети EtherTalk, 252
ЕР
Error Protocol, 416
протокол обработки ошибок, 416 ES
End System, 374
оконечная система, 374
ESF
Extended Superframe Format, 449 расширенный формат суперфрейма, 449
ES-IS
End System-to-Intermediate System, 373
протокол передачи маршрутной информации от оконечной системы к промежуточной системе, 373
EVL
Event Logging Facility, 356
средство регистрации событий, 356
F
FCC
Federal Communications Commission, 144
Федеральная комиссия по связи, 144
FCS
Frame Check Sequence, 126 контрольная последовательность фрейма, 126
FDDI
Fiber Distributed Data Interface, 53 распределенный интерфейс передачи данных по волоконнооптическим каналам, 53
FECN
Forward Explicit Congestion Notification, 592
прямое явное уведомление о заторе, 592
FELR
Far-End Loop Remote, 465
применение команды loop remote на дальнем конце, 465
FEP
Front-End Processor, 331
коммуникационный процессор, 331 FIA
switch Fabric Interface ASIC, 954 специализированная микросхема интерфейса коммутационной структуры, 954
FIP
FDDI Interface Processor, 149 интерфейсный процессор FDDI, 149
FLAP
FDDITalk Link Access Protocol, 252
протокол канального доступа в сети FDDITalk, 252
FPGA
Field Programmable Gate Array, 957 вентильная матрица с эксплуатационным программированием, 957
FS1P
Fast Serial Interface Processor, 442 быстродействующий процессор последовательного интерфейса, 442
FST
Fast Sequenced Transport, 312
скоростная упорядоченная передача, 312
FTP
File Transfer Protocol, 943 протокол передачи файлов, 943
G
GOSIP
Government Open Systems
Interconnection Profile, 373 поддерживаемые государством спецификации для протоколов OSI, 373
н
HDLC
High-level Data Link Control, 217 высокоуровневый протокол управления каналом, 217
HLS
Halt Line State, 150 состояние остановленного канала, 150
НММ
Hex MICA Module, 502 модуль, состоящий из шести модемов MICA, 502
HSRP
Hot Standby Router Protocol, 173; 646 протокол резервного маршрутизатора, 173; 646
HSS1
High-Speed Serial Interface, 53 высокоскоростной последовательный интерфейс, 53
HTTP
Hypertext Transfer Protocol, 198 протокол передачи гипертекста, 198
I
ICMP
Internet Control Messages Protocol, 40 протокол управляющих сообщений
Internet, 40
ICP
Internet Control Protocol, 398 межсетевой управляющий протокол, 398
IDN
International Data Number, 608 международный номер данных, 608
IDP
Initial Domain Part (начальная часть идентификатора домена), 374
Internet Datagram Protocol (межсетевой дейтаграммный протокол), 413
IEEE
Institute of Electrical and Electronic Engineers, 300
Институт инженеров по электротехнике и электронике, 300
IETF
Internet Engineering Task Force, 409
Проблемная группа проектирования Internet, 409
IGRP
Interior Gateway Routing Protocol, 374
протокол маршрутизации внутреннего шлюза, 374 IIS
Internet Information Server, 829 информационный сервер Internet, 829
ILMI
Interim Local Management Interface, 643
промежуточный интерфейс локального управления, 643 ILS
Idle Line State, 150
состояние простаивающего канала, 150
IMAP
Internet Message Access Protocol, 182 протокол доступа к сообщениям в
сети Internet, 182
Inverse ARP
Inverse Address Resolution Protocol, 602
протокол обратного преобразования адресов, 602
IOCP
Input/Output Control Program, 341 программа управления вводом- выводом, 341
IOS
Internetwork Operating System, 39
операционная система для объединенных сетей, 39
IP
Internet Protocol, 174
межсетевой протокол, 174
IPCP
IP Control Protocol, 531
протокол управления межсетевым протоколом, 531
1РМ
Internetwork Performance Monitor, 43
монитор производительности объединенной сети, 43 IPX
Internetwork Packet Exchange, 207; 413
межсетевой пакетный обмен, 207;
413 IPXOD1
Internetwork Packet Exchange Open Data-link Interface, 209 открытый канальный интерфейс протокола межсетевого пакетного обмена, 209
IRB
Integrated Routing and Bridging, 628 совместная маршрутизация и мостовое перенаправление, 628 IS
Intermediate System, 374 промежуточная система, 374 ISDN
Integrated Services Digital Network, 210
цифровая сеть с комплексным обслуживанием, 210
1S-IS
Intermediate System-to-Intermediate System, 373
протокол обмена маршрутной информацией между промежуточными системами, 373
ISL
Inter-Switch Link, 683
межкоммутаторный канал, 683
ISO
International Organization for Standardization, 137; 300
Международная организация по стандартизации, 137; 300
ISP
Internet Service Provider, 31
провайдер служб Internet, 31 ITU
International Telecommunications Union, 605
Международный телекоммуникационный союз, 605
ITU-T
International Telecommunication
Union Telecommunication
Standardization Sector, 300 сектор стандартизации
Международного телекоммуникационного союза, 300
L
L3
Layer 3 ASIC, 954
специализированная микросхема уровня 3, 954
LACK
Local Acknowledgment, 335
локальное подтверждение, 335
LANE
LAN Emulation, 639
эмуляция локальной сети, 639
LAP
Link Access Procedure, 300
процедура доступа к каналу, 300
LAP В
Link Access Procedure, Balanced, 300 сбалансированная процедура доступа к каналу, 300
LAPD
Link Access Procedure on the D channel, 508
процедура доступа к D-каналу, 508
LAST
Local-Area Systems Technology, 352
технология локальных систем, 352
LAT
Local-Area Transport, 352
локальная передача, 352
LAVC
Local-Area VAX Cluster, 352
локальный кластер VAX, 352
LBO
Line Build Out, 451
оценка длины канала, 451
LCP
Link Control Protocol, 528
протокол управления каналом, 528
LEARP
LAN Emulation Address Resolution
Protocol, 640
протокол преобразования адресов в эмулированной LAN, 640
LEC
LAN Emulation Client, 640
клиент LAN Emulation, 640
LEGS
LAN Emulation Configuration Server, 641
конфигурационный сервер эмулированной локальной сети, 641
LECS-сервер, 641
LEC-клиент, 640
LES
LAN Emulation Server, 640
сервер LAN Emulation, 640
LES-сервер, 640 LIPX
Large Internetwork Packet Exchange, 214
межсетевой обмен крупными пакетами, 214
LLAP
LocalTalk Link Access Protocol, 252 протокол канального доступа в
сети LocalTalk, 252 LLC
Logical Link Control, 127
подуровень управления логическим соединением, 127
LMI
Local Management Interface, 217 интерфейс локального управления, 217
LNM
LAN Network Manager, 314
диспетчер локальной сети, 314 LOF
Loss Of Frame, 468
потеря фрейма, 468
LSAP
Link Services Access Point, 631 точка доступа к канальным службам, 631
LSP
Link State Packet, 381
пакет с информацией о состоянии канала, 381
LSU
Line State Unknown, 149
состояние канала неизвестно, 149 LU
Logical Unit, 209
логический модуль, 209
м
МАС
Media Access Control, 45; 138
управление доступом к передающей среде, 45; 138
МАС-устройство, 151 MAU
Media Attachment Unit, 124
устройство подключения к передающей среде, 124 MBS
Maximum Burst Size, 668
максимальный размер всплеска, 668 MBUS
Maintenance BUS, 954
шина обслуживания, 954
MHS
Message Handling Service, 210 система управления сообщениями, 210
MIB
Management Information Base, 43 информационная база управления, 43
MICA
Modem ISDN Channel Aggregation, 501
объединение модема с каналом ISDN, 501
MIPS
Multichannel Interface Processor, 953 многоканальный интерфейсный процессор, 953
MLP
Multilink Point-to-Point Protocol, 532
MultiLink PPP, 537
многоканальный протокол PPP, 537 многоканальный протокол
соединения "точка-точка", 532 MLS
Master Line State, 150
состояние ведущего канала, 150 MLSP
MultiLayer Switching Protocol, 684
протокол многоуровневой коммутации, 684
MMP
Multichassis multilink PPP, 534 многоблочный многоканальный протокол PPP, 534
MOP
Maintenance Operation Protocol, 52
протокол обслуживания, 52
MSAU
MultiStation Access Unit, 157
многостанционный модуль доступа, 157
MSFC
Multilayer Switch Feature Card, 90;
767
плата поддержки многоуровневой коммутации, 90; 767
MTU
Maximum Transmission Unit, 183;
324
максимальная единица передачи
данных в сети, 183; 324
N
NAS
Network Access Server, 581
сервер доступа к сети, 581
NAT
Network Address Translation, 198
трансляция сетевых адресов, 198
NBP
Name Binding Protocol, 257
протокол привязки имен, 257
NCP
NetWare Core Protocol (базовый протокол NetWare), 205
Network Control Protocol (протокол управления сетью), 528; 582
NELR
Near-End Loop Remote, 465 применение команды loop remote на ближнем конце, 465
NET
Network Entity Title, 374
заголовок сетевого объекта, 374
NetBIOS
Network Basic Input/Output System, 210
сетевая базовая система ввода- вывода, 210
NFFC
NetFlow Feature Card, 768
плата поддержки средства NetFlow, 768
NFS
Network File System, 182
сетевая файловая система, 182
NIM
Network Interface Module, 327
сетевой интерфейсный модуль, 327 NLM
NetWare Loadable Module, 210 загружаемый модуль системы
NetWare, 210
NLP
Normal Link Pulse, 123 нормальный канальный импульс, 123
NLS
Noise Line State, 150
состояние зашумленного канала, 150
NLSP
NetWare Link Services Protocol, 207
протокол коммуникационных услуг в среде NetWare, 207
NPM
Network Processor Module, 63
сетевой процессорный модуль, 63
NRZ
Non-Return to Zero, 327
метод кодирования информации без возврата к нулю, 327
NRZI
Non-Return to Zero, Inverted, 327 метод кодирования информации без возврата к нулю, с инверсией, 327
NSAP
Network Service Access Point, 368
точка доступа к сетевой службе, 368
NSP
Network Services Protocol, 352 протокол сетевых служб, 352
NT1
network termination type 1, 505 сетевое оконечное устройство типа
505
NT2
network termination type 2, 505 сетевое оконечное устройство типа
505
NTN
National Terminal Number, 609 региональный номер оконечного устройства, 609
о
ОАМ
Operation, Administration, Maintenance, 672
эксплуатация, администрирование, обслуживание, 672
ОРСОМ
OPerator Communication Manager, 353
диспетчер операторской связи, 353 OSI
Open System Interconnection, 137 взаимодействие открытых систем, 137
OSPF
Open Shortest Path First, 415
открытый протокол SPF, 415
GUI
Organizational Unique Identifier, 322 уникальный идентификатор организации, 322
OVUF
Elasticity Buffer Overflow/U nderilow, 150
переполнение/ опустошение эластичного буфера, 150
Р
P/F
Poll Final, 301
конец опроса, 301
PAD
Packet Assembler/Disassembler, 606 сборщик/разборщик пакетов, 606
PAgP
Port Aggregation Protocol, 704 протокол агрегирования портов, 704
PAP
Password Authentication Protocol (протокол аутентификации по паролю), 446
Printer Access Protocol (протокол доступа к принтеру), 261
РАТ
Port Address Translation, 913 трансляция адресов портов, 913
РСМ
Physical Connection Management, 150
управление физическим соединением, 150 PCR
Peak Cell Rate, 668
пиковая скорость передачи ячеек, 668
РОС
Primary Domain Controller, 812
первичный контроллер домена, 812 PDN
Public Data Network, 605
открытая сеть передачи данных, 605 РЕР
Packet Exchange Protocol, 416
протокол пакетного обмена, 416 PFC
Policy Feature Card, 772
плата поддержки правил, 772
PLIM
Physical Layer Interface Module, 954
модуль интерфейса физического уровня, 954
PLP
Packet-Level Protocol, 348
протокол пакетного уровня, 348 PMD
Physical layer MeDium, 138
среда передающая физического уровня, 138
POP
Post Office Protocol, 182
почтовый протокол, 182
PPP
Point-to-Point Protocol, 207
протокол соединения "точка-точка”, 207
PRI
Primary Rate Interface, 507
интерфейс основного уровня, 507 PSN
Packet Switched Network, 210
сеть с коммутацией пакетов, 210 PSTN
Public Switched Telephone Network, 548
открытая коммутируемая телефонная сеть, 548
PVC
Permanent Virtual Circuit, 308
постоянный виртуальный канал, 308
Q
QLS
Quiet Line State, 150
состояние неактивного канала, 150 QoS
Quality of Service, 175
качество обслуживания, 175
R
RAI
Remote Alarm Indication, 469 дистанционная индикация аварийного сигнала, 469 RARP
Reverse Address Resolution Protocol, 178
протокол обратного преобразования адресов, 178
RCP
Remote Copy Protocol, 52 протокол дистанционного копирования, 52
RFC
Requests For Comment, 174
запрос на комментарии, 174
RIF
Routing Information Field, 167; 308 поле маршрутной информации, 167; 308
RIP
Routing Information Protocol, 205 протокол маршрутной информации, 205
RP
Route Processor, 91; 929
процессор маршрутизации, 91; 929 RPC
Remote Procedure Call, 182
дистанционный вызов удаленных процедур, 182
RPS
Ring Parameter Server, 164
сервер параметров кольца, 164 RSFC
Route-Switch Feature Card, 767 плата поддержки средств маршрутизации в коммутаторе, 767
RSM
Route Switch Module, 629
модуль коммутатора маршрутов, 629 RSP
Route Switch Processor, 55 процессор
маршрутизации/коммутации, 55 RSRB
Remote Source-Route Bridging, 311 дистанционное мостовое перенаправление от отправителя, 311
RTMP
Routing Table Maintenance Protocol, 257
протокол сопровождения таблиц маршрутизации, 257
RTP
Routing Table Protocol, 398 протокол таблиц маршрутизации, 398
RTR
Response Time Reporter, 43 генератор отчетов о времени отклика, 43
RTS
Request То Send, 325
запрос на передачу, 325
RTT'
Round-Trip Time, 183
время кругового обращения, 183
S
SABM
Set Asynchronous Balanced Mode, 611
установление асинхронного уравновешенного режима, 611
SAID
Security Association ID, 864 идентификатор в системе защиты, 864
SAP
Service Advertising Protocol, 205 протокол анонсирования служб, 205
SAPI
Service Access Point Identifier, 509 идентификатор точки доступа к службе, 509
SARP
Sequenced Address Resolution Protocol, 406
протокол упорядоченного преобразования адресов, 406
SAS
Single Attachment Station, 139
станция с одинарным подключением, 139
SCR
Sustainable Cell Rate, 668 стабильная скорость передачи ячеек, 668
SCT
Serial Clock Transmit, 327 передача синхроимпульсов в последовательном канале, 327
SCTE
Serial Clock Transmit External, 327 передача синхроимпульсов в последовательном канале от внешнего устройства, 327
SDLC
Synchronous Data Link Control, 299 синхронное управление передачей данных, 299
SDLLC
SDLC Logical Link Control, 330 управление логическим каналом
SDLC, 330
SF
Superframe Format, 449
формат суперфрейма, 449
SGBP
Stack Group Bidding Protocol, 537протокол определения владельцавызова в группе стека, 537
SIMM
Single In-Line Memory Module, 65 модуль памяти с однорядным расположением выводов, 65
SLARP
Serial Line Address Resolution Protocol, 53
протокол преобразования адресов последовательного канала, 53
SMDR
Storage Management Data Requester, 245; 246
программа запроса данных для управления запоминающими устройствами, 245; 246
SMDS
Switched Multimegabit Data Service, 216
коммутируемая мультимегабитовая служба передачи данных, 216
SMT
Station ManagemenT, 150 управление станцией, 150
SMTP
Simple Mail Transfer Protocol, 182 простой протокол электронной почты, 182
SNA
Systems Network Architecture, 43
системная сетевая структура, 43 SNAP
Subnetwork Access Protocol, 208 протокол доступа к подсети, 208
SNMP
Simple Network Management Protocol, 43
простой протокол управления сетью, 43
SNRM
Set Normal Response Mode, 326 настройка режима нормального отклика, 326
SP
Switch Processor, 91
процессор коммутации, 91
SPID
Service Profile Identifier, 512
идентификатор услуги и линии, 512 SPP
Sequenced Packet Protocol, 209 протокол упорядоченной передачи пакетов, 209
SPX
Sequenced Packet Exchange, 208 упорядоченный пакетный обмен, 208
SRB
Source-Route Bridging, 299 мостовое перенаправление от отправителя, 299
SRT
Source-Route Transparent, 302 прозрачное мостовое перенаправление от отправителя, 302
SSAP
Source Service Access Point, 127 точка доступа к службе отправителя, 127
SSRP
Simple Server Redundancy Protocol, 646
простой протокол избыточности серверов, 646
STA
Spanning-Tree Algorithm, 623 алгоритм распределенного связующего дерева, 623 STP
Shielded Twisted Pair (экранированная витая пара), 45
Spanning-Tree Protocol (протокол распределенного связующего дерева), 683
STUN
Serial TUNnel, 335
последовательный туннель, 335 SVC
Switched Virtual Circuit, 590 коммутируемый виртуальный канал, 590
SWC
SWitch Card, 957
плата коммутатора, 957
т
ТА
Terminal Adapter, 504
терминальный адаптер, 504 ТАС
Technical Assistance Center, 93
центр технический поддержки, 93 TACACS
Terminal Access Controller Access Control System, 296 система управления доступом к контроллеру терминального доступа, 296 ТС
Topology Change, 626
изменение топологии, 626 ТСА
Topology Change Acknowledgment, 626
подтверждение изменения топологии, 626
TCN
Topology Change Notification, 764 извещение об изменении топологии, 764
TCP
Transmission Control Protocol, 174 протокол управления передачей, 174
TCP/IP
Transmission Control
Protocol/Internet Protocol, 258 протокол управления передачей/межсетевой протокол, 258
ТЕ1
terminal equipment type 1, 504 терминальное оборудование типа 1, 504
TEI
Terminal Endpoint Identifier, 509 идентификатор терминальной оконечной точки, 509
ТЕТР
Trivial File Transfer Protocol, 52 простейший протокол передачи файлов, 52
TLAP
TokenTalk Link Access Protocol, 252
протокол канального доступа в сети TokenTalk, 252'
TOD
Time Of Day, 957
истинное время, 957
ToS
Type of Service, 175
тип обслуживания, 175
TP4
Transport Protocol 4, 415
транспортный протокол класса 4, 415
TTL
Time-To-Live, 41
срок жизни, 41
и
UA
Unnumbered Acknowledgment, 326;
613
ненумерованное подтверждение, 326; 613
UDLD
Uni-Directional Link Detection, 690 обнаружение однонаправленного канала, 690
UDP
User Datagram Protocol, 53 протокол пользовательских дейтаграмм, 53
UTP
Unshielded Twisted Pair, 45 неэкранированная витая пара, 45
V
VBR
Variable Bit-Rate, 668
переменная битовая скорость, 668
VBR-NRT
Variable Bit Rate Nonreal Time, 667 класс переменной битовой скорости вне режима реального времени, 667
VCD
Virtual Circuit Descriptor, 655 дескриптор виртуального канала, 655
VINES
Virtual Integrated Network Service, 397
виртуальная интегрированная сетевая служба, 397
VIP
VINES Internetwork Protocol, 398 протокол объединенной сети
VINES, 398
VJ
Van Jacobsen header compression, 583 метод сжатия заголовков Якобсена, 583
VMS
Virtual Memory System, 356
система виртуальной памяти, 356
VP
Virtual Path, 647
виртуальный маршрут, 647
приложение Virtual Profiles, 539
VPDN
Virtual Private Dialup Network, 541 виртуальная закрытая сеть коммутируемого доступа, 541
VPI
Virtual Path Identifier, 643 идентификатор виртуального маршрута, 643
VT
Virtual Template, 539
виртуальный шаблон, 539
VTP
Virtual Trunking Protocol, 704 протокол формирования магистральных каналов виртуальных сетей, 704
W
WIC
WAN interface card, 550
плата с интерфейсом распределенной сети, 550
X
XDR
External Data Representation, 182 внешнее представление данных, 182
XID
exchange Identification, 332
идентификация обмена, 332
XNS
Xerox Network Systems, 205
системы сетей Xerox, 205
ХО
eXactly Once, 261
однократная транзакция, 261
Z
ZIP
Zone Information Protocol, 258
протокол информации о зоне, 258 ZIT
Zone Information Table, 258
таблица с информацией о зоне, 258
А
Агент
CORBA, 851
Адаптер
порта дуплексный, 146
порта многомодовый, 146
порта одномодовый, 146
службы сжатия данных, 409
терминальный, 504
цифрового канала, 429
Адрес
DECnet, 350
DLCI, 408; 409
IEEE 802, 415
NET, 376
NSAP, 373; 375; 376
VINES, 398
X.121, 373
виртуальный HSRP, 192
глобального типа, 415
групповой, 126
группы интерфейса, 167
зоны, 375
направленного типа, 415
одиночный, 126
прошитый, 647
широковещательный, 126
Адресация
глобальная, 591; 594
множественная, 382
Алгоритм
DEC распределенного связующего дерева, 636
IEEE распределенного связующего дерева, 636
STA, 625
автоматического согласования, 123
мостового перенаправления от отправителя, 303
передачи кадра, 160 прозрачного мостового перенаправления, 622; 681
распределенного связующего дерева, 623
Анализатор
сетевой, 45
трафика, 671
Аппаратура
в помещении пользователя, 471
Аутентификатор, 530
Аутентификация
TACACS, 831
Б
База
информационная управления, 43
Байт
управления доступом, 161
Бит
индикатора маршрутной информации, 305
маркера, 161
монитора, 161
Блок
управления вызовами, 514
Бокс
коммутационный, 44
Брандмауэр, 184
PIX, 906
Буфер
аппаратный, 453
системный, 453
В
Вентилятор
корпуса внутренний, 59
Версия
DECnet Phase V, 347
DECnet/OSI, 347
IPv4, 174
IPv6, 174
Взаимодействие
открытых систем, 137
Вольтомметр, 44
Восстановление
пароля коммутатора, 890
пароля маршрутизатора, 890
Время
кругового обращения, 183
Вызов
асинхронного модема, 550
дистанционный удаленных
процедур, 182; 206
Выравнивание, 144
Г
Генератор
отчетов о времени отклика, 43
тестовых последовательностей, 44
Группа
локальная рабочая, 251
многоадресатная, 415
портов, 718
стека, 535
чередующаяся, 490; 493
д
Дамп
ядра, 807
Демон
smid, 895
Диаметр
сети, 120
Диапазон
кабельный, 269; 277
Дисперсия
мод, 138
Диспетчер
локальной сети, 314
Домен, 374
коллизий, 120
широковещательный, 681
Доступ
множественный с контролем несущей и обнаружением коллизий, 119
Е
Единица
максимальная передачи данных в сети, 183; 324
3
Заголовок
сетевого объекта, 374
Загрузка
начальная маршрутизатора, 53
начальная маршрутизатора по сети, 53
Запрос
на комментарии, 174
настройки конфигурации
входящий, 578
определения конфигурации исходящий, 578; 583
Запросчик, 530
Зона, 374
разъединенная, 360
И
Идентификатор
AN1, 524
CLID, 524
SAID, 866
виртуального маршрута, 643
организации уникальный, 322
подключения канального уровня, 216
терминальной оконечной точки, 509
точки доступа к службе, 509
Извещение
TCN, 763
Имитация
состояния up/up, 519
Импульс
канальный быстрый, 123
канальный нормальный, 123
Индикатор
ненумерованный
информационный, 593
световой, 193
Инкапсуляция, 208
ЗСот, 415
Ethernet I, 271
Ethernet SNAP, 271
Ethernet версии 2.0, 415
Frame Relay, 373
FST, 312
HDLC, 373; 459
LAPB, 373
PPP, 373
SMDS, 373
SNAP, 415
TCP, 312
Ungermann-Bass, 415
X.25, 373
Интерпретатор
вывода Output Interpreter, 654
командного языка, 91
Интерфейс
базовой скорости передачи, 65
виртуального доступа, 541
виртуального шаблона, 541
высокоскоростной
последовательный, 53
группы мостов виртуальный, 628
локального управления, 217 локального управления
промежуточный, 643
номеронабирателя, 527
основного уровня, 507
открытый канальный протокола межсетевого пакетного обмена, 209
подключаемого устройства, 124 пользовательский Macintosh, 251 распределенный передачи данных
по волоконно-оптическим каналам, 53
распределенный проводной
передачи данных, 144
сетевой, 65
физический, 527
к
Кабель
волоконно-оптический многомодовый, 138
волоконно-оптический одномодовый, 138
обратный, 552
ответвительный, 159
прямой, 552
с обратным подключением выводов, 552
с перекрестным подключением выводов, 552
с прямым подключением выводов, 552
системный, 63; 65
соединительный, 159
трансивера, 124
Канал
активный, 143
асинхронный, 493
виртуальный, 590; 607
виртуальный коммутируемый, 590
виртуальный многоадресатного перенаправления, 652; 655
виртуальный многоадресатной передачи, 652; 655
виртуальный непосредственный конфигурационный, 655
виртуальный непосредственный управляющий, 650; 655
виртуальный распределенный управляющий, 651; 655
логический, 534
межкоммутаторный, 683
пассивный, 143
постоянный виртуальный, 308; 590
трассировки Trace Channel, 909
физический, 534
Карта
маршрута, 390
Качество
обслуживания, 175
Класс
сети, 176
Клиент, 252
службы преобразования адресов, 403
Код
сетевых данных идентификационный, 609
циклический избыточный, 370
Кодирование, 144
AMI, 449
B8ZS, 449
с чередованием полярности элементов, 449
Коллизия запоздалая, 128
Кольцо
вторичное, 139
первичное, 139
Команда
backup interface, 520
cat /etc/resolv.conf, 202
clear interface, 163
debug, 37; 852
debug apple error, 263
debug apple events, 279
debug lane client all, 645
modem autoconfigure discovery, 490
ping, 37; 40
show, 37
show apple private, 275; 280
show appletalk globals, 269; 284
show appletalk interfaces, 268; 272;
281; 284
show appletalk traffic, 275; 280
show biga, 790
show buffers, 38; 453; 455
show cdp neighbors, 38
show controllers, 38; 442
show debugging, 38
show environment, 58; 61
show environment table, 58; 61
show executor characteristics, 354
show flash, 38
show inband, 790
show interfaces, 38
show interfaces ethernet, 127; 128
show interfaces fddi, 145
show interfaces serial, 427
show interfaces token, 162 show interfaces tokenring, 165 show known circuit characteristics, 354
show lane client, 641
show line, 561; 563
show memory summary, 38
show modem, 498
show modem connect, 500
show process cpu, 38
show processes cpu, 790
show protocol route, 308; 313
show running-config, 38
show stacks, 38
show startup-config, 38
show version, 38
tell, 355
test appletalk, 264
trace, 37; 852
transport input telnet, 490
корректировки скорости порта, 557
перехода в режим буферизации, 557
привязки номеронабирателя, 523 Комитет
по стандартам ANSI ХЗТ9.5, 137
Коммутация
быстрая, 188
канальная, 299
многоуровневая, 684
Компания
BBN, 173
Cisco Systems, 589
Digital Equipment Corporation, 589
GN Nettest, 671
HP, 671
Northern Telecom, 589
StrataCom, 589
Компьютер
Macintosh, 251
Конвертер
данных, 436
Контроллер
домена первичный, 812
домена резервный, 812
остановленный администратором, 466; 478
формирования логических каналов Ethernet, 718
Конфигурация
SDLC двухточечная, 300
SDLC многоточечная, 300
SDLC радиально-кольцевая, 301
SDLC циклическая, 300
конкретного пользователя, 538
Концентратор
интеллектуальный, 123
Корпорация
Apple Computer, 251
Digital Equipment Corporation, 119;
347
IBM, 157
Intel, 119
Rockwell, 549
Xerox, 119
M
Маркер, 158 Маркировка фрейма, 683
Маршрут
виртуальный, 647
плавающий статический, 520 статический, 520
Маршрутизатор, 178 активный, 290; 291 внешний, 259 назначенный, 362 пассивный, 238; 291 уровня 1, 351 уровня 2, 351
Маршрутизация
DDR, 568
динамическая, 179
на скорости коммутации, 795 с набором номера по требованию, 514
статическая, 179
Маска
адреса, 178
Метод
DDR традиционный, 514 кодирования информации без возврата к нулю, 327 кодирования информации без возврата к нулю, с инверсией, 327
Механизм
сброса FLUSH, 657
Мода, 138
Модель
решения проблемы поиска неисправностей, 32
семиуровневая эталонная OSI, 174 Модем
цифровой, 548
Модуль
Director, 892
Post Office, 892
Sensor, 892
вентиляторный плоский, 56; 59 доступа многостанционный, 157 загружаемый системы NetWare, 210 коммутатора маршрутов, 629 коммутации вызовов, 553 обработки данных, 430 обслуживания канала, 430
памяти с однорядным расположением выводов, 65
программный AURP, 260 процессорный сетевой, 63 сетевой интерфейсный, 327 сетевой процессорный, 63 Монитор
активный, 160
производительности объединенной сети, 43
сетевой, 44
Мост
корневой, 624
назначенный, 624
не предусмотренный проектом, 419 прозрачный, 621
Мультиметр цифровой, 44
Мультиплексирование статистическое, 590
н
Нагрузка
канала оконечная неуравновешенная, 478
канала оконечная уравновешенная, 478
Назначение
адреса динамическое, 399 Несогласованность
средств синхронизации, 447 Несоответствие
скоростей на низком уровне, 580 Номер
группы мостов, 629
данных международный, 608 оконечного устройства
региональный, 609
порядковый команды, 389 сетевой, 268; 277 справочный вызова, 550 фрейма порядковый, 610
О
Обеспечение
программное FDDITalk, 293 программное pre-FDDITalk, 293 программное VTAM, 334 программное брандмауэра, 890
программное обнаружения вторжения, 890
программное сканирующее, 890
Облако
ATM, 861
Область
действия неисправности, 160 заголовков протокола высокого уровня, 208
Обнаружение коллизий, 121
Обновление
RTMP, 273; 278; 282
SAP инкрементное, 235; 240
SAP полное, 235; 240
Оборудование терминальное, 46 терминальное канала передачи данных, 46
Обслуживание
сетевое без установления соединения, 40
Обход
маршрутизатора, 768
Объект
ARP, 403
сетевой, 374
Ограничение
трафика, 647; 666
Операция
параллельного обнаружения смежного интерфейса, 123
Определение
группы устройств, 858
Определитель протокола, 593
Опция
SelfTest, 806
Организация
ATM Forum, 667
очередей по приоритетам, 435; 456
Отладка
пакетов, 183
Отношение
смежности, 364
Отображение
канала РРР на владельца вызова, 535
Оценка
длины канала, 451
п
Пакет
BPDU, 690
BrRq, 264
Х.25, 608
ZIP, 275; 279
инициализирующий, 769 многоадресатный, 415 одноадресатный, 415 разрешающий, 769
с информацией о состоянии канала, 381
широковещательный, 415
Память
ассоциативная, 681
Пара
AV, 541
Пара витая
неэкранированная, 45; 144
экранированная, 45; 144
Переброска
маршрутов, 393
Передача
скоростная упорядоченная, 312
Перемешивание, 144
трафика, 672
Перенаправление, 682
мостовое дистанционное от отправителя, 311
мостовое от отправителя, 299
мостовое прозрачное от отправителя, 302
Перераспределение
маршрутов, 381; 384; 386; 394
Переход
на другой адрес зоны, 382
Петля
обратной связи локальная, 458
обратной связи удаленная, 459 Плата
двухканальная, 549
поддержки многоуровневой коммутации, 90; 767
поддержки правил, 772
поддержки средств маршрутизации в коммутаторе, 767
поддержки средства NetFlow, 768
с интерфейсом распределенной сети, 550
сетевая ATM, 640
четырехмодемная, 549
Поддержка
плотности единичных импульсов, 448
Подключение
двойное, 143
Подсеть, 177
Подсистема
охлаждения, 56; 59; 63; 65; 66; 68
питания, 56; 59; 63; 65; 66; 68
процессора, 56; 59
процессора и интерфейсов, 66; 68
Подтверждение
LACK, 335
запроса настройки конфигурации
исходящее, 578
конфигурации входящее, 578
локальное, 335
ненумерованное, 326; 613
Подуровень
управления логическим соединением, 127
Поле
RIF, 167
маршрутной информации, 167; 308
Попадание
в кэш, 768
Порт
корневой, 624
назначенный, 624
Поеледовател ьность
DIL, 554
контрольная фрейма, 126
сигнальная, 301
Потеря
фрейма, 468
Поток, 769
Преамбула, 126
Представление
данных внешнее, 182
Префикс, 178
Присваивание
адреса статическое, 399
Провайдер
служб ATM, 662
служб Internet, 31
Проверка
наличия несущей в сети, 121
Программа
Chooser, 264
Cisco Dialout Utility, 493
Cisco FIX Firewall, 890
CiscoSecure Scanner, 890
Cisco View, 42
ifeonfig, 191
ipconfig.exe, 191, .
NCR, 355
NetRanger, 890
NetSonar, 890
telnet, 199
winipcfg.exe, 191
управления вводом-выводом, 341
Производительность
сети ISO CLNS, 377
Протокол
ВООТР, 191
DHCP, 191
Frame Relay, 589
ILMI, 674
LANE, 639
EAT, 320
LE_ARP, 656
NetWare/IP, 209
PAgP, 743
PHY, 138
QSAAL, 674
SMDS, 674
TCP/IP, 258
Telnet, 181
.34, 554
.90, 549
X Window, 182
.25 уровня 3, 348
XNS сетевого уровня, 413
агрегирования портов, 704
анонсирования служб, 205
аутентификации по паролю, 446
аутентификации с предварительным согласованием вызова, 446
высокоуровневый управления каналом, 217
граничного шлюза, 415
динамического формирования магистральных каналов, 704
динамического формирования межкоммутаторного канала, 709
дистанционного копирования, 52
доставки дейтаграмм, 256
доступа к подсети, 208
доступа к принтеру, 261
информации о зоне, 258
канального доступа в сети
EtherTalk, 252
канального доступа в сети FDDITalk, 252
канального доступа в сети LocalTalk, 252
канального доступа в сети TokenTalk, 252
канального уровня, 347
коммуникационных услуг в среде NetWare, 207
маршрутизации AppleTalk на базе обновлений, 257
маршрутизации внутреннего шлюза, 374
маршрутной информации, 205
межсетевого обмена крупными пакетами, 214
межсетевого пакетного обмена, 207;
413
межсетевой, 174
межсетевой дейтаграммный, 413
межсетевой управляющий, 398
многоканальный РРР, 537
многоуровневой коммутации, 684
обнаружения однонаправленного канала, 690
обнаружения устройств компании Cisco, 38
обработки ошибок, 416
обратного преобразования адресов, 178; 602
обслуживания, 52
объединенной сети VINES, 398
открытый SPF, 415
пакетного обмена, 416
пакетного уровня, 348
передачи гипертекста, 181; 198
передачи данных AppleTalk, 261
передачи информационных
сообщений Digital, 300
передачи файлов, 181
пользовательских дейтаграмм, 53
преобразования адресов, 53
преобразования адресов AppleTalk, 254
преобразования адресов последовательного канала, 53
привязки имен, 257
простейший передачи файлов, 52
простой управления сетью, 43
распределенного связующего дерева, 682; 683; 742
расширенный маршрутизации внутреннего шлюза, 211
резервного маршрутизатора, 173; 646
сеансовый AppleTalk, 261
сетевого обслуживания без установления соединения, 348
сетевого обслуживания с установлением соединения, 348
сетевых служб, 352
соединения "точка-точка", 207
сопровождения таблиц маршрутизации, 257
таблиц маршрутизации, 398
транзакций AppleTalk, 257 транспортный класса 4, 415 удаленного доступа AppleTalk, 294 упорядоченного пакетного обмена, 208
упорядоченного преобразования адресов, 406
упорядоченной передачи пакетов, 209
управления каналом, 528
управления логическим каналом SDLC, 330
управления межсетевым протоколом, 531
управления передачей, 174
управления сетью, 528; 582
управления сжатием, 583
управляющих сообщений Internet, 40 уровня 0, 413
файловый AppleTalk, 262
физического уровня, 138
формирования магистральных каналов виртуальных сетей, 704
Профиль
виртуальный, 541
номеронабирателя, 525; 530; 551
Процедура
xmodem, 92
восстановления пароля, 921
доступа к D-каналу, 508
доступа к каналу, 300
сбалансированная доступа к каналу, 300
Процесс
ANI, 851
CWSI Campus, 851
Event Channel, 851
OSAgent, 851
RTPoller, 851
автореконфигурации, 160
аутентификации PPP, 571
серверный, 850
согласования FDX, 148
Процессор
MSEC, 91
VIР2, 409
блока управления, 91 интерфейсный FDD1, 149 канального интерфейса, 339 коммуникационный, 302; 331 коммутации, 91 маршрутизации, 91; 929 маршрутизации/коммутации, 55 многоканальный интерфейсный ТЗ, 460
цифровой сигналов, 502
Пул
номеронабирателя, 527
Путь
MLS сокращенный, 769
Р
Разбиение
зоны,382
Разделитель
начальный, 161
Размер
всплеска максимальный, 668
Разрешение
на возврат материалов, 93
Разъем
с петлей обратной связи, 476
Рассылка
глобальная многоадресатная, 415
глобальная широковещательная, 415
лавинная, 682
многоадресатная, 591; 595; 622
направленная широковещательная, 415
широковещательная, 622
Расширение
LMI, 589
LMI необязательное, 591
LMI общепринятое, 591
Режим
ROMmon, 917
вставки битов, 451
детерминированный, 159
дуплексный, 122
локальной петли обратной связи, 430; 446; 458
обнаружения, 267
обнаружения устройств AppleTalk, 263; 267
полудуплексный, 120
преждевременного освобождения маркера, 158
Рефлектометр динамический, 44 оптический динамический, 44
С
Светодиод индикаторный, 193
Связка, 534
Сеанс
Telnet обратный, 297; 490
Семейство
протоколов DECnet, 347
Сервер, 252 доступа, 297; 490; 548 доступа к сети, 581 конфигураций ведущий, 868 параметров кольца, 164
Сеть
Ethernet, 119
FDDITalk, 252
ISDN, 504
SONET/SDH, 668
Token Ring, 157
TokenTalk, 252
TYMNET, 605 бессерверная, 408 виртуальная локальная, 640; 681 виртуальная локальная
административная, 797 виртуальная локальная исходная, 691 логическая VINES, 398 передачи данных открытая, 605 с коммутацией пакетов, 210 с множественным доступом и
обнаружением коллизий, 159 с эстафетной передачей, 159 цифровая с комплексным обслуживанием, 210
широковещательная, 122
Сжатие
пакетов по алгоритму FRF.9, 409
пакетов по методу Stacker, 409
Сигнализация канал-зависимая, 500
Синхронизация терминала в режиме SCTE, 449
Система
CiscoSecure Intrusion Detection System, 890; 892
DNS, 182
IDS, 892
автоматизированного производства, 159
автономная, 290
ввода-вывода сетевая базовая, 210
виртуальной памяти, 356
доменных имен, 182
оконечная, 351; 374; 661
операционная DOS, 404
операционная UNIX, 191; 404
операционная Windows 2000, 191;
202
операционная Windows 95, 191; 202
операционная Windows 98, 191; 202
операционная Windows NT, 191;
202
операционная для объединенных сетей, 39
приоритетов, 160
промежуточная, 374; 661
сетевая операционная NetWare, 205
сетевая файловая, 182
управления доступом к контроллеру терминального доступа, 296
управления сообщениями, 210
Скорость
доступа согласованная, 774
передачи ячеек пиковая, 668
передачи ячеек стабильная, 668
переменная битовая, 668
Слияние
зон, 382
Служба
BRI ISDN, 506
PRI ISDN, 507
виртуальная интегрированная сетевая, 397
надежная передачи сообщений, 403 ненадежная передачи дейтаграмм, 403■
передачи данных коммутируемая мультимегабитовая, 216
потоковой передачи данных, 404
преобразования адресов, 403
транспортного уровня VINES, 403
удаленного доступа AppleTalk, 262
Событие
Configure direct, 648
Control direct, 648
Control distribute, 648
Data direct, 649
Multicast forward, 648
Multicast send, 648
набора номера, 568
Согласование
параметров протокола NCP, 582
Соглашение
о трафике, 663
Соединение
LMI сквозное, 568
одноранговое, 579
передачи данных по виртуальному каналу непосредственное, 657
управляющее, 199
Создание
сокращенного пути, 768
Сообщение
BPDU, 625
CANCEL, 509
CLEAR REQUESTS, 614
CONNECT, 509
DISCONNECT, 509; 571
INFORMATION, 509
RELEASE, 509
RELEASE_COMP, 571
RESTART, 614
SABM, 614
SABME, 475; 486
SETUP, 509; 550
STATUS, 509
USER, 509
конфигурационное, 625
о состоянии виртуальных каналов, 591
об отклонении запроса конфигурации исходящее, 578;
583
Состояние
MULTI PLE_FRAME_ ESTABLISHED, 474; 484
активного канала, 150
ведущего канала, 150
зашумленного канала, 150
неактивного канала, 150
простаивающего канала, 150
Спецификация
100BaseT4, 124
AppleTalk версии 1, 251
AppleTalk версии 2, 251; 271
Frame Relay, 591; 593
ICP, 403
IEEE 802.Id, 623
IEEE 802.3, 119
IEEE 802.5, 157
сети Ethernet, 119
сети Token Ring корпорации IBM, 157
Список
доступа, 419; 567
Среда
передающая физического уровня, 138
Средство
EtherChannel, 743
PortFast, 743
PortFast BPDU-Guard, 743
маршрутизации OSI, 348
регистрации событий, 356
Срок
жизни, 41
существования информации максимальный, 781; 789
Стандарт
AS5100, 549
Ethernet, 347
FDDI, 137; 347
IEEE 802.2, 347
ISDN, 504
Token Ring, 347
X.25, 347
Станция
DAS, 139
SAS, 139
рабочая, 206; 209
с двойным подключением, 139
с одинарным подключением, 139
Стоимость, 349
корневого пути, 624
пути, 624
Структура
системная сетевая, 43
Схема
кодирования MLT3, 144
Сценарий
диалогового взаимодействия, 570
Счетчик
коллизий, 122
т
Таблица
САМ, 681
маршрутизации, 179
с информацией о зоне, 258
Таймер
активный, 290
Тестер
кабельный, 44
частоты ошибочных битов, 44
частоты ошибочных блоков, 44 Технология
ATM, 639; 661
Тип
обслуживания, 175
Топология звездообразная, 157
Точка
доступа к канальным службам, 631 доступа к сетевой службе, 368 доступа к службе отправителя, 127 доступа к службе получателя, 127 кодирования дифференцированных служб, 175
контрольная ISDN, 505
Точка доступа, 374
Транзакция, 261
многократная, 261 однократная, 261 Трансляция
адресов портов, 913
сетевых адресов, 198
Трафик
внутрисегментный, 622 интересующий, 515; 567 межсегментный, 622
Туннель, 259
STUN без локального подтверждения, 335 блочный последовательный, 423 многоточечный, 259 полностью связанный, 259 последовательный, 335 типа "точка-точка", 259 частично связанный, 259
У
Узел, 158; 254 вторичный, 300 маршрутизирующий, 349; 367 маршрутизирующий DECnet, 351 несервисный, 402 первичный, 300 сервисный, 398
Университет
Стэнфордский, 173
Упорядочение трафика, 666
Управление
доступом к передающей среде, 45;
138
конфигурацией, 150
координацией объектов, 150
потоком данных, 556; 563; 591
потоком данных аппаратное, 557;
561
потоком данных программное, 558
соединениями, 149
станцией, 138; 150
физическим соединением, 150
Уровень
транспортный DNA, 352
Устройство
подключения к передающей среде, 124
пользовательское, 589
Утилита
ping, 183
traceroute, 183
Ф
Фиксация
скорости DTE модема, 580
Фильтрация, 682
Формирование, 541
Фрейм
информационный, 158; 609
ненумерованный, 302; 610
поиска маршрутов, 305
поиска одного маршрута, 305
поиска связующего дерева, 305
поисковый, 303
управляющий, 302; 610
Фреймирование
D4, 449
ESF, 449
X
Характеристика
качества обслуживания, 662
Хост
в связке интерфейса владельца вызова, 535
ц
Центр
технический поддержки, 93
ч
Часть уточняющая идентификатора домена, 374
ш
Шаблон виртуальный, 539
Шлюз, 178 почтовый, 200
э
Экспонометр, 145
Эмуляция локальной сети, 639
Эхо-протокол
AppleTalk, 257
Я
Ячейка, 661
Научно-популярное издание
Cisco Systems и др.
Руководство по поиску неисправностейв объединенных сетях
И. А. ПоповаО. В. ЛинникВ. Г. ПавлютинИ. А. ПоповаО. В. ЛинникВ. Г. ПавлютинЛитературный редактор Верстка Художественный редактор
И. А. Попова
О. В. Линник
В. Г. Павлютин
И. А. Попова
О. В. Линник
В. Г. Павлютин
Издательский дом “Вильямс”.101509, Москва, ул. Лесная, д. 43, стр. 1.Изд. лиц. ЛР № 090230 от 23.06.99Госкомитета РФ по печати.
Подписано в печать 27.12.2002. Формат 70x100/16.
Гарнитура Times. Печать офсетная.
Усл. печ. л. 83,8. Уч.-изд. л. 64,4.
Тираж 3000 экз. Заказ № 2151.
Отпечатано с диапозитивов в ФГУП “Печатный двор”Министерства РФ по делам печати,телерадиовещания и средств массовых коммуникаций.197110, Санкт-Петербург, Чкаловский пр., 15.
Cisco Systems
Руководство по поиску неисправностей в объединенных сетях
Второе издание
Исчерпывающие рекомендации по решению сложных сетевых проблем
www.williamspublishing.com
www.ciscopress m
5 AARP (AppleTalk Address Resolution Protocol — протокол преобразования адресов AppleTalk).
1 Устройство CSU/DSU (Channel Service Unit/Data Service Unit — адаптер цифрового канала) состоит из модуля CSU (модуль обслуживания канала) и DSU (модуль обработки данных).
11 Следует отметить, что в системе Cisco IOS не предусмотрена поддержка средств мостовой маршрутизации в асинхронных интерфейсах.
7 SSRP (Simple Server Redundancy Protocol — простой протокол избыточности серверов).
8 HSRP (Hot Standby Router Protocol — протокол резервного маршрутизатора).
1 Если происходит обращение к этому пространству, выводится кэш L2 для его псевдонима в младших адресах области памяти 8 Гбайт, а соответствующий дескриптор объявляется недействительным.