From: David Schwartz on 24 Jun 2010 17:39 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 24 Jun 2010 23:29 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 25 Jun 2010 05:26 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 26 Jun 2010 23:56 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 27 Jun 2010 05:44 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.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Netfilter clarification Next: Connecting via ssh from machines on different subnets |