Subject: Re: thanks for the terminal room!

From: Steve Bellovin <[email-masked]>
Date: Thu, 17 Dec 1998 07:35:35 -0500

In message <v0410360fb29e877517f7@[192.168.124.31]>, Patrik =?iso-8859-1?Q?F=E4
ltstr=F6m?= writes:
> At 17.17 -0500 98-12-16, Flanigan, Bill wrote:
> > Make that a platinum star, and also make it 10!
> 
> To get platinum, I would have liked a DHCP server which worked also 
> for non-Windows boxes.
> 
> Because of that, I only have them gold (and they get Gold because 
> everyone which had problem with DHCP promptly got fixed IP-addresses).

I was able to use ISC dhcp from my BSD/OS box; it worked just fine,
modulo a few instances where someone else started using my lease --
and I don't know if I should blame the client or the server for that.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 17 Dec 1998 13:47:55 +0100

> and I don't know if I should blame the client or the server for that.

It seems that the responses from the servers were kind of "very 
slow". I first thought that my Mac got garbage back (i.e. a 
169-network) but after checking the documentation from OpenTransport 
I see that at a timeout, OT.2x is allocating a private address space 
address to the interface so one can still run some internet service. 
I.e. the result was a timeout.

On a Windows box, one can easilly use "chkifconfgkzcvskjsd" or 
whatever the program was called ;-) to renew a lease, and easilly 
click renew several times until one got a response from the DHCP 
server.

A friend of mine using UNIX also had to try to get an IP-address 
several times until he got one.

For the Mac, I have not found that kind of tool which talks to OT 
directly and renews (or retries) when _I_ want.

What helped was though to eject and insert the PC-Card over and over 
again, to force OT to renew the lease every time (or to sleep/wakeup 
a couple of times). After a while, I got bored and asked for a fixed 
address instead.

    Patrik

P.S. If anyone knows of an OT2.x - aware tool which can fiddle with 
DHCP stuff, please let me know. Othervise I have to play with it over 
x-mas :-)

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 17 Dec 1998 13:47:55 +0100

Patrik

---

From: "Michael H. Warfield" <[email-masked]>
Date: Thu, 17 Dec 1998 09:13:17 -0500 (EST)

> and I don't know if I should blame the client or the server for that.

	I used the dhcpcd package in with RedHat Linux and it also worked
very well.  On a couple of occasions, I had to retry the address request
once or twice.  I wasn't sure if it was timeouts on dhcpcd or congestion
on the terminal room network.  From a few other remarks I've heard, it
sounds more likely the latter than the former.  Never had to retry more
than twice though and, once up, the network worked like a champ.  Didn't
run into any problems with others using my lease.  So I guess I got lucky?

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  [email-masked]
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

---

From: "Michael H. Warfield" <[email-masked]>
Date: Thu, 17 Dec 1998 09:13:17 -0500 (EST)

Mike

---

From: Daniel Senie <[email-masked]>
Date: Thu, 17 Dec 1998 09:21:15 -0500

> and I don't know if I should blame the client or the server for that.

Both client and server are to blame. The server either didn't respond,
or was slow, and so a client decided to use the address it had from the
last time it did get to talk to the server. There are a few solutions to
this:

1. Assign more IP address space to the DHCP pool. We had 3 class C
chunks for this
   pool, which is 759 addresses. Of those, I suspect the desktop systems
were
   using DHCP as well, reducing the count some. Let's say around 700
were really
   available. We had almost 2000 people present. I suspect more than
half had
   laptops, so we were oversubscribed to the address pool. DHCP deals
with this,
   but it's been my experience that the combination of NT server DHCP,
and
   Win95/98 clients don't deal as well with the server rolling over
addresses at
   high rate.

2. Use ISC DHCP for the server. Put a Linux box or BSD box in place to
handle
   that chore (it'd also be able to handle DNS and such).

3. Decrease the lease time. This probably requires #2, since decreasing
the lease
   time increases the server load. Lower lease times make sense if
address use
   is going to roll over frequently. Since many folks go to the terminal
room,
   connect up and pull their email, then go off to meetings, keeping the
lease
   alive for an hour is questionable. For those who do stay on, their
laptops
   will continue to renew the leases anyway. The only danger here is a
non-
   responding DHCP server, which would could lead to two users on the
same
   address again.

We had the same DHCP problems in Chicago and LA. Addresses were getting
reused by laptops due to non-responding DHCP server. On Windows laptops,
you get really good at using winipcfg to ensure your lease is current.

Another factor which may be affecting things some is increased use of
the wireless network. Those laptops on the wireless network are likely
to keep their leases longer than those using the terminal room, since
they're in more constant communication. The wireless is a big positive
for both users of that system and nonusers. Most folks who use the
wireless spend little time in the terminal room, leaving more hookups
available for those without wireless.

My only minor issue other than DHCP, is with printing. It'd be nice if
the printers were configured for Windows networking in such a way that
you didn't have to log into an NT domain. I believe it's possible to do
this, since I've been in environments where it worked, but most folks
don't do this. Changing network config, especially user name, creates
problems for some applications and thus is not a desirable approach. My
solution was to FTP files to the desktop machines and print from there.
I've used that method the last 3 IETFs, since each time I tried to go
the NT domain route something or other on my laptop blew up.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com

---

From: Daniel Senie <[email-masked]>
Date: Thu, 17 Dec 1998 09:21:15 -0500

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Dec 1998 09:27:21 -0500

> and I don't know if I should blame the client or the server for that.

Most likely the other person's client.   I'm not going to point
fingers here because I believe the offending clients have been fixed,
but I do know of one or more clients that have had problems keeping
leases beyond their time.

On that note, as the author of the Internet Software Consortium DHCP
server, I would like to formally volunteer to set up the ISC DHCP
server at any future meetings, if there is interest.   The ISC server
has been proven capable of handling demands much higher than those
imposed by an IETF terminal room, so I think it would be an excellent
choice for the terminal room.   Of course, I'm biased... :')

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Dec 1998 09:27:21 -0500

_MelloN_

---

From: "Perry E. Metzger" <[email-masked]>
Date: 17 Dec 1998 11:05:56 -0500

Patrik Fältström <[email-masked]> writes:
> slow".
[...]
> several times until he got one.

I had frequent problems with the DHCP service, but because I was using 
Ted's (ISC's) DHCP client, I managed to tune my parameters to deal
with the slow response and timeout issues.

I suggest that whomever runs the next IETF ask Ted Lemon to help set
up the DHCP service...

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 17 Dec 1998 11:05:56 -0500

[...]

Perry

---

From: "Michael H. Warfield" <[email-masked]>
Date: Thu, 17 Dec 1998 11:15:10 -0500 (EST)

Daniel Senie enscribed thusly:
	:
	: - Snip - trimmed to reduce noise...
> last time it did get to talk to the server. There are a few solutions to

	Oh, that's interesting...  Client timeouts and lack of retries in
the clients seems to be at the heart of several problems then.

	I find it hard to blame the server though.  It doesn't sit back and
think "I'll be slow responding to this request".  It could be too that
packets got lost due to congestion.  Throughput was certainly great in
the terminal room so that may be unlikely.

	This also points up the danger of the logic in saying "Oh, I couldn't
contact the server this time so I'll just use the old information".  I
think that's a bad practice, especially if the lease had expired.  If the
server assigned out an address were the lease had not expired, that's also
bad practice and I would blame the server for that.

>    Win95/98 clients don't deal as well with the server rolling over

	Interesting...

>    that chore (it'd also be able to handle DNS and such).

	I'm assuming here that by referring to using ISC DHCP and then saying
"it'd also be able to handle DNS and such" that you are thinking along the
lines of the dynamic DNS updating from DHCP to DNS...

	If so...

	Danger Will Robinson, Danger!

	Yes!  ISC DHCP is great for the server.  I use it on Linux at
several locations.  Highly recommended.

	DNS on Linux also works great.

	Dynamic DNS has some real gotcha's though...  I remember one person
on the ISC DHCP mailing list saying that they had tried the dynamic DNS
update patch to the ISC DHCP and immediately had to rip it back out!  The
problem was not with ISC's DHCP (or any DHCP implimentation at all) but
with the fact that people like to assign boxes with names which are not
legal DNS names.  DHCP has no way to respond to the requestor with a NAK
for a bad host name (illegal characters, duplicate name, what ever).  He
ended up with DHCP loading his zone file with some illegal names and then
the bind server refused to reload his zone until he manually cleaned it out.

	I suppose the patch could be updated to ignore any non-valid host
names, but that will introduce its own brand of random acts of terrorism.

	If you were not thinking about the dynamic DNS updating, then
excuse the rant and...  Yes...  ISC DHCP and DNS on Linux would have
been a great idea!  :-)

>    responding DHCP server, which would could lead to two users on the

	I thought there were some problems if you reduced the lease time
too low.  I'm not sure if I would experiment with something like that,
live, in a terminal room full of irrate techies...  Maybe it would help.
What would start happening if you had more leases expiring and then
the DHCP server was responding slow?  Would the boxes just stop talking
on the network?  I realize that several renewal attempts would have to
fail to do this, but in a crowded terminal room I wouldn't say never.

> the NT domain route something or other on my laptop blew up.

	Hmmm...  I didn't need to print while there but that might have
been a good environment to test out some of the new Samba domain stuff
that some of us have working on.  You shouldn't HAVE to log into an
NT Domain just to print, though, and Samba/smbclient works just fine
with generic printer shares for printing.  I though I saw something
about Unix lp print queues as well.  Was this just trying to print
from Windows boxes without logging into the domain?

	You suggested DHCP and DNS on Linux.  I've got my printers hung off
of Linux boxes as well, at home and at the office.  The Windows boxen don't
know or care about the difference.  My "SO" (Significant Other) has her
Windows box upstairs while my workstations and printers are in the basement.
The only difference she noticed when I move the laser printer from my NT
workstation to my Linux server (other than changing the name) was that
reliability improved...  :-)

	Mike

---

From: "Michael H. Warfield" <[email-masked]>
Date: Thu, 17 Dec 1998 11:15:10 -0500 (EST)

Interesting...

	If so...

	Mike

---

From: Daniel Senie <[email-masked]>
Date: Thu, 17 Dec 1998 11:48:25 -0500

> the terminal room so that may be unlikely.

I've seen this at some of my clients' networks. I think it's unlikely
congestion was the issue, with the possible exception of congestion on
the NT server's NIC card and OS buffers. The LAN infrastructure was
rather good.

> bad practice and I would blame the server for that.

Win98, if it doesn't presently have a lease (i.e. current address is
0.0.0.0) will assign itself an address from the link-local block
(169.254/16). If it already has an address, it appears to keep using it.
In some ways, this is reasonable. If a company's DHCP server is
temporarily down, and a lease expires, a workstation would suddenly
quit. In a typical environment where the address space isn't
oversubscribed, this works pretty well.

> lines of the dynamic DNS updating from DHCP to DNS...

Nope.

> excuse the rant and...  Yes...  ISC DHCP and DNS on Linux would have

Yep. That's what I was thinking.

> fail to do this, but in a crowded terminal room I wouldn't say never.

I've experimented with low lease times with little trouble. Given a
choice between lowering lease times and increasing the block of
addresses available, I'd strongly recommend the latter. Lowering the
lease times will increase traffic and increase the chance a DHCP
interaction times out. If there's enough address space in the block used
for IETF meetings, that's the way to go.

> from Windows boxes without logging into the domain?

Yes. Windows machine wanting to print to a printer. As set up, the WINS
servers would not allow anyone to browse the network unless they were
logged into the domain. It's not clear if I could have configured
printing by typing in the \\path info (had I known it).

I think this is just a matter of having the folks dealing with the NT
servers learn some better methods of doing the setups.

In Chicago, I could browse the network without logging in to the domain,
but the Windows95/98 drivers weren't properly loaded onto the NT server
(so they could be downloaded and used automatically by Windows) so I
never got printing to work there either. Much of the trouble is with the
software structure as opposed to the people, I think. It really
shouldn't be so hard to get this stuff to work simply and cleanly.

In my own network, I use SAMBA for communication to my servers (which
are Linux) rather than using NT servers at all. I use Windows clients
since I have to use certain tools from a certain 1000 pound gorilla at
present.

---

From: Daniel Senie <[email-masked]>
Date: Thu, 17 Dec 1998 11:48:25 -0500

Nope.

---

From: "Perry E. Metzger" <[email-masked]>
Date: 17 Dec 1998 12:02:41 -0500

> choice for the terminal room.   Of course, I'm biased... :')

I think this would be an excellent idea.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 17 Dec 1998 12:02:41 -0500

Perry

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 17 Dec 1998 09:24:44 -0800

>choice for the terminal room.   Of course, I'm biased... :')

As the host for the next IETF meeting, I would like to formally say I need
all the help I can get! 

Does DHCP work over tin cans and string?

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 17 Dec 1998 09:24:44 -0800

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 17 Dec 1998 14:16:55 -0500

>Does DHCP work over tin cans and string?

If you support that interface on your routers :)

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 17 Dec 1998 14:16:55 -0500

---

From: Chris Newman <[email-masked]>
Date: Thu, 17 Dec 1998 11:24:52 -0800 (PST)

> last time it did get to talk to the server. There are a few solutions to

Wait a minute!  We're not allowed to have technical discussions on the
main IETF list, are we?  I guess it's time for this thread to end.

		- Chris

P.S. The terminal room was great, despite the slow DHCP server.

---

From: Chris Newman <[email-masked]>
Date: Thu, 17 Dec 1998 11:24:52 -0800 (PST)

- Chris

---

From: Ralph Droms <[email-masked]>
Date: Sun, 20 Dec 1998 21:56:46 -0500

At 11:15 AM -0500 12/17/98, Michael H. Warfield wrote:
>think that's a bad practice, especially if the lease had expired.

Let me clarify a little, here.  Using an existing (not-yet-expired) lease
if the server can't be reached makes *a lot* of sense, as it allows a
client that still has a good address to continue operating in the face of
lost connectivity with the server.  Continuing to use an address for which
the lease has expired violates the DHCP spec (which is a lot worse than
"bad practice"), and no RFC2131-conformant client will use an address past
the expiration of the lease.

>If the

Reassigning an address before the lease expires violates the DHCP spec; a
server which makes such a reassignment is not RFC2131-conformant.

>>    responding DHCP server, which would could lead to two users on the

No, a non-responding DHCP server *cannot* lead to two computers (using
RFC-2131 conformant DHCP clients) using the same address.  Well, that's the
theory, anyway.  I can imagine situations in which computers with drifting
clocks might lead to overlapping leases...

>too low.

Not for "reasonable" values; a lease time of an hour should work fine.

>on the network?

Yes; according to RFC2131, a client that can't extend it's lease simply
stops all other IP activity and restarts the DHCP initialization process.

- Ralph Droms

---

From: Ralph Droms <[email-masked]>
Date: Sun, 20 Dec 1998 21:56:46 -0500

- Ralph Droms