[ILUG] ip route equalize

[Ronan Mullally]

A back to school question for everybody ;-)

I've got a scenario as shown below:

   +-----------+                            +-----------+
   | linux src |=========== Internet -------| linux dst |
   +-----------+                            +-----------+

There are two (or more) paths from the src box to the Internet.  It is
sending traffic to the dst box, and wants to balance UDP traffic across
these multiple links.  Traffic in the other direction is not an issue.

Sane options like Multilink PPP are not avaialble.  Less sane options like
running IPSEC/VPN tunnels are not available.  The option I'm left with is
to load balance outbound traffic across the links.  The insane twist is
that these packets will need to be source NATed on egress, but let's
ignore that for the moment.

I'm trying to use the equalize flag to the ip route command.  I can set up
a multipath route okay:

 # ip route add 172.16.0.0/24 equalize nexthop dev dummy1 nexthop dev dummy2

 # ip route show
 172.16.0.0/24 equalize
        nexthop dev dummy1 weight 1
        nexthop dev dummy2 weight 1

And would expect to see a ping to a host in the above range to send
packets via each link in turn.  It doesn't.  It sends all traffic via the
first path, so the routing decision is getting cached rather than
re-calculated per packet.

The man page for 'ip' indicates that the kernel needs to be patched to
support equalisation.  I was hoping that CONFIG_IP_ROUTE_MULTIPATH would
be sufficient, but it's not.  I've found the patch I think the man page
refers to at http://trash.net/~kaber/equalize/equalize_2.4.18.patch but
it doesn't apply cleanly against a recent 2.6 kernel.

Am I missing something obvious, or can anybody think of a more elegant
solution?  The only other alternative I can think of (apart from trying
to re-write the patch for 2.6) is the eql driver in the kernel, but that
looks well and truly dead (circa 1995) and I don't think it'll work in a
reverse-path-filtering environment.


-Ronan