В данной статье производится описание порядка диагностики и поиска ошибок на портах коммутатора.
В примере используется коммутатор Cisco Catalyst C4948
Для диагностики ошибок на портах коммутатора Cisco необходимо подключиться к консоли
коммутатора через утилиту telnet, используя консольный порт (прямое подключение)
или по IP-адресу.
Следующим шагом мы переходим в привилегированный режим редактирования конфигурации Enable (en).
C4948> enable
или
C4948> en
Следующей командой мы можем посмотреть счетчики ошибок по всем портам коммутатора:
C4948# sh interfaces counters errors
или по одному порту gi1/33
C4948# sh interfaces gi1/33 counters errors
Вывод команды
Port CrcAlign-Err Dropped-Bad-Pkts Collisions Symbol-Err
Gi1/33 0 0 0 0
Port Undersize Oversize Fragments Jabbers
Gi1/33 0 0 0 0
Port Single-Col Multi-Col Late-Col Excess-Col
Gi1/33 0 0 0 0
Port Deferred-Col False-Car Carri-Sen Sequence-Err
Gi1/33 0 0 0 0
Приведем описание наиболее важных счетчиков
| Счетчик | Описание | Возможная причина |
|---|---|---|
| CrcAlign-Err | Количество ошибок выравнивания определяется числом полученных кадров, которые не заканчиваются четным числом октетов и имеют неверную контрольную сумму CRC | Данные ошибки обычно являются результатом несоответствия дуплексных режимов или физической проблемы (такой как прокладка кабелей, неисправный порт или сетевая плата). При первом подключении кабеля к порту могут возникнуть некоторые из этих ошибок. Кроме того, если к порту подключен концентратор, ошибки могут вызвать конфликты между другими устройствами концентратора |
| Collisions | В счетчиках кадров с конфликтами содержится число пакетов, одна попытка передачи которых была неудачной, а следующая — успешной. Это означает, что в случае увеличения значения счетчика кадров с конфликтами на 2, коммутатор дважды неудачно пытался передать пакет, но третья попытка была успешной | Отбрасывание кадров вызвано чрезмерной нагрузкой трафиком данного интерфейса. Если в этих полях наблюдается рост числа пакетов, уменьшите нагрузку на данный интерфейс |
| Undersize | Это общее число принятых пакетов с длиной менее 64 октетов (без битов кадрирования, но с октетами FCS) и допустимым значением FCS | Указывает на поврежденный кадр, сформированный подключенным устройством. Убедитесь, что подключенное устройство функционирует правильно |
| Oversize | Число принятых портом из сети пакетов с длиной более 1514 байтов2 | Это может указывать на сбой оборудования либо проблемы конфигурации режима магистрального соединения для dot1q или ISL |
| Fragment | Общее число кадров с длиной менее 64 октетов (без битов кадрирования, но с октетами FCS) и неверным значением FCS | Увеличение значения этого счетчика указывает на то, что порты настроены на полудуплексный режим. Установите в настройках дуплексный режим |
| Single-Col | Число конфликтов, произошедших до того, как интерфейс успешно передал кадр носителю | Нормальное явление для полудуплексных интерфейсов, но не для полнодуплексных интерфейсов. Быстрый рост числа конфликтов указывает на высокую загрузку соединения или возможное несоответствие дуплексных режимов с присоединенным устройством |
| Multi-Col | Число множественных конфликтов произошедших до того, как порт успешно передал кадр носителю | Нормальное явление для полудуплексных интерфейсов, но не для полнодуплексных интерфейсов. Быстрый рост числа конфликтов указывает на высокую загрузку соединения или возможное несоответствие дуплексных режимов с присоединенным устройством |
| Late-Col | Количество обнаруженных конфликтов в определенном интерфейсе на последних этапах процесса передачи. Для порта со скоростью 10 Мбит/с это позднее, чем время передачи 512 битов для пакета. В системе со скоростью передачи данных 10 Мбит/с 512 битовых интервалов соответствуют 51,2 микросекунды | Ошибка, в частности, может указывать на несоответствие дуплексных режимов. В сценарии с несоответствием дуплексных режимов на стороне с полудуплексным режимом наблюдается поздний конфликт. Во время передачи со стороны с полудуплексным режимом на стороне с дуплексным режимом выполняется одновременная передача без ожидания своей очереди, что приводит к возникновению позднего конфликта. Поздние конфликты также могут указывать на слишком большую длину кабеля или сегмента Ethernet. На интерфейсах, сконфигурированных в качестве полнодуплексных, конфликты наблюдаться не должны |
| Excess-Col | Количество кадров, для которых передача через отдельный интерфейс завершилась с ошибкой из-за чрезмерного числа конфликтов. Избыточный конфликт возникает, когда для некоторого пакета конфликт регистрируется 16 раз подряд. Затем пакет отбрасывается | Чрезмерное количество конфликтов обычно обозначает, что нагрузку на данный сегмент необходимо разделить между несколькими сегментами, но может также указывать на несоответствие дуплексных режимов с присоединенным устройством. На интерфейсах, сконфигурированных в качестве полнодуплексных, конфликты наблюдаться не должны |
| Deferred-Col | Общее число кадров, первая попытка передачи которых была отложена из-за трафика в сетевом носителе | Отбрасывание кадров вызвано чрезмерной нагрузкой трафика, направленного к данному коммутатору. Если в этом поле наблюдается рост числа пакетов, уменьшите нагрузку на данный коммутатор. Может потребоваться изменение топологии сети, чтобы снизить нагрузку трафика на данный коммутатор |
| Carri-Sen | Счетчик увеличивается каждый раз, когда контроллер Ethernet собирается отослать данные по полудуплексному соединению. Контроллер обнаруживает провод и перед передачей проверяет, не занят ли он | Нормально для полудуплексного сегмента Ethernet |
Далее проверяем, включено ли обнаружение отключения из-за ошибки на порту коммутатора:
C4948# sh errdisable detect
Вывод команды
ErrDisable Reason Detection Mode
----------------- --------- ----
arp-inspection Enabled port
bpduguard Enabled port
channel-misconfig Enabled port
community-limit Enabled port
dhcp-rate-limit Enabled port
dtp-flap Enabled port
ekey Enabled port
gbic-invalid Enabled port
inline-power Enabled port
invalid-policy Enabled port
l2ptguard Enabled port
link-flap Enabled port
link-monitor-failure Enabled port
lsgroup Enabled port
oam-remote-failure Enabled port
mac-limit Enabled port
pagp-flap Enabled port
port-mode-failure Enabled port
pppoe-ia-rate-limit Enabled port
psecure-violation Enabled port/vlan
security-violation Enabled port
sfp-config-mismatch Enabled port
storm-control Enabled port
udld Enabled port
unicast-flood Enabled port
vmps Enabled port
где, по умолчанию, в колонке Detection все значения должны быть Enabled
Смотрим порты которые находятся в состоянии ошибки errdisable (порт
автоматически отключен операционной системой коммутатора, так как порт
обнаружен в состоянии ошибки):
C4948# sh errdisable recovery
Вывод команды:
ErrDisable Reason Timer Status
----------------- --------------
arp-inspection Disabled
bpduguard Disabled
channel-misconfig Disabled
dhcp-rate-limit Disabled
dtp-flap Disabled
gbic-invalid Disabled
inline-power Disabled
l2ptguard Disabled
link-flap Disabled
mac-limit Disabled
link-monitor-failure Disabled
oam-remote-failure Disabled
pagp-flap Disabled
port-mode-failure Disabled
pppoe-ia-rate-limit Disabled
psecure-violation Disabled
security-violation Disabled
sfp-config-mismatch Disabled
storm-control Disabled
udld Disabled
unicast-flood Disabled
vmps Disabled
Timer interval: 300 seconds
Interfaces that will be enabled at the next timeout:
где в колонке ErrDisable Reason отображается причина перехода порта в состояние errdisable.
В нашем случае портов в состоянии errdisable не обнаружено.
Просмотр подробной информации о настройках и состоянии порта коммутатора:
C4948# sh interfaces gigabitEthernet 1/33
Вывод команды
GigabitEthernet1/33 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet Port, address is 8843.e1a1.7f60 (bia 8843.e1a1.7f60)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, link type is auto, media type is 10/100/1000-TX
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 22000 bits/sec, 18 packets/sec
249311846 packets input, 197650705208 bytes, 0 no buffer
Received 146 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
413450928 packets output, 82056436068 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Как видно из вывода команды, ошибок на порте коммутатора не обнаружено.
Также, набрав следующую команду, можно посмотреть статус и используемые протоколы на портах коммутатора:
C4948# sh interfaces counters protocol status
или по определенному порту:
C4948# sh interfaces gi1/33 counters protocol status
Вывод команды:
Protocols allocated:
GigabitEthernet1/33: Other, IP, Spanning Tree, CDP
где
| Протокол | Описание |
|---|---|
IP |
Маршрутизируемый протокол сетевого уровня стека TCP/IP. |
Spanning Tree (STP) |
Канальный протокол связующего дерева. Основной задачей STP является устранение петель в топологии произвольной сети Ethernet, в которой есть один или более сетевых мостов, связанных избыточными соединениями. |
CDP |
Проприетарный протокол второго уровня, разработанный компанией Cisco Systems, позволяющий обнаруживать подключённое сетевое оборудование Cisco, его название, версию IOS и IP-адреса. |
Часть 1 Часть 2 Часть 3
Содержание
Распространенные проблемы портов и интерфейсов
Состояние порта или интерфейса – Disable или Shutdown
Порт или интерфейс в состоянии «errDisable»
Порт или интерфейс в неактивном состоянии
Увеличение значения счетчика отложенных кадров в интерфейсе коммутаторов Catalyst
Перемежающиеся сбои при выполнении функции set timer [значение] from vlan [№ vlan]
Несоответствие режима магистрального соединения
Кадры jumbo, giant и baby giant
Не удается проверить связь с конечным устройством
Использование команды Set Port Host или Switchport Host для устранения задержек во время запуска
Проблемы со скоростью/дуплексным режимом, автоматическим согласованием или сетевой платой
Петли в дереве STP
UDLD: одностороннее соединение
Отложенные кадры (Out-Lost или Out-Discard)
Неполадки программного обеспечения
Ошибки оборудования
Ошибки ввода в интерфейсе уровня 3, подключенном к коммутационному порту уровня 2.
Быстрое увеличение значения счетчика Rx-No-Pkt-Buff и ошибок ввода
Режим магистрального соединения между коммутатором и маршрутизатором
!—Дискуссионные форумы NetPro — избранные темы
—>Дополнительные сведения
Распространенные проблемы портов и интерфейсов
Состояние порта или интерфейса – Disable или Shutdown
Очевидная, но часто упускаемая из виду причина сбоя подключения к порту заключается в неправильной настройке коммутатора. Если индикатор порта горит постоянным оранжевым светом, это означает, что работа порта завершена программным обеспечением коммутатора, либо с помощью пользовательского интерфейса, либо внутренними процессами.
Примечание: Некоторые индикаторы портов данной платформы функционирует по отношению к протоколу STP отличным образом. Например, на коммутаторах серии Catalyst 1900/2820 индикаторы портов горят оранжевым светом, когда порты функционируют в режиме блокирования STP. В этом случае оранжевый свет может означать нормальную работу протокола STP. На коммутаторах серии Catalyst 6000/5000/4000 индикаторы портов не загораются оранжевым светом в случае блокирования портов протоколом STP.
Убедитесь, что порт или модуль не отключен или не выключен по каким-либо причинам. Если на одной стороне соединения работа порта или модуля завершена вручную, это соединение активируется только после повторного включения порта. Проверьте состояние порта на обеих сторонах.
В CatOS выполните команду show port и, если порт отключен, включите его.
Port Name Status Vlan Duplex Speed Type ----- -------------------- ---------- ---------- ------ ----- ------------ 3/1 disabled 1 auto auto 10/100BaseTX !--- Use the set port enable mod/port command to re-enable this port.
Используйте команду show module , чтобы определить, отключен ли данный модуль. Если модуль отключен, включите его.
Mod Slot Ports Module-Type Model Sub Status --- ---- ----- ------------------------- ------------------- --- -------- 2 2 2 1000BaseX Supervisor WS-X6K-SUP1A-2GE yes ok 16 2 1 Multilayer Switch Feature WS-F6K-MSFC no ok 3 3 48 10/100BaseTX Ethernet WS-X6348-RJ-45 no disable !--- Use the set module enable mod/port command to re-enable this port.
Для Cisco IOS используйте команду show run interface и проверьте, не находится ли данный интерфейс в состоянии завершения работы:
Switch#sh run interface fastEthernet 4/2 ! interface FastEthernet4/2 switchport trunk encapsulation dot1q switchport mode trunk shutdown duplex full speed 100 end !--- Use the no shut command in config-if mode to re-enable this interface.
Если порт переходит в режим завершения работы сразу после перезагрузки коммутатора, вероятная причина заключается в настройке безопасности порта. Если в данном порту включена односторонняя лавинная маршрутизация, это может вызывать завершение работы порта после перезагрузки. На практике компании осуществляющее абонетское техническое облуживание компьютеров и сетевого оборудования отключают одностороннюю лавинную маршрутизацию. Корпорация Cisco рекомендует отключать одностороннюю лавинную маршрутизацию, так как это также гарантирует, что в таком порте не возникнет лавинная маршрутизация после достижения ограничения MAC-адресов.
Порт или интерфейс в состоянии «errDisable»
По умолчанию программное обеспечение, установленное на коммутаторе, может завершить работу порта или интерфейса при обнаружении определенных ошибок.
В выходных данных команды show port для CatOS может указываться состояние errdisable:
switch>(enable) sh port 4/3
Port Name Status Vlan Duplex Speed Type
----- -------------------- ---------- ---------- ------ ----- ------------
4/3 errdisable 150 auto auto 10/100BaseTX
!--- The show port command displays a status of errdisable.
Можно также воспользоваться командой show interface card-type {slot/port} status для Cisco IOS:
Router#show int fasteth 2/4 status
Port Name Status Vlan Duplex Speed Type
Gi2/4 err-disabled 1 full 1000 1000BaseSX
!--- The show interfaces card-type {slot/port} status command for Cisco IOS
!--- displays a status of errdisabled.
!--- The show interfaces status errdisabled command shows all the interfaces
!--- in this status.
Команда show logging buffer для CatOS и команда show logging для Cisco IOS также отображают сообщения об ошибках (точный формат сообщений различен), связанные с состоянием «errdisable».
Порты или интерфейсы, работа которых завершается из-за состояния ошибки, в CatOS и в Cisco IOS считаются причинами. Причины этого различны: от неправильной настройки EtherChannel, которая вызывает PAgP-переброску, до несоответствия дуплексных режимов, одновременной настройки режима PortFast и защиты порта от блоков BPDU, функции обнаружения односторонной связи (UDLD) и т.д.
Необходимо вручную включить порт или интерфейс, чтобы вывести его из состояния «errdisable», если не настроено восстановление из состояния «errdisable». В программном обеспечении CatOS версии 5.4(1) и выше поддерживается автоматическое повторное включение порта после его пребывания в состоянии отключения после ошибки в истечение настраиваемого периода времени. Cisco IOS в большинстве коммутаторов также обладают этой функциональной возможностью. Нижняя строка имеет этот вид, даже если настроить интерфейс на восстановление из состояния. Данная проблема продолжает возникать, пока не будет устранена ее основная причина.
Дополнительные сведения о причинах состояния «errdisable» для коммутаторов и восстановлении из него см. в документе Восстановление при состоянии порта «errDisable» на платформах CatOS.
Примечание: Используйте эту ссылку в качестве справки по состоянию «errdisable» на коммутаторах с Cisco IOS, так как основные причины одинаковы, вне зависимости от используемой операционной системы.
В этой таблице сравниваются команды, используемые для настройки проверки и устранения состояния «errdisable» на коммутаторах с CatOS и Cisco IOS. Выберите команду для перехода к документации по командам.
|
Команды CatOS для работы с состоянием «errdisable» |
Действие |
Команды Cisco IOS для работы с состоянием «errdisable» |
|---|---|---|
|
set errdisable-timeout {enable | disable} {reason} |
установка или настройка |
errdisable detect cause errdisable recovery cause |
|
set errdisable-timeout interval {interval |
установка или настройка |
errdisable recovery {interval |
|
show errdisable-timeout |
проверка и устранение неполадок |
show errdisable detect show interfaces status err-disabled |
Порт или интерфейс в неактивном состоянии
Одна из распространенных причин отсутствия активности портов на коммутаторах с CatOS — исчезновение сети VLAN, которой они принадлежат. Такая же проблема может возникнуть на коммутаторах с Cisco IOS, когда интерфейсы настроены в качестве портов коммутатора уровня 2 с помощью команды switchport .
Каждый порт коммутатора уровня 2 принадлежит сети VLAN. Каждый порт коммутатора уровня 3, настроенный в качестве коммутационного порта L2, также должен принадлежать некоторой сети VLAN. При удалении такой сети VLAN соответствующий порт или интерфейс становятся неактивным.
Примечание: Когда это происходит, на некоторых коммутаторах индикатор горит постоянным оранжевым светом на каждом порте.
В CatOS используйте команду show port или show port status вместе с командой show vlan для проверки:
Switch> (enable) sh port status 2/2
Port Name Status Vlan Duplex Speed Type
----- -------------------- ---------- ---------- ------ ----- ------------
2/2 inactive 2 full 1000 1000BaseSX
!--- Port 2/2 is inactive for VLAN 2.
Switch> (enable) sh vlan
VLAN Name Status IfIndex Mod/Ports, Vlans
---- -------------------------------- --------- ------- ------------------------
1 default active 5 2/1
!--- VLANs are displayed in order and VLAN 2 is missing.
Для Cisco IOS используйте команду show interfaces card-type {slot/port} switchport вместе с командой show vlan , чтобы проверить.
Router#sh interfaces fastEthernet 4/47 switchport
Name: Fa4/47Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 11 ((Inactive))
!--- FastEth 4/47 is inactive.
Router#sh vlan VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi1/1, Gi2/1, Fa6/6
10 UplinkToGSR's active Gi1/2, Gi2/2
!--- VLANs are displayed in order and VLAN 11 is missing.
30 SDTsw-1ToSDTsw-2Link active Fa6/45
Если коммутатор, удаливший сеть VLAN, является VTP-сервером для VTP-домена, у всех коммутаторов серверов и клиентов этого домена данная сеть VLAN также удаляется из их таблицы сетей VLAN. Когда данная сеть VLAN снова добавляется в таблицу сетей VLAN коммутатора VTP-сервера, порты коммутаторов домена, принадлежащие восстановленной сети VLAN, снова становятся активными. Порт помнит, какой сети VLAN он назначен, даже если эта сеть VLAN удалена.
Увеличение значения счетчика отложенных кадров в интерфейсе коммутаторов Catalyst
Отбрасывание кадров вызвано чрезмерной нагрузкой трафиком данного коммутатора. Обычно отложенные кадры — это кадры, которые были переданы успешно после ожидания носителя, так как он был занят. Они обычно наблюдаются в полудуплексных средах, в которых несущая уже используется, при попытке передачи кадра. Однако в дуплексных средах эта проблема возникает, когда к коммутатору направляется чрезмерная нагрузка.
Ниже описывается обходное решение.
-
Чтобы избежать ошибок согласования, жестко задайте использование дуплексного режима на обеих сторонах соединения.
-
Замените кабель и шнур коммутационной панели, чтобы гарантировать исправность кабеля и соединительных шнуров.
Перемежающиеся сбои при выполнении функции set timer [значение] from vlan [№ vlan]
Данная проблема возникает, когда логической схеме распознавания закодированных адресов (Encoded Address Recognition Logic, EARL) не удается задать требуемое число секунд для времени устаревания CAM сети VLAN. В данном случае время устаревания сети VLAN уже настроено на быстрое устаревание.
Когда сеть VLAN уже находится в процессе быстрого устаревания, схема EARL не может ее настроить на быстрое устаревание, процесс настройки таймера устаревания блокирован. По умолчанию время устаревания CAM равно пяти минутам, т.е. каждые 5 минут коммутатор очищает таблицу полученных MAC-адресов. Это гарантирует, что в таблице MAC-адресов (таблица CAM) содержатся только самые последние записи.
При быстром устаревании время устаревания CAM временно становится равным числу секунд, заданному пользователем, и используется в процессе создания уведомлений об изменении топологии (TCN). Идея заключается в том, что при изменении топологии это значение необходимо для ускорения очистки таблицы CAM, чтобы компенсировать изменение топологии.
Выполните команду show cam aging , чтобы проверить время устаревания CAM на данном коммутаторе. Процессы TCN и быстрого устаревания выполняются достаточно редко. Поэтому данное сообщение имеет уровень важности 3. Если сети VLAN часто участвуют в процессе быстрого устаревания, проверьте причину этого.
Наиболее распространенная причина уведомлений об изменении топологии — клиентские ПК, напрямую подключенные к коммутатору. При включении или отключении питания ПК порт коммутатора изменяет состояние, а коммутатор начинает процесс уведомления об изменении топологии. Это вызвано тем, что коммутатору неизвестно, что подключенное устройство является ПК. Коммутатору известно лишь то, что порт изменил состояние.
Чтобы разрешить данную проблему, корпорация Cisco разработала функцию PortFast для портов узлов. Преимущество PortFast заключается в том, что данная функция подавляет уведомление об изменении топологии для порта хоста. При проведени IT-аудита рекомендуется обозначать порты на которых включена функция PortFast.
Примечание: Кроме того, поскольку функция PortFast игнорирует вычисление топологии STP для порта, она может применяться только для портов хостов.
Чтобы включить PortFast для порта, выполните одну из следующих команд:
set spantree portfast mod/port enable | disable
или
set port host mod/port Корпорация Cisco рекомендует использовать эту команду, если на коммутаторе используется CatOS5.4 или более высокой версии.
Несоответствие режима магистрального соединения
Проверьте режим магистрального соединения на каждой стороне связи. Убедитесь, что на обеих сторонах используется либо один и тот же режим магистрального соединения (ISL или IEEE 802.1Q), либо на обеих сторонах режим магистрального соединения отключен. Если включить режим магистрального соединения («on» вместо «auto» или «desirable») на одном порте, а на другом его отключить (off), порты не смогут обмениваться данными. Режим магистрального соединения изменяет форматирование пакета. Порты должны согласовать формат, используемый для данного соединения, иначе они не поймут друг друга.
В CatOS используйте команду show trunk {mod/port}, чтобы проверить статус магистрали и убедиться в совпадении параметров собственной сети VLAN (для dot1q) на обеих сторонах.
Switch> (enable) sh trunk 3/1
* - indicates vtp domain mismatch
Port Mode Encapsulation Status Native vlan
-------- ----------- ------------- ------------ -----------
3/1 desirable dot1q trunking 1 Port Vlans allowed on trunk
-------- ---------------------------------------------------------------------
3/1 1-1005,1025-4094
!--- Output truncated.
Для Cisco IOS используйте команду show interfaces card-type {mod/port} trunk , чтобы проверить конфигурацию режима магистрального соединения и собственную сеть VLAN.
Router#sh interfaces fastEthernet 6/1 trunk
Port Mode Encapsulation Status Native vlan Fa6/1 desirable 802.1q
trunking 1 Port Vlans allowed on trunk Fa6/1 1-4094
!--- Output truncated.
Рекомендации, ограничения, а также дополнительные сведения о различных режимах магистрального соединения см. в следующих документах:
-
Системные требования для реализации режима магистрального соединения
-
Страница поддержки технологии магистрального соединения
Кадры jumbo, giant и baby giant
По умолчанию максимальный размер передаваемого блока данных (MTU) для кадра Ethernet равен 1500 байтам. Если в передаваемом трафике MTU превышает поддерживаемое значение MTU, коммутатор не пересылает такой пакет. Кроме того, в зависимости от аппаратного и программного обеспечения на некоторых платформах в результате увеличиваются значения счетчиков ошибок портов и интерфейсов.
-
Jumbo-кадры не определены в стандарте IEEE Ethernet и зависят от поставщика. Их можно определить как кадры размера, превышающего размер стандартного кадра Ethernet (1518 байтов, включая заголовок L2 и контрольную сумму CRC). Размер jumbo-кадров обычно значительно больше (более 9000 байтов).
-
Кадры giant определяются как кадры с неверным значением последовательности FCS, размер которых превышает размер максимального кадра Ethernet (1518 байтов).
-
Кадры baby giant — это кадры, лишь незначительно превышающие максимальный размер кадра Ethernet. Обычно это кадры размером до 1600 байтов.
Поддержка jumbo-кадров и кадров baby giant на коммутаторах Catalyst зависит от платформы и даже от модулей внутри коммутатора. Поддержка jumbo-кадров также зависит от версии программного обеспечения.
Дополнительные сведения о требованиях к системе, настройке, поиску и устранению проблем, связанных с jumbo-кадрами и кадрами baby giant см. в документе Настройка поддержки кадров jumbo/giant на коммутаторах Catalyst .
Не удается проверить связь с конечным устройством
Проверьте связь с конечным устройством, сначала отправляя эхо-запросы из напрямую подключенного коммутатора, затем последовательно проверяйте каждый порт, интерфейс и магистраль, пока не будет найден источник проблемы подключения. Убедитесь, что каждому коммутатору доступен MAC-адрес конечного устройства в таблице CAM.
В CatOS используйте команду show cam dynamic {mod/port}.
Switch> (enable) sh cam dynamic 3/1 * = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry. X = Port Security Entry $ = Dot1x Security Entry VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 2 00-40-ca-14-0a-b1 3/1 [ALL] !--- A workstation on VLAN 2 with MAC address 00-40-ca-14-0a-b1 is seen in the CAM table !--- on the trunk port of a switch running CatOS. Total Matching CAM Entries Displayed =1 Console> (enable)
Для Cisco IOS используйте команду show mac address-table dynamic или подставьте ключевое слово interface.
Router# sh mac-address-table int fas 6/3
Codes: * - primary entry vlan mac address type learn qos ports
------+----------------+--------+-----+---+-------------------------- *
2 0040.ca14.0ab1 dynamic No -- Fa6/3
!--- A workstation on VLAN 2 with MAC address 0040.ca14.0ab1 is directly connected
!--- to interface fastEthernet 6/3 on a switch running Cisco IOS.
Если известно, что в таблице CAM коммутатора действительно содержится MAC-адрес устройства, определите, принадлежит ли данное устройство сети VLAN, которой принадлежит узел, где предпринимается попытка установления связи.
Если конечное устройство относится к другой сети VLAN, необходимо настроить коммутатор L3 или маршрутизатор, чтобы разрешить связь между устройствами. Убедитесь в правильной настройке адресации L3 на конечном устройстве и в маршрутизаторе или коммутаторе L3. Проверьте IP-адрес, маску подсети, основной шлюз, конфигурацию протокола динамической маршрутизации, статические маршруты и т.д.
Использование команды Set Port Host или Switchport Host для устранения задержек во время запуска
Если станциям не удается связаться со своими основными серверами при подключении через коммутатор, то проблема может быть связана с задержками в порту коммутатора, который становится активным после включения соединения на физическом уровне. В некоторых случаях задержки могут достигать 50 секунд.
Некоторые рабочие станции просто не могут ждать так долго во время поиска своих серверов. Такие задержки вызываются протоколом STP, согласованиями режима магистрального соединения (DTP) и согласованиями EtherChannel (PAgP). Все эти протоколы можно отключить для портов доступа, где они не нужны. В результате порт или интерфейс коммутатора начинает пересылать пакеты всего через несколько секунд после установления соединения с соседним устройством.
Команда set port host введена в CatOS версии 5.4. Эта команда отключает режим канала и режим магистрального соединения и переводит порт в STP-состояние пересылки.
Switch> (enable) set port host 3/5-10 Port(s) 3/5-10 channel mode set to off. !--- The set port host command also automatically turns off etherchannel on the ports. Warning: Spantree port fast start should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc. to a fast start port can cause temporary spanning tree loops. Use with caution. !--- Notice the switch warns you to only enable port host on access ports. Spantree ports 3/5-10 fast start enabled. Dot1q tunnel feature disabled on port(s) 3/5-10. Port(s) 3/5-10 trunk mode set to off. !--- The set port host command also automatically turns off trunking on the ports.
Примечание: В CatOS версий, предшествующих версии 5.4, использовалась команда set spantree portfast {mod/port} enable . В текущих версиях CatOS сохраняется возможность использования только этой команды, однако для этого необходимо по отдельности отключить режим магистрального соединения и EtherChannel, чтобы максимально снизить время задержек при запуске рабочих станций. Ниже перечислены необходимые дополнительные команды: set port channel {mod/port} off и set trunk {mod/port} off.
Для Cisco IOS можно использовать команду switchport host , чтобы отключить объединение портов в канал и включить функцию PortFast протокола STP, и команду switchport nonegotiate , чтобы отключить пакеты согласования DTP. Используйте команду interface-range , чтобы сделать это одновременно на нескольких интерфейсах.
Router6k-1(config)#int range fastEthernet 6/13 - 18 Router6k-1(config-if-range)#switchport Router6k-1(config-if-range)#switchport host switchport mode will be set to access spanning-tree portfast will be enabled channel group will be disabled !--- Etherchannel is disabled and portfast is enabled on interfaces 6/13 - 6/18. Router6k-1(config-if-range)#switchport nonegotiate !--- Trunking negotiation is disabled on interfaces 6/13 - 6/18. Router6k-1(config-if-range)#end Router6k-1#
В Cisco IOS есть возможность использования команды global spanning-tree portfast default для автоматического применения функции PortFast к любому интерфейсу, настроенному в качестве коммутационного порта доступа уровня 2. Описание возможностей этой команды см. в Справочнике по командам для используемого выпуска программного обеспечения. Можно также воспользоваться командой spanning-tree portfast для каждого интерфейса, однако для этого необходимо по отдельности отключить режим магистрального соединения и EtherChannel, чтобы максимально снизить время задержек при запуске рабочих станций.
Дополнительные сведения об устранении задержек во время запуска см. в документе Использование режима PortFast и других команд для устранения задержек соединения во время запуска рабочей станции.
Проблемы со скоростью/дуплексным режимом, автоматическим согласованием или сетевой платой
В случае большого количества ошибок выравнивания, ошибок FCS или поздних конфликтов это может указывать на одно из следующего:
-
несоответствие дуплексных режимов
-
неисправный или поврежденный кабель
-
неполадки сетевой платы
Несоответствие дуплексных режимов
Распространенная проблема со скоростью/дуплексным режимом — несоответствие параметров дуплексных режимом между двумя коммутаторами, между коммутатором и маршрутизатором, либо между коммутатором и рабочей станцией или сервером. Такая ситуация может возникать, если параметры скорости и дуплексных режимов запрограммированы жестко вручную, или в случае проблем автоматического согласования между двумя устройствами.
Если такое несоответствие возникает между двумя устройствами Cisco с включенным протоколом CDP, в консоли или буфере регистрации обоих устройств отображаются CDP-сообщения об ошибках. Протокол CDP полезен при обнаружении ошибок, а также для сбора статистики о портах и системах соседних устройств Cisco. Протокол CDP разработан корпорацией Cisco. Он работает путем отправки пакетов хорошо известному MAC-адресу 01-00-0C-CC-CC-CC.
В рассмотренном ниже примере показаны сообщения журнала, которые появляются в результате несоответствия дуплексных режимов между двумя коммутаторами серии Catalyst 6000: на одном используется CatOS, а на другом — Cisco IOS. В таких сообщениях обычно сообщается суть несоответствия и место его возникновения.
2003 Jun 02 11:16:02 %CDP-4-DUPLEXMISMATCH:Full/half duplex mismatch detected on port 3/2 !--- CatOS switch sees duplex mismatch. Jun 2 11:16:45 %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet6/2 (not half duplex), with TBA04251336 3/2 (half duplex). !--- Cisco IOS switch sees duplex mismatch.
В CatOS используйте команду show cdp neighbor [mod/port] detail для отображения данных протокола CDP о соседних устройствах Cisco.
Switch> (enable) sh cdp neighbor 3/1 detail Port (Our Port): 3/1 Device-ID: Router Device Addresses: IP Address: 10.1.1.2 Holdtime: 133 sec Capabilities: ROUTER SWITCH IGMP Version: Cisco Internetwork Operating System Software IOS (tm) c6sup2_rp Software (c6sup2_rp-PK2S-M), Version 12.1(13)E6, EARLY DEPL OYMENT RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2003 by cisco Systems, Inc. Compiled Fri 18-Apr-03 15:35 by hqluong Platform: cisco Catalyst 6000 Port-ID (Port on Neighbors's Device): FastEthernet6/1 !--- Neighbor device to port 3/1 is a Cisco Catalyst 6000 Switch on !--- FastEth 6/1 running Cisco IOS. VTP Management Domain: test1Native VLAN: 1 Duplex: full !--- Duplex is full. System Name: unknown System Object ID: unknown Management Addresses: unknown Physical Location: unknown Switch> (enable)
Для Cisco IOS используйте команду show cdp neighbors card-type {slot/port} detail для отображения данных протокола CDP о соседних устройствах Cisco.
Router#sh cdp neighbors fastEthernet 6/1 detail ------------------------- Device ID: TBA04251336 Entry address(es): IP address: 10.1.1.1 Platform: WS-C6006, Capabilities: Trans-Bridge Switch IGMP Interface: FastEthernet6/1, Port ID (outgoing port): 3/1 Holdtime : 152 sec Version : WS-C6006 Software, Version McpSW: 6.3(3) NmpSW: 6.3(3) Copyright (c) 1995-2001 by Cisco Systems !--- Neighbor device to FastEth 6/1 is a Cisco Catalyst 6000 Switch !--- on port 3/1 running CatOS. advertisement version: 2 VTP Management Domain: 'test1' Native VLAN: 1 Duplex: full !--- Duplex is full. Router#
Установка значения «auto» для параметров скорости/дуплексного режима на одной стороне и значения «100/Full-duplex» на другой также является неправильной конфигурацией и может привести к несоответствию дуплексных режимов. Если в порту коммутатора возникает много поздних конфликтов, это обычно указывает на проблему несоответствия дуплексных режимов и может привести к переводу порта в состояние отключения из-за ошибки. Сторона с полудуплексным режимом ожидает пакеты только в определенные промежутки времени, не постоянно, поэтому получение пакета в несоответствующее время воспринимается как конфликт. Существуют и другие причины поздних конфликтов, кроме несоответствия дуплексных режимов, но это одна из самых распространенных причин. Всегда на обеих сторонах соединения настраивайте автоматическое согласование скорости/дуплексного режима или задавайте эти параметры на обеих сторонах вручную.
В CatOS используйте команду show port status [mod/port] для отображения настроек скорости и дуплексного режима и другой информации. Используйте команду set port speed и set port duplex для жесткой настройки обеих сторон на значения 10 или 100 и «half» или «full», при необходимости.
Switch> (enable) sh port status 3/1 Port Name Status Vlan Duplex Speed Type ----- -------------------- ---------- ---------- ------ ----- ------------ 3/1 connected 1 a-full a-100 10/100BaseTX Switch> (enable)
Для Cisco IOS используйте команду show interfaces card-type {slot/port} status для отображения параметров скорости и дуплексного режима, а также другой информации. Используйте команду скорость и duplex в режиме конфигурации интерфейса для жесткой настройки обеих сторон на значения 10 или 100 и «half» или «full», при необходимости.
Неисправный или поврежденный кабель
Всегда проверяйте кабель на наличие заметного повреждения или сбоя. Кабель может быть достаточно хорошим для соединений на физическом уровне, и в тоже время повреждать пакеты в результате скрытого повреждения проводов или разъемов. Проверьте или замените медный или оптоволоконный кабель. Замените конвертер GBIC (если можно) для оптоволоконных соединений. Исключите все неправильные подключения к коммутационной панели и медиаконвертеры между источником и назначением. Попробуйте вставить кабель в другой порт или интерфейс (если есть) и проверить, сохранится ли данная проблема.
Проблемы автоматического согласования и сетевых плат
Иногда возникают проблемы между коммутаторами Cisco и определенными сетевыми платами сторонних производителей. По умолчанию порты и интерфейсы коммутаторов Catalyst настроены на автоматическое согласование. Такие устройства, как портативные компьютеры или другие устройства, также обычно настраиваются на автоматическое согласование, тем не менее иногда возникают проблемы с автоматическим согласованием.
Для устранения проблем с автоматическим согласованием часто рекомендуется жестко запрограммировать обе стороны. Если ни автоматическое согласование, ни жесткое программирование не работает, возможно, возникла неполадка в микропрограмме или программном обеспечении сетевой платы. Для разрешения проблемы обновите драйвер сетевой платы до последней версии, доступной на веб-узле производителя.
Подробные сведения о разрешении проблем с параметрами скорости/дуплексного режима и автоматическим согласованием см. в документе Настройка и устранение неполадок автоматического согласования Ethernet 10/100/1000 MB в полудуплексном и дуплексном режимах.
Петли в дереве STP
Петли протокола STP могут вызвать серьезные проблемы с производительностью, маскирующиеся под неполадки портов или интерфейсов. В такой ситуации, пропускная способность снова и снова используется одними и теми же кадрами, оставляя очень мало ресурсов законному трафику.
В данном документе рассматриваются причины возможных сбоев протокола STP, информация, которую необходимо найти для идентификации источника проблемы, и типы проектов, минимизирующие риски STP.
Петли также могут вызываться однонаправленными соединениями. Дополнительные сведения о проблемах, связанных с однонаправленными соединениями, см. в разделе «UDLD: одностороннее соединение» настоящего документа.
UDLD: одностороннее соединение
Однонаправленное соединение — это соединение, при котором трафик передается только в одном направлении, а в обратном направлении трафик отсутствует. Коммутатору не известно, что соединение для обратного трафика не функционирует (соединение воспринимается портом как активное и работоспособное).
Вышедший из строя оптоволоконный кабель или другие проблемы, связанные с кабелем/портом, могут стать причиной превращения соединения в одностороннее. Эти частично работающие соединения могут вызывать такие проблемы, как петли STP, если задействованные коммутаторы не осведомлены о частичной неисправности соединения. Функция обнаружения однонаправленной связи (UDLD) может перевести порт в состояние «errdisable» при обнаружении однонаправленного соединения. Команду «udld aggressive-mode» можно использовать на коммутаторах с CatOS и Cisco IOS (сведения о поддерживаемых командах см. в заметках о выпуске) для соединений «точка-точка» между коммутаторами, в которых неправильно функционирующие соединения не допускаются. Эта функция может помочь при идентификации трудно обнаруживаемых проблем, связанных с возникновением однонаправленной связи.
Сведения о настройке функции обнаружения однонаправленной связи (UDLD) см. в документе Общие сведения и настройка протокола обнаружения однонаправленной связи (UDLD).
Отложенные кадры (Out-Lost или Out-Discard)
Большое количество отложенных или «Out-Discard» кадров (на некоторых платформах они также называются Out-Lost) означает, что выходные буферы коммутатора полностью заполнены и коммутатор был вынужден отбрасывать данные пакеты. Причиной этого может быть то, что данный сегмент функционирует при недостаточных параметрах скорости и/или дуплексного режима, либо что через порт проходит слишком большой объем трафика.
Сбои буфера вывода могут вызываться следующими причинами:
Неоптимальная скорость/дуплексный режим для заданного объема трафика
Сеть может пересылать через порт слишком много пакетов, чтобы порт мог их обработать при текущих параметрах скорости/дуплексного режима. Это может произойти на участках, где осуществляется передача от нескольких высокоскоростных портов к одному (обычно более медленному) порту. Устройство, вызвавшее зависание порта, можно подключить к более быстрому носителю. Например, если порт работает на скорости 10 Мбит/с, подключите данное устройство к порту 100 Мбит/с или к порту Gigabit. Можно изменить топологию, чтобы поменять маршрутизацию кадров.
Проблемы перегруженности: сегмент слишком занят
Если является общим, другие устройства в данном сегменте могут передавать так много данных, что у коммутатора нет возможности для передачи. По возможности избегайте каскадного подключения концентраторов. Перегруженность может привести к потере пакетов. Потеря пакетов вызывает повторные передачи на транспортном уровне, что в свою очередь приводит к возникновению задержки на уровне приложений. По возможности замените соединения с пропускной способностью 10 Мбит/с на линии 100 Мбит/с или Gigabit Ethernet. Некоторые устройства можно перенести из перегруженных в менее загруженные сегменты. Задача устранения перегруженности сети должна быть приоритетной.
Приложения
Порой характеристики передачи трафика используемых приложений могут привести к проблемам с выходными буферами. Передачи файлов NFS от подключенного к плате Gigabit сервера, использующего протокол UDP с размером окна 32K, представляют пример настройки приложения, которые приводят к данному типу проблемы. Если все другие советы и инструкции (проверка скорости/дуплексного режима, проверка наличия физических ошибок соединения, допустимости всего трафика и т.д.), предлагаемые в данном документе, не помогли устранить данную проблему, уменьшите размер отправляемых приложением блоков. Это поможет смягчить негативное влияние неполадки.
Неполадки программного обеспечения
Если наблюдаемое поведение системы/сети можно охарактеризовать только как «странное», определите конкретный узел, являющийся источником неполадок. Проведите все предложенные до сих пор проверки. Если это не помогает устранить возникшие неполадки, возможно, наличие проблем программного или аппаратного обеспечения. Обычно проще обновить программное обеспечение, чем оборудование. Сначала обновите программное обеспечение.
В CatOS используйте команду show version , чтобы проверить версию текущего программного обеспечения и освободить флеш-память для обновления.
Для Cisco IOS используйте команду show version , чтобы проверить версию текущего программного обеспечения, вместе с командой dir flash: или dir bootflash: (в зависимости от платформы), чтобы проверить доступную флеш-память для обновления
Обновление программного обеспечения
Чтобы получить информацию об обновлении ПО для коммутаторов Catalyst, выберите необходимую платформу в списке коммутаторов для ЛВС (LAN Switches) или коммутаторов ATM (ATM Switches), а затем перейдите к разделам «Configuration» (Настройка) > Software Upgrade (Обновление ПО) и Working With Configuration Files (Работа с файлами конфигурации).
Несовместимость аппаратного и программного обеспечения
Возможна ситуация, когда программное обеспечение несовместимо с оборудованием. Такое случается, когда поступает новое оборудование, требующее специальной поддержки от программного обеспечения. Для получения дополнительных сведений о совместимости программного обеспечения используйте средство Software Advisor.
Ошибки в программном обеспечении
В операционной системе могут быть ошибки. После загрузки более новой версии программного обеспечения нередко проблема устраняется. С помощью средства поиска ошибок в ПО можно искать информацию об известных ошибках в программном обеспечении.
Поврежденные образы
Образ может быть поврежден или утрачен. Чтобы получить информацию о восстановлении поврежденных образов ПО, выберите необходимую платформу в списке коммутаторов для ЛВС (LAN Switches) или коммутаторов ATM (ATM Switches), а затем перейдите к разделам «Troubleshooting» (Устранение неполадок) > «Recovery from Corrupted or Missing Software» (Восстановление поврежденного или отсутствующего образа ПО).
Ошибки оборудования
Проверьте результаты выполнения команды show module для коммутаторов серии Catalyst 6000 и 4000 с ПО CatOS или Cisco IOS.
Switch> (enable) sh mod Mod Slot Ports Module-Type Model Sub Statu
--- ---- ----- ------------------------- ------------------- ----------- 1 1 2
1000BaseX Supervisor WS-X6K-S2U-MSFC2 yes ok 15 1 1
Multilayer Switch Feature WS-F6K-MSFC2 no ok 3 3 8
1000BaseX Ethernet WS-X6408A-GBIC no faulty 5 5 48
10/100BaseTX Ethernet WS-X6348-RJ-45 no faulty
!--- Status of "faulty" indicates a possible hardware problem.
!--- This could be a line card problem, but since two mods are effected,
!--- perhaps there's a problem with the supervisor.
!--- Use the reset command (CatOS) or hw-module{mod}reset command (Cisco IOS),
!--- or try physically reseating the modules and the supervisor.
!--- Also, try moving the supervisor to slot 2.
Проверьте результаты выполнения процедуры POST на коммутаторе, чтобы проверить появление указаний на сбои портов коммутатора. В случае сбоя теста модуля или порта в результатах тестирования отображается буква «F».
В CatOS используйте команду show test , чтобы просмотреть результаты всех тестов. Чтобы просмотреть результаты тестов для каждого модуля, используйте команду show test {mod} команда:
Switch> (enable) sh test 3 Diagnostic mode: complete (mode at next reset: minimal) !--- The diaglevel is set to complete which is a longer but more thorough test. !--- The command to do this for CatOS is set test diaglevel complete. Module 3 : 16-port 1000BaseX EthernetLine Card Status for Module 3 : PASS Port Status : Ports 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ----------------------------------------------------- . . . . . . . . . . . . . . . . GBIC Status : Ports 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16----------------------------------------------------- . . . . . N . . . . . . . . N N Line Card Diag Status for Module 3 (. = Pass, F = Fail, N = N/A) Loopback Status [Reported by Module 1] : Ports 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ----------------------------------------------------- F F F F F F F F F F F F F F F F !--- The failed loopback tests mean the ports are currently unusable. !--- Use the reset {mod} command or, if necessary, physically reseat the !--- module to try and fix this problem. !--- If these steps fail, open a case with Cisco Technical Support.
Для Cisco IOS на модульных коммутаторах, таких как Cat6000 и 4000, используйте команду show diagnostics. Чтобы просмотреть результаты процедуры POST для каждого модуля, используйте команду show diagnostics module {mod} команда.
ecsj-6506-d2#sh diagnostic module 3 Current Online Diagnostic Level = Minimal
!--- The diagnostic level is set to minimal which is a shorter,
!--- but also less thorough test result.
!--- You may wish to configure diagnostic level complete to get more test results.
Online Diagnostic Result for Module 3 : MINOR ERROR
Online Diagnostic Level when Line Card came up = Minimal Test Results: (. = Pass, F = Fail, U = Unknown)
1 . TestLoopback :
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
----------------------------------------------------------------------------
. . . . . . . . . . . . . . . . . . F F F F F F
!--- Notice the MINOR ERROR test result and failed loopback test which means
!--- these ports are currently unusable.
!--- Use the hw-module{mod}reset command or, if necessary, physically reseat the
!--- module to try and fix this problem.
!--- If these steps fail, open a case with Cisco Technical Support.
Примечание: Для коммутаторов серии Catalyst 3750, 3550, 2970 , 2950/2955 и 2900/3500XL используйте команду show post , которая сообщает о прохождении или сбое проверки состояния оборудования. Индикаторы на этих портах помогают понять результаты процедуры POST. См. документ Общие сведения о результатах процедуры Post.
Чтобы получить дополнительную информацию об устранении аппаратных проблем на коммутаторах Catalyst с CatOS и Cisco IOS, перейдите на страницы поддержки ATM-коммутаторов и коммутаторов для ЛВС, выберите необходимую платформу и перейдите к разделам Troubleshooting (Устранение неполадок) > Hardware (Оборудование).
Уведомления об обнаруженных проблемах см. в разделе Field Notices (Уведомления о дефектах) для ATM-коммутаторов и коммутаторов для ЛВС.
Ошибки ввода в интерфейсе уровня 3, подключенном к коммутационному порту уровня 2.
По умолчанию все порты уровня 2 находятся в режиме dynamic desirable (динамическое согласование), поэтому такой порт пытается сформировать магистральный канал и отправляет DTP-пакеты удаленному устройству. Когда интерфейс уровня 3 подключен к порту коммутатора уровня 2, он не может интерпретировать эти кадры, что приводит к ошибкам ввода, ошибкам WrongEncap и потерям очереди ввода.
Чтобы устранить данную проблему, измените режим порта коммутатора на static access (статический доступ) или trunk (магистраль) в соответствии с требованиями.
Switch2(config)#int fa1/0/12 Switch2(config-if)#switchport mode access
или
Switch2(config)#int fa1/0/12 Switch2(config-if)#switchport trunk encapsulation dot1q
Switch2(config-if)#switchport mode trunk
Быстрое увеличение значения счетчика Rx-No-Pkt-Buff и ошибок ввода
Значение счетчика Rx-No-Pkt-Buff для портов может возрастать, если есть blade-серверы, такие как WS-X4448-GB-RJ45, WS-X4548-GB-RJ45 и WS-X4548-GB-RJ45V. Кроме того, некоторый рост отбрасывания пакетов является обычным результатом пульсирующего трафика.
Число ошибок этих типов быстро растет, особенно если через данное соединение проходит интенсивный трафик или если к данному интерфейсу подключены такие устройства, как серверы. Такой трафик высокой интенсивности перегружает выделенные ресурсы портов, что вызывает исчерпание входных буферов и быстрый рост значения счетчика Rx-No-Pkt-Buff и ошибок ввода.
Такие типы ошибок в данном интерфейсе связаны с проблемой трафика на перегруженных портах. В модулях коммутации WS-X4448-GB-RJ45, WS-X4548-GB-RJ45 и WS-X4548-GB-RJ45V есть 48 перегруженных портов в шести группах по восемь портов в каждой:
-
Порты 1, 2, 3, 4, 5, 6, 7, 8
-
Порты 9, 10, 11, 12, 13, 14, 15, 16
-
Порты 17, 18, 19, 20, 21, 22, 23, 24
-
Порты 25, 26, 27, 28, 29, 30, 31, 32
-
Порты 33, 34, 35, 36, 37, 38, 39, 40
-
Порты 41, 42, 43, 44, 45, 46, 47, 48
Восемь портов в каждой группе используют общую схему, что эффективно уплотняет группу в одно неблокируемое дуплексное подключение Gigabit Ethernet к внутренней фабрике коммутаторов. Для каждой группы из восьми портов принимаемые кадры помещаются в буфер и отправляются через общее соединение Gigabit Ethernet на внутреннюю фабрику коммутаторов. Если объем принимаемых портом данных начинает превышать возможности буфера, управление потоком отправляет удаленному порту кадр паузы, чтобы временно остановить передачу трафика и предотвратить потерю кадров.
Если количество кадров, принимаемых любой группой портов, превышает пропускную способность в 1 Гбит/с, данное устройство начинает отбрасывать кадры. Такое отбрасывание не очевидно, так как кадры отбрасываются во внутренней микросхеме ASIC, а не в реальных интерфейсах. Это может привести к уменьшению скорости передачи пакетов через данное устройство.
Если есть устройства, которые должны поддерживать передачу большого объема трафика через данный интерфейс, рассмотрите возможность такого использования одного порта в каждой группе, чтобы общая схема, используемая в одной группе, не была затронута этим трафиком. Когда модуль коммутации Gigabit Ethernet используется не полностью, соединения портов можно распределить между группами портов для максимального использования пропускной способности. Например, в случае модуля коммутации WS-X4448-GB-RJ45 10/100/1000 можно подключить порты из различных групп, например, порты 4, 12, 20 или 30 (в любом порядке), перед подключением портов из той же группы, таких как 1, 2, 3, 4, 5, 6, 7 и 8.
Если это не решает проблему, необходимо рассмотреть возможность использования модуля без перегруженных портов. Если проблему не получается решить самостоятельно, то рекомендуется обратиться в компанию осуществляющую аутсорсинговое сопровождение вашего бизнеса.
Режим магистрального соединения между коммутатором и маршрутизатором
Магистральные каналы между коммутатором и маршрутизатором могут вызвать ухудшение работоспособности порта коммутатора. Магистраль можно активировать после включения и отключения такого порта коммутатора, однако, в конце концов, его работоспособность снова может ухудшиться.
Для разрешения этой проблемы выполните следующие действия.
-
Убедитесь, что коммутатором и маршрутизатором используется протокол CDP и они могут связаться друг с другом.
-
Отключите запросы keepalive в интерфейсе маршрутизатора.
-
Заново настройте инкапсуляцию магистрали на обоих устройствах.
Когда запросы keepalive отключены, протокол CDP позволяет соединению работать в нормальном режиме.
>Лечиться путём reset system и настройкой с нуля.
Не обязательно ресетить весь коммутатор, можно счетчики на портах обнулить (clear counters ports <portlist>)
Но эта проблема аппаратная, программно её не исправишь.
Небольшая статистика, откуда на клиентских портах CRC Err:
1. Самое распространенное: аппаратное отключение от сети интернет на стороне клиента (выдергивание вилки из сетевой карты) — как следствие плохой контакт между вилкой 8р8с и розеткой сетевой карты. Патчкорды никто не использует, а жесткий кабель обжатый в вилку 8р8с со временем теряет контакт.
Лечится не ресетом коммутатора, а тупо вынуть вилку из сетевой и снова воткнуть. Иногда клиент так задрачивает вилку, что приходится ехать переобжимать.
2. неисправность сетевой карты.
3. На стороне коммутатора. Сырость, пыль, грязь. Отсутствие гибких патчкордов. Кабель обжатый «двустволкой» после небольших телодвижений контакт в разъеме 8р8с лучше не становиться.
4. неисправность порта после грозы. Либо залило коммутатор водой (было такое: пинги ходят, а на IPerf порт виснет намертво)
5. По кабелю. Скрутки, боченки кат3. Кабель алюминиевый и/или стальной. Запредельная длина (больше 100метров), Толщина жилы AWG26 вместо положенных AWG24.
Последний раз редактировалось pvl Пт авг 26, 2011 10:12, всего редактировалось 2 раз(а).
RX (recive) — принимать пакеты приходящие от клиента
TX (transmit) передавать— пакеты приходящие к клиенту
Типы ошибок:
CRC Error — ошибки проверки контрольной суммы
Undersize — возникают при получение фрейма размером 61-64 байта.
Фрейм передается дальше, на работу не влияет
Oversize — возникают при получении пакета размером более 1518 байт и правильной контрольной суммой
Jabber — возникает при получении пакета размером более 1518 байт и имеющего ошибки в контрольной сумме
Drop Pkts — пакеты отброшенные в одном из трех случаев:
Какие пакеты входят в Drop Packets при выводе show error ports?
Переполнение входного буфера на порту
Пакеты, отброшенные ACL
Проверка по VLAN на входе
Fragment — количество принятых кадров длиной менее 64 байт (без преамбулы и начального ограничителя кадра, но включая байты FCS — контрольной суммы) и содержащих ошибки FCS или ошибки выравнивания.
Excessive Deferral — количество пакетов, первая попытка отправки которых была отложена по причине занятости среды передачи.
Collision — возникают, когда две станции одновременно пытаются передать кадр данных по общей сред
Late Collision — возникают, если коллизия была обнаружена после передачи первых 64 байт пакета
Excessive Collision — возникают, если после возникновения коллизии последующие 16 попыток передачи пакета окончались неудачей. данный пакет больше не передается
Single Collision — единичная коллизия
Не всегда понятно что может означать та или иная ошибка при передаче. Ниже моя попытка объяснить значение счетчиков ошибок, которые регистрирует коммутатор.
Счетчики ошибок при получении кадров (RX):
CRC Error
Counts otherwise valid packets that did not end on a byte (octet) boundary.
Счетчик ошибок контрольной суммы (CRC). В свою очередь, является суммой счетчиков Alignment Errors и FCS Errors.
FCS (Frame Check Sequence) Errors — ошибки в контрольной последовательности кадра. Счетчик регистрирует кадры с ошибками FCS, при этом кадры имеют корректный размер (от 64 до 1518 байт) и получены без ошибок кадрирования или коллизий.
Alignment Errors — ошибки выравнивания (некорректной длины кадра). Счетчик регистрирует кадры с ошибками FCS, при этом кадры имеют корректный размер (от 64 до 1518 байт), но были получены с ошибками кадрирования.
В случае, если кадр был классифицирован как имеющий ошибку Alignment Error, счетчик FCS при этом не увеличивается. Иными словами, инкрементируется либо счетчик FCS либо Aligment, но не оба сразу.
UnderSize
The number of packets detected that are less than the minimum permitted packets size of 64
bytes and have a good CRC. Undersize packets usually indicate collision fragments, a normal
network occurrence.
Счетчик кадров с правильной контрольной суммой и размером менее 64 байт. Такие кадры могут возникать в результате коллизий в сети.
OverSize
Counts valid packets received that were longer than 1518 octets and less than the
MAX_PKT_LEN. Internally, MAX_PKT_LEN is equal to 1536.
Счетчик кадров с правильной контрольной суммой, размер которых превышает 1518 байт, но не превышает 1536 байт — внутреннего максимального значения кадра.
Fragment
The number of packets less than 64 bytes with either bad framing or an invalid CRC. These
are normally the result of collisions.
Счетчик кадров с неправильной контрольной суммой или структурой кадра и размером менее 64 байт. Такие кадры могут возникать в результате коллизий в сети.
Jabber
Counts invalid packets received that were longer than 1518 octets and less than the
MAX_PKT_LEN. Internally, MAX_PKT_LEN is equal to 1536.
Счетчик кадров с неправильной контрольной суммой, размер которых превышает 1518 байт, но не превышает 1536 байт — внутренного максимального значения кадра.
Счетчик ошибок при отправке кадров (TX):
Excessive Deferrral
Counts the number of packets for which the first transmission attempt on a particular
interface was delayed because the medium was busy.
Счетчик кадров, первая попытка отправки которых было отложена из-за занятости среды передачи.
CRC Error
Counts otherwise valid packets that did not end on a byte (octet) boundary.
Счетчик ошибок контрольной суммы (CRC).
На практике никогда не увеличивается.
Late Collision
Counts the number of times that a collision is detected later than 512 bit-times into the
transmission of a packet.
Счетчик случаев когда коллизия обнаруживалась после передачи первых 64 байт (512 бит) кадра.
Excessive Collision
Excessive Collisions. The number of packets for which transmission failed due to excessive
collisions.
Счетчик кадров, отправка которых не удалась из-за чрезмерного количества колизий.
Single Collision
Single Collision Frames. The number of successfully transmitted packets for which
transmission is inhibited by more than one collision.
Счетчик успешно отправленных кадров, передача которых вызвала более одной коллизии.
Collision
An estimate of the total number of collisions on this network segment.
Счетчик общего числа коллизий в сегменте сети.
Моно добавить, что на практике RX CRC обычно является результатом деградации среды передачи (медный кабель или оптоволокно), а TX-коллизии — результатом неправильного согласования скорости соединения, например half-линка.
Неплохая расшифровка значений счетчиков приведена тут.
input errors: counter of error packets received from this port
CRC: counter of packets with CRC checksum error
frame alignment: counter of packets not just multiple of bytes
overrun: counter of packets dropped because input queue is full
ignored: miss error packets
abort: just larger than MTU and no other errors
length error: no sense in this device, the value is always 0 here
undersize: RFC 1757 under size packets
jabber: larger than MTU and with checksum error
fragments: less the 64 bytes and with checksum error
pause frame: delay packets
underruns: dropped because the output bandwidth not enough
output errors: counter of error packets output from this port
late collisions: collision error occurs after the first 512 bits of data are transmitted by the transmitting station
pause frame: delay packets
Процесс обновления коммутаторов QTECH данных моделей производится по следующему алгоритму:
1) Настройка mgmt порта для управления стеком коммутаторов.
2) Проверка доступности TFTP сервера.
3) Введение команды инициирующей загрузку и установку новой версии ПО.
4) Перезагрузка устройств.
…
Для данной линейки коммутаторов, если у вас появилась необходимость организовать динамически назначаемый Voice Vlan, вам необходимо
Разрешить получение LLDP информации.
Создать Voice vlan
перевести порт в режим работы Trunk
Проверить что на порту разрешено LLDP
Указать Voice Vlan на пор…
Vlan-translation
VLAN-translation — это функция, которая позволяет преобразовать тэг VLAN пакета в новый в соответствии с требованиями. Это позволяет обмениваться данными в разных VLAN.
VLAN-translation может быть использован на обоих направлениях трафика.
Ниж…
К списку
Проблемы, с которыми приходится сталкиваться в коммутируемой сетевой среде, мало чем отличаются от сбоев в разделяемой среде передачи.
Поэтому и вопросы, на которые требуется ответить, одинаковые: что случилось? кто это сделал? каков будет ущерб? Принципиальная разница заключается
в том, что в коммутируемой среде ответы должны относиться к конкретному порту, а значит, следует учитывать следующие факторы:
-
насколько интенсивно используется каждый порт;
-
каким образом идентифицируется и отслеживается источник ошибок;
-
что является источником широковещательного шторма;
-
правильно ли работают таблицы пересылки;
-
какие рабочие станции подключены к конкретному порту;
-
накладывает ли коммутатор ограничения по скорости на какие-либо протоколы или порты;
-
относится ли порт к виртуальной сети VLAN, и если да, то принадлежит ли сервер или служба к той же самой виртуальной сети?
С чего следует начинать, когда вы получаете сообщение о том, что в коммутируемой сети возникла проблема? Как правило, главная трудность заключается в невозможности «заглянуть» внутрь коммутатора. Источник неполадок следует искать в первую очередь на втором уровне сетевой модели OSI при организации коммутатором моста, при этом использование виртуальных сетей VLAN и других функций третьего и более высоких уровней, а также правил продвижения трафика, может дополнительно осложнить ситуацию. Если в сети реализованы «продвинутые» функции коммутации, например, маршрутизация на четвертом уровне и выше вкупе с балансировкой нагрузки, то за диагностику должен браться специалист, отлично разбирающийся во всех тонкостях настройки коммутаторов.
Устанавливая в сети коммутатор, вы фактически создаете отдельный коллизионный домен на каждом порту – именно таков принцип работы коммутаторов. Если к порту подключить концентратор, ресурсы которого используются совместно, то коллизионный домен может увеличиться до максимально допустимого для данного варианта Ethernet размера. Коммутирующее оборудование постоянно дешевеет, поэтому в большинстве современных сетей к каждому порту подключается всего одна рабочая станция, и в этом случае коллизионный домен состоит из единственного кабельного сегмента.
Коммутатор, в целом в свою очередь, является частью отдельного широковещательного домена, причем иногда в домен входят несколько коммутаторов, объединенных в каскад или подключенных параллельно. При использовании функций третьего уровня модели OSI в сети создается большое количество широковещательных доменов — по числу виртуальных сетей VLAN. В предельном случае, если, конечно, коммутатор допускает это, каждый порт может быть сконфигурирован как отдельный широковещательный домен. Такая конфигурация, с полным на то основанием, называется прямой маршрутизацией до рабочего места пользователя.
Если на каждом порту создается собственный широковещательный домен, то возможности диагностики сильно ограничены. Кроме того, организация отдельного широковещательного домена на каждом порту требует от коммутатора выделения для маршрутизации значительной части ресурсов центрального процессора на продвижение всего сетевого трафика. В реальной жизни очень трудно представить себе сеть, где требовалось бы обрабатывать и перенаправлять каждый запрос и отклик по отдельности. При отсутствии очень веских оснований создания именно такой структуры сети следует избегать.
К сожалению, весьма распространена конфигурация, когда в одну подсеть или широковещательный домен помещаются все серверы, а пользователи распределены по некоторому количеству других подсетей или широковещательных доменов. В таком случае практически все запросы должны маршрутизироваться. Если ради удобства обслуживания необходимо разместить все серверы в одном помещении (серверной), то их рекомендуется распределить по нескольким виртуальным сетям VLAN. Пользователей, которые обращаются к конкретному серверу, следует отнести к той же виртуальной сети. В такой конфигурации матрица коммутатора может использовать для обычного трафика мост на втором уровне модели OSI, поэтому маршрутизироваться будут только нетипичные или редкие запросы. Если сервер обслуживает более одного сообщества пользователей, то установите в него дополнительные сетевые карты, чтобы связь осуществлялась на втором уровне модели OSI.
ТОЧНОЕ РАСПОЗНАВАНИЕ ПРОБЛЕМЫ
Чуть ли не единственный по-настоящему эффективный метод диагностики коммутируемых сетей — запрос информации о поведении сети у самого коммутатора. Такие данные обычно запрашиваются с помощью протокола SNMP, либо через консольный порт коммутатора. Разумеется, прямое подключение к консольному порту менее удобно, поскольку администратору придется подходить к каждому коммутатору в сети. Во избежание подобных неудобств можно, конечно, установить терминальные серверы и подключить их к консольным портам, но все-таки предпочтительнее использовать протокол SNMP, поскольку он позволяет отправлять запросы из любой точки сети и для этого не нужно устанавливать дополнительное оборудование.
При наличии системы управления сетью коммутатор можно настроить таким образом, чтобы он сам отправлял незапрашиваемый ответ — уведомление SNMP trap – каждый раз, когда уровень использования, количество ошибок или какой-то другой параметр превышают установленное пороговое значение. Причину можно выяснить позже — с помощью системы управления сетью или инструментов мониторинга. Множество проблем успешно разрешается путем запроса к коммутатору, но есть такие, для которых этот способ непригоден. Запрос может применяться как в качестве профилактики, так и для осуществления мониторинга в случае сбоя.
Другая стратегия – дождаться, пока от пользователей начнут поступать жалобы. Во многих сетях применяется именно такой подход, который не стоит недооценивать из-за внешней простоты – на самом деле, он очень эффективен. Пользователи чутко реагируют на состояние сети, несмотря на то, что представление о ее работе больше основывается на подсознательном восприятии, чем на логических заключениях. Заметив малейшее ухудшение
в работе сети, пользователь обычно тут же обращается с жалобой в отдел ИТ или к системному администратору. Так что работу по поиску и устранению неисправности можно начать с его рабочего места. Такой подход называется реактивным, поскольку предполагает реагирование на уже произошедший сбой.
Напротив, профилактические, проактивные методы направлены на то, чтобы не допустить возникновения сбоя. Для этого проводится регулярный опрос коммутаторов, мониторинг качества трафика на каждом порту коммутатора и в каждом сегменте. Когда проблема уже появилась (поступила жалоба, либо вы сами обнаружили сбой), диагностировать ее можно разными методами, каждый из которых имеет свои плюсы и минусы.
МЕТОДЫ ДИАГНОСТИРОВАНИЯ КОММУТАТОРОВ
Получить информацию о работе коммутатора можно как минимум десятью основными способами. Каждый предполагает свой порядок действий и имеет свои положительные и отрицательные стороны. Как обычно, единого рецепта на все случаи жизни не существует. Выбирать подходящее решение из разных вариантов следует, прежде всего, исходя из доступности ресурсов, опыта специалиста, проводящего работы, и оценки последствий для функционирования сети (приостановка, перерывы в работе) при использовании того или иного метода.
Однако даже сочетание всех методов не позволяет следить за коммутируемой сетью в таких подробностях, как это можно было делать в сетях на базе концентраторов. Увидеть и отследить абсолютно весь трафик и все ошибки, относящиеся к коммутатору, практически невозможно. Большинство диагностических процедур подразумевает, что трафик проходит между рабочей станцией и соответствующим сервером или направляется на магистральный порт. Если две рабочие станции обмениваются данными напрямую через одноранговое (пиринговое) соединение, то трафик не проходит ни через магистральный порт, ни через какой-либо другой порт коммутатора. Такие соединения редко обнаруживаются, если только не искать их специально. Обычно ошибки не распространяются за пределы порта коммутатора, однако для некоторых их типов и определенных настроек коммутаторов возможна и дальнейшая трансляция.
Для простоты представим себе минимальный сегмент сети: сервер, подключенный к коммутатору. В одних случаях мы будем предполагать, что пользователи, испытывающие проблемы, подключены к тому же самому коммутатору, в других — что они будут пытаться получить доступ к серверу через магистральный порт, ведущий либо к другому коммутатору, либо к маршрутизатору. Диагностика начинается в ответ на жалобу о медленной работе сети при обращении к серверу. К сожалению, такое описание проблемы ничего не говорит специалисту ИТ. Если речь идет не об обычном сбое, а взломе системы защиты, причем предполагаются последствия юридического характера, то необходимо принять дополнительные меры, чтобы обеспечить достоверность и юридическую силу собираемых данных.
Информация, относящаяся сразу к нескольким методам, будет приводиться в описании того метода, в котором она раскрывается наиболее полно. Большая часть описаний относится также к методам, отличным от того, которому посвящен конкретный раздел, причем она может иметь как тривиальные, так и фундаментальные последствия для конечного результата.
МЕТОД 1: КОНСОЛЬНЫЙ ДОСТУП К КОММУТАТОРУ
Получить доступ к настройкам коммутатора можно разными способами, включая следующие:
-
войти в систему с помощью сеанса TELNET;
-
войти в систему с помощью сеанса SSH;
-
войти в систему через сеанс Web;
-
подключиться через последовательный порт коммутатора.
Некоторые коммутаторы обладают рядом встроенных диагностических средств, которыми можно воспользоваться, но следует помнить, что их функциональные возможности существенно различаются в зависимости от производителя и модели коммутатора. Расширенные команды операционной системы позволяют провес-ти более глубокий анализ транслируемого трафика, однако имеющийся интерфейс нельзя назвать дружественным к пользователю. Чтобы успешно применить такие функции, надо обладать значительным опытом и глубоким знанием теории сетей.
Плюсы. Консольный доступ – очень эффективный метод диагностики, он широко распространен и используется чаще других. Множество самых разных проблем в сети вызвано именно неправильными настройками коммутаторов и выполняемыми в соответствии с этими настройками действиями.
Получить доступ к консоли управления коммутатором можно всегда — одним из вышеперечисленных способов. Почти повсеместная доступность беспроводных сервисов и услуг передачи данных, предоставляемых мобильной связью, позволяют управлять сетью из любой точки планеты. Настроив систему управления сетью на отправку уведомлений на мобильные устройства, вы сразу узнаете о возникновении сбоя.
Если сбой действительно вызван настройками, то метод консольного доступа, безусловно, позволит устранить его.
Минусы. Старшие системные администраторы и другие ведущие сотрудники отделов ИТ, обладающие паролями для доступа к настройкам коммутаторов, при проведении диагностики уделяют столь повышенное внимание конфигурации, что никакие другие варианты даже не приходят им в голову, пока этот метод себя полностью не исчерпает. Между тем, отказ от прочих подходов может существенно задержать устранение сбоя и дополнительно осложнить ситуацию. С помощью только консольного доступа удается выявить и устранить только часть сетевых проблем.
Обычные команды, подаваемые с помощью консоли, позволяют установить средние уровни использования, но не дают информации о конкретных видах сетевой активности или исходной причине сбоя того или иного протокола. Более того, данные, получаемые с помощью консольного доступа, указывают, скорее, на то, как сеть должна работать, а не сообщают о реальном положении дел, поэтому они мало помогут в случае, например, некорректного функционирования части коммутатора. Просмотр конфигурации не позволяет выявить программные ошибки в операционной системе или неточности и упущения в настройках. Иногда, выведя дамп конфигурации на экран, нельзя узнать настройки по умолчанию, поскольку выдаются только изменения по сравнению с настройками по умолчанию. Между тем, причиной снижения производительности сети вполне могут быть именно эти настройки.
Данные о конфигурации полезны для того, чтобы в общих чертах выяснить, работает ли коммутатор так, как должен. Однако для проверки конфигурации и производительности сети нужно применять иные методы диагностики коммутаторов — возможно, даже не один,
а несколько.
Если речь идет о критически важных сегментах сети, то консольный доступ из удаленных точек может быть либо запрещен, либо разрешен только с конкретной группы жестко фиксированных адресов. Обычно пароли для доступа к коммутаторам не известны рядовому персоналу отделов ИТ и служб технической поддержки, поэтому они не имеют возможности использовать консольный доступ. Инженеры более высокого уровня, располагающие паролями, как правило, не участвуют в ежедневной работе по устранению сбоев в сетях. А теперь представьте, каким образом специалист, в прямые обязанности которого входит постоянное поддержание производительности сети, сможет эффективно работать, если консольный доступ ему запрещен?
О других методах диагностирования коммутаторов мы расскажем в следующих выпусках рубрики.
Игорь Панов — региональный менеджер по продукции и поддержке партнеров Fluke Networks в России и СНГ. С ним можно связаться по адресу: igor.panov@flukenetworks.com.