Windows

Best practices for network interface naming conventions

For Windows Servers admins, it's extremely annoying when you cannot determine which interface is which based on network names. Rick Vanover presents strategies for network naming practices.

There is nothing more frustrating than logging into a Windows Server and seeing interfaces named Local Area Connection, Local Area Connection 2, and Local Area Connection 3 and not knowing which is which. Since Windows 2000 Server, we've been able to give names to interfaces. This has enabled us to do a few things, including using an icon to identify the Active Directory domain connection (only Windows 2008) within Group Policy and using clear names for interfaces. The best way to name a network interface is to make something that is self-documenting, repeatable, and easy to understand.

Figure A identifies a server with two interfaces: one on a production Ethernet network and another on an iSCSI storage network. Figure A

Click the image to enlarge.

This example is right out of my personal lab, which is a small environment; larger environments may have trouble using such simple names, but there are other network interface naming strategies.

Here is a simple approach that can work for almost any environment for operating system names: role, network, media, and node. So, let's take an example of an interface that is on a production network, addressed as VLAN 33 (10.0.33.0 network for example), used copper and is the first node. That example would be represented as PROD-33-COPPER-1. For this example, let's change it to be a virtual machine: PROD-33-VM-1. For a storage network, similar strategies can apply, such as: SAN-33-COPPER-1. Figure B shows how I can represent the two networks from Figure A a little more clearly. Figure B

Click the image to enlarge.

In these simple steps, the network interfaces are much more clearly named and intuitively laid out. Other strategies, such as denoting a crossover, cluster, 10 GB, or other configuration, can easily be rolled into the nomenclature standard that is used.

What strategies do you employ to name Windows server network interfaces? Let us know in the discussion.

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

8 comments
Ron_007
Ron_007

Having a "rational" naming convention makes sense. But on the other hand, I have heard arguments for the opposite. When the "bad guy" hacks into your system, he will thank you for those rational names pointing to production and other "jems" while he will say nasty things when he encounters non-logical names like "snoopy", "snow white", "grumpy" etc

alexandre.matos
alexandre.matos

netsh interface set interface name = "{old name here}" newname = "{newname here}"

Neon Samurai
Neon Samurai

Seeing multiple "Local Area network (#)" entries does suck rocks. For network devices, I've taken to this type of naming: what it is, how it connects, what number it is if needed LAN 802.3 0 LAN 802.3 1 LAN 802.11 PAN 802.15.1 VPN Cisco ... and so on My home machine has two wired NIC so "LAN 802.3" is the connection type and the "0" or "1" identifies the two NICs. "LAN 802.11" - it's a local area network connection and it's wireless in the popular .11 standard. PAN; personal area network device and it happens to be bluetooth "802.15.1" though "PAN BT" would work just as well. If one is using a Cisco gateway then "VPN Cisco"; using OpenVPN then maybe "VPN OpenVPN" or "VPN OVPN".. and so on. The unix way is also worth considering: eth0, eth1 - first and second ethernet adapter wlan0 - first wireless adapter, maybe a wlan1 if you have a second vpn0 This naming method may not hold up once you include other connections though as Bluetooth would seem to be "bt0" however, a "bt0" device is often used when binding virtual NICs into a physical NIC or similar odd network setups. The Unix way does make more sense to me when naming hard drives though. Instead of: (C:\) local drive (D:\) local drive (F:\) removable media Consider: (C:) sda1 -- mounted on letter C, SATA drive A, Partition 1 (D:) sda2 -- mounted on letter D, SATA drive A, Partition 2 (E:) hda1 -- maybe you have an old IDE driva A, Partition 1 mounted on letter E (F:) cdrw -- disk reader/writer with more human readable name if the icon isn't enough (F:) sr0 -- to match the Unix /dev/sr0 location if one prefers consistancy over the "cdrw" name (G:) fda1 -- mounted on letter G, Flash drive A, Partition 1 I can see how the article's naming convention could help when one machine connects to multiple dedicated hosts though such as eth0 for LAN and internet with eth1 dedicated to connecting with the SAN host. Not related to naming but related to network devices; Baud how I wish Windows did bonded network devices. I have two NICS connecting to the same LAN, under my Debian boot, the litterally apear as one; each handles half the network draffic, if one fails the other takes over the full trafic load. I've yet to find any way to do this under a WinXP or Win7 bootup though. Every server or consumer motherboard I've looked at in the last two years comes with two NICs onboard.. why can't I simply merget them into a bonded device? Is there a way to do this and I'm just missing it? (The closest I've come is Bridging at all the same unfortunately. I want two NICs as one not one NIC shared to the other's subnet.)

coloracer2003
coloracer2003

If the system is compromised, I agree that what you name it isnt going to matter very much to a hacker. At best, naming schemes that are for cartoon characters, etc...is only going to make the hacker chuckle a little. What's more, in an enterprise environment, the naming conventions that arent standardized (and cartoon characters most certainly arent) cannot scale properly. Security through obscurity is a poor practice to hang your hat on.

Neon Samurai
Neon Samurai

They already have control of your workstation and will simply be sniffing or scanning the network; probably not taking note of anything beyond the addressing details of the network device. Each must decide for themselves but I can't put any real value in obscuring the network device names to achieve any positive affects on security.

b4real
b4real

This in no way is a security practice.

Neon Samurai
Neon Samurai

"Since Network Adapter Teaming is only provided by Hardware Vendors," Wow.. Microsoft actually manages to claim that while keeping a strate face? Amazing.. Here's how the other half lives for comparison: http://www.howtoforge.com/nic-bonding-on-debian-lenny Install ifenslave, make two quick config file edits and restart your networking stack. All done in software which is why I've been so confused about not finding a way for Windows to do the same. When cleaning up the wiring at work in the server locker, it was very nice to be able to unplug one NIC at a time to replace the cables; no down time and the machine got two short wires for cleaner management and better air flow. Drat.. looks like my Win7 dualboot is going to continue showing the second NIC as disabled. Boooo! I was really hoping I was just missing how it's done rather than confirmation that it isn't capable of what should be simple. Cheers for the link though. That answers the question and saves me continuing to look for a solution.

Editor's Picks