Date: Tue, 12 Dec 2017 12:00:49 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: sthaug@nethelp.no Cc: eugen@grosbein.net, freebsd-net@freebsd.org, crest@rlwinm.de Subject: Re: Changes to route(8) or routing between r325235 and r326782? Message-ID: <201712122000.vBCK0nAE088143@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <20171212.203058.74686940.sthaug@nethelp.no>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > >>> The whole maintain_loopback_route should be KILLED from the kernel, > > > >>> it is simply the wrong thing to be doing. > > > >> > > > >> Only if you can supply alternative way to assign highest priority > > > >> (administrative distance = 0) for "directly connected" routes. > > > >> And ability to override dynamically received prefixes with direct > > > >> interface address assignment. > > > > > > > > This is all done by correctly configured routing daemon > > > > running in userland over the route socket. > > > > > > Do we have such daemon maintaining directly connected routed in the base system? > > > > I believe we do, though it uses a fairly rare protocol now a days, > > called ripv2. man routed Both bird and quagga maintain these > > routes as well. I believe that openospfd does too. In fact > > I dont know of a routing daemon that does not try to maintain > > these. > > > > Also why does this need to ba a "in the base system"? Certainly > > sticking a route decision in the kernel that defeats any attempt > > to change it makes that pointless anyway. > > Being a router jockey at my daytime job I can symphatize with both > views here. > > - I *expect* that a route pointing out an interface will disappear > when that interface goes down, and reappear again when the interface > comes back up. This behavior is extremely consistent across all the > major router brands. On a hardware router this is always handled by a configured protocol, try turning off all configured protocols and see what happens. > - The standard FreeBSD behavior where a static route (added by a > manual "route add -net ...") does *not* reappear when an interface > comes back up, simply feels incredibly wrong and inconsistent. Again, your use to that behavior because on the hardware router you always have a routing protocol running. Try a router fresh out of the box with no protocols and see if it instantiats a loop back route, hech, I am not even sure if lo0 exists on some routers unless you create it! > But I also want the kernel to handle packet *forwarding*, and not > routing policy. I guess I'm looking for a a simplified routed which > will handle my static routes and can be turned on with a only an > xxx_enable in rc.conf and then basically forgotten. routed -q Need to test that, but if the code hasnt been broken that should just do the right thing about routes via local interfaces having the local IP added as a lo0 loopback route. I also think that if you use /etc/rc.d/netif and have your variables properly set in /etc/rc.conf that your routes well come and go as you down and up with /etc/rc.d/netif. > If I want something more complicated (typically BGP) I'll install > quagga. One of the problems now is that these programs are fighting with the kernel over these routes and just fill your logs with lots of useless messages and you can not reliably predict the loop back routes even if you ARE running a routing protocol daemon. I also find it hillarious that the code emits a bogous console message when I down an interface that it could not delete the loopback route, that is because it went away when the if went down and it is nonsense to call maintain_loopback_route with a delete flag in this instance. This clearly informs one that the code was not well thought out. Probably written by someone that does not understand what is happening in the kernel automatically when an interface goes down. > Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201712122000.vBCK0nAE088143>