「2024-01-17-19 JANOG53 参加レポート」の版間の差分
ナビゲーションに移動
検索に移動
編集の要約なし |
編集の要約なし |
||
| (同じ利用者による、間の13版が非表示) | |||
| 1行目: | 1行目: | ||
今回は個人的に見たいセッションが多かったです。キーワードをこのレポートにメモったので、今後見直して反芻していきたい。 | |||
= | = Day1 = | ||
== | == 15:30 [https://www.janog.gr.jp/meeting/janog53/global/ 海外で日本のやり方が通用しないの、なぁぜなぁぜ？ 東南アジアでのインターネットインフラを構築の実例から、グローバルでのオペレータ交流を考える]== | ||
===== ケーブリングやばいよ | === BBIX 立松さん : [https://www.janog.gr.jp/meeting/janog53/wp-content/uploads/2023/11/janog53-GLOBAL-%E7%AB%8B%E6%9D%BE-%E8%A3%95%E5%B0%87.pre_.pdf 資料]=== | ||
==== ケーブリングやばいよ ==== | |||
* 海外はケーブリングがとてもやばいぞ ! | * 海外はケーブリングがとてもやばいぞ ! | ||
==== 品質とスピード ==== | |||
* 日本の品質は海外案件に適用できない | * 日本の品質は海外案件に適用できない | ||
** 海外はスピード優先で、企画・設計・構築をやる必要がある | ** 海外はスピード優先で、企画・設計・構築をやる必要がある | ||
| 14行目: | 16行目: | ||
** 「今日は走れるクルマが少ないんだよー」「!?」 | ** 「今日は走れるクルマが少ないんだよー」「!?」 | ||
** 車両ナンバーの末尾で、走行できる日が規制されている | ** 車両ナンバーの末尾で、走行できる日が規制されている | ||
** 主に渋滞・混雑対策 | |||
* DC に持ち込みは Quarantine (検疫) で 1 日必要 | * DC に持ち込みは Quarantine (検疫) で 1 日必要 | ||
** immunity test のために必要 : 電源に影響を及ぼさないかのチェックのため | ** immunity test のために必要 : 電源に影響を及ぼさないかのチェックのため | ||
** 今回については、何もやってない (DC で 1 日放置) | ** 今回については、何もやってない (DC で 1 日放置) | ||
==== 税関で製品が止められる件 ==== | |||
輸出の該非判定が必要、通関のために書類がいろいろ求められる。 | 輸出の該非判定が必要、通関のために書類がいろいろ求められる。 | ||
| 26行目: | 29行目: | ||
** 香港も厳しいらしい | ** 香港も厳しいらしい | ||
=== NTT-Data 冨樫さん : [https://www.janog.gr.jp/meeting/janog53/wp-content/uploads/2023/11/janog53-GLOBAL-%E5%86%A8%E6%A8%AB-%E6%B4%B8.pre_.pdf 資料]=== | |||
ジャカルタで JKT-IX を立ち上げた話。 | ジャカルタで JKT-IX を立ち上げた話。 | ||
* IX 単体で儲けるのではなく、コンテンツプロバイダなどのターゲット顧客を DC に誘致して、DC を拡販する | * IX 単体で儲けるのではなく、コンテンツプロバイダなどのターゲット顧客を DC に誘致して、DC を拡販する | ||
* NTT の名前は出さず、ジャカルタ ローカルへ貢献するように | |||
==== 相互接続交渉が難航した話 ==== | |||
日本人が交渉して 2-3 ヶ月接続できなかったのが、交渉先のボードメンバーと友達を交渉担当者にアサインすると 1 週間で妥結された。。 | 日本人が交渉して 2-3 ヶ月接続できなかったのが、交渉先のボードメンバーと友達を交渉担当者にアサインすると 1 週間で妥結された。。 | ||
==== プライジング ==== | |||
2017 当時の IX マーケットだと、IX は $0 | 2017 当時の IX マーケットだと、IX は $0 | ||
* 費用を取ろうとすると、めっちゃ怒られた | * 費用を取ろうとすると、めっちゃ怒られた | ||
シェア No.1 | シェア No.1 を取ってからは、無料 (1G) と高速プラン (10G-) に分けて課金できるようになった。 | ||
==== インドネシアの要求品質 ==== | |||
同時複数ダウン時以外はトラブルシュートしない、通知しない。 | 同時複数ダウン時以外はトラブルシュートしない、通知しない。 | ||
| 48行目: | 52行目: | ||
他のメンバーからの問い合わせや、全体に影響する問題は妥協せず対応する。 | 他のメンバーからの問い合わせや、全体に影響する問題は妥協せず対応する。 | ||
==[https://www.janog.gr.jp/meeting/janog53/as63802/ 特殊局が手掛けるIN地域研究室の紹介「インターネット業界の未来を創る技術者育成」]== | |||
[[カテゴリ: | |||
* IN 地域 = インチキ | |||
=== NTT 特殊局 === | |||
光ファイバー・クロージャー・果物 (!?) | |||
* ファイバと一緒にバナナが干してある | |||
技術研究に適したコンピュータ・ネットワークを提供する。 | |||
=== パワーワード集 === | |||
苦行センター | |||
うちのメールサーバーにはアメリカ人が住んでいた | |||
* 最近は中国かロシアからのホームステイ (!?) が多い | |||
IN 地域 NW (インチキ NW) | |||
イン地域研究室 | |||
* サーバ・ネットワークを自由に触れる環境 | |||
霞が関 曼荼羅 | |||
* PPT にすべての要素を詰め込んで書き込まれたもの | |||
* 参考 : [https://nlab.itmedia.co.jp/nl/articles/2303/07/news151.html 環境省の作ったパワポ資料がある意味すごいと話題] | |||
僕がいなくなったらふすまが開くようになったらしい | |||
* ISP・検証用の機材を木造の 2 階自室に置いていたら、家が傾いていた | |||
* 実家 -> 東京に引っ越したら解決 | |||
「NTT 東日本に就職すれば、ダークファイバーを使い放題だよね」 | |||
* そう思っていた時代も僕にもありました | |||
つぶらなひとみで「光ファイバ利用申請書類」を社内へ提出すると・・・ | |||
* NTT 法の関係で自由に使えるわけじゃないと思われる | |||
=== ブートストラップ問題 === | |||
(登さん) ネットワークの初学者が学ぶための、書籍が古くなっていて入りづらくなってきていて、口伝になってしまっている | |||
=== 質疑応答 : NTT は金持ちだから成長しなかった ? === | |||
お金が自由に使えることで、不利になることがある。お金に制限があることで、知恵と工夫をする余地が生まれる。 | |||
* Google : インチキサーバで起業 | |||
* Amazon : Sun の SPARC サーバが高すぎたので、x86 サーバでクラウドを作った | |||
もの好き同士の連携が少なくなっているのでは。 | |||
= Day2 = | |||
==[https://www.janog.gr.jp/meeting/janog53/400g/ 400G時代の相互接続 〜100G-LR1って検討されてますか？〜]== | |||
[https://www.janog.gr.jp/meeting/janog53/wp-content/uploads/2023/11/JANOG53_400G%E6%99%82%E4%BB%A3%E3%81%AE%E7%9B%B8%E4%BA%92%E6%8E%A5%E7%B6%9A-%E3%80%9C100G-LR1%E3%81%A3%E3%81%A6%E6%A4%9C%E8%A8%8E%E3%81%95%E3%82%8C%E3%81%A6%E3%81%BE%E3%81%99%E3%81%8B%EF%BC%9F%E3%80%9C.pdf 資料] | |||
100G-LR4 が高いので、100G-LR1 ってどう ? というセッション。 | |||
{| class="wikitable" | |||
|+ | |||
比較 | |||
!規格 | |||
!変調方式 | |||
!波長数 | |||
!FEC | |||
!ブレークアウト | |||
!メリット | |||
!デメリット | |||
|- | |||
|100G-LR4 | |||
|NRZ : 2 値 | |||
|25G x 4 波長 | |||
|任意 | |||
|? | |||
|使用実績が長い | |||
|コストが高い | |||
|- | |||
|100G-LR1 | |||
|PAM4 : 4 値 | |||
|100G x 1 波長 | |||
|必須 | |||
|400G-PLR4 から可能 | |||
|IC 部の微細化でコスト低減されそう | |||
波長数が少ないため、HW コンポーネント数が低減 -> MTBF に好影響 | |||
|リンクアップが遅い | |||
|} | |||
安いのと採用例が増えているため、みんなで利用を推進したい。 | |||
==[https://www.janog.gr.jp/meeting/janog53/dcqos/ データセンターネットワークでの輻輳対策どうしてる？]== | |||
=== In-cast congestion === | |||
* any src to 1 dest | |||
* 受信側で tail drop | |||
* 対処が難しい | |||
* 今回の発表のメイン対象 | |||
=== Fabric congestion === | |||
* 不均衡なトラフィック分散 | |||
=== Out-cast congetion === | |||
=== Lossy === | |||
* TCP 再送でカバー | |||
=== Lossless === | |||
* RDMA などでロスレスにする | |||
=== 対処策 === | |||
* 専用 NW | |||
** 専用構成が乱立 | |||
* 輻輳対策 HW | |||
** コストが妥当なのか ? | |||
* バッファチューニング | |||
** これは実施していない | |||
=== 輻輳制御の手法 === | |||
* Deep Buffer | |||
* ECN , PFC | |||
* DCTC | |||
* H-TCP , CUBIC , BBR | |||
=== Deep Buffer === | |||
GB 単位の HBM 大容量メモリでバースト トラフィックを吸収する | |||
HoLB (Head of Line Blocking) 対策の VoQ | |||
VoQ アーキテクチャと Buffer Broat (バッファによる遅延) | |||
Loss-Based TCP 輻輳制御アルゴリズムだとバッファを埋め尽くすまで止まらない | |||
* AQM で先行してドロップさせる | |||
=== ECN (Explicit Congestion Notification) === | |||
* 受信側がフィードバックのために、送信側に Notification して、送信を抑制する | |||
=== PFC (Priority-based Flow Control) === | |||
* Traffic Class のキューから PAUSE フレームを送信する | |||
=== Hadoop === | |||
In-cast Congestion が起きやすい Hadoop を検証ターゲットとした。 | |||
=== TeraSort === | |||
* Hadoop に標準搭載されたベンチマーク | |||
=== 予想に反した検証結果 === | |||
* '''Deep Buffer''' のジョブ完了時間が、Shallow (短い) Buffer よりも'''長い''' (なんでや !) | |||
** Deep Buffer はドロップが抑えられているが、処理時間が長かった | |||
* 負荷が高くても Shallow (短い) Buffer のほうが、ジョブ完了時間が短かった | |||
* PFC のみ有効だと、InDiscards が増加し、OutDiscards は発生しない | |||
=== 予想通りだった検証結果 === | |||
* ECN を設定すると Drop がほぼ抑えられた | |||
* Deep Buffer よりも速く完了した | |||
=== 今後のアクション === | |||
* Deep Buffer は必要ないかも | |||
= Day3 = | |||
==[https://www.janog.gr.jp/meeting/janog53/div1nfv/ 自作k6 Extension利用した NFVへの負荷計測手法の紹介]== | |||
MVNO は HSS , PGW-C , PGW-U を BB Sakura で自作している。 | |||
「パフォーマンス測定ツールがなければ、作ればいいじゃない」 | |||
[https://github.com/bbsakura/xk6-gtp github] に公開中。 | |||
==[https://www.janog.gr.jp/meeting/janog53/div3ansible/ 知っておくと小回りがきく Ansibleの使い方]== | |||
ansible-playbook 実行時に、-e (--extra-vars) +"@" を使う | |||
* 外部ファイルを指定して実行すると良い感じ | |||
YAML 記述に中括弧 "{}" とカンマ "," を使う | |||
* Juniper の display set コンフィグみたいになるので見やすい | |||
==[https://www.janog.gr.jp/meeting/janog53/div4fhr/ OpenStack on L3 Clos-NW First-Hop Redundancy by Open vSwitch & BGP in Yahoo! JAPAN network.]== | |||
[https://www.janog.gr.jp/meeting/janog53/wp-content/uploads/2024/01/%E3%80%90%E7%99%BA%E8%A1%A8%E8%B3%87%E6%96%99%E3%80%91OpenStack-on-L3-Clos-NW-First-Hop-Redundancy-by-Open-vSwitch-BGP-in-Yahoo-JAPAN-network.pdf 資料] | |||
==[https://www.janog.gr.jp/meeting/janog53/nfv/ 次世代OpenStack NFV基盤の検証]== | |||
[https://www.janog.gr.jp/meeting/janog53/wp-content/uploads/2023/11/janog53-NFV-%E8%BE%BB-%E5%BA%83%E5%BF%97-pre.pdf 資料] | |||
IPv6 シングル スタック環境で構築する OpenStack 基盤のナレッジ。 | |||
IPv6 ND RA と DHCPv6 ってややこしいよね・・・ | |||
==[https://www.janog.gr.jp/meeting/janog53/as2518/ BIGLOBE AS2518をまるごと仮想環境へ”コピー”してみた]== | |||
[https://www.janog.gr.jp/meeting/janog53/wp-content/uploads/2024/01/janog53-as2518-takiguchi-pre.pdf 資料1] | |||
[https://www.janog.gr.jp/meeting/janog53/wp-content/uploads/2023/11/janog53_as2518_all.pdf 資料2] | |||
[https://www.janog.gr.jp/meeting/janog53/wp-content/uploads/2024/01/janog53_as2518_%E6%BB%9D%E5%8F%A3%E6%95%8F%E8%A1%8C.pdf 資料3] | |||
All 実機では難しい商用 NW を仮想環境で再現して、「NW 全体の動作を」「実際にやって確認」したい。 | |||
=== BIGLOBE === | |||
DC 10 拠点、L2SW / Router で 50 台以上、3.2Tbps 以上、ピア数 220 以上。 | |||
月 20 件程度の作業に対して、障害を防ぐためのレビュー多すぎ問題がある。 | |||
* ベテラン -> マネージャー (-> 部長) | |||
構成図を最新に保つことが難しい。 | |||
=== 仮想環境の作成 === | |||
商用環境のコンフィグを吸い出して、コンテナ NOS を生成する仕組みを構築し、テストベッドを使えるようにする。 | |||
* iperf ノードや監視システムも同時にデプロイされる | |||
* iperf は商用のフローデータから、プレフィックスごとの流量を再現させた | |||
=== 仮想環境で確認できたこと === | |||
show コマンドやトラフィック断の有無などは、仮想環境で確認でき、レビュー者の負担が減らせた | |||
=== 仮想環境できなかったこと === | |||
Juniper の cPRD に統一したが、Cisco ルータの挙動は確認できていない。 | |||
PNI は適用可能だが、IX / Transit ピアは非定型で対応できていない。 | |||
外部 AS も再現したいが、コンフィグが無い。 | |||
* 再現に必要な情報を別途与える | |||
コンフィグのデフォルメと網羅性の両立が難しい。 | |||
* 商用コンフィグはデカすぎて扱うのがつらい | |||
[[カテゴリ:イベント]] | |||
2024年1月23日 (火) 08:18時点における最新版
今回は個人的に見たいセッションが多かったです。キーワードをこのレポートにメモったので、今後見直して反芻していきたい。
Day1
15:30 海外で日本のやり方が通用しないの、なぁぜなぁぜ？ 東南アジアでのインターネットインフラを構築の実例から、グローバルでのオペレータ交流を考える
BBIX 立松さん : 資料
ケーブリングやばいよ
- 海外はケーブリングがとてもやばいぞ !
品質とスピード
- 日本の品質は海外案件に適用できない
- 海外はスピード優先で、企画・設計・構築をやる必要がある
- レンタカーはドライバー付きじゃないと、クルマを貸し出してくれない
- 「今日は走れるクルマが少ないんだよー」「!?」
- 車両ナンバーの末尾で、走行できる日が規制されている
- 主に渋滞・混雑対策
- DC に持ち込みは Quarantine (検疫) で 1 日必要
- immunity test のために必要 : 電源に影響を及ぼさないかのチェックのため
- 今回については、何もやってない (DC で 1 日放置)
税関で製品が止められる件
輸出の該非判定が必要、通関のために書類がいろいろ求められる。
- Cisco はオンラインで書類を発行できたりする
- 中古機材は持ち込むのが難しい
- 新品はメーカーから書類を入手したり、ノウハウがあったり
- 香港も厳しいらしい
NTT-Data 冨樫さん : 資料
ジャカルタで JKT-IX を立ち上げた話。
- IX 単体で儲けるのではなく、コンテンツプロバイダなどのターゲット顧客を DC に誘致して、DC を拡販する
- NTT の名前は出さず、ジャカルタ ローカルへ貢献するように
相互接続交渉が難航した話
日本人が交渉して 2-3 ヶ月接続できなかったのが、交渉先のボードメンバーと友達を交渉担当者にアサインすると 1 週間で妥結された。。
プライジング
2017 当時の IX マーケットだと、IX は $0
- 費用を取ろうとすると、めっちゃ怒られた
シェア No.1 を取ってからは、無料 (1G) と高速プラン (10G-) に分けて課金できるようになった。
インドネシアの要求品質
同時複数ダウン時以外はトラブルシュートしない、通知しない。
利用者から要求がない品質は追わない。
他のメンバーからの問い合わせや、全体に影響する問題は妥協せず対応する。
特殊局が手掛けるIN地域研究室の紹介「インターネット業界の未来を創る技術者育成」
- IN 地域 = インチキ
NTT 特殊局
光ファイバー・クロージャー・果物 (!?)
- ファイバと一緒にバナナが干してある
技術研究に適したコンピュータ・ネットワークを提供する。
パワーワード集
苦行センター
うちのメールサーバーにはアメリカ人が住んでいた
- 最近は中国かロシアからのホームステイ (!?) が多い
IN 地域 NW (インチキ NW)
イン地域研究室
- サーバ・ネットワークを自由に触れる環境
霞が関 曼荼羅
- PPT にすべての要素を詰め込んで書き込まれたもの
- 参考 : 環境省の作ったパワポ資料がある意味すごいと話題
僕がいなくなったらふすまが開くようになったらしい
- ISP・検証用の機材を木造の 2 階自室に置いていたら、家が傾いていた
- 実家 -> 東京に引っ越したら解決
「NTT 東日本に就職すれば、ダークファイバーを使い放題だよね」
- そう思っていた時代も僕にもありました
つぶらなひとみで「光ファイバ利用申請書類」を社内へ提出すると・・・
- NTT 法の関係で自由に使えるわけじゃないと思われる
ブートストラップ問題
(登さん) ネットワークの初学者が学ぶための、書籍が古くなっていて入りづらくなってきていて、口伝になってしまっている
質疑応答 : NTT は金持ちだから成長しなかった ?
お金が自由に使えることで、不利になることがある。お金に制限があることで、知恵と工夫をする余地が生まれる。
- Google : インチキサーバで起業
- Amazon : Sun の SPARC サーバが高すぎたので、x86 サーバでクラウドを作った
もの好き同士の連携が少なくなっているのでは。
Day2
400G時代の相互接続 〜100G-LR1って検討されてますか？〜
100G-LR4 が高いので、100G-LR1 ってどう ? というセッション。
| 規格 | 変調方式 | 波長数 | FEC | ブレークアウト | メリット | デメリット |
|---|---|---|---|---|---|---|
| 100G-LR4 | NRZ : 2 値 | 25G x 4 波長 | 任意 | ? | 使用実績が長い | コストが高い |
| 100G-LR1 | PAM4 : 4 値 | 100G x 1 波長 | 必須 | 400G-PLR4 から可能 | IC 部の微細化でコスト低減されそう
波長数が少ないため、HW コンポーネント数が低減 -> MTBF に好影響 |
リンクアップが遅い |
安いのと採用例が増えているため、みんなで利用を推進したい。
データセンターネットワークでの輻輳対策どうしてる？
In-cast congestion
- any src to 1 dest
- 受信側で tail drop
- 対処が難しい
- 今回の発表のメイン対象
Fabric congestion
- 不均衡なトラフィック分散
Out-cast congetion
Lossy
- TCP 再送でカバー
Lossless
- RDMA などでロスレスにする
対処策
- 専用 NW
- 専用構成が乱立
- 輻輳対策 HW
- コストが妥当なのか ?
- バッファチューニング
- これは実施していない
輻輳制御の手法
- Deep Buffer
- ECN , PFC
- DCTC
- H-TCP , CUBIC , BBR
Deep Buffer
GB 単位の HBM 大容量メモリでバースト トラフィックを吸収する
HoLB (Head of Line Blocking) 対策の VoQ
VoQ アーキテクチャと Buffer Broat (バッファによる遅延)
Loss-Based TCP 輻輳制御アルゴリズムだとバッファを埋め尽くすまで止まらない
- AQM で先行してドロップさせる
ECN (Explicit Congestion Notification)
- 受信側がフィードバックのために、送信側に Notification して、送信を抑制する
PFC (Priority-based Flow Control)
- Traffic Class のキューから PAUSE フレームを送信する
Hadoop
In-cast Congestion が起きやすい Hadoop を検証ターゲットとした。
TeraSort
- Hadoop に標準搭載されたベンチマーク
予想に反した検証結果
- Deep Buffer のジョブ完了時間が、Shallow (短い) Buffer よりも長い (なんでや !)
- Deep Buffer はドロップが抑えられているが、処理時間が長かった
- 負荷が高くても Shallow (短い) Buffer のほうが、ジョブ完了時間が短かった
- PFC のみ有効だと、InDiscards が増加し、OutDiscards は発生しない
予想通りだった検証結果
- ECN を設定すると Drop がほぼ抑えられた
- Deep Buffer よりも速く完了した
今後のアクション
- Deep Buffer は必要ないかも
Day3
自作k6 Extension利用した NFVへの負荷計測手法の紹介
MVNO は HSS , PGW-C , PGW-U を BB Sakura で自作している。
「パフォーマンス測定ツールがなければ、作ればいいじゃない」
github に公開中。
知っておくと小回りがきく Ansibleの使い方
ansible-playbook 実行時に、-e (--extra-vars) +"@" を使う
- 外部ファイルを指定して実行すると良い感じ
YAML 記述に中括弧 "{}" とカンマ "," を使う
- Juniper の display set コンフィグみたいになるので見やすい
OpenStack on L3 Clos-NW First-Hop Redundancy by Open vSwitch & BGP in Yahoo! JAPAN network.
次世代OpenStack NFV基盤の検証
IPv6 シングル スタック環境で構築する OpenStack 基盤のナレッジ。
IPv6 ND RA と DHCPv6 ってややこしいよね・・・
BIGLOBE AS2518をまるごと仮想環境へ”コピー”してみた
All 実機では難しい商用 NW を仮想環境で再現して、「NW 全体の動作を」「実際にやって確認」したい。
BIGLOBE
DC 10 拠点、L2SW / Router で 50 台以上、3.2Tbps 以上、ピア数 220 以上。
月 20 件程度の作業に対して、障害を防ぐためのレビュー多すぎ問題がある。
- ベテラン -> マネージャー (-> 部長)
構成図を最新に保つことが難しい。
仮想環境の作成
商用環境のコンフィグを吸い出して、コンテナ NOS を生成する仕組みを構築し、テストベッドを使えるようにする。
- iperf ノードや監視システムも同時にデプロイされる
- iperf は商用のフローデータから、プレフィックスごとの流量を再現させた
仮想環境で確認できたこと
show コマンドやトラフィック断の有無などは、仮想環境で確認でき、レビュー者の負担が減らせた
仮想環境できなかったこと
Juniper の cPRD に統一したが、Cisco ルータの挙動は確認できていない。
PNI は適用可能だが、IX / Transit ピアは非定型で対応できていない。
外部 AS も再現したいが、コンフィグが無い。
- 再現に必要な情報を別途与える
コンフィグのデフォルメと網羅性の両立が難しい。
- 商用コンフィグはデカすぎて扱うのがつらい