[nSLUG] Fwd: ISC dhcpd on Linux and Novell...uh...stuff.

Soren Aalto soren.aalto at gmail.com
Sun Oct 23 09:31:17 ADT 2005


OK...I promise not to complain about our "vendor" (a promise I
will now proceed to break...).

Have any of you used dhcpd on Linux/unix in an environment
where you have to serve Novell NDS type options to clients?
>From what I can deduce, the Novell & desktop people want
dhcpd to supply the NDS tree name and also the IP address
of an SLP server to clients...so that the Novell client on the
WinXP machines can (i) have the right tree in the login
box selected by default, and (ii) all the "lookup stuff" boxes
(trees, contexts, and...uh, something else) work as they
have an SLP server to ask.  (*is* it an SLP server that we
need?  *I* don't know, because I don't know Novell, and
the Novell guys don't know, because, they're, uh, Novell
guys)

The Novell guys are cross -- because stuff used to work
and it doesn't in the new network.  My educated guess
is that in our old networks, the SLP broadcasts used to
work because everybody was in the same layer-2 domain
(i.e. VLAN) on our network.  And maybe because they were
using IPX as well on the old network...where IPX routers
do things like SLP forwarding into the other VLANs where
our student labs lived...I'm sure I don't know, I just remember
having to stick magic IPX network numbers in our VLAN
configs on the Cisco route-switch-module.

Anyway, now our network puts everybody in separate
zones that need to cross layer-3 routers (redundant 3750s
in every zone)...the server farm is in one zone, and each "building"
is in a different zone, so broadcast traffic doesn't leak accross
the backbone connecting it all.

And nobody explained any of this to me till about yesterday, but
the vendor's proj managers have been told repeatedly that this is
because DNS and DHCP don't work (because apparently DNS and/or
DHCP are supposed to "broadcast" SLP information or
some such gibberish).

(the other worry I have -- has anybody's head ever exploded
from having to deal with these sorts of folk?)

I just want to know if there's anything I have to watch out
for -- I've found the relevant DHCP options, nds-tree-name
and slp-directory-agent)...again, guessing
what they need.

But I get about 20 minutes on Monday morning to make
this work, otherwise they're going to get a Windows box to
run DHCP because they know that works at other sites.  They
really want to stick in a Windows box and are anxious for
me to fail at this.

I set the options in our DHCP server -- and it seems that
they only get set in responses to new lease requests.
Most dhcp responses I watched in tcpdump did not have
the options set (although they were global options in the
config file), but occasionally I could see a response packet
containing the options.  I'm guessing that you only see the
options if you request a new lease, but if you are renewing
an existing lease, then you won't see the options that I have
changed.  So I'm worried that the options
will be set, they'll test with a client that already has a long
lease & won't get the options sent & then bring in Windows
to save everybody.

...not that I think ISC dhcpd is all that great.  Actually, I
think it's a pain in the butt to configure and the config
file has a very fussy syntax.  But I don't know if anything
else is actually better...

The vendor's approach seems to be "ah, we don't
know this wierd stuff, let's replace it with { windows | cisco }."
Certainly our Linux firewalling stuff got tossed and replaced
by a PIX and our sendmail relays got replaced by...um, some
Trend crap on Windows which is actually also sendmail, but
nobody seems to know this.

(And GroupWise becomes the "corporate messaging standard",
with brilliantly opportunistic timing, if you read /.).

--
J2EE -- the Hamiltonian mechanics of webapp
development.

!DSPAM:435b8297121015010113069!




More information about the nSLUG mailing list