From: David Schwartz on
On Jun 23, 6:44 pm, "Mark" <mark_cruzNOTFORS...(a)hotmail.com> wrote:

> bcm5358's ethernet driver supports VLANs and currently it seperates these 5
> ports in two VLAN groups. Now I'm going to
> use two ports of bcm5358 to connect to external 24-port switch, thus these
> two ports will serve as WAN and LAN ports respectively and should be able to
> have IP addresses on them.  I see no other reason rather then make them look
> distinct interfaces form the point of view of OS.

Do you understand the way people would normally do this? They would
assign one VLAN ID to the first port and one to the second, say 1 and
2. They would then use the operating system's VLAN support to create
interfaces 'eth0.1' and 'eth0.2', each of which can be assigned an IP
address and treated as a distinct interface by the OS.

This has two huge benefits over your approach:

1) They could still set a third port to preserve VLAN tags and connect
it to an intelligent switch. This would allow them to extend both
interfaces over a single link.

2) They could add a third port into either VLAN and preserve the
hardware switching capability.

Distinct interfaces would make both of these things impossible.

DS
From: Mark on
There was perhaps misunderstanding on both sides, so I've drawn a
small picture at http://www.imagehousing.com/image/493175 describing
the architecture of the device.

Port 0 is WAN, port 1 is for LAN of internal switch are fixed, port 5
internal MII to CPU, other ports will not be used. Ports A and B of
the managed 24-port switch are fixed and wired to port 0 and 1
respectively.

So, there will be two VLAN groups on the managed switch:

SwitchGroup 1 - port A.... for WAN
SwitchGroup 2 - port B... for LAN

(such are the requirements). On the other hand, the CPU will have two
vlan groups:

Group 1 - port 0 & 5 (wan)
Group 2 - port 1 & 5 (lan)

These groups on CPU are managed and created by the Ethernet driver, so
they are not visible to OS. As you suggested, I should use, for
example, vconfig tool to create two vlan interfaces:

eth0.vlan1 (wan)
eth0.vlan2 (lan)

where the underlying interface is only eth0.

Does it look fine now ?

PS. And to make the ir work, I will also have to set up NAT and
iptables on CPU side.

--
Mark
From: David Brown on
On 25/06/2010 05:29, Mark wrote:
> There was perhaps misunderstanding on both sides, so I've drawn a
> small picture at http://www.imagehousing.com/image/493175 describing
> the architecture of the device.
>
> Port 0 is WAN, port 1 is for LAN of internal switch are fixed, port 5
> internal MII to CPU, other ports will not be used. Ports A and B of
> the managed 24-port switch are fixed and wired to port 0 and 1
> respectively.
>
> So, there will be two VLAN groups on the managed switch:
>
> SwitchGroup 1 - port A.... for WAN
> SwitchGroup 2 - port B... for LAN
>
> (such are the requirements). On the other hand, the CPU will have two
> vlan groups:
>
> Group 1 - port 0& 5 (wan)
> Group 2 - port 1& 5 (lan)
>
> These groups on CPU are managed and created by the Ethernet driver, so
> they are not visible to OS. As you suggested, I should use, for
> example, vconfig tool to create two vlan interfaces:
>
> eth0.vlan1 (wan)
> eth0.vlan2 (lan)
>
> where the underlying interface is only eth0.
>
> Does it look fine now ?
>
> PS. And to make the ir work, I will also have to set up NAT and
> iptables on CPU side.
>

OK, I think I see what you are doing now. And it looks like you are
trying to do double the work.

Here is how I would arrange things:

On the external managed switch, set up a VLAN for the WAN group (say,
VLAN 1). You probably only need a single port in that group - set that
port to untagged VLAN 1.

Set up a second VLAN (say VLAN 2) for the LAN group. Put as many ports
as you want on that group, all untagged.

Have one port (such as "A") on the switch in both VLAN 1 and VLAN 2, set
for tagged packets. This port is connected to a single port on the
broadcom device.

Don't use the broadcom switch at all. All the packets coming in to the
ethernet port are already tagged as VLAN 1 or VLAN 2. In your Linux
setup, simply set up two virtual ethernet ports eth0.1 and eth0.2 -
these are your WAN and LAN interfaces.

That way you have full separation of the two networks, and full control
(at the external switch) of which ports are on which networks. On the
Linux side, you can use NAT, iptables, and whatever between these two
interfaces.

This saves all the effort in configuring the broadcom switch. And if
you ever want to make more isolated LANs, you just make a new VLAN group
on the managed switch and a new virtual ethernet port on the router.
You can also use tagged trunks to let you split up the VLANs further up
the line if you want.

If you are dealing with a PHB that says there must be two cables from
the managed switch to your box, with LAN traffic on one and WAN traffic
on the other, then set port A on the switch to tagged packets VLAN 1,
and port B on the switch to tagged packets VLAN 2. Connect both to the
broadcom switch, but leave the switch as unmanaged so that the tags all
pass through to your Linux kernel.
From: Mark on
David, thank you very much for this suggestion, it looks simpler and
more obvious. Just to make sure I got what you suggest:

(1) VLAN group 1 (untagged) on the external switch - port A + any
portwhich will serve as WAN port.
(2) VLAN group2 (untagged) on the external switch - port A + as many
ports as I want to be included in LAN group
(3) Port A is set tagged (for example, if a frame arrives a port of
group 1 it will leave the group as tagged with vlan1; if the frame
arrives group 2, them it leaves the group 2 tagged with vlan2 -- I
believe that is correct?)
(4) I need only *one* port connecting Broadcom to the ext. switch.

The one fundemantal question remained though:
- any intelligent switch processes incoming frames according to
forwarding and VLAN tables; but why do you always mention of tagged
frames? As far as I can understand the 802.1q standard, a switch not
necessary has to tag all incoming packets, it may have some other
associative rules to apply to the packets.

--
Mark
From: David Brown on
Mark wrote:
> David, thank you very much for this suggestion, it looks simpler and
> more obvious. Just to make sure I got what you suggest:
>
> (1) VLAN group 1 (untagged) on the external switch - port A + any
> portwhich will serve as WAN port.
> (2) VLAN group2 (untagged) on the external switch - port A + as many
> ports as I want to be included in LAN group
> (3) Port A is set tagged (for example, if a frame arrives a port of
> group 1 it will leave the group as tagged with vlan1; if the frame
> arrives group 2, them it leaves the group 2 tagged with vlan2 -- I
> believe that is correct?)
> (4) I need only *one* port connecting Broadcom to the ext. switch.
>
> The one fundemantal question remained though:
> - any intelligent switch processes incoming frames according to
> forwarding and VLAN tables; but why do you always mention of tagged
> frames? As far as I can understand the 802.1q standard, a switch not
> necessary has to tag all incoming packets, it may have some other
> associative rules to apply to the packets.
>

There are various ways to tag and untag packets with their VLAN numbers,
and various ways to associate packets with different VLANs. People use
them to join disjoint networks as one logical network, or to split up
high priority traffic from other traffic, amongst many other uses.

I prefer to keep them simple, and stick to port-based tagging - I find
it easy to visualise, and thus easy to work with. I use the managed
switch and VLANs to give the Linux server/router multiple virtual
ethernet ports.

The trick is to make each port on the managed switch into either an
untagged port on a single VLAN, or a tagged port on multiple VLANs for
trunking. Trunk ports are only ever connected to trunk ports on other
switches, or a port on a Linux box configured with virtual ethernet
ports to match the VLANs. This way traffic on a port is either untagged
and on a specific VLAN, or tagged and carrying multiple VLANs, which can
be split up later by another switch or by a Linux box.