pod

нет, самые обычные, без UPS ок, как следующая проблема случится - соберу

собирал, и трафик дампил с разных сторон. со свича dhcp запросы не уходят(все 1 в 1 как на 2990) 48-5b-39-95-fd-f8 - мак тестового клиента в 1м порту, 9й порт - аплинк в сторону ядра сети [tNACTask]:DHCPS: rcv packet from client 48-5b-39-95-fd-f8, interface Ethernet1/0/1(portID 0x1000001), length 363, type DHCPDISCOVER, opcode BOOTREQUEST, stacking 0 [tNACTask]:DHCPS: flood dhcp pkt from Ethernet1/0/1 dst mac ff-ff-ff-ff-ff-ff to all up port except input port Ethernet1/0/1 in vlan 18 [tNACTask]:DHCPS: do binding info from client 48-5b-39-95-fd-f8, interface Ethernet1/0/1, type DHCPDISCOVER, flag 0 [tNACTask]:DHCPS: rcv packet from client bc-ee-7b-65-96-c9, interface Ethernet1/0/9(portID 0x1000009), length 362, type DHCPDISCOVER, opcode BOOTREQUEST, stacking 0 [tNACTask]:DHCPS: flood dhcp pkt from Ethernet1/0/9 dst mac ff-ff-ff-ff-ff-ff to all up port except input port Ethernet1/0/9 in vlan 13 [tNACTask]:DHCPS: do binding info from client bc-ee-7b-65-96-c9, interface Ethernet1/0/9, type DHCPDISCOVER, flag 8 [tNACTask]:DHCPS: parse packet from client bc-ee-7b-65-96-c9, failed interface Ethernet1/0/9(portID 0x1000009), length 357, type DHCPOFFER, opcode BOOTREPLY, stacking 0 Invalid DHCP Server from Ethernet1/0/9

@Ivan Tarasenko эта проблема встречалась и на 2990. Через рандомный промежуток времени после перезагрузки(от нескольких часов до недель) клиенты, включенные в 2985 или свичи за 2985 перестают получать IP адреса. Если убрать из конфига "ip dhcp snooping enable" то все сразу нормализуется, но в dhcp запросе перестает приходить опция82(что логично :)) Кроме того, в момент существования проблемы таблица биндингов "sh ip dhcp snooping binding all" пустая

Здравствуйте! Подскажите, ПО SNR-S2985G-48T(24T_8T)(POE)(UPS)(RPS)_7.0.3.5(R0241.0311) содержит в себе исправление ошибки FIX|MT8441 skb leaking caused by dhcp packets with option82(из ченжлога ПО для 2990G) ? Т.к на 2985-8Т на версии R0241.0305 наблюдаю периодические проблемы с выдачей IP адресов при включенном ip dhcp snooping

в данном случае на #sh ver SNR-S2990G-24T Device, Compiled on Mar 07 15:44:32 2019 SoftWare Version 7.0.3.5(R0102.0295) но по-идее это некий общий атрибут для всех свичей одного вендора...

Здравствуйте! Возможно ли в ответе от radius сервера указать уровень привилегий пользователя? С настройками из мануала ($RAD_REPLY{'Service-Type'} = "Administrative-User";) сразу пускает с "Current privilege level is 15".

да, работает, но с сторонними онушками не дружит... #show card Rack Shelf Slot CfgType RealType Port HardVer SoftVer Status ------------------------------------------------------------------------------- 1 1 2 ETGH ETGHK 16 151202 V1.2.5P3 INSERVICE 1 1 3 PRAM PRAM 3 V1.01 INSERVICE 1 1 4 SMXA SMXA 3 131201 V1.2.5P3 INSERVICE

Интересует информация о совместимости ONU МГТС(Sercomm) rv6688 и головы ZTE c320. Столкнулся с тем, что онушка регается на голове, пару секунд через даже ходят пинги, и потом отваливается OMCI: 2634223.35s olt:7 ont:1 Mib upload finished, success! syncReason:2.1-period,2-reEst,3-start Mib sync result report type:0.0-omccReady,1-no report,2-mibDataSync not equal for omccReady,3-mibDataSync not equal for RestoreAPI ZTE debug-log:MAC: 2634228.07s olt:7 onu:1(1) MUX DEACTIVE ONU return value:0 task:tXponNpPlCtrl

hwpmc использовать не получилось, в 8.2 он был слишком старый и не работал с установленным процом. Обновился до 10.2, нагружающие проц {igb1 que} из топа пропали, хотя максимальный LA так и остался выше 4. Виновником оказался dummynet, который в top хоть и показывал 0% нагрузки, но по факту нагружал 30% system на одном из ядер. Решением оказалась установка net.inet.ip.dummynet.expire=0 Это снизило нагрузку system, которую создавал dummynet, в 2-2.5 раз и LA в пике теперь до 3.75.

Со ссылками ознакомлен. По ним, и не только, ответа на основной вопрос - Что вообще обрабатывается в процессах {igb1 que}? Какой трафик попадает туда а не в {irqххх: igb1:que}? нету. Вообще в найденных темах ни у кого нагрузки такого вида не вылазит.

приведеные данные именно с порта коммутатора, в который включена igb1

Обновить пора, согласен. Но ведь такая аномалия в нагрузке появляется не всегда, значит дело не в версии ОС. Значимого количества мультикаста от абонов нет, один пакет в пару секунд не в счет, вот статистика на порту из сети на igb1 в сторону этого сервера Output packets statistics: 14147591214 output packets, 5726773091420 bytes, 0 underruns 1262240916 unicast packets, 146773 multicast packets, 301637 broadcast packets Что вообще обрабатывается в процессах {igb1 que}? Какой трафик попадает туда а не в {irqххх: igb1:que}?

Здравствуйте! Есть бордер (ipfw NAT, dummynet шейпер) вот такого вида i5-4460 CPU @ 3.20GHz 4Gb RAM Freebsd 8.2 Intel(R) PRO/1000 Network Connection version - 2.2.3 - igb Применен стандартный тюнинг loader.conf sysctl.conf для igb На нем подсети для абонентов натятся в пул из 48 белых ip. Большую часть времени по нагрузке все нормально, но иногда, в часы пик, вылазит вот такое 0 root -68 0 0K 240K - 2 72.2H 36.23% {igb1 que} 0 root -68 0 0K 240K - 1 73.2H 35.35% {igb1 que} 0 root -68 0 0K 240K - 3 71.6H 33.59% {igb1 que} 0 root -68 0 0K 240K - 0 82.0H 29.79% {igb1 que} В целом по системе last pid: 74549; load averages: 4.03, 4.21, 4.21 up 129+13:25:47 20:13:49 148 processes: 16 running, 113 sleeping, 19 waiting CPU 0: 1.9% user, 0.0% nice, 46.3% system, 42.6% interrupt, 9.3% idle CPU 1: 0.0% user, 0.0% nice, 35.2% system, 55.6% interrupt, 9.3% idle CPU 2: 0.0% user, 0.0% nice, 44.4% system, 53.7% interrupt, 1.9% idle CPU 3: 0.0% user, 0.0% nice, 31.5% system, 61.1% interrupt, 7.4% idle Mem: 200M Active, 1207M Inact, 652M Wired, 12K Cache, 405M Buf, 1759M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root -68 - 0K 448K CPU2 2 609.6H 55.86% {irq258: igb0:que} 12 root -68 - 0K 448K CPU3 3 615.3H 51.17% {irq259: igb0:que} 12 root -68 - 0K 448K CPU0 0 384.1H 50.24% {irq256: igb0:que} 12 root -68 - 0K 448K WAIT 1 604.1H 46.44% {irq257: igb0:que} 0 root -68 0 0K 240K - 2 72.2H 36.23% {igb1 que} 0 root -68 0 0K 240K - 1 73.2H 35.35% {igb1 que} 0 root -68 0 0K 240K - 3 71.6H 33.59% {igb1 que} 0 root -68 0 0K 240K - 0 82.0H 29.79% {igb1 que} 0 root -68 0 0K 240K - 0 1496.6 14.60% {dummynet} 0 root -68 0 0K 240K - 1 42.5H 10.64% {igb0 que} 11 root 171 ki31 0K 64K RUN 1 2284.2 8.40% {idle: cpu1} 11 root 171 ki31 0K 64K RUN 3 2292.1 6.69% {idle: cpu3} 11 root 171 ki31 0K 64K RUN 2 2286.5 5.18% {idle: cpu2} 11 root 171 ki31 0K 64K RUN 0 1074.8 3.37% {idle: cpu0} 0 root -68 0 0K 240K RUN 1 23.6H 2.54% {igb0 que} 12 root -68 - 0K 448K WAIT 1 76.6H 2.39% {irq262: igb1:que} 12 root -68 - 0K 448K RUN 0 78.1H 2.34% {irq261: igb1:que} 0 root -68 0 0K 240K - 3 25.0H 2.05% {igb0 que} 12 root -68 - 0K 448K RUN 3 77.1H 2.00% {irq264: igb1:que} 12 root -68 - 0K 448K RUN 2 77.5H 1.90% {irq263: igb1:que} 0 root -68 0 0K 240K - 2 24.1H 0.93% {igb0 que} 13 root 44 - 0K 32K sleep 1 66:39 0.68% {ng_queue0} 12 root -32 - 0K 448K RUN 0 29.1H 0.54% {swi4: clock} igb1 это сетевая, которая смотрит внутрь локальной сети, и обычно процессы igb1 que не нагружают проц больше чем на доли % Трафик на сетевой в это время netstat -w1 -h -I igb1 input (igb1) output packets errs idrops bytes packets errs bytes colls 46K 0 0 15M 64K 0 78M 0 38K 0 0 12M 55K 0 68M 0 41K 0 0 13M 59K 0 73M 0 На что обратить внимание, что может так загружать эту сетевую?

Заставил себя выйти в ночь и все-таки склонировал систему с первого сервера на второй. теперь la в норме на обоих серверах, несмотря на то, что на 2м вернул память в одноканале. Значит все дело в версии freebsd и freebsd 8.3 отличается от 8.2 более высоким load average, возможно именно в сочетании с сетевыми картами igb. Или изменился способ подсчета la, так как встречал информацию, что kernel nat в 8.2 не отображается в la

Характер трафика должен быть максимально схож - NATятся подсети с абонентами, по 1-1.5к на сервер. С версиями пока ничего не сделаю, т.к обновлять 8.2 с хорошими показателями не хочется, а ставить 8.2 на 2й сервер пока нет технической возможности - сервер на боевом дежурстве. Идеальный вариант был бы вообще склонировать систему с 1го сервера на 2й