![systemd-networkd가 dhcp 요청을 수신하지 않습니다](https://rvso.com/image/1451565/systemd-networkd%EA%B0%80%20dhcp%20%EC%9A%94%EC%B2%AD%EC%9D%84%20%EC%88%98%EC%8B%A0%ED%95%98%EC%A7%80%20%EC%95%8A%EC%8A%B5%EB%8B%88%EB%8B%A4.png)
호스트, 컨테이너: 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
한숨을 쉬다