はじめに

ある日、校内の教育系Wi-Fiに接続したWindows端末のタスクマネージャーを見ると、何もしていないのに常時1〜1.5Mbps程度の受信トラフィックが発生していた。同じPCを校務系ネットワークに有線接続すると止まる。何の通信なのか。

本記事では、この「謎の通信」の原因特定から対策実施、効果測定までの過程を記録する。

環境

生徒用iPad：約600台（Jamf Pro管理）
Apple TV：約30台（教室に設置）
管理外の教員iPad・iPhone：約140台　※教育系はBYOD端末の接続を許可
SSID：共通（802.11ax）
スイッチ：NEC QX-S1124GT-4G-PW（主スイッチ1台＋ブランチスイッチ9台）
ルーター：NEC IX2235
UTM：FortiGate 60F（透過モード）
すべての端末が同一L2セグメント（192.168.192.0/20）に存在

1. 原因の特定

リソースモニターで確認

タスクマネージャー → パフォーマンス → リソースモニターを開く → ネットワーク

上位に並んでいたのは以下のプロセスだった。

プロセス	アドレス	受信（バイト/秒）
mDNSResponder.exe	mdns.mcast.net	79,505
svchost.exe (NetworkService)	mdns.mcast.net	79,507
chrome.exe	mdns.mcast.net	79,505

mdns.mcast.net = 224.0.0.251 はmDNSのマルチキャストアドレスである。IPv6側では ff02::fb 宛に同様の通信が確認された。

Wiresharkで詳細分析

udp.port == 5353 でキャプチャし、フィルタなしの全トラフィックも別途取得した。プロトコル階層統計の結果、全トラフィックに占めるmDNSの割合は85.9%（IPv4 43.0% + IPv6 42.9%）であった。タスクマネージャーで観測される1〜1.5 Mbpsの受信トラフィックのほぼすべてがmDNSということになる。

送信元を分析すると、iPad・Apple TVが以下のmDNSサービスをアナウンスしていた。

送信元	サービス	パケットサイズ
iPad	`_companion-link._tcp`（Handoff・Sidecar）	約430 B
Apple TV	`_airplay._tcp` / `_raop._tcp` / `_sleep-proxy._udp`	約1,400〜1,500 B

iPad 1台あたりは小さなパケットでも、600台が同一L2セグメントにいるため、全端末がすべてのmDNSパケットを受信し続ける状態になっていた。

mDNSとIGMPスヌーピング

mDNSが使用する 224.0.0.251 はリンクローカルマルチキャスト（224.0.0.0/24）に属し、RFC上IGMPスヌーピングの対象外として常にフラッディングされる。IGMPスヌーピングではこの問題を解決できない。

2. 対策① — Jamf ProでHandoff制限

設定内容

Jamf Pro → 構成プロファイル → 制限 → 機能 → 「Handoffを許可」をオフ

_companion-link._tcp はHandoff・Sidecar・Universal Control・iPhone Mirrorが共用するサービスであり、Handoffを無効化すればアナウンスが抑制されると期待した。

効果と限界

時点	タスクマネージャー実測値
制限前（授業中）	1～1.5 Mbps
制限5分後（6限終了直後）	1Mbps程度
制限後（放課後・部活時間）	約600Kbps～1Mbps
制限後（翌日授業中）	1～1.5 Mbps

制限5分後、わずかにトラフィックが下がった。
この時間はまだ生徒は清掃や帰りの会のために学校におり、接続iPadの台数は変わっていないはずである。
効果があり、プロファイルが浸透すればさらに下がるのかと期待した。

その後、放課後になるとトラフィックが減少すると考えていた。
しかし、放課後も数値がゼロには近づかなかった。この残存トラフィックの主体はApple TVであることが分かった。

さらに翌日の確認で、プロファイル適用済みのiPadからも _companion-link が送出され続けていることが判明した。端末の設定画面を確認するとHandoffは無効・変更制限済みであり、プロファイルは正しく適用されていた。

iOS 17以降、Appleは _companion-link の用途をiPhone Mirror（iOS 18〜）やContinuity Cameraにも拡張しており、Handoffを無効にしてもmDNSアナウンス自体は完全には停止しない仕様になっている。

また管理外の教員iPadとiPhoneはHandoff制限ができないため、約140台分のmDNSは制御不能である。

Jamf側での対策には限界があると判断し、ネットワーク側での対策に移行した。

3. 対策の方針検討

VLAN分割 vs ACL

当初はブランチスイッチ単位でVLANを分割する案を検討した。

方式	mDNS閉じ込め効果	副作用
VLAN分割	高い	教室移動のたびにIPアドレスが変わる。IX2235のサブインターフェース、DHCP設定変更など影響範囲が広い
ACL（主スイッチ）	同等	既存のIPアドレス体系に影響なし。設定変更はSW000のみ

教育系ネットワークでは生徒が授業ごとに教室を移動するため、VLAN分割はDHCPリース管理の問題が大きい。ACLでmDNSだけをブランチ間でブロックする方が、同等の効果を最小の変更で実現できると判断した。

4. 対策② — 主スイッチ（SW000）にmDNSブロックACLを適用

構成

主スイッチSW000のブランチスイッチ接続ポート（8本）のインバウンドにACLを適用し、ブランチ間のmDNSフラッディングを遮断する。

[SW000]
  GE1/0/2〜6   AP（特別教室・直結）    → ACL適用しない
  GE1/0/9      Webサーバー             → ACL適用しない
  GE1/0/13     IX2235（上流）          → ACL適用しない
  GE1/0/17     Linux DNS/DHCPサーバー  → ACL適用しない
  GE1/0/21     SW009                   → ★ACL適用
  GE1/0/22     SW008                   → ★ACL適用
  GE1/0/23     SW006（SW007はSW006配下）→ ★ACL適用
  GE1/0/24     SW005                   → ★ACL適用
  GE1/0/25     SW004                   → ★ACL適用
  GE1/0/26     SW003                   → ★ACL適用
  GE1/0/27     SW002                   → ★ACL適用
  GE1/0/28     SW001                   → ★ACL適用

SW000直結のAP（GE1/0/2〜6）にはACLを適用しない。理由は2つある。

特別教室のAPであり普段生徒が少なく、mDNSが流れ込んでも影響が小さい
直結APにACLを適用すると、そのAP配下でのAirPlayも不可になる

投入コマンド（NEC QX Comware）

system-view

acl advanced 3001
 rule 1 deny udp destination 224.0.0.251 0 destination-port eq 5353
 rule 2 permit ip

acl ipv6 advanced 3601
 rule 1 deny udp destination ff02::fb 128 destination-port eq 5353
 rule 2 permit ipv6

interface GigabitEthernet1/0/21
 packet-filter 3001 inbound
 packet-filter ipv6 3601 inbound
interface GigabitEthernet1/0/22
 packet-filter 3001 inbound
 packet-filter ipv6 3601 inbound
interface GigabitEthernet1/0/23
 packet-filter 3001 inbound
 packet-filter ipv6 3601 inbound
interface GigabitEthernet1/0/24
 packet-filter 3001 inbound
 packet-filter ipv6 3601 inbound
interface GigabitEthernet1/0/25
 packet-filter 3001 inbound
 packet-filter ipv6 3601 inbound
interface GigabitEthernet1/0/26
 packet-filter 3001 inbound
 packet-filter ipv6 3601 inbound
interface GigabitEthernet1/0/27
 packet-filter 3001 inbound
 packet-filter ipv6 3601 inbound
interface GigabitEthernet1/0/28
 packet-filter 3001 inbound
 packet-filter ipv6 3601 inbound

return
save force

AirPlayへの影響

パターン	動作
同一ブランチSW配下のiPad ↔ Apple TV	✅ 正常動作（SW000を経由しない）
異なるブランチSW間のAirPlay	❌ 不可（ACLでブロック）
SW000直結AP配下のiPad ↔ Apple TV	✅ 正常動作（ACL未適用）
電波が届く隣のAP配下のApple TV	✅ 表示される（無線のマルチキャストはACL対象外）

教室でのミラーリング先表示は、これまでの全校全台表示から電波の届く範囲のApple TVのみに変わった。教室間の移動でAppleTVが表示されないケースは発生しておらず、運用上問題はない。

5. 効果測定

トラフィック推移

時点	タスクマネージャー実測値
対策前（授業中）	1〜1.5 Mbps
Handoff制限後	1～1.5Mbps
Handoff制限後（放課後・部活時間）	約600Kbps～1Mbps
ACL適用後(放課後・部活時間)	約40 Kbps

タスクマネージャーの実測値で97%以上削減した。

ACL適用後のプロトコル階層

ACL適用後のWiresharkプロトコル階層統計では、mDNSは主要プロトコルから消え、TLS（正常な暗号化通信）やARP（L2アドレス解決）が上位に来る健全な状態になった。

※注意点※

上記のトラフィック推移とプロトコル階層の調査結果は、放課後の測定であった。
それでも、タスクマネージャによる通信は設定前後で瞬間的に改善し、
体感できる程度にAppleTVのミラーリングが素早く確立されるようになった。
週明け日中に調査し、トラフィックと実際のミラーリングや通信の使用感が改善されていることを期待。

6. まとめ

対策	効果	作業コスト
Jamf ProでHandoff制限	約半減（ただしiOS仕様変更で完全には止まらない）	低
主スイッチにmDNSブロックACL	▼97%（1〜1.5 Mbps → 約40 Kbps）	低

iPad・Apple TVが大量に存在する学校ネットワークでは、mDNSが深刻な帯域消費を引き起こす。同一L2セグメントに数百台のAppleデバイスを収容する場合、主スイッチでmDNSをブランチ間ブロックするACLが、VLAN分割よりも低コストかつ即効性のある解決策となる。

追記：ブランチスイッチでIPv6 mDNSをブロック

授業中の再測定

ACL適用後の放課後に測定した40 Kbpsという数値は、大半の生徒が下校した後、最も接続APの少ないスイッチSW008配下での測定結果であった。
翌週月曜の授業時間に、最も接続AP（=クライアントiPad）が多いスイッチSW001配下で再測定したところ、280 Kbps・mDNS比率75%であった。
先週末測定したSW008の放課後測定値よりは増えるが、対策前の1〜1.5 Mbpsと比べれば大幅な改善である。

IPv6 mDNSの重複送信

Wiresharkの分析で、iPadは同一のmDNSアナウンスをIPv4とIPv6で同時に送信していることが分かっていた。AirPlayの発見にはIPv4のmDNSだけで十分であるため、IPv6側のmDNS（ff02::fb 宛、UDP 5353）を破棄しても機能に影響はない。

実装

各ブランチスイッチ（SW001〜SW009）のAP接続ポートのインバウンドにIPv6 mDNSのみを破棄するACLを適用した。アップリンクポートや他のスイッチ接続ポートには適用しない。

system-view

acl ipv6 advanced 3602
 rule 1 deny udp destination ff02::fb 128 destination-port eq 5353
 rule 2 permit ipv6

interface GigabitEthernet1/0/1
 packet-filter ipv6 3602 inbound
interface GigabitEthernet1/0/2
 packet-filter ipv6 3602 inbound
...（AP接続ポートすべてに適用）

return
save force

最終結果

時点	トラフィック	mDNS割合
対策前（授業中）	1〜1.5 Mbps	85.9%
SW000 ACL適用後（授業中）	280 Kbps	75%
＋全SW IPv6 mDNSブロック（授業中）	132 Kbps	70%

最も端末密度の高いスイッチSW001配下での測定であり、他のエリアではこれ以下になる。残る132 Kbpsの主体は、同じAPに接続中のiPadから無線レベルで届くmDNSであり、有線側のACLでは制御できない領域である。

AirPlayのミラーリングは正常動作を確認済み。接続確立の体感速度も改善された。

今後の確認事項

AirPlayの安定性改善の確認（mDNS輻輳がハンドシェイクパケットロスの原因であった可能性）