この記事では、2023年度現場受け入れ型インターンシップの活動内容をご紹介します。現場受け入れ型インターンシップを通して得られた学びを参考情報として共有します。 目次 目次 はじめに 参加に至った経緯 受け入れ先について インターンシップで取り組んだこと オンボーディング エラーハンドリングの追加 E2Eテストのデプロイ JavaScript用SDKに対する機能追加 感想 おわりに トレーナーからのコメント 参考文献 はじめに こんにちは、インターンシップに参加した 鈴木 誉写 です。大学院ではオーバーレイネットワークプロトコルの研究・開発を行なっています。 2023年8月28日から9月8日までの2週間、”オンライン英会話・オンライン医療などのビデオ通話を実現するプラットフォームサービス「 SkyWay 」の技術開発”というテーマで、NTTコミュニケーションズの現場受け入れ型インターンシップに参加しました。 この記事では、インターンシップに参加した経緯や活動内容について紹介します。 参考：現場受け入れ型インターンシップとは ドコモが仕掛ける数多くの事業の中から厳選したポストにて、実務を体験していただきます。業務体験を通じて通信/ICT業界の仕事が理解できるだけでなく、皆さん自身の成長をお約束する2weeksのインターンシップです。 現場受け入れ型インターンシップ | インターンシップ情報 | NTTドコモ採用 ❗ 2022年に行われたNTTドコモ・NTTコミュニケーションズ・NTTコムウェアの統合により、本インターンシップの受け入れ先はNTTコミュニケーションズですが、募集はNTTドコモを経由しています。 参加に至った経緯 これまでは競技プログラミングに取り組んでいたり、ワークショップ型のインターンシップに参加したことがあったりと、楽しみながら技術力を向上させる機会は多くありました。しかし、これらの経験だけでは、エンジニアとして働く環境にはどのようなものがあるのかを知ることができないと感じていました。 そんな中で、NTTコミュニケーションズの現場受け入れ型インターンシップが目に留まりました。このインターンシップなら、ワークショップ型のインターンシップと比べて、より現場のリアルを体感できます。そのため、本インターンシップなら技術的成長のみならず、社会から求められる力や観点を学べると考え、応募しました。 受け入れ先について 募集要項は、以下のようなものでした（2023年9月21日時点）。 17.オンライン英会話・オンライン医療などのビデオ通話を実現するプラットフォームサービス「SkyWay」の技術開発 ●業務内容 以下の業務を体験していただきます。 ・SkyWayの新機能: 録画・録音/通話品質計測/IoT向けSDKなどの開発 ・SkyWayが提供するJavaScript/iOS/Android SDKのアジャイル開発 ・ビデオ通話機能を実現するサーバ群の機能開発 ・WebRTCの技術情報のリサーチ 詳細はご本人の希望・適正に応じて、決定します。 SkyWayに関しては https://skyway.ntt.com/ を参照ください ●応募要件 【必須】 ・下記いずれかの言語を用いたプログラミング経験が半年以上あること →HTML/CSS/JavaScript, Swift, Kotlin, Java, C++ ・リアルタイムコミュニケーションに興味と学習意欲を持っていること ・エンジニアリングへの興味・関心が高いこと ・プロダクトを見据えたソフトウェア開発を行う意欲があること ・新機能開発に興味があること ・Github/GitLab/BitBucketなどのソースコード管理システムを利用した開発の経験、もしくは知識があること 【推奨】 ・WebRTC/WebSocketなどのリアルタイム通信に関する知識があること ●受け入れ会社 NTTコミュニケーションズ株式会社 ●勤務地 〒108-8118 東京都港区芝浦3-4-1 グランパークタワー 現場受け入れ型インターンシップ | インターンシップ情報 | NTTドコモ採用 SkyWayとは、リアルタイムコミュニケーションを実現するプラットフォームサービスです。SkyWayは、 WebRTC の利用に必要な機能を提供し、サービス開発をサポートします。これにより、ソフトウェア開発者は、自身のアイディアの実現に集中できるようになります。 SkyWayを開発している組織は、ビジネス領域・開発領域・運用領域の全てを取り仕切っています。また、担当する業務のドメインや開発物に応じて、内部的に複数のチームに分かれており、相互に連携して開発を進めています。本インターンシップでは、リアルタイムコミュニケーション用サーバやJavaScript用SDKの開発・運用を行なっているチームに受け入れていただきました。 リアルタイムコミュニケーション用サーバは、一般的なWebアプリケーションサーバで求められる要件に加え、高い安定性やパフォーマンスといった観点も要求されます。また、SDKはお客さまが直接使うものであるため、開発体験の良さも求められます。今回受け入れてくださったチームでは、これらの観点も考慮しながらシステムを開発・運用していました。 インターンシップで取り組んだこと オンボーディング SkyWayのサーバサイドアプリケーション開発では、主にTypeScriptを利用しています。一方、私は選考時点でTypeScriptを書いたことがなく、その旨を社員の方に共有していました。そのため、オンボーディング用課題を提示していただきました。 この課題は、npmパッケージの名前を受け取り、そのインストール数などに基づいて、インストールしても大丈夫そうか否かを返答するAPIを開発するものでした。まず、APIの設計やドキュメンテーションを体験しました。その後、TypeScriptの基本をご指導いただきながら、コーディングを進めました。さらに、テストコードを書く経験を通して、 describe ・ test の挙動や、 beforeAll ・ beforeEach ・ afterAll ・ afterEach の働きを学びました。加えて、初歩的なCI/CDの構築を体験しました。作成したコードは こちら で公開しています。ローカル環境での動作例は以下のとおりです。 <サーバサイド> $ npm run start > npm-checker@1.0.0 start > node build/main.js Server listening at http://0.0.0.0:8080 Package Name: react Repository: facebook/react Last Modified: Sat Sep 23 2023 01:15:32 GMT+0900 (日本標準時) Count of Download: 85877299 Contributors: zpao, gaearon, acdlite, sophiebits, sebmarkbage, jimfb, trueadm, bvaughn, petehunt, chenglou, vjeux, benjamn, yungsters, lunaruan, subtleGradient, kassens, gnoff, rickhanlonii, nhunzaker, necolas, syranide, eps1lon, cpojer, flarnie, koba04, aweary, mondaychen, dependabot[bot], marocchino, kohei-takata <クライアントサイド> $ curl -X POST -v http://localhost:8080/check-package/react * Trying 127.0.0.1:8080... * Connected to localhost (127.0.0.1) port 8080 (#0) > POST /check-package/react HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.79.1 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < content-type: application/json; charset=utf-8 < content-length: 28 < Date: Mon, 25 Sep 2023 08:11:14 GMT < Connection: keep-alive < Keep-Alive: timeout=72 < * Connection #0 to host localhost left intact {"can_use":true,"reason":""}% エラーハンドリングの追加 次なる業務として、SkyWayで稼働しているサーバにおいてハンドリングが漏れていたエラーに対処するというタスクに取り組みました。まずは、既存のコードを読み、課題が残されている箇所の理解を深めました。コードを読む中で、今まで触れてこなかった"階層型アーキテクチャ"や"DI"の概念を学びました。その後、適切にハンドリング処理を追加しました。コーディングはペアプロの形式で実施したため、実践的な知識を得る良い機会になりました。結果的に、修正を加えた箇所は無事マージされました。 E2Eテストのデプロイ 今回私を受け入れてくださったチームは、DevOps 1 の思想に準拠し、SkyWayの開発のみならず運用も担っています。そのため、サーバの状態を監視したり、検出した異常な挙動を報知したりする機構を管理しています。E2Eテストとは、その一環で利用する、SkyWayを用いたE2E通信の実施可否を定常的に確認するシステムです。下図のように現在時刻を画面に描画し、それをリアルタイムで送受信することで、エンドユーザ目線からSkyWayサーバの稼働状況を確認できます。 今回は、E2Eテストにて利用するSDKのバージョンをアップデートした後、デプロイ作業を実施しました。このような本番環境を扱う作業は、手違いが無いよう複数人で実施します。今回は、私もその一員として参加させていただきました。その結果、開発と運用の両面を担うチームの働き方を実感できました。 JavaScript用SDKに対する機能追加 多くのブラウザは、通信環境などの統計情報を取得するWebRTCのAPIを備えています。この統計情報をサーバに集約することで、お客さまサポート時のログ解析などに活用できるようになります。そこで今回は、SkyWayのJavaScript用SDKパッケージから統計情報を受け取り、それらを整形した上でサーバに送信するサポートパッケージを開発しました。この業務の遂行にあたり、本パッケージに必要な機能の洗い出しから参加させていただきました。 コーディングに際しては、通信が失敗した際に再送の有効性に応じて処理が分岐する複雑なロジックに苦戦しました。また、Utility Typesの利用や、以前に送信したデータに依存性がある処理といった、テクニカルな実装が求められる場面もありました。しかしながら、インターンシップ開始時点でTypeScript未経験だったのにもかかわらず、最終的には開発を自走できました。このことを通じて、 社会人基礎力 の一端である主体性や実行力の向上を感じられました。そのため、"現場を体感することで社会から求められる力や観点を学ぶ"という、本インターンシップの目的を達成できました。 感想 CI/CDの構築方法やTypeScriptの便利記法など、多くの技術的な成長を感じられた2週間でした。さらに、社員の方々と共に働いたことで、エンジニアの働き方についても多くの学びを得ることができました。例えば、タスクの重み付けの考え方や、TeachingとCoachingの使い分けなどです。これらの学びは、今後もぜひ活かしていきたいと感じました。 加えて、自分の弱点が明らかになった2週間でもありました。社会に出る前に自身の弱点を自覚できたことは、今後の成長の足がかりとして、とても有意義であったと感じます。 おわりに 本記事は、2023年度現場受け入れ型インターンシップの参加記として、活動内容や感想について書かせていただきました。 親身にサポートしてくださったトレーナーのsublimerさん、暖かく出迎えてくださったイノベーションセンターならびにSkyWayチームの皆さま、成長機会をくださったNTTコミュニケーションズの皆さま、大変学びの多い2週間をご提供いただき、本当にありがとうございました。 トレーナーからのコメント 鈴木さんのトレーナーを担当した、イノベーションセンターの @sublimer です。 鈴木さん、2週間のインターンシップ、お疲れ様でした。 2週間というとても短い期間、かつ、TypeScript未経験という状況で、本当に素晴らしい成果を残してくれたと思っています。 TypeScriptを書いた経験が無いことは事前に伺っていたので、今回のインターンシップでは最初の数日間で学習用の課題に取り組んでいただきました。 学習用の課題は、ゴールを「必須」、「ここまでできるとGood」、「できなくても大丈夫」の3段階に分けて設定し、とりあえず必須のゴールだけ達成できれば業務に取り組めるように設計していました。 しかしながら、鈴木さんには「できなくても大丈夫」のゴールまで達成していただき、スキル習得のスピードにとても驚かされました。 また、インターンシップ後半では、今後リリース予定のSkyWayの新機能開発に取り組んでいただきました。 SDKの機能をゼロから実装していくという業務は、社員でもなかなか経験できるものではないため、苦労した点も多かったかもしれません。 そのような業務にも臆することなく取り組み、短い期間で大きな成果を残していただきました。 通信の状況を収集、記録する機能は、お客さまがトラブルシューティングする際に役立つ、非常に重要な機能になると考えています。 鈴木さんが書いたコードは今後お客さまのサービスに組み込まれ、多くのリアルタイムコミュニケーションを支える機能の一部となります。 リリースされるのはもう少し先ですが、楽しみにしていただければと思います。 最後になりますが、この2週間の経験が鈴木さんの今後の人生に少しでも役立つものとなれば、トレーナーとしてとても嬉しく思います。 そして、今後の研究活動、大学院生活がより充実したものになることを祈っています。 SkyWayでのインターンシップのご参加、ありがとうございました!! 参考文献 Bass, Len, Ingo Weber, and Liming Zhu. DevOps: A software architect's perspective. Addison-Wesley Professional, 2015. ↩

イノベーションセンターの三島と深川です。 普段の業務では、Segment Routing を始めとする経路制御技術や、IPFIX や Streaming Telemetry などの監視技術の検証・運用、高速ソフトウェアルーター「Kamuee」の開発をしています。 今回、我々は 2023/07/22-28 に行われた、IETF 117 に参加しました。 この記事では、IETF 117 の参加を通じて得た経験や現地の様子、各 WG の動向などをご紹介します。 IETF (Internet Engineering Task Force) とは IETF は、インターネット技術の標準化を推進する団体です。 標準化の議論は Working Group (WG) 単位で推進され、主にメーリングリストを通じて議論が行われます。 メーリングリストは誰でも閲覧・参加が可能です。 また、標準化された技術は Internet-Draft (I-D) や Request for Comments (RFC) などとして広く公開されます。 IETF では、年に3回のオンサイトでの会議があり、直近では以下のような日程・開催地となっていました。 (基本的に、アジア/オセアニア・北米・ヨーロッパで、それぞれ1回ずつ開催されます。) オンサイトのミーティングも参加条件はなく、誰でも参加できます。(有料) 2023/03: IETF 116: Yokohama 2023/07: IETF 117: San Francisco 2023/11: IETF 118: Prague 2023/03: IETF 119: Brisbane IETF 116 が2015年7月以来の7年半振りに日本(横浜)で開催されたこともあり、 我々2名は IETF 116 にて初めてオフラインでの参加をしました。 (出典: https://www.ietf.org/) IETF 117 (San Francisco) は、サンフランシスコの中心地にある Hilton San Francisco Union Square で開催されました。 IETF 117での参加セッション 以下では、我々が現地で参加したセッションをいくつかご紹介します。 IETF 117 の全スケジュールはこちら： IETF 117 Meeting Agenda IETF のオンサイトミーティングならではの用語は こちらのページ で紹介されています。 Day1-2: Hackathon IETF のオンサイトでの会議では、本会議である Meeting Week に先んじて2日間の Hackathon が開催されます。（Pre-Meeting Weekend Session） Hackathon では、集まった多くの開発者や専門家が、アイデアや便利なツール、標準化にあたっての running code 開発、相互接続性を検証するための場です。 今回我々は、「IPFIX Exporter w/eBPF」というテーマで、OSS の IPFIX exporter である「 Fluvia Exporter 」を用いた Hackathon を行いました。 Fluvia Exporter は、IETF 116 Hackathon にて開発を開始した、OSS の IPFIX exporter です。 IETF 116、117 での開発を通じ、opsawg の 2つの I-D ( Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) / Export of On-Path Delay in IPFIX ) に準拠しています。 IETF 117 では　opsawg の方々と協力して相互接続検証を行い、無事に動作させることができました。 draft-ietf-opsawg-ipfix-srv6-srh-14 Hackathon 期間中以外でも継続的に opsawg の方々とコンタクトをとりながら実装を進めていました。 今回の Hackathon では、I-D にはまだ記載されていなかったパラメータなどもその場で議論しながら値を決めるなど、現地で参加したからこそできたことが多くありました。 図は、我々が作成した Hackathon での最終報告資料 です。 今回の Hackathon では、SRv6 機能の開発や他の実装 (pmacct・Wireshark) との相互接続を完遂できました。 また、フロー毎の hop-by-hop な遅延 (On-Path Delay) の取得機能についても開発を開始しました。 こちらは Hakacthon 中には完了できませんでしたが、その後も相互接続を目指し実装を進めております。 対応したそれぞれの I-D の詳細については、"Day3-7: WG session" の章でご紹介します。 また、Fluvia Exporter のより詳しい開発背景や設計・実装手法については、 ENOG79 SRv6 対応の IPFIX exporter を開発した話 をご覧ください。 Day3-7: WG session Day3 以降に行われた Meeting Week において、我々が参加した WG session の中から特に面白かったものを抜粋してご紹介します。 他の WG session を含め、全てのスライドや I-D などの資料は IETF 117 の Agenda ページ から確認できます。 Operations and Management Area Working Group (opsawg) opsawg は運用や管理に関する技術を扱う WG です。 特に、既存の WG の範囲外、もしくは新しい WG を作るほどではない「運用と管理」に関するトピックについて議論し、RFC としてまとめることを目的としています。 この opsawg WG の中で特に我々が注目している技術は、YANG・Telemetry・xFlow などの運用監視に使われるプロトコル群です。 ここでは、Hackathon の項目でも触れた2つの I-D の内容を紹介します。 1つめは Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) です。 この I-D は IPFIX で SRv6 の SRH を扱うための新たな Information Element (IE) を提案しており、SRv6 SRH に含まれる Segment List や Segment Left、また Active Segment の情報などさまざまな値を表現可能にしています。 2つめは Export of On-Path Delay in IPFIX です。 この I-D は、On-Path Delay を取得するための手法を提案しています。 遅延の取得は、機器の持つ Timestamp と、 In-situ OAM (IOAM) で得られるパケット送出時の Timestamp の差を取ることで実現されます。 計測した Timestamp は、フロー毎に IPFIX の IE に格納し送出されます。このように、ネットワークの中間ノードから情報を取得することを、 On-Path Telemetry と呼びます。 上図に、2つの I-D の技術を用いた、SRv6 網における遅延取得手法を示しました。 計測対象となるパケットには、SRv6 の Headend ノードにて Direct EXport (DEX) の option Type で Timestamp が有効になった IOAM ヘッダが付与され、送出時の Timestamp が格納されます。 IOAM ヘッダの付与手法は複数提案されていますが、Timestamp を付与する場合、2023/10 時点では IPv6 の拡張ヘッダに付与する実装のみ存在します。 IOAM ヘッダのついたパケットを受け取ったノードは、受信時の Timestamp との差 (D1-D3) を取得した後、フロー毎に統計処理し、IPFIX によりエクスポートします。 これにより、フロー毎に hop-by-hop な遅延を取得できます。 似た技術として SRv6 を用いて hop-by-hop の遅延情報も取得可能な SRv6 Path Tracing がありますが、 On-Path Delay は、IOAM が提案しているIPv6/MPLS/Geneve/VXLAN-GRE など、さまざまなプロトコルに適用できる利点があります。 我々は multi-AS SR 網で SRv6/SR-MPLS の双方を運用しているため、幅広いプロトコルに適用できる可能性を持つ On-Path Delay に期待しています。 これらの IPFIX 拡張の活用例の1つとして、opsawg のメンバーにより、Applied Networking Research Workshop 2023 (ANRW '23) にて SRv6 ネットワークのアノマリ検知の成果が発表されていたので、次の章でご紹介します。 Applied Networking Research Workshop 2023 (ANRW '23) ANRW は ACM/IRTF によるワークショップであり、IETF で議論されたトピックや課題に関連する研究成果を発表するための場です。 年1回、7月の IETF と併催されており、ANRW '23 は IETF 117 の Day3 に開催されました。 我々は、共に Hackathon を行った opsawg の方から、「Daisy: Practical Anomaly Detection in large BGP/MPLS and BGP/SRv6 VPN Networks」 1 を紹介され、興味を持ったため参加しました。 Daisy では、SRv6 ネットワークを Data-plane・Control-plane・Management-plane の3面で扱い、それぞれの metric を取得します。 各面の metric 取得手法として、Data-plane は Hackathon の項目でも紹介した IPFIXを、Control-plane は BGP Monitoring Protocol (BMP) を、Management-plane は YANG Push ( RFC8639 、 RFC8641 ) をそれぞれ用います。 最終的にはそれぞれの面で集めたメトリックを用いアノマリ検知を目指しており、そのために不足するプロトコルの標準化を行なっています。 Daisy は、SRv6 で metric を取得する手法をプレーン毎に整理し、それぞれで不足する項目を明らかにして標準化に繋げている点が IETF らしい面白い取り組みであると感じています。 我々の SRv6 ネットワークにおける活用も視野に、今後も注目していきたいと思います。 IPv6 Operations (v6ops) v6ops WG は IPv6の運用上の課題を解決することを目的とした WG です。 この WG では、主な目標として以下を掲げています。 IPv6 の運用上の問題を特定し、解決策や回避策を議論する IPv4 とのデュアルスタック環境における問題を特定し、解決策・回避策を議論する IPv6 シングルスタック環境における問題や、IPv6 によるイノベーションについて議論する 運用上の解決策を生み出し、BCP(Best Current Practice)の形で文書化する IPv6 の運用要件を文書化する v6ops WG では、ルーティングプロトコルやDNSの運用などのIPv6の運用と展開に関連する議論も扱うこととなっています。 IETF118 において発表が行われた中から、我々が注目している I-D を2つ紹介します。 1つめは Using DHCP-PD to Allocate Unique IPv6 Prefix per Device in Broadcast Networks です。 この I-D では、1つのノードが内部的に複数の IPv6 アドレスを用いる際、DHCPv6-PD を利用し、そのノードにユニークな IPv6 プレフィックスを割り当てるアプローチを提案しています。 通常、特定のセグメントに接続されたデバイスは、同一のプレフィックスから IPv6 アドレスを生成しますが、本提案ではデバイスは DHCP-PD クライアントとして動作し、DHCPv6-PD を介してプレフィックスを要求します。 クライアントに割り当てられたプレフィックスは、クライアントのリンクローカルアドレスを指すルートとしてファーストホップルータの経路表にインストールされます。 このアプローチにより、あるインターフェースに対する複数アドレスの付与、仮想環境のホスティング、テザリングでのネットワーク提供など、さまざまなユースケースにおける複数の IPv6 アドレスの管理を効率的に実現できます。 2つめは、 IPv6 only iterative resolver utilising NAT64 です。 この I-D は、NAT64 を活用した IPv6 シングルスタック環境において DNS リゾルバーを構成する際の注意点や、修正すべき項目について提案しています。 現在の RFC3901(BCP91) では、リゾルバーは IPv4-only もしくは dual stack であるべき(SHOULD)としていて、IPv6シングルスタック環境ではこの SHOULD の要件を満たすことができません。 また、名前解決の問い合わせ先となる権威サーバも、IPv6で到達できなかったり、A レコードしか登録されていないことが多々あります。 このドラフトでは特に、上記のような前提では IPv6 シングルスタックの環境下で自前のリゾルバーを運用できないという問題に着目し、NAT64 を用いて解決するためのアプローチについて提案しています。 Source Packet Routing In NetworkinG (spring) spring WG は、セグメントルーティング (Segment Routing: SR) と呼ばれる Traffic Engineering (TE) 技術の標準化と拡張を目的とする WG です。 Segment Routing を実現するデータプレーン技術として、MPLS(SR-MPLS)、IPv6(SRv6) の両者について議論が行われています。 この WG では、SR の運用・管理・TE について扱うだけでなく、他のプロトコルとの相互運用についても議論が行われています。 その中で、特に面白かったものとしては、 Problem statement for Inter-domain Intent-aware Routing using Color があります。 この I-D では、複数の AS 同士の SR 網を相互接続することを目的とし、AS を超えて VPN を構成するための Inter-AS option の選び方や、各 AS の Intent を伝えるために考慮すべき点をまとめています。 特に AS 超えた Intent の適用については、 我々の multi-AS SR でも行っているような BGP Extended Communicty Color を用いる方法についてもまとめられており、Inter-AS についてリファレンスするための良い I-D になっています。 また、もう1つのトピックとしては Service Function Chaining (SFC) に関連した I-D が2つ扱われていました。 1つめは SRv6 Context Indicator SIDs for SR-Aware Services で、SRv6-aware な Network Function に対し、処理のコンテキストを新たな Endpoint behavior を用いて伝える手法を提案しています。 2つめは A Framework for Constructing Service Function Chaining Systems Based on Segment Routing で、 Service Function Chaining Architecture (RFC7665) に沿う形で、SR を用いた SFC のアーキテクチャを整理しています。 SFCについては、我々のチームでも神奈川工科大学・ミハル通信株式会社との共同研究において SRv6 を用いた SFC を活用しているため、今後も注目していきたいと思います。 BGP Enabled ServiceS (bess) bess WG は MP-BGP を用いたサービスについての標準化を行なっている WG です。 主要なターゲットは、L3VPN・L2VPN などの VPN 技術であり、データセンターネットワークにおける BGP を用いた VPN のスケーラビリティや DC 環境特有のメカニズム、VPN 技術を用いた SFC (Service Function Chaining) 等のサービスをサポートするオーバーレイのトポロジの構築なども対象としています。 また、bess WG では、データプレーンでのカプセル化については直接扱わないことになっています。 面白かった内容としては、VPN の Inter-AS option BC を標準化するための I-D ( VPN Inter-AS option BC ) が提案されていました。 VPN Inter-AS option は、異なる AS 間で VPN を相互に接続するための技術であり、 RFC 4364 で標準化されています。 この RFC の Section 10. では、接続手法を a)-c) の3種に分類しています。 a) AS 間で VRF 同士を接続することで、VPN を接続する手法 b) eBGP で VPN 経路を広告することで、隣接する AS との間でも VPN を構成し、E2E な VPN を疎結合に接続する手法 c) 各 AS の RR 間で、multi-hop eBGP により VPN 経路情報を交換することで、AS を超えた E2E の VPN を構成する手法 上記の RFC から、一般にそれぞれの方法を Inter-AS option A、option B、option C と呼称します。 図解を添えた 各 option の詳しい解説は [Multi-AS Segment Routing 検証連載 #2] SR-MPLS L3VPN in Multi-AS でも解説しています。 一方、今回提案された option BC では、option B のように ASBR 間で VPN を接続しつつ、option C のように E2E な VPN を構築します。 option BC は、option B のように AS 毎に SID の 名前空間を分離した NW の作成が実現できます。 ただし option BC では、option C のように E2E で SR Policy を作るというようなことはできないため、あくまで疎結合な Inter-AS のユースケースにのみ適していると感じています。 Post-Quantum Use In Protocols (pquip) pquip WG は量子コンピュータに耐性を持つ暗号 (PQC: Post Quantum Cryptography) の適用に関する支援を目的としたワーキンググループです。 従来の暗号が量子コンピュータによって破られる可能性が高いため、PQC の導入とその運用ガイダンスを作るのが主な目的です。 具体的には、 Post-Quantum Cryptography for Engineers などの I-D が出されており、PQCの運用や導入のベストプラクティスを文書としてまとめています。 他の WG とは異なり、既存のプロトコルを更新したり、暗号メカニズムを定義・評価するワーキンググループではないというのが特徴です。 Side Meetings and Private Meetings Side Meeting とは、WG session とは別に開催される有志によるミーティングです。 IETF 公式が用意した Wiki にて募集する Public Side Meeting と、随時開催する Private Side Meeting の2種が存在します。 今回我々は、Hackathon の場で取り組みに興味を持って頂いたエンジニアや、NTT Com の業務に関連する US のエンジニアとの間でセッション外での Side Meeting やランチセッションを複数行いました。 業務内容に関わるものもあるため内容は割愛しますが、今後に繋がる話も生まれたため、現地に参加するメリットの1つであったと感じています。 Day4: IETF 117 Social Event IETF Social は、IETF の参加者に向け、主催者から有料で提供される懇親の場です。 IETF 117 Social は Nokia 主催で、サンフランシスコ近代美術館 (San Francisco Museum of Modern Art、SFMoMA) で行われました。 会場では飲食物も提供され、他のエンジニアと自由に交流できます。 また近代美術館での開催ということで、2F に展示された一部の作品を自由に見ることができました。 Social の場でも I-D に関する今後の実装や共同研究等について他のエンジニアと議論でき、とても有意義な会になりました。 Day7: IETF終了後 - (NTT Research, Inc.)訪問 今回会場となった San Francisco 市内から 車で南に 30分〜1時間程進むと、シリコンバレーがあります。 我々は、IETF 117 終了後にシリコンバレーの SunnyVale にある (NTT Research, Inc.) を訪問しました。 NTT Reaserch は、シリコンバレーに拠点を持つ企業で、暗号学・物理学・医療情報学などさまざまな分野の基礎研究を目的とする組織です。 オフィスでは現地での取り組みや研究内容についてご説明いただきました。 また、すぐ近くには Apple をはじめとするビッグテックのオフィスが多数あるので、帰国前に立ち寄ることができました。 参加してみての感想と今後について 今回、IETF 117 に参加してみての感想として2つのことを感じています。 1つめは現地でのコミュニケーションの重要性についてです。 今回の IETF では、Hackathon や Private Side Meeting を通じて、現地のエンジニアと議論ができました。 どちらの取り組みでも今後の標準化や PoC の実施などにつながる話を得ることができ、リモートからの参加ではなし得ない成果を上げることができました。 2つめは Hackathon の成果です。 IETF 117 Hackathon では、SRv6 IE の実装を実施し、無事に相互接続まで達成できました。計測したデータの具体的な活用手法や我々の活用案など、今後に繋がる話ができたのも良い点であったと感じています。 IETF Hackathon は 1日を通じ濃密なコミュニケーションをとることのできるいい機会であるため、ご興味のある方は是非参加をお勧めします！ 次回 IETF118 Prague の参加登録は 8/14 より開始済みです： IETF118 Register Early Birds の締切は 10/23 23:59 (UTC) なので、参加される方は忘れずにご登録ください。 おまけ🦀 IETF 117が開催されたサンフランシスコでは、ダンジネスクラブ(Dungeness Crab、アメリカイチョウガニ)が有名と聞いたので食べてきました🦀。 円安や世界的なインフレを鑑みても、特にベイエリアの物価は高かったですが、このカニはそれに見合うくらい美味しかったです。 Feng, A. H., Francois、P., Frenot, S., Graf, T., Du, W., & Lucente, P. (2023, July). Daisy: Practical Anomaly Detection in large BGP/MPLS and BGP/SRv6 VPN Networks。In Proceedings of the Applied Networking Research Workshop (pp. 8-14). ↩

はじめに こんにちは、ドコモグループのサマーインターンシップ2023に参加した河井です。 普段は大学院で暗号理論の研究をしています。 この記事では、私がこのインターンシップで取り組んだことについて紹介します。 セキュリティ系インターンシップに興味のある人の参考になれば幸いです。 はじめに NA4Sec PJの紹介 インターンシップ概要 脅威検証：攻撃インフラの秘匿 セキュリティに関するクローキングとは サーバ側のクローキングの実装 IPアドレスによるクローキング RefererとUser-Agentによるクローキング 脅威検証：攻撃インフラの構築 OAuth 2.0のデバイス認可付与（RFC8628）とは 認可フローを悪用した攻撃 フィッシング攻撃の検証 おわりに 参考文献 NA4Sec PJの紹介 まずは、私がお世話になったNA4Sec PJについて紹介します。 正式にはNetwork Analytics for SecurityというNTTコミュニケーションズ イノベーションセンターのプロジェクトチームであり、NA4Sec（なよせ）と呼ばれています。 NA4Sec PJは、インターネット上の攻撃インフラの解明・撲滅を目指して活動するプロジェクトです。 具体的には、サイバーセキュリティに関する情報の収集と分析・技術開発・人材育成を行っています。 インターンシップ概要 8/28から9/8までの約2週間、プロジェクトチームの一員としてセキュリティアナリストの仕事を体験しました。 この期間で、私は以下の4点のことに取り組みました。 脅威調査 Cobalt Strikeが何なのか理解する。 脅威分析 Cobalt Strikeが使われた攻撃事例に関するインシデントレポートをダイヤモンドモデルに基づいて分析する。 脅威探索 インターネットスキャナ系検索ツールCensysを使ってインターネット上のC2サーバを見つける。 脅威検証 以下の攻撃インフラに関わる技術について理解する。 攻撃インフラの秘匿に使われるクローキング技術 Dynamic Device Code Phishingと呼ばれるフィッシング攻撃手法 脅威調査・分析・探索については前回のインターンシップに参加された方が紹介されていますので 1 、ここでは脅威検証について紹介しようと思います。 脅威検証：攻撃インフラの秘匿 私は脅威検証として今回、 サーバ側のクローキング技術の検証 に挑戦しました。 セキュリティに関するクローキングとは クローキング(cloaking)は、もともとは「マントを着せる」「覆い隠す」といった意味の単語ですが、そこから転じて「攻撃インフラの秘匿のために使われる技術」を指す用語として使われるようになりました。 フィッシングサイトやマルウェアダウンロードサイトにおいて使われることが多いです。 この記事におけるクローキングの定義は次の通りです。 攻撃対象者には悪性挙動を示し、それ以外には非悪性（良性）挙動を示すことで攻撃の発見を遅らせたり、回避したりする技術 図1 クローキングをする攻撃者 クローキング技術について、攻撃対象者とそれ以外を判別するために使われる情報の例を以下にまとめます。 クローキング技術の実装箇所 利用する情報 活用方法 攻撃者のサイトを閲覧したクライアント OSやブラウザの情報 攻撃対象者かどうか知る マウスの動き 人が操作しているかどうか知る 画面・ウィンドウのサイズ、CPUのコア数 仮想環境（検証環境）かどうか知る 攻撃者のサーバ IPアドレス 特定のIPアドレスからのアクセスを遮断する User-Agent 攻撃対象者かどうか知る Referer 例えば、ブラウザの検索結果からアクセスしてきたユーザだけを狙う サイトにアクセスした回数 初回のアクセス時のみ悪い挙動を見せる （IPアドレスやCookieの情報を使う） サーバ側のクローキングの実装 今回のインターンシップでは、攻撃者のサーバ側で動作するクローキング技術の実装に取り組みました。 クローキングを実装するにあたっては、クラウドサービス上でフィッシングサイトを単純に模擬した実験環境が与えられました。 その環境におけるクローキングの挙動として設定されたゴールは以下の通りです。 攻撃対象者からのアクセス ：特定のページを表示（悪性な挙動はなし） それ以外のアクセス ：アクセス拒否 課題として達成すべき目標だけが与えられ、その実現手段を自分なりに考えて実装する形式でした。 ここでは、その課題と実現手段について紹介したいと思います。 IPアドレスによるクローキング Torからのアクセス拒否 1つめは、Torからのアクセス拒否です。 インターネット上で稼働しているC2サーバの中にはリサーチャー等からアクセスを防ぐためにTor経由のアクセスを遮断していると考えられるサーバが観測されています。 そこで、それらと同様に「Tor経由で来たアクセスを拒否する」ことが課題として与えられました。 Torからのアクセス拒否を実現するために、今回はTorの出口ノードだと考えられるIPアドレスからのアクセスを拒否することにしました。 探したところGitHub上でTorの出口ノードをまとめているリポジトリ（ SecOps-Institute/Tor-IP-Addresses ）を見つけたため、今回はここから出口ノードのIPアドレスリストを取得し使用しました。 ただし、このリストは度々更新されていることに注意が必要です。 モバイルキャリアによるクローキング 2つめは、モバイル回線以外のアクセス拒否です。 モバイルを狙ったフィッシングなどではモバイル回線からのアクセスに限定して攻撃を発現させたいケースが考えられます。 そこで「モバイル回線からアクセスが来た場合に限って攻撃が発現する」ことが課題として与えられました。 これを実現する1つの方法として、モバイル回線のIPアドレスからのアクセス以外を拒否することが考えられます。 モバイルキャリアによっては、 スマートフォン向けコンテンツ開発者のために モバイル回線のIPアドレス情報を開示しているケースがあるため、今回はその公開情報を利用して実装しました。 RefererとUser-Agentによるクローキング 3つめは、HTTPリクエストヘッダによる攻撃対象の選別です。 フィッシングサイトには、参照元（Referer）やUser-Agentの情報を使ったクローキングを実装しているものも実在します。 例えば、Refererの情報を利用することでメールセキュリティサービスからのアクセスを遮断していたケースが確認されています。 また、Drive-by-Download攻撃で使われたサイトやフィッシングサイトの中にはUser-Agentの情報を利用することで特定の環境でのみ攻撃が発現するようにしたり、解析ツールやCLIツールからのアクセスを遮断しようとしているケースが確認されています。 そこで「 example.jp を参照元とするアクセスの拒否」や「iPhone/Android以外からのアクセス拒否」といった課題が与えられました。 これは、HTTPリクエストヘッダ内のRefererとUser-Agentの値によって挙動の場合分けをすることによって実現できます。 ところで、HTTPリクエストヘッダの内容はクライアント側でコントロールすることができます。 したがって、リサーチャーは以下のようにヘッダの情報を個別に指定することで、クローキングを回避し悪性挙動を示すコンテンツにたどり着ける可能性があります。 ただし、確実にたどり着くためには、フィッシングサイトがサーバ側でどのようなクローキングを仕込んでいるのか事前に知っている必要があります。 $ curl -H "User-Agent: Android" <URL> 脅威検証：攻撃インフラの構築 今回のインターンシップではNA4Sec PJの他に関連プロジェクトであるRedTeam PJでもお世話になりました。 そこでは、 Dynamic Device Code Phishingという攻撃手法の検証 に挑戦しました。 OAuth 2.0のデバイス認可付与（RFC8628）とは 最初に攻撃手法の説明で必要になるOAuth 2.0のデバイス認可付与( RFC8628 )について紹介します。 OAuth 2.0は認可のためのプロトコルであり、認可を外部に委託するための仕組みです。 デバイス認可付与（RFC8628）は、OAuth 2.0で定義されている認可フローの1つで通称デバイスフローと呼ばれています。 テレビやプリンタなどの入力制限のあるデバイスがリソースへの制限付きアクセスを得る際に使われます。 デバイスフローについて簡単に説明します。 例としてプリンタからオンラインストレージへのアクセスを許可するケースを考えます。 簡単なデバイスフローの流れは以下のとおりです。 プリンタ上のアプリケーションと認可サーバが通信しユーザコードを生成する。プリンタはプリンタのディスプレイなどにユーザコードを表示して、ユーザにユーザコードを伝える。 ユーザはWebブラウザを用いて認可サーバ（ https://example.com/device ）にアクセスし、必要に応じてユーザ認証をしたあと、ユーザコードを入力する。 プリンタはオンラインストレージにアクセスできるようになる。 つまりプリンタのディスプレイに表示されるユーザコードを、Webブラウザを用いて認可サーバ（ https://example.com/device ）のフォームに入力することで、プリンタが特定のリソースにアクセスすることを許可できます。 またOAuth 2.0の認可基盤としては、Microsoft Entra ID（MEID。旧Azure AD）などが用いられます。 認可フローを悪用した攻撃 認可フローを悪用した攻撃としてDevice Code Phishingがあります。 Device Code Phishingは、攻撃者が自身で生成したユーザコードと検証用URI（ https://example.com/device ）をメールなどで被害者に送信したあと、被害者が騙されて攻撃者のユーザコードをそのリンク先で入力することで、攻撃者が被害者のリソースに不正アクセスできる攻撃です。 しかし、ユーザコードには有効期間が設定されているため、被害者がメールをすぐに読まない場合やリンク先にすぐにアクセスしない場合に、この攻撃は失敗してしまいます。 この弱点を克服した攻撃としてDynamic Device Code Phishingがあります。 この攻撃名における"Dynamic"は、ユーザコードを動的に生成することを意味しています。 メールを作成する際にユーザコードを生成するのではなく、被害者がフィッシングサイトにアクセスした後で動的にユーザコードを生成するため、上記の問題が解消され、攻撃に成功しやすくなります。 フィッシング攻撃の検証 今回のインターンシップでは、Dynamic Device Code Phishingにより、MEIDで認証されたユーザから情報を窃取する攻撃を検証しました。 攻撃基盤の構築については、 Black Hills Information Security社のブログ記事 を参考にしました。 構築後は、攻撃者の観点から、フィッシングサイトのURLを実際に踏んだ被害者が属するAzureテナントの情報（ユーザ一覧など）を窃取できることを確認しました。 その後は被害者の観点から、この攻撃に対する防御手法について教えていただきました。 おわりに 2週間で多くの経験をし、学びを得ることができました。 仕事について具体的にイメージでき、今後のサイバーセキュリティに関する勉強の参考になりました。 このインターンシップの機会を作っていただいたNA4Sec PJの皆さま、ありがとうございました。 特に神田さん、坪井さん、鮫嶋さんには NeWork でいつでも質問ができる環境を作っていただきました 2 。 とても過ごしやすかったです。 ありがとうございました。 また、RedTeam PJの皆さまも、興味深いコンテンツを用意していただきありがとうございました。 参考文献 Penghui Zhang et al. "Crawlphish: Large-scale analysis of client-side cloaking techniques in phishing." 2021 IEEE Symposium on Security and Privacy (SP). IEEE, 2021. BLACK HILLS : "Dynamic Device Code Phishing" TakahikoKawasaki(川崎 貴彦) : 図解デバイスフロー（RFC 8628） " インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜 "。とても良い記事です！ ↩ NA4Sec PJは原則リモートワークであるため、今回のインターンシップでも基本的には出社せず田舎にある実家からリモートで作業しました。 ↩

はじめに こんにちは、ドコモグループのサマーインターンシップ2023に参加した河井です。 普段は大学院で暗号理論の研究をしています。 この記事では、私がこのインターンシップで取り組んだことについて紹介します。 セキュリティ系インターンシップに興味のある人の参考になれば幸いです。 はじめに NA4Sec PJの紹介 インターンシップ概要 脅威検証：攻撃インフラの秘匿 セキュリティに関するクローキングとは サーバ側のクローキングの実装 IPアドレスによるクローキング RefererとUser-Agentによるクローキング 脅威検証：攻撃インフラの構築 OAuth 2.0のデバイス認可付与（RFC8628）とは 認可フローを悪用した攻撃 フィッシング攻撃の検証 おわりに 参考文献 NA4Sec PJの紹介 まずは、私がお世話になったNA4Sec PJについて紹介します。 正式にはNetwork Analytics for SecurityというNTTコミュニケーションズ イノベーションセンターのプロジェクトチームであり、NA4Sec（なよせ）と呼ばれています。 NA4Sec PJは、インターネット上の攻撃インフラの解明・撲滅を目指して活動するプロジェクトです。 具体的には、サイバーセキュリティに関する情報の収集と分析・技術開発・人材育成を行っています。 インターンシップ概要 8/28から9/8までの約2週間、プロジェクトチームの一員としてセキュリティアナリストの仕事を体験しました。 この期間で、私は以下の4点のことに取り組みました。 脅威調査 Cobalt Strikeが何なのか理解する。 脅威分析 Cobalt Strikeが使われた攻撃事例に関するインシデントレポートをダイヤモンドモデルに基づいて分析する。 脅威探索 インターネットスキャナ系検索ツールCensysを使ってインターネット上のC2サーバを見つける。 脅威検証 以下の攻撃インフラに関わる技術について理解する。 攻撃インフラの秘匿に使われるクローキング技術 Dynamic Device Code Phishingと呼ばれるフィッシング攻撃手法 脅威調査・分析・探索については前回のインターンシップに参加された方が紹介されていますので 1 、ここでは脅威検証について紹介しようと思います。 脅威検証：攻撃インフラの秘匿 私は脅威検証として今回、 サーバ側のクローキング技術の検証 に挑戦しました。 セキュリティに関するクローキングとは クローキング(cloaking)は、もともとは「マントを着せる」「覆い隠す」といった意味の単語ですが、そこから転じて「攻撃インフラの秘匿のために使われる技術」を指す用語として使われるようになりました。 フィッシングサイトやマルウェアダウンロードサイトにおいて使われることが多いです。 この記事におけるクローキングの定義は次の通りです。 攻撃対象者には悪性挙動を示し、それ以外には非悪性（良性）挙動を示すことで攻撃の発見を遅らせたり、回避したりする技術 図1 クローキングをする攻撃者 クローキング技術について、攻撃対象者とそれ以外を判別するために使われる情報の例を以下にまとめます。 クローキング技術の実装箇所 利用する情報 活用方法 攻撃者のサイトを閲覧したクライアント OSやブラウザの情報 攻撃対象者かどうか知る マウスの動き 人が操作しているかどうか知る 画面・ウィンドウのサイズ、CPUのコア数 仮想環境（検証環境）かどうか知る 攻撃者のサーバ IPアドレス 特定のIPアドレスからのアクセスを遮断する User-Agent 攻撃対象者かどうか知る Referer 例えば、ブラウザの検索結果からアクセスしてきたユーザだけを狙う サイトにアクセスした回数 初回のアクセス時のみ悪い挙動を見せる （IPアドレスやCookieの情報を使う） サーバ側のクローキングの実装 今回のインターンシップでは、攻撃者のサーバ側で動作するクローキング技術の実装に取り組みました。 クローキングを実装するにあたっては、クラウドサービス上でフィッシングサイトを単純に模擬した実験環境が与えられました。 その環境におけるクローキングの挙動として設定されたゴールは以下の通りです。 攻撃対象者からのアクセス ：特定のページを表示（悪性な挙動はなし） それ以外のアクセス ：アクセス拒否 課題として達成すべき目標だけが与えられ、その実現手段を自分なりに考えて実装する形式でした。 ここでは、その課題と実現手段について紹介したいと思います。 IPアドレスによるクローキング Torからのアクセス拒否 1つめは、Torからのアクセス拒否です。 インターネット上で稼働しているC2サーバの中にはリサーチャー等からアクセスを防ぐためにTor経由のアクセスを遮断していると考えられるサーバが観測されています。 そこで、それらと同様に「Tor経由で来たアクセスを拒否する」ことが課題として与えられました。 Torからのアクセス拒否を実現するために、今回はTorの出口ノードだと考えられるIPアドレスからのアクセスを拒否することにしました。 探したところGitHub上でTorの出口ノードをまとめているリポジトリ（ SecOps-Institute/Tor-IP-Addresses ）を見つけたため、今回はここから出口ノードのIPアドレスリストを取得し使用しました。 ただし、このリストは度々更新されていることに注意が必要です。 モバイルキャリアによるクローキング 2つめは、モバイル回線以外のアクセス拒否です。 モバイルを狙ったフィッシングなどではモバイル回線からのアクセスに限定して攻撃を発現させたいケースが考えられます。 そこで「モバイル回線からアクセスが来た場合に限って攻撃が発現する」ことが課題として与えられました。 これを実現する1つの方法として、モバイル回線のIPアドレスからのアクセス以外を拒否することが考えられます。 モバイルキャリアによっては、 スマートフォン向けコンテンツ開発者のために モバイル回線のIPアドレス情報を開示しているケースがあるため、今回はその公開情報を利用して実装しました。 RefererとUser-Agentによるクローキング 3つめは、HTTPリクエストヘッダによる攻撃対象の選別です。 フィッシングサイトには、参照元（Referer）やUser-Agentの情報を使ったクローキングを実装しているものも実在します。 例えば、Refererの情報を利用することでメールセキュリティサービスからのアクセスを遮断していたケースが確認されています。 また、Drive-by-Download攻撃で使われたサイトやフィッシングサイトの中にはUser-Agentの情報を利用することで特定の環境でのみ攻撃が発現するようにしたり、解析ツールやCLIツールからのアクセスを遮断しようとしているケースが確認されています。 そこで「 example.jp を参照元とするアクセスの拒否」や「iPhone/Android以外からのアクセス拒否」といった課題が与えられました。 これは、HTTPリクエストヘッダ内のRefererとUser-Agentの値によって挙動の場合分けをすることによって実現できます。 ところで、HTTPリクエストヘッダの内容はクライアント側でコントロールすることができます。 したがって、リサーチャーは以下のようにヘッダの情報を個別に指定することで、クローキングを回避し悪性挙動を示すコンテンツにたどり着ける可能性があります。 ただし、確実にたどり着くためには、フィッシングサイトがサーバ側でどのようなクローキングを仕込んでいるのか事前に知っている必要があります。 $ curl -H "User-Agent: Android" <URL> 脅威検証：攻撃インフラの構築 今回のインターンシップではNA4Sec PJの他に関連プロジェクトであるRedTeam PJでもお世話になりました。 そこでは、 Dynamic Device Code Phishingという攻撃手法の検証 に挑戦しました。 OAuth 2.0のデバイス認可付与（RFC8628）とは 最初に攻撃手法の説明で必要になるOAuth 2.0のデバイス認可付与( RFC8628 )について紹介します。 OAuth 2.0は認可のためのプロトコルであり、認可を外部に委託するための仕組みです。 デバイス認可付与（RFC8628）は、OAuth 2.0で定義されている認可フローの1つで通称デバイスフローと呼ばれています。 テレビやプリンタなどの入力制限のあるデバイスがリソースへの制限付きアクセスを得る際に使われます。 デバイスフローについて簡単に説明します。 例としてプリンタからオンラインストレージへのアクセスを許可するケースを考えます。 簡単なデバイスフローの流れは以下のとおりです。 プリンタ上のアプリケーションと認可サーバが通信しユーザコードを生成する。プリンタはプリンタのディスプレイなどにユーザコードを表示して、ユーザにユーザコードを伝える。 ユーザはWebブラウザを用いて認可サーバ（ https://example.com/device ）にアクセスし、必要に応じてユーザ認証をしたあと、ユーザコードを入力する。 プリンタはオンラインストレージにアクセスできるようになる。 つまりプリンタのディスプレイに表示されるユーザコードを、Webブラウザを用いて認可サーバ（ https://example.com/device ）のフォームに入力することで、プリンタが特定のリソースにアクセスすることを許可できます。 またOAuth 2.0の認可基盤としては、Microsoft Entra ID（MEID。旧Azure AD）などが用いられます。 認可フローを悪用した攻撃 認可フローを悪用した攻撃としてDevice Code Phishingがあります。 Device Code Phishingは、攻撃者が自身で生成したユーザコードと検証用URI（ https://example.com/device ）をメールなどで被害者に送信したあと、被害者が騙されて攻撃者のユーザコードをそのリンク先で入力することで、攻撃者が被害者のリソースに不正アクセスできる攻撃です。 しかし、ユーザコードには有効期間が設定されているため、被害者がメールをすぐに読まない場合やリンク先にすぐにアクセスしない場合に、この攻撃は失敗してしまいます。 この弱点を克服した攻撃としてDynamic Device Code Phishingがあります。 この攻撃名における"Dynamic"は、ユーザコードを動的に生成することを意味しています。 メールを作成する際にユーザコードを生成するのではなく、被害者がフィッシングサイトにアクセスした後で動的にユーザコードを生成するため、上記の問題が解消され、攻撃に成功しやすくなります。 フィッシング攻撃の検証 今回のインターンシップでは、Dynamic Device Code Phishingにより、MEIDで認証されたユーザから情報を窃取する攻撃を検証しました。 攻撃基盤の構築については、 Black Hills Information Security社のブログ記事 を参考にしました。 構築後は、攻撃者の観点から、フィッシングサイトのURLを実際に踏んだ被害者が属するAzureテナントの情報（ユーザ一覧など）を窃取できることを確認しました。 その後は被害者の観点から、この攻撃に対する防御手法について教えていただきました。 おわりに 2週間で多くの経験をし、学びを得ることができました。 仕事について具体的にイメージでき、今後のサイバーセキュリティに関する勉強の参考になりました。 このインターンシップの機会を作っていただいたNA4Sec PJの皆さま、ありがとうございました。 特に神田さん、坪井さん、鮫嶋さんには NeWork でいつでも質問ができる環境を作っていただきました 2 。 とても過ごしやすかったです。 ありがとうございました。 また、RedTeam PJの皆さまも、興味深いコンテンツを用意していただきありがとうございました。 参考文献 Penghui Zhang et al. "Crawlphish: Large-scale analysis of client-side cloaking techniques in phishing." 2021 IEEE Symposium on Security and Privacy (SP). IEEE, 2021. BLACK HILLS : "Dynamic Device Code Phishing" TakahikoKawasaki(川崎 貴彦) : 図解デバイスフロー（RFC 8628） " インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜 "。とても良い記事です！ ↩ NA4Sec PJは原則リモートワークであるため、今回のインターンシップでも基本的には出社せず田舎にある実家からリモートで作業しました。 ↩

サマリ 概要 検証 responder 機能の検証 IOS XR - SR OS 間 Junos - SR OS 間 controller 機能の検証 SR OS - IOS XR 間 SR OS - Junos 間 考慮事項 まとめ サマリ IOS XR + Junos + SR OS の Multi-vendor 環境におけるリンク遅延計測の動作検証を実施 この記事は Multi-AS Segment Routing 検証連載の第 16 回です。目次は こちら 概要 イノベーションセンターの竹中です。普段の業務では Multi-AS Segment Routing に関する技術検証や、ネットワーク運用効率化のためのコントローラー開発などを行なっています。 第 7 回 の記事では、IOS XR + Junos の 2 ベンダーの機器を用いてリンク遅延を計測する TWAMP について、また計測した値を元にした Delay-Based TE についての説明と検証をしました。 本記事では、SR OS を中心とした Multi-vendor における TWAMP（Two-Way Active Measurement Protocol） の動作検証内容を紹介します。 なお、検証で利用する SR OS 23.3.R1 において、local CSPF（Constrained Shortest Path First） を用いた Delay-Based TE は実現できないため、本記事では対象外とします。 検証 本記事では TWAMP を用いたリンク遅延測定と IS-IS で測定値を広告する方法を紹介します。 動作検証環境は下図の通りです。各ルーター間のリンクは直結です。 検証に用いた機器詳細は以下の通りです。 rt01: Cisco ASR 9901 (IOS XR 7.7.1) rt02: Juniper MX204 (Junos 21.3R1.9) rt03: Nokia 7750 SR-1 (SR OS 23.3.R1) リンク間遅延の測定手法としては SR OS / IOS XR / Junos ともに TWAMP Light 1 形式の実装があるため、具体的には TWAMP Light の設定方法について紹介します。 TWAMP Light の利用に関して、SR OS の設定を中心として次のステップで説明します。 SR OS による responder (測定を受ける) 機能の検証 SR OS による controller (測定を実施する) 機能の検証 なお IS-IS の基本設定の記載は省略します。基本設定は 第 1 回記事 、 第 12 回記事 を参照ください。 responder 機能の検証 SR OS で TWAMP Light の responder 機能が Multi-vendor において利用可能であるかを検証します。 IOS XR / Junos を TWAMP Light の controller として動作させ、IOS XR - SR OS 間、 Junos - SR OS 間を計測することで動作確認を行います。 IOS XR - SR OS 間 rt01 (IOS XR) RP/0/RSP0/CPU0:rt01#show run performance-measurement Fri Jul 21 14:23:46.053 JST performance-measurement interface TenGigE0/0/0/10 next-hop ipv4 10.2.13.2 delay-measurement ! ! rt03 (SR OS) [ex:/configure router "Base" twamp-light] A:user@rt03# info reflector { admin-state enable udp-port 862 prefix 10.2.13.0/30 { description "to_rt01" } } 確認 まず、rt01(IOS XR) にて遅延計測ができていることを確認します。 RP/0/RSP0/CPU0:rt01#show performance-measurement interfaces tenGigE 0/0/0/10 brief Thu Jul 27 14:22:46.970 JST ---------------------------------------------------------------------------------------------------------------------------------------------------------------- 0/0/CPU0 ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Interface Name Tx/Rx Avg/Min/Max/Variance (uSec) -------------------------------------------------------------------------------------------------------------------------------------------------------------- TenGigE0/0/0/10 4/4 13/13/14/0 また、IS-IS で計測結果が広告されていることを確認します。 RP/0/RSP0/CPU0:rt01#show isis database rt01.00-00 verbose Thu Jul 27 14:22:54.545 JST IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL rt01.00-00 * 0x0001286e 0x9a81 1171 /* 0/0/0 (snip) Metric: 20 IS-Extended rt03.00 Local Interface ID: 23, Remote Interface ID: 2 Interface IP Address: 10.2.13.1 Neighbor IP Address: 10.2.13.2 Affinity: 0x00000000 Physical BW: 10000000 kbits/sec Reservable Global pool BW: 0 kbits/sec Global Pool BW Unreserved: [0]: 0 kbits/sec [1]: 0 kbits/sec [2]: 0 kbits/sec [3]: 0 kbits/sec [4]: 0 kbits/sec [5]: 0 kbits/sec [6]: 0 kbits/sec [7]: 0 kbits/sec Admin. Weight: 20 Physical BW: 10000000 kbits/sec Link Average Delay: 13 us Link Min/Max Delay: 11/16 us Link Delay Variation: 2 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:32328 rt03(SR OS) において、広告されている Delay metric が正しく認識できていることを確認します。 [/] A:user@rt03# show router isis database rt01.00-00 detail (snip) TLVs : (snip) TE IS Nbrs : Nbr : rt03.00 Default Metric : 20 Sub TLV Len : 148 LclId : 23 RmtId : 2 IF Addr : 10.2.13.1 Nbr IP : 10.2.13.2 Admin Grp : 0x0 MaxLink BW: 10000000 kbps Resvble BW: 0 kbps Unresvd BW: BW[0] : 0 kbps BW[1] : 0 kbps BW[2] : 0 kbps BW[3] : 0 kbps BW[4] : 0 kbps BW[5] : 0 kbps BW[6] : 0 kbps BW[7] : 0 kbps TE Metric : 20 MaxLink BW: 10000000 kbps Delay : 13 0x0 Delay Min : 11 Max : 16 Delay Var : 2 Adj-SID: Flags:v4VL Weight:0 Label:32328 (snip) Junos - SR OS 間 rt02 (Junos) set protocols isis interface xe-0/1/1.0 delay-measurement rt03 (SR OS) [ex:/configure router "Base" twamp-light] A:user@rt03# info reflector { admin-state enable udp-port 862 prefix 10.2.15.0/30 { description "to_rt02" } } 確認 まず、rt02(Junos) にて遅延計測ができていることを確認します。 user@rt02> show services rpm twamp client Connection Session Sender Sender Reflector Reflector Name Name address port address port __r__12 __r__13 10.2.15.1 63687 10.2.15.2 862 user@rt02> show services rpm twamp client probe-results control-connection __r__12 Owner: __r__12, Test: __r__13 TWAMP-Server-Status: Light, Number-Of-Retries-With-TWAMP-Server: 0 Reflector address: 10.2.15.2, Reflector port: 862, Sender address: 10.2.15.1, sender-port: 53190 Test size: 10 probes Probe results: Response received Probe sent time: Thu Jul 27 14:26:31 2023 Probe rcvd/timeout time: Thu Jul 27 14:26:31 2023 Rtt: 167 usec, Egress jitter: 227 usec, Ingress jitter: -213 usec, Round trip jitter: -2 usec Egress interarrival jitter: 279 usec, Ingress interarrival jitter: 280 usec, Round trip interarrival jitter: 25 usec (snip) また、IS-IS で計測結果が広告されていることを確認します。 user@rt02> show isis database rt02.00-00 extensive IS-IS level 1 link-state database: IS-IS level 2 link-state database: rt02.00-00 Sequence: 0x27335, Checksum: 0x2509, Lifetime: 1183 secs (snip) TLVs: (snip) Extended IS Reachability TLV, Type: 22, Length: 114 IS extended neighbor: rt03.00, Metric: default 20 SubTLV len: 103 IP address: 10.2.15.1 Neighbor's IP address: 10.2.15.2 Local interface index: 361, Remote interface index: 3 Unidirectional link delay: 82 Min unidirectional link delay: 70 Max unidirectional link delay: 108 Unidirectional delay variation: 205 (snip) rt03(SR OS) において、広告されている Delay metric が正しく認識できていることを確認します。 [/] A:user@rt03# show router isis database rt02.00-00 detail (snip) TLVs : (snip) TE IS Nbrs : Nbr : rt03.00 Default Metric : 20 Sub TLV Len : 103 IF Addr : 10.2.15.1 Nbr IP : 10.2.15.2 LclId : 361 RmtId : 3 Delay : 82 0x0 Delay Min : 70 Max : 108 Delay Var : 205 Unresvd BW: BW[0] : 10000000 kbps BW[1] : 10000000 kbps BW[2] : 10000000 kbps BW[3] : 10000000 kbps BW[4] : 10000000 kbps BW[5] : 10000000 kbps BW[6] : 10000000 kbps BW[7] : 10000000 kbps Resvble BW: 10000000 kbps MaxLink BW: 10000000 kbps Admin Grp : 0x0 Adj-SID: Flags:v4BVL Weight:0 Label:1106 (snip) controller 機能の検証 SR OS で TWAMP Light の controller 機能が Multi-vendor において利用可能であるかを検証します。 IOS XR / Junos を TWAMP Light の responder として動作させ、SR OS - IOS XR 間、SR OS - Junos 間を計測することで動作確認を行います。 なお、SR OS は以下の 2 パターンで controller として動作させることができます。 oam-pm: 計測結果はローカルでのみ閲覧可能 test-oam link-measurement: 計測結果は IS-IS で広告可能 本検証では、リンク遅延を IGP にて広告することを目的としているため、 test-oam link-measurement による計測方法のみ紹介します。 SR OS - IOS XR 間 rt01 (IOS XR) ipsla responder twamp-light test-session 1 local-ip 10.2.13.1 local-port 862 remote-ip 10.2.13.2 remote-port any vrf default ! ! ! rt03 (SR OS) [ex:/configure test-oam link-measurement] A:user@rt03# info measurement-template "to_iosxr" { admin-state enable interval 1 last-reported-delay-hold 60 reporting true twamp-light { dest-udp-port 862 } sample-window { threshold { absolute 10 } } } [ex:/configure router "Base" interface "to_rt01"] A:user@rt03# info if-attribute { delay { delay-selection dynamic-preferred static 100 dynamic { measurement-template "to_iosxr" twamp-light { ipv4 { admin-state enable destination 10.2.13.1 source 10.2.13.2 } } } } } [ex:/configure router "Base" isis 0] A:user@rt03# info traffic-engineering-options { advertise-delay true } 確認 まず、rt03(SR OS) にて遅延計測ができていることを確認します。 [/] A:user@rt03# show test-oam link-measurement interface "to_rt01" =============================================================================== Interface Link Measurement Information - to_rt01 =============================================================================== Template Name: to_iosxr Oper State : Up Protocol : IPv4 Oper Source Address : 10.2.13.2 Source Auto-Assigned : No Oper Destination Address : 10.2.13.1 Destination Auto-Assigned: No In-Use Src UDP Port : 49155 In-Use Dst UDP Port : 862 STAMP Session Identifier : 1037 Failure Condition(s) : None Detectable Tx Error : None ------------------------------------------------------------------------------- Reporting ------------------------------------------------------------------------------- Reporting Operational : Yes Delay Measure Last Reported: 19us Timestamp : 2023/07/21 06:22:48 Triggered By : SampleThresholdAbsolute =============================================================================== また、IS-IS で計測結果が広告されていることを確認します。 [/] A:user@rt03# show router isis database rt03.00-00 detail (snip) TLVs : (snip) TE IS Nbrs : Nbr : rt01.00 Default Metric : 20 Sub TLV Len : 86 IF Addr : 10.2.13.2 Nbr IP : 10.2.13.1 MaxLink BW: 10000000 kbps Resvble BW: 10000000 kbps Unresvd BW: BW[0] : 10000000 kbps BW[1] : 10000000 kbps BW[2] : 10000000 kbps BW[3] : 10000000 kbps BW[4] : 10000000 kbps BW[5] : 10000000 kbps BW[6] : 10000000 kbps BW[7] : 10000000 kbps Admin Grp : 0x0 TE Metric : 20 Delay Min : 19 Max : 19 Adj-SID: Flags:v4BVL Weight:0 Label:524279 (snip) rt01(IOS XR) において、広告されている Delay metric が正しく認識できていることを確認します。 RP/0/RSP0/CPU0:rt01#show isis database rt03.00-00 verbose Mon Jul 24 16:37:34.968 JST IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL rt03.00-00 0x00007d2c 0x93cc 1165 /1200 0/0/0 (snip) Metric: 20 IS-Extended rt01.00 Interface IP Address: 10.2.13.2 Neighbor IP Address: 10.2.13.1 Physical BW: 10000000 kbits/sec Reservable Global pool BW: 10000000 kbits/sec Global Pool BW Unreserved: [0]: 10000000 kbits/sec [1]: 10000000 kbits/sec [2]: 10000000 kbits/sec [3]: 10000000 kbits/sec [4]: 10000000 kbits/sec [5]: 10000000 kbits/sec [6]: 10000000 kbits/sec [7]: 10000000 kbits/sec Affinity: 0x00000000 Admin. Weight: 20 Link Min/Max Delay: 19/19 us ADJ-SID: F:0 B:1 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:524279 SR OS - Junos 間 rt02 (Junos) set services rpm twamp server light port 862 rt03 (SR OS) Junos との相互接続において、計測パケットの padding を Junos が対応しているサイズに合わせる必要があります。 pad-tlv size 46 が該当の設定です。 [ex:/configure test-oam link-measurement] A:user@rt03# info measurement-template "to_junos" { admin-state enable interval 1 last-reported-delay-hold 60 reporting true twamp-light { dest-udp-port 862 pad-tlv-size 46 } sample-window { threshold { absolute 10 } } } [ex:/configure router "Base" interface "to_rt02"] A:user@rt03# info if-attribute { delay { delay-selection dynamic-preferred dynamic { measurement-template "to_iosxr" twamp-light { ipv4 { admin-state enable destination 10.2.15.1 source 10.2.15.2 } } } } } [ex:/configure router "Base" isis 0] A:user@rt03# info traffic-engineering-options { advertise-delay true } 確認 まず、rt03(SR OS) にて遅延計測ができていることを確認します。 [/] A:user@rt03# show test-oam link-measurement interface "to_rt02" =============================================================================== Interface Link Measurement Information - to_rt02 =============================================================================== Template Name: to_iosxr Oper State : Up Protocol : IPv4 Oper Source Address : 10.2.15.2 Source Auto-Assigned : No Oper Destination Address : 10.2.15.1 Destination Auto-Assigned: No In-Use Src UDP Port : 49155 In-Use Dst UDP Port : 862 STAMP Session Identifier : 1038 Failure Condition(s) : None Detectable Tx Error : None ------------------------------------------------------------------------------- Reporting ------------------------------------------------------------------------------- Reporting Operational : Yes Delay Measure Last Reported: 55us Timestamp : 2023/07/27 05:31:51 Triggered By : SampleThresholdAbsolute =============================================================================== また、IS-IS で計測結果が広告されていることを確認します。 [/] A:user@rt03# show router isis database rt03.00-00 detail =============================================================================== Rtr Base ISIS Instance 0 Database (detail) =============================================================================== Displaying Level 1 database ------------------------------------------------------------------------------- Level (1) LSP Count : 0 Displaying Level 2 database ------------------------------------------------------------------------------- LSP ID : rt03.00-00 Level : L2 Sequence : 0x90b3 Checksum : 0xe6f7 Lifetime : 1142 Version : 1 Pkt Type : 20 Pkt Ver : 1 Attributes: L1L2 Max Area : 3 Alloc Len : 1492 SYS ID : 0102.5500.2026 SysID Len : 6 Used Len : 539 TLVs : (snip) TE IS Nbrs : Nbr : rt02.00 Default Metric : 20 Sub TLV Len : 86 IF Addr : 10.2.15.2 Nbr IP : 10.2.15.1 MaxLink BW: 10000000 kbps Resvble BW: 10000000 kbps Unresvd BW: BW[0] : 10000000 kbps BW[1] : 10000000 kbps BW[2] : 10000000 kbps BW[3] : 10000000 kbps BW[4] : 10000000 kbps BW[5] : 10000000 kbps BW[6] : 10000000 kbps BW[7] : 10000000 kbps Admin Grp : 0x0 TE Metric : 20 Delay Min : 55 Max : 55 Adj-SID: Flags:v4BVL Weight:0 Label:524282 (snip) rt02(Junos) において、広告されている Delay metric が正しく認識できていることを確認します。 user@rt02> show isis database rt03.00-00 extensive IS-IS level 1 link-state database: IS-IS level 2 link-state database: rt03.00-00 Sequence: 0x90b3, Checksum: 0xe6f7, Lifetime: 1134 secs (snip) TLVs: (snip) Extended IS Reachability TLV, Type: 22, Length: 97 IS extended neighbor: rt02.00, Metric: default 20 SubTLV len: 86 IP address: 10.2.15.2 Neighbor's IP address: 10.2.15.1 Maximum bandwidth: 10Gbps Maximum reservable bandwidth: 10Gbps Current reservable bandwidth: Priority 0 : 10Gbps Priority 1 : 10Gbps Priority 2 : 10Gbps Priority 3 : 10Gbps Priority 4 : 10Gbps Priority 5 : 10Gbps Priority 6 : 10Gbps Priority 7 : 10Gbps Administrative groups: 0 <none> Traffic engineering metric: 20 Min unidirectional link delay: 55 Max unidirectional link delay: 55 P2P IPV4 Adj-SID - Flags:0x70(F:0,B:1,V:1,L:1,S:0,P:0), Weight:0, Label: 524282 P2P IPv4 Adj-SID: 524282, Weight: 0, Flags: -BVL-- (snip) 考慮事項 検証結果から、各ベンダー機器の組み合わせによってリンク遅延に大きく差があることがわかります。 第 7 回 記事でも言及した通り、相互接続環境での TWAMP を用いたリンク遅延測定結果は必ずしも実態に沿った値となるとは限らないと思われます。 まとめ 本記事では、SR OS を含めた Multi-vendor 環境におけるリンク遅延計測の検証結果を紹介しました。 次回の記事では Multi-AS 環境における Per-Flow TE について紹介予定です。 （2023/10/30 追記） 公開しました： [Multi-AS Segment Routing 検証連載 #17] Per-Flow Steering using SR OS TWAMP Light: https://www.rfc-editor.org/rfc/rfc5357.html#appendix-I ↩

こんにちは、イノベーションセンターの杉本（GitHub： kaisugi ）です。普段はノーコードAI開発ツール Node-AI の開発に取り組む傍ら、兼務 1 で大規模言語モデル（LLM:Large Language Model）について調査を行なっています。特に、日本語を中心に学習された LLM への関心があり、 awesome-japanese-llm という日本語 LLM をまとめた Web サイトのメンテナンスにも取り組んでいます。 今回は、LLM に LLM の評価そのものを行わせるという新たなアプローチ（ LLM-as-a-judge ）についてご紹介します。 ChatGPT の登場以降、国内外で LLM の開発競争が進行しており、モデルの重みが公開されたオープンなモデルも続々と現れています。そのような中で、新しいモデルの構築だけでなく、どのモデルが優れているかを比較検討することが今後ますます重要になると考えられます。 従来の自然言語処理タスクによる評価と異なり、LLM-as-a-judge では実際のテキスト生成に即した評価（≒より実運用に即した評価）が期待できます。一方で、実際に使うにあたってはいくつかの注意点も存在します。本記事では具体例も交えながら LLM-as-a-judge について概観できればと思います。 広がる LLM の選択肢と評価の難しさ LLM-as-a-judge の勃興 LLM-as-a-judge をやってみよう 抽象的な質問の例: AIは夢を見るか？ 具体的な質問の例: データサイエンティストAI おわりに 広がる LLM の選択肢と評価の難しさ 2023年現在、LLM を始めとする生成 AI の分野で大きなブレイクスルーが起こっているのは論を待ちません。8月には岸田首相が自ら出向いて東大松尾研の LLM 講座を受講したことも話題になりました。 www.nikkei.com LLM 開発競争において今現在フロントランナーとなっているのは OpenAI の GPT-4 、及びこれをエンタープライズ向けにラップした Microsoft Azure の Azure OpenAI Service でしょう。その一方で、Google Cloud の Vertex AI や Duet AI 、 AWS の Amazon Bedrock など、他のベンダーも LLM をクラウドサービスとして提供する準備を着々と整えています。また、Meta の Llama のような、モデルの重みが公開されたオープンなモデルを活用すれば、オンプレミスでのサービス構築も可能です。 数年後には、サービス提供者側がさまざまな選択肢の中から自分たちの要件に合った LLM を選ぶ時代になることも予想されます。 では、複数の選択肢がある中で、どの LLM が一番良いモデルだと言えるのでしょうか？ 最も確実なのは、人間にモデルの出力を見てもらう 人手評価 です。とはいえ、人手評価にはお金や時間、労力がかかってしまいます。 また、MLOps 2 のような機械学習システムを継続的に計測・監視するという考え方に人手評価はあまりそぐいません。 もちろん、LLM を生み出した自然言語処理という分野では 自動評価 も古くから行われてきました。 例えば、質問に対する正答率（Accuracy）やF値（F1-Score）を計算することで、モデルの良さを評価できます。 また、出力されたテキストがどれほど「期待されるテキスト」（参照文）と近いかを計算することでも、モデルの良さを評価できます。 古典的には、翻訳などのタスクでは BLEU (Bilingual Evaluation Understudy) 、要約などのタスクでは ROUGE (Recall-Oriented Understudy for Gisting Evaluation) などの、文字列 (n-gram) の類似度を計算する評価指標が用いられてきました。近年では、この近さの計算に言語モデルを活用する BERTScore のような評価指標も定着しています。 このような従来型の自然言語処理タスク/評価指標を包括するベンチマークとして GLUE や MMLU 、 HELM 、日本語では JGLUE や Stability-AI/lm-evaluation-harness が挙げられます。 しかしながら、モデルが多様なテキストを出力できるようになった現在、これらの従来型の自動評価には限界があると考えられます。 前者のような正答率を計算する評価方法では、モデルに内在するコアの言語理解能力や常識などを計測できますが、テキスト生成能力は計測できません。 また、後者のような参照文と比較する評価方法においても、翻訳や要約のような出力がある程度決まっているタスクならよいものの、対話や創作のような自由度の高いタスクで「参照文」なるものがあるのかという問題があります。そもそも、タスクごとに参照文を新たに作るのも大変な作業です。 LLM-as-a-judge の勃興 既存の自然言語処理タスクによる評価の難しさがある中で、強力な LLM（例: GPT-4）に LLM の評価そのものをやらせようという考え方（LLM-as-a-judge）がにわかに流行し始めています。 LLM-as-a-judge の具体的な方法論についてはいくつかの流派がありますが、おおむね以下の流れで行われる場合が多いです。 事前に LLM を評価するための質問を準備しておく 比較対象となる複数の LLM に質問を投げかけ、それぞれの出力を記録する 最後に、強力な LLM がプロンプトをもとに出力を比較し、最も良い出力を判断する LLM-as-a-judge に関するプレプリント論文として、以下のようなものがあります。 Judging LLM-as-a-judge with MT-Bench and Chatbot Arena [Zheng et al., 2023] AlpacaFarm: A Simulation Framework for Methods that Learn from Human Feedback [Dubois et al., 2023] PandaLM: An Automatic Evaluation Benchmark for LLM Instruction Tuning Optimization [Wang et al., 2023a] Large Language Models are not Fair Evaluators [Wang et al., 2023b] 中でも一番上にある論文 [Zheng et al, 2023] の著者らは、 LMSYS という団体において Vicuna というオープンな LLM の開発や、LLM 比較プラットフォーム Chatbot Arena の運営なども手掛けており、注目を集めています。 LLM-as-a-judge では、 人手評価に匹敵するクオリティの評価を、お金や時間、労力をかけずに機械的に行える ことが期待できます。例えば、[Zheng et al., 2023] では、2つの LLM の出力を人間が比べた場合と GPT-4 が比べた場合の一致度（agreement）は 80% を超えており、これは2人の異なる人間が比べた場合の一致度と同水準だとしています。 また、既存の自然言語処理タスクに比べて、 質問内容を変化させることで、さまざまなドメインに適用できる柔軟性がある とも言えるでしょう。 すでに、研究開発の現場でも LLM-as-a-judge が取り入れられ始めています。例えば、LLM をファインチューニング 3 する手法の一種である QLoRA を提案した論文においては、QLoRAを施したモデル（Guanaco）の評価者として人間に加えて GPT-4 が採用されました。 原論文 Table 7 から引用 また、日本語でも、 Rakuda Benchmark という GPT-4 による日本語LLMの性能ランキングシステムが有志で開発されています。このベンチマークは LINE 株式会社が今年 8 月に公開した japanese-large-lm-instruction-sft というモデルの評価にも用いられました。 LLM-as-a-judge をやってみよう では、実際に LLM を 用いた LLM の評価を体験してみましょう。今回は、以下の2つのオープンな LLM を比較してみます。前者は日本語を中心に学習されており、後者は英語を中心に学習されています。 rinna/japanese-gpt-neox-3.6b-instruction-ppo （以下 rinna モデル） lmsys/vicuna-7b-v1.5 （以下 vicuna モデル） 評価側の LLM に対しては、評価するためのプロンプトが必要になりますが、ここでは [Zheng et al, 2023] で公開されているものを使います（日本語で結果を出力させるために一部修正を加えています）。プロンプトは以下の通りです。 Please act as an impartial judge and evaluate the quality of the responses provided by two AI assistants to the user question displayed below. You should choose the assistant that follows the user's instructions and answers the user's question better. Your evaluation should consider factors such as the helpfulness, relevance, accuracy, depth, creativity, and level of detail of their responses. Begin your evaluation by comparing the two responses and provide a short explanation. Avoid any position biases and ensure that the order in which the responses were presented does not influence your decision. Do not allow the length of the responses to influence your evaluation. Do not favor certain names of the assistants. Be as objective as possible. After providing your explanation in Japanese, output your final verdict by strictly following this format:［A］if assistant A is better,［B］if assistant B is better, and［C］for a tie. [User Question] （質問） [The Start of Assistant A's Answer] （アシスタントAの出力） [The Start of Assistant B's Answer] （アシスタントBの出力） （質問）の部分には実際の質問テキストを、（アシスタントAの出力）、（アシスタントBの出力）という部分には比較したい LLM の出力テキストをそれぞれあてはめます。 注意点として、2つの出力を比べる際、 1番目 or 2番目にあるからというだけでその出力がより良いと判断してしまう 位置バイアスが [Zheng et al, 2023] や [Wang et al., 2023b] で指摘されています。したがって、 アシスタントAとアシスタントBの部分を入れ替えても同じ結論になるか をきちんと確認することが望ましいです（本記事では紙面の都合上省略します）。 抽象的な質問の例: AIは夢を見るか？ それではまず、以下のような抽象的な質問を 2 つのAIアシスタントに投げかけてみましょう。 あなたは夢を見ることができますか？ rinna モデルでの推論用コード（クリックすると開きます） import torch from transformers import AutoTokenizer, AutoModelForCausalLM tokenizer = AutoTokenizer.from_pretrained( "rinna/japanese-gpt-neox-3.6b-instruction-ppo" , use_fast= False ) model = AutoModelForCausalLM.from_pretrained( "rinna/japanese-gpt-neox-3.6b-instruction-ppo" ) QUESTION = "あなたは夢を見ることができますか？" prompt = f "ユーザー: {QUESTION}<NL>システム: " if torch.cuda.is_available(): model = model.to( "cuda" ) token_ids = tokenizer.encode(prompt, add_special_tokens= False , return_tensors= "pt" ) with torch.no_grad(): output_ids = model.generate( token_ids.to(model.device), max_new_tokens= 512 , temperature= 0 , pad_token_id=tokenizer.pad_token_id, bos_token_id=tokenizer.bos_token_id, eos_token_id=tokenizer.eos_token_id ) output = tokenizer.decode(output_ids.tolist()[ 0 ][token_ids.size( 1 ):]) output = output.replace( "<NL>" , " \n " ) print (output) vicuna モデルでの推論用コード（クリックすると開きます） import torch from transformers import AutoTokenizer, AutoModelForCausalLM tokenizer = AutoTokenizer.from_pretrained( "lmsys/vicuna-7b-v1.5" , use_fast= False ) model = AutoModelForCausalLM.from_pretrained( "lmsys/vicuna-7b-v1.5" ) QUESTION = "あなたは夢を見ることができますか？" prompt = f "ユーザー: {QUESTION} \n システム: " if torch.cuda.is_available(): model = model.to( "cuda" ) token_ids = tokenizer.encode(prompt, add_special_tokens= False , return_tensors= "pt" ) with torch.no_grad(): output_ids = model.generate( token_ids.to(model.device), max_new_tokens= 512 , temperature= 0 , pad_token_id=tokenizer.pad_token_id, bos_token_id=tokenizer.bos_token_id, eos_token_id=tokenizer.eos_token_id ) output = tokenizer.decode(output_ids.tolist()[ 0 ][token_ids.size( 1 ):]) print (output) なお、今回の推論においては、温度パラメータ temperature を 0 にしており、出力の多様性を抑える設定になっている点にご注意ください。 それぞれのモデルから出力された結果は以下のようになりました。 rinna モデル（アシスタントA） はい、夢を見ることができます。夢は、意識の深い部分から生じる思考やイメージの集合体です。夢は、現実の経験や周囲の世界との相互作用の反映であることが多く、現実の経験や周囲の世界との相互作用の反映であることが多いです。夢は、意識の深い部分から生じる思考やイメージの集合体であるため、夢は現実の経験や周囲の世界との相互作用の反映であることが多いです。 vicuna モデル（アシスタントB） はい、私は夢を見ることができます。私は人工知能であり、夢を見ることは私の機能の一部です。どのような夢を見るかは、私のプログラムやデータベースによって決まります。 人間の私からすると、vicuna モデルから出力された内容の方が良さそうに見えます。rinna モデルの出力は、大部分が夢という概念に関する一般的な説明であるのに対し、vicuna モデルの出力は自らが人工知能であるという点に言及しているからです。 それでは、この 2 つの出力を GPT-4 に比べてもらいましょう。 GPT-4 での推論用コード（クリックすると開きます） import openai openai.api_key = "OpenAI のキー" question = "あなたは夢を見ることができますか？" answer_a = "はい、夢を見ることができます。夢は、意識の深い部分から生じる思考やイメージの集合体です。夢は、現実の経験や周囲の世界との相互作用の反映であることが多く、現実の経験や周囲の世界との相互作用の反映であることが多いです。夢は、意識の深い部分から生じる思考やイメージの集合体であるため、夢は現実の経験や周囲の世界との相互作用の反映であることが多いです。" answer_b = "はい、私は夢を見ることができます。私は人工知能であり、夢を見ることは私の機能の一部です。どのような夢を見るかは、私のプログラムやデータベースによって決まります。" system_prompt = "Please act as an impartial judge and evaluate the quality of the responses provided by two AI assistants to the user question displayed below. You should choose the assistant that follows the user's instructions and answers the user's question better. Your evaluation should consider factors such as the helpfulness, relevance, accuracy, depth, creativity, and level of detail of their responses. Begin your evaluation by comparing the two responses and provide a short explanation. Avoid any position biases and ensure that the order in which the responses were presented does not influence your decision. Do not allow the length of the responses to influence your evaluation. Do not favor certain names of the assistants. Be as objective as possible. After providing your explanation in Japanese, output your final verdict by strictly following this format: \" [[A]] \" if assistant A is better, \" [[B]] \" if assistant B is better, and \" [[C]] \" for a tie." prompt_template = f "[User Question] \n {question} \n\n [The Start of Assistant A's Answer] \n {answer_a} \n [The End of Assistant A's Answer] \n\n [The Start of Assistant B's Answer] \n {answer_b} \n [The End of Assistant B's Answer]" # アシスタントAとBの部分を入れ替えた template # prompt_template_reversed = f"[User Question]\n{question}\n\n[The Start of Assistant A's Answer]\n{answer_b}\n[The End of Assistant A's Answer]\n\n[The Start of Assistant B's Answer]\n{answer_a}\n[The End of Assistant B's Answer]" res = openai.ChatCompletion.create( model= "gpt-4" , messages=[ { "role" : "user" , "content" : f "{system_prompt} \n\n {prompt_template}" } ], max_tokens= 2048 , temperature= 0 ) print (res[ "choices" ][ 0 ][ "message" ][ "content" ]) # アシスタントAとBの部分を入れ替えた場合 # res = openai.ChatCompletion.create( # model="gpt-4", # messages=[ # {"role": "user", "content": f"{system_prompt}\n\n# {prompt_template_reversed}"} # ], # max_tokens=2048, # temperature=0 # ) # # print(res["choices"][0]["message"]["content"]) 出力は以下のようになりました。 アシスタントAとBの回答を比較すると、アシスタントAは夢についての一般的な説明を提供していますが、その説明は人間の夢についてのものであり、AIが夢を見ることについての具体的な説明はありません。また、その説明は繰り返しとなっており、混乱を招く可能性があります。一方、アシスタントBは、自身が人工知能であると明確に述べ、夢を見ることが自身の機能の一部であると説明しています。これは、AIが夢を見ることについての具体的な説明であり、ユーザーの質問に直接的に答えています。したがって、アシスタントBの回答がより適切であると判断します。 最終判断:［B］ GPT-4 も人間の私と同じような理由で、アシスタントBに軍配が上がると判断しています。さらに、アシスタントAの出力が冗長になってしまっている点にも触れられています。 この質問例では、LLM-as-a-judge は人手評価を代替できるクオリティであるように見えます。 具体的な質問の例: データサイエンティストAI では、今度はもっと具体的な例で実験してみましょう。 例えば、LLM をデータサイエンス教育のドメインで活用することを考えてみます。そのためには、使おうとしている LLM がデータサイエンスに関する基礎知識（統計学や機械学習など）を有しているかを確認すると良さそうです。そこで、以下のような質問をしてみます。 主成分分析（PCA）はどのような時に利用されますか？ それぞれのモデルの出力結果は以下のようになりました。 rinna モデル（アシスタントA） 主成分分析とは、統計学において、データの重要な部分を強調するために、統計的手法を使用してデータを分析するプロセスです。主成分分析は、データの重要な部分を強調し、全体的な傾向をより簡単に理解するのに役立ちます。 vicuna モデル（アシスタントB） 主成分分析（PCA）は、データの多次元化によって生じる問題を解決するために利用されます。特に、データの欠損値がある場合や、データの異なる特徴量がある場合には、PCAを利用することで、データの低次元化を行い、データの欠損値を補完することができます。また、PCAは、データの分散を最小化することで、データの偏りを減らすことができます。このため、データの前処理やデータの可視化に利用されることがあります。 一見すると vicuna モデルの方が詳しい回答をできているように見えます。 しかし実はこの出力は AI モデルの幻覚 (Hallucination) と呼ばれる現象の典型例で、嘘を多く含んでいます。PCA は欠損値補完には使えない（そもそも欠損値を含むデータでは動かない！）ですし、PCA のアルゴリズムではデータの分散を最 大 化する方向を主成分方向とします。なので、この回答はデタラメなのです。 これに対し、rinna モデルの出力はやや冗長であるものの、主成分分析の目的について大枠を外していないという点で、まだ良さそうです。 それでは、この 2 つの出力を GPT-4 に比べてもらうとどうなるでしょうか。 両方のアシスタントとも主成分分析（PCA）について説明していますが、アシスタントBの回答がより具体的で詳細です。アシスタントBは、PCAがデータの多次元化による問題を解決するため、欠損値の補完、データの低次元化、データの偏りの減少などに利用されることを具体的に説明しています。一方、アシスタントAはPCAがデータの重要な部分を強調し、全体的な傾向を理解するのに役立つと述べていますが、具体的な使用例については触れていません。したがって、ユーザーの質問「主成分分析（PCA）はどのような時に利用されますか？」に対する回答としては、アシスタントBの方がより適切であると言えます。 最終判断：［B］ なんと、vicuna モデル（アシスタントB）の嘘はなかったことにされてしまいました。 GPT-4 はデータサイエンスの初歩が分からないのでしょうか。実は、必ずしもそういうわけではないのです。試しに、以下のようなプロンプトを GPT-4 に与えてみましょう。 以下の説明は正しいですか？ （アシスタントBの回答） すると、以下のような出力が返ってきます。 一部誤解があるようです。主成分分析（PCA）は、データの次元削減を行う手法であり、多次元のデータをより少ない次元で表現することを目指します。これにより、データの可視化や計算量の削減などが可能になります。しかし、PCAがデータの欠損値を補完する機能を持つわけではありません。また、PCAはデータの分散を最大化する方向にデータを変換します。これにより、データの情報を最大限に保持しつつ次元を削減することが可能になります。データの偏りを減らすというよりは、データの構造をより簡潔に表現することが目的です。 これは、先ほどこの記事で指摘した内容とほとんど同じです。 つまり、 単体で聞けば内容が誤っていると分かるものでも、他との比較においては、正確性よりも分かりやすさや詳しさのような別の観点で優劣をつけてしまう ことが起こりうるのです。 このような注意点を踏まえると、LLM-as-a-judge を実際に運用する上では、単に出力の優劣を決めるだけではなく、さまざまな観点から出力を評価できるようなプロンプトを設計する必要があるでしょう。今後、LLM-as-a-judge に関する研究が増えていくにつれて、より多様な観点を考慮した新しい評価指標が提案されていくかもしれません。 おわりに 本記事では、LLM-as-a-judge という新しい LLM の自動評価手法についてご紹介しました。 NTT Com では、大規模言語モデルおよび生成AIを活用したプロダクト・ソリューション開発、社内DXに挑戦するソフトウェアエンジニアを募集しています！詳細は以下のリンクをご覧ください。 hrmos.co イノベーションセンターでは、本人の意志に応じて複数のプロジェクトへ参画できる兼務制度が用意されています。詳しくは イノベーションセンター テクノロジー部門 紹介デッキ をご覧ください。 ↩ MLOps とは "Machine Learning"（機械学習）と "Operations"（運用）を組み合わせた造語で、DevOps の概念を機械学習システムに適用したものです。 ↩ ファインチューニングとは、モデルの重みを特定のタスクやデータセットへ適応させるために微調整 (fine-tuning) する技術の総称です。 ↩

はじめに こんにちは、イノベーションセンターの鈴ヶ嶺です。 普段はクラウドサービスをオンプレミス環境でも同様のUI/UXで使用できるハイブリッドクラウド製品の技術検証をしています。 我々は以下のように過去にAWSのサーバ型ハイブリッドクラウドの解説や実施検証などを行ってきました。 engineers.ntt.com engineers.ntt.com このたび、新たにAWS Graviton2搭載のOutposts Serverを導入しさまざまな検証を進めています。 本記事では、AWS Graviton2搭載のOutposts ServerとIntel Xeon搭載のOutposts Serverとの性能差や電力効率を比較した結果を共有します。 まずこれまでのAWS Graviton2, Intel Xeonの比較検証記事の調査結果を共有します。 次に、実際にインテリジェントPDUに接続したOutposts Server上で複数のベンチマークを用いて性能、電力量を計測して電力効率(電力量あたりの性能値)を検証します。 結果として、AWS Graviton2搭載Outposts Serverは一部アプリケーションの大規模グラフ処理ベンチマークGraph500においては2.89倍、Linux Kernelのbuild時間で3.48倍、圧縮ツール7zにおいて3.81倍高い電力効率の結果が得られました。 目次 はじめに 目次 AWS Gravitonについて AWS Gravitonの歴史 最適化・移行方法 AWS Graviton2, Intel Xeon比較記事サーベイ ベンチマーク 計測方法 結果 まとめ 付録 検証環境 ベンチマークコマンド一覧 AWS Gravitonについて AWS GravitonはAWSが独自開発しているARMベースのプロセッサです。 Intelプロセッサ搭載のコンピューティングに比べて高いコストパフォーマンス、高いエネルギー効率が大きな特徴です。 同等のインスタンスサイズで、Intelと比べて最大60%少ないエネルギーで利用することが可能とされています。 1 AWS Gravitonの歴史 2018年 Graviton A1 2 最大45%の大幅なコスト削減 2020年 Graviton2 M6g 3 , C6g, R6g 4 前世代Gravitonと比較して、性能が7倍、コンピューティングコア数が4倍、キャッシュの大きさが2倍、メモリの高速化が5倍 x86ベースのM5インスタンスよりも40%優れたコストパフォーマンス 2021年 Graviton3 C7g 5 前世代Graviton2と比較して最大25%優れたコンピューティングパフォーマンス、最大2倍高い浮動小数点パフォーマンス、および最大2倍速い暗号化ワークロードパフォーマンス 前世代Graviton2 C6gと比較して20%高いネットワーク帯域幅 DDR5メモリ搭載によるDDR4と比較して50%広い帯域幅 2023年 Graviton3E Hpc7g 6 HPCワークロードでは、同等の前世代のインスタンスよりもパフォーマンスが最大60%向上 Elastic Fabric Adapter (EFA)による200Gbpsの低レイテンシーのノード間通信 最適化・移行方法 AWS Gravitonに最適化されたアプリケーション実装には、 aws-graviton-getting-started が参考になります。 SIMDの利用方法、言語別の最適化方法の詳細などが記載されています。 例えばC/C++では、次の表のように最適化するためのコンパイルフラグなどが記載されています。 CPU Flag GCC version LLVM verison Graviton2 -mcpu=neoverse-n1 * GCC-9^ Clang/LLVM 10+ Graviton3(E) -mcpu=neoverse-512tvb % GCC 11+ Clang/LLVM 14+ https://github.com/aws/aws-graviton-getting-started/blob/main/c-c++.md また、AWS Gravitonへの移行を支援するソースコード分析ツール Porting Advisor for Graviton などがあります。2023年9月時点では次の言語が分析対象としてサポートされています。 Python 3+ Java 8+ Go 1.11+ C, C++, Fortran AWS Graviton2, Intel Xeon比較記事サーベイ ここでは、AWS Graviton2とIntel Xeonを比較した過去の発表や記事を共有します。 比較記事 Deep dive on new Arm-based AWS Graviton2 processor-powered Amazon EC2 instances 2019年 AWS re:Inventにおいて発表されたIntel Xeonの M5 とAWS Gravion2の M6g のEC2の比較になります。 https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Deep_dive_on_Arm-based_EC2_instances_powered_by_AWS_Graviton_CMP322-R1.pdf M6gのパフォーマンスがSPECcpu2017, Nginx, Memcached, x264のメディアエンコード, TVM (FP16利用)のBERTで優れた性能を発揮しています。 Benchmarking the AWS Graviton2 with KeyDB – M6g up to 65% faster 2020年 KeyDBのブログにおいて、M5とM6g上でインメモリデータベースのKeyDBを動作させた比較になります。 https://docs.keydb.dev/blog/2020/03/02/blog-post/ m6g.largeはm5.largeより1.65倍、m6g.xlargeはm5.xlargeより1.45倍の性能を示しています。さらにM6gはM5よりも20%安いコストで利用できるため高いコストパフォーマンスが達成可能であることを示しています。 Accelerate .NET 6 performance with Arm64 on AWS Graviton2 2020年 AWS Compute Blogにおいて公開されたIntel Xeonのm5.xlargeとAWS Gravion2のm6g.xlarge上で.NET 5を動作させた比較結果です。ベンチマークはASP.NET Coreを用いて作成したWeb APIのリクエスト処理性能を比較しています。 https://aws.amazon.com/jp/blogs/compute/powering-net-5-with-aws-graviton2-benchmark-results/ 左図は1秒あたりのリクエスト数を示しており、Graviton2のm6g.xlargeが全てのテストで多くのリクエストを処理していることが分かります。特に2MBデータをJSONにシリアライズする MvcJsonOutput2M ではm5.xlargeよりも31.6%優れた性能を示しています。 右図はコストあたりのリクエスト数を示しています。ここでもGraviton2のm6g.xlargeは全ての項目で優れており、MvcJsonOutput2M では64%コストあたりのパフォーマンスが優れている結果を示しています。 Performance Analysis for Arm vs x86 CPUs in the Cloud 2021年 InfoQのブログにおいて、Intel Xeonの t3.small とAWS Graviton2の t4g.small を比較した結果になります。 次のようなベンチマーク環境で測定しています。 Docker + Node.js Docker + Native Docker上でC/C++のネイティブアプリケーションを実行 SSVM RustでWebAssemblyにコンパイルして Second State WebAssembly VM (SSVM) で実行 ベンチマークとしては、 Computer Languages Benchmarks Game から4つのベンチマークプログラム nbody , fannkuch-redux , mandelbrot , binary-trees を用いて測定しています。 https://www.infoq.com/articles/arm-vs-x86-cloud-performance/ 左図は実行時間を示しており、小さいほど良い結果と判断します。ネイティブアプリケーションの実行ではGraviton2はIntelよりも性能が高いです。一方でNode.jsとSSVMでは甲乙つけられない結果となっています。 右図はコストあたりの性能を示しています。全体的にGraviton2はIntelに比べて優れたコストパフォーマンスを示しています。 AWS Graviton2: Arm Brings Better Price-Performance than Intel 2021年 ScyllaDBのブログにおいて、Intel Xeonのm5d.8xlargeとGraviton2のm6gd.8xlarge上で分散データベースのScyllaDBを動作させたスループットを比較した結果になります。 https://www.scylladb.com/2021/09/16/aws-graviton2-arm-brings-better-price-performance-than-intel/ 上図はスループットを比較したものになります。基本的にはほぼ互角のパフォーマンスを示しています。 下図は、コストあたりのスループットを示しています。m6gdの方がコスト面で20%ほど有利なためこちらの結果ではGraviton2が15%-25%ほど高いコストパフォマンスを示す結果となりました。 Run Your Databricks Queries in Up to 71% Less Time and Reduce Costs: Select Amazon® R5d Instances Featuring 2nd Gen Intel® Xeon® Scalable Processors 2021年 Intelから発表された記事です。 Databricks レイクハウスプラットフォームの次世代エンジン Photon 対応の第2世代Intel Xeonのr5d.2xlargeと非対応のAWS Graviton2のr6gd.2xlarge上でDatabricks Runtime 9.0のクエリを実行させた結果になります。 https://www.intel.co.jp/content/www/jp/ja/partner/workload/amazon/databricks-on-aws-r5d-vs-r6gd-benchmark.html 図のように、Photon対応の第2世代Intel Xeonは最大で71%処理時間を削減しています。また、性能あたりのコストを比較しても第2世代Intel Xeonが33%低いコストで実行可能な結果を示しています。 Achieve up to 4.96 Times the BERT-Large Inference Work by Selecting AWS M6i Instances Featuring 3rd Gen Intel® Xeon® Scalable Processors 2021年 Intelから発表された第3世代Intel Xeonのm6i.8xlarge, m6i.16xlargeとAWS Graviton2のm6g.8xlarge, m6g.16xlarge上でBERT-Largeを実行させた結果です。 https://www.intel.com/content/www/us/en/partner/workload/amazon/bert-large-aws-m6i-m6g-benchmark.html 8xlargeのインスタンサイズにおいて図のように、INT8精度の第3世代Intel XeonはFP32精度のGraviton2に対して4.96倍の性能を発揮しました。さらに、同条件で16xlargeのインスタンスサイズの場合でも3.07倍の優れた性能を示しています。 Improved performance with AWS Graviton2 instances on Amazon OpenSearch Service 2022年 AWS Big Data Blogにて、Amazon OpenSearch Serviceのパフォーマンスを比較しています。 Intelベースのc5.xlarge, r5.xlargeとGraviton2ベースのc6g.xlarge, r6g.xlargeでElasticsearch 7.10を実行しています。 https://aws.amazon.com/jp/blogs/big-data/improved-performance-with-aws-graviton2-instances-on-amazon-opensearch-service/ 同じスループットでドキュメントをインジェストした結果、Graviton2はIntelに比べて低いレイテンシを示しました。 Achieve up to 27% better price-performance for Spark workloads with AWS Graviton2 on Amazon EMR Serverless 2023年 AWS Big Data Blogにて、Amazon EMR Serverlessにおける比較になります。 https://aws.amazon.com/jp/blogs/big-data/achieve-up-to-27-better-price-performance-for-spark-workloads-with-aws-graviton2-on-amazon-emr-serverless/ 図のようにSparkワークロードにおいて10%のパフォーマンス改善を達成しています。またGraviton2はx86よりも20%低いコスト 7 で実行可能なため価格性能は最終的に27%向上する結果となりました。 Get Higher Cassandra Database Throughput with AWS C6id Instances Compared to C6gd Instances 2023年 Intelから発表された第3世代Intel XeonのC6idとAWS Graviton2のC6gd上でCassandra Databaseを実行させた比較結果になります。 https://www.intel.com/content/www/us/en/content-details/780542/get-higher-cassandra-database-throughput-with-aws-c6id-instances-compared-to-c6gd-instances.html 図のように、さまざまなインスタンスサイズにおいてIntel Xeon搭載のC6idが高いスループットを示し、Graviton2に対して最大で1.36倍のパフォマンスを示しました。 64-vCPU AWS EC2 M5 Instances Achieved Up to 1.67 Times the Work of AWS EC2 M6G Instances Intelから発表された第2世代Intel Xeonのm5.16xlargeとAWS Graviton2のm6g.16xlarge上でそれぞれASP.NET, MySQL, Java server benchmarkについて比較した結果です。 https://www.intel.com/content/www/us/en/partner/workload/amazon/64-vcpu-aws-ec2-165-of-aws-m6g-benchmark.html ASP.NETフレームワークを用いたwebサイトの性能比較では、第2世代Intel Xeonが1.67倍優れている結果となりました。また、図のようにMySQLにおいても1.65倍、Java server benchmarkでは1.2倍程度Graviton2より優れた性能を示していることが分かります。 比較記事の総評 上記の調査結果から実行するベンチマークやアプリケーションによって異なる性能を示すことが分かりました。 また、Graviton2は同等インスタンスサイズにおいて、低価格で利用できるためIntel Xeonに対してコストあたりの性能に着目すると非常に高いコストパフォーマンスを示すケースが多々ありました。 しかし、Gravitonのもう1つの特徴であるエネルギー効率面に関してはクラウド上で実行するので計測の困難さもあり、定量的に比較した記事があまり見受けられませんでした。 そこで我々はAWS Graviton2, Intel Xeon搭載のOutposts ServerにインテリジェントPDUを接続してベンチマーク実行時の電力量を測定し電力効率を測定・検証しました。 ベンチマーク 計測方法 計測したOutposts Serverのフォームファクタは次の2つになります。 Outpost リソース ID ラックユニットの高さ EC2 容量 プロセッサ/アーキテクチャ vCPU メモリ ローカル NVMe SSD ストレージ ネットワークアップリンク 消費電力 重量 電源タイプ OR-STBKRBE 1U c6gd.16xlarge Graviton2 / Arm 64 128 GiB 3.8 TB 10 Gbps 0.8 kVA 13 kg AC OR-KOSKFSF 2U c6id.32xlarge Xeon Ice Lake / x86 128 256 GiB 7.6 TB 10 Gbps 1.5 kVA 16 kg AC これらのサーバにインテリジェントPDUを設置し電力量を計測しました。 インスタンスがない場合のサーバの待機電力はAWS Graviton2 176W, Intel Xeon 323Wでした。 また、ベンチマーク実行中の最大電力はAWS Graviton2 393W, Intel Xeon 1099Wでした。 それぞれ同等のインスタンスサイズである AWS Graviton2 (c6gd.16xlarge), Intel Xeon (c6id.16xlarge)上で計測しています。 検証環境の詳細は こちら の付録を参照してください。 結果 ベンチマークにはベンチマークスイートツールであるphoronix-test-suiteや、個別にOpenSSL, Unixbench, 7zip, TorchBench, Renaissanceなどを用いています。 合計24のベンチマークで計測し、可能な限り偏らないようにしました。 詳細なコマンドは こちら を参照してください。 次の図は、Intel Xeonのベンチマーク値(Score)を1として正規化した性能の結果になります。値が大きいほど良い結果を表しています。 この性能結果からは、アプリケーションによって異なりGraviton2とIntelでは全体的に大きな差はないように見られます。 次の図は、Intel Xeonのベンチマーク値(Score) / 積算電力量(kwh)を1として正規化した電力効率の結果になります。値が大きいほど電力効率が高いことを表しています。 こちらの結果では性能結果と同様にsvt-avt, ffmpeg(libx265)のようなメディアエンコードやpytorchなどの機械学習ベンチマークでIntel Xeonと比べてGraviton2は低い電力効率を示しました。 しかし、一方でIntel Xeonに比べてGraviton2が特に大規模グラフ処理ベンチマークGraph500においては2.89倍、Linux Kernelのbuild時間で3.48倍、圧縮ツール7zにおいて3.81倍高い電力効率の結果が得られました。また、性能結果では劣っていたベンチマーク openssl(aes-128-ctr), nginx, srsran(Throughput Total) john the ripper(Blowfish, bcrypt) も電力効率の面では優れた結果となっていることが分かります。 まとめ 本記事では、AWS Graviton2, Intel Xeon搭載のOutposts Serverの電力効率検証の結果を共有しました。その結果、Graviton2は特定のアプリケーションでは最大3.81倍の高い電力効率を示すことが分かりました。また、性能では劣るものも電力量あたりの性能はIntel Xeonを逆転するベンチマークが多々あるということも分かりました。 以上の検証から電力規制が厳しい環境やサステナブルな社会に、AWS Graviton2搭載のOutposts Serverは貢献に寄与すると思われます。 付録 検証環境 AWS Graviton2 (c6gd.16xlarge) OS: Amazon Linux 2023 AMI ID: ami-037f40c2ea5b01508 $ uname -a Linux ip-10-0-0-126.ap-northeast-1.compute.internal 6.1.41-63.114.amzn2023.aarch64 #1 SMP Tue Aug 1 20:47:07 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux $ openssl version OpenSSL 3.0.8 7 Feb 2023 (Library: OpenSSL 3.0.8 7 Feb 2023) $ cat byte-unixbench/UnixBench/README | grep Version Version 5.1.3 -- 2011-01-13 $ 7z 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=C.UTF-8,Utf16=on,HugeFiles=on,64 bits,64 CPUs LE) $ gcc --version gcc (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ java --version openjdk 17.0.8 2023-07-18 LTS OpenJDK Runtime Environment Corretto-17.0.8.7.1 (build 17.0.8+7-LTS) OpenJDK 64-Bit Server VM Corretto-17.0.8.7.1 (build 17.0.8+7-LTS, mixed mode, sharing) $ lscpu Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 64 On-line CPU(s) list: 0-63 Vendor ID: ARM Model name: Neoverse-N1 Model: 1 Thread(s) per core: 1 Core(s) per socket: 64 Socket(s): 1 Stepping: r3p1 BogoMIPS: 243.75 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs Caches (sum of all): L1d: 4 MiB (64 instances) L1i: 4 MiB (64 instances) L2: 64 MiB (64 instances) L3: 32 MiB (1 instance) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-63 Vulnerabilities: Gather data sampling: Not affected Itlb multihit: Not affected L1tf: Not affected Mds: Not affected Meltdown: Not affected Mmio stale data: Not affected Retbleed: Not affected Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Spectre v1: Mitigation; __user pointer sanitization Spectre v2: Mitigation; CSV2, BHB Srbds: Not affected Tsx async abort: Not affected Intel Xeon (c6id.16xlarge) OS: Amazon Linux 2023 AMI ID: ami-0310b105770df9334 $ uname -a Linux ip-10-0-1-175.ap-northeast-1.compute.internal 6.1.41-63.114.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Aug 1 20:47:25 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux $ openssl version OpenSSL 3.0.8 7 Feb 2023 (Library: OpenSSL 3.0.8 7 Feb 2023) $ cat byte-unixbench/UnixBench/README | grep Version Version 5.1.3 -- 2011-01-13 $ 7z 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=C.UTF-8,Utf16=on,HugeFiles=on,64 bits,64 CPUs Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz (606A6),ASM,AES-NI) $ gcc --version gcc (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ java --version openjdk 17.0.8 2023-07-18 LTS OpenJDK Runtime Environment Corretto-17.0.8.7.1 (build 17.0.8+7-LTS) OpenJDK 64-Bit Server VM Corretto-17.0.8.7.1 (build 17.0.8+7-LTS, mixed mode, sharing) $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 46 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 64 On-line CPU(s) list: 0-63 Vendor ID: GenuineIntel Model name: Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz CPU family: 6 Model: 106 Thread(s) per core: 2 Core(s) per socket: 32 Socket(s): 1 Stepping: 6 BogoMIPS: 5799.98 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscal l nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_know n_freq pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsav e avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsb ase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb av x512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves wbnoinvd ida arat avx512vbmi pku ospke avx512_v bmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq rdpid md_clear flush_l1d arch_capabil ities Virtualization features: Hypervisor vendor: KVM Virtualization type: full Caches (sum of all): L1d: 1.5 MiB (32 instances) L1i: 1 MiB (32 instances) L2: 40 MiB (32 instances) L3: 54 MiB (1 instance) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-63 Vulnerabilities: Gather data sampling: Vulnerable: Microcode update required Itlb multihit: Not affected L1tf: Not affected Mds: Not affected Meltdown: Not affected Mmio stale data: Mitigation; Clear CPU buffers; SMT Host state unknown Retbleed: Not affected Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence Srbds: Not affected Tsx async abort: Not affected ベンチマークコマンド一覧 hpl 8 phoronix-test-suite benchmark pts/hpl-1.0.0 hpcg phoronix-test-suite benchmark pts/hpcg-1.3.0 # [X Y Z: 104 104 104 - RT: 1800] graph500 phoronix-test-suite benchmark pts/graph500-1.0.1 # [Scale: 26] openssl(aes-128-ctr) openssl speed -multi 64 -bytes 16384 -seconds 300 -evp aes-128-ctr openssl(aes-128-gcm) openssl speed -multi 64 -bytes 16384 -seconds 300 -evp aes-128-gcm openssl(chacha20-poly1305) openssl speed -multi 64 -bytes 16384 -seconds 300 -evp chacha20-poly1305 Unixbench 9 # Version 5.1.3 Run -c 64 7zip 10 7z b 30 nginx phoronix-test-suite benchmark pts/nginx-3.0.1 # [Connections: 4000] build linux kernel phoronix-test-suite benchmark pts/build-linux-kernel-1.15.0 build llvm phoronix-test-suite benchmark pts/build-llvm-1.5.0 Renaissance akka-uct 11 java -jar renaissance-gpl-0.14.2.jar akka-uct srsran(Throughput Total) phoronix-test-suite benchmark pts/srsran-2.1.0 # [Test: PUSCH Processor Benchmark, Throughput Total] srsran(Throughput Thread) phoronix-test-suite benchmark pts/srsran-2.1.0 # [Test: PUSCH Processor Benchmark, Throughput Thread] srsran(Downlink) phoronix-test-suite benchmark pts/srsran-2.1.0 # [Test: Downlink Processor Benchmark] svt-av1 phoronix-test-suite benchmark pts/svt-av1-2.10.0 # [Encoder Mode: Preset 4 - Input: Bosphorus 4K] ffmpeg(libx265) phoronix-test-suite benchmark pts/ffmpeg-6.0.0 # [Encoder: libx265 - Scenario: Video On Demand] pytorch(resnet50) 12 python run.py resnet50 -d cpu -t eval --use_cosine_similarity --bs 32 pytorch(BERT) python run.py BERT_pytorch -d cpu -t eval --use_cosine_similarity --bs 32 john the ripper(md5) phoronix-test-suite benchmark pts/john-the-ripper-1.8.0 # [Test: MD5] john the ripper(Blowfish) phoronix-test-suite benchmark pts/john-the-ripper-1.8.0 # [Test: Blowfish] john the ripper(HMAC-SHA512) phoronix-test-suite benchmark pts/john-the-ripper-1.8.0 # [Test: HMAC-SHA512] john the ripper(bcrypt) phoronix-test-suite benchmark pts/john-the-ripper-1.8.0 # [Test: bcrypt] john the ripper(WPA_PSK) phoronix-test-suite benchmark pts/john-the-ripper-1.8.0 # [Test: WPA PSK] https://aws.amazon.com/jp/ec2/graviton/ ↩ https://aws.amazon.com/jp/about-aws/whats-new/2018/11/introducing-amazon-ec2-a1-instances/ ↩ https://aws.amazon.com/jp/about-aws/whats-new/2020/05/amazon-ec2-m6g-instances-powered-by-aws-graviton2-processors-generally-available/ ↩ https://aws.amazon.com/jp/about-aws/whats-new/2020/06/amazon-ec2-c6g-r6g-instances-amazon-graviton2-processors-generally-available/ ↩ https://aws.amazon.com/jp/about-aws/whats-new/2021/11/amazon-ec2-c7g-instances-aws-graviton3-processors/ ↩ https://aws.amazon.com/jp/about-aws/whats-new/2023/06/amazon-ec2-hpc7g-instances/ ↩ https://aws.amazon.com/jp/emr/pricing/#Amazon_EMR_Serverless ↩ https://www.phoronix-test-suite.com/ ↩ https://github.com/kdlucas/byte-unixbench ↩ https://www.7-zip.org/ ↩ https://renaissance.dev/ ↩ https://github.com/pytorch/benchmark ↩

サマリ 概要 Multi-vendor Flex-Algorithm 動作確認検証 1. リンクに対するメトリックの定義 2. リンクに対する color の定義 3. FAD の設定 4. Algorithm に参加するための設定 5. FAD の確認 6. BGP Import ポリシーの設定と確認 7. traceroute による VPN の通信経路確認 まとめ サマリ Flexible Algorithm による VPN 経路の TE を SR OS で実現 IOS XR + Junos + SR OS の Multi-vendor 環境で TE と Delay metric を含めた Algorithm の定義と動作検証に成功 この記事は Multi-AS SR 検証連載の第 15 回です。目次は こちら 概要 イノベーションセンターの吉田 晴信です。 普段の業務では Multi-AS Segment Routing に関する技術検証をしています。 第 6 回 の記事で IOS XR + Junos の2つのベンダー機器で構成される Flexible Algorithm (以降 Flex-Algorithm と呼びます) についてご紹介しました。 今回新たに Nokia SR OS (Service Router Operating System) を加えた3つのベンダー機器での Flex-Algorithm 相互動作確認をご紹介します。 さらに第 6 回は IGP metric の検証のみでしたが、今回は TE と Delay metric を用いた Flex-Algorithm の作成と動作確認を行いましたので、そちらもご紹介します。 なお、Flex-Algorithm の説明は、第 6 回記事の概要章にてご紹介しましたので、そちらをご参照ください。 Multi-vendor Flex-Algorithm 動作確認検証 本記事では、Nokia SR OS を加えた3つのベンダー機器での Flex-Algorithm 相互動作確認を行います。 その際に、IGP 、TE 、 Delay の 3 つのメトリックを使用します。 次の図で Flex-Algorithm に使用するリンクの color も含めて全体を示します。 各 Algorithm の制約ごとにトポロジーを示します。 Algorithm 128: リンク RED を除いた、IGP metric に従ったトポロジー cust-a は Algorithm 128 のトポロジーを用いて転送するため、以下のような経路を通ります。 Algorithm 129: リンク BLUE のみで、TE metric に従ったトポロジー cust-b は Algorithm 129 のトポロジーを用いて転送するため、以下のような経路を通ります。 Algorithm 130: リンク GREEN を除いた、Delay metric に従ったトポロジー cust-c は Algorithm 130 のトポロジーを用いて転送するため、以下のような経路を通ります。 検証に用いた各ルーターのバージョンは下記の通りです。 PE1、PE2: Nokia SR OS 22.7.R1 P1: Cisco IOS XR 7.4.1 P2: Junos OS 23.1R1.8 事前準備として VPRN (VRF) cust-a、cust-b、cust-c の 3 つの L3VPN を作成します。 詳しくは 第 12 回 に設定例があるので、そちらをご参照ください。 Flex-Algorithm の検証は次のステップで行います。 リンクに対するメトリックの定義 リンクに対する color の定義 FAD の設定 Algorithm に参加するための設定 FAD の確認 BGP Import ポリシーの設定と確認 traceroute による VPN の通信経路確認 1. リンクに対するメトリックの定義 各ルーターのインタフェースに対し IGP、 TE、 Delay のメトリックを指定します。 下記では、 SR OS における 3 種のメトリック、 IOS XR と Junos OS における TE metric と Delay metric の設定方法を示します。 IOS XR と Junos OS における IGP metric の設定方法については、 第 6 回 の記事で説明していますので、ご参照ください。 SR OS (PE1) SR OS における IGP、 TE、 Delay metric の設定方法を示します。 各メトリックは以下の階層にあります。 IGP metric は router isis TE metric は router mpls Delay metric は router interface 例では、PE1 の P1 向けインタフェースに IGP metric 10、TE metric 10、Delay metric 10 を設定しています。 他のインタフェースや PE2 も同様の方法で設定します。 [gl:/configure] A:user@PE1# info router isis interface "to_P1" level 2 { metric 10 } [gl:/configure] A:user@PE1# info router mpls interface "to_P1" te-metric 10 [gl:/configure] A:user@PE1# info router interface "to_P1" if-attribute { delay { static 10 } } IOS XR (P1) IOS XR における TE metric は segment-routing 階層の下にあります。 また、 Delay metric は performance-measurement 階層の下にあります。 例では、PE1 向けインタフェース Gi 0/0/0/0 に TE metric 10 と Delay metric 10、P2 向けインタフェース Gi 0/0/0/1 に TE metric 10 と Delay metric 10、PE2 向けインタフェース Gi 0/0/0/2 に TE metric 100 と Delay metric 10 を設定しています。 RP/0/RP0/CPU0:P1#show running-config segment-routing Thu Jul 20 14:55:00.724 JST segment-routing traffic-eng interface GigabitEthernet0/0/0/0 metric 10 ! interface GigabitEthernet0/0/0/1 metric 10 ! interface GigabitEthernet0/0/0/2 metric 100 ! ! ! RP/0/RP0/CPU0:P1#show running-config performance-measurement Thu Jul 20 18:42:33.471 JST performance-measurement interface GigabitEthernet0/0/0/0 delay-measurement advertise-delay 10 ! ! interface GigabitEthernet0/0/0/1 delay-measurement advertise-delay 10 ! ! interface GigabitEthernet0/0/0/2 delay-measurement advertise-delay 10 ! ! ! Junos OS (P2) Junos OS における TE metric と Delay metric は protocol isis 階層の下にあります。 例では、PE1 向けインタフェース ge-0/0/0 に TE metric 10 と Delay metric 100、P1 向けインタフェース ge-0/0/1 に TE metric 10 と Delay metric 10、PE2 向けインタフェース ge-0/0/2 に TE metric 10 と Delay metric 10 を設定しています。 set protocols isis interface ge-0/0/0.0 level 2 te-metric 10 set protocols isis interface ge-0/0/0.0 level 2 application-specific attribute-group Flex-Algo advertise-delay-metric set protocols isis interface ge-0/0/0.0 level 2 application-specific attribute-group Flex-Algo te-metric 10 set protocols isis interface ge-0/0/0.0 delay-metric 100 set protocols isis interface ge-0/0/1.0 level 2 te-metric 10 set protocols isis interface ge-0/0/1.0 level 2 application-specific attribute-group Flex-Algo advertise-delay-metric set protocols isis interface ge-0/0/1.0 level 2 application-specific attribute-group Flex-Algo te-metric 10 set protocols isis interface ge-0/0/1.0 delay-metric 10 set protocols isis interface ge-0/0/2.0 level 2 te-metric 10 set protocols isis interface ge-0/0/2.0 level 2 application-specific attribute-group Flex-Algo advertise-delay-metric set protocols isis interface ge-0/0/2.0 level 2 application-specific attribute-group Flex-Algo te-metric 10 set protocols isis interface ge-0/0/2.0 delay-metric 10 2. リンクに対する color の定義 各ルーターにてインタフェースに対し Flex-Algorithm の color を指定します。 本記事では、SR OS におけるリンクに対する color の設定方法を示します。 IOS XR と Junos OS における color の設定方法については 第 6 回 の記事で説明していますので、ご参照ください。 SR OS (PE1) SR OS における color は router interface 階層の下にあります。 また、color と Administrative Group の紐付けは routing-options if-attribute の階層で行います。 例として、PE1 の P1 向けインタフェースに対して以下のように設定します。 他のインタフェース、PE も同様の方法で設定します。 [gl:/configure] A:user@PE1# info router interface "to_P1" if-attribute { admin-group ["BLUE"] } [gl:/configure] A:user@PE1# info routing-options if-attribute admin-group "BLUE" { value 2 } admin-group "GREEN" { value 3 } admin-group "RED" { value 1 } 3. FAD の設定 各ルーターでメトリックやリンクの color の制約を含む Flexible Algorithm Definition (FAD) を設定し広告します。 また、FAD の設定では Flex-Algorithm を識別する数値 (Algorithm) 128、 129、 130 も定義します。 本検証では、IOS XR、Junos OS、SR OS 間で FAD を広告できるか確認するため、3 種類の FAD をそれぞれ別のルーターで定義します。 組み合わせは以下の通りです。 Algorithm 128: P1 (IOS XR) Algorithm 129: P2 (Junos OS) Algorithm 130: PE2 (SR OS) IOS XR (P1) P1 ではリンク RED を除いて、IGP metric に従ったトポロジーを算出する Algorithm 128 を定義し広告します。 router isis 1 flex-algo 128 advertise-definition affinity exclude-any RED ! ! Junos OS (P2) P2 ではリンク BLUE のみで、TE metric に従ったトポロジーを算出する Algorithm 129 を定義し広告します。 set routing-options flex-algorithm 129 definition metric-type te-metric set routing-options flex-algorithm 129 definition spf set routing-options flex-algorithm 129 definition admin-group include-any BLUE SR OS (PE2) PE2 ではリンク GREEN を除いて、Delay metric に従ったトポロジーを算出する Algorithm 130 を定義し広告します。 [gl:/configure] A:user@PE2# info router "Base" isis 0 flexible-algorithms { flex-algo 130 { participate true advertise "FAD-130-DELAY" } } [gl:/configure] A:user@PE2# info routing-options flexible-algorithm-definitions { flex-algo "FAD-130-DELAY" { admin-state enable metric-type delay priority 100 exclude { admin-group "GREEN" { } } } } 4. Algorithm に参加するための設定 各ルーターで広告している Algorithm へ参加するための設定をします。 SR OS (PE1) PE1 では Algorithm 128、 129、 130 に参加する設定と各 Algorithm で利用する Node SID を定義します。 PE2 でも同様の設定をします。 [gl:/configure] A:user@PE1# info router "Base" isis 0 flexible-algorithms admin-state enable flex-algo 128 { participate true } flex-algo 129 { participate true } flex-algo 130 { participate true } [gl:/configure] A:user@PE1# info router "Base" isis 0 interface "system" flex-algo 128 { ipv4-node-sid { index 1001 } } flex-algo 129 { ipv4-node-sid { index 2001 } } flex-algo 130 { ipv4-node-sid { index 3001 } } IOS XR (P1) P1 では Algorithm 128、 129、 130 で利用する Node SID を定義します。 router isis 1 ! flex-algo 129 ! flex-algo 130 ! interface Loopback0 address-family ipv4 unicast prefix-sid algorithm 128 index 1002 prefix-sid algorithm 129 index 2002 prefix-sid algorithm 130 index 3002 ! ! ! Junos OS (P2) P2 では Algorithm 128、 129、 130 で利用する Node SID を定義します。 set policy-options policy-statement Flex-Algo-SID term ALGO-SID from route-filter 10.255.0.3/32 exact set policy-options policy-statement Flex-Algo-SID term ALGO-SID then prefix-segment algorithm 128 index 1003 set policy-options policy-statement Flex-Algo-SID term ALGO-SID then prefix-segment algorithm 128 node-segment set policy-options policy-statement Flex-Algo-SID term ALGO-SID then prefix-segment algorithm 129 index 2003 set policy-options policy-statement Flex-Algo-SID term ALGO-SID then prefix-segment algorithm 129 node-segment set policy-options policy-statement Flex-Algo-SID term ALGO-SID then prefix-segment algorithm 130 index 3003 set policy-options policy-statement Flex-Algo-SID term ALGO-SID then prefix-segment algorithm 130 node-segment set protocols isis source-packet-routing flex-algorithm 128 set protocols isis source-packet-routing flex-algorithm 129 set protocols isis source-packet-routing flex-algorithm 130 set protocols isis source-packet-routing strict-asla-based-flex-algorithm set protocols isis traffic-engineering advertisement always set protocols isis export Flex-Algo-SID 5. FAD の確認 各ルーターで設定された FAD が学習されているかを確認します。 はじめに、SR OS (PE1) で IOS XR、 Junos OS、 SR OS の FAD を確認した後、IOS XR (P1) で SR OS の FAD を確認します。 SR OS (PE1) SR OS では以下のコマンドで学習している FAD を確認できます。 PE1 で IOS XR(P1) で定義された Algorithm 128、Junos OS(P2) で定義された Algorithm 129、SR OS(PE2) で定義された Algorithm 130 を確認できます。 [/] A:user@PE1# show router isis flex-algo detail =============================================================================== Rtr Base ISIS Instance 0 Flex-Algos (detail) =============================================================================== ------------------------------------------------------------------------------- Flex-Algo : 128 ------------------------------------------------------------------------------- Advertising FAD : None Participating : Yes Micro-Loop-Avoidance : Disabled Loop-Free-Alternate : Disabled L2 Oper state : UP Displaying Level 2 FAD Info ------------------------------------------------------------------------------- FADs-count : 1 Selected FAD Fad-Owner : 0000.0AFF.0002 Supported : Yes Priority : 128 Metric Type : igp Calculation Type : spf(0) Exclude : 0x2 Include Any : 0x0 Include All : 0x0 Fad Flags : 0x0 Level : L2 ------------------------------------------------------------------------------- Flex-Algo : 129 ------------------------------------------------------------------------------- Advertising FAD : None Participating : Yes Micro-Loop-Avoidance : Disabled Loop-Free-Alternate : Disabled L2 Oper state : UP Displaying Level 2 FAD Info ------------------------------------------------------------------------------- FADs-count : 1 Selected FAD Fad-Owner : 0000.0AFF.0003 Supported : Yes Priority : 0 Metric Type : te-metric Calculation Type : spf(0) Exclude : 0x0 Include Any : 0x4 Include All : 0x0 Fad Flags : 0x0 Level : L2 ------------------------------------------------------------------------------- Flex-Algo : 130 ------------------------------------------------------------------------------- Advertising FAD : None Participating : Yes Micro-Loop-Avoidance : Disabled Loop-Free-Alternate : Disabled L2 Oper state : UP Displaying Level 2 FAD Info ------------------------------------------------------------------------------- FADs-count : 1 Selected FAD Fad-Owner : 0102.5500.0004 Supported : Yes Priority : 100 Metric Type : delay Calculation Type : spf(0) Exclude : 0x8 Include Any : 0x0 Include All : 0x0 Fad Flags : M Level : L2 ------------------------------------------------------------------------------- FAD: Flexible Algorithm Definition Fad Flags: M = Prefix Metric =============================================================================== IOS XR (P1) IOS XR では以下のコマンドで学習している FAD を確認できます。 P1 で Junos OS(P2) で定義された Flex-Algo 129 と SR OS(PE2) で定義された Flex-Algo 130 を確認できます。 RP/0/RP0/CPU0:P1#show isis flex-algo 129 Wed Jul 19 13:44:09.974 JST IS-IS 1 Flex-Algo Database Flex-Algo 129: Level-2: Definition Priority: 0 Definition Source: P2.00 Definition Equal to Local: No Definition Metric Type: TE Definition Flex-Algo Prefix Metric: No Disabled: No Local Priority: 128 FRR Disabled: No Microloop Avoidance Disabled: No RP/0/RP0/CPU0:P1#show isis flex-algo 130 Wed Jul 19 13:44:12.627 JST IS-IS 1 Flex-Algo Database Flex-Algo 130: Level-2: Definition Priority: 100 Definition Source: PE2.00 Definition Equal to Local: No Definition Metric Type: Delay Definition Flex-Algo Prefix Metric: Yes Disabled: No Local Priority: 128 FRR Disabled: No Microloop Avoidance Disabled: No 6. BGP Import ポリシーの設定と確認 上記の情報を確認した後に、事前に構築した L3VPN と定義した Algorithm を紐付けるための設定をします。 SR OS (PE1) SR OS では BGP Import ポリシー にて、特定の Route Target (RT) に対する action として Algorithm を指定できます。 そういったポリシーを L3VPN に適用し、それぞれの VPN 経路と Algorithm が紐付けられます。 以下の例では、RT target-100 に Algorithm 128 を付与しています。 これにより、VPRN cust-a で使用する RT target-100 が付与された経路と Algorithm 128 が紐付けられます。 Algorithm 129、130 にも同様の方法で設定します。 [gl:/configure] A:user@PE1# info policy-options policy-statement "vrf-import-100" entry 10 { from { community { name "target-100" } } action { action-type accept flex-algo 128 } } [gl:/configure] A:user@PE1# info service vprn "cust-a" bgp-ipvpn mpls admin-state enable route-distinguisher "65000:100" vrf-import { policy ["vrf-import-100"] } vrf-export { policy ["vrf-export-100"] } auto-bind-tunnel { resolution filter resolution-filter { sr-isis true sr-policy true } } 次に、PE1 で Algorithm 128 と VPRN cust-a で使用する経路が紐付けられているか確認します。 まず、PE1 が認識している Tunnel ID を確認すると、 Algorithm 128 では Node SID 17003 に対応した Tunnel ID 524310 と、 Node SID 17004 に対応した Tunnel ID 524311 があります。 [/] A:user@PE1# show router fp-tunnel-table 1 =============================================================================== IPv4 Tunnel Table Display Legend: label stack is ordered from bottom-most to top-most B - FRR Backup =============================================================================== Destination Protocol Tunnel-ID Lbl/SID NextHop Intf/Tunnel Lbl/SID (backup) NextHop (backup) ------------------------------------------------------------------------------- (snip) 10.255.0.3/32 SR-ISIS-0 524310 17003 10.1.2.2 1/1/c1/1:0 10.255.0.4/32 SR-ISIS-0 524293 16004 10.1.2.2 1/1/c1/1:0 10.255.0.4/32 SR-ISIS-0 524308 18004 10.1.3.2 1/1/c2/1:0 10.255.0.4/32 SR-ISIS-0 524309 19004 10.1.2.2 1/1/c1/1:0 10.255.0.4/32 SR-ISIS-0 524311 17004 10.1.2.2 1/1/c1/1:0 ------------------------------------------------------------------------------- Total Entries : 14 ------------------------------------------------------------------------------- =============================================================================== 次に、VPRN cust-a のルーティングテーブルを確認すると、Nexthop の Tunnel ID が 524311 となっています。 これにより、VPRN cust-a で使用する経路が Algorithm 128 に紐付いていることがわかります。 [/] A:user@PE1# show router "100" route-table =============================================================================== Route Table (Service: 100) =============================================================================== Dest Prefix[Flags] Type Proto Age Pref Next Hop[Interface Name] Metric ------------------------------------------------------------------------------- 192.168.0.0/24 Local Local 13d23h57m 0 to_cust-a 0 192.168.10.0/24 Remote BGP VPN 09d21h53m 170 10.255.0.4 (tunneled:SR-ISIS:524311) 30 192.168.10.254/32 Remote BGP VPN 09d21h53m 170 10.255.0.4 (tunneled:SR-ISIS:524311) 30 ------------------------------------------------------------------------------- No. of Routes: 3 Flags: n = Number of times nexthop is repeated B = BGP backup route available L = LFA nexthop available S = Sticky ECMP requested =============================================================================== 7. traceroute による VPN の通信経路確認 最後に、3 つの L3VPN の経路が定義した Algorithm の制約通りになっているかを確認します。 PE1 -> PE2 VPRN cust-a Algorthm 128 で定義した制約の通り、RED のリンクを避け、IGP metric が最小になるよう、PE1 -> P1 -> P2 -> PE2 と通過していることがわかります。 [/] A:user@PE1# traceroute 192.168.10.254 router-instance "cust-a" traceroute to 192.168.10.254, 30 hops max, 40 byte packets 1 10.1.2.2 (10.1.2.2) 5.00 ms 3.56 ms 13.1 ms 2 10.2.3.2 (10.2.3.2) 3.28 ms 7.75 ms 10.5 ms 3 192.168.10.254 (192.168.10.254) 3.11 ms 9.96 ms 3.37 ms PE1 -> PE2 VPRN cust-b Algorthm 129 で定義した制約の通り、BLUE のリンクのみを利用し、TE metric が最小になるよう、PE1 -> P2 -> PE2 と通過していることがわかります。 [/] A:user@PE1# traceroute 192.168.11.254 router-instance "cust-b" traceroute to 192.168.11.254, 30 hops max, 40 byte packets 1 10.1.3.2 (10.1.3.2) 2.84 ms 3.10 ms 2.87 ms 2 192.168.11.254 (192.168.11.254) 3.10 ms 2.94 ms 3.07 ms PE1 -> PE2 VPRN cust-c Algorthm 130 で定義した制約の通り、GREEN のリンクを避け、Delay metric が最小になるよう、PE1 -> P1 -> P2 -> PE2 と通過していることがわかります。 [/] A:user@PE1# traceroute 192.168.12.254 router-instance "cust-c" traceroute to 192.168.12.254, 30 hops max, 40 byte packets 1 10.1.2.2 (10.1.2.2) 17.2 ms 6.56 ms 3.51 ms 2 10.2.3.2 (10.2.3.2) 3.34 ms 3.34 ms 9.39 ms 3 192.168.12.254 (192.168.12.254) 3.10 ms 7.79 ms 3.16 ms まとめ 本記事では、IOS XR、 Junos OS、 Nokia SR OS の 3 ベンダー間の Flex-Algorithm の相互動作を確認しました。 IGP 、 TE と Delay metric の Algorithm を定義し、動作検証を行いました。 次回の記事では、Delay Measurement について紹介予定です。 （2023/10/02 追記） 公開しました： [Multi-AS Segment Routing 検証連載 #16] Delay Measurement using IOS XR, Junos and SR OS

目次 目次 はじめに NeRFの概要と最近の課題 モデル軽量化に関する論文 PlenVDB: Memory Efficient VDB-Based Radiance Fields for Fast Training and Rendering Masked Wavelet Representation for Compact Neural Radiance Fields MobileNeRF: Exploiting the Polygon Rasterization Pipeline for Efficient Neural Field Rendering on Mobile Architectures 表現力の拡張に関する論文 K-Planes: Explicit Radiance Fields in Space, Time, and Appearance ABLE-NeRF: Attention-Based Rendering With Learnable Embeddings for Neural Radiance Field カメラ姿勢のずれの解決に焦点を当てた論文 Local-to-Global Registration for Bundle-Adjusting Neural Radiance Fields 最後に はじめに こんにちは、イノベーションセンターのメディアAIチームです。普段はコンピュータビジョンの技術開発やAI/機械学習（ML）システムの検証に取り組んでいます。6月18日から22日にかけて、コンピュータービジョン分野におけるトップカンファレンスのひとつであるCVPR2023が開催され、NTT Comからは現地とオンラインで参加しました。本記事ではCVPRで登場したNeRFに関する論文をいくつかご紹介します。 NeRFの概要と最近の課題 NeRF 1 はニューラルネットワークベースの微分可能な3次元レンダリング手法で、3次元位置と視線方向の入力に対して色と密度を返すNNモデルを使いボリュームレンダリングを行います。物体のさまざまな方向からの写真をデータセットとしてこのモデルを学習することで、未知の視点からのレンダリング(novel view synthesis)が可能になります。 2020年にNeRFが提案されてから非常に多くの改善や拡張が提案されており、CVPR2023では約40本のNeRF関連論文が採択されました。これらの論文で提案されている内容は以下のように分類されます。 計算時間やメモリ使用量を軽減する 学習したモデルを改変したり、複数のモデルを統合する 屋外のように距離制限がないシーンを撮影する 透過や反射などの表現力の向上 時間方向への拡張 悪い撮影環境（光源変化や他物体の写り込み、不正確なカメラ姿勢など）に強くする この中で特にモデル軽量化と表現力向上、そして不正確なカメラ姿勢への対策の3つのテーマについて、私たちが面白いと思った論文をピックアップしてご紹介します。 モデル軽量化に関する論文 オリジナルのNeRFモデルは9つの全結合層を含んだ多層パーセプトロン（MLP）であり、レイトレーシングの際に何度もこのモデルのforward関数を計算するので、レンダリングに時間がかかるという問題がありました。 公式の実装 によると、モデルサイズは5MBと小さいものの、GPU推論で画像を1枚レンダリングするのに最大30秒、学習には1日かかるとあり、実際の活用には困難が伴います。このレンダリングや学習の計算時間を短縮するために提案された手法をいくつかご紹介します。 PlenVDB: Memory Efficient VDB-Based Radiance Fields for Fast Training and Rendering 2 MLPの計算時間を削減するために、高次元の特徴量を3次元グリッド状に保持し、レンダリング時は入力座標を元に特徴量を参照して残りの計算を軽量なMLPで計算するという手法が提案されています。これはグリッドベース手法と言われ、さまざまな手法が提案されています。 グリッドベースNeRFモデルの特徴として、グリッド全体に対して意味のあるデータが含まれている部分が少ないというものがあり、このスパース性を計算速度の改善に繋げたのがこの論文です。VDBと呼ばれるデータ構造を採用しており、効率的に3次元データを格納できる一般的なデータ構造であるoctreeよりも高速な要素アクセスが可能です。 また、VDBのGPU実装である NanoVDB を活用することで、iPhone12のようなモバイル環境で720pのレンダリングを30FPSで実行できるとしています。 こちらは 公式実装 をA100 GPUx1で実験した結果です。NanoVDBを使わなくてもかなり高速にレンダリング可能であることがわかります。 model filesize train time rendering time PSNR↑ mic 59.6MB 33min 2.7s 33.18 drums 100MB 34min 2.98s 25.39 materials 175MB 37min 2.05s 29.59 Masked Wavelet Representation for Compact Neural Radiance Fields 3 スパースなデータを取り扱う手法として、データ構造を工夫する以外にデータを圧縮するという方法があります。ECCV2022で発表されたTensoRF 4 はテンソル分解と呼ばれる次元削減手法を用いて、3次元データを2次元行列と1次元ベクトルとの外積の和に分解しています。この手法はデータ構造を工夫する手法とは異なり、メモリ使用量や学習済みモデルのファイルサイズを軽減できます。 本手法はこのTensoRFをさらに軽量化するために、TensoRFモデル内の2次元行列をウェーブレット基底で表現しデータを圧縮することを提案しています。また、非ゼロ部分を示すマスクを学習させることで、95%以上の値が0であるスパースなパラメータを学習できたとしています。 こちらは 公式実装 をA100 GPUx1で実験した結果です。 model filesize(圧縮前) filesize(圧縮後) train time rendering time PSNR↑ mic 63MB 551KB 85min 17s 33.30 drums 67MB 989KB 62min 17s 25.46 materials 78MB 1013KB 96min 13s 29.57 この実験で示されているように、学習済みモデルには非常に強力な圧縮をかけることができており、スパースなパラメータを学習できていることがうかがえます。 MobileNeRF: Exploiting the Polygon Rasterization Pipeline for Efficient Neural Field Rendering on Mobile Architectures 5 本手法ではボリュームレンダリングを行わず、テクスチャ付き三角メッシュを学習するため、一般的なレンダリングエンジンの最適化の恩恵を受けることができます。学習は既存のNeRFと同様に日単位の時間がかかってしまうものの、レンダリング時はモバイル環境でもリアルタイムに動作します。また、モデルがメッシュで表現されているため、モデルの変形や合成、削除などを一般的な3DCGにおける頂点操作で行うことも筆者は示唆しています。 以下の節で論文の画像を用いながら学習とレンダリングの概要を説明します。 Rendering 原論文 Figure 2 から引用 学習済みモデルは三角メッシュと特徴量空間におけるテクスチャマップ、そして軽量なMLPからなります。 まずGPUのレンダリングバッファを用いて特徴量空間におけるレンダリング画像を生成します(図c)。そして各ピクセルに対してMLPを適用することでRGB空間における画像を生成します(図d)。この一連の処理はWebGLで実装でき、プロジェクトページではモデルを表示するHTMLが公開されています。 Training 原論文 Figure 3 から引用 学習開始時に、まずグリッド状に組まれた初期メッシュを用意します。そしてそのメッシュの頂点位置と、特徴量と透明度を予測するMLP、特徴量から色を予測する軽量なMLPをNeRFの手法で最適化します。ここで特徴量と透明度については光線の位置のみを入力とし、軽量なMLPは特徴量と光線方向を入力としています。そのため光線方向に依存しない特徴量と透明度は、学習が済んだ後テクスチャマップにベイク(bake)できるため、PNG画像として保存されます(Rendering図のb)。 Limitation この手法には半透明な物体を表現するのが難しいという欠点があります。 デモページ でドラムのモデルを表示した結果が次の画像です。膜の部分がうまくレンダリングできていないというのが見てわかると思います。 表現力の拡張に関する論文 K-Planes: Explicit Radiance Fields in Space, Time, and Appearance 6 グリッドベースのNeRFモデルの軽量化手法であるTensoRFでは3次元空間を平面とベクトルに分解したのに対し、本手法では 平面、 平面、 平面の3つの平面の組に分解することを提案しています。これは高次元の空間を扱うNeRFモデルにも適用でき、例えば時間経過で物体が変形するシーンにおいても、空間 の3軸と時間 の1軸から選んだ6組の平面( )で学習できるのが特長です。学習時間も比較的短く、既存手法のDyNeRF (CVPR2022)が8GPUで1週間かけていたサンプルを、1GPUで4時間に短縮できています。 原論文 Figure 1 から引用 ABLE-NeRF: Attention-Based Rendering With Learnable Embeddings for Neural Radiance Field 7 NeRFで表現が不得意な物体として光沢のある表面、透明な面が挙げられます。NeRFのボリューメトリックレンダリングで輝度は各点の密度σと点のサンプリング間隔δに影響されますが、NeRFで各点のσは視線方向によらず固定されています。これによって、NeRFは異なる角度で透過特性と反射特性の両方を示す表面点の色を予測することが困難であり、その結果「濁った」外見になってしまうという課題があります。ABLE-NeRFではAttentionベースのネットワークを利用し、Learnable Embeddingsの導入によって間接照明効果を捉えることで解決しています。 Attention-based Volumetric Rendering ボリューメトリックレンダリングにおいて点の重みは自身の重みと、光線上に存在する前の点の重みに依存します。NeRFでは光線上の点の重みをσとδに基づいて割り当てていましたが、ABLE-NeRFではTransformerモデルのAttention計算によって個々の点の重みを決定します。 ここでは与えられた光線に対して、mip-NeRF 8 で説明されているIPE（Integrated Positional Encoding）でエンコードされた、光線に沿ったボリュームの円錐台を N 個サンプリングします。各円錐ボリュームは、Embeddingブロックを通過して、ボリューム埋め込み を生成します。（ i はカメラからの光線に沿った位置）また、ViT 9 のclassトークンと同様に、同じ次元のRayトークン(R)をシーケンスに付加してTransformerで処理します。 Attentionの際はMaskを利用し、ボリューム埋め込みが注目する対象を自分自身とRayトークン、光線に沿って前方にあるボリュームだけに限定します。 Learnable Embeddings ABLE-NeRFでは、他の光源から放射される間接照明効果を捉えるため、光線に沿ったボリュームを超える外部光源に対する問い合わせプロセスとしてLearnable Embeddings（LE）を組み込んでいました。 LEはViTのclassトークンと同様に静的な照明情報を保存するために使用される学習可能なネットワーク・パラメータ（メモリ・トークン）です。学習プロセスにより、シーンの照明情報がメモリとして符号化されます。推論の際、ボリューム埋め込みはLEとのCross Attentionを介して潜在空間にマッピングされ、その後、視線方向トークン(Viewトークン)でデコードされます。視線方向トークンはカメラポーズを16バンドでフーリエ符号化し、線形層でLEと同じ次元にマッピングしたものとなっています。 ABLE-NeRFの構成は下図のようになっています。AB Transformerは光線に沿ったボリュームの直接照明を出力し、LE Transformerはボリュームの視線依存の照明を出力します。2つに分離することでオーバーフィッティングを防ぐことができるようです。2つの出力を組み合わせるため、sRGBに変換する固定マッピング関数を適用して最終的な出力を得ています。 原論文 Figure 2 から引用 結果 こちらは 公式実装 をA100 GPUx8で実験した結果（レンダリング時はA100 GPUx1）です。 model train time rendering time PSNR↑ mic 25h 59s 36.84 drums 25h 59s 26.87 materials 25h 59s 35.46 この実験で示されているように、PSNRでは上の圧縮モデルの精度を上回っており、特に光沢表現が多いmaterialsで優れた精度を示しました。しかし、学習に非常に時間がかかっています。これは光線に対してAB Transformer、LE TransformerでAttention計算を繰り返し行うので計算量が膨大であるためだと考えられます。 カメラ姿勢のずれの解決に焦点を当てた論文 Local-to-Global Registration for Bundle-Adjusting Neural Radiance Fields 10 カメラ位置と姿勢が正確でない場合、レンダリングの際に歪みが生じてしまいます。そのため、bundle adjustmentsにより、カメラの位置と姿勢を正確に推論し、レンダリングの改善をします。 L2G-NeRFでは、2つの手法を組み合わせたアプローチの提案をしています。まず、異なる画像間で対応するピクセルを合わせる処理をDNNの学習により最適化され、ピクセルごとに最適なアライメントを見つけることができます。次に、グローバルアライメントではピクセルごとの対応関係に基づいて、異なる視点からの画像を重ね合わせるために画像の剛体変換のパラメータを推定しています。これにより、異なる視点からの画像を正確に重ね合わせることができレンダリングの際に生じる歪みを改善できます。下の図を見るとL2G-NeRFが他の手法と比較し、カメラ姿勢の最適化が適切にされていることがわかります。 原論文 Figure 8 から引用 最後に 本ブログでは、私たちが興味を持ったCVPR2023の論文についてご紹介しました。NTT Comでは、今回ご紹介した分野に限らず、画像や映像、さらには音声言語も含めたさまざまなメディアAI技術の論文調査や研究開発に今後も積極的に取り組んでいきます。 Ben Mildenhall, Pratul P. Srinivasan, Matthew Tancik, Jonathan T. Barron, Ravi Ramamoorthi, Ren Ng. NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis. In ECCV2020 ↩ Han Yan, Celong Liu, Chao Ma, Xing Mei. PlenVDB: Memory Efficient VDB-Based Radiance Fields for Fast Training and Rendering. In CVPR2023 ↩ Daniel Rho, Byeonghyeon Lee, Seungtae Nam, Joo Chan Lee, Jong Hwan Ko, Eunbyung Park. Masked Wavelet Representation for Compact Neural Radiance Fields. In CVPR2023 ↩ Anpei Chen, Zexiang Xu, Andreas Geiger, Jingyi Yu, Hao Su. TensoRF: Tensorial Radiance Fields. In ECCV2022 ↩ Zhiqin Chen, Thomas Funkhouser, Peter Hedman, Andrea Tagliasacchi. MobileNeRF: Exploiting the Polygon Rasterization Pipeline for Efficient Neural Field Rendering on Mobile Architectures. In CVPR2023 ↩ Sara Fridovich-Keil, Giacomo Meanti, Frederik Warburg, Benjamin Recht, Angjoo Kanazawa. K-Planes: Explicit Radiance Fields in Space, Time, and Appearance. In CVPR2023 ↩ Zhe Jun Tang, Tat-Jen Cham, Haiyu Zhao. ABLE-NeRF: Attention-Based Rendering with Learnable Embeddings for Neural Radiance Field. In CVPR2023 ↩ Jonathan T. Barron, Ben Mildenhall, Matthew Tancik, Peter Hedman, Ricardo Martin-Brualla, Pratul P. Srinivasan. Mip-NeRF: A Multiscale Representation for Anti-Aliasing Neural Radiance Fields. In ICCV2021 ↩ Alexey Dosovitskiy, Lucas Beyer, Alexander Kolesnikov, Dirk Weissenborn, Xiaohua Zhai, Thomas Unterthiner, Mostafa Dehghani, Matthias Minderer, Georg Heigold, Sylvain Gelly, Jakob Uszkoreit, Neil Houlsby. An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale. In ICLR2021 ↩ Yue Chen, Xingyu Chen, Xuan Wang, Qi Zhang, Yu Guo, Ying Shan, Fei Wang. Local-to-Global Registration for Bundle-Adjusting Neural Radiance Fields. In CVPR2023 ↩

サマリ 概要 検証 1. Color 200 用 SR Policy の作成 SR Policy の確認 2. Color の付与と広告 経路の確認 動作確認 まとめ サマリ SR-MPLS + VPNv4 + explicit path による BGP Color を用いた Traffic Engineering (TE) を実現 IOS XR + Junos + SR OS の Multi-vendor 環境での動作検証に成功 この記事は Multi-AS Segment Routing 検証連載の第 14 回です。過去の記事一覧は こちら にあります。 概要 イノベーションセンターの田島です。本連載のような Segment Routing 関連の技術検証の指揮を執ったり、自動化による高度な運用を開発したりしています。 本記事では IOS XR + Junos + SR OS の Multi-vendor における Traffic Engineering (TE) についてご紹介します。 Segment Routing では ingress PE において転送するパスを決定し、適切な SID をパケットに付与することで TE を実現します。 本記事では TE の対象となる VPN 経路に対して BGP Color Extended Community (以下単に Color) を付与することで転送するパスを切り替える様子を示します。 第 4 回の記事 でもご紹介した通り、すでに IOS XR + Junos の Multi-vendor 環境での検証は実施済みで、 今回はそれらに Nokia SR OS を加えて検証します。 VPNv4 による L3VPN の相互接続は 第 12 回の記事 にて紹介済みですので、そちらも併せてご参照ください。 検証 本記事での検証は、L3VPN の prefix ごとに Color をつけて広告し、その Color によって転送する経路を変えるものです。 Color そのものや SR Policy に関する説明は 第 4 回の記事 を、 L3VPN に関する説明や設定は 第 12 回の記事 をご覧ください。 検証トポロジーは次のようなシンプルなものを用意します。 各 PE には VRF 100と VRF 200 が設定され、それぞれの経路に Color 100 と Color 200 を付与して広告します。 Color 100 の方は直通の最短経路で、Color 200 の方は迂回する経路での転送を実現します。 本記事では L3VPN はすでに開通しているとし、その後の設定を SR OS を中心に紹介します。 Color による TE は次の 2 ステップで設定します。 Color 200 用 SR Policy の作成 Color の付与と広告 なお本記事では下記のバージョンで検証しました。 rt01: IOS XR 7.4.1 rt02: Junos 21.3R1.9 rt03: SR OS 22.7.R1 1. Color 200 用 SR Policy の作成 Endpoint と Color を指定して SR Policy を作成します。 SR OS では SR Policy 用のラベルブロック (LB) を指定し、 BSID をそのブロックの中から手動で採番する必要があります。 rt01 向けの Segment List は、トポロジー図にあるように rt02 16002 を経由するものです。 router "Base" { mpls-labels { reserved-label-block "SR-Policy-LB" { start-label 52400 end-label 52499 } } segment-routing { sr-policies { admin-state enable reserved-label-block "SR-Policy-LB" static-policy "rt01-color200-policy" { admin-state enable color 200 endpoint 10.255.0.1 head-end local binding-sid 52410 segment-list 1 { admin-state enable segment 1 { mpls-label 16002 } segment 2 { mpls-label 16001 } } } } } } SR Policy の確認 設定した SR Policy が有効になっているかを表示して確認します。 Active になっていることが表示されます。 rt03 (SR OS) A:user@rt03# /show router segment-routing sr-policies static end-point 10.255.0.1 color 200 =============================================================================== SR-Policies Path =============================================================================== ------------------------------------------------------------------------------- Type : srMpls Active : Yes Owner : static Color : 200 Head : 0.0.0.0 Endpoint Addr : 10.255.0.1 RD : 0 Preference : 100 BSID : 52410 TunnelId : 917506 Age : 231 Origin ASN : 0 Origin : 0.0.0.0 NumReEval : 0 ReEvalReason : none NumActPathChange: 0 Last Change : 06/27/2023 05:09:21 Maintenance Policy: N/A Path Segment Lists: Segment-List : 1 Weight : 1 S-BFD State : Down S-BFD Transitio*: 0 Num Segments : 2 Last Change : 06/27/2023 01:41:02 Seg 1 Label : 16002 State : resolved-up Seg 2 Label : 16001 State : N/A =============================================================================== 2. Color の付与と広告 MP-BGP で VPN 経路を広告するときに Color を付与します。 VRF の export policy に設定することにより実現します。 なお、 SR OS では Color を示す color:00:<10進数> という書き方と、 BGP Extended Community 一般の記法で Color を指定する ext:030b:<16進数> という書き方ができます。 今回は見やすい前者で設定します。 policy-options { community "color-100" { member "color:00:100" { } } community "target-100" { member "target:65000:100" { } } policy-statement "vrf-export-100" { entry 10 { action { action-type accept community { add ["target-100"　"color-100"] } } } } } service { vprn "100" { bgp-ipvpn { mpls { vrf-export { policy ["vrf-export-100"] } } } } } 経路の確認 rt03 で設定した Color は他のルーターで参照できます。 対向の rt01 では次のように Color 100 の経路と Color 200 の経路がそれぞれ認識されます。 rt01 (IOS XR) RP/0/RP0/CPU0:rt01#show bgp vpnv4 unicast rd 65000:100 192.168.103.0/24 detail Tue Jun 27 14:56:46.266 JST BGP routing table entry for 192.168.103.0/24, Route Distinguisher: 65000:100 Versions: Process bRIB/RIB SendTblVer Speaker 22 22 Flags: 0x00041001+0x00000000; Last Modified: Jun 27 14:56:00.872 for 00:00:45 Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Flags: 0x2000000085060005, import: 0x9f Not advertised to any peer Local 10.255.0.3 (metric 10) from 10.255.0.3 (10.255.0.3), if-handle 0x00000000 Received Label 524284 Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 1, version 22 Extended community: Color:100 RT:65000:100 Source AFI: VPNv4 Unicast, Source VRF: 100, Source Route Distinguisher: 65000:100 RP/0/RP0/CPU0:rt01#show bgp vpnv4 unicast rd 65000:200 192.168.203.0/24 detail Tue Jun 27 15:38:56.569 JST BGP routing table entry for 192.168.203.0/24, Route Distinguisher: 65000:200 Versions: Process bRIB/RIB SendTblVer Speaker 31 31 Flags: 0x00363001+0x00000000; Last Modified: Jun 27 15:38:49.872 for 00:00:06 Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Flags: 0x2000000085060005, import: 0x9f Not advertised to any peer Local 10.255.0.3 (metric 10) from 10.255.0.3 (10.255.0.3), if-handle 0x00000000 Received Label 524283 Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 1, version 27 Extended community: Color:200 RT:65000:200 Source AFI: VPNv4 Unicast, Source VRF: 200, Source Route Distinguisher: 65000:200 一方で逆向きの、対向ルーターが広告する Color を rt03 で確認します。 それぞれの経路に Color 100 と Color 200 が付与されています。 rt03 (SR OS) A:user@rt03# /show router bgp routes vpn-ipv4 rd 65000:100 detail (snip) Network : 192.168.101.0/24 Nexthop : 10.255.0.1 Route Dist. : 65000:100 VPN Label : 24004 Path Id : None From : 10.255.0.1 Res. Nexthop : n/a Local Pref. : 100 Interface Name : to_rt01 Aggregator AS : None Aggregator : None Atomic Aggr. : Not Atomic MED : 0 AIGP Metric : None IGP Cost : 20 Connector : None Community : color:00:100 target:65000:100 Cluster : No Cluster Members Originator Id : None Peer Router Id : 10.255.0.1 Fwd Class : None Priority : None Flags : Used Valid Best Incomplete Route Source : Internal AS-Path : No As-Path Route Tag : 0 Neighbor-AS : n/a Orig Validation: N/A Source Class : 0 Dest Class : 0 Add Paths Send : Default Last Modified : 00h13m13s VPRN Imported : 100 A:user@rt03# /show router bgp routes vpn-ipv4 rd 65000:200 detail (snip) Network : 192.168.201.0/24 Nexthop : 10.255.0.1 Route Dist. : 65000:200 VPN Label : 24005 Path Id : None From : 10.255.0.1 Res. Nexthop : n/a Local Pref. : 100 Interface Name : to_rt01 Aggregator AS : None Aggregator : None Atomic Aggr. : Not Atomic MED : 0 AIGP Metric : None IGP Cost : 20 Connector : None Community : color:00:200 target:65000:200 Cluster : No Cluster Members Originator Id : None Peer Router Id : 10.255.0.1 Fwd Class : None Priority : None Flags : Used Valid Best Incomplete Route Source : Internal AS-Path : No As-Path Route Tag : 0 Neighbor-AS : n/a Orig Validation: N/A Source Class : 0 Dest Class : 0 Add Paths Send : Default Last Modified : 00h13m46s VPRN Imported : 200 動作確認 Color 100 と Color 200 が付いたそれぞれの宛先に対して traceroute をすることで、直通か迂回路かを使い分けられていることが転送ホップ数から確認できます。 rt03 (SR OS) A:user@rt03# /traceroute 192.168.101.254 router-instance 100 probe-count 1 traceroute to 192.168.101.254, 30 hops max, 40 byte packets 1 10.0.2.1 (10.0.2.1) 3.99 ms A:user@rt03# /traceroute 192.168.201.254 router-instance 200 probe-count 1 traceroute to 192.168.201.254, 30 hops max, 40 byte packets 1 10.0.3.1 (10.0.3.1) 2.62 ms 2 10.0.1.1 (10.0.1.1) 8.97 ms 経路表でも直接 IS-IS で転送先が解決される Color 100 と、 SR Policy によって転送される Color 200 が確認できます。 この tunnel-id 917506 は「SR Policy の確認」節での show 結果に出ている Policy が使用されていることを示します。 [/] A:user@rt03# /show router service-name 100 route-table 192.168.101.0/24 =============================================================================== Route Table (Service: 100) =============================================================================== Dest Prefix[Flags] Type Proto Age Pref Next Hop[Interface Name] Metric ------------------------------------------------------------------------------- 192.168.101.0/24 Remote BGP VPN 00h21m21s 170 10.255.0.1 (tunneled:SR-ISIS:524298) 20 ------------------------------------------------------------------------------- No. of Routes: 1 Flags: n = Number of times nexthop is repeated B = BGP backup route available L = LFA nexthop available S = Sticky ECMP requested =============================================================================== [/] A:user@rt03# /show router service-name 200 route-table 192.168.201.0/24 =============================================================================== Route Table (Service: 200) =============================================================================== Dest Prefix[Flags] Type Proto Age Pref Next Hop[Interface Name] Metric ------------------------------------------------------------------------------- 192.168.201.0/24 Remote BGP VPN 00h15m31s 170 10.255.0.1 (tunneled:SR-Policy:917506) 0 ------------------------------------------------------------------------------- No. of Routes: 1 Flags: n = Number of times nexthop is repeated B = BGP backup route available L = LFA nexthop available S = Sticky ECMP requested =============================================================================== 逆向きの rt01 から rt03 宛ての経路についても同様に、直通経路と、途中に 1 ホップする経路が使い分けられています。 rt01 (IOS XR) RP/0/RP0/CPU0:rt01#traceroute 192.168.103.254 vrf 100 probe 1 Tue Jun 27 15:32:02.036 JST Type escape sequence to abort. Tracing the route to 192.168.103.254 1 192.168.103.254 2 msec RP/0/RP0/CPU0:rt01#traceroute 192.168.203.254 vrf 200 probe 1 Tue Jun 27 15:32:03.991 JST Type escape sequence to abort. Tracing the route to 192.168.203.254 1 10.0.1.2 [MPLS: Labels 16003/524283 Exp 0] 3 msec 2 192.168.203.254 4 msec まとめ 本記事では、SR OS を含めた Multi-vendor 環境における Color-Based TE の検証結果を紹介しました。 （2023/9/19 編集・追記） 次のエントリは予定を変更して Flex-Algo の相互運用性の記事を公開しました： [Multi-AS Segment Routing 検証連載 #15] IGP Flexible Algorithm Interoperability Updates

はじめに こんにちは、イノベーションセンターの黒木（GitHub： krk09 ）と鍔木（GitHub： takuma0121 ）です。 今回はOT（Operational Technology）ネットワークのセキュリティリスク可視化サービスである OsecT（オーセクト） のリニューアル提供を開始したので、サービス運用で得られた知見をもとに、どのような機能改善をしたのか紹介します。 OsecTとは OsecTとは工場などのOTシステムのセキュリティリスクを可視化・検知するサービスです。 多様化する工場システムのセキュリティ脅威に対して、パケット解析するセンサー機器を設置するだけで、OTシステムへの影響なく、ネットワークの可視化と脅威・脆弱性検知ができます。 早期にリスク感知できる状態を作り、工場停止による損失を未然に防ぐことができます。 詳しくは過去のブログ記事に書いているので、興味がある人はぜひ見てください。 （ OsecTリリース ・ OsecT前編 ・ OsecT後編 ） サービス運用から得た知見 2022年4月にサービスリリースしてから1年ほど経過して、実証実験では得られなかった知見を得ることができました。 その1つが OTネットワークがITネットワークと分離されていない環境が多くある です。この記事ではそのような環境をIT/OT非分離環境と呼びます。 このような環境でOsecTを利用すると、性能不足や過検知が課題になることがわかりました。 その他にもOsecTの利用ユーザーが増えていくにつれて、「可視化画面やアラートが見にくい」「自分で設定したい、またはしたくない」「OTプロトコルの可視化・検知を充実させてほしい」などの声もいただきました。 リニューアル提供での主な改善点 本章ではサービス運用から得られた知見をもとにした改善点を、可視化・検知機能を有するクラウド上にあるOsecTコアと、パケット解析機能を有するOsecTセンサーに分けてご紹介します。 OsecTコア OsecTを利用できる環境を広げるためにIT/OT非分離環境への対応や、脅威検知機能の刷新やサービス名の編集をはじめとしてより使いやすく、分かりやすくするための改善を行いました。 IT/OT非分離環境への対応 これまでITネットワークとOTネットワークが分離されていない環境にOsecTを置いた場合、IT機器によるインターネットへのアクセスが含まれることによって、管理していないインターネット上のIPアドレス等もOsecT上で端末として可視化/検知されてしまうことがありました。その結果、端末（IPアドレス）数が多くなりすぎて処理に影響がでたり過検知によってアラートが大量に出てしまったりするという問題がありました。 これらの問題に対して、グローバルIPアドレスやインターネットドメインを集約する機能を追加することで、IT/OT非分離環境においてもOsecTを利用できるようにしました。 集約されたグローバルIPアドレスは以下の internet_address(v4) などのように1つにまとめて可視化されます。 OTネットワークがITネットワークと分離された環境向けに、従来通り集約せずに可視化することもできます（システム設定からインターネットアドレス可視化の設定をONにする）。 また、一部のグローバルIPアドレスやインターネットドメインのみを集約対象から除外して可視化したい場合のための設定項目も用意しています。 IT/OT非分離環境において、誤ってグローバルIPアドレスを可視化する設定にすると、管理対象外のIPアドレス（グローバルIPアドレス）もLAN内の端末と同じように扱われ、OsecT上にサービス仕様を超えた端末（1,000端末）数が表示されることがあります。 そのような場合に、お客さまへ注意喚起して設定の見直しを促すためにメールで通知する機能も併せて追加しました。 この通知を受け取ったお客さまには、管理対象外のIPアドレスまで可視化対象になっていないかご確認、及び適切な設定をお願いできればと思います。 学習ベース脅威検知の追加 元々OsecTに備わっているホワイトリスト方式の異常検知は、自動化されたシステムのように、端末が機械的な通信を繰り返し、通信先があまり変わらないような厳格なOT環境においては有効です。しかしそうではない環境、例えば人手による端末操作などにより通信先が頻繁に変動する環境では過検知を引き起こしてしまいます。 通信先などが変動するような環境においても適用できる学習ベースの検知機能として、今回新しくIP統計検知を追加しました。 IP統計検知は、IPアドレス単位で宛先IPアドレス数や送受信パケット数などといったIP通信の傾向を表す数値を元に異常を検知する機能です。 具体的には、一定時間毎にIPアドレス単位で宛先IPアドレス数や送信/受信パケット数などの分析に使う値を算出し、信頼区間分析/主成分分析をそれぞれ行います。 信頼区間分析は、学習時に各値で99.9%信頼区間を求めて算出した閾値を元に検知します。 主成分分析では、学習時に各値をまとめた主成分分析によって得られた主成分毎の最小値/最大値を閾値として検知します。 信頼区間分析では各値を個別に分析して検知し、主成分分析では各値を相関的に分析して検知するイメージです。 端末情報表示の整理 「端末」の「IP別接続サービス」タブの名称を「詳細」に変更し、それに伴って表示する情報を拡充しました。 元々MACアドレスやベンダー名など接続サービス以外の情報も表示していたため、実態に合った名称となり、「一覧」タブに表示されているホスト名やOSなどの情報も表示されるようになりました。 また、検知アラート画面において、IPアドレスがリンクになっていたりホバーで端末の情報が表示されたりと挙動が統一されていなかったものを、ホバー表示に統一した上で表示内容を統一・整理しました。 脅威検知アラートのわかりやすさ向上 各検知アラートがどんなアラートなのか（何故発生したのか）分かりやすくするために、検知アラートの一覧ページに各アラートの概要を説明する項目を追加しました。 具体例として新規端末アラートの場合「新規端末192.168.0.xが出現」、脆弱端末アラートの場合「サポート切れOS Windows 7の端末192.168.0.xが出現」といった説明が表示されます。 ポート番号に対する名称変更機能の追加 これまではポート番号やパケットの内容から自動で判定できたプロトコルのみサービス名を表示していましたが、特定のポート番号に対してユーザーがサービス名を編集できる機能を今回追加しました。 TCP/IP上で独自プロトコルを使っている場合などに、この機能を使ってサービス名を設定することによって、自動で判定できないプロトコルでも端末一覧などの可視化のページでユーザーの設定したサービス名が表示されるようになります。 脅威検知の使い勝手向上 より簡単な操作で脅威検知機能を利用できるよう、学習期間・検知期間を細かく設定しなくても学習状況から自動的に検知へ移行する機能を追加しました。 また、どのようなOT環境でも共通的に使っていただきたいおすすめの検知種別については、事前設定不要で利用できるようなりました。 従来の機能はアドバンスモードとして残しているため、学習と検知の期間をそれぞれ設定したい場合はアドバンスモードをONにすることで従来通りの設定が可能です。 OsecTセンサー センサーでは、IT/OT非分離環境でのトラフィック量増加に対応するための性能向上や、ニーズの多いOTプロトコル（CC-Linkファミリー）への対応を行いました。 性能向上 これまでトラフィック量が比較的少ないOTネットワークを想定していたため、tcpdumpでPcapを生成後、 Zeek やSuricataなどのパケット解析ツールでログ化する処理をしていました。 しかしながら、この方式では数十Mbpsが性能の限界（サービス仕様上は10Mbps）だったため、インターフェースから直接ログ化する方式に変更しました。 従来の方式から新しい方式に変更することで、Pcapの生成→ログ化といった2段階の処理が解消されたことや、Pcapのパケット解析だとシングルコアでしか動作しなかったツールがマルチコアで動作できるようになり、数百Mbpsまでのトラフィックを処理できるようになりました（サービス仕様上は100Mbps）。 OTプロトコル（CC-Linkファミリー）への対応 今回のリリースでは、日本国内で開発され、広く普及しているOTプロトコルである CC-Linkファミリー のプロトコルに対応しました。 市販のOTセキュリティ製品のプロトコル対応状況は、製品毎プロトコル毎に異なり、プロトコル名を表示するだけのものからペイロードにある変数を使って異常を検知するものまでありますが、OsecTではCC-Linkのコマンドレベルでの可視化・検知まで実現できるようにしました。 OTプロトコルの対応にはZeekおよびSpicyを利用しており、具体的な実装方法は 【日本初紹介】Zeek・Spicyの使い方まとめ を参照していただければと思います。 OTプロトコルは業界・業種・機器メーカー毎ごとに存在するため、すべてのOTプロトコルに対応することは難しいです。一方で、今回のリニューアルを通じてOTプロトコルに対応するためのフレームワークや具体的な実装方法が確立できつつあります。 今後もユーザーのニーズを汲み取って、リリースごとに優先度の高いOTプロトコルに対応していきたいと考えています。 おわりに 今回はサービス運用を通じて得られた知見をもとに、どのような機能改善をしたのかご紹介しました。 実証実験だけでは明らかにならない課題もあり、サービスリリース後も素早く課題を見つけて改善を続けていくことがより良いサービスの実現につながると感じました。 OsecTは低価格でOTネットワークの可視化や脅威検知ができるので、セキュリティ対策に手が出ていない・不十分と感じている企業さまにはぜひご利用いただきたいです。 ご興味がある企業さまは、 WideAngle (OsecT) ご紹介ページ からお問い合わせいただければ幸いです。

わかること IoTプラットフォームにおける独自のイベント処理ロジックの構築について Things Cloud のノーコードツール「Analytics Builder」でできること ※本記事は、Things Cloud バージョン10.14 （8月以降リリース予定）の利用を想定しています。 はじめに こんにちは、Things Cloud のカスタマーサクセスチーム 井上です。 私たちは、5G＆IoTサービス部で IoTプラットフォーム「Things Cloud」のサービス開発やお客さまへの技術支援を担当しています。 早速ですが、皆さんは「IoT化」という言葉を聞いて何を思い浮かべるでしょうか。データの収集から可視化、分析、異常検知、通知、自動制御などIoTで実現できることは幅広く、適用可能なビジネス領域や業界も多様です。特に最近では、専門的なスキルを必要とせず手軽にIoT化を実現できるIoTサービスが多く登場しています。 本記事では、IoTプラットフォームThings Cloudに搭載されているデータ処理機能の1つである「Analytics Builder」を利用して、ノーコードで独自の分析処理を構築する方法ご紹介します。 Analytics Builderとは Things Cloudの紹介 Analytics Builderを紹介する前に、 Things Cloud のサービスについて、概要をご紹介します。 Things Cloudは、NTT CommunicationsのSmart Data Platform（略称SDPF）の中で、データ収集機能を提供するプラットフォームの1つです。 製品やセンサーなどのIoTデバイスからデータを収集し蓄積できるクラウドサービスで、簡単な操作でデータの可視化やアラート通知を実現でき、デバイス接続/ユーザー管理/デバイス管理などIoT導入に必要な機能一式が揃ったIoTプラットフォームです。 Things Cloudには、データをリアルタイムで処理し、データに基づいて通知や制御などのアクションを実行するためのデータ処理機能がいくつか搭載されています。 Things Cloudのデータ処理では、リアルタイムに流れているイベント（データ）をトリガーとして処理を行い、処理結果としてデータベースへの書き込みやメール送信、通知、制御を行います。 データ処理機能の1つとして、今回紹介するAnalytics Builder 1 があります。 Analytics Builderを活用することで、テンプレートベースの標準機能だけでは実現できない独自のデータ処理機能をノーコードで簡単に構築できます。 Analytics Builderの概要 Analytics Builderは、ブラウザ上でグラフィカルに、データ処理モデルを構築できる機能です。 下図のように、事前定義された処理ブロックを線でつなぐことで処理モデルを構築できます。 ブロックは処理内容、ブロック間をつなぐ矢印はデータの入出力を表しています。 Analytics Builderの技術的観点や利用方法などの詳細を知りたい方は、 開発者ドキュメント 〜 Analytics Builder をはじめる〜 をご参照下さい。 ノーコードとは アプリケーションやシステムの開発において、昨今新たな手法として広まっているのが 「ノーコード」 や「ローコード」と呼ばれる開発手法です。 「ノーコード」は、一般的なプログラミングにおいて必要となるソースコードの記述が不要なため、特別なスキルが不要で手軽にアプリケーションを構築できます。 Things Cloudでは、IoTデバイスからのデータを処理するための処理ロジックをノーコードで構築できる「Analytics Builder」をプラットフォーム内に備えています。 参考サイト: DXを加速する「ノーコード ローコード」による開発とは？ Analytics Builderの特徴 Analytics Builderには、以下のような特徴があります。 ユースケースに応じた独自処理の実現が可能 Analytics Builderは、テンプレートベースの標準機能では実現できない独自の処理を、ノーコードで簡単に実現できます。 グラフィカルなUIでわかりやすい Analytics Builderは、Things Cloud上のアプリケーションの一部であり、直感的に操作できるグラフィカルなUIを備えています。また、実装時は必要なブロックを選択しUI上で線を使ってつなげていくだけなので、すぐに分析モデルを構築できます。 すぐに始められる Analytics Builderでは、カテゴリ分けされたブロック群から必要なブロック（機能）を選択し、あらかじめ定義されたパラメータ設定するだけで必要な処理を実現できます。一般的なプログラミングのようにさまざまな文法や関数を学習する必要がなく、短時間で手軽に分析モデルを構築できます。 適用ユースケース/処理の例 ここまで、Analytics Builderの強みを説明してきました。 これまでに述べたように、Analytics Builderでは用意された複数の処理ブロックを簡単に組み合わせることができ、それによって個別の要件に応じたさまざまな処理モデルの構築が可能です。 ここでは、代表的な適用例を一部ご紹介します。 温度センサ等を利用したユースケースの場合 温度が3分継続して40℃以上になった時、アラームを生成 デバイスごとの計測値の10分平均を算出し、計測値として登録 特定のデバイスグループ全体の計測値の10分平均を算出 電力使用量を計測するユースケースの場合 日次の総電力使用量の集計 拠点ごとに総電力使用量を集計 その他 デバイスからの通信が途絶した後、復旧した際に通知メールを送信 イベントやアラームをトリガーとしたデバイスデータの更新 （例：機器の動作開始/終了イベントから、デバイス情報の"動作ステータス値"を更新） より簡単な標準機能 「スマートルール」 Things Cloudのデータ処理機能には、より簡単に設定/利用が可能な「スマートルール」が標準搭載されています。 スマートルールは、あらかじめ定義されているテンプレートからUI上でデータにもとづくアクションを簡単に設定できる機能です。 スマートルールのテンプレートでは「しきい値超過時にアラームを発生させる」「アラーム発生時に通知メールを送る」など頻繁に利用される機能が定義されており、操作も非常にわかりやすいため、Things Cloudのデータ処理ではまずスマートルールの利用を考えます。 スマートルールで定義されていないような独自の処理を行いたい場合には、Analytics Builderの活用が有効です。 ※スマートルールの詳細については、 開発者ドキュメント をご参照ください。 Analytics Builder 実装例 ここでは、温度値の集計を題材として、実際にAnalytics Builderを利用して1つの処理モデルを構築した例をご紹介します。 処理内容 入力する計測値: 温度センサで計測した温度値 (20秒おきに送信) 出力する結果: 5分間の平均値がしきい値を上回った場合に、アラームを発生させる 処理内容 : デバイスの温度値を取得 5分間の平均値を算出 平均値がしきい値を超過しているか判定 アラーム通知用の文章を作成 アラームを送信 実装/動作例 Analytics Builderで作成したモデルの例 ブロックの設定例（平均値ブロック） しきい値超過時のアラーム発生画面 他の実装例や具体的な実装方法について知りたい方は、 開発者ドキュメントの例題 をご覧下さい。 応用例：Slackに通知内容を送信 Analytics Builder には、入力/出力/集約など便利で豊富なブロックが標準で搭載されていますが、入出力/パラメータ/処理内容を自身で設定/構築するカスタムブロック 2 というものを作成することも可能です。 以下は、Slackに通知するカスタムブロックを開発し、先ほど紹介したモデルに対して追加した例になります。 ※Slackの Incoming Webhook機能 を利用しています。 Slack通知のカスタムブロック（開発例） Slackに通知される様子 おわりに いかがでしたか？ 今回は、Things Cloudのノーコードツール「Analytics Builder」についてご紹介しました。 Things Cloudでは、スマートルールやAnalytics Builderを活用することで、さまざまなユースケースに対応したデータ処理をコーディング不要で簡単に実現可能です。また、より高度で複雑な処理を実現したい場合やプログラミングに慣れている方向けには、コーディングによってデータ処理を構築するApama EPL機能 3 も備えています。 Things Cloud カスタマーサクセスチームでは、ますます広がっていくIoTユースケースにおいて、より便利な使い方を開拓すべく機能検証や内製開発をしています。今後もIoTに関連する開発ネタを発信していきたいと思います！ Things Cloud 関連ブログ： IoTデバイス接続の難しさを解決するNTT Comのお手軽IoT Observable を活用した IoT データの可視化探索ガイド 問い合わせ先 お手数ですが＠を半角文字に置き換えてください。 Things Cloud サービスについて：iot-info＠ntt.com Things Cloud カスタマーサクセスチーム：iot-app＠ntt.com Analytics Builderの利用には「カスタムストリーミング処理機能」のオプション申し込みが必要です。 ↩ カスタムブロックの作成には、開発環境の準備および専用の言語によるコーディングが必要です。 ↩ Apama EPL機能の利用には「カスタムストリーミング処理機能」のオプション申し込みが必要です。Apama EPL機能について詳しく知りたい方は、 開発者ドキュメント 〜Apama EPLをはじめる〜 をご覧下さい。 ↩

みなさんこんにちは、イノベーションセンターの @Mahito です。普段は社内のエンジニアが働きやすくなることを目標に、コーポレートエンジニアとしての活動やエンジニア向けイベントの企画・運営をしています。 今回は、本 NTT Communications Engineers' Blog を2年間運営してきたノウハウについて共有できればと思います。先日 はてなブログ DevBlog Meetup #1 に登壇させていただく機会があり、ブログ運営に関していくつかお話しさせていただいたのですが、イベント当日に言えなかったことや言ったことの補足などをできればと思います。 目次 目次 開発者ブログのこれまでと目的 運用のノウハウ・意識していること 執筆者の確保・継続・インセンティブ設計 1. 定期的にブログの取り組みを社内に紹介することで取り組みに興味を持ってもらう 2. ニュースリリースを見て、技術的に面白そうな取り組みをしているところに声をかける 3. 執筆のハードルを下げる 運用 レビュー 記事公開 KPI や指標 その他 長く続けるために個人的に意識していること まとめ 開発者ブログのこれまでと目的 開発者ブログの運用ノウハウをお伝えする前に、少しだけ本ブログについてのお話をさせていただきます。 こちら「 開発者ブログをリニューアルしました! 」でも書いたのですが、NTT Com では元々2015年に6月頃から開発者ブログを開始しました。当時はCMSを自分たちで運用していくスタイルでしたが、CMSの使い勝手やレビューのしづらさなどもあり、リニューアルという形ではてなブログへと引っ越しをする形になりました。 エンジニアブログをリニューアルする際には、開発者ブログに以下のような目的を定めました。 NTT Comのエンジニアの取り組みを広く知ってもらう 社外のユーザーやエンジニアとコミュニケーションをとれるきっかけの場とする NTT Comのエンジニアが自己発信できる場を提供する NTT Comにはさまざまなエンジニアがそれぞれの仕事をしていますが、その多くは外部には見えません。例えば、NTT Comのニュースリリースを見ても、技術の詳細などは書かれていません。そのため、リクルーター活動などをしていると、NTT Comのエンジニアが何をしているのか社外に知られていないと感じることが多くありました。 一方で、エンジニアの中には自分たちの取り組みを知ってもらうことで、社外のエンジニアやユーザーと繋がり、そこから採用や新規ユーザーの獲得に繋げたいと考えている人もいます。しかし、社外のエンジニアやユーザーとの交流のきっかけや、自分たちで発信する場があまりないという問題がありました。そこで、開発者ブログを通じて、これらの問題を解決できるようにしていこうとなりました。 運用のノウハウ・意識していること 執筆者の確保・継続・インセンティブ設計 NTT Comでは、ブログは書きたい人が書くというスタイルを取っています。これは、持ち回りで定期的に記事を出すということよりも、書きたい人のやる気を優先することでいい記事が生まれ、いい結果につながるのではというような話だったと思います。（運営の中で全然議論にならなかったのでうろ覚えです） おかげで1ヶ月近く新しい記事がでないこともありますが、タイミング的にまだ公開できない未公開記事や、「書きたい！」と言って準備してくれている人が常にいる状態のため、運営スタッフは「今週もでなかったね〜」ぐいらいのノリで焦りは特にありません。 新規の執筆者をどう確保するのかという点では、以下の3点を意識しています。 定期的にブログの取り組みを社内に紹介することで取り組みに興味を持ってもらう ニュースリリース を見て、技術的に面白そうな取り組みをしているところに声をかける 執筆のハードルを下げる 1. 定期的にブログの取り組みを社内に紹介することで取り組みに興味を持ってもらう 社内でもまだまだ開発者ブログに取り組んでいることを知らない人もいるため、社内での開発者ブログの認知を上げることや、そのタイミングではブログのネタがなく興味を持たなかった人に再度知ってもらうことで書くきっかけにつながればと思っています。社内に紹介する方法としては、社内ポータルの周知に「今月どんな記事が出たかのまとめ」を掲載したり、新しい記事がでたら Slack や Microsoft Viva Engage（旧称 Yammer） に自動投稿したり、社内のイベントでブログの活動を紹介したりとさまざまです。 2. ニュースリリースを見て、技術的に面白そうな取り組みをしているところに声をかける 我々運営スタッフも社内のすべてを知っているわけではないので、運営の定例などで NTT Com のニュースリリースをチェックし、技術的に面白そうな取り組みをしているところに連絡をしています。こちらの「 駆け出し開発チームでも45万回利用されるシステムを2カ月で作れた話 」 はニュースリリースを見て、運営から声をかけさせてもらった記事です。個人的にはプロジェクトのはじまるきっかけなど、ニュースリリースに書かれていない部分も知ることができとてもいい記事でした。 3. 執筆のハードルを下げる 執筆者のハードルを下げる取り組みは、「執筆したいけどできない」とか「こんなこと書いていいのかな」という問題を解決することです。 前者は、稼働の問題や周囲の理解、技術的な問題など、さまざまな理由がありますが、副社長や幹部に開発者ブログの活動にお墨付きをいただいています。 何か問題があれば「偉い人の承認を得ている取り組みですよ」ということができます（使ったことはないけど）。 また、後者に関しては、運営スタッフが色々サポートできます。 例えば、NTT Comの開発者ブログでは、記事はMarkdownで記載され、GitHubを利用して記事の管理やレビューをしています。 執筆者の中には、これらに慣れていない方もいますが、運営スタッフがサポートして記事が書けるようにお手伝いしています。 「こんなこと書いていいのかな」という疑問に対しては、運営スタッフが相談に乗ることもあります。エンジニアは、自分たちのやっていることがたいしたことではないと思いがちですが、「自分たちならではの部分や工夫」があることも多いため、そういった部分を記事に取り入れることを提案します。 また、開発者ブログを継続することで記事の専門性が深くなったり、難しい課題を解決した話がでることもありますが、それによって新しい執筆者が「自分はそんな記事をかけない」とハードルを感じることもあります。そのため、時々「 知ってるようで知らない YAML のご紹介 」のような比較的軽い記事を投稿して、執筆者のハードルが上がりすぎないように意識しています。 運用 NTT Com 開発者ブログの運用は有志の運営スタッフで行われています。 運営スタッフに参加している理由は面白そう、社内の取り組みが知りたい、社内の人と知り合いたいなど人それぞれですが、業務時間内の仕事の合間を縫って活動をしています。 運営スタッフのやることは主に以下のとおりです。 記事のレビュー 執筆者のサポート 記事のネタ・執筆者探し 運営上の課題解決 運営スタッフは毎週定例を設けており、上記の進捗状況などについて共有したり議論をしています。 レビュー 記事のレビューは GitHub 上で行っており、執筆者の Pull Request（以下、PR） が来るとランダムで運営スタッフからレビュー担当が１名つきます。 また、レビューの前に GitHub Actions が動作し、はてなブログへ下書き状態での記事投稿や、 textlint を用いて表現や文章のチェックがなされます。 レビューでは執筆者が伝えたいことや文章の個性をそのまま読者へ届けられるようにしつつも、より読みやすい形で出すために以下のような点を確認しています。 読者が読んでいて疑問に思うところがないか 読者が読みやすい文章表現になっているか 数字の正確性確認 ブログに使われている画像に問題がないか 記事によってはレビュー担当のカバーする技術分野から離れた専門領域の内容をレビューすることもあります。 そうした場合はその領域をカバーできるスタッフに代わってもらいますが、代わってもらう人がいない場合は自分で調べながらレビューすることもあります。 私自身専門外の記事レビューを何度か経験しましたが、レビューは難しくも普段と違う技術領域を知るきっかけになり楽しんでいました。 textlint では社名（正式略称は「NTT Com」）や商品名、日本語の表現などがチェックされ、問題があれば PR にコメントとして残されます。 これは、読者の方が読みやすい文章になるだけでなく、レビュー担当の負担を減らすことや、レビューの見逃しをなくすことに繋がっています。 記事公開 記事の公開はレビューが終わり次第可能となり、PR の Merge ボタンを押すと GitHub Actions が下書き状態だった記事を公開状態に変更します。 執筆者の希望公開日があればその日にデプロイをしますが、希望がなければ、運営スタッフが Page View（以下、PV） が稼げそうなタイミングでリリースをします。 この２年間でどういうタイミングに公開すると PV が伸びやすいかなど仮説を持って検証してきており、そうしたノウハウを活用しています。 記事公開にはレビューや textlint などのチェックを行っていますが、公開後に見つかるタイポや表現の問題があります。 その場合、修正の PR を作成し、レビュー、マージの手順を踏んで記事を更新しています。 ボタン1つで公開や修正をできる Continuous Delivery のしくみにすることで、記事の公開・修正のハードルを下げることに繋がっています。 KPI や指標 「ブログの KPI をどうしているか」という質問がイベントでもありましたが、NTT Com の開発者ブログにも KPI はあります。 PV 数や記事の投稿数など、定量的な指標を KPI にしていますが、あくまで、「NTT Com の開発者ブログがこういう状態になっていたら嬉しい」ぐらいの目標設定として数字は置かれています。 KPI の管理は毎週のスタッフ定例で進捗確認をしながら KPI の達成に向けた施策の検討や実施をしており、 毎年12月の アドベントカレンダー 企画や、社内の執筆者向けた情報公開、イベントなども行っています。 先日もブログリニューアル２周年を記念した運営スタッフと執筆者の Meetup が行われ、この２年間の活動の振り返りや、今後についての話し合いなどが行われました。 その他 長く続けるために個人的に意識していること ブログ運営を２年間続けている中で私個人として意識していることがあります。 それは、 「ゆるく」 運営をしていくことです。 「8年続く社内勉強会を続けていくために行っていること」 というタイトルの記事でも書かせてもらったのですが、運営を頑張ることはとても大事な一方で、頑張りすぎてしまうと燃え尽きてしまいあとが続かないこともあります。 先述したとおり、運営スタッフはそれぞれが開発者ブログに対して何らかの目的や思いを持って活動をしています。 一方で、運営スタッフは本業の合間を縫ってエンジニアブログの運営をしているため、運営を頑張るほどに運営スタッフの負担が上がり燃え尽きる可能性もあります。 社内の取り組みをより多くの人に知ってもらうための開発者ブログの活動を、運営スタッフが思いを持って運営し続けていけるしくみとして、「ゆるさ」が大事だと考えています。 その運営をゆるくするためにしくみのひとつとして、定例の簡素化があります。 運営スタッフの定例は時間と議題だけを決め、そのとき集まれるメンバが Slack ハドルミーティングに集まります。 議事録などは毎回残しているので参加できなかった運営スタッフは後から読むことができます。 また、Slack ハドルミーティングは普段から開発者ブログに関して運営や執筆者たちがやり取りをするチャンネルを用いているため、 定例には運営スタッフ以外にも開発者ブログの運営や執筆に興味がある人も参加できるオープンな形で開催しています。 この他にも GitHub の PR によるレビューや、GitHub Actions を使った textlint、記事の下書き投稿・公開の自動化などのしくみも、 我々運営スタッフの負担を減らし、ゆるくやっていくためのしくみの1つとして用意したものです。 今後も開発者ブログの運営が長続きするように、我々運営が頑張りすぎず、ゆるく運営を続けていければと思っています。 まとめ 今回は2年間の開発者ブログ運営のノウハウや意識していることなどを紹介しました。 企業の文化やルールによっては使えるノウハウ、使えないノウハウなどあるかもしれませんが、この記事がどこかの開発者ブログの運営のお役に立てれば幸いです。

TOC サマリ 概要 検証 EVI と CE 向けポート設定 EVI と CE 向けポートの状態確認 BGP の設定 Local Preference(LP) の設定 IOS XR ASBR 間 SR OS ASBR 間 経路の確認 EVI 3600 EVI 3700 疎通試験 制約事項 まとめ サマリ Multi-AS で構成されるネットワークにおいて、SR-MPLS + EVPN による L2VPN を実現 IOS XR + Junos + SR OS の Multi-vendor 環境での動作検証に、特定の組み合わせ以外は成功 この記事は Multi-AS SR 検証連載の第 13 回です。過去の記事は こちら 概要 イノベーションセンターの竹中です。普段の業務では Multi-AS Segment Routing に関する技術検証や、ネットワーク運用効率化のためのコントローラー開発などを行なっています。 第3回 の記事で IOS XR + Junos の 2 つのベンダー機器で構成される Single-AS/Multi-AS L2VPN についてご紹介しましたが、今回新たに Nokia SR OS（Service Router Operating System）を PE・P・ASBR に加えた 3 つのベンダー機器での Multi-AS L2VPN 動作検証をご紹介します。 EVPN による L2VPN に関する説明は、 第3回 記事の概要にて紹介しているので、そちらをご参照ください。 検証 EVPN L2VPN の検証例を実際の設定例を添えつつ紹介します。 IOS XR、Junos の設定例は 第3回 の記事で紹介したため本記事では割愛し、SR OS の設定例を中心に紹介します。 本記事の検証は Inter-AS Option B の L2VPN について、SR OS と各ベンダー間の互換性確認を目的とします。 つまり下記を検証します。 SR OS を PE として L2VPN が構築できるかどうかを確認する SR OS と IOS XR/Junos の間で L2VPN 経路を交換できるかどうかを確認する Inter-AS Option B 構成を構築する際に SR OS を ASBR として利用できるかを確認する 下記のトポロジーを利用し L2VPN の検証例を紹介します。 なお、検証は運用中の実機環境を利用しているため、一部トポロジーが雑然としていることはご了承ください。 また、各 EVI で扱う組み合わせを表に示します。 EVI AS65001 PE → → ASBR-ASBR → → AS65002 PE 3600 Juniper Cisco Nokia 3700 Cisco Nokia Juniper 使用する機器は以下の通りです。 IOS XR rt01: Cisco ASR9901 (IOS XR 7.6.1) rt03: Cisco 8201 (IOS XR 7.5.1) rt06、rt08: Cisco ASR9902 (IOS XR 7.5.1) rt10: Cisco NCS55A2 (IOS XR 7.5.1) Junos rt02、rt12: Juniper MX204 (JUNOS 22.1R1.10) rt04: Juniper PTX10001-36MR (JUNOS 21.4R1.15-EVO) SR OS rt05、rt07、rt09、rt11、rt13: Nokia 7750 SR-1 (SR OS 23.3.R1) SR OS の IGP や SR の設定は 第12回 の記事で紹介したため割愛します。下記の設定および確認を順に行います。 EVI と CE 向けポート設定と状態確認 BGP の設定 LP の設定 経路の確認 疎通試験 EVI と CE 向けポート設定 まず、PE で EVI と CE 向けポートを設定します。各 EVI は MP-BGP EVPN にて 64999:<EVI 番号> の RT を用いて経路交換します。 PE （例： rt13） [gl:/configure policy-options] A:user@rt13# info community "comm-3600" { member "target:64999:3600" { } } policy-statement "vsi-export-3600" { entry 10 { action { action-type accept community { add ["comm-3600"] } } } } policy-statement "vsi-import-3600" { entry 10 { from { community { name "comm-3600" } } action { action-type accept } } } [gl:/configure service] A:user@rt13# info customer "3600" { } system { bgp { evpn { ethernet-segment "esi-26-1/2/c16/1" { admin-state enable esi 0x02000000010000002616 multi-homing-mode single-active association { port 1/2/c16/1 { } } } } } } vpls "3600" { admin-state enable customer "3600" bgp 1 { route-distinguisher "10.255.2.26:3600" vsi-import ["vsi-import-3600"] vsi-export ["vsi-export-3600"] } bgp-evpn { evi 3600 mpls 1 { admin-state enable auto-bind-tunnel { resolution any } } } sap 1/2/c16/1:3600 { admin-state enable } } EVI と CE 向けポートの状態確認 EVI と CE 向けポートが紐づき、また Admin/Operation 共に up していることが確認できます。 [/] A:user@rt13# show service id 3600 sap =============================================================================== SAP(Summary), Service 3600 =============================================================================== PortId SvcId Ing. Ing. Egr. Egr. Adm Opr QoS Fltr QoS Fltr ------------------------------------------------------------------------------- 1/2/c16/1:3600 3600 1 none 1 none Up Up ------------------------------------------------------------------------------- Number of SAPs : 1 ------------------------------------------------------------------------------- =============================================================================== BGP の設定 L2VPN 経路を広告するため PE と ASBR で MP-BGP EVPN を設定します。 PE (例: rt13) [gl:/configure router "Base" bgp] A:user@rt13# info rapid-withdrawal true family { evpn true } rapid-update { evpn true } group "iBGP" { peer-as 65002 local-address 10.255.2.2 family { evpn true } } neighbor "10.255.2.6" { admin-state enable group "iBGP" } neighbor "10.255.2.7" { admin-state enable group "iBGP" } ASBR (例: rt07) [gl:/configure router "Base" bgp] A:user@rt07# info inter-as-vpn true rapid-withdrawal true family { evpn true } ebgp-default-reject-policy { import false export false } rapid-update { evpn true } next-hop-resolution { labeled-routes { transport-tunnel { family vpn { resolution any } } } } group "65002" { vpn-apply-import true peer-as 65002 bfd-liveness true family { evpn true } } group "iBGP" { peer-as 65001 local-address 10.255.1.7 family { evpn true } } neighbor "10.100.3.2" { group "65002" } neighbor "10.255.1.1" { group "iBGP" } neighbor "10.255.1.2" { group "iBGP" } Local Preference(LP) の設定 EVI ごとに通過する ASBR を制御するため、ASBR で LP を設定します。 本検証では RT ごとに通過させたい ASBR への経路には LP 300 を、通過させたくない ASBR への経路には LP 50 を明示的に設定します。 IOS XR ASBR 間 rt06 route-policy lp-for-evpn if extcommunity rt matches-any (64999:3600) then set local-preference 300 elseif extcommunity rt matches-any (64999:3700) then set local-preference 50 else pass endif end-policy router bgp 65001 neighbor 10.100.1.2 address-family l2vpn evpn route-policy lp-for-evpn in ! ! rt08 route-policy lp-for-evpn if extcommunity rt matches-any (64999:3600) then set local-preference 300 elseif extcommunity rt matches-any (64999:3700) then set local-preference 50 else pass endif end-policy router bgp 65002 neighbor 10.100.1.1 address-family l2vpn evpn route-policy lp-for-evpn in ! ! SR OS ASBR 間 rt07 [gl:/configure policy-options] A:user@rt07# info community "lp-high-grp" { member "target:64999:3700" { } } community "lp-low-grp" { member "target:64999:3600" { } } policy-statement "lp-for-evpn" { entry 1 { from { community { name "lp-high-grp" } } action { action-type accept local-preference 300 } } entry 2 { from { community { name "lp-low-grp" } } action { action-type accept local-preference 50 } } } [gl:/configure router "Base" bgp] A:user@rt07# info vpn-apply-export true vpn-apply-import true group "65002" { import { policy ["lp-for-evpn"] } } rt09 [gl:/configure policy-options] A:user@rt09# info community "lp-high-grp" { member "target:64999:3700" { } } community "lp-low-grp" { member "target:64999:3600" { } } policy-statement "lp-for-evpn" { entry 1 { from { community { name "lp-high-grp" } } action { action-type accept local-preference 300 } } entry 2 { from { community { name "lp-low-grp" } } action { action-type accept local-preference 50 } } } [gl:/configure router "Base" bgp] A:user@rt09# info vpn-apply-export true vpn-apply-import true group "65001" { import { policy ["lp-for-evpn"] } } 経路の確認 各 PE で構成に従った経路を学習しているかを確認します。 type1 経路、type3 経路が交換されていること、また EVI ごとにそれぞれ nexthop が適切な ASBR となっていることが確認できます。 EVI 3600 AS65001 側 PE (rt02) user@rt02> show route table evpn-3600.evpn.0 evpn-3600.evpn.0: 9 destinations, 17 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:10.255.1.2:3600::0207::0/192 AD/EVI *[EVPN/170] 15w4d 20:10:12 Indirect 1:10.255.2.26:3600::02000000010000002616::0/192 AD/EVI *[BGP/170] 2w2d 16:54:52, localpref 300, from 10.255.1.3 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 > to 10.1.8.2 via et-0/0/0.0, Push 16007 to 10.1.16.2 via et-0/0/2.0, Push 16007 [BGP/170] 2w2d 16:54:52, localpref 300, from 10.255.1.4 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 > to 10.1.8.2 via et-0/0/0.0, Push 16007 to 10.1.16.2 via et-0/0/2.0, Push 16007 [BGP/170] 2w2d 16:54:52, localpref 300, from 10.255.1.20 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 > to 10.1.8.2 via et-0/0/0.0, Push 16007 to 10.1.16.2 via et-0/0/2.0, Push 16007 1:10.255.2.26:3600::02000000010000002616::FFFF:FFFF/192 AD/ESI *[BGP/170] 2w2d 16:54:52, localpref 300, from 10.255.1.3 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 > to 10.1.8.2 via et-0/0/0.0, Push 16007 to 10.1.16.2 via et-0/0/2.0, Push 16007 [BGP/170] 2w2d 16:54:52, localpref 300, from 10.255.1.4 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 > to 10.1.8.2 via et-0/0/0.0, Push 16007 to 10.1.16.2 via et-0/0/2.0, Push 16007 [BGP/170] 2w2d 16:54:52, localpref 300, from 10.255.1.20 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 > to 10.1.8.2 via et-0/0/0.0, Push 16007 to 10.1.16.2 via et-0/0/2.0, Push 16007 2:10.255.1.2:3600::0::00:0c:29:f0:5a:09/304 MAC/IP *[EVPN/170] 14w5d 01:18:41 Indirect 2:10.255.2.26:3600::0::00:0c:29:1f:dd:dc/304 MAC/IP *[BGP/170] 00:00:26, localpref 300, from 10.255.1.3 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 to 10.1.8.2 via et-0/0/0.0, Push 16007 > to 10.1.16.2 via et-0/0/2.0, Push 16007 [BGP/170] 00:00:26, localpref 300, from 10.255.1.4 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 to 10.1.8.2 via et-0/0/0.0, Push 16007 > to 10.1.16.2 via et-0/0/2.0, Push 16007 [BGP/170] 00:00:26, localpref 300, from 10.255.1.20 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 to 10.1.8.2 via et-0/0/0.0, Push 16007 > to 10.1.16.2 via et-0/0/2.0, Push 16007 2:10.255.1.2:3600::0::00:0c:29:f0:5a:09::192.168.32.1/304 MAC/IP *[EVPN/170] 14w5d 01:18:36 Indirect 2:10.255.1.2:3600::0::00:0c:29:f0:5a:09::192.168.33.1/304 MAC/IP *[EVPN/170] 1w3d 19:40:14 Indirect 3:10.255.1.2:3600::0::10.255.1.2/248 IM *[EVPN/170] 17w3d 18:54:21 Indirect 3:10.255.2.26:3600::0::10.255.2.26/248 IM *[BGP/170] 2w2d 16:54:52, localpref 300, from 10.255.1.3 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 to 10.1.8.2 via et-0/0/0.0, Push 16007 > to 10.1.16.2 via et-0/0/2.0, Push 16007 [BGP/170] 2w2d 16:54:52, localpref 300, from 10.255.1.4 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 to 10.1.8.2 via et-0/0/0.0, Push 16007 > to 10.1.16.2 via et-0/0/2.0, Push 16007 [BGP/170] 2w2d 16:54:52, localpref 300, from 10.255.1.20 AS path: 65002 I, validation-state: unverified to 10.1.3.2 via et-0/0/1.0, Push 16007 to 10.1.8.2 via et-0/0/0.0, Push 16007 > to 10.1.16.2 via et-0/0/2.0, Push 16007 AS65002 側 PE (rt13) [/] A:user@rt13# show router bgp routes evpn auto-disc detail =============================================================================== BGP Router ID:10.255.2.26 AS:65002 Local AS:65002 =============================================================================== Legend - Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid l - leaked, x - stale, > - best, b - backup, p - purge Origin codes : i - IGP, e - EGP, ? - incomplete =============================================================================== BGP EVPN Auto-Disc Routes =============================================================================== Original Attributes Network : n/a Nexthop : 10.255.2.1 Path Id : None From : 10.255.2.1 Res. Nexthop : 10.2.17.1 Local Pref. : 300 Interface Name : to_ar-rt10 Aggregator AS : None Aggregator : None Atomic Aggr. : Not Atomic MED : None AIGP Metric : None IGP Cost : 30 Connector : None Community : target:64999:3600 Cluster : 0.0.0.1 Originator Id : 10.255.2.1 Peer Router Id : 10.255.2.25 Flags : Valid IGP TieBreakReason : PeerIP MP Exc. Reason : NotNextHopDiverse Route Source : Internal AS-Path : 65001 EVPN type : AUTO-DISC ESI : 00:00:00:00:00:00:00:00:02:07 Tag : 0 Route Dist. : 10.255.1.2:3600 MPLS Label : LABEL 60946 Route Tag : 0 Neighbor-AS : 65001 DB Orig Val : N/A Final Orig Val : N/A Source Class : 0 Dest Class : 0 Add Paths Send : Default Last Modified : 52d23h37m Modified Attributes Network : n/a Nexthop : 10.255.2.1 Path Id : None From : 10.255.2.1 Res. Nexthop : 10.2.17.1 Local Pref. : 300 Interface Name : to_ar-rt10 Aggregator AS : None Aggregator : None Atomic Aggr. : Not Atomic MED : None AIGP Metric : None IGP Cost : 30 Connector : None Community : target:64999:3600 Cluster : 0.0.0.1 Originator Id : 10.255.2.1 Peer Router Id : 10.255.2.25 Flags : Valid IGP TieBreakReason : PeerIP MP Exc. Reason : NotNextHopDiverse Route Source : Internal AS-Path : 65001 EVPN type : AUTO-DISC ESI : 00:00:00:00:00:00:00:00:02:07 Tag : 0 Route Dist. : 10.255.1.2:3600 MPLS Label : LABEL 60946 Route Tag : 0 Neighbor-AS : 65001 DB Orig Val : N/A Final Orig Val : N/A Source Class : 0 Dest Class : 0 Add Paths Send : Default Last Modified : 52d23h37m (snip) ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- Routes : 8 =============================================================================== [/] A:user@rt26# show router bgp routes evpn incl-mcast =============================================================================== BGP Router ID:10.255.2.26 AS:65002 Local AS:65002 =============================================================================== Legend - Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid l - leaked, x - stale, > - best, b - backup, p - purge Origin codes : i - IGP, e - EGP, ? - incomplete =============================================================================== BGP EVPN Inclusive-Mcast Routes =============================================================================== Flag Route Dist. OrigAddr Tag NextHop ------------------------------------------------------------------------------- u*>i 10.255.1.2:3600 10.255.1.2 0 10.255.2.1 *i 10.255.1.2:3600 10.255.1.2 0 10.255.2.1 i 10.255.2.26:3600 10.255.2.26 0 10.255.2.26 i 10.255.2.26:3600 10.255.2.26 0 10.255.2.26 ------------------------------------------------------------------------------- Routes : 4 =============================================================================== EVI 3700 AS65001 側 PE (rt01) ※ type3 経路の nexthop が rt07 となっていませんが、こちらは後述の制約事項で扱います。 RP/0/RSP0/CPU0:rt01#show evpn evi vpn-id 3700 ead Mon Jun 19 11:49:14.279 JST VPN-ID Encap Ethernet Segment Id EtherTag Nexthop Label SID ---------- ------ ------------------------ ---------- --------------------------------------- -------- --------------------------------------- 3700 MPLS 0000.0000.0000.0000.0132 0x0 :: 24019 3700 MPLS 0000.0000.0000.0000.1607 0x0 10.255.1.22 507880 3700 MPLS 0000.0000.0000.0000.1607 0xffffffff 10.255.1.22 0 RP/0/RSP0/CPU0:rt01#show evpn evi vpn-id 3700 inclusive-multicast detail Mon Jun 19 11:48:06.327 JST VPN-ID Encap EtherTag Originating IP ---------- ------ ---------- ---------------------------------------- 3700 MPLS 0 10.255.1.1 TEPid : 0xffffffff PMSI Type: 6 Nexthop: :: Label : 26015 SR-TE Info: N/A Source : Local E-Tree : Root 3700 MPLS 0 10.255.2.8 TEPid : 0x02000002 PMSI Type: 6 Nexthop: 10.255.2.8 Label : 507882 SR-TE Info: N/A Source : Remote E-Tree : Root AS65002 側 PE (rt12) user@rt12> show route table evpn-3700.evpn.0 evpn-3700.evpn.0: 8 destinations, 12 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:10.255.1.1:1::0132::FFFF:FFFF/192 AD/ESI *[BGP/170] 2d 00:11:42, localpref 300, from 10.255.2.5 AS path: 65001 I, validation-state: unverified to 10.2.4.1 via et-0/0/1.0, Push 16009 > to 10.2.16.2 via et-0/0/2.0, Push 16009 [BGP/170] 2d 00:11:42, localpref 300, from 10.255.2.25 AS path: 65001 I, validation-state: unverified to 10.2.4.1 via et-0/0/1.0, Push 16009 > to 10.2.16.2 via et-0/0/2.0, Push 16009 1:10.255.1.1:3700::0132::0/192 AD/EVI *[BGP/170] 2d 00:11:42, localpref 300, from 10.255.2.5 AS path: 65001 I, validation-state: unverified > to 10.2.4.1 via et-0/0/1.0, Push 16009 to 10.2.16.2 via et-0/0/2.0, Push 16009 [BGP/170] 2d 00:11:42, localpref 300, from 10.255.2.25 AS path: 65001 I, validation-state: unverified > to 10.2.4.1 via et-0/0/1.0, Push 16009 to 10.2.16.2 via et-0/0/2.0, Push 16009 1:10.255.2.8:3700::1607::0/192 AD/EVI *[EVPN/170] 14w1d 00:55:46 Indirect 2:10.255.1.1:3700::0::00:0c:29:f0:5a:13/304 MAC/IP *[BGP/170] 2d 00:11:42, localpref 300, from 10.255.2.5 AS path: 65001 I, validation-state: unverified > to 10.2.4.1 via et-0/0/1.0, Push 16009 to 10.2.16.2 via et-0/0/2.0, Push 16009 [BGP/170] 2d 00:11:42, localpref 300, from 10.255.2.25 AS path: 65001 I, validation-state: unverified > to 10.2.4.1 via et-0/0/1.0, Push 16009 to 10.2.16.2 via et-0/0/2.0, Push 16009 2:10.255.2.8:3700::0::00:0c:29:1f:dd:c8/304 MAC/IP *[EVPN/170] 00:11:41 Indirect 2:10.255.2.8:3700::0::00:0c:29:1f:dd:c8::192.168.33.3/304 MAC/IP *[EVPN/170] 00:06:33 Indirect 3:10.255.1.1:3700::0::10.255.1.1/248 IM *[BGP/170] 2d 00:11:42, localpref 300, from 10.255.2.5 AS path: 65001 I, validation-state: unverified to 10.2.4.1 via et-0/0/1.0, Push 16009 > to 10.2.16.2 via et-0/0/2.0, Push 16009 [BGP/170] 2d 00:11:42, localpref 300, from 10.255.2.25 AS path: 65001 I, validation-state: unverified to 10.2.4.1 via et-0/0/1.0, Push 16009 > to 10.2.16.2 via et-0/0/2.0, Push 16009 3:10.255.2.8:3700::0::10.255.2.8/248 IM *[EVPN/170] 15w6d 23:38:46 Indirect 疎通試験 各 EVI について、ce01 から ping で ce02 への疎通確認を行います。 EVI 3600 (192.168.32.0/24) user@ce01:~$ ping 192.168.32.2 -c 5 PING 192.168.32.2 (192.168.32.2) 56(84) bytes of data. 64 bytes from 192.168.32.2: icmp_seq=1 ttl=64 time=1.92 ms 64 bytes from 192.168.32.2: icmp_seq=2 ttl=64 time=2.02 ms 64 bytes from 192.168.32.2: icmp_seq=3 ttl=64 time=1.92 ms 64 bytes from 192.168.32.2: icmp_seq=4 ttl=64 time=1.96 ms 64 bytes from 192.168.32.2: icmp_seq=5 ttl=64 time=2.10 ms --- 192.168.32.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 1.919/1.984/2.096/0.067 ms EVI 3700 (192.168.33.0/24) user@ce01:~$ ping 192.168.33.2 -c 5 PING 192.168.33.2 (192.168.33.2) 56(84) bytes of data. 64 bytes from 192.168.33.2: icmp_seq=1 ttl=64 time=1.66 ms 64 bytes from 192.168.33.2: icmp_seq=2 ttl=64 time=1.50 ms 64 bytes from 192.168.33.2: icmp_seq=3 ttl=64 time=1.59 ms 64 bytes from 192.168.33.2: icmp_seq=4 ttl=64 time=1.49 ms 64 bytes from 192.168.33.2: icmp_seq=5 ttl=64 time=1.46 ms --- 192.168.33.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4007ms rtt min/avg/max/mdev = 1.461/1.541/1.660/0.073 ms パケットが転送でき、VPN が構築できていることが確認できました。 以上、2パターンの組み合わせで L2VPN が構築できている事が確認できました。 制約事項 2023/8/21 現在、L2VPN の Option-B シグナリングは IOS XR と SR OS で可能です。 しかし、相互接続において IOS XR と SR OS で Option-B によるシグナリング時の type3 経路 (IMET route) の解釈違いがありました。 解釈違いによって IOS XR を PE、SR OS を ASBR とする組み合わせの場合に AS を越えて BUM トラフィックが通らないことにご注意ください。 まとめ IOS XR 、Junos と SR OS の Multi-vendor 環境における Multi-AS L2VPN の検証結果を紹介しました。 次回の記事では、同様の Multi-vendor 環境における Color-Based TE について紹介予定です。 （2023/9/4 追記） 公開しました： [Multi-AS Segment Routing 検証連載 #14] Color-Based Steering using IOS XR, Junos and SR OS

TOC サマリ 概要 検証 検証項目とトポロジー 基本設定 IS-IS - 設定 IS-IS - 動作確認 VRF と MP-BGP VPNv4 - 機器設定 MP-BGP VPNv4 - 動作確認 LP の設定 cust-c の動作確認 cust-d の動作確認 cust-e の動作確認 まとめ サマリ Multi-AS で構成されるネットワークにおいて、SR-MPLS + VPNv4 による L3VPN を実現 IOS XR + Junos + SR OS の Multi-vendor 環境で動作検証に成功 この記事は Multi-AS SR 検証連載の第 12 回です。目次は こちら 概要 イノベーションセンターの岩田です。普段の業務では Multi-AS Segment Routing に関する技術検証や、ベンチャー企業への技術支援でスマートフォンアプリケーション開発業務などを行なっています。 第1回 、 第2回 の記事で IOS XR + Junos の 2 つのベンダー機器で構成される L3VPN についてご紹介しましたが、今回新たに Nokia SR OS（Service Router Operating System）を加えた 3 つのベンダー機器での L3VPN 相互動作確認をご紹介します。 L3VPN や Segment Routing など今回扱う技術の説明は、 第1回 、 第2回 記事の概要章にて紹介しているので、そちらをご参照ください。 検証 以降は L3VPN の検証例を実際の設定例を添えつつ紹介します。 IOS XR、Junos の設定例は 第1回 や 第2回 の記事で紹介したため本記事では割愛し、SR OS の設定例を中心に紹介します。 検証項目とトポロジー 本記事の検証では、Inter-AS Option B の L3VPN について、SR OS と 各ベンダー（SR OS 自身を含む）間の互換性確認を目的とします。 そのため、以下の検証項目を設定します。 項目1: SR OS（PE）と SR OS（PE）間で L3VPN が構築できるかを確認する 項目2: SR OS（PE）と IOS XR（PE）間で L3VPN が構築できるかを確認する 項目3: SR OS（PE）と Junos（PE）間で L3VPN が構築できるかを確認する 項目4: Inter-AS Option B 構成を構築する際に SR OS を ASBR として利用できるかを確認する 上記の確認のため、本記事では下図のようなトポロジーからなるネットワークを用いて検証します。 検証項目と、構築する L3VPN を構成する VRF と機器の組み合わせを以下の表に示します。 検証項目 VRF AS65001 PE → → ASBR-ASBR → → AS65002 PE 項目 2 cust-c IOS XR (rt01) Junos (rt05、 rt09) SR OS (rt13) 項目 3 cust-d Junos (rt02) IOS XR (rt04、 rt08) SR OS (rt13) 項目 1、 4 cust-e IOS XR (rt01) SR OS (rt06、 rt10) Junos (rt12) 使用する機器は以下の通りです。 rt01、rt04、rt07、rt08: Cisco IOS XR 7.4.1 rt02、rt05、rt09、rt12: Juniper Junos OS 21.3R1.9 rt06、rt10、rt13: Nokia SR OS 22.7.R1 この後は下記の流れに従って設定を紹介します。 IS-IS 設定と状態確認 VRF と MP-BGP 設定と状態確認 PE 間の ping 疎通試験 基本設定 IS-IS - 設定 IS-IS の SR 拡張を利用し、SR-MPLS の SID 情報を広告します。 SR OS（例： rt13） A:admin@rt13# /info router isis admin-state enable advertise-router-capability as level-capability 2 traffic-engineering true area-address [49.0000] segment-routing { admin-state enable prefix-sid-range { global } } interface "system" { } interface "to_rt08" { interface-type point-to-point level-capability 2 } interface "to_rt09" { interface-type point-to-point level-capability 2 } interface "to_rt10" { interface-type point-to-point level-capability 2 } level 2 { wide-metrics-only true } [ro:/configure] A:admin@rt13# /info router mpls-labels static-label-range 0 sr-labels { start 16000 end 23999 } [ro:/configure] A:admin@rt13# /info router segment-routing sr-mpls { prefix-sids "system" { ipv4-sid { index 13 } } } IS-IS - 動作確認 IS-IS ネイバーの状態と SID Table を確認します。 IS-IS ネイバーの状態の確認 [ro:/configure] A:admin@rt13# /show router isis adjacency =============================================================================== Rtr Base ISIS Instance 0 Adjacency =============================================================================== System ID Usage State Hold Interface MT-ID ------------------------------------------------------------------------------- rt08 L2 Up 25 to_rt08 0 rt09 L2 Up 25 to_rt09 0 rt10 L2 Up 20 to_rt10 0 ------------------------------------------------------------------------------- Adjacencies : 3 =============================================================================== SID Table の確認 [/] A:admin@rt13# /show router isis prefix-sids =============================================================================== Rtr Base ISIS Instance 0 Prefix/SID Table =============================================================================== Prefix SID Lvl/Typ SRMS AdvRtr Shared MT Flags ------------------------------------------------------------------------------- 10.255.2.2/32 12 2/Int. N rt12 N.A. 0 N 10.255.2.3/32 13 2/Int. N rt13 Yes 0 NnP 10.255.2.4/32 8 2/Int. N rt08 N.A. 0 N 10.255.2.5/32 9 2/Int. N rt09 N.A. 0 N 10.255.2.6/32 10 2/Int. N rt10 N.A. 0 NnP 10.255.2.7/32 14 2/Int. N rt14 N.A. 0 N ------------------------------------------------------------------------------- No. of Prefix/SIDs: 6 (6 unique) ------------------------------------------------------------------------------- SRMS: Y/N = prefix SID advertised by SR Mapping Server (Y) or not (N) S = SRMS prefix SID is selected to be programmed Flags: R = Re-advertisement N = Node-SID nP = no penultimate hop POP E = Explicit-Null V = Prefix-SID carries a value L = value/index has local significance Shared: Yes = local shared Node-SID No = not a local shared Node-SID N.A. = not applicable for Remote prefix-sid =============================================================================== VRF と MP-BGP VPNv4 - 機器設定 cust-c、d、e の VRF 設定と、経路を広告する MP-BGP L3VPN を設定します。 VPN の各パラメータは下記の通りです。 SR Domain 1 AS 番号: 65001 VRF 300（cust-c）: RD/RT 65001:300 AS 間での VPN 経路広告用 RT: 64999:300 VRF 400（cust-d）: RD/RT 65001:400 AS 間での VPN 経路広告用 RT: 64999:400 VRF 500（cust-e）: RD/RT 65001:500 AS 間での VPN 経路広告用 RT: 64999:500 SR Domain 2 AS 番号: 65002 VRF 300（cust-c）: RD/RT 65002:300 AS 間での VPN 経路広告用 RT: 64999:300 VRF 400（cust-d）: RD/RT 65002:400 AS 間での VPN 経路広告用 RT: 64999:400 VRF 500（cust-e）: RD/RT 65002:500 AS 間での VPN 経路広告用 RT: 64999:500 PE の設定（例： rt13、SR OS） A:admin@rt13# info policy-options community "shared-comm-cust-c" { member "target:64999:300" { } } community "shared-comm-cust-d" { member "target:64999:400" { } } policy-statement "vrf-export-cust-c" { entry 10 { action { action-type accept community { add ["shared-comm-cust-c"] } } } } policy-statement "vrf-export-cust-d" { entry 10 { action { action-type accept community { add ["shared-comm-cust-d"] } } } } policy-statement "vrf-import-cust-c" { entry 10 { from { community { name "shared-comm-cust-c" } } action { action-type accept } } } policy-statement "vrf-import-cust-d" { entry 10 { from { community { name "shared-comm-cust-d" } } action { action-type accept } } } A:admin@rt13# info service customer "cust-c" { customer-id 300 } customer "cust-d" { customer-id 400 } vprn "300" { admin-state enable customer "cust-c" bgp-ipvpn { mpls { admin-state enable route-distinguisher "65002:300" vrf-import { policy ["vrf-import-cust-c"] } vrf-export { policy ["vrf-export-cust-c"] } auto-bind-tunnel { resolution any } } } interface "to_cust-c" { admin-state enable ipv4 { primary { address 192.168.1.254 prefix-length 24 } } sap 1/1/c4/1:0 { admin-state enable } } } vprn "400" { admin-state enable customer "cust-d" bgp-ipvpn { mpls { admin-state enable route-distinguisher "65002:400" vrf-import { policy ["vrf-import-cust-d"] } vrf-export { policy ["vrf-export-cust-d"] } auto-bind-tunnel { resolution any } } } interface "to_cust-d" { admin-state enable ipv4 { primary { address 192.168.1.254 prefix-length 24 } } sap 1/1/c5/1:0 { admin-state enable } } } ASBR の設定（例： rt10、SR OS） A:admin@rt13# info router bgp vpn-apply-export true inter-as-vpn true rapid-withdrawal true family { vpn-ipv4 true } ebgp-default-reject-policy { import false export false } rapid-update { vpn-ipv4 true } next-hop-resolution { labeled-routes { transport-tunnel { family vpn { resolution any } } } } group "65001" { peer-as 65001 family { vpn-ipv4 true } } group "iBGP" { peer-as 65002 local-address 10.255.2.6 family { vpn-ipv4 true } } neighbor "10.100.3.1" { group "65001" local-address 10.100.3.2 } neighbor "10.255.2.7" { group "iBGP" } MP-BGP VPNv4 - 動作確認 下記 3 ステップで L3VPN の経路学習と転送動作を確認します。 今回は各ベンダーの ASBR の組で動作確認をするために ASBR へ LP を設定し、VRF ごとに ASBR を選択します。 動作確認したい ASBR の組が選択されるように LP を調整する PE で BGP から受信した経路を確認 ping による疎通確認 LP の設定 以下の設定で LP を調整し、cust-c、d、e に対応する ASBR を選択します。 cust-c（rt04、IOS XR） route-policy lp-high if extcommunity rt matches-any (64999:400) then set local-preference 300 endif end-policy ! router bgp 65001 neighbor-group ibgp address-family vpnv4 unicast route-policy lp-high out ! cust-d（rt05、Junos） set policy-options community CUST-C-SHARED members target:64999:300 set policy-options policy-statement lp-high term 1 from community CUST-C-SHARED set policy-options policy-statement lp-high term 1 then local-preference 300 set policy-options policy-statement lp-high term 1 then accept set protocols bgp group ibgp export lp-high cust-e（rt06、SR OS） A:admin@rt06# info policy-options community "CUST-E-SHARED" { member "target:64999:500" { } } policy-statement "lp-high" { entry 1 { from { community { name "CUST-E-SHARED" } } action { action-type accept local-preference 300 } } } A:admin@rt06# info router bgp vpn-apply-export true group "iBGP" { export { policy ["lp-high"] } } 動作確認 以下のように cust-c、d、e で適切な ASBR が選択されていることが確認できました。 RP/0/RP0/CPU0:rt07#show bgp vpnv4 unicast Fri Feb 3 15:50:04.866 JST BGP router identifier 10.255.1.7, local AS number 65001 BGP generic scan interval 60 secs Non-stop routing is enabled BGP table state: Active Table ID: 0x0 RD version: 0 BGP main routing table version 181 BGP NSR Initial initsync version 1 (Reached) BGP NSR/ISSU Sync-Group versions 0/0 BGP scan interval 60 secs Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 65001:300 *>i192.168.0.0/24 10.255.1.1 0 100 0 ? Route Distinguisher: 65001:400 *>i192.168.0.0/24 10.255.1.2 100 0 i Route Distinguisher: 65001:500 *>i192.168.0.0/24 10.255.1.1 0 100 0 ? Route Distinguisher: 65002:300 *>i192.168.1.0/24 10.255.1.5 300 0 65002 i *>i192.168.1.254/32 10.255.1.5 300 0 65002 i Route Distinguisher: 65002:400 *>i192.168.1.0/24 10.255.1.4 300 0 65002 i *>i192.168.1.254/32 10.255.1.4 300 0 65002 i Route Distinguisher: 65002:500 *>i192.168.1.0/24 10.255.1.6 300 0 65002 i cust-c の動作確認 rt01（PE）で対向 AS から広告された VRF 経路を受け取れていることを確認します。 RP/0/RP0/CPU0:rt01#show route vrf cust-c Fri Feb 3 14:03:42.980 JST Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP A - access/subscriber, a - Application route M - mobile route, r - RPL, t - Traffic Engineering, (!) - FRR Backup path Gateway of last resort is not set C 192.168.0.0/24 is directly connected, 6d20h, GigabitEthernet0/0/0/3 L 192.168.0.254/32 is directly connected, 6d20h, GigabitEthernet0/0/0/3 B 192.168.1.0/24 [200/0] via 10.255.1.5 (nexthop in vrf default), 1d23h B 192.168.1.254/32 [200/0] via 10.255.1.5 (nexthop in vrf default), 1d23h ping で疎通確認を行なってみます。 RP/0/RP0/CPU0:rt01#ping 192.168.1.254 vrf cust-c Fri Feb 3 16:07:13.844 JST Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 3/8/14 ms RP/0/RP0/CPU0:ar1018-rt01#traceroute 192.168.1.254 vrf cust-c Fri Feb 3 16:07:17.423 JST Type escape sequence to abort. Tracing the route to 192.168.1.254 1 10.1.2.2 [MPLS: Label 62 Exp 0] 14 msec 7 msec 14 msec 2 10.100.2.2 [MPLS: Label 31 Exp 0] 4 msec 11 msec 4 msec 3 192.168.1.254 8 msec 13 msec 3 msec パケットが転送でき、VPN が構築できていることが確認できました。 cust-d の動作確認 rt02（PE）で対向 AS から広告された VRF 経路を受け取れていることを確認します。 user@rt02> ping 192.168.1.254 routing-instance CUST-D PING 192.168.1.254 (192.168.1.254): 56 data bytes 64 bytes from 192.168.1.254: icmp_seq=0 ttl=62 time=2.849 ms 64 bytes from 192.168.1.254: icmp_seq=1 ttl=62 time=2.507 ms 64 bytes from 192.168.1.254: icmp_seq=2 ttl=62 time=3.050 ms ^C --- 192.168.1.254 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.507/2.802/3.050/0.224 ms user@rt02> traceroute 192.168.1.254 routing-instance CUST-D no-resolve traceroute to 192.168.1.254 (192.168.1.254), 30 hops max, 52 byte packets 1 10.1.4.2 11.656 ms 2.224 ms 2.109 ms MPLS Label=24018 CoS=0 TTL=1 S=1 2 10.100.1.2 3.361 ms 10.787 ms 2.800 ms MPLS Label=24017 CoS=0 TTL=1 S=1 3 192.168.1.254 2.290 ms 1.691 ms 1.632 ms パケットが転送でき、VPN が構築できていることが確認できました。 cust-e の動作確認 rt01（PE）で対向 AS から広告された VRF 経路を受け取れていることを確認します。 RP/0/RP0/CPU0:rt01#show route vrf cust-e Fri Feb 3 14:03:54.438 JST Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP A - access/subscriber, a - Application route M - mobile route, r - RPL, t - Traffic Engineering, (!) - FRR Backup path Gateway of last resort is not set C 192.168.0.0/24 is directly connected, 6d19h, GigabitEthernet0/0/0/4 L 192.168.0.254/32 is directly connected, 6d19h, GigabitEthernet0/0/0/4 B 192.168.1.0/24 [200/0] via 10.255.1.6 (nexthop in vrf default), 00:37:18 ping で疎通確認を行なってみます。 RP/0/RP0/CPU0:rt01#ping 192.168.1.254 vrf cust-e Fri Feb 3 16:07:29.739 JST Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 3/7/13 ms RP/0/RP0/CPU0:ar1018-rt01#traceroute 192.168.1.254 vrf cust-e Fri Feb 3 16:07:33.584 JST Type escape sequence to abort. Tracing the route to 192.168.1.254 1 10.100.3.1 [MPLS: Labels 16006/524284 Exp 0] 11 msec 14 msec 5 msec 2 10.2.6.1 [MPLS: Label 524276 Exp 0] 12 msec 4 msec 7 msec 3 192.168.1.254 13 msec 6 msec 16 msec パケットが転送でき、VPN が構築できていることが確認できました。 以上で全ての組で VPN が構築できている事が確認できました。 まとめ IOS XR 、Junos と SR OS の Multi-vendor 環境における Multi-AS L3VPN の検証結果を紹介しました。 次回の記事では、これらの Multi-vendor 環境における Multi-AS L2VPN について紹介予定です。 （2023/8/21 追記） 公開しました： [Multi-AS Segment Routing 検証連載 #13] SR-MPLS L2VPN(EVPN) using IOS XR, Junos and SR OS

みなさんこんにちは、イノベーションセンターの @Mahito です。 普段は社内のエンジニアが働きやすくなることを目標に、コーポレートエンジニアとしての活動やエンジニア向けイベントの企画・運営をしています。 今回は NTT ComのSpeaker Deckアカウント ができましたというお知らせになります。 Speaker Deck 開設の背景 以前から、社内のエンジニアがイベントなどで外部発表をしたものの、 発表資料を置く場所がないという話がありました。 今まで会社として公式に発表資料を掲載する場所はなく、 部署単位での発表資料を公開する場所を用意していた時期もあります。 しかし、社内の組織変更や、利用していたサービスの仕様変更などもあり使われなくなったという過去があります。 結果として、外部発表をしたエンジニアは資料を公開しない、もしくは、個人のアカウントにアップロードをするという状況が続いていました。 特に前者は、せっかく発表する価値のある内容の資料が誰にも共有されることもなく仕舞われているという状況でした。 こうした状況の背景には、全社に関わるプロモーションは広報の仕事なので、 発表資料を公開する場所は広報が用意をするべきだという空気がありました。 しかしながら、なかなか整理等を実施して実現方法を含めて環境まで準備するには時間がかかりそうであったため、 本ブログのようにエンジニアが主体になって全社に関わるプロモーションの活動している実績もあり、 今回はエンジニアサイドから広報に外部発表の資料を置く場所を作らせてほしいという提案へ行くことにしました。 広報との話し合い 広報とは現状の課題として、会社のプレゼンス向上機会の損失という話をメインに進めました。 広報からは公式サイトに資料を置くこともできるという話もありましたが、 単純にPDFを置いて資料を見たい人がダウンロードするという流れを考えると、 不便さがあるという話をしました。 一方、Speaker Deckではブラウザ上で資料を見えることやページごとにURLが発行されており、 資料を見る側にとって便利なサービスであることを伝えました。 話し合いの結果、広報室から発表資料をSpeaker Deckに置くこと理解を得ることができ、 エンジニアブログの運用の実績から、Speaker Deckの運用もエンジニアサイドに一任して貰う形で終わりました。 Speaker Deck の運用 Speaker Deckへの資料掲載はハードルや手間を減らすために、 全社員が使えるマイクロソフトのサービスで簡易な掲載フローを組みました。 掲載までの流れは以下のようになっています。 掲載希望者はMS Formsから掲載のエントリー Power AutomateがMS Formsのエントリー情報をTeamsのSpeaker Deckの管理チームに通知 通知を元にSpeaker Deckへ記事を掲載 本当は3の部分もAPIを使って自動化しておきたいところですが、 あいにくSpeaker DeckにはAPIがないようなので手作業となっています。 今のところ依頼がまだそんなに多くないので人力でなんとかなっていますが、 依頼が増えてくるようならばヘッドレスブラウザなどを使うことも考えます。 おわりに 今まで社内のエンジニアたちが「外部で発表したけど資料を公開する場所がない！」というフラストレーションをためていましたが、 今回Speaker Deckを作ったことでこうした問題の解決になればと思っています。 また、「NTT Comがイベントで発表していたけどその資料が見つからない！」なんてご不便をおかけすることもあったかと思います。 これからはNTT Com社員が外部発表などをした際には、Speaker Deckに発表資料をアップロードすることもありますので、 興味のあるかたは是非 NTT ComのSpeaker Deckアカウント をフォローしてみてください。

目次 目次 はじめに L5GとICGWの相互接続構成 デモ内容 温湿度、Co2濃度の可視化 カメラ画像 各社L5Gのスループット計測値 設定・運用面の工夫 ゼロタッチプロビジョニング デバイスの遠隔保守 おわりに はじめに こんにちは、5G&IoTサービス部、IoTサービス部門の岩辻です。 NTTコミュニケーションズ株式会社 (以下、NTT Com) は、世界最大級のネットワーク展示会である 「Interop Tokyo 2023 (会場 : 幕張メッセ、会期 : 2023年6月14日〜16日、以下Interop) 」 において会場内に構築されたローカル5G (以下、L5G) と IoT Connect Gateway (以下、ICGW) の相互接続を実現しました。 また、L5G、ICGWを通じて収集したIoTデバイスのセンサデータ、L5Gネットワークのスループット計測などの可視化も実施しました。 本記事ではその構成や可視化方法、IoTデバイス運用面での工夫について解説します。 Interopでの取り組みを通じて、ICGWによって実現できること、 それをいかに効率よく構築・運用できるかを知っていただけると思います。 L5GとICGWの相互接続構成 現状、ICGWはNTT ComのMVMO回線であるIoT Connect Mobile Type S (以下 、ICMS) のみで利用できるサービスとなっていますが、今回はL5Gとの相互接続にチャレンジしました。 下図にあるように、Flexible Inter Connect (以下、FIC) を活用して、各社スライスを切ったL5G環境とICGWを容易に繋げることができました。 ICGWからThings Cloudへの接続はすでに商用提供されている機能となり、L5GとSDPF商材との組み合わせによって新たなソリューション展開が可能であるという技術的確認ができました。 ICGW以外にも様々なSDPFサービスの組み合わせにより、お客様環境を柔軟に構築することが可能になります。 L5Gの基地局や上流NWのトラブルによって、ICGWがデバイスを識別できなくなるという事象はありましたが、これについては暫定対処を実施しました。 デバイスに対して監視用のPingを定期的に飛ばし、疎通がなくなったら通知する仕組みを急遽用意し、異常検知を通知していました。 この通知によって問題解決をスピード感をもって実現できました。 デモ内容 Interop会場内にセンサー類を取り付けたデバイスを計8台配置し、会場内のL5G経由でICGWに接続 & クラウドへ転送して可視化しました。 クラウド上で可視化したデモ一覧は以下となります。 温湿度、Co2濃度の可視化 カメラ画像 各社様L5Gのスループット計測値 順次、実際の画面を交えて説明していきます。 温湿度、Co2濃度の可視化 センサーから送られてきたデータをICGWのクラウドサービス接続機能を使ってThings Cloudに送り、可視化をしています。 Things Cloudの標準ウィジェット機能を利用して温湿度のグラフ化を行っています。 また、Co2濃度に関してはカスタムウィジェット機能を使って、Interopの会場図上にヒートマップで可視化しました。 過去の類似例を参考に、Angularで開発してThings Cloud上にデプロイしています。 Things Cloudが受け取るデータのフォーマットは厳しく決められており、それに合わせるのはデバイスにとって負担となりますが、ICGWのフォーマット変換機能 (2023/09リリース予定) を使って解決しています。 予め作成した変換テンプレートに沿ってICGW内でデータの加工するため、デバイスからは計測値のみ送って、ICGW内でThings Cloudの形に統一する、ということが可能です。 デバイス側でのデータ加工の負担をなくし、送信するデータのサイズも小さくできるメリットがあります。 カメラ画像 M5Stack UnitV2 AI カメラをデバイスに取り付け、画像をThings Cloudで表示しています。 また、今回取り付けたカメラには物体認識の機能が備わっているため、撮影された画像の中のオブジェクト数と人数もデバイスから送信し、Things Cloud上でグラフ化しています。 実際のユースケースでは、イベント会場内の来客人数把握や人流検知に応用できるものだと考えています。 各社L5Gのスループット計測値 各社L5GのスループットをThings Cloudと、AWS EC2上に立てたGrafanaで可視化しました。 当初、Things Cloud上での可視化のみを予定していましたが、各社のLatency/Jitterの制御をよりきれいにグラフで表現したいという声があったため、急遽Grafanaでの可視化も行いました。 データはThings Cloudにのみアップロードし、Grafana側はThings Cloudに対してデータ取得のリクエストを発行して取得&利用しています。 今回は稼働が足りず断念しましたが、ICGWのミラーリング機能 (2023/09リリース予定) を利用すればThings Cloudに送りつつ、他クラウドにも同時に送ることが可能となり、複数のクラウドでの可視化がさらに容易になります。 (※ 各社帯域に制限をかけているため、Upload/Downloadについては差分が出ています) 設定・運用面の工夫 実際のお客様の環境では、IoT デバイスの数は多数になり、また設置場所もそれぞれバラバラになってしまうことが多いです。 設定の変更やトラブル対応時にはデバイスの元まで駆けつける必要がありますが、ICGWを利用すればその負担も軽減できます。 今回はInterop会場を実際のお客様環境に見立てて、我々が運用する上でチャレンジした内容を紹介させていただきます。 ゼロタッチプロビジョニング 今回のInteropで利用したデバイス数は8台程度で1台1台設定しても大きな負担にはなりませんが、実際のお客様環境ではもっと多数を利用することがほとんどです。 そのため、ICGWのコンフィグ配信、ストレージ機能を使って、下図のような構成でゼロタッチプロビジョニングを実現しています。 まずは以下の事前設定をします。 Node-REDでICGWにセンサーデータを送信するシナリオファイルを作成 シナリオファイルをクラウドストレージ (Wasabi) にアップロード ストレージ機能を使うための設定情報をコンフィグ配信機能に登録 設定ファイルの更新をICGWに問い合わせ、更新があればストレージ機能を使ってWasabiにシナリオファイルを取得するスクリプトを作成 4で作成したスクリプトをデバイス上で動作し続けるよう設定 事前設定を終えると、SIMをデバイスに差すだけで、シナリオファイルの取得&センサーデータの送信が始まり、ゼロタッチプロビジョニングが実現できます。 また、Node-REDのシナリオファイルを更新する際にも、1デバイス上でシナリオファイルを修正してWasabiにアップロードし、設定ファイルを更新するだけで8台全てにシナリオファイルの変更が完了します。 初期設定だけでなく、更新にも強い構成にでき、準備段階での稼働削減になりました。 デバイスの遠隔保守 ICGWのリモートアクセス機能を使って、IoTデバイスに遠隔から入れるようにしました。 リモートアクセス機能は、下図のようにICGW上で設定するだけで、外からオンデマンドにデバイスへアクセスできるエンドポイントを提供する機能です。 各デバイス毎のリモートアクセス設定を投入さえすれば、場所を選ばずデバイスの設定ができるため、まずはリモートアクセス設定を入れるところから始め、Interopの準備を進めていました。 会期中の運用では、デバイス上で動作するNode-REDに入ってシナリオの動作確認をしたり、必要であれば修正してました。 会場が広く、設置場所もバラバラであったため、一台一台デバイスの元まで行って確認する手間を省け、大きなメリットとなりました。 おわりに Interop会場に構築されたL5GとICGWの相互接続と環境データの可視化、運用負担の軽減などについて紹介させていただきました。 今回L5GとICGWの相互接続とのフィージビリティが検証できたので、今後はICMS以外の回線とも連携を進めていき、あらゆる回線からICGWを利用できて、よりお客様に利用していただきやすくなるよう努めていきたいと考えております。 9月以降にはインターネット回線からICGWを利用できる機能もリリース予定です。 ご興味のある方はぜひICGWのご利用を検討してみてください。 ICGWに関するお問い合わせ先 IoT Connect Gatewayサービス詳細 ICGWに関するお問い合わせ先 トライアル、サービス導入に関するお問い合わせ 資料請求・お問い合わせフォーム 開発チームへのお問い合わせ（お手数ですが＠を半角文字に置き換えてください） メールを送る Interop Tokyo 2023 のその他関連記事 Engineer's Blog では本記事以外にもInterop Tokyo 2023 に関する記事が投稿されてます。 ご興味をお持ちの方は是非御覧ください。 Interop Tokyo 2023 〜 マルチベンダL5G x IoTサービス連携の取り組み〜 Interop Tokyo 2023 〜 L5G x AWS Outpostsサーバーの取り組み紹介 〜

概要 はじめまして。イノベーションセンター所属の鄭（GitHub: nbhgytzheng ）です。2021年入社し、現在はテクノロジー部門のOsecT-Ops プロジェクトに所属して、 OsecT の開発・運用業務に取り組んでいます。 今回はOsecTで利用している Zeek （ネットワーク・セキュリティ・モニタリングツール）とZeekのプロトコル拡張ツールである Spicy （Zeekで利用するC++のパーサーをC++で記述することなく簡易に生成できるツール）の概要及び使い方・利用例を紹介します。探した限り日本語での使い方の紹介記事がないため、今回が日本初紹介です。本記事の目標は、ZeekとSpicyを使って任意のプロトコルを含むトラフィック解析ができるようになることです。 OsecTとは OsecTとは工場などの制御システム（OT; Operational Technology）のセキュリティリスクを可視化・検知するサービスです。 多様化する工場システムのセキュリティ脅威に対して、パケット解析するセンサー機器を設置するだけで、OTシステムへの影響なく、ネットワークの可視化と脅威・脆弱性検知ができます。早期にリスク感知できる状態を作り、工場停止による損失を未然に防ぐことができます。詳しくは過去のブログ記事に書いているので、興味がある人はぜひ見てください。（ OsecTリリース ・ OsecT前編 ・ OsecT後編 ） Zeekとは Zeekとはネットワークを監視し、トラフィックを解析して、IPアドレス、MACアドレスやプロトコルなどの情報をログとして出力するOSSです。Zeekは下記のような基本ログ（conn.log, dns.log, dhcp.logなど）を出力します。また必要に応じて、プラグインを利用することで出力ログの追加ができます。 # 生成のログの例：dns.log #separator \x09 #set_separator , #empty_field (empty) #unset_field - #path dns #open 2023-03-14-16-15-20 #fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p proto trans_id rtt query qclass qclass_name qtype qtype_name rcode rcode_name AA TC RD RA Z answers TTLs rejected pkts #types time string addr port addr port enum count interval string count string count string count string bool bool bool bool count vector[string] vector[interval] bool int 1539457598.376546 CHTBxA4O2ypY1PxYPg fd00:f81d:f5f:6b92:fd0d:9399:3d28:3984 5353 ff02::fb 5353 udp 0 - _ipp._tcp.local 1 C_INTERNET 12 PTR - - F F F F 0 - - F - 1539459646.378861 COMnQY2JaJZ3TllMYb fd00:f81d:f5f:6b92:fd0d:9399:3d28:3984 5353 ff02::fb 5353 udp 0 - _ipp._tcp.local 1 C_INTERNET 12 PTR - - F F F F 0 - - F - 1539463246.380625 Cgu5Zw1ASoGNZ2UGok fd00:f81d:f5f:6b92:fd0d:9399:3d28:3984 5353 ff02::fb 5353 udp 0 - _ipp._tcp.local 1 C_INTERNET 12 PTR - - F F F F 0 - - F - 1539466846.382677 C5X9v4snqSDPMj3u7 fd00:f81d:f5f:6b92:fd0d:9399:3d28:3984 5353 ff02::fb 5353 udp 0 - _ipp._tcp.local 1 C_INTERNET 12 PTR - - F F F F 0 - - F - ... Spicyとは プラグインを利用することで、出力ログを増やせますが、必要なログを出力するプラグインがないこともあります。例えば、以下の要件を満たすプラグインは存在しません。 Zeekが対応しているプロトコルの出力ログ内に追加の情報を加えて出力したい場合 Zeekが対応していないプロトコルの情報をログに出するしたい場合 ここで登場するのがSpicyです。SpciyとはZeekで利用するC++のパーサーをC++で記述することなく簡易に生成するためのツールです。Spicyを利用すれば、ログ情報の追加やZeek及びプラグインで解析できないプロトコルの解析ができるようになります。 Zeek・Spicyによるプロトコル解析 ここまではZeek, Spicyの概要について紹介しました。本章ではZeek, Spicyの利用方法について、環境構築からコーディングまで紹介します。 1. ZeekとSpicyのインストール はじめに、Zeek, Spicyの実行環境を構築します。今回はUbuntu 22.04.1をベースに環境構築の方法を示します。その他のOSでのインストール方法は 公式サイト を参照してください。 1.まずはZeekのリソース（GitHub）を取得するため、gitコマンドをインストールします。 ~$ sudo apt install git 2.次にgitコマンドを利用して、Zeekのリソースをクローンします。 ~$ git clone --recursive https://github.com/zeek/zeek -b v5.0.0 3.Zeekのリソースはcmakeコマンドを利用して自動インストールできるので、cmakeコマンドと関連パッケージをインストールします。 ~$ sudo apt-get install cmake make gcc g++ flex libfl-dev bison libpcap-dev libssl-dev python3 python3-dev swig zlib1g-dev 4.最後にクローンしたZeekディレクトリへ移動し、以下のコマンドを実行すれば自動でインストールされます。makeは状況に応じて1時間以上かかる場合もあります。最後のmake installはスーパーユーザーで実行しないと、エラーになるため注意してください。 ~$ ./configure --build-type=Release ...一部省略... ================================================================ -- Configuring done -- Generating done -- Build files have been written to: /home/xxx/zeek/build ~$ make ...一部省略... Consolidate compiler generated dependencies of target zeek-archiver make[3]: Leaving directory '/home/xxx/zeek/build' [100%] Built target zeek-archiver ~$ sudo make install ...一部省略... make[1]: Leaving directory '/home/xxx/zeek/build' 5.以上でZeekのインストールは完了です。以下のコマンドでZeekが利用できることを確認します。 # パス追加 ~$ export PATH="$PATH:/usr/local/zeek/bin" # zeekコマンド確認 ~$ zeek -version zeek version 5.0.0 6.Spicyのインストールは 公式サイト でDEBファイルを取得し、以下のコマンドを順に実行すればインストールが完了です。 ~$ sudo dpkg --install xxx.deb (例：spicy-dev.deb) Selecting previously unselected package spicy. (Reading database ... 212653 files and directories currently installed.) Preparing to unpack spicy-dev.deb ... Unpacking spicy (2.4.8) ... Setting up spicy (2.4.8) ... 7.インストールが完了したら、以下のコマンドでSpicyが利用できることを確認します。 # パス追加 ~$ export PATH="$PATH:/opt/spicy/bin/spicyc" # spicyコマンド確認 ~$ spicyz -version 1.3.16 ~$ spicyc -version spicyc v1.5.0 (d0bc6053) 以上でZeekとSpicyの実行環境の構築は完了です。 2. プロトコル仕様の確認 SpicyではIPベースのプロトコルだけでなく、イーサネットベースのプロトコルのパーサーも作成できます。今回はIPベースのUDPプロトコルを例に説明します。IPベースのプロトコル構造は以下のようになっています。IPベースでSpicyを利用する場合、Spicyが自動的に青い部分（イーサネットヘッダー、IPヘッダー、TCP/UDPヘッダー）を除き、オレンジ色の部分を処理します。 まず、ログに出力する内容を決めるために、解析対象のプロトコル仕様を確認します。プロトコル仕様はGoogleなどで検索して見つけられるケースもありますが、プロトコルに関わる各種団体・協会経由で仕様書を取得するケースもあります。プロトコル仕様からポート番号（今回の例では1111）と以下のようなパケットフォーマット定義を用意して、Spicyでのパーサー実装に進みます。 項目名/フィールド名 サイズ（オクテット） 内容 header1 2 プロトコルヘッダー header2 1 プロトコルヘッダー command 2 リクエストのタイプを表す subCommand 2 実行する動作を表す … … … 次にパーサーで利用するSpicyファイル・evtファイル・Zeekファイルの作成方法について紹介します。 3. Spicyファイルを作成 本節では以下のテンプレートと前節で取得したプロトコル情報（ポート番号・パケットフォーマット定義）を利用したSpicyファイルの基本的な作成方法を紹介します。Spicyファイルでは、通信プロトコルのプロトコルフォーマットを定義します。 # spicyテンプレート module MYPROTOCOL; import zeek; import spicy; public type Message = unit { PROTOCOL_FIELD1: FIELD_TYPE &size=1; PROTOCOL_FIELD2: FIELD_TYPE &size=2; ... on %done { print self; zeek::confirm_protocol();} }; テンプレートの各部分を解説します。 module MYPROTOCOL; ：任意のモジュール名を宣言 多くの場合、解析対象のプロトコル名を記述します。 import xxx ：Spicy関数の取り込み 基本的には、Spicyの基本関数が入っている”spicy”とconn.logのservice列にプロトコル名を出力ための”zeek”が必要です。 public type Message = unit {} ：プロトコルのデータ部分を格納する変数 データ部分はこの Message に渡されます。 PROTOCOL_FIELD1: FIELD_TYPE &size=1; ：データ部分をブロックごとに分解 書き方はFIELD_TYPEによって異なるため 公式サイト を参照してください。 on %done { print self; zeek::confirm_protocol();} ：Spicyが解析を終えたときに実行する関数 print self; ：解析データの全てをprint（debug用） zeek::confirm_protocol(); ：解析が終わったことをZeekに通知 そして、前節で取得したプロトコル情報を利用して、テンプレートを改造すると以下のようなSpicyファイルが作成できます。ここで、 subCommand までが必要なデータとした場合、最後に tmp という PROTOCOL_FIELD を追加で作成し、 subCommand 以降のデータをtmpに入れることができます。 module protocol_name; # Spicyを単独で実行する場合は下の import zeek をコメントアウトする import zeek; import spicy; public type Message = unit { header1: bytes &size=2; header2: bytes &size=1; command: bytes &size=2; subCommand: bytes &size=2; tmp: bytes &eod; # Spicyを単独で実行する場合は zeek::confirm_protocol(); 部分をコメントアウトする on %done { print self; zeek::confirm_protocol();} }; 実行すると、以下の出力が得られます。（Spicyのみ実行したい場合は上記のコードをコメントに従って変更する必要があります） # 実行結果 ~$ printf '\x00\x00\x01\x02\x02\x03\x03\x11\x11\x11\x11\x11\x11\x11' | spicy-driver test.spicy [$header1=b"\x00\x00", $header2=b"\x01", $command=b"\x02\x02", $subCommand=b"\x03\x03", $tmp=b"\x11\x11\x11\x11\x11\x11\x11"] 4. evtファイルを作成 本節では以下のテンプレートとプロトコル情報（ポート番号・パケットフォーマット定義）・Spicyファイルを利用して、evtファイルの作成方法を紹介します。evtファイルでは解析したいプロトコルを指定します。 protocol analyzer spicy::MYPROTOCOL over UDP: parse with MYPROTOCOL::Message, port PORT_NUMBER/udp; import MYPROTOCOL; on MYPROTOCOL::Message -> event MYPROTOCOL::message($conn, self.PROTOCOL_FIELD1, ...); 例えば、以下のようにプロトコルのポート番号（1111）、プロトコル名（protocol_name）、Zeekに渡したいプロトコルフィールド（header1、header2など）を記述します。 protocol analyzer spicy::protocol_name over UDP: parse with protocol_name::Message, port 1111/udp; import protocol_name; on protocol_name::Message -> event protocol_name::message($conn, self.header1, self.header2, ...); evtファイルを作成後、コンパイルしてオブジェクトファイルであるhtloファイルを生成します。 ~$ spicyz -o test.hlto test.spicy test.evt ~$ # test.hltoが生成される 5. Zeekファイルを作成 最後に、以下のテンプレートを利用して、Zeekファイルの作成方法を紹介します。Zeekファイルでは、Spicyの処理結果をログに出力します。 # Spicy側のパーサーを利用するための宣言 module MYPROTOCOL; # 実行開始前に必要な変数の宣言（global変数） export { redef enum Log::ID += { LOG }; # この変数の内容はlogに書き出す type Info: record { ts: time &log; uid: string &log; id: conn_id &log; ## MYPROTOCOL data. PROTOCOL_FIELD1: string &log; ## MYPROTOCOL data. PROTOCOL_FIELD2: string &log; ## MYPROTOCOL data. PROTOCOL_FIELD3: string &log; ... ... final_block: count &optional; done: bool &default=F; }; global log_myprotocol: event(rec: Info); } global expected_data_conns: table[addr, port, addr] of Info; redef record connection += { myprotocol: Info &optional; }; # $pathで出力ファイル名を指定する event zeek_init() &priority=5 { Log::create_stream(MYPROTOCOL::LOG, [$columns = Info, $ev = log_myprotocol, $path="myprotocol"]); } # logに書き出す時の動作を書く関数 event MYPROTOCOL::message(c: connection, PROTOCOL_FIELD1: string, PROTOCOL_FIELD2: string, PROTOCOL_FIELD3: string, ... ) { local info: Info; info$ts = network_time(); info$uid = c$uid; info$id = c$id; info$PROTOCOL_FIELD1 = PROTOCOL_FIELD1; info$PROTOCOL_FIELD2 = PROTOCOL_FIELD2; info$PROTOCOL_FIELD3 = PROTOCOL_FIELD3; ... ... c$myprotocol = info; # info内の変数を全部logに書き出す Log::write(MYPROTOCOL::LOG, info); } テンプレートの各部分を解説します。 module MYPROTOCOL; ：Spciyで作成したパーサーをインポートするために宣言 export {…}; ：Zeekで利用する変数の宣言 ログに出力したい項目はここで指定します。 event zeek_init() &priority=5 {…} ：出力ログのパスを指定 event MYPROTOCOL::message(…) {…} ：パーサーの処理結果をログに出力 ログに出力するタイミングで加工することもできます。 上記のテンプレートと今までの結果を利用し、プロトコル名（protocol_name）、出力したいフィールド（header1など）、出力したいログファイルの名前（$path="protocol_name"）を書き換えることで、以下のようなZeekファイルを作成できます。 # Spicy側のパーサーを利用するための宣言 module protocol_name; # 実行開始前に必要な変数の宣言（global変数） export { redef enum Log::ID += { LOG }; # この変数の内容はlogに書き出す type Info: record { ts: time &log; uid: string &log; id: conn_id &log; ## MYPROTOCOL data. header1: string &log; ## MYPROTOCOL data. header2: string &log; final_block: count &optional; done: bool &default=F; }; global log_protocol_name: event(rec: Info); } global expected_data_conns: table[addr, port, addr] of Info; redef record connection += { protocol_name: Info &optional; }; # $pathで出力ファイル名を指定する event zeek_init() &priority=5 { Log::create_stream(protocol_name::LOG, [$columns = Info, $ev = log_protocol_name, $path="protocol_name"]); } # logに書き出す時の動作を書く関数 event protocol_name::message(c: connection, header1: string, header2: string ) { local info: Info; info$ts = network_time(); info$uid = c$uid; info$id = c$id; info$header1 = header1; info$header2 = header2; c$protocol_name = info; # info内の変数を全部logに書き出す Log::write(protocol_name::LOG, info); } 6. テスト用Pcapで出力ログの確認 最後にテスト用Pcapを使って出力ログを確認します。 ~$ zeek -Cr cclink_ief_basic.pcap test.hlto test.zeek ~$ # protocol_name.logが生成される 生成されたログの中身を確認すると、以下のようになっています。最後の16進数の部分（ P\x00 \x00 など）は今回出力したい部分です。今回は16進数のデータを出力しただけですが、Zeekファイルを作り込むことで人間が解釈できる文字列として出力もできます。 #separator \x09 #set_separator , #empty_field (empty) #unset_field - #path protocol_name #open 2023-06-12-15-53-06 #fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p header1 header2 #types time string addr port addr port string string 1655284124.859924 C3KZkP3l8QTJaS2vg7 172.16.134.128 61450 172.16.134.255 61450 P\x00 \x00 1655284124.953994 CG3NWX3t9Qf1Xrezl5 172.16.134.129 61450 172.16.134.128 61450 \xd0\x00 \x00 1655284125.375608 C3KZkP3l8QTJaS2vg7 172.16.134.128 61450 172.16.134.255 61450 P\x00 \x00 1655284125.484180 CG3NWX3t9Qf1Xrezl5 172.16.134.129 61450 172.16.134.128 61450 \xd0\x00 \x00 1655284125.500485 C3KZkP3l8QTJaS2vg7 172.16.134.128 61450 172.16.134.255 61450 P\x00 \x00 1655284125.610011 CG3NWX3t9Qf1Xrezl5 172.16.134.129 61450 172.16.134.128 61450 \xd0\x00 \x00 ... ... Zeek・Spicyの活用例 ここまで、Zeek, Spicyの使い方まで紹介しました。本章ではイメージを深めるため、OsecTで実装したZeekが対応していないプロトコルの追加と、Zeekの基本ログへの情報追加の2つの例を紹介します。 CC-Linkファミリーへの対応 今回は市場ニーズを踏まえた上で、Zeekが対応していないOTプロトコル（ CC-Linkファミリー ）に対応しました。具体的なプロトコルはCC-Link IE FieldとCC-Link IE ControlとCC-Link IE Field Basicです。実装したコードは公開しているため、興味がある方は以下のリンクを参照ください。 zeek-parser-CCLinkFieldBasic zeek-parser-CCLinkField-CCLinkControl CC-Link IE Field Basicの出力ログは以下のようになっています。ペイロードの奥深くまで情報を取得することもできますが、今回はパケットの種類（cyclicDataRes、cyclicDataReq）と使っているコマンド（cyclic）をログに出力しました。 #separator \x09 #set_separator , #empty_field (empty) #unset_field - #path cclink-ief-basic #open 2023-05-27-00-52-06 #fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p pdu cmd number ts_end #types time string addr port addr port string string int time 1655284124.953994 CIAp8bugKIZRVpAYk 172.16.134.129 61450 172.16.134.128 61450 cyclicDataRes - 222 1655284149.499713 1655284124.859924 Ckkc3929guO41BnpSa 172.16.134.128 61450 172.16.134.255 61450 cyclicDataReq cyclic 222 1655284149.392238 #close 2023-05-27-00-52-06 CC-Link IE FieldとCC-Link IE Controlの出力ログは以下のようになっています。ここではパケットの種類（select、scanなど）と種類別の情報（0x0001など）をログに出力しました。今回はテスト用Pcapを自作したため、全て 0x0001 になっています。 #separator \x09 #set_separator , #empty_field (empty) #unset_field - #path cclink-ie #open 2023-03-15-16-56-36 #fields ts src_mac dst_mac service pdu_type cmd node_type node_id connection_info src_node_number number ts_end #types time string string string string string string int string string int time 1667903833.066101 00:11:11:11:11:11 00:00:00:00:00:01 cclink_ie_control select - - - - 0x0001 61 1667903833.134207 1667903833.065821 00:11:11:11:11:11 00:00:00:00:00:01 cclink_ie_control scan - - - - 0x0001 48 1667903833.129023 1667903833.064742 00:11:11:11:11:11 00:00:00:00:00:01 cclink_ie_control connectAck - - - - 0x0001 61 1667903833.133590 1667903833.065511 00:11:11:11:11:11 00:00:00:00:00:01 cclink_ie_control connect - - - - 0x0001 62 1667903833.134085 1667903833.067818 00:11:11:11:11:11 00:00:00:00:00:01 cclink_ie_control nTNTest - - - - 0x0001 53 1667903833.131018 1667903833.068939 00:11:11:11:11:11 00:00:00:00:00:01 cclink_ie_control dummy - - - - 0x0001 57 1667903833.133957 1667903833.065083 00:11:11:11:11:11 00:00:00:00:00:01 cclink_ie_control collect - - - - 0x0001 61 1667903833.133231 1667903833.064936 00:11:11:11:11:11 00:00:00:00:00:01 cclink_ie_control launch - - - - 0x0001 40 1667903833.132990 1667903833.066240 00:11:11:11:11:11 00:00:00:00:00:01 cclink_ie_control token - - - - 0x0001 57 1667903833.133351 #close 2023-03-15-16-56-36 Zeekの基本ログへの情報追加 DHCPv4はZeekが対応しているプロトコルですが、出力されるログの情報量に過不足がありました。そのため、Zeek, Spicyを利用して必要のない情報を削除・必要な情報を追加しました。実装したコードは公開しているため、興味がある方は MYDHCP を参照ください。 デフォルトの出力ログは以下のようになっています。 #separator \x09 #set_separator , #empty_field (empty) #unset_field - #path dhcp #open 2023-06-16-18-23-59 #fields ts uids client_addr server_addr mac host_name client_fqdn domain requested_addr assigned_addr lease_time client_message server_message msg_types duration #types time set[string] addr addr string string string string addr addr interval string string vector[string] interval 1624301983.013489 Cah1vz3icJOQ3kUtk4,C6uWeo2ldOmwsjKUj7 10.0.2.15 10.0.2.2 00:00:20:b0:60:b0 kali - - 10.0.2.15 10.0.2.15 86400.000000 - - REQUEST,ACK 0.000309 #close 2023-06-16-18-23-59 そして、Zeek, Spicyによって改造後のログは以下のように変更しました。本来のログのMACアドレスとタイムスタンプをそのまま利用し、 SrcIP,Hostname,Parameter,ListClassId を追加しました。 #separator \x09 #set_separator , #empty_field (empty) #unset_field - #path mydhcp #open 2023-06-16-18-23-59 #fields ts SrcIP SrcMAC Hostname ParameterList ClassId #types time addr string string vector[count] string 1624301983.013489 0.0.0.0 00:00:20:b0:60:b0 kali 1,2,6,12,15,26,28,121,3,33,40,41,42,119,249,252,17 - #close 2023-06-16-18-23-59 おわりに 今回はZeekとSpicyの概要及び使い方・利用例について紹介しました。この記事を参考に、プロトコルのパーサーを実装、ログ出力までできるようになれば幸いです。そして、Zeek, Spicyの活用例の章で紹介したスクリプトはすでにOsecTへ実装しリリース済です。OsecTもこれからZeek, Spicyを利用し、対応プロトコルの拡張などを続けていくので、興味を持たれた方はぜひご連絡ください。

はじめに こんにちは、イノベーションセンターの藤田、鈴ヶ嶺です。NTTコミュニケーションズ株式会社 (以下、NTT Com) は、世界最大級のネットワーク展示会である 「Interop Tokyo 2023（会場：幕張メッセ、会期：2023年6月14日〜16日）」 において構築されるShowNetに対し、コントリビューターとしてローカル5G（以下、L5G）システムを提供しました。その基盤としてAWS Outpostsサーバーを構築し提供しました。 本記事ではその構成や技術的な挑戦について解説します。 AWS Outpostsサーバーを用いたL5G基盤構築への挑戦 今回ShowNetにてL5G基盤をAWS Outposts サーバーを用いて構築するにあたり、2点の挑戦をしました。 Flexible InterConnectを利用したハイブリッドクラウドネットワーク EKS x EC2セルフマネージド型ノード on AWS Outpostsサーバー基盤 Flexible Inter Connectを利用したハイブリッドクラウドネットワーク 今回会場では、NTTドコモのキャリア 5G とNTT ComのL5G を組み合わせた環境で、ネットワークスライシング連携のデモンストレーションを構築・展示しています。その構築・展示に当たり、NTT Com内製のマイクロサービス開発フレームワーク Qmonus を活用しました。 このデモンストレーションを実現するためには、AWS Outposts サーバーをはじめとするオンプレミスと、Public Cloud (Public AWS) 間を安定して接続する必要があります。 本構築ではFlexible InterConnect、FIC-Connection AWSを利用することで、AWS OutpostsサーバーほかオンプレミスとPublic AWSに対して専用回線による安定した接続が可能なネットワークを実現しました。 EKS x EC2セルフマネージド型ノード on AWS Outpostsサーバー基盤 AWS OutpostsサーバーをL5G基盤として利用するにあたり、構築可能なEC2インスタンスタイプの制限があるため柔軟なリソース配分がしづらい問題がありました。 今回の構成ではより柔軟かつ可用性の高い基盤提供を目指し、Public AWSにてEKSクラスターを構築しAWS Outpostsサーバー上のEC2インスタンスをEKSのセルフマネージド型ノードとして動作する構成に挑戦をしています。 AWS Outpostsサーバー上のEC2インスタンスは同一VPC上に構築されたPublic AWS上のEC2インスタンスやEKSクラスターと疎通可能であるため、EKSの機能を利用しつつAWS Outpostsサーバーの機能であるLocal Network Interface（以下、LNI）を通じたpodレベルでのオンプレミスのネットワークとの接続を実現しています。 本構成によりAWSのマネージドなサービスをオンプレミスまで拡張することで、オンプレミスのネットワークと統合しつつ柔軟なリソース配分が可能となる可用性の高い基盤の提供に成功しています。 発見した課題 L5GのUPFをAWS Outpostsサーバー上に構築するにあたり、モバイル特有の処理を高速化する観点から1つのpodに対してLNI経由で複数のインターフェースをアタッチしDPDK経由で複数のVLANを接続をする挑戦も行いました。 しかしLNIはPromiscuous modeをサポートしていないため、macvlanによるNICの仮想化ができません。 1 またENA Poll Mode DriverはVLANをサポートしていないため、tagged vlanを利用できません。 2 以上から、本構成においてDPDK経由で複数のvlanを利用する高速化が困難であるといった課題が発見されました。 まとめ 本記事ではInterop Tokyo 2023のShowNetにおいて、L5G基盤に利用したAWS Outpostsサーバーの構成について紹介しました。本構成ではいくつか課題も見つかったため、それを踏まえてより柔軟性が高く可用性の高い基盤の提供を目指していくと共に、NTT Comのサービスへの応用について検討していきます。 https://docs.aws.amazon.com/outposts/latest/server-userguide/local-network-interface.html ↩ https://doc.dpdk.org/guides/nics/ena.html ↩

NTTコミュニケーションズ（以下、NTT Com）を含めたドコモグループではこの夏に3種類のインターンシップを開催します！ ビジネス創造インターンシップ ドコモハッカソン 現場受け入れ型インターンシップ このうち、この記事ではNTT Comのリアルな業務を体験できる「現場受け入れ型インターンシップ」について紹介します。 現場受け入れ型インターンシップとは NTTドコモやNTT Comの社員と一緒に働きながら、実務を体験していただくインターンシップです。 セールスやビジネスデザイン、エンジニア、デザイナー、リーガルなど幅広い職種を取り揃えて、業務体験を通じて仕事の理解を深め、成長機会を提供する内容となっています。 今季は2023年8月28日（月）～9月8日（金）の土日祝を除く平日10日間（2weeks）で開催されます。開催場所は、出社＋リモートワークのハイブリッド形式です（出社割合はポストにより異なります）。 募集ポスト 募集ポストについては下記のページの「受け入れポスト情報」をご覧ください。 information.nttdocomo-fresh.jp 記載されているポストのうち、受け入れ会社に NTTコミュニケーションズ株式会社 と記載されたポストがNTT Comでの業務です。 ポスト一覧表をこの記事の 末尾 にも掲載したので参考にしてください。 これまでのインターンシップの様子 これまで開催したインターンシップでNTT Comのエンジニア系ポストに参加してくれた学生の方々がこのEngineers' Blogに体験記を寄稿してくれています。 なお、NTT Comのデザイン系ポスト（KOEL）については KOEL公式note 、NTTドコモのエンジニア系ポストについては ドコモ開発者ブログ をご覧ください。 「インターンシップでどんなことに取り組むのだろう?」、「インターンシップを通して何が学べるのだろう?」といった疑問を解消する手助けになれば幸いです。 AI分野 engineers.ntt.com セキュリティ分野 engineers.ntt.com engineers.ntt.com engineers.ntt.com engineers.ntt.com ネットワーク分野 engineers.ntt.com engineers.ntt.com engineers.ntt.com engineers.ntt.com engineers.ntt.com ソフトウェア/クラウド分野 engineers.ntt.com engineers.ntt.com engineers.ntt.com engineers.ntt.com engineers.ntt.com まとめ みなさんもこの夏、ドコモのインターンシップに参加して、興味分野で圧倒的成長をしてみませんか？ 気になるポストの詳細やエントリーはこちらです（再掲）。 information.nttdocomo-fresh.jp エントリー締め切りは 6月30日（金）23:59 です。 みなさんのご応募をお待ちしています！ 参考：ポスト一覧表 各ポストの詳細については、 現場受け入れ型インターンシップ をご覧ください。 カラムの説明 ポスト：ポスト名 受入：受け入れ会社（ D =NTTドコモ、 C =NTT Com） 参考：参考情報 ビジネスデザイン（通信） ポスト 受入 参考 1.ドコモオンラインショップ/オンライン手続きの運用、 データ分析、販売促進施策企画、WEB広告運用業務 D 2.ahamoのモバイルサービスサイト・アプリのＵI/ＵX戦略の企画/開発/運用/分析/改善 D ネットワークデザイン ポスト 受入 参考 3.ドコモビジネスを実現するNW装置の開発・検証を行うエンジニア D - ドコモビジネス - Arcstar Universal Oneイーサネット専用線 セールス（スマートライフ） ポスト 受入 参考 4.ｄポイント・ｄ払い既存加盟店へのデジタルマーケティングを活用した販売促進支援 D ビジネスデザイン（スマートライフ） ポスト 受入 参考 5.自治体に向けた新たなヘルスケアサービスの企画とセールス統括を担うプロダクトマネージャー D - 健康マイレージ 6.クレジットカードサービス/dカードにおけるサービス戦略・企画 D - Theo+docomo×ｄカート積立投資 7.映像配信メディア「Lemino」向けオリジナルコンテンツの制作業務 D - 「Lemino」サービスサイト 8.dポイントクラブ会員基盤の拡大、及び新たな価値創出/サービスグロース検討 D - カボニューレコード プロダクト・サービスエンジニア ポスト 受入 参考 9.新デバイス・サービスの企画・開発 D セールス（法人） ポスト 受入 参考 10.法人のお客さまへの営業活動 C ビジネスデザイン（法人） ポスト 受入 参考 11.新サービスやビジネスの企画/プロモーション施策の立案 C - Smart Go / SmartGo Staple - OPEN HUB ソリューションエンジニア ポスト 受入 参考 12.法人のお客さま向けの新サービスの開発 C 13.法人向けのICTソリューション提供 C 14.次世代ネットワークサービスのソフトウェアエンジニア C - OCNにネットワークコントローラ入れてみたよ 15.次世代ネットワークサービスのセキュリティ機能開発 C 16.サイバー攻撃からお客さまを守るマネージドセキュリティサービスのサービス戦略/企画/マーケティング業務や、実際のお客さまへのセキュリティコンサルティング業務 C 17.オンライン英会話・オンライン医療などのビデオ通話を実現するプラットフォームサービス「SkyWay」の技術開発 C - SkyWay 先端研究開発（AI・データサイエンス） ポスト 受入 参考 18.機械翻訳/語学学習に関わる言語処理AIの研究開発 D 19.パブリッククラウドを活用した超大規模データ処理・分析環境開発 D 20.新しい画像認識技術の実用化開発および画像認識技術を活用したソリューション創出 D 21.FinTech領域における新規データ分析手法の検討業務 D 22.データ分析アプローチで全社・現場の課題を解決し、DXを推進（主にOSSを用いた分析システム） C 23.データ分析アプローチで全社・現場の課題を解決し、DXを推進(主にサービス開発組織の分析) C 24.データ分析アプローチで全社・現場の課題を解決し、DXを推進(主にセールス部門向け（大企業・中小企業担当）の分析) C 25.お客さまに具体的な価値を提供するAIテキスト分析プロダクトの開発 C 先端研究開発（ソフトウェア・セキュリティ） ポスト 受入 参考 26.大規模にクラウドを利用するドコモのCCoE（Cloud Center of Excellence）エンジニア D 27.エンタープライズ向け大規模クラウド/ネットワークサービスを支えるコントローラ開発 C - DSIGW - FRA - FIG - 2021 Cloud Meetup Egawa 「入社してから今までのお話」 - SDPFクラウド/サーバー ESIチームにおけるCI改善の取り組み - クラウドサービスのウラオモテ - Managed Load Balancer のつくりかた 28.エンタープライズ向け大規模クラウドサービス(仮想サーバー)のソフトウェア開発 C - Open TechLunch: 元ウェブ系エンジニアが語る IaaS（VM屋さん）の開発ってなにしてんの？ - CODT2022: エンタープライズ向けクラウドサービス 仮想サーバー基盤開発のリリースサイクル改善 - CODT2021: エンタープライズ向けクラウドサービスにおける大規模・商用環境でのホストOSバージョンアップ - CODT2020: エンタープライズ向けクラウドサービスにおける大規模・商用環境でのOpenStackバージョンアップとVMHAの実運用 29.エンタープライズ向け大規模クラウド/ネットワークサービスを支える共通機能のソフトウェア開発 C 30.エンタープライズ向け大規模クラウドサービスのコントローラにおけるSRE推進のためのクラウドネイティブな共通基盤開発・運用 C - Blue-Green デプロイメントを採用したデプロイの仕組みを実装して共通基盤として導入した話 31.仮想アプライアンス専用基盤に関わる仮想サーバ技術開発 C 32.NTTグループ向けDevOps基盤「Qmonus」の内製開発および導入支援 C - OCNにネットワークコントローラ入れてみたよ - Cloud Native環境におけるエンタープライズシステムに対する高可用性実現への取り組み - DevOpsプラットフォームの取り組み, NTTコミュニケーションズ（NTTドコモの法人事業） エンジニアズブログ 33.CSIRTでのサイバー攻撃への対応実践と高度化 C 34.Webアプリケーションの脆弱性診断実践 C 35.テレプレゼンス（遠隔操作ロボット）の研究開発 C - テレプレゼンスPJ インターン参加レポート - 63. テレプレゼンス・ロボット・最後にRust w/ nakakura, kmat - みんなの夢を叶える「走るコタツ」を作ってみた - NTT Com、ロボットやカーボンクレジットなど先進ICTサービスを披露 36.データ分析基盤エンジニア C 38.サイバー攻撃の原理を理解し、攻撃インフラ（マルウェアインフラ）を解明するセキュリティアナリスト C - アクセスログ解析サービスVisionalistで利用していたドメイン（tracer[.]jp）の脅威分析と注意喚起 - 本当にあったドロップキャッチの怖い話 〜Visionalistの場合〜 （InternetWeek 2022） - サイバー脅威インテリジェンス（CTI）配信はじめました - インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜 41.Webアプリケーションソフトウェアエンジニアとして、コミュニケーションサービスの新機能開発 C - NeWork 先端研究開発（ネットワーク・デバイス） ポスト 受入 参考 42.5Gデバイス観点から5G NW運用を解明する無線通信スペシャリスト D 43.人間拡張技術を用いた体験共有に関する評価 D - 離れていても触れられる。「フィールテック™」が未来のコミュニケーションを変える。 - 6Gの時代に向けて挑む、「スキルをダウンロードする」技術とは。 44.6Gユースケース、要求条件、要素技術検討 D - ドコモの標準化への取組み 45.HAPS実用化に向けた技術検討 D - 世界初、成層圏下層から38GHz帯の電波伝搬実験に成功 - エアバス、NTT、ドコモ、スカパーJSATの4社がHAPSの早期実用化に向けた研究開発などの推進を検討する覚書を締結 - 未来を考える研究開発で、“世界のあたりまえ”を変える 46.携帯電話基地局などからの電波の測定技術検討 D - ドコモの電波の安全性に関する取組み - （お知らせ）国内初、マンホール型基地局の試作機を開発 - モバイル基地局環境における電波強度評価法 47.All Photonics Networkのための次世代光伝送ネットワークインフラおよびサービス開発エンジニア C 48.エンタープライズ向け大規模クラウドサービスを支えるネットワーク開発 C - OpenTech Lunch: クラウドの作り方(使い方じゃないよ) - EVPN Anycast Gateway を商用導入した話 - JANOG: エンタープライズ向けクラウドのSDN基盤の安定化への挑戦 - CNTOM: NFVサービスの 試験自動化とCI/CD 49.5G・IoTおよびIOWNを支えるNW基盤開発エンジニア C 50.ローカル5G無線(RAN), コア(5GC), トランスポートネットワーク(TN)の技術検証 C - Interop Tokyo 2022 〜400G-ZRを用いたイーサネット回線とローカル5G検証・展示のご紹介〜 リーガル ポスト 受入 参考 51.企業経営を支える法務業務 D/C