Routing gets a network up; IP services keep it running. NAT connects private addressing to the public internet, DHCP hands every host its identity, DNS makes names work, NTP keeps every clock honest, SNMP and syslog tell you what the network is doing, and TFTP/FTP move configs and images around when you need to change it. These are the day-2 operations protocols: unglamorous, everywhere, and worth exactly one quarter of nothing until they break, at which point they are the whole outage.
This guide is the hub for the PingLabz IP Services cluster, mapping to CCNA 200-301 domain 4 (IP Services, 10% of the exam) and to the daily reality of running networks. Every command and every line of output below was captured live from a Cisco IOS XE lab in CML (three routers, a switch, and a Linux host acting as the syslog/SNMP/TFTP/FTP server), and each section links to a full deep-dive article. Bookmark this page; the details are one click away when you need them during a change window.
What "IP Services" Actually Covers
The umbrella term takes in seven protocols that share one trait: they are infrastructure for the infrastructure. None of them forward user packets. All of them determine whether the network is operable, observable, and recoverable:
Translates private inside addresses to routable outside addresses. UDP/TCP/ICMP rewriting at the network edge.
Leases addresses and options to hosts. UDP 67/68, relayed across subnets with ip helper-address.
Name resolution. UDP/TCP 53. Routers are clients (and hand out resolver addresses via DHCP).
Clock synchronization in a stratum hierarchy. UDP 123. Everything forensic depends on it.
Telemetry polling and traps. UDP 161/162. The data source behind every monitoring dashboard.
Event logging to a collector. UDP 514. The timeline you reconstruct incidents from.
File transfer for configs and images. UDP 69 / TCP 21+20. Backup before you break it.
NAT: The Edge Translation Layer
Your LAN runs RFC 1918 private space; the internet will not route it; NAT at the edge swaps addresses so the two worlds interoperate. Cisco IOS XE gives you three modes, and reading the translation table is the skill that unlocks all of them. Here is a real PAT table with an SSH session and a ping active from one inside host:
R1#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 192.168.99.1:1024 10.0.20.1:2 192.168.99.100:2 192.168.99.100:1024
tcp 192.168.99.1:4790 10.0.20.1:28674 192.168.99.100:22 192.168.99.100:22Static NAT is one-to-one and permanent (and allows outside-initiated connections, which is how published servers work). Dynamic NAT leases one-to-one mappings from a pool. PAT (overload) rewrites source ports so an entire network shares one address, which is what nearly every real network runs. The full walkthrough with all three configured and verified, including the inside/outside local/global terminology decoded, is in NAT on Cisco IOS XE: Static, Dynamic, and PAT. (For NAT on the ASA firewall platform, where the model is object-based, see the Cisco ASA guide.)
DHCP and DNS: Identity and Names
DHCP's four-message DORA exchange (Discover, Offer, Request, Ack) starts as broadcast, which routers drop, so enterprise DHCP lives or dies on the relay agent: ip helper-address converts the broadcast to a unicast, stamps giaddr, and the central server picks the right pool from it. The lab runs server, relay, and client on three separate routers, and the client's lease tells the story:
R3#show dhcp lease | include IP|Lease|serv
Temp IP addr: 10.0.40.10 for peer on Interface: Ethernet0/3
DHCP Lease server: 10.0.12.1, state: 5 Bound
Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secsDNS is the other half of host identity: DHCP tells the host which resolver to use (the pool's dns-server option), DNS then answers name queries for the life of the session. Keeping those roles distinct is an explicit CCNA objective, and the deep dive covers both sides plus router-as-DNS-client commands: DHCP and DNS on Cisco Networks: Roles, Relay, and ip helper-address.
NTP: One Truth About Time
Certificates, log correlation, and time-based authentication all assume device clocks agree. NTP arranges time sources in strata (1 = owns a reference clock, 16 = unsynchronized) and converges over several 64-second polls, which you verify with the reach register rather than impatience:
R2#show ntp associations
address ref clock st when poll reach delay offset disp
*~1.1.1.1 127.127.1.1 3 65 64 377 3.000 -0.500 3.334Reach 377 (octal, all eight recent polls answered) plus the * sys.peer marker is the healthy state. The deep dive walks the entire convergence from stratum 16 to synced, explains ntp master vs ntp server, and covers authentication: NTP on Cisco IOS XE: Stratum, ntp master, and Verification.
SNMP: The Polling Plane
SNMP is a manager polling an agent for OIDs (leaves in the MIB tree) on UDP 161. Version 2c authenticates with a cleartext community string; version 3 brings real users, SHA authentication, and AES encryption. The difference in configuration is small and the difference in security is not:
! v2c: one line, one secret on the wire
snmp-server community pinglabz-ro RO
! v3: authPriv, the deployable level
snmp-server group NETADMIN v3 priv
snmp-server user snmpadmin NETADMIN v3 auth sha AuthPass123! priv aes 128 PrivPass123!The lab polls both from a Linux manager, walks the interface table your dashboards are built on, and shows the failure modes (wrong v2c community = silent timeout; wrong v3 key = cryptographic rejection): SNMP Explained: v2c vs v3, OIDs, MIBs, and Real Polling.
Syslog: The Event Timeline
Every %LINK-3-UPDOWN and %SYS-5-CONFIG_I your routers emit is evidence, but only if it survives off-box. Two commands ship severities 0 through 6 to a collector (logging host + logging trap informational), and six lines of rsyslog on any Linux box catch them:
2026-07-10T15:53:31.948104-07:00 192.168.99.1 219: Jul 10 22:53:31.240: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: cisco] [Source: 192.168.99.100] [localport: 22] at 22:53:31 UTC Fri Jul 10 2026Severity levels 0 (emergency) through 7 (debugging), message anatomy, destination types, and the collector-side configuration are all in Syslog on Cisco IOS XE: Severity Levels, Logging Host, and Real Messages. Pair it with NTP or the timestamps across devices will not line up when you need them most.
TFTP and FTP: Moving Configs and Images
Config backups and IOS images move over TFTP (UDP 69, no auth, lock-step slow) or FTP (TCP 21/20, credentials, TCP speed). The same 2 KB config transferred over both in the lab made the difference concrete: 572 bytes/sec over TFTP, 4703 bytes/sec over FTP, same path. The deep dive covers both directions of copy, platform filesystem naming, the merge-vs-replace restore trap, the security story told by file ownership on the server, and why SCP is the modern answer: TFTP vs FTP for Cisco IOS File Transfers and Config Backup.
How the Services Interlock
These seven protocols are usually taught as a list, but operationally they form a dependency chain, and outages love to walk it. DHCP hands a host its resolver addresses, so a wrong dns-server option in one pool becomes "the internet is down" for one subnet while every ping by address works perfectly. NTP underwrites everything forensic: if clocks drift, the syslog timeline across devices stops agreeing with itself, certificate-based logins start failing intermittently, and SNMP graphs develop mysterious discontinuities. Syslog and SNMP watch each other's blind spots (a trap can die in transit with nobody the wiser; the syslog line about the same event usually survives, and vice versa). And NAT sits underneath the lot at the edge, where an over-broad translation ACL can quietly eat your management sessions, something this very lab demonstrated when the switch's SSH replies started leaving through the PAT rewrite and never made it home.
That interdependence is why the deep dives in this cluster were all captured from one lab rather than seven isolated demos: R1 is simultaneously the NAT boundary, DHCP server, NTP master, and a syslog/SNMP source, R2 relays DHCP while syncing time from R1, and the Linux host collects logs, answers SNMP polls, and serves TFTP/FTP. When you build the same topology (the CCNA lab series shows you how), you see the services interact instead of memorizing them separately.
The Verification Commands You Should Know Cold
The CCNA Angle
Domain 4 of the 200-301 blueprint asks you to configure and verify NAT (static and pool, plus PAT) and NTP in client/server mode, and to explain the roles of DHCP, DNS, SNMP, and syslog, plus DHCP relay and the use of TFTP/FTP. In practice the exam leans hard on reading output: given a show ip nat translations line, identify the inside local address; given show ntp status, say whether the device is synchronized and at what stratum; given a syslog message, name its severity. Every capture in this cluster is exactly that output, from a live device, so treat the deep dives as reading practice with answers. The domain 4 labs then have you produce the same output with your own hands, which is the difference between recognizing and knowing.
Ports and Transports Reference
Hardening the Services Layer
Because these protocols manage the network, compromising them compromises everything, and most of them default to weak. The checklist that survives audits: SNMPv3 authPriv instead of v2c wherever tooling allows, and ACLs on whatever polls remain; NTP authentication so nobody can steer your clocks; syslog and SNMP sourced from a consistent interface (logging source-interface) so collectors can trust source addresses; TFTP confined to isolated management segments and cleaned after use; FTP replaced by SCP for anything sensitive; and DHCP snooping on the switch side to shut down rogue servers (covered in the Layer 2 switching cluster). Authentication for device logins is its own topic with its own lab captures in the 802.1X guide.
The Full IP Services Cluster, in Reading Order
Adjacent reading: the Network Fundamentals guide covers the addressing and switching concepts these services sit on, the IP Routing guide covers how packets reach these services in the first place, and the Network Automation guide covers managing all of this at scale instead of by hand.
The Lab Behind Every Capture
For the curious (and for anyone who wants to reproduce the outputs): the topology is three IOS XE routers in a triangle running OSPF, a Layer 2 switch hanging off R2, and a Debian host bridged into R1's edge. R1 serves as NAT boundary, DHCP server (ip dhcp pool), and NTP master; R2 is the DHCP relay and an NTP client; R3 plays DHCP client on a spare interface; and the Debian host runs rsyslog (UDP 514), net-snmp tools, tftpd-hpa, and vsftpd. Nothing in this cluster was captured from a simulator screenshot or pasted from documentation, and where the virtual platform behaved differently from hardware (filesystem naming, an NTP status header that lagged its own reach register), the articles say so instead of editing it out. That is the standard for everything on this site: if you build it, you will see what we saw.
Frequently Asked Questions
What ports does SNMP use?
UDP 161 for manager-to-agent polling (get, getnext, getbulk, set) and UDP 162 for agent-to-manager traps and informs. If a firewall sits between your NMS and your devices, both need opening, in opposite directions.
What is the difference between a DHCP server and a DHCP relay?
The server owns the address pools and makes leasing decisions. The relay is a router interface (ip helper-address) that converts a client's broadcast Discover into a unicast to the server, tagging it with giaddr so the server knows which subnet is asking. One central server plus a relay on every LAN is the standard enterprise design.
Why does NTP stratum matter?
Stratum counts hops from the reference clock: it is a loop-prevention and sanity mechanism, not a quality score. What matters operationally is that stratum 16 means "not synchronized," that your devices agree on a small set of sources, and that reach shows 377 before you trust the clock.
Is TFTP secure?
No. No authentication, no encryption, no access control beyond reachability of UDP 69. It persists because bootstrap environments (ROMMON, PXE) speak it and because it is effortless for quick lab transfers. Confine it to management segments and use SCP where security matters.
Which NAT type should I use?
PAT (overload) for general outbound internet access, static NAT entries for the handful of services that must be reachable from outside, and dynamic pool NAT almost never (it caps concurrent hosts at the pool size). Real edges run PAT plus statics.
Key Takeaways
IP services are the operations layer: NAT at the edge, DHCP and DNS for host identity, NTP for a shared clock, SNMP and syslog for visibility, TFTP/FTP/SCP for moving files. Each one is a small configuration with a large blast radius when neglected, and each one has a verification command whose output you should be able to read cold (show ip nat translations, show ip dhcp binding, show ntp associations, show logging, show snmp user). Every capture in this cluster came from a live lab you can rebuild yourself with the CCNA lab series, where domain 4 has hands-on labs for each of these services.