本記事では、Meraki機器がDHCPサーバとして利用されている環境において、端末からのDHCPのリクエストがRejectされる事でDHCPエラーとなっている事象と、その調査方法について解説しています。
※1: MRもNATモードにおいてはDHCPサーバの役割を担いますが本記事では対象外となります。
※2: 本記事ではDHCPのNegative ACKnowledgementはNAKまたはNACKと表記されます。
※3: 本記事の内容ではMeraki機器がDHCPサーバとして稼働している前提ですが、他機器の場合でも発生する場合があります
※4: DHCP NAKは本記事に記載以外の要因や原因で発生する事もあり、その場合DHCPサーバ側の詳細ログ（Meraki機器以外の場合）等を含め詳細調査が必要となります。
// 概要 //
事象は主に無線接続環境で発生する場合が多く、DHCPエラーとしてダッシュボード上で確認できますが、MRの接続ログにおいて端末のリクエストに対し下記のようにdhcp_nackでrejectされるログ（Client made a request to the DHCP server, but the DHCP server rejected the client's request）が確認できます。
またエラー発生後、実際には端末がDHCPのリクエストを再実施し正しいIPアドレスを取得できる場合があり、ユーザ側では接続時に時間がかかっているといった状況になっていると想定されます。
この事象は特にDHCPプールにおける枯渇がしていない状況下でも発生しますが、通信経路で取得したパケットキャプチャでは端末がDHCP Requestを出した後に、Meraki機器側がDHCP NAKを返す様子が確認できます。
例：MXのLAN側で取得した例で#80でMXがDHCP NAKを返している
// 事象原因 //
本事象は対象環境や設定によって発生することがあり、主に以下のような環境で発生します。
・MX（またはMS）をDHCPサーバとし、その配下にMRが接続されているような構成
・ダッシュボード上でNetworkが複数あり、同じ設定のSSIDを利用しているような設定
（または同一ネットワーク内でも、こちらの設定で異なるフロア等に配置されたAPに対し、Tagで割当VLANを変えているような場合）
・端末が上記異なるネットワーク間（同じ建物内の別フロア、広い施設における別の場所・別館等）を物理的に移動するような環境
上記において、端末が移動元で保持してるIPアドレスを移動先の場所で利用する際にDHCP RequestすることでMX（またはMS）がそれをNAKでRejectする場合があります。こちらの挙動は端末の種別やOSにも依存し、Apple iOSデバイスにおける詳細についてはこちらのKBをご参照ください。
該当箇所：
Before an Apple iOS device uses DHCP to obtain an IP address on a new network connection, it will first attempt to re-use the IP address configuration received from a previous networks DHCP server.
例：DHCP NAKの前に端末が#79で10.xx.xx.111でDHCP Requestをしている
上記NAKの理由としては以下のような場合が考えられますが、そのトリガーとしては上述の通り端末の挙動に依存します。
(1)端末が接続されたVLANとは異なるIPアドレスをRequestしている
(2)端末からRequestされたIPアドレスが既に別の機器で利用されている
上記1に関しては異なるNetwork間でSSIDに対し割り当たるIPアドレスレンジが異なる場合に発生しますが、IPアドレスレンジが同じであっても、2のような理由でNAKになる場合もあります。
// 事象対応方法 //
対応としては主に以下のようなものが考えられます。
1. クライアントの動作上やむをえず発生するエラーであるため、実影響を確認しダッシュボード上のエラー発生自体は許容する
2. ネットワーク構成、またはSSIDの変更
// 問題切り分け方法 //
該当DHCPエラーが確認できた場合、通常下記のような順序での確認で詳細が分かる場合があります。
1. エラーが発生した端末のMACアドレスが該当時間に移動をしていたか
建物図面やユーザへの確認を行います
2. 移動をしている場合、移動元及び移動先のNetworkでの接続履歴を時系列に確認
ネットワーク全体 ＞ イベントログ ＞ アクセスポイント向けの画面で、端末MACアドレスでフィルタし確認
3. 移動元のNetworkでリースされたIPアドレスを確認
イベントログ上でMXまたはMSの画面に切り替え、移動元のNeytworkでDHCPリース時のIPアドレスを確認
4. NAKの理由の調査
移動先のNetworkで同じIPアドレスレンジの場合、上記3のIPアドレスが別端末で既に利用されていないか、または端末の接続VLANが移動元と異なるIPアドレスレンジになっているか確認。
5. パケットキャプチャの取得
必要に応じて該当端末で移動し事象再現をさせている間に通信経路（APの有線やMXのLAN側）でパケットキャプチャを実施し端末がRequestしているIPアドレスやその後のNAKを確認します。
//参考情報//
Configuring DHCP Services on the MX and MS
