vlans and cloning
Sam Leffler
sam at errno.com
Mon Jul 10 18:53:28 UTC 2006
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 at homelynx# ifconfig vlan32 create
> root at homelynx# ifconfig vlan32 vlan 32 vlandev rl0
> root at homelynx# ifconfig vlan32 -vlandev
> root at homelynx# ifconfig vlan32 vlan 33 vlandev rl0
> root at 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
More information about the freebsd-arch
mailing list