本文へ移動

インフラ転職コンパス現場・技術・キャリアをつなぐ専門メディア

メニュー

未知のユニキャストフラッディングとは?MAC未学習時の動作

unknown unicast floodingは、宛先 MACがMAC テーブルにないunicast フレームを、受信ポートを除く同一VLAN内へ転送する動作です。ARP broadcastとは異なり宛先MACはunicastですが、未学習のためスイッチが出力ポートを特定できません。

この記事でわかること

  • 未知のユニキャストフラッディングとは?
  • broadcastとは何が違う?
  • MAC未学習はなぜ起きる?
  • Ciscoでflooding原因をどう確認する?

Xの元ポスト

宛先MACが学習されていないと未知のユニキャストとしてフラッディングされることがあると解説したポスト。

けんと@設計構築チャンネル
けんと@設計構築チャンネル
ユニキャストフラッディングを追うときは、VLAN、受信ポート、学習したMAC、転送先ポートを同じ表に置きます。項目を別々に見るより、フレームの流れと学習結果を対応させやすくなります。

未知のユニキャストフラッディングとは?

先に答えると、unknown unicast floodingは、宛先 MACがMAC テーブルにないunicast フレームを、受信ポートを除く同一VLAN内へ転送する動作です。ARP broadcastとは異なり宛先MACはunicastですが、未学習のためスイッチが出力ポートを特定できません。

broadcastとは何が違う?

unknown unicastは「宛先unicast MAC未学習」を担い、実務では「同一VLANへflood」を確認します。続く表で各要素の役割と判断点を比べます。

仕組みと判断軸
項目 仕組み・役割 実務での判断
unknown unicast 宛先unicast MAC未学習 同一VLANへflood
known unicast 宛先MAC学習済み 該当ポートだけ
broadcast 宛先FF:FF:FF:FF:FF:FF 同一VLANへflood
multicast group宛先 IGMP snooping等で範囲制御
構成・処理フロー
Server sends to MAC-B (not learned)
Gi1/0/1 → SW → Gi1/0/2, Gi1/0/3, Gi1/0/4... (same VLAN)
MAC-B source frame受信後: MAC-B→port学習、以降unicast

MAC未学習はなぜ起きる?

実施順は「対象VLAN/MACと発生時刻を特定」から「SPANでflood rateと宛先を観測」です。完了時には「capacity影響」を確認します。

実行手順と完了条件
STEP 実施内容 確認する結果
1 対象VLAN/MACと発生時刻を特定 対象範囲を限定
2 MAC テーブルの有無・aging・移動を確認 未学習理由
3 送信元側トラフィックとasymmetryを確認 学習フレームが戻るか
4 SPANでflood rateと宛先を観測 capacity影響
設定・確認例(対象機種・OS・バージョンで確認してください)
show mac address-table address 0011.2233.4455
show mac address-table aging-time vlan 20
show interfaces counters errors
show logging | include MACFLAP
show monitor session 1
正常時の出力例・記録例
VLAN20 target MAC: not present
Aging time: 300 seconds
Flood observed on access ports: 1,240 pps
Source frames from target: not observed on this switch

Ciscoでflooding原因をどう確認する?

「一方向stream」の場合は「宛先から送信元 フレームが来ない」を原因候補にし、次に「スタティック/receiver behaviorとpath」を確認します。正常時との差を症状ごとに追います。

正常時と異常時の切り分け
症状・誤り 主な原因候補 次に確認すること
一方向stream 宛先から送信元 フレームが来ない スタティック/receiver behaviorとpath
MAC agingが短い 再学習前にflood タイマーとトラフィック間隔
asymmetric L2 path 学習スイッチと転送スイッチが別 topology/MLAG
テーブル capacity超過 大量MAC・attack・ループ テーブル件数と制御

抑制前に何を直す?

unknown-unicast suppressionを先に強くすると、正当な初回トラフィックも落とす可能性があります。原因が一方向トラフィック、aging、ループ、capacityのどれかを確認し、抑制値はbaselineと業務影響から決めます。

  • 対象機器・インターフェース・VRF/VLAN
  • 取得日時・タイムゾーン・software バージョン
  • 変更前後の同一コマンド出力
  • 期待値・実測値・判定者
  • 異常時の停止条件と切り戻し結果

関連する仕組みを次に確認する

次の記事では、今回の確認を隣接するレイヤーや別の観測点へ広げます。

まとめ:宛先未学習の理由を送信元 フレームとL2 pathから確認する

要点は、宛先未学習の理由を送信元 フレームとL2 pathから確認することです。構成図、設定、確認コマンド、正常時と異常時の結果を同じ条件で保存すると、第三者も判断を再現できます。

最近の記事
お知らせ