Коммутаторы : ??????????? Cisco Catalyst ????? 4500

Рекомендации по настройке и управлению для коммутаторов серии Catalyst 4500/4000, 5500/5000 и 6500/6000, работающих под управлением CatOS

23 марта 2008 - Перевод, выполненный профессиональным переводчиком
Другие версии: PDF-версия:pdf | Машинный перевод (28 июля 2013) | Английский (29 ноября 2007) | Отзыв

Содержание

Общие сведения
Предварительные условия
      Требования
      Используемые компоненты
      Условные обозначения
      Базовые сведения
Базовая конфигурация
      Протоколы уровня управления Catalyst
      Протокол транкинга (организации магистральных каналов) в виртуальной локальной сети
      Расширенные виртуальные сети и уменьшение количества MAC-адресов
      Автосогласование
      Gigabit Ethernet
      Динамический протокол транкинга
      Протокол связующего дерева
      EtherChannel
      Обнаружение однонаправленного канала
      Большие кадры
Настройка управления
      Схемы сетей
      Внутриполосное управление
      Управление через выделенное подключение
      Испытания системы
      Обнаружение ошибок системы и аппаратного обеспечения
      Обработка ошибок каналов EtherChannel/физических каналов
      Диагностика буфера пакетов Catalyst 6500/6000
      Регистрация системы
      Протокол SNMP (простой протокол управления сетью)
      Удаленный контроль
      Протокол сетевого времени
      Протокол обнаружения CDP (Cisco Discovery Protocol)
Конфигурация безопасности
      Основные функции безопасности
      Система управления доступом к контроллеру терминального доступа (TACACS)
Контрольный список конфигурации
Связанные обсуждения сообщества поддержки Cisco
Дополнительные сведения

Общие сведения

В данном документе рассмотрено использование в сети коммутаторов Cisco серии Catalyst, а конкретно – платформ Catalyst 4500/4000, 5500/5000 и 6500/6000. Рассматриваемые настройки и команды предполагают использование ПО Catalyst OS (CatOS) General Deployment версии 6.4(3) или более новых версий. Несмотря на наличие некоторых предположений о конфигурации, данный документ не охватывает конфигурацию всей сети.

Предварительные условия

Требования

Данный документ предполагает знакомство со Справочником команд Catalyst серии 6500 версии 7.6.

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

Используемые компоненты

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

Условные обозначения

Дополнительные сведения об условных обозначениях  см. в документе Технические рекомендации Cisco. Условные обозначения.

Базовые сведения

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

  • Решения, которые, согласно статистике, распространены наиболее широко и поэтому подвергаются минимальному риску;

  • Простые решения, в которых некоторая часть гибкости принесена в жертву определенности результатов;

  • Простые в управлении решения, настройку которых может осуществлять группа управления сетью;

  • Решения, обеспечивающие высокую доступность и высокую надежность.

Этот документ состоит из следующих четырех разделов:

  • Базовая конфигурация — используемые в большинстве сетей функции, такие как протокол связующего дерева (STP) и создание магисталей (транкинг);

  • Настройка управления — вопросы проектирования, а также мониторинга системы и событий при помощи протокола SNMP (простой протокол управления сетью), RMON (удаленный мониторинг), системного журнала, CDP (протокол Cisco Discovery) и протокола NTP (протокол сетевого времени);

  • Настройка безопасности — пароли, защита портов, физическая безопасность и аутентификация при помощи TACACS+;

  • Контрольный список конфигурации — сводка предложенных шаблонов конфигурации.

Базовая конфигурация

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

Протоколы уровня управления Catalyst

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

Трафик управляющего модуля Supervisor

Для большинства возможностей, доступных в сети Catalyst, необходимо взаимодействие двух или более коммутаторов, поэтому необходимо организовать управляемый обмен сообщениями проверки активности (keepalive), параметрами конфигураций и управляющими изменениями. Вне зависимости от того, являются протоколы собственностью Cisco (например, CDP) или основываются на стандартах (например, IEEE 802.1d (STP)), у всех них при реализации в серии Catalyst есть общие элементы.

При базовой пересылке кадров, кадры с пользовательскими данными исходят из конечных систем, и адреса их источников и получателей не изменяются в коммутируемых доменах уровня 2. В процессе запоминания адресов источников происходит заполнение таблиц поиска ассоциативного ЗУ (CAM) в Supervisor Engine каждого коммутатора, а таблицы позволяют определять выходные порты, на которые пересылаются получаемые кадры. Если процесс запоминания адресов не завершен (адрес назначения неизвестен или кадр направлен на адрес широковещательной или многоадресной рассылки), они направляются (передаются) на все порты этой виртуальной сети.

Коммутатор также должен распознавать, какие кадры нужно перенаправить через систему, а какие нужно передать непосредственно на ЦП коммутатора (процессор сетевого управления [NMP]).

Уровень управления Catalyst создается при помощи специальных записей в таблице CAM, называемых системными записями, позволяющих принимать и направлять трафик NMP на внутренний порт коммутатора. Трафик уровня управления можно отделить от данных с помощью протоколов с известными MAC-адресами назначения. Чтобы проверить это, введите в коммутаторе команду show CAM system:

>show cam system

* = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.
X = Port Security Entry
VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type]
----  ------------------    -----  -------------------------------------------
1     00-d0-ff-88-cb-ff  #          1/3

!--- Внутренний порт NMP.

1     01-00-0c-cc-cc-cc  #          1/3

!--- CDP и т. д.

1     01-00-0c-cc-cc-cd  #          1/3

!--- Cisco STP.

1     01-80-c2-00-00-00  #          1/3

!--- IEEE STP.

1     01-80-c2-00-00-01  #          1/3

!--- Управление IEEE-потоком.

1     00-03-6b-51-e1-82 R#          15/1

!--- Маршрутизатор многоуровневой коммутации (MSFC).

...

У Cisco есть зарезервированный диапазон MAC-адресов и адресов протоколов Ethernet, приведенных ниже. Описание каждого из них приведено в документе ниже. Для удобства в данной таблице приведена сводная информация.

Функция

Тип протокола SNAP HDLC

MAC-адрес назначения для многоадресной рассылки

Протокол агрегирования портов (PAgP)

0x0104

01-00-0c-cc-cc-cc

Связующее дерево PVSTP+

0x010b

01-00-0c-cc-cc-cd

Мост VLAN

0x010c

01-00-0c-cd-cd-ce

Обнаружение однонаправленного соединения (физического канала) (UDLD)

0x0111

01-00-0c-cc-cc-cc

Протокол Cisco Discovery

0x2000

01-00-0c-cc-cc-cc

Протокол динамического транкинга (DTP)

0x2004

01-00-0c-cc-cc-cc

STP Uplink Fast

0x200a

01-00-0c-cd-cd-cd

Протокол связующего дерева IEEE 802.1d

Отсутствует - DSAP 42 SSAP 42

01-80-c2-00-00-00

Протокол межкоммутаторных соединений (ISL)

Отсутствует

01-00-0c-00-00-00

Протокол транкинга в виртуальных сетях (VTP)

0x2003

01-00-0c-cc-cc-cc

IEEE Pause, 802.3x

Отсутствует - DSAP 81 SSAP 80

01-80-C2-00-00-00>0F

Для большинства управляющих протоколов Cisco используется инкапсуляция SNAP IEEE 802.3, включая LLC 0xAAAA03, OUI 0x00000C, что можно видеть в трассировочных данных сети. К другим общим свойствам этих протоколов относятся:

  • Данные протоколы подразумевают подключение типа "точка-точка". Следует учесть, что обдуманное использование адресов назначения многоадресной рассылки позволяет двум устройствам Catalyst обеспечивать прозрачный обмен информацией через коммутаторы, произведенными другими фирмами (не Cisco), так как устройства, которые не распознают и не перехватывают кадры, просто передают их на все порты. Использование соединений типа "точка-с-несколькими точками" в средах, в которых применяется оборудование различных производителей, может привести к неустойчивому поведению сети, и поэтому их следует избегать;

  • Эти протоколы оканчиваются на маршрутизаторах уровня 3, они работают только в пределах домена коммутатора;

  • Специализированная микросхема (ASIC) обработки и планирования входящего трафика назначает этим протоколам приоритет перед пользовательскими данными.

После описания адресов назначения для протоколов управления, для полноты картины необходимо также описать адреса источников. Протоколы коммутации используют MAC-адрес, полученный из банка доступных адресов в ЭСППЗУ, находящемся в корпусе. Чтобы отобразить диапазоны адресов, которые доступны каждому из модулей, являющихся источниками трафика, такого, как сообщения BPDU протокола STP или кадры протокола ISL, введите команду show module.

>show module

...
Mod MAC-Address(es)                        Hw     Fw         Sw
--- -------------------------------------- ------ ---------- -----------------
1   00-01-c9-da-0c-1e to 00-01-c9-da-0c-1f 2.2    6.1(3)     6.1(1d)
    00-01-c9-da-0c-1c to 00-01-c9-da-0c-1
    00-d0-ff-88-c8-00 to 00-d0-ff-88-cb-ff

!--- MAC для исходящего трафика.

...
VLAN 1

VLAN 1

В сетях Catalyst VLAN 1 играет особую роль.

Для обозначения нескольких протоколов управления при организации магистралей (транкинге), таких как CDP, VTP и PAgP, Catalyst Supervisor Engine всегда использует настроенную по умолчанию виртуальную сеть VLAN 1. Все порты, включая внутренний интерфейс sc0, по умолчанию настроены на участие в VLAN 1. По умолчанию все магистральные каналы входят в VLAN 1, а в версиях ПО CatOS, предшествующих версии 5.4, блокировать передачу пользовательских данных в VLAN 1 было нельзя.

Для разъяснения некоторых терминов, используемых в сетях Catalyst, необходимо привести несколько определений:

  • Управляющая виртуальная сеть – это виртуальная сеть, которой принадлежит внутренний интерфейс sc0, эту виртуальную сеть можно менять;

  • Собственная VLAN определяется как VLAN, к которой порт возвращается в отсутствие магистрали, и в магистрали 802.1Q она является непомеченной.

Вот несколько разумных причин для того, чтобы настроить сеть и изменить поведение портов в сети VLAN 1:

  • Если диаметр VLAN 1, подобно любой другой VLAN, становится настолько большим, чтобы угрожать стабильности (особенно для STP), его нужно уменьшить. Более подробно это описано в разделе Внутриполосное управление данного документа;

  • Чтобы упростить устранение неполадок и увеличить число доступных циклов ЦП, данные уровня управления VLAN 1 следует отделять от пользовательских данных;

  • При проектировании многоуровневых сетей без STP, в которых при наличии нескольких виртуальных сетей и IP-подсетей требуется организация магистралей к уровню доступа, необходимо избегать образования петель уровня 2 в VLAN 1. Для этого вручную удалите магистральные порты из VLAN 1.

В заключение, следует помнить данную информацию о магистральных каналах:

  • Обновления CDP, VTP и PAgP всегда перенаправляются в магистраль с меткой VLAN 1. Это правило не нарушается, даже если VLAN 1 удаляется из магистралей и не является собственной VLAN. Удаление VLAN 1 для пользовательских данных не влияет на трафик уровня управления, который по-прежнему передается при помощи VLAN 1;

  • В магистралях ISL пакеты DTP передаются по VLAN 1. Это правило не нарушается, даже если VLAN 1 удаляется из магистралей и не является собственной VLAN. В магистральном канале 802.1Q пакеты DTP передаются по собственной VLAN. Это правило не нарушается, даже если собственная VLAN удаляется из магистрали;

  • В PVST+ BPDU 802.1Q IEEE в целях совместимости с оборудованием других производителей пересылаются непомеченными по общей VLAN 1 связующего дерева за исключением случаев, когда VLAN 1 удаляется из магистрального канала. Это происходит независимо от конфигурации стандартной VLAN. По всем другим виртуальным сетям BPDU Cisco PVST+ передаются помеченными. Дополнительную информацию см. в разделе Протокол связующего дерева данного документа;

  • BPDU протокола множественных связующих деревьев (MST) 802.1s всегда передаются по VLAN 1 по магистральным каналам ISL и 802.1Q. Это справедливо даже когда VLAN 1 удаляется из магистральных каналов;

  • Не следует удалять или отключать VLAN 1 в магистралях между мостами MST и мостами PVST+. Однако в случаях, когда VLAN 1 отключена, мост MST должен стать корневым для всех виртуальных сетей, чтобы граничные порты моста MST не перешли в несогласованное с корневым состояние. Дополнительные сведения см. в документе Общие сведения о протоколе MSTP (протокол множественных связующих деревьев, 802.1s).

Протокол транкинга (организации магистральных каналов) в виртуальной локальной сети

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

Технологическое описание

VTP – это протокол передачи сообщений на уровне 2, обеспечивающий согласованность конфигурации виртуальной сети. VTP обеспечивает управление добавлением, удалением и переименованием виртуальных сетей на общесетевом уровне. VTP позволяет свести к минимуму ошибки и несогласованность конфигурации, которые могут привести ко многим проблемам, таким как дублирование имен виртуальных сетей, неверным спецификациям типов виртуальных сетей и нарушениям безопасности. База данных виртуальных сетей представляет собой двоичный файл и хранится в энергонезависимом ПЗУ на серверах VTP отдельно от файла конфигурации.

Протокол VTP обеспечивает связь между коммутаторами, используя MAC-адрес назначения многоадресной рассылки Ethernet (01-00-0c-cc-cc-cc) и тип протокола SNAP HDLC Ox2003. Он не работает через немагистральные порты (VTP представляет собой полезные данные ISL или 802.1Q), поэтому до организации магистрального канала при помощи DTP сообщения пересылать невозможно.

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

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

В таблице приведено сводное сравнение функций различных режимов VTP:

Функция

Сервер

Клиент

Прозрачный

Выключено1

Исходные сообщения VTP

Да

Да

Нет

Нет

Прослушивание сообщений VTP

Да

Да

Нет

Нет

Пересылка сообщений VTP

Да

Да

Да

Нет

Создание виртуальных сетей

Да

Нет

Да (только локальное значение)

Да (только локальное значение)

Запоминание виртуальных локальных сетей

Да

Нет

Да (только локальное значение)

Да (только локальное значение)

В режиме transparent(прозрачный) VTP обновления VTP игнорируются (MAC-адрес многоадресной рассылки VTP, который обычно используется для получения управляющих кадров и их перенаправления в supervisor engine, удаляется из системной CAM). Поскольку протокол использует адрес многоадресной рассылки, коммутатор в прозрачном режиме (или коммутатор другого поставщика) просто передаст кадр другим коммутаторам Cisco.

1 В ПО CatOS версии 7.1 добавлена опция отключения VTP при помощи режима off. В режиме VTP off коммутатор работает почти как в режиме VTP transparent, за исключением того, что в режиме off происходит подавление пересылки обновлений VTP.

В таблице приведена сводка исходной конфигурации:

Функция

Значение по умолчанию

Имя домена VTP

Null

Режим VTP

Сервер

Версия VTP

Включена версия 1

Пароль VTP

Отсутствует

Отсечение каналов в протоколе VTP

Отключено

Протокол VTP версии 2 (VTPv2) обеспечивает следующую функциональную гибкость. Однако он не взаимодействует с VTP версии 1 (VTPv1):

  • Поддержка Token Ring;

  • Поддержка нераспознанной информации VTP: теперь коммутаторы передают значения, которые они не могут проанализировать;

  • Прозрачный режим, который зависит от версии; в режиме transparent доменное имя больше не проверяется. Это позволяет поддерживать в прозрачном домене больше одного домена;

  • Распространение номера версии; если протокол VTPv2 поддерживается всеми коммутаторами, его можно включить во всех коммутаторах посредством включения только на одном коммутаторе.

Дополнительную информацию см. в документе Общие сведения и настройка магистрального протокола виртуальной сети (VTP).

Протокол VTP версии 3

В ПО CatOS версии 8.1 добавлена поддержка протокола VTP версии 3 (VTPv3). VTPv3 усовершенствован по сравнению с предыдущими версиями. Эти усовершенствования обеспечивают:

  • Поддержку расширенных виртуальных сетей

  • Поддержку создания и объявления частных виртуальных локальных сетей

  • Поддержку экземпляров виртуальных сетей и экземпляров распространения отображений MST (поддерживаемых в ПО CatOS версии 8.3)

  • Улучшенную аутентификацию серверов

  • Защиту от случайного добавления "неправильной" базы данных в домен VTP

  • Взаимодействие с VTPv1 и VTPv2

  • Возможность настройки для всех портов по отдельности

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

Коммутаторы, на которых работает VTPv3, принимают только базы данных VTP с номером версии конфигурации, превышающим номер версии конфигурации текущего основного сервера. Этот процесс существенно отличается от VTPv1 и VTPv2, в которых коммутатор всегда принимает конфигурацию с превосходящим номером от соседнего коммутатора этого же домена. Изменения в VTPv3 обеспечивают защиту. Новый коммутатор с большим номером версии конфигурации VTP, добавляемый в сеть, не может изменить конфигурацию виртуальной сети всего домена.

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

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

  • При попытке настройки коммутатора в качестве основного сервера выдается запрос пароля. При совпадении введенного пароля с секретным паролем коммутатор становится основным сервером, что позволяет выполнять настройку домена.

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

  • Перезагрузка коммутатора;

  • Резкое изменение доступности между активными и резервными управляющими модулями;

  • Перехват у другого сервера;

  • Изменения в настройках режима;

  • Любое из следующих изменений конфигурации домена VTP:

    • Версия;

    • Имя домена;

    • Пароль домена.

VTPv3 также позволяет коммутаторам участвовать в нескольких экземплярах VTP. В таком случае один коммутатор может быть VTP-сервером для одного экземпляра и клиентом для другого экземпляра, поскольку для различных экземпляров VTP режимы VTP могут различаться. Например, коммутатор может работать в режиме transparent для экземпляра MST, а для экземпляра VLAN коммутатор может быть настроен на работу в режиме server.

Что касается взаимодействия с VTPv1 и VTPv2, по умолчанию во всех версиях VTP предусмотрено, чтобы более старые версии VTP просто отбрасывали обновления новых версий. За исключением случаев, когда коммутаторы, поддерживающие VTPv1 и VTPv2, работают в режиме transparent, все обновления VTPv3 отбрасываются. С другой стороны, когда коммутаторы VTPv3 получают по магистральному каналу кадры предыдущих версий VTPv1 или VTPv2, коммутаторы передают на коммутаторы, работающие в режимах VTPv1 и VTPv2 обновления своих баз данных в старом формате. Однако обмен информацией является односторонним, поскольку коммутаторы VTPv3 не принимают обновления от коммутаторов VTPv1 и VTPv2. На магистральных каналах коммутаторы VTPv3 наряду с обновлениями в формате VTPv3, продолжают рассылать обновления в старом формате, учитывая наличие на магистральных портах соседних коммутаторов VTPv2 и VTPv3.

Чтобы обеспечить поддержку VTPv3 для расширенных VLAN, был изменен формат базы данных VLAN, в которой VTP назначает каждой VLAN 70 байт. Данное изменение предусматривает кодирование только нестандартных значений, вместо хранения неизмененных полей для предыдущих версий протокола. Это изменение позволяет поддерживать базу данных VLAN размером 4 Кб.

Рекомендация

Для использования режимов client/server протокола VTP или режима transparent протокола VTP специальные рекомендации отсутствуют. Несмотря на некоторые факторы, изложенные ниже, некоторые клиенты предпочитают простоту управления режима client/server VTP. В целях резервирования рекомендуется иметь в каждом домене два коммутатора в режиме server, обычно два коммутатора уровня распределения. Остальные коммутаторы в домене должны находиться в режиме client. При реализации режима client/server при помощи VTPv2 следует помнить, что в одном домене VTP конфигурация с большим номером версии принимается всегда. Если коммутатор, настроенный в режиме client или server VTP, добавляется в домен VTP и у него больший номер версии конфигурации, чем у имеющихся VTP-серверов, он переписывает базу данных VLAN в домене VTP. Если конфигурация изменяется непреднамеренно и при этом происходит удаление виртуальных сетей, такое переписывание может привести к серьезному сбою в работе сети. Чтобы номер версии конфигурации коммутатора в режиме client или server всегда был меньше, чем у сервера, измените имя домена клиента VTP на любое, отличное от стандартного. После измените имя на стандартное. Это действие установит номер версии конфигурации в значение 0.

У возможностей VTP по простому внесению изменений в сети есть "за" и "против". Поэтому на многих предприятиях предпочтение отдается предусмотрительному использованию режима transparent VTP:

  • Он предполагает надлежащие правила управления изменениями, поскольку изменения VLAN на коммутаторе или магистральном порте могут одновременно вноситься только на одном коммутаторе;

  • Это ограничивает риск ошибок администратора, влияющих на весь домен, таких как случайное удаление VLAN;

  • Можно безо всякого риска добавлять в сеть новые коммутаторы с большими номерами версий VTP, не изменяя конфигурацию VLAN всего домена;

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

  • Расширенный диапазон VLAN в CatOS 6.x и CatOS 7.x с номерами от 1025 до 4094 можно настроить только таким способом. Дополнительную информацию см. в разделе Расширенные VLAN и уменьшение количества MAC-адресов данного документа;

  • В программе Campus Manager 3.1 из пакета Cisco Works 2000 поддерживается режим transparent VTP. Старое ограничение, требовавшее наличия в домене VTP хотя бы одного сервера, было снято.

Примеры команд VTP

Комментарии

set vtp domain name password x

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

set vtp mode transparent

 

set vlan vlan number name name

Для каждого коммутатора, имеющего порты в VLAN.

set trunk mod/port vlan range

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

clear trunk mod/port vlan range

Ограничивает диаметр STP посредством ручного отсечения VLAN, где она не существует, например в магистральных каналах от уровня распределения до уровня доступа.

Примечание. Указание VLAN с помощью команды set только добавляет VLAN и не удаляет их. Например, команда set trunk x/y 1-10 не ограничивает список разрешенными виртуальными сетями 1-10. Чтобы достичь нужного результата, необходимо ввести команду clear trunk x/y 11-1005.

Несмотря на то, что коммутация token ring выходится за рамки данного документа, следует помнить о том, что режим transparent VTP не рекомендуется использовать в сетях TR-ISL. В основе коммутации token ring лежит то, что весь домен образует единый распределенный многопортовый мост, поэтому у всех коммутаторов должна быть одинаковая информация о виртуальных сетях.

Другие параметры

В средах token ring, для которых крайне рекомендуется использование режимов client/server, использование VTPv2 является обязательным.

VTPv3 обеспечивает возможность реализации более строгой аутентификации и управления версиями конфигураций. Наряду с улучшенной безопасностью VTPv3 в целом обеспечивает тот же уровень возможностей, как у режима transparent VTPv1/VTPv2. Кроме того, VTPv3 частично совместим с более старыми версиями VTP.

В данном документе отстаиваются преимущества отсечения VLAN, которые заключаются в сокращении распространения ненужных кадров. Команда set vtp pruning enable автоматически отсекает VLAN и прекращает неэффективную передачу кадров туда, где они не нужны. В отличие от процедуры ручного отсечения каналов VLAN автоматическое отсечение не ограничивает диаметр связующего дерева.

Начиная с CatOS 5.1, коммутаторы Catalyst могут отображать номера виртуальных сетей 802.1Q, превышающие 1000, в номера виртуальных сетей ISL. В CatOS 6.x коммутаторов Catalyst 6500/6000 в соответствии со стандартом IEEE 802.1Q поддерживается 4096 виртуальных локальных сетей. Эти виртуальные сети организованы в следующие три диапазона, и только несколько из них распространяются на другие коммутаторы сети при помощи VTP:

  • виртуальные сети из стандартного диапазона: 1–1001;

  • виртуальные сети из расширенного диапазона: 1025–4094 (могут распространяться только посредством VTPv3);

  • виртуальные сети из зарезервированного диапазона: 0, 1002—1024, 4095.

Для получения результатов, аналогичных результатам использования протокола VTP, IEEE была создана стандартизированная архитектура. Как часть протокола регистрации типовых атрибутов (GARP) 802.1Q, протокол регистрации типовых виртуальных сетей (GVRP) обеспечивает совместимость управления виртуальными сетями в оборудовании различных производителей, однако выходит за рамки настоящего документа.

Примечание. В CatOS 7.x добавлена возможность включения VTP в режиме off, очень похожего на режим transparent. При этом коммутатор не пересылает кадры VTP. Это может пригодиться при конфигурациях, когда вы не осуществляете управление организацией магистральных каналов к коммутаторам.

Расширенные виртуальные сети и уменьшение количества MAC-адресов

Функция уменьшения количества MAC-адресов обеспечивает идентификацию виртуальных сетей из расширенного диапазона. Включение уменьшения количества MAC-адресов отключает пул MAC-адресов, используемых для связующего дерева виртуальных сетей и оставляет один MAC-адрес. Этот MAC-адрес служит для идентификации коммутатора. В ПО CatOS версии 6.1(1) добавлена поддержка уменьшения количества MAC-адресов для коммутаторов Catalyst 6500/6000 и Catalyst 4500/4000, что позволяет поддерживать 4096 виртуальных сетей в соответствии со стандартом IEEE 802.1Q.

Технологическое описание

Протоколы коммутаторов используют MAC-адреса из банка доступных адресов, предоставляемых ЭСППЗУ шасси в качестве части идентификаторов моста для виртуальных сетей, работающих в режиме PVST+. Коммутаторы Catalyst 6500/6000 и Catalyst 4500/4000 поддерживают 1024 или 64 MAC-адреса, количество которых зависит от типа шасси.

По умолчанию коммутаторы Catalyst с 1024 MAC-адресами не включают уменьшение количества MAC-адресов. MAC-адреса выделяются последовательно. Первый MAC-адрес диапазона назначается VLAN 1. Второй MAC-адрес диапазона назначается VLAN 2 и так далее. Это позволяет коммутаторам поддерживать 1024 VLAN, при этом для каждой виртуальной сети используется уникальный идентификатор моста.

Тип шасси

Количество адресов шасси

WS-C4003-S1, WS-C4006-S2

1024

WS-C4503, WS-C4506

641

WS-C6509-E,WS-C6509, WS-C6509-NEB, WS-C6506-E, WS-C6506, WS-C6009, WS-C6006, OSR-7609-AC, OSR-7609-DC

1024

WS-C6513, WS-C6509-NEB-A, WS-C6504-E, WS-C6503-E, WS-C6503, CISCO7603, CISCO7606, CISCO7609, CISCO7613

641

1 Уменьшение количества MAC-адресов по умолчанию включено для коммутаторов с 64 MAC-адресами, и отключить функцию невозможно.

Для коммутаторов серии Catalyst с 1024 MAC-адресами включение уменьшения количества MAC-адресов позволяет поддерживать 4096 VLAN, работающих при поддержке PVST+, или назначать 16 экземплярам Multiple Instance STP (MISTP) уникальные идентификаторы без увеличения количества MAC-адресов, необходимых для коммутатора. Уменьшение MAC-адресов уменьшает количество MAC-адресов, необходимых для STP, с одного адреса на VLAN или экземпляр MISTP до одного адреса на коммутатор.

На рисунке показано, что уменьшение количества MAC-адресов идентификации моста не включено. Идентификатор моста состоит из 2-байтового приоритета моста и 6-байтового MAC-адреса:

103a.gif

Уменьшение количества MAC-адресов изменяет область BPDU, предназначенную для идентификации моста STP. Исходное 2-байтовое поле приоритета разбивается на два поля. Это разбиение приводит к образованию 4-битового поля приоритета моста и 12-битового расширения идентификации системы, позволяющего пронумеровать VLAN от 0 до 4095.

103b.gif

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

Руководство по настройке

При настройке расширенного диапазона VLAN необходимо следовать определенным рекомендациям. Коммутатор может выделять блок виртуальных сетей из расширенного диапазона для внутренних целей. Например, коммутатор может выделять виртуальные сети для маршрутизируемых портов или модулей Flex WAN. Выделение блоков VLAN всегда начинается с VLAN с номером 1006 и продолжается по возрастающей. При наличии виртуальных сетей в диапазоне, необходимом для модуля Flex WAN, выделение всех необходимых VLAN не происходит, поскольку виртуальные сети никогда не выделяются из диапазона пользовательских VLAN. Чтобы отобразить назначенные пользователем и внутренние виртуальные сети, введите в коммутаторе команду show vlan или команду show vlan summary.

>show vlan summary

Current Internal Vlan Allocation Policy - Ascending

Vlan status    Count  Vlans
-------------  -----  ------------------------------------------
VTP Active         7   1,17,174,1002-1005

Internal           7   1006-1011,1016

!--- Это внутренние VLAN.

>show vlan
---- -------------------------------- --------- ------- --------

1    default                          active    7       4/1-48                                                 


!--- Выходные данные отключены.


1006 Online Diagnostic Vlan1          active    0       internal
1007 Online Diagnostic Vlan2          active    0       internal
1008 Online Diagnostic Vlan3          active    0       internal
1009 Voice Internal Vlan              active    0       internal
1010 Dtp Vlan                         active    0       internal
1011 Private Vlan Internal Vlan       suspend   0       internal
1016 Online SP-RP Ping Vlan           active    0       internal

!--- Это внутренние VLAN.

Кроме того, перед использованием VLAN из расширенного диапазона, необходимо удалить любые существующие отображения 802.1Q-в-ISL. Также в версиях, предшествующих VTPv3, необходимо статически настраивать расширенные VLAN на всех коммутаторах с использованием режима transparent VTP. Дополнительную информацию см. в разделе Рекомендации по настройке VLAN из расширенного диапазона документа Настройка виртуальных локальных сетей.

Примечание. В ПО более старых, чем 8.1(1), версий, отсутствует возможность настройки имен виртуальных сетей для VLAN из расширенного диапазона. Данная возможность не зависит от версии или режима VTP.

Рекомендация

Постарайтесь обеспечивать согласованную конфигурацию уменьшения количества MAC-адресов в одном домене STP. Однако включение уменьшения количества MAC-адресов на всех сетевых устройствах может быть невозможным при добавлении в домен STP нового шасси с 64 MAC-адресами. Уменьшение количества MAC-адресов включено для коммутаторов с 64 MAC-адресами по умолчанию, и отключить функцию невозможно. Следует помнить, что когда две системы настроены с одинаковым приоритетом связующего дерева, у системы без уменьшения количества MAC-адресов приоритет связующего дерева выше. Чтобы включить или выключить уменьшение количества MAC-адресов, введите следующую команду:

set spantree macreduction enable | disable

Выделение внутренних VLAN производится в возрастающем порядке и начинается с VLAN с номером 1006. Во избежание конфликтов между пользовательскими и внутренними VLAN следует назначать пользовательские виртуальные сети как можно ближе к VLAN с номером 4094. При использовании коммутаторов Catalyst 6500, работающих под управлением ПО Cisco IOS®, можно настраивать выделение внутренних VLAN в убывающем порядке. Эквивалент интерфейса командной строки для ПО CatOS официально не поддерживается.

Автосогласование

Ethernet/Fast Ethernet

Автосогласование – дополнительная функция стандарта IEEE Fast Ethernet (FE) (802.3u), которая позволяет устройствам автоматически обмениваться по каналу информацией о скорости и возможностях дуплексного режима. Автосогласование работает на уровне 1 и направлено на порты уровня доступа, к которым временные пользователи, такие как ПК, подключаются к сети.

Технологическое описание

Одна из основных причин, по которым возникают проблемы с производительностью физических каналов Ethernet 10/100 Мбит/с, заключается в том, что один порт физического канала функционирует в полудуплексном, а второй – в дуплексном режиме. Это иногда случается, если у одного или обоих портов на физическом канале сброшены настройки, а процесс автосогласования не приводит к установлению одинаковой конфигурации обоих участников. То же самое происходит, когда администраторы изменяют конфигурацию на одном конце канала, не сделав это на другом конце. Типичными симптомами такой ситуации являются увеличение счетчиков последовательности контроля кадров (FCS), циклической проверки четности с избыточностью (CRC), выравнивания или карликовых пакетов.

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

Общее заблуждение об автосогласовании состоит в том, что считается возможным вручную настроить одного участника соединения на работу в полнодуплексном режиме на скорости 100 Мбит/с и обеспечить автосогласование дуплексного режима с другим участником. Фактически попытка выполнить это выльется в несогласованность дуплексных параметров. Когда один из участников соединения не видит параметров автосогласования от другого партнера, он по умолчанию устанавливает полудуплексный режим.

Большинство модулей Catalyst Ethernet поддерживают скорость 10/100 Мбит/с и полудуплексный/полнодуплексный режимы, однако это можно проверить при помощи команды show port capabilities mod/port.

FEFI

Индикация ошибок на удаленной стороне (FEFI) защищает интерфейсы 100BaseFX (оптоволокно) и Gigabit, в то время как автоматическое согласование защищает 100BaseTX (медь) от сбоев физического уровня/передачи сигналов.

Ошибка на удаленной стороне – это ошибка соединения, которую одна станция может обнаружить, а другая – нет, пример такой ошибки – отключенный передающий провод (TX). В данном примере передающая станция может принимать действительные данные и определять нормальную работу соединения при помощи отслеживания целостности соединения. Она не может определить, что другая станция не получает передаваемые ей данные. Станция 100BASE-FX, которая обнаруживает такую ошибку на удаленной стороне, может изменить передаваемый ей поток IDLE и передать специальную последовательность битов (которая называется последовательностью FEFI IDLE), чтобы сообщить соседу об ошибке на удаленной стороне; последовательность FEFI-IDLE вызывает отключение удаленного порта из-за ошибки (errdisable). Дополнительные сведения о защите от ошибок см. в разделе UDLD данного документа.

FEFI поддерживается следующим оборудованием и модулями:

  • Catalyst 5500/5000: WS-X5201R, WS-X5305, WS-X5236, WS-X5237, WS-U5538 и WS-U5539;

  • Catalyst 6500/6000 и 4500/4000: все модули 100BASE-FX и модули GE.

Рекомендация

При настройке автосогласования в 10/100-мегабитных каналах или при явной установке скорости и дуплексного режима последние полностью зависят от типа противоположного участника соединения или оконечного устройства, подключенного к порту коммутатора Catalyst. Автоматическое согласование между оконечными устройствами и коммутаторами Catalyst обычно функционирует надлежащим образом, и коммутаторы Catalyst соответствуют спецификации IEEE 802.3u. Однако неполное соответствие сетевых интерфейсных плат или коммутаторов некоторых поставщиков стандарту может привести к возникновению неисправностей. Несовместимость аппаратного обеспечения и другие проблемы также могут являться результатом добавления поставщиком дополнительных функций, таких как автоматическое определение полярности или целостности кабельного соединения, которые не описаны в спецификации IEEE 802.3u для автоматического согласования 10/100 Мбит/с. См. пример подобной ситуации в документе Уведомление о дефекте: проблемы производительности при подключении плат Intel Pro/1000T к CAT4K/6K.

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

  • Убедитесь, что на обеих сторонах канала настроено либо автоматическое согласование, либо параметры заданы явно;

  • Проверьте замечания к выпуску CatOS на наличие общих предупреждений;

  • Проверьте версию драйвера сетевой платы или операционной системы – зачастую требуется последняя версия драйвера или исправление.

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

Если для скорости порта Ethernet, который может работать со скоростью 10/100 Мбит/с, установлено значение auto, скорость и дуплексный режим согласуются автоматически. Чтобы включить для порта режим auto, введите следующую команду:

set port speed port range auto

!--- Это значение используется по умолчанию.

При явной настройке параметров порта введите следующие команды настройки:

set port speed port range 10 | 100 
set port duplex port range full | half

В ПО CatOS версии 8.3 и более новых версий было добавлено дополнительное ключевое слово auto-10-100. Ключевое слово auto-10-100 следует использовать для портов, поддерживающих скорости 10/100/1000 Мбит/с, но для которых автоматическое согласование скорости 1000 Мбит/с является нежелательным. Использование ключевого слова auto-10-100 приводит к тому, что порт ведет себя как 10/100-мегабитный порт, скорость которого установлена в значение auto. Согласование скорости и дуплексного режима выполняется только для 10/100-мегабитных портов, а скорость 1000 Мбит/с не участвует в согласовании.

set port speed port_range auto-10-100

Другие параметры

Когда автоматическое согласование используется между двумя коммутаторами, это может привести к отказу индикации ошибок уровня 1 для некоторых неисправностей. Полезным будет для дополнительного обнаружения неисправностей использовать протоколы уровня 2, как, например, интенсивный режим UDLD.

Gigabit Ethernet

Gigabit Ethernet (GE) оснащен более расширенной процедурой автоматического согласования (IEEE 802.3z), чем для Ethernet 10/100 Мбит/с, и используется для обмена параметрами управления потоком, информацией об удаленных ошибках, а также информацией о дуплексном режиме (даже, несмотря на то, что Catalyst серии GE поддерживает только полнодуплексный режим).

Примечание. Спецификация 802.3z была заменена спецификациями IEEE 802.3:2000. Дополнительные сведения см. в документе Интерактивные стандарты IEEE, подписка на стандарты LAN/MAN: архивы leavingcisco.com.

Технологическое описание

Согласование для портов GE включено по умолчанию, а у портов по обеим сторонам соединения GE должны быть одинаковые настройки. В отличие от соединений FE соединение GE не устанавливается, если по обеим сторонам соединения настройки автосогласования для портов различаются. Однако единственным необходимым условием для установления соединения на порте, для которого отключено автосогласование, является наличие действительного сигнала Gigabit с удаленной стороны. Это состояние не зависит от настройки автосогласования на удаленной стороне. Например, предположим, что есть два устройства A и B. У каждого из устройств автосогласование включено или отключено. В таблице приведен список возможных конфигураций и соответствующих состояний соединения:

Согласование

B включено

B выключено

A включено

up с обеих сторон

A down, B up

A выключено

A up, B down

up с обеих сторон

В GE синхронизация и автосогласование (если они включены) выполняются при включении соединения посредством использования специальной последовательности из зарезервированных для соединения кодовых слов.

Примечание. Существует словарь допустимых слов, но не все возможные слова действуют в GE.

Существование соединения GE можно охарактеризовать следующим образом:

103c.gif

Потеря синхронизации означает, что MAC обнаруживает отключение соединения. Потеря синхронизации применяется вне зависимости от состояния автосогласования. Потеря синхронизации происходит в определенных условиях при возникновении неисправностей, таких как получение трех недопустимых слов подряд. Если данное условие продолжается на протяжении 10 мс, возникает условие "нарушение синхронизации" и соединение переходит в состояние link_down. После потери синхронизации для восстановления синхронизации необходимо возникновение трех последовательных действительных состояний бездействия. Другие неблагоприятные события, как, например, потеря сигнала приема (Rx), приводит к отключению соединения.

Автоматическое согласование составляет часть процесса установления соединения. Когда соединение установлено, процесс автоматического согласования прекращается. Однако коммутатор продолжает отслеживать состояние соединения. Если автоматическое согласование для порта выключено, фаза "autoneg" отсутствует.

Спецификация GE по медным проводам (1000BASE-T) не поддерживает автосогласование при помощи Next Page Exchange (обмен следующими страницами). Next Page Exchange позволяет выполнять автоматическое согласование для 10/100/1000-мегабитных скоростей на медных портах.

Примечание. Спецификация оптоволоконного GE предусматривает только согласование дуплексного режима, управление потоком и удаленное обнаружение неисправностей. Порты оптоволоконного GE не выполняют согласование скорости портов. Дополнительные сведения по автосогласованию см. в разделах 28 и 37 спецификации IEEE 802.3-2002 leavingcisco.com.

Задержка повторного запуска синхронизации представляет собой программную функцию, которая управляет общим временем автоматического согласования. Если за это время синхронизация не проходит успешно, в случае зависания микропрограмма перезапускает автосогласование. Команда set port sync-restart-delay действует только в случае, когда автосогласование установлено в состояние enable.

Рекомендация

В среде GE включение автоматического согласования имеет гораздо более важное значение, чем в среде 10/100. Фактически автоматическое согласование необходимо отключать только для портов коммутатора, подключенных к устройствам, не поддерживающим согласование, либо когда проблемы взаимодействия приводят к возникновению неисправностей с соединением. Cisco рекомендует включать согласование для Gigabit Ethernet (настройка по умолчанию) для всех соединений "коммутатор-коммутатор" и вообще для всех устройств GE. Для включения автоматического согласования введите следующую команду:

set port negotiation port range enable

!--- Это значение используется по умолчанию.

Единственное известное исключение составляет подключение к устройству Gigabit Switch Router (GSR), работающему под управлением ПО Cisco IOS версий, предшествующих версии 12.0(10)S, в которую было добавлено управление потоком и автоматическое согласование. В этом случае эти две функции необходимо отключать, либо порт коммутатора сообщит, что он находится в состоянии not connected, а GSR сообщит об ошибке. Вот пример последовательности команд:


set port flowcontrol receive port range off
set port flowcontrol send port range off
set port negotiation port range disable

Время от времени необходимо проверять подключения коммутаторов к серверам. Клиенты Cisco столкнулись с проблемами согласования Gigabit Ethernet на серверах Sun, HP и IBM.

Другие параметры

Управление потоком является факультативной частью спецификации 802.3x и при его использовании необходимо выполнять его согласование. Устройства могут или не могут отправлять кадры PAUSE и отвечать на них (известный MAC 01-80-C2-00-00-00 0F). Кроме того, они могут не отвечать на запросы управления потоком от удаленных соседей. При заполнении входного буфера порта последний передает участнику соединения кадр PAUSE, который прекращает передачу, и задерживает все дополнительные кадры в выходных буферах участника соединения. Это не решает проблемы постоянного режима превышения, однако во время переполнения эффективно увеличивает входной буфер на некоторую часть выходного буфера противоположного участника.

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

Управление ей обеспечивает следующая команда:


set port flowcontrol mod/port receive | send off |on | desired


>show port flowcontrol

 Port  Send FlowControl    Receive FlowControl   RxPause TxPause
       admin    oper       admin    oper
-----  -------- --------   -------- --------     ------- -------
 6/1   off      off        on       on           0       0
 6/2   off      off        on       on           0       0
 6/3   off      off        on       on           0       0

Примечание. При согласовании на кадр PAUSE отвечают все модули Catalyst. Некоторые из модулей (например, WS-X5410, WS-X4306) никогда не передают кадры PAUSE, даже когда они согласовывают эту возможность, поскольку они не способны выполнять блокировку.

Динамический протокол транкинга

Тип инкапсуляции

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

Создание магистральных каналов (транкинг) поддерживается в нескольких типах сред уровня 2, включая ATM LANE, FDDI 802.10 и Ethernet, хотя в данном документе рассматривается только последняя.

Технологическое описание ISL

Запатентованная схема Cisco для идентификации или маркировки, называемая ISL, используется уже много лет. Доступен также стандарт IEEE 802.1Q.

Посредством полной инкапсуляции исходных кадров по схеме двухуровневой маркировки, ISL эффективно работает в качестве протокола туннелирования и обладает дополнительными преимуществами передачи кадров, не относящихся к Ethernet. В стандартный кадр Ethernet добавляются 26-битовый заголовок и 4-битовая последовательность проверки кадров (FCS) – порты, настроенные в качестве магистральных, ожидают и обрабатывают большие кадры. ISL поддерживает 1024 сети VLAN.

Формат кадра ISL

40 битов

4 бита

4 бита

48 битов

16 битов

24 бита

24 бита

15 битов

Бит

16 битов

16 битов

Переменная длина

32 бита

Адрес назначения

Тип

USER

SA

LEN

SNAP LLC

HSA

VLAN

BPDU

INDEX

Зарезервировано

Инкапсулированный кадр

FCS

01-00-0c-00-00

       

AAAA03

00000C

           

Для получения дополнительных сведений см. Формат кадра сетевого соединения между коммутаторами и IEEE 802.1Q.

Технологическое описание 802.1Q

Стандарт IEEE 802.1Q описывает гораздо больше, чем просто типы инкапсуляции, включая расширения связующего дерева, GARP (см. раздел VTP данного документа) и метки 802.1p Quality of Service (QoS).

Формат кадра 802.1Q обеспечивает сохранение исходных адресов источников и адресов назначения Ethernet, хотя при этом коммутаторы должны ожидать получения достаточно больших кадров даже на порты приема, на которых узлы могут использовать метки, устанавливая пользовательский приоритет 802.1p для сигнализации QoS. Метка имеет длину 4 байта, поэтому кадры 802.1Q Ethernet v2 имеют длину 1522 байта, что является достижением спецификации IEEE 802.3ac. 802.1Q также обеспечивает пространство для нумерации 4096 виртуальных сетей.

Все передаваемые и принимаемые кадры данных помечены в соответствии с 802.1Q, за исключением кадров, передаваемых в собственной VLAN (есть неявная метка, которая зависит от конфигурации входного порта коммутатора). Кадры в собственной VLAN всегда передаются непомеченными и также принимаются непомеченными. Однако им также могут быть присвоены метки.

Дополнительную информацию см. в документах Стандартизация виртуальных сетей IEEE 802.10 и Получение IEEE 802 leavingcisco.com.

Формат кадров 802.1Q/801.1p

 

Заголовок метки

 

TPID

TCI

48 битов

48 битов

16 битов

3 бита

1 бит

12 битов

16 битов

Переменная длина

32 бита

DA

SA

TPID

Приоритет

CFI

Идентификатор VLAN

Длина/ тип

Данные с PAD

FCS

 

0x8100

0 - 7

0-1

0-4095

 

Рекомендация

Поскольку все новое оборудование поддерживает 802.1Q (а некоторое поддерживает только 802.1Q, например, Catalyst серии 4500/4000 и CSS 11000), Cisco рекомендует, чтобы все новые реализации соответствовали стандарту IEEE 802.1Q, а старые сети постепенно переходили с ISL.

Стандарт IEEE позволяет организовать взаимодействие с устройствами других производителей. Это является преимуществом любой среды Cisco, поскольку появляются новые сетевые платы и устройства, работающие в соответствии со стандартом 802.1p. Несмотря на уровень развития реализаций ISL и 802.1Q, стандарт IEEE в конечном итоге получит большее распространение и более широкую поддержку третьих сторон, как, например, поддержка в сетевых анализаторах. Меньшие непроизводительные затраты стандарта 802.1Q на инкапсуляцию по сравнению с ISL также является небольшим аргументом в пользу 802.1Q.

Поскольку тип инкапсуляции согласовывается между коммутаторами при помощи DTP, когда ISL выбран ведущим по умолчанию при его поддержке обоими участниками, необходимо ввести следующую команду для включения использования dot1q:


set trunk mod/port mode dot1q

Если VLAN 1 удаляется из магистрального канала, что обсуждалось в разделе Внутриполосное управление данного документа, несмотря на то что пользовательские данные не принимаются и не передаются, NMP продолжает передачу по VLAN 1 управляющих протоколов, таких как CDP и VTP.

Также, как описано в разделе VLAN 1, при наличии магистральных каналов пакеты CDP, VTP и PAgP всегда передаются по VLAN 1. Если собственная VLAN коммутатора изменена, то при использовании инкапсуляции dot1q управляющие кадры будут содержать метку VLAN 1. Если включено выделение магистральных каналов dot1q до маршрутизатора и собственная VLAN в коммутаторе изменена, в VLAN 1 требуется субинтерфейс, чтобы принимать помеченные кадры CDP и обеспечивать видимость соседей CDP на маршрутизаторе.

Примечание. При использовании dot1q есть потенциальная угроза безопасности, обусловленная неявной маркировкой собственной VLAN, что позволяет пересылать кадры из одной VLAN в другую без использования маршрутизатора. Дополнительные сведения см. в документе Есть ли уязвимости в реализациях VLAN? leavingcisco.com. Обойти это можно при помощи идентификатора VLAN для собственной виртуальной локальной сети магистрального канала, которая не используется для доступа конечных пользователей. Чтобы добиться этого простым образом, большинство клиентов Cisco оставляют VLAN 1 в качестве собственной VLAN в магистральном канале и назначают порты доступа виртуальным сетям, отличным от VLAN 1.

Режим создания магистральных каналов (транкинга)

DTP представляет собой второе поколение динамического ISL (DISL) и создан для того, чтобы коммутаторы с обоих концов магистрального канала могли согласовать параметры, участвующие в передаче кадров ISL или 802.1Q, как, например, настроенный тип инкапсуляции, собственная VLAN и возможности оборудования. Это также помогает защитить немагистральные порты от передачи в них маркированных кадров, которые могут представлять серьезную угрозу безопасности, за счет обеспечения согласованного состояния портов и соседних узлов.

Технологическое описание

DTP – это протокол уровня 2, который обеспечивает согласование параметров конфигурации между портами коммутаторов и соседними портами. Он использует другой MAC-адрес многоадресной рассылки (01-00-0c-cc-cc-cc) и тип протокола SNAP 0x2004. В таблице приведена сводка режимов настройки:

Режим

Функция

Передача кадров DTP

Конечное состояние (локальный порт)

Auto (по умолчанию)

Порт готов к преобразованию соединения в магистральный канал. Порт становится магистральным, если соседний порт работает в режиме on или desirable.

Да, периодически.

Магистральный канал

On

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

Да, периодически.

Магистральный канал, безусловно.

Nonegotiate

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

Нет

Магистральный канал, безусловно.

Desirable

Порт активно пытается преобразовать соединение в магистральный канал. Порт становится магистральным, если соседний порт работает в режиме on, desirable или auto.

Да, периодически.

Приводит к созданию магистрального канала, только когда удаленный порт находится в режиме on, auto или desirable.

Off

Порт переходит в постоянный немагистральный режим и выполняет согласование для преобразования соединения в немагистральный канал. Порт становится немагистральным, даже если соседний порт не дает согласия на это изменение.

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

Магистральный канал отсутствует

Ниже приведено несколько ключевых моментов протокола:

  • DTP предполагает соединение типа "точка-точка", а устройства Cisco поддерживают только магистральные порты 802.1Q, находящиеся в режиме соединения типа "точка-точка";

  • Во время согласования протокола DTP порты не участвуют в протоколе STP. Порт будет добавлен в STP только после того, как он станет портом одним из трех типов DTP (access, ISL или 802.1Q). В другом случае, если настроен протокол PAgP, то он будет следующим процессом, запускаемым перед тем, как порт будет участвовать в STP;

  • Если порт участвует в образовании магистрального канала в режиме ISL, пакеты DTP передаются в VLAN 1, в противном случае (для магистральных или немагистральных портов 802.1Q) они передаются в собственную VLAN;

  • В режиме desirable пакеты DTP передают имя домена VTP (которое для создаваемого магистрального канала должно соответствовать), конфигурацию магистрального канала и состояние администрирования;

  • При согласовании сообщения передаются каждую секунду, а после этого – каждые 30 секунд;

  • Следует помнить, что режимы on, nonegotiate и off явно задают конечное состояние, в которое переходит порт. Неверная конфигурация может привести к опасному или несовместимому состоянию, в котором одна сторона работает в режиме магистрального канала, а другая – нет;

  • Порт, который находится в состоянии on, auto или desirable, периодически передает кадры DTP. Если порт, который находится в состоянии auto или desirable, в течение пяти минут не получает пакетов DTP, он переходит в немагистральное состояние.

Дополнительные сведения по ISL см. в документе Настройка магистральных каналов ISL в коммутаторах семейства Catalyst 5500/5000 и 6500/6000. Дополнительные сведения по 802.1Q см. в документе Создание магистральных каналов между коммутаторами Catalyst серий 4500/4000, 5500/5000 и 6500/6000 с использованием инкапсуляции 802.1Q с системным ПО Cisco CatOS.

Рекомендация

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


set trunk mod/port desirable ISL | dot1q

Примечание. На всех немагистральных портах включите магистральный режим off. Это помогает избежать потери времени на согласование при включении портов узла. Данная команда также выполняется при использовании команды set port host; дополнительные сведения см. в разделе STP. Чтобы выключить магистральные каналы для диапазона портов, введите следующую команду:


set trunk port range off

!--- Транкинг на портах выключен; часть команды set port host.

Другие параметры

В другой общей пользовательской конфигурации режим desirable используется только на уровне распределения, а самая простая конфигурация, устанавливаемая по умолчанию (режим auto) – на уровне доступа.

Некоторые коммутаторы, такие, как Catalyst 2900XL, маршрутизаторы Cisco IOS или устройства других производителей, в настоящее время не поддерживают согласование магистралей посредством DTP. В коммутаторах Catalyst 4500/4000, 5500/5000 и 6500/6000 можно использовать режим nonegotiate, чтобы порты создавали магистральные каналы безусловно, что может помочь стандартизировать общие настройки всей сети. Кроме того, режим nonegotiate можно использовать для того, чтобы уменьшить "общее" время инициализации соединения.

Примечание. Такие факторы, как режим канала и конфигурация STP также могут повлиять на время инициализации.

Чтобы включить режим nonegotiate, введите следующую команду:

set trunk mod/port nonegotiate ISL | dot1q

Cisco рекомендует использовать режим nonegotiate при наличии подключения к маршрутизатору Cisco IOS, поскольку при выполнении мостовых соединений некоторые кадры DTP, полученные из режима on, могут вернуться в магистральный порт. При получении кадра DTP порт коммутатора попытается выполнить ненужное повторное согласование (т. е. магистральный канал отключается и включается снова). Если включено состояние nonegotiate, коммутатор не пересылает кадры DTP.

Протокол связующего дерева

Основные идеи

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

Несмотря на то что STP является вполне развитым протоколом, разработанным для низкоскоростных программных спецификаций мостовых соединений (IEEE 802.1d), его реализация в больших коммутируемых сетях с большим количеством виртуальных сетей, большим количеством коммутаторов в домене, поддержкой оборудования различных производителей и новыми расширениями IEEE может представлять значительные сложности.

Для будущих целей в CatOS 6.x продолжается разработка новых функций STP, таких как MISTP, функции loop-guard (защита от петель) и root-guards (защита корневых серверов), а также обнаружение рассинхронизации времени поступления BPDU. Кроме того, в CatOS 7.x доступны дополнительные стандартизированные протоколы, как, например, общее связующее дерево IEEE 802.1s и быстросходимое связующее дерево IEEE 802.1w.

Технологическое описание

В выборах корневого моста VLAN побеждает коммутатор с наименьшим корневым идентификатором моста (BID). BID – это приоритет моста, объединенный с MAC-адресом коммутатора.

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

Для обеспечения схождения топологии выполняются следующие действия:

  1. Для всего домена связующего дерева выбирается один корневой мост.

  2. У каждого некорневого моста выбирается один корневой порт (обращенный на корневой мост).

  3. В каждом сегменте назначается порт для пересылки BPDU.

  4. Неназначенные порты становятся блокирующими.

Дополнительные сведения см. в документе Настройка связующего дерева.

Настройки по умолчанию основного таймера (секунды)

Имя

Функция

2

Hello

Управление передачей BPDU.

15

Forward Delay (Fwddelay)

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

20

Maxage

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

Состояния портов

Значение

Время по умолчанию до перехода в следующее состояние

Disabled

Выключено принудительно.

Отсутствует

Blocking

Получение BPDU и блокирование пользовательских данных.

Отслеживание получения BPDU. Ожидание в течение 20 секунд до истечения Maxage или немедленное изменение при обнаружении неисправности прямого/локального соединения.

Listening

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

Таймер fwddelay (ожидание в течение 15 секунд)

Learning

Создание топологии/таблицы CAM

Таймер fwddelay (ожидание в течение 15 секунд)

Forwarding

Передача/получение данных.

 
 

Общее изменение основной топологии:

20 + 2 (15) = 50 секунд при ожидании истечения Maxage, либо 30 секунд для неисправности прямого соединения

Два типа BPDU в STP играют роль BPDU настройки и BPDU уведомления об изменениях в топологии (TCN).

Поток BPDU конфигурации

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

Для каждого BPDU, полученного коммутатором от корневого моста, центральный NMP коммутатора Catalyst обрабатывает новый BPDU, а затем отправляет его с данными о корневых мостах. Другими словами, если потерян корневой мост или все пути до корневого моста, получение BPDU прекращается (до тех пор, пока по таймеру maxage не начнутся перевыборы корневого моста).

Поток BPDU TCN

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

BPDU TCN следует до корневого моста и подтверждается на каждом этапе, поэтому может считаться надежным механизмом. После его прихода на корневой мост, корневой мост извещает весь домен об изменении, передавая BPDU конфигурации с флагом TCN, значение времени которого равно maxage + fwddelay (по умолчанию 35 секунд). Это приводит к тому, что все коммутаторы изменяют обычное время устаревания CAM с пяти минут (по умолчанию) на интервал, задаваемый значением fwddelay (по умолчанию 15 секунд). Дополнительные сведения см. в документе Изменения топологии протокола связующего дерева.

Режимы связующего дерева

Есть три различных способа поддержания соответствия VLAN и связующего дерева:

  • Единственное связующее дерево для виртуальных сетей либо протокол одного связующего дерева, как IEEE 802.1Q;

  • Одно связующее дерево для виртуальной сети либо общее связующее дерево, как Cisco PVST;

  • Одно связующее дерево для нескольких виртуальных сетей либо множественное связующее дерево, как Cisco MISTP и IEEE 802.1s.

Одно связующее дерево для всех VLAN предусматривает только одну активную топологию и, как результат, отсутствие распределения (балансировки) нагрузки. Порт с блокировкой STP будет заблокирован для всех VLAN и не сможет передавать данные.

Одно связующее дерево на VLAN позволяет осуществлять распределение нагрузки, однако при увеличении количества VLAN требует больше времени ЦП на обработку BPDU. В замечаниях к выпуску CatOS содержатся указания по количеству логических портов, рекомендованных в протоколе связующего дерева на один коммутатор. Например, формула для Catalyst 6500/6000 Supervisor Engine 1 выглядит следующим образом:

количество портов + (количество магистральных каналов * количество виртуальных сетей на магистральных каналах) < 4000

Cisco MISTP и новый стандарт 802.1s позволяют определить только два активных экземпляра/две активных топологии STP и организовать отображение всех виртуальных сетей в любое из этих двух деревьев. Эта методика позволяет масштабировать STP на многие тысячи виртуальных локальных сетей при включенном распределении нагрузки.

Форматы BPDU

Для поддержки стандарта IEEE 802.1Q существующая реализация Cisco STP была расширена до PVST+ посредством добавления поддержки туннелирования через область одиночного связующего дерева IEEE 802.1Q. Поэтому протокол PVST+ совместим как с протоколом IEEE 802.1Q MST, так и с протоколом Cisco PVST, и для него не требуются дополнительные команды или настройка. Кроме того, в PVST+ добавлены механизмы проверки, которые позволяют убедиться в том, что среди коммутаторов отсутствует несогласованность конфигураций магистральных каналов и идентификаторов VLAN.

Ниже приведено несколько ключевых моментов протокола PVST+:

  • PVST+ взаимодействует с протоколом одиночного связующего дерева 802.1Q посредством так называемого протокола общего связующего дерева (CST) по магистральному каналу 802.1Q. CST всегда находится во VLAN 1, поэтому для взаимодействия с оборудованием других производителей эту виртуальную сеть необходимо включить в магистраль. BPDU CST всегда передаются в стандартную группу мостов IEEE (MAC-адрес 01-80-c2-00-00-00, DSAP 42, SSAP 42) без меток. Для полноты описания на MAC-адрес общего связующего дерева Cisco для VLAN 1 также выполняется параллельная передача BPDU;

  • Протокол PVST+ обеспечивает туннельную передачу BPDU PVST через области виртуальной сети 802.1Q в виде данных многоадресной рассылки. BPDU общего связующего дерева Cisco передаются для всех виртуальных сетей магистрального канала на MAC-адрес 01-00-0c-cc-cc-cd (тип протокола SNAP HDLC 0x010b). BPDU не помечаются в собственной виртуальной локальной сети и помечаются для всех остальных виртуальный локальных сетей;

  • PVST+ выполняет проверку несогласованности портов и виртуальных сетей. Во избежание возникновения петель пересылки PVST+ блокирует порты, принимающие ошибочные BPDU. Протокол также оповещает пользователей о любых несоответствиях конфигураций при помощи сообщений системного журнала;

  • Протокол PVST+ обратно совместим с существующими коммутаторами Cisco, использующими протокол PVST в магистральных каналах ISL. BPDU, инкапсулируемые в ISL, по-прежнему передаются и получаются при помощи MAC-адресов IEEE. Другими словами, каждый из типов BPDU является локальным для канала; проблем во время преобразования не возникает.

Рекомендация

Во всех коммутаторах Catalyst протокол STP включен по умолчанию. Протокол STP рекомендуется включать даже в том случае, если выбранная конфигурация не содержит петель уровня 2 и не требует включения STP, поскольку STP выполняет активное управление заблокированными портами.

set spantree enable all

!--- Это значение используется по умолчанию.

Cisco рекомендует оставлять STP включенным по следующим причинам:

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

  • Защита от сбоев канала EtherChannel;

  • В большинстве сетей протокол STP включен, что обусловливает его широкое распространение. Обычно широкое использование означает стабильность кода;

  • Защита от неправильной работы сетевых плат с двойным подключением (или мостовых соединений, включенных на серверах);

  • Программное обеспечение, поддерживающее большое количество протоколов (таких, как PAgP, отслеживание IGMP и транкинга), тесно связано с STP. Работа без STP может привести к непредсказуемым результатам.

Не изменяйте значения таймеров, это может отрицательно сказаться на стабильности. Большинство развернутых сетей не настроены. Доступ к простым таймерам STP, таким, как hello-interval и Maxage, обеспечивается при помощи интерфейса командной строки, а сами таймеры состоят из сложного набора других дополнительных и собственных таймеров, поэтому настройка таймеров и учет всех последствий такой настройки является сложной задачей. Кроме того, есть возможность нарушения защиты UDLD.

Лучше всего не использовать управляющую VLAN для пользовательского трафика. Особенно в случае более старых процессоров коммутаторов Catalyst лучше избегать проблем с STP, не допуская попадания пользовательских данных в управляющую VLAN. Одна неправильно работающая конечная станция может привести к такой загрузке процессора управляющего модуля пакетами широковещательной рассылки, что управляющий модуль может пропустить один или несколько BPDU. Однако современные коммутаторы с более мощными ЦП и регулированием потока данных избавляют от подобных проблем. Дополнительные сведения см. в разделе Внутриполосное управление данного документа.

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

Проверьте и узнайте, где располагается корневой мост и заблокированные порты. Нанесите их на схему сети. Блокирующие порты являются тем местом, откуда начинается устранение неисправностей в STP. Поиск причины, по которой порты из блокирующих стали пересылающими, часто является ключевой частью анализа неисправностей с корневыми мостами. В качестве места расположения основных/вспомогательных корневых мостов следует выбирать распределительные и основные уровни, поскольку они считаются наиболее стабильными частями сети. При помощи путей пересылки данных на уровне 2 проверьте оптимальность уровня 3 и перекрытия HSRP. Следующая команда является макрокомандой, которая служит для настройки приоритета моста. Для корневого моста устанавливается приоритет, значение которого гораздо меньше приоритета по умолчанию (32768), а для вспомогательного корневого моста устанавливается приоритет, который меньше приоритета по умолчанию на достаточную величину.

set spantree root secondary vlan range

Примечание. Данная макрокоманда устанавливает значение приоритета корневого моста равным 8192 (по умолчанию), текущему приоритету минус 1 (если известен другой корневой мост), либо текущему приоритету корневого моста (если его MAC-адрес меньше адреса текущего корневого моста).

Отключите необязательные VLAN от магистральных портов (двунаправленная задача). Это сокращает нагрузку на обработку STP и NMP в тех сегментах сети, где некоторые VLAN не используются. Автоматическое отсечение VTP не удаляет STP из магистрального канала. Для получения дополнительных сведений см. раздел Протокол VTP данного документа. При помощи CatOS версии 5.4 и в более новых версиях VLAN 1 можно удалять из магистральных каналов.

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

Другие параметры

У Cisco есть другой протокол STP, известный как VLAN-bridge. Данный протокол работает с использованием MAC-адреса назначения 01-00-0c-cd-cd-ce и типа протокола 0x010c.

Он наиболее полезен при необходимости мостового соединения немаршрутизируемых или устаревших протоколов между виртуальными сетями без помех для экземпляров связующего дерева IEEE, работающих в этих VLAN. Если интерфейсы VLAN для не связанного мостом трафика блокируются для трафика уровня 2 (это может легко произойти при их участии в одном STP, как в случае с виртуальными IP-сетями), идущий поверх него трафик уровня 3 также непреднамеренно отсекается – это непредусмотренный побочный эффект. Таким образом, VLAN-bridge является отдельным экземпляром STP для мостовых протоколов, обеспечивающим отдельную топологию, которой можно управлять, не оказывая влияния на IP-трафик.

Cisco рекомендует использовать VLAN-bridge, если необходимо мостовое соединение между сетями VLAN на маршрутизаторах Cisco, таких как MSFC.

PortFast

PortFast используется для обхода обычной работы связующего дерева на портах доступа с целью увеличения скорости подключения конечных станций друг к другу и к сервисам, к которым они должны подключаться после установления соединения. Во избежание проблем с GNS в некоторых протоколах, таких как IPX/SPX, важно, чтобы порт доступа переходил в режим пересылки сразу после установления соединения.

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

Технологическое описание

Функция PortFast пропускает обычные состояния прослушивания и обучения STP за счет непосредственного перевода порта из режима блокировки в режим пересылки, как только становится известно о включении соединения. Если эта функция не включена, STP будет отбрасывать все пользовательские данные до перевода порта в режим пересылки. Может потребоваться время, которое до двух раз больше значения времени ForwardDelay (всего 30 секунд по умолчанию).

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

В частности, STP PortFast играет важную роль в многоадресной рассылке CGMP и сетях MLS Catalyst 5500/5000. В этих средах TCN могут привести к истечению срока действия статических записей таблиц CAM CGMP, что вызовет потерю пакетов многоадресной рассылки до следующего отчета IGMP и/или очистку записей кэша MLS, который необходимо будет перестроить, и, как следствие, вызовет всплеск нагрузки на ЦП маршрутизатора, который зависит от размера кэша. (При этом не оказывается влияния на реализации MLS Catalyst 6500/6000 и записи многоадресной рассылки, изученные при отслеживании IGMP.)

Рекомендация

Cisco рекомендует, чтобы функция PortFast STP была включена для всех активных портов узла и выключена для соединений между коммутаторами и для неиспользуемых портов.

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

В CatOS версии 5.2 добавлена макрокоманда set port host port range, которая реализует эту конфигурацию для портов доступа и существенно способствует автосогласованию и производительности соединения:

set port host port range


!--- Макрокоманда для этих команд:

set spantree portfast port range enable
set trunk port range off
set port channel port range mode off

Примечание. Наличие PortFast не означает, что связующее дерево совсем не работает на этих портах. Пакеты BPDU при этом отправляются, принимаются и обрабатываются.

Другие параметры

BPDU-guard функции PortFast обеспечивает способ предотвращения образования петель, переводя немагистральный порт в состояние errdisable при получении BPDU на этот порт.

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

Команда применяется ко всему коммутатору, а не к отдельным портам, как показано ниже:

set spantree portfast bpdu-guard enable

В случае отключения порта администратор сети получает соответствующее сообщение SNMP trap (ловушку) или сообщение системного журнала. Для портов, переведенных в состояние errdisabled, можно настроить автоматическое восстановление. Для получения дополнительных сведений см. раздел UDLD данного документа. Дополнительные сведения см. в документе Функция BPDU Guard для оптимизации функции Portfast связующего дерева.

Примечание. В CatOS версии 7.x добавлена функция PortFast для магистральных портов, в более старых версиях данная функция на магистральные порты не действует. Функция PortFast для магистральных портов разработана для увеличения времени сходимости для сетей уровня 3. Чтобы дополнить эту функцию, в CatOS версии 7.x также добавлена возможность настройки функции BPDU-guard PortFast для отдельных портов.

UplinkFast

Функция UplinkFast обеспечивает быструю сходимость STP после сбоя прямого соединения на уровне сетевого доступа. Она не вносит изменений в STP, а ее целью является уменьшение времени сходимости в определенных обстоятельствах до менее чем трех секунд, в отличие от обычной 30-секундной задержки. Дополнительные сведения см. в документе Общие сведения и настройка функции Cisco Uplink Fast.

Технологическое описание

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

Группа восходящих каналов – это набор портов на виртуальную сеть, которые можно рассматривать как корневые порты и резервные корневые порты. В нормальных условиях корневые порты гарантируют соединение точки доступа с корневым мостом. Если соединение с корневым портом по какой-либо причине отключается, соединение с резервным коревым портом включается немедленно, без обычной 30-секундной задержки сходимости.

Поскольку это позволяет эффективно обходить обычный процесс обработки изменений топологии STP (прослушивание и обучение), необходим альтернативный механизм исправления топологии для обновления сведений коммутаторов в домене о том, что локальные конечные станции доступны через альтернативный путь. Коммутатор уровня доступа, в котором работает UplinkFast, также генерирует для каждого MAC-адреса из своей таблицы CAM кадры на MAC-адрес многоадресной рассылки (01-00-0c-cd-cd-cd, протокол HDLC 0x200a), чтобы обновить таблицы CAM во всех коммутаторах домена новой топологией.

Рекомендация

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

set spantree uplinkfast enable 

Данная команда устанавливает высокий приоритет моста для минимизации риска его обращения в корневой мост и высокий приоритет порта для того, чтобы он не стал назначенным портом, что привело бы к нарушениям в работе. При восстановлении коммутатора с включенной функцией UplinkFast ее следует отключить, очистить базу данных каскадного подключения с помощью команды "clear uplink" и вручную восстановить приоритеты моста.

Примечание. Когда включена функция фильтрации протоколов, для команды UplinkFast требуется ключевое слово all protocols. Поскольку при включенной фильтрации протоколов в CAM записываются тип протокола, а также данные MAC и VLAN, для каждого протокола на каждом MAC-адресе требуется создание кадра UplinkFast. Ключевое слово rate указывает количество передаваемых в секунду пакетов uplinkfast кадров обновления топологии. Рекомендуется оставить значение по умолчанию. При использовании Rapid STP (RSTP) или IEEE 802.1w настройка BackboneFast не требуется, поскольку RSTP изначально содержит этот механизм и автоматически включает его.

BackboneFast

BackboneFast обеспечивает быструю сходимость от сбоев непрямых каналов. При добавлении данной функции в STP, время сходимости обычно может уменьшиться с устанавливаемых по умолчанию 50 секунд до 30 секунд.

Технологическое описание

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

По правилам обычного связующего дерева принимающий коммутатор игнорирует подчиненные BPDU в течение заданного максимального времени старения, по умолчанию оно составляет 20 секунд. Однако с BackboneFast коммутатор видит подчиненные BPDU как сигнал возможного изменения топологии, и пытается определить, есть ли у него альтернативный путь к корневому мосту, используя BDPU запроса соединения с корневым мостом (RLQ). Данное дополнение к протоколу позволяет коммутатору проверять доступность корневого моста, переводит заблокированный порт в состояние пересылки за меньшее время и сообщает изолированному коммутатору, передающему подчиненные BPDU, о том, что корневой мост еще действует.

Ниже приведено несколько ключевых моментов работы протокола:

  • Коммутатор передает пакеты RLQ только из корневых портов (то есть по направлению к корневому мосту);

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

  • Если коммутатор потерял соединение с корневым, он должен дать отрицательный ответ на этот запрос;

  • Ответ должен быть послан только на тот порт, из которого поступил запрос;

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

  • Если ответ получен на некорневой порт, он сбрасывается.

При этом время сходимости STP может быть уменьшено на 20 секунд или менее, поскольку нет необходимости в ожидании истечения времени maxage.

Дополнительную информацию см. в документе Общие сведения и настройка Backbone Fast в коммутаторах Catalyst.

Рекомендация

Cisco рекомендует включать BackboneFast на всех коммутаторах, на которых работает STP. Ее можно добавлять без ущерба рабочей сети. Для включения BackboneFast введите следующую команду:

set spantree backbonefast enable

Примечание. Данную команду глобального уровня необходимо настроить на всех коммутаторах домена, поскольку он добавляет протоколу STP функции, которые должны понимать все коммутаторы.

Другие параметры

BackboneFast не поддерживается в 2900XLs и 3500s. Эту функцию не следует включать в случае, если в домене коммутаторов наряду с коммутаторами Catalyst 4500/4000, 5500/5000 и 6500/6000 есть эти коммутаторы.

При использовании RSTP или IEEE 802.1w настройка BackboneFast не требуется, поскольку RSTP изначально содержит этот механизм и автоматически включает его.

Функция Loop Guard (защита от петель) протокола связующего дерева

Loop guard – это разработка Cisco для оптимизации STP. Loop guard защищает сети уровня 2 от образования петель, вызванных следующими причинами:

  • Неправильная работа сетевых интерфейсов;

  • Загрузка ЦП;

  • Все, что не позволяет нормально пересылать BPDU.

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

Функция Loop guard полезна только в коммутируемых сетях, в которых коммутаторы связаны соединениями типа "точка-точка". Большинство современных сетей университетов и информационных центров является сетями этих типов. В соединении типа "точка-точка" назначенный мост не может исчезнуть, пока он не передаст подчиненный BPDU или не отключит соединение. Функция защиты от петель STP была добавлена в CatOS версии 6.2(1) платформ Catalyst 4000 и Catalyst 5000 и в версии 6.2(2) для платформы Catalyst 6000.

Дополнительную информацию по функции loop guard см. в документе Усовершенствование протокола связующего дерева с помощью функций Loop Guard и BPDU Skew Detection.

Технологическое описание

Функция Loop guard проверяет, получает ли BPDU корневой порт или дополнительный/резервный корневой порт. Если порт не получает BPDU, loop guard переводит порт в несовместимое состояние (блокирования) до тех пор, пока порт не начнет снова получать BPDU. Порт в несовместимом состоянии не передает BPDU. Если такой порт получает BPDU снова, порт (и соединение) снова считается действующим. Порт выходит из несовместимого состояния петли и STP определяет состояние порта, поскольку такое восстановление происходит автоматически.

Loop guard изолирует неисправность и позволяет связующему дереву сходиться в стабильную топологию без нарушенного канала или моста. Loop guard предотвращает образование петель STP со скоростью используемой версии STP. Зависимость от самого протокола STP (802.1d или 802.1w) или настроек таймеров STP отсутствует. Поэтому используйте loop guard в сочетании с UDLD в топологиях, полагающихся на STP, и когда ПО поддерживает эти функции.

Когда loop guard блокирует несовместимый порт, записывается следующее сообщение:

%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated 
in VLAN 77. Moved to root-inconsistent state.

Когда BPDU поступает на порт, находящийся в несовместимом состоянии петли STP, порт переходит в другое состояние STP. В соответствии с полученным BPDU восстановление происходит автоматически и вмешательство не требуется. После восстановления регистрируется следующее сообщение:

SPANTREE-2-LOOPGUARDUNBLOCK: port 3/2 restored in vlan 3.

Взаимодействие с другими функциями STP

  • Root guard (защита корня)

    Root guard заставляет порт всегда быть назначенным портом. Loop guard действует, только когда порт является корневым или альтернативным. Эти функции являются взаимоисключающими. Функции loop guard и root guard нельзя включать для порта одновременно.

  • UplinkFast

    Функция Loop guard совместима с UplinkFast. Если loop guard переводит корневой порт в заблокированное состояние, UplinkFast переводит новый корневой порт в состояние пересылки. Кроме того, UplinkFast не выбирает порт в несовместимом состоянии петли в качестве корневого.

  • BackboneFast

    Функция Loop guard совместима с BackboneFast. Получение подчиненного BPDU с назначенного моста приводит к включению BackboneFast. Поскольку BPDU поступают с данного канала, loop guard не включается, поэтому функции BackboneFast и loop guard являются совместимыми.

  • PortFast

    Portfast переводит порт в назначенное состояние пересылки сразу после установления соединения. Поскольку порт, на котором включена функция PortFast, не может быть корневым или альтернативным, функции loop guard и PortFast являются взаимоисключающими.

  • PAgP

    Loop guard использует порты, известные для STP. Поэтому loop guard может использовать преимущества абстрагирования логических портов, обеспечиваемые PAgP. Однако для формирования логического канала все физические порты, объединенные в логический канал, должны обладать совместимыми конфигурациями. Для формирования канала EtherChannеl PAgP обеспечивает согласованную конфигурацию loop guard на всех физических портах.

    Примечание. При настройке loop guard на канале EtherChannel следует помнить следующее:

    • Чтобы отправить BPDU, STP всегда использует первый подходящий порт. Если это соединение становится однонаправленным, loop guard блокирует канал, даже если другие соединения канала функционируют должным образом;

    • Если порты, заблокированные loop guard, сгруппированы для формирования логического канала, STP теряет всю информацию о состоянии этих портов. Новый канальный порт может получить состояние пересылки с назначенной ролью;

    • Если канал EtherChannel заблокирован loop guard и нарушается, STP теряет всю информацию о состоянии. Отдельные физические порты могут переходить в состояние перенаправления с присвоением назначенной роли, даже когда один или больше физических каналов, сформировавших канал EtherChannel, являются однонаправленными.

    В последних двух случаях, приведенных в списке, есть возможность образования петли до тех пор, пока UDLD не обнаружит ошибку. Однако loop guard не может обнаружить петлю.

Сравнение функций Loop Guard и UDLD

Функции Loop guard и UDLD частично совпадают. Обе направлены на защиту от сбоев STP, вызываемых однонаправленными соединениями. Разница между этими двумя функциями заключается в различном подходе к проблеме и разных функциональных возможностях. В частности, есть определенные ошибки однонаправленных соединений, которые невозможно обнаружить с помощью UDLD, такие, как ошибки, вызванные невозможностью ЦП передать BPDU. Кроме того, использование интенсивных значений таймеров STP и режима RSTP может привести к образованию петель до того, как ошибки будут обнаружены UDLD.

Функция Loop guard не действует на общих каналах и в ситуациях, когда канал с момента установления соединения был однонаправленным. В случае, когда канал был однонаправленным с момента установления соединения, порт никогда не получит BPDU и становится назначенным. Такое поведение может считаться нормальным, потому в этом случае loop guard не применяется. UDLD не обеспечивает защиту при таких обстоятельствах.

Чтобы обеспечить максимальный уровень защиты, необходимо включать и UDLD, и loop guard. Для сравнения функций loop guard и UDLD см. раздел Защита от петель и обнаружение однонаправленных каналов документа Усовершенствование протокола связующего дерева с помощью функций Loop Guard и BPDU Skew Detection.

Рекомендация

Cisco рекомендует включать loop guard глобально в сетях коммутаторов с физическими петлями. Начиная с версии 7.1(1) программного обеспечения Catalyst, loop guard можно включать глобально на всех портах. Эффективность обеспечивается включением функции для всех соединений типа "точка-точка". Дуплексное состояние соединения обнаруживает соединение типа "точка-точка". При наличии полнодуплексного режима соединение считается имеющим тип "точка-точка". Для глобального включения loop guard введите следующую команду:

set spantree global-default loopguard enable

Другие параметры

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

set spantree guard loop mod/port

Сети, в топологиях которых петли отсутствуют, все-таки получают преимущества от использования функции loop guard при случайном образовании петель. Однако включение loop guard в таких типах топологий может привести к проблемам изоляции сетей. Чтобы создать топологии без петель и избежать проблем с изоляцией сетей, введите следующие команды, чтобы отключить loop guard глобально или в индивидуальном порядке. Не включайте loop guard в общих каналах.

set spantree global-default loopguard disable

!--- Это глобальное значение по умолчанию.

или

set spantree guard none mod/port

!--- Это настройка порта по умолчанию.

Функция Root Guard (защита корня) протокола связующего дерева

Функция защиты корня обеспечивает способ принудительного расположение корневого моста в сети. Функция защиты корня обеспечивает, чтобы порт, для которого включена эта функция, был назначенным портом. Обычно все порты корневого моста являются назначенными портами до тех пор, пока два или более корневых моста не будут соединены между собой. Если мост получает вышестоящий BPDU STP на порт, на котором включена защита, мост переводит этот порт в несовместимое с корневым состояние STP. Несовместимое с корневым состояние фактически равно состоянию прослушивания. Через этот порт трафик не пересылается. Таким образом, защита корня принудительно определяет положение корневого моста. Защита корня доступна в CatOS для коммутаторов Catalyst 29xx, 4500/4000, 5500/5000 и 6500/6000 в ПО версии ПО 6.1.1 и последующих версиях.

Технологическое описание

Root guard является механизмом, встроенным в STP. У функции Root guard нет собственного таймера, она полагается только на получаемые BPDU. Когда функция root guard применяется к портам, она не позволяет им становиться корневыми портами. Если получение BPDU включает схождение связующего дерева, которое делает назначенный порт корневым, порт переводится в несовместимое с корневым состояние. Данное сообщение системного журнала демонстрирует действие:

%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated 
in VLAN 77. Moved to root-inconsistent state

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

%SPANTREE-2-ROOTGUARDUNBLOCK: Port 1/1 restored in VLAN 77

Roop guard делает порт назначенным, а loop guard действует, только когда порт является корневым или альтернативным. Поэтому эти две функции являются взаимоисключающими. Функции loop guard и root guard нельзя включать для порта одновременно.

Дополнительную информацию см. в документе Функция расширения протокола связующего дерева для защиты корневого узла.

Рекомендация

Cisco рекомендует включать функцию root guard на портах, подключенных к сетевым устройствам, управление которыми не осуществляется. Для настройки функции root guard введите следующую команду:

set spantree guard root mod/port

EtherChannel

Технологии EtherChannel позволяет выполнять инверсное мультиплексирование нескольких физических каналов (до восьми в Catalyst 6500/6000) в один логический канал. Хотя каждая следующая платформа отличается от предыдущей, необходимо понимать общие требования:

  • Алгоритм статистически мультиплексирует кадры по нескольким каналам;

  • Логические порты создаются так, что может быть запущен один экземпляр STP;

  • Протокол управления логическим каналом как, например, протокол PAgP или протокол управления агрегированием каналов (LACP).

Мультиплексирование кадров

Канал EtherChannel охватывает алгоритм распределения кадров, который эффективно мультиплексирует кадры по компонентам 10/100-мегабитных или гигабитных физических каналах. Различия в алгоритмах на той или иной платформе проистекают из способности каждого типа оборудования извлекать сведения заголовка кадра для принятия решения о распределении.

Алгоритм распределения нагрузки является глобальным параметром для обоих протоколов управления логическими каналами. В PAgP и LACP используется алгоритм распределения кадров, поскольку стандарт IEEE не обязывает использовать какой-либо определенный алгоритм распределения. Однако любой алгоритм распределения обеспечивает, чтобы при получении кадров алгоритм не приводил к неправильному расположению кадров, являющихся частью какого-либо диалога (conversation), либо к дублированию кадров.

Примечание. Необходимо учесть следующую информацию:

  • Коммутаторы Catalyst 6500/6000 оснащены более современным коммутирующим оборудованием, чем Catalyst 5500/5000, и могут считывать информацию IP на уровне 4 со скоростью передачи, чтобы принимать более рациональные решения о мультиплексировании, чем на основании простой информации MAC уровня 2;

  • Возможности Catalyst 5500/5000 зависят от наличия в модуле микросхемы Ethernet Bundling Chip (EBC). Команда show port capabilities mod/port отображает возможности каждого из портов.

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

Платформа

Алгоритм балансировки нагрузки логического канала

Catalyst серии 5500/5000

Catalyst 5500/5000 с необходимыми модулями позволяет организовать до четырех физических каналов на FEC1, эти каналы должны находиться в одном модуле. Пары MAC-адресов источника и пункта назначения определяют физический канал, выбранный для пересылки кадра. Над двумя наименее значащими битами MAC-адресов источника и получателя выполняется операция X-OR. В результате данной операции получается один из четырех результатов. (0 0), (0 1), (1 0) или (1 1). Каждое из этих значений указывает на канал в группе FEC. В случае канала Fast EtherChannel на двух портах в операции X-OR используется только единственный бит. Возможны ситуации, в которых один из адресов (источника или назначения) является постоянным. Например, местом назначения может быть сервер или, что более вероятно, маршрутизатор. В таком случае вы увидите статистику по распределению нагрузки, поскольку адреса источника всегда различаются.

Catalyst серии 4500/4000

Catalyst 4500/4000 EtherChannel распространяет кадры в физические каналы логического канала (в одном модуле) на основе битов низкого порядка MAC-адресов источника и назначения каждого кадра. По сравнению с Catalyst 5500/5000 алгоритм более сложен и использует определенное хеш-значение полей MAC DA (байты 3, 5, 6), SA (байты 3, 5, 6), входного порта и идентификатора виртуальной сети. Метод распределения кадров не предусматривает настройку.

Catalyst серии 6500/6000

Есть два доступных алгоритма хеширования, зависящих от оборудования Supervisor Engine. Хэш-функция представляет собой аппаратно реализованный многочлен семнадцатой степени, в котором во всех классах для генерации трехбитового значения используется MAC-адрес, IP-адрес или номер порта IP TCP/UDP2. Эти действия отдельно выполняются для адреса источника и адреса назначения. После результаты подвергаются операции XOR для генерации другого трехбитового значения, которое используется для определения порта канала, используемого для пересылки пакета. Каналы в Catalyst 6500/6000 можно создавать между портами любого модуля, а портов может быть до 8.

1 FEC = канал Fast EtherChannel

2 UDP = Протокол датаграмм пользователя

В таблице перечислены механизмы распределения, поддерживаемые различными моделями Supervisor Engine Catalyst 6500/6000, и их работа по умолчанию.

Оборудование

Описание

Механизмы распределения

WS-F6020 (механизм уровня 2)

Ранний Supervisor Engine 1

MAC уровня 2: SA; DA; SA и DA

WS-F6020A (механизм уровня 2)

WS-F6K-PFC (механизм уровня 3)

Следующие версии Supervisor Engine 1 и Supervisor Engine 1A/PFC1

MAC уровня 2: SA; DA; SA и DA

IP уровня 3: SA; DA; SA и DA (по умолчанию)

WS-F6K-PFC2

Supervisor Engine 2/PFC2 (требуется CatOS 6.x)

MAC уровня 2: SA; DA; SA и DA

IP уровня 3: SA; DA; SA и DA (по умолчанию)

Сессия уровня 4: порт S; порт D; порты S и D (по умолчанию)

WS-F6K-PFC3BXL

WS-F6K-PFC3B

WS-F6K-PFC3A

Supervisor Engine 720/PFC3A (требуется CatOS 8.1.x)

Supervisor Engine 720/Supervisor Engine 32/PFC3B (требуется CatOS 8.4.x)

Supervisor Engine 720/PFC3BXL (требуется CatOS 8.3.x)

MAC уровня 2: SA; DA; SA и DA

IP уровня 3: SA; DA; SA и DA (по умолчанию)

Сессия уровня 4: порт S; порт D; порты S и D

Сессия IP-VLAN уровня 4: SA, VLAN и порт S; DA, VLAN и порт D; SA, DA, VLAN, порт S и порт D

Примечание: При распределении на уровне 4 для первого фрагментированного пакета используется распределение на уровне 4. Для всех последующих пакетов используется распределение на уровне 3.

Дополнительные сведения по поддержке каналов EtherChannel на других платформах, а также описание их настройки и устранения неисправностей можно найти в следующих документах:

Рекомендация

По умолчанию коммутаторы Catalyst серии 6500/6000 выполняют распределение нагрузки по IP-адресу. Это рекомендуется в CatOS 5.5 в предположении, что IP является основным протоколом. Для настройки распределения нагрузки введите следующую команду:

set port channel all distribution ip both

!--- Это значение используется по умолчанию.

В большинстве сетей приемлемым является распределение кадров по MAC-адресу уровня 2 в Catalyst серий 4500/4000 и 5500/5000. Однако, если по каналу общаются только два основных устройства (когда SMAC и DMAC остаются постоянными), для всего трафика будет использоваться один канал. Обычно это может создать препятствия для резервного копирования на сервере и передачи больших файлов или для транзитного сегмента между двумя маршрутизаторами.

Хотя логическим агрегируемым портом (agport) можно управлять с помощью протокола SNMP как отдельным экземпляром и собирать совокупную статистику пропускной способности, Cisco рекомендует управлять каждым физическим интерфейсом отдельно. Такой подход позволяет проверить, как работает механизм распределения кадров и достигнут ли баланс статистической нагрузки.

Новая команда show channel traffic в CatOS 6.x может отображать статистику распределения в процентах, что нагляднее проверки счетчиков портов по отдельности с помощью команд show counters mod/port или show mac mod/port в CatOS 5.x. Другая новая команда, show channel hash, в CatOS 6.x позволяет на основании режима распределения проверять, какой порт был бы выбран в качестве исходящего для определенных адресов и/или определенных номеров портов. Эквивалентными командами для LACP являются команды show lacp-channel traffic и show lacp-channel hash.

Другие параметры

Если относительные ограничения алгоритмов Catalyst 4500/4000 или Catalyst 5500/5000, в основе которых лежит использование MAC-адресов, создают препятствия и не позволяют оптимально распределять статистическую нагрузку, можно выполнить следующее:

  • Точечное использование коммутаторов Catalyst 6500/6000;

  • Увеличение полосы пропускания без создания логических каналов при помощи коммутации, например, с нескольких портов FE на один порт GE или с нескольких портов GE на один порт 10 GE;

  • Переназначить адреса пар конечных станций с потоками больших объемов;

  • Предусмотреть выделенные физические каналы/виртуальные сети для устройств с широкой полосой пропускания.

Рекомендации и ограничения для настройки EtherChannel

Перед агрегированием совместимых портов в один логический порт EtherChannel проверяет свойства всех физических портов. Рекомендации и ограничения для настройки различаются для различных коммутирующих платформ. Во избежание проблем с объединением необходимо следовать данным рекомендациям. Например, когда включается QoS, каналы EtherChannel не создаются при объединении коммутирующих модулей Catalyst серий 6500/6000 с различными возможностями QoS. В ПО Cisco IOS при помощи команды интерфейса порта-канала no mls qos channel-consistency можно отключать проверку характеристик QoS порта при объединении каналов EtherChannel. В CatOS аналогичная команда отключения проверки характеристик QoS порта отсутствует. Для отображения возможностей QoS порта и определения их совместимости можно ввести команду show port capability mod/port.

Во избежание проблем с настройкой необходимо следовать данным рекомендациям для различных платформ:

Примечание. Максимальное количество портов каналов, поддерживаемых Catalyst 4000, составляет 126. В версиях ПО 6.2(1) и более ранних версиях шести- и девятислотовые коммутаторы Catalyst серии 6500 поддерживают не более 128 каналов EtherChannel. В версиях ПО начиная с 6.2(2) функция связующего дерева работает с идентификаторами портов. Поэтому максимальное количество каналов EtherChannel с поддержкой составляет 126 для шести- или девятислотовых корпусов и 63 для 13-слотового корпуса.

Протокол агрегирования портов

Протокол PAgP представляет собой протокол управления, обеспечивающий проверку согласованности параметров на обоих концах канала и согласование при сбое или добавлении физического канала. Необходимо помнить о PAgP следующее:

  • Для PAgP требуется, чтобы все порты в логическом канале принадлежали одной VLAN или были настроены в качестве магистральных портов; (Поскольку динамические VLAN могут вызывать изменения портов в другой VLAN, они не принимают участия в EtherChannel.)

  • Когда группа уже существует и изменяется конфигурация одного порта (например, при изменении VLAN или магистрального режима), все порты группы изменяются, чтобы соответствовать измененной конфигурации;

  • PAgP не группирует порты, работающие с различными скоростями или в различных дуплексных режимах. Если скорость или дуплексный режим изменяются в то время, когда каналы объединены в группу, PAgP изменит скорости и дуплексные режимы для всех портов группы.

Технологическое описание

PAgP контролирует все отдельные физические (или логические) порты, которые должны быть включены в группу. Пакеты PAgP пересылаются с использованием того же группового MAC-адреса многоадресной рассылки, который используется для пакетов CDP, 01-00-0c-cc-cc-cc. Значение протокола равно 0x0104. Ниже приведено краткое описание работы протокола:

  • Пока физический порт в состоянии up (работает), пакеты PAgP передаются каждую секунду во время обнаружения и каждые 30 секунд в устойчивом режиме;

  • Протокол следит за пакетами PAgP, которые подтверждают, что физический порт имеет двустороннее соединение с другим устройством, поддерживающим PAgP;

  • При получении пакетов данных и отсутствии пакетов PAgP считается, что порт подключен к устройству, не поддерживающему PAgP;

  • Как только группа физических портов получает два пакета PAgP, она пытается создать агрегированный порт;

  • Если получение пакетов PAgP прекращается, PAgP переходит в состояние down (отключено).

Нормальная обработка

Для помощи в понимании работы протокола необходимо определить следующие понятия:

  • Агрегированный порт — логический порт, состоящий из всех физических портов одной группы, его можно определить по собственному значению ifIndex SNMP. Поэтому агрегированный порт не содержит нерабочих портов;

  • Канал — группа, удовлетворяющая критериям формирования; следовательно, она может содержать нерабочие порты (агрегированные порты являются подмножеством каналов). Протоколы, включая STP и VTP, но исключая CDP и DTP, работают в агрегированных портах поверх PAgP. Для этих протоколов передача и прием пакетов невозможны до тех пор, пока протокол PAgP не подключит агрегированные порты данных протоколов к одному или нескольким физическим портам;

  • Групповая возможность (group capability) — все физические порты и агрегированные порты обладают параметром настройки, который называется групповой возможностью. Физический порт может быть объединен с другим физическим портом тогда и только тогда, когда у них одинаковые групповые возможности;

  • Процесс агрегирования — когда физический порт достигает состояний UpData или UpPAgP, он подключается к соответствующему агрегированному порту. При переходе порта из одного состояния в другое он удаляется из агрегированного порта.

В таблице приведены определения состояний и порядка создания:

Состояние

Значение

UpData

Не было получено ни одного пакета PAgP. Отправка пакетов PAgP выполнена. Физический порт – единственный подключенный к агрегированному порту. Между физическим портом и агрегированным портом выполнены передача и прием отличных от PAgP пакетов.

BiDir

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

UpPAgP

Этот физический порт, возможно совместно с другими физическими портами, подключен к агрегированному порту. Пакеты PAgP отправляются и принимаются физическим портом. Между физическим портом и агрегированным портом выполнены передача и прием отличных от PAgP пакетов.

Оба конца обоих соединений должны согласовать способ объединения, которое определяется как наибольшая группа портов в агрегированном порте, допустимая для обоих концов соединения.

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

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

Поведение при сбое

Если в физическом канале существующего логического канала произошел сбой (например, отключен порт, снят преобразователь Gigabit Interface Converter [GBIC] или нарушено оптическое волокно), агрегированный порт обновляется и в течение одной секунды трафик перераспределяется между оставшимися физическими каналами. Любой трафик, который не нужно перераспределять после сбоя (трафик, который продолжает идти через то же соединение), не испытывает никаких потерь. Восстановление нарушенного физического канала приводит к новому обновлению агрегированного порта и трафик перераспределяется снова.

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

В Catalyst 6500/6000 есть исключение из этого правила. В версиях CatOS, предшествующих версии 6.3, при удалении модуля, когда канал состоит только из портов модулей 1 и 2, агрегированный порт не разрывается.

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

Для уменьшения нежелательных изменений топологии в Catalyst 6500/6000 рекомендуется следующее:

  • Если для формирования логического канала используется один порт на модуль, необходимо использовать три и более модулей (всего три и более портов);

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

  • Если с двумя платами необходимо организовать двухпортовый логический канал, используйте только порты Supervisor Engine;

  • Выполните обновление до версии CatOS 6.3, которая обрабатывает удаление модулей без пересчета STP для логических каналов, распределенных между модулями.

Параметры настройки

Каналы EtherChannels можно настраивать в различных режимах, описанных в следующей таблице:

Режим

Настраиваемые параметры

On

PAgP не работает. Порт участвует в формировании логического канала вне зависимости от того, как настроен соседний порт. Если соседний порт находится в режиме on, то формируется логический канал.

Off

Порт не участвует в формировании логического канала вне зависимости от того, как настроен соседний порт.

Auto (по умолчанию)

Агрегирование выполняется под управлением протокола PAgP. Порт переводится в состояние пассивного согласования; пакеты PAgP не отправляются через интерфейс, пока не будет получен, по крайней мере, один пакет PAgP, наличие которого говорит о том, что отправитель работает в режиме desirable.

Desirable

Агрегирование выполняется под управлением протокола PAgP. Переводит порт в активное состояние согласования, в котором порт начинает согласование с другими портами, посылая пакеты PAgP. Логический канал формируется с другой группой портов, находящихся в режиме desirable или auto.

Non-silent (по умолчанию в оптоволоконных портах FE и GE Catalyst 5500/5000)

Ключевое слово режимов auto или desirable. Если интерфейс не получает пакетов данных, интерфейс никогда не включается в агрегированный порт и не может быть использован для данных. Данная проверка двунаправленности была добавлена для определенного оборудования Catalyst 5500/5000, поскольку некоторые сбои физических каналов приводят к нарушениям логических каналов. Поскольку включен режим non-silent, восстановившемуся соседнему порту не разрешается без необходимости включаться в логический канал и нарушать его. По умолчанию в оборудовании Catalyst серий 4500/4000 и 6500/6000 присутствует более гибкое объединение и улучшенная проверка двунаправленности.

Silent (по умолчанию во всех портах Catalyst 6500/6000 и 4500/4000 и портах для медного кабеля 5500/5000)

Ключевое слово режимов auto или desirable. Если интерфейс не получает пакетов данных, через 15 секунд ожидания интерфейс сам присоединяется к агрегированному порту и поэтому может быть использован для передачи данных. Режим Silent также позволяет каналу работать, когда партнер может быть анализатором или сервером, никогда не посылающим PAgP.

Настройки silent/non-silent влияют на то, как порты реагируют на ситуации, вызывающие однонаправленный трафик, или на то, как они ведут себя для устранения сбоя. Когда порт не может передавать информацию (например, из-за нарушений физического подуровня [PHY] или разрывов оптоволокна или кабеля), это может привести к тому, что соседний порт может остаться в рабочем состоянии. Партнер продолжает передавать данные, но данные теряются из-за невозможности получения ответного трафика. Из-за однонаправленности канала также могут возникать петли связующего дерева.

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

При использовании устройств, которые передают данные (например, BPDU) и не могут обнаруживать условия однонаправленности, необходимо использовать режим non-silent, который позволяет портам оставаться в нерабочем состоянии до получения данных и подтверждения двунаправленности соединения. Время, которое требуется PAgP для обнаружения однонаправленности канала, составляет около 3,5 * 30 секунд = 105 секунд, где 30 секунд – это время между двумя последовательными сообщениями PAgP. В качестве более быстрого средства обнаружения однонаправленных соединений рекомендуется использовать UDLD.

При использовании устройств, которые не передают данных, необходимо использовать режим silent. Это вызовет принудительное соединение и рабочее состояние порта независимо от получения данных. Кроме того, для портов, которые могут обнаруживать наличие однонаправленных соединений, например, в более новых платформах, использующих L1 FEFI и UDLD, режим silent используется по умолчанию.

Проверка

В таблице приведены все возможные сценарии режима создания логических каналов PAgP между двумя напрямую соединенными коммутаторами (Коммутатор A и Коммутатор B). Некоторые из этих комбинаций могут приводить к тому, что STP переведет порты со стороны, на которой созданы логические каналы, в состояние errdisable (то есть некоторые из комбинаций приводят к отключению портов со стороны, на которой созданы логические каналы).

Режим создания логических каналов в коммутаторе A

Режим создания логических каналов в коммутаторе B

Состояние логического канала

On

On

Channel (non-PAgP)

On

Off

Not Channel (errdisable)

On

Auto

Not Channel (errdisable)

On

Desirable

Not Channel (errdisable)

Off

On

Not Channel (errdisable)

Off

Off

Not Channel

Off

Auto

Not Channel

Off

Desirable

Not Channel

Auto

On

Not Channel (errdisable)

Auto

Off

Not Channel

Auto

Auto

Not Channel

Auto

Desirable

PAgP Channel

Desirable

On

Not Channel (errdisable)

Desirable

Off

Not Channel

Desirable

Auto

PAgP Channel

Desirable

Desirable

PAgP Channel

Рекомендация

Cisco рекомендует включать PAgP для всех межкоммутаторных логических каналов, избегая режима on. Предпочтительно устанавливать режим desirable с обоих концов соединения. Дополнительно рекомендуется из ключевых слов silent/non-silent оставлять ключевое слово по умолчанию silent в коммутаторах Catalyst 6500/6000 и 4500/4000, а для оптоволоконных портов Catalyst 5500/5000 оставлять ключевое слово non-silent.

Как было сказано в данном документе, явное отключение логических каналов на всех остальных портах полезно для быстрой пересылки данных. Следует избегать истечения времени ожидания (15 секунд) PAgP порта, который не будет использоваться для создания логических каналов, особенно в случае последующей передачи порта протоколу STP, для которого требуется 30 секунд для включения пересылки данных и 5 секунд для DTP, что составляет 50 секунд. Более подробно команда set port host описана в разделе STP данного документа.

set port channel port range mode desirable

set port channel port range mode off

!--- Каналы на портах не выделяются; часть команды set port host.

Эта команда присваивает логическим каналам номер группы администрирования, который отображается с помощью команды show channel group. В последующем при необходимости добавлением и удалением канальных портов в один агрегированный порт можно управлять при помощи номера группы администрирования.

Другие параметры

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

При создании логических каналов к устройствам, не поддерживающим PAgP, необходимо явно включать для таких логических каналов режим on. Это относится к таким устройствам, как серверы, устройства Local Director, коммутаторы контента, маршрутизаторы, коммутаторы со старыми версиями ПО, коммутаторы Catalyst XL и Catalyst 8540s. Введите следующую команду:

set port channel port range mode on

Новый стандарт IEEE LACP 802.3ad, доступный в версиях CatOS 7.x, вероятно, заменит PAgP в долгосрочной перспективе, так как он обеспечивает взаимодействие разных платформ и оборудования разных производителей.

Протокол управления агрегированием логических каналов

LACP представляет собой протокол, который позволяет портам со схожими характеристиками формировать логические каналы при помощи динамического согласования со смежными коммутаторами. PAgP – это принадлежащий Cisco протокол, который может работать только в коммутаторах Cisco и в коммутаторах лицензированных производителей. Однако LACP, определенный в IEEE 802.3ad, позволяет коммутаторам Cisco управлять организацией каналов Ethernet с устройствами, соответствующими спецификации 802.3ad. Поддержка LACP добавлена в ПО CatOS 7.x.

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

  • Скорость;

  • Дуплексный режим;

  • Собственная VLAN;

  • Тип магистральных каналов.

LACP и PAgP значительно различаются в следующем:

  • LACP может работать только на полнодуплексных портах, LACP не поддерживает полудуплексных портов;

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

Примечание. В CatOS одному ключу администрирования можно назначить до восьми портов. В ПО Cisco IOS протокол LACP пытается настроить максимальное количество совместимых портов в канале EtherChannel, которое допускает оборудование (восемь портов). Дополнительно восемь портов можно настроить в качестве горячего резерва.

Технологическое описание

LACP контролирует все отдельные физические (или логические) порты, которые должны быть включены в группу. Пакеты LACP передаются с использованием группового MAC-адреса многоадресной рассылки, 01-80-c2-00-00-02. Тип/рабочее значение равно 0x8809 с подтипом 0x01. Ниже приведено краткое описание работы протокола.

  • Протокол полагается на объявление возможностей агрегирования и информации о состоянии устройств самим устройствам. Пакеты пересылаются периодически на каждый "агрегируемый" физический канал.

  • Если физический порт работает, пакеты LACP передаются каждую секунду во время обнаружения и каждые 30 секунд в устойчивом режиме.

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

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

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

  • Кроме периодической передачи сообщений LACP (LACPDU) при наличии изменений в информации о состоянии протокол передает партнеру LACPDU, обусловленные определенными событиями. Партнеры по протоколу предпринимают действия в соответствии с новым состоянием системы.

Параметры LACP

Чтобы протокол LACP мог определить, что набор физических каналов подключен к одной системе и что эти каналы являются совместимыми с точки зрения агрегирования, необходима возможность определения следующих параметров:

  • Уникальный глобальный идентификатор для каждой системы, участвующей в агрегировании физических каналов;

    Каждой системе, работающей с LACP, должен быть назначен приоритет, который либо выбирается автоматически, либо назначается администратором. Значение приоритета системы по умолчанию равно 32768. Приоритет системы главным образом используется в сочетании с MAC-адресом системы для формирования идентификатора системы.

  • Средство идентификации набора возможностей, связанных с каждым портом и с каждым агрегатором, поскольку данная система их понимает;

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

  • Средство идентификации группы агрегирования физических каналов и связанный с ним агрегатор.

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

    • Физическими характеристиками портов, среди которых:

      • Скорость передачи данных;

      • Дуплексный режим;

      • Соединение типа "точка-точка" или общая среда обмена данными.

    • Ограничения конфигурации, наложенные администратором сети.

    Два ключа, связанных с каждым из портов:

    • Управляющий ключ — данный ключ позволяет управлять значениями ключей. Пользователи могут выбирать данный ключ;

    • Рабочий ключ — система использует данный ключ для формирования объединений. Пользователи не могут выбирать или напрямую изменять данный ключ.

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

Если у вас есть две системы и набор портов с одинаковым административным ключом, каждая из систем попытается объединить порты. Каждая система начинает с порта с максимальным приоритетом, принадлежащего системе с максимальным приоритетом. Такое поведение возможно постольку, поскольку каждая система знает свой приоритет, назначенный пользователем или системой, и приоритет партнера, полученный при помощи пакетов LACP.

Поведение при сбое

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

  • Отключение порта;

  • Удаление GBIC;

  • Нарушение оптоволокна;

  • Сбой оборудования (интерфейса или модуля).

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

Параметры настройки

Каналы EtherChannel LACP можно настраивать в различных режимах, описанных в следующей таблице:

Режим

Настраиваемые параметры

On

Агрегирование физических каналов производится принудительно без согласования LACP. Коммутатор не пересылает пакеты LACP и не обрабатывает входящие пакеты LACP. Если соседний порт находится в режиме on, то формируется логический канал.

Off

Порт не участвует в формировании логического канала вне зависимости от того, как настроен соседний порт.

Passive (по умолчанию)

Аналогично режиму auto в PAgP. Коммутатор не инициирует создание логического канала, но понимает входящие пакеты LACP. Соседний равноправный узел (в состоянии active) инициирует согласование передачей пакета LACP. Коммутатор принимает пакет и отвечает на него и далее формирует агрегированный канал с соседним узлом.

Active

Аналогично режиму desirable в PAgP. Для формирования агрегированного соединения коммутатор инициирует согласование. Объединение физических каналов формируется, если другая сторона работает в режиме LACP active или passive.

Проверка (LACP и LACP)

В таблице данного раздела приведены все возможные сценарии режима создания каналов LACP между двумя напрямую соединенными коммутаторами (Коммутатор A и Коммутатор B). Некоторые из этих комбинаций могут привести к тому, что STP переведет порты со стороны, создавшей канал, в состояние errdisable. Это означает, что некоторые из комбинаций вызывают выключение портов со стороны создания логического канала.

Режим создания логических каналов в коммутаторе A

Режим создания логических каналов в коммутаторе B

Режим создания логических каналов в коммутаторе A

Режим создания логических каналов в коммутаторе B

On

On

Channel (non-LACP)

Channel (non-LACP)

On

Off

Not Channel (errdisable)

Not Channel

On

Passive

Not Channel (errdisable)

Not Channel

On

Active

Not Channel (errdisable)

Not Channel

Off

Off

Not Channel

Not Channel

Off

Passive

Not Channel

Not Channel

Off

Active

Not Channel

Not Channel

Passive

Passive

Not Channel

Not Channel

Passive

Active

LACP Channel

LACP Channel

Active

Active

LACP Channel

LACP Channel

Проверка (LACP и PAgP)

В таблице данного раздела приведены все возможные сценарии режима создания логических каналов LACP-в-PAgP между двумя напрямую соединенными коммутаторами (Коммутатор A и Коммутатор B). Некоторые из этих комбинаций могут привести к тому, что STP переведет порты со стороны, создавшей канал, в состояние errdisable. Это означает, что некоторые из комбинаций вызывают выключение портов со стороны создания канала.

Режим создания логических каналов в коммутаторе A

Режим создания логических каналов в коммутаторе B

Режим создания логических каналов в коммутаторе A

Режим создания логических каналов в коммутаторе B

On

On

Channel (non-LACP)

Channel (non-PAgP)

On

Off

Not Channel (errdisable)

Not Channel

On

Auto

Not Channel (errdisable)

Not Channel

On

Desirable

Not Channel (errdisable)

Not Channel

Off

On

Not Channel

Not Channel (errdisable)

Off

Off

Not Channel

Not Channel

Off

Auto

Not Channel

Not Channel

Off

Desirable

Not Channel

Not Channel

Passive

On

Not Channel

Not Channel (errdisable)

Passive

Off

Not Channel

Not Channel

Passive

Auto

Not Channel

Not Channel

Passive

Desirable

Not Channel

Not Channel

Active

On

Not Channel

Not Channel (errdisable)

Active

Off

Not Channel

Not Channel

Active

Auto

Not Channel

Not Channel

Active

Desirable

Not Channel

Not Channel

Рекомендация

Cisco рекомендует включать PAgP в соединенных логическими каналами коммутаторах Cisco. При создании логического канала к устройствам, не поддерживающим PAgP, но поддерживающим LACP, включите LACP, настроив состояние LACP active в устройствах с обоих концов. Если устройства с обоих концов не поддерживают ни LACP, ни PAgP, необходимо явно включить для логического канала режим on.

  • set channelprotocol lacp module
    
    

    По умолчанию все порты коммутаторов Catalyst 4500/4000 и Catalyst 6500/6000, работающих под управлением CatOS, используют протокол канального уровня PAgP и не используют LACP. Для настройки использования на портах LACP необходимо установить протокол (логического) канального уровня в модулях в значение LACP. В коммутаторах, работающих под управлением CatOS, LACP и PAgP не могут одновременно работать в одном модуле.

  • set port lacp-channel port_range admin-key
    
    

    При помощи пакетов LACP выполняется обмен параметрами admin key (административный ключ). Канал будет сформирован только между портами с одинаковым административным ключом. Команда set port lacp-channel port_range admin-key назначает логическим каналам значение admin key. Команда show lacp-channel group отображает это значение. Команда set port lacp-channel port_range admin-key назначает всем портам диапазона одинаковое значение admin key. Если значение не указывать, назначается случайное значение admin key. Позже, при необходимости, для управления добавлением и удалением канальных портов в один и тот же агрегированный порт, можно использовать значение admin key.

  • set port lacp-channel port_range mode active
    

    Команда set port lacp-channel port_range mode active изменяет канальный режим на active для набора портов, ранее назначенных одному значению admin key.

Кроме того, после создания каналов EtherChannels LACP протокол LACP использует таймер (Slow_Periodic_Time) с 30-секундным интервалом. Количество секунд до аннулирования полученной информации LACPDU при использовании длинных задержек (3 x Slow_Periodic_Time) составляет 90. В качестве более быстрого средства обнаружения однонаправленных соединений используйте UDLD. Таймеры LACP настраивать нельзя, и на сегодняшний день нельзя настраивать коммутаторы на быструю передачу PDU (каждую секунду) в целях поддержки канала после его формирования.

Другие параметры

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

Обнаружение однонаправленного канала

UDLD – это принадлежащий Cisco упрощенный протокол, разработанный для обнаружения однонаправленных соединений между устройствами. Несмотря на наличие других способов обнаружения двунаправленного состояния среды передачи, таких как FEFI, есть определенные случаи, для которых механизмов обнаружения уровня 1 недостаточно. Эти варианты могут привести к любому из следующих событий:

  • Непредсказуемая работа STP;

  • Неправильная или избыточная лавинная маршрутизация пакетов;

  • Исчезновение трафика.

Функция UDLD направлена на обнаружение этих условий отказа в оптоволоконных и медных интерфейсах Ethernet:

  • Отслеживает физическую конфигурацию разводки кабелей и переключает любые неправильно подключенные порты в состояние errdisable;

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

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

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

Технологическое описание

UDLD – это протокол уровня 2, работающий над уровнем LLC (MAC-адрес назначения 01-00-0c-cc-cc-cc, тип протокола SNAP HDLC 0x0111). При работе UDLD в комбинации с механизмами FEFI и автоматического согласования уровня 1, можно проверять физическую (уровня 1) и логическую (уровня 2) целостность соединения.

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

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

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

  • UDLD-3-DISABLE: Unidirectional link detected on port [dec]/[dec]. Port disabled

  • UDLD-4-ONEWAYPATH: A unidirectional link from port [dec]/[dec] to port [dec]/[dec] of device [chars] was detected

Полный список системных сообщений по механизмам, среди которых также события UDLD, см. в документе Сообщения и действия по восстановлению (коммутаторы серии Catalyst, 7.6).

После того как соединение установлено и рассматривается как двунаправленное, UDLD продолжает рассылать сообщения probe/echo через установленные по умолчанию интервалы времени, равные 15 секундам. В таблице приведены действительные состояния соединения UDLD, которые встречаются в выходных данных команды show udld port:

Состояние порта

Комментарий

Undetermined

Выполняется определение, либо соседний элемент UDLD был отключен, либо его передача была заблокирована.

Not applicable

UDLD отключен.

Shutdown

Обнаружен однонаправленный канал и порт отключен.

Bidirectional

Обнаружен двунаправленный канал.

  • Поддержание кэша соседнего узла — UDLD периодически отправляет пакеты hello probe/echo на каждый активный интерфейс, чтобы обеспечивать целостность кэша UDLD соседнего узла. Всякий раз, когда принимается сообщение hello, оно кэшируется и хранится в памяти в течение максимального периода, определенного как время промежуточного хранения (hold-time). Когда время промежуточного хранения истекает, соответствующая запись кэша устаревает. Если в течение этого времени промежуточного хранения получено новое сообщение hello, происходит замена старой записи новой и сброс соответствующего таймера времени существования.

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

  • Механизм обнаружения эхо-ответов — в основе механизма обнаружения лежит механизм эхо-ответов. Когда устройство UDLD узнает о новом соседнем узле или получает запрос на повторную синхронизацию от несинхронизированного соседнего узла, оно запускает/перезапускает окно обнаружения на своей стороне подключения и отправляет в ответ пакет эхо-сообщений. Поскольку такое поведение должно быть одинаковым для всех соседних узлов, отправитель эхо-запроса ожидает получить эхо-ответ. Если достигнут конец окна обнаружения и при этом не было получено ни одного корректного ответного сообщения, соединение считается однонаправленным, и может быть инициирован процесс переподключения или выключения порта.

Время сходимости

Чтобы предотвратить образование петель STP, в CatOS 5.4(3) интервал передачи сообщений UDLD, установленный по умолчанию, уменьшен с 60 секунд до 15, чтобы выключать однонаправленное соединение до того, как заблокированный порт сможет перейти в состояние пересылки.

Примечание. Значение интервала между сообщениями определяет скорость, с которой соседний узел отсылает проверочные сообщения UDLD после фазы включения соединения или определения. Интервал между сообщениями не обязательно должен совпадать на обоих концах соединения, хотя по возможности рекомендуется поддерживать согласованную конфигурацию. Когда соседние узлы UDLD установлены, передается установленный интервал между сообщениями и вычисляется время задержки для соседнего узла, которое равно (3 * message_interval). Поэтому связь с соседним узлом прерывается после пропуска трех последовательных сообщений hello (или probe). Когда интервалы между сообщениями различаются с обеих сторон, это значение времени ожидания различается для обеих сторон.

Чтобы протокол UDLD обнаружил образование однонаправленного канала, требуется приблизительно (2,5 * message_interval + 4 секунды) или около 41 секунды при стандартном интервале между сообщениями, равном 15 секундам. Это значительно меньше 50 секунд, которые обычно требуются для схождения STP. Если у ЦП NMP есть несколько свободных циклов и при тщательном отслеживании уровня загрузки можно уменьшить интервал между сообщениями до минимального значения (точного), составляющего 7 секунд. Этот интервал между сообщениями помогает значительно ускорить обнаружение.

Таким образом, UDLD имеет предполагаемую зависимость от таймеров связующего дерева по умолчанию. При настройке более быстрого схождения STP по сравнению с UDLD следует рассмотреть возможность использования альтернативного механизма, как, например, функции loop guard CatOS 6.2. Возможность использования альтернативного механизма следует также в случаях использования RSTP (IEEE 802.1w), поскольку сходимость RSTP исчисляется миллисекундами и зависит от топологии. В таких случаях используйте loop guard в сочетании с UDLD, что обеспечивает максимальную защиту. Loop guard предотвращает образование петель STP со скоростью используемой версии STP, а UDLD обнаруживает однонаправленные соединения в отдельных физических каналах логического канала EtherChannel или в случаях, когда BPDU не передаются в направлении, где соединение нарушено.

Примечание. UDLD обнаруживает не все сбои STP. Например, UDLD не обнаруживает сбои, когда ЦП не передает BPDU в течение времени, превышающего (2 * FwdDelay + Maxage). По этой причине Cisco рекомендует в топологиях, полагающихся на STP, использовать UDLD в сочетании с функцией loop guard (добавленной в CatOS 6.2).

caution Внимание! Будьте внимательны с более ранними версиями протокола UDLD, в котором используется ненастраиваемый интервал между сообщениями, равный по умолчанию 60 секундам. Эти версии чувствительны к условиям образования петель связующего дерева.

Интенсивный  режим UDLD

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

  • Когда потеря PDU UDLD является симметричной и на обоих концах происходит превышение времени ожидания, ни один из портов не переходит в состояние errdisabled;

  • На одной стороне канала порт зависает (осуществляет передачу [Tx] и прием [Rx]);

  • Один конец канала остается в рабочем состоянии, в то время как другой отключается;

  • Автосогласование или другой механизм обнаружения сбоев уровня 1 отключены;

  • Ожидается снижение надежности механизмов FEFI уровня 1;

  • Требуется максимальная защита от сбоев однонаправленных каналов в каналах FE/GE типа "точка-точка". В частности, сбои между двумя соседними узлами недопустимы, проверочные сообщения интенсивного режима UDLD можно рассматривать как “сердцебиения”, наличие которых гарантирует работоспособность соединения.

Наиболее распространенным случаем использования интенсивного режима UDLD является проверка подключения участника группы, когда автосогласование или другой механизм обнаружения сбоев на уровне 1 отключены или бесполезны. Это в особенности верно для соединений EtherChannel, поскольку для PAgP/LACP, когда они включены, в устойчивом состоянии не используются очень маленькие значения таймеров сообщений hello. В этом случае интенсивный режим UDLD обладает дополнительным преимуществом предупреждения образования петель связующего дерева.

Обстоятельства, способствующие симметричной потере проверочных пакетов UDLD, охарактеризовать сложнее. Необходимо осознавать, что в обычном режиме UDLD не проверяет состояние однонаправленного канала передачи, даже после того, как канал перейдет в двунаправленное состояние. Цель UDLD заключается в обнаружении проблем уровня 2, приводящих к образованию петель STP, а эти проблемы обычно связаны с однонаправленностью, поскольку в устойчивом состоянии BPDU передаются только в одном направлении. Поэтому использование обычного UDLD в сочетании с автосогласованием и loop guard (для сетей, полагающихся на STP) практически всегда является достаточным. Однако интенсивный режим UDLD полезен в ситуациях, когда наблюдается перегрузка в обе стороны, что приводит к потере проверочных сообщений UDLD в обоих направлениях. Например, такая потеря проверочных сообщений UDLD может происходить при повышении нагрузки на ЦП с обеих сторон соединения. Другим примером нарушения двунаправленной связи является сбой одного из следующих устройств:

  • Приемопередающего устройства спектрального уплотнения (DWDM);

  • Преобразователь сред передачи данных;

  • Концентратор;

  • Другое устройство уровня 1.

    Примечание. Сбой невозможно обнаружить при помощи автосогласования.

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

После устаревания всех соседних узлов порта, интенсивный режим UDLD (если он включен) перезапускает последовательность включения соединения, пытаясь выполнить ресинхронизацию с любыми потенциально рассинхронизированными соседними узлами. Эти попытки имеют место либо в фазе объявления, либо в фазе обнаружения. Если после быстрой последовательности сообщений (восемь неудачных попыток) канал считается "неопределенным", порт переводится в состояние errdisable.

Примечание. В некоторых коммутаторах отсутствует поддержка интенсивногорежима UDLD. В настоящее время интервал между сообщениями в Catalyst 2900XL и Catalyst 3500XL установлен неизменным и равен 60 секундам. Этот интервал не считается достаточно коротким для защиты от потенциальных петель STP (с использованием параметров STP по умолчанию).

UDLD в маршрутизируемых соединениях

В данном разделе маршрутизируемое соединение – это соединение одного из двух типов:

  • Соединение типа "точка-точка" между двумя узлами маршрутизатора;

    Данное соединение настроено с 30-битовой маской подсети.

  • VLAN с несколькими портами, которая поддерживает только маршрутизируемые подключения.

    В примере основная топология разделена на уровне 2.

Все протоколы внутренней маршрутизации шлюзов (IGRP) обладают уникальными характеристиками в отношении того, как они обрабатывают соседние связи и сходимость маршрутов. Характеристики, рассматриваемые в данном разделе, являются соответствующими при сравнении двух и более распространенных протоколов маршрутизации, используемых сегодня, протокол открытия кратчайшего пути (OSPF) и усовершенствованный IGRP (EIGRP).

Сначала следует отметить, что ошибки уровней 1 и 2 в любой маршрутизируемой сети с соединениями типа "точка-точка" приводят к немедленному разрыву соединения уровня 3. Поскольку единственный порт коммутатора в этой VLAN при ошибке уровня 1/2 переходит в неподключенное состояние, функция автоматического определения состояния MSFC синхронизирует состояния порта уровней 2 и 3 приблизительно за две секунды. Эта синхронизация переводит интерфейс виртуальной сети уровня 3 в состояние включения/выключения (при выключенном протоколе линии).

Предположим, что таймерам присвоены значения по умолчанию. OSPF передает сообщения hello каждые 10 секунд, время ожидания ответа составляет 40 секунд (4 * hello). Эти таймеры согласуются для сетей OSPF с соединениями типа "точка-точка" и широковещательных сетей. Поскольку для формирования смежности для OSPF требуется двунаправленная связь, время восстановления после сбоя в худшем случае составляет 40 секунд. Это восстановление после сбоя имеет место даже в случае, когда сбой уровня 1/2 не является полным в соединении типа "точка-точка", что приводит к неполной работоспособности, с которой должен работать протокол уровня 3. Поскольку определение времени в протоколе UDLD очень подобно времени таймера бездействия OSPF (около 40 секунд), преимущества конфигурации обычного режима UDLD в соединениях типа "точка-точка" уровня 3 OSPF являются ограниченными.

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

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

  • Предотвращает ненужное исчезновение трафика;

    Примечание. В некоторых случаях требуются минимальные значения таймеров.

  • Переводит нестабильное соединение в состояние errdisable;

  • Обеспечивает защиту от петель, возникающих вследствие настроек EtherChannel уровня 3.

Поведение UDLD при настройках по умолчанию

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

Примечание. UDLD необходимо включать глобально и уровень интерфейса между соседних узлов может достигнуть двунаправленного состояния. В версиях CatOS, начиная с 5.4(3), по умолчанию интервал между сообщениями составляет 15 секунд и устанавливается в пределах от 7 до 90 секунд.

По умолчанию восстановление из состояния errdisable на глобальном уровне отключено. После его глобального включения, если порт переходит в состояние errdisable, то через заданный промежуток времени происходит его автоматическое включение. По умолчанию это время составляет 300 секунд. Значение этого таймера является глобальным и поддерживается для всех портов в коммутаторе. Чтобы вручную отключить повторное включение порта, можно установить время ожидания состояния errdisable для порта в значение disable. Введите команду set port errdisable-timeout mod/port disable.

Примечание. Использование данной команды зависит от версии ПО.

Следует рассмотреть возможность использования времени ожидания состояния errdisable при использовании интенсивногорежима UDLD при отсутствии возможностей управления сетью через выделенное подключение, в частности на уровне доступа или в любом устройстве, которое становится изолированным от сети в случае возникновения состояния errdisable.

Дополнительные сведения о настройке значений времени ожидания для портов, находящихся в состоянии errdisable, см. в документе Настройка коммутации Ethernet, Fast Ethernet, Gigabit Ethernet, и 10-гигабитного Ethernet.

Рекомендация

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

  • FEFI;

  • Автосогласование;

  • Loop guard.

При использовании UDLD следует рассмотреть необходимость постоянной проверки двунаправленности подключения (интенсивный режим). Обычно при включенном автосогласовании нет необходимости использовать интенсивный режим, поскольку автосогласование выполняет обнаружение сбоев на уровне 1.

Cisco рекомендует включать обычный режим UDLD во всех соединениях FE/GE типа "точка-точка" между коммутаторами Cisco, в которых значение интервала между сообщениями UDLD по умолчанию составляет 15 секунд. Эта конфигурация предполагает установку таймеров связующего дерева 802.1d в значения по умолчанию. Кроме того, в целях обеспечения избыточности и сходимости в сетях, полагающихся на STP, следует использовать UDLD в сочетании с функцией loop guard. Эта рекомендация относится к сетям, в топологии которых есть один и более портов в состоянии блокирования STP.

Для включения UDLD введите следующую команду:

set udld enable

!--- После глобального включения на всех оптоволоконных 
!--- портах FE и GE служба UDLD включена по умолчанию.


set udld enable port range


!--- Это для дополнительных специальных портов и медных линий связи, если требуется.

Необходимо вручную включать порты, отключенные в результате ошибки при возникновении симптомов однонаправленного соединения. Введите команду set port enable.

Дополнительные сведения см. в документе Общие сведения и настройка протокола обнаружения однонаправленных соединений (UDLD).

Другие параметры

Для максимальной защиты от симптомов однонаправленного соединения настройте интенсивный режим UDLD:

set udld aggressive-mode enable port_range

Кроме того, для ускорения сходимости, с каждой стороны, на которой это поддерживается, можно настраивать значение интервала между сообщениями UDLD в пределах от 7 до 90 секунд.

set udld interval time

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

Если порт переходит в состояние errdisable, по умолчанию порт остается выключенным. Можно ввести следующую команду, которая включает порт по истечении времени ожидания:

Примечание. Значение времени ожидания по умолчанию равно 300 секундам.

>set errdisable-timeout enable ?
bpdu-guard

!--- Это защита портов BPDU.


channel-misconfig

!--- Это неправильная конфигурация канала.


duplex-mismatch
udld
other

!--- Это другие причины.


all

!--- Примените тайм-аут при отключении из-за ошибки для всех причин.

Если соседнее устройство, например, конечный узел или маршрутизатор, не поддерживает UDLD, не используйте протокол. Введите следующую команду:

set udld disable port_range

Проверка и контроль UDLD

В тестовых условиях UDLD трудно проверить без откровенно неисправного/однонаправленного компонента, такого как дефектный GBIC. Этот протокол был разработан для выявления сценариев отказа, которые встречаются реже, чем те, которые обычно используют в тестовых условиях. Например, при выполнении простой проверки посредством отключения одной жилы оптоволокна для получения требуемого состояния errdisable, необходимо отключить автосогласование уровня 1. В противном случае физический порт выключается, что приводит к нарушению обмена сообщениями UDLD. В обычном режиме UDLD удаленная сторона переходит в неопределенное состояние. При использовании интенсивногорежима UDLD удаленная сторона переходит в состояние errdisable.

Есть дополнительный способ проверки, имитирующий потерю PDU от соседнего узла для UDLD. Для блокирования аппаратных адресов UDLD/CDP и пропускания остальных адресов следует использовать фильтры уровня MAC.

Для проверки UDLD введите следующие команды:

>show udld

UDLD              : enabled
Message Interval  : 15 seconds


>show udld port 3/1

UDLD              : enabled
Message Interval  : 15 seconds
Port      Admin Status  Aggressive Mode  Link State
--------  ------------  ---------------  ----------------
	3/1      enabled       disabled         bidirectional

Чтобы в режиме enable проверить содержимое кэша UDLD (так же, как это делается с CDP), можно ввести скрытую команду show udld neighbor. Часто для проверки наличия нарушений, связанных с конкретными протоколами, полезным бывает сравнение кэша UDLD и кэша CDP. Обычно при любых нарушениях CDP также оказывается влияние на все PDU/BPDU. Поэтому необходимо также проверить STP. Например, проверьте наличие недавних изменений корневых узлов или изменений положения корневых/назначенных портов.

>show udld neighbor 3/1

Port  Device Name            Device ID    Port-ID OperState
----- ---------------------  ------------ ------- ----------
	3/1   TSC07117119M(Switch)   000c86a50433 3/1     bidirectional

Кроме того, с помощью переменных Cisco UDLD SNMP MIB можно контролировать состояние UDLD и корректность конфигурации.

Большие кадры

По умолчанию максимальный размер передаваемого блока (MTU) составляет 1518 байт для портов Ethernet, что также включает GE и 10 GE. Функция больших кадров позволяет интерфейсам осуществлять коммутацию кадров, размер которых превышает стандартный размер кадра Ethernet. Функция полезна для оптимизации межсерверной производительности и поддержки таких областей применения, как многопротокольная коммутация с использованием меток (MPLS), туннелирование 802.1Q и версия 3 протокола туннелирования по уровню 2 (L2TPv3), что увеличивает размер исходных кадров.

Технологическое описание

В спецификации стандарта IEEE 802.3 определен максимальный размер кадра Ethernet, который составляет 1518 байтов для обычных кадров и 1522 байта для инкапсулированных кадров 802.1Q. Обычно инкапсулированные кадры 802.1Q называются "baby giants" ("огромными малышами"). В общем случае пакеты считаются большими, когда их длина для конкретного соединения Ethernet превышает максимальную длину кадров Ethernet. Пакеты большого размера также носят название больших кадров (jumbo frames).

Есть много причин, по которым размер MTU определенных кадров может превышать 1518 байтов. Вот несколько примеров:

  • Требования оборудования определенных производителей — приложения и некоторые сетевые интерфейсные платы (NIC) могут задавать размер MTU, превышающий стандартные 1500 байт. Тенденция задавать такой размер MTU происходит из проведенных исследований, которые доказали, что увеличение размера кадра Ethernet может привести к увеличению общей пропускной способности.

  • Создание магистралей (транкинг) — для увеличения стандартного размера кадра Ethernet с целью передачи данных об идентификаторе VLAN между коммутаторами или другими сетевыми устройствами используется функция создания магистралей. На сегодня два самых распространенных вида создания магистралей – это протокол инкапсуляции ISL, разработанный Cisco, и протокол IEEE 802.1Q.

  • MPLS — после включения MPLS для интерфейса у него появляется потенциал для увеличения размера пакета. Это увеличение зависит от количества меток в стеке меток для пакетов, помеченных при помощи MPLS. Общий размер меток составляет 4 байта. Общий размер стека меток составляет n x 4 байта. Если сформирован стек меток, кадры могут превышать MTU.

  • Туннелирование 802.1Q — в туннельных пакетах 802.1Q содержится две метки 802.1Q, только одну из которых оборудование видит одновременно. В результате внутренняя метка добавляет к значению MTU 4 байта (размер полезной информации).

  • Универсальный транспортный интерфейс (UTI)/L2TPv3 — UTI/L2TPv3 инкапсулирует данные уровня 2, которые необходимо перенаправлять по сетям IP. Инкапсуляция может увеличить размер кадра на величину до 50 байтов. Новый кадр состоит из нового заголовка IP (20-байтового), заголовка L2TPv3 (12-байтового) и нового заголовка уровня 2. Полезная информация L2TPv3 состоит из полного кадра уровня 2, в состав которого входит заголовок уровня 2.

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

  • Коммутаторы Catalyst серии 5500/5000 поддержка больших кадров включена в CatOS версии 6.1. Когда для порта включена поддержка больших кадров, размер MTU увеличивается до 9216 байтов. В 10/100-мегабитных линейных платах для неэкранированной витой пары (UTP) максимальный поддерживаемый размер кадра составляет только 8092 байт. Это ограничение ASIC. Обычно ничего не препятствует включению функции поддержки кадров больших размеров. Данную функцию можно использовать с транкингом/без транкинга и с созданием/без создания логических каналов.

  • Коммутаторы Catalyst 4000 (Supervisor Engine 1 [WS-X4012] и Supervisor Engine 2 [WS-X4013]) не поддерживают большие кадры вследствие ограничения ASIC. Однако исключение составляет транкинг 802.1Q.

  • Платформы Catalyst серии 6500 могут поддерживать кадры больших размеров начиная с CatOS версии 6.1(1). Однако эта поддержка зависит от типа используемых линейных плат. Обычно ничего не препятствует включению функции поддержки кадров больших размеров. Данную функцию можно использовать с транкингом/без транкинга и с созданием/без создания логических каналов. После включения поддержки кадров большого размера на отдельном порту размер MTU по умолчанию составляет 9216 байт. С использованием CatOS размер MTU, устанавливаемый по умолчанию, настройке не подлежит. Однако в ПО Cisco IOS версии 12.1(13)E добавлена команда system jumbomtu, позволяющая изменить размер MTU, устанавливаемый по умолчанию.

Дополнительную информацию см. в документе Пример конфигурации поддержки больших/гигантских кадров в коммутаторах Catalyst.

В таблице приведены размеры MTU, поддерживаемые различными линейными платами для коммутаторов Catalyst серии 6500/6000:

Примечание. Размер MTU пакета относится только к полезной информации Ethernet.

Линейная плата

Размер MTU

По умолчанию

9216 байт

WS-X6248-RJ-45, WS-X6248A-RJ-45 WS-X6248-TEL, WS-X6248A-TEL WS-X6348-RJ-45(V), WS-X6348-RJ-21(V)

8092 байт (ограничивается микросхемой PHY)

WS-X6148-RJ-45(V), WS-X6148-RJ-21(V) WS-X6148-45AF, WS-X6148-21AF

9100 байт (на скорости 100 Мбит/с)

9216 байт (на скорости 10 Мбит/с)

WS-X6148A-RJ-45, WS-X6148A-45AF, WS-X6148-FE-SFP

9216 байт

WS-X6324-100FX-MM, -SM, WS-X6024-10FL-MT

9216 байт

WS-X6548-RJ-45, WS-X6548-RJ-21, WS-X6524-100FX-MM WS-X6148X2-RJ-45, WS-X6148X2-45AF WS-X6196-RJ-21, WS-X6196-21AF WS-X6408-GBIC, WS-X6316-GE-TX , WS-X6416-GBIC WS-X6516-GBIC, WS-X6516A-GBIC, каскадные соединения Supervisor Engine 1, 2, 32 и 720 WS-X6816-GBIC

9216 байт

WS-X6516-GE-TX

8092 байта (на скорости 100 Мбит/с)

9216 байта (на скоростях 10 или 1000 Мбит/с)

WS-X6148-GE-TX, WS-X6148V-GE-TX, WS-X6148-GE-45AF, WS-X6548-GE-TX, WS-X6548V-GE-TX, WS-X6548-GE-45AF

1500 байт (большие кадры не поддерживаются)

WS-X6148A-GE-TX, WS-X6148A-GE-45AF, WS-X6502-10GE, серия WS-X67xx

9216 байт

OSM ATM (OC12c)

9180 байт

OSM CHOC3, CHOC12, CHOC48, CT3

9216 байт (OCx и DS3)

7673 байта (T1/E1)

Flex WAN

7673 байта (CT3 T1/DS0)

9216 байт (OC3c POS)

7673 байта (T1)

CSM (WS-X6066-SLB-APC)

9216 байт (для CSM 3.1(5) и 3.2(1))

OSM POS OC3c, OC12c, OC48c; OSM DPT OC48c, OSM GE WAN

9216 байт

Поддержка больших кадров на уровне 3

В ПО CatOS, под управлением которого работает Supervisor Engine, и в ПО Cisco IOS, под управлением которого работает MSFC, коммутаторы Catalyst 6500/6000 также обеспечивают поддержку больших кадров на уровне 3 в ПО Cisco IOS® начиная с версии 12.1(2)E при использовании оборудования PFC/MSFC2, PFC2/MSFC2 или более нового. Если для больших кадров настроены и входная, и выходная виртуальные сети, все пакеты аппаратно коммутируются PFC со скоростью передачи данных. Если входная виртуальная сеть настроена на большие кадры, а выходная виртуальная сеть не настроена, возможны два случая:

  • Конечный узел передает большой кадр с установленным битом "не фрагментировать" (DF) (для обнаружения MTU пути) — пакет сбрасывается и конечному хосту отправляется сообщение протокола управляющих сообщений Интернета (ICMP) о недостижимости с кодом сообщения fragment needed and DF set;

  • Конечный узел передает большой кадр, у которого бит DF не установлен — пакеты передаются MSFC2/MSFC3 для фрагментирования и коммутации в ПО.

В таблице приведено описание поддержки больших кадров на уровне 3 для различных платформ:

Коммутатор или модуль уровня 3

Максимальный размер MTU на уровне 3

Catalyst серий 2948G-L3/4908G-L3

Большие кадры не поддерживаются.

Catalyst 5000 RSM1/RSFC2

Большие кадры не поддерживаются.

Catalyst 6500 MSFC1

Большие кадры не поддерживаются.

Catalyst 6500 MSFC2 и более новые версии

ПО Cisco IOS версии 12.1(2)E: 9216 байт

1 RSM = маршрутизирующий модуль коммутатора

2 RSFC = плата маршрутизации для коммутатора

Рекомендации по пропускной способности сети

Пропускная способность TCP в глобальных сетях (Internet) была подвергнута тщательному изучению. Данное уравнение объясняет зависимость верхней границы пропускной способности от следующих факторов:

  • Максимальный размер сегмента (MSS), который равен разнице между длиной MTU и длиной заголовков TCP/IP;

  • Время прохождения сигнала в прямом и обратном направлениях (RTT);

  • Потери пакетов.

103d.gif

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

Во-вторых, постоянное растущие потребности в пропускной способности пулов серверов требуют более эффективных средств, обеспечивающих большие скорости передачи с использованием датаграмм UDP сетевой файловой системы (NFS). NFS является наиболее широко распространенным механизмом хранения данных, предназначенным для передачи файлов между серверами, работающими под управлением UNIX. Для NFS используются датаграммы размером 8400 байт. При использовании увеличенного 9-килобайтного MTU Ethernet один большой кадр достаточно велик для передачи 8 килобайт датаграммы приложения (например, NFS) плюс заголовок пакета. Эта возможность в данном случае позволяет осуществлять более эффективный прямой доступ к памяти (DMA) узлов, поскольку ПО ничего дополнительно не требуется для фрагментирования блоков NFS на отдельные датаграммы UDP.

Рекомендация

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

Настройте в устройствах, которые могут работать с большими кадрами, размер MTU, который является наименьшим из поддерживаемых сетевым оборудованием, для всей виртуальной сети уровня 2, в которой находятся узлы. Чтобы включить поддержку больших кадров модулями, поддерживающими работу с большими кадрами, введите следующую команду:

set port jumbo mod/port enable

Кроме того, если необходима поддержка больших кадров за границами уровня 3, на всех соответствующих интерфейсах VLAN настройте максимальное доступное значение MTU, составляющее 9216 байт. Для интерфейсов VLAN введите команду mtu:

interface vlan vlan#
mtu 9216

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

Настройка управления

В данном разделе рассматриваются моменты, которые помогут в управлении, подготовке и устранении неисправностей сети, состоящей из устройств Catalyst.

Схемы сетей

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

Рекомендация

Cisco рекомендует подготовить следующие три схемы:

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

  • Схема физических соединений — на ней отображаются все коммутаторы, маршрутизаторы и разводка кабелей. Необходимо нанести магистральные каналы, физические каналы, скорости, группы логических каналов, номера портов, слоты, типы корпусов, ПО, домены VTP, корневые мосты, приоритет резервных корневых мостов, MAC-адреса и заблокированные порты для виртуальных сетей. Часто бывает полезным нанесение на схему внутренних устройств, таких как MSFC Catalyst 6500/6000, как маршрутизатор в каскаде, подключенный при помощи магистрали;

    103e.gif

  • Логическая схема — содержит только функции уровня 3 (маршрутизаторы в виде объектов, виртуальные сети в виде сегментов Ethernet). Необходимо нанести IP-адреса, подсети, вторичная адресация, HSRP в активном и дежурном режимах, уровни доступа основного уровня распределения и сведения о маршрутизации.

    103f.gif

Внутриполосное управление

В зависимости от конфигурации интерфейсу внутриполосного (внутреннего) управления коммутатора (известному как sc0) может потребоваться обработка следующих данных:

  • Такие протоколы управления коммутатором, как SNMP, Telnet, Secure Shell Protocol (SSH) и системный журнал;

  • Пользовательские данные, как широковещательная и многоадресная рассылка;

  • Такие протоколы контроля коммутатора, как BPDU STP, VTP, DTP, CDP и другие.

Общепринятым для многоуровневой схемы Cisco является настройка управляющих виртуальных сетей, которые охватывают коммутируемые домены и содержат все интерфейсы sc0. Это помогает отделить управляющий трафик от пользовательского и повысить безопасность управляющих интерфейсов коммутатора. В данном разделе описана важность и потенциальные проблемы использования VLAN 1, настраиваемой по умолчанию, а также направление управляющего трафика в ту же виртуальную сеть, по которой передается пользовательский трафик.

Технологическое описание

Первым препятствием для использования VLAN 1 для пользовательских данных является то, что NMP Supervisor Engine нельзя прерывать интенсивным многоадресным и широковещательным трафиком, который генерируют конечные станции. У более старого оборудования Catalyst 5500/5000, Supervisor Engine I и Supervisor Engine II в частности, ресурсы для обработки трафика ограничены, однако ко всем Supervisor Engine применяется следующий принцип: если ЦП, буфер или внутренний канал к объединительной плате Supervisor Engine полностью занят прослушиванием ненужного трафика, возможна потеря управляющих кадров. В худшем случае это может привести к образованию петли связующего дерева или возникновению сбоя канала EtherChannel.

Если в Catalyst ввести команды show interface и show ip stats, то можно получить некоторое представление об отношении широковещательного и одноадресного трафика, а также об отношении трафика IP и не относящегося к IP (обычно не просматривается в управляющих VLAN).

Дальнейшая проверка работоспособности для более старого оборудования Catalyst 5500/5000 заключается в проверке выходных данных show inband | biga (скрытая команда) на наличие ошибок ресурсов (RscrcErrors), подобных потере буфера в маршрутизаторе. Если эти ошибки ресурсов повторяются постоянно, память не может принимать системные пакеты, возможно из-за значительного объема широковещательного трафика в управляющей VLAN. Одна ошибка ресурсов может обозначать, что Supervisor Engine не способен обработать пакет (например, BPDU), что в скором времени может превратиться в проблему, поскольку такие протоколы, как протокол связующего дерева не передает BPDU повторно.

Рекомендация

Как указано в разделе Протоколы уровня управления Catalyst данного документа, VLAN 1 представляет собой специальную виртуальную сеть, которая помечает и обрабатывает основную часть трафика уровня управления. По умолчанию VLAN 1 включена во всех магистральных каналах. В больших сетях необходимо следить за диаметром VLAN 1 Домен STP; нестабильность одной из частей сети может повлиять на работу VLAN 1, при этом повлиять на стабильность уровня управления и, как следствие, стабильность STP для всех остальных виртуальных сетей. В CatOS, начиная с версии 5.4, появилась возможность ограничения передачи пользовательских данных в VLAN 1 и запуска STP при помощи следующей команды:

clear trunk mod/port vlan 1

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

Примечание.  В настоящее время возможность устранения магистралей VLAN 1 в 3500s и 2900XLs отсутствует.

Даже когда в общей сети предприняты меры по ограничению пользовательских виртуальных сетей относительно небольшими коммутируемыми доменами и соответственно узкими границами сбоев/уровня 3, некоторые клиенты пытаются подойти к управляющей VLAN по-другому и покрыть всю сеть одной управляющей подсетью. Нет ни технических оснований для того, чтобы центральное приложение NMS было смежным на уровне 2 с устройствами, которыми оно управляет, ни каких-либо обоснованных возражений в отношении безопасности. Cisco рекомендует ограничивать диаметр управляющих VLAN теми же маршрутизируемыми доменами, в которых находятся пользовательские VLAN, а для увеличения надежности управления сетью рекомендуется использовать управление через выделенное подключение и/или поддержку SSH CatOS 6.x.

Другие параметры

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

Нет простого ответа на вопрос о том, создавать ли отдельную управляющую VLAN и разрешать ли использование магистралей для ее связывания между уровнем доступа на уровне 2 и распределительным уровнем на уровне 3. Есть два варианта конфигурации для проверки с инженером Cisco:

  • Вариант 1: соединить магистралью две или три уникальных VLAN с распределительного уровня с каждым коммутатором уровня доступа. Это позволяет организовать, например, VLAN для данных, VLAN для голосовых данных и управляющую VLAN и при этом пользоваться преимуществами неактивного STP. (Следует помнить, что если VLAN 1 удаляется из магистралей, то добавляется один шаг настройки.) В данном решении есть также вопросы конфигурации, которые следует учитывать для того, чтобы во время устранения неисправностей избежать исчезновения маршрутизируемого трафика: STP PortFast для магистральных каналов (CatOS, начиная с версии 7.x) или синхронизация VLAN Autostate с пересылкой STP (в версиях CatOS, начиная с 5.5[9]);

  • Вариант 2: приемлем вариант одной VLAN для данных и управления. При использовании более нового коммутирующего оборудования, более мощных ЦП и регуляторов скорости уровня управления, в сочетании с конфигурацией с относительно небольшими широковещательными доменами, как рекомендуется для многоуровневой конфигурации – теперь для большинства клиентов содержание интерфейса sc0 отдельно от пользовательских данных более не представляет проблему, как это было ранее. Решение выносится после исследования широковещательного трафика для этой VLAN и обсуждение возможностей коммутирующего оборудования с инженером по обслуживанию оборудования Cisco. Если управляющая VLAN действительно содержит всех пользователей в этом коммутаторе уровня доступа, крайне рекомендуется использовать фильтры IP на входе для защиты коммутатора от пользователей, как это описано в разделе Настройка безопасности данного документа.

Управление через выделенное подключение

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

  • Управление через выделенное подключение при помощи выделенной LAN;

  • Управление через выделенное подключение при помощи терминальных серверов.

Технологическое описание

Каждый маршрутизатор и коммутатор в сети может быть снабжен выделенным интерфейсом управления Ethernet в управляющей VLAN. Один порт Ethernet на каждом из устройств настроен в управляющей VLAN и подключен мимо основной сети к отдельной коммутирующей управляющей сети через интерфейс sc0. Следует помнить, что у коммутаторов Catalyst 4500/4000 в Supervisor Engine есть специальный интерфейс me1, который необходимо использовать только управления через выделенное подключение, но не как порт для коммутации.

Кроме того, к серверу терминала можно подключиться, настроив Cisco 2600 или 3600 при помощи кабелей для соединения порта RJ-45 с последовательным портом для доступа к консольным портам каждого маршрутизатора и коммутатора схемы. Использование терминального сервера также позволяет избежать настройки резервных способов подключения, таких как модемы на вспомогательных портах для каждого устройства. Один модем можно подключить к вспомогательному порту терминального сервера; этот модем обеспечит возможность соединения с другими устройствами при сбое в работе сети.

Рекомендация

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

  • Выделенное подключение отделяет управляющий трафик от пользовательских данных;

  • Для выделенного подключения используется управляющий IP-адрес из отдельной подсети, VLAN, а также коммутатор для повышения безопасности;

  • Выделенное подключение обеспечивает более высокую надежность управления передачей данных при сбоях в сети;

  • При выделенном подключении в управляющей VLAN отсутствует активное связующее дерево. Резервирование не является критическим условием.

103g.gif

Испытания системы

Диагностика при загрузке

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

Технологическое описание

В зависимости от платформы и конфигурации оборудования при загрузке, а также при горячей замене платы в корпусе выполняются различные виды диагностики. Более высокий уровень диагностики приводит к обнаружению большего количества проблем но и к увеличению времени загрузки. Можно выбирать один из этих трех уровней диагностики POST (при всех тестах проверяется DRAM, ПЗУ, наличие кэша и его размер, а также выполняется их инициализация).

Технологическое описание

Обход

Отсутствует

3

Не доступно в серии 4500/4000 с CatOS до версии 5.5.

Минимальная

Проверка записи шаблона только в первый мегабайт DRAM.

30

По умолчанию в сериях 5500/5000 и 6500/6000; недоступно в серии 4500/4000.

Полная

Проверочная запись шаблонов во всю память.

60

По умолчанию в серии 4500/4000.

Оперативная диагностика

С помощью данных тестов осуществляется внутренняя проверка маршрутов пакетов в коммутаторе. Следует отметить, что именно поэтому оперативная диагностика относится к общесистемным тестам, а не просто к тестам портов. В коммутаторах Catalyst 5500/5000 и 6500/6000 тесты выполняются начиная с резервного Supervisor Engine, а затем проводятся в основном Supervisor Engine. Длительность диагностики зависит от конфигурации системы (числа слотов, модулей, портов). Существуют три категории тестов:

  • Петлевая проверка — пакеты из NMP Supervisor Engine передаются на все порты, затем возвращаются в NMP и проверяются на наличие ошибок;

  • Проверка группирования — создаются логические каналы из портов, которых может быть до восьми, после чего выполняются петлевые проверки агрегированного порта с целью проверки распределения по конкретным соединениям (дополнительную информацию см. в разделе Каналы EtherChannel данного документа);

  • Проверка логики распознавания закодированных адресов (EARL) — проверяются центральный Supervisor Engine и подсистемы перезаписи встроенных модулей Ethernet уровня 3. Перед отправкой проверочных пакетов из NMP через коммутационное оборудование на каждом модуле и обратно в NMP выполняется аппаратное создание записей пересылки и маршрутизируемых портов (для каждого типа протоколов инкапсуляции). Это справедливо для модулей PFC Catalyst 6500/6000 и более новых модулей.

Полная оперативная диагностика может занять около двух минут. При минимальной диагностике в модулях, отличных от Supervisor Engine, не выполняется проверка группирования или перезаписи. Этот вид диагностики занимает около 90 секунд.

Во время проверки памяти при обнаружении различий между записанными и считанными шаблонами состояние порта изменяется на faulty. Результаты этих проверок можно увидеть при вводе команды show test с номером проверяемого модуля:

>show test 9

Diagnostic mode: complete (mode at next reset: complete)

!--- Настройка конфигурации.

Module 9 : 4-port Multilayer Switch
Line Card Status for Module 9 : PASS
Port Status :
  Ports 1  2  3  4
  -----------------
        .  .  .  .
Line Card Diag Status for Module 9 (. = Pass, F = Fail, N = N/A)
 Loopback Status [Reported by Module 1] :
  Ports 1  2  3  4
  -----------------
        .  . F  .

!--- Неисправное.

 Channel Status :
  Ports 1  2  3  4 
  -----------------
        .  .  .  .

Рекомендация

Cisco рекомендует включать во всех коммутаторах полную проверку, которая обеспечивает наиболее полное обнаружение сбоев и предотвращение сбоев в обычных режимах работы.

Примечание. Это изменение не действует до следующей загрузки устройства. Чтобы включить полную диагностику, введите следующую команду:

set test diaglevel complete 

Другие параметры

В некоторых ситуациях быстрая загрузка может быть предпочтительнее, чем ожидание выполнения полной диагностики. Запуск системы зависит от других факторов и настроек, но в общем случае POST и оперативная диагностика увеличивают время запуска приблизительно на треть. При тестировании полностью заполненного девятислотового корпуса Supervisor Engine в Catalyst 6509 при полной диагностике общее время загрузки составляло около 380 секунд, при минимальной диагностике около 300 секунд, а при пропуске диагностики – всего 250 секунд. Для настройки обхода диагностики введите следующую команду:

set test diaglevel bypass

Примечание. Catalyst 4500/4000 принимает настройку минимальной диагностики, однако при этом все равно выполняется полная проверка. Возможно, на этой платформе режим минимальной проверки будет поддерживаться в будущем.

Текущая диагностика

После того как система начала работу, Supervisor Engine коммутатора выполняет различные виды контроля других модулей. Если модуль недоступен при передаче управляющих сообщений (последовательный протокол управления [SCP], работающий через выделенную управляющую шину), Supervisor Engine выполняет попытку перезапуска платы или другое соответствующее действие.

Технологическое описание

Supervisor Engine автоматически выполняет различные виды контроля; настройка для этого не требуется. Для Catalyst 5500/5000 и 6500/6000 выполняется контроль следующих компонентов коммутатора:

  • NMP при помощи самоконтроля;

  • Ошибки микросхемы Enhanced EARL;

  • Стандартный канал связи от Supervisor Engine до объединительной платы;

  • Модули при помощи сообщений проверки активности через выделенный канал (Catalyst 6500/6000);

  • Резервный Supervisor Engine следит за состоянием активного Supervisor Engine (Catalyst 6500/6000).

Обнаружение ошибок системы и аппаратного обеспечения

Технологическое описание

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

  • Внутренняя полоса связи;

  • Счетчик портов;

  • Память.

Когда включена данная функция и обнаруживается ошибка, коммутатор генерирует сообщение системного журнала. Сообщение информирует администратора о наличии проблем до того, как производительность понизится. В CatOS версий 6.4(16), 7.6(12), 8.4(2) и в следующих версиях режим для всех трех компонентов по умолчанию изменен с выключенного на включенное.

Внутренняя полоса связи

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

  • Зависание внутренней полосы связи;

  • Ошибки ресурсов;

  • Сбой внутренней полосы связи при загрузке.

При обнаружении сбоя проверки ping внутренней полосы связи функция также создает дополнительное сообщение системного журнала с фиксацией текущих значений скорости передачи (Tx) и приема (Rx) соединения внутренней полосы связи, загрузки ЦП и объединительной платы коммутатора. Данное сообщение позволяет правильно определить, произошло зависание внутренней полосы связи (отсутствие Tx/Rx) или перегрузка (слишком большие значения Tx/Rx). Эта дополнительная информация может помочь определить причину сбоев проверки ping внутренней полосы связи.

Счетчик портов

При включении данной функции она создает и запускает процесс отладки счетчиков портов. Счетчик портов периодически проверяет выбранные внутренние счетчики ошибок портов. Счетчики, которые опрашивает функция, определяются архитектурой линейной платы, а точнее микросхемами ASIC модуля. Центр технической поддержки или отдел инженерного проектирования Cisco могут воспользоваться данной информацией для устранения неисправностей. Эта функция не опрашивает счетчики ошибок FCS, CRC, выравнивания и карликовых пакетов, которые напрямую связаны с подключением к партнеру по соединению. Чтобы включить данную возможность, см. раздел Обработка ошибок каналов EtherChannel/физических каналов данного документа.

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

Счетчик портов не поддерживается платформой Catalyst 4500/4000.

Память

При включении данной функции выполняется фоновый контроль и обнаружение условий повреждений DRAM. Среди таких условий повреждений памяти:

  • Выделение;

  • Освобождение;

  • Выход за пределы диапазона;

  • Ошибки синхронизации.

Рекомендация

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

set errordetection inband enable

!--- Это значение используется по умолчанию в CatOS 6.4(16), 7.6(12), 8.4(2) и выше.


set errordetection portcounters enable

!--- Это значение используется по умолчанию в CatOS 6.4(16), 7.6(12), 8.4(2) и выше.


set errordetection memory enable

!--- Это значение используется по умолчанию в CatOS 6.4(16), 7.6(12), 8.4(2) и выше.

Чтобы убедиться, что обнаружение ошибок включено, введите следующие команды:

>show errordetection 

Inband error detection:                   enabled
Memory error detection:                   enabled
Packet buffer error detection:            errdisable
Port counter error detection:             enabled
Port link-errors detection:               disabled
Port link-errors action:                  port-failover
Port link-errors interval:                30 seconds

Обработка ошибок каналов EtherChannel/физических каналов

Технологическое описание

В CatOS, начиная с версии 8.4, добавлена новая функция, которая при сбоях выполняет автоматическое перенаправление трафика с одного порта канала EtherChannel на другой порт этого же канала EtherChannel. Когда в течение заданного промежутка времени для одного из портов логического канала происходит превышение заданного порогового значения, выполняются действия по переключению порта. Переключение порта выполняется только при наличии рабочего порта в канале EtherChannel. Если порт, в котором произошел сбой, является последним портом в канале EtherChannel, порт не переходит в состояние port-failover. Этот порт продолжает передавать трафик вне зависимости от типа возникающих ошибок. Один порт, не входящий в состав логического канала, не переходит в состояние port-failover. Когда в течение заданного промежутка времени происходит превышение порогового значения, эти порты переходят в состояние errdisable.

Данная функция доступна при вводе команды set errordetection portcounters. Отслеживаемые ошибки физических каналов основаны на трех счетчиках:

  • InErrors;

  • RxCRC (ошибки CRCAlignErrors);

  • TxCRC.

Чтобы отобразить значения счетчиков ошибок, введите в коммутаторе команду show counters. Ниже представлен пример:

>show counters 4/48

.......

32 bit counters

0  rxCRCAlignErrors           =          0
.......

6  ifInErrors                 =          0
.......

12 txCRC                      =          0

В таблице приведен список возможных параметров конфигураций и соответствующих состояний по умолчанию:

Параметры

По умолчанию

Глобальный

Выключен

Контроль RxCRC порта

Выключен

Контроль InErrors порта

Выключен

Контроль TxCRC порта

Выключен

Действие

Переключение порта

Интервал

30 секунд

Число выборок

3 последовательно

Нижнее пороговое значение

1000

Верхнее пороговое значение

1001

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

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

Присутствует риск случайного отключения порта при ошибке из-за непредвиденного однократного события. Для снижения подобного риска действия для порта предпринимаются, только когда состояние сохраняется для последовательного количества выборок. По умолчанию количество выборок равно 3, а допустимый диапазон можно менять от 1 до 255.

Пороговое значение – это абсолютное число, которое проверяется на основании интервала проверки ошибок физического канала. По умолчанию нижнее пороговое значение равно 1000, а допустимый диапазон можно менять от 1 до 65535. По умолчанию верхнее пороговое значение равно 1001. Когда в течение последовательного количества выборок достигается нижнее пороговое значение, отправляется сообщение системного журнала. Если в течение последовательного количества выборок достигается верхнее пороговое значение, отправляется сообщение системного журнала и выполняется отключение порта при ошибке или переключение порта.

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

Рекомендации

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

set errordetection link-errors enable

Кроме того, начинайте с установленных по умолчанию пороговых значений, интервала и параметров выборки. Используйте установленное по умолчанию действие, переключение порта.

Чтобы применить глобальные параметры для ошибок соединения к отдельным портам, введите следующие команды:

set port errordetection mod/port inerrors enable

set port errordetection mod/port rxcrc enable

set port errordetection mod/port txcrc enable

Чтобы проверить конфигурацию для ошибок соединения, можно ввести следующие команды:

show errordetection

show port errordetection {mod | mod/port}

Диагностика буфера пакетов Catalyst 6500/6000

В CatOS версий 6.4(7), 7.6(5) и 8.2(1) добавлена диагностика буфера пакетов Catalyst 6500/6000. Диагностика буфера пакетов, включенная по умолчанию, обнаруживает ошибки буфера пакетов, вызванные временными сбоями статического ПЗУ (SRAM). Обнаружение работает в следующих 48-портовых 10/100-мегабитных линейных модулях:

  • WS-X6248-RJ45;

  • WS-X6248-RJ21;

  • WS-X6348-RJ45;

  • WS-X6348-RJ21;

  • WS-X6148-RJ45;

  • WS-X6148-RJ21.

При возникновении условий сбоя 12 из 48 10/100-мегабитных портов остаются подключенными и могут испытывать случайные проблемы с подключением. Единственный способ обойти эти условия – выключить и включить питание линейного модуля.

Технологическое описание

Функция диагностики буфера пакетов проверяет данные, которые хранятся в определенной области буфера пакетов, чтобы определить, не повреждены ли они в результате временных сбоев SRAM. Если процесс считывает данные, отличные от записанных, он выполняет одно из двух возможных настраиваемых действий:

  1. По умолчанию выполняется отключение при ошибке порта линейной платы, в котором произошел сбой буфера.

  2. Вторая возможность – отключение и включение питания линейной платы.

Добавлено два сообщения системного журнала. Сообщения содержат предупреждения об отключении портов при ошибках или отключении и включении питания модуля из-за ошибок буфера пакетов:

%SYS-3-PKTBUFFERFAIL_ERRDIS:Packet buffer failure detected. Err-disabling port 5/1.
%SYS-3-PKTBUFFERFAIL_PWRCYCLE: Packet buffer failure detected. Power cycling module 5.

В CatOS версий, предшествующих 8.3 и 8.4, время выключения и включения питания линейной платы составляет от 30 до 40 секунд. В CatOS версий 8.3 и 8.4 добавлена функция быстрой загрузки Rapid Boot. Для уменьшения времени загрузки функция автоматически загружает микропрограмму в установленные линейные платы в процессе первой загрузки. Функция Rapid Boot позволяет сократить время выключения и включения питания приблизительно до 10 секунд.

Рекомендация

Cisco рекомендует оставить параметр errdisable, установленным по умолчанию. Данное действие оказывает минимальное влияние на работу сети при ее загрузке. Если возможно, для восстановления работы переведите физические каналы, проходящие через порты, отключенные при ошибках, на другие доступные порты коммутатора. Запланируйте выключение и включение питания линейной платы вручную во время окна обслуживания. Чтобы полностью вывести порт из состояния повреждения пакетов в буфере, введите команду reset module mod. Для включения параметра errdisable введите следующую команду:

set errordetection packet-buffer errdisable

!--- Это значение используется по умолчанию.

Дополнительный параметр

Поскольку для полного восстановления портов, в которых произошел сбой SRAM, требуется выключение и включение питания линейной платы, альтернативной возможностью является настройка параметра отключения и включения питания. Данный параметр полезен в условиях, когда нарушение сетевого обслуживания длительностью 30–40 секунд является приемлемым. Данное время требуется для полного выключения и включения питания линейного модуля и приведения его в рабочее состояние без функции Rapid Boot. Функция Rapid Boot может сократить время простоя сетевых сервисов с параметром выключения и включения питания до 10 секунд. Чтобы включить параметр выключения и включения питания, введите следующую команду:

set errordetection packet-buffer power-cycle

Диагностика буфера пакетов

Данная проверка выполняется только в коммутаторах Catalyst 5500/5000. Данная проверка предназначена для обнаружения сбоев аппаратного обеспечения коммутаторов Catalyst 5500/5000, в которых используются модули Ethernet с определенным аппаратным обеспечением, которое предусматривает связь со скоростью 10/100 Мбит/с между портами пользовательского оборудования и объединительной платой коммутатора. Поскольку они не в состоянии выполнить проверку CRC для кадров магистральных каналов, то, если во время работы буфера пакетов порта происходит сбой, это может привести к повреждению пакетов и ошибкам CRC. К сожалению это может привести к дальнейшему распространению кадров с нарушениями в сеть ISL Catalyst 5500/5000, что потенциально приводит к нарушениям уровня управления и в худшем случае к лавинам широковещательных пакетов.

Современные модули Catalyst 5500/5000 и другие платформы снабжены обновленной встроенной аппаратной проверкой ошибок, и им не требуется проверка буфера пакетов, поэтому в них отсутствует возможность настройки этой функции.

Линейные модули, в которых необходимо выполнять диагностику буфера пакетов: WS-X5010, WS-X5011, WS-X5013, WS-X5020, WS-X5111, WS-X5113, WS-X5114, WS-X5201, WS-X5203, WS-X5213/a, WS-X5223, WS-X5224, WS-X5506, WS-X5509, WS-U5531, WS-U5533 и WS-U5535.

Технологическое описание

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

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

Проверки по требованию выполняются в интенсивном режиме, чтобы их можно было выполнить в течение нескольких минут. Поскольку эти проверки активно работают с памятью пакетов, перед проведением проверки порты необходимо отключать в административном порядке. Чтобы выключить порты, введите следующую команду:

> (enable) test packetbuffer 4/1
Warning: only disabled ports may be tested on demand - 4/1 will be skipped.
> (enable) set port disable 4/1
> (enable) test packetbuffer 4/1
Packet buffer test started. Estimated test time: 1 minute.
%SYS-5-PKTTESTSTART:Packet buffer test started
%SYS-5-PKTTESTDONE:Packet buffer test done. Use 'show test' to see test results

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

>show test packetbuffer status


!--- При выполнении теста команда выдает 
!--- следующую информацию:

Current packet buffer test details
Test Type           : scheduled
Test Started        : 03:30:08 Jul 20 2001
Test Status         : 26% of ports tested
Ports under test    : 10/5,11/2
Estimated time left : 11 minutes

!--- Если тест не выполняется, 
!--- команда выдает следующую информацию:

Last packet buffer test details
Test Type           : scheduled
Test Started        : 03:30:08 Jul 20 2001
Test Finished       : 06:48:57 Jul 21 2001

Рекомендация

Cisco рекомендует использовать функцию плановой проверки буфера пакетов для систем Catalyst 5500/5000, поскольку преимущества обнаружения проблем в модулях превышают риск потери пакетов.

Стандартное еженедельное время необходимо спланировать во всей сети, что позволит пользователям при необходимости переключать соединения с неисправных портов или модулей RMA. Поскольку такая проверка может привести к потере некоторых пакетов в зависимости от загрузки сети, ее необходимо планировать на время с наименьшей нагрузкой, как время 3:30 утра в воскресенье, установленное по умолчанию. Чтобы задать время проверки, введите следующую команду:

set test packetbuffer Sunday 3:30

!--- Это значение используется по умолчанию.

После включения (как после первого обновления CatOS до версии начиная с 5.4) есть шанс обнаружения ранее скрытых проблем с памятью/аппаратным обеспечением и, как результат, автоматического выключения порта. Можно увидеть следующее сообщение:

%SYS-3-PKTBUFBAD:Port 1/1 failed packet buffer test

Другие параметры

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

test packetbuffer port range

Регистрация системы

Сообщения системного журнала специально создаются для оборудования Cisco и представляют собой ключевую часть упреждающего управления обработкой неисправностей. Системный журнал позволяет регистрировать более широкий ряд состояний сетей и протоколов, чем это позволяет стандартный протокол SNMP. Управляющие платформы, как, например, пакеты Cisco Resource Manager Essentials (RMEs) и Network Analysis Toolkit (NATkit) эффективно используют информацию системного журнала, поскольку они выполняют следующие задачи:

  • Выполняют анализ по серьезности ошибок, сообщениям, устройствам и так далее;

  • Включение фильтрации сообщений, поступающих для анализа;

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

Рекомендация

Важным моментом является уровень регистрации информации, создаваемой локально и хранимой в буфере коммутатора, и информации, передаваемой на сервер системного журнала (при помощи команды set logging server severity value). В одних организациях поддерживается высокий уровень централизованной регистрации информации, а в других вход на сам коммутатор выполняется для проверки подробной информации о событии или включения более высокого уровня регистрации информации в системном журнале только на время устранения неисправностей.

В платформах CatOS устранение неисправностей выполняется не так, как в ПО Cisco IOS, однако подробную регистрацию системной информации на время сеанса, не изменяя информацию, регистрируемую по умолчанию, можно включить при помощи команды set logging session enable.

В общем случае Cisco рекомендует перевести связующее дерево и функции системного журнала на уровень 6, поскольку это ключевые функции обеспечения стабильности, за которыми необходимо следить. Кроме того, для сред многоадресной рассылки рекомендуется включение регистрации функции mcast до уровня 4, чтобы при удалении портов маршрутизатора создавались сообщения системного журнала. К сожалению, в версиях CatOS, предшествующих 5.5(5), это может привести к возникновению сообщений системного журнала, записываемых для освобождения и объединения IGMP, и созданию большого количества лишней для контроля информации. В заключение, при использовании списков входящих IP рекомендуется использовать уровень регистрации не ниже 4, чтобы регистрировать попытки несанкционированного входа. Чтобы установить следующие параметры, введите такие команды:

set logging buffer 500

!--- Это значение используется по умолчанию.

set logging server syslog server IP address
set logging server enable

!--- Это значение используется по умолчанию.

set logging timestamp enable
set logging level spantree 6 default

!--- Увеличьте стандартный уровень регистрации STP системного журнала.

set logging level sys 6 default

!--- Увеличьте уровень регистрации по умолчанию системного журнала.

set logging server severity 4

!--- Это значение используется по умолчанию;
!--- оно ограничивает сообщения, экспортируемые на сервер системного журнала.

set logging console disable

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

В таблице перечислены функции регистрации, уровни по умолчанию и рекомендуемые изменения для Catalyst 6500/6000. У всех платформ службы немного различаются в зависимости от поддерживаемых функций.

Служба

Уровень по умолчанию

Рекомендуемое действие

acl

5

Не менять.

cdp

4

Не менять.

cops

3

Не менять.

dtp

8

Не менять.

earl

2

Не менять.

ethc1

5

Не менять.

filesys

2

Не менять.

gvrp

2

Не менять.

ip

2

При использовании списков входящих IP установите значение 4.

kernel

2

Не менять.

1d

3

Не менять.

mcast

2

При использовании многоадресной рассылки установите уровень 4 (CatOS начиная с версии 5.5[5]).

mgmt

5

Не менять.

mls

5

Не менять.

pagp

5

Не менять.

protfilt

2

Не менять.

pruning

2

Не менять.

Privatevlan

3

Не менять.

qos

3

Не менять.

radius

2

Не менять.

rsvp

3

Не менять.

security

2

Не менять.

snmp

2

Не менять.

spantree

2

Измените на 6.

sys

5

Измените на 6.

tac

2

Не менять.

tcp

2

Не менять.

telnet

2

Не менять.

Tftp

2

Не менять.

UDLD

4

Не менять.

VMPS

2

Не менять.

VTP

2

Не менять.

1 В CatOS, начиная с версии 7.x, код службы ethc заменяет код службы pagp, отражая поддержку LACP.

Примечание. В настоящее время коммутаторы Catalyst для каждой выполненной команды set или clear сохраняют сообщение изменения конфигурации уровня 6, в отличие от ПО Cisco IOS, которое создает сообщение только при выходе из режима настройки. Если для резервного копирования настроек в режиме реального времени по этому событию требуется RMEs, эти сообщения также необходимо отправлять на сервер системных сообщений RMEs. Большинству клиентов достаточно периодического резервного копирования конфигурации для коммутаторов Catalyst, и изменение установленного по умолчанию уровня регистрации не требуется.

При настройке предупреждений NMS рекомендуется ознакомиться с Руководством по системным сообщениям.

Протокол SNMP (простой протокол управления сетью)

SNMP используется для извлечения статистики, таблиц и значений счетчиков, сохраняемых в базах управляющей информации (MIB) сетевых устройств. Собранную информацию можно использовать в NMS (таких, как HP Openview) для генерирования предупреждений в режиме реального времени, оценки доступности и создания информации планирования производительности, а также для помощи при проверке конфигурации и устранении неисправностей.

Технологическое описание

При использовании некоторых механизмов защиты станция управления сетью может извлекать информацию из MIB при помощи запросов get и get next протокола SNMP и изменять параметры при помощи команды set. Кроме того, сетевое устройство можно настроить на генерирование сообщений trap (ловушек) для NMS для получения уведомлений в режиме реального времени. Для опроса SNMP используется порт 161 IP UDP, а для сообщений trap SNMP используется порт 162.

Cisco поддерживает следующие версии SNMP:

  • SNMPv1: стандарт Интернет RFC 1157, использующий защиту строк сообщества открытого текста. Список контроля доступа по IP-адресам и пароли определяют группу управляющих, которые могут получать доступ к агенту MIB;

  • SNMPv2C: комбинация из SNMPv2, проекта Интернет-стандарта, определенного в RFC с 1902 по 1907 и SNMPv2C, административной инфраструктуры SNMPv2 для сообществ, которая представляет собой экспериментальный проект, описанный в RFC 1901. К числу преимуществ следует отнести механизм группового извлечения, позволяющий извлекать таблицы и большие объемы данных за минимальное число циклов приема-передачи, а также улучшенную обработку ошибок;

  • SNMPv3: Проект, предлагаемый RFC 2570, обеспечивает безопасный доступ к устройствам посредством сочетания аутентификации и шифрования пакетов в сети. В SNMPv3 реализованы следующие функции защиты:

    • Целостность сообщений: обеспечивает неизменность пакетов в пути;

    • Аутентификация: определяет происхождение сообщения из надежного источника;

    • Шифрование: шифрует содержимое пакета, предотвращая его простое прочтение посторонними лицами.

В таблице приведены комбинации моделей безопасности:

Уровень модели

Аутентификация

Шифрование

Результат

Версия 1

noAuthNoPriv, Community String

Нет

При проверке подлинности используется совпадение строки группы.

Версия 2c

noAuthNoPriv, Community String

Нет

При проверке подлинности используется совпадение строки группы.

Версия 3

noAuthNoPriv, Username

Нет

Для аутентификации используется совпадение имени пользователя.

Версия 3

authNoPriv, MD5 или SHA

Нет

Обеспечивает аутентификацию на основе алгоритмов HMAC-MD5 или HMAC-SHA.

Версия 3

authPriv, MD5 или SHA

DES

Обеспечивает аутентификацию на основе алгоритмов HMAC-MD5 или HMAC-SHA. Кроме аутентификации обеспечивает 56-битное шифрование DES на основе стандарта CBC-DES (DES-56).

Примечание. Необходимо помнить следующую информацию об объектах SNMPv3:

  • Каждый пользователь относится к группе;

  • Группа определяет политику доступа для множества пользователей;

  • Политика доступа определяет доступ на чтение, запись и создание объектов SNMP;

  • Группа определяет список уведомлений, которые могут получать ее пользователи;

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

Рекомендации по сообщениям SNMP Trap

Протокол SNMP является основой всей системы управления сетью - он включается и используется во всех сетях. Агент SNMP в коммутаторе должен быть настроен для использования версии SNMP, поддерживаемой станцией управления. Поскольку агенты могут связываться с несколькими диспетчерами, можно, например, настроить программное обеспечения на поддержку связи с одной управляющей станцией при помощи протокола SNMPv1 и с другими при помощи протокола SNMPv2.

На сегодняшний день большинство станций NMS использует SNMPv2C в следующей конфигурации:

set snmp community read-only string


!--- Разрешите просмотр только переменных.


set snmp community read-write string


!--- Разрешите настройку переменных.


set snmp community read-write-all string<string>

!--- Включите настройку SNMP строк. 

Cisco рекомендует включить сообщения SNMP traps для всех используемых функций (неиспользуемые функции можно отключить). После включения сообщений trap их можно протестировать с помощью команды test snmp и подходящего обработчика, установленного на NMS для ошибки (таких, как предупреждение на пейджер или всплывающее сообщение).

По умолчанию все сообщения trap отключены и их необходимо добавлять в конфигурацию либо по отдельности, либо с параметром all, как показано ниже:


set snmp trap enable all
set snmp trap server address read-only community string

Доступные сообщения trap в CatOS 5.5:

Сообщение trap

Описание

auth

Аутентификация

bridge

Мост

chassis

Шасси

config

Конфигурация

entity

Объект

ippermit

Разрешение IP

module

Модуль

repeater

Повторитель

stpx

Расширение связующего дерева

syslog

Уведомление системного журнала

vmps

Сервер политик участия в VLAN

vtp

Протокол магистральных каналов VLAN

Примечание. Trap системного журнала пересылает все сообщения системного журнала, создаваемые коммутатором, в NMS также в виде сообщения trap SNMP. Если создание уведомлений системного журнала уже выполняется анализатором, таким, как Cisco Works 2000 RMEs, то нет необходимости в повторном получении этой информации.

В отличие от ПО Cisco IOS, сообщения trap SNMP уровня порта отключены по умолчанию, поскольку в коммутаторах могут быть сотни активных интерфейсов. Поэтому Cisco рекомендует включать SNMP-ловушки на уровне порта для ключевых портов, например соединений инфраструктуры маршрутизаторов, коммутаторов и основных серверов. Другие порты, например порты узлов пользователей, не требуются, что помогает упростить управление сетью.

set port trap port range enable

!--- Включите только на ключевых портах.

Рекомендации по опросам SNMP

Для подробного обсуждения определенных потребностей рекомендуется проанализировать управление сетью. Ниже изложено несколько основных принципов Cisco по управлению большими сетями:

  • Делая просто, делайте хорошо;

  • Сократите лишнюю нагрузку на персонал, возникающую в результате чрезмерного опроса, сбора данных, использования инструментов и ручного анализа;

  • Управлять сетью можно при помощи всего нескольких инструментов, таких как HP Openview в качестве NMS, Cisco RMEs в качестве диспетчера настройки, системного журнала, оборудования и программного обеспечения, Microsoft Excel в качестве анализатора данных NMS и CGI в качестве средства публикации этих данных в Интернет;

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

  • Определите, что в сети работает хорошо, и не трогайте это. Сосредоточьтесь на том, что не работает.

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

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

Вторая фаза организации NMS – более подробный опрос определенных участков сети при помощи SNMP. Среди них сомнительные участки, участки перед изменениями или участки, работающие исправно. Используйте системы NMS в качестве прожектора, который поможет подробно осмотреть сеть и осветить очаги опасности (не пытайтесь осветить всю сеть).

Группа Cisco Network Management Consulting рекомендует анализировать или контролировать в общей сети следующие ключевые MIB ошибок. Дополнительные сведения (например, об опросе производительности MIB (база управляющей информации) см. в документе Инструкции Cisco по мониторингу сети и взаимосвязи событий.

Имя объекта

Описание объекта

Идентификатор объекта (OID)

Интервал опроса

Пороговое значение

MIB-II

sysUpTime

время работы системы в сотых долях секунды

1.3.6.1.2.1.1.3

5 мин

<30000

Имя объекта

Описание объекта

Идентификатор объекта (OID)

Интервал опроса

Пороговое значение

CISCO-PROCESS-MIB

cpmCPUTotal5min

Общий процент загрузки ЦП в течение последних 5 минут

1.3.6.1.4.1.9.9.109.1.1.1.1.5

10 мин

Базовое значение

Имя объекта

Описание объекта

Идентификатор объекта (OID)

Интервал опроса

Пороговое значение

CISCO-STACK-MIB

sysEnableChassisTraps

Указывает, будут ли в данной MIB создаваться прерывания chassisAlarmOn и chassisAlarmOff.

1.3.6.1.4.1.9.5.1.1.24

24 часа

1

sysEnableModuleTraps

Указывает, будут ли в данной MIB создаваться ловушки moduleUp и moduleDown.

1.3.6.1.4.1.9.5.1.1.25

24 часа

1

sysEnableBridgeTraps

Указывает, будут ли в BRIDGE-MIB (RFC 1493) создаваться прерывания newRoot и topologyChange.

1.3.6.1.4.1.9.5.1.1.26

24 часа

1

sysEnableRepeaterTraps

Указывает на необходимость создания ловушек в REPEATER-MIB (RFC1516).

1.3.6.1.4.1.9.5.1.1.29

24 часа

1

sysEnableIpPermitTraps

Указывает, будут ли создаваться в данной MIB ловушки IP permit.

1.3.6.1.4.1.9.5.1.1.31

24 часа

1

sysEnableVmpsTraps

Указывает, должно ли быть создано прерывание vmVmpsChange, определенное в CISCO- VLAN-MEMBERSHIP-MIB.

1.3.6.1.4.1.9.5.1.1.33

24 часа

1

sysEnableConfigTraps

Указывает, будет ли в данной MIB создаваться прерывание sysConfigChange.

1.3.6.1.4.1.9.5.1.1.35

24 часа

1

sysEnableStpxTrap

Указывает, будет ли в CISCO-STP-EXTENSIONS-MIB создаваться прерывание stpxInconsistencyUpdate.

1.3.6.1.4.1.9.5.1.1.40

24 часа

1

chassisPs1status

Состояние питания 1.

1.3.6.1.4.1.9.5.1.2.4

10 мин

2

chassisPs1TestResult

Подробная информация о состоянии питания 1.

1.3.6.1.4.1.9.5.1.2.5

По необходимости.

 

chassisPs2Status

Состояние питания 2.

1.3.6.1.4.1.9.5.1.2.7

10 мин

2

chassisPs2TestResult

Подробная информация о состоянии питания 2

1.3.6.1.4.1.9.5.1.2.8

По необходимости.

 

chassisFanStatus

Состояние вентилятора шасси.

1.3.6.1.4.1.9.5.1.2.9

10 мин

2

chassisFanTestResult

Подробная информация о состоянии вентилятора шасси.

1.3.6.1.4.1.9.5.1.2.10

По необходимости.

 

chassisMinorAlarm

Состояние вспомогательной сигнализации шасси.

1.3.6.1.4.1.9.5.1.2.11

10 мин

1

chassis MajorAlarm

Состояние основной сигнализации шасси

1.3.6.1.4.1.9.5.1.2.12

10 мин

1

chassisTempAlarm

Состояние сигнализации температуры шасси.

1.3.6.1.4.1.9.5.1.2.13

10 мин

1

moduleStatus

Рабочее состояние модуля.

1.3.6.1.4.1.9.5.1.3.1.1.10

30 мин

2

moduleTestResult

Подробная информация о состоянии модулей.

1.3.6.1.4.1.9.5.7.3.1.1.11

По необходимости.

 

moduleStandbyStatus

Состояние вспомогательного модуля.

1.3.6.1.4.1.9.5.7.3.1.1.21

30 мин

=1 или =4

Имя объекта

Описание объекта

Идентификатор объекта (OID)

Интервал опроса

Пороговое значение

CISCO-MEMORY-POOL-MIB

dot1dStpTimeSinceTopologyChange

Время (в сотых долях секунды) с момента обнаружения объектом последнего изменения топологии.

1.3.6.1.2.1.17.2.3

5 мин

<30000

dot1dStpTopChanges

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

1.3.6.1.2.1.17.2.4

По необходимости.

 

dot1dStpPortState [1]

Текущее состояние порта, определенное путем применения протокола связующего дерева. Возвращаемое значение может быть следующим: disabled (1), blocking (2), listening (3), learning (4), forwarding (5) или broken (6).

1.3.6.1.2.1.17.2.15.1.3

По необходимости.

 

Имя объекта

Описание объекта

Идентификатор объекта (OID)

Интервал опроса

Пороговое значение

CISCO-MEMORY-POOL-MIB

ciscoMemoryPoolUsed

Число байтов из пула памяти, используемых в текущий момент на управляющем устройстве.

1.3.6.1.4.1.9.9.48.1.1.1.5

30 мин

Базовое значение

ciscoMemoryPoolFree

Число байтов из пула памяти, не используемых в текущий момент на управляющем устройстве.

Примечание: Сумма ciscoMemoryPoolUsed и ciscoMemoryPoolFree составляет общее количество памяти в пуле.

1.3.6.1.4.1.9.9.48.1.1.1.6

30 мин

Базовое значение

ciscoMemoryPoolLargestFree

Размер максимальной непрерывной области пула памяти, не используемой в текущий момент на управляемом устройстве.

1.3.6.1.4.1.9.9.48.1.1.1.7

30 мин

Базовое значение

Дополнительную информацию по поддержке Cisco MIB см. в документе Cisco Network Management Toolkit - MIBs.

Примечание. Некоторые стандартные MIB предполагают, что определенный объект SNMP содержит только один экземпляр MIB. Поэтому у стандартных MIB нет списка, позволяющего пользователям получать прямой доступ к определенному экземпляру MIB. В таких случаях для доступа к каждому из экземпляров стандартного MIB обеспечивается индексация строки сообщества. Синтаксис: [строка сообщества]@[номер экземпляра], где экземпляром, как правило, является номер VLAN.

Другие параметры

Аспекты безопасности протокола SNMPv3 означают, что со временем он заменит SNMPv2. Cisco рекомендует своим клиентам подготовиться к внедрению данного нового протокола как части их стратегии NMS. Преимуществом является то, что данные можно безопасно забирать с устройств SNMP без угрозы их изменения или повреждения. Конфиденциальную информацию, такую, как пакеты команды set SNMP, изменяющие конфигурацию коммутатора, можно шифровать, предотвращая просмотр их содержимого в сети. Кроме того, у различных групп пользователей могут быть различные привилегии.

Примечание. Конфигурация SNMPv3 значительно отличается от командной строки SNMPv2 и ожидается увеличенная нагрузка на ЦП Supervisor Engine.

Удаленный контроль

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

Результаты обработки удаленного мониторинга RMON хранятся в базах управляющей информации RMON MIB для последующего сбора станцией NMS, как описано в RFC 1757 leavingcisco.com.

Технологическое описание

Коммутаторы Catalyst аппаратно поддерживают на каждом порту протокол mini-RMON, состоящий из четырех групп RMON-1: Статистика (группа 1), История (группа 2), Предупреждения (группа 3) и События (группа 9).

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

Настройку порогов лучше всего проводить с помощью пакета управления RMON, поскольку успешное создание строк параметров в таблицах предупреждений и событий является трудоемким процессом. Коммерческие пакеты NMS RMON, как, например, Cisco Traffic Director, входящий в пакет Cisco Works 2000, содержат графический интерфейс пользователя, который существенно упрощает настройку пороговых значений RMON.

Для целей базовых значений группа etherStats предоставляет полезный диапазон статистики трафика уровня 2. Объекты этой таблицы можно использовать для получения статистики по одноадресному, многоадресному и широковещательному трафику и статистики по различным ошибкам уровня 2. Агент RMON на коммутаторе также можно настроить для хранения этих выборочных значений в группе журналов. Этот механизм позволяет уменьшить количество опросов без уменьшения частоты опроса. При помощи записей журнала RMON можно получить точные базовые значения без существенной перегрузки в виде опросов. Однако чем больше информации собирается, тем больше используется ресурсов коммутатора.

В то время как коммутаторы содержит только четыре основных группы RMON-1, важно не забыть об остальных группах RMON-1 и RMON-2. Все группы, включая UsrHistory (группа 18) и ProbeConfig (группа 19), описаны в RFC 2021. Информацию уровня 3 и более высоких уровней можно получать из коммутаторов при помощи функций порта SPAN или перенаправления ACL VLAN, которые позволяют копировать трафик во внешний SwitchProbe RMON или внутренний модуль анализа сети (NAM).

NAM поддерживают все группы RMON и даже могут проверять данные прикладного уровня, включая данные Netflow, экспортируемые из Catalysts при включении MLS. В случае запуска MLS маршрутизатор выполняет коммутацию не всех пакетов в потоке, поэтому только счетчики экспорта данных NetFlow, а не счетчики интерфейсов обеспечивают надежный учет VLAN.

Для захвата потока пакетов для определенного порта, магистрального канала или VLAN можно использовать порт SPAN и средство захвата информации коммутатора и загружать пакеты для раскодирования при помощи пакета управления RMON. Порт SPAN контролируется SNMP через группу SPAN в CISCO-STACK-MIB, поэтому этот процесс легко автоматизировать. Traffic Director использует эти функции при помощи функции агента roving.

Следует быть осторожным при охвате всей VLAN. Даже при использовании средства захвата, работающего со скоростью 1 Гбит/с, весь поток пакетов одной VLAN или даже один полнодуплексный порт, работающий со скоростью 1 Гбит/с, может превысить полосу пропускания порта SPAN. Если порт SPAN постоянно работает на всю ширину полосы пропускания, есть шансы потери данных. Для получения дополнительных сведений обратитесь к документу Настройка анализатора коммутированных портов (SPAN) Catalyst.

Рекомендация

Cisco рекомендует в дополнение к опросам SNMP использовать пороговые значения и предупреждения RMON для управления сетью на более высоком уровне. За счет этого снижается объем передаваемого служебного трафика и достигается интеллектуальное оповещение при изменении базовых параметров сети. RMON должен работать под управлением внешнего агента, такого, как Traffic Director. Поддержка интерфейса командной строки отсутствует. Для включения RMON введите следующую команду:

set snmp rmon enable
set snmp extendedrmon netflow enable mod


!--- Для использования только с модулем NAM.

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

Требования к памяти

Для ведения статистики, журналирования, предупреждений и событий RMON использует одинаковое для всех платформ коммутаторов количество памяти. Для хранения журналов и статистических данных в агенте RMON (в данном случае это коммутатор) протокол RMON использует сегмент памяти. Размер участка памяти определяется устройством захвата RMON (устройство захвата коммутатора) или приложением RMON (диспетчер трафика), а затем отсылается для сохранения в коммутаторе. Обычно ограничения памяти следует учитывать только в старых Supervisor Engines, размер памяти DRAM которых составляет менее 32 Мб. Следуйте этим рекомендациям:

  • Для поддержки mini-RMON (который представляет собой четыре группы RMON: статистика, журнал, предупреждения и события) в образ NMP добавляется около 450 Кб пространства для кода. Требования к динамической памяти для RMON меняются, поскольку зависят от конфигурации в процессе выполнения. Ниже приведена информация по использованию памяти для RMON в процессе работы для каждой из групп mini-RMON:

    • Группа Ethernet Statistics — требует 800 байт для каждого коммутируемого интерфейса Ethernet/FE;

    • Группа History — каждая настроенная для интерфейса Ethernet управляющая запись журнала с 50 сегментами памяти занимает около 3,6 Кб памяти и 56 байт для каждого дополнительного сегмента;

    • Группа Alarms and Events — занимает 2,6 Кб для каждого настроенного предупреждения и соответствующих ему записей событий.

  • Сохранение относящейся к RMON конфигурации занимает около 20 Кб энергонезависимого ПЗУ, если общий размер энергонезависимого ПЗУ системы равен 256 Кб или больше, и 10 Кб энергонезависимого ПЗУ, если общий размер энергонезависимого ПЗУ равен 128 Кб.

Протокол сетевого времени

NTP, RFC 1305 leavingcisco.com, синхронизирует время в ряде распределенных клиентов и серверов времени и позволяет сопоставлять события при создании системных журналов или возникновении других событий, происходящих в определенное время.

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

Технологическое описание

Впервые протокол NTP был описан в RFC 958 leavingcisco.com и был развит в RFC 1119 (NTP версии 2), а теперь в RFC 1305 leavingcisco.com описана его третья версия. Он работает через порт 123 UDP. Все соединения NTP используют формат всемирного координированного времени (UTC), аналогичного гринвичскому времени.

Доступ к общедоступным серверам времени

Подсеть NTP в настоящее время содержит более 50 общедоступных основных серверов, синхронизированных напрямую c всемирным скоординированным временем (UTC) с помощью радио, спутниковой связи или модема. Обычно клиентские рабочие станции и серверы со сравнительно небольшим числом клиентов не синхронизируются с основными серверами. Существует около 100 общедоступных вспомогательных серверов, синхронизированных с основными серверами, что обеспечивает синхронизацию со 100 000 клиентов и серверов в Интернете. Текущие списки находятся на странице списка общедоступных серверов NTP, которая регулярно обновляется. Существует также целый ряд частных основных и вспомогательных серверов, которые недоступны широким массам пользователей. Список общедоступных серверов NTP и информацию по их использованию можно найти на Интернет-странице Сервер синхронизации времени leavingcisco.com университета штата Делавэр.

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

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

Уровень

Для каждого сервера NTP используется уровень, указывающий удаленность сервера времени от внешнего источника. У серверов уровня 1 есть доступ к некоторым типам внутренних источников синхронизации, например радиочасам. Серверы уровня 2 получают подробные данные о времени от выделенных серверов уровня 1, а серверы уровня 3 получают подробные данные о времени от серверов уровня 2 и так далее.

Равноправные отношения с серверами

  • Сервер только отвечает на запросы клиентов, но не пытается получить какую-либо информацию о времени с источника времени клиента.

  • Равноправный сервер отвечает на запросы клиентов, однако пытается использовать запросы клиентов в качестве потенциальных источников более правильного времени и для стабилизации своей синхронизации.

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

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

    Примечание. CatOS может выступать только в качестве NTP-клиента.

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

Опрос

Протокол NTP разрешает клиенту посылать запрос на сервер в любое время. Фактически при первой настройке NTP в устройстве Cisco оно быстро отправляет восемь запросов подряд с интервалом NTP_MINPOLL (24 = 16 секунд). Значение NTP_MAXPOLL составляет 214 секунд (что составляет 16384 секунды или 4 часа, 33 минуты, 4 секунды), максимальное время до повторного опроса NTP для получения ответа. В настоящее время в Cisco пользователь не может вручную настраивать время POLL.

Счетчик опроса NTP запускается через 26 (64) секунды и возрастает как степень двойки (поскольку два сервера синхронизируются между собой) до 210. То есть, сообщения синхронизации будут отправляться с интервалами 64, 128, 256, 512 и 1024 секунд для каждого настроенного сервера или равноправного узла. Время варьируется между 64 и 1024 секундами как степень двойки на основании синфазной петли, которая посылает и принимает пакеты. При наличии большого отклонения во времени опрос производится чаще. Если эталонные часы являются точными, а сетевое соединение постоянным, можно видеть, что время между опросами будет доходить до 1024 секунд.

В реальных условиях это означает, что интервал опроса NTP изменяется, поскольку изменяется соединение между клиентом и сервером. Чем лучше соединение, тем дольше будет интервал опроса, что означает, что NTP-клиент получил 8 ответов на 8 своих последних запросов (после чего интервал опроса будет удвоен). Один пропущенный ответ приведет к сокращению интервала опроса вдвое. Интервал опроса начинается с 64 секунд и достигает максимального значения в 1024 секунд. В оптимальных условиях для увеличения интервала опроса с 64 секунд до 1024 секунд потребуется немногим более 2 часов.

Широковещательные пакеты

Широковещательные пакеты NTP никогда не пересылаются. По команде ntp broadcast маршрутизатор начнет широковещательную рассылку пакетов NTP через интерфейс, в котором она настроена. По команде ntp broadcast client маршрутизатор переключится на прослушивание пакетов широковещательной рассылки NTP на интерфейсе, на котором оно настроена.

Уровни трафика NTP

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

Один NTP-клиент использует скорость примерно 0,6 бит/с сервера.

Рекомендация

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

Использование адресов обратной связи в качестве источника обновления позволяет повысить согласованность. Возникают следующие два вопроса в отношении безопасности:

  • Фильтрация обновлений серверов;

  • Аутентификация.

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

Cisco рекомендует использовать следующие настройки:

Настройка Catalyst

set ntp broadcastclient enable
set ntp authentication enable
set ntp key key                    

!--- Хеш-значение Message Digest 5 (MD5).

set ntp timezone <zone name>
set ntp summertime <date change details>

Альтернативная настройка Catalyst


!--- Данная более привычная конфигурация требует
!--- больше работы по настройке и больше равноправных связей NTP.

set ntp client enable
set ntp server IP address of time server
set timezone zone name
set summertime date change details

Настройка маршрутизатора


!--- Это пример конфигурации маршрутизатора для распространения
!--- широковещательной информации NTP клиентам широковещательной рассылки Catalyst.

ntp source loopback0
ntp server IP address of time server
ntp update-calendar
clock timezone zone name
clock summer-time date change details ntp authentication key key
ntp access-group access-list


!--- Для фильтрования обновлений и разрешения только доверенных источников информации NTP.

Interface to campus/management VLAN containing switch sc0
        ntp broadcast

Протокол обнаружения CDP (Cisco Discovery Protocol)

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

Технологическое описание

Для CDP используется инкапсуляция SNAP с кодом типа 2000. В Ethernet, ATM и FDDI используется адрес назначения многоадресной рассылки 01-00-0c-cc-cc-cc, тип протокола HDLC 0x2000. В устройствах Token Ring используется функциональный адрес c000.0800.0000. Кадры CDP отправляются периодически, по умолчанию каждую минуту.

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

CDP версии 1 поддерживает следующие параметры:

Параметр

Тип

Описание

1

Идентификатор устройства

Имя узла устройства или серийный номер аппаратного обеспечения в кодировке ASCII.

2

Адрес

Адрес уровня 3 интерфейса, передавшего обновление.

3

Идентификатор порта

Порт, на который было передано обновление CDP.

4

Возможности

Описание функциональных возможностей устройства:

Маршрутизатор: 0x01 TB-мост: 0x02 SR-мост: 0x04 Коммутатор: 0x08 (обеспечивает коммутацию уровней 2 и/или 3) Узел: 0x10 условное фильтрование IGMP: 0x20 Мост или коммутатор не пересылают пакеты отчетов IGMP на немаршрутизируемые порты. Повторитель: 0x40

5

Версия

Строка символов, содержащая версию ПО (как в результате команды show version).

6

Платформа

Аппаратная платформа, например WS-C5000, WS-C6009 или Cisco RSP.

В CDP версии 2 добавлены дополнительные поля протокола. Вторая версия CDP поддерживает любые поля, но перечисленные поля могут быть особенно полезными в коммутируемых средах и используются в CatOS.

Примечание. Следует отметить, что когда в коммутаторе работает CDPv1, он сбрасывает кадры v2. Когда коммутатор, работающий с CDPv2, получает на интерфейс кадры CDPv1, он в дополнение к кадрам CDPv2 начинает передачу кадров CDPv1 из этого интерфейса.

Параметр

Тип

Описание

9

Домен VTP

Домен VTP, если он настроен в устройстве.

10

Собственная VLAN

В dot1q это непомеченная VLAN.

11

Полнодуплексная и полудуплексная связь

Это поле содержит настройки дуплексного режима посылающего порта.

Рекомендация

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

set cdp enable

!--- Это значение используется по умолчанию.

set cdp version v2

!--- Это значение используется по умолчанию.

В сегментах сети, в которых требуется высокий уровень безопасности (например, демилитаризованные зоны, подключенные к Интернету), необходимо отключить CDP следующим образом:

set cdp disable port range

Команда show cdp neighbors отображает локальную таблицу CDP. Записи, помеченные звездочкой (*), обозначают несоответствие VLAN, записи, помеченные #, обозначают несовпадение дуплексных режимов. Эта информация может очень помочь при устранении неисправностей.

>show cdp neighbors

* - indicates vlan mismatch.
# - indicates duplex mismatch.
Port  Device-ID          Port-ID Platform
----- ------------------ ------- ------------
 3/1  TBA04060103(swi-2) 3/1     WS-C6506
 3/8  TBA03300081(swi-3) 1/1     WS-C6506
15/1  rtr-1-msfc         VLAN 1  cisco    Cat6k-MSFC
16/1  MSFC1b             Vlan2   cisco    Cat6k-MSFC

Другие параметры

В некоторых коммутатора, например, Catalyst 6500/6000, есть возможность подачи питания к IP-телефонам через кабели UTP. Информация, полученная по протоколу CDP, помогает осуществлять управление питанием на коммутаторе.

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

Кроме того, при изменении вспомогательной VLAN (например, для того, чтобы заставить телефон использовать определенную VLAN или определенный способ маркировки) эта информация передается телефону посредством CDP.

Параметр

Тип

Описание

14

Идентификатор устройства

Позволяет отделять трафик VoIP от другого трафика, как с использованием отдельного идентификатора VLAN (вспомогательной VLAN).

16

Потребляемая мощность

Мощность, потребляемая VoIP-телефоном в милливаттах.

Примечание. Коммутаторы Catalyst 2900 и 3500XL в настоящее время не поддерживают CDPv2.

Конфигурация безопасности

В идеальном случае клиент уже создал политику безопасности, которая поможет определить, какие инструменты и технологии Cisco ему подходят.

Примечание. Безопасность ПО Cisco IOS, в отличие от CatOS, описывается во многих документах, как, например Cisco ISP Essentials.

Основные функции безопасности

Пароли

Настройка пароля уровня пользователя (учетная запись). В CatOS, начиная с версии 5.x, пароли являются чувствительными к регистру и их длина может составлять от 0 до 30 символов, включая пробелы. Установите пароль включения:


set password password
set enablepass password

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

Чтобы получить большую гибкость при управлении безопасностью паролей и доступом к устройствам, Cisco рекомендует использовать сервер TACACS+. Для получения дополнительных сведений см. раздел TACACS+ данного документа.

Secure Shell

Для обеспечения безопасности сеансов Telnet и удаленных подключений к коммутатору используйте шифрование SSH. Шифрование SSH поддерживается только для удаленных подключений к коммутатору. Сессии Telnet, инициируемые с коммутатора, не подлежат шифрованию. В CatOS 6.1 поддерживается SSH версии 1, а в CatOS 8.3 добавлена поддержка версии 2. SSH версии 1 поддерживает алгоритмы шифрования Data Encryption Standard (DES) и Triple-DES (3-DES), а SSH версии 2 поддерживает алгоритмы 3-DES и Advanced Encryption Standard (AES). Шифрование SSH можно использовать при аутентификации RADIUS и TACACS+. Данная функция поддерживается образами SSH (k9). Дополнительные сведения см. в документе Настройка SSH в коммутаторах Catalyst, работающих под управлением CatOS.

set crypto key rsa 1024

Чтобы отключить поддержку версии 1 и принимать только соединения версии 2, введите следующую команду:

set ssh mode v2

Разрешающие фильтры IP

Это фильтры для ограничения доступа к управляющему интерфейсу sc0 через Telnet или другие протоколы. Эти фильтры играют особенно важную роль, когда в используемой для управления VLAN содержатся пользователи. Чтобы включить фильтрование IP-адресов и портов, введите следующие команды:


set ip permit enable 
set ip permit IP address mask Telnet|ssh|snmp|all

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

Защита портов

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

set port security mod/port enable MAC address

Это также можно организовать с использованием динамического изучения MAC-адресов.

set port security port range enable 

Можно настроить следующие параметры:

  • set port security mod/port age time value — задает время, в течение которого адреса в порте фиксируются перед изучением нового адреса. Допустимые значения: 10 – 1440 минут. По умолчанию старения не происходит;

  • set port securitymod/port maximum value — ключевое слово, которое задает максимальное количество MAC-адресов, защищаемых в порте. Допустимые значения: от 1 (по умолчанию) до 1025;

  • set port security mod/port violation shutdown — при нарушении выключает порт (по умолчанию) и передает сообщение системного журнала (по умолчанию), а также сбрасывает трафик;

  • set port security mod/port shutdown time value — время, в течение которого порт остается отключенным. Допустимые значения: 10 – 1440 минут. По умолчанию отключение постоянное.

В CatOS, начиная с версии 6.x, Cisco была добавлена аутентификация 802.1x, которая позволяет клиентам аутентифицироваться на центральном сервере перед тем, как порт будет включен для данных. Поддержка данной функции на таких платформах, как Windows XP, только начинается, однако может рассматриваться как стратегическое направление для многих предприятий.

Сообщения при входе

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

# set banner motd ^C
*** Unauthorized Access Prohibited ***
***  All transactions are logged   ***
------------- Notice Board -------------
----Contact Joe Cisco at 1 800 go cisco for access problems----
^C

Физическая безопасность

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

Система управления доступом к контроллеру терминального доступа (TACACS)

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

Существует три системы безопасности, призванных помочь при контроле и управлении доступом к сетевым устройствам. Для размещения всей информации о защите в единой центральной базе данных в них используется архитектура клиент/сервер. Вот эти три системы безопасности:

  • TACACS+;

  • RADIUS;

  • Kerberos.

TACACS+ является распространенным решением в сетях Cisco и в данной главе упор делается на него. Оно обладает следующими функциями:

  • Аутентификация — процесс идентификации и проверки пользователей. Для аутентификации пользователей могут использоваться различные методы, однако чаще всего используется комбинация из имени пользователя и пароля;

  • Авторизация — пользователь может получить авторизацию различных команд после прохождения аутентификации;

  • Учет — запись действий, которые пользователь выполняет или выполнял в устройстве;

Дополнительную информацию см. в документе Настройка TACACS+, RADIUS и Kerberos в коммутаторах Cisco Catalyst.

Технологическое описание

Протокол TACACS+ перенаправляет имена пользователей и пароли через сеть на централизованный сервер в зашифрованном виде, используя одностороннее хеширование MD5 (RFC 1321 leavingcisco.com). Для транспортного протокола используется порт TCP 49. Это обеспечивает следующие преимущества над UDP (который используется для RADIUS):

  • Передача данных через установленное соединение;

  • Отдельное подтверждение получения запроса (TCP ACK), которое не зависит от текущей загрузки механизма аутентификации;

  • Немедленное уведомление о сбое сервера (пакеты RST).

Если во время сеанса требуется дополнительная проверка подлинности, то коммутатор выполняет ее с помощью TACACS+, чтобы определить наличие у пользователя разрешения на использование определенной команды. Это обеспечивает большую степень управления командами, которые могут быть выполнены на коммутаторе, чем при использовании механизма аутентификации. Использование учета команд позволяет выполнять аудит команд, введенных определенным пользователем при его подключении к определенному сетевому устройству.

103h.gif

Когда пользователь пытается выполнить простой вход ASCII с помощью авторизации на сетевом устройстве, использующем TACACS+, обычно происходит следующий процесс:

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

  • Через некоторое время сетевое устройство получит один из следующих ответов от демона TACACS+:

    • ACCEPT — пользователь прошел аутентификацию и работа службы начата. Если сетевое устройство настроено так, что требуется авторизация, авторизация начнется в это время;

    • REJECT — пользователь не прошел аутентификацию. В зависимости от используемого демона TACACS+ пользователю может быть отказано в доступе или предложено повторить последовательность входа;

    • ERROR — в некоторый момент во время аутентификации произошла ошибка. Это может быть демон или сетевое подключение между демоном и коммутатором Если получен ответ ERROR, сетевое устройство обычно пытается использовать для аутентификации пользователя альтернативный метод;

    • CONTINUE — пользователь получает запрос на дополнительную информацию аутентификации.

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

  • Если требуется авторизация TACACS+, демону TACACS+ отправляется запрос, и он возвращает ответ авторизации ACCEPT или REJECT. Если возвращается ответ ACCEPT, он будет содержать данные в форме атрибутов, используемых для направления сеанса EXEC или NETWORK для данного пользователя, определяя команды, к которым ему разрешен доступ.

Рекомендация

Cisco рекомендует использовать протокол TACACS+, поскольку его легко реализовать при помощи CiscoSecure ACS для NT, Unix или иного ПО других производителей. Среди функций TACACS+ есть предоставление подробного отчета, содержащего статистику по использованию команд и системы, алгоритм шифрования MD5 и административное управление процессами аутентификации и авторизации.

В данном примере в режимах входа и включения для аутентификации используется сервер TACACS+, а если сервер недоступен, для них может использоваться локальная аутентификация. Это важный черный ход, присутствующий в большинстве сетей. Чтобы настроить TACACS+, введите следующие команды:

set tacacs server server IP primary
set tacacs server server IP


!--- Резервные серверы возможны.

set tacacs attempts 3

!--- Это значение используется по умолчанию.

set tacacs key key


!--- Ключ шифрования MD5

set tacacs timeout 15

!--- Более длительный период ожидания ответа от сервера (по умолчанию используется 5).

set authentication login tacacs enable
set authentication enable tacacs enable
set authentication login local enable
set authentication enable local enable

!--- Последние две команды – по умолчанию; они разрешают переход к внутренней
!--- аутентификации при недоступности сервера TACACS+.

Другие параметры

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

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

set accounting connect enable start-stop tacacs+
set accounting exec enable start-stop tacacs+
set accounting system enable start-stop tacacs+
set accounting commands enable all start-stop tacacs+
set accounting update periodic 1

Конфигурация обладает следующими функциями:

  • Команда connect включает учет событий исходящего соединения на коммутаторе, такого как Telnet;

  • С помощью команды exec включается учет сеансов входа на коммутаторе, например для оперативного персонала;

  • С помощью команды system включается учет системных событий коммутатора, таких как перезагрузка или сброс;

  • Команда commands включает учет вводимых на коммутаторе данных – как для команд show, так и для команд конфигурации;

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

Контрольный список конфигурации

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

Крайне важной является маркировка всех портов. Чтобы промаркировать порты, введите следующую команду:

set port description descriptive name

Используйте данную подсказку в таблице "Команды":

Подсказка:

Жирный текст - рекомендованное изменение

Обычный текст - по умолчанию, рекомендованная настройка

Команды глобальной настройки

Команда

Комментарий

set vtp domain name password x

Защита от несанкционированного обновления VTP с новых коммутаторов.

set vtp mode transparent

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

set spantree enable all

Убедитесь во включении STP во всех VLAN.

set spantree root vlan

Рекомендуется для задания положения корневых (и вспомогательных корневых) мостов для VLAN.

set spantree backbonefast enable

Включение быстрой сходимости STP при косвенных ошибках (только если функцию поддерживают все коммутаторы домена).

set spantree uplinkfast enable

Включение быстрой сходимости STP при прямых ошибках (только для коммутаторов уровня доступа).

set spantree portfast bpdu-guard enable

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

set udld enable

Включение обнаружения однонаправленного канала (также требуется настройка на уровне порта).

set test diaglevel complete

Включение полной диагностики при загрузке (по умолчанию в Catalyst 4500/4000).

set test packetbuffer sun 3:30

Включение проверки ошибок буфера порта (применяется только к Catalyst 5500/5000).

set logging buffer 500

Установка максимального размера буфера внутреннего системного журнала.

set logging server IP address

Настройка сервера системного журнала для внешней регистрации системных сообщений.

set logging server enable

Разрешение сервера внешнего журналирования.

set logging timestamp enable

Включение меток времени сообщений журнала.

set logging level spantree 6 default

Увеличение уровня по умолчанию системного журнала STP.

set logging level sys 6 default

Увеличение уровня по умолчанию системного журнала System.

set logging server severity 4

Разрешение экспорта только системного журнала с более высоким уровнем серьезности ошибок.

set logging console disable

Отключение консоли за исключением устранения неисправностей.

set snmp community read-only string

Настройка пароля для разрешения удаленного сбора данных.

set snmp community read-write string

Настройка пароля для разрешения удаленной настройки.

set snmp community read-write-all string

Настройка пароля для разрешения удаленной настройки включая пароли.

set snmp trap enable all

Включение сообщений SNMP-trap на сервер NMS для ошибок и предупреждений о событиях.

set snmp trap server address string

Настройка адреса получателя сообщений NMS trap.

set snmp rmon enable

Включение RMON для сбора локальной статистики. Для получения дополнительных сведений см. раздел Удаленный контроль данного документа.

set ntp broadcastclient enable

Включение получения точного системного времени от маршрутизатора более высокого уровня в каскаде.

set ntp timezone zone name

Установка локального часового пояса для устройства.

set ntp summertime date change details

Настройка летнего времени, если применимо для часового пояса.

set ntp authentication enable

Настройка зашифрованной информации о времени в целях безопасности.

set ntp key key

Настройка ключа шифрования.

set cdp enable

Включение обнаружения соседних узлов (также по умолчанию включено для портов).

set tacacs server IP address primary

Настройка адреса сервера AAA (аутентификации, авторизации и учета).

set tacacs server IP address

Резервные серверы AAA, если возможно.

set tacacs attempts 3

Разрешить 3 попытки ввода пароля для учетной записи пользователя сервера AAA.

set tacacs key key

Настройка ключа шифрования MD5 для AAA.

set tacacs timeout 15

Установка большего значения времени ожидания ответа от сервера (по умолчанию пять секунд).

set authentication login tacacs enable

Использование сервера AAA для аутентификации в целях входа.

set authentication enable tacacs enable

Использование сервера AAA для аутентификации для режима включения.

set authentication login local enable

По умолчанию; разрешает переход к внутренней аутентификации при недоступности сервера AAA.

set authentication enable local enable

По умолчанию; разрешает переход к внутренней аутентификации при недоступности сервера AAA.

Команды настройки портов узла

Команда

Комментарий

set port host port range

Удаление ненужной обработки порта. Данная макрокоманда включает функцию PortFast связующего дерева, отключает логические каналы и магистрали.

set udld disable port range

Удаление обработки ненужных портов (по умолчанию отключено на портах для подключения медного кабеля).

set port speed port range auto

Использование автосогласования с последними драйверами сетевых интерфейсных плат.

set port trap port range disable

Обычным пользователям не требуется SNMP trap, отслеживаются только ключевые порты.

Команды настройки сервера

Команда

Комментарий

set port host port range

Удаление ненужной обработки порта. Данная макрокоманда включает функцию PortFast связующего дерева, отключает каналы и магистрали.

set udld disable port range

Удаление обработки ненужных портов (по умолчанию отключено на портах для подключения медного кабеля).

set port speed port range 10 | 100

Обычная настройка статических портов/портов серверов, в остальных случаях используется автосогласование.

set port duplex port range full | half

Обычная настройка статических портов/портов серверов, в остальных случаях используется автосогласование.

set port trap port range enable

Порты ключевых серверов должны передавать сообщения trap в NMS.

Команды настройки неиспользуемых портов

Команда

Комментарий

set spantree portfast port range disable

Включение обработки и защиты нужных портов для STP.

set port disable port range

Отключение неиспользуемых портов.

set vlan unused dummy vlan port range

Направление несанкционированного трафика в неиспользуемую VLAN, если порт включен.

set trunk port range off

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

set port channel port range mode off

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

Порты инфраструктуры (коммутатор-коммутатор, коммутатор-маршрутизатор)

Команда

Комментарий

set udld enable port range

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

set udld aggressive-mode enable port range

Включение интенсивногорежима (для устройств, которые его поддерживают).

set port negotiation port rangeenable

Разрешить автосогласование параметров соединения GE по умолчанию.

set port trap port range enable

Разрешить сообщения SNMP trap для этих ключевых портов.

set trunk port range off

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

set trunk mod/port desirable ISL | dot1q | negotiate

При использовании магистральных каналов отдавать предпочтение dot1q.

clear trunk mod/port vlan range

Ограничение диаметра STP отсечением ненужных виртуальных сетей от магистральных каналов.

set port channel port range mode off

Отключение функции в случае неиспользования логических каналов.

set port channel port range mode desirable

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

set port channel all distribution ip both

Разрешение распределения нагрузки по адресу источника/приемника на уровне 3 при использовании логических каналов (по умолчанию в Catalyst 6500/6000).

set trunk mod/port nonegotiate ISL | dot1q

Отключение DTP при организации магистрального канала к маршрутизатору (Catalyst 2900XL, 3500 или маршрутизатор другого производителя).

set port negotiation mod/port disable

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

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 13414