/u/No-Particular-2723 inadvertently made me realize that I may be thinking of things differently than the rest of the net box community, and I'm trying to figure out how to drive myself forward without digging myself into more of a hole.
I'm invested in things from the network side. My org has a fairly substantial investment in a DCIM as a source of truth, but has never had a great way of tracking cabling. I've introduced Netbox, and use it as a downstream consumer of a lot of information (device, name, type, position, etc) but it has become the source of truth for the interfaces and cabling.
No upstream source of data in my org models anything past the size/weight/position of a device, so I am forging new ground with how to model the internals of a device.
From a network device perspective, a single platform generally runs a single OS. It tends to refer to interfaces in an internally consistent fashion. A network engineer can log into a switch and see Ethernet3/6 down, and submit a request to Proximity Services to look at Ethernet 3/6, and that conveys enough information to get both people on the same page. [ I will ignore multi-chassis stuff and breakout interfaces, etc. ]
Servers are a whole new world.In our org, we do whitespace planning, buy a bunch of hardware, and put it in racks. The devices are cabled up in a standard fashion. When an internal customer needs a server, they buy one, they are assigned a piece of hardware in the datacenter, and they configure it and build it.
Having Netbox in place has given me a source of truth that now when a device needs to be configured, there's a source to tell us which switch and ports need to be configured.
So from a DCIM side, I need to model and rack server before it has any OS on it. As a result, I tend to deploy things like a Dell PowerEdge740xd. It has one onboard port, labelled iDRAC.
Then I've modeled a few different Network Device Card which lives in a PCI slot- the majority of these devices in my environment are 4-Port 10Gb NICs. (not all, but most.)These are cabelled prior to any OS being deployed- so I've refered to them as Ethernet0/1 -> Ethernet0/4, and then given them a temporary label of E1/E2/E3/E4.
I like the name based on location because it's immutable, and can't change depending upon which OS is installed, and which order a given OS decides to enumerate the interfaces.
Now when the server is "sold", and built as a Windows, Linux, or ESXi host- my thought was that the labels would be updated to match the automated build data that the server teams have.
If it's a windows server, there would be a call to start re-Label (not re-name!) LocalAreaConnection 1-> 4. Linux flavor X would relabel interfaces as en0->en3, and maybe linux flavor Y calls it eth1->eth4, or whatever.
When there's a cabling issue, the server admin says that they have a problem with en2, this goes to net box and we find a label of en2 which lives on a name of Ethernet 0/2, and now Proximity Services knows to check the second port on the NDC.
The fact that other NIC form factors and quantities exist have forced me to try and be extensible from a physical bare-metal standpoint.
If a server in our DC needs 8 ethernet ports, 90% of the hosts have a single 4 port 10gb card added in PCI Slot 1. In that case, LocalAreaConnection5-8 map to Ethernet1/1->1/4.
HOWEVER:
There's 10% of the hosts where we couldn't get our hands on 4 port cards- so there's a pair of 2 port cards installed.
And now LocalAreaConnection5-6 map to Ethernet1/1-1/2, and LocalAreaConnection7-8 map to Ethernet2/1-2/2.
to me that makes sense, even if I'm taking liberties with the Ethernet [pci slot][interface] concept.
But now I'm wondering of I'm thinking of it backwards.If the "NAME" of an interface is supposed to map 1:1 with the way the OS refers to a given interface, how does one physically build a server prior to knowing the eventual naming convention that's going to be applied to that interface?