関するご質問はこのフォーラムにお気軽にご投稿ください。amよろしくお願いいたします。稼働環境をお知らせいたします。ファイアウォールデバイスはありますか?>NATがあり、ESP,UDP500,4500のポートフォワーディング適用しております。機能を使用していますか?>利用しておりません。上記環境下で利用させていただいております。表題の通り、L2TP通信がランダムで不安定になります。クライアントは、Windows7、Windows8.1、Android5、Android6、Chromebook全てで発生します。具体的な症状としては、リモートL2TP接続後、規則性なくインターネット接続できなくなります。接続してから良い時では15分くらい、悪い時には5分くらいでL2TP経由のインターネット接続ができなくなります。・この接続できなくなる間は、[ルーターB]にPingを投げても応答しませんでした。・しばらく待つとインターネットへ接続できるようになり、またしばらくすると接続できなくなります。・インターネットへ接続できる間は[ルーターB]にPingを投げてもすぐに応答します。・リモート接続後、ルーターB配下のNAS等には常にPing応答が帰り切断等問題なく利用できます。・Windows機にSoftetherクライアントソフトウェアを導入しての接続では発生しません。L2TPが不安定になるか、ご教示くださいますようお願い致します。大量のパケットが流れ、通信量が異常に多くなった場合、クライアントに正常なパケットを正しく届けられなくなる場合があります。通信量が、通常のネットワーク利用で想定されるものと乖離していないか確認してみてください。大量のパケットが流れ、通信量が異常に多くなった場合、クライアントに正常なパケットを正しく届けられなくなる場合があります。通信量が、通常のネットワーク利用で想定されるものと乖離していないか確認してみてください。ご返信ありがとうございます。ループの可能性や設定ミスについても今でも疑ってはおりますが、以下の条件でも頻発することからL2TPのみの異常を疑っております。Softetherクライアントではインターネット接続不可発生せず、ルーターBからもPingロスも無し、もちろんNASからもPing応答が返る※PingはIPアドレス指定です。非力なARM機器なので過負荷についても疑いましたが、上位のRaspi2でも発生しており、また、vmstatやtopコマンドで確認する限り負荷もほとんど無いため、原因がわかっておりません。パケットを扱う手順がかなり異なるため、やはり通信状況を見てみないことには判断できません。サーバーのパケットログには、問題発生時に何か記録は残っていないでしょうか。amセッションが切れてしまうようであれば、何らかの理由でNATのテーブルが溢れているという可能性も考えられます。可能であればルーターのログやステータスも確認してみると良いかもしれません。amcedar様ご連絡が遅くなり申し訳ございません。>セッションが切れてしまうようであれば、何らかの理由でNATのテーブルが溢れているという可能性も考えられます。>可能であればルーターのログやステータスも確認してみると良いかもしれません。NVR500を確認した限りおよそ200から400程度のセッション数で、最大値の4096には達しておりませんでしたので、NATテーブルあふれは考えにくいかと思っております。FWに関してもルーターのログからは特に異常検出はございませんでした。サーバーのパケットログには、問題発生時に何か記録は残っていないでしょうか。不安定になるきっかけもつかめませんでした。念のためパケットログを添付しておきます。192.168.2.0/24でGWルーターは192.168.2.1NASは192.168.2.2L2TP端末のグローバルIPは36.12.6.82(auLTE)、L2TP接続後のローカルIPは192.168.2.52※192.168.2.10、192.168.2.11はプリンタです。以降からGWルーターへPingが返らなくなります。同時刻、NASからの応答は返っていることがわかります。GWルーターにPingが返らなくなると同時にインターネットへの接続ができなくなります。トラブルというよりもローカルブリッジかスイッチングの問題のように見えます。これをきっかけにルーターのMACアドレスが誤って学習されてしまっている可能性が考えられます。アドレステーブルを参照して、対応付けがおかしくなっていないか確認してみてください。動作が特殊になっているようです。何か相性問題が起きているのかもしれません。amcedar様またご連絡が遅くなり申し訳ございません。検証した結果をお伝えいたします。アドレステーブルを参照して、対応付けがおかしくなっていないか確認してみてください。MACテーブルについての対応付けは特にNASの差異は認められませんでした。こちらに投稿する前にもMACアドレスのエージングタイムに原因があるのではないと、確認しておりましたがランダムで発生することと、エージングタイムが切れる前にも現象が発生していることから可能性は低いと判断しておりました。-d」を実行しても、ルーターへのPingNGは発生したり、しなかったりしていますのでMACアドレスが起因する可能性は低いと判断しておりました。※ARPテーブルを固定化またはGARPあたりを発行すれば回避できるのではと思いましたが、androidやchromebookからのでは実行は厳しいと判断しあきらめました。動作が特殊になっているようです。何か相性問題が起きているのかもしれません。掲示されておりましたNAT方式は、利用しておりますNVR500には搭載されておらず可能性は低いと思われます。YAHAMAルーターのNATと相性をかんがみまして、NEC製のルーターとも交換してみましたがやはり症状が発生しており他の原因を模索しております。スイッチング部分ではないかと思われます。稀ではありますが、受け取ったパケットをそのまま送り返してしまうようなイーサネットデバイス(LANカードやスイッチ)があり、MACアドスが正しく学習されずに通信が寸断される現象が起きる事があります。アドレスが学習されてしまっていないか確認してみてください。amcedar様ご返信が遅れてしまい申し訳ござません。アドレスが学習されてしまっていないか確認してみてください。私が確認した限りでは、特に誤ったMACアドレス学習は確認できませんでした。LUA3U2ATX)2本を利用いたしましたがやはり現象は再発いたしました。※USBNIC1はIPアドレスをセット、USBNIC2はブリッジとしてipアドレスなし。スイッチングHUBについても、Elecom製からBuffalo製へ変更いたしましたが改善いたしませんでした。クライアントへの経路を見失っている可能性も考えられます。ルーター以外の通信に障害は起きていないということなので、ルーターの不具合である可能性も考えられます。ルーターを交換し見てみることは可能でしょうか。連絡が遅くなり申し訳ございません。クライアントへの経路を見失っている可能性も考えられます。>ルーター以外の通信に障害は起きていないということなので、ルーターの不具合である>可能性も考えられます。>ルーターを交換し見てみることは可能でしょうか。12月23日に記載いたしましたが、一度、YAMAHAからNECへルーター変更を実施いたしましたが症状が再現しております。可能な限り交換できるものは交換したつもりではございますが、引き続き再発することから異なる場所にRaspberryPiのみを移設したところ、問題なく接続安定することが確認できました。安定化した環境は変わり映えございませんがに、ONU→ルーター(NATマスカレード)→RaspbrryPiとなります。今回は単純に周辺環境の相性問題かもしれないため、移設先で利用させていただきたいと思います。cedar様にはいくつも助言をいただきありがとうございました。