Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Jul 2006 22:23:37 +0300 (EEST)
From:      Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>
To:        Sam Leffler <sam@errno.com>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: vlans and cloning
Message-ID:  <20060710215459.W95495@atlantis.atlantis.dp.ua>
In-Reply-To: <44B2A220.4090705@errno.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060710215459.W95495>