深夜の運用センターで、CoreスイッチのSyslogが「%SW_MATM-4-MACFLAP_NOTIF」を吐き出し続けている。客先電話「特定のサーバが時々応答しない」。心拍数が上がる。これ、ほぼ確実にMAC Flappingです。
MAC Flapping（MACアドレス揺らぎ）は、本来1つのポートにしか学習されないはずのMACアドレスが、短時間で別のポートに移動を繰り返す現象。原因の8割はL2ループ、残り2割は冗長構成の設計ミスや仮想化環境のvSwitch挙動。この記事では現場で実際に踏んだケースを混ぜつつ、切り分けの順序と確認コマンドを整理しました。
対象は Catalyst 2960 / 9300 系を中心としたCisco IOS / IOS-XE。ただ、ロジック自体はAristaやJuniperでも同じなので、他ベンダーでも応用できます。
そもそもMAC Flappingはどう判定されているのか
Ciscoスイッチは、CAM（Content Addressable Memory）テーブル上で「同じMACアドレスが同じVLAN内で別ポートに学習された」イベントを検出すると、MAC Flap通知を出します。デフォルトでは1秒に複数回の上書きが起こるとSyslogに警告を出力する仕様。閾値はプラットフォームによって違うけれど、Catalystの一般的な挙動としては「同一MACが1秒に2回以上、別ポートで再学習」がトリガー。
Cisco公式ドキュメント（”MAC Address Flapping”）でも、MACが同一VLAN内で頻繁にポート間を移動する場合の主原因として、L2ループ・冗長リンクのSTP無効化・誤配線を挙げています。
以前、客先で「ファイル共有が30秒おきに切れる」というクレームを受けて駆けつけたことがある。Syslogを見るとMACFLAPが秒間100件オーダー。原因は、ユーザーが机の下に置いた500円の家電量販店のスイッチングHubでBPDUが透過せず、フロアSWの2ポートを橋渡ししていた。物理を見るまで30分くらいかかった、これは反省。
放置するとどうなるか
MACが揺れている間、フレームの転送先が定まらないので、ユニキャスト通信がフラッディングに化けたり、TCPセッションが瞬断したりする。さらにL2ループ起因の場合はブロードキャストストームに発展してCPU使用率が99%に張り付き、最終的にスイッチが管理不能になる。経験上、Flap発生から完全停止まで早ければ数分。
原因は大きく分けて4パターンに分類できます。発生比率は私の体感ですが、実務でよくぶつかる順に並べました。
| 原因パターン | 具体例 | 見るべき場所 |
|---|---|---|
| L2ループ（物理） | PoEに簡易Hub接続、ユーザーがLANケーブルをループ刺し | 物理配線・BPDU Guard・Storm Control |
| 冗長配線でのSTP無効 | portfast trunk誤設定、no spanning-tree vlan | show spanning-tree、interface config |
| 仮想化環境のvSwitch挙動 | vMotion・LBT・VRRPトラックのMAC移動 | ハイパーバイザのNICチーミング設定 |
| MACアドレス被り | USB-LANアダプタのROM焼きミス、VRRP/HSRPの仮想MAC衝突 | 該当MACの所有機器、VRRPグループID |
図1: MAC Flappingの原因別発生比率（私が過去に遭遇した30件ベース）
60%
20%
15%
5%
ちなみに、4番のMAC被りは数として少ないけれど、見つけるまでが一番厄介。物理的にはどこも問題なく見えるから、CAMテーブルとアームの突き合わせをやらないと判明しない。
まずSyslogから揺らいでいるMACと該当ポートを特定する
Switch# show logging | include MACFLAP *Apr 29 02:14:33.218: %SW_MATM-4-MACFLAP_NOTIF: Host aaaa.bbbb.cccc in vlan 10 is flapping between port Gi1/0/24 and port Gi1/0/1 *Apr 29 02:14:34.005: %SW_MATM-4-MACFLAP_NOTIF: Host aaaa.bbbb.cccc in vlan 10 is flapping between port Gi1/0/1 and port Gi1/0/24 *Apr 29 02:14:34.812: %SW_MATM-4-MACFLAP_NOTIF: Host aaaa.bbbb.cccc in vlan 10 is flapping between port Gi1/0/24 and port Gi1/0/1
この時点で、容疑者は Gi1/0/1（uplink側） と Gi1/0/24（downlink側）。MACアドレスは aaaa.bbbb.cccc、VLANは10。ここで両方のポートに同じMACが現れているということは、その2ポートの間で物理ループが組まれているか、L3的に同じMACを持つ機器が2台ぶら下がっているか、のどちらか。
「flapping between port X and port Y」のYが Po1（Port-channel）になっている場合、EtherChannel配下のメンバーポートで起きていることが多い。show etherchannel summary でメンバーを確認すること。Po配下なら正常動作のケース（HSRP仮想MAC同期など）もあるので、即ループ判定はNG。
Switch# show mac address-table address aaaa.bbbb.cccc
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
10 aaaa.bbbb.cccc DYNAMIC Gi1/0/24
「あれ、1ポートしか出ない」と思うけど、これはコマンド実行の一瞬を切り取っただけ。show mac address-table count や、後述の debug mac-notification と組み合わせて時系列で見る必要がある。
Switch# show interfaces Gi1/0/24 | include rate 30 second input rate 412358000 bits/sec, 38291 packets/sec 30 second output rate 410992000 bits/sec, 38104 packets/sec Switch# show interfaces counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi1/0/24 0 0 0 0 0 0
入出力レートが400Mbps級でほぼ対称、しかもエラーカウンタはゼロ。これがL2ループの典型的なシグネチャです。エラーがゼロなのは「ループしているフレーム自体は正常なフレームだから」。
| コマンド | 用途 | 見るべき値 |
|---|---|---|
show logging | inc MACFLAP | Flap発生履歴と該当MAC、ポートペアの抽出 | MAC、VLAN、port pair |
show mac address-table address X | 特定MACの現在の学習ポート | Type=DYNAMIC, Port |
show spanning-tree vlan 10 | Forwarding/Blockingが期待通りか | Role, Sts |
show interfaces counters errors | 物理層のエラーが伴っていないか | CRC、Align-Err |
show cdp neighbors detail | 想定外の機器がぶら下がっていないか | DeviceID、Platform |
show storm-control | Storm Controlで遮断されたポート確認 | Action状態 |
STPの状態を必ず確認する
VLAN0010
Spanning tree enabled protocol rstp
Root ID Priority 24586
Address 0011.2233.4455
Cost 4
Port 25 (GigabitEthernet1/0/25)
Interface Role Sts Cost Prio.Nbr Type
----------------- ---- --- --------- -------- --------------------------------
Gi1/0/1 Desg FWD 4 128.1 P2p
Gi1/0/24 Desg FWD 4 128.24 P2p Edge
怪しいのは Gi1/0/24 が P2p Edge になっていること。Edgeポート＝portfast扱い、つまりBPDUを送らない設定。下流に簡易Hub経由でループが組まれていても検知できない。BPDU Guardが入っていないと、ここでループが完成する。
物理ループには即座に該当ポートをshut
原因が物理ループと特定できたら、まずは該当ポートをshutdown。サービス影響を最小化したうえで、現地に行って配線を確認する。これが最速の止血。
Switch(config)# interface GigabitEthernet1/0/24 Switch(config-if)# shutdown
恒久対策：エッジポートにBPDU Guardを必ず
portfastだけ入れて満足する設計は本当に多い、けど危険。BPDU Guardをセットで入れると、Hub経由でBPDUが流れ込んできた瞬間にerr-disableで遮断してくれる。
Switch(config)# spanning-tree portfast bpduguard default Switch(config)# errdisable recovery cause bpduguard Switch(config)# errdisable recovery interval 300
errdisable recoveryを300秒で自動復旧にしておくと、ユーザーが配線を直したあとに勝手に復活してくれる。深夜呼び出しが減る。個人的にはこの組み合わせが一番好き。
仮想化環境のFlapはvSwitch側を疑う
VMware ESXiやHyper-Vでは、NICチーミング設定とアップリンクの組み合わせ次第でMAC Flapが正常動作として発生する。たとえばESXiの「ルートベース：発信元仮想ポートIDベース」と物理SW側のEtherChannelの不整合とか。物理SW側を直すか、ハイパーバイザのチーミングをLACPに合わせるかの2択。
vMotion中に一時的にMAC Flapが出るのは仕様。アラート対象から除外したいときは、該当VLANのMAC通知抑止を検討する。ただ、抑止しすぎると本物のループを見落とすので、しきい値ベースで監視するのが正攻法。
MAC被りはまずvendor partを確認
同じMACが2台ぶら下がっているケースは、OUI（先頭24bit）でベンダーを調べると特定が早い。怪しいUSB-LANアダプタや古いNICで起きやすい。物理的にどちらかをshutして残ったMACの所在で犯人を絞る、というアナログだけど確実な方法を取る。
| 対策 | 設定例 | 効果 |
|---|---|---|
| BPDU Guard | spanning-tree portfast bpduguard default | エッジでループ即遮断 |
| Loop Guard | spanning-tree loopguard default | 単方向リンク起因のループ防止 |
| Storm Control | storm-control broadcast level 1.00 | ブロードキャストの暴走を抑制 |
| UDLD | udld enable | 光ファイバの単方向通信検知 |
| MAC通知監視 | mac address-table notification mac-move | SNMPトラップでFlapを検知 |
余談だけど、Cisco IOS-XE 16.x 以降でmac address-table notification mac-moveを有効にしておくと、%MAC_MOVE-SP-4-NOTIFでも検知できる。MACFLAP_NOTIFと組み合わせるとSyslog監視がだいぶ楽になる。
- スパニングツリープロトコル（STP）の仕組みをわかりやすく図解｜BPDU・ルートブリッジ・RSTP収束時間の違い【Cisco設定例付き】
- Cisco Storm Control設定手順とerr-disabled復旧方法｜errdisable recovery・閾値設定・ループ対策【コマンド付き】
- Trunkポートで特定VLANだけ通信できない原因と対処法｜allowed vlan・Native VLAN・DTPの落とし穴【Cisco実機検証】
- Cisco show interfacesの見方｜エラーカウンタ（CRC・input errors・output drops）の意味と対処法【counters errors対応】
この記事の要点
MAC Flappingの大半はL2ループ。Syslogから揺らぐMACとポートペアを特定し、show spanning-treeでBlocking状態を確認、対称な高トラフィックが見えたら物理を疑う。恒久対策はBPDU Guard + errdisable recoveryをエッジに必ず仕込むこと。仮想化環境ではvSwitch側のチーミング設定との不整合も忘れずに。
よくある質問（FAQ）
Q. MAC Flappingは放置しても大丈夫ですか？
A. 仮想化のvMotionなどに伴う一時的なFlapは無害ですが、秒間で複数件出続ける場合は確実にループ起因。CPU使用率がスパイクし、最悪スイッチが管理不能になります。早めの切り分けを推奨。
Q. MACFLAP_NOTIFのSyslogレベルを変更できますか？
A. logging discriminatorでフィルタは可能ですが、レベル自体（Warning=4）は変更不可です。監視側で抑止するか、mac address-table notification mac-moveと組み合わせて閾値監視に切り替えるのがおすすめ。
Q. EtherChannel配下でMACFLAPが出るのは異常ですか？
A. メンバーポート間で揺れているように見えるケースは、ハッシュ計算上は正常動作のことも。Po（Port-channel）論理ポートとして1つの場所に学習されていれば問題なし。show etherchannel summaryで状態を必ず確認してください。
Q. 切り分けの最初に見るべきコマンドは？
A. まずshow logging | include MACFLAPで揺れているMACとポートペアを特定。次にshow interfaces <port> | include rateで対称な高トラフィックの有無、最後にshow spanning-tree vlan <vlan>でSTPのRole/Stsを確認、の順番が早い。
