DemYaN

не совсем точно выразился - интересно, но ничего нового :) В том то и дело - было бы ОЧЕНЬ интересно видеть результат тестов для задач шейпа/ната (для той другой машинки :) ), потому как таких докладов вообще нет. А доклады по простому роутингу (не напичканного netfilter/tc) были и раньше. В особенности это интересно из-за multicore/multiqueue и ограничений QDSIC связанных с этим. А также как netfilter ведет себя на нескольких ядрах и прочее. Вот этого еще не было. Проблемы с масштабированием есть, но они точно будут решаться в будущих ядрах. Разработчики линуксовой сетевой подсистемы работают во Vyatta, делающей роутеры на PC-шном железе, и поэтому в курсе дела. Это же не OpenBSD со сферической безопасностью в вакууме и полным игнорированием реальных проблем. во, и хотелось бы видеть эти проблемы с масштабированием

вот только что будет если навешать htb qdisc с парой тысяч классов или conntrack включить, а просто роутинг - не интересно

pptp-интерфейс: # tc -s -d filter ls dev ppp30 filter parent 1: protocol all pref 2 u32 filter parent 1: protocol all pref 2 u32 fh 801: ht divisor 1 filter parent 1: protocol all pref 2 u32 fh 801::800 order 2048 key ht 801 bkt 0 terminal flowid ??? (rule hit 246 success 246) match 00000000/00000000 at 0 (success 246 ) action order 1: mirred (Egress Redirect to device ifb0) stolen index 1136 ref 1 bind 1 installed 112 sec used 30 sec Action statistics: Sent 58595 bytes 123 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 На нем определенно IP (4500 0028): #tcpdump -enXvi ppp30 14:35:45.216683 Out ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 217.73.200.221.80 > 172.31.2.146.12404: ., cksum 0x8bc2 (correct), ack 687 win 6850 0x0000: 4500 0028 0000 4000 3506 f4f7 d949 c8dd E..(..@.5....I.. 0x0010: ac1f 0292 0050 3074 0ef4 f0ab 1c31 6be2 .....P0t.....1k. 0x0020: 5010 1ac2 8bc2 0000 На IFB куда-то делись 6 6айт: #tcpdump -eni ifb0 14:34:09.301064 40:00:35:06:f4:f7 > 45:00:00:28:00:00, ethertype Unknown (0xd949), length 40: 0x0000: c8dd ac1f 0292 0050 303a 080f 48f9 fcc7 .......P0:..H... 0x0010: a285 5010 1a31 23eb 0000 что-то тут нечисто.... чешу репу :) UPD может дело в datalinktype, который интерпретирует tcpdump? tcpdump: listening on ppp30, link-type LINUX_SLL (Linux cooked) tcpdump: listening on ifb0, link-type EN10MB (Ethernet) но тогда все-равно не понятно, куда делись 6 байт - 4500 0028 0000

ну, как минимум нужно две очереди, иначе куда прикажете деваться трафику который не с меткой 1? нужно пробовать, что-то вроде такого: tc qdisc add dev ppp0 root handle 1: prio bands 2 priomap 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 tc qdisc add dev ppp0 parent 1:1 handle 10: tbf rate 40kbit buffer 1600 limit 3000 tc qdisc add dev ppp0 parent 1:2 handle 11: bfifo tc filter add dev ppp0 parent 1: protocol ip prio 1 handle 1 fw classid 1:1 tc filter add dev ppp0 parent 1: protocol ip u32 match u32 0 0 classid 1:2

нужно accel брать из git: accel-pptp 0.8.4 * supports 2.6.31 kernel * included 430-persist.patch (theMIROn)

Классовая то она классовая, да вот только разблюдовка по классам в ней осуществляется по TOS полю и никак иначе. WTF? priomap "If you do not provide tc filters to classify traffic", the PRIO qdisc looks at the TC_PRIO priority to decide how to enqueue traffic. The kernel assigns each packet a TC_PRIO priority, based on TOS flags or socket options passed by the application. The TC_PRIO is decided based on the TOS

те как-это нельзя вешать дисциплины ? prio такой же classful как и htb

accel-pptp не ядреный?? через pppox-модуль работает же

А может попробовать protocol 0x8864 .... чтоб pppoe заворачивать?

Хм, у меня на куче PPTP-интерфейсов наложен фильтр: tc filter add dev $DEV parent 1: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 > /dev/null 2>&1 и все прекрасно срабатывает, хотя при этом в tcpdump вообще пакеты с неизвестным ethertype: listening on ifb0, link-type EN10MB (Ethernet), capture size 96 bytes 21:20:33.589313 40:00:2e:06:51:4a > 45:00:00:28:38:4e, ethertype Unknown (0x5e64), length 40: 0x0000: b634 ac1f 0280 07f9 04a6 613e 7001 83b8 .4........a>p... 0x0010: 7066 5010 0036 1a69 0000 pfP..6.i..

Я правильно понял что на ifb0 навешен u32 фильтр и он не срабатывает?

на вскидку - до версии 2.6.20 (или 21) с ifb было много глюков

тут вроде как описывается проблема с qdisc http://vger.kernel.org/~davem/davem_nyc09.pdf?, и вроде бы есть какой-то патч авторства Миллера который эту проблему решает, но не красиво

в ipguard'е, к примеру, de:ad:9a:c3:20:7f

тут подробнее http://vger.kernel.org/netconf2009_slides/...rouer_final.pdf

нормальная прокладка уже забыла про PCI-X и использует PCIe :)

аналогично

1. Retracker.local прописывается только в российский сегмент интернета. Сделано это потому что зарубежным товарищам вряд ли придет в голову делать ретрекеры для torrents.ru. Хотя впрочем если вы провайдер, и все таки хотите сделать ретрекер - то просто напишите лс-ку юзернейму retracker и в свободной форме попросите включить в список для выдачи ваши диапазоны IP адресов. Это касается в основном провайдеров из ближнего зарубежья - Украины, Казахстана, Белорусии, прибалтики и т.п. http://torrents.ru/forum/viewtopic.php?t=2234744 отправил ЛС, вот жду

jab кагбе намекает о FreeBSD :)

82541GI - на PCI, да и 82566DM-2 не блещет

Intel® Core2 Duo CPU E8200 @ 2.66GHz EXPI9402PTBLK: 01:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 01:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) # grep eth /proc/interrupts 218: 1182924455 2956915521 PCI-MSI-edge eth1 219: 1722968244 2491800775 PCI-MSI-edge eth0 В данный момент 140M и 27kpps, каждое ядро загружено на 7%: Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 93.0%id, 0.0%wa, 1.3%hi, 5.6%si, 0.0%st Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 92.7%id, 0.0%wa, 2.0%hi, 5.3%si, 0.0%st

Marvell и встроенные сетевые в топку. Берите Intel, лучше E1G42ETBLK.

Еще желательно промониторить стаус-переменные MySQL через SHOW GLOBAL STATUS '%Handler_%'; (лучше загнать в rrd для наглядности), как они выглядят до и после навешивания дополнительной нагрузки.

дык может сами запросы в MySQL требовательны к IO и просто не хватает ресурсов, когда параллельно запущена еще одна тяжелая io-операция?

echo 524288 > /sys/module/nf_conntrack/parameters/hashsize echo 524288 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max # uname -r 2.6.26-1-686