6.3IP services and port numbers (DHCP, DNS, NAT, SNMP, NTP)

Behind one line of an automation script, requests.get("https://api.example.com/devices"), DNS must resolve the name, NAT must translate the source address, and it must reach the target on the right port number (443 for HTTPS). If any one of these IP services or ports is missing, the symptom looks like "the app is broken," yet the causes are entirely different. This section organizes the roles of DHCP, DNS, NAT, SNMP, and NTP that apps/automation depend on, plus the must-memorize key port numbers, as knowledge for pinpointing "which service/port this failure belongs to."

6.3.1Key IP services

• DHCP (UDP 67 server / 68 client) auto-distributes IP address, subnet mask, default gateway, and DNS server to a host. If DHCP fails, the host lacks a correct IP/GW/DNS in the first place, so no downstream communication succeeds.
• DNS (UDP/TCP 53) resolves a hostname to an IP address. Since automation specifies endpoints by FQDN, if DNS cannot resolve, it fails with Name or service not known before connecting. NAT translates private IPs to global (and vice versa) so internal hosts can talk to the outside; if the return mapping (translation table) breaks, symptoms like one-way-only reachability appear.
• SNMP (UDP 161, traps 162) monitors device state by polling/notification. NTP (UDP 123) synchronizes device/server time. Time skew is fatal to automation because TLS certificate validity, API token expiry, log correlation, and Kerberos auth are time-dependent, so bad NTP often surfaces as "certificate error" or "auth failure."

6.3.2Port numbers to memorize

• Management/API: SSH 22 (TCP) / Telnet 23 (TCP, plaintext, deprecated) / HTTP 80 (TCP) / HTTPS 443 (TCP) / NETCONF 830 (TCP, over SSH). Automation's RESTCONF uses HTTPS 443 and NETCONF uses 830—commonly tested; do not mistake "NETCONF is SSH so port 22."
• Infrastructure services: DNS 53 (UDP/TCP) / DHCP 67-68 (UDP) / SNMP 161 (traps 162, UDP) / NTP 123 (UDP) / Syslog 514 (UDP). When passing automation through a firewall, whether these required ports are permitted is the crux of connectivity.

Suppose your CI/CD pipeline injects configuration nightly into Cisco devices over HTTPS (RESTCONF/443). One morning, every job suddenly starts failing with SSL: CERTIFICATE_VERIFY_FAILED: certificate is not yet valid. Reading only the error string tempts "let us replace the certificate," but this is a time trap. not yet valid means the client clock is skewed into the past relative to the certificate's validity start date. Indeed, the CI runner's date shows several days ago, and the cause is NTP (UDP/123) sync failure. The runner was recently moved to another segment, and the firewall on the path did not permit UDP/123, so the clock drifted and time-dependent TLS validation failed. The lesson: the symptom (certificate error) and the root cause (NTP/port block) live in different layers, and when isolating automation failures you must "not take the error string at face value." Even if NTP were fine, the next checks are whether DNS (53) resolves the endpoint FQDN (a Name or service not known drops before connect), whether RESTCONF's 443 passes the firewall (not confused with NETCONF's 830), and whether NAT translation maps the return traffic—closing out the dependent IP services and ports one by one. Following error string -> dependent service -> required port, you can identify many connectivity faults before touching application code.

6.3.3Section summary

• Apps/automation depend on DHCP (67/68), DNS (53), NAT, SNMP (161), NTP (123); any one missing looks like "app trouble" but the causes differ
• Memorize key ports: SSH 22 / Telnet 23 / HTTP 80 / HTTPS 443 / NETCONF 830 / DNS 53 / SNMP 161 / NTP 123. Do not confuse RESTCONF=443 vs. NETCONF=830
• Do not take error strings at face value: not yet valid/expired suspect NTP skew first, Name or service not known suspect DNS, and connection refused/timeout suspect port block/route