[Xorp-hackers] Query on Policy-Based Routing

[Kristian Larsson]

On Fri, Aug 12, 2005 at 08:48:03AM +0100, Mark Handley wrote:
> > I'm not sure, but I think he means actual traffic
> > coming from one interface should be forwarded down
> > one path and traffic from another to some other
> > path, ie not the actual route.
> > 
> > Something along the lines (on a cisco):
> > >
> > > interface FastEthernet 0/1
> > >  ip address 192.168.1.1 255.255.255.0
> > >  ip policy route-map example1
> > > interface FastEthernet 0/2
> > >  ip address 192.168.2.1 255.255.255.0
> > > ...
> > > ip route 0.0.0.0 0.0.0.0 172.20.1.1
> > > route-map example1 permit 10
> > >  set next-hop 10.0.0.1
> > >
> > >
> > > traffic from FE0/1 goes to 10.0.0.1 while
> > > everything else goes to 172.20.1.1
> > >
> > > Correct me if I'm wrong but XORP will never be
> > > able to do this since it doesn't forward traffic.
> > > It must be done by the kernel (unless the traffic
> > > is lifted out into userspace first) and can be
> > > done in for example Linux using iproute2.
> 
> I think you're right that you can't do this sort of thing in the
> normal kernel forwarding table on Linux or BSD.  I haven't looked at
> iproute2, but I'll take your work for it that it can do this.  You
> could also do this sort of thing with a Click-based forwarding path. 
> In neither case does XORP  have any way to configure this sort of
> kernel-forwarding rule at the moment.
On FreeBSD most of this can be done with IPFilter.
OpenBSD has it mostly implemented through pf. pf
can also do some really neat integration with
OpenBGPD. OpenBGPD can send a list with all
prefixes and their originating AS to pf which then
can filter based on AS. If XORP could do this it
would kick ass :)

> 
> The policy routing framework Andrea has been working on is just that:
> policy *routing*.  In other words it gives you a lot of control over
> how the routing protocols behave, but the general model of routing
> protocols still applies.  In particular, the routing protocols
> contribute routes to a RIB (actually 4 RIBs, one for each combinaton
> of {IPv4,IPv6} {unicast,multicast}).  For each RIB, there's only one
> final nexthop for a packet with a particular destination IP address.
> 
> The sort of rule you describe, I would call policy *forwarding*, to
> distinguish it from policy *routing*.  At this stage we only have the
> latter and not the former.  The two are clearly complementary.
> 
> From XORP's point of view, policy routing is critical to do well. 
> Policy forwarding seems mostly to deal with corner-cases - what I
> don't know is how common such corner cases are in the real world - I'd
> love some feedback on this.
The policy "routing" ( I agree with you that
forwarding is a better word for it, but AFAIK it
, de facto, still goes under the term policy 
routing) implemented on cisco routers is very
powerful, you could do quite a lot with 'em.
Still I think the example I gave is one of the
more common ones - to source route!
I'm using it get route a /27 to my home.
I have a tunnel between my "home" router (cisco
2811) and a router at work (7206). On the 7206 I
just set a static route for my net down through
the tunnel.
Since I have a default route on my Cisco at home
not pointing through the tunnel traffic that comes
through the tunnel will be sent out on my usual
connection when answered. With source routing I
route all packets from the /27 I have forwarded to
me, back through the tunnel.

There are other examples, one could use a
route-map to unset the DF bit before going through
a link which has a smaller MTU than the normal
1500 (even though this is better corrected for by
adjusting the MSS).

Mostly I'd say policy forwarding is used for what
we in Sweden would call a fulhack (c) which
roughly translates to "ugly hack".
A network which is properly built probably does
not need to use policy forwarding. 

Perhaps there are exception but I can't think of
an example where policy forwarding is the better
solution, it's almost always used as a substitute
for something more expensive or harder to setup.

> From a practical point of view, cross-platform support for
> policy-routing is pretty simple.  Cross-platform support for
> policy-forwarding seems really hard.  Are there a common set of a
> abstractions for policy-forwarding?  I haven't been tracking what the
> IETF ForCES WG has been doing in this space, so maybe there's
> something there.
AFAIK there are no standards for policy forwarding
or how it's implemented.
It's much like firewalls, everone knows what can
be done (filtering on ACK/SYN, ports, dst, src and
so on) but everyone has a different way to do it
and configure it.

//Kristian Larsson