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

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

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

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

Чтобы понять, как работает anycast необходимо иметь представления о том, как работает маршрутизация в сетях использующих протокол IP.
Основы маршрутизации.

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

Часто, два удаленных хоста в Интернете связаны между собой избыточными связями. Порой, пакет данных отосланный от хоста A теоретически может достичь хоста Б десятками различных путей. Совсем не факт, что если пакет от хоста А прошел через 3 определенных маршрутизатора, то обратный пакет от хоста Б придет через те же 3 маршрутизатора. Наличие избыточных связей дает 2 основных преимущества, первое – выход из строя одного из каналов связи не будет означать недоступности для группы хостов, второе – нагрузка при передаче данных может распределяться между различными каналами, в результате общая пропускная способность сети возрастает.

В процессе принятия решения, через какой из возможных путей переслать пакет маршрутизатор руководствуется, прежде всего, адресом назначения пакета и логикой маршрутизации. Обычно, маршрутизатор не руководствуется информацией об источнике (кто послал пакет), протоколе, портах и прочей информацией заголовков пакета данных. Но, например, у маршрутизаторов cisco есть особая фича, так называемый PBR (Policy-Based Routing) http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfclass.html#wpxref35843

, однако, это скорее исключение, чем правило.

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

Вопрос: пакет на хост 192.168.0.2 уйдет с верхнего или нижнего интерфейса?

Правильный ответ – с верхнего. Почему? Потому, что при выборе лучшего маршрута последовательно срабатывают следующие 3 правила.

1) Если длины префиксов подсетей, в которые попадает IP адрес хоста назначения разные, то выбирается маршрут с самым длинным префиксом.

2) Если префиксы равны, то выбирается маршрут с более приоритетным протоколом маршрутизации.

3) Если и префиксы равны и протоколы одинаковые, то срабатывает внутренняя метрика протокола маршрутизации.

В данном примере сработало первое правило.

А теперь немного подробней. Что такое префикс? Префикс это метод описания подсети. Префикс состоит из двух частей, левая – идентификатор подсети, правая – длина этого идентификатора.

Самый длинный префикс имеет длину 32 при этом левая часть такого префикса, по сути, является IP адресом. Самый короткий префикс имеет длину 0, при этом левая часть префикса также равна 0, такой префикс записывается как 0/0 или 0.0.0.0/0, и в него попадают все возможные IP адреса.

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

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

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

Несколько слов о приоритетах протоколов маршрутизации. Статическая маршрутизация имеет наивысший приоритет, различные протоколы динамической маршрутизации имеют каждый свой приоритет. В примере, приведенном выше, если бы префиксы подсетей совпадали, то пакет, согласно второму правилу, был бы передан через нижний интерфейс. Область действия приоритетов протоколов маршрутизации локальна для каждого маршрутизатора. Если маршрутизатор A получил маршрут для сети 192.168.0.0/28 через статический маршрут, а маршрутизатор B получил маршрут 192.168.0.0/28 от маршрутизаторов A и C по OSPF, то маршрутизатор B в выборе приоритетов руководствуется метриками OSPF. То есть маршрутизатору не важно, как соседи узнали о том либо ином маршруте, важно только то, как и что он о нем узнал.

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

Различные протоколы динамической маршрутизации вычисляют метрики различными способами. Для примера поверхностно рассмотрим критерии выбора маршрута протоколом динамической маршрутизации OSPF.

OSPF - Open Shortest Path first, вольно это можно перевести как лучший (маршрут) - с наименьшим доступным путем. Это значит, что в случае равнозначных (по скорости) связей между узлами сети выбирается маршрут с наименьшим количеством маршрутизаторов через которые он будет следовать. На длину пути автоматически влияет скорость, с которой работает интерфейс. Например, если интерфейс работает на скорости 100Мбит/c, то путь до соседа будет равен 1, если 10Мбит/c, то он будет равен 10 и т.д. Повлиять на дистанцию можно и ручками. Для этого надо просто прописать на нужном интерфейсе параметр bandwith (емкость), который не влияет на физическую скорость интерфейса, но влияет на процесс принятия решения маршрутизации.

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

Правило номер 1.

Задумайтесь, как описать, где расположены выходы из вашей сети, в которой крутится, допустим, тот же OSPF. Естественно, на маршрутизаторах, где они (выходы) расположены надо прописать маршрут по умолчанию (default gateway). В маршрут по умолчанию должны включаться все возможные IP адреса. Как описывается default gateway в префиксах? Вот так - 0/0. Любой IP адрес попадает в префикс 0/0, однако пакеты на default gateway должны кидаться только в том случае, если другие маршруты не срабатывают (адрес назначения не попадает ни в один другой существующий префикс маршрутизации). Default gateway – тот же маршрут, он так же передается между маршрутизаторами протоколом OSPF, следовательно, маршруты с более длинным префиксом всегда делаются более приоритетными, для того, чтобы схема с маршрутом по умолчанию работала.

Правило номер 2.

Метрики различных протоколов маршрутизации не соизмеримы. Гораздо проще дать приоритет одному протоколу маршрутизации над другим, чем, не понятно как, сопоставлять приоритеты метрик различных протоколов маршрутизации.

Правило номер 3.

Оно третье только потому, что первые 2 места уже заняты J

Для того, чтобы понять как организовывается anycast в IP сетях, понимания описанных выше принципов работы маршрутизации достаточно.
Как работает anycast.

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

Допустим, работает тот же OSPF, при этом линки между маршрутизаторами имеют одинаковую пропускную способность и параметр bandwith нигде не сконфигурирован. Критерием выбора маршрута в данном случае, является только количество маршрутизаторов, через которые должны пройти пакеты. Стрелками разного цвета указаны пути пакетов для того, чтобы достичь сервера.

А теперь, для этой же сети включим еще один физический сервер с таким же IP в маршрутизатор F. Этот маршрутизатор, в свою очередь заставим анонсировать тот же префикс через себя.

Очевидно, что в этом случае, часть трафика пойдет на один сервер, часть на другой.

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

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

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

В такой схеме есть только одна засада. Допустим, пользователь, работающий через маршрутизатор B качает по ftp большой файл с сервера, работающего через маршрутизатор А. В это время связь между А и B прерывается. Если бы не было anycast-а, таблицы маршрутизации перестроились бы таким образом, что пакеты пошли бы в обход, но все равно, достигли бы сервера работающего через A, и закачка бы не прервалась. В случае с anycast-ом пользователь переключится на сервер, работающий через маршрутизатор F. Так как ftp на транспортном уровне использует tcp, который ориентирован на сессию, то закачка для пользователя прервется. Я не буду детально объяснять, почему это так, так как это выходит за рамки статьи. В целом же, относительно возможности нормального использования ориентированных на сессию протоколов со схемами anycast-а, с глобальной точки зрения на функционирование Интернет, мнения специалистов разделились. Одни считают, что это не целесообразно, так как чревато частыми “обрывами” (причем, мало кто способен будет нормально объяснить, почему раньше НЕ БЫЛО НИ ЕДИННОГО ОБРЫВА, а сейчас они есть J), другие же говорят, что заметных “обрывов” не будет, и доказывают это на практике.

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

Действительно, допустим, вы хотите построить систему с тремя anycast серверами, живущими на одинаковых IP адресах, при этом объявили в маршрутизации 2 из них с префиксом длиной 28, а третий с префиксом длиной 29. Тогда схема не будет работать, так как все пакеты будут маршрутизироваться на третий маршрут. Если же вы прописали третий маршрут с префиксом длиной 27, то пакеты будут идти только на первые два сервера, третий выпадет из схемы.

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

Теперь вернемся к нашим баранам, то есть корневым DNS серверам.
DNS Root сервера и anycast.

Принцип работы с anycast в глобальном масштабе такой же, как и в локальных сетях. В глобальной сети Интернет в качестве протокола динамической маршрутизации используется протокол BGP.

В целом описывать, как все устроено, и какие проблемы могут возникнуть при включении anycast-а очень сложно. Сам по себе протокол BGP не прост, а при включении anycast возникают дополнительные не совсем приятные моменты. Существует RFC http://tools.ietf.org/html/rfc4786, которые описывают лучшие практики при организации anycast в глобальных масштабах.

Чтобы определить к какому из корневых anycast серверов идут запросы, адресованные на тот либо иной anycast адрес корневого DNS сервера, можно использовать команду.

dig +norec @X.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT

Где X – буква от A до M для каждого из 13-ти anycast IP адресов серверов.

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

Хотелось бы осветить различные топологии, используемые различными организациями, ответственными за корневые сервера. Прежде, чем описывать какие топологии используется необходимо ввести 2 понятия anycast DNS серверов. Существуют, так называемые, локальные root anycast сервера и глобальные root anycast сервера. Глобальные сервера – это сервера которые доступны в глобальных пределах, то есть теоретически всем в Интернет, хотя, благодаря регуляциям метриками BGP каждый из них доступен только из определенных мест. Локальные сервера доступны только клиентам нескольких ближайших к ним провайдеров. Регулированием того, какой это сервер глобальный или локальный занимается протокол BGP. Согласно тому, какие сервера (локальные или глобальные) и в какой пропорции используются при организации anycast, различают 3 схемы.

Единообразная (flat) – состоит только из глобальных серверов, используется для J-root серверов.

Иерархическая (hierarchical) состоит из нескольких географически близко расположенных глобальных серверов и множества локальных серверов используется для F-root серверов.

Гибридная (hybrid) состоит из географически распределенных глобальных серверов и также распределенных локальных серверов используется для K-root серверов.

Вот, например, как выглядит картина глобального местоположение для k-root серверов c IP адресом 193.0.14.129, которую администрирует RIPE www.ripe.net (гибридная схема).

И для f-root с IP адресом 192.5.5.241, которую администрирует Internet Systems Consortium, Inc. www.isc.org (иерархическая схема).

Как видите, среди различных организаций ответственных за корневые сервера различные подходы. Каждая из схем эффективна, какая из них более эффективна вопрос до конца не определенный.

Согласно всем отчетам, результаты тестирования подтверждают эффективность работы anycast для root DNS серверов в глобальном режиме, проблемы при работе DNS с использованием tcp не существенны.

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

На текущий момент всего в мире 150 root DNS серверов, что более чем на порядок больше, чем первоначальное число - 13. Более подробную информацию о текущем состоянии дел по корневым серверам можно узнать тут http://www.root-servers.org/

Тот факт, что сервера географически распределены, делает DoS атаку на них более сложной. Бот сеть, которая сможет вывести из строя все корневые сервера также должна быть глобально распределенной. Ведь, если допустим, хосты атакующей бот сети будут сконцентрированы в основном в Европе, жители Южной Америки даже не будут подозревать о том, что на корневые DNS проводится атака.

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

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