What is the difference between ip link "add link" vs "add dev" commands

Solution 1:

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.

Solution 2:

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