I've seen examples of the ip link command where some are shown as

ip link add dev xxx type devtype 

and sometimes its of the form

ip link add link xxx type devtype

I looked at the documentation and still am confused about the difference between the two. Is there a difference, and if so when would you use one vs the other.

  • 1
    It's confusing, I hand you that. First, an observation: The top of the man page puts [ link DEVICE ] in brackets. The way I understand it: Some device types, e.g. VXLAN, have a dev parameter, so that the link parameter becomes redundant and can be left out. Others, e.g. VLAN, don't have a device parameter and need the link. – berndbausch Apr 17 at 1:31

The confusion is caused by abbreviations in the syntax. If you stick to full syntax there will be no confusion.

  • optional dev (and name) keywords

    The complete syntax of an usual command (not requiring link) is:

    ip link add name foo type bar ...

    Now name is optional, and in many contexts (not all, see example below) is interchangeable with dev. Once the interface is created, it can be set with:

    ip link set dev foo ...

    Again here dev is optional. name or dev are needed only when the following parameter would be taken itself as a keyword. So you can create an interface with the name dev:

    ip link add name dev type dummy

    And rename it into up (here dev and name have not the same role):

    ip link set dev dev name up

    But better avoid such strange choices:

    ip link set dev up name foo

    When there's no syntax ambiguity some keyword(s) can be omitted. Here dev can be omitted because the interface name isn't clashing with a keyword:

    ip link set foo up

    So in most cases, you don't see dev or name in commands handling interfaces. As you can understand, a script manipulating arbitrary interface names should never omit these keywords or suffer unexpected failures.

    Actually, even naming the device is optional. If you don't name a device at creation, it usually adopts a default naming convention that depends on the type, and which is often type+number with number being the next available number. For example:

    ip link add type bridge

    will create a bridge interface named bridge0 unless bridge0 already exists, in such case it will choose bridge1 or bridge2 etc.

  • With the link keyword

    For interfaces that have a relation with an other interface when created, there's the additional keyword link to designate such interface: this happens for VLAN, macvlan ... interfaces. So to create this interface, an other interface must be provided in addition to the chosen name of the new interface:

    ip link add link foo name bar type vlan id 10

    Again name can be replaced with dev:

    ip link add link foo dev bar2 type vlan id 20

    And both can be omitted because there's no ambuiguity with the syntax with the current names in use:

    ip link add link foo mvlan0 type macvlan mode bridge

    As seen before, if you don't even care to name the created interface, the system will choose a name itself:

    ip link add link foo type macvlan

    will create a macvlan interface linked to the parent foo interface and name it macvlan0 or if such name already existed macvlan1 etc.

In the end it's quite different to use:

  ip link add link foo type macvlan

where system gets to choose the name of an interface linked with foo

rather than:

  ip link add dev foo type bridge

where you create an interface named foo. The type matters and is not interchangeable here, but for example:

  ip link add link foo type bridge

will also work, but ignore the unneeded parameters link foo and will create a bridge interface named for example bridge1.

Any confusion that can happen is caused by abbreviations. If you keep the full syntax, there won't be any confusion possible. That's also what should be done with automated scripts.


when i run the command ip link add link foo type bridge on debian10, it will not ignore the unneeded parameters but report a error:

root@debian10:~#  ip link add link foo type bridge
Cannot find device "foo"

so the device foo must exists on the system, it will then ignore the unneeded parameters(here that is link foo) without any error report

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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