Jump to content
Калькуляторы

IFB egress mirror from pppX interfaces Трабла кто сталкивался?

В общем в процессе работы над прошивкой столкнулся с проблемой невозможности нормально прикрутить IMQ (привернуть то привернул но из-за закрытых моудей есть неисправимые глюки). Решил таки приюзать IFB, поправил сырцы чтобы структуры не съезжали, вставил парочку "фильтров" чтоб wifi не падал при "летящих" на него с ifb пакетов, всё вроде OK.

 

Делаю:

tc qdisc add dev $OUTIFACE ingress

tc filter add dev $OUTIFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

 

Если $OUTIFACE это физический ифейс или скажем vlan то всё ОК, траффик редиректиться, если делам миррор с pppX (pppoe/l2tp/pptp) то видим что редкая птица/пакет долетит до середины днепра (ifb0 ифейса). Разборки показали, что на pppoe mirror на входе получает инкапсулированный в pppoe/l2tp/pptp траффик (в зависимости от типа туннеля) и ессно отсекается match u32.

 

Вот сижу чешу репу что делать. Чинить wifi драйвер с дизасмом или придумывать что-то для ifb или может есть ещё аналоги псевоустройства какие куда модно зарулить ВХОДЯЩИЙ на ифейс туннеля траффик? Кто решал сию проблему? На всякий, ядро 2.6.19.7, обновиться выше не реально держат бинарные блобы и крепко держат.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
на вскидку - до версии 2.6.20 (или 21) с ifb было много глюков

IFB я бэкпортил из 2.6.31, проблема в том что mirror делает ровно то что должен, берёт фрэйм и обрабатывает его заданным классификатором в нашем случае ip u32 который ессно этот фрэйм в жизнь не поймёт т.к. ожидает на входе ip а не ip инкапсулированный в pppoe. На 2.6.31 только что проверил на ноуте - ситуация ровно та же. Вывод egres mirror для обработки входящего потока с pppX интерфейсов туннелей не подходит %( Авторы советуют юзать IMQ, но беда в том, что оно не живёт по селовечьи с блобами от производителя чипа wifi как итог имеем хаотичные потери на всех интерфейсах и чтобы это полечить нуно либо иметь сырцы на руках вайфай модуля либо сидеть с дизасмом что нереально долго с учётом размера кода.

 

Может есть ещё какие-нить псевдодевайсы или другой метод замиррорить ip с ppp+ на ifb или иной другой псевдодевайс?

Share this post


Link to post
Share on other sites

Я конечно дико извиняюсь, но на ядре 2.6.18-164.el5 вот такая вот конструкция работает:

 

/sbin/tc qdisc del dev ppp0 root 1>/dev/null 2>/dev/null

/sbin/tc qdisc del dev ppp0 ingress 1>/dev/null 2>/dev/null

/sbin/ip link set dev ifb0 up 1>/dev/null 2>/dev/null

/sbin/tc qdisc del dev ifb0 root 1>/dev/null 2>/dev/null

 

/sbin/tc qdisc add dev ppp0 root handle 1: htb r2q 10

/sbin/tc class add dev ppp0 parent 1: classid 1:1 htb rate 1095Kbit prio 1 quantum 1514

/sbin/tc class add dev ppp0 parent 1:1 classid 1:101 htb rate 1094Kbit ceil 1095Kbit prio 1 quantum 1514

/sbin/tc class add dev ppp0 parent 1:1 classid 1:102 htb rate 1Kbit ceil 1095Kbit prio 7 quantum 1514

/sbin/tc qdisc add dev ppp0 parent 1:101 sfq perturb 10

/sbin/tc qdisc add dev ppp0 parent 1:102 sfq perturb 10

/sbin/tc filter add dev ppp0 parent 1: protocol ip u32 match ip src 0.0.0.0/0 flowid 1:102

/sbin/tc filter add dev ppp0 parent 1: protocol ip u32 match ip tos 0x10 0xff flowid 1:101

/sbin/tc filter add dev ppp0 parent 1: protocol ip u32 match ip protocol 1 0xff flowid 1:101

/sbin/tc filter add dev ppp0 parent 1: protocol ip u32 match ip protocol 17 0xff match ip sport 53 0xffff flowid 1:101

/sbin/tc filter add dev ppp0 parent 1: protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:101

 

/sbin/tc qdisc add dev ppp0 handle ffff: ingress

/sbin/tc filter add dev ppp0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid ffff: action mirred egress redirect dev ifb0 1>/dev/null 2>/dev/null

 

/sbin/tc qdisc add dev ifb0 root handle 1: htb r2q 10

/sbin/tc class add dev ifb0 parent 1: classid 1:1 htb rate 1095Kbit prio 1 quantum 1514

/sbin/tc class add dev ifb0 parent 1:1 classid 1:101 htb rate 1094Kbit ceil 1095Kbit prio 1 quantum 1514

/sbin/tc class add dev ifb0 parent 1:1 classid 1:102 htb rate 1Kbit ceil 1095Kbit prio 7 quantum 1514

/sbin/tc qdisc add dev ifb0 parent 1:101 sfq perturb 10

/sbin/tc qdisc add dev ifb0 parent 1:102 sfq perturb 10

/sbin/tc filter add dev ifb0 parent 1: protocol ip u32 match ip dst 0.0.0.0/0 flowid 1:102

/sbin/tc filter add dev ifb0 parent 1: protocol ip u32 match ip tos 0x10 0xff flowid 1:101

/sbin/tc filter add dev ifb0 parent 1: protocol ip u32 match ip protocol 1 0xff flowid 1:101

/sbin/tc filter add dev ifb0 parent 1: protocol ip u32 match ip protocol 17 0xff match ip dport 53 0xffff flowid 1:101

/sbin/tc filter add dev ifb0 parent 1: protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:101

 

Share this post


Link to post
Share on other sites

Чем не устраивает обычный ingress policing, работающий без каких-либо IFB? В этой теме http://forum.nag.ru/forum/index.php?showtopic=51367 был неплохой пример как раз для ppp-интерфейсов.

 

tc filter add dev $OUTIFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

Почему здесь какие-то нули? Если нужно заворачивать весь IP-трафик, то наверное лучше так: match ip src 0.0.0.0/0

Edited by photon

Share this post


Link to post
Share on other sites
Чем не устраивает обычный ingress policing, работающий без каких-либо IFB? В этой теме http://forum.nag.ru/forum/index.php?showtopic=51367 был неплохой пример как раз для ppp-интерфейсов.

Тем что у меня 8мь входящих ppp интерфейсов, а шейпить нужно в сторну юзера. Внимательнее прочитайте исходный пост, сказано что это железный мелкий SOHO роутер.

 

tc filter add dev $OUTIFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

Почему здесь какие-то нули? Если нужно заворачивать весь IP-трафик, то наверное лучше так: match ip src 0.0.0.0/0

Нули потому что это пример их документации прекрасно работающий с ethX и нифига не работающий с pppX в виде интерфейса c которого нужно миррорить!!! Мне нужно завернуть с PPP+ на IFB а не шейпить в сторону PPP, вот тут и возникает проблема с тем что match ip не будет отрабатывать т.к. на входе в итоге ip in pppoe. С pptp обшибся там действительно проблем нет. Проблема с kernel level pppoe/l2tp.

 

Ваш пример будет вести себя аналогично.

 

 

Я конечно дико извиняюсь, но на ядре 2.6.18-164.el5 вот такая вот конструкция работает:

ppp0 в вашем случае это что?

 

 

Для понимания процесса http://mailman.ds9a.nl/pipermail/lartc/2007q3/021561.html

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

нет, не срабатывает вот эта строка tc filter add dev $OUTIFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

т.к. protocol там получается не ip, а pppoe что прекрасно видно tcpdump`ом, по ссылке чётко всё расписано.

 

OUTIFACE=ppp0 к примеру который pppoe до аплинка.

Share this post


Link to post
Share on other sites

Хм, у меня на куче 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..

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

А толку если мне нуно будет на ifb разбирать всё это дело, хотя мысль интересная.

А то что у вас срабатывает у мну на pptp тоже срабатывает, а вот на ядреных l2tp/pppoe фигушки, на юзерспэйсных pppoe/l2tp тоже всё отрабатывает как часы. Чую там сам механизм напильника просит.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

pptp срабатывает хоть с ядерным хоть с обычным, с l2tp/pppoe сложнее.

Share this post


Link to post
Share on other sites
Я конечно дико извиняюсь, но на ядре 2.6.18-164.el5 вот такая вот конструкция работает:
ppp0 в вашем случае это что?

В моем случае это pppoe.
Для понимания процесса http://mailman.ds9a.nl/pipermail/lartc/2007q3/021561.html
Прочитал... Проникся... Перепугался и сделал следующий эксперимент (коннекчусь тестовому брасу):

 

[root@bras1 ~]# uname -a
Linux bras1.test 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 athlon i386 GNU/Linux
[root@bras1 ~]# rpm -qa | grep rp-pppoe
rp-pppoe-3.10-1
[root@bras1 ~]# ps ax | grep pppoe-server
2729 ?        S      0:00 /usr/sbin/pppoe-server -k -I eth0 -L 172.26.0.64 -R 172.26.0.65 -N 32 -x 1 -S test
2987 ?        Ss     0:00 pppd plugin /etc/ppp/plugins/rp-pppoe.so nic-eth0 rp_pppoe_sess 1:00:24:8c:73:f2:49 rp_pppoe_service test file /etc/ppp/pppoe-server-options 172.26.0.64:172.26.0.130 nodetach noaccomp nobsdcomp nodeflate nopcomp novj novjccomp default-asyncmap
3044 pts/0    S+     0:00 grep pppoe-server
[root@bras1 ~]# ip addr show dev ppp0
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast qlen 3
    link/ppp
    inet 172.26.0.64 peer 172.26.0.130/32 scope global ppp0
[root@bras1 ~]# modprobe ifb
[root@bras1 ~]# ip link set dev ifb0 up
[root@bras1 ~]# tc qdisc del dev ifb0 root
RTNETLINK answers: No such file or directory
[root@bras1 ~]# tc qdisc add dev ppp0 handle ffff: ingress
[root@bras1 ~]# tc filter add dev ppp0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid ffff: action mirred egress redirect dev ifb0
Action 4 device ifb0 ifindex 6
[root@bras1 ~]# tc qdisc add dev ifb0 root handle 1:0 htb default 12
[root@bras1 ~]# tc class add dev ifb0 parent 1:0 classid 1:1 htb rate 2Mbit
[root@bras1 ~]# tc class add dev ifb0 parent 1:1 classid 1:11 htb rate 1Mbit
[root@bras1 ~]# tc class add dev ifb0 parent 1:1 classid 1:12 htb rate 1Mbit ceil 2Mbit
[root@bras1 ~]# tc filter add dev ifb0 protocol ip parent 1:0 pref 5 u32 match ip src 172.26.0.130 match ip dst 172.26.0.6 flowid 1:11
[root@bras1 ~]# tc filter add dev ifb0 protocol ip parent 1:0 pref 5 u32 match ip dst 172.26.0.6 flowid 1:11

После этого с хоста 172.26.0.130 (хост подключен по pppoe к интерфейсу ppp0) гоню трафик iperf-ом на 172.26.0.6, который являет некстхопом для данного браса.

Имею следующее:

C:\Util>iperf.exe -c 172.26.0.6 -t 30 -i 5
------------------------------------------------------------
Client connecting to 172.26.0.6, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1912] local 172.26.0.130 port 3786 connected with 172.26.0.6 port 5001
[ ID] Interval       Transfer     Bandwidth
[1912]  0.0- 5.0 sec   544 KBytes   891 Kbits/sec
[1912]  5.0-10.0 sec   544 KBytes   891 Kbits/sec
[1912] 10.0-15.0 sec   536 KBytes   878 Kbits/sec
[1912] 15.0-20.0 sec   544 KBytes   891 Kbits/sec
[1912] 20.0-25.0 sec   536 KBytes   878 Kbits/sec
[1912] 25.0-30.0 sec   536 KBytes   878 Kbits/sec
[1912]  0.0-30.2 sec  3.17 MBytes   881 Kbits/sec

На барасе вижу следующее:

[root@bras1 ~]# tc -s -d class show dev ifb0; tc -s -d filter show dev ifb0
class htb 1:11 parent 1:1 prio 0 quantum 12500 rate 1000Kbit ceil 1000Kbit burst 1725b/8 mpu 0b overhead 0b cburst 1725b/8 mpu 0b overhead 0b level 0
Sent 3477264 bytes 2440 pkt (dropped 0, overlimits 0 requeues 0)
rate 563224bit 49pps backlog 0b 0p requeues 0
lended: 2440 borrowed: 0 giants: 0
tokens: -5359 ctokens: -5359

class htb 1:1 root rate 2000Kbit ceil 2000Kbit burst 1850b/8 mpu 0b overhead 0b cburst 1850b/8 mpu 0b overhead 0b level 7
Sent 3499095 bytes 2519 pkt (dropped 0, overlimits 0 requeues 0)
rate 567224bit 50pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: -1135 ctokens: -1135

class htb 1:12 parent 1:1 prio 0 quantum 12500 rate 1000Kbit ceil 2000Kbit burst 1725b/8 mpu 0b overhead 0b cburst 1850b/8 mpu 0b overhead 0b level 0
Sent 21831 bytes 79 pkt (dropped 0, overlimits 0 requeues 0)
rate 24bit 0pps backlog 0b 0p requeues 0
lended: 79 borrowed: 0 giants: 0
tokens: 13352 ctokens: 7176

filter parent 1: protocol ip pref 5 u32
filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:11  (rule hit 2445 success 2440)
  match ac1a0082/ffffffff at 12 (success 2445 )
  match ac1a0006/ffffffff at 16 (success 2440 )

Т.е. наблюдается явное попадание в фильтр и заворачивание трафика в класс 1:11 на интерфейсе ifb.

 

При аплоаде трафика в Интернет (т.е. за хост 172.26.0.6) наблюдается скорость 1.85 МБит/сек и явное попадание в дефолтный класс 1:12.

 

[root@bras1 ~]# tc -s -d class show dev ifb0; tc -s -d filter show dev ifb0
class htb 1:11 parent 1:1 prio 0 quantum 12500 rate 1000Kbit ceil 1000Kbit burst 1725b/8 mpu 0b overhead 0b cburst 1725b/8 mpu 0b overhead 0b level 0
Sent 3477264 bytes 2440 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 2440 borrowed: 0 giants: 0
tokens: -5359 ctokens: -5359

class htb 1:1 root rate 2000Kbit ceil 2000Kbit burst 1850b/8 mpu 0b overhead 0b cburst 1850b/8 mpu 0b overhead 0b level 7
Sent 5334893 bytes 7396 pkt (dropped 0, overlimits 0 requeues 0)
rate 11416bit 4pps backlog 0b 0p requeues 0
lended: 501 borrowed: 0 giants: 0
tokens: 7176 ctokens: 7176

class htb 1:12 parent 1:1 prio 0 quantum 12500 rate 1000Kbit ceil 2000Kbit burst 1725b/8 mpu 0b overhead 0b cburst 1850b/8 mpu 0b overhead 0b level 0
Sent 1857629 bytes 4956 pkt (dropped 35, overlimits 0 requeues 0)
rate 11416bit 4pps backlog 0b 0p requeues 0
lended: 4455 borrowed: 501 giants: 0
tokens: 13256 ctokens: 7176

filter parent 1: protocol ip pref 5 u32
filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:11  (rule hit 7357 success 2440)
  match ac1a0082/ffffffff at 12 (success 7357 )
  match ac1a0006/ffffffff at 16 (success 2440 )

 

Результаты замера скорости несколько ниже заявленных, но я думаю что данное явление можно отнести на счет того, что вся тестовая система крутится на VMware.

 

Т.е., как по мне, ожидаемые результаты достигнуты. - Что я делаю не так?

Edited by Jugernault

Share this post


Link to post
Share on other sites

А вам в голову не приходило что 2.6.18-164.el5 (это кто шапка?) моги это и пофиксить или сломали после 18го.. Nuclearcat повторил и подтвердил багу. Багрепорт отправлен. Считайте что вам повезло.

Share this post


Link to post
Share on other sites
А вам в голову не приходило что 2.6.18-164.el5 (это кто шапка?) моги это и пофиксить или сломали после 18го..
Это CentOS 5.3.

Приходило конечно - просто я не могу понять на каком этапе у Вас затык происходит?

Nuclearcat повторил и подтвердил багу. Багрепорт отправлен. Считайте что вам повезло.
В ближайшее время проверю на 2.6.30.

Share this post


Link to post
Share on other sites

Центось уже не шапка, асп уже не федора =) Ну ну. Затык локализован буду разбираться по коду дальше, ядро сменить не выйдет, бинарные блобы увы и ах.

Share this post


Link to post
Share on other sites

Пара мыслей по вопросу.

Пример tc filter add dev $OUTIFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

работает в 2.6.25.17 с iproute2-ss080417 - возможно в более поздних версиях iproute2 чего-то наломали.

При этом tcpdump на ifbX действительно показывает инкапсулированный трафик, но tc filter работает :)

Share this post


Link to post
Share on other sites

попробуйте теперь навесить на ibf пару фильтров по src/dst адресам. Сработает?

У меня как на 2.6.31 так и на 2.6.19 наблюдается бага хот и несколько по разному проявляется.

Share this post


Link to post
Share on other sites

в netdev сказали могут сделать патч, если очень хочится, но это неправильно

Лучше шейпить типа такого:

/sbin/tc filter add dev eth1 protocol 0x8864  parent 2:0 prio 1 u32 \

match u32 0x$IPREMOTE_HEX 0xffffffff at 24 flowid 2:$ID

 

Share this post


Link to post
Share on other sites

Не совсем понял что предлагается накостылить. А вот патч нужен однозначно. Неплохо бы иметь при сборке ядра возможность выбора поведения. Почему неправильно не пояснили?

Share this post


Link to post
Share on other sites

Многим нужно аккаунтить траффик с заголовками.

Если их отрезать - то у них такой возможности не будет вообще.

Если не отрезать - то неудобно нам, но именно просто неудобно, не более того, приходится задавать offset.

Share this post


Link to post
Share on other sites

Почему не сделать возможность выбора алгоритма при загрузке модуля? Неудобно это слабо сказано, учитывая что один и тотже ифейс может быть как pppoe так и l2tp и прочие, т.е. при автоматизации этого дела придётся городить проверки и выставлять офсет для каждого из возможных типов. В общем изврат. Таки возможность выбора алгоритма при загрузке модуля было бы более удобно, ну или выбор алгоритма при сборке ядра.

Share this post


Link to post
Share on other sites

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

Edited by DemYaN

Share this post


Link to post
Share on other sites
попробуйте теперь навесить на ibf пару фильтров по src/dst адресам. Сработает?

У меня как на 2.6.31 так и на 2.6.19 наблюдается бага хот и несколько по разному проявляется.

Сейчас работают фильтры по протоколу и размеру пакета. Добавил по src адресу:

tc filter add dev ifb1 parent 1:1 protocol ip prio 1 u32 match ip src 213.180.204.8 flowid 1:6 - тоже работает

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this