<div dir="ltr"><div><div><div>Don't just think about your naming scheme. Consider how it aligns with, and can support, your business processes. Keep it as simple as possible, but no simpler. Ideally a  traceroute would be sufficient for help desk to escalate to the right team.<br><br>Use semantically meaningful names, where possible, that match function, rather than simply mapping the name from the IP space (which has been suggested). If you do this, your traceroutes don't add anything you won't see with traceroute -n.<br><br>Do you want separation of naming schemes, and shared management, for network vs servers? If there's separate teams for network and servers, the answer probably is yes. Best practice would be where IP and name allocation are the one process, with PTR records autogenerated. You can do things with SNMP to further reduce manual process.<br><br></div><div>Map infrastructure to physical locations. But services, no. A VM that moves between DCs can be misleading if it's migrated from the DC where it's resident, while its DNS claims it's still in the primary DC.<br></div><div><br></div>Plan for future growth. The name that's meaningful today, might not make sense in 5 years time. For instance, don't include hardware names (eg. N7K-1). When the hardware changes on upgrade, there will be confusion. Better something that reflects function (eg. pce - for primary CE). Also, just because your naming convention produces a canonical name today that is unique, doesn't mean you won't have name collisions after the environment scales up.<br></div><br></div>Paul Wilkins<br></div>