はじめに

こんにちは、NTTテクノクロスの山口です。

本連載では、SONiCとTelemetry、AIを活用した簡易なクローズドループ基盤の構築とその動作例について紹介します。
第2回となる今回は「試験用NW(SONiC, 試験トラヒック用サーバ)」とこれを監視/制御するためのサーバ（監視/制御サーバ)の事前設定までを扱います。

図0-1 本記事の範囲概要

SONiCの動作や経路切り替えの為の仕組みづくりなどをおさえていきましょう。

【目次】

※ 本記事の内容を用いた開発・運用は、必ずご自身の責任と判断によって行ってください。
　 開発・運用の結果について、いかなる責任も負いません。

環境の作り方(各サーバ設定)

1. 全体像

早速ですが、ここからは第1回の「本連載で作る環境と検証シナリオ」章で紹介した環境を作るための設定手順を示します。
環境構築の全体概要や前提などは第1回を参照ください。
第1回からの再掲ですが、以下に各VMの全体像とNW構成を示します。

図1-1 [第1回のおさらい] 環境の全体像(概要)とNW構成

以降で、各VMごとに設定と動作について説明します。

2. SONiC

まずはSONiC VMを用意します。
SONiCはVMで起動できるVS版が提供されていますので、今回はそれを利用します。

図2-1 本節の対象

以下サイトからイメージファイルをダウンロードしましょう。
https://sonic-net.github.io/SONiC/sonic_latest_images.html

その後、仮想化ソフト上でイメージファイルを指定しSONiC VMを起動します。
vCPUは最低2つ、メモリは8GB以上用意しましょう。
IFは監視VMとの接続用に1つ、試験トラヒック用に3つのIFを用意します。
仮想化ソフトによっては、VMを管理する為に自動で作られる場合もありますが、指定/作成が必要な場合はホストマシンからVMに接続用のIFも用意しましょう。（この点は他のVMも同様のため、他VMでは記載を省略します）
ここでは最低5本のIFを用意することとします。

図2-2 SONiCの必要IF

起動後しばらくすると以下の画像のようにログインが求められるかと思います。

図2-3 SONiC起動後の認証画面

初期ID/PWは admin/YourPaSsWoRd となりますので、それでログインしてみましょう。
ログインできたら、動作確認も踏まえてまずはバージョン確認をしてみます。

# 動作確認(version情報が表示されればOK)
$ show version
---
SONiC Software Version: SONiC.master.1157060-8a04e6c1b
SONiC OS Version: 13
Distribution: Debian 13.5
Kernel: 6.12.41+deb13-sonic-amd64
(以下略)
---

【NOS入門第2回】 で各NW機能はコンテナで実現されている、と説明しました。
docker psコマンドをたたいてコンテナをみてみましょう。

図2-4 SONiC内で起動しているコンテナ(docker psコマンドの結果)

LLDPやSNMP、BGPなどのコンテナが起動していることがわかります。
真ん中ぐらいにgnmiというコンテナがありますが、これがTelemetryを利用するためのコンテナになります。
gnmiとは何か、という点は第3回にて紹介しますので、まずはTelemetry用のコンテナがいるんだな、と理解いただければ、と思います。

ホストからアクセスできるIPアドレスも確認してみましょう。

$ ip addr show eth0
---
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:17:d2:25 brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.101/24 brd 192.168.56.255 scope global dynamic eth0
      valid_lft 534sec preferred_lft 534sec
    inet6 fe80::a00:27ff:fe17:d225/64 scope link proto kernel_ll
      valid_lft forever preferred_lft forever
---

仮想化ソフトによりますが、基本的にはeth0にホストからのアクセス用IPも付与されるかと思います。
今回の例では192.168.56.101が振られていることがわかります。
SONiCはこのようにLinux OSでよく使われるコマンドで操作が可能ですので、とっつきやすいのではないかと思います。

次に監視VMとの接続用の設定を行います。

# 監視VMと接続するためのIFにIPアドレス設定を行う
# 今回はeth1が監視VM向けのIFとし、IFは仮想化基盤ツールで設定する。
$ sudo ip addr add 172.16.100.11/24 dev eth1
$ sudo ip link set eth1 up

上の設定は一時的な設定となるため、VM再起動した場合は再設定が必要です。
設定の永続化をする場合はsystemdでサービス設定をすると良いかと思いますが、今回は説明を省略したいと思います。

3. 試験トラヒック用サーバ

ここからは試験トラヒック用サーバの準備について扱います。

図3-1 本節の対象

試験トラヒック用サーバはUbuntu24.04 LTS Serverを利用して、VMを立ち上げます。
vCPUは最低2つ、メモリは4GB以上用意します。
IFはSONiCへのトラヒック出力用に1本、SONiCからのトラヒック流入用に2本用意します。
その他、ホストマシンからのSSHやapt用にもIFを用意しておきましょう。

図3-2 試験トラヒック用サーバの必要IF

ログインはご自身がVM作成時に指定したアカウントをお使いください。
今回はadminアカウントとし、管理者権限を有するアカウントで操作するものとします。(以降のVMも同様です)

ログインしたらまずはバージョン確認と初期設定をします。

# バージョン確認
$ lsb_release -a
---
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.4 LTS
Release:        24.04
Codename:       noble
---


# Ubuntu初期セットアップ
$ sudo apt update
$ sudo apt upgrade -y
$ sudo apt install -y curl ca-certificates vim


# ホストからSSHできるようにする
$ sudo apt install -y openssh-server
$ sudo systemctl enable --now ssh

ホストからSSHするためのIPアドレスは仮想化ソフトにて自動付与されていることもあるかと思います。
以下コマンドで付与されたIPアドレスを確認しましょう。

$ ip a
---
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:1e:2a:b3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.102/24 brd 192.168.56.255 scope global enp0s8
      valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe1e:2ab3/64 scope link
      valid_lft forever preferred_lft forever
---

ない場合は以下コマンドで付与を行います。

# enp0s8が対象のIFとする。
$ sudo ip addr add 192.168.56.102/24 dev enp0s8
$ sudo ip link set enp0s8 up

今回は上の通り「192.168.56.102/24」を想定します。
なお、上の設定は一時的な設定となるため、VM再起動した場合は再設定が必要です。
設定の永続化をする場合はnetplanで設定すると良いかと思いますが、今回は説明を省略したいと思います。（これ以降のVM/設定手順も同様です)

さて、検証でのユーザ通信疑似パケットの条件は以下のようにしたいと思います。

  1.iperfにてパケット出力を行う。
  2.経路は
     試験トラヒックサーバのSONiC向け出力IF(enp0s9) → SONiC → 試験トラヒックサーバのSONiC向け入力IF(enp0s10 or enp0s16)
  3.どちらのIFに帰ってくるかはSONiCの経路設定次第

図3-3 試験トラヒックの流れ

今回は同じ宛先通信の経路変更を疑似するべく、スタティックルーティング(静的ルーティング)とipコマンドのネームスペース(namespace/ns)を活用します。
ネームスペースは簡単にいうと同一マシン内でNW環境を論理的に分離する仕組みです。
NW機器でいうVRFに近いイメージを持ってもらえるとよいかと思います。
今回は論理的に区切った空間に同じIPアドレスを指定することで、宛先としては同じIPアドレスだが到着IFが異なる、という状況を作り上げます。

設定は以下の通りです。

iperfの負荷パケット出力側（クライアント）は、ns-cli経由で10.10.99.1を送信先としてパケットを出力します。
その後はSONiC側の設定/処理に応じて、ns-serv-a/ns-serv-bのどちらかに帰ってくる、という動作となります。

このルーティング設定は試験トラヒック用サーバだけでなく、SONiC側にも設定が必要です。
順をおって本章で設定も説明しますが、概要図としては以下の通りとなります。

図3-4 namespaceも含めたtraf-SONiC間NW概要図

まずは、試験トラヒック用サーバにスタティックルーティングの設定を入れていきます。

### 試験トラヒック用サーバで実施
# ns-cliの設定
$ sudo ip netns add ns-cli
$ sudo ip link set enp0s9 netns ns-cli
$ sudo ip netns exec ns-cli ip link set lo up
$ sudo ip netns exec ns-cli ip addr add 10.10.1.1/24 dev enp0s9
$ sudo ip netns exec ns-cli ip link set enp0s9 up
$ sudo ip netns exec ns-cli ip route replace default via 10.10.1.2 dev enp0s9


# ns-serv-aの設定
$ sudo ip netns add ns-serv-a
$ sudo ip link set enp0s10 netns ns-serv-a
$ sudo ip netns exec ns-serv-a ip addr add 10.10.99.1/32 dev lo
$ sudo ip netns exec ns-serv-a ip link set lo up
$ sudo ip netns exec ns-serv-a ip addr add 10.10.11.1/24 dev enp0s10
$ sudo ip netns exec ns-serv-a ip link set enp0s10 up
$ sudo ip netns exec ns-serv-a ip route replace default via 10.10.11.2 dev enp0s10


# ns-serv-bの設定
$ sudo ip netns add ns-serv-b
$ sudo ip link set enp0s16 netns ns-serv-b
$ sudo ip netns exec ns-serv-b ip addr add 10.10.99.1/32 dev lo
$ sudo ip netns exec ns-serv-b ip link set lo up
$ sudo ip netns exec ns-serv-b ip addr add 10.10.12.1/24 dev enp0s16
$ sudo ip netns exec ns-serv-b ip link set enp0s16 up
$ sudo ip netns exec ns-serv-b ip route replace default via 10.10.12.2 dev enp0s16

次にSONiC側のスタティックルーティング設定を入れていきます。

### SONiCで実施
# 試験トラヒックサーバのenp0s9の対向がeth2、enp0s10の対向がeth3, enp0s16の対向がeth4である想定
$ sudo ip addr add 10.10.1.2/24 dev eth2
$ sudo ip link set eth2 up


$ sudo ip addr add 10.10.11.2/24 dev eth3
$ sudo ip link set eth3 up


$ sudo ip addr add 10.10.12.2/24 dev eth4
$ sudo ip link set eth4 up


$ sudo sysctl -w net.ipv4.ip_forward=1


# 10.10.99.1宛てはeth3で返す初期設定(=試験トラヒック用サーバのns-serv-a側に返る)
$ sudo ip route replace 10.10.99.1/32 via 10.10.11.1 dev eth3

ここまでの設定で以下のようになっているはずです。

図3-5 現時点の設定状態

SONiC側の手順でIPアドレスを設定したeth2～4にユーザ通信疑似のiperfパケットが流れるため、Telemetryデータの取得対象はこれらのIFとなります。
これまでの手順の通り、仮想化ソフトで追加したIFについてはeth1のようにethX形式で表示/認識されますが、SONiCのポート管理上ではEthernet0というようにEthernetX形式で管理されています。
本検証環境では、それぞれ以下のように紐づいています。
  ・eth2：Ethernet4
  ・eth3：Ethernet8
  ・eth4：Ethernet12

SONiC上でのipコマンドレベルのIF確認や経路制御ではethXで表示/指定しますが、Telemetryによる監視ではEthernetXが使用されます。

ここまで設定出来たら、試験トラヒック用サーバから疎通確認を行い、設定が正しく入っているか確認しましょう。

### 試験トラヒック用サーバで実施
# 疎通確認
$ sudo ip netns exec ns-cli ping -c 3 10.10.99.1

問題なければSONiC側でルーティングを切り替えても、問題なく届くか合わせて確認しておきましょう。

### SONiCで実施
# 経路切り替え(eth3経由からeth4(ns-serv-b向け)に変更)
$ sudo ip route replace 10.10.99.1/32 via 10.10.12.1 dev eth4

切り替え後、再度試験トラヒック用サーバで疎通確認を行います。（コマンドはns-serv-a経由で試した際と同様です) こちらも問題なければ、SONiCの経路設定を元のeth3経由に戻しておきましょう。

### SONiCで実施
# 経路切り替え(eth4経由からeth3(ns-serv-a向け)に変更)
$ sudo ip route replace 10.10.99.1/32 via 10.10.11.1 dev eth3

ここまで出来たら、iperfのインストールを行います。

# iperf3インストール
$ sudo apt install -y iperf3
# インストール後確認
$ sudo ip netns exec ns-cli iperf3 --version
---
iperf 3.16 (cJSON 1.7.15)
Linux traf 6.8.0-134-generic #134-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 26 18:43:11 UTC 2026 x86_64
Optional features available: CPU affinity setting, IPv6 flow label, SCTP, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, authentication, bind to device, support IPv4 don't fragment, POSIX threads
---

iperfではクライアント側から出力するパケット条件を指定して出力、サーバ側で待ち受けて到達したかどうかなどを確認できます。

図3-6 iperf利用のイメージ

ここまできたら以下のコマンドで負荷を実際にかけられます。

### 試験トラヒック用サーバで実施
## iperfクライアント(パケット出力側)
# 10.10.99.1宛てに10.10.1.1からUDPで1000Kbpsで10秒間出力
$ sudo ip netns exec ns-cli iperf3 -u -b 1000K -c 10.10.99.1 -B 10.10.1.1 -t 10


## iperfサーバ(パケット受信側)での待ち受け
# ns-serv-a側(10.10.99.1で待ち受け)
$ sudo ip netns exec ns-serv-a iperf3 -s -B 10.10.99.1
# ns-serv-b側(10.10.99.1で待ち受け)
$ sudo ip netns exec ns-serv-b iperf3 -s -B 10.10.99.1

今回の構成でのイメージは以下の通りです。

図3-7 今回の構成でのiperfイメージ(iperfサーバ同時起動の場合)

参考までに実行結果は以下のようになります。

図3-8 iperfでの負荷実施例

結果を見ると送信間隔ごとの値の差も発生していることに加え、ロスも発生していると表示されており、あまり安定はしていなそうです。
検証環境(ホストマシン)や試験トラヒック用サーバのスペックの他、VMを使っていることによるオーバーヘッドも考えられます。
より安定的にパケットを送信するのであれば一案として試験トラヒック用サーバのスペックを上げる(スケールアップする)ことや、PktgenなどDPDKを活用したパケットジェネレータを使う案もありますが、今回の検証は主目的が性能評価ではないこと、また手順を簡易化したいことから、このままのVMスペックで、かつパケット負荷はiperfを利用します。
[参考] DPDKやPktgenについては【DPDK 第1回】、【同12回】を参照ください。

さて、ここまできたら「本連載で作る環境と検証シナリオ」章(第1回)で説明したシナリオの準備をしましょう。
通常時のトラヒックと異常時のトラヒック条件の準備をします。

トラヒックは多少凹凸があるかと思うので、通常時は900K～1100Kをランダムに流れる形で準備をします。

# 通常時のトラヒック流入シェルスクリプトを作成
$ vim loop_iperf_normal.sh

#!/usr/bin/env bash
BWS=("900K" "1000K" "1100K")


while true; do
    # ランダムな数値÷3をした際の余り(0, 1, 2)をBWS配列の添え字として渡す
    BW=${BWS[$RANDOM % 3 ]}
    # 決められた条件で出力
    sudo ip netns exec ns-cli iperf3 -u -b "$BW" -c 10.10.99.1 -B 10.10.1.1 -t 10
    sleep 0.5
done

異常時の負荷スクリプトも用意しましょう。
今回のシナリオでは通常時の概ね3倍のトラヒックが流れるものとします。

# 異常時のトラヒック流入シェルスクリプトを作成
$ vim loop_iperf_anomaly.sh

#!/usr/bin/env bash


while true; do
    # 3000Kbpsで出力し続ける。
    sudo ip netns exec ns-cli iperf3 -u -b 3000k -c 10.10.99.1 -B 10.10.1.1 -t 10
    sleep 0.5
done

なお、どちらの条件もiperfは極力指定された条件の通りに流そうとしますが、前述の通りホストマシンやVMのリソース状態により、これに満たない流量で流れる可能性があります。

両方のスクリプトに実行権限を付与しておきます。

$ sudo chmod +x ./loop_iperf_normal.sh
$ sudo chmod +x ./loop_iperf_anomaly.sh

ここまでできたらiperfを使って通常のトラヒックをかけておきましょう。

### 試験トラヒック用サーバで実施
## iperfクライアント(パケット出力側)
# iperfによる通常時パケット出力を行うスクリプト起動
$ sudo ./loop_iperf_normal.sh


## iperfサーバ(パケット受信側)での待ち受け
# ns-serv-a側(10.10.99.1で待ち受け)
$ sudo ip netns exec ns-serv-a iperf3 -s -B 10.10.99.1
# ns-serv-b側(10.10.99.1で待ち受け)
$ sudo ip netns exec ns-serv-b iperf3 -s -B 10.10.99.1

ここまで問題なくできたらNW層(SONiCと試験トラヒック用サーバ)の事前設定は完了です。

4. 監視/制御サーバ

VMとしては最後となりますが、監視/制御用のサーバを用意しましょう。

図4-1 本節の対象

監視/制御サーバはUbuntu24.04 LTS Serverを利用して、VMを立ち上げます。
vCPUは最低8つ、メモリは16GB以上用意します。
IFはSONiCからのTelemetry収集用に1つと、ホストマシンとのSSHやapt用IF1つ、監視/制御基盤サーバの増築・スケールアウト用（拡張性保持）のIF1つの計3つを最低限用意します。
  ※ 監視/制御サーバのスケールアウトは本連載では扱いません。

図4-2 監視/制御サーバの必要IF

まずは初期設定をします。
初期設定は「試験トラヒック用サーバ」で実行した手順と同じです。
ホストマシンからアクセスするためのIP確認も同様です。今回は「192.168.56.103/24」を想定します。

次にSONiCと将来拡張する可能性があるkubernetes用NWのIFの設定を行います。

# SONiC向け。enp0s9がSONiC向けのIFとする。
$ sudo ip addr add 172.16.100.100/24 dev enp0s9
$ sudo ip link set enp0s9 up


# k8s用。enp0s10が当該NW用のIFとする。
$ sudo ip addr add 172.16.200.10/24 dev enp0s10
$ sudo ip link set enp0s10 up

設定したらSONiC側と疎通が通るか確認します。

$ ping 172.16.100.11

ここまでできたらサーバの事前設定は完了です。

おわりに

今回はSONiC, 試験トラヒック用サーバの連携動作のための構築(NW層の構築)と監視/制御サーバの事前設定を行いました。
SONiCの動作イメージやNamespaceの利用方法などの理解が進んだのであれば幸いです。

次回はいよいよ監視/可視化基盤の構築です。
併せて関連する技術などの紹介/補足もできれば、と思います。

今回も最後までご覧いただきありがとうございました。
もし何かご意見・コメント・ご質問などがあれば、以下からお問い合わせください。