• はじめに
• 概要
• 検証構成
  • 対象イメージ
  • 検証環境
    • VMスペック
    • フルルートの生成
    • 検証トポロジー
• 測定方法
  • ① 起動時のリソース測定
  • ② フルルート学習時のリソース測定
  • ③ 学習完了後の安定時リソース測定
• テスト結果
  • Juniper vJunosSwitch
    • グラフから分かること
  • Juniper cJunosEvolved
    • グラフから分かること
  • Juniper vJunosRouter
    • グラフから分かること
  • Arista cEOS
    • グラフから分かること
  • Cisco XRv9000
    • グラフから分かること
  • Nokia SR Linux
  • VyOS1.5
    • グラフから分かること
• テスト結果からの一覧表
• さいごに

はじめに

こんにちは、ITインフラ本部インフラ部ネットワークグループ NRE（Network Reliability Engineering）チームの大橋です。
この記事では、Containerlab 上で各種ネットワークOS (以下、NOS) イメージを動作させた際に、フルルートを扱えるのか、そしてそのためにどれほどのリソースが必要なのかを検証した結果を紹介します。

概要

Containerlabで各 NOS イメージを動かす際、どの程度のCPU・メモリが必要なのか、特にフルルート（約107万のIPv4経路、約24万のIPv6経路）を扱えるのかは、ドキュメントだけでは判断しにくい部分があります。

本記事では、実際にリソース使用量をモニタリングしながら、以下の3点を検証しました。

1. 各OSイメージがフルルートを受信・学習できるか
2. フルルート学習時に必要なCPU・メモリの実測値
3. 学習完了後の安定稼働時のリソース使用量

これらの結果をもとに、検証環境やオンプレ環境でのサーバスペック選定の参考となる指標を提供します。

検証構成

対象イメージ

今回は下記7つのイメージで確認しました。

• Juniper vJunosSwitch
• Juniper vJunosEvolved
• Juniper vJunosRouter
• Arista cEOS
• Cisco XRv9000
• Nokia SR Linux
• VyOS1.5

※ Juniper vJunos 系や Cisco XRv9000 などの VM ベースの NOS は、vrnetlab を利用してコンテナイメージ化を行い、検証に使用しています。

検証環境

検証環境に設置しているサーバからVMを切り出して検証をしました。ハイパーバイザーはProxmoxを利用しています。

VMスペック

CPU : Intel Xeon Gold 6230 20コア割当
Memory : 256GB
Storage : SSD 500GB
OS : Ubuntu 24.04.3 LTS
Containerlab : v0.71.1

フルルートの生成

GoBGPから下記経路を広報
IPv4 : 約107万経路
IPv6 : 約24万経路

検証トポロジー

各 NOS コンテナは GoBGP と BGP ピアを張り、フルルートを受信する構成としました。

測定方法

今回の検証では、各 NOS のリソース使用状況を1秒間隔で収集しながら、以下の3つのフェーズで測定しました。

① 起動時のリソース測定

NOS を単体で起動し、起動完了までに必要なCPU・メモリと起動時間を測定します。

② フルルート学習時のリソース測定

GoBGPとBGPセッションを確立し、フルルート（IPv4約107万経路、IPv6約24万経路）を受信します。この際、以下を測定します。

• 学習中のCPU使用率とメモリ使用量
• フルルート学習完了までの時間
• 学習が完了するかどうか

③ 学習完了後の安定時リソース測定

フルルート学習完了後、アイドル状態で維持されるCPU使用率とメモリ使用量を測定します。

テスト結果

Juniper vJunosSwitch

Containerlab経由でvrnetlabを使用する場合、デフォルトでは内部のQEMUに対して4コア/5GBメモリが割り当てられますが、フルルート学習時にメモリ不足となったため、20GBに増やしました。
コンテナ自体のリソース制限はありません(最大約251GB)。
CPUは4コアのままとしています。

グラフから分かること

このグラフは、Juniper vJunosSwitch が起動してアイドルに入り、その後フルルートを受信したときの CPU とメモリの推移をまとめたものです。
0〜650 秒あたりまでは起動処理で、その区間を超えると初期処理がひと段落して CPU の揺れも落ち着きます。

その後、650〜2300 秒付近まではアイドル状態で、まだ経路を受け取っていないため CPU・メモリともに落ち着いています。
2300 秒付近からフルルートの受信が始まります。受信開始直後から CPU 使用率が一気に上がり、経路取り込みや内部テーブル構築が動き出しているのが分かります。
vJunosSwitch でもフルルート自体の受信は進んでおり、v4/v6 ともに一定量の経路を取り込めています。

ただ、受け取れたのはフルルートのおよそ 1/4 程度で、残りは取り込み途中のまま止まってしまいました。この状態だと RIB や FIB の反映が最後まで終わらず、rpd がアイドルに戻れないまま負荷がかかった状態が続きます。
メモリ使用量は大きな変動はなく安定していましたが、CPU の負荷だけが収束しない挙動が特徴的でした。

Juniper cJunosEvolved

デフォルト値(4コア/8GBメモリ)ではフルルート学習時にメモリ不足となったため、内部向け環境変数(CPTX_EVOVM_MEM_MB)で20GBに増やしました。
コンテナ自体のリソース制限はありません(最大約251GB)。
CPUはデフォルト値としています。

グラフから分かること

このグラフは、Juniper vJunosEvolved が起動してアイドルに入り、その後フルルートを受信したときの CPU とメモリの推移をまとめたものです。
0〜1200 秒あたりまでは起動処理の時間で、その後 1200〜3300 秒まではアイドル状態が続きます。

3300 秒付近からフルルートの受信が始まり、3500 秒前後までが学習区間です。受信が始まった瞬間から CPU 使用率が急上昇し、最大で 500% ほどまで跳ね上がっています。学習が終わった直後は CPU が 300〜400% ぐらいのまま少し残りますが、その後は起動直後と同じくらいの落ち着いた状態へ戻ります。メモリは起動直後からほぼ一定で、割り当てた 20GB の中で安定して動いていました。

Juniper vJunosRouter

Containerlab経由でvrnetlabを使用する場合、デフォルトでは内部のQEMUに対して4コア/5GBメモリが割り当てられますが、フルルート学習時にメモリ不足となったため、20GBに増やしました。
コンテナ自体のリソース制限はありません(最大約251GB)。
CPUは4コアのままとしています。

グラフから分かること

このグラフは、Juniper vJunosRouter が起動してアイドルに入り、その後フルルートを受信したときの CPU とメモリの推移をまとめたものです。
0〜600 秒あたりまでが起動処理で、その後 CPU の揺らぎも少なくなり落ち着きます。
600〜1200 秒の区間はアイドル状態で、ほぼ負荷の変化はありません。

その後 1200 秒付近からフルルートの受信が始まり、1350 秒あたりまでが学習時間です。受信開始直後に CPU 使用率が大きく上がっています。
学習が終わったあとは CPU が少し揺れつつも、徐々にアイドル時のレベルに戻ります。メモリは最初から最後まで大きな変動はなく、20GB の範囲で安定していました。

Arista cEOS

デフォルト値ではCPUとメモリともに制限がなく、そのままの状態でテストをしています。
メモリは最大251GBほど使える形になります。

グラフから分かること

このグラフは Arista cEOS が起動してアイドルに入り、その後フルルートを受信したときの CPU とメモリの推移をまとめたものです。
起動は非常に早く、0〜60 秒ほどで終わり、その後 860 秒付近まではアイドル状態です。

860 秒付近からフルルートの受信が始まり、CPU 使用率が一気に上がります。cEOS の特徴として、ルーティング処理がかなり速く、900 秒あたりには受信も処理もほぼ完了していました。およそ 40 秒ほどでフルルートの処理が終わる計算になります。処理後は CPU がすぐに低い利用率へ戻り、安定した状態へ復帰します。
メモリは経路学習のタイミングで増えていますが、その後は安定しています。

Cisco XRv9000

Containerlab経由でvrnetlabを使用する場合、デフォルトでは内部のQEMUに対して2コア/16GBメモリが割り当てられますが、フルルート学習時にメモリ不足となったため、20GBに増やしました。
コンテナ自体のリソース制限はありません(最大約251GB)。
CPUは2コアのままとしています。

グラフから分かること

このグラフは Cisco XRv9000 が起動してアイドルに入り、その後フルルートを受信したときの CPU とメモリの推移をまとめたものです。
起動は 0〜1000 秒あたりで完了します。起動後は CPU 使用率が 200% に張り付いた状態になります。XRv9000 のデフォルト制限にちょうど当たっているためで、内部的にどれくらい負荷がかかっているかは外から分かりにくい挙動になっています。メモリは 6.6% ほどで安定します。

1500 秒付近からフルルート受信が始まり、約 120 秒で受信自体は終わります。取り込み速度は十分に速いです。
ただ、その後の FIB 書き込みに時間がかかり、ここからさらに約 400 秒ほど処理が続きます。FIB への書き込みが完成しても CPU が制限値に張り付いたまま戻ってこない点が XRv9000 の特徴で、処理が本当に収束しているのか判断がつきにくい動きになっています。メモリ使用量はFIBの書き込みと比例して増えていきます。

Nokia SR Linux

デフォルト値ではCPUとメモリともに制限がなく、そのままの状態でテストをしています。メモリは最大251GBほど使える形になります。

Nokia SR Linux は内部構造の都合で docker stats から CPU やメモリの値を直接取得できず、グラフ化はできませんでした。
ただ、フルルートの受信と学習そのものは問題なく動作しており、IPv4/IPv6 ともに正常に取り込めていました。経路処理で大きく止まったり、遅延したりする様子もありませんでした。
リソースの細かい数値こそ取れなかったものの、機能面では他の仮想ルータと同様にフルルートの処理が可能という結果でした。

VyOS1.5

デフォルト値ではCPUとメモリともに制限がなく、そのままの状態でテストをしています。
メモリは最大251GBほど使える形になります。

グラフから分かること

このグラフは VyOS 1.5 が起動してアイドルに入り、その後フルルートを受信したときの CPU とメモリの推移をまとめたものです。
起動は非常に速く、0〜10 秒ほどで完了しています。
10〜1100 秒付近まではアイドル状態で、とても静かな推移です。

1100 秒あたりからフルルートの受信が始まり、約 70 秒で学習が完了します。CPU はこの区間だけ大きく跳ね上がり、経路処理が集中している様子が分かります。学習後は CPU がすぐに 1% ほどまで戻り、アイドルへすぐに復帰します。内部処理が長引かない点が VyOS の軽さとしてよく出ています。メモリも全体を通して安定していました。

テスト結果からの一覧表

ここまで個別に書いてきましたが、ざっくり比較したい人向けに一覧でまとめてみました。
CPU の上限に当たる挙動や、フルルート処理の速さなど、装置ごとの特徴がそのまま出ています。

さいごに

今回の検証では、同じ Containerlab 上で動かした場合でも、NOS ごとにリソースの使い方や処理完了までの挙動に明確な差があることが分かりました。

中でも、XRv9000 や vJunos のようにコンテナ内部で QEMU（仮想マシン）を動かすタイプと、cEOS のようにコンテナネイティブに動作するタイプでは、起動時間・CPU の伸び方・フルルート処理の完了までの挙動に大きな違いが出ています。
QEMU ベースのイメージ（XRv9000、vJunos等）は、起動に時間がかかったり、内部処理が長く続いたりする傾向がありました。

実際にJuniper 系イメージでは、フルルート受信後も rpd の負荷が一定時間残り、CPU がアイドルに戻りきらないケースが確認できました。
一方で、コンテナとして直接動作する cEOS や VyOS は、起動も処理も短時間で完了し、学習後の CPU の収束も速いという結果になりました。

また、複数の NOS を同時に Containerlab 上で動かす場合は、ホスト側のリソース配分も結果に影響します。

CPU の上限に張り付きやすい XRv9000 や、内部処理が長く続くイメージを並べると、ホスト側のオーバーコミットによって挙動が不安定になる可能性があります。
今回の環境でも、ホストに余裕があると各イメージが安定して処理を完了しやすい傾向が見られました。

今後は、今回の基礎的な挙動に加えて、以下のような観点も検証していく予定です。

• オーバーコミット時の挙動の詳細
  サーバのリソースに余裕がない状態で、どの NOS がどの程度処理を遅らせるのかを確認し、CPU やメモリをどこまで割り当てれば安定して動かせるのかをサーバ選定の参考として整理する予定です。
  BGP セッション維持や FIB の更新にどれぐらい余裕が必要なのかも合わせて見ていきます。

• 割り当てリソースごとのスループット計測
  特に XRv9000 は割り当て CPU を増やすことでフォワーディング側のリソースも伸び、転送性能が変わる構造になっています。
  vJunos 系や cJunos についても、割り当てリソースと転送性能の相関を確認していく予定です。

これらの結果も含めて、Containerlab 上で NOS を検証・比較する際の材料としてまた整理していこうと思います。