Musings on Static vs Dynamic (Was: Switch from pure DHCP to Static/DHCP)

[Simon Hobson]

lucio at proxima.alt.za wrote:
>  > Is there any particular reason for requiring fixed addresses ? I can
>>  tell you from experience it makes things a whole lot harder to manage.
>
>Hmm.   I was going to say (having been piqued by your statement):
>
>Yes, sure, but once you've gone there, you won't want to do anything
>else.  The "D" in DHCP is overrated and I believe you're doing the
>'Net a disservice by praising its dynamic nature when it's only the
>"HC" bit that has any real value :-)
>
>I accept that static assignment does not scale well and is perceived
>as a poor relation, but, without having given it much thought, I think
>it could be administered with no greater effort.  The tools are not as
>helpful, but if more people used it, I think the tools would mature.
>
>Perhaps I should humbly ask you to share _your_ views on this?  I have
>the same situation as Erick Perez (around two hundred users) and I
>would not like to change to dynamic allocation as the users are too
>poorly trained, but evidently you have a different perspective on it.

My views ? I'm a firm believer in the value of the D in DHCP, but 
that doesn't mean I don't also believe in the value of static address 
assignments when the conditions are there. It would probably help if 
I told my story as a "network admin" for want of a better term so you 
have the background (*, **, #, etc are footnotes !) ...




OK, my experience is probably coloured a bit by the tools available 
(or not) to me at the time. My previous job was in a smallish 
business, when I started there 11-16 years ago* they had serial 
terminals off a SCO Xenix box for the business accounting, sales 
processing etc. Desktops were 100% Mac, and there was some 
LocalTalk** networking between the Macs. No IP at all. After a bit, 
we started hooking up serial cables to the PCs and Macs and running 
terminal emulations - so reducing the number of screens and keyboards 
on peoples desks.

When the Xenix system got upgraded to Unix, I persuaded the then IT 
Manager that they should buy the TCP/IP option for it - I didn't tell 
her why, if she'd known she would have blocked it ! At one point they 
employed a new Design Manager, and one of the first questions she 
asked was "why's this network so slow ?" - they were then shifting 
'massive' 40 and 50MByte files around over the LocalTalk network. 
Having just taken an 8 port 10baseT hub in as part ex against a 
16port for a customer, then got slipped into the network without 
anyone knowing apart from me and the design manager ;-)

Slowly I was able to start slipping things onto this new network, 
slip IP capable terminal emulation past the IT manager, and so the 
wedge got driven deeper and deeper. By now you may have twigged that 
the IT Manager was of the "the world revolves around MY server, you 
can stick with serial terminals because I understand and can control 
them" mentality. She was also of the "Macs over my dead body because 
I don't understand them" attitude to system selection !

Anyway, the wedge was now well and truly started, and soon everything 
new was going on the network - particularly useful once we went to 
multi-site working. We were gaining sites by aquisition, closing some 
down, opening others ...

By the time I left last year, we were up to something in the order of 
100 desktops at the main site, with 6 other sites around Europe, and 
part of a global WAN with about 50 sites worldwide (other companies 
in the parent group). OK, so it's a trivially small network compared 
with some of the stuff other people here are doing, but big enough to 
have many of the same headaches.


Now to get back on topic.

Our first forays into IP were naturally with manual address 
assignment and manual configuration. It worked fine at first, until 
we'd forget where we'd gotten to with addresses and had to start 
playing the "who the f**k is using that address" game !

After a while I started playing with the DHCP server provided on the 
SCO OpenServer box. Yes, it could provide addresses, but it wasn't 
what you'd call simple***. I settled on only using static address 
assignments, which were done in the same way as configuring a BOOTP 
server. Another factor was the total absence of any DNS integration 
which was important for me - we wanted to be able to look at the 
users logged into the Unix box and see where they were logged in from 
- I could cope with IPs, but the (now different) IT manager needed to 
see things like "freds-mac.company.com".

As a slight aside, when I first started with IP, addresses were 
handed out on request - no need to justify your need for them. So I 
was using a single class C block internally.

After a while of this manual addressing, I realised that I hadn't 
been keeping track of equipment that had been removed. For various 
reasons (not least looking at splitting a single block across 
multiple sites) I was now starting to suffer from 'lack of planning' 
and had a bootp list with a lot of unused devices.

I switched tactics and decided to use private addressing using the 
10.0.0.0 range. I could now give myself huge blocks at each site so 
no need for IP reuse. I simply did something like :

10.1.0.x are the servers, printers etc etc at HO, 10.1.1.x are the 
Macs, 10.1.2.x are the PCs, then 10.2.2.x are the PCs at site 2 etc - 
and I simply used the asset number for the last octet. We called out 
hardware PC123, Mac076, and so on. I used a 16 bit mask so had loads 
of space.

Changing over was 'interesting', I found out about a feature and a 
bug in SCO's DHCP server. The feature - all statically assigned 
devices are given infinite leases. The bug# - DHCP-NAK is only ever 
sent if it is in response to the FIRST request since the server 
started up (it is started from inetd and by default quits after 15 
minutes inactivity). Bummer ! Some of you will by now have twigged 
that all the PCs were happy to carry on using their infinite leases 
until the dhcp server told them otherwise, but in practice, very few 
NAks got sent out. So yes, we were using DHCP but still had to walk 
round the building to manually reconfigure every damn PC.

So now I did have a system that worked, was reasonably simple to set 
up and manage, and I didn't need to worry about address recovery (it 
was going to be a while before we reached Mac255 or PC255 !)

The downside was that this was still the days when manufacturers 
didn't see a need to put the MAC address on a sticky label on the 
outside of the box. So we needed to boot up the new clients, find out 
their MAC address, then configure the DHCP server. Not hard, but 
'irritating'. Another issue was that it didn't deal with equipment 
moving between sites, or indeed, visitors wanting to plug into our 
network.



While looking around the internet, I came across a script that would 
read a leases file and update the DNS. I looked at this, but guess 
what - SCO's dhcp server (or rather Address Allocation Server (AAS)) 
kept a totally different format. IIRC, around this time we got our 
first Linux server in (Redhat 6.2) which of course came with the ISC 
DHCP server, also about this time, ISC had version 3 out in beta - 
I've been using it ever since.

My set-up was to define classes based on the hostname (Windows) or 
client-id (Macs). We had already started coding these to ensure 
uniqueness with our partners elsewhere in the group (they had some 
grand plans that never did come to fruition !) - so they were called 
ECMac123-Jim, ECPC123-Fred etc (E for Europe, C for <Company>). For 
clients that matched these, I would set the ddns-hostname to be the 
supplied value with the EC stripped and allow them access to a pool 
with a decent lease time. Anything else I simply used the supplied 
hostname and gave them a visitors pool with an 8 hour lease.

It wasn't perfect - I would have liked to have CNAMEs along the lines 
of "jim CNAME Mac123-jim", but we managed without. The other IT staff 
were happy because in the user listings they would see logins from 
things like "PC123-Fred.company.com" or "PC075-steve.sit.company.com" 
(sit being a three letter site code). The best thing though was that 
we simply needed to set the hostname (done during Windows setup 
anyway) or client-id (a few clicks) and the rest 'just happened' - as 
I wasn't the only one (or by now even the main one) setting up 
computers, this was important.


Of course, printers were all on fixed addresses - but dished out by 
DHCP where possible (we had some older ones that only did bootp, and 
one that wouldn't accept a dhcp lease - I later found out that the 
numb***s that programmed it decided that anything less that 2 years 
wasn't a valid lease !). This wasn't a hardship as we had to set up 
all the printing on various servers anyway, so manually configuring 
the dhcp and dns for them wasn't a big issue.##


So, that gives the potted history of how I got to where we were, and 
why I did things the way we did. DHCP made things a lot easier, 
roaming users were (mostly) happy, we could move equipment between 
sites easily, IT staff could identify where users were logged in 
from, and it all ran fairly smoothly - too smoothly as it turns out.



How can a network run too smoothly ? Well the company had been going 
through a 'tough patch', sales dropping like lemmings off a cliff and 
so on. Management doing the usual 'headless chicken' routine and 
blaming everyone but themselves - it seemed the only ones unable to 
see that our product lines were now old and tired, and quality going 
down the pan were ... the people in charge. I mentioned a few 
paragraphs back about being part of the group, well with that comes 
US ownership and a US style of management (which is what forced the 
companies founders to leave). To a beancounter, R&D is a cost to be 
squeezed, not an investment - and of course, cutting R&D is something 
that gives an immediate improvement on the bottom line but doesn't 
apparently have any effect ! By the time the effects come through, 
it's like house training a puppy - if you don't rub it's nose in it 
and sling it out in the garden straight away then it can't associate 
the two events. Hence the downturn is nothing to do with not having 
been keeping the product line up to date ...

Once the sales are dropping, then the pressure is on, so work harder 
became the mantra. Longstanding complaints of "too much workload" 
were simply shrugged off with "prioritise" as though that will 
magically reduce the amount of work demanded (as distinct from 
requested) ! Eventually I decided enough was enough.

The last straw was when a director (new to the business) looked at me 
across the table and with a completely straight face said "I've asked 
people what you do and I can't see that you do anything" ! So if the 
network was unreliable, him taking his laptop in and out of the 
office required IT assistance, etc, then I'd be seen to be doing 
something. But because I'd (invisibly) made things 'just work' then 
the clueless f***wits couldn't see anything happening. After that 
conversation, I just left my union rep to negotiate !



So what's my view now ? Well I work for an IT service company, and 
it's taking 'a bit of adjustment' to working on small networks where 
none of this is even considered. Mostly they've been built by 
"throwing in" an ADSl router, a Windows Server, and a pile of default 
settings !

Having tried to use it, I have to say that the Windows DHCP server is 
a pile of c**p ! Like most of Windows, it's trivially easy to use for 
trivially simple setups, but beyond the trivial setups it just 
doesn't have any of the features people are asking about on this 
list. Similarly, their DNS server is lacking even some basic controls.


Would I use the same set up again ? Most definitely. Would I go back 
to static assignments ? No, not unless there was a specific 
requirement. Whatever the pros and cons, there's far more serious 
issues to consider - like the evils of NAT !

Simon




* When I started full time, it took some people a while to notice ! 
I'd already been looking after various areas for them on a contract 
basis from the business I part owned - eventually it was a case of 
(as my brother called it) getting a proper job and I went there full 
time.

** LocalTalk was Apples low cost network (originally they called it 
AppleTalk, but later renamed the physical layer stuff to 
differentiate it from the protocols). Single twisted pair, 230kbps. 
Slow, but it was a) cheap, b) built into ever Mac ever made, and c) 
it was REALLY easy to set up - these three facts made it very popular.

*** SCO didn't let their DHCP server actually allocate addresses, 
that was a separate service. In it's favour, it meant that in theory 
you could have multiple services taking addresses and the Address 
Allocation Server could take care of them, in practice it added an 
extra layer of complexity.

# AFAIK, this bug has never been fixed by SCO !

## I had adapted SCO's text-to-PS print filter to read a config file 
listing the printers and the model, it then included a big "case 
printer-model in ..." block to support the various facilities 
available. So replacing a printer became a matter of changing the mac 
address in dhcp, and changing the model if required in the printer 
list.