[12:06] <ThomasConnect> Good afternoon, I've got a query regarding some netplan behaviour. I'm running ubuntu 20.04 containers on lxc, with the standard cloud init netplan configuration, and I've noticed every time I do a netplan apply (not changing the config at all), my container gets assigned a new IP on the eth0 interface. Is this intended behaviour? and is it
[12:06] <ThomasConnect> possible to avoid this happening?
[13:29] <slyon> ThomasConnect: hmm I think this is the expected behavior (kind of). As the standard cloud-init netplan config probably defines a DHCP connection. And on 'netplan apply' the backend (systemd-networkd) is re-started, requesting a DHCP connection from the server.
[13:30] <slyon> Usually the DHCP should give the same IP address if a client with same MAC/existing lease is re-requesting a connection. So maybe this is a misconfiguration of the DHCP server?
[13:44] <ThomasConnect> I will look into the DHCP configuration we have, and see if there is something fishy. Thank you
[13:56] <ThomasConnect> We have 2 dhcpd servers, a primary and a secondary, and it seems that the ip difference comes in between the primary and secondary. Makes sense because the container only ever gets 2 different ips, no matter how many times you do netplan apply
[13:59] <slyon> Yes, that should explain the behaviour.
[14:12] <BeRoots> Hello. I tried to make a netplan on eth0 to configure this interface to use a private ipv4 network between two computers using an rj45 crossover link (p2p without router ; hub ; switch ; ...). I tried a lot of things but my connection doesn't work yet. I have replace the content of /etc/netplan/50-cloudinit.yaml by this:
[14:12] <BeRoots> https://pastebin.com/cTpGN2dU If someone have an idea about what's wrong here and why `ip a` not show any ipv4 for the eth0 interface?
[14:13] <kjetilho> /30 is very tight, but it should work I think.
[14:14] <BeRoots> It is for a 2 machine network using a direct link (crossover).
[14:15] <kjetilho> yes, so the other machine is .2, and .3 will be broadcast
[14:15] <BeRoots> Yes
[14:15] <kjetilho> should work
[14:16] <lukasm> looks good to me as well. It should show up in 'ip a' after you executed 'netplan apply'
[14:17] <BeRoots> With only this yaml or with all uncommented lines ?
[14:18] <lukasm> leave out the comments. Just defining "addresses: " should be OK
[14:20] <BeRoots> Ok. I tried with or without command then I do a `netplan generate && netplan -d apply && reboot` and I don't have any ip =L
[14:21] <BeRoots> I'm on an Ubuntu server (raspberry pi 4 release)
[14:21] <lukasm> can you paste the output of 'ip a' and the output of 'netplan --debug apply'?
[14:22] <BeRoots> Ok...
[14:34] <BeRoots> Ok It's work. I have to plug the rj45 into the two computers. not only on the ubuntu. '=D
[14:34] <BeRoots> Thanks for help (y)
[14:34] <kjetilho> :-D
[23:30] <loco41211> I have one interface with multiple public IPs. (ethernet interface in netplan yaml). What I want is to force a specific process via a specific source IP (shell script / curl / compiled code / whatever). Is the right approach here using ehternets -> xx -> addresses -> ip -> label ?
[23:34] <kjetilho> in general the process should be configured to bind a specific address
[23:35] <loco41211> on the process level?
[23:35] <loco41211> I should specify I mean outgoing traffic, not incoming
[23:35] <loco41211> e.g HTTP requests
[23:36] <kjetilho> yes
[23:36] <loco41211> I saw with physical network interfaces I can force a process via a specific namespace, via `ip netns` - any ideas if that wroks with virtual interfaces/labels config'd via netplan?
[23:39] <kjetilho> I would use the vrf concept, but netplan doesn't support it, unfortunately.
[23:40] <loco41211> I don't mind other tools, nor creating other users if it's easier that way. Overall I just have multiple IPs on one eth interface, and I want to force specific processes to send their outgoing traffic via specific origin IPs... still researching, but if you have ideas or pointers (anyone else too), they're very appreciated
[23:41] <kjetilho> like I said, it's best to configure the daemon to use it