はじめに

wpg (web-packet-generator) は、Web GUI で動作するネットワーク検証向けの Rust 製パケットジェネレータです。IS-IS や CLNP など OSI 系の深いプロトコルまで含め、任意のパケットを組み立てて高速に送出できます。送出バックエンドは pcap/Npcap から AF_PACKET、AF_XDP、DPDK まで選択可能です。Windows / macOS / Linux 向けの単一バイナリとして配布されます。利用は検証環境に限定してください。

どこから読むか

1. インストール方法を選ぶ: 手元の OS でソースからビルドする、SSH で Linux の検証ホストにデプロイする、Docker イメージで動かす、のいずれかを選びます。
2. 選んだ方法のインストールページに沿って進めます。wpg doctor が送信できないと報告したら 権限設定 を読みます。
3. 初回ログイン: パスワードを設定し、画面をひととおり見ます。
4. チュートリアルを ARP スイープ から順に進めます。

送信以外は権限なしで試せます。テンプレートを pcapng ファイルに書き出すだけなら raw ソケットは不要です。

用語

同じバイナリがサーバ (wpg serve: Web UI と REST API) とコマンドラインツール (wpg send、wpg render、wpg template lint など) を兼ねます。CLI リファレンス を参照してください。

このマニュアルの構成

• はじめに (Getting Started): インストール、権限設定、初回ログイン。
• チュートリアル: ARP スイープ、レート制御、pcap の再生、IS-IS の隣接確立などを最初から最後まで行う手順。
• リファレンス: 全プロトコル、テンプレートスキーマ、API、CLI、wpg.toml の生成ページ。
• 運用: デプロイ、サービス化、Docker、アップグレード、高速バックエンド、TLS、受信と検証。
• 開発者ガイド: crate 構成、プロトコルと翻訳の追加手順。

送信は、自分が管理しているか試験を許可されたネットワークでだけ行ってください。法的注意 を参照してください。

インストール方法を選ぶ

wpg は Web UI を組み込んだ単一の wpg 実行ファイルです。リリースバイナリはまだ公開していないため、下のどの方法でもソースからビルドします。違いは、どこでビルドし、どう動かすかです。

必要なもの

• wpg を動かすマシン: Linux (Ubuntu 20.04 以降と同等のディストリビューション)、macOS 12 以降、Windows 10 21H2 以降。
• 試験したい検証ネットワークにつながったネットワークインタフェース。自分が管理していない、または試験を許可されていないネットワークへの送信はできません。
• ブラウザ。同じマシン上のもの、またはパスワードを設定してローカル以外のアドレスで待ち受ければ別のマシンのもの。

方法を選ぶ

選ぶときの注意:

• レート。 Windows は Npcap だけで送信し、GUI での低〜中レートの利用を想定しています。macOS は BPF で送信します。高レート (AF_PACKET、AF_XDP、DPDK) には Linux を使ってください。
• Docker Desktop (macOS / Windows) はコンテナを VM の中で動かすので、フレームは物理 NIC に届きません。Docker は Linux ホストでだけ使ってください。
• まだ権限がない場合。 どの方法でも、テンプレートの pcapng への書き出しと Web UI は raw ソケットの権限なしで使えます。権限が要るのは送信だけです (権限設定)。

インストールの後

どの方法でも、次の手順は同じです。

1. wpg doctor を実行し、送信について報告された問題を直します (権限設定)。
2. wpg serve でサーバを起動し (デプロイスクリプトと Docker では起動済みです)、http://127.0.0.1:8080 を開きます。
3. パスワードを設定して画面を見て回ります: 初回ログイン。
4. まずドライラン (pcapfile バックエンドは送信せずに pcapng ファイルへ書き出します) を試し、ARP スイープのチュートリアル で実際に送信します。

うまくいかないときは FAQ / トラブルシュート を参照してください。

Linux へのインストール

対応: Ubuntu 20.04 以降 (glibc 2.31) と同等のディストリビューション。リリースバイナリはまだ公開していないため、ソースからビルドします。成果物は Web UI を組み込んだ単一の wpg 実行ファイルです。

1. 前提ソフトウェアを入れる

# Rust ツールチェーンのインストーラ (rustup.rs) と、リンク用の C ツールチェーン
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
sudo apt install build-essential pkg-config git

git clone https://github.com/SeiyaFunaokaJP/web-packet-generator.git
cd web-packet-generator
./scripts/setup.sh          # --just を付けるとタスクランナー just も入れる

scripts/setup.sh は rust-toolchain.toml で固定した Rust ツールチェーンと Web UI 用の WASM ターゲット、scripts/versions.env で固定したバージョンのビルド済み trunk (Web UI のバンドラ) を入れ、最後に次に実行するコマンドを表示します。

Linux は AF_PACKET で送信するので、追加のライブラリは不要です。任意の libpcap バックエンド (--features pcap) を使う場合だけ sudo apt install libpcap-dev が必要です。tshark (パッケージ名 tshark) は任意です。チュートリアルで生成したキャプチャの確認に使います。

2. ビルドする

./scripts/build.sh --release        # または: just release

スクリプトは trunk で Web UI を、続いて cargo で wpg バイナリをビルドして、==> done: target/release/wpg と表示します。オプションのバックエンドには --features pcap、--features afxdp、--dpdk を付けます。trunk が無い場合、バイナリはビルドされますが Web UI はスキップされます。

3. 権限なしで試す

ファイルへの書き出しに特別な権限は不要なので、まず動作を確認できます。

./target/release/wpg doctor
./target/release/wpg template lint templates/examples/*.wpg.yaml
./target/release/wpg render templates/examples/arp-sweep.wpg.yaml -o /tmp/arp.pcapng

wpg doctor は送信に不足しているものを報告します (権限設定)。次の手順を行うまでは caps.raw_socket が失敗して構いません。

4. 生ソケット送信を許可する

root で実行するか、バイナリに一度だけ capability を付与します (ファイルを置き換えると失われます)。

sudo setcap cap_net_raw,cap_net_admin+ep ./target/release/wpg
./target/release/wpg doctor

5. サーバを起動する

./target/release/wpg serve            # 開発用のホットリロードは: just run

既定では 127.0.0.1:8080 で待ち受け、./templates のテンプレートを読み込みます。ブラウザで http://127.0.0.1:8080 を開き、パスワードと最初の画面は次ページの 初回ログイン を参照してください。別のマシンからアクセスするには、パスワードを設定したうえで --bind 0.0.0.0:8080 (または wpg config init で作る wpg.toml の bind) を使います。設定リファレンス を参照してください。ラボのホストに常設するときは scripts/deploy.sh がバイナリのコピー、setcap、systemd ユニットの投入を行います。CML2 での注意点 も参照してください。

最初のフレームを送る

./target/release/wpg ifaces
./target/release/wpg send templates/examples/arp-sweep.wpg.yaml -i eth1 --rate 1000pps

送信してよいのは、自分が所有する、または試験を許可されたネットワークだけです。続けて ARP スイープのチュートリアル に進んでください。

macOS へのインストール

対応: macOS 12 以降。リリースバイナリはまだ公開していないため、ソースからビルドします。成果物は Web UI を組み込んだ単一の wpg 実行ファイルです。macOS は libpcap を標準で持つので、追加のライブラリは不要です。macOS で送信できるのは libpcap バックエンド (pcap feature) だけなので、scripts/build.sh (と just release) は macOS では自動でこれを組み込みます (--no-pcap で外せます)。リリースアーカイブにも含まれます。

1. 前提ソフトウェアを入れる

xcode-select --install                     # コンパイラとリンカ
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
brew install wireshark                     # 任意: tshark と ChmodBPF (下記)

git clone https://github.com/SeiyaFunaokaJP/web-packet-generator.git
cd web-packet-generator
./scripts/setup.sh                         # --just を付けるとタスクランナー just も入れる

scripts/setup.sh は rust-toolchain.toml で固定した Rust ツールチェーンと WASM ターゲット、scripts/versions.env で固定したバージョンのビルド済み trunk を入れます。

2. ビルドする

./scripts/build.sh --release        # または: just release

最後に ==> done: target/release/wpg と表示されます。

3. 権限なしで試す

./target/release/wpg doctor
./target/release/wpg template lint templates/examples/*.wpg.yaml
./target/release/wpg render templates/examples/arp-sweep.wpg.yaml -o /tmp/arp.pcapng

4. 送信を許可する

送信は /dev/bpf* を通ります。sudo で wpg を実行するか、デバイスをアクセス可能にします。Wireshark を ChmodBPF ヘルパー付きでインストールすると、access_bpf グループのメンバーに対してそれが行われます。お使いのマシンに合った案内は wpg doctor が表示します。権限設定 を参照してください。

5. サーバを起動する

./target/release/wpg serve

既定では 127.0.0.1:8080 で待ち受け、./templates のテンプレートを読み込みます。ブラウザで http://127.0.0.1:8080 を開き、初回ログイン に進んでください。

最初のフレームを送る

./target/release/wpg ifaces
sudo ./target/release/wpg send templates/examples/arp-sweep.wpg.yaml -i en0 --rate 1000pps

送信してよいのは、自分が所有する、または試験を許可されたネットワークだけです。続けて ARP スイープのチュートリアル に進んでください。

リリースバイナリ: Gatekeeper と quarantine

リリースアーカイブ (Apple シリコン用の wpg-<version>-aarch64-apple-darwin.tar.gz、Intel 用の ...-x86_64-apple-darwin.tar.gz) は署名も公証もしていません。ブラウザでダウンロードしたファイルには com.apple.quarantine 属性が付き、Gatekeeper が実行を拒否します (「Apple は悪質なソフトウェアかどうかを確認できないため、“wpg” を開けません」や「壊れているため開けません」と表示されます)。上の手順でソースからビルドすれば、この問題は起きません。

まずダウンロードしたファイルを確認し、展開したファイルから属性を外します。

shasum -a 256 -c wpg-0.2.0-aarch64-apple-darwin.tar.gz.sha256   # または SHA256SUMS と比べる
tar -xzf wpg-0.2.0-aarch64-apple-darwin.tar.gz
xattr -dr com.apple.quarantine wpg-0.2.0-aarch64-apple-darwin
./wpg-0.2.0-aarch64-apple-darwin/wpg --version

別の方法:

• ブラウザではなく curl -LO でダウンロードします。curl は quarantine 属性を付けません。
• 一度実行してから、システム設定 → プライバシーとセキュリティ で許可します (「このまま開く」)。次の起動時にもう一度確認され、以後は記憶されます。
• Finder の近道 (Control キーを押しながらクリック → 開く) は macOS 15 で廃止され、コマンドラインツールにはもともと使えません。xattr かシステム設定を使ってください。

Gatekeeper 全体を無効にする (spctl --master-disable) ことはしないでください。新しくダウンロードしたファイルにはそのたびに属性が付くので、アップグレードのたびに外し直してください。起動時に wpg を動かす方法は サービスとして動かす を参照してください。

Windows へのインストール

対応: Windows 10 21H2 以降。リリースバイナリはまだ公開していないため、ソースからビルドします。送信は Npcap のみを使い、GUI での低〜中レート利用を想定しています。高いレートが必要なときは Linux を使ってください。以下のコマンドは PowerShell 用です。

Windows から Linux の検証用ホストに wpg を入れたいだけなら、Windows 上でビルドする必要はありません。リポジトリを手元に用意し (git clone、または GitHub の「Download ZIP」を展開)、scripts\deploy.bat をダブルクリックします。ウィザードが接続先、SSH のユーザとパスワード、sudo パスワード、Web UI の管理者パスワード、送信に使うインタフェースを日本語で聞き、ホスト上で wpg をビルドしてサービスとして入れます。必要なのは Windows 10 / 11 標準の OpenSSH クライアントだけです。デプロイ を参照してください。

1. 前提ソフトウェアを入れる

1. rustup をインストールします (既定の MSVC ツールチェーンを選びます。Visual Studio Build Tools の「C++ によるデスクトップ開発」が無い場合は案内されます)。

2. Npcap をインストールします (既定のオプションのままでかまいません。WinPcap API 互換モードは不要です)。送信に必要です。

3. リポジトリを取得し、セットアップスクリプトを実行します。

   git clone https://github.com/SeiyaFunaokaJP/web-packet-generator.git
   cd web-packet-generator
   .\scripts\setup.ps1              # -Just を付けるとタスクランナー just も入れる
   

   rust-toolchain.toml で固定した Rust ツールチェーンと WASM ターゲット、scripts\versions.env で固定したバージョンのビルド済み trunk と Npcap SDK (C:\Npcap-SDK に展開) を入れ、まだ足りないもの (C++ ビルドツール、Npcap) を表示します。PowerShell がスクリプトの実行を拒否する場合は powershell -ExecutionPolicy Bypass -File .\scripts\setup.ps1 で実行してください。

   SDK は Npcap バックエンド (pcap feature) のリンクに必要です。Windows で送信できるのはこのバックエンドだけです。自分で展開した SDK も、scripts\build.ps1 が C:\npcap-sdk-<バージョン> (zip の名前のまま。複数あれば新しいもの)、環境変数 NPCAP_SDK で指定したディレクトリ、SDK の Lib\x64 を指す LIBPCAP_LIBDIR から見つけます。SDK が無くてもビルドは成功しますが、できた wpg.exe は送信できず、build.ps1 が警告します。

4. 任意: Wireshark (tshark 用)。

2. ビルドする

.\scripts\build.ps1 -Release       # または: just release

SDK が見つかると ==> Npcap SDK: LIBPCAP_LIBDIR=... と表示し、最後に ==> done: target\release\wpg.exe と表示されます。主な使い方は次のとおりです。

trunk が無いとフロントエンドのビルドは警告付きで省略されます (Web UI は古い、または存在しない crates\wpg-web\dist を配信します)。

3. 権限なしで試す

.\target\release\wpg.exe doctor
.\target\release\wpg.exe render templates\examples\arp-sweep.wpg.yaml -o $env:TEMP\arp.pcapng

4. 送信を許可する

wpg doctor が Npcap をインストール済み (npcap)、Npcap バックエンドを組み込み済み (backend.pcap) と報告することを確認します。backend.pcap が fail なら build.ps1 が Npcap SDK を見つけられていないので、.\scripts\setup.ps1 を実行して (手順 1) ビルドし直してください。Npcap を既定のオプションで入れていれば、通常の PowerShell から送信できます (caps.raw_socket は ok)。「Restrict Npcap driver’s access to Administrators only」を選んで入れた場合は caps.raw_socket が fail になるので、送信するときは 管理者として PowerShell を開いて ください。権限設定 を参照してください。

5. サーバを起動する

.\scripts\run.ps1                  # または: .\target\release\wpg.exe serve

既定では 127.0.0.1:8080 で待ち受け、.\templates のテンプレートを読み込みます。ブラウザで http://127.0.0.1:8080 を開き、初回ログイン に進んでください。Windows ファイアウォールが wpg.exe の許可を求めたときは、ローカル以外のアドレスに bind する場合に限り、プライベートネットワークだけを許可してください。

最初のフレームを送る

.\target\release\wpg.exe ifaces
.\target\release\wpg.exe send templates\examples\arp-sweep.wpg.yaml -i <インタフェース> --rate 1000pps

インタフェース名は wpg ifaces の表示 ({GUID}) を使います (tshark -D が表示する \Device\NPF_{GUID} でもかまいません)。Npcap のループバックアダプタ (\Device\NPF_Loopback) は Ethernet フレームを受け付けません (PacketSendPacket failed ... (50))。実ネットワークに出さずに送信を試すときは、Hyper-V の vEthernet (Default Switch) や VMware のホストオンリーアダプタなどの仮想アダプタを使い、wpg capture -i <インタフェース> --backend pcap --include-outgoing か tshark で確認してください。送信してよいのは、自分が所有する、または試験を許可されたネットワークだけです。続けて ARP スイープのチュートリアル に進んでください。

リリースアーカイブと Npcap の確認

リリースアーカイブ (wpg-<version>-x86_64-pc-windows-msvc.zip) には、Web UI と Npcap バックエンドを組み込んだ wpg.exe、サンプルテンプレート、packaging\windows\wpg-service.ps1 が入っています。コード署名はしていません。

# 確認してから、展開前に「インターネットからダウンロードした」印を外す
(Get-FileHash .\wpg-0.2.0-x86_64-pc-windows-msvc.zip -Algorithm SHA256).Hash   # SHA256SUMS と比べる
Unblock-File .\wpg-0.2.0-x86_64-pc-windows-msvc.zip
Expand-Archive .\wpg-0.2.0-x86_64-pc-windows-msvc.zip -DestinationPath "C:\Program Files\wpg"

それでも SmartScreen が「Windows によって PC が保護されました」と表示した場合は、一度だけ 詳細情報 → 実行 を選びます。

Npcap は同梱していません (無償版のライセンスでは再配布できません)。wpg.exe は wpcap.dll を /DELAYLOAD でリンクしており、pcap バックエンドを初めて使うときに読み込みます。その際 System32\Npcap を自分で DLL 検索パスに加えるので、Npcap が無くても起動でき、Npcap のどちらのインストールモードでも動きます。wpg doctor と scripts\build.ps1 の両方が確認します。

• wpg doctor は、Npcap が無いと npcap のチェックを失敗にし、Npcap がインストールされているように見えるのに wpcap.dll が System32\Npcap にも System32 にも無いときは警告します。対処の行に https://npcap.com/#download へのリンクが出ます。
• Npcap 無しで送信すると、クラッシュせずに Npcap is not installed; install it from https://npcap.com/#download and run wpg doctor で止まります。
• wpg doctor は、wpg.exe が Npcap バックエンドなしでビルドされていると backend.pcap を失敗にし、SDK を展開して scripts\build.ps1 を再実行するよう案内します。
• Npcap を管理者専用モードで入れた場合、昇格していないターミナルでは caps.raw_socket が fail になります。管理者ターミナルで実行するか、そのオプションを外して Npcap を入れ直してください。
• scripts\build.ps1 もビルドの前に警告を出します。Npcap が無くてもビルドは成功しますが送信はできないため、また Npcap SDK なしでビルドするときも警告します。

起動時に wpg をバックグラウンドで動かす方法は サービスとして動かす を参照してください。

Docker で動かす

イメージはコンテナの中で wpg と Web UI をビルドするので、ホストに必要なのは Docker だけです。Rust ツールチェーンも trunk も要りません。Linux ホスト を使ってください。macOS / Windows の Docker Desktop はコンテナを VM の中で動かすため、そこから送ったフレームは物理 NIC に届きません。

このページは最短の手順です。ビルドオプション、プロキシ、全設定、制限は Docker にあります。

1. リポジトリを取得して起動する

git clone https://github.com/SeiyaFunaokaJP/web-packet-generator.git
cd web-packet-generator
WPG_PASSWORD='change me' WPG_ALLOWED_IFACES='["eth1"]' docker compose up -d --build

• WPG_PASSWORD は必須です。サーバはホストの全アドレスで待ち受けるため、パスワードがないと起動しません。自分で決めた値にしてください。Web UI の管理者パスワードになります。
• WPG_ALLOWED_IFACES はジョブが送信してよいインタフェースの一覧です。検証用インタフェースの名前を指定します (ip -br link で一覧できます)。省略するとすべて許可します。
• 初回のビルドはすべてをコンパイルするので時間がかかります。2 回目以降はイメージを再利用します。

コンテナはホストのネットワークを使い、CAP_NET_RAW と CAP_NET_ADMIN だけを持ちます。ホスト上で wpg を root で動かさずに、ホストのインタフェースから送信できます。

2. 確認する

docker compose ps                         # サーバが応答すると STATUS が "healthy" になる
docker compose exec wpg wpg doctor        # コンテナから見た raw ソケットとインタフェース

ホストで http://127.0.0.1:8080 (別のマシンからは http://<ホスト>:8080) を開き、パスワードでログインします。画面の説明は 初回ログイン にあります。

3. テンプレートを試す

同梱テンプレートはコンテナ内の /usr/share/wpg/templates にあり、テンプレート 画面に表示されます。コマンドラインでは、まずファイルに書き出し (何も送信しません)、それから送信します。

docker compose exec wpg wpg render /usr/share/wpg/templates/examples/arp-sweep.wpg.yaml -o /var/lib/wpg/arp.pcapng
docker compose exec wpg wpg send /usr/share/wpg/templates/examples/arp-sweep.wpg.yaml -i eth1 --rate 1000pps

/var/lib/wpg は wpg-data ボリュームです。データベース、自分のテンプレート、上の pcapng のようなファイルは、再起動やイメージの更新後も残ります。送信は、自分が管理しているか試験を許可されたネットワークでだけ行ってください。続きは ARP スイープのチュートリアル です。チュートリアルの wpg ... は docker compose exec wpg wpg ... に読み替えてください。

停止・更新・削除

docker compose logs -f wpg                # ログを追う
docker compose down                       # 停止 (wpg-data ボリュームは残る)
git pull && WPG_PASSWORD='change me' docker compose up -d --build   # 更新
docker compose down -v                    # 停止して wpg-data ボリュームも削除

設定をシェルの履歴に残したくない場合は、docker-compose.yml と同じ場所の .env ファイルに書きます (WPG_PASSWORD=...、WPG_ALLOWED_IFACES=...、WPG_BIND=...)。リポジトリは .env を git と Docker のビルドコンテキストの両方で無視するので、パスワードがコミットされたりイメージに入ったりすることはありません。

権限設定

raw フレームの送出は特権操作であり、必要な権限は OS ごとに異なります。wpg は起動時と wpg doctor の実行時に自己診断を行い、OS 別の対処方法を表示します。管理者設定で、許可インタフェースや最大レートを制限することもできます。

Linux

afpacket バックエンドには CAP_NET_RAW が必要です (CAP_NET_ADMIN も併せて付与します)。root で実行するか、バイナリに capability を付与します。

sudo setcap cap_net_raw,cap_net_admin+eip /path/to/wpg

これは wpg doctor が、実行中のバイナリの実パスで表示するヒントです。バックエンドが EPERM/EACCES で拒否された場合、エラーは次のように案内します。

AF_PACKET needs CAP_NET_RAW: run as root or grant it with `sudo setcap cap_net_raw,cap_net_admin+ep $(command -v wpg)`

file capability はバイナリを置き換えると失われ、nosuid マウント上では無視されます。systemd では AmbientCapabilities=CAP_NET_RAW CAP_NET_ADMIN を使います。CML2 での注意点も参照してください。

macOS

/dev/bpf* への読み書きアクセスが必要です。sudo で実行するか、デバイスをアクセス可能にします (例: Wireshark の ChmodBPF)。wpg doctor のヒントは sudo /path/to/wpg … (or make /dev/bpf* accessible, e.g. via Wireshark's ChmodBPF) です。

Windows

Npcap が必要です (インストールモードは問いません。wpg が System32\Npcap の wpcap.dll を自分で見つけます)。管理者ターミナルが必要なのは、Npcap を管理者専用モードで入れた場合だけです。wpg doctor はその設定 (HKLM\SYSTEM\CurrentControlSet\Services\npcap\Parameters の AdminOnly) を読み、既定のインストールなら管理者権限なしでも caps.raw_socket を ok (npcap_admin_only=no) に、管理者専用モードなら fail にしてヒント Run from an elevated (Administrator) terminal, or reinstall Npcap ... without "Restrict Npcap driver's access to Administrators only" (管理者ターミナルで実行するか、この選択を外して Npcap を入れ直す) を表示します。設定を読めないときは警告です。Npcap がない場合は https://npcap.com/#download を案内します。

wpg doctor による確認

wpg doctor は 1 チェック 1 行で、角括弧内に安定した id を表示します。wpg doctor --json はスクリプト向けに同じ内容を返します。チェックが fail のとき終了ステータスは 0 以外です。

各チェックの結果は ok、warn、fail、skip (この OS では対象外) のいずれかです。

初回ログイン

サーバを起動し、表示されたアドレスを開きます。

wpg serve                       # 127.0.0.1:8080 で待ち受け

管理パスワードの設定

パスワードは次のいずれかで設定します (優先度の高い順。お使いのビルドが対応するものは wpg serve --help で確認してください)。

1. wpg serve --password … または --password-file <file>
2. 環境変数 WPG_PASSWORD
3. wpg.toml の [auth] password_hash / password_file (argon2id ハッシュ。wpg config set-password で書き込み)
4. 上のいずれも無い場合の、初回アクセス時のセットアップ画面

パスワードが無い間、wpg はローカルマシンからの接続だけを受け付け、起動時に警告します。パスワードを設定するまでは、ローカル以外のアドレスに bind しないでください。パスワードは argon2id ハッシュで保存され、セッションは HttpOnly、SameSite=Strict の Cookie で管理され、ログイン失敗の繰り返しはレート制限されます。ネットワーク越しにアクセスするときは TLS を前段に置きます (--tls、wpg.toml の証明書、またはリバースプロキシ)。

最初の画面

ログインするとダッシュボードが開きます。インタフェース状態、実行中ジョブ、直近の統計が見られます。続いて次の画面を使います。

1. テンプレート: 同梱ライブラリ (examples、protocols、scenarios、malformed) が一覧され、タグ (protocol:ipv4、layer:l3、scenario、malformed) で検索できます。開くか、複製して自分用にします。
2. ビルダー: レイヤを積み、フィールド (Auto/Manual、ジェネレータ) を編集し、Hex ダンプとフィールドツリーの更新を確認します。空のビルダーには「Ethernet II / IPv4 / UDP」などのよく使う構成が並び、各フィールドには既定値 (MAC アドレス、IP アドレスなど) が入った入力欄が最初から表示されます。入力するとその値が手動の値になり、↺ で既定値に戻ります。
   • 既定では規格どおりのパケットだけを作れます。長さ・チェックサムなどの自動計算フィールドは固定され、規格外の値 (長さやチェックサムの不一致、制約外の値など) はフィールドの下とツールバーにエラーとして表示され、保存とジョブ作成ができません。
   • 異常系のパケットを作るときは、ツールバーの 不正なパケットを許可 をオンにします。自動計算フィールドを「上書き」でき、規格外の値は警告として扱われます。設定はブラウザごとに保存され、規格外の値を含むテンプレート (malformed など) を開くと自動でオンになります。
3. ジョブ: テンプレート、インタフェース、レート、回数を選んで開始します。送出せずファイルに書き出す をオンにするとドライラン (pcapng の書き出し) になります。バースト、ワーカ数、検証用シグネチャは 詳細設定 にあります。終了したジョブは もう一度実行 で再実行でき、新しいジョブとして編集 で設定をフォームに読み込めます。
4. 設定: 言語 (日本語・英語・中国語簡体字・中国語繁体字・韓国語・ドイツ語・フランス語・スペイン語)、テーマ、テンプレートのライブラリパス。

言語の切り替え (ヘッダの言語メニュー) とテーマの切り替えは、どの画面でもヘッダにあります。

送信が拒否されたら wpg doctor を実行し、権限設定 を読んでください。その後 ARP スイープのチュートリアル に進みます。

チュートリアル: ARP スイープ

所要時間: 約 15 分。必要な権限: ステップ 5 までは不要です (それまではドライランです)。

作るもの

/22 の全ホストアドレスに対する ARP 要求 (「10.0.0.x は誰?」) を順に送るストリームと、同じスイープを複数の VLAN の中で繰り返すストリームです。ARP キャッシュを埋める、スイッチのブロードキャスト転送を確認する、といった用途に使えます。

同梱の 3 つのテンプレートを使います。

始める前に

wpg を一度ビルドし (Linux、macOS、Windows)、リポジトリのルートでコマンドを実行します。例ではバイナリを wpg と書いています。PATH に無い場合は ./target/release/wpg に読み替えてください。tshark は必須ではありませんが確認に役立ちます。

送信してよいのは、自分が所有する、または試験を許可されたネットワークだけです (法的注意)。

ステップ 1. 最小のスイープを読む

layers:
  - protocol: ethernet2
    fields:
      dst: ff:ff:ff:ff:ff:ff
      src: ${src_mac}

  - protocol: arp
    fields:
      oper: request
      sha: ${src_mac}
      spa: ${src_ip}
      tha: 00:00:00:00:00:00
    generators:
      tpa: ${first}-${last}   # range ジェネレータの短縮表記

generators.tpa がストリーム全体で ARP のターゲット IP を変化させます。${...} はテンプレート変数で、実行時に --var 名前=値 で上書きできます。Ethernet の ethertype は書いていません。Auto なので、次のレイヤが ARP であることから 0x0806 になります。

最初のフレームを表示します。

$ wpg template show templates/scenarios/vlan-arp-sweep.wpg.yaml
Hex dump (60 bytes)
0000  ff ff ff ff ff ff 02 00  00 00 00 01 81 00 00 64  ...............d
0010  08 06 00 01 08 00 06 04  00 01 02 00 00 00 00 01  ................
0020  0a 00 00 fa 00 00 00 00  00 00 0a 00 00 01 00 00  ................
0030  00 00 00 00 00 00 00 00  00 00 00 00              ................
...

末尾はゼロパディングです。ARP 要求は 42 オクテットですが、Ethernet のフレームは 60 オクテット必要です (FCS は NIC が付けます)。

ステップ 2. /22 全体をスイープする

arp-sweep-slash22.wpg.yaml は、変数に入れた CIDR ブロックをジェネレータにします。

variables:
  - name: net
    default: 10.0.0.0/22
layers:
  - protocol: arp
    generators:
      tpa: ${net}

CIDR ジェネレータはホストアドレスだけを返すので、/22 では 1022 フレーム (10.0.0.1 から 10.0.3.254) になります。ネットワークには触れず pcapng に書き出します。

$ wpg render templates/scenarios/arp-sweep-slash22.wpg.yaml -o /tmp/sweep.pcapng
Wrote 1022 packets to /tmp/sweep.pcapng.

ファイルを編集せず別のサブネットにすることもできます。

$ wpg render templates/scenarios/arp-sweep-slash22.wpg.yaml -o /tmp/sweep.pcapng --var net=10.1.0.0/22

ステップ 3. 複数の VLAN で繰り返す

vlan-arp-sweep.wpg.yaml は 802.1Q タグを挿入し、ジェネレータをもう 1 つ追加します。

  - protocol: dot1q
    generators:
      vid: ${vids}          # 既定 100-103

  - protocol: arp
    generators:
      tpa: ${first}-${last} # 既定 10.0.0.1-10.0.0.254

stream:
  mode: nested
  order: [dot1q.vid, arp.tpa] # 遅い方から

ジェネレータが 2 つあるときは組み合わせ方を指定します。zip は同時に進め、product は直積、nested は順序を明示した直積です。ここでは VLAN が遅いループなので、VLAN 100 で 254 アドレス、次に VLAN 101、と続き、4 x 254 = 1016 フレームになります。リストで 2 つの VLAN に絞ることもできます。

$ wpg render templates/scenarios/vlan-arp-sweep.wpg.yaml -o /tmp/vlan-sweep.pcapng --var vids=100,200
Wrote 508 packets to /tmp/vlan-sweep.pcapng.

ステップ 4. フレームを確認する

$ tshark -r /tmp/vlan-sweep.pcapng -T fields -e vlan.id -e arp.dst.proto_ipv4 | sed -n '1p;254p;255p;$p'
100	10.0.0.1
100	10.0.0.254
200	10.0.0.1
200	10.0.0.254

テンプレートを編集したら wpg template lint を実行してください。未知のフィールド、範囲外の値、ジェネレータの書式誤りを送信前に検出できます。

ステップ 5. 送信する

まずファイル出力 (pcapfile。-i が出力パスになります) または破棄 (null) のバックエンドで予行演習します。

$ wpg send templates/scenarios/arp-sweep-slash22.wpg.yaml --backend null -i lo --rate 100kpps
Sending on lo via null: rate 100000pps, burst 1, 1022 packets, 1 worker(s), plan PreRender (...)
state      finished (stream exhausted)
packets    1022
bytes      61320

次にラボのインタフェースへ実際に送信します。生ソケットの送信には権限が必要です (権限設定)。wpg ifaces でインタフェースを確認し、バックエンドが拒否されたら wpg doctor を実行します。

$ wpg ifaces
$ wpg send templates/scenarios/vlan-arp-sweep.wpg.yaml -i eth1 --rate 2000pps

ストリームを 1 回送信して (1016 フレームを 2000 fps で約 0.5 秒) サマリを表示します。--count 10000 でスイープを繰り返し、--duration 30s で時間指定もできます。

ステップ 6. 結果を読む

• 試験対象の ARP/ネイバーテーブル (ip neigh、show ip arp) とスイッチの MAC テーブルを確認します (送信元 MAC 02:00:00:00:00:01 が使った VLAN に現れるはずです)。
• 同じセグメントの Linux ホストで tcpdump -e -n -i eth1 arp を実行すると、VLAN タグ付きの要求が見えます。
• スイープの送信元アドレスは架空の 10.0.0.250 です。応答を観測したいときは --var で src_mac と src_ip を変更します。

次のステップ

• ランダムな送信元や TCP オプションは VLAN タグ付き TCP SYN 大量送信。
• --rate や --duration、複数ワーカーは 負荷とレート制御。
• ジェネレータの種類は テンプレートスキーマ。

チュートリアル: VLAN タグ付き TCP SYN 大量送信

所要時間: 約 20 分。必要な権限: ステップ 5 までは不要です。

作るもの

802.1Q VLAN 内で、送信元アドレス・送信元ポート・初期シーケンス番号をランダムにした TCP SYN を 10 万個送るストリームです。一般的な SYN オプション (MSS、SACK-permitted、ウィンドウスケール) を付けます。多数のクライアントからファイアウォールやロードバランサ、コネクション追跡テーブルに負荷をかけ、SYN の扱いを観察する用途です。wpg はステートレスで、ハンドシェイクを完了させず SYN-ACK にも応答しません。

自分が所有する、または試験を許可されたラボ機器に対してのみ使用してください。

始める前に

wpg をビルドし、リポジトリのルートで実行します (Linux へのインストール)。使うテンプレートは templates/scenarios/vlan-syn-flood.wpg.yaml です。より小さい例として templates/examples/vlan-tcp-syn.wpg.yaml もあります。

ステップ 1. テンプレートを読む

layers:
  - protocol: ethernet2
    fields: { dst: ${dst_mac}, src: ${src_mac} }

  - protocol: dot1q                 # TPID 0x8100 は ethernet2 に自動で入る
    fields:
      vid: ${vid}

  - protocol: ipv4
    fields:
      dst: ${dst_ip}
      ttl: 64
      flags: df
    generators:
      src: { kind: random, min: 10.0.0.1, max: 10.255.255.254 }

  - protocol: tcp
    fields:
      dst_port: ${dst_port}
      flags: syn
      window: 64240
      options:
        - mss: 1460
        - sack_permitted
        - ws: 7
    generators:
      src_port: { kind: random, min: 1024, max: 65535 }
      seq: { kind: random, min: 0, max: 4294967295 }

stream:
  seed: 7
  count: 100000

tx:
  rate: 50kpps
  burst: 32

知っておくと良い点です。

• それ以外は何も書いていません。 IPv4 の ihl・total_length・protocol・header_checksum、TCP の data_offset と checksum (IPv4 疑似ヘッダ込み)、dot1q/Ethernet の EtherType はすべて Auto で、フレームごとに再計算されます。TCP オプション領域は 32 ビット境界まで自動でパディングされます。
• オプションは型付きです。 mss: 1460、sack_permitted、ws: 7、nop、timestamps: { tsval: 1000, tsecr: 0 } が組み込み名で、それ以外は { type: 99, data: "01 02" } と書けます。
• stream.seed でランダムを再現可能にします。 同じ seed なら、実行するたび、マシンが違っても同じ 10 万フレームになります。
• tx.rate と tx.burst は既定値で、wpg send --rate で上書きできます。

ステップ 2. 最初のフレームを見る

$ wpg render templates/scenarios/vlan-syn-flood.wpg.yaml -o /tmp/syn.pcapng --count 3
Wrote 3 packets to /tmp/syn.pcapng.
$ tshark -r /tmp/syn.pcapng -o tcp.check_checksum:TRUE
    1   0.000000 10.114.228.243 → 198.51.100.7 TCP 70 2311 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM WS=128
    2   0.000001 10.99.228.10 → 198.51.100.7 TCP 70 51321 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM WS=128
    3   0.000002 10.251.163.120 → 198.51.100.7 TCP 70 10483 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM WS=128

Wireshark はチェックサム不正を報告しません。(Seq=0 は Wireshark が表示する相対シーケンス番号で、実際の値はランダムです。) tshark -V -c 1 で ID: 100 の 802.1Q ヘッダも確認できます。

ステップ 3. ファイルを編集せずに宛先を変える

${...} はすべて変数で、既定値はファイル先頭の variables: にあります。コマンドラインで上書きします。

$ wpg render templates/scenarios/vlan-syn-flood.wpg.yaml -o /tmp/syn.pcapng \
      --var vid=200 --var dst_ip=203.0.113.9 --var dst_port=8443 --count 1000

MAC アドレスは --var src_mac=… と --var dst_mac=… で設定します。宛先 MAC は、送信インタフェースから見た試験対象 (ネクストホップ) の MAC にします。

ステップ 4. count・seed・事前レンダリング

ストリームの長さは固定 (stream.count: 100000) です。wpg send は小さなストリームをメモリに事前レンダリングし (既定のしきい値 256 MiB)、大きなものはその場で展開します。--plan prerender または --plan onthefly で強制できます。

ステップ 5. 送信する

まず予行演習をしてから、ラボのインタフェースに送信します (権限設定)。

$ wpg send templates/scenarios/vlan-syn-flood.wpg.yaml --backend null -i lo --rate 20kpps --count 5000
$ wpg send templates/scenarios/vlan-syn-flood.wpg.yaml -i eth1 --rate 50kpps \
      --var vid=200 --var dst_ip=203.0.113.9 --var dst_mac=00:11:22:33:44:55

最初のバーストで落ちる機器には、緩やかに上げていくのが有効です。--ramp-up 10s はレートをゼロから直線的に上げます。詳しくは 負荷とレート制御 を参照してください。

ステップ 6. 結果を読む

• ファイアウォールやロードバランサの接続数・SYN カウンタ (show conn count、conntrack -C、SYN cookie カウンタ) を見ます。
• Linux の対象機器では nstat -az TcpExtTCPReqQFullDoCookies と ss -s で SYN キューの挙動が分かります。
• 送信側では、wpg send 終了時のサマリに packets・bytes・dropped と、目標に対する達成レートが出ます。

次のステップ

• flags: syn を syn|ack、rst、fin|ack に変えると、ステートフル機器が状態外のセグメントをどう扱うかを試せます。
• 宛先ポート 1-1024 を走査するには templates/scenarios/tcp-syn-port-scan.wpg.yaml を使います。
• 実際のキャプチャを編集できるテンプレートにするには pcap からテンプレートへ変換して再生 を参照してください。

チュートリアル: IPv6 と近隣探索 (NDP)

所要時間: 約 25 分。必要な権限: ステップ 6 までは不要です。

このページでは、型・長さ・チェックサムが互いに導出される複数レイヤと、ネットワーク層アドレスから計算するリンク層マルチキャストアドレスを、IPv6 スタックで練習します。IP を使わない OSI 系のスタック (LLC 上の IS-IS) は IS-IS Hello で隣接を Up にする で扱います。

作るもの

IPv6 のリンク上の動作を支える近隣探索メッセージと、近隣要請のスイープです。

始める前に

wpg をビルドし、リポジトリのルートで実行します。送信してよいのは自分が所有する、または試験を許可されたラボだけです。偽の RA はセグメント上の全ホストを混乱させる可能性があります。

ステップ 1. 近隣要請 1 個のレイヤをたどる

$ wpg template show templates/protocols/l3/ndp-ns.wpg.yaml
Hex dump (86 bytes)
0000  33 33 ff 00 00 02 02 00  00 00 00 01 86 dd 60 00  33............`.
0010  00 00 00 20 3a ff 20 01  0d b8 00 00 00 00 00 00  ... :. .........
...
Layout
[0] ethernet2  bytes 0..86
  dst: 33:33:ff:00:00:02
  src: 02:00:00:00:00:01
  ethertype: 0x86dd (ipv6)  (auto)
[1] ipv6  bytes 14..86
  payload_length: 32  (auto)
  next_header: 0x3a (icmpv6)  (auto)
  hop_limit: 255
  src: 2001:db8::1
  dst: ff02::1:ff00:2
[2] icmpv6  bytes 54..86
  type: 0x87 (neighbor_solicitation)  (auto)
  code: 0
  checksum: 7207  (auto)
[3] ndp_ns  bytes 58..86
  reserved: 0
  target: 2001:db8::2
  options: 01 01 02 00 00 00 00 01

(auto) の値はすべて、入力ではなく導出されたものです。

• ethernet2.ethertype = 0x86dd: 次のレイヤが ipv6 だからです。
• ipv6.next_header = 58: 次のレイヤが icmpv6 だからです。payload_length は 40 オクテットのヘッダ以降すべてを数えます。
• icmpv6.type = 135: 次のレイヤが ndp_ns だからです。ICMPv6 メッセージは意図的に 2 つのレイヤに分かれています。icmpv6 が type・code・checksum を持ち、本体レイヤ (ndp_ns、ndp_na、ndp_rs、ndp_ra、ndp_redirect、icmpv6_echo) が type を決めます。
• icmpv6.checksum は IPv6 疑似ヘッダ、ICMPv6 ヘッダ、本体全体にかかるため、下位のどのフィールドを変えても変わります。

元の YAML は短いものです。

layers:
  - protocol: ethernet2
    fields: { dst: "33:33:ff:00:00:02", src: "02:00:00:00:00:01" }
  - protocol: ipv6
    fields:
      src: 2001:db8::1
      dst: ff02::1:ff00:2
      hop_limit: 255          # NDP は 255 が必須
  - protocol: icmpv6          # type: auto
  - protocol: ndp_ns
    fields:
      target: ${target}
      options: "01 01 02 00 00 00 00 01"   # 送信元リンク層アドレス

ステップ 2. 一致させるべき 2 つのアドレス

2001:db8::2 の近隣要請は、被請求ノードマルチキャストグループ ff02::1:ff00:2 (ff02::1:ff にターゲットの下位 24 ビット) 宛てに、Ethernet ではマルチキャスト MAC 33:33: に IPv6 宛先の下位 32 ビットを付けた 33:33:ff:00:00:02 宛てに送ります。wpg は一方から他方を導出しないので、target を変えたら ipv6.dst と ethernet2.dst も変える必要があります (スイープのように全ノード宛て ff02::1 / 33:33:00:00:00:01 に送る方法もあります)。

hop_limit: 255 にも注意してください。受信側は他の値の NDP メッセージを破棄するため、既定の 64 のままだと Wireshark では正しく見えるのに何も起きないパケットになります。

ステップ 3. オプションは生のバイト列

NDP オプション (options) は 16 進で書きます。01 01 02 00 00 00 00 01 は、タイプ 1 (送信元リンク層アドレス)、長さ 1 (8 オクテット単位)、続いて 6 オクテットの MAC です。ルータ通知のテンプレートは 3 つのオプションを連結しています。

options: >-
  01 01 02 00 00 00 00 01
  05 01 00 00 00 00 05 dc
  03 04 40 c0 00 27 8d 00 00 09 3a 80 00 00 00 00
  20 01 0d b8 00 01 00 00 00 00 00 00 00 00 00 00

オプションは生のオクテットなので、長さ 0 のオプションやパケット末尾を越えるオプション、未知のタイプなど、わざと変なものも作れます。

ステップ 4. Wireshark で確認する

$ wpg render templates/protocols/l3/ndp-ns.wpg.yaml -o /tmp/ns.pcapng
$ tshark -r /tmp/ns.pcapng -V | sed -n '/Internet Control/,$p'
Internet Control Message Protocol v6
    Type: Neighbor Solicitation (135)
    Code: 0
    Checksum: 0x1c27 [correct]
    [Checksum Status: Good]
    Reserved: 00000000
    Target Address: 2001:db8::2
    ICMPv6 Option (Source link-layer address : 02:00:00:00:00:01)

重要なのは [correct] です。疑似ヘッダ込みのチェックサムを wpg が自分で計算しています。

ステップ 5. スイープする

ndp-ns-sweep.wpg.yaml は target ジェネレータに IPv6 の範囲を指定します。

  - protocol: ndp_ns
    generators:
      target: 2001:db8::1-2001:db8::100

$ wpg render templates/scenarios/ndp-ns-sweep.wpg.yaml -o /tmp/ns-sweep.pcapng
Wrote 256 packets to /tmp/ns-sweep.pcapng.

宛先は全ノードグループなので、セグメント上の全ホストが 256 個すべてを受け取り、自分のアドレス分にだけ応答します。実際のホストはターゲットごとの被請求ノードグループに送りますが、スイープでは単純な 1 テンプレートにするためそれを省いています。

ra-flood.wpg.yaml は、送信元 MAC (OUI 固定の random_mac) と送信元リンクローカルアドレスにランダムジェネレータを使う例で、どちらも stream.seed で再現できます。

ステップ 6. 送信する

$ wpg send templates/scenarios/ndp-ns-sweep.wpg.yaml --backend null -i lo --rate 1000pps
$ wpg send templates/scenarios/ndp-ns-sweep.wpg.yaml -i eth1 --rate 1000pps

(権限は 権限設定 を参照。) 対象機器では ip -6 neigh や show ipv6 neighbors で学習結果を、別ホストの tcpdump -n -i eth1 icmp6 で要請と通知を確認できます。

その他の ICMPv6 タイプ

本体プロトコルがまだ無いタイプ (たとえば MLD) は、icmpv6.type を明示的に設定し、チェックサム以降の 4 オクテットとメッセージを含む raw レイヤを続けます。IPv6 拡張ヘッダの連鎖は専用のサンプルがあります: templates/protocols/l3/ の ipv6-hopopts、ipv6-dstopts、ipv6-routing、ipv6-frag、ipv6-ext-chain です。

次のステップ

• RA フラッドを指定レートで送るには 負荷とレート制御。
• IPv6/ICMPv6 の全フィールドは プロトコルリファレンス。

チュートリアル: 負荷とレート制御

所要時間: 約 20 分。必要な権限: なし (全体を通して null と pcapfile バックエンドを使います)。

ここで扱う技術 (大量生成、レート、時間、ランプアップ、ワーカー) はどのテンプレートでも使えます。実際のサーバに負荷をかけて応答を数える例は DHCP サーバの負荷試験 にあります。

作るもの

テンプレートを指定のレートと時間で送出し、返ってくるサマリを読み、ラボの制限内に収めるためのコマンド群です。題材は MAC フラッド (templates/scenarios/mac-flood.wpg.yaml、ランダムな送信元 MAC の 10 万フレーム) と SYN フラッド (templates/scenarios/vlan-syn-flood.wpg.yaml) です。

始める前に

wpg をビルドし、リポジトリのルートで実行します。実際の送信には権限とラボのインタフェースが必要ですが、このチュートリアルは --backend null (フレームを作って数えるだけで送らない) を使うので、どこでも実行できます。実際に送るときは --backend null -i lo を -i eth1 などに置き換えます。

負荷をかけてよいのは、自分が所有する、または試験を許可された機器だけです。

ステップ 1. 回数・時間・レート

停止条件と速度はテンプレートの tx: にあり、コマンドラインで上書きできます。

回数と時間の両方を指定した場合は先に達した方で終了します。bps 指定はレイヤ 1 のバイト数 (プリアンブル、FCS、フレーム間ギャップ込み) で数えます。% はリンク速度が分かる実インタフェースが必要です (lo では失敗します)。

$ wpg send templates/scenarios/udp-qos-matrix.wpg.yaml --backend null -i lo --rate 250kpps --count 50000
Sending on lo via null: rate 250000pps, burst 1, 50000 packets, 1 worker(s), plan PreRender (...)
state      finished (count reached)
backend    null
packets    50000
bytes      10100000
dropped    0
elapsed    0.200 s
average    250.00 kpps  404.00 Mbps (L2)  452.00 Mbps (L1)
accuracy   target 250.00 kpps  achieved 100.00%  max jitter 454.12µs  mean jitter 202ns

(数値は環境によって異なります。) まず最後の 2 行を読みます。average は実際に送れたレート、accuracy は目標にどれだけ近く送れたかです。dropped が大きいときは、バックエンドが追い付いていません。

ステップ 2. ランプアップ

最初のバーストで落ちる機器は、レートを上げていくと特性を調べやすくなります。--ramp-up はレートをゼロから目標まで指定時間で直線的に上げます。

$ wpg send templates/scenarios/vlan-syn-flood.wpg.yaml --backend null -i lo --rate 20kpps --ramp-up 1s --duration 3s
[    3.0 s]        50023 pkts  16.67 kpps  9.34 Mbps  dropped 0  rate 100.0%
state      finished (duration elapsed)
packets    50023
elapsed    3.000 s
average    16.67 kpps  9.34 Mbps (L2)  12.54 Mbps (L1)
accuracy   target 20.00 kpps  achieved 100.04%  max jitter 3.196862ms  mean jitter 115.686µs

最初の 1 秒がランプなので、平均 (16.67 kpps) は目標 20 kpps を下回ります。

ステップ 3. 開始時刻を指定する

--start-at は最初のフレームの前に待ちます。遅延 (+10s) か RFC 3339 の時刻 (2026-09-29T12:00:00Z) を指定します。複数の送信側を同時に始めたいときや、キャプチャを起動する時間が欲しいときに便利です。

$ wpg send templates/scenarios/vlan-syn-flood.wpg.yaml --backend null -i lo --start-at +2s --count 10
Scheduled start at +2s (in 2.0 s); Ctrl-C cancels.

ステップ 4. 複数ワーカーを使う

ワーカー 1 つは CPU コア 1 つが上限です。--workers N は N 本の送信スレッドを起動し、それぞれが独立したバックエンドインスタンスと、ストリームおよびレートの分担を持ちます。--pin-cores 2,3 でコアに固定できます (Linux)。

$ wpg send templates/scenarios/vlan-syn-flood.wpg.yaml --backend null -i lo --rate unlimited --count 100000 --workers 2
average    10.35 Mpps  5.79 Gbps (L2)  7.78 Gbps (L1)
worker 0     50000 pkts  3500000 bytes
worker 1     50000 pkts  3500000 bytes

null バックエンドでの unlimited は、フレームを作る速さの測定であり、ネットワークの数値ではありません。afpacket バックエンドでは --batch、--ring-depth、--qdisc-bypass、--no-tx-ring も使えます (wpg send --help)。詳しくは 性能チューニング を参照してください。

ステップ 5. 事前レンダリングかその場生成か

--plan auto (既定) は、ストリームが小さければ (しきい値 256 MiB) メモリに事前レンダリングして送信ループではバイトのコピーだけを行い、大きければその場で展開します。--plan prerender または --plan onthefly で強制できます。ランダムジェネレータの値は stream.seed から決まるので、再現性が必要なら seed を指定してください。

ステップ 6. 機械可読な結果

--json は最終レポートを JSON で標準出力に出します (進捗とバナーは標準エラー)。CI やスクリプト向けです。

$ wpg send templates/scenarios/mac-flood.wpg.yaml --backend null -i lo --count 100000 --json | jq '{state: .state.state, packets: .backend.packets, dropped: .backend.dropped}'

実行に失敗したとき (たとえばバックエンドが拒否された) は終了コードが 0 以外になるので、wpg send はパイプラインの 1 ステップにできます。

ステップ 7. 制限内に収める

• wpg.toml の [tx] max_rate (例: max_rate = "100kpps") で全員に対する上限を設定し、allowed_ifaces で使えるインタフェースを制限します。設定リファレンス を参照してください。
• Ctrl-C で実行をキャンセルできます。
• 新しいテンプレートは、毎回予行演習用のバックエンド (null、または -i out.pcapng を指定した pcapfile) で試してから送ります。

次のステップ

• 実ネットワークで記録したトラフィックで機器に負荷をかけるには pcap からテンプレートへ変換して再生。
• バックエンドごとの調整は 性能チューニング。

チュートリアル: pcap からテンプレートへ変換して再生

所要時間: 約 20 分。必要な権限: 最後のステップまで不要です。

作るもの

キャプチャ (ここでは再現しやすいよう wpg で作りますが、Ethernet の pcap/pcapng なら何でも構いません) を編集可能なテンプレートに変換し、元と同じバイト列に戻す往復です。途中で wpg は、パケット間で変化するフィールドを見つけてジェネレータにします。

wpg import は pcap (両バイトオーダー、マイクロ秒/ナノ秒) と pcapng を読みます。リンク層は Ethernet のみで、フレームに FCS は付いていない前提です。貼り付けた 16 進も読めます。

始める前に

wpg をビルドし、リポジトリのルートで実行します。tshark は確認にだけ使います。

ステップ 1. キャプチャを作る

$ wpg render templates/examples/arp-sweep.wpg.yaml -o /tmp/arp.pcapng
Wrote 254 packets to /tmp/arp.pcapng.

実際には tcpdump -i eth0 -w capture.pcap や Wireshark で取得したファイルを使います。

ステップ 2. インポートする

$ wpg import /tmp/arp.pcapng -o /tmp/arp.wpg.yaml
Imported 254 packet(s) into 1 template(s): /tmp/arp.wpg.yaml

結果は次のとおりです。

schema: 1
meta:
  name: arp
  description: Imported from /tmp/arp.pcapng (254 packets)
  ...
  tags:
  - imported
layers:
- protocol: ethernet2
  fields:
    dst: ff:ff:ff:ff:ff:ff
    src: 02:00:00:00:00:01
    ethertype: auto
- protocol: arp
  fields:
    htype: ethernet
    ptype: ipv4
    hlen: 6
    plen: 4
    oper: request
    sha: 02:00:00:00:00:01
    spa: 192.168.1.10
    tha: 00:00:00:00:00:00
  generators:
    tpa:
      kind: range
      start: 192.168.1.1
      end: 192.168.1.254
      step: 1
- protocol: raw
  fields:
    data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
stream:
  mode: zip
  count: 254

3 つのことが起きています。

1. フィールドは人間向け表記 (192.168.1.10、request、ethernet) になり、wpg が再計算できるフィールドは、そうしても取り込んだバイト列が再現できる場合に限り auto に戻されます。チェックサムや長さが誤ったキャプチャでは、そのフィールドが手動値のまま残るので、わざと壊したトラフィックも失われません。
2. ジェネレータ推定。 254 フレームすべてが同じレイヤ構成で、arp.tpa が毎回 +1 なので、(厳密な) range ジェネレータになりました。周期的な繰り返しは list、少数の値の集合は近似の list、それ以外は観測した最小/最大の random になります (近似のときは警告が出ます)。--no-detect-generators で先頭パケットの値だけを使うこともできます。
3. ARP の後ろの 0 が 18 オクテット は、キャプチャに含まれていた Ethernet のパディングです。インポータはプロトコルに帰属できないバイトを raw レイヤに残し、フレームを正確に再現します。このレイヤは削除して構いません。packet.pad_to_min (既定) で wpg が自分でパディングします。

ステップ 3. lint して再レンダリングする

$ wpg template lint /tmp/arp.wpg.yaml
/tmp/arp.wpg.yaml: no issues
0 error(s), 0 warning(s) in 1 file(s)
$ wpg render /tmp/arp.wpg.yaml -o /tmp/arp2.pcapng
Wrote 254 packets to /tmp/arp2.pcapng.
$ diff <(tshark -r /tmp/arp.pcapng -x) <(tshark -r /tmp/arp2.pcapng -x) && echo identical
identical

フレームはバイト単位で一致します (タイムスタンプは wpg が独自に付けるので異なります)。

ステップ 4. 編集して再利用する

テンプレートになったので、何でも変更できます。

• 定数を変数にする: 192.168.1.10 を ${src_ip} に置き換え、variables: [{ name: src_ip, default: 192.168.1.10 }] を追加して、wpg render … --var src_ip=10.9.8.7 を実行します。
• スイープを広げる: range を 192.168.0.1-192.168.7.254 に変更します。
• oper: reply にするとキャプチャを応答に変えられます。
• packet: { fcs: bad } を加えると、不正な FCS を機器がどう扱うか試せます。

ステップ 5. パケットごとのテンプレート、貼り付けた 16 進

スイープではなく会話のキャプチャなら、パケットごとに 1 テンプレートを作らせます。

$ wpg import /tmp/capture.pcap --per-packet /tmp/templates/

Wireshark の「Copy → as a Hex Stream」、xxd/hexdump -C の出力、空白区切りのバイト列はパイプで渡せます。

$ echo "ff ff ff ff ff ff 02 00 00 00 00 01 08 06 00 01 08 00 06 04 00 01 02 00 00 00 00 01 c0 00 02 01 00 00 00 00 00 00 c0 00 02 02" \
    | wpg import --hex - -o -

Ethernet II 以外で始まるキャプチャには --first-protocol を使います。wpg が知らないプロトコルのフレームは、デコードできた最後のレイヤの後ろに raw バイト列として残るので、再生はできます。

ステップ 6. 共有と再生

テンプレートと元のキャプチャを、同僚がインポートできるバンドルにまとめます。

$ wpg template export /tmp/arp.wpg.yaml -o /tmp/arp.wpgbundle --attach /tmp/arp.pcapng
$ wpg template import /tmp/arp.wpgbundle -o ./my-templates

ほかのテンプレートと同様に、好きなレートで送信します。

$ wpg send /tmp/arp.wpg.yaml -i eth1 --rate 500pps

オプションは 負荷とレート制御 を参照してください。

次のステップ

• ファイルに書ける内容は テンプレートスキーマ。
• ARP スイープ、VLAN タグ付き TCP SYN 大量送信、IPv6 と近隣探索 (NDP)。

チュートリアル: DHCP サーバの負荷試験

所要時間: 約 25 分。必要な権限: ステップ 3 まで不要、ステップ 4 から root (名前空間と afpacket)。

作るもの

多数のクライアントを装って DHCPDISCOVER を送り、DHCP サーバが返す DHCPOFFER を数えて、サーバがどのレートまで追従できるかを調べます。1 フレームごとに送信元 MAC と chaddr (クライアントのハードウェアアドレス) を揃えて変え、トランザクション ID (xid) をランダムにします。サーバには、1 台の Linux 上の名前空間で動かす dnsmasq を使います。

wpg はステートレスです。OFFER を受け取っても DHCPREQUEST は返さないので、DORA (Discover / Offer / Request / Ack) は完了せず、リースも作られません。測れるのは DISCOVER の処理能力で、アドレスプールの枯渇試験ではありません (ステップ 6)。

自分が所有する、または試験を許可された DHCP サーバに対してのみ使用してください。本番セグメントに DISCOVER を大量に流すと、本物のクライアントがアドレスを取れなくなることがあります。

始める前に

wpg をビルドし、リポジトリのルートで実行します (Linux へのインストール)。使うテンプレートは templates/scenarios/dhcp-discover-flood.wpg.yaml です。1 フレームだけの例として templates/protocols/app/dhcpv4-discover.wpg.yaml もあります。ステップ 4 以降は Linux、iproute2、dnsmasq (sudo apt install dnsmasq-base) と root が必要です。

ステップ 1. テンプレートを読む

variables:
  - name: oui
    default: "02:00:5e"

layers:
  - protocol: ethernet2
    fields:
      dst: "ff:ff:ff:ff:ff:ff"
    generators:
      src: { kind: range, start: "${oui}:00:00:01", end: "${oui}:ff:ff:ff" } # one MAC per client
  - protocol: ipv4
    fields:
      src: 0.0.0.0
      dst: 255.255.255.255
  - protocol: udp
    fields:
      src_port: 68
      dst_port: 67
  - protocol: dhcpv4
    fields:
      op: boot_request
      flags: broadcast
      options:
        - { message_type: discover }
        - { parameter_request_list: [1, 3, 6, 15, 51] } # mask, router, DNS, domain, lease
        - end
    generators:
      chaddr: { kind: expr, expr: "$0.src" } # the same MAC as the Ethernet source (layer 0)
      xid: { kind: expr, expr: "rand(0, 0xffffffff)" }

stream:
  seed: 1
  count: 10000

tx:
  rate: 200pps

知っておくと良い点です。

• 送信元 MAC は連番です。 range は MAC アドレスにも使え、02:00:5e:00:00:01 から 1 ずつ増えます。先頭オクテットの 02 はローカル管理アドレスで、実在の機器と重なりません。--var oui=… で上位 3 オクテットを変えられます。
• chaddr は式で送信元 MAC を写します。 expr ジェネレータの $0.src は「レイヤ 0 (ethernet2) の src ジェネレータの、このフレームでの値」です。サーバはふつう chaddr でクライアントを識別するので、2 つがずれると試験になりません。式の書き方は テンプレートスキーマ を参照してください。
• xid はフレームごとのランダム値です。 rand(min, max) はフレーム番号から決まる乱数で、stream.seed が同じなら何度実行しても同じ値になります。
• 書いていないフィールドは Auto か既定値です。 IPv4 の長さとチェックサム、UDP の長さとチェックサム (疑似ヘッダ込み) は Auto で、DHCP の htype / hlen、sname と file のゼロ埋め、マジッククッキーは既定値で入ります。

ステップ 2. 最初のフレームを見る

$ wpg render templates/scenarios/dhcp-discover-flood.wpg.yaml -o /tmp/dhcp.pcapng --count 3
Wrote 3 packets to /tmp/dhcp.pcapng.
$ tshark -r /tmp/dhcp.pcapng
    1   0.000000      0.0.0.0 → 255.255.255.255 DHCP 293 DHCP Discover - Transaction ID 0xc4c98940
    2   0.000001      0.0.0.0 → 255.255.255.255 DHCP 293 DHCP Discover - Transaction ID 0xef7b0650
    3   0.000002      0.0.0.0 → 255.255.255.255 DHCP 293 DHCP Discover - Transaction ID 0x330355d7
$ tshark -r /tmp/dhcp.pcapng -o udp.check_checksum:TRUE -T fields -e eth.src -e dhcp.hw.mac_addr -e udp.checksum.status
02:00:5e:00:00:01	02:00:5e:00:00:01	1
02:00:5e:00:00:02	02:00:5e:00:00:02	1
02:00:5e:00:00:03	02:00:5e:00:00:03	1

送信元 MAC と Client MAC address が一致し、UDP チェックサムは正しい (1 = Good) と判定されます。1 万フレーム全体でも確かめられます。

$ wpg render templates/scenarios/dhcp-discover-flood.wpg.yaml -o /tmp/dhcp-all.pcapng
Wrote 10000 packets to /tmp/dhcp-all.pcapng.
$ tshark -r /tmp/dhcp-all.pcapng -Y 'eth.src != dhcp.hw.mac_addr' | wc -l
0

ステップ 3. 規模を変える

クライアント数は --count で決まります (stream.count の 1 万を超えると MAC の連番が先頭に戻るので、それ以上は --var oui=… を変えた 2 本目のストリームにします)。

$ wpg render templates/scenarios/dhcp-discover-flood.wpg.yaml -o /tmp/dhcp-b.pcapng --var oui=02:00:5f
Wrote 10000 packets to /tmp/dhcp-b.pcapng.

このファイルの送信元 MAC は 02:00:5f:00:00:01 から 02:00:5f:00:27:10 (10000 = 0x2710) です。

ステップ 4. 試験用の DHCP サーバを用意する

名前空間 wpgdhcp に dnsmasq を起動し、veth (dh0 ⇔ dhs0) で wpg とつなぎます。プールは 50 アドレスです。

sudo ip netns add wpgdhcp
sudo ip link add dh0 type veth peer name dhs0
sudo ip link set dhs0 netns wpgdhcp
sudo ip link set dh0 up
sudo ip netns exec wpgdhcp ip link set lo up
sudo ip netns exec wpgdhcp ip link set dhs0 up
sudo ip netns exec wpgdhcp ip addr add 10.98.0.1/24 dev dhs0
sudo ip netns exec wpgdhcp dnsmasq --no-daemon --port=0 --interface=dhs0 --bind-interfaces \
    --dhcp-range=10.98.0.10,10.98.0.59,10m --dhcp-authoritative --dhcp-leasefile=/tmp/wpg-leases \
    --log-dhcp --log-facility=/tmp/wpg-dnsmasq.log &

--port=0 は DNS を無効にします。実機の DHCP サーバやルータを試験する場合は、dh0 の代わりにそのサーバにつながるラボのインタフェースを使います。

ステップ 5. 送って OFFER を数える

OFFER (送信元ポート 67) を wpg capture で数えながら、別の端末から DISCOVER を 100 個送ります。

$ sudo wpg capture -i dh0 -f "udp src port 67" --duration 3s --show 2 -w /tmp/offers.pcapng
$ sudo wpg send templates/scenarios/dhcp-discover-flood.wpg.yaml -i dh0 --backend afpacket --count 100

Capturing on dh0 via afpacket, filter udp src port 67 (Ctrl-C stops)
#   0  16:14:33.696984775    342 B  ethernet2 / ipv4 / udp / dhcpv4
#   1  16:14:33.703225873    342 B  ethernet2 / ipv4 / udp / dhcpv4
state      finished (duration elapsed)
...
matched    100 pkts  34200 bytes
saved      100 pkts to /tmp/offers.pcapng
$ tshark -r /tmp/offers.pcapng -c 3
    1   0.000000    10.98.0.1 → 255.255.255.255 DHCP 342 DHCP Offer    - Transaction ID 0xc4c98940
    2   0.006241    10.98.0.1 → 255.255.255.255 DHCP 342 DHCP Offer    - Transaction ID 0xef7b0650
    3   0.009784    10.98.0.1 → 255.255.255.255 DHCP 342 DHCP Offer    - Transaction ID 0x330355d7

OFFER の xid は DISCOVER のもの (ステップ 2) と一致します。broadcast フラグを立てているので、OFFER は 255.255.255.255 宛てに返ります。

最初はとても遅く見えるはずです。 dnsmasq の既定の設定では、OFFER の前にそのアドレスへ ICMP Echo を送って使われていないことを確かめるため、DISCOVER 1 件に約 3 秒かかり、3 秒の捕捉では 1 件しか数えられません (ログ /tmp/wpg-dnsmasq.log に 3 秒おきの DHCPOFFER が並びます)。上の結果は dnsmasq に --no-ping を付けて起動し直したものです。このような「サーバ側の作りで決まる上限」を見つけることが、この種の試験の目的の 1 つです。

次にレートを上げて、OFFER が DISCOVER に追い付かなくなる点を探します。

for r in 1kpps 5kpps 20kpps; do
  sudo wpg capture -i dh0 -f "udp src port 67" --duration 4s --show 0 > /tmp/cap-$r.txt &
  sudo wpg send templates/scenarios/dhcp-discover-flood.wpg.yaml -i dh0 --backend afpacket --count 2000 --rate $r
  wait; grep '^matched' /tmp/cap-$r.txt
done

開発用コンテナ (--no-ping) での結果です。値はホストとサーバ次第です。

応答率が下がり始めるレートが、このサーバの DISCOVER 処理能力の目安です。応答しなかった DISCOVER は、サーバのソケットの受信バッファで捨てられています。実機では、DHCP スヌーピングや CoPP (制御プレーンのポリシング) が先に落とすこともあります。その場合はスイッチやルータのカウンタも確認してください。

ステップ 6. 結果を読む

• OFFER はアドレスを予約しません。 プールは 50 アドレスですが、100 個の DISCOVER すべてに OFFER が返り、提示されたアドレスは 50 種類でした (tshark -r /tmp/offers.pcapng -T fields -e dhcp.ip.your | sort -u | wc -l)。dnsmasq をはじめ多くのサーバは REQUEST / ACK でリースを作るので、DISCOVER だけではプールは枯渇しません。リース ファイル (/tmp/wpg-leases) も空のままです。
• リースまで作る試験は wpg の対象外です。 OFFER を受けて REQUEST を返すのはステートフルな処理で、wpg の非ゴールです。プールの枯渇やリース保持の試験には、DHCP クライアントのエミュレータ (perfdhcp など) を使ってください。
• リレー経由の試験には templates/protocols/app/dhcpv4-relay.wpg.yaml (giaddr とオプション 82 付き、ユニキャスト) を元にします。宛先をサーバのアドレスにすれば、ルーティングされた先のサーバを試験できます。
• DHCPv6 には templates/protocols/app/dhcpv6-solicit.wpg.yaml と dhcpv6-relay-forward.wpg.yaml があります。

後片付け:

sudo pkill -f 'dnsmasq --no-daemon --port=0 --interface=dhs0'
sudo ip netns del wpgdhcp      # dh0 も一緒に消えます

次のステップ

• --rate の代わりに --ramp-up 30s を付けると、レートを直線的に上げながら応答率の落ち始めを探せます。詳しくは 負荷とレート制御。
• GUI では、テンプレート画面でこのシナリオを開いてジョブから送出し、受信画面 (/rx) でフィルタ udp src port 67 を指定して OFFER を数えられます (受信と検証)。

チュートリアル: IS-IS Hello で隣接を Up にする

所要時間: 約 30 分。必要な権限: ステップ 2 まで不要、ステップ 3 から root (名前空間と afpacket)。

作るもの

IS-IS のレベル 2 LAN Hello (IIH) を組み立てて FRR の isisd に送り、相手側で隣接が Initializing から Up になるまでを追います。題材は相互接続確認用のテンプレート templates/interop/isis-l2-lan-hello-up.wpg.yaml です。Ethernet の上に LLC (0xfe) と IS-IS が直接載る、IP を使わない OSI 系のスタックで、PDU 長、MTU までのパディング、IS Neighbors TLV による双方向確認を順に見ます。

wpg はステートレスです。Hello を送り続ければ隣接は維持されますが、LSP のフラッディングや DIS としての振る舞いはしません。

自分が所有する、または試験を許可されたルータに対してのみ使用してください。運用中の IS-IS ドメインに偽の隣接を作ると、経路計算に影響することがあります。

始める前に

wpg をビルドし、リポジトリのルートで実行します (Linux へのインストール)。ステップ 3 以降は Linux、iproute2、FRR (sudo apt install frr。デーモンはスクリプトが直接起動するので、frr サービスは止めたままで構いません) と root が必要です。IS-IS の PDU と TLV の一覧は IS-IS (P2) にあります。

ステップ 1. テンプレートを読む

layers:
  - protocol: dot3
    fields:
      dst: "01:80:c2:00:00:15" # AllL2ISs
      src: ${src_mac}
      length: auto
  - protocol: llc
  - protocol: isis_l2_lan_hello
    fields:
      circuit_type: l2
      source_id: ${system_id}
      holding_time: 30
      priority: 0 # wpg does not flood LSPs, so let the peer be the DIS
      lan_id: "0000 0000 0001 01" # overwritten by the DIS's LAN ID once the peer elects itself
      # Manual PDU length: Padding TLVs fill the PDU up to it (MTU 1500 - LLC 3).
      pdu_length: 1497
      tlvs:
        - { protocols_supported: [ipv4] }
        - { area_addresses: [{ address: "${area}" }] }
        - { ip_interface_addresses: ["${ip}"] }
        - { is_neighbors: ["${peer_mac}"] }

tx:
  count: 40 # two minutes of Hellos
  rate: ifg=3s

知っておくと良い点です。

• IS-IS は IP を使いません。 dot3 (長さフィールド付きの 802.3) の上に llc を置くと、DSAP / SSAP は 0xfe (OSI) に自動で決まります。IS-IS の NLPID 0x83 も PDU レイヤから自動で入ります。宛先 01:80:c2:00:00:15 はレベル 2 の全 IS 宛て (AllL2ISs) です。
• pdu_length を Manual にするとパディングが付きます。 Auto のままなら PDU は TLV の分だけの長さです。値を書くと、PDU がちょうどその長さになるまで Padding TLV (種別 8) が自動で足されます。1497 は Ethernet の MTU 1500 から LLC ヘッダ 3 オクテットを引いた値です。相手は、Hello がこの大きさで届くことで MTU が一致していると判断します。
• is_neighbors が双方向確認の鍵です。 LAN の隣接は、相手の Hello に自分の MAC (SNPA) が載っているのを見て初めて Up になります。peer_mac には相手インタフェースの MAC を入れます。
• priority: 0 で DIS (代表 IS) の選出に負けるようにしています。wpg は DIS の仕事 (CSNP の送出や疑似ノード LSP) をしないためです。
• System ID (source_id) は 6 オクテット、エリアアドレスは NSAP の表記 (49.0001) で書きます。

ステップ 2. フレームを見る

$ wpg render templates/interop/isis-l2-lan-hello-up.wpg.yaml -o /tmp/isis.pcapng --count 1
Wrote 1 packets to /tmp/isis.pcapng.
$ tshark -r /tmp/isis.pcapng
    1   0.000000 02:00:00:00:00:01 → ISIS-all-level-2-IS's ISIS HELLO 1514 L2 HELLO, System-ID: 0000.0000.0001
$ tshark -r /tmp/isis.pcapng -V
...
ISIS HELLO
    .... ..10 = Circuit type: Level 2 only (0x2)
    SystemID {Sender of PDU}: 0000.0000.0001
    Holding timer: 30
    PDU length: 1497
    .000 0000 = Priority: 0
    SystemID {Designated IS}: 0000.0000.0001.01
    Protocols Supported (t=129, l=1)
    Area address(es) (t=1, l=4)
        Area address (3): 49.0001
    IP Interface address(es) (t=132, l=4)
        IPv4 interface address: 10.99.0.1
    IS Neighbor(s) (t=6, l=6)
        IS Neighbor: 02:00:00:00:00:02 (02:00:00:00:00:02)
    Padding (t=8, l=255)
    Padding (t=8, l=255)
    Padding (t=8, l=255)
    Padding (t=8, l=255)
    Padding (t=8, l=255)
    Padding (t=8, l=160)

(-V の出力は抜粋です。) フレームは 1514 オクテット (MTU 1500 + Ethernet ヘッダ 14) です。PDU 1497 オクテットの内訳は、ヘッダ 27、上の 4 つの TLV 23、Padding TLV 6 個 (255 オクテットが 5 個と 160 オクテットが 1 個、それぞれ種別と長さの 2 オクテットを加えて 1447) です。

ステップ 3. FRR のラボを用意する

scripts/interop/frr-netns.sh が、名前空間 wpgfrr に FRR を起動し、veth (wpg0 ⇔ frr0) で wpg とつなぎます。FRR 側の IS-IS は net 49.0001.0000.0000.0002.00、is-type level-2-only です。--keep を付けると、相互接続確認のあともラボが残ります。

$ cargo build --release -p wpg-cli
$ sudo scripts/interop/frr-netns.sh --keep target/release/wpg
...
PASS  IS-IS L2 adjacency Up
...
lab kept: ip netns exec wpgfrr vtysh -N wpg; tear down with scripts/interop/frr-netns.sh --down

スクリプト自身の確認で隣接が一度 Up になっています。最後の Hello から保持時間 (30 秒) が過ぎて消えるまで待ってから先に進みます。

$ sudo ip netns exec wpgfrr vtysh -N wpg -c "show isis neighbor"
Area 1:
  System Id           Interface   L  State        Holdtime SNPA

両端の MAC を控えておきます (veth の MAC は作るたびに変わります)。

SRC=$(cat /sys/class/net/wpg0/address)
PEER=$(sudo ip netns exec wpgfrr cat /sys/class/net/frr0/address)

ステップ 4. 相手の Hello を受信する

FRR は 3 秒ごとに自分の Hello を送っています。wpg capture で 1 つ受け取って、wpg のパーサで読めることを確かめます。

$ sudo wpg capture -i wpg0 -f "ether dst 01:80:c2:00:00:15" --count 1 --show 1
Capturing on wpg0 via afpacket, filter ether dst 01:80:c2:00:00:15 (Ctrl-C stops)
#   0  16:10:42.763122508   1514 B  dot3 / llc / isis_l2_lan_hello
state      finished (count reached)
...

FRR の Hello も MTU までパディングされた 1514 オクテットで、dot3 / llc / isis_l2_lan_hello と解析されます。-w /tmp/frr.pcapng で保存して、テンプレートに取り込むこともできます (pcap からテンプレートへ変換して再生)。

ステップ 5. 隣接を Up にする

まず、相手の MAC を載せずに Hello を 1 つ送ります。peer_mac は既定値の 02:00:00:00:00:02 のままなので、FRR から見ると「自分を知らない相手」です。

$ sudo wpg send templates/interop/isis-l2-lan-hello-up.wpg.yaml -i wpg0 --backend afpacket \
      --var src_mac=$SRC --count 1
$ sudo ip netns exec wpgfrr vtysh -N wpg -c "show isis neighbor"
Area 1:
  System Id           Interface   L  State        Holdtime SNPA
 0000.0000.0001      frr0        2  Initializing  29       a63f.1a8d.7239

FRR は wpg を見つけましたが、双方向の確認が取れていないので Initializing です。次に peer_mac に FRR の MAC を入れて送ります。

$ sudo wpg send templates/interop/isis-l2-lan-hello-up.wpg.yaml -i wpg0 --backend afpacket \
      --var src_mac=$SRC --var peer_mac=$PEER --count 2 --rate 1pps
$ sudo ip netns exec wpgfrr vtysh -N wpg -c "show isis neighbor"
Area 1:
  System Id           Interface   L  State        Holdtime SNPA
 0000.0000.0001      frr0        2  Up            30       a63f.1a8d.7239
$ sudo ip netns exec wpgfrr vtysh -N wpg -c "show isis neighbor detail"
Area 1:
 0000.0000.0001
    Interface: frr0, Level: 2, State: Up, Expires in 30s
    Adjacency flaps: 1, Last: 1s ago
    Circuit type: L2, Speaks: IPv4
    SNPA: a63f.1a8d.7239, LAN id: 0000.0000.0001.01
    LAN Priority: 0, unknown DIS state, DIS flaps: 0, Last: 2s ago
    Area Address(es):
      49.0001
    IPv4 Address(es):
      10.99.0.1

テンプレートの TLV (エリア、IPv4 アドレス、優先度 0、保持時間 30 秒) がそのまま FRR に見えています。隣接を保つには、保持時間より短い間隔で Hello を送り続けます。テンプレートの既定 (--count なし) は 3 秒間隔で 40 個、2 分間です。止めると 30 秒で隣接が消えます。

ステップ 6. 変えてみる

• エリアを変える: --var area=49.0002 --var "system_id=0000 0000 0003" で送っても、隣接は Up になります。エリアアドレスの一致が必要なのはレベル 1 の隣接だけで、レベル 2 はエリアをまたいで隣接するためです (ISO 10589)。レベル 1 を試すには、テンプレートの isis_l2_lan_hello を isis_l1_lan_hello に、宛先を 01:80:c2:00:00:14 (AllL1ISs) に変え、FRR を is-type level-1 にします。
• MTU の不一致: pdu_length を Auto に戻す (行を消す) と、パディングのない短い Hello になります。FRR は既定で Hello のパディングを要求しないため隣接は張れますが、パディングを必須にしている実装では張れません。実機での挙動の違いを確かめるのに使えます。
• 認証: templates/protocols/routing/isis-l2-lan-hello.wpg.yaml は平文認証 (TLV 10) 付きの例です。HMAC-MD5 の値は wpg が計算しないので、手で入れる必要があります。
• 他の PDU: LSP・CSNP・PSNP・ポイントツーポイント Hello のサンプルが templates/protocols/routing/isis-*.wpg.yaml にあります。LSP のチェックサム (Fletcher) は Auto です。

後片付け:

sudo scripts/interop/frr-netns.sh --down

次のステップ

• 実機 (IOS-XR、Junos) や CML2 上のルータで同じ確認をする手順と設定例は 相互接続確認 にあります。
• 同じ考え方の IPv6 版 (型・長さ・チェックサムが互いに導出される複数レイヤ) は IPv6 と近隣探索 (NDP) で扱います。

プロトコルリファレンス

本章は wpg-protocols のプロトコル定義 IR (GET /api/protocols で返すカタログ) から自動生成しているため、常にコードと一致します。対象は 183 プロトコルです。各ページには、ワイヤ順のフィールド (型、既定値、Auto の規則、説明)、そのプロトコルに至る下位レイヤ、次レイヤの対応表、組み立て後に検査する制約、同梱のサンプルテンプレートを載せています。到達経路、手で設定するフィールド、残っている近似は手書きのプロトコル補足を参照してください。定義を変更したら just docs-gen で再生成します。

L2 (データリンク)

L3 (ネットワーク)

L4 (トランスポート)

アプリケーション・制御

ペイロード

Ethernet II (ethernet2)

• レイヤ: L2 (データリンク)
• ヘッダ: 14 オクテット (固定長)
• 最小フレーム長: 60 オクテット
• 補足: カプセル化・トンネル, L2 制御プロトコル, SRv6 SRH / SR-MPLS (P2), ユーザ定義プロトコル (protocols.d)

下位レイヤからの到達

フィールド

ethertype

次レイヤ

次レイヤは ethertype で判別します。このフィールドが Auto のときは、上に積んだプロトコルの値を書き込みます。

ethertype = 34825 (0x8809) のときのペイロード先頭 8 ビット

サンプルテンプレート

• interop-bfd-session-up — templates/interop/bfd-session-up.wpg.yaml
• interop-ldp-link-hello — templates/interop/ldp-link-hello.wpg.yaml
• interop-ospfv2-hello-2way — templates/interop/ospfv2-hello-2way.wpg.yaml
• interop-pim-hello-neighbor — templates/interop/pim-hello-neighbor.wpg.yaml
• interop-ripv2-response-route — templates/interop/ripv2-response-route.wpg.yaml
• interop-vrrpv3-preempt — templates/interop/vrrpv3-preempt.wpg.yaml
• arp-bad-address-lengths — templates/malformed/arp-bad-lengths.wpg.yaml
• bad-fcs — templates/malformed/bad-fcs.wpg.yaml
• bad-ipv4-checksum — templates/malformed/ipv4-bad-checksum.wpg.yaml
• bad-ipv4-ihl — templates/malformed/ipv4-bad-ihl.wpg.yaml
• bad-ipv4-total-length — templates/malformed/ipv4-total-length-too-long.wpg.yaml
• bad-ipv4-total-length-short — templates/malformed/ipv4-total-length-too-short.wpg.yaml
• truncated-ipv4-udp — templates/malformed/ipv4-truncated.wpg.yaml
• bad-ipv6-payload-length — templates/malformed/ipv6-bad-payload-length.wpg.yaml
• bad-tcp-checksum — templates/malformed/tcp-bad-checksum.wpg.yaml
• bad-udp-checksum — templates/malformed/udp-bad-checksum.wpg.yaml
• bad-udp-length — templates/malformed/udp-bad-length.wpg.yaml
• frame-with-fcs — templates/protocols/frame/fcs-auto.wpg.yaml
• jumbo-frame-9000 — templates/protocols/frame/jumbo-9000.wpg.yaml
• min-frame-padded — templates/protocols/frame/min-frame-60.wpg.yaml
• runt-frame-unpadded — templates/protocols/frame/no-padding-runt.wpg.yaml
• arp-gratuitous — templates/protocols/l2/arp-gratuitous.wpg.yaml
• arp-reply — templates/protocols/l2/arp-reply.wpg.yaml
• arp-request — templates/protocols/l2/arp-request.wpg.yaml
• dot1ad-qinq-frame — templates/protocols/l2/dot1ad.wpg.yaml
• dot1q-frame — templates/protocols/l2/dot1q.wpg.yaml
• eth-ii-frame — templates/protocols/l2/ethernet2.wpg.yaml
• macsec — templates/protocols/l2/macsec.wpg.yaml
• icmpv4-echo-request — templates/protocols/l3/icmpv4-echo.wpg.yaml
• icmpv6-echo-request — templates/protocols/l3/icmpv6-echo.wpg.yaml
• ipv4-dscp-ecn-matrix — templates/protocols/l3/ipv4-dscp-ecn-matrix.wpg.yaml
• ipv4-fragments — templates/protocols/l3/ipv4-fragment.wpg.yaml
• ipv4-router-alert — templates/protocols/l3/ipv4-router-alert.wpg.yaml
• ipv4-udp — templates/protocols/l3/ipv4.wpg.yaml
• ipv6-dstopts — templates/protocols/l3/ipv6-dstopts.wpg.yaml
• ipv6-ext-chain — templates/protocols/l3/ipv6-ext-chain.wpg.yaml
• ipv6-fragment — templates/protocols/l3/ipv6-frag.wpg.yaml
• ipv6-hopopts-router-alert — templates/protocols/l3/ipv6-hopopts.wpg.yaml
• ipv6-routing-type2 — templates/protocols/l3/ipv6-routing.wpg.yaml
• ipv6-udp — templates/protocols/l3/ipv6.wpg.yaml
• ndp-neighbor-advertisement — templates/protocols/l3/ndp-na.wpg.yaml
• ndp-neighbor-solicitation — templates/protocols/l3/ndp-ns.wpg.yaml
• ndp-router-advertisement — templates/protocols/l3/ndp-ra.wpg.yaml
• ndp-redirect — templates/protocols/l3/ndp-redirect.wpg.yaml
• ndp-router-solicitation — templates/protocols/l3/ndp-rs.wpg.yaml
• sctp-abort — templates/protocols/l4/sctp-abort.wpg.yaml
• sctp-data — templates/protocols/l4/sctp-data.wpg.yaml
• sctp-heartbeat — templates/protocols/l4/sctp-heartbeat.wpg.yaml
• sctp-init-ack — templates/protocols/l4/sctp-init-ack.wpg.yaml
• sctp-init — templates/protocols/l4/sctp-init.wpg.yaml
• sctp-over-udp — templates/protocols/l4/sctp-over-udp.wpg.yaml
• sctp-sack — templates/protocols/l4/sctp-sack.wpg.yaml
• sctp-shutdown — templates/protocols/l4/sctp-shutdown.wpg.yaml
• tcp-data-psh-ack — templates/protocols/l4/tcp-data.wpg.yaml
• tcp-syn-options — templates/protocols/l4/tcp-syn.wpg.yaml
• udp-over-ipv6 — templates/protocols/l4/udp-ipv6.wpg.yaml
• udp-datagram — templates/protocols/l4/udp.wpg.yaml
• diameter-ccr-initial — templates/protocols/mobile/diameter-ccr-initial.wpg.yaml
• diameter-cer — templates/protocols/mobile/diameter-cer.wpg.yaml
• gtpv2-create-session-request — templates/protocols/mobile/gtpv2-create-session-request.wpg.yaml
• gtpv2-create-session-response — templates/protocols/mobile/gtpv2-create-session-response.wpg.yaml
• gtpv2-echo-request — templates/protocols/mobile/gtpv2-echo-request.wpg.yaml
• ldp-hello — templates/protocols/mpls/ldp-hello.wpg.yaml
• ldp-initialization — templates/protocols/mpls/ldp-initialization.wpg.yaml
• ldp-label-mapping — templates/protocols/mpls/ldp-label-mapping.wpg.yaml
• ldp-label-withdraw — templates/protocols/mpls/ldp-label-withdraw.wpg.yaml
• ldp-targeted-hello — templates/protocols/mpls/ldp-targeted-hello.wpg.yaml
• rsvp-hello — templates/protocols/mpls/rsvp-hello.wpg.yaml
• rsvp-path-err — templates/protocols/mpls/rsvp-path-err.wpg.yaml
• rsvp-path-tear — templates/protocols/mpls/rsvp-path-tear.wpg.yaml
• rsvp-te-path — templates/protocols/mpls/rsvp-te-path.wpg.yaml
• rsvp-te-resv — templates/protocols/mpls/rsvp-te-resv.wpg.yaml
• sr-mpls-entropy — templates/protocols/mpls/sr-mpls-entropy.wpg.yaml
• bfd-auth — templates/protocols/oam/bfd-auth.wpg.yaml
• bfd-multihop-ipv6 — templates/protocols/oam/bfd-multihop-ipv6.wpg.yaml
• bfd-single-hop — templates/protocols/oam/bfd-single-hop.wpg.yaml
• cfm-ccm — templates/protocols/oam/cfm-ccm.wpg.yaml
• cfm-generic — templates/protocols/oam/cfm-generic.wpg.yaml
• cfm-lbm — templates/protocols/oam/cfm-lbm.wpg.yaml
• cfm-lbr — templates/protocols/oam/cfm-lbr.wpg.yaml
• cfm-ltm — templates/protocols/oam/cfm-ltm.wpg.yaml
• cfm-ltr — templates/protocols/oam/cfm-ltr.wpg.yaml
• efm-oam-event — templates/protocols/oam/efm-oam-event.wpg.yaml
• efm-oam-generic — templates/protocols/oam/efm-oam-generic.wpg.yaml
• efm-oam-information — templates/protocols/oam/efm-oam-information.wpg.yaml
• efm-oam-loopback — templates/protocols/oam/efm-oam-loopback.wpg.yaml
• efm-oam-organization-specific — templates/protocols/oam/efm-oam-organization-specific.wpg.yaml
• efm-oam-variable-request — templates/protocols/oam/efm-oam-variable-request.wpg.yaml
• efm-oam-variable-response — templates/protocols/oam/efm-oam-variable-response.wpg.yaml
• erps-raps-nr-rb — templates/protocols/oam/erps-raps-nr-rb.wpg.yaml
• erps-raps-sf — templates/protocols/oam/erps-raps-sf.wpg.yaml
• micro-bfd — templates/protocols/oam/micro-bfd.wpg.yaml
• y1731-1dm — templates/protocols/oam/y1731-1dm.wpg.yaml
• y1731-1sl — templates/protocols/oam/y1731-1sl.wpg.yaml
• y1731-ais — templates/protocols/oam/y1731-ais.wpg.yaml
• y1731-csf — templates/protocols/oam/y1731-csf.wpg.yaml
• y1731-dmm — templates/protocols/oam/y1731-dmm.wpg.yaml
• y1731-dmr — templates/protocols/oam/y1731-dmr.wpg.yaml
• y1731-lck — templates/protocols/oam/y1731-lck.wpg.yaml
• y1731-lmm — templates/protocols/oam/y1731-lmm.wpg.yaml
• y1731-lmr — templates/protocols/oam/y1731-lmr.wpg.yaml
• y1731-slm — templates/protocols/oam/y1731-slm.wpg.yaml
• y1731-slr — templates/protocols/oam/y1731-slr.wpg.yaml
• y1731-tst — templates/protocols/oam/y1731-tst.wpg.yaml
• srv6-end-dx2-hmac — templates/protocols/srv6/srv6-end-dx2-hmac.wpg.yaml
• srv6-h-encaps-ipv4 — templates/protocols/srv6/srv6-h-encaps-ipv4.wpg.yaml
• srv6-srh-udp — templates/protocols/srv6/srv6-srh-udp.wpg.yaml
• esmc-event-dnu — templates/protocols/timing/esmc-event-dnu.wpg.yaml
• esmc-ql-prc — templates/protocols/timing/esmc-ql-prc.wpg.yaml
• ptp-announce-udp — templates/protocols/timing/ptp-announce-udp.wpg.yaml
• ptp-delay-req-udp — templates/protocols/timing/ptp-delay-req-udp.wpg.yaml
• ptp-delay-resp-udp — templates/protocols/timing/ptp-delay-resp-udp.wpg.yaml
• ptp-follow-up-l2 — templates/protocols/timing/ptp-follow-up-l2.wpg.yaml
• ptp-generic — templates/protocols/timing/ptp-generic.wpg.yaml
• ptp-management-get — templates/protocols/timing/ptp-management-get.wpg.yaml
• ptp-pdelay-req-l2 — templates/protocols/timing/ptp-pdelay-req-l2.wpg.yaml
• ptp-pdelay-resp-follow-up-l2 — templates/protocols/timing/ptp-pdelay-resp-follow-up-l2.wpg.yaml
• ptp-pdelay-resp-l2 — templates/protocols/timing/ptp-pdelay-resp-l2.wpg.yaml
• ptp-signaling-unicast — templates/protocols/timing/ptp-signaling-unicast.wpg.yaml
• ptp-sync-two-step-l2 — templates/protocols/timing/ptp-sync-two-step-l2.wpg.yaml
• rtcp-feedback-app — templates/protocols/voip/rtcp-feedback-app.wpg.yaml
• rtcp-rr-bye — templates/protocols/voip/rtcp-rr-bye.wpg.yaml
• rtcp-sr-sdes — templates/protocols/voip/rtcp-sr-sdes.wpg.yaml
• rtp-pcmu — templates/protocols/voip/rtp-pcmu.wpg.yaml
• sip-invite — templates/protocols/voip/sip-invite.wpg.yaml
• sip-register — templates/protocols/voip/sip-register.wpg.yaml
• scenario-arp-sweep-slash22 — templates/scenarios/arp-sweep-slash22.wpg.yaml
• scenario-dhcp-discover-flood — templates/scenarios/dhcp-discover-flood.wpg.yaml
• scenario-frame-size-sweep — templates/scenarios/frame-size-sweep.wpg.yaml
• scenario-jumbo-udp-mtu-probe — templates/scenarios/jumbo-udp-mtu-probe.wpg.yaml
• scenario-mac-flood — templates/scenarios/mac-flood.wpg.yaml
• scenario-ndp-ns-sweep — templates/scenarios/ndp-ns-sweep.wpg.yaml
• scenario-ping-sweep-pattern — templates/scenarios/ping-sweep-pattern.wpg.yaml
• scenario-qinq-service-sweep — templates/scenarios/qinq-service-sweep.wpg.yaml
• scenario-ipv6-ra-flood — templates/scenarios/ra-flood.wpg.yaml
• sr-mpls-prefix-sid-sweep — templates/scenarios/sr-mpls-prefix-sid-sweep.wpg.yaml
• scenario-tcp-syn-port-scan — templates/scenarios/tcp-syn-port-scan.wpg.yaml
• scenario-ttl-sweep — templates/scenarios/ttl-sweep.wpg.yaml
• scenario-udp-qos-matrix — templates/scenarios/udp-qos-matrix.wpg.yaml
• scenario-vlan-arp-sweep — templates/scenarios/vlan-arp-sweep.wpg.yaml
• scenario-vlan-id-sweep — templates/scenarios/vlan-id-sweep.wpg.yaml
• scenario-vlan-syn-flood — templates/scenarios/vlan-syn-flood.wpg.yaml

802.1Q VLAN (dot1q)

• レイヤ: L2 (データリンク)
• ヘッダ: 4 オクテット (固定長)
• 補足: ユーザ定義プロトコル (protocols.d)

下位レイヤからの到達

フィールド

ethertype

次レイヤ

次レイヤは ethertype で判別します。このフィールドが Auto のときは、上に積んだプロトコルの値を書き込みます。

制約

サンプルテンプレート

• dot1ad-qinq-frame — templates/protocols/l2/dot1ad.wpg.yaml
• dot1q-frame — templates/protocols/l2/dot1q.wpg.yaml
• cfm-ccm — templates/protocols/oam/cfm-ccm.wpg.yaml
• erps-raps-nr-rb — templates/protocols/oam/erps-raps-nr-rb.wpg.yaml
• erps-raps-sf — templates/protocols/oam/erps-raps-sf.wpg.yaml
• scenario-qinq-service-sweep — templates/scenarios/qinq-service-sweep.wpg.yaml
• scenario-vlan-arp-sweep — templates/scenarios/vlan-arp-sweep.wpg.yaml
• scenario-vlan-id-sweep — templates/scenarios/vlan-id-sweep.wpg.yaml
• scenario-vlan-syn-flood — templates/scenarios/vlan-syn-flood.wpg.yaml

802.1ad S-VLAN (dot1ad)

• レイヤ: L2 (データリンク)
• ヘッダ: 4 オクテット (固定長)

下位レイヤからの到達

フィールド

ethertype

次レイヤ

次レイヤは ethertype で判別します。このフィールドが Auto のときは、上に積んだプロトコルの値を書き込みます。

制約

サンプルテンプレート

• dot1ad-qinq-frame — templates/protocols/l2/dot1ad.wpg.yaml
• scenario-qinq-service-sweep — templates/scenarios/qinq-service-sweep.wpg.yaml

IEEE 802.3 (dot3)

• レイヤ: L2 (データリンク)
• ヘッダ: 14 オクテット (固定長)
• 最小フレーム長: 60 オクテット
• 補足: L2 制御プロトコル

下位レイヤからの到達

フィールド

次レイヤ

次レイヤは length で判別します。このフィールドが Auto のときは、上に積んだプロトコルの値を書き込みます。

制約

サンプルテンプレート

• interop-isis-l2-lan-hello-up — templates/interop/isis-l2-lan-hello-up.wpg.yaml
• dot3-llc-osi — templates/protocols/l2/dot3-llc-osi.wpg.yaml
• dot3-llc-snap-frame — templates/protocols/l2/dot3-llc-snap.wpg.yaml
• dot3-llc-frame — templates/protocols/l2/dot3-llc.wpg.yaml
• clnp-dt — templates/protocols/l3/clnp-dt.wpg.yaml
• clnp-er — templates/protocols/l3/clnp-er.wpg.yaml
• clnp-erq — templates/protocols/l3/clnp-erq.wpg.yaml
• esis-esh — templates/protocols/routing/esis-esh.wpg.yaml
• esis-generic — templates/protocols/routing/esis-generic.wpg.yaml
• esis-ish — templates/protocols/routing/esis-ish.wpg.yaml
• esis-rd — templates/protocols/routing/esis-rd.wpg.yaml
• isis-generic — templates/protocols/routing/isis-generic.wpg.yaml
• isis-l1-csnp — templates/protocols/routing/isis-l1-csnp.wpg.yaml
• isis-l1-lan-hello — templates/protocols/routing/isis-l1-lan-hello.wpg.yaml
• isis-l1-lsp — templates/protocols/routing/isis-l1-lsp.wpg.yaml
• isis-l1-psnp — templates/protocols/routing/isis-l1-psnp.wpg.yaml
• isis-l2-csnp — templates/protocols/routing/isis-l2-csnp.wpg.yaml
• isis-l2-lan-hello — templates/protocols/routing/isis-l2-lan-hello.wpg.yaml
• isis-l2-lsp — templates/protocols/routing/isis-l2-lsp.wpg.yaml
• isis-l2-psnp — templates/protocols/routing/isis-l2-psnp.wpg.yaml
• isis-p2p-hello — templates/protocols/routing/isis-p2p-hello.wpg.yaml

IEEE 802.2 LLC (llc)

• レイヤ: L2 (データリンク)
• ヘッダ: 3 オクテット (固定長)
• 補足: L2 制御プロトコル, OSI カプセル化 (P2)

下位レイヤからの到達

フィールド

dsap

ssap

control

次レイヤ

次レイヤは dsap で判別します。このフィールドが Auto のときは、上に積んだプロトコルの値を書き込みます。

dsap = 254 (0xfe) のときのペイロード先頭 8 ビット

サンプルテンプレート

• interop-isis-l2-lan-hello-up — templates/interop/isis-l2-lan-hello-up.wpg.yaml
• dot3-llc-osi — templates/protocols/l2/dot3-llc-osi.wpg.yaml
• dot3-llc-snap-frame — templates/protocols/l2/dot3-llc-snap.wpg.yaml
• dot3-llc-frame — templates/protocols/l2/dot3-llc.wpg.yaml
• clnp-dt — templates/protocols/l3/clnp-dt.wpg.yaml
• clnp-er — templates/protocols/l3/clnp-er.wpg.yaml
• clnp-erq — templates/protocols/l3/clnp-erq.wpg.yaml
• esis-esh — templates/protocols/routing/esis-esh.wpg.yaml
• esis-generic — templates/protocols/routing/esis-generic.wpg.yaml
• esis-ish — templates/protocols/routing/esis-ish.wpg.yaml
• esis-rd — templates/protocols/routing/esis-rd.wpg.yaml
• isis-generic — templates/protocols/routing/isis-generic.wpg.yaml
• isis-l1-csnp — templates/protocols/routing/isis-l1-csnp.wpg.yaml
• isis-l1-lan-hello — templates/protocols/routing/isis-l1-lan-hello.wpg.yaml
• isis-l1-lsp — templates/protocols/routing/isis-l1-lsp.wpg.yaml
• isis-l1-psnp — templates/protocols/routing/isis-l1-psnp.wpg.yaml
• isis-l2-csnp — templates/protocols/routing/isis-l2-csnp.wpg.yaml
• isis-l2-lan-hello — templates/protocols/routing/isis-l2-lan-hello.wpg.yaml
• isis-l2-lsp — templates/protocols/routing/isis-l2-lsp.wpg.yaml
• isis-l2-psnp — templates/protocols/routing/isis-l2-psnp.wpg.yaml
• isis-p2p-hello — templates/protocols/routing/isis-p2p-hello.wpg.yaml

SNAP (snap)

• レイヤ: L2 (データリンク)
• ヘッダ: 5 オクテット (固定長)
• 補足: L2 制御プロトコル

下位レイヤからの到達

フィールド

pid

次レイヤ

次レイヤは pid で判別します。このフィールドが Auto のときは、上に積んだプロトコルの値を書き込みます。

サンプルテンプレート

• dot3-llc-snap-frame — templates/protocols/l2/dot3-llc-snap.wpg.yaml

ARP (arp)

• レイヤ: L2 (データリンク)
• ヘッダ: 28 オクテット (固定長)

下位レイヤからの到達

フィールド

htype

ptype

oper

制約

サンプルテンプレート

• arp-bad-address-lengths — templates/malformed/arp-bad-lengths.wpg.yaml
• min-frame-padded — templates/protocols/frame/min-frame-60.wpg.yaml
• runt-frame-unpadded — templates/protocols/frame/no-padding-runt.wpg.yaml
• arp-gratuitous — templates/protocols/l2/arp-gratuitous.wpg.yaml
• arp-reply — templates/protocols/l2/arp-reply.wpg.yaml
• arp-request — templates/protocols/l2/arp-request.wpg.yaml
• srv6-end-dx2-hmac — templates/protocols/srv6/srv6-end-dx2-hmac.wpg.yaml
• scenario-arp-sweep-slash22 — templates/scenarios/arp-sweep-slash22.wpg.yaml
• scenario-vlan-arp-sweep — templates/scenarios/vlan-arp-sweep.wpg.yaml

LLDP (lldp)

• レイヤ: L2 (データリンク)
• ヘッダ: 可変長
• 補足: L2 制御プロトコル

下位レイヤからの到達

フィールド

tlvs

各要素は以下のフィールドの組です。

サンプルテンプレート

• lldp — templates/protocols/l2/lldp.wpg.yaml

CDP (cdp)

• レイヤ: L2 (データリンク)
• ヘッダ: 可変長
• 補足: L2 制御プロトコル

下位レイヤからの到達

フィールド

tlvs

• タイプ 16 ビット、長さ 16 ビット。
• 長さはタイプと長さのフィールドも含みます。
• 未知のタイプは値をオクテット列のまま保持します。

サンプルテンプレート

• cdp — templates/protocols/l2/cdp.wpg.yaml

STP BPDU (stp)

• レイヤ: L2 (データリンク)
• ヘッダ: 可変長
• 補足: L2 制御プロトコル

下位レイヤからの到達

フィールド

protocol_version

bpdu_type

flags

制約

サンプルテンプレート

• stp — templates/protocols/l2/stp.wpg.yaml

LACP (lacp)

• レイヤ: L2 (データリンク)
• ヘッダ: 110 オクテット (固定長)
• 補足: L2 制御プロトコル, PTP / ESMC / CFM / R-APS / 802.3ah OAM (P2)

下位レイヤからの到達

フィールド

actor_state

partner_state

サンプルテンプレート

• lacp — templates/protocols/l2/lacp.wpg.yaml

Marker Protocol (marker)

• レイヤ: L2 (データリンク)
• ヘッダ: 110 オクテット (固定長)
• 補足: L2 制御プロトコル, PTP / ESMC / CFM / R-APS / 802.3ah OAM (P2)

下位レイヤからの到達

フィールド

サンプルテンプレート

• marker — templates/protocols/l2/marker.wpg.yaml

EAPOL (eapol)

• レイヤ: L2 (データリンク)
• ヘッダ: 可変長
• 補足: L2 制御プロトコル

下位レイヤからの到達

フィールド

type

サンプルテンプレート

• eapol — templates/protocols/l2/eapol.wpg.yaml

PPPoE Discovery (pppoe_discovery)

• レイヤ: L2 (データリンク)
• ヘッダ: 可変長
• 補足: L2 制御プロトコル

下位レイヤからの到達

フィールド

code

tags

• タイプ 16 ビット、長さ 16 ビット。
• 長さは値の部分だけを数えます。
• 未知のタイプは値をオクテット列のまま保持します。

サンプルテンプレート

• pppoe-discovery — templates/protocols/l2/pppoe-discovery.wpg.yaml

PPPoE Session (pppoe_session)

• レイヤ: L2 (データリンク)
• ヘッダ: 6 オクテット (固定長)
• 補足: L2 制御プロトコル

下位レイヤからの到達

フィールド

次レイヤ

次レイヤは session_id で判別します。このフィールドが Auto のときは、上に積んだプロトコルの値を書き込みます。

サンプルテンプレート

• pppoe-ppp-ipcp — templates/protocols/l2/pppoe-ppp-ipcp.wpg.yaml
• pppoe-ppp-lcp — templates/protocols/l2/pppoe-ppp-lcp.wpg.yaml

PPP (ppp)

• レイヤ: L2 (データリンク)
• ヘッダ: 2 オクテット (固定長)
• 補足: L2 制御プロトコル, OSI カプセル化 (P2)

下位レイヤからの到達

フィールド

protocol

次レイヤ

次レイヤは protocol で判別します。このフィールドが Auto のときは、上に積んだプロトコルの値を書き込みます。

protocol = 35 (0x0023) のときのペイロード先頭 8 ビット

サンプルテンプレート

• pppoe-ppp-ipcp — templates/protocols/l2/pppoe-ppp-ipcp.wpg.yaml
• pppoe-ppp-lcp — templates/protocols/l2/pppoe-ppp-lcp.wpg.yaml

PPP LCP (ppp_lcp)

• レイヤ: L2 (データリンク)
• ヘッダ: 可変長
• 補足: L2 制御プロトコル

下位レイヤからの到達

フィールド

code

options

• タイプ 8 ビット、長さ 8 ビット。
• 長さはタイプと長さのフィールドも含みます。
• 未知のタイプは値をオクテット列のまま保持します。