- 802.1Q VLAN Implementation for Linux (site)
VLANs are a very cool way to segregate your
networks in a more virtual than physical way. Good information on VLANs can
be found here. With this implementation, you can have your Linux box talk
VLANs with machines like Cisco Catalyst, 3Com: {Corebuilder, Netbuilder II,
SuperStack II switch 630}, Extreme Ntwks Summit 48, Foundry: {ServerIronXL,
FastIron}.
A great HOWTO about VLANs can be found here.
Update: has been included in the kernel as of 2.4.14 (perhaps 13).
- Alternate 802.1Q VLAN Implementation for Linux (site)
Alternative VLAN implementation for linux. This project was started out of
disagreement with the 'established' VLAN project's architecture and coding
style, resulting in a cleaner overall design.
- Linux Virtual Server (site)
These people are brilliant. The Linux Virtual Server is a highly scalable and
highly available server built on a cluster of real servers, with the load
balancer running on the Linux operating system. The architecture of the
cluster is transparent to end users. End users only see a single virtual
server.
In short whatever you need to load balance, at whatever level of traffic, LVS
will have a way of doing it. Some of their techniques are positively evil!
For example, they let several machines have the same IP address on a
segment, but turn off ARP on them. Only the LVS machine does ARP - it then
decides which of the backend hosts should handle an incoming packet, and
sends it directly to the right MAC address of the backend server. Outgoing
traffic will flow directly to the router, and not via the LVS machine, which
does therefor not need to see your 5Gbit/s of content flowing to the world,
and cannot be a bottleneck.
The LVS is implemented as a kernel patch in Linux 2.0 and 2.2, but as a
Netfilter module in 2.4/2.5, so it does not need kernel patches! Their 2.4
support is still in early development, so beat on it and give feedback or
send patches.
- CBQ.init (site)
Configuring CBQ can be a bit daunting, especially if all you want to do is
shape some computers behind a router. CBQ.init can help you configure Linux
with a simplified syntax.
For example, if you want all computers in your 192.168.1.0/24 subnet
(on 10mbit eth1) to be limited to 28kbit/s download speed, put
this in the CBQ.init configuration file:
DEVICE=eth1,10Mbit,1Mbit
RATE=28Kbit
WEIGHT=2Kbit
PRIO=5
RULE=192.168.1.0/24 |
By all means use this program if the 'how and why' don't interest you.
We're using CBQ.init in production and it works very well. It can even do
some more advanced things, like time dependent shaping. The documentation is
embedded in the script, which explains why you can't find a README.
- Chronox easy shaping scripts (site)
Stephan Mueller (smueller@chronox.de) wrote two useful scripts, 'limit.conn'
and 'shaper'. The first one allows you to easily throttle a single download
session, like this:
# limit.conn -s SERVERIP -p SERVERPORT -l LIMIT |
It works on Linux 2.2 and 2.4/2.5.
The second script is more complicated, and can be used to make lots of
different queues based on iptables rules, which are used to mark packets
which are then shaped.
- Virtual Router
Redundancy Protocol implementation (site)
This is purely for redundancy. Two machines with their own IP address and
MAC Address together create a third IP Address and MAC Address, which is
virtual. Originally intended purely for routers, which need constant MAC
addresses, it also works for other servers.
The beauty of this approach is the incredibly easy configuration. No kernel
compiling or patching required, all userspace.
Just run this on all machines participating in a service:
# vrrpd -i eth0 -v 50 10.0.0.22 |
And you are in business! 10.0.0.22 is now carried by one of your servers,
probably the first one to run the vrrp daemon. Now disconnect that computer
from the network and very rapidly one of the other computers will assume the
10.0.0.22 address, as well as the MAC address.
I tried this over here and had it up and running in 1 minute. For some
strange reason it decided to drop my default gateway, but the -n flag
prevented that.
This is a 'live' fail over:
64 bytes from 10.0.0.22: icmp_seq=3 ttl=255 time=0.2 ms
64 bytes from 10.0.0.22: icmp_seq=4 ttl=255 time=0.2 ms
64 bytes from 10.0.0.22: icmp_seq=5 ttl=255 time=16.8 ms
64 bytes from 10.0.0.22: icmp_seq=6 ttl=255 time=1.8 ms
64 bytes from 10.0.0.22: icmp_seq=7 ttl=255 time=1.7 ms |
Not *one* ping packet was lost! Just after packet 4, I disconnected my P200
from the network, and my 486 took over, which you can see from the higher
latency.
