Date: Mon, 10 Jul 2006 11:53:20 -0700 From: Sam Leffler <sam@errno.com> To: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning Message-ID: <44B2A220.4090705@errno.com> In-Reply-To: <20060710211733.Y58186@atlantis.atlantis.dp.ua> References: <44B15511.206@errno.com> <20060710103404.I25526@atlantis.atlantis.dp.ua> <44B2713A.2020204@errno.com> <20060710211733.Y58186@atlantis.atlantis.dp.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Dmitry Pryanishnikov wrote: > > Hello! > > On Mon, 10 Jul 2006, Sam Leffler wrote: >>> ifconfig vlan0 create >>> ifconfig vlan0 vlan 1 vlandev em0 >>> >>> sequence is required for now. Also, I thing it's perfectly correct to >>> have >>> >>> cloned_interfaces="vlan30" >>> >>> while NOT having 'ifconfig_vlan30' assignment - system administrator >>> could just reserve a spare interface w/o assigning it's parameters. So I >>> think >>> that possibility of the specific device cloning w/o arguments, e.g., >>> >>> ifconfig vlan30 create >>> >>> should be preserved. >> >> Clearly one would need to fix rc scripts. The question is should the >> old behaviour be preserved; it provides no functionality--i.e. a cloned >> device is unusable until you set the tag+parent and you cannot set the >> tag or parent on an existing cloned device (once setup). So the only > > I don't agree: > > 1) Cloned but unset device is perfectly legal for, e.g., mentioning > in ipfw rules (or any other context which requires interface name); > > 2) Sure, you _can_ change tag+parent afterwards: > > root@homelynx# ifconfig vlan32 create > root@homelynx# ifconfig vlan32 vlan 32 vlandev rl0 > root@homelynx# ifconfig vlan32 -vlandev > root@homelynx# ifconfig vlan32 vlan 33 vlandev rl0 > root@homelynx# Hmm, that did not work yesterday in my testing. That's the answer I've been looking for. Thank you. OTOH I can easily see that plumbing a vlan into firewall rules and then changing it's configuration might generate very hard to find bugs; but whatever. > >> preserve existing practice. Removing the 2 step procedure would allow >> code to be removed and (IMO) clarify how a vlan is crafted. In the >> future there will be cloned devices that cannot/will-not be specified >> with a 2-step procedure so having vlans work this way will violate POLA. > > Please don't break well-known and useful behaviour! Remember that it > allows > to switch easily physical vlanXXX device assignment (e.g., migration to the > another trunk) w/o reloading firewall rules. I've got no plans. You'll note I committed the new stuff as completely separate. I only asked now because I saw an opportunity to remove cruft. But given that it's used that cruft can just stay around. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44B2A220.4090705>