1.　はじめに

情報ネットワークを構築・構成変更する準備として，ネットワークエンジニアはその仕様を吟味した後に，ネットワーク機器を設定するための作業手順書を作成する[1], [2]．作業手順書とは，エンジニアの能力によらないよう設定作業の均質化を図り，また設定内容を後から追跡できるように，ネットワーク機器設定コマンドからなる設定手順（以下，機器設定手順）等を明記した手順書である．エンジニアは通常，ネットワーク構成やその変更の仕様を基に手作業で作業手順書を作成するため，作業手順書が実際の仕様と乖離しやすい問題がある．

その改善に直接的に寄与する従来研究として，ネットワーク構成やその変更の仕様に基づき作業手順書を自動生成するアプローチの研究がある[3], [4]．本アプローチは，仕様と整合する作業手順書を得るために有効である．その一方で，複雑かつ多様な機器設定手順を表す作業手順書を正確に自動生成するには，生成元の仕様に対する厳密性や表現力の向上が課題とされる．仕様の厳密性を高める従来研究としては，図記号を取り入れた準形式的な仕様記述であるモデルを活用するアプローチがある[5]–[10]．しかし，これらの手法は，現在可用な仕様のみを網羅するものであり，拡張性を考慮した仕様の表現方法については言及されていない．

その他，AnsibleやNETCONFを用いたネットワーク構成自動管理についても挙げられる．特に，Ansibleに関しては，ネットワークや機器の構成の状態をyamlによってドキュメント化し，仕様をまとめている．また，この仕様からPlaybookを用いたネットワーク作業手順書などのドキュメント生成も可能であると考えられる．しかし，Ansibleによるネットワークの構成変更は，すでにネットワーク機器に関する文法構造を理解していることが前提であり，どのようなエンジニアでも様々なネットワークの変更に容易に対応することは難しいと考える．またネットワーク構成の管理のたびに，コマンドを考慮した仕様を記述することはエンジニアの負担につながると考える．

さて，仕様の拡張性を高めるとしても，現在利用可能な通信プロトコル等を網羅するのでは一過的である．我々は，通信プロトコル等の進化にエンジニアが維持・管理しやすいように仕様記法の拡張性を高めることが肝要と考える．しかしながら，仕様の厳密性と拡張性の両立や，そのような仕様に基づいて作業手順書を自動生成する観点では未だ確立された方法はない．

そこで本研究では，仕様の厳密性と拡張性の両立を指向するため，オブジェクト指向モデリング言語UML（Unified Modeling Language）を応用してネットワーク構成をモデル化する記法を新たに実現した．この記法によるモデルは，ネットワーク機器の設定コマンドにおけるパラメタ値レベルの詳細な情報を提供できる．UMLとは，グラフィカルな記述言語の一種で，単一のメタモデルで構成されており，オブジェクト指向スタイルを使って構築するシステムの記述や設計に用いられるものである[11], [12].

一般的に，情報ネットワークを構築・構成変更する際には，様々なエンジニアからなる設計者によりネットワーク構成を設計するが，その役割は，ネットワークニンジニアがネットワークを構築・構成変更などするための詳細な設計を行うことである．この設計とは，ネットワークエンジニアとしては，悩むことなくきわめて直接的に従うことができる指示になっていなければならない．そこでUMLに着目し，複雑なネットワーク構成の概念や関係を視覚的に表現させ，そしてクラスやオブジェクトなどの詳細な記述により，より具体的かつ細分化を図ることで，仕様の拡張性や厳密性を高めることを期待し，ネットワーク構成をモデル化する記法を提案している．また本研究ではさらに，2つのネットワーク構成モデル間の差分に基づき，ネットワーク機器ごとに機器設定手順を自動生成するシステムも新たに実現した．この方法では，ネットワーク構成モデル間差分の詳細な情報に対してネットワーク機器の設定コマンド列を正確に自動生成でき，かつ生成される設定コマンドをエンジニアが拡張変更しやすいように，モデルと設定コマンドの対応関係記述（以下，機器設定コマンドテンプレート）の記法も新たに実現した．これにより，ネットワークシステムを設計すると同時に，ネットワーク機器に発行するべきコマンドを自動で生成することが可能になるため，エンジニアの負担軽減が見込める．

本研究の評価実験として，OSPFプロトコルを用いた，実運用なネットワークにおいて複数のネットワーク機器の設定に変更が生じる構成変更例に提案手法を適用した結果，すべての設定手順が期待どおりに得られ，期待どおりの振る舞いをするネットワークが構築されたことを確認した．

本稿の構成は次のとおりである．2章で提案手法について説明し，3章では生成された機器設定手順について説明する．また，4章で評価について述べ，提案手法の正当性を確認するための評価とその結果についてまとめる．最後に，5章でまとめと今後の課題を述べる．

2.　提案手法

提案手法を2つのパートで説明する．1つ目はネットワーク構成の文法構造を規定するネットワーク構成メタモデルと，ネットワーク構成のインスタンスを表すネットワーク構成モデルについてである．2つ目は2つのネットワーク構成モデル間の差分と機器設定コマンドテンプレートに基づく機器設定手順の自動生成方法についてである．

2.1　ネットワーク構成のメタモデルとモデル

ネットワーク構成情報とは，結線等のネットワーク機器の構成や，各機器への設定内容をまとめたものである．実運用なネットワークであるほど，その構築や構成変更の失敗を防ぐためにはネットワーク構成情報を明確に記述し，エンジニア間で吟味することが重要となる．設計段階でネットワーク構成情報を明確化するには，ネットワーク機器に対する設定コマンドのパラメタ値といった構築・構成変更時に必須なデータをそのままの粒度で表すことが重要であり，かつ，それらデータを整理しやすい記法も重要である．

従来の典型的なネットワーク構成図[2]では，ネットワーク機器などのネットワーク要素のアイコンを線で繋ぐことでネットワーク構成を分かりやすく図示するものであるが，各機器の設定を記述する空間は取りにくく曖昧になりやすい．加えて，各機器の設定詳細を任意で記述するにしても自由記述にならざるを得ないため，書き手の能力に大きく依存して質が保証しにくい．

情報の充実化と記述の形式化を図った方法として，吉澤ら[4]のシステムでは，ネットワーク構成図を図示でき，かつ各ネットワーク機器の設定詳細を入力できるダイアログも表示できる．そのため，典型的なネットワーク構成図に比べてネットワーク構成を厳密かつ詳細に管理できる．しかし，ネットワーク機器の設定項目を拡張変更する場合にはソフトウェアの改変が必要であり，そのような改変作業は一般に高コストである．本システムのデータ構造を明文化した仕様を活用できるならば，設定項目の拡張容易性を高めることに向くが，仕様記述に基づく作業手順書生成のアプローチは示されていない．

そこで本研究では，ネットワーク構成やその変更の仕様について厳密性と拡張性の両立を指向するため，オブジェクト指向モデリング言語UMLを応用したネットワーク構成のモデル化記法を実現した．提案記法の主な登場概念として，ネットワーク構成の仕様項目を構造的に規定するネットワーク構成メタモデル（以下，単にメタモデルとも呼称）と，具体的なネットワーク構成を表すネットワーク構成モデル（以下，単にモデルとも呼称）がある．たとえば，メタモデルでは“port”等の仕様項目を規定し，モデルでは“port”に対して“$\tt{2}$”等の値を表現する．以下の項で，メタモデルとモデルについて詳解する．

2.1.1　ネットワーク構成メタモデル

図1に，本稿が係わる部分のメタモデルを示す．メタモデルはUMLクラス図の記法をベースに表される．主な構成概念を図中の番号（1）～（6）に対応させ，次にまとめる．

• (1) $\tt{ipAddress}$や$\tt{port}$等の互いに関連が強い仕様項目をまとめた仕様項目グループ（例：$\tt{EthernetSetting}$をラベルとする大きな四角形）がある．ここで$\tt{EthernetSetting}$はグループ名である．
• (2) 仕様化すべき項目を表す仕様項目（例：$\tt{port:int}$）がある．ここで$\tt{port}$は項目名であり，$\tt{int}$は型である．
• (3) 仕様項目グループ間の関係性を規定する関係（例：$\tt{OspfSetting}$と$\tt{Config}$の間の線）がある．
• (4) 関係の端には多重度（例：^＊）と呼ぶ記述があり，^＊は“0個以上”を意味する．たとえば$\tt{OspfSetting}$が1個存在したときに関係する$\tt{OspfVirtualLink}$が0個以上存在することを表す．なお，$\tt{0..1}$は“0個または1個”を意味する．
• (5) 白三角付きの関係は汎化と呼び，三角側の性質を無印側が引き継ぐことを意味する．この意味論により，たとえば$\tt{Client}$は$\tt{Link}$と関係があるとみなせる．
• (6) 黒菱形付きの関係はコンポジションと呼び，菱形側が無印側を専有することを意味する．この意味論により，たとえば1個の$\tt{OspfSetting}$が，ある複数個の$\tt{OspfInterfaceSetting}$を共有するような関係は持てないとみなせる．

したがって，本研究におけるメタモデルは，物理設計観点の仕様項目群（例：$\tt{Link}$や$\tt{LinkableElement}$）と，論理設計観点の仕様項目群（例：$\tt{EthernetSetting}$や$\tt{OspfSetting}$）を組み合わせて定義されている．このようにメタモデルでは異なる観点の仕様項目の構造を1つの記法で一貫的に整理できる．

また，本稿における論理設計観点の仕様項目のほとんどはCisco製ネットワーク機器のコマンド体系を基に定義されている．そのため，図1に示される仕様項目は多くないが，当該体系に一貫した拡張は容易である．一方で，本稿のメタモデルではマルチベンダ対応を指向していないが，Cisco製機器のコマンド体系と整合性が高い他ベンダの機器については対応は比較的容易と考えられる．

2.1.2　ネットワーク構成モデル

図2にモデルを例示する．モデルはUMLオブジェクト図の記法をベースに表されている．モデルは図1のメタモデルに準拠している．この準拠とは次の（1）～（3）のことを意味する．また，図中に登場する（1）～（3）と対応している．

• (1) メタモデルの仕様項目グループを型とした値（以下，グループ値；例：$\tt{Cf1:Config}$をラベルとする大きな四角形）を作成している．ここで$\tt{Cf1:Config}$を識別子と呼び，$\tt{Cf1}$をグループ値名と呼ぶ．また，$\tt{Config}$は仕様項目グループ名である．
• (2) グループ値ごとに仕様項目に値（以下，項目値；例：$\tt{name = campus1}$における$\tt{campus1}$）を与えている．
• (3) 仕様項目グループ間の関係を満たすようにグループ値間の線（以下，関係値）を記述している．

なお，項目値が空値の仕様項目は，たとえば$\tt{name = campus1}$の=以降の記述が存在しない．ここで，等号（=）はUMLオブジェクト図の意味論に基づき，左辺の仕様項目に右辺の項目値が与えられた状態を示す．

2.2　機器設定手順の生成手法

図3に，機器設定手順の生成手法の概要を示す．本手法では，2つのモデル間の差分に基づき機器設定手順を生成する．この2つのモデルは，変更が必要な現状のネットワーク構成を表すモデル（AsIsモデル）と，変更後にあるべきネットワーク構成を表すモデル（ToBeモデル）の関係にあることを前提とする．以下は，本手法のフローである．

1．手法利用者の入力　本手法では，後述するAsIsモデル（図6）とToBeモデル（図7），機器設定コマンドテンプレート（図8）の3つを手法利用者の入力とし，機器設定手順を最終出力とする．ここでの機器設定手順とは，AsIsをToBeに変えるために必要となる，ネットワーク機器ごとに得られる機器設定コマンド列の集合である．モデル間差分に基づき生成する理由の1つとして，適用後のネットワークに不具合が生じた場合，切り戻しを容易に行うことができる利点がある．単に，AsIsモデルとToBeモデルから機器設定手順を生成することも可能ではあるが，元のネットワーク構成からの差分を参照できないため，切り戻しが難しいと考えられる．加えて，ACL（Access Control List）が適用されているインタフェースの変更やリモートからの作業を考慮すると，必要箇所だけの機器設定手順を生成することが望ましい．

2．モデル間差分の検出　本ステップでは，AsIsとToBeのモデル間差分を検出する．モデル間差分とは端的に，設定解除が必要な設定内容と，新規設定が必要な設定内容を併合した情報である．モデル間差分を得ることで，AsIsからToBeに変えるために必要な機器設定コマンドを特定できる．モデル間差分の検出手順については，2.2.1項で詳述する．

3．機器設定手順の生成　本ステップでは，モデル間差分に基づいて機器設定コマンドテンプレートを具体化することで，機器設定手順を生成し，最終出力とする．機器設定手順の生成手順については2.2.2項で詳述する．

本手法の説明事例として，図4のネットワーク構成を図5に変更するケースを扱う．また，紙面の都合上，AsIsモデルとToBeモデルに関しては一部のみの掲載とする．本例は，信州大学のネットワーク[13]を模倣したものを取り上げており，スタティックルーティングで構成されたネットワークから，OSPFプロトコルを用いたダイナミックルーティングで構成されるネットワークの設定を行うものである．図4，図5のそれぞれに対応するモデルを図6，図7に示す．

2.2.1　モデル間差分の検出

モデル間差分とは，AsIsとToBeのモデル間における項目値の差異を指す．項目値に差異があったとき，AsIsモデルの項目値はネットワーク機器から解除が必要であり，ToBeモデルの項目値はネットワーク機器への新規設定が必要となる．本ステップの目的は，設定解除すべき項目値に$\tt{unset}$ラベルを与え，新規設定すべき項目値に$\tt{set}$ラベルを与えることである．

次にモデル間差分の検出アルゴリズムを説明する．前提として空値（使用しなかった項目）の項目値は必ずラベル無しとする．そのため，次から説明する手順でのラベリング処理は，空値でない項目値に対してのみ行う．まず，AsIsとToBeのモデル間で識別子（例：$\tt{Cf1\_Hn}$や$\tt{Cf1\_Vl1}$）が同じグループ値をペアとする．グループ値のペアが成立した場合，ペア内の同名な仕様項目間で項目値に差異があれば，AsIs側の項目値に$\tt{unset}$を与え，ToBe側の項目値に$\tt{set}$を与える．もしAsIsとToBeでモデルが異なるなどして同名の仕様項目がない場合，AsIs側のみにある仕様項目の項目値に$\tt{unset}$を与え，ToBe側のみにある仕様項目の項目値に$\tt{set}$を与える．一方，グループ値のペアが成立しなかった場合，そのグループ値が有するすべての項目値に対し，項目値がAsIs側にあれば$\tt{unset}$を与え，ToBe側にあれば$\tt{set}$を与える．このようにして，新規設定または更新する場合と設定解除をする場合にラベルを付与することで，生成するべきコマンドの情報を得ることができる．また，厳密な識別子の書き方については特に定めていない．

図6と図7に示されるように，ネットワーク機器で設定不要な項目値（例：結線情報を表す$\tt{Link}$中の$\tt{description}$の項目値）にラベルが与えられている．本手法で登場する$\tt{Link}$や$\tt{Client}$とは，ネットワーク機器やクライアントとの接続を表す仕様項目グループであり，機器設定手順を生成する際のコマンドは登場しない．そのため，変更前後においてラベルが付与されていたとしても無視するものとする．このような項目値は，機器設定手順の生成アルゴリズムや機器設定コマンドテンプレートにより最終出力から除外するものとする．

2.2.2　機器設定手順の生成

前ステップで得られたモデル間差分をネットワーク機器の設定に反映するには，各項目値のラベルに応じた機器設定コマンドが必要となる．

図8に機器設定コマンドテンプレートを例示し，表1で構成要素を説明する．ネットワーク機種が異なる場合，設定コマンドの体系も異なることがある．これを踏まえて，ネットワーク機種ごとに機器設定コマンドテンプレートを作成できるように，$\tt{Config}$の$\tt{deviceModel}$の値と，（図8には表れないが）機器設定コマンドテンプレートの名前を同名にして対応づける．また，図8の$\tt{Spec. \ Item \ Group}$に記載がない仕様項目グループ（例：$\tt{Link}$や$\tt{Client}$）は，機器設定手順の生成には利用しない．

その他，ACL（$\tt{AccessList}$）など，順序の制約が強いものに関しては機器設定コマンドテンプレート等を用いた順序の制約は与えず，モデル内で登場する関連に制約を与える．たとえば，図1で登場する$\tt{AccessList}$では，0から1の多重度を持つ自己参照を行うことで，$\tt{AccessList}$のインスタンスが，自分自身と同じ型のインスタンスを参照することになり，単方向リストを表現している．これにより，ネットワーク構成モデル内で登場する$\tt{AccessList}$の機器設定手順は，関連づけされている順番から機器設定手順が生成されるアルゴリズムとなっている．また，ネットワークを運用する際，ACLに追加や削除などの変更を加える場合がある．一般的に，ACLの変更には次の2つの方法があると考えられる．

1．既存のACLを編集する方法　ACLに書かれた条件文には，それぞれシーケンス番号が与えられている．シーケンス番号とは，ACL内で定義した条件文それぞれに昇順に割り当てられた番号であり，ルールが実行される順序を表している．通常，シーケンス番号は指定が無い限り，等間隔（例：10条件文A 20条件文B ...）に与えられ，この番号を用いることで既存のACLに変更を加えることができる．ACLを追加する場合は，等間隔に設定されたシーケンス番号の間に入れるようにシーケンス番号を付与して行う．たとえば，シーケンス番号10が割り当てられた条件文Aと20が割り当てられた条件文Bの間に条件文Cを追加したい場合は，条件文Cのシーケンス番号を11から19のいずれかを与えて追加することで，条件文との間に設定を追加することができる．一方で削除する場合については，削除したい条件文に割り当てられたシーケンス番号を指定することで条件文を削除することができる．また，シーケンス番号は等間隔に均すことができるため，設定変更の都度行う．

2．新たにACLを作成する方法　既存のACLを残したまま新たに別のACLを作成し，設定変更をする方法がある．1の方法と異なり，シーケンス番号を考慮する必要がなく，既存のACLの条件文を含め，新たに追加したい条件文を併せてACLを新たに作成する．

本手法では，“2．新たにACLを作成する方法”を採用しており，ACLに変更があった場合，既存のACLに変更は加えず，新たにACLを作成し，適用し直すことで設定変更を行っている．

次に機器設定手順の生成アルゴリズムを説明する．モデルに$\tt{Config}$グループ値が複数登場する場合は，下記（1）–（7）の処理は$\tt{Config}$グループ値ごとに行うものとする．

• (1) コマンドを処理順で保持するリスト（以下，$\tt{list}$）と，$\tt{Dep. \ ID}$に基づく優先コマンド関係を階層構造にして保持するツリー（以下，$\tt{tree}$）の2つを用意する．（図9右が$\tt{list}$と$\tt{tree}$のイメージとなる．）

  

• (2) 図9に示すように，$\tt{header}$コマンドを$\tt{list}$に入れ，もし$\tt{list}$要素内のコマンドC_aに優先コマンドC_pがあれば，C_pを上位とし，C_aを下位とするコマンド構造を$\tt{tree}$に反映する．状況によっては，$\tt{list}$要素内のコマンドC_bに複数の優先コマンドC_p1，C_p2（ただし，ind(C_p1)＜ind(C_p2)）が存在する場合がある．ここでind(C)は$\tt{list}$中のコマンドCのindexを取得する関数とする．このときは，indexの大きい（直近の）コマンドC_p2に対して，C_p2を上位とし，C_bを下位とするコマンド構造を$\tt{tree}$に反映する．
• (3) 設定解除コマンドを生成するため，AsIsモデルの$\tt{Config}$を次のように処理する．
  • (a)$\tt{Config}$を根ノードとした木構造としてモデルを捉え，行きがけ順深さ優先探索を行う（図10）．ただし，別の機器への結線情報である$\tt{Link}$に到達したときは，$\tt{Link}$は処理せずに引き返して探索に戻る．

    

  • (b)探索中に到達したノード（仕様項目グループ値）に対し，機器設定コマンドテンプレートにおける当該グループ値に対応づく$\tt{unset}$分類の$\tt{Command}$を上から順に処理する（図11）．つぎのどちらかの条件を満たしたときに，$\tt{Command}$を項目値で具体化して$\tt{list}$へ追加し，優先コマンドがあれば$\tt{tree}$に反映する．

    

条件1.

• ・$\tt{Spec. \ Item}$に紐づく項目値に1つでも$\tt{unset}$ラベルがある，かつ，
• ・仕様項目名に対応する項目値がすべて非空値である（仕様項目名が1つも存在しない場合は真とみなす），かつ，
• ・$\tt{Condition}$を満たす（$\tt{Condition}$が空値の場合は真とみなす）．

条件2.　$\tt{Modal}$が$\tt{true}$である．（当該コマンドの真の必要性は後で判定する．）

• (4) 新規設定コマンドを生成するために，ToBeモデルの$\tt{Config}$に対し，設定解除コマンドと同様な手順で$\tt{Command}$を処理する．ただし，この手順では，前述の設定解除コマンドの手順中の“$\tt{unset}$”の部分を“$\tt{set}$”に読み替えるものとする．
• (5) $\tt{footer}$コマンドを$\tt{header}$コマンドと同様に処理する．
• (6) $\tt{mode}$-$\tt{before}$コマンドと$\tt{mode}$-$\tt{after}$コマンドを次のように処理する（図12）．

  

  • (a)$\tt{Modal}$が$\tt{true}$な機器設定コマンド（$\tt{Modal}$コマンド）について，Spec. Itemに紐づく項目値に$\tt{set}$および$\tt{unset}$のラベルが無く，かつ，$\tt{tree}$上で下位コマンドが1つも無いものを冗長な$\tt{Modal}$コマンドとして$\tt{tree}$から削除する．
  • (b)$\tt{tree}$を行きがけ順深さ優先で探索して，$\tt{Modal}$コマンドの前隣りに$\tt{mode}$-$\tt{before}$のコマンド（群）を追加し，$\tt{Modal}$コマンドの後ろ隣りに$\tt{mode}$-$\tt{after}$のコマンド（群）を追加する．このとき，$\tt{mode}$-$\tt{before}$や$\tt{mode}$-$\tt{after}$のコマンドがそれぞれ複数存在する場合は，順序は機器設定コマンドテンプレートに定義された順とする．
• (7) $\tt{tree}$に対し，図13に示すように行きがけ順深さ優先探索をして到達したノード（機器設定コマンド）順に$\tt{list}$を再作成することで，最終的な機器設定手順を生成する．

  

3.　生成された機器設定手順について

2.2.2項で詳述した，生成された機器設定手順について詳解する．紙面の都合上，生成された例として，一部のみを掲載している．適用事例の$\tt{Cf1}$に着目し，機器設定手順を生成してみると，図14で示すように，変更差分のみが生成されていることが分かる．また，設定削除をするためのコマンドが生成されている点からも，不要になった情報を差分から検出できていることが確認できる．生成された機器設定手順は，各ネットワーク機器のコンソールモードから発行（コピーしてペースト）することで，ToBeネットワークに必要な設定が行われる．

4.　評価

図4と図5で示したネットワークを適用事例とし，期待される機器設定手順を生成できるかどうかの観点から提案手法の有効性を評価した．本評価では，提案手法を実行するツール（提案ツール）を2.2.1, 2.2.2項で詳述したアルゴリズムを参考にJavaで試作して用いた．また本手法では，モデルの作成にastah [14]を用いており，astahでは作成したモデルの情報をJavaプログラムから抽出するためのAPIを提供している．そのAPIを利用することで，モデル間差分の検出に必要な情報の取得し，ラベルの付与をアルゴリズムに沿って行っている．また，その情報に付与されたラベルと機器設定コマンドテンプレートを用いることで，実行可能な機器設定手順の生成を行う．さらに，提案ツールより生成された機器設定手順の正しさを確認するために，実機を用いて検証を行った．その際，ネットワーク運用管理のエキスパート1名の助力を得て，ルーティングテーブル，断線時の経路変更が正しく行えるかどうかの計2つの項目について確認をした．

4.1　適用事例のネットワーク

本評価で用いる適用事例のネットワークの構成について詳解する．今回用いた適用事例は，各キャンパスの拠点間の相互接続を小規模化し，表している．

4.1.1　変更前のAsIsネットワーク

変更前のAsIsネットワーク（図4）は，以前，信州大学で運用されていたネットワークを再現したものである．ルーティングには，スタティックルーティングを採用しており，ルートを手動設定し，冗長構成が考慮されていない運用形態となっている．そのため，一か所でネットワーク障害が発生してしまうと，障害発生個所の拠点からの通信が途絶えてしまうようなネットワーク構成となっている．また，それぞれのネットワーク機器の名前（$\tt{Hostname}$の$\tt{name}$）を$\tt{campus1}$から$\tt{campus6}$までとしている．また，$\tt{campus1}$から得たルーティングテーブルの情報をリスト1に示す．このとき，$\tt{C}$は，$\tt{connected}$を意味し，直接接続されていることを表す．また，$\tt{S}$は，$\tt{static}$を意味し，設定したスタティックルートを表す．

4.1.2　変更後のToBeネットワーク

次に，変更後のToBeネットワーク（図5）は，現在，信州大学で運用されているネットワークを再現したものである．ルーティングには，ダイナミックルーティングとスタティックルーティングを併用しており，主にダイナミックルーティングではOSPFプロトコルを採用しているため，エリアを複数に分けた，冗長構成が考慮されている運用形態となっている．そのため，一か所でネットワーク障害が発生した場合には，迂回経路に自動で切り替わるようなネットワーク構成となっている．また，それぞれのネットワーク機器の名前（$\tt{hostname}$）を，$\tt{campus1}$から$\tt{campus7}$，$\tt{dc}$（データセンタ），$\tt{top}$（出入口）としている．

4.2　機器設定手順の評価

自動生成された機器設定手順の評価について詳解する．一般に一回の構成変更に対して必要かつ妥当なコマンド列は複数仮定できるが，本評価では（1）ネットワーク運用管理のエキスパートが受容でき，かつ（2）実ネットワーク機器を用いて構築した（AsIsの）ネットワークへ適用した後に期待された動作かどうかを，ルーティングテーブルと経路確認により評価する．特に（2）の動作確認については，ICMPプロトコル[15]を使用したネットワーク断線時の経路の確認を行い，期待とおりに動作するかを確認した．ここでの期待とおりの動作とは，各機器間（図5で示したネットワーク機器間）のパケット送受信において欠損が無いことと，経路情報が問題なく得られるか（図5で示したネットワーク機器間の経路情報）の2つの条件を満たすものである．

4.3　準備

本評価で用いた具体的な入力データ，機材は以下のとおりである．

• ・AsIsモデル（図6）
• ・ToBeモデル（図7）
• ・機器設定コマンドテンプレート（図8）
• ・Cisco 1812-J ^＊ 7台（Version 12.4(15)T11）
• ・Cisco 892 ^＊ 2台（Version 15.1(4)M5）

また，AsIsモデルとToBeモデルは，モデリングツールastahにより作成し，機器設定コマンドテンプレートはCSV形式により表現した．

次に，実験手順を以下に示す．

• (1) 実験者が，入力データを提案ツールに入力して機器設定手順を生成する
• (2) ネットワーク運用管理のエキスパートが，生成された機器設定手順に問題があるかどうかを確認する
• (3) 実験者が，ToBeネットワークを構築するため，生成された機器設定手順を実機に発行する
• (4) 実験者が，ネットワークの運用管理のエキスパートの監視の元，ルーティングテーブル，断線時の経路を確認することで，期待どおりの振る舞いかどうかを確かめる

4.4　結果

生成された機器設定手順を実機に発行し，ルーティングテーブルの確認とtracerouteコマンドによる経路の確認，さらには，意図的に断線障害を起こし，目的のネットワーク機器への経路が正しく表示されるかどうかの確認を行ったところ，正常にネットワークが動作していることを確かめた．一方で機器設定手順の生成において，$\tt{Config}$を根ノードとした仕様項目グループの探索では，$\tt{Config}$の子ノードにあたる仕様項目グループ値間に探索順序の制約が与えられていないため，実行によっては区切られたコマンド列（例：$\tt{vlan}$と$\tt{hostname}$）間が入れ替わる結果が得られることがあったが，本例においては，機能的には問題がないことを確認した．

4.4.1　ToBeネットワークのルーティングテーブル

AsIsネットワークの各ネットワーク機器と新しく追加したネットワーク機器に対し，実際に出力された機器設定手順を発行した．その際の，$\tt{campus1}$から得たルーティングテーブルをリスト2に示す．このとき，$\tt{O}$は，LSA Type1, Type2によって得られた経路情報を表しており，$\tt{O;AI}$は，LSA Type3によって得られた経路情報を表している．いずれも，OSPFプロトコルが適用されているため，異なるエリア間でも，問題なく経路情報が得られていることが分かる．

4.4.2　断線障害によるルーティングテーブルの様子

OSPFプロトコルが問題なく適用されているかどうかを確かめるために，意図的に断線障害を起こし，経路情報を確認した．$\tt{campus4}$から$\tt{top}$に向けて，tracerouteコマンドを発行した様子をリスト3に示す．このとき，すべての経路に関して，$\tt{campus4}$から$\tt{top}$までのルートを全て網羅していることから，動作に問題がないことが確認できる．次に，$\tt{(campus4)}$から$\tt{campus5}$間のネットワーク（10.0.6.0/24）を断線させた場合の経路の様子をリスト4に示す．このとき，断線されたネットワーク（10.0.6.0/24）を経由せず，迂回経路を判断し，$\tt{top}$までの経路を示していることから，期待どおりの振る舞いをしていることが分かった．

4.5　考察

評価結果に基づき，期待どおりのネットワーク機器設定手順が得られたことは，提案手法に一定の有効性があったことを示していると言える．これにより，提案手法では，モデル間差分が適切に得られ，そこから必要な機器設定コマンドが機器設定コマンドテンプレートを通じて妥当に得られた．

加えて，機器設定手順を自動生成することの効果として，エンジニアによる記述の抜け漏れの防止や誤解への気づきやエンジニア間の記述ポリシーの違いの発見，そして設計段階における機器設定手順の生成によるエンジニアの負担軽減にも役立つ見込みを得た．一方で，本手法を適用するにあたり必要となるモデルを作成するエンジニアへの負担については考慮していない．特に仕様項目値の重複によって，同一ネットワークのIPアドレス等の重複や，妥当ではない値を付記したモデルの不備による不適切な機器設定手順の生成へとつながる可能性が考えられる．そこで，これらの対策として，エンジニアがモデルを作成しやすいように，モデル作成段階でモデルチェックが可能な静的検証[16]ツールの開発や，ネットワークシミュレータを用いたモデル作成後の動的検証[17]ツールの開発をすることが望ましいと考えられる．

また，本評価の適用事例は，ACLやOSPFプロトコル，VLAN等の機能に対応しているが，他にも様々な機能やプロトコル，そして他ベンダ機器による独自プロトコルなどが存在する．そのため，提案手法をさらに拡充し，そのうえで有効性を評価することが今後の課題となる．また，$\tt{Config}$の子ノードの探索順序の制約化や，エンジニアのポリシーに応じた機器設定手順の生成に提案手法が柔軟に対応できるか否かは評価できていない．

その他，ACLの設定変更においては作成時のモデルに依存するため，既存のACLに変更を加える場合については考慮していないことが明らかになった．本手法を用いたACLの設定変更を行う場合には，既存のACLに変更は加えず，新たにモデル内にACLに関する情報を記述し，機器設定手順を生成する．そして，新しく作成されたACLを適用することでACLの設定変更を行う仕組みとなっている．しかし，これらのACLの変更に関しては，変更作業の状況に応じて選択をすることが適切であり，エンジニアのポリシーによって異なると考えられる．そのため，既存のACLに変更を加えられる機器設定手順の生成システムを実装し，エンジニアのポリシーによって生成方法を選択できることが望ましいと考えられる．

5.　おわりに

本稿では，ネットワーク構成モデルに基づく機器設定手順の自動生成手法を提案した．提案手法は，2つのネットワーク構成モデル間の差分から，機器設定コマンドテンプレートを通じて機器設定手順（機器設定コマンド列）を生成するものである．実運用ネットワークを適用事例として提案手法の有効性を評価した結果，期待どおりの機器設定手順を提案手法により生成することができ，提案手法が有効であったことを確認した．

今後の課題として，エンジニアのポリシーに応じた柔軟な機器設定手順を生成できるように提案手法を拡充し，その有効性を定量的・定性的に評価することが挙げられる．また，マルチベンダを前提とした機器設定コマンド生成に対する提案手法の汎用性評価や，未対応の様々なプロトコルを適用した実運用ネットワークでの提案手法の有効性評価が挙げられる．さらには，作業手順書の自動生成に向けた提案手法の拡充や従来手法との連携方法の模索も挙げられる．まずは提案手法のさらなる表現力の向上と本手法における適用範囲の限界の調査，また機器設定手順の作成ポリシーについて様々なエンジニアへの調査を行っていきたい．

また，今回提案したモデルの作成時間や妥当性の評価についても今後の課題となるが，ネットワーク自動化手法として挙げられる，AnsibleやNETCONFを組み合わせたネットワークの自動生成手法に関しての連携方法についても考慮をしていきたい．

謝辞　本研究を実施するにあたり，信州大学ネットワークの管理・運用に当たっているNTT東日本様のご協力を得ましたので，ここに感謝の意を表します．また，本研究はJSPS科研費JP17KT0043の助成を受けたものです．