Re: vlans and cloning

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

_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: vlans and cloning
    ... ifconfig vlan0 vlan 1 vlandev em0 ... you can still specify the name of the cloned device. ...
    (freebsd-arch)
  • Re: problem with vlan interfaces in 6-STABLE
    ... >> I have a small problem with my vlan interfaces configured from rc.conf: ... The config did not change during the update: ... > to ifconfig in RELENG_6. ... those from the parent, ...
    (freebsd-stable)
  • Re: vlans and cloning
    ... ifconfig vlan0 vlan 1 vlandev em0 ... root@homelynx# ifconfig vlan32 vlan 32 vlandev rl0 ...
    (freebsd-arch)
  • Re: "ifconfig -vlandev" syntax
    ... > deprecate the old syntax so we may need to keep it around. ... ifconfig: must specify both vlan tag and device ... ifconfig_vlan14="vlan 14 vlandev fxp0 name somename" ...
    (freebsd-current)
  • Re: "ifconfig -vlandev" syntax
    ... > deprecate the old syntax so we may need to keep it around. ... ifconfig: must specify both vlan tag and device ... ifconfig_vlan14="vlan 14 vlandev fxp0 name somename" ...
    (freebsd-net)