Re: [LARTC] IMQ Stability

[Alexander Clouter <alex-lartc@digriz.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]

On Jan 24, mkazmier@sofast.net wrote:
> Thank you for the detailed discussion.  There is no doubt that there is a
> need for an IMQ type device/funtionality.  What would work really great,
> IMHO, is a "fake" or psuedo ethernet driver that simply sits as a shim
> between one or more real drivers.  This fake device could allow us to
> "Stack" qdiscs in a way to allow one to shape traffic in multiple
> "policies"  - ie, prioritize traffic AND allocate / rate shape end users. 
> I have actually thought of utilizing the kernel bonding driver for this -
> attaching only a single slave to it - but haven't had time as yet.  Not
> sure that this would do anything for ingress shaping though.
> 
I have been working on this with using what I call a ppp-pipe.  The result is

Internet (eth0) <-> ppp0 ----- ppp1 <-> LAN (eth1) 10.0.0.0/8

where ppp0----ppp1 is on the local machine (and simulates two NICs with a 
crossover cable between them in the same machine).  What you throw in at ppp0 
appears at ppp1 and vice versa.  This works fine, it also means you can shape 
on the ppp0/ppp1 interfaces and leave all the NAT stuff on the real 
interfaces.

The command to create this ppp-pipe is (as root), so far I am not completely 
sure if you need to add to the first pppd command "<real ip>:<real ip>" for 
its parameters (you might also need 'xonxoff' too in both):

# mkfifo /tmp/ppp-pipe
# pppd noauth nodefaultroute notty < /tmp/ppp-pipe | pppd noauth \
	notty > /tmp/ppp-pipe

However there is a major problem......connection tracking.  In the above 
setup you do

iptables -t nat -I POSTROUTING -s 10.0.0.0/8 \
	-d ! 10.0.0.0/8 -o eth0 -j MASQUERADE

the '-o eth0' is very important, you also create some advance routing bits to
make all traffic crossing the router to pass through the ppp-pipe; easy
enough, but depends on your needs.  Conntrack unfortunately notices that you
did not want to NAT the packet straight away when it arrives on eth1 (if you
do then you will be unable to shape fairly per IP, for example with ESFQ),
but then later on when the packet resurfaces at ppp0 the 'nat' table is 
skipped.  The only way about this is to use the patch-o-matic RAW patch and 
instruct it to skip connection tracking for packets on eth1 destined for the 
Internet.

As I am now pure 2.6.x goodness I am in the middle of porting the patch 
myself (the patch-o-matic-ng does not work for me, could be me being lame 
though).

Sure this is replacing one patch dependency with another, however IMQ really
seems that it has been left out to rot; whilst the RAW patch probably is
going to stay better maintained, hell its in the patch-o-matic for starters. 
Besides there are lots of advantages with the ppp-pipe, as now all you folks
who want to shape over with IP-Aliasing can just use cunning ppp-pipes
instead; whilst still keeping things very simple.  So far the above should
work in non-NAT (or rather connection tracking) setups but where you want the
equilivent of IP-Aliased style shaping.

Anyway thoughts would be apprieated, however when I was on #lartc it was its 
normal dead self so I was left dead in the water myself :(

have fun

Alex

-- 
 ___________________________ 
< Fortune favors the lucky. >
 --------------------------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]