- PR -

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

投稿者投稿内容
Torabon
会議室デビュー日: 2008/08/06
投稿数: 9
投稿日時: 2009-03-25 15:45
詳細な解説、ありがとうございます。

1.についてはCiscoの機器などにストームコントロールがある、
ということは理解できました。

引用:

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



物分りが悪くすみません。この「自分よりも強いブリッジの制御下」とは
どういうことでしょうか?(なにか、複数のスイッチを統合制御するような
プロトコルがあって、その影響下に置かれている、ということですか?)

通常のBPDU(Conf)は、平常時も飛び続けて、STP対応機器間で死活判断に
使用され、リンクダウン等ポートステータスの変化が検知されれば、
例によって、BPDU(TCN)が出る、ということですね。

根本的なところですが、I/Fの物理的な損傷、ケーブルの断線、対向機器の
ダウンによる信号消失がない限り、ポートのステータスってForwarding(と
Blocking)からそうそう変わらないものです・・・よね?

→つまり、BPDU(TCN)が、特にトポロジ変更したりしてないLAN内で、ポロポロ
  見かけるのは、何らかの問題がある、ということになりませんか?
たらお
大ベテラン
会議室デビュー日: 2006/12/25
投稿数: 206
お住まい・勤務地: 東京・永代通り
投稿日時: 2009-03-25 17:32
↓この辺は、ちょっと歯切れが悪かったようですね。失礼しました;
引用:

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



上記は間違いで、リンク状態に変化があれば、BPDU(TCN)が発生します。ブリッジのプライオリティとは関係ありませんね。(Blockポートがリンクダウンした場合の挙動は自身ありませんが;)

で、本件物理障害の感は拭えませんが、よくあるケースが、STP設定放置のL2にPCやサーバーを直収している場合です。ブリッジは、リンクアップしているポートからBPDU(Conf)を送出します。このときに自分のBPDUが戻ってこなければ、ループはないと判断して、ポートの対抗がSTP非対応のPCやSWでも、ツリートポロジの一部として学習します。

ですから、STP非対応の機器を接続する場合は、CiscoではPortFastとかのオプションを設定していましたね。

Ciscoスイッチに端末類が直収されてなければ、障害くさいです。

_________________
_福田太郎_
BackDoor
ぬし
会議室デビュー日: 2006/02/20
投稿数: 831
投稿日時: 2009-03-25 19:57
なんだか私からの返信が不要みたいですが、一部勘違いがあっので。

引用:
Torabonさんの書き込み (2009-03-25 11:04) より:

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

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


# 私自身はconfiguration設定は行ってないので、実際には違うかも知れませんが、
# 当方L2SWの設定はIPアドレスの付与とSNTPを有効化していただけのはずです。

1.この資料の頁17を参照願います。
 但し、実際のポート閉塞がこのために起こったのかは未確認です。

2.ゴメンナサイ。基礎部分の勉強不足でこの辺は正確に説明できません。
 BPDU(Conf)は2〜3秒に1回程度のタイミングで発生するので、タイムアウト
 (経路の障害か大幅な遅延)時にはTCNが出されます。
 ICMP(ping)も同様ですが、LANケーブルが潰れて傷んだケース等でも意外と
 タイムアウトは多く発生しますので「不自然ではない」とコメントしました。
# 良く考えたら、Default状態のBPDUのタイムアウトはL3SW間なので、ケーブル損傷
# は考えにくい。
# あと、「頻発」はLAN末端でのケーブル損傷の方を指してました。

念のため情報検索したら、昔のスレが検索エンジンにhitした・・・
たらお
大ベテラン
会議室デビュー日: 2006/12/25
投稿数: 206
お住まい・勤務地: 東京・永代通り
投稿日時: 2009-03-25 20:51
横レス失礼してました。
決してBackDoorさんをないがしろにはしたわけでは、、。
昔のスレ情報ありがとうございました。

参照スレではブロックポートのリンクダウンは影響しないと言い切ってます;
私の記憶も朧げですね。しかも直収PCについても影響ないと。
設定とかも影響しているのでしょうかね。

となると本件は、物理障害の線が濃くなってきますね。

_________________
_福田太郎_
Torabon
会議室デビュー日: 2008/08/06
投稿数: 9
投稿日時: 2009-03-26 09:54
BackDoorさん、たらおさん、度々のご教示ありがとうございました。
おかげさまで、(たぶん)STPの概要については理解できたように思います。

まとめさせて頂くと、

1.BPDU(TCN)発生は、ポートステータスの変化を検知したタイミング。
  (ただし、ブロックポートのリンクDOWNには反応しない)

2.ポートステータスはBPDU(Conf)の送受信状況に左右されるため、
  物理レイヤーでの軽微な損傷や、大幅な輻輳が原因で、一時的に
  ポートステータスの遷移が発生し、BPDU(TCN)が出てしまうのは十分にありえる。
  (物理損傷やら輻輳自体は問題だけども、即座にSTPトポロジ設計が変と
   いうわけではない)

3.BPDU(TCN)発生はポートステータスの変化に反応するため、STP対応スイッチと
  STP非対応スイッチ間でのリンクの状態についても、【STP対応スイッチ側】は
  反応する。
  (最近のNICはWake On Lan機能でケーブルが挿してあれば、リンクがあがるため、
   PC、サーバなどの状態にはさほど左右されない)
  (また、Cisco機であればPortFast設定でBPDUを封じたポート設定にすることで
   望まないSTPトポロジの拡張が防げる)

4.以上から、BPDU(TCN)がたまに発生するのはどこかに物理的な障害がある
  (または潜伏している)可能性が高い。

ということで、私の推測の正否をまとめると

■TCN BPDUの発生頻度が多すぎるような気がする。一部の機器の障害の可能性がある。
 --> 数分〜数十分に一度であればさほど問題ではないが、発生原因で対応が異なる
     STP対応スイッチにたまに抜き差しが発生しているなら運用の問題で、
     PortFast設定したり、運用を変えるべきだし、軽微なHW故障の可能性もある。

■Configuration BPDUの Root IDが 32768 ということはデフォルト値であり、STP構成上のルートブリッジが、
  適切に(管理者が意図をもって)選定されていない可能性がある。
 --> STP設定放置っぽい。が、トラブルになるわけではない。
    あるべきSTPトポロジが構成できない可能性はあるが。


■本来コアスイッチとして動作すべきL2スイッチが〜
 --> 同上

■もし、STPを使っていない場合は、STPのBPDUは停止させるべき。
 --> CiscoはデフォルトでONになってるんで気をつける

■〜本STPの設定を見直すことで問題が解決する可能性もある。
 --> 誤り。STPトポロジが狂うことで変なツリーが形成されたとしても
    ARPテーブルの交換に不具合が出るような事態になるのは考えにくい。
    (STPトポロジの再計算でCAMエイジングが短縮され、アドレステーブルが
     Flushされたとしても、それはSTPとSTPトポロジのせいではなく、
     STP再計算が発生している原因が問題)

以上です。(勘違いしているところがあれば御指摘頂ければ幸いです)

#ちなみに本件について調べる発端となったトラブルは、昨日エッジスイッチの交換
#で落ち着きました。(結局原因は不明でしたが・・・)
#ただ、どうも、使ってなさそうな設定放置が他にもあるようです。CDPとか。
#そういうところを、パッと見抜いて、「手ぇ抜くな!」と言える様になりたいものですが
#やっぱり甘くないですね。



[ メッセージ編集済み 編集者: Torabon 編集日時 2009-03-26 09:57 ]

スキルアップ/キャリアアップ(JOB@IT)