[Xorp-users] Problem adding routes to custom devices

Ben Greear greearb at candelatech.com
Thu May 20 09:26:49 PDT 2010


On 05/20/2010 07:51 AM, Jeff Mitchell wrote:
> On 05/20/2010 10:35 AM, Jeff Mitchell wrote:
>> 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.
>
> Looks like I spoke a bit too soon on that point. If I change the address
> type:
>
> 6: abcd0:<BROADCAST,MULTICAST,NOARP,UP,LOWER_UP>  mtu 1500 qdisc
> pfifo_fast qlen 100
>       link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
>
> then still no dice. It's possible that XORP doesn't like the all-zeros
> address in this situation -- or the problem lies elsewhere, perhaps in
> some unsupported call being used when trying to set the routing information?

There may indeed be issues with > 48 byte 'MAC' addresses, but I'm not
sure that would show up in routing table issues.

The logic that actually sets such stuff in Linux should be in the
netlink related logic.  Setting interface logic is in fea/ifconfig/*set_netlink*,
and the routing stuff is in fea/fibconfig/*netlink*

Some other logic will actually tell fea to add/delete routes, and it's
possible the error lies there.  I'd add logging to the route setting
logic to see what it tries to set.

Thanks,
Ben


>
> --Jeff
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



More information about the Xorp-users mailing list