Difference between bootp and dhcp

Номера портов

Для BOOTP выделено два заранее известных порта: 67 для сервера и 68 для клиента. Это означает, что клиент не выбирает неиспользуемый динамически назначаемый порт, а использует порт номер 68. Причина, по которой были выбраны два номера портов, вместо того чтобы использовать только один для сервера, заключается в том, что сервер может отправить отклик (хотя обычно он этого не делает) широковещательным образом.

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

Если клиент воспользуется заранее известным портом сервера (67), все сервера в сети будут вынуждены просматривать каждый широковещательный отклик. (Если все сервера были «разбужены», им придется проверить код операции, определить, что это отклик, а не запрос, и снова «уснуть».) Поэтому выбор был остановлен на том, как все сделано сейчас, то есть клиент имеет свой собственный единственный заранее известный порт, который отличается от заранее известного порта сервера.

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

ALLOW and DENY

Параметры allow и deny используются для контроля над поведением демона dhcp в отношении различных видов запросов.

Ключевое слово unknown-clients allow unknown-clients;
deny unknown-clients;

Параметр unknown-clients используется что бы сообщить серверу как поступать с неизвестными клиентами. По умолчанию выдача адресов неизвестным клиентам разрешена.

Ключевое слово bootp allow bootp;
deny bootp;

Параметр bootp сообщает серверу dhcp обрабатывать или нет bootp-запросы. По умолчанию bootp-запросы разрешены.

Ключевое слово booting allow booting;
deny booting;

Параметр booting сообщает серверу обрабатывать ли запрос конкретного клиента. Имеет смысл только если присутствует в описании host и действует только на соответствующий хост. По умолчанию разрешено, в противном случае хост не сможет получать свой адрес и другие параметры.

Discussion

What about little endian bug ? There is some errors in «seconds elasped» field, but nothing about an issue about this. (I’ve got this error on DHCPInform request, the request is loaded twice, with 3 seconds intervals and one of the two request contains this error) — CortoGueguen

If you think there’s a bug in Wireshark’s DHCP dissector, either file the bug on the Wireshark Bugzilla or send mail to the wireshark-users mailing list; this is not the place for reporting Wireshark bugs. -Guy Harris

I think CortoGueguen might be referring to an error message that Wireshark displays. I’ve added an explanation along with a screenshot. — GeraldCombs

Yes this is it, GeraldCombs, thanks a lot — CortoGueguen

Lease Store Configuration

Sub-menu:

This sub-menu allows the configuration of how often the DHCP leases will be stored on disk. If they would be saved on disk on every lease change, a lot of disk writes would happen which is very bad for Compact Flash (especially, if lease times are very short). To minimize writes on disk, all changes are saved on disk every seconds.
Additionally leases are always stored on disk on graceful shutdown and reboot.

Note: Manual changes to leases — addition/removal of static lease, removal of dynamic lease will cause changes to be pushed for this lease to storage.

This sub-menu has only one configurable property:

Vendor Classes

Since 6.45beta6 version RouterOS support vendor class id matcher. The vendor class is used by DHCP clients to optionally identify the vendor and configuration.

Example

In the following configuration example, we will give an IP address from a particular pool for an Android based mobile phone. We will use the RouterBOARD with a default configuration

/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
add name=pool-for-VID ranges=172.16.16.10-172.16.16.120

Configure matcher. DHCP servers configuration remains default

/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dhcp-server vendor-class-id
add address-pool=pool-for-VID name=samsung server=defconf vid=android-dhcp-9

Connect your mobile phone to the device to receive an IP address from 172.16.16.0 network

 > /ip dhcp-server lease print detail 
Flags: X - disabled, R - radius, D - dynamic, B - blocked 
 0 D address=172.16.16.120 mac-address=30:07:4D:F5:07:49 client-id="1:30:7:4d:f5:7:49" address-lists="" server=defconf dhcp-option="" 
     status=bound expires-after=8m55s last-seen=1m5s active-address=172.16.16.120 active-mac-address=30:07:4D:F5:07:49 
     active-client-id="1:30:7:4d:f5:7:49" active-server=defconf host-name="Galaxy-S8"

If you do not know your devices Vendor Class ID, you can turn on DHCP debug logs with . Then in the logging entries, you will see Class-ID

10:30:31 dhcp,debug,packet defconf received request with id 4238230732 from 0.0.0.0 
10:30:31 dhcp,debug,packet     secs = 3 
10:30:31 dhcp,debug,packet     ciaddr = 0.0.0.0 
10:30:31 dhcp,debug,packet     chaddr = 30:07:4D:F5:07:49 
10:30:31 dhcp,debug,packet     Msg-Type = request 
10:30:31 dhcp,debug,packet     Client-Id = 01-30-07-4D-F5-07-49 
10:30:31 dhcp,debug,packet     Address-Request = 172.16.16.120 
10:30:31 dhcp,debug,packet     Server-Id = 192.168.88.1 
10:30:31 dhcp,debug,packet     Max-DHCP-Message-Size = 1500 
10:30:31 dhcp,debug,packet     Class-Id = "android-dhcp-9" 
10:30:31 dhcp,debug,packet     Host-Name = "Galaxy-S8" 
10:30:31 dhcp,debug,packet     Parameter-List = Subnet-Mask,Router,Domain-Server,Domain-Name,Interface-MTU,Broadcast-Address,Address-Time,Ren
ewal-Time,Rebinding-Time,Vendor-Specific 
10:30:31 dhcp,info defconf assigned 172.16.16.120 to 30:07:4D:F5:07:49 
10:30:31 dhcp,debug,packet defconf sending ack with id 4238230732 to 172.16.16.120 
10:30:31 dhcp,debug,packet     ciaddr = 0.0.0.0 
10:30:31 dhcp,debug,packet     yiaddr = 172.16.16.120 
10:30:31 dhcp,debug,packet     siaddr = 192.168.88.1 
10:30:31 dhcp,debug,packet     chaddr = 30:07:4D:F5:07:49 
10:30:31 dhcp,debug,packet     Msg-Type = ack 
10:30:31 dhcp,debug,packet     Server-Id = 192.168.88.1 
10:30:31 dhcp,debug,packet     Address-Time = 600 
10:30:31 dhcp,debug,packet     Domain-Server = 192.168.88.1,10.155.0.1,10.155.0.126 

DHCP Relay Agent Sub-Option Codes

Registration Procedure(s)

IETF Review

Reference

Available Formats

Alerts

Sub-menu:

To find any rogue DHCP servers as soon as they appear in your network, DHCP Alert tool can be used. It will monitor the ethernet interface for all DHCP replies and check if this reply comes from a valid DHCP server. If a reply from an unknown DHCP server is detected, alert gets triggered:

 ip dhcp-server alert>/log print
00:34:23 dhcp,critical,error,warning,info,debug dhcp alert on Public:
    discovered unknown dhcp server, mac 00:02:29:60:36:E7, ip 10.5.8.236
 ip dhcp-server alert>

When the system alerts about a rogue DHCP server, it can execute a custom script.

As DHCP replies can be unicast, the ‘rogue dhcp detector’ may not receive any offer to other dhcp clients at all. To deal with this, the rogue dhcp detector acts as a dhcp client as well — it sends out dhcp discover requests once a minute

Properties

Read only properties

Microsoft.Windows.2008R2.DHCP.Server.IPv4Runtime.Monitor.BOOTPFileConfig (UnitMonitor)

Протокол BOOTP — это протокол конфигурации узлов, разработанный до появления DHCP. DHCP совершенствует BOOTP, устраняя ограничения, присущие этому протоколу в роли службы конфигурации узлов сети. Чтобы настроить на DHCP-сервере назначение IP-адресов и сопутствующей информации BOOTP-клиентам, следует добавить резервирование для каждого BOOTP-клиента. Резервирование создает связь между MAC-адресом и IP-адресом.

Краткое описание

Протокол BOOTP — это протокол конфигурации узлов, разработанный до появления DHCP. DHCP совершенствует BOOTP, устраняя ограничения, присущие этому протоколу в роли службы конфигурации узлов сети.

Чтобы настроить на DHCP-сервере назначение IP-адресов и сопутствующей информации BOOTP-клиентам, следует добавить резервирование для каждого BOOTP-клиента. Резервирование создает связь между MAC-адресом и IP-адресом.

Причины

Системе DHCP не удалось считать таблицу файлов BOOTP из реестра. Служба DHCP не может отвечать на BOOTP-запросы, в которых указывается имя файла BOOTP, пока в таблицу BOOTP не будут вручную добавлены записи, содержащие MAC-адреса клиентов, делающих BOOTP-запросы. Клиентские компьютеры BOOTP не смогут получать адреса от DHCP-сервера и не смогут подключиться к сети.

Решения

Решение: создайте или добавьте записи в таблице BOOTP

По умолчанию таблица BOOTP пуста. Если таблица BOOTP отсутствует или пуста, служба BOOTP не может считать ее, чтобы получить сведения о конфигурации своих клиентов.

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

Чтобы создать или добавить запись в таблицу BOOTP, выполните указанные ниже действия.

• На DHCP-сервере нажмите кнопку Пуск, выберите пункт Администрирование, а затем — DHCP.

• В дереве консоли DHCP выберите пункт Таблица BOOTP.

• В меню Действие выберите пункт Создать образ загрузки.

• В диалоговом окне Добавление BOOTP-записи введите необходимые сведения.

• Нажмите кнопку Добавить.

• Повторите предыдущие два действия для каждой дополнительной BOOTP-записи, которую необходимо добавить, и нажмите кнопку Закрыть.

Дополнительно

Средство проверки: таблица BOOTP существует, и в ней есть записи

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

Чтобы проверить, что таблица BOOTP существует и в ней есть записи, выполните следующие действия:

• На DHCP-сервере нажмите кнопку Пуск, выберите пункт Администрирование, а затем — DHCP.

• В дереве консоли DHCP щелкните DHCP-сервер, который требуется настроить.

• В меню Действие выберите пункт Свойства.

• Проверьте, установлен ли флажок Отобразить папку таблицы BOOTP.

• Если флажок снят, установите его, и нажмите кнопку ОК.

• В дереве консоли DHCP выберите пункт Таблица BOOTP.

• BOOTP-записи, если они были добавлены в таблицу BOOTP, будут отображены в области сведений.

Element properties:

Networks

Sub-menu:

Why would I want to use the udhcp server/client

The udhcp server/client is targeted deliberately at embedded environments…
Other linux DHCP servers out there (such as the ISC DHCP server) are targeted
at larger systems such as PCs (with more RAM/disk space/etc.).
As a result, the udhcp package does not have as large a feature set
as some of these DHCP packages.

Compiled against uClibc, both the server and client binaries are around 18k and when
compiled as one combined binary, has a size of 28k. udhcp is a perfect fit for embedded
systems requring DHCP capabilities.

The udhcp server lease file is in binary format making the additional storage space required
for IP and MAC addresses minimal. It also has the option of storing lease times in absolute
form, or relative form, for systems without a clock. The lease file can also be saved
periodically or by using a signal for systems with flash memory.

The client accepts all options on the command line, and calls external scripts to handle the
configuration of interfaces to allow for the ultimate flexibility.

Call for testing

The 0.9.x version of udhcp is basically a complete rewrite of the previous versions and has matured very quickly. I’d like to get a list together of both known interoptability, and platforms that udhcp compiles/works on. I’ve noticed that win98 often requests unicast packets when it can only receive broadcast packets, so I started a unicast blacklist within the server, and I’m suspected that win95 will go in there too. If I notice that this behavior is too widespread, I’ll probably just drop unicasting altogether. As soon as the list is more or less complete, I’ll release a stable version of udhcp

If you have something to add to the list, let
me know

Client Interoptability listServer Interoptability listWorking client platformsWorking server platforms

Setting up a BOOTP gateway

A BOOTP client normally finds a BOOTP server by
broadcasting on the subnet that is connected to its network interface.
If you want a BOOTP client to obtain its configuration
information from a BOOTP server that is not on the same
subnet, you must configure a BOOTP gateway on the same subnet
as the client. The BOOTP gateway
listens for broadcast BOOTP requests, and forwards them to
a BOOTP server.

NOTE:

To configure a BOOTP gateway:

Log in as root.

The bootpgw daemon is started by the Internet services daemon,
inetd, when required.
To enable a BOOTP gateway, add the following line in
/etc/inetd.conf:

bootps dgram/i udp wait root /usr/sbin/in.bootpgw in.bootpgw server

Replace server with the name or IP address of the
BOOTP server, or that of another BOOTP gateway in the path
to the server.

Force inetd to re-read /etc/inetd.conf
by sending it a SIGHUP signal:
kill -HUP `cat /etc/saf/inetd/_pid`

or by stopping and restarting it:
sacadm -k -p inetd
sacadm -s -p inetd

inetd will now be able to start bootpgw
when the gateway receives a BOOTP request broadcast from a client.

Quick Setup Guide

RouterOS has a built in command that lets you easily set up a DHCP server. Let’s say we want to configure DHCP server on ether1 interface to lease addresses from 192.168.0.2 to 192.168.0.254 which belong to the 192.168.0.0/24 network. The gateway and DNS server is 192.168.0.1.

From menu run setup command and follow instructions:

 ip dhcp-server> setup
Select interface to run DHCP server on

dhcp server interface: ether1
Select network for DHCP addresses

dhcp address space: 192.168.0.0/24
Select gateway for given network

gateway for dhcp network: 192.168.0.1
Select pool of ip addresses given out by DHCP server

addresses to give out: 192.168.0.2-192.168.0.254
Select DNS servers

dns servers: 192.168.0.1
Select lease time

lease time: 3d
 ip dhcp-server>
      

The wizard has made the following configuration based on the answers above:

 ip dhcp-server> print
Flags: X - disabled, I - invalid
  #   NAME            INTERFACE RELAY           ADDRESS-POOL LEASE-TIME ADD-ARP
  0   dhcp1           ether1    0.0.0.0         dhcp_pool1   3d         no

 ip dhcp-server> network print
  # ADDRESS            GATEWAY         DNS-SERVER      WINS-SERVER     DOMAIN
  0 192.168.0.0/24        192.168.0.1        192.168.0.1

 ip dhcp-server> /ip pool print
  # NAME                                        RANGES
  0 dhcp_pool1                                  192.168.0.2-192.168.0.254

 ip dhcp-server>

For more about BOOTP

To obtain more information about BOOTP,
see the following manual pages:

2004 The SCO Group, Inc. All rights reserved.

UnixWare 7 Release 7.1.4 — 22 April 2004

Viewing a client’s network configuration

You can query the BOOTP server
for a client’s network configuration information
by running the
bootp(1Mtcp)
command.

NOTE:bootp

Perform the following procedure:

Log in as a privileged user on the client.

Enter the command:
bootp device

device is the name of the device for the
client’s network interface via which the BOOTP
server can be reached (possibly using a gateway).

For example, the command
bootp /dev/SMC8K_0
might display information such as this:

UX:bootp: INFO: Local ether address: 00:00:c0:19:ca:35
UX:bootp: INFO: 32/64 vend bytes used
INET_YOUR_IP_ADDRESS=137.2.133.63
INET_SERVER_IP_ADDRESS=137.2.133.56
INET_BOOT_FILE_NAME=/export/diskless/fido/stand/unix
INET_SUBNET_MASK=0xFFFFFF00
INET_BROADCAST_ADDRESS=137.2.133.255
INET_ROUTER=137.2.133.1
INET_TIME_OFFSET=0
INET_DNS_SERVER=137.2.200.5
INET_DNS_SERVER=137.2.200.21
INET_DOMAIN_NAME=eng.widgit.com
INET_HOSTNAME=laz
INET_ETHER_ENCAPSULATION=ETHER_II

If you see several messages such as
n
followed by , then a
BOOTP server is not accessible on the specified device
interface, inetd on the server is not configured to
run bootpd, or information about
this host (such as its MAC address)
is not configured correctly on the BOOTP server.

История

Обслуживающий персонал тех (?) лет столкнулся с проблемами постоянного подключения и перемещения новых устройств, а также с необходимостью изменения сетевой конфигурации для соответствия современным требованиям к сетям. Все это привело к необходимости создания механизма для автоматизации конфигурации сетевых узлов, распределенных операционных систем и сетевого программного обеспечения. Наиболее эффективным способом реализации такого механизма может быть сохранение конфигурационных параметров и образов программного обеспечения на одном или нескольких серверах загрузки (boot server). Во время запуска система взаимодействует с таким сервером, получает от него начальные параметры конфигурации и при необходимости загружает с него нужное программное обеспечение.

BOOTP был введен в RFC 951 как замена устаревшему RARP. Первоначально ВООТР разрабатывался для бездисковых рабочих станций. Современные условия привели к необходимости автоматизации загрузки систем, имеющих в ПЗУ только базовые средства для IP, UDP и TFTP. Исходный сценарий загрузки выглядел следующим образом:

• Клиент отправляет в широковещательной рассылке сообщение UDP на загрузочную информацию.
• Сервер возвращает клиенту его IP-адрес и, при необходимости, местоположение файла загрузки.
• С помощью простейшего протокола пересылки файлов TFTP (англ. Trivial File Transfer Protocol) клиент загружает в собственную память необходимое программное обеспечение и начинает работу.

История

Обслуживающий персонал тех (?) лет столкнулся с проблемами постоянного подключения и перемещения новых устройств, а также с необходимостью изменения сетевой конфигурации для соответствия современным требованиям к сетям. Все это привело к необходимости создания механизма для автоматизации конфигурации сетевых узлов, распределенных операционных систем и сетевого программного обеспечения. Наиболее эффективным способом реализации такого механизма может быть сохранение конфигурационных параметров и образов программного обеспечения на одном или нескольких серверах загрузки (boot server). Во время запуска система взаимодействует с таким сервером, получает от него начальные параметры конфигурации и при необходимости загружает с него нужное программное обеспечение.

BOOTP был введен в RFC 951 как замена устаревшему RARP. Первоначально ВООТР разрабатывался для бездисковых рабочих станций. Современные условия привели к необходимости автоматизации загрузки систем, имеющих в ПЗУ только базовые средства для IP, UDP и TFTP. Исходный сценарий загрузки выглядел следующим образом:

• Клиент отправляет в широковещательной рассылке сообщение UDP на загрузочную информацию.
• Сервер возвращает клиенту его IP-адрес и, при необходимости, местоположение файла загрузки.
• С помощью простейшего протокола пересылки файлов TFTP (англ. Trivial File Transfer Protocol) клиент загружает в собственную память необходимое программное обеспечение и начинает работу.

Возможности сервера DHCP

Но самый главный плюс DHCP вовсе не в том, что с его помощью можно автоматически раздавать IP-адреса. На этом функционал протокола не заканчивается. Основная его ценность в другом: с его помощью вы можете назначать хостам и другие, не менее важные настройки. Например:

• Шлюзы по умолчанию. Если в вашей сети имеется несколько Интернет-каналов (для обеспечения бесперебойной работы), вы можете назначить хостам несколько шлюзов и порядок их предпочтения. В случае выхода одного из каналов из строя, переключение на резервный канал произойдет автоматически, без вашего вмешательства. Это же дает возможность организовать простейшую балансировку нагрузки между каналами, назначив по DHCP одной группе хостов один маршрутизатор в качестве шлюза, а другой группе – второй.
• Статические маршруты. Если в вашей сети есть несколько подсетей, соединенных маршрутизаторами, то при помощи DHCP можно автоматически оповещать хосты о наличии маршрутов в другие подсети. Причем это, по желанию, можно сделать только для избранных – например, используя привязку к MAC. Эта же опция полезна при организации Что это такое VPN-доступа к корпоративной сети – VPN-клиентам можно сообщить маршруты лишь к нужным им подсетям, оставив другие подсети недоступными для подключающихся по VPN пользователей.
• Смещение времени. Если ваши пользователи часто бывают в различных временных поясах (например, мотаются из Питера во Владивосток и обратно), то можно заставить системные часы их ноутбука адаптироваться к вашему местному времени при помощи DHCP.
• Сервер синхронизации времени. Поскольку часы компьютеров славятся своей неточностью, их желательно синхронизировать с какими-то эталонными часами. Для этого используется служба NTP. Информацию о сервере Запуск сервера NTP можно раздавать хостам при помощи DHCP.
• Что такое DNS-серверы. С помощью этой опции вы можете назначать вашим клиентам DNS-серверы как внутри сети, так и за ее пределами. Причем, в отличие ручной настройки интерфейса, вы можете передать хосту обширный список доступных DNS-серверов.
• Настройки сервера загрузки – настройки протокола TFTP/BOOTP, необходимые для бездисковой загрузки хостов. Эта возможность востребована при наличии в сети бездисковых терминалов, загружающихся по сети, и при организации дистанционной автоматической установки ОС на компьютеры пользователей (об этом поговорим отдельно)
• Списки доступных SMTP — простой протокол передачи почты и POP серверов.
• Настройки WINS и Netbios
• Размер MTU, время жизни кэша Работа с ARP протоколом: очистка таблицы, размер TTL и др.

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

Когда клиент загружается, начальные параметры определяются в соответствующем клиенту объявлении host, затем проверяется секция group (если она существует) которая содержит в себе host, далее проверяется секция subnet соответствующая подсети в которой находится клиент, после этого проверяется указаны ли какие-нибудь параметры в секции shared-network(если есть), содержащей нашу подсеть, ну и наконец проверяются глобальные параметры, которые могут быть указаны перед всеми объявлениями.

Когда dhcpd ищет секцию host для соответствующего клиента, он следует следующим правилам: сперва ищется объявление host где указан параметр fixed-address и секция subnet или shared network совпадает с подсетью в которой находится клиент. Если нет соответствующих записей, dhcpd ищет объявление host без параметра fixed-address. Если подходящих записей не найдено, то dhcpd считает что нет записей для этого клиента, даже если они есть для этого клиента в другой подсети.