heap

Споткнулся об сабж. Ситуация следующая. Создаю policy: # sh policy "Prov-IN" Policies at Policy Server: Policy: Prov-IN entry Prov-IN_01 { if match all { source-address 10.6.0.0/30 ; } then { permit ; count prov_permit_bgp ; } } entry Prov-IN_03 { if match all { destination-address 192.168.1.0/24 ; } then { permit ; count prov_permit_cl ; } } entry denyall { if match all { } then { deny ; count prov_drop ; } } Применяю к VLAN. Запускаю трафик. Смотрю. Растут счетчики permit. В какой-то момент трафик пропадает, счетчики permit останавливаются и начинает расти счетчик drop. X670-48x.13 # sh access-list counter Policy Name Vlan Name Port Direction Counter Name Packet Count Byte Count ================================================================== Prov-IN DES * ingress prov_drop 685 prov_permit_bgp 178 prov_permit_cl 423 Причем prov_permit_bgp худо бедно немного увеличивается. А вот счетчик prov_permit_cl вообще стоит на месте. Проверено и на summitX-15.3.1.4-patch1-10.xos и на summitX-15.3.2.11.xos. В чем соль?

Солидарен. Но есть исторический момент - так уж сложилось. :)

Да рад бы интелами жевать, только HP в свои лезвия воткнул встроенные бродкомы, так что имеем, что имеем - два бродкома и четыре интела, исторически с не самыми лучшими под задачу чипами. :(

Работать-то он работает, но на плотных потоках всё равно появляются interrupt'ы, и много, а с coalescing'ом там всё не просто плохо, а очень плохо. Это надо так понимать, что сетевые на данном чипе - дело печальное?

Господа! Тут в ветке много выкладок типа - подтюнинговал на роутере такие-то sysctl переменные. Разве следующие переменные несут смысл именно для роутера и транзитного трафика? net.core.wmem_max net.core.wmem_default net.ipv4.tcp_wmem net.core.rmem_max net.core.rmem_default net.ipv4.tcp_rmem net.ipv4.tcp_max_syn_backlog net.ipv4.tcp_sack net.ipv4.tcp_no_metrics_save net.core.somaxconn net.ipv4.ipfrag_high_thresh net.ipv4.ipfrag_low_thresh net.ipv4.ipfrag_time net.ipv4.ipfrag_secret_interval net.ipv4.ipfrag_max_dist

С NAPI отбой. Работает. Посмотрел perf top. С небольшим отрывом лидирует: __ticket_spin_lock. Что за зверь такой? Кто-нибудь уже сталкивался?

У меня такое ощущение, что не работает или как-то не так работает NAPI в bnx2x. На коленке сделал скриптик, который раз в 5 секунд считает PPS и IRQPS для интерфейсов. Получается что-то такое: eth0 -- PPS: 76897 -- IRQps: 70219 eth1 -- PPS: 72635 -- IRQps: 66999 eth2 -- PPS: 39957 -- IRQps: 14058 eth3 -- PPS: 32346 -- IRQps: 16307 eth4 -- PPS: 33862 -- IRQps: 15686 eth5 -- PPS: 29576 -- IRQps: 16251 Total: -- PPS: 285273 -- IRQps: 199520 driver: bnx2x version: 1.74.22 driver: bnx2x version: 1.74.22 driver: e1000e version: 2.2.14-NAPI driver: e1000e version: 2.2.14-NAPI driver: e1000e version: 2.2.14-NAPI driver: e1000e version: 2.2.14-NAPI Интела в два раза примерно отличается PPS от IRQPS, а вот с бродкомом что-то не то. :(

Убеждался tcpdump'ом. Указывал адрес wget --bind-address=<ip>. Соль в том, что: а) один и тот же адрес, включенный в один и тот же коммутатор, только на разных железках и в одном случае lacp, а в другом просто один порт - выдают разные скорости в один поток. б) если предположить затык в пути до аплинка - но с него же едет хорошо в обоих случаях в) если предположить затык за ним, то, во-первых, адрес у меня и на одной, и на другой железке то один и тот же, одним и тем же он остается и при запуске закачки в несколько потоков, а скорость чудным образом рождается из бездны. Вот такой вот комок противоречий, потому и не понятно ничего.

Как-то так. Исходные данные: сервер и еще один ПК торчат в одном коммутаторе в одном влане. ПК - одним портом 1Г, сервер транком 1+1Г. Вешаем айпишник на ПК. Включаем закачку: 23% [====================================> ] 553 263 792 34,2M/s ост 53s Скорость летит 30-34Мбайт/с. Перевешиваем айпи на сервер. И уже: 5% [=======> ] 123.050.248 6,13M/s eta 4m 53s Колеблется - в пиках до 10Мбайт, в среднем около 6. Причем полосы на интерфейсах в достатке: eth0: 452.28 Mb/s In 456.11 Mb/s Out - 62037.0 p/s In 67201.0 p/s Out eth1: 500.63 Mb/s In 406.58 Mb/s Out - 71679.0 p/s In 65577.0 p/s Out То есть запаса почти в половину на каждом.

Взорвал себе мозг обнаружив одну интересную закономерность в работе софтроутера. А именно: Есть сервер на двух Xeon E5540. На борту два порта: BCM57711E. Вставлена платка на 4 порта: 82571EB. Два встроенных бродкомовских интерфейса собраны в lacp bonding bond0 и смотрят в сторону интернета (линки по 1Гб). На каждый порт по 4 очереди/прерывания развешаны на 4 ядра первого процессора. Оставшиеся 4 интела собраны в bond1 и смотрят внутрь. Интерапты интелов повешены на 4 ядра второго процессора. CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 68: 250 0 0 0 2093741818 0 0 0 IR-PCI-MSI-edge eth2 73: 161135 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0 75: 1465180138 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-fp-0 76: 16593 3647641664 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-fp-1 77: 4447 0 1497707430 0 0 0 0 0 IR-PCI-MSI-edge eth0-fp-2 78: 9186 0 0 1510644930 0 0 0 0 IR-PCI-MSI-edge eth0-fp-3 79: 161144 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth1 81: 5112 1513929435 0 0 0 0 0 0 IR-PCI-MSI-edge eth1-fp-0 82: 3599112940 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth1-fp-1 83: 5240 0 0 1439802463 0 0 0 0 IR-PCI-MSI-edge eth1-fp-2 84: 4332 0 1462675245 0 0 0 0 0 IR-PCI-MSI-edge eth1-fp-3 85: 227 0 0 0 0 2118178819 0 0 IR-PCI-MSI-edge eth3 86: 228 0 0 0 0 0 2114268794 0 IR-PCI-MSI-edge eth4 87: 225 0 0 0 0 0 0 2156799972 IR-PCI-MSI-edge eth5 Через сервер бегает трафик. На входе (bond0) около 800мбит. Загрузка процессоров далека от 100%. При этом и на самом сервере, и на клиенте за ним, наблюдается следующая история. Тянем в один поток wget'ом с некоторого ftp, стоящего у вышестоящего провайдера. Тяну в 1 поток 11.2мбайта/с (около 100 честных мегабит) как на самом сервере(роутере), так и на клиенте. Берем файл на ftp2.ru.freebsd.org. Видим картинку куда печальнее - в лучшие времена около 4-7мегабайт/с, при большей нагрузке может быть и того меньше. Но что примечательно - стоит потянуть в несколько потоков lftp pget -n 10, например, и видим замечательно скорость около 100мбит/с, а на самом сервере и все несколько сотен. Если же клиентский IP отроутить мимо этого самого софтроутера - закачка в одну сессию становится веселее. Откуда растут вопросы: 1. Где затык? Ведь с некоего одного ftp мы видим в один поток все честные 100мбит, а с некоего другого в один поток ни в какую. При этом как показывают смежные тесты - фтп сервер способен отдавать существено большую скорость в 1 поток, нежели мы наблюдаем в реальности. 2. В какую сторону можно двигаться и куда копать? Стоит две 2-х головых платки таких как ниже. Вроде едут норм. 03:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) Subsystem: Broadcom Corporation Device 1917 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at fa000000 (64-bit, non-prefetchable) [size=32M] Capabilities: [48] Power Management version 3 Capabilities: [50] Vital Product Data Capabilities: [58] MSI: Enable- Count=1/16 Maskable- 64bit+ Capabilities: [a0] MSI-X: Enable+ Count=9 Masked- Capabilities: [ac] Express Endpoint, MSI 00 Capabilities: [100] Device Serial Number 00-10-18-ff-fe-9d-12-26 Capabilities: [110] Advanced Error Reporting Capabilities: [150] Power Budgeting <?> Capabilities: [160] Virtual Channel Kernel driver in use: bnx2 Kernel modules: bnx2 CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 44: 1530325219 0 0 0 0 6 PCI-MSI-edge eth2-0 45: 3512258558 0 0 0 0 3 PCI-MSI-edge eth2-1 46: 0 4248180959 0 0 0 1 PCI-MSI-edge eth2-2 47: 0 0 987437417 0 0 5 PCI-MSI-edge eth2-3 48: 0 0 0 383412068 0 1 PCI-MSI-edge eth2-4 49: 0 0 0 0 841825087 1 PCI-MSI-edge eth2-5 50: 0 0 0 1 0 4040313913 PCI-MSI-edge eth2-6 52: 0 0 0 0 0 1463678266 PCI-MSI-edge eth3-0 53: 0 0 0 0 0 3460050862 PCI-MSI-edge eth3-1 54: 3409670956 0 0 0 1 0 PCI-MSI-edge eth3-2 55: 0 457389160 0 0 0 8 PCI-MSI-edge eth3-3 56: 0 0 446337170 0 0 1 PCI-MSI-edge eth3-4 57: 0 0 0 395466091 0 1 PCI-MSI-edge eth3-5 58: 0 0 0 0 519687263 1 PCI-MSI-edge eth3-6 60: 0 0 0 0 618133199 14 PCI-MSI-edge eth0-0 61: 0 0 0 0 2789380916 23 PCI-MSI-edge eth0-1 62: 0 0 0 0 0 1882917262 PCI-MSI-edge eth0-2 63: 1201784718 0 0 0 2 18 PCI-MSI-edge eth0-3 64: 0 503770750 0 0 0 1 PCI-MSI-edge eth0-4 65: 0 0 283256949 0 0 4 PCI-MSI-edge eth0-5 66: 0 0 0 233077182 0 1 PCI-MSI-edge eth0-6 68: 0 0 0 759127286 1 16 PCI-MSI-edge eth1-0 69: 0 0 0 2933903470 0 8 PCI-MSI-edge eth1-1 70: 0 0 0 0 2873845998 8 PCI-MSI-edge eth1-2 71: 0 0 0 0 0 1043693785 PCI-MSI-edge eth1-3 72: 3520592126 0 0 0 0 10 PCI-MSI-edge eth1-4 73: 0 4151452057 0 0 1 3 PCI-MSI-edge eth1-5 74: 0 0 3994587621 0 0 2 PCI-MSI-edge eth1-6

Прошу просветить в таком вопросе. Есть софт-роутеры под Linux на различном железе, включая как 2 х 4х-головых Ксеона, так и один Коре i7 2600. Для балансировки нагрузки в случае с зионами бондинг на 82571EB c e1000e. На Коре i7 бондинг, включая RSS на 82576 под igb. В итоге - рисуются графики cacti по нагрузке по CPU, трафику на bondX и pps там же. В любой конфе вижу траф до 1.1-1.2Гигабита максимум и не выше 150-160kpps. При этом по CPU по всем ядрам еще имеется idle. А картинка трафика иногда схожа на "полочку". Какие могут быть иные ограничения в kpps? Задачи железяки: tc + hashing filters, частично на трафик nat, ipset, ipt_netflow. Тут же в конфе прочитал про perf top. В любое время суток независимо от нагрузки: kernel:99.4% [100000 cycles] >=98%. Что показывает этот параметр? Гугл не отвечает на мой вопрос.

А за пределами постсоветского пространства? :)))

Не подскажет ли всезнающий All хороших конференций, выставок, семинаров телекоммуникационной направленности в постсоветском пространстве, Европе, мире?

Спасибо. Решил хелпером ftp, но по-моему достаточно nf_conntrack_ftp подгрузить, даже в случае с НАТ.

Доброго времени всем. Озадачился следующим моментом. Нужно запретить пользователям соединения наружу по всем портам, кроме 1-1024, но при этом чтобы работал активный и пассивный режим фтп. Как этого можно достич?

Спасибо. Хоть что-то прояснилось. А то во всех анонсах RPS/RFS, а как и с чем его едят нигде нет. O_o

Выше я писал отчет о результатах тестирования на насе. Коротко - распараллеливание действительно имеется... Кроме описания на LWN есть ссылка на нормальный док по RPS/RFS? А то что-то в тупик меня ставят фразы "включение rfs на 64к записей". Что есть включение и где та самая таблица на 64к записей?

Вы свежими сорцами пользуетесь ? Не поделитесь линком на них ? Модуль с какими параметрами подгружаете ? Сорцы могу кинуть на мыло - пишите в личку адрес. Параметры: echo 8192 > /sys/module/ipfw_mod/parameters/hash_size echo 8192 > /sys/module/ipfw_mod/parameters/dyn_buckets echo 10 > /sys/module/ipfw_mod/parameters/autoinc_step echo 1 > /sys/module/ipfw_mod/parameters/io_fast

Хмм. Полагаю искать штучно такого зверя надо у интеграторов. И то под заказ. В простых магазинах скорее всего такого не сыскать. Скинутый вариант встроен в блейд-сервер HP. Вот, например, опции для DELL R410: http://www1.euro.dell.com/ru/ru/business/%...d&cs=rubsdc Сетевая плата Intel 10GbE Сетевая плата Broadcom 10GbE Думаю как минимум в этом виде можно заказать. Или поискать другие сборки.

02:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM57711E 10-Gigabit PCIe Subsystem: Hewlett-Packard Company Device 7058 Flags: bus master, fast devsel, latency 0, IRQ 40 Memory at f9800000 (64-bit, non-prefetchable) [size=8M] Memory at f9000000 (64-bit, non-prefetchable) [size=8M] [virtual] Expansion ROM at e4010000 [disabled] [size=64K] Capabilities: [48] Power Management version 3 Capabilities: [50] Vital Product Data <?> Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable- Capabilities: [a0] MSI-X: Enable+ Mask- TabSize=17 Capabilities: [ac] Express Endpoint, MSI 00 Capabilities: [100] Device Serial Number 54-31-b7-fe-ff-85-d3-d8 Capabilities: [110] Advanced Error Reporting <?> Capabilities: [150] Power Budgeting <?> Capabilities: [160] Virtual Channel <?> Kernel driver in use: bnx2x Kernel modules: bnx2x Вручную задано 4 очереди: 66: 56124 858265 0 0 985166 3630 650 90250 PCI-MSI-edge eth0 67: 267172806 3575636609 0 0 0 0 0 0 PCI-MSI-edge eth0-rx-0 68: 97 1639428370 100 0 3465715304 0 0 0 PCI-MSI-edge eth0-rx-1 69: 7319531 12993439 237 0 0 0 0 0 PCI-MSI-edge eth0-tx-0 70: 29 530072608 0 2345601238 0 0 0 0 PCI-MSI-edge eth0-tx-1 71: 533 983533 0 0 856775 90041 55746 4116 PCI-MSI-edge eth1 72: 27 0 1830181446 0 0 0 0 0 PCI-MSI-edge eth1-rx-0 73: 111 0 0 1873577924 0 0 0 0 PCI-MSI-edge eth1-rx-1 74: 44739359 0 24481514 0 0 0 0 0 PCI-MSI-edge eth1-tx-0 75: 92404 0 1606315414 31767023 0 0 0 0 PCI-MSI-edge eth1-tx-1

Уже дочитался, что не должно. Написано примерно так "Для поддерживающих аппаратно очереди - появятся очереди". А для неподдерживаемых появится очередь как раз rx-0. Откуда возникают вопросы: 1. Таки кто-то заметил оптимизацию от этого RPS, там где очереди не появились? 2. Почему, если указанный бродком с драйвером bnx2 умеет очереди, они раньше не появлялись ни в каком виде, в том время как 10Г бродком с драйвером bnx2x появлялся в /proc/interrupts в виде интераптов на заданное количество очередей?

Занимательно. На сервере встроенные Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet на драйвере bnx2 - тут видно: # ls -1 /sys/class/net/eth0/queues/ rx-0 rx-1 rx-2 rx-3 rx-4 rx-5 rx-6 rx-7 И не встроенные Intel Corporation 82571EB Gigabit Ethernet Controller на драйвере e1000e, однако: # ls -1 /sys/class/net/eth2/queues/ rx-0 Есть мысли, почему для bnx2 появилось количество очередей = количеству процессорных ядер, а для интеля нет?

Там проблема в вербосити, если не ошибаюсь. Девелоперы делились сорцами новее, чем есть на оффсайте. Они вроде работают стабильно.

Посмотрел. В итоге то ли в силу криворукости, то ли в силу иных причин, вот результаты: 1. Для начала захотелось попробовать режим flow. Прочитав вместо документации, которой нет, коменты в конфиге, что оно работает только с маской 16 для одной подсети - записал для теста подсеть: 10.10.0.0/16. заинитил sc, создался ipset, фильтры и дисциплины. сделал sc add 10.10.1.2 10Mibit и получил все 100Мбит. Есть подозрение, что неверно понимаю логику этого самого flow. Документация есть: man sc и man sc.conf. Собирается из pod и устанавливается в нужные каталоги по make install. Что касается отсутствия шейпинга, подозреваю, что есть проблемы с NAT или перепутаны внутренний/внешний интерфейсы. В принципе уже разобрался, однако решил наваять свое решение под ситуацию. Если будет интересно, то вот почему: 1. Таки не ушли мы еще от абонентиков с серыми айпи. А шейпить надо бы и их. 2. Для u32 скриптом генерирую правила с матчингом по всем октетам, точнее сначала 1й, потом 2й, потом 3й и по четвертому уже заворачиваю в класс. Получается веселее, тем более с учетом, что я не хочу дропать все лишнее, мне нужно зашейпить нужное. Очень негодовал, когда запустил sc с u32 и все заблокировалось. Блокирую ipset+iptables. 3. Шейпить надо так, чтобы часть трафика на определенные адреса не шейпить или шейпить на другой скорости. Итого вывод из всего вышесказанного: 1. Было бы неплохо, чтобы tc filter мог пользоваться ipset или аналогом. Возможно кто-то возьмется припилить такой финт ушами. 2. Учитывая специфику пункта 1 пришлось использовать ifb, а учитывая специфику пункта 3 - теперь готовлю переход на IMQ, ибо в случае с NAT маркировка пакетов в iptables проходит позже, чем я траф заворачиваю на ifb. Обидно. В связи с чем дважды интересен пункт 1 выводов. :) 3. В сухом остатке получается - или ipfw+dummynet собирать для Linux. Или накручивать IMQ, что вообще требует полной пересборки ведра. Вот такая диллема. Не исключаю, что где-то в логике ошибаюсь, прошу поправить ход моих мыслей, если так.

Тема старовата, но я так понял решения адекватного не нашлось, если есть много префиксов, для которых нужно отмаркировать пакетики для парсинга на ifb? Не встречалось ли решения задействовать ipset в фильтрах iproute2?