Here comes several options: 1. reject local next hop w/ EINVAL 2. delete route when local next hop removed 3. transition between RT_SCOPE_HOST amd RT_SCOPE_LINK 4. document it
which one should we choose ? 1 will definitely cause compatibility problem 2 is the easiest solution 3 need a bit of code, not sure if worth it On Mon, Aug 10, 2015 at 5:16 AM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > Hello, > > Zang MingJie <zealot0...@gmail.com> writes: >> Days ago I mistakenly set the gateway address on my box, then add the >> default router, after I deleted the address my box can't access >> Internet and all things looks fine. It takes me several hours to >> figure out it is an kernel bug. > > I don't consider this a kernel bug. > >>>On Sat, Aug 8, 2015, 1:00 AM Hannes Frederic Sowa >>><han...@stressinduktion.org> wrote: >>>If we could rewind time, we could make local nexthops -EINVAL. >> >> I don't think this is the proper solution. As almost all network OS >> considers the routing table recursive, and it's next hop can be any >> unicast ip address. > > You are talking about ios, junos, no? > > Linux does not have any kind of recursive routing table. It only helps > by doing a first-hop lookup during insertion time, that's merely it. If > you want to compare Linux to a "network OS" you would have to install > quagga/bird/xorp/... on a box to get the same behavior. > > Also notice that we don't talk about adding/removing addresses to > interfaces but what the routing code considers are the routes which get > created because of those address changes (like the subnet route added in > IPv4 if you install an address with subnet on an interface). Thus we > shouldn't make address changes special, we would have to reevaluate the > complete FIB/routing-table (I guess everyone is talking about something > different here) at the time we only change a route. And this is a no-go. > > I don't see a problem with adding a "recursive routing table" to the > stack if people need that. I just don't see the need for that. > >> When the next hop is unreachable the entry won't be installed. > > In a recursive routing table, the entry could be installed but it will > only get into effect when the nexthop turns reachable. > >> I suggest adding a new sysconf entry, when not set, behavior as the >> same as now, when set recalculate the fib when necessary > > A new sysctl would work, but I don't consider it necessary. I don't > think we need the additional code for that. Kernel does not run routing > protocols and those are normally the only ones which need to do that. > >> BTW is there any way to check the fib table? > > I don't understand the question. Do you mean > > ip route get xx.yy.zz.aa ? > > Bye, > Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
