[trouble] restart network & vlan`s interface (if_vlan / conf/63700 redux)

[Brian A. Seklecki]

[Originally from freebsd-hackers@ / Feb 2008]

 All:
  
 pf conf/63700 got the ball rolling on fixing cloned/VLAN 
 interface management with rc.d/netif, but problems still remain.  

 For example, adding an alias to a VLAN and running:
 /etc/rc.d/netif restart && /etc/rc.d/routing restart 
 is a failure.

Take the following rc.conf(4) config:

hostname="sexdrugsandunix"
cloned_interfaces="vlan14"
ifconfig_em0="up media 100baseTX mediaopt full-duplex -tso"
ifconfig_vlan14="inet 1.2.3.4 netmask 255.255.255.128 vlan 14 vlandev
em0 up"
ifconfig_vlan14_alias0="inet 1.2.3.5 netmask 255.255.255.255"

Change it to include a second alias without a reboot, instead run
'rc.d/netif restart', as works on a physical interface:

hostname="sexdrugsandunix"
cloned_interfaces="vlan14"
ifconfig_em0="up media 100baseTX mediaopt full-duplex -tso"
ifconfig_vlan14="inet 1.2.3.4 netmask 255.255.255.128 vlan 14 vlandev
em0 up"
ifconfig_vlan14_alias0="inet 1.2.3.5 netmask 255.255.255.255"
ifconfig_vlan14_alias1="inet 1.2.3.6 netmask 255.255.255.255"

The result will be:

% ifconfig vlan14
[bseklecki at sureshot ~]$ ifconfig vlan14
vlan14: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
inet 1.2.3.6 netmask 0xffffffff broadcast 192.168.158.152
inet 1.2.3.5 netmask 0xffffffff broadcast 192.168.158.255


1) I'm not sure where the .152 broadcast comes from. ?!
2) The new _alias1= data is now in the primary IP slot
3) The primary IP is lost, there is no routable IP
4) The original _alias0= data is now in the 1st alias slot
5) rc.d/routing fails because the interface lacks a routable
   IP with a valid netmask/broadcast combination.

 ---------------------------

 Problem #1: rc.d/netif::network_stop()

 The core problem is that rc.d/netif::network_stop() never calls
 network.subr::clone_down() in the same way that
 rc.d/netif::network_start() calls network.subr::cloned_up()

 I'd speculate that this is a design decision not to destroy 
 network interfaces that certain userland daemons (DHCP, RTADVD, 
 BPF) may be strictly bound to; I disagree.

 Even if you explicitly pass your VLAN interface to rc.d/netif,
 a stop doesn't call 'ifconfig VL destory', and, when 'rc.d/netif start'
 is called later, SIOCSETVLAN results.

 jail-host-80:/home/bseklecki% sudo ifconfig vlan666 destroy
 jail-host-80:/home/bseklecki% sudo ifconfig vlan666 
 create inet 1.2.3.4 netmask 255.255.255.0 vlan 666 vlandev em0
 jail-host-80:/home/bseklecki% sudo ifconfig vlan666 
 create inet 1.2.3.4 netmask 255.255.255.0 vlan 666 vlandev em0
 ifconfig: create: bad value

 A simple rc.d/network_stop() patch could fix this problem if 
 we can avoid bikeshedding.

------------------------------------------


 Problem #2: VLAN interface data structures maintain configuration 
             data after being destroyed, *SOMETIMES*

%ifconfig vlan666
vlan666: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500
	options=3<RXCSUM,TXCSUM>
	ether 00:0c:29:a1:4b:9d
	inet 192.168.15.54 netmask 0xffffff00 broadcast 192.168.15.255
	media: Ethernet 1000baseT <full-duplex>
	status: active
	vlan: 666 parent interface: em0
%sudo ifconfig vlan666 destroy
%sudo ifconfig vlan666 create
%ifconfig vlan666
vlan666: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500
	options=3<RXCSUM,TXCSUM>
	ether 00:0c:29:a1:4b:9d
!!**?>>	inet 192.168.15.54 netmask 0xffffff00 broadcast 192.168.15.255
	media: Ethernet 1000baseT <full-duplex>
	status: active
	vlan: 666 parent interface: em0

Now, that's something you don't see very day!!
----------------------------------------------------

NOTE: I can't get that persistent IP data problem to happen
consistently, but its highly reproducible.


I also have no idea on the fixes, I'll check this weekend, but I have a
work-around.

To avoid destroying your routing table after adding an alias to a VLAN
interface in rc.conf(5), simply run:

 $ sudo /etc/rc.d/netif [VLAN####] start

 DO NOT RESTART, and you should be okay.

~BAS

References:

http://lists.freebsd.org/pipermail/freebsd-hackers/2008-February/023440.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=63700&cat=  (Circa 2004)
http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015447.html



-- 
Brian A. Seklecki <bseklecki at collaborativefusion.com>
Collaborative Fusion, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20100604/be5db369/attachment.pgp