When the route doesn't have the specified gateway or nexthop it's scope
should be link(RT_SCOPE_LINK).
Otherwise it should be global(RT_SCOPE_UNIVERSE).
This is the problem in original XORP. Also how to tell XORP that there is no
nexthop in the following function call?
bool XrlRibV0p1Client::send_add_interface_route4 ( const char *
dst_xrl_target_name,
const string & protocol,
const bool & unicast,
const bool & multicast,
const IPv4Net & network,
const IPv4 & nexthop,
const string & ifname,
const string & vifname,
const uint32_t & metric,
const XrlAtomList & policytags,
const AddInterfaceRoute4CB & cb
)
Jiangxin
-----Original Message-----
From: Igor Maravic [mailto:[email protected]]
Sent: Tuesday, June 12, 2012 8:25 AM
To: Jiangxin Hu
Cc: Ben Greear; [email protected]
Subject: Re: [Xorp-hackers] XORP enhancement for wireless mesh network
routing
I've just tested. There is NO restriction when adding interface route.
I even wrote the tests to confirm that.
Also You can test my claim by adding interface route via static routes!
Only there is a catch.
If your neighboring router have address 192.168.3.1, and you want to have
all routes for 192.168.3.0/24 go via that router, you first have to add
192.168.3.1/32 interface route, and after that to add 192.168.3.0/24 route.
This is configuration to do that.
---
protocols {
static {
interface-route 192.168.3.1/32 {
next-hop-interface: "eth2"
next-hop-vif: "eth2"
}
interface-route 192.168.3.0/32 {
next-hop-interface: "eth2"
next-hop-vif: "eth2"
next-hop-router: 192.168.3.1
}
}
}
---
There was a problem with registering those routes in fea, but I fixed that
problem. I'm sending that patch to the list. Patches for enabling rib test,
you can find on my github.
BR
Igor
2012/6/8 Jiangxin Hu <[email protected]>:
> The restriction for subnetwork still there even you use
> add_interface_route function.
>
> The protocol should specify which interface a route go for. The
> current XORP-OLSR does not do this.
>
> By the way, I found to delete a wireless route also has problem.
>
> Jiangxin
>
> -----Original Message-----
> From: Igor Maravic [mailto:[email protected]]
> Sent: Friday, June 08, 2012 9:51 AM
> To: Ben Greear
> Cc: Jiangxin Hu; [email protected]
> Subject: Re: [Xorp-hackers] XORP enhancement for wireless mesh network
> routing
>
> Going through the code I found function:
>
> add_interface_route in RIB's xrl. With that function, route is
> directly added to the specified interface, no questions asked.
>
> If the OLSR would use that function it could add route as directly
> connected without any problem. Because I don't know any thing much
> about OLSR, I have to ask this - Does the route should be added to the
> interface from which it received advertisement?
>
> If that is the case, interface name could be propagated through the
> code, and instead of calling send_add_route, OLSR could call
> send_add_interface_route, with appropriate vif name.
> BR
> Igor
>
> 2012/6/1 Ben Greear <[email protected]>:
>> On 06/01/2012 02:09 PM, Igor Maravic wrote:
>>>>
>>>> Igor: Why should we ever restrict adding the connected routes?
>>>>
>>>> It seems to me that if the routing protocol wants it added, fea
>>>> should just do so. But maybe I'm missing something?
>>>>
>>>
>>> When the route comes to the RIB, if it isn't recognized as direct
>>> route, RIB assumes that this route is external one.
>>> This happens with BGP routes, because their nexthop is external.
>>>
>>> Because of that it will try to resolve the nexthop for that route
>>> with existing IGP routes.
>>>
>>> The BGP routes can't be resolved, if this behavior is overridden.
>>>
>>> Thus I think that the best solution would be if the OLSR would tell
>>> the RIB to add directly connected route.
>>> This will resolve the problem of RIB recognizing OLSR routes as
external.
>>> My proposition is to add function add_direct_route, that would be
>>> called via xrl from OLSR, the same way as add_route is called now.
>>> But that function would be in any doubt if it should resolve route
>>> as external or not.
>>>
>>> Maybe it is possible to check if route is resolved for wireless
>>> link, or not, from the add_route function, without braking the BGP
>>> route resolution, but I think that would stress out a performance
>>> dramatically. This is due the fact that before resolving any BGP
>>> route it would pass through all vifs to check if they are wireless
>>> or not (according to Jiangxin
>>> patch)
>>
>>
>> Ok, I haven't looked at this stuff in a while (and perhaps never in
>> great detail), so a new method: add_direct_route seems good to me.
>>
>> Better than changing behaviour based on an interface flag I think.
>>
>> Thanks,
>> Ben
>>
>>>
>>> BR
>>> Igor
>>
>>
>>
>> --
>> Ben Greear <[email protected]>
>> Candela Technologies Inc http://www.candelatech.com
>>
>
_______________________________________________
Xorp-hackers mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
