{"id":307,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:00","modified_gmt":"2020-08-22T20:26:00","slug":"this-is-the-page-title-toplevel-142","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=307","title":{"rendered":"DHCP"},"content":{"rendered":"\nDHCP<\/title>\n<p>\nOne of the most tedious jobs of any system <glossary>administrator<\/glossary>\nis configuring each\nmachine so it can talk to the <glossary>network<\/glossary>.\nIn many cases, this means physically\ngoing to each machine and making the necessary changes. Even if the changes are\naccomplished by one of the various configuration programs (linuxconf, yast,\netc.), it is still a hassle to have to do this on multiple machines. What makes\nmatters worse is when changes are made to your <glossary>network<\/glossary>,\nsuch as changing routes\nor which machine is your <glossary>name server<\/glossary>,\nyou have to go through everything again.\nAlthough such changes hopefully do not occur too often, obviously the more\nmachines you administer, the longer it takes to make the changes by hand.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What is the purpose of the Dynamic Host Configuration Protocol?\" \/>\n<concept id=\"\" description=\"The Dynamic Host Configuration Protocol is used to centrally configure and manage the network configuration of all of your systems\" \/>\n<p>\nWhat is needed is a way to centrally configure and manage the network\nconfiguration of all of your systems. This is accomplished using the Dynamic\nHost Configuration Protocol (DHCP). Even if you are running a <glossary>network<\/glossary>\nwith a handful of machines, then you may want to consider DHCP. It is generally\nplug-n-play, in that a machine can be added to the <glossary>network<\/glossary>\nwith basically no additional configuration effort on your part, saving your\nhours of configuration time.\n<\/p>\n<p>\nThe version of DHCP provided with most Linux distributions includes the <glossary>DHCP<\/glossary> server, but also the DHCP <glossary>client<\/glossary>,\n as well as\na DHCP relay, which allows you to have a central DHCP server which manages\nmultiple networks. The current distributed release is version2, with version 3\nalready in the beta stage.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"Which of the following is not true about DHCP?\" \/>\n<question id=\"\" type=\"tf\" text=\"The most common function of DHCP is to translate host names to IP addresses for various network services.\" \/>\n<question id=\"\" type=\"tf\" text=\"Because of the 'dynamic' nature of DHPC, it always assigns different IP addesses each time a machine requests an IP address.\" \/>\n<concept id=\"\" description=\"The most common function of DHCP is to assign IP addresses to machines a network.\" \/>\n<p>\nThe most basic (and perhaps\nmost commonly known) function of <glossary>DHCP<\/glossary> is to assign\n<glossary>IP<\/glossary> addresses to machines\nwithin a <glossary>network<\/glossary>.\n Although dynamically assigning the addresses is one of the key\nadvantages of <glossary>DHCP<\/glossary> it is not a requirement. That is, you <em>could<\/em> configure\nDHCP to assign specific addresses to specific machines. For example, I have done\nit in some networks for the servers, as well as the clients. Each machine was\nconfigured to use DHCP, but the servers needed to have static addresses. Rather\nthan configuring the servers themselves with a particular <glossary>address<\/glossary>,\nwe did this using DHCP. That way, should routers, <glossary>DNS<\/glossary>\nservers, or whatever get changed, we did not need to reconfigure the servers.\n<\/p>\n<p>\n<glossary>DHCP<\/glossary> is also useful in environments\nwhere you have a people with laptops working in multiple networks, such as\npeople who regularly work out of the home, but still come into the office. Other\ncases are people who visit many of your branch offices and where these offices\nare on different networks. If the laptop is configured to use DHCP and there is\na DHCP server at each location, the laptop is automatically configured for the\n<em>local<\/em> <glossary>network<\/glossary>.\nIn fact, I use it at home on my four-node network, so I don’t\nhave to deal with configuring each machine individually (or re-configuring it).\n<\/p>\n<p>\nWhen the <glossary>DHCP<\/glossary> server (<command>dhcpd<\/command>) starts it reads it configuration file, which\ndefaults to <file type=\"\">\/etc\/dhcp.conf<\/file>, but can be changed when the server is started using\nthe -cf option. Using the configuration file, DHCP stores the list of addresses\nin memory for each of the subnets to which it provides services. When a DHCP\nclient starts, it requests an <glossary>address<\/glossary>.\n The server looks for an available address\nand assigns it to the <glossary>client<\/glossary>.\n Should the specific client be configured a static\naddress, then it is this <glossary>address<\/glossary>,\n which is returned to the <glossary>client<\/glossary>.\n<\/p>\n<p>\nThe assignment of the <glossary>IP<\/glossary>\n<glossary>address<\/glossary>\nto the machine is referred to as a lease. Like\nleases in other contexts, DHCP leases are only valid for a specific period of\ntime. The default is one day, but you can configure it to be most any value. In\naddition, it is also possible for the <glossary>client<\/glossary>\nto request a specific lease\nduration. However, to prevent any machine from holding on to the lease and not\nletting go, you can configure the server with a maximum lease time.\n<\/p>\n<p>\nDepending on your <glossary>network<\/glossary>\nsetup, it may be necessary to limit DHCP to just a\nsingle <glossary>network<\/glossary>\n<glossary>segment<\/glossary>.\n This could be a problem if the DHCP server is sitting on\nboth segments. However, DHCP can be configured to listen for requests on just\nspecific <glossary>network<\/glossary>\ninterfaces. In addition, if for some reason your system cannot\ndetermine whether a specific interface can\n<\/p>\n<p>\nObviously, the DHCP server needs a means of keeping track of the leases across reboots of either the server or\nthe clients. This is accomplished with the dhcpd.leases files, which is\ntypically in the <directory>\/var\/state\/dhcp<\/directory> directory. After reading the <file type=\"\">dhcpd.conf<\/file> file at\nsystem startup, the server reads the <filecontents type=\"\">dhcpd.leases<\/filecontents> file and marks accordingly\nthose systems that have active leases.\n<\/p>\n<p>\nOne important thing to note is that\nunlike other system services, <glossary>dhcpd<\/glossary> does not re-read its configuration file\nwhile it is running. Therefore, you need to restart the server by hand each time\nyou make a change. Also, the <file type=\"\">dhcpd.leases<\/file> file is not rewritten each time the\nserver is started. Instead, the file is maintained across reboots, so that the\nstate of each lease is saved.\n<\/p>\n<p class=\"subtitle\">Basic Server Configuration\n<\/p>\n<p>\nThe <file type=\"\">dhcpd.conf<\/file>\nfile is very straightforward and easy to comprehend. At the top is a\n<glossary>header<\/glossary>,\nwhich contains the global configuration parameters for the server itself and\nwhich is applicable to each of the supported subnets, unless specifically\noverridden. Following that are the configuration declarations for all subnets\naccessible from the server, whether they are actually provided DHCP services or\nnot.\n<\/p>\n<p>\nConfiguration is done by various statements in the dhcpd.conf file,\nwhich can be either a declaration or parameter. A declaration is used to\ndescribe the topology of your <glossary>network<\/glossary>,\nas it is these declarations that specify\nfor which subnets or even individual <glossary>host<\/glossary>\nspecific configuration is valid.\nParameters define the various characters, such as how to do something (which\nroute to take), how to behave (the length a lease is valid) or basic\ncharacteristics, such as the <glossary>IP<\/glossary> address.\n<\/p>\n<p>\nIn its simplest form a <glossary>DHCP<\/glossary>\nconfiguration entry consists of a <glossary>subnet<\/glossary>\n<glossary>address<\/glossary>, the <glossary>netmask<\/glossary>\nand the range of IP addresses. For example, you might have something that looks like this:\n<\/p>\n<p>\n<screenoutput>\nsubnet 10.2.0.0 <glossary>netmask<\/glossary>\n255.255.0.0 { range 10.2.3.0 10.2.3.200; }\n<\/screenoutput>\n<\/p>\n<p>\nThis entry applies to the Class A <glossary>network<\/glossary>\n10.2.0.0. However, only addresses in a much\nsmaller <glossary>network<\/glossary>\n(10.2.3.0) are available. In fact, not all of the\naddresses in that range are available, since the highest <glossary>address<\/glossary>\nis 10.2.3.200.\nNote that each entry is followed by a semi-colon. Hosts can also be configured\nindividually using the <glossary>host<\/glossary>\nkeyword, which is followed by the name of the host.\n<\/p>\n<p> In this example, we used the hardware and fixed-address options to define\nthe configuration for this specific <glossary>host<\/glossary>.\n<\/p>\n<p>\nThese have the general syntax:\n<\/p>\n<p>\n<filecontents type=\"\">\noption option-name option-data\n<\/filecontents>\n<p>\nWhat is valid as “option-data” will depend on\nthe option you use. Some are <glossary>IP<\/glossary>\naddresses or hostnames; others are can be text\nstrings or numbers, while others are simply Boolean values (true\/false or\non\/off). Note that you actually need to include the word “option” to tell the\nDHCP server that what follows is an option and not a <glossary>subnet<\/glossary>\ndeclaration or\nsomething else. Keep in mind that if an option specified as a global parameter,\nit applies to all of the subnets. However as mentioned above, your can also\noverride this value in one of the <glossary>subnet<\/glossary>\ndefinitions.\n<\/p>\n<p> Table 1 gives you a\nlist of the more common dhcpd options. However, there are several dozen more,\nmany of which only apply to specific protocols or services such as NNTP, finger,\nIRC, and so forth. For a complete list of options with even more details, check\nout the dhcp-options <glossary>man-page<\/glossary>.\n<\/p>\n<p>\nOne of the <glossary>host<\/glossary>\nspecific definitions is\n“hardware” which describes the specific hardware. As of this writing only the\n“<glossary>ethernet<\/glossary>” and “<glossary>token-ring<\/glossary>” hardware types are supported. Following the type is\nthe physical <glossary>address<\/glossary>\nof the card (i.e. the <glossary>MAC address<\/glossary>). For example, you might\nhave something like this:\n<\/p>\n<p>\n<screenoutput>host saturn { hardware ethernet 00:50:04:53:F8:D2; fixed-address 192.168.42.3: }<\/screenoutput>\n<\/p>\n<p>\nThis example says that the\nmachine saturn has an <glossary>Ethernet<\/glossary>\ncard with the MAC <glossary>address<\/glossary>\n00:50:04:53:F8:D2 and\nit to be assigned the fixed <glossary>address<\/glossary>\n192.168.42.3.\n<\/p>\n<p>\nSometimes you need to\nspecify options for a number of machines on your <glossary>network<\/glossary>\nwithout having to treat\nthem as a separate <glossary>subnet<\/glossary>.\n For example, you could define a subnet for a group of\nmachines and then apply specific options just to that <glossary>subnet<\/glossary>.\n However, this\nmeans that you will generally have specify all of the necessary configuration\noptions, plus these special nodes obviously cannot have <glossary>IP<\/glossary>\naddresses in the same\nsubnet as the others.\n<\/p>\n<p>\nTo overcome this limitation, you can group machines\ntogether using the group keyword. Then, all the options included within the\ngroup definition apply to that group. However, it is also possible to specify\nparameters for specifics. Like subnets, it is also to specify individual hosts\nwith the group. For example:\n<\/p>\n<p>\n<screenoutput>\ngroup { default-lease-time 300000; option routers 192.168.42.1;\nhost jupiter{ hardware ethernet 00:50:04:53:D5:57;\n default-lease-time 500000; }\nhost saturn { hardware ethernet 00:50:04:53:F8:D2;}\nhost uranus { hardware ethernet 00:50:04:53:32:8F;}\n}\n<\/screenoutput>\n<p>\nIn this example, we set the default lease time (how long the lease is valid) for\nthe group to 500000 seconds (almost 6 days) and the <glossary>router<\/glossary>\nto be the machine 192.168.42.1. This definition applies to the three hosts\nlisted. However, with the <glossary>host<\/glossary> jupiter we set the default\nlease time to a higher value, but the <glossary>router<\/glossary> definition\nwould still apply.\n<\/p>\n<p>\nAnother consideration is when there are multiple networks on the same physical\n<glossary>network<\/glossary> <glossary>segment<\/glossary>. There are several reasons that such a configuration is necessary and the ISC DCHP provides you with the ability to configure your system accordingly. This is done by declaring a shared-network.\n<\/p>\n<p>\nA shared <glossary>network<\/glossary>\nis basically nothing more than a container for a group of machines. One\ndifference to the group declaration is that a shared-network declaration can\ncontain subnets, as well as groups or individual hosts. It has the general\nsyntax:\n<\/p>\n<p>\n<screenoutput>\nshared-network network-name {\nshared-network-specific parameters\nsubnet {\nsubnet-specific parameters\n }\n group {\n group-specific parameters\n }\n}\n<\/screenoutput>\n<\/p>\n<p>\nNote that within either the group or <glossary>subnet<\/glossary>\ndeclarations, you can specify parameters for individual hosts, just as when they\nare not part of a shared-network.\n<p>\nAlthough the configuration of the DHCP server is pretty straightforward, having\nto administer a large number of systems by editing files can become tedious.\nOne solution I found useful is Webmin (www.webmin.com). This provides a\ngraphical, web-based interface to a large number of system functions (including\n<glossary>DHCP<\/glossary>). Figure 1, shows you the primary DHCP configuration page. At the top you\nsee three subnets which this machine managers. Here, too, you would also see any\nshared networks that are configured.\n<\/p>\n<p>\nUnderneath are any machines that are specifically configure as well as groups of\nmachines. When you select each object, you are can configure the same options as\nyou can be editing the files. Figure 2, shows you the configuration for a\nspecific <glossary>host<\/glossary>.\n<\/p>\n<p>\n<b>Troubleshooting the Server<\/b>\n<p>\nWith complex DHCP configurations it is often difficult to tell which parameter\napplies to any given <glossary>host<\/glossary>. When trying to figure out what\nis happening, there are two rules of thumb. First, <glossary>host<\/glossary>\nor group declarations can specifically override the global definition. In addition, host declarations can override the group declarations.\n<\/p>\n<p>\nSecond, definitions are not necessarily applied in the order in which they\nappear in the dhcpd.conf file. Instead, the values are applied starting from\nthe specific moving to the more general. That is, the server first checks for a\nspecific <glossary>host<\/glossary> configuration, then for a group\nconfiguration, then the <glossary>subnet<\/glossary> configuration, followed by a\nshared-network configuration, followed by the global declarations. Configuration\noptions are only added to and not overwritten. Therefore, the configuration for\nthe smaller, more specific units (like hosts) overrides those of the more\ngeneral units (like global parameters). So, when trouble shooting, start at the\nbottom, working your way up.\n<\/p>\n<p>\nPerhaps the most basic troubleshooting technique is to look at the leases the\nserver has assigned. This is done by looking at the leases file\n(<file type=\"\">\/var\/state\/dhcp\/dhcp.leases<\/file>), which maintains the current state of all active\nleases. One thing to note is that this file is rewritten from time to time to\nkeep the file from growing too large. First a temporary copy is made called and\nthe old file is renamed dhcpd.leases~. Although fairly rare, it can happen that\nfor some reason the server dies at this point. There is no dhcpd.leases file and\nthus server cannot restart. Rather than simply creating an empty dhcpd.leases\nfile, you need to rename dhcpd.leases~ to get things to work correctly.\n<\/p>\n<p>\nThe contents of the <directory>dhcpd.leases<\/directory> file is fairly straight forward. Each lease\ndeclaration is identified with the keyword “lease” followed by the IP address\nand a block of configuration information within curly brackets. For example, you\nmight have something like this:\n<\/p>\n<p>\n<screenoutput>\nlease 192.168.42.1 {\n starts 0 2000\/01\/30 08:02:54;\n ends 5 2000\/02\/04 08:02:54;\n hardware ethernet 00:50:04:53:D5:57;\n uid 01:00:50:04:53:D5:57;\n client-hostname “PC0097”;\n}\n<\/screenoutput>\n<\/p>\n<p>\nThe starts and ends statements indicate the period when the lease is valid.\nEach entry is of the form:\n<\/p>\n<p>\n<screenoutput>\nweekday yyyy\/mm\/dd hh:mm:ss;\n<\/screenoutput>\n<p>\nThe weekday is the numerical value for the day of the week starting with 0 on\nSunday, as in this case. One key aspect is that the date and time are\nGreenwich Mean Time and not local time.\n<\/p>\n<p>\nThe hardware entry is the same as from the dhcpd.conf file and list the hardware\n<glossary>address<\/glossary> of the card. The uid entry is unique identified\nfor the client, using either a <glossary>ASCII<\/glossary>\nstring <glossary>client<\/glossary>\nidentifier supplied by the client or the hardware <glossary>address<\/glossary>\npreceeded by hardware type (in this example “01”).\n<\/p>\n<p>\nOften times the <glossary>client<\/glossary>\nwants to pick its own name. There are two ways a client can do this. One is\nusing the “Client Hostname” option, as in this example. The other is using the\n“Hostname” option, which is used by many operating systems, such as\n<glossary>Windows 95<\/glossary>. In this cases, you would have just the keyword\n“hostname”, which is also followed by the name of the <glossary>host<\/glossary>.\n<\/p>\n<p>\nJust because the dhcpd.leases file contains a specific entry does not make it\nvalid. One approach would be to remove any applicable entry (based on either\nthe <glossary>IP<\/glossary> <glossary>address<\/glossary>\nor hardware address) and then re-start the server. If you end up with the same\nresults, there may be a problem with the way the <glossary>client<\/glossary> is\nconfigured.\n<\/p>\n<p>\nIt may also be necessary to see what the server thinks it is doing as compared\nto looking at the <glossary>client<\/glossary> or dhcpd.leases file and guessing\nwhat the server thinks it is doing. This can be accomplished by running the dhcp\nserver in the foreground (using the -f option) and having it output all of the\nerror messages to <glossary>stderr<\/glossary> (using the -d option) rather than using the system\nlogging <glossary>daemon<\/glossary>. You can then watch the server as it\naccepts and processes requests.\n<\/p>\n<p class=\"subtitle\">Client Configuration<\/p>\n<p>\nConfiguring the client-side is fairly straight forward, depending on your\ndistribution. For example, if you are running a SuSE 6.3, then all you need to\ndo is get into the <glossary>network<\/glossary> configuration portion of YAST\nand select the basic network configuration. Pressing F3 sets auto-IP\nconfiguration, which gives you the choice of configuring either <glossary>DHCP<\/glossary>\nor <glossary>BOOTP<\/glossary>.\nIf you select DHCP, you end with something like figure 2. This makes changes to\nthe file <file>\/etc\/rc.config<\/file> by setting the configuration parameters for the\nrespective card simply to “dhcpclient”. For example, without DHCP you might have\nan entry like this:\n<\/p>\n<p>\n<screenoutput>\nIFCONFIG_0=”192.168.42.1 broadcast 192.168.42.255 <glossary>netmask<\/glossary>\n255.255.255.0 up”\n<\/screenoutput>\n<\/p>\n<p>\nOnce DHCP is configured the entry would look like this:\n<\/p>\n<p>\n<screenoutput>IFCONFIG_0=”dhcpclient”\n<\/screenoutput><p>\nNote that you could have some of the interfaces configured to use DHCP and\nothers with static addresses. When the system boots, the <file type=\"\">\/etc\/rc.d\/network<\/file>\nscript is called (for example, as <file type=\"\">\/etc\/rc.d\/rc2.d\/S05network<\/file>). If it finds that\nthe IFCONFIG line for the respective card equals “dhcpclient”, it simply skips\nthe configuration of that interface, for the moment. Later in the\n<glossary>boot<\/glossary> process, the DHCP <glossary>client<\/glossary> script\nis started (for example, as <file type=\"\">\/etc\/rc.d\/rc2.d\/S05dhclient<\/file>).\nIt is here that the\n<glossary>client<\/glossary> then tries to get its configuration from the DHCP\nserver.\n<\/p>\n<p>\nOn other systems, like Caldera or Redhat, have their own configuration tool and\nchange the appropriate file in \/etc\/sysconfig\/network-scripts\/. For example,\nif you were configuring DHCP on your eth0 interface, the script ifcfg-eth0 would\nbe changed. When done you end up with something like this:\n<\/p>\n<p>\n<screenoutput>\nDEVICE=eth0\nIPADDR=0.0.0.0\nNETMASK=255.255.255.0\nNETWORK=\nBROADCAST=0.0.0.255\nGATEWAY=none\nONBOOT=yes\nDYNAMIC=dhcp\n<\/screenoutput>\n<p>\nFind the line labeled simply DYNAMIC= and change it to DYNAMIC=dhcp.\n<\/p>\n<p>\nIn most cases the default <glossary>client<\/glossary>\nconfiguration is sufficient (at least, in my experience). If not, the client has\nit’s own configuration file: <file type=\"\">\/etc\/dhclient.conf<\/file>. If you have more than one\ninterface on your system with different <glossary>network<\/glossary> option, you\nneed to group the options by interface. For example, you might have something\nlike this:\n<\/p>\n<p>\n<screenoutput>\ninterface eth0 {\nsend dhcp-lease-time 3600;\nrequest subnet-mask, broadcast-address, time-offset, routers,\n domain-name, domain-name-servers, host-name;\nrequire subnet-mask, domain-name-servers;\n}\n<\/screenoutput>\n<p>\nThe send statement tells the <glossary>client<\/glossary>\nto send the particular option with the specified value. These can be any of the\noptions the server understands and are defined in detail in the dhcp-options\n(5) <glossary>man-page<\/glossary>.\n<\/p>\n<p>\nThe request statement is a list of configuration options (not the values) that\nthe <glossary>client<\/glossary> requests that the server send. The key word is\n“request” as the required statement, says that the particular configuration\noption must be sent by a server in order for the <glossary>client<\/glossary> to\naccept the server’s response.\n<\/p>\n<p class=\"subtitle\">Security<p>\nAt first glance, there may not seem to be much to talk about in terms of\n<glossary>security<\/glossary> and <glossary>DHCP<\/glossary>. However, considering the importance of\nDHCP, a few precautions are in order.\n<\/p>\n<p>\nThe first consideration is the machine itself. Although an outage of a couple of\nhours might be something you can deal with, any long outage means that they may\nbe a number of machines without a valid configuration or even a valid\n<glossary>IP<\/glossary> <glossary>address<\/glossary>. Therefore, you need to\nlook at what other services the machine with your <glossary>DHCP<\/glossary> server provides. Since\nthere is very little computer power required to support DHCP, you can easily get\naway with smaller machines. This might be preferable to having the <command>dhcpd<\/command> running\nalong side some other machines. On the other hand, I worked in one company where\nthe DHCP server was also the <glossary>DNS<\/glossary> and mail server for the\ncompany.\n<\/p>\n<p>\nAnother issue to consider is a denial of service attack. If your DHCP server\nwere accessible from the Internet, it would be possible for someone to gobble\nup all of your <glossary>IP<\/glossary> addresses, leaving nothing for your own\nmachines. Therefore, you should block DHCP traffic through your firewalls. If\nyour firewall is running on a Linux machine, you can use the ipfwadm program to\nblock port 67 (the DHCP listen <glossary>port<\/glossary>) and port 68 (the DHPC transmit port).\n<p>\n<p>\nTable 1 – Common dhcpd.conf Configuration Options and Declarations\n<\/p>\n<p>\n<table>\n<tr>\n<td>Parameter <td>Description <td> Datatype\n<tr>\n<td>default-lease-time <td>Default length in seconds the lease is valid <td>Numeric\n<tr>\n<td>domain-name <td>The name of the <glossary>domain<\/glossary> for the specified subnet<td>Text\n<tr>\n<td>domain-name-servers <td>A list of name servers for the specified <glossary>subnet<\/glossary>.\n <td>List of <glossary>IP<\/glossary> addresses\n<tr>\n<td>fixed-address <td>Static <glossary>address<\/glossary>to assign to a <glossary>host<\/glossary>\n <td>List of <glossary>IP<\/glossary> addresses(supports multiple networks)\n<tr>\n<td>group <td> Starts a group declaration <td>N\/A\n<tr>\n<td>hardware <td>The type of hardware the <glossary>network<\/glossary>interface has (currently only ethernet and toke-ring are supported)\n<td>Harware-type: text<br \/>\n Hardware-address:<br \/>\n Octets, colon seperated.<br \/>\n<tr>\n<td>Host<td> Starts a <glossary>host<\/glossary>declaration <td>N\/A\n<tr>\n<td>host-name <td>Name to assign to the requesting <glossary>host<\/glossary> <td>Text\n<tr>\n<td>max-lease-time <td>Maximum time seconds the server will grant alease should the\n<glossary>client<\/glossary> request a specific lease\n<td> Numeric time\n<tr>\n<td>netbios-name-servers<td>Name of the WINS server <td> List of <glossary>IP<\/glossary> addresses\n<tr>\n<td>range<td>Range of <glossary>IP<\/glossary> addresses to assign on the specified network\n<td>Low and high IP address\n<tr>\n<td>routers <td>A list of routers to use <td>List of <glossary>IP<\/glossary> addresses\n<tr>\n<td>shared-network<td>Starts a shared <glossary>network<\/glossary> declaration <td>N\/A\n<tr>\n<td>subnet <td>Starts a <glossary>subnet<\/glossary> declaration <td>N\/A\n<tr>\n<td>subnet-mask <td>The subnet-mask of this <glossary>network<\/glossary>, group, host or <glossary>IP<\/glossary> address<td>\n<\/table>\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>DHCP One of the most tedious jobs of any system administrator is configuring each machine so it can talk to the network. In many cases, this means physically going to each machine and making the necessary changes. Even if the … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=307\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-307","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/307","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=307"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/307\/revisions"}],"predecessor-version":[{"id":541,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/307\/revisions\/541"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}