The DHCP vendor class is rarely modified on the server side, but what do you need to know about making these modifications and how can they be managed?
As networks become more advanced by offering the transport of additional services, such as telephone, video devices, virtual desktop devices, and other technologies, network administrators are frequently requested to add scope options to DHCP configurations. DHCP scope options are used frequently for the standard configurations items of IP address, subnet mask, default gateway, DNS servers, and other typical items that are the basic parameters of the network's desired configuration.
Recently, I was working with a concept situation that required the creation of a vendor identifier to interact with a proprietary device. Sounds easy enough, in fact, on Microsoft Windows DHCP servers, it is quite easy to do within the interface. However, what about non-Microsoft DHCP servers? At that point, I had to ask around, and I found myself asking none other than fellow TechRepublic network blog contributor David Davis. He gave me the direct answer for using Cisco-based DHCP services (thanks again, David!). The answer in this specific example revolved around the use of option 60 (vendor class identifier) and a hex value for use within IOS, Cisco's operating system for network equipment. The immediate takeaway here is that the vendor class is used differently across DHCP engines, so it is worth taking a look at what vendor class identifiers will be used in your environment.
Like other frequently used options for noncomputing devices, there may soon be duplicates. The good example in this space is the boot server or TFTP server scope option, used frequently by IP-enabled telephones. The long-term issue becomes what happens when one network is planned to contain two separate devices -- such as a phone and a security system camera for example -- that both need the same scope obscure option? One answer is to make separate networks, which was long the practice when IP-enabled telephones first arrived into company networks. For larger facilities, that may not be such a problem, but for remote sites such as a retail store or small office of three sales employees, would a network for the security camera, telephones, virtual desktop computers, and the time and attendance clock really be a manageable situation? How are you handling the inevitable entrance of noncomputing devices onto networks? Share your comments below.