MACアドレステーブルの「寿命」を知る：なぜスイッチは記憶を捨てるのか？
ネットワークエンジニアとして現場に立っていると、ふとした瞬間に「なぜ今のネットワークはこんなにも安定して動いているのか」という哲学的な問いにぶつかることがある。その答えの一つが、レイヤ2スイッチが黙々と繰り返す「MACアドレステーブルの管理」だ。
特に、その中でも「エージングタイマー（Aging Timer）」は、一見地味だが、ネットワークの「鮮度」を保つための心臓部とも言える機能だ。今回は、このエージングの深淵に触れつつ、なぜデフォルト値が300秒なのか、そしてそれが実務でどのようなトラブルを招き得るのかを紐解いていこう。
—
1. なぜスイッチは記憶を捨てなければならないのか？
スイッチのMACアドレステーブルは、いわば「ポートとMACアドレスの対応表」だ。スイッチはフレームを受け取るたびに、送信元MACアドレスを見て「このポートの向こうにはこのデバイスがいる」と学習する。
しかし、なぜ学習した情報を永続的に保持してはいけないのか？ 理由はシンプルだ。「物理的なトポロジー変更」と「デバイスの移動」に対応するためである。
もしエージングタイマーが存在しなければ、あるPCがポート1からポート2へ物理的に移動した場合、スイッチは旧い情報を持ち続け、宛先不明のフレームを誤ったポートへ転送し続けることになる。エージングタイマーは、一定時間通信がないエントリを「もうこのデバイスはここにいない（あるいは休止している）」と見なし、テーブルから追い出すための「断捨離」の仕組みなのだ。
2. エージングタイマーのシーケンスと設計思想
デフォルトで多くのベンダー（Cisco等）が採用している 300秒（5分） という値には、歴史的な背景がある。
- 通信のライフサイクル: 多くのTCPセッションやARPキャッシュの保持時間は数分単位である。
- テーブルの枯渇防止: スイッチのメモリ（TCAM）は有限だ。使われていない古びたMACアドレスでメモリを埋め尽くすことは、パフォーマンス低下や新規学習の妨げになる。
トラブルシューティングの現場から
もし、あなたが現場で「特定の端末だけ通信が不安定になる」という事象に遭遇したら、まず疑うべきは「ARPのタイムアウト」と「MACエージングのミスマッチ」だ。
例えば、スイッチ側が 300秒 で学習を破棄するのに、上位のL3機器が 1800秒 でARPをキャッシュしていたらどうなるか？ L3機器は「まだ通信できる」と思ってパケットを送り続けるが、スイッチは既にMACアドレスを知らないため、そのパケットをすべてのポートに垂れ流す「未知のユニキャストフラッディング」が発生する。これがネットワークの帯域を食い潰し、ジッターやパケットロスを引き起こす原因になるのだ。
3. 実践：MACアドレステーブルの確認と制御
実際にスイッチの設定を確認し、制御する方法を見ていこう。CLIでの操作は、ネットワークエンジニアにとっての「聴診器」だ。
Cisco IOSでの設定例
! 現在のMACアドレステーブルを確認する
show mac address-table dynamic
! エージングタイムを調整する（環境に合わせて1800秒に変更する場合）
configure terminal
mac address-table aging-time 1800
endPythonでスイッチの情報を監視する（Netmiko使用例）
運用自動化の文脈では、定期的にテーブルサイズを監視することが重要だ。以下はPythonを使って現在のエントリ数を取得する簡易的なコードである。
from netmiko import ConnectHandler
# スイッチへの接続情報
device = {
'device_type': 'cisco_ios',
'host': '192.168.1.1',
'username': 'admin',
'password': 'password',
}
def check_mac_table_size():
with ConnectHandler(**device) as net_connect:
# MACアドレステーブルのサマリを表示
output = net_connect.send_command("show mac address-table count")
print(f"--- 現在のMACアドレステーブル状況 ---\n{output}")
if __name__ == "__main__":
check_mac_table_size()4. API設計者へ贈る、L2レベルの考慮事項
Web APIを設計する際、バックエンドのコンテナやサーバーが頻繁に立ち消えする（オートスケーリングする）環境では、MACアドレステーブルの挙動がアプリケーションのレイテンシに直結することがある。
特に、Keep-Alive が効いていない短命なコネクションが大量に発生する環境では、スイッチ側で頻繁にMAC学習が書き換わる「MACフラッピング」が発生しやすい。これを防ぐには、物理層での設計だけでなく、論理的に「どのノードがどのポートに属するか」を固定するか、あるいはエージングタイマーを環境のトラフィック特性に合わせて適正化（あるいはやや長めに設定）する判断が求められる。
まとめ：ネットワークは生き物である
MACアドレステーブルのエージングは、単なるパラメータの一つではない。それは、ネットワークという巨大なシステムが、刻一刻と変化する物理環境に対して「賢く適応する」ための生存戦略そのものだ。
これからインフラを設計する諸君には、ただデフォルト値に従うだけでなく、「なぜこの値なのか？」「この環境ならどう調整すべきか？」という問いを常に持ち続けてほしい。コマンド一つ、設定行一つに、そのネットワークの命運がかかっていることを忘れないでいただきたい。
さあ、次はどのプロトコルの深淵を覗こうか。現場からは以上だ。
コメント