IP Services Command List

DHCP and relay

ip dhcp excluded-address <start> <end>
ip dhcp pool USERS
network <network> <mask>
default-router <gateway>
ip helper-address <server>
show ip dhcp binding

NAT

ip nat inside
ip nat outside
ip nat inside source list 1 interface gi0/1 overload
show ip nat translations
show ip nat statistics

Operations

ntp server <address>
logging host <address>
ip name-server <address>
show clock
show logging

Do not confuse

DHCP supplies host configuration; DNS resolves names; NTP synchronizes time.

SNMP polls and reports management data, while syslog sends event messages.

Policing enforces a rate by dropping or remarking excess traffic; shaping delays excess traffic in a queue.

Real scenarios you'll actually face

"We need to set up DHCP relay for the new branch office." A DHCP client's initial Discover message is a Layer 2 broadcast — it never leaves its own subnet on its own, which means a DHCP server sitting on a different subnet (the normal case in any real network) never sees it. `ip helper-address <server>` goes on the router interface facing the CLIENTS — the branch's own gateway interface, not the server's — and it converts that broadcast into a unicast the server can actually receive across the WAN. Getting the interface backwards (helper-address on the server-facing interface instead) is the single most common reason this "doesn't work" on the first attempt; `show ip dhcp binding` on the server-side, and confirming the client actually got an address in the right subnet, is how you prove it actually worked rather than just assuming the command took effect.

"Users behind the NAT router can reach some sites but not others, and it's intermittent." This is almost always PAT running out of available port translations under load, or an inside/outside direction that's backwards on one interface — `show ip nat translations` fills up predictably, and `show ip nat statistics` shows hit/miss counts and any dropped-translation errors that a simple ping test won't reveal. If `ip nat inside`/`ip nat outside` are on the wrong interfaces entirely, translation appears to work for some traffic patterns and silently fail for others, which is exactly the confusing intermittent symptom that sends people down the wrong troubleshooting path first.

"The security team says our logs don't match up during an incident." If NTP was never configured, or one device's `ntp server` points somewhere unreachable, that device's clock drifts on its own — `show clock` looking "close enough" isn't proof, `show ntp status` (or `show ntp associations`) showing an actual synchronized, reachable source is. During an actual incident, timestamps that are minutes apart across devices make it genuinely impossible to reconstruct the order events happened in — this is boring infrastructure work until the one day it's the only thing standing between you and a usable timeline.