<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> One modification to Step 2, below. You will need to ensure that the hostnames are unique. I didn't point that out. So, while your /etc/hosts file might look like this: 192.168.0.1 ws001 192.168.0.2 ws002 and so on... I would tweak the hostnames to look like this, by adding a digit, like so: 192.168.0.1 ws0001 192.168.0.2 ws0002 192.168.4.1 ws4001 192.168.4.2 ws4002 See the difference? In this case, the first digit after the "ws" reflects the third octet of the subnet. That tells me very quickly which subnet a client is on, just by looking at the hostname. Could be handy for troubleshooting. Of course, you can use any scheme you want, as long as the hostnames remain unique. --TP <div class="moz-signature">_______________________________ Do you <a href="http://www.gnu.org">GNU</a>? <a href="http://www.cmosnetworks.com">Microsoft Free since 2003</a>--the ultimate antivirus protection! </div> Terrell Prudé Jr. wrote: <blockquote cite="mid:494BE3FB.4000204@cmosnetworks.com" type="cite"> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> This is exactly how I did the PPC/x86/SPARC K12LTSP server a while back, and yes, it would work wonderfully for your situation. Basically, you'd need to do this: 1.) Set up your third NIC for another client subnet (e. g. 192.168.4.0/24), and hook 'er up to that switch. 2.) Modify /etc/hosts to include host entries for the 192.168.4.0 range, just like the ones for 192.168.0.0 are today. 3.) Create a second DHCP scope in your /etc/dhcpd.conf file. I just copied the info from the first scope, changing "192.168.0" to "192.168.4". Since all the clients are x86 in your case, you don't need to change any directory path info (just keep using /opt/ltsp/i386). 4.) TRIPLE-CHECK THAT YOUR THIRD NIC IS PLUGGED INTO THE RIGHT SWITCH! You don't want to be handing out LTSP client addresses to the main LAN. That would be bad. 5.) Restart DHCPD and try booting a client. And you're right, 802.1q is indeed VLANs, and yes, it would work if you had the hardware. But then you run into a scalability problem. I'm assuming that the interfaces on your server are Gig-E or lower (Ten Gig-E is still very expensive). Thus, it's not too hard to put enough clients on a LAN segment to saturate that Gig-E line. Fifteen simultaneous TuxType sessions will do it, as would anything else with lots of screen updates (e. g. video streaming or ChildsPlay). Using that second NIC will give you the bandwidth needed to support that second set of clients in the other room. Note that this is not channel-bonding. This is just good ol' fashioned separate interfaces on separate broadcast domains. There doesn't seem to be any need to channel-bond here. --TP <div class="moz-signature">_______________________________ Do you <a moz-do-not-send="true" href="http://www.gnu.org">GNU</a>? <a moz-do-not-send="true" href="http://www.cmosnetworks.com">Microsoft Free since 2003</a>--the ultimate antivirus protection! </div> Joseph Bishay wrote: <blockquote cite="mid:ba50840812190756p3bb186ffo478772e888002db6@mail.gmail.com" type="cite"> <pre wrap="">Hello, 802.1q, or as I understand it -- VLANS -- would also do the same idea so to speak. The issue is the hardware. We don't have anything that is capable of doing VLANS. I thought since this isn't the case of a large single network that I'm trying to break up into two smaller virtual networks, but rather two distinct rooms that are coming together, I could use the 2 NICs to resolve it? Joseph On Fri, Dec 19, 2008 at 8:20 AM, Paul VanGundy <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:pvangundy@bradfordnetworks.com"><pvangundy@bradfordnetworks.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Joseph, Would 802.1q be a better solution instead of having two cards to separate two environments and a third NIC to act as your access to the outside world? /paul On Fri, Dec 19, 2008 at 12:30 AM, Joseph Bishay <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:joseph.bishay@gmail.com"><joseph.bishay@gmail.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Hello, How are you? I hope you are all doing well. I figure after lurking for a while it was time to get all my questions out. :) It ends up that our new LTSP network has two groups of clients (currently existing LTSP room A and a new room of thin clients in room B). Each room has a switch. There are 2 cables that then run from room A and B to a common server room where the LTSP server is. Originally the LTSP server was in room A serving only that room. Our LTSP server has 3 network cards. Currently one of those cards is not active. The second NIC plugs into the switch for the thin clients and the last NIC plugs into the router for Internet access. How do I activate that 3rd NIC card as a second thin client card? That way NIC A serves room A and NIC B serves room B and NIC C access the internet for room A & B? I wasn't able to search for this because I didn't know what this process was called -- I didn't think it was network bonding. Thank you. Joseph _______________________________________________ K12OSN mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:K12OSN@redhat.com">K12OSN@redhat.com</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</a> For more info see <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="http://www.k12os.org"><http://www.k12os.org></a> </pre> </blockquote> <pre wrap=""> -- Paul VanGundy Senior Network Engineer BRADFORD NETWORKS Toll Free: 1-866-990-3799 Office: 1-603-717-9361 Fax: 1-603-228-6420 SC Magazine "Innovator of the Year" 2007 & 2008 NOTICE REGARDING CONFIDENTIAL COMMUNICATION: The information in this electronic message is confidential and may be privileged, and is intended only for the recipient(s) listed above. If you are neither the intended recipient(s) nor a person responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any use, dissemination, distribution or reproduction of this communication is strictly prohibited. If you have received this communication in error, please immediately notify Bradford Networks, Inc. at (603) 228-5300. Thank you. _______________________________________________ K12OSN mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:K12OSN@redhat.com">K12OSN@redhat.com</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</a> For more info see <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="http://www.k12os.org"><http://www.k12os.org></a> </pre> </blockquote> <pre wrap=""> _______________________________________________ K12OSN mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:K12OSN@redhat.com">K12OSN@redhat.com</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</a> For more info see <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="http://www.k12os.org"><http://www.k12os.org></a> </pre> </blockquote> <pre wrap=""> <hr size="4" width="90%"> _______________________________________________ K12OSN mailing list <a class="moz-txt-link-abbreviated" href="mailto:K12OSN@redhat.com">K12OSN@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</a> For more info see <a class="moz-txt-link-rfc2396E" href="http://www.k12os.org"><http://www.k12os.org></a></pre> </blockquote> </body> </html>