☰

systemd-networkd は DHCP リクエストを受信しません

tag-icon • tag-icon networking dhcp systemd
systemd-networkd は DHCP リクエストを受信しません

ホスト、コンテナ: fc21

$ systemctl start systemd-networkd.service
$ systemd-nspawn -b -D `pwd` -M m1  --private-network --network-veth

... コンテナ内:

$ systemctl start systemd-networkd.service
$ ip addr
2: host0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether c6:a1:72:9b:16:08 brd ff:ff:ff:ff:ff:ff
    inet 169.254.215.78/16 brd 169.254.255.255 scope link host0
       valid_lft forever preferred_lft forever
    inet6 fe80::c4a1:72ff:fe9b:1608/64 scope link 
       valid_lft forever preferred_lft forever

-> コンテナは、見栄えの良い DHCP 割り当てアドレスではなく、ipv4LL アドレスのみを取得します。

なぜ ？

ホスト上tcpdump -i v1-m1インターフェース host0 の systemd-networkd デフォルト設定に従って、m1 コンテナから送信される DHCP 要求を表示します。

$ sudo tcpdump -i ve-m1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ve-m1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:57:18.768736 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:a1:72:9b:16:08 (oui Unknown), length 271
11:57:19.757532 ARP, Request who-has 169.254.215.78 tell 0.0.0.0, length 28

ホスト上で、systemd-networkdのstraceはUDP DHCPサーバポートをリッスンしていることを示しています。しかし決して読まない:

socket(PF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 12
setsockopt(12, SOL_IP, IP_TOS, [192], 4) = 0
setsockopt(12, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(12, SOL_IP, IP_PKTINFO, [1], 4) = 0
setsockopt(12, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
bind(12, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 12, {EPOLLIN, {u32=2522795824, u64=139692039130928}}) = 0
writev(2, [{"DHCP SERVER: STARTED", 20}, {"\n", 1}], 2) = 21

他のプロセスが同じ UDP ポートをリッスンしていないことを確認しました。

$ lsof |grep -i udp |grep -i bootps
systemd-n 16276       systemd-network   12u     IPv4             265473       0t0        UDP *:bootps

これで、デバッグ スキルの限界に達しました。質問は、これをさらにデバッグするにはどうすればよいかということです。つまり、DHCP 要求がどこで失われるか、またその理由に関する情報を取得する方法はあるのでしょうか。

答え1

次のコマンドを試してください:

$ systemctl stop firewalld.service

はぁ

関連情報