YAMAHA業務向けルーター運用構築スレッドPart25

【お約束】
ここはYAMAHAルーターなどで小規模〜大規模のネットワークを
構築、運用する人のための情報交換スレッドです。
ネットボランチシリーズ(コンシューマー向け)、業務用向け機器でもYAMAHAルーターの
設定方法、YAMAHAルーターの使い方などハードウェア寄りの話題は関連スレへ

【公式サイト】
RTXシリーズルーター
https://network.yamaha.com/products/routers/
RTpro - ヤマハネットワーク周辺機器 技術情報ページ
http://www.rtpro.yamaha.co.jp/
ヤマハネットワーク機器
https://network.yamaha.com/

【関連スレ】
YAMAHAヤマハブロードバンドルーターpp select 26
http://mevius.5ch.net/test/read.cgi/hard/1544435522/

【過去スレ・前スレ】
YAMAHA業務向けルーター運用構築スレッドPart19
http://mao.5ch.net/test/read.cgi/network/1485790427/
YAMAHA業務向けルーター運用構築スレッドPart20
http://mao.5ch.net/test/read.cgi/network/1501976932/
YAMAHA業務向けルーター運用構築スレッドPart21
http://mao.5ch.net/test/read.cgi/network/1527602451/
YAMAHA業務向けルーター運用構築スレッドPart22
http://mao.5ch.net/test/read.cgi/network/1558571559/
YAMAHA業務向けルーター運用構築スレッドPart23
http://mao.5ch.net/test/read.cgi/network/1591073378/
YAMAHA業務向けルーター運用構築スレッドPart24
https://mao.5ch.net/test/read.cgi/network/1609198305/

2get v(^-^*)

>>1おつ

前スレで最後たくさん書き込んでた人はもう気が済んだのかねぇ

>>4
書かなくなったってことはそうなんじゃない？
まあ、原因の見立てが正しいかは知らんが。

>>4 >>5
原因わかりました。

Linux---IPv6インターネット---[OGW]--IPv6--ラズパイ4

上記テスト環境で、Linux→ラズパイ4方向について、
IPsec(IPsec as IP4 over IP6 )通信速度をiperf4で調べました。
結果は次のとおりです。

[ 4] 9.00-10.00 sec 3.37 MBytes 28.3 Mbits/sec 0 118 KBytes


一方、次の環境についても調べました。
Linux---IPv6インターネット---[HGW(500番台)]--IPv6--ラズパイ4
結果は、次のとおりです。

[ 4] 4.00-5.00 sec 14.0 MBytes 117 Mbits/sec 0 589 KBytes

この結果から、OGWがIPsecに対して非常に遅いということが判明しました。
したがって、RTX1210はどうやら悪くなさそうです。
OWGが信じられないくらいに遅かったのでした。

>>6
うん知ってたって反応したくなる結果ですね。

>>6
ちなみに、600番台HGWを用いても同じテストをしましたが、
速度は変わりませんでした。

前スレッドにも書いたとおり、
600番台HGWではなぜか折り返し通信がうまくいかないので使っていません。
ただし、インターネット上のIpv6マシンとの通信はできた。
IPv6アドレスの変更もなかった。

これについてはHGWのファーム更新を期待したいと思います。
（500番台に戻すと折り返し通信もできた。）

>>7
やってみないとわからないのか化学

>>8
機器の切り替えを短時間で行い、すぐにテストしなかったかい？

>>10
500番台をはずして、600番台を取り付けてテストしました。
網側の情報書き換えが追いついていないということでしょうか。

十分程度放置したけど解決しなかった。

そういえば、以前も別機種で、なかなかpingが通らず、
焦ったことがありました。
これは諦めてしばらくしてから試すと繋がって、首を傾げたことがありました。

これもそうってことかな。

>>11
クライアントとONUの間の機器を変えた場合、
Neighbor Cacheの更新がクライアント側、網側双方ともなされるまで通信が不安定（できる機器・できない機器が混ざるなど）が当然起きます。

>>12
ありがとうございます。

休みだし、600番台に戻して様子をみます。

置き換えた直前なので、今は折り返し通信不可の状態です。

>>13
約10分経過、まだping6が通らない。
もう少しまとう。
インターネット側のLinuxマシンとは最初からIPv6で疎通している。

フレッツで正規の切断手順踏まずに切って他の機器繋いだ場合最大1時間くらいはキャッシュでおかしくなることがあるな

>>14
20分経過
まだ通らない。

>>15
正規の切断手順って？
DCアダプター抜いただけ。

>>12
でも、折り返し通信だけ不可で、
インターネットとの通信はできるのはどうしてなんだろうか。

>>17
今試している接続構成を余すところなく書いてくれんと答えようがない。

>>18
今取り組んでいるのは、
純粋にHGWの置き換えにまつわるトラブルについて。

変化するのはHGWの置き換えだけで、接続しているRTXの設定にはいっさい変更がないし、
IPv6アドレスが変化していないことも確認済み。

HGWの置き換えで網側のルーティングに関する情報が再設定されるまで折り返し通信ができないという仮説のもと、
待機している。


今30分経過したが、まだ無理

>>19
IPアドレスが変化しないことが一つの鍵にも思えるからこその提案だったんだがね。
書きたくないならいいよ。

>>13
>>15
これで60分経過した。
まだNGN折り返し通信が通らない。（繰り返すが、インターネット側ホストとのIPv6通信はできている）

もうちょっと待ってみるか。どうせ休みで誰にも迷惑かからないし。

試すことは悪くないけど、出来ない、出来ない　とだけ言ってても良いことないのではないかな？
アマチュアならまだしも、仕事なら出来ない人アピールでしかない。

リンクダウンにならないとPPPoE切断判定しないよね
工事後にPADI Timeout連発で全然つながらないってコール多いもん

>>10
ご報告すると、
>>12
2時間半まったけど、ping6が折り返しの対向に届かなくて、
>>15
さすがにもとの500番台HGWに戻しました。
>>21
設定は全部RTXが持っていて、IPv6アドレスの変化はいっさいないから
原因不明
また数カ月後に暇ができたら試してみようかなと思います。

レスアンカーがおかしいですと誤解されるので、アンカーはこういう形態にしました。

そもそもHGWの二台をとっかえひっかえすること自体どうなんだっけ？
NTTは許容していないと思うが。

ONU内蔵型だったら、取り換えの前後でIPv6が同一のサブネットで降ってくること自体があり得ないんじゃないかと思う。

Defaultのセキュリティ設定外したんだろうか…

そもそも回線紐付けのはずのHGWを交換できるって2個目はどっから調達したのかって問題が

RTXのコンフィグ作成で、シェルスクリプトみたいに自由に変数とか、コメントとか使えたら良いのにな
あと、フィルタにいちいち番号を付けないといけないのも面倒。
リナックスのiptablesの設定みたいになればいいのにと思う。

>>29
フィルタ周りはあれでいいわ
iptablesとか20行超えてくると順番の変更すら面倒臭いじゃん

>>30
iptablesコマンドの集合で作られるルールを、
スクリプトにまとめると便利だよ

ルールを変更する場合は、スクリプトを変更して、
スクリプトを実行するだけにしておく。

スクリプト変更前はバックアップをとっておくとバージョン管理も簡単

すげえいまさらだけどRT57iにdisconnect pp 1コマンドないんね
入れ換えるときにちゃんと切断かけたいんだがrestartでも切ってくれるかな？

RTX1210でご助言をいただきたいです。
RTX1210にWindows10をVPN接続(L2TP/IPsec)して運用しております。

接続台数が14台を超えたあたりから、VPNは張れるものの、PCからはRTX1210と同一セグメントにあるサーバーにはpingが通らなくなります。
RTX1210あてにはping通ります。

CPUとメモリの負荷は低く、回線も空いてます。
再起動してみましたが状況変わらず。
これはスペック的な限界によるものでしょうか？
どこか設定変更で改善できればよいのですが。

proxy arpの設定があるパターンですか？

ありがとうございます。
proxy arpはONにしております。

複数のトンネルと複数のトランスポート作成するときに、templateは使ってる？

>>33
クライアントからサーバーへのpingが通らなくなった段階で、
RTX1210からそのサーバーへのpingは通るのかな？

アドレスがかぶってるとか？

クライアントが使っているアドレスが内部と被っているんじゃねL2TPだし

>>32
古いRTはdisconnectだけでppは省略されてる

昔はppしか接続切断は考慮してなかった
それでtunnelの接続切断が出来なくて現場で困った記憶がある

>>36
L2TPとかで5接続以上になったら設定見直し時にテンプレート化してる
tunnel定義が無駄に長いとメンテしにくい
業務だとメンテしにくいのは将来的に無駄やトラブルのもとになるし

>>41
L2TPで、繋げたときに取得するIPは想定されてるIPが出てきてますか？
LANインターフェースやトンネルインターフェースにフィルターは記載ありますか？
L2TPで接続後にプリンター等にping行きますか？

西日本NGN（フレッツネクスト）だけど、
RTXで網内の両端(RTX)がIPv6のIPsec構成の場合、
ESPパケットドロップされない？

IPsecセッションは、show ipsec saで確認できたし、対向へping 192.168..を打つと、
ESPパケットがこちら側からOUTされていることをフィルタで確認できたが、
相手側にESPパケットが届かない。

もちろん、ping6で双方の通信は確認済み。

これ、NTT側でIPsec通信が無条件で落とされていないか？

ちなみに、以前から使用しているRTX同士の通信は落とされないで通信がキープできている。
新しい機器を設置した場合、IPsec通信は落とされるのかな。
（VPN商品を売りつけるため）

>>43
IPv6パケットの優先制御設定に問題があると思うんだけど、
RTXでIPv6パケットをNGNに適した優先制御設定する方法ってありますか？

このへんとか関係あるかな。これでフィールドを書き換えできる？
http://www.rtpro.yamaha.co.jp/RT/docs/qos/band-shaping.html

ipsec ike nat-traversalを設定したらどう？

>>45
レスありがとうございます。
それはESPをUDP4500ポートで使うというやつですね
一度やってみたいと思います。

33です。
皆さんレスありがとうございます。
恥ずかしながら原因がわかりました。

導入は業者さんに設定をお願いしておりまして、中身を良く理解していなかたのですが、先ほど自分で設定を確認してみたところ、トンネルに関する記述が1〜13までしかありませんでした。
そりゃ14台目からつがなりませんよね。
その業者さんYAMAHAを使える人が退職してしまい、対応できるかわからないとのことなので、なんとか自力で20個ぐらいに増やしてみたいと思います。
なぜ13個にしたのかもわからず。

テンプレートは使われていませんでした。

スレ汚しすみません。33です。
トンネル13個は見ていたコンフィグファイルが古く導入時のものでした。
Web GUIから最新コンフィグを見たところ、トンネルの記述は40個ありました。
以前Web GUIからリモートアクセス用のVPNユーザー追加した際に連動して増えていたようです。

ということで、また原因がわかなくなってしまいました。

>>37
通ります。

>>38-39
最近症状が再現しなくなってしまったので確認できておりません。
DHCPサーバーで発行されるIPアドレスと
ip pp remote address poolで指定しているIPアドレスは重なっていなかったです。
再現しましたら確認いたします。

>>41
私へのご返答ですかね？
通常はプリンタ等へping通ります。
14台以上になると通らなくなります。

>>48
まさかトンネル記述はあるけどpp bindに当たってないとか
ipsec transportが設定されてないトンネルがあるとかじゃね

その程度の問題はYAMAHA業務ルーター向けサポートに問い合わせれば対応してくれるぞ

RTXのCUIのコマンドプロンプトの#のところに、Linuxマシンみたいにホスト名を表せないかな。
#マークだけだと、複数のルーターを設定しているときに非常に混乱してしまう。

>>50
自己レスです。

すみませんありました。

# console prompt ?
入力形式： console prompt プロンプト文字列
　 　説明： 64文字以内でコンソールのプロンプト文字を設定しますさｇ

>>43

>>43
自己レスになります。

うまくいきました。
原因は、LANインターフェイスに192.168.100.1という設定があったためです。
LANインターフェイスはDHCPCによってアドレスをネットワークにあわせて自動取得するようにしていました。
ルーターから対向へpingテストすると、ネットワークのアドレスからではなく、192.168.100.1から対向へicmpパケットが飛んでいたらしく、
対向は192.168.100.1へのルートが未設定でした。
そのため、片方からはpingが飛ばないという問題が発生していました。
優先制御関係ありませんでした。

>>49
ありがとうございます。
pp bindとipsec transportの設定には矛盾はありませんでした。
Web GUIでVPNユーザー追加するとちゃんと自動設定してくれてました。

iOS 15のPrivate RelayってQUIC接続なんやね

>>55
ヤマハもQUICプロトコルに対応するかな

>>56
対応するって何？

10年後ぐらいじゃね？

それよりクロスパスにちゃんと対応して欲しい
スクリプトとか書かないで済むようにしてくれ

スクリプト書かなくても使えるけど？？？

固定IP契約なんでしょ。

そう固定IPだけど、動的ならそのまま使えるん？
固定と言っても外部からのアクセス受ける訳じゃなくて
ポート沢山使いたいだけなんだけど

動的ならスクリプト無しでいけるね

公式設定例のスクリプトはDDNS使ってる場合の登録変更じゃないの？

IPv6プレフィックスが変更になった時の自動対応用で普通に使うだけなら
スクリプトなしでも通信はできるな
ただし障害とかでIPv6プレフィックスが変更になったら自動で復帰しない

つまりスクリプト無しで使えるとか言ってるのは
プレフィックス変わったら切れる前提って事だね
自宅なら良いけど仕事には使えん

クロスパスだけの問題じゃねーよ
v6プラスでも同じだ

気になるなら業務用に可変使うなってこと

クロスパスの技術仕様なかなか無いからわからんかったけど
mfeedのDS-Liteと違ってDDNS登録しないとトンネル貼れない仕様なのか
それで仮対応した結果がluaスクリプトなのか

外部DDNSへの対応が必要だな
今のYAMAHAはアップデート遅いけど半年ぐらいで対応するんじゃね

>>67
いやクロスパスの特殊仕様DS-Liteの問題
DDNSへの登録がIPv4トンネル接続に関わってる

>>69
DS-Liteの問題ではない。

DS-LiteでもIPv4動的アドレスの契約ならDDNS登録要らなかったわ
固定IPv4アドレスの契約だとDDNS登録必須だから要スクリプト

この辺はクロスパスでもmfeedのtransixサービスでも一緒だった
DS-Liteで一括りにしちゃダメだな

DS-Liteとそうでないものを一括りにできないのは当然だわ

telnetしてから、viが使えるようにしてほしい
そして、コメントをたくさんかけるようにしてほしい

#コメント
コマンド
コマンド
#コメント
コマンド

>>71
MAP-Pの仕組みを使った固定IPをやってるＯCNバーチャルコネクトでも同じ。
というか、仕組み上、どこのサービスでもこのようなやり方をしないと円滑なサービス提供を実現できない。

>>71
クロスパスの固定IPはDS-Liteではない

http://mevius.5ch.net/test/read.cgi/hard/1618238582/
このスレの >>954-960 がちょっと気になってる。
>>960の記述でなんで990ポートに問題が起こらへんのや？

>>76
動的フィルタってｔcpflugは無視するんだっけ？

>>76
Dynamicフィルタのトリガパケットが通過すると
相手側送信元ポートと内部990ポートへのフラグを無視した双方向の通信が許可されている模様

ダイナミックフィルタのコネクションを確認するshow ip connectionのテーブル見る限りTCPフラグは無いからポートレベルで判定してるかと
YAMAHAの技術資料からは具体的な動作が読み切れないから確証はないけど

FTPとかFTPSとかのPORTモードはNATとかフィルタとか考慮しない時代の産物だから面倒よね

>>78
なるほどー、理にかなってる推察。
そもそも昔はリビジョンではtcpflagなんて指定は出来なかったし、静的フィルタにだけ後からTCPフラグが設定出来るように追加されたイメージなのかもしんない。

YAMAHAルータって現行機種はもう全て業務用って扱いになってるの？

>>80
一般家庭用なら、サイトももっとそれ用のデザインにしていると思うが。
https://network.yamaha.com/

>>80
一般向けじゃないな
機能的にも性能や安定も家庭やSOHO程度ならばもっと安いので十分というか、速度は負けていたりw
フレッツのレンタルでもVPNできるからな

NVRは簡単なリモート保守用として昔から(RT)重宝されていて、アホな顧客ではベンダー毎に用意してあって同じサーバーラックにゴロゴロあったりするよ

速度で他社のブロードバンドルーターに明らかに勝てなくなったのはRT55iの頃の印象

速度をあまり求められなかったISDN全盛時代のヤマハルータは今風に言うと神っていたのじゃよ…

RTX1000で一気にパフォーマンス上がって実用性上がった印象あるわ
あと耐久性もRTXシリーズから寿命どうなってんのと思うぐらい壊れないし

>>85
ハードウエアはRTXクラスならば他社も壊れないよ

いまだに動いているRTX1000とかあるからな
ブロードバンドといえばRT58iで1000BASE-T搭載しなかったことに呆れたっけ

RT59iの登場が待たれる

>>88
58iの後継はNVR500。

NVR510が出てる

RTX1000はファームウェアのアップデートでスループットがめっちゃ上がったのが印象的

RTXはRTにブロードバンドを意味したXを付けた型番だけど
NVRってどういう意味の型番なんだろ

NetVolante Router→NVR

ネットボランチシリーズも当初は個人向けで頑張ってたが今やVoIP用とターゲット変わったよね
ちょっと前までNetVolanteブランドでホームページも独立してたのに今はYAMAHA本体に統合
個人向けはもう終わった感

ISDN全盛時代は独特の輝きがあった
時間課金の時代、通信が発生した時だけ自動でダイヤルアップして繋がったりとか便利だったよ
こういうノウハウって今はもう出番ないのかな

大震災レベルの災害が起こってあちこちで光ケーブル破断したらダイアルアップ接続が光り輝くようになるよ

>>92
network video recorder用かと思た

VoIPもクラウドPBXやビデオ会議系に蹴散らされちゃった感あるしなぁ
安価なUTM路線なんかで頑張ってほしい

変なことしなくていいから売り切りのVPNルータとしてそのままの位置でいて欲しい

>>96
既にアナログ電話網はバックボーンがほぼ光なんだがw

マジレスするとBRIの代替にはLTEドングルで十分だよな
速度も出るし、大企業のとあるエンドユーザ向け端末でも使ってたし