Date: Sun, 22 Oct 2017 04:03:47 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: loopback routes miss RTF_PINNED flag Message-ID: <59EBB633.2050201@grosbein.net> In-Reply-To: <201710212016.v9LKGPnh035752@pdx.rh.CN85.dnsmgr.net> References: <201710212016.v9LKGPnh035752@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
22.10.2017 3:16, Rodney W. Grimes wrote: > I think we are talking either about 2 different issues, Yes, we are. I'm trying to solve a problem described in detail here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223129 >> I said that in face of PPP interface kernel creates two routes, one loopback >> and another one to the tunnel interface itself. Both of them should be allowed >> to override possibly already existing dynamic routes and RTF_PINNED solves this problem. > > I think I see what your getting to, your bringing up an interface that > routes into a network that we have already learned about over some > routing protocol. Exactly. Plus, local address of the PPP interface also conflicts with dynamic route. > When the if comes up the maintain_loopback_route > clashes with that route and you get a complaint, adding RTF_PINNED > clears that issue up some how? Exactly. RTF_PINNED signals kernel to override dynamic route: kernel atomically deletes dynamic route and installs its own pinned route. Without RTF_PINNED flag, dynamic route persists, IP address configuration fails with EEXIST, so PPP daemon fails to setup the tunnel. >> And before RTF_PINNED introduction there were no solution, not to mention complex >> and not always possible dynamic route filtering. > > Um, I have been and still am routing with ppp and ethernet using > the FreeBSD kernel since pre 1.0 without using RTF_PINNED, so I > do not agree here. THere are solutions, infact it just works. It works in some configurations only. It does not work in others. For example, it is not possible to filter OSPF routes inside single OSPF area. One cannot filter out dynamic route and needs a way to override it. This is consistent with other router implementations like Cisco: one always can configure and have "connected" route with administrative distance 0 despite of presence of any other routes (except of another "connected" interface). >> But route daemon should not override pinned routes that are pinned for the reason. >> If pinned route is not needed, it should not have been created in first place, I agree. > > Ok, so why is it that these maintain_loopback_route routes are needed, > the world works and lives fine without them, other than a minor > in effecency in traffic to the local ip address of the interface. I would be totally fine with any other solution instead of loopback route that gives me standard features: 1. Routing daemon has "something" instead of loopback route to redistribute prefix created with another part of a system like PPP daemon or just "ifconfig" command. 2. Traffic to local IP address goes through loopback interface, that is: - it is seen with "tcpdump -i lo0" (bpf "sees" it within lo0) - it is matched with packet filter rule like "ipfw allow ip from any to any via lo0" And I'm not saying this should be same for everyone. I'm just saying new code should make it possible to use these features as they are very useful. If new code allows administrator to optionally break this, that's fine until it is an option and defaults do not break POLA. >> But if it WAS created, it should have absolute priority over dynamic routes >> or we get into same old trouble solved with RTF_PINNED that I described earlier. > > That is a policy decision, your policy is that you want these kernel > routes to take precedence over the dynamicly created ones, I want > the ones that my bird configuration says that I want and unless I > go ripe this code out of the kernel I can not get them cause the > kernel keeps changing them back. I see. You are just happy without loopback routes, you need not traffic to local addresses go through loopback interface, and you was never hit by a problem that gave birth to pinned routes. I struggled with that problem for years hoping that one day "ifconfig vlan100 X.X.X.X/24" would just work no matter if local routing daemon installed this prefix to the routing table already, or not. So, I'm just happy with pinned routes and want them more :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59EBB633.2050201>