I85PREP
⌘ K
BSF HC RO/RM study materials
BSF HC RO/RM study resources

Three Simultaneous Faults on a Flat Battalion HQ LAN

BSF HC RO/RM · Put your knowledge to work in context.

All case studies

Three Simultaneous Faults on a Flat Battalion HQ LAN

The battalion headquarters data network runs on one flat subnet, 10.20.30.0/24, with the router at 10.20.30.1, the DNS and file server at 10.20.30.5, and a DHCP server issuing addresses 10.20.30.100 to 10.20.30.199 on eight-day leases. Addresses below .100 are statically assigned to printers, switches and servers. In one month the strength has grown from 74 to 118 networked devices after new data terminals and IP cameras were installed. This week clerks report three faults. First, newly installed terminals configure themselves with 169.254.x.x addresses and cannot print. Second, on terminals that do work, the share \10.20.30.5\orders opens when typed by address but fails when typed as \hq-srv\orders. Third, the entire network stalls for 30 to 90 seconds several times an hour, the core switch CPU touches 100 per cent, and its MAC address table shows one MAC address alternating between two different ports. Two unmanaged eight-port switches were recently added at the quartermaster's store and the MT shed; one of them has both uplinks patched into wall sockets.

1. Diagnose the 169.254.x.x addresses, show the arithmetic that supports your diagnosis, and set out two remedies with their trade-offs.

Read the worked answer

A 169.254 address is an APIPA address: the client broadcast for a DHCP offer, received none, and self-assigned. The question is why no offer came. Answer the arithmetic first: the pool .100 to .199 contains 199 - 100 + 1 = 100 addresses, but there are now 118 devices. At least 18 devices cannot get a lease. Eight-day leases make it worse, because addresses belonging to machines that have moved or been switched off stay reserved for up to a week. The count matches the symptom exactly, so scope exhaustion, not a cabling or VLAN fault, is the primary cause.

Remedy A - widen the pool in the same subnet. Move statics down to .1 to .19 and issue .20 to .250, giving 231 addresses. Cost: a change on the DHCP server and a check that no static device sits inside the new range. Fast, no downtime, but it leaves the /24 with only about 250 usable addresses - under two years of growth at this rate.

Remedy B - move to 10.20.30.0/23. Mask 255.255.254.0 gives 510 usable addresses across 10.20.30.0 to 10.20.31.255. Cost: mask change on the router, both servers, every static printer and switch, and the DHCP scope; needs a maintenance window.

Recommend A today to clear the fault, and B in the next planned outage. Either way, verify with ipconfig /release and /renew on a failed terminal and check the DHCP console for an exhausted-scope warning before declaring it closed.

2. Explain the second fault - the share opening by IP but not by name - and state the exact checks you would run and the fix.

Read the worked answer

The IP address reaches the server, so routing, the physical link and the share permissions are all sound. What fails is name resolution: the client cannot turn the short name hq-srv into 10.20.30.5.

Checks, in order:

  1. ipconfig /all on a working but affected terminal - is a DNS server listed at all, and is the DNS suffix set? A terminal that received an APIPA address has no DNS server at all, so the two faults overlap.
  2. nslookup hq-srv 10.20.30.5 - a 'non-existent domain' reply proves the server is reachable but holds no record for that name, which is a server-side fault, not a client fault.
  3. On the DNS console, check the forward lookup zone for the A record for hq-srv, and check whether the zone is AD-integrated and the record was deleted or never created.
  4. Check DHCP scope option 006 (DNS servers) and option 015 (DNS suffix) so that every future lease carries the right settings.

Fix: create or repair the A record for hq-srv pointing to 10.20.30.5, set scope options 006 and 015, then on a client run ipconfig /flushdns and retest with ping hq-srv and nslookup hq-srv. Teaching clerks to use the fully qualified name hq-srv. is a workaround, not a fix; the record must exist.

3. Explain the third fault and give the corrective action, including what you would do about the immediate outage risk.

Read the worked answer

The three symptoms together are diagnostic of a Layer-2 switching loop with a broadcast storm. A frame with an unknown destination is flooded out of every port; with two paths between the same pair of switches it circulates forever, is replicated each lap, and saturates every link. The MAC address table shows one address alternating between two ports because the same source is being learned from both directions - MAC flapping, the classic signature. The core switch CPU hits 100 per cent because it is spending all its cycles on broadcast and on relearning the table, so legitimate traffic stalls for as long as the storm lasts. The unmanaged switch with both uplinks patched into wall sockets has created exactly this loop, and being unmanaged it runs no spanning tree.

Corrective action:

  1. Locate the store switch and remove one of the two uplinks. Do it in a short announced window - the network is already stalling, so a deliberate 30-second break is cheaper than an unplanned one.
  2. Replace the unmanaged units with managed switches and enable RSTP on all inter-switch links.
  3. On access ports to terminals, set portfast together with BPDU guard, so that a mispatched wall socket errs into shutdown instead of forming a loop.
  4. Enable storm-control on access ports as a backstop.
  5. Record the incident, and add a rule that no unmanaged switch is added to the HQ LAN without the signals section's clearance.