Hello, On Thu, 21 Jun 2018, Grant Taylor wrote: > On 06/21/2018 01:57 PM, Julian Anastasov wrote: > > Hello, > > > http://ja.ssi.bg/dgd-usage.txt > > "DGD" or "Dead Gateway Detection" sounds very familiar. I referenced it in an > earlier reply. > > I distinctly remember DGD not behaving satisfactorily years ago. Where > unsatisfactorily was something like 90 seconds (or more) to recover. Which > actually matches what I was getting without the ignore_routes_with_linkdown=1 > setting that David A. mentioned. Yes, ARP state for unreachable GWs may be updated slowly, there is in-time feedback only for reachable state. > With ignore_routes_with_linkdown=1 things behaved much better. > > > Not true. net/ipv4/fib_semantics.c:fib_select_path() calls > > fib_select_default() only when prefixlen = 0 (default route). > > Okay.... My testing last night disagrees with you. Specifically, I was able > to add a alternate routes to the same prefix, 192.0.2.128/26. There was not > any default gateway configured on any of the NetNSs. So everything was using > routes for locally attacked or the two added via "ip route append". > > What am I misinterpreting? Or where are we otherwise talking past each other? You can create the two routes, of course. But only the default routes are alternative. > > > Otherwise, only the first route will be considered. > > "only the first route" almost sounds like something akin to Equal Cost Multi > Path. > > I was not expecting "alternative routes" to use more than one route at a time, > equally or otherwise. I was wanting for the kernel to fall back to an > alternate route / gateway / path in the event that the one that was being used > became unusable / unreachable. > > So what should "Alternative Routes" do? How does this compare / contract to > E.C.M.P. or D.G.D. The alternative routes work in this way: - on lookup, routes are walked in order - as listed in table - as long as route contains reachable gateway (ARP state), only this route is used - if some gateway becomes unreachable (ARP state), next alternative routes are tried - if ARP entry is expired (missing), this gateway can be probed if the route is before the currently used route. This is what happens initially when no ARP state is present for the GWs. It is bad luck if the probed GW is actually unreachable. - active probing by user space (ping GWs) can only help to keep the ARP state present for the used gateways. By this way, if ARP entry for GW is missing, the kernel will not risk to select unavailable route with the goal to probe the GW. > > fib_select_default() is the function that decides which nexthop is reachable > > and whether to contact it. It uses the ARP state via fib_detect_death(). > > That is all code that is behind this feature called "alternative routes": > > the kernel selects one based on nexthop's ARP state. > > Please confirm that you aren't entering / referring to E.C.M.P. territory when > you say "nexthop". I think that you are not, but I want to ask and be sure, > particularly seeing as how things are very closely related. nexthop is the GW in the route > It sounds like you're referring to literally the router that is the next hop > in the path. I.e. the device on the other end of the wire. Yes, the kernel avoids alternative routes with unreachable GWs > I want to do some testing to see if fib_multipath_use_neigh alters this > behavior at all. I'm hoping that it will invalidate an alternate route if the > MAC is not resolvable even if the physical link stays up. The multipath route uses all its alive nexthops at the same time... But you may need in the same way active probing by user space, otherwise unavailable GW can be selected. > Sure, the ARP cache may have a 30 ~ 120 second timeout before triggering this > behavior. But having that timeout and starting to use an alternative route is > considerably better than not using an alternative route. Yes, if you prefer, you may run PING every second to avoid such delays... Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
