Cisco 7604 + RSP720 3CXL + WS-X6704-10GE растут ошибки на порту,

[allan_sundry]

Доброе время суток!

 

Есть Cisco 7604 + RSP720 3CXL + WS-X6704-10GE на которой затерминированы клиенты + настроен полисинг для ограничения скорости клиентов в рамках тарифа.

Заметил что почему-то на порту активно растут ошибки:

#sh interfaces Te3/4
TenGigabitEthernet3/4 is up, line protocol is up (connected)
 Hardware is C7600 10Gb 802.3, address is 588d.09b4.8d80 (bia 588d.09b4.8d80)
 MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
    reliability 255/255, txload 42/255, rxload 42/255
 Encapsulation 802.1Q Virtual LAN, Vlan ID  1., loopback not set
 Keepalive set (10 sec)
 Full-duplex, 10Gb/s
 Transport mode LAN (10GBASE-R, 10.3125Gb/s)
 input flow-control is off, output flow-control is off
 Clock mode is auto
 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 3d03h
 Input queue: 0/75/291/291 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue: 0/40 (size/max)
 5 minute input rate 1667291000 bits/sec, 244099 packets/sec
 5 minute output rate 1665910000 bits/sec, 243961 packets/sec
 L2 Switched: ucast: 4875 pkt, 1667250 bytes - mcast: 0 pkt, 0 bytes
 L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
 L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
    46982598919 packets input, 40800999530943 bytes, 0 no buffer
    Received 1748682 broadcasts (0 IP multicasts)
    0 runts, 0 giants, 0 throttles
    155706 input errors, 65000 CRC, 11401 frame, 0 overrun, 0 ignored
    0 watchdog, 0 multicast, 0 pause input
    0 input packets with dribble condition detected
    46985469520 packets output, 40792363160570 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

при этом потерь пакетов через порт нет.

 

Пиковая загрузка порта: 2,3Gbps при 313kpps.

 

Где искать источник роста счетчиков?!

[sexst]

155706 input errors, 65000 CRC это за сколько времени? Как проверяли что потерь нет?

Если при таком трафике это набежало за пару часов и более, то вы и не заметите потерь.

[allan_sundry]

155706 input errors, 65000 CRC это за сколько времени? Как проверяли что потерь нет?

Если при таком трафике это набежало за пару часов и более, то вы и не заметите потерь.

 

 Last clearing of "show interface" counters 3d03h

собственно за 3 дня и 3 часа :)

 

Проверял банальным ping - 10000 пакетов несколько раз с 76-й до соседнего роутера.

За время пока шел ping счетчики подросли, но ошибок не было.

Тест проводил пару раз подряд.

[shvlad1]

париться имхо надо при проценте и более

вашим 155706/46982598919 можно пока пренебречь

[darkagent]

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

Рекомендации на текущий момент - для профилактики протереть патчкорды.

[allan_sundry]

париться имхо надо при проценте и более

вашим 155706/46982598919 можно пока пренебречь

В данной ситуации интересно найти прияну, а потом уже пренебречь...

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

Рекомендации на текущий момент - для профилактики протереть патчкорды.

Какое значение счетчика является критическим приводящим к падению интерфейса?

[necrozz]

париться имхо надо при проценте и более

вашим 155706/46982598919 можно пока пренебречь

В данной ситуации интересно найти прияну, а потом уже пренебречь...

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

Рекомендации на текущий момент - для профилактики протереть патчкорды.

Какое значение счетчика является критическим приводящим к падению интерфейса?

Ну тогда начать с банальщины:

sh int Te3/4 tra det

[allan_sundry]

париться имхо надо при проценте и более

вашим 155706/46982598919 можно пока пренебречь

В данной ситуации интересно найти прияну, а потом уже пренебречь...

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

Рекомендации на текущий момент - для профилактики протереть патчкорды.

Какое значение счетчика является критическим приводящим к падению интерфейса?

Ну тогда начать с банальщины:

sh int Te3/4 tra det

 

#sh int te3/4 transceiver detail
ITU Channel not available (Wavelength not available),
Transceiver is internally calibrated.
mA: milliamperes, dBm: decibels (milliwatts), NA or N/A: not applicable.
++ : high alarm, +  : high warning, -  : low warning, -- : low alarm.
A2D readouts (if they differ), are reported in parentheses.
The threshold values are calibrated.

                             High Alarm  High Warn  Low Warn   Low Alarm
          Temperature        Threshold   Threshold  Threshold  Threshold
Port       (Celsius)          (Celsius)   (Celsius)  (Celsius)  (Celsius)
---------  -----------------  ----------  ---------  ---------  ---------
Te3/4        28.2                   70.0       60.0        5.0        0.0

                             High Alarm  High Warn  Low Warn   Low Alarm
          Voltage            Threshold   Threshold  Threshold  Threshold
Port       (Volts)            (Volts)     (Volts)    (Volts)    (Volts)
---------  -----------------  ----------  ---------  ---------  ---------
Te3/4        0.00                    N/A        N/A        N/A        N/A

                             High Alarm  High Warn  Low Warn   Low Alarm
          Current            Threshold   Threshold  Threshold  Threshold
Port       (milliamperes)     (mA)        (mA)       (mA)       (mA)
---------  -----------------  ----------  ---------  ---------  ---------
Te3/4         N/A                    N/A        N/A        N/A        N/A

          Optical            High Alarm  High Warn  Low Warn   Low Alarm
          Transmit Power     Threshold   Threshold  Threshold  Threshold
Port       (dBm)              (dBm)       (dBm)      (dBm)      (dBm)
---------  -----------------  ----------  ---------  ---------  ---------
Te3/4         N/A         ++         0.9        0.4       -8.2       -8.1

          Optical            High Alarm  High Warn  Low Warn   Low Alarm
          Receive Power      Threshold   Threshold  Threshold  Threshold
Port       (dBm)              (dBm)       (dBm)      (dBm)      (dBm)
---------  -----------------  ----------  ---------  ---------  ---------
Te3/4         N/A         ++         0.9        0.4      -14.4      -15.0

 

Для коммутации используется переходник XENPACK to SFP+ и DirectAttach кабель SFP+ to SFP+.

[necrozz]

париться имхо надо при проценте и более

вашим 155706/46982598919 можно пока пренебречь

В данной ситуации интересно найти прияну, а потом уже пренебречь...

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

Рекомендации на текущий момент - для профилактики протереть патчкорды.

Какое значение счетчика является критическим приводящим к падению интерфейса?

Ну тогда начать с банальщины:

sh int Te3/4 tra det

 

Для коммутации используется переходник XENPACK to SFP+ и DirectAttach кабель SFP+ to SFP+.

Пардон, при вашей схеме включени мой вопрос не имеет смысла ) Из практики использования переходников XENPACK->SFP+, X2->SFP+ периодически возникали косяки именно в работе самого переходника, по крайней мере его замена проблему решала. Проблемы были именно такого же плана - при нормальных данных диагностики тонны input error's на порту. Проблемы возникали на всех переходниках которые мы использовали (SNR,Upnet,Opticin)

[mcdemon]

я обычно тестирую так:

беру программу Ping Tester (Windows)

 

выставляю размер пакета 32000, интервал отправки 1мс, и кол-во пакетов сколько угодно

если пинг до узла 1мс, то 1000 пингов пройдет за несколько сек

 

очень хороший тест я считаю)

я так проверяю старые медиаконвертеры, соединяю пару конвертеров оптикой, одну медь в комп другую в коммутатор

и пингую с удаленного сервера свой компьютер, если есть хоть 1 потеря на 8000 например, то проверяю патчкорды и пробую еще раз, при повторе потерь, отдаю конвертеры на ремонт

 

и абонентов на потери также проверяю

 

п.с. с линукса и без доп. программ можно выставить интервал отправки пакетов в 0.01 например) но там статистика неудобная, её можно смотреть только после остановки пинга

а через прогу в реальном времени показывает сколько потеряно в количестве и процентах

Edited August 6, 2013 by mcdemon

[allan_sundry]

я обычно тестирую так:

беру программу Ping Tester (Windows)

 

выставляю размер пакета 32000, интервал отправки 1мс, и кол-во пакетов сколько угодно

если пинг до узла 1мс, то 1000 пингов пройдет за несколько сек

 

очень хороший тест я считаю)

я так проверяю старые медиаконвертеры, соединяю пару конвертеров оптикой, одну медь в комп другую в коммутатор

и пингую с удаленного сервера свой компьютер, если есть хоть 1 потеря на 8000 например, то проверяю патчкорды и пробую еще раз, при повторе потерь, отдаю конвертеры на ремонт

 

и абонентов на потери также проверяю

 

п.с. с линукса и без доп. программ можно выставить интервал отправки пакетов в 0.01 например) но там статистика неудобная, её можно смотреть только после остановки пинга

а через прогу в реальном времени показывает сколько потеряно в количестве и процентах

 

Откройте для себя mtr (My traceroute)