web-dev-qa-db-ja.com

DHCP：DHCPREQUESTの問題

たぶん、DHCPとネットワークについてもっと知っている誰かがこれを手伝ってくれるでしょう。私はしばらくの間これを見て投げられたので、ServerFaultコミュニティに連絡しています。

システムを転用する際に、本番データセンターからサーバーを移行しました。ローカルラボでは、サーバーをPXEで環境に起動しましたが、PXEで正常に起動し、イメージを正常にロードしました。ただし、イメージをロードした後、キックスタートをダウンロードできませんでした。 DHCPログから、新しいIPアドレスを取得しようとしていて、取得できなかったことがわかりました。 PXEは、ローカルのPXE/DHCPサーバーを使用して起動し、ロードしてからDHCPを再試行すると、ラボ環境外のランダムサーバーに到達します。 DHCPログは次のとおりです。

dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 via 10.6.246.1
dhcpd: DHCPOFFER on 10.6.246.9 to 00:11:22:33:44:55 via 10.6.246.1
dhcpd: DHCPREQUEST for 10.6.246.9 (10.6.247.236) from 00:11:22:33:44:55 via 10.6.246.1
dhcpd: DHCPACK on 10.6.246.9 to 00:11:22:33:44:55 via 10.6.246.1
xinetd[3010]: START: tftp pid=26359 from=10.6.246.9
in.tftpd[26360]: RRQ from 10.6.246.9 filename /pxelinux.0
in.tftpd[26360]: tftp: client does not accept options
in.tftpd[26361]: RRQ from 10.6.246.9 filename /pxelinux.0
in.tftpd[26362]: RRQ from 10.6.246.9 filename /pxelinux.cfg/44454c4c-5800-104e-8057-b9c04f4b4e31
in.tftpd[26363]: RRQ from 10.6.246.9 filename /pxelinux.cfg/01-00-11-22-33-44-55
in.tftpd[26364]: RRQ from 10.6.246.9 filename //images/RHEL-6.4-x86_64/vmlinuz
in.tftpd[26365]: RRQ from 10.6.246.9 filename //images/RHEL-6.4-x86_64/initrd.img
dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 via 10.6.246.1
dhcpd: DHCPOFFER on 10.6.246.9 to 00:11:22:33:44:55 via 10.6.246.1
dhcpd: DHCPREQUEST for 10.88.254.102 (10.88.254.22) from 00:11:22:33:44:55 via 10.6.246.1: ignored (not authoritative).

注意事項は次のとおりです。

  1. 00:11:22:33:44:55は私が参照しているMACアドレスです
  2. DHCPサーバーでは、サブネット10.6.246.0はauthoratativeとして設定されます
  3. DHCPサーバーでは、オプションルーターセクションは10.6.246.1に設定されています。これは、デフォルトゲートウェイであり、ネットワーク内では、ネットワーク上のあらゆるものにアクセスできます。

これは奇妙に見えますか、それとも私だけですか？あるべきではない何かに手を差し伸べているような気がします。

また、10.88.254.102サーバーと.22サーバーはどこからでもpingできませんが、nmapを実行すると、squid-httpサーバー（プロキシサーバー）が表示されますが、私のネットワークチームはそれらを私に伝えますARPエントリがないため、「ダウン」しています。

私はここで途方に暮れています。

networkingdhcppxe-boot
3
drewrockshard

自分で問題を解決することができました。プロビジョニングしていたサーバーと同じスイッチ（したがって、同じネットワーク/ VLAN）に不正なDHCPサーバーがありました。

これは奇妙な間違いでした。両方のサーバーが同時に接続され、2番目のサーバーが実際に起動し、サーバーが古いDHCPサーバーであったため、DHCPオファーを発行し始めたためです。私はそれがその目的のために使用されていたことさえ知っていました。ネットワークチームにオファーを追跡してもらいましたが、問題の原因となっているのは2番目のサーバーであることがわかりました。でもとても奇妙です。

2
drewrockshard