[K12OSN] DHCP and PXE with two different Class of IP address

[Bert Rolston]

Thanks John,

The fact is THEY ARE having problems on the network. Their Exchange
server was misbehaving today.

I will insist they have ALL other problems on their network resolved
BEFORE the K12LTSP server is installed. And I will be insisting on GOOD
server grade hardware.

This site had a Samba server that was installed on old hardware, with
command line only administration. After the tech that set it up moved to
a new job a hard drive failed. People blamed Linux and said it wasn't up
to the job.

I've seen one installation on another site removed because LINUX was
blamed for network problems. The culprit was a Win95 proxy server with a
failing hard drive. 

But back to the question.

So what you were saying earlier is that on the K12LTSP server I set up
	- 1 NIC with a Class B address that matches their scheme, 
	  connected to their physical media
	- 1 NIC with the standard K12LTSP Class C scheme connected to 
	  the same physical media, through the same switch

This should satisfy my customer's criteria.

What will the MS DHCP server do when a PXE request comes from the old
hardware?

I may be answering my own question, as I understand things MS DHCP will
ignore the request. Is that the case?

As for the LTSP DHCP server, I take it I can tell it to IGNORE any DHCP
requests from a host with an MS operating system.

Thanks for your time.

Cheers,
Bert

On Thu, 2006-12-07 at 22:18 -0400, John Lucas wrote:
> Well you should be able to set up the LTSP server as a NAT firewall through 
> IPTables, or use a hardware NAT firewall in front of the server; that way you 
> can hide the terminals behind the server's IP address and still make no 
> changes to the rest of the network, while still enabling you to run your own 
> DHCP server for the terminals. 
> 
> BTW, a single net class B means that *all* hosts are in the same broadcast 
> domain. If you have over 250 hosts on that net, that is a lot of broadcast 
> traffic, one chattering NIC and the entire net feels the pain. I wouldn't 
> want to be a network support tech on that net if anything goes wrong; that 
> isn't the most robust net design. A netmask of 20 bits would allow 16 subnets 
> of 1024 hosts each and allow sub-dividing the broadcast domain and isolate 
> traffic behind routers (as well as allow special subnets like yours without 
> resorting to NAT).
> 
> On Thursday 07 December 2006 16:44, Bert Rolston wrote:
> > Hi John,
> >
> > Thanks for your reply.
> >
> > The reason they went to a Class B scheme was to overcome the 254 host
> > limit.
> >
> > They are using a /16 subnet mask.
> >
> > The network in question is at a small tertiary educational
> > establishment. It provides courses in business studies ( 1 lab),
> > animation ( 2 labs), certificate in television production, christian
> > ministry and counselling courses. Also running on the same network are
> > campus admin, a small regional TV station, TV production and marketing
> > company, an animation studio with render farm.
> >
> > Thanks for your time,
> > Bert
> >
> > On Thu, 2006-12-07 at 12:54 -0400, John Lucas wrote:
> > > You mentioned that the current network is using a class B address scheme,
> > > but is that address space sub-divided? What netmask is being used?
> > >
> > > Almost no one with a class B uses the 16-bit netmask; use of a 24-bit
> > > netmask divides the single network into up, to 254 subnets of up to 254
> > > hosts each (a more useful scheme). Assuming that a 24-bit (or larger)
> > > netmask *is* being used, how about creating a new private (class-C sized)
> > > subnet on one NIC in an LTSP server, and have another NIC attached to the
> > > existing network? This allows the terminals to use
> > > DHCP/tftp/PXE/etherboot from the LTSP server and still access the MS
> > > Terminal server (using rdesktop) without changing the existing network
> > > (save for the addition of the new LTSP server and it's terminals). In
> > > this scenario the LTSP server could be used as a router (for terminals
> > > running rdesktop sessions), or as a dual-homed host (running rdesktop
> > > from the LTSP server itself).
> > >
> > > My choice would be to run rdesktop on the terminal (via the SCREEN_x
> > > directive in lts.conf). This allows sound to be re-directed from the MS
> > > TC to the terminal and preseves the ability to run Linux on the LTSP
> > > server (via a separate SCREEN_x directive). Thin clients are far simpler
> > > to maintain than stand-alone PCs.
> > >
> > > On Thursday 07 December 2006 00:58, you wrote:
> > > > Hey folks,
> > > >
> > > > I know this little chestnut has been chewed over many times on this
> > > > list. I don't remember my situation coming up. So first I'll describe
> > > > the environment.
> > > >
> > > > =======================
> > > > The current environment
> > > > =======================
> > > >
> > > > An MS Network with AD, terminal server and MS DHCP server with CLASS B
> > > > IP address scheme.
> > > >
> > > > They want to revitalise their old Win 9x / NT machines and are
> > > > investigating using K12LTSP or locally installed Linux. They have a lot
> > > > of old classic to PII Pentiums which are gathering dust.
> > > >
> > > > One option is to boot the LTSP terminals in kiosk mode to access their
> > > > Windows Terminal server using the RDP client included.
> > > >
> > > > The other option is to install a lightweight Linux distro (Puppy or
> > > > DSL) on all the machines and use the RDP client that way.
> > > >
> > > > They don't want to change their existing infrastructure if at all
> > > > possible. Even making changes to their DHCP server is considered risky
> > > > by the network admin. ANY adverse impact on their existing system is
> > > > unacceptable.
> > > >
> > > > The network admin uses Ubuntu at home, but has been unable to get any
> > > > Linux computer to authenticate to the AD at work.
> > > > For that reason he only sees limited potential for Linux / OSS in their
> > > > current environment.
> > > >
> > > > Users will authenticate to their AD through Windows terminal sessions.
> > > >
> > > > Later on they may enable access to the Linux desktop and apps.
> > > >
> > > >
> > > > =======================
> > > > My Question
> > > > =======================
> > > >
> > > > Given that the current DHCP server issues Class B addresses.
> > > >
> > > > Can the K12LTSP DHCP server, which issues Class C addresses
> > > > 	- co-exist on the same physical media
> > > > 	- handle PXE requests from the old hardware,
> > > > 	- and not interfere with their current setup?
> > > >
> > > > If so what changes (if any) need to be made
> > > > 	- on the MS DHCP server,
> > > > 	- their current setup
> > > > 	- the K12LTSP server
> > > >
> > > > Thanks,
> > > > Bert
> > > >
> > > > _______________________________________________
> > > > K12OSN mailing list
> > > > K12OSN at redhat.com
> > > > https://www.redhat.com/mailman/listinfo/k12osn
> > > > For more info see <http://www.k12os.org>
>