=== gjolly_ is now known as gjolly
=== jrm2 is now known as jrm
=== kenyon_ is now known as kenyon
=== yawkat` is now known as yawkat
[12:49] <caribou> Hello, I have a netplan renderer question for you : In  our Datasource, when trying to add a static IPv4 network with the following network_config :
[12:49] <caribou> {'version': 1, 
[12:49] <caribou> 'config': [
[12:49] <caribou> {'type': 'physical',
[12:49] <caribou> 'name': 'ens2', 
[12:49] <caribou> 'subnets': [
[12:49] <caribou> {'type': 'static', 
[12:49] <caribou> 'address': '195.154.xx.yyy', 
[12:49] <caribou> 'mac_address': 'xx:00:00:00:00:xx', 
[12:49] <caribou> 'routes': [
[12:49] <caribou> {'network': '0.0.0.0', 
[12:49] <caribou> 'prefix': 0, 
[12:49] <caribou> 'gateway': '62.210.0.1'}]}]}]}
[12:49] <caribou> The netplan rendered file will not add the default route unless I manually add on-link: true to validate the fact that the gateway's subnet is not in the same subnet as the NIC
[12:50] <caribou> I don't see any way to add the on-link: true in the network_config structure so I suppose that there is another proper way of doing this in order to get the proper routing
[12:53] <caribou> The generated netplan file is here : http://pastebin.fr/112811
[13:35] <caribou> weeelll, I don't now if will be your suggestion, but since switching to version 2 means that there is a one-to-one matching between the network_config structure and netplan, I can easily build the proper structure with on-link: True and it seems to work as I expect
[14:51] <falcojr> caribou: I don't think cloud-init networking config has a way of accomplishing that other than the netplan passthrough as you mentioned. That's something we should probably add
[15:44] <caribou> falcojr: well, using V2 seems to do the job, I just had to dig into the source to figure it out. Thanks for confirming that
[16:14] <holmanb> caribou: This setup is unusual. What would be the use case for this?
[16:20] <minimal> I'd think it is more than just usual, how would the default route ever be usable as there is no machine interface on the same subnet as the gateway
[16:20] <minimal> s/usual/unusual/
[16:21] <holmanb> minimal: +1 to "more than unusual"
[16:22] <holmanb> I see examples of this being supported at https://netplan.io/examples
[16:23] <minimal> you need a router on your local network so that you can send it packets for machines not on the same network. But if the router itself is not on the same network then you'd need another router on the same network as you to send the packets to for it to forward them to the 1st router ;-)
[16:26] <minimal> hmm, from "ip route" manpage: "pretend that the nexthop is directly attached to this link, even if it does not match any interface prefix."
[16:28] <minimal> confused how this works at all as it goes against fundamental routing principles
[16:32] <holmanb> if arp returns a mac for that IP I assume this would work, despite how wrong it seems
[16:33] <minimal> unless it's supposed to act like "unnumbered links" which are sometimes used for PtP serial/leased-line connections (rather than broadcast networks like ethernet) where each router sees IP address(es) of the other non-PtP interfaces of the other router as being directly accessible
[16:35] <minimal> bjut that works with PtP networks as there is no broadcast "domain" in PtP links, unlike broadcast media such as ethernet, so packets sent can only possibly go to the machine/router at the other end
[16:38] <caribou> holmanb: tbh, I'm not behind the network setup of all this. maybe I can fetch more details
[16:41] <caribou> that might also be an unusual configuration of our lab setup which may not reflect our "real world" network configuration. I'll check on that too
[16:44] <holmanb> caribou: I think minimal and I are confused because however this "works" it violates a lot of typical network addressing expectations.
[16:45] <holmanb> caribou: which would likely make it a pretty low priority for cloud-init support
[16:45] <holmanb> caribou: If this is only for a lab where you need two devices to talk to each other, then adding support for an obscure networking feature to cloud-init seems like the "hard way" to accomplish whatever you're trying to do.
[16:46] <holmanb> caribou: more details would help a lot - real world details especially so
[16:46] <holmanb> Thanks :)
[16:48] <caribou> holmanb: yep; I'll get more details from my network engineers counterpart & let you know as soon as I know more
[16:49] <holmanb> caribou: Thanks!
[20:20] <meena> caribou, holmanb, minimal: I'm pretty, and sure, Hetzner has, or used to have a peet-to-peer setup your their IPv4 network 
[20:20] <meena> peer-to-peer, even
[20:24] <minimal> meena: over a broadcast (ethernet) media?
[20:27] <meena> https://gist.github.com/642efb4e0f4da255382bc299ec65ce83
[20:28] <meena> sometimes i forget what an unholy mess Hetzner's network is
[20:29] <meena> and this is waaaaaaay improved from what it used to be
[21:30] <holmanb> meena: Why configure the interface to be in a different subnet than the gateway?
[21:36] <minimal> holmanb: I guess to save on public IPv4 address space, the vtnet0 IP is "global" but the gateway is private address space
[21:37] <minimal> if they didn't use this "trick" then they'd have to waste some public/global address space for gateway within their hosting environment
[21:42] <minimal> plus they're handling out/creating a /32 so what IP could a "local" gateway be on? lol
[21:43] <minimal> the joys of VPS-type hosting providers wacky setups....
[21:46] <minimal> was helping someone last night who's using cloud-init with OVH's Bare Metal service - it's Openstack-based and so ConfigDrive data source. He had a *large* number of IPv6 routes, turns out the network info passed via ConfigDrive has this in it so something must have gone wrong at OVH side - it defined IPv6 routes for a /32, a /33, a /34, a /35, etc all the way to a /128 ;-)
[21:47] <minimal> so the resultant e/n/i file (for the Debian deriivative he used) had all these interface "pre-up" entries per route
[21:48] <holmanb> > plus they're handling out/creating a /32 so what IP could a "local" gateway be on? lol
[21:48] <holmanb> I see the config meena shared has a /32, but I haven't even found anywhere in Hetzner's docs where static addressing recommends that.
[21:48] <holmanb> most of their examples use hdpc
[21:48] <holmanb> dhcp
[21:49] <holmanb> ahhh, found it
[21:49] <holmanb> https://docs.hetzner.com/cloud/servers/static-configuration
[21:49] <minimal> I definately heard of some VPS type providers using /32
[21:51] <minimal> holmanb: ah I see in that page their e/n/i example has "pointopoint 172.31.1.1" which goes back to my original comment about unnumbered PtP links
[21:51] <minimal> that I think turns the interface effectively into no longer a broadcast media
[21:51] <holmanb> ^^ that docs page also says to disable cloud-init, lol
[21:51] <minimal> well it says to disable c-i network *changes*
[21:51] <holmanb> *cloud-init networking
[21:51] <holmanb> yeah, mistyped that
[21:52] <minimal> so it might do the original network config ok
[21:53] <minimal> same with that guy last night and OVH Bare Metal, he was overriding the ConfigDrive network info as he was setting up a bridge to layer the ethernet on
[21:54] <meena> this is funny to me, because we just merged a change to apply network changes to on every boot
[21:57] <meena> anyway, we need a better way to set pointopoint routes in FreeBSD 
[22:02]  * holmanb updates priors about cloud network design