Unknown protocol drops cisco как найти причину
Здравствуйте! Наткнулся на проблему большой нагрузки на Cisco 7604:
Router#sh proc cpu hist
1
999999989744334434333434355554505544444777322345326333533783334243634442
939999989211955575299863760195302177089170764149064914065993130521611319
100 * ***** * *
90 #######** * *
80 #######** * * **
70 #######*** * *** ** *
60 #######*** * * * *** * * ** *
50 #######*** ** * * *********** ***** * * * ** *
40 #######*********** ************************ ** ** ***** * * * **
30 #######************************************* *************************
20 ###########**##*********################**********######**************
10 ######################################################################
0. 5. 1. 1. 2. 2. 3. 3. 4. 4. 5. 5. 6. 6. 7..
0 5 0 5 0 5 0 5 0 5 0 5 0
CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU% Router#sh proc cpu sorted | exc 0.00%
CPU utilization for five seconds: 90%/83%; one minute: 88%; five minutes: 88%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
9 18828736 1042621 18059 2.07% 0.66% 0.66% 0 Check heaps
171 13168652 672293 19587 0.55% 0.37% 0.37% 0 Compute load avg
237 31988840 118522036 269 0.47% 0.65% 0.63% 0 IP Input
14 5533876 7936828 697 0.47% 0.21% 0.19% 0 ARP Input
619 3139112 6594197 476 0.47% 0.15% 0.14% 0 RADIUS
615 2878684 87341282 32 0.39% 0.27% 0.25% 0 PPP Events
277 283256 328541665 0 0.39% 0.07% 0.06% 0 Ethernet Msec Ti
324 4085968 1953534 2091 0.31% 0.15% 0.14% 0 XDR receive
432 4490952 1313388 3419 0.31% 0.16% 0.17% 0 HIDDEN VLAN Proc
225 529108 2516097 210 0.31% 0.13% 0.14% 0 ACCT Periodic Pr
348 1955068 4070269 480 0.23% 0.22% 0.21% 0 CEF: IPv4 proces
621 899328 74154842 12 0.15% 0.11% 0.09% 0 OSPF-1 Hello
2 607728 525326 1156 0.07% 0.05% 0.05% 0 Load Meter
247 1348816 6415634 210 0.07% 0.03% 0.05% 0 SSM connection m
173 116032 2631628 44 0.07% 0.07% 0.06% 0 Per-Second Jobs
372 630160 264884 2379 0.07% 0.04% 0.05% 0 QoS stats proces
321 669832 3373091 198 0.07% 0.07% 0.09% 0 XDR mcast
251 3124320 3112933 1003 0.07% 0.12% 0.14% 0 SSS Manager хотя по процессам так и не скажешь почему. Подскажите на что можно обратить внимание по решению этой проблеме, debug не охота запускать, так как есть большая вероятность потерять железку, хотя на что запускать debug непонятно. Сразу скажу, что в цысках не силён, буду рад любой помощи.
| Оглавление |
- Большая нагрузка на Cisco 7604 без видимых причин, fantom, 11:10 , 31-Янв-15, (1)
- Большая нагрузка на Cisco 7604 без видимых причин, fantom, 11:10 , 31-Янв-15, (2)
- Большая нагрузка на Cisco 7604 без видимых причин, sanmiron, 12:26 , 31-Янв-15, (3)
- Большая нагрузка на Cisco 7604 без видимых причин, fantom, 12:31 , 31-Янв-15, (4)
- Большая нагрузка на Cisco 7604 без видимых причин, Йогурт, 10:46 , 02-Фев-15, (5)
- Большая нагрузка на Cisco 7604 без видимых причин, fantom, 10:49 , 02-Фев-15, (6)
- Большая нагрузка на Cisco 7604 без видимых причин, Йогурт, 12:29 , 03-Фев-15, ( 8 )
- Большая нагрузка на Cisco 7604 без видимых причин, Уава, 12:32 , 03-Фев-15, ( 9 )
- Большая нагрузка на Cisco 7604 без видимых причин, sanmiron, 18:19 , 12-Фев-15, ( 10 )
Сообщения по теме [Сортировка по времени | RSS] >[оверквотинг удален]
> 3373091 198 0.07%
> 0.07% 0.09% 0 XDR mcast
> 251 3124320 3112933
> 1003 0.07% 0.12%
> 0.14% 0 SSS Manager
> хотя по процессам так и не скажешь почему. Подскажите на что можно
> обратить внимание по решению этой проблеме, debug не охота запускать, так
> как есть большая вероятность потерять железку, хотя на что запускать debug
> непонятно. Сразу скажу, что в цысках не силён, буду рад любой
> помощи.для начала посмотреть аномалии на интерфейсах — бродкасты, ошибки и т.д.
>[оверквотинг удален]
>> 0.07% 0.09% 0 XDR mcast
>> 251 3124320 3112933
>> 1003 0.07% 0.12%
>> 0.14% 0 SSS Manager
>> хотя по процессам так и не скажешь почему. Подскажите на что можно
>> обратить внимание по решению этой проблеме, debug не охота запускать, так
>> как есть большая вероятность потерять железку, хотя на что запускать debug
>> непонятно. Сразу скажу, что в цысках не силён, буду рад любой
>> помощи.
> для начала посмотреть аномалии на интерфейсах — бродкасты, ошибки и т.д.И в логи заглянуть не грех.
>[оверквотинг удален]
>>> 251 3124320 3112933
>>> 1003 0.07% 0.12%
>>> 0.14% 0 SSS Manager
>>> хотя по процессам так и не скажешь почему. Подскажите на что можно
>>> обратить внимание по решению этой проблеме, debug не охота запускать, так
>>> как есть большая вероятность потерять железку, хотя на что запускать debug
>>> непонятно. Сразу скажу, что в цысках не силён, буду рад любой
>>> помощи.
>> для начала посмотреть аномалии на интерфейсах — бродкасты, ошибки и т.д.
> И в логи заглянуть не грех.Router#sh int gigabitEthernet 3/0/0
GigabitEthernet3/0/0 is up, line protocol is up
Hardware is GigEther SPA, address is 0026.cb39.d7c0 (bia 0026.cb39.d7c0)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 67/255, rxload 18/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive not supported
Full Duplex, 1000Mbps, link type is force-up, media type is unknown media type
output flow-control is unsupported, input flow-control is unsupported
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 never
Input queue: 0/75/37948190/0 (size/max/drops/flushes); Total output drops: 544704321
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 72471000 bits/sec, 20781 packets/sec
5 minute output rate 262841000 bits/sec, 29258 packets/sec
34270937362 packets input, 17220354078031 bytes, 0 no buffer
Received 135947101 broadcasts (0 IP multicasts)
0 runts, 3220 giants, 0 throttles
149347 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 150238020 multicast, 0 pause input
42474749030 packets output, 44742702952626 bytes, 0 underruns
0 output errors, 0 collisions, 12 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 outRouter#sh int tenGigabitEthernet 1/1
TenGigabitEthernet1/1 is up, line protocol is up (connected)
Hardware is C6k 10000Mb 802.3, address is 0026.cb39.d7c0 (bia 0026.cb39.d7c0)
Internet address is х.х.х.х/х
MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 6/255
Encapsulation ARPA, 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 never
Input queue: 2/75/87394/86031 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 265477000 bits/sec, 35942 packets/sec
5 minute output rate 73383000 bits/sec, 27046 packets/sec
L2 Switched: ucast: 20050797 pkt, 23272261965 bytes — mcast: 21489536 pkt, 3094633663 bytes
L3 in Switched: ucast: 42597592453 pkt, 44919843787845 bytes — mcast: 0 pkt, 0 bytes mcast
L3 out Switched: ucast: 31791715209 pkt, 14977654751458 bytes mcast: 0 pkt, 0 bytes
58253166209 packets input, 46269368606400 bytes, 0 no buffer
Received 23090392 broadcasts (0 IP multicasts)
0 runts, 0 giants, 71 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
47383843896 packets output, 16354214092902 bytes, 0 underruns
0 output errors, 0 collisions, 2 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На Giga3/0/0 наблюдаются input errors, разве оно могло так влиять? Кстати нагрузка продолжалась около 12 часов, потом упала до 17%, видимо какой то pppoe клиент такое делал. и как такого хомяка найти в следующий раз.
>[оверквотинг удален]
> 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
> На Giga3/0/0 наблюдаются input errors, разве оно могло так влиять? Кстати нагрузка
> продолжалась около 12 часов, потом упала до 17%, видимо какой то
> pppoe клиент такое делал. и как такого хомяка найти в следующий раз.Настраивайте статистику, следите за динамикой. ошибки/мультикасты/бродкасты набежали за час или за сутки тут невидно!
>[оверквотинг удален]
>> 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
>> На Giga3/0/0 наблюдаются input errors, разве оно могло так влиять? Кстати нагрузка
>> продолжалась около 12 часов, потом упала до 17%, видимо какой то
>> pppoe клиент такое делал. и как такого хомяка найти в следующий раз.
> Настраивайте статистику, следите за динамикой. ошибки/мультикасты/бродкасты набежали
> за час или за сутки тут невидно!ЭТО НОРМА!
Чо ты хочешь от софтовой железки? Её нат да и тупо большой pps убивают только впуть.>[оверквотинг удален]
>>> 0 output buffer failures, 0 output buffers
>>> swapped out
>>> На Giga3/0/0 наблюдаются input errors, разве оно могло так влиять? Кстати нагрузка
>>> продолжалась около 12 часов, потом упала до 17%, видимо какой то
>>> pppoe клиент такое делал. и как такого хомяка найти в следующий раз.
>> Настраивайте статистику, следите за динамикой. ошибки/мультикасты/бродкасты набежали
>> за час или за сутки тут невидно!
> ЭТО НОРМА!
> Чо ты хочешь от софтовой железки? Её нат да и тупо большой
> pps убивают только впуть.Может я чего недопонял. 76-я кошка вроде не софтовая. не- софт там безусловно Эсть, но вот траф должна молотить в «железе» и если обработка «вдруг» вылетает в софт — то надыть причины искать такового поведения.
> Здравствуйте! Наткнулся на проблему большой нагрузки на Cisco 7604:
> Router#sh proc cpu histВаш «сферический конь в вакууме» какой супервизор имеет?
Какие сервисы поддерживает этот супервизор в настоящий момент?
Конфиг? Версия IOS? Логи?> for five seconds: 90%/83%;
90% общая загрузка. 83% — прерывания ЦПУ. «Дергать» ЦПУ может любой поцесс.
>> Здравствуйте! Наткнулся на проблему большой нагрузки на Cisco 7604:
>> Router#sh proc cpu hist
> Ваш «сферический конь в вакууме» какой супервизор имеет?
> Какие сервисы поддерживает этот супервизор в настоящий момент?
> Конфиг? Версия IOS? Логи?
>> for five seconds: 90%/83%;
> 90% общая загрузка. 83% — прерывания ЦПУ. «Дергать» ЦПУ может любой поцесс.The x% represents total CPU utilization, and y% represents the CPU that is spent at the interrupt level.
короче у вас трафик попадает на cpu, это может быть arp и еще что-то, на что процессор отвечает.
>> Здравствуйте! Наткнулся на проблему большой нагрузки на Cisco 7604:
>> Router#sh proc cpu hist
> Ваш «сферический конь в вакууме» какой супервизор имеет?
> Какие сервисы поддерживает этот супервизор в настоящий момент?
> Конфиг? Версия IOS? Логи?
>> for five seconds: 90%/83%;
> 90% общая загрузка. 83% — прерывания ЦПУ. «Дергать» ЦПУ может любой поцесс.The x% represents total CPU utilization, and y% represents the CPU that is spent at the interrupt level.
короче у вас трафик попадает на cpu, это может быть arp и еще что-то, на что процессор отвечает.
>[оверквотинг удален]
>>> Router#sh proc cpu hist
>> Ваш «сферический конь в вакууме» какой супервизор имеет?
>> Какие сервисы поддерживает этот супервизор в настоящий момент?
>> Конфиг? Версия IOS? Логи?
>>> for five seconds: 90%/83%;
>> 90% общая загрузка. 83% — прерывания ЦПУ. «Дергать» ЦПУ может любой поцесс.
> The x% represents total CPU utilization, and y% represents the CPU that
> is spent at the interrupt level.
> короче у вас трафик попадает на cpu, это может быть arp и
> еще что-то, на что процессор отвечает.Решили проблему другим способом, в тот момент когда cpu подскочило, залезли на сервер радиуса и в phpmyadmin сделали выборку по подключенным клиентам в это же время. и нашли этого хомяка. Довольно таки простой способ получился)
Cisco2911 постоянно перезагружается (до 3-х раз за час). В чем может быть причина?
Здравствуйте. Имеется проблема с Cisco2911, начала сама перезагружаться. На ней поднято dmvpn с 2-мя провайдерами(один резервный).При отключении основного провайдера в ручную, циска начинает работать нормально(на резервном). Crashinfo создаются. Может кто сталкивался с такой проблемой?
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.4(3)M3, RELEASE SOFTWARE (fc2)
Technical Support: www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Fri 05-Jun-15 13:24 by prod_rel_teamROM: System Bootstrap, Version 15.0(1r)M16, RELEASE SOFTWARE (fc1)
Kremenki uptime is 10 minutes
System returned to ROM by error — a Software forced crash, PC 0x30EE9F68 at 13:56:12 Moscow Thu Nov 9 2023
System image file is «flash0:c2900-universalk9-mz.SPA.154-3.M3.bin»
Last reload type: Normal Reload
Last reload reason: error — a Software forced crash, PC 0x30EE9F68Отрывок из Краша:
current memory block, bp = 0x241B9A50,
memorypool type is Processor
data check, ptr = 0x241B9A80next memory block, bp = 0x241C2810,
memorypool type is Processor
data check, ptr = 0x241C2840previous memory block, bp = 0x24179A24,
memorypool type is Processor
data check, ptr = 0x24179A54- Вопрос задан 09 нояб. 2023
- 240 просмотров
Комментировать
Решения вопроса 0
Ответы на вопрос 2
Daemon23RUS @Daemon23RUS
А случаем не черезмерная входящая сетевая активность (ddos) на основном повайдере крашит ?
Было несколько лет назад что то подобное, но и циска другая была. Это как вектор поиска. Сами долго голову ломали пока случайно (смена стороны в договоре с провайдером) внешний IP не сменилсяОтвет написан 10 нояб. 2023
Комментировать
Нравится 1 Комментировать
Михаил @Bard099 Автор вопросавот что по загрузке порта где основной провайдер:
GigabitEthernet0/0 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is cc46.d64d.6ab8 (bia cc46.d64d.6ab8)
Description: ===provider===
Internet address is x.x.x.x
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 7/255, rxload 8/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 100Mbps, media type is RJ45
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 never
Input queue: 2/75/2/370 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 3289000 bits/sec, 856 packets/sec
5 minute output rate 3056000 bits/sec, 867 packets/sec
435354 packets input, 209457185 bytes, 0 no buffer
Received 88 broadcasts (0 IP multicasts)
0 runts, 0 giants, 2 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 12 multicast, 0 pause input
441530 packets output, 205024329 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
12 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Что может быть причиной возникновения lost carrier?
Столкнулся с такой проблемой, в неопределённые интервалы времени возникает ошибка lost carrier:
1921-grt01-nya#sh int gig 0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is 84b8.0239.99a0 (bia 84b8.0239.99a0)
Description: pp21-p1
Internet address is x.x.x.x/30
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 100Mbps, media type is RJ45
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:14, output 00:00:00, output hang never
Last clearing of «show interface» counters 4d19h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 26
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 135000 bits/sec, 15 packets/sec
5 minute output rate 8000 bits/sec, 11 packets/sec
5707773 packets input, 3204418960 bytes, 0 no buffer
Received 10201 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
78 input errors, 12 CRC, 27 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
3805486 packets output, 384755047 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
7 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped outЭто данные за три дня, причём input errors, CRC и frame, не увеличиваются постоянно, они возникли при одном из lost carrier event, но больше не растут. Сами lost carrier ошибки возникают без какого-либо объяснимого события.
Схема подключения до коммутатора ISP выглядит следующим образом: edge router -> patch panel main cross -> patch panel inductory cross -> lightning protection -> ISP switch.
Само собой кабель проверен, по крайней мере базовым тестером, к сожалению такого, чтобы мог замерить характеристики прохождения сигнала в кабеле нет.
Switch ISP находится в необогреваемом шкафу, морозы у нас до -35, корреляции температуры и количества возникающих ошибок, пока установить не удалось, на первый взгляд их количество увеличивается при достижение температуры ниже -15, но мало вводных данных.
Есть подозрение на возможное влияние пассивной грозозащиты на возникновение данной ошибки, запланировано мероприятие по её временному обходу, для исключения этого фактора.
Что ещё можно предпринять, до полного пере монтажа всего кабельного тракта?
Любые советы и тем более собственный опыт борьбы с lost carrier, приветствуется.
Не могу найти, есть ли у CISCO debug для таких events, чтобы можно было более детально увидеть, что происходит при этом lost carrier error event?
U.P.D. Вопрос закрыт.
Виною был и есть, коммутатор фирмы D-Link, как оказалось, у ISP нашлась ещё куча тикетов с той же самой проблемой, lost carrier, все они решались переходом в no negotiation.
Грозозащита, FTP кабеля, низкие температуры, всё это было не при чём, D-Link, знает, что-то о стандартах, чего не знают другие компании.
- Вопрос задан более трёх лет назад
- 10171 просмотр
Interface — unknown protocol drops
In the output of the show interfaces command for a particular interface, there is a counter called unkonwn protocol drops as shown below:
R1#show interfaces FastEthernet 0/0 FastEthernet0/0 is up, line protocol is up Hardware is Gt96k FE, address is c201.1d00.0000 (bia c201.1d00.0000) MTU 1500 bytes, BW 100000 Kbit/sec, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:02, output hang never Last clearing of "show interface" counters never Input queue: 0/75/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 0 packets input, 0 bytes Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog 0 input packets with dribble condition detected 2 packets output, 403 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped outThe unknown protocol drops counter refers to the number of packets that were discarded because the router could not identify or process the protocol encapsulated in the packet. Essentially, the Layer 3 protocol used is unidentified or unsupported by the router, so the packet is dropped.
These drops can occur for various reasons, such as:
- The packet header is corrupted, making it impossible for the router to determine the encapsulated protocol.
- The router is not configured to handle the specific protocol encapsulated in the packet.
- The encapsulated protocol is obsolete or not widely used, so the router does not recognize it.
When a Cisco router receives a packet, it checks the EtherType field in the Layer 2 (Data Link layer) header to determine the encapsulated Layer 3 protocol (such as IPv4, IPv6, or others). If the EtherType field value does not correspond to a known or supported Layer 3 protocol, the router will consider it an unknown protocol and drop the packet.
If you are consistently seeing a high number of unknown protocol drops, it could indicate a network issue, such as misconfigured devices, or faulty hardware or cabling.
Links to this page:
- Большая нагрузка на Cisco 7604 без видимых причин, Йогурт, 10:46 , 02-Фев-15, (5)
- Большая нагрузка на Cisco 7604 без видимых причин, fantom, 12:31 , 31-Янв-15, (4)
- Большая нагрузка на Cisco 7604 без видимых причин, sanmiron, 12:26 , 31-Янв-15, (3)
- Большая нагрузка на Cisco 7604 без видимых причин, fantom, 11:10 , 31-Янв-15, (2)