L2ループ対策

L2ループ対策

「L2 のループ対策なんて STP を使えば良いんじゃね?」

仰るとおりなのですが、そこで思考を止めてもおもしろくないので、
今回は、STP を使用していたとしてもループが発生してしまう場合と、
そんな時にどんなループ対策があるんでしょうということを
書いてみたいと思います。

 

L2 ループが発生すると

L2 ループが発生する条件は、当然 L2 ネットワークで
ループ構成になっていることが前提。

 

L2ループ構成

 

L2 ネットワークでループ状態になると以下のような問題が発生します。

  • ブロードキャストやマルチキャストフレーム
  • 同一データを複数受信
  • MACアドレステーブルの不安定

 

ブロードキャスト / マルチキャスト

スイッチはブロードキャストやマルチキャストは受信したポート以外の
全ポートにフラッディングします。
それを受信したスイッチは、同じように受信したポート以外の全ポート
にフラッディングします。
さらにそれを受信したスイッチは、同じように受信したポート以外の全ポート
にフラッディングします。
・・・という動作を繰り返すことで、延々とブロードキャストや
マルチキャストのフレームが転送され続けてしまうことを、
ブロードキャストストーム / マルチキャストストームと呼びます。

 

ブロードキャストストーム / マルチキャストストーム

 

ブロードキャストストーム / マルチキャストストームが発生すると、

  • 帯域がブロードキャスト / マルチキャストのフレームで使い切ってしまう
  • スイッチが CPU 負荷がとんでもないことになって正常動作しなくなる
  • スイッチに接続されている端末も通信不能に

 

この問題を解決する方法は言わずとしれた STP を使用すること。
STP については以下で解説しています。
・STP -スパニングツリー-

 

STP 設定していてもループしちゃう場合

社内ネットワークに良くある構成で考えてみます。

 

STPのループ構成

 

上図のように基本的な L2 ネットワークはツリー構成になっています。
ここで末端のハブ同士を誤って接続してしまった場合を考えてみます。

で、通常のコアやアクセススイッチでは STP を有効にしてループが
発生しないようにするわけですが、仮にエッジポートで STP を
停止させている場合。

 

ブロードキャストストーム / マルチキャストストームが発生

 

この場合はループ状態となり、ブロードキャストストーム /
マルチキャストストームが発生してしまいます。

では、エッジポートに STP を設定していた場合はというと、

通常はエッジポートで BPDU を受信するとループを検知して
Blocking に遷移するためループにはなりません。

でも、末端のハブによっては BPDU を廃棄するハブがあったりします。
この場合、アクセススイッチではループを検知出来ずにループ状態に
なってしまいます。

こういった事象は意外に多いのかなぁと。

そこで、STP 以外でループを回避する方法をごにょごにょと
考えてみました。

ああそうそう、ここでは Cisco のスイッチにある機能のみを
書いています。
その他のベンダーのスイッチの機能については記載していませんので
あしからず。

 

keepalive によるループ検知

Cisco スイッチでデフォルト動作している「keepalive」機能は、
ループ検知のための基本的な機能です。

「keepalive」機能が有効の場合、スイッチは keepalive フレームを
定期的に送出し、自身が送出した keepalive フレームを同一ポートで
受信した場合にポートをダウンさせます。

以下のような状況でループが発生した場合に有効な機能。

 

keepalive によるループ検知

 

以下のような状況では残念ながら役に立たず。

 

ブロードキャストストーム / マルチキャストストームが発生

 

keepalive 設定コマンド

設定は至って簡単です。

インタフェースコンフィグレーションモードで以下の設定を投入するだけ。

(config-if)# keepalive [ period ]

デフォルトは 10 秒おきに keepalive フレームを送信します。

 

ループを検知すると

ループを検知すると、インタフェースがダウンするのですが、
その場合に show interface を見ると、以下のように
通常の dowm 表示ではなく、「(err-disabled)」という表示になります。

Switch#show interfaces
GigabitEthernet0/1 is down, line protocol is down (err-disabled)

ちなみにループ検知による Down は、「自身が送出した keepalive
フレームを同一ポートで受信した場合」意外にも、リンクが
フラップした場合やレイトコリジョンの検出など機種によって
トリガがいくつか存在しています。

 

ポートの復旧方法

err-disabled によるポートダウンの復旧方法は、
インタフェースの shutdown → no shutdown で復旧出来ます。

もし、err-disabled から自動的に復旧させたい場合は
以下の設定を投入します。

(config-if)# errdisable recovery {cause {option}} | {interval interval}

option で自動復旧させたい項目を選択することが可能です。
interval はerr-disabled になってから自動復旧するまでの
時間を指定できます。(デフォルトは 300 秒)

ただし、errdisable recovery を投入しておくと、
ループの原因が取り除かれていないと、当然ポートの down/up が
繰り返されるわけで、ネットワークがとても不安定な状態なるので
注意しましょう。

おすすめ記事

関連記事

検索

特集

初心者のためのciscoルータの管理

目指せPMP

▼ ネットワークエンジニアにおすすめのサイトはこちら ▼


著書

図解入門 よくわかる最新ネットワーク技術の基本と仕組み

初心者のためのCiscoルータ運用ガイド: 最速でCiscoルータを理解するための解説書

目指せPMP PMBOK第5版対応: 最速でPMPに合格するための解説書

見てわかるTCP/IP

おすすめ記事

カテゴリ

ブログ最新記事