エンジニア初心者がOCX-Router(v1)の仕様に関する検証をした話

この記事は BBSakura Networksアドベントカレンダー2025 の8日目の記事です

はじめに

こんにちは!営業の技術支援や個別案件のPMOなどをやっている青木です。BBIXではクラウドSE課というところにいます。

本記事では、エンジニア初心者である私が行ったOCX-Router(v1)の仕様に関する検証について、ここで得た知識や経験を紹介します。 この検証のおかげで、NWエンジニアのスタートラインにも立てていなかった自分が、スタートラインから一歩出るくらいのところまでいけたと思っています。 当時の私にとってはかなり難易度が高く感じましたが、エンジニアの経験値という意味でとても充実していました。

この検証は3ヶ月くらいやっていたので(もちろんずっとというわけではないですが)、いろいろなことを試していましたが、今回は掻い摘んで簡単にまとめています。

また、検証内容の詳細は記載していません。この検証で得られた知識や、新たな視点にフォーカスして書いていきます。

なお、本検証はベテランのNWエンジニアの方だったらおそらく2~3日で片付けられる検証内容だと思います。 「初心者がこの検証でエンジニアとしてのスタートを切ったんだー、へぇー」くらいの軽いノリで見ていただけると幸いです。

検証について

BFDとGraceful Restart

本検証で大きく関わってくるのが、BFDとGraceful Restartという2つのプロトコルです。それぞれのプロトコルはネットワークの可用性向上やネイバー関係の維持を目指すという意味では似ていますが、相反する効果を持ちます。検証でも大きく関わっていたので、以下で簡単に説明します。

※2025年12月8日の情報です。

BFD

データプレーンの通信経路に障害が発生していないかを、非常に高速 (ミリ秒単位)に検出するためのプロトコルです。 ルーター間でBFD専用のパケットを送り合い、それが途絶えることで「相手との通信経路に問題がある」と判断します。

OCX-Router(v1)ではRouter InterfaceのBGP Paramaterで設定でき、クラウド側も、本検証においては全ての場合でBFDが有効になっていました。

Graceful Restart(以降GR)

ルーターのコントロールプレーン(ルーティングプロセスのソフトウェアなど)が再起動する際に、通信の転送(フォワーディング)を止めずに処理を継続させるための仕組みです。 再起動中、隣接ルーターに「少し待ってほしい」と伝え、その間は既存の経路情報を使って通信を続けてもらいます。

GRが働く際は、役割によって、再起動するためにGRのオファーをするルーターと、再起動中ルートを保持して待つヘルパーモードのルーターに分けられますが、ヘルパーモードでしか働けない(helper mode onlyの)ルーターもあります。

OCX-Router(v1)はヘルパーモードでしか働けないルーターであることがCLI上やパケットキャプチャから確認できており、クラウド側ではGoogle CloudのCloud RouterのみGRのオファー機能が設定されていることが、Google Cloudの公式のドキュメントより確認できています。このGoogle Cloudの仕様が、本検証に大きく関わっていました。

このようにBFDとGRには、「即座に切り替える」か「ルートを保持して待つか」の点で、相反する効果を持っています。

検証の構成と経験

本検証の構成はこちらになります。

OCX-Router(v1)を自由に触れるような環境で用意する必要があったため、構成は商用環境と検証用環境を跨ぐようになっています。
本検証の構成図

本検証では、OCX-Router(v1)を自由に触れるような環境で用意する必要があったため、構成は商用環境と検証用環境を跨ぐようになっていました。この構成上、商用のVCIと検証用のRouter Connectionを繋げる必要があり、この際に通常ポータルでVC作成→アタッチでできる設定を手動で行う必要がありました。

この検証をするまでの私は、VC作成やアタッチの際に、システム・技術的に何が行われているのかは全く知りませんでした。

「ポータルでポチポチ操作したら何かしらの魔法がかかって繋がるんだ!」

本当にこのレベルの理解です。

そのため、まずは社内の技術に関する資料をひたすら読み込みました。 ここで、VC以外の他リソースも含め、システム上でどのような設定が投入されているかを初めて知ることになります。

その後は、実際に手を動かすフェーズです。

CLIでの設定投入の経験値が乏しかったこともあり、設定しても簡単にはPingが通らなかったり、VCの手動設定の部分で資料を読み込んでいても理解できていないところがあったり、一つ一つの工程で課題が出てくるような状況でした。

しかし、ルーティングテーブルやARPテーブルを見ながら切り分けを行い、トライ&エラーを繰り返しながらラボの機器に設定を投入しました。その結果、今まで理解できていなかったSWの設定や、ネットワークにおける存在意義など、挙げ始めたらキリがないほど多くの仕組みを学ぶことができました。

副産物

検証の構成や機器への設定の話に焦点を絞って書いてきましたが、これら以外にもこの検証で初めてやってことを超初歩的なことも含めて羅列していくと、ざっと以下のようになります。

  • ラボ環境の把握
  • 商用環境のCLI操作
  • 実機へのBGP設定
  • パケットチャプチャ          etc…

細かいところまで含めようとすると書き切れないですが、この全てがメインテーマになれるくらい貴重な経験でした。

(逆にこの検証をしていなかったらと思うと何も知らなさすぎて怖い...)

まとめ

初めてのブログなのでうまく書けていたかわかりませんが、少しでも伝わっていたら嬉しいです。

さまざまな経験を一度にできる初心者にはもってこいの検証でした。

自分から技術をやりたいと希望を出してやらせていただいているので、これからも頑張っていきます!