Sixty Branch Areas, One Firewall, and a Memory Budget
A campus hub router R-HQ is the area 0 ABR for 60 branch areas, area 1 through area 60. Each branch has one SR OS access router with three /24 user LANs and a /30 link to R-HQ. The access routers are low-end boxes with about 64 MB of free memory, and each currently holds a type 3 LSA for every prefix in every other branch - roughly 180 summary LSAs and rising as branches are added. Fifty-nine branches have no external routing requirement at all. Branch 27 is different: a firewall in area 27 redistributes four static routes that must be visible to R-HQ and to every other branch, and its users must reach the internet through R-HQ. Change control wants the LSDB on each branch access router reduced to a default route plus local prefixes, without breaking branch 27's redistribution or its reachability to the rest of the network.
1. Which area type do you configure for the 59 plain branches, what gets blocked, and where does the default route come from?
Read the worked answer
Configure the 59 branch areas as stub, and if the requirement really is only a default plus local prefixes, as stub with summary suppression - the totally stubby variant. A stub area blocks type 5 and type 4 LSAs at the ABR boundary, so no external or ASBR-summary information is flooded in. The ABR then originates a default summary into the area, and the metric of that default is controlled by the default-metric value set on the area's stub configuration; without setting it the default advertises a metric that may not reflect the real distance to the exit. With type 3 also suppressed, the branch router's LSDB drops to its own type 1, any type 2 on a broadcast handoff, and the single default - the largest reduction available and exactly what change control asked for. Two constraints to state explicitly: every router in a stub area must be configured as stub, otherwise hellos are rejected and the adjacency fails outright; and a stub area cannot act as a transit area for a virtual link. Confirm the branches do not need per-prefix visibility for policy before accepting a default-only LSDB.
2. Design branch 27. Explain the LSA mechanics that make your choice work and the side effect on the other 59 branches.
Read the worked answer
Branch 27 needs an NSSA, not a stub and not a normal area. Inside the NSSA the ASBR - the router adjacent to the firewall - originates type 7 LSAs for the four statics, with the P-bit set to indicate that translation is allowed. The NSSA ABR at R-HQ translates those type 7s into type 5s and floods them into the backbone, so R-HQ and the rest of the domain see the four prefixes. On SR OS the translation and default behaviour are controlled by the NSSA options on the area, including type-7-to-5 translation (redistribute-external) and default origination; where two ABRs serve the NSSA, only the translator with the highest router ID translates unless the role is set explicitly. The NSSA still blocks type 5 from the rest of the domain, so branch 27 also needs a default route generated by the ABR to reach external destinations. Then state the side effect: the 59 stub branches will never carry the four external prefixes, because stubs reject type 5. Their users still reach those destinations through the default pointing at R-HQ, which is acceptable but must be documented as a design decision.
3. How do you summarize at R-HQ, and what are the limits of that summarization here?
Read the worked answer
Use area-range on R-HQ, one range per branch area, for example 10.27.0.0/16 covering that branch's three /24s. The range is configured on the ABR for the area that owns the components, and the ABR must hold at least one component prefix in its LSDB before the range is advertised; a range with no live component is simply not originated. The benefit is directional: it shrinks the type 3 count in area 0 and in every other branch's LSDB, not in the summarized branch itself, which already sees its own type 1s. Two limits matter here. First, area-range covers intra-area prefixes only. The four external routes from branch 27 are type 5 and are not summarized, so they remain individual LSAs across the domain - fine at four, unacceptable at five hundred. Second, if a branch is configured totally stubby it receives only the default anyway, so the range mainly benefits the backbone and any normal areas. Verify there is no overlap between ranges, since a more specific type 3 still wins in SPF.