ITインフラ技術メモ(仮)

ネットワークやサーバー技術についてのメモ書き

loopdetect検証(続)

時間が空きました。SR-X324T2のloopdetect機能検証の続き。

・loopdetect portdisable

・loopdetect portblock

・syslog、SNMP TRAP

構成

port1と2を直結させる

f:id:nanishikori:20170918125135p:plain

loopdetect portdisable

以下を設定。

f:id:nanishikori:20170918125509p:plain

(ちなみに上記コマンドの後 commit コマンドを実行しないと設定が反映されません。富士通製の仕様)

loop検知後の結果

(リカバリ時間はinterval 10s × 10の100秒)

f:id:nanishikori:20170918125951p:plain

両ポートで検知しているため、どちらもportdisableになっています。

そしてリカバリ時間が経過しても自動で復旧しません。復旧させる場合は以下のコマンドを実行します。もちろんループ状態を解除してからです。

f:id:nanishikori:20170918130332p:plain

実行後は即元通りになります。

f:id:nanishikori:20170918130612p:plain

portdisableオプションは手動で復旧させなければならない点が注意です。

loopdetect portblock

以下を設定。

f:id:nanishikori:20170918131139p:plain

loop検知後の結果

f:id:nanishikori:20170918131624p:plain

 

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ファイルの取り込み必要。参考サイト・・・

snmptrapd 設定方法

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を接続するなど、管理が行き届かないケースがある。そして、ループさせることも稀によくある。

構成 

f:id:nanishikori:20170820233704p:plain

・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ループ発生時のトラフィック量を測定。

結果は以下。

〇タスクマネージャー(ネットワーク)

f:id:nanishikori:20170821004500p:plain

⇒ワイヤーレートに近いトラフィックが流れていることがわかる。

 

Wireshark

f:id:nanishikori:20170821004540p:plain

⇒主にSSDPというプロトコルのパケットがキャプチャされている。PC(10.15.1.2)から239.255.255.250というマルチキャストアドレスへのパケットがループしている様子。

 

本検証

念のため、loopdetectの監視フレームの情報は以下になる。

f:id:nanishikori:20170821021426p:plain

Ethernet-Configuration-Test-protocol」とあるが、調べてもよくわからない。規格化されているわけではないのだろうか。

 

では、ループ検証に移る。

〇まずは、ループ発生前の状態

f:id:nanishikori:20170821014845p:plain

 ⇒undetectedになっている。

 

〇ループ発生時

f:id:nanishikori:20170821015112p:plain

⇒port 1でdetectedに変化。構成図の条件で検知に成功することが確認できた。

ちなみに「count」が0/60と表示されているが、こちらはループ復旧と判断するまでの監視フレームの送出回数であり、実際にループ構成を解消させるとcountの数字が増加し、60になると「undetected」に戻る。

f:id:nanishikori:20170821015801p:plain

⇒ループ構成を解消させるとcountが増えていき、、、

f:id:nanishikori:20170821015856p:plain

⇒最終的にundetectedに戻る。上記設定では10秒×60なので復旧と判断するまで10分かかることになる。もっと少なく10回くらいでもよい気がする。

 

まとめ

ループ検知機能は意図した通りに機能することがわかった。ただし、あくまでもループしていることがわかるだけで、どのHUBのどのポートがループの原因となっているかまではわからない。

また、今回はポートの自動閉塞は設定していないが、ループ解消後に自動で閉塞も解除されるのかなどについても検証したい。下手に閉塞させると余計に影響が大きくなる可能性もあるので、実際の運用も考慮して最適な設定を検討すべきである。

 

 

 

 

 

 

 

 

-------------------------------------------------------------------------------------------------------------

初めての記事がこれて…。どうせ誰も見ないからいいや。今後もネットワーク機器やサーバの検証メモとして記事にできればいいな。