Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
the only way a client is going to get an ip from the wrong subnet is if they are on that wrong subnet physically. How are your subnets seperated? you'd need separate switches / full 802.1q tagging, not interface aliasing etc... Is that what's happening? You've not explained what you really mean by a "guest ip". that is the other subnet, right?
A DCHP request is a broadcast and has the source ip address set as 0.0.0.0. The DHCP server with multiple scopes needs to be able to figure out which scope to assign from. In the case of a server with two separate broadcast domain connections, i.e separate physical nics or as mentioned a tagged interface, these broadcasts are received separately by the interface that already has an address of the network concerned. i.e. If server eth0 has and IP of 184.108.40.206 255.255.255.0 and it receives a DHCP request, it can "fill in the blanks" by assuming a source address of 1.1.1.x and assign an address from that pool.
If you have two IPs bound to the same interface, then both subnets share the same broadcast domain. When the DHCP request is received, it is received by a broadcast domain that both subnets are sharing. The server has no way of identifying or even infering which DHCP pool the request should be associated with. So typically it just picks the first one configured.
wimnat, http://pastebin.com/m5d223aaa is broken: "Unknown post id, it may have expired or been deleted" -- please repost somewhere permanent. LQ is supposed to a archive of answers & this thread makes less sense w/o the orig. dhcpd.conf that was referenced.
Q: Should LQ have its own pastebin?
Members only, tied to a forum, blog, or other post; & as permanent as the items that reference it.
Isn't there a limit on the # of files each of us can attach? I just clicked the "Manage Attachments" button, & greeted w/:
"Sum of all attachments owned by archtoad6: 575.9 KB"
above a slightly ominous red & green bar that seems to indicate that I am a little over half my quota.
Just now I revisited my User Control Panel & noticed the Attachments link under Miscellaneous. This opens w/
"You are currently using 575.9 KB to store 5 uploaded attachments."
above the same red/green bar which I believe represents 575.9 KB used out of a 1,000 or 1,024 KB quota. With a quota I can't keep adding things indefinitely -- I'll eventually have to delete something(s). That is not permanent, & does not solve the need for an LQ pastebin for long code blocks, like config files & scripts.
As we both know, one of the goals of LQ is to be a permanent archive of knowledge, so if we want to unclutter threads by moving long code blocks elsewhere, the elsewhere has to be as permanent as the referencing post.