To clarify....
The term I referred to as "Double VLAN" is not the technically correct name
(thats just what I call it), it is actually called "Q in Q" as stated by
several in this thread.
One of the reasons this is valuable is for a wholesale network. It basically
allows you to create a single VLAN end to end across your network for a
subscriber or reseller, and still use VLAN for your local needs to operate
your network.
I'll give an example of where I might use VLAN for my network need. I have a
single fiber connection from the basement to the roof. On the roof I have a
VLAN switch and 6 sector radios. I have a router in the basement. I could
then seperate data between the different radio traffic by giving a unique
VLAN to the Ethernet port that each sector radio connects to, and route
between them in my basement router.
I'll give an example of where I'd use a VLAN end to end for a reseller.
Reseller has a connection between me and them at one point on my network.
The reseller might provide the backbone and IPs. The client routes the
customers traffic to a specific VLAN when entering my network. I then have
that VLAN configured across my network until reaches the end user's building
router that terminates the VLAN.
Now what happens when the resellers customer (example 2) resides in the
building (example 1)? Normally two VLANs can't exist simultaneously as teh
switch wouldn;t know which ID to tag data with. Q in Q VLAN would allow one
VLAN ID to reside in side of another VLAN. Its the same concept as
tunnelling, except for its not.
Now how does this apply to radios that support Q in Q? Depends. Use your
imagination. The first problem is can the radio pass Q in Q VLAN data?
Second can it tag it? Being able to tag VLAN data at the radio level can be
extremely useful. First off it avoids having to configure a second device
(VLAN switch) that complicates the automation of configurations. Part of
the Idea is that CLECs and Governement, are all high on Security, and they
do not want to have to coordinate complex IP models between their systems
and the wholesalers, instead they want to be able to send traffic LAyer2 and
seperate traffic so one client does not have the abilty to see the other
client's traffic. Its sort of an Ethernet way of doing a Private Virtual
Circuit.
The only problem with VLAN is you need to have every component of you
network that passes VLANs to be able to pass large packets so Full MTU can
be delivered to clients. This is one of the limits to Wifi and regular
switches, is many Wifi devices and all non managed switches do not pass
large packets.
Radio like Trango and Alvarion (with Q in Q support) have the abilty to pass
large packets.
The other advantage of VLAN is that when used across a PtMP design and VLAN
support at CPE, it allows doing remote banwdith management based on the
customers circuit ID, and having a way to distinguish and differentiate the
data.
Q in Q, gives the provider flexibilty on how and when they would like to use
VLAN and in multiple ways simultaneously.
Its uncertain how Q in Q will be used for sure, as VLAN does add much
complexity over say a basic bridged design. Part of the benefit, is that
redundancy is not always supported in an ideal way when VLAN is used. By
allowing a VLAN end to end encapsulated in the other packets, it potentially
could allow avoiding the pitfalls that limit redundancy by having the end
locations (the reseller and the client) the one tagging the VLAN and
knowing that that VLAN info survives any other VLAN tagging that may happen
on the network, or for that matter abilty for that data to route across
paths that are not technically that VLAN assignment on the other layer. I'm
not explaining this clearly, but that is the gist of it.
The end result is, if a provider's whole network supports Q in Q, it allows
them to compete with other fiber Metro-E services.
Many believe that the design of the future for Metro deployments is to run
MPLS at the edge devices, and then Q in Q VLAN inside the Metro Ethernet
rings. The key ideas here is abilty to creaetequivelent of virtual circuits
of Ethernet.
Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband
----- Original Message -----
From: "Charles Wu" <[EMAIL PROTECTED]>
To: "'WISPA General List'" <wireless@wispa.org>
Sent: Friday, June 09, 2006 11:33 AM
Subject: RE: [WISPA] looking for a device
I think Jon is asking about the "double VLAN" -- or a "q in q"
implementation
It's extremely useful for creating virtual bridged customer networks
-Charles
-------------------------------------------
CWLab
Technology Architects
http://www.cwlab.com
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Rick Harnish
Sent: Friday, June 09, 2006 9:10 AM
To: 'WISPA General List'
Subject: RE: [WISPA] looking for a device
Virtual LAN. Imagine segregating segments of your network across a backhaul
pipe so that they flow together but don't actually see each other. Managed
switches have the ability to create VLANs per port. Think of it as a merger
between routing and switching. Its a pipe or several inside a pipe. Tried
to be simple here, I'm sure someone else can give you a more technical
description.
Rick Harnish
President
OnlyInternet Broadband & Wireless, Inc.
260-827-2482 Office
260-307-4000 Cell
260-918-4340 VoIP
www.oibw.net
[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of John Scrivner
Sent: Friday, June 09, 2006 9:39 AM
To: WISPA General List
Subject: Re: [WISPA] looking for a device
Can you or someone explain what double VLAN is? I have never heard of
such a thing. How can it be used to help us?
Thanks,
Scriv
Yo may want to look at Alvarion. Alvarion does support VLAN. new
Firmware4 supports double VLAN also.
Alvarion used to have one model that was designed to have a second
integrated radio into it.
I can't remember if it was a 900/2.4 combo, or a 5.8/2.4 combo.
--
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
--
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
--
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
--
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
