Re: [LARTC] Packet marking for ingress shapping and NAT

[Andy Furniss <andy.furniss@dsl.pipex.com>]

Patrick Spousta wrote:

<snip>

>> I don't think IMQ will help - but you can mark local src in postrouting 
> 
> 
> Do you mean manualy configured marking for many, many IP addresses? I 
> think it isn't right way :-( I like ESFQ for it's source or destination 
> hash because I don't need to setup any filters/markers for those IPs, 
> ESFQ creats it's own queues for each IP.

Yes I agree - not nice for your setup, though personally the thing I 
don't like about using esfq on src/dst is you loose per tcp fairness - 
it was less than a year ago that I was on 56K and anyone with high 
latency downloading from you will get their already small bandwidth 
squeezed out by the low latency downloaders.

Maybe it's less noticable/of an issue for your big setup anyway.

> 
> In POSTROUTING chain it normaly look like this
> 
> ... -> mangle -> nat -> imq -> (output interface)
> 
> I don't understand C language so I don't understand IMQ+NAT patch, but 
> I'll try to use imq for egress shapping. Maybe the patch is working 
> identically on PRE i POST chains.

I only just started getting into C myself - (used motorolla 68000 
assembly years ago on an atari ST - these "high level" languages are 
much trickier :-) ).

I can see that the patch is trivial and needs an understanding of 
netfilter hooks more than C.

I just tested with u32 to double confirm what I knew really - the patch 
only affects prerouting hooks.

Then knowing nothing about netfilter decided to have a go at changing 
the egress hook - it appears to be working as expected.

One caveat - some people have reported stability problems using 
postrouting IMQ, probably to do with dropping locally generated traffic. 
I and others don't, but then I don't leave my gateway PC up that long. 
Grepping my logs :

Sent 3744702472 bytes 5539814 pkts (dropped 354902, overlimits 11722774)

is the most I can see (most of the drops are locally generated packets 
ie. bittorrent running on the shaping PC).

If you wan't to give my blind and possibly stupid hack a go you just 
need to change near the top of drivers/net/imq.c so it looks like -

static struct nf_hook_ops imq_egress_ipv4 = {
         { NULL, NULL},
         imq_nf_hook,
         PF_INET,
         NF_IP_POST_ROUTING,
         NF_IP_PRI_NAT_SRC - 1
};


Rather than -

static struct nf_hook_ops imq_egress_ipv4 = {
         { NULL, NULL},
         imq_nf_hook,
         PF_INET,
         NF_IP_POST_ROUTING,
         NF_IP_PRI_LAST
};

You could do the same for the egress ipv6 bits below it aswell.

If you still have your source tree intact and use modules cd to top dir 
in kernel tree do

make SUBDIRS=drivers/net modules

which should build a new imq.o in drivers/net

Backup /lib/modules/[your version]/kernel/drivers/net/imq.o

and replace with new one.

Take down shaping and modprobe -r imq (check it's gone with lsmod) and 
restart shaper.

It's a bit of a pain that imq is unstable for some anyway - you won't 
know whoose fault it is if/when it crashes :-)

Andy.

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/