VTP(VLAN Trunking Protocol) Part.1
VTPに関する解説はこちらを参照してください
VTP（ VLAN Trunking Protocol ）とは
VLAN Trunk Protocol（VTP）について - Cisco
今回はVTPメッセージの中身を見ていきます。VTPメッセージには以下の種類があります。
・要約アドバタイズメント
・サブセット アドバタイズメント
・アドバタイズメント要求
・VTP 加入メッセージ
----------------------------------------------------------------------------------------------------------------------
VTPフレームをキャプチャするためには、SPANの宛先設定で
encapsulation replicate オプションを付ける必要があります。この設定によりタグ付きフレームをキャプチャすることができます。
----------------------------------------------------------------------------------------------------------------------
ここでは要約アドバタイズメントとサブセットアドバタイズメントの内容を見ていきます。なお、VTPドメイン名は「CCNP」としています。
要約アドバタイズメント
(1)宛先MACアドレス
Destination: CDP/VTP/DTP/PAgP/UDLD (01:00:0c:cc:cc:cc)
(2)メッセージの中身
VLAN Trunking Protocol
Version: 0x01 ←VTPバージョン
Code: Summary Advertisement (0x01) ←メッセージ種類
Followers: 0
Management Domain Length: 4
Management Domain: CCNP ←ドメイン名
Configuration Revision Number: 5 ←リビジョン番号
Updater Identity: 192.168.1.1
Update Timestamp: 93-03-01 00:44:11
MD5 Digest: 0da9a2dc6fc3be7958046bf02df81d4a
サブセットアドバタイズメント
(1)宛先MACアドレスは共通
(2)メッセージの中身
VLAN Trunking Protocol
Version: 0x01
Code: Subset Advertisement (0x02)
Sequence Number: 1
Management Domain Length: 4
Management Domain: CCNP
Configuration Revision Number: 6
VLAN Information ←VLAN情報
VLAN Information Length: 20
Status: 0x00
.... ...0 = VLAN suspended: False
VLAN Type: Ethernet (0x01)
VLAN Name Length: 7
ISL VLAN ID: 0x0001 ←VLAN番号
MTU Size: 1500
802.10 Index: 0x000186a1
VLAN Name: default ←VLAN名
VLAN Information
・・・省略・・・
以上です。Part.2ではVTP V3の設定とVTPプルーニングの動作を検証します。
loopdetect検証(続)
時間が空きました。SR-X324T2のloopdetect機能検証の続き。
・loopdetect portdisable
・loopdetect portblock
・syslog、SNMP TRAP
構成
port1と2を直結させる
loopdetect portdisable
以下を設定。
(ちなみに上記コマンドの後 commit コマンドを実行しないと設定が反映されません。富士通製の仕様)
loop検知後の結果
(リカバリ時間はinterval 10s × 10の100秒)
両ポートで検知しているため、どちらもportdisableになっています。
そしてリカバリ時間が経過しても自動で復旧しません。復旧させる場合は以下のコマンドを実行します。もちろんループ状態を解除してからです。
実行後は即元通りになります。
portdisableオプションは手動で復旧させなければならない点が注意です。
loopdetect portblock
以下を設定。
loop検知後の結果
portdisableと異なり、countの値が表示されています。ループ状態が解除された後、
countが10になる(100秒経過する)と自動的にportblockが解除される仕様です。
(今回の構成ではループ解除=リンクダウンになり、detected状態が即リセットされるため実際に試せていません)
syslog、SNMP TRAPによる監視
上記のportdisable、portblockではあくまでも自機のポートを閉塞するだけであり、異なる機器でループ状態となっている場合はあまり意味がありません。自機への影響を防ぐだけです。となると結局は人が検知してループ状態を解除し、復旧させるしかありません。
syslog
loop検知時のsyslogメッセージは以下になります。
l2loopd: Configuration Testing Protocol detects a loop in port 1 and port 2
・syslogサーバーの設定例
SR-X324T2(config)# syslog server 0 address 192.168.11.10
・syslog facilityの設定例(デフォルトは23=local7)
SR-X324T2(config)# syslog facility 22
サーバー側でrsyslog(facilityを合わせる)やfirewall(udp port=514許可)の設定をすればサーバー側のログに出力できます。
SNMP TRAP
・trap送信の設定例
SR-X324T2(config)# snmp service on
SR-X324T2(config)# snmp manager 0 192.168.11.10 public v2c
SR-X324T2(config)# snmp trap loopdetect enable
※ファームウェアが1.05ではsnmp trap loopdetectは存在しないため、2.00にアップデートする必要があります。アップデート手順は以下を参考。
ネットワーク機器 無線LANソリューション SR-Mシリーズ アップデートモジュール インストールの詳細手順 - Fujitsu Japan
・アップデートファイル、拡張MIBファイルのダウンロードURL
ネットワーク機器 サーバ収容スイッチ SR-Xシリーズ アップデートモジュール - Fujitsu Japan
サーバー側でsnmptrapを受信するための設定は割愛。上記拡張MIBファイルの取り込み必要。参考サイト・・・
CentOS snmptrapd へ MIBファイルを追加する - OSSゆいまーる広場
設定後、実際にTRAPを受信した際のメッセージは以下になりました。
※冒頭一部省略。
[UDP: [10.10.0.100]:162->[192.168.11.10]:162]:#012DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2833995) 7:52:19.95#011SNMPv2-MIB::snmpTrapOID.0 = OID: SRX-MIB::srxLoopDetect#011SRX-MIB::srxLoopDetectSendIfIndex.7001 = INTEGER: 7001#011SRX-MIB::srxLoopDetectRecvIfIndex.7001 = INTEGER: 7002#011SRX-MIB::srxLoopDetectStatus.7001 = INTEGER: detect(2)
syslogの方がわかりやすいです。
以上のように、syslogやSNMP TRAPをzabbixなどと連携してメール通知を行えばリアルタイムで人間が検知可能かと思います。
loopdetectの検証は今回で終了します。
年末にCCNPの更新があるので、その勉強過程で行った検証を一部記事にする予定です。
loopdetect検証
富士通製L2スイッチ「SR-X324T2」のループ検知機能の検証
ループ検知機能とは
ループ検知機能をONにしたポートから一定間隔でフレームを送出し、自身が送出したフレームを受信した場合にループとみなす機能(らしい)。
参考・・・ループ検知の機能説明
検知時にポートを自動でシャットダウンする機能などもある。
検証の目的
STP機能がない末端のHUBでループが発生してしまった時に、上位スイッチ側で検知したい。
末端のHUBはユーザーが勝手に接続を変えたり新しいHUBを接続するなど、管理が行き届かないケースがある。そして、ループさせることも稀によくある。
構成
・SR-XでloopdetectをON
・SR-Xの配下にほかのL2スイッチ(Catalyst)を繋いでループ構成とする
・配下のスイッチはSTPをOFFにしておく
設定
〇STP無効化設定(Catalyst)
Switch(config)#no spanning-tree vlan 1
⇒ポート単位での設定は不可。vlan単位で無効化する。
〇loopdetect有効化(SR-X)
SR-X324T2(config)# loopdetect use on
⇒有効化
SR-X324T2(config)# loopdetect portdisable no
⇒とりあえずポートの自動閉塞はしない設定
事前検証
loopdetectの検証の前に、実際にブロードキャストストーム発生の様子を観測してみる。
SR-Xの代わりにPC(Windows 10)を接続し、L2ループ発生時のトラフィック量を測定。
結果は以下。
〇タスクマネージャー(ネットワーク)
⇒ワイヤーレートに近いトラフィックが流れていることがわかる。
⇒主にSSDPというプロトコルのパケットがキャプチャされている。PC(10.15.1.2)から239.255.255.250というマルチキャストアドレスへのパケットがループしている様子。
本検証
念のため、loopdetectの監視フレームの情報は以下になる。
「Ethernet-Configuration-Test-protocol」とあるが、調べてもよくわからない。規格化されているわけではないのだろうか。
では、ループ検証に移る。
〇まずは、ループ発生前の状態
⇒undetectedになっている。
〇ループ発生時
⇒port 1でdetectedに変化。構成図の条件で検知に成功することが確認できた。
ちなみに「count」が0/60と表示されているが、こちらはループ復旧と判断するまでの監視フレームの送出回数であり、実際にループ構成を解消させるとcountの数字が増加し、60になると「undetected」に戻る。
⇒ループ構成を解消させるとcountが増えていき、、、
⇒最終的にundetectedに戻る。上記設定では10秒×60なので復旧と判断するまで10分かかることになる。もっと少なく10回くらいでもよい気がする。
まとめ
ループ検知機能は意図した通りに機能することがわかった。ただし、あくまでもループしていることがわかるだけで、どのHUBのどのポートがループの原因となっているかまではわからない。
また、今回はポートの自動閉塞は設定していないが、ループ解消後に自動で閉塞も解除されるのかなどについても検証したい。下手に閉塞させると余計に影響が大きくなる可能性もあるので、実際の運用も考慮して最適な設定を検討すべきである。
-------------------------------------------------------------------------------------------------------------
初めての記事がこれて…。どうせ誰も見ないからいいや。今後もネットワーク機器やサーバの検証メモとして記事にできればいいな。
