RE: [LARTC] HTB Rate and Prio (continued)
It depends on what rate you are really synced at and what extra overheads/encapsulation your sdsl line has. It may be a bit different for sdsl - I only know adsl, but as an example, for me, an empty ack which htb will see as 40 bytes (ignoring timestamps/sacks) will actually use 2 atm cells = 106 bytes on my line a 1500 byte ip packet will use 32 cells = 1696 bytes. Which means that if I tweaked by experementing with my rate using bulk traffic and arrived at some figure which seemed OK things could still go overlimits when the traffic consists of alot of small packets. There are patches to work things out per packet and a thesis giving various overheads at http://www.adsl-optimizer.dk/ but for now just back off - 1800 is probably OK for netperf tests. I am talking about egress here - if you are going to shape ingress aswell you need to back off even more as you are trying to shape from the wrong end of the bottleneck (which can't be done perfectly anyway) to build up queues to shape with. Andy. Thanks for all this tips, before I try all you said, I was going to test my line at 500kbits rate/ceil just to put one variable out of the equation, and to my surprise the shaping is working good with 500kbits, I did more tests an dit is working good up to something between 1000 and 1200 kbits, at 1000 it is working, at 1200 the shaping is gone and the problem is back... What I don't understand here, is the fact I can go up to 1800 or higher with iptraf and some netperfs tests... So I'm really lost now, what can I do ?? I can't only shape 1000 and loose 800 kbits, I really need some advice here on what can be done, I'm going mad :) Thanks Gael. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Attatchment test
Hi, I'm about to tell a story best told through diagrams. So I'm testing whether I can attach PNGs to an email to this list. Please ignore this email! ^^ Ta, James. The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. The contents of an attachment to this email may contain software viruses that could damage your own computer systems. Whilst The Spur Group of Companies has taken every precaution to minimise the risk, we cannot accept liability for any damage that you sustain as a result of software viruses. Test.png Description: Test.png ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] HTB Rate and Prio (continued)
Actually doing some more tests with all traffic classified can reach 1700 kbits as rate/ceil, at this rate I must put the prio to have some good results. Doing more tests, I didn't know HTB was so sensitive to the max rate/ceil... I'll post later on. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Problems with table
hi, I have problems with tables. I installed the last iproute2: iproute2-2.4.7-now-ss010824.tar.gz on Linux 2.4.26 (slackware 9.1). I want to use 2 adsl on this server. I run this command: #echo 201 routeradsl2 /etc/iproute2/rt_tables (only one time); then #ip route add 82.189.148.240 dev eth1 src 82.189.148.243 table routeradsl2 at this point I run: #ip route show table routeradsl2 # the table is routeradsl2 empty then I run #ip route show table main 82.189.148.240 dev eth1 scope link src 82.189.148.243 82.189.148.240/29 dev eth1 proto kernel scope link src 82.189.148.243 194.243.125.0/26 dev eth0 proto kernel scope link src 194.243.125.10 194.243.125.0/24 dev eth0 proto kernel scope link src 194.243.125.4 127.0.0.0/8 dev lo scope link default via 194.243.125.1 dev eth0 metric 1 The line 82.189.148.240 dev eth1 scope link src 82.189.148.243 was added to table main instead table routeradls2. Why? MIchele ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problems with table
Sorry. My kernel was not able to perform policy routing in the correct way. Michele Michele Cerioni wrote: hi, I have problems with tables. I installed the last iproute2: iproute2-2.4.7-now-ss010824.tar.gz on Linux 2.4.26 (slackware 9.1). I want to use 2 adsl on this server. I run this command: #echo 201 routeradsl2 /etc/iproute2/rt_tables (only one time); then #ip route add 82.189.148.240 dev eth1 src 82.189.148.243 table routeradsl2 at this point I run: #ip route show table routeradsl2 # the table is routeradsl2 empty then I run #ip route show table main 82.189.148.240 dev eth1 scope link src 82.189.148.243 82.189.148.240/29 dev eth1 proto kernel scope link src 82.189.148.243 194.243.125.0/26 dev eth0 proto kernel scope link src 194.243.125.10 194.243.125.0/24 dev eth0 proto kernel scope link src 194.243.125.4 127.0.0.0/8 dev lo scope link default via 194.243.125.1 dev eth0 metric 1 The line 82.189.148.240 dev eth1 scope link src 82.189.148.243 was added to table main instead table routeradls2. Why? MIchele ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] FW: LARTC Chapter 4.2, variation on a theme.
Hi, I'm building a network similar to that seen in 4.2 of the LARTC Howto. There is a diagram of this attached to this mail. Addendum to diagram: AlexRouter br0 = 192.168.58.1 eth0 = dhcpcd DaveRouter br0 = 192.168.58.2 eth0 = dhcpcd But we've run into some problems when actually implementing the routing for multiple uplinks. The difference between my network and the LARTC example is instead of having one router with two modems I have two routers with one modem each. AlexRouter and DaveRouter. They run Bering-uClibc 2.x off of fd0. A wired/wireless network connects the two together. 192.168.58.0/24. AlexRouter is the default route/DNS server/DHCP server for every host on the network. It gets its DNS servers from dhcpcd. They way I figure it, Provider2 in the example is (in my case) actually DaveRouter. With that in mind, these are the figures I came up with for settings up the routes. These are all from the perspective of AlexRouter. $IF1 = eth0 $IF2 = br0 $IP1 = 80.blah.blah.blah (can't remember my real address) $IP2 = 192.168.58.1 $P1 = $IP1 *DON'T KNOW IF THIS IS RIGHT, DON'T KNOW HOW TO FIND MY PROVIDERS GATEWAY* $P2 = 192.168.58.2 (DaveRouter) $P1_NET = 80.blah.blah.0/24 (got $IP1 and $P1_NET from ip route show) $P2_NET = 192.168.58.0/24 $P0_NET = 192.168.58.0/24 $IF0 = br0 If I set up all the routes using those values, test browsing around is flakey. Some pages load, some don't (one connection working, one not?) I *can* use one connection *OR* the other connection. But only if I manually re-write /etc/resolv.conf to contain the correct DNS servers for the provider used. One ISP is Demon, the other is BT. They won't let each other use their DNS servers. Also, I had duplicate returns from ping. Apart from that, I'm not sure where I go with diagnosis. Does anybody have any idea what's going on? Thanks, James. The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. The contents of an attachment to this email may contain software viruses that could damage your own computer systems. Whilst The Spur Group of Companies has taken every precaution to minimise the risk, we cannot accept liability for any damage that you sustain as a result of software viruses. StonechatNetSm.png Description: StonechatNetSm.png ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Problems setting up nested qdisc, feedback to LARTC HOWTO
Hi all, based on the information in the Linux Advanced Routing Traffic Control HOWTO, I was trying to set up traffic shaping on my firewall. While I found the HOWTO very useful, in the process I ran into some problems that I did not forsee: According to the HOWTO it seems that it should have worked, even after spending some time going through the sections looking for answers, the problem was not obvious to me. So I would appreciate if you could tell me where my mistake was and also maybe add a bit of information to the HOWTO to help others fall into the same traps that I fell into. :-) Here is what I wanted my ideal solution to look like: A strong priority of traffic, where parts of the upstream should be guaranteed rate for some traffic, the rest should be given to normal traffic and any leftovers to BULK traffic, which is allowed to starve for a while. Also, connection handshake and such very short, time critical things should get absolute priority over everything else. So this is what I ideally wanted to set up: 1: PRIO QDISC (4 Bands), DEFAULT: ALL TO BAND 3 (2 in priomap) 1:1 - SFQ, handle 10: for priority communication (connection handshake co) 1:2 - HTB, handle 20: limited to Xk for different kinds of guaranteed rates that can borrow from each other, but never more than the maximum -- so it cannot saturate the link fully. 20:1 - SFQ, handle 100: 20:2 - SFQ, handle 200: 20:3 - SFQ, handle 300: 20:4 - SFQ, handle 400: [...] 1:3 - PRIO QDISC (default), handle 30: for all normal/unclassified traffic, TOS splitting only 30:1 (BAND 1) 30:2 (BAND 2) 30:3 (BAND 3) 1:4 - PFIFO, handle 40: starvation bitbucket gets what is left, can starve at times The setup was apparently successful, tc does not complain and displays the structure: without any CLASSIFY targets, all traffic goes to 1:3 and is split in the three bands properly. Looks good. I can also add CLASSIFY for 1:1 and 1:4, which seem to fall into the SFQ/PFIFO buckets underneath, both look good. The problem starts with the HTB embedded in 1:2 as 20: -- I can never CLASSIFY traffic for it properly, the only way to get ANY traffic into it is to CLASSIFY for 1:2, but that puts all into its default bucket, which defeats its purpose. Neither 20:1 nor 100:0 would put traffic into its first bucket. Such classification is simply ignored as far as I can tell. This is the problem that I ultimately did not find a way to solve, the indirect approach of using the MARK target and tc filters also did not work -- it shows the exact same result. I currently run another approach to this, which I am not quite as happy with, but which works for now -- but would still like to know: * WHY was the 20:1 or 100:0 CLASSIFY not successful? Nothing in the documentation seemed to indicate that it should fail. * HOW could it have been made to work? * WHAT kind of information was I lacking? or, in short: WHAT did I do wrong? I'd be grateful to find an answer and think it might help to then find a way to add that answer into the LARTC HOWTO. Regards, Georg -- Georg C. F. Greve [EMAIL PROTECTED] Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) pgpD4EcAmuYf3.pgp Description: PGP signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Use of qcdisc+htb
On Fri, 15 Jul 2005 11:55:34 +0200 Pawe³ Staszewski [EMAIL PROTECTED] wrote: Hello Hello I have 40Mbit/s internet uplink Average transfer 25Mbit/s - 3957 users [cut] Well, the question is what kind of TC-setup you have. Do you have a separate HTB class for every user? Yours sincerely, Peter ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Goodbye!
I am unsubscribing from the list. I asked for help at least twice for an issue and only one person even offered to try and help if they could. I sent them the details directly and did not receive anything back. I realize this is a community effort and that I am not guaranteed an answer when I submit a question, but to not even receive an RTFM just doesn't leave me feeling very positive about the value of the mailing list. Regards, Cameron ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Goodbye!
I did not see your question, but there are so many topics like load balancing between n interfaces that sometimes I personnally don't want to bother answering for people who do not search at all. Also, please keep in mind that this is not a hotline and that nobody has a obligation to reply. Regards, Sylvain On Ven 15 juillet 2005 18:23, Cameron Nikitiuk a écrit : I am unsubscribing from the list. I asked for help at least twice for an issue and only one person even offered to try and help if they could. I sent them the details directly and did not receive anything back. I realize this is a community effort and that I am not guaranteed an answer when I submit a question, but to not even receive an RTFM just doesn't leave me feeling very positive about the value of the mailing list. Regards, Cameron ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Goodbye!
I am very new in this area, and I asked several questions here. For most of them, I got good replies; for some of them I didn't get any reply (maybe too stupid questions). I think this list is still useful, and no one has obligation to help us anyway. Good luck, -Ji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cameron Nikitiuk Sent: Friday, July 15, 2005 12:24 PM To: LARTC Mailing List Subject: [LARTC] Goodbye! I am unsubscribing from the list. I asked for help at least twice for an issue and only one person even offered to try and help if they could. I sent them the details directly and did not receive anything back. I realize this is a community effort and that I am not guaranteed an answer when I submit a question, but to not even receive an RTFM just doesn't leave me feeling very positive about the value of the mailing list. Regards, Cameron ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] gre tunnel between networks with same subnet
Ok, so I tried the bridging thing. I tried to bridge eth1 and tun0 on A, but apparently linux can't bridge tunnel interfaces (I got an error saying invalid argument when I issued 'brctl addif br0 tun0'). I was told to try using the vtun interface, so I'll dig into that for now. --- Gabriel [EMAIL PROTECTED] wrote: /---\ | | |eth0 |eth0 |---| |---| | |eth1 eth1 | | A |___| B |- | |\ / | | || | | | | | | --- |___| switch What you see above is my setup. Box A is connected to Box B through a switch. Box A is connected to the Internet through eth0, same with Box B. The link that goes through the switch is not very reliable, so I want to connect the two boxes using their Internet link via a gre tunnel. The problem is that the boxes are on the same subnet (and I can't change that). I've read about proxy arp, about bridging, but things are still confused. Here are some numbers: eth1 on Box A is 192.168.1.1/24, eth1 on Box B is 192.168.1.31/24. On Box B there are 4 NICs, 3 of them (including eth1) are bridged, with the bridge interface being br0 (192.168.1.31 is actually assigned to br0, not eth1). I've read the lartc howto, so I created a tun0 interface on both boxes: ip tunnel add tun0 mode gre remote remote_ip_here local local_ip_here ttl 255; ip link set tun0 up. The problem is what do I do from here? Do I bridge tun0 and eth1 on Box A and add tun0 to br0 on Box B? Or do I just enable proxy_arp for eth1 and tun0 on Box A and for br0 and tun0 on B? Are there any routes neccesary (my guess is no, but I'm not very sure)? And about proxy_arp: what do I have to do to turn it on, just set /proc/sys/net/ipv4/conf/iface/proxy_arp to 1 and that's it? One last thing: http://leaf.sourceforge.net/doc/howto/proxyarp.html#id2805973 says proxy-arp is not bridging (agreed) so DO NOT CONFIGURE BRIDGE OPTIONS!!! Does this mean using bridging and doing proxy-arp on the same box is not possible? Thanks. (hope the ascii art comes out well) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc __ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problems setting up nested qdisc, feedback to LARTC HOWTO
Have you tried not using classify but instead using tc filters? Maybe this is a limitation with iptables classify. Try using your classify to put things into 20: and then use tc filters attached to 20: to split into the htb subclasses? I never used classify much and have always used tc filter instead, and i have done a setup similar to this with success. - Jody On 7/15/05, Georg C. F. Greve [EMAIL PROTECTED] wrote: Hi all, based on the information in the Linux Advanced Routing Traffic Control HOWTO, I was trying to set up traffic shaping on my firewall. While I found the HOWTO very useful, in the process I ran into some problems that I did not forsee: According to the HOWTO it seems that it should have worked, even after spending some time going through the sections looking for answers, the problem was not obvious to me. So I would appreciate if you could tell me where my mistake was and also maybe add a bit of information to the HOWTO to help others fall into the same traps that I fell into. :-) Here is what I wanted my ideal solution to look like: A strong priority of traffic, where parts of the upstream should be guaranteed rate for some traffic, the rest should be given to normal traffic and any leftovers to BULK traffic, which is allowed to starve for a while. Also, connection handshake and such very short, time critical things should get absolute priority over everything else. So this is what I ideally wanted to set up: 1: PRIO QDISC (4 Bands), DEFAULT: ALL TO BAND 3 (2 in priomap) 1:1 - SFQ, handle 10: for priority communication (connection handshake co) 1:2 - HTB, handle 20: limited to Xk for different kinds of guaranteed rates that can borrow from each other, but never more than the maximum -- so it cannot saturate the link fully. 20:1 - SFQ, handle 100: 20:2 - SFQ, handle 200: 20:3 - SFQ, handle 300: 20:4 - SFQ, handle 400: [...] 1:3 - PRIO QDISC (default), handle 30: for all normal/unclassified traffic, TOS splitting only 30:1 (BAND 1) 30:2 (BAND 2) 30:3 (BAND 3) 1:4 - PFIFO, handle 40: starvation bitbucket gets what is left, can starve at times The setup was apparently successful, tc does not complain and displays the structure: without any CLASSIFY targets, all traffic goes to 1:3 and is split in the three bands properly. Looks good. I can also add CLASSIFY for 1:1 and 1:4, which seem to fall into the SFQ/PFIFO buckets underneath, both look good. The problem starts with the HTB embedded in 1:2 as 20: -- I can never CLASSIFY traffic for it properly, the only way to get ANY traffic into it is to CLASSIFY for 1:2, but that puts all into its default bucket, which defeats its purpose. Neither 20:1 nor 100:0 would put traffic into its first bucket. Such classification is simply ignored as far as I can tell. This is the problem that I ultimately did not find a way to solve, the indirect approach of using the MARK target and tc filters also did not work -- it shows the exact same result. I currently run another approach to this, which I am not quite as happy with, but which works for now -- but would still like to know: * WHY was the 20:1 or 100:0 CLASSIFY not successful? Nothing in the documentation seemed to indicate that it should fail. * HOW could it have been made to work? * WHAT kind of information was I lacking? or, in short: WHAT did I do wrong? I'd be grateful to find an answer and think it might help to then find a way to add that answer into the LARTC HOWTO. Regards, Georg -- Georg C. F. Greve [EMAIL PROTECTED] Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problems setting up nested qdisc, feedback to LARTC HOWTO
|| On Fri, 15 Jul 2005 14:46:24 -0400 || Jody Shumaker [EMAIL PROTECTED] wrote: js Have you tried not using classify but instead using tc filters? Well, the tc filters are much more limited than iptables, they could not replicate what I am doing with the iptables. That is why I tried using the -j MARK iptables target to set a tc filter based on that. js Maybe this is a limitation with iptables classify. Try using js your classify to put things into 20: and then use tc filters js attached to 20: to split into the htb subclasses? Interesting idea. It is comforting that you have done something similar with success, so I guess a combination of -j MARK and -j CLASSIFY targets might be able to do that job, I will have to try this. But having to employ such a mix seems like a cludge, shouldn't this work properly with CLASSIFY, as well? Nothing in the documentation says that it shouldn't -- and the docs are missing sufficiently complex examples to get an idea of how others solved that problem. It seems some problem exists, it is just not clear to me yet whether this is a bug in the documentation or the software. Regards, Georg -- Georg C. F. Greve [EMAIL PROTECTED] Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) pgpmbGBZFwHBI.pgp Description: PGP signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problems setting up nested qdisc, feedback to LARTC HOWTO
|| On Fri, 15 Jul 2005 22:58:09 +0200 || Georg C. F. Greve [EMAIL PROTECTED] wrote: gg It is comforting that you have done something similar with gg success, so I guess a combination of -j MARK and -j CLASSIFY gg targets might be able to do that job, I will have to try this. UPDATE: This indeed appears to be working. Maybe this ought to go into the HOWTO in some way. Regards, Georg -- Georg C. F. Greve [EMAIL PROTECTED] Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) pgp70PnVx6Idb.pgp Description: PGP signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problems setting up nested qdisc, feedback to LARTC HOWTO
When I read this earlier I thought of offering the same, i'm using a mix of -j mark and tc filters to do my routing into nexted qdiscs. Seems more like i'd consider this a bug of classify that should be fixed, and maybe a note in the howto that it is broken for now. - Jody Georg C. F. Greve wrote: || On Fri, 15 Jul 2005 22:58:09 +0200 || Georg C. F. Greve [EMAIL PROTECTED] wrote: gg It is comforting that you have done something similar with gg success, so I guess a combination of -j MARK and -j CLASSIFY gg targets might be able to do that job, I will have to try this. UPDATE: This indeed appears to be working. Maybe this ought to go into the HOWTO in some way. Regards, Georg ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
