5.26 Прокси ARP
Предположим, что в сети нельзя использовать смежные номера. Например, 128.36.4.0 и 128.36.20.0 совместно используют носитель. В этом случае хосты локальной сети можно конфигурировать с маской 255.255.0.0, т.е. без выделения подсетей. Затем хосты смогут использовать ARP для всех точек назначения сети 128.36. Этот метод прекрасно подходит для сетей с совместным использованием носителя, но что делать с трафиком в подсеть сети 128.36, которая не принадлежит общей локальной сети?
Маршрутизатор локальной сети будет управлять внешним трафиком в том случае, если он поддерживает прокси (прокси иногда называют посредником. — Прим. пер.) ARP (Proxy ARP). При обнаружении запросов ARP, направляемых в точки назначения, которые являются для локальной сети внешними, маршрутизатор пошлет ответ ARP, содержащий физический адрес самого маршрутизатора. Если в локальной сети несколько маршрутизаторов, выбирается тот, у которого будет наилучший путь для ответа на запрос о точке назначения. Хосту потребуется заключить датаграмму в кадр и переслать ее маршрутизатору, который перешлет ее дальше.
5.27 Многоадресные рассылки
Широковещательные рассылки в IP позволяют доставить датаграмму на все системы сети или подсети. Вариант с большей избирательностью называется многоадресной (multicasting) рассылкой. В этом случае датаграммы пересылаются группе систем (см. рис. 5.16).
Рис. 5.16. Распространение датаграммы в многоадресной рассылке
Многоадресные рассылки в IP — очень полезный сетевой инструмент. Например, одно сообщение может использоваться для одновременного обновления конфигурационных параметров однородной группы хостов или для задания статуса группы маршрутизаторов. Многоадресные рассылки служат основой приложений для пользовательских конференций.
Для многоадресной рассылки используются IP-адреса класса D, формат которых представлен на рис. 5.17. Определен протокол для стандартной многоадресной рассылки, однако число поддерживающих этот протокол хостов и маршрутизаторов в настоящее время ограничено. Возможно, через несколько лет это положение изменится.
Рис 5.17. Адрес класса D для многоадресной рассылки в IP
5.27.1 Группы многоадресной рассылки
Группа многоадресной рассылки (multicast group) — это набор систем, которым присвоен IP-адрес многоадресной рассылки. Члены группы продолжают использовать собственные IP-адреса, однако они имеют возможность принимать данные, посланные в многоадресной рассылке. Любая система может принадлежать нескольким группам многоадресной рассылки или ни одной из них.
Адреса класса D для многоадресных рассылок находятся в диапазоне номеров от 224 до 239. Некоторые IP-адреса многоадресных рассылок являются постоянными (они перечислены в RFC о присвоенных номерах Интернета). К таким адресам относятся:
224.0.0.1 Все хосты локальной подсети
224.0.0.2 Все маршрутизаторы локальной подсети
224.0.0.5 Все маршрутизаторы, поддерживающие протокол Open Shortest Path First (OSPF)
Многоадресные рассылки могут применяться для временной группы систем, создаваемой или ликвидируемой по мере надобности, например для аудио- или видеоконференций.
Хост должен поддерживать несколько определенных функций, чтобы участвовать в одной или нескольких группах многоадресных рассылок:
■ Реализацию команды для объединения с многоадресной группой и идентификации интерфейса, который будет отслеживать соответствующие адреса
■ Распознавание на уровне IP многоадресной рассылки для входящих и исходящих датаграмм
■ Кроме того, должна существовать команда, позволяющая хосту исключить себя из группы многоадресной рассылки
Многоадресные рассылки не ограничиваются только локальными сетями. Маршрутизаторы с программным обеспечением для таких рассылок способны распространять датаграммы IP среди систем интернета.
Для более эффективного выполнения рассылки маршрутизатор должен знать, принадлежит ли хост локальной сети одной из многоадресных групп. Кроме того, маршрутизаторам необходимо обмениваться информацией между собой для определения многоадресных групп в удаленных сетях, куда должны направляться датаграммы.
Хосты используют протокол обслуживания групп Интернета (Internet Group Management Protocol — IGMP) для отчета о своем членстве в группе перед ближайшим маршрутизатором, поддерживающим многоадресные рассылки. Такой отчет посылается по IP-адресу многоадресной рассылки, присвоенному данной группе. Маршрутизатор не транслирует такой отчет вне пределов локальной сети, поэтому он будет услышан только маршрутизаторами и другими членами локальной группы.
Так как протокол IGMP предполагает полноту информации о членстве в группе, то он разрешает маршрутизаторам периодически опрашивать хосты о членстве в различных текущих группах. Опрос проводится по IP-адресу многоадресной рассылки 224.0.0.1 на все хосты.
5.27.2 Трансляция многоадресных рассылок в адреса Ethernet и FDDI
Физическим интерфейсам локальных сетей Ethernet и FDDI могут присваиваться один или несколько адресов для многоадресных рассылок. Это логическое присваивание предполагает выбор из нескольких подходящих для этого значений, что существенно упрощает трансляцию IP-адресов многоадресных рассылок в физические адреса таких рассылок. Отметим, что для этого не нужен протокол ARP.
Для локальных сетей Ethernet и FDDI применяются следующие правила:
■ Первые 3 октета физического адреса для многоадресной рассылки имеют значение 01-00-5E.
■ Следующий далее бит должен быть установлен в 0, а последние 23 бита должны иметь значение младших 23-х битов IP-адреса многоадресной рассылки.
Такое отображение показано на рис. 5.18:
■ Последние 23 бита IP-адреса многоадресной рассылки отмечены как "х". Эти биты копируются в младшие биты физического адреса многоадресной рассылки.
■ Отмеченные символами "?" позиции IP-адреса многоадресной рассылки могут быть заполнены произвольными битами. Они не копируются в физический адрес многоадресной рассылки.
Рис. 5.18. Отображение части IP-адреса на физический адрес
Таким образом, три IP-адреса многоадресной рассылки
11100000 00010001 00010001 00010001
11100000 10010001 00010001 00010001
11100001 10010001 00010001 00010001
будут отображаться на один и тот же физический адрес многоадресной рассылки:
00000001 00000000 01011110 00010001 00010001 00010001
Интерфейсы систем, принадлежащих одной из трех групп, будут реагировать на многоадресные рассылки в своих группах. Однако каждый из хостов на уровне IP будет отбрасывать (игнорировать) посторонние многоадресные рассылки.
Хорошим способом исключения дополнительной обработки является выбор адресов многоадресных рассылок, в которых в позициях "?" стоят нули. При этом все равно остается 2²³ (примерно 9 млн.) адресов для многоадресных рассылок.
5.27.3 Трансляция адресов многоадресных рассылок в адреса Token-Ring
К сожалению, рассмотренную выше схему для Ethernet и FDDI почти никогда нельзя применить в Token-Ring (по крайней мере, на момент написания этой книги), поскольку многие аппаратные интерфейсы Token-Ring не могут быть сконфигурированы на произвольные адреса многоадресных рассылок. Следовательно, остается применить один из трех методов трансляции (в зависимости от оборудования):
■ Вставить 23 бита IP-адреса многоадресных рассылок (этот метод рассмотрен выше)
■ Выбрать и использовать один из функциональных (functional) адресов Token-Ring
■ Применить широковещательную рассылку по всему кольцу Token-Ring
Существует 31 функциональный физический адрес. Они применяются для идентификации систем со специальными свойствами (например, мостов, концентраторов кольцевых подключений или мониторов ошибок в кольце). При выборе второго метода многоадресную рассылку нужно направить по функциональному физическому адресу:
03-00-00-20-00-00
Когда станция получит кадр, содержащий датаграмму многоадресной рассылки, по IP-адресу будет проверено, действительно ли станция является членом группы многоадресной рассылки.
Поскольку один функциональный адрес применяется для всех адресов многоадресных рассылок, такой метод не очень эффективен. Однако он гораздо лучше, чем третий вариант, когда используется широковещательная рассылка по всем станциям.
5.28 Дополнительная литература
Классы адресов определены в стандарте IP RFC 791. Выделение подсетей описывается в RFC 950, а формирование суперсетей — в RFC 1519. Широковещательные рассылки рассмотрены в RFC 919 и RFC 922.
