Welcome to Orange and Peel

Company background

Orange and Peel began in 2008 when longtime friends Nora Orange and Peter Peel rented a small warehouse outside Grove. Their original business supplied fresh citrus and specialty ingredients to independent restaurants, bakeries, and neighborhood markets. Nora managed relationships with growers while Peter built a reputation for getting difficult orders delivered on time.

The company grew through personal service rather than sophisticated technology. Orders initially arrived by phone, inventory lived in spreadsheets, and the warehouse team could identify most customers by name. That approach worked well while everyone operated from one building.

By 2015, Orange and Peel had expanded beyond wholesale produce. The company began making bottled juices, dried fruit, preserves, and citrus-based flavoring products. Production remained at Grove, but new distribution sites were opened to shorten delivery times and support regional customers.

Today, Orange and Peel employs approximately 180 people across four locations. The company is still privately owned and takes pride in being friendly, practical, and quick to adapt. Unfortunately, its network has adapted a little too quickly.

The sites

Grove — Headquarters

Grove is the original location and remains the center of the company. It contains:

• Executive and administrative offices
• The main warehouse and production floor
• Finance and customer-service teams
• Central IT services
• Network monitoring and management systems
• Central voice and security services

Most company-wide technology is operated from Grove. If Grove becomes unavailable, the branches can continue some local work, but many business services are affected.

Zest — Sales and customer experience

Zest was the first branch office. It supports regional sales, product demonstrations, and customer training. Its employees rely heavily on voice, video meetings, and access to corporate applications hosted at Grove.

Zest frequently hosts customers and therefore needs dependable guest access that remains separated from corporate systems.

Juice — Distribution and logistics

Juice is a busy distribution site with warehouse workstations, shipping stations, phones, handheld devices, and network-connected operational equipment. The site operates early and late shifts, so outages outside normal office hours can still interrupt the business.

The site is especially sensitive to poor documentation because visiting technicians may be asked to troubleshoot equipment without help from the person who installed it.

Pulp — Product development and quality testing

Pulp is the newest site. It contains offices, test kitchens, small production equipment, security devices, and temporary workspaces for visiting employees. The site changes frequently as equipment and projects move in and out.

Pulp needs a network that can accommodate change without sacrificing segmentation or supportability.

How the network reached its current state

Each location was originally opened under time pressure. Switches were purchased when needed, local vendors made one-off changes, and documentation varied from site to site. Some settings are sensible, some are outdated, and some exist because “that was the only way it worked at the time.”

As the company grew, several recurring problems appeared:

• Device names and interface descriptions were inconsistent.
• Management addressing was not applied uniformly.
• Unused ports were not always secured.
• Voice, guest, security, and corporate devices were sometimes mixed together.
• Configuration backups were incomplete or difficult to locate.
• Branch troubleshooting depended too heavily on individual memory.
• Firewall rules accumulated without clear documentation.
• Remote connectivity was built for immediate needs rather than a common design.

No major incident triggered the current project. Leadership instead recognized that the company had reached the point where informal practices created unacceptable operational and security risk.

The Citrus Refresh project

Orange and Peel has launched an internal modernization effort called Project Citrus Refresh. The project will standardize the network at all four sites while allowing the business to remain operational.

The project goals are to:

• Apply the approved switch standards consistently.
• Separate Corp, Voice, Netman, Guest, and optional Security traffic.
• Give every network device a predictable identity and management address.
• Introduce consistent firewall routing and security policy.
• Preserve local guest internet access without exposing internal systems.
• Connect the branches securely to Grove.
• Improve configuration backups, diagrams, and troubleshooting records.
• Make the environment supportable by any qualified technician.

Your role

You are the Tier 1 technical team assigned to Project Citrus Refresh. Each technician owns one site throughout the project

Your responsibility is broader than making the equipment work. Every configuration must follow the standard, every change must be verifiable, and every site must be left in a state that another technician can support.

Over the coming weeks, you will:

1. Standardize and configure the site switch.
2. Validate a peer's deployment and resolve Layer 2 incidents.
3. Introduce Layer 3 gateways and routing.
4. Enforce firewall segmentation and outbound-access requirements.
5. Connect the branches securely to Grove.

Project Citrus Refresh is successful when the network works as designed, prohibited traffic fails for the intended reason, and the team can explain the complete traffic path from an endpoint at a branch to a service at headquarters.

Week 1 Discussion Problem — A Switch for Every Site

The situation

Orange and Peel is beginning Project Citrus Refresh. The company has one headquarters at Grove and branch offices at Zest, Juice, and Pulp. Each location has received a spare switch that will eventually support employees, phones, guests, network management, and—in some locations—security equipment.

The switches were pulled from storage. Nobody is willing to guarantee what configuration is currently on them. Some may have old names, old VLANs, outdated management settings, or configuration left behind by a previous project.

Orange and Peel wants all four sites to follow the same switch standard. A technician visiting an unfamiliar site should be able to identify the switch, understand its port usage, manage it securely, and locate a usable backup without relying on the original installer.

At this stage, no firewall or router has been installed. The immediate goal is to create a safe, consistent Layer 2 foundation.

Business requirements

• Employee devices, phones, guests, network management, and optional security equipment have different business purposes.
• Guest devices must not share the same Layer 2 environment as company devices.
• Network-device management must be kept separate from normal user traffic.
• Phones must be supported without requiring a completely separate physical switch.
• Unused ports must not provide unapproved network access.
• Device identity and interface purpose must be obvious to another technician.
• Management must use approved secure methods.
• The configuration must survive a reboot and be recoverable if the switch fails.
• The design should be repeatable at future sites.

Questions for the group

1. What should be inspected and recorded before changing an unknown switch?
2. Which groups of devices should share a broadcast domain, and which should be separated?
3. What logical networks are required at every site? Which one is conditional?
4. How can a phone and a workstation use the same physical edge location while remaining logically separated?
5. What information should a hostname communicate?
6. What information belongs in an interface description?
7. How should the switch itself be managed?
8. What should happen to ports that are not currently assigned?
9. What protections reduce the risk of an accidental Layer 2 loop?
10. What must be included in the trunk to the future firewall?
11. What should a technician verify before declaring the switch ready?
12. What evidence would prove that the saved configuration is usable?

Produce a high-level design

As a group, sketch one site and identify:

• Endpoint categories
• Proposed Layer 2 boundaries
• Access-port types
• The future firewall uplink
• The management path
• Required standards controls
• Verification points

Do not write device commands yet. The purpose is to agree on what the network must accomplish and why.

Information to request

Before implementation, list the details you would need from the network standard or project owner. Consider naming, VLANs, management addressing, authentication, monitoring, time, logging, trunking, STP, unused ports, backups, and approved software.

Week 1 — Layer 2 Fundamentals and Switch Standards

Scenario

Orange and Peel is preparing four sites for deployment. Each technician has received a spare switch with an unknown or incomplete configuration. The switch must be brought into compliance with company standards before it can be installed.

Objectives

By the end of the session, participants should be able to:

• Explain basic Ethernet switching, MAC learning, broadcasts, VLANs, trunks, and STP.
• Locate and interpret the Orange Pod switch standards.
• Establish console access and identify the switch's current state.
• Apply a standards-compliant baseline without losing management access.
• Verify and back up a configuration.

Suggested duration

120 minutes

Equipment

• One switch and console cable per participant
• One test endpoint per participant
• Patch cables
• Approved switch standards and configuration template
• Terminal-emulation software
• A safe configuration-backup location

Site assignments

Agenda

1. Baseline Q&A — 30 minutes

Use short scenarios instead of trivia questions. Mark each topic as comfortable, partial, or unfamiliar.

1. What is layer 2 ?
2. How does a switch learn its MAC-address table?
3. What happens when the destination MAC address is unknown?
4. What is a broadcast domain?
5. What problem does a VLAN solve?
6. What is the difference between an access port and a trunk?
7. Why must both ends of a trunk agree about VLAN tagging?
8. What is a native or untagged VLAN?
9. What does STP protect the network from?
10. Why can two hosts in different VLANs not communicate through a Layer 2 switch alone?

2. Standards walkthrough — 30 minutes

For each applicable company standard, cover the required setting, its purpose, and the verification method.

• Device and domain naming
• Management VLAN and address
• Firmware Updates
• Interface Configuration
• Access- and trunk-port conventions
• Allowed and native VLAN expectations
• STP mode and edge-port protections
• Configuration storage and backup

Do not place real production secrets in the lab configuration.

3. Guided configuration — 45 minutes

Participants should:

1. Connect through the console.
2. Record model, serial number, software version, and existing state.
3. Reset the device.
4. Apply the assigned hostname and domain configuration.
5. Create VLANs 10, 100, 220, and 250.
6. Create VLAN 210 only when directed.
7. Configure the switch management interface as .5/24 in VLAN 220.
8. Configure the future default gateway as .1 in the Netman network.
9. Apply approved access, authentication, logging, time, monitoring, and security standards.
10. Save and export the configuration.

4. Verification and closeout — 15 minutes

Each participant demonstrates:

• The correct device identity
• The correct VLAN configuration
• The correct Netman address
• Secure administrative access
• Successful configuration save

Instructor notes

• The firewall is not present yet. A temporary test host in VLAN 220 may be used to verify management connectivity.
• Do not require inter-VLAN communication during Week 1.
• Ask participants to explain why each setting exists instead of simply reading configuration lines.
• Record weak Q&A topics so they can be revisited in Week 2.

Week 1 Homework — Build the Orange and Peel Access Switch

Assignment

Finish the standards-compliant Layer 2 configuration for your assigned site. The result must be understandable and supportable by another technician.

Required VLANs

Required work

• Complete every applicable item in the company switch standard.
• Use the assigned FQDN.
• Configure the switch as .5/24 in the site's Netman network.
• Configure .1 as the future Netman gateway.
• Add clear descriptions to every active or reserved interface.
• Configure the future firewall uplink as a trunk.
• Restrict the trunk to the approved site VLANs.
• Apply the approved native/untagged VLAN standard.
• Apply approved STP edge and loop-protection features.
• Secure or disable all unused interfaces according to standards.
• Save the running configuration to startup configuration.
• Export a dated configuration backup.

Verification

Capture the platform-equivalent output showing:

• Device identity and software version
• VLANs and VLAN names
• Access-port assignments
• Trunk state and allowed VLANs
• Management IP and default gateway
• Interface status and descriptions
• MAC-address learning from a connected endpoint
• Running and saved configuration state

Submission

Submit:

1. The sanitized configuration backup.
2. A port map.
3. Verification output.
4. A standards checklist marked Pass, Fail, or Not applicable.
5. A short explanation of why hosts in different VLANs cannot communicate yet.

Do not include reusable credentials, private keys, or production secrets.

Completion standard

Another technician should be able to audit the switch, identify every connected device, and restore the switch from the submitted documentation.

Week 2 Discussion Problem — It Worked When We Installed It

The situation

The four Orange and Peel switches have been configured and are being prepared for deployment. During final validation, the project manager reports that the results are inconsistent.

At one site, an employee workstation connects physically but appears to be on the guest network. At another site, a phone cannot use voice services even though the workstation connected through it still works. A third switch is reachable from a directly connected management laptop but not from elsewhere in the management network. At the remaining site, guest connectivity works on one port but fails when traffic must cross the uplink.

The original installers insist that their configurations worked when they finished. The project manager does not want the switches erased and rebuilt. The team must identify the actual fault, make the smallest justified correction, and prove that unrelated services still work.

Constraints

• Each technician must review a switch configured by someone else.
• Existing configurations and user changes must be preserved unless a change is required.
• A working link light is not sufficient evidence of working service.
• Multiple symptoms may share one cause, and similar symptoms may have different causes.
• The running configuration may not match the saved configuration.
• Standards compliance and functional operation must both be checked.
• Every change must be documented and reversible.

Questions for the group

1. What facts are missing from each reported symptom?
2. How would you determine the scope before touching the configuration?
3. Which evidence would distinguish a physical problem from a VLAN problem?
4. How could a workstation work while a phone at the same desk fails?
5. How could one VLAN work locally but fail across an uplink?
6. Why might local switch management work while remote management fails?
7. Which tables and interface states are most useful at Layer 2?
8. How should the known-good backup be used without assuming it is correct?
9. Why should only one variable be changed at a time?
10. What regression tests should follow a correction?
11. Which findings are functional faults, and which are standards violations?
12. What should a useful support record tell the next technician?

Develop a troubleshooting plan

Create a shared sequence that begins with the reported user experience and moves through:

• Physical state
• Port configuration
• VLAN membership
• MAC-address learning
• Uplink behavior

For each stage, identify what evidence would allow you to continue or change direction.

Discussion challenge

Choose one reported symptom and propose at least three plausible causes at different points in the path. For each cause, identify a test that could disprove it without making a configuration change.

Week 2 — Layer 2 Validation and Troubleshooting

Scenario

The four Orange and Peel switches have passed initial configuration, but predeployment testing has found inconsistent results. Each technician must audit a peer's switch and resolve reported symptoms without being told the faulty command.

Objectives

• Validate a switch against written standards.
• Separate physical, Layer 2, and management-plane symptoms.
• Use interface, VLAN, trunk, MAC-table, and STP evidence.
• Make controlled changes and demonstrate restoration.
• Produce a useful troubleshooting record.

Suggested duration

90–120 minutes

Peer-review rotation

Troubleshooting method

1. Restate the reported symptom.
2. Determine the affected users, ports, VLANs, and devices.
3. Record the initial state.
4. Check physical status.
5. Check access-port and VLAN state.
6. Check trunking and STP.
7. Form a testable hypothesis.
8. Change one item.
9. Verify both the original symptom and adjacent services.
10. Document the result.

Instructor fault bank

Select one functional fault and one standards violation per switch. Save a known-good backup before injecting faults.

Ticket examples

Ticket A: Wrong network

A Grove Corp workstation connects physically but receives guest-network behavior. Other Corp workstations are unaffected.

Ticket B: Voice deployment failure

A phone at Zest powers on, but the voice network is unavailable. A workstation connected through the phone still reaches Corp resources.

Ticket C: Management outage

The Juice switch responds locally but cannot be managed from outside its Netman subnet.

Ticket D: Guest inconsistency

Guest connectivity works on one Pulp switch port but not across the uplink path.

Functional faults

• Corp endpoint placed in VLAN 250
• VLAN 100 missing
• VLAN 250 omitted from the trunk
• Firewall-uplink port configured as an access port
• Required VLAN pruned or blocked
• Edge port administratively disabled
• Netman subnet mask incorrect
• Switch default gateway incorrect
• Port-security or STP protection triggered by the test setup

Standards violations

• Incorrect hostname or domain
• Missing interface description
• Unused port active
• Insecure management protocol enabled
• NTP, syslog, or monitoring setting omitted
• Native/untagged VLAN inconsistent with the standard
• Saved configuration differs from running configuration

Closeout discussion

Each technician explains:

• The evidence that narrowed the fault domain
• The root cause
• Why the correction was appropriate
• How the final state was verified
• Whether the fault would have been detected by the standards checklist

Week 2 Homework — Audit, Repair, and Document

Assignment

Complete the peer audit started during the session, repair all authorized faults, and return the switch to its owner with a supportable record.

Required work

• Audit every applicable switch-standard item.
• Review running configuration
• Resolve the assigned ticket.
• Verify that the correction did not disrupt other VLANs or management access.
• Update inaccurate interface descriptions and port-map information.
• Save and export the corrected configuration.
• Explain the fault to the switch owner.

Troubleshooting record

Complete the following for every fault:

Layer 2 traffic explanation

Write a short packet-walk explanation for both cases:

1. Two Corp hosts in the same VLAN communicate through a switch.
2. A Corp host attempts to communicate with a Guest host before a Layer 3 gateway exists.

Include the roles of the source and destination MAC addresses, MAC-address learning, broadcasts, and VLAN boundaries.

Submission

Submit:

• Completed standards audit
• Completed troubleshooting record
• Corrected, sanitized configuration backup
• Updated port map
• Layer 2 traffic explanation

Week 3 Discussion Problem — The Networks Need to Talk

The situation

The access switches at Grove, Zest, Juice, and Pulp now follow a common standard. Corporate workstations can communicate with other devices in their own logical network, and guest devices remain in a separate Layer 2 environment.

This separation has introduced the next business need. Employees must reach approved services outside their local network. Phones require access to voice services. Network technicians must manage switches from the management network. Guests need a path toward internet service. The optional security network may need to reach a controller.

Simply connecting all of the logical networks together would defeat the reason they were separated. Orange and Peel needs a Layer 3 boundary at each site that can act as the default gateway and later enforce security policy.

Each site has been assigned a firewall, but the firewalls have not yet been connected or configured.

Business requirements

• Every required logical network needs a predictable default gateway.
• The existing switch design should not need to be rebuilt.
• One physical switch-to-firewall connection should carry the site networks when supported.
• The switch must remain manageable on the network-management segment.
• Addressing must be consistent enough for technicians to recognize a site and network quickly.
• The design must support future site-to-site connectivity.
• Initial testing must distinguish routing behavior from security-policy behavior.
• A bad client address, mask, or gateway should be diagnosable from evidence.

Questions for the group

1. How does an endpoint decide whether a destination is local or remote?
2. What does the endpoint do when the destination is remote?
3. Which device should become the default gateway for each logical network?
4. How can one physical firewall interface serve multiple logical networks?
5. What must the switch and firewall agree on for that connection to work?
6. What routes appear automatically when the firewall interfaces are configured?
7. Why is a valid route not the same as permission to pass traffic?
8. What must be true about the return path?
9. Which addresses should be reserved for infrastructure?
10. How can the team prove that the switch remains reachable through the management network?
11. Where would you collect evidence if a client can reach its gateway but not another network?
12. What should be tested before any WAN or VPN work begins?

Produce a logical design

Draw one site with:

• At least two endpoint networks
• The management network and switch
• The switch-to-firewall connection
• Firewall gateway interfaces
• A representative source and destination host

Then narrate a packet moving between two logical networks. Identify every Layer 2 and Layer 3 decision, but do not create firewall rules or device commands yet.

Failure analysis

Discuss how the symptoms would differ if the problem were:

• A wrong endpoint subnet mask
• A wrong endpoint default gateway
• A missing VLAN on the trunk
• A missing firewall interface
• A valid route with no permitting policy
• A missing return path

Week 3 — Layer 3 Fundamentals and Firewall Onboarding

Scenario

The Orange and Peel switches are ready. Each site now needs a firewall to act as the default gateway for its VLANs. Participants will extend their existing Layer 2 deployment into a routed branch network.

Objectives

• Explain subnetting, default gateways, ARP, connected routes, and return paths.
• Distinguish routing decisions from firewall-policy decisions.
• Configure an 802.1Q handoff between a switch and firewall.
• Create one firewall interface per site VLAN.
• Verify inter-VLAN packet flow methodically.

Suggested duration

120 minutes

Agenda

1. Layer 3 baseline Q&A — 30 minutes

Use short scenarios instead of trivia questions. Mark each topic as comfortable, partial, or unfamiliar.

1. What is Layer 3, and what problem does it solve that Layer 2 does not?
2. What is an IP network or subnet?
3. How does a host use its IP address and subnet mask to decide whether a destination is local or remote?
4. What is a default gateway, and when does a host use it?
5. Whose MAC address does a host use when the destination is on another network?
6. What information is contained in a routing table?
7. What is the difference between a connected route and a default route?
8. How does a router choose between multiple matching routes?
9. Why must a valid return path exist?
10. Why does having a route not necessarily mean that a firewall will permit the traffic?

2. Layer 3 and routing walkthrough — 30 minutes

Build a shared, high-level mental model before opening the firewall interface. Keep this section vendor-neutral and focus on what happens to a packet.

• Networks and subnets: An IP address identifies a host and, together with its subnet mask, the network to which it belongs.
• Local versus remote traffic: A host compares the destination address with its own network. Local traffic is sent directly to the destination; remote traffic is sent to the default gateway.
• ARP and the gateway: ARP resolves an IPv4 address to a MAC address on the local VLAN. For a remote destination, the host resolves the gateway's MAC address—not the remote host's MAC address.
• Routers and Layer 3 boundaries: Routers connect different IP networks. Each routed interface belongs to a network and can serve as that network's gateway.
• Routing tables: A routing table lists known destination networks and the next step for reaching them. Directly attached interface networks normally create connected routes automatically.
• Route selection: A router chooses the most specific matching route. A default route is the fallback used when no more-specific route matches.
• Hop-by-hop forwarding: The source and destination IP addresses normally remain the same while the Layer 2 headers are replaced at each routed hop.
• Return paths: Two-way communication requires the destination and every routing device involved to know how to return traffic to the source.
• Routing versus policy: Routing determines where traffic should go. Firewall policy determines whether that traffic is allowed to pass.
• NAT, DNS, and troubleshooting: NAT may translate addresses, while DNS translates names to addresses; neither replaces routing. Test addressing, gateway reachability, routes, and policy separately.

Use one example packet—from a Corp workstation to a Guest workstation—to draw the endpoint's subnet decision, ARP for the gateway, the firewall's route lookup, the policy decision, and the return path.

3. Firewall and addressing walkthrough — 15 minutes

Connect the routing concepts to the lab design before configuring devices.

• Each VLAN is a separate Layer 2 broadcast domain and IP network.
• The firewall supplies the .1/24 default gateway for each site VLAN.
• An 802.1Q trunk carries the VLANs between the switch and firewall over one physical connection.
• Configuring each firewall VLAN interface creates a directly connected route.
• Temporary lab policies permit selected tests; they do not create the routes.
• The switch remains managed at .5/24 in the Netman VLAN.

Addressing standard

For every site, the firewall uses .1/24 and the third octet matches the VLAN ID.

4. Guided implementation — 35 minutes

1. Back up the switch and firewall starting configurations.
2. Verify the switch uplink trunk and allowed VLANs.
3. Connect the firewall without attaching it to production or an unapproved WAN.
4. Create tagged firewall interfaces for VLANs 10, 100, 220, and 250.
5. Add VLAN 210 only when assigned.
6. Assign the correct .1/24 gateway addresses.
7. Configure DHCP scopes if included in the lab platform.
8. Add temporary, clearly labeled policies sufficient for the routing tests.
9. Test an endpoint's gateway, ARP entry, and selected inter-VLAN traffic.
10. Review the firewall's connected routes, session table, logs, and packet captures.

5. Verification and closeout — 10 minutes

• Correct a client with a wrong subnet mask.
• Correct a client with a wrong default gateway.
• Demonstrate that the switch remains managed at Netman .5.
• Trace Corp-to-Guest traffic and identify both Layer 2 and Layer 3 headers.
• Remove one temporary policy and explain why a valid route is not sufficient.

Instructor notes

Keep the initial policy set simple. Week 3 is about addressing and routing behavior; production-style segmentation and NAT are introduced in Week 4.

Week 3 Homework — Build the Site Gateway

Assignment

Complete the Layer 3 deployment for your Orange and Peel site. Every required VLAN must have a working gateway, and the evidence must show that you understand the traffic path.

Required work

• Confirm the switch-to-firewall trunk carries only approved VLANs.
• Configure firewall interfaces for Corp, Voice, Netman, and Guest.
• Configure Security only if assigned.
• Use .1/24 as each VLAN's firewall address.
• Preserve the switch's .5/24 Netman address.
• Configure lab DHCP scopes if assigned; exclude infrastructure addresses.
• Configure only the temporary policies authorized by the instructor.
• Back up both the switch and firewall configurations.

Test matrix

Record the expected and actual result. Do not mark a test Pass without evidence.

Packet walk

Explain a packet traveling from a Corp endpoint to a Guest endpoint. Include:

• The endpoint's subnet decision
• ARP for the default gateway
• Source and destination MAC addresses on the first segment
• The firewall's route lookup
• The firewall-policy decision
• Rewritten Layer 2 headers on the destination segment
• The return path

Submission

• Sanitized switch and firewall backups
• Completed test matrix
• Relevant route, ARP, session, log, and interface evidence
• Packet-walk explanation
• List of unresolved questions