04/28/2001 - BBP: initial version of the FAQ
04/29/2001 - nitrox: corrected mailing-list address

--------------------------------------------------------------------------------
Table Of Contents
--------------------------------------------------------------------------------

1 Basic principle
1.1 What is a VLAN server and do I need one ?
1.2 But what is a VLAN, anyway ?
1.3 But how do hosts exchange data when they are not in the same VLAN ?
1.4 Some of my network equipements support multicast, how can I use them ?

2 Current status
2.1 I would like to use the VLAN server on my network, how do I do ?
2.2 Is the VLAN server stable ?
2.3 What switches are supported ?
2.4 When will my switches be supported ?
2.5 I want to use the VLAN server on my network, where is the doc ?
2.6 Does the current version catch SNMP traps from switches ?
2.7 Does the current version handle multicast ?
2.8 When will the next version be released ?

3 Security
3.1 Is the VideoLAN's VLAN server secure ?
3.2 So why did you release it ?
3.3 When will a secure version be available ?

4 Contributing
4.1 I have found a bug in the VLAN server, what do I do ?
4.2 I have a patch which corrects a bug/adds a new feature, what do I do ?
4.3 How do I request a feature ?
4.4 I would like to write a patch, but I don't understand the code
4.5 I would like to create and distribute a package for my favorite distro

--------------------------------------------------------------------------------
1 Basic principle
--------------------------------------------------------------------------------

1.1 What is a VLAN server and do I need one ?
---------------------------------------------

Some recent network equipements are able to process multicast packets properly,
thus enabling their owner to multicast some data (say some video streams :=) )
on their network. However, some older equipements do not handle these packets
properly or treat them as broadcast packets, and this prevents their users from
sending high bandwith data streams to several sets of clients.

There is however a workaround for this on ethernet networks: using VLANs, one
can in some way simulate multicast with a few tricks. A VLAN server is an
essential tool for this to work. So you need a VLAN server if you want to
multicast data streams on an ethernet network which is too old to properly
handle multicast.

1.2 But what is a VLAN, anyway ?
--------------------------------

I won't be exhaustive here, but just explain the basics of the VLAN technology.
Basically, when one configures an ethernet switch featuring this technology, she
can assign each port to one VLAN (Virtual Local Area Network). Then, the switch
considers each VLAN as a separate network: data coming from a port in VLAN x can
only join ports which are also in VLAN x. The consequence is that a host
connected to a port in a certain VLAN can't exchange ethernet frames with
another host connected to a port in another VLAN.

The idea to emulate multicast is that for each data stream that should be
multicasted, we will create a new VLAN, and broadcast this stream in this VLAN.
Then, when a host needs to receive the stream, the VLAN server will put the port
this host is connected to in the proper VLAN. This way, only the ports which
should transmit the stream will actually do it. On the VideoLAN team's network,
this trick permits to "multicast" up to 16 MPEG-2 5 Mbps streams on a 10 Mbps
ethernet network.

1.3 But how do hosts exchange data when they are not in the same VLAN ?
-----------------------------------------------------------------------

Well, that's a good question, because the basic role of VLANs is precisely to
prevent this to happen :). Several tricks exist, so I will give two examples.

The first thing you have to know to understand them is that it is possible for a
host to be in several VLANs at the same time. It could for instance have several
ethernet cards, one in each VLAN. Another way is to have a VLAN capable NIC, or
an ATM card connected to an ATM backbone if your network has such a backbone. At
last, the linux VLAN project enables to do so with most common NICs.

So let's start with our tricks.

The solution that has been sucessfuly experimented by the VideoLAN team is to
have a host connected to each VLAN, which transmits IP datagrams between VLANs
when needed. Such a host is called a VLAN bridge. The VLAN bridge's code is not
released yet, but it is available from the CVS.

Another way to enable hosts to communicate is to use some special features of
switches. But it is not guaranteed to work, it depends on all your switches. It
is however a far better solution. For instance, one could use a VLAN for
communication between hosts and the other VLANs to emulate multicast. Then,
each switch on the network should have at least one port configured to be in
every VLAN (of course, this port must be faster than the other ports), and this
port connected to a central switch. This central switch would have some ports in
the communication VLAN and one port for each "multicast" VLAN. Then, you just
have to plug a cable, one end in the communication VLAN and the other end in the
"multicast" VLANs. Then, to avoid "multicast" packets to go from one VLAN into
another, configure the central switch to forbid broadcast packets from going
through the "multicast" ports. Well.. this was not so clear, was it ? Let's do
some ascii-art. We will assume one uses the VLAN 2 for communication between
hosts, and the 12 and 42 VLANs for "multicast" streams, and that the switches
feature one 100 Mbps port and several 10 Mbps ports. We will use a central
switch with several 100 Mbps ports.


   +-----------------------------------------------------------------------+
   |                                                                       |
   |                            central switch                             |
   |                                                                       |
   +--------+--------+--------+--------+--------+--------+--------+--------+
   |100 Mbps|100 Mbps|100 Mbps|100 Mbps|10 Mbps |10 Mbps |10 Mbps |10 Mbps |
   |port    |port    |port    |port    |port    |port    |port    |port    |
   |in VLANs|in VLANs|in VLANs|in VLANs|in VLAN |in VLAN |in VLAN |in VLAN |
   |2,12,42 |2,12,42 |2,12,42 |2,12,42 |2       |12      |2       |42      |
   |bcasts  |bcasts  |bcasts  |bcasts  |bcasts  |bcasts  |bcasts  |bcasts  |
   |allowed |allowed |allowed |allowed |allowed |blocked |allowed |blocked |
   +--------+--------+--------+--------+--------+--------+--------+--------+
       ||       ||       ||       ||       ||       ||       ||       ||
       ||       ||       ||       ||       ||       ||       ||       ||
       ||       ||       ||       ||        \=======/         \=======/
       ||       ||       ||       ||
       ||       ||       ||       ||
       ||       ||       ||       ||       +--------+----------------------+
       ||       ||       ||       ||       |        |the other ports of    |
       ||       ||       ||       ||       |100 Mbps|this switch need only |
       ||       ||       ||       ||       |port    |to be 10 Mbps ports   |
       ||       ||       ||       ||       |in VLANS|and they are in a VLAN|
       ||       ||       ||        \=======|2,12,42 |depending on the mcast|
       ||       ||       ||                |bcasts  |stream the host       |
       ||       ||       ||                |allowed |connected to them     |
       ||       ||       ||                |        |receives; of course   |
       ||       ||       ||                |        |they allow broadcasts |
       ||       ||       ||                +--------+----------------------+
       ||       ||       ||
       ||       ||       ||       +--------+----------------------+
       ||       ||       ||       |        |the other ports of    |
       ||       ||       ||       |100 Mbps|this switch need only |
       ||       ||       ||       |port    |to be 10 Mbps ports   |
       ||       ||       ||       |in VLANS|and they are in a VLAN|
       ||       ||        \=======|2,12,42 |depending on the mcast|
       ||       ||                |bcasts  |stream the host       |
       ||       ||                |allowed |connected to them     |
       ||       ||                |        |receives; of course   |
       ||       ||                |        |they allow broadcasts |
       ||       ||                +--------+----------------------+
       ||       ||
       ||       ||       +--------+----------------------+
       ||       ||       |        |the other ports of    |
       ||       ||       |100 Mbps|this switch need only |
       ||       ||       |port    |to be 10 Mbps ports   |
       ||       ||       |in VLANS|and they are in a VLAN|
       ||        \=======|2,12,42 |depending on the mcast|
       ||                |bcasts  |stream the host       |
       ||                |allowed |connected to them     |
       ||                |        |receives; of course   |
       ||                |        |they allow broadcasts |
       ||                +--------+----------------------+
       ||
       ||       +--------+----------------------+
       ||       |        |the other ports of    |
       ||       |100 Mbps|this switch need only |
       ||       |port    |to be 10 Mbps ports   |
       ||       |in VLANS|and they are in a VLAN|
        \=======|2,12,42 |depending on the mcast|
                |bcasts  |stream the host       |
                |allowed |connected to them     |
                |        |receives; of course   |
                |        |they allow broadcasts |
                +--------+----------------------+

With this solution, you will however need an ARP proxy that will be in each
VLAN, but the difference with the VLANbridge is taht this work can be
distributed over several machines. Indeed, you could even use one machine for
each VLAN. Another solution would be to completely remove ARP requests by
entering the MAC addresses of each host in each other host's ARP table. Or
one could write an ARP forwarder, this should not be too hard. The appropriate
solutoin depends on your exact network layout.

1.4 Some of my network equipements support multicast, how can I use them ?
--------------------------------------------------------------------------

In one word, yes. I won't give many details here, because there are hundreds of
ways to do this, but a simple technique is to use a VLAN in which streams are
multicasted and the other VLANs for multicast emulation.

--------------------------------------------------------------------------------
2 Current and future status
--------------------------------------------------------------------------------

2.1 I would like to use the VLAN server on my network, how do I do ?
--------------------------------------------------------------------

Currently, creating a multicast emulation solution is not really simple, and the
VLAN server hardly matches our needs, so it won't probably  match yours. We will
probably have to add new features or at least support for your switches in order
for this to work. So, contact our users mailing-list:

	vlcs@videolan.org

Precisely describe your network topology, even if you don't know how you can use
the VLAN server exactly and we will discuss what we can do. But first read the
3.1 question about security. Really. Do it. Now.

2.2 Is the VLAN server stable ?
-------------------------------

NO. There are probably many bugs in the VLAN server, it has not been much tested
yet. And there are still many kludges in the code.

2.3 What switches are supported ?
---------------------------------

The only switches supported currently are 3Com superstack 1000, 1100 and 3300
switches.

2.4 When will my switches be supported ?
----------------------------------------

Adding support for new switches is trivial in most cases. If you need support
for a certain type of switches, just contact the developpers:

	vlcs@videolan.org

You will be asked for some information about the MIB of your switches, and
support will probably be added promptly.

2.5 I want to use the VLAN server on my network, where is the doc ?
-------------------------------------------------------------------

Err, well... There is not much documentation yet, because the configuration of
the VLAN server depends heavily on your network topology, and we probably will
have to write some additional code before you can use it. So if you plan to use
it or just wonder whether you can use it or not, you should contact our users
mailing list:

	vlcs@videolan.org

2.6 Does the current version catch SNMP traps from switches ?
-------------------------------------------------------------

No. Some code has been written in order to do so, but it does not work yet, and
we do not know yet if this code will be completed in a near future.

2.7 Does the current version handle multicast ?
-----------------------------------------------

It does not handle multicast currently, but you can still use the VLAN server in
a network where you use multicast and VLANs. It just does not care about
multicast, so you will have to use another for solution for the multicast part.
However, some code (not yet completed) has been written so that an arbitrary
text string (depending on the channel) can be sent to the client requesting to
change its channel, so it is quite easy to implement something to help multicast
users.

2.8 When will the next version be released ?
--------------------------------------------

In fact two new versions are planned. The current application is called the VLANserver, and it will be maintained while the new application, called VLCS
(VideoLAN Channel Server), is not released. The term "maintained" here means we
will correct reported bugs and add requested features when it is possible, but
the largest part of our developpement effort will be for the VLCS.

A new VLAN server version may come very soon if we have some bug reports and
if we are able to correct the bugs quickly. We may also release new versions
soon if support for other kind of switches is requested.
But the developpement of the VLCS should take quite a long time. However, the
VLAN server will progressively be left, and we will concentrate on the
developpement of the VLCS, which will be able to handle much more network
topologies (it will in particular provide support for multicast architectures),
and be much more stable, powerful and flexible than the VLAN server.

If you want to keep informed about future developpements, you can subscribe to
our users mailing list. For this, send a mail to listar@videolan.org with
subscribe vlcs-users in the subject.

You can also subscribe to the developpers mailing list. For this, send a mail to
listar@videolan.org with subscribe vlcs-devel in the subject.

--------------------------------------------------------------------------------
3 Security
--------------------------------------------------------------------------------

3.1 Is the VideoLAN's VLAN server secure ?
------------------------------------------

NO. NOT AT ALL. We know there are buffer overflows and other security holes in
the current VLAN server. Moreover, there is no client authentification at all:
anyone reading the source to understand the protocol used between the clients
requesting to change their VLAN and the VLAN server is able to change the VLAN
of any host. This version of the VLAN server is only a very soon developpement
version.

Usage of this software should be very careful and only authorized clients should
be able to access it. Use firewalling, and remember it won't protect you from an
internal malicious user.

3.2 So why did you still release it ?
-------------------------------------

Because some discussions with a few other schools showed that they also needed
something like this. We know they can not use it as is (we can hardly use it),
but a very large part of the code should be useful to them.

3.3 When will a secure version be available ?
---------------------------------------------

Hard question. In fact, the VLAN server project has been forked recently between
its current version, which is full of kludges which will probably never be
removed, and a new version, called the VLCS (for VideoLAN Channel Server), which
should be much more clean and secure. In particular, we will not have time to
patch security holes in the current VLAN server. We will just patch other bugs.

We think we had better making a channel server that really rocks instead of
continuously patching the VLAN server. So use it at your own risks. You know it
contains security holes, and it's up to you to decide whether you have
reasonable users or not.

--------------------------------------------------------------------------------
4 Contributing
--------------------------------------------------------------------------------

4.1 I have found a bug in the VLAN server, what do I do ?
---------------------------------------------------------

You can report the bug to the VLAN server's developpers mailing list:

	vlcs-devel@videolan.org

Please include the most precise description of the problem you can, and send us
the VLAN server's logs if you have some. Compiling the VLAN server in debug mode
should also help diagnosing the problem.

4.2 I have a patch which corrects a bug/adds a new feature, what do I do ?
--------------------------------------------------------------------------

Please contact the VLAN server's developpers mailing list:

	vlcs-devel@videolan.org

4.3 How do I request a feature ?
--------------------------------

Don't hesitate to mail your features requests to our mailing list. If it can
quickly be added to the current VLAN server, it probably will. If it can't, we
will at least give you some clues to do it yourself, and you can be sure it will
be in the features list of the new channel server.

4.4 I would like to write a patch, but I don't understand the code
------------------------------------------------------------------

Yes, the code is not so simple, and some more comments and/or documentation
would be useful. Well, don't hesitate asking questions on the developpement
mailing list.

4.5 I would like to create and distribute a package for my favorite distro
--------------------------------------------------------------------------

PLEASE DON'T. Please do not package this software nor distribute it under binary
form. We would really really like that anyone using this software sees several
times the disclaimers about security.

But for packaging the channel server when it will be available, you're welcome.
