[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
[bsekle...@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 <bsekle...@collaborativefusion.com>
Collaborative Fusion, Inc.
signature.asc
Description: This is a digitally signed message part
