[lxc-users] How to get rid of pesky extra dhcp IP

[jjs - mainphrame]

Greetings,

Running lxd-3.0.0 on ubuntu 18.04 beta

I've set up a couple of new 16.04 cts and they act as I expect.

I set up an 18.04 ct and a persistent unwanted dhcp IP appears in the lxc
list:

***@ronnie:~# lxc list
+-----------+---------+------------------------+------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE |
SNAPSHOTS |
+-----------+---------+------------------------+------+------------+-----------+
| dbserv111 | RUNNING | 192.168.111.221 (eth0) | | PERSISTENT | 0
|
+-----------+---------+------------------------+------+------------+-----------+
| kangal | RUNNING | 192.168.111.44 (eth0) | | PERSISTENT | 0
|
| | | 192.168.111.239 (eth0) | | |
|
+-----------+---------+------------------------+------+------------+-----------+
| mg111 | RUNNING | 192.168.111.222 (eth0) | | PERSISTENT | 0
|
+-----------+---------+------------------------+------+------------+-----------+

However, inside the 18.04 container (kangal), only the static IP is listed:
***@kangal:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.111.44 netmask 255.255.255.0 broadcast
192.168.111.255
inet6 fe80::216:3eff:fef3:857e prefixlen 64 scopeid 0x20<link>
ether 00:16:3e:f3:85:7e txqueuelen 1000 (Ethernet)
RX packets 80658 bytes 97973222 (97.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 56964 bytes 5320056 (5.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1400 bytes 115581 (115.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1400 bytes 115581 (115.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

***@kangal:~#

However I can ssh to this dhcp IP and gain access to the box.

Any clues as to how to get rid of this unwanted extra IP?

Jake

[Simos Xenitellis]

These 192.168.111.x IP addresses are not LXD default private IP addresses.
Have you configured a bridge or a macvlan?

Simos

Post by jjs - mainphrame
Greetings,
Running lxd-3.0.0 on ubuntu 18.04 beta
I've set up a couple of new 16.04 cts and they act as I expect.
I set up an 18.04 ct and a persistent unwanted dhcp IP appears in the lxc
+-----------+---------+------------------------+------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE |
SNAPSHOTS |
+-----------+---------+------------------------+------+------------+-----------+
| dbserv111 | RUNNING | 192.168.111.221 (eth0) | | PERSISTENT | 0
|
+-----------+---------+------------------------+------+------------+-----------+
| kangal | RUNNING | 192.168.111.44 (eth0) | | PERSISTENT | 0
|
| | | 192.168.111.239 (eth0) | | |
|
+-----------+---------+------------------------+------+------------+-----------+
| mg111 | RUNNING | 192.168.111.222 (eth0) | | PERSISTENT | 0
|
+-----------+---------+------------------------+------+------------+-----------+
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.111.44 netmask 255.255.255.0 broadcast
192.168.111.255
inet6 fe80::216:3eff:fef3:857e prefixlen 64 scopeid 0x20<link>
ether 00:16:3e:f3:85:7e txqueuelen 1000 (Ethernet)
RX packets 80658 bytes 97973222 (97.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 56964 bytes 5320056 (5.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1400 bytes 115581 (115.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1400 bytes 115581 (115.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
However I can ssh to this dhcp IP and gain access to the box.
Any clues as to how to get rid of this unwanted extra IP?
Jake
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

[jjs - mainphrame]

Thanks Simos,

The host has a bridge, br0, but not an lxc-specific one
(USE_LXC_BRIDGE="false" in /etc/default/lxc-net)

The 192.168.111 range is from the pool on the local dhcp box. However, this
container is configured to use a static IP in /etc/network/interfaces:
--
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
# source-directory /etc/network/interfaces.d

auto eth0
iface eth0 inet static
address 192.168.111.44
netmask 255.255.255.0
gateway 192.168.111.1
dns-nameservers 192.168.111.1
dns-search mainphrame.net
--

I'm not seeing where a dhcp address is being requested for this container.
Is there some systemd magic going on behind the scenes?

Jake



On Mon, Apr 9, 2018 at 11:36 PM, Simos Xenitellis <

Post by Simos Xenitellis
These 192.168.111.x IP addresses are not LXD default private IP addresses.
Have you configured a bridge or a macvlan?
Simos

Post by jjs - mainphrame
Greetings,
Running lxd-3.0.0 on ubuntu 18.04 beta
I've set up a couple of new 16.04 cts and they act as I expect.
I set up an 18.04 ct and a persistent unwanted dhcp IP appears in the lxc
+-----------+---------+------------------------+------+-----

-------+-----------+

Post by jjs - mainphrame
| NAME | STATE | IPV4 | IPV6 | TYPE |
SNAPSHOTS |
+-----------+---------+------------------------+------+-----

-------+-----------+

Post by jjs - mainphrame
| dbserv111 | RUNNING | 192.168.111.221 (eth0) | | PERSISTENT | 0
|
+-----------+---------+------------------------+------+-----

-------+-----------+

Post by jjs - mainphrame
| kangal | RUNNING | 192.168.111.44 (eth0) | | PERSISTENT | 0
|
| | | 192.168.111.239 (eth0) | | |
|
+-----------+---------+------------------------+------+-----

-------+-----------+

Post by jjs - mainphrame
| mg111 | RUNNING | 192.168.111.222 (eth0) | | PERSISTENT | 0
|
+-----------+---------+------------------------+------+-----

-------+-----------+

Post by jjs - mainphrame
However, inside the 18.04 container (kangal), only the static IP is
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.111.44 netmask 255.255.255.0 broadcast
192.168.111.255
inet6 fe80::216:3eff:fef3:857e prefixlen 64 scopeid 0x20<link>
ether 00:16:3e:f3:85:7e txqueuelen 1000 (Ethernet)
RX packets 80658 bytes 97973222 (97.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 56964 bytes 5320056 (5.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1400 bytes 115581 (115.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1400 bytes 115581 (115.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
However I can ssh to this dhcp IP and gain access to the box.
Any clues as to how to get rid of this unwanted extra IP?
Jake
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

[jjs - mainphrame]

Bump -

The bug is 100% repeatable. Steps to reproduce:

1. create ubuntu container (lxc launch)
2. enter container and configure a static IP in /etc/network/interfaces
3. If container is 16.04, only static IP exists. if container is 18.04.
there are both static and dhcp ips.

+-----------------+---------+------------------------+------+------------+-----------+
| national-dragon | RUNNING | 192.168.111.26 (eth0) | | PERSISTENT |
0 |
+-----------------+---------+------------------------+------+------------+-----------+
| open-moth | RUNNING | 192.168.111.25 (eth0) | | PERSISTENT |
0 |
| | | 192.168.111.241 (eth0) | | |
|
+-----------------+---------+------------------------+------+------------+-----------+

Jake

Post by jjs - mainphrame
Greetings,
Running lxd-3.0.0 on ubuntu 18.04 beta
I've set up a couple of new 16.04 cts and they act as I expect.
I set up an 18.04 ct and a persistent unwanted dhcp IP appears in the lxc
+-----------+---------+------------------------+------+-----
-------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE |
SNAPSHOTS |
+-----------+---------+------------------------+------+-----
-------+-----------+
| dbserv111 | RUNNING | 192.168.111.221 (eth0) | | PERSISTENT | 0
|
+-----------+---------+------------------------+------+-----
-------+-----------+
| kangal | RUNNING | 192.168.111.44 (eth0) | | PERSISTENT | 0
|
| | | 192.168.111.239 (eth0) | | |
|
+-----------+---------+------------------------+------+-----
-------+-----------+
| mg111 | RUNNING | 192.168.111.222 (eth0) | | PERSISTENT | 0
|
+-----------+---------+------------------------+------+-----
-------+-----------+
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.111.44 netmask 255.255.255.0 broadcast
192.168.111.255
inet6 fe80::216:3eff:fef3:857e prefixlen 64 scopeid 0x20<link>
ether 00:16:3e:f3:85:7e txqueuelen 1000 (Ethernet)
RX packets 80658 bytes 97973222 (97.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 56964 bytes 5320056 (5.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1400 bytes 115581 (115.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1400 bytes 115581 (115.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
However I can ssh to this dhcp IP and gain access to the box.
Any clues as to how to get rid of this unwanted extra IP?
Jake

[Sergiusz Pawlowicz]

it's not a bug, it is a feature

man netplan

[jjs - mainphrame]

Thanks for the clue. Looking into this.

Jake

On Sat, Apr 14, 2018 at 10:31 AM, Sergiusz Pawlowicz <

Post by Sergiusz Pawlowicz
it's not a bug, it is a feature
man netplan
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

[jjs - mainphrame]

Confirmed, removing netplan solves the problem.

Thanks for the hint.

Jake

Post by jjs - mainphrame
Thanks for the clue. Looking into this.
Jake
On Sat, Apr 14, 2018 at 10:31 AM, Sergiusz Pawlowicz <

Post by Sergiusz Pawlowicz
it's not a bug, it is a feature
man netplan
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

[David Favor]

Post by jjs - mainphrame
Confirmed, removing netplan solves the problem.
Thanks for the hint.
Jake
Thanks for the clue. Looking into this.
Jake
On Sat, Apr 14, 2018 at 10:31 AM, Sergiusz Pawlowicz
it's not a bug, it is a feature
man netplan

Netplan doesn't get rid of the "pesky DHCP IP".

Currently there's a bug in ifconfig, which fails to report the DHCP IP.

The only way (till the ifconfig bug is fixed) you can view all IPs via...

ip addresses (container level)

lxc list (machine level)

Likely good for you to read many posts about the purpose of the DHCP IP
inside containers.

If you do destroy this IP (in netplan - rm -f /etc/netplan/50*), then
you'll produces subtle packet routing breakage when trying to communicate
between containers (yes even if they have public IPs).

[jjs - mainphrame]

Thanks for the insights. The netplan and cloud packages look like something
which might be indeed useful in uses cases other than mine.
In retrospect I'm curious how 16.04 is working so well without netplan.
Apparently further study is needed...

Jake

Post by David Favor

Post by jjs - mainphrame
Confirmed, removing netplan solves the problem.
Thanks for the hint.
Jake
Thanks for the clue. Looking into this.
Jake
On Sat, Apr 14, 2018 at 10:31 AM, Sergiusz Pawlowicz
it's not a bug, it is a feature
man netplan

Netplan doesn't get rid of the "pesky DHCP IP".
Currently there's a bug in ifconfig, which fails to report the DHCP IP.
The only way (till the ifconfig bug is fixed) you can view all IPs via...
ip addresses (container level)
lxc list (machine level)
Likely good for you to read many posts about the purpose of the DHCP IP
inside containers.
If you do destroy this IP (in netplan - rm -f /etc/netplan/50*), then
you'll produces subtle packet routing breakage when trying to communicate
between containers (yes even if they have public IPs).
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

[David Favor]

Post by jjs - mainphrame
Thanks for the insights. The netplan and cloud packages look like
something which might be indeed useful in uses cases other than mine.
In retrospect I'm curious how 16.04 is working so well without netplan.
Apparently further study is needed...

Netplan support begins with Artful (where Netplan + old style EIN coexist).

Netplan is default in Bionic... well sort of default Artful too.

My suggestion is when Bionic releases in a few days, start with a fresh system.

1) Install Bionic from scratch at machine level. No update, true install.

2) Install LXD via snap. No migration, true install.

3) Do an lxd copy remote:cname local:cname for each container, to move them
from where ever they live to your Bionic machine.

The /etc/netplan/60-public-init.yaml file format I've been using, which works...

network:
version: 2
ethernets:
eth0:
match:
name: eth0
addresses:
- X.X.X.X/32

The Netplan docs are... to me... are overly complex + difficult to understand.

For example, the eth0: above requires the match: operator (I guess) to differentiate
between base interface name + aliases.

Just start with the above Netplan config file + get your system working, then start
making whatever experimental changes seem useful.

Netplan is very unforgiving + in many cases syntax errors emit no errors/warnings,
so you have to do eyeball syntax checking.

Post by jjs - mainphrame
Jake
Confirmed, removing netplan solves the problem.
Thanks for the hint.
Jake
On Sat, Apr 14, 2018 at 10:39 AM, jjs - mainphrame
Thanks for the clue. Looking into this.
Jake
On Sat, Apr 14, 2018 at 10:31 AM, Sergiusz Pawlowicz
it's not a bug, it is a feature
man netplan
Netplan doesn't get rid of the "pesky DHCP IP".
Currently there's a bug in ifconfig, which fails to report the DHCP IP.
The only way (till the ifconfig bug is fixed) you can view all IPs via...
ip addresses (container level)
lxc list (machine level)
Likely good for you to read many posts about the purpose of the DHCP IP
inside containers.
If you do destroy this IP (in netplan - rm -f /etc/netplan/50*), then
you'll produces subtle packet routing breakage when trying to communicate
between containers (yes even if they have public IPs).
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
<http://lists.linuxcontainers.org/listinfo/lxc-users>
------------------------------------------------------------------------
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

[jjs - mainphrame]

Thanks for the additional info and pointers.

BTW I'd noticed that the ip command showed the extraneous IP missed by
ifconfig. But not showing the extra IP was not the problem, rather that the
extra IP existed at all. In any event, the removal of netplan and cloud
packages facilitate the intended modes of operation in my environment
(system type containers using bridged networking and static IPs)

But I do prefer to see the whole system work as intended, so thanks for the
netplan details.

BTW - re your recommendation to install LXD via snap - is the preferred
install method moving forward?

Jake

Post by David Favor

Post by jjs - mainphrame
Thanks for the insights. The netplan and cloud packages look like
something which might be indeed useful in uses cases other than mine.
In retrospect I'm curious how 16.04 is working so well without netplan.
Apparently further study is needed...

Netplan support begins with Artful (where Netplan + old style EIN coexist).
Netplan is default in Bionic... well sort of default Artful too.
My suggestion is when Bionic releases in a few days, start with a fresh system.
1) Install Bionic from scratch at machine level. No update, true install.
2) Install LXD via snap. No migration, true install.
3) Do an lxd copy remote:cname local:cname for each container, to move them
from where ever they live to your Bionic machine.
The /etc/netplan/60-public-init.yaml file format I've been using, which works...
version: 2
name: eth0
- X.X.X.X/32
The Netplan docs are... to me... are overly complex + difficult to understand.
For example, the eth0: above requires the match: operator (I guess) to differentiate
between base interface name + aliases.
Just start with the above Netplan config file + get your system working, then start
making whatever experimental changes seem useful.
Netplan is very unforgiving + in many cases syntax errors emit no errors/warnings,
so you have to do eyeball syntax checking.
Jake

Post by jjs - mainphrame
Confirmed, removing netplan solves the problem.
Thanks for the hint.
Jake
On Sat, Apr 14, 2018 at 10:39 AM, jjs - mainphrame
Thanks for the clue. Looking into this.
Jake
On Sat, Apr 14, 2018 at 10:31 AM, Sergiusz Pawlowicz
it's not a bug, it is a feature
man netplan
Netplan doesn't get rid of the "pesky DHCP IP".
Currently there's a bug in ifconfig, which fails to report the DHCP IP.
The only way (till the ifconfig bug is fixed) you can view all IPs via...
ip addresses (container level)
lxc list (machine level)
Likely good for you to read many posts about the purpose of the DHCP IP
inside containers.
If you do destroy this IP (in netplan - rm -f /etc/netplan/50*), then
you'll produces subtle packet routing breakage when trying to communicate
between containers (yes even if they have public IPs).
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
<http://lists.linuxcontainers.org/listinfo/lxc-users>
------------------------------------------------------------------------
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

[David Favor]

Post by jjs - mainphrame
Thanks for the additional info and pointers.
BTW I'd noticed that the ip command showed the extraneous IP missed by
ifconfig. But not showing the extra IP was not the problem, rather that
the extra IP existed at all. In any event, the removal of netplan and
cloud packages facilitate the intended modes of operation in my
environment (system type containers using bridged networking and static IPs)
But I do prefer to see the whole system work as intended, so thanks for
the netplan details.
BTW - re your recommendation to install LXD via snap - is the preferred
install method moving forward?

Removing Netplan will work temporarily, until all the old networking plumbing
is completely removed.

Better to start moving to Netplan now, before some future update removes old
processing of your /etc/network/interfaces files + all your networking simply
stops working.

[Mark Constable]

Post by David Favor
Removing Netplan will work temporarily, until all the old networking
plumbing is completely removed. Better to start moving to Netplan
now, before some future update removes old processing of your
/etc/network/interfaces files + all your networking simply stops
working.

FWIW I completely remove python, therefor netplan, in my lightweight
containers and I find systemd-networkd works just fine as a replacement
of the old ifupdown package. I can't see it ever being removed so I'd
say it's a safe lightweight long-term substitute for netplan.

~ cat /etc/systemd/network/20-dhcp.network
[Match]
Name=e*

[Network]
DHCP=ipv4

[jjs - mainphrame]

Mark,

Good data point. Noted.

Jake

Post by Mark Constable

Post by David Favor
Removing Netplan will work temporarily, until all the old networking
plumbing is completely removed. Better to start moving to Netplan
now, before some future update removes old processing of your
/etc/network/interfaces files + all your networking simply stops
working.

FWIW I completely remove python, therefor netplan, in my lightweight
containers and I find systemd-networkd works just fine as a replacement
of the old ifupdown package. I can't see it ever being removed so I'd
say it's a safe lightweight long-term substitute for netplan.
~ cat /etc/systemd/network/20-dhcp.network
[Match]
Name=e*
[Network]
DHCP=ipv4
--
/Cheers,/
0419 530 037 <tel:[phone]>
RentaNet
/Domain, Web, Mail and Storage Hosting/
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

[Andrey Repin]

Greetings, David Favor!

Post by David Favor
Removing Netplan will work temporarily, until all the old networking plumbing
is completely removed.
Better to start moving to Netplan now,

Not until they publish a sane interface to edit its config.
YAML is NOT a text format. It's a very sensitive binary format. You can't tell
if a YAML file is correct by looking at it on screen.

Post by David Favor
before some future update removes old
processing of your /etc/network/interfaces files + all your networking simply
stops working.

[jjs - mainphrame]

So, is it really the plan to remove all the time honored net utilities? no
more ifconfig, ifupdown, ip, etc? all canned, in favor of some amorphous
systemd add-on?

Maybe I'm old school, but I've always appreciated the fact that I could
type ifconfig or netstat -r on just about any unix box and get an
informative result.

Jake

Post by David Favor

Post by jjs - mainphrame
Thanks for the additional info and pointers.
BTW I'd noticed that the ip command showed the extraneous IP missed by
ifconfig. But not showing the extra IP was not the problem, rather that the
extra IP existed at all. In any event, the removal of netplan and cloud
packages facilitate the intended modes of operation in my environment
(system type containers using bridged networking and static IPs)
But I do prefer to see the whole system work as intended, so thanks for
the netplan details.
BTW - re your recommendation to install LXD via snap - is the preferred
install method moving forward?

Removing Netplan will work temporarily, until all the old networking plumbing
is completely removed.
Better to start moving to Netplan now, before some future update removes old
processing of your /etc/network/interfaces files + all your networking simply
stops working.
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users