I'm trying to implement a research routing protocol, and I've come
across a situation where I think having the routing engine use an
external resover would fit the bill perfectly. As I was trying to grok
the code, I came across rtm_type RTN_XRESOLVE which indicates that it is
used for an external resolver. It seems that it is not implemented yet.
My guess at what the semantics should be is that when a packet is to be
sent down this route, we add a destination cache with dst_entry.output =
dst_blackhole so that this packet, and others like it, will be
discarded, and send a rtnetlink broadcast message indicating the
particulars of the route to be resolved. The user space portion of the
resolver would hear the rtnetlink message, resolve the route, and modify
the destination cache route to actually point in the right direction.
I'm getting a bit confused in the details of implementing this, however.
(It doesn't help that I'm still trying to understand the routing code
completely -- man there's a lot of it to read!) It seems to me that I'll
have change fib_semantic_match() in fib_semantics.c to just return when
it sees a RTN_XRESOLVE type, and to fixup fib_props so that it doesn't
generate an instant -EINVAL. And maybe there's some touchups in
fib_create_info().
It looks like ip_route_output_slow() is the next routine that needs
changing. I think I can just add a test for type == RTN_XRESOLVE in the
make_route part of the routine, right before seting dst_entry.output to
ip_output, and do my thing there, like so:
rth->rt_gateway = key.dst;
rth->rt_spec_dst= key.src;
+ if(res.type == RTN_XRESOLVE)
+ {
+ // kick off a rtnetlink message to resolve this route
+ }
else
rth->u.dst.output = ip_output;
if (flags&RTCF_LOCAL) {
rth->u.dst.input = ip_local_deliver;
rth->rt_spec_dst = key.dst;
}
I'm a little concerned about kicking off a netlink message in this
routine, but I think that's the way I'm going start attacking this from.
Also, I don't really want to push the handling of RTN_XRESOLVE down to
the protocols -- I'd rather handle it in the core, but I just don't see
a great way to do that without letting an error escape back to the
application.
I'm hoping someone can look at this and tell me if I'm on the right
track, or better yet, point me in the right direction, either on the
semantics or the code.
Thanks all,
David Dillow
dillowd@y12.doe.gov
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
