【実務・中級編】 MACアドレステーブルのエージングタイマーとタイムアウト処理 – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

ネットワークの世界において、ルータが持つルーティングテーブルの輝かしい活躍の裏で、L2スイッチの片隅で黙々と、しかし極めて重要な役割を果たしているのが「MACアドレステーブル（ブリッジングテーブル）」だ。

Webエンジニアやアプリケーションレイヤーを主戦場とする人たちから見れば、MACアドレスやL2スイッチなんてものは「L3パケットをカプセル化して次のホップへ運ぶための透明なパイプ」に過ぎないかもしれない。しかし、インフラの現場で幾多のネットワーク障害――例えば「なぜか特定のサーバだけが数分間通信できなくなる」「VLANの再設計後にネットワークが一時的にマヒした」といったトラブル――を切り分けた経験があるエンジニアなら、この小さなテーブルの挙動、特にエージングタイマー（Aging Timer）の機微がいかにシステム全体の生死を握っているか、痛いほど知っているはずだ。

今回は、このMACアドレステーブルのエージングタイマーのメカニズムと、トポロジ変更時のリアルな挙動について、現場のシニアエンジニアの視点から深く掘り下げていこう。

—

MACアドレステーブルの基本とエージングタイマーの正体

L2スイッチは、届いたイーサネットフレームの送信元MACアドレス（Source MAC）を自身のテーブルに学習し、宛先MACアドレス（Destination MAC）がテーブルに存在すれば対応するポートへフォワードし、なければフラッディング（全ポート転送）を行う。これはスイッチングハブの基本動作だ。

しかし、ネットワーク機器のメモリリソースは無限ではない。また、物理的なネットワークトポロジは動的に変化する。

  • サーバがシャットダウンされた
  • 別のポートにLLANケーブルが差し替えられた
  • 端末がWi-Fiローミングで別のアクセスポイントへ移動した

これらが発生したとき、古いMACアドレス情報が永遠にテーブルに居座り続けたらどうなるか？ スイッチは存在しない古いポートへフレームを送り続け、通信は完全にブラックホールに吸い込まれてしまう。

ここで登場するのがエージングタイマーだ。

デフォルト値の背景と標準仕様

IEEE 802.1D（ブリッジおよびスイッチングに関する規格）などの標準において、ダイナミックエントリのエージングタイムのデフォルト値は、一般的に300秒（5分）に設定されていることが多い。Cisco CatalystやArista、あるいは主要なL2スイッチのOSでも、この「300秒」が業界標準の黄金律として長く採用されてきた。

この「5分」という時間は絶妙だ。短すぎると、少しトラフィックが途切れただけで再学習のフラッディングが発生してCPU負荷やネットワーク帯域が無駄になり、長すぎるとトポロジ変更時のブラックホール期間が延びてしまう。その絶妙なバランスを取った値が300秒なのだ。

—

エージングタイマーとタイムアウト処理の内部挙動

スイッチのASIC（Application-Specific Integrated Circuit）内部では、MACアドレステーブルのエントリごとにタイマーカウンタが保持されている。

1. 学習（Learning）:
フレームの送信元MACアドレスがポート Gi0/1 から受信されると、テーブルにエントリがない場合は新規作成、既存の場合はタイマーがリセット（ゼロクリア）される。
2. エージング（Aging）:
タイマーがスタートし、フレームの受信がないまま時間が経過していく。
3. タイムアウト＆削除（Timeout & Purge）:
カウンタが設定値（例: 300秒）に達すると、スイッチはそのエントリをダイナミックテーブルからパージ（削除）する。

この一連の処理は、CPUの割り込み処理を最小限にするため、専用のハードウェア（ASICやTCAM）上で高速に処理されている。

—

トポロジ変更時の挙動：TCNとエージングの短縮

正常な定常状態では300秒のエージングは非常に理にかなっているが、ネットワークの形がダイナミックに変わるとき――例えばスパニングツリー（STP: Spanning Tree Protocol）が働き、冗長パスが切り替わった瞬間――には、この「5分」という時間が致命的な遅延を生む。

新しいパスが開通した直後、古いトポロジに基づくMACアドレステーブルのせいで、フレームが間違った方向へ転送されてしまうからだ。

ここでSTPのTCN（Topology Change Notification）がトリガーされる。

TCN受信時のスイッチの振る舞い

IEEE 802.1Dなどの環境において、トポロジ変更を検知したブリッジ（スイッチ）は、ルートブリッジに向けてTCN BPDUを送信し、ルートブリッジはネットワーク全体にTCNフラグを立てたConfiguration BPDUをばら撒く。

これを受信した各スイッチは、何を隠すか、ダイナミックMACアドレステーブルのエージングタイマーを劇的に短縮する（通常、フォワーディングディレイの時間、デフォルトで15秒に短縮される）。

これにより、古くなったMACアドレステーブルのエントリが高速にパージされ、新しいトポロジに合わせた再学習が瞬時に促される仕組みになっている。この連動を知っているかいないかで、障害切り分けのスピードが何倍も変わってくる。

—

現場で役立つ！スイッチの設定と確認のハンズオン

百聞は一見に如かず。実際にCisco IOSや一般的なネットワークOSでのエージングタイマーの確認・変更方法、およびデバッグのアプローチを見ておこう。

1. MACアドレステーブルとエージングタイムの確認（CLI）

現在のMACアドレステーブルの状況と、エージングタイムの設定値を確認するコマンドだ。

# MACアドレステーブルのエージングタイムの設定確認
Switch# show mac address-table aging-time
Global Aging Time: 300
Vlan   Aging Time
----   ----------
(デフォルトは300秒。VLANごとに個別の値をオーバーライドすることも可能)

# 現在学習されているダイナミックエントリの確認
Switch# show mac address-table dynamic
Mac Address Table
------------------------------------------------------------------
Vlan    Mac Address       Type        Ports
----    -----------       ----        -----
 10     aabb.cc00.1111    DYNAMIC     Gi0/1
 10     aabb.cc00.2222    DYNAMIC     Gi0/2

2. エージングタイマーの変更設定例

例えば、仮想マシンのライブマイグレーションが頻発する高密度なクラウド基盤のアクセスレイヤーなどでは、古いMACアドレステーブルが残ることで一時的な通信断が発生するのを防ぐため、エージングタイムをあえて短く（例: 60秒）チューニングすることがある。

Switch# configure terminal
! グローバルコンフィギュレーションモードへ移行
Switch(config)# mac address-table aging-time 60
! エージングタイムを300秒から60秒に変更（※短すぎるとフラッディングが増えるためトラフィック量に注意）

! 特定のVLAN（例: VLAN 20）だけ時間を変更したい場合
Switch(config)# mac address-table aging-time 120 vlan 20

Switch# end
Switch# write memory

3. デバッグとトラブルシューティングのPythonスクリプト例

インフラの自動化や死活監視、あるいはSDNコントローラーの文脈で、SNMPやNETCONF/RESTCONF経由でスイッチからMACアドレステーブルの統計やステータスを定期的にポーリングし、異常検知を行うようなケースを考えてみよう。以下は、モダンなネットワーク管理API（RESTCONF等）を模したPythonスクリプトのイメージだ。

import requests
import json

# スイッチのRESTCONFエンドポイント設定
SWITCH_IP = "192.168.1.1"
API_URL = f"https://{SWITCH_IP}/restconf/data/Cisco-IOS-XE-ethernet-bridging-oper:mac-table"

# 認証情報（本番環境では環境変数やセキュアなシークレットストアから取得すること）
AUTH = ("admin", "secure_password_123")

headers = {
    "Accept": "application/yang-data+json",
    "Content-Type": "application/yang-data+json"
}

def fetch_mac_table_status():
    """
    スイッチから現在のMACアドレステーブルの統計情報を取得し、
    エージングやエントリ数の異常をチェックする関数
    """
    try:
        # SSL証明書の検証は適宜環境に合わせて調整（実運用ではTrueを推奨）
        response = requests.get(API_URL, auth=AUTH, headers=headers, verify=False, timeout=10)
        
        if response.status_code == 200:
            data = response.json()
            mac_entries = data.get("Cisco-IOS-XE-ethernet-bridging-oper:mac-table", {}).get("mac-entry", [])
            
            print(f"[INFO] 取得成功: 現在のエントリ数 = {len(mac_entries)}")
            
            # エントリが多すぎる場合や、特定の古いMACが残っていないかなどの簡易バリデーション
            if len(mac_entries) > 4000:
                print("[WARNING] MACアドレステーブルのエントリ数が急増しています。MACフラッディング攻撃やループの可能性があります！")
                
            return mac_entries
        else:
            print(f"[ERROR] API呼び出しに失敗しました。ステータスコード: {response.status_code}")
            return None

    except requests.exceptions.RequestException as e:
        print(f"[CRITICAL] ネットワーク接続エラーが発生しました: {e}")
        return None

if __name__ == "__main__":
    fetch_mac_table_status()

—

シニアからの実務Tips：エージングタイムをイジるべき瞬間と罠

最後に、現場で数々の修羅場をくぐってきた私から、エージングタイマーにまつわる実践的な教訓（Tips）をいくつか授けておこう。

1. 安易にエージングタイムを短くするな
「フェイルオーバーを速くしたいから」という理由だけで、エージングタイムを極端に短く（例えば10秒など）設定すると、大いなしっぺ返しを食らう。トラフィックが少ない端末のエントリがすぐに消えてしまい、次に通信するたびにスイッチがブロードキャスト/フラッディングを強制され、L2ネットワーク全体のパフォーマンスが低下する原因になる。
2. スタティックMAC（固定設定）との使い分け
セキュリティ要件が厳しいポート（例えば、特定の物理認証された端末しか繋いではいけないポート）では、mac address-table static コマンドを用いてエージングされない静的エントリを記述し、不正なMACアドレスの侵入を防ぐと共に、エージングによるフラッディングを排除する設計が鉄則だ。
3. 仮想環境やロードバランサーとの相性
VMware等のハイパーバイザー上で動く仮想スイッチ（vSwitch）や、Active-Standby構成のロードバランサーのフロートIP/MACが頻繁に移動する環境では、物理スイッチ側のエージングタイムと、仮想環境側のGARP（Gratuitous ARP）の送信間隔の整合性が取れていないと、通信断の温床になる。このあたりのタイミングズレに悩んだときは、まずエージングタイマーとGARPの挙動を疑え。

ネットワークの挙動は、突き詰めればすべて「ルール（規格）」と「時間（タイマー）」の組み合わせでできている。MACアドレステーブルのエージングタイマーという地味な存在も、その背後にある設計思想とパケットの流れをイメージできるようになれば、もはや恐れるものではない。むしろ、トラブルシューティングにおける強力な武器となるはずだ。

スポンサーリンク

コメント

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