Re: [LARTC] can I use tos and fwmark at the same time?
panca sorin wrote: Hello lartc maintainers and users! I have a router with two NICs. One NIC is connected to the Internet and the other to my internal LAN. I made a script for priorizing interactive traffic. The script matches TOS Minimize-Delay for priorizing interactive trafic, and fwmark for metropolitan packets. I have two root classes (simulating two circuits) : 1:1 for internet and 1:3 for metropolitan. When I watch -n1 tc -s -d qdisc show, the classes that belong to metropolitan traffic (FE) on the two interfaces are not sending nor receiving any byte... Can someone help me out this situation? I list my tc and iptables scripts below (for some reason I could't attach them - "Invalid file"). Thank you in advance! - my_script.sh: I only skimmed through - the lack of CRs make it a bit difficult to read. One thing to note is that unlike htb, prio 1 is the top prio for filters - and you use prio 0 for the metro so this filter won't see traffic that has already been fclassified by the prio 1 tos filter. Also when using tos be aware that some apps set it - so there could be other traffic than that set by the iptables rules. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] The effects of queueing on delay...(TX Ring Buffer the problem)
Jonathan Lynch wrote: Quoting Andy Furniss <[EMAIL PROTECTED]>: Jonathan Lynch wrote: This was down to the tx buffer size on the network card i was using. It was an Intel 82547EI gigabit Card using the e1000 driver and operating at 100mbit. The tx buffer was set to 256 which caused this huge delay. The minimum the driver lets me reduce the tx buffer size using ethtool is 80. By reducing the tx ring buffer to 80, the delay when there is full link utilisation and a maximum queue of 10 packets was reduced from 30ms to 10ms. The 3com 3c59x vortex driver uses a tx buffer of 16. I reduced the tx to 16 on the e1000 driver, but the max throughput i could achieve on the interface went down. Has anyone experimented with reducing the size of the tx buffer on this card to get a good balance between delay and throughput ? Strange - I thought that as long as you are under rate for the link then the most htb should burst per tick is the burst size specified. That assumes one bulk class - more will make it worse. Andy. Just noticed your reply there, havnt been very busy lately and havnt been checked LARTC in a while. say for example with a htb qdisc configured with a ceil of 100 Mbit (overhead 24 mpu 84 mtu 1600 burst 12k cburst 12k quantum 1500) or a queue discipline that doesnt rate limit such as prio or red there was a delay of 30 ms imposed when the outgoing interface was saturated and the tx ring size was 256. when the tx ring size was reduced to 80 the delay was around 9ms. Ahh I see what you mean - reducing the buffer beyond htb, but I don't really see why you need to, rather than reducing htb rate so you only have one htb burst of packets in it at a time (that assumes you only have two classes like in your other tests - more bulk classes would be worse). The tx ring is a fifo structure. The NIC driver uses DMA to transmit packets from the tx ring. these are worst case delays when The tx ring is full of maximum size FTP packets with the VoIP packet at the end. The VoIP has to wait for all the FTP packets to be transmitted. When the rate was reduced to 99Mbit the maximum delay imposed is about 2ms. It seems that with the reduced rate there is time to clear more packets from the TX ring...there are less packets in the ring resulting in a lower delay. But the delay increases linearly. I agree from our previous discussion and tests that even with overheads added you need to back off a bit more than expected, but I assumed this was to do with either : The 8/16 byte granularity of the lookup tables. The fact that overhead was not designed into htb, but added later. Timers maybe being a bit out. Me not knowing the overhead of ethernet properly. Making tx buffer smaller is just a workaround for htb being over rate for whatever reason. Also a question when defining the following parameters (overhead 24 mpu 84 mtu 1600 burst 12k cburst 12k quantum 1500) I suppose quantum should be 1514 - as you pointed out to me previously as it's eth - maybe more if you are still testing on vlans. I don't think it will make any difference in this test - I see the overhead allows for it already (I am just stating for the list as it was down during our previous discussions about overheads). mtu 1600 - It's a bit late to check now - but there is a size makes the table go from 8 to 16 and 1600 seems familiar - but 2048 comes to mind aswell :-) I would check with tc -s -d class ls and reduce it a bit if you see /16 after burst. i have them defined on all classes and on the htb qdisc itself. Is there a minimum place where they can be specified...ie just on the htb qdisc itself, or do they have to be specified on all I would think so, htb has a lookup table for each rate and ceil. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Theory test
Kenneth Kalmer wrote: Are we talking about ingress or egress? Egress, all my ingress experiments worked 100% (mostly prioritization, that's all) That's handy I was expecting you to say ingress. Outbound should be totally under your control. How much bandwidth do you have (and how much are you sacrificing)? Sadly, only 512kbits but upgrading to 1024kbits in Feb You have 512kbit upstream - symmetrical dsl - what rate do you set htb? What are the lengths of queues for each user? Pardon me? It's less relevant for egress - for ingress shaping the length of the queues if too long can mess things up, and unless you use esfq it would have been hard when shaping 200 users to reduce it/them. What is the link DSL/other? ADSL, African style... Not sdsl then - is your egress 512? Do you know what type of connection you have eg pppoa/e or bridged ip etc. I assume whatever it is ends up as atm cells? Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] GRED & HTB
Hi, I am tring to setup AF on my router using GRED/HTB. I plan to mark and set the DSCP with iptables and the ingress qdisc to set the tc_index for the proper GRED vq(1-12). My question is: Is there a way to allow for priority between the af classes and within the af classes? also would it be possible to to the following: HTB(6Mb) | GRED(1)grio HTB1 (af1) (1MB) GRED(1-3)grio | GRED(2)grio HTB2(af2) (1MB) GRED(1-3)grio thx jason what i have now** HTB (6Mb) | GRED (1-12) using grio af11 -> gred vq 10 af12 -> gred vq 11 af13 -> gred vq 12 af21 -> gred vq 7 af23 -> gred vq 8 af23 -> gred vq 9 af31 -> gred vq 4 af32 -> gred vq 5 af33 -> gred vq 6 af41 -> gred vq 1 af42 -> gred vq 2 af43 -> gred vq 3 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Theory test
On 12/5/05, Andy Furniss <[EMAIL PROTECTED]> wrote: > Kenneth Kalmer wrote: > > Guys > > > > Considering the festive season is upon us, thanks to everyone > > contributing to the list and helping all the readers with your great > > input! I don't want to mention names, I'll most certainly leave > > someone out. > > > > With this mail I'd like to test some theory on bandwidth management, > > with my own successes and failures during the past year. > > > > Sharing a link between 200 users > > > > This has probably been my worst headache this year, since all the > > trials go well but the implementation doesn't run as expected. So here > > goes. We have one connection that is shared by 200 users. Mostly > > students, so abuse is rampant. Each user should have an upper-limit > > for speed, but the upper limit times the number of users exceed the > > link capacity (over subscription). The speed must degrade as more and > > more users are online, so that in peak times the link must still be > > usable for each and every user, even if dreadfully slow. > > > > Here is the implementation in theory: > > Total internet capacity: X > > Total number of users: 200 > > Minimum transfer rates: Y = X / 200 > > Maximum transfer rates: Z = 8 * Y > > Over subscription rate: 1:50 > > Are we talking about ingress or egress? Egress, all my ingress experiments worked 100% (mostly prioritization, that's all) > How much bandwidth do you have (and how much are you sacrificing)? Sadly, only 512kbits but upgrading to 1024kbits in Feb > What are the lengths of queues for each user? Pardon me? > What is the link DSL/other? ADSL, African style... -- Kenneth Kalmer [EMAIL PROTECTED] [EMAIL PROTECTED] stats http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Theory test
On 12/5/05, Andreas Klauer <[EMAIL PROTECTED]> wrote: > On Monday 05 December 2005 18:42, Kenneth Kalmer wrote: > > -= HTB =- > > > > Set the parent class for internet traffic to X, with 200 children. > > Each child has a rate of Y, their totals equal X. Each child also has > > a ceil of Z. This means that Z * 200 > X, hence the over subscription. > > I'm using pretty much the same with success, although not for 200 users, > just 5. However, the bandwidth is considerably slower than what you are > likely to have (128kbit), so it may be just as critical. This is the scary part, I only have 512kbit now, will be upgrading to 1024kbit in Feb... > > What happens here is that several people download at Z, but their > > speed does not decrease when more people start accessing the internet. > > They stay at Z, which is a problem. > > This is a serious problem which should not happen. So assuming that there > is no error in your configuration, it's likely to be a HTB bug which > should be fixed. Doubt it, the problem will be on my side... I've seen so many guys here go "HTB not working!", and be proved fatally wrong... > > -= HFSC =- > > > > Tried playing around with the curves, but a lack of knowledge and > > resources has hampered me from figuring out this one. > > Is there still no documentation for HFSC around? There is, still very cryptic. The best is scattered through the pf mailing lists... > > -= WRR =- > > Sounds very interesting, unfortunately I didn't have the time to try this > one out. So I can't comment on the problems you have with it either. :-( > > > Can anyone advise me on how to get this done properly, please. > > Somewhere I must be missing something small, and I don't want to paste > > millions of lines of scripts in here until I know I've got the theory > > right. The over subscription is the big problem, pure rate limiting > > works like a charm in my other experiments. > > The theory sounds fine to me. About the sum of ceils being bigger than the > rate of the parent class, that's not really over subscription, but the > whole point of the ceil parameter. Over subscription to my understanding > would be the case if the guaranteed rates of classes would exceed the > parent class rate. But since you say that it sums up to X, the theory > sounds just fine to me. > > I'd like to have a look at your HTB setup, since that is the scheduler I'm > most familiar with. If the script is too long, you could upload it > somewhere and post the URL to it. Or just cut out the repetitive parts if > you aren't using functions for that already anyway (I'm assuming that the > 200 user classes are all created the same way). Correct, right now I'm going to bed. But I'll rip apart my wrr, hfsc and htb scripts and place them in a message for everyone to check out. They're all populated from data in text files, so the scripts themselves are pretty light. > > Regards, > Andreas Klauer > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > -- Kenneth Kalmer [EMAIL PROTECTED] [EMAIL PROTECTED] stats http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Theory test
On 12/5/05, Peter Surda <[EMAIL PROTECTED]> wrote: > On Mon, 5 Dec 2005 19:42:09 +0200 Kenneth Kalmer <[EMAIL PROTECTED]> > wrote: > > >Guys > Hi, > > >Sharing a link between 200 users > Been there, done that (1400 users even). > > >-= WRR =- > >My favourite, but with the most disappointment at the moment... I can > >see the weights are adjusted, and our trials have shown that the link > >gets shared equally. However, in implementation it doesn't work that > >way. The abusers can still go mad, and now at link capacity (X), no > >longer at Z. This has caused some serious problems for non-abusive > >users. > You probably need to use bigger incr and decr in wrr. Check out shurdix' tc > script: http://docs.shurdix.org/shurdix:learn , it calculates the parameters > automatically, you only need to set incoming and outgoing bandwidth. I'll check this out. By hacking shurdix's tc.sh to sh*t is how I learned to configure WRR properly... Thanks :) > > >Kenneth Kalmer > >[EMAIL PROTECTED] > Yours sincerely, > Peter > > -- > http://www.shurdix.org - Linux distribution for routers and firewalls -- Kenneth Kalmer [EMAIL PROTECTED] [EMAIL PROTECTED] stats http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Theory test
Kenneth Kalmer wrote: Guys Considering the festive season is upon us, thanks to everyone contributing to the list and helping all the readers with your great input! I don't want to mention names, I'll most certainly leave someone out. With this mail I'd like to test some theory on bandwidth management, with my own successes and failures during the past year. Sharing a link between 200 users This has probably been my worst headache this year, since all the trials go well but the implementation doesn't run as expected. So here goes. We have one connection that is shared by 200 users. Mostly students, so abuse is rampant. Each user should have an upper-limit for speed, but the upper limit times the number of users exceed the link capacity (over subscription). The speed must degrade as more and more users are online, so that in peak times the link must still be usable for each and every user, even if dreadfully slow. Here is the implementation in theory: Total internet capacity: X Total number of users: 200 Minimum transfer rates: Y = X / 200 Maximum transfer rates: Z = 8 * Y Over subscription rate: 1:50 Are we talking about ingress or egress? How much bandwidth do you have (and how much are you sacrificing)? What are the lengths of queues for each user? What is the link DSL/other? Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB - prio and rate
On Monday 05 December 2005 10:40, Mark Lidstone wrote: > 1) The sum of all HTB classes under a single HTB qdisc should > add up to the maximum rate of the qdisc A HTB qdisc does not have a rate; it's the classes that do. And it's not all classes, but just parent-children relationship. The sum of the children class rates should be the parent class rate. Maximum rate doesn't sound right either; just to avoid misunderstandings, we're talking about rate here, not ceil. Think of rate as 'this much bandwidth is guaranteed at all times for this class (and divided between the children)', then you should get it about right. > 2) HTB's prio is only used when 'borrowing' bandwidth from other > classes under the same HTB qdisc, then classes with a given prio will > only be able to "borrow" bandwidth when classes with a lower prio have > nothing waiting "classes under the same HTB qdisc" is too general. You have to respect parent / child / sibling relationship as well. A class can't just borrow from any other class. For example, if a class has same rate and ceil, it won't borrow anything, simply because it doesn't have to. And if the parent won't borrow, it's children won't borrow from outside classes either, even though they are "under the same qdisc". > Is this correct? Getting there, I think. Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Theory test
On Monday 05 December 2005 18:42, Kenneth Kalmer wrote: > -= HTB =- > > Set the parent class for internet traffic to X, with 200 children. > Each child has a rate of Y, their totals equal X. Each child also has > a ceil of Z. This means that Z * 200 > X, hence the over subscription. I'm using pretty much the same with success, although not for 200 users, just 5. However, the bandwidth is considerably slower than what you are likely to have (128kbit), so it may be just as critical. > What happens here is that several people download at Z, but their > speed does not decrease when more people start accessing the internet. > They stay at Z, which is a problem. This is a serious problem which should not happen. So assuming that there is no error in your configuration, it's likely to be a HTB bug which should be fixed. > -= HFSC =- > > Tried playing around with the curves, but a lack of knowledge and > resources has hampered me from figuring out this one. Is there still no documentation for HFSC around? > -= WRR =- Sounds very interesting, unfortunately I didn't have the time to try this one out. So I can't comment on the problems you have with it either. :-( > Can anyone advise me on how to get this done properly, please. > Somewhere I must be missing something small, and I don't want to paste > millions of lines of scripts in here until I know I've got the theory > right. The over subscription is the big problem, pure rate limiting > works like a charm in my other experiments. The theory sounds fine to me. About the sum of ceils being bigger than the rate of the parent class, that's not really over subscription, but the whole point of the ceil parameter. Over subscription to my understanding would be the case if the guaranteed rates of classes would exceed the parent class rate. But since you say that it sums up to X, the theory sounds just fine to me. I'd like to have a look at your HTB setup, since that is the scheduler I'm most familiar with. If the script is too long, you could upload it somewhere and post the URL to it. Or just cut out the repetitive parts if you aren't using functions for that already anyway (I'm assuming that the 200 user classes are all created the same way). Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Theory test
On Mon, 5 Dec 2005 19:42:09 +0200 Kenneth Kalmer <[EMAIL PROTECTED]> wrote: >Guys Hi, >Sharing a link between 200 users Been there, done that (1400 users even). >-= WRR =- >My favourite, but with the most disappointment at the moment... I can >see the weights are adjusted, and our trials have shown that the link >gets shared equally. However, in implementation it doesn't work that >way. The abusers can still go mad, and now at link capacity (X), no >longer at Z. This has caused some serious problems for non-abusive >users. You probably need to use bigger incr and decr in wrr. Check out shurdix' tc script: http://docs.shurdix.org/shurdix:learn , it calculates the parameters automatically, you only need to set incoming and outgoing bandwidth. >Kenneth Kalmer >[EMAIL PROTECTED] Yours sincerely, Peter -- http://www.shurdix.org - Linux distribution for routers and firewalls ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Theory test
Guys Considering the festive season is upon us, thanks to everyone contributing to the list and helping all the readers with your great input! I don't want to mention names, I'll most certainly leave someone out. With this mail I'd like to test some theory on bandwidth management, with my own successes and failures during the past year. Sharing a link between 200 users This has probably been my worst headache this year, since all the trials go well but the implementation doesn't run as expected. So here goes. We have one connection that is shared by 200 users. Mostly students, so abuse is rampant. Each user should have an upper-limit for speed, but the upper limit times the number of users exceed the link capacity (over subscription). The speed must degrade as more and more users are online, so that in peak times the link must still be usable for each and every user, even if dreadfully slow. Here is the implementation in theory: Total internet capacity: X Total number of users: 200 Minimum transfer rates: Y = X / 200 Maximum transfer rates: Z = 8 * Y Over subscription rate: 1:50 I tried to achieve this, but below are my hiccups -= HTB =- Set the parent class for internet traffic to X, with 200 children. Each child has a rate of Y, their totals equal X. Each child also has a ceil of Z. This means that Z * 200 > X, hence the over subscription. What happens here is that several people download at Z, but their speed does not decrease when more people start accessing the internet. They stay at Z, which is a problem. -= HFSC =- Tried playing around with the curves, but a lack of knowledge and resources has hampered me from figuring out this one. In essence, the same problem occurs, the link isn't shared equally between the active users. -= WRR =- My favourite, but with the most disappointment at the moment... I can see the weights are adjusted, and our trials have shown that the link gets shared equally. However, in implementation it doesn't work that way. The abusers can still go mad, and now at link capacity (X), no longer at Z. This has caused some serious problems for non-abusive users. Can anyone advise me on how to get this done properly, please. Somewhere I must be missing something small, and I don't want to paste millions of lines of scripts in here until I know I've got the theory right. The over subscription is the big problem, pure rate limiting works like a charm in my other experiments. Thanks in advance -- Kenneth Kalmer [EMAIL PROTECTED] [EMAIL PROTECTED] stats http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Fwd: Re: [LARTC] inspecting what's going in a class
Subject: Re: [LARTC] inspecting what's going in a class Date: Monday 05 December 2005 09:38 From: "Ethy H. Brito" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] On Mon, 5 Dec 2005 00:59:46 -0500 Jason Boxman <[EMAIL PROTECTED]> wrote: > > > Sadly not possible with tc-filter. But perhaps I could do this for tc > > > with Vincent Perrier's sch_spy module. > > > > sch_log is also good for this: > > > > http://kernel.umbrella.ro/net/sch_log/v0.4/sch_log-0.4.tar.gz Question to All: I see that the patch applies against iproute2-2.6.11. Does the "2.6.11" part have anything to do with kernel version??? I.e. iproute2-2.6.11 has to be used with 2.6 kernel series? Regards -- Ethy H. Brito /"\ InterNexo Ltda. \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML +55 (12) 3941-6860 X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL S.J.Campos - Brasil / \ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Trouble redirecting traffic on transparent bridge.
Ok I gave br0 an IP. Now I have a new problem. When the client tries to access a webserver the traffic redirected to the ip on the bridge to the local web server. However, the traffic going back to the client machine from the web server has a source port of 1, this isn't what the client expects so it rejects it. Here's a tethereal dump of eth2, the interface on the bridge between the client and the bridge: 172.16.110.139 is client, 64.233.187.104 is google.com 10.841477 172.16.110.139 -> 64.233.187.104 TCP 2684 > http [FIN, ACK] Seq=0 Ack=0 Win=65535 Len=0 10.841661 64.233.187.104 -> 172.16.110.139 TCP tcpmux > 2684 [ACK] Seq=0 Ack=0 Win=6432 Len=0 10.841853 172.16.110.139 -> 64.233.187.104 TCP 2684 > tcpmux [RST] Seq=0 Ack=2730207901 Win=0 Len=0 10.844408 64.233.187.104 -> 172.16.110.139 TCP [TCP ACKed lost segment] http > 2684 [RST, ACK] Seq=2730208227 Ack=2 Win=0 Len=0 10.868209 172.16.110.139 -> 64.233.187.104 TCP 2685 > http [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460 10.868384 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 10.868584 172.16.110.139 -> 64.233.187.104 TCP 2685 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0 10.881201 172.16.110.139 -> 64.233.187.104 HTTP GET /index.html HTTP/1.1 10.881635 64.233.187.104 -> 172.16.110.139 TCP tcpmux > 2685 [ACK] Seq=0 Ack=0 Win=6432 Len=0 10.881824 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 Ack=562108981 Win=0 Len=0 10.882135 64.233.187.104 -> 172.16.110.139 TCP tcpmux > 2685 [PSH, ACK] Seq=0 Ack=0 Win=6432 Len=325 10.882324 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 Ack=562108981 Win=0 Len=0 10.883252 64.233.187.104 -> 172.16.110.139 TCP [TCP ACKed lost segment] [TCP Previous segment lost] http > 2685 [RST, ACK] Seq=562108982 Ack=491 Win=0 Len=0 10.883268 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [RST, ACK] Seq=562108982 Ack=491 Win=0 Len=0 13.851777 172.16.110.139 -> 64.233.187.104 HTTP [TCP ZeroWindowViolation] [TCP Out-Of-Order] GET /index.html HTTP/1.1 13.852239 64.233.187.104 -> 172.16.110.139 TCP [TCP Dup ACK 11#1] tcpmux > 2685 [ACK] Seq=325 Ack=0 Win=6432 Len=0 SLE=4294966807 SRE=0 13.852403 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 Ack=562108981 Win=0 Len=0 13.853102 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [RST, ACK] Seq=562108982 Ack=491 Win=0 Len=0 13.881844 64.233.187.104 -> 172.16.110.139 TCP [TCP Retransmission] tcpmux > 2685 [PSH, ACK] Seq=0 Ack=0 Win=6432 Len=325 13.882009 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 Ack=562108981 Win=0 Len=0 13.882705 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [RST, ACK] Seq=562108982 Ack=491 Win=0 Len=0 19.859637 172.16.110.139 -> 64.233.187.104 HTTP [TCP ZeroWindowViolation] [TCP Out-Of-Order] GET /index.html HTTP/1.1 19.860007 64.233.187.104 -> 172.16.110.139 TCP [TCP Dup ACK 11#2] tcpmux > 2685 [ACK] Seq=325 Ack=0 Win=6432 Len=0 SLE=4294966807 SRE=0 19.860139 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 Ack=562108981 Win=0 Len=0 19.860874 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [RST, ACK] Seq=562108982 Ack=491 Win=0 Len=0 19.882250 64.233.187.104 -> 172.16.110.139 TCP [TCP Retransmission] tcpmux > 2685 [PSH, ACK] Seq=0 Ack=0 Win=6432 Len=325 19.882496 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 Ack=562108981 Win=0 Len=0 19.883111 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [RST, ACK] Seq=562108982 Ack=491 Win=0 Len=0 #ip route 192.168.200.0/24 dev br0 proto kernel scope link src 192.168.200.1 172.16.110.0/23 dev eth0 proto kernel scope link src 172.16.110.150 127.0.0.0/8 dev lo scope link default via 172.16.111.254 dev eth0 metric 1 # iptables -n -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT all -- 172.16.110.139 64.233.187.104 to:192.168.200.1 Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 192.168.200.1172.16.110.139 to:64.233.187.104 Chain OUTPUT (policy ACCEPT) target prot opt source destination Any ideas on what's going on? Why would the source port change? - Original Message - From: "Jeffrey B. Ferland" <[EMAIL PROTECTED]> To: "Kran Kor" <[EMAIL PROTECTED]> Subject: Re: [LARTC] Trouble redirecting traffic on transparent bridge. Date: Sat, 3 Dec 2005 10:35:06 -0500 > > > > > >> From nat: > > -A PREROUTING -s $CLIENT_IP -p tcp -m tcp --dport 80 -j DNAT > > --to- destination 127.0.0.1:80 > > > > But the kernel sees the traffic as "martian" and disards them: > > Dec 1 15:09:45 last message repeated 9 times > > Dec 1 15:11:37 kernel: martian destination 127.0.0.1 > > from 172.16.110.139, dev br0 > > Dec 1 15:11:46 last message repeated 2 times > > > > The above part is what really matters... you can
Re: [LARTC] inspecting what's going in a class
On Mon, 5 Dec 2005 00:59:46 -0500 Jason Boxman <[EMAIL PROTECTED]> wrote: > > > > > > Sadly not possible with tc-filter. But perhaps I could do this for tc > > > with Vincent Perrier's sch_spy module. > > > > sch_log is also good for this: > > > > http://kernel.umbrella.ro/net/sch_log/v0.4/sch_log-0.4.tar.gz Question to All: I see that the patch applies against iproute2-2.6.11. Does the "2.6.11" part have anything to do with kernel version??? I.e. iproute2-2.6.11 has to be used with 2.6 kernel series? Regards -- Ethy H. Brito /"\ InterNexo Ltda. \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML +55 (12) 3941-6860 X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL S.J.Campos - Brasil / \ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Shaping per machine
Dnia poniedziałek, 5 grudnia 2005 13:58, Dave Weis napisał(a): > > That's because you are putting all /24 network into one single HTB. You > > have to make one HTB (SFQ for every user helps a lot too) for each > > computer in the network: > > > > tc qdisc del root dev eth1 > > tc qdisc add root dev eth1 handle 1: htb default 1 > > tc class add dev eth1 parent 1: classid 1:1 htb \ > > rate 1000Mbit ceil 1000Mbit burst 100kbit > > > > tc class add dev eth1 parent 1:1 classid 1:2 htb \ > > rate 64kbit ceil 256kbit quantum 2000 burst 10kbit > > tc qdisc add dev eth1 parent 1:2 handle 2: sfq perturb 5 quantum 1500b > > > > tc class add dev eth1 parent 1:1 classid 1:3 htb \ > > rate 80kbit ceil 320kbit quantum 2000 burst 10kbit > > tc qdisc add dev eth1 parent 1:3 handle 3: sfq perturb 5 quantum 1500b > > Do I still need to connect the IP to the class and qdisc with the filter > add command? Yes you do. I didn't write any because I mentioned hashing filters later ;) > > Putting all computers to proper HTBs with separate filters can make high > > load on your machine, so it is best to use hashing filters. > > Is there any rule of thumb on how much bandwidth you can handle for a > general size of machine? This is two 7 meg DSL connections, a 1.7 GHz > Celeron, and 200 users. I don't know, I was always working with hashing filters. But I heared people complaining about high load if they have big networks. Hash filtering goes like this: # create main filter divided into 256 filters... tc filter add dev eth1 parent 1:0 prio 5 protocol ip u32 tc filter add dev eth1 parent 1:0 handle 2: \ prio 5 protocol ip u32 divisor 256 # now we create many filters... they direct packets into # proper HTB. In fact they don't even have to check anything! # hash filtering will put packets into proper filter # (here is only checking if ip address is from proper network) # important: ht is defined in hexdecimal! # 1:2 ... 1:254 are HTBs for each user tc filter add dev eth1 protocol ip parent 1:0 \ prio 5 u32 ht 2:2: match ip dst 192.168.2.0/24 flowid 1:2 tc filter add dev eth1 protocol ip parent 1:0 \ prio 5 u32 ht 2:3: match ip dst 192.168.2.0/24 flowid 1:3 tc filter add dev eth1 protocol ip parent 1:0 \ prio 5 u32 ht 2:4: match ip dst 192.168.2.0/24 flowid 1:4 ... tc filter add dev eth1 protocol ip parent 1:0 \ prio 5 u32 ht 2:fd: match ip dst 192.168.2.0/24 flowid 1:253 tc filter add dev eth1 protocol ip parent 1:0 \ prio 5 u32 ht 2:fe: match ip dst 192.168.2.0/24 flowid 1:254 # now add the hashing filter - it takes the number from 16th byte # of IP header with mask 0x00ff - the last number of IP address # so it just reads one byte and directs packet to filter with # the same number (this filter sends it to proper HTB) - this is really fast! tc filter add dev eth1 protocol ip parent 1:0 u32 match ip dst 192.168.2.0/24 hashkey mask 0x00ff at 16 link 2: summary: check ip address -> go to filter numbered as the ip address -> redirect to HTB Position 16 in IP header is dst address. If you need src address (for example on IMQ interface for incoming traffic (upload from users)) then you need check address at position 12. some piece of example is also here: http://lartc.org/howto/lartc.adv-filter.hashing.html -- | pozdrawiam / greetings | powered by Trustix, Gentoo and FreeBSD | | Kajetan Staszkiewicz | JID: [EMAIL PROTECTED] | |Vegeta | IMQ devnames: http://tuxpowered.net| `^' ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Connmark question
I am trying to get IPP2P working on my router. Thus far I can see connections being marked (see below), but they don't seem to get saved or something. When looking at /proc/net/ip_conntrack, nothing has anything other than 0 for mark. The iptables commands for this are: iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j ACCEPT iptables -t mangle -A PREROUTING -m ipp2p --bit --dc --edk -j MARK --set-mark 3 iptables -t mangle -A PREROUTING -m mark --mark 3 -j CONNMARK --save-mark iptables -t mangle -A POSTROUTING -o ppp0 -m mark --mark 3 -j CLASSIFY --set-class 1:50 This is pretty much a copy of one of the examples from the ipp2p web site. When doing a iptables -t mangle -L -n -v -x, I get the following: Chain PREROUTING (policy ACCEPT 7179 packets, 1787132 bytes) pkts bytes target prot opt in outsource destination 799 161475 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore 00 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match !0x0 28 4372 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.7.4 --edk --dc --bit MARK set 0x3 28 4372 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x3 CONNMARK save Chain INPUT (policy ACCEPT 3388 packets, 610487 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 3789 packets, 1175165 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 2911 packets, 684078 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 6757 packets, 1866938 bytes) pkts bytes target prot opt in out source destination 15 1752 CLASSIFY all -- * ppp00.0.0.0/0 0.0.0.0/0 MARK match 0x3 CLASSIFY set 1:50 So I can see the packets are getting marked, or at least I see them being matched. Just don't know why the connection doesn't get shaped. Here's the stats from tc. class htb 1:50 parent 1:1 leaf 50: prio 5 rate 325000bit ceil 65bit burst 1639b cburst 1680b Sent 1752 bytes 15 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 15 borrowed: 0 giants: 0 tokens: 38314 ctokens: 19674 I am using kernel 2.6.11-6 and ipp2p 7.4 with iptables 1.2.9 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: IPSec tunnel and routing
> On Mon, 05 Dec 2005 10:42:23 +0100 > "AU" == Andreas Unterkircher <[EMAIL PROTECTED]> wrote: AU> AU> ip ro add 192.168.2.0/24 via 10.2.0.1 dev ethx src 192.168.1.1 AU> the spd policies will then match and encrypt the traffic. Uff... src in route... something really crazy, even thenks for the hint. Rather wild situation when one need to explicitly set up route for router own packets, while forwarded ones find their (same!) destination themself. -- Alexander Kotelnikov Saint-Petersburg, Russia ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: IPSec tunnel and routing
ip ro add 192.168.2.0/24 via 10.2.0.1 dev ethx src 192.168.1.1 the spd policies will then match and encrypt the traffic. this is the same solution like you have to do for the freeswan ipsec stack. for me it works... Alexander Kotelnikov ([EMAIL PROTECTED]) schrieb: > > > On Mon, 05 Dec 2005 06:08:30 +0100 > > "AU" == Andreas Unterkircher <[EMAIL PROTECTED]> wrote: > AU> > AU> Alexander Kotelnikov schrieb: > >> Ok, I would not ask all this if I have no problem with > >> tunnelling. With configuration like described above, where multihomed > >> maches have ip-addresses (192.168.1.1, 10.1.0.1) and (192.168.2.1, > >> 10.2.0.1) tunneling works for all machines, but these two > >> routers. This happenes becase if we send a packet from 10.1.0.1 into > >> 192.168.2/24 this packet does not come to ipsec, but is pushed to > >> default gateway, if it exists. In other words, local generated packets > >> do not come through prerouting or something. > >> > AU> You have to add a route on 10.1.0.1 to make sure packets which belong to > AU> 192.168.2.0/24 have > AU> a src address of 192.168.1.1. > > Very funny, how do you imagine this could be done? > > -- > Alexander Kotelnikov > Saint-Petersburg, Russia > > ___ > 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] HTB - prio and rate
Hi, It's not for a particular use that I was asking, it was just for my understanding. So what I think people are saying is: 1) The sum of all HTB classes under a single HTB qdisc should add up to the maximum rate of the qdisc 2) HTB's prio is only used when 'borrowing' bandwidth from other classes under the same HTB qdisc, then classes with a given prio will only be able to "borrow" bandwidth when classes with a lower prio have nothing waiting Is this correct? Many thanks, Mark Lidstone IT and Network Support Administrator BMT SeaTech Ltd Grove House, Meridians Cross, 7 Ocean Way Ocean Village, Southampton. SO14 3TJ. UK Tel: +44 (0)23 8063 5122 Fax: +44 (0)23 8063 5144 E-Mail: mailto:[EMAIL PROTECTED] Website: www.bmtseatech.co.uk == Confidentiality Notice and Disclaimer: The contents of this e-mail and any attachments are intended only for the use of the e-mail addressee(s) shown. If you are not that person, or one of those persons, you are not allowed to take any action based upon it or to copy it, forward, distribute or disclose the contents of it and you should please delete it from your system. BMT SeaTech Limited does not accept liability for any errors or omissions in the context of this e-mail or its attachments which arise as a result of Internet transmission, nor accept liability for statements which are those of the author and not clearly made on behalf of BMT SeaTech Limited. == -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian J. Murrell Sent: 02 December 2005 20:31 To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] HTB - prio and rate On Fri, 2005-12-02 at 21:25 +0100, Andreas Klauer wrote: > Actually, a class is always able to use it's rate at any time. The > prio has only an effect when the class is trying to borrow bandwidth > from others - then the high prio classes are allowed to take what they need first. I have wondered about something like this too. I want to simply prioritize my upstream bandwidth use, not limit it's use by anything. Just say (for example) that if an SSH packet is somewhere in the outbound direction when it hits the queue it gets put to the front of the queue to minimize the latency of SSH whereas something like bittorrent waits for SSH but otherwise gets full use of the upstream bandwidth. In fact if I were to saturate the upstream with SSH, something like bittorrent should effectively get no bandwidth at all. I think this is what Mark wants to, if I'm understanding him correctly. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: IPSec tunnel and routing
> On Mon, 05 Dec 2005 06:08:30 +0100 > "AU" == Andreas Unterkircher <[EMAIL PROTECTED]> wrote: AU> AU> Alexander Kotelnikov schrieb: >> Ok, I would not ask all this if I have no problem with >> tunnelling. With configuration like described above, where multihomed >> maches have ip-addresses (192.168.1.1, 10.1.0.1) and (192.168.2.1, >> 10.2.0.1) tunneling works for all machines, but these two >> routers. This happenes becase if we send a packet from 10.1.0.1 into >> 192.168.2/24 this packet does not come to ipsec, but is pushed to >> default gateway, if it exists. In other words, local generated packets >> do not come through prerouting or something. >> AU> You have to add a route on 10.1.0.1 to make sure packets which belong to AU> 192.168.2.0/24 have AU> a src address of 192.168.1.1. Very funny, how do you imagine this could be done? -- Alexander Kotelnikov Saint-Petersburg, Russia ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ip route doesn't not work with virtual inferfaces
You can specify the source address
ip route add 192.168.66.0/24 via 192.168.1.2 src {The_Source_IP_of_interface}
Radek Vokál ([EMAIL PROTECTED]) schrieb:
>
> I have two IP for eth0 which correspond to eth0 and eth0:1
> I want to create a route
> to 192.168.66.0/24 via 192.168.0.50 from eth0:1
>
> so I add the route with
>
> ip route add 192.168.66.0/24 via 192.168.1.2 dev eth0:1
>
> but when I connect to 192.168.66.0/24 network in connects still using
> the IP of eth0, not the IP of eth0:1 as one would expect.
>
> What's strange to me is that ip route list dev eth0:1 shows same output
> as ip route list dev eth0
>
> is this expected behavior or is there a bug?
>
> Radek
>
>
> --
> Radek Vokál <[EMAIL PROTECTED]>
>
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] ip route doesn't not work with virtual inferfaces
I have two IP for eth0 which correspond to eth0 and eth0:1 I want to create a route to 192.168.66.0/24 via 192.168.0.50 from eth0:1 so I add the route with ip route add 192.168.66.0/24 via 192.168.1.2 dev eth0:1 but when I connect to 192.168.66.0/24 network in connects still using the IP of eth0, not the IP of eth0:1 as one would expect. What's strange to me is that ip route list dev eth0:1 shows same output as ip route list dev eth0 is this expected behavior or is there a bug? Radek -- Radek Vokál <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Multi-ISP :- Multi-Wan Broadband Router Appliance VS Multiple eth Linux routing
Hi all I need to use three 512 kbps aDSL internet connections, in a load-sharing, link-failover scenario. Presently I am using Ipcop with a single DSL. Now, I seem to have two options...one..an Edimax quad wan port adsl router, with firewalling and NAT and second install a minimal linux distro for routing...something on the lines of LARTCand keep NATTING, IDS & Firewalling on the linux box, so that I can manage IDS/IPS slowly as I learn to do. However, I presently don't have the skill for a good LARTC multi-ISP implementation. Therefore, I am thinking of getting the Edimax router, provided I can keep the Natting, Firewalling & IDS at the Linux Gateway Server and giving over the load-sharing & failover function to the Edimax quad port adsl router or any other equipment suggested by the list (low budget please). Will I be losing my functionality in firewalling & IDS, if I use such a product? Or should I use a managed switch (not available less than 8 ports) and connect three different adsl routers or use a multi-port ethernet card and connect three different adsl routers...last two seem the same to me, as I will have to implement some sort of LARTC/iproute2 functionality by hit & trial and learning, while holding off the implementation. Can someone please suggest a solution that can decrease the birthing pains of this project ;-) Can someone suggest a canned script on LARTC lines or similar that can provide me load-sharing & link-failover facility, while I learn the subject, just like IPcop did for Natting, firewalling & IDS, while I learned the features. Haven't got to traffic-shaping as yet, but have tested a minimal fedora with own iptables scripts. Hope that this list will steer me in the right direction, like it always has. With best regards. Sanjay. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
