Prev: Netfilter clarification
Next: Connecting via ssh from machines on different subnets
From: David Schwartz on 24 Jun 2010 01:43
On Jun 23, 7:35 pm, "Mark" <mark_cruzNOTFORS...(a)hotmail.com> wrote:

> I can't see how it would happen: I'm not disabling switching function,
> neither do I disable VLAN grouping, i.e. any frame entering a switch port
> would be switched in hardware according to the forwarding table.

I thought you wanted to present them as five separate interfaces. If
you do that, how can you also have the hardware switch packets between
them?

> So as I
> understand, as long as I don't assign IP address on those interfaces,
> everything should work as before; assigning IP addresses will imply NAT on
> those interfaces.

Huh? How did NAT get into this?

If you think that just having two operational interfaces with no
addresses assigned to them implements some kind of switching or
bridging, you are mistaken.

Perhaps I'm misunderstanding you, but it sounds like you don't really
understand the basics about specifically what a network interface
driver does.

DS
From: Mark on 24 Jun 2010 02:09
David Schwartz wrote:
> I thought you wanted to present them as five separate interfaces. If
> you do that, how can you also have the hardware switch packets between
> them?


As I wrote earlier to Pascal in this thread, I will basically have 2
internal ports connected to external 24-port switch, and I need these two
ports configured as WAN and LAN interfaces. I thought the easiest way would
be have the seperate interfaces.

Hm.. now I'm very confused.

> If you think that just having two operational interfaces with no
> addresses assigned to them implements some kind of switching or
> bridging, you are mistaken.
I don't really understand this point -- if a packet enters the switch,
before it gets any network interface (eth0..eth4) it is supposed to be
already hardware switched, unless the switch is configured to forward all
frames to the CPU port (in this case it will be processed by the network
driver).

> Perhaps I'm misunderstanding you, but it sounds like you don't really
> understand the basics about specifically what a network interface
> driver does.
That's why I'm here, asking the questions.

--
Mark

From: Mark on 24 Jun 2010 02:53
David Schwartz wrote:
[skip]
> Perhaps I'm misunderstanding you, but it sounds like you don't really
> understand the basics about specifically what a network interface
> driver does.

Allright, let's reason about this once again. Suupose we have 5 distinct
network interfaces, eth0 is for switch port 0, eth1 - port 1 and so on. Now,
a frame enters the port 0, the driver picks the frame off the switch and
pushes it up the network stack, so in this case all switching/tagging is
done in driver or in higher OS layer.

Am I right, is that what you meant ?

On the other hand -- consider the 5-port switch and the driver representing
single interface to OS (that single interface is the one connecting the
switch to CPU), that's how it's implemented now. Any frame entering the
switch port is hardware switched and if necessary (depending on the switch
configuration) is also forwarded to the CPU port and will be accepted by the
driver and moved, if necessary, up the tcp/ip stack.

--
Mark

From: David Brown on 24 Jun 2010 03:17
On 24/06/2010 08:09, Mark wrote:
> David Schwartz wrote:
>> I thought you wanted to present them as five separate interfaces. If
>> you do that, how can you also have the hardware switch packets between
>> them?
>
>
> As I wrote earlier to Pascal in this thread, I will basically have 2
> internal ports connected to external 24-port switch, and I need these
> two ports configured as WAN and LAN interfaces. I thought the easiest
> way would be have the seperate interfaces.
>

This will work fine. I think perhaps David missed the other post where
you mentioned the external 24-port switches.

Most small or medium routers work in this way, using VLAN tags to get
multiple virtual Ethernet devices from the managed switch. The
disadvantage is, as David says, that you can't then pass VLAN tagged
packets through the router. But that's okay - if you have such a large
and advanced network that you are wanting to pass VLAN tagged packets
here then you would probably have faster and more advanced hardware anyway.

I haven't used these Broadcom devices on their own, but I use LinkSys
routers with similar devices and OpenWRT firmware. Using the VLAN
tagging on the built-in switch gives you enormous flexibility - far more
than you get with the original firmware.

If you can't make use of the switch driver code from tomoyo, you could
look at openwrt and see if you can use the code from there (although I
believe the two projects have a common ancestor, so the code there may
be the same).

> Hm.. now I'm very confused.
>
>> If you think that just having two operational interfaces with no
>> addresses assigned to them implements some kind of switching or
>> bridging, you are mistaken.
> I don't really understand this point -- if a packet enters the switch,
> before it gets any network interface (eth0..eth4) it is supposed to be
> already hardware switched, unless the switch is configured to forward
> all frames to the CPU port (in this case it will be processed by the
> network driver).
>

The external switches will handle switching within their local network.
Packets aimed off the network will be passed on to your device
(assuming you have the routing and addresses configured correctly). But
your two virtual ports eth0.1 and eth0.2 on your device need an ip
address so that machines on the network can pass packets to them for
forwarding.

It /is/ possible to set up your device as a bridge between eth0.1 and
eth0.2 rather than a router, with no IP addresses on the ports, but
unless you are doing something really advanced (such as using ebtables
to control the bridge), a patch wire between the two 24-port switches
would be more efficient.

>> Perhaps I'm misunderstanding you, but it sounds like you don't really
>> understand the basics about specifically what a network interface
>> driver does.
> That's why I'm here, asking the questions.
>

From: David Schwartz on 24 Jun 2010 06:41
On Jun 23, 11:53 pm, "Mark" <mark_cruzNOTFORS...(a)hotmail.com> wrote:

> Allright, let's reason about this once again.  Suupose we have 5 distinct
> network interfaces, eth0 is for switch port 0, eth1 - port 1 and so on. Now,
> a frame enters the port 0, the driver picks the frame off the switch and
> pushes it up the network stack, so in this case all switching/tagging is
> done in driver or in higher OS layer.
>
> Am I right, is that what you meant ?

Right, but the hardware switch has no way to do this other than
tagging the packet with a VLAN when it comes in and stripping that
VLAN off to decide which of the five distinct interfaces to pretend it
received the packet on. If you do this, you will be unable to support
VLAN tagging because you will be using VLAN tagging to make the switch
look like distinct interfaces when it's actually only one switch.

> On the other hand -- consider the 5-port switch and the driver representing
> single interface to OS (that single interface is the one connecting the
> switch to CPU), that's how it's implemented now. Any frame entering the
> switch port is hardware switched and if necessary (depending on the switch
> configuration) is also forwarded to the CPU port and will be accepted by the
> driver and moved, if necessary, up the tcp/ip stack.

Right, which enables the switch to act like a switch. It also enables
you to set ports to not have their VLAN tags modified, allowing the
operating system to support VLAN tagging.

Suppose the switch receives a packet on physical port one. How will
you be able to make that packet appear to have been received on
interface one if you don't set the physical port to tag the packet?
And if you do set the physical port to tag the packet, how can you
support VLAN tagging? (You can either use VLAN tagging to make VLANs
or to make five interfaces, but I don't see how you can do both.)

DS
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Netfilter clarification
Next: Connecting via ssh from machines on different subnets