Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there a way to name a VLAN interface arbitrarily like eth72 or ext19 instead of the four standard nameing schemes eth0.72, vlan19 (and the padded variations)?

Don't have no clue. Perhaps udev?

share|improve this question
Sure, udev can do that. – Skaperen Sep 5 '12 at 16:11
@boburob: I have three "upstream" nets - one comes in physically and two via VLANs on another Link. For sake of clarity I want to rename them all to ext0, ext1 and ext2. – Michuelnik Sep 5 '12 at 16:43
This is very likely to confuse anybody who ever has to touch that box in the future. We are professionals here and we assume you are too. Don't confuse your colleagues. – Michael Hampton Sep 5 '12 at 19:14
@MichaelHampton: Actual, this wish came from my colleagues - where I have been denying their request. – Michuelnik Sep 5 '12 at 19:31
@ChrisS I have been stunned, too. But there is an easy way to do this - simply ip link set name... – Michuelnik Sep 27 '12 at 8:04
up vote 7 down vote accepted

OMG - it's that easy:

Rename vlan 42 on eth0 to ext2:

ip link set dev eth0.42 name ext2

share|improve this answer

In OpenBSD (and presumably other BSDs) you can set a description of an interface with ifconfig using the aptly named description argument, see ifconfig(8). This is very handy for distinguishing between a bunch of interfaces. But that doesn't help you.

Unfortunately there's no great way to do this in Linux.

In Linux, interfaces are named dynamically with each interface being assigned the first available name. This means that if you pull a NIC and then add another one (say to replace it or upgrade it) there is no guarantee that its interface will remain the same.

Try a program like ifrename which will allow you to manually specify the interface names. It looks primarily designed to assure that NIC0 is always associated with eth0 but I believe you can use it assign names like external and dmz to interfaces instead of eth0 and so on. Udev will also allow you to change interface names using the network.rules file (see here for an examples).

You should be careful to document this as it is not typically done but unlike @MichealHampton I don't see any particular problem with it. I personally make great use of the description field for interfaces in my BSD installs.

share|improve this answer
On all BSDs: -description actually takes the description off an interface, description or descr followed by the quoted text puts it on an interface. Also, you can easily rename interfaces with the name command to ifconfig. – Chris S Sep 5 '12 at 23:29
@ChrisS: Ahh thanks! Edited my answer for correctness. – kce Sep 6 '12 at 1:04
Unfortunately ifrename won't work here (I guess!) since it's using the MAC addr to distinguish interfaces and the VLAN-IFs of an ethernet inherit it's MAC.... Same applies to udev if only the MAC can be used as distinguisher. Maybe the full device path? – Michuelnik Sep 6 '12 at 6:51
To your pull-replace-nic-part: atm it's mostly guarenteed, that the interface will NOT remain the same since $most dists are using mac-based dynamically learned fixed interface names. (-> 70-persistent-net.rules) Understood udev so far, but cant get the step to VLAN interfaces there.... – Michuelnik Sep 6 '12 at 6:59

I didn't have luck with "ip link set dev bond0.10 name ext0". If the interface is up, it gets a BUSY error. If the interface is down, it gets a NOT FOUND error.

What I did have luck with is this: in my base interface definition for bond0,

post-up ip link add name ext0 link bond0 type vlan id 10
pre-down ip link delete dev ext0 type vlan


auto ext0
iface ext0 inet static
    address ...

Now I find that "ifup bond0" not only creates the VLAN as seen in /proc/net/vlan/config and creates the ext0 device, but it even ifup's the ext0 device. bond0.10 never comes into existence.

share|improve this answer

In debian you use /etc/network/interfaces to configure your network interfaces.

Be aware that you should install the vlan package:

apt-get install vlan

From man 5 interfaces:

To ease the configuration of VLAN interfaces, interfaces having . (full stop character) in the name are configured as 802.1q tagged virtual LAN interface.

For example, interface eth0.1 is a virtual interface having eth0 as physical link, with VLAN ID 1.

For more information check man 5 vlan-interfaces. Basically, you can give your vlan interface any name, and use vlan-raw-device to associate the vlan with your NIC. For instance, vlan10 on eth0 would be:

iface vlan10 inet static
    vlan-raw-device eth0

On non-debian distros, you can do this same thing with iproute2 as follows:

ip link add link enp3s0f1 name vlan10 type vlan id 10
ip addr add dev vlan10
share|improve this answer

Not sure if this also applies to Debian, but in Ubuntu (and Red Hat), this is easily done by editing /etc/udev/rules.d/persistent-net.rules (or similar; I'm not in a position to check)

Renaming interfaces has some useful advantages:

  • assigns known semantics to an interface (eg. 'management0', 'front0', 'back0')
  • having a predictable name makes it easier for configuration management scripts etc to work well (esp. Firewall rules)

You do need to make sure that your team knows to expect this. That's not a problem, it's generally very welcome, particularly when you have many interfaces in a system (eth8 is not unreasonable in an host with redundant bonded links to SAN storage)

Having discussed this recently, if you wanted to rename based on VLAN ID, I would suggest that you consider the following:

  • VLAN IDs are not all that memorable and easily mistyped and looked over.
  • a host generally has no simple way to determine which VLAN (if any) it is on, or it if is the native VLAN, and an access or trunk port (doing this manually from the host is sometimes doable if you tcpdump for CDP messages or know what traffic maps to which VLAN). Thus, the configuration is one based on belief, which can easily become invalid.
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.