変更要約: 初版
4.2DHCP・DNS・NTP
IPアドレスを自動配布するDHCPのDORA動作とサーバ／クライアント／リレーエージェント（ip helper-address）の役割、ホスト名をIPへ解決するDNSの役割、機器の時刻を階層的に同期するNTPのstratumとクライアント／サーバ設定を学び、「別セグメントの端末にIPが配られない」等の障害を切り分ける判断力を身につけます。
端末にIPアドレスを手動設定して回るのは非現実的なため、実務ではDHCPで自動配布します。名前でアクセスできるのはDNSが裏でホスト名をIPに解決しているからであり、ログの時刻をそろえて相関分析できるのはNTPで機器の時計を同期しているからです。CCNAでは、これら3つの「縁の下」サービスについて、動作の仕組みを土台に設定と障害切り分けを判断できるかが問われます。特にDHCPリレーは頻出の実務トラブルです。
4.2.1DHCPのDORA動作とリレーエージェント
- DHCPはクライアントとサーバ間でDORA（Discover→Offer→Request→Ack）の4メッセージでアドレスを貸与する。最初の Discover は宛先が定まらないためブロードキャストで送られる（サーバはUDP67、クライアントはUDP68）。
- ルータはブロードキャストを他セグメントへ転送しないため、DHCPサーバがクライアントと別サブネットにある場合、Discoverはサーバに届かない。この橋渡しをするのがDHCPリレーエージェントで、クライアント側インタフェースに
ip helper-address <サーバIP>を設定すると、ルータが受け取ったDHCPブロードキャストをサーバ宛のユニキャストに変換して転送する。 - Ciscoルータ自身をDHCPサーバにする場合は
ip dhcp pool <名前>→network/default-router/dns-serverを定義し、配布したくないアドレス（ルータのIP等）はip dhcp excluded-addressで除外する。
4.2.2DNSの役割
- DNSは
www.example.comのようなホスト名をIPアドレスに解決する仕組み。端末は問い合わせるDNSサーバのアドレスを（多くはDHCP経由で）受け取り、通信のたびに名前をIPへ変換する。 - 切り分けの勘所：
ping 8.8.8.8（IP直指定）は成功するのにping www.example.com（名前指定）が失敗するなら、IP到達性は正常でDNS名前解決だけが失敗していると判断できる。Cisco機器側ではip name-serverでDNSサーバを指定し、ip domain-lookupで名前解決を有効化する。
4.2.3NTPとstratum
- NTPは機器の時計を正確な基準時刻へ同期するプロトコル。時刻源からの距離をstratum（ストラタム）という階層値で表し、基準時計（GPS/原子時計）がstratum 0、それに直結したサーバがstratum 1、以降1ホップごとに数字が増える。stratumの値が小さいほど時刻源に近く信頼度が高い（16は未同期を意味する）。
- Cisco機器をNTPクライアントにするには
ntp server <IP>を設定するだけでよい。同期状態はshow ntp status（Clock is synchronized の表示・自機のstratum）やshow ntp associationsで確認する。正確な時刻はSyslogやデジタル証明書の検証、ログ相関に不可欠。
「DHCP Discoverはブロードキャスト／別サブネットのサーバには ip helper-address のリレーが必要」「リレーはブロードキャストをユニキャストに変換して転送」「NTPのstratumは小さいほど時刻源に近い」「ntp server でクライアント設定」「IP直pingは通るが名前pingが通らない＝DNS障害」が最頻出です。DHCPリレーの付け忘れは実務でも試験でも定番の切り分けポイントです。
あなたは複数サブネットを束ねるL3スイッチ（ルータ）を運用しており、本社サーバ室にある1台のDHCPサーバから全社にIPを配布しています。ある日、新設した営業部セグメント（10.20.0.0/24・サーバとは別サブネット）のPCだけが「IPアドレスを取得できません」という状態になりました。同セグメントで手動設定したPCからDHCPサーバへの ping は成功するため、経路（L3到達性）は正常です。それでも自動取得できないのは、DHCPの最初の Discover がブロードキャストであり、ルータ／L3スイッチはブロードキャストを別セグメントのDHCPサーバへ転送しないからです。既存の他部署セグメントでは正常に配布できていたのに新設セグメントだけ失敗する——この差分は、新設セグメントのゲートウェイインタフェースに ip helper-address <DHCPサーバIP> を設定し忘れていることを強く示唆します。対処として営業部のSVIに ip helper-address 10.10.1.5（サーバのIP）を設定すると、ルータが受信したDHCPブロードキャストをサーバ宛ユニキャストに変換して中継し、DORAが成立してIPが配布されます。ここで「サーバへpingが通るのだからDHCPも届くはず」と考えるのは誤り——pingはユニキャストのL3到達性、DHCP DiscoverはブロードキャストでリレーがなければL3境界を越えない、という動作の違いが切り分けの核心です。同様に、時刻がずれてSyslogの相関が取れない拠点があれば、その機器に ntp server が設定されているか・show ntp status が synchronized かを確認します。
| サービス | 役割 | 代表設定 | 切り分けの勘所 |
|---|---|---|---|
| DHCP | IPアドレス等を自動配布（DORA） | ip dhcp pool / 別サブネットは ip helper-address | 別セグメントで未取得＝リレー付け忘れ |
| DNS | ホスト名をIPに解決 | ip name-server / ip domain-lookup | IP直pingは可・名前pingは不可＝DNS障害 |
| NTP | 時刻を階層的に同期（stratum） | ntp server <IP>（クライアント） | show ntp status が not synchronized |
ひっかけ： 「DHCPサーバへpingが通るなら、別サブネットの端末も自動でIPを取得できるはずだ」は誤りです——pingはユニキャストのL3到達性を確認するだけで、DHCP Discoverはブロードキャストなので、リレー（ip helper-address）がなければL3境界を越えてサーバに届きません。また「NTPはstratumの値が大きいほど時刻源に近く高精度」も誤り＝stratumは小さいほど時刻源に近く信頼度が高い（stratum 1が最上位、16は未同期）。
4.2.4この節のまとめ
- DHCPはDORAでアドレスを貸与。Discoverはブロードキャストのため、別サブネットのサーバには
ip helper-addressのリレーが必須（ブロードキャストをユニキャストへ変換） - DNSはホスト名をIPへ解決。IP直pingは通るが名前pingが通らないなら到達性は正常でDNS名前解決の障害
- NTPは時刻を同期しstratumが小さいほど時刻源に近い。クライアントは
ntp server <IP>、状態はshow ntp statusで確認
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 新設した営業部セグメント（DHCPサーバとは別サブネット）のPCだけがIPアドレスを自動取得できない。同セグメントで手動設定したPCからDHCPサーバへのpingは成功する。既存の他部署セグメントでは正常に配布できている。最も可能性の高い原因はどれか。
Q2. ある端末から `ping 8.8.8.8`（IPアドレス直指定）は成功するが、`ping www.example.com`（ホスト名指定）はすべて失敗する。この現象から最も強く疑われる原因はどれか。
Q3. 複数のNTPサーバから時刻を取得できる環境で、どのサーバを基準に同期すべきかを判断する。stratum値に関する説明として最も適切なものはどれか。