前回までのおさらい

➡️第2〜3回で、自動化の判断を傾けている前提として、変えられない「NWの性質」と自分たちで埋められる「足りない情報」を見てきました。今回は前提の3つ目、「機器ごとの違い」です。これはそのまま自動化のコストを押し上げるので、今回からコスト・効果・リスクがなぜ「自動化しない」側に傾くのかも見ていきます。最初はコストです。

図1: 連載マップ

この回の要点

NW機器は、同じことをするのにも設定の書き方・処理の順番・名前の付け方が機器ごとに違います。
一つひとつは小さな違いでも、ベンダ・機種・OS・世代の組み合わせで掛け算になります。
この掛け算がNW全体を対象にした自動化を作るコストを押し上げます。規模がなければそのコストは回収できません。

困る場面

ある拠点のNWに、新しいセグメントを追加する作業を自動化しようとしたとします。対象の拠点ではベンダAのルータ、別の拠点ではベンダBのルータ、データセンタではベンダCのスイッチが使われています。さらに、同じベンダAでも数年前に導入した機種と最近導入した機種では OS が違います。

「セグメントを追加する」という目的はひとつなのに、作るべき処理は機器の種類の数だけ必要になります。しかも、機器の OS がバージョンアップされると、その処理の一部が変わってしまうことがあります¹。自動化の処理を書いている時間より、機器ごとの違いを調べて対応している時間のほうが長くなっていきます。

設定の表現が違う

最もわかりやすい違いは設定(コンフィグ)の書き方です。

OSPF を設定する例で比べてみます。

! Cisco IOS
router ospf 1
 router-id 10.0.0.1
 network 10.0.0.0 0.0.0.255 area 0

# Junos
set routing-options router-id 10.0.0.1
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0

同じ OSPF でも、Cisco IOS では router ospf 1 のように process id (1)を指定しますが、Junos には process id という概念がありません。この例では、有効にするインタフェースも、ネットワークアドレスとインタフェース名という別の方法で指定しています。router-id も、OSPF の設定の中に書くか、ルーティング全体の設定として書くかが違います²。自動化の立場から見ると、これは「OSPF の設定を表すデータ」そのものが機器ごとに違うということです。Cisco 向けには process id を持たせる必要があり、Junos 向けには不要……こうした違いを処理の中で書き分けなければなりません。

違いはベンダの間だけではありません。同じベンダの製品でも、OS の種類やバージョンによって、設定の構造が変わることがあります。さらに、ラインカードなど機器のハードウェア構成に依存した操作やコマンドもあります。こうした操作は機器の種類ごとに手順そのものが違います。

中の処理の順番が違う

これとはまた別のハードルが、機器の中でパケットがどういう順番で処理されるか機器ごとに違うことです。

ファイアウォールでパケットフィルタと NAT(アドレス変換)を組み合わせる場面を考えます。機器の中でパケットを受け取ってから送り出すまでに、フィルタの評価、アドレスの変換、経路の決定といった処理が行われます。この順番(パケット処理パイプライン)は標準が決められているわけではなく製品ごとに実装が違います。その結果、たとえば「外部からこのサーバへの通信を許可する」というルールを書くときに、フィルタに書くべき宛先アドレスが NAT で変換する前のアドレスなのか後のアドレスなのか、機器によって変わることがあります。

Configuring NAT in Juniper SRX Platforms using JunOS | TunnelsUP

Cisco ASA Packet Processing Algorithm.

ASR9000 QoS and LAG QoS

図: 製品ごとのパケット処理順序の例(Juniper SRX、Cisco ASA、Cisco ASR 9000。出典は各画像の下のリンク)

「パケットフィルタをしたい」「アドレスを変換したい」というゴールは同じでも、それを実現するためのデータの扱い方が機器ごとに異なります。したがって、こうした処理を自動化しようとすると、設定の書き方を変換するだけではなく処理のロジックそのものを機器ごとに使い分ける必要があります。これは、製品知識を自動化処理のロジックの中に書くということです。

同じことは、FW のクラスタやセッション同期のような冗長化の方式にも言えます。こうした方式には標準がなく、各社がそれぞれの考え方で実装しています。それぞれの方式を理解して、個別に使い分けないと正しく運用できません。

名前が違う

インタフェース(操作対象となるリソース名/識別子)の名前も、機器ごとにバラバラです。

機器・OS	インタフェース名の例	省略形・別名の例
Cisco IOS / IOS XE	`GigabitEthernet0/0/1`	`Gi0/0/1`、`Gig0/0/1`、`Gig 0/0/1`（CDP表示）
Cisco IOS XR	`HundredGigE0/0/0/1`	`Hu0/0/0/1`
Junos	`ge-0/0/1`	なし
Arista EOS	`Ethernet1`	`Et1`

名前の体系が違うだけでなく、同じ機器の中でも正式名と省略形が混在します。コマンドの出力では省略形、設定ファイルではフルネーム…というように場面によって表記が変わることもあります³。自動化処理では、これらが同じものを指していることを判定しなければなりません。

さらに、インタフェース名にはスロットやポートの番号といったハードウェアの構成がそのまま反映されています⁴。ハードウェア構成が変われば名前が変わり、名前が変わればその名前を使っているすべての設定や処理が影響を受けます。この問題は「仮想環境での検証」でさらに厄介になります(➡️第7回)。

機械向けの口が足りない

人が操作するためのインタフェース(CLI)を核にした自動化には限界があります。そのため、NW機器には機械による自動化向けの共通インタフェースが用意されてきました。NETCONF と YANG、そのうえでベンダをまたいだ共通のデータモデルを定義する OpenConfig、gNMI などです。これらは大きな前進ですが現実にはまだ足りない部分があります。

網羅されていない: 共通のデータモデルでは表現できない機能があります。たとえば BGP のポリシのような複雑な設定は共通モデルでの扱いが限られます。
機器固有の機能は入らない: そもそも、特定の機器にしかない機能は共通モデルに含めようがありません。
対応状況がバラバラ: 「OpenConfig 対応」の機器だとしても、OpenConfig のどのデータモデルに対応しているかは機器によって違います。既存の CLI の設定を移行しようとしても一部を表現できないこともあります。

共通データモデル定義は、性質上どうしても様々な機器の「最大公約数」的な定義が中心になります。その結果、その機器固有のとがった機能や高度な設定は織り込みにくくなります。共通モデルで表せない機能でも、ベンダ固有のデータモデルを使えば NETCONF などで扱える場合があります。ただしその場合は、ベンダごとの違いを処理の中で吸収することになります。機械向けのインタフェース自体が対応していない機能では、さらに CLI との併用が必要になります。複数のインタフェースを組み合わせる複雑さを避けようとして、扱っている機器・機能全体をまとめて使える共通部分を取ると、結局 CLI に戻ってしまいます。

繰り返しになりますが、CLI は人が使うために作られたものです⁵。コマンドの出力は人が読むためのテキストで、決まった形式がありません。自動化するなら機種や OS のバージョンごとにパーサを作り、使い分ける必要があります。たとえば、インタフェースの状態と IP アドレスを一覧する、よく使われるコマンドの出力を比べてみます。

! Cisco IOS: show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0/1   192.0.2.1       YES manual up                    up

# Junos: show interfaces terse
Interface               Admin Link Proto    Local                 Remote
ge-0/0/1                up    up
ge-0/0/1.0              up    up   inet     192.0.2.1/24

知りたいことは同じでも、列の並び、状態の表し方、IP アドレスの書き方(プレフィックス長があるかどうか)、論理インタフェースを別の行に出すかどうかが違います。人が読めばパッと見て同じ情報だとわかりますが、機械に解釈させるにはそれぞれの形式に合わせたパーサが必要です。そして OS のバージョンアップで列が1つ増えれば、パーサはうまく動きません(実装次第ですが)。

CLIの操作にもノウハウが必要ですし、そもそも限界があります。

ページング(画面ごとに出力を止める機能, more)や行の折り返しを止めるなど、CLIベース自動化のための設定が必要です。
大量のデータを、テキストの出力としてやり取りするのは効率が悪く、時間がかかります。
改行コード他、ホワイトスペース文字や制御文字は人には「見えない」ことが多く、自動化実装して初めて気づくことがあります。

対照的なのが、SONiC のように、設定も状態もデータベースを中心に持ち、gNMI などの API やストリーミングテレメトリで扱うことを前提にした設計です。自動化の観点ではこのほうがずっと扱いやすいはずですが、そこまで振り切ったアーキテクチャへの変更は、全体をゼロから設計できる新規構築でもない限り難しいでしょう。もし変えるとすると、障害対応などの緊急対応を含む運用体制や要員に求められるスキルセットも一新する必要があります。既存の多くの運用は、これまで蓄積してきた「人が操作する」信頼性と資産をそう簡単には捨てられません。

掛け算になる

ここまで見てきた違いを、まとめて眺めてみます。

設定の書き方、処理の順番、名前、操作のインタフェース。一つひとつの違いはそれだけなら対応できる大きさです。しかし、これらはベンダ × 機種 × OS × バージョンの組み合わせごとに現れます。

そこに、「ライフサイクルの長さ」が加わります(➡️第2回)。NWの機器は数年使い続け、部分的・段階的にしか更新できないので、世代の違う機器が混在するのが普通です。新しい機器を入れるたびに、組み合わせは増えていきます。

試しに計算してみましょう。ベンダが3社、それぞれで使っている OS が2種類、運用中のバージョンが各2つ、操作のインタフェースが CLI と NETCONF の2つ。これだけで、3 × 2 × 2 × 2 = 24 通りの組み合わせになります。自動化したい作業が10種類あれば、その作業ごとに24通りのどれで動くかを確かめる必要があり、確認すべき組み合わせは最大で240通りになります……単純計算では。実際にはすべての組み合わせが使われるわけではありませんが、組み合わせのうちどれが使われていてどれが使われていないかを把握すること自体が、ひとつの仕事になります。

図2: バリエーションの掛け算。

しかも、この数は固定ではありません。機器の OS をバージョンアップすれば確認をやり直す必要があります。新しい機種を入れれば組み合わせが増えます。自動化の処理は一度作れば終わりではなく、環境・機器の変化に合わせて継続的に維持管理が必要になります。

扱うべき組み合わせは、足し算ではなく掛け算で増えます。自動化の処理を作るコストもそれを維持するコストも、この掛け算によって膨らみます。規模が大きければこの掛け算のコストを多くの作業で割って回収できますが、規模に劣るところだと「そこまでする」のは割高に見えてしまいます。

調達で効いてくること

機器の調達は、多くの場合価格や性能、サポート体制などで判断されます。一方、ベンダや機種、OS の種類をひとつ増やすことは、将来の自動化で扱う組み合わせを掛け算で増やすことでもあります。

逆に言えば、調達の段階で「自動化で扱う組み合わせを増やさない」ことを評価軸のひとつに入れれば、将来の自動化のコストを抑えられます。マルチベンダには価格交渉やリスク分散の利点もあるので、単純に減らせばよいわけではありません。ただ、その判断に自動化のコストという項目が入っているかどうかは見ておくべきでしょう。

違いがあるなら、それを吸収する仕組みを作ればいい。そう考えるのは自然です。次回は、その試み(抽象化や共通管理製品)がなぜ思うように使われないのかを考えます。

処理そのものが変わらなくても、コマンドの出力(コンソールへのアウトプット)が変わってしまう…なども含みます。設定自動化では、コマンドを実行したときの標準出力の特定フィールドの値を正規表現で抜き出して成否判定をするようなスクリプトがよく使われます。こうしたスクリプトは、コマンドの出力フォーマットが少し変わるだけでうまく結果が拾えなくなります。 ↩
Cisco IOSの場合、OSPFプロセスごとにrouter-idを設定する。Junosの場合、router-idはOSPF専用ではなく、同じルーティングインスタンス内のBGPなど、router-idを使用するほかのルーティングプロトコルからも参照される共通設定になる。 ↩
Cisco系だとCLIでユーザが入力する場合、”GigabitEthernet”などの名前は「一意に判別できる文字数まで省略できる」ことになっています(Arista EOS 他 Cisco-likeなCLI操作を受け付けるOSはいろいろあります)。表に載せているのはコマンドの出力に表れる省略形の例です。 ↩
もちろん、操作対象とするインタフェースがどのモジュールの何番目のポートなのか、名前から一意にわかるのは必要なことです。ただ、自動化のことを考えるとデメリットもあるということです。 ↩
インタフェース名の省略形も、CLIならタブ補完が効いたり、省略形で入れるとコンフィグにはフルネームで入るといった支援機能があるので、人にとってはむしろ入力が楽になる仕組みです。 ↩