FWD IMQ mail on netdev

----- Forwarded message from jamal <[email protected]> -----

X-Original-To: sebek@localhost
X-Received-Date: Mon, 12 Apr 2004 03:25:37 +0200 (CEST)
Subject: (Long) ANNOUNCE: IMQ replacement WAS(Re: [RFC/PATCH] IMQ port to

	2.6

From: jamal <[email protected]>
Reply-To: [email protected]
To: "Vladimir B. Savkin" <[email protected]>
Cc: [email protected]
Organization: jamalopolis
X-archive-position: 4611
X-ecartis-version: Ecartis v1.0.0
X-original-sender: [email protected]
X-list: netdev
X-UIDL: 1081733138.87482_0.m1.post.cz,S‚83

Hello,

Following up on a 3 month old email ;->

I finally hacked dummy device as a good replacement (IMO) for IMQ. I am only subscribed to netdev so if there are other lists which are of interest to this subject please forward on, but make sure responses make it to netdev.

Well, why dummy you ask? Because it is such dumb a device ;-> Ok, that may not be funny enough, how about:
because nobody has touched the dummy device in 10 years - that cant be right in Linux. On a serious note though, because i didnt think it was worth writting another device for this. Dummy continues to work the same way when not used with tc extensions. Like i said in my email at the bottom that IMQ was just at the wrong abstraction layer. The dummy extension can now pick ANY packets (not just IP and requiring to attach to a few hooks to get IPV6, arp etc)
Of course all this needs the tc extensions (which has a lot of other features that i wont discuss here).

Why dont i show an example:

----
export TC="/sbin/tc"
#
#attach prio qdisc to the dummy0 device
#
$TC qdisc add dev dummy0 root handle 1: prio
$TC qdisc add dev dummy0 parent 1:1 handle 10: sfq
$TC qdisc add dev dummy0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000
$TC qdisc add dev dummy0 parent 1:3 handle 30:
sfq

# redirect packets coming in with fwmark 1 to class 1:1 (sfq)
$TC filter add dev dummy0 protocol ip pref 1 parent 1: handle 1 fw
classid 1:1
#redirect packets tagged with fwmark 2 to 1:2 (tbf)
$TC filter add dev dummy0 protocol ip pref 2 parent 1: handle 2 fw
classid 1:2

#bring up dummy0
ifconfig dummy0 up

#watch the ingress of eth0;
$TC qdisc add dev eth0 ingress

# redirect all IP packets arriving in eth0 to dummy0
# use mark 1 --> puts them onto class 1:1
$TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
match u32 0 0 flowid 1:1 \
action ipt -j MARK --set-mark 1 \
action mirred egress redirect dev dummy0

# note, the above just shows eth0 and only at ingress;

# you could repeat this on egress/ingress of any device
# and redirect to dummy0 if you wanted;

A Little test:

from another machine ping so that you have packets going into the box:
-----
[root@jzny action-tests]# ping 10.22
PING 10.22 (10.0.0.22): 56 data bytes
64 bytes from 10.0.0.22: icmp_seq=0 ttld time=2.8 ms
64 bytes from 10.0.0.22: icmp_seq=1 ttld time=0.6 ms
64 bytes from 10.0.0.22: icmp_seq=2 ttld time=0.6 ms

--- 10.22 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.6/1.3/2.8 ms [root@jzny action-tests]#

Now look at some stats:
-----

[root@jmandrake]:~# tc -s filter show parent ffff: dev eth0
filter protocol ip pref 10 u32
filter protocol ip pref 10 u32 fh 800: ht divisor 1
filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0
flowid 1:1
   match 00000000/00000000 at 0
         action order 1: tablename: mangle  hook: NF_IP_PRE_ROUTING
         target MARK set 0x1
         index 1 ref 1 bind 1 installed 4195sec  used 27sec
          Sent 252 bytes 3 pkts (dropped 0, overlimits 0)

action order 2: mirred (Egress Redirect to device dummy0) stolen index 1 ref 1 bind 1 installed 165 sec used 27 sec
Sent 252 bytes 3 pkts (dropped 0, overlimits 0)

[root@jmandrake]:~# ifconfig dummy0
dummy0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00
           inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
           UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
           RX packets:6 errors:0 dropped:3 overruns:0 frame:0
           TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:32
           RX bytes:504 (504.0 b)  TX bytes:252 (252.0 b)
-----

Note the three extra received packets on dummy0 were ndisc packets sent by the stack when it booted up (which would normally be dropped - they were). Also, the mirred action can do a _lot_ more, but thats not the point of this email. Send me private email if you want to know more. Additionaly note: the ipt report of NF_IP_PRE_ROUTING is a lie since this happens waaay before IP.
This has been tested on both uni and smp machines. Unfortunately, the code is only available for 2.4.x (2.4.25 patches available - more vigorous testing happened on 2.4.21 - my two machines above)

What am i looking for?
1) users and authors of IMQ to tell me if this achieves what IMQ started as. I have to say I DONT like the level of obstrutiveness from IMQ as is today. The code added by this is small (100 or less lines on top of dummy) and doesnt touch any of the main core bits.
2) testing of the above by people who use IMQ
3) If someone has better ideas - i am not religious about keeping this; but it certainly cant be the blasphemy that IMQ introduces.

I have also introduced hooks to easily add a -i <input dev> to tc classifiers - still on the TODO list. So on the egress you could now classify based on which incoming device the packet arrived on.

cheers,
jamal

class

classes,

----- End forwarded message -----

_______________________________________________
LARTC mailing list / [email protected]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

..

..

..

Hello,

I would like to test your patch. Can you please point me to the place, from which it can be downloaded? I have a terrible experience with Patrick McHardy's IMQ on NATing firewalls (kernel panics randomly etc) and a very good experience with the very same IMQ on an ethernet bridge (rock solid for one year).

I can share the results of the test with netdev ml.

Thanks!

Martin Volf