web-dev-qa-db-ja.com

IPヘルパーアドレスが役に立たないのはなぜですか？

Cisco 2811といくつかのリモートサイトを備えたハブサイトがあり、サイト間VPN用に設定されたCisco851ルータと871ルータが混在しています。管理を容易にするために、リモートコンピューターにDHCPスコープとDNSゾーンを追加している最中です。これらのサイトのいくつかは、IPアドレスを正常に取得し、中央サイトのDNSに登録しています。これは、別のサイト（10.30.1.1）にコピーした作業サイトのスポーク構成のサンプルです。

interface Vlan1
 description Site 302
 ip address 10.30.2.1 255.255.255.0
 ip helper-address 172.16.0.1
 ip nat inside
 ip virtual-reassembly
 ip tcp adjust-mss 1452

動作していないサイト10.30.1.1からのUDPパケットデバッグは、同じ構成です（ハードウェアとソフトウェア、両方ともCisco 870がc870-advipservicesk9-mz.124-15.T7を実行しています）。ご覧のとおり、ルータは正しくパッキングされています。 DHCPブロードキャストを送信し、ヘルパーアドレスに送信するCPUからのブロードキャストをアップします。

000150: .Nov 16 20:50:33.752: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67), length=308
000151: .Nov 16 20:50:33.752: UDP: sent src=10.30.1.1(67), dst=172.16.0.1(67), length=308
000152: .Nov 16 20:50:38.862: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67), length=263
000153: .Nov 16 20:50:38.866: UDP: sent src=10.30.1.1(67), dst=172.16.0.1(67), length=263
000154: .Nov 16 20:50:49.683: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67), length=308
000155: .Nov 16 20:50:49.683: UDP: sent src=10.30.1.1(67), dst=172.16.0.1(67), length=308

ただし、このサイトでは、ヘルパーアドレスが応答しないか、応答が通過しません。私はスポークサイトにいるので、まだDHCPサーバーにモニターを配置していません...それが次のステップです。ただし、すべてのアクセスリストは同じであり、さらに、たとえばリモートデスクトップを介したDHCPサーバーへの通信は問題なく機能します。中央サイトのサーバーへのデータベース接続は問題ありません。 DHCPクエリを除き、TCPまたはUDP）、あらゆる形式の通信が機能します。

それで、私は何を逃しましたか？ DHCPサーバーはWindows2008サーバーであり、すでにいくつかのスコープがありますが、許可されるスコープの総数に制限はありますか？私はそうは思いませんでした。
明らかにスコープがアクティブになっています。アドレスが一致します。同じDHCPサーバーが、他のすべてのリモートサイトにアドレスを提供しています。

ciscoipdhcpcisco-vpnudp
2
atroon

DHCPサーバーでスコープを再確認してください。DHCPがこのサブネットの有効なスコープ定義を認識していないようです。スコープオプションでルーターアドレスが正しいことを確認してください。

スコープを削除して最初から再度追加して、表示されていないものが間違って入力されていないかどうかを確認してください。

3
Nick Zepp

これは古い投稿ですが、検索している他の人にとって、IPヘルパーのデバッグに関する質問への回答は「debugipUDP」です。次のような出力が表示されます。

000063: Feb 14 09:45:02.738 BOT: UDP: forwarding packet 255.255.255.255(54583) to 10.107.3.1(5187)
000064: Feb 14 09:45:02.742 BOT: UDP: forwarded broadcast 5187 from 10.107.3.85 to 10.107.3.1 on Vlan10
000065: Feb 14 09:45:03.466 BOT: UDP: rcvd src=10.107.3.114(4421), dst=255.255.255.255(5187), length=96
000066: Feb 14 09:45:03.470 BOT: UDP: forwarding packet 255.255.255.255(4421) to 10.107.3.1(5187)
000067: Feb 14 09:45:03.470 BOT: UDP: forwarding packet 255.255.255.255(4421) to 10.107.3.1(5187)
000068: Feb 14 09:45:03.470 BOT: UDP: forwarded broadcast 5187 from 10.107.3.114 to 10.107.3.1 on Vlan10
000069: Feb 14 09:45:04.802 BOT: UDP: rcvd src=10.107.3.81(2627), dst=255.255.255.255(5187), length=176
0
RWR

私はまったく同じシナリオを持っていて、問題を見つけましたが、解決策がありません:-(

ユニキャストdhcp要求は、NATが実行される前に作成され、内部インターフェイスのIPアドレスは、IP送信元アドレスであると同時にデータフィールドの一部として要求に含まれます。IP送信元アドレスは外部インターフェイスでNATを取得するため、パケットは正常に見えます。

この問題は、DHCPサーバーが要求に応答しようとしたときに発生します。 DHCPでは、受信したパケットのIP送信元アドレスではなく、DHCP要求で見つかったアドレス（つまり、内部インターフェイス）に応答を送信することを除いて、すべて正常に機能します。

私もまだ解決できないので、これが解決策を見つけるのに役立つことを願っています...

0
Rick