Hey guys, I finally got IMQ to work!!! This may be novel to many, but
recompiling the kernel has always slightly intimidated me until now, even
though I've successfully done it in the past. I've been working for three
days now getting IMQ support into the kernel and iptables.
First off, I didn't want to do a manual compile. So I followed the
instructions for recompiling the RH src.rpm and it worked great after a
little research. I had kernel support for imq devices, but no iptables
support. So I began down the dark path of patch-o-matic. 99% of the docs out
there are for the version of iptables-1.2.6a which was the last version of
iptables to include patch-o-matic. Once I figured out how to work the
patch-o-matic magic, I was felt like I was on my way. I never could get the
new module sources created by iptables to be built into the new kernel-rpm
with rpmbuild. So with more research, I found some great pointers about
re-using the config out of the /boot directory. Once I edited that I
recompiled and all was well with the world.
I've been a fairly hard Linux user now for three years and using
iproute2 now for a year. Now I understand that recompiling the kernel is
second-nature to most on this list, but I just wanted to share a positive
comment rather than a question for once. Most of the stuff involved with
this process is fairly easy "once you understand what's going on". That
reminds me of a joke between my boss and I, "There's no clear documentation
on this because if you are messing with this, you should already know what
you are doing". That actually stemmed from an installation of RADIUS about
three years ago.
In short and IMHO, use of the IMQ Device with classful queues is the
absolute best method to apply fine-tuned ingress/egress control to a
host/subnet. I want to say thanks to everyone to gave me great pointers and
help on this.
Walt
----- Original Message -----
From: "David Boreham" <david_list@xxxxxxxxxxx>
To: <lartc@xxxxxxxxxxxxxxx>
Sent: Thursday, September 25, 2003 4:26 PM
Subject: Re: IMQ Install Without Recompiling Kernel?
> > 1) Why is RH a bad choice?
>
> It's not necessarily bad, for example they can sell you
> good commercial support, and most commercial binary-only
> applications will only support RH kernels (e.g. Clearcase).
> However, RH tends to have their own ideas about a bunch of
> stuff which doesn't always match the 'mainstream'.
>
> This is why I quit using
> RH for my own projects and instead use Mandrake.
> It's RH-like, but rather more in sync with the 'normal'
> Linux environment. There are other distributions which
> have their own 'better' attributes for any given task too.
>
> > 2) Why the sarcasm about not wanting to recompile the kernel? I love
using
> > Linux, and I have recompiled kernels before. However, in this
application
> it
> > may not be my best choice. You do not know my situation. I tried
> recompiling
> > the kernel on this machine and had much trouble with the particular SCSI
> > card in that machine. However, I felt this list was limited to routing
> > issues and NOT kernel recompilation issues with a SCSI card.
>
> Yeah, try the RPM rebuilding route that I suggested.
> I too became frustrated with the typical Linux community
> suggestion that you should rebuild from source in the
> classic manner---I found that the result almost always
> breaks something which previously worked in the distro kernel.
> If you build from the source RPM, modulo some corner
> cases such as using a different compiler build, you'll be
> making exactly the same binary that RH made.
>
> > 4) I'm not the qdisc or routing master, but from my reading I understand
> the
> > following:
> > -An egress qdisc applied to eth0 ONLY shapes traffic leaving
eth0,
> > NOT eth1, eth2, etc.
>
> Right, it's per-interface shaping.
>
> > -I don't want to write an egress qdisc for each of my 9
> interfaces,
> > plus I also want ingress control.
>
> Correct. Plus, if you want to correctly share incoming bandwidth between
> nodes which are on the other side of more than one of those interfaces,
> then separate shaping won't do what you want (the queue at each
> interface has no knowledge of the situation at any of the other
interfaces).
> Therefore you need IMQ.
>
> > 5) I have different types of customers on each interface, hence
different
> > traffic flows and speeds.
>
> Without IMQ you'll be able to shape on each interface,
> but you won't be able to fairly distribute the same bandwidth
> between customers on different interfaces.
>
>
>
> _______________________________________________
> LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>
****************************************************************************
******************
> * This message has been scanned by CityNET's email scanner for viruses and
dangerous content *
> * and is believed to be clean. CityNET is proud to use MailScanner. For
more information *
> * concerning MailScanner, visit http://www.mailscanner.info
*
>
****************************************************************************
******************
>
>
**********************************************************************************************
* This message has been scanned by CityNET's email scanner for viruses and dangerous content *
* and is believed to be clean. CityNET is proud to use MailScanner. For more information *
* concerning MailScanner, visit http://www.mailscanner.info *
**********************************************************************************************
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
