Catalystのミラーポートは実際にワイヤーに流れているパケットと一致しない、すべてのパケットが取れているわけではない可能性がvlanまわりである件について


トラブルシューティングでスイッチ間がdot1qでタグ付けされているリンクのパケットキャプチャすることはままあることかと思います。このとき業務影響を出さないようにするためリンク間にネットワークタップを差し込まず、スイッチのミラーポート機能を使ってパケットを取ることが多いと思います。

採取したパケットを眺めてみるとCisco Catalystのミラーポートでとれるパケットは、 **VLANまわりで** 、かならずしもワイヤーに流れているものと一致するわけではないことに気が付きました。なんとなく[ミラーポートで取れるパケット]==[ワイヤーに流れているパケット]と思っていたので、忘れないようにメモを残しておきます。

# 1. 構成とコンフィグ

利用したスイッチ・タップは下記のとおりです。

|型番|OS version|hostname|
|:-:|:-:|:-:|
|C3560CG-8PC-S|IOS 12.2|000sw01|
|C2960-8TC-L|IOS 15.0|000sw02|
|FXG-05RPT|-|000tap01|

構成図は下記のとおりです。

![Network.png](https://qiita-image-store.s3.amazonaws.com/0/38761/5dbeb58b-7f10-de03-dd67-e5bf43294423.png "Network.png")



[コンフィグはgistにあげています]
(https://gist.github.com/tossh0095/5be7a96907441fad83edb31dba60524c)。



# 2. Case 1:Native VLANとして指定していても、ミラーポートで取るとタグがついている

000sw02について、Fa0/6(vlan 100/access)にPCを接続して、Fa0/1(vlan 100,200,300/trunk)のパケットをFa0/2(ミラーポート)で観測すると、VLAN 100はNative VLANとして指定しているにも関わらず、ミラーポートではVLANタグ100が **付与されていました** 。タップでとったパケットにはVLANタグ100は付与されていないので[ミラーポートでとったパケット]!=[ワイヤーでとれるパケット]でした。

![tagged(1).png](https://qiita-image-store.s3.amazonaws.com/0/38761/de2e6416-fdc3-a7dc-97ea-d63328e34372.png "tagged(1).png")



どうもCase 1は機種に依存している動きのようです。000sw01について、下図のように上に述べたのと同様の試験をするとを、上に述べたケースと異なりVLANタグが **付与されていません** でした。

![tagged(2).png](https://qiita-image-store.s3.amazonaws.com/0/38761/e831dd9a-55a5-a2b0-e51f-8c7098f5049c.png "tagged(2).png")


現場でいきなりこの事象に遭遇すると、あれー？Native VLANの指定間違ってんのかなー？みたいにミスリーディングされる可能性があるので要注意です。

# 3. Case 2:VLANを定義しないとミラーポートではパケットがきてないようにみえる

000sw01はvlan 400を定義していません。この状態で000sw02のFa0/8(vlan 400/access)にPCを接続して、000sw01のGi0/2(ミラーポート)で観測するとパケットがとれません。ところが000sw01にvlan 400を定義するとGi0/1のallowed vlanに登録されているかいないかにかかわらず、vlan 400の通信が取れるようになります。tapではvlanが定義されているかいないかにかかわらずvlan 400の通信が取得できるため、vlanの定義がミラーポートに影響を及ぼしているようです。

![vlandefine(1) (2).png](https://qiita-image-store.s3.amazonaws.com/0/38761/a9ab55d5-75c8-7943-fe69-8e1230607ee6.png "vlandefine(1) (2).png")



Case 2は000sw01と000sw02は機種に依存しない動きのようです。少なくとも今回の構成では違いがありませんでした。下図のように上に述べたのと同様の試験をするとを、上に述べたケースと同じくVLAN 300を定義したときにパケットが取れるようになりました。

![vlandefine(2).png](https://qiita-image-store.s3.amazonaws.com/0/38761/e0ff0215-4ccc-2656-1a5a-75a0abae04cc.png "vlandefine(2).png")


スイッチの管理組織が違う場合、対向のコンフィグがわからない(=vlanがお互いに正しく設定されているかわからない)ケースがあると思います。例えば、基幹のネットワーク機器はネットワークエンジニアが管理しているが仮想スイッチ(VMware ESXi vSwitchとか)やブレードサーバ内のスイッチはサーバエンジニアが管理しているケース、協業しているA社とB社のL2接続と言ったケースです。

このときお互いでVLANが正しく定義されていないのを、そもそもパケットが来ていないと勘違いしトラブルシュートが長引く可能性があり要注意です。

# 4. まとめ

ミラーポートで取れるパケットがワイヤーで流れているものと一緒と思うのは早計だと意識することで余計な落とし穴にはまらずに済むようになると思います。

なぜこのような挙動になるのか、理論的な説明はまだ調査できてません。実は「Catalystのアーキテクチャから考えると当たり前じゃん？」なのかもしれません。理論的な側面をご存じの方がいれば、なぜこうなるのかご教示いただきたいです。

この辺の動きはメーカ/OS/機種毎にも違うと思うので、やっぱりミラーポートより専門のネットワークタップを差し込んでキャプチャを取るのが一番確実だと思います。できないのであれば、ミラーポートで取れるものがなんなのか(=期待するものが本当に取れるのか)本番環境でやるまえに検証環境で試すべきであると再認識しました。

今回はタップ製品は比較的安価なものを使いましたが、本格的には[こういうの](http://www.bitrieve.co.jp/products/lan_tap/?page=product-tap-2)とか[こういうの](http://www.ikeriri.ne.jp/develop/profitap/profishark.html)を使いましょう。(別に回し者じゃないですよ。。。）

あとパケットを取得するとき、Windowsは[こういう落とし穴があるので](http://d.hatena.ne.jp/naga_sawa/20090510/1241949218)事前確認は大切です。

サーバポートの解析だったらモニターポートで十分かなぁと一瞬思いましたが、最近は仮想化がすすんで、サーバ内の仮想スイッチに刺さっているケースが多いです。仮想スイッチでvlanタグが使われているので、実質スイッチ間接続なんだよってことをネットワークエンジニアは意識する必要があるなぁと、しみじみ感じました。