【実務・中級編】 スイッチングハブの基本動作：フラッディング（Flooding）の条件と発生メカニズム – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

ネットワークの「迷子」を救え：スイッチングハブのフラッディングとMACアドレステーブルの深層心理

ネットワークエンジニアとして現場に立っていると、しばしば「スイッチって、結局どうやって宛先を見分けているんですか？」という素朴かつ本質的な問いにぶつかります。

レイヤ2（L2）スイッチは、OSI参照モデルのデータリンク層において「MACアドレス」という識別子を唯一の頼りに通信を制御する、寡黙で忠実な働き者です。しかし、彼らも万能ではありません。今回は、スイッチが宛先を見失ったときに起こる「フラッディング（Flooding）」という現象を軸に、その裏側で何が起きているのかを紐解いていきましょう。

—

1. スイッチの基本行動原理：学習と転送

スイッチは電源が入ると同時に、流れてくるフレームの「送信元MACアドレス」を読み取り、自身のメモリ内にある MACアドレステーブル（CAMテーブル） に記録します。

  • 送信元MACアドレスの学習: 「このポートから来たフレームの送信元はAだ」とメモする。
  • 宛先MACアドレスの照合: 「この宛先MACアドレスは、どのポートに繋がっているか？」をテーブルで検索する。

ここまでは教科書通りです。問題は、「テーブルに載っていないアドレス」が宛先として指定されたときに発生します。

2. フラッディング：スイッチの「苦渋の決断」

宛先MACアドレスが MACアドレステーブル に存在しない場合、スイッチは非常に「泥臭い」挙動に出ます。それが フラッディング です。

スイッチは、「どこにいるか分からないなら、全員に送って返事をもらおう」という戦略をとります。具体的には、受信ポート以外の全ポートに同じフレームをコピーして転送します。

フラッディングが発生する3つのトリガー

1. 宛先不明（Unknown Unicast）: 宛先MACアドレスがテーブルに存在しない。
2. ブロードキャスト（Broadcast）: 宛先が FF:FF:FF:FF:FF:FF である場合。
3. マルチキャスト（Multicast）: 特定のグループ宛て（ただし、IGMPスヌーピング等が未設定の場合）。

この「全ポートへのばら撒き」が起きると、ネットワークセグメント全体の帯域を消費します。小規模なLANなら一瞬ですが、大規模な環境やループが発生している環境では、フラッディングが雪崩を打ち、ネットワークが機能不全に陥る「ブロードキャストストーム」という地獄絵図を招くことになります。

—

3. 実務で遭遇する「通信のゆらぎ」をコードで考える

Web API開発をしていると、突然のレイテンシや接続エラーに悩まされることがあります。もしインフラ層でこのフラッディングが頻発していたらどうなるか。アプリケーション層の視点から curl でシミュレートしてみましょう。

# 宛先サーバーがARP解決待ち、あるいはスイッチが学習中の状態を想定
# 接続に時間がかかる、またはパケットロスが発生する状況を再現する
curl -v -m 2 http://192.168.1.50/api/v1/resource

もし curl の実行で Connection timed out が頻発する場合、アプリケーションのコードを疑う前に、ネットワーク層でARP要求がフラッディングされ、パケットの往復が阻害されていないか疑うべきです。

以下は、Pythonで特定のインターフェースのトラフィックを監視するための概念的なコードです。

import psutil

# 指定したNICのパケット数をモニタリングし、異常なスパイクがないか確認する
def monitor_traffic(interface):
    counters = psutil.net_io_counters(pernic=True)
    if interface in counters:
        # パケット受信数を確認
        print(f"受信パケット数: {counters[interface].packets_recv}")
        # フラッディングが起きている場合、この数値が異常に上昇する
    else:
        print("インターフェースが見つかりません")

# 運用中のメトリクス収集ツールに組み込む際のロジック例

—

4. 現場のシニアエンジニアからのTips

現場で「通信が不安定だ」と言われたとき、私は真っ先にスイッチの MACアドレステーブル を確認します。

Cisco IOSでのデバッグ例

# どのMACアドレスがどのポートに紐づいているか確認
show mac address-table dynamic

# 特定のインターフェースのトラフィック統計を確認
show interfaces GigabitEthernet 0/1 | include drops

もし、特定のポートで Broadcast や Unknown Unicast のパケットが異常に多い場合、それは「意図しないループ」か「MACアドレステーブルの溢れ（MACフラッピング）」が原因であることがほとんどです。

解決のためのチェックリスト

  • 物理ループの排除: STP (Spanning Tree Protocol) は有効か？ ログに Topology Change が記録されていないか確認してください。
  • ポートの適正化: 不要なポートを shutdown しているか？ 未使用ポートを放置するのは、セキュリティ的にもネットワーク的にも「招かざる客」を招くようなものです。
  • VLANの分割: フラッディングの範囲（ブロードキャストドメイン）を小さくする。VLANを適切に設計することは、現代のネットワーク運用において最も有効な「災厄の防波堤」です。

—

まとめ：スイッチは「賢い」が「正直」すぎる

スイッチは、決められたアルゴリズムに忠実すぎるがゆえに、ときとしてネットワークを危険に晒します。フラッディングは、スイッチの「正直さ」の裏返しです。

ネットワークのトラブルは、多くの場合、こうした基本的な挙動の積み重ねから発生します。フレームがどこへ消えたのか、なぜ全ポートへ送られてしまったのか。その「パケットの旅路」を想像できるようになれば、あなたはもう一人前のインフラアーキテクトです。

次回は、この「正直すぎる」スイッチを制御する STP や VLAN の設計思想について、より深く掘り下げていきたいと思います。現場からは以上です！

スポンサーリンク

コメント

タイトルとURLをコピーしました