napTu

нужна freebsd+netflow v9 с расширением NEL (NAT events extension ) нашел только упоминание https://lists.freebsd.org/pipermail/freebsd-net/2013-October/036993.html

удалось снизить нагрузку dummynet на 20% за счет установки параметра pipe burst на 20 мегабайт

Была подобная проблема, но правда помогало передергивание сфп или port state disable/enable. В первый раз переставили на другие порты и работали дальше без проблем, пометив предыдущие "плохими", потом, со временем пришлось занять и "плохие" и они работают до сих пор нормально. Во второй раз на любых портах гас 20км модуль, в другом свиче нормально работает, а в этом гаснет. Замена модуля на того же производителя и той-же дистанции помогла. Ревизия A2.

я смутно представляю обработку пакета, но из того что вычитал про HK_QUEUE, это что дальнейшая обработка пакета производится на базе подсистемы netisr. И тут теряется смысл уходить из ISR в netgraph чтобы затем вернуться в ISR. Пока что вроде собрались yandex драйвера под 9.1release с небольшой правкой мелкой наждачкой: в /usr/src/sys/dev/e1000/e1000_osdep.h закоментил строки 76,78,99 (на которые была ругань) и в /usr/src/sys/modules/em/Makefile убрал e1000_i210.c ... собирал только em драйвер, да и тот похоже не заработал, нет опций rx_queue в sysctl... Полная сборка ядра не идет, ругается на igb ... сетевушки PCI на новособранной тестовой машинке оказались, а на них только legacy em драйвер, который яндексами не поддерживается...

похожую ситуацию давно наблюдаю на 8.1 с яндекс дровами, когда перезагрузка раза в два снижает пиковую нагрузку CPU. Были идеи что замусориваются таблицы в ipfw или еще какие буфера. А то что перекос входа-выхода разных интерфейсов роутера, так это действительно быстрее всего разный путь обработки пакета в ipfw

а есть смысл ? если да , то немножко ближе к реализации кто то может натолкнуть? Например если принимаемый трафик направить в ng_onw2many, а затем с каждого many вернуть в ядро, этого будет достаточно, или необходимы еще какие либо ноды для организации очереди?

естественно речь о 100мбит портах. я не понимаю, des-3028 и cisco2950 дают в полке 12800кбайт/с, почему 3526 не дает?

раз уж 3536, то спрошу здесь Заметил что на моем 3526 максимальная скорость по show packet ports составляет 9523840 байт в сек, упирается в это значение и растут пинги, делю на 1024, получается 9300,625 кбайт/сек, или 74405кбит/с, или 72.66 мбит/с Возникает вопрос - куда же деваются оставшиеся 27.33 мбит полосы порта? Перекопал все настройки, никаких ограничений нет, ни в hardware , ни в cpu, практически все фичи выключены, свич сброшен был перед продажей. Работают только два access_profile на tcp445 deny и udp68 deny. Если, например, ставить config bandwidth_control 1-24 rx_rate 99 tx_rate 99 то всё равно маскимум 9523840 байт в сек. А как у вас?

управляемый - циска2950. раздача через основной шлюз. пакеты в ответе не дробленные, так и идут по 1300-1500 байт. в запросах все пакеты короткие, но и аплинка особого нет. мультикаст шторм? и куда он девается при закрытии доступа в инет?

У нас тепло, +5 - +15, иногда сыро, но зависимости нет. есть, смотрел, udp,tcp обмен торрента, ничего лишнего или необычного, искал какие либо маркеры пакетов, но возможно они в центре уже отфильтрованы. input flow-control is unsupported output flow-control is unsupported

Может кто то посоветует по сабжу? Ситуация периодически наблюдается на нескольких сегментах сети. Сеть построена на управляемом свиче в середине и оптическими 100мбит выносами на конверторах, затем идут по частному сектору 100м отрезки на неуправляемых свичах. При включении одним из клиентов какого то хитрого торрента возрастают пинги в пределах всего сегмента после оптики, даже в другую ветку от оптики. При запрещении на роутере ip трафика от этого клиента пинги становятся 1-2мс, если же блокировать трафик tcp или udp по раздельности, то пинги кратковременно уменьшаются до 10-20мс, а затем снова возрастают до 30-60мс. От клиента поступает при этом примерно 50 очередей и низкий upload, при этом download к нему около 10мбит. Общий download на сегмент 20-30мбит Как вариант, пакеты маркируются высоким приоритетом QoS? Не нашел никакой информации по этому поводу, неизвестно, понимают ли неуправляемые свичи (или конверторы) маркеры qos и может ли торрент маркировать так пакеты.

Винт SATA 300Гиг, swap раздел отдельный, остальные разделы совмещены на руте. Nov 21 00:23:21 icenet savecore: reboot after panic: page fault Nov 21 00:23:21 icenet savecore: writing core to vmcore.1 Nov 21 01:57:22 icenet kernel: em1: link state changed to DOWN Nov 21 01:57:22 icenet kernel: em1: permanently promiscuous mode enabled Кто может подсказать?

ну типа так

ух как всё запущено... после замены машины на двуядерную нагрузка по taskq процессам выравнялась странно то что драйвер кушал на прием в два раза больше CPU, чем на передачу

Имеется роутер freeBSD8 , установлена двухголовая сетевуха Intel PRO1000, на роутере крутятся ipfw_NAT и dummynet шейпер, проблема в том что нагрузка CPU не внешнем интерфейса в два раза выше чем на внутреннем CPU: 0.0% user, 0.0% nice, 38.5% system, 1.5% interrupt, 60.0% idle Mem: 13M Active, 73M Inact, 130M Wired, 100K Cache, 110M Buf, 768M Free Swap: 499M Total, 499M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 11 root 171 ki31 0K 8K RUN 719.7H 75.88% idle 0 root -68 0 0K 72K - 250.8H 19.19% {em1 taskq} 0 root -68 0 0K 72K - 140.3H 7.08% {em0 taskq} 12 root -32 - 0K 152K WAIT 16.9H 0.39% {swi4: clock} - это утром, когда нагрузки нет, в часы пик всё совсем плачевно, на роутер по ssh зайти невозможно. # netstat -I em0 1 input (em0) output packets errs idrops bytes packets errs bytes colls 4581 0 0 1963289 8970 0 11783169 0 2750 0 0 1546138 3936 0 4542593 0 3646 0 0 1542227 7645 0 9602153 0 5698 0 0 1674778 12439 0 15911144 0 4211 0 0 1532071 9564 0 11906136 0 3793 0 0 1512754 8095 0 10265014 0 4955 0 0 1732655 11360 0 14124697 0 ^C # netstat -I em1 1 input (em1) output packets errs idrops bytes packets errs bytes colls 8794 0 0 11249858 3362 0 975056 0 7600 0 0 9997996 3077 0 1001101 0 10414 0 0 13646838 4013 0 1003573 0 10120 0 0 12928187 3923 0 1057064 0 10329 0 0 13476388 4049 0 1107544 0 9571 0 0 12497571 3726 0 965102 0 7356 0 0 9980667 3295 0 1049251 0 pps соответственно перекошен с большей частью по приему через внешний интерфейс em1. Кто то сталкивался, что может вызывать перекос нагрузки CPU, преимущественно входящий трафик или NAT на этом интерфейсе?