「2023-07-05-7 JANOG52 参加レポート」の版間の差分

提供：hkatou_Lab
ナビゲーションに移動 検索に移動
← 古い編集
ビジュアルウィキテキスト
 
(同じ利用者による、間の40版が非表示)
1行目: 1行目:
JANOG52 Meeting in Nagasaki に参加しました。


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


=== ケーブル敷設船きずな見学会 ===
* 発表を聞いたけど、用語が多くてよく分からなかった -> 用語のディティールを知りたい・調査するとっかかりがほしい
 
= Day1 =
 
== ケーブル敷設船きずな見学会 ==
海底ケーブルを敷設・保守する、NTT-WEM (ワールド エンジニアリング マリン) の運用する船、きずなを見学させてもらいました。
海底ケーブルを敷設・保守する、NTT-WEM (ワールド エンジニアリング マリン) の運用する船、きずなを見学させてもらいました。


==== 船の所有について ====
2017 年 3 月 31 日 に竣工し、[https://www.ntt-finance.co.jp/news/170331.html NTT ファイナンスが保有して、NTT-WE にリースで貸し出して]います。
2017 年 3 月 31 日 に竣工し、[https://www.ntt-finance.co.jp/news/170331.html NTT ファイナンスが保有して、NTT-WE にリースで貸し出して]います。


船舶や飛行機では投資家などから資金を募って、購入資金を集めるファイナンスが一般的です。
船舶や飛行機では投資家などから資金を募って、購入資金を集めるファイナンスが一般的ですが、ケーブル敷設船はどのようなオーナーがいるのか気になりました。例えば大型のタンカーでは、年金機構のように投資家が入っていたりします。
 
きずなについては基本的に NTT グループで保守をメインに担当することから、あまり多様なオーナーはいないでしょう。
 




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


* [https://www.ntt.com/bizon/k-1.html 最新鋭のケーブル敷設船「きずな」の内部に潜入！]
* [https://www.ntt.com/bizon/k-1.html 最新鋭のケーブル敷設船「きずな」の内部に潜入！]
28行目: 37行目:


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


* 関係省庁へ手続き
* 関係省庁へ手続き
38行目: 47行目:
ケーブルは敷設時期・保有/運用企業により異なるため、保守ではケーブルを搭載しておらず、出港時に交換対象のケーブルを積み込みます。
ケーブルは敷設時期・保有/運用企業により異なるため、保守ではケーブルを搭載しておらず、出港時に交換対象のケーブルを積み込みます。


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


==== 災害対応 ====
==== 災害対応 ====
52行目: 61行目:


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


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


同様に一般的な船尾の舵は推進時に向きを変化させるものであるため、搭載していません。
ややこしいですが、内燃機関を搭載しないわけではなく、[http://naikou00.blog70.fc2.com/blog-entry-3042.html?sp ダイハツ ディーゼル 6DCM-32e 3,500ps x4 基を搭載]して発電を行い、スラスターを電気駆動します。車でいうとホンダ アコード ハイブリッドやノート e-Power などの'''シリーズ ハイブリッド'''が近い方式だと言えます。
 
# エンジンで発電
# 電気推進機を駆動
# プロペラを回転
 
一般的な船尾の舵は、推進時に向きを変化させる (推進しないと転舵できない) ものであるため、搭載されていません。


==== [https://www.nttwem.co.jp/service/lay/ DPS] (Dynamic Positioning System) ====
==== [https://www.nttwem.co.jp/service/lay/ DPS] (Dynamic Positioning System) ====
風・潮流などの影響を計算して GPS のいち情報を補正し、推進機と連動して特定の位置に船を保持できるシステム。
風・潮流などの影響を計算して GPS の位置情報を補正し、推進機と連動して特定の位置に船を保持できるシステム。


==== [https://ja.wikipedia.org/wiki/ROV ROV] (Remote Operated Vehicle) ====
リアルタイムでズレを測定し、その他の外乱要因も補正できるそうです。
海底の確認やケーブルの切断・引き上げを行う、無人潜水機のこと。
 
====[https://ja.wikipedia.org/wiki/ROV ROV] (Remote Operated Vehicle) [http://naikou00.blog70.fc2.com/blog-entry-3041.html?sp CaRBIS- Ⅳ] ====
海底の確認やケーブルの切断・引き上げを行う、200 馬力の無人潜水機のこと。
 
船上の建物であるコントロール ルームから、液晶 9 画面とコンソールで操作します。


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


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


==== 海底ケーブルの障害 ====
他には金属探知機・マニピュレータ・カメラ・磁気センサーなどがあります。
近海では漁で誤って切断してしまう、浅海では地震・台風・潮流でケーブルがこすられて破損、といった原因があるそうです。


深海では潮流の影響が少ないため、逆に細いケーブルを使用してコストを下げられたりするとのこと。
==== 海底ケーブルの障害原因 ====
近海では漁で碇を下ろす・網に引っかかって誤って切断してしまう、浅海では地震・台風・潮流でケーブルがこすられて破損、といった原因があるそうです。


深海探査機などでは深海のほうがコストがかかる印象があったため、これは意外でした。
深海では潮流の影響が少ないため、逆に'''細いケーブルを使用してコストを下げられたりする'''とのこと。
 
深海探査機などでは深海のほうが水圧でコストがかかるため、これは意外でした。


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


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


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




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


==== [https://weekly.ascii.jp/elem/000/001/482/1482904/2/ ドラム ケーブル エンジン] ====
==== [https://weekly.ascii.jp/elem/000/001/482/1482904/2/ ドラム ケーブル エンジン] ====
直径 2.7m の金属ドラムを使ったケーブル巻き上げ機です。ケーブルの敷設は海底の高さを考慮して行う必要があるため、[https://www.nttwem.co.jp/service/lay/ 送り出す長さを変化させて対応]します。
直径 2.7m の金属ドラムを使ったケーブル巻き上げ機です。ケーブルの敷設は海底の高さを考慮して行う必要があるため、[https://www.nttwem.co.jp/service/lay/ 送り出す速度を変化させて対応]します。


巻き上げ時は横幅に対して均等に巻き上げ・敷設するため、2 つの[https://www.mhi.com/jp/group/mhimme/news/meet_no21_05.html フリーティングナイフライニングで均等になるように巻き付け]ます。
巻き上げ時は横幅に対して均等に巻き上げ・敷設するため、2 つの[https://www.mhi.com/jp/group/mhimme/news/meet_no21_05.html フリーティングナイフライニングで均等になるように巻き付け]ます。
109行目: 130行目:
# 新規ケーブルを正常な部分 #2 と接続
# 新規ケーブルを正常な部分 #2 と接続
# 新規ケーブルと正常な部分 #1 と接続
# 新規ケーブルと正常な部分 #1 と接続
= Day2 =
==[https://www.janog.gr.jp/meeting/janog52/5gccl/ モバイルコアネットワークのパブリッククラウド搭載に向けた取り組みとその課題　～ちょっと気になったので5GCをAWSに載せてみた～]==
[https://www.janog.gr.jp/meeting/janog52/wp-content/uploads/2023/06/janog52-5gccl-kunitomo_okuda_shimizu.pdf PDF]
5GC の設備をオンプレミスから自社仮想基盤・AWS の両方にプロビジョニングできるようにする
* 自社仮想基盤で動作 -> 障害時にコールド スタンバイの AWS にプロビ
** AWS 利用料が削減できる
AWS Graviton2 CPU に移行して省電力化
ShowNet でキャリア 5G と ローカル 5G の使い分けを実験
* Qmonus で加入者情報・スライスを統合制御
* ネットワーク スライスを高速と通常に分けて、スループットを高速 / 低速制御
==[https://www.janog.gr.jp/meeting/janog52/srop/ SRv6による社内検証網の提供と、SR-MPLS/SRv6双方を運用してみてわかったこと]==
[https://www.janog.gr.jp/meeting/janog52/wp-content/uploads/2023/06/janog52-srop-mishima-takenaka.pdf PDF]
SRv6 は個人的にメリットがあまり理解できてない分野です。
技術的に SID を付与することで送信元情報をベースにルーティングできる (一般的には宛先ベース) のはわかるのですが、現実にどのようなメリット・ユースケースがあるのでしょうか ?
==== Segment Routing ====
送信元ノードで指定した SID をパケットに埋め込むことで、送信元に応じてルーティングを経路制御できる経路技術
==== SRv6 MUP (Mobile User Plane) ====
2023/02 [https://www.softbank.jp/corp/news/press/sbkk/2023/20230224_01/ ソフトバンクでフィールドトライアルを開始]。
==== SRv6 SID IPv4 射影アドレス ====
行き : ノード#1 の送信元アドレスは SR ヘッダの中に埋め込まれる
戻り : 送信元アドレスは宛先ノード#2 が埋め込んでくるため、SR ヘッダの v6 アドレスに射影アドレスとしてエンコードされる
==== Flex-Algo ====
アンダーレイ上に複数のトポロジを生成
遅延を Metric にすることも可能
==[https://www.janog.gr.jp/meeting/janog52/carwb/ キャリアバックボーンネットワークへのホワイトボックスルータ商用化に向けた取り組み]==
事例の 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 商用化について ====
ピアリング ルータ、スタンドアローンでの適用、すでにインターネットのトラフィックをさばいており、商用化できている。
==== 参考リンク ====
[https://www.ipinfusion.com/news-events/ip-infusions-disaggregated-cell-site-gateway-solution-validated-by-kddi-corporation-delivers-carrier-grade-production-ready-network-operating-system/ IP Infusion’s Disaggregated Cell Site Gateway Solution Validated by KDDI Corporation; Delivers Carrier-Grade, Production-Ready Network Operating System]
[https://www.access-company.com/news_event/archives/20210315/ IP InfusionのDCSGソリューションが、KDDIの検証試験により、キャリアグレードの商用環境対応ネットワークOSであると評価]
* IP Infusion : S/W OcNOS (Cisco Like CLI)
** [https://www.ipinfusion.com/wp-content/uploads/05-23_OcNOS_AGGR_Product_Brief.pdf Product Brief]
* UfiSpace : H/W S9500-30XS
[https://www.access-company.com/wp-content/blogs.dir/3/files/2017/11/0225_IPInfusion.pdf ホワイトボックスが網全域へ]
=== [https://www.janog.gr.jp/meeting/janog52/cf5g/ キャリアバックボーンから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 となる。
==[https://www.janog.gr.jp/meeting/janog52/evpn/ EVPNマルチホーミングと RFC8584のお話]==
[https://www.janog.gr.jp/meeting/janog52/wp-content/uploads/2023/06/janog52-evpn-shtsuchi-00.pdf PDF]
==== EVPN マルチホーミング タイプ 4 Ethernet Segment Route ====
PE 間のリンクを持たないことで、MLAG に頼らずに L2 冗長化を実現する。
==== まとめ ====
ルーティングで負荷分散を行うため、
* PE のノード数が 2 台よりも多くできる
* 遠隔冗長できる
* 異バージョン冗長が組める
** プロトコルの挙動はバージョンごとに異なるため、不具合となる場合も想定される
** 密結合よりは相当マシ
* 異機種冗長が組める
* 異メーカー冗長も可能
==== Vlan Aware Bundle のバッドプラクティス - SB 川上さんのナレッジ ====
Vlan allowed を冗長の片系のみ若番を追加 or 削除すると、DF の選出が正常に行われなくなり、片側で BUM が全く転送されなくなるといった障害が発生します。
使用しない Vlan1 を追加しておく回避策や、RFC8584 でこの挙動に対する改善が行われるといった対策があります。
== [https://www.janog.gr.jp/meeting/janog52/atpo/ Yahoo! JAPAN アメリカデータセンタと ネットワーク変遷] ==
[https://www.janog.gr.jp/meeting/janog52/wp-content/uploads/2023/06/janog52-atpo-fukazawa.pdf PDF]
新旧 DC 移行の苦労話とか。やっぱ物理レイヤでいろいろ課題が出てくるのが面白い。
2021/06 1000 年熱波 カナダで 47.9 度の過去最高気温。
* キャリアの回線がお亡くなりになったり、商店のコンプレッサーがお亡くなり -> 食品がすべて廃棄にとか。。
==[https://www.janog.gr.jp/meeting/janog52/east/ 東日本エリアのネットワーク強靭化、転送効率化について議論しよう　Season2 ～東北・北海道エリアにおけるインターネット通信の継続性向上、効率的な転送を実現するためのeXchange方法について～]==
[https://www.janog.gr.jp/meeting/janog52/wp-content/uploads/2023/06/janog52-east-toyama-pre.pdf PDF]
秋田 CATV : 個別に東京と繋いでいる北海道と東北の ISP を、IX で ISP 集約ポイントと接続し、個別に東京へ繋がなくても良くする実験を行った事例。
==[https://www.janog.gr.jp/meeting/janog52/bof-freelance/ フリーランス BOF]==
2023/04 フリーランス新法が制定
JANOG 界隈でも増えている ?
==== サラリーマンとフリーランスの違い ====
フリーランスは業務委託契約で売上に応じた報酬となるが、サラリーマンは雇用契約に基づいた固定収入となるのが大きな違い。
ワーカホリックや自分に仕事を合わせる人に向いているのでは。
==== メリット ====
* 時間や仕事量がコントローラブル
* 自由度高し
==== デメリット ====
* 自己責任、社会保障が少なめ
* 本業以外のことも自分でやる必要あり
* 営業・経理・納税も自分でやる
==== 株式会社コーダンス 小島さん ====
00:00-04:00 とかも働いている。そもそも稼働量 (契約しているニンク) が週に 8.5 日に。。
JANOG は契約時点でスケジュール空けておく + 契約書に書いておく + 前後にタスクを消化して対応している。
* 100% リモート
* チームに参加
* 基本はチャット + 各社 1h / 週の打ち合わせ
** 打ち合わせは時間帯固定
病気で休んだときにも、会社 -> 自分に給与を払うことができる。(会社の約款次第 ?)
* 会社にはお金が入らないため、会社のお金を消費してしまう
===== 発注側から見て (想像) =====
* だいたいうまく行ってる。長い発注元とは 8 年目。
* 細かいところでは問題あり
* 1 社員が複数プロジェクトを担当する文化だと問題なし
** 時間非同期で徐々にタスクを消化していく業務フロー
* フルタイムで 1 プロジェクト担当する社員とペースが合わない
** (筆者注) ベンチャーのスピード感には向かないと考えられる
* タスク割当に気を使う
* 「もっと時間増やして」
* 与信頑張ってって言われる (けどやる気なしw)
** 上げるノウハウもあるらしい
** (会社を持ってる別の人) 決算書とか渡して当然とか言われるが、別に渡したくねーし !!
==== 株式会社イプリオ 松下さん ====
地域 ISP / CATV 事業者様のネットワーク・サーバ構築 保守運用を軸に対応。
===== フリーランスとの契約の有無、利用シーン =====
* 自社の技術力だけでは心細いとき、リソースが足りないとき
* 基本はプロジェクトベースで契約
===== フリーランスと組むデメリット =====
* 良くない意味で社員ではない
* 契約内容を決めておく必要がある
* 方針や業務スタイルにあうか ?
===== 発注側 (イプリオ) からのリクエストがふわっとしすぎているケースがある =====
* 振り方が良くなかった ?
= Day3 =
==[https://www.janog.gr.jp/meeting/janog52/aiml400/ AI/ML基盤の400G DCネットワークを構築した話]==
[https://www.janog.gr.jp/meeting/janog52/wp-content/uploads/2023/06/janog52-aiml400-uchida-koshoji.pdf 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
*
==[https://www.janog.gr.jp/meeting/janog52/sonicztp/ SONiC ZTPでデータセンターネットワークを作った話]==
[https://www.janog.gr.jp/meeting/janog52/wp-content/uploads/2023/06/janog52-sonicztp_pre.pdf 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 できない
* ログが上がらない
==[https://www.janog.gr.jp/meeting/janog52/spine/ NWの拡張～広帯域化で解決を目指して100Gから400Gへ切り替えの挑戦～]==
==== 大規模導入 vs 小規模導入 ====
ホワイトボックス スイッチの OS ベンダーが買収された !
* 別のスイッチを購入する羽目に
* ツギハギ構成によって、運用にしわ寄せが
==== SuperSpine を 3 -> 6 台に増設するのは超大変 ====
工事と運用の部隊から超怒られた。。
* 工事 : に、二度とやらないんだからねっ !
** 全部の Leaf から新 Spine x3 に新規配線
==[https://www.janog.gr.jp/meeting/janog52/srop/ SRv6による社内検証網の提供と、SR-MPLS/SRv6双方を運用してみてわかったこと]==
[https://www.janog.gr.jp/meeting/janog52/wp-content/uploads/2023/06/janog52-srop-mishima-takenaka.pdf PDF]
NTT コミュニケーションズの SRv6 Testbed : SRv6 vs SR-MPLS のお話。
SR-MPLS から SRv6 の機能を利用し、SR-MPLS に戻す検証を実施。
* Interwork Router に 2 つ VRF を作成して実現した
==[https://www.janog.gr.jp/meeting/janog52/p4/ P4から探る、サーバーサイド高速パケット処理の現状と展望]==
[https://www.janog.gr.jp/meeting/janog52/wp-content/uploads/2023/06/janog52-p4serverside-ebisawa.pdf PDF]
スイッチの ASIC やサーバのスマート NIC で使用される、P4 言語のお話。
==== P4 のメリット ====
データプレーンを HAL (Hardware Abstraction Layer) で抽象化することで、データプレーンが世代交代しても、ソフトウェア資産を捨てなくても良くなる。(2011 Scott Shenker)
Classic な ASIC はパケット処理がハードコードされていて、新機能の追加はできない。
新世代の ASIC は Programmable になってきており、ソフトウェアからパケット処理を変更できるようになってきている。
* Ex) Cisco UADP ASIC , Cisco Silicon One , Broadcom Trident
データ プレーンをソフトウェア (P4 DPDK) に入れ替えて検証することで、コントロール プレーンの検証を仮想環境で実施できるようになる。
==== Intel の Tofino ASIC の開発が凍結された ====
* 生産は継続するが、新規の研究開発を凍結する
* Alibaba など中国で圧倒的に売れている
* P4 には投資していく
* スマート NIC の IPU が売れすぎた
==== サーバサイド・アクセラレーション ====
* ネットワークが CPU リソースを消費してしまうようになってきているが、CPU では増大する速度に対してパフォーマンスが不足する
* ネットワークの処理を NIC にオフロードすることで、CPU のリソースを空けることが可能に -> IPDK (Infrastructure Programmer Development Kit)
==== OPI (Open Programmable Infrastructure) ====
スマート NIC のメーカーに依存せず、ユーザがメーカーを選択できるように標準化を行う団体。
==== スマート NIC のメーカー・製品例 ====
製品バリエーションは PDF に。以下は代表的なもの。
* Intel IPU E2000
* AMD Pensand DSC2-200
* NVIDIA (Mellanox) ConnectX SmartNICs
[[カテゴリ:イベント]]
[[カテゴリ:イベント]]

2023年7月21日 (金) 16:21時点における最新版

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 などのシリーズ ハイブリッドが近い方式だと言えます。

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

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

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. 障害ポイントを特定
  3. 正常な部分 #1 のみの片側はブイをつけていったん沈めてしまう
  4. 船上に引き上げて、障害箇所を含むようにもう一箇所を切断し、異常な部分を含むケーブルを分離
  5. 新規ケーブルを正常な部分 #2 と接続
  6. 新規ケーブルと正常な部分 #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)
  • 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 台で構築、提供するプロジェクトの発表でした。目的は以下に設定したとのことです。

  1. Private HaaS を早く利用者に提供したい
  2. 保守作業の品質を維持しつつ、効率を高めたい
  3. 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 に新規配線

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

PDF

NTT コミュニケーションズの SRv6 Testbed : SRv6 vs SR-MPLS のお話。

SR-MPLS から SRv6 の機能を利用し、SR-MPLS に戻す検証を実施。

  • Interwork Router に 2 つ VRF を作成して実現した

P4から探る、サーバーサイド高速パケット処理の現状と展望

PDF

スイッチの ASIC やサーバのスマート NIC で使用される、P4 言語のお話。


P4 のメリット

データプレーンを HAL (Hardware Abstraction Layer) で抽象化することで、データプレーンが世代交代しても、ソフトウェア資産を捨てなくても良くなる。(2011 Scott Shenker)

Classic な ASIC はパケット処理がハードコードされていて、新機能の追加はできない。

新世代の ASIC は Programmable になってきており、ソフトウェアからパケット処理を変更できるようになってきている。

  • Ex) Cisco UADP ASIC , Cisco Silicon One , Broadcom Trident

データ プレーンをソフトウェア (P4 DPDK) に入れ替えて検証することで、コントロール プレーンの検証を仮想環境で実施できるようになる。


Intel の Tofino ASIC の開発が凍結された

  • 生産は継続するが、新規の研究開発を凍結する
  • Alibaba など中国で圧倒的に売れている
  • P4 には投資していく
  • スマート NIC の IPU が売れすぎた


サーバサイド・アクセラレーション

  • ネットワークが CPU リソースを消費してしまうようになってきているが、CPU では増大する速度に対してパフォーマンスが不足する
  • ネットワークの処理を NIC にオフロードすることで、CPU のリソースを空けることが可能に -> IPDK (Infrastructure Programmer Development Kit)


OPI (Open Programmable Infrastructure)

スマート NIC のメーカーに依存せず、ユーザがメーカーを選択できるように標準化を行う団体。

スマート NIC のメーカー・製品例

製品バリエーションは PDF に。以下は代表的なもの。

  • Intel IPU E2000
  • AMD Pensand DSC2-200
  • NVIDIA (Mellanox) ConnectX SmartNICs
「http://hkatou.net/index.php?title=2023-07-05-7_JANOG52_参加レポート&oldid=1104」から取得