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

提供：hkatou_Lab
← 古い編集
ビジュアル
編集の要約なし
 
(同じ利用者による、間の37版が非表示)
1行目: 1行目:
JANOG52 Meeting in Nagasaki に参加しました。


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


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


8行目: 13行目:
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 グループで保守をメインに担当することから、あまり多様なオーナーはいないでしょう。
 




122行目: 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
[[カテゴリ:イベント]]
[[カテゴリ:イベント]]
「http://hkatou.net/wiki/2023-07-05-7_JANOG52_参加レポート」から取得