- PR -

STP（BPDU）と、クライアントPCのMACアドレス取得障害

投稿者

投稿内容

Torabon: 会議室デビュー日: 2008/08/06; 投稿数: 9

投稿日時: 2009-03-13 13:47

いつもお世話になっております。

表題の件ですが、現在、LAN内で、クライアントPCがデフォルトゲートウェイに
通信するためのMACアドレスの取得に失敗していまい、通信不能になる障害が発生しています。
その際、その場でパケットキャプチャしてみたところSTPのBPDU（Topology Change Notification）が
かなり頻繁に飛んでいることがわかりました。
このことにつき、以下、自身の推測が正しいか否か、また、間違っていれば、その点をご教示下さい。

【現状】
■パケットの観測場所は、エッジブリッジの配下の末端。プロミスキャスモードで取得。
■数分～数十分に一回、BPDU(TCN)が飛んでくる。ソースアドレスはスイッチA。
■直後、TCA,TCフラグon のBPDUが一回、その後2秒間隔でTCフラグon のBPDUが
　 10～14秒？程度飛んでいる。（5～7フレームぐらい）また、こちらのフレームのソースアドレスはスイッチB。
■後者のフレームが持っているRoot ID、Bridge IDは同一で、
　 32768 00-0d-bd-XX-XX-XX（スイッチBのMACアドレス）となっている。
■エッジのクライアントPCが、デフォルトゲートウェイに向かうための、MACアドレス
　の取得に失敗するトラブルがごく稀に発生する。(手動でStaticにarpエントリを追加すると問題なく通信できる）
■また、このトラブル発生時は、前述のTCN-->TCA-->TCのBDPUがたくさん流れっぱなしになっている。
■スイッチA、スイッチBの位置は正確にわからない。

【推測、考えられること】
■TCN BPDUの発生頻度が多すぎるような気がする。一部の機器の障害の可能性がある。
　エッジ側に置くようなスイッチングハブ（安物）はそんなにSTPに対応していないから
　末端で抜き差しされたり、ハブの電源ON、OFFではBPDUは発生しない。
■Configuration BPDUの Root IDが 32768 ということはデフォルト値であり、STP構成上のルートブリッジが、
　適切に（管理者が意図をもって）選定されていない可能性がある。
■つまり、物理的な配線上、また機器の性能上、本来コアスイッチとして動作すべきL2スイッチが、STP構成上の
　ルートブリッジになっていない可能性があり、このためLAN内にオーバーヘッドが発生していることも考えられる。
■もし、STPを使っていない場合は、STPのBPDUは停止させるべき。
■ただ、TCNの発信元を見る限り、スイッチAまたは、スイッチA配下のスイッチのどこかで経路障害（＝トラブル）が
　発生しているのは間違いない。たとえ、数分～数十分に１回のBPDU（TCN）であっても、障害っぽい。
■無論これだけが、エッジのクライアントPCのMACアドレス取得障害の原因では
　ない可能性もあるが、本STPの設定を見直すことで問題が解決する可能性もある。

以上になります。

宜しくお願い致します。

[ メッセージ編集済み編集者: Torabon 編集日時 2009-03-13 13:47 ]

たらお: 大ベテラン; 会議室デビュー日: 2006/12/25; 投稿数: 206; お住まい・勤務地: 東京・永代通り

投稿日時: 2009-03-13 18:32

00-0d-bd はCiscoのベンダーIDのようですね。
世代にもよりますが、ほぼデフォルトでSTP有効になってます。

でも、この手は、トポロジが見えないと難しいですね。
確実にループが存在しないことを確認できないと切り分け作業もできない。
Flukeとか試してみたくなりますね。

あとは、ポイントになるケーブルを抜いていく切り分けでしょうかね。

追記：
Ciscoスイッチに直収されている機器の電源OFF/ONが影響しているかもしれません。
ポートのLinkがup/downする毎にTCNを投げているかも。

_________________
＿福田太郎＿

[ メッセージ編集済み編集者: たらお編集日時 2009-03-13 18:36 ]

Torabon: 会議室デビュー日: 2008/08/06; 投稿数: 9

投稿日時: 2009-03-16 09:00

レス、ありがとうございます。

仰られる通り、トポロジがわからない（そもそも、本件自体、自身が全部
管理している領域の話でない）ので、曖昧になってしまっています。

ただ、コアスイッチがCiscoである以上、BPDUのRoot ID は32768じゃ、
ダメなんじゃないかなぁ、と思っています。
（CiscoのSTP Bridge PriorityのRoot値推奨は4096だから）

> Ciscoスイッチに直収されている機器の電源OFF/ONが影響しているかもしれません。
直収機器のLink up/downが検知されている、とのことなんですが、その場合、
その接続されている機器とCisco間でSTP のやりとりが行われていることが
前提ということでいいでしょうか？

STP自体、今回はじめて調べたので、スイッチ関連にある機能というのはわかりますが、
他の（サーバなどのNICも？）対応しているようなものなのでしょうか？

BackDoor: ぬし; 会議室デビュー日: 2006/02/20; 投稿数: 831

投稿日時: 2009-03-17 06:39

割り込み失礼。

引用:

Torabonさんの書き込み (2009-03-13 13:47) より:

STPのBPDU（Topology Change Notification）がかなり頻繁に飛んでいることがわかりました。

【現状】
■数分～数十分に一回、BPDU(TCN)が飛んでくる。ソースアドレスはスイッチA。
■直後、TCA,TCフラグon のBPDUが一回、その後2秒間隔でTCフラグon のBPDUが
　 10～14秒？程度飛んでいる。（5～7フレームぐらい）また、こちらのフレームのソースアドレスはスイッチB。
■また、このトラブル発生時は、前述のTCN-->TCA-->TCのBDPUがたくさん流れっぱなしになっている。
■スイッチA、スイッチBの位置は正確にわからない。

【推測、考えられること】
■TCN BPDUの発生頻度が多すぎるような気がする。一部の機器の障害の可能性がある。
　エッジ側に置くようなスイッチングハブ（安物）はそんなにSTPに対応していないか
■Configuration BPDUの Root IDが 32768 ということはデフォルト値であり、STP構成上のルートブリッジが、適切に（管理者が意図をもって）選定されていない可能性がある。
■つまり、物理的な配線上、また機器の性能上、本来コアスイッチとして動作すべきL2スイッチが、STP構成上のルートブリッジになっていない可能性があり、このためLAN内にオーバーヘッドが発生していることも考えられる。
■無論これだけが、エッジのクライアントPCのMACアドレス取得障害の原因では
　ない可能性もあるが、本STPの設定を見直すことで問題が解決する可能性もある。

BPDU(TCN)の頻度に関して、STP設定がDefault状態ならさほど多くないように思います。
STPはDefaultのままでも問題なく動作するケースが多いのではないでしょうか？
#　ヤマ勘ですが、LANケーブルの部分断線等を疑ってます。
#　一般的に機器故障よりも、LANケーブルのダメージの方が発生頻度が高いので。

引用:
Torabonさんの書き込み (2009-03-16 09:00) より: 仰られる通り、トポロジがわからない（そもそも、本件自体、自身が全部管理している領域の話でない）ので、曖昧になってしまっています。

現場の状況が判らないままnet上でアドバイスを求めること自体、如何なもの
かと思います。
他の社内管理者に状況説明し、確認・調査を行うのがまともなアプローチだと
思えますが・・・。

修正：イタリック体部分を追記

[ メッセージ編集済み編集者: BackDoor 編集日時 2009-03-17 08:14 ]

Torabon: 会議室デビュー日: 2008/08/06; 投稿数: 9

投稿日時: 2009-03-17 09:38

レスありがとうございます。

引用:
BPDU(TCN)の頻度に関して、STP設定がDefault状態ならさほど多くないように思います。 STPはDefaultのままでも問題なく動作するケースが多いのではないでしょうか？

STP設定がDefaultならさほど多くない、というのは、『数分～数十分に１回BPDU(TCN)が流れるのは普通』ということでしょうか？　
基本的に経路障害（もしくは意図的な切断）が発生しない限り流れてはいけないものであるように見えます。

Default設定だと、RootIDが同一になり、結果、MACアドレスの値でRootブリッジが選定
されますが、この場合にトラブルとはなりえないということでしょうか？
（素人考えですが、意図しないブリッジがRootになってしまうと、輻輳の原因になる
　のではないかと思うのですが）

引用:
現場の状況が判らないままnet上でアドバイスを求めること自体、如何なものかと思います。他の社内管理者に状況説明し、確認・調査を行うのがまともなアプローチだと思えますが・・・。

本件、トラブルを解決したい！というのではなく、STPに関する自身の認識の確認と、
STPの実際の運用についてお聞きしたいのが趣旨になります。誤解を招いたようでしたら申し訳ありません。
（Rootブリッジの設定、選定、それが適正でない場合の問題や、今回のようにLANの
　MACアドレス取得に影響を及ぼすようなトラブルの原因になりえるかという点）

BackDoor: ぬし; 会議室デビュー日: 2006/02/20; 投稿数: 831

投稿日時: 2009-03-17 20:03

引用:
Torabonさんの書き込み (2009-03-17 09:38) より: 本件、トラブルを解決したい！というのではなく、STPに関する自身の認識の確認と、 STPの実際の運用についてお聞きしたいのが趣旨になります。誤解を招いたようでしたら申し訳ありません。

了解しました。こちらこそ誤解を詫びます。

引用:

引用:
BPDU(TCN)の頻度に関して、STP設定がDefault状態ならさほど多くないように思います。
STPはDefaultのままでも問題なく動作するケースが多いのではないでしょうか？

STP設定がDefaultならさほど多くない、というのは、『数分～数十分に１回BPDU(TCN)が流れるのは普通』ということでしょうか？　
基本的に経路障害（もしくは意図的な切断）が発生しない限り流れてはいけないものであるように見えます。

少々説明不足でした。
当方、LANの基本設計で基幹部分はツリー形状にしていますので、L2SWのSTP
はDefaultのまま（ブリッジIDの設定はしない状態）で使用しています。
質問内容を見た限りでは当方と同様の状況ではないかと想像してコメントした次第で
完全な延髄レスでした。
→　当方と違って基幹L2SW間がSTP設定必要なトポロジだった場合は以降のコメントは
　　無視して下さい。

前のコメントは、この状況下で『数分～数十分に１回BPDU(TCN)が流れるのは普通』
という意図でした。
→　基幹部分以下のエッジSWは一般利用者が触れる状態なので、間違えて
　　ループを起こしてしまうケースもありますが、基幹SW側では当該ポート
　　が閉塞するだけで済んでます。

STPの基本はあくまでも機器障害時にLANが継続使用可能なこと位しかメリットが無く、
常時モニタリングも必要です。
単純なツリー形状なら（酷い話かも知れませんがｗ）機器故障時にはユーザから
障害連絡が入りますので、代替機持って現地に入るだけで済みますから。
#　１～２時間で復旧できれば問題ない場合、シンプルな方が運用保守は容易です。

Torabon: 会議室デビュー日: 2008/08/06; 投稿数: 9

投稿日時: 2009-03-25 11:04

度々のレス、ありがとうございます。
また返答が遅くなり申し訳ありません。

引用:

少々説明不足でした。
当方、LANの基本設計で基幹部分はツリー形状にしていますので、L2SWのSTP
はDefaultのまま（ブリッジIDの設定はしない状態）で使用しています。
質問内容を見た限りでは当方と同様の状況ではないかと想像してコメントした次第で
完全な延髄レスでした。
→　当方と違って基幹L2SW間がSTP設定必要なトポロジだった場合は以降のコメントは
　　無視して下さい。

この可能性は失念していました。たらおさんの御指摘どおり、Ciscoの機器が
デフォルトでSTPがオンになっていることも併せて考えると、物理トポロジが
ツリー型だけれども、特にSTPを止めていない、という可能性も高そうです。
（万一のループ配線の回避策？・・・というより、設定し忘れっぽいですね）

引用:
前のコメントは、この状況下で『数分～数十分に１回BPDU(TCN)が流れるのは普通』という意図でした。 →　基幹部分以下のエッジSWは一般利用者が触れる状態なので、間違えて　　ループを起こしてしまうケースもありますが、基幹SW側では当該ポート　　が閉塞するだけで済んでます。

この点、脱線しているかもしれませんが、２点、確認させてください。

１．仰られる環境で、末端でブロードキャストストームが発生してしまった場合、
　　基幹SW側のポート閉塞だけで済んでいるのは、なぜでしょうか？
　　（ループ構成になってしまったエッジ側から無限送出され続けるブロードキャスト
　　　フレームを延々と中継、そのままダウンするのでは？）

２．物理的トポロジがツリー型になっている場合、なぜBPDU（TCN）が発生するのでしょうか。
　　私の認識では、STP対応機器のBPDUがタイムアウト（経路の障害か大幅な遅延）か、
　　新たにSTP対応のネットワーク機器が投入され、STPトポロジの再構築が発生しない
　　限り、BPDU（TCN）は発生してはいけないもののように思います。
　　上掲のいずれの要因も、そう頻発するような類の事象には思えないのですが、
　　他に、BPDU（TCN）が発生する要因があるのでしょうか。

たらお: 大ベテラン; 会議室デビュー日: 2006/12/25; 投稿数: 206; お住まい・勤務地: 東京・永代通り

投稿日時: 2009-03-25 12:06

1.については、条件つきですが可能性があります。

・トポロジは、STP管理外でループが起きた場合。
・STPスイッチが、ストームコントロールを実装している。

という場合です。

コード:


[L2(STP有効)]
　｜▲閉塞対応
　｜
[L2(非STP)]┐
　｜　　　 ｜
　｜　　　 ｜→配下の通信は極端に遅くなるか、通信不能。
[L2(非STP)]┘

Bcastの閾値が3000から5000くらいでポートが閉塞します。これはまだ良いほうで、

[L2(STP有効)]→CPU負荷が上がり(80%以上)、通信が遅くなる。
　｜▲閉塞対応
　｜
[L2(非STP)]┐
　｜　　　 ｜
　｜　　　 ｜→配下の通信不能。スイッチがリブートを繰り返すこともある。
　└───-┘

この場合は、閉塞対応してもSTPスイッチのCPU負荷が極端に上がります。(実験済み)
本件の事象とは異なりますね。

2.については、自分よりも強いブリッジの制御下でない場合には、
　ポートのリンク状態に変化があれば、BPDU(TCN)が発生すると思います。

　[実測]純粋にSTP設定放置なら、BPDU(Conf)のみ流れてます。

＃そういえば、1990年代までの高級ダムハブには、
＃パーティション機能といって、ポート電圧が大きくなったら、
＃ストームと判断して物理閉塞するのがありましたね。
＃当時8ポートもので2-3万円くらいだったか。

_________________
＿福田太郎＿

1|2 次のページへ»

＠IT SpecialPR

STP（BPDU）と、クライアントPCのMACアドレス取得障害

スキルアップ／キャリアアップ（JOB@IT）