Messages in this thread | | | Date | Thu, 22 Oct 1998 10:01:48 -0500 (CDT) | From | Mark Spencer <> | Subject | Re: NADS for Linux |
| |
> 1. when there is already a switched network architecture in place, by > making the server appear in multiple (possibly all) branches of the > switch-separated network.
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/
| |