HP Procurve DHCPリレーとSRX DHCPクライアントの互換性

一部のJuniper SRX100で構成をブートストラップしようとしていますが、DHCPの問題があります。

具体的には、0/0ポート（ソフトウェアではfe-0 / 0/0）を既存のネットワークに接続しています。DHCPは、私が使用した他のほぼすべてのデバイスに対して非常に確実に機能しています。SRX100はDHCPアドレスを取得していません。私がこれを試みているとき、SRX100は標準のデフォルト構成です。

デバイスの1つを家に持ってきてホームネットワークに接続しましたが、DHCP経由でホームネットワークのIPアドレスを問題なく取得しました。

私のオフィスネットワークのデスクトップには、Procomve 1400（レイヤー2のみ）スイッチがあり、Polycom IP670 IP電話（シンプルなレイヤー2スイッチとして機能）にアップリンクされ、Procurve 3500ylスイッチにアップリンクされ、「ip DHCPリレー用のDHCPサーバーを指しているvlanインターフェイス上のhelper-address 1.1.1.1 "。

SRX DHCPクライアントがProcurveを介してIPアドレスを取得した経験はありますか（K.15.09.0012ソフトウェアを実行しています... Procurveの複数のファームウェアバージョンで問題が発生しています）。SRX100には、出荷時に11.2が搭載されているようですが、12.1X44-D10.4にアップグレードしても問題は解決しないと思います。

これをトラブルシューティングするための提案はありますか？Procurve 3500ylは、SRX100からのDHCPクライアント要求の受信を認めていないようですが、この領域のProcurvesに関するトラブルシューティング情報は限られているようです。DHCPサーバーは、SRX100に関連するDHCPDISCOVERパケットの到着を確認しません。

私の回避策は、SRX100のIPアドレスを静的に構成してネットワーク上で取得し、残りの構成を行うことでしたが、私が取り組んでいるプロジェクトでは、SRX100を自分の制御下にないリモートの場所に送信し、したがって、接続用のDHCPアドレスを確実に取得することに依存しているため、これをトラブルシューティングし、特定の原因を突き止めて、リモートサイトでこれが発生した場合に何を探すかを知りたいと思います。

更新： 工場でデフォルト設定されたSRX100を（再確認するために）直接接続しましたが、Procurve 3500ylのポートに直接接続しましたが、それでも問題が解決されないため、1400とIP670電話がディスカッションから削除されます。以下にSRX100からのtcpdump出力を含めました...ご覧のように、問題が3500ylのdhcp-relay関数にあることが示唆されがちな場合、可能な最も単純なDHCPパケットに関する送信です。dhcp-relay関数にヒットしたパケットを（成功したかどうかに関係なく）3500ylからデバッグ出力を取得する方法が見つかりません。3500ylでこの関数をデバッグする方法についての提案をいただければ幸いです。

tcpdump -n -s 0 -c 1 -vvv -r juniper.dhcp.pcap 
reading from file juniper.dhcp.pcap, link-type JUNIPER_ETHER (Juniper Ethernet)
17:49:11.538670 
Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16
  Device Media Type Extension TLV #3, length 1, value Ethernet (1)
  Logical Interface Encapsulation Extension TLV #6, length 1, value Ethernet (14)
  Device Interface Index Extension TLV #1, length 2, value 34304
  Logical Interface Index Extension TLV #4, length 4, value 70
-----original packet-----
IP (tos 0x0, ttl 1, id 13874, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from a8:d0:e5:1c:68:80, length 300, xid 0x643c9869, Flags [Broadcast] (0x8000)
  Client-Ethernet-Address a8:d0:e5:1c:68:80
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Discover
    END Option 255, length 0
    PAD Option 0, length 0, occurs 56

この問題についてHPにケースをオープンしました。役に立たないレベル1の技術をエスカレートした後、レベル2の技術は私が持っていなかった何かを非常に注意深く発見しました。

SRXは、TTLが1のDHCPDISCOVERパケットを送信しています。Procurveは、明らかにTTLを減らし、その結果のTTLをリレーされたパケットでDHCPサーバーに使用します。この場合、デクリメントによりTTLは0のままになり、パケットがフロアでドロップされます。

これは実際にはDHCP / BOOTPリレーの仕様ですが、明らかに相互運用性が低下します。HPNetworkingにこれをバグ/ RFEとして扱い、動作を変更するように依頼しました。この場合、その要求に対する即時の応答はありません。

TTLが1のDHCPDISCOVERを送信するSRXもおそらく仕様の範囲内ですが、ここでも相互運用性の低下を選択しているため、JTACでも同じ基準でケースをオープンする予定です。

ジュニパーネットワークスとHPの対応が可能になり次第、情報を追加します。

ちなみに、Cisco 4506（ファームウェアのバージョンはすぐには入手できません）とBrocade / Foundry FastIron Edge X（7.2または7.3のファームウェア、確認するための即時アクセス権がないと思います）のリレー動作をテストしましたが、どちらも処理します問題なくTTL 1でリクエストを中継します。

更新 SRXがそのDHCPリクエストで使用するTTL値を変更する方法はありますが、JunOSクライアンス内からではなく、基盤となるUnix OSから行われます。

root@% sysctl -w net.inet.ip.mcast_ttl=64

HPとのRFEを開いて、リレー機能の回復力を高めましたが、それが機能するかどうか、またはいつ機能するかについてはまだ応答していません。

問題がどこにあるのかがわからず、3つのベンダーから3つのデバイスがあり、可視性があるように見える（SRX100、1400、およびIP670）と思われる前に、トラブルシューティングを行うのは難しい場合があります。特定のデバイスと話すことはできませんが、パケットを追跡することで問題が発生することはありません。ProCurve 1400は管理対象外のデバイスであるため、ネットワークタップを使用する必要があります。

次の場所でトラフィックをキャプチャする必要があります（3500ylが検出パケットを受信して​​いないというステートメントに基づく）。

• SRX100と1400の間。
• 1400とIP670の間
• IP670と3500ylの間

これらはすべてデスクから行うことができ、タップを接続/切断している間は混乱が生じますが、それはユーザーとデバイスにのみ影響します。

DHCP検出パケットを少なくとも1回キャプチャし、それ以降のDHCP検出パケットのキャプチャをこれと比較して、変更があるかどうかを確認できるため、このリストの先頭から始めます。

また、動作しているデバイスからDHCP検出パケットをキャプチャして、SRX100が送信する検出パケットとの違いがあるかどうかを確認することもできます。

パケットがどこで失敗するかがわかったら、その時点でパケットが失敗する理由を具体的にトラブルシューティングして調べることができます。

他の場所でSRXをテストしましたが、

1. SRX は自宅とまったく同じ構成のアドレスを取得しますか？
   • これは、以下が問題ではないことを意味します。
   • set security zones security-zone host-inbound-traffic system-services dhcp 行われました
   • 基本的なインターフェース設定が完了しました（rawインターフェース、vlanタグ、正しいvlanのインターフェース、そのvlanのいずれか）
2. ジュニパー側でインターフェイスが実際にクリーンアップされていますか？
   • show interfaces fe-0/0/0 extensive あなたの友だちです
   • （これは適切ではないことはわかっていますが、それでも...）光インターフェイスの場合、電力レベルも確認してください。 show interfaces diagnostics optics ge-0/0/0
3. DHCPクライアントにトレースを追加します。

構成、設定
システムサービスの設定dhcp traceoptionsファイルdhcp_client.log読み取り可能な
set system services dhcp traceoptions flag client
システムサービスを設定するdhcp traceoptions level all
コミットして終了

次に、でインターフェイスを起動するときにログを監視しますmonitor start dhcp_client.log。（完了したら、必ずtraceoptionを削除してください）