Yes, or before a switch network is in place, allowing, for example, more
extensive use of hubs and maybe no switches at all.
> 2. ultimately, to use the linux server itself as a switch (via the
> bridging code) to provide occasional communications between the
> separated clients, but still provide better connectivity to each
> of the local network branches.
Of course, this is already done, but be careful! Trying to use a linux
box as a switch *and* a host causes some unique problems -- exlpicitly
that the linux host only sees the machines on one side of the network.
Even in the Bridging FAQ, it explicitly discourages you from doing so.
> [suggestion about DNS]
> Probably not everything would work with this,
Certainly everything IP based wouldn't (dhcp, who your dns server is,
etc). But more fundamentally:
> Ok, so this requires subnetting, which NADS does not (plan to) need,
> but it might be more common than switched networks.
Exactly. If you're already subnetted, this isn't much of an issue, but
you're increasing somewhat the complexity of your network (if your network
is big enough, subnetting can be a headache), and you're necessitating
routing of some sort (even if it's through your server).
> since if you are a bridge, you are local to all connected clients, and
> you could even work as a hot backup switch.
Yes, and no. At least as of the bridging code I used last year, linux
forwards packets from one side to the other without looking at what their
IP address is (which is what a bridge *should* do. As a side effect
though, it is impossible to see the opposite interface from a given
network. So, your server still has to have two IP addresses (on different
networks) or static routes to all your hosts (doesn't this bypass the
whole point of bridging). It would be nice if your bridge automatically
knew where everybody was, but then you'd have NADS :)
> the current bridge code is a bit "hard coded", it could be shaped up
> quite a bit to multiple bridge groups,
Yes, this is an issue for me in another project for work. I was building
a network simulator, allowing you to plug in two hosts to its ethernet
ports, then set parameters like packet loss, packet reordering, latency,
etc etc and I had to use two computers instead of just one (although it
did work. it was unstable for some reason (c 2.1.76) because the
bridgiing code didn't seem to want to work with the netlink code) since I
couldn't build a separate bridge group for each interface. If I could
that would be wildly useful for me.
> In a real switch, even the send is being done concurrently while the
> rest of the packet is still coming in, and that sounds a nightmare to
> implement in a generic network server OS like Linux. Although a few
> years back, mingo thought about this, and he still might have code
> that could be used.
Well, it would seem to me that you could use the "fast routing" code to
implement this right? Surely it's easier to bridge than to route between
two interfaces! I don't know that it would be concurrently sending, but
it could be pretty dang close to that kind of performance!
Mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/