Опубликован: 30.07.2013 | Уровень: для всех | Доступ: платный
Лекция 7:

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

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

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

Рис. 6.5. Сеть выбирает узел anycast в зависимости от точки подключения хоста

Перейдем теперь ко второму случаю, когда источник и все узлы anycast — соседи по какому-то каналу. В этом случае трудно сказать, какой из узлов anycast ближе к источнику, так что пусть это будет настоящее вещание наугад, когда первичный выбор узла anycast происходит случайно. Тем не менее, после случайного выбора должен идти воспроизводимый этап передачи пакетов. Решим ли мы и эту задачу уже доступными нам средствами?

Допустим, что источник по-прежнему не подозревает об особенностях адреса X и работает с ним, как с обычным индивидуальным адресом. По условию задачи, адрес X — "на канале". Поэтому источник первым делом проведет розыск соседа X, направив вызов NS группе искомого узла Г(X), как мы обсудили в §5.1. Если наши узлы anycast заранее вступят в эту группу, то все они, в идеале, получат NS и ответят на него объявлениями NA. В результате источник получит несколько объявлений NA об одном и том же сетевом адресе цели X, но все они будут с разными канальными адресами, как показано на рис. 6.6.

 Anycast в пределах канала

Рис. 6.6. Anycast в пределах канала

Потенциально эти объявления могут состязаться за запись в кэше NC источника, меняя ее непредсказуемым образом. Поэтому нам надо позаботиться, чтобы узлы anycast не воевали между собой. Гарантией мира будет сброшенный флаг O ( O = 0) в их объявлениях NA насчет адреса цели X. Тогда в кэше NC закрепится канальный адрес из объявления, пришедшего самым первым. Последующие объявления станут переводить запись в состояние ПРОСРОЧЕННАЯ, но она будет возвращаться в состояние ДОСТУПНАЯ, не меняя канального адреса, благодаря процедуре NUD. Таким образом, вещание наугад будет воспроизводимым и в этом случае.

Обратите внимание на прямое сходство между механизмами ND proxy и anycast [§7.2.8 RFC 4861].

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

Пока что в нашей схеме узлы anycast отвечают на каждый вызов NS "хором", а это приведет к пикам нагрузки на канал. Чтобы сгладить эти пики, пусть каждый узел anycast задерживает объявление NA на случайное время, от 0 до заданного потолка1 Параметр MAX_ANYCAST_DELAY_TIME, 1 с [§10 RFC 4861]. [§7.2.4 RFC 4861].

По-хорошему, параметр MAX_ANYCAST_DELAY_TIME должен быть меньше параметра RETRANS_TIMER, чтобы оставить немного времени на передачу по каналу, но в §10 RFC 4861 их значения совпадают.

С другой стороны, если бы узлы anycast отвечали на вызов NS без искусственной задержки, это позволило бы источнику выбрать ближайший или наименее загруженный узел, так как выигрывает ответ NA, пришедший первым.

А что произойдет, если выбранный узел anycast через какое-то время станет недоступен, скажем, его просто выключат? Тогда источник вычистит запись об адресе X из NC благодаря NUD, и цикл розыска повторится с начала. В результате источник переключится на другой, доступный узел anycast. Так оказывается, что вещание наугад в рамках одного канала открывает путь не только к распределению нагрузки, но и к резервированию.

Итак, мы рассмотрели два независимых сценария с вещанием наугад. Можно ли их объединить, чтобы охватить все возможные случаи? Конечно! Если мы поместим между источником и каналом с узлами anycast маршрутизатор, как показано на рис. 6.7, то выбирать узел anycast придется маршрутизатору, но он с этой задачей вполне справится. Ведь выбор узла anycast по адресу ничем не отличается от обычного розыска соседа. Однако у гибридного сценария есть важное отличие от сценария "все на одном канале": если несколько источников станут обращаться по адресу anycast через один и тот же маршрутизатор, то все обращения пойдут на один и тот же узел anycast. В этом случае распределения нагрузки не произойдет.

Anycast на канале через маршрутизатор

Рис. 6.7. Anycast на канале через маршрутизатор

Остался последний вопрос касательно вещания наугад: какова структура "волшебного" адреса anycast? Возникнет ли у нас новый тип адреса IPv6? Нет, не возникнет. "Построенная" нами схема вещания наугад в IPv6 явно требует, чтобы адрес anycast ничем не отличался от индивидуального адреса. Только при этом условии вещание наугад можно вести на основе уже доступных механизмов, маршрутизации и ND. Узнать, что данный адресanycast, можно только из настроек узла, которому он назначен, и только такой узел работает с адресом anycast чуть иначе.

"Разрабатывая" вещание наугад, мы почти не ограничивали себя деталями IPv6. Поэтому вещать наугад по той же схеме можно и в среде IPv4, с точностью до замены ND на ARP [RFC 1546]. Вещание наугад уже пробовали использовать в DNS [RFC 3258].

О назначении общепринятых адресов anycast в IPv6 см. §6.1 и [RFC 2526].

Некоторые реализации не поддерживают передачу пакетов с адресом источника anycast2 http://www.freebsd.org/cgi/man.cgi?query=ifconfig ,3 http://technet.microsoft.com/en-us/library/cc759104%28WS.10%29.aspx хотя такие пакеты вполне имеют право на существование, если они идут в ответ, а не открывают сетевой диалог. Единственная их проблема в том, что адрес источника потенциально указывает на более чем один сетевой интерфейс. Тем не менее, в каждом конкретном случае эта неоднозначность устраняется теми же механизмами, что обеспечивают воспроизводимости anycast. Обсудите самостоятельно, можно ли считать применение адреса обратной связи ::1 особым случаем anycast.

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

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

Сергей Субботин
Сергей Субботин

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

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

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

 

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

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

Александр Худышкин
Александр Худышкин
Россия
Константин Второв
Константин Второв
Россия, Бокситогорск, ЛГОУ им. А.С.Пушкина, 2003