I85PREP
⌘ K
GCE A/L Information & Communication Technology study materials
GCE A/L Information & Communication Technology study resources

VLSM Redesign and One-Way Reachability in a Three-Storey Garment Factory

GCE A/L Information & Communication Technology · Put your knowledge to work in context.

All case studies

VLSM Redesign and One-Way Reachability in a Three-Storey Garment Factory

Kandy Garments runs a three-storey factory in Katunayake with 124 networked devices on one flat IPv4 network, 192.168.20.0/24, all in a single broadcast domain. Device counts are: Design 58, Accounts 26, Production 26, HR 12, and the server room 2 (one file server and one domain controller). Three symptoms worry management. File sharing between two Design workstations saturates the whole network and interrupts the Production barcode scanners. A laptop in HR occasionally self-assigns 169.254.31.7 and then cannot reach anything. After the network engineer created VLAN 30 for a new Quality section, a VLAN 30 PC can ping its own default gateway but cannot reach the file server, although the file server can ping the VLAN 30 PC successfully. Management wants each department isolated in its own subnet, DHCP to keep working for every department, the existing 192.168.20.0/24 block retained, and room left for the new Quality section to grow.

1. Produce a VLSM plan for 192.168.20.0/24 that satisfies all five existing groups plus spare space. Give the block, mask, usable range and broadcast address for each, state the allocation order and justify it, and say how much space remains.

Read the worked answer

Allocate largest requirement first; this keeps the blocks contiguous and prevents a small block from fragmenting the address space.

Group Hosts needed Block Mask Usable range Broadcast
Design 58 192.168.20.0/26 255.255.255.192 .1 – .62 .63
Accounts 26 192.168.20.64/27 255.255.255.224 .65 – .94 .95
Production 26 192.168.20.96/27 255.255.255.224 .97 – .126 .127
HR 12 192.168.20.128/28 255.255.255.240 .129 – .142 .143
Servers 2 192.168.20.144/29 255.255.255.248 .145 – .150 .151

Reasoning: a /26 gives 2^6 − 2 = 62 usable addresses, the smallest power-of-two block that covers 58; a /27 gives 30, covering 26; a /28 gives 14, covering 12; a /29 gives 6, covering 2 (the four extra addresses absorb the domain controller plus a spare for a second server or a switch management address).

Assigned: 64 + 32 + 32 + 16 + 8 = 152 addresses. Remaining: 192.168.20.152 – 192.168.20.255, i.e. 104 addresses, ample for VLAN 30 and future growth.

Two caveats worth stating: Design has only 4 spare addresses, so the next four new designers force a renumber - if growth is expected, give Design a /25 and compress elsewhere. Also, the server block should not be the smallest by accident of ordering; it is small here because it genuinely holds two hosts, but leave it capable of holding a backup domain controller.

2. Diagnose the 169.254.31.7 address. What does it tell you and what does it not tell you, and what would you check, in order, to find the cause?

Read the worked answer

169.254.0.0/16 is the link-local (APIPA) range that Windows assigns when its DHCPDISCOVER receives no DHCPOFFER after several attempts. So the immediate conclusion is narrow and precise: the client obtained no lease. That is all it proves.

What it does not prove: the cable is fine, the switch port is up and the client is in the correct VLAN. Those would all be true if DHCP is simply unreachable. A host with APIPA can still ping another APIPA host on the same segment, which is a useful test to separate 'no link' from 'no DHCP'.

Why it is intermittent matters: only one laptop, occasionally. That pattern points to lease exhaustion or a transient, not to a permanently mis-trunked port.

Check in this order:

  1. Switch port VLAN membership - is the HR port actually in the HR VLAN, or was it left in VLAN 1 during a patch-panel change?
  2. DHCP relay - if the DHCP server sits in the server VLAN, the HR SVI needs ip helper-address pointing at it; without it, DISCOVERs never leave the subnet.
  3. Scope state - is the HR scope large enough (a /28 has 14 addresses for 12 devices, leaving only 2 free, so a couple of visitors' phones exhaust it), and are leases being released on shutdown?
  4. Rogue DHCP - a consumer router plugged into a wall port, or a server team member running a DHCP role; check for duplicate offers.
  5. Server service health and the DHCP audit log for that MAC address.

The fix usually follows from the answer: enlarge the HR scope or shorten lease time, add the relay, correct the port VLAN. Note that moving to per-department subnets itself creates the relay requirement - a common regression after a VLAN project.

3. Explain the one-way reachability between the VLAN 30 PC and the file server. Give the most likely causes ranked, and describe a step-by-step test sequence that isolates the fault.

Read the worked answer

The key evidence is directionality. The server can reach the PC, so a complete L2/L3 path from the server VLAN to VLAN 30 exists (ARP resolves, routing works, no segment down). The forward direction PC → server fails. A fault in cabling, VLAN trunking or routing would normally break both directions, so the cause is almost certainly a filter or an asymmetric path in the PC-to-server direction.

Ranked causes:

  1. Stateful host firewall on the file server blocking inbound ICMP/echo requests while permitting the server's own outbound echo requests (their replies are allowed by the firewall's state table). This fits the evidence exactly and is by far the most common cause of 'I can ping you but you cannot ping me'.
  2. An ACL on the VLAN 30 SVI or on the inter-VLAN router permitting only certain source/destination pairs - e.g. an ACL written for the Quality PCs' intended application ports, with no ICMP rule.
  3. Asymmetric routing: if a second L3 device advertises the VLAN 30 subnet, the server's return traffic may take a different path that has no route back, giving one-way delivery at the packet level even though a ping initiated by the server succeeds.

Test sequence - change one variable at a time:

  1. From the PC: ping its own gateway (already works), then ping another host in the same VLAN, then ping the domain controller (a second host in the server subnet). If the DC responds but the file server does not, the network is fine and the server is the suspect.
  2. From the PC: tracert the file server, and check the ARP entry for the gateway. A traceroute that completes to the last hop confirms routing is intact.
  3. Temporarily disable the server's host firewall for one ping, or add an explicit allow rule - if pings then succeed, close the case and write the rule properly.
  4. Check ACL hit counters on the SVI in both directions; a growing deny counter on the VLAN 30 interface identifies the ACL.
  5. On the server, run netstat -rn and compare the default gateway with the L3 device that owns the server VLAN, to rule out the asymmetric second path.

Only after these should you consider re-trunking or re-cabling, since the reverse ping already proved those are working.