emp

отвечаю сам себе. может кому то пригодится: нужно было в влан добавлять не только ether1, но и bridge1 /interface bridge vlan add bridge=bridge1 vlan-ids=10 tagged=bridge1,ether1

/interface vlan add name=v10 interface=bridge1 vlan-id=10 /ip address add interface=v10 address=10.0.0.2/24 /interface bridge vlan add bridge=bridge1 vlan-ids=10 tagged=ether1 включаюсь в ether1 ноутбуком. на сетевухе создаю vlan10. 10.0.0.2 пингуется. конфиг бриджа: 16 R name="bridge1" mtu=auto actual-mtu=1500 l2mtu=1592 arp=enabled arp-timeout=auto mac-address=74:4D:28:39:06:3F protocol-mode=none fast-forward=yes igmp-snooping=no auto-mac=yes ageing-time=5m vlan-filtering=no dhcp-snooping=no конфиг порта в бридже: 38 H interface=ether1 bridge=bridge1 priority=0x80 path-cost=10 internal-path-cost=10 edge=auto point-to-point=auto learn=auto horizon=none hw=yes auto-isolate=no restricted-role=no restricted-tcn=no pvid=1 frame-types=admit-all ingress-filtering=no unknown-unicast-flood=yes unknown-multicast-flood=yes broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no multicast-router=temporary-query fast-leave=no включаю vlan-filtering=yes и 10.0.0.2 перестаёт пингваться. что я не так делаю ?

Доброго времени суток! Подскажите, а ipv6 dhcp relay на 4948 рабочий ? Есть грабли ?

Раскидывание по ядрам и модуль никак не свазаны, поэтому порядок этих событий не важен. Вы можете еще увеличить hashsize, чтоб [metric] (эффективность работы хэша) приблизилась к единице, что ещё снизит нагрузку на проц. Скажем, у вас пик потоков 629918, сделайте hashsize=1200000. возможно я гдето протупил. но после обновления я видел netflow только на 2 ядре, о чём здесь и написал. дальше перезагрузка модуля с опциями по агрегации решила проблему. тогда я ещё мог ребутить сервер. сейчас мне уже сложно это делать. hashsize увеличил. нагрузки от netflow не вижу. тем временем трафик дорос до 7gbit. p.s большое всем спасибо за помощь. многое понял. остался только впорос по зебре с её сканированием интерфейсов.

вообщем теперь картина такая: ipt_NETFLOW v2.0-38-g54c3227, srcversion 2D9D2E1F19E951BD1E36FD7; aggr llist Protocol version 5 (netflow) Timeouts: active 1800s, inactive 15s. Maxflows 2000000 Flows: active 506633 (peak 629918 reached 0d22h26m ago), mem 77495K, worker delay 1/250 [1..25] (0 ms, 0 us, 352:0 0 [cpu0]). Hash: size 800000 (mem 6250K), metric 1.51 [1.50, 1.18, 0.53]. InHash: 387235936 pkt, 308018407 K, InPDU 42, 4370. Rate: 5428845418 bits/sec, 843379 packets/sec; Avg 1 min: 5455167067 bps, 846323 pps; 5 min: 5370635896 bps, 835048 pps cpu# pps; <search found new [metric], trunc frag alloc maxflows>, traffic: <pkt, bytes>, drop: <pkt, bytes> Total 843376; 5380167913351 273517684728 9284260499 [1560.44], 0 0 0 0, traffic: 282801945227, 215325245 MB, drop: 0, 0 K cpu0 0; 0 0 0 [1.00], 0 0 0 0, traffic: 0, 0 MB, drop: 0, 0 K cpu1 96604; 587841216125 30008463123 1015699971 [1.49], 0 0 0 0, traffic: 31024163094, 23416140 MB, drop: 0, 0 K cpu2 85199; 585970499794 29848668569 1015470655 [1.53], 0 0 0 0, traffic: 30864139224, 23608223 MB, drop: 0, 0 K cpu3 87528; 591770187481 29989603720 1016108203 [1.48], 0 0 0 0, traffic: 31005711923, 23569537 MB, drop: 0, 0 K cpu4 86224; 586031363593 29651185174 1015642784 [1.52], 0 0 0 0, traffic: 30666827958, 23223060 MB, drop: 0, 0 K cpu5 97806; 585107051867 29621936067 1015719804 [1.48], 0 0 0 0, traffic: 30637655871, 23378563 MB, drop: 0, 0 K cpu6 89432; 586299031406 29784012474 1015647323 [1.50], 0 0 0 0, traffic: 30799659797, 23445886 MB, drop: 0, 0 K cpu7 96904; 581832408673 29873359107 1015340858 [1.49], 0 0 0 0, traffic: 30888699965, 23711121 MB, drop: 0, 0 K cpu8 100359; 639396671221 32319288741 1086884706 [1.50], 0 0 0 0, traffic: 33406173447, 25613678 MB, drop: 0, 0 K cpu9 103320; 635919483198 32421167763 1087746195 [1.49], 0 0 0 0, traffic: 33508913958, 25359032 MB, drop: 0, 0 K Export: Rate 1329312 bytes/s; Total 309458462 pkts, 432059 MB, 9283753856 flows; Errors 0 pkts; Traffic lost 0 pkts, 0 Kbytes, 0 flows. sock0: 10.10.4.111:9000, sndbuf 212992, filled 1, peak 92161; err: sndbuf reached 0, connect 0, cberr 0, other 0 aggr#0 port: ports 1024-65535 replace 0 (usage 1086409121) вроде всё красиво. раньше netflow ложился на второе ядро. подозреваю что сперва модуль загрузился а позже запустился скрипт который по ядрам прерывания раскидал. после этого я модуль руками перезагружал. тогда то netflow и разделился по ядрам. сталобыть к ipt_netflow притензий нет. теперь другая проблема. quagga сильно проц жрёт временами. на машине поднят bgp. маршрутов несколько сотен. а вот интерфейсов ~9k и постоянно добавляются и убавляются. процесс zebra ругается 2014/11/19 19:07:07 ZEBRA: SLOW THREAD: task work_queue_run (7f78b19862c7) ran for 6294ms (cpu time 5840ms) подозреваю что это из за большого количества интерфейсов. зачем zebra их сканит ? чтоб конфиг добавить ? а можно это както отключить ?

Flows: active 218680 (peak 611012 reached 1d18h44m ago) pps максимум что видел 1.6mpps эксперимент по поводу обхода второго ядра решил отложить. сейчас нет постоянной нагрузки на 2 ядро. нагрузка периодически подскакивает рандомно на разных ядрах и буквально на 1-3 секунды после чего падает. поднимаю нагрузку. пока раскачал до 5gbit. # grep Hash /proc/net/stat/ipt_netflow Hash: size 800000 (mem 6250K), metric 1.04 [1.02, 1.00, 1.00]. InHash: 21648276 pkt, 14981741 K, InPDU 137, 85860. А у Вас? p.s. настройки hash по default (8192 buckets) не предназначены для highload странно. в sysctl.conf net.netflow.hashsize = 327680 а оно почему то не применилось. хотя возможно я просто потом руками модуль перезагружал и оно сбросилось. поднял. посмотрим что будет вечером.

Да, но есть отдельная тема про ipt_NETFLOW, как раз для таких случаев. Хотя я не спорю, что темы сопряженные. уже вроде как и про производительность говорим. Теория нормальная, потому что помимо Intel Smart Cache, который L2 и общий, есть кеш у каждого ядра, который L1. Если ядро без трафика на нем будет всеравно давать 50-60%, то дело не в вымывании кеша. Кстати, на всякий случай, у вас irqbalance и HT отключены? теорию без практики подзабывать начал. L1 разве не кэш инструкций ? irqbalance и HT конечно отключены. попробую обойти 2 ядро прерываниями сетевух. если это может - замечательно. только вот как бы это потом на автомате делать после ребута. бывало что эти же самые спецэффекты были на нулевом ядре.

вроде про soft router говорим :) те граждане которые его обычно запрашивают ещё ни разу про порты не спрашивали. пока что их устраивал такой формат: source ip, destination ip, octets. сагрегировал на вскяй случай 1024-65535. это я пробовал. садится на 2 ядро и никак иначе. Правильно сомневаетесь, правило обрабатывается в контексте прерывания, затем после отработки правила, зовется модуль ipt_NETFLOW ( контекст переключается на следующее прерывание или что там ). Сам модуль прибит гвоздями к kworker и само исполнение правила переходит уже физически на другое ядро. На сколько я понял. Но тогда не понятно, почему у других, включая меня, проблем нет. плохая теория. кэш то общий на все ядра. толку не будет. сейчас кстати посмотрел статистику netflow. всё распаралелено. по ядрам за исключением нулевого. на нём нет прерываний от сетевух. раньше всё было на 2-м ядре. в какой момент оно разпаралелилость мне не понятно. после обновления или после включения агрегации.

вообщем отвечаю сам себе. помогла опция aggregation. таблица видимо стала генериться сильно меньше. кэша стало хватать. посмотрим что будет вечером.

да правила то не сильно грузят. можно с этим мириться. netflow больше напрягает. перекоса нет. всё идеально балансируется. мне кажется что после запуска netflow он просто генерит таблицу вымывая кэш. в принципе я netflow могу снимать в другом месте. но sampled. кто нибудь пользуется netflow sampled для "органов" ? они не сильно обижаются ? законно ли это ? Сорри, что не по теме, но не могу пройти мимо. Для чего вообще netflow органам? У нас омега стоит, на нее span + доступ к биллингу. А нетфлоу каким боком им нужно? сорм доступен только фcб. иногда приходят письма от отдела к и вообще от мвд с запросом детализации. на сколько я помню по закону нужно хранить логи 3 года. если это уже не так, то с удовольствием с этим распрощаюсь. Хмм, я думал это от них и приходит. Вопросик можно - как вы храните и на чем? Может в личке пообщаемся? от этих тоже приходит иногда. просят логи годовалой давности для суда. вообщем здесь это уже офтопик. отписал в личку.

да правила то не сильно грузят. можно с этим мириться. netflow больше напрягает. перекоса нет. всё идеально балансируется. мне кажется что после запуска netflow он просто генерит таблицу вымывая кэш. в принципе я netflow могу снимать в другом месте. но sampled. кто нибудь пользуется netflow sampled для "органов" ? они не сильно обижаются ? законно ли это ? Сорри, что не по теме, но не могу пройти мимо. Для чего вообще netflow органам? У нас омега стоит, на нее span + доступ к биллингу. А нетфлоу каким боком им нужно? сорм доступен только фcб. иногда приходят письма от отдела к и вообще от мвд с запросом детализации. на сколько я помню по закону нужно хранить логи 3 года. если это уже не так, то с удовольствием с этим распрощаюсь.

да правила то не сильно грузят. можно с этим мириться. netflow больше напрягает. перекоса нет. всё идеально балансируется. мне кажется что после запуска netflow он просто генерит таблицу вымывая кэш. в принципе я netflow могу снимать в другом месте. но sampled. кто нибудь пользуется netflow sampled для "органов" ? они не сильно обижаются ? законно ли это ?

поставил v2.0-38-g54c3227. тоже самое. автор врядли чем то поможет. это же не его вина. надо понять как ядерные процессы прибивать к ядрам или хотябы как их обходить и будет счастье.

дак конечно. всё гораздо лучше становится. если убрать все правила то вообще красота. тоесть без правил и netflow 2-4% по всем ядрам. включаем правила без netflow - на 2 ядре нагрузка подростает до 6-8%. добавляем правило с -j NETFLOW - нагрузка на 2 ядре подскакивает до 50-60%. на остальных ядрах по прежнему 2-4%. трафика 3gbit.

ipt_NETFLOW linux 2.6.x-3.x kernel module by <abc@telekom.ru> -- 2008-2014. #define GITVERSION "v1.8-121-gd353977"