Network+ Certification Prep

The exam you are preparing for

CompTIA launched exam N10-009, the ninth version of Network+, on 20 June 2024, and in October 2026 it is still the version you can book. Every lesson in this course is built against that exam's published objectives. Before you study a single protocol, it pays to know exactly what the test looks like, because its format should shape how you prepare.

Here are the facts as CompTIA publishes them on its Network+ page, read on 27 October 2026. Check that page again before you book, because CompTIA can change any of them.

Two of those numbers deserve a second look. Ninety questions in ninety minutes sounds like a minute each, but performance-based questions take several minutes, so the multiple-choice items have to go faster than that to bank time. And 720 is not 72 percent. It is a scaled score. CompTIA says its passing scores are set by statistical analysis, and it does not publish how many correct answers produce a given score, so no percentage target is reliable.

The certification, once earned, is valid for three years, and CompTIA offers continuing-education routes to renew it. The recommended experience is advice, not a requirement: nobody checks your work history at the test centre. This course is written for people who lack that year on the job, so each lesson includes the hands-on practice that the job would have given you.

Key idea: N10-009 gives you at most 90 questions in 90 minutes, mixes multiple choice with performance-based tasks, and reports a scaled score where 720 passes, so practise for speed and for doing, not only for recall.

Five domains, unevenly weighted

CompTIA divides the exam into five domains and tells you what share of the exam each one represents. The weights are your first study-planning tool.

Troubleshooting is the heaviest domain, and it cannot be studied on its own. A question about a laptop that reaches its gateway but not the internet is a troubleshooting question, yet it tests addressing, routing and name resolution. That is why Domain 1 gets the most lessons here: subnetting, ports and the layered model are the raw material of nearly every scenario in Domain 5. You will also practise the troubleshooting habit long before Module 12, in the labs at the end of each lesson.

Key idea: the weights tell you where the marks are, and troubleshooting, the largest share, is really a test of everything else applied to a broken network.

Reading the objectives the way the exam does

The official objectives document for N10-009 (document version 6.0) lists 25 numbered objectives under the five domains. Each objective has bulleted examples beneath it, and the document ends with a long acronym list and a suggested list of lab hardware and software. Download it from CompTIA (the link is in the Sources) and keep it open while you study. This course paraphrases the objectives rather than copying them, and every lesson names the objective numbers it covers, so you can tick them off as you go.

Read the verb at the start of each objective, because it tells you how deeply the topic is tested.

• Explain and Summarize ask what something is and why it exists. Objective 1.1 on the OSI model is an "Explain" objective.
• Compare and contrast asks you to choose between neighbours: single-mode or multimode fiber, a hot site or a warm site.
• Given a scenario asks you to apply the idea to a situation: use, configure, implement or troubleshoot. Ten of the 25 objectives start this way, including IPv4 addressing (1.7), switching (2.2), network services (3.4) and all of the troubleshooting objectives from 5.2 to 5.5.

Two warnings sit in the document itself. First, CompTIA says the bulleted examples are not exhaustive lists, so a technology that fits an objective can appear even if it is not named. Second, it states that people who prepare with unauthorized materials, the leaked question collections known as brain dumps, will have their certifications revoked and can be barred from future testing. Every practice question in this course is original and written from the objectives, not from anyone's memory of the real exam.

Key idea: treat the objectives document as your syllabus, read each objective's verb as a depth gauge, and expect anything that reasonably belongs under an objective, named or not.

Performance-based questions and the clock

CompTIA lists Network+ among its exams with simulation performance-based questions, or PBQs. It describes these as approximations of a tool or environment: they have restricted functionality, but they are built so that more than one path can reach a correct answer, and the scoring allows for those different approaches. Three details from CompTIA's own explanation matter for strategy. You can skip a simulation PBQ and come back to it later. Simulation PBQs have a reset button. And partial credit may be given.

Those three facts suggest a plan. When a PBQ appears early in the exam, read it, flag it, and move on to the multiple-choice items, then return to the PBQs with whatever time you have banked. A partly completed PBQ can still earn marks, so never leave one blank. The best preparation for PBQs is the one this course builds into every lesson: typing real commands, reading real output and making configuration decisions yourself, so the simulated screen feels familiar.

You can sit the exam at a Pearson VUE test centre or online through Pearson VUE's OnVUE service. Online, your webcam and microphone monitor you throughout, you may not have paper, and you write on a built-in digital whiteboard instead. That last rule matters for subnetting: practise writing your subnetting chart quickly, from memory, because you will rebuild it on a screen.

If the first attempt goes badly, CompTIA's retake policy imposes no waiting period between the first and second attempts, but requires at least 14 days before a third or later attempt, and every attempt is paid for in full.

Which version you will sit

CompTIA has posted a draft of the next version, N10-010, on its page of exam objectives under development. The draft (objectives document version 1.2) has no announced launch date, and CompTIA notes that draft objectives can change. When CompTIA sets a launch date for N10-010, it will also announce when N10-009 retires. This course teaches N10-009, the exam you can actually sit today. If you are reading this after N10-010 has launched, check the Network+ page, decide which version you will take, and compare its objectives with the ones listed in each lesson here.

One plain statement belongs in this lesson. CompTIA and Network+ are trademarks of CompTIA. CompTIA does not endorse or sponsor this course, and the course has no connection to CompTIA beyond following its published objectives. No course can promise a pass, and this one does not; what it can do is make sure nothing on the objectives list is new to you on exam day.

How to study so it lasts

In 2013 John Dunlosky and four colleagues reviewed the research on ten common study techniques. Two earned their highest rating, "high utility": practice testing and distributed practice, which means spreading study across many sessions instead of cramming. Five techniques were rated low utility, including rereading, highlighting and summarizing. Those are exactly the habits most learners rely on.

For Network+ the translation is direct. Use the ten questions at the end of each lesson as a test, not as a check after rereading. Explain each answer aloud, including why the wrong options are wrong, because the distractors are built from real misconceptions. Come back to a lesson's quiz a few days later and again a week after that. For material that must become automatic, like the port table in Lesson 8 and subnetting in Lessons 10 and 11, do a short daily drill rather than one long session.

Plan on six to eight hours a week. Keep a lab notebook, paper or digital, where you record each command you run, what it printed and what you think it means. That notebook becomes your revision guide, and writing the meaning down is itself a form of retrieval.

Key idea: test yourself and space your sessions; rereading and highlighting feel productive but, in the research, do little for what you can recall weeks later.

Building a lab that costs nothing

You do not need to buy equipment for this course. Everything below is free and legal to use on your own computer.

• Your operating system's command line. Windows has Command Prompt and PowerShell; macOS and Linux have a terminal. You will use ping, tracert or traceroute, ipconfig or ip, nslookup or dig, netstat or ss, and arp, which are the command-line tools objective 5.5 names.
• Wireshark. A free, open-source packet analyzer released under the GNU General Public License. It shows captured traffic in detail; it does not send or change traffic on the network. On Windows its installer includes Npcap, the driver that lets Wireshark capture live traffic. Without Npcap you can still open saved capture files.
• Wireshark's sample captures. The Wireshark wiki keeps a library of capture files covering protocols you cannot easily generate at home, such as OSPF, spanning tree and VLAN tagging. Later lessons point you to specific files.
• Cisco Packet Tracer. A free network simulator in which you can cable switches and routers and type configuration commands. It requires a Cisco Networking Academy account: you enrol in the free course Getting Started with Cisco Packet Tracer, which includes the download. The sign-up form asks for your birth month and year, and the Academy's terms say the program is not intended for children as local law defines them (for example, people under 13 in the United States) unless a Cisco-authorized academy, such as a school, creates the account with a parent's or guardian's consent.

One rule governs every lab in this course. Capture traffic and run tests only on networks and devices you own, or where you have written permission from the owner. Even at home, other people's traffic is theirs: capture your own device's conversations. Never point a scanner at a network that is not yours. Lesson 35 explains why tools like Nmap need that permission, and the Sources list where the law on this is discussed.

Your first procedure: the ping ladder

Ping sends Internet Control Message Protocol (ICMP) echo request messages and reports the echo replies that come back, with round-trip times. On Windows it sends four requests by default. The ping ladder uses it to test one layer of your connection at a time, from the inside out. Do it now on your own computer.

1. Read your configuration. On Windows run ipconfig /all; on Linux run ip addr and then ip route; on macOS run ifconfig. Write down your IPv4 address, subnet mask, default gateway and DNS servers.
2. Ping the loopback address: ping 127.0.0.1. Addresses beginning with 127 are reserved for a host talking to itself, and the standard for Internet hosts says they must never appear outside the host. Success shows your computer's own IP software works. It proves nothing about the cable or Wi-Fi.
3. Ping your own address, the one from step 1. Success shows the address is configured on an interface.
4. Ping your default gateway. This is the first test that crosses the network: a reply shows your link to the local router works.
5. Ping a site by name: ping www.wikipedia.org. Ping first resolves the name to an address, then sends echo requests across the internet. Success tests routing and name resolution together.

Now change one input and watch the result flip. Run ping www.wikipedia.invalid. The name ends in .invalid, a top-level domain reserved so that it can never exist. Ping fails before sending a single echo request, because it never learns an address to send to. That is the shape of a name-resolution failure, and Microsoft's documentation for ping gives the rule you should remember: if pinging an IP address works but pinging the name does not, suspect name resolution.

Read the ladder as a diagnosis. If step 2 fails, the problem is inside the computer. If step 4 fails while step 3 succeeds, look at the local link: the cable, the Wi-Fi association, the address settings. If pinging an internet address by number works but step 5 fails, look at DNS. Each rung narrows the search. Lesson 31 turns that narrowing into CompTIA's full troubleshooting method.

Key idea: test from the inside out, loopback then own address then gateway then a remote name, and the first rung that fails tells you which part of the path to examine.

Watching the ladder in Wireshark

Install Wireshark, start a capture on the interface you use (Wi-Fi or Ethernet), and type icmp in the display filter bar. Run the ladder again. For the gateway and the remote site you will see pairs of packets: an echo request, which ICMP numbers as type 8, and an echo reply, type 0. Click one and expand the ICMP section in the middle pane to see the type, a sequence number that matches each reply to its request, and the copy of your data that the reply sends back.

Something is missing. The pings to 127.0.0.1 and to your own address do not appear on the Wi-Fi or Ethernet capture at all. They never left the computer, so the adapter never saw them. That one observation is a lesson in itself: a successful ping to yourself says nothing about the network outside you.

Keep this capture. In the next lesson you will open one of these packets and find the layers of the OSI model stacked inside it, one header wrapped around the next.

Common misconceptions

• "720 means I need 72 percent." The score is scaled from 100 to 900, CompTIA sets passing scores by statistical analysis, and it does not publish the conversion. Aim to know the material, not to hit a guessed percentage.
• "If a topic is not listed in the objectives, it will not be tested." The objectives document says its bulleted examples are not exhaustive. Anything that clearly belongs under an objective is fair game.
• "A failed ping means the host is down." Ping tests one protocol, ICMP. Many hosts and firewalls block echo requests, which is why Nmap's documentation calls ICMP-only discovery unreliable across the internet. A web server can answer browsers all day and ignore every ping.
• "Rereading my notes is the safest way to prepare." Rereading was rated low utility in Dunlosky and colleagues' review. Practice testing and spaced sessions were rated high.

What to carry forward

• N10-009: at most 90 questions, multiple choice plus performance-based, 90 minutes, a scaled passing score of 720 on 100 to 900. A draft N10-010 exists with no launch date; this course teaches N10-009.
• Domain weights: Concepts 23%, Implementation 20%, Operations 19%, Security 14%, Troubleshooting 24%. Troubleshooting applies all the others.
• Objective verbs set the depth. "Given a scenario" means you must apply the idea, and ten of the 25 objectives say it.
• Simulation PBQs can be skipped and revisited, have a reset button, and may earn partial credit.
• Study by testing yourself and spacing sessions. Never use brain dumps.
• Your lab: the command line, Wireshark and its sample captures, and Packet Tracer through a Cisco Networking Academy account. Test only what you own or have permission to test.
• The ping ladder tests loopback, own address, gateway and a remote name in order; the first failure locates the problem.

Sources

1. CompTIA. (n.d.). Network+ (V9) certification: Exam details. Retrieved 27 October 2026. comptia.org
2. CompTIA. (2023). CompTIA Network+ N10-009 certification exam objectives (Document version 6.0). CompTIA (PDF)
3. CompTIA. (n.d.). CompTIA exam objectives under development. Retrieved 27 October 2026. comptia.org
4. CompTIA. (n.d.). Performance-based questions explained. comptia.org
5. CompTIA. (n.d.). Candidate testing policies; CompTIA certification retake policy; Online-proctored exam guidelines. comptia.org
6. Dunlosky, J., Rawson, K. A., Marsh, E. J., Nathan, M. J., and Willingham, D. T. (2013). Improving students' learning with effective learning techniques. Psychological Science in the Public Interest, 14(1), 4-58. doi.org
7. Microsoft. (2023). ping [Windows commands reference]. Microsoft Learn. learn.microsoft.com
8. Postel, J. (1981). Internet Control Message Protocol (RFC 792). RFC Editor. rfc-editor.org
9. Braden, R. (Ed.). (1989). Requirements for Internet hosts: Communication layers (RFC 1122), section 3.2.1.3. RFC Editor. rfc-editor.org
10. Eastlake, D., and Panitz, A. (1999). Reserved top level DNS names (RFC 2606). RFC Editor. rfc-editor.org
11. Wireshark Foundation. (n.d.). Wireshark User's Guide, chapters 1 and 2. wireshark.org
12. Cisco Networking Academy. (n.d.). Cisco Packet Tracer and Terms and conditions. netacad.com; terms (PDF)
13. Lyon, G. (n.d.). Host discovery, in Nmap reference guide. nmap.org

A seven-layer agreement

On 1 July 1994 the International Telecommunication Union approved Recommendation X.200, a 47-page document that ISO publishes word for word as ISO/IEC 7498-1. It describes how two computers can communicate by dividing the job into seven layers, each with its own duties. The protocols that ISO designed to fill those layers never took over the world; the internet runs on the TCP/IP suite instead. Yet the seven-layer model outlived its own protocols. It is still the vocabulary engineers use to say where a problem lives, and objective 1.1 of the Network+ exam is built on it.

Here is the model, from the top down, with the job each layer does.

A mnemonic helps you hold the order from layer 1 upward: Please Do Not Throw Sausage Pizza Away (Physical, Data link, Network, Transport, Session, Presentation, Application). Learn it, then stop needing it, because the exam rarely asks for the order alone. It asks which layer a symptom, a device or a protocol belongs to.

The point: the seven layers divide one hard job, getting data from a program on one machine to a program on another, into separate duties that can be designed, tested and blamed separately.

Following one request down the stack

Abstract layers make more sense when you watch them do something. Follow a single request: you type https://www.wikipedia.org into your browser and press Enter. Here is what each layer does on your computer before anything leaves it.

Layers 7 to 5. The browser forms an HTTP request: GET this page, from this host. Because the address begins with https, that request will be encrypted by TLS before it is sent. Exam questions usually place encryption, compression and character encoding at the presentation layer, and TLS is commonly taught as a layer 6 protocol, although in practice TLS runs inside the application's own software over TCP. The session layer's duties, opening and closing the dialogue, are handled here too: the TLS handshake that sets up the encrypted conversation is the closest thing in this request to a session.

Layer 4. TCP takes the encrypted data and adds its header. The most important fields are two port numbers: destination port 443, which identifies the HTTPS service on the server, and a source port your computer picked at random from its pool of temporary ports, which identifies your browser's conversation. TCP also numbers the bytes so that the other end can put them in order and ask for anything lost.

Layer 3. IP adds its header: your computer's IP address as the source, the server's address as the destination, and a time-to-live counter that each router decrements. These addresses are logical. They say where the data is ultimately going, not which wire to use next.

Layer 2. The server is not on your local network, so your computer hands the packet to its default gateway. Ethernet or Wi-Fi wraps the packet in a frame addressed to the gateway's MAC address, with your own MAC as the source. The frame also gets a trailer, the frame check sequence, a checksum the receiver uses to detect damage.

Layer 1. The network adapter turns the frame's bits into signals: voltage changes on copper, pulses of light in fiber, or radio waves for Wi-Fi.

Each step wrapped the previous one inside a new header. That wrapping is called encapsulation, and the reverse, unwrapping at the receiver, is decapsulation. The internet's host requirements standard, RFC 1122, gives the units their names: a TCP segment, an IP datagram, a packet passed down to the link layer, and a frame on the link. Network+ material usually simplifies this to a ladder you should know cold.

The point: sending is encapsulation, each layer wrapping the one above in its own header; learn the matching names, segment, packet, frame and bits, because exam questions use them as clues.

What changes at each hop, and what does not

Your frame reaches the gateway router. The router reads the frame, checks the frame check sequence, and then throws the frame away. It keeps the IP packet inside, looks at the destination IP address, chooses the next router, lowers the time-to-live by one, and builds a brand-new frame addressed to that next router's MAC address. The same thing happens at every router on the way to Wikipedia.

That gives you one of the most tested ideas in the whole model. Layer 2 addresses are local: they are rewritten at every router hop. Layer 3 addresses are end to end: the source and destination IP addresses stay the same for the whole journey. (Network address translation, in Lesson 18, is the deliberate exception, rewriting IP addresses at the edge of a network.) If you capture the same request on both sides of a router, the MAC addresses differ and the IP addresses match.

At the server, decapsulation runs the other way. The adapter turns signals into bits, Ethernet checks the frame and hands up the packet, IP sees its own address and hands the segment to TCP, TCP sees destination port 443 and hands the data to the web server program, TLS decrypts it, and the server reads your GET request. The reply makes the same journey in reverse.

The point: MAC addresses change at every router while IP addresses persist from end to end, which is exactly what a router does: it strips one frame, keeps the packet, and builds the next frame.

Where devices and protocols sit

Network+ questions often name a device and ask for its layer. The rule is to ask what information the device reads in order to make its decision.

A hub repeats every signal out of every port without looking at addresses, which is why it is a layer 1 device even though it looks like a switch. A switch learns which MAC address lives on which port and forwards frames only where they need to go, which is layer 2 work. Lesson 4 returns to these devices in detail.

The model the internet actually uses

The internet's own standards describe a simpler stack. RFC 1122, written in 1989 as the requirements every internet host must meet, names four layers: link, internet, transport and application. Its application layer covers what OSI splits into application and presentation, and session duties are left to applications too.

Some protocols refuse to sit neatly anywhere. ARP, which you meet in the next lesson, uses layer 2 frames to find layer 3 neighbours, so textbooks place it at 2, at 3, or between them. The IETF has even published a warning about leaning on layers too hard: RFC 3439, written in 2002 by Randy Bush and David Meyer, argues that strict layering can hide information lower layers need and pushes designers into separate optimizations that work against each other. Treat the model as a map, not as the territory.

The point: the internet runs on a four-layer TCP/IP stack, and the seven-layer OSI model is the reference vocabulary laid over it; when a protocol straddles layers, the map is simplifying, not wrong.

Using the layers to troubleshoot

The layers are a search plan. CompTIA's troubleshooting method, which Lesson 31 covers in full, names two layer-based approaches. Bottom-to-top starts at the physical layer: is the cable connected, is there a link light, does the adapter have an address, can it reach the gateway? You used it in Lesson 1 when you climbed the ping ladder. Top-to-bottom starts at the application: one program fails while others work, so begin with that program's settings and protocol and work down only if needed.

Choose by symptom. When nothing works, start at the bottom, because a missing link light explains every failure above it. When a single application fails while the browser, email and chat all work, start at the top, because the lower layers have just proved themselves. A third approach, divide and conquer, starts in the middle, often with a ping at layer 3, and moves up or down depending on the answer.

The point: pick the starting layer from the symptom: everything broken suggests bottom-up, one application broken suggests top-down, and a quick layer 3 test tells you which half to search.

Common misconceptions

• "The internet is built on the OSI model." The internet runs on TCP/IP, whose host requirements standard defines four layers. OSI is the reference vocabulary engineers use to describe it.
• "Addresses stay the same all the way to the server." Only the IP addresses do (barring NAT). Every router builds a new frame, so source and destination MAC addresses change at every hop.
• "A hub and a switch are the same device at different prices." A hub repeats signals to every port at layer 1; a switch reads MAC addresses and forwards each frame only toward its destination at layer 2.
• "Every protocol belongs to exactly one layer." ARP and TLS straddle layers, and the IETF's own RFC 3439 warns against treating layering as absolute. On the exam, give the conventional answer; in practice, expect overlap.

Recap

• The seven layers, top down: Application, Presentation, Session, Transport, Network, Data link, Physical (ITU-T X.200, identical to ISO/IEC 7498-1).
• Sending is encapsulation: data, then segment (ports), packet (IP addresses), frame (MAC addresses, plus a trailer), bits.
• Routers strip and rebuild frames: MAC addresses change hop by hop, IP addresses persist.
• Devices sit at the layer whose information they read: hub 1, switch 2, router 3, simple firewall 3 and 4, application-aware devices up to 7.
• TCP/IP's four layers (link, internet, transport, application) are what the internet actually uses.
• Troubleshoot bottom-up when everything fails, top-down when one application fails, or divide and conquer from a ping.

Sources

1. International Telecommunication Union. (1994). Recommendation X.200: Information technology, Open Systems Interconnection, Basic Reference Model: The basic model (identical to ISO/IEC 7498-1:1994). ITU-T. itu.int
2. Braden, R. (Ed.). (1989). Requirements for Internet hosts: Communication layers (RFC 1122), sections 1.1.3 and 1.3.3. RFC Editor. rfc-editor.org
3. Bush, R., and Meyer, D. (2002). Some Internet architectural guidelines and philosophy (RFC 3439), section 3. RFC Editor. rfc-editor.org
4. Wireshark Foundation. (n.d.). The packet details pane, in Wireshark User's Guide. wireshark.org
5. Wireshark Foundation. (n.d.). Sample captures. Wireshark Wiki. wiki.wireshark.org
6. CompTIA. (2023). CompTIA Network+ N10-009 certification exam objectives (Document version 6.0), objectives 1.1 and 5.1. CompTIA (PDF)

A laptop that can print but cannot browse

A laptop with the address 192.168.1.50 and the subnet mask 255.255.255.0 prints without any trouble to a printer at 192.168.1.20. Yet it cannot load a single website, and neither can it reach the company's file server in the next building. The cable is fine; the printer proves it. Running ipconfig shows one more line: Default Gateway 192.168.1.254. The office router's address is 192.168.1.1.

You may already suspect the answer. The point of this lesson is to understand exactly why one wrong number breaks some conversations and leaves others untouched. To get there you need four ideas from layer 2 and the boundary with layer 3: the frame, the MAC address, the switch's learning table, and ARP. They also carry objective 1.4's traffic types and the arp command from objective 5.5.

The frame: an envelope for one link

Everything a computer sends on Ethernet or Wi-Fi travels inside a frame, addressed only as far as the next device on the same link. The Ethernet II frame, the format your traffic uses, looks like this.

Two details explain things you will see later. The 1,500-byte payload ceiling is the standard Ethernet maximum transmission unit, which Lesson 16 revisits with jumbo frames. And Wireshark normally shows neither the preamble nor the frame check sequence, because most adapters strip both before the capture software sees the frame. A frame that fails its check is simply discarded, and counted as an error on the interface, a counter you will read in Lesson 32.

Why this matters: a frame only ever travels one link, so its addresses answer the question "which adapter next?", not "which computer finally?"

MAC addresses: 48 bits with two flag bits

A MAC address is 48 bits long, written as six pairs of hexadecimal digits such as 00-1A-2B-3C-4D-5E (Windows style) or 00:1a:2b:3c:4d:5e (Linux style). For a globally unique address, the first three bytes are an Organizationally Unique Identifier, a 24-bit block the IEEE Registration Authority assigns to a manufacturer, and the manufacturer numbers the last three bytes itself. Look up an OUI and you can often tell who made a device, which is handy when you find an unknown device on a network.

Two bits in the first byte change the address's meaning. The lowest bit is the individual/group bit: 0 means the address names one adapter, 1 means it names a group. The next bit up is the universal/local bit: 0 means the address came from a manufacturer's assigned block, 1 means it was set locally. Some examples make this concrete.

• ff:ff:ff:ff:ff:ff, all ones, is the broadcast address: every adapter on the segment accepts it.
• 01:00:5e: followed by three bytes is an IPv4 multicast MAC address. The low 23 bits of the IP group address are copied into it, so several IP groups can share one MAC address.
• 33:33: followed by four bytes is an IPv6 multicast MAC address.
• An address whose first byte is 3a, 9e or da has the local bit set. Modern phones and laptops use such addresses on purpose: Apple's devices, for example, identify themselves to each Wi-Fi network with a different private address, so that networks cannot track one device from place to place.

That last point overturns an old belief. A MAC address is not a permanent serial number. It can be configured, randomized or spoofed, which is why Lesson 30 will not let MAC filtering pose as real security.

Why this matters: the first byte of a MAC address tells you whether a frame is for one adapter or a group, and whether the address came from a manufacturer or was set locally, often for privacy.

How a switch learns where everyone is

A switch starts with an empty MAC address table and fills it by watching traffic. Every time a frame arrives, the switch records the frame's source MAC address against the port it came in on, and stamps the entry with the time. To forward a frame, it looks up the destination MAC address. If the address is in the table, the frame goes out of that one port. If it is not, the switch floods the frame out of every port in the VLAN except the one it arrived on, because the destination must be somewhere, and its reply will teach the switch where. Broadcasts are always flooded. Entries that go quiet are removed when they age out, so a device that moves to a new port is soon relearned.

Walk through it on a four-port switch with an empty table. PC A is on port 1, PC B on port 2, PC C on port 3.

On a Cisco switch the table is displayed with show mac address-table; CompTIA's objectives and older software write it as show mac-address-table. You will use it in Lesson 33 to find which port a misbehaving device is plugged into.

Why this matters: a switch learns from source addresses and forwards on destination addresses, flooding only what it does not yet know, and that simple rule explains both its efficiency and its weaknesses.

ARP: from an IP address to a MAC address

A computer knows the IP address it wants to reach, but a frame needs a MAC address. The Address Resolution Protocol bridges the gap. David Plummer described it in RFC 826 in November 1982, and it still works the way he wrote it.

1. The sender broadcasts an ARP request to ff:ff:ff:ff:ff:ff. In effect it asks: whoever has IP address 192.168.1.20, tell 192.168.1.50 your MAC address. The ARP message carries operation code 1, request.
2. Every device on the segment receives the request. Only the owner of 192.168.1.20 answers, with operation code 2, reply, sent directly to the requester rather than broadcast.
3. The sender stores the answer in its ARP cache, so the next frames need no new request. RFC 826 also has the receiver of a request record the requester's mapping, which saves a second broadcast later.

That trusting design, in which devices accept mappings that arrive unchecked, is what ARP poisoning exploits; Lesson 29 shows how. To see your own cache, run arp -a on Windows. On Linux the modern command is ip neigh, which also shows each entry's state: REACHABLE for a confirmed neighbour, STALE for one that needs rechecking, INCOMPLETE while a request is outstanding, and FAILED when the maximum number of probes got no answer.

Why this matters: ARP is the step that turns "send to this IP address" into "put this MAC address on the frame", and it works only for devices on the same segment.

The local-or-remote decision

Before a host sends anything, it must decide whether the destination is on its own network. RFC 1122, the internet's host requirements, describes the test. The host applies its subnet mask to its own address and to the destination address. If the results match, the destination is on a connected network, and the host sends to it directly. If they differ, the host sends to a gateway, its default gateway, and lets the router carry the packet onward.

With the mask 255.255.255.0, the test is simple: compare the first three numbers. Lesson 10 shows the binary version for masks that do not fall on those boundaries.

(The 203.0.113.0/24 block is one of three that RFC 5737 reserves for documentation, so it can never belong to a real server.)

Now the opening problem solves itself. For the printer, the laptop ARPs for 192.168.1.20, gets a reply, and prints. For every remote destination, it ARPs for its configured gateway, 192.168.1.254. No device owns that address, so no reply ever comes. Without a MAC address, the laptop cannot build a single frame toward the internet. On Linux, ip neigh would show the .254 entry as FAILED; on Windows, arp -a simply has no entry for it. Correct the default gateway to 192.168.1.1 and everything remote starts working.

Notice that ARP never asks for the remote server's MAC address. A host only ever ARPs for something on its own segment: the destination itself when it is local, the gateway when it is not.

Why this matters: the subnet mask decides local or remote, local traffic goes straight to the destination's MAC, and remote traffic goes to the gateway's MAC, so a wrong gateway breaks only remote traffic.

Four ways to address a message

Objective 1.4 asks you to tell apart four traffic types. Each is defined by how many receivers one transmission is meant to reach.

RFC 1112 defines the IPv4 multicast range by its first four bits, 1110, which gives 224.0.0.0 to 239.255.255.255; the address 224.0.0.1 means all multicast-capable hosts on the local network. Anycast is how the DNS root servers can sit in hundreds of cities behind a handful of addresses: RFC 4786 describes it as making one service address available from many separate locations, with ordinary routing delivering each query to one of them. IPv6, in Lesson 12, drops broadcast entirely and leans on multicast and anycast instead.

The set of devices that receive a broadcast is a broadcast domain. Switches flood broadcasts to every port in a VLAN, so one switch or a stack of them is one broadcast domain. Routers do not forward broadcasts, so each router interface marks a boundary. VLANs, in Lesson 15, split one switch into several broadcast domains.

Why this matters: unicast reaches one, broadcast reaches all on the segment, multicast reaches those who joined, and anycast reaches the nearest; recognizing each from its address is a quick exam point and a real diagnostic skill.

Common misconceptions

• "ARP finds the MAC address of the remote web server." ARP works only on the local segment. For a remote destination, the host resolves its default gateway's MAC address and the router handles the rest.
• "If local devices work, the IP settings must be right." A wrong default gateway leaves local traffic untouched and breaks only remote traffic, exactly as in this lesson's laptop.
• "A MAC address is a permanent, unique serial number." It can be changed, randomized for privacy, or spoofed. The local bit in the first byte often gives a randomized address away.
• "A switch sends broadcasts only to the router." A switch floods broadcasts out of every port in the VLAN. Only a router, or a VLAN boundary, stops them.

What you now know

• A frame carries a packet across one link: destination MAC, source MAC, EtherType, a payload of up to 1,500 bytes, and a frame check sequence.
• A MAC address is 48 bits; its first byte holds the individual/group and universal/local bits, and ff:ff:ff:ff:ff:ff is broadcast.
• A switch learns source MAC addresses per port, forwards known destinations, floods unknown ones and broadcasts, and ages out silent entries.
• ARP broadcasts a request and receives a unicast reply; arp -a and ip neigh show the cache.
• The mask decides local or remote. Local traffic goes to the destination's MAC; remote traffic goes to the default gateway's MAC.
• Unicast, broadcast, multicast (224.0.0.0 to 239.255.255.255) and anycast differ in how many receivers one transmission reaches; routers bound broadcast domains.

Sources

1. Plummer, D. C. (1982). An Ethernet Address Resolution Protocol (RFC 826). RFC Editor. rfc-editor.org
2. Braden, R. (Ed.). (1989). Requirements for Internet hosts: Communication layers (RFC 1122), section 3.3.1.1. RFC Editor. rfc-editor.org
3. Eastlake, D., Abley, J., and Li, Y. (2024). IANA considerations and IETF protocol and documentation usage for IEEE 802 parameters (RFC 9542). RFC Editor. rfc-editor.org
4. Deering, S. (1989). Host extensions for IP multicasting (RFC 1112). RFC Editor. rfc-editor.org
5. Abley, J., and Lindqvist, K. (2006). Operation of anycast services (RFC 4786). RFC Editor. rfc-editor.org
6. Juniper Networks. (n.d.). MAC table aging [Junos OS documentation]. juniper.net
7. Microsoft. (2025). arp [Windows commands reference]. Microsoft Learn. learn.microsoft.com
8. Linux man-pages project. (n.d.). ip-neighbour(8). man7.org
9. Wireshark Foundation. (n.d.). Ethernet. Wireshark Wiki. wiki.wireshark.org
10. Apple. (n.d.). Use private Wi-Fi addresses on Apple devices. Apple Support. support.apple.com
11. Arkko, J., Cotton, M., and Vegoda, L. (2010). IPv4 address blocks reserved for documentation (RFC 5737). RFC Editor. rfc-editor.org

Boxes are named for what they read

NIST's firewall guide, Special Publication 800-41 Revision 1, published in September 2009, begins its catalogue with the plain packet filter and then observes that few firewalls sold today do only stateless packet filtering. That remark is a useful warning for this whole lesson. Product names blur: a home "router" is also a switch, an access point, a firewall and a DHCP server in one plastic case. The exam, though, asks about functions, and functions are easy to tell apart if you ask two questions of any device. What does it examine in the traffic? And what does it do with what it finds?

Objective 1.2 lists the devices, applications and functions you must compare. The table below is the lesson in one view; the sections after it explain the rows that cause the most confusion.

What matters here: identify any appliance by what it reads (MAC address, IP address, port, state, content) and what it does (forward, filter, alert, block, distribute, store), and the exam's device questions become lookups.

Three generations of firewall

NIST describes firewall technology in layers of capability, and the exam's distinctions follow it.

• Packet filtering (stateless). The basic feature: each packet is checked on its own against a ruleset of addresses, protocols and ports. NIST notes these filters do not track the state of a flow, so they cannot tie a reply to the request that caused it, and they are not concerned with packet content.
• Stateful inspection. The firewall keeps a state table of connections, typically recording source and destination addresses, ports and the connection's state. A reply is allowed because it matches a connection an inside host opened, and packets that deviate from the expected state are blocked. This is why a home router lets web pages come in without an inbound rule for every website.
• Application-aware filtering. Application firewalls and application-proxy gateways examine the content of protocols such as HTTP, SMTP or SQL, and can spot suspicious command sequences or malformed requests. Products marketed as next-generation firewalls combine this with stateful filtering, intrusion prevention and identity awareness.

Firewalls come as physical boxes, as virtual appliances running in a hypervisor, and as software on each host. Placement and rule writing return in Lesson 30.

Seeing versus stopping: IDS and IPS

NIST's guide to intrusion detection and prevention, Special Publication 800-94 from February 2007, draws the line in one sentence. An IDS automates the detection of possible incidents; an IPS has all the capabilities of an IDS and can also attempt to stop them. The practical difference is placement. A passive sensor watches a copy of the traffic, fed from a switch's mirror port or a network tap, so nothing passes through it and it cannot block. An inline sensor sits in the traffic path, like a firewall, so it can drop malicious packets, and it can also delay or drop legitimate ones if it fails or misjudges.

Both use the same detection methods. Signature-based detection compares traffic with patterns of known threats; NIST calls it very effective against known threats and largely ineffective against new ones or variants. Anomaly-based detection builds a profile of normal activity and flags significant deviations. No method is perfectly accurate: a false positive flags benign activity as malicious, a false negative misses real malicious activity, and NIST notes that reducing one usually increases the other. On an IPS a false positive is not just noise, it is a blocked legitimate transaction.

What matters here: an IDS sees a copy and alerts, an IPS sits inline and can block; choose by whether the organization can tolerate a missed attack more than a wrongly blocked transaction.

Load balancers and proxies: standing in front of servers and clients

A load balancer presents one address to clients, often called a virtual IP, and spreads incoming requests across a pool of real servers. The open-source NGINX documentation shows the common methods. Round robin, the default, hands requests to each server in turn. Least connections sends each new request to the server with the fewest active connections. IP hash sends a given client to the same server each time, which keeps a user's session on one machine. Load balancers also watch server health. NGINX, for example, marks a server as failed after a configurable number of unsuccessful attempts, stops sending it requests for a while, then probes it again. One server can fail without users noticing, which makes the load balancer a high-availability tool as well as a performance tool.

A proxy makes requests on someone else's behalf. HTTP's own standard, RFC 9110, draws the distinction the exam uses. A proxy is chosen by the client, usually through its configuration. A forward proxy at the edge of a company network receives employees' web requests and fetches pages for them. Along the way it can filter categories, log usage and cache popular content. A gateway, which the RFC notes is also called a reverse proxy, acts as the origin server for the outside world and passes requests inward to one or more real servers. Many load balancers are reverse proxies with health checks.

Storage on the network: NAS and SAN

The Storage Networking Industry Association's dictionary separates the two by how storage is accessed. Network-attached storage serves files: clients see shared folders over ordinary file protocols such as SMB, which you will meet on port 445, and NFS. A storage area network serves blocks: a server sees a SAN volume as if it were a local disk and puts its own file system on it. SANs traditionally run on a dedicated network, often Fibre Channel, though the term does not require it; iSCSI carries the same block commands over an ordinary IP network.

Wireless access points and controllers

An access point bridges wireless clients onto the wired network at layer 2. A small office can configure each AP separately. A campus with hundreds of APs instead uses a wireless LAN controller that manages lightweight APs centrally. The IETF's CAPWAP protocol, RFC 5415 from 2009, standardizes that arrangement and lists among its goals centralizing authentication and policy enforcement for the wireless network. Lesson 19 compares autonomous and lightweight APs in detail.

What matters here: load balancers and reverse proxies stand in front of servers, forward proxies stand in front of clients, NAS serves files while SAN serves blocks, and controllers manage many access points as one system.

Applications and functions: CDN, VPN, QoS and TTL

Four items in objective 1.2 are not boxes at all but services or behaviours.

• Content delivery network. RFC 6707 describes a CDN as network infrastructure whose elements cooperate at layers 4 to 7 to deliver content more effectively, chiefly by caching it closer to the edge of the network. A user in Lisbon streaming a film fetches it from a nearby cache rather than from the origin server on another continent.
• Virtual private network. An encrypted tunnel that carries private traffic across a public network, either between two sites or from one remote user to a site. Lesson 7 covers the IPsec protocols beneath many VPNs, and Lesson 27 the designs.
• Quality of service. When a link is congested, QoS decides which traffic waits. Packets are marked in the six-bit Differentiated Services Code Point that RFC 2474 placed in the old IPv4 type-of-service byte, and routers queue each class differently. RFC 4594 recommends the Expedited Forwarding class, DSCP 46 (binary 101110), for telephony, because voice cannot tolerate delay or jitter while a file transfer can.
• Time to live. In IP, TTL is an eight-bit counter that RFC 791 requires every router to decrease by at least one; a packet whose TTL reaches zero is destroyed. That stops a packet caught in a routing loop from circling forever, and traceroute, in Lesson 35, exploits it. The same name is used for a different idea in DNS and in CDN caches: how long an answer or object may be kept before it must be fetched again.

You can see IP TTL at work in Lesson 1's ping output. Hosts start packets with a fixed TTL: the Linux kernel's default is 64, and Windows has long used 128. A reply that arrives with TTL 116 most likely started at 128 and crossed 12 routers.

What matters here: CDNs move content closer to users, VPNs tunnel private traffic across public networks, QoS ranks traffic when links are busy, and TTL limits how long a packet or a cached answer may live.

Physical and virtual appliances

Every function in this lesson can run as dedicated hardware or as software. A virtual firewall or virtual router is the same function packaged as a virtual machine, and cloud providers sell load balancers, firewalls and NAT gateways as services you never see. The exam's phrase "physical and virtual appliances" means only that. Lesson 13 shows how cloud networks rebuild this whole table out of virtual parts, an idea called network functions virtualization.

Common misconceptions

• "An IDS protects the network by stopping attacks." A passive IDS only sees a copy of traffic and alerts. Blocking requires an inline IPS or another control acting on the alert.
• "A firewall that allows outbound traffic must also need inbound rules for every reply." A stateful firewall admits replies that match connections in its state table. Only stateless packet filters need explicit rules for return traffic.
• "NAS and SAN are the same thing with different marketing." NAS serves files to users over the LAN; SAN presents block storage that a server treats as its own disk.
• "TTL is a time in seconds." RFC 791 defined it in seconds but required every router to subtract at least one, so in practice IP TTL is a hop count. DNS TTL, by contrast, really is in seconds.

The short version

• Routers read IP addresses, switches read MAC addresses, firewalls read addresses, ports, state and sometimes content.
• Stateless filters judge each packet alone; stateful firewalls track connections; application-aware firewalls inspect content.
• IDS: passive copy, alerts. IPS: inline, can block, and pays for false positives in blocked legitimate traffic.
• Load balancers spread requests and drop failed servers using health checks; forward proxies serve clients, reverse proxies serve servers.
• NAS serves files; SAN serves blocks over a dedicated storage network.
• CDN caches content near users; VPN tunnels; QoS prioritizes with DSCP (EF 46 for voice); IP TTL is a hop limit that prevents endless loops.

Sources

1. Scarfone, K., and Hoffman, P. (2009). Guidelines on firewalls and firewall policy (NIST Special Publication 800-41 Revision 1). National Institute of Standards and Technology. csrc.nist.gov
2. Scarfone, K., and Mell, P. (2007). Guide to intrusion detection and prevention systems (IDPS) (NIST Special Publication 800-94). National Institute of Standards and Technology. csrc.nist.gov
3. Fielding, R., Nottingham, M., and Reschke, J. (Eds.). (2022). HTTP semantics (RFC 9110), section 3.7. RFC Editor. rfc-editor.org
4. NGINX. (n.d.). Using nginx as HTTP load balancer. nginx.org
5. Storage Networking Industry Association. (n.d.). Network attached storage and Storage area network, in SNIA online dictionary. snia.org (NAS); snia.org (SAN)
6. Calhoun, P., Montemurro, M., and Stanley, D. (Eds.). (2009). Control and provisioning of wireless access points (CAPWAP) protocol specification (RFC 5415). RFC Editor. rfc-editor.org
7. Niven-Jenkins, B., Le Faucheur, F., and Bitar, N. (2012). Content distribution network interconnection (CDNI) problem statement (RFC 6707). RFC Editor. rfc-editor.org
8. Nichols, K., Blake, S., Baker, F., and Black, D. (1998). Definition of the Differentiated Services field (DS field) in the IPv4 and IPv6 headers (RFC 2474). RFC Editor. rfc-editor.org
9. Babiarz, J., Chan, K., and Baker, F. (2006). Configuration guidelines for DiffServ service classes (RFC 4594). RFC Editor. rfc-editor.org
10. Postel, J. (Ed.). (1981). Internet Protocol (RFC 791), section 3.1. RFC Editor. rfc-editor.org
11. Linux kernel documentation. (n.d.). IP sysctl: ip_default_ttl. docs.kernel.org
12. Microsoft. (n.d.). Appendix A: TCP/IP configuration parameters (DefaultTTL) [Windows Server 2003 technical reference]. learn.microsoft.com

Six links to choose by Monday

A distribution warehouse sits 2 km from its head office, and the network team has six links to specify before the fit-out crew arrives. Desks in the warehouse office sit 85 m of cable away from the wiring closet. The closet must reach the server room 350 m away at 10 Gbps. The two buildings need a 10 Gbps link across the 2 km gap. Inside the server rack, a top-of-rack switch must connect servers 2 m away at 10 Gbps. A security kiosk at the gate has no cable at all. And the internet service arrives from the cable company. The cable route above the office ceiling runs through the space the air-conditioning uses as its return path.

Each link has a right answer, and working them out covers nearly all of objective 1.5. The deciding questions are always the same: how far, how fast, through what environment, and at what cost?

Link 1: desks to the closet, on twisted-pair copper

Twisted-pair copper with RJ45 connectors is the default for desks, because it is cheap, easy to terminate and can carry power to phones and access points. Its limit is distance: the Ethernet standards for twisted pair are written around a 100 m channel. Speed depends on the cable's category. Intel's guidance for its 10GBASE-T adapters gives the figures most networks are designed around.

The desks need 1 Gbps at 85 m, so Category 6 is a sound choice, and Category 6A would leave room for 10 Gbps later. One more requirement decides the jacket. The ceiling is a plenum, a space that is part of the building's air-distribution system, and in the United States the National Electrical Code allows only plenum-rated communications cable, marked CMP, in such spaces. Plenum cable is made to limit flame spread and smoke, because a fire in a concealed air path can travel through a building. Ordinary non-plenum cable is fine inside walls and conduit but not in an air-handling space. Your local code governs; the exam expects you to know that air-handling spaces need plenum-rated cable.

Remember: twisted pair reaches 100 m; the category sets the speed (Category 6 does 10 Gbps only to 55 m, Category 6A to 100 m), and a ceiling used for air return needs plenum-rated cable.

Links 2 and 3: fiber, multimode or single-mode

Past 100 m, or wherever electrical interference or lightning between buildings is a concern, fiber takes over. Fiber carries light, so it ignores electrical noise and does not conduct current between buildings. The Fiber Optic Association describes the two families.

The wide multimode core lets light travel in many paths at slightly different speeds, which smears the signal over distance, so multimode reach is limited. The narrow single-mode core carries essentially one path, so it reaches kilometres. Cisco's data sheet for its 10 Gbps optics turns that into numbers: 10GBASE-SR runs up to 300 m on OM3 and 400 m on OM4 multimode, while 10GBASE-LR runs up to 10 km on single-mode fiber at 1310 nm.

So link 2, 350 m inside the building at 10 Gbps, fits 10GBASE-SR on OM4 multimode with 50 m to spare, though OM3's 300 m would fall short. Link 3, 2 km between buildings, is beyond any multimode option and needs 10GBASE-LR on single-mode fiber. A useful habit: name the optic (SR or LR) and the fiber (OM4 or OS2) together, because a mismatch between them is a classic reason a new link stays dark.

Remember: multimode is for hundreds of metres (10GBASE-SR: 300 m on OM3, 400 m on OM4); single-mode is for kilometres (10GBASE-LR: 10 km); the optics at both ends must match each other and the fiber.

Link 4: inside the rack, direct attach copper

For the 2 m hop from the top-of-rack switch to each server, fiber optics would work but cost more than they need to. A direct attach copper (DAC) cable is a length of twinaxial copper with an SFP+ module permanently fixed at each end; it plugs straight into the switch and the server's network card. Cisco sells passive DAC cables from 1 to 5 m and active ones at 7 and 10 m. Short, cheap and simple, DAC is the standard answer for in-rack links. Twinaxial cable, the objective's other term, simply means the two-conductor shielded copper inside a DAC.

Links 5 and 6: cellular, satellite and coaxial cable

The gate kiosk has no cable, so it needs radio. Objective 1.5 names three wireless families. Wi-Fi (802.11), which Lesson 19 covers in depth, serves short distances inside a site. Cellular service, 4G LTE and 5G, reaches anywhere a carrier has coverage; the ITU's requirements for 5G, called IMT-2020, cover enhanced mobile broadband, ultra-reliable low-latency communications and massive machine-type communications. A small cellular router is the quickest way to connect a kiosk, a construction site or a pop-up shop, and many businesses use one as a backup internet link.

Satellite covers places with neither cable nor cellular coverage, and its weakness is physics. The European Space Agency gives the altitude of geostationary orbit as 35,786 km. Light travels about 300,000 km per second, so one trip up or down takes about 0.12 seconds. A request goes up and down, and the reply goes up and down again: four legs, at least about 0.48 seconds, before any processing. That delay is tolerable for email and painful for voice calls. Low Earth orbit, which ESA puts below 2,000 km, shortens each leg to a few milliseconds, which is why newer satellite services use large constellations of low satellites.

Finally, the internet service. The cable company delivers it over coaxial cable, which has a single central conductor inside a shield. At the cable modem it ends in a threaded F-type connector. Amphenol, a connector maker, describes the F-type as a threaded interface used mainly for cable television, set-top boxes and cable modems. Its older cousin, the BNC connector, fastens with a bayonet twist and appears on video equipment and very old coaxial Ethernet.

Transceivers and connectors

Switch uplink ports are often empty cages that accept a pluggable transceiver, so the same switch can use copper or any type of fiber. Objective 1.5 asks you to know the form factors, and that a transceiver is built for a protocol, usually Ethernet, sometimes Fibre Channel for SANs.

The Q stands for quad: a QSFP module bundles four lanes, which is why 100GBASE-SR4 needs a multi-fiber connector. The fiber connectors themselves are easy to tell apart once you know what to look for. The Fiber Optic Association's identification guide describes them.

• LC: a small form-factor connector with a 1.25 mm ferrule, half the size of SC. The usual connector on SFP and SFP+ optics, normally paired as duplex LC.
• SC: a larger snap-in connector with a 2.5 mm ferrule that latches with a push-pull motion. Common on older equipment and in carrier gear.
• ST: a bayonet-mount connector with a long cylindrical 2.5 mm ferrule, twisted to lock. Found on older multimode installations.
• MPO: an array connector for ribbon cable, holding 12 or more fibers in one ferrule, used for parallel optics such as 40 and 100 Gbps multimode links.

Copper connectors complete the list: RJ45, the eight-position Ethernet connector; RJ11, the narrower jack for analogue telephone lines and DSL; and the two coaxial connectors, F-type and BNC.

Remember: SFP is 1 Gbps, SFP+ is 10 Gbps, QSFP is four lanes for 40 or 100 Gbps; LC is the small duplex fiber connector, SC is push-pull, ST twists, MPO carries many fibers at once.

The finished specification

Common misconceptions

• "Category 6 means 10 Gbps." Only to 55 m. For 10 Gbps across a full 100 m channel you need Category 6A.
• "Single-mode is always better, so use it everywhere." It reaches farther, but its optics cost more. Inside a building, multimode with SR optics is usually the economical choice.
• "Any fiber transceiver works with any fiber." SR optics are for multimode at 850 nm and LR optics for single-mode at 1310 nm. Mixing them, or using the wrong fiber, leaves the link down.
• "Plenum is just a premium grade of cable." It is a fire-safety rating required in air-handling spaces, not a performance grade.

Putting it together

• Choose media by distance, speed, environment and cost.
• Twisted pair: 100 m channel; Category 5e for 1 Gbps, Category 6 to 55 m or 6A to 100 m for 10 Gbps; Category 8 for 25 and 40 Gbps over at least 30 m.
• Multimode fiber for hundreds of metres, single-mode for kilometres; match the optic to the fiber at both ends.
• DAC twinax for in-rack links; coaxial with F-type for cable service; cellular or satellite where there is no cable, remembering geostationary latency of at least about 0.48 seconds.
• SFP, SFP+ and QSFP set the speed class; LC, SC, ST and MPO are the fiber connectors to recognize.
• Air-handling spaces need plenum-rated cable.

Sources

1. Intel. (n.d.). Cable requirements for Intel Ethernet converged network adapter X540 series. Intel Support. intel.com
2. IEEE 802.3 Working Group. (2003). 10GBASE-T Study Group objectives; (2015). P802.3bq 25G/40GBASE-T objectives. ieee802.org (10GBASE-T); ieee802.org (25G/40GBASE-T)
3. Fluke Networks. (2016, April 28). Cabling standard subcommittee work hand in hand with IEEE. flukenetworks.com
4. Fiber Optic Association. (n.d.). Optical fiber and Fiber optic connector identifier. thefoa.org (fiber); thefoa.org (connectors)
5. Cisco Systems. (n.d.). Cisco 10GBASE SFP+ modules data sheet; Cisco 1000BASE SFP transceiver modules data sheet; Cisco 100GBASE QSFP-100G modules data sheet. cisco.com (10G); cisco.com (1G); cisco.com (100G)
6. DeDad, J. (2003, April 1). Plenum datacom wiring: What you need to know. EC&M. ecmweb.com
7. National Fire Protection Association. (2023). NFPA 70: National Electrical Code, Article 800. NFPA. (Cited for the plenum rule as summarized by DeDad; check the edition your jurisdiction has adopted.)
8. European Space Agency. (n.d.). Types of orbits. esa.int
9. International Telecommunication Union. (n.d.). IMT-2020 [ITU-R Working Party 5D]. itu.int
10. Amphenol RF. (n.d.). F-type connectors. amphenolrf.com

A telephone idea in a data center

In March 1953 Charles Clos of Bell Telephone Laboratories published "A Study of Non-Blocking Switching Networks" in the Bell System Technical Journal. His subject was the telephone exchange. A single giant switch that could connect any caller to any other was impossibly expensive. The alternative was a network built in stages from smaller switches, arranged so that calls would not be blocked. In August 2016, engineers from Facebook and Arista Networks published RFC 7938, describing how large data centers build their networks as exactly this kind of Clos fabric, now called spine and leaf. The idea moved from telephone exchanges to racks of servers because the traffic problem had become the same: anyone must reach anyone, quickly, without a bottleneck.

Network topology is the shape of a network: which devices connect to which. Objective 1.6 asks you to compare the shapes and the architectures built from them. The clearest way in is to follow the shapes in the order an organization usually meets them, from a single office to a data center. Watch what problem each one solves, and what new problem it creates.

Point to point and star: the first office

The simplest topology is point to point: one link joining exactly two endpoints, such as the fiber between two buildings in Lesson 5 or a leased circuit between two offices. Nothing else shares the link, so there is no addressing question on it, only capacity and reliability.

Inside the first office, every computer, printer and access point runs a cable to one switch. That is a star: all devices connect to a central point. Stars are cheap, easy to extend and easy to troubleshoot, because a fault on one cable affects only one device. Their weakness is the centre: if the switch fails, everyone is cut off. Almost every wired LAN you will ever see is a star, or a star of stars.

Hub and spoke: the first branches

When the company opens branch offices, the cheapest way to connect them is to link each branch to headquarters and nothing else. That is hub and spoke, the WAN version of a star. Microsoft's reference architecture for its Azure cloud uses the same pattern for virtual networks. The hub is the central point of connectivity and hosts shared services such as firewalls, DNS and the VPN gateway, while spokes isolate individual workloads. The design makes central policy easy, since everything passes through the hub.

The costs follow from the shape. Branch-to-branch traffic must travel through the hub, adding a hop and loading the hub's links, and the hub is a single point of failure for the whole WAN. Microsoft's guide notes that sending spoke-to-spoke traffic through a hub appliance adds a hop, and that direct peering between spokes avoids it.

Mesh: when links matter more than money

In a full mesh, every site has a direct link to every other site. Any single link can fail and every site can still reach every other one, often directly. The price grows quickly. Each of n sites needs a link to the other n minus 1, and each link serves two sites, so a full mesh needs n(n minus 1) divided by 2 links.

That is why real networks usually build a partial mesh: direct links among the few most important sites, and hub and spoke for the rest. Wireless networks also use mesh, with access points relaying traffic for one another, which Lesson 19 covers. Picture a star in each office, hub and spoke across the WAN, and a partial mesh among the three largest sites. A network that combines shapes like this is called a hybrid topology, and it describes most real organizations.

In short: stars and hub-and-spoke are cheap and simple but depend on their centre. A full mesh survives link failures but needs n(n minus 1) divided by 2 links, so most networks are hybrids that mesh only where it pays.

The three-tier campus and its collapsed cousin

As the headquarters grows into a campus of several buildings, a flat star of stars becomes hard to manage. Cisco's Enterprise Campus 3.0 design guide, updated in 2008 and still the vocabulary the exam uses, divides the campus into three layers.

The guide is specific about the core: it should offer a limited set of services, avoid complex policy and have no directly attached users or servers, because its whole job is to move traffic fast and stay up. A smaller campus, one building or a few adjacent ones, can merge core and distribution into the same switches. That two-tier design is a collapsed core. It saves money, and Cisco's guide accepts it for small sites while recommending a separate core as the network grows, because a distinct core isolates faults and simplifies change control.

In short: access is where users plug in, distribution aggregates and applies policy, core moves traffic and nothing else; a collapsed core merges the top two layers to save cost on a small campus.

Spine and leaf: back to Clos

The three-tier model was built for traffic that flows between users and servers. A modern data center carries something different. RFC 7938 explains that large data centers now host applications that generate significant server-to-server traffic, such as Hadoop clusters, data replication and virtual machine migration. In a tree of core, distribution and access, two servers in different branches talk through several layers, and the links near the top become bottlenecks.

Spine and leaf fixes this with Clos's idea. Servers connect to leaf switches, usually one or two at the top of each rack. Cisco's data center fabric white paper states the rule that defines the design: every leaf switch is connected to each of the spine switches, in a full mesh between the two layers. Leaves never connect to other leaves, and spines never connect to other spines. Two consequences follow.

• Any server reaches any server in another rack through the same path length: leaf, spine, leaf. Latency is predictable whichever two racks are talking.
• Every spine offers an equally good path, so traffic is spread across all of them; RFC 7938 describes server-to-server traffic being load balanced over all available paths using equal-cost multipath. Add a spine to add bandwidth; add a leaf to add server ports.

In short: in spine and leaf every leaf links to every spine, so any two servers in different racks are always leaf, spine, leaf apart, and capacity grows by adding spines.

North-south and east-west

Engineers describe traffic direction with a compass. North-south traffic enters or leaves the data center or campus: a customer on the internet loading your web page, an employee reaching a cloud application. East-west traffic stays inside: a web server querying a database server, two virtual machines replicating data. RFC 7938's argument is that data centers have shifted from mostly north-south to heavily east-west traffic, which is why spine and leaf replaced the three-tier tree there. The distinction matters for security too. A firewall at the edge sees north-south traffic but never sees east-west traffic, which is one reason Lesson 14's zero trust designs inspect traffic inside the network as well.

The topologies side by side

Common misconceptions

• "Full mesh is always the most reliable choice, so use it everywhere." It survives link failures, but 20 sites need 190 links. Partial mesh plus hub and spoke usually buys enough resilience for far less.
• "In spine and leaf, leaves connect to each other for speed." Leaves connect only to spines and spines only to leaves. That rule is what keeps every path the same length.
• "The core layer is where the important servers go." Cisco's design guidance keeps users and servers off the core entirely; servers attach in the data center or a server block.
• "East-west means traffic between the company's eastern and western offices." It means traffic that stays inside the data center or network, between servers. North-south crosses its edge.

Where this leaves us

• Point to point joins two endpoints; star joins many to a centre; hub and spoke is the WAN star; mesh links sites directly at a cost of n(n minus 1)/2 links; hybrid mixes them.
• Three-tier: access (users, trust boundary), distribution (aggregation, policy), core (fast backbone, no users). Collapsed core merges core and distribution for small campuses.
• Spine and leaf: every leaf to every spine, leaf-spine-leaf paths, scale by adding spines or leaves; descended from Clos's 1953 telephone networks.
• North-south crosses the network's edge; east-west stays inside, and now dominates data centers.

Sources

1. Clos, C. (1953). A study of non-blocking switching networks. Bell System Technical Journal, 32(2), 406-424. DOI 10.1002/j.1538-7305.1953.tb01433.x (cited as reference CLOS53 in RFC 7938; the paper itself was not consulted for this lesson).
2. Lapukhov, P., Premji, A., and Mitchell, J. (Ed.). (2016). Use of BGP for routing in large-scale data centers (RFC 7938). RFC Editor. rfc-editor.org
3. Cisco Systems. (2008). Enterprise Campus 3.0 architecture: Overview and framework. cisco.com
4. Cisco Systems. (n.d.). Cisco massively scalable data center network fabric design and operation white paper. cisco.com
5. Microsoft. (2026). Hub-spoke network topology in Azure. Azure Architecture Center. learn.microsoft.com
6. CompTIA. (2023). CompTIA Network+ N10-009 certification exam objectives (Document version 6.0), objective 1.6. CompTIA (PDF)

Two different promises

Jon Postel's RFC 768, dated 28 August 1980, defines the User Datagram Protocol with a header of just four fields and a frank warning that delivery and duplicate protection are not guaranteed. The Transmission Control Protocol makes the opposite promise. Its current specification, RFC 9293 from August 2022, is mostly about keeping that promise: connection states, sequence numbers, acknowledgments, retransmission. Every application that sends data across an IP network chooses between these two promises, or asks IP to carry something else entirely. Objective 1.4 calls these choices the IP types, and this lesson compares them side by side.

The protocol number: what the packet is carrying

Every IPv4 header has a protocol field, a number telling the receiver what is inside the packet. IANA keeps the registry of these numbers. Six of them appear in the exam objectives, and two of them, 50 and 51, are favourite exam questions because they are easy to confuse.

Do not confuse these numbers with port numbers. A protocol number says which protocol sits inside IP. A port number, inside a TCP or UDP header, says which program or service the data is for. Lesson 8 covers ports.

The upshot: the IP protocol field names the cargo: 1 ICMP, 6 TCP, 17 UDP, 47 GRE, 50 ESP, 51 AH.

TCP: a connection with receipts

TCP builds a connection before it sends any data. RFC 9293 describes the setup as the three-way handshake. Each side sends a SYN segment carrying its initial sequence number and receives an acknowledgment of it. One message can carry the server's SYN and its acknowledgment together, so the exchange takes three segments.

1. Client to server: SYN, "my byte numbering starts here."
2. Server to client: SYN-ACK, "acknowledged; mine starts here."
3. Client to server: ACK, "acknowledged." The connection is ESTABLISHED.

From then on, every byte is numbered. The receiver acknowledges what it has received, the sender retransmits anything that goes unacknowledged, and a checksum on each segment detects corruption. The window field tells the sender how many more bytes the receiver can accept right now, which is TCP's flow control. Closing is polite: each side sends a FIN and acknowledges the other's. A reset, RST, is the impolite version: RFC 9293 says it is sent when a segment arrives that apparently is not intended for the current connection, and it aborts the connection at once.

The states are visible on your own computer. On Windows, netstat -ano lists every TCP connection with its state and the owning process ID; on Linux, ss -tuna shows TCP and UDP sockets numerically. You will see LISTEN for a service waiting for clients, ESTABLISHED for live connections, and TIME_WAIT for connections that have just closed. A long list of SYN_SENT entries toward one address tells you the handshake never completed: the far end, or a firewall in between, is not answering.

The upshot: TCP spends one round trip on a handshake, then numbers, acknowledges and retransmits every byte, so the application receives exactly what was sent, in order, or learns that the connection failed.

UDP: send it and move on

UDP's header is eight bytes: source port, destination port, length and checksum. There is no handshake, no acknowledgment and no retransmission. A UDP datagram is sent once; if it is lost, UDP itself does nothing about it. That sounds like a flaw until you look at who chooses UDP and why.

• Short request and reply. A DNS query fits in one datagram. If no answer comes, the client simply asks again, which is cheaper than a handshake for every lookup.
• No address yet. A DHCP client has no IP address when it starts and must broadcast. A TCP connection is always between exactly two endpoints, so broadcast and multicast traffic travels over UDP.
• Late is useless. A voice packet that arrives half a second late is worse than one that never arrives. Voice and video calls send media over UDP and conceal small losses rather than wait for retransmission.
• Doing reliability its own way. QUIC, standardized in RFC 9000 in May 2021 and used by HTTP/3, runs over UDP and builds its own encryption, multiplexing and recovery on top.

The upshot: UDP is not a broken TCP; it is the right choice when a retry is cheap, when there is no single peer, or when late data is worthless.

ICMP: the network talking about itself

ICMP carries messages about delivery rather than application data. RFC 792 defines the ones you meet most.

It is tempting to block all ICMP at the firewall, since attackers can use ping to find hosts. The cost is hidden. Path MTU discovery, described in RFC 1191, works by sending packets with the Don't Fragment bit set. When a packet is too big for the next link, the router answers with destination unreachable, code "fragmentation needed and DF set," and the sender shrinks its packets. Block those messages and large packets vanish silently while small ones get through: web pages that start loading and then hang are the classic symptom. Filter ICMP selectively, not wholesale.

Tunnels: GRE and the IPsec family

Sometimes the cargo is another packet. GRE, Generic Routing Encapsulation, defined in RFC 2784 in March 2000, wraps an arbitrary network-layer packet inside an IP packet with protocol number 47. That lets two routers build a virtual point-to-point link across the internet, which can carry traffic a plain internet path would not, such as routing protocol updates or multicast. GRE provides no encryption at all. Its security considerations compare it to a normal IPv4 network.

IPsec adds the protection. Three pieces work together.

• AH, the Authentication Header (RFC 4302, protocol 51), provides integrity, data origin authentication and protection against replayed packets. It does not encrypt. It also covers the IP addresses in its integrity check, which is why, as RFC 3715 explains, AH breaks when NAT rewrites those addresses.
• ESP, the Encapsulating Security Payload (RFC 4303, protocol 50), provides confidentiality by encryption, plus integrity, data origin authentication and anti-replay. Its integrity check covers only what follows the ESP header, so it survives address translation better. ESP is what nearly every IPsec VPN uses.
• IKE, Internet Key Exchange (version 2 in RFC 7296), authenticates the two peers to each other and sets up the security associations, the agreed keys and algorithms, that AH and ESP use. IKE runs over UDP port 500, and over UDP port 4500 when NAT is in the way.

IPsec runs in two modes. Transport mode protects the payload of a packet between two hosts and leaves the original IP header in place. Tunnel mode protects the entire original packet and wraps it in a new outer IP header, which is how site-to-site VPNs join two networks. A common design runs GRE inside IPsec: GRE carries the routing protocols and multicast, and ESP encrypts the lot. Lesson 27 builds VPNs from these parts.

The upshot: GRE tunnels without protecting; AH authenticates without encrypting and fails through NAT; ESP encrypts and authenticates; IKE on UDP 500 and 4500 negotiates the keys for both.

Traffic types, revisited with transports

Lesson 3 introduced the four traffic types. Here they are with the transport each can use.

Common misconceptions

• "UDP is unreliable, so serious applications avoid it." DNS, DHCP, NTP, voice and HTTP/3 all ride on UDP. Applications that need reliability over UDP build it themselves, as QUIC does.
• "ICMP is only ping, so blocking it is pure gain." Path MTU discovery depends on ICMP destination unreachable messages. Blocking them causes large transfers to hang mysteriously.
• "GRE tunnels are encrypted." GRE only encapsulates. Encryption comes from running it inside IPsec ESP.
• "AH and ESP are interchangeable; AH is just the older one." AH never encrypts and breaks through NAT; ESP encrypts. Protocol 50 is ESP, 51 is AH.

Pulling it together

• IP protocol numbers: ICMP 1, TCP 6, UDP 17, GRE 47, ESP 50, AH 51.
• TCP: three-way handshake (SYN, SYN-ACK, ACK), numbered and acknowledged bytes, retransmission, window flow control, FIN to close, RST to abort.
• UDP: an 8-byte header and no guarantees; chosen for quick queries, broadcast and multicast, and real-time media.
• ICMP: echo (8 and 0), destination unreachable (3), time exceeded (11); path MTU discovery needs it.
• GRE encapsulates without encryption; AH authenticates without encryption; ESP encrypts; IKE (UDP 500 and 4500) sets up the keys.
• netstat -ano and ss -tuna show connection states on your own machine.

Sources

1. Postel, J. (1980). User Datagram Protocol (RFC 768). RFC Editor. rfc-editor.org
2. Eddy, W. (Ed.). (2022). Transmission Control Protocol (TCP) (RFC 9293). RFC Editor. rfc-editor.org
3. Postel, J. (1981). Internet Control Message Protocol (RFC 792). RFC Editor. rfc-editor.org
4. Mogul, J., and Deering, S. (1990). Path MTU discovery (RFC 1191). RFC Editor. rfc-editor.org
5. Internet Assigned Numbers Authority. (n.d.). Assigned Internet protocol numbers. iana.org
6. Farinacci, D., Li, T., Hanks, S., Meyer, D., and Traina, P. (2000). Generic Routing Encapsulation (GRE) (RFC 2784). RFC Editor. rfc-editor.org
7. Kent, S. (2005). IP Authentication Header (RFC 4302) and IP Encapsulating Security Payload (ESP) (RFC 4303). RFC Editor. rfc-editor.org (AH); rfc-editor.org (ESP)
8. Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and Kivinen, T. (2014). Internet Key Exchange protocol version 2 (IKEv2) (RFC 7296). RFC Editor. rfc-editor.org
9. Aboba, B., and Dixon, W. (2004). IPsec-network address translation (NAT) compatibility requirements (RFC 3715). RFC Editor. rfc-editor.org
10. Iyengar, J., and Thomson, M. (Eds.). (2021). QUIC: A UDP-based multiplexed and secure transport (RFC 9000). RFC Editor. rfc-editor.org
11. Microsoft. (2017). netstat [Windows commands reference]. Microsoft Learn. learn.microsoft.com
12. Linux man-pages project. (n.d.). ss(8). man7.org

Twenty rows out of fifteen thousand

The registry of service names and port numbers that IANA publishes as a spreadsheet ran to more than 15,000 lines when it was downloaded for this lesson on 27 October 2026. Objective 1.4 asks you to know twenty services from it. Those twenty are worth real effort: they turn up in firewall rules, in troubleshooting scenarios and in performance-based questions where you must decide what to allow. This lesson is a procedure for learning them so they stay learned, in six steps, with a check on a real machine at the end.

Step 1: know what a port is

An IP address gets a packet to a host. A port number gets the data to the right program on that host. Ports are 16-bit numbers, so they run from 0 to 65,535, and each transport has its own set: TCP port 53 and UDP port 53 are different doors. A conversation is identified by both ends: source address and port, destination address and port, and the transport.

Servers listen on fixed, published ports so clients know where to knock. Clients do not need fixed ports; the operating system picks a temporary one for each connection, often called an ephemeral port. RFC 6335 divides the range into three blocks.

Operating systems choose their own ephemeral range. The Linux kernel's default, for example, is 32768 to 60999. So when Wireshark shows your browser talking from port 52811 to a server's port 443, the 443 tells you the service and the 52811 is just your side of this one conversation.

Worth holding on to: the server's port names the service; the client's port is a temporary number that only identifies the conversation.

Step 2: learn the table in groups, not as a list

Twenty unrelated numbers are hard to hold. Twenty numbers grouped by what the service does are much easier, because each group tells a story. Here is the objective's list, checked against the IANA registry.

A few patterns make the numbers stick. The file-transfer and remote-access group sits together at 20 to 23. The things a host needs to join a network, names, addresses and time, are 53, 67 and 68, and 123. Monitoring pairs up: SNMP at 161 and 162. Secure versions of directory and mail protocols sit in the 400s to 600s. Microsoft's services sit higher: 445, 1433, 3389.

Worth holding on to: group the ports by job (files, remote access, email, joining the network, web, monitoring, directories, Windows and databases, voice) and recall the group before the number.

Step 3: pair every clear-text service with its secure partner

Many exam questions are really about replacing an insecure protocol, so learn the table in pairs.

The email row needs care, because the exam's label and the standards differ. CompTIA lists "SMTPS" on port 587. IANA registers 587 as "submission", the port mail clients use to hand outgoing mail to their server, and the connection is usually secured by the STARTTLS command after it opens. RFC 8314, from January 2018, defines port 465 as "submissions", where TLS starts immediately, and says implicit TLS on 465 should be preferred over STARTTLS. For the exam, answer 587 when asked for SMTPS. At work, expect to see both 587 and 465, and 25 for server-to-server relay.

Worth holding on to: every insecure protocol in the table has a secure partner; know both numbers, and know that the exam's SMTPS is port 587.

Step 4: know which transport each one uses

IANA registers most of these numbers for both TCP and UDP, but each protocol actually uses one or both. Firewall rules must name the right one. Use the reasoning from Lesson 7: one-shot queries, broadcasts and streams of small reports go over UDP; sessions that must arrive intact go over TCP.

• UDP: DHCP 67 and 68, TFTP 69, NTP 123, SNMP 161 and 162, syslog 514. IANA's entry for TCP 514 is a different, older service entirely: rsh, the remote shell.
• TCP: FTP, SSH and SFTP, Telnet, SMTP and submission, HTTP, LDAP and LDAPS, SMB, SQL Server.
• Both: DNS on 53. Ordinary queries usually use UDP, but RFC 7766 makes TCP support required for every full DNS implementation: zone transfers always use TCP, and a client retries over TCP when a UDP answer comes back truncated. SIP on 5060 runs over UDP or TCP, and its TLS form on 5061 uses TCP. RDP uses TCP 3389 and can add UDP 3389, and HTTP/3 brings HTTPS onto UDP 443.

Now the changed-input example. A firewall team writes a rule allowing TCP 53 to the company's DNS server and nothing else. Zone transfers work. Every ordinary lookup fails, because ordinary lookups arrive on UDP 53. Change the rule to allow UDP and TCP 53, and both work.

Step 5: check against a real machine

Ports become concrete when you see them on your own computer.

1. What is listening here? On Windows, run netstat -ano and look for lines in the LISTENING state; the last column is the process ID. On Linux, ss -tuln lists listening TCP and UDP sockets numerically. Identify any well-known port you recognize, such as 445 on Windows.
2. Can I reach that service over there? In PowerShell, Test-NetConnection -ComputerName www.wikipedia.org -Port 443 attempts a TCP connection and reports TcpTestSucceeded. Run it against a website, which is ordinary use of a public service.
3. Make it fail on purpose. Run Test-NetConnection -ComputerName localhost -Port 23 against your own computer. Unless you have installed a Telnet server, the test fails, because nothing listens on 23. A failed test means one of three things: nothing is listening, a firewall is blocking the port, or the host is unreachable. A ping that works while the port test fails points to the first two.
4. Watch the numbers on the wire. In Wireshark, the display filters tcp.port == 443 and udp.port == 53 isolate web and DNS traffic. Look at the source and destination ports in each direction of one conversation.

Keep to your own machine and to ordinary use of public services. Testing a port on a host you do not own or manage, beyond simply using its public service, needs the owner's permission.

Step 6: drill until it is automatic

Use the study method from Lesson 1. Make cards with a port on one side and the service, transport and secure partner on the other, and drill in both directions: 636 to LDAPS, and LDAPS to 636. Mix in scenario prompts such as "allow encrypted directory queries" or "receive switch logs". Five minutes a day for two weeks beats one long evening. When you can write the whole grouped table from memory in under four minutes, you are ready; on exam day you can jot it on the whiteboard before you start.

Common misconceptions

• "SFTP is FTP with SSL." SFTP is the SSH File Transfer Protocol, carried inside SSH on port 22. FTP secured with TLS is FTPS, a different protocol.
• "DNS uses UDP only." Queries usually do, but RFC 7766 requires TCP support, and zone transfers and large answers use TCP 53.
• "Moving a service to an unusual port hides it." Nmap's documentation warns that people can and do run services on strange ports, and its version detection identifies what actually answers on a port, whatever the number.
• "Port 587 is SMTP over SSL, just like 443 is HTTP over SSL." On 587 the session usually starts in clear text and upgrades with STARTTLS. Implicit TLS for submission is port 465. The exam still calls 587 SMTPS.

Summing up

• Ports identify programs; servers use fixed ports, clients use temporary ones. Ranges: 0 to 1023 well-known, 1024 to 49151 registered, 49152 to 65535 dynamic.
• Files: FTP 20/21, SFTP 22, TFTP 69. Remote access: SSH 22, Telnet 23, RDP 3389. Email: SMTP 25, SMTPS 587.
• Joining the network: DNS 53, DHCP 67/68, NTP 123. Web: HTTP 80, HTTPS 443.
• Monitoring: SNMP 161/162, syslog 514. Directories: LDAP 389, LDAPS 636. Windows and databases: SMB 445, SQL Server 1433. Voice: SIP 5060/5061.
• UDP: DHCP, TFTP, NTP, SNMP, syslog. Both: DNS and SIP. The rest are TCP.
• Check with netstat -ano, ss -tuln, Test-NetConnection and Wireshark port filters, on equipment you own.

Sources

1. Internet Assigned Numbers Authority. (n.d.). Service name and transport protocol port number registry. Retrieved 27 October 2026. iana.org
2. Cotton, M., Eggert, L., Touch, J., Westerlund, M., and Cheshire, S. (2011). IANA procedures for the management of the service name and transport protocol port number registry (RFC 6335). RFC Editor. rfc-editor.org
3. Moore, K., and Newman, C. (2018). Cleartext considered obsolete: Use of TLS for email submission and access (RFC 8314). RFC Editor. rfc-editor.org
4. Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and Wessels, D. (2016). DNS transport over TCP: Implementation requirements (RFC 7766). RFC Editor. rfc-editor.org
5. Ylonen, T., and Lonvick, C. (Ed.). (2006). The Secure Shell (SSH) transport layer protocol (RFC 4253). RFC Editor. rfc-editor.org
6. Galbraith, J., and Saarenmaa, O. (2006). SSH File Transfer Protocol (Internet-Draft draft-ietf-secsh-filexfer-13). IETF. datatracker.ietf.org
7. Ford-Hutchinson, P. (2005). Securing FTP with TLS (RFC 4217). RFC Editor. rfc-editor.org
8. Okmianski, A. (2009). Transmission of syslog messages over UDP (RFC 5426). RFC Editor. rfc-editor.org
9. Microsoft. (n.d.). Test-NetConnection [NetTCPIP module reference]. Microsoft Learn. learn.microsoft.com
10. Lyon, G. (n.d.). Service and version detection, in Nmap reference guide. nmap.org
11. Linux kernel documentation. (n.d.). IP sysctl: ip_local_port_range. docs.kernel.org

Five confident notes, five errors

A junior technician left these notes on five help-desk tickets, and every one contains a mistake. They are worth debugging carefully, because each mistake is one the exam is designed to catch.

1. "Laptop has 169.254.37.12. The DHCP server gave it a bad address; reboot the DHCP server."
2. "Lab server is 172.32.10.5, so it's private and safe from the internet."
3. "Host 10.1.1.1 with mask 255.255.255.0 is a class C address."
4. "Only 127.0.0.1 is loopback, so 127.20.0.9 must be a public address somewhere."
5. "Set the printer to 192.168.1.255/24, it's the last free address."

To see exactly where each note goes wrong, you need to read an address the way a computer does: as 32 bits.

Reading an address in binary

An IPv4 address is 32 bits, written as four 8-bit octets in decimal and separated by dots. Each bit in an octet has a place value, doubling from right to left.

To convert decimal to binary, work from the left: if the number is at least the place value, write 1 and subtract; otherwise write 0. Take 172. It is at least 128, so 1, leaving 44. It is less than 64, so 0. It is at least 32, so 1, leaving 12. Less than 16: 0. At least 8: 1, leaving 4. At least 4: 1, leaving 0. Then 0 and 0. So 172 is 10101100. Check by adding the place values of the 1 bits: 128 + 32 + 8 + 4 = 172.

A few conversions are worth knowing on sight, because they keep appearing in masks and private ranges.

So what?: every rule in this module, private ranges, classes, subnets, is a statement about bits; convert the octet that matters to binary and the rule becomes visible.

Note 3 debugged: classes come from the first bits, not the mask

The original IP specification, RFC 791 from 1981, split addresses into classes by their high-order bits. Class D was added for multicast by RFC 1112, which also reserved class E. The exam still lists all five.

The class is fixed by the first bits of the address, and 10 in binary is 00001010, which starts with 0. So 10.1.1.1 is a class A address whatever mask it carries. The note confused class with mask. That confusion is understandable, because under the old scheme the class did decide the mask. It no longer does. Classless Inter-Domain Routing, documented today in RFC 4632, replaced classes with an explicit prefix length, the /24 in 10.1.1.1/24, so any address can carry any mask. The exam uses classes as vocabulary; real networks use prefix lengths.

Note 2 debugged: private means three exact blocks

RFC 1918, published in 1996, reserves three blocks for private networks. Anyone may use them internally, and they are not routed on the public internet.

The middle block is where the note went wrong. The /12 means only the first 12 bits are fixed: all of the first octet and the first four bits of the second. In binary, 16 is 00010000 and 31 is 00011111: the first four bits, 0001, stay the same and the last four vary. Now look at 32: 00100000. Its first four bits are 0010, outside the block. So 172.32.10.5 is a public address, not a private one, and the server is not shielded by being in private space. Private addresses need translation to reach the internet, which is NAT's job in Lesson 18.

One more block causes confusion in the field. RFC 6598 reserves 100.64.0.0/10 as shared address space for carrier-grade NAT, used by internet providers between their own NAT devices and customers' routers. If your router's internet-facing address falls in that block, it is not truly public, and inbound connections cannot reach you directly.

Note 1 debugged: 169.254 means no DHCP answer at all

An address beginning 169.254 is an IPv4 link-local address, which Microsoft and CompTIA call Automatic Private IP Addressing (APIPA). RFC 3927, from 2005, describes the mechanism. When a host has no configured address, typically because no DHCP server answered, it picks an address at random from 169.254.1.0 to 169.254.254.255 (the first and last 256 addresses of 169.254.0.0/16 are reserved). It then uses ARP probes to check that no neighbour already uses the address. Link-local packets must not be sent to a router for forwarding, so the host can talk only to devices on its own link.

So the DHCP server did not give the laptop a bad address. Nothing gave it any address. The fault lies between the laptop and the DHCP server: a broken cable or Wi-Fi association, a wrong VLAN on the switch port, a missing DHCP relay, or a DHCP server that is down or out of addresses. Rebooting a healthy DHCP server fixes none of those. Lesson 25 traces DHCP failures properly.

Note 4 debugged: the whole of 127 is loopback

The special-purpose address registry in RFC 6890 lists the entire block 127.0.0.0/8 as loopback, citing RFC 1122, which says such addresses must never appear outside a host. 127.0.0.1 is just the conventional choice. 127.20.0.9 is also loopback, and so is every other address beginning 127. RFC 6890 lists the other special blocks you should recognize.

Everything not in a special block is ordinary public address space, globally unique and routed on the internet.

Note 5 debugged: the all-ones host is the broadcast address

Every subnet reserves two addresses. With all host bits set to 0, the address names the network itself; with all host bits set to 1, it is the subnet's broadcast address. In 192.168.1.0/24 the last octet holds the host bits, so 192.168.1.0 is the network and 192.168.1.255 the broadcast. Usable hosts run from .1 to .254. The note picked the one address in the subnet that a printer cannot have. Lesson 10 turns this rule into the subnetting procedure for any mask.

So what?: each wrong note came from skipping the bits: classes are set by leading bits, RFC 1918's middle block ends at 172.31, 169.254 means no DHCP reply, all of 127 is loopback, and the all-ones host is the broadcast.

Common misconceptions

• "A /24 mask makes an address class C." Class comes from the first bits of the address. Since CIDR, any class of address can carry any prefix length.
• "Every 172 address is private." Only 172.16.0.0 to 172.31.255.255 is RFC 1918 space.
• "APIPA is a kind of DHCP address." It is what a host gives itself when DHCP fails, and it only works on the local link.
• "Private addresses are a security feature." They are not routed on the internet, which helps, but hosts behind NAT still reach out and can still be attacked through those connections. Security comes from firewalls and hardening (Module 11).

Looking back

• IPv4 addresses are 32 bits in four octets; place values 128, 64, 32, 16, 8, 4, 2, 1.
• Classes by leading bits: A 0 (0 to 127), B 10 (128 to 191), C 110 (192 to 223), D 1110 multicast (224 to 239), E 1111 reserved (240 to 255). CIDR prefixes replaced class-based masks.
• Private: 10/8, 172.16/12 (to 172.31), 192.168/16. Shared CGN space: 100.64/10.
• 169.254/16 is link-local (APIPA): no DHCP answer, local link only.
• 127/8 is loopback; 255.255.255.255 is the limited broadcast; 0.0.0.0 means this host or the default route.
• In any subnet, all-zero host bits name the network and all-one host bits are the broadcast.

Sources

1. Postel, J. (Ed.). (1981). Internet Protocol (RFC 791), section 2.3 and section 3.2 (address formats). RFC Editor. rfc-editor.org
2. Deering, S. (1989). Host extensions for IP multicasting (RFC 1112), section 4. RFC Editor. rfc-editor.org
3. Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and Lear, E. (1996). Address allocation for private internets (RFC 1918). RFC Editor. rfc-editor.org
4. Cheshire, S., Aboba, B., and Guttman, E. (2005). Dynamic configuration of IPv4 link-local addresses (RFC 3927). RFC Editor. rfc-editor.org
5. Cotton, M., Vegoda, L., Bonica, R., and Haberman, B. (2013). Special-purpose IP address registries (RFC 6890). RFC Editor. rfc-editor.org
6. Fuller, V., and Li, T. (2006). Classless Inter-domain Routing (CIDR): The Internet address assignment and aggregation plan (RFC 4632). RFC Editor. rfc-editor.org
7. Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and Azinger, M. (2012). IANA-reserved IPv4 prefix for shared address space (RFC 6598). RFC Editor. rfc-editor.org

Same switch, different networks

Give a security camera the address 192.168.10.100 with the mask 255.255.255.224. Give its video recorder 192.168.10.140 with the same mask. Plug both into the same switch, and they still cannot talk to each other without a router. Nothing is broken. The mask has put them in two different networks, and by the end of this lesson you will be able to see that in about fifteen seconds. Objective 1.7 asks you to use IPv4 addressing "given a scenario", and this is the skill underneath every such scenario.

Masks and prefix lengths

A subnet mask is 32 bits: ones over the network part of an address, zeros over the host part. Lesson 3 showed a host comparing the network parts of two addresses to decide local or remote; Cisco's subnetting guide for new users describes the same operation as a logical AND of address and mask. The prefix length is just a count of the ones. 255.255.255.224 is 24 ones followed by 111 and five zeros: 27 ones, so it is written /27. Subnetting was standardized by RFC 950 in 1985, and RFC 4632's classless addressing lets the prefix length be anything from /0 to /32.

Within the octet where the mask changes, only eight values are possible, because the ones always fill from the left.

The same eight values repeat one octet to the left: /17 to /24 use the third octet (for example /20 is 255.255.240.0) and /9 to /16 use the second (for example /12 is 255.240.0.0). The host count comes from the number of host bits, h = 32 minus the prefix: 2 to the power h, minus 2 for the network and broadcast addresses. A /27 has 5 host bits: 32 minus 2 gives 30 hosts. A /20 has 12: 4,096 minus 2 gives 4,094.

Two edge cases matter. A /31 has only two addresses and no room for a separate network and broadcast address; RFC 3021, from December 2000, allows /31 on point-to-point links so both addresses can be used. A /32 names exactly one address, which is how a route to a single host or a loopback interface is written.

The core of it: the prefix counts the mask's ones; the octet where they stop gives a block size of 256 minus its value; and hosts equal 2 to the power of the host bits, minus 2.

The block-size method, step by step

Here is a procedure that works for any address and mask without writing out 32 bits.

1. Find the interesting octet: the one where the mask is neither 255 nor 0.
2. Find the block size: 256 minus the mask's value in that octet. Subnets start at every multiple of the block size.
3. Find the network address: take the largest multiple of the block size that is not more than the address's value in that octet. Octets to the left stay as they are; octets to the right become 0.
4. Find the broadcast address: the next multiple minus 1 in the interesting octet, with octets to the right set to 255.
5. Find the host range: first host is the network address plus 1; last host is the broadcast address minus 1.

Why does it work? Because the AND operation keeps the address bits under the mask's ones and zeros everything else, and in the interesting octet that is exactly rounding down to a multiple of the block size. You can check one in binary: 100 is 01100100, 224 is 11100000, and their AND is 01100000, which is 96.

Worked example 1: the camera and the recorder

Camera: 192.168.10.100/27. The mask is 255.255.255.224, so the fourth octet is interesting and the block size is 256 minus 224, which is 32. Subnets start at 0, 32, 64, 96, 128, 160 and so on. The largest multiple not above 100 is 96.

• Network: 192.168.10.96
• Broadcast: 192.168.10.127 (the next multiple, 128, minus 1)
• Hosts: 192.168.10.97 to 192.168.10.126, 30 of them

Recorder: 192.168.10.140/27. Same block size; the largest multiple not above 140 is 128. Its network is 192.168.10.128, broadcast 192.168.10.159. Different network from the camera's, so each device treats the other as remote and sends the traffic to its default gateway. With no router there, they cannot talk.

Now change one input. Move the recorder to 192.168.10.120. The largest multiple of 32 not above 120 is 96, so it now sits in 192.168.10.96/27 with the camera, and they talk directly through the switch. Alternatively, keep the addresses and widen both masks to /24: then both fall in 192.168.10.0/24. Either change flips the result.

Worked example 2: the interesting octet is the third

A host is 172.16.45.200 with mask 255.255.240.0 (/20). The third octet is interesting, with value 240, so the block size is 16. Multiples of 16 in the third octet: 0, 16, 32, 48. The largest not above 45 is 32.

• Network: 172.16.32.0 (third octet 32, fourth octet 0)
• Broadcast: 172.16.47.255 (third octet 48 minus 1, fourth octet 255)
• Hosts: 172.16.32.1 to 172.16.47.254
• Count: 12 host bits, so 4,096 minus 2, which is 4,094 hosts

The most common slip here is answering 172.16.45.255 for the broadcast, as if the mask were /24. The fourth octet is entirely host bits in a /20, so the broadcast ends in 255 only after the third octet reaches the end of its block, 47.

Worked example 3: the second octet, and a point-to-point link

A host is 10.20.30.40/13. The mask is 255.248.0.0, so the second octet is interesting and the block size is 8. Multiples of 8: 16, 24. The largest not above 20 is 16. The network is 10.16.0.0 and the broadcast 10.23.255.255. With 19 host bits, this subnet holds 524,286 hosts.

At the other extreme, a link between two routers needs only two addresses. Take 192.168.5.10/30. The block size is 4, the largest multiple not above 10 is 8, so the network is 192.168.5.8, the broadcast 192.168.5.11, and the two hosts .9 and .10. Many networks now use /31 for such links instead, following RFC 3021, which saves two addresses per link.

Dividing a network to order

Scenarios also run the other way: you are given a block and a requirement.

By number of subnets. Split 192.168.100.0/24 into at least six equal subnets, each as large as possible. Borrowing n host bits makes 2 to the power n subnets: 2 bits give 4, too few; 3 bits give 8. So the prefix becomes /27, mask 255.255.255.224, block size 32. The eight subnets start at .0, .32, .64, .96, .128, .160, .192 and .224, each with 30 hosts.

By hosts per subnet. A department needs 50 hosts. Find the smallest h with 2 to the power h minus 2 of at least 50: 5 host bits give 30, too few; 6 give 62. So the department needs a /26. Notice that the requirement always rounds up, never down.

Old documents warn against using the first subnet (subnet zero) and the last (the all-ones subnet). That rule came from RFC 950 in 1985. RFC 1878, ten years later, called the practice obsolete, and Cisco's subnetting guide explains how its routers allow subnet zero. On the exam, treat every subnet as usable unless a question says otherwise.

The core of it: for subnets, borrow the bits whose power of 2 first reaches the number required; for hosts, keep the host bits whose power of 2 minus 2 first reaches the number required.

Practice until it is boring

Work each of these on paper before looking at the answers below. Aim for under a minute each, then under thirty seconds.

1. 192.168.1.77/26
2. 10.0.5.130/25
3. 172.20.99.14/22
4. 192.168.50.200/29. Is .200 a usable host?
5. 10.200.17.9/12
6. 192.168.7.63/27. Can a server use this address?

For exam day, practise writing the first table in this lesson, prefix, mask value, block size and hosts, from memory in under two minutes. On the online exam you will rebuild it on the digital whiteboard.

Common misconceptions

• "The broadcast address always ends in 255." Only when the subnet's block ends at the octet boundary. 192.168.10.96/27 broadcasts on .127; 172.16.32.0/20 broadcasts on 172.16.47.255.
• "A /27 has 32 hosts." It has 32 addresses and 30 usable hosts. Subtract the network and broadcast addresses, except on /31 point-to-point links.
• "If an address ends in .0 it must be a network address." In a /22 such as 172.20.96.0/22, 172.20.97.0 is an ordinary host. Network addresses are defined by the mask, not by a zero.
• "Hosts on the same switch are always on the same subnet." The switch connects them at layer 2; the mask decides whether they consider each other local, as the camera and recorder showed.

What to remember

• Prefix length counts the mask's ones; mask octet values run 128, 192, 224, 240, 248, 252, 254, 255.
• Block size is 256 minus the mask value in the interesting octet; subnets start at its multiples.
• Network: round down to a multiple. Broadcast: next multiple minus 1, with 255s to the right. Hosts: everything between.
• Usable hosts are 2 to the power h minus 2; /30 gives 2 for links, /31 gives 2 on point-to-point links under RFC 3021, /32 is one host.
• For n subnets, borrow bits until 2 to the power bits reaches n; for h hosts, keep host bits until 2 to the power bits minus 2 reaches h.
• All subnets, including subnet zero, are usable in modern practice.

Sources

1. Mogul, J., and Postel, J. (1985). Internet standard subnetting procedure (RFC 950). RFC Editor. rfc-editor.org
2. Fuller, V., and Li, T. (2006). Classless Inter-domain Routing (CIDR): The Internet address assignment and aggregation plan (RFC 4632). RFC Editor. rfc-editor.org
3. Retana, A., White, R., Fuller, V., and McPherson, D. (2000). Using 31-bit prefixes on IPv4 point-to-point links (RFC 3021). RFC Editor. rfc-editor.org
4. Pummill, T., and Manning, B. (1995). Variable length subnet table for IPv4 (RFC 1878). RFC Editor. rfc-editor.org
5. Cisco Systems. (2023). Configure IP addresses and unique subnets for new users (Document ID 13788). cisco.com
6. CompTIA. (2023). CompTIA Network+ N10-009 certification exam objectives (Document version 6.0), objective 1.7. CompTIA (PDF)

One /24, seven networks

A small company is given 192.168.20.0/24, 256 addresses, and asked to build seven networks from it: Sales needs 100 hosts, Engineering 50, Support 25, Management 10, and three router-to-router WAN links need 2 addresses each. Can it be done, and how?

Try the method from Lesson 10 first. Equal subnets must be big enough for Sales, so each would be a /25 with 126 hosts. A /24 holds only two /25s, and seven networks are needed. Go the other way and pick /27s, 30 hosts each: eight subnets, enough in number, but Sales cannot fit 100 hosts into 30. Fixed-length subnetting fails both ways. The fix is to give each network its own mask, sized to its need. Cisco's subnetting guide describes this as variable length subnet masks, VLSM, which use different masks for each subnet so that address space is used efficiently.

The VLSM procedure

1. List the requirements, largest first. Sorting matters: big blocks have the strictest alignment, so place them while the space is empty.
2. Size each one. Choose the smallest prefix whose usable hosts, 2 to the power h minus 2, meet the need.
3. Place each one at the next free address that is a multiple of its own block size. A /26 (block 64) may start only at .0, .64, .128 or .192; a /27 (block 32) only at multiples of 32.
4. Record the network, broadcast and host range, then continue from the next free address.

Now solve the company's problem.

Every subnet starts on a multiple of its block size, none overlap, and 192.168.20.252/30 is left free for a fourth link. All seven networks fit, with 128 + 64 + 32 + 16 + 4 + 4 + 4 = 252 addresses used.

Bottom line: VLSM sizes each subnet to its need; place the largest first, each on a multiple of its own block size, and the pieces fit without overlapping.

When one input changes

Suppose Engineering grows from 50 hosts to 70. A /26 holds only 62, so Engineering now needs a /25. Sales already holds 192.168.20.0/25, and Engineering takes 192.168.20.128/25. The /24 is now full, and Support, Management and the WAN links have nowhere to go. The design has to change: request another block, move the WAN links into a separate range, or renumber from a larger private block such as 10.0.0.0/8. Small changes in host counts can push a subnet across a power-of-two boundary and double its size, so good plans leave room to grow.

The overlap error, and how to catch it

The most damaging VLSM mistake is an overlap. An administrator assigns 10.1.1.64/26 to one VLAN and later 10.1.1.96/27 to another. The /26 runs from .64 to .127, so the /27 sits entirely inside it. Routers now hold two routes for the same addresses, and hosts at .97 to .126 may be reachable from one side and not the other. The check is the alignment rule in reverse: for any new subnet, work out its range and confirm it does not fall inside an existing one. A subnet whose start address is not a multiple of its block size, such as a /26 starting at .96, is never valid; it reveals that the planner was counting addresses rather than blocks.

Summarizing: one route for many networks

VLSM divides a block; summarization combines blocks. RFC 4632's classless routing plan exists largely to allow this aggregation: a provider that announces one short prefix instead of hundreds of long ones keeps routing tables smaller. Inside a company, a branch whose networks all fall under one summary can be reached through a single route.

A branch uses the eight networks 192.168.16.0/24 to 192.168.23.0/24. Find the bits they share. The first two octets are identical. In the third octet, 16 is 00010000 and 23 is 00010111: the first five bits, 00010, are common and the last three vary. That makes 16 + 5 = 21 common bits, so the summary is 192.168.16.0/21. The block-size view confirms it: a /21 has block size 8 in the third octet, and 16 is a multiple of 8, so 192.168.16.0/21 covers exactly 16 to 23.

Now a range that will not summarize neatly: 192.168.10.0/24 to 192.168.17.0/24, also eight networks. They do not start on a multiple of 8, so no single /21 covers exactly them; 192.168.8.0/21 would cover 8 to 15, including two networks that belong elsewhere. Covered exactly, they need three routes: 192.168.10.0/23, 192.168.12.0/22 and 192.168.16.0/23. Summaries work cleanly only when the addresses were planned in aligned, power-of-two groups, which is a reason to design addressing with summarization in mind.

The wrong mask in the wild

Objective 5.3 lists an incorrect subnet mask as a common fault, and its symptoms follow directly from the local-or-remote test in Lesson 3. Two cases cover most tickets.

• Mask too wide. A host at 192.168.20.10 is given 255.255.0.0 instead of /25. It now believes 192.168.20.200, which really sits in another VLAN behind the router, is local. It sends ARP requests for .200 that no one on its segment answers, so it cannot reach .200, while the internet, clearly remote even under the wrong mask, still works through the gateway.
• Mask too narrow. A host at 192.168.20.10 is given /28 (.0 to .15) on a network that is really /25. It treats .100, which is on its own segment, as remote and sends to the gateway. If the gateway is .126, outside the host's imagined /28, the host cannot even reach its gateway, and everything off the first 16 addresses fails.

The tell is partial reachability that follows address boundaries. When some hosts on the same segment work and others do not, compare every device's mask with the documented design before suspecting cables.

Keeping the plan: IP address management

A VLSM plan that lives in one person's head or an old spreadsheet will eventually overlap. Objective 3.1 lists IP address management (IPAM) among the documentation an organization keeps. Microsoft describes its IPAM feature as an integrated suite of tools for planning, deploying, managing and monitoring IP address infrastructure, including discovering the DHCP and DNS servers on a network. Whatever the tool, record for every subnet its prefix, purpose, VLAN, gateway, DHCP scope and owner, and check new allocations against it. Lesson 22 returns to IPAM as part of documentation.

Subnetting at exam speed

Under time pressure, three habits help. Write your chart first: prefix, mask value, block size, hosts, for /24 to /32. Answer hosts-to-prefix questions with a short ladder: 2, 6, 14, 30, 62, 126, 254 usable hosts for /30 down to /24. And always check alignment: a start address must be a multiple of the block size, which also makes many wrong options impossible at a glance.

Common misconceptions

• "In VLSM you can place subnets in any order." Placing small subnets first scatters them and can leave no aligned space for a large one. Largest first avoids that.
• "A subnet can start at any free address." It must start on a multiple of its own block size; otherwise it is not a valid subnet at all.
• "Any group of eight consecutive /24s summarizes to a /21." Only if the first one starts on a multiple of 8 in that octet.
• "A wrong mask breaks everything at once." It usually breaks only some destinations, which is exactly why it is easy to misdiagnose.

The takeaway

• VLSM: sort largest first, choose the smallest prefix that fits, place on a multiple of the block size, record, repeat.
• Growth that crosses a power of two doubles a subnet; plan headroom.
• Overlaps come from ignoring alignment; check every new range against the plan.
• Summarize by counting shared leading bits; 192.168.16.0 to 192.168.23.0 is 192.168.16.0/21, but unaligned ranges need several routes.
• Wrong masks cause partial reachability: too wide hides routers, too narrow hides neighbours and sometimes the gateway.
• Track every allocation in IPAM.

Sources

1. Cisco Systems. (2023). Configure IP addresses and unique subnets for new users (Document ID 13788), sections on VLSM and CIDR. cisco.com
2. Fuller, V., and Li, T. (2006). Classless Inter-domain Routing (CIDR): The Internet address assignment and aggregation plan (RFC 4632). RFC Editor. rfc-editor.org
3. Pummill, T., and Manning, B. (1995). Variable length subnet table for IPv4 (RFC 1878). RFC Editor. rfc-editor.org
4. Braden, R. (Ed.). (1989). Requirements for Internet hosts: Communication layers (RFC 1122), section 3.3.1.1. RFC Editor. rfc-editor.org
5. Microsoft. (n.d.). IP Address Management (IPAM) [Windows Server documentation]. Microsoft Learn. learn.microsoft.com
6. CompTIA. (2023). CompTIA Network+ N10-009 certification exam objectives (Document version 6.0), objectives 1.7, 3.1 and 5.3. CompTIA (PDF)

The day the pool ran dry

On 3 February 2011, in Montevideo, the Number Resource Organization announced that the free pool of IPv4 addresses was fully depleted. IANA had just handed out its last five /8 blocks, one to each of the five regional internet registries: 102/8 to AfriNIC, 103/8 to APNIC, 104/8 to ARIN, 179/8 to LACNIC and 185/8 to the RIPE NCC. The registries kept distributing what they held for some years, but the central supply of the 4.3 billion addresses that 32 bits allow was gone.

The engineers had seen it coming. The replacement, IPv6, was specified in the 1990s; its current standard, RFC 8200 from 2017, opens its list of changes with the reason: IPv6 increases the IP address size from 32 bits to 128 bits. That is about 3.4 times 10 to the 38th addresses, enough to give every subnet on earth more addresses than the whole IPv4 internet. Objective 1.8 lists this as IPv6's first purpose, mitigating address exhaustion. The harder problem, which the rest of this lesson follows, is how a world built on IPv4 moves to IPv6 without a day on which everything is switched over.

Writing a 128-bit address

An IPv6 address is written as eight groups of four hexadecimal digits separated by colons, each group 16 bits. In full, an address looks like 2001:0db8:0000:0000:0000:ff00:0042:8329. RFC 5952 sets the rules for writing it compactly, and tools and the exam follow them.

1. Drop leading zeros in each group. 0db8 becomes db8; 0042 becomes 42; 0000 becomes 0.
2. Replace the longest run of all-zero groups with a double colon, once only, because two double colons would make the length ambiguous. If two runs are equally long, compress the first.
3. Do not use :: for a single zero group, and write the hexadecimal letters in lowercase.

So 2001:0db8:0000:0000:0000:ff00:0042:8329 becomes 2001:db8::ff00:42:8329. And 2001:0db8:0000:0001:0000:0000:0000:0001 becomes 2001:db8:0:1::1, because the run of three zero groups near the end is longer than the single zero group earlier. (Addresses beginning 2001:db8 are reserved for documentation, like 192.0.2.0/24 in IPv4.)

IPv6 prefixes use the same slash notation as IPv4. A standard subnet is a /64: the first 64 bits identify the network and the last 64 bits, the interface identifier, identify the host. RFC 4291 requires 64-bit interface identifiers for nearly all unicast addresses, so in IPv6 you never squeeze hosts into a subnet; you count subnets instead.

Key idea: an IPv6 address is eight hexadecimal groups; drop leading zeros, replace the longest zero run with :: once, and remember that a normal subnet is a /64 with a 64-bit interface identifier.

The address types, and the missing broadcast

RFC 4291 states plainly that there are no broadcast addresses in IPv6; multicast does that job. The types you must recognize are these.

Run ipconfig on Windows and you will almost certainly see a "Link-local IPv6 Address" beginning fe80, even on a network that has no IPv6 service. Every IPv6-enabled interface creates one automatically, because the protocol needs it to talk to its neighbours.

Getting an address without a server: SLAAC and NDP

IPv6 hosts can configure themselves. Stateless address autoconfiguration (SLAAC), defined in RFC 4862, works with the Neighbor Discovery Protocol of RFC 4861, which carries its messages in ICMPv6.

1. The host creates its link-local address from the fe80::/64 prefix and an interface identifier.
2. It runs duplicate address detection: a neighbour solicitation asking whether anyone already uses that address. Silence means the address is free.
3. It sends a router solicitation to the all-routers multicast group, or waits for the next periodic router advertisement.
4. The router advertisement carries the network's /64 prefix and says whether to use SLAAC, DHCPv6, or both. The host combines the prefix with an interface identifier to form a global address, checks it for duplicates, and uses the router as its default gateway.

Neighbor Discovery also replaces ARP: a host finds a neighbour's MAC address with a neighbour solicitation sent to a multicast address and receives a neighbour advertisement in reply. That is why filtering all ICMPv6 breaks IPv6 completely, a sharper version of the ICMP lesson from Lesson 7.

Where does the interface identifier come from? One older method, the modified EUI-64 format in RFC 4291, builds it from the 48-bit MAC address: insert ff:fe in the middle and invert the universal/local bit. The MAC 00:1a:2b:3c:4d:5e becomes 00:1a:2b:ff:fe:3c:4d:5e, and flipping the 0x02 bit of the first byte turns 00 into 02, giving the interface identifier 021a:2bff:fe3c:4d5e. On the prefix 2001:db8:acad:1::/64, the host's address is 2001:db8:acad:1:21a:2bff:fe3c:4d5e. Because that identifier follows the device everywhere, RFC 8981 defines temporary addresses with randomized interface identifiers that change over time, and most current operating systems use them for outgoing connections.

Key idea: SLAAC lets a host build its own address from a router-advertised /64 prefix after checking for duplicates; Neighbor Discovery over ICMPv6 replaces ARP, so ICMPv6 must never be blocked wholesale.

Living with two protocols

No one can switch the internet to IPv6 overnight, so objective 1.8 lists three ways the two coexist.

Walk through NAT64 once. A phone on an IPv6-only network asks its DNS64 server for the address of a site that only has an IPv4 address, say 192.0.2.33. DNS64 answers with a synthesized IPv6 address that embeds it: 64:ff9b::192.0.2.33, which the phone sees as 64:ff9b::c000:221. The phone sends IPv6 packets there; they route to the NAT64 gateway, which recognizes the prefix, extracts the IPv4 address, and translates each packet to IPv4 using one of its public IPv4 addresses. The phone never needs an IPv4 address of its own.

Key idea: dual stack runs both protocols everywhere, tunneling carries one protocol across a network of the other, and NAT64 with DNS64 lets IPv6-only clients reach IPv4-only servers.

IPv6 header changes worth knowing

RFC 8200 simplified the header. The IPv4 time-to-live field becomes the hop limit, decremented by 1 at each router. There is no header checksum. And routers never fragment IPv6 packets: fragmentation is performed only by the source, so path MTU discovery, and the ICMPv6 "packet too big" messages it depends on, are essential rather than optional.

Common misconceptions

• "An fe80 address means the host failed to get a real address." Every IPv6 interface has a link-local address by design. Only an IPv4 169.254 address signals a failure.
• "You can use :: twice to shorten an address further." RFC 5952 allows :: once, because two would make it impossible to know how many zero groups each one hides.
• "IPv6 has broadcast like IPv4." It has none; multicast groups such as all-nodes and all-routers do that work.
• "NAT64 lets IPv4-only clients reach IPv6 servers." Stateful NAT64 as defined in RFC 6146 is the other way round: IPv6-only clients reaching IPv4 servers.

Recap

• IANA's IPv4 free pool ran out on 3 February 2011; IPv6's 128-bit addresses remove the shortage.
• Write addresses compactly: drop leading zeros, one :: for the longest zero run, lowercase. Standard subnets are /64.
• Types: global unicast (2000::/3), unique local (fc00::/7), link-local (fe80::/10), loopback ::1, multicast ff00::/8, anycast; no broadcast.
• SLAAC builds an address from a router-advertised prefix after duplicate address detection; NDP over ICMPv6 replaces ARP; EUI-64 inserts ff:fe and flips the universal/local bit; temporary random identifiers protect privacy.
• Coexistence: dual stack, tunneling (protocol 41), NAT64 with DNS64.

Sources

1. Number Resource Organization. (2011, February 3). Free pool of IPv4 address space depleted. nro.net
2. Deering, S., and Hinden, R. (2017). Internet Protocol, version 6 (IPv6) specification (RFC 8200). RFC Editor. rfc-editor.org
3. Hinden, R., and Deering, S. (2006). IP version 6 addressing architecture (RFC 4291). RFC Editor. rfc-editor.org
4. Kawamura, S., and Kawashima, M. (2010). A recommendation for IPv6 address text representation (RFC 5952). RFC Editor. rfc-editor.org
5. Thomson, S., Narten, T., and Jinmei, T. (2007). IPv6 stateless address autoconfiguration (RFC 4862); Narten, T., Nordmark, E., Simpson, W., and Soliman, H. (2007). Neighbor discovery for IP version 6 (RFC 4861). RFC Editor. rfc-editor.org (SLAAC); rfc-editor.org (NDP)
6. Hinden, R., and Haberman, B. (2005). Unique local IPv6 unicast addresses (RFC 4193). RFC Editor. rfc-editor.org
7. Nordmark, E., and Gilligan, R. (2005). Basic transition mechanisms for IPv6 hosts and routers (RFC 4213). RFC Editor. rfc-editor.org
8. Bagnulo, M., Matthews, P., and van Beijnum, I. (2011). Stateful NAT64 (RFC 6146); Bagnulo, M., Sullivan, A., Matthews, P., and van Beijnum, I. (2011). DNS64 (RFC 6147). RFC Editor. rfc-editor.org (NAT64); rfc-editor.org (DNS64)
9. Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and Li, X. (2010). IPv6 addressing of IPv4/IPv6 translators (RFC 6052). RFC Editor. rfc-editor.org
10. Gont, F., Krishnan, S., Narten, T., and Draves, R. (2021). Temporary address extensions for stateless address autoconfiguration in IPv6 (RFC 8981). RFC Editor. rfc-editor.org
11. Internet Assigned Numbers Authority. (n.d.). Internet Protocol version 6 address space. iana.org

A short definition that stuck

In September 2011 Peter Mell and Timothy Grance of NIST published Special Publication 800-145, a short definition of cloud computing that the industry still quotes: five essential characteristics, three service models and four deployment models. Objective 1.3 uses that vocabulary, then adds the networking parts that cloud providers built on top of it: virtual private clouds, gateways, security groups and dedicated connections. This lesson defines the words first, then builds a cloud network step by step, the way you would in a provider's console.

The vocabulary, from NIST

The three service models differ in where the provider's responsibility stops and yours begins.

NIST's deployment models describe who the infrastructure is for. A public cloud is provisioned for open use by the general public. A private cloud is provisioned for exclusive use by a single organization, whether it runs on premises or off. A hybrid cloud is a composition of two or more distinct clouds bound together so that data and applications can move between them. (NIST adds a fourth, community cloud, shared by organizations with common concerns.)

Three more words from the objective come from NIST's essential characteristics. Multitenancy is part of resource pooling: the provider's resources serve many customers at once, with physical and virtual resources assigned and reassigned as demand changes. Elasticity means capabilities can be provisioned and released, sometimes automatically, to scale outward and inward with demand. Scalability is the broader ability to grow to handle more load. The difference the exam looks for: an elastic system also shrinks again when demand falls, and you stop paying for what you released.

The point: IaaS gives you the network to build, PaaS gives you a platform for your code, SaaS gives you a finished application; public, private and hybrid describe who shares the infrastructure; elasticity is scaling both out and back in with demand.

Step 1: create the virtual private cloud

Take a common design: a public web server and a private database for a small online shop, built in Amazon Web Services. AWS describes its Virtual Private Cloud as a logically isolated virtual network that you define, closely resembling a traditional network in your own data center. Microsoft Azure calls the same thing a virtual network, and other providers use similar names.

Start by choosing the VPC's address block. Use private space you will never need to route publicly and that does not overlap your office networks, because the two may be joined later: 10.0.0.0/16, for example. Everything from Lessons 9 to 11 applies unchanged.

Step 2: carve subnets

AWS defines a subnet as a range of IP addresses in your VPC that must reside in a single Availability Zone, one of the provider's separate data centers in a region. Create two:

• Public subnet 10.0.1.0/24 for the web server, which internet users must reach.
• Private subnet 10.0.2.0/24 for the database, which no one on the internet should ever reach directly.

What makes a subnet public or private is not its address. It is the route table attached to it, which the next two steps set up.

Step 3: attach an internet gateway

An internet gateway is the VPC component that allows communication between the VPC and the internet; AWS describes it as horizontally scaled, redundant and highly available. Attach one to the VPC, then give the public subnet's route table a default route, 0.0.0.0/0, pointing to it. Give the web server a public address, and it is now reachable, subject to the security rules in step 5.

Step 4: add a NAT gateway for the private subnet

The database must download security patches, yet must never accept a connection from outside. That is exactly what AWS's NAT gateway provides: instances in a private subnet can connect to services outside the VPC, but external services cannot initiate a connection with those instances. Place the NAT gateway in the public subnet, and give the private subnet's route table a default route pointing to the NAT gateway, not to the internet gateway. Lesson 18 explains the translation inside; for now, the key fact is that it allows outbound connections only.

Now change one input and watch the design fail. Move the web server into the private subnet and leave its security rule allowing HTTPS from anywhere. No one can reach it. The rule permits the traffic, but the private subnet's only default route leads to a NAT gateway, which never accepts inbound connections. A security rule cannot create a path that routing does not provide.

Step 5: write the security rules

Cloud networks filter traffic at two levels, and the two behave differently.

For the shop: the web server's security group allows inbound TCP 443 from anywhere. The database's security group allows its database port only from the web server's security group, so even another machine inside the VPC cannot reach it. Because security groups are stateful, neither needs a rule for the replies. If you add a stateless network ACL to a subnet as a second layer, remember that it judges every packet alone, so the replies to clients, which leave from port 443 toward the clients' temporary ports, need an outbound rule covering those ephemeral ports.

The point: routes decide whether a path exists; security groups (stateful, per instance) and network ACLs or security lists (per subnet, often stateless) decide whether traffic on that path is allowed.

Step 6: connect the office

The company wants its office network joined to the VPC. Objective 1.3 lists two options.

• VPN. An IPsec site-to-site tunnel from the office router to a VPN gateway in the cloud, built in hours across the ordinary internet. It is encrypted, but its performance depends on the internet path.
• Direct Connect. AWS's name for a dedicated connection: your network is linked to a Direct Connect location over a standard Ethernet fiber-optic cable, one end on your router and the other on an AWS router. Other providers sell the same idea under other names. It avoids the public internet and gives consistent performance, at higher cost and longer lead time.

Whichever you choose, the office and VPC address blocks must not overlap, which is why step 1 chose 10.0.0.0/16 with care.

Network functions virtualization

Notice that nothing in this design is a box you can touch. The internet gateway, the NAT gateway, the firewalls and any load balancer are software. That idea has a name. In October 2012 a group of network operators published a white paper through ETSI, the European standards body, calling for network functions virtualization: implementing network functions in software that runs on industry-standard servers and can be moved or instantiated wherever it is needed. Cloud networking is NFV at scale, and objective 1.2's virtual appliances are the same idea inside your own data center.

Common misconceptions

• "Security groups and network ACLs are interchangeable." AWS security groups are stateful and attach to instances; network ACLs are stateless and attach to subnets. Forgetting return rules on a stateless ACL is a classic outage.
• "A private subnet cannot reach the internet at all." With a NAT gateway it can open outbound connections; it simply cannot be reached from outside.
• "Allowing a port in a security group makes a server reachable." Only if a route exists. A server in a subnet with no route to an internet gateway stays unreachable, whatever its rules say.
• "Scalability and elasticity mean the same thing." Elasticity, in NIST's definition, includes releasing capacity as demand falls, often automatically.

What to carry forward

• Service models: IaaS (you run OS and up), PaaS (you run your code), SaaS (you use the application). Deployment: public, private, hybrid (and community).
• Multitenancy: many customers share pooled resources. Elasticity: scale out and back in with demand.
• A VPC is a logically isolated virtual network with your own address block and subnets.
• Internet gateway plus a 0.0.0.0/0 route makes a subnet public; a NAT gateway gives private subnets outbound-only access.
• Security groups: stateful, per instance. Network ACLs and security lists: per subnet, stateless in AWS's case.
• Connect sites by VPN across the internet or by a dedicated connection such as Direct Connect; avoid overlapping address blocks.
• NFV runs network functions as software on standard servers; cloud gateways and firewalls are NFV.

Sources

1. Mell, P., and Grance, T. (2011). The NIST definition of cloud computing (NIST Special Publication 800-145). National Institute of Standards and Technology. csrc.nist.gov
2. Amazon Web Services. (n.d.). What is Amazon VPC?; Connect to the internet using an internet gateway; NAT gateways [Amazon VPC User Guide]. docs.aws.amazon.com (VPC); docs.aws.amazon.com (internet gateway); docs.aws.amazon.com (NAT gateway)
3. Amazon Web Services. (n.d.). Control traffic to your AWS resources using security groups; Control subnet traffic with network access control lists [Amazon VPC User Guide]. docs.aws.amazon.com (security groups); docs.aws.amazon.com (network ACLs)
4. Amazon Web Services. (n.d.). What is Direct Connect? [Direct Connect User Guide]. docs.aws.amazon.com
5. Microsoft. (n.d.). Network security groups [Azure Virtual Network documentation]. Microsoft Learn. learn.microsoft.com
6. Oracle. (n.d.). Security lists [Oracle Cloud Infrastructure documentation]. docs.oracle.com
7. ETSI. (2012). Network functions virtualisation: An introduction, benefits, enablers, challenges and call for action [Introductory white paper, SDN and OpenFlow World Congress, Darmstadt]. portal.etsi.org

One command, every data center

On 4 October 2021, during routine maintenance, an engineer at Facebook issued a command intended to assess the availability of capacity on the company's global backbone. In the words of the engineering post Santosh Janardhan published the next day, it unintentionally took down all the connections in the backbone network, effectively disconnecting Facebook's data centers from one another and from the internet. The systems were designed to audit commands like that and stop mistakes, but a bug in the audit tool let this one through. Facebook, Instagram and WhatsApp were unreachable for hours.

That outage sits at the centre of an argument that runs through objective 1.8. Modern networks are increasingly controlled from the centre: software-defined controllers, cloud-delivered security, automation that pushes one configuration to thousands of devices. One side says this makes networks more consistent, more secure and faster to change. The other side says it concentrates failure, so that a single mistake travels everywhere at once. Both sides have evidence. This lesson sets out the technologies, then the dispute, then what would settle it.

The case for central control: software-defined networking

Every router and switch does two jobs. The data plane (forwarding plane) moves packets according to tables. The control plane decides what those tables should contain: routes, policies, paths. Traditionally each box runs both, and administrators configure each box separately. RFC 7426, an IRTF document from 2015, describes software-defined networking as an approach that makes networks programmable through open interfaces and separates the forwarding plane from the control plane. A central controller holds the control logic and programs many devices' forwarding planes at once.

The same idea applied to wide area links is SD-WAN. NIST's 2022 Guide to a Secure Enterprise Network Landscape, Special Publication 800-215, describes SD-WAN as removing the tight coupling between control and data planes so that policies such as access control, routing and application traffic prioritization can be specified centrally. Objective 1.8 names four SD-WAN features, and NIST's list maps onto them.

Zero-touch provisioning is the vivid one: a router is shipped unconfigured to a shop, a staff member plugs it in, it contacts the controller, proves its identity and downloads its full configuration. No engineer travels.

Why this matters: SDN and SD-WAN move the decisions (control plane) to a central controller that programs many devices' forwarding, which is what makes application-aware routing and zero-touch deployment possible.

VXLAN: stretching layer 2 over layer 3

Data centers hit a limit that Lesson 15 explains in detail: 802.1Q VLAN IDs are 12 bits, so a network can have at most 4,094 usable VLANs. RFC 7348, from 2014, calls that limit inadequate for large multi-tenant data centers. Its answer, Virtual Extensible LAN, wraps each Ethernet frame inside a UDP packet (destination port 4789 by default) and labels it with a 24-bit VXLAN Network Identifier, allowing up to 16 million segments. Because the encapsulated frames ride ordinary IP routing, VXLAN overlays layer 2 networks on top of a layer 3 network. That is the objective's "layer 2 encapsulation", and it is also how a layer 2 segment can be stretched between data centers over a routed link, the objective's "data center interconnect".

Zero trust: no trust by location

NIST's Zero Trust Architecture, Special Publication 800-207 from August 2020, states the core idea in its abstract: zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location. A laptop inside headquarters gets no more trust than one in a café. NIST's reasoning is a direct criticism of the perimeter model: once attackers breach the perimeter, further lateral movement is unhindered.

The tenets translate into the objective's three terms. Policy-based authentication: access is decided by dynamic policy using the requester's identity, the state of the device and other attributes. Authorization: access to each resource is granted per session, and access to one resource does not grant access to another. Least privilege access: each grant gives only what the task needs. Architecturally, a policy decision point evaluates each request and a policy enforcement point, such as a gateway in front of an application, carries out the decision.

SASE and SSE are how many organizations buy these ideas. NIST SP 800-215 notes that Gartner coined secure access service edge in 2019 for an architecture that converges networking and security functions and delivers them globally as a cloud service, reached through points of presence. Security service edge is the security half of that package without the WAN: Microsoft, for example, describes SSE as an identity-aware, cloud-delivered network perimeter, and markets its own SSE products under that category. SASE combines SD-WAN with SSE.

Why this matters: zero trust replaces "inside means trusted" with per-session, least-privilege decisions on every request; SASE and SSE deliver those controls as cloud services near the user.

Infrastructure as code: networks configured like software

The last part of objective 1.8 is about how configuration is produced. With infrastructure as code, the desired configuration of every device is written in files, kept in a repository and applied by automation tools rather than typed by hand. The objective's terms each name a practice.

• Playbooks, templates and reusable tasks. Ansible's documentation describes its playbooks as a repeatable, reusable, simple configuration management and multimachine deployment system. One template for an access switch builds the hundredth switch exactly like the first.
• Configuration drift and compliance. Drift is the slow divergence of devices from their intended state through manual edits. Ansible explains that most of its modules check whether the desired final state has already been achieved and do nothing if it has, so running a playbook again restores the intended state and reports what differed.
• Upgrades. Firmware upgrades can be rolled out by automation in batches, with checks after each batch.
• Dynamic inventories. When hosts come and go, as they do in a cloud, Ansible's documentation recommends a dynamic inventory that pulls the current host list from sources such as cloud providers or a configuration database, instead of a static file.

Source control is what makes code trustworthy. Version control records every change, who made it and why, and allows rollback. A central repository is the single agreed copy. Branching lets an engineer prepare a change without touching the production configuration. And conflict identification protects against two people changing the same thing: the Git book explains that if you changed the same part of the same file differently in the two branches being merged, Git cannot merge them cleanly and reports a merge conflict for a human to resolve.

Why this matters: infrastructure as code turns configuration into reviewed, versioned, repeatable files, which ends drift and makes every change traceable and reversible.

The dispute: consistency or concentrated risk?

The case for central, automated, zero trust networks rests on concrete evidence. Manual configuration drifts; templates do not. Perimeters fail, and NIST documents why: lateral movement after a breach. SD-WAN deploys branches without site visits. Each change goes through a repository, so it can be reviewed and reversed.

The case for caution rests on evidence just as concrete. Facebook's outage shows a central command reaching every data center at once, past a safety check that failed. NIST's own zero trust guide lists denial of service against the policy components as a threat: in a zero trust architecture resources cannot connect without the policy administrator's permission, so disrupting it can stop the enterprise. And NIST expects most organizations to run a hybrid of zero trust and perimeter-based security for years, adopting zero trust incrementally rather than in one leap.

What would settle it is not choosing a side but adding the controls that each side's evidence calls for. Test before production: Ansible's check mode runs a playbook and reports the changes it would make without making them. Review changes in branches before they merge. Roll out in stages, so a bad change hits five devices, not five thousand. Keep an out-of-band path to devices that does not depend on the network being changed, which Lesson 27 covers. Replicate policy engines, as NIST recommends, so that zero trust's decision point is not a single point of failure. Centralization is safe exactly to the degree that its mistakes are caught before they spread.

Common misconceptions

• "In SDN every packet goes through the controller." The controller programs the forwarding tables; devices still forward packets themselves at line rate.
• "Zero trust means trusting no one, so nobody can get in." It means trust is never assumed from location. Users and devices are verified and authorized for each resource, then allowed in with least privilege.
• "VXLAN is just a bigger VLAN number on the same switch." It encapsulates frames in UDP and carries them over routed IP networks, which is why it can span data centers.
• "Automation removes human error." It removes typing errors and drift, but it also multiplies the reach of a wrong command. Review, testing and staged rollout are what contain that risk.

What you now know

• SDN separates the control plane (decisions) from the data plane (forwarding) and centralizes control; RFC 7426 describes it.
• SD-WAN: transport agnostic, application aware, central policy, zero-touch provisioning.
• VXLAN: Ethernet in UDP 4789, 24-bit VNI for about 16 million segments, layer 2 overlays across layer 3 and between data centers.
• Zero trust (NIST SP 800-207): no implicit trust by location; per-session, policy-based, least-privilege access via decision and enforcement points. SASE converges SD-WAN and cloud security; SSE is the security part.
• Infrastructure as code: playbooks and templates, drift correction, automated upgrades, dynamic inventories; source control adds versioning, a central repository, branching and conflict detection.
• Central automation is powerful and dangerous; check mode, review, staged rollout, out-of-band access and redundant policy engines contain the danger.

Sources

1. Janardhan, S. (2021, October 5). More details about the October 4 outage. Engineering at Meta. engineering.fb.com
2. Haleplidis, E. (Ed.), et al. (2015). Software-defined networking (SDN): Layers and architecture terminology (RFC 7426). RFC Editor. rfc-editor.org
3. Chandramouli, R. (2022). Guide to a secure enterprise network landscape (NIST Special Publication 800-215). National Institute of Standards and Technology. csrc.nist.gov
4. Mahalingam, M., et al. (2014). Virtual eXtensible Local Area Network (VXLAN) (RFC 7348). RFC Editor. rfc-editor.org
5. Rose, S., Borchert, O., Mitchell, S., and Connelly, S. (2020). Zero trust architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. csrc.nist.gov
6. Microsoft. (n.d.). What is Global Secure Access? Microsoft Learn. learn.microsoft.com
7. Ansible project. (n.d.). Ansible playbooks and Working with dynamic inventory. Ansible documentation. docs.ansible.com (playbooks); docs.ansible.com (dynamic inventory)
8. Chacon, S., and Straub, B. (2014). Pro Git (2nd ed.), section 3.2, Basic branching and merging. Apress; online edition at git-scm.com. git-scm.com

One switch, three networks

A 48-port switch on the second floor of a clinic serves three kinds of device: reception PCs, IP phones on every desk, and a medical-imaging workstation. Clinic policy says the workstation must not share a network with anything else. Buying three switches would work, and waste ports, power and money. The alternative is to divide one switch into three separate networks. That is a virtual LAN. Objective 2.2 asks you to configure VLANs "given a scenario": the database, the ports, the trunks, the native and voice VLANs, and the virtual interface that lets a switch route.

Cisco's configuration guide defines a VLAN as a switched network that is logically segmented by function, project team or application, with packets forwarded and flooded only to stations in the same VLAN. In Lesson 3's terms, each VLAN is its own broadcast domain. A PC in VLAN 10 never sees an ARP broadcast from VLAN 20, even on the next port of the same switch. The two can exchange traffic only through a router or a layer 3 switch.

The procedure below builds the clinic's design on a Cisco-style command line, the same commands you can type in Packet Tracer. Each step ends with a check.

Step 1: create the VLANs in the VLAN database

1. vlan 10, then name RECEPTION
2. vlan 20, then name VOICE
3. vlan 30, then name IMAGING

On Cisco switches, normal-range VLANs, IDs 1 to 1005, are stored in a file called vlan.dat, the VLAN database. Extended-range IDs run from 1006 to 4094. VLAN 1 exists from the start as the default VLAN and cannot be deleted, and every port belongs to it until you say otherwise. Check with show vlan brief, which lists each VLAN and the ports assigned to it.

Step 2: make the access ports

An access port belongs to exactly one VLAN and sends and receives untagged frames; the device plugged into it has no idea VLANs exist. For the imaging workstation on port 15:

1. interface GigabitEthernet1/0/15
2. switchport mode access
3. switchport access vlan 30

Run show vlan brief again and port 15 now appears under VLAN 30. Changing one input shows why this check matters. Forget the switchport access vlan line on a reception port and it stays in VLAN 1. The PC plugged into it sends its DHCP request into VLAN 1, where no DHCP server answers. It ends up with a 169.254 address from Lesson 9, while the PC on the next port works perfectly.

What matters here: a VLAN is a broadcast domain created in software. Access ports carry one VLAN untagged, and a port left in VLAN 1 by mistake is a classic reason one desk gets no address.

Step 3: add the phones with a voice VLAN

Each reception desk has one network jack, with the phone plugged into it and the PC plugged into the phone. The phone's traffic must go into VLAN 20 and the PC's into VLAN 10, through a single switch port. Cisco's voice VLAN feature exists for exactly this.

1. interface GigabitEthernet1/0/2
2. switchport mode access
3. switchport access vlan 10 for the PC's data
4. switchport voice vlan 20 for the phone

Cisco's guide describes how it works. The switch sends Cisco Discovery Protocol messages that instruct the attached phone to send its voice traffic in 802.1Q frames tagged for the voice VLAN, by default with a priority of 5. Untagged traffic from the PC behind the phone passes through unchanged and lands in the data VLAN. Many other vendors' phones learn the voice VLAN through LLDP-MED, the media extensions to the Link Layer Discovery Protocol, which Lesson 35 covers.

Step 4: build the trunk to the next switch

The clinic's other floor has its own switch with the same three VLANs. The link between the two switches must carry all three. That link is a trunk, which Cisco defines as a point-to-point link that carries several VLANs. To keep the VLANs apart on one cable, each frame gets an IEEE 802.1Q tag: four bytes inserted after the source MAC address.

Twelve bits give 4,096 values; 0 and 4095 are reserved, which leaves the 4,094 usable IDs you saw in step 1, and the limit that VXLAN was invented to escape in Lesson 14.

1. interface GigabitEthernet1/0/48
2. switchport mode trunk
3. switchport trunk native vlan 999
4. switchport trunk allowed vlan 10,20,30,999

Two lines need explaining. The native VLAN is the one VLAN whose frames cross the trunk untagged. Cisco's guide notes that it is VLAN 1 by default and that untagged frames arriving on a trunk are placed into it. Good practice moves it to an unused VLAN, here 999, configured identically on both ends. A native VLAN mismatch between the two ends can, as Cisco warns, cause spanning-tree loops, and it silently mixes traffic between two VLANs. Lesson 29 shows how attackers abuse the native VLAN in VLAN hopping. The allowed VLAN list matters because, by default, all VLANs are allowed on a trunk: list only the VLANs this link should carry.

One more default deserves attention. Cisco's guide gives the default mode of its Ethernet interfaces as dynamic auto, meaning the port negotiates with its neighbour about becoming a trunk. Set trunk and access modes explicitly, as above, so that nothing is left to negotiation. Check with show interfaces trunk, which lists each trunk, its native VLAN and the VLANs it is allowed and actively forwarding.

What matters here: trunks carry many VLANs by tagging frames with a 12-bit VLAN ID. The native VLAN crosses untagged, must match at both ends, and should not be VLAN 1. Prune the allowed list to what the link needs.

Step 5: give a VLAN a layer 3 interface

The VLANs are now separate, and reception PCs must still reach the imaging server's results portal. Something has to route between VLANs. On a multilayer switch the answer is a switch virtual interface, a logical interface that represents a whole VLAN. Cisco's guide notes that SVIs must be explicitly configured and assigned an IP address.

1. interface vlan 10, then ip address 10.10.10.1 255.255.255.0, then no shutdown
2. interface vlan 30, then ip address 10.10.30.1 255.255.255.0, then no shutdown
3. ip routing to let the switch route between its SVIs

Each SVI address becomes the default gateway for its VLAN's hosts. A layer 2 switch with no routing still uses one SVI, usually in a management VLAN, purely to give the switch itself an address for SSH. Lesson 18 shows the other way to route between VLANs, a router with one subinterface per VLAN on a trunk.

The three port types side by side

Common misconceptions

• "Devices in different VLANs can talk because they share a switch." VLANs are separate broadcast domains. Traffic between them needs a router or an SVI on a layer 3 switch.
• "The native VLAN is tagged like the others." It is the one VLAN sent untagged on an 802.1Q trunk, which is why both ends must agree on it.
• "A trunk carries only the VLANs you configured." By default every VLAN is allowed; restrict the list yourself.
• "A desk phone needs a trunk port." An access port with a voice VLAN carries the phone's tagged voice traffic and the PC's untagged data.

The short version

• A VLAN is a separate broadcast domain on shared switches; create it in the VLAN database (normal range 1 to 1005, extended to 4094; VLAN 1 is the undeletable default).
• Access ports carry one untagged VLAN; a port forgotten in VLAN 1 strands its device.
• Voice VLANs let a phone and PC share a port: tagged voice, untagged data.
• Trunks tag frames with 802.1Q (TPID 0x8100, 3-bit priority, 12-bit VLAN ID); the native VLAN goes untagged and must match on both ends; prune the allowed VLAN list; set modes explicitly.
• SVIs give VLANs IP interfaces for routing or management.
• Verify with show vlan brief and show interfaces trunk.

Sources

1. Cisco Systems. (n.d.). Configuring VLANs, in VLAN configuration guide, Cisco IOS XE 17.12.x (Catalyst 9300 switches). cisco.com
2. Cisco Systems. (n.d.). Configuring VLAN trunks, in the same guide. cisco.com
3. Cisco Systems. (n.d.). Configuring voice VLANs, in the same guide. cisco.com
4. Wireshark Foundation. (n.d.). VLAN. Wireshark Wiki. wiki.wireshark.org
5. Mahalingam, M., et al. (2014). Virtual eXtensible Local Area Network (VXLAN) (RFC 7348), section 3 on the 4,094-VLAN limit. RFC Editor. rfc-editor.org
6. CompTIA. (2023). CompTIA Network+ N10-009 certification exam objectives (Document version 6.0), objective 2.2. CompTIA (PDF)

A spare cable and a dead floor

A spare patch cable with both ends plugged into two wall jacks in the same meeting room can stop an entire floor's network within seconds. Both jacks lead to the same switch, so the cable makes a loop. The next broadcast, perhaps an ARP request, leaves the switch through one jack, comes back through the other, and is flooded again, out of every port including the loop. Each copy spawns more copies. Ethernet frames carry no time-to-live, so nothing ever discards them. Within moments the links are saturated with copies of the same broadcasts, every device on the floor must process them, and the switch's MAC table flips back and forth as it sees the same source addresses arriving on two ports. This is a broadcast storm.

Engineers build loops on purpose, too: two links between switches so that one can fail without cutting anyone off. The question this lesson answers, under objective 2.2, is how to have redundant links without storms, and then how to tune the links themselves: bundling them, setting speed and duplex, and choosing the frame size.

Problem 1: redundancy without loops, solved by spanning tree

The Spanning Tree Protocol lets switches discover loops and block just enough ports to break them, leaving one active path between any two points and keeping the blocked links ready as backups. Cisco Meraki's documentation describes its purpose plainly: to prevent layer 2 loops and broadcast storms while still supporting redundancy. Switches exchange messages called bridge protocol data units (BPDUs) and build the tree in three steps.

1. Elect a root bridge. Every switch has a bridge ID made of a priority value, 32768 by default, followed by its MAC address. The switch with the lowest bridge ID becomes the root. With every priority left at the default, the switch with the lowest MAC address wins, which is often the oldest, slowest switch in the building. Set a lower priority on the core switch so that it becomes root by design.
2. Choose root ports. Every other switch picks one root port: the port with the lowest-cost path to the root bridge. Faster links have lower costs.
3. Choose designated ports and block the rest. On each link, one port, the one with the best path to the root, becomes designated and forwards. Any port that is neither root nor designated is blocked.

The original standard, 802.1D, moves a port through blocking, listening, learning and forwarding states (plus disabled). Listening and learning each last the forward delay, 15 seconds by default, so Cisco's documentation describes a new link causing 30 seconds of disruption. Rapid Spanning Tree, 802.1w, merges disabled, blocking and listening into one discarding state, keeps learning and forwarding, and renames the blocking role as two roles, alternate and backup. Its proposal and agreement handshake does not wait for timers, so Cisco notes it can converge in a few hundred milliseconds. RSTP elects its root using the same criteria as 802.1D.

Ports that connect only to end devices should not wait at all. RSTP calls them edge ports, which Cisco notes correspond to its older PortFast feature: they go straight to forwarding when a PC is plugged in. Pair them with BPDU guard, which Lesson 30 covers, so an edge port that suddenly hears BPDUs, the sign of a switch or loop plugged in where a PC should be, shuts itself down. That would have saved the meeting room. Lesson 33 returns to spanning tree as a troubleshooting topic: wrong root bridge, unexpected port roles, ports stuck in a state.

Remember: spanning tree elects the lowest bridge ID as root, gives each switch one root port and each link one designated port, and blocks the rest; RSTP converges in milliseconds instead of 30 seconds, and edge ports skip the wait.

Problem 2: one uplink is not enough, solved by link aggregation

The floor's access switch has a single 1 Gbps uplink, and it is busy. Adding a second cable would just give spanning tree another link to block. Link aggregation bundles several physical links into one logical link, so spanning tree sees one link and all members carry traffic. Cisco calls the bundle an EtherChannel. Its configuration guide makes four points the exam likes.

• The open negotiation protocol is LACP, defined originally in IEEE 802.3ad. A port in active mode starts negotiation; a passive port only responds. Two passive ends never start, so the bundle never forms. PAgP is Cisco's proprietary alternative.
• All member ports must match: same speed and duplex, and the same VLAN or trunk configuration.
• Up to eight ports can be active in a bundle; LACP can hold more in standby.
• If a member link fails, its load is redistributed across the remaining links automatically.

The fourth point of design is load balancing, and it surprises people. The switch hashes address fields of each frame to choose a member link, so all frames of one conversation take the same link; Cisco notes that packets from the same host use the same port in the channel. Four bundled 1 Gbps links can carry four conversations at 1 Gbps each, but a single file copy between two hosts still tops out at about 1 Gbps.

Remember: LACP bundles matching links into one logical link that spanning tree will not block; at least one end must be active, and each flow is hashed onto one member, so the bundle adds capacity, not single-flow speed.

Problem 3: a slow server with errors, solved by fixing duplex

A file server's switch port shows climbing CRC errors and late collisions, and transfers crawl. The server's network card was hard-set to 100 Mbps full duplex during a long-ago troubleshooting session; the switch port is left on auto-negotiation. Cisco's guide to switch and NIC compatibility explains the result: a manual full-duplex setting on one link partner results in a duplex mismatch, because the auto-negotiating side receives no negotiation and falls back to half duplex. The half-duplex side backs off when it sees the full-duplex side transmitting and records collisions; the full-duplex side never backs off, so frames are mangled and counted as CRC errors. Cisco lists the symptoms as slow performance, intermittent connectivity and data link errors, and advises checking for a duplex mismatch whenever FCS, CRC, alignment or runt counters increase.

The rule is simple: auto-negotiate on both ends, or hard-set both ends to the same speed and duplex. Never mix the two. On a switch, show interfaces displays the negotiated speed and duplex and the error counters; on Linux, ethtool shows the same for the server's card.

Problem 4: storage traffic that fails only when large, solved by matching the MTU

The standard Ethernet payload is at most 1,500 bytes, the maximum transmission unit from Lesson 3. Storage networks often raise it with jumbo frames, commonly to a 9,000-byte MTU, because, as Cisco's jumbo frame guide notes, larger frames can increase average throughput by cutting per-frame overhead. The catch is that every device in the layer 2 path must accept them. A switch port still set to 1,500 treats a 9,000-byte frame as an error and discards it, and a switch cannot fragment frames. The symptom is distinctive: pings and small requests work, and large transfers fail or hang. Cisco's guide adds a routing detail: when traffic is routed between VLANs through an SVI, the SVI's MTU must be raised too. Check the MTU on every hop: host, each switch port, SVI and storage array.

Remember: mismatched duplex shows up as late collisions and CRC errors on a slow link; mismatched MTU shows up as small traffic working and large traffic failing.

Common misconceptions

• "The most powerful switch automatically becomes root." The lowest bridge ID wins, and with default priorities that is the lowest MAC address, often an old switch. Set priorities deliberately.
• "Four 1 Gbps links in a bundle make one 4 Gbps connection." They add total capacity, but each flow is hashed onto one link.
• "Hard-coding speed and duplex on the server is always safer." Only if the switch end is hard-coded to match. Hard-coding one side against auto-negotiation creates the very mismatch it was meant to prevent.
• "Jumbo frames are a free speed boost." Only when every device in the path supports the same MTU; one 1,500-byte hop drops the large frames.

Putting it together

• Loops plus broadcasts make storms, because frames have no TTL. Spanning tree breaks loops by electing the lowest bridge ID as root and blocking non-root, non-designated ports.
• 802.1D: blocking, listening, learning, forwarding, with about 30 seconds to forward. RSTP: discarding, learning, forwarding, converging in milliseconds; edge ports (PortFast) forward immediately.
• LACP (802.3ad) bundles up to eight matching active links; active and passive modes; per-flow hashing.
• Duplex: both auto or both fixed. Mismatch symptoms: late collisions, CRC errors, slow links.
• MTU: 1,500 standard, jumbo around 9,000; every hop and SVI must match, or large frames are dropped.

Sources

1. Cisco Systems. (n.d.). Understand Rapid Spanning Tree Protocol (802.1w) (Document ID 24062). cisco.com
2. Cisco Meraki. (n.d.). Spanning Tree Protocol (STP) overview. Meraki documentation. documentation.meraki.com
3. Cisco Systems. (n.d.). Configuring EtherChannels, in Layer 2 configuration guide, Cisco IOS XE 17.12.x (Catalyst 9300 switches). cisco.com
4. Cisco Systems. (n.d.). Troubleshoot Catalyst switches to NIC compatibility issues (Document ID 17053). cisco.com
5. Cisco Systems. (n.d.). Configure jumbo/giant frame support on Catalyst switches (Document ID 24048). cisco.com
6. Wireshark Foundation. (n.d.). Sample captures (stp.pcap, lacp1.pcap.gz). Wireshark Wiki. wiki.wireshark.org

A confident diagnosis that is wrong

A network technician adds a static route for 10.1.0.0/16 to a branch router and writes in the ticket: "Traffic to 10.1.1.20 will now use the new static route, because static routes have an administrative distance of 1 and always beat OSPF." Ten minutes later a capture shows the traffic still leaving through the OSPF path. The technician concludes the router is broken. It is not. The diagnosis mixes up two separate decisions a router makes, and untangling them is the core of objective 2.1's route selection: administrative distance, prefix length and metric.

Here is the router's table, simplified from the format of a Cisco show ip route. The letter shows where each route came from; the bracket shows administrative distance and metric.

Where the reasoning fails: two decisions, not one

Cisco's guide to route selection separates the decisions cleanly. The first decides which routes are installed in the routing table: when two sources offer a route to the same prefix, the one with the lowest administrative distance wins, and among several paths from the same protocol, the lowest metric wins. The second decides which installed route forwards a packet, and there the guide is blunt: the longest prefix match always wins among the routes installed in the routing table. The internet's router requirements, RFC 1812, call this rule longest match.

Now trace 10.1.1.20 through the table. It matches 0.0.0.0/0 (every address does), 10.1.0.0/16 and 10.1.1.0/24. The /24 is the longest match, 24 bits against 16, so the packet follows the OSPF route. Administrative distance never entered the decision, because the static and OSPF routes are for different prefixes; both were installed side by side. The technician's rule, "static beats OSPF", is true only when both describe exactly the same prefix.

Change the destination and the answer flips. A packet to 10.1.2.5 matches the /16 and the default route but not the /24, so the static route wins on prefix length. A packet to 10.2.0.1 matches only the default route, 0.0.0.0/0, which is used exactly when nothing more specific exists.

In short: longest prefix match chooses among installed routes for every packet; administrative distance and metric only break ties between routes to the identical prefix.

Administrative distance: which source to believe

When two sources offer the same prefix, the router needs a ranking of trust. Cisco defines administrative distance as a value used to rank the trustworthiness of routing information sources, and publishes its defaults.

So if 10.1.1.0/24 arrived from both OSPF and internal EIGRP, EIGRP's 90 would beat OSPF's 110 and only the EIGRP route would be installed. A useful trick follows: a static route configured with a higher distance than the dynamic protocol, say 200, stays out of the table while OSPF provides the route and appears only if OSPF loses it. That is a floating static route, a cheap backup path.

Metric: which path within one protocol

Within a single protocol, the metric picks the best path, and each protocol measures differently. OSPF adds up interface costs, which by default favour faster links. EIGRP's composite metric, described in RFC 7868, is based by default on bandwidth and delay. BGP compares path attributes such as the length of the list of autonomous systems a route has crossed. If two OSPF paths tie on cost, RFC 2328 supports equal-cost multipath, sharing traffic across both.

In short: administrative distance ranks sources for the same prefix (connected 0, static 1, eBGP 20, EIGRP 90, OSPF 110, RIP 120, iBGP 200); the metric ranks paths within one protocol.

Static routes and the three dynamic protocols

A static route is typed by an administrator: "to reach this prefix, send to this next hop." It costs nothing to run and never changes by itself, which is its strength and its weakness. If the next hop fails, a static route keeps pointing at it. Static routes suit small networks, stub sites with one way out, and default routes toward an internet provider.

Dynamic routing protocols let routers tell one another what they can reach and recalculate when links fail. The exam names three.

An autonomous system is a network under one administration with a single routing policy toward the rest of the internet. OSPF and EIGRP are interior protocols, used inside one; BGP is the exterior protocol that joins them, and RFC 7938 from Lesson 6 shows it now running inside large data centers too.

In short: static routes are simple and blind to failures; OSPF (link state) and EIGRP (advanced distance vector) route inside an organization; BGP (path vector) routes between autonomous systems.

The full decision, in order

1. Each routing source offers its best paths, ranked by its own metric.
2. For each prefix offered by more than one source, the lowest administrative distance is installed.
3. For each packet, the router picks the installed route with the longest matching prefix.
4. If nothing more specific matches, the default route is used; if there is no default route, the packet is dropped and the router can return ICMP destination unreachable.

Common misconceptions

• "A lower administrative distance always wins." Only between routes to the identical prefix. A more specific prefix wins forwarding regardless of its source.
• "The default route is the router's preferred path." It is the path of last resort, used only when no more specific route matches.
• "Static routes adapt when a link fails." They do not; that is why dynamic protocols or floating static backups exist.
• "BGP is only for internet providers." Enterprises with two providers, and large data centers, run BGP too.

Where this leaves us

• Two decisions: administrative distance and metric decide what is installed; longest prefix match decides what forwards each packet.
• Cisco default AD: connected 0, static 1, eBGP 20, internal EIGRP 90, OSPF 110, IS-IS 115, RIP 120, external EIGRP 170, iBGP 200.
• Metrics: OSPF cost, EIGRP bandwidth and delay, BGP path attributes; equal costs can share load.
• Static routes suit stub sites and defaults; a floating static route with a high AD is a backup.
• OSPF is link state, EIGRP advanced distance vector, BGP path vector between autonomous systems on TCP 179.

Sources

1. Cisco Systems. (n.d.). Configure route selection for routers (Document ID 8651). cisco.com
2. Cisco Systems. (n.d.). Understand administrative distance (Document ID 15986). cisco.com
3. Baker, F. (Ed.). (1995). Requirements for IP version 4 routers (RFC 1812), section 5.2.4.3. RFC Editor. rfc-editor.org
4. Moy, J. (1998). OSPF version 2 (RFC 2328). RFC Editor. rfc-editor.org
5. Savage, D., Ng, J., Moore, S., Slice, D., Paluch, P., and White, R. (2016). Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP) (RFC 7868). RFC Editor. rfc-editor.org
6. Rekhter, Y. (Ed.), Li, T. (Ed.), and Hares, S. (Ed.). (2006). A Border Gateway Protocol 4 (BGP-4) (RFC 4271). RFC Editor. rfc-editor.org

One packet leaves home

Follow one packet. A laptop at home has the private address 192.168.1.23. Its owner opens a website at 203.0.113.80, and the laptop's TCP stack picks source port 51515 for the connection. The packet leaves with source 192.168.1.23:51515 and destination 203.0.113.80:443. As Lesson 9 showed, that source address cannot cross the internet: RFC 1918 addresses are not routed there, and the server would have no way to reply to it. Something at the edge must change it. That something is network address translation, and in a home router it is a specific kind, port address translation. This lesson follows the packet out and back, then follows two other journeys through objective 2.1: a gateway that survives its own failure, and a single router port serving several VLANs.

Out through PAT, and back again

RFC 3022, from 2001, describes the two forms of traditional NAT. Basic NAT maps addresses from one group to another. Network Address Port Translation, NAPT, maps many internal addresses and their TCP and UDP ports onto a single external address and its ports. Network+ calls NAPT port address translation (PAT), and it is why one public address can serve a whole household or office.

When the packet reaches the router, whose internet-facing address is 198.51.100.7, the router rewrites the source to 198.51.100.7 and a port of its own choosing, say 40001, and records the mapping.

The server replies to 198.51.100.7:40001. The router looks up 40001, finds 192.168.1.23:51515, rewrites the destination, and delivers the reply. Because each conversation gets its own translated port, two laptops visiting the same server at the same moment, rows one and two, never get each other's replies. The router must also fix the IP and TCP checksums after each rewrite, which is part of why NAT is real work for the device.

Now reverse the direction. Someone on the internet sends a packet to 198.51.100.7:8080. No row matches, so the router has nowhere to send it and drops it. RFC 3022 notes that NAPT lets internal hosts start sessions outward, while inbound sessions need a static mapping set up in advance. That is port forwarding, or static NAT: "send anything arriving on 198.51.100.7:8080 to 192.168.1.50:80." It is how a home game server or a small company's web server is published.

The upshot: PAT rewrites private source addresses and ports to one public address with unique ports and remembers each mapping, so replies find their way home; unsolicited inbound traffic is dropped unless a static mapping forwards it.

Where NAT fits, and where it hurts

NAT conserves public IPv4 addresses, which is why it spread after the address shortage in Lesson 12. It is not a security control in itself, although dropping unmatched inbound packets looks like one; the stateful firewall in the same box does the real filtering. It also breaks things that carry addresses inside the payload or check them end to end. Lesson 7 showed one: IPsec AH fails through NAT because its integrity check covers the addresses. IPv6, with its abundance of addresses, is designed to run without NAT at all.

The gateway that cannot fail

The next journey starts in an office. Every PC is configured with one default gateway, 10.10.10.1. If the router owning that address dies, every PC loses everything off its subnet, even though a second router sits in the same rack, because nobody can reconfigure two hundred PCs quickly. A first hop redundancy protocol (FHRP) solves this by giving the gateway address to a group of routers rather than to one.

The open standard is VRRP, the Virtual Router Redundancy Protocol, version 3 in RFC 5798 from 2010; Cisco's own HSRP, described in RFC 2281, works the same way in outline. Here is the sequence with VRRP.

1. Routers A (10.10.10.2) and B (10.10.10.3) join virtual router group 1, sharing the virtual IP 10.10.10.1. Hosts use the virtual IP as their gateway.
2. The routers elect a master by priority; the default priority is 100, and a router that actually owns the virtual address takes 255. Router A, set to priority 110, becomes master.
3. The master answers ARP for the virtual IP with a virtual MAC address, which for VRRP over IPv4 is 00-00-5E-00-01 followed by the group number. Hosts learn that MAC and send their traffic there.
4. The master sends advertisements, by default every second. If the backup hears none for the master down interval, three advertisement intervals plus a small skew, it declares the master down and takes over the virtual IP and virtual MAC.

Because the virtual MAC moves with the role, hosts keep sending to the same gateway address and the same MAC, and switches simply learn the MAC on a new port. Users see a pause of a few seconds, not an outage.

The upshot: an FHRP gives hosts a virtual gateway IP and MAC shared by several routers; the master answers for it, and a backup takes over when advertisements stop.

One router port, many VLANs

The last journey goes back to the clinic from Lesson 15, which has VLANs 10, 20 and 30 but no layer 3 switch. A router can route between them through a single physical port, a design often called router on a stick, by splitting that port into subinterfaces, one per VLAN, over an 802.1Q trunk. Cisco's example configuration looks like this.

1. interface gigabitEthernet 1.10, then encapsulation dot1Q 10, then ip address 10.10.10.1 255.255.255.0
2. interface gigabitEthernet 1.30, then encapsulation dot1Q 30, then ip address 10.10.30.1 255.255.255.0
3. For the native VLAN, Cisco's example adds the keyword native: encapsulation dot1Q 1 native

The switch port facing the router is a trunk. A frame from VLAN 10 arrives tagged 10, lands on subinterface .10, is routed, and leaves on subinterface .30 tagged 30. Each subinterface address is the default gateway for its VLAN. The design is cheap but squeezes all inter-VLAN traffic through one link twice, so busy networks move to SVIs on a layer 3 switch, as in Lesson 15. The tag number in the encapsulation command must match the VLAN on the switch; a mismatch strands that VLAN without a gateway.

Common misconceptions

• "NAT is a firewall." PAT drops unmatched inbound packets as a side effect, but filtering is the firewall's job, and port forwarding opens deliberate holes.
• "PAT gives each inside host its own public address." That is basic one-to-one NAT. PAT shares one public address and tells conversations apart by port.
• "With two routers, hosts should list both as gateways." Hosts use one gateway. An FHRP makes that one virtual address survive the loss of either router.
• "Subinterfaces are separate physical ports." They are logical divisions of one physical port, each bound to one VLAN tag.

Pulling it together

• Basic NAT maps addresses; PAT (NAPT, RFC 3022) maps many inside address and port pairs to one public address with unique ports.
• The translation table returns replies to the right host; inbound sessions need static mappings, also called port forwarding.
• NAT saves IPv4 addresses but is not a security control and breaks protocols such as IPsec AH.
• FHRPs (VRRP, HSRP, GLBP) share a virtual IP and MAC among routers; the master answers, and a backup takes over after missed advertisements.
• Router subinterfaces bind one VLAN tag each with encapsulation dot1Q, routing between VLANs over one trunk.

Sources

1. Srisuresh, P., and Egevang, K. (2001). Traditional IP network address translator (Traditional NAT) (RFC 3022). RFC Editor. rfc-editor.org
2. Nadas, S. (Ed.). (2010). Virtual Router Redundancy Protocol (VRRP) version 3 for IPv4 and IPv6 (RFC 5798). RFC Editor. rfc-editor.org
3. Li, T., Cole, B., Morton, P., and Li, D. (1998). Cisco Hot Standby Router Protocol (HSRP) (RFC 2281). RFC Editor. rfc-editor.org
4. Cisco Systems. (n.d.). Configure inter VLAN routing with the use of an external router (Document ID 14976). cisco.com
5. Aboba, B., and Dixon, W. (2004). IPsec-network address translation (NAT) compatibility requirements (RFC 3715). RFC Editor. rfc-editor.org
6. Rekhter, Y., et al. (1996). Address allocation for private internets (RFC 1918). RFC Editor. rfc-editor.org

Eleven channels, three usable

In the United States the 2.4 GHz Wi-Fi band holds eleven channels. Yet Cisco Meraki's channel planning guide points out that only three of them, 1, 6 and 11, can be used side by side without overlapping. Every other choice puts two networks partly on top of each other, where they interfere. That one fact explains much of wireless design. The radio spectrum is a shared, limited resource, and almost every Wi-Fi decision trades speed against range, channels against width, or convenience against interference. Objective 2.3 asks you to select and configure wireless devices "given a scenario", and objective 1.5 asks you to know the 802.11 standards. This lesson compares them side by side.

The 802.11 generations

The IEEE's 802.11 working group writes the standards; the Wi-Fi Alliance certifies products and, since Wi-Fi 6, gives the generations simple numbers. Intel's reference table gives the theoretical maximums below, and Cisco Meraki's Wi-Fi 7 technical guide adds the newest generation.

Two cautions. These maximums are theoretical, reached only with ideal conditions and the widest channels; real throughput is far lower and shared by every client on the channel. And a client and AP connect at the best standard both support. One old device does not drag a modern AP down to its own speed, though it does use more airtime per byte. Meraki's guide describes Wi-Fi 7's multi-link operation as aggregating multiple bands or channels at once, for higher throughput, lower latency and better reliability.

Worth holding on to: b and g live at 2.4 GHz, a and ac at 5 GHz, and n and ax use both. Wi-Fi 6E adds 6 GHz, and Wi-Fi 7 (802.11be) doubles the widest channel to 320 MHz.

Three bands compared

Higher frequencies generally fade faster with distance and walls, so more APs are needed for the same coverage, but each gets cleaner, wider channels. That is why dual-band and tri-band APs exist, and why band steering matters. Meraki's documentation describes band steering as detecting clients capable of 5 GHz operation and steering them to that frequency. That leaves the crowded 2.4 GHz band for devices that can use nothing else.

Channels, widths and the regulators

Channel width is a trade. Bonding adjacent 20 MHz channels into 40, 80, 160 or 320 MHz channels raises the peak rate. But it uses up the supply of separate channels, so nearby APs end up sharing one and taking turns. Meraki's guide notes that bonding in 2.4 GHz leaves a single non-overlapping 40 MHz channel, which is why 20 MHz is the usual choice there. Its Wi-Fi 7 guide warns that 320 MHz channels are so few that they suit only selected locations. In a dense office, narrower channels often deliver more total throughput than wide ones.

Governments decide which channels may be used and at what power, so the list differs by country; Meraki's guide notes that local governing authorities dictate the available channels. Part of the 5 GHz band is shared with radar. The 802.11h amendment, Cisco explains, brought two features for this: dynamic frequency selection (DFS) and transmit power control (TPC). An AP using a DFS channel must watch for radar. Cisco's overview says that a radio that detects radar must stop using the channel for at least 30 minutes, and Meraki's guide says the AP immediately picks a new channel. An AP that changes channel unexpectedly on a DFS channel has usually heard radar, real or apparent. TPC lets an AP limit its transmit power to local rules.

Worth holding on to: wider channels raise peak speed but leave fewer separate channels. Local regulators set the allowed channels and power, and 802.11h's DFS forces APs off 5 GHz channels where radar appears.

Names on the air: SSID, BSSID and ESSID

Meraki's documentation puts the relationship clearly. Several APs in an extended service set may advertise the same SSID, and the BSSID is the unique identifier that tells a client which AP it is associated with. It is also the address you see in wireless packet captures.

Network types

Antennas and access point models

Meraki's antenna guidance describes the basic split. An omnidirectional antenna radiates and collects signals in all 360 degrees in the horizontal plane, which suits a ceiling AP serving the people around it. A directional antenna, such as a patch or sector antenna, focuses energy in one direction. Meraki notes that directional antennas do not amplify the signal but provide passive gain that projects it farther one way. Use omni antennas to cover a space and directional antennas to cover a long corridor, a warehouse aisle or a point-to-point link between buildings.

Common misconceptions

• "Use the widest channel for the best performance." In a dense deployment wide channels leave too few separate channels, so APs share airtime. Narrower channels often win overall.
• "Any 2.4 GHz channel is as good as any other." Only 1, 6 and 11 avoid overlap in the US; channels between them interfere with both neighbours.
• "5 GHz is always better than 2.4 GHz." It offers more channels and speed but shorter range; 2.4 GHz still reaches farther through walls.
• "A directional antenna amplifies the signal." It concentrates the same energy in one direction, giving passive gain there and less coverage elsewhere.

Summing up

• Standards: b (11 Mbps, 2.4), a and g (54 Mbps, 5 and 2.4), n Wi-Fi 4 (both), ac Wi-Fi 5 (5 GHz), ax Wi-Fi 6 and 6E (adds 6 GHz), be Wi-Fi 7 (320 MHz channels, multi-link operation).
• 2.4 GHz reaches farther with three non-overlapping channels in the US; 5 and 6 GHz offer many more channels at shorter range; band steering moves capable clients up.
• Wider channels mean fewer separate channels; regulators set channels and power; 802.11h brings DFS and TPC.
• SSID is the name, BSSID the radio's MAC for that SSID, ESS the same SSID across many APs.
• Infrastructure, ad hoc, point to point, mesh; omni antennas cover areas, directional antennas aim; autonomous APs stand alone, lightweight APs follow a controller.

Sources

1. Intel. (n.d.). Different Wi-Fi protocols and data rates. Intel Support. intel.com
2. Cisco Meraki. (n.d.). Wi-Fi 7 (802.11be) technical guide. Meraki documentation. documentation.meraki.com
3. Cisco Meraki. (n.d.). Channel planning best practices. Meraki documentation. documentation.meraki.com
4. Cisco Meraki. (n.d.). Band steering. Meraki documentation. documentation.meraki.com
5. Cisco Systems. (n.d.). Overview on 802.11h, transmit power control and dynamic frequency selection (Document ID 200069). cisco.com
6. Cisco Meraki. (n.d.). Calculating Cisco Meraki BSSID MAC addresses; Frequently asked questions regarding Cisco Meraki antennas. Meraki documentation. documentation.meraki.com (BSSID); documentation.meraki.com (antennas)
7. IEEE 802.11 Working Group. (n.d.). Official IEEE 802.11 working group project timelines. grouper.ieee.org

Forty people, one password

A 40-person architecture firm runs its office Wi-Fi on one shared passphrase, printed on a card in the kitchen. On a Friday a designer leaves for a competitor, and her laptop still knows the passphrase. To lock her out, the firm must change the passphrase and then re-enter it on every laptop, phone and printer in the office. The office manager asks the obvious question: is there a better way? Two credible answers exist, each with real evidence behind it. This lesson sets them side by side and then settles the question for this firm. It finishes with guest access and site surveys, the rest of objective 2.3's security items and objective 3.1's survey.

The protocols underneath both answers

Wi-Fi security has evolved through several generations, and some of the old ones must simply never be used. Apple's recommended settings for Wi-Fi routers tell owners not to create or join networks that use deprecated protocols. The list names WEP in its various forms, WPA Personal, WPA/WPA2 mixed modes and anything with TKIP in its name. The live choices are WPA2 with AES and WPA3.

Two side notes matter in practice. WPA3 transition mode lets WPA2 and WPA3 clients share one SSID, which eases migration but leaves the WPA2 clients without WPA3's protections. And hiding the SSID is not a security setting at all. Apple's guidance says that hiding the network name doesn't conceal the network from detection or secure it against unauthorized access. It can even expose information about the networks a device has used.

Position 1: a strong shared passphrase is enough

The case for staying with a personal mode, upgraded to WPA3, rests on concrete points. There is nothing extra to run: no RADIUS server, no certificates, no directory integration. Every device, including printers and cheap smart displays, can join. And WPA3's SAE removes the classic weakness of WPA2-PSK. Under WPA2-PSK, an attacker who records a device joining the network can take the recording away and try passwords offline at leisure. Meraki's description of SAE, limiting password guesses and adding forward secrecy, means a recorded session cannot later be decrypted even if the password leaks. For a café or a household, Apple's advice is exactly this: WPA3 Personal, or WPA2/WPA3 Transitional for older devices.

Position 2: every user needs their own credentials

The case for enterprise authentication rests on different evidence: the Friday departure. With 802.1X, each person signs in with their own directory account, the access point passes the exchange to a RADIUS server, and the server decides. Disabling one account removes one person, immediately, without touching anyone else's device. The logs show which person connected when, which a shared password never can. WPA3-Enterprise adds mandatory Protected Management Frames, which Meraki notes protect against attacks such as denial of service, honeypots and eavesdropping. The costs are real too: a RADIUS server, careful certificate handling so that devices verify they are talking to the genuine server, and a plan for devices that cannot do 802.1X.

What settles it

The two positions are answering different questions. A shared password, even under SAE, cannot tell users apart. So the deciding facts are how many people share it, how often they leave, and whether the organization needs to know who connected. The architecture firm has forty staff, regular turnover and client files to protect. For it, the evidence points to WPA3-Enterprise, or WPA2-Enterprise where older devices require it, tied to the firm's existing directory. Printers and smart displays that cannot do 802.1X go on a separate WPA3-Personal network in their own VLAN, with firewall rules limiting what they can reach. A five-person office with no directory server might reasonably decide the other way.

So what?: personal modes share one secret, so removing one person means changing it for everyone. Enterprise modes give everyone their own credentials through 802.1X and RADIUS, at the price of running that infrastructure.

Guests: a separate network and a captive portal

Visitors need internet access and nothing else. The standard design gives them their own SSID mapped to their own VLAN, routed only to the internet, with client isolation so guests cannot reach one another. Many guest networks add a captive portal: a web page that appears before access is granted, to accept terms, enter a voucher code or sign in. RFC 8952, the IETF's captive portal architecture from November 2020, records how older portals work by forging DNS or HTTP responses to steer the browser. It explains why that breaks other applications and DNSSEC validation. Its architecture instead lets the network announce the portal through DHCP or router advertisements and an API, so devices know they are captive. You will still meet the older kind in hotels and cafés.

Before the first AP goes up: surveys and heat maps

Where should the access points go, and how many are needed? A site survey answers that, and objective 3.1 lists the survey and its heat map, a floor plan coloured by measured or predicted signal strength, as documentation a network should keep. Three kinds of survey are common.

Meraki's survey guidance adds two practical rules. Survey with the same AP model that will be installed. And remember that survey mode on its APs defaults to 20 MHz channels unless an RF profile changes it. Keep the heat maps with the network documentation; they become the baseline for every later complaint that the Wi-Fi is slow in the corner office, a problem Lesson 34 diagnoses.

Common misconceptions

• "A hidden SSID keeps attackers out." Apple's guidance is explicit that hiding the name neither conceals nor secures the network.
• "WPA3-Personal gives each user a separate identity." SAE protects the shared password from offline guessing, but everyone still shares it. Individual credentials need 802.1X.
• "A captive portal encrypts the guest network." It controls access; encryption comes from the Wi-Fi security mode.
• "A predictive survey makes an on-site survey unnecessary." Models estimate. A passive or active survey after installation confirms what the building actually does to the signal.

Looking back

• Never use WEP, WPA or TKIP. Choose WPA3 where clients support it, WPA2 with AES where they do not.
• Personal modes share one secret: WPA2-PSK, or WPA3's SAE, which resists offline dictionary attacks and provides forward secrecy.
• Enterprise modes use 802.1X and RADIUS for per-user credentials and per-user revocation; WPA3-Enterprise requires Protected Management Frames.
• Choose by headcount, turnover and accountability needs; isolate devices that cannot do 802.1X.
• Guests: separate SSID and VLAN, internet only, often with a captive portal (RFC 8952).
• Predictive, passive and active surveys produce the heat maps that guide AP placement and later troubleshooting.

Sources

1. Cisco Meraki. (n.d.). WPA3 encryption and configuration guide. Meraki documentation. documentation.meraki.com
2. Apple. (n.d.). Recommended settings for Wi-Fi routers and access points. Apple Support. support.apple.com
3. Larose, K., Dolson, D., and Liu, H. (2020). Captive portal architecture (RFC 8952). RFC Editor. rfc-editor.org
4. Kumari, W., and Kline, E. (2020). Captive-portal identification in DHCP and router advertisements (RAs) (RFC 8910). RFC Editor. rfc-editor.org
5. Cisco Meraki. (n.d.). Conducting site surveys with MR access points. Meraki documentation. documentation.meraki.com
6. CompTIA. (2023). CompTIA Network+ N10-009 certification exam objectives (Document version 6.0), objectives 2.3 and 3.1. CompTIA (PDF)

A walk through one building's network rooms

MIT's 2022 design standard for communications spaces is the document its architects must follow when they put up a building. It says that every floor's network room must sit within 295 feet of cable from the farthest communication outlet it serves. That number, about 90 metres, is the horizontal limit of the twisted-pair channel from Lesson 5 with room left for patch cords. It decides where the rooms go before anyone thinks about switches. This lesson follows a technician through a typical building, from where the internet arrives to the room on the top floor. Along the way it collects objective 2.4's physical installation factors: locations, racks, cabling, airflow, power, environment and security.

The basement: where the outside world comes in

The provider's fiber and copper enter the building at an entrance facility and run to the main distribution frame (MDF). MIT's standard reserves that name for spaces that serve multiple services, buildings or a whole campus; other organizations call the same room the main equipment room or the building's core. Here sit the edge router and firewall, the core or distribution switches, the provider's demarcation equipment, and the backbone cables that climb to every floor.

On each floor, or for each zone of a large floor, there is an intermediate distribution frame (IDF). It is a telecommunications room that connects the backbone to the horizontal cabling running out to desks and access points. MIT's standard asks for these rooms to be stacked vertically where possible, so that backbone cables run straight up through sleeves between them. The rooms should sit off a main corridor with doors opening outward. Because every desk must be within the cable limit of some IDF, a long or sprawling floor may need two.

The core of it: the MDF is where outside services and the backbone meet. IDFs bring the backbone within about 90 metres of every outlet, and that distance limit decides how many there are and where they go.

Inside the room: racks, panels and cable

The technician opens the IDF door with a card, because MIT's standard requires card access and a lockset on these rooms, and finds two racks. Rack-mounted equipment is a standard 19 inches wide. Its height is measured in rack units (U), each 1.75 inches (44.45 mm) under the EIA-310 rack standard. A typical access switch is 1U, and a rack-mount UPS takes several U. Rack size is chosen for the equipment plus growth, and enclosed cabinets can be locked where the room itself is shared.

Horizontal cables from the desks never plug straight into switches. They terminate on a patch panel, a row of jacks wired permanently at the back, and short patch cords connect panel ports to switch ports at the front. Fiber backbone strands terminate the same way on a fiber distribution panel. The point is to protect the permanent cabling: moving a desk to a different VLAN means moving one patch cord, never re-terminating a cable in the wall. Labelled panels, matching the cable maps of Lesson 22, make each cord traceable.

Airflow: which way the switch breathes

The US Department of Energy's best-practices guide for data center design describes the layout that most equipment rooms imitate. Racks stand in rows with alternating cold aisles, where equipment draws in air, and hot aisles, where it exhausts heat. Equipment is installed to achieve front-to-back airflow, and vacant rack spaces are blocked so hot exhaust cannot leak back to the front. A blanking panel in every empty U is cheap cooling.

Network switches complicate this, because their ports usually face the patch panels rather than the cold aisle. Manufacturers therefore sell the same switch with fans and power supplies in two airflow directions, port-side intake or port-side exhaust. Cisco's documentation for one of its data center switches lists separate fan part numbers for each. It requires every fan and power supply in the chassis to share one direction. Order the direction that matches how the rack faces. A port-side intake switch mounted with its ports toward the hot aisle breathes the exhaust of everything around it and runs hot.

The core of it: cold aisle in, hot aisle out, blanks in every gap, and switch airflow ordered to match the way the rack faces.

Power: UPS, PDU, load and voltage

A brief power cut should not reboot the network, so the room has an uninterruptible power supply (UPS). Schneider Electric's white paper on UPS types describes three common designs.

The DOE guide adds that double conversion is the most common data center design. Many units offer an "eco" mode that bypasses conversion when power is clean, raising efficiency. A UPS buys minutes, not hours; longer outages need a generator, which Lesson 24's disaster planning covers.

From the UPS, power reaches equipment through a power distribution unit (PDU), the rack's outlet strip. The DOE guide describes PDUs as distributing conditioned power to many pieces of equipment; some step a higher voltage, such as 208 V, down to 120 V. Two numbers must be planned. The power load is the sum of what every device draws. It must stay within the rating of the PDU, the UPS and the circuit feeding them, with headroom for growth. The voltage must match: equipment, PDU and receptacle must all agree, and MIT's standard, for example, specifies dedicated 120 V, 20 A circuits per rack. Dual power supplies in critical switches should be fed from two different PDUs on two circuits, so one failure leaves the switch running.

The room itself: heat, humidity and fire

Electronics fail early when they run hot or when the air is too dry or too damp. The DOE guide reproduces the ASHRAE thermal guidelines most operators follow. They recommend an inlet air temperature of 18 to 27 degrees C (64.4 to 80.6 degrees F), with humidity kept within limits. Wider allowable envelopes exist, which equipment can survive but which are not meant for normal operation. MIT's standard estimates 5,000 to 7,500 BTU of heat per equipment rack and notes that a UPS adds heat of its own. That is why network rooms need dedicated cooling rather than office air conditioning that switches off at night.

Fire protection has to stop a fire without destroying what it protects. MIT's standard asks for sprinkler heads in wire cages to prevent accidental operation. Many data centers use pre-action sprinklers, whose pipes hold compressed air until a separate detection system opens a valve, so a knocked sprinkler head alone does not flood the room. Others add a clean agent system, which Consulting-Specifying Engineer describes, following NFPA 2001, as an electrically nonconducting gaseous extinguishant that leaves no residue. NFPA 75 is the standard for protecting IT equipment spaces.

Common misconceptions

• "An IDF can be anywhere convenient." Its location is fixed by the cable-length limit to the farthest outlet, about 90 metres of horizontal cable.
• "All switches blow air the same way." Many models come in port-side intake and port-side exhaust versions; the wrong one for the rack's orientation overheats.
• "A UPS keeps the network running through any outage." It bridges minutes and smooths power problems. Long outages need a generator.
• "Any sprinkler will do in a server room." Pre-action and clean-agent designs exist precisely to avoid water damage from accidents and to protect electronics.

What to remember

• MDF: where outside services and the backbone meet. IDFs: within about 90 metres of every outlet, stacked where possible.
• 19-inch racks measured in 1.75-inch rack units; horizontal cable ends on patch panels, fiber on fiber distribution panels; rooms and cabinets locked.
• Hot aisle and cold aisle, front-to-back airflow, blanking panels; order port-side intake or exhaust to match the rack.
• UPS types: standby, line interactive, double conversion on-line (0 ms transfer). PDUs deliver power; keep the power load within ratings and match voltages; feed dual supplies from two circuits.
• ASHRAE recommends 18 to 27 degrees C inlet air; control humidity; plan for heat loads.
• Fire: caged sprinklers, pre-action systems, clean agents (NFPA 2001); NFPA 75 covers IT equipment spaces.

Sources

1. Massachusetts Institute of Technology. (2022). MIT design standards, Division 27: Communications. MIT Facilities. web.mit.edu (PDF)
2. U.S. Department of Energy, Federal Energy Management Program. (2024). Best practices guide for energy-efficient data center design (revised July 2024). energy.gov (PDF)
3. Spitaels, J., Zhang, L., and Lin, P. (n.d.). The different types of UPS systems (White Paper 1, version 10). Schneider Electric Energy Management Research Center. schneider-electric.com (PDF)
4. Cisco Systems. (n.d.). Fan overview [Hyperfabric HF6100-32D hardware installation]. cisco.com
5. Consulting-Specifying Engineer. (2006, June 1). Keeping fire in its place in data centers. csemag.com
6. Electronic Components Industry Association. (2005). EIA-310-E: Cabinets, racks, panels, and associated equipment. (Cited for the 19-inch rack and 1.75-inch rack unit; the standard itself was not consulted.)

A playbook, a typo and an afternoon offline

On 28 February 2017, an authorized member of Amazon's S3 storage team, following an established playbook, ran a command intended to remove a small number of servers from one subsystem. Amazon's public summary of the event explains what went wrong: one of the inputs to the command was entered incorrectly, and a much larger set of servers was removed than intended, including ones that two other S3 subsystems depended on. Large parts of S3 in the US-EAST-1 region were unavailable for hours. Amazon's fix was procedural as much as technical: the tool was changed to remove capacity more slowly and to refuse any removal that would take a subsystem below its minimum capacity.

Your network is smaller, but its outages often start the same way: a change made without enough checking, or a recovery slowed because nobody can find the right document. Here is the problem for this lesson. At 2 a.m. the core switch in a branch office fails. A replacement arrives by courier at 6. What must already exist, written down and up to date, for the on-call engineer to have the branch working by 7? Objective 3.1 is the answer: documentation, life-cycle management, change management and configuration management.

The documents the engineer reaches for

An SLA is only useful if its numbers are concrete. Amazon's EC2 service-level agreement, for example, commits to a region-level monthly uptime percentage of at least 99.99 percent and pays service credits on a sliding scale when it misses. Work out what that means: a 30-day month has 43,200 minutes, and 0.01 percent of that is about 4.3 minutes of allowed downtime. Every extra nine divides the allowance by ten.

Bottom line: diagrams, rack elevations, cable maps, inventory, IPAM and SLAs turn a midnight guessing game into a checklist; write them before the outage, because no one can write them during it.

Configuration management: three copies of the truth

The fastest way to rebuild the failed switch is to load its configuration. Objective 3.1 names three versions to keep.

• Production configuration: what is running on the device now.
• Backup configuration: a saved copy of the production configuration, taken automatically on a schedule and after every change, stored off the device.
• Baseline or golden configuration: the approved standard. NIST's guide to security-focused configuration management, SP 800-128, defines a baseline configuration as a set of specifications that has been formally reviewed and agreed on at a point in time, can be changed only through change control, and serves as the basis for future builds.

With all three, the 6 a.m. rebuild is simple: load last night's backup onto the new switch, then compare it with the golden configuration to catch anything that drifted. Without them, the engineer rebuilds VLANs and trunks from memory. Comparing production against baseline is also how drift, Lesson 14's term, is detected before it causes an outage.

Change management: making changes boring

NIST SP 800-128 names configuration change control as the process for managing updates to baseline configurations, and most organizations run it as a workflow along these lines:

1. Request: a change request or service request is logged in a tracking system, stating what, why, when and who. The objective calls this request process tracking.
2. Assess and approve: someone other than the requester reviews the risk, the affected systems and the rollback plan; larger changes go to a change advisory board.
3. Schedule: risky work goes in an agreed maintenance window, with users told in advance.
4. Implement and verify: the change is made as written and tested against a defined success check.
5. Roll back if needed, using the backup configuration.
6. Document: the diagrams, inventory and baseline are updated, and the ticket closed.

Amazon's S3 fix shows the same idea built into tooling: limit how much one command can change, and refuse changes that break a safety threshold. Lesson 14's version-controlled configurations make every approved change reviewable and reversible.

Life-cycle management: from purchase to disposal

Every device eventually stops being supported, and the exam uses two terms. End-of-life (EOL) means the vendor stops making or selling the product. End-of-support (EOS) means the vendor stops providing fixes and help. Vendors' own terms differ, which causes real confusion. Cisco, for example, uses EOS for End-of-Sale, the date after which the product is no longer offered for sale, and LDoS for the Last Date of Support; its policy gives hardware five years of support from the end-of-sale date. When you read "EOS" in a vendor notice, check which meaning it has.

Support status matters because of software management. Switches, routers, firewalls and access points run an operating system and firmware that need patches and bug fixes. NIST's guide to enterprise patch management, SP 800-40 Revision 4, warns that some patches will never be released because the software is at end of life, which leaves the organization to isolate or replace the asset. Track each device's software version and support dates in the asset inventory, and plan replacements before the last date of support, not after.

At the end comes decommissioning. Network devices hold configurations with passwords, keys, SNMP communities and VPN secrets. NIST SP 800-88, whose Revision 2 was published in September 2025, describes media sanitization as making access to the data on media infeasible for a given level of effort. Sanitize or destroy the storage, then remove the device from the inventory, IPAM, DNS, monitoring and any certificate or credential lists, so that nothing still trusts a box that has left the building.

Bottom line: keep baseline, production and backup configurations; push every change through request, approval, scheduling, verification and documentation; and track support dates so no device runs unpatched past end of support or leaves the building with its secrets.

Common misconceptions

• "The running configuration is the documentation." It shows what is configured now, not what was intended, approved or connected to what. Diagrams, baselines and cable maps answer different questions.
• "Change management is paperwork that slows engineers down." It is the review that catches the mistyped input before it removes the wrong servers, and the record that makes rollback possible.
• "EOS always means end of support." Some vendors use it for end of sale. Read the vendor's definitions and dates.
• "A decommissioned switch can be recycled as is." Its configuration holds credentials and keys; sanitize it and remove it from every system that trusts it.

The takeaway

• Documentation: physical and logical diagrams (layers 1 to 3), rack diagrams, cable maps, asset inventory with licences and warranty, IPAM, SLAs, wireless surveys.
• SLAs need numbers: 99.99 percent monthly uptime allows about 4.3 minutes of downtime.
• Configurations: production, backup and baseline or golden; compare to catch drift (NIST SP 800-128).
• Change management: request tracking, review and approval, maintenance windows, verification, rollback, documentation.
• Life cycle: EOL and EOS dates, patching of OS and firmware (NIST SP 800-40), decommissioning with sanitization (NIST SP 800-88).

Sources

1. Amazon Web Services. (2017). Summary of the Amazon S3 service disruption in the Northern Virginia (US-EAST-1) region. aws.amazon.com
2. Johnson, A., Dempsey, K., Ross, R., Gupta, S., and Bailey, D. (2011, updated 2019). Guide for security-focused configuration management of information systems (NIST Special Publication 800-128). National Institute of Standards and Technology. csrc.nist.gov
3. Souppaya, M., and Scarfone, K. (2022). Guide to enterprise patch management planning: Preventive maintenance for technology (NIST Special Publication 800-40 Revision 4). National Institute of Standards and Technology. csrc.nist.gov
4. National Institute of Standards and Technology. (2025). Guidelines for media sanitization (NIST Special Publication 800-88 Revision 2). csrc.nist.gov
5. Cisco Systems. (n.d.). End-of-life policy. cisco.com
6. Amazon Web Services. (n.d.). Amazon Compute service level agreement. Retrieved 27 October 2026. aws.amazon.com

Thirty years of asking devices how they are

RFC 1157, dated May 1990, defined the Simple Network Management Protocol, a way for a central station to ask any router or switch how it was doing. Twelve years later, in December 2002, the IETF's overview of the management framework, RFC 3410, judged the first versions harshly. SNMPv1 and SNMPv2c, it said, support only trivial authentication based on plain-text community strings and are fundamentally insecure. That arc, from simple and useful to replaced for security, runs through network monitoring generally. Objective 3.2 asks you to use monitoring technologies "given a scenario", which means knowing what each method can and cannot tell you. This lesson compares them side by side.

The methods compared

Key idea: choose the method by the question: SNMP for device health and utilization, traps for immediate events, flows for who-talks-to-whom, packet capture for exact contents, logs and SIEM for events and correlation.

SNMP up close: managers, agents and the MIB

SNMP has two roles. An agent runs on each managed device. A manager, the monitoring server, polls agents with get requests on UDP 161 and receives traps on UDP 162. What can be read is defined in a Management Information Base (MIB), a structured catalogue in which every value has an object identifier. The interfaces MIB, RFC 2863, defines the counters you will poll most: octets in and out, errors and discards for each interface. A monitoring tool polls those counters every few minutes and turns the differences into graphs of utilization and error rates.

The versions matter for the exam and for security.

A community string is effectively a shared password. In v1 and v2c it crosses the network unencrypted, so anyone capturing traffic can read it, and a read-write community lets an attacker change device settings. RFC 3410 records that v1 and v2c were declared Historic because of these weaknesses. Use SNMPv3 with authentication and privacy where devices support it; where v2c cannot be avoided, use read-only communities that are not the default "public", and restrict which addresses may query.

Key idea: SNMP agents expose MIB objects to a manager on UDP 161 and send traps to UDP 162; v1 and v2c protect them only with plain-text community strings, while v3 adds authentication and encryption.

Flows: the phone bill of the network

SNMP tells you a WAN link is 95 percent full. It cannot tell you why. Flow data can. IPFIX, the IETF's flow export standard in RFC 7011 (September 2013), defines a flow as a set of packets passing an observation point during a time interval. The packets in a flow share common properties, typically source and destination address and port and protocol. Routers and switches export a record for each flow to a collector, rather like an itemized phone bill: who called whom, for how long, how much data, but never what was said. Cisco's older NetFlow works the same way. Traffic analysis tools build top-talker reports from flow records, which answer the classic question of who is using the bandwidth.

Packets, mirrors and taps

When you need the actual conversation, you capture packets with Wireshark or tcpdump. On a switched network, the capture point needs a copy of the traffic. Port mirroring, which Cisco calls SPAN, tells the switch to copy one port's or VLAN's traffic to a monitoring port. A network tap is a hardware device placed in the cable itself. The Wireshark project's capture guidance lists the trade-offs. Monitor ports may not pass malformed frames or VLAN tags, may duplicate packets, and change timing. A passive tap is better for exact studies such as jitter measurement. Capture only traffic you are authorized to inspect; packet captures can contain passwords, messages and personal data.

Logs: syslog, collectors and SIEM

Devices describe events in log messages, and the standard format is syslog, RFC 5424 from March 2009. Every message carries a severity from 0 to 7, and the exam expects you to know the order.

Lower numbers are more severe. Setting a device to log at level 4 sends levels 0 to 4 and suppresses the chattier 5 to 7. A syslog collector gathers messages from every device into one searchable place with synchronized timestamps, which is why NTP, in Lesson 25, matters to monitoring. A SIEM goes further. NIST's guide to log management, SP 800-92, describes SIEM software as centralized logging with servers that analyse and store logs, receiving data through agents or agentlessly. It performs event correlation: finding relationships between entries from different logs. A failed login on the VPN, then a successful one from a new country, then a configuration change on a firewall, each harmless alone, together become an alert.

Baselines and alerting

A number means little without knowing what is normal. A baseline records typical values over time: utilization by hour and day, error rates, latency, CPU. Alerting then works two ways. Fixed thresholds fire when a value crosses a line, such as interface errors above zero or utilization above 80 percent. Anomaly alerting compares current behaviour with the baseline profile, the approach NIST's intrusion detection guide calls anomaly-based detection, and flags significant deviations, such as backup-sized traffic at 3 p.m. instead of 3 a.m. Baselines also make troubleshooting possible: "slow" can only be measured against what normal looked like.

Key idea: collect a baseline first, then alert on thresholds and on deviations from it; without a baseline, monitoring data cannot say whether today is unusual.

Putting the methods to work

Objective 3.2 also lists five monitoring solutions, each built from the methods above.

• Network discovery, run ad hoc or on a schedule, finds what is attached: scans of your own address space, SNMP walks, and neighbour protocols such as LLDP. A scheduled discovery that finds a device missing from the asset inventory is an early warning of a rogue device.
• Traffic analysis uses flows and captures to see what the traffic is.
• Performance monitoring tracks utilization, latency, jitter and loss against the baseline.
• Availability monitoring checks reachability and service health, by ping, by connecting to a port, or by loading a page, and measures uptime against the SLA from Lesson 22.
• Configuration monitoring compares running configurations with the baseline configuration and alerts on unauthorized change.

Modern tools increasingly gather all of this through APIs rather than screen-scraping or SNMP alone. RESTCONF, RFC 8040, for example, is an HTTP-based protocol giving programs access to device data defined in the YANG modelling language. It lets monitoring, automation and ticketing systems share data directly.

Common misconceptions

• "SNMP tells you who is using the bandwidth." It reports interface counters. Flow data tells you which hosts and applications are responsible.
• "Community strings are passwords, so SNMPv2c is secure enough." They cross the network in plain text; RFC 3410 calls v1 and v2c fundamentally insecure. Use SNMPv3.
• "Severity 7 is the most serious syslog level." Severity 0, Emergency, is the most serious; 7 is debug output.
• "A mirrored port shows exactly what was on the wire." Mirror ports can drop malformed frames, strip VLAN tags and alter timing; a tap is more faithful.

Recap

• SNMP: agents, managers and MIBs; polls on UDP 161, traps on UDP 162; v1 and v2c use plain-text community strings, v3 adds authentication and privacy.
• Flows (IPFIX, NetFlow) summarize who talked to whom and how much; packet capture shows exact contents; port mirroring or taps deliver copies.
• Syslog severities: 0 Emergency, 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notice, 6 Informational, 7 Debug; collectors centralize, SIEMs correlate.
• Baselines make thresholds and anomaly alerts meaningful.
• Solutions: discovery (ad hoc or scheduled), traffic analysis, performance, availability and configuration monitoring, increasingly through APIs such as RESTCONF.

Sources

1. Case, J., Fedor, M., Schoffstall, M., and Davin, J. (1990). A Simple Network Management Protocol (SNMP) (RFC 1157). RFC Editor. rfc-editor.org
2. Case, J., Mundy, R., Partain, D., and Stewart, B. (2002). Introduction and applicability statements for Internet-standard management framework (RFC 3410). RFC Editor. rfc-editor.org
3. Blumenthal, U., and Wijnen, B. (2002). User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) (RFC 3414). RFC Editor. rfc-editor.org
4. McCloghrie, K., and Kastenholz, F. (2000). The interfaces group MIB (RFC 2863). RFC Editor. rfc-editor.org
5. Claise, B. (Ed.), Trammell, B. (Ed.), and Aitken, P. (2013). Specification of the IP Flow Information Export (IPFIX) protocol (RFC 7011). RFC Editor. rfc-editor.org
6. Gerhards, R. (2009). The syslog protocol (RFC 5424). RFC Editor. rfc-editor.org
7. Kent, K., and Souppaya, M. (2006). Guide to computer security log management (NIST Special Publication 800-92). National Institute of Standards and Technology. csrc.nist.gov
8. Wireshark Foundation. (n.d.). Capture setup: Ethernet. Wireshark Wiki. wiki.wireshark.org
9. Bierman, A., Bjorklund, M., and Watsen, K. (2017). RESTCONF protocol (RFC 8040). RFC Editor. rfc-editor.org

Start with what the business can bear

NIST's contingency planning guide for federal information systems, Special Publication 800-34 Revision 1 from May 2010, begins recovery planning with a business impact analysis rather than with technology. Its reasoning is that the right design depends on two numbers the business must supply: how long it can be without a system, and how much data it can afford to lose. Everything else, from the type of backup site to whether two firewalls share the load, follows from those numbers. This lesson works through the procedure for a small chain of clinics whose network carries appointments, patient records and phones, and then changes one input to show how much the answer depends on it. It covers objective 3.3.

Step 1: set the targets

NIST SP 800-34 defines the three targets that frame every plan.

Keep RTO and RPO apart. RTO is about time to get back up; RPO is about how far back in time the recovered data will be. A system can come back in ten minutes (a short RTO) and still have lost a day of entries (a long RPO) if the last backup was yesterday's. The clinic's 15-minute RPO already rules out nightly backups: it needs replication or backups at least every 15 minutes.

The point: the business sets MTD, RTO and RPO; RTO limits how long recovery may take, RPO limits how much data may be lost, and the technology is chosen to meet them.

Step 2: measure how often things break and how long repairs take

Two more metrics describe the equipment itself. Mean time between failures (MTBF) is the average operating time between failures of a repairable item. Mean time to repair (MTTR) is the average time to restore it after a failure. A NASA Kennedy Space Center reliability formula sheet gives the standard expression that links them: inherent availability equals MTBF divided by the sum of MTBF and MTTR.

Work it for the clinic's main firewall. The vendor quotes an MTBF of 50,000 hours, and with a spare unit on the shelf the team can swap and restore its configuration in 4 hours.

• Availability = 50,000 / (50,000 + 4) = 0.99992, or about 99.992 percent.
• Expected downtime per year = (1 minus 0.99992) times 8,760 hours, about 0.7 hours, or roughly 42 minutes.

Now change one input. Suppose there is no spare and a replacement must be shipped, so the MTTR becomes 72 hours.

• Availability = 50,000 / (50,000 + 72) = 0.99856, or about 99.86 percent.
• Expected downtime per year = (1 minus 0.99856) times 8,760 hours, about 12.6 hours.

Nothing about the firewall changed, only the repair process, and the expected annual downtime grew eighteenfold. A single 72-hour repair would also blow straight through the clinic's 4-hour RTO. Cutting MTTR, with spares, backups of configurations from Lesson 22 and practised procedures, is often the cheapest availability improvement there is. A large MTBF is an average across many units, not a promise that this unit will run that long.

The point: availability is MTBF divided by MTBF plus MTTR, so faster repair raises availability as surely as more reliable hardware does.

Step 3: decide how much redundancy to run

Even a 4-hour swap is too slow for the clinic's phones, so the firewall and core need high availability: a second unit that takes over automatically. Objective 3.3 names two approaches, which Amazon's disaster-recovery whitepaper describes for whole sites as well as devices.

You have met both already. A VRRP gateway in Lesson 18 is active-passive: one master answers for the virtual IP while the backup waits. An EtherChannel or equal-cost routes in Lessons 16 and 17 are active-active: every member carries traffic. For the clinic, an active-passive firewall pair is the usual choice, because stateful firewalls must track every connection and passing that state between two active units is harder.

Step 4: choose the recovery site

If a whole site is lost, by fire, flood or a long power cut, the clinic needs somewhere else to run. NIST SP 800-34 describes the common alternate sites.

With a 4-hour RTO and a 15-minute RPO, a cold site is far too slow. The clinic chooses a warm site at its second location, with records replicated continuously and network configurations and spare equipment staged there, so recovery is a matter of activating and redirecting rather than buying and building.

The point: match the site to the RTO and the data protection to the RPO: cold sites are cheap and slow, hot and mirrored sites are fast and expensive.

Step 5: prove it works

A recovery plan that has never been exercised is a hope, and NIST describes two kinds of exercise that objective 3.3 names. A tabletop exercise is discussion-based: people meet, a facilitator presents a scenario, and the team talks through roles, coordination and decisions without touching equipment. It is cheap and finds gaps in responsibilities and contact lists. Validation tests, which NIST calls functional exercises, have staff perform their duties in a simulated operational environment, up to a full failover: restore a backup and check the data's age against the RPO, fail the firewall over and time it against the RTO. Amazon's whitepaper makes the same point for cloud designs: regularly assess and test the strategy so you have confidence in invoking it. Record the results and fix what failed.

Common misconceptions

• "RTO and RPO are two names for the same target." RTO limits how long recovery takes; RPO limits how much data may be lost.
• "An MTBF of 50,000 hours means this unit will run for 50,000 hours." MTBF is an average across many units; any single unit can fail tomorrow.
• "Active-active doubles capacity." Only if each unit can carry the full load alone after the other fails; otherwise a failure overloads the survivor.
• "Having backups means we can recover." Only a restore test proves the backups are complete, readable and recent enough to meet the RPO.

What to carry forward

• Business impact first: MTD, RTO (time to recover) and RPO (data loss tolerated), as NIST SP 800-34 defines them.
• Availability = MTBF / (MTBF + MTTR); cutting repair time raises availability.
• Active-passive: one serves, one waits. Active-active: both serve, each sized to carry everything.
• Cold, warm, hot and mirrored sites trade cost against recovery time.
• Test with tabletop exercises and validation (functional) tests, then fix what they reveal.

Sources

1. Swanson, M., Bowen, P., Phillips, A. W., Gallup, D., and Lynes, D. (2010). Contingency planning guide for federal information systems (NIST Special Publication 800-34 Revision 1). National Institute of Standards and Technology. csrc.nist.gov
2. NASA Kennedy Space Center. (2017). Formulas: Inherent availability and reliability with constant failure and repair rates. nasa.gov (PDF)
3. Amazon Web Services. (n.d.). Disaster recovery options in the cloud, in Disaster recovery of workloads on AWS [Whitepaper]. docs.aws.amazon.com
4. Nadas, S. (Ed.). (2010). Virtual Router Redundancy Protocol (VRRP) version 3 for IPv4 and IPv6 (RFC 5798). RFC Editor. rfc-editor.org
5. CompTIA. (2023). CompTIA Network+ N10-009 certification exam objectives (Document version 6.0), objective 3.3. CompTIA (PDF)

Four messages to a working computer

RFC 2131, published by Ralph Droms in March 1997, describes how a computer with no address, no gateway and no idea where any server is can be fully configured in four messages. That protocol, DHCP, runs every time you open a laptop on a new network, and it is objective 3.4's first service. This lesson follows one laptop through a Monday morning at a branch office: getting an address, reaching a DHCP server on another subnet, and then setting its clock, which matters far more than it sounds.

The exchange: discover, offer, request, acknowledge

The laptop starts with nothing, so its first message is a broadcast. RFC 2131 defines the messages that follow.

The initials give the common mnemonic DORA. The client uses UDP port 68 and the server port 67, the ports from Lesson 8. Other messages handle the exceptions: DHCPNAK when the client's idea of its address is wrong, for example after moving to a new subnet; DHCPDECLINE when the client finds the offered address already in use; DHCPRELEASE when it gives an address back.

The address is not given forever. It is leased. RFC 2131 has the client try to renew at T1, which defaults to half the lease time, by asking the same server directly, and at T2, which defaults to 87.5 percent of the lease, by asking any server. If the lease expires with no renewal, the client must stop using the address. A short lease suits a café with constant turnover; a long one suits an office of fixed desktops.

Why this matters: DHCP's four messages, DORA, configure a host that starts with nothing, and the lease with its renewal timers decides how long that configuration lasts.

What the server hands out: scopes, exclusions, reservations and options

The branch's DHCP service is configured with four ideas the exam expects you to know. Cisco's guide to its built-in DHCP server shows them as commands, and Windows Server uses the same concepts with a graphical console.

• Scope (a pool): the range of addresses the server may lease for one subnet, here 10.20.30.0/24.
• Exclusions: addresses inside the range that the server must never hand out, because they are statically assigned, such as the router at .1 and the printers at .2 to .20. Cisco's command for this, ip dhcp excluded-address, specifies addresses the server should not assign.
• Reservations: a fixed address always given to one particular client, identified by its MAC address or client identifier. RFC 2131 calls this manual allocation: the administrator chooses the address, and DHCP simply delivers it. Reservations suit printers and servers that need a stable address but are easier to manage centrally.
• Options: the extra settings delivered with the address. RFC 2132 numbers them: option 3 is the router (default gateway), option 6 the DNS servers, option 15 the domain name, option 51 the lease time.

Get one option wrong and the symptom is precise. A wrong option 3 gives every client a broken default gateway, Lesson 3's laptop that can print but cannot browse, multiplied by the whole office. A wrong option 6 gives addresses that work but names that do not resolve. And a scope that runs out of addresses leaves the latest arrivals with 169.254 addresses, an address pool exhaustion problem that Lesson 33 diagnoses.

Crossing a router: the relay agent

The branch has no DHCP server of its own; the server sits at headquarters. That is a problem, because the DISCOVER is a broadcast and routers do not forward broadcasts. Cisco's relay agent guide explains the fix. On the router interface facing the clients you configure ip helper-address with the server's address. The router then catches the client's broadcast and sends it on to the server as a unicast. It fills in the gateway address field, giaddr, with the address of its own client-facing interface, and the server uses that field to know which subnet the client is on and which scope to lease from. RFC 2131 calls such a device a relay agent.

A missing or wrong helper address produces the same symptom as a dead DHCP server: clients on that one subnet get 169.254 addresses while everyone else is fine.

Why this matters: a relay agent (ip helper-address) turns the client's local broadcast into a unicast to a remote server and marks the subnet in giaddr, so one DHCP server can serve many subnets.

The IPv6 way: SLAAC and DHCPv6

Lesson 12 showed IPv6 hosts building their own addresses with SLAAC from a router advertisement's prefix. A router advertisement can also tell hosts to use DHCPv6, defined today in RFC 8415, either for addresses (stateful DHCPv6) or only for extra settings such as DNS servers (stateless DHCPv6, using an information-request message). Many networks combine SLAAC for addresses with stateless DHCPv6 or router-advertised DNS servers.

Why the clock matters

Once the laptop has an address, it needs the right time, and the reasons are practical. Logs from different devices can only be correlated, as the SIEM in Lesson 23 does, if their timestamps agree. Certificates, Lesson 28, have validity periods, so a clock far off makes valid certificates look expired. And authentication protocols use time to stop replays: Microsoft's documentation for Kerberos, which Windows domains use for sign-in, gives a default maximum clock difference of 5 minutes between client and domain controller.

NTP's hierarchy is described in strata. RFC 5905 assigns stratum 1 to primary servers attached to a reference clock such as GPS, and each server synchronizing from another sits one stratum higher. Accuracy tends to degrade as the stratum number grows. A typical design points every device at two or three internal servers, which in turn synchronize from several external stratum 1 or 2 sources. Why does NTS matter? Plain NTP packets can be forged, and an attacker who moves a victim's clock can make expired certificates look valid again or break logging. RFC 8915, published in September 2020, uses TLS and authenticated encryption to stop that.

Why this matters: accurate, trusted time underpins log correlation, certificate checks and authentication; NTP provides it for most networks, PTP for sub-microsecond needs, and NTS secures NTP against forgery.

Common misconceptions

• "DHCP works across routers by itself." The DISCOVER is a broadcast. Without a relay agent (ip helper-address) on the client subnet's router interface, a remote server never hears it.
• "A reservation and an exclusion are the same thing." An exclusion keeps an address out of DHCP entirely; a reservation tells DHCP to always give one address to one client.
• "Time synchronization only matters for clocks on screens." Logs, certificates and Kerberos sign-in all fail or mislead when clocks drift.
• "PTP replaces NTP everywhere." PTP needs hardware support for its precision and suits specialized networks; NTP remains the general choice.

What you now know

• DORA: DISCOVER (broadcast), OFFER, REQUEST, ACK on UDP 67 and 68; leases renew at T1 (50 percent) and T2 (87.5 percent).
• Scopes define the range; exclusions keep static addresses out; reservations fix an address to a client; options carry gateway (3), DNS (6), domain name (15) and lease time (51).
• A relay agent with ip helper-address forwards DHCP broadcasts to a remote server as unicasts, marking the subnet in giaddr.
• IPv6 uses SLAAC, stateful DHCPv6 or stateless DHCPv6 for extra settings.
• Time: NTP (UDP 123, strata), PTP (IEEE 1588, hardware timestamps, sub-microsecond), NTS (TLS-based security for NTP); Kerberos tolerates 5 minutes of skew by default.

Sources

1. Droms, R. (1997). Dynamic Host Configuration Protocol (RFC 2131). RFC Editor. rfc-editor.org
2. Alexander, S., and Droms, R. (1997). DHCP options and BOOTP vendor extensions (RFC 2132). RFC Editor. rfc-editor.org
3. Cisco Systems. (n.d.). Configuring the Cisco IOS DHCP server and Configuring the Cisco IOS DHCP relay agent [Cisco IOS IP addressing services configuration guide, release 12.4T]. cisco.com (server); cisco.com (relay)
4. Mrugalski, T., et al. (2018). Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (RFC 8415). RFC Editor. rfc-editor.org
5. Mills, D., Martin, J. (Ed.), Burbank, J., and Kasch, W. (2010). Network Time Protocol version 4: Protocol and algorithms specification (RFC 5905). RFC Editor. rfc-editor.org
6. Franke, D., Sibold, D., Teichel, K., Dansarie, M., and Sundblad, R. (2020). Network Time Security for the Network Time Protocol (RFC 8915). RFC Editor. rfc-editor.org
7. Red Hat. (n.d.). Configuring PTP using ptp4l, in Red Hat Enterprise Linux 7 system administrator's guide. docs.redhat.com
8. Microsoft. (n.d.). Maximum tolerance for computer clock synchronization [Windows security policy settings]. Microsoft Learn. learn.microsoft.com

A ticket with the wrong culprit

At 9:00 on a Monday an administrator moved the company intranet, intranet.corp.example, to a new server, changing its A record from 10.1.1.20 to 10.1.1.80. At 15:00, half the office still lands on the old server, and one user who tried everything still cannot reach the new one. The administrator's ticket reads: "The DNS server did not save my change." That conclusion is plausible and wrong, and tracing exactly where it fails teaches most of objective 3.4's name-resolution content. The tools are nslookup, built into Windows, and dig, from the BIND project, whose manual gives its typical form as dig @server name type.

Step 1: ask the server that owns the zone

The first move is to skip every cache and ask the authoritative primary server directly: dig @ns1.corp.example intranet.corp.example A. It returns 10.1.1.80, and the response carries the AA flag, which RFC 1035 defines as Authoritative Answer: the responding server is an authority for the name. So the primary saved the change. The administrator's diagnosis fails at the first test.

An authoritative server holds the zone itself. A non-authoritative answer comes from a server that does not own the zone, usually a resolver answering from its cache; nslookup labels such answers "Non-authoritative answer", which is normal and not an error.

Step 2: ask the secondary

The zone has two authoritative servers: a primary, where edits are made, and a secondary, which keeps a copy. Asking the secondary, dig @ns2.corp.example intranet.corp.example A, returns the old 10.1.1.20. Why would an authoritative server give a stale answer? RFC 1034 explains how secondaries stay current: they periodically check the SERIAL field of the zone's SOA (start of authority) record, and the serial must be advanced whenever any change is made. The administrator edited the record but never advanced the serial, so the secondary saw no change and never requested a zone transfer. Advance the serial, and the secondary fetches the new zone at its next check or on notification. Roughly half the office was asking ns2.

Step 3: ask the resolver the users actually use

Users' computers do not ask authoritative servers directly. Their stub resolver asks a recursive resolver, the DNS server handed out by DHCP option 6, which does the work of finding the answer: asking the root servers, then the servers for the top-level domain, then the zone's authoritative servers, and caching what it learns. Querying the resolver shows the old address, with a TTL counting down from 86,400.

RFC 1035 defines a record's TTL as the time interval that the record may be cached before the source should be consulted again. This record's TTL was one day, so any resolver that looked it up before 9:00 could keep serving the old address until the next morning, quite correctly. The fix for today is to flush the resolver's cache. The fix for next time is procedure: lower the TTL to a few minutes a day before a planned change, make the change, then raise it again.

Step 4: the one computer that still fails

One user's PC keeps reaching the old server even after the resolver is fixed and ipconfig /flushdns has cleared its own cache. Running ipconfig /displaydns shows the answer. Microsoft's documentation explains that the DNS client cache includes entries preloaded from the local hosts file, used before querying DNS servers. A forgotten line in that user's hosts file, 10.1.1.20 intranet.corp.example, added during an old test, overrides DNS entirely. nslookup, which queries DNS servers directly, returns the right address, while the browser and ping do not; that mismatch is the classic hosts-file signature. Delete the line and the problem is gone.

What matters here: the server had the right answer all along; a forgotten SOA serial, a long TTL and a stale hosts file each kept the old one alive, and querying each layer separately with dig or nslookup found all three.

The pieces, generalized

The record types objective 3.4 lists each answer a different question.

Zones come in two directions. A forward zone maps names to addresses. A reverse zone maps addresses to names with PTR records, under in-addr.arpa for IPv4 (RFC 1035) and ip6.arpa for IPv6 (RFC 3596). Reverse lookups are what let logs and tools show names instead of bare addresses, and some mail servers check them.

Protecting DNS: DNSSEC, DoT and DoH

Plain DNS has no protection, which Lesson 29's DNS poisoning attacks exploit. Three technologies protect different things.

DNSSEC answers "is this answer authentic?"; DoT and DoH answer "can anyone on the path see or change my query?". They complement each other. A network team should know that browsers using DoH can send queries past the company resolver to an outside provider, which affects content filtering and monitoring, a policy decision rather than a purely technical one.

What matters here: DNSSEC signs records for integrity without encrypting them; DoT (port 853) and DoH (inside HTTPS) encrypt queries for privacy without proving the data authentic.

Common misconceptions

• "A non-authoritative answer is wrong or untrustworthy." It only means it came from a server that does not own the zone, usually a cache. It can be stale until the TTL expires.
• "Changing a record takes effect everywhere immediately." Cached copies live until their TTL expires, and secondaries update only when the SOA serial advances.
• "DNSSEC encrypts DNS." It signs answers for authenticity and integrity; RFC 4033 says it does not provide confidentiality. DoT and DoH provide the encryption.
• "If nslookup works, the browser must resolve the same way." nslookup queries DNS servers directly; applications use the system resolver, which consults the hosts file first.

The short version

• Stub resolver asks a recursive resolver, which asks root, TLD and authoritative servers and caches the answers for their TTL.
• Authoritative answers come from the zone's own servers (AA flag); non-authoritative ones come from caches.
• Primary holds the editable zone; secondaries copy it when the SOA serial advances.
• Records: A, AAAA, CNAME, MX, TXT, NS, PTR, SOA; forward zones map names to addresses, reverse zones (in-addr.arpa, ip6.arpa) map back.
• The hosts file overrides DNS on the local machine.
• DNSSEC: integrity and authenticity. DoT (853) and DoH (443): privacy.
• Test each layer separately: dig @server name type, nslookup name server, ipconfig /displaydns and /flushdns.

Sources

1. Mockapetris, P. (1987). Domain names: Concepts and facilities (RFC 1034) and Domain names: Implementation and specification (RFC 1035). RFC Editor. rfc-editor.org (RFC 1034); rfc-editor.org (RFC 1035)
2. Thomson, S., Huitema, C., Ksinant, V., and Souissi, M. (2003). DNS extensions to support IP version 6 (RFC 3596). RFC Editor. rfc-editor.org
3. Arends, R., Austein, R., Larson, M., Massey, D., and Rose, S. (2005). DNS security introduction and requirements (RFC 4033). RFC Editor. rfc-editor.org
4. Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and Hoffman, P. (2016). Specification for DNS over Transport Layer Security (TLS) (RFC 7858). RFC Editor. rfc-editor.org
5. Hoffman, P., and McManus, P. (2018). DNS queries over HTTPS (DoH) (RFC 8484). RFC Editor. rfc-editor.org
6. Microsoft. (n.d.). ipconfig and nslookup [Windows commands reference]. Microsoft Learn. learn.microsoft.com (ipconfig); learn.microsoft.com (nslookup)
7. Internet Systems Consortium. (n.d.). dig: DNS lookup utility, in BIND 9 manual pages. bind9.readthedocs.io

Three ways in, compared

NIST's guide to IPsec VPNs, Special Publication 800-77 Revision 1 from June 2020, sorts VPNs into three architectures. Gateway-to-gateway joins two networks, such as a main office and a branch. Remote access, also called host-to-gateway, lets individual hosts on untrusted networks reach an organization's services. Host-to-host protects traffic between two specific machines. Objective 3.5 asks you to compare these and the ways administrators reach the devices themselves. The comparison matters because each choice trades convenience against visibility and risk, and the exam's scenarios turn on exactly those trade-offs.

VPNs side by side

Site-to-site tunnels are usually IPsec in tunnel mode, built from the ESP and IKE pieces of Lesson 7. Client-to-site VPNs may use IPsec or TLS. Clientless VPNs use TLS through the browser. NIST's guide to SSL VPNs, SP 800-113, describes the portal type: one standard secure connection to a web site, the portal, which then leads to many other resources once the user has authenticated.

For client-to-site VPNs, one setting decides what travels through the tunnel.

NIST's telework guide, SP 800-46 Revision 2 from July 2016, sets out that trade-off. Split tunneling increases efficiency and reduces load, but the organization can no longer examine the traffic that bypasses the tunnel. A device connected to two networks at once can also become a bridge between a trusted and an untrusted network. For teleworkers on higher-risk networks such as wireless hotspots, the guide says organizations should consider disabling split tunneling.

Remember: site-to-site joins networks without user action; client-to-site connects one device; clientless works through a browser portal; full tunnels send everything through the organization, split tunnels only internal traffic.

Ways to manage a device, side by side

Cisco's guide to hardening its devices recommends SSH because it encrypts authentication and management data, and advises allowing only SSH for remote sessions instead of Telnet. It also says that access to the console port must be secured, just like remote access. A new switch that has no IP address yet cannot be reached by SSH, a GUI or an API, so the console is the usual way to give it its first configuration. Cisco's guidance for terminal emulators lists the settings: 9600 bits per second, 8 data bits, no parity, 1 stop bit and no flow control. The cable is usually a rollover console cable on a USB-to-serial adapter, or a USB console cable on newer devices.

Remember: SSH for daily work, HTTPS for GUIs, APIs for automation, and the console for first setup and emergencies; each needs authentication, and none should run unencrypted.

Where administrators connect from: jump boxes and out-of-band paths

Even encrypted management protocols are risky if any computer can reach them. Cisco's hardening guide recommends infrastructure access lists that permit management connections, such as SSH and SNMP, only from specific trusted management stations and deny everything else aimed at the devices. In practice that trusted station is often a jump box, or jump host: a hardened, monitored server inside the management network. Administrators connect to it first, with strong authentication, and from there to the devices. Every session passes one point that can be logged and protected, and a compromised laptop cannot reach switches directly.

The path the management traffic takes is the last choice. In-band management uses the production network itself: the same links that carry user traffic carry the SSH session. It is simple and free, and it fails exactly when you need it most, during an outage of that network. Out-of-band management uses a separate path: a dedicated management network, or a console server connected to each device's console port and reachable by its own link, often a cellular modem. Cisco's guide says that, ideally, every network device should have both in-band and out-of-band management access. The out-of-band path is the one that still works when the production network does not. Lesson 14's argument for out-of-band access after a bad change is the same point seen from automation.

Remember: restrict management to trusted stations such as a jump box, and keep an out-of-band path so devices can be reached when the production network is down.

Common misconceptions

• "A VPN makes all of a teleworker's traffic safe." With split tunneling, only internal traffic goes through the tunnel; the rest is exposed to whatever network the device is on.
• "Clientless VPN means no authentication." It means no installed client; the user still authenticates to the portal.
• "Out-of-band management is a luxury." It is the only way to reach a device whose production links are down or misconfigured.
• "Telnet is fine on the internal network." It sends passwords in clear text to anyone capturing traffic on any internal segment. Use SSH.

Putting it together

• VPN architectures (NIST SP 800-77): gateway-to-gateway (site-to-site), host-to-gateway (remote access) and host-to-host; clientless portals through a browser (SP 800-113).
• Full tunnel: everything through the organization. Split tunnel: only internal traffic; NIST suggests disabling it on risky networks (SP 800-46).
• Management methods: SSH, GUI over HTTPS, API, console (9600, 8 data bits, no parity, 1 stop bit).
• Restrict management to trusted stations, typically a jump box; keep both in-band and out-of-band paths.

Sources

1. Barker, E., et al. (2020). Guide to IPsec VPNs (NIST Special Publication 800-77 Revision 1). National Institute of Standards and Technology. csrc.nist.gov
2. Frankel, S., Hoffman, P., Orebaugh, A., and Park, R. (2008). Guide to SSL VPNs (NIST Special Publication 800-113). National Institute of Standards and Technology. csrc.nist.gov
3. Souppaya, M., and Scarfone, K. (2016). Guide to enterprise telework, remote access, and bring your own device (BYOD) security (NIST Special Publication 800-46 Revision 2). National Institute of Standards and Technology. csrc.nist.gov
4. Cisco Systems. (n.d.). Harden IOS devices (Document ID 13608). cisco.com
5. Cisco Systems. (n.d.). Troubleshoot and apply correct terminal emulator settings for console connections (Document ID 217970). cisco.com
6. Ylonen, T., and Lonvick, C. (Ed.). (2006). The Secure Shell (SSH) transport layer protocol (RFC 4253). RFC Editor. rfc-editor.org

A board meeting, and a vocabulary

Harbor Outfitters, a fictional retailer, runs twelve shops, an online store, and a warehouse whose freezers and heating are controlled over the network. Its new network manager has ten minutes with the board to explain the security budget. "We need more firewalls" will not work. She has to speak the language of risk, which is what objective 4.1 teaches. This lesson follows her through it: the vocabulary, encryption and certificates, identity, physical security and deception, compliance, and segmentation.

She starts with the three properties every control protects, the CIA triad. NIST's FIPS 199, from February 2004, quotes the US legal definitions. Confidentiality means keeping access and disclosure within authorized limits, including personal privacy. Integrity means guarding against improper modification or destruction, including authenticity and non-repudiation. Availability means "ensuring timely and reliable access to and use of information." Encryption serves confidentiality, hashes and signatures serve integrity, and the redundancy of Lesson 24 serves availability.

Next come four words the exam keeps apart. NIST's risk assessment guide, SP 800-30 Revision 1 from September 2012, defines a threat as any circumstance or event that could harm the organization through an information system. A vulnerability is a weakness in a system, procedure, control or implementation that a threat source could exploit. Risk combines how likely a threat event is with how much harm it would do. An exploit is the specific code or technique that takes advantage of a vulnerability.

In short: threats act, vulnerabilities are the openings, exploits are the tools, and risk, likelihood times impact, decides what to fix first.

Encryption and certificates

Encryption protects data in two states. Data in transit crosses a network, protected by TLS for web and mail, SSH for management and IPsec for VPNs, as Lessons 7, 8 and 27 showed. Data at rest sits on a disk, in a database or in a backup, protected by full-disk or database encryption. A stolen laptop with an encrypted disk is an inconvenience; without encryption, every file on it is exposed. Protection in transit does nothing for data at rest, and the reverse is also true, so read each scenario for where the data is.

Encryption needs keys, and keys need trust. A certificate binds a public key to a name and is signed by a certificate authority (CA). Operating systems and browsers ship with a set of trusted root CAs. The CAs, their certificates and the rules for issuing and checking them form a public key infrastructure (PKI). RFC 5280, the profile for these X.509 certificates, describes self-signed certificates as ones whose signature is verified with the public key inside the certificate itself.

Root CA certificates are self-signed too; they are trusted only because they were installed in advance. A switch's or a lab server's self-signed certificate is in nobody's trust store, so browsers warn. That is fine in a lab. In production it teaches users to click through warnings, which is exactly the habit an attacker needs.

Every certificate also has a validity period, two dates RFC 5280 calls notBefore and notAfter. This is the link promised in Lesson 25. A device whose clock is a year wrong will reject valid certificates as expired or not yet valid. When TLS fails on one machine only, check its clock.

Identity: proving who, then deciding what

Identity and access management (IAM) answers two questions. Authentication asks who you are; authorization asks what you may do. NIST's authentication guideline, SP 800-63B-4 from July 2025, uses the classic factors: a password is something you know, a physical authenticator is something you have, and a biometric is something you are. Multifactor authentication (MFA) needs two different factors, so two passwords are still one factor.

The same guideline treats codes sent by SMS or voice over the phone network as a restricted option, and asks verifiers to watch for risk signs such as a SIM change or a ported number. It also says verifiers must not force periodic password changes. They should force a change only when there is evidence of compromise.

The objectives' term time-based authentication covers two ideas. The codes in an authenticator app are time-based one-time passwords (TOTP), defined in RFC 6238 from May 2011, which recommends a 30-second time step: each code is computed from a shared secret and the current time. Access rules can also depend on time, such as accounts that may sign in only during working hours. Both depend on accurate clocks.

Signing in once for many services is single sign-on (SSO). Inside an organization, the directory behind it is usually reached with LDAP, the Lightweight Directory Access Protocol, on TCP 389, or 636 for LDAPS, as in Lesson 8. Across organizations and cloud applications, SAML, the Security Assertion Markup Language from OASIS, carries the proof. Its technical overview names the roles. An identity provider (IdP) authenticates the user and issues assertions, and a service provider (SP) relies on them. Harbor's staff sign in once to the company IdP and reach payroll and email without new passwords.

Network access and device administration use two older AAA protocols. Compare them before the exam does.

Exam materials usually say TACACS+ encrypts the entire payload while RADIUS encrypts only the password. RFC 8907 is blunter. It says TACACS+ protection is best called obfuscation, not encryption, because it gives no meaningful integrity, privacy or replay protection. Deployments must limit access to known clients and secure the whole transmission path. Treat RADIUS the same way.

Authorization follows authentication. Least privilege restricts each user, or each process acting for a user, to the minimum access needed for assigned tasks. Role-based access control (RBAC) makes that manageable: permissions attach to roles such as store manager or network operator, and people receive roles, not individual permissions. When someone changes jobs, you change the role. Geofencing adds location to the decision. An identity system can refuse sign-ins from countries where Harbor has no staff, and a device-management tool can let a handheld scanner work only inside the warehouse.

Physical security and deception

Every logical control assumes the attacker is not standing next to the switch. Physical security makes that true. Locks, from keyed doors to badge readers that log each entry, keep people out of closets and server rooms. Cameras deter, record, and let one guard watch many doors. Lesson 27 made the point with console ports: physical access can become administrative access.

Deception technologies turn an intruder's curiosity into an alarm. A honeypot, in the CNSSI 4009 definition on NIST's glossary, is a system or resource designed to attract potential intruders, "like honey is attractive to bears." A honeynet is a network of honeypots that imitates a real environment. No legitimate user has any reason to touch either, so any connection to one is suspicious by definition.

Rules from outside: audits and compliance

Some requirements are not choices. Harbor takes card payments, so it must meet the Payment Card Industry Data Security Standard (PCI DSS). The PCI Security Standards Council describes it as a baseline of technical and operational requirements to protect payment account data. It applies to every entity that stores, processes or transmits cardholder data, or could affect the security of the cardholder data environment. Assessors audit the controls against the standard. Segmentation helps: card systems in their own tightly controlled zone limit how much of the network can affect card data.

Harbor's online store also sells to customers in the European Union, which can bring it under the General Data Protection Regulation (GDPR), Regulation (EU) 2016/679. The European Commission notes that it entered into force on 24 May 2016 and has applied since 25 May 2018, across the European Economic Area (EEA). When personal data leaves the EEA, safeguards such as adequacy decisions or standard contractual clauses must make sure, in the Commission's words, that "the protection travels with the data." That is why data locality, where data is physically stored and processed, has become a design question. The cloud region chosen for a VPC in Lesson 13 can be a compliance decision.

Segmentation as enforcement

The last part of objective 4.1 is a design habit. Put devices that cannot defend themselves, or should not be trusted, in segments of their own, and control what crosses. Four groups appear on the exam.

NIST's Guide to Operational Technology Security, SP 800-82 Revision 3 from September 2023, explains the OT row. OT covers programmable systems that interact with the physical environment, such as industrial control systems and building automation. Supervisory control and data acquisition (SCADA) systems are one kind: they monitor and control dispersed assets, such as pipelines and power grids, from a central location. The guide notes that IT may treat data loss or availability as the higher priority, while OT may put safety, production and environmental damage first.

The guide recommends organizing OT devices into segments by function or location. Firewalls or unidirectional gateways, also called data diodes, then permit only explicitly authorized traffic between segments. Harbor's freezer controllers belong in such a zone, not on the shop Wi-Fi.

Common misconceptions

• "HTTPS protects the data on the server." TLS protects data in transit. Data at rest on the server needs its own encryption and access control.
• "A password plus a security question is MFA." Both are something you know, so it is one factor used twice.
• "Self-signed means weak encryption." The cryptography can be just as strong. The problem is trust: no one has installed that certificate in advance, so clients cannot tell it from an attacker's.
• "TACACS+ is encrypted, so it is safe anywhere." RFC 8907 calls its protection obfuscation and requires a secured transmission path.
• "Passing an audit means we are secure." An audit shows that required controls existed when it was done. Risk keeps changing afterwards.

Where this leaves us

• CIA: confidentiality, integrity, availability (FIPS 199). Threat, vulnerability, exploit and risk are different things (SP 800-30).
• Data in transit and data at rest need separate protection. PKI makes certificates trustworthy; self-signed certificates are trusted by no one by default; validity periods depend on correct clocks.
• MFA uses two different factors. TOTP codes follow the clock. SSO uses LDAP directories inside and SAML across organizations. RADIUS (UDP 1812) serves network access; TACACS+ (TCP 49) separates AAA for device administration.
• Least privilege and RBAC limit what authenticated users can do; geofencing adds location.
• Locks and cameras protect the hardware; honeypots and honeynets catch intruders. PCI DSS, GDPR and data locality set outside rules. IoT, OT, guest and BYOD devices get their own segments.

Sources

1. National Institute of Standards and Technology. (2004). Standards for security categorization of federal information and information systems (FIPS PUB 199). csrc.nist.gov
2. Joint Task Force Transformation Initiative. (2012). Guide for conducting risk assessments (NIST Special Publication 800-30 Revision 1). National Institute of Standards and Technology. csrc.nist.gov
3. Temoshok, D., et al. (2025). Digital identity guidelines: Authentication and authenticator management (NIST Special Publication 800-63B-4). National Institute of Standards and Technology. csrc.nist.gov
4. M'Raihi, D., Machani, S., Pei, M., and Rydell, J. (2011). TOTP: Time-based one-time password algorithm (RFC 6238). RFC Editor. rfc-editor.org
5. Cooper, D., et al. (2008). Internet X.509 public key infrastructure certificate and certificate revocation list (CRL) profile (RFC 5280). RFC Editor. rfc-editor.org
6. Rigney, C., Willens, S., Rubens, A., and Simpson, W. (2000). Remote Authentication Dial In User Service (RADIUS) (RFC 2865). RFC Editor. rfc-editor.org
7. Rigney, C. (2000). RADIUS accounting (RFC 2866). RFC Editor. rfc-editor.org
8. Dahm, T., Ota, A., Medway Gash, D. C., Carrel, D., and Grant, L. (2020). The Terminal Access Controller Access-Control System Plus (TACACS+) protocol (RFC 8907). RFC Editor. rfc-editor.org
9. OASIS. (2008). Security Assertion Markup Language (SAML) V2.0 technical overview (Committee Draft 02). docs.oasis-open.org
10. National Institute of Standards and Technology. (n.d.). Honeypot. CSRC glossary. csrc.nist.gov
11. PCI Security Standards Council. (n.d.). PCI Data Security Standard (PCI DSS). pcisecuritystandards.org
12. European Commission. (n.d.). Legal framework of EU data protection and Rules on international data transfers. commission.europa.eu; commission.europa.eu
13. Stouffer, K., et al. (2023). Guide to operational technology (OT) security (NIST Special Publication 800-82 Revision 3). National Institute of Standards and Technology. csrc.nist.gov
14. Cybersecurity and Infrastructure Security Agency. (2021). Understanding denial-of-service attacks. cisa.gov

The problem: attacks arrive as symptoms

At 9:10 on a Monday, Harbor's help desk takes four calls. The warehouse network is slow. A cashier's browser shows a certificate warning on the payroll site. Two new laptops received addresses from a range nobody uses. A shop switch is sending every frame out of every port. None of the callers says "attack." Real incidents, and the exam's scenario questions, arrive as symptoms. Objective 4.2 asks you to work backwards from what you see to the attack and its impact.

This lesson takes the attacks in the order an attacker meets a network: the switch, the addressing and naming services, the air, the network's capacity, the people, and the software. For each one, ask three questions. How does it work? Which part of the CIA triad from Lesson 28 does it damage? What stops it?

Attacks on the switch: MAC flooding and VLAN hopping

A switch learns which MAC address lives on which port and stores the answer in its MAC address table, often called the CAM table (Lesson 3). The table has a fixed size. In MAC flooding, an attacker sends frames with thousands of invented source addresses until the table is full. Cisco's guide to layer 2 security features describes the result. With no room to learn, the switch floods incoming frames out of every port in the VLAN and "acts like a hub." The attacker can now capture traffic meant for others. The impact is on confidentiality, and the defense is port security, which limits the addresses a port may learn (Lesson 30).

VLAN hopping sends traffic into a VLAN the attacker is not assigned to, defeating the separation of Lesson 15. It has two forms.

• Switch spoofing. A port left to negotiate its mode, such as one in Cisco's default dynamic auto mode, can be talked into becoming a trunk by a device that pretends to be a switch. The attacker then receives traffic for every VLAN the trunk carries.
• Double tagging. An attacker on an access port in the trunk's native VLAN sends a frame carrying two 802.1Q tags: an outer tag for the native VLAN and an inner tag for the target VLAN. The first switch removes the outer tag, because native VLAN frames cross trunks untagged. The next switch reads the inner tag and delivers the frame into the target VLAN. Replies cannot come back the same way, so the attack is one-way, which is still enough to deliver an exploit.

Cisco's best-practices guide for its Catalyst switches warns that frames can pass between VLANs without a router when the sending port sits in the native VLAN of an 802.1Q trunk. It recommends a dummy native VLAN that is not used for end-user access. It also recommends setting host ports to access mode explicitly, so they never negotiate a trunk. Those are the settings Lesson 15 used.

The upshot: MAC flooding turns a switch into a hub, and VLAN hopping crosses VLAN boundaries by negotiating a trunk or abusing the untagged native VLAN. Switch settings stop both; a firewall never sees them.

Lying about addresses: ARP and DHCP

ARP, defined in RFC 826 in 1982, maps an IP address to a MAC address on the local network (Lesson 3). It has no way to check who sent a message, and hosts readily update their caches from the ARP messages they receive. In ARP spoofing, an attacker sends forged ARP replies claiming that the default gateway's IP address belongs to the attacker's MAC address. The victims' caches now hold the false mapping, which is ARP poisoning. Spoofing is the act and poisoning the result, and many sources use the terms interchangeably. The victims send their gateway-bound frames to the attacker, who forwards them onward, reading or changing them on the way.

A rogue DHCP server lies one step earlier. It answers DHCP requests before, or instead of, the real server (Lesson 25), handing out its own choice of default gateway and DNS server. Clients that accept its offer route through the attacker or ask the attacker for names. Rogue DHCP is not always malicious. A home router plugged into an office port does similar damage by accident, handing out addresses from the wrong range.

Cisco's layer 2 guide describes the defenses. DHCP snooping acts "like a firewall between untrusted hosts and DHCP servers," dropping server replies that arrive on untrusted, user-facing ports. It also builds a table of which client holds which address on which port. Dynamic ARP Inspection uses that table to discard ARP packets with invalid IP-to-MAC bindings.

Lying about names: DNS poisoning and DNS spoofing

DNS poisoning targets a resolver's cache. CERT/CC's vulnerability note VU#800113, from July 2008, describes it as introducing forged DNS information into the cache of a caching nameserver. A DNS query carries a 16-bit transaction ID. With a properly random ID, the note says, an attacker needs on average 32,768 attempts to guess it. The main mitigation was randomizing the source port of each query, which adds roughly 16 more bits to guess. The note adds that only protocol changes such as DNSSEC (Lesson 26) can prevent cache poisoning completely. Once a cache is poisoned, every client of that resolver goes to the attacker's address until the record's TTL expires.

DNS spoofing forges the answer that a particular victim receives instead. An on-path attacker can answer a query before the real server does. A rogue DHCP server can simply name the attacker's machine as the DNS server, and malware can edit the hosts file. The impact of poisoning and spoofing is the same: web traffic, mail and sign-ins go to systems the attacker controls. If the victim connects with TLS, the fake site cannot show a valid certificate for the real name. A certificate warning, like the cashier's, may be the only visible sign.

Attacks through the air: rogue APs and evil twins

NIST's WLAN security guide, SP 800-153 from February 2012, singles out rogue WLAN devices. An attacker can deploy an access point configured to look like part of the organization's WLAN. Plugged into the wired network, it is a backdoor that bypasses perimeter firewalls. If clients connect to it, the attacker can watch and manipulate their traffic.

Objective 4.2 names two cases. A rogue AP is any unauthorized access point on the network, including one an employee installs for convenience. An evil twin imitates a legitimate network's SSID, often with a stronger signal, so that clients join it instead. Wireless intrusion detection and surveys (Lesson 20) find both. Enterprise Wi-Fi with server certificate validation stops clients trusting an evil twin, and 802.1X on switch ports (Lesson 30) stops a rogue AP from getting network access.

The common thread: on-path attacks

Several of these attacks share a goal. NIST's glossary defines the man-in-the-middle attack, which the objectives call an on-path attack. The attacker is positioned between two communicating parties to intercept or alter the data between them. ARP poisoning, rogue DHCP, DNS spoofing and evil twins are all ways onto the path. The defense that works wherever the attacker sits is authenticated encryption from end to end: TLS with valid certificates, SSH with verified host keys, or IPsec. The attacker still sees the traffic but cannot read it or change it unnoticed.

Attacks on capacity: DoS and DDoS

CISA describes a denial-of-service (DoS) attack as one that leaves legitimate users unable to reach systems or services. It is usually done by flooding the target with traffic until it cannot respond or crashes. CISA's examples include the SYN flood, which starts TCP handshakes (Lesson 7) and never completes them, tying up the server until real users cannot connect. A distributed denial-of-service (DDoS) attack uses many machines at once, typically a botnet of compromised devices. CISA notes that IoT devices, which often keep default passwords, make botnets easy to grow.

Reflection and amplification make DDoS cheap. CISA's alert TA14-017A explains that UDP does not validate source addresses. An attacker can forge the victim's address on small requests to public servers, which then send larger replies to the victim. The alert's table of bandwidth amplification factors includes DNS at 28 to 54, NTP at 556.9 and Memcached at 10,000 to 51,000. The impact is on availability. The defenses sit mostly upstream: DDoS protection services, filtering of spoofed source addresses, and never leaving resolvers or other UDP services open to the whole internet.

The upshot: a DoS exhausts something, whether bandwidth, connection slots or processing, and a DDoS spreads the attack over many sources so that blocking one source does not help.

Attacks on people: social engineering

CISA defines a social engineering attack as one in which the attacker uses human interaction to obtain or compromise information about an organization or its systems. Phishing is the most common form: email or malicious websites that pose as a trustworthy organization to collect information. The exam adds three physical forms.

Attacks in software: malware

NIST's malware guide, SP 800-83 Revision 1 from July 2013, defines malware as a program covertly inserted into another with the intent to compromise confidentiality, integrity or availability. Its classic categories matter to networks because they spread differently.

• A virus inserts copies of itself into programs or files and usually needs a user to open or run something.
• A worm is self-replicating and self-contained. A network service worm exploits a vulnerable service to spread from host to host on its own.
• A Trojan horse appears benign but has a hidden malicious purpose.
• Ransomware, in CISA's description, encrypts files so that they and the systems relying on them become unusable, and then demands payment.

Segmentation, patching and least privilege limit how far malware spreads. Tested backups (Lesson 24) limit what ransomware can take.

Common misconceptions

• "VLANs are a security boundary by themselves." They separate traffic only while the switches are configured correctly. MAC flooding and VLAN hopping break that separation.
• "A DoS attack needs a huge botnet." Reflection and amplification let one attacker's small requests become a far larger flood.
• "ARP spoofing and ARP poisoning are different attacks." They are the act and its result, and many sources treat the names as synonyms.
• "HTTPS makes on-path attacks harmless." Only if certificates are validated and users do not click through warnings.
• "A rogue DHCP server always means an attacker." It is often a consumer router plugged in by someone trying to help.

Pulling it together

Sources

1. Cisco Systems. (n.d.). Layer 2 security features on Cisco Catalyst layer 3 fixed configuration switches configuration example (Document ID 72846). cisco.com
2. Cisco Systems. (n.d.). Best practices for Catalyst 6500/6000 series and Catalyst 4500/4000 series switches running Cisco IOS software (Document ID 24330). cisco.com
3. Plummer, D. C. (1982). An Ethernet address resolution protocol (RFC 826). RFC Editor. rfc-editor.org
4. CERT Coordination Center. (2008). Multiple DNS implementations vulnerable to cache poisoning (Vulnerability Note VU#800113). kb.cert.org
5. Souppaya, M., and Scarfone, K. (2012). Guidelines for securing wireless local area networks (WLANs) (NIST Special Publication 800-153). National Institute of Standards and Technology. csrc.nist.gov
6. National Institute of Standards and Technology. (n.d.). Man-in-the-middle attack (MitM). CSRC glossary. csrc.nist.gov
7. Cybersecurity and Infrastructure Security Agency. (2021). Understanding denial-of-service attacks. cisa.gov
8. Cybersecurity and Infrastructure Security Agency. (2019). UDP-based amplification attacks (Alert TA14-017A, last revised December 18, 2019). cisa.gov
9. Cybersecurity and Infrastructure Security Agency. (2021). Avoiding social engineering and phishing attacks. cisa.gov
10. Souppaya, M., and Scarfone, K. (2013). Guide to malware incident prevention and handling for desktops and laptops (NIST Special Publication 800-83 Revision 1). National Institute of Standards and Technology. csrc.nist.gov
11. Cybersecurity and Infrastructure Security Agency. (n.d.). Ransomware 101. StopRansomware. cisa.gov
12. Wireshark Foundation. (n.d.). Sample captures (dhcp.pcap, teardrop.cap, arp-storm.pcap). Wireshark Wiki. wiki.wireshark.org

The job: harden the warehouse before it opens

Lesson 29 listed the attacks. Objective 4.3 asks you to apply the defenses, and it begins "given a scenario," so expect to choose the right control for a described situation. This lesson works through one job in order. Harbor's new warehouse has an access switch, a few access points, an edge firewall and two public servers, and none of it may go live until it is hardened. Each step names the objective items it covers.

Step 1: Replace default credentials

Every device arrives with a known way in. Default usernames and passwords are published in manuals, and attackers try them first. CISA's Secure by Design alert of December 2023 urges manufacturers to eliminate the risk of default password exploitation altogether. Until every vendor does, removing defaults is your job. Give each device a unique, long administrator password kept in a password manager. Better still, send administrator logins to TACACS+ (Lesson 28), so that each engineer signs in as themselves.

On Cisco devices, the vendor's hardening guide adds two details. Use enable secret, not enable password, which uses weak encryption. And do not rely on service password-encryption: it uses a simple cipher that only deters someone glancing at the configuration.

Step 2: Disable unused services and secure management

Every service that listens is something to patch and something to attack. Cisco's guide to hardening IOS devices recommends disabling services the device does not need, because unneeded services can be abused, for example for denial of service. Its list includes old diagnostic small servers, finger, BOOTP, and the HTTP and HTTPS servers when no one manages the device through them. It also suggests turning off CDP and LLDP on interfaces that face untrusted networks; those protocols advertise details such as the device's platform and software version. Then apply Lesson 27: SSH only, with management only from the jump host.

• no ip http server and no ip http secure-server
• line vty 0 15, then transport input ssh
• no cdp enable on each interface facing an untrusted network

Worth holding on to: hardening starts by removing what an attacker would try first: default credentials, then services nobody uses.

Step 3: Shut down unused ports

An unused, enabled switch port is an invitation to anyone with a cable. Shut down every port that has no device, and assign it to an unused parking VLAN, so that even a port enabled by mistake leads nowhere.

• interface range GigabitEthernet1/0/41 - 48
• switchport mode access, switchport access vlan 998 and shutdown

Step 4: Lock down the access ports

Ports that do have users get layered protection against the switch attacks of Lesson 29. First set the mode to access explicitly, so the port never negotiates a trunk. Then add the four features below.

Cisco's port security guide describes the violation modes. Protect silently drops frames from unknown addresses. Restrict drops them too, but also sends an alert, logs a message and counts the violation. Shutdown, the default, puts the port into the error-disabled state. It returns only when an operator enters shutdown and no shutdown, or when automatic recovery is configured. A fourth mode, shutdown vlan, disables only the VLAN where the violation happened. Sticky learning adds the addresses a port learns to the running configuration, so the first devices seen become the permitted ones.

BPDU guard, promised in Lesson 16, uses the same error-disabled state. Cisco's explanation is that a PortFast port connects to an end host and should never receive a BPDU. A port that does probably has a switch attached, which could cause a loop or even take over as root bridge.

• switchport mode access and switchport access vlan 10
• switchport port-security, switchport port-security maximum 2 and switchport port-security violation restrict
• spanning-tree portfast and spanning-tree bpduguard enable
• Globally, ip dhcp snooping, ip dhcp snooping vlan 10 and ip arp inspection vlan 10; on the uplink toward the real DHCP server, ip dhcp snooping trust and ip arp inspection trust

Step 5: Network access control with 802.1X

Port security trusts MAC addresses, and MAC addresses prove little. NIST's intrusion detection guide notes that it is "relatively trivial to spoof a MAC address." NIST's zero trust architecture, SP 800-207, says device identity should rest on enterprise-issued credentials, not on information that cannot be authenticated, such as MAC addresses. That is why MAC filtering, allowing only listed addresses on a port or SSID, is a convenience rather than security, as Lesson 3 warned. Real network access control (NAC) authenticates the device or user before the port opens.

802.1X does this for wired and wireless ports alike. RFC 3580, the guide to using it with RADIUS, names three roles:

1. The supplicant, the device being authenticated, such as a laptop.
2. The authenticator, the switch or access point that demands authentication.
3. The authentication server, usually RADIUS, which checks the supplicant's credentials.

Until authentication succeeds, the port passes only authentication traffic. On success, the RADIUS server can place the port in a particular VLAN, as RFC 3580 describes, so a contractor and an accountant who use the same wall socket land in different networks. Devices that cannot run 802.1X, such as some printers, are often admitted by MAC address instead. That is MAC filtering with the same weakness, so give such devices a restricted VLAN of their own.

Worth holding on to: port security and MAC filtering check addresses, while 802.1X checks credentials. Only the second is access control that an attacker cannot simply copy.

Step 6: Write the security rules

Access control lists (ACLs) on routers and firewalls decide which packets may pass. Cisco's ACL guide sets out how they behave. Entries are checked in sequence and testing stops at the first match, so "the order of the conditions is critical." Every ACL ends with an implicit deny, so traffic that matches nothing is dropped. Standard ACLs match only the source address; extended ACLs also match the destination, protocol and port.

NIST's firewall guide, SP 800-41 Revision 1, adds two principles. Rules should be as specific as possible. And policy should deny by default: block all inbound and outbound traffic that has not been expressly permitted. Here is Harbor's inbound rule set for its public servers, written with documentation addresses:

• ip access-list extended FROM-INTERNET
• permit tcp any host 203.0.113.10 eq 443 for the web server, HTTPS only
• permit tcp any host 203.0.113.25 eq 25 for the mail server, SMTP only
• deny ip any any log, the implicit deny made explicit so that drops are logged

Put the deny line first and it would drop everything, because nothing after a match is read. A stateful firewall (Lesson 4) also lets in the replies to connections that inside hosts started, without a rule for each.

ACLs filter by address and port. Two more rule types look deeper into web traffic. URL filtering allows or blocks web requests by address or by category, such as gambling or known malware sites. Content filtering inspects what comes back, for example blocking executable downloads. NIST's firewall guide notes that outbound HTTP proxies let an organization filter dangerous content before it reaches the requesting PC. It also advises doing content filtering as close to the content receiver as possible.

Step 7: Draw the zones

Rules make sense only once you know which networks you trust. A trusted zone holds systems the organization manages, such as the staff LAN. An untrusted zone holds everything it does not control, above all the internet. Between them sits the screened subnet, the objectives' term for what is often called a DMZ. NIST's firewall guide describes a DMZ as a network on its own firewall interface, where it is common to put public-facing servers such as web and mail servers. Traffic between the DMZ and the protected network still passes through the firewall, so a compromised web server does not hand an attacker the inside.

This answers the placement question from Lesson 4. Firewalls sit where zones meet, and every rule is written as traffic from one zone to another. SP 800-41 recommends port filtering at the outer edge of the network, and probably at places inside it as well.

Step 8: Manage the keys

Hardening leaves a trail of secrets: Wi-Fi pre-shared keys, RADIUS and TACACS+ shared secrets, SSH host keys, the web server's TLS private key, and VPN keys. Key management is the discipline of generating, storing, distributing, rotating and destroying them. NIST's key management recommendation, SP 800-57 Part 1 Revision 5 from May 2020, defines a cryptoperiod as the time span during which a key is authorized for use. A suitable cryptoperiod limits how much is exposed if one key is compromised, and how long attackers have to break it. The document follows each key through states from pre-activation and active to deactivated, compromised and destroyed.

In practice, generate keys on the device or another trusted system and store them where few people can read them. Rotate them on schedule, and at once when someone who knew them leaves. Revoke certificates whose private keys may have leaked. A Wi-Fi key shared by forty staff cannot be withdrawn from just one of them; individual 802.1X credentials (Lesson 20) can.

Worth holding on to: every secret has a life cycle. Know where each key lives, who can read it, and when it will be replaced.

Common misconceptions

• "MAC filtering keeps unknown devices off the network." MAC addresses are visible and easily changed, so an attacker copies an allowed one.
• "Port security and 802.1X do the same job." Port security limits which MAC addresses a port accepts; 802.1X authenticates credentials before the port opens.
• "If no rule matches, the ACL lets the packet through." Every ACL ends with an implicit deny.
• "The screened subnet is safe because it is behind the firewall." Its servers face the internet by design. Treat it as less trusted than the inside, and control traffic from it.
• "Changing the default password once is enough." Each device needs its own password, and shared secrets need rotating whenever someone who knew them leaves.

Summing up

• Device hardening: unique passwords instead of defaults; unused services and ports disabled, with unused ports parked in an unused VLAN.
• Access ports: access mode, port security (protect, restrict or shutdown), BPDU guard, DHCP snooping and Dynamic ARP Inspection.
• NAC: MAC filtering is weak because MACs can be spoofed. 802.1X uses a supplicant, an authenticator and an authentication server, and can assign VLANs.
• Security rules: ACLs are read top-down, first match wins, and an implicit deny ends each one. Deny by default; add URL and content filtering for web traffic.
• Zones: trusted inside, untrusted outside, and a screened subnet for public servers, with rules written zone to zone.
• Key management: cryptoperiods, protected storage, rotation on schedule and on staff changes.

Sources

1. Cybersecurity and Infrastructure Security Agency. (2023). Secure by Design alert: How manufacturers can protect customers by eliminating default passwords. cisa.gov
2. Cisco Systems. (2024). Harden IOS devices (Document ID 13608). cisco.com
3. Cisco Systems. (n.d.). Port security, in Security configuration guide, Cisco IOS XE Cupertino 17.9.x (Catalyst 9300 switches). cisco.com
4. Cisco Systems. (2026). Understand Spanning Tree PortFast and BPDU Guard features (Document ID 10586). cisco.com
5. Cisco Systems. (n.d.). Layer 2 security features on Cisco Catalyst layer 3 fixed configuration switches configuration example (Document ID 72846). cisco.com
6. Scarfone, K., and Mell, P. (2007). Guide to intrusion detection and prevention systems (IDPS) (NIST Special Publication 800-94). National Institute of Standards and Technology. csrc.nist.gov
7. Rose, S., Borchert, O., Mitchell, S., and Connelly, S. (2020). Zero trust architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. csrc.nist.gov
8. Congdon, P., Aboba, B., Smith, A., Zorn, G., and Roese, J. (2003). IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) usage guidelines (RFC 3580). RFC Editor. rfc-editor.org
9. Cisco Systems. (2025). Configure commonly used IP ACLs (Document ID 26448). cisco.com
10. Scarfone, K., and Hoffman, P. (2009). Guidelines on firewalls and firewall policy (NIST Special Publication 800-41 Revision 1). National Institute of Standards and Technology. csrc.nist.gov
11. Barker, E. (2020). Recommendation for key management: Part 1, general (NIST Special Publication 800-57 Part 1 Revision 5). National Institute of Standards and Technology. csrc.nist.gov

Tuesday, 8:40: "The CRM is down"

The ticket is short: "CRM down, sales can't work, URGENT." Priya, on Harbor's help desk, has two choices. She can start changing things, restarting the browser, the PC, the switch, until something works. Or she can follow a method. The first choice sometimes works, and when it does, nobody learns why. When it fails, it can turn one problem into three. Objective 5.1 is the second choice: CompTIA's troubleshooting methodology.

The method has seven steps. None of them is paperwork. Each one prevents a specific, expensive mistake, and exam questions often ask what a technician should do next, so the order matters as much as the content.

So what? The steps are paraphrased here from the objectives document, which is worth reading in the original. Learn them in order, because the exam's favourite question is "what should the technician do next?"

Step 1: Identify the problem

Priya starts by gathering information. Monitoring (Lesson 23) shows the CRM server up, with normal load. She questions users, asking open questions rather than leading ones. "What exactly happens?" The page times out, with no error message. "Since when?" Since this morning. "Who else?" Everyone on the second floor; managers on the third floor are fine. Other websites work. Those answers are symptoms, and they already rule out a lot. The server, the internet link and the users' PCs in general are probably fine.

Next, she determines whether anything has changed. Google's site reliability engineering book, in its chapter on effective troubleshooting, observes that working systems tend to stay working until something acts on them, such as a configuration change or a shift in load. Recent changes are therefore a productive place to start. Harbor's change log (Lesson 22) shows one entry: a firewall rule change on Monday evening.

She duplicates the problem: from a second-floor PC, the CRM times out; from a third-floor PC, it loads. Finally, she approaches multiple problems individually. Two callers also mentioned a printer jam and slow Wi-Fi in the canteen. Those become separate tickets. Bundling them would tempt her to look for one cause that explains all three.

Step 2: Establish a theory of probable cause

First, question the obvious. Is the CRM server running? Yes, the third floor reaches it. Are the second-floor PCs on the network? Yes, other websites work. The SRE chapter makes the same point with a medical saying: "when you hear hoofbeats, think of horses not zebras." Simple, common causes come before exotic ones.

Then choose an approach. The objectives name three, built on the OSI model from Lesson 2.

• Bottom-to-top starts at the physical layer and works up: link lights, cables, then addressing, then applications. It suits symptoms that point low, such as one PC with no connection at all.
• Top-to-bottom starts at the application and works down. It suits symptoms that point high, such as one application failing while everything else works.
• Divide and conquer starts in the middle, often with a layer 3 test such as ping, and moves up or down depending on the result. The SRE chapter calls the same idea bisection: split the system in half, find which half works, and repeat.

Priya's symptoms point high: one application, one floor. Her first theory is DNS, since "a website is down" so often turns out to be a naming problem.

Step 3: Test the theory

From a second-floor PC, nslookup returns the CRM's correct address. The theory is not confirmed, so the method sends her back: establish a new theory, or escalate. She does not "fix DNS anyway." The SRE chapter warns against exactly that pattern: latching on to the cause of a past problem, or chasing correlations that are coincidences.

Her second theory comes from the change log: Monday's firewall change blocks the second floor's subnet. She tests it in two ways. A connection test to the CRM's HTTPS port fails from 10.20.2.0/24 and succeeds from 10.20.3.0/24. The firewall's log shows denies for second-floor addresses to the CRM since Monday at 18:05. The theory is confirmed, and the method's next instruction is to determine the steps to resolve it.

So what? A theory is only a cause once a test confirms it. A disproved theory is progress too, because it removes a whole branch of the search.

Steps 4 and 5: Plan, then implement or escalate

The change request explains the fault. Monday's rule was meant to block the guest network, 10.20.200.0/24, from internal servers, but it was entered as 10.20.2.0/24. The obvious fix is to correct the subnet. Step 4 asks for a plan of action and its potential effects. Correcting the entry must not reopen the guest network. The change needs approval as an emergency change under Lesson 22's process. And the current configuration must be backed up so that the change can be rolled back.

Step 5 says implement the solution or escalate as necessary. Priya has no rights on the firewall, and should not. She escalates to the network team, and a good escalation carries its evidence: the symptoms, the two tests, the log lines and the suspected entry. The network team makes the correction in minutes because the investigation is already done.

Steps 6 and 7: Verify, prevent, document

Verifying full system functionality means more than asking one salesperson. Priya checks the CRM from the second floor, and also confirms that the guest network is still blocked, because that was the original goal of the change. She checks that the third floor is unaffected. Preventive measures follow: a peer review for every firewall change, and a monitoring check that loads the CRM from each floor's subnet every five minutes.

Documentation runs throughout the process, not just at the end. Priya's ticket already holds a timeline, each test and its result. The final note adds the cause, the fix and the lessons learned. For bigger incidents, the SRE book's chapter on postmortems defines a postmortem as a written record of an incident, its impact, the actions taken, the root causes and the follow-up actions. It insists that postmortems be blameless: they look for contributing causes without accusing any person or team.

One caution about order. In a major outage, the SRE chapter advises making the system work as well as possible first, for example by diverting traffic away from a broken component, before hunting for the root cause. That is not a break from the method. It is a plan of action whose purpose is to restore service while the investigation continues.

Reading exam scenarios

Common misconceptions

• "Documentation is the last step." It is numbered last, but the objectives say to document throughout the process.
• "Escalating means failing." Escalation is part of steps 3 and 5. Escalating with evidence is good troubleshooting.
• "When the user says it works, the ticket is done." Verify full functionality, including whatever the fix might have broken, and consider preventive measures.
• "Always start at layer 1." Bottom-to-top is one approach. Choose the approach that fits the symptoms.
• "Restarting things is a harmless first step." A restart can destroy evidence such as logs, counters and tables, and can hide an intermittent fault for a while.

Looking back

• The seven steps, in order: identify the problem; establish a theory; test it; plan the fix and its effects; implement or escalate; verify and prevent; document throughout.
• Identifying the problem includes questioning users, finding what changed, reproducing the problem and separating multiple problems.
• Approaches: bottom-to-top, top-to-bottom and divide and conquer, chosen by the symptoms.
• A disproved theory leads to a new theory or escalation, never to a fix applied anyway.
• Recent changes are the most productive first suspect; postmortems should be blameless.

Sources

1. CompTIA. (2023). CompTIA Network+ N10-009 certification exam objectives (Document version 6.0), objective 5.1. CompTIA (PDF)
2. Jones, C. (2016). Effective troubleshooting. In B. Beyer, C. Jones, J. Petoff, and N. R. Murphy (Eds.), Site reliability engineering: How Google runs production systems (chapter 12). O'Reilly Media. sre.google
3. Lunney, J., and Lueder, S. (2016). Postmortem culture: Learning from failure. In B. Beyer, C. Jones, J. Petoff, and N. R. Murphy (Eds.), Site reliability engineering: How Google runs production systems (chapter 15). O'Reilly Media. sre.google

How to read this lesson

Objective 5.2 covers the bottom of the stack: cables, ports, power and optics. Faults here produce some of the most confusing symptoms in networking. A marginal cable can keep its link light on while corrupting a fraction of frames, so users see "slow" or "sometimes," not "broken." This lesson works like a debugging session. Each case starts with a symptom, shows the evidence a technician gathers, and ends with the diagnosis. The commands are Cisco IOS, and the ideas transfer to any vendor.

One habit first. Counters accumulate from the last reboot or clear, so an old error count tells you little. Run clear counters on the interface, wait while users work, and look again. Counters that climb now are evidence; counters from last month are history.

Case 1: "File transfers crawl at desk 14"

Evidence. show interfaces GigabitEthernet1/0/14 shows input errors and CRC errors rising by hundreds per hour. Both ends report full duplex at 1 Gb/s, so this is not the duplex mismatch of Lesson 16. Cisco's guide to switch port problems defines a CRC error as a frame whose checksum does not match the data received. It lists the usual causes as noise, cabling or NIC problems, and duplex mismatch. It also warns that a link light does not prove a cable is good: a marginal cable can still corrupt packets.

Diagnosis. A cable tester runs a wiremap: are all eight wires connected, pin to pin, with no opens, shorts or crossed pairs? The run passes the basic wiremap. A better tester that measures crosstalk fails it. The Fiber Optic Association calls the split pair the most difficult wiremap fault. One wire of each of two pairs is swapped at both ends, so continuity looks perfect, but the signal travels on wires from different pairs and crosstalk fails. In the FOA's experience, the usual cause is someone using punchdown color codes on jacks. The jack is re-terminated, the counters are cleared, and they stay at zero.

The core of it: rising CRC errors with matching duplex point to the physical layer: the cable, the termination, a connector or interference. Prove it with a tester, not with a guess.

Signal degradation: three ways a good signal goes bad

The same table explains incorrect cable faults. A cable of too low a category may carry 1 Gb/s and fail at 10 Gb/s, as the speed and distance limits in Lesson 5 showed. Unshielded twisted pair (UTP) in an electrically noisy plant collects interference that shielded twisted pair (STP) would reject. Improper termination covers bad crimps, untwisted pairs and wrong pin orders. A crossed pair, which the FOA attributes usually to a 568A termination at one end and 568B at the other, shows up immediately in a wiremap.

Case 2: "The new fiber uplink will not come up"

Evidence. The command show interfaces status lists the port as notconnect, which Cisco describes as no link at layer 1. Next, show interfaces TenGigabitEthernet1/1/1 transceiver detail shows receive power far below the low alarm threshold on both switches. Cisco's guide to troubleshooting fiber links on Catalyst 9000 switches explains that the transmit and receive values are in dBm. The thresholds depend on the transceiver in use, and readings outside them can affect data quality and cause link flaps.

Diagnosis. Check the possible causes in order of likelihood:

1. TX and RX transposed. Each fiber must run from one side's transmitter to the other side's receiver. Both Cisco guides tell you to verify that transmit and receive are crossed correctly between the ends. Swapping the two connectors at one end fixes a transposed pair.
2. Transceiver mismatch. Both ends need compatible optics: the same speed, compatible wavelengths, and the same signalling. The Catalyst fiber guide says a wavelength mismatch causes miscommunication, if the optics can communicate at all.
3. Wrong fiber type. The same guide says the optics and the cabling must both be single-mode or both multimode. A multimode short-reach optic on a single-mode run is an incorrect-cable fault.
4. Dirty or damaged fiber. Clean the connectors, then trace the strands.

A visual fault locator (VFL) helps with the last two. The FOA describes it as a visible red laser, at 635 to 650 nm, injected into the fiber. Where it lights the far end, the strand is continuous. At a break or a tight bend, the light escaping through the jacket can be visible. In this case, red light appears at the far end of both strands, so the fibers are intact, and the transposed pair is confirmed. Never look into a fiber that might be connected to a live transmitter; the infrared light that optics use is invisible and can harm the eye.

The core of it: for a dead fiber link, read the transceiver's light levels first. No light received usually means transposed strands, a mismatch or a break; low light means dirt, bends or too much distance.

Case 3: "Three of the new cameras never power on"

Evidence. Twelve PoE cameras were added to a 48-port switch. The first nine work; the last three show no power. show power inline lists the switch's available, used and remaining watts, and the remaining figure is close to zero. The log holds messages that power was denied.

Diagnosis. Cisco's PoE guide explains the behavior. If granting a device's request would exceed the switch's power budget, the switch denies power to that port, turns it off and logs a syslog message, then periodically checks the budget again. The budget depends on the installed power supplies. The fix is more power, by adding a supply, moving cameras to another switch or using midspan injectors, or less demand.

The second PoE fault is the incorrect standard. Cisco's guide notes that IEEE 802.3at (PoE+) raised the maximum per port from 15.4 W under 802.3af to 30 W. Its class table runs from Class 0 at 15.4 W to Class 8 at 90 W at the switch, the top classes coming from 802.3bt. An access point that needs a Class 4 budget gets too little power from an 802.3af-only port. Depending on its design, it may start in a reduced mode or not start at all.

Case 4: "Port 22 is down after the weekend"

Three port states look alike in a hurry and mean very different things.

Cisco's port guide stresses that automatic error-disable recovery does not fix the underlying problem: the port simply fails again. Cisco's EtherChannel guide gives the reasons for suspension. Ports with a misconfigured port mode or VLAN mask are suspended, and so are ports whose LACP partner stops responding. Members must match in speed, duplex, native VLAN, allowed VLANs and trunking mode. In show etherchannel summary, a suspended member carries the flag s.

The core of it: administratively down is a human decision; err-disabled is the switch protecting itself; suspended is a bundle refusing a member that does not match.

Reading the counters

Input errors are a total of several counters. Cisco notes that the total will not equal the sum of its parts, because one frame can trigger more than one error.

The hardware toolkit

The tap deserves a note. Wireshark's capture setup page lists arguments for a passive tap over a switch's monitor (SPAN) port. A monitor port does not pass bad frames, too-short or too-long frames, or malformed packets, and it can change timing. When the problem is physical, a capture from a SPAN port can look perfectly clean.

Common misconceptions

• "The link light is on, so the cable is fine." Cisco warns that a marginal cable can keep a link while corrupting frames.
• "A cable that passes continuity is correctly wired." A split pair passes a basic DC wiremap and still fails crosstalk.
• "Re-enabling an err-disabled port fixes it." The switch disabled it for a reason. Remove the cause first, or it fails again.
• "PoE is PoE." 802.3af, 802.3at and 802.3bt deliver different power, and the whole switch has a budget.
• "Any optic fits any fiber." Mode, wavelength, speed and connector polish must all match.

What to remember

• Clear counters, then watch. Rising CRC errors with matching duplex point to cabling, termination or interference.
• Degradation: attenuation (distance), crosstalk (untwisted or split pairs) and interference (noise; consider STP or fiber).
• Fiber: check light levels with the transceiver's DOM readings; TX/RX transposed, mismatched optics, wrong fiber mode or a break are the usual causes. A VFL proves continuity.
• PoE: the switch denies power when its budget is exhausted; 802.3af gives 15.4 W, 802.3at 30 W, and 802.3bt up to 90 W at Class 8.
• States: administratively down (shutdown), err-disabled (fix the cause), suspended (EtherChannel mismatch).
• Tools: toner to find, cable tester to verify, tap to capture everything, VFL to see fiber faults.

Sources

1. Cisco Systems. (2023). Troubleshoot switch port and interface problems (Document ID 12027). cisco.com
2. Cisco Systems. (2025). Troubleshoot fiber links on Catalyst 9000 series switches (Document ID 222738). cisco.com
3. Cisco Systems. (n.d.). Configuring Power over Ethernet, in Interface and hardware components configuration guide, Cisco IOS XE Dublin 17.11.x (Catalyst 9300 switches). cisco.com
4. Cisco Systems. (n.d.). Configuring EtherChannels, in Layer 2 configuration guide, Cisco IOS XE 17.12.x (Catalyst 9300 switches). cisco.com
5. Fiber Optic Association. (n.d.). UTP cable testing and Wiremap testing. thefoa.org (testing); thefoa.org (wiremap)
6. Fiber Optic Association. (n.d.). Visual tracing and fault location. thefoa.org
7. Wireshark Foundation. (n.d.). Ethernet capture setup. Wireshark Wiki. wiki.wireshark.org

The problem: "I can't reach the server"

That sentence could describe a dozen faults. Objective 5.3 lists the ones that live above the cable. Switching faults include spanning tree, VLAN assignment and ACLs. Routing faults sit in the routing table and default routes. Addressing faults include an exhausted address pool, a wrong default gateway, a wrong or duplicate IP address, and a wrong subnet mask. Their symptoms overlap, so the skill is to let a few commands narrow the list quickly.

Objective 5.5 names the device commands you need. Cisco's current syntax differs slightly from the names in the objectives, so here are both.

Each problem below starts with what users report, then follows the commands to the cause.

Problem 1: a whole floor loses the network at once

Lesson 16 described the mechanism: a loop with nothing blocking it multiplies broadcasts until links saturate. Cisco's guide to spanning-tree problems gives the troubleshooting view. A bridging loop is likely when all users in a bridge domain lose connectivity at the same time. Port utilization shows abnormal values, and a capture shows the same packets again and again. The guide's advice for a live loop is practical. Use the network diagram to know the expected root and blocked ports, find the links with abnormal utilization, and disable suspected redundant ports one at a time, checking connectivity after each. Do this through the console or an out-of-band path (Lesson 27), because the in-band network may be unusable.

Cisco lists the usual reasons spanning tree fails to prevent a loop: duplex mismatches, unidirectional links, packet corruption, overloaded CPUs, PortFast configuration errors, aggressive tuning of timers, and software errors. The most common human cause is simpler: a cable joining two wall jacks on a port without BPDU guard. Once the loop is broken, prevent the next one with BPDU guard on edge ports (Lesson 30), and never fix a loop by disabling spanning tree.

Bottom line: sudden, total, floor-wide failure with saturated links and repeated frames is a loop until proved otherwise. Break it from the console, then find out why spanning tree did not.

Problem 2: traffic takes a strange path

Users in one building complain that file transfers crawl, though nothing is down. On the core switch, show spanning-tree vlan 10 shows a Root ID different from the switch's own Bridge ID. The root is an old access switch in a closet. The output also lists each port's role (Root, Desg for designated, Altn for alternate) and state (FWD for forwarding, BLK for blocking). On the core, the fast uplink to the server farm is an alternate port, blocking.

The cause is in Lesson 16: with every priority left at 32768, the switch with the lowest MAC address wins, and it is often the oldest. Cisco's guide advises against leaving root selection to spanning tree. Choose a powerful switch in the middle of the network as root, and another as backup root, for each VLAN. Set them with a lower bridge priority, or with spanning-tree vlan 10 root primary on the chosen root and root secondary on its backup. Once the root moves, port roles are recalculated, and the fast uplink becomes a root port that forwards.

Roles and states also explain stranger symptoms. A port that should forward but shows an alternate role is blocked by design, so look at the root placement and the path costs. Under classic 802.1D, a port that sits in listening or learning for 30 seconds every time a PC boots needs PortFast.

Problem 3: one PC gets the wrong address

A new PC on the second floor gets an address from the voice subnet, and none of the business applications work. Start from the device. Its MAC address, from ipconfig /all, goes into show mac address-table address followed by that MAC, which returns the switch port, GigabitEthernet1/0/7 (the use Lesson 3 promised). Then show interfaces GigabitEthernet1/0/7 switchport shows the port's access VLAN as 20, the voice VLAN, instead of 10. show vlan brief confirms it, listing port 7 under VLAN 20.

The fix is switchport access vlan 10 on that port, then a DHCP renewal on the PC. An incorrect VLAN assignment shows up in one of two ways. The device gets an address from the wrong scope, or it gets no address at all if that VLAN has no DHCP service. Either way, the switch configuration, not the PC, is where the fault lives.

Problem 4: one application stops after a change

After a security change, accounting can no longer reach the finance server, though everything else works. On the router, show ip interface shows which ACL is applied to the interface, and in which direction. Then show access-lists shows each entry with a count of matches. The counters climb on the final, explicit deny line and stay at zero on the permit line meant for accounting. The permit names the wrong subnet. Cisco's ACL guide gives the two rules behind this, both from Lesson 30: entries are processed in order until the first match, and anything unmatched meets the implicit deny.

Bottom line: when a single flow fails after a change, read the ACL's match counters. They show which line is deciding the traffic's fate.

Problem 5: some destinations are unreachable

A branch office reaches headquarters but not the internet. On the branch router, show ip route lists the headquarters networks, learned through the routing protocol, and the line "Gateway of last resort is not set." There is no default route, so packets for any destination not in the table are dropped. The fix is a default route toward the ISP, such as ip route 0.0.0.0 0.0.0.0 203.0.113.1. Then show ip route again, to confirm that the gateway of last resort is set.

Route selection, from Lesson 17, causes the subtler faults. The longest matching prefix wins, so a forgotten static route for 10.20.0.0/16 can steal traffic meant to follow a /8 learned from OSPF. Administrative distance decides between sources, so a static route with a lower distance overrides the dynamic one. Traceroute, covered in Lesson 35, shows where along the path packets stop.

Problem 6: latecomers get 169.254 addresses

At 2 p.m., new laptops joining the guest Wi-Fi get 169.254 addresses, while those that connected in the morning work. An address in 169.254.0.0/16 is an IPv4 link-local address (RFC 3927), which a host gives itself when DHCP produces no lease (Lesson 9). The pattern matters. If every client on a subnet gets 169.254, suspect the DHCP server, the relay (Lesson 25) or the VLAN. If only the latest arrivals do, suspect address pool exhaustion. The DHCP server's scope statistics confirm it: every address in the /24 is leased, most of them to phones that left hours ago, because guest leases last eight days.

The fixes match the cause: a shorter lease time on the guest scope, a larger subnet for the guest network, or both. Rogue or misbehaving clients that grab many leases call for DHCP snooping and its rate limiting (Lesson 30).

Problem 7: addresses that are wrong, doubled or badly masked

Four addressing faults look alike at first: something does not work. Their exact pattern of what works and what fails tells them apart.

For a duplicate IP address, RFC 5227 describes how hosts probe with ARP before using an address and keep watching for conflicts afterwards. It also notes that conflicts still happen, for example when two hosts were out of contact while they configured themselves. To find the culprit, take the second MAC address from show ip arp on the router and look it up with show mac address-table address to find its port. Then fix the static configuration, or add a DHCP exclusion for statically assigned addresses.

The incorrect subnet mask needs one example. Lesson 3 explained that a host uses its mask to decide whether a destination is local, so it should ARP directly, or remote, so it should send to the gateway (RFC 1122). Suppose a host is 10.10.5.20/16 instead of /24. It can reach the internet, because 8.8.8.8 is clearly remote and goes to the gateway. But it treats the printer at 10.10.9.30 as local, ARPs for it on its own segment, gets no answer, and fails. Too long a mask causes the opposite fault: neighbours outside the narrower range look remote, so traffic to them detours through the router or fails.

Bottom line: map what works against what fails. Local-only success points to the gateway; intermittent success points to a duplicate; success that depends on the destination points to the mask or the routes.

Common misconceptions

• "Turn off spanning tree to stop the loop." Spanning tree is what prevents loops. Remove the looping link and find out why STP failed.
• "169.254 means the DHCP server is down." It means no lease was obtained. Exhaustion, a missing relay or the wrong VLAN produce it too.
• "If I can ping the gateway, routing is fine." The gateway may have no route, or no default route, to the destination.
• "The fastest switch automatically becomes root." The lowest bridge ID wins; set priorities deliberately.
• "A wrong mask breaks everything." It often breaks only some destinations, which makes it easy to misdiagnose.

The takeaway

• Loops: sudden floor-wide outage, saturated links, repeated frames. Break the loop from the console; prevent it with BPDU guard.
• Root bridge: place it deliberately with priority or root primary and secondary; read roles and states in show spanning-tree.
• Wrong VLAN: trace MAC to port with show mac address-table, then check show interfaces switchport and show vlan brief.
• ACLs: read the match counters in show access-lists; order and the implicit deny decide.
• Routes: show ip route; longest prefix wins; "Gateway of last resort is not set" means no default route.
• Addresses: 169.254 for latecomers means exhaustion; local-only reach means a bad gateway; intermittent reach means a duplicate; destination-dependent reach means a bad mask.

Sources

1. Cisco Systems. (2026). Troubleshoot STP problems and related design considerations (Document ID 10556). cisco.com
2. Cisco Systems. (n.d.). Understand Rapid Spanning Tree Protocol (802.1w) (Document ID 24062). cisco.com
3. Cisco Systems. (2025). Configure commonly used IP ACLs (Document ID 26448). cisco.com
4. Cisco Systems. (n.d.). Configure route selection for routers (Document ID 8651). cisco.com
5. Cheshire, S., Aboba, B., and Guttman, E. (2005). Dynamic configuration of IPv4 link-local addresses (RFC 3927). RFC Editor. rfc-editor.org
6. Cheshire, S. (2008). IPv4 address conflict detection (RFC 5227). RFC Editor. rfc-editor.org
7. Braden, R. (Ed.). (1989). Requirements for Internet hosts: Communication layers (RFC 1122), section 3.3.1.1. RFC Editor. rfc-editor.org

"Slow" is five different problems

When users say the network is slow, they are describing a feeling. Objective 5.4 asks you to turn it into a measurement, because each kind of slowness has different causes and fixes. The first step is to ask which quantity is bad. The table compares them.

Key idea: bandwidth is what the link could carry and throughput is what you actually get. Latency, loss and jitter decide how the traffic feels, especially for voice and video.

Congestion, contention and bottlenecks

Three related words describe demand meeting capacity. Congestion is demand greater than capacity at some point, so packets queue and, when queues fill, are dropped. Contention is many devices competing for a shared resource, such as Wi-Fi airtime or an oversubscribed uplink. A bottleneck is the most constrained point on a path, which caps throughput for everything behind it. A branch with a 1 Gb/s LAN and a 200 Mb/s internet circuit will never see more than 200 Mb/s to the internet, however fast its switches.

The evidence is in the counters you met in Lesson 32. Cisco's guide to switch port problems explains that output drops count packets discarded because the output queue was full, and that a common cause is a faster link feeding a slower one. Utilization graphs from monitoring (Lesson 23) show the busy hours. A tell-tale pattern is latency that rises with load: ping to the data center takes 2 ms at night and 80 ms at 10 a.m. The extra delay is time spent waiting in queues.

There are three kinds of fix. Add capacity, with a faster link or link aggregation (Lesson 16). Reduce demand at peak, for example by moving backups to the night. Or protect the traffic that matters with quality of service (Lesson 4). QoS has limits. Cisco's guide to QoS for voice over IP says that enough bandwidth must be provisioned before QoS features are applied, because QoS cannot replace it. Priority queuing decides who waits; it does not make the link bigger.

Latency, jitter and loss compared

Latency has several parts. Propagation delay depends on distance; Lesson 5 noted that a geostationary satellite path adds at least about 0.48 seconds. Serialization delay depends on link speed. Cisco's VoIP guide gives the example that a 1,500-byte packet takes about 187.5 ms to transmit on a 64 kb/s link, so a voice packet can wait that long behind one large data packet. Queuing delay depends on congestion, and processing delay on the devices in the path. Only queuing and serialization respond to more bandwidth or QoS; no setting shortens the distance.

Jitter is the everyday name for delay variation. RFC 3393, which defines the IP packet delay variation metric, notes that the term "jitter" is used in different ways by different groups. It prefers the more precise "delay variation." Real-time applications absorb jitter with jitter buffers, which hold packets briefly and play them out evenly. Cisco's VoIP guide notes the cost: jitter buffers add to end-to-end delay, and they are usually effective only for variations under about 100 ms.

Packet loss hurts applications differently. TCP retransmits lost segments, so file transfers slow down but complete. Voice and video cannot wait for a retransmission, so the loss is heard or seen. Cisco's VoIP guide says the G.729 codec needs loss well below 1 percent to avoid audible errors.

These figures come from Cisco's QoS best-practices summary. Treat them as design targets, not laws of physics.

Key idea: latency is how long, jitter is how unevenly, and loss is how often packets fail to arrive. Real-time traffic is hurt by all three; bulk transfers mostly by loss and latency.

Measuring: speed testers and iperf3

A speed tester measures throughput between your device and a test server. M-Lab describes its NDT test as a single-stream measurement of a connection's capacity for bulk transport, reporting upload and download speeds and latency. Two consequences follow. The result describes one path to one server, at one moment. And a test run over Wi-Fi measures the Wi-Fi as much as the internet circuit. Before blaming the provider, repeat the test on a cable, close to the router.

For a test you control from end to end, ESnet's iperf3 performs active measurements of the maximum achievable bandwidth between two hosts. For each test it reports the throughput, loss and other parameters. Run iperf3 -s on one of your own computers and iperf3 -c followed by its address on another. Add -u for a UDP test, which reports loss and jitter. To find where loss occurs along a path, Microsoft's pathping sends repeated probes to each router on the way and computes loss at each hop; mtr does the same on Linux.

Wireless problems compared

Wi-Fi adds a shared, invisible medium, so it has its own list in objective 5.4. A Wi-Fi analyzer is the first tool for all of them. It lists the networks in range with their BSSIDs, channels and signal strengths. Dedicated apps add graphs. Windows has netsh wlan show networks mode=bssid and netsh wlan show interfaces, and Linux has nmcli device wifi list.

Cisco Meraki's documentation supplies the numbers and causes behind the table. It lists interference sources that include microwave ovens, cordless phones, Bluetooth devices, wireless cameras, fluorescent lights and other 802.11 networks. Two APs on the same channel share that channel's capacity. Its definition of signal-to-noise ratio (SNR) is the difference between the received signal and the noise floor. It recommends 20 dB or more for data networks and 25 dB or more for voice. Its site survey guidance describes a classic voice-grade design with cell edges around -67 dBm and an SNR of 25 dB or more.

On roaming, Meraki explains that the client, not the AP, decides when to roam, normally when it detects a better signal from another AP. A client that stays on a distant AP is called a sticky client, and Meraki's troubleshooting guide suggests reducing transmit power or raising the minimum bit rate. Its roaming guide warns that some legacy devices may not connect to a network with 802.11r fast roaming enabled, and recommends auditing devices first. The same guide notes that APs share client information during a roam using broadcasts, so upstream port isolation must not block them.

The corner office, solved

Lesson 20 left a complaint open: the Wi-Fi is slow in the corner office. A Wi-Fi analyzer at the desk shows the laptop associated to AP-3, across the floor, at -76 dBm with an SNR of 14 dB. AP-5, in the next room, is visible at -55 dBm but shares channel 6 with a neighbour's network. Two problems, then: a sticky client on a weak signal, and co-channel contention on the nearer AP. Lowering AP-3's transmit power and raising the minimum bit rate pushes the laptop to roam, and moving AP-5 to channel 11 removes the overlap. A speed test from the desk, before and after, documents the result.

Key idea: on Wi-Fi, look at signal, SNR, channel and which AP the client chose before touching anything else.

Common misconceptions

• "Bandwidth and throughput are the same thing." Bandwidth is capacity; throughput is what you achieve, limited by the bottleneck, loss and latency.
• "A speed test measures my network." It measures one path to one server at one moment, often through Wi-Fi.
• "More bandwidth fixes latency." It shortens queuing and serialization, but not propagation over distance.
• "Turn every AP to full power." High power encourages sticky clients and spreads co-channel contention.
• "Jitter buffers fix jitter for free." They trade jitter for added delay, and only work for modest variation.

Recap

• Bandwidth is capacity; throughput is achieved rate; latency, loss and jitter shape the experience.
• Congestion fills queues, raising latency and causing drops; the bottleneck caps throughput. QoS protects priority traffic but cannot replace capacity.
• Voice design targets in Cisco's summary: 150 ms one-way delay, 30 ms jitter, 1 percent loss.
• Measure with ping, traceroute, pathping or mtr, speed testers and iperf3, using your own endpoints.
• Wi-Fi: interference and channel overlap, weak signal and low SNR (20 dB data, 25 dB voice), coverage gaps, disassociation and roaming problems; start with a Wi-Fi analyzer.

Sources

1. Cisco Systems. (2001). Quality of service for voice over IP. cisco.com
2. Cisco Systems. (n.d.). QoS best practices at-a-glance. cisco.com (PDF)
3. Demichelis, C., and Chimento, P. (2002). IP packet delay variation metric for IP performance metrics (IPPM) (RFC 3393). RFC Editor. rfc-editor.org
4. Cisco Systems. (2023). Troubleshoot switch port and interface problems (Document ID 12027). cisco.com
5. Measurement Lab. (n.d.). NDT (Network Diagnostic Tool). measurementlab.net
6. ESnet. (n.d.). iperf3. software.es.net
7. Microsoft. (n.d.). pathping [Windows commands reference]. Microsoft Learn. learn.microsoft.com
8. Microsoft. (n.d.). Netsh commands for wireless local area network (WLAN). Microsoft Learn. learn.microsoft.com
9. NetworkManager project. (n.d.). nmcli. networkmanager.dev
10. Cisco Meraki. (n.d.). Common sources of wireless interference; Signal-to-noise ratio (SNR) and wireless signal strength. Meraki documentation. documentation.meraki.com (interference); documentation.meraki.com (SNR)
11. Cisco Meraki. (n.d.). Conducting site surveys with MR access points. Meraki documentation. documentation.meraki.com
12. Cisco Meraki. (n.d.). Wireless issue resolution guide; Roaming technologies. Meraki documentation. documentation.meraki.com (troubleshooting); documentation.meraki.com (roaming)

The job: match the tool to the question

Objective 5.5 is a toolbox: software tools, command-line utilities, hardware tools and device show commands. The exam phrases it "given a scenario, use the appropriate tool or protocol." So the skill is not reciting what each tool is. It is knowing which one answers the question in front of you, and reading its output correctly. This last lesson gives a four-step procedure, a reference for every tool on the list, and practice with scenarios that cross all five domains.

Step 1: Write down the question

Before touching a keyboard, say what you need to know, in one sentence. "Is this PC configured correctly?" "Can it reach the gateway?" "Does the name resolve?" "Where along the path do packets stop?" "Is anything listening on port 443?" "What is actually on the wire?" "Which switch port is this device on?" Each question has a tool that answers it directly. A vague goal, such as "check the network," leads to running tools at random.

Step 2: Pick the tool that answers it

The point: every tool answers a particular question. Name the question first and the tool almost chooses itself.

Step 3: Read the output for what it really says

Most tool mistakes are reading mistakes. Here are the outputs that matter most, tool by tool.

ipconfig, ip and ifconfig. Microsoft describes ipconfig as displaying all current TCP/IP configuration values and refreshing DHCP and DNS settings. Read four values every time: address, mask, gateway and DNS server. A 169.254 address means no DHCP lease (Lesson 33). ipconfig /release and /renew request a new lease, and /flushdns clears the DNS client cache. On Linux, the ip command shows and changes addresses, routes and devices.

ping. A reply proves the round trip works, at least for ICMP. A timeout proves less than it seems, because many hosts and firewalls block echo requests (Lesson 1). Ping from the inside out: loopback, own address, gateway, a remote address, then a remote name. The first failure marks the layer to investigate.

traceroute and tracert. This is the TTL trick that Lesson 4 promised. Microsoft explains that tracert sends ICMP echo requests with increasing TTL values. Each router must decrement the TTL, so the router where it reaches zero discards the packet and reports back. The first probe, with TTL 1, reveals the first router; TTL 2 reveals the second, and so on. The Linux traceroute manual describes the same use of TTL, and notes that its default method sends UDP probes rather than ICMP. A line of asterisks means no reply for that hop. If later hops answer, that router simply does not reply to probes; if nothing answers after it, the path probably breaks there.

nslookup and dig. Both query DNS directly, as Lesson 26 showed. Ask the default server, then name a different server, to tell a broken resolver from a broken record.

arp. Shows the IP-to-MAC mappings a host has learned (Lesson 3). It is how you spot a duplicate address or a poisoned gateway entry.

netstat and ss. Microsoft's netstat displays active TCP connections, listening ports, Ethernet statistics and the IP routing table. On Linux, its manual calls it mostly obsolete and names ss as the replacement, and ip route for its routing view. If nothing is listening on the port a service should use, the network is not the problem.

tcpdump and Wireshark. tcpdump prints a description of packets matching a filter expression, or saves them with -w for later analysis, which suits servers without a graphical desktop. Wireshark's user's guide calls it a network packet analyzer that presents captured data in as much detail as possible. A typical pairing is tcpdump -i eth0 -w capture.pcap port 53 on the server, then the file opened in Wireshark on a workstation. Capture only traffic you are authorized to see.

Step 4: Let the result choose the next tool

Each result should move you up or down the stack, the divide-and-conquer approach of Lesson 31. A ping to the gateway fails: look down, at the address, the VLAN or the cable. It succeeds but a remote ping fails: look at routes with tracert or traceroute and show ip route. Pings by address work but names fail: use nslookup or dig. Everything resolves and routes, but one application fails: check netstat or ss on the server, then capture.

Discovery tools: LLDP, CDP and Nmap

Cisco's configuration guide describes the Link Layer Discovery Protocol (LLDP) as a vendor-neutral protocol, defined in IEEE 802.1AB, that devices use to advertise information about themselves to directly connected neighbours. The Cisco Discovery Protocol (CDP) is Cisco's proprietary equivalent. On a switch, show lldp neighbors detail or show cdp neighbors detail names the device on each port, its model, its port and often its management address.

Lesson 15 promised a word on LLDP-MED, the media endpoint extensions. Cisco lists what they add: capabilities discovery, a network policy that tells an IP phone its voice VLAN and QoS markings, power management, inventory details and location. That is how a phone on a non-Cisco switch can learn its voice VLAN automatically. The same guide notes that LLDP is disabled by default on those switches. Lesson 30 explained why hardening guides turn discovery protocols off on interfaces facing untrusted networks.

Nmap, in its own reference guide, is an open source tool for network exploration and security auditing. It uses raw packets to find which hosts are available, which services and versions they offer, and which operating systems they run. That is exactly why permission matters.

Lesson 1 promised to explain, and the explanation is simple: probing systems you do not control can break the law, depending on what you do and where you are. Nmap's author, writing about the legal issues of scanning, advises asking a competent lawyer in your jurisdiction. He also says the best way to avoid controversy is to secure written authorization from the target network's representatives before any scanning. He adds that people are rarely troubled for scanning their own machines or networks they administer.

Laws such as the US Computer Fraud and Abuse Act (18 U.S.C. 1030) and the UK Computer Misuse Act 1990 make unauthorized access a crime; the Sources link to both. In this course, the rule is absolute: scan only your own devices, in your own lab, or a network whose owner has authorized you in writing.

The point: discovery protocols tell you what is connected; Nmap tells you what is listening. Use the first freely on your own switches, and the second only with written permission.

Exam practice: performance-based questions

Lesson 1 described performance-based questions (PBQs): tasks such as configuring a device, matching tools to situations or reading a topology, which take several minutes each. The procedure above is how to work them.

1. Read the whole task first and list exactly what it asks for. Many PBQs have several parts.
2. Read every exhibit: topology, command output, logs. The answer is usually in an output you skimmed.
3. Apply the troubleshooting method from Lesson 31 quickly: symptoms, likeliest cause, the evidence that confirms it.
4. Answer exactly what is asked, no more. A correct fix in the wrong place scores nothing.
5. Watch the clock. If one PBQ is eating your time, give it your best answer and move on.

Capstone scenarios across the domains

Common misconceptions

• "If ping fails, the host is down." ICMP may be filtered. Test the actual service, or ARP for the host on its own subnet.
• "Asterisks in traceroute mean the path is broken there." Only if nothing answers after that hop; many routers simply do not reply to probes.
• "nslookup failing means the DNS record is missing." The resolver may be unreachable or broken. Ask another server to tell the two apart.
• "Nmap is fine on any network I can reach." Reachability is not permission. Get written authorization, or scan only your own lab.
• "LLDP and CDP are harmless everywhere." They advertise device details, so hardening guides disable them on untrusted interfaces.

What to carry forward

• Name the question, pick the tool that answers it, read the output carefully, and let the result choose the next tool.
• ipconfig, ip or ifconfig for configuration; ping for reachability; tracert or traceroute for the path; nslookup or dig for names; arp for MAC mappings; netstat or ss for listeners; tcpdump and Wireshark for the wire.
• traceroute raises the TTL one hop at a time; asterisks alone do not prove a break.
• LLDP (802.1AB) and CDP identify neighbours; LLDP-MED hands phones their voice VLAN and power details.
• Nmap discovers hosts and services, and is used only with written authorization or in your own lab.
• For PBQs: read the whole task and every exhibit, apply the method, answer exactly what is asked, and manage the clock.

Sources

1. Microsoft. (n.d.). ipconfig, tracert and netstat [Windows commands reference]. Microsoft Learn. ipconfig; tracert; netstat
2. Linux man-pages project. (n.d.). traceroute(8), netstat(8) and ip(8). traceroute; netstat; ip
3. The Tcpdump Group. (n.d.). tcpdump(1) manual page. tcpdump.org
4. Wireshark Foundation. (n.d.). Wireshark user's guide, chapter 1: Introduction. wireshark.org
5. Cisco Systems. (n.d.). Configuring LLDP, LLDP-MED, and wired location service, in Interface and hardware components configuration guide, Cisco IOS XE 17.18.x (Catalyst 9300 switches). cisco.com
6. Lyon, G. (n.d.). Nmap reference guide. Nmap.org. nmap.org
7. Lyon, G. (n.d.). Legal issues. In Nmap network scanning. Nmap.org. nmap.org
8. Legal Information Institute. (n.d.). 18 U.S. Code 1030: Fraud and related activity in connection with computers. Cornell Law School. law.cornell.edu
9. UK Parliament. (1990). Computer Misuse Act 1990. legislation.gov.uk. legislation.gov.uk
10. CompTIA. (2023). CompTIA Network+ N10-009 certification exam objectives (Document version 6.0), objective 5.5. CompTIA (PDF)