Slashdot Mirror

On RHEL7 and similar, net-tools is no longer installed by default, you should use the 'ip' command from iproute2, see http://lartc.org/howto/lartc.i... . ifconfig and 'route' for Linux have been on the deprecation path for years, before systemd existed.

I think since RHEL6 the Red Hat documentation and training material stopped referring to ifconfig.

But lets not pretend its perfect. NetworkManager used to constantly cause my Xen server to lose its networking. 'systemctl restart NetworkManager' caused it to come back - after hooking up a keyboard and mouse. Systemd's networkd can't bring up ppp connections - it doesn't know what they are - and last time I tried it choked on bridges.

So, you fall back to the good old 'chkconfig network on' and remove everything networkd and NetworkManager related. But now wait-online doesn't work for systemd - so anything that requires the network to be up will cause issues - requiring other hacks to bring back into line.

So yeah, its not perfect, and some stuff is still broken.

Systemd is terrible and what they've been doing to Linux is also terrible.

You're assigning guilt for too many things to systemd.

No more simple ifconfig to set an ip address.

On RHEL7 and similar, net-tools is no longer installed by default, you should use the 'ip' command from iproute2, see http://lartc.org/howto/lartc.i... . ifconfig and 'route' for Linux have been on the deprecation path for years, before systemd existed.

I think since RHEL6 the Red Hat documentation and training material stopped referring to ifconfig.

You need to create a file in /etc/network/eth-whatever and add some options.

This has been the way to create persistent network configuration for years (since Red Hat 5.3).

(And it's /etc/sysconfig/network-scripts/ifcfg-${INTF})

No more "route" either, so how do you set a route?

ip route add

'ip route' is significantly better than 'route', e.g. 'ip route get ip.add.re.ss' will change your life.

Oh and the best part is things like nslookup and traceroute are not included by default!

So, install them (e.g. 'yum install bind-utils traceroute') . You can resolve names (the way most normal processes would, e.g. looking in /etc/hosts or other sources of host information as configured in /etc/nsswitch.conf) using 'getent hosts', that should be sufficient on most general-purpose servers (if you don't need to look up SRV or MX or TXT records etc.).

Neither is "man" which I had to install manually.

What distro are you talking about? This *really* has nothing to do with systemd ...

Sure give me 10,000 obscure and buggy libraries but not include core utilities like nslookup? Oh and I almost forgot. On a completely idle system, systemd is using the most cpu time out of everything else. So nice of my startup manager is the top resource hog.

On an idle system that has been up for 10 minutes, systemd has consumed less than 1 second of CPU time. A *real* resource hog</sarcasm>

Your boss should have prevented you from abusing your network in this manner. Use rsync with compression enabled and be done with it.

Here's an article about the huge latency caused by bittorrent traffic on your network.

For a fix of your latency problem see: LARTC ultimate traffic conditioner I use it and do not experience these latecies on my *home* network and it also explains reasons for this to occur.

It is not caused only by bittorrent traffic it's caused by any heavy traffic on home networks. It is a fairly common phenomenon with home routers and home internet connection. This is not experienced in serverhousing networks. Also I talk about uploading sustained ~170 MBytes/second on average with peaks of ~3GBytes/second (almost one DVD per second), highly available and to thousands of clients at once all around the world from many servers on many continents.

Bittorrent have more overhead than e.g. rsync. The number of connections isn't really problem (at least in our serverhouse, they can handle, they're paid for it and our clients connect only to our mirrors -- about 10 of them) but the possibility of having any mirror shut down and traffic balancing among all our mirrors ... well I cannot see any possibility of this being done with rsync :-) And it also doesn't qualify as abuse :-) Or you can say CDNs abuse the whole internet :-) Anyway Popcorn Time like client would be great for porn sites :-) cheap hosting + bittorrent + popcorn time and almost CDN like streaming. Perfect use case. I do not condone pirating stuff from intenet, but bittorrent is a great technology which is without it normally implemented by a very very expensive hardware.

1. Set up OpenVPN on the datacenter Linux server to act as your Battlefield endpoint (single IP + port).
2. Set up 2 VPN connections, one from each phone, to that box.
3. Set up a Linux box to act as a router at home. Use bluetooth or whatever to connect it to your mobile connections.
4. Follow the directions here http://www.lartc.org/autoloadb... on how to set up iptables rules as needed on both Linux boxes.
5. Modify the iptables rules as needed to your specific requirements.
6. Keep on modifying iptables. It will take days to work out all the kinks.
7. Verify that your latency problems still exist.

Or for the lazy: http://lartc.org/wondershaper/

Slick script that sets up all your QoS rules for you to prioritize interactive traffic over bulk traffic, makes it easy to limit bandwidth used by a "guest network" interface to an arbitrary limits to leave some headroom for your gear , etc. etc.

Some examples:
http://www.ubuntugeek.com/use-bandwidth-shapers-wondershaper-or-trickle-to-limit-internet-connection-speed.html

There isn't an easy answer to your question. In general, bufferbloat is when you get latency or jitter issues because some network device upstream of you has a large buffer, which it fills before it starts dropping your packets. The dropped packets is how software relying on TCP is notified of network congestion so it knows to throttle back. Other protocols may be affected differently (you might notice VoIP delay or bad lag on your xbox).

To combat this, the idea is to limit your traffic in buffers you control which are (typically) smaller than your ISP and modem's buffers so the ISP ones stay empty and highly interactive. In general, this means limiting your data rates to lower than your bandwidth and prioritizing packets by interactivity requirements. The linux kernel additions in 3.3 allow you to set your buffer size smaller for the entire interface with the goal being to reduce the delay induced by the linux router/bridge. It also adds the ability to prioritize traffic and limit buffers by cgroup (which is like a process categorization or pool which has certain resource limits), but this isn't particularly helpful in your forwarding situation.

For my own QoS setup, I usually use a script similar to this HTB one. It requires some tuning and getting your queue priorities right requires some understanding of the traffic going through your network. A lot of high level netfilter tools (smoothwall, dd-wrt, etc) have easier to use tools QoS tools which may better suit your purposes. Having not used one, I'm not in a position to recommend them.

The easiest is to pick up a dual wan router, which will do the load balancing for you. Something like a SYSWAN SW24 would probably work. Some firewalls, like WatchGuard and Cisco also have dual or quad WAN ports, and can be set up for load balancing, but they are going to be more expensive.

Alternatively, you can set up a linux box with multiple network cards to do the job for you.
http://lartc.org/howto/lartc.rpdb.multiple-links.html

Can they actually throttle OpenVPN though? I was under the impression that it goes on port 443 and looks like normal SSL traffic unless you decrypt it.

By default OpenVPN is UDP traffic over port 1194, although you can use TCP over 443.

The behaviour of OpenVPN over TCP differs quite a bit in packet flow compared to most HTTPS requests. While both use OpenSSL over TCP, HTTPS requests typically follow the pattern of : connect -> short burst of data -> short burst of data from client -> long burst of data from server -> short burst of data from client -> long burst of data from server -> disconnect (according to http Keep-Alive).

This differs from OpenVPN which tries to keep the connection open as long as possible (and upon disconnect reconnects almost immediately). The packet flow doesn't typically follow the short burst from client -> large burst from server pattern, since we're not dealing with HTTP underneath. A good way to throttle OpenVPN usage over TCP at port 443 is to throttle port 443 on the client side to allow for short bursts of data, but not allow sustained bandwidth intensive usage. Typical P2P usage even when the client isn't uploading much requires much more data from the client side than HTTP does. You can accomplish this on your average linux box with QOS, but that requires a bit of reading of the Linux Advanced Routing and Traffic Control HOWTO. It's a very enlightening document as to how the linux networking stack works, although it's quite a dry subject.

And yes, you're going to hinder things like HTTPS file uploads of large files, but all in all that's something not many people need so the damage you do is pretty limited.

You might want to look into load-balanced routing. I had a linux box with 3 NIC's, one NIC per ISP and one NIC to the rest of the house. I set it up for load-shared routing via the LARTC HOWTO, and for web traffic it worked ok.

I didn't stay with it because it wasn't stable for VPN connections. The decision about which upstream link to use was somehow governed by the local/remote host pairing, plus some unknown-to-me modifier. So I could establish a VPN connection, but it wouldn't keep the connection through 1 of the two links consistently. As soon as it tried to switch the VPN connection to route through the other uplink, pow, there went my VPN session. I don't recall the exact time before failure but it was less than 2 hours in most cases. made it basically unusable for me, at that time, for working from home. Perhaps that's solved(or can be configured around) by now.

I don't know/remember how it works for p2p either, though, since it was so long ago and the decision about which upstream path for any outbound traffic to take is controlled by the kernel on that routing box.

here's the relevant section of the LARTC HOWTO, in case you want to read more or try it out:
http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN298

A router should support both modes simultaneously, offering itself as two access points. Encrypted links should have higher packet priority over nonencrypted links, so that guest access can't starve out authorized users.

You can also do this without having two access points.
I would use OpenWRT on a cheap consumer-grade router.If you want to provide a guest network as well as a secure, encrypted network for yourself, you could install a VPN solution on the router, e.g. OpenVPN. You would then connect to your unencrypted WiFi but then tunnel all your traffic over the VPN. The guest user can just connect normally. That also allows you to restrict guest users to some services, as well as using different QoS and traffic shaping (bandwith throttling) settings. Some info on traffic shaping on Linux routers can be found here, as well as here (specific to openwrt)..

There is a nice table of hardware supported by OpenWRT here.
I wouldn't say that is an easy way the average consumer could do though. It requires some knowledge of Linux as well as Networking.

Linux:
http://lartc.org/wondershaper/
http://lartc.org/howto/

Cisco:
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml#policingvsshaping

D-Link:
http://www.dlink.com/products/?pid=651

Linux:
http://lartc.org/wondershaper/
http://lartc.org/howto/

Cisco:
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml#policingvsshaping

D-Link:
http://www.dlink.com/products/?pid=651

What I'm telling you to do, technically, is never to fill your pipe (very bad practice). ISPs never fill their pipes more than 60%, if they can help it. Install something like DD-WRT and rate-limit both sides of the connection to 95% of the link bandwidth (60% is better, but I'm guessing you're not game). Allow it to buffer like crazy, but to prioritize new connections.

That'll solve your latency issues (of course, not 100%. SOME slowdown is unavoidable, regardless of algorithm used, if you are on a connection where transmitting a single packet takes 4 ms (typical dsl), please don't complain about any slowdown less than 8 ms, nothing can be done about it, except upgrading).

Or you could just use a linux router : http://lartc.org/howto/lartc.qdisc.html

And frankly, we have lots of people complaining like you. Sometimes I feel like helping them. Guess what one finds 95% of the time when inspecting their traffic (often at their request, and often, even after the packet dumper removes all doubt, they STILL claim not to be running kazaa and/or bittorrent. Then we go "let's try blocking it, then. If you're not using it anyway", and *surprise* that solves the problem. Then they ask to turn the block off)

Something doesn't compute with what you're saying. It would take quite an artificial situation to cause this behavior.

Perhaps if you've been downloading an iso for an hour or so, and then start browsing that you'll have to wait for the iso download connection to drop a packet, but come on, is that so bad ?

If you're browsing and downloading you shouldn't notice any slowdown.

You want to fix this ? Read this : http://lartc.org/howto/lartc.qdisc.html (or install a ready-made router distro and enable qos).

TCP contains some of the most incredible heuristic algorithms I've ever seen. Each algorithm, like Slow Start, RTT Estimation, SACK, etc. are relatively simple but together they work incredibly well at keeping data flowing across heterogeneous networks. They work so well that I've seen TCP overcome broken ethernet drivers and make them appear to work. Unfortunately, as someone who use to look at TCP traces for a living, I can tell you it can be really hard to work backwards from packet traces to figure out what is going on in the TCP/IP stack because there can be so much going on at the same time. This means that Wireshark in the hands of a weekend-hacker can easily lead to erroneous conclusions. If you follow this link and go to section 14.5 Random Early Detection (RED) you can see that the issue is already known and there are already solutions to mitigate the problem.

Relax and take a deep breath. Now you can move on to something more important......... like where you're going to spend your eternity

However, most of us here know enough about networking that we realize that no matter what any kind of "priorisation" will come at the expense of everyone else. Even if you don't have saturation, your discrimination protocol is running and taking up router CPU time, adding to the latency, etc.

Not necessarily true - many network technologies simply don't degrade gracefully towards 100% saturation, which means that you can be using only a small fraction of your hypothetically available bandwidth yet performance goes to hell.

It's possible to set up QoS to avoid this issue, making better use of available bandwidth - which involves making trade-offs based on latency and reliability - and if done carefully, you can make overall performance much more predictable without significantly slowing it. Obviously you can't give two HTTP downloads 10Mbps each when you've only got a 10Mbps link, but you can ensure things like VoIP and SSH remain usable when such demand is being placed on the link. The difficult bit is configuring everything appropriately.

There exist scripts for Linux firewalls which attempt to do this in a fairly idiot-proof "one-size fits all" fashion. A well-known example of this is Wondershaper.

(Disclaimer: my employer produces QoS software, though I'm not directly involved in that bit).

It's actually pretty easy in linux. http://lartc.org/howto/lartc.qdisc.classless.html#AEN691 In fact, http://lartc.org/ has loads of good stuff.

It's actually pretty easy in linux. http://lartc.org/howto/lartc.qdisc.classless.html#AEN691 In fact, http://lartc.org/ has loads of good stuff.

I used QoS with iproute2 and iptables (see http://lartc.org/howto) when I faced that issue.
I do not mean to say I had room mates, but when I used bittorrent and noticed how it abused the network, I used that howto to limit it's bandwidth.

It worked very nice.

Linux & iproute2 should be more than enough for what you want.

"Routing for multiple uplinks/providers"

Once the load balancing has been stablished you can set up OpenVPN to encrypt the traffic between the two (I like using openvpn + brigde to do a Layer 2 vpn). You can even get more fancy and add traffic shaping to distribute bandwith, prioritize packets (for a lower latency in ssh or terminal server traffic for example).

If we are to have telemedicine, displacement of copper telephone infrastructure, etc., then we do need guaranteed levels of service for some things.

Traffic shaping is not necessarily opposed to net neutrality. I see nothing wrong with prioritizing traffic based on how much a customer paid, or how much bandwidth they've used recently, for instance. An ISP account should come with X gigabytes/month of "first class" service, where you get to decide what to send/receive first class, and the rest is bulk. I have wasted too much time kluging with LARTC. Traffic prioritization needs to be end-to-end, not just at the network layer of one end.

You're right. This is just another example of how the technology itself is not malevolent but rather how its employed.

That being said, I can assure you that simply by reviewing the level of divisive manipulation of traditional corporate media, while technological advancement have historically entailed a net benefit for purveyors of truth(thinking here, printing press, telephones, etc), it also has enabled morally bereft institutions to expand and refine their influence on the hearts and minds of the masses. Now we're talking about a fundamental change in the infrastructure of the internet which could easily force social dissonance or protesting underground by simply making it inaccessible, thus negating all of the great advancements in information transparency we've achieved on an *almost* fully open internet. An open internet is exceedingly difficult to control, and malevolent corporations have made little headway here like that seen in print, television, radio, etc.

On another note, the suppression of thought and technology permeates every facet of our modern lives, and now with the explosion of the internet we not only have an abundance of air and water but also information, which quite certainly is the most important tool in mitigating and extinguishing the suppressive and unaccountable corporate influence over our lives. This to me is indicative of a greater economic and social transition resulting in the replacement of antiquated short-term socially detrimental corporate group-think with something so open and free that none of us can possibly fathom its colossal magnitude.

IMO, defeating net neutrality, or enabling corporations to do so(even with the best of intentions), will result in humanities failure once again to recognize and respond adequately to threats to the our overall social and economic cohesion. Quite simply, in order for humanity to succeed as Bill Hicks said "..as one race explor[ing] outer space together in peace, forever." we must educate and enlighten people in order to encourage reform and the discontinuation of the broken components of our establishment.

Traffic shaping is not necessarily opposed to net neutrality. I see nothing wrong with prioritizing traffic based on how much a customer paid, or how much bandwidth they've used recently, for instance. An ISP account should come with X gigabytes/month of "first class" service, where you get to decide what to send/receive first class, and the rest is bulk. I have wasted too much time kluging with LARTC. Traffic prioritization needs to be end-to-end, not just at the network layer of one end.

15 Euros for cFoss? I'll stick to http://lartc.org/wondershaper/

Linux gateways make sense because the firewall, the AV, the traffic shaper, everything runs at no monetary cost.

As someone above pointed out - it's ironic to pay for services and software that enable you to download stuff you aren't willing to pay for......

Can't help you with the paying for extra bandwidth, but the wondershaper has helped my limited speed home network remain responsive during downloads.

HTB is Hierarchical Token Bucket, a CBQ (Class Based Queueing) discipline for Linux. It lets you create a hierarchy of queues for a network link. The "Token Bucket" part means each leaf and node in the tree has a "bucket" that constantly, slowly fills with tokens. Sending a byte removes a token. So, on average, you're only guaranteed the fill rate, but if you haven't used it for a bit, you can send a burst until your bucket is empty. Extra tokens can be borrowed between nodes if they're not used by the others, up to the max rate. Thus you get minimum guarantees, max limits, and bursts, such as being able to quickly fetch a web page even if the link is full from others' usage, if you haven't used up your tokens.

For instance, you could have Customer A, Customer B, and Customer C at the top level, and then they each have a second level of HTTP, BitTorrent, and SSH. Customer A and B get a rate of 128k, and C gets 512k since he pays extra as a business customer. They all have a max rate of 6M, since that's the speed of their DSL lines, and a burst size of 1MB. Then, they have SSH (with a small rate and a small burst), HTTP (with a high rate and a large burst), and BitTorrent (with a 1k rate, and a small burst).

As long as Customer C isn't using any bandwidth, A and B can use it all. As soon as C wants to use some, he first gets his guaranteed 512k - no matter what - and then they all split any leftovers in proportion to their committed rates (So A gets a share, B gets a share, C gets four shares). If C only wants 512k, A and B each get to split all the leftovers evenly.

If A is using BT like mad, but then opens an HTTP connection, it'll be allowed most of his net connection (it has a high rate, but still lower than the full line speed). BT will automatically (and instantly) be throttled until HTTP is done. When he types on the SSH connection, it'll use little bits of its burst speed to refresh the window instantly, but its small rate won't let it consume the whole net if he accidentally cats /dev/urandom.

Sounds great, right? There are a few gotchas: You can only queue packets like this when *sending*. What're you going to do, receive a packet from the slow link and then delay it before sending it over the fast one that's not saturated? (Well, yes, you can, and it makes a limited amount of sense to fine tune TCP's flow control, in addition to selectively dropping packets to make it back off, and other tricks.) It's good, but it doesn't necessarily make optimal tradeoffs between latency and bandwidth - HFSC is an attempt to address this. Also, this is a moderately heavyweight way to do things. It has to spend some CPU classifying packets, and memory to track the buckets' state, so other queueing disciplines and schedulers exist that work on other methods (such as statistical, instead of discrete tracking), that are more appropriate for very large ISPs. Also, as a large ISP, you're going to be using Cisco, not Linux, for routing. :) But Cisco has sophisticated QOS as well.

Despite how complex this sounds, even using the simplest case on your home router will make a huge improvement in the weak side of your DSL line, the uplink. Several of the open source WIFI router firmwares support it out of the box for this reason. I have survived having my web site on my DSL linked to the front page of a popular site known to bring servers to their knees, without any lag in SSH or games, or interruption of mail or other services. We only noticed because our bulk transfers slowed to a crawl, as intended.

Learn more:

HTB: http://luxik.cdi.cz/~devik/qos/htb/ (the user guide has a good overview and pretty graphs)

HFSC: http://linux-ip.net/articles/hfsc.en/ (More pretty graphs and good explanation)

Linux Advanced Routing and Traffic Control list: http://lartc.org/ (The howto is out of date, but very enlightening)

Not have to shut down other applications because my 4 BitTorrent connections are making my email logon time out and my web browser not load images on the pages (assuming it can even load the page to begin with)?

This can be fixed quite easily if you simply manage your upstream bandwidth appropriately.

Read this for details of why this is happening to you, and what needs to be done to fix it.

Can't load balance hosted services without a remote router? Round robin DNS with short TTLs, with a script to remove an IP if a link goes down.

Outgoing TCP connections are OK when using Linux:

http://lartc.org/lartc.html#LARTC.RPDB.MULTIPLE-LINKS

If you buy an off the shelf solution from the likes of F5 there's even more control.

I recently set up a similar setup, but instead of load balancing across the two connections for everything, I needed to construct rules that decided if certain types of traffic (irc, http, etc.) went across which connections. If you choose to use any type of linux-based router, iproute2 will probably be what you'll be using, even if it is abstracted by some type of graphical tool. Consider the following links explaining iproute2:

The Linux Foundation's iproute2 page:
http://www.linuxfoundation.org/en/Net:Iproute2

These guys seem to be maintaining iproute2 now.

The "Linux Advanced Routing & Traffic Control HOWTO": http://lartc.org/howto/

This is probably the most thorough document on iproute2 and will cover absolutely everything you would need to know about it.

Specifically, look into load balancing:
http://lartc.org/howto/lartc.loadshare.html

This excellent page also explains how to make iproute2 and iptables interact with each other, so you can use iptables rules to mark packets for iproute2 to route over a certain interface:
http://lartc.org/howto/lartc.netfilter.html

Finally, this document provides some basic information about how to manipulate rules with iproute2, which is useful if you're trying to diagnose why it's not working correctly:
http://www.policyrouting.org/iproute2-toc.html

I recently set up a similar setup, but instead of load balancing across the two connections for everything, I needed to construct rules that decided if certain types of traffic (irc, http, etc.) went across which connections. If you choose to use any type of linux-based router, iproute2 will probably be what you'll be using, even if it is abstracted by some type of graphical tool. Consider the following links explaining iproute2:

The Linux Foundation's iproute2 page:
http://www.linuxfoundation.org/en/Net:Iproute2

These guys seem to be maintaining iproute2 now.

The "Linux Advanced Routing & Traffic Control HOWTO": http://lartc.org/howto/

This is probably the most thorough document on iproute2 and will cover absolutely everything you would need to know about it.

Specifically, look into load balancing:
http://lartc.org/howto/lartc.loadshare.html

This excellent page also explains how to make iproute2 and iptables interact with each other, so you can use iptables rules to mark packets for iproute2 to route over a certain interface:
http://lartc.org/howto/lartc.netfilter.html

Finally, this document provides some basic information about how to manipulate rules with iproute2, which is useful if you're trying to diagnose why it's not working correctly:
http://www.policyrouting.org/iproute2-toc.html

I recently set up a similar setup, but instead of load balancing across the two connections for everything, I needed to construct rules that decided if certain types of traffic (irc, http, etc.) went across which connections. If you choose to use any type of linux-based router, iproute2 will probably be what you'll be using, even if it is abstracted by some type of graphical tool. Consider the following links explaining iproute2:

The Linux Foundation's iproute2 page:
http://www.linuxfoundation.org/en/Net:Iproute2

These guys seem to be maintaining iproute2 now.

The "Linux Advanced Routing & Traffic Control HOWTO": http://lartc.org/howto/

This is probably the most thorough document on iproute2 and will cover absolutely everything you would need to know about it.

Specifically, look into load balancing:
http://lartc.org/howto/lartc.loadshare.html

This excellent page also explains how to make iproute2 and iptables interact with each other, so you can use iptables rules to mark packets for iproute2 to route over a certain interface:
http://lartc.org/howto/lartc.netfilter.html

Finally, this document provides some basic information about how to manipulate rules with iproute2, which is useful if you're trying to diagnose why it's not working correctly:
http://www.policyrouting.org/iproute2-toc.html

look for the Linux Advance Routing Howto

:^D

Somewhere in that site it talks about some of the problems of having 2 IP addresses, like confusing game servers and the like, but with a bit of tweaking you could get it functional. I don't think this solution explicitly provides failover functionality, but I suppose that could be scripted in somehow.

pfsense is a nice turnkey solution for this too, if you're not into spending a couple weeks solid trying to make your debian or lfs distro act like a router.

db

I was thinking about a similar scenario and found this website:
http://lartc.org/howto/lartc.rpdb.multiple-links.html

I haven't tried it yet, but it seems do-able (in the non-sexual way).

http://lartc.org/howto/lartc.loadshare.html

Check it out.

You might as well just get yourself a power-efficient linux-powered router and set up tc properly to guarantee an uplink bandwidth slice to VOIP. (There are various recipes on lartc.org to help you with this.

Downlink bandwidth management is slightly more complicated, but you can sort of manage it by droping or delaying non-voip packets which are coming in too fast to keep your ISPs queue empty.

• The ADSL Bandwidth Management HOWTO from TLDP is what got me started. It is quite outdated by now, though.
• The Advanced Routing HOWTO from TLDP. In particular, sections 9, 9.5 and 9.5.5. Note that it was outdated even when I read it, which was several years ago (you haven't had to patch your kernel to get HTB since 2.4.20 or so).
• The LARTC site and mailing list archives.
• The HTB home page.
• The manpages tc(8) and htb(8). (I wish they had existed when I learned about it.)

http://lartc.org/wondershaper/

Works in Linux since 2002.

*yawn*

Agreed. I'd specifically recommend the "Wonder Shaper" http://lartc.org/wondershaper/ from the kind, albiet insane, folks at the Linux Advanced Routing & Traffic Control site.

Careful though; spending too much time there might cause mental grief (for example, go read Section 12.1.3 of the LARTC HOWTO), but I digress.

On the other hand, if you're fluent in this and/or like working in the kernel networking stack, shoot me an email/message, cause I've got a fun job for you.

Agreed. I'd specifically recommend the "Wonder Shaper" http://lartc.org/wondershaper/ from the kind, albiet insane, folks at the Linux Advanced Routing & Traffic Control site.

Careful though; spending too much time there might cause mental grief (for example, go read Section 12.1.3 of the LARTC HOWTO), but I digress.

On the other hand, if you're fluent in this and/or like working in the kernel networking stack, shoot me an email/message, cause I've got a fun job for you.

If you're using Linux, which TCP Congestion algorithm are you using? Reno isn't very fair; if a single connection is congested beyond the first hop, you'll slow down the rest of your connections when the window slides to smaller units. Have you tried Bicubic, Veno, or any of the other 9 or 10 congestion algorithms?

You can change them on the fly by echoing the name into your procfs, IIRC. Also, if you have the stomache for it, and two connections to the internet, you can load balance and/or stripe them using Linux advanced Routing & Traffic Control (mostly the ip(1) command). Very cool stuff if you want to route around a slow node or two (check out the multiple path stuff) at your ISP(s).

Check out "policy routing", its been in Linux now maybe 7 years. /sbin/ip route add table 10 0/0 via 10.0.0.1 dev eth0 /sbin/ip rule add from 10.0.0.0/24 table 10 pri 10

Should be along the lines of always routing traffic from 10.0.0.0/24 via gateway 10.0.0.1 on device eth0.

This problem isn't actually TCP code as your short sighted comment implies but I suppose you got the general networking area right in your thoughts so you aren't completely clueless. It's not recommended network practice to have two NICs in the same subnet (unless the NIC is designed for failover and is viewed as one from a MAC address perspective). Maybe the LARTC mailing list can help you at http://lartc.org/. May I wish you every success overcoming your problems but next time don't blame the tools when the user is naive.

What the heck good is 500M of free storage when it still takes way too long to upload 500M of data? I seem to get around 70k/s upload speed on my Cox cablemodem (business cablemodem, I think I have 512k/s upstream) and it takes two hours to upload 500M. The average user will take even longer.

I currently use Amazon S3 for storage (mostly backups) and I have 100G of stuff on there for my 4 monthly full backups. It takes me 4 full days to upload a full backup. So I spend nearly a quarter of the month constantly uploading! Thank the FSM that I have a Linux box doing QoS using the fine Wondershaper script so I don't even notice the uploading.

Linux has very powerful traffic shaping capabilities.

Check it out: http://lartc.org/

If you're running Linux, you can try out WonderShaper. I have been using it since 2003 and it works great on keeping the SSH connection running 100% while other traffic is chugging along.

Download speed dropping when upload reaches a certain number is a problem inherent to ADSL technology. You didn't experience it on Comcast, because that is a cable connection. Part of the problem is the Asynchronous aspect. The big speed difference between ACKs being sent "up" acknowledging receipt of the packets you've received "down" and the speed of the packets arriving "down".

Also exacerbating the problem are the huge queues that ISPs typically employ to reduce packet loss and improve the perception of download speeds. (This is also the reason your ssh session will seem slow if you are also downloading other content.) One fix for this is to throttle yourself to slightly below the speed of the connection to avoid your packets being hung up in the ISP's queue.
The LARTC has a cookbook section for how to do this with your linux router/firewall: http://lartc.org/howto/lartc.cookbook.ultimate-tc. html

Or for those already running a linux firewall on iptables, wondershaper... well... works wonders. I'm on a 15/2 FiOS line and had a roommate for a while that was on bittorrent *constantly* streaming 10 things at a time. We're talking 24/7. I couldn't play ANY game without lag. Slap wondershaper in, it tweaks things up based on the line speeds you hand it, and bam. Problem solved.

Sure if you know enough about iptables you can do the tweaks yourself, but when somebody writes a script that you understand when you read it, why not just use that instead? ;-)

The article doesn't mention QoS, for me this was the main reason I got the wrt54g and openwrt. You can put traffic control on there and shape/limit the traffic going through. Together with the marking of packets from iptables this is a very powerful function only usually available on much more expensive kit.

I used it so I could play FPS without latency problems when other users were on the LAN. It would also really help out for VoIP.

I guess Linksys won't advertise this fact, which is a shame as it could make this a huge seller, partly because their supplied firmware doesn't support it and partly because they want to push people towards Cisco kit for this kind of functionality. Plus the average user probably isn't able to flash openwrt/dd-wrt onto the box and then write their own firewall/tc rulesets. Maybe someone should write a nice web frontend to TC and start reselling wrts with it installed....

I have a very low upload cap, around 15 KBPS, and when it gets maxed, I'd like to be able to limit the connection just a little, to leave room for ACK packets.

As far as a feature goes, it's really a complete non-story. Aside from the inefficiency of shaping traffic on every client computer as opposed to the router, it's also the sort of thing that you can do with ease on linux.

For a home router I recommend taking a look at the Fairnat script http://www.metamorpher.de/fairnat/ although it doesn't include rules for firewalling - you have to do that yourself.

To take full advantage of traffic shaping a connection on linux for users who use p2p it's a good idea to get a version of iptables (or compile your own) with the ipp2p module. It can match against pretty much all p2p protocols that people use (bittorrent, edonkey, soulseek etc).

That'll allow you to prioritise your interactive traffic (ssh, IRC, instant messengers), let your mid-priority traffic (HTTP, IMAP, POP) come in and then put your bulk transfers and p2p lower down in terms of priority.

If you've just got the one machine connected to a broadband modem then take a look at the wondershaper http://lartc.org/wondershaper/ script which will shape traffic on your machine.

Hi!

In the university where I work, we made use of HTB (http://luxik.cdi.cz/~devik/qos/htb/) along with other "traffic shapping" tools. I don't have the scripts on hand, but it is based on the "wondershaper" you can find here: http://www.lartc.org/howto/lartc.cookbook.ultimate -tc.html I just spaiced it up with IMQ.

Anyway, at our university we gave everyone a public IP address, because it was already done that way. But I proposed to change it (it hasn't been done yet, but it will). My proposal is as follow:

Assign private IP addresses via DHCP (previous 802.1x auth, or at least MAC access control, yes the address goes static becuase the DHCP have MAC-based IP address assignation), and add several "localized" IDSs and have one traffic shaper at the Internet link. The traffic shaper have simple rules: high priority to "real time" protocols,medium to "bulk" preffered traffic (http, mainly), slighly lower to "not interactive" protocols (like SMTP), and low to the rest (here you will have BT, or whatever). The idea is: if there is nothing better to do with the link, you will have fast BT download.

As for these kind of services, we decided to use more than one IP address and to SNAT instead of MASQUERADE on them, and then have each pool of address into one external address. Then, we create (via script, off course), the DNAT rules for port forwarding for income conections, and assign two ports to each internal IP (two TCP, two UDP (the same port numbers, but for TCP and UDP), then we would inform the users wich external IP/ports where assigned to each workstation (we are still not sure if publicate the info in the intranet server, or if we would send a massive e-mail). The idea is: the user have two TCP and two UDP ports, he/she will decide what to do with these (they could even create a web server or whatever), the thing is: they are being watched (no it detail), but we do internal scans of network to identify which services are running on each computer, and we have rules that forbid having SMTP. We have the ports firewalled (outgoing), but they could still have and "incoming" SMTP, and thus we would detect it, and inform the responsable user.

Yes, all of this is done with a Linux computer (well, more than one if you count the IDS).

Anyway, this is a "resumed" version of the idea, because I have no time to explain it all, but at least the "special services" are covered.

Hope this helps,

Ildefonso Camargo

Here at my university, in the dorms connections have a 24 hour rolling bandwidth quota (updated hourly) of 750mb off campus traffic, which is sufficient for the overwhelming majority of users. Connections are not speed limited up to 750mb of traffic. After the 750mb has been reached, the user is placed into a "Class B" tier of service where connections are limited to 128kbit per flow. If the traffic exceeds 1gb per 24 hour period, users are moved into "Class C" service, which is 512kbit pool for all users in that tier. This system worked very well for us, allowing normal usage but curbing the people that abuse the connection. http://www.lartc.org/ has excellent documentation on how to get a setup like this up and running