On Mon, Oct 19, 2020 at 10:03:29AM +0100, Stuart Henderson wrote: > On 2020/10/19 11:47, David Gwynne wrote: > > On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote: > > > On 2020/10/18 14:04, David Gwynne wrote: > > > > the problem i'm hitting is that i have a multihomed box where the > > > > service it provides listens on an IP address that's assigned to lo1. > > > > it's a host running a service, it's not a router, so the > > > > net.inet.ip.forwarding sysctl is not set to 1. > > > > > > I ran into this, I just turned on the forwarding sysctl to avoid the > > > problem. > > > > > > > i came up with this diff, which adds even more special casing for > > > > loopback interfaces. it says addreesses on loopbacks are globally > > > > reachable, even if ip forwarding is disabled. > > > > > > I don't see why loopbacks should be special. Another place this > > > might show up is services running on carp addresses (I haven't updated > > > those machines yet but there's a fair chance they'll be affected too). > > > I would prefer an explicit sysctl to disable "strong host model". > > > > loopback is already special. if a packet comes from an loopback > > interface, we allow it to talk to any IP on the local machine. i think > > this is mostly to cope with the semantic we've had where local traffic > > get's tied to a loopback interface instead of going anywhere near the > > physical ones. > > > > carp is also special. > > > > let me paste the ip_laddr function instead of the diff to it, it's a bit > > more obvious what's going on: > > Thanks, that will already work for the machines I was thinking of then. > > > back to loopback and receiving packets. loopback is special because it > > is not connected to the outside world. it is impossible to send a packet > > via a loopback interface from another host, so configuring a globally > > (externally) routable IP on it is currently pointless unless you enable > > forwarding. i think making loopback more special and allowing it > > to be globally reachable makes sense. i can't think of any downsides to > > this at the moment, except that the behaviour would be subtle/not > > obvious > > ok, so it makes sense for this to be independent of any possible > separate lever. > > > is there a need to configure a globally reachable IP on a non-loopback > > interface on a host (not router)? if so, then i'd be more convinced that > > we need a separate lever to pull. > > I'm not using it this way, but here's a scenario. > > Say there are a couple of webservers with addresses from a carp on > ethernet/vlan, with a link to their upstream router on some separate > interface. They announce the carp prefix into ospf.
so carp is just being used to elect a webserver as a master, and then the result of that election is fed upstream. > They aren't routing themselves so the only reason to have forwarding=1 > is to have them use "weak host model". > > With forwarding=0 I think they'll have to use "stub router no" otherwise > everything will be announced high metric (rather than being dependent on > carp state), but ospfd explicitly handles this; it's marked in parse.y > with "/* allow to force non stub mode */". so is a Big Global Lever what you want here? if you enable weak host mode, all IPs on the host will be addressible from all legs of the host. would it make more sense to configure specific interfaces as holding globally addressible IPs? if my understanding of your scenario is right, you could configure the carp interface with the weak or globally accessible flag. in my situation i could configure that on lo1. dlg
