>> I have a pseudo-interface driver that does [ip_src-based routing]:
> Thanks for the heads up.  This sounds useful in other contexts.

It is - or at least, I've found it so.

For example, my house gateway machine has its outside-facing interface
configured with an address on a /30 (why not /31? ask the provider!)
that's used just for that link.  Its default route conceptually points
out that interface.  But if I just had its default route point there,
then when it established a connection to the outside world, it would
use that unknown and irrelevant address, not the address it should be
using (which is its address on the house LAN).

So I gave it an srt interface, configured to send 0.0.0.0/0 to the
other end of the netlink, with the srt's local-end address set to
duplicate that machine's house-LAN address and the actual default route
pointing to the srt's other-end address (which is a 1918 address).

I pay a very slight performance penalty for each packet that uses the
interface because of the extra layer of calls, and another very slight
performance penalty because a few kernel data structures are slightly
larger (another interface, a few more routes in the routing table).
But that machine isn't running anywhere near the edge; I consider the
price trivial compared to the benefit of getting the addresses right.

> In this context we actually have three transit ISPs connected, plus
> peering at an interchange. We have both provider independent
> addresses and provider dependant addresses.  We have a full routing
> table.

As written, srt uses linear search to figure out where to send packets.
If you want to have a lot of different outgoing tunnels, as it were,
you may want to convert it to use the radix tree code used by the
normal routing tables.

Of course, like (almost) all my stuff, anyone's welcome to a copy of
the srt code.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B