Just set it to IPv4::ZERO(), or IPv6::ZERO(). 2012/6/12 Jiangxin Hu <[email protected]>: > > 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
