解決/応答されていないarpリクエストの考えられる理由はどれですか？
今週末、私はサービスプロバイダーからの新しいデータリンク接続をテストしていて、いくつかのアドレス解決の問題を経験しました。
ISPから提供されたいくつかのネットワークパラメータを使用して、自分の側のラップトップを使用して、遠端のホストへの到達可能性をテストしました。
次に、UTMの使用可能なNICで構成した場合、同じホストに到達できませんでした。ルーティング構成が正しく設定されていることを確認した後、tcpdumpでスニッフィングを開始しました。反対側の最初のホップに対するLinuxUTMのARP要求（_arp who-has_）が応答を取得していなかったことがわかりました。そのため、そのIPアドレスの_<incomplete>_エントリがUTMのARPテーブルに作成されました。
一時的な回避策として、_arp -a_を介してUTMのARPテーブルに永続的なエントリを追加しました。
私のarp要求に応答しないホストがCiscoルーターであることがわかりました（nmap OS検出機能によるとCisco 7600 router (IOS 12.2)）。この問題の根本的な原因は何でしょうか？
- ルーターのARPにある種のACL構成？ （私のラップトップはARP解像度を取得しました）
- 一部の_
arp_filter_は、他のサブネットからのアドレスへの応答を許可していません/ NAT必須ですか？ - UTMで同じアドレスを設定すると、ルーターのARPテーブルとスプーフィング保護のラップトップの一時的なエントリがアクティブになります。
- 不正な形式のARP要求？ （同じUTM上の他のデータリンクでこの問題は発生していません）
- 「理解できない」ARP回答がUTMに送信されましたか？
- 他の？
データリンクのネットマスクは_/30_であるため、arp要求に応答できるホストは2つだけです（私のUTMとルーター）
更新：
私のISPからの返信：
セキュリティポリシーが適用されていますが、MACアドレスレベルでは、アクセスポート（Gi7/3）の場合、そのポートへのトラフィックを許可するMacは最大10個あり、ログにはこの日付までに4つのエントリが登録されています。セキュリティアクション（制限）がまだアクティブ化されていないことを確認します。
より多くのNICを利用できるようにするために、UTMのハードウェアをアップグレードしました。このアップグレードでは、私のNICデータリンクの受信が含まれていましたが、動作は同じで、静的arpエントリがないと、Ciscoルーターにパケットを送信できませんでした。 。
（これは https://networkengineering.stackexchange.com/ に移動する必要があります）
「理解できない」ARPはありません。Linuxボックスがarp-requestsで応答を受け取らない場合、network-configは正しく（IP、ネットマスク）、イーサネットは機能します（インターフェースはUPです）。
したがって、Ciscoデバイスへのアクセスがない原因について何も言うことはできません。考えられる原因：
- どういうわけか間違ったnetwork-config
- 静的arpエントリ
- ファイアウォール/フィルタリング/.。