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

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

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


Содержание


Введение

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

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

Требования

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

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

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

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

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

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

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

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

  • Решения, статистически имеющие самое широкое распространение, а следовательно обеспечивающие наименьший риск.

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

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

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

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

Основная конфигурация

В данном разделе рассматриваются функции, используемые в большинстве сетей 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 internal port.

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

!--- CDP and so on.

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 flow control.

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

!--- Multilayer Switch Feature Card (MSFC) router.

...

У 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 Protocol 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 N/A - DSAP 42 SSAP 42 01-80-c2-00-00-00
Inter-Switch Link (ISL) Н/Д 01-00-0c-00-00-00
Протокол транкинга в виртуальных сетях (VTP) 0x2003 01-00-0c-cc-cc-cc
IEEE Pause, 802.3x N/A—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-адрес, полученный из банка доступных адресов в памяти EPROM на шасси. Чтобы отобразить диапазоны адресов, которые доступны каждому из модулей, являющихся источниками трафика, такого, как сообщения 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

!--- MACs for sourcing traffic.

...
VLAN 1

VLAN 1

VLAN 1 имеет особое значение в сетях Catalyst.

Для обозначения нескольких протоколов управления при организации магистралей (транкинге), таких как 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.

  • Для изменения собственного VLAN выполните команду vlan-id mod/port set vlan.

    Примечание: Создайте VLAN перед установкой ее как собственного VLAN транка.

Вот несколько разумных причин для того, чтобы настроить сеть и изменить поведение портов в сети 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 посылаются на VLAN1. Это правило не нарушается, даже если VLAN 1 удаляется из магистралей и не является собственной VLAN. В магистральном канале 802.1Q пакеты DTP передаются по собственной VLAN. Это правило не нарушается, даже если собственная VLAN удаляется из магистрали.

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

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

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

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

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

Если вы не хотите подключать устройство, подключать разъем обратной связи в каком-либо порту для той VLAN. Как альтернатива, попробуйте перекрестный кабель, который подключает два порта в той VLAN на том же коммутаторе. Этот метод повышает порт. См. раздел Разъема обратной связи Кольцевых проверок для Линий T1/56K для получения дополнительной информации.

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

Протокол транкинга виртуальной локальной сети (VLAN)

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

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

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

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

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

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

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

Функция Сервер Клиент Прозрачный Off1
Исходные сообщения VTP Да Да Нет Нет
Обнаружение сообщений VTP Да Да Нет Нет
Пересылка сообщений VTP Да Да Да Нет
Создайте виртуальные LAN (VLAN) Да Нет Да (только локальное значение) Да (только локальное значение)
Помните о виртуальных локальных сетях (VLAN) Да Нет Да (только локальное значение) Да (только локальное значение)

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

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

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

Функция Значение по умолчанию
Vtp domain имя NULL
Режим VTP Сервер
Версия VTP Версия 1 включена
Пароль VTP Нет
Процедура отсечения каналов в протоколе VTP Отключенный

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

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

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

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

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

Для получения дополнительной информации см. раздел Основные понятия и настройка магистрального протокола VLAN (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:

    • Version

    • Имя домена

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

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 Кб.

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

Рекомендаций относительно выбора режима серверного/клиентского режима VIP или прозрачного режима VTP не предусмотрено. Несмотря на некоторые факторы, изложенные ниже, некоторые клиенты предпочитают простоту управления режима client/server VTP. Мы рекомендуем установить в каждом домене по два коммутатора в режиме сервера (обычно это коммутаторы уровня распределения) для резервирования. Остальные коммутаторы в домене должны находиться в режиме 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 на транках канала порта, гарантируйте, что любые порты, связанные с IP-телефонами, настроены как порты доступа с голосовым VLAN.

  • Расширенный диапазон 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.
mod/port set trunk диапазон VLAN Включает использование магистралей всеми виртуальными сетями по необходимости. По умолчанию - все 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 байтов МАС-адреса:

/image/gif/paws/13414/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

!--- These are internal VLANs.

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

1    default                          active    7       4/1-48



!--- Output suppressed.


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

!--- These are internal VLANs.

Кроме того, перед использованием 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 на наличие общих предупреждений.

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

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

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

set port speed port range auto

!--- This is the default.

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

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 с удаленной стороны. Это состояние не зависит от настройки автосогласования на удаленной стороне. Например, пусть существуют два устройства: А и В. Для каждого из них автосогласование может быть включено или отключено. В таблице приведен список возможных конфигураций и соответствующих состояний соединения:

Negotiation B включено B отключен
Включен А up с обеих сторон A down, B up
A недоступен A up, B down up с обеих сторон

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

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

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

/image/gif/paws/13414/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 рекомендует включить согласование скорости передачи 1 Гбит/с (настройка по умолчанию) для всех связей "коммутатор-коммутатор" и предпочтительно всех устройств GE. Для включения автоматического согласования введите следующую команду:

set port negotiation port range enable

!--- This is the default.

Единственное известное исключение составляет подключение к устройству 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 обнаружили проблемы с гигабитным согласованием на серверах 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, даже когда они согласовывают эту возможность, поскольку они не способны выполнять блокировку.

Динамический транкинговый протокол (Dynamic Trunking Protocol)

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

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

Создание магистральных каналов (транкинг) поддерживается в нескольких типах сред уровня 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 ИНДЕКС Резерв Инкапсулированный кадр 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". Да, периодически. Транкинг
Включено При этом порт переходит в постоянный режим группирования магистралей, а канал преобразуется в магистральный. Порт становится магистральным портом, даже если соседний порт не согласен на это изменение. Да, периодически. Транкинг, без условий.
Nonegotiate Переведите порт в режим постоянного объединения, но не допускайте создания портом кадров DTP. Нужно вручную настроить соседний порт как магистральный порт, чтобы установить магистральный канал. Этот метод удобно использовать в устройствах, которые не поддерживают DTP. Нет Транкинг, без условий.
Desirable Заставляет порт активно пытаться преобразовать канал в магистральный канал. Порт становится магистральным, если соседний порт работает в режиме "on", "desirable" или "auto". Да, периодически. Это заканчивается в режиме trunking, только если режим удаленного узла будет on, auto или desirable.
Выключен Порт переходит в постоянный режим non-trunking, а канал, благодаря согласованию, преобразуется в немагистральный. Порт становится немагистральным портом, даже если соседний порт не согласен на это изменение. В установившемся состоянии – нет, однако после перехода из состояния 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

!--- Ports are not trunking; part of the set port host command.

Дополнительные варианты

В другой общей пользовательской конфигурации режим 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), его реализация в крупных коммутируемых сетях с большим числом сетей VLAN, большим числом коммутаторов в домене, поддержкой нескольких производителей и Усовершенствование 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. Неуказанные порты блокируются.

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

Настройки по умолчанию основного таймера (секунды) Name Функция
2 Hello Управление отправкой BPDU (протокольных информационных единиц моста).
15 Задержка передачи (Fwddelay) Контролирует, сколько времени порт проводит в режиме прослушивания и изучения и влияет на процесс изменения топологии (см. следующий раздел).
20 Max age Контролирует, как долго коммутатор поддерживает текущую топологию перед поиском альтернативного пути. По истечении времени, равного значению 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

  • Связующее дерево для каждой VLAN или совместное связующее дерево, как Cisco PVST

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

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

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

количество портов + (количество транков * количество VLAN на транках) <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, поэтому для этой VLAN требуется включить магистраль для взаимодействия с другими поставщиками. 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+ обнаруживает несогласованности порта и VLAN. Во избежание возникновения петлей переадресации PVST+ блокирует порты, принимающие неполные пакеты BPDU. Протокол также оповещает пользователей о любых несоответствиях конфигураций при помощи сообщений системного журнала.

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

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

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

set spantree enable all

!--- This is the default.

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

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

  • Защита от сбоев EtherChannel.

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

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

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

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

Лучше всего не использовать управляющую VLAN для абонентского трафика. Особенно в случае более старых Catalyst switch processors лучше избегать проблем с 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, если необходимо мостовое соединение между сетями VLAN на маршрутизаторах Cisco, например MSFC.

PortFast

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

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

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

Порт PortFast пропускает обычные состояния прослушивания и обучения STP за счет непосредственного перевода порта из режима блокировки в режим пересылки, как только становится известно о включении канала. Если эта функция не включена, STP будет отбрасывать все пользовательские данные до перевода порта в режим пересылки. Может потребоваться время, которое до двух раз больше времени отсрочки пересылки (всего 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


!--- Macro command for these commands:

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 или системного журнала. Для портов, переведенных в состояние 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 на уровне доступа, если работа пересылающего восходящего канала прерывается, заблокированный восходящий канал немедленно переключается в состояние пересылка без ожидания состояний прослушивания и обучения.

Группа каналов от абонента к операторы – это набор портов для каждой VLAN, которые можно рассматривать как корневой порт и резервный корневой порт. При нормальных условиях корневой порт гарантирует соединение точки доступа с корнем. Если соединение с корневым портом по какой-либо причине отключается, соединение с резервным коревым портом включается немедленно, без обычной 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 – это разработка 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 (защита от петель) и BPDU Skew Detection (обнаружение искажения BPDU).

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

Функция 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, и когда ПО поддерживает эти функции.

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

%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

  • Защита корня дерева STP

    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, сгруппированы для формирования логического канала, STP теряет всю информацию о состоянии этих портов. Новый канальный порт может получить состояние пересылки с назначенной ролью.

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

    В последних двух случаях, приведенных в списке, есть возможность образования петли до тех пор, пока UDLD не обнаружит ошибку. Однако 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 глобально или в индивидуальном порядке. Не следует отключать защиту от петель на совместных линиях связи.

  • set spantree global-default loopguard disable
    
    !--- This is the global default.
    
    

    или

  • set spantree guard none mod/port
    
    
    !--- This is the default port configuration.
    
    

Корневая защита для протокола связующего дерева

Функция защиты корня обеспечивает возможность задать расположение корневого моста в сети. Функция защиты корня обеспечивает, чтобы порт, для которого включена эта функция, был назначенным портом. Обычно все порты корневого моста являются назначенными, если два или более портов корневого моста не соединены вместе. Если мост получает вышестоящий 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 или в канале с пропускной способностью 1 Гбит. Различия в алгоритмах на той или иной платформе проистекают из способности каждого типа оборудования извлекать сведения заголовка кадра для принятия решения о распределении.

Алгоритм распределения нагрузки – это общая функция для обоих протоколов управления каналами. В 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-адресов источника и пункта назначения определяют канал, выбранный для переадресации кадра. Операция X-OR выполняется над наименее значащими двумя битами MAC-адреса источника и получателя. В результате возможны 4 варианта: (0 0), (0 1), (1 0) или (1 1). Каждое из этих значений указывает на канал в группе FEC. В случае Fast EtherChannel на двух портах в операции X-OR используется только единственный бит. Возможны ситуации, в которых один из адресов (исходный или конечный) является константой. Например, местом назначения может быть сервер или, что более вероятно, маршрутизатор. В таком случае вы увидите статистику по распределению нагрузки, поскольку адреса источника всегда различаются.
Catalyst 4500/4000 Series 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 (механизм L2) (L3 Engine) WS-F6K-PFC Следующие версии Supervisor Engine 1 и Supervisor Engine 1A/PFC1 L2 MAC: SA; DA; SA И IP L3 DA: SA; DA; SA и DA (по умолчанию)
WS-F6K-PFC 2 Supervisor Engine 2/PFC2 (требуется CatOS 6.x) L2 MAC: SA; DA; SA и IP L3 DA: SA; DA; SA и DA (по умолчанию) сеанс L4: Порт 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 L2 MAC: SA; DA; SA и IP L3 DA: SA; DA; SA и DA (по умолчанию) сеанс L4: Порт S; D порт; сеанс L4 VLAN IP порта S & D: 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

!--- This is the default.

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

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

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

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

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

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

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

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

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

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

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

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

  • Если пакеты PAgP останавливаются, состояние PAgP – "разорвано".

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

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

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

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

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

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

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

Состояние Значение
UpData Не было получено ни одного пакета PAgP. Отправка пакетов PAgP выполнена. Физический порт – единственный подключенный к agport. Выполнена двусторонняя передача отличных от PAgP пакетов между физическим портом и портом agport.
BiDir Ровно один пакет PAgP был получен, что свидетельствует о существовании двунаправленного соединения ровно с одним соседом. Физический порт не подключен ни к какому агрегируемому порту. Пакеты PAgP переданы и могут быть получены.
UpPAgP Этот физический порт, возможно в сопоставлении с другими физическими портами, подключен к агрегируемому порту. Пакеты PAgP отправляются и принимаются в физическом порту. Выполнена двусторонняя передача отличных от PAgP пакетов между физическим портом и портом agport.

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

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

Задержка PAgP может возникнуть на последнем соседе, известном на физическом порту. Таймаут порта удален из agport. В то же время, удаляются все физические порты на одном порту agport, на таймерах которых превышено время ожидания. Это позволяет отключить целиком весь агрегируемый порт, на другом конце которого потеряна связь, вместо последовательного отключения одного физического порта за другим.

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

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

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

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

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

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

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

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

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

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

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

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

Режим Настраиваемые параметры
Включено PAgP не работает. Порт продолжает передачу по каналу вне зависимости от того, как настроен соседний порт. Если соседний порт находится в режиме on, то формируется канал.
Выключен Порт не участвует в формировании логического канала вне зависимости от того, как настроен соседний порт.
Auto (по умолчанию) Агрегирование выполняется под управлением протокола PAgP. Порт переводится в состояние пассивного согласования; пакеты PAgP не отправляются через интерфейс, пока не будет получен по крайней мере один пакет PAgP, в котором указано, что отправитель работает в режиме desirable.
Desirable Агрегирование выполняется под управлением протокола PAgP. Переводит порт в активное состояние согласования, в котором порт начинает согласование с другими портами, посылая пакеты PAgP. Канал формируется с другой группой портов в нужном или автоматическом режиме.
Non-silent (по умолчанию в оптоволоконных портах FE и GE Catalyst 5500/5000) Ключевое слово для автоматического или требуемого режима. Если интерфейс не получает пакетов данных, интерфейс никогда не включается в агрегированный порт и не может быть использован для данных. Данная проверка двунаправленности была добавлена для определенного оборудования Catalyst 5500/5000, поскольку некоторые сбои физических каналов приводят к нарушениям логических каналов. Поскольку включен режим non-silent, восстановившемуся соседнему порту не разрешается без необходимости включаться в логический канал и нарушать его. По умолчанию в оборудовании Catalyst серий 4500/4000 и 6500/6000 присутствует более гибкое объединение и улучшенная проверка двунаправленности.
Silent (по умолчанию во всех портах Catalyst 6500/6000 и 4500/4000 и портах для медного кабеля 5500/5000) Ключевое слово для автоматического или требуемого режима. Если интерфейс не получает пакетов данных, через 15 секунд ожидания интерфейс сам присоединяется к агрегированному порту и поэтому может быть использован для передачи данных. Режим молчания также позволяет работать в канале связи, когда партнер может быть анализатором или сервером, никогда не посылающим 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 (то есть некоторые из комбинаций приводят к отключению портов со стороны, на которой созданы логические каналы).

Режим канала коммутатора А Режим канала коммутатора В Состояние канала
Включено Включено Канал (не PAgP)
Включено Выключен Нет канала (errdisable)
Включено Auto Нет канала (errdisable)
Включено Desirable Нет канала (errdisable)
Выключен Включено Нет канала (errdisable)
Выключен Выключен Нет канала
Выключен Auto Нет канала
Выключен Desirable Нет канала
Auto Включено Нет канала (errdisable)
Auto Выключен Нет канала
Auto Auto Нет канала
Auto Desirable Канал PAgP
Desirable Включено Нет канала (errdisable)
Desirable Выключен Нет канала
Desirable Auto Канал PAgP
Desirable Desirable Канал PAgP

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

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

!--- Ports not channeled; part of the set port hostcommand.

Эта команда присваивает каналам номер группы администратора, который отображается с помощью команды 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 очень небольшая разница. Оба протокола поддерживают не более восьми портов в каждом канале, а перед формированием группы проверяются одинаковые свойства портов. Среди этих свойств портов:

  • Скорость

  • Дуплекс

  • Native 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 можно настраивать в различных режимах, описанных в следующей таблице:

Режим Настраиваемые параметры
Включено Агрегирование линий связи производится принудительно без согласования LACP. Коммутатор не пересылает пакеты LACP и не обрабатывает входящие пакеты LACP. Если соседний порт находится в режиме on, то формируется канал.
Выключен Порт не участвует в формировании логического канала вне зависимости от того, как настроен соседний порт.
Passive (режим по умолчанию) Это аналогично автоматическому режиму в PAgP. Коммутатор не инициирует создание логического канала, но понимает входящие пакеты LACP. Соседний равноправный узел (в состоянии active) инициирует согласование передачей пакета LACP. Коммутатор принимает пакет и отвечает на него и далее формирует агрегированный канал с соседним узлом.
Active Аналогичен режиму desirable в PAgP. Для формирования агрегированного соединения коммутатор инициирует согласование. Объединение линий связи формируется, если другая сторона работает в режимах LACP active или passive.

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

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

Режим канала коммутатора А Режим канала коммутатора В Состояние канала коммутатора А Режим создания логических каналов в коммутаторе B
Включено Включено Канал (не LACP) Канал (не LACP)
Включено Выключен Нет канала (errdisable) Нет канала
Включено Пассивный Нет канала (errdisable) Нет канала
Включено Active Нет канала (errdisable) Нет канала
Выключен Выключен Нет канала Нет канала
Выключен Пассивный Нет канала Нет канала
Выключен Active Нет канала Нет канала
Пассивный Пассивный Нет канала Нет канала
Пассивный Active Канал LACP Канал LACP
Active Active Канал LACP Канал LACP

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

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

Режим канала коммутатора А Режим канала коммутатора В Состояние канала коммутатора А Режим создания логических каналов в коммутаторе B
Включено Включено Канал (не LACP) Канал (не PAgP)
Включено Выключен Нет канала (errdisable) Нет канала
Включено Auto Нет канала (errdisable) Нет канала
Включено Desirable Нет канала (errdisable) Нет канала
Выключен Включено Нет канала Нет канала (errdisable)
Выключен Выключен Нет канала Нет канала
Выключен Auto Нет канала Нет канала
Выключен Desirable Нет канала Нет канала
Пассивный Включено Нет канала Нет канала (errdisable)
Пассивный Выключен Нет канала Нет канала
Пассивный Auto Нет канала Нет канала
Пассивный Desirable Нет канала Нет канала
Active Включено Нет канала Нет канала (errdisable)
Active Выключен Нет канала Нет канала
Active Auto Нет канала Нет канала
Active Desirable Нет канала Нет канала

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

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

  • 
    set channelprotocol lacp модуль
    
    
    

    По умолчанию все порты коммутаторов 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 команда ключа администратора назначает каналы номер ключа администратора. Команда show lacp-channel group отображает это значение. Set port lacp-channel port_range команда ключа администратора назначает тот же ключ администратора на все порты в диапазоне портов. Если значение не указывать, назначается случайное значение 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:

Состояние порта Комментарий
Неопределенный Выполняется определение, либо соседний элемент UDLD был отключен, либо его передача была заблокирована.
Не применимо UDLD отключен.
Отключение Обнаружен однонаправленный канал и порт отключен.
Bidirectional Обнаружен двунаправленный канал.

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

  • Чтобы сохранить целостность кэша 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

!--- After global enablement, all FE and GE fiber 
!--- ports have UDLD enabled by default.


set udld enable port range


!--- This is for additional specific ports and copper media, if needed.

Необходимо вручную включать порты, отключенные в результате ошибки при возникновении симптомов однонаправленного соединения. Введите команду 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

!--- This is BPDU port-guard.


channel-misconfig

!--- This is a channel misconfiguration.


duplex-mismatch
udld
other

!--- These are other reasons.


all

!--- Apply errdisable timeout to all reasons.

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

set udld disable port_range

Тестирование и мониторинг UDLD

UDLD трудно проверить без откровенно неисправного/однонаправленного компонента, такого как дефектный GBIC, в лабораторных условиях. Этот протокол был разработан для выявления сценариев отказа, которые встречаются реже, чем те, которые обычно используют в тестовых условиях. Например, при выполнении простой проверки посредством отключения одной жилы оптоволокна для получения требуемого состояния errdisable, необходимо отключить автосогласование уровня 1. В противном случае физический порт переходит в состояние down, что приводит к нарушению обмена сообщениями 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. Гигантские пакеты также известны как кадры большого размера.

Есть много причин, по которым размер 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 байта (T1/DS0 CT3) 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 также предоставляют поддержку кадров большого размера L3 в 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 в глобальных сетях (WAN) (Интернет) была подвергнута тщательному изучению. Данное уравнение объясняет зависимость верхней границы пропускной способности от следующих факторов:

  • Максимальный размер сегмента (MSS), равный разнице между длиной MTU и длиной заголовков TCP/IP

  • Период кругового обращения (RTT)

  • Потери пакетов

/image/gif/paws/13414/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, в которой находятся узлы. Чтобы включить поддержку больших кадров модулями, поддерживающими работу с большими кадрами, введите следующую команду:


mod/port set port jumbo включает

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

interface vlan vlan#
mtu 9216

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

Настройка управления

В данном разделе рассматриваются моменты, которые помогут в управлении, подготовке и устранении неисправностей сети, состоящей из устройств Catalyst.

Сетевые графики

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

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

Cisco рекомендует подготовить следующие три схемы:

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

  • Схема физических соединений на ней отображаются все коммутаторы, маршрутизаторы и разводка кабелей. Необходимо нанести магистральные каналы, физические каналы, скорости, группы логических каналов, номера портов, слоты, типы корпусов, ПО, домены VTP, корневые мосты, приоритет резервных корневых мостов, MAC-адреса и заблокированные порты для виртуальных сетей. Часто бывает полезным нанесение на схему внутренних устройств, таких как MSFC Catalyst 6500/6000, как маршрутизатор в каскаде, подключенный при помощи магистрали.

    /image/gif/paws/13414/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. Длительность диагностики зависит от конфигурации системы (числа слотов, модулей, портов). Существуют три категории тестов:

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

Во время проверки памяти при обнаружении различий между записанными и считанными шаблонами состояние порта изменяется на faulty. Результаты этих проверок можно увидеть при вводе команды show test с номером проверяемого модуля:

>show test 9

Diagnostic mode: complete (mode at next reset: complete)

!--- Configuration setting.

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  .

!--- Faulty.

 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

!--- This is the default in CatOS 6.4(16), 7.6(12), 8.4(2), and later.


set errordetection portcounters enable

!--- This is the default in CatOS 6.4(16), 7.6(12), 8.4(2), and later.


set errordetection memory enable

!--- This is the default in CatOS 6.4(16), 7.6(12), 8.4(2), and later.

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

>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-RJ-45

  • RJ21 WS-X6248

  • WS-X6348-RJ-45

  • RJ21 WS-X6348

  • 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

!--- This is the default.

Дополнительный параметр

Поскольку для полного восстановления портов, в которых произошел сбой 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


!--- When test is running, the command returns 
!--- this information:

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

!--- When test is not running, 
!--- the command returns this information:

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

!--- This is the default.

После включения (как после первого обновления 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

!--- This is the default.

set logging server syslog server IP address
set logging server enable

!--- This is the default.

set logging timestamp enable
set logging level spantree 6 default

!--- Increase default STP syslog level.

set logging level sys 6 default

!--- Increase default system syslog level.

set logging server severity 4

!--- This is the default;
!--- it limits messages exported to syslog server.

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.
ядро 2 Не менять.
1d 3 Не менять.
mcast 2 При использовании многоадресной рассылки установите уровень 4 (CatOS начиная с версии 5.5[5]).
mgmt 5 Не менять.
mls 5 Не менять.
pagp 5 Не менять.
protfilt 2 Не менять.
отсечение 2 Не менять.
Privatevlan 3 Не менять.
qos 3 Не менять.
radius 2 Не менять.
rsvp 3 Не менять.
безопасность 2 Не менять.
snmp 2 Не менять.
spantree 2 Измените на 6.
системный 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 рекомендуется ознакомиться с Руководством по системным сообщениям.

Simple Network Management Protocol

SNMP используется для извлечения статистики, таблиц и значений счетчиков, сохраняемых в базах управляющей информации (MIB) сетевых устройств. Собранную информацию можно использовать в NMS (таких, как HP Openview) для генерирования предупреждений в режиме реального времени, оценки доступности и создания информации планирования производительности, а также для помощи при проверке конфигурации и устранении неисправностей.

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

При использовании некоторых механизмов защиты станция управления сетью может извлекать информацию из MIB при помощи запросов get и get next протокола SNMP и изменять параметры при помощи команды set. Кроме того, сетевое устройство можно настроить на генерирование сообщений захвата для NMS для получения тревожных сообщений в реальном времени. Опрос SNMP использует порт 161 IP UDP, а ловушки SNMP используют порт 162.

Cisco поддерживает следующие версии SNMP:

  • SNMPv1: Стандарт Интернет RFC 1157, использующий защиту строк сообщества открытого текста. Список контроля доступа по IP-адресам и пароли определяют группу управляющих, которые могут получать доступ к агенту MIB.

  • SNMPv2C: комбинация из SNMPv2, проекта Интернет-стандарта, определенного в RFC с 1902 по 1907 и SNMPv2C, административной инфраструктуры SNMPv2 для сообществ, которая представляет собой экспериментальный проект, описанный в RFC 1901. К числу преимуществ следует отнести механизм группового извлечения, позволяющий извлекать таблицы и большие объемы данных за минимальное число циклов приема-передачи, а также улучшенную обработку ошибок.

  • SNMPv3: Проект, предлагаемый RFC 2570, обеспечивает безопасный доступ к устройствам посредством сочетания аутентификации и шифрования пакетов в сети. В SNMPv3 реализованы следующие функции защиты:

    • Целостность сообщений обеспечивает неизменность пакетов в пути

    • Аутентификация определяет происхождение сообщения из надежного источника

    • Шифрование: шифрует содержимое пакета, предотвращая его простое прочтение посторонними лицами

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

Уровень модели Аутентификация Шифрование Результат
v1 noAuthNoPriv, строка имени и пароля Нет При проверке подлинности используется совпадение строки имени и пароля.
v2c noAuthNoPriv, строка имени и пароля Нет При проверке подлинности используется совпадение строки имени и пароля.
v3 noAuthNoPriv, Username Нет Для аутентификации используется совпадение имени пользователя.
v3 authNoPriv, MD5 или SHA Np Обеспечивает проверку подлинности на основе алгоритмов HMAC-MD5 или HMAC-SHA.
v3 authPriv, MD5 или SHA DES Обеспечивает проверку подлинности на основе алгоритмов HMAC-MD5 или HMAC-SHA. Кроме аутентификации обеспечивает 56-битное шифрование DES на основе стандарта CBC-DES (DES-56).

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

  • Каждый пользователь относится к группе.

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

  • Политика доступа определяет доступ на чтение, запись и создание объектов SNMP.

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

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

Рекомендации по ловушкам SNMP

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

На сегодняшний день большинство станций NMS использует SNMPv2C в следующей конфигурации:

set snmp community read-only string


!--- Allow viewing of variables only.


set snmp community read-write string


!--- Allow setting of variables.


set snmp community read-write-all string<string>

!--- Include setting of SNMP strings. 

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 Аутентификация
мост Мост
шасси Шасси
config !--- конфигурацию
entity Entity
разрешение IP Разрешение IP
модуль Модуль
repeater 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

!--- Enable on key ports only.

Рекомендации по опросам SNMP

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

  • Поступите просто, но с максимальной ответственностью.

  • Сократите лишнюю нагрузку для персонала на основании избыточных данных опроса, сбора, инструментов и ручного анализа.

  • Управлять сетью можно при помощи всего нескольких инструментов, таких как HP Openview в качестве NMS, Cisco RMEs в качестве диспетчера настройки, системного журнала, оборудования и программного обеспечения, Microsoft Excel в качестве анализатора данных NMS и CGI в качестве средства публикации этих данных в Интернет.

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

  • Определите, что в сети работает хорошо, и не трогайте это. Сконцентрируйтесь на нерабочих устройствах.

Первый этап реализации NMS заключается в определении базовых параметров сетевого оборудования. Сведения об исправности устройства и протокола можно получить благодаря простому отслеживанию загрузки CPU, памяти и буфера на маршрутизаторах, а также загрузки NMP CPU, памяти и системной платы на коммутаторах. Базовые значения пиковой и средней нагрузки приобретают значение только после обработки базовым оборудованием трафика уровней 2 и 3. Обычно базовые значения устанавливаются в течение нескольких месяцев, что позволяет получить значения ежедневной, ежемесячной и ежеквартальной загрузки, соответствующие экономическому циклу компании.

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

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

Группа Cisco Network Management Consulting рекомендует анализировать или контролировать в общей сети следующие ключевые MIB ошибок. Дополнительные сведения (например, об опросе производительности MIB (база управляющей информации) см. в документе Инструкции Cisco по мониторингу сети и взаимосвязи событий.

Имя объекта Описание объекта OID Интервал опроса Threshold
MIB-II
sysUpTime время доступности системы в сотых долях секунды 1.3.6.1.2.1.1.3 5 мин <30000

Имя объекта Описание объекта OID Интервал опроса Threshold
CISCO-PROCESS MIB
cpmCPUTotal5min Общий процент занятости CPU в течение последних 5 минут 1.3.6.1.4.1.9.9.109.1.1.1.1.5 10 мин Срок

Имя объекта Описание объекта OID Интервал опроса Threshold
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
sysEnableIpPermitTraps Указывает, будет ли в 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 Интервал опроса Threshold
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 Интервал опроса Threshold
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


!--- For use with NAM module only.

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

Требования к памяти

Использование памяти 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 (Network Time Protocol, протокол сетевого времени)

NTP, RFC 1305 , синхронизирует время в ряде распределенных клиентов и серверов времени и позволяет сопоставлять события при создании системных журналов или возникновении других событий, происходящих в определенное время. leavingcisco.com

NTP обеспечивает точность времени клиента обычно в пределах миллисекунды в LAN и до нескольких десятков миллисекунд в WAN, относительно основного сервера, синхронизированного с универсальным координированным временем. Типичные конфигурации NTP используют несколько резервных серверов и различные сетевые пути для достижения высокой точности и надежности. Некоторые конфигурации содержат криптографическую аутентификацию, чтобы предотвратить случайные или умышленные атаки на протокол.

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

Впервые протокол NTP был описан в RFC 958 и был развит в RFC 1119 (NTP версии 2), а теперь в RFC 1305 описана его третья версия. leavingcisco.com leavingcisco.comОн работает через порт 123 UDP. Все соединения NTP используют формат всемирного координированного времени (UTC), аналогичного гринвичскому времени.

Доступ к общедоступным серверам времени

Подсеть NTP в настоящее время включает более 50 основных серверов, синхронизированных напрямую c всемирным скоординированным временем (UTC) с помощью радио, спутниковой связи или модема. Обычно клиентские рабочие станции и серверы со сравнительно небольшим числом клиентов не синхронизируются с основными серверами. Существует около 100 общедоступных вторичных серверов, синхронизированных с основными серверами, что обеспечивает синхронизацию со 100000 клиентов и серверов в Интернете. Текущие списки находятся на странице списка общих серверов NTP, которая регулярно обновляется. Существует целый ряд частных основных и вспомогательных серверов, которые недоступны широким массам пользователей. Список общедоступных серверов NTP и информацию по их использованию можно найти на Интернет-странице Сервер синхронизации времени университета штата Делавэр. leavingcisco.com

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

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

Страта

Для каждого сервера NTP используется уровень, указывающий удаленность сервера времени от внешнего источника. Серверы Stratum 1 имеют доступ к некоторым типам внутреннего источника синхронизации, например радиочасам. Серверы Stratum 2 получают подробные данные о времени от номинированной установки серверов Stratum 1, а серверы Stratum 3 получают подробные данные о времени от серверов Stratum 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 секунд). При правильном планировании можно выполнить в рамках сетей маршрутизатора через глобальную сеть WAN. Клиенты 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                    

!--- This is a Message Digest 5 (MD5) hash.

set ntp timezone <zone name>
set ntp summertime <date change details>

Альтернативная настройка Catalyst

!--- This more traditional configuration creates
!--- more configuration work and NTP peerings.

set ntp client enable
set ntp server IP address of time server
set timezone zone name
set summertime date change details

Настройка маршрутизатора

!--- This is a sample router configuration to distribute
!--- NTP broadcast information to the Catalyst broadcast clients.

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


!--- To filter updates to allow only trusted sources of NTP information.

Interface to campus/management VLAN containing switch sc0
        ntp broadcast

Протокол 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 Version Строка символов, содержащая версию ПО (как в результате команды show version).
6 Платформа Аппаратная платформа, например WS-C5000, WS-C6009 или Cisco RSP.

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

Примечание: Следует отметить, что когда в коммутаторе работает CDPv1, он сбрасывает кадры v2. Когда коммутатор, работающий с CDPv2, получает на интерфейс кадры CDPv1, он в дополнение к кадрам CDPv2 начинает передачу кадров CDPv1 из этого интерфейса.

Параметр Введите Описание
9 Домен VTP Домен VTP, если настроен на устройстве.
10 Native VLAN В dot1Q это непомеченная VLAN.
11 Дуплексная и полудуплексная связь Это поле содержит двусторонние настройки посылающего порта.

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

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

set cdp enable

!--- This is the default.

set cdp version v2

!--- This is the default.

В сегментах сети, в которых требуется высокий уровень безопасности (например, демилитаризованные зоны, подключенные к Интернету), необходимо отключить 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 2900XL и 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 

Можно настроить следующие параметры:

В CatOS, начиная с версии 6.x, Cisco была добавлена аутентификация 802.1x, которая позволяет клиентам аутентифицироваться на центральном сервере перед тем, как порт будет включен для данных. Поддержка данной функции на таких платформах, как Windows XP, только начинается, однако может рассматриваться как стратегическое направление для многих предприятий. См. Защиту на уровне порта Настройки для получения информации о том, как настроить защиту на уровне порта на коммутаторах, которые выполняют программное обеспечение Cisco IOS.

Баннер регистрации

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

# 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+, чтобы определить наличие у пользователя разрешения на использование определенной команды. Это обеспечивает большую степень управления командами, которые могут быть выполнены на коммутаторе, чем при использовании механизма аутентификации. Использование учета команд позволяет выполнять аудит команд, введенных определенным пользователем при его подключении к определенному сетевому устройству.

/image/gif/paws/13414/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


!--- Redundant servers are possible.

set tacacs attempts 3

!--- This is the default.

set tacacs key key


!--- MD5 encryption key.

set tacacs timeout 15

!--- Longer server timeout (5 is default).

set authentication login tacacs enable
set authentication enable tacacs enable
set authentication login local enable
set authentication enable local enable

!--- The last two commands are the default; they allow fallback
!--- to local if no TACACS+ server available.

Дополнительные варианты

Можно использовать авторизацию 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 Увеличьте уровень по умолчанию системного журнала.
set logging server severity 4 Разрешение экспорта только системного журнала с более высоким уровнем серьезности ошибок.
set logging console disable Отключение консоли за исключением устранения неисправностей.
установить идентификационную строку сообщества SNMP только для чтения Настройка пароля для разрешения удаленного сбора данных.
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.
установить разрешение snmp rmon Включение RMON для сбора локальной статистики. Для получения дополнительных сведений см. раздел Удаленный контроль данного документа.
set ntp broadcastclient enable Включение получения точного системного времени от маршрутизатора более высокого уровня в каскаде.
set ntp timezone zone name Установка локального часового пояса для устройства.
set ntp summertime date change details Настройка летнего времени, если применимо для часового пояса.
установить аутентификацию ntp Настройка зашифрованной информации о времени в целях безопасности.
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 port speed port range auto Использование автосогласования с последними драйверами сетевых интерфейсных плат.
set port trap port range disable Обычным пользователям не требуется SNMP trap, отслеживаются только ключевые порты.

Команды настройки сервера

Команда Комментарий
set port host port range Удаление ненужной обработки порта. Данная макрокоманда включает функцию PortFast связующего дерева, отключает каналы и магистрали.
настройка блокированного порта обнаружения односвязного канала Удаление обработки ненужных портов (по умолчанию отключено на портах для подключения медного кабеля).
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 или маршрутизатор другого производителя).
установить согласование портов/отключить порт Согласование может быть несовместимым для некоторых старых устройств GE.


Дополнительные сведения


Document ID: 13414