vlan troubles - SIOCIFCREATE2: File exists

Hello

I have some strange problems with creating vlan1.
When creating other vlans no any problems,only with vlan1.

Code:
root@core:/etc # ifconfig vlan1
ifconfig: interface vlan1 does not exist
root@core:/etc # ifconfig vlan1 create
ifconfig: SIOCIFCREATE2: File exists
root@core:/etc # ifconfig vlan11
ifconfig: interface vlan11 does not exist
root@core:/etc # ifconfig vlan11 create
root@core:/etc # ifconfig vlan11 
vlan11: flags=8002<BROADCAST,MULTICAST> metric 0 mtu 1500
	ether 00:00:00:00:00:00
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	vlan: 0 parent interface: <none>
root@core:/etc # ifconfig vlan11 destroy
root@core:/etc # 

root@core:/etc # uname -isr
FreeBSD 9.1-RELEASE GENERIC
root@core:/etc # uname -a
FreeBSD core 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
root@core:/etc #
 
I just tried to reproduce this on a box where I have set up two vlans (vlan0 and vlan1), but later renamed them to something else.
/etc/rc.conf
Code:
cloned_interfaces="vlan0 vlan1"
ifconfig_vlan0="inet a/b vlan 1 vlandev x name someName"
ifconfig_vlan1="inet c/d vlan 2 vlandev x name someOtherName"

I get the same results as you when trying to create vlan0/vlan1, but vlan2 works.
I suspect this might be because something still remembers these virtual interfaces were named vlan0/vlan1.
 
I tried syntax with and without write vlan1 in rc.conf, but without success.
Tried too netif && routing restart with vlan1 parameters in rc.conf, no success.

with vlan1 config in rc.conf
Code:
## Cloned interfaces lagg/vlann
#
cloned_interfaces="lagg0 ix1.669 em2.4 em2.1000 em2.1111 em2.1114 em2.3479 em2.3480 vlan1 vlan42 vlan101 vlan121 vlan122 vlan123
vlan124 vlan125 vlan126 vlan127 vlan128 vlan129 vlan131 vlan132 vlan133 vlan135 vlan137 vlan138 vlan139 vlan200"
#

#       lan vlan
ifconfig_vlan1="vlan 1 vlandev lagg0"
ifconfig_vlan42="vlan 42 vlandev lagg0"
ifconfig_vlan101="vlan 101 vlandev lagg0"
ifconfig_vlan121="vlan 121 vlandev lagg0"
ifconfig_vlan122="vlan 122 vlandev lagg0"
ifconfig_vlan123="vlan 123 vlandev lagg0"
ifconfig_vlan124="vlan 124 vlandev lagg0"
##ifconfig_vlan124_alias0="inet 192.168.100.1 netmask 255.255.255.224"
ifconfig_vlan125="vlan 125 vlandev lagg0"
ifconfig_vlan126="vlan 126 vlandev lagg0"
ifconfig_vlan127="vlan 127 vlandev lagg0"
ifconfig_vlan128="vlan 128 vlandev lagg0"
ifconfig_vlan129="vlan 129 vlandev lagg0"
ifconfig_vlan131="vlan 131 vlandev lagg0"
ifconfig_vlan132="vlan 132 vlandev lagg0"
ifconfig_vlan133="vlan 133 vlandev lagg0"
ifconfig_vlan135="vlan 135 vlandev lagg0"
ifconfig_vlan137="vlan 137 vlandev lagg0"
ifconfig_vlan138="vlan 138 vlandev lagg0"
ifconfig_vlan139="vlan 139 vlandev lagg0"
ifconfig_vlan200="vlan 200 vlandev lagg0"
 
vLAN ID 1 is the default vlan, and always exists. It's what all interfaces use by default. You can't create it or destroy it.
 
bsdfunn:
Is it feasible to disable all vlans in rc.conf, restart the box, and then try to manually create the vlan, for testing purposes? Please see next post.


phoenix said:
vLAN ID 1 is the default vlan, and always exists. It's what all interfaces use by default. You can't create it or destroy it.

False. In the following example, I'm adding the virtual device vlan1 which is assigned vlan id 1, on an install which does not already use vlans. It works.
Code:
# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether .....
        inet .... netmask ... broadcast ...
        inet6 ...%em0 prefixlen 64 scopeid 0x1
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
# ifconfig vlan1 create vlandev em0 vlan 1
# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether .....
        inet .... netmask ... broadcast ...
        inet6 ...%em0 prefixlen 64 scopeid 0x1
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
vlan1: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=3<RXCSUM,TXCSUM>
        ether ...
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        vlan: 1 parent interface: em0
# uname -a
FreeBSD ... 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
 
I created a new VM to try and mimick bsdfunn's setup.
I found out that creating vlans by the style if.vlan (i.e. em2.4) is using a vlanN device (for example vlan0, vlan1) behind the scenes, and then renames it to em2.4. As I stated in my first reply to this thread, something still remembers the original name of the interface, and will state that it already exists. I do not know why. :)

bsdfunn: Try altering your cloned_interfaces line to the following, and see if that helps:
Code:
cloned_interfaces="vlan1 vlan42 vlan101 vlan121 vlan122 vlan123 vlan124 vlan125 vlan126 vlan127 vlan128 vlan129 
vlan131 vlan132 vlan133 vlan135 vlan137 vlan138 vlan139 vlan200 lagg0 ix1.669 em2.4 em2.1000 em2.1111 em2.1114 em2.3479 em2.3480"

I think this will create your custom-numbered vlan* interfaces first, then fill the gaps with the em2.4-style vlan definitions.


Or in order to make it a little more future proof, maybe something like this?
Code:
cloned_interfaces="vlan0 vlan1 ...."
ifconfig_vlan0="vlandev em2 vlan 4 name em2.4"
ifconfig_vlan1="vlandev em2 vlan 1000 name em2.1000"
...
 
Untagged ethernet frames do not belong to any VLAN by definition, not even to VLAN 1. It's only when a VLAN capable device, switch for example, receives those frames it may decide to assign them to VLAN 1 internally. That's in fact a default configuration on many VLAN capable switches.
 
This may be fixed in head/, where we utilized alloc_unr(9) in the interface cloning infrastructure, and the latter had been significantly rewritten. I'd appreciate if you compare behavior of your create/destroy sequence in head and stable/9.
 
Back
Top