College Campus: Alternating Traceroute and 169.254 Addresses
A degree college in Guwahati runs its campus network with an edge router R1, a core router R2 and a Layer-3 switch S1. S1 hosts VLAN 10 (staff, 10.10.10.0/24, gateway 10.10.10.1) and VLAN 20 (students, 10.10.20.0/24, gateway 10.10.20.1). R1 has two exits to the internet: a 100 Mbit/s fibre link to ISP-A and a licensed radio link to ISP-B that is sold as 100 Mbit/s but in practice sustains about 18 Mbit/s. The radio interface on R1 is configured with the command bandwidth 100000, matching the licensed figure. The college's examination application server at 172.16.5.10 is hosted at another campus and is reachable only through ISP-A. For the past week staff complain that sessions to 172.16.5.10 freeze and reset every two to four minutes, and a traceroute run repeatedly alternates between the two ISPs. Separately, students have started receiving 169.254.x.x addresses since the old DHCP server was retired and a new one at 10.10.10.20 was commissioned on VLAN 10.
1. Explain why the traceroute alternates and why sessions to 172.16.5.10 reset. Give the configuration change that fixes it, with the exact value you would set.
Read the worked answer
Why it alternates: R1 holds two default routes of equal administrative distance, one per ISP, and the router is doing per-destination (ECMP) load sharing. Nothing in the topology distinguishes the two exits for a given destination, so successive probes - and successive flows - are hashed across both.
Why sessions reset: the hash sometimes places the flow to 172.16.5.10 on the radio exit. That link carries only about 18 Mbit/s while the interface claims 100 Mbit/s; under load its queues overflow, packets are dropped mid-session, and TCP resets or stalls. The fibre path to the same server is clean, which is exactly why the fault looks intermittent rather than total.
The interface bandwidth clue matters twice. OSPF cost = reference bandwidth ÷ interface bandwidth. With the default 100 Mbit/s reference, the radio at bandwidth 100000 is given cost 1, identical to the fibre - the routing protocol is being told a lie about the link.
Fix:
- Correct the radio interface:
bandwidth 20000, giving OSPF cost 5 instead of 1, so any internal traffic prefers the fibre. - For the external decision, make it deterministic: either set the ISP-B default route to a floating static (administrative distance 250) so it is used only when ISP-A fails, or apply policy-based routing so 172.16.5.0/24 always exits via ISP-A.
Then verify with a traceroute repeated 10 times and confirm no path through ISP-B appears for that prefix.
2. Students are receiving 169.254.x.x addresses. State the cause and the two configuration points you would check first.
Read the worked answer
Cause: 169.254.x.x is the link-local self-assigned range (APIPA) that a host falls back to when its DHCPDISCOVER gets no reply. The DHCP server now sits on VLAN 10; a DHCPDISCOVER from a student PC is a broadcast and is confined to the VLAN 20 broadcast domain. The Layer-3 switch does not forward broadcasts between SVIs, so the request never reaches 10.10.10.20. Nothing is broken on the server - it simply never hears the request.
Configuration points to check:
- On the S1 VLAN 20 interface (10.10.20.1):
ip helper-address 10.10.10.20. This converts the broadcast into a unicast to the server. Without it, relay cannot happen. - On the DHCP server: a scope for 10.10.20.0/24 with the correct router option (10.10.20.1) and an address range that excludes the SVI and any statically addressed devices. Also confirm the VLAN 20 SVI is up/up, that VLAN 20 is allowed on the trunks to the access switches, and that access ports are actually in VLAN 20.
Verification: renew a client and confirm it receives a 10.10.20.x lease with the right gateway, then ping across VLANs and to the internet to confirm the relay path and return route.
3. After the routing fix, staff still report occasional resets on large file transfers to 172.16.5.10, while pings stay clean all day. Give two plausible causes and how you would confirm each.
Read the worked answer
Pings passing while bulk transfers fail points to something size- or state-dependent rather than a flat outage.
Cause 1 - MTU / path MTU discovery failure. One of the exits (or a tunnel or PPPoE session on it) carries a smaller MTU than 1500, and ICMP fragmentation-needed messages are being filtered. Small echo packets pass; full-size TCP segments are silently dropped, transfers stall and eventually reset.
Confirmation: ping the server with the DF bit set and a payload stepped up from 1400 to 1472 bytes; note the size at which it starts failing. Compare the interface MTU on both exits and look for a tunnel or PPPoE layer. A packet capture showing repeated retransmissions of full-size segments confirms it.
Fix: clamp MSS on the affected path, for example ip tcp adjust-mss 1360 on the tunnel or WAN interface, and stop blocking the relevant ICMP type.
Cause 2 - asymmetric routing combined with stateful NAT. The outbound flow leaves via ISP-A but a prefix or default is learned back through ISP-B, so return packets arrive on an interface where no NAT or firewall state exists and are dropped. Small request/response exchanges sometimes survive; long transfers do not.
Confirmation: traceroute to the server from both ends, and check show ip nat translations and interface counters for drops on the unexpected ingress path during a failing transfer.
Fix: make the exit deterministic for 172.16.5.0/24 in both directions, or apply consistent NAT/firewall policy on both exits.