Интерфейсы и модули Cisco : Адаптеры портов Cisco

Диагностика коллизий Ethernet

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


Содержание


Введение

В этом документе рассмотрены различные счетчики, относящиеся к конфликтам Ethernet, и поясняется устранение проблем, связанных с конфликтами Ethernet, на которые указывают соответствующие сообщения об ошибках (в зависимости от платформы):

  • %AMDP2_FE-5-COLL

  • %DEC21140-5-COLL

  • %ILACC-5-COLL

  • %LANCE-5-COLL

  • %PQUICC-5-COLL

  • %PQUICC_ETHER-5-COLL

  • %PQUICC_FE-5-COLL

  • %QUICC_ETHER-5-COLL

  • %AMDP2_FE-5-LATECOLL

  • %DEC21140-5-LATECOLL

  • %ILACC-5-LATECOLL

  • %LANCE-5-LATECOLL

  • %PQUICC-5-LATECOLL

  • %PQUICC_ETHER-5-LATECOLL

  • %PQUICC_FE-5-LATECOLL

  • %QUICC_ETHER-5-LATECOLL

  • %SIBYTE-4-SB_EXCESS_COLL

Примечание: Сведения в этом документе только применяются к полудуплексному Ethernet. В полнодуплексном Ethernet отключено обнаружение коллизий.

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

Требования

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

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

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

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

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

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

Что такое конфликты?

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

Ethernet использует CSMA/CD (множественный доступ с анализом состояния канала/обнаружение конфликтов) в качестве своего метода обнаружения конфликтов. Вот упрощенный пример работы Ethernet:

eth_collisions.gif

  1. Станция A собирается отправить кадр. В первую очередь проверяется доступность носителя (контроль несущей). Если это не, это ждет, пока не закончил текущий отправитель на среде.

  2. Допустим, станция A считает, что среда передачи доступна и пытается отправить кадр. Поскольку среда разделена (Множественный доступ), другие отправители могли бы также попытаться передать в то же время. На этом этапе Станция B пытается передать кадр в то же время, что и Станция A.

  3. Сразу после этого станции Station A и Station B обнаруживают еще одно устройство, пытающееся отправить кадр (обнаружение конфликта). Каждая станция ожидает в течение произвольного периода времени, прежде чем снова начать передачу. Время после коллизии разделено на временные интервалы; Станция A и станция B каждая выбирает случайный слот для попытки повторной передачи.

  4. Если станция А и станция B попытаются выполнить повторную передачу в течение одного и того же временного интервала, число интервалов увеличится. Каждая станция тогда выбирает новый слот, таким образом уменьшая вероятность ретранслирования в том же слоте.

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

Некоторые полезные сведения:

  • Максимальное количество временных интервалов ограничено до 1024.

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

Счетчик задержанных пакетов

Вот пример вывода от команды show interface:

router#show interface ethernet 0
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0010.7b36.1be8 (bia 0010.7b36.1be8)
  Internet address is 10.200.40.74/22
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:06, output hang never
  Last clearing of "show interface" counters never
  Input queue: 1/75/1/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: random early detection(RED)
  Output queue :0/40 (size/max)
  5 minute input rate 1000 bits/sec, 2 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     2058015 packets input, 233768993 bytes, 1 no buffer
     Received 1880947 broadcasts, 0 runts, 0 giants, 1 throttles
     3 input errors, 0 CRC, 0 frame, 0 overrun, 3 ignored
     0 input packets with dribble condition detected
     298036 packets output, 32280269 bytes, 0 underruns
     0 output errors, 10 collisions, 0 interface resets
     0 babbles, 0 late collision, 143 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

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

Счетчик конфликтов

Вот другой пример вывода от команды show interface:

router#show interface ethernet 0
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0010.7b36.1be8 (bia 0010.7b36.1be8)
  Internet address is 10.200.40.74/22
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:06, output hang never
  Last clearing of "show interface" counters never
  Input queue: 1/75/1/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: random early detection(RED)
  Output queue :0/40 (size/max)
  5 minute input rate 1000 bits/sec, 2 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     2058015 packets input, 233768993 bytes, 1 no buffer
     Received 1880947 broadcasts, 0 runts, 0 giants, 1 throttles
     3 input errors, 0 CRC, 0 frame, 0 overrun, 3 ignored
     0 input packets with dribble condition detected
     298036 packets output, 32280269 bytes, 0 underruns
     0 output errors, 10 collisions, 0 interface resets
     0 babbles, 0 late collision, 143 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

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

Счетчик коллизий может быть настроен на простые коллизии и множественные коллизии, как в выходе команды show controller:

8 single collisions, 2 multiple collisions

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

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

Нет никакого установленного предела для, "сколько коллизий плохо" или максимальная частота конфликтов.

В заключение счетчик коллизий не предоставляет очень полезная статистика для анализа производительности сети или проблем.

Late collisions (поздние конфликты)

Чтобы позволить обнаружению коллизий работать должным образом, период, в который обнаружены коллизии, ограничен (512 битовых интервалов). Для Ethernet это 51.2us (микросекунд), а для Fast Ethernet – 5.12us. Для Станций Ethernet коллизии могут быть обнаружены спустя 51.2 микросекунды после того, как передача начинается, или другими словами до 512-го бита кадра.

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

О запоздалых коллизиях сообщают эти сообщения об ошибках:

%AMDP2_FE-5-LATECOLL: AMDP2/FE 0/0/[dec], Late collision 
%DEC21140-5-LATECOLL: [chars] transmit error 
%ILACC-5-LATECOLL: Unit [DEC], late collision error 
%LANCE-5-LATECOLL: Unit [DEC], late collision error 
%PQUICC-5-LATECOLL: Unit [DEC], late collision error 
%PQUICC_ETHER-5-LATECOLL: Unit [DEC], late collision error 
%PQUICC_FE-5-LATECOLL: PQUICC/FE([DEC]/[DEC]), Late collision    
%QUICC_ETHER-5-LATECOLL: Unit [DEC], late collision error

Конкретное сообщение об ошибках зависит от платформы. Можно проверить количество избыточных коллизий в выходных данных ethernet show interface [номер интерфейса] команда.

router#show interface ethernet 0
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0010.7b36.1be8 (bia 0010.7b36.1be8)
  Internet address is 10.200.40.74/22
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:06, output hang never
  Last clearing of "show interface" counters never
  Input queue: 1/75/1/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: random early detection(RED)
  Output queue :0/40 (size/max)
  5 minute input rate 1000 bits/sec, 2 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     2058015 packets input, 233768993 bytes, 1 no buffer
     Received 1880947 broadcasts, 0 runts, 0 giants, 1 throttles
     3 input errors, 0 CRC, 0 frame, 0 overrun, 3 ignored
     0 input packets with dribble condition detected
     298036 packets output, 32280269 bytes, 0 underruns
     0 output errors, 10 collisions, 0 interface resets
     0 babbles, 0 late collision, 143 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

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

Частые коллизии

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

Об избыточных коллизиях сообщают эти сообщения об ошибках:

%AMDP2_FE-5-COLL: AMDP2/FE 0/0/[DEC], Excessive collisions, TDR=[DEC], TRC=[DEC]    
%DEC21140-5-COLL: [chars] excessive collisions 
%ILACC-5-COLL: Unit [DEC], excessive collisions. TDR=[DEC] 
%LANCE-5-COLL: Unit [DEC], excessive collisions. TDR=[DEC]    
%PQUICC-5-COLL: Unit [DEC], excessive collisions. Retry limit [DEC] exceeded    
%PQUICC_ETHER-5-COLL: Unit [DEC], excessive collisions. Retry limit [DEC] exceeded    
%PQUICC_FE-5-COLL: PQUICC/FE([DEC]/[DEC]), Excessive collisions, TDR=[DEC], TRC=[DEC]
%QUICC_ETHER-5-COLL: Unit [DEC], excessive collisions. Retry limit  [DEC] exceeded
%SIBYTE-4-SB_EXCESS_COLL : Excessive collisions on mac [dec] (count: [dec])

Конкретное сообщение об ошибках зависит от платформы.

Примечание: Счетчик Числа повторов передачи (TRC) является 4-разрядным полем, которое указывает на количество повторных попыток передачи соответствующего пакета. Максимальное число отсчетов равно 15. Однако если возникает ошибка повтора, число сбрасывается до нуля. Только в этом случае нулевое значение TRC следует понимать как шестнадцать. TRC записывается контроллером в последний дескриптор передачи кадра или при прерывании кадра ошибкой.

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

Количество избыточных коллизий можно узнать из выходных данных команды show controller ethernet [номер интерфейса].

router#show controller ethernet 0
LANCE unit 0, idb 0xFA6C4, ds 0xFC218, regaddr = 0x2130000, reset_mask 0x2
IB at 0x606E64: mode=0x0000, mcfilter 0000/0000/0100/0000
station address 0010.7b36.1be8  default station address 0010.7b36.1be8
buffer size 1524
RX ring with 16 entries at 0x606EA8
Rxhead = 0x606EC8 (4), Rxp = 0xFC244 (4)
00 pak=0x0FCBF4 Ds=0x60849E status=0x80 max_size=1524 pak_size=66
01 pak=0x10087C Ds=0x6133B6 status=0x80 max_size=1524 pak_size=66
02 pak=0x0FDE94 Ds=0x60BA7E status=0x80 max_size=1524 pak_size=203
03 pak=0x100180 Ds=0x611F82 status=0x80 max_size=1524 pak_size=66
04 pak=0x0FD09C Ds=0x609216 status=0x80 max_size=1524 pak_size=66
05 pak=0x0FE590 Ds=0x60CEB2 status=0x80 max_size=1524 pak_size=66
06 pak=0x100AD0 Ds=0x613A72 status=0x80 max_size=1524 pak_size=66
07 pak=0x0FD9EC Ds=0x60AD06 status=0x80 max_size=1524 pak_size=66
08 pak=0x0FF830 Ds=0x610492 status=0x80 max_size=1524 pak_size=348
09 pak=0x1003D4 Ds=0x61263E status=0x80 max_size=1524 pak_size=343
10 pak=0x0FEA38 Ds=0x60DC2A status=0x80 max_size=1524 pak_size=66
11 pak=0x100D24 Ds=0x61412E status=0x80 max_size=1524 pak_size=64
12 pak=0x0FC74C Ds=0x607726 status=0x80 max_size=1524 pak_size=64
13 pak=0x0FD798 Ds=0x60A64A status=0x80 max_size=1524 pak_size=66
14 pak=0x0FE7E4 Ds=0x60D56E status=0x80 max_size=1524 pak_size=64
15 pak=0x0FD2F0 Ds=0x6098D2 status=0x80 max_size=1524 pak_size=66
TX ring with 4 entries at 0x606F68, tx_count = 0
TX_head = 0x606F80 (3), head_txp = 0xFC294 (3)
TX_tail = 0x606F80 (3), tail_txp = 0xFC294 (3)
00 pak=0x000000 Ds=0x63491E status=0x03 status2=0x0000 pak_size=332
01 pak=0x000000 Ds=0x634FDA status=0x03 status2=0x0000 pak_size=327
02 pak=0x000000 Ds=0x630A9E status=0x03 status2=0x0000 pak_size=60
03 pak=0x000000 Ds=0x630A9E status=0x03 status2=0x0000 pak_size=60
3 missed datagrams, 0 overruns
0 transmitter underruns, 0 excessive collisions
8 single collisions, 2 multiple collisions
0 dma memory errors, 0 CRC errors
 
0 alignment errors, 0 runts, 0 giants
0 tdr, 0 spurious initialization done interrupts
0 no enp status, 0 buffer errors, 0 overflow errors
0 TX_buff, 1 throttled, 1 enabled
Lance csr0 = 0x73

Избыточные коллизии указывают на проблему. Обычные последствия – соединение устройств в режиме полного дуплекса на совместно используемом Ethernet, разрушенные NIC, или просто слишком много станций на совместно используемой среде. Избыточные коллизии могут быть решены скоростью и дуплексным режимом жесткого кодирования.

Если сервисный внутренний режим идет, в коммутаторах Cisco Catalyst системное сообщение %SIBYTE-4-SB_EXCESS_COLL отображено для каждого возникновения избыточных коллизий. С сервисным внутренним режимом прочь, система только распечатывает это сообщение каждый раз, когда избыточные коллизии достигают определенного, некоторый неподвижного порога. В этом случае появление этого сообщения могло бы указать на реальный случай коллизии. С сервисным внутренним режимом на система распечатывает это сообщение каждый раз, когда существует один экземпляр избыточных коллизий. Это могло бы быть вызвано некоторым аппаратным шумом. Случайное появление этого сообщения с сервисным внутренним режимом на является нормальным поведением. Можно выполнить команду no service internal, чтобы выключить эту регистрацию и видеть, как это влияет на журналы ошибок.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


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


Document ID: 12768