みなさん､こんにちは｡ソリューションアーキテクトの杉山です｡今週も 週刊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アドレスやホスト名、ポートコンベンション等は同じ、もしくは類似させるようなことはせず、推測されないような値にしてください。

はじめに はじめまして。2025年9月に入社したshun-itoと申します。所属は基幹システムグループ インフラシステムチームです。担当業務はオフィス及びデータセンターのネットワークの設計・構築・運用・保守です。 趣味はバスケやボウリングなどで体を動かすことと、お酒（最近は特にクラフトビールと日本酒）を飲むためにお出かけすることです。 これまでの経歴と転職のきっかけ 前職では某事業会社（非IT系）の子会社に在籍しており、セキュリティ系システムのインフラ部分（ネットワーク、サーバ）の設計・構築を担当しておりました。 前職での私のポジションは顧客（親会社のシステム部）の要望のヒアリングや進捗報告、システム開発ベンダーへの依頼や進捗管理を担当しておりました。ですので、自分で手を動かしてシステムに触れる機会があまり無く、ステークホルダーとのコミュニケーションを取る時間が業務の大半を占めておりました。 私は自分の手でシステムに触れる方が性に合っていると感じ、ベンダーへ委託するよりも内製で業務を遂行する会社に転職したいと考えるようになりました。また、前職では運用・保守は担当していなかったので、より幅広い工程に携わりたいとも考えておりました。 業務を内製化していること・自身の技術領域（主にネットワーク）と一致していること・できるだけ幅広い工程に携われることの3点を軸として転職先の候補となる会社を調べていたところ、ニフティにたどり着きました。 ネットワークエンジニアとして当然ニフティは存じ上げており、転職活動の早い段階で候補に上がりました。他にも候補は何社かありましたが、他の会社と比較すると求められるスキルや経験が私の持つものと共通点が多く志向性が合いそうだと考えて応募し、幸いにも内定を頂くことができました。 入社して感じたこと 応募した職種は文字通り「ネットワークエンジニア」でしたので、概ね予想していた通りの業務内容ではありました。 しかし、一口に「ネットワークエンジニア」と言いましても、やはり会社によって採用している技術領域には僅かな違いがあります。先ほど「求められるスキルや経験が私の持つものと共通点が多かった」と申し上げましたが、僅かに違う技術領域の習得は必要になりましたので、慣れるまでの苦労はありました（ニフティに転職するまでは、CiscoやJuniperの機器を使用したオンプレのネットワークの経験しかなく、AWSやAzure等のパブリッククラウドを使用した経験がありませんでした） ただ、オンボーディングの内容が体系的にまとめられており、何をどの順番で習得していけばいいのかが分かりやすかったのが大きな助けになりました。 今後の目標・抱負 実は私は僭越ながらも「リードエンジニア候補」という枠で入社させていただきました。過去にもチームリーダーの経験（あまり自覚は無いですが周りからはそう見られていたようです）はありましたが、ニフティのリーダークラスの方々を見ていると、知識の広さや深さ、そして判断の速さに驚かされる機会も多いです。そういった方々が身近にいらっしゃることは大変心強いのですが、その一方で将来的には自身がそのような立ち位置に付いていることを期待されていると考えると「本当に自分で大丈夫かな・・・？」と不安になることもあります。 今後は技術や知識を身に着けていくことはもちろん、リーダーシップを発揮できるようなコミュニケーションスキルも身に着けていき、期待に応えられるようにリーダーとして活躍していきたいです。 最後に ここまで読んでいただきありがとうございました。 ニフティは提供サービスが多く、その分採用している技術領域の幅が広いので自分に合ったチームが見つかりやすい会社だと思います。 「自分の得意分野で活躍したい」という想いも「新しいことにチャレンジしたい」という想いも叶えられる環境があります。 少しでもニフティにご興味を持っていただけたのであれば、ぜひ応募していただき、カジュアル面談や面接でお話してみませんか？ 皆さんと一緒に働ける日をお待ちしております！