YAMAHA業務向けルーター運用構築スレッドPart23
■ このスレッドは過去ログ倉庫に格納されています
>>596
もうとっくにIPv6移行技術の方式をまとめる気はなくなってる
IPv6移行技術の方式がそれぞれあるのは前提として、プロビジョニング方式を揃える話になってきている
http://www.v6pc.jp/jp/entry/wg/2020/08/ipv6_10.phtml ASAHIネットのv6コネクト
アルテリア・ネットワークスのクロスパス
がDS-Liteを採用してる コメントありがとうございます。
ocnバーチャルコネクトは固定IPでrtx830の機器にすれば良さそうですね。法人向でも動的IPと安い方の機器(ドコモルーター)は業務用では避けるようにします。 ポート開放してPPPoEの通信速度で不足が出るなら仕方ないけど、普段の通信はOCNバーチャルコネクトで、特定のポートが必要な通信はPPPoE経由でと使い分ければいいんでないかな 今日新製品の発表あるのかな
なんかイベントあったよね 10G対応のRTX後継は来年後半だからまだ出ないよ >>605
今日の13時から17時だね
Zoom開催だから、時間がある人は見ていいんじゃないかな
https://network-innovation.jp/ynif2020/ RTXからのSYSLOGを2台のsyslogサーバに転送してたけど
ログを突き合わせても時間が合わないので、どうして？って思ってたら
RTXから送られてくるsyslogにタイムフォーマット含まれてなくて
受け取ったsyslogサーバ側でタイムスタイムスタンプ付与してた
（ログサーバの片方のntpdが起動してないのが原因だった（恥） で、ニュースサイトにも何もあがってないようだし、新製品を臭わせるような発言は無しか 某大規模案件で在庫が少ないから新製品どころじゃないのかな？ >>608
なるほどね。
RTXはログにタイムスタンプしないのか。 >>612
syslogのフォーマットで必要な、時間とホスト名のヘッダー情報が付与されてない
PRIとmessaageだけだった RTX830は届いたが1210が注残
在庫のまま年越しかねぇ rtx1210とswx3200の組み合わせで評価してるんだけどなんかGoogleとYouTubeと一部サイトが繋がらない。
他はサクサクなんだが、
これって機械のせいじゃないよね、
回線かpcが悪いとおもってるんだけど >>615
複数のPCで共通なら回線かネットワーク機器
特定のPCだけならそいつのせい
機器でありがちなのはMTU, IPv6->IPv4のフォールバックとかじゃないの？知らんけど。 自分のpcも無線で繋いだiPhoneもそうなっちゃってちょっとやな感じだなと
ちなみに無線apもヤマハ で全部ヤマハ 構成
やっぱやめときゃよかったかな、、
なんか機器のバグとかだったら嫌やな dns server select 1 reject aaaa .
dns server select 2 pp 1 any .
などと 自分が設定ミスって起こしたトラブルをメーカーのせいにされるなんてヤマハも可哀想だなw やっぱ設定ミスっててるだけだよね
ちょっと安心したわ
いつもウィザードぐらいでしか設定してなかったからあんまヤマハ 詳しくないよね
>>621
これはどんな効果あんですか？ そういやYAMAHAのL3SWは普通に動くようになったの？ WLX212 のsyslogに
[SYSTEM] <5113> Log message were saved to FLASH.
ってのが1時間おきに出てるんだけど、flashメモリの寿命は大丈夫なのかしら？
RTXの方はフラッシュメモリにガリガリ書き込むと死ぬよ。保証対象外だよって書いてあったので気になってる
ttp://www.rtpro.yamaha.co.jp/RT/docs/rtfs/index.html >>625
「平常時はRAMバッファ+syslogサーバ送信のみ、syslogサーバに繋がらない時だけフラッシュ保存」ていう設定はないのかな？
と思った。 NVR500って光電話の複数番号の鳴り分けって可能？？
GUIから設定すると、PR-600側で片側しか内線のステータスが登録にならないね。
もしかして、光ネクストのipv6をNVR500に持って来ないと無理なのかな？？
ちなみに、PR-600からはUNIポートからLAN出して、ONUのルータ機能切ってます。 >>627
その疑問は、公式の設定例を見てのものかい？ >>627
ONUにルーター機能はない
HGWのルーター機能もひかり電話機能も生きたまま、NVRをHGWのSIP子機にする話？
だとしたらひかり電話をNVRで収容しないのは何故？ 意地悪だなぁ型番書いてあるから分かるっしょ
HGWのルーター部を切り離してONU単体として接続してるんでしょ >>630
だとしても、
> GUIから設定すると
のくだりが意味わからんが 他スレに出張してGUI有るから初心者でも使えるとか言うアホが居るからこうなる >>626
syslogはUDPで投げっぱなしだからそういうの無いわけですよ
ログを保存するのはデフォルトでそうなってるみたいで特に設定は無さそうですわ
保証期間すぎたあたりで故障するようなSタイマーもどきとかだったら嫌だなーと思いますが
気にしないことにしよう >>627
UNI出しでipv6を生かしたままそういうことをやるのは結構茨の道だから、おすすめできん。 そもそも、書いている内容に矛盾があるから返答は無意味 RTX1210のWEB画面のダッシュボード。
設定はほぼコマンド叩いていCUIで入れているけど状態チェックには有用なんで使っていたら
WEB画面表示が壊れて使えない状態に。
原因はカスペルスキーだった。
カスベルを新しいバージョンにしたらどうやらデフォルトでローカルのIPもトラフィックチェックするようになったみたい。
いつも使っているブラウザーを信頼アプリにしてすべてのトラフィックをチェックしない設定をローカルIPに設定したら
表示が壊れなくなった。
同じ問題に遭遇した時の参考にどうぞ >>639
危険に判断されるコードでも混じっていたのかな
なにに反応したのか知りたいところだね
オリジナルのjavascriptかな。 >>627
着信電話番号によって着信するアナログポートの選択はできないのか？ >>625
RTX1210とかで、
syslogはデフォルトでフラッシュにかきこまれているのか？ 全社のネット接続（ブラウジング）がダウンした。
原因は、DNSによる名前解決の失敗だった。
そして、犯人は、RTX1210 Rev.14.01.34 だったと結論する。
RTX1210 Rev.14.01.34には静的DNSレコードが複数登録されていて、
拠点での名前解決を全てこちらにさせていた。
RTX1210 Rev.14.01.34は、前も同じ障害を一回だけ引き起こした。
普段は正常に機能していることと、今回DNS以外のルーティングなどの機能は正常だったこと、そして再起動で回復したから、
このルーターには名前解決に関するなにかしらのソフトウェア的なバグがひそんでいると考えられる。 >>644
IP電話も全て名前解決に依存しているから、
社内のあちこちのサービスがダウンした。
しかし、それでいてパケットは正常にルーティングされ、
VPNもつながるので当該ルーター（RTX1210 Rev.14.01.34）の異常だと見抜けなかった。
なにかとんでもない大規模障害が発生しているのではないかと、アドレナリンが脈打った。
これで二回目である。
随分時間が経っていたので、再びRTX1210 Rev.14.01.34の名前解決問題だと見抜けなかった。
非常に焦った。
基幹にはYAMAHAルーターやめて、Linuxマシンをルーター代わりに使おうかなと本気で考えている。 普通ルーターとDNSは分けるけどね
同じ機器で兼用させるのは自宅だけにしときなよ >>645
さらに言っておくと、
名前解決不能の問題を引き起こしたRTX1210 Rev.14.01.34 は、
毎日定時に再起動をスケジュールしている。
だから、おそらく、再起動の段階で、名前解決不能な状態に陥ってしまうのではないかと思う。
たとえば年間を通じて365回再起動すれば、そのうち低頻度でこの問題が発生するのではないだろうか。
再起動がアダとなったと言えると思う。 >>646
静的レコードを含むDNSキャッシュサーバーは、dnsmasqかなにかをLinuxマシンで使うことにする。
でも、今度は無停電電源の配備など、ハードウェア的な故障も考慮しないといけなくなるなあと。
VPSに肩代わりさせたとしても、ネットがダウンしたら駄目になるしなあ。
まあ、ネットがダウンしたら、DNSが正常でも不通になるからどっちみち意味ないか。
VPSにdnsmasqかなにかでDNSキャッシュサーバーを構築するしようかな。 顧客への信用ガタ落ち
このような意味わからんバグが放置されていることにとても腹が立っている。
まあ、他の人が言うように、ルーターはルーターとVPNサーバーやIPフィルタなどのIPレベルでの機能のみ使って、
それ以外の機能は他のサーバーを使うべきだったと反省している。 くどくどと書いてもうしわけない。
自分が使っているルーターが、そのバグのせいで地震のように突発的に地面をゆるがせ、
焦らせることにどうも納得行かないわ。
問題が起きた場合に備えて対策をとっておくことが必要だが、
バグが放置されていることに納得いかない。 やっぱり、大勢の人が使っていて、
問題提起するOSSの方がいいのかもしれないと思う。
とくに、IPレベルを超えるアプリケーションレベルの実装は、OSSの方が良いのかもしれない。 バグが放置されるのに納得がいかないなら自分でバグの無い機器作ればいいと思うよ。
定期再起動とかDNS兼用とかしておいて顧客の信用がー言うのはちょっと浅過ぎる なんの為の再起動なんだかね。
叩けば治るテレビかよ 日ごとの再起動って、普通でない。
普段使われるものから、バグは見つかり改善されていくものだから、ほとんどの人がしない使い方をしている時点で、障害に巻き込まれに行っていることを自覚すべきだな。 この人はグダグダと自分は能なしですって自己紹介してるの？
2回目なんでしょ？ そんなにやってるのにファームウェアは最新じゃないとかなんなの？
どうせLinuxでサーバ立てても同じように運用間違いで障害起こすよ
個人的に思うけど静的レコードをYAMAHAに任せるとか正気の沙汰とは思えない
第一、その静的レコードが原因でネット接続ができないとかどういう仕様なの？
普通はDNSサーバを複数端末に登録して一つ死んでも何とかなるようにするのが本来のDNSの運用でしょ？
それなのに一つが死んだら「はい全部おしまい」とかネットワーク管理者として下の下の行為だと思うのだが 1台アホになったら全オチを招く設計がさ、
個体にグチグチいう話かってね。 >>657>>656
ヤマハ寄りの意見が多いな
さて、なんのためにリリースノートがあると思ってるんだ？
構築時ならともかく、意味のないアップデートは自ら問題に巻き込まれに行くようなものだ。
仕様変更が影響して不具合が生じる可能性もある。
ネットワーク規模、顧客がかけられる費用も色々だろう。
複数DNSサーバーを立てれば、そのメンテナンスも必要になり、対応できる人員にも限りがある。
静的レコードをルーターにまかせてしまうのも一つの手だと思う。
そもそも、キャッシュサーバー機能に欠陥があるまま残されていることが問題だ。
再起動後に、DNSキャッシュサーバーが動作しなくなる危険性が排除されていないことがそもそもの問題。
それを指摘するだけの利用者がないということだろう。
ヤマハルーターに肝心の機能にバクが残されている訳だから、ルーターを別メーカーに変えてしまうか、アプリレベルにおいてはOSSを使うということは良い手だ。
>>654
毎日再起動のどこが異常な使い方なんだ？
アプリや、サービスを再起動させないで使う場合、不具合が重なって動作しなくなる可能性がある。
実際、ヤマハルーターでも、再起動させると問題が解消されるということがしばしばあった。
再起動するということは、開発時の動作状況にリセットするということだ。
動作時間を重ねることで異常な状態になるのを防いでいる。 >>659
何十台も冗長化してたら、
寝ぼけて作られたデバイスでも安全なんだろうね みんなYAMAHA寄りなんじゃ無くてエンジニアとしての思想や設計がおかしい、って言ってるだけなんだけど噛み合わないんだろうなと思いましたまる >>655
2度も生じる問題なんだから、
偶然でなく、バグがあるんでしょう。
設計について、指南してくれなくて結構。
指南するつもりもないくせに。 >>664
欠陥にはめもくれないで、
穴の空いたバケツを多重化して機能を維持するのが共通のエンジニアなんですか？ もうヤマハ使うのやめよう。
OSSで実績のあるLinuxの方が色々安心できる。 >>664
たしかに多重化してなかったのはネットワーク設計の問題だろう。
しかし、それだけを問題とみなす見方が多いな。
安定なソフトウェアなら、こうも頻繁に問題を起こさない。
ネットワークではないが、あるOSSのデータベースはコケたことないぞ。
データベースは複雑なものでしょ。
それでも今まで何年もコケたことなく動作している。
自分の指摘は、デバイスの安定性の問題。
もし、後も頻繁に問題を起こし、壊れるハブがあったら使わないのと同じ。
ヤマハルーターは、ハードウェアが壊れることはほとんどない印象はある。 バケツには穴が空いてるかもしれないと思いながら影響を極小化するように組み合わせるのがエンジニアの仕事じゃないのかなぁ。
空いてないと信じたり、空いたって騒いで得られる物があるならそれでも良いのかもね。 事象発生時のログやらメモリダンプやら
サポート連絡すりゃね。
察するに、無理だろうけど >>669
穴の空いていない物を探すのも大切で、
穴が空いていることを周知することも大切だと思う。
設計については当たり前の話で、
それをどうするかは別問題。
穴が空いていることを冗長化で見えなくすることでそれを指摘しないことが良いとは思わない。
冗長化を前提とする穴開きデバイスならいらない。 >>670
再起動したら治ったからね。
開発者でもなければデバッグ材料を集めるのは無理でしょう。
だから、バグとしてしつこく残っているんだろうけどね。 複数拠点があるようだと小さい環境ではないでしょうに。
DNS障害で拠点内でさえも全業務が止まるような構成にしてはそもそもダメだろ。 >>673
DNSを冗長化してなくての障害ということね。 > 冗長化を前提とする穴開きデバイスならいらない。
冗長化を前提としないデバイスが存在する世界に俺も行きたいなぁ、って思いました。新鮮だった。 >>671
穴開きどころか、底抜けだったわ
RTX1210のDNSキャッシュサーバー機能は突然に死ぬ危険があるので注意が必要です。
私の場合、動作の初期化のために再起動を毎日スケジュールしていました。
再起動直後かどうかは分かりませんが、再起動後にDNSキャッシュサーバー機能が死にました。 >>675
もうそういう指摘はいいから
それに、変なところで、引用するな。
イメージ操作かよ。 >>676
この問題は、年間で2度も生じたので、
何か明らかに不具合がありそうです。 昼から必死でこんなトコで意識高い風にイキってるから面白かったんです。絡んじゃいけないって分かってたのにごめんなさい。 これって
>>147
>>153
か。あーはいはい >>681
それ。
半年に一回程度かとおもってたが、
数カ月に一回の頻度でDNSキャッシュサーバー死んでるな。
>>682
休みがなくなった DNSが死ねば全業務が止まるのは事前にわかる訳だし、そんなシングルポイントを作った過去の自分を呪うべきかと。 >>684
ソフトウェアの開発もしないといけないし、雑用もあるし、なかなか忙しくて余裕がなかった
今後は、DNSキャッシュサーバー機能は、
Linuxマシンで対応することにした。 >>684
本当にDNS死ぬと、障害が一見、多発しているみたいに見えてしまう。
普段、DNSなんて意識しないからその影響について忘れてしまう。
過去からの習慣は引き継ぎやすい。
問題発生をきっかけに優先順位改めようと思う。
人が死なないと対応が為されないことって、世の中でも色々ある理由がわかりそう。 ソフト開発も業務ね…
だとすると、とても残念な人だな。
今あなたがYAMAHAに向けている怒り(他から見て、その一部はどうかと思うが)は、多分同じように自分に返ってきそうだね。理不尽と思いながら対応してそう。 >>688
怒りでなくて、事実のレポートでしょう。 >>688
だとすると残念だ
という論理的なつながりがわからない >>688
自分に返ってきそう
というのもわからない。
しそう
という表現も、論拠がなくて、
占い師さんですか？ >>686
> 忙しくて余裕がなかった
データベースもPCごと冗長化したほうがいいよどうせしてないんでしょ？
何年もこけたことない＝ずっと未来永劫こけないじゃないよ
ソフトウェアが落ちなくてもハードウェアが死ぬこともあるでしょうよ
個人使用じゃなくて業務なんでしょ？
起こりうる障害に対策をしてないと今回みたいにもっと忙しくなるよ
あのWindowsですら二か所もDNSサーバーを入力する場所があるのにもかかわらず、
DNSを冗長化してないのはどうかと思うよ
「Linuxで運用する！プンプン！」って言ってるけど冗長化しなかったらまた同じことになるよ。
そしたらまたPCか何かのせいにするの？
はっきり言って社員の中には「明らかにあいつのミスだ」って思ってるひとはいると思うよ
ハードウェアは壊れることもあるということは考えたことない？
静的DNSを使うのだって要は手抜きでしょ？
IPアドレス直打ちの方が確実でしょ？
それでDNSを二つ立てるのも面倒で手抜き。
それで障害が起こったらプロならすぐわかるようなことなのに
素人管理者が原因の特定にも時間がかかって業務の足を引っ張る
そういう運用をしているようじゃまたやらかすよ？ あなたの投稿でのYAMAHAの立場は、あなた自身の立場でもあるだろうに。
ソフト開発、本業でしょ？ 2台並べてりゃねえ、ケーブル引っこ抜いて
サポート受けるのに動態保存できるんだし。
無駄に再起動はするわで、この半年やるべきことはあったよ。
被疑部位を証明出来なきゃただの嘘になる 実際どのぐらいの規模運用してんの？
障害を克服するためにリブートかけるような運用してるのが祟っただけだろう
たとえバグだとしても
それ以外のハード的、ネットワーク的トラブルが発生しても
そういう運用構成じゃ大規模書発生するだろうって話では？
たとえLinuxつかったとしても
その調子じゃ同じ事起こすって気づかないのかな？
データベースは大丈夫だって言ってるけど偶々故障がなかっただけだろう >>694
似た仕事であって、
同じ立場であるはずがない ■ このスレッドは過去ログ倉庫に格納されています
