Objective: All web traffic originating from my proxy server should be forwarded through interface eth2 instead of the default eth0. The reply should take the same path back to the proxy server. Problem: On the return bout, the kernel doesn''t pass the packet to the higher layers. The reply seems to be getting tossed away between PREROUTING and INPUT Netfilter chains. Host Setup: Kernel Version: 2.4.22 with Netfilter base patches from CVS Sept. 10; Redhat 9 options w/all Netfilter modules Network Map: eth0 --- Default Route, Default Internet Access eth2 -| eth3 -|- Alternative Internet Access eth4 -| Relevant Configuration: <Squid proxy is set to use <eth2_ip> as its outgoing address> iptables -t mangle -A OUTPUT -m owner --uid-owner squid1 -p tcp --dport 80 -j MARK --set-mark 1 iptables -t mangle -A POSTROUTING -o eth2 --source ! <eth2_ip> -j DROP ip rule add fwmark 1 table 100 ip route add default via <eth2_gw> src <eth2_ip> dev eth2 table 100 <Logs for mangle in,out.pre,post> <NAT / Filter tables are basically empty for this test> Results: Sep 22 11:20:02 gw2 kernel: OUTPUT - IN= OUT=eth0 SRC=<eth2_ip> DST=216.239.39.99 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26601 DF PROTO=TCP SPT=37984 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 <Strange that the first round of routing didn''t use the <eth2_ip> to force the outgoing interface> Sep 22 11:20:02 gw2 kernel: POSTROUTING - IN= OUT=eth2 SRC=<eth2_ip> DST=216.239.39.99 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26602 DF PROTO=TCP SPT=37984 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 <Ok, its looking better after the fwmark is processed> Sep 22 11:20:02 gw2 kernel: PREROUTING - IN=eth2 OUTMAC=00:05:5d:64:9a:f2:00:00:77:92:56:92:08:00 SRC=216.239.39.99 DST=<eth2_ip> LEN=44 TOS=0x00 PREC=0x00 TTL=240 ID=16723 PROTO=TCP SPT=80 DPT=37984 WINDOW=8190 RES=0x00 ACK SYN URGP=0 <IP_CONNTRTACK detects SYN_RECV> <netstat detects SYN_SENT> <Kernel retries sending SYN until timeout> <So, it never reaches back up to the socket layer... I''m screwed>
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 * **********************************************************************************************
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/
> 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/
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/
> > 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/
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 anddangerous content *> * and is believed to be clean. CityNET is proud to use MailScanner. Formore 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/
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/
> 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/
> 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/
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 inthe> 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 anddangerous content *> * and is believed to be clean. CityNET is proud to use MailScanner. Formore 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/
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/
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/
> 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 applicationit> may not be my best choice. You do not know my situation. I triedrecompiling> 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 understandthe> 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 9interfaces,> 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/
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/