From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 19:23:53 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 2696F16A4FF for ; Mon, 10 Jul 2006 19:23:53 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 652E443D45 for ; Mon, 10 Jul 2006 19:23:52 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k6AJNb8F020149; Mon, 10 Jul 2006 22:23:37 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Mon, 10 Jul 2006 22:23:37 +0300 (EEST) From: Dmitry Pryanishnikov To: Sam Leffler In-Reply-To: <44B2A220.4090705@errno.com> Message-ID: <20060710215459.W95495@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> <44B2A220.4090705@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 19:23:53 -0000 On Mon, 10 Jul 2006, Sam Leffler wrote: >> 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. This (changing vlan binding w/o device destruction) is very handy for providing software-assisted failover in some hardware configurations. Suppose you have 2 VLAN trunks (say fxp2 and fxp3) which (via different physical media) are connected to the same remote switch (which demultiplexes VLANs to the different clients). Changing 'vlandev' on-the-fly (actually removing old parent with -vlandev, then assigning the new one), you can just move all vlans from e.g. fxp2 to fxp3 (in the event of fxp2's hardware link failure) w/o touching the firewall. I had this scheme in production during several months, and didn't see any bugs (under RELENG_4, but I doubt that such a simple yet efficient feature is broken in newer branches). >> 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. I hope I've managed to show that it isn't a cruft ;) Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE