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スイッチにまたがるとします。少なくとも1つのトランクリンクの構成の間に不一致がある場合、同様の問題が発生します。
詳細には、DHCP-DISCOVER/DHCP-OFFERの終わりのないサイクル(DHCPサーバー側から見ると)、DHCPクライアントは[〜#〜]ない[〜#〜]DHCP-OFFERを受信しているため、DHCP-DISCOVERメッセージを再発行しています。このようなDHCP-DISCOVER(DHCPクライアント側から見た場合)は、DHCP-SERVERから正しく受信されます。
次のシナリオを検討します。 2つのトランクポートの設定が間違っているか一致していない場合、次のことを意味します。
これはトラブルシューティングが非常に簡単で、ifあなたがDHCPクライアントホストを「制御」します。そのような場合、eth0がDHCPクライアントホストによって使用されるネットワークインターフェイスであると仮定すると、簡単です:
tcpdump -n -i eth0 ether-Host <dhcp-server-mac-address>
ifクライアントがDHCP-SERVERからDHCP-OFFERを受信するかどうかを示します。
クライアント側を制御できるできない場合、トラブルシューティングはより困難になります。
PS:上記の問題はもちろん、他の関連する引数も、適切なテクノロジーを使用して簡単に回避できます( [〜#〜] gvrp [〜#〜] 、- [〜#〜] vtp [〜#〜] またはその他のnot-strictly-manual-config-approach)しかし...これはこの回答の範囲外です
同じ問題があった。 DHCPACKが表示されない。ここでの問題は:
ディスクがいっぱいです
dhcpdは/var/lib/dhcp/dhcpd.leases
に書き込めませんでした。
これを何度か見たことがありますが、これまでのところ、2つの理由しか見ていません。
幸い、どちらも簡単にテストできます。 IPアドレスにpingを送信し、関連するファイアウォールを確認します。
私は仮想ボックスを使用するファイアウォールについて学習しており、サーバーでDHCPACKを取得しない同様の問題があり、ubuntuファイアウォールvmのテストグリーン(内部)ネットワークに間違った仮想ボックスネットワーク設定を使用していることが判明しました。テストUbuntuクライアントVM。 NAT vb内部ネットワークではなくネットワークを使用する場合、クライアント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