search

jpetazzo / pipework

Software-Defined Networking tools for LXC (LinuX Containers)
Apache License 2.0
4.22k stars 727 forks source link

Using DHCP on CoreOS #20

Closed helander closed 9 years ago

helander commented 10 years ago

pipework uses udhcpc for DHCP leases, but udhcpc does not seem to be available in CoreOs. Anyone that has experience with pipework on CoreOS and use of DHCP?

jpetazzo commented 10 years ago

It should be possible to use another DHCP client, as long as it supports one-shot operation.

Which DHCP client ships with CoreOS?

helander commented 10 years ago

I think it is the busybox dhcp-client. I tried it, but could not get it to work.

jpetazzo commented 10 years ago

Did you get any kind of output?

helander commented 10 years ago

If I recall correctly (it was a couple of days since I tried) it seemed like the client started and "communicated" with a central daemon (guessing a bit here and I do not know the architecture of the busybox dhcp solution), I did not see any traces of lease requests being made, not sure where to look,

jumanjiman commented 10 years ago

I did not see any traces of lease requests being made, not sure where to look

I had the same questions and found that coreos uses systemd-networkd as seen with journalctl. In the following snippet, host IP is 51.3.1.54/24 and was provided by dhcp server 51.3.1.1.

core@localhost ~ $ journalctl -u systemd-networkd
-snip lots of output-

core@localhost ~ $ journalctl -u systemd-networkd | grep -i dhcp
Mar 19 17:47:06 localhost systemd-networkd[463]: enp2s0f0: DHCPv4 address 51.3.1.54/24 via 51.3.1.1
Mar 19 18:06:59 localhost systemd-networkd[459]: enp2s0f0: DHCPv4 address 51.3.1.54/24 via 51.3.1.1
Mar 23 21:49:00 localhost systemd-networkd[459]: enp2s0f0: DHCP lease lost
Mar 23 21:53:07 localhost systemd-networkd[461]: enp2s0f0: DHCPv4 address 51.3.1.54/24 via 51.3.1.1
Apr 12 02:40:47 localhost systemd-networkd[462]: enp2s0f0: DHCPv4 address 51.3.1.54/24 via 51.3.1.1
May 01 13:27:10 localhost systemd-networkd[461]: enp2s0f0: DHCPv4 address 51.3.1.54/24 via 51.3.1.1
May 03 20:03:57 localhost systemd-networkd[3478]: enp2s0f0: DHCPv4 address 51.3.1.54/24 via 51.3.1.1

core@localhost ~ $ ls -l /etc/resolv.conf 
lrwxrwxrwx 1 root root 32 Mar 12 23:21 /etc/resolv.conf -> /run/systemd/network/resolv.conf

Additional info is at:

jumanjiman commented 10 years ago

i also found this message

...add SYSTEMD_LOG_LEVEL=debug to the environment of systemd-networkd

You can just run SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/systemd-networkd directly after systemctl stop systemd-networkd too.

jpetazzo commented 10 years ago

Let me summon my favorite systemd expert! :-)

@seblu: do you know if there is a way to tell networkd to do its magic on a network interface, when that network interface is in a different namespace? My intuition tells me that we should bring up networkd in the namespace, let it get the DHCP lease, then terminate it. But... Yuck.

cameron commented 9 years ago

@seblu I await your arrival with baited breath.

starkovv commented 9 years ago

+1

starkovv commented 9 years ago

@jpetazzo @seblu Any news on topic? :-)

flipchart commented 9 years ago

+1

jpetazzo commented 9 years ago

My last changes hopefully address this issue: 19bc094

Can you test it and report?

jpetazzo commented 9 years ago

Closing older issues.

pppq commented 8 years ago

On CoreOS beta 877.1.0 (docker version 1.9.1), the dhcp option doesn't seem to work for me. The helper container stays around indefinitely, with the following output:

1/2/2016 8:39:50 PM udhcpc (v1.24.1) started
1/2/2016 8:39:50 PM udhcpc: sendto: Network is down
1/2/2016 8:39:50 PM Sending discover...
1/2/2016 8:39:50 PM Read error: Network is down, reopening socket
1/2/2016 8:39:53 PM Sending discover...
1/2/2016 8:39:53 PM udhcpc: sendto: Network is down
1/2/2016 8:39:53 PM Read error: Network is down, reopening socket
1/2/2016 8:39:56 PM Sending discover...
1/2/2016 8:39:56 PM Read error: Network is down, reopening socket
1/2/2016 8:39:56 PM udhcpc: sendto: Network is down
1/2/2016 8:39:59 PM Read error: Network is down, reopening socket
1/2/2016 8:40:02 PM Read error: Network is down, reopening socket
1/2/2016 8:40:05 PM Read error: Network is down, reopening socket
1/2/2016 8:40:08 PM Read error: Network is down, reopening socket
1/2/2016 8:40:11 PM Read error: Network is down, reopening socket
1/2/2016 8:40:14 PM Read error: Network is down, reopening socket

The eth1 interface added by pipework is not in UP state by default, and can not be brought up in the container in question:

core@coreos ~ $ sudo ./pipework enp0s3 -i eth1 5d489f03addf dhcp
root@5d489f03addf:/# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:03
          inet addr:172.17.0.3  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:acff:fe11:3/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:49 errors:0 dropped:0 overruns:0 frame:0
          TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3645 (3.6 KB)  TX bytes:2802 (2.8 KB)

eth1      Link encap:Ethernet  HWaddr f2:d4:fe:cd:8b:fb
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:75 errors:0 dropped:0 overruns:0 frame:0
          TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:38281 (38.2 KB)  TX bytes:38281 (38.2 KB)

root@5d489f03addf:/# ifconfig eth1 up
SIOCSIFFLAGS: Operation not permitted

It is possible to do so in the DHCP helper container, however:

/ # ifconfig eth1 up

Following which, the next discovery attempt succeeds, but the interface is never updated with an IP address:

1/2/2016 9:26:17 PM Read error: Network is down, reopening socket
1/2/2016 9:26:20 PM Read error: Network is down, reopening socket
1/2/2016 9:26:37 PM Sending discover...
1/2/2016 9:26:40 PM Sending discover...
1/2/2016 9:26:40 PM Sending select for 192.168.178.225...
1/2/2016 9:26:40 PM Lease of 192.168.178.225 obtained, lease time 43200
root@5d489f03addf:/# ifconfig -a
[...]
eth1      Link encap:Ethernet  HWaddr f2:d4:fe:cd:8b:fb
          inet6 addr: fe80::f0d4:feff:fecd:8bfb/64 Scope:Link
          # no "inet addr" line appears here
          *UP* BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1474 (1.4 KB)  TX bytes:1680 (1.6 KB)
[...]

The output for eth1 is the same in the helper container, if I keep udhcpc around with the foreground -f option.

(Note that dhcpcd is installed by default on this version of CoreOS, and pipework succeeds in allocating an address without problems if I use that option instead of dhcp.)

pppq commented 8 years ago

BTW, this looks very similar to what @dreamcat4 describes in https://github.com/jpetazzo/pipework/issues/163#issuecomment-144538955 and below.

pppq commented 8 years ago

For future reference, I'll also mention https://github.com/jpetazzo/pipework/issues/182 here (dhcpcd runs indefinitely, because it does not treat option -q as "run in one-shot mode").

jpetazzo commented 8 years ago

I've merged #186, does it provide alternate DHCP options that could work for you?

pppq commented 8 years ago

I am not using pipework actively at the moment, just happened to try it on containers running on CoreOS at the time. To summarize (hopefully correctly):