Linux dhcp lease time

the Lease Declaration

Each lease declaration includes the single IP address that has been leased to the client. The statements within the braces define the duration of the lease and to whom it is assigned.

The start and end time of a lease are recorded using the starts and ends statements. The tstp statement is specified if the failover protocol is being used, and indicates what time the peer has been told the lease expires. The tsfp statement is also specified if the failover protocol is being used, and indicates the lease expiry time that the peer has acknowledged. The atsfp statement is the actual time sent from the failover partner. The cltt statement is the client’s last transaction time.

The date is specified in two ways, depending on the configuration value for the db-time-format parameter. If it was set to default, then the date fields appear as follows:

The weekday is present to make it easy for a human to tell when a lease expires — it’s specified as a number from zero to six, with zero being Sunday. The day of week is ignored on input. The year is specified with the century, so it should generally be four digits except for really long leases. The month is specified as a number starting with 1 for January. The day of the month is likewise specified starting with 1. The hour is a number between 0 and 23, the minute a number between 0 and 59, and the second also a number between 0 and 59.

Lease times are specified in Universal Coordinated Time (UTC), not in the local time zone. There is probably nowhere in the world where the times recorded on a lease are always the same as wall clock times. On most unix machines, you can display the current time in UTC by typing date -u.

If the db-time-format was configured to local, then the date fields appear as follows:

The seconds-since-epoch is as according to the system’s local clock (often referred to as «unix time»). The # symbol supplies a comment that describes what actual time this is as according to the system’s configured timezone, at the time the value was written. It is provided only for human inspection.

If a lease will never expire, date is never instead of an actual date.

hardware hardware-type mac-address;

The hardware statement records the MAC address of the network interface on which the lease will be used. It is specified as a series of hexadecimal octets, separated by colons.

The uid statement records the client identifier used by the client to acquire the lease. Clients are not required to send client identifiers, and this statement only appears if the client did in fact send one. Client identifiers are normally an ARP type (1 for ethernet) followed by the MAC address, just like in the hardware statement, but this is not required.

The client identifier is recorded as a colon-separated hexadecimal list or as a quoted string. If it is recorded as a quoted string and it contains one or more non-printable characters, those characters are represented as octal escapes — a backslash character followed by three octal digits.

Most DHCP clients will send their hostname in the host-name option. If a client sends its hostname in this way, the hostname is recorded on the lease with a client-hostname statement. This is not required by the protocol, however, so many specialized DHCP clients do not send a host-name option.

The abandoned statement indicates that the DHCP server has abandoned the lease. In that case, the abandoned statement will be used to indicate that the lease should not be reassigned. Please see the dhcpd.conf(5) manual page for information about abandoned leases.

binding state state; next binding state state;

The binding state statement declares the lease’s binding state. When the DHCP server is not configured to use the failover protocol, a lease’s binding state will be either active or free. The failover protocol adds some additional transitional states, as well as the backup state, which indicates that the lease is available for allocation by the failover secondary.

The next binding state statement indicates what state the lease will move to when the current state expires. The time when the current state expires is specified in the ends statement.

option agent.circuit-id string; option agent.remote-id string;

The option agent.circuit-id and option agent.remote-id statements are used to record the circuit ID and remote ID options send by the relay agent, if the relay agent uses the relay agent information option. This allows these options to be used consistently in conditional evaluations even when the client is contacting the server directly rather than through its relay agent.

The set statement sets the value of a variable on the lease. For general information on variables, see the dhcp-eval(5) manual page.

The ddns-text variable is used to record the value of the client’s TXT identification record when the interim ddns update style has been used to update the DNS for a particular lease.

The ddns-fwd-name variable records the value of the name used in updating the client’s A record if a DDNS update has been successfully done by the server. The server may also have used this name to update the client’s PTR record.

If the server is configured to use the interim ddns update style, and is also configured to allow clients to update their own fqdns, and the client did in fact update its own fqdn, then the ddns-client-fqdn variable records the name that the client has indicated it is using. This is the name that the server will have used to update the client’s PTR record in this case.

If the server successfully updates the client’s PTR record, this variable will record the name that the DHCP server used for the PTR record. The name to which the PTR record points will be either the ddns-fwd-name or the ddns-client-fqdn.

on events < statements. > The on statement records a list of statements to execute if a certain event occurs. The possible events that can occur for an active lease are release and expiry. More than one event can be specified — if so, the events are separated by ‘|’ characters.

bootp; reserved; These two statements are effectively flags. If present, they indicate that the BOOTP and RESERVED failover flags, respectively, should be set. BOOTP and RESERVED dynamic leases are treated differently than normal dynamic leases, as they may only be used by the client to which they are currently allocated.

Источник

Курс по основам компьютерных сетей на базе оборудования Cisco. Этот курс поможет вам подготовиться к экзаменам CCENT/CCNA, так как за его основу взят курс Cisco ICND1.

9.4 Время аренды IP-адреса в DHCP или lease time. Как происходит перезапрос и освобождение IP-адреса?

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей. Продолжаем рассматривать и разбирать протокол DHCP, на этот раз мы рассмотрим срок аренды IP-адреса в DHCP, который передается при помощи опции 51 (Option 51 IP Address Lease Time). В общем, нам нужно понять зачем нужно время аренды и как правильно настроить этот параметр в своей компьютерной сети.

9.4.1 Введение

Сразу скажу, что в DHCP-клиенты получают IP-адреса не насовсем, а на строго определенное время, которое задается на сервере, это время называется временем аренды IP-адреса или lease time. Такой механизм в DHCP необходим, поскольку было бы глупо заставлять сервер постоянно проверять: а пользуется ли клиент выданным IP-адресом? Во-первых, у сервера может быть несколько тысяч или десятков тысяч клиентов, а его ресурсы не бесконечны, во-вторых, представьте, как не экономно расходовалась бы полоса пропускания, если бы сервер проверял доступность клиентов.

В конце концов у клиента могли бы быть написаны правила безопасности, запрещающие отвечать на всевозможные проверки, например, на ping. И что тогда, сервер бы забирал ранее выданный IP-адрес и отдавал его другому клиенту? Тогда были бы конфликты IP-адресов, что не есть хорошо. Разработчики протокола DHCP решили по-другому, придумали более гибкий и в то же время надежный подход, они решили, что клиент должен получать IP-адрес на определенное время и при необходимости продлевать это время, сервер же в свою очередь, не должен выдавать IP-адрес никому другому, пока длится время аренды, как только оно закончится и не будет продлено, сервер будет вправе освободить адрес, а затем выдать его другому клиенту.

9.3.2 Зачем нужен срок аренды в DHCP и как его правильно выбрать?

Давайте начнем с того, что поговорим: зачем в протоколе DHCP нужно время аренды IP-адреса и как его правильно выбрать. А затем посмотрим на практике, как это всё работает.

9.3.2.1 Зачем нужно время аренды IP-адреса в DHCP?

Разберемся с первой частью вопроса. Все мы прекрасно понимаем, что количество IP-адресов в мире ограничено, особенно, если речь идет о протоколе IPv4. Если же говорить про локальную сеть, то здесь IP-адресов еще меньше, это будет не совсем точно, но можно сказать, что количество IP-адресов в локальной сети ограничено количеством частных IP-адресов. Кроме того, не стоит забывать и том, что мы должны выделить DHCP-серверу пул IP-адресов, чтобы сервер начал их раздавать клиентам, этот пул тоже не бесконечен.

Думаю, приведенных выше аргументов достаточно, чтобы понять важность опции время аренды в DHCP. Эта опция нужна, чтобы клиент не владел адресом до бесконечности. Ведь может возникнуть такая ситуация в сети, при которой клиента уже в ней нет, а DHCP-сервер держит ранее выданный IP-адрес за этим клиентом и никому другому его не отдает, хотя легко мог бы это сделать, и никакого конфликта бы не произошло. Как-то не экономнененько получается с учетом дефицита IP-адресов. Заставлять DHCP-сервер опрашивать своих клиентов – затея так себе, об этом я написал выше. Значит, надо сделать так, чтобы клиент не навсегда получал адрес, а на определенное время, как я уже говорил, это время называется lease time, но не подумайте, клиент ничего серверу не платит за то, чтобы получить IP-адрес, просто надо было как-то это дело назвать.

Когда время аренды будет истекать, клиент будет вправе продлить время пользования IP-адресом, а сервер может даже ему в этом отказать в некоторых случаях. Если время аренды истекло, то клиент будет обязан прекратить использование IP-адреса, дабы чего не произошло. Также клиент вправе в любой момент времени отказать от полученного IP-адреса, для этого есть специальное DHCP-сообщение DHCPREALEASE.

Бывают такие ситуации, при которых клиент отключается от сети, проходит какое-то время, за это время срок аренды истекает, а клиент вновь подключается к сети, в таком случае он попытается запросить у сервера тот IP-адрес, который был получен ранее и если этот IP-адрес будет свободен, то сервер его выдаст, если нет, то клиент получит другой IP-адрес.

В противовес бывают обратные ситуации. Клиент отключился от сети и подключился вновь, но время аренды еще не истекло, естественно, клиент сперва попытается достучаться до сервера, чтобы выполнить продление IP-адреса, если это сделать не удается, то клиент будет использовать старый IP-адрес до тех пор, пока время аренды не истечет.

В DHCP есть одно интересное сообщение, которое нигде не реализовано, его посылает сервер клиенту и называется оно DHCPFORCERENEW, этим сообщением сервер может заставить клиента отказаться от IP-адреса до истечения срока аренды, это сообщение очень сомнительно по своему функционалу, поэтому и не реализовано.

9.3.2.2 Рекомендации по выбору и настройки времени аренды в DHCP

Тут можно сказать, что рекомендаций нет и всё зависит от того, как долго клиент находится в сети, а можно сказать, что есть одна универсальная рекомендация: настраивайте время аренды IP-адреса в соответствие с потребностями пользователей вашей сети. Все станет понятно тогда, когда мы разберем с вами несколько примеров.

Для начала представим, что под нашим управлением находится ресторан быстрого питания с суточной пропускной способностью в тысячу человек человек, среднее время, которое посетитель находится в ресторане, составляет не больше 20 минут, да и не каждый посетитель хочет подключаться к нашей сети, чтобы воспользоваться халявным Интернетом. Тогда мы легко можем прийти к выводу, что для того, чтобы все были довольны, нам хватит сети с маской /25, а время аренды IP-адреса должно быть не более 20 минут, если посетитель будет пользоваться нашей сетью дольше 20 минут, то для него ничего страшного не произойдет, его устройство просто продлит время аренды.

Следующий пример. У нас есть офисная сеть с нормальным офисным планктоном, который работает пять дней в неделю по 8 часов. В нашей сети 50 сотрудников, которые раз в год уходят в отпуск на месяц и иногда болеют, все остальное время они работают. Вообще, тут напрашивается статика, но это очень лень, когда есть DHCP-сервер, поэтому смело выставляем время аренды несколько больше, чем 30 дней и берем сеть с маской /26. Все довольны.

И третий пример с выбором времени аренды. Представим себе, что мы администрируем сеть гостинцы, которая для поддержания статуса проводит в своих помещениях выставки и конференции. Первым делом нужно для себя определить следующее: посетители в гостинице есть всегда, а вот выставки – акция разовая. Поэтому будет логично иметь на DHCP-сервере, как минимум, два пула IP-адресов, один для посетителей (хотя тут вопрос спорный, можно создать по пулу на каждый этаж гостиницы), а другой пул для разовых акций, им будут пользоваться участники конференции. Размер первого пула должен быть чуть больше, чем среднее число постояльцев, это на тот случай, если будут гости, а время аренды выставлять дольше, чем на два часа не имеет смысла, поскольку посетитель в гостинице не живет постоянно. Размер второго пула зависит от числа участников, а время аренды ставить больше, чем на час, и не стоит.

Ну а что делать, если в гостинице есть важные клиенты, которые в любом случае должны иметь доступ к сети, в этом случае для таких гостей можно зарезервировать IP-адрес и не париться. Заметили, что я все время указывал сравнительно небольшие сетки, которые должен раздавать DHCP-сервер? Почему не стоит создавать большие пулы IP-адресов, даже скажу так: почему не стоит создавать пул больше, чем /24? Дело все в том, что и клиент, и сервер обычно находятся в одной канальной среде, что будет, если клиента заштормит или случится какая другая оказия, правильно, всем остальным клиентам тоже будет плохо, и они не смогут работать, а нас это не устраивает, ведь так? У нас все должны работать. А теперь представьте – каково это – искать заглючившую железку в огромной сети.

9.3.3 Истечение срока аренды IP-адреса или как DHCP-клиент делает повторный запрос?

К сожалению, тут я ничего продемонстрировать на практике не смогу, кроме опции, в которой сервер сообщает клиенту время аренды, поэтому поверьте на слово или попробуйте самостоятельно провести эксперимент на основе моего описания.

9.3.3.1 Ключевые особенности времени аренды

Ключевые особенности протокола DHCP, связанные с временем аренды мы уже перечислили ранее, но сделали это размыто, сейчас мы просто акцентируем внимание.

• любой клиент воспринимает IP-адрес, полученный по DHCP, как временный;
• срок аренды задается на DHCP-сервере администратором, не ждите, что я вам скажу какой срок используется по умолчанию, то всё зависит от желания разработчиков;
• как только срок аренды истек, клиент обязан прекратить использовать арендованный IP-адрес, ему нужно либо продлить аренду текущего, либо получить новый, но пока это происходит, старым адресом пользоваться нельзя;
• клиент вправе продлить время аренды, о том как он это может сделать, мы поговорим ниже;
• клиент может в любой момент прекратить пользоваться арендованным адресом, при этом он может сообщить об этом серверу при помощи специального сообщения (в этом случае сервер сразу же освободит IP-адрес), а может и не сообщать, тогда адрес будет освобожден сразу после окончания срока аренды;
• в DHCP есть механизм, который позволяет серверу заставить клиента освободить уже занимаемый IP-адрес, для этих целей используется сообщение DHCPFORCERENEW, но я не встречал таких реализаций;
• сервер вправе отклонить запрос клиента на продление IP-адреса, в этом случае он обязан будет послать сообщение DHCPNACK.

Эти особенности стоит помнить, при использовании протокола DHCP.

9.3.3.2 Option 51 IP Address Lease Time

Время аренды сообщает сервер клиенту, это тот процесс, за который отвечает сервер, администратор может изменить время аренды IP-адреса в любой момент. Для того, чтобы DHCP-сервер мог сообщить клиенту время аренды используется Option 51 (IP Address Lease Time). Если я всё правильно помню, то в качестве единиц измерения всегда используются секунды, ниже вы видите фрагмент дампа с сообщением DHCPOFFER, в котором сервер сообщает клиенту время, после которого IP-адрес должен быть освобожден.

9.4.1 Option 51. Сервер сообщает клиенту время аренды IP-адреса в сообщение DHCPOFFER

Тут стоит заметить, что клиент начинает отсчет времени сразу после того, как получит подтверждение от сервера, а сервер начинает отсчет после того, как зарезервирует IP-адрес за клиентом. При этом клиенту нужно заботиться только о себе любимом, а серверу приходится следить и помнить время каждого клиента.

9.3.3.3 Как клиент продлевает время аренды IP-адреса

Срок аренды IP-адреса обычно обозначается буквой Т, но мы для ясности будем считать, что клиент арендовал адрес на 100 секунд, как только он получил этот адрес, пошел отсчет: 100, 99, 98, 97… Но что если клиенту мало 100 секунд, может он хочет побыть в сети немного подольше, снова проходить весь процесс получения IP-адреса, это долго и это broadcast, то есть неудобно. Поэтому клиент сделает попытку продлить IP-адрес, у него есть на это право по истечению половины периода времени аренды, это у нас время равное T/2 или 50 секунд для нашего случая.

Клиент будет пытаться продлить IP-адрес при помощи сообщения DHCPREQUEST, но в отличие от получения, продление отправляется как unicast с использованием IP-адреса того сервера, у которого клиент получил IP-адрес. Если DHCPREQUEST таки дошел до сервера, то он отправит в ответ DHCPACK тоже юникастом, так он сообщает клиенту, что запрос получил и с ним согласен, можно снова начинать отсчет, начиная со 100 секунд.

А что если выдавший IP-адрес сервер вышел из строя, но есть резервный сервер, как поступит клиент? Клиент в этом случае отправит еще одно unicast сообщение на основной сервер на 75-ой секунде (это для нашего случая, а вообще, попытка будет сделана по истечению половины оставшегося времени) при этом, если половина оставшегося времени от времени аренды, это позже, чем 7/8Т, то есть 87.5% времени аренды или 87.5 секунд для нашей ситуации, то следующая попытка продления IP-адреса будет широковещательная.

Как только истекло 87.5 секунд, клиент начнет отправлять DHCPREQUEST в сеть, используя broadcast адрес, чтобы его слышали все, в том числе и резервный DHCP-сервер, если он, конечно, есть. Если резервный сервер есть, то он может продлить аренду клиенту, в этом случае клиент получит DHCPACK, а может отказать клиенту в продлении, например, если у резервного сервера нет пула IP-адресов, в который попадает IP-адрес клиента. Тогда сервер отправит клиенту DHCPNACK, а клиент поймет, что нужно просить другой адрес.

Как только срок аренды IP-адреса истек, клиент обязан перестать его использовать и пытаться получить новый IP-адрес, либо запустить механизм APIPA и придумать сам себе случайный IP в надежде, что он будет такой не один.

9.3.4 Освобождение IP-адреса и получение нового адреса в ОС Windows

В завершении разговора поговорим о том, как происходит освобождения IP-адреса до истечения времени аренды и получение нового IP на компьютерах под управлением Windows 10. Для этого нам потребуется Wireshark, командная строка или эмулятор терминала и стандартная сетевая утилита ipconfig. Запускаем командую строку и для начала выполним команду ipconfig.

Источник