Across dozens of municipal leaves, tenant routing-instance names and IDs drift (vrf-parks vs Parks_VRF vs tnt3). Why does consistent naming matter for multitenancy?
Select an answer to reveal the explanation.
Short Explanation
If Parks is vrf-parks on one leaf and tnt3 on another, humans will attach the wrong VLAN at 2 a.m. Consistent names are seat belts for multitenancy—boring, mandatory, and cheaper than an outage postmortem. Hyphens are fine; chaos is not.
Full Explanation
Across dozens of municipal leaves, drifting tenant routing-instance names and IDs (vrf-parks versus Parks_VRF versus tnt3) undermine multitenancy because consistent instance naming and IDs across leaves keep isolation operable and reduce mis-attachment risk. Automation playbooks, audit scripts, and human operators all attach VLANs and IRBs to the wrong civic tenant when synonyms proliferate for the same agency. Junos does not reject every instance name that contains a hyphen, so that myth is not the reason to standardize nomenclature. EVPN does not require instance names to match interface descriptions character-for-character as a protocol rule. Preferring unique names per leaf so BGP can supposedly load-balance tenants is backwards: inconsistent naming increases configuration error rather than improving ECMP. Exam caveat: treat routing-instance nomenclature as an isolation control surface and standardize it fabric-wide for every municipal agency. Operational check: publish a city naming standard such as vrf-<agency>, inventory drifts on all leaves, align names and IDs during a maintenance window with careful cutovers, and add CI checks that reject commits introducing unknown tenant instance names.