トップ > ネットワーク > 商用NOSに頼らない！Containerlab × freeRouterで構築するInter-AS OptionC検証環境

商用NOSに頼らない！Containerlab × freeRouterで構築するInter-AS OptionC検証環境

ネットワーク 検証レポート

はじめに

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. 背景・目的

複雑なトポロジを持つネットワークの保守運用を想定し、その事前検証が可能な環境を構築する機会がありました。
検証環境を構築するにあたり、コンテナベースで動作し、ホスト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を実現するため、以下のポイントに基づき構築を行いました。

  1. ASBR間でのラベル交換: ASBRがlabeledルートを交換します。
  2. Next-hopの管理: PEのIPv4 LoopbackアドレスをBGP next hopとしてラベル交換を行います。
  3. ラベル配布: 各ドメインのPEに対して、OSPFによるSR-MPLS（Segment Routing）を使用します。
  4. 再配布の活用: 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（初めて自宅に迎え入れた子なため）です。

参考資料・出典

本記事を執筆するにあたり、以下のサイトを参考にしました。

商標

  • 「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アドレスやホスト名、ポートコンベンション等は同じ、もしくは類似させるようなことはせず、推測されないような値にしてください。

© NTT WEST, Inc.