A bank runs IS-IS with Level-1 access areas in each city and a Level-2 backbone, needing to limit Level-1 database size, advertise only a default plus summaries upward, and keep metrics comparable across old and new routers. Which IS-IS route leaking, summarization and metric design should the designer specify to meet scale and compatibility?

The correct design meets all stated goals because summarizing Level-1 prefixes at the Level-1-2 boundary keeps the backbone table small while preserving reachability, leaking only a default down lets city areas stay minimal without learning backbone detail, and wide metrics support large values needed for traffic engineering with transition support for mixed old and new routers. Retaining narrow metrics only fails on compatibility and scale because narrow metrics cap interface cost at 63 and path cost at 1023, so larger differentiated costs cannot be represented consistently across implementations. Leaking more-specific Level-2 routes down instead of only a default fails on scale because each specific enlarges the Level-1 database and SPF load, defeating the need to constrain city areas even though selective leaking is valid for exit control. Summarizing Level-2 prefixes into Level-1 reverses the hierarchy and fails on direction because it does not reduce Level-1 to Level-2 advertisement and leaves upward flooding unsummarized. For exams, remember summarization is configured on the propagating Level-1-2 router and default flows from Level-2 toward Level-1 through the attached bit or explicit policy, not automatically both ways. In practice verify database size, Level-2 summary entries, default presence in Level-1, and consistent metric style across neighbors before allowing exceptions.