Опубликован: 30.07.2013 | Доступ: свободный | Студентов: 1714 / 60 | Длительность: 24:05:00
Лекция 7:

Приложения протокола розыска соседей

Аннотация: Вещание наугад — anycast. Автоматическая настройка узлов IPv6. Обнаружение конфликтов адресов. Распространение конфигурационных сведений маршрутизаторами.

Пересмотр типов вещания IPv6. Вещание наугад — anycast

Поработав над розыском соседей, мы можем пересмотреть типы вещания в IPv6. Прежде всего, что произошло с широковещанием? До сих пор мы старательно избегали этой темы. Однако теперь мы убедились, что необходимость в широковещании полностью отпала благодаря обязательной поддержке группового вещания. Широковещание IPv4 опиралось на широковещание канального уровня, а с ним мы активно боремся, чтобы не расходовать впустую ресурсы сети. Обратиться же ко всем узлам IPv6 в определенной зоне всегда можно с помощью общепринятой группы "все узлы" (FF0x::1). Итак, в IPv6 нет широковещания; его функции выполняет групповое вещание.

А когда нет широковещания, то не нужны и особые широковещательные адреса. В частности, идентификатор интерфейса FFFF:FFFF:FFFF:FFFF (все биты установлены) никоим образом не зарезервирован.

Это не значит, что такой идентификатор можно свободно использовать. Чтобы понять, какие с ним связаны сложности, проанализируйте его с позиций модифицированного формата EUI 64 (§2.7). (Подсказка: обратите внимание на значения битов U/L и I/G в нем.)

Групповое вещание полезно для протоколов не только служебных, но и прикладных. Оно выручает в тех случаях, когда один пакет надо с минимальными затратами разослать нескольким узлам. Например, сервер NTP может передавать "сигналы точного времени" сразу группе клиентов; клиент DHCP может обратиться одним запросом к группе серверов и получить несколько предложений, а затем выбрать среди них наиболее подходящее.

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

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

Также групповое вещание совершенно бессильно в протоколах, работающих поверх TCP. Тем не менее, сама концепция сетевой группы, когда за одним адресом стоят несколько узлов (точнее, интерфейсов), сохраняет свое значение и в этом случае. Скажем, в крупной организации можно было бы назначить всем серверам DNS или SMTP один "волшебный" адрес X, так чтобы клиент, независимо от местоположения в сети и не меняя настроек, всегда обращался бы к ближайшему серверу (см. рис. 6.1). С точки зрения источника пакета, это будет вещание наугад (anycast), по принципу "кому попало".

Идея anycast для DNS

Рис. 6.1. Идея anycast для DNS

Тем не менее, роль случайности в этом типе вещания не так велика, как кажется источнику. Для простых протоколов, где весь сеанс состоит из обмена парой пакетов UDP по схеме "запрос-ответ", действительно неважно, в какой именно узел anycast попадет запрос. Между тем, TCP не играет в кости: для его работы надо, чтобы пакеты данного соединения попадали в один и тот же узел anycast хотя бы при условии постоянной конфигурации сети. Получается оксюморон: вещание наугад должно быть воспроизводимым (см. рис. 6.2).

 Anycast должен быть воспроизводимым

Рис. 6.2. Anycast должен быть воспроизводимым

Примером простого протокола "запрос-ответ" мог бы служить DNS поверх UDP, если бы его стороны вообще не поддерживали транспорт "виртуальная цепь" при поддержке TCP [RFC 5966]. Но, как мы помним, поддержка этого транспорта важна для передачи длинных сообщений DNS. Так что даже DNS требует от вещания наугад воспроизводимости.

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

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

В первом случае задачу можно решить обычной настройкой маршрутов в сети. Для простоты положим, что источник — это хост, у которого есть только маршрутизатор по умолчанию. По условию задачи, источник — не сосед ни одному из узлов anycast, а значит, первым шагом пакет попадет на маршрутизатор по умолчанию. Если у того будет маршрут для адреса anycast X в сторону ближайшего узла anycast N, то следующим шагом пакет достигнет его или хотя бы приблизится к нему и т.д. То есть достаточно выстроить на маршрутизаторах цепочку маршрутов, которая приведет пакет к ближайшему узлу anycast, как показано на рис. 6.3. Принципиально это ничем не отличается от процесса маршрутизации в сложной сети, где к данному адресату можно проложить более одного пути и потому пакеты от разных источников ходят к нему через совершенно разные участки сети. Следовательно, и осуществить такую схему можно теми же инструментами: статическими маршрутами или протоколом динамической маршрутизации.

Трасса к адресу anycast

Рис. 6.3. Трасса к адресу anycast
Все так просто, пока у каждого маршрутизатора один маршрут на данный адрес anycast. Если же маршрутизатор поддерживает распределение нагрузки по нескольким путям, то придется каким-то образом позаботиться, чтобы все пакеты одного сеанса приходили на один и тот же узел anycast. Однако мы знаем, к тому же, что пакеты одного сеанса должны идти по одному пути во избежание нежелательных побочных эффектов, таких как переупорядочение. В точности та же задача возникает и при обработке индивидуального трафика, так что маршрутизатору не придется делать исключений для пакетов anycast. Например, будет достаточно выбрать алгоритм балансировки, в котором выбор маршрута есть однозначная функция от адреса источника пакета. А это автоматически обеспечит попадание пакетов одного сеанса в один и тот же узел anycast.

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

Согласно первому из них, маршрутизатор должен полагать, что адрес X — "на канале". Как сообщить эту информацию маршрутизатору, зависит от реализации. К примеру, можно назначить каналу между маршрутизатором и узлом anycast префикс X/64. Так или иначе, маршрутизатор проведет розыск адреса X, а узел anycast откликнется и получит пакет.

Второй подход состоит в том, чтобы каждому узлу anycast J назначить, помимо адреса X, обычный индивидуальный адрес A_J. Тогда в таблице маршрутов последнего маршрутизатора достаточно будет создать маршрут X\to A_N, и по нему пакет достигнет узла anycast N. В этой схеме адрес A_J вполне может быть внутриканальным, а хотя бы один такой адрес — это обязательный атрибут всякого интерфейса IPv6 (см. §2.5); так что назначать дополнительные адреса только ради работы anycast не придется. Сам же адрес X можно назначить любому сетевому интерфейсу узла, включая "петлю", как это показано на рис. 6.4.

 Последний шаг к адресу anycast

Рис. 6.4. Последний шаг к адресу anycast
Сергей Субботин
Сергей Субботин

"Теоретически канал с адресацией EUI 64 может соединить порядка 2^63 "

запись вида 2^63  не понятна и отнимает время на попытку ее осмыслить.

ее можно заменить например на записи вида  264  или 1,8 * 1019

 

Павел Афиногенов
Павел Афиногенов

Курс IPv6, в тексте имеются ссылки на параграфы. Разбиения курса на параграфы нет.