「2025-07-30-08-01 JANOG56 参加レポート」の版間の差分

提供：hkatou_Lab
ナビゲーションに移動 検索に移動
← 古い編集
ビジュアルウィキテキスト
編集の要約なし
 
(同じ利用者による、間の14版が非表示)
9行目: 9行目:
[https://www.janog.gr.jp/meeting/janog56/wp-content/uploads/2025/07/JANOG56_AIML%E5%9F%BA%E7%9B%A4%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B800GbE%E3%82%B9%E3%82%A4%E3%83%83%E3%83%81%E5%B0%8E%E5%85%A5%E3%81%A8%E3%81%9D%E3%81%AE%E6%8C%91%E6%88%A6.pdf 資料]
[https://www.janog.gr.jp/meeting/janog56/wp-content/uploads/2025/07/JANOG56_AIML%E5%9F%BA%E7%9B%A4%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B800GbE%E3%82%B9%E3%82%A4%E3%83%83%E3%83%81%E5%B0%8E%E5%85%A5%E3%81%A8%E3%81%9D%E3%81%AE%E6%8C%91%E6%88%A6.pdf 資料]


=== 既存が 400G スイッチで、800G スイッチを追加導入 ===
==== 既存が 400G スイッチで、800G スイッチを追加導入 ====
400G で増設 or 800G 導入
400G で増設 or 800G 導入


16行目: 16行目:
** 混在構成で行けないか ?
** 混在構成で行けないか ?


=== 400G / 800G 混在の課題 ===
==== 400G / 800G 混在の課題 ====
OS / ASIC が別
OS / ASIC が別


27行目: 27行目:
* NCCL_CROSS_NIC = 0 で NIC を使用すると同じ Ring で同じ NIC ポートを使用
* NCCL_CROSS_NIC = 0 で NIC を使用すると同じ Ring で同じ NIC ポートを使用


=== 性能劣化発生 ! ===
==== 性能劣化発生 ! ====
Spine - Leaf に想定よりも多くのトラフィックが
Spine - Leaf に想定よりも多くのトラフィックが


34行目: 34行目:
NIC の見え方 (例:enp64s0) がサーバの種類で異なる
NIC の見え方 (例:enp64s0) がサーバの種類で異なる


=== 物理系の話 ===
800G 64 ポートスイッチを 800G x1 -> 400G x2 へブレークアウト接続して、400G 128 ポートスイッチとして使用
MPO ケーブルとトランシーバのプルタブが干渉、MPO 抜栓時にトランシーバも抜けてしまった
ポート番号が分かりづらい
* 上段は若番が左側に、下段は若番が右側に
===== 1U MPO-12 32 ポートは高密度すぎる =====
* SN-MT コネクタで小型化
* ポート密度が 4 倍に
* ラック間ケーブル本数を半分に
* クリーナが別なのがつらみ
=== マルチベンダー Lossless ===
Dell SN4700 と Juniper QFX5240 を使用
* QFX5240 の Broadcom ASIC では Adaptive Routing (AR) 使用不可、Dynamic Load Balacing (DLB) を使用する
==== DLB の inactiveity-interval ====
長すぎる場合は負荷分散が弱く、短すぎると Reorder で順番が入れ替わってしまう
* 常に最良の結果を出せる値は存在しない
* 自動化される機能があれば採用したい
筆者注 : この機能は Juniper
=== 監視基盤 ===
QFX5420 / Junos : gNMIc でテレメトリーデータを取得 @ 2 秒間隔
SN4700 / Cumulus Linux : OpenTelemetry で取得 @ 2 秒間隔
* gNMIc は 15 秒間隔で採用できなかった
=== Q&A ===
GPU 間トラフィックの NVLINK でどこを通るのか、どうやって調べたのか ?
* NCCL のデバッグログを人の目で見て、気合で解析
検証機と予算はどのように確保している ?
* ベンダーさんから借用 or 予備機で検証環境を作る
少量の Loss があったほうがかえってパフォーマンスが高い場合もあるそうだが、テスト手法についてどのような展望を持っているか ?
* 今後議論していきたいところです
== [https://www.janog.gr.jp/meeting/janog56/rpki/ 経路ハイジャックに一撃、RPKI ROA] ==
資料
=== IPv4 枯渇 ===
2010 年頃に枯渇、APNIC では 103. から始まるアドレスを配布
/23 までならまだ申請で入手可能
2023/10 に返却されたアドレスの再利用を開始
連絡が取れず回収した PI アドレスもあり
=== 未使用 IP アドレスが勝手に使用されてしまう話 ===
JANOG49 で発表あり
* [https://www.janog.gr.jp/meeting/janog49/ipv4/ 帰ってきた「あなたのIPv4アドレス、狙われていませんか？」]
実際に使用されてしまった例あり
=== RPKI ===
経路ハイジャックで、/21 や /23 で他組織のアドレスを広報していた組織あり
* IRR の RADB に Customer Prefix として登録されてしまっており、フィルタをくぐり抜けていた
RPKI Origin Authorization (ROA) や Route Origin Validation (ROV) で検証する
* IRR Explorler や BGP.tools で ROA や IRR の登録状況を見ることができる
IP アドレスを持っている組織に確認し、AS0 ROA を発行し、インターネット上で広報されない、という動作を行った
* 悪意ある組織が瞬時に使用できなくなった
* 結構たくさんの AS で RPKI/ROA を導入していた
* 経路が残るところもあった
** ROV されていない広告 Path を抜けている
** 顧客から受信しちゃってる上流
** Invalid と直接ピアしている組織
ROA が間違っていると通信が止まってしまうため、変更は要注意
ENOG で JPNIC がガイドラインを発表済み
* [https://www.nic.ad.jp/doc/jpnic-01324.html RPKIのROAを使ったインターネットにおける不正経路への対策ガイドライン]
APNIC では、2020 年に未割り当て IP に AS0 の ROA を作成
* JPNIC も検討中
== [https://www.janog.gr.jp/meeting/janog56/ddos/ 2024~2025年末年始にDDoSと戦った人の交換会リターンズ] ==
航空会社や気象庁とかいろいろ攻撃を受けた件
== [https://www.janog.gr.jp/meeting/janog56/home-internet/ 集合住宅インターネットの"今"と"これから" 〜ホワイトペーパーから見える課題と展望〜] ==
[https://www.janog.gr.jp/meeting/janog56/nl-home-internet/ 資料]
業務で FTTH をやっているため、大体抑えている内容でした
=== サイバー旅館 ===
* 光回線 x3 , V-ONU x2 が引いてあるぞ !
* 聞いてみたら、女将さんはポカーン
==== フレッツの PPPoE が輻輳したので、VNE を始めて IPoE へ切り替え ====
* 週二回深夜作業を半年間、計 40 回くらい
* PPPoE はローミング事業者から原因不明の回答、事業の上でブラックボックスに見えていた
* AS も取得し、トラフィックの中身がわかるようになった
* 原価が見えるように
** トランジットや IX 事業者に価格交渉
** ローミング事業者の価格が適正か評価できるように
==== VNE / AS でツライこと ====
* トラフィック管理 -> すごい大変
* やんちゃな住人がマンション全体のサービス品質に影響
** Q : やんちゃな人に公平制御で帯域幅を下げると、文句を言ってくるのでは ?
** A : やんちゃな人は何をしても文句を言ってくるので、約款に基づいて説明している
* 24/365 で運用技術者を揃えるのは至難
* 経営層に説明するのが難しい
** 親会社が電力会社系でそこから経営層の人が降りてくる
** トランジットを変電所に例えたりするとヨシ !


= Day3 =
= Day3 =
== [https://www.janog.gr.jp/meeting/janog56/seu/ 宇宙線とネットワーク機器との戦い] ==
[https://www.janog.gr.jp/meeting/janog56/wp-content/uploads/2025/05/janog56-seu-shtsuchi-00.pdf 資料]
オフレコ プログラム。資料の内容は SNS などで公開 OK. 議論の内容はオフレコで、とのこと。
=== Arista EOS パリティ / ECC エラーハンドリング ===
==== パリティ付きメモリ ====
検出はできるが修正はできない
==== EOS の修正 ====
ハードウェアで SEU (Single Event Upset) を検知
EOS に割り込み処理
ソフトウェアで正しい値を特定
メモリ全体を修正
修正可能な場合はログを記録し、ハードウェアに書き込む
=== FPGA や ASIC のパリティ エラー ===
ログが記録されるが、連続して記録される場合はメンテナンス ウィンドウを取って再起動が推奨
Broadcom の ASIC ではエラーを検出する機能がある
=== 替え玉エリア ===
すげーたのしい !!!
やっぱ HW がすこ
== [https://www.janog.gr.jp/meeting/janog56/ddbr/ AI時代のバックボーンネットワーク：DDBRとスケールアウトネットワークアーキテクチャの商用化について] ==
[https://www.janog.gr.jp/meeting/janog52/carwb/ 前にやってた内容] とあんまり変わらない
複数キャリアで検証すると品質が高まっていいよね、とか
== [https://www.janog.gr.jp/meeting/janog56/sonic/ コミュニティ版SONiCをAI/ML基盤適用できるか探る] ==
[https://www.janog.gr.jp/meeting/janog56/wp-content/uploads/2025/06/janog56-%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E7%89%88SONiC%E3%82%92-AI_ML%E5%9F%BA%E7%9B%A4%E9%81%A9%E7%94%A8%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%8B%E6%8E%A2%E3%82%8B-%E4%B8%AD%E9%87%8E%E5%AF%9B%E4%BA%8C-1.pdf 資料]
=== 負荷分散技術 ===
Enhanced ECMP
Adaptive Routing Switching
== [https://www.janog.gr.jp/meeting/janog56/autoverification/ “自動化やってみた”のその先へ ～KDDIネットワーク検証の自動化、現場エンジニアの奮闘と学び～] ==
[https://www.janog.gr.jp/meeting/janog56/wp-content/uploads/2025/05/JANOG56_%E8%87%AA%E5%8B%95%E5%8C%96%E3%82%84%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F%E3%81%AE%E3%81%9D%E3%81%AE%E5%85%88%E3%81%B8%EF%BD%9EKDDI%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E6%A4%9C%E8%A8%BC%E3%81%AE%E8%87%AA%E5%8B%95%E5%8C%96%E3%80%81%E7%8F%BE%E5%A0%B4%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E5%A5%AE%E9%97%98%E3%81%A8%E5%AD%A6%E3%81%B3%EF%BD%9E.pdf 資料]
80 件 320 人月 / 年の検証工数あり
= ブース =
== A10 ==
A10 Thunder ADC が LB 兼 DNS キャッシュサーバで動作するらしいので、色々聞いてみました。
数万規模のユーザでも TH1060S で足りる、ただ帯域幅ライセンスに注意で、使用できる CPU コア数が異なるとのこと。
[[カテゴリ:イベント]]

2025年8月6日 (水) 10:08時点における最新版

キーワードをこのレポートにメモったので、今後見直して反芻していきたい。

Day1

不参加。

Day2

AI/ML基盤における800GbEスイッチ導入とその挑戦

資料

既存が 400G スイッチで、800G スイッチを追加導入

400G で増設 or 800G 導入

  • 800G で決定
  • 400G が余るのは避けたいため、有効活用したい
    • 混在構成で行けないか ?

400G / 800G 混在の課題

OS / ASIC が別

負荷分散のメソッドをどうするか

  • ADaptive Routing / Dynamic Load Balancing

なるべく Spine を通したくない

  • NCCL_CROSS_NIC = 0 で NIC を使用すると同じ Ring で同じ NIC ポートを使用

性能劣化発生 !

Spine - Leaf に想定よりも多くのトラフィックが

  • NVIDIA DGX H100 と Dell XE9680 と 2 種類の GPU サーバを採用

NIC の見え方 (例:enp64s0) がサーバの種類で異なる

物理系の話

800G 64 ポートスイッチを 800G x1 -> 400G x2 へブレークアウト接続して、400G 128 ポートスイッチとして使用

MPO ケーブルとトランシーバのプルタブが干渉、MPO 抜栓時にトランシーバも抜けてしまった

ポート番号が分かりづらい

  • 上段は若番が左側に、下段は若番が右側に
1U MPO-12 32 ポートは高密度すぎる
  • SN-MT コネクタで小型化
  • ポート密度が 4 倍に
  • ラック間ケーブル本数を半分に
  • クリーナが別なのがつらみ

マルチベンダー Lossless

Dell SN4700 と Juniper QFX5240 を使用

  • QFX5240 の Broadcom ASIC では Adaptive Routing (AR) 使用不可、Dynamic Load Balacing (DLB) を使用する

DLB の inactiveity-interval

長すぎる場合は負荷分散が弱く、短すぎると Reorder で順番が入れ替わってしまう

  • 常に最良の結果を出せる値は存在しない
  • 自動化される機能があれば採用したい

筆者注 : この機能は Juniper

監視基盤

QFX5420 / Junos : gNMIc でテレメトリーデータを取得 @ 2 秒間隔

SN4700 / Cumulus Linux : OpenTelemetry で取得 @ 2 秒間隔

  • gNMIc は 15 秒間隔で採用できなかった

Q&A

GPU 間トラフィックの NVLINK でどこを通るのか、どうやって調べたのか ?

  • NCCL のデバッグログを人の目で見て、気合で解析

検証機と予算はどのように確保している ?

  • ベンダーさんから借用 or 予備機で検証環境を作る

少量の Loss があったほうがかえってパフォーマンスが高い場合もあるそうだが、テスト手法についてどのような展望を持っているか ?

  • 今後議論していきたいところです

経路ハイジャックに一撃、RPKI ROA

資料

IPv4 枯渇

2010 年頃に枯渇、APNIC では 103. から始まるアドレスを配布

/23 までならまだ申請で入手可能

2023/10 に返却されたアドレスの再利用を開始

連絡が取れず回収した PI アドレスもあり

未使用 IP アドレスが勝手に使用されてしまう話

JANOG49 で発表あり

実際に使用されてしまった例あり

RPKI

経路ハイジャックで、/21 や /23 で他組織のアドレスを広報していた組織あり

  • IRR の RADB に Customer Prefix として登録されてしまっており、フィルタをくぐり抜けていた

RPKI Origin Authorization (ROA) や Route Origin Validation (ROV) で検証する

  • IRR Explorler や BGP.tools で ROA や IRR の登録状況を見ることができる

IP アドレスを持っている組織に確認し、AS0 ROA を発行し、インターネット上で広報されない、という動作を行った

  • 悪意ある組織が瞬時に使用できなくなった
  • 結構たくさんの AS で RPKI/ROA を導入していた
  • 経路が残るところもあった
    • ROV されていない広告 Path を抜けている
    • 顧客から受信しちゃってる上流
    • Invalid と直接ピアしている組織

ROA が間違っていると通信が止まってしまうため、変更は要注意


ENOG で JPNIC がガイドラインを発表済み


APNIC では、2020 年に未割り当て IP に AS0 の ROA を作成

  • JPNIC も検討中

2024~2025年末年始にDDoSと戦った人の交換会リターンズ

航空会社や気象庁とかいろいろ攻撃を受けた件

集合住宅インターネットの"今"と"これから" 〜ホワイトペーパーから見える課題と展望〜

資料

業務で FTTH をやっているため、大体抑えている内容でした

サイバー旅館

  • 光回線 x3 , V-ONU x2 が引いてあるぞ !
  • 聞いてみたら、女将さんはポカーン

フレッツの PPPoE が輻輳したので、VNE を始めて IPoE へ切り替え

  • 週二回深夜作業を半年間、計 40 回くらい
  • PPPoE はローミング事業者から原因不明の回答、事業の上でブラックボックスに見えていた
  • AS も取得し、トラフィックの中身がわかるようになった
  • 原価が見えるように
    • トランジットや IX 事業者に価格交渉
    • ローミング事業者の価格が適正か評価できるように

VNE / AS でツライこと

  • トラフィック管理 -> すごい大変
  • やんちゃな住人がマンション全体のサービス品質に影響
    • Q : やんちゃな人に公平制御で帯域幅を下げると、文句を言ってくるのでは ?
    • A : やんちゃな人は何をしても文句を言ってくるので、約款に基づいて説明している
  • 24/365 で運用技術者を揃えるのは至難
  • 経営層に説明するのが難しい
    • 親会社が電力会社系でそこから経営層の人が降りてくる
    • トランジットを変電所に例えたりするとヨシ !

Day3

宇宙線とネットワーク機器との戦い

資料

オフレコ プログラム。資料の内容は SNS などで公開 OK. 議論の内容はオフレコで、とのこと。

Arista EOS パリティ / ECC エラーハンドリング

パリティ付きメモリ

検出はできるが修正はできない

EOS の修正

ハードウェアで SEU (Single Event Upset) を検知

EOS に割り込み処理

ソフトウェアで正しい値を特定

メモリ全体を修正

修正可能な場合はログを記録し、ハードウェアに書き込む

FPGA や ASIC のパリティ エラー

ログが記録されるが、連続して記録される場合はメンテナンス ウィンドウを取って再起動が推奨

Broadcom の ASIC ではエラーを検出する機能がある

替え玉エリア

すげーたのしい !!!

やっぱ HW がすこ

AI時代のバックボーンネットワーク：DDBRとスケールアウトネットワークアーキテクチャの商用化について

前にやってた内容 とあんまり変わらない

複数キャリアで検証すると品質が高まっていいよね、とか

コミュニティ版SONiCをAI/ML基盤適用できるか探る

資料

負荷分散技術

Enhanced ECMP

Adaptive Routing Switching

“自動化やってみた”のその先へ ～KDDIネットワーク検証の自動化、現場エンジニアの奮闘と学び～

資料

80 件 320 人月 / 年の検証工数あり

ブース

A10

A10 Thunder ADC が LB 兼 DNS キャッシュサーバで動作するらしいので、色々聞いてみました。

数万規模のユーザでも TH1060S で足りる、ただ帯域幅ライセンスに注意で、使用できる CPU コア数が異なるとのこと。

「http://hkatou.net/index.php?title=2025-07-30-08-01_JANOG56_参加レポート&oldid=2579」から取得