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

stasn1

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

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

  • Посещение

Все публикации пользователя stasn1


  1. Мне, например, не нужна высокая производительность при отправке резетов/редиректов. Поэтому для этих отправок и управления сервером использую вланы на одной сетевой. Подправил немного исходники и ExtFilter (DPDK) сам создает при запуске tap интерфейс для отправок, который потом биндится на нужный мне влан.
  2. Можно же завернуть неTCP трафик фильтром с меньшим номером в класс без шейпера на нем... А вместо drr можно, наверное, соорудить дерево из HFSC или HTB если нужно резать и суммарную полосу.
  3. dev=imq0 tc qdisc del dev $dev root tc qdisc add dev $dev handle 1025: root drr for i in $(seq 1 1024); do h=$(printf %x $i) tc class add dev $dev parent 1025: classid 1025:$h drr tc qdisc add dev $dev parent 1025:$h handle $h: netem rate 1Mbit done tc filter add dev $dev protocol ip handle 1025 parent 1025: flow hash keys src,dst,proto,proto-src,proto-dst divisor 1024 perturb 10
  4. Испытал на себе тоже, сегодня. Откатился на ядро 3.16.7-992-generic. И все отлично, извините за флуд. Но на 4.x ветке что-то поломали.... Хотелось бы комментарий .... Спецов :) Тоже столкнулся. Вычислил, что баг появился после коммита eb3b85388944b4e15b6db2db99d136f538384c4e - preparation for DPDK intergation (part 7). У себя временно вылечил вот так: --- a/accel-pppd/ppp/ppp.c.orig 2016-05-31 15:46:37.000000000 +0300 +++ b/accel-pppd/ppp/ppp.c 2016-05-31 15:47:33.046457966 +0300 @@ -353,7 +353,7 @@ while(1) { cont: ppp->buf_size = net->read(h->fd, ppp->buf, PPP_BUF_SIZE); - if (ppp->buf_size < 0) { + if (ppp->buf_size < 1) { if (errno != EAGAIN) { log_ppp_error("ppp_chan_read: %s\n", strerror(errno)); ap_session_terminate(&ppp->ses, TERM_NAS_ERROR, 1); @@ -401,7 +401,7 @@ while (1) { cont: ppp->buf_size = net->read(h->fd, ppp->buf, PPP_BUF_SIZE); - if (ppp->buf_size < 0) { + if (ppp->buf_size < 1) { if (errno != EAGAIN) { log_ppp_error("ppp_unit_read: %s\n",strerror(errno)); ap_session_terminate(&ppp->ses, TERM_NAS_ERROR, 1); Ядро - 4.4.12.
  5. Я уже писал выше про подобный вариант. Сейчас рулю у себя по метке skb->priority, но можно и fwmark как доп.вариант.
  6. можно сразу как-то так -m ndpi --proto http,http_proxy,http_connect,ssl -j CLASSIFY --set-class 1:10 -m ndpi --proto ftp_control,ftp_data -j CLASSIFY --set-class 1:11 -m ndpi --proto bittorrent -j CLASSIFY --set-class 1:12
  7. Говорю же: грязный хак. ) - addr = ip_hdr(skb)->daddr; + addr = skb->priority; Оба - целые 32битные числа. Дальше сервисная связка, например, a027 соответствует у меня qdisc 10:a027. Путем нехитрых манипуляций она превращается в ip-адрес 39.160.16.0 (я прямо в селекте из базы конвертирую). Ну а дальше этот адрес добавляю в правило.
  8. Почему же лишнее?! В моем случае при использовании шейпера на tc qdisc фильтр просто перемещается из tc filter в ipset/iptables. Даже, наверное, учитывая то, что в один qdisc может залетать несколько ip/net (т.е. нужно было несколько фильтров), то и некая оптимизация что ли получается. Да и проще само по себе так, по-моему. Я для собственных нужд только что добился нужного функционала от ipt_ratelimit при помощи грязного хака и пары костылей, заменив полстрочки в исходниках. Проверил - раскидывает по правилам по номеру сервисной связки. )
  9. У меня аналогичная ситуация, возможное универсальное решение описал выше. В моем случае это "ipset add clients 1.1.1.0/30 skbprio 10:b552", где $b552 - это и есть номер сервисной связки. И таких элементов в ipset с одинаковым номером может быть несколько. Потом этот номер копируется в поле skb->priority по "iptables ... -j SET --map-set clients dst --map-prio" и как результат сразу летит в нужный класс шейпера без какого-либо фильтра в нем. Было бы идеально если бы появилась такая возможность сразу по skb->priority заруливать трафик в нужное правило и в ipt-ratelimit.
  10. Каким образом? Мне, например, сразу представилась следующая схема: Сейчас я для шейпера на tc через -j SET --map-set anyname dst --map-prio (или map-mark) некой группе адресов, сетей назначаю сразу номер класса в шейпере, несколько разных адресов могут иметь одинаковый номер класса, так как принадлежат одной и той же услуге. Что избавляет от необходимости использовать потом "tc filter". В моем случае было бы идеально сделать возможность задавать полосы в xt_ratelimit не только по списку одиночных ip-адресов (или подсетей когда реализуются префиксы), но и по номеру в skb->priority (и skb->mark). А то сейчас мало того что приходится каждую подсеть парсить в список отдельных адресов, так еще если у клиента несколько таких сетей-адресов, то и склеивать потом в кучу все это. Например, можно сделать пару доп.режимов кроме mode dst,src - mode prio & mark. А в /proc кроме(или вместо) адресов - prio:MIN (или MAJ+MIN) или mark:XXXX. Это бы позволило при желании вынести логику раскидывания по полосам за пределы xt_ratelimit, и уже извращаться там как душа пожелает: различать, например, не только адреса, но и протоколы, порты, да что угодно, вешая метки через CLASSIFY и MARK. Плюс в таком режиме и самому модулю, наверное, проще будет: не нужно сначала парсить адреса в правиле, загонять в хэш, а потом по хэшу сверять пролетащие пакеты. Тут просто по сути номер правила сравнивается с определенным полем в skb.
  11. А как обстоят дела с внедрением поддержки префиксов?
  12. Попробовал транк - та же беда. Гента - unstable или stable? Можно увидеть emerge --info? Unstable. Там вывод большой, могу на мыло. Я, правда, ебилд правил под себя когда-то, особенно в части сборки ядреных модулей.
  13. У меня тоже самое, это если собирать версию из git. При этом релизный 1.10.0 собирается без проблем. accel-cmd -V accel-cmd 343af33b08ebc83791fd57a1ccdef91ce1ac2a9e т.е. последний коммит из мастер ветки. Тоже Gentoo, ядро 4.3, все собирается, в т.ч новый vlan_mon модуль.
  14. Последняя версия, пару дней уже как, ядро 4.2.3. Записей, правда, не очень много. Полет нормальный!
  15. Подсети были бы очень кстати. Пока приходится парсить подсеть на отдельные адреса при добавлении, что не совсем удобно. В остальном все просто замечательно. Огромное спасибо за идею и реализацию!
  16. add basic mpls support to iproute http://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=dacc5d4197c1f8ac12938a594f7e4131cb937cb2
  17. я сталкивался http://forum.nag.ru/forum/index.php?showtopic=45266&view=findpost&p=1102294
  18. Уточнение - задвоение трафика на ipoe интерфейсе (оригинал на dst mac ff:ff:ff:ff:ff:ff + копия на mac gateway хоста в TEE) просходит только если он поднят по start=up (неклассифицированному пакету), при start=dhcpv4 всё нормально, при том что все остальные настройки в accel для принимающих вланов идентичны. В результате дублирования трафика шейпер на ipoe-интерфейсе естественно работает некорректно. Реально ли это как-то поправить?
  19. Такой нюанс вылез: при использовании -j TEE --gateway x.x.x.x --oif vlanXXX для зеркалирования - трафик на ipoe интерфейсах удваивается....
  20. Подтверждаю, уже думал сам багрепорт строчить... )
  21. тоже самое на 3.11.х написал на гитхабе.... но при повторной загрузке модуля (rmmod/modprobe) ошибка не выскакивает
  22. не компилируется с новыми хидерами от ядра 3.4 похоже из-за https://lkml.org/lkml/2012/3/4/145
  23. попробуйте последний комит: commit aff9450a3b95e848f761533a4c659269477a2fd4 Author: Kozlov Dmitry <xeb@mail.ru> Date: Wed May 2 14:30:37 2012 +0400 ppp: implemented adaptive lcp echo functionality в конфиг нужно написать: [ppp] echo-interval=10 echo-timeout=60 После обновления до этого коммита словил уже два сегфолта за три дня accel-pppd[3375]: segfault at 0 ip (null) sp 00007f05b9737db8 error 14 in accel-pppd[400000+1d000] accel-pppd[1380]: segfault at 0 ip (null) sp 00007f069b1f0db8 error 14 in accel-pppd[400000+1d000]