Policy routing and multipath routing needed (override routing table)

[Oleg Tarasov]

Hello,

Many people know how to engage policy routing using ipfw forward
function. This can be successfully used on simple routers (not NAT
gateways) and to make gateways with multiple internet connections
provide services (such as DNS, mail etc) on all interfaces.

But the difficulty comes when the box itself is the source of packets.
For example when mail server sends mail to another server. In this
case the source ip of packets is calculated using routing table based
on the destination address. These packets can't be correctly routed
using policy as in this case we should probably pass these packets
through NAT that is not always acceptable and is difficult to perform
using standart tools as forwarded packets are not injected into
firewall to be diverted through NAT.

The easiest way to show this need is a simple planning of interface
load division between internet interfaces based on services (for ex.
proxy, dns, mail, ftp etc).

In this case simple routing table can not provide what we need.

The second thing to be mentioned is known as multipath routing. It is
a special situation of policy routing but is more easy to develope. It
can solve some problems too.

I have found a mentioning of developing these functions as "planned"
by FreeBSD developers in march 2004 (http://kerneltrap.org/node/2593).

The obvious solution of this problem lies in using of Cisco router but
this is not good for medium-size business organization due to lack of
funds (you know those bosses) as thas router costs like another
routing machine ;)

It would be great to hear from core team of their plans regarding this
network stack changes.

There is another problem. In my opinion it should be great to make one
more attribute to routes in routing table indicating of their
activity/inactivity. The source of this problem is that all static
routes on reconfigured interface are deleted as ip changes. If this
reconfiguration occurs we need to recreate these routes again. It
would be great if they would persisted and for that time were
"inactive".

One of the solutions in this case would be a tool for monitoring
interface state able to activate some script on state change. This
would be great for failover for example.

Please enlight me and tell if there is any.

-- 
Best regards,
 Oleg Tarasov                          mailto:subscriber at osk.com.ua