sid1333

cpuset -l 0 -p 47 Уменьшит ли нагрузку на dummynet данная команда? и sysctl dev.em в студию

:-) При 3х rx_kthreads, суммарная нагрузка на ядра процессоров получается меньше, чем при 4х. По крайней мере у меня. Но изначально про высокую загрузку проца речи не шло. Она как-бы ещё терпит... Я хотел узнать, как эффективнее перейти к 4 сетевым картам, есть ли смысл в бридже и агрегации каналов?

Да. Но трафика сейчас в 1.5 раза меньше, чем в ЧННКак видно, пол-компа просто простаивает :( last pid: 53112; load averages: 2.14, 1.91, 1.55 up 31+09:10:22 14:43:03 102 processes: 18 running, 71 sleeping, 13 waiting CPU: 0.0% user, 0.0% nice, 7.4% system, 0.0% interrupt, 92.6% idle Mem: 91M Active, 214M Inact, 497M Wired, 216K Cache, 208M Buf, 1119M Free Swap: PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 11 root 171 ki31 0K 16K CPU14 e 746.9H 100.00% [idle: cpu14] 12 root 171 ki31 0K 16K CPU13 d 746.7H 100.00% [idle: cpu13] 15 root 171 ki31 0K 16K CPU10 a 744.6H 100.00% [idle: cpu10] 16 root 171 ki31 0K 16K CPU9 9 744.1H 100.00% [idle: cpu9] 18 root 171 ki31 0K 16K CPU7 7 740.4H 100.00% [idle: cpu7] 25 root 171 ki31 0K 16K CPU0 0 639.4H 100.00% [idle: cpu0] 14 root 171 ki31 0K 16K CPU11 b 745.3H 99.27% [idle: cpu11] 10 root 171 ki31 0K 16K CPU15 f 747.5H 99.17% [idle: cpu15] 17 root 171 ki31 0K 16K CPU8 8 743.3H 99.17% [idle: cpu8] 13 root 171 ki31 0K 16K CPU12 c 746.7H 98.97% [idle: cpu12] 20 root 171 ki31 0K 16K CPU5 5 671.1H 87.89% [idle: cpu5] 19 root 171 ki31 0K 16K RUN 6 675.4H 86.38% [idle: cpu6] 23 root 171 ki31 0K 16K RUN 2 663.8H 86.18% [idle: cpu2] 24 root 171 ki31 0K 16K CPU1 1 664.5H 84.96% [idle: cpu1] 22 root 171 ki31 0K 16K CPU3 3 669.1H 84.77% [idle: cpu3] 21 root 171 ki31 0K 16K CPU4 4 667.4H 82.28% [idle: cpu4] 59 root 43 - 0K 16K WAIT 1 83.7H 20.07% [em1_rx_kthread_0] 60 root 43 - 0K 16K WAIT 2 79.7H 19.68% [em1_rx_kthread_1] 64 root 43 - 0K 16K WAIT 5 78.1H 18.80% [em2_rx_kthread_1] 232 root 43 - 0K 16K WAIT 3 80.0H 18.65% [em1_rx_kthread_2] 219 root 43 - 0K 16K CPU6 6 72.9H 18.65% [em2_rx_kthread_2] 63 root 43 - 0K 16K WAIT 4 78.0H 17.68% [em2_rx_kthread_0] 27 root -32 - 0K 16K WAIT 7 449:51 0.29% [swi4: clock] 73 root -68 - 0K 16K - 0 105.2H 0.00% [dummynet] 58 root -68 - 0K 16K WAIT 0 547:17 0.00% [em1_txcleaner] 62 root -68 - 0K 16K WAIT 0 483:55 0.00% [em2_txcleaner] 40 root 44 - 0K 16K - b 89:53 0.00% [yarrow] 72 root 8 - 0K 16K pftm 3 68:16 0.00% [pfpurge]

К сожалению, 2 машины это геморно и дороже, чем одна сетёвка на 4 порта. К тому-же роутер как мне кажется себя ещё далеко не исчепал. 800 Мбит/с входящего с интернета на шейпер прилетает.

Всем доброго времени суток! Имеется шейпер, обсуждаемый когда-то в этой теме: http://forum.nag.ru/forum/index.php?showtopic=49336 Платформа Intel sr1630bc на 2х xeon 5520. Установлена pro/1000 PT dual, em0 - к пограничнику, em1 в сеть. Сервер занимается маршрутизацией - 0.0.0.0 в ядро по ospf, шейпингом и натингом :) На данный момент нагрузка по сетевым приближается к 80%. По процессору - загружены на 50% только первые 7 из 16 виртуальных. В ЧНН нагрузка чуть выше, чем приведённая shaper-0 16:35:52 ~ # netstat -w1d 205097 0 159597690 203601 0 160596994 0 203944 0 159027946 202248 0 160017831 0 206316 0 160121798 204564 0 161361380 0 205305 0 159661574 203407 0 160274076 0 203136 0 160762659 201302 0 159682926 0 205133 0 160831585 202442 0 158285687 0 204073 0 159997438 201657 0 157972303 0 208393 0 162726945 205767 0 160343248 0 205144 0 160977995 202836 0 158564620 0 205161 0 161568061 202235 0 159337878 0 207557 0 160559455 205161 0 158634721 0 202014 0 159948872 199521 0 157821071 0 202879 0 161294195 200446 0 160487068 0 Понятно, что необходимо или менять pro/1000 dual на pro/1000 quad, или использовать 2 встроенные в мать сетевые. Сам склоняюсь к 1 варианту, ибо по спецификации одна из встроенных в мать сетевых вроде как подключена через pci шину. 2ой вопрос - это как быть с 4 новыми портами: - оставаться на роутинге, не организовывая lagg интерфейсы, пытаясь роутинг оставить как есть. - оставаться на роутинге, организовывая lagg (2 сетевые к пограничнику, 2 - в ядро) - немного изменить дизайн и перейти на bridge'ывание 2х lagg интерфейсов (2 сетевые к пограничнику, 2 - в ядро). Ибо по противоречивым сведениями bridge производительнее маршрутизации. Прошу совета, как лучше поступить, особенно с 4 имеющимися/новыми портами Заранее спасибо.

Ну начнём с того, что в ЧНН (для хомячков с 22:00 до 23:00) активно примерно 30-40% абонентов, то есть тех, что потребляют хотя бы 3% от выделенной им в пользование полосы. Для моей сети в среднем каждый из абонентов в среднем нагружает свою полосу например в 2500 Кбит/с не более чем на 12% (Есть отдельные личности - примерно 8%, которые в ЧНН занимают весь канал на 100% :). Таким образом, грубым расчётом получаем, что на полосу в 100Мбит/с можно посадить 100Мбит/с / (2.5Мбит/с * 40% * 12%) = 833 абонента. Тут правда не оговариваются никакие параметры качества обслуживания, такие как потери пакетов, задержки и т.п. Так как не сказано про дисциплины обслуживания какого-то ни было бы класса трафика - критичного к задержкам, к полосе или ещё какому-то параметру канала. Считайте и анализируйте для каждого из тарифов. А после корректировки полосы проделывайте расчёты снова и снова. Удачи :)

Ну изначально вопрос стоял как распараллелить dummynet из-за того, что нагрузка на него зашкаливала по неведомым причинам, но на данный момент необходимости в этом у меня нет вообще, как и у тов. jab'а - нагрузка на dummynet 0%

А система какая у вас? У меня такой эффект дало на 2 шейперах - один 7.2@amd64, 2ой 7.1@i386До привязки как я уже писал нагрузка на dummynet прыгала до 60% (7.1@i386 1.5Гбит/с in/out) Через 2ой шейпер бегает пока намного меньше, но и там это наблюдалось. AMD64 7.2-STABLE #12: Tue Sep 29 05:10:11 MSD 2009 у меня там и 100% было, сейчас отключил(net.isr.direct=0) прямой процессинг пакетов, стало легче, выше 50% не поднимается пока. все соптимизированно естессно, пользуется tablearg. А драйвера на em у вас какие? Использую yandex'овские

А система какая у вас? У меня такой эффект дало на 2 шейперах - один 7.2@amd64, 2ой 7.1@i386До привязки как я уже писал нагрузка на dummynet прыгала до 60% (7.1@i386 1.5Гбит/с in/out) Через 2ой шейпер бегает пока намного меньше, но и там это наблюдалось.

Команда где? Во Freebsd

Нашел в итоге в чём был косяк. Прознал про замечательную команду - cpuset. Прибил dummynet к 0 ядру и всё - 0.00% нагрузка на него сразу стало. И даже не думает подпрыгивать как было раньше.

Наблюдал глюки с ng_car с этими дровами. Иногда, не часто, просто не шейпит рррое. Тоесть параметры ноды в порядке если смотреть ngctl а трафик прет без ограничений... Да, есть такое. Только нод ng_car было 2-3 тысячи. А попробуй пересоздай ноду - получишь kernel panic. И проблема была только с yandex дровами - с родными проблем не возникало, но там были другие косяки, и от netgraph пришлось отказаться.

А в каком процессе Фряха обрабатывает НАТ трансляции через PF? Стоят драйвера от Яндекса - очевидно это emX_rx_kthread'ы - в этом случая PF видимо параллелится? Или я не прав?

Колечко крепится на задней стенке ящика. Глубины E-29 хватает для размещения оборудования.

Была такая же проблема в сети - строилась на 3526 с dhcp snooping и ip mac port binding.Также IMB некорректно отрабатывал при смене компа абонентом или ещё каких-либо действий - приходилось ждать окончания lease time. В итоге полностью отказался от IMB - для каждого коммутатора до установке генерируется набор ACL, разрешающий IP/ARP пакеты на порту и определяющий для каждого порта свой IP. DHCP snooping отключил, оставил только dhcp relay. В конечном счёте абонент может как автоматом получить нужные настройки, так и вручную вписать свой IP. Соглашусь, что решение ни разу не изящное, но тем не менее хорошо работает.

Было дело ТСЖ запретило кольца вокруг ящиков - таки затянули запас волокна в ящик - и там смотали кольцами. Ящик E-29 - около 20 метров и смотали + кросс + DGS-3100. Всё прекрасно влезло. Так что смотать волокно в ящике вполне реально :)

Для ng_netflow таймауты стандартные.Но трафика мне кажется у вас ощутимо больше, чем у меня.

Т.о. ng_netflow у Вас привязана в физическим интерфейсам без какой-либо хитрой конфигурации (сливаюся только входящие потоки на интерфейс), я правильно понимаю? В схеме с vlan per user так сделать не получилось (считался только исходящий), и сделал как вы - по iface с 3 конфигом ng_netflow на каждый vlan - считается и входящий и исходящий.А в схеме em0/em1 - вход/выход - сделано именно так - iface0 тупо к em1 - также считаются оба направления трафика.

Насколько я помню у вас считается только в одном направлении, у меня в и входящий и исходящий через vlan. На vlan считает оба направления с 3 конфигом. На данный момент 3000 абонентов генерируют 950 Мбит суммарно вход/выход, uplink и downlink. Но на той машине схема другая немного - em0 вход/em1 выход без всяких vlan и т.п.На нём поднят шейп, нат, netflow - роутер на 30% нагружен. Оптимизировать схему всё руки никак не дойдут.

На 7.2 такой огород можно не городить, а задать конигурацию iface-ов и все будет считаться в обе стороны: У меня работает вот так: #!/bin/sh . /etc/rc.subr # 1. Name of start script used in rc.conf name=flow_export rcvar=`set_rcvar` # 2. Functions of script (start/stop) start_cmd="nfsensor_start" stop_cmd="nfsensor_stop" # 3. Read configuration from rc.conf & setting defaults # 3.1 Collectors: new collector used by default. load_rc_config $name : ${flow_export_enable="NO"} : ${flow_export_interfaces=""} : ${flow_export_collectors="192.168.26.58:9995"} # 3.2 Executables # 3.2.1 Netgraph executable ngctl=/usr/sbin/ngctl # 3.2.2 Kldstat executable kldstat=/sbin/kldstat # 3.2.3 Number of netflow hooks nodes num_iface=0 # 3.2.4 Number of virtual hub ports connected to collectors num_port=1 # 3.2.5 List of modules module_list="ng_ether ng_ksocket ng_netflow ng_hub" # 4. Functions nfsensor_start() { # Sanity check echo "Starting flow_export netgraph structure." # Checking if "export" interface specified. if [ -z "$flow_export_interfaces" ] then echo "[ERR]: You must specify at least one iface." exit fi # Checking if require modules are loaded for module in $module_list; do check=`$kldstat -v |grep ${module}` if [ -z "$check" ] then echo "[ERR]: Module ${module} is not loaded." exit fi done # Creating nodes for iface in $flow_export_interfaces; do # Checkng if netflow node is created if [ $num_iface -eq 0 ] then # Creating neflow node for given iface $ngctl mkpeer $iface: netflow lower iface${num_iface} $ngctl name $iface:lower nfsr-node $ngctl connect $iface: nfsr-node: upper out${num_iface} # Configuring current netflow node $ngctl msg nfsr-node: setdlt { iface=${num_iface} dlt=1 } $ngctl msg nfsr-node: settimeouts { inactive=10 active=30 } # Collecting ingress & egress flows (require FreeBSD 7.2 and above) $ngctl msg nfsr-node: setconfig { iface=${num_iface} conf=11 } else # Connecting given iface to netflow node $ngctl connect $iface: nfsr-node: lower iface${num_iface} $ngctl connect $iface: nfsr-node: upper out${num_iface} # Collecting ingress & egress flows (require FreeBSD 7.2 and above) $ngctl msg nfsr-node: setconfig { iface=${num_iface} conf=11 } fi # Using next node num_iface=`expr $num_iface + 1` done # Connecting export hook of netflow node to virtual hub $ngctl mkpeer nfsr-node: hub export hubtmp $ngctl name nfsr-node:export nfex-hub # Connecting export flows to collectors to hub ports num_port=1 for collector in $flow_export_collectors; do $ngctl mkpeer nfex-hub: ksocket p${num_port} inet/dgram/udp $ngctl name nfex-hub:p${num_port} nfex-hub-p${num_port} $ngctl msg nfex-hub:p${num_port} connect inet/$collector num_port=`expr $num_port + 1` done } nfsensor_stop() { echo "Stoping flow_export netgraph structure." # Killing virtual hub node $ngctl shutdown nfex-hub: > /dev/null 2>&1 # Killing netflow node $ngctl shutdown nfsr-node: > /dev/null 2>&1 } run_rc_command "$1" Ну собсно аналогичный вашему скриптовый костыль быль прикручен перед созданием темы на форуме =) Только не с 11, а с 3 конфигом для ng_netflow. Надеялся просто, как всегда сделать проще, да видать не судьба =) Dm1try, у вас судя по скрипту создаётся по ноде ng_netflow для каждого vlan? Позвольте спросить: а зачем? Можно же обойтись всего одной :) Или я просто немного не разобрался в принципе функционирования вашего скрипта?

Всем доброго времени суток! Возникла проблема сбора статистики через ng_netflow. Топология: L3 сеть <-> em0:Router:em1 <-> DGS-3100-24TG <-> ВОЛС <-> DES-3526 <-> Абонент по vlan per user. Операционка FreeBSD 7.2. Cобираюсь считать трафик через ng_netflow, прикрепляя его к ng_ether который от em1: ngctl mkpeer em1: netflow lower iface0 ngctl name em1:lower netflow ngctl connect em1: netflow: upper out0 ngctl msg netflow: setconfig { iface = 0 conf = 3 } <- тут учитываем проходящие в обе стороны пакеты ngctl mkpeer netflow: ksocket export inet/dgram/udp ngctl msg netflow:export connect inet/xxx.xxx.147.26:1670 По каким-то причинам трафик считается только в одну сторону - только пакеты, приходящие из em1 Знает ли кто способ сбора статистики таким образом? Очень не хочется прикручивать к netgraph ipfw и заворачивать трафик через ngtee. P.S. снимать статистику с внешнего интерфейса em0 не удастся, ибо на нем висит pfnat. Всем заранее спасибо :)

Я видел что-то такое на сайте производителя, но там ни инструкции, ни описания, видать рассчитано на спецов, а хочется своими кривыми ручками сначала попробовать... Поэтому жду дальнейших советов по активации GUI или по управлению через SNMP http://www.alliedtelesis.co.nz/documentati...-10496-01-B.pdf - в Release Notes есть "мануал". Читайте

На сайте AT есть инструкции как включить на x900 WEB. Читайте мануалы.Но вообще, конфигурировать такие железки нужно через консоль.

Доброй ночи! Столкнулся тут с косяком с ISC DHCPD 3.0 при использовании option-82. Пока не могу понять как правильно его настроить. В двух словах: Сеть имеет такой вид: [Абонент]---[DES-3526]---[DES-3100-24TG]---[DGS-3612G]---[L3 сеть]---[ЦСФ]---[2 дублирующих DHCP сервера] На DES-3526 включен DHCP snooping, он же выступает DHCP relay и шлёт запросы на сервера в ЦСФ. Все абоны запиханы в один vlan с IP 10.xxx.0.0/20, порты изолированы друг от друга - пускается трафик только на uplink. IP адреса свичей в управляющем vlan из подсети 10.xxx.31.0/24 Конфиги dhcpd идентичны. Привожу конфиг слэйва: # /etc/dhcp/dhcp.conf ddns-update-style none; default-lease-time 600; max-lease-time 86400; log-facility local7; local-address xx.xx.xx.xz; option domain-name "isp.ru"; if exists agent.circuit-id { log(info, concat( "Leased IP address: ", binary-to-ascii(10, 8, ".", leased-address), "; Switch: ", substring(option agent.remote-id, 2, 32), "; VLAN ID: ", binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 2, 2)), "; Port: ", binary-to-ascii(10, 8, "/", substring(option agent.circuit-id, 4, 2)))); } # Failover failover peer "DHCP-Master" { secondary; address xx.xx.xx.xx; port 313; peer address xx.xx.xx.xy; peer port 313; max-response-delay 30; max-unacked-updates 10; } shared-network prov { subnet xx.xx.xx.00 netmask 255.255.255.224 { } # Networks including include "/etc/dhcp/XXX-0/XX3-0"; include "/etc/dhcp/XXX-0/XX4-0"; } Конфиг одной подсети: # Network XX3-0 subnet 10.XX3.31.0 netmask 255.255.255.0 { range 10.XX3.31.254; deny unknown-clients; } subnet 10.XX3.0.0 netmask 255.255.240.0 { authoritative; option routers 10.XX3.0.1; option subnet-mask 255.255.240.0; option domain-name-servers 10.XX3.0.1, xx.xx.xx.xz; # Including access switches definitions include "/etc/dhcp/XX3-0/XX3-0-1"; include "/etc/dhcp/XX3-0/XX3-0-2"; ... include "/etc/dhcp/XX3-0/XX3-0-20"; Конфиг для одного из коммутаторов: # IP address range 10.XX3.1.145-10.XX3.1.168 class "acc-XX3-0-7-port-1" { match if (substring(option agent.remote-id, 2, 32) = "Acc-XX3.0-7" and binary-to-ascii(10, 8, "", suffix(option agent.circuit-id, 1)) = "1"); } class "acc-XX3-0-7-port-2" { match if (substring(option agent.remote-id, 2, 32) = "Acc-XX3.0-7" and binary-to-ascii(10, 8, "", suffix(option agent.circuit-id, 1)) = "2"); } class "acc-XX3-0-7-port-3" { match if (substring(option agent.remote-id, 2, 32) = "Acc-XX3.0-7" and binary-to-ascii(10, 8, "", suffix(option agent.circuit-id, 1)) = "3"); } ... class "acc-XX3-0-7-port-24" { match if (substring(option agent.remote-id, 2, 32) = "Acc-XX3.0-7" and binary-to-ascii(10, 8, "", suffix(option agent.circuit-id, 1)) = "24"); } pool { failover peer "DHCP-Master"; deny dynamic bootp clients; range 10.XX3.1.145; allow members of "acc-XX3-0-7-port-1"; } pool { failover peer "DHCP-Master"; deny dynamic bootp clients; range 10.XX3.1.146; allow members of "acc-XX3-0-7-port-2"; } pool { failover peer "DHCP-Master"; deny dynamic bootp clients; range 10.XX3.1.147; allow members of "acc-XX3-0-7-port-3"; } ... pool { failover peer "DHCP-Master"; deny dynamic bootp clients; range 10.XX3.1.168; allow members of "acc-XX3-0-7-port-24"; } Свичи прекрасно релеят запросы на сервера, но выдаётся не то, что прописано в пулах: Jul 10 17:46:40 dhcpd-slave dhcpd: Leased IP address: 10.XX3.31.254; Switch: Acc-XX3.0-7; VLAN ID: 50; Port: 0/1 Jul 10 17:46:40 dhcpd-slave dhcpd: DHCPDISCOVER from 00:15:f2:77:8f:e1 via 10.XX3.31.7: unknown client Jul 10 17:46:44 dhcpd-slave dhcpd: Leased IP address: 10.XX3.31.254; Switch: Acc-XX3.0-7; VLAN ID: 50; Port: 0/1 Jul 10 17:46:44 dhcpd-slave dhcpd: DHCPDISCOVER from 00:15:f2:77:8f:e1 via 10.XX3.31.7: unknown client Jul 10 17:46:52 dhcpd-slave dhcpd: Leased IP address: 10.XX3.31.254; Switch: Acc-XX3.0-7; VLAN ID: 50; Port: 0/1 Jul 10 17:46:52 dhcpd-slave dhcpd: DHCPDISCOVER from 00:15:f2:77:8f:e1 via 10.XX3.31.7: unknown client Jul 10 17:47:07 dhcpd-slave dhcpd: Leased IP address: 10.XX3.31.254; Switch: Acc-XX3.0-7; VLAN ID: 50; Port: 0/1 Jul 10 17:47:07 dhcpd-slave dhcpd: DHCPDISCOVER from 00:15:f2:77:8f:e1 via 10.XX3.31.7: unknown client Jul 10 17:47:43 dhcpd-slave dhcpd: Leased IP address: 10.XX3.31.254; Switch: Acc-XX3.0-7; VLAN ID: 50; Port: 0/1 Выдаётся IP 10.XX3.31.254. Эту сеть обязательно нужно задавать и выделять в ней пул хотя бы на 1 IP, иначе dhcpd ругается на неопределённую сеть, когда приходит пакет от 3526, или на отсутствие свободных адресов в этой сети, если не определять пул. Прошу подсказать, как сделать так, чтобы isc dhcpd не обращал внимание на подсеть свичей, и выдавал только заданные адреса из абонентских пулов. Заранее спасибо :)

При чём тут сложность? Мы говорим о том, как решить конкретную задачу с минимумом затрат и максимально оптимально.