Frequently Asked Questions About IMQ

There's an official FAQ page at http://www.linuximq.net/faq.html , don't forget to check that page also.

Use of IMQ

What can I do with IMQ?

The IMQ device has two common uses:

Ingress shaping, using egress qdiscs:

There are real ingress qdiscs, but their functionality is rather limited. On the other hand, there are the egress qdiscs (like HTB, prio, ...) that are very flexible and efficient.

With IMQ you can use these egress qdiscs to shape igress traffic, while retaining all the power of these egress qdiscs. You may also became | certified editor if use IMQ in right direction.

Shaping over multiple interfaces:

You can attach a qdisc to only one interface. You can attach the same kind of qdisc to many interfaces, but these qdisc instances are not in any relation to each other: they share no state, no information exchange occurs between them. That is, you can't limit eg. the sum of bandwidth going through the qdiscs on different interfaces; you can only limit them individually.

When it is desired that you put one qdisc in the flow of traffic coming from (or going to) multiple interfaces, you have IMQ to do that. With IMQ you are not restricted to physical interfaces to attach qdiscs to.

Stability

How stable is IMQ?

It is stable, both on 2.4 and 2.6 kernels. There are reports from IMQ being used in different scenarios with large traffic without problems.

However, on 2.6-series kernels, directing locally generated traffic (including IPsec, GRE tunnels, ... besides traffic generated by userspace programs) into an IMQ device leads to kernel panics. The issue is being worked on currently (2005-09), hope it will be fixed soon. Until then, you should avoid this by appropriate iptables rules.

Eg.: Samba traffic counts as "locally generated". Using folowing lines, that problem is solved:

  iptables -t mangle -A POSTROUTING -o eth0 -s ! 192.168.100.100 -j IMQ --todev imq0
  iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev imq0

In the past there were problems using IMQ on 2.6 kernels as modules and those issues were solved on patch linux-2.6.7-imq1 or newer ones.

Why IMQ is not in the official kernel tree? (Well, if IMQ is stable, then why isn't it included in the official kernel tree?)

The main reason is that IMQ is just a 'quick hack' to solve some existing problems, and theoretically is wrong. Wrong, because (at the kernel people's opinion) this functionality should not be implemented at the level of the networking stack where IMQ is now. Really, there's a guy (namely, Jamal) working on stuffing similar functionality into the dummy device driver (and so bypassing the netfilter hack of IMQ). This thread on linux-netdev list discusses the question: http://marc.theaimsgroup.com/?t=108202471500003&r=1&w=2 Note that Jamal's theoretically correct approach does not provide the full possibilities of IMQ. By moving the ingress traffic-shaping to the device layer, no connection tracking/marking information can be used for classification of packets. The entire classification power of netfilter is inaccessable at the point where Jamal's patches provide shaping. You should also check OtherImqDocs page for fresh links. But until that driver (and its userspace counterparts) become as stable and mature as IMQ is now, there's IMQ as the only stable choice.

Other, much less important reasons are that IMQ was dead for a long time, and some people still consider it being so.

OK, but have You tried including it in POM (patch-o-matic - netfilter.org) ?

Most distros use POM to patch their kernels. They do not use all the POM's patches in the kernels, but try to include as much as possible in their iptables packages. I think it is a good idea to make IMQ part of POM. (Note, this is still just a question, no answer provided).

I heard about other IMQ implementations. How are they related to this project?

First some short history of IMQ:

The idea of IMQ came from Martin Devera (aka. devik). He wrote the first version of the IMQ kernel part and userspace part.

Some time later Patrick McHardy took over the project. After some time he left it, too. The project seemed to be died.

Then a group of people (those are we:-) started to keep the project alive. With contributions from many people, the patches have always been available for every new kernel version in the 2.4 series from 2.4.21, and in the 2.6 series from 2.6.1. Usually it took only a few days before we came up with the new patch for the freshly released kernel versions. Iptables versions have being updated quickly as well, following netfilter releases.

While the original implementation seemed to die out, some people (independently of each other) started to rewrite the kernel part from scratch. Their goals and success are varying, see OtherImqDocs. They use the same userspace part as we, did not rewrote that.

We believe that our project (the original implementation) is the most stable, mature and most widely known of all the IMQ implementations (while it may be that not the most effective, or so). And also we are the most up-to-date regarding new kernel and iptables versions.

Should I not compile IMQ as a kernel module? (I read somewhere that IMQ as a kernel module does not compile/work.)

No, that's not true anymore. You can use IMQ as module safely:

Under 2.4 compiling (and using) IMQ as a dynamically loadable kernel module is perfectly fine and heavily tested.

Under 2.6 if you use patch linux-2.6.7-imq1 or newer ones you are OK, modules work fine.

If you are still using older patches there were problems:

• compiling IMQ device driver (imq.o) as a kernel module caused the kernel compilation to stop with an error; this issue was solved ages ago
• unloading (=rmmod='ing) the IMQ device driver module (imq.o) caused a kernel panic; this issue has been solved also
• when used as a kernel module, the IMQ driver did nothing; this issue came from the previous (kernel panic when unloading), and has been solved

We recommend not using any IMQ patch earlier than linux-2.6.7-imq1 (for 2.6 kernels) or linux-2.4.26-imq.diff (2.4 kernels). (These patches apply on earlier versions as well, than their names suggest.)

Tuning

I need more than two IMQ devices. How can I create more?

The trivial way is to modify the source ( numdevs variable in linux/drivers/net/imq.c) and recompile your kernel. (With the new 2.6 patch - currently beta - , it is now possible to set it from the kernel configuration.) But that's too clumsy. Note that if you ever need more than 16 devices, there is no other option than to dive into the source code, because there is a hard-coded limit: #define IMQ_MAX_DEVS 16.

Remember, you can set the number of imq devices (imq0, imq1, ...) before the IMQ device driver is initialized.

That means that if you use IMQ as

• compiled into kernel, you can give (via your bootloader) your kernel the parameter imq.numdevs = n (of course, without any spaces on both sides of the equal sign), where n is the number of devices you want
• loadable kernel module, you can give modprobe the parameter numdevs = n (of course, without any spaces on both sides of the equal sign), where n is the number of devices you want. Remember, that first you have to unload the module, to load it with a different numdevs parameter.

You can safely initialize IMQ with more devices created than is actually used. The only disadvantage is some dozen of bytes kernel memory allocated per device.

And lastly a tip: Are you sure do you really need that many IMQ devices? It is common that people misinterpret something, and think that their problem needs a dozen IMQ devices. Ask on the list, if you're not sure.

When does IMQ (and filters attached to the IMQ device) see the packets - relative to NAT?

The default behaviour is that in PREROUTING, IMQ sees the packets before NAT, and in POSTROUTING, IMQ sees packets after NAT. But see Can I change the way IMQ hooks in netfilter?.

With the default behaviour, on a NATing (masquerading) machine, you should set up your IMQ devices like this, to enable QoS u32 filters to see packets before NAT (that is, classify according to private IP addresses):

If eth1 is the interface facing the network with private addresses, then you should say:

iptables -t mangle -A PREROUTING -i eth1 -j IMQ --todev 0
iptables -t mangle -A POSTROUTING -o eth1 -j IMQ --todev 1

Now QoS u32 filters attached to imq0 and imq1 both see the private IP addresses of packets originating from, or going to your private network, accordingly.

Can I change the way IMQ hooks in netfilter? (Can I make IMQ see packets in PREROUTING/POSTROUTING before/after (de)NAT?)

Yes, you can.

With 2.6 series kernels, you can easily change it at configuration time. (Look at Device drivers_/_Networking support_/_IMQ behavior (PRE/POSTROUTING).)

With 2.4 series kernels, currently the only way is to edit the source, and recompile your kernel.

To hook after NAT in PREROUTING: find the priority member (the last member) of the imq_ingress_ipv4 structure in linux/drivers/net/imq.c, and change from NF_IP_PRI_MANGLE + 1 to NF_IP_PRI_NAT_DST + 1. Similarly, change the priority member (last member, too) of imq_ingress_ipv6 from NF_IP6_PRI_MANGLE + 1 to NF_IP6_PRI_NAT_DST + 1.

To hook before NAT in POSTROUTING: find the priority member (the last member) of the imq_egress_ipv4 structure in linux/drivers/net/imq.c, and change from NF_IP_PRI_LAST to NF_IP_PRI_NAT_SRC - 1. Similarly, change the priority member (last member, too) of imq_egress_ipv6 from NF_IP6_PRI_LAST to NF_IP6_PRI_NAT_SRC - 1.

There's a patch (http://www.linuximq.net/patchs/imq-nat.diff) which does this for IPv4. You can apply that patch after patching with the IMQ patch. (Or look at the ImqDevelCorner, there will be soon patches implementing the functionality backported from 2.6 patches.)

I read on the list that there's a beta stability patch implementing XXXYYY. I'd like to try it. Where can I download it from?

There's an ImqDevelCorner in this Wiki. You can find the latest testing (beta) patches there, and there you can follow the development issues.

If you are willing to help us in the testing or the development, please contact us on the ImqMailingList.

Problems

IMQ does not work for me. I set up everything, got no error, but the qdisc's/classes attached to the IMQ device(s) get no packets.

Some common mistakes:

• forgot to bring the IMQ interface(s) up (commands like ip link set imq0 up)

The IMQ patch has a hunk failed on skbuff.h when applying on my 2.4 kernel. I'm using a kernel-source-2.4.*.deb package from Debian.

Debian's kernel-source-* packages are not the same as the vanilla kernel.org kernels. These kernels have some patches applied on them (eg. patches for discovered exploits).

In that particular case, the __unused member is used up by one of those patches, and then you have to allocate a new member for IMQ.

You can make the changes by hand (on that particular file), or follow the instructions at http://debian.nix.hu/projects/kernel-patch-imq/index.html#use . Or may ask for advice some | certified editors if there are any.

I got kernel panics when using IMQ. I'm using 2.6.8.1 (or 2.6.8) kernel.

Well, It's not IMQ's fault. It's a bug in the kernel, which will trigger kernel panic when using the QoS facilites.

See http://www.ussg.iu.edu/hypermail/linux/kernel/0408.1/2291.html or google around.

I got kernel panics when using IMQ. I'm using a 2.6-series kernel (but not 2.6.8 or 2.6.8.1).

Make sure you do not send locally generated traffic (traffic generated by userspace programs or the kernel itself - eg. GRE, IPsec tunnels) into the IMQ device. There's a known bug affecting 2.6-series kernels, see How stable is IMQ?

Make sure you use the latest stable patches and a sensibly recent kernel, and that the patch matches the kernel.

' kernel: ip_queue: initialisation failed: unable to create queue ' message in kernel log.

The IMQ device feeds itself packets through netfilter queueing mechanism. At the moment there can only be one netfilter queue per protocol family so this means IMQ came first and ip_queue (or ip6_queue) cannot register as PF_INET(6) netfilter queue.

' kernel: ip6_queue: initialisation failed: unable to create queue ' message in kernel log.

See 'kernel: ip_queue: initialisation failed: unable to create queue' message in kernel log..

' kernel: nf_hook: Verdict = QUEUE. ' messages in kernel log.

You have compiled your kernel with netfilter debugging on ( CONFIG_NETFILTER_DEBUG=y). Turn it off and recompile the kernel to get rid of these messages.

Iptables say ' iptables v1.2.6a: Couldn't load target `IMQ':/usr/local/lib/iptables/libipt_IMQ.so: cannot open shared object file: No such file or directory ' or similar when I'm trying to use the IMQ target ( -j IMQ).

You haven't patched/built/installed iptables correctly. Iptables consists of the iptables binary, plus some shared library ( .so) files, one for each target.

• Perhaps the shared libs didn't built (check the existence of libipt_IMQ.so in the source tree, to ensure it's built).
• Maybe you (or the install script) forgot or failed to install it in the right place.
• Perhaps your iptables binary looks for the shared libs somewhere else than you supposed.
• Don't forget to remove your old iptables installation before installing the new one (it's common mistake that the old one is found in the path before the patched one).
• Perhaps you have tried to compile Iptables without giving the sripts execution permisions. Try chmod u+x extensions/.IMQ-test and chmod u+x extensions/.IMQ-test6
  

Compile error ( structure has no member named `imq_flags')

Make ends in:

  CC      net/ipv4/netfilter/ipt_IMQ.o

net/ipv4/netfilter/ipt_IMQ.c: In function `imq_target':

net/ipv4/netfilter/ipt_IMQ.c:19: error: structure has no member named `imq_flags'

make[3]: *** [net/ipv4/netfilter/ipt_IMQ.o] Error 1

make[2]: *** [net/ipv4/netfilter] Error 2

make[1]: *** [net/ipv4] Error 2

make: *** [net] Error 2

Solution: Enable CONFIG_IMQ in your kernel .config

When creating an IP tables rule with -j IMQ I get 'iptables: No chain/target/match by that name'

When compiling the kernel you need to make sure you have enabled CONFIG_IP_NF_TARGET_IMQ (Networking options/IP: Netfilter Configuration/IMQ target support)

Patch for 2.6.21 applies cleanly, but compilation fails in IPv6 code

The patch for 2.6.21 released on may 5th does not work for IPv6 code.

To make it work, edit the patch and replace "ip6t_register_target" with "xt_register_target", and "ip6t_unregister_target" with "xt_unregister_target".

The sole change from 2.6.20 to 2.6.21 was this change, but corrected only for IPv4

I downloaded Debian iptables package source, patched and compiled it successfully, but the package contains no libipt_IMQ.so

Problem: I use Debian 4.0 (etch), downloaded the source of the iptables package. The patches applied cleanly, I recompiled it, but the resulting .deb package contains no /lib/iptables/libipt_IMQ.so.

Solution: In iptables-1.3.6.0debian1/iptables/extensions/Makefile add IMQ to the list of PF_EXT_SLIB and PF6_EXT_SLIB, just after chmod-ing the .IMQ-test* files.

Others

Content in this Wiki is CopyRight ed under the GNU General Public License Version 2.