Posted inネットワーキング

Containerlabによるネットワークラボシミュレーション：GNS3より速く仮想ルーター・スイッチ環境を構築する

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

3年前、本番環境に投入する前にBGPフェイルオーバーのシナリオをテストするためGNS3を起動しようとしました。VMの起動に8分かかり、12GBのRAMを消費し、ルーター間でpingを実行する前に2回クラッシュしました。そのとき、もっと良いツールを探し始め——Containerlabがすべてを変えました。

ネットワークエンジニアもDevOps実践者も共通の問題を抱えています：テスト用にリアルな環境が必要なのに、構築に時間がかかりすぎるという問題です。Containerlabは、肥大化したVMの代わりにコンテナを使ってマルチベンダーのネットワークトポロジーを定義・デプロイすることでこの問題を解決します。完全なルーティングプロトコルサポート、実際のベンダーOSイメージ、そしてラボ全体が60秒以内に起動します。

クイックスタート — 5分で動かす

Containerlabを動かすのは本当に簡単です。必要なのはDockerがインストールされたLinuxホスト（WindowsではWSL2）だけです。

Containerlabのインストール

# ワンライナーインストール（公式スクリプト）
bash -c "$(curl -sL https://get.containerlab.dev)"

# インストールの確認
clab version

これだけです。pip、virtualenv、依存関係の地獄はありません。

最初のラボ — 3台のルーター、2分で起動

lab01.yml というファイルを作成してください：

name: first-lab

topology:
  nodes:
    router1:
      kind: linux
      image: frrouting/frr:latest
    router2:
      kind: linux
      image: frrouting/frr:latest
    router3:
      kind: linux
      image: frrouting/frr:latest

  links:
    - endpoints: ["router1:eth1", "router2:eth1"]
    - endpoints: ["router2:eth2", "router3:eth1"]

デプロイします：

sudo clab deploy -t lab01.yml

コンテナが起動し、各ノードの管理IPが記載されたテーブルが表示されます。ゼロから3台のルーターが接続されるまでの合計時間：ミドルレンジのラップトップで約25秒です。

router1に接続するには：

sudo docker exec -it clab-first-lab-router1 vtysh

完了したら：

sudo clab destroy -t lab01.yml

コンテナが削除され、ネットワークインターフェースがクリーンアップされ、何も残りません。

深掘り — ContainerlabのトポロジーYAMLを理解する

ContainerlabのトポロジーYAMLは一つのことだけをします：ネットワークを記述する。構造を理解すれば、ほぼすべての実環境シナリオをモデル化できます。

ノードの種類とイメージ

Containerlabはいくつかのノードの種類をすぐに使える状態でサポートしています：

  • linux — Linuxを実行する任意のDockerイメージ（FRRouting、Bird、VyOS）
  • srl — Nokia SR Linux（無料、フル機能、ラボに最適）
  • ceos — Arista cEOS（arista.comでの無料登録が必要）
  • crpd — Juniper cRPD（Juniperライセンスが必要）
  • vr-ros — vrnetlab経由のMikroTik RouterOS

ベンダーライセンスのない多くのラボでは、Linux上のFRRoutingでOSPF、BGP、IS-IS、MPLSなどをカバーできます。Nokia SR LinuxはPullが無料で、本物のネットワークOSの体験を提供します。

デプロイ時のノード設定

起動設定はbindsキーを通じてコンテナに直接マウントされます——デプロイ後に手動でコピーする必要はありません：

name: ospf-lab

topology:
  nodes:
    r1:
      kind: linux
      image: frrouting/frr:latest
      binds:
        - configs/r1/frr.conf:/etc/frr/frr.conf
        - configs/r1/daemons:/etc/frr/daemons

    r2:
      kind: linux
      image: frrouting/frr:latest
      binds:
        - configs/r2/frr.conf:/etc/frr/frr.conf
        - configs/r2/daemons:/etc/frr/daemons

  links:
    - endpoints: ["r1:eth1", "r2:eth1"]
      mtu: 9000

ルーターの設定はホスト上に保存されます——バージョン管理可能、差分確認可能、どのマシンでも再現可能です。

ネットワークリンクと属性

リンクは内部的にvethペアです。MTUの設定、レイテンシのシミュレーション、物理ホストインターフェースへのブリッジ接続——すべてトポロジーファイルで設定できます：

  links:
    # シンプルなリンク
    - endpoints: ["r1:eth1", "r2:eth1"]

    # 障害あり（レイテンシシミュレーション）
    - endpoints: ["r1:eth2", "r3:eth1"]
      mtu: 1500

    # ホストの物理インターフェースにブリッジ
    - endpoints: ["r2:eth3", "host:ens4"]

応用 — マルチベンダーBGPラボ

私はこのような構成を本番ルーターに触れる前にBGPポリシー変更のテストに使用しています。以下のトポロジーは4コア、8GB RAMのマシンで約45秒で起動します。同等のCisco IOS VMを使ったGNS3では最低でも16GBが必要になります。

FRRoutingを使ったBGPラボ

name: bgp-lab

topology:
  nodes:
    isp1:
      kind: linux
      image: frrouting/frr:latest
      binds:
        - configs/isp1/frr.conf:/etc/frr/frr.conf
        - configs/isp1/daemons:/etc/frr/daemons

    isp2:
      kind: linux
      image: frrouting/frr:latest
      binds:
        - configs/isp2/frr.conf:/etc/frr/frr.conf
        - configs/isp2/daemons:/etc/frr/daemons

    customer:
      kind: linux
      image: frrouting/frr:latest
      binds:
        - configs/customer/frr.conf:/etc/frr/frr.conf
        - configs/customer/daemons:/etc/frr/daemons

    client:
      kind: linux
      image: alpine:latest

  links:
    - endpoints: ["isp1:eth1", "customer:eth1"]
    - endpoints: ["isp2:eth1", "customer:eth2"]
    - endpoints: ["customer:eth3", "client:eth0"]

customerルーターの最小限のFRRouting BGP設定（configs/customer/frr.conf）：

frr version 9.0
frr defaults traditional
hostname customer

router bgp 65001
 bgp router-id 10.0.0.1
 neighbor 10.0.1.1 remote-as 65010
 neighbor 10.0.2.1 remote-as 65020
 !
 address-family ipv4 unicast
  network 192.168.100.0/24
  neighbor 10.0.1.1 soft-reconfiguration inbound
  neighbor 10.0.2.1 soft-reconfiguration inbound
 exit-address-family
!
line vty
!

BGPを有効にするdaemonsファイル：

bgpd=yes
ospfd=no
zebra=yes
vtysh_enable=yes

実行中のラボの確認

# すべてのノードと管理IPを表示
sudo clab inspect -t bgp-lab.yml

# customerルーターのvtyshに接続
sudo docker exec -it clab-bgp-lab-customer vtysh

# vtysh内 — BGPネイバーを確認
show bgp summary
show ip route bgp

# eth1のトラフィックをキャプチャ
sudo ip netns exec clab-bgp-lab-customer tcpdump -i eth1 -n

Nokia SR Linuxを使う（無料、ライセンス不要）

name: srl-lab

topology:
  nodes:
    leaf1:
      kind: srl
      image: ghcr.io/nokia/srlinux:latest
    leaf2:
      kind: srl
      image: ghcr.io/nokia/srlinux:latest
    spine1:
      kind: srl
      image: ghcr.io/nokia/srlinux:latest

  links:
    - endpoints: ["leaf1:e1-1", "spine1:e1-1"]
    - endpoints: ["leaf2:e1-1", "spine1:e1-2"]

SR Linuxは適切なCLIに加えてgRPC、gNMI、JSON-RPCインターフェースを備えており、実際のベンダーOSのように動作する環境でネットワーク自動化スクリプトをテストするのに最適です。

現場で役立つ実践的なヒント

リソース比較：Containerlab vs GNS3

同じ8コア、16GB RAMのマシンで5ノードのOSPFトポロジーを実行した場合：

  • Cisco IOS VMを使ったGNS3：約10GB RAM、4〜8分の起動時間、ルーターごとに1つのVM
  • FRRoutingを使ったContainerlab：約400MB RAM、30秒未満、ルーターごとに1つのコンテナ
  • Nokia SR Linuxを使ったContainerlab：ノードごとに約1.2GB RAM、60〜90秒、フルベンダーOS

OSPF、BGP、MPLS、ルーティングポリシーなど、ほとんどのプロトコルテストにおいて、FRRoutingコンテナはリソースコストの何分の一かで必要なすべてを提供します。

ルーター設定の保存と復元

vtyshで手動変更を行った後、設定をホストに保存します：

# コンテナからホストへの実行設定を保存
sudo docker exec clab-bgp-lab-customer vtysh -c "write memory"
sudo docker cp clab-bgp-lab-customer:/etc/frr/frr.conf ./configs/customer/frr.conf

これでラボの設定がバージョン管理されます。Gitにプッシュし、チームメンバーと共有して、どこでも同じラボを再作成できます。

ContainerlabをCI/CDに統合する

YAMLファイルとDockerイメージの組み合わせモデルは、CIパイプラインに自然に組み込めます。マージ前にネットワーク設定の変更を検証しましょう：

# .github/workflows/network-test.yml
jobs:
  network-lab-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Containerlabのインストール
        run: bash -c "$(curl -sL https://get.containerlab.dev)"
      - name: ラボのデプロイ
        run: sudo clab deploy -t tests/bgp-lab.yml
      - name: 接続テストの実行
        run: |
          sleep 30  # BGPコンバージェンスを待機
          sudo docker exec clab-bgp-lab-client ping -c 3 192.168.100.1
      - name: ラボの削除
        if: always()
        run: sudo clab destroy -t tests/bgp-lab.yml

トポロジーのグラフ表示

組み込みのトポロジービジュアライザーもあります：

sudo clab graph -t bgp-lab.yml

これによりWebブラウザでインタラクティブなネットワークトポロジー図が開きます——ドキュメント作成や大規模なラボを一目で把握するのに便利です。

覚えておきたい便利なclabコマンド

# 実行中のすべてのラボを一覧表示
sudo clab inspect --all

# 削除せずに再デプロイ（再設定）
sudo clab redeploy -t lab01.yml

# 命名の衝突を避けるために特定のプレフィックスでデプロイ
sudo clab deploy -t lab01.yml --prefix myproject

# すべてのノード設定を一度に保存
sudo clab save -t lab01.yml

本格的なネットワークエンジニアリングやインフラ自動化に取り組んでいるなら、Containerlabを習得すれば素早く成果を出せます。起動、テスト、壊す、再構築——すべて1分以内、物理ラボ不要、VMハイパーバイザーのオーバーヘッドなし。トポロジーYAMLとルーター設定をGitリポジトリで共有すれば、「ラボテスト」と「本番環境への自信」の距離はほぼゼロになります。

まず2台のルーターによるFRRoutingセットアップから始めましょう。YAMLの構文に慣れたら、ベンダー固有の動作が必要になったときにSR LinuxまたはcEOSに移行してください。半日もあれば実用的なレベルに達せます。

Share:
Tags: