- - PR -
STP(BPDU)と、クライアントPCのMACアドレス取得障害
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2009-03-25 15:45
詳細な解説、ありがとうございます。
1.についてはCiscoの機器などにストームコントロールがある、 ということは理解できました。
物分りが悪くすみません。この「自分よりも強いブリッジの制御下」とは どういうことでしょうか?(なにか、複数のスイッチを統合制御するような プロトコルがあって、その影響下に置かれている、ということですか?) 通常のBPDU(Conf)は、平常時も飛び続けて、STP対応機器間で死活判断に 使用され、リンクダウン等ポートステータスの変化が検知されれば、 例によって、BPDU(TCN)が出る、ということですね。 根本的なところですが、I/Fの物理的な損傷、ケーブルの断線、対向機器の ダウンによる信号消失がない限り、ポートのステータスってForwarding(と Blocking)からそうそう変わらないものです・・・よね? →つまり、BPDU(TCN)が、特にトポロジ変更したりしてないLAN内で、ポロポロ 見かけるのは、何らかの問題がある、ということになりませんか? | ||||
|
投稿日時: 2009-03-25 17:32
↓この辺は、ちょっと歯切れが悪かったようですね。失礼しました;
上記は間違いで、リンク状態に変化があれば、BPDU(TCN)が発生します。ブリッジのプライオリティとは関係ありませんね。(Blockポートがリンクダウンした場合の挙動は自身ありませんが;) で、本件物理障害の感は拭えませんが、よくあるケースが、STP設定放置のL2にPCやサーバーを直収している場合です。ブリッジは、リンクアップしているポートからBPDU(Conf)を送出します。このときに自分のBPDUが戻ってこなければ、ループはないと判断して、ポートの対抗がSTP非対応のPCやSWでも、ツリートポロジの一部として学習します。 ですから、STP非対応の機器を接続する場合は、CiscoではPortFastとかのオプションを設定していましたね。 Ciscoスイッチに端末類が直収されてなければ、障害くさいです。 _________________ _福田太郎_ | ||||
|
投稿日時: 2009-03-25 19:57
なんだか私からの返信が不要みたいですが、一部勘違いがあっので。
# 私自身はconfiguration設定は行ってないので、実際には違うかも知れませんが、 # 当方L2SWの設定はIPアドレスの付与とSNTPを有効化していただけのはずです。 1.この資料の頁17を参照願います。 但し、実際のポート閉塞がこのために起こったのかは未確認です。 2.ゴメンナサイ。基礎部分の勉強不足でこの辺は正確に説明できません。 BPDU(Conf)は2〜3秒に1回程度のタイミングで発生するので、タイムアウト (経路の障害か大幅な遅延)時にはTCNが出されます。 ICMP(ping)も同様ですが、LANケーブルが潰れて傷んだケース等でも意外と タイムアウトは多く発生しますので「不自然ではない」とコメントしました。 # 良く考えたら、Default状態のBPDUのタイムアウトはL3SW間なので、ケーブル損傷 # は考えにくい。 # あと、「頻発」はLAN末端でのケーブル損傷の方を指してました。 念のため情報検索したら、昔のスレが検索エンジンにhitした・・・ | ||||
|
投稿日時: 2009-03-25 20:51
横レス失礼してました。
決してBackDoorさんをないがしろにはしたわけでは、、。 昔のスレ情報ありがとうございました。 参照スレではブロックポートのリンクダウンは影響しないと言い切ってます; 私の記憶も朧げですね。しかも直収PCについても影響ないと。 設定とかも影響しているのでしょうかね。 となると本件は、物理障害の線が濃くなってきますね。 _________________ _福田太郎_ | ||||
|
投稿日時: 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 ] |