[Xorp-hackers] XORP enhancement for wireless mesh network routing

[Igor Maravić]

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 <jiangxin.hu at crc.gc.ca>:
> 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:igorm at etf.rs]
> Sent: Friday, June 08, 2012 9:51 AM
> To: Ben Greear
> Cc: Jiangxin Hu; xorp-hackers at icir.org
> 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 <greearb at candelatech.com>:
>> 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 <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>