А, б) Суточные вариации потоков TCP-сегментов

Рисунок 5.1.6(а, б). Суточные вариации потоков TCP-сегментов

А,б) Суточные вариации потоков UDP-дейтограмм

Рисунок 5.1.5(а,б). Суточные вариации потоков UDP-дейтограмм.

А, б) Временная зависимость ifinucastpkts, ifoutucastpkts и ifinnucastpkts

Рисунок 5.1.3(а, б). Временная зависимость ifinucastpkts, ifoutucastpkts и ifinnucastpkts

По горизонтальной оси отложено время от начала суток. Кривая, отмеченная треугольниками, соответствует правой шкале диаграммы, это справедливо для всех последующих рисунков. Входной и выходной потоки через данный интерфейс практически равны. На Рисунок 5.1.4(а,б) показана вариация со временем входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers). Пик в правой части Рисунок 5.1.4а (19:00 - 20:00) показывает, что поток ipinreceives превосходит поток ipindelivers почти в два раза. Можно было бы предположить, что разница определяется числом ошибок, но так как по времени это совпадает с пиком в диаграмме ipinreasmreqd, различие следует интерпретировать, как необходимость сборки сообщений. Сопоставление значений ipinreceives, ipinreasmreqd и ipindelivers подтверждает такое предположение. Если такого рода ситуация в сети повторяется часто, нужно просмотреть корректность выбора mtu для объектов, участвующих в данном обмене. Для областей вне указанного пика значения ipinreceives и ipindelivers почти совпадают, что говорит о низком уровне ошибок (это подтверждается и значением потока icmpouterrors, icmpoutdestunreachs и ifinunknownprotos.

На Рисунок 5.1.5(а и б) показаны суточные вариации потоков udp-дейтограмм, а на Рисунок 5.1.6(а и б) представлены аналогичные временные зависимости для TCP-сегментов. Если входные и выходные потоки UDP-дейтограмм отличаются друг от друга временами в несколько раз (что вполне естественно), то входные и выходные потоки TCP-сегментов почти не отличаются (ведь каждому посланному пакету в этом протоколе должен соответствовать пакет-подтверждение).

А,б) Временные зависимости входных

Рисунок 5.1.4(а,б). Временные зависимости входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers)

Алгоритм DES

6.4.1 Алгоритм DES

Стандарт шифрования DES (Data Encryption Standard) был разработан в 1970-х годах, он базируется на алгоритме DEA.

Исходные идеи алгоритма шифрования данных DEA (data encryption algorithm) были предложены компанией IBM еще в 1960-х годах и базировались на идеях, описанных Клодом Шенноном в 1940-х годах. Первоначально эта методика шифрования называлась lucifer (разработчик Хорст Фейштель, название dea (см. http/:snoopy.falkor.gen.nz/~rae/des.html) она получила лишь в 1976 году. Lucifer был первым блочным алгоритмом шифрования, он использовал блоки размером 128 бит и 128-битовый ключ. По существу этот алгоритм являлся прототипом DEA. В 1986 в Японии (NIT) разработан алгоритм FEAL(Fast data Encipherment ALgorithm), предназначенный для использования в факсах, модемах и телефонах (длина ключа до 128 бит). Существует и ряд других разработок.

DEA (ANSI x3.92-1981; www.cryptosoft.com/html/fips46-2.htm) оперирует с блоками данных размером 64 бита и использует ключ длиной 56 бит. Такая длина ключа соответствует 1017 комбинаций, что обеспечивало до недавнего времени достаточный уровень безопасности. В дальнейшем можно ожидать расширения ключа до 64 бит (например, LOKI) или вообще замены DES другим стандартом.

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

Вводится функция f, которая работает с 32-разрядными словами исходного текста (А) и использует в качестве параметра 48-разрядный ключ (J). Схеме работы функции f показана на Рисунок 6.4.1.1. Сначала 32 входные разряда расширяются до 48, при этом некоторые разряды повторяются. Схема этого расширения показана ниже (номера соответствуют номерам бит исходного 32-разрядного кода).

32 1 2 3 4 5

4 5 6 7 8 9

8 9 10 11 12 13

12 13 14 15 16 17

16 17 18 19 20 21

20 21 22 23 24 25

24 25 26 27 28 29

28 29 30 31 32 1

Для полученного 48-разрядного кода и ключа выполняется операция исключающее ИЛИ (XOR). Результирующий 48-разрядный код преобразуется в 32-разрядный с помощью S-матриц. На выходе S-матриц осуществляется перестановка согласно схеме показанной ниже (числа представляют собой порядковые номера бит).

16 7 20 21

29 12 28 17

1 15 23 26

5 18 31 10

2 8 24 14

32 27 3 9

19 13 30 6

22 11 4 25

Алгоритм Диффи-Хелмана

6.4.6 Алгоритм Диффи-Хелмана

Алгоритм Диффи-Хелмана (1976 год) использует функцию дискретного возведения в степень и похож на метод Эль-Гамаля.

Сначала генерируются два больших простых числа n и q. Эти два числа не обязательно хранить в секрете. Далее один из партнеров P1 генерирует случайное число x и посылает другому участнику будущих обменов P2 значение

A = qx mod n

По получении А партнер P2 генерирует случайное число у и посылает P2 вычисленное значение

B = qy mod n

Партнер P1, получив В, вычисляет Kx = Bx mod n, а партнер P2 вычисляет Ky = Ay mod n. Алгоритм гарантирует, что числа Ky и Kx равны и могут быть использованы в качестве секретного ключа для шифрования. Ведь даже перехватив числа А и В, трудно вычислить Kx или Ky.

Алгоритм Диффи-Хелмана, обеспечивая конфиденциальность передачи ключа, не может гарантировать того, что он прислан именно тем партнером, который предполагается. Для решения этой проблемы был предложен протокол STS (station-to-station). Этот протокол для идентификации отправителя использует технику электронной подписи. Подпись шифруется общим секретным ключом, после того как он сформирован. Подпись включает в себя идентификаторы как P1, так и P2. (см. также RFC-2786 "Diffie-Helman USM Key Management Information Base and Textual Convention. M. St. Johns. March 2000".)

Алгоритм работы функции f

Рисунок 6.4.1.1. Алгоритм работы функции f

Преобразование начинается с перестановки бит (IP – Initial Permutation) в 64-разрядном блоке исходных данных. 58-ой бит становится первым, 50-ый – вторым и т.д. Схема перестановки битов показана ниже.

58 50 42 34 26 18 10 2

60 52 44 36 28 20 12 4

62 54 46 38 30 22 14 6

64 56 48 40 32 24 16 8

57 49 41 33 25 17 9 1

59 51 43 35 27 19 11 3

61 53 45 37 29 21 13 5

63 55 47 39 31 23 15 7

Полученный блок делится на две 32-разрядные части L0 и R0. Далее 16 раз повторяются следующие 4 процедуры:

Преобразование ключа с учетом номера итерации i (перестановки разрядов с удалением 8 бит, в результате получается 48-разрядный ключ)

Пусть A=Li, а J – преобразованный ключ. С помощью функции f(A,J) генерируется 32-разрядный выходной код.

Выполняется операция XOR для Ri f(A,J), результат обозначается Ri+1.

Выполняется операция присвоения Li+1=Ri.

Структурная схема реализации алгоритма dea показана на Рисунок 6.4.1.2.

Алгоритм вычисления последовательности ключей Kn

Рисунок 6.4.1.3. Алгоритм вычисления последовательности ключей Kn

Для описания алгоритма вычисления ключей Kn (функция KS) достаточно определить структуру “Выбора 1” и “Выбора 2”, а также задать схему сдвигов влево (табл. 6.4.1.2). “Выбора 1” и “Выбора 2” представляют собой перестановки битов ключа (PC-1 и PC-2; табл. 6.4.1.1). При необходимости биты 8, 16,…, 64 могут использоваться для контроля четности.

Для вычисления очередного значения ключа таблица делится на две части С0 и D0. В С0 войдут биты 57, 49, 41,…, 44 и 36, а в D0 – 63, 55, 47,…, 12 и 4. Так как схема сдвигов задана (табл. 6.4.1.2) C1,D1; Cn, Dn и так далее могут быть легко получены из C0 и D0. Так, например, C3 и D3 получаются из C2 и D2 циклическим сдвигом влево на 2 разряда

х каскадной сети

Рисунок 4.1.10.1. Блок-схема 4- х каскадной сети Delta-2

Диагностика локальных сетей и Интернет

5 Диагностика локальных сетей и Интернет

Номер раздела	Название раздела	Объем в страницах	Объем в кбайт
5	Диагностика локальных сетей и Интернет	15	91
5.1	Сетевая диагностика с применением протокола SNMP	14	209
5.2	Диагностика на базе ICMP	4	23
5.3	Применение 6-го режима сетевого адаптера для целей диагностики	2	12
5.4	Причины циклов пакетов и осцилляции маршрутов	2	14
5.5	Конфигурирование сетевых систем	3	15

Читатели неизбежно делятся на две категории:

а. Администраторы сети, которые формируют сетевую среду (подавляющее меньшинство).

б. Пользователи сети, кто вынужден эту среду осваивать и в ней жить.

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

"Почему не работает электронная почта?" (хотя известно, что вторые сутки за неуплату обесточен весь вычислительный центр). Бывают и сложные: "Как уменьшить задержку отклика, если канал перегружен?"

Число компьютерных сетей увеличивается лавинообразно, растет число больших (>10 ЭВМ) и многопротокольных сетей (Novell, DECnet, TCP/IP, AppleTalk и т.д.). По мере увеличения сети усложняется ее обслуживание и диагностика, с чем сталкивается администратор при первом же отказе. Наиболее сложно диагностировать многосегментные сети, где ЭВМ разбросаны по большому числу помещений, далеко отстоящих друг от друга. По этой причине сетевой администратор должен начинать изучать особенности своей сети уже на фазе ее формирования и готовить себя и сеть к будущему ремонту. При возникновении нештатной ситуации администратор должен суметь ответить на ряд вопросов:

связана проблема с оборудованием или программным обеспечением;

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

Начинать надо с исчерпывающего документирования аппаратной и программной части сети.
Администратор всегда должен иметь под рукой схему сети, отвечающую реальному положению на текущий момент, и подробное описание конфигурации программного обеспечения с указанием всех параметров (физические и IP-адреса всех интерфейсов, маски, имена ЭВМ, маршрутизаторов, значения MTU, MSS, TTL и других системных переменных, типовые значения RTT и других параметров сети, измеренных в разных режимах.).

В пределах локальной сети поиск неисправности возможен с помощью временного деления ее на части. По мере интеграции сети в Интернет такие простые меры становятся недостаточными или недопустимыми. Но не следует пренебрегать такими простыми средствами, как отсутствие обрыва или закоротки сетевого кабеля. Нужно помнить, что сопротивление сегмента толстого коаксиального кабеля не должно превышать 5 Ом, тонкого - 10 Ом, а скрученные пары не должны иметь сопротивление больше 11,8 Ом (22AWG) и соответственно 18,8 Ом (24AWG) из расчета на 100 м.

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

Ниже будет предполагаться, что сеть на физическом уровне использует стандарт Ethernet, а для межсетевой связи протокол TCP/IP (Интернет). Этим перечнем разнообразие сетевых сред не исчерпывается, но многие приемы и программные диагностические средства с успехом могут использоваться и в других случаях. Большинство из рассматриваемых программ работают в среде UNIX, но существуют их аналоги и для других ОС. Сложные (дорогостоящие, но весьма эффективные) аппаратно-программные диагностические комплексы здесь не рассматриваются. Проблемы маршрутизации и конфигурирования системы также выходят за рамки данного рассмотрения.

В Интернет имеется немало общедоступных специализированных диагностических программных продуктов: Etherfind, Tcpdump (lss:os2warez@merlin.itep.ru

ftp.ee.lbl.gov/tcpdump.tar.Z, для SUN или BSD 4.4; ftp.ee.lbl.gov.libpcap.tar.Z), netwatch (windom.ucar.edu), snmpman (http://www.smart.is/pub/mirror-indstate/snmp), netguard (oslo-nntp.eunet.no/pub/msdos/winsock/apps), ws_watch (bwl.bwl.th-harmstadt.de /windows/util).


Программа tcpdump создана в университете Калифорнии и доступна по адресу ftp.ee.lbl.gov. Эта программа переводит интерфейс ЭВМ в режим приема всех пакетов, пересылаемых по данному сетевому сегменту. Такой режим доступен и для многих интерфейсов IBM/PC (например, популярный NE2000 Eagle, mode=6), но tcpdump на этих машинах не работает. Tcpdump написана на СИ, она отбирает и отображает на экране пакеты, посылаемые и получаемые данным интерфейсом. Критерии отбора могут варьироваться, что позволяет проанализировать выполнение различных сетевых процедур. В качестве параметров при обращении к программе могут использоваться наименования протоколов, номера портов и т.д., например, tcpdump TCP port 25. Существует довольно большое число модификаторов программы (опций). К сожалению для рядовых пользователей программа не доступна - требуются системные привилегии. Описание применения программы можно найти по указанному выше адресу, а также в [10]. Другой полезной служебной программой является sock (socket или sockio). Эта программа способна посылать TCP и UDP пакеты, она может работать в четырех режимах.



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

Работа в режиме диалогового сервера (опция -s). В этом режиме параметром операции является ее имя или номер порта (или комбинация IP-адреса и номера порта), например: sock -s 100. После установления связи с клиентом программа переадресовывает весь стандартный ввод клиенту, а все что посылается клиентом, отправляет на стандартный вывод.

Режим клиента-отправителя (опция -i). Программа выдает в сеть заданное число раз (по умолчанию 1024) содержимое буфера с объемом в 1024 байта. Опции -n и -w позволяют изменить число и размер посылок.

Режим приема и игнорирования данных из сети (опция –i и -s).

Такие средства входят также и в комплекты поставки большинства стандартных сетевых пакетов для ОС MS-DOS, UNIX, Windows NT, VMS и других: ping, tracetoute, netstat, arp, snmpi, dig (venera.isi.edu /pub), hosts, nslookup, ifconfig, ripquery.Перечисленные выше диагностические программы являются необходимым инструментом для отладки программ, передающих и принимающих пакеты. Сводный перечень конфигурационных и диагностических команд набора протоколов TCP/IP представлен в таблице 5.1.

Диаграмма состояний DHCP-клиента

Рисунок 5. Диаграмма состояний DHCP-клиента

4.4.1. Инициализация и выделение сетевого адреса

Клиент начинает работу в состоянии INIT и формирует сообщение DHCPDISCOVER. Клиент должен ждать случайное время в интервале 1-10 секунд, для того чтобы десинхронизовать процессы при запуске DHCP. Клиент устанавливает 'ciaddr' равным 0x00000000. Клиент может запросить специфические параметры путем включения опции 'parameter request list'. Клиент может предложить сетевой адрес и/или время действия набора параметров путем включения опций 'запрошенный IP-адрес' и 'IP-address lease time'. Клиент должен включить его аппаратный адрес в поле 'chaddr', если это необходимо для доставки DHCP-откликов. Клиент может включить уникальный идентификатор в опцию 'client identifier', как это описано в разделе 4.2. Если клиент включил список запрашиваемых параметров в сообщение DHCPDISCOVER, он должен включать этот список во все последующие сообщения.

Клиент генерирует и записывает случайный идентификатор транзакции, вставляет этот идентификатор в поле 'xid'. Клиент записывает свое локальное время для использования позднее при вычислении времени пригодности набора конфигурационных параметров. Клиент затем посылает широковещательно DHCPDISCOVER по локальному аппаратному адресу 0xffffffff, по широковещательному IP-адресу и UDP-порту 'DHCP-сервера'.

Если 'xid' приходящего сообщения DHCPOFFER не согласуется с 'xid' последнего сообщения DHCPDISCOVER, сообщение DHCPOFFER должно молча игнорироваться. Любое приходящее сообщение DHCPACK должно молча игнорироваться.

Клиент собирает сообщения DHCPOFFER за определенный период времени, выбирает одно сообщение DHCPOFFER из числа приходящих сообщений DHCPOFFER (например, первое сообщение DHCPOFFER или сообщение DHCPOFFER от сервера, используемого ранее) и извлекает адрес сервера из опции 'server identifier' сообщения DHCPOFFER. Время, в течение которого клиент собирает сообщения, и механизм, используемый для выбора одного DHCPOFFER зависит от конкретной реализации.

DNS (структура, обработка запросов, ресурсные записи)

4.4.12 DNS (структура, обработка запросов, ресурсные записи)

Главной ЭВМ любой системы является та, на которой работаете вы. Но помимо этой машины и маршрутизатора локальной сети не последнюю роль играет сервер имен (DNS-система, RFC-2137, -2052, -2136, -1996, -1918, -1793, -1712-13, -1706, -1664, -1611-12, -1536-37, -1401, -1383, -1183, -1101, -1034-35). Сервер имен это программа управления распределенной базой данных, в которой хранятся символьные имена сетей и ЭВМ вместе с их IP-адресами. Наиболее распространенным программным продуктом, решающим данную задачу является BIND (Berkrley Internet Name Domain). Иногда для этой цели выделяют специальную машину. Задача DNS - преобразование символьного имени в IP-адрес и наоборот в условиях, когда число узлов Internet растет экспоненциально, совсем не проста. Сама иерархическая система имен (DNS) настроена на упрощение решения этой проблемы. Схема взаимодействия программы пользователя с локальным и удаленными DNS-серверами показана ниже на рисунке 4.4.12.1.

Формат BGP-сообщений об изменениях маршрутов

Рисунок 4.4.11.4.1. Формат BGP-сообщений об изменениях маршрутов

Поле маркер содержит 16 октетов и его содержимое может легко интерпретироваться получателем. Если тип сообщения "OPEN", или если код идентификации в сообщении open равен нулю, то поле маркер должно быть заполнено единицами. Маркер может использоваться для обнаружения потери синхронизации в работе BGP-партнеров. Поле длина имеет два октета и определяет общую длину сообщения в октетах, включая заголовок. Значение этого поля должно лежать в пределах 19-4096. Поле тип представляет собой код разновидности сообщения и может принимать следующие значения:

1	OPEN	(открыть)
2	UPDATE	(изменить)
3	NOTIFICATION	(внимание)
4	KEEPALIVE	(еще жив)

После того как связь на транспортном протокольном уровне установлена, первое сообщение, которое должно быть послано - это OPEN. При успешном прохождении этого сообщения партнер должен откликнуться сообщением KEEPALIVE ("Еще жив"). После этого возможны любые сообщения. Кроме заголовка сообщение open содержит следующие поля (Рисунок 4.4.11.4.2):

Формат dns-сообщений

Рисунок 4.4.12.3. Формат dns-сообщений

Каждое сообщение начинается с заголовка, который содержит поле идентификация, позволяющее связать в пару запрос и отклик. Поле флаги определяет характер запрашиваемой процедуры, а также кодировку отклика. Поля число... определяют число записей соответствующего типа, содержащихся в сообщении. Так число вопросов задает число записей в секции вопросов, где записаны запросы, требующие ответов. Каждый вопрос состоит из символьного имени домена, за которым следует тип запроса и класс запроса. Значения битов поля флаги в сообщении сервера имен отображены в таблице 4.4.12.2. Разряды пронумерованы слева направо, начиная с нуля Рисунок 4.4.12.4.

Формат ячейки DQDB (цифры в верхней части рисунка характеризуют длины полей)

Рисунок 4.1.9.1. Формат ячейки DQDB (цифры в верхней части рисунка характеризуют длины полей)

Поле ST (segment type) характеризует тип сегмента. Поле MID (message identifier) представляет собой идентификатор сообщения. LEN –характеризует длину поля данных, а CRC – это контрольная сумма ячейки. Когда станция намерена передать ячейку, она должна знать, справа или слева от нее находится место назначения. Если место назначения справа, отправитель использует шину А, в противном случае передача производится по шине В. Для ввода данных на шину применяется схема проволочного ИЛИ. По этой причине обесточенная станция не вызовет отказа всего сегмента сети. Станция образуют очередь для передачи в порядке поступления заявок (fifo). Структура заголовка ячейки показана на Рисунок 4.1.9.2 она весьма схожа с той, что имеет ячейка atm.

Формат опции аутентификации пользователя

Рисунок .1. Формат опции аутентификации пользователя

Код	98
Длина	длина поля данных (т.e., списка URL) в байтах.
Список URL	Список из одного или более URL, разделенных символами ASCII (0x20) пробел. Поле список URL имеет переменную длину.

Формат поля 'флаги'

Рисунок .2: Формат поля 'флаги'

2.1. Основные конфигурационные параметры

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

Например, ключ может представлять собой пару (номер IP-субсети, аппаратный адрес), чтобы допустить повторное или даже одновременное применение одних и тех же аппаратных адресов в различных субсетях. Заметим, что должен быть определен тип "аппаратного адреса" с тем, чтобы можно было решить проблему возможного дублирования при изменении порядка бит в случае смешения типов оборудования. В качестве альтернативы, ключ может представлять собой пару (номер IP-субсети, имя ЭВМ), позволяя серверу присвоить параметры DHCP-клиенту, который переместился в другую субсеть или сменил свой аппаратный адрес (возможно из-за выхода из строя и замены сетевого интерфейса). Протокол определяет то, что ключ представляет собой (номер IP-субсети, аппаратный адрес), если только клиент не прелагает идентификатор в явном виде, используя опцию 'client identifier'. Клиент может запросить DHCP-сервис, чтобы получить свои конфигурационные параметры. Интерфейс клиента к депозитарию конфигурационных параметров реализуется с помощью протокольных сообщений запроса и откликов серверов, несущих в себе конфигурационные параметры.

2.2. Динамическое выделение сетевых адресов

Вторым видом сервиса, предоставляемым DHCP, является временное или постоянное выделение клиенту сетевого (IP) адреса. Основной механизм для динамического присвоения сетевых адресов достаточно прост: клиент запрашивает использование адреса на определенный период времени. Механизм выделения адреса (ассоциация DHCP-серверов) гарантирует, что адрес в течение оговоренного времени не будет использован для других целей, и пытается прислать тот же сетевой адрес всякий раз, когда клиент его запрашивает.
Клиент может расширить это время последующими запросами. Клиент может послать серверу сообщение об освобождении адреса, когда клиент более не нуждается в этом адресе. Клиент может запросить постоянное присвоение адреса, потребовав бесконечное значение времени выделения адреса. Даже при "постоянном" выделении адресов, сервер может определить большой, но не бесконечный срок аренды адреса, чтобы позволить детектирование факта, что клиент перестал работать.

При некоторых обстоятельствах может оказаться необходимым повторно присваивать сетевые адреса из-за отсутствия свободных адресов. При таких условиях, механизм выделения будет повторно присваивать адреса, чье время действительности истекло. Сервер должен использовать информацию, которая доступна в конфигурационном депозитарии, чтобы выбрать адрес, который может быть использован повторно. Например, сервер может выбрать последний из присвоенных адресов. В качестве проверки совместимости сервер должен проверить повторно используемые адреса, прежде чем их повторно пускать в оборот. Это может быть, например, контроль посредством ICMP эхо-запроса, а клиент должен проверить вновь полученный адрес, например, посредством ARP.



3. Протокол клиент-сервер



DHCP использует формат сообщение BOOTP, определенный в RFC-951 и представленный в таблице 1 и на Рисунок 1. Поле 'op' каждого сообщения DHCP, посланного клиентом серверу, содержит BOOTREQUEST. В поле 'op' DHCP-сообщения, посланного сервером клиенту, заносится BOOTREPLY.

Первые 4 октета поля 'опции' сообщения DHCP содержат (десятичные) коды 99, 130, 83 и 99, соответственно (это те же коды (magic cookie), что определены в RFC-1497 [17]). Остальная часть поля 'опции' состоит из списка помеченных параметров, которые называются "опции". Все "vendor extensions" перечисленные в RFC-1497, являются также опциями DHCP. Документ RFC-1533 предоставляет полный набор опций, определенных для использования с DHCP.

Несколько опций уже определено. Одной из них является опция "DHCP message type", которая должна включаться во все DHCP-сообщения.


Эта опция определяет тип DHCP-сообщения. Дополнительные опции могут допускаться, требоваться или не разрешаться в зависимости от типа DHCP-сообщения.

В рамках данного документа, DHCP-сообщения, которые содержат опцию 'тип сообщения DHCP' будут восприниматься согласно типу сообщения; например, сообщение DHCP с типом опции равным 1 будет восприниматься как сообщение "DHCPDISCOVER".



3.1. Взаимодействие клиента и сервера при выделении сетевого адреса



Ниже рассматривается протокольный обмен между клиентом и сервером DHCP-сообщениями, описанными в таблице 2. Временная диаграмма на Рисунок 3 демонстрирует типичную схему взаимодействия клиента и сервера. Если клиент уже знает свой адрес, некоторые шаги могут быть опущены; такое упрошенное взаимодействие описано в разделе 3.2.

1.

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

2.

Каждый сервер может откликнуться сообщением DHCPOFFER, которое содержит сетевой адрес в поле 'yiaddr' (и другие конфигурационные параметры в опциях DHCP). Серверы не должны резервировать предлагаемый сетевой адрес, хотя протокол будет работать более эффективно, если сервер избегает присвоения предлагаемого сетевого адреса другому клиенту. При выделении нового адреса, серверы должны проверять, чтобы предлагаемый сетевой адрес не использовался где-то еще; например, сервер может протестировать предлагаемый адрес с помощью эхо-запроса ICMP. Серверы должны быть реализованы так, чтобы сетевые администраторы могли выбрать желательные тесты для вновь выделяемых адресов. Сервер отправляет клиенту сообщение DHCPOFFER, используя, если необходимо транспортные средства BOOTP.

Формат ресурсных записей в DNS

Рисунок 4.4.12.6. Формат ресурсных записей в DNS

Имя домена в этой записи может иметь произвольную длину. Поля тип и класс характеризуют тип и класс данных, включенных в запись (аналогичны используемым в запросах). Поле время жизни (TTL) содержит время (в секундах), в течение которого запись о ресурсах может храниться в буферной памяти (в кэше). Обычно это время соответствует двум дням. Формат информации о ресурсах зависит от кода в поле тип, так для тип=1 - это 4 байта IP-адреса. Сервер имен может обслуживать и другие запросы, например, по IP-адресу определять символьное имя домена или преобразовать имя домена в адрес почтового сервера. Когда организация присоединяется к Интернет, она получает в свое распоряжение не только определенную DNS-область, но и часть пространства в in-addr.arpa, соответствующую ее IP-адресам. Домен in-addr.arpa предназначен для определения имен по их IP-адресам. Такая схема исключает процесс перебора серверов при подобном преобразовании.

Имена в домене IN-ADDR.ARPA могут иметь до четырех субполей помимо суффикса IN-ADDR.ARPA. Каждое субполе представляет собой октет IP-адреса, и содержит последовательность символов, отображающую коды в диапазоне 0-255. Так имя для IP-адреса 192.148.166.137 (если оно существует) содержится в домене с именем 137.166.148.192.IN-ADDR.ARPA. Запись адреса задом наперед диктуется общими принципами записи имен доменов (корневая часть имени находится справа). Направив несколько запросов в домен IN-ADDR.ARPA относительно имен объектов с интересующими вас IP-адресами, можно получить следующий результат:

IP_address	Hard-addr	Delay	Date	Host_name
128.141.202.101	00.00.0c.02.69.7d	440	10/10/95	na48-1.cern.ch
192.148.166.102	00.00.a7.14.41.c2	5	10/10/95
192.148.166.237	00.00.0c.02.69.7d	5	10/10/95	ITEP-M9.Relcom.ITEP.RU

где в левой колонке записаны IP-адреса, имена которых ищутся, во второй - записаны аппаратные адреса интерфейсов, через которые доступны искомые объекты. Поскольку первая и третья строки относятся к внешним по отношению к узлу ITEP объектам, здесь записан адрес интерфейса пограничного маршрутизатора.
В третьей колонке содержится значение RTT в мсек, а в оследней - имена объектов. IP-адресу 192.148.166.102 не соответствует никакого имени.

Задержка при выполнении команды telnet между выдачей команды и появлением на экране IP-адреса связана с доступом и работой DNS-сервера. Пауза между появлением надписи Trying и Connected to определяется временем установления TCP-связи между клиентом и сервером. База данных имен может содержать и другую информацию. Типы такой информации представлены в таблице 4.4.12.3. Для извлечения информации из этой распределенной базы данных можно воспользоваться программой host (SUN или другая ЭВМ, работающая под UNIX). Рассмотрим несколько примеров (курсивом выделены команды, выданные с терминала).

host -t cname cernvm.cern.ch

cernvm.cern.ch is a nickname for crnvma.cern.ch

Напомним, что CNAME - каноническое имя узла или ЭВМ, иногда называемое также псевдонимом (alias).

host -t hinfo ns.itep.ru

ns.itep.ru HINFO SparcStation-1 SunOS-4.1.3

HINFO - информация об ЭВМ. Это обычно две последовательности символов, которые характеризуют ЭВМ и ее операционную систему. Много полезной информации можно узнать о почтовом сервере узла посредством команды:

host -t mx cl.itep.ru

cl.itep.ru is a nickname for r02vax.itep.ru

r02vax.itep.ru mail is handled by relay1.kiae.su

r02vax.itep.ru mail is handled by relay2.kiae.su

r02vax.itep.ru mail is handled by mx.itep.ru

r02vax.itep.ru mail is handled by x4u2.desy.de

host -v info.cern.ch

Trying domain "itep.ru"

rcode = 3 (Non-existent domain), ancount=0

Trying null domain

rcode = 0 (Success), ancount=2

info.cern.ch	86400	IN	CNAME	www6.cern.ch
www6.cern.ch	86400	IN	A	128.141.202.119

Trying domain "itep.ru"

rcode = 3 (Non-existent domain), ancount=0

Trying null domain

rcode = 0 (Success), ancount=1

The following answer is not authoritative:

www6.cern.ch

86400

IN

A

128.141.202.119

For authoritative answers, see:

CERN.CH	52256	IN	NS	dxmon.cern.ch
CERN.CH	52256	IN	NS	ns.eu.net
CERN.CH	52256	IN	NS	sunic.sunet.se
CERN.CH	52256	IN	NS	scsnms.switch.ch

<


/p> Additional information:

dxmon.cern.ch 79157 IN A 192.65.185.10

ns.eu.net 56281 IN A 192.16.202.11

sunic.sunet.se 85087 IN A 192.36.125.2

sunic.sunet.se 85087 IN A 192.36.148.18

scsnms.switch.ch 72545 IN A 130.59.1.30

scsnms.switch.ch 72545 IN A 130.59.10.30

Опция -v, используемая совместно с командой host позволяет получить более полную информацию об узле. Во второй колонке данной выдачи указано время жизни (TTL) в секундах. Значение TTL в первых строках соответствует суткам (24x60x60=86400). IN в следующей колонке указывает на принадлежность к классу Интернет. В четвертой колонке проставлены указатели типов запроса (см. табл. 4.4.12.3). В пятой колонке идут названия серверов имен и IP-адреса ЭВМ. Далее следуют коды предпочтения. MX-записи активно используются почтовыми серверами. Обмен MX-записями производится в следующих случаях:

Локальная сеть или ЭВМ не имеет непосредственной связи с Интернет, но желает участвовать в почтовом обмене (например, через UUCP-протокол).

Адресат не доступен и предпринимается попытка доставить почтовое сообщение альтернативной ЭВМ.

Создание виртуальных ЭВМ, куда можно пересылать почту.

MX-записи снабжены 16-битными кодами предпочтения. Если для адреса имеется несколько MX-записей, они используются в порядке нарастания этого кода. Если вы хотите узнать список доступных услуг на той или иной ЭВМ, вы можете напечатать команду (WKS - Well Known Services, сюда не входят услуги прикладного уровня, например, услуги NEWS-сервера и пр.):

host -tv wks ns.itep.ru

ns.itep.ru WKS 193.124.224.35 udp domain tftp

ns.itep.ru WKS 193.124.224.35 tcp echo ftp telnet smtp time finger

Если вам нужно узнать IP-адреса того или иного узла можно также воспользоваться командой host:

host vxdesy.desy.de

vxdesy.desy.de has address 131.169.35.78

vxdesy.desy.de has address 131.169.35.79

vxdesy.desy.de has address 131.169.35.76

vxdesy.desy.de has address 131.169.35.77

Большая часть данных относится к типу "А".

Выше уже говорилось, что для транспортировки DNS-запросов применяются протоколы UDP и TCP.


Когда же следует использовать эти протоколы? Обычно используется UDP. Когда в ответ на запрос программа получает отклик с битом флагов TC=1 (сообщение укорочено), программа повторяет запрос, но уже с использованием протокола TCP. Этот протокол применяется также для зонных обменов между первичным и вторичным DNS-серверами.

Обычно реализация сервера имен (версия BIND – Berkeley Internet Name Domain) предполагает наличие трех конфигурационных файлов:

named.boot - файл начальной загрузки сервера имен;

named.local - стартовый файл клиента DNS;

named.ca - исходный буфер имен и адресов.

Это текстовые файлы, строки и фрагменты, начинающиеся с точки с запятой, представляют собой комментарии. В первом из перечисленных файлов строка, начинающаяся со слова sortlist, указывает на порядок присылки адресов при условии, что отклик на запрос содержит несколько адресов. Строка, начинающаяся со слова directory, содержит название каталога, где хранятся конфигурационные файлы (по умолчанию /etc). Строка cache сообщает имя файла-буфера имен и адресов (по умолчанию named.ca). Далее обычно следует несколько строк, начинающихся со слова primary. Эти строки указывают имена файлов (например, named.hosts или named.local), где содержится информация о соответствии имен и адресов для определенных субдоменов. Вместо имени файла может быть указан IP-адрес. Укладка данных в файле соответствует требованиям документа RFC-1033. Для вторичного (secondary) DNS файл named.boot имеет схожую структуру. Вместо строк со словом primary в этом файле присутствуют строки secondary. Эти строки содержат помимо имен субдоменов и файлов IP-адрес первичного DNS. Последний выполняет и функцию переадресации запросов вышестоящим серверам. Вторичный DNS-сервер при невозможности выполнить запрос переадресует его первичному серверу, а не вышестоящему. Первичный сервер может создавать большой кэш-буфер для локального обслуживания часто поступающих запросов.

Файл named.local служит для спецификации интерфейса сервера имен и содержит в себе запись SOA (Start of Authority) и две ресурсных записи.


Запись SOA определяет начало зоны. Символ @ в начале первой строки файла определяет имя зоны. Здесь же указываются опционные параметры:

номер версии файла (увеличивается каждый раз при внесении любых изменений, этот параметр отслеживается вторичным сервером);

время обновления данных (период запросов, посылаемых вторичным сервером первичному) в секундах;

длительность периода повторных попыток (retry) вторичного сервера в случае неудачи;

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

значение TTL по умолчанию.

Запись может выглядеть как (RFC-1033):

@ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (

45 ;serial

3600 ;refresh

600 ;retry

3600000 ;expire

86400 ) ;minimum

В файле приводится имя первичного сервера имен для данного субдомена (флаг NS) и имя администратора с указанием адреса его электронной почты. Последняя запись в файле содержит указатель на местную ЭВМ. Первая цифра в строке этой записи содержит суффикс IP-адреса этой машины.

Файл named.ca используется для заполнения кэша при первичной загрузке DNS. Примером, иллюстрирующим возможное содержимое файла можно считать следующее (взято из RFC-1033):

;list of possible root servers

. 1 IN NS SRI-NIC.ARPA.

NS C.ISI.EDU.

NS BRL-AOS.ARPA.

NS C.ISI.EDU.

;and their addresses

SRI-NIC.ARPA. A 10.0.0.51

A 26.0.0.73

C.ISI.EDU. A 10.0.0.52

BRL-AOS.ARPA. A 192.5.25.82

A 192.5.22.82

A 128.20.1.2

A.ISI.EDU. A 26.3.0.103

Первое поле представляет собой имя домена или субдомена, второе поле – значение TTL, третье - поле класс (Internet), четвертое – тип записи (NS для сервера имен или A для адреса), и последнее поле характеризует имя ЭВМ или IP-адрес. Если какие-то поля пусты, это означает, что они тождественны приведенным выше. Точка в начале первой строки указывает на корневой домен.

Для администраторов, обслуживающих DNS, весьма полезно ознакомиться с документом RFC-1536 (“Common DNS Implementation Errors and Suggested Fixes”).


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

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

Иногда DNS-сервер в ответ на запрос не присылает сообщений об ошибке и никаких-либо данных клиенту. Это случается когда запрашиваемое имя вполне корректно, но записей нужного типа не найдено. Например, запрошен адрес почтового сервера домена xxx.com. Домен этот существует, но рекорда типа MX не обнаружено. Дальнейшие события зависят от характера программного обеспечения клиента. Если клиент считает такого рода “отклик” некорректным, он может послать запрос повторно и т.д. и т.д. По этой причине в случае, если программное обеспечение это позволяет, рекомендуется ограничить число повторных запросов клиента.


Приведенные примеры показывают, насколько актуальна корректная конфигурация DNS клиента и сервера.

В системах Windows часто используется своя служба имен WINS (Windows Internet Naming Service, см. RFC-2136 и RFC-2137). Эта служба совместима с системой динамического конфигурирования сети DHCP (Dynamic Host Configuration Protocol, использует динамическое распределение IP-адресов). В WINS, также как и в DHCP, имеются части, работающие у клиента и на сервере. WINS автоматически устанавливается и конфигурируется при установке системы DHCP. Эта система имеет удобную встроенную диагностику, позволяющую контролировать процесс обработки запросов к службе имен. WINS осуществляет преобразование NETBIOS-имен в IP-адреса. Эта техника предполагает использование протокола NetBIOS поверх TCP/IP (NetBT). В ОС WINDOWS 2000 технология WINS заменена DDNS (Dynamic Domain Name Service).

WINS-запросы обычно транспортируются в UDP-дейтограммах. При этом используется порт отправителя=137. В поле данных размешается 2-октетное поле идентификатора, позволяющего связать запрос с откликом. Далее следует 2 байта флагов, в случае запроса туда записывается 0. За ним размещается два октета, содержащие число вопросов, 2 октета числа ответов и еще 4 нулевых октетов. Завершается кадр запроса двумя октетами поля типа (00 21 -> статус узла NetBIOS) и полем класса (для Интернет 00 01 -> (IN,1)). Такие запросы позволяют получить дополнительные данные (имя узла, его MAC-адрес, NetBIOS-имя, имя группы) об ЭВМ с заданным IP-адресом. Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать в OS Windows. Формат поля данных UDP-дейтограммы запроса показан на Рисунок 4.4.12.7.



В поле данных UDP-дейтограммы отклика располагается 2-байтовое поле идентификатора, идентичного содержащемуся в пакете запроса. Далее следует поле флагов с длиной в два октета. Формат поля данных UDP-дейтограммы отклика показан на Рисунок 4.4.12.8.



Поле флаги имеет следующую структуру:

0 _ _ _	_ _ _ _	Команда
_ 000	0 _ _ _	Запрос
_ _ _ _	_ _ 0 _	Не укорочено
_ _ _ _	_ _ _ 0	Рекурсия нежелательна

<


/p>

1 _ _ _	_ _ _ _	Отклик
_ 000	0 _ _ _	Запрос
_ _ _ _	_ _ 0 _	Не укорочено
_ _ _ _	_ 1 _ _	Официальный ответ

Для поля флаги имени характерна следующая структура

0 _ _ _	_ _ _ _	Уникальное имя NetBIOS
_ 10 _	_ _ _ _	Узел М-типа
_ _ _ _	_ 1 _ _	Активное имя
_ _ _ _	_ _ 0 _	Временное имя

Для поля флагов имени группы характерно следующее назначение бит

1 _ _ _	_ _ _ _	Имя группы NetBIOS
_ 10 _	_ _ _ _	Узел М-типа
_ _ _ _	_ 1 _ _	Активное имя
_ _ _ _	_ _ 0 _	Временное имя

В последнее время развивается технология DDNS динамического обновления ресурсных записей зоны DNS внешними ЭВМ или процессами (Dynamic DNS; RFC-2136). Клиенты с возможностями DDNS могут сами обновлять записи локальных серверов имен. Еще более интересное решение базируется на интеграции служб DHCP и DNS. В этом варианте серверы DHCP, поддерживающие DDNS, посылают соответствующему серверу DNS данные для обновления записей, включая имена NetBIOS клиентов DHCP. Запись обновляется после выделения IP-адреса. При реализации DDNS возникают проблемы безопасности. Часть этих проблем может быть решено путем использования цифровых подписей (RFC-2137).

Еще одной проблемой, связанной со службой имен, являются атаки, которые сопряжены с имитацией DNS. Для преодоления таких атак разработан метод транзакционных подписей TSIG (Transaction SIGnarure).

Формат секции вопросов dns-запроса

Рисунок . 4.4.12.5. Формат секции вопросов dns-запроса.

Формат сообщений BOOTP

Рисунок 4.4.10.1. Формат сообщений BOOTP

Поле операция=1 говорит о том, что данное сообщение запрос, а значение операция=2 указывает на то, что сообщение является откликом. Поля H-тип и Hlen определяют тип используемого оборудования и длину аппаратного адреса (для Ethernet H-тип=1, а HLen=6). ЭВМ-клиент кладет в поле Hop# (число шагов) нуль. Если BOOTP-сервер, получив запрос, решит передать его другой ЭВМ, он увеличит значение этого поля на 1, и так далее. Поле идентификатор операции

содержит целое число, которое на бездисковых машинах позволяет связать в пары запросы и отклики. Поле секунды хранит время с момента начала процедуры загрузки (BOOT).

ЭВМ-клиент заполняет все последующие поля, если она этой информацией владеет, в противном случае поля обнуляются. Возможность указания имени BOOT(загрузочного)-файла позволяет учесть индивидуальность конфигурации конкретной ЭВМ и пожелания относительно загружаемой операционной системы. Поле специфическая информация поставщика содержит информацию, которая передается от сервера к ЭВМ-клиенту. Первые 4 октета этого поля носят название "волшебное печенье" (magic cookie) и определяют формат остальных субполей. Если в указанном поле имеется информация, субполе волшебное печенье имеет значение 99.130.83.99. Вслед за этим субполем следует последовательность субполей, содержащих один октет тип, опционный октет длина и многооктетное субполе значение. Стандарт предусматривает следующие разновидности субполей:

Формат сообщения DHCP

Рисунок 1. Формат сообщения DHCP

DHCP определяет новую опцию 'client identifier', которая используется для прямой передачи идентификатора клиента DHCP серверу. Это изменение исключает перегрузку поля 'chaddr' в сообщениях BOOTP, где 'chaddr' используется как в качестве аппаратного адреса для пересылки сообщений откликов BOOTP, так и в качестве идентификатора клиента. Идентификатор клиента представляет собой непрозрачный ключ, который не должен интерпретироваться сервером; например, идентификатор клиента может содержать аппаратный адрес, идентичный тому, который лежит в поле 'chaddr', или он может содержать другой идентификатор типа, такой как DNS-имя. Идентификатор клиента, выбранный DHCP клиентом, должен быть уникальным для субсети, к которой он подключен. Если клиент использует идентификатор клиента в одном сообщении, он должен использовать тот же идентификатор во всех последующих сообщениях, чтобы гарантировать корректную идентификацию клиента всеми серверами. DHCP определяет поле 'siaddr' как адрес сервера для использования во время следующего шага процесса начальной загрузки клиента. DHCP-сервер может прислать свой собственный адрес в поле 'siaddr', если сервер готов обеспечить последующую загрузку (например, доставку образа операционной системы). DHCP-сервер всегда присылает свой адрес в опции 'server identifier'. Назначения полей заголовка представлены в таблице 1.

Формат сообщения open

Рисунок 4.4.11.4.2 Формат сообщения open

Поле версия описывает код версии используемого протокола, на сегодня для BGP он равен 4. Двух-октетное поле моя автономная система определяет код AS отправителя. Поле время сохранения характеризует время в секундах, которое отправитель предлагает занести в таймер сохранения. После получения сообщения OPEN BGP-маршрутизатор должен выбрать значение времени сохранения. Обычно выбирается меньшее из полученного в сообщении open и значения, определенного при конфигурации системы (0-3сек). Время сохранения определяет максимальное время в секундах между сообщениями KEEPALIVE и UPDATE или между двумя UPDATE-сообщениями. Каждому узлу в рамках BGP приписывается 4-октетный идентификатор (BGP-identifier, задается при инсталляции и идентичен для всех интерфейсов локальной сети). Если два узла установили два канала связи друг с другом, то согласно правилам должен будет сохранен канал, начинающийся в узле, BGP-идентификатор которого больше. Предусмотрен механизм разрешения проблемы при равных идентификаторах.

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

Длина сообщения = 29 + длина поля идентификационных данных.

Минимальная длина сообщения open составляет 29 октетов, включая заголовок.

Сообщения типа UPDATE (изменения) используются для передачи маршрутной информации между BGP-партнерами. Этот тип сообщения позволяет сообщить об одном новом маршруте или объявить о закрытии группы маршрутов, причем объявление об открытии нового и закрытии старых маршрутов возможно в пределах одного сообщения. Сообщение UPDATE всегда содержит стандартный заголовок и может содержать другие поля в соответствии со схемой:

Формат update-сообщения

Рисунок 4.4.11.4.3 Формат update-сообщения

Если длина списка отмененных маршрутов равна нулю, ни один маршрут не отменен, а поле отмененные маршруты в сообщении отсутствует. Поле отмененные маршруты имеет переменную длину и содержит список IP-адресных префиксов маршрутов, которые стали недоступны. Каждая такая запись имеет формат:

Формат заголовка DQDB–пакета

Рисунок 4.1.9.2. Формат заголовка DQDB–пакета

Поле ACF (access control field) служит для управления доступом. Поле VCI (virtual cannel identifier) - виртуальный идентификатор канала. Далее следуют поля:

PT	(payload type) 4 бита типа данных (коды аналогичны atm);
CLP	(cell loss priority) - уровень приоритета при потере пакета. Указывает на то, какой приоритет имеет ячейка, и будет ли она отброшена в случае переполнения канала (как и в ATM);
HEC	(header error control) поле контроля ошибок (crc заголовка).

Ячейка DQDB отличается от ячейки ATM тем, что не содержит поля VPI (идентификатор виртуального пути), а поле VCI имеет на 4 бита больше. Упрощенная схема подключения узлов к сети показана на Рисунок 4.1.9.3. Шины А и Б служат для передачи ячеек в противоположных направлениях. Если станция намерена передать ячейку по шине Б, она должна выполнить резервирование заранее на шине А, осуществив запись 1 в бит request соответствующей ячейки.

Формат заголовка DVMRP-сообщений

Рисунок 4.4.9.4.1 Формат заголовка DVMRP-сообщений

Поле версия равно 1. Поле тип содержит всегда код 3. А поле субтип может принимать значения:

1 = Отклик; сообщение о маршрутах до некоторого (-ых) мест(а) назначения.

2 = Запрос; поиск маршрутов до определенного места назначения;

3 = Сообщение о выходе из членов группы;

4 = Отмена заявки о выходе из группы.

Контрольная сумма вычисляется также как и в других IP-протоколах. Отдельные записи в указанном списке выполняют роль команд и их размер должен быть кратен 16 бит (их границы соответствующим образом выравниваются). Максимальная длина DVMRP-сообщения, включая заголовок, не может превышать 512 байт.

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

Иерархия имен в Интернет-DNS (I – домен первого уровня; II – второго уровня)

Рисунок 4.4.12.2. Иерархия имен в Интернет-DNS (I – домен первого уровня; II – второго уровня)

Каждому узлу (прямоугольнику на рисунке) соответствует имя, которое может содержать до 63 символов. Только самый верхний, корневой узел не имеет имени. При написании имени узла строчные и прописные символы эквивалентны. Имя домена, завершающееся точкой называется абсолютным или полным именем домена (например, itep.ru.). В некоторых странах создана структура имен сходная с com/edu/org. Так в Англии можно встретить адреса .ac.uk для академических учреждений и .co.uk - для коммерческих. Если имя домена не завершено символом точки, DNS может попытаться его дополнить, например имя ns может быть преобразовано в ns.itep.ru. На приведенной схеме каждому объекту трех верхних уровней соответствуют серверы имен, которые могут взаимодействовать друг с другом при решении задачи преобразования имени в IP-адрес. Можно было бы построить схему, при которой в любом сервере имен имелись адреса серверов .com, .edu, .ru и т.д. и при необходимости он мог бы послать туда запрос. Реальная схема серверов не столь идеальна и стройна - существуют серверы nsf.gov, oakland.edu и т.д., которые непосредственно связаны с базовым сервером имен. Каждый сервер содержит лишь часть дерева имен. Эта часть называется зоной ответственности сервера. DNS-сервер может делегировать ответственность за часть зоны другим серверам, создавая субзоны. Когда в зоне появляется новая ЭВМ или субдомен, администратор зоны записывает ее имя и IP-адреса в базу данных сервера. Администратор зоны определяет, какой из DNS-серверов имен является для данной зоны первичным. Число вторичных серверов не лимитировано. Первичный и вторичный серверы должны быть независимыми и работать на разных ЭВМ, так чтобы отказ одного из серверов не выводил из строя систему в целом. Отличие первичного сервера имен от вторичного заключается в том, что первичный загружает информацию о зоне из файлов на диске, а вторичный получает ее от первичного. Администратор вносит любые изменения в соответствующие файлы первичного сервера, а вторичные серверы получают эту информацию, периодически (раз в 3 часа) запрашивая первичный сервер.
Пересылка информации из первичного во вторичные серверы имен называется зонным обменом. Как будет вести себя сервер, если он не имеет запрашиваемой информации? Он должен взаимодействовать с корневыми серверами. Таких серверов насчитывается около десяти и их IP-адреса должны содержаться в конфигурационных файлах.

Список корневых серверов вы можете получить с помощью анонимного ftp по адресам: nic.ddn.mil или ftp.rs.internic.net . Корневые серверы хранят информацию об именах и адресах всех серверов доменов второго уровня. Существует два вида запросов: рекурсивные и итеративные. Первый вид предполагает получение клиентом IP-адреса, а второй - адреса сервера, который может сообщить адрес. Первый вид медленнее, но дает сразу IP-адрес, второй эффективнее - в вашем сервере копится информация об адресах серверов имен. Одним из способов повышения эффективности трансляции имен в адреса является кэширование, то есть хранение в оперативной памяти имен-адресов, которые использовались последнее время особенно часто. Рассмотрение процесса обмена между ЭВМ-клиентом и сервером имен может прояснить работу системы в целом. Прежде чем использовать протоколы UDP или TCP прикладная программа должна узнать IP-адрес объекта, куда она хочет послать дейтограмму. Для решения этой проблемы программа посылает запрос в локальный сервер имен. В Unix-системах имеются специальные библиотечные процедуры gethostbyname и gethostbyaddr, которые позволяют определить IP-адрес по имени ЭВМ и наоборот. В одном запросе может содержаться несколько вопросов. Если сервер не сможет ответить на вопросы, он пришлет отклик, где содержатся адреса других серверов, способных решить эту задачу. Ниже на рисунке 4.4.12.3 представлен формат таких сообщений (в качестве транспорта используется UDP или TCP, порт 53).

Пример диагностируемой сети

Рисунок 4.1.1. Пример диагностируемой сети

Для диагностики сегмента, непосредственно связанного с ЭВМ-тестером, можно использовать режим 6 Ethernet-интерфейса ЭВМ-тестера. Этот режим, при котором принимаются все пакеты, следующие по сегменту, позволяет регистрировать распределение пакетов по адресам отправителя и получателя, протоколам, длинам пакетов и т.д.. Запуская определенные программы на ЭВМ 1 или 2 (сегмент С-1), можно получить исчерпывающую информацию о состоянии сегмента. Этот способ диагностики не пригоден для сегментов, к которым подключены ЭВМ 3 (сегмент С-2), 4 и 5 (сегмент С-3). В случае, если все ЭВМ сети поддерживают протокол tcp/ip, возможно применение для целей диагностики протокола icmp (RFC-1256, -1788, -1885, -792). Этот протокол также как и snmp пригоден для диагностики не только локальной сети но и каналов Интернет. Если использовать icmp не только для трассировки маршрутов, но и для измерения процента испорченных пакетов, можно получить весьма полезную информацию, а при длинных сегментах зарегистрировать ухудшение качества сегмента при подключении слишком большого числа ЭВМ. Такая техника может прогнозировать ухудшение пропускной способности канала при подключении дополнительных ЭВМ. Но применение icmp ограничено ЭВМ, поддерживающими протоколы Интернет, да и получаемые данные весьма ограничены.

Следует иметь в виду, что в многопротокольных средах структуры MIB могут заметно отличаться, варьируется несколько и формат SNMP-пакетов. В настоящее время существует достаточно большой выбор коммерческих программ сетевой SNMP-диагностики (их цены лежат в диапазоне 5-45 тыс. дол.). Особую ценность представляют аппаратно-программные комплексы (15-55 тыс. дол.), которые способны диагностировать состояние оборудования и кабельных сегментов. К сожалению, для отечественных пользователей они по причине цены практически недоступны.

Сеть ИТЭФ, которая была зарегистрирована одной из первых в качестве узла Интернет в 1991 году, в настоящее время содержит более 400 ЭВМ при суммарной длине кабельных сегментов около 10 км и обслуживается 6 сотрудниками.
В сети используются протоколы TCP/IP, Novell, Arcnet и др.. Проблема диагностики такой сети достаточно актуальна. Мы сначала использовали традиционные программные средства типа ping, traceroute, netstat, arp, snmpi, dig (venera.isi.edu/pub), hosts, nslookup, ifconfig, ripquery, поставляемые со многими сетевыми пакетами. Позднее пытались адаптировать общедоступные диагностические средства типа: netwatch (windom.ucar.edu), snmpman (http:// www.smart.is/pub/mirror-indstate/snmp), netguard (oslo-nntp,eunet.no/pub/msdos/winsock/apps), ws_watch (bwl.bwl.th-harmstadt.de/windows/util). Среди наиболее часто встречающихся проблем: разрывы кабельных сегментов, несанкционированное использование IP-адресов, некачественное питание сетевого оборудования, отказы тех или иных устройств.
Не все ЭВМ имеют активные SNMP-резиденты, это происходит по причине экономии оперативной памяти или по соображениям безопасности. Еще меньше snmp-агентов, доступных в режиме public (поле SNMP-пакета community; формат пакетов описан, например, в книге Семенова Ю.А. “Протоколы и ресурсы Интернет”, Москва, “Радио и связь”, 1996). Но для контроля ситуации достаточно иметь по одному активному SNMP-резиденту на каждом из кабельных сегментов. При этом не обязательно ставить их в общедоступный режим, можно использовать для получения диагностической информации и пароль.
При написании диагностической программы не нужно пытаться считывать все переменные и таблицы MIB. База данных весьма велика и для целей диагностики не все ее записи представляют интерес. При написании нашей диагностической программы были отобраны 35 переменных (ниже приводится сокращенный список):

interface.iftable.ifentry.ifinucastpkts	Число полученных обычных пакетов;
interface.iftable.ifentry.ifinnucastpkts	Число полученных широковещательных и мультикаст-пакетов;
interface.iftable.ifentry.ifinerrors	Число ошибок при приеме пакетов;
interface.iftable.ifentry.ifoutucastpkts	Число посланных обычных пакетов;
interface.iftable.ifentry.ifinnucastpkts	Число посланных широковещательных и мультикаст-пакетов;
interface.iftable.ifentry.ifinunknownprotos	Число полученных пакетов с неизвестным кодом протокола;
ip.ipinreceives	Полное число ip-дейтограмм, включая полученные с ошибкой;
ip.ipinhdrerrors	Число входных ip-дейтограмм с ошибками в заголовке пакета, включая ошибки контрольной суммы, ttl и т.д.
ip.ipinaddrerrors	Число полученных пакетов с ошибкой в адресе;
ip.ipinunknownprotos	Число входных ip-дейтограмм, с кодами протоколов, которые не поддерживаются данной системой;
ip.ipreasmreqds	Число полученных фрагментов, которые требуют сборки;
ip.ipindelivers	Число ip-дейтограмм, принятых без ошибок (включая icmp);
icmp.icmpinmsgs	Число полученных icmp-пакетов;(другие 10 контролируемых переменных icmp-группы из соображений экономии места из списка исключены);
udp.udpindatagrams	Число принятых udp-дейтограмм;
udp.udpoutdatagrams	Число отправленных udp-дейтограмм;
udp.udpnoports	Полное число udp-дейтограмм, для которых не существует приложения для указанного номера порта;
udp.udpinerrors	Число udp-дейтограмм, которые не могут быть доставлены не по причине отсутствия приложения по указанному порту;
tcp.tcpinsegs	Число принятых tcp-сегментов;
tcp.tcpoutsegs	Число отправленных TCP-сегментов;
tcp.tcpretranssegs	Число tcp-сегментов с повторной пересылкой;
tcp.tcpoutrsts	Число сегментов с флагом rst=1;
tcp.tcpinerror	Число tcp-сегментов, полученных с ошибкой.

<


Выбор определялся тем, что именно эти переменные варьируются динамически в течение суток. Ставилась задача исследования временных вариаций потоков в заданном сегменте и выработки критериев для диагностики потенциально опасных ситуаций. Измерения проводились каждые полчаса в течение недели.
Многие переменные базы MIB не меняются или меняются незначительно, но определяют режим работы и состояние ЭВМ-сервера. Так переменная snmpinbadcommunityuses {snmp 5} может сообщить о попытках несанкционированного доступа к базе mib. Переменные snmpintoobigs {snmp 8}, snmpingenerrs {snmp 12} или ifadminstatus {ifentry 7} и многие другие характеризуют текущее состояние системы и длительное их отслеживание чаще всего не дает полезной информации. Другие переменные, например, ipnettomedianetaddress {ip 22}, ipnettomediaentry или iproutedest и т.д. полезно контролировать при серьезных сбоях и сравнивать их с эталонными значениями. Некоторые переменные важны при анализе эффективности системы, например, ipfragcreate {ip 19} или ipfragfails {ip 18}, последняя переменная говорит о том, сколько встретилось пакетов с флагом, запрещающим фрагментацию, в условиях, когда она необходима, что может свидетельствовать, если ipfragfails велико, о неверном выборе MTU.

Рассмотрим средние значения некоторых переменных за сутки. Так переменные ip.ipinreceives=1379552, ifentryifinucastpkts=1278232, ifentry.ifinnunicastpkts=5083 характеризуют средний поток пакетов на входе сетевого интерфейса. Видно, что широковещательные и мультикастинг-пакеты составляют малую долю потока, что и следует ожидать. Большой поток пакетов типа nonunicast обычно говорит о неисправности в сети. Величины ifentry.ifoutunicastpkts=1369809 и ifentry.ifoutnunicastpkts=90 характеризуют выходной поток пакетов, соотношение обычных и nonunicast-пакетов и здесь нормально. Сравнимое их значение говорило бы о неисправности сетевого интерфейса данной ЭВМ или о порче сетевого программного драйвера. Блок переменных ip.ipinhdrerrors=8, icmp.icmpouterrors=45, icmp.icmpoutdestunreachs=22 и ifentry.ifinunknownprotos=81 указывает на число сбоев в сети, если соотнести эти цифры с входным и выходным потоками пакетов можно сделать вывод о благополучии в данном кабельном сегменте, во всяком случае на протяжении данных суток.


Такие ошибки возможны из- за всплеска шумов или наводок (например, по сети переменного тока). Определенное беспокойство может вызвать значение icmpoutdestunreachs, но это может быть результат работы программы ping или traceroute для недоступного узла или опечатка в IP-адресе. Переменная icmp.icmpinsrcquenchs=19 весьма важна, так как она отмечает случаи перегрузки. В данном случае таких ситуаций за сутки случилось мало. Отслеживая эту переменную для разных ЭВМ, можно выявить слабые элементы в сети и скорректировать их параметры (например, увеличить буферную память). Переменные tcp.tcpinsegs=762696, tcp.tcpoutsegs=803676 и tcp.tcpretranssegs=3554 говорят о потоках tcp-пакетов (главного транспортного средства Интернет). Число tcpretranssegs характеризует надежность и правильность настойки параметров сети, чем меньше это число, тем лучше. udp.udpindatagrams=378119, udp.udpoutdatagrams=59429 указывают на входной и выходной потоки UDP-дейтограмм (сравните с потоками TCP-сегментов). Запись в MIB udp.udpnoports является важным диагностическим показателем. Переменные, регистрирующие число тех или иных ошибок, неупомянутые в этом абзаце, оказались равными нулю. Количество пакетов snmp в точности совпадает с их числом, посланным и полученным данной программой-тестером, что говорит об отсутствии какой-либо другой SNMP-активности. Контролировать это время от времени также полезно из соображений сетевой безопасности.

Пример разных маршрутов для пути "туда" и "обратно"

Рисунок 4.4.11.4.4. Пример разных маршрутов для пути "туда" и "обратно".

Предполагается, что оператор находится в ЭВМ-отправителе. Команда traceroute 192.148.166.33 в этом случае выдаст:

1 GW-1	(192.148.166.35)
2 Место назначения	(192.148.166.33)

Команда же traceroute 192.148.165.80 распечатает:

1 GW-1	(192.148.166.35)
2 GW-2	(192.148.166.7)
3 Место назначения	(192.148.165.80)

Команда traceroute -g 192.148.165.80 сообщит вам:

1 GW-1	(192.148.166.35)
2 *****	; В этом режиме маршрутизатор не откликается
3 Место назначения	(192.148.165.80)
4 GW-1	(192.148.166.35)
5 ЭВМ-отправитель	(192.148.166.32)

Из приведенных примеров видна также полезность команды traceroute для понимания того, как движутся пакеты в сети. В некоторых случаях это может помочь оптимизировать маршрутизацию и улучшить пропускную способность сети.

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

-a отображает состояния всех соединений;

-i отображает значения конфигурационных параметров;

-r отображает таблицу маршрутов;

-v отображает статистику обмена локального Ethernet-интерфейса.

Например, команда netstat -r может выдать:

Routing tables (таблицы маршрутизации)

Destination	Gateway	Flags	Refcnt	Use	Interface
Stavropol-GW.ITEP.RU	nb	UGHD	0	109	le0
ihep.su	itepgw	UGHD	0	103	le0
m10.ihep.su	itepgw	UGHD	0	16	le0
194.85.66.50	itepgw	UGHD	0	455	le0
Kharkov.ITEP-Kharkov	nb	UGHD	0	105	le0
Bryansk-GW.ITEP.Ru	nb	UGHD	1	8113	le0
193.124.225.67	nb	UGHD	0	0	le0
ixwin.ihep.su	itepgw	UGHD	1	6450	le0
ihep.su	itepgw	UGHD	0	14	le0
192.148.166.21	nb	UGHD	0	109	le0
ihep.su	itepgw	UGHD	0	224	le0
193.124.225.71	nb	UGHD	0	10	le0
194.85.112.0	ITEP-FDDI-BBone.ITEP	UGD	0	253	le0
default	itepgw	UG	10	102497	le0

Здесь приведен только фрагмент маршрутной таблицы.
Колонка destination указывает на конечную точку маршрута (default - маршрут по умолчанию), колонка gateway – имена маршрутизаторов, через которые достижим адресат. Флаг "U" (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг "G" указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора. Если флаг "G" отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг "D" указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом "H" (host), при этом первая колонка таблицы содержит его IP-адрес. Базовая команда netstat может обеспечить следующую информацию:
Active Internet connections (активные Интернет связи)

Proto	Recv-Q	Send-Q	Local Address	Foreign Address	(state)
tcp	0	0	127.0.0.1.1313	127.0.0.1.sunrpc	TIME_WAIT
tcp	0	0	ns.1312	193.124.18.65.smtp	SYN_SENT
tcp	0	0	127.0.0.1.1311	127.0.0.1.sunrpc	TIME_WAIT
tcp	0	0	ns.1310	ns.domain	TIME_WAIT
tcp	0	0	127.0.0.1.1309	127.0.0.1.sunrpc	TIME_WAIT
tcp	39	24576	ns.nntp	Bryansk-GW.ITEP.1697	ESTABLISHED
tcp	0	0	ns.telnet	semenov.1802	ESTABLISHED
tcp	0	188	ns.1033	xmart.desy.de.6000	ESTABLISHED
udp	0	0	127.0.0.1.domain	*.*
udp	0	0	ns.domain	*.*

Active UNIX domain sockets (активные UNIX-соединители домена)

Address	Type	Recv-Q	Send-Q	Vnode	Conn	Refs	Nextref Addr
ff64b38c	stream	0	0	ff13187c	0	0	0 /dev/printer
ff64b28c	dgram	0	0	0	0	0	0
ff64698c	dgram	0	0	ff137fa8	0	0	0 /dev/log

Протокол динамического конфигурирования ЭВМ DHCP

4.4.12.1 Протокол динамического конфигурирования ЭВМ DHCP

Протокол мультикастинг-маршрутизации DVMRP

4.4.9.4 Протокол мультикастинг-маршрутизации DVMRP

DVMRP - (Distance Vector Multicast Routing Protocol) мультикастинг-протокол, где в качестве метрики применен вектор расстояния (см. также описание RIP, RFC-1058). DVMRP использует идеологию документа RFC-1054, а также алгоритм TRPB (Truncated Reverse Path Broadcasting). При получении первого пакета маршрутизатор не имеет информации о группе. Он посылает полученный пакет через все интерфейсы, кроме того, через который этот пакет получен. Если пакет пришел не через интерфейс, который используется маршрутизатором для посылки пакетов отправителю мультикаст-информации, полученный пакет выбрасывается. При получении пакета маршрутизатором, в зоне ответственности которого нет членов группы, он посылает сообщение об исключении (prun-команда). Эти сообщения используются для отсечения от дерева маршрутов веток, не содержащих членов группы. По истечении определенного времени "отрезанные" ветки дерева маршрутов "отрастают" вновь и снова могут быть отсечены (протокол TRPB). В настоящее время этот протокол рассматривается в качестве экспериментального и его широкое применение не рекомендуется. DVMRP относится к внутренним протоколам маршрутизации, пригодным для использования в пределах автономной системы.

Протокол DVMRP используется для построения дерева мультикасинг-маршрутов. Предполагается, что в дальнейшем принцип "вектора расстояния" может быть заменен алгоритмом "состояния канала" (MOSPF аналог OSPF). Целью протокола DVMRP является описание обратного пути к источнику мультикастинг-дейтограмм. Протоколы состояния канала предполагают широковещательную рассылку информации о членстве в группе. При получении мультикаст-пакета маршрутизатор определяет дерево кратчайших маршрутов.

DVMRP-дейтограмма состоит из небольшого заголовка фиксированного размера и длинного списка записей. Заголовок DVMRP-сообщений имеет формат IGMP (Рисунок 4.4.9.4.1):

Протокол загрузки BOOTP

4.4.10 Протокол загрузки BOOTP

В больших сетях некоторые рабочие станции (например, Х-терминалы) могут не иметь системного диска, а операционная система и сетевое программное обеспечение загружается через сеть. Для этого рабочая станция должна иметь стартовую программу, записанную в ПЗУ. Такое постоянное запоминающее устройство часто производится на фирме, изготовившей эту рабочую станцию, и по этой причине не содержат информации ни об адресе сервера, ни даже о своем IP-адресе. Выше был описан протокол RARP, который способен решать подобные задачи для случая, когда сервер находится в пределах данной локальной сети. Ведь RARP выдает широковещательный запрос на связном уровне, а он не ретранслируется маршрутизаторами. Более мощным средством для загрузки бездисковых станций является протокол BOOTP (Bootstrap протокол, RFC-951, -1048, -1532). BOOTP пригоден и для загрузки бездисковых маршрутизаторов. BOOTP в качестве транспортного использует UDP-протокол. ЭВМ-клиент (порт=68), которая хочет воспользоваться BOOTP, посылает широковещательное сообщение (по адресу = 255.255.255.255). Сервер (порт=67) в отличии от случая RARP не обязательно должен находиться в пределах данной локальной сети. В поле IP-адрес клиента будет записано 0.0.0.0, так как клиент пока не знает своего адреса. Получив запрос через порт 67, маршрутизатор помещает свой IP-адрес в поле IP-адрес маршрутизатора (см. формат запроса на Рисунок 4.4.10.1) и пересылает запрос действительному BOOTP-серверу, увеличив на 1 значение поля Hop#. По пути к серверу может быть несколько маршрутизаторов (но обычно не больше 3). Сервер не знает физического адреса клиента. Воспользоваться ARP-запросом он не может, так как клиент пока не знает своего IP-адреса и на ARP-запрос не откликнется. У сервера, получившего запрос, имеется две возможности.

1. Проанализировать пакет, извлечь из него физический адрес клиента и скорректировать ARP-таблицу.

2. Послать отклик, используя широковещательный адрес.

Так как программа загрузки находится на прикладном уровне, и ей запрещено исправлять ARP-таблицы, реально доступен только второй путь.
Использование разных номеров портов для сервера и клиента делает работу системы более эффективной. Когда отклик сервера является широковещательным, это позволяет не прерывать работу прикладных программ, работающих с номерами портов, отличными от 68 (порт Bootp-клиента). В Bootp ответственность за надежность связи лежит на ЭВМ-клиенте. При отсутствии отклика в отведенное время клиент повторяет Bootp-запрос. На IP-уровне, где данные не имеют контрольной суммы, целостность сообщения не гарантирована. Bootp требует, чтобы проверка контрольной суммы обязательно проводилась на UDP-уровне (следует заметить, что обычно это не является обязательным). Сервер читает UDP-дейтограммы через порт 67. Для повышения надежности обменов, как правило, блокируется фрагментация дейтограмм.

Загрузка рабочих станций часто запускается броском напряжения сетевого питания. При этом несколько Bootp-процессов стартуют одновременно. Для того чтобы снизить вероятность столкновений, величина времени тайм-аута выбирается случайно в интервале 0-4сек. После каждого повторного запроса это время удваивается. Верхнее значение тайм-аута равно 60сек. Для справок время загрузки бездискового x-терминала при благоприятных условиях может составлять около 20 сек.

bootp осуществляет загрузку в два этапа. На первом этапе bootp лишь снабжает клиента информацией, где лежит нужные ему данные. Далее ЭВМ-клиент использует протокол RFTP для получения искомого загружаемого файла. Bootp-сервер не обязательно должен работать на той же машине, где хранятся загружаемые файлы, но он должен знать их имена. Формат Bootp-сообщений представлен на Рисунок 4.4.10.1.

Сегментация МАС-кадра

Рисунок 4.1.9.4. Сегментация МАС-кадра

Сети DQDB могут иметь размер до 160 км при скорости передачи данных 44,736 Мбит/с (Т3).

Сетевая диагностика с применением протокола SNMP

5.1 Сетевая диагностика с применением протокола SNMP

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

Так как сеть может быть построена с использованием различных физических сред и протоколов, наиболее привлекательным, если не единственным, средством диагностики представляется протокол snmp, который служит для целей управления в ISDN, X.25, FDDI, ATM, TCP/IP и других сетях. Протокол SNMP (std15, RFC-1448, -1592, -1901, 1902-1907, 1908-1910) использует управляющую базу данных mib (RFC-1213, -1158, -1792, -1042; std16, std17), доступ к которой определяется администратором локальной сети или конкретной ЭВМ (ссылки, выделенные полужирным шрифтом, являются стандартами Интернет). Для того чтобы база данных была доступна, необходимо наличие snmp-демона с режимом свободного доступа (поле community = public). Рассмотрим сеть, изображенную на Рисунок 4.1.1.

Сети ase-VG

4.1.11 Сети 100Base-VG

Сети 100BASE-VG (Voice Grade) используют звездообразную схему сетевых объектов с помощью соединения типа точка-точка. Эта разновидность сети может работать через кабельную инфраструктуру стандартной сети 10BASE-T. Станции подключаются к сети через концентратор (Hub). Когда станция желает что-либо передать, она посылает сигнал определенной частоты. Начало обмена стартует только после получения разрешения (сигнал специальной частоты, посылаемый концентратором. Широковещательные и мультикатинг-запросы обслуживаются в соответствии со схемой “запомнить и передать”. В одно и то же время допускается прием или передача только одного пакета. Для предоставления доступа используется карусельный принцип, что делает эту сеть весьма удобной для небольших рабочих групп и для решения задач управления в реальном масштабе времени. Имеется возможность и приоритетного обслуживания. В сети используется схема кодирования 5B/6B.

Сети DQDB (двойная шина с распределенной очередью)

4.1.9 Сети DQDB (двойная шина с распределенной очередью)

Сети с двойной шиной и распределенной очередью (DQDB - distributed queue dual bus) используют алгоритм доступа, называемый распределенное переключение пакетов (QPSX – queued-packet distributed-switch). Здесь используется две несвязанные однонаправленные шины, сформированные из цепочки соединений точка-точка. Описание работы сети содержится в документе IEEE 802.6. Пропускная способность сети составляет 150 Мбит/с (планируется 600 Мбит/с). Максимально возможная длина сети составляет 160 км. Максимальное число узлов равно 512. В качестве транспортной среды можно использовать одно- и мультимодовое оптическое волокно (длина волны 1300 нм). Схема кодирования 8В/9В при представлении сигнала NRZI. средняя частота ошибок (BER) составляет 10-9. По сетям DQDB пересылаются также как и по ATM-каналам ячейки фиксированного размера (L=53 байта). Формат поля данных совместим с некоторыми типами AAL. Формат пакета показан на рис 4.1.9.1

Сети с многокаскадными соединениями

4.1.10 Сети с многокаскадными соединениями

Среди традиционных сетей особое положение занимают сети, базирующиеся на большом числе идентичных ключевых элементов. Это сети с многокаскадными связями (MIN – Multistage Interconnection Network). Идеология таких сетей используется при построении коммутаторов ATM. Из таких сетей наиболее известной является Delta Banyan (Batcher-switch). Эта сеть содержит регулярную структуру N*N переключателей с двух направлений на два. Сеть содержит log2N число каскадов, каждый из которых имеет N/2 переключателей. Для управления маршрутизацией сообщений в этой сети необходимо log2N бит информации. Схема 4-каскадной сети Delta-2 приведена на Рисунок 4.1.10.1.

Схема устройства линейной дельта-модуляции

Рисунок 2.4.1.1 Схема устройства линейной дельта-модуляции

Если скорость нарастания входного сигнала велика, то уровень на выходе ЦАП будет отставать и сможет нагнать In(t) только, когда входной сигнал начнет уменьшаться. Данный метод не является разумной альтернативой PCM. Для улучшения характеристик дельта-преобразователя реверсивный счетчик можно заменить цифровым процессором, при этом шаг S становится переменным, но кратным некоторому базовому значению.

Существуют много других способов кодирования человеческого голоса, среди них наиболее эффективный реализован в приборах, носящих название - вокодер (VOCODER).

Спецификация протокола DHCP для системы клиент-сервер

4. Спецификация протокола DHCP для системы клиент-сервер

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

4.1. Формирование и посылка сообщений DHCP

Клиенты и серверы DHCP конструируют DHCP-сообщения путем заполнения полей в секции сообщения с фиксированным форматом и присоединяя помеченные информационные элементы переменной длины в секции опций. Область опций включает в себя 4-октетную секцию 'magic cookie' (которая описана в разделе 3), за которой следуют собственно опции. Последняя опция должна быть всегда опцией 'end'.

DHCP использует в качестве транспортного протокола UDP. DHCP-сообщения от клиента к серверу посылаются через порт DHCP-сервера (67), а DHCP-сообщения от сервера к клиенту посылаются через порт DHCP-клиента (68). Сервер с несколькими сетевыми адресами (например, ЭВМ с несколькими сетевыми интерфейсами) может использовать для передачи исходящего DHCP-сообщения любой из своих сетевых адресов.

Поле 'server identifier' используется как для идентификации DHCP-сервера в DHCP-сообщении, так и в качестве адреса места назначения при передаче информации от клиента серверу. Сервер с несколькими сетевыми адресами должен быть готов воспринимать любой из своих сетевых адресов в качестве идентификатора в DHCP-сообщении. Чтобы адаптироваться к потенциально не полной сетевой коннективности, сервер должен выбрать адрес в качестве 'server identifier', который по информации сервера доступен со стороны клиента. Например, если DHCP-сервер и DHCP-клиент подключены к одной субсети (т.e., поле 'giaddr' в сообщении от клиента равно нулю), сервер должен выбрать свой IP-адрес, используемый для передачи в пределах субсети в качестве 'server identifier'. Если сервер использует несколько IP-адресов в субсети, он может воспользоваться любым таким адресом. Если сервер получил сообщение через DHCP-агента доставки, сервер должен в качестве 'server identifier' выбрать адрес интерфейса, через который получено сообщение, (если только сервер не имеет других, лучших идей по поводу такого выбора).
DHCP-клиенты должны использовать IP-адрес, переданный через опцию 'server identifier', для любого уникастного запроса, адресованного DHCP-серверу.

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

Если поле 'giaddr' в DHCP-сообщении клиента не равно нулю, сервер посылает любой отклик в порт 'DHCP server' агента транспортировки BOOTP, чей адрес указан в 'giaddr'. Если поле 'giaddr' равно нулю, а поле 'ciaddr' не равно нулю, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по уникастному адресу, записанному в поле 'ciaddr'. Если 'giaddr' равно нулю и 'ciaddr' равно нулю, а бит broadcast =1, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по адресу 0xffffffff. Если бит broadcast =1 и 'giaddr' равно нулю и 'ciaddr' равно нулю, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по аппаратному адресу клиента и адресу 'yiaddr'. Во всех случаях, когда 'giaddr' равно нулю, сервер широковещательно посылает любое сообщение DHCPNAK по адресу 0xffffffff.

Если опции в DHCP-сообщении распространяются на поля 'sname' и 'файл', в поле 'опции' должна появиться опция 'option overload', со значением 1, 2 или 3, как это специфицировано в RFC-1533. Если в поле 'опции' присутствует опция 'option overload', опции в этом поле должны завершаться опцией 'end', и могут содержать один или более опций 'pad' (заполнитель). Опции в полях 'sname' и 'файл' (если их применение индицировано опцией 'options overload') должны начинаться с первого октета поля, завершаться опцией 'end', и за ними для заполнения пространства до конца поля должны следовать опции 'pad'. Любая индивидуальная опция в полях 'опции', 'sname' и 'файл' должна полностью умещаться в поле. Опции в поле 'options' должны интерпретироваться первыми, так чтобы любая 'option overload' могла быть воспринята. Поле 'файл' должно интерпретироваться следующим (если опция 'option overload' указывает, что поле 'файл' содержит опции DHCP), за ним должно следовать поле 'sname'.



Значения, передаваемые в метку 'option' могут превосходить по длине 255 октетов, выделенных на одну опцию (например, список маршрутизаторов опции 'router' [21]). Опции могут появляться только раз, если только явно не указано обратного. Клиент присоединяет значения кратных опций к общему списку параметров для конфигурации.

Клиенты DHCP ответственны за доставку всех сообщений. Клиент должен адаптировать стратегию повторных передач, которая включает в себя экспоненциальный алгоритм вычисления псевдослучайных задержек между повторными пересылками. Задержки между повторными пересылками должны быть выбраны так, чтобы предоставить достаточно времени для ответов сервера с учетом условия связи между клиентом и сервером. Например, в сети 10Mбит/c Ethernet, задержка перед первой повторной посылкой должна быть случайным образом равномерно распределенной при среднем значении 4 секунды. Задержка следующей (второй) ретрансмиссии должна быть также случайной и составлять 8 секунд. Значения последовательных повторных передач должны при каждой последующей попытке удваиваться. Максимальное значение равно 64 секунд. Клиент может обеспечить для пользователя индикацию попыток повторной передачи.

Поле 'xid' используется клиентом для установления соответствия между приходящим DHCP-сообщением и отправленного ранее запросом. DHCP-клиент должен выбрать 'xid так чтобы минимизировать вероятность получения идентичных 'xid' разными клиентами. Например, клиент может выбирать разные, случайные начальные 'xid' каждый раз, когда клиент перезагружается, а далее использует инкрементацию этого значения при последующих передачах вплоть до следующей перезагрузки. Выбор нового 'xid' для каждой последующей повторной передачи относится на усмотрение конкретной программной реализации. Клиент может решить повторно использовать то же самое значение 'xid' или выбрать новый 'xid' для передачи каждого сообщения.

В норме, DHCP-серверы и агенты доставки BOOTP пытаются доставить сообщения DHCPOFFER, DHCPACK и DHCPNAK непосредственно клиенту, используя уникастную адресацию.


IP-адрес места назначения (в IP-заголовке) равен адресу 'yiaddr', а адрес связного уровня равен 'chaddr'. К сожалению, некоторые реализации клиентов не могут получать уникастные IP-дейтограммы до тех пор, пока приложение не будет сконфигурировано и клиент не получит корректный IP-адрес (это ведет к тупику, когда IP-адрес не может быть получен клиентом до тех пор, пока в результате конфигурационного процесса он этот самый адрес не получит).

Клиент, который не может получать уникастные IP-дейтограммы, пока его протокольная программа не сконфигурирована, должен установить бит BROADCAST=1 в поле флагов в любом сообщении DHCPDISCOVER или DHCPREQUEST, которые клиент посылает. Бит BROADCAST укажет, что DHCP-сервер и агент транспортировки BOOTP должны посылать клиенту сообщения широковещательно. Клиент, который может получать уникастные IP-дейтограммы до того как его программа сконфигурирована, должен сделать бит BROADCAST равным 0.

Сервер или агент доставки, посылающие или передающие DHCP-сообщение непосредственно DHCP-клиенту (т.e., не агенту транспортировки, указанному в поле 'giaddr'), должны анализировать бит BROADCAST поля 'флаги'. Если этот бит равен 1, DHCP-сообщение должно быть послано как широковещательное по адресу 0xffffffff. Если бит BROADCAST равен 0, сообщение должно быть послано по уникастному IP-адресу указанному в поле 'yiaddr'. Если уникастная транспортировка невозможна, сообщение может быть послано по широковещательному адресу 0xffffffff.



4.2. Административное управление сервером DHCP



DHCP-серверы не обязаны откликаться на каждое сообщение DHCPDISCOVER и DHCPREQUEST, которое они получают. Например, сетевой администратор с целью сохранения строгого контроля за клиентами, подключенными к сети, может захотеть сконфигурировать DHCP-серверы так, чтобы они реагировали только на клиентов, которые были зарегистрированы ранее с помощью некоторого внешнего механизма. Спецификация DHCP описывает только взаимодействие между клиентами и серверами, когда они хотят этого; описание административного контроля со стороны системного администратора находится вне пределов данной спецификации.


Специальные реализации DHCP-серверов могут включать в себя любые механизмы административного контроля.

При некоторых условиях, DHCP-сервер будет должен проанализировать значения опций vendor class, включенные в сообщения DHCPDISCOVER или DHCPREQUEST с тем, чтобы определить корректные параметры для конкретного клиента.

DHCP-сервер должен использовать некоторый уникальный идентификатор, для того чтобы установить соответствие между клиентом и его набором конфигурационных параметров. Клиент может решить выдать идентификатор с помощью опции 'client identifier'. Если клиент предоставляет 'client identifier', он должен использовать его во всех последующих сообщениях, а сервер должен использовать этот идентификатор для распознавания клиента. Если клиент не предоставляет опцию 'client identifier', сервер должен для идентификации клиента использовать содержимое поля 'chaddr'. Для клиента DHCP весьма важно использовать уникальный идентификатор в пределах субсети, к которой он подключен согласно опции 'client identifier'. Использование 'chaddr' в качестве уникального идентификатора клиента может вызвать непредсказуемые результаты, так как такой идентификатор может быть ассоциирован с аппаратным интерфейсом, который может быть передан новому клиенту. Чтобы избежать непредсказуемых изменений сетевого адреса клиента (из-за переноса аппаратного интерфейса) некоторые узлы могут использовать в качестве идентификатора клиента серийный номер производителя. Сетевые узлы могут также использовать в качестве идентификатора клиента DNS-имя.

Клиенты DHCP вольны использовать любую стратегию при выборе DHCP-сервера из числа тех, список которых клиент получает в сообщении DHCPOFFER. Реализация клиента должна предоставлять для пользователя механизм выбора значений 'vendor class identifier'.



4.3. Поведение сервера DHCP



DHCP-сервер обрабатывает приходящие от клиента DHCP-сообщения на основе текущего состояния набора конфигурирующих параметров клиента. DHCP-сервер может получать от клиента следующие сообщения:



o DHCPDISCOVER

o DHCPREQUEST

o DHCPDECLINE

o DHCPRELEASE

o DHCPINFORM

В таблице 3 рассмотрено использование полей и опций в DHCP-сообщении сервера.



4.3.1. Сообщение DHCPDISCOVER



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

o	Текущий адрес клиента, как это записано в текущем блоке параметров клиента, в противном случае
o	Предшествующий адрес клиента, как это записано в текущем блоке параметров клиента (срок действия которого истек или использование которого прекратилось), если этот адрес находится в пуле доступных адресов сервера, в противном случае
o	Адрес запрошенный в опции 'Запрошенный IP-адрес', если адрес корректен и еще не присвоен, в противном случае
o	Новый адрес, полученный из пула свободных адресов; адрес выбирается с учетом субсети, откуда получено сообщение (если 'giaddr' = 0) или с учетом адреса агента транспортировки, который доставил сообщение (когда 'giaddr' не равен 0).

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

Заметим, что в некоторых сетевых архитектурах (например, в Интернет с более чем одной IP-субсетью, сопряженной с физическим сетевым сегментом), DHCP-клиенту должен быть присвоен адрес из другой субсети, а не адрес, записанный в 'giaddr'. Таким образом, DHCP не требует, чтобы клиенту был присвоен адрес из субсети 'giaddr'. Сервер волен выбрать какую-то другую субсеть. Механизм выбора IP-адреса находится вне пределов данной спецификации.

Если это не требуется для корректной работы DHCP, сервер не должен повторно использовать выбранный сетевой адрес, прежде чем клиент пришлет сообщение серверу DHCPOFFER. Сервер может решить записать этот адрес, как предложенный клиенту.


Он должен также выбрать время действия конфигурационного набора, согласно следующим правилам:

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

Ссылки

Ссылки

[1]	Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, March 1997.
[2]	Technical Standard: Network Computing Client, The Open Group, Document Number C801, October 1998.
[3]	Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC-2068, January 1997.
[4]	Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol, Version 3.0", Netscape Communications Corp., November 1996. Standards Information Base, The Open Group, http://www.db.opengroup.org/sib.htm#SSL_3.
[5]	Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC-1738, December 1994.
[6]	Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC-2132, March 1997.

/p>

A. Параметры конфигурации ЭВМ



IP-layer_parameters,_per_host:_

Быть маршрутизатором	on/off	HRC 3.1
Non-local source routing	on/off	HRC 3.3.5
Фильтры для non-local source routing	(список)	HRC 3.3.5
Maximum reassembly size	целое	HRC 3.3.2
TTL по умолчанию	целое	HRC 3.2.1.7
PMTU aging timeout	целое	MTU 6.6
MTU plateau table	(список)	MTU 7
IP-layer_parameters,_per_interface:
IP -адрес Маска субсети MTU All-subnets-MTU Широковещательный адрес Определить маску Быть поставщиком масок Выполнять поиск маршрутизатора Router solicitation address	(адрес)	HRC 3.3.1.6
(маска адреса)	HRC 3.3.1.6
целое	HRC 3.3.3
on/off	HRC 3.3.3
0x00000000/0xffffffff	HRC 3.3.6
on/off	HRC 3.2.2.9
on/off	HRC 3.2.2.9
on/off	RD 5.1
(адрес)	RD 5.1
Маршрутизаторы по умолчанию:
Адрес маршрутизатора	(адрес)	HRC 3.3.1.6
Уровень предпочтения	целое	HRC 3.3.1.6
Статические маршруты, список:
Место назначения	(host/subnet/net)	HRC 3.3.1.2
Маска места назначения	(маска адреса)	HRC 3.3.1.2
Тип услуг	целое	HRC 3.3.1.2
Соседний маршрутизатор	(адрес)	HRC 3.3.1.2
Игнорирование переадресации	on/off	HRC 3.3.1.2
PMTU	целое	MTU 6.6
Выполнить поиск PMTU	on/off	MTU 6.6

Link-layer_parameters,_per_interface:_

Trailers	on/off	HRC 2.3.1
Таймаут ARP кэша	целое	HRC 2.3.2.1
Инкапсуляция Ethernet	RFC-894/RFC-1042	HRC 2.3.3

TCP_parameters,_per_host:_

TTL	целое	HRC 4.2.2.19
Интервал Keep-alive	целое	HRC 4.2.3.6
Размер данных Keep-alive	0/1	HRC 4.2.3.6

Key:

MTU = Path MTU Discovery (RFC-1191, предлагаемый стандарт)

RD = Router Discovery (RFC-1256, предлагаемый стандарт)



Опция DHCP для протокола аутентификации пользователей открытых групп


(RFC-2485, S. Drach, DHCP Option for The Open Group's User Authentication Protocol)

Технический стандарт для клиента вычислительной сети разработан рабочей группой по сетевым вычислениям NCWG (Network Computing Working Group), он определяет схему аутентификации клиента-пользователя в вычислительной сети, которая носит название протокола аутентификации пользователя (UAP).



UAP предлагает два уровня аутентификации, базовый и безопасный. Базовая аутентификация использует механизм, определенный в спецификации HTTP 1.1 [3]. Безопасная аутентификация является просто аутентификацией реализованной в рамках сессии SSLv3 [4].

В обоих случаях клиент UAP должен получить IP-адрес и номер порта службы UAP. В зависимости от реализации системы может потребоваться дополнительная информация о проходе. URL [5] представляет прекрасный механизм инкапсуляции этой информации, так как многие серверы UAP реализуются как часть HTTP/SSL-серверов.

Большинство клиентов UAP конфигурируются при загрузке через DHCP. Ни одна из существующих опций DHCP [6] не имеет информационных полей, содержащих URL. Опция 72 содержит список IP-адресов WWW-серверов, но она не адекватна задаче, так как нельзя специфицировать номер порта и/или проход. Следовательно, нужна опция, которая содержит список URL.



Опция протокола аутентификации пользователя



Эта опция специфицирует список URL, каждый из которых указывает на сервер аутентификации пользователя, способный обрабатывать запросы, реализуемые через протокол UAP. Серверы UAP могут воспринимать соединения HTTP 1.1 или SSLv3. Если список содержит URL, который не содержит данных о номере порта, присваивается значение порта по умолчанию (т.e., порт 80 для http и порт 443 для https). Если список включает в себя URL, который не содержит данных о проходе, предполагается проход /uap. На Рисунок 1 показан формат опции аутентификации пользователя.

Структура взаимодействия с серверами имен

Рисунок 4.4.12.1. Структура взаимодействия с серверами имен

База имен является распределенной, так как нет такой ЭВМ, где бы хранилась вся эта информация. Как уже отмечалось имя содержит несколько полей (длиной не более 63 символов), разделенных точками. Имя может содержать не более 255 октетов, включая байт длины. Анализ имени производится справа налево. Самая правая секция имени характеризует страну (двухсимвольные национальные коды смотри в приложении), или характер организации образовательная, коммерческая, правительственная и т.д.).

Следующие 3-х символьные коды в конце Internet-адреса означают функциональную принадлежность узла:

Структурная схема реализации алгоритма DEA

Рисунок 6.4.1.2. Структурная схема реализации алгоритма DEA

Инверсная перестановка разрядов предполагает следующее размещение 64 бит зашифрованных данных (первым битом становится 40-ой, вторым 8-ой и т.д.).

40 8 48 16 56 24 64 32

39 7 47 15 55 23 63 31

38 6 46 14 54 22 62 30

37 5 45 13 53 21 61 29

36 4 44 12 52 20 60 28

35 3 43 11 51 19 59 27

34 2 42 10 50 18 58 26

33 1 41 9 49 17 57 25

S-матрицы представляют собой таблицы содержащие 4-ряда и 16 столбцов. Матрица S(1) представлена ниже (эта матрица, также как и те, что приведены в ссылке 2, являются рекомендуемыми).

No. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7

1 0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8

2 4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0

3 15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13

Исходный 48-разрядный код делится на 8 групп по 6 разрядов. Первый и последний разряд в группе используется в качестве адреса строки, а средние 4 разряда – в качестве адреса столбца. В результате каждые 6 бит кода преобразуются в 4 бита, а весь 48-разрядный код в 32-разрядный (для этого нужно 8 S-матриц). Существуют разработки, позволяющие выполнять шифрование в рамках стандарта DES аппаратным образом, что обеспечивает довольно высокое быстродействие.

Преобразования ключей Kn (n=1,…,16; Kn = KS(n,key), где n – номер итерации) осуществляются согласно алгоритму, показанному на Рисунок 6.4.1.3.

Сжатие данных с использованием преобразования Барроуза-Вилера

2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера

Майкл Барроуз и Давид Вилер (Burrows-Wheeler) в 1994 году предложили свой алгоритм преобразования (BWT). Этот алгоритм работает с блоками данных и обеспечивает эффективное сжатие без потери информации. В результате преобразования блок данных имеет ту же длину, но другой порядок расположения символов. Алгоритм тем эффективнее, чем больший блок данных преобразуется (например, 256-512 Кбайт). Пояснение работы алгоритма будет выполнено на ограниченном объеме исходных данных (строка S длиной N, например, SEMENOV). Строка S рассматривается как последовательность, состоящая из N строк.

Сначала осуществляется циклический сдвиг строки S и формируется N-1 новая строка. На практике строки не размножаются, а создается массив указателей на циклический буфер, где лежит исходная строка S.

	Строка
S E M E N O V	S0
E M E N O V S	S1
M E N O V S E	S2
E N O V S E M	S3
N O V S E M E	S4
O V S E M E N	S5
V S E M E N O	S6

Далее выполняется лексикографическое упорядочение (сортировка) этих строк (указателей). Для упорядочения можно использовать С-функции типа strcmp() или memcmp() (учитывая особенности структуры буфера, это должны быть их функциональные аналоги).

F						L	Строка
E	M	E	N	O	V	S	S1
E	N	O	V	S	E	M	S3
M	E	N	O	V	S	E	S2
N	O	V	S	E	M	E	S4
O	V	S	E	M	E	N	S5
S	E	M	E	N	O	V	S0
V	S	E	M	E	N	O	S6

Первая колонка помечена буквой F, а последняя – L. Колонка F (EEMNOSV) содержит все символы исходной строки S, записанные в упорядоченной последовательности. Строка L представляет собой последовательность префиксных символов для строки S.

Результатом работы алгоритма BWT является строка L и первичный индекс, который представляет собой номер элемента строки L, где хранится первый символ исходной строки S. В приведенном примере индекс равен 1.

Смотри

http://web2.airmail/markn/articles/bwt/bwt.htm

PC-1 (Выбор 1)

Таблица 6.4.1.1

PC-1 (Выбор 1)	PC-2 (Выбор 2)
57 49 41 33 25 17 9	14 17 11 24 1 5
1 58 50 42 34 26 18	3 28 15 6 21 10
10 2 59 51 43 35 27	23 19 12 4 26 8
19 11 3 60 52 44 36	16 7 27 20 13 2
63 55 47 39 31 23 15	41 52 31 37 47 55
7 62 54 46 38 30 22	30 40 51 45 33 48
14 6 61 53 45 37 29	44 49 39 56 34 53
21 13 5 28 20 12 4	46 42 50 36 29 32

Таблица 6.4.1.2

Номер итерации	Число сдвигов влево
1	1
2	1
3	2
4	2
5	2
6	2
7	2
8	2
9	1
10	2
11	2
12	2
13	2
14	2
15	2
16	1

Таблица

Таблица 5.1.

Название команды	Назначение
arp	Отображает или модифицирует таблицу протокола ARP (преобразование IP в MAC-адреса)
chnamsv	Служит для изменения конфигурации службы имен на ЭВМ (для TCP/IP)
chprtsv	Изменяет конфигурацию службы печати на ЭВМ-клиенте или сервере
gettable	Получает таблицы ЭВМ в формате NIC
hostent	Непосредственно манипулирует записями адресного соответствия ЭВМ в конфигурационной базе данных системы
hostid	Устанавливает или отображает идентификатор данной ЭВМ
hostname	Устанавливает или отображает имя данной ЭВМ
htable	Преобразует файлы ЭВМ в формат, используемый программами сетевой библиотеки
ifconfig	Конфигурирует или отображает параметры сетевых интерфейсов ЭВМ (для протоколов TCP/IP)
ipreport	Генерирует сообщение о маршруте пакета на основе специфицированного маршрутного файла
iptrace	Обеспечивает отслеживание маршрута движения пакетов на интерфейсном уровне для протоколов Интернет
lsnamsv	Отображает информацию базы данных DNS
lsprtsv	Отображает информацию из базы данных сетевой службы печати
mkhost	Создает файл таблицы ЭВМ
mknamsv	Конфигурирует службу имен клиента (для TCP/IP)
mkprtsv	Конфигурирует службу печати ЭВМ (для TCP/IP)
mktcpip	Устанавливает требуемые величины для запуска TCP/IP на ЭВМ
namerslv	Непосредственно манипулирует записями сервера имен для локальной программы DNS в базе данных конфигурирования системы
netstat	Отображает состояние сети
no	Конфигурирует сетевые опции
rmnamsv	Удаляет TCP/IP службу имен из ЭВМ
rmprtsv	Удаляет службу печати на машине клиента или сервере
route	Служит для ручного манипулирования маршрутными таблицами
ruptime	Отображает состояние каждой ЭВМ в сети
ruser	Непосредственно манипулирует записями в трех отдельных системных базах данных, которые регулируют доступом внешних ЭВМ к программам
securetcpip	Активизирует сетевую безопасность
setclock	Устанавливает время и дату для ЭВМ в сети
slattach	Подключает последовательные каналы в качестве сетевых интерфейсов
timedc	Присылает информацию о демоне timed
trpt	Выполняет отслеживание реализации протокола для TCP-сокетов

<

характеризует различие между сообщениями клиента в различных состояниях

Таблица 4 характеризует различие между сообщениями клиента в различных состояниях

Коды ошибок

Таблица 4.4.11.4.1. Коды ошибок

Код ошибки	Описание
1	Ошибка в заголовке сообщения.
2	Ошибка в сообщении open
3	Ошибка в сообщении update
4	Истекло время сохранения
5	Ошибка машины конечных состояний
6	Прерывание

При отсутствии фатальной ошибки BGP-партнер может в любой момент прервать связь, послав NOTIFICATION-сообщение с кодом ошибки прерывание.

Одно-октетное поле cубкод ошибки предоставляет дополнительную информацию об ошибке. Каждый код ошибки может иметь один или более субкодов. Если поле содержит нуль, это означает, что никаких субкодов не определено.

Коды поля флаги

Таблица 4.4.12.2. Коды поля флаги

Код поля флаги	Описание
0 (qr)	Операция:	0 Запрос 1 Отклик
1…4	Тип запроса (opcode):	0 стандартный 1 инверсный 2 запрос состояния сервера
5 (aa)	Равен 1 при ответе от сервера, в ведении которого находится домен, упомянутый в запросе.
6 (tc)	Равен при укорочении сообщения. Для UDP это означает, что ответ содержал более 512 октетов, но прислано только первые 512.
7 (rd)	Равен 1, если для получения ответа желательна рекурсия.
8 (ra)	Равен 1, если рекурсия для запрашиваемого сервера доступна.
9…11	Зарезервировано на будущее. Должны равняться нулю.
12…15	Тип отклика (rcode):	0 нет ошибки 1 ошибка в формате запроса 2 сбой в сервере 3 имени не существует

Ниже описан формат секции вопросов в DNS-сообщении.

Опции программы dig

Таблица 5.3 Опции программы dig

Тип запроса	Запись DNS-сервера
a	Адресная запись
any	Любой тип записи
axfr	Все записи, относящиеся к зоне
hinfo	Записи, характеризующие ЭВМ
mx	Записи, определяющие почтовый обмен
ns	Записи сервера имен
soa	Начало записей для зоны ответственности DNS-сервера
txt	Текстовые записи

Ниже приведен пример использования команды dig для сервера имен узла DESY (Гамбург):

dig @vxdesy.desy.de ns

; <<>> DiG 2.0 <<>> @vxdesy.desy.de ns

; (3 servers found)

;; res options: init recurs defnam dnsrch

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10

;; flags: qr rd ra; Ques: 1, Ans: 9, Auth: 9, Addit: 9

;; QUESTIONS:

;;., type = NS, class = IN

;; ANSWERS:

.	185470	NS	A.ROOT-SERVERS.NET.
.	185470	NS	H.ROOT-SERVERS.NET.
.	185470	NS	B.ROOT-SERVERS.NET.
.	185470	NS	C.ROOT-SERVERS.NET.
.	185470	NS	D.ROOT-SERVERS.NET.
.	185470	NS	E.ROOT-SERVERS.NET.
.	185470	NS	I.ROOT-SERVERS.NET.
.	185470	NS	F.ROOT-SERVERS.NET.
.	185470	NS	G.ROOT-SERVERS.NET.

;; AUTHORITY RECORDS:

.	185470	NS	A.ROOT-SERVERS.NET.
.	185470	NS	H.ROOT-SERVERS.NET.
.	185470	NS	B.ROOT-SERVERS.NET.
.	185470	NS	C.ROOT-SERVERS.NET.
.	185470	NS	D.ROOT-SERVERS.NET.
.	185470	NS	E.ROOT-SERVERS.NET.
.	185470	NS	I.ROOT-SERVERS.NET.
.	185470	NS	F.ROOT-SERVERS.NET.
.	185470	NS	G.ROOT-SERVERS.NET.

;; ADDITIONAL RECORDS:

A.ROOT-SERVERS.NET.	531366	A	198.41.0.4
H.ROOT-SERVERS.NET	531366	A	128.63.2.53
B.ROOT-SERVERS.NET.	531366	A	128.9.0.107
C.ROOT-SERVERS.NET.	578733	A	192.33.4.12
D.ROOT-SERVERS.NET.	578733	A	128.8.10.90
E.ROOT-SERVERS.NET.	547664	A	192.203.230.10
I.ROOT-SERVERS.NET.	578733	A	192.36.148.17
F.ROOT-SERVERS.NET.	531366	A	192.5.5.241
G.ROOT-SERVERS.NET.	531366	A	192.112.36.4

;; FROM: ns.itep.ru to SERVER: vxdesy.desy.de 131.169.30.46

;; WHEN: Thu Jul 25 12:07:54 1996

;; MSG SIZE sent: 17 rcvd: 429

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

ifconfig le0

le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST>

inet 193.124.224.35 netmask ffffffe0 broadcast 193.124.224.32
Флаг UP означает, что интерфейс готов к использованию, DOWN указывает на необходимость перевода интерфейса в состояние UP с помощью команды ifconfig le0 up. Если эта команда не проходит, следует проверить соединительный кабель или сам интерфейс. Флаг RUNNING говорит о том, что интерфейс работает. При отсутствии этого флага следует проверить правильность инсталляции. Флаг BROADCAST указывает на то, что интерфейс поддерживает широковещательный режим адресации (MULTICAST - допускает многоадресное обращение). Флаг NOTRAILERS - показывает, что интерфейс не поддерживает trailer-инкапсуляцию (Ethernet). Вторая строка отклика на команду начинается с ключевого слова inet (Интернет) и содержит IP-адрес, маску субсети и широковещательный адрес. На ошибку в задании маски субсети указывает факт доступности удаленных ЭВМ и машин локальной субсети при недоступности ЭВМ соседних субсетей. При неверном задании IP-адреса возможны самые разные ошибки. При неверной сетевой части адреса команда Ping будет вызывать ошибку типа “no answer”. Ошибка же в части адреса, характеризующей ЭВМ, может быть не замечена в течение длительного времени, если носителем ошибочного адреса является персональная ЭВМ, обращений к которой извне не происходит. Определенное время можно использовать и чужой IP-адрес. Такого рода ошибки не могут быть выявлены с помощью ifconfig, здесь хорошую службу может оказать программа arp (см. описание протокола в RFC-826). Эта программа позволяет анализировать преобразование IP-адресов в физические (Ethernet). Она имеет несколько полезных опций (возможны вариации для разных реализаций и ОС):

-a	отображает содержимое всей ARP-таблицы
-d <имя ЭВМ>	удаляет запись из ARP-таблицы
-s <имя ЭВМ> <Ethernet-адрес>	добавляет новую запись в таблицу

Ниже приведен пример исполнения команды arp, которая печатает имя объекта, его IP- и физический адреса (следует иметь в виду, что содержимое ARP-таблиц изменяется со временем, время хранения записи задается администратором сети):

arp -a

itepgw.itep.ru	(193.124.224.33) at 0:0:c:2:3a:49
ITEP-FDDI-BBone.ITEP.RU	(193.124.224.50) at 0:0:c:2:fb:c5
RosNET-Gw.ITEP.Ru	(193.124.224.37) at 0:c0:14:10:1:cd
nb.itep.ru	(193.124.224.60) at 0:80:ad:2:24:b7

Указанием на наличие ошибки в ARP-таблице может служить сообщение о недоступности или неизвестности ЭВМ при выполнении команд типа FTP или telnet. Такие сообщения возможны, например, при использовании одного и того же IP-адреса двумя ЭВМ. Все зависит от того, какая из машин успела “прописаться” в ARP-таблице раньше. Просматривая таблицу, администратор может заметить, что одному и тому же IP-адресу временами соответствуют разные физические адреса. Легальность адреса может быть проверена с помощью содержимого файла /etc/ethers. Первые три байта физического адреса характеризуют производителя интерфейса (см. Assigned Numbers, RFC-1700), что может помочь найти “IP-двойника”. Если анализ ARP-таблицы не помог, попробуйте войти в ЭВМ, соответствующую подозрительному адресу, с помощью команды telnet. Если ЭВМ допускает удаленный доступ, характер входного сообщения поможет разобраться, что это за машина.
Одной из наиболее информативных команд является netstat (за исчерпывающим описанием опций и методов применения отсылаю к документации на ваше сетевое программное обеспечение). Эта команда может вам дать информацию о состоянии интерфейсов на ЭВМ, где она исполнена:

netstat -i

Name	Mtu	Net/Dest	Address	Ipkts	Ierrs	Opkts	Oerrs	Collis	Queue
le0	1500	193.124.224.32	ns	966204	0	584033	0	846	0
lo0	1536	127.0.0.0	127.0.0.1	4191	0	4191	0	0	0

<


Name - имя интерфейса, если в этом поле стоит *, это означает, что интерфейс в состоянии down; Net/Dest - показывает IP- адрес сети или ЭВМ, куда интерфейс осуществляет доступ; Address - IP-адрес интерфейса; Ipkt - число принятых пакетов; Ierr - число ошибок при приеме пакетов; Opkts - число отправленных пакетов через данный интерфейс, Oerrs - число ошибок при отправке; Collis - число столкновений в сегменте Ethernet, зафиксированных интерфейсом; Queue - длина очереди пакетов, ждущих отправки. Программа nrtstat позволяет ознакомиться и с маршрутной таблицей:

netstat -nr

Маршрутная таблица

Место назначения	Маршрутизатор	Флаги	Refcnt	Use	Интерфейс
192.148.166.185	193.124.224.33	UGHD	0	0	le0
192.148.166.161	193.124.224.33	UGHD	0	0	le0
192.148.166.97	193.124.224.33	UGHD	0	0	le0
192.148.166.177	193.124.224.33	UGHD	0	0	le0
192.148.166.129	193.124.224.33	UGHD	1	192	le0
192.148.166.145	193.124.224.33	UGHD	0	72	le0
192.148.166.170	193.124.224.33	UGHD	0	4	le0
192.148.166.26	193.124.224.60	UGHD	0	19	le0
192.148.166.131	193.124.224.33	UGHD	0	0	le0
192.148.166.140	193.124.224.33	UGHD	0	0	le0
192.148.166.173	193.124.224.33	UGHD	0	2	le0
192.148.166.182	193.124.224.33	UGHD	0	20	le0
192.148.166.142	193.124.224.33	UGHD	0	300	le0

Колонка место назначения указывает на конечную точку маршрута, колонка маршрутизатор - имя маршрутизатора, через который достижим адресат. Флаг "U" (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг "G" указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора или его адрес. Если флаг "G" отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг "D" указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом "H" (host), при этом первая колонка таблицы содержит его IP-адрес.


Флаг “M” указывает на то, что маршрут был изменен с помощью сообщения о переадресации. Флаг <null> говорит о том, что адресат достижим непосредственно.
Возможности netstat не ограничиваются локальной сетью или автономной системой, с помощью ее можно получить некоторую информацию об удаленных ЭВМ или маршрутизаторах. Например:

netstat -r 194.85.112.34

input packets	(le0) errs	output packets	errs	colls	input packets	Total errs	Output packets	errs	colls
7636610	0	4578719	0	5918	7674851	0	4616960	0	5918

Это может быть полезно при экспресс диагностике внешних каналов связи, когда простого ping или traceroute оказалось недостаточно. Если возникло подозрение относительно маршрутизации пакетов, можно сначала проверить работает ли программа gated, для этого выдайте команду:
ps ‘cat /etc/gated.pid’

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

showmount -e ns (ns - имя ЭВМ)

export list for ns.itep.ru:

/u1/SunITEP saturn.itep.ru,suncom.itep.ru
Крайне полезна для контроля конфигурации системы команда host, она имеет много опций и с ее помощью можно узнать о доступных типах услуг, об именах и IP-адресах почтовых серверов и серверов имен, о кодах их предпочтения и т.д..

host -a vitep5

Trying domain "itep.ru"

rcode = 3 (Non-existent domain), ancount=0

Trying null domain

rcode = 0 (Success), ancount=6

vitep5.itep.ru	86400	IN	WKS	192.148.166.198 tcp ftp telnet
vitep5.itep.ru	86400	IN	HINFO	VAX-8530	VMS 5.3
vitep5.itep.ru	86400	IN	MX	15	mx.itep.ru
vitep5.itep.ru	86400	IN	MX	200	relay1.kiae.su
vitep5.itep.ru	86400	IN	MX	210	relay2.kiae.su
vitep5.itep.ru	86400	IN	A	192.148.166.198

Additional information:

relay1.kiae.su	18938 IN	A	193.125.152.6
relay1.kiae.su	18938 IN	A	193.125.152.1
relay2.kiae.su	18938 IN	A	193.125.152.1

Во второй колонке данной выдачи указано время жизни пакетов (TTL) в секундах. Значение TTL в первых строках соответствует суткам (24x60x60=86400). IN в следующей колонке указывает на принадлежность к классу Интернет. В четвертой колонке проставлены указатели типов запроса. В пятой колонке идут названия серверов, IP-адреса ЭВМ и коды предпочтения (15, 200 и 210). Более подробно о возможностях этой команды можно ознакомиться в [11].
В последнее время появилось несколько комплексных (общедоступных) пакетов диагностики (NetWatch, WS_watch, SNMPMAN, Netguard и др.). Некоторые из этих пакетов позволяют построить графическую модель тестируемой сети, выделяя цветом или с помощью вариации картинок работающие ЭВМ. Программы, использующие протокол SNMP, проверяют наличие посредством специального запроса доступность SNMP-демона, с помощью ICMP-протокола определяют работоспособность ЭВМ, после чего отображают переменные и массивы данных из управляющей базы данных MIB (если эта база имеет уровень доступа public). Это может делаться автоматически или по запросу оператора. SNMP-протокол позволяет мониторировать вариации загрузки отдельных сегментов сети пакетами UDP, TCP, ICMP и т.д., регистрируя количество ошибок по каждому из активных интерфейсов. Для решения этой задачи можно использовать соответствующую программу, которая регулярно опрашивает MIB интересующих вас ЭВМ, а полученные числа заносятся в соответствующий банк данных. При возникновении нештатной ситуации администратор сети может просмотреть вариации потоков в сегментах сети и выявить время и причину сбоя в системе. Аналогичные данные можно получить с помощью программы, переводящей интерфейс Ethernet в режим приема всех пакетов (mode=6). Такая программа допускает получение данных по всем типам пакетов, циркулирующих в данном кабельном сегменте. Введя в программу определенные фильтры (отбор по IP-адресам отправителей, получателей, по широковещательным запросам или определенным протоколам) можно узнать много полезного о своей сети. К сожалению, этот метод пригоден только в отношении логического сегмента, к которому подключена ваша ЭВМ. Такие программы могут использоваться для контроля сетевых ресурсов, если ЭВМ размещена на соответствующем сегменте, что может оказаться актуально в связи с коммерциализацией сетевых услуг. По этой причине метод диагностики через SNMP-резидентов более универсален. Упомянутые в начале программы Tcpdump и Etherfind крайне полезны для отладки программ, работающих с сетевыми пакетами. Они позволяют отображать все входящие и посылаемые пакеты. Следует иметь в виду, что эти программы потенциально опасны с точки зрения несанкционированного доступа и, поэтому их применение часто возможно только для привилегированных пользователей. Работа интерфейса в режиме перехвата всех пакетов также представляет угрозу безопасности сети (возможность получения чужих паролей). С учетом этого обстоятельства должно приветствоваться использование программного обеспечения, где содержимое пакетов терминального обмена подвергается шифрованию-дешифрованию.
Определенный интерес может представлять диагностическая программа ttcp, которая позволяет измерять некоторые характеристики TCP- или UDP-обменов между двумя узлами (ftp.sgi.com, каталог sgi/src/ttcp или vgr.brl.mil ftp/pub/ttcp.c).
Перечисленные режимы работают в рамках протокола TCP, для исследования процессов, требующих UDP, следует использовать опцию -u. Существует множество других опций, обеспечивающих реализацию самых разнообразных режимов работы (см. [10] и справочные руководства на вашей ЭВМ).
Конфигурация сети и режимы ее работы определяются системными переменными, которые задаются администратором сети. Имена этих сетевых переменных для разных ЭВМ и программных пакетов варьируются. Ниже будут перечислены основные переменные, определяющие работу TCP/IP протоколов для SunOS 4.1.3.

IPFORWARDING - значение этой константы инициализирует системную переменную ip_forwarding. Если она равна -1, IP-дейтограммы никогда не переадресуются, а переменная уже никогда не меняется. Если же она равна 0 (значение по умолчанию), IP-дейтограммы не переадресуются. Переменная принимает значение 1, когда доступны несколько интерфейсов. При значении константы, равном 1, переадресация всегда разрешена.

SUBNETSARELOCAL - константа, определяющая начальное значение переменной ip_subnetsarelocal. Если она равна 1 (по умолчанию), то IP-адрес места назначения с идентификатором сети, идентичным с тем, что имеет ЭВМ- отправитель, считается локальным вне зависимости от идентификатора субсети. Если константа равна нулю, то локальным будет считаться только адрес, принадлежащий данной субсети (при совпадении идентификаторов сети и субсети).

IPSENDREDIRECTS - константа, используемая для определения стартового значения переменной ip_sendredirects. Если константа равна 1, (по умолчанию) ЭВМ при выполнении процедуры forward посылает ICMP-сообщения о переадресации. При равенстве нулю ICMP-сообщения не посылаются.

DIRECTED_BROADCAST - константа, определяющая начальное значение переменной ip_dirbroadcast. Если константа равна 1 (по умолчанию), получаемые дейтограммы, адрес места назначения которых является широковещательным адресом интерфейса, переадресуются на канальный широковещательный уровень. При равенстве нулю такие дейтограммы ничтожаются.
Ряд системных переменных содержится в файле in_proto каталога /usr/kvm/sys/netinet. При изменении этих переменных система должна быть перезагружена.

tcp_default_mss значение MSS протокола TCP для нелокальных адресатов, по умолчанию равна 512.

tcp_keepidle определяет число 500 мс тактов между посылками запросов о работоспособности. По умолчанию равна 14400 (2 час.).

tcp_keepintvl определяет число 500 мс тактов между посылками запросов о работоспособности, когда не получено никакого отклика. По умолчанию эта переменная равна 150 (75сек).

tcp_keeplen используется для обеспечения совместимости с ранними версиями (4.2BSD), должна равняться 1.

tcp_nodelack при неравенстве нулю требует отправки немедленного отклика (ACK), по умолчанию равна нулю.

tcp_recvspace определяет размер входного TCP-буфера и влияет на величину окна. По умолчанию эта переменная равна 4096.

tcp_sendspace определяет размер выходного TCP-буфера, по умолчанию равна 4096.

tcp_ttl задает значение поля TTL в TCP-сегменте, по умолчанию имеет значение 60.

udp_cksum при неравенстве нулю требует вычисления контрольной суммы для отправляемых UDP-дейтограмм и проверки контрольных сумм для получаемых UDP-дейтограмм, если поле контрольной суммы не равно нулю. По умолчанию переменная равна нулю.

udp_recvspace определяет размер входного UDP-буфера, по умолчанию равна 18000, что соответствует двум 9000-байтным дейтограммам.

udp_sendspace задает объем выходного UDP-буфера, ограничивая предельную длину посылаемой дейтограммы. По умолчанию переменная равна 9000.

udp_ttl определяет значение поля TTL для UDP-дейтограмм, значение по умолчанию - 60.
Для изменения значений этих переменных необходимо иметь системные привилегии.

Описание полей сообщения DHCP

Таблица 1. Описание полей сообщения DHCP

Поле	Байт	Описание
op	1	Код операции сообщения / тип сообщения.
1	= BOOTREQUEST, 2 = BOOTREPLY
htype	1	Тип аппаратного адреса, смотри раздел ARP в RFC "Assigned Numbers"; например, '1' для 10 мегабитного Ethernet.
Hlen	1	Длина аппаратного адреса (например, '6' для 10 мегабитного Ethernet).
Шаги	1	Клиент устанавливает это поле равным нулю, поле используется опционно агентами транспортировки, когда загрузка осуществляется через посредника.
Xid	4	ID-транзакции, случайное число, выбираемое клиентом, и используемое как клиентом, так и сервером для установления соответствия между запросами и откликами.
Secs	2	Заполняется клиентом, число секунд с момента начала запроса адреса или рестарта процесса.
Флаги	2	Флаги (смотри Рисунок 2).
Ciaddr	4	IP-адрес клиента заполняется только в случае, если клиент находится в состоянии BOUND, RENEW или REBINDING и может реагировать на запросы ARP.
Yiadd	4	IP-адрес следующего сервера, используемого в процессе загрузки; присылается сервером в DHCPOFFER, DHCPACK.
Giaddr	4	IP-адрес агента транспортировки, используется когда загрузка осуществляется через посредника.
Chaddr	16	Аппаратный адрес клиента.
Sname	64	Опционное имя ЭВМ-сервера, строка завершается нулем.
Файл	128	Имя файла загрузки (Boot-файла), строка завершается нулем; имя "generic" или нуль в DHCPDISCOVER, полное описание прохода в DHCPOFFER.
Опции	var	Поле опционных параметров.

Поле опции имеет переменную длину. Клиент DHCP должен быть готов получать DHCP-сообщения с полем 'опции' длиной, по крайней мере, 312 октетов. Это требование подразумевает, что DHCP-клиент должен быть готов получать сообщения длиной до 576 октетов. DHCP-клиенты могут согласовать применение более длинных DHCP-сообщений с помощью опции 'maximum DHCP message size'. Поле options может быть еще расширено в полях 'файл' и 'sname'.

В случае, когда клиент использует DHCP для начальной конфигурации (прежде чем программа клиента TCP/IP полностью сконфигурирована), DHCP требует использования клиентского программного обеспечения TCP/IP в вольной интерпретации RFC-1122.
Программа TCP/IP должна принять и передать IP-уровню любой IP-пакет, доставленный по аппаратному адресу клиента, до того как IP-адрес будет сконфигурирован; DHCP-серверы и агенты транспортировки BOOTP могут быть неспособны доставить DHCP-сообщения клиентам, которые не могут принимать уникастные дейтограммы, до того, как программа TCP/IP сконфигурирована должным образом.
Для того чтобы работать с клиентами, которые не могут воспринимать уникастные IP-дейтограммы до того, как будет сконфигурирована программа TCP/IP, DHCP использует поле 'флаги' [21]. Самый левый бит определен как флаг BROADCAST (B). Остающиеся биты поля флаги зарезервированы на будущее. Они должны быть установлены равными нулю клиентами и игнорироваться серверами и агентами транспортировки. На Рисунок 2 показан формат поля флаги.

0   1   2   3   4   5   6   7   8   9   10   11   12   13   14   15
B	MBZ

B: флаг BROADCAST

MBZ: должно быть равно нулю (must be zero; зарезервировано на будущее)

описывает использование полей и опций DHCP-сообщения клиента

Таблица 5 описывает использование полей и опций DHCP-сообщения клиента.

Основные TCP/IP демоны

Таблица 5.2. Основные TCP/IP демоны

Название демона	Назначение
fingerd	Предоставляет информацию об удаленном пользователе
ftpd	Реализует функции сервера передачи файлов (протокол FTP)
gated	Реализует функции маршрутизации шлюза для протоколов RIP, HELLO, EGP, BGP и SNMP
inetd	Реализует управление сетевыми услугами Интернет
named	Реализует услуги сервера имен (DNS)
rexecd	Реализует серверные функции для команд rexec (удаленное исполнение)
rlogind	Реализует серверные функции для команд rlogin (авторизация)
routed	Управляет сетевыми маршрутными таблицами
rshd	Реализует серверные функции для команд удаленного исполнения
rwhod	Реализует серверные функции для команд rwho и ruptime
syslogd	Читает и записывает в журнал сообщения
talkd	Реализует серверные функции для команд talk
telnetd	Реализует серверные функции для протокола TELNET
tftpd	Реализует серверные функции для протокола TFTP
timed	При загрузке системы устанавливает демон timeserver

Конфигурация inetd определяется содержимым файла /etc/inetd.conf. Для ознакомления с содержимым файла достаточно с клавиатуры ввести команду:

head -16 /etc/inetd.conf

# @(#)inetd.conf 1.24 92/04/14 SMI

# Configuration file for inetd(8). See inetd.conf(5).

# To re-configure the running inetd process, edit this file, then

# send the inetd process a SIGHUP.

# Internet services syntax:

# <service_name> <socket_type> <proto> <flags> <user> <server_pathname> <args>

# Ftp and telnet are standard Internet services.

#ftp	stream	tcp	nowait	root	/usr/etc/in.ftpd	in.ftpd
#ftp	stream	tcp	nowait	root	/usr/etc/wrapper.3.9.4/tcpd	in.ftpd -dl

ftp stream tcp nowait root /usr/etc/wrapper.3.9.4/tcpd /usr/local/etc/ftpd -lio

Строки, начинающиеся с символа #, являются комментариями. В данном примере представлена одна информативная строка (их может быть много больше), характеризующая файловый обмен. Каждая строка в этом файле начинается с имени ресурса (в приведенном примере ftp).
Далее следует поле типа соединителя (socket): stream (TCP поток байтов); dgram - передача данных в виде UDP-дейтограмм. Следующее поле характеризует протокол, используемый данным видом сервиса (TCP или UDP). За ним идет поле, которое описывает способ реализации процедуры (wait/nowait; для поточных серверов nowait). Следующее поле представляет собой идентификатор пользователя (UID), но обычно пользователем является системный администратор - root. Встречается два исключения. Процедура finger выполняется с UID=nobody или daemon, а uucp использует реальное имя пользователя. За полем uid следует поле сервера (в примере /usr/etc/wrapper.3.9.4/tcpd /usr/local/etc/ftpd). В это поле заносится полное описание пути к программе-серверу, запускаемой inetd. Завершающим полем является поле аргументы, куда записывается строка, передаваемая программе-серверу. Содержимое файла inetd.conf должно быть предметом особой заботы администратора, так как от содержимого этого файла зависит эффективная работа сети и ее безопасность.
Как уже отмечалось выше, одним из важнейших частей любого узла Интернет является сервер имен (DNS). Конфигурация DNS-сервера определяется тремя файлами: named.boot, named.ca и named.local. Зонная информация содержится в файле named.rev, а данные о локальном домене в файле named.hosts. Отладка, контроль и диагностика DNS-сервера осуществляется с использованием программ nslookup (или dig). Рассмотрим пример использования процедуры nslookup (здесь выполнены запросы по серверам имен, по почтовым серверам и по параметрам зоны ответственности):

Nslookup (запуск сервера)

Default Server: ns.itep.ru

Address: 193.124.224.35

set type=NS (запрос данных о серверах имен)

> > Server: ns.itep.ru

Address: 193.124.224.35

eunet.fi

(определяем имя запрашиваемого узла)

Non-authoritative answer:

eunet.fi	nameserver = ns1.EUNET.FI
eunet.fi	nameserver = ns2.EUNET.FI
eunet.fi	nameserver = ns3.eunet.fi
eunet.fi	nameserver = ns.eu.net
eunet.fi	nameserver = ns0.EUNET.FI

<


Authoritative answers can be found from (официальные данные могут быть получены от):

eunet.fi

nameserver = ns1.EUNET.FI

set type=ANY (запрос всей информации)

..........................................

Non-authoritative answer:

eunet.fi	nameserver = ns1.EUNET.FI
eunet.fi	nameserver = ns2.EUNET.FI
eunet.fi	nameserver = ns3.eunet.fi
eunet.fi	nameserver = ns.eu.net
	origin = ns1.eunet.fi
	mail addr = hostmaster.eunet.fi
	serial = 199607235
	refresh = 28800 (8 hours)
	retry = 7200 (2 hours)
	expire = 604800 (7 days)
	minimum ttl = 86400 (1 day)
eunet.fi	preference = 10, mail exchanger = pim.eunet.fi (Основной почтовый сервер)
eunet.fi	preference = 50, mail exchanger = mail.eunet.fi
eunet.fi	nameserver = ns0.EUNET.FI

Authoritative answers can be found from:

eunet.fi	nameserver = ns1.EUNET.FI
eunet.fi	nameserver = ns2.EUNET.FI
eunet.fi	nameserver = ns3.eunet.fi
eunet.fi	nameserver = ns.eu.net
eunet.fi	nameserver = ns0.EUNET.FI
ns1.EUNET.FI	internet address = 192.26.119.7
ns2.EUNET.FI	internet address = 192.26.119.4
ns3.eunet.fi	internet address = 192.26.119.4
ns.eu.net	internet address = 192.16.202.11
pim.eunet.fi	internet address = 193.66.4.30
mail.eunet.fi	internet address = 192.26.119.7
ns0.EUNET.FI	internet address = 192.26.119.1
set type=MX	(запрос информации о почтовых серверах)

...................................

Non-authoritative answer:

eunet.fi	preference = 50, mail exchanger = mail.eunet.fi	(имена почтовых серверов)
eunet.fi	preference = 10, mail exchanger = pim.eunet.fi

(Параметр preference характеризует степень предпочтения почтового сервера, чем он ниже - тем выше предпочтение.)
Authoritative answers can be found from:

eunet.fi	nameserver = ns1.EUNET.FI
eunet.fi	nameserver = ns2.EUNET.FI
eunet.fi	nameserver = ns3.eunet.fi
eunet.fi	nameserver = ns.eu.net
eunet.fi	nameserver = ns0.EUNET.FI
mail.eunet.fi	internet address = 192.26.119.7
pim.eunet.fi	internet address = 193.66.4.30
ns1.EUNET.FI	internet address = 192.26.119.7
ns2.EUNET.FI	internet address = 192.26.119.4
ns3.eunet.fi	internet address = 192.26.119.4
ns.eu.net	internet address = 192.16.202.11
ns0.EUNET.FI	internet address = 192.26.119.1

<


set type=SOA ( запрос параметров, зоны сервера имен, см. RFC-1034-35)

.......................................

Non-authoritative answer (см. документы RFC-1034-35):

	origin = ns1.eunet.fi
	mail addr = hostmaster.eunet.fi
	serial = 199607235
	refresh = 28800 (8 часов)
	retry = 7200 (2 часа)
	expire = 604800 (7 дней)
	minimum ttl = 86400 (1 день)

Authoritative answers can be found from:

eunet.fi	nameserver = ns1.EUNET.FI
eunet.fi	nameserver = ns2.EUNET.FI
eunet.fi	nameserver = ns3.eunet.fi
eunet.fi	nameserver = ns.eu.net
eunet.fi	nameserver = ns0.EUNET.FI
ns1.EUNET.FI	internet address = 192.26.119.7
ns2.EUNET.FI	internet address = 192.26.119.4
ns3.eunet.fi	internet address = 192.26.119.4
ns.eu.net	internet address = 192.16.202.11
ns0.EUNET.FI	internet address = 192.26.119.1
>exit	(команда выхода из nslookup)

Рассмотренный пример показывает, что DNS-сервер весьма важный объект узла, от него зависит скорость обслуживания запросов и надежность системы в целом. Именно по этой причине помимо основного любой узел имеет несколько вторичных DNS-серверов.
Программа dig функционально является аналогом nslookup, но в прикладном плане имеет определенные отличия, она снабжена рядом полезных опций (таблица 5.3):

Поля и опции, используемые DHCP-серверами

Таблица 3. Поля и опции, используемые DHCP-серверами

Поле	DHCPOFFER	DHCPACK	DHCPNAK
'op'	BOOTREPLY	BOOTREPLY	BOOTREPLY
'htype'	Из RFC "Assigned Numbers"
'hlen'	Длина аппаратного адреса в октетах
'hops'	0	0	0
'xid'	'xid' из сообщения клиента DHCPDISCOVER	'xid' из сообщения клиента DHCPREQUEST	'xid' из сообщения клиента DHCPREQUEST
'secs'	0	0	0
'ciaddr'	0	'ciaddr' из DHCPREQUEST или 0	0
'yiaddr'	IP-адрес предложенный клиенту	IP-адрес присвоенный клиенту	0
'siaddr'	IP-адрес следующего сервера загрузки	IP-адрес следующего сервера загрузки	0
'flags'	'flags' из сообщения клиента DHCPDISCOVER	флаги' из сообщения клиента DHCPREQUEST	'flags' из сообщения клиента DHCPREQUEST
'giaddr'	'giaddr' из сообщения клиента DHCPDISCOVER	'giaddr' из сообщения клиента DHCPREQUEST	'giaddr' >из сообщения клиента DHCPREQUEST
'chaddr'	'chaddr' из сообщения клиента DHCPDISCOVER	'chaddr' из сообщения клиента DHCPREQUEST	'chaddr' из сообщения клиента DHCPREQUEST
'sname'	Имя ЭВМ сервера или опции	Имя ЭВМ сервера или опции	(не используется)
'файл'	Файл загруз. клиента имя или опции	Файл загруз. клиента имя или опции	(не используется)
'опции'	опции	опции

Опция	DHCPOFFER	DHCPACK	DHCPNAK
Запрошенный IP-адрес	не должен	не должен	не должен
IP-адрес lease time	должен	должен (DHCPREQUEST) не должен (DHCPINFORM)		не должен
Использование полей 'файл'/'sname'	может	может	не должен
Тип сообщения DHCP	DHCPOFFER	DHCPACKDHCPNAK
Список параметров	не должен	не должен	не должен
Сообщение	должен	должен	должен
Идентификатор клиента	не должен	не должен	может
Идентификатор Vendor class	может	может	может
Идентификатор сервера	должен	должен	должен
Макс. размер сообщения	не должен	не должен	не должен
Все прочие	может	может	не должен

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

o	Сетевой адрес клиента, как это определено правилами приведенными выше,
o	Время действия клиентского набора, как это определено правилами из данного раздела,
o	Параметры, запрошенные клиентом, согласно следующим правилам:
	- Если в сервере явно задано значение параметра по умолчанию, сервер должен включить это значение в соответствующую опцию поля 'option', в противном случае
	- Если сервер распознает параметр, как параметр, определенный в документе Host Requirements, сервер должен включить его значение по умолчанию (как это рекомендуется в документе Host Requirements), в соответствующую опцию в поле 'option', в противном случае
	- Сервер не должен присылать значение этого параметра

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

o	Любые параметры из существующего набора, которые отличаются от значений по умолчанию документа Host Requirements,
o	Любые параметры, специфичные для клиента (как это с пецифицировано в содержимом 'chaddr' или 'client identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором,
o	Любые параметры специфичные для этого класса клиента (как это идентифицировано в опции 'vendor class identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором;
o	Параметры со значениями, неравными величинам по умолчанию для клиентской субсети.

<


Сервер может прислать 'vendor class identifier', использованный чтобы определить параметры в сообщении DHCPOFFER, чтобы помочь клиенту решить, какой выбрать DHCPOFFER. Сервер вводит поле 'xid' из сообщения DHCPDISCOVER в поле 'xid' сообщения DHCPOFFER и посылает клиенту, приславшему запрос, сообщение DHCPOFFER.

4.3.2. Сообщение DHCPREQUEST

Сообщение DHCPREQUEST может прийти от клиента, реагирующего на сообщение сервера DHCPOFFER, от клиента, верифицирующего ранее выделенный IP-адрес, или от клиента, расширяющего время действия конфигурационного набора. Если сообщение DHCPREQUEST содержит опцию 'server identifier', то это отклик на сообщение DHCPOFFER. В противном случае, сообщение является запросом верификации или расширения времени действия набора. Если клиент использует 'client identifier' в сообщении DHCPREQUEST, он должен использовать его во всех последующих сообщениях. Если клиент включил список запрашиваемых параметров в сообщение DHCPDISCOVER, он должен включить этот список во все последующие сообщения. Любые конфигурационные параметры в сообщении DHCPACK не должны конфликтовать с полученными ранее в сообщении DHCPOFFER. Клиент должен использовать для конфигурации параметры из сообщения DHCPACK. Клиенты посылают сообщения DHCPREQUEST следующим образом:
o DHCPREQUEST, сформированный в состоянии SELECTING:
Клиент вводит адрес выбранного сервера 'server identifier', 'ciaddr' должен быть равен нулю, в ‘запрошенный IP-адрес' должно быть записано значение yiaddr, взятое из DHCPOFFER.
Заметим, что клиент может собрать несколько сообщений DHCPOFFER и выбрать наилучшее предложение. Клиент определяет свой выбор путем идентификации сервера в сообщении DHCPREQUEST. Если клиент получает неприемлемые предложения, клиент может попробовать другое сообщение DHCPDISCOVER. Следовательно, серверы не могут получить DHCPREQUEST, из которого они могли бы решить, принял ли клиент данное предложение. Так как серверы не осуществили присвоение какого-либо сетевого адреса на основе DHCPOFFER, они вольны повторно использовать предложенные сетевые адреса в откликах на последующие запросы.


Серверы не должны повторно использовать предложенные адреса и могут реализовать зависимый от реализации механизм таймаутов в процессе принятия решения о повторном использовании предложенных адресов.
o DHCPREQUEST генерируется в состоянии INIT-REBOOT:
Поле 'server identifier' не должно быть заполнено, в опции 'Запрошенный IP-адрес' должен быть записан предшествующий адрес, присвоенный клиенту. 'ciaddr' должен быть равен нулю. Клиент пытается верифицировать присвоенный ранее конфигурационный набор. Сервер должен клиенту послать сообщение DHCPNAK, если ‘запрошенный IP-адрес’ не корректен, или относится к неверной сети.
Определение того, находится ли клиент в состоянии INIT-REBOOT, осуществляется просмотром содержимого 'giaddr', опции 'requested IP-адрес', и базы данных. Если DHCP-сервер обнаружит, что клиент находится не в той сети (т.e., результат наложения локальной маски субсети или маски удаленной субсети (если 'giaddr' не равно нулю) на опцию 'запрошенный IP-адрес' выдает не реальный результат), тогда сервер должен послать клиенту сообщение DHCPNAK. Если с сетью все в порядке, тогда DHCP-сервер должен проверить, корректна ли запись клиента о его IP-адресе. Если нет, сервер должен послать клиенту сообщение DHCPNAK. Если DHCP-сервер не имеет записи об этом клиенте, тогда он должен оставаться пассивным, и может выдать предупреждение сетевому администратору.
Если 'giaddr' в сообщении DHCPREQUEST равен 0x0, клиент находится в той же субсети, что и сервер. Сервер должен широковещательно послать сообщение DHCPNAK по адресу 0xffffffff, так как клиент не может иметь корректный сетевой адрес или сетевую маску, и клиент не может откликаться на ARP-запросы.
Если в сообщении DHCPREQUEST установлен 'giaddr', клиент находится в другой субсети. Сервер должен установить широковещательный бит в DHCPNAK, агент отклика пошлет клиенту сообщение DHCPNAK широковещательно, так как клиент может не иметь корректного сетевого адреса или сетевой маски, и клиент может не откликаться на ARP-запросы.


o DHCPREQUEST генерируется в состоянии RENEWING:
' server identifier' не должен быть заполнен, опция 'запрошенный IP-адрес' не должна быть заполнена, в 'ciaddr' должен быть записан IP-адрес клиента. В этой ситуации, клиент полностью сконфигурирован, и пытается расширить срок действия конфигурационного набора. Это сообщение будет послано по уникастному адресу, таким образом, в обмен не будет вовлечено никаких агентов транспортировки. Так как 'giaddr' не заполнен, DHCP-сервер будет полагаться на значениеn 'ciaddr', и использовать его при передаче данных клиенту.
Клиент может пожелать обновить или расширить время действия конфигурационного набора до T1. Сервер может пожелать не расширять время действия (например, по решению сетевого администратора), но должен в любом случае откликнуться сообщением DHCPACK.
o DHCPREQUEST генерируется в состоянии REBINDING:
'server identifier' не должен быть заполнен, опция 'запрошенный IP-адрес' не должна быть заполнена, в 'ciaddr' должен быть записан IP-адрес клиента. В этой ситуации, клиент полностью сконфигурирован, и пытается увеличить время действия набора параметров. Это сообщение должно быть передано широковещательно по IP-адресу 0xffffffff. DHCP-сервер должен проверить корректность 'ciaddr' прежде чем откликаться на DHCPREQUEST. DHCPREQUEST от клиента в состоянии REBINDING имеет целью согласовать узлы, имеющие несколько DHCP-серверов, а также предложить механизм для согласования времен действия конфигурационных наборов, предлагаемых разными серверами. DHCP-сервер может расширить время действия набора параметров клиента, только если он имеет для этого административные привилегии.

4.3.3. Сообщение DHCPDECLINE

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

4.3.4. Сообщение DHCPRELEASE

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

4.3.5. Сообщение DHCPINFORM

Сервер реагирует на сообщение DHCPINFORM посылкой сообщения DHCPACK непосредственно по адресу, записанному в поле 'ciaddr' сообщения DHCPINFORM. Сервер не должен уведомлять клиента об истечении времени действия конфигурационного набора и не должен производить запись в 'yiaddr'. Сервер включает в сообщение DHCPACK другие параметры, как это определено в разделе 4.3.1.

4.3.6. Сообщения клиента

Поля и опции, используемые клиентами DHCP

Таблица 5. Поля и опции, используемые клиентами DHCP

Поле	DHCPDISCOVER DHCPINFORM	DHCPREQUEST	DHCPDECLINE, DHCPRELEASE
'op'	BOOTREQUEST	BOOTREQUEST	BOOTREQUEST
'htype'	Из RFC"Assigned Numbers"
'hlen'	Длина аппаратного адреса в октетах
'шаги'	0	0	0
'xid'	выбрано клиентом	'xid' из сообщения сервера DHCPOFFER	выбрано клиентом
'secs'	0 или число сек с момента, когда HCP-процесс запущен	0 или число сек со времени, когдаDHCP- процесс запущен	0
'флаги'	Устанавливает 'BROADCAST'-флаг, если клиент требует широковещательного отклика	Устанавливает 'BROADCAST' флаг, если клиент требует широковещательного отклика	0
'ciaddr'	0 (DHCPDISCOVER) сетевой адрес клиента(DHCPINFORM)	0 или сетевой адрес клиента (BOUND/RENEW/REBIND)	0 (DHCPDECLINE) сетевой адрес клиента (DHCPRELEASE)
'yiaddr'	0	0	0
'siaddr'	0	0	0
'giaddr'	0	0	0
'chaddr'	аппаратный адрес клиента	аппаратный адрес клиента	аппаратный адрес клиента
'sname'	опции, если указано в 'sname/file' опция; иначе не используется	опции, если указано в 'sname/file' опция; иначе не используется	(не используется)
'файл'	опции, если указано в 'sname/file' опция; иначе не используется	опции, если указано в 'sname/file' опция; иначе не используется	(не используется)
'опции'	опции	опции	(не используется)

Опция	DHCPDISCOVER DHCPINFORM	DHCPREQUEST	DHCPDECLINE, DHCPRELEASE
Requested IP-address	Может (DISCOVER) не должен (INFORM)	Должен (в SELECTING или INIT-REBOOT) не должен (в BOUND или RENEWING)	Должен (DHCPDECLINE), не должен (DHCPRELEASE)
IP-address lease time	Может (DISCOVER) не должен (INFORM)	Может	Не должен
Использование полей 'file'/'sname'	Может	Может	Может
Тип сообщения DHCP	DHCPDISCOVER/ DHCPINFORM	DHCPREQUEST	DHCPDECLINE/ DHCPRELEASE
Идентификатор клиента	Может	Может	Может
Vendor class identifier	Может	Может	Не должен
Идентификатор сервера	Не должен	Должен (после SELECTING) Не должен (после INIT-REBOOT, BOUND, RENEWING или REBINDING)	Должен
Parameter request list	Может	Может	Не должен
Maximum message size	Может	Может	Не должен
Message	Не следует	Не следует	Следует
Site-specific	Может	Может	Не должен
Прочие	Может	Может	Не должен

<
Если параметры приемлемы, клиент записывает адрес сервера, который предоставляет параметры из поля 'server identifier' и посылает этот адрес в поле 'server identifier' широковещательного сообщения DHCPREQUEST. Раз от сервера пришло сообщение DHCPACK, клиент инициализирован и переходит в состояние BOUND. Сообщение DHCPREQUEST содержит тот же 'xid' что и сообщение DHCPOFFER. Клиент записывает время истечения действия конфигурационного набора как сумму времени, когда был послан исходный запрос и длительности действия конфигурационного набора из сообщения DHCPACK. Клиент должен выполнить проверку предложенного адреса, чтобы убедиться, что адрес не используется. Например, если клиент находится в сети, которая поддерживает ARP, клиент может послать запрос ARP для предложенного адреса. При посылке широковещательного ARP-запроса для предлагаемого адреса, клиент должен записать туда, как отправитель, свой аппаратный адрес, и 0 в качестве IP-адреса отправителя, чтобы исключить конфликт с ARP-кэшами в других ЭВМ той же субсети. Если оказалось, что сетевой адрес используется, клиент должен послать серверу сообщение DHCPDECLINE. Клиент должен широковещательно послать ARP-отклик, чтобы уведомить о новом IP-адресе клиента и удалить устаревшие записи из ARP-кэша ЭВМ, размещенных в той же субсети.

4.4.2. Инициализация при известном сетевом адресе

Клиент начинает работу в состоянии INIT-REBOOT и посылает сообщение DHCPREQUEST. Клиент должен вставить свой сетевой адрес в опцию 'requested IP-адрес' сообщения DHCPREQUEST. Клиент может запросить специфические конфигурационные параметры, включив опцию 'parameter request list'. Клиент генерирует и записывает случайный идентификатор транзакции и заносит этот идентификатор в поле 'xid'. Клиент записывает свое локальное время для последующего использования при вычислении времени истечения пригодности конфигурационного набора параметров. Клиент не должен включать 'server identifier' в сообщение DHCPREQUEST. Клиент затем широковещательно посылает DHCP-серверу сообщение DHCPREQUEST с использованием аппаратного широковещательного адреса и UDP-порта.


Раз от какого- то сервера пришло сообщение DHCPACK с полем 'xid' согласующимся с тем, которое содержится в сообщении клиента DHCPREQUEST, клиент инициализирован и он переходит в состояние BOUND. Клиент записывает время истечения годности конфигурационного набора параметров, которое равно сумме времени, когда было послано сообщение DHCPREQUEST и длительности пригодности конфигурационного набора, взятого из сообщения DHCPACK.

4.4.3. Инициализация при сетевом адресе заданном извне

Клиент посылает сообщение DHCPINFORM, клиент может запросить специфические конфигурационные параметры путем включения их в опцию 'parameter request list'. Клиент генерирует и записывает случайный идентификатор транзакции и вводит его в поле 'xid'. Клиент помещает свой сетевой адрес в поле 'ciaddr'. Клиенту не следует запрашивать параметры времени действия конфигурационного набора.
Клиент посылает уникастное сообщение DHCPINFORM DHCP-серверу, если он знает адрес сервера, в противном случае он посылает это сообщение широковещательно. Сообщения DHCPINFORM должны быть направлены 'DHCP-серверу ' через UDP-порт.
Раз от любого из серверов получено сообщение DHCPACK с полем 'xid', согласующимся с тем, что содержалось в сообщении клиента DHCPINFORM, клиент инициализирован.
Если клиент не получил DHCPACK в пределах разумного временного интервала (60 секунд или 4 попыток, если используется таймауты, предложенные в разделе 4.1), тогда клиент должен выдать сообщение пользователю, уведомляющее его о возникшей проблеме, а затем продолжить сетевую активность, используя разумные значения по умолчанию из приложения A.

4.4.4. Использование широковещательной и уникастной адресации

DHCP-клиент широковещательно посылает сообщения DHCPDISCOVER, DHCPREQUEST и DHCPINFORM, если только клиент не знает адреса DHCP-сервера. Клиент посылает сообщения DHCPRELEASE серверу уникастно. Так как клиент отказывается использовать IP-адрес, предоставленный сервером, он посылает сообщения DHCPDECLINE широковещательно.
Когда DHCP-клиент знает адрес DHCP-сервера, в состоянии INIT или REBOOTING, клиент может использовать адрес, записанный в DHCPDISCOVER или DHCPREQUEST, а не широковещательный IP-адрес.


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

4.4.5. Восстановление и истечение пригодности

Клиент поддерживает две временные переменные, T1 и T2, которые специфицируют времена, когда клиент пытается расширить время действия своего сетевого адреса. T1 равно времени, когда клиент попадает в состояние RENEWING и пытается контактировать с сервером, который предоставил клиенту сетевой адрес. T2 равно времени, когда клиент перешел в состояние REBINDING и пытается контактировать с каким-то сервером. T1 должно быть раньше T2, которое в свою очередь, должно быть раньше, чем время, когда истекает период годности конфигурационного набора параметров.
Чтобы исключить необходимость синхронизации часов, T1 и T2 выражаются в опциях в относительных единицах [2].
В момент T1 клиент переходит в состояние RENEWING и посылает серверу (уникастно) сообщение DHCPREQUEST с тем, чтобы продлить действие набора конфигурационных параметров. Клиент устанавливает поле 'ciaddr' в DHCPREQUEST равным его текущему сетевому адресу. Клиент записывает локальное время, когда было послано сообщение DHCPREQUEST. Клиент не должен включать идентификатор сервера в сообщение DHCPREQUEST.
Любые сообщения DHCPACK, которые приходят с 'xid', не согласующимся с ‘xid' из сообщения клиента DHCPREQUEST, игнорируются. Когда клиент получает от сервера DHCPACK, он вычисляет время истечения пригодности конфигурационного набора параметров (равно сумме времени, когда клиент посылал сообщение DHCPREQUEST и длительности пригодности конфигурационного набора параметров из сообщения DHCPACK). Клиент успешно восстанавливает свой сетевой адрес, возвращается в состояние BOUND и может продолжить свою сетевую активность.
Если не приходит никакого DHCPACK до T2, клиент переходит в состояние REBINDING и посылает широковещательно сообщение DHCPREQUEST с целью расширения времени действия конфигурационного набора.


Клиент устанавливает поле 'ciaddr' в DHCPREQUEST равным его текущему сетевому адресу. Клиент не должен включать 'server identifier' в сообщение DHCPREQUEST.
Времена T1 и T2 конфигурируются сервером посредством опций. T1 по умолчанию равно (0.5 * duration_of_lease). T2 по умолчанию равно (0.875 * duration_of_lease). Чтобы исключить синхронизацию восстановления состояния клиентов, времена T1 и T2 должны быть выбраны с некоторым случайным разбросом относительно фиксированных значений.
Клиент может решить обновить или продлить время действия конфигурационного набора вплоть до T1. Сервер может решить расширить длительность пригодности конфигурационного набора параметров в соответствии с политикой сетевого администратора.
Как в состоянии RENEWING, так и в REBINDING, если клиент не получает отклика на свое сообщение DHCPREQUEST. Клиент должен ждать половину остающегося времени вплоть до T2 (в состоянии RENEWING) и половину остающегося времени действия конфигурационного набора (в состоянии REBINDING), как минимум 60 секунд, прежде чем осуществить повторную отправку сообщения DHCPREQUEST.
Если время действия конфигурационного набора иссякло, клиент получает DHCPACK, переходит в состояние INIT, должен остановить всякую сетевую активность и запросить инициализацию параметров. Если клиент получает затем DHCPACK, присваивающее клиенту его предыдущий сетевой адрес, клиенту следует продолжить сетевые операции. Если клиенту дали новый сетевой адрес, он не должен использовать предыдущий и ему следует уведомить локальных пользователей о возникшей проблеме.

4.4.6. Сообщение DHCPRELEASE

Если клиент более не нуждается в использовании своего сетевого адреса (например, клиент завершил работу через shutdown), клиент посылает серверу сообщение DHCPRELEASE. Заметим, что корректная работа DHCP не зависит от передачи сообщений DHCPRELEASE.

Разновидности полей тип запроса и их коды

Таблица 4.4.12.3.. Разновидности полей тип запроса и их коды

Тип запроса	Код запроса	Описание
A	1	IP-адрес
NS	2	Сервер имен.
CNAME	5	Каноническое имя.
SOA	6	Начало списка серверов. Большое число полей, определяющих часть иерархии имен, которую использует сервер.
MB	7	Имя домена почтового ящика.
WKS	11	well-known service - стандартная услуга.
PTR	12	Запись указателя.
HINFO	13	Информация об ЭВМ.
MINFO	14	Информация о почтовом ящике или списке почтовых адресов.
MX	15	Запись о почтовом сервере.
TXT	16	Не интерпретируемая строка ASCII символов.
AXFR	252	Запрос зонного обмена
* или ANY	255	Запрос всех записей.

(Пропущенные коды являются устаревшими или экспериментальными).

Последние две строки в таблице 4.4.12.3 относятся только к вопросам. Поле класс запроса позволяет использовать имена доменов для произвольных объектов (все официальные имена Интернет относятся к одному классу [IN] - 1). В сообщении DNS-сервера каждая из секций (дополнительной информации, ответов или узловых серверов имен) состоит из набора ресурсных записей, которые описывают имена доменов и некоторую другую информацию (например, их адреса). Появление ресурсных полей в DNS базе данных придают ей новые качества. Каждая запись описывает только одно имя, формат этих записей отображен на Рисунок 4.4.12.6.

Разновидности субполей и их коды (BOOTP)

Таблица 4.4.10.1 Разновидности субполей и их коды (BOOTP)

Тип субполя	Код субполя	Длина субполя в октетах	Содержимое субполя
Заполнитель	0	-	Нули - используются для заполнения неиспользуемых полей
Маска субсети	1	4	Маска субсети в локальной сети
Время дня	2	4	Время дня по универсальной шкале
Маршрутизаторы	3	N	Список IP-адресов N/4 маршрутизаторов
Временные серверы	4	N	IP-адреса N/4 временных серверов
IEN116 сервер	5	N	IP-адреса N/4 IEN116 серверов
Домейн-сервер	6	N	IP-адреса N/4 DNS-серверов
Log-сервер	7	N	IP-адреса N/4 log-серверов
Сервер квот	8	N	IP-адреса N/4 серверов квот
Сервер принтера	9	N	IP-адреса N/4 серверов печати
Impress	10	N	IP-адреса N/4 impress-серверов
RLP-сервер	11	N	IP-адреса N/4 RLP серверов
Имя ЭВМ	12	N	N байтов имени ЭВМ-клиента
Размер Boot-файла	13	2	2-октетный размер boot-файла
Зарезервировано	128-254	-	Зарезервировано для местного применения
Конец	255	-	Конец списка

Определены и другие субполя (RFC-1533), субполе конец (255) помечает конец поля. Хотя маска субсети может быть получена с помощью ICMP-запроса, стандарт требует, чтобы маска присылалась BOOT-сервером в ответ на каждый запрос, что исключает лишние ICMP-сообщения. Маска субсети может быть записана в поле специфическая информация поставщика, как это видно из таблицы. Время дня (тип=2) отсчитывается в секундах от 1-го января 1900 года. В новом протоколе DHCP (Dynamic Host Configuration Protocol, RFC-1531, протокол динамического конфигурирования системы) размер поля специфическая информация поставщика расширен до 312 байт.

Сообщения DHCP

Таблица 2: Сообщения DHCP

Сообщение	Использование
DHCPDISCOVER	Клиент посылает сообщение широковещательно, чтобы обнаружить доступный сервер.
DHCPOFFER	Посылается сервером клиенту в ответ на сообщение DHCPDISCOVER и содержит предложение по конфигурационным параметрам.
DHCPREQUEST	Сообщение клиента серверу либо (a) запрашивающее параметры от одного сервера и неявно отвергающее предложения других серверов, (b) подтверждающее корректность ранее присвоенного адреса после, например, перезагрузки системы, или (c) запрос расширения времени жизни конкретного сетевого адреса.
DHCPACK	Посылается сервером клиенту и содержит конфигурационные параметры, включая присвоенный сетевой адрес.
DHCPNAK	Посылается сервером клиенту, сообщая о том, что сетевой адрес не корректен (например, клиент переместился в новую субсеть), или время использования адреса клиентом истекло
DHCPDECLINE	Клиент и сервер обнаружили, что сетевой адрес уже используется.
DHCPRELEASE	Посылается клиентом серверу с целью отказа от сетевого адреса и аннулирует оставшееся время действия адреса.
DHCPINFORM	Посылается клиентом серверу с просьбой о локальных конфигурационных параметрах; клиент уже имеет полученный извне сетевой адрес.

Сообщения клиента для различных состояний

Таблица 4. Сообщения клиента для различных состояний

	INIT-REBOOT	SELECTING	RENEWING	REBINDING
broad/unicast	Широковещ.	Широковещ	Уникастный	Широковещ
server-ip	Не должен	Должен	Не должен	Не должен
Запрошенный IP	Должен	Должен	Не должен	Не должен
ciaddr	нуль	нуль	IP адрес	IP адрес

4.4. Поведение клиента DHCP

На Рисунок 5 представлена диаграмма состояний для DHCP-клиента. Клиент может получить следующие сообщения от сервера:

o DHCPOFFER

o DHCPACK

o DHCPNAK

Сообщение DHCPINFORM не показано на Рисунок 5. Клиент просто посылает DHCPINFORM и ждет сообщения-отклика DHCPACK. Раз клиент выбрал свои параметры, он завершил процесс конфигурации.

Стандартизованные суффиксы имен

Таблица 4.4.12.1. Стандартизованные суффиксы имен

Поле адреса	Тип сети
.com	Коммерческая организация;
.gov	Государственное учреждение (США);
.org	Бесприбыльная организация;
.edu	Учебное заведение;
.mil	Военное предприятие или организация (США);
.net	Большая сеть;
.int	Международная организация;
.arpa	Специальный домен, используемый для преобразования ip-адреса в имя

Секции .mil и .gov принадлежат исключительно американским сетям (хотя и многие другие трех-символьные секции адреса, например .edu, чаще, но не всегда, принадлежат американским университетам и другим учебным организациям). Структура имен обычно отражает структуру организации, которой принадлежат сети или ЭВМ, но не архитектуру сети в этой организации. Так имя itep.ru - это имя домена itepnet (Институт Теоретической и Экспериментальной физики, Москва). cl.itep.ru - имя mvax-кластера в ИТЭФ, vxitep.itep.ru - имя vax-кластера, а suncom.itep.ru - имя одной из ЭВМ SUN в той же сети. По имени, как правило, нельзя определить является ли оно именем сети, маршрутизатора или конкретной ЭВМ. Для записи символьных имен используется исключительно латинский алфавит.

Маленький фрагмент интернетовской иерархии имен показан на Рисунок 4.4.12.2. Число уровней реально больше, но обычно не превышает 5.

Субкоды ошибок

Таблица 4.4.11.4.2 Субкоды ошибок

Ошибка	Субкод	Описание
Заголовок	1 2 3	Соединение не синхронизовано Неверная длина сообщения Неверный тип сообщения
Сообщения OPEN	1 2 3 4 5 6	Неверный код версии Ошибочный код as-партнера Ошибочный идентификатор BGP Ошибка в коде идентификации Ошибка при идентификации Неприемлемое время сохранения
Сообщения UPDATE	1 2 3 4 5 6 7 8 9 10 11	Ошибка в списке атрибутов Не узнан стандартный атрибут Отсутствует стандартный атрибут Ошибка в флагах атрибута Ошибка в длине атрибута Неправильный атрибут origin Циклический маршрут Ошибка в атрибуте next_hop Ошибка в опционном атрибуте Ошибка в сетевом поле Ошибка в as_path

Вся маршрутная информация хранится в специальной базе данных RIB (routing information base). Маршрутная база данных BGP состоит из трех частей:

1.	ADJ-RIBS-IN:	Запоминает маршрутную информацию, которая получена из update-сообщений. Это список маршрутов, из которого можно выбирать. (policy information base - PIB).
2.	LOC-RIB:	Содержит локальную маршрутную информацию, которую BGP-маршрутизатор отобрал, руководствуясь маршрутной политикой, из ADJ-RIBS-IN.
3.	ADJ-RIBS-OUT:	Содержит информацию, которую локальный BGP-маршрутизатор отобрал для рассылки соседям с помощью UPDATE-сообщений.

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

Протокол BGP позволяет реализовать маршрутную политику, определяемую администратором AS (см. раздел "Автономные системы и маршрутная политика"). Политика отражается в конфигурационных файлах BGP. Маршрутная политика это не часть протокола, она определяет решения, когда место назначения достижимо несколькими путями, политика отражает соображения безопасности, экономические интересы и пр.
Количество сетей в пределах одной AS не лимитировано. Один маршрутизатор на много сетей позволяет минимизировать таблицу маршрутов.
BGP использует три таймера:

Connectretry (сбрасывается при инициализации и коррекции; 120 сек),

Holdtime (запускается при получении команд Update или Keepalive; 90сек) и

keepalive (запускается при посылке сообщения Keepalive; 30сек).
BGP отличается от RIP и OSPF тем, что использует TCP в качестве транспортного протокола. Две системы, использующие BGP, связываются друг с другом и пересылают посредством TCP полные таблицы маршрутизации. В дальнейшем обмен идет только в случае каких-то изменений. ЭВМ, использующая BGP, не обязательно является маршрутизатором. Сообщения обрабатываются только после того, как они полностью получены.
BGP является протоколом, ориентирующимся на вектор расстояния. Вектор описывается списком AS по 16 бит на AS. BGP регулярно (каждые 30сек) посылает соседям TCP-сообщения, подтверждающие, что узел жив (это не тоже самое что "Keepalive" функция в TCP). Если два BGP-маршрутизатора попытаются установить связь друг с другом одновременно, такие две связи могут быть установлены. Такая ситуация называется столкновением, одна из связей должна быть ликвидирована. При установлении связи маршрутизаторов сначала делается попытка реализовать высший из протоколов (например, BGP-4), если один из них не поддерживает эту версию, номер версии понижается.
Протокол BGP-4 является усовершенствованной версией (по сравнению с BGP-3). Эта версия позволяет пересылать информацию о маршруте в рамках одного IP-пакета. Концепция классов сетей и субсети находятся вне рамок этой версии. Для того чтобы приспособиться к этому, изменена семантика и кодирование атрибута AS_PASS. Введен новый атрибут LOCAL_PREF (степень предпочтительности маршрута для собственной AS), который упрощает процедуру выбора маршрута. Атрибут INTER_AS_METRICSпереименован в MULTI_EXIT_DISC (4 октета; служит для выбора пути к одному из соседей). Введены новые атрибуты ATOMIC_AGGREGATE и AGGREGATOR, которые позволяют группировать маршруты.


Структура данных отражается и на схеме принятия решения, которая имеет три фазы:
Вычисление степени предпочтения для каждого маршрута, полученного от соседней AS, и передача информации другим узлам местной AS.
Выбор лучшего маршрута из наличного числа для каждой точки назначения и укладка результата в LOC-RIB.
Рассылка информации из loc_rib всем соседним AS согласно политике, заложенной в RIB. Группировка маршрутов и редактирование маршрутной информации.
Бесклассовая интердоменная маршрутизация (CIDR- classless interdomain routing, RFC-1520, -1519) – способ избежать того, чтобы каждая С-сеть требовала свою таблицу маршрутизации. Основополагающий принцип CIDR заключается в группировке (агрегатировании) IP-адресов таким образом, чтобы сократить число входов в таблицах маршрутизации (RFC-1519, RFC-1518, RFC-1467, RFC-1466). Протокол совместим с RIP-2, OSPF и BGP-4. Основу протокола составляет идея бесклассовых адресов, где нет деления между полем сети и полем ЭВМ. Дополнительная информация, например 32-разрядная маска, выделяющая поле адреса сети, передается в рамках протокола маршрутизации. При этом выдерживается строгая иерархия адресов: провайдер > предприятие > отдел/здание > сегмент локальной сети. Групповой (агрегатный) адрес воспринимается маршрутизатором как один адрес. Группу может образовывать только непрерывная последовательность IP-адресов. Такой бесклассовый интернетовский адрес часто называется IP-префиксом. Так адрес 192.1.1.0/24 означает диапазон адресов 192.1.1.0 - 192.1.1.255, а адрес 192.1.128.0/17 описывает диапазон 192.1.128.0 - 192.1.255.255, таким образом, число, следующее после косой черты, задает количество двоичных разрядов префикса. Это представление используется при описании политики маршрутизации и самих маршрутов (см. разд.4.4.11.4 – "Маршрутная политика"). Для приведенных примеров это в терминах масок выглядит следующим образом:

Значения TTL для различных приложений

Таблица 4.4.9.4.1. Значения TTL для различных приложений

Вид мультикастинг-туннеля	TTL	Порог
IETF канал 1 GSM-аудио (~18кб/с)	255	224
IETF канал 2 GSM-аудио	223	192
IETF канал 1 видео	127	96
IETF канал 2 видео	95	64
Местное аудио	63	32
Местное видео	31	1

Мультикастинг-дейтограмма с исходным TTL=64 доступна для достаточно обширной области, а мультикастинг-дейтограмма с исходным TTL=128 доступна для целого континента, дейтограмма же с исходным TTL=255 дойдет до любой точки сети Интернет. Понятия "узкий регион" и "обширная область" достаточно неопределенные и будут уточняться позднее.

Маршрутные сообщения, посылаемые конкретному физическому интерфейсу, также как и запросы подтверждения членства в мультикастинг-группе должны иметь TTL=1. Цикл обмена маршрутной информацией между мультикастинг- маршрутизаторами (FULL_UPDATE_RATE) равен 60 сек. Подтверждение членства в группе должно посылаться каждые 120 сек (QUERY_RATE). Если подтверждение не получено в течение 2*QUERY_RATE+20 секунд, то членство в данной группе аннулируется. Соседний мультикастинг-маршрутизатор считается работающим при отсутствии подтверждений (UPDATE-сообщений) в течение 4*FULL_UPDATE_RATE.

Описанные выше протоколы DVMRP и MOSPF имеют общий недостаток - широко используют широковещательные режимы рассылки пакетов и требуют каналов с высокой пропускной способностью. Они удобны для компактных групп (например, все члены группа находятся в пределах одной автономной системы). Для обслуживания более широких групп предложен протокол PIM.

Топология сети DQDB

Рисунок 4.1.9.3. Топология сети DQDB

Каждый из узлов подключен к обеим шинам. По каждой из шин всегда циркулирует фиксированное число контейнеров. Содержимое контейнеров может передаваться с одной шины на другую. В сети DQDB используются следующие типы сегментов:

одиночный сегмент (не нужно никакой сегментации);

первый сегмент (первая ячейка сегментированного МАС-кадра);

промежуточный сегмент фрагментируемого mac-кадра;

последний сегмент (последняя ячейка сегментированного МАС-кадра)

Поле MID остается идентичным для всех DQDB ячеек сегментированного МАС-кадра. Поле ACF содержит биты busy и request, которые используются в рамках механизма qpsx. Бит busy=1 указывает на то, что ячейка занята. Бит request=1 устанавливается узлом, который ждет возможности начать передачу. В каждом узле имеется счетчик запросов RC(request counter), который фиксирует число узлов, ожидающих передачи и стоящих в очереди впереди данного узла. Содержимое счетчика увеличивается всякий раз, когда по шине А проходит контейнер с битом busy=1. Счетчик декрементируется при появлении на шине Б контейнера со свободным битом request. Когда станция сама намеривается передать кадр, содержимое RC переносится в реверсивный счетчик DC, а в регистр RC заносится нуль. Код в DC уменьшается на единицу при получении контейнера с битом busy=1. DC определяет положение запроса в очереди (нуль соответствует началу очереди). Если получен контейнер с request=0 и DC=0, узел может передать ячейку по данной шине. Каждый узел может осуществлять передачу и прием по любой из шин А и Б. В сети DQDB предусмотрено 4 уровня приоритетов и каждый узел поддерживает до 5 очередей с RC и DC счетчиками для каждой из очередей. Для индикации приоритета в поле ACF предусмотрено 4 двоичных разряда (R1, R2, R3 и R4). Высшему приоритету соответствует R4. Схема сегментирования MAC-кадра при передаче с помощью DQDB ячеек показана на Рисунок 4.1.9.4.

Вариации tcpinsegs и udpindatagrams в течение недели

Рисунок 4.1.2. Вариации tcpinsegs и udpindatagrams в течение недели

Для защищенных систем доступ к snmp-резиденту в пакетах должно использоваться поле community = паролю. Но даже эта мера не может блокировать вторжение со стороны LAN, так как в результате перехвата snmp-пакетов пароль может быть открыт. При написании таких программ нужно учитывать версии MIB, используемые анализируемыми узлами, а также тот факт, что snmp-отклики могут иметь для разных операционных сред. Рассмотрим, как варьируются некоторые из перечисленных переменных в течении суток и недели. На Рисунок 4.1.2 видны спады сетевой активности в ночное время и в выходные дни. Левый край диаграммы соответствует понедельнику 9 сентября (ночь), правый - понедельнику, но уже следующей недели. На Рисунок 4.1.3 приведена диаграмма вариации некоторых переменных за сутки. Сетевая активность захватывает период от 10 часов утра и спадает почти до нуля к 9-10 вечера, хотя бывают и исключения. Для эффективной интерпретации временных зависимостей можно использовать программу мониторинга last (или любой ее эквивалент), которая позволяет отслеживать появление новых пользователей или процессов (например, ftp). Фрагмент распечатки, выданной программой last на ЭВМ, snmp-резидентом которой пользовалась наша программа, приведен ниже.

ms977	pts/0	vitep5.itep.ru	tue sep 10 23:49 - 00:16 (00:27)
ms977	pts/2	vitep5.itep.ru	tue sep 10 22:20 - 23:46 (01:26)
ostrouh	pts/0	athene.itep.ru	tue sep 10 18:30 - 18:43 (00:13)
titovich	pts/0	athene.itep.ru	tue sep 10 18:30 - 18:30 (00:00)
vita	pts/3	athene.itep.ru	tue sep 10 14:55 - 15:56 (01:00)
checho	pts/12	itep05.itep.ru	tue sep 10 13:35 - 13:37 (00:01)
fomin	pts/10	hydra.ifh.de	tue sep 10 13:16 - 13:22 (00:06)
checho	pts/7	itep05.itep.ru	tue sep 10 13:09 13:16 (00:07)
illarion	pts/7	xt07.itep.ru	tue sep 10 12:45 12:45 (00:00)
vita	pts/9	athene.itep.ru	tue sep 10 11:55 13:03 (01:07)
bely	pts/12	pcx01.itep.ru	tue sep 10 11:49 12:02 (00:13)
vita	pts/13	athene.itep.ru	tue sep 10 11:49 11:52 (00:03)
efre	pts/4	pcx10.itep.ru	tue sep 10 10:05 10:24 (00:18)
checho	pts/0	169-151-147.ipt.	tue sep 10 05:07 05:09 (00:01)
ssemen	ftp	clotho.itep.ru	mon sep 09 20:14 20:15 (00:01)
ssemen	ftp	clotho.itep.ru	mon sep 09 19:34 19:35 (00:00)
ostrouh	pts/3	athene.itep.ru	mon sep 09 19:20 19:40 (00:20)
ozero	pts/0	athene.itep.ru	mon sep 09 19:13 22:44 (03:30)
ozero	pts/5	itep05.itep.ru	mon sep 09 18:05 18:32 (00:27)
olyalin	pts/6	itep05.itep.ru	mon sep 09 16:19 16:27 (00:08)
efre	ftp	pcx10.itep.ru	mon sep 09 16:14 16:15 (00:00)
mara	pts/1	hpl3pur2.cern.ch	mon sep 09 16:02 16:27 (00:24)
mara	pts/1	hpl3pur2.cern.ch	mon sep 09 15:50 15:54 (00:04)
itep977	pts/2	1mars.itep.ru	mon sep 09 15:22 15:23 (00:00)
ozero	pts/20	aix0.itep.ru	mon sep 09 15:06 15:36 (00:29)
ozero	pts/12	itep05.itep.ru	mon sep 09 14:56 14:56 (00:00)
galy	pts/16	athene.itep.ru	mon sep 09 14:27 14:31 (00:03)
bely	pts/15	vitep5.itep.ru	mon sep 09 14:09 10:36 (20:27)
sed	pts/5	pcx11.itep.ru	mon sep 09 14:01 14:01 (00:00)
kisel	pts/1	vxitep.itep.ru	mon sep 09 13:59 15:22 (01:22)
ozero	pts/12	itep05.itep.ru	mon sep 09 13:53 14:55 (01:02)
ozero	pts/2	193.148.166.214	mon sep 09 13:40 13:41 (00:00)
ozero	pts/8	193.148.166.214	mon sep 09 13:32 13:37 (00:04)
vita	pts/9	aix0.itep.ru	mon sep 09 13:32 13:32 (00:00)
vita	pts/2	vitep5.itep.ru	mon sep 09 13:32 13:32 (00:00)
checho	pts/3	itep05.itep.ru	mon sep 09 13:11 13:12 (00:00)
efre	pts/3	pcx10.itep.ru	mon sep 09 12:12 12:23 (00:10)
kisel	pts/2	vxitep.itep.ru	mon sep 09 12:11 12:43 (00:32)
checho	pts/6	itep05.itep.ru	mon sep 09 12:02 12:03 (00:00)
kisel	ftp	pcx11.itep.ru	mon sep 09 11:42 11:43 (00:00)
kisel	ftp	ion04.cern.ch	mon sep 09 10:59 11:06 (00:06)
galy	pts/1	athene.itep.ru	mon sep 09 10:57 10:58 (00:00)
titovich	pts/4	athene.itep.ru	mon sep 09 10:20 10:21 (00:01)
korol	pts/0	193.124.225.174	mon sep 09 05:20 05:57 (00:37)

<
/p> Первая колонка содержит имена пользователей, вторая - тип задачи (PTS/n - удаленный доступ с терминала с номером n), далее следует имя узла или его IP-адрес, с которого осуществлен доступ, дата, время работы и длительность сессии. Как правило, сессии типа FTP или NFS дают большую сетевую загрузку. Нужно учитывать возможность запуска FTP-сессии или другой информационно-емкой процедуры после входа в систему с помощью telnet (PTS). Рассматривая эту распечатку совместно с временными зависимостями переменных базы данных MIB, можно интерпретировать результаты, определить, какая из сессий загружает данный сегмент сети более других. Рассмотрев, например, результаты работы программы last и Рисунок 5.1.3а, можно видеть, что максимум в период с 18 до 20 часов связан с активностью пользователей ozero, ostrouh и ssemen. Но даже в отсутствии сессий, зафиксированных last, можно наблюдать заметную сетевую активность. Это может быть доставка почтовых сообщений или зондирование сервера пакетами-роботами со стороны удаленных www-клиентов.

Внешний протокол BGP

4.4.11.4 Внешний протокол BGP

Протокол BGP (RFC-1267, BGP-3; RFC-1268; RFC-1467, BGP-4; -1265-66, 1655) разработан компаниями IBM и CISCO. Главная цель BGP - сократить транзитный трафик. Местный трафик либо начинается, либо завершается в автономной системе (AS); в противном случае – это транзитный трафик. Системы без транзитного трафика не нуждаются в BGP (им достаточно EGP для общения с транзитными узлами). Но не всякая ЭВМ, использующая протокол BGP, является маршрутизатором, даже если она обменивается маршрутной информацией с пограничным маршрутизатором соседней автономной системы. AS передает информацию только о маршрутах, которыми она сама пользуется. BGP-маршрутизаторы обмениваются сообщениями об изменении маршрутов (UPDATE-сообщения, Рисунок 4.4.11.4.1). Максимальная длина таких сообщений составляет 4096 октетов, а минимальная 19 октетов. Каждое сообщение имеет заголовок фиксированного размера. Объем информационных полей зависит от типа сообщения.

Временная диаграмма обмена

Рисунок 3. Временная диаграмма обмена сообщениями между DHCP-клиентом и сервером в ходе присвоения нового сетевого адреса

3. Клиент получает одно или более сообщений DHCPOFFER от одного или более серверов. Клиент может предпочесть дождаться нескольких откликов. Клиент выбирает один сервер, которому пошлет запрос конфигурационных параметров, согласно предложению, содержащемуся в сообщении DHCPOFFER. Клиент широковещательно отправляет сообщение DHCPREQUEST, которое должно содержать опцию 'server identifier', чтобы указать, какой сервер им выбран, и которое может включать в себя другие опции, специфицирующие желательные конфигурационные значения. Опция 'requested IP-адрес' в сообщении сервера DHCPOFFER должна содержать значение 'yiaddr'. Сообщение DHCPREQUEST посылается широковещательно агентами транспортировки DHCP/BOOTP. Для того чтобы быть уверенным, что любой агент транспортировки BOOTP направляет сообщение DHCPREQUEST тому же набору DHCP-серверов, которые получили исходное сообщение DHCPDISCOVER, сообщение DHCPREQUEST должно использовать то же значение поля 'secs' заголовка DHCP-сообщения и должно посылаться по тому же широковещательному IP-адресу, что и оригинальное сообщение DHCPDISCOVER. Клиент реализует таймаут и повторно посылает сообщение DHCPDISCOVER, если не получает сообщений DHCPOFFER.

4.

Серверы получают широковещательное сообщение DHCPREQUEST от клиента. Серверы, не выбранные сообщением DHCPREQUEST, используют сообщение как уведомления о том, что клиент отверг предложение сервера. Сервер, выбранный сообщением DHCPREQUEST, осуществляет запись конфигурационного набора клиента в постоянную память и реагирует сообщением DHCPACK, содержащим конфигурационные параметры для клиента, приславшего запрос. Комбинация 'client identifier' или 'chaddr' и присвоенного сетевого адреса представляет собой уникальный идентификатор для времени действия адреса клиента и используется клиентом и сервером для идентификации этого времени в любом DHCP-сообщения. Любые конфигурационные параметры в сообщении DHCPACK не должны конфликтовать с параметрами из сообщения DHCPOFFER, на которое клиент откликается. Сервер не должен проверять предложенный сетевой адрес. В поле 'yiaddr' сообщений DHCPACK записывается выбранный сетевой адрес. Если выбранный сервер не может адекватно реагировать на сообщение DHCPREQUEST (например, запрошенный сетевой адрес уже выделен), сервер должен реагировать посылкой сообщения DHCPNAK. Сервер должен пометить адрес, предложенный клиенту в сообщении DHCPOFFER, как доступный, если сервер не получил от клиента никакого сообщения DHCPREQUEST.

5.

Клиент получает сообщение DHCPACK, содержащее конфигурационные параметры. Клиент должен выполнить окончательную проверку параметров (например, запустить ARP для выделенного сетевого адреса), и фиксировать длительность предоставления конфигурационных параметров, прописанную в сообщении DHCPACK. Клиент окончательно сконфигурирован. Если клиент обнаруживает, что адрес уже используется (например, с помощью ARP), он должен послать серверу сообщение DHCPDECLINE и повторно запустить процесс конфигурации. Клиент должен подождать как минимум 10 секунд, прежде чем заново начинать конфигурационную процедуру, чтобы избежать возникновения лишнего сетевого трафика. Если клиент получает сообщение DHCPNAK message, клиент перезапускает конфигурационный процесс.

<

и повторно посылает сообщение DHCPREQUEST,

/p> Клиент реализует таймаут и повторно посылает сообщение DHCPREQUEST, если клиент не получает ни сообщения DHCPACK ни DHCPNAK. Клиент повторно посылает DHCPREQUEST согласно алгоритму повторной пересылки, описанному в разделе 4.1. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго; например, клиент, осуществляя повторную пересылку так, как это описано в разделе 4.1, может повторно послать сообщение DHCPREQUEST четыре раза, при полной задержке 60 секунд, прежде чем повторно запустит процедуру инициализации. Если клиент не получает ни сообщения DHCPACK ни DHCPNAK после применения алгоритма повторной пересылки, клиент возвращается в исходное состояние и перезапускает процесс инициализации. Клиент должен уведомить пользователя о том, что процесс инициализации не прошел и делается повторная попытка.

6.

Клиент может решить отказаться от аренды сетевого адреса путем посылки серверу сообщения DHCPRELEASE. Клиент идентифицирует набор параметров, от которого он отказывается, с помощью своего идентификатора, или 'chaddr' и сетевого адреса в сообщении DHCPRELEASE. Если клиент использовал идентификатор клиента, когда он получил набор конфигурационных параметров, клиент должен использовать тот же идентификатор клиента (client identifier) в сообщении DHCPRELEASE.

3.2. Взаимодействие клиента и сервера при повторном использовании ранее выделенных сетевых адресов



Если клиент помнит и желает использовать выделенный ранее сетевой адрес, он может опустить некоторые шаги, рассмотренные в предыдущем разделе. Временная диаграмма на Рисунок 4 показывает типовое взаимодействие клиента и сервера в случае повторного использования старого сетевого адреса.

1.

Клиент широковещательно рассылает по локальной субсети сообщение DHCPREQUEST. Сообщение включает в себя сетевой адрес клиента в опции 'requested IP-адрес'. Раз клиент не получил свой сетевой адрес, он не должен заполнять поле 'ciaddr'. Агенты транспортировки BOOTP передают сообщение DHCP-серверам за пределами данной субсети. Если клиент использует 'client identifier' для получения своего адреса, клиент должен использовать тот же 'client identifier' в сообщении DHCPREQUEST.

2.

Серверы, которые знают конфигурационные параметры клиента, откликаются сообщением DHCPACK. Серверы не должны проверять, используется ли уже сетевой адрес клиента; клиент может реагировать посылкой запроса эхо ICMP.

Так как клиент и сервер могут не иметь синхронизованных часов, значения времени в DHCP-сообщения являются относительными, и должны интерпретироваться с учетом показаний локальных часов клиента. Время измеряется в секундах и представляется в виде 32-битных кодов без знака. Это позволяет описывать относительные интервалы времени от 0 до примерно 100 лет, что вполне приемлемо для целей протокола DHCP.

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



3.4. Получение параметров при внешне заданных адресах



Если клиент получил сетевой адрес каким-то другим образом (например, при ручной конфигурации), он может использовать запрос-сообщение DHCPINFORM, чтобы получить другие локальные конфигурационные параметры. Серверы, получив сообщение DHCPINFORM, формируют сообщение DHCPACK с любыми конфигурационными параметрами, приемлемыми для клиента. При этом сетевой адрес не присваивается, не проверяется существующий набор параметров, не заполняется 'yiaddr' и не задаются параметры времени действия конфигурационного набора. Серверы должны послать ответ DHCPACK по уникастному адресу, заданному в поле 'ciaddr' сообщения DHCPINFORM.

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



3.5. Параметры клиента в DHCP



Не все клиенты требуют инициализации всех параметров, перечисленных в приложении A.


Используются два способа сокращения числа параметров, пересылаемых от сервера клиенту. 1. Большинство параметров имеет значения по умолчанию, определенные в Host Requirements RFC; если клиент не получил параметров от сервера, которые переписывают значения по умолчанию, клиент использует эти значения. 2. В своем исходном сообщении DHCPDISCOVER или DHCPREQUEST, клиент может предоставить серверу список специфических параметров, которые ему нужны. Если клиент включает список параметров в сообщение DHCPDISCOVER, он должен включать этот список в любое последующее сообщение DHCPREQUEST.

Клиент должен включить опцию 'maximum DHCP message size', чтобы позволить серверу знать, максимальный размер его DHCP-сообщений. Параметры, присланные в ответ клиенту, могут иметь размер больший, чем выделено для опций в сообщении DHCP. В этом случае, два дополнительных опционных флага (которые должны присутствовать в поле 'опции' сообщения) индицируют, что для опций должны использоваться поля 'file' и 'sname'.

Клиент может проинформировать сервер о том, в каких конфигурационных параметрах заинтересован клиент, включив опцию 'parameter request list'.

Кроме того, клиент может предложить значения для сетевого адреса и времени его действия в сообщении DHCPDISCOVER. Клиент может включить опцию 'requested IP-адрес', чтобы предложить конкретное значение IP-адреса, которое он хотел бы получить, и может включить опцию 'IP-адрес lease time', чтобы предложить предпочтительное значение времени действия конфигурационного набора. Другие опции, представляющие рекомендации по конфигурационным параметрам, допустимы в сообщении DHCPDISCOVER или DHCPREQUEST. Однако дополнительные опции могут игнорироваться серверами, и разные серверы могут прислать различные отклики на одни и те же опции. Опция 'requested IP-адрес' должна заноситься только в сообщение DHCPREQUEST, когда клиент проверяет конфигурационные параметры, полученные ранее. Клиент заполняет поле 'ciaddr', только когда он имеет корректный IP-адрес в состояниях BOUND, RENEWING или REBINDING.



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



3.6. Применение DHCP для клиентов с несколькими интерфейсами



Клиент с несколькими сетевыми интерфейсами должен использовать DHCP для получения конфигурационных параметров через каждый из интерфейсов независимо.



3.7. Когда клиентам следует использовать DHCP?



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

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

Протокол динамической конфигурации ЭВМ DHCP

1. Введение

Протокол динамической конфигурации ЭВМ DHCP (Dynamic Host Configuration Protocol, RFC-2131, -2132, -2485, -2563, -2610, -2855, -2937, -2939, -3004, -3011, -3046; [22], [23], [24] и [25]) служит для предоставления конфигурационных параметров ЭВМ, подключенных к Интернет. DHCP имеет два компонента: протокол предоставления специфических для ЭВМ конфигурационных параметров со стороны DHCP-сервера и механизм предоставления ЭВМ сетевых адресов.
Протокол DHCP используется, помимо загрузки бездисковых станций или Х-терминалов (BOOTP), сервис-провайдерами для пулов модемов, когда число одновременно занятых модемов существенно меньше их полного числа. Это позволяет сэкономить заметное число IP-адресов. Протокол эффективен для случая распределения адресов за Firewall, где ЭВМ в защищенной зоне все равно бессмысленно выделять реальные IP-адреса.
DHCP построен по схеме клиент-сервер, где DHCP-сервер выделяет сетевые адреса и доставляет конфигурационные параметры динамически конфигурируемым ЭВМ.
ЭВМ не должна действовать как DHCP-сервер, если только она специально не сконфигурирована системным администратором. IP-протокол требует установки многих параметров. Так как IP-протокол может быть использован самым разным сетевым оборудованием, значения этих параметров не могут быть угаданы заранее. Кроме того, схема распределенного присвоения адресов зависит от механизма выявления уже используемых адресов. ЭВМ могут не всегда корректно зарезервировать свои сетевые адреса, таким образом, схема распределенного выделения адресов не может гарантировать уникальности сетевых адресов.
DHCP поддерживает три механизма выделения IP-адресов. При "автоматическом выделении", DHCP присваивает клиенту постоянный IP-адрес. При "динамическом присвоении", DHCP присваивает клиенту IP-адрес на ограниченное время. При "ручном выделении", IP-адрес выделяется клиенту сетевым администратором, а DHCP используется просто для передачи адреса клиенту. Конкретная сеть использует один или более этих механизмов, в зависимости от политики сетевого администратора.


Динамическое присвоение адресов представляет собой единственный механизм, который позволяет автоматически повторно использовать адрес, который не нужен клиенту. Таким образом,
динамическое присвоение адресов является оптимальной схемой для клиентов, подключаемых к сети временно, или совместно использующих один и тот же набор IP-адресов и не нуждающихся в постоянных адресах.
Формат сообщений DHCP базируется на формате сообщений BOOTP, чтобы можно было воспользоваться процедурами транспортировки данных, описанными в спецификации BOOTP [7, 21] и обеспечить совместимость DHCP-серверов с существующими клиентами BOOTP. Использование агентов транспортировки BOOTP исключает необходимость наличия DHCP-серверов в каждом физическом сегменте сети.

1.1. Сопряженные разработки

Существует несколько протоколов Интернет, которые так или иначе связаны с проблемой присвоения сетевых адресов. Протокол RARP (Reverse Address Resolution Protocol) [10] через расширения, описанные в DRARP (Dynamic RARP [5]), не только позволяет определить сетевой адрес, но и включает в себя автоматический механизм распределения IP-адресов. Протокол TFTP (Trivial File Transfer Protocol) [20] обеспечивает транспортировку загрузочного модуля от boot-сервера. Протокол ICMP (Internet Control Message Protocol) [16] с помощью сообщений "ICMP redirect" информирует ЭВМ о дополнительных маршрутизаторах. ICMP может также предоставить информацию о масках субсетей (сообщения "ICMP mask request"). ЭВМ могут найти маршрутизатор через ICMP-механизм поиска маршрутизаторов [8].
BOOTP является транспортным механизмом сбора конфигурационной информации. Протокол BOOTP является масштабируемым, определены стандартные расширения [17] для нескольких конфигурационных параметров. Морган предложил расширение BOOTP для динамического присвоения IP-адресов [15]. Протокол NIP (Network Information Protocol), использованный в проекте Athena МТИ, предоставляет распределенный динамический механизм выделения IP-адресов [19].


Протокол RLP (Resource Location Protocol [1]) служит для нахождения серверов, предоставляющих услуги верхнего уровня. Бездисковые рабочие станции компании Sun Microsystems используют процедуру загрузки, которая с привлечением механизма RARP, TFTP и RPC, называемого "bootparams", предоставляет бездисковой ЭВМ конфигурационную информацию и фрагменты операционной системы.
Существуют разработки, которые позволяют определить для заданного пути максимальный размер пакета (MTU) [14]. Существуют предложение по использованию протокола ARP (Address Resolution Protocol) для нахождения и выбора ресурсов [6]. Наконец, в RFC Host Requirements [3, 4] упоминаются специфические требования к конфигурированию ЭВМ, и предлагается сценарий инициализации бездисковых ЭВМ.

1.2. Постановка задачи

Протокол DHCP предназначен для предоставления клиентам DHCP конфигурационных параметров, описанных в RFC Host Requirements. После получения через DHCP необходимых параметров, клиент DHCP должен быть готов к обмену пакетами с любой другой ЭВМ в Интернет. Параметры стека TCP/IP, предоставляемые протоколом DHCP перечислены в приложении A. Не все эти параметры необходимы для первичной инициализации клиента. Клиент и сервер могут согласовывать список необходимых параметров.
Протокол DHCP позволяет, но не требует конфигурации параметров клиента, не имеющих прямого отношения к IP-протоколу. DHCP не обращается к системе DNS для регистрации адреса [12, 13]. DHCP не может использоваться для конфигурации маршрутизаторов.

1.3. Терминология

В данном документе применены следующие определения:

DHCP клиент	Клиент DHCP является ЭВМ, подключенной к Интернет, которая использует DHCP, чтобы получить конфигурационные параметры, например сетевой адрес.
DHCP сервер	Сервер DHCP является ЭВМ, подключенной к Интернет, которая присылает клиенту DHCP параметры конфигурации.
Агент пересылки BOOTP	Агент пересылки BOOTP представляет собой ЭВМ, подключенную к Интернет, или маршрутизатор, который осуществляет связь между клиентом и сервером DHCP. DHCP спроектирован так, чтобы обеспечить совместимость со спецификациями протокола BOOTP.
Binding	Сопряжение (binding) представляет собой совокупность конфигурационных параметров, включая, как минимум, IP-адрес, присваиваемый DHCP-клиенту. Сопряжением управляют DHCP-серверы.

<


1.4. Цели

Ниже предлагается список основных задач DHCP.

o	DHCP представляет собой механизм, а не политику. DHCP должен управляться местными системными администраторами, путем задания желательных конфигурационных параметров.
o	Клиенты не должны требовать ручной конфигурации. Каждый клиент должен быть способен прочесть локальные конфигурационные параметры.
o	Сети не должны требовать ручной конфигурации для отдельных клиентов. В нормальных условиях, сетевой администратор не должен вводить какие-либо индивидуальные конфигурационные параметры клиента.
o	DHCP не требует отдельного сервера для каждой субсети.
o	Клиент DHCP должен быть готов получить несколько откликов на запрос конфигурационных параметров. Для повышения надежности и быстродействия можно использовать несколько DHCP-серверов, обслуживающих перекрывающиеся области сети.
o	DHCP должен сосуществовать с ЭВМ, которые сконфигурированы вручную.
o	DHCP должен быть совместим с логикой работы BOOTP-агента, описанной в RFC-951 и RFC-1542 [21].
o	DHCP должен обслуживать существующих клиентов BOOTP.

DHCP должен:

o	Гарантировать, что любой специфический сетевой адрес не будет использоваться более чем одним клиентом DHCP одновременно.
o	Поддерживать DHCP конфигурацию клиента при стартовой перезагрузке DHCP-клиента. Клиенту DHCP должен, при каждом запросе по мере возможности, присваиваться один и тот же набор конфигурационных параметров (например, сетевой адрес).
o	Поддерживать конфигурацию DHCP-клиента при перезагрузке сервера, и, по мере возможности, DHCP-клиенту должен присваиваться один и тот же набор конфигурационных параметров.
o	Позволяет автоматически присваивать конфигурационные параметры новым клиентам, чтобы избежать ручной конфигурации.
o	Поддерживать фиксированное или постоянное присвоение конфигурационных параметров для заданного клиента.

2. Краткий обзор протокола

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


В RFC-1542 [2] детализировано взаимодействие между BOOTP- и DHCP-клиентами и серверами [9]. Имеется несколько новых, опционных операций, которые оптимизируют взаимодействие между DHCP-клиентами и серверами (смотри разделы 3 и 4).
На Рисунок .1 представлен формат сообщения DHCP, а в таблице 1 перечислены поля этого сообщения. Числа в скобках указывают размер каждого из полей в октетах.
Существует два принципиальных отличия между DHCP и BOOTP. Во-первых, DHCP определяет механизмы, через которые клиентам на определенное время могут быть присвоены сетевые адреса, позволяя последовательное присвоение сетевого адреса различным клиентам. Во-вторых, DHCP предоставляет механизм, который позволяет клиенту получить все необходимые им для работы конфигурационные параметры.
DHCP вводит небольшое изменение в терминологию, имеющее целью прояснить значение одного из полей. Поле "vendor extensions" в BOOTP переименовано в поле "опции" в DHCP. Аналогично, помеченные информационные элементы, использованные в поле BOOTP "vendor extensions", которые именовались как "расширения производителя", теперь называются просто "опции".

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
op (1)	htype (1)	hlen (1)	Шаги (1)
xid (4)
secs (2)	Флаги (2)
ciaddr (4)
yiaddr (4)
siaddr (4)
chaddr (4)
chaddr (16)
sname (64)
Файл (128)
Опции (длина переменная)

---

---