[LiSA-Devel] 8021q and bridge implementation

[Radu Rendec]

On Thu, 2013-05-02 at 18:50 +0300, Claudiu Ghioc wrote:
> 1. In switch_init, now we add a default VLAN (VID 1), using the
> "vlan_add" function. I believe we must add a default bridge (let's
> name it br1) in which the switch interfaces will be added. Am I
> correct?

The vlan_add() implementation for bridge should create a bridge
interface that corresponds to the given vlan id. Since switch_init()
calls vlan_add() with id=1, the "default" bridge will be created
automagically. You don't need to do anything specific for creating the
"default" bridge.

As for the name, I would suggest "vlan%d" instead of "br%d" to keep
compatibility with the "switch" module and the "interface vlan x"
command in the CLI.

> 2. When we add an interface to the switch, does this mean that we also
> have to add it to the default bridge? (br1, VLAN id 1)

When we add a new interface to the switch it is configured by default in
"access" mode and set up in the default vlan, which is 1 for now (and we
don't have any implemented mechanism to change it). This should be
handled by if_add() when mode=SW_IF_SWITCHED, without requiring the
frontend to additionally call if_set_mode() and/or if_set_port_vlan().

> 3. Each time we create a new VLAN we have to create a new bridge.
> Therefore this action will not be reflected in the "8021q" module, but
> only in the "bridge" module.

Correct.

> Afterwards we will use the VLAN module if
> we want to add an interface in a VLAN. Again, am I right?

The 8021q module is only required when the interface is set in "trunk"
mode. As long as the interface is in "access" mode, you add it directly
to the bridge that corresponds to the interface's configured access
vlan.

> 4. If we want to add a VLAN (66) to a interface (say eth0) we also
> have to create a new interface (eth0.66) and add it to the bridge
> "br66" (the one for VLAN 66).

Correct. But keep in mind that you must only do this when the interface
is in "trunk" mode. BUT, trunk vlans can be configured while the
interface is in "access" mode, they just won't immediately reflect in
the interface's configuration. You have to store this information (the
trunk vlans) somewhere, so you may use it when the interface is changed
to "trunk" mode.

For the "switch" module, this happens by default, because the forbidden
vlan bitmap serves for both the switching engine and storing the "list"
of trunk vlans.

But for your backend, I think you need to explicitly store the list of
trunk vlans somewhere in the backend-specific data area (probably in the
SHM segment).

> What happens then with eth0? Don't we
> also have to create a new interface eth0.1 for the default VLAN?

You only need to create eth0.1 (and add it to the "vlan1" bridge) if
vlan 1 is part of the eth0 trunk vlans. This is pretty clear.

On the other hand, theory says that when you receive an untagged frame
on a trunk port, you inject that frame for switching in the vlan that is
configured as "native vlan" for that port. By default, vlan 1 also
serves as "native vlan" for all trunk ports, but it can be configured to
something else on a per-port basis.

To implement the native vlan functionality, you'd have to remove eth0
from the configured "access vlan" bridge and add it to the "native vlan"
bridge, if these 2 are distinct.

But the big question is what does the 8021q module when you receive
untagged frames on an interface that has 8021q virtual interfaces.
Normally, it should leave the untagged frames follow the natural rx path
of the primary interface (eth0 in your case), but I'm not sure. This has
to be tested.

Radu