Joltlined

Notes & literary analysis

FBLA · National 2026–27

Network Design

12 two-page sheets · 24 printable pages · 24 lines per page

Read a sheet, then open “Sources, practice, lab and scope notes” beneath it for questions, answers and the module lab. Plain and colored downloads contain the same notes. Use your browser's Print command for one numbered sheet per page.

Official scope: 2026–27 CONNECT guideline. The notes and companion deck have been reviewed; neither certifies your mastery or a competition result. Objective IDs are local study labels, and source-reading limits are recorded in the source ledger.

Confirm qualification, entry limits and conference-specific rules with your adviser. Studying all four events does not establish eligibility to enter all four.

Guideline ambiguity: flipchart/visual-aid language conflicts with no-visuals direction; SMP is undefined. Confirm with adviser; no resolution inferred.

Course contents

  1. SOHO Links, Wireless, and Addressing
  2. Physical Infrastructure and Printing
  3. Security, Access, and Platform Controls
  4. Recovery, Monitoring, and Wireless Security
  5. Network administration: maintenance and monitoring
  6. Network administration: diagnostics and assets
  7. Network planning: requirements and scale
  8. Network planning: tradeoffs and services
  9. Network Environments and Security
  10. Protocols and Troubleshooting
  11. Analyze and Recommend a Network Design
  12. Deliver and Defend the Recommendation

Physical Infrastructure and Printing

Network Installation and Configuration

Physical Infrastructure and Printing

Page 1 · Lines 1–24

o Overview
-> Fiber and copper selection
-> Rack and blade installation
o Fiber and copper selection
-> Copper Ethernet sends signals over twisted pairs.
-> UTP lacks metallic shielding; STP includes shielding.
-> Shield installation and grounding must follow cable design.
-> Cable category, endpoints and PHY constrain rate and channel.
-> Coax has a central conductor and shield; some ISPs use it.
-> Fiber carries light and resists electromagnetic interference.
-> Multimode commonly serves shorter links with matching optics.
-> Single-mode with compatible optics can serve longer links.
-> Reach depends on PHY, optics, wavelength, loss and connectors.
o Rack and blade installation
-> Rack servers mount as units in a cabinet with service access.
-> Check rail fit, equipment depth, weight and rack capacity.
-> Plan labeled power, network ports, cable paths and airflow.
-> Blade servers fit a shared chassis with common interconnects.
-> Chassis can improve density and centralized management.
-> Chassis adds cost and shared failure dependencies.
-> Inventory assets, firmware, NICs, storage and switch ports.
-> Follow vendor install, grounding and safety procedures.
-> After install, verify links, management, alarms and logs.
-> Redundant PSUs help only with adequate independent feeds.

Physical Infrastructure and Printing

Page 2 · Lines 25–48

o Overview
-> Power, temperature, and UPS
-> Direct, shared, and server printing
o Power, temperature, and UPS
-> Excess heat can throttle equipment, age it or shut it down.
-> Keep vents clear; monitor inlet temperature and airflow.
-> Cooling capacity and airflow must suit the installed load.
-> A UPS supplies temporary battery power during an interruption.
-> Size runtime to load; test batteries and controlled shutdown.
-> A UPS is not a generator, backup, or independent power feed.
-> Power redundancy fails if upstream circuits share one failure.
-> Define recovery priorities and dependencies before controls.
-> Tabletop power loss; predict effects; do not unplug live gear.
o Direct, shared, and server printing
-> Direct USB printing connects a client to one printer.
-> A network printer can accept jobs directly over the LAN.
-> Host-shared printing exposes a host queue to other clients.
-> The host and its print service must stay available for jobs.
-> A print server centralizes queues and printer administration.
-> Clients submit jobs to a queue; spooler manages pending work.
-> A server outage or queue fault can interrupt shared printing.
-> Restrict queue management and printing to authorized users.
-> Keep printer firmware and drivers supported and maintained.
-> Protect confidential output; use secure release if available.
Sources, practice, lab and scope notes

Objectives

  • ND-NIC-04
  • ND-NIC-05
  • ND-NIC-09
  • ND-NIC-10
  • ND-NSR-02
  • ND-NIC-11

Sources

  • FBLA Network Design 2026-27 Guidelines, study guide p. 6 — fetched; Read the current study-guide objective descriptions for installation/configuration and network security/recovery; establishes scope, not mechanisms.
  • Cisco: Configure IP Access Lists — fetched; Read ACL matching, ordered evaluation, implicit deny, direction/application, traffic criteria, and stateful inspection discussion. Platform-specific examples; not a universal firewall configuration recipe.
  • RFC 3021: Using 31-Bit Prefixes on IPv4 Point-to-Point Links — fetched; Read sections 1-3 and deployment notes: /31 uses both addresses as hosts only on point-to-point links; both endpoints must support it.
  • Microsoft Learn: BitLocker Overview — fetched; Read volume-encryption purpose, TPM/offline integrity role, startup protection, and recovery-key backup behavior; warns encryption without protected keys is insufficient.
  • Microsoft Learn: Active Directory Domain Services overview — fetched; Read directory objects, centralized account access, authentication, access control, policy administration, and replication. Distinguishes directory function from DNS naming.
  • Red Hat Enterprise Linux 9: Using SELinux — fetched; Read guide introduction: SELinux implements MAC; policy constrains how users/processes interact with files and devices. Platform-specific Linux control, not antivirus.
  • CISA Zero Trust Maturity Model — fetched; Read current model overview: per-request least-privilege decisions, location-centric to data-centric shift, visibility and granular enforcement.
  • Microsoft Learn: Print and Document Services Architecture — fetched; Read print queue, client/server sharing, driver and spooler architecture. Windows Server 2012-era source; used only for durable queue/host dependency concepts, not current driver deployment advice.
  • NIST SP 800-34 Rev. 1, Contingency Planning Guide — fetched; Read publication overview and planning purpose/process metadata. Detailed operational claims below are kept to general plan, backup, recovery-test concepts; document is 2010 guidance, not current vendor prescription.
  • Cisco: What Is Ethernet? — fetched; Read Ethernet/IEEE 802.3, frame switching and MAC learning versus router IP forwarding, and physical media overview; not used for universal cable reach.
  • IEEE 802.11 Working Group and amendments — fetched; Verified IEEE 802.11 is the Wireless LAN Working Group standard family; IEEE-SA amendment pages identify 802.11ax-2021 and 802.11be-2024. No universal device rate or range inferred.

Practice (answers below)

1. An office has 40 users, two printers, and rotating staff. Compare a host-shared printer with a print server.

Host sharing is simple but jobs depend on that host's uptime and controls. A print server can centrally manage queues and permissions, but introduces a service to maintain and secure; choose based on support and availability needs.

2. Why does a blade chassis improve density but not automatically improve resilience?

Blades share chassis infrastructure such as power, cooling and interconnects, increasing density and management convenience while creating common failure dependencies. Validate independent feeds and capacity; redundancy labels alone do not prove independence.

Offline network and recovery tabletop

  1. Draw a fictional ISP-to-SOHO path and label modem, router, switch, AP, DHCP, DNS and firewall roles.
  2. On paper, evaluate ordered allow/deny rules and identify an unintended flow; make no device changes.
  3. Use a sample subnet card to find network and gateway; explain why /31 is point-to-point only.
  4. Sort fictional backup copies by location, medium and version; select a restore candidate against stated RTO/RPO.
  5. For a mock access request, decide NAC admission and Zero Trust authorization separately.
  6. Review sample IDS/IPS alert cards and state what evidence is needed before declaring an incident.

Expected: Learner distinguishes NAT, routing, DHCP/DNS, ACL policy and stateful filtering. Learner explains fiber/copper/WLAN limits and accurate subnet/loopback purposes. Learner compares direct/shared/server printing and rack/blade power dependencies. Learner selects a tested, versioned restore approach and explains RAID is not backup. Learner distinguishes BitLocker encryption, AD DS identity/policy and SELinux MAC. Learner explains IDS alert versus IPS inline blocking and WPA/ACL limits.

Limitations: Cisco ACL behavior cited is IOS-specific; other firewall products can differ in rule order, defaults and state handling. Microsoft print architecture reference describes Windows Server 2012; queue and host dependency concepts are used, not current driver deployment instructions. Fiber reach and exact PHY rates require the actual cable, optics, standard and vendor specifications; no universal distance/rate is asserted. NIST SP 800-34 Rev. 1 is older guidance; organization-specific recovery requirements and current policy govern implementation.

Security, Access, and Platform Controls

Network Security and Recovery

Security, Access, and Platform Controls

Page 1 · Lines 1–24

o Overview
-> Threat defenses and least privilege
-> Zero Trust and network admission
o Threat defenses and least privilege
-> DoS exhausts a service resource; DDoS distributes that load.
-> Capacity, filtering and provider aid may mitigate DoS.
-> Phishing deceives users into disclosing data or taking action.
-> Verify requests via known channels; report suspicious mail.
-> Insider risk may be intentional or accidental.
-> Least privilege limits access to needed tasks and time.
-> Remove unused services; close ports and patch systems.
-> Antivirus detects some threats; it cannot assure safety.
-> Third-party access needs scope, oversight and revocation.
o Zero Trust and network admission
-> Zero Trust grants no automatic trust merely from LAN location.
-> Evaluate each access request using identity and context.
-> Grant granular least-privilege access to data and services.
-> Reassess decisions as users, devices and risk context change.
-> MFA combines factor types; two passwords are one type.
-> Authentication checks identity; authorization grants actions.
-> NAC checks device or identity at network admission.
-> NAC may quarantine a device pending remediation or compliance.
-> VLAN segmentation needs policy controls on inter-VLAN traffic.
-> NAC complements endpoint, identity controls and monitoring.

Security, Access, and Platform Controls

Page 2 · Lines 25–48

o Overview
-> BitLocker and directory identity
-> SELinux mandatory access control
o BitLocker and directory identity
-> BitLocker encrypts Windows volumes against offline exposure.
-> TPM can protect startup keys and check offline integrity.
-> Startup PIN or key can add preboot access protection.
-> Encryption does not protect data in an open session.
-> Protect and back up recovery keys for legitimate recovery.
-> AD DS stores directory objects such as accounts and groups.
-> Domain identity centralizes authentication and access control.
-> Policy-based administration manages settings across systems.
-> DNS locates services; a DNS name is not AD identity.
o SELinux mandatory access control
-> SELinux is Linux Security-Enhanced Linux access control.
-> It implements mandatory access control (MAC) through policy.
-> Policy constrains user and process interaction with objects.
-> File and process labels provide context for policy decisions.
-> Rules can restrict services beyond ordinary file permissions.
-> This can limit damage if a process is compromised.
-> Investigate denials; fix policy, do not blindly disable it.
-> SELinux is not antivirus; updates and backups still matter.
-> MAC policy differs from discretionary owner/group permissions.
-> Use platform docs for modes and safe policy administration.
Sources, practice, lab and scope notes

Objectives

  • ND-NSR-04
  • ND-NSR-05
  • ND-NSR-06
  • ND-NSR-07
  • ND-NSR-08
  • ND-NSR-09

Sources

  • FBLA Network Design 2026-27 Guidelines, study guide p. 6 — fetched; Read the current study-guide objective descriptions for installation/configuration and network security/recovery; establishes scope, not mechanisms.
  • Cisco: Configure IP Access Lists — fetched; Read ACL matching, ordered evaluation, implicit deny, direction/application, traffic criteria, and stateful inspection discussion. Platform-specific examples; not a universal firewall configuration recipe.
  • RFC 3021: Using 31-Bit Prefixes on IPv4 Point-to-Point Links — fetched; Read sections 1-3 and deployment notes: /31 uses both addresses as hosts only on point-to-point links; both endpoints must support it.
  • Microsoft Learn: BitLocker Overview — fetched; Read volume-encryption purpose, TPM/offline integrity role, startup protection, and recovery-key backup behavior; warns encryption without protected keys is insufficient.
  • Microsoft Learn: Active Directory Domain Services overview — fetched; Read directory objects, centralized account access, authentication, access control, policy administration, and replication. Distinguishes directory function from DNS naming.
  • Red Hat Enterprise Linux 9: Using SELinux — fetched; Read guide introduction: SELinux implements MAC; policy constrains how users/processes interact with files and devices. Platform-specific Linux control, not antivirus.
  • CISA Zero Trust Maturity Model — fetched; Read current model overview: per-request least-privilege decisions, location-centric to data-centric shift, visibility and granular enforcement.
  • Microsoft Learn: Print and Document Services Architecture — fetched; Read print queue, client/server sharing, driver and spooler architecture. Windows Server 2012-era source; used only for durable queue/host dependency concepts, not current driver deployment advice.
  • NIST SP 800-34 Rev. 1, Contingency Planning Guide — fetched; Read publication overview and planning purpose/process metadata. Detailed operational claims below are kept to general plan, backup, recovery-test concepts; document is 2010 guidance, not current vendor prescription.
  • Cisco: What Is Ethernet? — fetched; Read Ethernet/IEEE 802.3, frame switching and MAC learning versus router IP forwarding, and physical media overview; not used for universal cable reach.
  • IEEE 802.11 Working Group and amendments — fetched; Verified IEEE 802.11 is the Wireless LAN Working Group standard family; IEEE-SA amendment pages identify 802.11ax-2021 and 802.11be-2024. No universal device rate or range inferred.

Practice (answers below)

1. A compliant school laptop connects to a guest VLAN but cannot reach an internal file server. Explain a Zero Trust/NAC design reason.

NAC may admit the device only to a restricted segment; authorization can still deny the file-server resource. Verify identity, posture and the specific permitted flow rather than assuming LAN presence grants trust.

2. Contrast BitLocker, AD DS, and SELinux; which one is a volume-encryption feature?

BitLocker encrypts Windows volumes to reduce offline exposure; AD DS centrally stores identities and administers authentication/access; SELinux applies Linux MAC policy to process/object interactions. None alone replaces layered controls.

Offline network and recovery tabletop

  1. Draw a fictional ISP-to-SOHO path and label modem, router, switch, AP, DHCP, DNS and firewall roles.
  2. On paper, evaluate ordered allow/deny rules and identify an unintended flow; make no device changes.
  3. Use a sample subnet card to find network and gateway; explain why /31 is point-to-point only.
  4. Sort fictional backup copies by location, medium and version; select a restore candidate against stated RTO/RPO.
  5. For a mock access request, decide NAC admission and Zero Trust authorization separately.
  6. Review sample IDS/IPS alert cards and state what evidence is needed before declaring an incident.

Expected: Learner distinguishes NAT, routing, DHCP/DNS, ACL policy and stateful filtering. Learner explains fiber/copper/WLAN limits and accurate subnet/loopback purposes. Learner compares direct/shared/server printing and rack/blade power dependencies. Learner selects a tested, versioned restore approach and explains RAID is not backup. Learner distinguishes BitLocker encryption, AD DS identity/policy and SELinux MAC. Learner explains IDS alert versus IPS inline blocking and WPA/ACL limits.

Limitations: Cisco ACL behavior cited is IOS-specific; other firewall products can differ in rule order, defaults and state handling. Microsoft print architecture reference describes Windows Server 2012; queue and host dependency concepts are used, not current driver deployment instructions. Fiber reach and exact PHY rates require the actual cable, optics, standard and vendor specifications; no universal distance/rate is asserted. NIST SP 800-34 Rev. 1 is older guidance; organization-specific recovery requirements and current policy govern implementation.

Recovery, Monitoring, and Wireless Security

Network Security and Recovery

Recovery, Monitoring, and Wireless Security

Page 1 · Lines 1–24

o Overview
-> Disaster recovery planning
-> Backup types and restore assurance
o Disaster recovery planning
-> Disaster recovery restores systems and data after disruption.
-> Business continuity sustains priority work during disruption.
-> A plan defines scope, roles, contacts and dependencies.
-> Include recovery order, communication, resources and checks.
-> Risk assessment compares events and business impacts.
-> Recovery time objective (RTO) is target restoration time.
-> Recovery point objective (RPO) is tolerable data-loss time.
-> Select controls to meet business targets and resource limits.
-> Test plans; revise after exercises, incidents or changes.
o Backup types and restore assurance
-> Cloud backup is offsite but depends on provider and account.
-> NAS backup is convenient but shares site and access risks.
-> External drives can be disconnected; rotate them securely.
-> Use 3-2-1: three copies, two media, one copy offsite.
-> Keep an offline or immutable copy to resist ransomware.
-> Versioned copies allow selection of an earlier restore point.
-> Separate backup credentials from admin accounts.
-> RAID may sustain disk failure, not deletion or corruption.
-> A backup is an independent copy; RAID is not a backup.
-> Test isolated restores; validate data, rights and service.

Recovery, Monitoring, and Wireless Security

Page 2 · Lines 25–48

o Overview
-> IDS, IPS, updates, and response
-> Wireless authentication and ACLs
o IDS, IPS, updates, and response
-> An IDS observes host or network activity and raises alerts.
-> An IPS can block or drop traffic inline when policy triggers.
-> Inline false positives may disrupt legitimate service.
-> Detection depends on visibility, tuning and known indicators.
-> An alert is a lead to investigate, not proof of compromise.
-> Preserve evidence, contain, remediate, then validate recovery.
-> Patch supported systems and apps to fix known flaws.
-> Test updates and plan rollback; delay prolongs exposure.
-> Firewalls and endpoint protection work at different points.
o Wireless authentication and ACLs
-> WPA2/WPA3 protect Wi-Fi links; choose supported secure modes.
-> WPA2-Personal uses shared passphrase; protect it if exposed.
-> Enterprise Wi-Fi can use 802.1X/EAP user or device identity.
-> A backend validates credentials; protect its server and keys.
-> Use a unique secret, current firmware and secure admin access.
-> WPA3 compatibility depends on AP and client support.
-> Wireless ACLs filter traffic by rules and attributes.
-> MAC addresses can be spoofed; ACLs are not identity proof.
-> Isolate guest clients and restrict paths with network policy.
-> Revoke lost credentials; hidden SSID is not security.
Sources, practice, lab and scope notes

Objectives

  • ND-NSR-01
  • ND-NSR-02
  • ND-NSR-03
  • ND-NSR-04
  • ND-NSR-05
  • ND-NSR-10
  • ND-NSR-06
  • ND-NSR-08
  • ND-NSR-11

Sources

  • FBLA Network Design 2026-27 Guidelines, study guide p. 6 — fetched; Read the current study-guide objective descriptions for installation/configuration and network security/recovery; establishes scope, not mechanisms.
  • Cisco: Configure IP Access Lists — fetched; Read ACL matching, ordered evaluation, implicit deny, direction/application, traffic criteria, and stateful inspection discussion. Platform-specific examples; not a universal firewall configuration recipe.
  • RFC 3021: Using 31-Bit Prefixes on IPv4 Point-to-Point Links — fetched; Read sections 1-3 and deployment notes: /31 uses both addresses as hosts only on point-to-point links; both endpoints must support it.
  • Microsoft Learn: BitLocker Overview — fetched; Read volume-encryption purpose, TPM/offline integrity role, startup protection, and recovery-key backup behavior; warns encryption without protected keys is insufficient.
  • Microsoft Learn: Active Directory Domain Services overview — fetched; Read directory objects, centralized account access, authentication, access control, policy administration, and replication. Distinguishes directory function from DNS naming.
  • Red Hat Enterprise Linux 9: Using SELinux — fetched; Read guide introduction: SELinux implements MAC; policy constrains how users/processes interact with files and devices. Platform-specific Linux control, not antivirus.
  • CISA Zero Trust Maturity Model — fetched; Read current model overview: per-request least-privilege decisions, location-centric to data-centric shift, visibility and granular enforcement.
  • Microsoft Learn: Print and Document Services Architecture — fetched; Read print queue, client/server sharing, driver and spooler architecture. Windows Server 2012-era source; used only for durable queue/host dependency concepts, not current driver deployment advice.
  • NIST SP 800-34 Rev. 1, Contingency Planning Guide — fetched; Read publication overview and planning purpose/process metadata. Detailed operational claims below are kept to general plan, backup, recovery-test concepts; document is 2010 guidance, not current vendor prescription.
  • Cisco: What Is Ethernet? — fetched; Read Ethernet/IEEE 802.3, frame switching and MAC learning versus router IP forwarding, and physical media overview; not used for universal cable reach.
  • IEEE 802.11 Working Group and amendments — fetched; Verified IEEE 802.11 is the Wireless LAN Working Group standard family; IEEE-SA amendment pages identify 802.11ax-2021 and 802.11be-2024. No universal device rate or range inferred.

Practice (answers below)

1. A ransomware scenario has a recent encrypted NAS copy and a week-old offline copy. Which restore choice should the team investigate?

Investigate the offline version as a potentially cleaner restore point, while validating age against the RPO and checking integrity in an isolated environment. NAS proximity alone does not make it safe; RAID and online copies may share compromise.

2. An IPS blocked a legitimate file-transfer flow. What differs from IDS behavior, and what should operators do?

IDS primarily detects and alerts; IPS can enforce a block inline, so a false positive can interrupt service. Review evidence and rule scope, safely tune with change control, then validate both desired and prohibited flows.

Offline network and recovery tabletop

  1. Draw a fictional ISP-to-SOHO path and label modem, router, switch, AP, DHCP, DNS and firewall roles.
  2. On paper, evaluate ordered allow/deny rules and identify an unintended flow; make no device changes.
  3. Use a sample subnet card to find network and gateway; explain why /31 is point-to-point only.
  4. Sort fictional backup copies by location, medium and version; select a restore candidate against stated RTO/RPO.
  5. For a mock access request, decide NAC admission and Zero Trust authorization separately.
  6. Review sample IDS/IPS alert cards and state what evidence is needed before declaring an incident.

Expected: Learner distinguishes NAT, routing, DHCP/DNS, ACL policy and stateful filtering. Learner explains fiber/copper/WLAN limits and accurate subnet/loopback purposes. Learner compares direct/shared/server printing and rack/blade power dependencies. Learner selects a tested, versioned restore approach and explains RAID is not backup. Learner distinguishes BitLocker encryption, AD DS identity/policy and SELinux MAC. Learner explains IDS alert versus IPS inline blocking and WPA/ACL limits.

Limitations: Cisco ACL behavior cited is IOS-specific; other firewall products can differ in rule order, defaults and state handling. Microsoft print architecture reference describes Windows Server 2012; queue and host dependency concepts are used, not current driver deployment instructions. Fiber reach and exact PHY rates require the actual cable, optics, standard and vendor specifications; no universal distance/rate is asserted. NIST SP 800-34 Rev. 1 is older guidance; organization-specific recovery requirements and current policy govern implementation.

Network administration: maintenance and monitoring

Network Administration

Network administration: maintenance and monitoring

Page 1 · Lines 1–24

o Overview
-> Maintenance and recovery
-> Accounts and permissions
o Maintenance and recovery
-> Maintenance keeps services supported, secure, and recoverable.
-> An audit compares actual assets and settings with policy.
-> Record audit scope, evidence, owner, risk, and due action.
-> Updates add fixes or features; patches address known defects.
-> Test compatibility, stage deployment, then verify outcomes.
-> A rollback plan limits harm if an update breaks a service.
-> A backup is a separate copy intended for later recovery.
-> RAID may tolerate disk failure; it does not replace backup.
-> A restore test checks usable data and recovery procedure.
o Accounts and permissions
-> An account identifies a user or service to a system.
-> Authentication checks identity; authorization grants actions.
-> Groups collect accounts with similar job-based access needs.
-> Grant needed rights; avoid routine shared administrator use.
-> Review rights after role changes; disable accounts at exit.
-> Transfer ownership of files, queues, and scheduled work.
-> An asset record links item, owner, site, and support contact.
-> Track printer model, address, queue, host, and team.
-> A shared queue centralizes jobs, not printer uptime.
-> Remove obsolete group membership when duties end.

Network administration: maintenance and monitoring

Page 2 · Lines 25–48

o Overview
-> SNMP and management data
-> Traffic baselines and alerts
o SNMP and management data
-> Simple Network Management Protocol (SNMP) exchanges status.
-> Managers query agents that expose managed device objects.
-> A Management Information Base (MIB) names managed objects.
-> Poll counters; notifications report events but may be lost.
-> Counters need time intervals to show rates or changing errors.
-> SNMPv2c names are unencrypted; traffic can expose them.
-> SNMPv3 USM supports authentication and optional privacy.
-> Auth checks integrity and user; privacy encrypts data.
-> Use authPriv; limit MIB views and manager ACLs.
o Traffic baselines and alerts
-> Time counters; baseline latency, loss, errors, and demand.
-> Compare like periods; peak and average load differ.
-> An alert triggers investigation, not proof of cause.
-> A load balancer distributes eligible traffic across backends.
-> Azure defaults to hashing five flow fields for backend choice.
-> Client-IP affinity sends that client to the same backend.
-> Affinity may skew load when few distinct client flows exist.
-> Configured probes can stop new flows to unhealthy backends.
-> Map links, gateways, dependencies; log checks and recovery.
-> Restrict log access and retention to protect sensitive data.
Sources, practice, lab and scope notes

Objectives

  • ND-NA-01
  • ND-NA-06
  • ND-NA-02
  • ND-NA-10
  • ND-NA-03
  • ND-NA-08
  • ND-NA-07
  • ND-NA-09

Sources

  • FBLA 2026-27 Network Design Guidelines — fetched; Read study guide pp. 6-7 to verify Network Administration and Network Planning objective scope.
  • RFC 3411: SNMP Management Framework Architecture — fetched; Read §§1-2 and 3.1-3.2: manager and agent applications, managed objects/MIB, operations, notifications, and the distinction between message security and access control.
  • RFC 3414: SNMPv3 User-based Security Model — fetched; Read §§1.1-1.4 and 2: authentication provides integrity and user authentication, privacy protects payload disclosure and requires authentication, and timeliness limits replay. The document's example MD5/DES algorithms are historic, not current recommendations.
  • RFC 3418: SNMP Management Information Base — fetched; Read §§1-2, including system identity/location objects, SNMP counters, and notifications; used to explain management data and monitoring evidence.
  • RFC 1901: Community-based SNMPv2 — fetched; Read §§2-3: agents, managers, MIB objects, and SNMPv2c's community-based administrative framework. Historic experimental RFC; used only for community model context.
  • CISA: Reducing the Risk of SNMP Abuse — fetched; Read community-string exposure, SNMPv3 authPriv, MIB-view/ACL and least-privilege guidance. Dated 2017; confirm current device and cryptographic support.
  • Microsoft ping command reference — fetched; Read command description, examples, and parameters: ICMP Echo testing, name-versus-address comparison, and timeout behavior.
  • Microsoft tracert command reference — fetched; Read TTL-based path discovery and examples; intermediate routers can omit Time Exceeded responses, producing asterisks without proving a forwarding failure.
  • Microsoft ipconfig command reference — fetched; Read /all, /renew, /flushdns, and remarks: adapter configuration, DHCP renewal conditions, and local DNS-cache scope.
  • Microsoft Azure Load Balancer overview — fetched; Read Layer 4 flow distribution, backend pools, rules, health probes, monitoring, and availability overview. These are Azure implementation examples, not universal behavior for every load balancer.
  • Azure Load Balancer distribution modes — fetched; Read five-tuple hash distribution and two-/three-tuple client-IP affinity modes; same-client affinity can skew distribution, particularly where flow diversity is limited. Azure-specific implementation.
  • Azure Load Balancer health probes — fetched; Read TCP/HTTP probe operations, configured response/threshold behavior, unhealthy backend handling, and health-signal design guidance; implementation details vary by SKU and product.
  • Shared responsibility in the cloud — fetched; Read service-model responsibility matrix and retained customer duties for data, accounts, and access; Microsoft-specific guidance and contract terms govern.
  • What is Windows Server? — fetched; Read platform roles, deployment, management, integration, and licensing overview; used as vendor-specific evidence, not a neutral comparison or price quote.
  • Ubuntu Server documentation — fetched; Read overview sections for networking, security, software updates, storage, virtualisation, performance, and high availability.
  • What is Linux? — fetched; Read operating-system and distribution explanations: kernel, user space, packages, and different distribution choices. Vendor educational material; not used to claim universal superiority.
  • Microsoft print command reference — fetched; Read command syntax and examples showing local port printing and a named shared network queue.
  • Active Directory Domain Services overview — fetched; Read directory purpose and security sections: AD DS stores network objects and supports authentication, access control, and policy-based administration.
  • Configure IP Addresses and Unique Subnets for New Users — fetched; Read subnet/address examples and topology context. This older tutorial contains classful-era simplifications; notes do not treat them as modern routing practice.

Practice (answers below)

1. A patch causes an application outage. What maintenance evidence helps recovery?

Use the approved change record, compatibility test, deployment time, service logs, and rollback steps. A verified restore or rollback should be tested against recovery needs; the mere existence of a backup does not prove it will work.

2. What does SNMPv3 privacy add beyond authentication?

Authentication checks message integrity and the configured user identity. Privacy encrypts the management payload against disclosure and is used with authentication. It does not by itself prevent denial of service or replace access control; use currently supported algorithms, not the historical examples in RFC 3414.

Controlled network design tabletop

  1. Use a fictional 30-user office, two rooms, fixed budget, and a stated outage limit.
  2. Draw star, partial mesh, and bus alternatives; mark links and shared failure points.
  3. Estimate peak users and identify a critical application and its dependencies.
  4. Compare P2P, local server, and cloud options for cost, skills, access, and recovery.
  5. Select one design, define a measurable service target, and name a test for it.

Expected: The diagram identifies central equipment, paths, and failure consequences. The recommendation ties topology and platform to stated business constraints. The group distinguishes provider commitments from end-to-end availability. No live network, real credentials, or production settings are used.

Limitations: RFC 3414 is foundational but dates from 2002 and specifies historic MD5/DES examples; deployed SNMPv3 algorithm support must be checked against current vendor guidance and policy. Azure Load Balancer describes one Layer 4 product; algorithms, probe semantics, affinity, and failure handling vary by implementation. LAN/WAN are geographic scope labels, not fixed throughput classes. Actual performance needs measurement of media, topology, load, and endpoints. Windows Server and Ubuntu/Linux sources are platform owners; they document their own capabilities, not a neutral performance or security ranking. Licensing and support terms change and must be checked for the proposed deployment. The Cisco subnet tutorial is older and includes classful simplifications; no classful assumptions are used for current network planning.

Network administration: diagnostics and assets

Network Administration

Network administration: diagnostics and assets

Page 1 · Lines 1–24

o Overview
-> Fault isolation and symptoms
-> Read local configuration
o Fault isolation and symptoms
-> Define service, users, location, onset, and impact first.
-> Scope separates client faults from segment outages.
-> Compare symptoms with baseline, peers, logs, and changes.
-> Check power, cable, link, adapter, and Wi-Fi association.
-> Slow service may reflect congestion, loss, or host load.
-> Measure latency and throughput at the same place and time.
-> Connection faults occur at link, address, route, or service.
-> An IP conflict means devices share one address on a link.
-> Check DHCP leases and static assignments against plan.
o Read local configuration
-> Windows `ipconfig /all` shows adapter and gateway settings.
-> Compare IP, mask, gateway, DNS with network records.
-> `ipconfig /renew` requests DHCP renewal on auto adapters.
-> Renewal does not fix a manually configured static address.
-> `ipconfig /flushdns` clears the local resolver cache only.
-> Ping an address and then its name to distinguish DNS symptoms.
-> IP reply but name failure suggests a name lookup problem.
-> A wrong mask or duplicate address disrupts local delivery.
-> Verify command clues against server logs and another host.
-> A DHCP lease shows assignment, not connectivity.

Network administration: diagnostics and assets

Page 2 · Lines 25–48

o Overview
-> Path tools and limits
-> Evidence and asset records
o Path tools and limits
-> Ping sends Internet Control Message Protocol (ICMP) probes.
-> Reply shows ICMP worked then; it does not test app ports.
-> No reply may mean filtering, loss, routing, or host policy.
-> ICMP silence alone never proves a destination is down.
-> `tracert` raises time-to-live (TTL) to reveal responding hops.
-> Routers may omit TTL replies; asterisks do not prove failure.
-> Paths may be asymmetric; traces show only responding hops.
-> Unix `traceroute` may use UDP, ICMP, or TCP by implementation.
-> Use approved probes; firewalls and rate limits shape results.
o Evidence and asset records
-> Counters expose errors, discards, and traffic volume.
-> Packet captures show timing, retransmits, and resets.
-> Captures may expose private data; authorize and protect them.
-> Record test time, device, symptom, output, and interpretation.
-> Document cause confidence, repair, verification, and owner.
-> Track device, model, address, site, port, and support owner.
-> Track user and group ownership plus access review dates.
-> Printer records include queue, location, and maintainer.
-> Retest the affected service with its user after repair.
-> Printer queues can fail at client, server, network, or device.
Sources, practice, lab and scope notes

Objectives

  • ND-NA-04
  • ND-NA-07
  • ND-NA-05
  • ND-NA-10
  • ND-NA-08

Sources

  • FBLA 2026-27 Network Design Guidelines — fetched; Read study guide pp. 6-7 to verify Network Administration and Network Planning objective scope.
  • RFC 3411: SNMP Management Framework Architecture — fetched; Read §§1-2 and 3.1-3.2: manager and agent applications, managed objects/MIB, operations, notifications, and the distinction between message security and access control.
  • RFC 3414: SNMPv3 User-based Security Model — fetched; Read §§1.1-1.4 and 2: authentication provides integrity and user authentication, privacy protects payload disclosure and requires authentication, and timeliness limits replay. The document's example MD5/DES algorithms are historic, not current recommendations.
  • RFC 3418: SNMP Management Information Base — fetched; Read §§1-2, including system identity/location objects, SNMP counters, and notifications; used to explain management data and monitoring evidence.
  • RFC 1901: Community-based SNMPv2 — fetched; Read §§2-3: agents, managers, MIB objects, and SNMPv2c's community-based administrative framework. Historic experimental RFC; used only for community model context.
  • CISA: Reducing the Risk of SNMP Abuse — fetched; Read community-string exposure, SNMPv3 authPriv, MIB-view/ACL and least-privilege guidance. Dated 2017; confirm current device and cryptographic support.
  • Microsoft ping command reference — fetched; Read command description, examples, and parameters: ICMP Echo testing, name-versus-address comparison, and timeout behavior.
  • Microsoft tracert command reference — fetched; Read TTL-based path discovery and examples; intermediate routers can omit Time Exceeded responses, producing asterisks without proving a forwarding failure.
  • Microsoft ipconfig command reference — fetched; Read /all, /renew, /flushdns, and remarks: adapter configuration, DHCP renewal conditions, and local DNS-cache scope.
  • Microsoft Azure Load Balancer overview — fetched; Read Layer 4 flow distribution, backend pools, rules, health probes, monitoring, and availability overview. These are Azure implementation examples, not universal behavior for every load balancer.
  • Azure Load Balancer distribution modes — fetched; Read five-tuple hash distribution and two-/three-tuple client-IP affinity modes; same-client affinity can skew distribution, particularly where flow diversity is limited. Azure-specific implementation.
  • Azure Load Balancer health probes — fetched; Read TCP/HTTP probe operations, configured response/threshold behavior, unhealthy backend handling, and health-signal design guidance; implementation details vary by SKU and product.
  • Shared responsibility in the cloud — fetched; Read service-model responsibility matrix and retained customer duties for data, accounts, and access; Microsoft-specific guidance and contract terms govern.
  • What is Windows Server? — fetched; Read platform roles, deployment, management, integration, and licensing overview; used as vendor-specific evidence, not a neutral comparison or price quote.
  • Ubuntu Server documentation — fetched; Read overview sections for networking, security, software updates, storage, virtualisation, performance, and high availability.
  • What is Linux? — fetched; Read operating-system and distribution explanations: kernel, user space, packages, and different distribution choices. Vendor educational material; not used to claim universal superiority.
  • Microsoft print command reference — fetched; Read command syntax and examples showing local port printing and a named shared network queue.
  • Active Directory Domain Services overview — fetched; Read directory purpose and security sections: AD DS stores network objects and supports authentication, access control, and policy-based administration.
  • Configure IP Addresses and Unique Subnets for New Users — fetched; Read subnet/address examples and topology context. This older tutorial contains classful-era simplifications; notes do not treat them as modern routing practice.

Practice (answers below)

1. A host misses ping but its web page loads. Is the host down?

No. The application response is evidence that the web service is reachable while ICMP may be filtered or lost. Ping tests ICMP Echo, not all protocols; compare service checks and logs before diagnosing an outage.

2. A user can ping a server IP but not its hostname. What next?

Compare name resolution and configured DNS with the correct service name; `ipconfig /all` shows resolver settings. A local cache flush clears client cache but not server records, so verify DNS data and other clients before concluding.

Controlled network design tabletop

  1. Use a fictional 30-user office, two rooms, fixed budget, and a stated outage limit.
  2. Draw star, partial mesh, and bus alternatives; mark links and shared failure points.
  3. Estimate peak users and identify a critical application and its dependencies.
  4. Compare P2P, local server, and cloud options for cost, skills, access, and recovery.
  5. Select one design, define a measurable service target, and name a test for it.

Expected: The diagram identifies central equipment, paths, and failure consequences. The recommendation ties topology and platform to stated business constraints. The group distinguishes provider commitments from end-to-end availability. No live network, real credentials, or production settings are used.

Limitations: RFC 3414 is foundational but dates from 2002 and specifies historic MD5/DES examples; deployed SNMPv3 algorithm support must be checked against current vendor guidance and policy. Azure Load Balancer describes one Layer 4 product; algorithms, probe semantics, affinity, and failure handling vary by implementation. LAN/WAN are geographic scope labels, not fixed throughput classes. Actual performance needs measurement of media, topology, load, and endpoints. Windows Server and Ubuntu/Linux sources are platform owners; they document their own capabilities, not a neutral performance or security ranking. Licensing and support terms change and must be checked for the proposed deployment. The Cisco subnet tutorial is older and includes classful simplifications; no classful assumptions are used for current network planning.

Network planning: requirements and scale

Network Planning

Network planning: requirements and scale

Page 1 · Lines 1–24

o Overview
-> Translate business requirements
-> Network scope and physical scale
o Translate business requirements
-> Start with workflows, sites, users, services, and devices.
-> Estimate concurrent users and peak traffic, not headcount.
-> Map apps needing low delay, steady rates, or reliable access.
-> Physical size sets cable paths, closets, links, and coverage.
-> Growth affects port, address, capacity, and space needs.
-> Throughput is delivered rate, not the PHY link rate.
-> Contention, signal, servers, and uplinks affect throughput.
-> Availability needs set acceptable outage and recovery targets.
-> Budget includes licenses, staff, support, and replacement.
o Network scope and physical scale
-> A local area network (LAN) connects devices in a limited site.
-> A wide area network (WAN) links networks across distance.
-> LAN and WAN name scope, not speed or technology.
-> A WAN often depends on carrier links and service contracts.
-> Long links may add latency, cost, and provider dependence.
-> Geography shapes routing, addressing, and support needs.
-> Separate user, server, guest needs before choosing equipment.
-> Redundancy improves resilience but adds links and operations.
-> Measure workload; labels alone do not size a network.
-> Carrier diversity helps only if routes avoid shared risks.

Network planning: requirements and scale

Page 2 · Lines 25–48

o Overview
-> Topology and failure domains
-> Windows Server or Linux
o Topology and failure domains
-> Star connects endpoints to a central switch or access point.
-> Edge link failure affects one; central failure affects many.
-> Mesh adds alternate paths but increases link cost.
-> Full mesh of n nodes needs n(n-1)/2 point-to-point links.
-> Bus attaches devices along a shared backbone cable.
-> A bus backbone break can disrupt service and hinder diagnosis.
-> Physical topology maps cables; logical topology maps paths.
-> Topology weighs fault impact, scale, cost, and staff skills.
-> Redundancy helps when failure domains are independent.
o Windows Server or Linux
-> A network operating system (NOS) runs shared network services.
-> Windows Server provides roles for Microsoft environments.
-> Linux server features vary by distribution and packages.
-> Check applications, drivers, identity, and hardware support.
-> Check staff expertise, training, and vendor support coverage.
-> Include licensing, subscriptions, upkeep, and migration costs.
-> Compare security controls and patching for this configuration.
-> Pilot service, access, backup, monitoring, and recovery needs.
-> Choose for compatibility and support, not stereotypes.
-> Licensing varies by edition, cores, and deployment terms.
Sources, practice, lab and scope notes

Objectives

  • ND-NP-01
  • ND-NP-08
  • ND-NP-02
  • ND-NP-03
  • ND-NP-04
  • ND-NP-09
  • ND-NP-05

Sources

  • FBLA 2026-27 Network Design Guidelines — fetched; Read study guide pp. 6-7 to verify Network Administration and Network Planning objective scope.
  • RFC 3411: SNMP Management Framework Architecture — fetched; Read §§1-2 and 3.1-3.2: manager and agent applications, managed objects/MIB, operations, notifications, and the distinction between message security and access control.
  • RFC 3414: SNMPv3 User-based Security Model — fetched; Read §§1.1-1.4 and 2: authentication provides integrity and user authentication, privacy protects payload disclosure and requires authentication, and timeliness limits replay. The document's example MD5/DES algorithms are historic, not current recommendations.
  • RFC 3418: SNMP Management Information Base — fetched; Read §§1-2, including system identity/location objects, SNMP counters, and notifications; used to explain management data and monitoring evidence.
  • RFC 1901: Community-based SNMPv2 — fetched; Read §§2-3: agents, managers, MIB objects, and SNMPv2c's community-based administrative framework. Historic experimental RFC; used only for community model context.
  • CISA: Reducing the Risk of SNMP Abuse — fetched; Read community-string exposure, SNMPv3 authPriv, MIB-view/ACL and least-privilege guidance. Dated 2017; confirm current device and cryptographic support.
  • Microsoft ping command reference — fetched; Read command description, examples, and parameters: ICMP Echo testing, name-versus-address comparison, and timeout behavior.
  • Microsoft tracert command reference — fetched; Read TTL-based path discovery and examples; intermediate routers can omit Time Exceeded responses, producing asterisks without proving a forwarding failure.
  • Microsoft ipconfig command reference — fetched; Read /all, /renew, /flushdns, and remarks: adapter configuration, DHCP renewal conditions, and local DNS-cache scope.
  • Microsoft Azure Load Balancer overview — fetched; Read Layer 4 flow distribution, backend pools, rules, health probes, monitoring, and availability overview. These are Azure implementation examples, not universal behavior for every load balancer.
  • Azure Load Balancer distribution modes — fetched; Read five-tuple hash distribution and two-/three-tuple client-IP affinity modes; same-client affinity can skew distribution, particularly where flow diversity is limited. Azure-specific implementation.
  • Azure Load Balancer health probes — fetched; Read TCP/HTTP probe operations, configured response/threshold behavior, unhealthy backend handling, and health-signal design guidance; implementation details vary by SKU and product.
  • Shared responsibility in the cloud — fetched; Read service-model responsibility matrix and retained customer duties for data, accounts, and access; Microsoft-specific guidance and contract terms govern.
  • What is Windows Server? — fetched; Read platform roles, deployment, management, integration, and licensing overview; used as vendor-specific evidence, not a neutral comparison or price quote.
  • Ubuntu Server documentation — fetched; Read overview sections for networking, security, software updates, storage, virtualisation, performance, and high availability.
  • What is Linux? — fetched; Read operating-system and distribution explanations: kernel, user space, packages, and different distribution choices. Vendor educational material; not used to claim universal superiority.
  • Microsoft print command reference — fetched; Read command syntax and examples showing local port printing and a named shared network queue.
  • Active Directory Domain Services overview — fetched; Read directory purpose and security sections: AD DS stores network objects and supports authentication, access control, and policy-based administration.
  • Configure IP Addresses and Unique Subnets for New Users — fetched; Read subnet/address examples and topology context. This older tutorial contains classful-era simplifications; notes do not treat them as modern routing practice.

Practice (answers below)

1. A growing firm has two sites and hosted voice. What requirements drive design?

Count concurrent users and peak voice/data flows at each site, measure delay tolerance, map geography and provider options, and set outage/recovery targets. LAN/WAN names do not promise capacity; compare measured demand, link cost, support, and redundancy.

2. What tradeoff distinguishes star, mesh, and bus layouts?

Star is easy to expand but concentrates risk in central equipment. Mesh provides alternate paths at greater link and operating cost. Bus shares one backbone and can be inexpensive but a backbone fault affects many devices. Select by scale, outage impact, and maintainability.

Controlled network design tabletop

  1. Use a fictional 30-user office, two rooms, fixed budget, and a stated outage limit.
  2. Draw star, partial mesh, and bus alternatives; mark links and shared failure points.
  3. Estimate peak users and identify a critical application and its dependencies.
  4. Compare P2P, local server, and cloud options for cost, skills, access, and recovery.
  5. Select one design, define a measurable service target, and name a test for it.

Expected: The diagram identifies central equipment, paths, and failure consequences. The recommendation ties topology and platform to stated business constraints. The group distinguishes provider commitments from end-to-end availability. No live network, real credentials, or production settings are used.

Limitations: RFC 3414 is foundational but dates from 2002 and specifies historic MD5/DES examples; deployed SNMPv3 algorithm support must be checked against current vendor guidance and policy. Azure Load Balancer describes one Layer 4 product; algorithms, probe semantics, affinity, and failure handling vary by implementation. LAN/WAN are geographic scope labels, not fixed throughput classes. Actual performance needs measurement of media, topology, load, and endpoints. Windows Server and Ubuntu/Linux sources are platform owners; they document their own capabilities, not a neutral performance or security ranking. Licensing and support terms change and must be checked for the proposed deployment. The Cisco subnet tutorial is older and includes classful simplifications; no classful assumptions are used for current network planning.

Network planning: tradeoffs and services

Network Planning

Network planning: tradeoffs and services

Page 1 · Lines 1–24

o Overview
-> Peer-to-peer or client-server
-> Cloud service benefits and costs
o Peer-to-peer or client-server
-> Peer-to-peer (P2P) lets endpoints share resources directly.
-> P2P avoids dedicated server cost for small, simple groups.
-> Each peer may manage users, rights, and copies separately.
-> Shared resource availability depends on its host being online.
-> Decentralized rights and backups hinder oversight and restore.
-> Compromised peer or account can expose shared resources.
-> Client-server centralizes shared services and administration.
-> Central policy is consistent but adds server dependencies.
-> Size capacity, backup, and failover for critical server roles.
o Cloud service benefits and costs
-> Cloud services provide computing or management over a network.
-> Elastic capacity meets demand without local hardware buying.
-> IaaS leaves OS to customer; PaaS and SaaS shift more layers.
-> Customer owns data and identities; contract terms govern.
-> Usage, storage, support, and transfer create recurring costs.
-> Connectivity failure interrupts dependent workflows.
-> Review identity, access, data protection, recovery, export.
-> Local systems need staff and facilities but may work offline.
-> Compare lifecycle costs and ownership, not hardware price.
-> Portability depends on formats, contracts, and dependencies.

Network planning: tradeoffs and services

Page 2 · Lines 25–48

o Overview
-> Cost, throughput, and availability
-> Service targets and design choice
o Cost, throughput, and availability
-> Constraints include budget, space, and compatibility.
-> Business drivers include capacity, growth, and recovery.
-> Measure busy-hour throughput and identify bottlenecks.
-> Bandwidth costs money and may not fix server or app delay.
-> Independent redundant links and devices improve availability.
-> Extra paths need routes, tests, monitoring, and skilled staff.
-> Star's central device can fail without redundancy.
-> Mesh increases path choices and cabling/management complexity.
-> Topology labels alone do not guarantee performance or uptime.
o Service targets and design choice
-> A service level agreement (SLA) states measurable promises.
-> Define service, measurement window, exclusions, and reporting.
-> Provider uptime is not end-to-end application uptime.
-> Map power, DNS, identity, carrier, and storage dependencies.
-> Health probes can remove unhealthy backends from flows.
-> A probe may miss an untested dependency failure.
-> Session persistence keeps client affinity but can skew load.
-> Model options against cost, throughput, recovery, and staff.
-> Record assumptions, options, owners, and review triggers.
-> Review targets when business impact or dependencies change.
Sources, practice, lab and scope notes

Objectives

  • ND-NP-06
  • ND-NP-07
  • ND-NP-08
  • ND-NP-09
  • ND-NP-01

Sources

  • FBLA 2026-27 Network Design Guidelines — fetched; Read study guide pp. 6-7 to verify Network Administration and Network Planning objective scope.
  • RFC 3411: SNMP Management Framework Architecture — fetched; Read §§1-2 and 3.1-3.2: manager and agent applications, managed objects/MIB, operations, notifications, and the distinction between message security and access control.
  • RFC 3414: SNMPv3 User-based Security Model — fetched; Read §§1.1-1.4 and 2: authentication provides integrity and user authentication, privacy protects payload disclosure and requires authentication, and timeliness limits replay. The document's example MD5/DES algorithms are historic, not current recommendations.
  • RFC 3418: SNMP Management Information Base — fetched; Read §§1-2, including system identity/location objects, SNMP counters, and notifications; used to explain management data and monitoring evidence.
  • RFC 1901: Community-based SNMPv2 — fetched; Read §§2-3: agents, managers, MIB objects, and SNMPv2c's community-based administrative framework. Historic experimental RFC; used only for community model context.
  • CISA: Reducing the Risk of SNMP Abuse — fetched; Read community-string exposure, SNMPv3 authPriv, MIB-view/ACL and least-privilege guidance. Dated 2017; confirm current device and cryptographic support.
  • Microsoft ping command reference — fetched; Read command description, examples, and parameters: ICMP Echo testing, name-versus-address comparison, and timeout behavior.
  • Microsoft tracert command reference — fetched; Read TTL-based path discovery and examples; intermediate routers can omit Time Exceeded responses, producing asterisks without proving a forwarding failure.
  • Microsoft ipconfig command reference — fetched; Read /all, /renew, /flushdns, and remarks: adapter configuration, DHCP renewal conditions, and local DNS-cache scope.
  • Microsoft Azure Load Balancer overview — fetched; Read Layer 4 flow distribution, backend pools, rules, health probes, monitoring, and availability overview. These are Azure implementation examples, not universal behavior for every load balancer.
  • Azure Load Balancer distribution modes — fetched; Read five-tuple hash distribution and two-/three-tuple client-IP affinity modes; same-client affinity can skew distribution, particularly where flow diversity is limited. Azure-specific implementation.
  • Azure Load Balancer health probes — fetched; Read TCP/HTTP probe operations, configured response/threshold behavior, unhealthy backend handling, and health-signal design guidance; implementation details vary by SKU and product.
  • Shared responsibility in the cloud — fetched; Read service-model responsibility matrix and retained customer duties for data, accounts, and access; Microsoft-specific guidance and contract terms govern.
  • What is Windows Server? — fetched; Read platform roles, deployment, management, integration, and licensing overview; used as vendor-specific evidence, not a neutral comparison or price quote.
  • Ubuntu Server documentation — fetched; Read overview sections for networking, security, software updates, storage, virtualisation, performance, and high availability.
  • What is Linux? — fetched; Read operating-system and distribution explanations: kernel, user space, packages, and different distribution choices. Vendor educational material; not used to claim universal superiority.
  • Microsoft print command reference — fetched; Read command syntax and examples showing local port printing and a named shared network queue.
  • Active Directory Domain Services overview — fetched; Read directory purpose and security sections: AD DS stores network objects and supports authentication, access control, and policy-based administration.
  • Configure IP Addresses and Unique Subnets for New Users — fetched; Read subnet/address examples and topology context. This older tutorial contains classful-era simplifications; notes do not treat them as modern routing practice.

Practice (answers below)

1. A small office wants shared files without a server. What should it weigh?

P2P reduces dedicated-server purchase and administration for simple sharing, but peers may be offline, backups and permissions vary, and ownership is decentralized. If consistent access, central policy, and recovery matter, compare a managed client-server or cloud service including full operating cost.

2. Does a successful load-balancer health probe prove the whole app is healthy?

No. A probe checks its configured signal and can direct flows away from a backend that fails that check. It may not test downstream identity, database, or a complete user transaction. Define probes around meaningful service health and monitor dependencies separately.

Controlled network design tabletop

  1. Use a fictional 30-user office, two rooms, fixed budget, and a stated outage limit.
  2. Draw star, partial mesh, and bus alternatives; mark links and shared failure points.
  3. Estimate peak users and identify a critical application and its dependencies.
  4. Compare P2P, local server, and cloud options for cost, skills, access, and recovery.
  5. Select one design, define a measurable service target, and name a test for it.

Expected: The diagram identifies central equipment, paths, and failure consequences. The recommendation ties topology and platform to stated business constraints. The group distinguishes provider commitments from end-to-end availability. No live network, real credentials, or production settings are used.

Limitations: RFC 3414 is foundational but dates from 2002 and specifies historic MD5/DES examples; deployed SNMPv3 algorithm support must be checked against current vendor guidance and policy. Azure Load Balancer describes one Layer 4 product; algorithms, probe semantics, affinity, and failure handling vary by implementation. LAN/WAN are geographic scope labels, not fixed throughput classes. Actual performance needs measurement of media, topology, load, and endpoints. Windows Server and Ubuntu/Linux sources are platform owners; they document their own capabilities, not a neutral performance or security ranking. Licensing and support terms change and must be checked for the proposed deployment. The Cisco subnet tutorial is older and includes classful simplifications; no classful assumptions are used for current network planning.

Network Environments and Security

Network Protocols, Services, and Access

Network Environments and Security

Page 1 · Lines 1–24

o Overview
-> Network Scale and Work Models
-> Devices and Trust Boundaries
o Network Scale and Work Models
-> A LAN links devices within a limited local site.
-> A WAN connects distant LANs over carrier or private links.
-> WAN reach adds provider, latency, recurring-cost tradeoffs.
-> Peer-to-peer hosts share directly; control is distributed.
-> P2P can suit small groups but complicates consistent policy.
-> Client-server centralizes services, identity, administration.
-> Central services simplify control but become dependencies.
-> Thin clients rely on remote compute/apps; outages impair use.
-> Servers provide services; clients request services.
o Devices and Trust Boundaries
-> A modem adapts a carrier access signal; products vary.
-> A router forwards IP packets between networks using routes.
-> A switch forwards local frames using learned MAC addresses.
-> Servers attach to switches; clients reach services over links.
-> An access point bridges Wi-Fi clients to a wired LAN.
-> A gateway joins networks or systems; roles may be combined.
-> A switch is not automatically a router or policy firewall.
-> Authentication checks an identity claim or credential control.
-> Authorization decides permitted actions after identity checks.
-> Encryption protects confidentiality when keys are secure.

Network Environments and Security

Page 2 · Lines 25–48

o Overview
-> Connectivity and Attack Patterns
-> VPN and Authorized Capture
o Connectivity and Attack Patterns
-> Ethernet (IEEE 802.3) commonly carries wired LAN frames.
-> Wi-Fi (802.11) uses radio; walls and noise affect links.
-> Wi-Fi reach and rate depend on band, load, and equipment.
-> Bluetooth is short-range personal-area radio, not WAN access.
-> Phishing tricks people into unsafe disclosure or actions.
-> Spoofing falsifies an address or identity signal to mislead.
-> Poisoning corrupts trusted data, e.g. name-resolution answers.
-> Attack labels overlap; identify the mechanism and target.
-> Verify requests; use MFA, filtering, and updates.
o VPN and Authorized Capture
-> A VPN creates a logical tunnel across an underlying network.
-> Configured VPNs can authenticate peers and encrypt traffic.
-> Tunneling does not secure endpoints or grant user permissions.
-> Packet capture records traffic visible at the capture point.
-> Encryption hides payload; metadata may remain visible.
-> Capture only with explicit authorization and approved scope.
-> Minimize collection; protect files; follow retention policy.
-> Authentication checks identity; authorization grants access.
-> VPNs do not replace endpoint, account, or network controls.
-> Never inspect others' traffic without authorization.
Sources, practice, lab and scope notes

Objectives

  • ND-NPSA-01
  • ND-NPSA-06
  • ND-NPSA-07
  • ND-NPSA-02
  • ND-NPSA-05
  • ND-NPSA-03
  • ND-NPSA-04

Sources

  • FBLA Network Design 2026-27 Individual Guidelines — fetched; Read study guide pp. 6-7 for ND-NPSA objectives; pp. 2-4 for equipment and timing; p. 8 for the seven spoken rating criteria and maxima. The document leaves SMP unexplained and conflicts on flipchart/visuals.
  • IETF RFC 9293: Transmission Control Protocol — fetched; Read the abstract and TCP service description: TCP is connection-oriented and provides reliable in-order byte-stream service; segments use IP datagrams and ports identify services.
  • IETF RFC 2131: Dynamic Host Configuration Protocol — fetched; Read DHCP overview and address-allocation/client-server sections: DHCP delivers host configuration and allocates addresses through client-server exchanges and leases; relay agents can pass requests across subnets.
  • Cisco: Configure IP Addresses and Unique Subnets — fetched; Read network-mask/subnet sections and device terminology for IP addressing, router interfaces, and gateway relationships. Its classful framing is older; these notes do not teach classful masks as current practice.

Practice (answers below)

1. A small firm has two distant offices. What makes a WAN useful, and what tradeoffs should be compared?

A WAN connects the offices' LANs over distance. Compare provider cost, latency, service availability, security controls, and support needs; do not assume a WAN is one specific technology.

2. Why does an encrypted VPN not by itself authorize every connected user?

Encryption protects traffic in transit and peer authentication checks a tunnel endpoint; user authorization separately determines which actions/resources an identity may access.

Authorized tabletop and timed decision rehearsal

  1. On paper, map a hypothetical two-site LAN/WAN with clients, switches, router, and server; predict the path to an application.
  2. For a fictional intermittent link, state observations, assumptions, and a safe sequence of physical, IP, and service checks. Do not capture live traffic.
  3. Compare two hypothetical connectivity designs using cost, availability, security, support, and latency; label all invented figures as exercise assumptions.
  4. Run a 20-minute preparation and 7-minute presentation rehearsal; have a teammate interrupt with questions about evidence, rollback, cost, and security.
  5. Score the response on all seven current rubric criteria and revise the weakest reasoning area.

Expected: Learner distinguishes LAN/WAN scope and correctly traces client, switch, router, and server roles. Learner separates facts from hypotheses and chooses non-destructive, authorized checks. Learner explains concrete tradeoffs and a feasible phased recommendation with resources and rollback. Learner answers each judge question with a direct claim, reason, evidence, and limitation or verification step. Learner identifies all rubric maxima accurately and treats practice as hypothetical, not a confidential prompt.

Limitations: The National guide prints SMP as an example but does not define it. This module preserves the ambiguity and does not substitute SMTP, SNMP, or another protocol; seek adviser clarification on expected scope. Network Design guideline p.2 lists flipchart/easel while p.4 prohibits visuals and props. The conflict is unresolved here; ask the adviser and do not assume equipment permission.

Protocols and Troubleshooting

Network Protocols, Services, and Access

Protocols and Troubleshooting

Page 1 · Lines 1–24

o Overview
-> Layers and Addressing Roles
-> TCP, UDP, DHCP, and Printed SMP
o Layers and Addressing Roles
-> OSI 1 physical: signaling, media, connectors, and bits.
-> OSI 2 data link: local frames and link-layer addressing.
-> OSI 3 network: IP addressing and routing between networks.
-> OSI 4 transport: process delivery, ports, and TCP or UDP.
-> OSI 5 session: coordinates dialogues between apps.
-> OSI 6 presentation: data representation and transformations.
-> OSI 7 application: network services used by applications.
-> OSI is a learning model; implementations may span layers.
-> TCP/IP names a protocol suite, not one individual protocol.
o TCP, UDP, DHCP, and Printed SMP
-> TCP provides reliable, ordered byte-stream service.
-> TCP sequence numbers and ACKs support ordered recovery.
-> UDP has no TCP delivery or ordering guarantees.
-> Applications select transport to fit their requirements.
-> DHCP client-server exchanges configure hosts.
-> DHCP leases assign addresses temporarily; clients renew them.
-> DHCP relays pass requests to servers on other subnets.
-> DHCP does not establish that a device is trusted.
-> The guide prints SMP but leaves its meaning undefined.
-> Keep SMP unresolved; do not silently replace the term.

Protocols and Troubleshooting

Page 2 · Lines 25–48

o Overview
-> Topology and Reachability Tests
-> Layered Physical Diagnosis
o Topology and Reachability Tests
-> Star links devices through a center; its failure affects many.
-> A star cable fault usually isolates its attached endpoint.
-> Bus shares a backbone; a break may affect many devices.
-> Ring forwards around a loop; recovery depends on protection.
-> Physical cabling shape may differ from logical topology.
-> Ping tests ICMP echo; loss is evidence, not a cause.
-> Firewalls may block echo even when application service works.
-> Tracert shows responding hops; filtering can hide responses.
-> A hop timeout alone does not prove destination failure.
o Layered Physical Diagnosis
-> First scope impact: one device, site, service, or all users?
-> Check power, cables, link lights, and Wi-Fi association.
-> Confirm correct SSID, enabled adapter, signal, and wired port.
-> Check VLAN, IP address, mask, gateway, and DNS next.
-> Compare gateway, permitted remote IP, then a DNS name.
-> IP works but names fail? Check the resolver path.
-> No lease suggests DHCP checks, not a proven cause.
-> Change one safe variable; preserve before/after evidence.
-> Repeat the test; document cause and outcome.
-> Only test cables or capture traffic when authorized and safe.
Sources, practice, lab and scope notes

Objectives

  • ND-NPSA-08
  • ND-NPSA-09
  • ND-NPSA-10
  • ND-NPSA-11

Sources

  • FBLA Network Design 2026-27 Individual Guidelines — fetched; Read study guide pp. 6-7 for ND-NPSA objectives; pp. 2-4 for equipment and timing; p. 8 for the seven spoken rating criteria and maxima. The document leaves SMP unexplained and conflicts on flipchart/visuals.
  • IETF RFC 9293: Transmission Control Protocol — fetched; Read the abstract and TCP service description: TCP is connection-oriented and provides reliable in-order byte-stream service; segments use IP datagrams and ports identify services.
  • IETF RFC 2131: Dynamic Host Configuration Protocol — fetched; Read DHCP overview and address-allocation/client-server sections: DHCP delivers host configuration and allocates addresses through client-server exchanges and leases; relay agents can pass requests across subnets.
  • Cisco: Configure IP Addresses and Unique Subnets — fetched; Read network-mask/subnet sections and device terminology for IP addressing, router interfaces, and gateway relationships. Its classful framing is older; these notes do not teach classful masks as current practice.

Practice (answers below)

1. A device has a valid IP and can reach a server by address but not by name. What would you test next?

Check configured DNS resolver and name lookup path, since IP reachability works while name resolution fails. Confirm with permitted lookup tests; this is evidence for a DNS issue, not proof until verified.

2. Contrast a ping failure with a traceroute hop timeout. Does either prove an outage?

No. Ping can be filtered, and intermediate traceroute hops may not respond while forwarding traffic. Corroborate with authorized end-to-end service tests and local physical checks.

Authorized tabletop and timed decision rehearsal

  1. On paper, map a hypothetical two-site LAN/WAN with clients, switches, router, and server; predict the path to an application.
  2. For a fictional intermittent link, state observations, assumptions, and a safe sequence of physical, IP, and service checks. Do not capture live traffic.
  3. Compare two hypothetical connectivity designs using cost, availability, security, support, and latency; label all invented figures as exercise assumptions.
  4. Run a 20-minute preparation and 7-minute presentation rehearsal; have a teammate interrupt with questions about evidence, rollback, cost, and security.
  5. Score the response on all seven current rubric criteria and revise the weakest reasoning area.

Expected: Learner distinguishes LAN/WAN scope and correctly traces client, switch, router, and server roles. Learner separates facts from hypotheses and chooses non-destructive, authorized checks. Learner explains concrete tradeoffs and a feasible phased recommendation with resources and rollback. Learner answers each judge question with a direct claim, reason, evidence, and limitation or verification step. Learner identifies all rubric maxima accurately and treats practice as hypothetical, not a confidential prompt.

Limitations: The National guide prints SMP as an example but does not define it. This module preserves the ambiguity and does not substitute SMTP, SNMP, or another protocol; seek adviser clarification on expected scope. Network Design guideline p.2 lists flipchart/easel while p.4 prohibits visuals and props. The conflict is unresolved here; ask the adviser and do not assume equipment permission.

Analyze and Recommend a Network Design

Network Design Role-Play Performance

Analyze and Recommend a Network Design

Page 1 · Lines 1–24

o Overview
-> Define the Problem and Criteria
-> Compare Real Alternatives
o Define the Problem and Criteria
-> Restate the scenario accurately before proposing technology.
-> Separate observed symptoms from business problems and impact.
-> Identify stakeholders, sites, users, data, and deadlines.
-> Separate stated facts, assumptions, unknowns, and risks.
-> Measure goals: uptime, latency, cost, or security.
-> Rank mandatory constraints above preferences and explain why.
-> Map clients, switches, servers, gateways, and WAN links.
-> Identify trust boundaries and single points of failure.
-> Use network knowledge to explain impact and constraints.
o Compare Real Alternatives
-> Offer at least two credible options that meet the stated need.
-> Compare options against the same weighted decision criteria.
-> Assess capital, recurring cost, labor, and support effort.
-> Assess speed, resilience, security, complexity, and growth.
-> Name each option's concrete advantage and material drawback.
-> VPN offers control; managed WAN may simplify support.
-> VPN also needs endpoint, identity, and failover management.
-> Reject options against constraints, not straw-man comparisons.
-> Label estimates; avoid invented vendor guarantees.
-> Choose an option and acknowledge its residual risks.

Analyze and Recommend a Network Design

Page 2 · Lines 25–48

o Overview
-> Plan Feasible Implementation
-> Connect Design to Business Value
o Plan Feasible Implementation
-> Phase work: discover, design, pilot, migrate, verify, review.
-> Name owner, sequence, dependencies, and approval path.
-> List labor, equipment, licenses, circuits, and training.
-> Schedule maintenance and notify affected stakeholders.
-> Export configs and protect backups before production changes.
-> Set rollback trigger, owner, and tested recovery procedure.
-> Use least privilege, authentication, updates, and encryption.
-> Test access, service performance, recovery, and failover.
-> Compare test results with scenario success criteria.
o Connect Design to Business Value
-> VLANs separate teams; verify routing and access rules.
-> Switch ACLs limit flows; test allowed and denied paths.
-> A second link helps only with sufficiently independent paths.
-> Redundancy costs more and cannot ensure app recovery.
-> A pilot limits impact and reveals compatibility problems.
-> Monitoring checks health; assign a response owner.
-> Document topology, configs, dependencies, and support handoff.
-> State decision, next action, owner, and review date.
-> Tie technical choices to business needs or constraints.
-> If key facts are unknown, propose discovery before commitment.
Sources, practice, lab and scope notes

Objectives

  • ND-RP-01
  • ND-RP-04
  • ND-RP-02
  • ND-RP-03

Sources

  • FBLA Network Design 2026-27 Individual Guidelines — fetched; Read study guide pp. 6-7 for ND-NPSA objectives; pp. 2-4 for equipment and timing; p. 8 for the seven spoken rating criteria and maxima. The document leaves SMP unexplained and conflicts on flipchart/visuals.
  • IETF RFC 9293: Transmission Control Protocol — fetched; Read the abstract and TCP service description: TCP is connection-oriented and provides reliable in-order byte-stream service; segments use IP datagrams and ports identify services.
  • IETF RFC 2131: Dynamic Host Configuration Protocol — fetched; Read DHCP overview and address-allocation/client-server sections: DHCP delivers host configuration and allocates addresses through client-server exchanges and leases; relay agents can pass requests across subnets.
  • Cisco: Configure IP Addresses and Unique Subnets — fetched; Read network-mask/subnet sections and device terminology for IP addressing, router interfaces, and gateway relationships. Its classful framing is older; these notes do not teach classful masks as current practice.

Practice (answers below)

1. A two-site firm needs resilient access to a central app. Compare two approaches and give a decision criterion.

Compare site-to-site VPN over Internet with a managed WAN. VPN may lower circuit cost but requires tunnel, endpoint, and failover management; managed WAN may simplify operations but costs more and depends on provider terms. Compare measured availability, cost, latency, and support capacity before selecting.

2. What makes a network implementation plan feasible rather than just a preferred design?

It assigns owners and sequence, identifies labor/equipment/licenses, approvals and outage window, protects configuration backups, defines acceptance tests and rollback triggers, and accounts for operational support.

Authorized tabletop and timed decision rehearsal

  1. On paper, map a hypothetical two-site LAN/WAN with clients, switches, router, and server; predict the path to an application.
  2. For a fictional intermittent link, state observations, assumptions, and a safe sequence of physical, IP, and service checks. Do not capture live traffic.
  3. Compare two hypothetical connectivity designs using cost, availability, security, support, and latency; label all invented figures as exercise assumptions.
  4. Run a 20-minute preparation and 7-minute presentation rehearsal; have a teammate interrupt with questions about evidence, rollback, cost, and security.
  5. Score the response on all seven current rubric criteria and revise the weakest reasoning area.

Expected: Learner distinguishes LAN/WAN scope and correctly traces client, switch, router, and server roles. Learner separates facts from hypotheses and chooses non-destructive, authorized checks. Learner explains concrete tradeoffs and a feasible phased recommendation with resources and rollback. Learner answers each judge question with a direct claim, reason, evidence, and limitation or verification step. Learner identifies all rubric maxima accurately and treats practice as hypothetical, not a confidential prompt.

Limitations: The National guide prints SMP as an example but does not define it. This module preserves the ambiguity and does not substitute SMTP, SNMP, or another protocol; seek adviser clarification on expected scope. Network Design guideline p.2 lists flipchart/easel while p.4 prohibits visuals and props. The conflict is unresolved here; ask the adviser and do not assume equipment permission.

Deliver and Defend the Recommendation

Network Design Role-Play Performance

Deliver and Defend the Recommendation

Page 1 · Lines 1–24

o Overview
-> Organize a Decision Briefing
-> Communicate with Confidence
o Organize a Decision Briefing
-> National format: 20 minutes prep, 7 minutes delivery.
-> No separate Q&A; judges may interrupt during delivery.
-> Sequence: problem, criteria, options, choice, implementation.
-> Summarize facts and prioritized problems before solutions.
-> Compare options' pros and cons against common criteria.
-> Explain how the choice meets ranked requirements.
-> State phases, resources, owners, tests, and rollback triggers.
-> Use signposts and transitions to clarify the reasoning.
-> Close with success measure, requested decision, and next step.
o Communicate with Confidence
-> Project voice at a measured pace; pause after key decisions.
-> Use poised posture, purposeful gestures, and eye contact.
-> Define acronyms; connect technical terms to business impact.
-> Avoid jargon lists; explain mechanisms behind your choice.
-> Split speaking roles only when transitions stay coherent.
-> Every teammate should know the recommendation and risks.
-> Label assumptions and estimates; do not invent scenario facts.
-> Do not bluff when uncertain; describe safe verification steps.
-> Keep material explanations usable without visual aids.
-> Pause after key points; do not rush the conclusion.

Deliver and Defend the Recommendation

Page 2 · Lines 25–48

o Overview
-> Answer Judges Completely
-> Rubric and Practice Boundaries
o Answer Judges Completely
-> Listen through the full question before answering.
-> Clarify scope if needed, then answer the question directly.
-> Support the answer with reasoning and scenario evidence.
-> Address each part; state limits and residual risk honestly.
-> For unknown facts, name what to verify and how to verify it.
-> If a judge challenges an assumption, reassess it calmly.
-> Correct factual errors plainly; return to decision logic.
-> Acknowledge interruption; return to your planned sequence.
-> Complete interaction requires reasoning, not memorized lines.
o Rubric and Practice Boundaries
-> Maxima: problem 10; alternatives 20; solution 20.
-> Knowledge 20; organization, delivery, answers 10 each.
-> Spoken rubric totals 100 points before penalties.
-> Judges ask during presentation; no separate Q&A is scheduled.
-> Guide p.2 lists easel; p.4 prohibits visuals and props.
-> Conflict unresolved; ask adviser for clarification.
-> Do not assume permission; prepare a verbal explanation.
-> Practice cases are hypothetical, not official prompts.
-> Competitors author their own competition response.
-> Score rehearsal against each criterion's actual point maximum.
Sources, practice, lab and scope notes

Objectives

  • ND-RP-05
  • ND-RP-01
  • ND-RP-02
  • ND-RP-03
  • ND-RP-06
  • ND-RP-04
  • ND-RP-07

Sources

  • FBLA Network Design 2026-27 Individual Guidelines — fetched; Read study guide pp. 6-7 for ND-NPSA objectives; pp. 2-4 for equipment and timing; p. 8 for the seven spoken rating criteria and maxima. The document leaves SMP unexplained and conflicts on flipchart/visuals.
  • IETF RFC 9293: Transmission Control Protocol — fetched; Read the abstract and TCP service description: TCP is connection-oriented and provides reliable in-order byte-stream service; segments use IP datagrams and ports identify services.
  • IETF RFC 2131: Dynamic Host Configuration Protocol — fetched; Read DHCP overview and address-allocation/client-server sections: DHCP delivers host configuration and allocates addresses through client-server exchanges and leases; relay agents can pass requests across subnets.
  • Cisco: Configure IP Addresses and Unique Subnets — fetched; Read network-mask/subnet sections and device terminology for IP addressing, router interfaces, and gateway relationships. Its classful framing is older; these notes do not teach classful masks as current practice.

Practice (answers below)

1. During a hypothetical clinic Wi-Fi case, a judge asks how you know access-point placement is the cause. Respond completely.

It is not yet established. I would compare coverage and interference measurements in affected and unaffected rooms at peak times, review client association and wired backhaul, then pilot a placement change and repeat the same tests. I would retain rollback if performance or security worsens.

2. Name all seven role-play criteria and their current maximum points.

Problem definition 10, alternatives and pros/cons 20, solution and implementation 20, event knowledge 20, organization 10, delivery 10, and judge interaction/answers 10; total 100.

Authorized tabletop and timed decision rehearsal

  1. On paper, map a hypothetical two-site LAN/WAN with clients, switches, router, and server; predict the path to an application.
  2. For a fictional intermittent link, state observations, assumptions, and a safe sequence of physical, IP, and service checks. Do not capture live traffic.
  3. Compare two hypothetical connectivity designs using cost, availability, security, support, and latency; label all invented figures as exercise assumptions.
  4. Run a 20-minute preparation and 7-minute presentation rehearsal; have a teammate interrupt with questions about evidence, rollback, cost, and security.
  5. Score the response on all seven current rubric criteria and revise the weakest reasoning area.

Expected: Learner distinguishes LAN/WAN scope and correctly traces client, switch, router, and server roles. Learner separates facts from hypotheses and chooses non-destructive, authorized checks. Learner explains concrete tradeoffs and a feasible phased recommendation with resources and rollback. Learner answers each judge question with a direct claim, reason, evidence, and limitation or verification step. Learner identifies all rubric maxima accurately and treats practice as hypothetical, not a confidential prompt.

Limitations: The National guide prints SMP as an example but does not define it. This module preserves the ambiguity and does not substitute SMTP, SNMP, or another protocol; seek adviser clarification on expected scope. Network Design guideline p.2 lists flipchart/easel while p.4 prohibits visuals and props. The conflict is unresolved here; ask the adviser and do not assume equipment permission.