OT-hijacked. . .Re: [K12OSN] Solving the bandwidth bottleneck

[Les Mikesell]

On Wed, 2005-05-11 at 07:19, Doug Simpson wrote:
> >
> >Usually that is something you want to avoid.  You can overlay
> >different subnet ranges on the same wire - it's ugly but it works.
> >What people are saying is a bad idea is to connect 2 nics from
> >the same machine onto that network. 
> >  
> >
> But unless you want to run two completely different networks (physical 
> plant wiring) all over the campus, to 5 buildings and 150 rooms . . .

With the k12ltsp 2-nic scheme, only the 'outside' NIC needs to be
connected to the main backbone.  Clients only connect to their
local server's 'inside' nic.  This works fine for dual-booted
pc's as well, since the server acts as a NAT router for anything
on the private side.

> >If you really want a public address on the printer, let something
> >route your private addresses there.
> >
> It has a public IP because our state-wide comouter network, used for 
> student data dna administration, printe through local printers, and 
> therefore, requires publicly available IP number (we have many of such 
> units.)

Neither the k12ltsp server nor clients behind it on the private side
would have any trouble reaching printers or anything else on the public
net.

> >
> The state-wide network requests that computers that access it for 
> administration and student data have public IP numbers for 
> troubleshooting efficiency. I do have some that are on private IPs and 
> they work fine, too though.

They would appear to come from the k12ltsp server if you let it NAT.
In the case of thin clients, the program really would be running
there.  If you boot into a local OS with a private IP, you still
appear to the rest of the world as the public IP of the k12ltsp server.

However, there is nothing magic about using private IP's and NAT.  If
you have the public addresses to waste on dual-booting clients you
could assign them via dhcp and do normal routing instead of NAT to
the rest of the world.

> >
> All of the public IP addresses are assigned, and nearly all of the 
> private numbers are DHCP.  There are a few, like lab servers and private 
> printers that have private numbers assigned.
> 
> This has been working seemingly flawlessly for 4 years, with over 700 
> computers connected. . .  It may be wrong, but I don't have much trouble 
> with it. . .

The only problem I would anticipate would be if you ever want to
add a separate DHCP server on the public side.  With overlaid subnets
there is no way to distinguish which DHCP range any client should get.

> It is nice because it don't matter what kind of device I am connecting, 
> a public printer, private workstation, private server, private printer, 
> LTSP terminal, public workstation, whatever, I can connect it and it 
> just works, all on the same wire. . .

But you don't have much control over bandwidth on any of the network
segments with this topology.  If all of the switch interconnects are
gigabit you might not need to care but you won't like it if you end
up running more than 30 or so thin clients across one 100M connection.
If you really only want a single network and have appropriate bandwidth,
I'd switch the k12ltsp scheme to use a single nic and a public dhcp
range. 

A compromise is to set up VLANs on your switches. This still requires
enough bandwidth to carry everything on the switch trunk connections
but you can set up what appear to be physically isolated subnets with
only a single wire connecting the switches.

-- 
  Les Mikesell
   les at futuresource.com