Что такое arp запрос. Протоколы ARP, RARP, IP, ICMP. Для чего используется протокол ARP

Любое устройство, подключенное к локальной сети (Ethernet, FDDI и т.д.), имеет уникальный физический сетевой адрес, заданный аппаратным образом. 6-байтовый Ethernet-адрес выбирает изготовитель сетевого интерфейсного оборудования из выделенного для него по лицензии адресного пространства. Если у машины меняется сетевой адаптер, то меняется и ее Ethernet-адрес.

4-байтовый IP-адрес задает менеджер сети с учетом положения машины в сети Интернет. Если машина перемещается в другую часть сети Интернет, то ее IP-адрес должен быть изменен. Преобразование IP-адресов в сетевые выполняется с помощью arp-таблицы. Каждая машина сети имеет отдельную ARP-таблицу для каждого своего сетевого адаптера. Не трудно видеть, что существует проблема отображения физического адреса (6 байт для Ethernet) в пространство сетевых IP-адресов (4 байта) и наоборот.

Протокол ARP (address resolution protocol, RFC-826) решает именно эту проблему - преобразует ARP- в Ethernet-адреса.

ARP-таблица для преобразования адресов

Преобразование адресов выполняется путем поиска в таблице. Эта таблица, называемая ARP-таблицей, хранится в памяти и содержит строки для каждого узла сети. В двух столбцах содержатся IP- и Ethernet-адреса. Если требуется преобразовать IP-адрес в Ethernet-адрес, то ищется запись с соответствующим IP-адресом. Ниже приведен пример упрощенной ARP-таблицы.

IP-адрес Ethernet-адрес
223.1.2.1 223.1.2.3 223.1.2.4 08:00:39:00:2F:C3 08:00:5A:21:A7:22 08:00:10:99:AC:54

Табл.1. Пример ARP-таблицы

Принято все байты 4-байтного IP-адреса записывать десятичными числами, разделенными точками. При записи 6-байтного Ethernet-адреса каждый байт указывается в 16-ричной системе и отделяется двоеточием.

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

Протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol) является обязательным стандартом TCP/IP, описанным в документе RFC 792, «Internet Control MessageProtocol (ICMP)». Используя ICMP, узлы и маршрутизаторы, связывающиеся по протоколу IP, могут сообщать об ошибках и обмениваться ограниченной управляющей информацией и сведениями о состоянии.



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

Протокол обмена управляющими сообщениями ICMP (Internet Control Message Protocol) позволяет маршрутизатору сообщить конечному узлу об ошибках, с которыми машрутизаторстолкнулся при передаче какого-либо IP-пакета от данного конечного узла.

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

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

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

Формат ICMP-пакета

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

Существует несколько типов сообщений ICMP. Каждый тип сообщения имеет свой формат, при этом все они начинаются с общих трех полей: 8-битного целого числа, обозначающего тип сообщения (TYPE), 8-битного поля кода (CODE), который конкретизирует назначение сообщения, и 16-битного поля контрольной суммы (CHECKSUM). Кроме того, сообщение ICMP всегда содержит заголовок и первые 64 бита данных пакета IP, который вызвал ошибку. Это делается для того, чтобы узел-отправитель смог более точно проанализировать причину ошибки, так как все протоколы прикладного уровня стека TCP/IP содержат наиболее важную информацию для анализа в первых 64 битах своих сообщений.



Прежде всего, TCP и UDP - протоколы. А основное их отличие в том TCP - протокол с гарантированной доставкой пакетов, UDP - нет.

TCP - «гарантированный» транспортный механизм с предварительным установлением соединения, предоставляющий приложению надёжный поток данных, дающий уверенность в безошибочности получаемых данных, перезапрашивающий данные в случае потери и устраняющий дублирование данных. TCP позволяет регулировать нагрузку на сеть, а также уменьшать время ожидания данных при передаче на большие расстояния. Более того, TCP гарантирует, что полученные данные были отправлены точно в такой же последовательности. В этом его главное отличие от UDP.

UDP протокол передачи датаграмм без установления соединения. Также его называют протоколом «ненадёжной» передачи, в смысле невозможности удостовериться в доставке сообщения адресату, а также возможного перемешивания пакетов. В приложениях, требующих гарантированной передачи данных, используется протокол TCP.
UDP обычно используется в таких приложениях, как потоковое видео и компьютерные игры, где допускается потеря пакетов, а повторный запрос затруднён или не оправдан, либо в приложениях вида запрос-ответ (например, запросы к DNS), где создание соединения занимает больше ресурсов, чем повторная отправка.
И TCP, и UDP используют для определения протокола верхнего уровня число, называемое портом.

Rip ospf

В первое время RIP распространялся вместе с операционной системой BSD и не рассматривался в качестве стандарта для Интернет. Однако впоследствии, подобно множеству других служб BSD, он стал критически важным элементом IP-сетей. В настоящее время в документах IETF закреплено две версии RIP: версия 1 (исходная) - в RFC 1058 и версия 2 - в RFC 1722 (Internet Standard 56). Обе они похожи, но между ними имеются некоторые важные различия.

Протокол RIP основан на алгоритме “длины векторов” (distance-vector), который связывает длину маршрута (число переходов - hops) с его вектором (сетью или хостом назначения). Информацию о маршрутах к тем или иным сетям/хостам устройства RIP получают от соседних маршрутизаторов и затем выбирают маршрут с наименьшим числом переходов. Как только маршрут к месту назначения выбран, он сохраняется в локальной базе данных, а информация обо всех остальных маршрутах к тому же месту назначения стирается. Периодически каждый маршрутизатор сообщает остальным об обнаруженных им маршрутах.

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

Протокол OSPF появился как ориентированный на IP-сети вариант протокола IS-IS. Он определен в нескольких документах IETF: в RFC 1131 описан OSPF 1 (устаревшая версия), в RFC 1583, - вероятно, самая распространенная версия OSPF 2, и, наконец, в RFC 2328 определен последний вариант OSPF 2 (Internet Standard 54).

При использовании OSPF на каждом маршрутизаторе содержится независимая база данных по административной области маршрутизации, включающая информацию о доступных сетях, маршрутизаторах и стоимости каждого соединения. Когда состояние сети, маршрутизатора или интерфейса изменяется, каждый обнаруживший это маршрутизатор (в пределах области) вносит информацию в локальную базу данных, а затем соответственно перестраивает карты маршрутизации. Выбор маршрута производится с учетом стоимости всех маршрутов к конкретной точке назначения и напрямую не зависит от числа переходов. Другими словами, для выбора оптимальных маршрутов в OSPF применяется алгоритм “стоимости векторов” (cost vector).

Эта модель предоставляет больше возможностей для улучшения маршрутизации (например, быстрее происходит синхронизация изменений), но требует большей вычислительной мощности и большего объема памяти от участвующих в процессе машин. По этой причине на рынке гораздо шире представлены системы с поддержкой RIP, нежели OSPF. Например, хотя во многих серверных ОС имеются те или иные OSPF-демоны, лишь очень небольшое число сетевых клиентов или устройств низшего класса поддерживают OSPF, поскольку даже для пассивного “прослушивания” приходится снабжать устройство полнофункциональным механизмом анализа базы данных OSPF.

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

Областям присваиваются 32-битовые идентификаторы (обычно они представлены в виде адресов IPv4), магистраль же всегда имеет номер 0. Маршрутизаторы могут одновременно присутствовать в нескольких областях, но для каждой из них они должны хранить отдельную базу данных о состоянии соединений. Согласно терминологии OSPF, маршрутизатор, присутствующий одновременно в нескольких областях, называется ABR (Area Border Router), а маршрутизатор, обменивающийся данными с другим протоколом маршрутизации, - ASBR (Autonomous System Border Router).

Протокол ARP работает различным образом в зависимости от того, какой протокол канального уровня работает в данной сети - протокол локальной сети (Ethernet, Token Ring, FDDI) с возможностью широковещательного доступа одновременно ко всем узлам сети, или же протокол глобальной сети (X.25, frame relay), как правило не поддерживающий широковещательный доступ.

В локальных сетях протокол ARP использует широковещательные кадры протокола канального уровня для поиска в сети узла с заданным IP-адресом.

Принцип работы:

    Узел, которому нужно выполнить отображение IP-адреса на локальный адрес, формирует ARP запрос, вкладывает его в кадр протокола канального уровня, указывая в нем известный IP-адрес, и рассылает запрос широковещательно.

    Все узлы локальной сети получают ARP запрос и сравнивают указанный там IP-адрес с собственным.

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

Arp-таблица для преобразования адресов

Преобразование адресов выполняется путем поиска в таблице. Эта таблица, называемая ARP-таблицей, хранится в памяти и содержит строки для каждого узла сети.

ARP-таблицы строятся согласно документу RFC-1213 и для каждого IP-адреса содержит четыре кода:

    Ifindex - Физический порт (интерфейс), соответствующий данному адресу;

    Физический адрес - MAC-адрес, например Ethernet-адрес;

    IP-адрес - IP-адрес, соответствующий физическому адресу;

    тип адресного соответствия - это поле может принимать 4 значения: 1 - вариант не стандартный и не подходит ни к одному из описанных ниже типов; 2 - данная запись уже не соответствует действительности; 3 - постоянная привязка; 4 - динамическая привязка;

Примет таблицы для технологии Ethernet:

Ethernet-адрес

08:00:39:00:2F:C3

08:00:5A:21:A7:22

08:00:10:99:AC:5

Принято все байты 4-байтного IP-адреса записывать десятичными числами, разделенными точками. При записи 6-байтного Ethernet-адреса каждый байт указывается в 16-ричной системе и отделяется двоеточием.

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

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

Arp кэш.

    Эффективность функционирования ARP во многом зависит от ARP кэша (ARP cache), который присутствует на каждом хосте.

    Стандартное время жизни каждой записи в кэше составляет 20 минут с момента создания записи.

Порядок преобразования адресов

В ходе обычной работы сетевая программа, такая как TELNET, отправляет прикладное сообщение, пользуясь транспортными услугами TCP. Модуль TCP посылает соответствующее транспортное сообщение через модуль IP. В результате составляется IP-пакет, который должен быть передан драйверу Ethernet. IP-адрес места назначения известен прикладной программе, модулю TCP и модулю IP. Необходимо на его основе найти Ethernet-адрес места назначения. Для определения искомого Ethernet-адреса используется ARP-таблица.

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

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

    Исходящий IP-пакет ставится в очередь.

Каждый сетевой адаптер принимает широковещательные передачи. Все драйверы Ethernet проверяют поле типа в принятом Ethernet-кадре и передают ARP-пакеты модулю ARP. ARP-запрос можно интерпретировать так: "Если ваш IP-адрес совпадает с указанным, то сообщите мне ваш Ethernet-адрес". Пакет ARP-запроса выглядит примерно так:

Пример ARP-запроса

Каждый модуль ARP проверяет поле искомого IP-адреса в полученном ARP-пакете и, если адрес совпадает с его собственным IP-адресом, то посылает ответ прямо по Ethernet-адресу отправителя запроса. ARP-ответ можно интерпретировать так: "Да, это мой IP-адрес, ему соответствует такой-то Ethernet-адрес". Пакет с ARP-ответом выглядит примерно так:

Пример ARP-ответа

Этот ответ получает машина, сделавшая ARP-запрос. Драйвер этой машины проверяет поле типа в Ethernet-кадре и передает ARP-пакет модулю ARP. Модуль ARP анализирует ARP-пакет и добавляет запись в свою ARP-таблицу.

Обновленная таблица выглядит следующим образом:

Если компьютер контактирует с другим аналогичным устройством в той же сети, требуется физический или MAC-адрес. Но поскольку приложение предоставило IP-адрес получателя, ему нужен какой-то механизм для его привязки с MAC-адресом. Это делается по протоколу разрешения адресов (ARP). IP-адрес узла назначения является широковещательным, а узел-получатель сообщает источник его MAC-адреса.

Это значит, что в каждом случае, когда машина A намерена передать пакеты данных устройству B, она вынуждена отправить ARP-пакет для разрешения MAC-адреса B. Следовательно, это слишком сильно увеличивает нагрузку на трафик, поэтому для снижения стоимости связи, компьютеры, которые используют протоколы ARP, сохраняют кеш недавно приобретенных привязок адресов IP_to_MAC, т. е. они не должны повторно использовать этот протокол.

Современный вид

Сегодня используются несколько усовершенствований протокола ARP и его назначения. Так, когда машина A хочет отправить пакеты устройству B, возможно, что B отправит данные для A в скором времени. По этой причине, чтобы избежать ARP для машины B, A должна выполнить привязку адреса IP_to_MAC при запросе MAC-адреса B в специальном пакете.

Поскольку A направляет свой изначальный запрос для MAC-адреса B, каждый компьютер в сети должен извлекать и хранить в своем кеше привязку адреса IP_to_MAC A. Когда в сети появляется новый компьютер (например, при перезагрузке операционной системы), он может транслировать эту привязку, чтобы все остальные машины могли хранить его в своих кешах. Это позволит устранить множество ARP-пакетов всеми другими машинами, когда они хотят общаться с добавленным устройством.

Вариации ARP-протокола

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

Сообщение запроса Address Resolution Protocol (которое выглядит как обращение A.A.A.A к B.B.B.B - IP-адресам) транслируется в локальной сети с использованием протокола Ethernet типа 0x806. Пакет отбрасывается всеми машинами, за исключением целевой, которая отвечает сообщением ответа APR (AAAA - hh: hh: hh: hh: hh: hh где hh: hh: hh: hh: hh: hh - адрес источника Ethernet). Этот ответ является одноадресным для машины с IP-адресом B.B.B.B. Поскольку сообщение запроса протокола APR включало аппаратный адрес (а именно - источника Ethernet) запрашивающего компьютера, целевому устройству не требуется другое сообщение, чтобы понять это.

Взаимосвязь с другими протоколами

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

RARP - это протокол, с помощью которого физическая машина в локальной сети может делать запрос, чтобы узнать свой IP-адрес из таблицы протокола или кэширования сервера шлюза. Это необходимо, так как на устройстве не может присутствовать постоянно установленный диск, где оно может постоянно хранить свой IP-адрес. Сетевой администратор создает таблицу в маршрутизаторе шлюза локальной сети, который сопоставляет адреса физического компьютера (либо управления доступом к среде - MAC) соответствующим «айпи». Когда новая машина настроена, ее клиентская программа RARP запрашивает с сервера RARP на маршрутизаторе для отправки его IP-адрес. Предполагая, что запись была настроена в таблице маршрутизатора, данный сервер RARP вернет «айпи» на компьютер, который может сохранить его для будущего использования. Таким образом, это тоже своеобразный протокол определения адреса.

Механизм в деталях

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

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

Как и сообщение протокола ARP, запрос RARP отправляется с одного компьютера на другой, инкапсулированный в части данных сетевого кадра. Рамка Ethernet, содержащая его, имеет обычную преамбулу, Ethernet-источник и адреса назначения, а также поля типа пакета перед кадром. Кадр кодирует значение 8035, чтобы идентифицировать его содержимое как сообщение RARP. Часть данных кадра включает в себя 28-октетное сообщение.

Отправитель отправляет запрос RARP, который указывает себя как инициатор запроса и целевую машину, и передает свой физический сетевой адрес в поле целевого аппаратного адреса. Все устройства в сети получают запрос, но только те из них, кто уполномочен предоставлять RARP, обрабатывают запрос и отправляют ответ. Такие машины известны неофициально как серверы данного протокола. Для успешной реализации протоколов ARP/RARP сеть должна содержать как минимум один такой сервер.

Они отвечают на запрос, заполняя поле адреса целевого протокола, изменяя тип сообщения от запроса до ответа и отправляя ответ прямо на машину, отправляющую запрос.

Синхронизация транзакций RARP

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

Преимущества Mulitple RARP Servers: большая надежность.

Недостаток: перегрузка может возникнуть, когда все серверы ответят.

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

Недостатки RARP

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

ICMP-протокол

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

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

Связующее звено

Протокол управления интернет-протоколом позволяет шлюзам отправлять сообщения об ошибках или управлять сообщениями на другие шлюзы или хосты. ICMP предоставляет связь между программным обеспечением протокола Интернета между компьютерами. Это механизм сообщений так называемого специального назначения, добавленный разработчиками к протоколам TCP/IP. Это позволяет шлюзам в Интернете информировать об ошибках либо направлять информацию о непредвиденных обстоятельствах.

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

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

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

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

Оно насчитывает в себе три поля:

  • 8-битное целочисленное поле TYPE, идентифицирующее сообщение;
  • 8-битовое поле CODE, которое предоставляет дополнительную информацию о его типе;
  • 16-разрядное поле CHECKSUM (ICMP использует одну и ту же контрольную сумму алгоритма, которая охватывает только сообщение этого протокола).

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

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

Протоколы TCP/IP предоставляют средства, помогающие сетевым менеджерам или пользователям идентифицировать сетевые проблемы. Один из чаще всего используемых инструментов отладки делает вызовы эхо-запроса ICMP и сообщения эхо-ответа. Хост или шлюз отправляет сообщение к определенному пункту назначения.

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

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

  • IP-программное обеспечение источника должно маршрутизировать датаграмму;
  • Промежуточные шлюзы пунктом назначения и источником должны работать и правильно маршрутизировать дейтаграмму;
  • Должен быть запущен конечный компьютер, и на нем должно работать как программное обеспечение ICMP, так и IP;
  • Маршруты в шлюзах по обратному пути должны быть правильными.

Как это работает?

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

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

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

Этот механизм осуществляется с помощью протоколов разрешения адресов (ARP). Благодаря им происходит трансляция IP-адреса узла назначения, который информирует источник MAC-адреса. Таким образом, протоколы ARP способствуют связи двух устройств при их одновременном подключении в сеть.

Как это работает?

Это означает, что каждый раз, когда машина А хочет послать пакеты данных машине B, A должна послать пакет ARP для запроса MAC-адреса B. Вместе с тем это неизбежно приведет к увеличению нагрузки на сеть и утяжелению трафика.

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

Вместе с тем некоторые уточнения ARP возможны: когда машина А хочет послать данные машине B, возможно, что B собирается посылать ответные данные А в ближайшем будущем. Поэтому, чтобы избежать использования ARP для машины B, A должна сохранить его связующий адрес IP_to_MAC в специальном пакете при запросе на MAC-адрес B. Так как A передает свой первоначальный запрос на MAC-адрес B, каждая машина в сети должна извлекать и хранить в своем кэше адрес IP_to_MAC.

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

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

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

Сообщение запроса ARP (который идет от IP-адреса A.A.A.A к B.B.B.B) транслируется по локальной сети с типом протокола Ethernet. Протоколы ARP исходят от всех машин, кроме целевой, которая направляет ответное сообщение на запрос. Этот ответ содержит в себе IP-адрес B.B.B.B, т.е. аппаратный адрес источника Ethernet, после чего будет налажена связь между устройствами.

Протокол ARP и его назначение - выводы

Как можно увидеть из описания выше, протокол разрешения адресов используется для наладки взаимодействия между различными устройствами в сети. Другими словами, это технология, без которой нормальное подключение не представляется возможным. Но возможна ли работа протокола ARP без других параметров сети? Определенно, невозможна. Поэтому следует рассмотреть другие протоколы, играющие важную роль.

Протокол восстановления обратного адреса

RARP является протоколом, по которому физический компьютер в локальной сети может запросить свой IP-адрес из таблицы Address Resolution Protocol или кэш-сервера шлюза. создает таблицу в шлюзе или маршрутизаторе локальной сети, которая отображает физический адрес машины (или адрес управления доступом к среде - MAC) относительно соответствующего протокола. Когда новое устройство подключается в сеть, его RARP-клиент создает на сервере запрос для отправки его IP-адреса. Предполагая, что запись была создана в таблице маршрутизатора, сервер RARP возвращает IP-адрес на машину, которая может хранить его для дальнейшего использования. Таким образом, протокол разрешения адресов ARP непрерывно связан с RARP.

Детальный механизм

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

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

Действие RARP во времени

Так как RARP использует физическую сеть напрямую, никакое другое программное обеспечение протокола не будет отвечать на запрос или ретранслировать его. Программное обеспечение RARP должно единолично справиться с этими задачами. Некоторые рабочие станции, которые полагаются на RARP для загрузки, могут неоднократно повторять попытку неопределенное время, пока не получат ответ. Другие реализации имеют отказ после нескольких попыток, чтобы избежать перегрузки сети ненужными трансляциями.

Протоколы IP/ICMP/ARP

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

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

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

Протоколы TCP/IP

TCP/IP-протоколы предоставляют средства, способные помочь сетевым администраторам или пользователям идентифицировать проблемы сети. Один из наиболее часто используемых инструментов отладки вызывает запрос ICMP и получает ответное сообщение. В то же время хост или шлюз посылает эхо-сообщение с запросом ICMP на указанный адрес. Любая машина, которая получает эхо-запрос, формулирует отклик и возвращает к исходному отправителю. При этом ответ содержит копию данных, передаваемых в запросе, а также связанный с ними отклик.

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

Введение

Проблема, которую мы будем обсуждать в этой главе, заключается в том, что IP адреса имеют какое-либо значение только в семействе протоколов TCP/IP. Канальные уровни, такие как Ethernet или Token ring, имеют собственную схему адресации (в основном 48-битные адреса); сетевые уровни, в свою очередь, используют эти канальные уровни. Сеть Ethernet, может быть использована различными сетевыми уровнями в одно и то же время. Компьютеры использующие разные сетевые протоколы могут находиться на одном и том же физическом кабеле.

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

Другими словами возникает необходимость установить соответствие между двумя различными формами адресов: 32-битными IP адресами и каким-либо типом адресов канального уровня. RFC 826 [ Plummer 1982] - официальная спецификация ARP.

На рисунке 4.1 показаны два протокола, которые мы рассмотрим в этой и следующей главах: протокол определения адреса (ARP - address resolution protocol) и обратный протокол определения адреса (RARP - reverse address resolution protocol).

Рисунок 4.1 Протоколы определения адреса: ARP и RARP.

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

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

Если мы введем команду

% ftp bsdi

будет выполнена следующая последовательность действий. (См. рисунок 4.2.)

  1. Приложение, FTP клиент, вызывает функцию gethostbyname(3), чтобы конвертировать имя хоста (bsdi) в 32-битный IP адрес. Эта функция в DNS (Domain Name System) называется разборщиком (resolver) , мы опишем это подробно в . Подобное преобразование осуществляется с использованием DNS или, если существует маленькая сеть, то с помощью статического файла хостов ( /etc/hosts).
  2. FTP клиент требует установить TCP соединение с указанным IP адресом.
  3. TCP посылает запрос на установление соединения удаленному хосту, посылая IP датаграммы по указанному IP адресу. (Мы рассмотрим как это делается более подробно в .)
  4. Если хост назначения подключен к сети (Ethernet, Token ring, или к другому концу канала точка-точка), IP датаграмма может быть послана непосредственно хосту. Если хост назначения находится в удаленной сети, IP маршрутизатор определяет Internet адрес непосредственно подключенного маршрутизатора следующей пересылки, чтобы послать туда IP датаграмму. В обоих случаях IP датаграмма посылается либо хосту, либо маршрутизатору, подключенные непосредственно к данной сети.
  5. Если используется Ethernet, посылающий хост должен конвертировать 32-битный адрес в 48-битный Ethernet адрес. Или другими словами, осуществить преобразование из логического Internet адреса в соответствующий физический аппаратный адрес. Этим занимается ARP. ARP работает в широковещательных сетях, где много хостов или маршрутизаторов подключено к одной и той же сети.
  6. ARP посылает фрейм Ethernet, который называется ARP запрос (ARP request), каждому хосту в сети. Подобный метод рассылки называется широковещательным запросом (broadcast). На рисунке 4.2 широковещательный запрос показан пунктирными линиями. ARP запрос содержит IP адрес хоста назначения (имя которого bsdi) и запрос "если Вы владелец этого IP адреса, пожалуйста сообщите мне Ваш аппаратный адрес".

Рисунок 4.2 Реакция ARP на ввод пользователя: ftp hostname.

  • Хост назначения на ARP уровне получает этот широковещательный запрос, определяет, что отправитель спрашивает именно его IP адрес, и отвечает на него ARP откликом (ARP reply). Этот отклик содержит IP адрес и соответствующий аппаратный адрес.
  • ARP отклик принимается, и IP датаграмма, из-за которой начался обмен ARP запрос - ARP отклик, может быть послана.
  • IP датаграмма отправляется на хост назначения.
  • Фундаментальная концепция, заложенная в ARP, заключается в следующем. Сетевой интерфейс имеет аппаратный адрес (48-битное значение для Ethernet или Token ring). Фреймы, которыми обмениваются на аппаратном уровне, должны адресоваться к корректному интерфейсу. Однако TCP/IP испоьзует собственную схему адрессации: 32-битные IP адреса. Знание IP адреса хоста не позволяет ядру послать датаграмму этому хосту. Драйвер Ethernet должен знать аппаратный адрес пункта назначения, чтобы послать туда данные. В задачу ARP входит обеспечение динамического соответствия между 32-битными IP адресами и аппаратными адресами, используемыми различными сетевыми технологиями.

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

    Эффективность функционирования ARP во многом зависит от ARP кэша (ARP cache), который присутствует на каждом хосте. В кэше содержатся Internet адреса и соответствующие им аппаратные адреса. Стандартное время жизни каждой записи в кэше составляет 20 минут с момента создания записи.

    Содержимое ARP кэша можно увидеть с использованием команды arp(8). Опция -a показывает все записи, содержащиеся в кэше:

    bsdi % arp -a
    sun (140.252.13.33) at 8:0:20:3:f6:42
    svr4 (140.252.13.34) at 0:0:c0:c2:9b:26

    48-битные Ethernet адреса приведены в виде шести шестнадцатиричных чисел, разделенных двоеточиями. Дополнительные функции команды arp обсуждаются в разделе главы 4.

    Формат пакета ARP

    На рисунке 4.3 показан формат ARP запроса и формат ARP отклика, в случае использования Ethernet и IP адресов. (ARP можно использовать в других сетей, при этом он способен устанавливать соответствие не только для IP адресов. Первые четыре поля, следующие за полем типа фрейма, указывают на типы и размеры заключительных четырех полей.)

    Рисунок 4.3 Формат ARP запроса или отклика при работе с Ethernet.

    Два первых поля в Ethernet заголовке - поля источника и назначения Ethernet. Специальный адрес назначения Ethernet, состоящий из всех единиц, означает широковещательный адрес. Фреймы с таким адресом будут получены всеми Ethernet интерфейсами на кабеле.

    Двухбайтовый тип фрейма (frame type) Ethernet указывает, данные какого типа, пойдут следом. Для ARP запроса или ARP отклика это поле содержит 0x0806.

    Выражения аппаратный (hardware) и протокол (protocol) используются для описания полей в пакетах ARP. Например, ARP запрос запрашивает аппаратный адрес (в данном случае Ethernet адрес) соответствующий адресу протокола (в данном случае IP адрес).

    Поле hard type указывает на тип аппаратного адреса. Для Ethernet это значение равно единице. Prot type указывает тип адреса протокола, к которому будет приведено соответствие. Для IP адресов используется значение 0x0800. По своему целевому назначению это значение соответствует полю типа во фрейме Ethernet, который содержит IP датаграмму. (См. рисунок 2.1.)

    Два следующих однобайтных поля, hard size и prot size, указывают на размеры в байтах аппаратного адреса и адреса протокола. В ARP запросах и откликах они составляют 6 для Ethernet и 4 для IP адреса.

    Поле op указывает на тип операции: ARP запрос (значение устанавливается в 1), ARP отклик (2), RARP запрос (3) и RARP отклик (4). (Мы поговорим о RARP в .) Это поле необходимо, так как поля типа фрейма (frame type) одинаковы для ARP запроса и ARP отклика.

    Следующие четыре поля: аппаратный адрес отправителя (Ethernet адрес в данном примере), адрес протокола (IP адрес), аппаратный адрес назначения и адрес протокола назначения. Обратите внимание, что в данном случае происходит некоторое дублирование информации: аппаратный адрес отправителя может быть получен как из Ethernet заголовка, так и из ARP запроса.

    Для ARP запроса все поля заполнены, за исключением аппаратного адреса назначения. Когда система получает ARP запрос, который предназначается ей, она вставляет свой аппаратный адрес, меняет местами адреса источника и назначения, устанавливает поле op в значение 2 и отправляет отклик.

    Примеры ARP

    В этом разделе мы воспользуемся командой tcpdump, чтобы посмотреть, как в действительности работает ARP при запуске обычного TCP приложения, например, Telnet. В содержится дополнительная информация о работе программы tcpdump.

    Типичный пример

    Чтобы посмотреть как функционирует ARP, мы запустим команду telnet, чтобы подсоединиться к discard (discard server - сервер, не предоставляющий пользователю никаких услуг) серверу.

    bsdi% arp -a проверяем, что ARP кэш пуст
    bsdi% telnet svr4 discard подсоединяемся к серверу
    Trying 140.252.13.34 ...
    Connected to svr4.
    Escape character is "^]" .
    ^] нажимаем Control и правую квадратную скобку,
    telnet> quit чтобы получить приглашение Telnet и закрыть сессию
    Connection closed.

    Пока осуществляются эти действия, мы запускаем команду tcpdump с опцией -e на другом хосте (sun). Это позволит нам посмотреть аппаратные адреса (48-битные адреса Ethernet).


    arp who-has svr4 tell bsdi
    2 0.002174 (0.0022) 0:0:c0:c2:9b:26 0:0:c0:6f:2d:40 arp 60:
    arp reply svr4 is-at 0:0:c0:c2:9b:26
    3 0.002831 (0.0007) 0:0:c0:6f:2d:40 0:0:c0:c2:9b:26 ip 60:
    bsdi.1030>svr4.discard: S 596459521:596459521 (0)
    win 4096
    4 0.007834 (0.0050) 0:0:c0:c2:9b:26 0:0:c0:6f:2d:40 ip 60:
    svr4.discard>bsdi.1030: S 3562228252:3562228252 (0)
    ack 596459522 win 4096
    5 0.009615 (0.0018) 0:0:c0:6f:2d:40 0:0:c0:c2:9b:26 ip 60:
    bsdi.1030>svr4.discard: . ack 1 win 4096

    Рисунок 4.4 ARP запрос и ARP отклик, сгенерированные при запросе на Telnet соединение.

    %D0%A7%D0%B8%D1%81%D0%BB%D0%BE,%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D0%BE%D0%B5%20%D0%BF%D0%B5%D1%87%D0%B0%D1%82%D0%B0%D0%B5%D1%82%D1%81%D1%8F%20%D0%B2%20%D0%BA%D0%B0%D0%B6%D0%B4%D0%BE%D0%B9%20%D1%81%D1%82%D1%80%D0%BE%D0%BA%D0%B5,%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%20%D0%BD%D0%BE%D0%BC%D0%B5%D1%80%D0%B0%20%D1%81%D1%82%D1%80%D0%BE%D0%BA%D0%B8%20-%20%D1%8D%D1%82%D0%BE%0A%D0%B2%D1%80%D0%B5%D0%BC%D1%8F%20(%D0%B2%20%D1%81%D0%B5%D0%BA%D1%83%D0%BD%D0%B4%D0%B0%D1%85)%20%D0%BA%D0%BE%D0%B3%D0%B4%D0%B0%20%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%20%D0%B1%D1%8B%D0%BB%20%D0%BF%D1%80%D0%B8%D0%BD%D1%8F%D1%82%20%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BE%D0%B9%20tcpdump.%20%D0%92%20%D0%BA%D0%B0%D0%B6%D0%B4%D0%BE%D0%B9%20%D1%81%D1%82%D1%80%D0%BE%D0%BA%D0%B5%0A%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%20%D0%BF%D0%B5%D1%80%D0%B2%D0%BE%D0%B9%20%D1%81%D0%BE%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D1%82%D1%81%D1%8F%20%D1%80%D0%B0%D0%B7%D0%BD%D0%B8%D1%86%D0%B0%20%D0%B2%D0%BE%20%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8%20(%D0%B2%20%D1%81%D0%B5%D0%BA%D1%83%D0%BD%D0%B4%D0%B0%D1%85)%20%D1%81%20%D0%BF%D1%80%D0%B5%D0%B4%D1%8B%D0%B4%D1%83%D1%89%D0%B5%D0%B9%20%D1%81%D1%82%D1%80%D0%BE%D0%BA%D0%BE%D0%B9.%0A%D0%AD%D1%82%D0%BE%20%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D0%B5%20%D0%BF%D1%80%D0%B8%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D1%81%D1%8F%20%D0%B2%20%D1%81%D0%BA%D0%BE%D0%B1%D0%BA%D0%B0%D1%85.%20%D0%9A%D0%B0%D0%BA%20%D0%B2%D0%B8%D0%B4%D0%BD%D0%BE%20%D0%B8%D0%B7%20%D1%80%D0%B8%D1%81%D1%83%D0%BD%D0%BA%D0%B0,%20%D0%B2%D1%80%D0%B5%D0%BC%D1%8F%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83%20%D0%BE%D1%82%D0%BF%D1%80%D0%B0%D0%B2%D0%BA%D0%BE%D0%B9%0AARP%20%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%B0%20%D0%B8%20%D0%BF%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5%D0%BC%20ARP%20%D0%BE%D1%82%D0%BA%D0%BB%D0%B8%D0%BA%D0%B0%20%D1%81%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D1%82%202,2%20%D0%BC%D1%81.%20%D0%9F%D0%B5%D1%80%D0%B2%D1%8B%D0%B9%20TCP%20%D1%81%D0%B5%D0%B3%D0%BC%D0%B5%D0%BD%D1%82%0A%D0%BF%D0%BE%D1%81%D0%BB%D0%B0%D0%BD%20%D1%87%D0%B5%D1%80%D0%B5%D0%B7%200,7%20%D0%BC%D1%81%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%20%D1%8D%D1%82%D0%BE%D0%B3%D0%BE.%20%D0%A2%D0%B0%D0%BA%D0%B8%D0%BC%20%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%BC,%20%D0%B4%D0%BB%D1%8F%20%D0%B4%D0%B8%D0%BD%D0%B0%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B3%D0%BE%20%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F%0A%D0%B0%D0%B4%D1%80%D0%B5%D1%81%D0%B0%20%D1%81%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%D0%BC%20ARP,%20%D0%B2%20%D0%B4%D0%B0%D0%BD%D0%BD%D0%BE%D0%BC%20%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D1%80%D0%B5,%20%D0%BF%D0%BE%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BB%D0%BE%D1%81%D1%8C%20%D0%BC%D0%B5%D0%BD%D0%B5%D0%B5%20%D1%87%D0%B5%D0%BC%203%20%D0%BC%D1%81.

    %D0%98%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B5%20%D0%BD%D0%B0%20%D1%87%D1%82%D0%BE%20%D1%81%D0%BB%D0%B5%D0%B4%D1%83%D0%B5%D1%82%20%D0%BE%D0%B1%D1%80%D0%B0%D1%82%D0%B8%D1%82%D1%8C%20%D0%B2%D0%BD%D0%B8%D0%BC%D0%B0%D0%BD%D0%B8%D0%B5%20%D0%B2%20%D0%B2%D1%8B%D0%B2%D0%BE%D0%B4%D0%B5%20tcpdump:%20%D0%BC%D1%8B%20%D0%BD%D0%B5%0A%D1%83%D0%B2%D0%B8%D0%B4%D0%B8%D0%BC%20ARP%20%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%20%D0%BE%D1%82%20svr4,%20%D0%BA%D0%BE%D0%B3%D0%B4%D0%B0%20%D0%BE%D0%BD%20%D0%BF%D0%BE%D1%81%D1%8B%D0%BB%D0%B0%D0%B5%D1%82%20%D1%81%D0%B2%D0%BE%D0%B9%20%D0%BF%D0%B5%D1%80%D0%B2%D1%8B%D0%B9%20TCP%20%D1%81%D0%B5%D0%B3%D0%BC%D0%B5%D0%BD%D1%82%20(%D1%81%D1%82%D1%80%D0%BE%D0%BA%D0%B0%204).%0A%D0%94%D0%B5%D0%BB%D0%BE%20%D0%B2%20%D1%82%D0%BE%D0%BC,%20%D1%87%D1%82%D0%BE%20svr4%20%D1%83%D0%B6%D0%B5%20%D0%B8%D0%BC%D0%B5%D0%B5%D1%82%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BE%20bsdi%20%D0%B2%20%D1%81%D0%B2%D0%BE%D0%B5%D0%BC%20ARP%20%D0%BA%D1%8D%D1%88%D0%B5,%20%D1%82%D0%B0%D0%BA%20%D0%BA%D0%B0%D0%BA,%20%D0%BA%D0%BE%D0%B3%D0%B4%D0%B0%0A%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0%20%D0%BF%D0%BE%D0%BB%D1%83%D1%87%D0%B0%D0%B5%D1%82%20ARP%20%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81,%20%D0%BF%D0%BE%D0%BC%D0%B8%D0%BC%D0%BE%20%D1%82%D0%BE%D0%B3%D0%BE%20%D1%87%D1%82%D0%BE%20%D0%BE%D0%BD%D0%B0%20%D0%BF%D0%BE%D1%81%D1%8B%D0%BB%D0%B0%D0%B5%D1%82%20ARP%20%D0%BE%D1%82%D0%BA%D0%BB%D0%B8%D0%BA,%20%D0%BE%D0%BD%D0%B0%20%D1%82%D0%B0%D0%BA%D0%B6%D0%B5%0A%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D1%8F%D0%B5%D1%82%20%D0%B0%D0%BF%D0%BF%D0%B0%D1%80%D0%B0%D1%82%D0%BD%D1%8B%D0%B9%20%D0%B0%D0%B4%D1%80%D0%B5%D1%81%20%D0%B8%20IP%20%D0%B0%D0%B4%D1%80%D0%B5%D1%81%20%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%B8%D0%B2%D1%88%D0%B5%D0%B3%D0%BE%20%D0%B2%20%D1%81%D0%B2%D0%BE%D0%B5%D0%BC%20ARP%20%D0%BA%D1%8D%D1%88%D0%B5.%20%D0%AD%D1%82%D0%BE%0A%D0%BB%D0%BE%D0%B3%D0%B8%D1%87%D0%BD%D0%BE,%20%D1%82%D0%B0%D0%BA%20%D0%BA%D0%B0%D0%BA%20%D0%B5%D1%81%D0%BB%D0%B8%20%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%B8%D0%B2%D1%88%D0%B8%D0%B9%20%D1%81%D0%BE%D0%B1%D0%B8%D1%80%D0%B0%D0%B5%D1%82%D1%81%D1%8F%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B0%D1%82%D1%8C%20IP%20%D0%B4%D0%B0%D1%82%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%83,%20%D1%82%D0%BE%0A%D0%BF%D0%BE%D0%BB%D1%83%D1%87%D0%B8%D0%B2%D1%88%D0%B5%D0%BC%D1%83%20%D1%81%D0%BA%D0%BE%D1%80%D0%B5%D0%B5%20%D0%B2%D1%81%D0%B5%D0%B3%D0%BE%20%D0%BF%D1%80%D0%B8%D0%B4%D0%B5%D1%82%D1%81%D1%8F%20%D0%BE%D1%82%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D1%82%D1%8C%20%D0%BE%D1%82%D0%B2%D0%B5%D1%82%20%D0%BD%D0%B0%20%D1%8D%D1%82%D1%83%0A%D0%B4%D0%B0%D1%82%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%83.

    %0A%0A

    в этот раз telnet на IP адрес, а не на имя хоста (hostname)
    bsdi % date ; telnet 140.252.13.36 ; date
    Sat Jan 30 06:46:33 MST 1993
    Trying 140.252.13.36 ...
    telnet: Unable to connect to remote host: Connection timed out
    Sat Jan 30 06:47:49 MST 1993 прошло 76 секунд

    bsdi % arp -a проверяем ARP кэш
    ? (140.252.13.36) at (incomplete)

    На рисунке 4.5 мы видим вывод tcpdump.

    1 0.0 arp who-has 140.252.13.36 tell bsdi
    2 5.509069 (5.5091) arp who-has 140.252.13.36 tell bsdi
    3 29.509745 (24.0007) arp who-has 140.252.13.36 tell bsdi

    Рисунок 4.5 ARP запрос на несуществующий хост.

    Сейчас мы не указываем опцию -e, так как мы уже знаем, что ARP запрос широковещательный.

    Здесь интересно посмотреть, с какой частотой рассылаются ARP запросы: 5,5 секунд после первого запроса и снова через 24 секунды. (Мы рассмотрим тайм-ауты TCP и алгоритм повторных передач более подробно в .) Полное время, показанное в выводе tcpdump, составляет 29,5 секунды. Однако вывод от команды date перед и после команды telnet показывает, что запрос на соединение от Telnet клиента длился в течении 75 секунд. И действительно, мы увидим позже, что большинство BSD реализаций устанавливают ограничение в 75 секунд для завершения запроса на установление TCP соединения.

    Уполномоченный агент ARP

    Уполномоченный агент ARP позволяет маршрутизатору отвечать на ARP запросы в одну сеть, в то время как запрашиваемый хост находится в другой сети. С помощью этого средства происходит обман отправителя, который отправил ARP запрос, после чего он думает, что маршрутизатор является хостом назначения, тогда как в действительности хост назначения находится "на другой стороне" маршрутизатора. Маршрутизатор выступает в роли уполномоченного агента хоста назначения, перекладывая пакеты от другого хоста.

    Для того чтобы лучше описать работу уполномоченных агентов ARP, мы рассмотрим пример. Из рисунка 3.10 видно, что система sun подключена к двум сетям Ethernet. Однако в действительности это не так, в чем можно убедиться, если сравнить этот рисунок с рисунком, который приведен на внутренней стороне обложки. Между sun и подсетью 140.252.1 находится маршрутизатор, который выступает в роли уполномоченного агента ARP, при этом все выглядело так, как будто sun находится в подсети 140.252.1. На рисунке 4.6 показано, что Telebit NetBlazer, названный netb, находится между подсетью и хостом sun.

    Рисунок 4.6 Пример уполномоченного ARP.

    Когда какой-либо другой хост в подсети 140.252.1 (скажем, gemini) хочет послать IP датаграмму хосту sun на адрес 140.252.1.29, gemini сравнивает идентификатор сети (140.252) и идентификатор подсети (1), и если они идентичны, отправляет ARP запрос в верхний Ethernet (на рисунке 4.6) на IP адрес 140.252.1.29. Маршрутизатор netb распознает этот IP адрес как принадлежащий одному из dialup хостов и отвечает, отправив аппаратный адрес этого Ethernet интерфейса в кабель 140.252.1. Хост gemini посылает IP датаграмму в netb по Ethernet, а netb направляет датаграмму в sun по SLIP каналам с дозвоном (dialup). Это делает его прозрачным для всех хостов подсети 140.252.1, так как хост sun действительно находится "позади" маршрутизатора netb.

    Если мы запустим команду arp на хосте gemini после общения с хостом sun, то увидим, что оба эти адреса принадлежат подсети 140.252.1 (netb и sun) и что им соответствует один аппаратный адрес. Как правило, это основная причина, по которой используется уполномоченный агент ARP.

    gemini % arp -a
    появится много строк про хосты из подсети 140.252.1
    netb (140.252.1.183) at 0:80:ad:3:6a:80
    sun (140.252.1.29) at 0:80:ad:3:6a:80

    Еще одна деталь на рисунке 4.6, которую необходимо объяснить, это отсутствие IP адреса под квадратиком, который обозначает маршрутизатор netb (SLIP канал). Почему на обоих концах SLIP канала нет IP адреса, как между bsdi и slip? В разделе главы 3, из вывода команды ifconfig, мы заметили, что адрес назначения SLIP канала 140.252.1.183. NetBlazer не требует наличия IP адресов на каждом конце SLIP канала. (Это позволяет сэкономить несколько столь ценных в настоящее время IP адресов.) Он определяет какой хост посылает пакет в зависимости от того по какому последовательному интерфейсу прибыл пакет, поэтому нет необходимости каждому хосту на SLIP канале использовать уникальный IP адрес для своего канала с маршрутизатором. Все dialup хосты используют адрес 140.252.1.183 в качестве адреса назначения для своих SLIP каналов.

    Уполномоченный агент ARP обеспечивает доставку датаграмм к маршрутизатору sun, однако как это делают другие хосты из подсети 140.252.13? Для направления датаграмм в другие хосты должна использоваться маршрутизация. Где-либо в сети 140.252 должны быть сделаны записи в таблице маршрутизации, поэтому все датаграммы, направляющиеся в подсеть 140.252.13 или в указанные хосты этой подсети, будут направляться на маршрутизатор netb. Этот маршрутизатор знает, как доставить датаграммы в их конечный пункт назначения, отправляя их через маршрутизатор sun.

    Уполномоченный агент ARP также называется смешанным (promiscuous ARP) или расщепленным (ARP hack). Эти имена появились благодаря другому использованию уполномоченных агентов ARP: они применялись для того, чтобы спрятать друг от друга две физические сети между которыми находился маршрутизатор. В этом случае обе физические сети использовали один и тот же идентификатор сети, так как маршрутизатор, находящийся между ними, был сконфигурирован как уполномоченный ARP агент, чтобы отвечать на ARP запросы из одной сети к хостам в другой сети. Эта техника использовалась в прошлом, чтобы спрятать группу хостов с более старой версией TCP/IP на отдельном физическом кабеле. Две причины, по которым приходилось отделять эти "устаревшие" хосты, заключались в том, что, во-первых, они не могли поддерживать разделение на подсети и, во-вторых, использовали старые широковещательные адреса (идентификатор хоста состоял из всех нулевых бит вместо современного стандарта, при котором идентификатор хоста состоит из единичных битов).

    "Беспричинный" ARP

    Другая характеристика ARP, которую стоит рассмотреть - "беспричинный" ARP (gratuitous ARP). Он проявляется, когда хост посылает ARP запрос, основываясь на собственном IP адресе. Обычно это делается, когда интерфейс конфигурируется во время загрузки.

    Если мы запустим tcpdump на хосте sun при загрузке хоста bsdi, то увидим пакет, показанный на рисунке 4.7.

    1 0.0 0:0:c0:6f:2d:40 ff:ff:ff:ff:ff:ff arp 60:
    arp who-has 140.252.13.35 tell 140.252.13.35

    Рисунок 4.7 Пример "беспричинного" ARP.

    (Мы использовали флаг -n программы tcpdump, чтобы напечатать адреса в цифровом десятичном виде вместо имен хостов.) В терминах полей ARP запроса, адрес протокола отправителя и адрес протокола назначения идентичны: 140.252.13.35 (что соответствует хосту bsdi). Адрес источника в заголовке Ethernet, 0:0:c0:6f:2d:40 как показано программой tcpdump, эквивалентен аппаратному адресу отправителя (из рисунка 4.4).

    "Беспричинный" ARP предоставляет две характеристики.

    1. Он позволяет хосту определить, существует ли другой хост с тем же самым IP адресом. Хост bsdi не ожидает отклика на свой запрос, однако если отклик принят, на консоли возникает сообщение об ошибке "обнаружен дублирующий IP адрес с Ethernet адресом: a:b:c:d:e:f". Это предупреждение системному администратору о том, что одна из систем неправильно сконфигурирована.
    2. Если хост, посылающий "беспричинный" ARP, только что изменил свой аппаратный адрес (может быть потому, что хост был выключен, удалена интерфейсная плата и затем хост был перезагружен), этот пакет заставляет другой хост на кабеле, который имеет запись в своем кэше для старого аппаратного адреса, обновить ARP кэш соответствующим образом. Малоизвестный факт о протоколе ARP заключается в том, что если хост получает ARP запрос для IP адреса, который он уже имеет в кэше, содержимое кэша обновляется аппаратным адресом отправителя (Ethernet адресом) из запроса ARP. Это делается для любого запроса ARP, полученного хостом. (Повторим, что ARP запросы широковещательные, поэтому такие действия осуществляются всеми хостами в сети каждый раз при появлении ARP запроса.) описывает приложения, которые используют эту характеристику ARP. Она позволяет запасному (backup) файл-серверу занять место вышедшего из строя сервера с использованием "беспричинного" ARP запроса с запасным аппаратным адресом, однако с тем же IP адресом, который имел вышедший из строя хост. При этом все пакеты, направляемые серверу, вышедшему из строя, будут посланы на запасной сервер, а пользовательские приложения не будут знать о том, что основной сервер вышел из строя.
    К сожалению, авторы затем отказались от этого подхода, так как он зависит от корректности реализации ARP на всех типах клиентов. Существуют различные типы ARP, которые не поддерживают эту спецификацию.

    Наблюдения за всеми системами в подсети, используемой в этой книге, показывает, что SunOS 4.1.3 и 4.4BSD используют "беспричинный" ARP при загрузке, а SVR4 не поддерживает эту характеристику.

    Команда arp

    Мы использовали эту команду с флагом -a, чтобы отобразить все записи ARP кэша. Существуют и другие опции.

    Суперпользователь может использовать опцию -d, чтобы удалить запись из ARP кэша. (Это было сделано перед запуском некоторых примеров, чтобы показать изменения ARP.)

    Записи могут быть добавлены с использованием опции -s. При использовании этой опции необходимо указать имя хоста и Ethernet адрес, IP адрес, соответствующий имени хоста, и Ethernet адрес добавляются в кэш. Подобная запись делается на постоянной основе (она не будет удалена из кэша по тайм-ауту), если только в конце командной строки не будет использовано ключевое слово temp.

    Ключевое слово pub в конце командной строки с опцией -s приведет к тому, что система будет функционировать как ARP агент для этого хоста. Система будет отвечать на ARP запросы для IP адресов, соответствующих имени хоста, при этом ответ будет содержать указанный Ethernet адрес. Если объявленный адрес это адрес самой отвечающей системы, это означает, что система работает как уполномоченный агент ARP для указанного имени хоста.

    Краткие выводы

    ARP это основной протокол, который используется практически во всех реализациях TCP/IP. Обычно его функционирование не зависит от используемых приложений или воли системного администратора. ARP кэш является фундаментом этой работы. Мы использовали команду arp, чтобы просмотреть или модифицировать кэш. Каждая запись в кэше имеет таймер, который используется для удаления незавершенных или завершенных записей. Команда arp отображает модифицированные записи в ARP кэше.

    Мы посмотрели обычное функционирование ARP и специализированные версии: уполномоченный агент ARP (когда маршрутизатор отвечает на ARP запросы для хостов, находящихся на другом интерфейсе маршрутизатора) и "беспричинный" ARP (посылающий ARP запросы для своего собственного IP адреса, обычно во время загрузки).

    Упражнения

    1. Вернемся к команде, которую мы исполнили, чтобы получить вывод, показанный на рисунке 4.4. Что произойдет, если после того как мы проверили локальный ARP кэш и он оказался пустым, мы введем команду

      bsdi % rsh svr4 arp -a

      чтобы проверить, что ARP кэш также пуст на хосте назначения? (Эта команда исполнит команду arp -a на хосте svr4.)

    2. Опишите тест, который позволит определить, корректно ли обрабатывает определенный хост "беспричинные" ARP запросы.
    3. Шаг номер 7 в разделе может занять определенное время (миллисекунды), потому что пакет отправлен и ARP ожидает ответа. Как Вы думаете, обработает ли ARP несколько датаграмм, которые прибыли от IP на тот же адрес назначения в течение этого периода времени?
    4. В конце раздела мы упомянули, что RFC Host Requirements и Berkeley реализации отличаются с точки зрения обработки тайм-аутов для активных записей ARP. Что произойдет, если клиент Berkeley постарается установить контакт с сервером, который был выключен и из него была удалена плата Ethernet? Изменится ли что-нибудь, если сервер выдаст "беспричинный" ARP запрос при загрузке?


    Есть вопросы?

    Сообщить об опечатке

    Текст, который будет отправлен нашим редакторам: