Managing many connections means controlling where traffic can go—and proving that the design works
Unit 3 is where the LAN stops being a simple shared network and becomes an intentional system. Switches, trunks, VLANs, Layer 3 gateways, DHCP, firewalls, and verification all work together. The goal is not “everything can reach everything.” The goal is that required paths work, prohibited paths do not, and the network produces evidence that explains both outcomes.
Each Unit 3 topic adds one more layer of control
3.1 Devices & Connections
Identify switches, routers, APs, firewalls, NICs, media, and link roles.
3.2 Switching Topologies
Understand MAC learning and Layer 2 forwarding.
3.3 Configuration Verification
Compare intended, configured, and operational state.
3.4 Segmentation & Security
Create logical boundaries using VLANs and subnets.
3.5 Firewalls & Filtering
Apply policy between trust zones and services.
3.6 Segmented-LAN Troubleshooting
Trace failures across the whole dependency chain.
Switches and routers make different forwarding decisions
A switch forwards Ethernet frames inside a Layer 2 domain using MAC-address information. A router forwards IP packets between networks using destination prefixes and routing decisions. A Layer 3 switch can do both, but the reasoning boundary still matters.
When troubleshooting, ask first whether the failure is inside the local Layer 2 domain or at the Layer 3 boundary.
A switch learns from source MAC addresses, then forwards based on destination MAC addresses
As frames arrive, a switch records the source MAC and ingress port. When the destination MAC is already known, the switch forwards toward that port. When it is unknown, the switch may flood within the VLAN.
Physical proximity does not determine logical membership
Two endpoints connected to the same physical switch can be in different VLANs and therefore separate Layer 2 broadcast domains. Conversely, one VLAN can span several switches when trunks carry it across the infrastructure.
Endpoint links and infrastructure links solve different problems
Access port
Typically associates endpoint traffic with one VLAN.
Trunk
Typically carries multiple VLANs across infrastructure.
Failure clue
One VLAN failing while others work points toward VLAN-specific state.
If VLAN 30 is missing from a trunk, devices in VLAN 30 may work locally on one switch but fail to reach same-VLAN resources across the trunk.
Working VLANs become controls for the failed VLAN
This is much stronger than treating the trunk as simply “up” or “down.”
Entered commands are intent, not proof
A technician can configure VLAN 30 on a port and still have an operational failure. Verify the VLAN exists, the port is operationally in VLAN 30, the trunk carries it, the client receives the expected subnet, the gateway is reachable, and policy permits the required path.
Segment because trust and traffic requirements differ
A school may separate Students, Staff, Guests, Servers, and Network Management. Segmentation reduces broadcast scope, separates trust groups, simplifies policy, and constrains lateral movement.
| Segment | Typical need | Typical restriction |
|---|---|---|
| Students | DNS, learning services, Internet | No infrastructure management |
| Staff | Internal apps, printers, Internet | Limited admin access |
| Guests | Internet | No internal trusted resources |
| Servers | Published internal services | Restricted inbound access |
| Management | Device administration | Highly limited source access |
Swipe horizontally to see the segmentation table.
VLANs and IP subnets often align, but they are not the same concept
A VLAN is a Layer 2 broadcast domain. An IP subnet is a Layer 3 address domain. Designs commonly map one subnet to one VLAN because that creates clean boundaries, but the concepts answer different questions.
VLAN
Who shares the Layer 2 broadcast domain?
Subnet
Which addresses are local at Layer 3?
Gateway
Where does traffic go when the destination is remote?
Segmentation creates boundaries; firewall policy decides which crossings are allowed
Once traffic reaches a Layer 3 boundary, firewall or ACL logic can evaluate source, destination, protocol, and port. Least privilege means allowing only what the requirement needs.
On first-match systems, rule order can completely change the policy result
A correct-looking deny rule is irrelevant if an earlier rule already accepted the flow.
Trace one packet through every control point
A client in VLAN 20 at 10.20.0.25/24 wants an HTTPS server at 10.40.0.50/24 in VLAN 40.
The destination is remote.
The frame is sent toward VLAN 20's default gateway.
The frame reaches the Layer 3 boundary.
A route and usable next step are required.
TCP/443 must be permitted for the source.
The server must have correct addressing and an active HTTPS listener.
The user sees one outage, but the path contains many independent dependencies
| Dependency | Possible failure | Useful artifact |
|---|---|---|
| Access port | Wrong VLAN | Port/VLAN state |
| Trunk | VLAN missing | Allowed/active VLAN list |
| Gateway | SVI/interface down | Interface state + connected route |
| Routing | Missing/wrong route | Route table |
| Firewall | Rule denies flow | Counter/log |
| Server | Wrong gateway or no listener | Host config / socket state |
Swipe horizontally to see the dependency map.
Ask what else shares the failed component
Every VLAN fails
Inspect shared uplink/trunk or upstream dependency.
One VLAN fails
Inspect that VLAN's carriage, membership, SVI, and policy.
One port fails
Inspect endpoint, cable, access port, and local config.
The narrower the symptom, the narrower the first hypothesis should be.
Segmentation changes who receives Layer 2 broadcasts
ARP requests and many other Ethernet broadcasts remain inside their Layer 2 broadcast domain. Routers do not normally forward ordinary Layer 2 broadcasts between IP subnets. Splitting a flat LAN into VLANs changes broadcast reach and may also change discovery behavior for applications that relied on local broadcast or multicast.
Successful access alone does not prove security policy
If Staff should reach a server on TCP/443 and Students should not, a successful Staff test proves only the positive requirement. Test the Student path too.
This distinction—“the allowed task works” versus “the policy works”—is central to Unit 3.
One command rarely proves the whole design
| Artifact | What it can prove | What it cannot prove alone |
|---|---|---|
| VLAN table | Configured VLAN presence/membership | Application reachability |
| MAC table | Layer 2 learning | Routing or firewall success |
| Route table | Matching route exists | Firewall/application success |
| Firewall log | Policy decision for a flow | Destination listener state |
| DHCP lease | Operational client addressing | Inter-VLAN policy |
Swipe horizontally to see the artifact boundaries.
A new student lab crosses almost every Unit 3 dependency
A new lab uses VLAN 25 and 10.25.0.0/24. Access ports in two rooms must place student PCs into VLAN 25. The inter-switch trunk must carry VLAN 25. The gateway at 10.25.0.1 must be operational. DHCP must provide VLAN 25 leases. Policy should allow DNS, learning services, and Internet access while denying infrastructure management.
After correcting the trunk, verify DHCP, gateway access, required services, and the denied management path.
Audit one representative endpoint from each segment
For each role—Student, Staff, Guest, Server, Management—trace the intended access-port VLAN, subnet, gateway, trunk path, route, and firewall permissions. Then choose one allowed destination and one prohibited destination.
For the denied path: identify the rule that should stop the traffic and verify the denial.
This creates a reusable operational map that another technician can use to predict failure scope before changing configuration.
Learn Unit 3 in dependency order
What Unit 3 mastery looks like
- Identify network devices by function, not appearance.
- Predict switch forwarding from MAC-table evidence.
- Explain access versus trunk behavior.
- Separate VLAN concepts from IP-subnet concepts.
- Verify configured state with operational evidence.
- Read firewall rules in order.
- Trace an allowed and denied flow across a segmented LAN.
- Use successful traffic to eliminate known-good portions of the path.
Trace one segmented flow and isolate the first failed dependency
This is the kind of integrated reasoning Unit 3 is designed to build: preserve the working layers, identify the first failed boundary, and verify both the allowed and denied outcomes.
Use MAC learning as evidence, not as proof of the entire path
A MAC table can answer whether the switch has learned an endpoint on the expected port and VLAN. That is powerful Layer 2 evidence, especially when comparing a working host with a failing host. But it does not prove the endpoint has the correct IP address, that the gateway is reachable, or that a firewall will allow the eventual routed flow.
This evidence-boundary habit prevents one successful command from being stretched into a conclusion it cannot support.
Inter-VLAN routing depends on a working Layer 3 boundary
Each segmented client network needs a usable Layer 3 gateway. In many switched designs that gateway is an SVI; in others it may be a router subinterface or another routed interface. The exact platform matters less than the dependency: the gateway must exist, be operational, have the intended IP/prefix, and participate in routing.
If clients can communicate with each other inside VLAN 25 but no client can reach 10.25.0.1, focus on the Layer 3 boundary before investigating remote application policy.
A DHCP lease can reveal whether the endpoint reached the intended logical network
Unit 3 troubleshooting becomes much faster when you treat DHCP as evidence of placement. A client on the Staff SSID receiving a Guest subnet is not merely an addressing problem—it may indicate wrong SSID-to-VLAN mapping, an incorrect relay/helper target, or an unintended DHCP path.
Working paths are experiments you already ran
If Room A and Room B use the same firewall, ISP, and server but only Room B fails, those shared dependencies become weaker suspects. If VLAN 10 and VLAN 20 cross the same trunk while VLAN 25 fails, the shared physical link becomes weaker. Good Unit 3 troubleshooting constantly asks: what working traffic already proves part of the design?
Verify role-based policy with both allowed and denied examples
| Source role | Destination | Expected result | Evidence |
|---|---|---|---|
| Staff | AppServer:443 | Allow | HTTPS success + allow counter |
| Student | AppServer:443 | Depends on requirement | Test + matching rule |
| Guest | Management:22 | Deny | Failed SSH + deny log |
| Management | Switch admin | Allow | Admin session + source restriction |
Swipe horizontally to see the security verification matrix.
A matrix like this exposes accidental broad allows that a single successful test would miss.
Define a known-good baseline before editing shared infrastructure
Unit 3 devices often sit on shared paths, so a small change can affect several VLANs at once. Before modifying a trunk, firewall rule, or SVI, record enough baseline evidence to tell whether unrelated services changed.
This is much stronger than “I changed it and now my test works.”
Trace one endpoint from wall jack to policy decision
Choose one representative client and record the physical port, access VLAN, switch MAC learning, trunk path, IP address, prefix, default gateway, DHCP source, route, firewall decision, destination listener, and expected return path. Then test one allowed service and one denied service. This turns the unit into a complete operational model instead of six disconnected chapters.
If a future failure occurs, the last known-good checkpoint gives you a much narrower starting point.
24 AP Networking Unit 3 digital flashcards
Practice switches, routers, MAC learning, VLANs, trunks, segmentation, gateways, routing, firewall order, broadcast domains, evidence boundaries, troubleshooting scope, and verification.