none
ハブ(L2スイッチ)のスパニングツリー(STP)によるループ検出機能によって、AD関係の様々な障害を引き起こしている可能性 RRS feed

  • 全般的な情報交換

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

    ディスカッションというより、ご報告になります。
    ActiveDirectory相互の通信がうまくいかない場合のヒントになれば幸いです。

    クライアントPCからドメインメンバーとしてログオンするときに長時間待たされたり、
    グループポリシーの転送やログオンスクリプトの実行に失敗したり、
    「処理できるドメインコントローラーが見つかりません」「DNSサーバーが見つかりません」
    といったイベントログが記録されるようでしたら、
    スイッチングハブのループ検出機能(スパニングツリー)をOFFにすると
    きれいに処理されるようになるかもしれません。
    http://www.cisco.com/JP/support/public/ht/tac/100/1008211/5-j.shtml
    http://www.itbook.info/study/p19.html
    このループ検出機能は、NICのリンクアップ後から30秒~1分ほどパケットを止めてしまうため、
    その間のWindowsOSの各種ネットワーク処理ができなくなります。
    (Windowsからすると、リンクアップしているのにARPなどの基礎的な通信すら届かないという事象は想定していないでしょう)

    これらの障害は、クライアントPCの性能が高いほど現れるようです。
    (今まで発生しなかったのに、導入したての最新のマシンだけ発生したり)
    理由としては
    マシンの性能が高いほど、この時間内にどんどん先の処理を行っていくためと思われます。
    ADサーバー同士においても
    DFSのリンクに失敗すると、再試行は60分後になるケースがあるようですので
    この理由などによって初期処理で失敗すると、結構あとまで影響してしまいます。

    ループ検出機能は
    大規模な拠点であったり、ECサイトなどのミッションクリティカルな目的で冗長構成を組んでいたり、
    頻繁にネットワーク配線を組み直したりしているのであれば確かに有用かと思いますが、
    一般的なの事務所の拠点内や支店などであれば
    これらの弊害を鑑みるに、わざわざONにする必要もないかと思います。

    以上、ご参考になれば幸いです。

     



    2011年6月9日 7:54

すべての返信

  • 参考までに、PortFastをONにしないでスパツリをオフにしたのでしょうか?

    # PortFastをONだけではだめでしたでしょうか?

    2011年6月9日 12:54
  • pitchcat様

    ご意見、どうも有難うございます。

    それぞれの拠点の性質で、見合う方法をとるといいと思います。
    たとえば
    アグレッシブにNW構成を変更する拠点(工場などは多いでしょうか...)、
    公開サーバなどHA構成を組んでいるノードを含む場合などであれば
    スパニングツリー機能を生かしたままPortFastで個別設定すべきかと私も思います。

    ・自社の自拠点LANが単純なスター型トポロジーであること。
    ・ルートハブは専門の知識をもつ者以外触れないこと。
    ・ブランチハブについても
     一定の知識をもつ者に作業をさせるなら
     上位へのリンクをカスケードポート以外に接続すること自体考えづらいこと。
     (接続ポートへの気遣いを行わない者が作業をする場合は、
      個別にPortFast設定しても
      PortFast設定しているポートへ上位接続をしてしまい
      わざわざループをつくってしまう可能性も否めない)
    ・サーバやネットワーク構成の変更はまれにしか行わない。
    ・クライアントノード数がかなり多い。
     (大規模というほどでもないのですが...)

    以上のリスク受容と工数を検討した結果
    自社拠点の場合は、スパツリごと機能を止めてしまいました。



    2011年7月12日 0:31