DHCP

DHCP is a client-sever protocol. There are  two separate ports associated with DHCP:

• port 67 UDP for the DHCP server
• port 68 UDP for the client. 

DHCP client listen for messages from server on port 68. The DHCP server listens for messages on port 67.

When a DHCP client computer is booted, DHCP messages are exchanged between client computer and server as follows:

1. The DHCP client computer broadcasts a DHCPDISCOVER message. In a routed environment, the broadcast is limited to the physical subnet. If there is no DHCP server on the physical subnet, one or more of the routers should be configured to forward the (BOOTP) message to a known DHCP server location.The DHCPDISCOVER message can include options that request specific values for the network address and lease duration.
2. Each DHCP server that is configured to respond to the client computer's subnet should respond with a DHCPOFFER message. The DHCPOFFER message has a (presumably) available IP address as well as other configuration information. According to the IETF standard, the DHCP server should first grope the target subnet with an ICMP ECHO request to confirm that the address is available.
3. The DHCP client computer receives one or more DHCPOFFER messages from the DHCP server(s). The client computer selects one of the DHCPOFFER messages.
4. The DHCP client computer broadcasts a DHCPREQUEST message that includes a server identifier option to indicate which server it has selected. This DHCPREQEST message can include requests for specific configuration information.
5. All DHCP servers that responded to the client computer's original DHCPREQUEST broadcast should receive the second DHCPREQUEST message broadcast. The DHCP server(s) that were not selected by the client computer take no further action.
6. The selected DHCP server commits the IP address for the client computer to its list of client computers, IP addresses, and leases. It then sends a DHCPACK message that includes the (requested) configuration parameters for the DHCP client computer.
7. If the selected DHCP server cannot comply with the DHCPREQUEST message from the client computer (usually because the requested IP address is not available), the server sends a DHCPNAK message to the client computer.
8. The DHCP client computer receives the DHCPACK message from the server. The client computer normally performs a final validation of the configuration information and saves the address lease duration specified in the DHCPACK message. The client computer is configured.

Like DNS there can be primary and secondary DHCP servers but secondary DHCP servers are not a requirement and they are not that common.  Primary and secondary DHCP servers must have access to the exact same data. Copies cannot be used. This can be achieved by via NIS and NFS. 

• Primary server assign IP addresses to clients. The IP address range for DHCP zone is defined during the installation. A primary DHCP server assigns an IP address to any client which requested a new configuration. Assigned IP-addresses always belong to the DHCP zone for which the server responsible. Multiple primary servers can exist on the same network as long as each server is responsible for a different DHCP address range.
• Secondary server only can confirms existing configurations previously supplied  by a primary server when the primary server is not available. Every primary server can also act as a secondary server.

Introduction

The Dynamic Host Configuration Protocol (DHCP) permits centralization of IP-addresses assignment in a centralized location. The concept of dynamically assigning Internet Protocol (IP) addresses is fairly new and became common only in late 90th.  DHCP is the dominant application-layer TCP/IP protocol that does the job. All major OSes now provide a DHCP client.  Most provide DHCP server too. There is also free reference implementation from Internet consortium. For all major commercial Unixes the DHCP protocol engine has been updated to RFC 2131, but is still compatible with RFC 1541. (The server can also process options as defined in RFC 2132.) The protocol engine uses the database to determine what information should be returned to the client.

DHCP doesn't just provide IP addresses to clients, it is used to manage a large percentage of an installation's configuration information. The service interacts with other critical network infrastructure such as the Domain Name System. In DHCP environment, hosts may be  added to the network or moved between networks without the need for manual configuration.

DHCP is based on BOOTP protocol and it extends BOOTP transport standards for passing a variety of configuration information (known as options) to clients:

• Network configuration information:
  
  • IP address
    
  • Boot server IP address
    
  • DNS server, router, and the Network Time Protocol (NTP) server’s IP addresses
    
• Lease periods for network configuration parameters (see below)

Routers can be configured to act as a BOOTP relay agent. Support is available for clients that need to boot over a network, effectively replacing the need for RARP and the bootparams file.

DHCP is a client-sever protocol. There are  two separate ports associated with DHCP:

• port 67 UDP for the DHCP server
• port 68 UDP for the client. 

DHCP client listen for messages from server on port 68. The DHCP server listens for messages on port 67.

There are nine types of messages used by DHCP:

The configuration parameters managed by DHCP are valid for a period of time called a lease. The duration of the lease is set when the client accepts a configuration offer from a DHCP server. Although the protocol provides a method for a client to request a specific length for the lease, there is actually no negotiation of lease terms. The client either accepts or rejects the parameters offered by a server.

The DHCP client can be on six different stages:

1. INIT The client has not had a lease and is locating a DHCP server.
2. INIT-REBOOT The client has had a lease and is restarting its IP interface.
3. SELECTING The client has received lease offers from one or more DHCP servers.
4. BOUND The client has been successfully configured and has a valid lease.
5. RENEWING The client is attempting to renew the lease with the same DHCP server.
6. REBINDING The client could not renew the lease with the original server and is attempting find another DHCP server

At each of those stages the client can send/receive certain types of messages. See DHCP messages. The process of obtaining the initial information (initial lease) consists of several stages.

On the first stage the client broadcast the request using the address 255.255.255.255 to discover a server. If a router is present and configured to behave as a BOOTP relay agent, the request can be passed to other DHCP servers on different subnets.  Otherwise only local subnet is involved. The client’s broadcast includes its unique ID, which in the Solaris DHCP implementation, is derived from the client’s MAC address.

After any server returns an offer of address, the subsequent process, as described in Designing a Windows 2000 Network Infrastructure Developing DHCP Strategies , is somewhat similar to "DHCP handshake" of client with the server: 

When a DHCP client computer is booted, DHCP messages are exchanged between client computer and server as follows:

1. The DHCP client computer broadcasts a DHCPDISCOVER message. In a routed environment, the broadcast is limited to the physical subnet. If there is no DHCP server on the physical subnet, one or more of the routers should be configured to forward the (BOOTP) message to a known DHCP server location.The DHCPDISCOVER message can include options that request specific values for the network address and lease duration.
2. Each DHCP server that is configured to respond to the client computer's subnet should respond with a DHCPOFFER message. The DHCPOFFER message has a (presumably) available IP address as well as other configuration information. According to the IETF standard, the DHCP server should first grope the target subnet with an ICMP ECHO request to confirm that the address is available.
3. The DHCP client computer receives one or more DHCPOFFER messages from the DHCP server(s). The client computer selects one of the DHCPOFFER messages.
4. The DHCP client computer broadcasts a DHCPREQUEST message that includes a server identifier option to indicate which server it has selected. This DHCPREQEST message can include requests for specific configuration information.
5. All DHCP servers that responded to the client computer's original DHCPREQUEST broadcast should receive the second DHCPREQUEST message broadcast. The DHCP server(s) that were not selected by the client computer take no further action.
6. The selected DHCP server commits the IP address for the client computer to its list of client computers, IP addresses, and leases. It then sends a DHCPACK message that includes the (requested) configuration parameters for the DHCP client computer.
7. If the selected DHCP server cannot comply with the DHCPREQUEST message from the client computer (usually because the requested IP address is not available), the server sends a DHCPNAK message to the client computer.
8. The DHCP client computer receives the DHCPACK message from the server. The client computer normally performs a final validation of the configuration information and saves the address lease duration specified in the DHCPACK message. The client computer is configured.
9. If the DHCP client computer determines that the address is already in use, it sends a DHCPDECLINE message to the server and then begins the DHCP configuration process again with a DHCPREQUEST broadcast.
10. If the DHCP client computer does not receive a DHCPACK or a DHCPNAK message within a specified period of time, it resends the DHCPREQUEST message.
11. The client computer can relinquish its IP address lease by sending a DHCPRELEASE message to the DHCP server.

After that the behavior of the client is bound by the lease it obtained:

• When half of the lease time is used, the client sends the server a renew packet to extend the lease time. If the server is willing to renew, it sends a DHCP acknowledgement. If the client does not get a response from the server that owns its current address, it broadcasts a DHCP rebind packet to reach the server (that makes sense if, for example, the server has been moved from one network to another.)
   
• If the client has not renewed its address after the full lease time, the interface is brought down and the process starts over. This cycle prevents multiple clients on a network from being assigned the same address.  This process is informally known as "eviction".  While you won’t find the term eviction in any DHCP RFC, it does accurately describe what happens to a host’s IP interface if the lease counter reaches zero. At this point, the lease has expired and the interface can not transmit or receive datagrams using the previously assigned IP address. Any applications on the host that had been using the interface receive errors. It is important to note that eviction only occurs when a client has not been able to contact any DHCP server on the network and has made multiple attempts over a considerable amount of time. To recover from this undesirable situation, the client changes to the INIT state where it configures the interface with an address of 0.0.0.0, and continues its attempts to locate a DHCP server.

The DHCP server assigns addresses based on keys.  While usage of MAC address is standard de facto, the server can use several different keys to map an address and a set of configuration options to the client.

• client ID Identifies the client either through the machine's host name or its medium access control (MAC) layer address. The client ID is specified in the configuration file of the dhcpcd daemon. Also, the client ID can be used by the server to pass options to a specific client or prohibit a particular client from receiving any parameters.
• network Identifies which network segment the packet came from. The network key allows the server to check its address database and assign an address by network segment.
• class Is completely client configurable. It can specify an address and options. This key could be used to denote machine function in the network or describe how machines are grouped for administrative purposes. For example, the network administrator might want to create a netbios class that contains options for NetBIOS clients or an accounting class that represents Accounting department machines that need access to a specific printer.
• vendor Helps identify the client by its hardware/software platform (for example, a Windows 95 client or an OS/2 Warp client).

These keys can be used by the configuration either singularly or in combinations. If multiple keys are provided by the client and multiple addresses can be assigned, only one is chosen, and the option set is derived from the chosen key first. Again, the most common key is MAC address (that is transmitted as client ID).

The other piece of the picture is a BOOTP relay agent. A relay agent is needed so initial broadcasts from the client can leave the local network. The relay agents act as forwarding agents for DHCP and BOOTP packets.

The database is used to track clients and addresses and for access control (for example, allowing certain clients on some networks but not others or disabling BOOTP clients on a particular network). Options are also stored in the database for retrieval and delivery to clients.

The configuration of the address pools have some configuration options that affect the state machine. For example, the DHCP server pings addresses before it hands them out. The amount of time the server waits for a response is now configurable for each address pool.

To use this protocol, the network administrator needs to set up a DHCP server and configure BOOTP relay agents on links that do not have a DHCP server. Advance planning can reduce DHCP load on the network. For example, one server can be configured to handle all your clients, but all packets must be passed through it. If you have a single router between two large networks, it may be wiser to place two servers in your network, one on each link.

Another aspect to consider is that DHCP implies a pattern of traffic. For example, if you set your default lease time to fewer than two days and your machines are powered off for the weekend, Monday morning will be a period of high DHCP traffic. Although DHCP traffic does not cause huge overhead for the network, it needs to be considered when deciding where to place DHCP servers on a network and how many to use.

Historically DHCP evolved from the bootstrap protocol (BOOTP).

DHCP is based on BOOTP and maintains some backward compatibility. The main difference is that BOOTP was designed for manual pre-configuration of the host information in a server database, while DHCP allows for dynamic allocation of network addresses and configurations to newly attached hosts. Additionally, DHCP allows for recovery and reallocation of network addresses through a leasing mechanism.

RARP is a protocol used by Sun and other vendors that allows a computer to find out its own IP number, which is one of the protocol parameters typically passed to the client system by DHCP or BOOTP. RARP doesn't support other parameters and using it, a server can only serve a single LAN. DHCP and BOOTP are designed so they can be routed.

DHCP provides the following additional functionality:

• Messages include network configuration for clients, such as:
  
  • IP address
    
  • Boot server IP address
    
  • DNS server, router, and the Network Time Protocol (NTP) server’s IP addresses
    
• Lease periods are provided for IP address assignments.
  
• Routers can be configured to act as a BOOTP relay agent.
  
• Support is available for clients that need to boot over a network, effectively replacing the need for RARP and the bootparams file.

DHCP reduces the cost of managing networks by eliminating the need to manually assign or change IP addresses. DHCP also reclaims IP addresses that are no longer needed or if the lease  has expired. DHCP also makes it easier to renumber the network if the IP range changed.

NEWS CONTENTS

• 20210614 : BAD_ADDRESS FLOOD IN WINDOWS DHCP SERVER ( Jun 14, 2021 , letzzshop.blogspot.com )
• 20210614 : DHCP decline without duplicate or wrong ip - networking ( Jun 14, 2021 , www.reddit.com )
• 20210614 : Cisco ASA DHCP - Unable to acquire IP DHCP Address - Cisco Community ( Jun 14, 2021 , community.cisco.com )
• 20210614 : What happens to clients that sends a DHCPDECLINE ( Jun 14, 2021 , mailarchive.ietf.org )
• 20210614 : Actions to take in case of DHCP Decline message from the client - Knowledge Base - Ruckus Wireless Support ( Jun 14, 2021 , support.ruckuswireless.com )
• 20120326 : What ports are used by DHCP and the DHCP clients ( What ports are used by DHCP and the DHCP clients, Mar 26, 2012 )
• 20061221 : Problems Detecting Rogue DHCP Servers on Linux UPDATE ( Problems Detecting Rogue DHCP Servers on Linux UPDATE , Dec 21, 2006 )
• 20061220 : Problems Detecting Rogue DHCP Servers on Linux ( Problems Detecting Rogue DHCP Servers on Linux, Dec 20, 2006 )
• 20061211 : Planning, Implementing, and Troubleshooting DHCP Understanding DHCP ( Planning, Implementing, and Troubleshooting DHCP Understanding DHCP, Dec 11, 2006 )
• 20061211 : Table 3.3. The DHCP Daily Audit Log ID Codes ( )
• 20061027 : DHCP Server Security (Part 2) ( DHCP Server Security (Part 2), Oct 27, 2006 )
• 20061027 : DHCP for Windows 2000 Managing the Dynamic Host Configuration Protocol Chapter 4 Designing a DHCP Infrastructure ( DHCP for Windows 2000 Managing the Dynamic Host Configuration Protocol Chapter 4 Designing a DHCP Infrastructure, )
• 20061027 : DHCP ( DHCP, )

Old News ;-)

[Jun 14, 2021] BAD_ADDRESS FLOOD IN WINDOWS DHCP SERVER

Notable quotes:

"... cat /var/log/messages ..."

"... "If the server receives a DHCPDECLINE message, the client has discovered through some other means that the suggested network address is already in use. The server MUST mark the network address as "not allocated" and SHOULD notify the local system administrator of a possible configuration problem." ..."

Jun 14, 2021 | letzzshop.blogspot.com

BAD_ADDRESS FLOOD IN WINDOWS DHCP SERVER February 25, 2018 How a single misbehaving client can take down your network Well, not really your entire network but definitely DHCP. I came across a linux client that had issues with assigning an IP address using dhclient. The dhclient process would throw a null pointer exception during the phase in which it attempts to validate the assigned IP address. From here, dhclient sends a DHCPDECLINE message to the server. The DHCPDECLINE message tells the server that something is either wrong with the DHCP parameters or that the client discovered that the IP was in use (through gratuitous ARP or in this case, a failed attempt at sending a gratuitous ARP). cat /var/log/messages : RFC 1541 states: "If the server receives a DHCPDECLINE message, the client has discovered through some other means that the suggested network address is already in use. The server MUST mark the network address as "not allocated" and SHOULD notify the local system administrator of a possible configuration problem." Looking at my Windows DHCP server console, it's not a pretty sight. The entire pool is exhausted. Manually deleting the BAD_ADDRESS entries fixes it for only a few seconds. Here is the Wireshark output immediately after deletion of the BAD_ADDRESS entries: You can see that the linux client is just going nuts. Requesting and declining all IP addresses in the pool until there is no more. The quick fix in this instance is easy enough; take the linux client off the network or kill the faulty dhclient process and assign a static IP. But how do we ensure that this won't happen again?

[Jun 14, 2021] DHCP decline without duplicate or wrong ip - networking

Notable quotes:

"... Is the sender IP all 0s in the ARP request? If so, that's duplicate address detection. ..."

Jun 14, 2021 | www.reddit.com

Hi guys,

We have some trouble with dhcp at one location.

We have the exact same dhcp/network configuration around 400 times without trouble or problems. All locations are basically the same. Same firewalls, same construct.

So there is no problem with the concept.

Now our problem:

The hole problem is only at one vlan. Other work fine. Vlan has /24 class C network. Around 8 clients. Three dhcp other static ip.

Three clients keep requesting dhcp addresses. So normal dhcp process and after the process an arp request with their own new ip. After this it seem any device is accepting it and sending an answer to the arp. So the client is sending a DHCP Decline. IP is dropped and the client is requesting a new one. This happens until the pool is full and it will start from the beginning.

I gained this knowledge by sniffing the network at our firewall/dhcp server. So I have one file rx and one tx. I see some DHCP offers and ACKs on the rx file around 1-2 seconds after they were sent from my firewall.

This is a sign for a looped network. But why only one time if there is a loop. Why is the network without other problem. Normally a loop will shutdown the network due to BC storms.

Anyone with help?

Also I'm able to do a wireshark capture at client side tomorrow.

d_hoffman 4 years ago

So normal dhcp process and after the process an arp request with their own new ip. After this it seem any device is accepting it and sending an answer to the arp.

Is the sender IP all 0s in the ARP request? If so, that's duplicate address detection.

I've seen this when proxy ARP is enabled somewhere and it incorrectly responds to duplicate address detection ARP requests. (If it does, it's a bug. An early release of IOS 15.0 did this.) newworldmonkeys2 CompTIA A+ (expired) 4 years ago

· edited 4 years ago

1. What model device is acting as the default gateway for this VLAN?

2. What model device is acting as the DHCP server for this VLAN?

3. Are you using DHCP relay/IP helper?

4. If you remove all clients from this VLAN and then plug in just a single DHCP client, does the client get an address?

Edit: It sounds like local proxy ARP is enabled on some device in this VLAN, local proxy ARP could cause this problem. But local proxy ARP is usually disabled by default on most gear, which is why I ask for more info about models/versions. 2 Share Report Save

TeaL0w 4 years ago

1. 2. Gateway and DHCP Server PaloAlto 500

2. no, all clients only via switches connected. The is no router or IP network change between Firewall and client.

3. Good idea, I tried to shutdown single ports, check log in Firewall, enable port and check next in that one vlan. No result. But I had not this much time and did it not with all ports. I will shutdown all and activate only the three devices with the problem. One by one and check for the problem.

I have read about the arp proxy. Don't know if enabled, but if enabled we should have this problem more than once.

Thanks for help ;) newworldmonkeys2 CompTIA A+ (expired) 4 years ago

· edited 4 years ago

I have read about the arp proxy. Don't know if enabled, but if enabled we should have this problem more than once.

It would be enabled on a per-interface basis, not per-device, so it could be a setting just on this specific interface of the firewall. Technically it could also be on some other device in the VLAN rather than on the firewall, but that's even less likely. And to be clear - there is a difference between "proxy ARP" and "local proxy ARP". Proxy ARP alone would not cause this problem, but local proxy ARP could.

Unfortunately I'm entirely unfamiliar with Palo Alto gear so I can't advise as to how to check whether local proxy ARP is enabled, or whether it's even supported on the device to begin with.

Edit: Another test that might be worth trying is just verifying whether one of these problem clients can get DHCP addresses in other subnets/VLANs. Just to rule out any chance that it may be a problem with the end clients themselves. 2 Share Report Save

d_hoffman 4 years ago

Local proxy ARP should not cause the described behavior. Proxy ARP, with or without local proxy ARP, should ignore duplicate address detection requests.

I have a few hundred SVIs configured with local proxy ARP for VLANs with DHCP clients. In the one case where it has responded, it was a bug in IOS that affected all proxy ARP (proxy ARP without local proxy ARP still had the problem). 3 Share Report Save

newworldmonkeys2 CompTIA A+ (expired) 4 years ago

Proxy ARP, with or without local proxy ARP, should ignore duplicate address detection requests.

Ah, good to know, thanks for the information.

Out of curiosity, is there a reason you run local proxy ARP? What's your use case for that? 2 Share Report Save

d_hoffman 4 years ago

We needed to be able to filter traffic between clients on our residential networks in dorms and apartments. We block direct L2 connectivity between ports and use local proxy ARP to force everything up to a L3 device for ACLing. Intra-VLAN traffic is very minimal in these cases, so it works well enough. 3 Share Report Save

TeaL0w 4 years ago

Okay, good to know. I will check with Palo Alto.

Well I have changed the vlan on one of the clients and there was no problem with DHCP. Same Palo Alto is DHCP/gateway for this vlan. Everything is fine.

Tomorrow I will disable all clients and will enable one step by step. Check for the problem.

Some of these clients do have a wireless interface too. I don't know where or what the speak. Normally some clients at 2,4 ghz but non wifi. I will check it with the manufacture.

Also I will give you feedback if I have some additional questions or response. 1 Share Report Save

TeaL0w 4 years ago

· edited 4 years ago

Well. I was not able to sleep with this problem in my head. So i checked and activated one device by another. Also I forced the client to release its ip every time. After some ports the client started doing its DHCP problem again.

I found the problem Port. I found in our log who configured this port. And I will ask tomorrow what is behind this port...

Thanks for your help. Will update with further information

Edit: after quick check I realized there is our voice gateway. This will explain some strange ip addresses in my packet capture.

Need to ask the regarding colleagues why there is no mistake with this wrong configuration... 2 Share Report Save

newworldmonkeys2 CompTIA A+ (expired) 4 years ago

Interesting. Let us know what you find! 1 Share Report Save

TeaL0w 4 years ago

Well. We have connected a CISCO2801. I did not find any arp proxy or something. But I have no clue of this device and config.

But this is our voicegateway in our voice VLAN and one port in an other VLAN. So maybe any sort of arp proxy is there configured.

Well, we can close this I think. Port Konfig was wrong...

Thanks for your help :)

[Jun 14, 2021] Cisco ASA DHCP - Unable to acquire IP DHCP Address - Cisco Community

Jun 14, 2021 | community.cisco.com

Saurav Lodh Rising star ‎10-16-2014 06:12 PM

DHCP packets from client to server utilize UDP source port 68 and destination port 67. DHCP packets from the server to the client utilize UDP source port 67 and destination port 68. DNS uses UDP port 53. These ports must be allowed through the firewall when internal DNS and DHCP servers are implemented.

[Jun 14, 2021] What happens to clients that sends a DHCPDECLINE

Jun 14, 2021 | mailarchive.ietf.org

Re: [dhcwg] What happens to clients that sends a DHCPDECLINE

Ted Lemon <[email protected]> Wed, 23 August 2006 21:17 UTC Show header

On Aug 23, 2006, at 2:09 PM, Yi Chen wrote:
> However, what the RFC doesn't seem to cover is what happen if the IP  
> being DECLINEd is a static DHCP host. Should the DHCP server keep  
> ignoring the client or give it a dynamic IP from an appropriate  
> range? Since the purpose of a static DHCP host is to make sure that  
> client always gets the same IP, I would think that ignoring the  
> client would be the right approach.But I thought I should ask the  
> people on this list who are much more experienced with DHCP than I  
> do :)

DHCPDECLINE is used by the client to indicate that the IP address that  
was leased is in use by some other device.   So ignoring a DHCPDECLINE  
is a bad idea.   What you should do instead is to notify the  
administrator with some urgency that the IP address is in use.    
Whether to offer the client another IP address, or to ignore it until  
such time as the problem is corrected, is probably something that  
should be configurable by the operator.

_______________________________________________
dhcwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dhcwg

• [dhcwg] What happens to clients that sends a DHCP Yi Chen
• Re: [dhcwg] What happens to clients that sends a Ted Lemon

[Jun 14, 2021] Actions to take in case of DHCP Decline message from the client - Knowledge Base - Ruckus Wireless Support

Jun 14, 2021 | support.ruckuswireless.com

Summary This article explains what causes DHCP Decline response from a client, how to diagnose the problem, and what needs to be done to fix the issue. Question What to do when DHCP Decline response message is received from a client? Customer Environment Ruckus wireless network with DHCP server Root Cause Either duplicate IPs or not enough scope to support client volume. Troubleshooting Steps One of the symptoms in such environments will be client repeatedly gets a different IP every few seconds.
Looking at a network packet capture, client goes through normal DHCP discovery and request process. But there will be a DHCP Decline response from the client later to the above steps.
Scrolling a bit within the packet capture, there will be a gratuitous ARP from the client enquiring if there is anyone holding same IP (also indicating everyone which IP it got from the server). Following the gratuitous ARP, there will be an ARP response from a different client indicating it has the same IP. That's an indication that the client has received a duplicate IP. This will cause the client to send a DHCP Decline and start DHCP process all over again.

DHCP server event messages will have an indication of "This address is already in use". Packet capture will also have packets that show 'duplicate use of IP detected' messages. Resolution 1. Increase DHCP scope to avoid duplication.
2. If there are manually assigned IPs causing the duplication, avoid manual assignment or exclude those IPs from dynamic assignment.

[Mar 26, 2012] What ports are used by DHCP and the DHCP clients

Requests are on UDP reversed port 68
&
Server replies on UDP reversed port 67

If the above is right, then you can allow those ports on Linux(Ubuntu) with:
sudo iptables -A OUTPUT -p udp --dport 68 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 67 -j ACCEPT

[Dec 21, 2006] Problems Detecting Rogue DHCP Servers on Linux UPDATE

Dec 21, 2006

I have finally found a tool that works for RHEL and Debian (and probably all Linuxes). It's a Perl module and accompanying script which can optionally be run as a demon and be setup to email you each time it finds a rogue server. It's called RogueDetect and is GPL. I have tested version 0.4Alpha2. I've also used this code as a basis for a Nagios plugin the code for which I'll be releasing over the next few days on this blog.

Good post bart, nice to see that windows has some decent commands relating to standard internet protocols. In the longer term, you could have a permanent method of spotting rogue dhcp servers. I found a rule for snort:

#
# DHCP Servers
#
alert udp !$DHCP_SERVERS 67 -> 255.255.255.255 any (msg: "possible rogue DHCP Server"; sid:1000001;)

I know you use nagios, I dunno if theres a plugin for that yet.

[Dec 20, 2006] Problems Detecting Rogue DHCP Servers on Linux

I am by no means shy about pointing out problems with Windows on this blog but I do try to be objective in my criticism. Today I have the rare pleasure of sharing a Windows command-line tool that I haven't been able to find an equal to on RedHat Enterprise Linux (RHEL) 4. A few weeks ago a rogue DHCP server caused us some serious problems at work so I was asked to find a simple tool for detecting rogue servers. In theory there are loads of tools for this on Linux but after having tried everything Google was able to find for me (an entire day's work) I'd still drawn a blank. Everything I tried insisted that our main DHCP server did not exist. What's more tcpdump showed responses from the DHCP server arriving at the machine but all the tools insisted they got no reply regardless. In my search I did come across dhcploc.exe, a small MicroSoft command-line tool that ships with most versions of Windows. Granted, it's not part of the default install but it is on the CD none the less and more importantly it works!

Technorati Tags: Windows, RedHat, RHEL, DHCP, Rogue DHCP Servers

To install dhcploc.exe you have to install the Support Tools which you have to look for on your Windows CD. Once you have this installed you can set it looking for rogue servers with the following command:

dhcploc 

dhcploc.exe will then run continually and display all DHCP responses it sees. It will beep each time a rogue server is seen. You can also get it to only show you rogue traffic with the -p flag.

It's rare that Windows has more powerful command-line tools than Linux but when it comes to detecting rogue DHCP servers Windows had it nailed with this simple tool that just works! I just hope this tool still exists in Vista!

Update 21 December 2006

I have finally found a tool that works for RHEL and Debian (and probably all Linuxes). It's a Perl module and accompanying script which can optionally be run as a demon and be setup to email you each time it finds a rogue server. It's called RogueDetect and is GPL. I have tested version 0.4Alpha2. I've also used this code as a basis for a Nagios plugin the code for which I'll be releasing over the next few days on this blog.

[Dec 11, 2006] Planning, Implementing, and Troubleshooting DHCP Understanding DHCP

Dec 11, 2006 (samspublishing.com) Although DHCP is typically one of the easiest of the common network services to configure and maintain, from time to time, you might encounter problems. More often than not, the DHCP-related problems that arise stem from a misconfiguration in a scope, unauthorized DHCP servers on the network, or network connectivity problems. You might also find information that has changed in some way, but the change has not been reflected in your DHCP configuration, as in the case of DHCP reservations (which are tied to MAC addresses) or a DHCP server's IP address change. The following sections examine some troubleshooting tasks you can do to quickly determine the cause of DHCP woes and get this vital network service back into proper operation.

Troubleshooting DHCP Server Authorization Problems

As discussed previously, one of the first indicators you might see of an unauthorized or rogue DHCP server is an unexpected increase in the number of DHCPNACK messages. You can monitor this statistic over time by using the Performance console. The Performance console includes several counter objects that you can use to monitor and troubleshoot your DHCP server:

• Acks/Sec-This counter monitors the number of DHCPACK messages sent per second by the DHCP server to client computers. The DHCP server uses the DHCPACK messages to acknowledge requests for an address. An increase in this number indicates that a large number of client computers are probably trying to renew their leases with the DHCP server. This could be because of a short lease time configuration or because a number of new computers are entering the network.
• Active Queue Length-This counter monitors the current length of the internal message queue of the DHCP server. This number represents the number of unprocessed messages received by the server. A large number here could indicate an unusually large amount of network traffic or a heavy load on the server.
• Conflict Check Queue Length-This counter monitors the current length of the conflict check queue for the DHCP server. Before a Windows Server 2003 DHCP server issues an address, it checks whether any IP address conflicts exist. The conflict check queue holds the messages not responded to while the DHCP server performs address conflict detection. A large value here could indicate heavy lease traffic at the server. You might also want to check the Conflict Detection Attempts parameter, which could be set too high.
• Declines/Sec-This counter monitors the number of DHCPDECLINE messages that the DHCP server receives per second from client computers. This counter indicates that the DHCP client computer has declined the IP address issued by the server. You see this number rise when client computers start having address conflict problems, and it could indicate a network problem, computers with static addresses also being part of a scope, or a rogue DHCP server on the network.
• Discovers/Sec-This counter monitors the number of DHCPDISCOVER messages received per second by the server. The DHCPDISCOVER message is the initial request a client computer sends when it first enters the network and looks for a DHCP server to issue an address. A sudden increase in this counter could indicate that a large number of client computers are attempting to initialize and obtain an IP address lease from the server at the same time. You might see this first thing in the morning, when users power on their PCs, or after a power failure, when all the PCs might be powered on at about the same time.
• Duplicates Dropped/Sec-This counter monitors the number of duplicate packets per second dropped by the DHCP server. Duplicate packets on a network are never a good sign, and they can indicate that DHCP clients are timing out before the server can respond. This can be caused by client computers timing out too fast or the server not responding quickly enough.
• Informs/Sec-This counter monitors the number of DHCPINFORM messages received per second by the DHCP server. DHCPINFORM messages are used when the DHCP server queries the directory service for the enterprise root and when dynamic updates are being done on behalf of client computers by the DNS server. This is part of the DDNS integration, and an unusual increase in this number could indicate a large number of addresses being issued.
• Milliseconds Per Packet (Avg)-This counter monitors the average time, in milliseconds, the DHCP server takes to process each packet it receives. This is a very subjective number that depends on the server configuration; therefore, having a baseline for this number is a good idea. A sudden increase in this counter could indicate a disk problem or an increased load on the server.
• Nacks/Sec-This counter monitors the number of DHCP negative acknowledgment (DHCPNACK) messages sent per second by the DHCP server to client computers. A DHCPNACK message indicates that the server cannot fulfill the DHCP request. A very high value for this counter could indicate a network problem or a misconfiguration of client computers or the server. Watch for a deactivated scope as a possible culprit.
• Offers/Sec-This counter monitors the number of DHCPOFFER messages that the DHCP server sends per second to client computers. A DHCPOFFER message is the message the server returns to the client computer after the client computer sends a DHCPDISCOVER message, and it indicates that the server is offering to issue an address to that client computer. A sudden increase in this value could indicate heavy traffic or a heavy load on the server.
• Packets Expired/Sec-This counter monitors the number of packets per second that expire and are dropped by the DHCP server. This situation is caused by a packet remaining in the server's internal message queue too long. A large number for this counter indicates that the server either is taking too long to process some packets or is causing other packets to wait in queue, or that the traffic on the network is too heavy for the DHCP server to handle. It is important to note that high numbers for this counter can indicate pure network traffic problems and not necessarily DHCP-related problems.
• Packets Received/Sec-This counter monitors the number of message packets received per second by the DHCP server. A large number indicates heavy DHCP message traffic to the server. These message packets might be requests for addresses, renewals, or releases.
• Releases/Sec-This counter monitors the number of DHCPRELEASE messages that the DHCP server receives per second from client computers. A DHCPRELEASE message is sent only when the client computer manually releases an address, such as when the ipconfig /release command is used or the Release All button in the winipcfg utility is used at the client computer. Because most users do not manually release their addresses, this number should be low in all but the most unusual network environments.
• Requests/Sec-This counter monitors the number of DHCPREQUEST messages that the DHCP server receives per second from client computers. These messages are the requests that the client computer sends to request an IP address after it has found a server that can issue addresses. An increase in this number indicates that a large number of client computers are probably trying to renew their leases with the DHCP server. This could be caused by a short lease time configuration or by a number of new computers entering the network.

Configuring the Performance console to monitor and collect data about a DHCP server is a simple process, as outlined in Step by Step 3.7.

Step By Step 3.7: Monitoring DHCP Performance

1. Select Start, Program, Administrative Tools, Performance to open the Performance console.
2. Click System Monitor, as shown in Figure 3.34.

   

   Figure 3.34 You can view server performance statistics by using the Performance console.

3. To create an entry in System Monitor, click the + icon. The Add Counters dialog box shown in Figure 3.35 opens, enabling you to begin adding counters.

   

   Figure 3.35 You can add counters to begin monitoring DHCP server statistics.

4. Select the DHCP Server performance object in the Performance object drop-down list box. You then see the list of counters available for selection that relate to the DHCP service. If you need to know what a counter means, select the counter and click the Explain button.
5. When you have decided what counter you want to monitor, click Add. You can add multiple counters either by selecting each counter and clicking Add or by holding down the Ctrl key while you select all the counters you want to monitor and then clicking Add. Click Close when you are finished. Your counters are graphed like those shown in Figure 3.36.

Figure 3.36 You can monitor DHCP server statistics in real time.

NOTE

Creating server baselines If you create baselines on servers, you can compare the performance at any given time to a known value. This can be very useful in performing troubleshooting, and it also helps when configurations are being modified. To create a baseline, you create a counter log from the Counter Logs option of the Performance Logs and Alerts node, shown in Figure 3.35. The configuration and use of a counter log is nearly identical to the creation and use of System Monitor, as described in Step by Step 3.7.

If you notice a trend of higher-than-normal DHCPNACK messages, you need to determine the source. The most common cause is a rogue DHCP server that has been set up on the network. You can also examine the DHCP lease properties of clients to determine whether any of them have different information than what you have configured in your DHCP scopes.

It's important to remember that Windows 2000 and Windows XP clients in an Active Directory environment that are configured to use DHCP do not accept leases from unauthorized DHCP servers. Older clients accept these leases and can contribute to the number of DHCPNACK messages when they attempt to renew their DHCP leases.

You can also examine the DHCP server daily audit logs, located in the %systemroot%\ sysytem32\dhcp folder, to look for rogue-detection events. The DHCP audit logs are discussed in the next section.

Using the DHCP Logs

The DHCP server daily audit logs are often overlooked as a valuable source of information. You have learned how to enable the audit logs; now let's look at what they contain. Unlike the logs the Windows 2000 Server DHCP service produces, the Windows Server 2003 daily audit logs are natively in text format; you open them simply by double-clicking them. A sample of what you might expect to find in a log is displayed here:

ID,Date,Time,Description,IP Address,Host Name,MAC Address
00,04/27/06,20:08:38,Started,,,,
55,04/27/06,20:08:39,Authorized(servicing),,lab1.area51partners.com,,
24,04/27/06,20:44:10,Database Cleanup Begin,,,,
25,04/27/06,20:44:10,0 leases expired and 0 leases deleted,,,,
25,04/27/06,20:44:10,0 leases expired and 0 leases deleted,,,,
24,04/27/06,21:44:12,Database Cleanup Begin,,,,
25,04/27/06,21:44:12,0 leases expired and 0 leases deleted,,,,
25,04/27/06,21:44:12,0 leases expired and 0 leases deleted,,,,
11,04/27/06,19:39:46,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
31,04/27/06,19:39:46,DNS Update Failed,
    192.168.0.231,xpclient01.corp.quepublishing.com,-1,
10,04/27/06,19:43:07,Assign,192.168.0.230,
    iMac01.corp.quepublishing.com,00306509D772,
30,04/27/06,19:44:14,DNS Update Request,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
31,04/27/06,19:44:14,DNS Update Failed,192.168.0.231,
    xpclient01.corp.quepublishing.com,-1,
30,04/27/06,19:47:03,DNS Update Request,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
11,04/27/06,19:47:03,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
30,04/27/06,19:47:03,DNS Update Request,
    192.168.0.231,xpclient01.corp.quepublishing.com,,
11,04/27/06,19:47:03,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
32,04/27/06,19:47:03,DNS Update Successful,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
32,04/27/06,19:47:03,DNS Update Successful,192.168.0.231,
    xpclient01.corp.quepublishing.com,,

As you can see from this example, the DHCP server cleans up the database hourly. You can also see that two clients requested leases. One of them, an Apple iMac, requested and was assigned the IP address 192.168.0.230, with no further actions. Another client, a Windows XP Professional computer, requested and received the IP address 192.168.0.231, with several failed DNS updates (evidenced by ID 31). After the DNS dynamic update account was properly configured, the DHCP server was able to make the DNS dynamic updates and generate an ID of 32. Table 3.3 explains the ID codes used in the DHCP daily audit logs.

Table 3.3. The DHCP Daily Audit Log ID Codes

ID	Description
00	The log was started.
01	The log was stopped.
02	The log was temporarily paused due to low disk space.
10	A new IP address was leased to a client.
11	A client renewed a lease.
12	A client released a lease.
13	An IP address was found to be in use on the network.
14	A lease request could not be satisfied because the scope's address pool was exhausted.
15	A lease was denied.
16	A lease was deleted.
17	A lease was expired.
20	A BOOTP address was leased to a client.
21	A dynamic BOOTP address was leased to a client.
22	A BOOTP request could not be satisfied because the scope's address pool for BOOTP was exhausted.
23	A BOOTP IP address was deleted after a check was made to see that it was not in use.
24	The IP address cleanup operation has begun.
25	IP address cleanup statistics are provided.
30	A DNS update request to the named DNS server was made.
31	The DNS update failed.
32	The DNS update was successful.
50+	These IDs are used for Rogue Server Detection information.

In addition to the DHCP daily audit logs, events related to the DHCP service are generated and placed in the system log, as shown in Figure 3.37.

Figure 3.37 The system log contains events related to the DHCP service.

As you can see in Figure 3.38, a DHCP server on the network has not been authorized in Active Directory. The system log contains many useful log events about all aspects of a server, and this is an area you should review often.

Figure 3.38 An unauthorized DHCP server cannot start the DHCP service.

Troubleshooting DHCP Reservations

For the most part, the only problem that prevents a DHCP reservation from functioning properly is a misconfigured MAC address. If you have a misconfigured DHCP reservation, it should show up in the Address Leases node of your DHCP server with the status Reservation (Inactive). Reservations that are configured properly show the status Reservation (Active). If you look back at Figure 3.16, you'll see that the reservation we created had a bad MAC address and, thus, was the cause of the problem in Figure 3.39.

Figure 3.39 A DHCP reservation that is not active usually indicates a misconfiguration.

To verify that a reservation is configured properly, you can compare the MAC address of the component that is to have a reserved DHCP address (a print server, for example) to the MAC address entered in the reservation Properties dialog box. The vast majority of the time, this will reveal the source of the problem.

Troubleshooting the DHCP Relay Agent

The DHCP relay agent, like a DHCP reservation, typically doesn't present a problem. However, in some cases, relay services are not being provided to network clients. Some of the most common problems that you might encounter with the DHCP relay agent include the following:

• The network interface on the DHCP relay agent server that is connected to the subnet where the DHCP clients are located has not been selected for use with the DHCP relay agent. You can verify whether the interface has been added or add it from the DHCP Relay Agent node of the DHCP console. You should also verify that the Relay DHCP Packets check box is selected on all adapters that have been selected for use.
• An incorrectly entered DHCP server IP address on the DHCP Relay Agent Properties dialog box (refer back to Figure 3.32) prevents the successful relay of packets. You can verify and correct this problem from the properties dialog box of the DHCP Relay Agent node of the DHCP console.
• Remote DHCP servers might not be reachable because of network or server problems. In this case, you need to troubleshoot basic network connectivity, as discussed in Chapter 1, "Planning, Implementing, and Troubleshooting a TCP/IP Network Infrastructure". You should troubleshoot the server status as discussed in this chapter.
• DHCP traffic might be being filtered. In this case, you need to ensure that no IP filters exist for UDP ports 67 and 68 at any point between the DHCP servers and the remote DHCP clients.

[Oct 27, 2006 ] DHCP Server Security (Part 2)

Detecting Rogue DHCP Servers

Finally, there are a few tools you can use to detect the presence of rogue DHCP servers on your network so you can get rid of them. These include both tools from Microsoft and from third-party sources, and we'll end by examining two of these tools.

Dhcploc.exe

Dhcploc.exe is a command-line tool that is part of the Windows Support Tools found in the \Support\Tools folder on your Windows XP product CD and it can be used to display all DHCP servers that are active on the local subnet. Dhcploc.exe has been around since Windows NT 4.0 and it works by sending out DHCPREQUEST messages and displaying the IP addresses of the DHCP servers that responded with DHCPACK. You can find the syntax of this tool in the Help file that is installed when you install the Support Tools on your machine.

dhcp_probe

The Network Systems Group at Princeton University's Office of Information Technology has developed a tool called dhcp_probe that tries to discover DHCP and BOOTP servers on a directly-attached Ethernet network. The existing build runs on Solaris 8 on SPARC with gcc and there is patch for it to work on Linux also, so if you have either of those platforms you can try using this tool to detect any rogue DHCP servers that might be running on your network. You can find the Network Systems Group's tools page here and can download dhcp_probe directly from here.

DHCP for Windows 2000 Managing the Dynamic Host Configuration Protocol Chapter 4 Designing a DHCP Infrastructure

Internet Connection Sharing

Internet Connection Sharing (ICS) is a new feature found in Windows 2000 Professional and Windows 2000 Server that permits a single computer to host an Internet connection for a network.

For example, if you have a small network with 15 computers, only one of the computers (running Windows 2000 and ICS) requires a connection to the Internet. This computer, known as the ICS server, hosts the Internet connection via a dial-up line, cable modem, or xDSL. The remaining 14 computers are ICS clients that access the Internet via the ICS server.

ICS provides network address translation (NAT), IP address allocation via DHCP, and name resolution services via DNS for all ICS clients. Clients can use Internet applications (e.g., Internet Explorer and Outlook) just as though the computers themselves were connected to the Internet.

The ICS server can also be configured to terminate the Internet connection when not needed. If one of the ICS clients attempts access when the Internet connection is down, ICS automatically dials the ISP and establishes a connection. The client is then able to access the requested resource.

The ICS server needs two network connections: one for the internal network (i.e., the connection for ICS clients in the office) and one for the connection to the Internet.

By enabling ICS, the computer automatically becomes a DHCP server for the office network. DHCP automatically assigns IP addresses to the hosts on the office network along with TCP/IP configuration information such as DNS servers.

When ICS is enabled, the computer acting as the ICS server is configured with a static IP address 192.168.0.1 and subnet mask 255.255.255.0. ICS's internal DHCP server is configured with a scope of 192.168.0.2 through 192.168.0.254.

Note that these default settings cannot be modified, nor can any particular service such as DHCP or DNS Proxy be disabled. If you are already running a DHCP server on your network, the ICS internal DHCP server and your network DHCP server will both attempt to honor DHCP client requests, resulting in NACKs (negative acknowledgments). In this case you cannot utilize ICS on your network. Consider using Windows 2000's Network Address Translating

DHCP

This protocol is used to assign IP addresses to hosts or workstations on the network. Usually a DHCP server on the network performs this function. Basically it "leases" out address for specific times to the various hosts. If a host does not use a given address for some period of time, that IP address can then be assigned to another machine by the DHCP server. When assignments are made or changed, the DHCP server must update the information in the DNS server.

As with BOOTP, DHCP uses the machine's or NIC ethernet (MAC) or hardware address to determine IP address assignments. The DHCP protocol is built on BOOTP and replaces BOOTP. DHCP extends the vendor specific area in BOOTP to 312 bytes from 64. RFC 1541 defines DHCP.

DHCP RFCs are 1533, 1534, 1541, and 1542. Sent from DHCP server:

• IP address
• Netmask
• Default Gateway address
• DNS server addresse(s)
• NetBIOS Name server (NBNS) address(es).
• Lease period in hours
• IP address of DHCP server.

DHCP Lease Stages

1. Lease Request - The client sends a broadcast requesting an IP address
2. Lease Offer - The server sends the above information and marks the offered address as unavailable. The message sent is a DHCPOFFER broadcast message.
3. Lease Acceptance - The first offer received by the client is accepted. The acceptance is sent from the client as a broadcast (DHCPREQUEST message) including the IP address of the DNS server that sent the accepted offer. Other DHCP servers retract their offers and mark the offered address as available and the accepted address as unavailable.
4. Server lease acknowledgement - The server sends a DHCPACK or a DHCPNACK if an unavailable address was requested.

DHCP discover message - The initial broadcast sent by the client to obtain a DHCP lease. It contains the client MAC address and computer name. This is a broadcast using 255.255.255.255 as the destination address and 0.0.0.0 as the source address. The request is sent, then the client waits one second for an offer. The request is repeated at 9, 13, and 16 second intervals with additional 0 to 1000 milliseconds of randomness. The attempt is repeated every 5 minutes thereafter.

The client uses its own port 68 as the source port with port 67 as the destination port on the server to send the request to the server. The server uses its own port 67 as the source port with port 68 as the destination port on the client to reply to the client. Therefore the server is listening and sending on its own port 67 and the client is listening and sending on its own port 68. This can be confusing when you consider which way the message is going. To be clear on this, I quote RFC 1531 which states "DHCP messages from a client to a server are sent to the 'DHCP server' port (67), and DHCP messages from a server to a client are sent to the 'DHCP client' port (68)"

DHCP Lease Renewal

After 50% of the lease time has passed, the client will attempt to renew the lease with the original DHCP server that it obtained the lease from using a DHCPREQUEST message. Any time the client boots and the lease is 50% or more passed, the client will attempt to renew the lease. At 87.5% of the lease completion, the client will attempt to contact any DHCP server for a new lease. If the lease expires, the client will send a request as in the initial boot when the client had no IP address. If this fails, the client TCP/IP stack will cease functioning.

One DHCP scope is required for each subnet.

DHCP Relay Agents

May be placed in two places:

• Routers
• Subnets that don't have a DHCP server to forward DHCP requests.

Client Reservation

Client Reservation is used to be sure a computer gets the same IP address all the time. Therefore since DHCP IP address assignments use MAC addresses to control assignments, the following are required for client reservation:

• MAC (hardware) address
• IP address

Exclusion Range

Exclusion range is used to reserve a bank of IP addresses so computers with static IP addresses, such as servers may use the assigned addresses in this range. These addresses are not assigned by the DHCP server.

Sample DCHP Configuration File

In Linux, a sample configuration file is:

subnet 192.168.199.0 netmask 255.255.255.0 {
# --- default gateway
	option routers			192.168.199.1;
	option subnet-mask		255.255.255.0;

	option nis-domain		"mynet.net";
	option domain-name		"mynet.net";
	option domain-name-servers	192.168.199.1;

	option time-offset		-5;	# Eastern Standard Time
#	option ntp-servers		192.168.199.1;
#	option netbios-name-servers	192.168.199.1;
# --- Selects point-to-point node (default is hybrid). Don't change this unless
# -- you understand Netbios very well
#	option netbios-node-type 2;

	default-lease-time 1209600;  # 2 weeks
	max-lease-time 1814400;		# 3 weeks

	range 192.168.199.10 192.168.199.250;

	# we want the nameserver to appear at a fixed address
	host nameserver {
		next-server nameserver.mynet.net;
		hardware ethernet 00:10:4b:ca:db:b5;
		fixed-address 192.168.199.1;
	}
}

This demonstrates that the IP addresses are based on lease times to the various clients. If they are not used within the period of their lease time by the client, those IP addresses are freed up for use by other clients.

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Open Directory - Computers Internet Protocols DHCP
• [PDF] Solaris DHCP Administration Guide
• [PDF] Solaris DHCP Service Developer's Guide
• [PDF] Overview of DHCP (Chapter 8 of Solaris Administration guide).
• Solaris 8 Network Administrator Certification
• [PDF] Solaris Administration Guide IP services
• Dynamic Host Configuration Protocol
• Internet Systems Consortium, Inc.

  ISC's Dynamic Host Configuration Protocol Distribution provides a freely redistributable reference implementation of all aspects of DHCP, through a suite of DHCP tools:

  • A DHCP server
  • A DHCP client
  • A DHCP relay agent
• pSeries and AIX Information Center/TCP/IP address and parameter assignment - Dynamic Host Configuration Protocol
• DHCP FAQ
• ISC DHCP
• NetWare Connection
• Deploying and Troubleshooting Meta IP
• Advanced Topics in DNS Administration

FAQs

FAQ for Windows 2000

DHCP FAQ

Recommended Papers

DHCP for Windows 2000 Managing the Dynamic Host Configuration Protocol Chapter 4 Designing a DHCP Infrastructure

Designing a Windows 2000 Network Infrastructure Developing DHCP Strategies

Network Access Control for DHCP Environment Kazumasa Kobayashi <[email protected]>
Suguru Yamaguchi <[email protected]> Nara Institute of Science and Technology Japan

RFCs

Dynamic Host Configuration Protocol (RFC 1531) (96192 bytes) obsoleted by RFC 1541

RFC 2131 Dynamic Host Configuration Protocol

RFC 2132 DHCP Options and BOOTP Vendor Extensions

DHCP Options and BOOTP Vendor Extensions (RFC 1533) (50919 bytes) obsoletes RFC 1497/ obsoleted by RFC 2131,RFC 2132
Interoperation Between DHCP and BOOTP (RFC 1534) (6966 bytes)
Clarifications and Extensions for the Bootstrap Protocol (RFC 1532) (51545 bytes) obsoletes RFC 951/ obsoleted by RFC 1542
Dynamic Host Configuration Protocol (RFC 1541) (96950 bytes) obsoletes RFC 1531/ obsoleted by RFC 2131
Clarifications and Extensions for the Bootstrap Protocol (RFC 1542) (52948 bytes) obsoletes RFC 1532
Dynamic Host Configuration Protocol (RFC 2131) (113738 bytes) obsoletes RFC 1533,RFC 1541/ updated by RFC 3396,RFC 4361
DHCP Options and BOOTP Vendor Extensions (RFC 2132) (63670 bytes) obsoletes RFC 1533/ updated by RFC 3442,RFC 3942,RFC 4361
Netware/IP Domain Name and Information (RFC 2242) (10653 bytes)
DHCP Options for Novell Directory Services (RFC 2241) (8419 bytes)
DHCP Option for The Open Group's User Authentication Protocol (RFC 2485) (7205 bytes)
Procedure for Defining New DHCP Options (RFC 2489) (10484 bytes) obsoleted by RFC 2939
DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients (RFC 2563) (17838 bytes)
DHCP Options for Service Location Protocol (RFC 2610) (10859 bytes)
Procedure for Defining New DHCP Options and Message Types (RFC 2939) (13631 bytes) obsoletes RFC 2489
The Name Service Search Option for DHCP (RFC 2937) (8368 bytes)
The User Class Option for DHCP (RFC 3004) (10423 bytes)
The Subnet Selection Option for DHCP (RFC 3011) (13967 bytes)
DHCP Relay Agent Information Option (RFC 3046) (30633 bytes)
DHC load balancing algorithm (RFC 3074) (19374 bytes)
Authentication for DHCP Messages (RFC 3118) (35536 bytes)
DHCP reconfigure extension (RFC 3203) (11857 bytes)
The DOCSIS Device Class DHCP Relay Agent Information Sub-option (RFC 3256) (8551 bytes)
Encoding Long Options in DHCPv4 (RFC 3396) (18779 bytes) updates RFC 2131
The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 (RFC 3442) (19370 bytes) updates RFC 2132
Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration (RFC 3495) (26817 bytes)
Link Selection sub-option for the Relay Agent Information Option for DHCPv4 (RFC 3527) (16831 bytes)
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (RFC 3315) (231402 bytes) updated by RFC 4361
PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration (CCC)Option (RFC 3594) (12521 bytes)
DNS Configuration Options for DHCPv6 (RFC 3646) (13312 bytes)
IPv6 Prefix Options for DHCPv6 (RFC 3633) (45308 bytes)
KDC Server Address Sub-option (RFC 3634) (13163 bytes)
Unused DHCP Option Codes (RFC 3679) (13804 bytes)
Stateless DHCP Service for IPv6 (RFC 3736) (18510 bytes)
NIS Configuration Options for DHCPv6 (RFC 3898) (13955 bytes)
Vendor-Identifying Vendor Options for DHCPv4 (RFC 3925) (17999 bytes)
Reclassifying DHCPv4 Options (RFC 3942) (13996 bytes) updates RFC 2132
RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option (RFC 4014) (15416 bytes)
DHCP Subscriber ID Suboption for the DHCP Relay Agent Option (RFC 3993) (13938 bytes)
Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) (RFC 4039) (22297 bytes)
The Authentication Suboption for the DHCP Relay Agent Option (RFC 4030) (34332 bytes)
Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 (RFC 4075) (9424 bytes)
Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (RFC 4076) (15745 bytes)
The IPv4 Dynamic Host Configuration Protocol (DHCP) Options for the Internet Storage Name Service (RFC 4174) (29485 bytes)
Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (RFC 4242) (14759 bytes)
Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers (RFC 4280) (23001 bytes)
Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (RFC 4243) (14342 bytes)
Node-Specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) (RFC 4361) (28009 bytes) updates RFC 2131,RFC 2132,RFC 3315
Dynamic Host Configuration Protocol (DHCP) Leasequery (RFC 4388) (63914 bytes)
Detecting Network Attachment in IPv4 (DNAv4) (RFC 4436) (35991 bytes)
Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues (RFC 4477) (30440 bytes)
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option (RFC 4580) (10937 bytes)
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option (RFC 4649) (10940 bytes)

IETF-Drafts:

Books

Beyond Dhcp - Work Your Tcp/Ip Internetwork With Dynamic Ip by IBM Redbooks (Paperback - Jan 2000)

The DHCP Handbook (2nd Edition) Books Ralph Droms,Ted Lemon

DHCP for Windows 2000 Books Neall Alcott

DHCP: A Guide to Dynamic TCP/IP Network Configuration by Berry Kercheval (Hardcover - Jan 15, 1999)

Troubleshooting

Planning, Implementing, and Troubleshooting DHCP Understanding DHCP

Although DHCP is typically one of the easiest of the common network services to configure and maintain, from time to time, you might encounter problems. More often than not, the DHCP-related problems that arise stem from a misconfiguration in a scope, unauthorized DHCP servers on the network, or network connectivity problems. You might also find information that has changed in some way, but the change has not been reflected in your DHCP configuration, as in the case of DHCP reservations (which are tied to MAC addresses) or a DHCP server's IP address change. The following sections examine some troubleshooting tasks you can do to quickly determine the cause of DHCP woes and get this vital network service back into proper operation.

Troubleshooting DHCP Server Authorization Problems

As discussed previously, one of the first indicators you might see of an unauthorized or rogue DHCP server is an unexpected increase in the number of DHCPNACK messages. You can monitor this statistic over time by using the Performance console. The Performance console includes several counter objects that you can use to monitor and troubleshoot your DHCP server:

• Acks/Sec-This counter monitors the number of DHCPACK messages sent per second by the DHCP server to client computers. The DHCP server uses the DHCPACK messages to acknowledge requests for an address. An increase in this number indicates that a large number of client computers are probably trying to renew their leases with the DHCP server. This could be because of a short lease time configuration or because a number of new computers are entering the network.
• Active Queue Length-This counter monitors the current length of the internal message queue of the DHCP server. This number represents the number of unprocessed messages received by the server. A large number here could indicate an unusually large amount of network traffic or a heavy load on the server.
• Conflict Check Queue Length-This counter monitors the current length of the conflict check queue for the DHCP server. Before a Windows Server 2003 DHCP server issues an address, it checks whether any IP address conflicts exist. The conflict check queue holds the messages not responded to while the DHCP server performs address conflict detection. A large value here could indicate heavy lease traffic at the server. You might also want to check the Conflict Detection Attempts parameter, which could be set too high.
• Declines/Sec-This counter monitors the number of DHCPDECLINE messages that the DHCP server receives per second from client computers. This counter indicates that the DHCP client computer has declined the IP address issued by the server. You see this number rise when client computers start having address conflict problems, and it could indicate a network problem, computers with static addresses also being part of a scope, or a rogue DHCP server on the network.
• Discovers/Sec-This counter monitors the number of DHCPDISCOVER messages received per second by the server. The DHCPDISCOVER message is the initial request a client computer sends when it first enters the network and looks for a DHCP server to issue an address. A sudden increase in this counter could indicate that a large number of client computers are attempting to initialize and obtain an IP address lease from the server at the same time. You might see this first thing in the morning, when users power on their PCs, or after a power failure, when all the PCs might be powered on at about the same time.
• Duplicates Dropped/Sec-This counter monitors the number of duplicate packets per second dropped by the DHCP server. Duplicate packets on a network are never a good sign, and they can indicate that DHCP clients are timing out before the server can respond. This can be caused by client computers timing out too fast or the server not responding quickly enough.
• Informs/Sec-This counter monitors the number of DHCPINFORM messages received per second by the DHCP server. DHCPINFORM messages are used when the DHCP server queries the directory service for the enterprise root and when dynamic updates are being done on behalf of client computers by the DNS server. This is part of the DDNS integration, and an unusual increase in this number could indicate a large number of addresses being issued.
• Milliseconds Per Packet (Avg)-This counter monitors the average time, in milliseconds, the DHCP server takes to process each packet it receives. This is a very subjective number that depends on the server configuration; therefore, having a baseline for this number is a good idea. A sudden increase in this counter could indicate a disk problem or an increased load on the server.
• Nacks/Sec-This counter monitors the number of DHCP negative acknowledgment (DHCPNACK) messages sent per second by the DHCP server to client computers. A DHCPNACK message indicates that the server cannot fulfill the DHCP request. A very high value for this counter could indicate a network problem or a misconfiguration of client computers or the server. Watch for a deactivated scope as a possible culprit.
• Offers/Sec-This counter monitors the number of DHCPOFFER messages that the DHCP server sends per second to client computers. A DHCPOFFER message is the message the server returns to the client computer after the client computer sends a DHCPDISCOVER message, and it indicates that the server is offering to issue an address to that client computer. A sudden increase in this value could indicate heavy traffic or a heavy load on the server.
• Packets Expired/Sec-This counter monitors the number of packets per second that expire and are dropped by the DHCP server. This situation is caused by a packet remaining in the server's internal message queue too long. A large number for this counter indicates that the server either is taking too long to process some packets or is causing other packets to wait in queue, or that the traffic on the network is too heavy for the DHCP server to handle. It is important to note that high numbers for this counter can indicate pure network traffic problems and not necessarily DHCP-related problems.
• Packets Received/Sec-This counter monitors the number of message packets received per second by the DHCP server. A large number indicates heavy DHCP message traffic to the server. These message packets might be requests for addresses, renewals, or releases.
• Releases/Sec-This counter monitors the number of DHCPRELEASE messages that the DHCP server receives per second from client computers. A DHCPRELEASE message is sent only when the client computer manually releases an address, such as when the ipconfig /release command is used or the Release All button in the winipcfg utility is used at the client computer. Because most users do not manually release their addresses, this number should be low in all but the most unusual network environments.
• Requests/Sec-This counter monitors the number of DHCPREQUEST messages that the DHCP server receives per second from client computers. These messages are the requests that the client computer sends to request an IP address after it has found a server that can issue addresses. An increase in this number indicates that a large number of client computers are probably trying to renew their leases with the DHCP server. This could be caused by a short lease time configuration or by a number of new computers entering the network.

Configuring the Performance console to monitor and collect data about a DHCP server is a simple process, as outlined in Step by Step 3.7.

Step By Step 3.7: Monitoring DHCP Performance

1. Select Start, Program, Administrative Tools, Performance to open the Performance console.
2. Click System Monitor, as shown in Figure 3.34.

   

   Figure 3.34 You can view server performance statistics by using the Performance console.

3. To create an entry in System Monitor, click the + icon. The Add Counters dialog box shown in Figure 3.35 opens, enabling you to begin adding counters.

   

   Figure 3.35 You can add counters to begin monitoring DHCP server statistics.

4. Select the DHCP Server performance object in the Performance object drop-down list box. You then see the list of counters available for selection that relate to the DHCP service. If you need to know what a counter means, select the counter and click the Explain button.
5. When you have decided what counter you want to monitor, click Add. You can add multiple counters either by selecting each counter and clicking Add or by holding down the Ctrl key while you select all the counters you want to monitor and then clicking Add. Click Close when you are finished. Your counters are graphed like those shown in Figure 3.36.

Figure 3.36 You can monitor DHCP server statistics in real time.

NOTE

Creating server baselines If you create baselines on servers, you can compare the performance at any given time to a known value. This can be very useful in performing troubleshooting, and it also helps when configurations are being modified. To create a baseline, you create a counter log from the Counter Logs option of the Performance Logs and Alerts node, shown in Figure 3.35. The configuration and use of a counter log is nearly identical to the creation and use of System Monitor, as described in Step by Step 3.7.

If you notice a trend of higher-than-normal DHCPNACK messages, you need to determine the source. The most common cause is a rogue DHCP server that has been set up on the network. You can also examine the DHCP lease properties of clients to determine whether any of them have different information than what you have configured in your DHCP scopes.

It's important to remember that Windows 2000 and Windows XP clients in an Active Directory environment that are configured to use DHCP do not accept leases from unauthorized DHCP servers. Older clients accept these leases and can contribute to the number of DHCPNACK messages when they attempt to renew their DHCP leases.

You can also examine the DHCP server daily audit logs, located in the %systemroot%\ sysytem32\dhcp folder, to look for rogue-detection events. The DHCP audit logs are discussed in the next section.

Using the DHCP Logs

The DHCP server daily audit logs are often overlooked as a valuable source of information. You have learned how to enable the audit logs; now let's look at what they contain. Unlike the logs the Windows 2000 Server DHCP service produces, the Windows Server 2003 daily audit logs are natively in text format; you open them simply by double-clicking them. A sample of what you might expect to find in a log is displayed here:

ID,Date,Time,Description,IP Address,Host Name,MAC Address
00,04/27/06,20:08:38,Started,,,,
55,04/27/06,20:08:39,Authorized(servicing),,lab1.area51partners.com,,
24,04/27/06,20:44:10,Database Cleanup Begin,,,,
25,04/27/06,20:44:10,0 leases expired and 0 leases deleted,,,,
25,04/27/06,20:44:10,0 leases expired and 0 leases deleted,,,,
24,04/27/06,21:44:12,Database Cleanup Begin,,,,
25,04/27/06,21:44:12,0 leases expired and 0 leases deleted,,,,
25,04/27/06,21:44:12,0 leases expired and 0 leases deleted,,,,
11,04/27/06,19:39:46,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
31,04/27/06,19:39:46,DNS Update Failed,
    192.168.0.231,xpclient01.corp.quepublishing.com,-1,
10,04/27/06,19:43:07,Assign,192.168.0.230,
    iMac01.corp.quepublishing.com,00306509D772,
30,04/27/06,19:44:14,DNS Update Request,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
31,04/27/06,19:44:14,DNS Update Failed,192.168.0.231,
    xpclient01.corp.quepublishing.com,-1,
30,04/27/06,19:47:03,DNS Update Request,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
11,04/27/06,19:47:03,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
30,04/27/06,19:47:03,DNS Update Request,
    192.168.0.231,xpclient01.corp.quepublishing.com,,
11,04/27/06,19:47:03,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
32,04/27/06,19:47:03,DNS Update Successful,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
32,04/27/06,19:47:03,DNS Update Successful,192.168.0.231,
    xpclient01.corp.quepublishing.com,,

As you can see from this example, the DHCP server cleans up the database hourly. You can also see that two clients requested leases. One of them, an Apple iMac, requested and was assigned the IP address 192.168.0.230, with no further actions. Another client, a Windows XP Professional computer, requested and received the IP address 192.168.0.231, with several failed DNS updates (evidenced by ID 31). After the DNS dynamic update account was properly configured, the DHCP server was able to make the DNS dynamic updates and generate an ID of 32. Table 3.3 explains the ID codes used in the DHCP daily audit logs.

Table 3.3. The DHCP Daily Audit Log ID Codes

ID	Description
00	The log was started.
01	The log was stopped.
02	The log was temporarily paused due to low disk space.
10	A new IP address was leased to a client.
11	A client renewed a lease.
12	A client released a lease.
13	An IP address was found to be in use on the network.
14	A lease request could not be satisfied because the scope's address pool was exhausted.
15	A lease was denied.
16	A lease was deleted.
17	A lease was expired.
20	A BOOTP address was leased to a client.
21	A dynamic BOOTP address was leased to a client.
22	A BOOTP request could not be satisfied because the scope's address pool for BOOTP was exhausted.
23	A BOOTP IP address was deleted after a check was made to see that it was not in use.
24	The IP address cleanup operation has begun.
25	IP address cleanup statistics are provided.
30	A DNS update request to the named DNS server was made.
31	The DNS update failed.
32	The DNS update was successful.
50+	These IDs are used for Rogue Server Detection information.

In addition to the DHCP daily audit logs, events related to the DHCP service are generated and placed in the system log, as shown in Figure 3.37.

Figure 3.37 The system log contains events related to the DHCP service.

As you can see in Figure 3.38, a DHCP server on the network has not been authorized in Active Directory. The system log contains many useful log events about all aspects of a server, and this is an area you should review often.

Figure 3.38 An unauthorized DHCP server cannot start the DHCP service.

Troubleshooting DHCP Reservations

For the most part, the only problem that prevents a DHCP reservation from functioning properly is a misconfigured MAC address. If you have a misconfigured DHCP reservation, it should show up in the Address Leases node of your DHCP server with the status Reservation (Inactive). Reservations that are configured properly show the status Reservation (Active). If you look back at Figure 3.16, you'll see that the reservation we created had a bad MAC address and, thus, was the cause of the problem in Figure 3.39.

Figure 3.39 A DHCP reservation that is not active usually indicates a misconfiguration.

To verify that a reservation is configured properly, you can compare the MAC address of the component that is to have a reserved DHCP address (a print server, for example) to the MAC address entered in the reservation Properties dialog box. The vast majority of the time, this will reveal the source of the problem.

Troubleshooting the DHCP Relay Agent

The DHCP relay agent, like a DHCP reservation, typically doesn't present a problem. However, in some cases, relay services are not being provided to network clients. Some of the most common problems that you might encounter with the DHCP relay agent include the following:

• The network interface on the DHCP relay agent server that is connected to the subnet where the DHCP clients are located has not been selected for use with the DHCP relay agent. You can verify whether the interface has been added or add it from the DHCP Relay Agent node of the DHCP console. You should also verify that the Relay DHCP Packets check box is selected on all adapters that have been selected for use.
• An incorrectly entered DHCP server IP address on the DHCP Relay Agent Properties dialog box (refer back to Figure 3.32) prevents the successful relay of packets. You can verify and correct this problem from the properties dialog box of the DHCP Relay Agent node of the DHCP console.
• Remote DHCP servers might not be reachable because of network or server problems. In this case, you need to troubleshoot basic network connectivity, as discussed in Chapter 1, "Planning, Implementing, and Troubleshooting a TCP/IP Network Infrastructure". You should troubleshoot the server status as discussed in this chapter.
• DHCP traffic might be being filtered. In this case, you need to ensure that no IP filters exist for UDP ports 67 and 68 at any point between the DHCP servers and the remote DHCP clients.

Quiz

Q1. Which protocol allows automation of the IP assignment process ?

A: DHCP

Q2. DHCP stands for _____________________ ?

A: Dynamic Host Configuration Protocol

Q3. You have a team of several network administrators. They work independently. Often, they end up assigning same IP to multiple machine. Would using DHCP solve this problem ?

A: Yes

Q4. How many DHCP IP address pools are supported ?

A: 21

Q5. True/Flase: Same DHCP server can support multiple subnets .

A: True

Q6. which command releases and removed DHCP leases ?

A: dhcpagent

Q7. Which command displays value of parameters received through DHCP ?

A: dhcpinfo

Q8. What does a secondary dhcp server do when the primary server is unable to respond ?

A: confirms existing configuration supplied by primary

Q9. Which command will initialize the dhcptab ?

A: dhcpconfig

Q10. where does dhcptab reside ?

A: /var/dhcp/dhcptab

Q11. Where would you find DHCP information about supported network 128.251.144.0 ?

A: /var/dhcp/128_251_144_0

Q12. Which file contains information related to client (dhcp) configuration ?

A: dhcptab

Q13. Which 2 commands modifies the dhcptab file ?

A: pntadm and dhtadm

Q14. Which value of "Flags" in the DHCP network database denotes a permanent lease ?

A: 1

Q15. What are entries in the DHCP network database ?

A: Client ID , Flags, Client IP, Server IP, Lease, Macro, Comments

Q16. Which value in the "flags" field in the DHCP network database denotes that the evaluation of the DHCP lease is turned on ?

A: 0

Q17. True/False: Each record in the DHCP network database has an associated to DHCP zone IP address .

A: True

Q18. What does the "Lease" field hold in the dhcp network database ?

a. how long the client has the lease for (length)

b. how long remains of the lease

c. absolute time when the lease expires

A: C

Q19. Which comamnd will yield the current dhcp information on the DHCP server ?

A: dhtadm –P

Q20. which file tells the dhcp daemon where to find its configuration?

A: /etc/inet/dhcpsvc.conf

Q21. which command will show you the entry for the host fred from the "hosts" administrative database ?

A: getent hosts fred

Q22. How can you start the DHCP daemon ?

A: /etc/init.d/dhcp start

Q23. How do you shutdown the DHCP daemon ?

A: /etc/init.d/dhcp stop

Q24. Which option of the dhtadm command creates the DHCP service configuration table, dhcptab ?

A: -C

Q25. Which option of the dhtadm command adds a symbol or macro definition to dhcptab ?

A: -A

Q26. Which option of the dhtadm command modifies an entry in the dhcptab table ?

A: -M

Q27. Which option of the dhtadm command removes symbol or macro definition from dhcptab ?

A: -D

Q28. Which option of the dhtadm command deletes the dhcptab table entirely ?

A: -R

Q28: Put the DHCP client and DHCP server interaction steps into the appropriate sequence:

1. DHCPREQUEST

2. DHCPOFFER

3. DHCPDISCOVER

4. DHCPACK

A: c,b,a,d

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last Modified: June 14, 2021