From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 18:53:28 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00A1A16A4DE for ; Mon, 10 Jul 2006 18:53:28 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7689843D5E for ; Mon, 10 Jul 2006 18:53:27 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6AIrKiO088515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jul 2006 11:53:20 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44B2A220.4090705@errno.com> Date: Mon, 10 Jul 2006 11:53:20 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: Dmitry Pryanishnikov References: <44B15511.206@errno.com> <20060710103404.I25526@atlantis.atlantis.dp.ua> <44B2713A.2020204@errno.com> <20060710211733.Y58186@atlantis.atlantis.dp.ua> In-Reply-To: <20060710211733.Y58186@atlantis.atlantis.dp.ua> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 18:53:28 -0000 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