要点

  • Ivan Pepelnjak の公的な活動は、単一ベンダーの製品宣伝ではなく、国内初のインターネット交換拠点の設立への参加を含む、スロベニアのネットワーク運用と相互接続から始まった。
  • ipSpace.net を通じて独立した出版・教育・コンサルティングの場を築いた。その鋭い議論は、標準化団体の合意と取り違えないときにこそ役立つ。
  • netlab は YAML で記述したトポロジーを再現可能なマルチベンダー・ラボに変える。ただし、仮想環境があらゆる ASIC、物理回線、稼働中のネットワークに蓄積された状態を再現するとは装わない。
  • 中心的な貢献は判断の方法にある。データの権限を定め、期待する動作を検証し、依存関係を明らかにし、設定の生成と既存ネットワークの安全な管理を区別することだ。

バージョン 26.07 が示す、コントローラーではないラボの重要性

2026年7月13日、netlab はバージョン 26.07 を公開した。GRE と WireGuard のトンネル、グレースフルリスタート、BGP ロール、より大規模なラボに関する機能が拡充された。通常の変更一覧の背後には運用上の考え方がある。利用者が検証したいトポロジーとプロトコルを記述すると、プログラムは仮想マシンやコンテナーを作成し、パラメーターを割り当て、異なるネットワーク OS 向けの初期設定を生成する。

このプロジェクトは、本番環境の万能なオーケストレーターを標榜していない。その境界の明確さは Ivan Pepelnjak の公開活動の強みの一つだ。2026年6月、実機の設定を論じた際、netlab は既知のトポロジーと、通常は初期状態がクリーンまたはラボ用であることを前提とすると明言した。設定の断片は用意できても、稼働中のルーターに積み重なった任意の変更履歴を整合させたり、CLI のテキストを置き換える際にすべての現場固有の例外が残ると保証したりはできない。

この率直さは、長い機能一覧より重要だ。デモ用のもっともらしい設定を作るのは比較的容易である。長年のポリシー、文書化が不十分な依存関係、分散した責任を抱えるネットワークの変更には、設定の乖離の検出、処理の境界、承認、ロールバック、結果の独立した検証が欠かせない。

Ivan Pepelnjak の経歴には、この区別が一貫している。BGP や EVPN、自動化そのものを独占しているわけではない。設計上の主張を、別の技術者が再現または反証できるモデルと実験に変えている。

スロベニアの初期インターネットが与えた運用の土台

RIPE Labs の歴史的なインタビューは、Ivan Pepelnjak をスロベニアで商用・学術ネットワークが形成された時代に位置づける。国内初のインターネット交換拠点の設立への参加に触れ、鉄のカーテン崩壊前後の接続上の制約を描いている。これは共同の歴史であり、一人の専門家が国のインフラを独力で構築したという話を裏づけるものではない。

小さな市場では、容量不足、相互接続、即興的な対応が現実の条件だった。国際回線容量の余裕、多様なプラットフォーム、厚い国内エコシステムを当てにはできない。技術者はサービスを利用可能に保つため、経路、回線、機器、組織間の関係を十分に理解する必要があった。

インターネット交換拠点自体、ネットワーク、施設、運用者の間の取り決めである。直接のトラフィック交換を容易にするが、各参加者の経路制御ポリシーやトランジットに取って代わるものではない。この経験が示すのは、技術的な機能がインフラになるのは、設定、運用、障害時の責任について組織が合意して初めてだということだ。

ここから、Ivan Pepelnjak が設計上の流行に懐疑的な理由も理解できる。図が説得力を持つのはベンダーが美しく描いたからではない。依存関係が把握でき、運用者がそれを理解し、組織が想定される障害に耐えられるからだ。

コンサルティングから ipSpace.net へ：独立性を運営の形に

本人の公開プロフィールは、Ivan Pepelnjak を ipSpace.net の独立系ネットワークアーキテクトと紹介し、1990年から大規模ネットワークの設計、導入、教育、執筆に携わっているとしている。CCIE 第1354号 Emeritus の資格も記されている。これらは主に本人が管理するページに基づく情報として帰属を明確にすべきであり、経歴全体を検証済みの記録とみなすべきではない。

やがて ipSpace.net は、その活動の中心的な場になった。ルーティング、データセンター、クラウド、自動化に関する記事、ウェビナー、講座、ポッドキャスト、書籍を提供する。長期にわたる蓄積があるため、現在の判断を過去の予測、訂正、留保と照らし合わせられる。

独立していれば、複数のベンダーを比較し、その設計を率直に批判しやすい。しかし利害がないわけではない。有料教育、コンサルティング、ソフトウェアイメージ、スポンサー、職業上の関係も、経済的・技術的な依存を生む。重要なのは市場の外にいると称することではなく、その構造を透明にすることだ。

サイトは、記事が筆者の見解を表すと明記している。鋭い批判は宣伝文句を崩せる一方、個別の事例を一般化することもある。この長年の記録は技術的判断の蓄積として読むべきで、業界の総意として扱うべきではない。

「信頼できる唯一の情報源」は保存場所より先に権限を決める

Ivan Pepelnjak は信頼できる唯一の情報源という概念に繰り返し立ち返る。データベースを買えばインフラの不整合が消えるかのように使われることもある言葉だ。彼が求めるのはもっと根本的なことである。テンプレートや API にネットワークを確実に変更させる前に、機器台帳、アドレス、トポロジー、望ましいサービスを表すデータについて、その権限を定めなければならない。

機器の設定は、その機器が現在何を正しいと認識しているかの証拠にはなる。組織の意図を必ずしも示さない。文書化されていない例外を取り込めば、設定の乖離を承認済みの設計に変えてしまうおそれがある。一方、観測した状態を無視すれば、すでに変化したネットワークに理想上のモデルを押しつけかねない。

実務上の問いは、誰が決めるのかだ。アドレス割り当ては IPAM、サービスの識別は顧客システム、転送の意図の一部はコントローラーが権限を持つ場合がある。機器は一部の運用状態の情報源であり続ける。監視は状態を観測するが、それだけでポリシーを定めるわけではない。

テンプレートを選ぶ前に、誰が拠点を作り、アドレスを割り当て、どの記録が必要な隣接先を定め、誰が調整を承認し、モデルと機器が食い違ったらどうするかに答える必要がある。そうしなければ、データ統合は権限をめぐる対立を隠すだけだ。

YAML のトポロジーはネットワークを圧縮して表した理論

netlab の利用者は通常、ノード、接続、機器の種類、プロトコルのモジュールを記述する YAML ファイルから始める。ノード名は対象を作り、接続はリンクの存在を示し、OSPF、IS-IS、BGP、EVPN、VXLAN は期待される関係を加える。アドレスプールと既定値によって、抽象的な図が具体的なパラメーターになる。

プログラムは入力を検証し、既定値を展開し、アドレスを割り当て、各プラットフォーム向けの情報を組み立て、初期設定を生成する。適切なイメージがあれば、containerlab、Vagrant、libvirt などが仮想環境を作る。成果物は静止した図ではなく、実行可能なラボだ。

この設計は意図と構文を分ける。利用者が二つのノードを特定のプロトコルで動かしたいと指定し、プロジェクトがイメージごとに異なるコマンドを生成する。本番環境の自動化が掲げる約束に似ているが、ここでは削除・再構築ができ、失敗の費用が小さく、繰り返しが当たり前の環境に置かれている。

YAML は中立ではない。定義形式が表現できることを決め、既定値は判断を隠し、モジュールは共通の最小限の機能に対応しても固有の機能には対応しない場合がある。モデルが役立つかどうかは、問うていることに適合しているかで決まる。

実行環境の抽象化は利用を広げ、新たな依存も生む

同じトポロジーを異なる仮想化ツールやネットワーク OS で起動できる。作業の重複を減らし、多数の物理機器を購入せずに選択肢を比較できる。

ただし抽象化は、イメージ、ライセンス、ディスクやコンテナーの形式、管理インターフェース、ホストの資源に依存する。イメージの公開終了、ライセンスの変更、実行環境の更新によって、netlab 自体が正しく動いていても再現性が失われうる。

移植性は具体的な組み合わせごとに証明するものだ。「対応」とは、すべてのバージョンで全機能が同じように動くという意味ではない。結果とともに netlab のバージョン、イメージ、実行環境、資源上の制約を記録する必要がある。

この依存の連鎖はツールの価値を損なわない。ラボは YAML ファイルだけでなく、ソフトウェアと利用権の組み合わせであることを示している。

マルチベンダーのモジュールは、違いを同一視せず検証材料にする

netlab は多くのシステムと一般的なプロトコル向けに設定を生成する。一つの意図を異なる実装で試し、構文、既定値、機能の違いを確認できる。

「対応」という語は正確に使う必要がある。モジュールが通常の事例を扱えても、拡張機能を扱えない場合がある。二つの機器で BGP セッションが成立しても、コミュニティやエラーの扱いは異なりうる。有効な設定が、ベンダーの推奨事項をすべて含むとは限らない。

価値があるのは、観測できた違いを残すことだ。結果が異なれば、単一のモデルに合わせるためにラボがその違いをならしてはならない。その差こそ本番環境のリスクになりうる。

同等性には、動作の検証、バージョンの明示、期待する結果の明確化が必要だ。中立性は、ベンダーが存在しないと想像することではなく、ベンダーを比較することで得られる。

プロトコル実験は障害前に前提を明らかにする

BGP、OSPF、IS-IS、EVPN は時間とともに状態を伝える。ラボではセッションの確立、経路の伝播、経路選択、障害後の状態の取り消しを観察できる。

有用な試験は、ネットワークが「動くか」だけを問わない。維持すべき接続、古い状態が残ってよい時間、選ばれるべき経路、違反とみなす観測結果を定める。

再現可能な実験では、バージョン、タイマー、コスト、優先度、回線障害、再起動などを一度に一つずつ変える。本番ネットワークでは多数の要因に埋もれる仕組みを切り分けられる。

ラボは遅延、経路表の規模、CPU 負荷、ハードウェアの性質をすべて予測するものではない。仮説を検証するのであって、万能の認証を与えるわけではない。

稼働中の機器では、生成された設定が既存の状態に直面する

空の機器を設定するのはテキスト生成の課題だ。稼働中の機器を変更するのは状態遷移の課題である。現状、ルールの所有者、依存関係、削除の影響、有効化の順序を知る必要がある。

実機を論じる際、Ivan Pepelnjak はこの違いを認めている。netlab は設定の断片を作り、試験を助けられるが、どのようなネットワークの状態でも整合させる汎用のトランザクション処理基盤ではない。この制約によって、教育用ツールが証明できない管理能力を約束せずに済む。

本番用の仕組みは、望ましい状態と観測した状態を比較し、順序を入れ替えられない操作を理解し、機密情報を保護し、排他制御と権限を管理したうえで、実際の転送の変化を検証しなければならない。

生成は一段階にすぎない。権限、遷移、結果の証明を合わせて初めて、管理の仕組みになる。

仮想ラボは物理的な性能や耐障害性を保証しない

仮想機器は制御プレーンの多くの機能を十分に再現できる。一方、ASIC のテーブル容量、物理的なキュー、光回線のエラー、消費電力、基板の再起動、負荷時のスループットまで再現するとは限らない。

イメージには、物理プラットフォームとは異なるコード、ライセンス条件、制約がある場合もある。仮想環境で設定が受け入れられたことは、すべての機種でその機能が利用でき、必要な性能を発揮する証拠にはならない。

耐障害性には、独立したケーブルや電源、帯域外のアクセス、予備部品、手順、当番体制も関わる。仮想的な接続図だけでは、そのどれも保証できない。

ラボはリスクを減らすが、重大な変更前の機器試験、負荷試験、運用試験に取って代わらない。

データセンターネットワークで高まったベンダー横断的な説明の価値

リーフ・スパイン、アンダーレイ BGP、EVPN、VXLAN、ファブリックコントローラーによって、一つの意図が異なる形で表現される層が増えた。ベンダーは同じ略語を、異なる制約や動作に対して使う。

Ivan Pepelnjak はプロトコルと商業的な製品の売り方を分けて考える。EVPN の経路や VXLAN のトンネルは公開された仕組みに基づくが、運用はソフトウェア、ASIC、メーカーの設計判断に左右される。

比較は調達や運用に役立つが、勝者を決める必要はない。機能の豊富なプラットフォームは保守が難しいかもしれず、機能を絞ったもののほうがチームの能力に合う場合もある。

問うべきは図の新しさではなく、組織がどの性質を検証し、維持できるかだ。

クラウドは、単一ベンダーの抽象化が普遍的なネットワークではないと示した

パブリッククラウドは仮想ネットワーク、ゲートウェイ、経路表、ロードバランサー、ファイアウォールをサービスとして提供する。展開は速くなるが、これらが従来の機器やプロトコルに対応する形は一様ではない。

Ivan Pepelnjak の教育活動のかなりの部分は、こうしたモデルをネットワーク技術者の言葉に置き換えることにある。「伝播する」経路、ゾーン、障害領域はベンダーごとに固有の意味を持つ。複数のクラウドを描いた図でアイコンが同じでも、設計が均一になるわけではない。

抽象化は権限を隠しうる。誰が経路を設定し、どの指標が見え、どのポリシーを外へ出せ、サービスからどう離脱できるのか。これらの問いが費用と元に戻せるかどうかを左右する。

ラボは不確実性を減らせるが、実際の運用を確認するには、現実の利用枠、契約、通信経路で試験しなければならない。

有料教育は独立性を支え、固有の制約も生む

ipSpace.net は講座、ウェビナー、専門サービスを販売する。その収益は、特定の機器メーカーに依存せずにコンテンツやツールを支えうる。

ただし公開情報には、監査済みの会計書類、顧客総数、収益構成の全容はない。プラットフォームの知名度から規模、利益率、事業の分散度を推測することはできない。

この形は扱う題材にも影響する。需要の高い専門分野に、より多くの資源が向かう可能性がある。ベンダーのイメージとライセンスは、ラボで何を示せるかを決める。

こうした条件は仕事の価値を否定しない。ベンダーや大学の利害と同じく、見えるようにすべきものだ。

一人の主要な保守担当者への集中と継続性のリスク

netlab は一貫した構想から恩恵を受けている。文書、設計、例、利用者への回答を整合的に発展させられる。

同じ集中は依存にもなる。病気、優先順位の変化、使える時間の減少は、公開やレビューを遅らせうる。参加者の数だけでは、ほかの人が重要な部分を理解し、確実に新版を公開できる保証にならない。

継続性を決めるのは、設計判断の文書化、自動テスト、外部からの貢献の質、権利を引き継げるかどうかだ。オープンなライセンスは派生版を作れるようにするが、それを維持できる共同体を自動的に生むわけではない。

継続性のリスクは仕組みの性質であり、個人への評価ではない。

例もイメージもプロトコルも古くなるから、更新の継続には意味がある

Python、実行環境、ネットワークイメージの変更で、昨日まで動いたラボの例が壊れることがある。保守されなければ、その例は技術的負債になる。

バージョン 26.07 は、変化への対応が続いていることを示す。更新頻度だけで品質は証明できないが、前提を実装と照合し続けていることは分かる。

利用者は netlab、イメージ、実行環境、入力ファイルのバージョンを保存すべきだ。前提情報のない画面写真から結果を再現することはできない。

保守によって、一度きりの教材が長く使える道具になる。

教育が運用上の判断を改善するとき、基盤としての価値を持つ

説明そのものはパケットを転送しない。しかし、設計、調達、移行、障害へのチームの対応を変えうる。

Ivan Pepelnjak の影響を最も確かめやすいのは、この水準だ。記事や講座は実務で使える仕組みの説明と問いを提供する。ただし情報源からは、改善したネットワークの総数を数えたり、事業上の成果を一つの講義に帰したりはできない。

価値は、意図と構文、モデルと現実、うたわれた機能と検証された動作を混同する誤りを減らすことにある。

架空の市場シェアを持ち出さずに影響を論じることはできる。教育は閲覧数ではなく、判断の質を通じて作用する。

現在の試金石は、自動化が現場の知識を残せるかどうか

既存ネットワークには、例外、顧客の要件、予備経路、機器の制約、障害から得た教訓という履歴がある。その履歴を含まないモデルは、標準化の名の下にそれを消してしまうかもしれない。

一方、すべての例外を無批判に残せば、負債を自動化することになる。組織は何が要件で何が設定の乖離なのか、誰が争点を判断できるのかを定めなければならない。

Ivan Pepelnjak の方法が今も重要なのは、モデルと実験の両方を求めるからだ。モデルは結果を出せなければならず、観測にはその誤りを証明できる余地がなければならない。

成功とは技術者が消えることではない。知識を引き継ぎ、異議を唱えられる形にすることだ。

BGP のラボがポリシーを見えるようにする理由

BGP が伝えるのは到達可能性だけではない。その属性は優先順位、商業上の関係、トラフィックの目的、制約を表す。

ラボでは、ローカルプリファレンス、MED、コミュニティ、フィルタリング、集約、経路選択の相互作用を確認できる。ポリシーを変えれば、何が広告され、受け入れられ、拒否されるかを観測できる。

設定は構文上正しくても、事業上の意図を誤って表している場合がある。ネットワークが望ましくない結果へ完全に収束することもある。

試験ではパケットと判断を結びつける必要がある。どの経路が、なぜ選ばれ、どのデータがその選択を認めたのかを問うのだ。

EVPN と VXLAN：略語だけでは実装の全体は分からない

EVPN は経路と手順の一群であり、VXLAN はカプセル化方式だ。製品はそれらを、学習、ゲートウェイ、マルチホーミング、管理、ハードウェア対応について異なるモデルと組み合わせる。

二つのベンダーが「EVPN-VXLAN」を販売していても、経路の種類、ゲートウェイの動作、更新方法は違いうる。共通の名称は調査の出発点にはなるが、結論にはならない。

netlab を使えば比較可能な状況を作り、違いを記録できる。結論は、試験したバージョンと組み合わせに結びつけたままにすべきだ。

相互運用性は特定のシステムについて証明された性質であり、略語がもたらす魔法ではない。

障害試験は、許容できる劣化を先に定めてこそ役立つ

回線を切って「何かが残った」と確認するだけでは足りない。維持すべきトラフィック、許容される収束時間、古い状態が残ってよい時間、一時的に失われる機能を定める必要がある。

適切な試験は障害を起こし、動作を測り、復旧を確認する。通常状態に戻る過程で、別の種類の不具合が見つかることもある。

DNS、認証、外部コントローラー、時刻、ストレージ、帯域外アクセスがラボに含まれていない場合もある。試験条件には、こうした欠落を明記しなければならない。

「堅牢」という言葉は、観測可能な基準によって初めて検証できる。

設定生成は反復作業を解決しても、削除の意味は理解しない

一行を追加するのは簡単だ。削除は共有の依存関係を壊し、緊急時の経路を閉ざし、再計算を引き起こしかねない。仕組みには操作の意図を理解することが求められる。

本番環境では、変更を最小限に抑え、実行順序を決め、事前に確認し、ロールバックを備える必要がある。最終的なファイルが正しくても、全体を置き換えることが常に安全とは限らない。

netlab は主に環境を再作成できることで、この問題を避けている。その境界は対照的に、本番用コントローラーが何を証明すべきかを示す。

プラットフォームは生成したテキストだけでなく、状態の遷移によって評価すべきだ。

バージョン管理は必要だが、運用状態をすべて保存するわけではない

Git は YAML、テンプレート、文書、判断の記録を保存する。変更を見渡し、コードを以前の版へ戻せる。

しかし、学習したテーブル、物理的な状態、機密情報、公開終了したイメージ、動的経路、クラウドの利用枠、外部 API の作用までは自動的に保存しない。古いコミットに戻しても、ネットワークが元に戻るとは限らない。

信頼できる一連の仕組みでは、バージョン管理、機器台帳、バックアップ、遠隔測定、復旧を組み合わせ、保管場所に収まらないものを文書化する。

ツールが権限を持つ範囲は、明確に保たなければならない。

観測はモデルから実際の転送結果まで追わなければならない

有効なファイルと処理の成功が示すのは、入力が受け付けられたことまでだ。セッション、経路、転送テーブル、必要なら実際のパケット経路も検証しなければならない。

正しいモデルが誤って変換されることもある。機器がコマンドを受け入れても、異なる形で適用するかもしれない。経路が制御プレーンに現れても、ASIC に反映されない場合がある。

ラボでの確認には、隣接関係、プレフィックス、経路選択、損失、復旧を含めるべきだ。それによって初めて、生成が実験になる。

稼働中のネットワークでは、変更を行った経路とは独立した方法で観測すべきだ。

標準は共通言語を与え、実装は固有の動作を生む

RFC はメッセージ、状態、手順を記述する一方、選択肢や細部を製品に委ねる。ベンダーは既定値、保護策、制約を加え、運用者はポリシーを加える。

最終的な動作は、その全体から生まれる。Ivan Pepelnjak の活動は、標準の文面、製品の設定、観測結果を混同せずに結びつける。

そのため、製品の欠陥を標準のせいにしたり、適合をうたうだけで同一の運用が保証されると考えたりせずに済む。

有用なラボは違いを消さずに残す

抽象化を広げすぎると、違いをならして共通だが誤った設定にしてしまう。その場合、ラボが主に検証するのは自分自身のモデルだ。

違いを記録しておけば、それが許容可能か、別の処理が必要か、選択を覆すものかを判断できる。違いは設計上の事実になる。

目的は分断を賛美することではない。中立的なインターフェースが深い依存関係を隠さないようにすることだ。

優れたツールは共通の語彙と、共通ではないものを正直に示す場所を提供する。

教材と継続的な教育活動の違いは保守に表れる

教材は公開当日に動けばよいかもしれない。継続的な教育活動には、例の修正、イメージの更新、非互換性の説明、新しいバージョンへの対応が必要だ。

ipSpace.net と netlab には、議論、ラボ、その後の修正までの連続性が見られる。ただし、その継続性は依然として一人の人物と民間の運営形態に集中しており、公的な委任や永続性の保証はない。

長く続くかどうかは、ほかの人が内容とコードを理解し、引き継ぎ、保守できるかにかかっている。

強い意見は、読者に根拠が見えるときに役立つ

Ivan Pepelnjak はマーケティング上の主張や業界の流行について率直に書く。その文体は、商業文書が避ける問いを投げかける。

ただし経験、証明された仕組み、個人的な好みの区別がつかなくなれば、議論は弱まる。筆者の見解であるとの明示は、その境界を保つ助けになる。

読者が結果を再現または反証できるとき、ラボは信頼を強める。権威のよりどころが名前から実験へ移るからだ。

率直さは編集上の強みであり、反証可能性はそれを支える規律だ。

ベンダー中立性は、ベンダーを比較することで得られる

現代のラボは、イメージの権利者、仮想化基盤、ライブラリ、サポート期間と無縁ではいられない。

実務的な中立性とは、問いを一つの製品だけに合わせず、バージョンを記録し、複数の実装を試し、制約を公表することだ。

netlab は共通の枠組みを作るが、ライセンスや独自機能をなくすわけではない。抽象化が市場を消したと言い張るより、誠実な比較のほうが役立つ。

今後さらに強い証拠となるのは、ラボと実際の判断の変化のつながり

情報源からは、大規模な教育資料の蓄積と活発なプロジェクトの存在が分かる。しかし netlab によって障害を避けた組織の独立した一覧は示されていない。

より強い事例には、不具合の発見、設計の修正、導入の中止や手順の改善までを追い、チームの貢献とほかの要因も残すことが求められる。

ダウンロード数が測るのは関心であり、安全性ではない。現時点で言えるのは、この方法は利用でき説得力もあるが、全体としての効果は測定されていないということだ。

ラボはトポロジーの画像ではなく、問いから始める

美しいトポロジーだけでは試験にならない。仮説、成功基準、観測が必要だ。

問いは、選択される BGP 経路、回線障害への反応、境界を越えるコミュニティの伝達、二つのイメージの違いなどに関するものかもしれない。

入力ファイル、バージョン、観測コマンドを残し、繰り返せるようにすべきだ。否定的な結果も、誤った前提を明らかにするなら有益である。

そうしてラボは、教材の飾りではなく判断の道具になる。

好みの設計を覆せる方法こそ信頼に値する

設計を裏づけるためだけに作った試験は、独立した証拠ではない。モデルの不備、実装の違い、許容範囲を超える障害を示せる必要がある。

Ivan Pepelnjak の実践は、説明、モデル、実験を突き合わせる。信頼は無謬の主張ではなく、食い違いが明らかになる可能性から生まれる。

組織は不都合な結果を残し、レビューに変更を止める権限を与え、例外を解決すべき情報として扱わなければならない。

最も長く残る功績となるのは、自動化を実行可能な仮説とみなし、常にネットワークそのものによって検証する文化だろう。