CCNA/Phase 6 — Network Security & Operations/Module 17
🟢 Phase 6 · Network Security & Operations 🔴 Capstone MODULE 17 · FINAL

Build a Small Network

⏱️ 4 hours
📖 6 sections
🧩 10 Questions
🏆 Capstone Module
CCNA Module 17 progress100%
🎯 What you'll learn: Device and topology selection for small networks, common applications and protocols at play, scaling considerations, verifying connectivity with ping and traceroute, host and IOS troubleshooting commands, a systematic troubleshooting methodology, and a full capstone scenario tying every CCNA module together.
Section 1

Devices in a Small Network

Designing a small network starts with the same questions every time: how many devices need to connect, how much growth is expected, and what level of redundancy is justified by the budget and the business's tolerance for downtime.

Topology
Choosing a Layout
A small office often uses a simple hierarchical design: one router to the internet, one or two switches for the LAN, with redundancy added only where the cost is justified.
Device Selection
Right-Sizing Hardware
Port density, switching speed, and PoE (Power over Ethernet) requirements drive switch selection. Router selection depends on WAN connection type and required throughput.
IP Addressing
Planning Ahead
Even a small network benefits from a documented IP addressing plan — VLANs for departments, a consistent numbering scheme, and room to grow.
Redundancy
Avoiding Single Points of Failure
Dual ISP links, redundant switches, or simply keeping spare hardware on hand — the right amount of redundancy depends entirely on how costly downtime actually is for that business.

Traffic management also matters even in small networks — QoS (Quality of Service) can prioritize latency-sensitive traffic like VoIP over less time-critical traffic like file downloads, ensuring the network behaves well under load rather than only when it's quiet.

Section 2

Applications, Protocols, and Scaling

A small network typically runs a predictable mix of applications and protocols — almost everything covered across this entire course shows up here in practice: DNS and DHCP for addressing, HTTP/HTTPS and email for daily work, and increasingly, voice and video collaboration tools.

Typical Small-Office Protocol Stack
Reference
Network Services:     DHCP (addressing), DNS (name resolution)
Productivity:          HTTP/HTTPS (web), SMTP/IMAP (email), FTP/SFTP (files)
Voice & Video:        SIP/RTP-based VoIP, video conferencing — latency-sensitive, often UDP
Management:            SSH (secure device access), SNMP (monitoring)

As a small network grows, three things should be tracked: protocol behavior (which applications dominate traffic), employee/device count (and the resulting bandwidth demand), and a network baseline — a record of normal performance over time, which is the only way to recognize when something abnormal is actually happening.

💡
You Can't Detect "Abnormal" Without Knowing "Normal"
A network baseline — typical latency, typical bandwidth utilization, typical error rates — is what makes troubleshooting fast. Without one, "is this slow?" is a guess. With one, it's a measurement against a known-good reference point.
Section 3

Verify Connectivity

Ping and traceroute return throughout this entire course because they remain the fastest way to confirm a network is behaving as expected — and the extended versions of each add useful control for deeper testing.

Extended Ping and Traceroute
Cisco IOS
! Extended ping lets you control packet count, size, source interface, and timeout
R1# ping
Protocol [ip]: ip
Target IP address: 8.8.8.8
Repeat count [5]: 100
Datagram size [100]: 1500
Source address: 192.168.1.1

! Extended traceroute offers similar control over the test
R1# traceroute
Target IP address: 8.8.8.8
Source address: 192.168.1.1

Running an extended ping with a high repeat count and large datagram size is a good way to stress-test a link and look for intermittent packet loss that a default 5-packet ping would likely miss entirely.

✨
Extended Ping Catches What Basic Ping Misses
A link with occasional packet loss might show 5/5 success on a basic ping just by chance. Running 100+ pings with extended ping gives a far more reliable picture of real-world reliability — this is a genuinely practical technique, not just an exam topic.
Section 4

Host and IOS Commands

A short reference of the commands used most often across every operating system and Cisco device, gathered in one place since real troubleshooting jumps between all of them.

Cross-Platform Troubleshooting Commands
Multi-OS
! Windows — view IP configuration
C:\> ipconfig /all

! Linux — view IP configuration
$ ip addr show

! macOS — view IP configuration
$ ifconfig

! Any OS — view the local ARP table
$ arp -a

! Cisco IOS — discover directly connected Cisco devices
R1# show cdp neighbors

! Cisco IOS — quick interface status summary
R1# show ip interface brief

! Cisco IOS — full software/hardware version info
R1# show version

show cdp neighbors (Cisco Discovery Protocol) is especially useful for mapping an unfamiliar network — it reveals directly connected Cisco devices, their platform, and which local port connects to them, all without needing prior documentation.

Section 5

Troubleshooting Methodologies

Random guessing wastes time. A structured approach — even a simple one — consistently resolves issues faster than jumping straight to assumptions.

🔧 A Practical Troubleshooting Flow
Gather information — what changed? what's the symptom?
↓
Test the OSI layers — bottom-up (Layer 1 cabling first) or top-down (application first)
↓
Isolate — narrow down which device/link/layer is actually responsible
↓
Resolve or escalate — fix it directly, or hand off with clear documentation

For deeper diagnostics, Cisco IOS offers the debug command, which shows real-time event messages (e.g. debug ip icmp), and terminal monitor, which redirects those debug/log messages to a remote SSH/Telnet session instead of only the console.

⚠️
debug Commands Can Overwhelm a Router
debug output is resource-intensive — on a busy production router, an unfiltered debug ip packet can flood the console and even impact performance. Always use the most specific debug command available, and turn it off with undebug all as soon as you have what you need.
Section 6 · Capstone

Skills Integration — Build, Verify, Troubleshoot

This final scenario pulls together router configuration (Module 10), IPv4/IPv6 addressing (Modules 11–12), ICMP (Module 13), and security hardening (Module 16) into one connected exercise.

🏗️ Capstone Topology
PC1 — 192.168.10.50/24, Gateway 192.168.10.1
↓
SW1 — Layer 2 switch, management IP 192.168.10.2/24
↓
R1 — Gi0/0: 192.168.10.1/24 (LAN) · S0/0/0: 203.0.113.5/30 (WAN)
↓
ISP → Internet (8.8.8.8 used for testing)
🏆
Final Challenge — Full Build-and-Verify Scenario
Apply everything from Modules 1–17
Scenario: You are setting up R1 and SW1 for a small office, using the topology above.

Tasks:
  1. Write the full configuration for R1: hostname, enable secret, SSH-only remote access, both interfaces with correct IPs, and no shutdown on each.
  2. Write the configuration for SW1's management SVI (VLAN 1) and its default gateway.
  3. PC1 can ping SW1 and R1's LAN interface, but cannot reach 8.8.8.8. List two possible causes and how you'd confirm each with a single command.
  4. Once everything works, name one device-hardening step from Module 16 you should still apply before calling this "production ready."
💡 Show full suggested solution
  • Task 1: hostname R1 → enable secret [pass] → username admin secret [pass] → crypto key generate rsa (2048 bits) → line vty 0 4 → transport input ssh, login local → configure Gi0/0 with 192.168.10.1 255.255.255.0 and Serial0/0/0 with 203.0.113.5 255.255.255.252, no shutdown on both
  • Task 2: interface vlan 1 → ip address 192.168.10.2 255.255.255.0 → no shutdown; then globally ip default-gateway 192.168.10.1
  • Task 3 — Cause A: The WAN interface (Serial0/0/0) might be administratively down or have the wrong IP — confirm with show ip interface brief on R1
  • Task 3 — Cause B: There might be no default route pointing toward the ISP — confirm with show ip route on R1 and check whether a route to 0.0.0.0/0 exists
  • Task 4: Apply service password-encryption if any plaintext passwords remain, and confirm Telnet is disabled (only SSH allowed) on the VTY lines — both straight from Module 16

🎉 That's the complete CCNA: Introduction to Networks course — from network basics to building and securing a real small network.

🧩 Knowledge Check
10 questions — Build a Small Network (Final Module)
1. What is the primary purpose of establishing a network baseline?
2. What does QoS (Quality of Service) primarily accomplish on a small network?
3. What does extended ping allow you to control that basic ping does not?
4. Which Cisco command reveals directly connected Cisco devices, even without prior documentation?
5. In a structured troubleshooting approach, what should typically happen first?
6. Why should debug commands be used cautiously on a production router?
7. Which command redirects debug/log output to a remote SSH session instead of only the console?
8. A PC can ping its default gateway but cannot reach the internet. Which is the most likely place to check first on the router?
9. Even after a small network is working correctly, what should still be confirmed before calling it "production ready"?
10. Which factor should most influence how much network redundancy a small business invests in?
Finished the entire CCNA course?
Mark this final module complete to celebrate finishing all 17 modules!
🏆
CCNA: Introduction to Networks — Complete!
Congratulations — you've finished all 17 modules, from network fundamentals through building and securing a real small network. You now have a solid foundation for CCNA certification and associate-level networking roles.
← BitWithBite Home
Phase 6 · CCNAModule 17 of 17 — Final!
🗒 Cheat Sheet 📝 Worksheet