Re: [LARTC] High Latency With Tiered Queues
ISN Support Staff wrote: Hello, I'm trying to setup what I thought would be a fairly basic tiered shaping system. I have a 6mbit (768kbps) link coming into my eth1 device, with my LAN IPs on the eth0 device. I want to limit outgoing traffic so that certain IPs are limited to 400kbps, with 3 classes under that 400k so certain machines get prioritized (main servers in 1:21, other servers in 1:22, workstations in 1:23) The problem is that when I turn this on, my packet latency jumps up by 50 to 100 times the normal rate. I go from 10-20 ms ping times to 500-1600ms! I've tried putting SFQ qdiscs under the classes, but that makes no difference. I'm sure there is just some tuning parameter I'm not setting correctly, but can somebody clue me in to what I'm doing wrong? Or is HTB just the wrong scheduler to be using here? I tried CBQ, but I can't get the tiers to work ( I keep getting RTNETLINK answers: Invalid argument) I'm currently using a single tiered CBQ solution, but it really doesn't fit my needs. Here's the full script: --- qdisc add dev eth1 root handle 1: htb default 10 Using htb default will send arp to a really long (in this case) backlogged queue, which could cause problems. Generally you need to classify low latency traffic to different class than bulk if you want it to stay low latency. I am suprised sfq didn't help - maybe you also need to back off the ceils to allow for overheads on the quoted link speed. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: dropped bytes in tc -s class output
Ethy H. Brito wrote: On Sun, 20 May 2007 22:56:23 +0200 Christian Benvenuti [EMAIL PROTECTED] wrote: Hi, Hi All Is there any output that counts the number of dropped bytes (not packets) just as in Sent in tc -s class output? No. A simple workaround (for simple configurations) consists of redirecting all the traffic you want to drop to a dedicated class and attach a blackhole qdisc (i.e., drop everything) to it. Hmmm. I am pretty sure I did not tell what I meant. I assume that at some point an HTB class will drop some packets that are beyond its speed regulation, right? Not always if it's got a really long queue tcp windows can be absorbed. You can choose queue length. I just need to measure this amount of dropped bytes (not packets). I don't think you can. With this measure I can MRTG it and give the clients some felling that they really need more bandwidth. That would be a bit deceitful - TCP relies to some extent on dropped packets, how many you get depends on buffer lengths and number of connections. You could double the rate with a smaller buffer and see more dropped packets than a slower link with a bigger buffer. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] rate limiting netmask w/ dd-wrt
Ryan O'Toole wrote: I'm trying to setup a DD-WRT router (www.dd-wrt.com; embedded micro-device linux for the uninitiated) to rate limit all the traffic it receives from its wi-fi interface. Qdiscs work on traffic leaving the interfaces. If you want to limit incoming traffic have a look at the policer example in LARTC, there are other ways using ifb/imq, but I don't know if dd-wrt will have those. Wireless is a special case - half duplex, so it's going to be even harder to do. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Proxy ARP with a Coyote Point equalizer
Here is a puzzle. I have a network with several servers. It's a mess. It's a /24 and pieces and servers are all over the place inside this /24 block, on both sides of the firewall. For example, the router at 1.2.3.1 is outside the firewall and many of the servers at 1.2.3.nnn/24 are behind the firewall. (Obviously, 1.2.3.nnn is a fudged network.) eth0 points outward to the Internet. eth1 points inward to the serers. Both eth0 and eth1 have IP Address 1.2.3.2. I setup proxy ARP like this: echo 1 /proc/sys/net/ipv4/conf/eth0/proxy_arp echo 1 /proc/sys/net/ipv4/conf/eth1/proxy_arp And I set up appropriate routes to the systems on both sides of the firewall. This all works - all the systems route the way they are supposed to route. Here is the problem. Behind the firewall is a Coyote Point Equalizer at 1.2.3.10, with a high-volume website behind it spread across several servers. Every time I put this proxy ARP firewall in place, that nasty Coyote Point box dies and this breaks the high volume website behind it and makes lots of people mad. I've never seen a Coyote Point Equalizer but I have a hunch it might not get along well with a proxy ARP device in its same network. Here are my questions: Proxy ARP really means proxy ARP - that firewall answers ARP requests for anything and everything it sees, for any network. This also has consequences for new devices that try to be polite when they set IP Addresses for themselves by ARPing to see if anyone else answers at that address. Is there a way to limit proxy ARP to a list of IP Addresses? Or - should I forget proxy ARP and look at bridging instead? Can I do bridging and still access the bridged interfaces remotely? Thanks - Greg Scott [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Proxy ARP with a Coyote Point equalizer
On 5/30/2007 6:46 PM, Greg Scott wrote: Here is the problem. Behind the firewall is a Coyote Point Equalizer at 1.2.3.10, with a high-volume website behind it spread across several servers. Every time I put this proxy ARP firewall in place, that nasty Coyote Point box dies and this breaks the high volume website behind it and makes lots of people mad. I've never seen a Coyote Point Equalizer but I have a hunch it might not get along well with a proxy ARP device in its same network. Hrm... Proxy ARP really means proxy ARP - that firewall answers ARP requests for anything and everything it sees, for any network. This also has consequences for new devices that try to be polite when they set IP Addresses for themselves by ARPing to see if anyone else answers at that address. Is there a way to limit proxy ARP to a list of IP Addresses? This will be Proxy ARP implementation specific. I have no idea whether or not Linux can be configured to behave as you are asking or not. Or - should I forget proxy ARP and look at bridging instead? Having just (briefly) brushed up on Proxy ARPing, I can see how it would be a problem for a load balancer. Most load balancers work on a couple of different levels, either IP - MAC spoofing, or NATing. The former method is probably what is happening and thus having a problem with your Proxy ARP router / firewall. Consider if you will a host out side of the Proxy ARP router / firewall trying to connect to an IP address that is both behind the Proxy ARP router / firewall AND the load balancer. If the load balancer changes the MAC address that the IP address belongs to, the Proxy ARP router / firewall will inevitably end up pointing to the wrong internal MAC. How will the load balancer handle the traffic when it does not start flowing to the alternative MAC like it wants? I can not say. But, I do see a very big potential for a conflict. In said conflict, I can not say any thing to how any of the equipment will fail. Thus, you could end up in the scenario you are in now. I can't say for sure as to whether or not you should forget about proxy ARP or not, but I can say for sure that bridging will do what you are wanting to do very well. Bridging will pass the ARP requests in directly to the load balancer like it is expecting so that it can control things the way that it wants to. This means that when the load balancer alters the IP - MAC mapping, the upstream device on the other side of the bridge will see the changed MAC address. I think I would go the bridging route. Can I do bridging and still access the bridged interfaces remotely? Most definitely! Put your IP address on the bridge interface. I.e. eth0 and eth1 are bridged together by br0. ifconfig br0 1.2.3.2 netmask 255.255.255.0 You will be able to access 1.2.3.2 from either side of the bridge. That is presuming that you do not use EBTables / IPTables to filter the bridged traffic. In other words, so long as you are not doing any layer 2 filtering yes. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Multihome load balancing - kernel vs netfilter
Before we get into the Top-posting stuff, it would be nice if you follow the normal way of replying (or atleast marking a copy) to the list. I think that is the basic idea behind mailing list. If you had done that, I wouldn't have had to do the Top-Posting. Take a look at the archives please. -Original Message- From: Luciano Ruete [mailto:[EMAIL PROTECTED] Sent: Thursday, May 31, 2007 12:26 PM To: Salim S I Subject: Re: [LARTC] Multihome load balancing - kernel vs netfilter On Wednesday 30 May 2007 00:58:18 you wrote: First of all, learn about basic[1] mailing list rules, mainly your top-posting[2] is breaking all the sense of the thread Sorry, but it doesn't work that way yes it does. Up to you if you refuse to accept, doesn't matter for me if you choose to live in your little world. CONNMARK needs helper modules like the ones for FTP or H.323 to really know if connections belong to the same session. To cover all gaming and IM apps with own helper modules is practically impossible. this helpers are needed because some special protocols have special needs, all other protocols are covered in a simpler maner bye flowing the tcp flow between two ports, you need al least a litle low level knowldge about layer 3-4 protocols to undestand this. Yessir. 3 bags full. If you had read my post c l e a r l y, before you felt obliged to show off your knowledge, you might have understood that I was talking about the so-called 'special-protocols'. Btw, thanks for that bit about TCP flow between two ports, was quite new to me. I remember even MSN have had problems (timeout every 5 mins), but it seems to have been fixed at the server level. With CONNMARK solution 99,99% of the things works, i am the sys/net-admin from an ISP that proves it, whit load balancing over multiple links. Sorry again! That figure of '99.99' is in YOUR case, but are you aware there are others in this world too, with different scenarios/setups? You did not think Peter and I were dreaming up a scenario,did you? Btw, your being a netadmin doesn't automatically make your statements correct. For each protocol that are not covered by simple tcp flow a helper module was written. It must be a well kept secret then! I am sorry to say this, if your knowledge was half the size of your ego, it would have been good for us all. Could you please point out if I had missed any open discussion in the list which covers these things? just google(ie): connmark site:lartc...archive Thanks for introducing google. But my question still stands. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
