Unknown Unicastとは？フラッディングの仕組み・原因・対策を図解

スイッチを通る一対一の通信なのに、関係のないポートにも同じフレームが見える。そんなときに確認したいのがUnknown Unicastです。

宛先MACは特定の一台を指していても、スイッチがそのMACの接続ポートを知らないことがあります。通常のL2転送では、同じVLANへフレームを複製して届けようとします。この動作がフラッディングです。正常な初回動作と、長く続く問題を分けて考えていきましょう。

Unknownは、スイッチが宛先の場所を知らない状態

送信者は相手のMACを指定しています。それでもスイッチのMAC表にその宛先がなければ、出すポートを一つに絞れません。Unknownとは、IPや端末名が不明という意味ではなく、そのスイッチが宛先MACを未学習という意味です。

スイッチは受信フレームの送信元MACから場所を学び、宛先MACで転送先を探します。この二つは別の処理です。

未学習の宛先へは、通常、受信ポート以外の同じVLANで転送可能なポートへ複製します。返信を受けると、その送信元MACを学べるため、次から相手のポートへ絞れます。

ブロードキャストとは、宛先の意味が違う

ブロードキャストは、最初から同じL2範囲全体を宛先にします。Unknown Unicastは、特定のMAC宛ですが、スイッチの学習状態によって広く転送されます。見た目のコピー数だけで分類しないようにします。

端末接続直後や経路の切替後に、短時間発生することはあります。一フレーム見つけただけで障害と判断する必要はありません。

調査したいのは、大量に続く、一定周期で増える、帯域や端末に影響が出るといった状態です。正常時と比べて、量・継続時間・きっかけを記録します。

MAC Flooding攻撃は、偽の送信元MACを大量に学習させるなどして表を圧迫する原因側の話です。Unknown Unicastという転送動作と、すぐに同じ意味で扱わないでください。

ARPが残っていても、MAC表は消えることがある

ルーターのARP表にはIPとMACが残り、スイッチのMAC表だけが消える場合があります。動的MACは一定時間、そのMACを送信元とするフレームを受け取らないと削除されるためです。これをエージングと呼びます。

ルーターは知っているMACへ送り続けますが、スイッチは場所を知らないのでフラッディングします。保持時間が別々の表なので、矛盾した表示ではありません。

1. ゲートウェイのARP表には宛先IP 172.28.31.50 → MAC bbbb.bbbb.bbbb が残っている。
2. L2スイッチのVLAN 10のMAC表では bbbb.bbbb.bbbb がagingで消えている。
3. ゲートウェイからのユニキャストフレームは宛先MACを指定しているが、スイッチは出力ポートを特定できず、受信ポート以外の同一VLANへ複製する。
4. 宛先端末がフレームを送れば、その送信元MACからポートを再学習し、通常のユニキャスト転送へ戻る。

受信中心の端末や、往路と復路が別のスイッチを通る構成では、送信元として観測できないスイッチが生まれることもあります。

ほかに、STPのトポロジ変更、MAC移動、表の容量、VLANやLAGの不整合も原因候補です。保持時間の調整だけで済ませず、学習しないのか、学んだあとで消えるのかを分けて調べます。

宛先MAC・VLAN・時刻をそろえて確認する

最初に、どのVLANのどの宛先MACが増えているかを絞ります。そのMACをshow mac address-tableで検索し、事象発生中に何度か取得します。場所が変わるのか、登録がないのかを見ます。

対象IPはARP表からMACと対応付けます。同じMACでも別VLANを検索すると別の結果になるため、VLANと取得装置をそろえます。

• 特定VLANだけか、複数VLANか
• 特定時間帯か、常時か
• どのポートで受信量が増えているか
• 構成変更、端末増設、回線切替、機器再起動があったか

SW01# show mac address-table dynamic
SW01# show mac address-table vlan 10
SW01# show mac address-table address bbbb.bbbb.bbbb
SW01# show mac address-table interface Gi1/0/24
SW01# show mac address-table count
SW01# show mac address-table aging-time

GW01# show ip arp 172.28.31.50
GW01# show ip arp | include bbbb.bbbb.bbbb

Internet  172.28.31.50  72  bbbb.bbbb.bbbb  ARPA  Vlan10

SW01# show spanning-tree vlan 10 detail
SW01# show interfaces status
SW01# show interfaces counters errors
SW01# show etherchannel summary
SW01# show logging | include MACFLAP|SPANTREE|UPDOWN|EC

MACが短時間に別ポートへ移るなら、ログ、STP変更、ポートのup/down、LAGの参加状態、端末側の冗長化を確認します。仮想マシンの移動など、正常な変化との区別も必要です。

表を先にclearすると、元の状態が消え、未学習の転送も一時的に増えます。調査では、現在の表とログを残すところから始めてください。

Wiresharkだけでは、未学習かどうかは決まらない

キャプチャに表示されたユニキャストの宛先MACだけでは、その時点のスイッチが学習済みかどうかは分かりません。スイッチのMAC表と、どのポートへコピーが出たかを合わせて判断します。

SPANで必要な場所を取得し、対象の宛先MACへ絞ると、関係のないポートにも同じフレームが出ているかを調べられます。

1. スイッチで問題VLANと宛先MACを特定する
2. SPANでアップリンクまたは疑わしいポートをミラーする
3. 特定の宛先MACへ絞ってキャプチャする
4. 本来関係ない複数のアクセスポート側でも同じフレームが見えるか確認する
5. 同時刻のMACアドレステーブルと照合する

# 特定の宛先MACへ絞る
eth.dst == bb:bb:bb:bb:bb:bb

# 特定の送信元または宛先MACを見る
eth.addr == bb:bb:bb:bb:bb:bb

# ブロードキャストを除外する
eth.dst != ff:ff:ff:ff:ff:ff

# 特定VLANに絞る（タグが取得できる場合）
vlan.id == 10

SPAN自身がコピーを作るので、取得条件も記録します。監視したポートと方向が不明なキャプチャでは、本来の転送と監視のコピーを区別しにくくなります。

確認結果には「未学習だったMAC表」と「同じ時刻に観測した転送」を対応させて残すと、判断の理由を説明できます。

抑制設定を入れる前に、学習できない理由を直す

switchport block unicastなどは、対応する機種で未知ユニキャストの出力を止める設定です。通信量を下げられても、MACを学習できない原因が直ったとは言えません。

対象ポートの先に本来の受信者がいれば、未学習中の必要なフレームまで落とす可能性があります。まず配線、VLAN、経路、タイマー、端末の送信状況を調べます。

interface GigabitEthernet1/0/10
 description USER-PORT
 switchport mode access
 switchport access vlan 10
 switchport block unicast

storm-controlは、機種ごとの計測対象と閾値超過時の動作を確認します。同じコマンド名でも、数える通信や停止動作が一律とは限りません。

フラッディングで別ポートへ届くことと、アプリが受信することも別です。ただし観測可能な端末があれば情報を見られる可能性はあるため、端末認証やネットワーク分離、通信の暗号化も合わせて考えます。

「なぜ未学習なのか」を説明できる状態へ

Unknown Unicastは、特定MAC宛の通信を、スイッチが一つのポートへ絞れない状態です。初回や切替直後の短い発生と、継続する大量の発生を分けます。

ARP要求は通常ブロードキャストなので、Unknown Unicastではありません。また、L2のフラッディングがそのままルーターを越えるわけでもありません。

VLAN、宛先MAC、表の変化、端末からの送信をそろえると、原因へ近づけます。設定で止められるかより先に、なぜ学べないのか、なぜ消えるのかを確かめてみてください。

この記事の執筆・監修者

けんと＠設計構築チャンネル

ネットワーク設計構築エンジニア／インフラ転職コンパス編集者

30歳・IT未経験からSIerへ転職。ネットワークエンジニアとして、金融系・オフィス系ネットワークの設計・構築に携わり、PL・PMも経験。自身の未経験転職と現場経験をもとに、仕事内容・技術・キャリア・求人選びをわかりやすく解説しています。

YouTube登録者5,000人 Xフォロワー5,000人

執筆者プロフィール・編集方針