Guided Labs

The labs turn a concept into a decision you can explain. Read the scenario and objective first, record your expected result, and open the hints only after a genuine attempt. Use a private lab, VM, simulator, or devices you own.

Safety: Never scan, change, or troubleshoot systems and networks without explicit permission. Use documentation addresses, local VMs, and disposable test data.

A reliable lab method

1. State the expected result before changing anything.
2. Make one change at a time.
3. Record the command, time, actual output, and interpretation.
4. Distinguish “it works” from evidence that explains why.
5. Return the test environment to a known state.

Lab 1: Plan a small IPv4 network

Scenario: A small office needs a router, a network printer, and up to ten clients. You have 192.168.50.0/28.

Objective: Determine the boundaries and allocate static and dynamic addresses without overlap.

Prerequisites: IPv4 Basics and the subnetting practice.

1. Calculate the mask, network, broadcast, and conventional host range.
2. Reserve the first usable address for the gateway and one for the printer.
3. Choose a DHCP range for ten clients.
4. Leave at least two addresses as documented capacity for future devices.
5. Explain why the network and broadcast addresses are not assigned to ordinary hosts.

Hints

A /28 has four host bits and sixteen total addresses. The DHCP pool must exclude the gateway, printer, network address, and broadcast address.

Solution outline

The mask is 255.255.255.240, the network is .0, and the broadcast is .15. A valid plan is gateway .1, printer .2, reserves .3–.4, and DHCP .5–.14. Document the exact pool and exclusions rather than relying on memory.

Verify: Recalculate the same block with the Subnet Calculator, then solve a new /27 without it.

Lab 2: Observe ARP and switching

Scenario: Two authorised test clients in the same /24 can ping each other. Explain what the hosts and switch learned.

Objective: Keep the mappings IPv4 → MAC and MAC → switch port separate.

1. Check link and IP configuration on both clients.
2. Inspect the neighbor/ARP cache and, if your simulator allows it, clear it.
3. Clear the dynamic MAC table in the lab only.
4. Ping client B from client A and observe the ARP request, ARP reply, and ICMP exchange.
5. Compare the neighbor cache with the switch MAC table.
6. Repeat the ping and explain why a new ARP request is normally unnecessary.
7. Repeat with B in another subnet. Identify why A needs the gateway’s MAC, not B’s MAC.

Expected result: The host stores an IP-to-MAC mapping. The switch learns source MAC addresses on VLAN-specific ports. A routed destination is sent to the default gateway at Layer 2.

Verify: Use MAC Addresses & Ethernet and write one sentence describing each table.

Lab 3: Build a segmented VLAN design

Scenario: Staff and guest devices share switches but must use separate broadcast domains. Guests must not reach internal clients.

Objective: Connect access ports, trunks, VLANs, subnets, gateways, and policy into one design.

1. Create VLAN 10 for staff and VLAN 20 for guests in a simulator or disposable lab.
2. Assign client ports as access ports in the correct VLAN.
3. Connect switches with a trunk that explicitly allows only the required VLANs.
4. Verify same-VLAN connectivity across the trunk.
5. Add router subinterfaces or SVIs as gateways.
6. Test staff-to-server access and guest-to-internal access.
7. Add a policy that blocks guests from internal prefixes while allowing the required DNS and HTTPS tests.

Troubleshoot in order: link → access VLAN → VLAN existence → trunk allowed list → client prefix → gateway interface → route → policy.

Expected result: Same-VLAN traffic is switched. Inter-VLAN traffic requires a Layer 3 gateway and is then subject to the security policy.

Lab 4: Diagnose “the Internet is down”

Scenario: One client cannot open a website while other devices work.

Objective: Turn a vague report into one evidence-based next test.

1. Ask when it started, whether all destinations fail, and whether other clients are affected.
2. Check link, IP address, prefix, default gateway, and DNS servers.
3. Test loopback, the local address, and the gateway.
4. Test a known documentation IP address in your permitted lab.
5. Resolve a name with nslookup or dig.
6. Test the application port with Test-NetConnection -Port 443 or an authorised equivalent.
7. Use tracert/traceroute only after the simpler tests have a clear result.

Evidence	Narrowed area
169.254.0.0/16 and no gateway	Link, VLAN, or DHCP
Gateway unreachable	Addressing, local link, VLAN, or gateway
IP works but name fails	DNS path or record
Host works but TCP 443 fails	Service, route, or firewall
Name and port work but browser fails	Proxy, TLS, browser, or application

Verify: Write the next test and the reason for it after every result.

Lab 5: Create a VLSM plan

Scenario: Plan 10.10.0.0/23 for office (180 hosts), production (90), guests (50), servers (20), management (10), and two point-to-point links.

Objective: Allocate largest to smallest, preserve alignment, and show remaining capacity.

Create a table containing requirement, prefix, network, first/last host, broadcast, and unused space. Choose the smallest block that meets each requirement. Remember that point-to-point /31 links have different host semantics than ordinary LAN subnets.

Expected result: The blocks do not overlap, each network begins on a valid boundary, and the remaining range is explicit rather than hidden.

Lab 6: Measure a WLAN claim

Scenario: Wi-Fi is slow in one room, but the wired connection is stable.

Objective: Separate RF conditions, local throughput, and the Internet path.

Use two devices you own: an Ethernet-connected test server and a wireless client. Record AP, band, channel width, location, signal, time, and direction. Run a controlled iperf3 test, change one variable, and compare repeated median results. Use a short UDP test only when you understand its effect on loss and jitter.

Expected result: A local result isolates the WLAN better than an Internet speed test, which includes the router, provider, path, and remote server.

Lab 7: Back up and restore a Linux directory

Scenario: A disposable Linux VM contains three harmless text files under ~/bytepath-lab/input.

1. Create input, backup, and restore directories.
2. Record ownership and permissions with stat or ls -l.
3. Create a dated archive with tar -czf.
4. Inspect it with tar -tzf before extracting.
5. Extract into restore and compare with diff -r.
6. Set the archive to mode 640 and explain every permission digit.

Expected result: The restored contents match, the archive contains only intended relative paths, and other users cannot read it.

Lab 8: Return structured PowerShell results

Scenario: You need a repeatable report for an authorised test target, not a screen full of formatted text.

Create Test-NetworkTarget.ps1 with a mandatory Target parameter. Return a [pscustomobject] containing target, timestamp, ping result, and TCP 443 result. Filter failures with Where-Object and export the objects to CSV. Use try/catch for invalid input and keep Format-Table for the final display only.

Expected result: Get-Member shows stable properties and the same result can be filtered, exported, or tested.

Lab 9: Pilot an MFA policy safely

Scenario: A non-production Microsoft 365 tenant must require MFA without locking out administrators.

1. Define scope, identities, success criteria, and rollback criteria.
2. Confirm emergency access accounts are documented and tested.
3. Create a small pilot group with test accounts.
4. Use report-only or equivalent evaluation mode when available.
5. Test expected sign-ins and denied sign-ins from different conditions.
6. Review sign-in logs, document the result, and define the rollback path.
7. Expand gradually only after the pilot is understood.

Expected result: The pilot creates expected logs, emergency access is deliberate, and production users remain outside the first change.

Continue with the knowledge checks, then return to the course section that explains the evidence you observed.