[Xorp-users] Problem adding routes to custom devices

[Jeff Mitchell]

On 05/19/2010 06:04 PM, Ben Greear wrote:
>> I have a suspicion as to what may be wrong...here's the relevant output
>> of "ip link":
>>
>> 4: eth0.801 at eth0:<BROADCAST,MULTICAST,UP,LOWER_UP>   mtu 1500 qdisc noqueue
>>        link/ether 00:50:56:9e:1f:7f brd ff:ff:ff:ff:ff:ff
>> 6: abcd0:<BROADCAST,MULTICAST,NOARP,UP,LOWER_UP>   mtu 1500 qdisc
>> pfifo_fast qlen 100
>>        link/void 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd
>> ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00
>> 7: pimreg at NONE:<NOARP,UP,LOWER_UP>   mtu 1472 qdisc noqueue
>>        link/pimreg
>>
>> Note the type of "link/void" -- is it possible that XORP refuses to set
>> routes pertaining to this link because of the link type, even though it
>> will give the interface an IP address? If so, is there a way to disable
>> this/fix this/prevent this? Or any other idea what's going wrong?
>
> I'd say that's likely.  Can you just fix your network driver so that
> it claims to be Ethernet?  That's what other virtual drivers, such as 'veth'
> do...

 From what I hear, the answer is "maybe" -- in that they do have that 
option but it's not working right :-(

One thing the guys here told me is that void is a legit link type in the 
kernel with a configurable link layer address size. The address size 
above is 128-bit; however from poking around at the XORP source code it 
seems that it makes assumptions all over the place that the link layer 
addresses are 48 bit.

However, maybe that's not always the case. I still don't know why it 
successfully sets IP addresses to those interfaces, but won't set a 
route. I suspect that code handling the interfaces is written and/or 
behaving differently in different parts of XORP.

Does this sound like it could be the culprit, and if it's something that 
might be able to be fixed/made consistent? If so, could someone point me 
to where might be a good place to look?

> You might look though the logs in detail, maybe searching for 'static', to
> see if that module is complaining and not even attempting to set the route
> through fea.

I actually compared logs from running with a normal interface vs. our 
custom interface and they were basically identical.

I did see this:

[ 2010/05/19 17:19:21.86898  INFO xorp:3702 RTRMGR 
rtrmgr/module_manager.cc:94 execute ] Executing module: static_routes 
(xorp_static_routes)

[ 2010/05/19 17:19:21.98138  WARNING xorp:3702 XrlFinderTarget 
obj/x86_64-unknown-linux-gnu/xrl/targets/finder_base.cc:482 
handle_finder_0_2_resolve_xrl ] Handling method for 
finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target 
"static_routes" does not exist or is not enabled.

But, they appeared in *both* logs, including using the normal interface 
where the routes were successfully set.

--Jeff