Tuesday, August 18, 2009

Atlanta LinuxFest

Wanted to drop a quick note about ALF...

I'll be speaking at the Atlanta LinuxFest, talking about the Ubuntu Kernel. This will talk about the team, how we develop & maintain the Ubuntu Kernel.

In fact there are several Canonical folks talking at ALF.
  • Steve Conklin - Kernel Debugging
  • John Pugh - The Weather Ahead - Clouds
  • Ken VanDine - Ubuntu Desktop Experience
  • Rick Clark - Ubuntu Server
Along with all the speakers noted above, members of the Ubuntu Kernel Team will be conducting a driver writing session. This is based on GregKH's original driver writing presentation. We will be using a USB thermometer as the hardware and the object is to write a working driver that will get the current temperature.

Along with ALF there will be a Ubucon (Ubuntu User Conference). The Ubuntu Kernel Team will be holding a "Is your hardware ready for Karmic" workshop. We will have USB sticks loaded with a testsuite that will test most of the new Karmic hardware features like Kernel Mode Setting (KMS), grub2, net/notebook hotkeys, web cams, audio and the like. This is non destructive to the hard disk and will let folks know in advance about what the Karmic experience will look like on their hardware. If items fail to work we will file bugs on the spot with the proper debugging info attached to the bug.

I want to give a huge shout out to Manjo Iyer & Ronald Fader who have spent lots of time and hard work to make the testing happen and to John Johansen for putting together the driver writing session! Great work guys

More on ALF as it gets closer.

~pete

Split Routing Over 2 DSL Lines

Its been a bit since I've blogged last. Most of it is due to moving. We moved from Raleigh NC to a small town in the western part of NC called Union Mills. The good thing is we are on a farm, we have lots of land, space, fresh air... however the Net connection just plain sucks.

I'm 2.3 miles from the CO, so the best I can get with DSL is a 3m/384k connection thru AT&T. So I called AT&T commercial and was assured I could be 2x bonded ADSL lines that would give me effectively a 6mb connection. Guess what? The fibbed. In the end I had to settle for 2x ADSL lines not bonded, and I elected for the non-commercial option since it was far cheaper.

Now came the big question how to best effectively use em'. After hitting up Google I found lots of interesting solutions. Most were very complex, routing various protocols out this interface or that.... I wanted something that would give me the closest to a load balanced connection as possible.

I'm using a old HP Desktop with 3 network cards as my gateway router running Jaunty 9.04 Server Edition.

Below is what I came up with using ip route and iptables. I put in bogus IPs to keep it as real as possible.

First I added two routing tables to the /etc/iproute2/rt_tables file:

1 line1
2 line2

Then I found a script on the net and used it as a template and hacked it up as so:

#!/bin/bash

# DSL Lines are IF0 & IF1, IF2 is local net.
IF0=eth0
IF1=eth1
IF2=eth2

# IP Addr on Gateway matching interfaces above
IP0=192.168.1.1
IP1=192.168.2.1
IP2=172.31.0.1

# DSL IPs
P0=192.168.1.254
P1=192.168.2.254

# Network addresses
P0_NET=192.168.1.0
P1_NET=192.168.2.0

# Routing table entries
T1=1
T2=2

# Set up routes
ip route add $P0_NET dev $IF0 src $IP0 table $T1
ip route add default via $P0 table $T1
ip route add $P1_NET dev $IF1 src $IP1 table $T2
ip route add default via $P1 table $T2

ip route add $P0_NET dev $IF0 src $IP0
ip route add $P1_NET dev $IF1 src $IP1

# Set up default route to balance between both interfaces
ip route add default scope global nexthop via $P0 dev $IF0 weight 1 \
nexthop via $P1 dev $IF1 weight 1

# Add the rules for the routing tables
ip rule add from $IP0 table $T1
ip rule add from $IP1 table $T2

# Now for the masq bits
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t filter -F
iptables -t filter -X
#iptables -t nat -A POSTROUTING -o $IF0 -j MASQUERADE
#iptables -t nat -A POSTROUTING -o $IF1 -j MASQUERADE
iptables -t nat -I POSTROUTING -s 172.31.0.0/24 -j MASQUERADE

# Turn on ip_forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -i $IF2 -s 172.31.0.0/24 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Flush routing every four hours
echo 144000 > /proc/sys/net/ipv4/route/secret_interval

It works like this... Each time a connection is established outbound, the server will decide which interface to route it out of. This should be a rough 50/50 split. The server decides based on congestion and a few other factors. Only one connection can only ever be established over the same route.

If I was start a download, it will only ever utilize a single connection, another download from the same IP will also utilize the same connection. This is due to the kernel having already cached the route. If a 3rd download to a new server was to be started it will likely be established over the second connection due to the first route being congested and the second route is idle.

The route will be flushed 4 hours after the first download completes, then a new decision with be made on how to contact the original server.

I've been using this for a bit now and it seems to do what I need it to do... give me a faster response time when I have intensive net operations going on, like vonage & rsync's to offsite machines.

By no means am I a iptables or routing guru. If anyone has any other suggestions or better ways to do it I'd love to hear them.

~pete