Hatena::ブログ(Diary)

# cat /var/log/stereocat | tail -n3 RSSフィード Twitter

2016-05-04

VyOSでL2透過なNetwork Emulatorをつくる

VyOS で Network Emulator という話は前見ていたので記憶の片隅にあったわけです。

で。こういうのを見つけたわけですね。

思ったわけです。これ二つ組み合わせれば、L2透過 (L2 Transparent) な Network Emulator つくれるんじゃないのか? と。

はい。結論から言うとできました。まあそんなに機能追いかけて検証したわけじゃないけど、ちょっとしたテストくらいだったらこれで充分回せるじゃないだろうか。なお、VyOSのバックエンドで何をどう使っているのかとかを理解しているわけではないので、怪しげなことを書いているかもしれません。ツッコミどころがあったら教えてください。

環境構成

いきなり実機デプロイの図出だしますが、こんな感じでやりました。

f:id:stereocat:20160504203159p:image:w800


はいわかりにくいですね。ごめんなさい。この図で言いたいことは

  • Internal セグメント (VLAN101) と Vyos Expr セグメント (VLAN701) を VyOS(vyos-expr) でブリッジしてひとつの L2 セグメント (192.168.1.0/24) としている。
  • ホスト vyexpr1 (192.168.1.99) に対する通信はかならず Vyos Expr Seg/vyos-expr を経由する。

というあたりです。自宅の環境でやる以上、どうしてもいまある機材の中でどうするかという話があってですね。こういう状態になっていますね。あ、VyOS は 1.1.7 を使っています。

テストに当たって、基本は vyexpr1/vyexpr2 間の通信がどうなるのか、というのが見えれば良いです。ただ、Win10 だと今ひとつだったツールがあったりしたので、DMZ セグメントにいる host1 というのを召喚していたりします。なので、host1 使うのは重要ではありません。新しく VM 立てたりするのが面倒だったから既存の VM を使い回しているだけです。

スイッチ(core2)側のポート設定はこんな感じです。

interface GigabitEthernet1/0/16
 switchport access vlan 701
 switchport mode access
!
interface GigabitEthernet1/0/17
 switchport access vlan 701
 switchport mode access
!
interface GigabitEthernet1/0/18
 switchport access vlan 101
 switchport mode access
!

なお、vyos-expr が接続している vSwitch (vSwitch2/3) は、L2で透過になってほしいので、プロミスキャスモードを有効にしてあります。

ブリッジ設定

まず、物理構成を確認した後、vyos-expr をブリッジとして設定し、vyexpr1 が vyos-expr 経由で(L2透過で)通信できることを確認しましょう。

vyos-exprの設定

  • eth0/1 を bridge-group 追加する、というだけで良いのですが、bridge 自体に IP を振っておくとデバッグ用に使えるのに IP も設定しましょう。(参照; User Guide - VyOS)
set interface bridge br0
set interface bridge br0 address 192.168.1.100/24
set interfaces ethernet eth0 bridge-group bridge br0
set interfaces ethernet eth1 bridge-group bridge br0

今回、br0 に設定した IP をつかって vyexpr2 から ssh していますが、当然このあとの delay/packet-loss 等の設定をすると ssh connection も影響を受けます。リモートアクセス用のパスは別にしておくのがベターだと思います。(面倒だったので今回はやっていませんが…)

スイッチ側の確認(物理接続: MACアドレステーブルの確認)

core2#show mac address-table | inc 1/0/1[6-8]
 101    000c.291a.d732    DYNAMIC     Gi1/0/18
 701    000c.291a.d73c    DYNAMIC     Gi1/0/17
 701    000c.2978.3848    DYNAMIC     Gi1/0/16
core2#

vyos-expr 側の確認

vyos@vyos# show interfaces
 bridge br0 {
     address 192.168.1.100/24
 }
 ethernet eth0 {
     bridge-group {
         bridge br0
     }
     hw-id 00:0c:29:1a:d7:32
 }
 ethernet eth1 {
     bridge-group {
         bridge br0
     }
     hw-id 00:0c:29:1a:d7:3c
 }
 loopback lo {
 }
[edit]
vyos@vyos#

vyos-expr に通信できることがわかったら ssh 接続も有効にしておきます。

set service ssh

遅延

通信遅延の設定。

遅延設定を入れる前に、何もしないときの通信遅延を見ておきます。おおむね 1ms 弱というところですね。なお、最初 vyexpr2 (Windows10) の ping (Cygwin package の ping) でやったんですけど、出力が小数点以下切り捨てになるんですよね。有効数字桁数がちゃんと出てくれた方がなんとなくうれしいので host1 を使っています。

stereocat@host1:/tftpboot$ ping -c 10 192.168.1.99
PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data.
64 bytes from 192.168.1.99: icmp_req=1 ttl=63 time=0.615 ms
64 bytes from 192.168.1.99: icmp_req=2 ttl=63 time=0.713 ms
64 bytes from 192.168.1.99: icmp_req=3 ttl=63 time=0.657 ms
64 bytes from 192.168.1.99: icmp_req=4 ttl=63 time=0.726 ms
64 bytes from 192.168.1.99: icmp_req=5 ttl=63 time=3.03 ms
64 bytes from 192.168.1.99: icmp_req=6 ttl=63 time=1.04 ms
64 bytes from 192.168.1.99: icmp_req=7 ttl=63 time=0.547 ms
64 bytes from 192.168.1.99: icmp_req=8 ttl=63 time=0.610 ms
64 bytes from 192.168.1.99: icmp_req=9 ttl=63 time=0.565 ms
64 bytes from 192.168.1.99: icmp_req=10 ttl=63 time=0.578 ms

--- 192.168.1.99 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8999ms
rtt min/avg/max/mdev = 0.547/0.909/3.032/0.721 ms
stereocat@host1:/tftpboot$

vyos-expr に遅延設定を入れます。

VyOS でネットワーク遅延やロスを発生させるには の丸パクでそのままやります。この後のもだいたいそうです。あと、network-emulator 設定は interface outbound にのみ設定…などの話はこのリンク先を参照してください。

set traffic-policy network-emulator DELAY-100 network-delay 100
set interfaces ethernet eth1 traffic-policy out DELAY-100
vyos@vyos# compare
[edit interfaces ethernet eth1]
+traffic-policy {
+ out DELAY-100
+}
[edit]
+traffic-policy {
+ network-emulator DELAY-100 {
+ burst 15k
+ network-delay 100
+ }
+}
[edit]
vyos@vyos#

再度 ping 実行しましょう。

stereocat@host1:/tftpboot$ ping -c 10 192.168.1.99
PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data.
64 bytes from 192.168.1.99: icmp_req=1 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=2 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=3 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=4 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=5 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=6 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=7 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=8 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=9 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=10 ttl=63 time=100 ms

--- 192.168.1.99 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 100.581/100.677/100.762/0.207 ms
stereocat@host1:/tftpboot$

ちゃんと host1-vyexpr1 間の通信に設定した遅延が乗っかっていることがわかります。

いま eth1 の outbound で設定したので、eth0 の outbound にも同じポリシを設定してみると、当然 200ms の遅延が発生します。

set interfaces ethernet eth0 traffic-policy out DELAY-100
stereocat@host1:/tftpboot$ ping -c 10 192.168.1.99
PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data.
64 bytes from 192.168.1.99: icmp_req=1 ttl=63 time=200 ms
64 bytes from 192.168.1.99: icmp_req=2 ttl=63 time=200 ms
64 bytes from 192.168.1.99: icmp_req=3 ttl=63 time=200 ms
64 bytes from 192.168.1.99: icmp_req=4 ttl=63 time=200 ms
64 bytes from 192.168.1.99: icmp_req=5 ttl=63 time=200 ms
64 bytes from 192.168.1.99: icmp_req=6 ttl=63 time=200 ms
64 bytes from 192.168.1.99: icmp_req=7 ttl=63 time=200 ms
64 bytes from 192.168.1.99: icmp_req=8 ttl=63 time=200 ms
64 bytes from 192.168.1.99: icmp_req=9 ttl=63 time=200 ms
64 bytes from 192.168.1.99: icmp_req=10 ttl=63 time=200 ms

--- 192.168.1.99 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 200.620/200.704/200.761/0.531 ms
stereocat@host1:/tftpboot$

パケットロス

続いてパケットロスの設定にいきます。

set traffic-policy network-emulator LOSS-50 packet-loss 50
set interfaces ethernet eth1 traffic-policy out LOSS-50

遅延設定に続けてやったので

  • eth0 out: delay 100ms
  • eth1 out: loss 50%

となっている点に注意です。

vyos@vyos# show interfaces
 bridge br0 {
     address 192.168.1.100/24
 }
 ethernet eth0 {
     bridge-group {
         bridge br0
     }
     hw-id 00:0c:29:1a:d7:32
     traffic-policy {
         out DELAY-100
     }
 }
 ethernet eth1 {
     bridge-group {
         bridge br0
     }
     hw-id 00:0c:29:1a:d7:3c
     traffic-policy {
         out LOSS-50
     }
 }
 loopback lo {
 }
[edit]
vyos@vyos#

再度 ping 実行してみます。

stereocat@host1:/tftpboot$ ping -c 100 192.168.1.99
PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data.
64 bytes from 192.168.1.99: icmp_req=1 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=4 ttl=63 time=100 ms
(省略)
64 bytes from 192.168.1.99: icmp_req=89 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=91 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=92 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=94 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=95 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=96 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=97 ttl=63 time=100 ms
64 bytes from 192.168.1.99: icmp_req=99 ttl=63 time=101 ms
64 bytes from 192.168.1.99: icmp_req=100 ttl=63 time=100 ms

--- 192.168.1.99 ping statistics ---
100 packets transmitted, 51 received, 49% packet loss, time 99322ms
rtt min/avg/max/mdev = 100.560/100.734/101.324/0.341 ms
stereocat@host1:/tftpboot$

100 発なげてほぼ 50% のパケットロスでした + 片側でのこした遅延の設定もそのまま有効になっていることがわかります。

帯域制御

いったん遅延やパケロスの設定は外します。

帯域測定については、今回は iperf を使いました。

  • vyexpr2 (Win10): iperf 2.0.5 on Cygwin (iperf client)
  • vyexpr1 (ubuntu): iperf 2.0.5-3 (iperf server)

という組み合わせで行きます。

まずは何も設定しない状態での測定。

stereocat@vyexpr2 ~
$ iperf -c 192.168.1.99
------------------------------------------------------------
Client connecting to 192.168.1.99, TCP port 5001
TCP window size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.20 port 56689 connected with 192.168.1.99 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec

stereocat@vyexpr2 ~
$

1Gbps近く出ました。いやまあ、間のリンク全部 1Gbps だからなのですが、でも VyOS Bridge とか挟んだ割にはそれなりに出ましたね…。

帯域制御設定を入れてみます。

set traffic-policy network-emulator BANDWIDTH-100mbps bandwidth 100mbit
set interfaces ethernet eth1 traffic-policy out BANDWIDTH-100mbps

設定や単位についてはこの辺も参照してみてください。

再度帯域測定を実行してみます。

stereocat@vyexpr2 ~
$ iperf -c 192.168.1.99
------------------------------------------------------------
Client connecting to 192.168.1.99, TCP port 5001
TCP window size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.20 port 56814 connected with 192.168.1.99 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 115 MBytes 96.6 Mbits/sec

stereocat@vyexpr2 ~
$

ちゃんと 100Mbps 弱くらいの値になりました。

まとめ

VyOS で L2 Transparent なネットワークエミュレータが作れました。まあ精度とか性能とかでどこまで保証できるのか、というのはともかく、ちょっとした実験であればすぐ使えるんじゃないかと思います。これ、思いつきでちょっと試してみようと思って数時間ですよ…凄いお手軽。このお手軽さでこれだけできるんだからありがたいことです。

2016-04-18

「ネットワークのテスト」は何が難しいのか? (3)

どうやって状態を変化させるか・どのように状態が変化するか

ステートフル/ステートレス

通常、ネットワークには状態(State)があります。「通常」と書いたのは、ステートレスにする組み方も可能ではある、ということですが…。ある程度の規模がある・冗長性のあるネットワークは普通、ステートフルになっていると思います。

というのは、ネットワークの冗長性を実現する多くのプロトコルがステートフルだという点です。VRRP, OSPF, BGP,... どれもステートフルですね。まあ、機器間ネゴシエーションやタイマ動作があるようなプロトコルはステートフルですよね。あともちろん、クラスタ化して動作するNW機器(active-active/active-standbyとか)なんかもステートフルな動作をしますね。

こういう、個々の機器*1やプロトコルの持つ状態それぞれを組み合わせたものが、「ネットワーク(全体)の状態」として扱う情報になります。ステートフルなネットワークでは、あるイベント…たとえばルータのポート障害の発生とそれに伴う経路再計算の動作など…に応じて、どのように次の状態に変化するかは、その時々のネットワークの状態に応じて変化します。

ステートフルなもの・状態遷移のあるものをテストしようとするとどうするか。まず初期状態から一定のイベントを発生させて、そのイベントごとの状態変化と、イベントに応じて「テストしたいもの」= その中を流れる通信状況がどのように変わるか、というのを見ていくことになります。なので、テストは一定の手順(シーケンス)で定義されることになります。

状態変化トリガ

で、テストとしてみるべき「イベント」とは何か。まずは障害試験ですよね。リンクの故障、切断、あるいはデバイスそのものの停止。そういうのをどうやって発生させるか? 実際にケーブルを抜くとか、機材の電源を落とすとか、そういうオペレーションになるわけです。これをネットワーク経由でやりますか? リモート操作でケーブル抜いたり刺したりできないし*2、電源操作は…頑張ればできるでしょうけど、電源切った後どうやって復帰させるとかそういうのがありますよね。復帰させられたとして、「ネットワーク自体が停止するかもしれない」状況に追い込んで、どういう動作をするかを見るわけで、その上での通信保証はないわけです(それをテストする段階なので)。

などなど。こういう操作って他にもいろいろあって、NW機器のOS更新(再起動を伴う)、環境の拡張・縮小(新しくNW機器を追加する・古い機器を止めたり撤去したりする)なんかもそうですね。物理的なケーブル操作とかは現状、手作業に頼らざるを得ないし、機材の操作や情報取得(状態把握)を遠隔でやるなら、テスト対象のネットワークと独立した、NW機器操作用の接続経路とかをちゃんと考えないといけないわけです*3

検証環境でひとつのフロアに模擬環境を組んでやれるのであればまだいいんですよね。これが、遠隔地をつなぐ本番環境ネットワークだと、たとえば東京・九州で構築したシステムだとして、九州で行う環境拡張作業とかその通信テストとか、どうする? というのを考えないといけなくなる。出張しますか? 現地で人を調達できますか? 作業する人用に作業手順書、構築後のテスト手順書書きましたか?

用意できるリソース

これまで書いたようなあれこれを踏まえると、そこそこサイズがあるネットワークとか、複数の場所に移動して作業しなきゃいけないネットワークとかだと、そもそもの作業コストがそれなりにかかるというのはなんとなくわかってもらえる…かな……。本番作業は時間も人手もかかるし、いきなりブッツケ本番作業でいけるっていえるような複雑度じゃなくなっていく。ミスったときの時間的・コスト的リスクがあるので、事前にやった設計で問題なくいけそうかどうかテストするための環境(検証環境)とかを作るし、そこで現地で作業を行う人とか作業用の端末とかを想定してテスト用のリソースを用意したりしますよね。

とはいえ、用意できるリソースにもやっぱり限界があるので、本番環境と同等のものをいつでも全部作れるわけじゃないです。隣接するNW機器や全体の経路の組み合わせを実現させたい、機材の数やサイズの追加・削除とかのオペレーションが可能になるようにしたい……とか、ある程度フォーカスするところとあきらめるところ考えないといけない。機材の数、本番同等の型番機材とOSバージョンの組み合わせ、それらのライセンス費用、保守費用、作業用の端末、作業スケジュールや作業者の人数などなど。準備可能な規模で、どうやってテストしたいことを実現させるか、というのを考えて検証組むわけです。

おわりに

こんな疲れる話を最後まで見る人がどれくらいいるんだろうか?

このシリーズはちょっとした業務上の鬱憤を動機に、業務時間外で作成されました。正直、自分で書いていて疲れました。ちゃんと説明しようと思えば思うほどあさっての方向に転がっていきそうになってしまう。これでもそれなりに話を束ねようとしたんだけど、まだあれが足りてねえとか、イヤそうじゃねえだろとか、いろいろあるでしょうけど、書いていく気力がなくなってきたのでいったんこれで終わりにします…。

まあ何か思うところがありましたらコメントをください。(・ω・)ノシ

*1:TCP自体もステートフルなプロトコルなので、ファイアウォールやロードバランサなどL4の機器はステートフルな動作になります。「情報システムのテスト」の観点ではそうした話も加味した上でテストパターン考えたりします……が、ややこしくなるので今回の話からカットしてます。

*2:電子的に制御できるパッチパネル機材みたいなのを使ってれば別だけどね。

*3:観測側が観測対象から独立していて、観測対象の変化に影響を受けないこと、というのが保証できないと、取得した情報を信頼できない。

2016-04-17

「ネットワークのテスト」は何が難しいのか? (2)

組み合わせ

テストの単位

ネットワークの「単体試験」っていったら何をイメージしますか?

明確にコレが「ネットワークの単体試験」だというのはないんですけど、ひとつの考え方としては、ルータとか、スイッチとか、ファイアウォールとか、ひとつのデバイスに対して、使いたい機能(設定)や要求性能を満たし、想定通り動くかどうか確認する、というのがあるでしょう。

さて。「ひとつのデバイス」に対する通信のテスト。

通信って、コミュニケーションなので、1台だけだと会話にならない。必ずデータをやりとりするノード 2個は必要なんですよね。

ひとつは、テスト対象のNW機器を経由して実際に通信するもの。テスト対象の機器に2台ノード(以上)つないで通信することで、NW機器の機能の、何をどこまでテストをできるか、というのがまずある。あとは? ネットワークって普通たくさんのノードがいるので、そういう環境でちゃんと通信できるかどうかを見たいとしたら? 何十台何百台分のノードを用意する……のは限界があるので、たくさんのノードが生成するであろうトラフィックを生成する専用ツールとかを使ったりするわけです。それでも実際に現実世界で流れるトラフィックは、いろんな人のその時々の要求によって流れる量とか流れるデータの種類が変わるわけで、完全に想定される状況を模擬することはできないんですよね。

あともうひとつ。NW機器は、「どういう風にデータを中継すれば良いか」というデータ転送のための制御情報を相互にやりとりしてたりします。NW機器それぞれが、自分が持っているネットワークの情報を他のNW機器と交換して、ネットワーク全体でどうやってデータを中継・転送すれば良いかを決める。

こういうネットワーク機器の機能(動作)をテストしようとしたときにどうするか。NW機器同士がちゃんと制御情報をやりとりできているかをどうやって見る? 制御情報のやりとり・応答を代行するためのテスト用のツールを使う? 実際、そういうプロトコルの適合性試験(conformance test)をやるツールもあったりします。ただ、NW機器のテストなので、制御信号をやりとりした結果、必要なデータ中継がちゃんと行われているのかをどうやって見るのか、というのもあるんだよね。制御信号を交換して、その上でのデータ転送とかの話までみようとすると…。

結局、ネットワーク全体が設計(想定)したとおりに制御情報を交換して通信サービスを実現してくれるかテストしようとすると、実際使う機材を持ってきて、同じ構成の検証環境作る、あるいは実際に組んでみた本番環境用ネットワークが設計あるいは検証環境でためしたとおりに動くかどうかを確認する、という話になっていく。「単体試験」って、どこからどこまででしょう?

隣接機器間の整合性・経路の組み合わせ

関連して。

TCP/IPなネットワークでの通信(情報伝達)はバケツリレーで例えられますが、これはつまり、隣り合ってるNW機器間でデータの受けわたしをしていくわけです。当然、局所的には2者(2台)でのコミュニケーションというのがある。よって、隣接しているノード同士で、データの交換ができるように、お互いがどうやって情報を交換するかという決めごとの整合性がとれていなければいけない。そしてそれが、通信したいノード、end-to-end の経路全体で成立していかなければいけないわけです。

ということで、あるひとつの経路、あるひとつの隣接関係で整合性がとれているからといって、他の所でも問題なく通信できるようになっているかどうかというのは別物なんですよね。相互接続性とか相互運用性とかいう言葉がありますが、違うベンダの機械で仕様上はつながるはずなんだけど実際やってみたら上手くいかないなんてトラブルもあったりするわけです。(機械そのものの作りだけでなく置かれる環境によるものも…たとえば物理メディアの信号強度あるいはノイズ状況とか、交換する制御情報の解釈の仕方が一部違うとか。いろんな原因が考えられる。)

たくさんあるNW機器、それらの隣接関係の中で、どこか不整合があると、そこをまたぐ通信はできない。本当にすべてのデバイス、環境全体の隣接関係すべてで問題なく通信ができるかどうかを確認しようと思ったら、考え得るすべての経路、隣接関係を通るようテストを組まないといけない。

じゃあ、そういう end-to-end で取り得る経路の数ってどれくらいになるでしょう? 組み合わせ計算とかになっていくので、これは結構な数になるんだよね。なんでもかんでも機器間つなげても複雑化するだけなので、なるべくシンプルで全体の複雑さが押さえられつつ、かつ障害児にちゃんと切り替わることとか、将来的な拡張の余地があるように考えないといけない。だからネットワークトポロジ、ネットワークアーキテクチャみたいな話をみんないろいろ考えるわけです。

実際のテスト作業としても、人手だとそんなたくさんやれないわけです。なるべくシンプルになるようにネットワークトポロジ組むといっても全部の組み合わせを人力作業でやるのはたいてい無理なんですよね。なので、制御信号が交換されていて狙った状態になっているから大丈夫だよね、という形にしたり、一部の代表的なパターンでの通信状況だけテストして、そのほかの部分は設定ファイルの差分チェック(設定上のパターンチェック)とかで終わらせたりする。で、ちょっとした設定の抜け漏れとか、整合性のチェックとかが漏れて、トラブルにつながったりするんだけど……。

そして、複数の機器をまたぐ「経路」の組み合わせ、これを、冗長性とかを考えた上で考えていかないといけないんですね。たとえば機材の故障とか、障害が起きたときに通信全部落ちないように別な迂回経路切り替わるようにしておく。どういう障害に対してどういう経路で通信が通るか。こういうときにはこっちに廻るというパターンを出していって、その通りに経路の切り替え・切り戻しができるかどうかをチェックしておかないといけない……。

物理・論理構成のパターン

だんだん書いてて疲れてきた。

その上で仮想化技術を使ったりします。VLANとかVPNとかVRFとか。最近…この先だと Overlay Network とか? 物理的な構成と論理的な構成が必ずしも一致しなくなってきている。テストとしてパターン網羅したいネットワーク・インスタンスとして、どの物理環境を流れる通信なのか、という話と、どの論理環境の中での話なのか、というのの組み合わせが入ってくる。たとえば、あるセグメントの特定のノードだけなぜか通信できなくなった…というときに、特定のフロアの特定のスイッチのあるリンクでVLANの設定ミスってた、とか。

そういうのをどうやって検出しますか? というのを考えないといけない。物理的な配置・局所性と、その上での論理環境とのマッピングとかが見えてないと判断できない。あとで話を出すけど、どこに何が流れているかは「このときにネットワークがどういう状態だったか」という話が組み合わせに入ってきます。障害が起きて代替経路側を通るようになってる状態で…とかね…。

それぞれの機械が相互に接続・連携して通信(コミュニケーション)を実現してくれるというのは、たくさんの機器が、情報のやりとりのための「共通認識」をちゃんと持っているということなんだよね。で、使われてる共通認識がたくさんある。どれかひとつでもそこが食い違うと上手く通信できない。ということで、今回はその組み合わせに入ってくる要素でぱっと思いつくものについて挙げてみました。でも多分細かく挙げればまだある。が、きりがないのでまた次の話に行きましょう。一応つぎで最後。