Re: DHCP and multiple netsegments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- ----- Original Message ----- 
From: MONZ <monz@danbbs.dk>
To: Chris Knipe <cgknipe@mweb.co.za>
Cc: linux-net <linux-net@vger.kernel.org>
Sent: Thursday, October 19, 2000 6:42 PM
Subject: Re: DHCP and multiple netsegments


> > There is however options you can specify in your DHCP scope to 1)
> > force all clients to ALWAYS use the default gateway for routing,
> > and 2) you can force a broadcast address to be used, which means
> > that you will be able to perhaps minimise the mess of broadcasts
> > :)
 
> Sometimes I can get a connection from a client through the
> firewall/router, especially immidiately after rebooting the
> firewall. Shortly after, I get no replies, or it takes an immensely
> long time.  

I've experianced similar things aswell a few years back when I had a
simple redhat 5.0 boxlette assigning DHCP IPs to Windows 98....  You
have to understand two things.... 1) Windows is *VERY* fuzzy about
DHCP from Linux for some reason.  A simple version change in the
drivers of the Windows machine and (in my case) the entire thing
bombed out...   Secondly, as you mentioned below, your
255.255.255.255 routes *can* very well influence routing allot
aswell... 

Have you tried running without the 255.255.255.255 routes?  I've got
it working a few times without the route...  However, as I mentioned,
it was a tad buggy... 
 
> I can ping any interface, but not all traceroute's goes through.
> Unfortunately, my customer closes early, so I didn't have time to
> script tcpdumps, but from what I remember, I saw some 10.12.255.255
> broadcasts on a 10.12.0.0 segment.

Hmmm, can you perhaps show me some examples where ping works and
traceroute doens't?  This is very weird in my books... As to the
broadcasts...  10.x.x.x = Class A IP addresses...  Those broadcasts
are right to be on any IP address in the 10.x.x.x range if you use
the entire subnet (255.0.0.0)

> Now I have the feeling that those 255.255.255.255 routes nessesary
> for dhcp and dhcrelay to work, are mixing up normal broadcasts; not
> an expert on the subject, though.

It can...  As I mentioned to you previously..  I have not worked with
DHCP Relay, so perhaps you might not need the 255.255.255.255 route
anymore...  Give it a try and see what happens :)
 
> As you said, I can force specific broadcasts; true, but this will
> only work _after_ the client gets its config, right? M$ clients
> still need that 4x255 route to locate the dhcp-server. Didn't have
> time to test this either.

Technically, it shouldn't need to "locate" the DHCP server.  That's
why it uses a broadcast to ask for a IP address.  What I am thinking
right now, is that it perhaps is trying to locate a name server (yes,
this is microsoft's way of doing it).  MS will broadcast x.255 in an
attempt to try and locate anything.  Even if you send a ping packet
to a host not in ARP cache, it will send a broadcast to locate the
NIC and save the entry to its ARP... 

What I will suggest to you here, is to use NT's Network Monitor
application (if you have a NT machine), and make a dump of that and
see what is going on there.  The one nice part about Network Monitor
is that it will describe the packets it captures, and you will
immediately see where the packets come from, where it is going, and
for what REASON the packet was sent.  (It will for instance tell you
that "look listen, I sent this packet to locate a IP address not in
my ARP cache", or "This packet is designated for NS QUERY A - a DNS
Lookup on a A Record), and so forth... 

Also, as far as I know, the DHCP assigns the entire configuration to
the client in one go.  The client's broadcast packet will be at every
machine that is connected to the same wire, and in the case of a DHCP
Relay, the broadcast should also be forwareded to every wire the
relay is configured for.  So, your "Client Request" will be at any
machine located on any wire, connected to your DHCP Relay - Anothing
thing you can perhaps look into with tcpdump, see where what
information goes to... 

> I do specify a router on each segment, i.e. 10.13.0.1 for a
> 10.13.0.0 net:

Hmmm, it *may* be because of this that the windows machines is going
a bit crazy about the broadcasts.  Two things to check...  Is the IP
in the machine's ARP cache after it got a IP address (arp -a on
Windows)....  Also, whether the gateway is actually reachable.  Also
have a look at 'route print' and 'ipconfig' to check the IP
configuration received from the DHCP servers... 
 
> subnet 10.13.0.0 netmask 255.255.0.0 {
>     default-lease-time 86400;  # One day
>     max-lease-time 604800;  # seven days
>     option subnet-mask 255.255.0.0;
>     option routers 10.13.0.1;
>     range 10.13.0.10 10.13.0.250;

You'll have to do a bit more than this...  Some of the options arn't
standard on Linux DHCP server implementations, and therefor you need
to configure the options manually...  The options which should
interest you (aswell as those you allready have):

- - All subnets are local
- - Always use Default Gateway

Those are options from NT's DHCP server...  But if you can locate the
option numbers (or the value they carry as DHCP options - HEX Number
I believe), you will be able to configure this with Linux aswell... 
I'll have a look later, perhaps install DHCP on my NT quickly, and
see if I can get the values for you.  

I hope it helps... 

- ---
Regards,
Chris Knipe
Cell: (083) 430-8151


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBOe8jOdH4faKoc4EuEQJxUQCfZ+O5u5zvLIwrprkgzyYW7l5IarAAoNyL
/JIGY+PXVccWncqTohaSQIj8
=PDBE
-----END PGP SIGNATURE-----


-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org


[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux