DHCPDISCOVER / DHCPOFFER, DHCPACK 없음

DHCPDISCOVER를 보내는 원격 클라이언트 시스템이 있습니다. 서버가 DHCPOFFER로 응답하고 있지만 DHCPACK이 없습니다.

동일한 호스트에서 약 30 초마다 반복됩니다. 원격으로 수행 할 수있는 작업이 있습니까, 아니면 누군가 재부팅해야합니까? 그것은 데이터 센터에 있기 때문에 그것을하기 위해 여행해야 할 수도 있습니다!

제안 해 주셔서 감사합니다. 모든 컴퓨터를 재부팅했지만 여전히 문제가 있습니다. 구성에 문제가 있다고 생각합니다. 이것이 올바르게 보입니까?

#
# /etc/dhcpd.conf for primary DHCP server
#

authoritative;
ddns-update-style none;
deny duplicates;
default-lease-time 600;
max-lease-time 3600;

# Our fixed hosts
host host2  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.202; }
host host3  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.203; }
host host4  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.204; }
host host5  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.205; }

subnet x.x.x.128 netmask 255.255.255.128 {
  option subnet-mask 255.255.255.128;
  option broadcast-address x.x.x.255;
  option routers x.x.x.129;
  option domain-name-servers 8.8.8.8, 8.8.4.4;

  # Testing pool.
  pool {
    max-lease-time 300; # 5 minutes
    range x.x.x.250 x.x.x.254;
    deny known-clients;
  }

  # Our hosts - I didn't have this pool declaration before, do I need it if I want
  # the hosts to be running dhcp but always get the same address?
  pool {
    max-lease-time 1800;
    range x.x.x.200 x.x.x.220;
    deny unknown-clients;
  }
}

간다 :

CLIENT -> DHCPDISCOVER
SERVER -> DHCPOFFER
CLIENT -> DHCPREQUEST
SERVER -> DHCPACK

설명에서 DHCPACK 전에 DHCPREQUEST가 누락되었습니다.

클라이언트가 DHCP 서버와 다른 서브넷에있는 경우 DHCPOFFER는 포트 67 UDP의 DHCP 릴레이로 유니 캐스트로 전송됩니다. DHCP 릴레이 에이전트는 DHCPOFFER를 UDP 포트 68의 서브넷으로 브로드 캐스트합니다.

DHCPOFFER와 관련된 연결 문제를 조사했습니다. 그것을 추적하고 클라이언트로 돌아가는 길을 찾으면 클라이언트가 왜 DHCPREQUEST가 아닌지 주소를 확인하십시오.

일반적인 dhcp 릴레이 에이전트는 특정 인터페이스의 Cisco 스위치에있는 "ip helper-address"옵션입니다.

DHCP 서버와 DHCP 클라이언트가 모두 동일한 이더넷 세그먼트에 연결되어 있고 이러한 이더넷 세그먼트가 다양한 "트렁크"( 802.1q ) 링크 와 상호 연결된 여러 L2 스위치에 걸쳐 있다고 가정 하면 비슷한 문제가 발생했을 때 하나 이상의 트렁크 링크 구성간에 불일치

상세하게 말하면, DHCP-DISCOVER / DHCP-OFFER의 끝없는주기 (DHCP 서버 측에서 볼 때)는 DHCP 클라이언트가 DHCP-OFFER를 수신 하지 못하고 DHCP를 다시 발행 한다고 생각합니다. -디스 커버 메시지. DHCP-DISCOVER (DHCP 클라이언트 쪽에서 볼 수 있음)는 DHCP-SERVER에서 올바르게 수신됩니다.

다음 시나리오를 고려하면 두 트렁크 포트의 설정이 잘못되었거나 일치하지 않습니다.

• 트렁크를 따라 SW A에서 SW B로 (또는 DHCP 서버에서 DHCP 클라이언트로) 전송 된 VLAN X 트래픽은 태그가 지정되지 않습니다.
• 트렁크를 따라 SW B에서 SW A로 또는 DHCP 클라이언트에서 DHCP 서버로 전송 된 VLAN X 트래픽은 태그가 있습니다.
• SW B 트렁크 포트의 기본 VLAN 설정으로 인해 DHCP 클라이언트는 DHCP 서버로부터 패킷을받지 않습니다 .

이것은 문제를 해결하는 데 매우 쉽습니다 만약 당신이 "통제"는 DHCP 클라이언트 호스트. 이 경우 eth0 이 DHCP 클라이언트 호스트에서 사용하는 네트워크 인터페이스라고 가정하면 다음과 같습니다.

tcpdump -n -i eth0 ether-host <dhcp-server-mac-address>

클라이언트가 DHCP-SERVER로부터 DHCP-OFFER를 수신 하는지 표시 합니다 .

클라이언트 측을 제어 할 수 없는 경우 문제를 해결하기가 더 어렵습니다 .

추신 : 위의 문제뿐만 아니라 다른 관련 주장은 GVRP , VTP 또는 기타 수동적이지 않은 구성 접근법 과 같은 적절한 기술을 사용하여 쉽게 피할 수 있지만 ...이 답변의 범위를 벗어납니다.

같은 문제가 있었다. DHCPACK이 표시되지 않습니다. 여기에 문제가 있었다 :

디스크 꽉 참

dhcpd에 쓸 수 없습니다 /var/lib/dhcp/dhcpd.leases.

나는 이것을 몇 번 보았고 지금까지 두 가지 이유 만 보았다.

• DHCP 서버가 제공 한 IP 주소는 이미 다른 장치에서 사용 중입니다. 일반적으로 DHCPNAK가 표시됩니다.
• 방화벽이 dhcp 서버에 대한 트래픽을 수락하고 있지만 다시 트래픽은 허용하지 않습니다.

다행히 두 가지 모두 테스트하기 쉬워야합니다. IP 주소를 핑 (Ping)하고 관련 방화벽을 확인하십시오.

나는 가상 박스를 사용하는 방화벽에 대해 배우고 서버에서 DHCPACK을 얻지 못하는 비슷한 문제가 있었고 우분투 방화벽 VM의 테스트 녹색 (내부) 네트워크에 대해 잘못된 가상 박스 네트워크 설정을 사용하고있는 것으로 나타났습니다. 테스트 우분투 클라이언트 vm. vb 내부 네트워크 대신 NAT 네트워크를 사용하는 경우 클라이언트 vm은 DHCP 서버 vm이 아닌 vb에서 IP를 가져옵니다. 로그는 서버가 클라이언트로부터 요청을 받고 있음을 보여 주지만 클라이언트는 대신 vb에서 IP를 얻으므로 서버로 ACK를 다시 보내지 않습니다.

나를 위해 클라이언트에서 DHCP 서버를 끄는 것을 잊어 버리는 경우가있었습니다 (인터넷 공유를 통해). 이 기능을 끄 자마자 DHCP 임대가 승인되었습니다.

Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPREQUEST(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPACK(eth0) 10.0.0.4 40:6c:8f:59:24:8e Heaths-MBP