Slicing a /21 and Surviving a 576-Byte Tunnel
An ISP hands a customer the address block 172.20.8.0/21 and requires it to be carved up for four VLANs and three router-to-router links. VLAN-A must seat 500 hosts, VLAN-B 250, VLAN-C 120, VLAN-D 60, and each of the three point-to-point links needs two usable addresses. Every allocation must be CIDR-aligned, subnets may not overlap, and the customer wants the largest possible contiguous free block left for future growth. Independently, a host in VLAN-A sends a 3,000-byte IP datagram (header included, 20 bytes) to an external server. The first hop is Ethernet with MTU 1500; further along the path sits a tunnel with MTU 576. Routers on the path never set DF, and one middlebox silently discards every fragment after the first fragment of a datagram. The network team must size the subnets, predict the on-the-wire fragments, and explain a user complaint that small pings succeed while large uploads stall.
1. Produce a valid VLSM plan: network address, prefix and usable range for each VLAN and each /30 link, plus the largest remaining free block. Justify why VLAN-A needs a /23 rather than a /24.
Read the worked answer
Size each subnet by rounding the host requirement up to 2^k - 2 usable addresses, then place it on a boundary of that size.
| Purpose | Needs | Block | Usable range |
|---|---|---|---|
| VLAN-A | 500 hosts | 172.20.8.0/23 | 172.20.8.1 – 172.20.9.254 |
| VLAN-B | 250 hosts | 172.20.10.0/24 | 172.20.10.1 – 172.20.10.254 |
| VLAN-C | 120 hosts | 172.20.11.0/25 | 172.20.11.1 – 172.20.11.126 |
| VLAN-D | 60 hosts | 172.20.11.128/26 | 172.20.11.129 – 172.20.11.190 |
| Link 1 | 2 | 172.20.11.192/30 | .193 – .194 |
| Link 2 | 2 | 172.20.11.196/30 | .197 – .198 |
| Link 3 | 2 | 172.20.11.200/30 | .201 – .202 |
A /24 offers only 254 usable addresses (256 minus network and broadcast), which is below 500, so VLAN-A must be a /23 - and because a /23 must start on an even third octet, 172.20.8.0 is the only valid placement inside the block. Ordering largest-first is what makes the plan fit without gaps.
Remaining space: 172.20.11.203 – 172.20.15.255. The largest aligned CIDR block inside it is 172.20.12.0/22 (172.20.12.0 – 172.20.15.255, 1024 addresses); the leftover sliver 172.20.11.203–11.255 is fragmented and only usable as small units.
2. Give the exact fragment list the datagram produces at the 1500-byte first hop and, after re-fragmentation, at the 576-byte tunnel. Include total length, data length, fragment offset and MF for each fragment.
Read the worked answer
Data to carry = 3000 - 20 = 2980 bytes. Offsets are counted in 8-byte units, so each fragment's data length except the last must be a multiple of 8.
At MTU 1500: payload per fragment = 1480.
| # | Total length | Data | Offset | MF |
|---|---|---|---|---|
| 1 | 1500 | 1480 | 0 | 1 |
| 2 | 1500 | 1480 | 185 | 1 |
| 3 | 40 | 20 | 370 | 0 |
At MTU 576: payload = 556, rounded down to the multiple of 8, 552. Then 5 x 552 = 2760, leaving 220.
| # | Total length | Data | Offset | MF |
|---|---|---|---|---|
| 1 | 572 | 552 | 0 | 1 |
| 2 | 572 | 552 | 69 | 1 |
| 3 | 572 | 552 | 138 | 1 |
| 4 | 572 | 552 | 207 | 1 |
| 5 | 572 | 552 | 276 | 1 |
| 6 | 240 | 220 | 345 | 0 |
Checks: 552 is 69 x 8, so offset 69 follows one 552-byte fragment; 345 x 8 = 2760 matches five full fragments; 2760 + 220 = 2980. The result is identical whether you fragment the original datagram once or re-fragment each 1500-byte piece at the tunnel, which is why the receiving host sees the same reassembled datagram; only the DF flag would suppress this, and the path does not set it.
3. The user reports that pings of default size succeed while a large upload hangs after connecting. Explain the symptom in terms of the fragments above and the middlebox behaviour, and propose fixes with their limits.
Read the worked answer
A default ping carries 56 bytes of data, roughly 84 bytes on the wire - one unfragmented datagram. It passes the middlebox untouched. The upload's large segments must be fragmented, and the middlebox drops every fragment after the first, so the receiver holds fragment 1 and waits forever for offsets 69, 138, 207, 276 and 345. The reassembly timer expires, the datagram is discarded, retransmission reproduces the same loss, and TCP eventually stalls after the handshake (which uses tiny segments) has succeeded. That is exactly the "small works, large hangs" signature.
Fixes, in order of robustness:
- MSS clamping at the tunnel ingress - rewrite the TCP MSS option to 576 - 40 = 536 bytes so TCP never emits a segment that needs IP fragmentation. This works for TCP only; large UDP/DNS responses still fragment.
- Repair the middlebox so it forwards all fragments, or replace it. Fragment-hostile filtering is the actual defect; the rest are workarounds.
- Enable path MTU discovery properly - set DF and allow ICMP "fragmentation needed" (type 3 code 4) back to the sender, which is what lets the sender learn 576 without guessing.
Raising the tunnel MTU above 1500 is the cleanest fix if the transport permits it; if not, clamping is the pragmatic one, at the cost of ~11% header overhead per 536-byte segment.