Перейти к содержимому
Калькуляторы

napTu

Пользователи
  • Публикации

    26
  • Зарегистрирован

  • Посещение

О napTu

  • Звание
    Абитуриент
  1. netflow sensor linux/freebsd

    нужна freebsd+netflow v9 с расширением NEL (NAT events extension ) нашел только упоминание https://lists.freebsd.org/pipermail/freebsd-net/2013-October/036993.html
  2. удалось снизить нагрузку dummynet на 20% за счет установки параметра pipe burst на 20 мегабайт
  3. Была подобная проблема, но правда помогало передергивание сфп или port state disable/enable. В первый раз переставили на другие порты и работали дальше без проблем, пометив предыдущие "плохими", потом, со временем пришлось занять и "плохие" и они работают до сих пор нормально. Во второй раз на любых портах гас 20км модуль, в другом свиче нормально работает, а в этом гаснет. Замена модуля на того же производителя и той-же дистанции помогла. Ревизия A2.
  4. я смутно представляю обработку пакета, но из того что вычитал про 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 драйвер, который яндексами не поддерживается...
  5. FreeBSD 9.0 + em

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

    естественно речь о 100мбит портах. я не понимаю, des-3028 и cisco2950 дают в полке 12800кбайт/с, почему 3526 не дает?
  8. 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 байт в сек. А как у вас?
  9. управляемый - циска2950. раздача через основной шлюз. пакеты в ответе не дробленные, так и идут по 1300-1500 байт. в запросах все пакеты короткие, но и аплинка особого нет. мультикаст шторм? и куда он девается при закрытии доступа в инет?
  10. У нас тепло, +5 - +15, иногда сыро, но зависимости нет. есть, смотрел, udp,tcp обмен торрента, ничего лишнего или необычного, искал какие либо маркеры пакетов, но возможно они в центре уже отфильтрованы. input flow-control is unsupported output flow-control is unsupported
  11. Может кто то посоветует по сабжу? Ситуация периодически наблюдается на нескольких сегментах сети. Сеть построена на управляемом свиче в середине и оптическими 100мбит выносами на конверторах, затем идут по частному сектору 100м отрезки на неуправляемых свичах. При включении одним из клиентов какого то хитрого торрента возрастают пинги в пределах всего сегмента после оптики, даже в другую ветку от оптики. При запрещении на роутере ip трафика от этого клиента пинги становятся 1-2мс, если же блокировать трафик tcp или udp по раздельности, то пинги кратковременно уменьшаются до 10-20мс, а затем снова возрастают до 30-60мс. От клиента поступает при этом примерно 50 очередей и низкий upload, при этом download к нему около 10мбит. Общий download на сегмент 20-30мбит Как вариант, пакеты маркируются высоким приоритетом QoS? Не нашел никакой информации по этому поводу, неизвестно, понимают ли неуправляемые свичи (или конверторы) маркеры qos и может ли торрент маркировать так пакеты.
  12. Винт 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 Кто может подсказать?
  13. ух как всё запущено... после замены машины на двуядерную нагрузка по taskq процессам выравнялась странно то что драйвер кушал на прием в два раза больше CPU, чем на передачу
  14. Имеется роутер 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 на этом интерфейсе?