Operators place every municipal agency's tenant interfaces and routes into inet.0 on the leaves. Why does that undermine multitenancy?
Select an answer to reveal the explanation.
Short Explanation
inet.0 is the town square—great for underlay, terrible as everyone's tenant apartment. Dump all agencies there and overlapping addresses, shared reachability, and accidental leaks become the default lifestyle. Routing instances exist so tenants do not share that square.
Full Explanation
Operators who place every municipal agency's tenant interfaces and routes into inet.0 on the leaves undermine multitenancy because sharing the default table collapses tenant separation that routing instances would provide. One shared map book means overlapping prefixes, shared policy mistakes, and no clean civic isolation boundary between departments that policy says must stay apart.
inet.0 can hold more than one default route topic is a distractor about defaults, not a hard “only one default” law that explains the multitenancy failure. EVPN does not require tenant routes to exist only in iso.0. inet.0 is not reserved for multicast only and does not reject unicast tenant prefixes for that reason—the problem is architectural collapse of isolation, not a multicast reservation myth.
Exam caveat: “everything in inet.0” is almost always the anti-pattern when the stem values multitenancy.
Operational check: migrate tenants into dedicated routing instances, remove tenant IRBs from master where inappropriate, and show that inet.0 retains underlay/management concerns rather than agency overlays. After migration, ensure underlay loopbacks and IGP remain in the correct non-tenant context so fabric stability is unchanged.