← All challenges
easyaddressing~35 min

Carve up a /24 with VLSM, efficiently

One /24, four segments with different host counts. Design a non-overlapping VLSM plan with no waste, apply it, and prove every segment reaches every other.

Scenario

You have one block, 192.168.50.0/24, and four segments to address:

  • Sales: needs 50 hosts
  • Engineering: needs 25 hosts
  • Ops: needs 10 hosts
  • Router-to-router link: needs 2 usable addresses

Design a VLSM plan that fits all four into the /24 with no overlap and no waste: each subnet sized to the smallest prefix that works. Apply it, and prove every segment can reach every other.

Topology

  • R1 hosts the Sales and Engineering segments and links to R2.
  • R2 hosts the Ops segment.
  • One host sits on each segment. The interfaces and hosts start unaddressed: the addressing is yours to design and apply.

Your job

Produce the VLSM plan (largest segment first), apply it to the router interfaces and the hosts, add whatever routing is needed so all three segments reach each other, and show it works.

What "done" looks like

A clean, non-overlapping plan from 192.168.50.0/24 with the smallest prefix per segment, applied, with full reachability between segments.

Teaches: VLSM, prefix sizing, and why "biggest subnet first" matters: assign the largest blocks before the space gets fragmented.

What gets checked

Your solution is verified against each of these:

  • Each segment uses the smallest prefix that fits its host requirement
  • No two subnets overlap; all come from 192.168.50.0/24
  • A host on each segment can reach a host on every other segment

Solve it in the browser lab

No setup, no install. Open a live lab: configure each device in the editor or its Cisco IOS terminal, run show/ping/traceroute (or test from the hosts), and watch the network react. The in-house engine grades your fix instantly and issues your proof the moment every check passes.

Open the lab →

Prefer your own lab?

  1. Build the fix locally. New to the tooling? See setting up your lab.
  2. Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
  3. Submit the repo link. We review it by hand, confirm it works, and issue your proof page.
Submit your solution →