2019年08月24日(土) - 22:35 | カテゴリ:
Network
“ns-lab BB”のIPv6アドレスはHurricaneElectricからトンネルで調達している為、
接続点となるゲートウェイにはGREトンネルを張れるJuniperSRXを採用している。
年開けにルータが1回不機嫌になったのだが当時はその場で復旧させて様子見をしていたが、
先日の夏コミが終わり一段落した辺りで、このルータが故障して起動しなくなった。
別途出力しているログを解析した所、Junosを保存しているファイルシステムが吹っ飛び、
リカバリすら処理出来ない状態になった結果、
リカバリの再起動がスタックして通信出来なくなっている事が判明した。
メール鯖・DNS鯖は自宅とVPSでハイブリッド構成にしているので、
AAAAレコードをDNSゾーンから消す事で障害復旧したが、
DigiLoog含むWEB鯖は自宅サーバで稼働している事もあり、IPv6接続経路がないのは致命的だった。
さらに、ノートPC・スマホ用にIPv6のみを専用に喋るAPも動いており、
ルータが壊れるとInternetも見れなくなる環境がある為、IPv6接続環境を早めに修復する必要があった。
………
いくら嘆いても、壊れた物が直る訳では無いので代替手段を即検討開始。
上がったのは、
- 従来通りJuniperSRXを利用
- VyOSで仮想ルータ化
- IIJ SEILなど他ルータを入れて環境リプレース
の3択。
最後まで迷ったのだが、VyOSを動かせるリソースが仮想サーバ基板に無い事と、
他ルータに入れ替える際のH/W選定も出来ていなかったので、従来通りJuniperSRXを購入する事にした。
という事で、Juniper SRX100H2を2台買って来た。
常時稼働しているのは1台だが、以前から検証用途にも使いたかった為、今回を機に2台にした。
ちなみに、今まで稼働していた機種を正確に書くと「Juniper SRX100B」
今回購入したのは、マイナーチェンジ版となる「Juniper SRX100H2」となる。
SRX100シリーズは基本スペックに違いは無いのだが、
搭載しているメモリ・フラッシュ容量が下記の通り拡張されていたり、
サポートしているJunosバージョンが上がっていたりする。
| Model |
DRAM |
FLASH |
| Juniper SRX100B |
512MB |
1024MB |
| Juniper SRX100H |
1024MB |
1024MB |
| Juniper SRX100H2 |
2048MB |
2048MB |
今回は、SRX100シリーズの最終モデルとなるSRX100H2を購入した事もあり、
公式サポート中の12.3X48-D85以降を稼働させる事も出来るが、大きなメリットの一つとなる。
………
左：Juniper SRX100B
右：Juniper SRX100H2
基板レベルだと搭載パーツに違いがほぼ無く、チップのマイナーバージョン上がっているのみに見える。
それ以外だと、SRX100Bのメーカーロゴはジュニパーの木を模した古いロゴとなっている点と、
メーカーロゴに近くに制御用COMピンヘッダが半田付けされている事くらい。
という事で、H/Wレベルの大きな違いが無い事も判ったので、
バックアップコンフィグを使って設定リストアを実施。
Junosのメジャーバージョンが12.1から12.3に上がった点が気になったが、
コマンドを投入したら問題無くバックアップコンフィグを認識した。
………
以前は自宅NW基盤をH/Wレベルで冗長化している時期もあったが、
電気代がバカにならないので数年前にシングル構成に直した所、今回のルータ故障が直撃した。
とは言っても、普段は使わない機種を電源いれっぱなしにするのも辛い昨今なので、
同機種を検証機として使い回す事で一種の「コールドスタンバイ」とする事にした。
最近はネットワーク系から少し離れているので、そろそろNW層の追っ掛けも再開したい所。
ネットワーク仮想化・サービスチェイニングの概念が今後は出てきそうなので、
この辺りを今回購入したルータを使って構築出来るかチャレンジするのも良さそう。
技術ネタを追いかけるのは大変な事もあるが、
実環境に即反映出来る楽しい分野でもあるので精進したいと思う。
« 続きを隠す
2019年04月06日(土) - 21:48 | カテゴリ:
Network
“ns-lab BB”では、Webサーバ用と権威DNSサーバ用の2回線を使っているが、
4月5日早朝に両回線ともにメンテナンスでダウンした。
当初、Webサーバ用回線のメンテナンスしか頭に入っていなかったので少し焦ったが、
蓋を開けたら収容局の回線借用影響だった。
一方、自宅のコアルータではトラッキングとPBRを組み合わせる事で片回線が落ちた時、
もう片方に切り替わるようにルーティング制御も行っており、
グローバルIPを固定化する必要が無い通信は動的に切り替わる構成になっている。
という事で、ルータ変更以来久々に自鯖NW回線が全断したのでルータログを追いかけてみた。
ちなみに、”ns-lab BB”コアルータの構成は下記の様になっている。
コアルータから各ISP越しに2箇所ずつtrackingを仕掛け、ISP越しの通信が全断したらtrackingを落とす。
ファイアウォールはあえてISP毎に1台ずつ設ける事で、セッション増にも対応出来る様にしてある。
今回、収容局近くの回線借用だった為、結局はISPへ接続する事が出来なくなり、
回線が一時的に落ちる形になった。
この回線が全部落ちた時のログがこちら。”boolean or”も仕掛けているので綺麗に6個が落ちた。
Apr 5 03:56:47 Router 563: Apr 5 03:56:46.555 JST: %TRACK-6-STATE: 110 ip sla 1110 reachability Up -> Down
Apr 5 03:56:47 Router 564: Apr 5 03:56:46.555 JST: %TRACK-6-STATE: 120 ip sla 1120 reachability Up -> Down
Apr 5 03:56:47 Router 565: Apr 5 03:56:46.555 JST: %TRACK-6-STATE: 210 ip sla 1210 reachability Up -> Down
Apr 5 03:56:47 Router 566: Apr 5 03:56:46.555 JST: %TRACK-6-STATE: 220 ip sla 1220 reachability Up -> Down
Apr 5 03:56:47 Router 567: Apr 5 03:56:46.571 JST: %TRACK-6-STATE: 100 list boolean or Up -> Down
Apr 5 03:56:47 Router 568: Apr 5 03:56:46.571 JST: %TRACK-6-STATE: 200 list boolean or Up -> Down |
逆に復活した時は下記の通り。今回の借用時間は100～150分だったのだが、
実際には30分程度で工事が完了したのか、無事に接続が復活した。
Apr 5 04:25:58 Router 569: Apr 5 04:25:57.061 JST: %TRACK-6-STATE: 110 ip sla 1110 reachability Down -> Up
Apr 5 04:25:58 Router 570: Apr 5 04:25:57.061 JST: %TRACK-6-STATE: 120 ip sla 1120 reachability Down -> Up
Apr 5 04:25:58 Router 571: Apr 5 04:25:57.061 JST: %TRACK-6-STATE: 210 ip sla 1210 reachability Down -> Up
Apr 5 04:25:58 Router 572: Apr 5 04:25:57.061 JST: %TRACK-6-STATE: 220 ip sla 1220 reachability Down -> Up
Apr 5 04:25:58 Router 573: Apr 5 04:25:57.061 JST: %TRACK-6-STATE: 100 list boolean or Down -> Up
Apr 5 04:25:58 Router 574: Apr 5 04:25:57.061 JST: %TRACK-6-STATE: 200 list boolean or Down -> Up |
ルーティングの方も無事に切り替わっていたのだが、こちらはログがかなり多いので割愛。
ip trackingは挙動がわかりやすいので本業でも使う事が多いのだが、
監視元・NW経路・監視先を全部把握していないと痛い目を見るのが怖い所。
今回も、ISP-A(Webサーバ用回線)のメンテナンス情報は最初から知っていたのだが、
ログを見たらISP-B(権威DNSサーバ用回線)経由のtrackingも落ちていたので、
設定をミスってしまったのか1時間程度コンフィグを追いかける事になった _(:3」∠)_
意外と綺麗にログが取れる物で、trackingログとルーティングの遷移ログをsplunkとかに入れて、
縦串の相関分析をかけると面白い遷移図を出す事が出来る。
“ns-lab BB”はサーバに比重を置いているので、NWログ取得はそこまでやっていないが、
今後はこの辺りにも目を向けつつサーバのオートメーションと、
NWの遷移切り替えを図に出来ると面白いかもしれない。
« 続きを隠す
2018年12月03日(月) - 00:30 | カテゴリ:
Network
こうして、グローバルIPを引き継いだ上でフレッツ光への移行が完了した。
物理層の移行なので、スイッチ・ルータなどの上位層はギガビット化以外は何もやっていないが、
現在も問題無くインターネットを利用出来ている。
写真の通り、インターネットに接続する箇所がかなりスッキリした。
ただ、光ケーブルとSCコネクタがどうしても出っ張ってしまう為、
曲げ耐性のあるケーブルに変更すると、さらにコンパクト化出来そう。
この構成で数日使い続けているが、物理・論理の両方とも特に問題は出ていない。
製品の稼働耐熱が40度なので夏場が少し怖いが、周囲に熱源が少ないのでなんとかなると思う。
肝心の回線速度は次の通り。測定は「2018/12/01 16:30～17:00」に、WEB用ISP経由で実施。
計測結果にそれなりのブレが出てしまっているが、
混雑しやすい首都圏のフレッツ光回線としては早い方だと思われる。
 |
| 実際にはFirewall・ONU間にVLANを切ったスイッチが存在し、小型ONUは1個のみ稼働中。論理的に表現すると上記になる |
 |
 |
 |
| 下り：336.0Mbps |
下り：346.1Mbps |
下り：337.7Mbps |
上り：456.3Mbps |
下り：165.7Mbps |
上り：180.8Mbps |
 |
 |
 |
| 下り：262.3Mbps |
上り：154.7Mbps |
下り：123.5Mbps |
上り：133.4Mbps |
下り：179.1Mbps |
上り：115.7Mbps |
アップロードではあるが450Mbps出ている時もあったので、
小型ONU+メディアコンバータの構成自体は問題無さそうだった。
ルータに直収すると経由する物理装置が減るので理論上は効率化は出来そうだが、
使っているFirewallがNVR500な事もありギガビットをフルで処理するのは、そもそも厳しい気がする。
小型ONUを使える回線は今の所NTT東系統のみとなるが、
一般家庭用ルータでSFPポートを搭載するようになると事情が変わってくるかもしれない。
ただ、光電話つかっている人なら最初からホームゲートウェイで直収する事が大半なので、
一般家庭用ルータにSFPポートが今後追加される事はまず無いだろう。
逆に、逸般の誤家庭ならSFPポートを備えたネットワーク機器を所持している筈なので、
そっち方面での重要は大きいと思われる。
今回はBフレッツ終了に伴う無料工事枠を使いつつ、
小型ONUでフレッツ光への移行オーダーを通してみたのだが満足いく結果になった。
世間で小型ONUを知っている人はあまりいない模様だが、
ONUを無くせるメリットは相当大きいので是非とも今後普及して欲しい所。
………
筆者が経験してきた限り、業務用途でデータセンターにギガ回線を引き込む場合、
サーバルームのNWラック内に引き込むケースが殆どだった。
ところが、データセンターのNWラックには200vコンセントバーしか存在しないケースが多い為、
100v電源しか対応していないONUをそのまま設置する事が出来ない。
そうなると、降圧機を用いたり共用ONUラックみたいな所に設置する必要が出てきてしまう。
そのケースで大いに役立つのが、今回は家庭用として導入した小型ONUだと思う。
小型ONUで業務用ルータ・スイッチに直収出来るならば100v問題は発生しないのと、
外部電源が必要なONUの設置場所確保がいらないので、
利用者としては諸々の200v問題を考えなくて済むのが大きい。
利用出来る機器(ルータ・スイッチ)は限られてしまうと思うが、
NTTで『Auto/AutoでLinkUPするポートなら利用可能』の様に仕様のお墨付きを出せば、
ハードウェアベンダーもそれに沿って開発が出来る筈。
なのでNWを囓っている筆者からの要望としては、
『NTT東西さん是非業務用途で小型ONUを使える様に仕様を固めて下さい！』
の一言に尽きる。
« 続きを隠す
