ユースケースで見る OCX リソース解説 「拠点間接続」編

はじめに

こんにちは! BBSakura で基盤となるネットワークを開発している酒井です。

このブログ記事では、 OCX の代表的なユースケースを通して、 OCX 内でお客さまに作成いただく各 OCX リソースについて解説します。

OCX の代表的なユースケースとしては、「拠点間接続」と「拠点からクラウドサービスへの接続」があります。「拠点間接続」ユースケースは、一般的な用語として Data Center Interconnect (DCI) と呼ばれることもあります。今回の記事では「拠点間接続」のユースケースを通して、 Physical Port (PP)Virtual Circuit Interface (VCI)Virtual Circuit (VC) の OCX リソースについて解説します。「拠点からクラウドサービスへの接続」ユースケースを通しての他 OCX リソースの解説記事も予定しておりますので、楽しみにお待ちください。

この記事の想定読者ですが、下記の技術について理解していることを前提としています。

  • L2 スイッチ
  • VLAN

また、この記事では下記の流れで解説を行ないます。

  1. OCX 概要
    • OCX が提供するネットワークについて簡単に説明します。
  2. Virtual Circuit (VC)
    • OCX でもっとも基本となるリソースである VC について説明します。
  3. ユースケース「拠点間接続」について
    • 「拠点間接続」のネットワーク構成について簡単に説明します。
    • 「拠点間接続」に必要な OCX リソースである Physical Port (PP) と Virtual Circuit Interface (VCI)について説明します。
  4. お客さま接続ルータの設定
    • OCX に接続するお客さまルータの設定について簡単に説明します。

1. OCX 概要

OCX は BBSakura が開発を行なっているネットワークのサービスです。 OCX ではマネジメントポータルをお客さまに直接操作いただくことで、簡単に OCX 拠点を結ぶプライベートネットワークを構築できます。 将来的には API による操作も提供予定です。これらの操作は後述する OCX リソースの作成・変更・削除にあたります。

なお、具体的な OCX の操作方法については OCX ドキュメントサイト にすべて記載されておりますので、適宜ご参照ください。

OCX を用いて構築できるプライベートネットワークは基本的には L2 のネットワークになります。似たような L2 ネットワークのサービスとしては、通信キャリアが提供している 広域イーサネット があります。 OCX では、一般的な 広域イーサネット のサービスに無い特徴としてオンデマンドに直接お客さまが操作可能であること、また、単純な L2 ネットワーク以外のよりリッチな機能を提供していることが挙げられます。 OCX で提供しているリッチな機能については、別の機会に説明いたします。今すぐ知りたいという方は、弊社にお気軽にお問い合わせください。

OCX は OCX 拠点間で L2 ネットワークをお客さまに提供します。そのため、お客さま視点では OCX は巨大な L2 スイッチと考えていただくことが可能です。

OCXを端的な概念として表した図。左から拠点X・OCX・拠点Yが、並んでおり、拠点Xと拠点Yの中はルータとルータ配下のネットワークが描かれている。OCXは大きなスイッチで表されている。拠点Xと拠点Yから間のOCXへ接続を表す線が延びている。
OCXイメージ図

この記事で解説する「拠点間接続」ユースケースは、単純な L2 ネットワークのみで構成できます。そのため、 OCX の理解を始めるには「拠点間接続」ユースケースはうってつけです。

2. Virtual Circuit (VC)

OCX で構築できるネットワークは L2 のネットワークだと話しました。この L2 のネットワークに一対一で対応する OCX リソースが VC になります。そのため、 VC は OCX でもっとも基本的なリソースだと言えます。

リソース VC について詳細に解説します。まず、この OCX ドキュメント では VC は下記のように説明されています。

Virtual Circuit(VC)は1つの大きなブロードキャストドメインとして振る舞い、VCIやCloud Connection、Router Connection、Internet Connectionなどのレイヤ2の論理回線を相互に接続することができます。

ブロードキャストドメインとは、ブロードキャストアドレス宛の L2 イーサネットフレームが届く範囲のことを指します。ブロードキャストアドレス宛の L2 イーサネットフレームとは、具体的には宛先 MAC アドレスが FF-FF-FF-FF-FF-FF のイーサネットフレームになります。イーサネットでブロードキャストアドレスを宛先として使用するプロトコルの 1 つに ARP があります。この ARP は通信先の IP アドレスから MAC アドレスを解決するプロトコルであり、 1 つの L2 ネットワークに接続したルータやホスト間でネクストホップへの通信のために実行されることはご存じかと思います。

通常の L2 スイッチだと、このブロードキャストドメインは VLAN に対応します。具体的には、 L2 スイッチではイーサネットフレーム内の VLAN ID タグによってブロードキャストドメインを識別します。 OCX が単純な L2 スイッチと異なる点として、OCX でブロードキャストドメインに対応するリソース VC 自体には固有の VLAN ID は紐づきません

では、どのようにして OCX では VC 、つまり、ブロードキャストドメインを識別しているのでしょうか。 VC には後述するその他の OCX リソースを アタッチ するという操作が可能です。この VC へとアタッチされたリソースは、その VC のブロードキャストドメインに参加したと OCX では判断します。そのため、同一 VC にアタッチされた OCX リソース間で発生する通信は、その VC に対応したブロードキャストドメイン内で発生した通信として OCX では取り扱われます。

リソースVCを説明するための図。OCX内に2つのVCがあり、それぞれ複数のOCXリソースと重複がないように繋がっている。それらのOCXリソースからVCへのアタッチの関係を矢印で表している。また、各VCに接続されたOCXリソースの1つからブロードキャストフレームがVCに向けて送信され、そのVCにアタッチされている他のOCXリソースにそのブロードキャストフレームが転送されている。
VC説明図

お客さまが OCX で L2 ネットワークを作成する時は、まずブロードキャストドメインにあたる VC を作成し、そのブロードキャストドメインに接続させたい OCX リソースを当該 VC にアタッチする、ということが OCX における基本的な操作となります。逆に、ある OCX リソースのブロードキャストドメインへの接続を解除したい場合は、当該 VC からその OCX リソースを デタッチ すれば OK です。

3. ユースケース「拠点間接続」について

「拠点間接続」とは

ユースケース「拠点間接続」では、複数の OCX 拠点にお客さまネットワークを接続し、その OCX 拠点間で L2 ネットワークを構成することで、地理的に離れたお客さまネットワークをセキュアかつ低遅延で接続します。

下の図のように、お客さまが接続した OCX 拠点の間であれば、 VC を用いて自由に L2 ネットワークを構成できます。

拠点間接続を説明する図。拠点X・Y・Zがあり、拠点内にはルータとお客さまネットワークが存在する。これらの拠点がOCXを通して線で結ばれており、それらの線はそれぞれL2ネットワークを表している。図では、拠点Xと拠点Z間の線・拠点Xと拠点Y間の・全ての拠点と接続された線があり、OCXを通して自由にL2接続できることを説明している。
拠点間接続のイメージ

OCX 拠点は順次展開中ですが、47 都道府県すべてに展開することを BBSakura としては 1 つの目標としています。お客さまの「拠点間接続」の選択肢が増えるように、今後も頑張って OCX 拠点の展開を進めます!

さて、「拠点間接続」のためにはお客さまに物理的にいずれかの OCX 拠点に接続していただく必要があります。先に述べたように OCX は巨大な L2 スイッチと考えることができます。そのため、お客さまのオペレーションミス等でお客さまネットワーク内に L2 ループを構成してしまい、接続しているブロードキャストドメインでブロードキャストストームを発生させないようにするためにも、一般にはルータなどの L3 ネットワーク機器で OCX 拠点に接続していただくことを推奨しております。その点を気にしなければ、もちろん L2 スイッチなどの L2 ネットワーク機器での OCX 拠点への接続も可能です。

この物理的な OCX 拠点への接続に必要な OCX リソースが以降で説明する Physical PortVirtual Circuit Interface になります。

Physical Port (PP), Virtual Circuit Interface (VCI)

PP は物理的な OCX 拠点への接続口となる OCX リソースです。具体的には、 PP は OCX 側ネットワーク機器の物理インタフェースと考えていただければと思います。お客さまが接続したい OCX 拠点を選択して PP リソースを作成することで、当該 PP に対応する LOA が OCX マネジメントポータル上で発行されます。この LOA を当該 OCX 拠点のデータセンター事業者に提出することで、 PP へのクロスコネクト(ラック間接続)がデータセンター事業者によって敷設されます。クロスコネクトについてイメージがつかない方は、データセンター事業者にお問い合わせください。

なお、この記事を執筆時点では PP としてサポートしているインタフェース規格は 1000BASE-LX10GBASE-LR になります。そのため、 OCX の PP と接続するにはお客さま側ネットワーク機器がどちらかの接続規格に対応している必要がありますのでご注意ください。

無事にクロスコネクトが敷設され、お客さま側ネットワーク機器と OCX の PP 間でリンクアップすると、 VCI の出番となります。 VCI は 1 つの PP に紐づく OCX リソースです1。 VCI には主に 2 つの役割があります。

VCI の 1 つ目の役割が、 PP に VLAN を設定することになります。 OCX では 1 つの PP、つまり、 1 つの物理接続で複数のブロードキャストドメインへ接続できます。 PP とお客さま側ネットワーク機器間で送受信されるフレームがどのブロードキャストドメインと紐づくのかを識別するためには、 PP とお客さま側ネットワーク機器間で共通の VLAN を設定する必要があります。リソース VCI の設定項目には VLAN ID があり、この設定した VLAN ID が当該 VCI が紐づいている PP に追加されます。前述したように PP は OCX 側ネットワーク機器のインタフェースにあたりますので、 VCI を通して、 OCX 側ネットワーク機器インタフェースに VLAN ID を設定するイメージをしていただければと思います。

VCI の 2 つ目の役割は、ブロードキャストドメインへの接続となります。 VCI は VC へアタッチ可能な OCX リソースです。 VCI を VC へとアタッチすることで、その VC に対応するブロードキャストドメインへ当該 VCI を接続します。

この VCI の 2 つの役割によって、お客さまネットワーク機器とブロードキャストドメイン間で通信可能な状態となります。

例として、 1 つの PP に 2 つのブロードキャストドメインを重畳している構成を図示します。

PPとVCIリソースを説明するための図。OCXを挟んで拠点1・2・3が存在しており、各拠点内にはルータがある。各拠点のルータからOCXへは線が延びており、OCX側では各拠点のPPでその線を終端している。OCX内では各PPにVCIが引っ付いており、VCIからは2つあるVCのどちらか片方に接続の線が延びている。VC Xには拠点1のVCI A(VLAN10)と拠点3のVCI D(VLAN10)が接続されている。もう片方のVC Yには拠点1のVCI B(VALN20)と拠点2のVCI C(VLAN30)が接続されている。
PPとVCIを使用した接続図

この図では、拠点 1 には PP が 1 つ存在し、その PP には VCI AVCI B が紐づいています。 VCI A には VLAN 10 、 VCI B には VLAN 20 が設定されています。また、 VCI AVC XVCI BVC Y にそれぞれアタッチされています。さらに VC XVC Y にはそれぞれ別拠点の PP に紐づいた VCI がアタッチされていることがわかります。これらにより、下記の 2 つの L2 ネットワークが構成されたことになります。

  • 拠点 1 と拠点 2 間
   [拠点1 お客さま接続ルータ]---(VLAN10)---[VCI A]---(VC Y)---[VCI C]---(VLAN 30)---[拠点2 お客さま接続ルータ]
  • 拠点 1 と拠点 3 間
   [拠点1 お客さま接続ルータ]---(VLAN20)---[VCI B]---(VC X)---[VCI D]---(VLAN 10)---[拠点3 お客さま接続ルータ] 

このように、複数の VCI を用いて、拠点 1 では 1 つの PP で 2 つのブロードキャストドメイン( L2 ネットワーク)への接続を重畳できました。ここで、 VC Y にアタッチされた拠点 A の VCI B と拠点 2 の VCI C では VLAN ID が異なっていることに気づかれた方もいるかと思います。 OCX では VC への OCX リソースのアタッチでブロードキャストドメインを識別すると先に説明しました。そのため、同一の VC にアタッチする VCI 間で VLAN ID を揃える必要はありません。これにより、同一の L2 ネットワーク(ブロードキャストドメイン)に接続していたとしても、お客さまネットワーク機器の接続 OCX 拠点(正確には接続 PP)ごとに異なる VLAN ID を自由に使い分けることが可能です。

4. お客さま接続ルータの設定

ここまでの説明で、「拠点間接続」には VC ・ PP ・ VCI が必要であることがわかったかと思います。また、 1 つの PP で複数のブロードキャストドメインに接続できることも説明しました。

最後にお客さま側ネットワーク機器の設定例を確認しておきましょう。と言っても、単純に接続ルータ間で通信を行なうだけであれば、当該ルータの OCX 接続インタフェースに VLAN を設定すればよいだけです。例として、先ほどの図に IP アドレスを追記した図を用意しました。

設定例のもととなる図。先ほどの「PPとVCIリソースを説明するための図。」にIPアドレスが追記されている。VC Xは192.168.10.0/24、VC Yには192.168.20.0/24が対応していることが書かれている。また、拠点1では「.1」・拠点2では「.2」・拠点3では「.3」とルータの横に追記されており、各ルータのIPアドレスの第4オクテットを表している。
設定例のためのネットワーク図

この図に記載の VLAN や IP アドレスに合わせて設定すると下記のようになります。なお、この設定例では各ルータとして Cisco IOS ルータを使用し、 GigabitEthernet1 で PP に接続しているものとします。

  • 拠点 1 接続ルータ
   interface GigabitEthernet1.10
    encapsulation dot1Q 10
    ip address 192.168.10.1 255.255.255.0
   !
   interface GigabitEthernet1.20
    encapsulation dot1Q 20
    ip address 192.168.20.1 255.255.255.0
   !
  • 拠点 2 接続ルータ
   interface GigabitEthernet1.30
    encapsulation dot1Q 30
    ip address 192.168.20.2 255.255.255.0
   !
  • 拠点 3 接続ルータ
   interface GigabitEthernet1.10
    encapsulation dot1Q 10
    ip address 192.168.10.3 255.255.255.0
   ! 

Cisco IOS ルータであれば、上記のように sub-interface を作成し、その sub-interface に VLAN ID と IP アドレスを設定すれば OK です。この設定によって、各拠点接続ルータと PP の間で VLAN タグ付きフレームのやり取りができるようになり、結果としてルータ間で Ping が通るようになるはずです。実際には、各拠点接続ルータの先にお客さまネットワークがあり、それらのお客さまネットワーク間で通信ができるようにルーティングの設定する必要があるかと思いますが、今回の記事では割愛します。

おわりに

今回の記事では、「拠点間接続」ユースケースを通して、 Physical Port (PP)Virtual Circuit Interface (VCI)Virtual Circuit (VC) の OCX リソースについて解説しました。今回の内容が理解できましたら、 OCX の基本的な使い方は理解できたと言って良いと思います。

次回はもう片方の主なユースケースである「拠点からクラウドサービスへの接続」を通して、その他の OCX リソースについても解説できればと考えています。

もし、今回の記事を通して OCX のご利用に興味を持たれましたら、ぜひ弊社までお問い合わせください!


  1. より正確には PP もしくは LAG Port に紐づく OCX リソースとなります。 OCX の LAG Port についてはまた別の機会に解説できればと思います。

インターンシップ体験記

はじめに

こんにちは!インターン生の鈴木飛鳥です。

2023年8月14日から4週間、ソフトバンク株式会社のインターンシップに参加させていただきました。配属先の部署では、ソフトバンクの関連会社であるBBIX株式会社とBBSakura Networks株式会社の業務を兼務していました。そのため、インターンシップ中にBBSakuraのプロダクトを使用したネットワーク設計開発を体験することができました。ネットワークに関する知識が乏しい中でのインターンシップとなりましたが、一から教えていただき、精一杯頑張りました。この記事ではその体験記について書かせていただきます。

インターンシップに関して

BBSakuraでは、OCXというBBIXのIXプラットフォーム上で提供するクラウド型ネットワークサービスを開発しています。このサービスでは、OCXマネージメントポータルの操作だけで独自の閉域網を構築し、ネットワーク開通作業を進めることができます。また、閉域網であるOCXのネットワークからインターネットへの接続を実現する「Internet Connection」というオプションサービスもあります。

一般に、企業が閉域網でクラウドサービスやデータセンターに、高セキュリティかつ低遅延で接続するためにOCXを使用します。今回のインターンシップでは、このOCXを用いて、オンプレミスからクラウドへの接続を一から作成してみました。また、構築のために、Webポータルでの設定だけでなく、実際にデータセンターへ行き、ルータの設置、配線なども行いました。

使用技術の概要

全体図

今回のインターンシップで作成したネットワークは、下の図のような企業のネットワークを想定して作成しました。以降でCPEルータ、OCX、Azureの概要を説明します。

今回のインターンシップで想定したネットワークの図。左から企業内ネットワーク、OCX、Azureが描かれている。企業内ネットワーク内にはCPEルータがあり、Azureクラウド上にはVirtual Machineがある。OCXを介して、CPEルータとVirtual Machineが線で結ばれている。

CPEルータ

CPEルータとは、オンプレミス側のネットワークとOCXを接続する際のゲートウェイとなるルータのことです。今回のインターンシップでは、CPEルータのハードウェアとしてR86SというミニPCを使用しました。下の写真がR86Sです。OCXへの接続には、自身の機器が1000BASE-LXあるいは10GBASE-LRの接続に対応している必要があります。今回使用したR86SにはSFP+ポートがあり、1000BASE-LXと10GBASE-LRのどちらにも対応していることから採用しました。

このR86SをCPEルータとして使用するために、VyOSという仮想ルータのOSをR86Sにインストールし、仮想ルータを構築しました。VyOSを選択した理由は、インターネット上にドキュメントや解説が多かったからです。

R86Sの写真。手のひらサイズのミニPCで、SFP+ポートが2つある。

OCX

CPEルータからAzureクラウドに接続を行うために使用しています。

今回使用したOCXのリソースは、Physical Port、Virtual Circuit Interface(VCI)、Virtual Circuit(VC)、Cloud Connectionの4つです。各リソースの説明を、公式ドキュメントより引用します。

<各リソースの説明>

  • Physical Port : OCXネットワークへの接続ポイント
  • Virtual Circuit Interface(VCI) : お客様機器とOCX機器の間で利用する仮想ネットワーク(VLAN)に相当する機能
  • Virtual Circuit(VC):一つの大きなブロードキャストドメインとして振る舞い、VCIやCloud Connection、Router Connection、Internet Connectionなどのレイヤ2の論理回線を相互に接続可能
  • Cloud Connection : 各クラウドサービスへ接続するための仮想的な接続インターフェース

(引用) “OCXドキュメントサイト”. Open Connectivity eXchange. https://docs.ocx-cloud.net/docs/intro (2023/09/05)

次に、各リソースがどのように動作するのかを説明します。

光ファイバーケーブルを用いて「Physical Port」にCPEルータを接続します。CPEルータから送信されるフレームは「Physical Port」を通り、フレームに付属するVLAN IDごとに「VCI」に振り分けられ、アタッチされている「VC」へと送られます。「VC」はブロードキャストドメインとして働くため、フレームは「VC」にアタッチされている他のリソースに転送されます。今回の場合、「Cloud Connection」がフレームを受け取り、クラウド側にフレームが転送されるという流れになります。

Microsoft Azure

Microsoft Azureとは、マイクロソフト社が提供するパブリッククラウドのプラットフォームです。以降、Microsoft AzureをAzureと称します。OCXでは、現時点でAWS、Azure、Google Cloud、さくらのクラウド、Oracle Cloudの5つのクラウドに対応しています。その中から今回はAzureを選択しました。Azure上にVirtual Machine(VM)を構築し、CPEルータとVM間で通信を行います。

インターンシップで取り組んだ内容

手順書の作成

はじめに、OCX接続の手順書と、CPEルータ構築のための手順書の作成を行いました。構築作業を行う前に、IPアドレスやOCX接続拠点、リソースの名前などあらかじめパラメータを設計し、それを基に手順書を作成しました。設定ミスを無くすために、何度も社員の方にレビューをいただき、漏れがないように注意しました。

構築作業

構築作業は大きく分けて、OCXポータルの設定・Azureポータルの設定・CPEルータの構築・データセンターでの配線の4つです。下の図は全体図にリソース等の詳細を書き込んだ図です。具体的な作業内容は以下の通りです。

今回のインターンシップで想定したネットワークの図にリソース等の詳細を書き込んだ図。上からAzure 、MSEE、OCX、企業内ネットワークが描かれている。Azure クラウド上にはVirtual Machineがあり、OCX内にはリソースがある。また、企業内にはCPEルータがあり、CPEルータにループバックインターフェースが付属している。CPEルータとMSEEを線で結びBGPのピアを表している。OCXの各リソースとMSEEを介してCPEルータとVirtual Machineが線で結ばれている。

OCXポータルの設定

* 主要な設定項目の詳細も記載しています。

  1. Physical Portの作成
    • 拠点:接続するOCXの拠点(データセンター)
  2. VCIの作成
    • VLAN ID:一つのPhysicalPort上でVCIを区別し、仮想のネットワークを作成するために使用
  3. Cloud Connectionの作成
    • サービスキー:後述するExpressRoute作成後にAzureポータルにて取得
    • VLAN ID:後述するAzureプライベートピアリングと同じVLAN IDに設定することで、OCXのネットワークとAzureのネットワークを紐付けるために使用
  4. VCの作成
  5. VCにVCIとCloud Connectionをアタッチ

詳細に関しては以下のOCXドキュメントを参照してください。

「OCXドキュメントサイト」 https://docs.ocx-cloud.net/docs/intro

Azureポータルの設定

  1. 仮想ネットワークの作成
  2. 仮想マシンの作成
  3. ExpressRouteの作成
  4. Azureプライベートピアリングの作成(前述したOCXポータルの設定の3番まで完了している必要があります) Azureプライベートピアリングを作成することで、CPEルータとAzureのネットワークとの接続ポイントとなるルータ(MSEE)間でBGPのピアを張れる状態になります
  5. 仮想ネットワークゲートウェイの作成
  6. 仮想ネットワークとExpressRouteの接続

ExpressRouteとは、Azureが提供する帯域保証型のネットワークサービスです。このExpressRouteを使用することで、オンプレミス環境とAzure間を閉域網で接続できます。 詳細に関しては以下のAzureドキュメントを参照してください。

「ExpressRouteのドキュメント」 https://learn.microsoft.com/ja-jp/azure/expressroute/

「Virtual Networkのドキュメント」 https://learn.microsoft.com/ja-jp/azure/virtual-network/

CPEルータの構築

  1. VyOSのインストール
  2. 使用するインターフェースのIPアドレスの設定
  3. ExpressRouteとのBGPの設定
  4. SSHログインのための設定

データセンターでの配線

CPEルータからOCXの機器(Physical Port)に光ファイバーケーブルを用いて配線を行いました。商用の機器であるため誤って他の配線を抜いたり、機器にぶつかったりしないよう細心の注意を払って取り組みました。内心とてもどきどきしていました。

接続確認

今回はオンプレミス側のネットワークを再現するために、CPEルータのループバックインタフェースに対してIPアドレスを設定しました。このIPアドレスからVMに対してpingコマンドを実行することで、オンプレミスからクラウドへの接続ができていることを確認しました。また、AzureのVM側でもpingのパケットの受信確認を行いました。pingコマンドの実行結果は以下のようになりました。

  • パケット送信側(CPEルータ)からpingした結果
vyos@vyos:\~$ ping 192.168.100.4 source-address 192.168.200.1
PING 192.168.100.4 (192.168.100.4) from 192.168.200.1 : 56(84) bytes of data.
64 bytes from 192.168.100.4: icmp_seq=1 ttl=63 time=2.60 ms
64 bytes from 192.168.100.4: icmp_seq=2 ttl=63 time=2.74 ms
64 bytes from 192.168.100.4: icmp_seq=3 ttl=63 time=2.38 ms
  • パケット受信側(Azure上のVM)の受信確認結果
asukasuzuki@Internship-VM:\~$ sudo tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
08:49:34.837063 IP 192.168.200.1 > 192.168.100.4: ICMP echo request, id 44428, seq 1, length 64
08:49:34.837100 IP 192.168.100.4 > 192.168.200.1: ICMP echo reply, id 44428, seq 1, length 64
08:49:35.838706 IP 192.168.200.1 > 192.168.100.4: ICMP echo request, id 44428, seq 2, length 64
08:49:35.838751 IP 192.168.100.4 > 192.168.200.1: ICMP echo reply, id 44428, seq 2, length 64
08:49:36.840273 IP 192.168.200.1 > 192.168.100.4: ICMP echo request, id 44428, seq 3, length 64
08:49:36.840328 IP 192.168.100.4 > 192.168.200.1: ICMP echo reply, id 44428, seq 3, length 64

上記の結果より、pingが正常に実行できていることが確認できます。よって、オンプレミスからAzure上のVMまでの疎通が確認できました。

感想

ネットワークに関する知識が乏しく、オンプレミスとクラウドの違いさえも分からない状態の私でしたが、一から熱心に指導していただき、OCXを使用してオンプレミスとクラウド間を閉域で接続することができました。試行錯誤の結果pingが通った時には感動すらしました。この4週間で、ネットワークに関する知識や技術だけでなく、文章や図の書き方、データセンターでの作業の進め方や気をつけることなども学ばせていただきました。その他にも、社会人として働く上で改善した方がいいこと、心構えなど、本当に多くのことを学ばせていただきました。インターンシップ参加前と比べて確実に成長することができたと感じます。このインターンシップで得た知識や経験、感じた達成感や喜びは、私のこれからのキャリアにおいて大きな糧となると思います。

今後もこの経験を生かして、学生として勉学や研究に励み、さらに成長を続けて行きたいと思います。指導してくださった酒井さん、芦田さん、佐藤さん、山崎さん、4週間大変貴重な経験をさせていただき、本当にありがとうございました。

新卒がCCNAを取得した話

こんにちは、BBSakura Networksの接続推進課に所属しているキムです。

今回は新卒の私がCCNA取得に向けてネットワークの勉強をしたときの話をしようと思います。
私自身、大学・大学院とも情報系であり、ネットワークの授業を取ったことはあるものの、ほぼ忘れかけているくらいのベースで準備を始めました。 (ちなみに、学生時代の時はネットワークはまったく得意ではなく、ネットワークエンジニアになるとは思ったことなかったです)

CCNAとは?

CCNA(Cisco Certified Network Associate)は、Ciscoが主催する資格試験です。(https://www.cisco.com/c/ja_jp/training-events/training-certifications/certifications/associate/ccna.html)
レベルとしてはCCNA(アソシエイト) < CCNP(プロフェッショナル) < CCIE(エキスパート)となっていて、ネットワークエンジニアになるための基礎的な資格という位置付けになっています。試験時間は120分で、ネットワーク基礎からネットワーク自動化まで幅広い範囲から出題されます。

CCNAの出題範囲。"Network Fundamentals 20%, Network Access 20%, IP Connectivity 25%, IP Services 10%, Security FUndamentals 15%, Automation and Programmability"と記載されている。
CCNA出題範囲

問題形式には一択選択問題、多肢選択問題、Drag&Drop問題、シミュレーション問題があります。シミュレーション問題では直接コマンドを打つ必要があるのでコマンドを覚える必要があります。
受験料は2023年8月時点で税込42,900円でした。(去年までは36,960円だったらしいですがまた値上がりしていました、、)
認定期間は取得から3年間となり、資格を維持するためには再試験または高いレベルの資格を取得する必要があります。

CCNAの勉強方法

  • 講義
    会社の研修で受けることができました。CCNAの出題範囲の全体的なイメージを掴むことができてとても役に立ちました。

  • 問題集&過去問サイト
    会社の先輩から問題集をいただきました!(ありがとうございます!)
    勉強した内容の概念の復習から新しい概念を学ぶこともできて、問題集のおかげでだいぶ理解を深めることができました。
    ただ問題集だけでは不安だったため、過去問サイトも利用しました。一日200問ずつ解いて、自分の得意・不得意な問題を確認しました。特に私は書きながら勉強することが好きなタイプなので、不正解だった問題の概念をまとめたりしていました。

    勉強に使ったノート。用語やコマンドについてメモしてある。同じく勉強ノート
    CCNAノート

苦労したところ

  • 出題範囲が広い
    ネットワークの基礎的な知識が出題されるとはいえ、出題範囲が広いため勉強し続けても新しい用語が出てきて苦労しました。特に私は決まった日までにCCNAを取得したいという目標があったため、試験日が近づいてもわからない内容が出てきて不安になったりしていました。
    ただ、勉強し続ければ、どんどん「前見たことある!」が増えてくるので、諦めず勉強し続けるときっと大丈夫だと思います!

  • コマンドを覚えるのが難しい
    ネットワークのコマンドとしてはipconfigくらいしか分かっていなかったので、いきなり多くのコマンドを覚えることが大変でした。特にshow系に似たようなコマンドが多く、このコマンドを入力すればどういう情報が出力されるのかについてがなかなか覚えられなかったです。私の場合何度もコマンドを打つ練習をすることで覚えるようになったので、私みたいに短期間でいろんなコマンドを覚えるためには、とりあえず何回も繰り返して試してみることが重要だと思います。

  • 受験料が高い
    受験料が高いため、落ちたらどうしようというプレッシャーが結構ありました。ただ、そのプレッシャーのおかげで集中して勉強できる面もあったとは思います!

CCNAの準備するあたりで感じたこと

  • 一回で完璧に理解しなくても大丈夫
    勉強する途中で、私の理解能力が低いせいか一度説明を読んだだけでは理解できない部分が多々ありました。最初は頑張ってその説明を完璧に理解してから次に進もうとしていましたが、勉強を続けるにつれて理解できなかった概念は必ずまた出てくるので、出た時に少しずつ理解を深めれば良いという結論に至りました。実際にそうした方が同じ内容をいろんな角度の説明で理解するようになり、効果的に学習することができたと思います!

  • 学んだことあるからこその誤解
    ネットワークを勉強したことがあるという背景はもちろんCCNA取得するためのアドバンテージになりますが、勉強したことあるからこそ注意しなければいけない点もあります。
    私の場合、今まで「分かってるつもり」の知識が却って邪魔になることもありました。例えば、デフォルトゲートウェイとデフォルトルートが一緒だと思っていたので、デフォルトゲートウェイとデフォルトルートの両方が選択肢に出ると両方正解なんじゃないの?ってなって迷ってました。私みたいに概念が曖昧になっていなければ大丈夫だと思いますが、少し不安な方は「分かっているつもり」の概念を見返してもらうと大変勉強になると思います!

  • 略語は英語の意味まで把握しておこう
    ネットワークに限った話ではありませんが、ネットワークを勉強する時にはいろんな英語の略語が出てきます。単に略語自体を覚えるのではなく、英語での意味を理解しておいた方が記憶が長く続きました。(逆に知らない略語が出てきてもどういう単語からきている略語なのかを推測することにも役立つかと思います)

CCNAに挑戦してよかった点

  • 会社のミーティングの話の理解度が格段に上がった!
    CCNAの準備する前には、社内のミーティングで出てくる用語が理解できず、会話の流れを把握することがなかなか難しかったです。
    CCNAの準備をし始めてからは、前より用語が何を理解するのかが分かってきて、(まだまだわからないことはいっぱいですが)だいぶ会話の流れを理解できるようになりました。この点がCCNAに挑戦して一番よかったと感じている部分です。

  • 他の資格にも挑戦する気になった
    CCNA取得前には、資格取得を目標にするつもりはありませんでしたが、CCNAに合格したことをきっかけに他の資格にも興味を持つようになりました。 CCNA取得をスタートに、次はクラウドの資格を取りたいのでAWS Cloud Practitionerに挑戦したいと思っています!

まとめ

CCNAは、ネットワークの幅広い範囲の基礎的な知識を取得するためにおすすめな資格なので、ネットワーク業界で働くことになる新卒の方は是非チャレンジしてみてください!
私もまだまだ初心者であり、一例に過ぎない記事になりますが、少しでも役に立てればと思います。 読んでいただきありがとうございました!

OCXを支える技術 番外編 BBSakuraのCEOがOCX(Open Connectivity eXchange)にかける想い

ご覧いただきありがとうございます。BBSakura Networks CEOの佐々木(@sbsasa)です。

OCX(Open Connectivity eXchange)とは?

OCXはBBSakura Networksが開発したネットワーククラウドのサービスです。

WebのポータルやAPIを通じてオンデマンドにネットワークを作るのに必要なリソースを組み合わせて利用することが可能です。

OCXのイメージ。OCXにDC拠点、インターネット、クラウドサービスなどが接続されている。
OCXのイメージ

OCXの開発を始めたきっかけ

当社の親会社のBBIXでは、2013年、大手携帯事業者、ISP、データセンター/クラウド事業者、コンテンツ事業者の皆様と、クラウドコンピューティングやスマートフォンが中心となる時代に向けた理想的なトラフィックの流通を目的とし、Cloud IX研究会 を立ち上げておりました。

このCloud IX研究会の中で討議されていたアイテムの一つが、BBIXのIX Fabric上で、Cloudやソーシャルゲームプラットフォーマー等の間をオーバーレイのSDN(Software-Defined Network)でオンデマンドに結ぶサービスでした。以下は2013年当時に議論の内容をBBIX社内で説明した際の資料ですが、実はOCXの今のアーキテクチャに非常に似通っております。(笑)

ネットワーク概念を説明するスライド。BBIXのL2IXの上にCloud IX(SDN)が載っていて「論理的に別面で提供」と説明されている。

研究会での議論や実験結果をもとに、BBIX社内で2013年から継続して、事業化の検討を行っていたのですが、「通信事業者」を母体とするBBIXではプラットフォームのソフトウェア開発力が足りず、時間だけが経過した状況でした。そんな中、2019年にBBSakura Networksを設立し、さくらインターネットからのメンバーを受け入れた混合チームができたことで、急速に開発プロジェクトが進むことになります。

通信ネットワークの今後

従来通信ネットワークは人間が人間とコミュニケーションを取るために使われるインフラでしたが、約10年ほど前から、人がデータにアクセスするトラフィック量(North-South Traffic)より、サーバー/データセンター間の通信(East-West Traffic)の方が多くなってきたと言われております。 つまり、これからの通信インフラというのは、人間が使うという観点より、コンピューター・ソフトウェアにとって使いやすいインフラであるべきだと考えております。そこでAPIで制御可能なSoftware-Defined Networkの仮想ネットワークの構築を始めました。

これからデジタルツインと言われる時代を迎え入れるにあたり、現実空間の様々なデータを仮想空間(クラウド)へリアルタイムにアップロードをし、そのシミュレーション結果を現実空間へフィードバックする環境が求められるはずです。そういったデータの流通を実現するための基盤となるネットワークインフラにしていきたいと考えております。

現実空間と仮想空間が、情報収集とフィードバックのループを回している図

OCXで目指す世界

とはいえ、AIやソフトウェアを顧客としたビジネスを始める時代にはまだ少し早いと思っており、まずは「人」が簡単にポータルからオンデマンドに、クラウド、データセンター、アクセスラインや仮想アプライアンスを柔軟に組み合わせてas a ServiceとしてNetworkを構築できるサービスを目指して以下の3つのコンセプトを意識してサービス開発を始めました。

  • 全国カバーのネットワーク
  • 地域を主人公にしたビジネスモデル
  • 「モノ」が中心となった世界におけるNaaS*1のあり方

全国をカバーするネットワーク

OCXはどこでも、誰でも、どんなものでも接続できるプラットフォームを目指しており、「全国網」としてのプラットフォームを構築することを前提にサービスを開始しております。

全国に設置するアクセスポイントにおいて、全地域同一の価格・品質のサービスを提供し、地域間格差のない、クラウドネイティブな通信環境の実現を目指しております。

日本地図上の複数箇所にピンが立っている図

参考: OCX提供拠点一覧

地域発のDX推進

全国をカバーするネットワークを整備するにあたり、自社だけでの展開には限界があります。そこで考えたのが協業によるアクセスポイントの整備です。OCXのOpenという言葉には、全国の様々なエリア・規模・資本の事業者様と協業することで、一つの大きな接続基盤と作り上げたいという思いを込めております。

地域固有の課題を発見し、それをDXにより解決をかけていくため、様々な地域・業種の事業者様と協業し、拠点を開設しております。

政府の掲げる、デジタル田園都市国家構想 を実現するには東京や大阪で享受できる環境と同等のインフラを地域に整備する必要があると考えております。また、そのインフラは税金や補助金などに頼らなくても持続できるものでなければなりません。 OCXでは様々な事業者様の協力のもと、民間の力を結集することで、このインフラ整備を実現し、各地域に東京・大阪同等のインフラを整備することで、地方からのイノベーションを促進し、地方にいるソフトウェア、ネットワークエンジニアの力を借りて、日本のデジタルの力を底上げしていきたいと考えてます!

日本地図上の複数箇所にOCXの拠点が示され、その周りでソフトウェアエンジニアとネットワークエンジニアが働いている絵

コンピューターとネットワークの融合

全国に面としてのネットワークを整備できたら、コンピューターとネットワークサービスのより緊密な融合を図っていきたいと考えております。昔Sun Microsystemsが"The Network is the Computer"という提唱を行なっておりましたが、まさにこの世界を実現していきたいと考えております。 ソフトウェア、コンピューターのためのネットワークの始まりです。 様々なサービスをネットワークと融合されたコンピューターリソースで処理できるよう、これらに必要なソフトウェアの開発も行なっていきます。

様々なデバイス、モノが全てネットワークに接続されるとき、それらのデバイスがニューロンとなり、まるで一つの大きな脳のようになり、自律分散的に自己判断・推論できるようなそんな世界が作れるのではないでしょうか?OCXが完成する時、デジタルツインの実現ができていると信じております。

地球の上空に人間の脳が浮かび、その中にPC、車、信号などが示されているイメージ図

最後に

最後までお読み頂き、ありがとうございました。

連載記事はこの記事についているタグ OCXを支える技術 からお読みいただけます。

我々はまだ入り口でもがいている状況ですが、この基盤を完成させ、また世界へ展開していきたいと考えております。

一緒にサービス・ソフトウェアを作っていくことにご興味いただける方がいらっしゃいましたら、お問い合わせフォームなどから是非ご連絡くださいませ。

*1:NaaSはみずほリサーチ&テクノロジーズ株式会社の商標で、当社は商標の使用許可を得ております。

OCXを支える技術 #2 OCXのネットワークを制御するソフトウェアの仕組み

記事をご覧頂きありがとうございます!BBSakuraにてOCXの開発をリードしている川畑です。

OCXを支える技術の連載2記事目です。

連載記事一覧は、この記事についているタグ #OCXを支える技術 からご覧いただけます。

制御システム・ソフトウェアの構成

制御システムの構成図。フロントエンド、バックエンド、ネットワークの箱が示されており、バックエンドの中にAPI、DB、Workerが描かれており、APIからDBへは「パラメータ投入指示」、WorkerとDBのあいだには「投入指示取」、「投入結果記録」と書かれている。

前回の記事では代表的なOCXのネットワーク接続の機能について紹介しましたが、ここではそのネットワークを制御する心臓部にあたる部分についてお話します。 システムは大きく フロントエンド/認証バックエンド の2つに分けられます。前者はポータルのログイン機能やリソースの購入・設定などのUIを具備したもの、後者はお客様構成情報を管理し、課金を行ったり商用網のネットワーク機器を入力通り間違いなく制御するためのプログラムです。

図をご覧ください。クライアント(お客様のブラウザ)から操作され、ネットワーク機器に設定が投入される一連のフローが記されています。 これを見ると、特にバックエンドについては2つの制御機構があることが分かります。内部の呼称としてそれぞれ APIWorker と呼んでいます。 APIが担っている主な機能は、以下の通りです。

  • システム全体のマスターデータ(物理ポートやVLANなどの在庫となる情報)の管理
  • お客様からのリソース購入・変更・削除の要求を受け付け、適切に精査し、内容に異常が無ければ必要に応じてネットワークへの設定指示情報を生成すること
  • 購入した履歴を管理し、課金データを作りお客様に請求を行うこと

Workerが担っている主な機能は、以下の通りです。

  • データベースに登録された設定指示情報に基づき、担当するネットワーク機器へのconfigを適切に行うこと
  • 同様に、お客様のリソースの開通・閉塞時のデータベース上の状態遷移を取り扱い、適切に情報を更新すること

ネットワーク機器のconfigにはある一定の時間がかかることや、クラウド化されたサービスにおいてリクエスト受付時のリアルタイム性や待ち行列問題を考えたときに、 APIではリクエストを受理・精査した上で「作成や変更・削除要求を問題なく受け付けた」旨のレスポンスは即座に返し、非同期に設定を行うアーキテクチャを考案しました。 マイクロサービス的な構成で行こうという考えも私個人の開発者思想としてありましたが、「同期的にやった場合の平均待ち時間のストレス度合い」についての議論した結果がそれを後押しし、結果的にAPI/Workerで役割を完全に棲み分けた形になりました。

苦労するポイント

システムにおける処理の責任範囲が書かれており、サービスに近いシステムほど責任が増える

同期・非同期に関わらず、受け取るパラメータはお客様による入力値です。最終的にパラメータを受け取るのはサービス網に接続されているサーバやネットワーク機器、はたまたクラウド事業者のAPIであり、受け入れられるパラメータには制限があります。 つまり、お客様の入力値が最終的に投入する機器・APIにおいて受け入れられる値かどうか精査する必要があります。精査には2種類あり、1つ目はパラメータが受け入れられる範囲を超えていないかをチェックすること。2つ目は、既に設定済みの値や同じ値やその範囲に含まれるパラメータを2個以上持つことができない場合のチェックです。開発においては意図的に前者をバリデーション、後者をコンシステンシー(整合性)チェックと呼んでいます。

これら2つの分かりやすい例を紹介します

  • バリデーション
    • 入力されたIPアドレスが 192.168.0.256 の場合(IPアドレスとしてフォーマットが異常値)
    • 入力された帯域の値が 0Gbps の場合(設定できる帯域値として0は許可していない)
    • 入力が必須項目なのに、入力されていない場合(パラメータが無いと機器の設定が受け付けられない)
    • オプションの入力項目について、入力が中途半端な場合(オプションは全て入力するか、しないかの2択の場合がある)
  • コンシステンシーチェック
    • 既に 192.168.0.1/24 のIPアドレスが設定されているルータに、新たに別のインタフェースに 192.168.0.10/24 を設定した場合にはエラーを返す(同じセグメントに属するIPアドレスを、複数のインタフェースに設定できない)
    • ルータのインタフェースに 192.168.0.0/24 のIPアドレスを設定した場合にはエラーを返す(IPアドレスとしてのフォーマットは正しいが、ネットワークアドレスはインタフェースに設定できない)

OCXではお客様の入力値をポータル画面を介して受け付けているため、まずはここで入力値のバリデーションを行います。事前にUIチームに「この範囲から外れた値は異常値なので受け付けないで欲しい」という値を共有し、入力画面での異常値を受け付けないように開発してもらいます。 しかし開発途中で受け入れる値が変わることもあり、共有が漏れると異常値がそのままAPIへ渡ることがあります。

加えて、パラメータの中には「組み合わせ」でバリデーションを行うものもあり、単体で見ると正常値なのに組み合わせると異常値であるという場合もあり、バリデーションも一筋縄ではいきません。 更にコンシステンシーチェックまでやるとコード量が膨大になるため、入力画面はプレチェックとして捉え、本格的なチェックはAPIが担当しています。

APIやWorkerのバリデーション・整合性チェックの図が書かれている

さて、ここにきて非同期アーキテクチャを採用した最大の難関が待ち受けます。 フロントのバリデーションをすり抜けた値はAPI側で95%程度は救うことができるのですが、稀に5%くらいは考慮漏れ等によって機器まで到達してしまうことがあります(これをエッジケースと呼んでいます) こうなった場合が凶悪で、「機器に入らなかった設定値が、設定されたことになっている」という現象が発生します。設定されたことになっているというのは、ポータル画面で異常な入力値が確定値として表示されてしまっている状態です。 これが「APIは正常に処理をして設定指示情報を生成し、ユーザにも成功の値を返したが、Workerからネットワーク機器に設定を投入するときに失敗した・ネットワーク機器が受け付けなかった」という非同期処理特有の難しさです。

つまり、バリデーション及びコンシステンシーチェックは、投入するネットワーク機器と同じ機構・要領で値を精査しなければならないということを意味します。 普段何気なくネットワーク機器をコンソールで操作しているとき、間違った値を入れると即座ににエラーが返ってきますが、あれが本当にありがたいものだと痛感します。 同期的にやればネットワーク機器のエラーをそのままパラメータ投入結果のエラーとして返せばいいものの、応答の快適性を重視した結果、この問題が常に付きまとうことになりました。 実際、OCX-Router(v1)開発におけるコード量のうち半分以上はバリデーション及びコンシステンシーチェックに費やしました。

おわりに

このように、サービスの開発においてはシステムでの涙ぐましい工夫やサービスの提供仕様・運用・様々な観点でデメリットを許容できる範囲まで落としてチーム一丸で開発を進めています。

そんな工夫を支えるソフトウェア技術としては、フロントエンドはNext.js、バックエンドはGolangを採用しており、モダンなウェブアプリケーションに仕上がっています。 それぞれの技術の詳細については連載にて開発者が赤裸々にお話しますので、楽しみにお待ち下さい。

OCXを支える技術 #1 OCXの概要と構成要素

記事をご覧頂きありがとうございます!BBSakuraにてOCXの開発をリードしている川畑です。

概略

BBSakuraでは、BBIXがサービス提供を行っているOpen Connectivity eXchange(以下、OCX)のソフトウェア開発を行っています。

IaaSの台頭によってサーバがクラウド化され仮想マシンとしてオンデマンドに(必要な時に必要な分だけ)利用できるようになったように、OCXでは NaaS(Network as a Service) *1としてデータセンター間接続、ルーティング、クラウド事業者との接続などネットワークの様々な機能をクラウド化し、UIを具備したプラットフォームサービスとして提供しています。

2023年8月現在、OCXではデータセンター間接続をはじめ、国外・国内クラウド事業者との接続や、ルーティング機能、インターネット接続機能が利用できます。インターネット接続機能を除いた全ての通信はOCXの網内で行われ、インターネットを通さないことから第三者による通信の窃取やDDoS攻撃を防ぎ、安心・安全なネットワークを提供しています。

OCXの拠点となるデータセンターは首都圏のみならず、その特異なビジネスモデルから日本全国へ展開を進めています。将来的には47都道府県全てに展開し、皆様のありとあらゆる通信を支え、誰一人デジタルに取り残されない社会基盤の一つになることを、本気で目指しています。

本記事では、OCXを構成するネットワーク及びその機能についてかいつまんでご紹介します。また、この全体のアーキテクチャ紹介を皮切りに、実務を担当しているエンジニアメンバーが寄稿し、次のメニューで連載します。

この記事についているタグ #OCXを支える技術 から連載記事一覧をご覧いただけます。

  • ネットワークを制御するソフトウェア
  • フロントエンドおよび認証・認可周り
  • バックエンドシステム
  • ネットワーク
    • クラウド事業者との接続
    • コアのネットワーク
  • CEOによる「OCXにかける想い 」
  • その他、状況によって増えます!

OCX構成概要

"OCX構成概要図。中央にBBIXバックボーンがあり、その周りに展開拠点A~C、Router、Cloud NNIが接続されている。"

OCXのネットワークは、BBIXのバックボーンを軸に展開し、オーバーレイ方式の通信アーキテクチャを採用しています。

バックボーンはアンダーレイに徹し、青箱で示した 拠点ネットワークの機能 はお客様の通信を直接捌く と捉えることで、互いの責任分界点を明確にしています。面を単一の構成にでき、容易にスケールできる設計です。

また、ネットワーク特有の機能として、お客様の通信識別にVC(Virtual Circuit)と呼ばれるものを提供しています。 VCはOCX網内で単一のブロードキャストドメインとして機能し、拠点でお客様を収容しているVLANやクラウド接続、ルーティングリソースなどをレイヤ2で接続することができます。 Point-to-Pointはもちろんのこと、Point-to-MultiPoint構成も可能にしており、お客様のネットワーク構成にあわせて柔軟に接続できます。

これらのネットワークはソフトウェアをベースに制御されており、総合するとOCXはいわゆるSDN(Software Defined Network)に該当します。 OCXのお客様には各種接続やリソースの購入・変更・削除を行う機能を具備した専用のポータル画面を提供しており、そこからのリクエストを バックエンドのAPIが受け取り・処理をして、更に機器を制御する機構へ設定情報を渡すフローになっています。

データセンター間接続

データセンター間接続の図。BBIXバックボーン内のVirtual Circuitを介して展開拠点A~C内のCPE同士が線で結ばれている。

OCXで提供している基本機能の一つが、データセンター間のレイヤ2接続です。

お客様にはOCX拠点スイッチの物理ポートを Physical Port として、VLANに相当する論理回線を VCI(Virtual Circuit Interface) としてリソースを提供しています。 既にお客様がOCX展開拠点と同じデータセンター・ビル内に居る場合、安価で高速な拠点間接続としてご利用頂くことを想定しています。 購入したVCI(VLAN ID1つに相当する)を先述のVCに紐付けることで、各拠点をまるでひとつのレイヤ2スイッチに接続している感覚で通信することが可能になります。

クラウド接続

クラウド接続の図。BBIXバックボーン内のVirtual Circuitを介して展開拠点A内のCPEとさくらのクラウドが線で結ばれている。Virtual Circuitからさくらのクラウドまでの線はCloud NNI内のOCXNNI SWを経由する。

もう一つの基本機能として、各種パブリッククラウド事業者とのレイヤ2接続が可能です。 2023年8月現在の対応クラウド及びサービスは、下記の通りです。

クラウド事業者 サービス
さくらのクラウド プライベートリンク
Amazon Web Service Direct Connect
Microsoft Azure ExpressRoute
Google Cloud Partner Interconnect
Oracle Cloud Infrastructure FastConnect

これらはOCX(BBIX)がクラウド事業者の認定パートナーとなっており、ポータル画面からクラウド接続を申し込むと、我々パートナー事業者を通してお客様の クラウドアカウントに閉域接続設定を直接デプロイすることで、OCXネットワークとの間に専用のレイヤ2のパスが用意されます。 このレイヤ2リンクをOCX内でお客様専用とし、VCに接続することで拠点からクラウド事業者(のBGPルータ)まで閉域で接続できるようになります。

ルーティング機能

ルーティング機能の図。展開拠点A内のCPEからVirtual Circuitを介してOCX Routerにつながる線と、同じOCX Routerから別のVirtual Circuitを介してさくらのクラウドにつながる線が表現されている。

直接的なネットワークの機能として、ルーティングの機能も提供しています。 各所を直接レイヤ2で接続する機能の他に、自身でルータを持たなくてもOCXネットワーク内を自由にルーティングすることが可能になります。

クラウド事業者との接続(Direct Connect等)は全てBGPを使用して接続しなければならず、お客様の中にはご自身でBGPルータの運用やオペレーションを行いたくないという方もおられます。拠点とクラウド間のBGP接続をこの OCX-Router(v1) に任せることも可能ですし、異なるパブリッククラウド間をこのルータを介して接続することも可能です。 機能としてはStatic/BGPのルーティングに対応している上に、標準で1ペア2インスタンス・拠点冗長で提供しています。保持できる経路数も10,000経路と、通常利用ではほぼ困らない性能です。

論理的な見え方を説明する図。CPE、Virtual Circuit、ルータ、Virtual Circuit、さくらのクラウドが直列につながっている。

VCを2つ用意し、拠点とルータ、ルータとクラウドを接続すると、論理的にはこのようなネットワークとして構成することが可能です。

上記、論理的な見え方の図の中のルータからクラウドの区間について「BGP終端(=CPEの負担を減らす)」と記載されている

メインの使い所は、BGPに対応している点からクラウド接続でのBGP接続の終端にお役立て頂くことを想定して開発しました。

おわりに

本記事では、OCXのサービス概要・構成要素と今後の連載記事の概要について記載しました。 これらの機能を利用したネットワークを制御する仕組みについて、次の記事でお話しします。

*1:NaaSはみずほリサーチ&テクノロジーズ株式会社の商標で、当社は商標の使用許可を得ております。

JANOG52 Hackathon に参加して Winner Team になった話

概要

こんにちは、BBSakura Networks のシステム管理部に所属している蟹江( @kanix2929 )です。
普段は BBIX から委託されているシステムなどの開発・運用をメインに業務しています。

2023/07/05 ~ 2023/07/07 で長崎にて開催されていた JANOG52 に参加してきました(JANOG 参加自体がはじめて!)。
そのプログラムの 1 つである ハッカソン(Hackathon) に参加してきたので、それについての感想を述べていきます。
( BBIX の一員として JANOG に参加してきましたが、BBSakura にも出向しているので BBSakura のブログに投稿しています )

JANOG Hackathonとは

JANOG Hackathon については、公式ページがあるのでそちらを参考にしていただければと思います。
要は、日々の悩みや課題をそれぞれ持ち寄って、1 日開発の時間に充ててみようぜ!というイベントです。

これまで参加したことのあるハッカソンでは「共通のテーマが与えられてチームで競う」というタイプだったので、それぞれがテーマを持ち寄って別の課題に対して解決方法を提示する、という形式は新鮮でした。
(僕のなかでは「ハッカソン=競争」みたいなイメージでしたが、「ハッカソン」自体の言葉の意味は「短期集中開発」なんですね)

ハッカソンに参加するまで

僕がハッカソンに参加した理由は以下です。

  • せっかく現地参加するなら他社の人と密に会話してみたい!
  • 公式ページから JANOG 初心者でも Welcome な雰囲気を感じる!
  • 「うちの会社のエンジニアももっとコミュニティ活動していこうよ」という社内の風潮
  • JANOG のプログラム委員をしている人から声掛け

特に、新卒で今の会社に入社してからのこの 2 年間は、コロナの影響でオフラインイベント自体が少なかった & 業務で社外の人と関わる機会がほとんどなかった、ということが参加する一番の動機だったかなと思っています。

〜 社内での仲間集め 〜

いざハッカソンに参加すると決めたものの

  • 1 人で参加しにいくのは寂しい
  • 開発時間的に 1 人だと厳しい(当日開発メンバーを募ることもできますが)

と考えていたので、社内の同年代エンジニアを誘って即決で承諾もらいました。
業務で直接関わりがあるわけではなかった(話したことすらなかった)のですが、ハッカソンきっかけで 社内の他部署メンバーともチームになれる 、というのもこういったイベントに参加する良さだと思います。

社内の協力者を集められたことに安心したのもあって、ハッカソン開催前には社内の課題や使ってみたい技術とかについて少しだけ相談して、ふわっとしたテーマを決めただけです。

ハッカソン当日

ハッカソン当日の流れは以下です。

  1. 軽い自己紹介
  2. 参加者が持ち寄ってきたテーマの共有 & チームビルディング
  3. 開発
  4. 成果発表

すでに開発テーマが決まっているチーム、興味のあるテーマで開発する別チームに参加したい人、普段開発に携わる機会が少ない人、など多様な参加者がいました。

僕らのチームは、開催前に相談していたふわっとしたテーマを共有したところ、興味を持っていただいた方 1 人にうちのチームに参加していただきました。
僕らのチーム以外でも、当日作られていたチームが多かった印象です。 「社外の人と一緒に開発する」という経験をしたい方にはもってこいのイベント ですね。

チームビルディング後は、デモ環境としてどのくらい作りこむかのような要件整理をして、ひたすら開発です。

チームビルディングの様子

開発の様子

開発内容

今回開発したものはざっくりと以下です。

  1. Ansible を使ってスイッチの構成情報を LLDP で取得
  2. 取得したデータをパースして良い感じに整形
  3. inet-henge を使って可視化

ところどころ躓いたりしつつ助け合ってのワイガヤ開発でとても楽しかったです!

全くの余談ですが、飛行機の都合で少し遅れてくるメンバーには飛行機内でチーム名を考えてもらったりしていました w

発表

ある程度開発ゴールの目処がたってきたところで、発表資料も並行で作っていました。6,7 時間程度で、環境作って / デモ開発して / 発表資料を作る ので、時間は結構タイトです。
僕のチームが発表した 資料はこちら にあがっているので興味がある方は見てみてください。

他チームがどういう開発をしていたか、どんなツール使っているか、ということを聞けたりするのは面白かったです(他チームの資料は こちら)。
JANOG のネットワークを運用している学生主体のチームも参加していたのですが、成果物 が素晴らしくとても刺激受けました。

結果

結果としては Winner Team として JANOG 3 日目の Hackathon Wrap-Up にて登壇・発表させていただきました。
(正直言うと、上記のネットワーク運用チームには負けてしまったのですが、大人の事情で発表の機会をいただきました、、、)

Wrap-Upでの発表の様子

1 日という短い時間での開発だったこともあり、大したものを作ったわけではないですが、このように発表する機会を頂いたのはとてもいい経験になりました。
8/18 18:00 までは アーカイブ配信 があるので、興味があればぜひ見てみてください。

現地で挨拶もさせていただきましたが、inet-henge 作者の Kojima さんにも反応していただけました。JANOG 参加者同士で盛り上げていけるのは良いですね!

まとめ

総じて、ハッカソンに参加してとても良かったです!とてもいい経験になりました。
JANOG の運営をしてくださった方、特にハッカソンを運営してくださった皆さま、本当にありがとうございました!

次回の JANOG53 では NETCON が開催されるらしい?ので、興味ある方はチェックしてみると良いかもです。
僕は今後も JANOG に参加することはもちろん、スタッフとしての参加も楽しそうだな、と思っているので、もし JANOG 会場で見かけたらぜひお声がけください。

※ すべての写真は JANOG52 ミーティング フォトアルバムより