Cloud, On-Premises, Protocols, and Ports

Services, Hosting Models, and Protocols

Cisco training objectives for CCST Networking include comparing cloud and on-premises applications and services and describing common network applications and protocols. These topics belong together because users usually describe an application symptom, not a network layer. A technician has to determine where the service lives, how the client reaches it, and which protocols are involved.

An on-premises service runs on infrastructure owned or directly managed by the organization, such as a server in a network closet, campus data center, or private facility. Examples may include a local file server, print server, directory service, internal web app, camera recorder, or local DHCP server. On-premises systems can provide direct control over hardware, maintenance windows, security policy, physical access, and network placement. They also require local responsibility for power, cooling, backups, patching, hardware failure, and capacity planning.

A cloud service runs on provider-managed infrastructure and is reached over a network, often the Internet. Examples include hosted email, cloud storage, SaaS business applications, cloud-hosted web apps, virtual servers, managed databases, and collaboration platforms. Cloud can reduce local hardware requirements and make services easier to reach from many locations, but it adds dependency on Internet access, DNS, identity providers, provider status, subscription settings, and cloud security configuration. Cloud does not mean there is no network; it means the service is somewhere else and the path to it matters.

Many organizations use both models. A user might sign in with a cloud identity, print to an on-premises printer, open files from a cloud drive, and use a local DNS forwarder. Troubleshooting should separate questions: Is the endpoint connected? Does it have valid IP settings? Can it reach the default gateway? Does DNS resolve the service name? Is the destination local or remote? Is only one user affected or everyone? Is a provider status page showing an outage? Did a firewall rule, VPN, certificate, or password change?

Common protocols and ports provide a practical vocabulary. DNS translates names to addresses and commonly uses UDP or TCP port 53. DHCP assigns IP configuration and uses UDP ports 67 and 68 for IPv4. HTTP uses TCP port 80 for web traffic, while HTTPS uses TCP port 443 with encryption. SSH uses TCP port 22 for secure remote command-line access. Telnet uses TCP port 23 but is insecure and should generally be avoided in favor of SSH. FTP uses TCP ports 20 and 21 in traditional operation, while SFTP commonly uses SSH on TCP port 22.

SMTP commonly uses TCP port 25 for mail transfer between servers, with submission often on 587; IMAP uses 143 and secure IMAPS uses 993; POP3 uses 110 and secure POP3S uses 995. SNMP uses UDP port 161 for network management polling and 162 for traps. NTP uses UDP port 123 for time synchronization.

Port numbers do not prove that an application is healthy, but they help identify expected traffic. If HTTPS is blocked, many cloud applications will fail. If DNS fails, users may say the Internet is down even when IP connectivity works. If DHCP fails, clients may have no usable address or may self-assign an address that cannot reach the network. If NTP fails, certificate validation and logs may become confusing because device time is wrong.

For CCST-level support, know the purpose of the major protocols and recognize their common ports. Then use that knowledge carefully: verify symptoms, check scope, compare working and nonworking clients, and document what protocol or port appears to be failing.

Study Checkpoint

• Topic: Cloud, On-Premises, Protocols, and Ports.
• Verify the official Cisco concept before memorizing a shortcut.
• Practice the technician action: observe, document, test, fix when supported, or escalate.