input errors cisco что это

Ошибки на интерфейсах в Cisco || CRC || Collisions || Input/Output rate || Giants || Runts || throttles || Discards

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

[slimterm]RT1R#show interface FastEthernet6/1
FastEthernet6/1 is up, line protocol is up (connected)
Hardware is C6k 100Mb 802.3, address is 0009.11f3.8848 (bia 0009.11f3.8848)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Full-duplex, 100Mb/s
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:14, output 00:00:36, 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 0 bits/sec, 0 packets/sec
1117058 packets input, 78283238 bytes, 0 no buffer
Received 1117035 broadcasts, 0 runts, 0 giants, 0 throttles
79 input errors, 5 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
285811 packets output, 27449284 bytes, 0 underruns
6 output errors, 0 collisions, 2 interface resets
0 babbles, 1 late collision, 0 deferred
0 lost carrier, 0 no carrier
1 output buffer failures, 0 output buffers swapped out[/slimterm]

Значение	Описание
FastEthernet6/1 is up, line protocol is up (connected)	Первое «up» относится к состоянию физического уровня интерфейса. Сообщение «line protocol up» отображает состояние уровня канала передачи данных интерфейса и говорит, что интерфейс может отправлять и получать информацию в реальном времени. Если в статусе administratively down то интерфейс был отключен администратором.
Hardware	Указывает тип и адрес аппаратного обеспечения
Internet address	Задает Internet адрес за которым следует маска подсети
MTU	Максимальная единица передачи интерфейса. По умолчанию 1500 байт
BW	Пропускная способность интерфейса в килобитах в секунду.
DLY	Задержка интерфейса в микросекундах.
Reliability	Надежность интерфейса как части 255 (255/255 — 100-процентная надежность), рассчитанная как экспоненциальная средняя за 5 минут.
Load	Нагрузка на интерфейс как часть 255 (255/255 полностью насыщена), рассчитанная как экспоненциальная средняя за 5 минут.
Encapsulation	Метод инкапсуляции, назначенный интерфейсу.
ARP type	Назначенный тип Address Resolution Protocol
Loopback	Указывает, установлена ли петля.
Keepalive	Указывает, установлены ли keepalives.
Last input	Выдает количество часов, минут и секунд с момента успешного приема последнего пакета интерфейсом. Это полезно для того, чтобы знать, когда произошёл сбой на интерфейсе.
Last output	Выдает количество часов, минут и секунд, прошедших с момента последней успешной передачи пакета интерфейсом.
Output	Указывает количество часов, минут и секунд, прошедших с момента успешной отправки последнего пакета интерфейсом. Это полезно для того, чтобы знать, когда произошёл сбой на интерфейса.
Output hang	Количество часов, минут и секунд (или никогда) с момента последнего сброса интерфейса из-за слишком долгой передачи. Когда количество часов в любом из последних полей превышает 24 часа, печатается количество дней и часов. Если это поле переполняется, печатаются звездочки
Output queue, input queue, drops	Выдает количество пакетов в выходных и входных очередях. За каждым номером следует косая черта, максимальный размер очереди и количество drop пакетов в полной очереди.
Five minute input rate, Five minute output rate	Среднее число бит и пакетов, переданных / принятых в секунду за последние 5 минут.
Packets input	Выдает общее количество безошибочных пакетов, полученных системой
Bytes input	Дает общее количество байтов, включая данные и инкапсуляцию MAC, в пакеты без ошибок, полученные системой.
No buffers	Количество входных пакетов, сброшенных из-за отсутствия буферов. Сравните с проигнорированным.
Broadcasts/Multicasts	Количество broadcast или multicast пакетов, полученных интерфейсом.
Runts	Фрэймы, принятые короче 64 байт
Giants	Полученные фрэймы размером более 1518 байт
Throttles	Количество раз, когда интерфейс запрашивал другой интерфейс в маршрутизаторе для замедления, возможно из-за перегрузки буфера или процессора.
Input error	Всего no buffer, runts, giants, CRCs, frame, overrun, ignored, и aborts. Это может не уравновешиваться с другими показателями.
CRC	Ошибка проверки циклического избыточности на входном пакете.
Frame	Число полученных кадров, которые не заканчивались на границе 8-битного байта
Overrun	Количество раз, когда аппаратура приемника не могла передать принятые данные в аппаратный буфер, потому что скорость ввода превышала способность приемника обрабатывать данные.
Ignored	Пакеты сброшены, потому что аппаратному буферу интерфейса не хватало внутренних буферов. Эти буферы отличаются от системных буферов, упомянутых ранее.
Input packets with dribble condition detected	Выдает ошибку бита, которая указывает, что кадр является слишком длинным. Этот счетчик ошибок кадров увеличивается только для информационных целей; Маршрутизатор принимает фрейм.
Packets output	Показывает общее количество сообщений, передаваемых системой.
Bytes	Показывает общее количество байтов, включая данные и инкапсуляцию MAC, переданных системой.
Under runs	Количество раз, которое передатчик работал быстрее, чем может обрабатывать маршрутизатор. Это может никогда не сообщаться на некоторых интерфейсах.
Dribble condition detected	Ошибка бита указывает, что кадр является слишком длинным. Этот счетчик ошибок кадров увеличивается только для информационных целей; Маршрутизатор принимает фрейм.
Output errors	Сумма всех выходных ошибок. Это может не совпадать с ошибкой вывода
Collisions	Количество фреймов, которые были успешно переданы после одной коллизии. (Передано со второй попытки.)
Interface resets	Количество попыток сброса интерфейса. Обычно результат пропущенных keepalives.
Output buffer failures	Количество раз, когда пакет не выводился из очереди вывода из-за нехватки MEMD памяти.
Output buffers swapped out	Количество пакетов, хранящихся в основной памяти, когда очередь на выходе заполнена; Перестановка буферов в основную память предотвращает отбрасывание пакетов при переполнении выходного потока. Значение высоко, когда трафик замусорен.
Babbles	Количество переданных фреймов больше 1518 байт
Deferred	Количество кадров, которые были успешно переданы после их ожидания, поскольку носитель был занят.
Late collision	Коллизия, которая возникает после того, как интерфейс начал передавать свой фрейм
No carrier	Количество раз, когда пересылка пакетов не прошла во время передачи.
Lost carrier	Количество раз, когда пересылка была остановлена при передаче.

Более полную информацию Вы сможете просмотреть по следующим ссылкам:
Устранение неполадок на портах коммутатора

Добавить комментарий Отменить ответ

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

Источник

Input errors cisco что это

Выявил место проблемы по графикам observium: на внутреннем интерфейсе роутера начинают копиться input errors прямо пропорционально трафику через него, если начинают качать/отдавать под 60Мбит/с, то на внутреннем интерфейсе, идущего к пользователям лавинообразно растут input errors, делал debug ip error detail, не вижу ошибок на консоли. Если трафик 60-80Мбит/с, то применять SPAN тяжело, будет куча мусора. Может еще какие-то дебаги помогут?

В сети обычно говорят, что input errors чаще всего связаны с физическими проблемами в проводе, порту eth. Но я думаю это не тот случай.

> Выявил место проблемы по графикам observium: на внутреннем интерфейсе роутера начинают
> копиться input errors прямо пропорционально трафику через него, если начинают качать/отдавать
> под 60Мбит/с, то на внутреннем интерфейсе, идущего к пользователям лавинообразно растут
> input errors, делал debug ip error detail, не вижу ошибок на
> консоли. Если трафик 60-80Мбит/с, то применять SPAN тяжело, будет куча мусора.
> Может еще какие-то дебаги помогут?
> В сети обычно говорят, что input errors чаще всего связаны с физическими
> проблемами в проводе, порту eth. Но я думаю это не тот
> случай.

Должны быть где-то типы ошибок:
Runt? CRC? Collision? giant?

1. «Большое количество input errors на интерфейсе»	+ / –
Сообщение от fantom (??), 25-Июл-18, 11:05
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. «Большое количество input errors на интерфейсе»	+ / –
	Сообщение от cr1m2 (ok), 26-Июл-18, 09:13
	>[оверквотинг удален] >> копиться input errors прямо пропорционально трафику через него, если начинают качать/отдавать >> под 60Мбит/с, то на внутреннем интерфейсе, идущего к пользователям лавинообразно растут >> input errors, делал debug ip error detail, не вижу ошибок на >> консоли. Если трафик 60-80Мбит/с, то применять SPAN тяжело, будет куча мусора. >> Может еще какие-то дебаги помогут? >> В сети обычно говорят, что input errors чаще всего связаны с физическими >> проблемами в проводе, порту eth. Но я думаю это не тот >> случай. > Должны быть где-то типы ошибок: > Runt? CRC? Collision? giant? 5 minute input rate 739000 bits/sec, 230 packets/sec 5 minute output rate 1146000 bits/sec, 295 packets/sec 25930598 packets input, 2016324977 bytes, 0 no buffer Received 9106 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 3449 input errors, 0 CRC, 0 frame, 3449 overrun, 0 ignored 0 watchdog, 9069 multicast, 0 pause input 21973608 packets output, 3145839419 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

3. «Большое количество input errors на интерфейсе»

+ / –

Сообщение от cr1m2

(ok), 26-Июл-18, 09:41

> 3449 input errors, 0 CRC, 0 frame,
> 3449 overrun, 0 ignored
> 0 watchdog, 9069 multicast, 0 pause input

Я так понял, overrun-ошибки возникают при слишком большом кол-ве приходящих пакетов, которые роутер не смог занести в буфер. А вот как бы это побороть?

Может поможет доп.инфа: на этот внутренний интерфейс cisco 2921 подключен фаерволл asa5506, но на интерфейсе ASA ошибок нет.

И проверить саму медь (физику)

> Выявил место проблемы по графикам observium: на внутреннем интерфейсе роутера начинают
> копиться input errors прямо пропорционально трафику через него, если начинают качать/отдавать
> под 60Мбит/с, то на внутреннем интерфейсе, идущего к пользователям лавинообразно растут
> input errors, делал debug ip error detail, не вижу ошибок на
> консоли. Если трафик 60-80Мбит/с, то применять SPAN тяжело, будет куча мусора.
> Может еще какие-то дебаги помогут?
> В сети обычно говорят, что input errors чаще всего связаны с физическими
> проблемами в проводе, порту eth. Но я думаю это не тот
> случай.

Поиграйтесь с MTU (он же jumbe frame)//////

>> В сети обычно говорят, что input errors чаще всего связаны с физическими
>> проблемами в проводе, порту eth. Но я думаю это не тот
>> случай.
> Поиграйтесь с MTU (он же jumbe frame)//////

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

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

> Выявил место проблемы по графикам observium: на внутреннем интерфейсе роутера начинают
> копиться input errors прямо пропорционально трафику через него, если начинают качать/отдавать
> под 60Мбит/с, то на внутреннем интерфейсе, идущего к пользователям лавинообразно растут
> input errors, делал debug ip error detail, не вижу ошибок на
> консоли. Если трафик 60-80Мбит/с, то применять SPAN тяжело, будет куча мусора.
> Может еще какие-то дебаги помогут?
> В сети обычно говорят, что input errors чаще всего связаны с физическими
> проблемами в проводе, порту eth. Но я думаю это не тот
> случай.

Источник

Поддержка

Категория: Сеть

В данной статье производится описание порядка диагностики и поиска ошибок на портах коммутатора.
В примере используется коммутатор Cisco Catalyst C4948

Следующим шагом мы переходим в привилегированный режим редактирования конфигурации Enable (en).

Следующей командой мы можем посмотреть счетчики ошибок по всем портам коммутатора:

или по одному порту gi1/33

Приведем описание наиболее важных счетчиков

Счетчик	Описание	Возможная причина
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

Далее проверяем, включено ли обнаружение отключения из-за ошибки на порту коммутатора:

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

Смотрим порты которые находятся в состоянии ошибки errdisable (порт
автоматически отключен операционной системой коммутатора, так как порт
обнаружен в состоянии ошибки):

Просмотр подробной информации о настройках и состоянии порта коммутатора:

Как видно из вывода команды, ошибок на порте коммутатора не обнаружено.

Также, набрав следующую команду, можно посмотреть статус и используемые протоколы на портах коммутатора:

Источник

Input errors cisco что это

Понимаю, что по данному вопросу достаточно пишут на форумах, все же решил спросить.

Значит имеется 2821, через которую порядка 80 VoIP телефонов с «серыми» IP адресами регистрируются по SIP посредством NAT (PAT) оператора VoIP. При увеличении телефонной нагрузки начинают увеличиваться счетчики input errors и ignored errors на обоих интерфейсах. Наблюдается прерывистая речь. Вывод команды show buffers показывает увеличение счетчика failures в Middle buffers:

GigabitEthernet0/1 is up, line protocol is up

Hardware is MV96340 Ethernet, address is 0017.95bc.8999 (bia 0017.95bc.8999)

Internet address is

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, media type is T

output flow-control is XON, input flow-control is XON

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of «show interface» counters 01:01:40

Input queue: 0/500/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

30 second input rate 353000 bits/sec, 175 packets/sec

30 second output rate 352000 bits/sec, 151 packets/sec

219946 packets input, 54046444 bytes, 0 no buffer

Received 573 broadcasts, 0 runts, 0 giants, 0 throttles

43 input errors, 0 CRC, 0 frame, 0 overrun, 43 ignored

0 watchdog, 0 multicast, 0 pause input

0 input packets with dribble condition detected

177747 packets output, 54034239 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 86 pause output

0 output buffer failures, 0 output buffers swapped out

Middle buffers, 600 bytes (total 251, permanent 210, peak 626 @ 04:00:05):

248 in free list (180 min, 250 max allowed)

8299846 hits, 275239 misses, 69992 trims, 70033 created

39674 failures (0 no memory)

ip access-group ge0/1-in in

no ip unreachables

ip nbar protocol-discovery

ip route-cache flow

Роутер был выделен исключительно под голосовой трафик. ACL ge0/1-in запрещает все, кроме voip.

Загрузку CPU имеет смсыл смотреть в момент когда проявляется проблема командами:

sh proc cpu history

sh proc cpu sorted 5sec

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

Потери на интерфейсах могут быть вызваны тем, что CPU не успевает обрабатывать пакеты.

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

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

NAT у циски достаточно прожорливый, а 2821 железка слабенькая.

Я конечно сомневаюсь, что бы 80 фонов своим трафиком забили ресурсы CPU по NAT, но возможно вы всё же чего-то не договариваете и там может присутствовать и другой трафик, а в таком случае проблемы с CPU выглядят вполне реально.

P.S. Да, а у вас ширины канала-то до провайдера хватает?

А канал между вами и провайдером VOIP случайно не «интернет»?

Может у вас просто полосы не хватает и провайдер режет излишки вашего трафика?

Источник

Читайте также: цсп панели что это такое