[LARTC] IMQ Install Without Recompiling Kernel?

[LARTC] IMQ Install Without Recompiling Kernel?

[Walter D. Wyndroski]

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

Is it possible to compile/install IMQ without recompiling the kernel? 

Clarification: Is it possible to just compile IMQ into a module much like compiling network drivers to work with the current running kernel and then just simply do a modprobe or insmod to insert it?

I am running RH9.0 with kernel 2.4.20-8smp and iptables-1.2.7a-2. I understand that I may/probably have to patch/recompile iptables. However, I am not in a position to recompile my running kernel. My organization, as do I, prefers using the stock kernels from RH with no custom recompilation of the kernel.

Thank you and regards,

Walt
**********************************************************************************************
* 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                                  *
**********************************************************************************************


[-- Attachment #2: Type: text/html, Size: 2604 bytes --]

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[Stef Coene]

On Monday 22 September 2003 21:35, Walter D. Wyndroski wrote:
> Is it possible to compile/install IMQ without recompiling the kernel?
>
> Clarification: Is it possible to just compile IMQ into a module much like
> compiling network drivers to work with the current running kernel and then
> just simply do a modprobe or insmod to insert it?
>
> I am running RH9.0 with kernel 2.4.20-8smp and iptables-1.2.7a-2. I
> understand that I may/probably have to patch/recompile iptables. However, I
> am not in a position to recompile my running kernel. My organization, as do
> I, prefers using the stock kernels from RH with no custom recompilation of
> the kernel.
You have to recompile the kernel.

Stef

-- 
stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.openprojects.net

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

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[David Boreham]

> You have to recompile the kernel.

If you are willing to use a different distro,
then Mandrake 9.1 has a working HTB
compiled into its kernel. Just install and shape...


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

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[Stef Coene]

On Tuesday 23 September 2003 21:36, David Boreham wrote:
> > You have to recompile the kernel.
>
> If you are willing to use a different distro,
> then Mandrake 9.1 has a working HTB
> compiled into its kernel. Just install and shape...
He wants IMQ, not HTB ...

Stef

-- 
stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.openprojects.net

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

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[David Boreham]

> > If you are willing to use a different distro,
> > then Mandrake 9.1 has a working HTB
> > compiled into its kernel. Just install and shape...
> He wants IMQ, not HTB ...

Oh right, gamma ray hit my brain.
Anyway, that's there too:

# find /lib/modules/2.4.21-0.13mdk/ -name "imq*"
/lib/modules/2.4.21-0.13mdk/kernel/drivers/net/imq.o.gz


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

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[Walter D. Wyndroski]

I mostly figured that. Does anyone on the list have any idea when RH may or
may not incorporate IMQ into their stock kernel? Mandrake is not an option
for us as we run RedHat on over ten servers. We are too far entrenched in RH
as well as satisfied overall with it.

I'm really needing the ability to ingress and egress on a subnet, actually
multiple subnets. Primarily I need to ratelimit said subnet no mater which
of the nine interfaces (in my router) from which it's traffic is leaving or
entering the router. However, I still classful queuing using HTB/SFQ. Are
any other options available which could assist me until IMQ becomes part of
the RH stock kernel?

Walt

----- Original Message ----- 
From: "David Boreham" <david_list@boreham.org>
To: <lartc@mailman.ds9a.nl>
Sent: Tuesday, September 23, 2003 4:08 PM
Subject: Re: [LARTC] IMQ Install Without Recompiling Kernel?


> > > If you are willing to use a different distro,
> > > then Mandrake 9.1 has a working HTB
> > > compiled into its kernel. Just install and shape...
> > He wants IMQ, not HTB ...
>
> Oh right, gamma ray hit my brain.
> Anyway, that's there too:
>
> # find /lib/modules/2.4.21-0.13mdk/ -name "imq*"
> /lib/modules/2.4.21-0.13mdk/kernel/drivers/net/imq.o.gz
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> 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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[Stef Coene]

On Wednesday 24 September 2003 01:35, Walter D. Wyndroski wrote:
> I mostly figured that. Does anyone on the list have any idea when RH may or
> may not incorporate IMQ into their stock kernel? Mandrake is not an option
> for us as we run RedHat on over ten servers. We are too far entrenched in
> RH as well as satisfied overall with it.
>
> I'm really needing the ability to ingress and egress on a subnet, actually
> multiple subnets. Primarily I need to ratelimit said subnet no mater which
> of the nine interfaces (in my router) from which it's traffic is leaving or
> entering the router. However, I still classful queuing using HTB/SFQ. Are
> any other options available which could assist me until IMQ becomes part of
> the RH stock kernel?
Ask RH:)

Why don't you take the RH kernel source, apply the imq patch, use the RH 
kernel options and recompile the kernel?

Stef

-- 
stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.openprojects.net

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

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[David Boreham]

> Why don't you take the RH kernel source, apply the imq patch, use the RH
> kernel options and recompile the kernel?

A reasonably painless way to do this is to get the RH kernel RPM source.
Modify the .spec file to add the patches, and rebuild. I've done this in the
past and it tends to result in something which is closer to the original
kernel than if you just take the source tree and compile that. It's also a
more reproducable build process which helps if you need to do it
several times (e.g. when RH releases a new kernel).


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

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[Damjan]

> I'm really needing the ability to ingress and egress on a subnet, actually
> multiple subnets. Primarily I need to ratelimit said subnet no mater which
> of the nine interfaces (in my router) from which it's traffic is leaving or
> entering the router. However, I still classful queuing using HTB/SFQ. Are
> any other options available which could assist me until IMQ becomes part of
> the RH stock kernel?

First I must say that RH is a bad choice for what you want to do.
And second why use Linux if you can't/dont want to recompile a kernel -
its not rocket science....

But anyway, if I understand you corectly you want to shape your
traffic - the traffic is passing trough your Linux router. If this is
the case you don't need IMQ. You see although shaping works only on the
packets LEAVING YOUR ROUTER, still packets are leaving the router in the
direction to the Inerenet but also packets are leaving your router in
the direction to you internal network.



-- 
Damjan Georgievski
jabberID: damjan@bagra.net.mk
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[Walter D. Wyndroski]

Thank you. I had not thought of that route. I will probably go with your
suggestion.

Walt

----- Original Message ----- 
From: "David Boreham" <david_list@boreham.org>
To: <lartc@mailman.ds9a.nl>
Sent: Wednesday, September 24, 2003 12:40 PM
Subject: Re: [LARTC] IMQ Install Without Recompiling Kernel?


> > Why don't you take the RH kernel source, apply the imq patch, use the RH
> > kernel options and recompile the kernel?
>
> A reasonably painless way to do this is to get the RH kernel RPM source.
> Modify the .spec file to add the patches, and rebuild. I've done this in
the
> past and it tends to result in something which is closer to the original
> kernel than if you just take the source tree and compile that. It's also a
> more reproducable build process which helps if you need to do it
> several times (e.g. when RH releases a new kernel).
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> 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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[Walter D. Wyndroski]

1) Why is RH a bad choice?
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.
3) My boss prefers that we stay with the stock RH kernel. If that is not
possible then I will recompile, but only if absolutely necessary.
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.
        -I don't want to write an egress qdisc for each of my 9 interfaces,
plus I also want ingress control.
        -With that said, I want a subnet to be limited to speed X megabits
no matter if traffic is leaving or entering eth0, eth1, or any other
interface.
5) I have different types of customers on each interface, hence different
traffic flows and speeds.
6) I have read this mailing list for well over a year now and enjoyed it
quite a bit. I really appreciate all the members who help and give really
good pointers.

Thank you.

Walt


----- Original Message ----- 
From: "Damjan" <gdamjan@mail.net.mk>
To: <lartc@mailman.ds9a.nl>; "Walter D. Wyndroski" <wdwrn@friendlycity.net>
Sent: Wednesday, September 24, 2003 7:30 PM
Subject: Re: [LARTC] IMQ Install Without Recompiling Kernel?


> > I'm really needing the ability to ingress and egress on a subnet,
actually
> > multiple subnets. Primarily I need to ratelimit said subnet no mater
which
> > of the nine interfaces (in my router) from which it's traffic is leaving
or
> > entering the router. However, I still classful queuing using HTB/SFQ.
Are
> > any other options available which could assist me until IMQ becomes part
of
> > the RH stock kernel?
>
> First I must say that RH is a bad choice for what you want to do.
> And second why use Linux if you can't/dont want to recompile a kernel -
> its not rocket science....
>
> But anyway, if I understand you corectly you want to shape your
> traffic - the traffic is passing trough your Linux router. If this is
> the case you don't need IMQ. You see although shaping works only on the
> packets LEAVING YOUR ROUTER, still packets are leaving the router in the
> direction to the Inerenet but also packets are leaving your router in
> the direction to you internal network.
>
>
>
> -- 
> Damjan Georgievski
> jabberID: damjan@bagra.net.mk
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> 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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[Stef Coene]

On Thursday 25 September 2003 21:51, Walter D. Wyndroski wrote:
> 1) Why is RH a bad choice?
I think RH changes too much.  If you you have a RH apache server and you want 
support from the apache community, you are out of luck.  The RH apache server 
is so much patched that can't help you.  And apt-get rocks :)

> 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.
If this is a closed binary, you still can recomile the kernel with the RH 
kernel sources.  I did this before.  I wanted to use a closed source binary 
to access tape drives on my debian server.  I used the RH kernel sources and 
the module loaded without any problem.

> 3) My boss prefers that we stay with the stock RH kernel. If that is not
> possible then I will recompile, but only if absolutely necessary.
I'm afraid a recompile is needed.

> 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.
Indeed.

>         -I don't want to write an egress qdisc for each of my 9 interfaces,
> plus I also want ingress control.
>         -With that said, I want a subnet to be limited to speed X megabits
> no matter if traffic is leaving or entering eth0, eth1, or any other
> interface.
If it's only rate limiting, you can try filter + policers.

> 5) I have different types of customers on each interface, hence different
> traffic flows and speeds.
If you only need to limit speed and don't care about how bandwidth is divided, 
the ingress qdisc + filters + policers can help you.

> 6) I have read this mailing list for well over a year now and enjoyed it
> quite a bit. I really appreciate all the members who help and give really
> good pointers.
Thx:)

Stef

-- 
stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.openprojects.net

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

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[David Boreham]

> 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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

RE: [LARTC] IMQ Install Without Recompiling Kernel?

[Daniel Chemko]

>> 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.
>If this is a closed binary, you still can recomile the kernel with the
RH 
>kernel sources.  I did this before.  I wanted to use a closed source
binary 
>to access tape drives on my debian server.  I used the RH kernel
sources >and the module loaded without any problem.

I had problems with the DPT_I2O if that is what you are talking about.
You just have to remember to add the card's drivers to
initrd-<kernelver>.img (gzipped ext2 file system).

>> 3) My boss prefers that we stay with the stock RH kernel. If that is 
>> not possible then I will recompile, but only if absolutely necessary.
>I'm afraid a recompile is needed.

If the QOS stuff was compiled as a module, you don't even need to
reinstall the entire system, just the QOS sub-system (not tested with
QOS though). For example, with the kernel sources handy, you can patch
PPP - MPPE into a stock Redhat kernel by just running one of their
scripts. Two files from your existing system are changed, but everything
else is untouched.

My best bet without trying it is:
- Download and install the kernel-source RPM (not SRPM)
- # cp /boot/config-<currentkernel> /usr/src/linux-<version>/.config
This gives you the environment setup more or less how RedHat builds them
with, but without the RPM complexity.
- Edit /usr/src/linux-<version>/Makefile and remove the 'custom' tag
from the end of extraversion.
- # make menuconfig
Add the module that you need inside here
- # make dep; make modules
If all goes well, you should get to the end of modules without errors.
- Copy the module file that you added to the installation into the
module directory in /lib/modules.
- # depmod
If there are no errors here, you are home free.

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

Re: [LARTC] IMQ Install Without Recompiling Kernel?

[Walter D. Wyndroski]

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@boreham.org>
To: <lartc@mailman.ds9a.nl>
Sent: Thursday, September 25, 2003 4:26 PM
Subject: Re: [LARTC] 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@mailman.ds9a.nl
> 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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/