On Sat, Sep 03, 2016 at 05:32:01PM +0200, Martin Pieuchot wrote: > On 08/31/16 23:49, Andrei-Marius Radu wrote: > >[...] > >Coming from a cisco/juniper background it's perfectly valid for a static > >route to point > >to a non-directly-connected next-hop as long as the next-hop can be > >recursively > >resolved. I guess that for bgpd/ospfd the indirection is resolved by the > >protocol > >daemon before adding the route into the kernel. > > I understand your concern. However we're currently trying to decouple data > structure in order to make them readable by multiple CPUs at the > same time without loosing performance. > > >If it's in any way useful I can run some tests on an older snapshot to show > >that > >packet forwarding was actually working fine. > > That would be interesting. If you can include the output of "rouge get" > for the various destinations included in the indirection as well as the > route table output that would be great. > > >If on the other hand the current behaviour is considered the correct and > >expected one > >then I'll just have to adapt to it and not forget to thank everyone for a > >great operating > >system. > > It's currently not planned to support next-hop that can be recursively > resolved as this would either result in using atomic primitives in the > hot path or having to deal with some cache invalidation problem. >
I'm surprised that recursive lookups worked. Our stack only ever did one lookup to resolve the gw to a link local address. I totally agree with mpi here and see no need to add this feature. The kernel routing table is the FIB and sshould therefor be tuned for speed and the userland daemons (bgpd, ospfd, ...) should do the lookup from exit nexthop to true nexthop and insert routes with directly reachable nexthops. -- :wq Claudio
