1. はじめに

　Ciscoルータ内で動作しているDHCP Serverが意図しないNAKを返していたため，それを解決した時に調査した内容のメモ．

2. ネットワークの概要

　某所のネットワークをCisco1941を使用して管理していました．管理を行なっていたネットワーク図（今回の問題に関係する部分だけを示している）は図1のようなものになっています．インターネットにはNAPT変換を使用しており，私たちが所属する建物を管理する管理者のネットワークを介して接続されています．またIPアドレスはDHCPで取得し，Cisco1941上でローカル向けにDHCPサーバが動作しています． f:id:tyanogi:20180717155533p:plain

図1：管理してるネットワーク図

3. インターネットに接続できなくなった

　ある日インターネット側のIPアドレスが割り当てられなくなり，インターネットに接続することができなくなりました．建物の管理者に問い合わせたところ管理していないDHCPサーバが送信元のパケットを検知したため，IPアドレスの割り振りを遮断したとのことでした（通知をしないまま遮断するのはやめて…）．

4. 再現性を確保する

　建物の管理者と連絡を取りながら問題を解決するのは時間がかかるため，なんとか私が管理できるネットワーク内でこの問題を再現できるようにします．　

4.1 原因の特定

　建物の管理者の連絡から問題の原因を推測すると以下のようなことが考えられました．

Gi0/0から入ってきたDHCP要求に対してGi0/0にDHCP OfferメッセージまたはNACKメッセージを送信している可能性がある．
Gi0/1から入ってきたDHCP要求に対してGi0/0にDHCP OfferメッセージまたはNACKメッセージを送信している可能性がある．

　建物の管理者からの連絡は情報量が少なくなく，DHCPサーバがどうようなパケットを送信していたのかがわからなかったため再問い合わせしました．するとpcapファイルをいただくことができました！！（原因の特定をするのがめんどくさかったのでは…）
　実際にpcapファイルを調査したところ，どうやらCisco1941内で動作しているDHCPサーバからNAKを返しているようでした．

4.1 実験

　原因を特定できたので実際にDHCP Requestメッセージを送信した際にDHCPサーバがNAKを返すか実験してみます．今回はDHCP Discoverメッセージも反応するか確認するため送信しています．
　結果，DHCP Requestメッセージを作成してGi0/0に送信してみたところNAKが返ってきました！図2はその時にパケットキャプチャしたものです．パケットキャプチャはDHCP Requestメッセージを送信した端末でおこないました．Gi0/0のIPアドレスは一時的に172.16.0.254/16を割り当ててあります．

f:id:tyanogi:20180717151807p:plain

図2：パケットキャプチャした図

　しかし，なぜDHCP Requestメッセージには反応してDiscoverメッセージには反応しないのか調べてもよくわかりませんでした．IOSの仕様？分かる方がいましたら教えていただけると幸いです．
　

5. 問題の解決

　さてこの問題の解決方法なのですが，私の場合拡張ACLを使用して解決をしました．NAKを返す原因を特定してからまず初めに思い浮かんだのがこの解決方法だったのですが，他の方法もあるのではないかと思い調査していました（2週間くらい探してた…）．
　結果，私の調査した範囲では拡張ACLを使用する方法 [1]しか見つかりませんでした．以下がCisco1941に適応させた拡張ACLの設定になります．

ip access-list extended Deny_DHCP_Client
 deny   udp any any eq bootps
 permit ip any any

int gi0/0
ip access-group Deny_DHCP_Client in

参考

[1] WAN interface sending DHCP NAK，https://supportforums.cisco.com/t5/lan-switching-and-routing/wan-interface-sending-dhcp-nak/m-p/2615904

ちゃんおぎのメモ置き場

ネットワークに強くなるために少しづつ頑張るブログです．

Ciscoルータ内で動作しているDHCP Serverが意図しないNAKを返す