OSPF NSSA Redistribution and Translator Election
A service provider runs OSPFv2 in areas 0, 10, and 20. Area 10 is an NSSA with two ASBRs, R10-1 and R10-2, both redistributing the same summarized BGP prefix 198.51.100.0/24. R10-1 sits on a 50 Mbps backup circuit; R10-2 has a 1 Gbps primary circuit. Both use redistribute bgp 65000 subnets metric-type 2 metric 20. Area 0 receives two Type-5 LSAs for the prefix, and traffic from area 0 splits evenly across the two ASBRs, saturating the backup link. Area 10 also has a Type-7 translator election, and after a recent R10-2 reload, some external prefixes intermittently disappear from area 0 for 30-40 seconds. The NSSA ABR is R10-3. The design must keep area 10 stub-like, preserve redundancy, and avoid relying on static routes.
1. Why is traffic using the 50 Mbps link, and what OSPF design change would make R10-2 the deterministic primary without breaking NSSA redundancy?
Read the worked answer
Both ASBRs originate the same prefix as an OSPF external Type 2 with metric 20. Type 2 external cost is independent of the internal OSPF cost to reach the ASBR, so area 0 sees two equal-cost E2 routes and CEF load-shares across R10-1 and R10-2. The 50 Mbps circuit is saturated because OSPF has no bandwidth awareness. To steer deterministically, change the external metric calculation: use metric-type 1 and set a lower seed metric on R10-2, for example 10, and a higher seed on R10-1, for example 100, with a route-map on redistribution. With E1, the total cost is seed metric plus internal cost to the ASBR, so the primary remains preferred unless its internal cost grows beyond the difference. Alternatively keep E2 but set different external metrics, though E2 still ignores internal cost and can create a worse path if the topology changes. Verify with show ip ospf database external and show ip route 198.51.100.0. Do not rely on equal-cost load sharing for a 20:1 bandwidth mismatch.
2. What is causing the 30-40 second intermittent withdrawals, and how should the NSSA translator design be corrected?
Read the worked answer
In an NSSA, Type-7 LSAs from the ASBRs must be translated to Type-5 by an ABR. Only the elected translator normally does this; after R10-2 reloads, the translator role moves between R10-3 and another ABR, and the Type-5 LSAs can be withdrawn and re-originated while SPF and translation settle. Intermittent 30-40 second loss is consistent with that process, especially if the Type-7 forwarding address is not reachable from area 0 or the P-bit is not set consistently. Check show ip ospf database nssa, show ip ospf, and the Type-7 forwarding address. Make the translator behavior deterministic by configuring area 10 nssa translate type7 always on both NSSA ABRs, or at least on the redundant ABR, ensuring a stable reachable loopback is used as the forwarding address, and matching NSSA settings on both ABRs. Also confirm that both ASBRs set the P-bit for redistributed routes and that no area 0 filter blocks the translated Type-5.