From owner-freebsd-net@freebsd.org Thu Dec 14 14:47:18 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CBE0E82E14 for ; Thu, 14 Dec 2017 14:47:18 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E8A867053 for ; Thu, 14 Dec 2017 14:47:17 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBEElFQI097328; Thu, 14 Dec 2017 06:47:15 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBEElFhH097327; Thu, 14 Dec 2017 06:47:15 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712141447.vBEElFhH097327@pdx.rh.CN85.dnsmgr.net> Subject: Re: Changes to route(8) or routing between r325235 and r326782? In-Reply-To: <5A32208D.3070500@grosbein.net> To: Eugene Grosbein Date: Thu, 14 Dec 2017 06:47:15 -0800 (PST) CC: sthaug@nethelp.no, freebsd-net@freebsd.org, crest@rlwinm.de X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 14:47:18 -0000 > On 13.12.2017 03:21, Rodney W. Grimes wrote: > > > Flap your intgerfaces and see what happens when quagga and the kernel fight > > over who gets to install the local MTU route via lo of the ip address for > > the interface you flapped. > > I do not see any problem here. After service quagga restart: > > # egrep 'zebra|ospfd' /var/log/messages > Dec 14 13:48:43 ptic zebra[96288]: Zebra 1.2.1 starting: vty@2601 > ... > Dec 14 13:48:46 ptic ospfd[96297]: AdjChg: Nbr 192.168.7.1 on gif0:192.168.100.234: Loading -> Full (LoadingDone) > Dec 14 13:48:46 ptic ospfd[96297]: AdjChg: Nbr 192.168.7.1 on gif1:192.168.100.134: Loading -> Full (LoadingDone) > > # ifconfig gif1 down Ping the IP address of gif1 here, why can you still ping the if address of an administratively down interface? That is just fundementally wrong in so many ways. > # ifconfig gif1 up > > This adds to /var/log/messages: > > Dec 14 13:49:01 ptic ospfd[96297]: AdjChg: Nbr 192.168.7.1 on gif1:192.168.100.134: Full -> Deleted (KillNbr) > Dec 14 13:49:01 ptic zebra[96288]: if_ioctl(SIOCGIFMEDIA) failed: Invalid argument > Dec 14 13:49:01 ptic zebra[96288]: kernel_rtm_ipv4: 192.168.100.132/30: rtm_write() unexpectedly returned -4 for command RTM_DELETE > Dec 14 13:49:04 ptic zebra[96288]: if_ioctl(SIOCGIFMEDIA) failed: Invalid argument > Dec 14 13:49:04 ptic ospfd[96297]: OSPF MPLS-TE: Abort update TE parameters: no Link Parameters for interface > Dec 14 13:49:06 ptic ospfd[96297]: AdjChg: Nbr 192.168.7.1 on gif1:192.168.100.134: Exchange -> Full (ExchangeDone) > > There is no fight. Why don't you describe *your* setup in a PR so we could handle it right way? > Perhaps, we could add another sysctl to disable route pinning if it really unavoidable for such setups. I suspect your no longer seeing the bad messages cause your route is now -pinned and does nolonger alterable by anyone other than someone specifically using a -pinned arg to the calls. You have now hardwired a permanent route to the local IP address of any interface weither that interface is up or not. And done so in a way that is not easy to work around without altering kernel source code. Rather than file a PR I well write a differential that simply wraps a knob around all this *maintain_looopback_route() non-sense so that kernels can be bulit without it, and inside that knob add a sysctl to turn the behavior on and off so that those caught, like the reporting person on the mail list that got hammered by your MFC, can quickly recover with a loader.conf variable. Proposed option and sysctl names for bikeshed of colour blue: options MAINTAIN_LOOPBACK_ROUTE #Maintain a pinned and always present #(even when interface is down) route #to the local IP of all interfaces sysctl net.route.maintain_loopback_route=1 The above well be the defaults, IE, in GENERIC and sysctl set to 1, that well maintain YOUR bad behavior, but allow me and others to easily correct for it. OK? -- Rod Grimes rgrimes@freebsd.org