From owner-freebsd-net@freebsd.org Tue Dec 12 20:21:05 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 0DFF7E8354C for ; Tue, 12 Dec 2017 20:21:05 +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 C24C870BA3 for ; Tue, 12 Dec 2017 20:21:04 +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 vBCKL3QX088221; Tue, 12 Dec 2017 12:21:03 -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 vBCKL219088220; Tue, 12 Dec 2017 12:21:02 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712122021.vBCKL219088220@pdx.rh.CN85.dnsmgr.net> Subject: Re: Changes to route(8) or routing between r325235 and r326782? In-Reply-To: <5A303639.3090109@grosbein.net> To: Eugene Grosbein Date: Tue, 12 Dec 2017 12:21:02 -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: Tue, 12 Dec 2017 20:21:05 -0000 > On 13.12.2017 02:30, sthaug@nethelp.no wrote: > > > 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. > > > > If I want something more complicated (typically BGP) I'll install > > quagga. > > You can still install quagga with simple "pkg install" command > and run "zebra" daemon only to get exactly what you want, and no routing protocols: > > quagga_enable="YES" > quagga_daemons="zebra" > > Then change all your "kernel routes" ("route add") to "static routes" in terms of quagga > storing them in the /usr/local/etc/quagga/zebra.conf like I do: > > ip route 192.168.0.0/16 reject > ip route 192.168.2.0/24 10.0.0.2 > > And so on. This works just as you need. 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 must stress this is not about static routing, this is about the MTU route that typically is done in /etc/rc.d/ at boot time. This is a route to the local IP address of an interface to route its packets via lo0 so that we pickup the larger MTU. The code I am talking of here is *_maintain_loopback_route() in the kernel, that code just needs to die, it creates more problems that in solves. It has been dead in all my kernels since I found it in my syslogs fighting with bird. You should be able to run totally without these routes, they are there only to optimize local MTU. This has nothing to do with ppp, or the above routes, those are NOT lo0 or loopback routes. I am going to repeat that. You can run without these routes at all, totally not needed for a functional system. It might be non optimal as your connections to a local IP address are going to use the interface MTU rather than the MTU of lo0. Usually 1500 vs 16k. But then things should not really be using this route anyway, it would always be better to open 127.0.0.1 rather than an interface ip. The other thing these routes break is what the user complained of that started this whole thread, his pf or firewall no longer behaves as it did, because now we are forcing packets via lo0 that he was expecting to go via an interface. AND we have left this user no way to turn that function off reliably as he can delete the pinned route, but if his interface flaps it is gona come right back! -- Rod Grimes rgrimes@freebsd.org