JANOG52 Meeting in Nagasaki に参加しました。

ほとんど個人用のメモですが、以下の用途に参考になるかもしれません。

発表を聞いたけど、用語が多くてよく分からなかった -> 用語のディティールを知りたい・調査するとっかかりがほしい

Day1

ケーブル敷設船きずな見学会

海底ケーブルを敷設・保守する、NTT-WEM (ワールドエンジニアリングマリン) の運用する船、きずなを見学させてもらいました。

船の所有について

2017 年 3 月 31 日に竣工し、NTT ファイナンスが保有して、NTT-WE にリースで貸し出しています。

船舶や飛行機では投資家などから資金を募って、購入資金を集めるファイナンスが一般的ですが、ケーブル敷設船はどのようなオーナーがいるのか気になりました。例えば大型のタンカーでは、年金機構のように投資家が入っていたりします。

きずなについては基本的に NTT グループで保守をメインに担当することから、あまり多様なオーナーはいないでしょう。

今回船内の写真は撮影禁止なため、Web で見つかった記事のリンクを記載します。

海底ケーブル

多芯ファイバー・電力線・外皮を備えたものを海底ケーブルに使用します。

距離が遠い場合はリピータを使用し、光を増幅して中継します。

リピータは電力を消費するため、電力線はここで使用されます。

電圧が 10,000-15,000V 程度と高く、電流は少なくて良いそうです。

海底ケーブル自体の所有は海底ケーブルの運用会社となっており、NTT-WEM では所有していない扱いになっているそうです。

保守

保守契約を結んだ海底ケーブルの運用企業から障害連絡を受けると、

関係省庁へ手続き
食料・水・燃料などの確保
保守対象のケーブルを積載

などの準備を行い、海底ケーブルの交換を行うとのことです。

ケーブルは敷設時期・保有/運用企業により異なるため、保守ではケーブルを搭載しておらず、出港時に交換対象のケーブルを積み込みます。

数は少ないようですが、光ファイバ以外に同軸の海底ケーブルも存在するとのこと。

災害対応

大規模災害時、

資機材・燃料
DoCoMo の船上基地局
会議室・医務室・宿泊施設

などを被災地域に提供できるとのこと。

実際の活動例としては、北海道胆振東部地震があり、今後は首都圏直下型地震や南海トラフ巨大地震などを想定して備えているそうです。

推進装置

主推進機は微出力の調整に優れる電気駆動を採用しており、船首のスラスターで左右移動、船尾に 360 ℃回転可能なスクリューを駆動し、微細な機動を行えるようになっています。

ディーゼルエンジンなどの内燃機関は、出力の微調整が難しく、狙った緯度・経度に停泊したいケーブル船の推進機には向いていないとのこと。

ややこしいですが、内燃機関を搭載しないわけではなく、ダイハツディーゼル 6DCM-32e 3,500ps x4 基を搭載して発電を行い、スラスターを電気駆動します。車でいうとホンダアコードハイブリッドやノート e-Power などのシリーズハイブリッドが近い方式だと言えます。

エンジンで発電
電気推進機を駆動
プロペラを回転

一般的な船尾の舵は、推進時に向きを変化させる (推進しないと転舵できない) ものであるため、搭載されていません。

DPS (Dynamic Positioning System)

風・潮流などの影響を計算して GPS の位置情報を補正し、推進機と連動して特定の位置に船を保持できるシステム。

リアルタイムでズレを測定し、その他の外乱要因も補正できるそうです。

ROV (Remote Operated Vehicle) CaRBIS- Ⅳ

海底の確認やケーブルの切断・引き上げを行う、200 馬力の無人潜水機のこと。

船上の建物であるコントロールルームから、液晶 9 画面とコンソールで操作します。

ケーブルクリッパーは 27 トンのケーブル引き上げ能力を持ち、これはケーブルエンジンと同じ能力になっています。

またウォータージェットで海底の砂を巻き上げて、ケーブルを埋設させる装備なども備えています。

他には金属探知機・マニピュレータ・カメラ・磁気センサーなどがあります。

海底ケーブルの障害原因

近海では漁で碇を下ろす・網に引っかかって誤って切断してしまう、浅海では地震・台風・潮流でケーブルがこすられて破損、といった原因があるそうです。

深海では潮流の影響が少ないため、逆に細いケーブルを使用してコストを下げられたりするとのこと。

深海探査機などでは深海のほうが水圧でコストがかかるため、これは意外でした。

航海期間

大体 40 日程度のミッションを行えるような資材を搭載できるそうです。

ケーブルタンク

2,500km のケーブルを収容でき、4 回で日米間 10,000km のケーブルを敷設できるようなスケールとなっています。

実際には米国側のケーブルは米国側から敷設・メンテナンスを行うほうが効率的なため、数分の一 + 余長程度のキャパシティがあれば問題ないようです。また、きずなは保守がメインの船であるため、キャパシティは低めと思われます。

ケーブルの積載はまだ自動化できていない分野で、どうしてもねじりなどでキレイに巻けないため、手動で巻いています。

光のリピータは組み込まれた状態でケーブルタンクに搭載されるため、敷設時はリニアケーブルエンジンなどで巻き込み事故が起こらないように低速化して作業するそうです。スキー場のリフトのように、乗り込むときだけ低速化されるのに近いですね。

ドラムケーブルエンジン

直径 2.7m の金属ドラムを使ったケーブル巻き上げ機です。ケーブルの敷設は海底の高さを考慮して行う必要があるため、送り出す速度を変化させて対応します。

巻き上げ時は横幅に対して均等に巻き上げ・敷設するため、2 つのフリーティングナイフライニングで均等になるように巻き付けます。

障害切り分け

リピータがある場合はどのリピータ間で障害が起きているか、リモートで電力を流してもらい流れた電流を ROV で確認するなどの手法を用いて、障害箇所を切り分け・特定していくとのこと。

リピータは 40-100km 程度の間隔で 1 つ設置されるパターンが多いそうで、切り分けは大変だと思います。

ケーブル交換

ケーブルは ROV のケーブルカッターで障害箇所を切断し、ケーブルクリッパーで引き上げて、新ケーブルで障害区間を除いて接続します。

交換は大体以下の手順となるようです。KDDI のオーシャンリンクの場合は以下。

障害ポイントの左右どちらかを切断
障害ポイントを特定
正常な部分 #1 のみの片側はブイをつけていったん沈めてしまう
船上に引き上げて、障害箇所を含むようにもう一箇所を切断し、異常な部分を含むケーブルを分離
新規ケーブルを正常な部分 #2 と接続
新規ケーブルと正常な部分 #1 と接続

Day2

モバイルコアネットワークのパブリッククラウド搭載に向けた取り組みとその課題　～ちょっと気になったので5GCをAWSに載せてみた～

PDF

5GC の設備をオンプレミスから自社仮想基盤・AWS の両方にプロビジョニングできるようにする

自社仮想基盤で動作 -> 障害時にコールドスタンバイの AWS にプロビ
- AWS 利用料が削減できる

AWS Graviton2 CPU に移行して省電力化

ShowNet でキャリア 5G とローカル 5G の使い分けを実験

Qmonus で加入者情報・スライスを統合制御
ネットワークスライスを高速と通常に分けて、スループットを高速 / 低速制御

SRv6による社内検証網の提供と、SR-MPLS/SRv6双方を運用してみてわかったこと

PDF

SRv6 は個人的にメリットがあまり理解できてない分野です。

技術的に SID を付与することで送信元情報をベースにルーティングできる (一般的には宛先ベース) のはわかるのですが、現実にどのようなメリット・ユースケースがあるのでしょうか ?

Segment Routing

送信元ノードで指定した SID をパケットに埋め込むことで、送信元に応じてルーティングを経路制御できる経路技術

SRv6 MUP (Mobile User Plane)

2023/02 ソフトバンクでフィールドトライアルを開始。

SRv6 SID IPv4 射影アドレス

行き : ノード#1 の送信元アドレスは SR ヘッダの中に埋め込まれる

戻り : 送信元アドレスは宛先ノード#2 が埋め込んでくるため、SR ヘッダの v6 アドレスに射影アドレスとしてエンコードされる

Flex-Algo

アンダーレイ上に複数のトポロジを生成

遅延を Metric にすることも可能

キャリアバックボーンネットワークへのホワイトボックスルータ商用化に向けた取り組み

事例の URL に対して、某ルータメーカーからのアクセスがかなりあったとのこと。

ホワイトボックスルータの導入は、世界で AT&T が一番で、KDDI が 2 例目。日本では最初の事例となる。

筆者の所感としては、非常に強力なコンセプトなため、今後採用例が増えていくと思います。

後述のクラスタ型アーキテクチャは、マーチャントシリコン採用シャーシ型スイッチを複数のボックススイッチにバラしたものになると思いますが、シャーシ型よりも柔軟性に優れるメリットがあると考えられます。

課題としては、

キャリア自身の責任範囲が増えるため、技術力が必要とされる
ハードウェアとソフトウェア間でトラブルが発生したとき、調査・切り分けが大変
- キャリア自身がハードウェアとソフトウェアで切り分けを行い、各メーカーへエスカレーションを行う必要がある
- 例) ハードウェアは DELTA -> Broadcom , ソフトウェアは SONiC コミュニティ
- コミュニティに修正を望むには、スピード感が足りないのでは、キャリア自身でもコードを書く覚悟が必要かも

などがあるのではないかと思います。

上記は今回のセッションで DELTA , SONiC と確認したわけではなく、筆者の想像です。

Open ROADM (Reconfigurable Optical Add Drop Multiplexer)

光伝送で波長を Add / Drop できる ROADM を、オープンアーキテクチャのハードウェアとソフトウェアで実装するコンセプト。

今までのルータ

ピアリングルータ・コアルータ・エッジルータで別々の機種が必要になる。

コアルータのアップグレードは、ルーティングエンジン・ラインカード・ファブリックを全取っ替えになってしまい、シャーシしか共通して使えるコンポーネントがなかった。

Telecom Infra Project (TIP)

ホワイトボックスルータを標準化する団体。800 社以上が参加し、日本からもモバイルキャリアなどから参加している。

Disaggregated Open Routers (DOR)

KDDI , Vodafone が議長となって牽引、欧米の主要 8 者が集結した団体。

TIP ガバナンスモデル

従来はキャリアが個別に行っていた検証について、キャリア間で検証結果を共有する。

各国空軍の戦闘機開発のように、個別開発から共同開発になるコンセプトと近い。

TIP DOR の活動内容

技術仕様策定・製品開発・検証・商用化し、世界に浸透・普及。

共通化してハードウェアとソフトウェアを各セグメントにルータを展開することで、スケールメリットを得る。

オープンルータの適用範囲

Cell Site Gateway

Open BNG

Aggregation Router

Edge Router

Core Router

ルータアーキテクチャの比較

シャーシ型

従来のルータメーカーのルータ

クロスファブリック型

DC の IP Clos
機器は個別管理
QoS , Deep Buffer , Large TCAM なし

クラスタ型

複数の物理ルータを、1 つの論理ルータとして扱うアーキテクチャ
コントロールプレーンは、物理ルータとは別のサーバ上に展開され、複数の物理ルータをデータプレーンとして動作する
パケットはセル化されて転送される、ファブリックと同様の動作を行う
- ファブリックホワイトボックスとパケットフォワーダーホワイトボックス
コントロールプレーンとデータプレーンが分離
データプレーンは後方互換性を持つ
Spine-Leaf 間のトランシーバ台が安い
QoS , Deep Buffer , Large TCAM あり

DDBR の優位性

1 つのアーキテクチャで検証・運用ナレッジ・予備品を共通化。

スケールアップ・スケールアウトが容易。

DDBR SW の機能

シンプルに保つのをポリシーに。

DDBR の実装

HW/SW で複数ベンダがサポート。サポートベンダには TIP 認定バッジを授与。

機器の見える化・運用の自動化が容易なアーキテクチャ。

DDBR 導入のユースケース

コア・エッジ・ピアリングルータ。

シンプルなソフトウェア機能・パケットフォワード機能。

アクセスネットワークよりも、バックボーンネットワークのほうが適している。

アクセス層ではユーザ側の要件に柔軟に対応するために、必要とされる機能が多い

KDDI の DDBR 商用化について

ピアリングルータ、スタンドアローンでの適用、すでにインターネットのトラフィックをさばいており、商用化できている。

参考リンク

IP Infusion’s Disaggregated Cell Site Gateway Solution Validated by KDDI Corporation; Delivers Carrier-Grade, Production-Ready Network Operating System

IP InfusionのDCSGソリューションが、KDDIの検証試験により、キャリアグレードの商用環境対応ネットワークOSであると評価

IP Infusion : S/W OcNOS (Cisco Like CLI)
- Product Brief
UfiSpace : H/W S9500-30XS

ホワイトボックスが網全域へ

キャリアバックボーンからIP Clos Fabricへの移行による5GSAネットワークの進化

コア設備を 5G 専用で動作させる、5GSA を IP Clos ファブリックで設計・構築した事例の発表でした。

5G / BGP-EVPN / CGN / FW とキャリア NW の良いまとめになっていると思いました。

CGN - Full Cone NAT

EIM (Endpoint Independent Mapping) : 同一の送信元 IP は同一グローバル IP に変換
EIF (Endpoint Indedependent Filtering) : EIM で通信済みの IP に対して、不特定多数の IP からの通信を許可

EIM かつ EIF であるとき、Full Cone NAT となる。

EVPNマルチホーミングと RFC8584のお話

PDF

EVPN マルチホーミングタイプ 4 Ethernet Segment Route

PE 間のリンクを持たないことで、MLAG に頼らずに L2 冗長化を実現する。

まとめ

ルーティングで負荷分散を行うため、

PE のノード数が 2 台よりも多くできる
遠隔冗長できる
異バージョン冗長が組める
- プロトコルの挙動はバージョンごとに異なるため、不具合となる場合も想定される
- 密結合よりは相当マシ
異機種冗長が組める
異メーカー冗長も可能

Vlan Aware Bundle のバッドプラクティス - SB 川上さんのナレッジ

Vlan allowed を冗長の片系のみ若番を追加 or 削除すると、DF の選出が正常に行われなくなり、片側で BUM が全く転送されなくなるといった障害が発生します。

使用しない Vlan1 を追加しておく回避策や、RFC8584 でこの挙動に対する改善が行われるといった対策があります。

Yahoo! JAPAN アメリカデータセンタとネットワーク変遷

PDF

新旧 DC 移行の苦労話とか。やっぱ物理レイヤでいろいろ課題が出てくるのが面白い。

2021/06 1000 年熱波カナダで 47.9 度の過去最高気温。

キャリアの回線がお亡くなりになったり、商店のコンプレッサーがお亡くなり -> 食品がすべて廃棄にとか。。

東日本エリアのネットワーク強靭化、転送効率化について議論しよう　Season2 ～東北・北海道エリアにおけるインターネット通信の継続性向上、効率的な転送を実現するためのeXchange方法について～

PDF

秋田 CATV : 個別に東京と繋いでいる北海道と東北の ISP を、IX で ISP 集約ポイントと接続し、個別に東京へ繋がなくても良くする実験を行った事例。

フリーランス BOF

2023/04 フリーランス新法が制定

JANOG 界隈でも増えている ?

サラリーマンとフリーランスの違い

フリーランスは業務委託契約で売上に応じた報酬となるが、サラリーマンは雇用契約に基づいた固定収入となるのが大きな違い。

ワーカホリックや自分に仕事を合わせる人に向いているのでは。

メリット

時間や仕事量がコントローラブル
自由度高し

デメリット

自己責任、社会保障が少なめ
本業以外のことも自分でやる必要あり
営業・経理・納税も自分でやる

株式会社コーダンス小島さん

00:00-04:00 とかも働いている。そもそも稼働量 (契約しているニンク) が週に 8.5 日に。。

JANOG は契約時点でスケジュール空けておく + 契約書に書いておく + 前後にタスクを消化して対応している。

100% リモート
チームに参加
基本はチャット + 各社 1h / 週の打ち合わせ
- 打ち合わせは時間帯固定

病気で休んだときにも、会社 -> 自分に給与を払うことができる。(会社の約款次第 ?)

会社にはお金が入らないため、会社のお金を消費してしまう

発注側から見て (想像)

だいたいうまく行ってる。長い発注元とは 8 年目。
細かいところでは問題あり
1 社員が複数プロジェクトを担当する文化だと問題なし
- 時間非同期で徐々にタスクを消化していく業務フロー
フルタイムで 1 プロジェクト担当する社員とペースが合わない
- (筆者注) ベンチャーのスピード感には向かないと考えられる
タスク割当に気を使う
「もっと時間増やして」
与信頑張ってって言われる (けどやる気なしw)
- 上げるノウハウもあるらしい
- (会社を持ってる別の人) 決算書とか渡して当然とか言われるが、別に渡したくねーし !!

株式会社イプリオ松下さん

地域 ISP / CATV 事業者様のネットワーク・サーバ構築保守運用を軸に対応。

フリーランスとの契約の有無、利用シーン

自社の技術力だけでは心細いとき、リソースが足りないとき
基本はプロジェクトベースで契約

フリーランスと組むデメリット

良くない意味で社員ではない
契約内容を決めておく必要がある
方針や業務スタイルにあうか ?

発注側 (イプリオ) からのリクエストがふわっとしすぎているケースがある

振り方が良くなかった ?

Day3

AI/ML基盤の400G DCネットワークを構築した話

PDF

AI/ML 基盤のために GPU サーバと 400G スイッチを導入するお話でした。

Infiniband の知見が少なく、Ethernet に安心感があった
要件の異なる Lossless NW / Lossy NW で 2 つの NW を構築・分離
- RoCEv2 Lossless Ethernet - サーバ間のインターコネクト (相互接続・RDMA)
- Lossy Ethernet - Storage , L3SW , FW/LB

RoCEv2

Inifiniband の知識が必須で、QoS チューニングが大変

200GE の輻輳ポイントを作成し、動作確認

Lossless Ethernet

PFC (Priority Flow Control)
ECN (Explicit Congestion Notification)
ETS (Enhanced Transmission Selection)

BGP

BGP Unnumbered P2P

Lossless Ethernet では BGP Graceful shutdown コミュニティを使い、メンテナンス時はトラフィックを迂回させる

LAG なし、Adaptive Routing で偏りなしに

トランシーバ

EoR のため Spine-Leaf の物理距離が近い

400G トランシーバは純正を選定

3rd Party だと shutdown -> no shutdown で Linkup しなかった、そもそも Linkup が遅い

OSFP-RHS (Riding Heat Sink)

ヒートシンクが NIC 側についているため、トランシーバにヒートシンクがない
GPU サーバ <-> SW 間は OSFP-RHS --- 400G-DR3 ---- OSFP-DD
MPO-12 / SMF

SONiC ZTPでデータセンターネットワークを作った話

PDF

6300 台のサーバを収容する Private HaaS NW を、ホワイトボックススイッチ 1600 台で構築、提供するプロジェクトの発表でした。目的は以下に設定したとのことです。

Private HaaS を早く利用者に提供したい
保守作業の品質を維持しつつ、効率を高めたい
NW エンジニアとしてスキルアップできる NW にしたい

HaaS Management NW

HaaS の HW 構築・プロビ・保守運用を目的とした NW

サーバ BMC
Switch OOB
iPDU

WBS (White Box Switch) + SONiC

納期が短く、要件にマッチした

ZTP (Zero Touch Provisioning)

ONIE で SONiC をインストール -> SONiC の ZTP が動作 -> Zabbix Agent の DL/Inst -> 疎通試験 -> 結果をサーバへアップロード

機器個別の情報は差分定義ファイル (.csv) に集約されており、シリアルを元にしてコンフィグを生成、共通テンプレートとマージする

最初の 1 台を ZTP サーバ (DHCP / TFTP) で手動構築、残りは ZTP で構築

保守交換も差分定義ファイルのシリアル番号を書き換えて、管理歩0お接続 + 電源を入れるだけで OK

開発 / 検証

仮想検証環境・機能/性能検証環境・商用疑似検証環境・Private HaaS 検証環境

IPv6 でいくつかの不具合が確認された

課題

構築失敗時の検知手法を開発したい

SSH できない
ログが上がらない

NWの拡張～広帯域化で解決を目指して100Gから400Gへ切り替えの挑戦～

大規模導入 vs 小規模導入

ホワイトボックススイッチの OS ベンダーが買収された !

別のスイッチを購入する羽目に
ツギハギ構成によって、運用にしわ寄せが

SuperSpine を 3 -> 6 台に増設するのは超大変

工事と運用の部隊から超怒られた。。

工事 : に、二度とやらないんだからねっ !
- 全部の Leaf から新 Spine x3 に新規配線