「仮想デバイスのデッドループ」とは何ですか？どうすれば修正できますか？
最近、Cisco/LinksysからRVS4000という新しいルーターを入手しました。 「仮想デバイスsit1のデッドループ、緊急に修正してください」というメッセージがログに表示され続けます。しかし、それが何を意味するのか、これを修正するために何をする必要があるのかわかりません。これは私が心配すべきことですか？
検索すると、Linux関連のシステムで同様の質問がたくさん見つかります。実際の答えは多くありません（または私が理解できるものはありません）。橋やトンネルを不適切に設定することを指摘する人もいれば、それ以外の単純なバニラ設定である人もいます。
可能な場合は、ファームウェアのアップグレードから始めることをお勧めします。それから私である私は、それが問題を引き起こしているか、パフォーマンスの問題に気づいていない限り、おそらくそれを無視するでしょう。
私の意見では、人生は現実の問題でいっぱいで、幻のログエントリを追いかけることはできません。さらに、それが本当に重要であるならば、私はもっと決定的な何かを見つけることを期待していました。
それが本当に重要なシステムである場合、私はおそらく別のデバイスに移動します。 CiscoまたはSonicwallによるものまたは同様の品質のいずれか。それらはより高価ですが、適切な状況でそれを価値あるものにすることができる種類のサポートを提供します。
これは古い質問ですが、最近これに噛まれたので、ここで文書化させてください。6to4インターフェイスを使用しているが、内部ネットワークへのルートが欠落している場合は、このエラーをトリガーできます。私の場合、いくつかの仮想マシンを別のサブネットに配置しましたが、自分のマシンがこのサブネットのゲートウェイであることをルーターに伝えるのを忘れていました。
ルーターで何が起こっているかを推測することしかできません。内部ネットワーク宛てのパケットは、デフォルトの2002 ::/16ルートでキャッチされ、6to4トンネルにプッシュされ、IPv4パケットにカプセル化され、そこでレンガの壁にぶつかります。宛先アドレスはパブリックIPv4アドレスになるためです。すでにアウトバウンドキューに入っているので、それがカーネルを混乱させる理由がわかります。
私は、DebianSqueezeシステムの1つにある2つのsitデバイスでこの問題を経験しました。デバイスの構成スタンザでttl 64を指定することにより、メッセージフラッドを排除しました。
auto sit1
iface sit1 inet6 v4tunnel
address ................
netmask 64
endpoint ................
local .................
gateway ..................
ttl 64 <=================================
Cisco/Linksysルーターには興味がありません。これらのルーターのいくつかはLinuxをベースにしていることを知っているので、コードを見てみることにしました。このメッセージは、ソフトウェアデバイスがある種の無限ループに陥ったときに表示されます。コードでは、「ソフトウェアデバイス」という用語は、ループバックデバイスとトンネルを指します。
Hunterjiが上で述べたように、IPトンネリング構成がある場合はそれを再確認し、ファームウェアのアップグレードを試みます。