From: joern maier joern.maier@informatik.uni-ulm.de
To: lartc@vger.kernel.org
Subject: [LARTC] CBQ and load balancing
Date: Tue, 10 Oct 2000 10:36:36 +0000 [thread overview]
Message-ID: <marc-lartc-98373938216762@msgid-missing> (raw)
In-Reply-To: <marc-lartc-98373938216760@msgid-missing>
<PRE>bert hubert wrote:
><i> </I>
><i> On Mon, Oct 09, 2000 at 04:32:58PM +0200, joern maier wrote:
</I>><i> > o.k. here some more details I haven´t mentioned yet
</I>><i> </I>
><i> Please keep it on the list, I don't like to give private advice, I want</I>
><i> everyone to benefit.
</I>
sorry -> I just pushed the reply button not thinking that it won´t get
back
to the list but to your private e-mail account
><i> </I>
><i> >
</I>><i> > network cofiguration of the LB
</I>><i> >
</I>><i> > eth0 Link encap:Ethernet HWaddr 00:01:02:07:5F:CF
</I>><i> > inet addr:192.168.10.6 Bcast:192.168.255.255
</I>><i> > Mask:255.255.255.0
</I>><i> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
</I>><i> > RX packets:50624 errors:0 dropped:0 overruns:0 frame:0
</I>><i> > TX packets:50630 errors:0 dropped:0 overruns:0 carrier:0
</I>><i> > collisions:0 txqueuelen:100
</I>><i> > Interrupt:11 Base address:0xe800
</I>><i> >
</I>><i> > eth0:110 Link encap:Ethernet HWaddr 00:01:02:07:5F:CF
</I>><i> > inet addr:192.168.10.17 Bcast:192.168.255.255
</I>><i> > Mask:255.255.255.255
</I>><i> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
</I>><i> > Interrupt:11 Base address:0xe800
</I>><i> >
</I>><i> > lo Link encap:Local Loopback
</I>><i> > inet addr:127.0.0.2 Mask:255.255.255.0
</I>><i> > UP LOOPBACK RUNNING MTU:3924 Metric:1
</I>><i> > RX packets:77 errors:0 dropped:0 overruns:0 frame:0
</I>><i> > TX packets:77 errors:0 dropped:0 overruns:0 carrier:0
</I>><i> > collisions:0 txqueuelen:0
</I>><i> >
</I>><i> > the route table:
</I>><i> >
</I>><i> > Kernel IP routing table
</I>><i> > Destination Gateway Genmask Flags Metric Ref U</I>se
><i> > Iface
</I>><i> > lb.mynetwork.or * 255.255.255.255 UH 0 0 </I> 0
><i> > eth0
</I>><i> > 192.168.10.0 * 255.255.255.0 U 0 0 </I> 0
><i> > eth0
</I>><i> > default gw.mynetwork.or 0.0.0.0 UG 0 0 </I> 0
><i> > eth0
</I>><i> >
</I>><i> >
</I>><i> > -> so I only got one ethernet card which is listening to the normal I</I>P
><i> > and a
</I>><i> > virtual IP (the LB IP)
</I>><i> >
</I>><i> > for the nodes behind the lb the setup looks like this
</I>><i> >
</I>><i> > eth0 Link encap:Ethernet HWaddr 00:01:02:07:60:29
</I>><i> > inet addr:192.168.10.8 Bcast:192.168.10.255
</I>><i> > Mask:255.255.255.0
</I>><i> > UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
</I>><i> > RX packets:180379 errors:0 dropped:0 overruns:0 frame:0
</I>><i> > TX packets:183275 errors:0 dropped:0 overruns:0 carrier:0
</I>><i> > collisions:0 txqueuelen:100
</I>><i> > Interrupt:11 Base address:0xe800
</I>><i> >
</I>><i> > lo Link encap:Local Loopback
</I>><i> > inet addr:127.0.0.1 Mask:255.0.0.0
</I>><i> > UP LOOPBACK RUNNING MTU:3924 Metric:1
</I>><i> > RX packets:77 errors:0 dropped:0 overruns:0 frame:0
</I>><i> > TX packets:77 errors:0 dropped:0 overruns:0 carrier:0
</I>><i> > collisions:0 txqueuelen:0
</I>><i> >
</I>><i> > lo:0 Link encap:Local Loopback
</I>><i> > inet addr:192.168.10.17 Mask:255.255.255.255
</I>><i> > UP LOOPBACK RUNNING MTU:3924 Metric:1
</I>><i> >
</I>><i> > routing table:
</I>><i> > Kernel IP routing table
</I>><i> > Destination Gateway Genmask Flags Metric Ref U</I>se
><i> > Iface
</I>><i> > lb.mynetwork.or * 255.255.255.255 UH 0 0 </I> 0
><i> > lo
</I>><i> > 192.168.10.0 * 255.255.255.0 U 0 0 </I> 0
><i> > eth0
</I>><i> > loopback * 255.0.0.0 U 0 0 </I> 0
><i> > lo
</I>><i> > default gw.mynetwork.or 0.0.0.0 UG 0 0 </I> 0
><i> > eth0
</I>><i> >
</I>><i> >
</I>><i> > [...snip]
</I>><i> >
</I>><i> > >
</I>><i> > > Well, you can't shape incoming traffic directly. You can shape traf</I>fic going
><i> > > out to www_server_[123].
</I>><i> > >
</I>><i> > that´s what I wanted to do
</I>><i> >
</I>><i> > [...snip...]
</I>><i> >
</I>><i> > >
</I>><i> > > Did you enable 'shaping based on fwmark' when compiling the kernel?</I>
><i> > >
</I>><i> >
</I>><i> > did not do that in first place -> but I recompiled the kernel right n</I>ow
><i> > and
</I>><i> > it didn´t work either.
</I>><i> >
</I>><i> > [...snip...]
</I>><i> >
</I>><i> > > Please give some details on your network cards, and include where
</I>><i> > > 192.168.10.15 is in this picture, and which card it is connected to</I>, and
><i> > > which card the webservers are connected to.
</I>><i> > >
</I>><i> > more detailed host setup
</I>><i> >
</I>><i> >
</I>><i> > ---www_server_1 (lo:0 192.168.</I>10.17)
><i> > /
</I>><i> > client --------------|-------------------www_server_2 (lo:0
</I>><i> > 192.168.10.17)
</I>><i> > 192.168.10.15 load balancer \
</I>><i> > (with CBQ) ---www_server_3 (lo:0 192.168.</I>10.17)
><i> > eth0:110 = 192.168.10.17 \x18
</I>><i> >
</I>><i> >
</I>><i> > I tried to configure CBQ on the LB like this:
</I>><i> > # tc filter add dev eth0:110 protocol ip parent 100:0 prio 100 handle</I> 1
><i> > fw classid 100:100
</I>><i> > answer was:
</I>><i> > # Cannot find device eth0:110
</I>><i> >
</I>><i> > does this mean that CBQ and virtual IP addresses do not work together</I> ?
><i> >
</I>><i> > -------
</I>><i> > bert hubert wrote:
</I>><i> >
</I>><i> > On Mon, Oct 09, 2000 at 02:46:17PM +0200, joern maier wrote:
</I>><i> > > Hi there,
</I>><i> > >
</I>><i> > > I got a question about CBQ, hope anybody can help me (did not found</I>
><i> > > anything
</I>><i> > > in the archives).
</I>><i> >
</I>><i> > This is the first post ever on the LARTC list, so this does not amaze</I> me
><i> > :-)
</I>><i> >
</I>><i> > > My setup is like this:
</I>><i> > > all hosts are Athlon 800MHZ, 256 MByte RAM and 3com9x Netcards (100</I>MBit)
><i> > > Distribution SuSE 7.0 -> Kernel 2.2.16
</I>><i> > >
</I>><i> > > Host Setup:
</I>><i> > >
</I>><i> > > ---www_server_1
</I>><i> > > /
</I>><i> > > --------------|-------------www_server_2
</I>><i> > > load balancer \
</I>><i> > > (with CBQ) ---www_server_3
</I>><i> > > 192.168.10.17 \x18
</I>><i> > >
</I>><i> > >
</I>><i> > > all I want to do is shaping the INCOMING traffic this means
</I>><i> > > that if I define a special IP only 200Kbit of HTTP request
</I>><i> > > traffic (as an example) is forwarded to the webservers from
</I>><i> > > that IP.
</I>><i> >
</I>><i> > Well, you can't shape incoming traffic directly. You can shape traffi</I>c
><i> > going
</I>><i> > out to www_server_[123].
</I>><i> >
</I>><i> > > The load balancer (Linux Virtual Server) works on IP basis and
</I>><i> > > is integrated as a patch into the system-kernel. It distributes
</I>><i> > > the packets via "direct routing" this means load balancer and
</I>><i> > > www_server_X have all the same IP. If a package is received by
</I>><i> > > the LB it changes the MAC Address of the package and forward it
</I>><i> > > to the right www_server_X.
</I>><i> >
</I>><i> > Perhaps this interferes with Linux traffic shaping, not sure. Does yo</I>ur
><i> > loadbalancer have multiple ethernet cards? If so, you could shape the</I>
><i> > 'backend card' to limit itself to 200kbit.
</I>><i> >
</I>><i> > > The following attempts did not work:
</I>><i> > >
</I>><i> > > using the fw filter:
</I>><i> > > implementing one of the following rules via ipchains did not work:
</I>><i> > > (ip 192.168.10.15 is the client I want to restrict bandwidth)
</I>><i> > >
</I>><i> > > ipchains -A forward -p ip -d 192.168.10.17 m 1 -j ACCEPT
</I>><i> > > or
</I>><i> > > ipchains -A output -p ip -d 192.168.10.17 m 1 -j ACCEPT
</I>><i> > > or
</I>><i> > > ipchains -A forward -p ip -s 192.168.10.15 m 1 -j ACCEPT
</I>><i> > > or
</I>><i> > > ipchains -A output -p ip -s 192.168.10.15 m 1 -j ACCEPT
</I>><i> > >
</I>><i> > > the filter was set up with the following rule
</I>><i> > >
</I>><i> > > tc filter add dev eth0 protocol ip parent 100:0 prio 100 handle 1 f</I>w
><i> > > classid 100:100
</I>><i> >
</I>><i> > Did you enable 'shaping based on fwmark' when compiling the kernel?
</I>><i> >
</I>><i> > > should be reduced to to let´s say 200Kbit, with the last two rule</I>s
><i> > > traffic
</I>><i> > > from source IP 192.168.10.15 sould be reduced to 200Kbit. Non did w</I>ork.
><i> > >
</I>><i> > > using the u32 filter:
</I>><i> > >
</I>><i> > > tc filter add dev eth0 parent 100:0 protocol ip prio 100 u32 match </I>ip
><i> > > src 192.168.10.15 flowid 100:100
</I>><i> >
</I>><i> > Here you match outgoing traffic on eth0 with a source of your webbrow</I>ser
><i> > client.
</I>><i> >
</I>><i> > > the whole outgoing traffic was reduced to 200Kbit.
</I>><i> > > So if anybody has an idea what I did wrong in first place I would b</I>e
><i> > > very
</I>><i> > > happy if you could tell me. Or is it impossible to shape incomming
</I>><i> > > traffic
</I>><i> > > like this. If you need any further information please ask me.
</I>><i> >
</I>><i> > Please give some details on your network cards, and include where
</I>><i> > 192.168.10.15 is in this picture, and which card it is connected to, </I>and
><i> > which card the webservers are connected to.
</I>><i> >
</I>><i> > Regards,
</I>><i> >
</I>><i> > bert hubert
</I>><i> >
</I>><i> > --
</I>><i> > PowerDNS Versatile DNS Services
</I>><i> > Trilab The Technology People
</I>><i> > 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
</I>><i> >
</I>><i> > _______________________________________________
</I>><i> > LARTC mailing list / <A HREF="mailto:LARTC@mailman.ds9a.nl">LARTC@mailman.ds9a.nl</A>
</I>><i> > <A HREF="http://mailman.ds9a.nl/mailman/listinfo/lartc">http://mailman.ds9a.nl/mailman/listinfo/lartc</A> HOWTO:
</I>><i> > <A HREF="http://ds9a.nl/2.4Routing/">http://ds9a.nl/2.4Routing/</A>
</I>><i> >
</I>><i> </I>
><i> --
</I>><i> PowerDNS Versatile DNS Services
</I>><i> Trilab The Technology People
</I>><i> 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
</I>
</PRE>
next prev parent reply other threads:[~2000-10-10 10:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-09 12:46 [LARTC] CBQ and load balancing joern
2000-10-09 14:08 ` bert
2000-10-10 10:36 ` joern [this message]
2000-10-10 13:42 ` joern
2000-10-10 13:53 ` bert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-98373938216762@msgid-missing \
--to=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.