Галкин В.А., Григорьев Ю.А. Телекоммуникации и сети

Подождите немного. Документ загружается.

5. Сетевые

протоколы

ОН

пользуется услугами IP для доставки своих сообщений. Другими словами,

каждое сообщение ICMP передается по сети внутри 1Р-дейтаграммы.

ICMP-сообщения бывают двух видов: сообщение-запрос и сообщение об

ошибке. Сообщевгае об ошибке тесно связано с породившей его дейтаграм-

мой и всегда содержит заголовок этой IP-дейтаграммы и первые 64 бит ее

данных. Это необходимо для того, чтобы узел-источник смог более точно

проанализировать причину ошибки, так как все прикладные протоколы стека

TCP/IP содержат наиболее важную информащпо для анализа в первых 8 байт

своего сообщения. Сообщения-запросы передают информащдю об определен-

ной сети и об

определенном компьютере

или их

используют для диагностичес-

ких

целей.

IP-пакеты с сообщениями ICMP передаются по сети «на общих основани-

ях»,

без приоритетов, поэтому они тоже могут теряться. В загруженной сети

они могут вызвать дополнительную загрузку маршрутизаторов, когда потеря

сообщения об ошибке приводит к порождению нового сообщения

и т.

д., пока

канал связи

не

исчерпает своей пропускной способности. Для того чтобы пре-

дотвратить подобные ситуащш, в спецификащш четко определены правила,

руководствуясь которыми компьютер может решить, передавать его ICMP-

сообщение

или

нет.

Правило

потеря пакета

ICMP-сообщением никогда

не

генерирует ново-

го ICMP-сообщения.

Правило

сообщения об ошибке никогда не генерируются в ответ на IP-

дейтаграммы с широковещательными или групповыми адресами, чтобы не

вызвать полную перегрузку сети - широковещательный шторм (broadcast

storm).

Правило

при повреждении фрагментированной дейтаграммы, 1СМР-со-

общение отправляют

только

после первого поврежденного фрагмента (так как

источник все равно повторит передачу всей дейтаграммы целиком).

Доставка ICMP-пакетов требует

двух

уровней инкапсуляции. ICMP-пакеты

инкапсулируются внутрь 1Р-дейтаграммы, которая сама передается по каж-

дой физической сети

поле данных кадра

(рис.

5.29).

Несмотря на

то,

что сообщения ICMP инкапсулируются и посьшаются, ис-

пользуя

IP,

ICMP не считают протоколом более высокого уровня -

он

является

Заголовок

кадра

Заголовок

дейтаграммы

Заголовок

ICMP

Данные ICMP

Область данных дейтаграммы

Область данных кадра

Рис

5.29.

Два

уровня инкапсуляции сообщения ICMP

370

5.5.

Протоколы

III уровня стека TCP/IP

Тип(8или0)

Код(О)

Идентификатор

16 31

Контрольная сумма

Последовательный номер

Необязательные данные

Рис.

5.30. Формат

пакета

ICMP

необходимой частью

IP.

Протокол

ВР

необходлм для транспортировки сообще-

ний

ICMP,

так как им, чтобы достичь своего конечного назначения, надо пере-

сечь несколько физических сетей. Поэтому, они не могут быть доставлены

только с помощью физической передачи.

Формат ICMP-пакетов. Хотя каждое сообщение ICMP имеет свой соб-

ственный формат, все они начинаются с трех одинаковых полей:

8-битового

целочисленного поля «Тип», идентифшщрующего сообщение,

8-битового

поля

«Код», обеспечивающего более точную информащпо о типе сообщения, и 16-

битового поля «Контрольная сумма»

(рис.

5.30). Помимо

того,

сообщения ICMP,

сообщающие об ошибках, всегда включают заголовок и первые 64 бит данных

дейтаграммы, вызвавшей ошибку. Это необходимо для того, чтобы узел-от-

правитель смог более точно проанализировать причину ошибки, так как все

протоколы прикладного уровня стека TCP/IP содержат наиболее важную ин-

формащпо для анализа в первых 64 бит своих сообщений.

Сетевые программы распознают ICMP-сообщения по двум признакам: зна-

чению поля «Тип» и значению поля

«Код».

Контрольная сумма вычисляется не

только для ICMP-заголовка, но и для всего сообщения.

Таблица

5.12.

Типы

сообщений ICMP

Тип

сообщения

ICMP

Описание

Ответ на эхо (Echo Reply)

Узел назначения недостижим (Destination Unreachable)

Подавление источника (Source Quench)

Перенаправление маршрута (Redirect)

Запрос эха (Echo Request)

Информащы о маршрутизаторах (Router Advertisement)

Регистращ1я маршрутизатора (Router Solicitation)

Лимит времени для дейтаграммы превышен (Time Exceeded for а Data-

gramm)

Проблема с параметром пакета (Parameter Problem on а Datagramm)

Запрос метки времени (Timestamp Request)

Ответ для метки времени (Timestamp Reply)

Запрос информащш (не действует)

Ответ на запрос информащш (не действует)

Запрос маски адреса (Address Mask Request)

Ответ на запрос маски адреса (Address Mask Reply)

371

5. Сетевые

протоколы

Типы сообщений ICMP представлены в табл. 5.12. Рассмотрим каждое из

этих сообщений

его формат подробнее.

Тестирование достижимости места назначения. Протоколы TCP/IP

обеспечивают средства, помогающие сетевым администраторам или пользо-

вателям идентифшщровать проблемы в сети. Пользователь в качестве одного

из широко используемых средств отладки применяют команду, которая вызы-

вает сообщения ICMP запроса эха и ответа эха. Компьютер или маршрутиза-

тор посьшает сообщение запроса эха указанному месту назначения. Любая

машина, получившая

запрос

эха,

генерирует ответ

на эхо и

возвращает

его

пер-

воначальному отправителю. Этот запрос содержит необязательную область

данных; ответ содержит

копию

дашхых,

посланных

запросе.

Запрос

эха и

свя-

занный

ним ответ

можно

использовать для проверки достижимости назначе-

ния и его способности отвечать на запросы. Так как и запрос эха, и ответ на

него передаются в IP-дейтаграммах, успешный прием ответа свидетельству-

ет о работоспособности основных частей транспортной системы. Во-первых,

программное обеспечение IP на машине источника выполнило маршрутиза-

щпо дейтаграммы. Во-вторых, промежуточные маршрутизаторы между ис-

точником и получателем работоспособны и корректно маршрутизируют дей-

таграммы. В-третьих, машина получателя работает (по крайней мере, она

обрабатьшает прерывания) и программное обеспечение, как IP, так и ICMP,

выполняет свои

функции.

И, наконец,

таблищ>1

маршрутов

маршрутизаторах

на всем обратном пути корректны.

Во многих системах команда, которую пользователи вызывают для посыл-

ки запроса эха ICMP, назьюается

ping.

Усложненные версии этой программы

посьшают серии запросов эха

ICMP,

принимают ответы и вьщают статистику

о потерях дейтаграмм. Они позволяют пользователю указьюать длину посы-

лаемых данных и интервалы времени между запросами. Менее сложные вер-

сии просто посьшают запрос эха ICMP и ждут ответа.

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

запроса эха и

ответа

эха.

Средства для тестирова-

ния достижимости узлов сети представляют собой очень простой эхо-прото-

кол,

включающий

обмен двумя типами

сообщений:

эхо-запрос

эхо-ответ.

Ком-

пьютер или маршрутизатор посылают по интерсети эхо-запрос, в котором

указывают IP-адрес узла, достижимость которого нужно проверить. Узел, по-

лучающий эхо-запрос, формирует и отправляет эхо-ответ и возвращает сооб-

щение узлу ~ отправителю запроса. В запросе могут содержаться некоторые

данные, которые должны быгь возвращены в ответе.

Рис.

5.30 иллюстрирует формат сообщений запроса эха и ответа на запрос

эха.

Поле «Необязательные данные» имеет переменную длину

содержит дан-

ные,

которые надо вернуть отправителю. Ответ на эхо всегда возвращает те

же самые данные, что бьши получены им в запросе. Поля «Идентификатор» и

«Последовательный

номер»

отправитель использует

для

проверки соответствия

ответов запросам. Значение поля «Тип» определяет, является ли сообщение

запросом (8) или ответом (0).

372

5.5.

Протоколы

III уровня стека TCP/IP

8 16 31

Тип(З) Код (0-5) Контрольная сумма

Не используется (должно быть нулевым)

Префикс дейтаграммы (Заголовок плюс первые 8 байт дейтаграммы)

Рис.

5.31.

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

недостижимости назначения

Сообщения о недостиэюимости назначения. Когда маршрутизатор не

может доставить 1Р-дейгаграмму, он посылает сообщите «назначение недо-

стижимо» первоначальному отправителю, используя формат, приведенный на

рис. 5.31. Поле «Код» в сообщении о недостижимости назначения содержит

целое

число,

которое описывает

причину.

Возможные значения представлены

табл.

5.13.

Таблица

5.13.

Коды

сообщений

недостижимости

£^ад

сообщения

Пояснения

Сеть недостижима

Компьютер недостижим

Протокол недостижим

Порт недостижим

Необходима фрагментащм

Ошибка при маршрутизащш источника

Сеть назначения неизвестна

Компьютер назначения неизвестен

Компьютер источника изолирован

Взаимодействие с сетью назначения административно запрещено

То же с компьютером назначения

Сеть недостижима из-за класса обслуживания

Компьютер недостижим из-за класса обслуживания |

Хотя протокол

ЕР

является механизмом ненадежной доставки, дейтап)ам-

мы

не уничтожаются просто

так.

Всякий раз, когда опшбка мешает марпфути-

затору произвести марпфутизащпо или доставку дейтаграммы, марпфутиза-

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

затем

уничтожает дейтаграмму. Ошибки недостижимости сети обычно являются

следствием ошибок маршрутизащш; ошибки недостижимости компьютера -

следствие ошибок при доставке.

Назначения могут быгь недостижимыми из-за

того,

что оборудование бьшо

временно неработоспособно, отправитель указал несуществующий адрес на-

значения или (в редких случаях) у маршрутизатора не указано маршрута к

сети назначения. Необходимо отметить, что не все подобные ошибки можно

обнаружить.

373

Сетевые протоколы

Если дейтаграмма содержит

опцию

маршрутизации источника

некоррект-

ным маршрутом, то это может привести к появлению сообщения об ошибке

маршрутизации

источника.

Если

шлюзу

нужно

фрагментировать дейтаграмму,

но

установлен бит

«не

фрагментировать», то шлюз посьшает сообщение «тре-

буется фрагментация» обратно источнику.

Управление потоком дейтаграмм и переполнение сети. Так как IP-

протокол

не

устанавливает соединения, то маршрутизаторы не могут резерви-

ровать память или коммуникационные ресурсы до получения дейтаграмм. В

результате,

трафик может вызвать перегрузку марпфутизаторов,

ситуацию,

на-

зываемую переполнением сети (congestion). Переполнение сети происходит

по двум

совершенно разным

причинам.

Во-первых, высокоскоростной компью-

тер может генерировать трафик быстрее, чем сеть может передавать его. На-

пример,

представим суперкомпьютер, генерирующий межсетевой

трафик.

Дей-

таграммам, посьшаемым

им,

может потребоваться передача,

конечном счете,

по медленной глобальной сети (WAN), хотя сам суперкомпьютер может быть

присоединен к высокоскоростной

LAN.

Переполнение будет возникать в мар-

пфутизаторе, присоединенном к глобальной сети, так как дейтаграммы будут

прибьшать быстрее, чем их можно послать. Во-вторых, если большому числу

компьютеров одновременно нужно посьшать дейтаграммы через один марш-

рутизатор, этот маршрутизатор может оказаться переполненным, хотя ни один

источник в отдельности не вызьшает эту проблему.

Когда дейтаграммы прибывают на пшюз или маршрутизатор быстрее, чем

он успевает их обрабатьшать, он временно ставит их в очередь в своей памя-

ти.

Если эти дейтаграммы создают небольшую пиковую нагрузку при переда-

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

должает поступать, то, в конечном счете, маршрутизатор или пшюз займет

всю память под очередь и вьшужден будет удалять новые прибьшающие дей-

таграммы. Тогда машина для выхода из состояния переполнения использует

сообщения

подавлении источника.

Сообщение о подавлении источника требует от источника уменьшить ско-

рость передачи дейтаграмм. Обычно переполненные маршрутизаторы посы-

лают по одному сообщению о подавлении источника на каждую удаляемую

дейтаграмму

или

используют

более сложные

технологии

выхода из

переполне-

ния. Формат подавления источника представлен на рис. 5.32. Помимо обыч-

ньпс полей ICMP «Тип», «Код» и «Контрольная сумма» и неиспользуемого

32-битового поля, сообщения о подавлении источника имеют

поле,

содержащее

О 8 16 31

Тип (4) Код(О) Контрольная сумма

Не используется (должно быть нулевым)

Префикс дейтаграммы (Заголовок плюс первые 8 байт дейтаграммы)

Рис.

5.32.

Формат сообщения о подавлении источника ICMP

374

5.5.

Протоколы

III уровня стека TCP/IP

префикс дейтаграммы. Как и в других сообщениях об ошибках ICMP поле

префикса дейтаграммы содержит префикс дейтаграммы, вызвавшей этот зап-

рос подавления источника.

Сообщеьшя ICMP, вызывающего эффект, обратный подавлению источника,

не существует. Вместо этого, компьютер, принявший сообщения о подавлении

источника от некоторой машины, снижает скорость, с которой он посьшает ей

дейтаграммы. Это происходит до тех пор, пока к нему не перестанут прихо-

дить сообщения о подавлении источника. Затем он постепенно увеличивает

скорость пока снова не получит сообщения о подавлении источника.

Перенаправление маршрута. Маршрутные таблшхы у компьютеров обьш-

но статические, так как их конфигурирует администратор сети, а у маршрути-

заторов - динамические, формируемые автоматически с помощью протоколов

обмена маршрутной информащш. Поэтому с течением времени при изменении

топологии сети маршрутные таблицы компьютеров могут устаревать.

При изменении топологии сети таблицы маршрутизации в маршрутизаторе

или компьютере могут стать некорректными. Изменение может быть времен-

ным (например, нужно заменить неисправное оборудование) или постоянным

(например, когда в межсетевое взаимодействие включается новая сеть). Мар-

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

чгобы отслеживать изменения в сети и своевременно менять марпфуты. Для

корректировки поведения компьютеров маршрутизатор может использовать

сообщение протокола ICMP, назьшаемое «перенаправлением» (Redirect), зап-

рашивающее изменение маршрута в таблице маршрутизации компьютера.

Механизм перенаправления протокола ICMP позволяет компьютерам со-

держать в конфигурационном файле только IP-адреса его локальных маршру-

тизаторов. С помощью сообщеьшй о перенаправлении маршрутизаторы будут

сообщать компьютеру всю необходимую ему информацию о том, какому мар-

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

т.

е.

маршрутизаторы передадут компьютеру нужную ему часть их таблиц марш-

рутизации.

Преимуществом схемы перенаправления ICMP является ее простота: она

позволяет компьютеру знать вначале адрес только одного маршрутизатора в

локальной сети. Этот начальный маршрутизатор возвращает сообщение ICMP

о перенаправлении всякий раз, когда компьютер посьшает дейтаграмму, для

которой существует лучший маршрут. Таблица маршрутизации компьютера

останется маленькой, но содержит оптимальные маршруты для всех использу-

емых назначений.

Сообщения о перенаправлении, тем не менее, не решают проблему распро-

странения информации о маршрутах полностью, так как они предназначены

только для взаимодействия между маршрутизатором и компьютером в одной

физической сети. Каждое сообщение о перенаправлении содержит 32-битовое

поле «ГР-адрес маршрутизатора» и поле «Префикс дейтаграммы», как это по-

казано на рис. 5.33.

375

5. Сетевые

протоколы

16 31

Тип (5) Код (0-3) Контрольная сумма

IP-

адрес

м^шругазатора

Префикс дейтаграммы (Заголовок плюс первые 8 байт дейтаграммы)

Рис. 5.33.

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

перенаправлении

ICMP

Поле «Межсетевой адрес маршрутизатора» содержит IP-адрес маршрути-

затора, который должен использовать компьютер при отправлении дейтаграм-

мы к назначению, указанному в заголовке дейтаграммы. Поле «Префикс дей-

таграммы» содержит заголовок IP и следующие 8 байт дейтаграммы, которая

привела к появлению этого сообщения. Поэтому компьютер, принимающий

сообщение о перенаправлении ICMP, должен выделить адрес назначения дей-

таграммы из префикса дейтаграммы. Поле «Код» в сообщении о перенаправ-

лении ICMP более конкретно указывает, как интерпретировать адрес назначе-

ния,

при этом значения имеют следующий смысл:

- перенаправление

дейтаграмм для этой сети (устарело), 1 - перенаправление дейтаграмм для

этого компьютера, 2 - перенаправление дейтаграмм для этого типа сервиса и

сети,

3 - перенаправление дейтаграмм для этого типа сервиса и компьютера.

Напомним, что каждый заголовок IP указывает тип сервиса, используемого

при маршрутизащш. Как правило, маршрутизаторы посьшают запросы пере-

назначения ICMP только на компьютеры, а не на другие маршрутизаторы.

Изменение маршрута

является

одной

из

наиболее интересных

фушщий

про-

токола ICMP - по существу, это один из механизмов автоматической оптими-

защш доставки пакетов и адаптации сетей ТСРЯР к изменениям топологии.

Запросы «Информация о маршрутизаторах» {типы 9 w 10).

Информащ1Я

маршрутизащш

находится в

местных конфигуращюнных

фай-

лах и загружается оттуда при запуске компьютера. Чтобы таблрща маршрути-

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

протокол реализует один из способов ее обновления.

Существует 2 типа сообщений маршрутизаторов:

•

- информащ1я о маршрутизащш;

• 10 - регистращы маршрутизатора.

Всякий раз, когда компьютер запускают, он генерирует сообщения о регис-

тращш. В ответ маршрутизаторы, находящиеся

в той

же локальной сети, посы-

лают сообщения с информащ1ей о маршрутизащш, позволяющие правильно

сконфигурировать маршрутную таблицу.

Формат сообщения «Информация

маршрутизации»

(тип 9)

описан в RFC 1256

(рис. 5.34).

376

5.5.

Протоколы

III уровня стека TCP/IP

8 16 31

Тип

(9)

Количество

адресов

Код(О)

Длина поля

адреса

Контрольная сумма

Время существования

П*-адрес

маршрутизатора 1

Приоритет 1

IP-

адрес маршрутизатора 2

Приоритет 2

Рис.

5.34. Формат сообщения «Информация

маршрутизации»

В одном ICMP-сообщении может содержаться описание нескольких адре-

сов,

количество которых указано в поле «Количество адресов». Поле «Размер

адреса» задает длину адреса в 32-битовых словах. В настоящее время «Длина

поля адреса» всегда равна 2.

Поле «Время существования» задает интервал времени, в течение которо-

го информащм еще не устарела. Как правило, это 1800 с.

Поле «Приоритет» указьшает, какой из адресов следует использовать пер-

вым и более интенсивно. Как правило, чем больше значение поля, тем выше

приоритет. Маршрутизаторы передают информационные сообщения широко-

вещательно через случайные интервалы времени. Обычно через 450...600 с.

Поле «Время существования» можно использовать для уведомления, что дан-

ный маршрутизатор выключается. При этом содержимое данного поля уста-

навливается равным 0.

Формат сообщения «Регистрация» (тип 10) представлен на

рис.

5.35.

Запрос «Регистрация» передается

раза с интервалом

с при запуске мар-

шрутизатора и продолжает (при необходимости) передаваться, пока маршру-

тизатор не

получит информационного сообщения

с нужной

маршрутной инфор-

мацией.

Обнаруэюеиие циклических или слишком длинных

путей.

Как было от-

мечено вьппе для защиты Интернета от перегрузок каждая дейтаграмма име-

ет счетчик времени жизни TTL (Time-To-Live). Маршрутизатор декременти-

рует счетчик времени

жиз1Ш

всякий раз, когда он обрабатывает дейтаграмму,

и удаляет ее, когда счетчик становится нулевым.

Тип

(10)

Указатель

Код(О)

Контрольная сумма

Заполняется нулями

Рис.

5.35.

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

«Регистрация»

377

5. Сетевые

протоколы

Тип (10)

Указатель

Код(О)

Контрольная сумма

Заполняется нулями

Рис. 5.36.

Формат

сообщения

«Лимит

времеш!

для

дейтаграммы превышен»

Независимо от того, удалил ли маршрутизатор дейтаграмму из-за обнуле-

ния счетчика времени жизни или из-за превышения времени ожидания фраг-

ментов дейтаграммы, он посьшает сообщение ICMP «Лимит времени для дейта-

граммы превьппен» источнику дейтаграммы определенного формата (рис. 5.36).

Поле «Код» объясняет причину сообщения:

- превышено значение счет-

чика времени

жизни;

- превышено время ожидания фрагмента при сборке.

Сообщения

о других

ситуациях.

Когда маршрутизатор или компьютер стал-

кивается с проблемой, не укладывающейся

рамки описанных сообщений об

ошибках ICMP (например, некорректный заголовок дейтаграммы), связанной

с дейтаграммой, он посьшает сообщение «Проблема с параметром пакета»

первоначальному отправителю. Такую ситуащпо может вызвать некоррект-

ность аргументов опции. Сообщение, формат которого показан на рис. 5.37,

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

за этой опшбки. Для уточнения места ошибки

дейтаграмме отправитель ис-

пользует поле «Указатель» в заголовке сообщения для идентификации октета

в дейтаграмме, содержащего ошибку.

Синхронизация

часов и оценка времени

передачи.

Стек протоколов TCP/IP

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

зации часов. В сети

для

этого используется несколько технологий. Одна из про-

стейших технологий реализуется сообщениями ICMP для получения значения

времеьш от другой машины. Запрашивающая машина посьшает сообщение

ICMP «Запрос метки времени» другой машине, ожидая, что вторая машина

вернет ей текущее значение времени. Принимающая машина возвращает «От-

вет для метки времени» машине, вьщавшей запрос. Рис. 5.38 иллюстрирует

формат сообщений запроса и ответа временной метки. Поле «Тип» идентифи-

цирует сообщение

как

запрос (13)

или ответ

(14);

поля

«Идентификатор»

«Пос-

ледовательный номер» используют источник для связи между ответами и зап-

росами. Оставшиеся

поля

специфицируют

времена,

указанные

миллисекундах

после полуночи, по Гринвичу. Поле «Временная метка отправителя» заполняет

16 31

Тип (12)

Указатель

Код (0-1) Кошрольная сумма

Не используется (должно быть нулевым)

Префикс дейтаграммы (Заголовок плюс первые 8 байт дейтаграммы)

378

Рис. 5.37. Формат сообщения «Проблема с параметром пакета»

5.5.

Протоколы

III уровня стека TCP/IP

Тип (13 или 14) Код(О)

Идентификатор

Контрольная сумма

Последовательный номер

Префикс дейтаграммы (Заголовок плюс первые 8 байт дейгаграммы)

Временная метка отправителя

Временная метка приема

Временная метка передачи

Рис.

5.38.

Формат сообщений «Запрос метки времени»

«Ответ

для метки времени»

первоначальный отправитель перед передачей пакета, поле «Временная метка

приема» заполняется сразу после приема запроса, а поле «Временная метка

передачи» - непосредственно перед отправкой ответа.

Компьютеры используют эти три поля временных меток для определения

ожидаемого времени передачи между ними и синхронизации своих

часов.

Так

как ответ включает поле «Временная метка отправителя», компьютер может

вычислить общее время, требуемое для передачи запроса к назначению, фор-

мирования ответа на него и возвращения ответа. Так как ответ содержит как

время прихода запроса на удаленную

машину,

так

время выдачи ответа, ком-

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

между своими и удаленными часами. На практике бывает трудно точно оце-

нить время передачи по сети, так как IP является технологией с негарантиро-

ванной

доставкой,

дейтаграммы могут

быть

потеряны, задержаны

или

достав-

лены не по

порядку,

что

ограничивает полезность сообщений

ICMP о

временных

метках.

Сообщения запроса и ответа информации. Сообщения ICMP запроса

информации и ответа информации (тип

16) в

настоящее время устарели и

их использовать не рекомендуется. Они предназначались для обнаружения

компьютерами своих IP-адресов при

загрузке.

Сейчас для определения адреса

используют протоколы RARP и ВООТР.

Получение

маски

подсети.

Для применения адресации подсетей компью-

теру надо знать, какие биты их 32-битного IP-адреса соответствуют физичес-

кой

сети,

какие - адресу компьютера. Информация, требуемая для интерпре-

тации адреса, представляет собой 32-битовую величину, называемую маской

подсети. Чтобы узнать маску подсети, используемую

локальной

сети,

маши-

на может послать сообщение запроса маски адреса маршрутизатору и полу-

чить ответ маски адреса. Машина, формирующая запрос, может либо послать

сообщеьше

напрямую,

если она знает

адрес

маршрутизатора, либо послать ши-

роковещательное сообщение, если не знает

его.

Рис. 5.39 иллюстрирует фор-

мат сообщений маски адреса. Поле «Тип» в сообщении маски адреса указьгоа-

ет, является ли сообщение запросом (17) или ответом (18). Ответ содержит

маску адреса подсети в поле «Маска адреса». Как правило, поля «Идентифи-

катор» и «Последовательный номер» позволяют машине связать ответ с зап-

росом.

379