はじめに 「This Month in AWS Observability」最新号へようこそ。今回は、この6月に Amazon CloudWatch と AI 駆動型オペレーション全般で発表された新機能をご紹介します。CloudWatch でネイティブな OpenTelemetry メトリクスと PromQL クエリが一般提供（GA）となり、より深い統計・構造化分析のための 23 個の新しい Logs Insights コマンドがローンチされ、CloudWatch RUM に Session Replay が登場し、 AWS DevOps Agent では MCP および Agent-to-Agent プロトコルをサポートするカスタム SRE エージェントがリリースされました。EKS クラスター全体で GPU コストを配賦する場合も、実際のセッション再生でフロントエンドの問題をデバッグする場合も、チームのランブックを自律型 SRE エージェントに組み込む場合も、役立つ情報が見つかるはずです。これらの新機能のデモをご覧になりたい方は、8月11日開催のウェビナー「 I Didn’t Know Amazon CloudWatch Could Do That 」にご登録ください。 OpenTelemetry と Prometheus Amazon CloudWatch は、ネイティブ OpenTelemetry メトリクスと PromQL クエリの一般提供という大きなマイルストーンに到達しました。また、Amazon Managed Service for Prometheus には、高カーディナリティなワークロードのコストと複雑さを削減する機能が追加されました。 ネイティブ OpenTelemetry メトリクスと PromQL クエリ（GA）  Amazon CloudWatch が OpenTelemetry メトリクスをネイティブにサポートし、一般提供が開始されました。チームは OpenTelemetry Protocol（OTLP）経由でメトリクスを直接送信し、Prometheus Query Language（PromQL）でクエリできます。料金は GB あたりの取り込み課金で、15 か月分のストレージが含まれます。これにより、CloudWatch と並行して別途 Prometheus 互換バックエンドを用意する必要がなくなります。数十のラベル（namespace、pod、container、node、deployment）を持つ高カーディナリティメトリクスが CloudWatch に直接流れ込み、チームがすでに慣れ親しんだ PromQL 構文で即座にクエリ可能になります。 CloudWatch Pipelines が OpenTelemetry メトリクスの処理とエンリッチメントをサポート  CloudWatch Pipelines により、カスタムインフラストラクチャやアプリケーション計装の変更なしに、取り込み時に OpenTelemetry メトリクスの処理とエンリッチメントが可能になりました。例えば、ビジネスコンテキストの追加、高カーディナリティラベルの除去、命名規則の強制などが行えます。 Amazon Managed Service for Prometheus のネイティブヒストグラムサポート  ネイティブヒストグラムは、バケット境界ごとに 1 つの時系列を出力する従来の Prometheus ヒストグラムを置き換えるものです。20 個以上のバケット境界を事前定義してメトリクスごとに 20 以上の時系列分のコストを支払う代わりに、ネイティブヒストグラムは分布全体を動的な解像度を持つ単一の時系列に格納します。これにより、レイテンシー、リクエスト時間、値の分布の追跡において正確なパーセンタイル計算を維持しながら、ストレージコストとカーディナリティを削減できます。 OTel と Managed Prometheus による GPU コスト配賦  Amazon Elastic Kubernetes Service 上で AI/ML ワークロードをスケールさせるチーム向けに、OpenTelemetry コレクター、Amazon Managed Service for Prometheus、Amazon Managed Grafana を使用した GPU コスト配賦の新しいリファレンスアーキテクチャが公開されました。namespace、チーム、ワークロードタイプごとに GPU コストを配賦でき、「共有クラスターで最も高価なコンピューティングリソースを消費しているのは誰か」という問いに答えられます。 CloudWatch と OpenTelemetry による Claude Code 利用状況の分析  Claude Code のような AI コーディングエージェントがエンジニアリング組織全体に広がる中、トークン消費量、チームごとのコスト、開発者の生産性の追跡が重要になっています。このパターンでは、CloudWatch OTLP エンドポイントを使用して Claude Code セッションからカスタム OpenTelemetry メトリクスを取り込み、既存ツールでは答えられない問い（どのチームが最も多くのトークンを消費しているか、開発者あたりのコストはいくらか、AI 支援開発が最も価値を発揮しているのはどこか）に答えるダッシュボードを実現します。 ログ分析の進化 Amazon CloudWatch Logs の新しいクエリ・取り込み機能により、ログデータの大規模な分析・検索・ルーティングが容易になります。 23 個の新しい CloudWatch Logs Insights クエリコマンド  CloudWatch Logs Insights に、複数カテゴリにわたる 23 個の新しいクエリコマンドが追加されました。 パースコマンド: 多様なログ形式からの構造化抽出のための parse_json、parse_kv、parse_csv、parse_xml 分析関数: より深い統計分析のための median、percentile_cont、mode、variance、stddev ハッシュ・IP 関数: セキュリティおよびネットワーク調査ワークフローのための md5、sha256、ip_to_int、cidr_match 条件ロジック: より表現力豊かなクエリ構築のための case、coalesce、nullif、if これらの追加により、複雑な調査のためにログを外部分析プラットフォームへエクスポートする必要性が減少します。 Log Analytics 統合コンソール  新しい Log Analytics コンソールは、ロググループ横断のクエリ、自然言語によるログデータの探索、再利用可能なクエリパターンの保存を単一のインターフェースで提供します。従来は複数のコンソールページを行き来する必要があった作業が、単一のワークフローに統合されました。 タグベースのロググループクエリ 個々のロググループ名を指定する代わりに、タグでロググループをクエリできるようになりました。数百〜数千のロググループを持つ組織にとって、クエリのスコープ指定が簡素化されます。チーム、環境、サービス階層でロググループにタグ付けすることで、明示的なリストを維持することなく「決済チームの本番ログすべて」をクエリできます。 マネージド Syslog 取り込み  CloudWatch Logs が、VPC エンドポイント経由で TCP、TLS、UDP を使用したマネージド syslog 取り込みをサポートしました。RFC 5424、RFC 3164、および Cisco FTD や ASA を含むベンダー固有の形式に対応します。syslog メッセージは自動的に構造化フィールドにパースされ、手動での変換なしに Logs Insights で即座にクエリ可能になります。 Elastic Beanstalk ログ統合  AWS Elastic Beanstalk 環境が、ネイティブ統合によりアプリケーションログとプラットフォームログを CloudWatch Logs に直接ストリーミングできるようになりました。カスタムの .ebextensions 設定や、Beanstalk 管理インスタンス上のログストリーミングエージェントは不要です。 大規模なメトリクスとモニタリング 新しいクエリおよびメトリクス機能が拡張され、より大規模で複雑なマルチアカウントアーキテクチャを、より長い保持期間とより深いサービス固有の可視性でサポートします。 クロスアカウントメトリクスの一元化  CloudWatch が、簡素化された設定によるクロスアカウントメトリクスの一元的な収集をサポートしました。組織はモニタリングアカウントを指定し、メンバーアカウントからメトリクスを自動的に集約できます。アカウントごとの手動セットアップなしに、フリート全体のダッシュボードとアラームが実現します。 Metrics Insights の保持期間延長 CloudWatch Metrics Insights クエリが延長された保持期間をサポートし、より長い過去のウィンドウにわたる分析クエリを実行できるようになりました。これにより、外部分析システムへのデータエクスポートを必要とせず、CloudWatch 内で直接トレンド分析、キャパシティプランニング、前年比較が可能になります。 Amazon ElastiCache: 13 個の新しい CloudWatch メトリクス  Amazon ElastiCache が、メモリ断片化、接続チャーン、キー削除（Eviction）パターン、レプリケーションラグの詳細、コマンドレベルのレイテンシー分布をカバーする 13 個の新しい CloudWatch メトリクスを公開しました。これらのメトリクスは、従来は Redis や Memcached インスタンスに直接接続しないと観測できなかった、キャッシュ劣化の早期警告指標を見える化します。 エンドユーザーモニタリングと合成モニタリング 強化されたリアルユーザーの可視性と、より柔軟な合成テストトポロジーにより、モニタリングがエンドユーザーにさらに近づきます。 CloudWatch RUM Session Replay CloudWatch Real User Monitoring（RUM）に Session Replay が追加され、実際のユーザーセッションを発生した通りに記録・再生できるようになりました。顧客から報告された問題を調査する際、エンジニアはユーザーが体験したインタラクション、ページロード、エラー、レイテンシーの正確なシーケンスを見ることができ、フロントエンドデバッグから当て推量を排除します。 Synthetics マルチロケーション Canary  CloudWatch Synthetics に、単一の管理設定のもとで同じ合成テストを複数の AWS リージョンから同時に実行するマルチロケーション Canary が導入されました。各ロケーションは独立して動作します。あるロケーションが失敗を報告し、他が成功している場合、CloudWatch はシグナルを相関させて局所的な問題とグローバルな障害を区別し、誤検知によるアラームノイズを削減します。 AWS DevOps Agent によるインテリジェントオペレーション AWS DevOps Agent は、クラウド環境向けの AI 搭載オペレーションアシスタントとして進化を続けており、自動調査のインテリジェンスとリーチの両方を向上させる新機能が追加されました。 カスタム SRE エージェント  チーム固有の運用ランブックやインフラストラクチャパターンに合わせたカスタム SRE エージェントを構築できるようになりました。カスタムエージェントは、サービスアーキテクチャ、よくある障害モード、推奨される修復手順に関する組織の知見をエンコードし、繰り返し発生する問題の解決時間短縮を可能にします。 MCP および A2A プロトコルサポート  AWS DevOps Agent が Model Context Protocol（MCP）と Agent-to-Agent（A2A）通信をサポートしました。これにより、DevOps Agent はマルチエージェントアーキテクチャの中で他の AI エージェントとオーケストレーションし、外部ツールの呼び出し、ナレッジベースへのクエリ、組織の境界を越えた修復ワークフローの調整が可能になります。 Webhook トリガーと曖昧性解消カード  新しい Webhook ベースのトリガーにより、外部システム（PagerDuty、Datadog、カスタムアラートパイプライン）が DevOps Agent の調査を自動的に開始できるようになりました。調査中に曖昧さに遭遇した場合、曖昧性解消カード（disambiguation cards）が実行を停止させる代わりに構造化された選択肢をオペレーターに提示し、人間のガイダンスを得ながら調査ループを前進させ続けます。 5 つの新リージョンへの展開  AWS DevOps Agent がさらに 5 つの AWS リージョンで利用可能になり、広範なグローバルカバレッジを実現しました。ヨーロッパ、アジアパシフィック、および追加の北米リージョンで運用するチームは、調査をローカルで実行できるようになり、データレジデンシーの懸念を軽減し、リアルタイム運用ワークフローのレイテンシーを改善します。 開発者体験の改善 AWS DevOps Agent には、日常の運用ワークフローの摩擦を減らす、的を絞った QOL（quality-of-life）改善が加えられました。 リリース管理機能（プレビュー） DevOps Agent がリリース管理機能をプレビューとして提供開始しました。コード変更の本番投入準備状況をレビューし、標準からの逸脱、依存関係への影響、Well-Architected への準拠をチェックするとともに、テスト計画を自律的に生成・実行してデプロイ前にリグレッションを検出します。これにより、チームは AWS、マルチクラウド、オンプレミス環境全体で、より速いリリースと MTTR の削減を実現できます。 静的 IP サポート エージェントスペースにアウトバウンドトラフィック用の静的 IP アドレスを設定できるようになりました。IP ベースの許可リストを必要とする外部システム（オンプレミスの ITSM プラットフォーム、パートナー API、レガシーファイアウォール）との統合が可能になります。 自動拡張チャットと完全なコンテキスト保持  DevOps Agent の調査インターフェースに、自動的に広がるチャット入力欄と、調査セッションをまたいだ完全なコンテキスト保持が追加されました。より長く詳細なプロンプトが切り捨てられることなくサポートされ、以前の調査に戻ると会話履歴と調査結果が完全な状態で保持されています。 AWS Cloud Operations Blog の関連記事（2026年6月） 2026年5月〜6月に AWS Cloud Operations Blog で公開された記事は以下の通りです。 2026年6月 Log analysis with facets, correlation, enrichment, and automation in Amazon CloudWatch Log Analytics （6月19日）– Salman Ahmed, Ravi Kumar Amazon CloudWatch と OpenTelemetry による Claude Code 利用状況の分析 （6月17日）– Rodrigue Koffi, Gianluca Cacace, Vadim Omeltchenko GPU Cost Attribution in Amazon EKS Using Amazon Managed Service for Prometheus, Amazon Managed Grafana, and OpenTelemetry （6月12日）– Siva Guruvareddiar Introducing native histogram support in Amazon Managed Service for Prometheus （6月12日）– Vinod Kisanagaram, Priyanka Verma, Rohit Sharma まとめ 過去 2 か月間のオブザーバビリティ関連のローンチは、明確な方向性を示しています。AI 支援オペレーションはプロダクショングレードへの移行を続け、ログ分析は CloudWatch コンソールを離れることなくより強力になり、メトリクスはマルチアカウントのエンタープライズアーキテクチャに対応する規模へスケールし、モニタリングは合成テストとリアルユーザー体験の両レイヤーへさらに深く到達しています。 これらの機能を使い始めるには OpenTelemetry メトリクスを OTLP 経由で CloudWatch に直接送信 し、別途 Prometheus バックエンドなしで PromQL でクエリする 既存のロググループで新しい Logs Insights クエリコマンド を試す   CloudWatch RUM の Session Repla y を有効にして、ユーザーが体験していることを正確に確認する   マルチロケーション Canary を設定して、合成テストのカバレッジを向上させ誤報を削減する AWS DevOps Agent の  カスタムエージェント  を探索し、チームの運用ノウハウをエンコードする 最近のローンチの完全なリストは、Amazon CloudWatch でフィルタリングした AWS What’s New ページ をご覧ください。 さらに詳しく知りたい方へ 8月11日開催のウェビナー「 I Didn’t Know Amazon CloudWatch Could Do That 」に参加して、これらの新機能の実際の動作を確認し、トラブルシューティングの高速化に活用してください。 著者 Dot Ho Dot は AWS Observability 担当の Senior Technical Product Marketing Manager です。WCA 3×3 マルチブラインド（目隠し複数ルービックキューブ）ソルブの記録向上に向けて練習中です。 Joe Alioto Joe は AWS の Cloud Operations 担当の Worldwide Senior Specialist Solutions Architect で、オブザーバビリティ、AI 駆動のオペレーション、集中型オペレーション管理を専門としています。20年以上のオペレーションエンジニアリング経験を持ち、直近2年間は AI と AIOps に注力しています。彼は、アプリケーションパフォーマンス、インフラメトリクス、データベースワークロードを結びつけるインテリジェントなオブザーバビリティ戦略の構築を支援しており、AI エージェントと自動化を活用して平均解決時間 (MTTR) を短縮し、オペレーションチームの大規模な働き方を変革することにますます取り組んでいます。 本ブログは 2026 年 7 月 15 日に公開された This Month in AWS Observability: June 2026 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

みなさん､こんにちは｡ソリューションアーキテクトの杉山です｡今週も 週刊AWS をお届けします｡ 先週の木曜日､金曜日に AWS Summit Japan 2026 を開催しました｡台風が近づいていた中ではありましたが､多くのお客様にご来場いただきました｡ブースでたくさんのご相談を頂きましたが､AI 活用でどのような利便性があるのか､また､どういった仕組みでガバナンスを担保できるのか､という観点で質問を頂きました｡AWS Summit のセッションは､ オンデマンド視聴 が開始されています｡当日視聴が難しかった方も､キーノート､AWS セッション､お客様事例などをぜひご覧いただき次の一歩につながるヒントを得ていただければ幸いです｡ それでは､先週の主なアップデートについて振り返っていきましょう｡ 2026年6月22日週の主要なアップデート 6/22(月) Amazon Connect Customer が Agentic CX designer (NLX) のプレビュー版を提供開始 Amazon Connect Customer は､AI を活用したセルフサービス体験を設計・展開するためのノーコードキャンバス「Agentic CX designer (NLX)」のプレビュー版を提供開始しました｡ビジネスチームがコードを書かずに､エージェント型 AI と､本人確認や決済処理などの正確なアクションが求められるフローを組み合わせた音声・デジタル体験を構築できます｡また､通話中に顧客の Web/モバイルアプリをリアルタイムで操作できる Live Sync 機能も同時にプレビュー提供されます｡例えば､AI エージェントとホテル予約を通話している中で､会話内容に基づいて画面が同期して移動し､ホテルの予約を自動的に行うことがやりやすくなる仕組みです｡なお、プレビュー期間中は、ご自身のユースケースに合わせて精度などを検証いただくことが可能です｡ AWS Network Firewall がデフォルト drop action を更新し接続信頼性を改善 AWS Network Firewall は､新規作成するすべてのファイアウォールポリシーで､stateful action のデフォルトを “Application drop established (bidirectional)” から “Application drop established (server-directed only)” に変更しました｡この変更により､TCP window updates､keep-alives､resets などの正当なサーバーからクライアントへの TCP 制御パケットが誤ってドロップされることがなくなり､診断が困難だった断続的な接続障害を回避できます｡既存のポリシーには影響がなく､新規ポリシー作成時に自動的に適用されます｡ AWS Lambda MicroVMs で分離実行環境を提供開始 AWS Lambda MicroVMs を発表しました｡これはユーザーや AI が生成したコードを安全に実行するためのサーバーレスコンピューティング環境です｡VM レベルの分離､ほぼ瞬時の起動と再開速度､最大 8 時間の状態保存機能を提供します｡米国東部 (バージニア､オハイオ)､米国西部 (オレゴン)､アジアパシフィック (東京)､欧州 (アイルランド) で利用可能です｡従来の Lambda 関数がリクエストに応じて自動的にスケールするのに対し､MicroVMs は run-microvm API を呼んだ回数だけ MicroVM が 1 個ずつ起動し､各 MicroVM に専用の HTTPS エンドポイントが割り当てられます｡この「1 エンドポイント＝1 台」という特性を活かせば､ユーザーやセッションごとに独立した実行環境を割り当て､起動・サスペンド・終了のライフサイクルをアプリケーション側で自在に制御できるため､AI エージェントのコード実行サンドボックスやインタラクティブな開発環境のように「状態を保ったまま長時間使い続ける」ユースケースにうまくフィットします｡一方で従来の Lambda 関数は短時間・ステートレスなリクエストを大量にさばく用途に強いので､ワークロードの性質に応じて両者を使い分けるのがおすすめです｡なお､クォータは同時実行数ではなくアカウント・リージョンあたりの合計メモリ量で管理され､run-microvm API のレート制限はデフォルトで 5 TPS（バースト 5）です｡多数の環境を一度に立ち上げたい場合は､あらかじめサスペンド状態でプレウォームしておくと安定して払い出せます｡これらのクォータは Service Quotas コンソールから上限緩和を申請できます｡ 6/23(火) Claude Tag が AWS Marketplace の Claude Enterprise でベータ版として利用可能に Anthropic は､Claude Tag のベータ版を AWS Marketplace 経由で Claude Enterprise を利用する顧客向けに提供開始しました｡Claude Tag は､Slack チャネル内で @Claude とタグ付けすることで､チームメンバーが Claude にタスクを委任できる新機能です｡チャネルごとにアクセス権限と予算を設定でき､Claude は接続されたチャネルの文脈を記憶しながら､ツールやデータ､コードベースにアクセスできます｡管理者は Claude 管理コンソールで約 1 時間でエージェント ID をプロビジョニングし､チャネルごとにスコープを設定します｡ Amazon GuardDuty AI-powered investigations で脅威対応を加速 (Preview) Amazon GuardDuty に AI-powered investigations 機能 (Preview) が追加されました｡この機能は GuardDuty の findings とアカウントを自動的に分析し､真の脅威と誤検知を数分で見分けることができます｡過去 90 日間の関連アクティビティ､影響を受けるリソース､脅威インテリジェンスを knowledge graph を使って分析します｡これまで､GuardDuty の findings を手動で調査するには時間がかかり､アラート疲れ (alert fatigue) の原因となっていました｡AI-powered investigations により､数分で自動分析が完了します｡また､CLI コマンドを含む具体的な修復手順を提供してくれるため､対応のアクションが素早くなります｡ Amazon CloudWatch Logs がマネージド syslog 取り込みに対応 Amazon CloudWatch Logs が VPC エンドポイント経由での syslog 直接取り込みに対応しました｡ファイアウォール､ルーター､スイッチ､Linux サーバーからエージェントをインストールせずに syslog メッセージを CloudWatch Logs へ送信できます｡RFC 5424､RFC 3164､Cisco FTD/ASA の各フォーマットに対応し､facility､severity､hostname､appName などの構造化フィールドを自動的に抽出します｡PrivateLink に対応していて､Direct Connect や Site-to-Site VPN の Private 通信も可能となっています｡ 6/24(水) Amazon CloudWatch でダッシュボードのタグ機能をサポート Amazon CloudWatch がダッシュボードのタグ機能をサポートしました｡これにより､ダッシュボードをチーム､プロジェクト､環境などのカテゴリで整理し､タグベースでアクセス制御を実装できます｡PutDashboard API が Tags パラメータに対応したほか､TagResource､UntagResource､ListTagsForResource API がダッシュボード ARN をサポートし､1つのダッシュボードに最大50個のタグを設定できます｡CloudFormation と AWS Resource Explorer にも対応しており､追加コストなしで CloudWatch が利用可能な全リージョンで提供されます｡ Amazon Route 53 Global Resolver が AWS アカウント間での DNS View 共有をサポート Amazon Route 53 Global Resolver が､AWS Resource Access Manager (AWS RAM) を使用して DNS View を他の AWS アカウントと共有できるようになりました｡Route 53 Global Resolver は､リモート拠点やオンプレミス環境から AWS 上の Private Hosted Zone とパブリックドメインの両方を解決できる､インターネット到達可能な DNS リゾルバーです｡この機能により､consumer アカウントは自身の Route 53 Private Hosted Zone を共有された DNS View に関連付けることで､所有権を移譲せずに owner の Global Resolver を通じて全 AWS リージョンで名前解決できます｡DNS View 共有は追加料金なしで､Route 53 Global Resolver がサポートされている全リージョンで利用できます｡ AWS IoT Device SDK for Swift の一般提供開始 AWS IoT Device SDK for Swift が一般提供 (GA) を開始しました｡Swift 開発者は macOS 12+､iOS 16+､tvOS 16+､Linux 上で AWS IoT サービスを利用した IoT アプリケーションをネイティブに構築できるようになります｡SDK は MQTT 5 プロトコルをサポートし､AWS IoT Device Shadow､Jobs､Fleet Provisioning の統合クライアントを提供します｡iOS と tvOS では TLS 1.3 に対応しており､最新のセキュリティ標準でデータを保護します｡Swift Package Manager 経由でインストールできます｡ Amazon EC2､AMI ガバナンス強化のための AMI Watermarks 機能を発表 Amazon EC2 が AMI Watermarks 機能を発表しました｡この機能により､Private AMI にカスタム識別子を埋め込み､AMI の系譜追跡とガバナンスポリシーの実施が可能になります｡ウォーターマークは AMI のコピーや派生 AMI 作成時に自動的に引き継がれ､リージョン間コピーやアカウント共有でも保持されます｡Allowed AMIs 機能と組み合わせることで､承認されたウォーターマークを持つ AMI のみからインスタンスを起動するよう制限できます｡全 AWS リージョンで追加料金なしで利用可能です｡ 6/25(木) AWS Network Firewall が VisionHeight のマネージド脅威インテリジェンスルールをサポート AWS Network Firewall が VisionHeight 社の 2 つの新しいマネージドルールグループをサポートしました｡AWS Marketplace 経由で利用できる Zero-Day Threat Protection と Noisy Scanners and Tor Protection により､公開ブロックリストに掲載される数週間前に悪意ある IP インフラストラクチャを先制ブロックし､Tor 出口ノードや高頻度スキャンソースからの通信を遮断してファイアウォールログのノイズを削減します｡VisionHeight の Pulse テレメトリーに基づく独自の脅威インテリジェンスを活用でき､日次更新により最新の脅威情報を反映します｡ それでは､また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

はじめに NTTフィールドテクノの荒川 瑞斗です。 本記事では、コンテナネットワーク検証ツール「Containerlab」と、高機能なOSSソフトウェアルータである「freeRouter」を組み合わせて、「Inter-AS OptionC」という高度なネットワーク構成を構築しました。 本記事の結論と得られた知見 商用NOSのライセンス費用をかけず、Containerlab x freeRouter で複雑なSR-MPLS環境であるInter-AS OptionCの再現が出来ました。 「グローバルルーティングテーブルを持たない」といったfreeRouter特有の設計思想への理解が、構築の鍵となりました。 高度なSR-MPLS機能をOSSであるfreeRouterがサポートしている点は、Cisco IOS XRに匹敵する検証能力を備えていることを示しています。 ※ 本記事は2025年6月の構築当時の情報に基づきつつ、一部2026年4月時点の最新状況を追記しています 対象読者 本記事が想定する対象読者は以下の通りです。 Containerlabを用いたネットワーク検証に興味がある人 仮想環境でネットワークを構築して検証したいが、予算を抑えたいと考えている人 freeRouter（RAREプロジェクト）の独自の設計思想や仕様について知りたい人 SR-MPLSの基礎知識がある人 目次 はじめに 対象読者 目次 1. 背景・目的 2. freeRouterの特徴・仕様 Cisco IOS XR と freeRouter の確認コマンドを比較 Cisco IOS XR と freeRouter のコンフィグを比較 比較した結果 ルーティングテーブルの仕様と独自の解釈 3. Inter-AS OptionC 概要 4. 実装・検証内容 前提条件・動作環境 システム構成 設計方針／設計ポイント ネットワーク設計 5. 工夫点と注意点 デプロイ（起動）時にコンフィグが反映されない事象 SR-MPLS網の隠蔽（ハイド） 6. 動作確認 疎通が安定しているか (VPC間のping) 網内（AS内）リンク障害 AS間（Inter-AS）直結リンク障害 結果 7.最後に 今後の課題 執筆者 参考資料・出典 商標 免責事項 1. 背景・目的 複雑なトポロジを持つネットワークの保守運用を想定し、その事前検証が可能な環境を構築する機会がありました。 検証環境を構築するにあたり、コンテナベースで動作し、ホストOS（依頼主の環境）に依存せず動作する「 Containerlab 」に着目しました。 一方で、商用NOSはライセンス費用が高額な上、Containerlab上で動作するコンテナイメージとして用意することは至難の業です。 そこでOSS NOSの活用を検討しました。 VyOSやFRRouting、SONiCなども候補に挙がりましたが、今回の要件である高度なSR-MPLS機能の柔軟性、そして何より「 Cisco IOS XRに近いCLI体系 」を重視した結果、 freeRouter が最適解であると判断しました。 本記事に登場する主なネットワーク用語 NOS (Network Operating System)： ルーターやスイッチなどのネットワーク機器を動かす専用のOS。 PE (Provider Edge) / P (Provider)： 網の端に位置するルータ（PE）と、中心部で中継を担うルータ（P）。 ASBR (Autonomous System Boundary Router)： 異なるASを接続する境界ルータ。 RR (Route Reflector)： BGPの経路情報を効率的に配布する役割を持つルータ。 SR-MPLS / SID / SRGB： セグメントルーティング技術。各ノードを識別するID（SID）や、そのラベル範囲（SRGB）を使用します。 AFI / SAFI： BGPで扱う「どのアドレス体系（IPv4等）」と「経路の用途（ユニキャスト、マルチキャスト、ラベル付きなど）」を指す定義。 ECMP / BFD： 複数経路を同時に使う技術（ECMP）。 2. freeRouterの特徴・仕様 Cisco IOS XR と freeRouter の確認コマンドを比較 以下に主要なコマンド比較の例を抜粋します。 項目 Cisco IOS XR (例) freeRouter (相当) ルーティング確認 show route vrf A show ipv4 route A Ping確認 ping vrf A 172.16.100.1 ping 172.16.100.1 vrf A OSPFネイバー確認 show ospf neighbor show ipv4 ospf 10 neighbor Cisco IOS XR と freeRouter のコンフィグを比較 Segment Routing Global Block (SRGB) Cisco IOS XRでは segment-routing 配下でグローバルブロックを定義しますが、freeRouterではOSPFプロセス内でベースと範囲を定義します。 ! Cisco IOS XR segment-routing global-block 16000 275999 ! router ospf 100 segment-routing mpls segment-routing sr-prefer area 0 mpls traffic-eng interface Loopback1 prefix-sid index 16001 ! ! ! ! freeRouter (相当) router ospf4 10 vrf DEF_SEGROUT router-id 172.16.100.100 traffeng-id 0.0.0.0 segrout 500 base 12000 ! SRGBの定義 area 0 enable area 0 spf-ecmp area 0 segrout ecmp exit ! interface loopback1 vrf forwarding DEF_SEGROUT ipv4 address 172.16.100.100 255.255.255.255 router ospf4 10 enable router ospf4 10 area 0 router ospf4 10 passive router ospf4 10 segrout index 100 ! Indexの指定 router ospf4 10 segrout node no shutdown log-link-change exit ! Route Policy (RPL) 複雑な優先度制御（MEDやLocal Preferenceの打ち分け）についても、freeRouterの route-policy 構文を用いることが可能です。 具体的には、Cisco IOS XRの prefix-set を prefix-list に変換し、 sequence 管理下の elsif 構文にマッピングすることで、同等の経路選択ロジックを実現しています。 ! Cisco IOS XR prefix-set L3vpnGW-1 172.16.200.100/32 end-set ! prefix-set L3vpnGW-2 172.16.200.200/32 end-set ! route-policy L3vpnGW-POLICY if destination in L3vpnGW-1 or destination in L3vpnGW-2 then pass elseif next-hop in L3vpnGW-1 then set med 100 elseif next-hop in L3vpnGW-2 then set med 300 else pass endif end-policy ! ! freeRouter (相当) prefix-list A-ROUTE sequence 10 permit 172.16.200.100/32 ge 32 le 32 sequence 20 permit 10.50.80.4/30 ge 30 le 30 sequence 30 permit 172.16.200.1/32 ge 32 le 32 sequence 40 permit 10.200.135.0/30 ge 30 le 30 sequence 50 permit 10.200.135.4/30 ge 30 le 30 exit ! prefix-list B-ROUTE sequence 10 permit 172.16.200.200/32 ge 32 le 32 sequence 20 permit 10.50.81.4/30 ge 30 le 30 sequence 30 permit 172.16.200.2/32 ge 32 le 32 sequence 40 permit 10.200.136.0/30 ge 30 le 30 sequence 50 permit 10.200.136.4/30 ge 30 le 30 exit ! route-policy PE-UL-ROUTE sequence 10 if prefix-list A-ROUTE sequence 20 set locpref 1400 sequence 30 pass sequence 40 elsif prefix-list B-ROUTE sequence 50 set locpref 1000 sequence 60 pass sequence 70 else sequence 80 pass sequence 90 enif exit ! 比較した結果 このように、Cisco IOS XRとfreeRouterとのコンフィグ差分をマッピングし、相当コマンドの存在を確認しました。 互換性維持の判断基準をクリアしたため、freeRouterにて設計を進めました。 freeRouterでは、VRFやプロセスを明示的に指定して情報を取得する体系となっています。 調査を続けていく中で、ルーティングテーブルに関して、とても興味深い知見が得られました。 ルーティングテーブルの仕様と独自の解釈 freeRouterはグローバルルーティングテーブルを持ちません。 この独特な仕様は非常に苦労させられました。 ここで、公式の説明（引用）と、 検証から得た独自の考察 を整理して解説します。 公式の設計思想（引用） no global routing table: every routed interface must be in a virtual routing table In FreeRouter everything is in a VRF (so there is no global VRF) This design choice has very positive consequences like: No VRF awareness questions,have multiple bgp processes for the same freeRouter instance (each bound to a different VRF) 検証から得た独自考察と所感 「グローバルルーティングテーブル」が存在しない 全てのインターフェースは何らかのVRFに属している必要があります。 VRF分離の課題 現状、VRF間をルーティングさせてもRT（Route Target）値が期待通りに機能しないケースが見受けられました。 BGPプロセスの多重化 1つのBGPプロセスが1つのVRFに固定されるため、ユーザ（テナント）を物理的に分けるには、BGPプロセスそのものを分ける必要があるという結論に達しました。 3. Inter-AS OptionC 概要 Cisco社が提示している内容を確認します。 ・Route Reflectors exchange VPNv4 routes ・ASBRs Exchange PE loopbacks (IPv4) with labels as these are BGP NH addresses ・Eliminates LFIB duplication at ASBRs. ASBRs don’t hold VPNv4 prefix/label info. ・Two Options for Label Distribution for BGP NH Addresses for PEs in each domain: 　1. BGP IPv4 + Labels (RFC3107) – most preferred & recommended 　2. IGP + LDP ・BGP exchange Label Advertisement Capability - Enables end-end LSP Paths ・Subsequent Address Family Identifier (SAFI value 4) field is used to indicate that the NLRI contains a label ・Disable Next-hop-self on eBGP RRs (peers) 私は、以下の解釈をしました。 VPNルートの伝送 RR (Route Reflector) が AS間のVPNv4 ルート交換を行います。 ASBRはVPNv4のパス情報やラベル（LFIB）を保持することはしません。 エンドツーエンドLSPの確立 異なるASにあるPE間で通信するため、PEのループバックアドレスをラベル付きで共有します。 RFC 3107 (SAFI 4) に基づき、IPv4プレフィックスにラベルを付与して広告するBGP-LUを推奨します。 BGPのCapabilityを利用してラベルをやり取りし、ASを跨いだ一気通貫のラベルスイッチパス（LSP）を形成します。 ルーティングの制御 eBGP RR間でルートを交換する際、ネクストホップを自分自身（RR）に書き換えないように設定します。 4. 実装・検証内容 前提条件・動作環境 本記事の検証環境は以下の通りです。 ホストOS： Linux環境（Containerlabが動作する環境） ネットワークOS： freeRouter（RAREプロジェクト） ※ 使用したバージョンは、v24.3.30-cur, done by sprscc13@mrn0b0dy. クライアントOS： Alpine Linux ツール： Containerlab, Docker 検証時点： 2025年6月 システム構成 本検証では、AS65000とAS64512の2つの自律システム（AS）を跨ぐ構成を構築しました。 合計14台のコンテナを使用し、各ASにはPE、P、ASBR（ ASBR兼Route Reflector ）を配置しています。 表記について freeRouterのコマンド体系に基づいて記載している個所があります。 以下の読み替えをお願いします。 「 labeled 」と「labeled-unicast」 ： 一般的なBGP用語（BGP-LU）では、 labeled-unicast です。 設計方針／設計ポイント 前述のInter-AS OptionCを実現するため、以下のポイントに基づき構築を行いました。 ASBR間でのラベル交換: ASBRがlabeledルートを交換します。 Next-hopの管理: PEのIPv4 LoopbackアドレスをBGP next hopとしてラベル交換を行います。 ラベル配布: 各ドメインのPEに対して、OSPFによるSR-MPLS（Segment Routing）を使用します。 再配布の活用: Loopbackアドレスのリーチビリティ（到達性）は別プロセスのOSPFで広告し、BGPに再配布させます。 ネットワーク設計 内部リンク、およびAS間には特定のセグメントを割り当て、OSPFプロセスをAS内（プロセス10）とAS外（プロセス20）で分離しました 。 AS間にて、Loopback到達性を確保するため、各ASBRに別プロセスのOSPF（プロセス20）を動作させています。 一部、設定値を掲載します。 基本パラメータ 項目 設定内容 VRF定義 DEF_SEGROUT OSPFプロセス番号 AS内: 10 / AS外: 20 SRGB (segrout 500 base 12000) 12000 ～ 12499 AS番号 eなし装置: 65000 / eあり装置: 64512 OSPF コスト値一覧 該当箇所 コスト値 PE-P 2000 P-ASBR, ePE-eASBR 700 ASBR-ASBR, eASBR-eASBR (process 10) 1300 ASBR-ASBR, eASBR-eASBR (process 20) 900 ASBR-eASBR 3000 IPアドレス / サブネット範囲 区分 プレフィックス サブネットマスク 最大ノード数 範囲 OSPF 10 (AS 65000) /20 255.255.240.0 4096 10.100.128.0 ～ 10.100.143.255 OSPF 10 (AS 64512) /20 255.255.240.0 4096 10.200.128.0 ～ 10.200.143.255 OSPF 20 /28 255.255.255.240 16 10.10.186.0 ～ 10.10.186.15 CE (VPC1_1, VPC1_2) /29 255.255.255.248 8 10.50.80.0 ～ 10.50.80.7 CE (VPC2_1, VPC2_2) /29 255.255.255.248 8 10.50.81.0 ～ 10.50.81.7 Lo1 (AS 65000) /24 255.255.255.0 256 172.16.100.0 ～ 172.16.100.255 Lo2 (AS 64512) /24 255.255.255.0 256 172.16.200.0 ～ 172.16.200.255 実際のコンフィグ freeRouterでの物理インターフェースや論理インタフェースと、今回の肝であるOSPF, labeledのコンフィグを紹介します。 ! ASBR1のコンフィグ ! 物理インタフェース interface ethernet5 description [B1]eASBR1_eth5 cdp enable bundle-group 1 no shutdown log-link-change exit ! ! 論理インタフェース interface bundle1 description eASBR1 vrf forwarding DEF_SEGROUT ipv4 address 10.10.186.1 255.255.255.252 mpls enable router ospf4 20 enable router ospf4 20 area 0 router ospf4 20 cost 3000 no shutdown log-link-change exit ! ! OSPFとSegment Routing router ospf4 20 vrf DEF_SEGROUT router-id 192.18.1.1 traffeng-id 0.0.0.0 segrout 500 base 10000 area 0 enable area 0 segrout exit ! ! Loopbackインタフェースへの適用 interface loopback2 vrf forwarding DEF_SEGROUT ipv4 address 192.18.1.1 255.255.255.255 router ospf4 20 enable router ospf4 20 area 0 router ospf4 20 passive router ospf4 20 segrout index 20 router ospf4 20 segrout node no shutdown log-link-change exit ! ! BGP-LU router bgp4 65000 vrf DEF_SEGROUT local-as 65000 router-id 172.16.100.100 address-family labeled vpnuni ! template RRC-LU remote-as 65000 template RRC-LU local-as 65000 template RRC-LU address-family labeled vpnuni template RRC-LU distance 200 template RRC-LU additional-path-rx labeled vpnuni template RRC-LU additional-path-tx labeled vpnuni template RRC-LU update-source loopback1 template RRC-LU segrout template RRC-LU route-reflector-client template RRC-LU next-hop-self ! template eBGP remote-as 64512 template eBGP local-as 65000 template eBGP address-family labeled vpnuni template eBGP distance 20 template eBGP ttl-security 3 template eBGP additional-path-rx labeled vpnuni template eBGP additional-path-tx labeled vpnuni template eBGP update-source loopback2 template eBGP segrout template eBGP route-policy-in PE-UL-ROUTE ! template eBGP-LU remote-as 64512 template eBGP-LU local-as 65000 template eBGP-LU address-family labeled vpnuni template eBGP-LU distance 20 template eBGP-LU ttl-security 1 template eBGP-LU additional-path-rx labeled vpnuni template eBGP-LU additional-path-tx labeled vpnuni template eBGP-LU update-source loopback1 template eBGP-LU segrout template eBGP-LU next-hop-unchanged ! template iBGP-LU remote-as 65000 template iBGP-LU local-as 65000 template iBGP-LU address-family labeled vpnuni template iBGP-LU distance 200 template iBGP-LU additional-path-rx labeled vpnuni template iBGP-LU additional-path-tx labeled vpnuni template iBGP-LU update-source loopback1 template iBGP-LU segrout template iBGP-LU next-hop-self ! neighbor 192.18.5.5 template eBGP ! neighbor 172.16.100.1 template RRC-LU ! neighbor 172.16.100.2 template RRC-LU ! neighbor 172.16.100.200 template iBGP-LU ! neighbor 172.16.200.100 template eBGP-LU ! ! redistribute connected route-policy CON-TO-BGP exit ! 5. 工夫点と注意点 デプロイ（起動）時にコンフィグが反映されない事象 Containerlabの公式サイトにおけるfreeRouter（RARE）の解説では、以下のように説明されています。 参考： https://containerlab.dev/manual/kinds/rare-freertr/ User defined config It is possible to make RARE/freeRtr nodes to boot up with a user-defined config instead of a default one. In this case you'd have to create rtr-hw.txt and rtr-sw.txt files and bind mount them to the /rtr/run/conf dir: topology: nodes: rtr1: kind: rare image: ghcr.io/rare-freertr/freertr-containerlab:latest binds: - rtr-hw.txt:/rtr/run/conf/rtr-hw.txt - rtr-sw.txt:/rtr/run/conf/rtr-sw.txt しかしながら、これを記載してデプロイするとコンフィグが初期状態のままとなります。 freeRouterのDockerfileの仕様から全てを確認したところ、特定のファイルによって設定が上書きされる仕様であることが判明したため、該当ファイルを直接バインドマウントすることで解決しました。 topology: nodes: PE_A: kind: rare image: ghcr.io/rare-freertr/freertr-containerlab:main mgmt-ipv4: 172.31.0.2 binds: - startup_configuration/PE_A/rtr-sw.txt:/rtr/rtr-sw.txt ※ 2026年4月時点では、 /rtr/run/conf/ にバインドで動作するように修正されている ことを確認済みです。 SR-MPLS網の隠蔽（ハイド） Cisco IOS XRの mpls ip-ttl-propagate disable forwarded に相当するコマンドがfreeRouterには存在しません 。 そのため、PEルータのユーザ側インタフェースにアウトバウンドACLを適用し、SR-MPLS網内のホップが見えないよう工夫しました 。 mpls ip-ttl-propagate disable forwarded の機能概要 IPパケットのTTL（Time To Live）値をMPLSラベルのTTLへコピーする動作（伝搬）を無効化するために使用されます。 TTL伝搬の仕組み ルータやL3SWがIPパケットをラベルでカプセル化してSR-MPLS網に送り出す際、以下の動作が行われます。 １. IPヘッダのTTL値が、MPLSラベルのTTLフィールドにコピーされます。 ２. SR-MPLS網内の各ルータ（Pルータ）を通るたびに、ラベルのTTLが「1」ずつ減ります。 ３. SR-MPLS網を出る際、ラベルのTTL値がIPヘッダのTTLに戻されます。 最大の目的 外部ユーザから MPLSコアネットワークの内部構造を見えないようにする ことです。 実際にクライアントOS間のtracerouteをしたところ、以下の通り、網内の秘匿に成功しました。 / # traceroute 10.50.80.6 traceroute to 10.50.80.6 (10.50.80.6), 30 hops max, 46 byte packets 1 10.50.80.2 (10.50.80.2) 0.620 ms 0.868 ms 1.260 ms 2 * * * 3 * * * 4 * * * 5 10.50.80.6 (10.50.80.6) 2.772 ms 2.461 ms 1.841 ms 仕組みとしては、単純に 明示的な deny だけで隠蔽しています。 access-list custA_Filter sequence 10 permit all 10.50.80.0 255.255.255.248 all any all sequence 20 deny all any all any all exit ! tracerouteは、TTLが0になった時にルータが返す ICMP Time Exceeded (Type 11, Code 0) を受け取ることで経路を表示します。 上記のACLでは、最終的な宛先への通信は permit していますが、それ以外の通信（網内ルータからのICMPエラー通知など）を sequence 20 deny で叩き落としています。 まとめ 本構成では、SR-MPLS網内のPルータが返す ICMP Time Exceeded (Type 11, Code 0) を、PEルータの出口ACL（sequence 20 deny all any all any all）で意図的にドロップさせています。 通常の mpls ip-ttl-propagate disable が「TTLのコピーを止めることで、PルータでTTLを0にさせない（＝ICMPを発生させない）手法」であるのに対し、今回の手法は 「発生したICMP通知を境界で検閲・遮断する手法」 です。 これにより、外部からは網内のIPアドレスはおろか、ICMPエラーメッセージすら到達しないため、結果として * * *（タイムアウト）となり、ユーザ・トラフィックと網内管理情報の境界の明確化を実現しています。 6. 動作確認 通常時のルート (上り、下り共に同一ルート) Aルート: VPC1_1 ～ ASBR1 ～ eASBR1 ～ VPC1_2 Bルート: VPC2_1 ～ ASBR2 ～ eASBR2 ～ VPC2_2 ※ パケットロス計測は、VPC（Alpine Linux）間で デフォルトのping（1秒間隔、タイムアウト1秒） を実行し、ICMP Sequenceの抜けをカウントしたものです。 　 したがって、33 packetsのロスは約33秒間の通信断を意味します。 疎通が安定しているか (VPC間のping) 1日目 10000 packets loss 0% 2日目 10000 packets loss 0% 3日目 10000 packets loss 0% 4日目 10000 packets loss 0% 5日目 10000 packets loss 0% 網内（AS内）リンク障害 記載のないインタフェースはパケットロス無し。 検証の結果、リンクパススルー機能が無いため、OSPFのダウン検知に依存する箇所では数十パケット単位のロスが避けられないことが分かりました。 仮想環境ゆえに物理リンクの断が即座に伝播せず、BFD非対応の影響をこの段階で身をもって実感することになりました。 障害箇所 パケットロス（目安） 挙動・ルート変化 ログ・検知の特徴 PE_A (P2向け論理インタフェース) 約34 packets ・Aルートのみロス有 ・AS間ルート変化なし P2とのOSPFダウン検知 (対向で約36秒後) PE_B (P1向け論理インタフェース) 約33 packets ・Bルートのみロス有 ・AS間ルート変化なし P1とのOSPFダウン検知 (対向で約40秒後) P1 (両ASBR向け論理インタフェース) 0 ～ 40 packets ・送信側ならロス無 ・受信側ならOSPF検知までロス有 ASBR1/2とのOSPFダウンを検知 P2 (両ASBR向け論理インタフェース) 0 ～ 35 packets ・送信側ならロス無 ・受信側ならOSPF検知までロス有 ASBR1/2とのOSPFダウンを検知 AS間（Inter-AS）直結リンク障害 ASBR間のeBGP/OSPFリンクの障害です。 ここはInter-AS OptionCの核心部であり、冗長ルートへの切り替わりが発生します。 障害箇所 パケットロス（目安） 挙動・ルート変化 ログ・検知の特徴 ASBR1 (eASBR1向け論理インタフェース) 約33 packets ・AルートがASBR2経由へ迂回 eASBR1とのOSPFダウン後、eBGPもダウン ASBR2 (eASBR2向け論理インタフェース) 約39 packets ・BルートがASBR1経由へ迂回 eASBR2とのOSPFダウン後、eBGPもダウン eASBR1 (ASBR1向け論理インタフェース) 約37 packets ・AルートがeASBR2経由へ迂回 ASBR1とのOSPFダウン後、eBGPもダウン eASBR2 (ASBR2向け論理インタフェース) 約36 packets ・BルートがeASBR1経由へ迂回 ASBR2とのOSPFダウン後、eBGPもダウン 結果 インタフェースをダウンさせると対向装置から受け取る方向のトラフィックであった場合、OSPFネイバーダウンを検知後に切り替わるため、それまではパケットロスが発生しました。 インタフェースをダウンさせた側で送っているルートであった場合、ロス無く切り替わります。 上記二点より、freeRouterでのOSPFプロトコルのECMP仕様は、上り、下りで分けていることが判明しました。 トラフィック量に応じて、特定のトランジット経路へ動的に分散される挙動は見受けられませんでした。 AS間直結のリンク(B1)をダウンさせるとパケットロスが発生し、ルートの切り替わりが発生しました。 Lo1のeBGPはダウンし、Lo2で張ったeBGPのダウンは発生しないため想定通りです。 閉塞解除後は全てパケットロスは見受けられませんでした。 7.最後に freeRouterは非常に高機能ですが、その独特な設計思想や特有の挙動に苦労しました。 しかし、Inter-AS OptionC も含め、一つずつ紐解くことで、設計方針 / ポイント に基づいたSR-MPLS網を構築することが出来ます。 そして、ACLを設定したことにより、結果として、別ユーザからの通信もPEルータが検閲して通さないです。 今回、構築した環境は git clone https://github.com/MizutoArakawa/freeRTR_InterAS_OptionC.git で試すことが出来ます。 containerlab、Docker、freeRouterイメージが搭載されていることが前提とはなりますが、是非見てみてください。 また、freeRouterを使ってみて素晴らしいと感じましたら、開発者にビールを奢ってあげてください。 PE_A#show version freeRouter v24.3.30-cur, done by sprscc13@mrn0b0dy. place on the web: http://www.freertr.org/ license: http://creativecommons.org/licenses/by-sa/4.0/ the beer-ware,abandon-ware license for selected group of people: sprscc13@mrn0b0dy wrote these files. as long as you retain this notice you can do whatever you want with this stuff. if we meet some day, and you think this stuff is worth it, you can buy me a beer in return 2026年4月時点では、格言が追加されていました PE_A#show version freeRouter v26.4.28-cur, done by sprscc13@mrn0b0dy. place on the web: http://www.freertr.org/ license: http://creativecommons.org/licenses/by-sa/4.0/ the beer-ware license for selected group of people: sprscc13@mrn0b0dy wrote these files. as long as you retain this notice you can do whatever you want with this stuff. if we meet some day, and you think this stuff is worth it, you can buy me a beer in return quotes from devvies like sprscc13@mrn0b0dy: true random comes from weather forecasts and political announcements if a machine can learn the value of human life, maybe we can too be liberal in what you accept, and conservative in what you send rough consensus and running code, keep it stupid simple dont drive faster than your guardian angel can fly care about the bits and not the bits of the bits let bloom all the flowers, make the world better the great power comes great responsibility every tool could be used for good or bad do or not to do but dont try 今後の課題 私個人としては、どうしても「 RT（Route Target）による柔軟なVRF分離 」 でユーザ通信の分離を実現したいです。 その方が、 美しい と考えるからです。 とはいえ、freeRouterの設計理念が脳裏によぎります。 no global routing table: every routed interface must be in a virtual routing table freeRouterは1つのBGPプロセスに1つのVRFしか適用できませんし、そもそもグローバルルーティングテーブルを持ちません。 この点は、主流なNOSと大きく違う点です。 そのため、従来のVRFにおけるRT（Route Target）の概念をそのまま適用することには再考の余地があります。 如何に最適化されたコンフィグで再現が出来るか、今後も継続して検証を続けていきます。 更に、本構成内にL2VPNも含め、ユーザ通信を論理的に分離させることが可能か追加で取り組むことを検討しています。 EVPNへの拡張： L2VPN（E-LAN方式）を設定追加することで、同一装置にてL3VPNとL2VPNと論理的に分割が可能か実験。 経路最適化： コントローラを用いたPCEP連携による、遅延に基づいた最適経路の動的制御。 執筆者 荒川 瑞斗（NTTフィールドテクノ サービスマネジメント部所属） 現在は、監視・保守業務に従事している方のためのツール、及び搭載しているVMの維持、メンテナンスに携わっています。 好きなラックサーバはHPE ProLiant DL360 Generation 9（初めて自宅に迎え入れた子なため）です。 参考資料・出典 本記事を執筆するにあたり、以下のサイトを参考にしました。 Containerlab : https://containerlab.dev/ freeRouter : http://www.freertr.org/ freeRouter（GitHub） ： https://github.com/rare-freertr/freeRtr-containerlab Inter-AS OptionC : https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/200523-Configuration-and-Verification-of-Layer.html Inter-AS OptionC : https://nsrc.org/workshops/2015/apricot2015/raw-attachment/wiki/Track3MPLS/9-Apriot_2015_Inter-AS.2.pdf 商標 「Cisco、Cisco IOS、Cisco IOS XR」は、米国およびその他の国における Cisco Systems, Inc. の商標または登録商標です。 「Docker」は、Docker, Inc.の米国およびその他の国における商標または登録商標です。 「freeRouter」は、Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) および作者独自の「Beer-ware License」に基づき提供されています。 「HPE ProLiant」は、Hewlett Packard Enterprise Development LPの商標です。 その他、本記事に記載されている会社名、製品名は、各社の商標または登録商標です。 免責事項 本記事に掲載された手法を実施した結果発生する損失・損害については責任を負いかねます。 また、実際の通信事業用ネットワークを模擬する際、IPアドレスやホスト名、ポートコンベンション等は同じ、もしくは類似させるようなことはせず、推測されないような値にしてください。