Cisco CatalystをLANにつなげると、スマートリモコンがDHCPDECLINEしてしまう件│株式会社シーポイントラボ

ある日、自宅で使用しているスマートリモコン(RATOC REX-WFIREX2)が急にネットワークに繋がらなくなりました。

調べてみると、次のような情報がルーターのログに残っていました。

2022/03/25 12:27:36	DHCPS	DHCPDECLINE of 192.168.11.31 from xx:xx:xx:xx:xx:xx (WFIREX_xxxxxx) via br0: abandoned
2022/03/25 12:27:36	DHCPS	Abandoning IP address 192.168.11.31: declined.
2022/03/25 12:22:32	DHCPS	DHCPACK on 192.168.11.31 to xx:xx:xx:xx:xx:xx (WFIREX_xxxxxx) via br0
2022/03/25 12:22:32	DHCPS	DHCPREQUEST for 192.168.11.31 (192.168.11.1) from xx:xx:xx:xx:xx:xx (WFIREX_xxxxxx) via br0
2022/03/25 12:22:32	DHCPS	DHCPOFFER on 192.168.11.31 to xx:xx:xx:xx:xx:xx (WFIREX_ xxxxxx) via br0

どうやら、スマートリモコンがDHCPでIPアドレスを取得後、どういうわけか取得したIPアドレスを蹴って、LANから切断してしまっているようです。

原因が分からなかったため、とりあえず最近行ったネットワーク構成の変更を思い返してみたところ、最近入手した中古のCiscoのL2スイッチ(Catalyst)が思いあたりました。

とりあえず、一旦CatalystをLANから切り離したうえで、リモコンを再起動させたところ、DHCPDECLINEすることが無くなりました。
やはりCatalystとリモコンの間で何か起きていることは間違いなさそう… ということで、リモコンをつないだ時のCatalystとリモコン間のパケットのやり取りを、Wiresharkを使って観察してみることにしました。

結果、わかったことは、Catalystをつないでいると何やら大量のarpパケットがLAN上を流れていることに気づきました。

また、DHCPDECLINEが発生する原因について調べたところ、一般的にはDHCPサーバー(ルーターなど)からIPアドレスを取得した後で、割り当てられたIPがLAN上で本当に重複していないかをDHCPクライアント側でもチェックすることになっており、ここで重複を検出するとLAN内に対してDHCPDECLINEを送るようになっていることがわかりました。

さらに、この重複を検出する方法として、arpが使用されていました。

DHCP クライアントの障害追跡

もしかしてCatalystから送信されているarpパケットが影響しているのかもしれないと思い、CatalystをLANから切断した状態で、別のLinuxマシンからリモコンのIPアドレスの利用状況を調べるコマンドを手動で実行してみました。

# source IPが0.0.0.0のarpパケットでLAN上に同じIPが存在しないか確認するコマンド
arping  -I Linuxのインターフェース名 -D -c 1  192.168.11.31

すると、面白いことがわかりました。
上記のコマンドでリモコンへarpパケットを送信した1、2秒後に、リモコンがDHCPDECLINEを出すことがわかりました。

一応他の機器へも同じコマンドでarpパケットを送ってみましたが、特に切断されたりDHCPDECLINEを出したりといった挙動はなかったため、どうやらこのリモコン特有の仕様のようです。

なぜリモコンがこのような仕様になっているのかは謎ですが、とりあえずこれで原因は判明しました。

ただ、上記のコマンドで送出されるパケットは通常の状態ではリモコンに送出されることはあり得ないはずです。
なぜなら、このパケットはDHCPでIPアドレスを取得した際に、IPの重複を確認するために使用するものであり、そもそもIPが重複していなければリモコンはsource IPが0.0.0.0のarpパケットを受け取らないはずです。

また、リモコンをルーター側でIPを固定してるし、CatalystもIPの設定はスタティックになっているため、被ることはありえないはず…
さらに、Catalystをつないだ時だけリモコンが切断される現象が起きるため、やはりCatalystが何かしているとしか思えない。

ということで、上記の点を踏まえて再度Wiresharkのログを見直してみたところ、
Catalystが定期的にLAN上の端末にSource IPが0.0.0.0のarpパケットを投げていることがわかりました。

実はCatalystにはLAN上の端末を定期的にスキャンし、状態を追跡する”IP Device Tracking”という機能が搭載されており、この機能で0.0.0.0のarpパケットを使用しているとのことでした。

「Duplicate IP Address 0.0.0.0」エラーメッセージのトラブルシューティング – Cisco

これでようやく、事の真相がはっきりしました。

起きていた現象をまとめると次のようになります。

スマートリモコン(RATOC REX-WFIREX2)はsource IPが 0.0.0.0のarpパケットを受け取るとDHCPDECLINEを吐いて通信を切断する仕様になっている
Cisco CatalystはHostの監視、管理を行う機能として”IP Device Tracking”があり、この機能が有効になっていると、ネットワーク上の追跡対象ノードに定期的にsource IPが0.0.0.0のarpパケットを投げるようになっている
故にCatalystがリモコンに対しても定期的にsourceが0.0.0.0のパケットを投げてしまい、リモコンが受け取ってDHCPDECLINEしていた

つまり、Catalystで有効になっているIP Device Trackingさえ無効にしてしまえば、解決できそうな気がしてきました。

Catalystの全てのインターフェースで無効化してしまうと、影響範囲が大きくなってしまうので、ルーターとつながっているポートでのみ、IP Device Trackingを無効化してみます。

無効化するには、次のようにします。

enable #管理モードに移行
conf t #設定ターミナルへ移行
interface gig1/0/2 #設定対象のインターフェースを指定
ip device tracking maximum 0 #IP Device Tracking無効化

上記のコマンドでは正確にはIP Device Trackingで監視する機器数を0に設定しています。

IP Device Tracking機能自体の無効化は、IOS 15.2(1)E 以降できなくなっているため、代替手段としてこのような設定を行っています。

参考: Catalystスイッチ – IP Device Tracking機能について

この対応を行った後、Wiresharkで再度パケットを確認したところ、CatalystによるSource 0.0.0.0のarpパケットが送信されなくなっていました。

この状態で再度スマートリモコンをLANに接続してみたところ、今度はDHCPDECLINEすることはなくなりました！

同様の症状でお悩みの方は、是非参考にしてみてください。