Mac flapping: Наиболее распространенные сообщения об ошибках CatOS на коммутаторах Catalyst серии 4500/4000

21.03.2021 alexxlab

Содержание

Наиболее распространенные сообщения об ошибках CatOS на коммутаторах Catalyst серии 4500/4000

Содержание

Введение
Предварительные условия
      Требования
      Используемые компоненты
      Условные обозначения
Сообщения об ошибках на коммутаторах Catalyst серий 4500/4000
      %C4K_HWPORTMAN-4-BLOCKEDTXQUEUE:Blocked transmit queue HwTxQId[dec]on [char], count=[dec]
      %CDP-4-NVLANMISMATCH: Native vlan mismatch detected on port [dec]/[dec]
      DTP-1-ILGLCFG: Illegal config (on, isl—on,dot1q) on Port [mod/port]
      %IP-3-UDP_SOCKOVFL:UDP socket overflow
      %IP-3-UDP_BADCKSUM:UDP bad checksum
      %KERNEL-5-UNALIGNACCESS:Alignment correction made
      %MCAST-4-RX_JNRANGE:IGMP: Rcvd Report in the range
      MGMT-5-LOGIN_FAIL:User failed to log in from Console
      %PAGP-5-PORTFROMSTP / %PAGP-5-PORTTOSTP
      %SPANTREE-3-PORTDEL_FAILNOTFOUND
      %SYS-3-P2_ERROR: 1/Unknown module
      %SYS-3-P2_ERROR: 1/Have run out of vbufs (internal buffers)
      %SYS-3-P2_ERROR: Host xx:xx:xx:xx:xx:xx is flapping between ports
      %SYS-4-P2_WARN: 1/Blocked queue (tx) on port [char]
      %SYS-4-P2_WARN: 1/Filtering Ethernet MAC address of value zero
      %SYS-4-P2_WARN: 1/Invalid crc, dropped packet, count = xx
      %SYS-4-P2_WARN: 1/Invalid traffic from multicast source address
      %SYS-4-P2_WARN: 1/Astro(mod/port)
      %SYS-4-P2_WARN: 1/Tag 0

      convert_post_SAC_CiscoMIB:Nvram block [#] unconvertible
      Global checksum failed error
Дополнительные сведения

В данном документе приведена краткая поясняющая информация о наиболее распространенных ошибках, записывающихся в системный журнал (syslog), которые могут встретиться при работе с коммутаторами Cisco Catalyst серий 4500/4000, использующими программное обеспечение Catalyst OS (CatOS).

Если в данном документе нет описания какой-либо специфической ошибки, используйте приложение Error Message Decoder (Декодер сообщений об ошибке) (только для зарегистрированных пользователей). Данное приложение расшифровывает значение сообщений об ошибке, выдаваемых программным обеспечением Cisco IOS® и CatOS.

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

Примечание. Ниже приведен рекомендуемый минимум настройки системного журнала на коммутаторах Catalyst серий 4500/4000.

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

Сообщения об ошибках, приведенные в данном документе, могут встретиться при использовании коммутаторов Catalyst серий 4500/4000, а также их модификаций, таких как Catalyst 2948G, 2980G, и 4912G.

Требования

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

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

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

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

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

%C4K_HWPORTMAN-4-BLOCKEDTXQUEUE:Blocked transmit queue HwTxQId[dec]on [char], count=[dec]

Проблема

Коммутатор выдает ошибки %C4K_HWPORTMAN-4-BLOCKEDTXQUEUE:Blocked transmit queue HwTxQId[dec]on[char], count=[dec] (%C4K_HWPORTMAN-4-BLOCKEDTXQUEUE:Заблокированная передающая очередь HwTxQId[dec]on [char], count=[dec]).

Описание

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

shut/no shut для восстановления порта. Если ошибка не исчезает, подсоедините подключенное устройство к другому порту для проверки наличия ошибки там. В качестве последнего способа разблокирования очереди передачи (Tx) используйте команду hw-module reset для перезагрузки коммутатора и перезапуска линейной платы.

%CDP-4-NVLANMISMATCH: Native vlan mismatch detected on port [dec]/[dec]

Проблема

Коммутатор часто выдает сообщения syslog %CDP-4-NVLANMISMATCH (Несовпадение сети vlan обнаружено на порту [dec]/[dec]).

Описание

В данном примере показаны выходные данные консоли при этом вы видите сообщения об ошибке на коммутаторе.

%CDP-4-NVLANMISMATCH:Native vlan mismatch detected on port 4/1

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

Магистральные порты, настроенные с помощью тегирования IEEE802.1Q, могут получать как тегированный, так и нетегированный трафик. По умолчанию коммутаторы направляют нетегированный трафик по собственной VLAN, настроенной на порту. Если пакет имеет тот же VLAN ID, что и собственная VLAN исходящего порта, пакет передается нетегированным. Если VLAN ID не совпадают, коммутатор передает пакет с тегом.

Убедитесь, что собственная VLAN для магистрали 802.1Q одна и та же на обеих сторонах магистрального соединения. Если собственная VLAN на одном конце магистрали отличается от собственной VLAN на другом конце, трафик собственных VLAN с обоих концов не удастся корректно передать по магистрали. Данный сбой в передаче может привести к проблемам с соединениями в сети.

Для проверки собственной VLAN, настроенной на коммутаторе, используйте команду show trunk mod/port. В данной команде mod/port – магистральный порт. Пример выходных данных команды:

Console> (enable) show trunk 5/24

Port      Mode         Encapsulation  Status        Native vlan
--------  -----------  -------------  ------------  -----------
 5/24     desirable    dot1q          not-trunking  1

Port      Vlans allowed on trunk
--------  ---------------------------------------------------------------------
 5/24     1-1005

Port      Vlans allowed and active in management domain
--------  ---------------------------------------------------------------------
 5/24     1

Port      Vlans in spanning tree forwarding state and not pruned
--------  ---------------------------------------------------------------------
 5/24

Console> (enable)

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

DTP-1-ILGLCFG: Illegal config (on, isl—on,dot1q) on Port [mod/port]

Проблема

Коммутатор выдает ошибки DTP-1-ILGLCFG: Illegal config (on, isl—on,dot1q) on Port [mod/port] (DTP-1-ILGLCFG: Недопустимая настройка (on, isl—on,dot1q) на порту [mod/port]).

Описание

Данное сообщение может появляться, если обе стороны магистрали установлены в on (вкл), но типы инкапсуляции (isl, dot1q) не совпадают. Если режимы магистрали установлены в desirable (желательный), магистраль не будет функционировать по причине этой неправильной настройки. Для поиска и устранения неполадок проверьте выходные данные команды show trunk на обеих сторонах магистрали. Убедитесь, что типы инкапсуляции идентичны.

%IP-3-UDP_SOCKOVFL:UDP socket overflow

Проблема

Периодически в системном журнале коммутатор создает сообщения %IP-3-UDP_SOCKOVFL:UDP socket overflow (%IP-3-UDP_SOCKOVFL:переполнение UDP-сокета).

Описание

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

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

%IP-3-UDP_SOCKOVFL:UDP socket 2353 overflow
%IP-3-UDP_SOCKOVFL:UDP socket 2353 overflow
%IP-3-UDP_SOCKOVFL:UDP socket 2353 overflow
%IP-3-UDP_SOCKOVFL:UDP socket 2353 overflow

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

Увеличьте интервал опроса на станции управления сетью.
Уменьшите количество опрашиваемых объектов MIB (база управляющей информации).

В примере, приведенном в данном разделе, коммутатор получил чрезмерно большое количество пакетов, направленных на IP-адрес коммутатора (или на широковещательный адрес) с UDP-сокетом назначения 2353. Так как входящий буфер данного сокета на коммутаторе полон, коммутатор создает сообщение в системном журнале. Выполните команду show netstat udp чтобы увидеть, сколько раз коммутатор был в состоянии переполнения

Данные сообщения системного журнала указывают на то, что одна или более станций отправили большое количество UDP-трафика на определенные UPD-порты коммутатора. Если коммутатор создает чрезмерно большое количество сообщений, используйте сетевой анализатор для определения источника трафика и его уменьшения. Дополнительную информацию см. в документе Пример конфигурации Catalyst Switched Port Analyzer (SPAN) (Анализатор коммутируемого порта Catalyst).

Примечание. Не принимайте во внимание счетчик no such port. Данный счетчик показывает количество полученных коммутатором UDP-пакетов, которые были направлены на несуществующие порты.

%IP-3-UDP_BADCKSUM:UDP bad checksum (%IP-3-UDP_BADCKSUM:ошибка контрольной суммы UDP)

Проблема

Описание

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

Примечание. Отображаемый номер UDP-сокета может варьироваться или оставаться неизменным.

%IP-3-UDP_BADCKSUM:UDP bad checksum

Коммутатор создает сообщение системного журнала при обнаружении неверной контрольной суммы UDP-датаграммы, такой как SNMP-пакеты. Заголовок UDP-датаграммы содержит контрольную сумму, проверяемую принимающими устройствами сети для определения сохранения верности датаграммы в процессе передачи. Если полученная контрольная сумма не совпадает со значением в заголовке, датаграмма сбрасывается и создается сообщение об ошибке. Используйте команду show netstat udp для просмотра количества моментов обнаружения коммутатором датаграммы с ошибочной контрольной суммой.

6500-b (enable) show netstat udp

udp:
0 incomplete headers
0 bad data length fields
0 bad checksums
0 socket overflows
110483 no such ports

Данное сообщение является информационным. Причиной появления сообщения является сетевое устройство, отсылающее ошибочные пакеты. Используйте сетевой анализатор для определения источника трафика. Дополнительную информацию см. в документе Пример конфигурации Catalyst Switched Port Analyzer (SPAN) (Анализатор коммутируемого порта Catalyst).

%KERNEL-5-UNALIGNACCESS:Alignment correction made

Проблема

Периодически в системном журнале коммутатор создает сообщения %KERNEL-5-UNALIGNACCESS:Alignment correction made (%KERNEL-5-UNALIGNACCESS: произведена корректировка выравнивания).

Описание

В данном примере показаны выходные данные системного журнала при возникновении этой ошибки.

%KERNEL-5-UNALIGNACCESS:Alignment correction made at 0x80056B3C reading 0x81B82F36

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

В некоторых случаях наблюдается чрезмерно большое количество подобных сообщений. Например, данные сообщения могут заполнить лог-файл сервера syslog или консоль коммутатора. При получении чрезмерно большого количества сообщений попробуйте обновить программное обеспечение коммутатора до последней версии для техобслуживания для вашего потока ПО. Или используйте команду set logging level kernel 4 default для изменения уровня записи сообщений в системный журнал для устройства Kernel на 4 или ниже.

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

%MCAST-4-RX_JNRANGE:IGMP: Rcvd Report in the range

Проблема

Коммутатор с включенной функцией отслеживания IGMP (протокол управления группами Интернет) отображает следующее сообщение об ошибке %MCAST-4-RX_JNRANGE:IGMP: Rcvd Report in the range 01-00-5e-00-00-xx (Rcvd отчет в диапазоне).

Описание

В данном примере показаны выходные данные системного журнала при возникновении этой ошибки.

%MCAST-4-RX_JNRANGE:IGMP: Rcvd Report in the range 01-00-5e-00-00-xx

Сообщение Rcvd Report in the range (Rcvd отчет в диапазоне) является просто информационным. Коммутатор создает данное сообщение при получении отчетных IGMP-пакетов с групповым MAC-адресом, начинающимся с 01-00-5e-00-00-xx. Данный диапазон адресов Уровня 2 (L2) эквивалентен диапазону групповых адресов Уровня 3 (L3) между 224.0.0.0 и 224.0.0.255. Эти адреса зарезервированы для использования в протоколах маршрутизации и других потребностей на нижних уровнях топологии или протоколов обслуживания. В качестве примеров таких протоколов можно привести обнаружение шлюза и отчеты участников групп.

Для диагностики этой проблемы используйте средства захвата пакета, такие как sniffer, а также фильтр сообщений IGMP. Дополнительно можно использовать функцию Catalyst SPAN для копирования пакетов с порта, который, как предполагается, получает сообщения от сетевого устройства. Для подавления данных сообщений используйте команду set logging level mcast 2 default. Данная команда изменяет уровень записи многоадресных сообщений в системный журнал на 2.

Используйте порты, отображаемые командой show multicast router, и любые соединения с центром сети в качестве портов-источников SPAN. Если данные порты являются магистральными, настройте также порт назначения SPAN как магистральный порт. Используйте команду show trunk, чтобы удостовериться, что порты являются магистральными.

MGMT-5-LOGIN_FAIL:User failed to log in from Console

Проблема

Коммутатор генерирует ошибки MGMT-5-LOGIN_FAIL:User failed to log in from Console (MGMT-5-LOGIN_FAIL:Пользователь не может произвести вход из консоли).

Описание

Данное сообщение может указывать на неполадку терминального сервера, подключенного к консольному порту коммутатора. Когда консоль коммутатора подключена к асинхронной линии терминального сервера и производится мягкая перезагрузка коммутатора, на экране на несколько минут появляется «мусор» (произвольный текст). Если на коммутаторе активирован TACACS (Система управления доступом для контроллера доступа к терминалу), данное действие может продолжаться несколько дней, т. к. TACACS производит буферизацию и обработку «мусора» по частям. Решением проблемы является запуск команды no exec на асинхронной линии, к которой подключен коммутатор.

Примечание. После выполнения команды no exec сообщения будут появляться до момента очистки буфера.

Примечание. Если получено сообщение об ошибке %MGMT-5-LOGIN_FAIL:User failed to log via Telnet — max attempt reached (%MGMT-5-LOGIN_FAIL:Пользователю не удалось выполнить вход с помощью Telnet — достигнуто максимальное число попыток), попробуйте ограничить количество пользователей, использующих доступ Telnet к коммутатору.

%PAGP-5-PORTFROMSTP / %PAGP-5-PORTTOSTP

Проблема

Коммутатор часто генерирует сообщения системного журнала %PAGP-5-PORTFROMSTP и %PAGP-5-PORTTOSTP.

Описание

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

%PAGP-5-PORTFROMSTP:Port 3/3 left bridge port 3/3
%PAGP-5-PORTTOSTP:Port 3/3 joined bridge port 3/3

Средство записи сообщений системного журнала протокола агрегации портов (PAgP) сообщает о событиях, касающихся PAgP. PAgP используется для согласования соединений EtherChannel между коммутаторами. Коммутатор генерирует системное сообщение %PAGP-5-PORTFROMSTP каждый раз при потере связи на порте коммутатора. Коммутатор генерирует системное сообщение %PAGP-5-PORTTOSTP каждый раз при обнаружении связи на порте коммутатора. Данные сообщения системного журнала являются обычными информационными сообщениями, указывающими на добавление или удаление порта из связующего дерева.

Примечание. Такие сообщения могут появляться и при выключенной функции выделения каналов.

В примере, приведенном в данном разделе, коммутатор сначала теряет связь на порту 3/3 с удалением порта из связующего дерева. Затем коммутатор снова обнаруживает связь на порте и добавляет порт обратно в связующее дерево.

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

Несовпадение скорости/дуплекса
Повреждение кабеля
Неисправный сетевой адаптер (NIC) или другие неполадки на конечной станции
Неисправность порта коммутатора
Другие ошибки конфигурации

Для подавления данных сообщений используйте команду set logging level pagp 4 default для изменения уровня записи сообщений системного журнала устройства PAgP на 4 или ниже. Уровень записи для PAgP по умолчанию – 5.

%SPANTREE-3-PORTDEL_FAILNOTFOUND

Проблема

Коммутатор периодически генерирует сообщение %SPANTREE-3-PORTDEL_FAILNOTFOUND.

Описание

В данном примере показаны выходные данные системного журнала при возникновении этой ошибки.

%SPANTREE-3-PORTDEL_FAILNOTFOUND:9/5 in vlan 10 not found (PAgP_Group_Rx)

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

Данные сообщения обычно приходят вместе с сообщениями %PAGP-5-PORTFROMSTP. Эти сообщения предназначены для отладочных целей. Эти сообщения не указывают на неисправность коммутатора и не влияют на его быстродействие. Данные сообщения не записываются в системный журнал, если не было изменения конфигурации записи сообщений для устройства SPANTREE, установленного по умолчанию. Уровень записи для SPANTREE по умолчанию – 2.

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

%SYS-3-P2_ERROR: 1/Unknown module

Проблема

Сообщение об ошибке %SYS-3-P2_ERROR: 1/Unknown module отображается при установке нового модуля коммутации в коммутаторы Catalyst серий 4500/4000.

Описание

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

%SYS-3-P2_ERROR: 1/Unknown module (fru minor type 304) in slot 3

Ошибка %SYS-3-P2_ERROR: 1/Unknown module возникает, когда текущая версия программного обеспечения модуля управления Supervisor Engine не поддерживает установленный компонент оборудования.

В данном примере 18-портовый 1000BASE-X серверный модуль коммутации (WS-X4418) установлен на коммутаторе Catalyst 4500/4000 с ПО CatOS версии 4.4(1). Модулю WS-X4418 требуется версия программного обеспечения не ниже 4.5(1).

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

%SYS-3-P2_ERROR: 1/Have run out of vbufs (internal buffers)

Проблема

Коммутатор генерирует сообщения %SYS-3-P2_ERROR: 1/Have run out of vbufs (%SYS-3-P2_ОШИБКА:Нехватка vbufs (внутренних буферов), когда много хостов включены одновременно.

Описание

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

%SYS-3-P2_ERROR: 1/Have run out of vbufs(internal buffers)

Ошибки %SYS-3-P2_ERROR: 1/Have run out of vbufs(internal buffers) могут возникнуть при одновременном включении нескольких хостов. После включения хостов ошибки более не возникают.

Данные ошибки не влияют на коммутацию трафика коммутатором Catalyst. Данные сообщения являются информационными.

%SYS-3-P2_ERROR: Host xx:xx:xx:xx:xx:xx is flapping between ports

Проблема

Коммутатор генерирует сообщения %SYS-3-P2_ERROR: Host xx:xx:xx:xx:xx:xx is flapping between ports… (%SYS-3-P2_ОШИБКА:Хост xx:xx:xx:xx:xx:xx постоянно переключается между портами (flapping), где xx:xx:xx:xx:xx:xx является MAC-адресом.

Описание

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

%SYS-4-P2_WARN: 1/Host 00:50:0f:20:08:00 is flapping between port 1/2 and port 4/39

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

Сообщение указывает, что коммутатор Catalyst 4500/4000 получил MAC-адрес, уже существующий в таблице ассоциативной памяти (CAM), на порту, отличном от изначально заданного. Данная операция повторяется через короткие промежутки времени, что говорит о переключениях адреса между портами.

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

Высокая загрузка ЦП
Медленное прохождение трафика в сети
Высокая загрузка объединительной платы коммутатора

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

Если сообщение об ошибке появляется для одного или двух MAC-адресов, определите их принадлежность для установления причины. Используйте команду show cam mac_addr для установления источника изученных MAC-адресов. В данной команде mac_addr является переключающимся MAC-адресом.

После определения портов, между которыми происходит переключение MAC-адреса, отследите MAC-адрес. Подключитесь к промежуточному устройству между коммутатором Catalyst 4500/4000 и устройством, имеющим проблемный MAC-адрес. Проводите данную операцию, пока не установите источник и способ его подключения к сети.

Примечание. Так как MAC-адрес переключается между двумя портами, отследите оба пути.

В данном примере показано отслеживание обоих путей получения MAC-адреса:

Примечание. Предполагается, что данное сообщение получено и начато его изучения.

%SYS-4-P2_WARN: 1/Host 00:50:0f:20:08:00 is flapping between port 1/2 and port 4/39

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

Рассмотрите порт 1/2 и выполните команду show cam dynamic 1/2.
Если в списке MAC-адресов, полученном с данного порта, находится адрес 00:50:0f:20:08:00, определите, один или несколько хостов зарегистрировано на данном порту.
Зная, один хост или несколько, исследуйте устройство:
- Если подключен один хост (00:50:0f:20:08:00), проверьте другой зарегистрированный порт на предмет двойного подключения хоста к коммутатору.
  В данном примере другой порт – 4/39.
- Если хост имеет соединения с другими устройствами, которые могут быть в свою очередь соединены с коммутатором, попытайтесь отследить промежуточные устройства.
  Для устройств Cisco выполните команду show cdp neighbors mod/port detail. В выходных данных будет содержаться информация о промежуточных устройствах.
  Пример выходных данных:
```
Cat4K> (enable) show cdp neighbors 1/2 detail

Port (Our Port): 1/2
Device-ID: brigitte
Device Addresses:
IP Address: 172.16.1.1
Novell address: aa.0
Holdtime: 171 sec
Capabilities: ROUTER
Version:
Cisco Internetwork Operating System Software
IOS (tm) 2500 Software (C2500-JS-L), Version 12.0(7)T,  RELEASE SOFTWARE (fc2)

Copyright (c) 1986-1999 by cisco Systems, Inc.
Compiled Mon 06-DEC-99 17:10 by phanguye
Platform: cisco 2500
Port-ID (Port on Neighbors's Device): Ethernet0
VTP Management Domain: unknown
Native VLAN: unknown
Duplex: half
System Name: unknown
System Object ID: unknown
Management Addresses: unknown
Physical Location: unknown

Cat4K> (enable)
```
Установите Telnet-сессию с устройством и проследите маршрут MAC-адреса.
В данном примере IP-адрес – 172.16.1.1.
Повторите операцию для всех MAC-адресов, которые переключаются, в соответствии с сообщениями об ошибках.
Создайте простую схему устройства-источника с этим MAC-адресом и физическими соединениями (портов коммутатора Catalyst 4500/4000), между которыми переключается этот MAC-адрес.
Схема поможет определить, являются ли порт и путь правильными для вашей сети.
Если проверка показала, что оба порта с переключающимся MAC-адресом обеспечивают путь к сетевому узлу, существует вероятность неполадки связующего дерева. Информацию по изолированию и устранению неполадок с нежелательными петлями в сети см. в документе Проблемы протокола связующего дерева и смежные вопросы.
В больших сетях, объединяющих большое количество хостов разных производителей, возникает сложность при попытке проследить хост, используя только MAC-адрес. Используйте поисковую утилиту IEEE OUI and Company_id Assignments для отслеживания данных MAC-адресов. Данный список является клиентской частью базы данных, где все MAC-адреса, приписанные всем производителям, зарегистрированы IEEE. Введите первые три октета MAC-адресов в поле Search for: данной страницы для поиска производителя данного устройства. Первыми тремя октетами в данном примере являются 00:50:0f.

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

Проблема резервирования NIC сервера — сервер с дважды подключенной NIC, которая неправильно функционирует и не соответствует стандартам. Сервер использует один MAC-адрес для обоих портов, подсоединенных к одному коммутатору.
Переключение протокола Hot Standby Router Protocol (HSRP) — переключение протокола маршрутизатора горячего резервирования (HSRP) может вызывать появление подобных сообщений в консоли модуля управления Supervisor Engine. Если реализация протокола HSRP в сети нестабильна, см. документ Общие сведения и устранение неполадок с HSRP в сетях с коммутаторами Catalyst для решения проблемы.
Неправильная настройка EtherChannel — неправильная настройка соединения EtherChannel также может вызвать подобные неполадки. Если порты, описанные в сообщении, находятся в одной группе каналов, проверьте настройку EtherChannel и см. документ Общие сведения о балансировке и резервировании EtherChannel на коммутаторах Catalyst для устранения неполадок в настройке.
Отражение пакетов хостом обратно в сеть — отражение пакетов хостом обратно в сеть также может вызвать переключение. Обычно, основной причиной отражения пакетов является неисправная NIC или какая-либо неполадка физического интерфейса хоста, подключенного к порту.
Если отражение пакетов хостом является основной причиной, воспользуйтесь анализатором пакетов и исследуйте трафик, идущий в и из портов, обозначенных в сообщениях. Если хост отражает пакеты, обычно в трассировке будут зарегистрированы дублирующие пакеты. Дублирующие пакеты являются возможным признаком переключения MAC-адреса.
Подробную информацию по настройке порта для использования анализатора пакетов см. в документе Настройка SPAN и RSPAN.
Программный или аппаратный отказ — если после попытки устранить неполадки с сообщением о переключениях с помощью инструкций, приведенных в данном разделе, проблема не исчезла, обратитесь в Службу технической поддержки Cisco за дальнейшей информацией. Будьте готовы предоставить документальную информацию, собранную во время выполнения ваших действий. Данная информация позволит выполнить поиск и устранение неполадок быстрее и эффективнее.

%SYS-4-P2_WARN: 1/Blocked queue (tx) on port [char]

Проблема

Коммутатор генерирует сообщения Blocked queue (tx) on port [char](%SYS-4-P2_ПРЕДУПРЕЖДЕНИЕ:1/Заблокированная очередь (tx) на порту [char].

Описание

В данном примере показаны выходные данные системного журнала при возникновении этой ошибки.

%SYS-4-P2_WARN: 1/Blocked queue (tx) on port 3/3
%SYS-4-P2_WARN: 1/Blocked queue on gigaport 3, ( 8671 : 0)

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

Несовпадение дуплекса
Повреждение кабеля
Кабельная разводка типа 1
Повреждение портов
Аппаратная проблема внешнего подключенного устройства

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

В нормальных условиях очередь Tx может быть заблокирована только на, приблизительно, 20 секунд. Длительная блокировка указывает на серьезную проблему. Как результат, заблокированный счетчик очереди Tx увеличивается, если очередь не освобождается для гигапорта в течение 35 секунд.

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

%SYS-4-P2_WARN: 1/Filtering Ethernet MAC address of value zero

Проблема

Коммутатор генерирует сообщения Filtering Ethernet MAC address of value zero (%SYS-4-P2_ПРЕДУПРЕЖДЕНИЕ:Фильтрация нулевых значений MAC-адресов Ethernet).

Описание

В данном примере показаны выходные данные системного журнала при возникновении этой ошибки.

%SYS-4-P2_WARN: 1/Filtering Ethernet MAC address of value zero
                from agent host table interface
%SYS-4-P2_WARN: 1/Filtering Ethernet MAC address of value zero
                from agent host table interface

Коммутатор создает сообщение системного журнала Filtering Ethernet MAC address of value zero при получении пакетов с исходным MAC-адресом 00-00-00-00-00-00. Данный MAC-адрес является недействительным.

Сообщение указывает на то, что коммутатор отказался принять недействительный MAC-адрес. Несмотря на это, коммутатор передает трафик, полученный с нулевого MAC-адреса.

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

Генератор трафика, такой как Spirent SmartBits
Некоторые типы серверов, такие как распределяющие нагрузку серверы IBM WebSphere
Неправильно настроенный маршрутизатор или оконечная рабочая станция, т.е. устройство, передающее нулевые широковещательные пакеты
Неисправная NIC

%SYS-4-P2_WARN: 1/Invalid crc, dropped packet, count = xx

Проблема

Коммутатор с модулем управления Supervisor Engine II (WS-X4013=) создает сообщение, показанное в данном разделе, и происходит частичная или полная потеря соединений в сети. Потеря совместимости может повлиять только на часть портов коммутатора, в которую могут войти порты восходящей связи.

%SYS-4-P2_WARN: 1/Invalid crc, dropped packet, count = xx

Описание

В данном примере показаны выходные данные консоли при возникновении этой ошибки.

%SYS-4-P2_WARN: 1/Invalid crc, dropped packet, count = 590073  
%SYS-4-P2_WARN: 1/Invalid crc, dropped packet, count = 594688

Также иногда появляется следующее сообщение:

%SYS-4-P2_WARN: 1/Astro(3/4) - management request timed out

Примечание. При получении сообщения %SYS-4-P2_WARN: 1/Astro(3/4) — management request timed out (%SYS-4-P2_WARN:1/Astro(3/4) – тайм-аут запрошен управлением) см. раздел %SYS-4-P2_WARN: 1/Astro(mod/port) данного документа.

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

Выполните следующие действия по устранению неполадок с сохранением выходных данных команд для каждого шага:

Примечание. Обратитесь в Службу технической поддержки Cisco для получения помощи при устранении неполадок.

Используйте следующие команды:
1. show logging buffer -1023
2. show tech-support
3. show health 1
4. Выходные данные 1
Введите одну из этих команд пять раз через разные промежутки времени и проверьте счетчик InvalidPacketBufferCrcs:
- show nvramenv 1 — в программном обеспечении CatOS версии 6.1(1) или более поздней.
```
Cat4k> (enable) show nvramenv 1

PS1="rommon ! >"
?="0"
DiagBootMode="post"
MemorySize="64"
ResetCause="20"
AutobootStatus="success"
InvalidPacketBufferCrcs="82325"
```
- show env 1 — в программном обеспечении CatOS версии 5.5(19) или более ранней.
Как только выполнение команды будет повторено, проверьте наличие резкого увеличения значения счетчика InvalidPacketBufferCrcs.
```
cat4k> (enable) show nvramenv 1

PS1="rommon ! >"
?="0"
DiagBootMode="post"
MemorySize="64"
ResetCause="20"
AutobootStatus="success"
InvalidPacketBufferCrcs="82763"
```
Примечание. Если наблюдается небольшое значение InvalidPacketBufferCrcs в выходных данных и используется версия программного обеспечения CatOS ранее 5.5.10, 6.2.3 или 6.3.1, обновите до более поздней версии. Возможно, произошла ошибка Cisco ID CSCdu48749 (только для зарегистрированных пользователей) и CSCdt80707 (только для зарегистрированных пользователей). Для получения дополнительной информации см. следующее уведомление: Потеря портами Catalyst 4000 активного состояния VLAN, приводящая к потере пакетов.

Если произошло значительное увеличение показаний счетчика InvalidPacketBufferCrcs, используйте команду reset для мягкой перезагрузки коммутатора.

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

cat4k> (enable) reset

This command will reset the system.
Do you want to continue (y/n) [n]? y

nodcsw0nm1> (enable)
WS-X4013 bootrom version 5.4(1), built on 2000.02.17 18:28:09
H/W Revisions:    Crumb: 5    Rancor: 8    Board: 2
Supervisor MAC addresses: 00:0a:8a:6d:92:00 through 00:0a:8a:6d:95:ff
(1024 addresses)
Installed memory: 64 MB
Testing LEDs.... done!
The system will autoboot in 5 seconds.
Type control-C to prevent autobooting.

rommon 1 >
The system will now begin autobooting.
Autobooting image: "bootflash:cat4000-k9.6-3-9.bin"
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC################################
Starting Off-line Diagnostics
Mapping in TempFs
Board type is WS-X4013
DiagBootMode value is "post"
Loading diagnostics...

Power-on-self-test for Module 1:  WS-X4013
Status: (. = Pass, F = Fail)
uplink port 1: .       uplink port 2: F       eobc port: .
processor: .           cpu sdram: .           eprom: .
nvram: .               flash: .               enet console port: .
switch 0 port 0: .     switch 0 port 1: .     switch 0 port 2: .
switch 0 port 3: .     switch 0 port 4: .     switch 0 port 5: .
switch 0 port 6: .     switch 0 port 7: .     switch 0 port 8: .
switch 0 port 9: .     switch 0 port 10: .    switch 0 port 11: .
switch 0 registers: .  switch 0 sram: .       switch 1 port 0: .
switch 1 port 1: .     switch 1 port 2: .     switch 1 port 3: .
switch 1 port 4: .     switch 1 port 5: .     switch 1 port 6: .
switch 1 port 7: .     switch 1 port 8: .     switch 1 port 9: .
switch 1 port 10: .    switch 1 port 11: .    switch 1 registers: .
switch 1 sram: .       switch 2 port 0: F     switch 2 port 1: F
switch 2 port 2: F     switch 2 port 3: F     switch 2 port 4: F
switch 2 port 5: F     switch 2 port 6: F     switch 2 port 7: F
switch 2 port 8: F     switch 2 port 9: F     switch 2 port 10: F
switch 2 port 11: F    switch 2 registers: .  switch 2 sram: F
Module 1 Failed

Exiting Off-line Diagnostics
Failed Module Bringup Process
Use 'show test 1' to see results of tests.

!--- Выходные данные команды подавлены.

После перезагрузки коммутатора выполните команду show test 1.
Если в выходных данных отображаются диагностические неполадки, произведите перезагрузку коммутатора путем снятия/подачи питания.
После перезагрузки коммутатора выполните команду show test 1 снова и проверьте прохождение диагностических тестов.
Обратитесь в Службу технической поддержки Cisco, основываясь на собранных данных:
- Если коммутатор снова не прошел диагностические тесты, скорее всего неисправность заключается в модуле управления Supervisor Engine. Обратитесь в Службу технической поддержки Cisco для получения дальнейших инструкций.
- Если после перезагрузки со снятием питания диагностические тесты выполняются верно, обратитесь в Службу технической поддержки Cisco с информацией, собранной при выполнении других действий данной процедуры.
Примечание. Если при устранении неполадок не было обращений в службу технической поддержки Cisco, необходимо предоставить информацию в порядке ее сохранения.

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

%SYS-4-P2_WARN: 1/Invalid traffic from multicast source address

Проблема

Коммутатор создает сообщения Invalid traffic from multicast source address (%SYS-4-P2_ПРЕДУПРЕЖДЕНИЕ:1/Неверный трафик с исходного адреса многоадресной передачи.

Описание

В данном примере показаны выходные данные системного журнала при возникновении этой ошибки.

SYS-4-P2_WARN: 1/Invalid traffic from multicast source address
               81:00:01:00:00:00 on port 2/1
%SYS-4-P2_WARN: 1/Invalid traffic from multicast source address
                81:00:01:01:00:00 on port 2/1

Коммутатор создает сообщение системного журнала Invalid traffic from multicast source address при получении пакетов с MAC-адресом многоадресной передачи в качестве исходного. Использование широковещательного MAC-адреса или MAC-адреса многоадресной передачи в качестве исходного MAC для кадра не является стандартным поведением. Несмотря на это, коммутатор передает трафик с MAC-адреса многоадресной передачи.

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

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

Генератор трафика, такой как SmartBits
Устройства сторонних производителей, использующие MAC-адрес многоадресной передачи, такие как межсетевой экран с распределением нагрузки или серверное оборудование.

%SYS-4-P2_WARN: 1/Astro(mod/port)

Проблема

Коммутатор создает сообщения %SYS-4-P2_WARN: 1/Astro(6/6)….

Описание

Данное сообщение об ошибке указывает на то, что модуль управления Supervisor Engine потерял связь с компонентом на линейной плате. Модуль управления Supervisor Engine отслеживает любые тайм-ауты, ассоциированные с данным соединением. Существует множество возможных причин данной неисправности. Дополнительную информацию по данному сообщению об ошибке и возможных причинах см. в документе Общие сведения и устранение тайм-аутов Astro/Lemans/NiceR в коммутаторах Catalyst серий 4000/4500

%SYS-4-P2_WARN: 1/Tag 0

Коммутатор создает сообщения %SYS-4-P2_WARN: 1/Tag 0….

В данном примере показаны выходные данные системного журнала при возникновении этой ошибки.

%SYS-4-P2_WARN: 1/Tag [dec] on packet from [ether] port [chars],
                but port's native vlan is [dec]

Это сообщение указывает, что тегированный пакет 802.1Q получен на не магистральный порт. VLAN, полученная из тега пакета, отличается от собственной VLAN порта. В сообщении об ошибке:

Тег Tag [dec] – идентификатор VLAN из пакета.
[ether] – MAC-адрес хоста.
port [chars] — идентификатор порта.
Второй [dec] – номер собственной VLAN порта.

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

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

convert_post_SAC_CiscoMIB:Nvram block [#] unconvertible

Проблема

Коммутатор периодически создает сообщения syslog convert_post_SAC_CiscoMIB: .

Описание

В данном примере показаны выходные данные консоли при появлении данного сообщения.

convert_post_SAC_CiscoMIB:Nvram block 0 unconvertible: )
convert_post_SAC_CiscoMIB:Nvram block 1 unconvertible: )
convert_post_SAC_CiscoMIB:Nvram block 2 unconvertible: )

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

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

Данное сообщение является информационным. Сравните предыдущую конфигурацию с текущей для проверки точности конвертирования конфигурационной информации.

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

Global checksum failed error (Глобальная ошибка контрольной суммы)

Проблема

Данное сообщение об ошибке может появиться на коммутаторах Catalyst серий 4000/4500 и 6000/6500, использующих программное обеспечение Catalyst OS.

Сообщение об ошибке Global checksum failed может появиться в выходных данных команды show version.

4000-Switch> (enable) show version
WS-C4006 Software, Version NmpSW: 7.6(2)
Copyright (c) 1995-2003 by Cisco Systems, Inc.
NMP S/W compiled on Jun 25 2003, 23:00:25
GSP S/W compiled on Jun 25 2003, 17:11:56

System Bootstrap Version: 5.4(1)

Hardware Version: 3.2  Model: WS-C4006  Serial #: FOX053701JY

Mod Port Model              Serial #              Versions
--- ---- ------------------ -------------------- -------------------------------
--
1   2    WS-X4013           JAB054207A0          Hw : 3.2
                                                 Gsp: 7.6(2.0)
                                                 Nmp: 7.6(2)
2   48   WS-X4148-RJ45V     JAB05410EQF          Hw : 1.6
3   48   WS-X4148-RJ45V     JAB05410ES5          Hw : 1.6
4   48   WS-X4148-RJ45V     JAB0541070L          Hw : 1.6
5   48   WS-X4148-RJ45V     JAB05410ESC          Hw : 1.6

       DRAM                    FLASH                   NVRAM
Module Total   Used    Free    Total   Used    Free    Total Used  Free
------ ------- ------- ------- ------- ------- ------- ----- ----- -----
1       65536K  40935K  24601K  16384K  10543K   5841K  480K  198K  282K

Global checksum failed.

Uptime is 306 days, 8 hours, 0 minute

Сопутствующее сообщение NVRAM: F может появиться в выходных данных команды show test.

6000-Switch> show test 1

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


Module 1 : 2-port 1000BaseX Supervisor
Network Management Processor (NMP) Status: (. = Pass, F = Fail, U = Unknown)
  ROM:  .   Flash-EEPROM: .   Ser-EEPROM: .   NVRAM: F   EOBC Comm: .

Line Card Status for Module 1 : PASS

Port Status :
  Ports 1  2
  -----------
        .  .

!--- Выходные данные команды подавляются.

Описание

Глобальная ошибка контрольной суммы означает, что при следующей перезагрузке блока содержание NVRAM будет потеряно по причине ошибки контрольной суммы, произошедшей в момент чтения конфигурации. Обычно это не является аппаратной ошибкой, но коммутатор самостоятельно ее исправляет. Это не влияет на действующий коммутатор, пока не делаются изменения конфигурации во время нахождения коммутатора в данном состоянии. В большинстве случаев перезапуск решает проблему контрольной суммы, т. к. происходит ее перерасчет. Эта проблема описана в ошибке Cisco ID CSCdx87646 (только для зарегистрированных пользователей).

Решение

Выполните эти действия для восстановления коммутатора из состояния неисправности:

Произведите резервное копирование конфигурации коммутатора. Дополнительную информацию по резервному копированию конфигурации см. в документе Выгрузка конфигурационных файлов на TFTP-сервер.
Произведите перезапуск модуля Supervisor с помощью команды reset supervisor_module_#.
После загрузки коммутатора выполните команды show version и show test для проверки правильности выходных данных.
Проверьте находящуюся на коммутаторе конфигурацию и при необходимости восстановитесь с резервной копии.

Коммутатор Eltex MES3116F

Сетевые интерфейсы	12 x 100/1000 SFP 4 x 10/100/1000 Combo RJ45/SFP 2 x 1000/10G SFP/SFP+
Возможность монтажа в стойку	есть, крепления в комплекте
Консольный порт	RS-232/RJ45
Функции интерфейсов	Защита от блокировки очереди (HOL) Поддержка обратного давления (Back pressure) Поддержка Auto MDI/MDIX Поддержка сверхдлинных кадров (Jumbo frames) Управление потоком (IEEE 802.3X)
Функции при работе с МAC-адресами	Таблица MAC-адресов 16K Независимый режим обучения в каждой VLAN Поддержка многоадресной рассылки (MAC Multicast Support) Регулируемое время хранения MAC-адресов Статические записи MAC (Static MAC Entries) Логирование событий MAC Flapping
Поддержка VLAN	До 4K VLAN Поддержка Voice VLAN Зеркалирование VLAN (VLAN mirroring) Поддержка 802.1Q Поддержка Q-in-Q Поддержка Selective Q-in-Q Поддержка GVRP
Функции L2 Multicast	Поддержка 1K групп Поддержка профилей Multicast Поддержка статических Mullticast групп Поддержка IGMP Snooping v1, 2, 3 Поддержка IGMP snooping Fast Leave на основе порта/хоста Поддержка авторизации IGMP через RADIUS Поддержка MLD Snooping v1,2 Поддержка IGMP Querier Multicast TV VLAN Поддержка MVR
Функции L2	Поддержка протокола STP (Spanning Tree Protocol) Поддержка 32 независимых STP процессов Поддержка Spanning Tree Fast Link option Поддержка STP Mulitprocess (802.1d) Поддержка RSTP (Rapid spaning tree protocol) Поддержка Multiple Spanning Tree- MSTP (IEEE802.1s) Поддержка EAPS Поддержка STP Root Guard Поддержка BPDU Filtering Поддержка STP BPDU Guard Поддержка Per-device Loopback Detection (LBD) Поддержка ERPS (G.8032v2) Поддержка Per-device Loopback Detection (LBD) Изоляция портов
Функции Link Aggregation	Создание групп LAG Объединение каналов с использованием LACP Поддержка LAG Balancing Algorithm
Поддержка IPv6	Функциональность IPv6 Host Совместное использование IPv4, IPv6
Функции L3	Количество IP-интерфейсов: 512 до 12 К записей маршрутизации устройств с использованием протоколов IPv4/v6 до 12K для маршрутов IРv4 до 3K для маршрутов IРv6 Клиенты BootP и DHCP(Dynamic Host Configuration Protocol) Статические IP-маршруты Динамическая маршрутизация RIPv2 Поддержка ARP (Address Resolution Protocol), ARP Proxy Динамическая маршрутизация OSPFv2 Поддержка VRRP
Сервисные функции	Виртуальное тестирование кабеля (VCT) Диагностика оптического трансивера Green Ethernet
Функции обеспечения безопасности	DHCP snooping Опция 82 протокола DHCP Опция 18 и 37 протокола DHCP IP Source address guard Dynamic ARP Inspection (Protection) Поддержка sFlow Проверка подлинности на основе MAC-адреса, ограничение количества MAC-адресов, статические MAC-адреса Проверка подлинности по портам на основе 802.1x Guest VLAN Система предотвращения DoS атак Сегментация трафика Защита от несанкционированных DHCP серверов Фильтрация DHCP клиентов Предотвращение атак BPDU Фильтрация NetBIOS/NetBEUI PPPoE Intermidiate agent
Функции обеспечения безопасности	DHCP snooping Опция 82 протокола DHCP UDP Relay, DHCP Relay IP Source address guard Dynamic ARP Inspection (Protection) Проверка подлинности на основе MAC-адреса, ограничение количества MAC-адресов, статические MAC-адреса Проверка подлинности по портам на основе 802.1x SSL v1/v2/v3 Защита от атак BPDU PPPoE Intermediate agent
AAA	Web-based Authentication (WAC) (Управление доступом на основе порта/хоста, Динамическое назначение VLAN) Управление доступом на основе MAC-адресов Guest VLAN
Списки управления доступом ACL	L2-L3-L4 ACL (Access Control List) Поддержка Time-Based ACL IPv6 ACL до 2048 правил доступа ACL на основе: Порта коммутатора / Приоритета 802.1p / VLAN ID / Ether type / DSCP / Типа протокола / Номера порта TCP/UDP / Содержимого пакета, определяемого пользователем
Основные функции качества обслуживания (QoS) и ограничения скорости	Поддержка QoS/COS Статистика QoS Ограничение скорости на портах (shaping, policing) Поддержка до 8 приоритетных очередей Поддержка класса обслуживания 802.1p Защита от широковещательного шторма Управление полосой пропускания Обработка очередей по алгоритмам Strict/Weighted Round Robin (WRR) priority Три цвета маркировки Классификация трафика на основании на основании ACL Назначение меток CoS/DSCP на основании ACL
ОАМ	802.3ah Ethernet Link OAM Dying Gasp 802.1ag Connectivity Fault Management (CFM) 802.3ah Unidirectional LinkDetection (протокол однонаправленных связей)
Основные функции управления	Загрузка и выгрузка файла настройки по TFTP Протокол SNMP Интерфейс командной строки (CLI) Web-интерфейс Syslog SNTP (Simple Network Time Protocol) Traceroute LLDP (802.1ab) + LLDP MED Управление контролируемым доступом – уровни привелегий Блокировка интерфейса управления Локальная аутентификация Фильтрация IP-адресов для SNMP Клиент RADIUS, TACACS+ (Terminal Access Controller Access Control System) Сервер SSH Поддержка SSL Поддержка макрокоманд Журналирование вводимых команд Системный журнал Автоматическая настройка DHCP DHCP Relay (Поддержка IPv4) DHCP Option 12 DHCP Relay Option 82 Добавление тега PPPoE Circuit-ID Flash File System Команды отладки Механизм ограничения трафика в сторону CPU Шифрование пароля Восстановление пароля Ping (поддержка IPv4/IPv6) Multiple IP Interface Сервер FTP
Функции мониторинга	Статистика интерфейсов Удаленный мониторинг RMON/SMON Поддержка мониторинга загрузки CPU по задачам Мониторинг памяти Мониторинг температуры Мониторинг TCAM
MIB	RFC 1065, 1066, 1155, 1156, 2578 MIB Structure RFC 1212 Concise MIB Definitions RFC 1213 MIB II RFC 1215 MIB Traps Convention RFC 1493, 4188 Bridge MIB RFC 1157, 2571-2576 SNMP MIB RFC 1901-1908, 3418, 3636, 1442, 2578 SNMPv2 MIB RFC 271,1757, 2819 RMON MIB RFC 2465 IPv6 MIB RFC 2466 ICMPv6 MIB RFC 2737 Entity MIB RFC 4293 IPv6 SNMP Mgmt Interface MIB Private MIB RFC 3289 DIFFSERV MIB RFC 2021 RMONv2 MIB RFC 1398, 1643, 1650, 2358, 2665, 3635 Ether-like MIB RFC 2668 802.3 MAU MIB RFC 2674, 4363 802.1p MIB RFC 2233, 2863 IF MIB RFC 2618 RADIUS Authentication Client MIB RFC 4022 MIB для TCP RFC 4113 MIB для UDP RFC 3298 MIB для Diffserv RFC 2620 RADIUS Accounting Client MIB RFC 2925 Ping & Traceroute MIB RFC 768 UDP RFC 791 IP RFC 792 ICMPv4 RFC 2463, 4443 ICMPv6 RFC 4884 Extended ICMP для поддержки сообщений Multi-Part RFC 793 TCP RFC 2474, 3260 Определение поля DS в заголовке IPv4 и Ipv6 RFC 1321, 2284, 2865, 3580, 3748 Extensible Authentication Protocol (EAP) RFC 2571, RFC2572, RFC2573, RFC2574 SNMP RFC 826 ARP
Энергопотребление	до 50 Вт
Климатические условия эксплуатации	температура от -10 до 45° C при влажности от 0 до 80% (без конденсации)

Switch operations – часть 2 – Twistedminds

Честно скажу, не сразу решился писать вторую часть, так как она будет, в какой-то степени, дублировать мою предыдущую статью – http://twistedminds.ru/2012/12/tcam/, однако здравый смысл победил лень. Ну и повторение – мать учения, ага. В этой части мы более подробно поговорим про CAM и TCAM таблицы и их структуру, выясним что такое LOU, не забыв снабдить все это дело сочным примером. So, let’s go.

Content-Addressable Memory

Из пакета/фрейма только-только упавшего на входящий порт в CAM таблицу попадает доселе неизвестный коммутатору MAC адреса источника. Это мы знаем из предыдущей статьи. Вместе с этим MAC адресом в таблицу попадает еще и timestamp, указывающий на то, когда этот адрес был заучен. CAM таблицы довольное большие, но не бесконечные, по этому через 300 секунд (значение по умолчанию) данные из CAM таблицы будут удалены в том случае, если данное устройство не давало о себе знать.

Переопределить значение по умолчанию можно с помощью команды:

Switch(config)# mac address-table aging-time #_seconds

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

Switch(config)# mac address-table static mac-address vlan #_vlan interface #_iface

Что может быть полезно если вы соберетесь настроить у себя Microsoft NLB Cluster, например (http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml).

Так как MAC адрес является уникальным идентификатором устройства, то коммутатор, получив тот же Source MAC на другом порту заменит эту информацию в CAM таблицы. Такая ситуация называется address flapping. На практике такие события возникают в результате ошибок конфигурации LAG или при возникновении петель.

В CAM таблице хранятся бинарные данные. Эта таблица позволяет в ответ на запрос с данными (MAC адрес) получить адрес ячейки в которой эти данные хранятся. В обычной RAM все происходит с точностью до наоборот – вы отдаете адрес ячейки и получаете данные.

Посмотреть содержимое CAM таблицы можно с помощью:

Switch# show mac address-table dynamic

Вычислить местонахождение устройства:

Switch#show mac address-table dynamic address F46D.04AD.3BF3
Unicast Entries
 vlan   mac address     type        protocols               port
-------+---------------+--------+---------------------+--------------------
   1    f46d.04ad.3bf3   dynamic ip,ipx,assigned,other TenGigabitEthernet1/51

Проверить размер CAM таблицы:

Switch#show mac address-table count
MAC Entries for all vlans:
Dynamic Unicast Address Count:                  126
Static Unicast Address (User-defined) Count:    0
Static Unicast Address (System-defined) Count:  8
Total Unicast MAC Addresses In Use:             134
Total Unicast MAC Addresses Available:          55000
Multicast MAC Address Count:                    9
Total Multicast MAC Addresses Available:        32768

Вычислить путь до устройства (layer 2 traceroute):

CoreSwitchA#traceroute mac 7081.0553.2ef2 f46d.04ad.3bf3 detail
Source 7081.0553.2ef2 found on CoreSwitchA[WS-C4948E] (192.168.1.254)
1 CoreSwitchA / WS-C4948E / 192.168.1.254 :
                Gi1/47 [auto, auto] => Te1/51 [full, auto]
2 C2960S-24-B02 / WS-C2960S-24TS-L / 172.16.99.22 :
                Gi1/0/27 [auto, auto] => Gi1/0/24 [auto, auto]
Destination f46d.04ad.3bf3 found on C2960S-24-B02[WS-C2960S-24TS-L] (172.16.99.22)
Layer 2 trace completed.

Ternary Content-Addressable Memory

Для фильтрации и контроля определенного трафика мы склонны использовать ACL. ACL состоит из нумерованного списка правил, цель которых определить что делать с тем или иным типом трафика базируясь на наборе атрибутов. Каждое правило в списке называется Access Control Entity – ACE. Если бы мы сверялись с каждым ACE для каждого пакета, то о маршрутизации на скорости интерфейса и не пришлось бы мечтать. Представьте развесистые ACL, висящие и для входящего и для исходящего трафика, добавьте к ним соус из ACL, маркирующий трафик согласно политике QOS. В результате вместо заветных 1gbit/s мы получим блюдо 2mbit/s. Срамота, а не process switching.

По этому существование способа сделать поиск по всем ACE одновременно и параллельно с layer 2/layer 3 forwarding просто жизненно необходимо. Here comes TCAM.

Операционная система Cisco IOS обладает двумя автономными компонентами по работе с TCAM:

Feature Manager (FM) – процесс, компилирующий ACE в TCAM.
Switching Database Manager (SDM) – процесс, позволяющий распределить TCAM на различные области иначе, чем это предполагается в некой усредненной конфигурации из коробки. Например, таким образом можно “перебросить” не используемые QOS ACE на PBR ACE (см. SDM Templates).

TCAM, так же как и CAM позволяет за одну операцию производить поиск по всей таблице целиком. Тогда как CAM использует в качестве индекса MAC адрес, а в результате ожидает увидеть порт с TCAM все немного сложнее. Бинарная природа CAM прекрасно работает там, где нужны четкие запросы, тогда как ACL куда абстрактнее MAC адресов. Нет проблем, когда существует ACE конструкция типа:

Switch(config)# access-list 100 permit ip host 1.1.1.1 host 2.2.2.2

но что делать, когда на поле врываются маски подсети, определяющие какие биты имеют смысл, а какие можно опустить? Поэтому к бинарным 1, 0 в CAM добавляется третье значение – X и она становится TCAM.

Значения (values) – 134 битное поле, содержащее адрес отправителя, адрес получателя и другие значения, на основании которых можно производить выборки.
Маски – 134 битное поле, использующее тот же формат, что и значения. Маски выбирают только те значения, которые могут быть интересными.
Результат – результатом может стать как простое решение разрешить или запретить обработку пакета (если мы говорим о обычных Security ACL), так и указатель на индекс QOS политики или, даже, указатель на адрес next hop устройства в таблицы маршрутизации в случае с PBR.

Рассмотрим простой ACL:

access-list 100 permit tcp host 10.0.0.1 172.16.20.0 0.0.0.255 eq 80
access-list 100 permit udp host 10.0.1.1 192.168.100.0 0.0.0.255 eq domain
access-list 100 deny ip any 10.100.0.0 0.0.63.255
access-list 100 deny udp any 10.100.64.0 0.0.63.255 range 100 1000

И скомпилируем его в TCAM:

Самые внимательные из вас наверняка заметили новый термин – LOU или Logical Operation Unit. Выборка на основе значения и маски работает только тогда, когда были переданы конкретные значения Layer 4 информации (например eq domain) или их не было передано вообще. Однако TCAM предоставляет механизм поиска по вхождениям, включая различные логические операции с layer 4 информацией, такие как gt, lt, neq, range. Такие выборки портов размещаются в LOU и могут использоваться несколькими ACE.

IOS не предоставляет никаких механизмов по манипуляцией с TCAM за исключением SDM.

Ну и the last, but not the least – TCAM – это не обязательный компонент MLS. Вместо него может использоваться SRAM, но это уже совсем другая история.

Настройка mac-notification на коммутаторах 2800,2850,3400,3450,8200,8300,6500

Инструкция по настройке функционала mac notification на коммутаторах 2800,2850*,3400,3450,8200,8300,6500 (на коммутаторе 2850 настройка незначительно отличается и приводится в конце инструкции).

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

Трапы бывают 3 видов :

.1.3.6.1.4.1.27514.101.107.1 — Added
.1.3.6.1.4.1.27514.101.107.2 — Removed
.1.3.6.1.4.1.27514.101.107.3 – Moved

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

В режиме глобальной конфигурации

mac-address-learning cpu-control — включаем если до этого не был включен
snmp-server enable — включаем если до этого не был включен
snmp-server enable traps — включаем трапы глобально
snmp-server enable traps mac-notification — включаем отправку трапов mac-notification
snmp-server trap-source {IP} — указываем IP адрес с которого будут отправляться трапы
snmp-server {IP} v2c TRAP – указываем IP адрес хоста на который будут уходить трапы. В данной настройке указываем версию протокола SNMP и имя community
mac-address-table notification – включаем уведомления таблицы мак адресов
mac-address-table notification – так же можно настроить доп. Параметры

history-size History Size — Настройка размера таблицы истории, команда no восстанавливает настройки по умолчанию

interval Interval time — Настройка интервала для отправки MAC уведомлений, команда no восстанавливает настройки по умолчанию

В режиме настройки порта:

mac-notification — настраиваем на порту какую информацию отправлять
added Added MAC address information
all Added and Removed MAC address information
moved Flapping MAC address information
removed Removed MAC address information
mac-notification all ? – выбираем тип оповещения о событии в таблице мак адресов

log print to log and terminal

trap trap message

Значение value которое содержится в snmp трапе имеет кодировку ASCII. Значение value имеет вид :

Added mac:276+Ethernet1/2+90-2b-34-12-ce-b9 разделителем является плюс

* Настройка mac-notification на коммутаторе 2850.

В режиме глобальной конфигурации:

mac-address-table notification

snmp-server enable

snmp-server trap-source {IP}

snmp-server securityip disable

snmp-server host {IP} v2c TRAP

snmp-server enable traps

snmp-server enable traps mac-notification

mac-address-table notification

В режиме конфигурации порта

mac-notification all

Элтекс MES2324

Коммутатор L2+
Поддержка стекирования
Поддержка Multicast (IGMP snooping, MVR)
Расширенные функции безопасности (L2-L4 ACL, IP Source Guard, Dynamic ARP Inspection и др.)
Новое поколение коммутаторов доступа MES осуществляют подключение конечных пользователей к сети крупных предприятий, предприятий малого и среднего бизнеса и к сетям операторов связи с помощью интерфейсов 1G/10G.

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

Интерфейсы

Пакетный процессор: Marvel 98DX3236
24х10/100/1000BASE-T (RJ-45)
4х10GBASE-R (SFP+)/1000BASE-X (SFP)
Консольный порт: RS-232/RJ-45

Функции интерфейсов

Защита от блокировки очереди (HOL)
Поддержка обратного давления (Back pressure)
Поддержка Auto MDI/MDIX
Поддержка сверхдлинных кадров (Jumbo frames)
Управление потоком (IEEE 802.3X)
Зеркалирование портов (Port mirroring)
Стекирование

Функции при работе с МAC-адресами

Независимый режим обучения в каждой VLAN
Поддержка многоадресной рассылки (MAC Multicast Support)
Регулируемое время хранения MAC-адресов
Статические записи MAC (Static MAC Entries)
Логирование событий MAC Flapping

Поддержка VLAN

Поддержка Voice VLAN
Поддержка 802.1Q
Поддержка Q-in-Q
Поддержка Selective Q-in-Q
Поддержка GVRP

Функции L2 Multicast

Поддержка профилей Multicast
Поддержка статических Mullticast-групп
Поддержка IGMP Snooping v1,2,3
Поддержка IGMP snooping Fast Leave на основе порта/хоста
Поддержка авторизации IGMP через RADIUS
Поддержка MLD Snooping v1,2
Поддержка IGMP Querier
Поддержка MVR

Функции L2

Поддержка протокола STP (Spanning Tree Protocol, IEEE 802.1d)
Поддержка RSTP (Rapid Spaning Tree protocol, IEEE 802.1w)
Поддержка MSTP (Multiple Spanning Tree, IEEE802.1s)
Поддержка STP Multiprocess
Поддержка Spanning Tree Fast Link option
Поддержка EAPS^¹
Поддержка STP Root Guard
Поддержка STP Loop Guard
Поддержка BPDU Filtering
Поддержка STP BPDU Guard
Поддержка Loopback Detection (LBD) на основе VLAN
Поддержка ERPS (G.8032v2)
Поддержка Private VLAN
Поддержка Layer 2 Protocol Tunneling

Функции L3

Статические IP-маршруты
Протоколы динамической маршрутизации RIPv2, OSPFv2, OSPFv3
Address Resolution Protocol (ARP)
Поддержка протокола VRRP
Протоколы динамической маршрутизации мультикаста PIM SM, IGMP Proxy

Функции Link Aggregation

Создание групп LAG
Объединение каналов с использованием LACP
Поддержка LAG Balancing Algorithm

Поддержка IPv6

Функциональность IPv6 Host
Совместное использование IPv4, IPv6

Сервисные функции

Виртуальное тестирование кабеля (VCT)
Диагностика оптического трансивера
Green Ethernet

Функции обеспечения безопасности

DHCP snooping
Опция 82 протокола DHCP
IP Source Guard
Dynamic ARP Inspection
Поддержка sFlow
Проверка подлинности на основе MAC-адреса, ограничение количества MAC-адресов, статические MAC-адреса
Проверка подлинности по портам на основе 802.1x
Guest VLAN¹
Система предотвращения DoS-атак
Сегментация трафика
Защита от несанкционированных DHCP-серверов
Фильтрация DHCP-клиентов
Предотвращение атак BPDU
Фильтрация NetBIOS/NetBEUI
PPPoE Intermidiate agent

ACL (Списки управления доступом)

L2-L3-L4 ACL (Access Control List)
Поддержка Time-Based ACL
IPv6 ACL
ACL на основе:
— Порта коммутатора
— Приоритета 802.1p
— VLAN ID
— Ether type
— DSCP
— Типа протокола
— Номера порта TCP/UDP
— Содержимого пакета, определяемого пользователем (User Defined Bytes)

Основные функции качества обслуживания (QoS) и ограничения скорости

Статистика QoS
Ограничение скорости на портах (shaping, policing)
Поддержка класса обслуживания 802.1p
Защита от широковещательного «шторма»
Управление полосой пропускания
Обработка очередей по алгоритмам Strict Priority/Weighted Round Robin (WRR)
Три цвета маркировки
Назначение меток CoS/DSCP на основании ACL
Настройка приоритета 802.1p для VLAN управления
Перемаркировка DSCP to COS, COS to DSCP
Назначение VLAN на основании ACL

ОАМ/CFM

802.3ah Ethernet Link OAM
Dying Gasp
802.1ag Connectivity Fault Management (CFM)¹
802.3ah Unidirectional Link Detection (протокол обнаружения однонаправленных линков)

Основные функции управления

Загрузка и выгрузка конфигурационного файла по TFTP
Протокол SNMP
Интерфейс командной строки(CLI)
Web-интерфейс
Syslog
SNTP (Simple Network Time Protocol)
Traceroute
LLDP (802.1ab) + LLDP MED
Управление доступом к коммутатору – уровни привилегий для пользователей
Блокировка интерфейса управления
Локальная аутентификация
Фильтрация IP-адресов для SNMP
Клиент RADIUS, TACACS+ (Terminal Access Controller Access Control System)
Сервер SSH
Поддержка SSL
Поддержка макрокоманд
Журналирование вводимых команд
Системный журнал
Автоматическая настройка DHCP
DHCP Relay (Поддержка IPv4)
DHCP Option 12
DHCP Relay Option 82
Добавление тега PPPoE Circuit-ID
Flash File System
Команды отладки
Механизм ограничения трафика в сторону CPU
Шифрование пароля
Восстановление пароля
Ping (поддержка IPv4/IPv6)
Сервер FTP^¹

Функции мониторинга

Статистика интерфейсов
Удаленный мониторинг RMON/SMON
Поддержка мониторинга загрузки CPU по задачам и по типу трафика
Мониторинг загрузки оперативной памяти (RAM)
Мониторинг температуры
Мониторинг TCAM

MIB

RFC 1065, 1066, 1155, 1156, 2578 MIB Structure
RFC 1212 Concise MIB Definitions
RFC 1213 MIB II
RFC 1215 MIB Traps Convention
RFC 1493, 4188 Bridge MIB
RFC 1157, 2571-2576 SNMP MIB
RFC 1901-1908, 3418, 3636, 1442, 2578 SNMPv2 MIB
RFC 271,1757, 2819 RMON MIB
RFC 2465 IPv6 MIB
RFC 2466 ICMPv6 MIB
RFC 2737 Entity MIB
RFC 4293 IPv6 SNMP Mgmt Interface MIB
Private MIB
RFC 3289 DIFFSERV MIB
RFC 2021 RMONv2 MIB
RFC 1398, 1643, 1650, 2358, 2665, 3635 Ether-like MIB
RFC 2668 802.3 MAU MIB
RFC 2674, 4363 802.1p MIB
RFC 2233, 2863 IF MIB
RFC 2618 RADIUS Authentication Client MIB
RFC 4022 MIB для TCP
RFC 4113 MIB для UDP
RFC 3298 MIB для Diffserv
RFC 2620 RADIUS Accounting Client MIB
RFC 2925 Ping & Traceroute MIB
RFC 768 UDP
RFC 791 IP
RFC 792 ICMPv4
RFC 2463, 4443 ICMPv6
RFC 4884 Extended ICMP для поддержки сообщений Multi-Part
RFC 793 TCP
RFC 2474, 3260 Определение поля DS в заголовке IPv4 и IPv6
RFC 1321, 2284, 2865, 3580, 3748 Extensible Authentication Protocol (EAP)
RFC 2571, RFC2572, RFC2573, RFC2574 SNMP
RFC 826 ARP

¹ Не поддерживается в текущей версии ПО 4.0.7

linux — Является ли режим связывания = 5 решением проблемы смещения MAC-адресов?

В режиме 5 или режиме balance-tlb исходящий трафик использует MAC-адрес подчиненного интерфейса, который он оставляет, вместо использования адреса связанного интерфейса.

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

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

Интерфейс связи примет MAC-адрес одного из своих подчиненных интерфейсов:

  корень @ test1: ~ # ifconfig
bond1 Link encap: Ethernet HWaddr 00: 0c: 29: 3d: f7: 35
          inet адрес: 192.168.100.25 Bcast: 192.168.100.255 Маска: 255.255.255.0
          inet6 адрес: fe80 :: 20c: 29ff: fe3d: f735 / 64 Объем: Ссылка
          UP BROADCAST RUNNING MASTER MULTICAST MTU: 1500 Метрическая система: 1

eth2 Link encap: Ethernet HWaddr 00: 0c: 29: 3d: f7: 35
          UP BROADCAST RUNNING SLAVE MULTICAST MTU: 1500 Метрическая система: 1

eth3 Link encap: Ethernet HWaddr 00: 0c: 29: 3d: f7: 3f
          UP BROADCAST RUNNING SLAVE MULTICAST MTU: 1500 Метрическая система: 1

MAC-адрес

eth2 соответствует интерфейсу связи, он «первичный», поэтому он получает входящий трафик.

И, для подтверждения:

  корень @ test1: ~ # cat / sys / class / net / bond1 / bonding / mode
баланс-tlb 5

корень @ test1: ~ # cat / sys / class / net / bond1 / bonding / active_slave
eth2

Хорошо, так .. это балансировка нагрузки? Вот как это выглядит с другого узла, отправляющего постоянные пинги:

  корень @ test2: ~ # tcpdump -e -n -i eth0 proto 1
20: 33: 08.094078 00: 0c: 29: 46: 4f: c6> 00: 0c: 29: 3d: f7: 35, ethertype IPv4 (0x0800), длина 98: 192.168.100.40> 192.168.100.25: эхо-запрос ICMP, идентификатор 5810, последовательность 38, длина 64
20: 33: 08.094549 00: 0c: 29: 3d: f7: 35> 00: 0c: 29: 46: 4f: c6, ethertype IPv4 (0x0800), длина 98: 192.168.100.25> 192.168.100.40: эхо-ответ ICMP, id 5810, seq 38, длина 64
20: 33: 09.094052 00: 0c: 29: 46: 4f: c6> 00: 0c: 29: 3d: f7: 35, ethertype IPv4 (0x0800), длина 98: 192.168.100.40> 192.168.100.25: запрос эха ICMP, id 5810, seq 39, длина 64
20: 33: 09.094520 00: 0c: 29: 3d: f7: 35> 00: 0c: 29: 46: 4f: c6, ethertype IPv4 (0x0800), длина 98: 192.168.100.25> 192.168.100.40: эхо-ответ ICMP, id 5810, seq 39, длина 64
20: 33: 10.094078 00: 0c: 29: 46: 4f: c6> 00: 0c: 29: 3d: f7: 35, ethertype IPv4 (0x0800), длина 98: 192.168.100.40> 192.168.100.25: запрос эха ICMP, id 5810, seq 40, длина 64
20: 33: 10.094540 00: 0c: 29: 3d: f7: 35> 00: 0c: 29: 46: 4f: c6, ethertype IPv4 (0x0800), длина 98: 192.168.100.25> 192.168.100.40: эхо-ответ ICMP, id 5810, seq 40, длина 64

Все выглядит нормально — eth2 отвечает. Затем без подсказки появляется переключатель — обратите внимание, что MAC-адрес назначения запроса и MAC-адрес источника ответа больше не совпадают.

  20: 33: 11.094084 00: 0c: 29: 46: 4f: c6> 00: 0c: 29: 3d: f7: 35, ethertype IPv4 (0x0800), длина 98: 192.168.100.40> 192.168.100.25: эхо ICMP запрос, id 5810, seq 41, длина 64
20: 33: 11.094614 00: 0c: 29: 3d: f7: 3f> 00: 0c: 29: 46: 4f: c6, ethertype IPv4 (0x0800), длина 98: 192.168.100.25> 192.168.100.40: эхо-ответ ICMP, id 5810, seq 41, длина 64
20: 33: 12.094059 00: 0c: 29: 46: 4f: c6> 00: 0c: 29: 3d: f7: 35, ethertype IPv4 (0x0800), длина 98: 192.168.100.40> 192.168.100.25: запрос эха ICMP, id 5810, seq 42, длина 64
20:33:12.094531 00: 0c: 29: 3d: f7: 3f> 00: 0c: 29: 46: 4f: c6, ethertype IPv4 (0x0800), длина 98: 192.168.100.25> 192.168.100.40: эхо-ответ ICMP, id 5810, seq 42, длина 64
20: 33: 13.094086 00: 0c: 29: 46: 4f: c6> 00: 0c: 29: 3d: f7: 35, ethertype IPv4 (0x0800), длина 98: 192.168.100.40> 192.168.100.25: запрос эха ICMP, id 5810, seq 43, длина 64
20: 33: 13.094581 00: 0c: 29: 3d: f7: 3f> 00: 0c: 29: 46: 4f: c6, ethertype IPv4 (0x0800), длина 98: 192.168.100.25> 192.168.100.40: эхо-ответ ICMP, id 5810, seq 43, длина 64

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

Аварийное переключение для входящего трафика в режиме 5 намного проще; когда интерфейс обнаруживается как неработающий, MAC-адрес связанного интерфейса просто перемещается в активный интерфейс. Это часто вызывает предупреждение о смене MAC-адреса в журналах коммутатора, но этого следовало ожидать; не о чем беспокоиться.

MAC-адреса интерфейса изменяются с этого:

  eth2 Link encap: Ethernet HWaddr 00: 0c: 29: 3d: f7: 35
eth3 Link encap: Ethernet HWaddr 00: 0c: 29: 3d: f7: 3f

..to, после отключения eth2, это:

  eth2 Link encap: Ethernet HWaddr 00: 0c: 29: 3d: f7: 3f
eth3 Link encap: Ethernet HWaddr 00: 0c: 29: 3d: f7: 35

И все источники трафика от eth3 с MAC : 35 .

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

Если ваш маршрутизатор не заботится о нескольких исходных MAC-адресах, отправляющих трафик для одного IP-адреса, и не обижается на беспричинные отработки отказа ARP, тогда все готово!

Обнаружение петель и MAC-адресов на MS

Примечание: Обнаружение петель и обнаружение MAC-адресов доступно на MS12.8 и выше для поддерживаемых моделей.

Поддерживаемые модели: MS210 / 225/250/350/355/410/420/425/450

Обзор

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

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

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

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

Для обнаружения этих проблем на коммутаторах Meraki доступно обнаружение петель и MAC-адресов.

Обнаружение петли

Функция обнаружения петель по умолчанию включена в коммутаторах Meraki. Он отправляет пакет управления обнаружением петли и отслеживает их, чтобы обнаружить петлю и создать журнал событий / ловушку SNMP на приборной панели Meraki.

Все коммутаторы в топологии будут периодически генерировать широковещательные пробные пакеты, которые отправляются на каждый активный логический порт.По умолчанию этот период составляет 10 секунд. Эти пробные пакеты однозначно идентифицируются широковещательным адресом (ff: ff: ff: ff: ff: ff), кодом организации Cisco SNAP (00: 00: 0c) и PID SNAP 0x013c, как показано в 60-секундном захвате пакета. ниже

Если коммутатор получил этот пакет и видит свой собственный MAC-адрес, он сообщит о петле на приборной панели и сгенерирует журнал событий, показанный ниже

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

MAC Обнаружение откидной створки

Функция обнаружения заслонки MAC включена по умолчанию в коммутаторах Meraki. Эта функция будет отслеживать таблицу переадресации MAC-адресов, и если MAC-адрес будет изучен 3 или более раз на разных портах в течение 10 секунд, функция обнаружения MAC-переадресации сообщит об этом на приборной панели, как показано на изображении ниже

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

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

Лоскут

MAC отключил всю сеть: сеть

Привет, ребята, это один из тех постов, которые волнуют людей … lol jk.

Сегодня у нас кто-то включил порт коммутатора, который закрыл доступ почти для всех в сети ко всему в течение примерно 10 минут, пока мы не разрешили это

https: // imgur.com / a / wtJLyIA

На рисунке ниже поясняется топология. У нас есть 2 ядра нексуса, которые являются одноранговыми ссылками, которые подключаются ко многим коммутаторам через VPC, в этом примере это наш распределительный коммутатор здания. Наш выключатель дистанционного управления подключается к выключателю доступа в здание. VLAN 5 похожа на vlan из черной дыры, он по умолчанию установлен на всех наших sw-портах и не дает доступа ни к чему, пока мы не добавим туда настоящий vlan. Итак, у нас есть этот новый ciena, который должен подключить наш основной сайт здесь к удаленному сайту аварийного восстановления.пока он подключен только здесь, но еще не на сайте DR. У ciena есть 2 соединения, идущие к каждому ядру нексуса, настроенному как vlan 5 доступа к порту коммутатора на наших ядрах; они не настроены как VPC. Ciena тоже включается. Итак, когда мой коллега пошел активировать случайный sw-порт на случайном переключателе доступа для одного из зданий, он просто включил его … следующее, что вы знаете, начинают сыпаться билеты о потере связи, и мы получаем 1 войдите в коммутатор распределения, указав:

коммутатор распределения здания #

% SW_MATM-4-MACFLAP_NOTIF: Host 085f.51y6.5626 в vlan 5 колеблется между портом Po1 и портом Po2

% SW_MATM-4-MACFLAP_NOTIF: Хост 085f.51y6.5626 в vlan 5 колеблется между портом Po1 и портом Po2

Так что, черт побери, пока отключаем порт. у меня вопрос, как этого можно было избежать? Нужно ли мне настраивать пороги широковещательного шторма? Я бы подумал, что связующее дерево что-то с этим сделает, но, видимо, нет … Я также ожидал бы увидеть этот журнал более одного раза, как я вывел выше, верно? Я видел подобные петли раньше много раз с откидными крышками MAC, но чтобы отключить сеть для всех ??? Я никогда не видел, чтобы было так плохо !!

Cisco MAC Address Flapping, вызывающий высокую загрузку ЦП — блог tkrn

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

Ниже приведены команды, необходимые для определения перебоев MAC-адресов и высокой загрузки ЦП на коммутаторах серии Cisco Catalyst.Это было выполнено для устранения проблем с загрузкой ЦП на коммутаторе Cisco Catalyst серии 4500, но те же команды должны быть доступны для других коммутаторов Cisco, на которых работает микропрограммное обеспечение IOS.

cisco4500 # показать процессы cpu Загрузка процессора за пять секунд: 38% / 1%; одна минута: 32%; пять минут: 32% Время выполнения PID (мс) Вызвано uSec 5Sec 1Min 5Min Процесс TTY 27 524 250268 2 0,00% 0,00% 0,00% 0 Фон TTY 28 816 254843 3 0,00% 0.00% 0.00% 0 заданий в секунду 29 101100 5053 20007 0,00% 0,01% 0,00% 0 Поминутных заданий 30 26057260 26720

5 12,07% 11,41% 11,36% 0 Cat4k Mgmt HiPri 31 19482908 29413060 662 24,07% 19,32% 19,20% 0 Cat4k Mgmt LoPri 32 4468 162748 27 0,00% 0,00% 0,00% 0 Галиос Решедул

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

 cisco4500 # показать работоспособность платформы
% CPU% CPU RunTimeMax Priority Average% CPU Total
Целевое значение Фактическое целевое значение Фактическое значение Fg Bg 5 секунд Мин. Час ЦП
Протокол-старение-реви 0.20 0.00 2 0100500 0 0 0 0:01
Acl-Flattener 1,00 0,00 10 5 100 500 0 0 0 0:04
KxAclPathMan create / 1.00 0.00 10 5 100 500 0 0 0 0:21
Обновление KxAclPathMan 2.00 0,00 10 6 100 500 0 0 0 0:05
KxAclPathMan reprogr 1.00 0.00 2 1100500 0 0 0 0:00
ТагМан-ИнформМтегРев 1.00 0.00 5 0100500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 14 100 500 0 0 0 0:18
K2CpuMan Обзор 30.00 91.31 30 92100500128119 84 13039: 02
K2AccelPacketMan: Tx 10.00 2.30 20 0100500 2 2 2 1345: 30
K2AccelPacketMan: Au 0,10 0,00 0 0100500 0 0 0 0:00

Сначала войдите в разрешенный режим, затем настройте режим терминала.Выполните следующую команду, чтобы убедиться, что для mac-move ведется журнал, который идентифицирует изменение MAC-адреса.

 cisco4500 (config) #mac уведомление о таблице адресов mac-move

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

 cisco4500 (config) # do show log
Ведение журнала системного журнала: включено (0 сообщений отброшено, 1 сообщение ограничено по скорости, 0 сбросов, 0 переполнений, xml отключен, фильтрация отключена)
...
* 3 октября 08:51: 28.149:% SYS-5-CONFIG_I: Настроено с консоли администратором на vty0 (10.10.10.236)
* 3 октября 09: 43: 46.437:% C4K_EBM-4-HOSTFLAPPING: Хост 00: 60: 48: 1B: 01: 15 в vlan 400 перемещается с порта Gi2 / 40 на порт Gi2 / 30
* 3 октября 09: 43: 48.629:% C4K_EBM-4-HOSTFLAPPING: Хост 00: 60: 48: 1B: 01: 15 в vlan 400 перемещается с порта Gi2 / 30 на порт Gi2 / 40
* 3 октября 09: 43: 48.717:% C4K_EBM-4-HOSTFLAPPING: Хост 00: 60: 48: 1B: 01: 15 в vlan 400 перемещается с порта Gi2 / 40 на порт Gi2 / 30
* 3 октября 09: 43: 49.581:% C4K_EBM-4-HOSTFLAPPING: Хост 00: 60: 48: 1B: 01: 15 в vlan 400 перемещается с порта Gi2 / 30 на порт Gi2 / 40

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

 cisco4500 # sh адрес таблицы MAC-адресов 00: 60: 48: 1B: 01: 15

Одноадресные записи
vlan тип MAC-адреса протоколы порт
------- + --------------- + -------- + ----------------- ---- + --------------------
400 0060.481b.0115 динамический IP-адрес GigabitEthernet2 / 30

cisco4500 # sh адрес таблицы MAC-адресов 00: 60: 48: 1B: 01: 15
Одноадресные записи
vlan тип MAC-адреса протоколы порт
------- + --------------- + -------- + ----------------- ---- + --------------------
400 0060.481b.0115 динамический IP-адрес GigabitEthernet2 / 40

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

Для получения дополнительной информации и официальной документации Cisco, http://www.cisco.com/c/en/us/support/docs/switches/catalyst-4000-series-switches/65591-cat4500-high-cpu.html

Связанные

8 извлеченных уроков — Arista Datacenter Interconnect (DCI) с VXLAN и vARP

Хотя наше название означает, что мы работаем только с глобальными сетями, WAN Dynamics также работает над некоторыми очень интересными (и забавными!) Развертываниями центров обработки данных. используя в основном оборудование Arista Networks.Первое, что нужно отметить: этот комплект и компания просто фантастические. Нам искренне нравится работать с аппаратным и программным обеспечением Arista и, прежде всего, с их людьми.

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

Во время развертывания центров обработки данных мы узнали несколько вещей и, как нам кажется, являются истинным духом Arista, и почувствовали, что должны поделиться ими с сообществом.Мы хотели бы подробно рассказать здесь о 8 вещах, которые нам показались интересными и которые, по нашему мнению, следует учитывать при развертывании решений на основе Arista с VXLAN и vARP. Наслаждаться!

Урок 1. Скорее всего, вам понадобится один и тот же MAC-адрес Virtual ARP (vARP) в нескольких центрах обработки данных.

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

Урок 2: Если у вас один и тот же MAC-адрес в нескольких центрах обработки данных, вы получите сообщения журнала «MAC Flap» на своих коммутаторах.

Поскольку мы использовали один и тот же MAC-адрес для vARP на четырех коммутаторах ядра центра обработки данных, мы получили бы ошибки «MAC Flap» на коммутаторах VXLAN DCI, используемых для моста VXLAN. Поскольку коммутаторы не используют этот MAC-адрес для принятия решения о маршрутизации, мы создали записи статического MAC-адреса, чтобы подавить сообщение журнала для каждой из сетей VLAN, которые имели SVI в обоих центрах обработки данных.

Ошибка: 20 октября 15:19:45 7280-dci1 PortSec:% ETH-4-HOST_FLAPPING: Хост 00: 1c: 73: 00: 00: 99 в VLAN 1 переключается между интерфейсом Port-Channel30 и интерфейсом

Vxlan1 20 октября 15:30:12 7280-dci1 PortSec:% ETH-4-HOST_FLAPPING: Host

00: 1c: 73: 00: 00: 99 в VLAN 1 переключается между интерфейсом Vxlan1 и интерфейсом Port- Channel30

конфигурация, которая остановила ошибку:

таблица MAC-адресов статическая 001c.7300.0099 Интерфейс vlan 1 Port-Channel30

Урок 3: пиринг OSPF точка-точка с MTU 9100

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

Урок 4: Проблема с тайм-аутом MAC-адреса

Мы столкнулись с проблемой, которую было довольно трудно устранить, когда трафик периодически сбрасывался между центрами обработки данных, который проходил из одной VLAN в другую и проходил через VXLAN. Это заставляло коммутаторы Arista постоянно переучивать MAC-адреса, и это приводило к нарушению политики Control Plane Policing (CoPP) на коммутаторах и обрыву трафика.После работы с поддержкой Arista мы решили увеличить время выдержки MAC во всем мире до чуть более 4 часов. Это помогло решить нашу проблему.

Наша конфигурация:

Время устаревания таблицы MAC-адресов 14400

Урок 5: Обнаружение двунаправленной переадресации (BFD) между DCI и основными коммутаторами центра обработки данных

BFD — отличный протокол для быстрого переключения сеансов динамической маршрутизации. Это дало нам чрезвычайно быстрое изменение направления между нашими коммутаторами и быстрое время восстановления VXLAN по цепям DCI.

Урок 6: Приоритет связующего дерева на коммутаторах с агрегацией каналов с несколькими шасси (MLAG’d)

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

Урок 7. Особенности интернет-трафика

В каждом центре обработки данных в развертывании было две пары брандмауэров высокой доступности «Активный / Резервный».Обе пары брандмауэров HA объявляли маршрут по умолчанию в коммутаторы ядра центра обработки данных Arista. Чтобы сохранить детерминированный поток трафика, мы дали основному центру обработки данных лучшую метрику, чем вторичный центр обработки данных. Таким образом, в обычный рабочий день Интернет-трафик будет проходить только через пару HA межсетевого экрана в основном центре обработки данных. Этот метод избавил нас от необходимости беспокоиться о проблемах трансляции NAT на брандмауэре, таких как пакет, поступающий в брандмауэр в основном центре обработки данных, отправляющийся на сервер во вторичном центре обработки данных и затем уходящий через пару HA брандмауэра вторичного центра обработки данных.

Урок 8: Буферы имеют значение

Мы снова и снова наблюдаем, как клиенты недооценивают необходимость покупки коммутатора с большими буферами для хранения и других сетей большого объема. Это нельзя недооценивать, обратите внимание на предупреждение вашего инженера по продажам (SE), если он скажет вам, что вам нужен более глубокий переключатель буфера. Да, это будет дороже, но если вам нужны большие буферы, а у вас их нет, гораздо дороже будет развернуть сеть, которая не выдержит ее нагрузки. Возвращение к колодцу, чтобы попросить больше денег на покупку коммутаторов, которые вы должны были купить в первую очередь, очень плохо отражается на инженерах для ИТ-руководителей, которые могут не понимать вещи вплоть до уровня буферов.Они полагаются на своих надежных инженеров как на советников, которые сделают правильный выбор с первого раза.

В завершение…
Команда WAN Dynamics не может более высоко оценивать решения на базе Arista. Если вы хотите узнать больше и обсудить кое-что из того, что мы узнали, свяжитесь с нами. Мы будем счастливы договориться о взаимодействии, проконсультироваться отдельно или просто поторопиться. Мы любим эти вещи и хотим, чтобы вы тоже любили их, поэтому рады поделиться своими знаниями!

Flapping — Сетевая энциклопедия

Перебои в компьютерных сетях — это проблемное состояние, которое может возникнуть с динамическими маршрутизаторами в больших объединенных сетях.Узнайте все о flapping-роутерах, прочитав эту статью.

Что такое хлопанье?

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

Например, изменяющийся маршрутизатор может указать во время первой широковещательной передачи, что маршрут A является лучшим маршрутом к данному хосту, указать во время второй широковещательной передачи, что маршрут B является лучшим маршрутом, указать во время следующей широковещательной передачи, что маршрут A является наилучшим, и скоро.

Таким образом, маршрутизаторы

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

Чтобы проверить маршрутизаторы-бестселлеры на Amazon, нажмите здесь.

Маршрут колеблется

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

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

Суммирование эффективно изолирует другие маршрутизаторы от проблемы смены маршрутов.

Проблемы, которые могут возникнуть с маршрутизаторами: переключение и зацикливание

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

Переменный маршрутизатор и обобщение маршрута

Робот с мягким корпусом использует функции улитки для плавания через стресс-тест Марианской впадины

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

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

Исследование, опубликованное в журнале Nature на этой неделе, показывает, что мягкие машины могли работать в знаменитой Марианской впадине на глубине 10900 м, что ниже уровня океана, чем пик Эвереста над ним.

YouTube видео

Под давлением

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

«Для исследования глубин от 3 000 м до 11 000 м жестким роботам и машинам требуются сосуды высокого давления или системы с компенсацией давления. Однако глубоководная разведка остается сложной задачей, учитывая риск разрушения конструкции в экстремальных условиях », — заявили исследователи.

YouTube видео

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

«Мягкие организмы, обитающие на средних глубинах океана [более 1000 м], такие как осьминоги и медузы, широко изучаются; их приспособляемость вдохновила на создание подводных мягких роботов.Элегантные конструкции мягких роботов представляют многообещающие подходы к исследованию глубоководных районов », — говорится в документе« Мягкий робот с автономным питанием в Марианской впадине ».

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

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

Мягкий робот рядом с рыбой-улиткой, которая вдохновила его на создание. Рис: Природа

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

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

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

Робот успешно прошел испытания в Южно-Китайском море, где он свободно плавал, махая крыльями. Он также прошел испытания в Марианской впадине, где был привязан к обычному подводному роботу, который также сделал снимки миссии.

Но это не совсем быстро, плывет примерно со скоростью 5 см в секунду.

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

В сопроводительной статье профессор Сесилия Лаши с факультета машиностроения Национального университета Сингапура и Марчелло Калисти, старший преподаватель Университета Линкольна в Великобритании, сказали: «Исследования Ли и его сотрудников теперь подталкивают границы того, что может быть достигнуто: замена жестких защитных кожухов для электронных компонентов распределенной электроникой, встроенной в мягкий материал, открывает путь новому поколению исследователей морских глубин.”

Такие роботы могут «помочь исследователям исследовать огромные неизведанные глубины океанов», — заявили комментаторы.