-g

Вк

-Q

-Q

10 узлов

Префикс поставщика услуг

-—-Н

Далее начинается самый сложный этап — распределение полученного от поставщика услуг адресного пула S между четырьмя сетями клиента. Прежде всего, администратор решил назначить для самой большой сети (Ethernet на 600 узлов) весь пул адресов 131.57.8.0/22, полученный от поставщика услуг (рис. 16.17). Номер, назначенный для этой сети, совпадает с номером сети, полученным от поставщика услуг. А как же быть с оставшимися тремя сетями? Администратор учел, что для сети Ethernet требуется только 600 адресов, а из оставшихся 624 «выкроил» сеть Token Ring 131.57.9.0/24 на 250 адресов. Воспользовавшись тем, что для Token Ring требуется только 200 адресов, он «вырезал» из нее два участка: для сети DMZ 131.57.9.16/28 на 16 адресов и для связывающей сети 131.57.9.32/30 на 4 адреса. В результате все сети клиента получили достаточное (а иногда и с избытком) количество адресов.

0000 00001111 11110000 00001111 1111 0000 00001111 1111 00010000 00011111 1111 1111 0010 0000 0010 0011 0000 0000

/

(16 адресов)

Token Ring

^ (256-16-4 адресов)

Соединительная сеть (4 адреса)

Л

у Ethernet

г (1024-256 адресов)

Рис. 16.17. Планирование адресного пространства для сетей клиента

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

После конфигурирования сетевых интерфейсов должны быть созданы таблицы маршрутизации маршрутизаторов R1 и R2 клиента. Они могут быть сгенерированы автоматически или с участием администратора. Таблица маршрутизации маршрутизатора R2 соответствует табл. 16.11.

Таблица 16.11. Таблица маршрутизации маршрутизатора R2 Адрес назначенияМаскаАдрес следующего маршрутизатораАдрес выходного интерфейсаРасстояние 131.57.8.0255.255.252.0131.57.8.2131.57.8.2Подключена 131.57.9.0255.255.255.0131.57.9.1131.57.9.1Подключена 131.57.9.16255.255.255.240131.57.8.1131.57.8.21 «04 МП ООore orr orr ого4 04 СП О 44 0 4 СП О О4

600 узлов

131.57.8.1/22131.57.9.33/30 131.57.9.34/30 131.57.9.32/302 узла-131.57.9.17/28WWW

I—J LJ LJ LJ У

^^^е

DMZ

131.57.9.16/28

-g

?g

131.57.9.1/24Token Ring 131.57.9.0/24

Ethernet

R2 ___131.57.8.2/22 131.57.8.0/22

200 узлов

g g

10 узлов

Сеть клиента - S

Рис. 16.18. Сконфигурированная сеть клиента

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

Пусть, например, на маршрутизатор R2 поступает пакет с адресом назначения 131.57 В результате просмотра таблицы получаем следующие результаты для каждой строк

? (131.57.9.29) AND (255.255.252.0) - 131.57.8.0 - совпадение;

? (131.57.9.29) AND (255.255.255.0) - 131.57.9.0 - совпадение;

? (131.57.9.29) AND (255.255.255.240) = 131.57.9.16 - совпадение;

? (131.57.9.29) AND (255.255.255.252) = 131.57.9.28 - нет совпадения.

Поскольку при наличии нескольких совпадений выбирается маршрут из той ст] в которой совпадение адреса назначения с адресом из пакета имеет наибольшую д определено, что пакет с адресом 131.57.9.29 направляется в сеть DMZ.

CIDR

За последние несколько лет в Интернете многое изменилось: резко возросло число; и сетей, повысилась интенсивность трафика, изменился характер передаваемых да] Из-за несовершенства протоколов маршрутизации обмен сообщениями об обнов/ таблиц стал приводить к сбоям магистральных маршрутизаторов, происходящим перегрузок при обработке большого объема служебной информации. Так, сегодня т цы магистральных маршрутизаторов в Интернете могут содержать до нескольких и даже тысяч маршрутов.

Суть технологии С1Ш заключается а следующем. Каждому поставщику услуг Интернета назначается непрерывный диапазон ГР-адресое. При таком подходе еде адреса каждого поставщика услуг имеют обц^ старшую часть—префико/поэтому|^шрупЬа1^яна магйстрал5« Интер^ ; нета может осущаствлятьсяна основе префиксоэ,а не полныхадресов сетей* к его значит» что%‘ вместо множества записей по числу, сетей будет достаточна пометить оди$ запись сразу для всех сетей, имвккцих общий префикс. Такое агрегарованивадресовгтоаволит уменьшить обърм таблиц в маршрутизаторахвсех уровней/, а следовдтельно,усторить работу маршрутизаторов иповьюитьпропускмуюспособн^

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

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

Вернемся к рис. 16.16, на котором показано адресное пространство поставщика услуг с участками SI, S2, S3 и S, переданными в пользование четырем клиентам. Этот пример также иллюстрирует рис. 16.19. В результате агрегирования сетей клиентов в табл. 16.12 маршрутизатора Rjsp поставщика услуг для каждого клиента будет выделено по одной строке независимо от количества подсетей, организованных ими в своих сетях. Так, вместо четырех маршрутов к четырем сетям клиента S в таблице задан только один общий для всех них маршрут (выделенный жирным шрифтом).

Таблица 16.12. Таблица маршрутизатора Risp поставщика услуг i| Адрес назначенияМаскаСледующиймаршрутизаторНомер выходного интерфейсаРасстояние 1131.57.0.0 (S1)255.255.255.0R31Подключена j 131.57.2.0 (S2)255.255.255.0R331 1131.57.4.0 (S3)255.255.254.0R131 131.57.8.0 (S)255.255.252.0R12Подключена Маршрут по умолчаниюо.о.о.оRoxierna!4-

Итак, внедрение технологии CIDR позволяет решить две основные задачи.

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

? Уменьшение числа записей в таблицах маршрутизации за счет объединения маршрутов — одна запись в таблице маршрутизации может представлять большое количество сетей. Если все поставщики услуг Интернета начнут придерживаться стратегии CIDR, то особенно заметный выигрыш будет достигаться в магистральных маршрутизаторах.

; Сеть клиента S3 131.57.4.0/23 Сеть S нового клиента (131.57.8.0/22) Рис. 16.19. Объединение подсетей

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

Технология CIDR уже успешно используется в текущей версии протокола IP (IPv4) и го держивается такими протоколами маршрутизации, как OSPF, RIP-2, BGP4 (в основи на магистральных маршрутизаторах Интернета). Особенности применения технолш

птл р D игглг1ж ооп/чш пплфлт/лтто ТО (ТОттТТ17Т полл!тФЛтп.т та гттотал Л Q

Фрагментация IP-пакетов

Важной особенностью протокола IP, отличающей его от других сетевых протоколов (например, от сетевого протокола IPX, который какое-то время назад конкурировал с IP), является его способность выполнять динамическую фрагментацию пакетов при передаче их между сетями с различными максимально допустимыми значениями длины поля данных кадров (Maximum Transmission Unit, MTU). Значения MTU зависят как от протокола, так и от настройки сетевых интерфейсов.

Прежде всего отметим разницу между фрагментацией сообщений в узле-отправителе и динамической фрагментацией сообщений Ь транзитных узлах сети — маршрутизаторах.

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

В стеке TCP/IP эту задачу решает протокол TCP, который разбивает поток байтов, передаваемый ему с прикладного уровня, на сегменты нужного размера, например, по 1460 байт, если на нижнем уровне данной сети работает протокол Ethernet. Протокол IP в узле-отправителе, как правило, не использует свои возможности по фрагментации пакетов.

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

Параметры фрагментации

Каждый из фрагментов должен быть снабжен полноценным заголовком IP. Некоторые из полей заголовка (идентификатор, TTL, флаги DF и MF, смещение) непосредственно предназначены для последующей сборки фрагментов в исходное сообщение.

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

Q Поле времени жизни (Time То Live, TTL) занимает один байт и определяет предельный срок, в течение которого пакет может перемещаться по сети. Время жизни пакета измеряется в секундах и задается источником (отправителем). Как уже отмечалось в начале этой главы, по истечении каждой секунды пребывания на каждом из маршрутизаторов, через которые проходит пакет во время своего «путешествия» по сети, из его текущего времени жизни вычитается единица; единица вычитается и в том случае, если время пребывания было меньше секунды. Поскольку современные маршрутизаторы редко обрабатывают пакет дольше, чем за одну секунду, то время жизни можно интерпретировать как максимальное число транзитных узлов, которые разрешено пройти пакету. Если значение поля времени жизни становится нулевым до того, как пакет достигает получателя, пакет уничтожается. При сборке фрагментов хост-получатель использует значение TTL как крайний срок ожидания недостающих фрагментов.

? Поле смещения фрагмента предоставляет получателю информацию о положении фрагмента относительно начала поля данных исходного нефрагментированного пакета. Так, например, первый фрагмент будет иметь в поле смещения нулевое значение. В пакете, не разбитом на фрагменты, поле смещения также имеет нулевое значение. Смещение задается в байтах и должно быть кратно 8 байт.

? Установленный в единицу однобитный флаг MF (More Fragments — больше фрагментов) говорит о том, что данный пакет является промежуточным (не последним) фрагментом. Модуль IP, отправляющий нефрагментированный пакет, устанавливает бит MF в нуль.

? Флаг DF (Do not Fragment — не фрагментировать), установленный в единицу, запрещает маршрутизатору фрагментировать данный пакет. Если помеченный таким образом пакет не может достигнуть получателя без фрагментации, то модуль IP его уничтожает, а узлу-отправителю посылается диагностическое сообщение.

ПРИМЕЧАНИЕ-

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

Механизм фрагментации

Рассмотрим механизм фрагментации на примере составной сети, показанной на рис. 16.20.

В одной из подсетей (Frame Relay) значение MTU равно 4080, в другой (Ethernet) — 1492. Хост, принадлежащий сети Frame Relay, передает данные хосту в сети Ethernet. На обоих хостах, а также на маршрутизаторе, связывающем эти подсети, установлен стек протоколов TCP/IP.

Транспортному уровню хоста-отправителя известно значение MTU нижележащей технологии (4080). На основании этого модуль TCP и «нарезает» свои сегменты размером 4000 байт и передает вниз протоколу IP, который помещает сегменты в поле данных IP-пакетов и генерирует для них заголовки. Обратим особое внимание на заполнение тех полей заголовка, которые прямо связаны с фрагментацией:

? пакету присваивается уникальный идентификатор, например 12456;

? поскольку пакет пока еще не был фрагментирован, в поле смещения помещается значение 0;

? признак MF также обнуляется, это показывает, что пакет одновременно является и своим последним фрагментом;

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

Общая величина IP-пакета составляет 4000 плюс 20 (размер заголовка IP), то есть 4020 байт, что умещается в поле данных кадра Frame Relay, которое в данном примере равно 4080. Далее модуль IP хоста-отправителя передает этот кадр своему сетевому интерфейсу Frame Relay, который отправляет кадры следующему маршрутизатору.

Модуль IP маршрутизатора по сетевому адресу прибывшего IP-пакета определяет, что пакет нужно передать в сеть Ethernet. Однако она имеет значение MTU, равное 1492, что значительно меньше размера поступившего на входной интерфейс пакета. Следовательно, IP-пакет необходимо фрагментировать. Модуль IP выбирает размер поля данных фрагмента равным 1000, так что из одного большого IP-пакета получается 4 маленьких пакета-фрагмента. Для каждого фрагмента и его заголовка IP в маршрутизаторе создается отдельный буфер (на рисунке фрагменты и соответствующие им буферы пронумерованы от 1 до 4). Протокол IP копирует в эти буферы содержимое некоторых полей заголовка IP исходного пакета, создавая тем самым «заготовки» заголовков IP всех новых пакетов-фрагментов. Одни параметры заголовка IP копируются в заголовки всех фрагментов, другие — лишь в заголовок первого фрагмента.

В процессе фрагментации могут измениться значения некоторых полей заголовков IP в пакетах-фрагментах по сравнению с заголовком IP исходного пакета. Так, каждый фрагмент имеет собственные значения контрольной суммы заголовка, смещения фрагмента и общей длины пакета. Во всех пакетах, кроме последнего, флаг MF устанавливается в единицу, а в последнем фрагменте — в нуль. Полученные пакеты-фрагменты имеют длину 1020 байт (с учетом заголовка IP), поэтому они свободно помещаются в поле данных кадров Ethernet.

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

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

ПРИМЕЧАНИЕ-

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

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

Когда первый фрагмент исходного пакета приходит на хост-получатель, этот хост запускает таймер, который определяет максимальное время ожидания прибытия остальных фрагментов данного пакета. В различных реализациях IP применяются разные правила выбора максимального времени ожидания. В частности, таймер может быть установлен на фиксированный период времени (от 60 до 120 секунд), рекомендуемый RFC. Как правило, этот интервал достаточен для доставки пакета от отправителя получателю. В других реализациях максимальное время ожидания определяется с помощью адаптивных алгоритмов измерения и статистической обработки временных параметров сети, позволяющих оценивать ожидаемое время прибытия фрагментов. Наконец, тайм-аут может быть выбран на базе значений TTL прибывающих фрагментов. Последний подход основан на том, что нет смысла ожидать, пока прибудут другие фрагменты пакета, если время жизни одного из прибывших фрагментов уже истекло.

ПРИМЕЧАНИЕ-

Если хотя бы один фрагмент пакета не успеет прийти на хост назначения к моменту истечения таймера, то никаких действий по дублированию отсутствующего фрагмента не предпринимается, а все полученные к этому времени фрагменты пакета отбрасываются! Хосту, пославшему исходный пакет, направляется ICMP-сообщение об ошибке. Такому поведению протокола IP вполне соответствует его кредо «с максимальными усилиями» — стараться по возможности, но никаких гарантий не давать.

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

Выводы

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

Максимальная длина IP-пакета составляет 65 535 байт. Заголовок обычно имеет длину 20 байт и содержит информацию о сетевых адресах отправителя и получателя, параметры фрагментации, время жизни пакета, контрольную сумму и некоторые другие параметры.

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

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

Эффективным средством структуризации IP-сетей являются маски. Маски позволяют разделить одну сеть на несколько подсетей или объединить несколько сетей в одну более крупную сеть.

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

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

Вопросы и задания

1. Сравните таблицу моста или коммутатора с таблицей маршрутизатора. Каким образом формируются эти таблицы? Какую информацию содержат? От чего зависит их объем?

2. Верно ли утверждение, что широковещательная рассылка является частным случаем групповой рассылки? Произвольной рассылки?

3. Может ли один сетевой интерфейс иметь одновременно несколько 1Ру6-адресов разных типов: уникальный адрес, адрес произвольной рассылки, групповой адрес?

4. Рассмотрим маршрутизатор на магистрали Интернета. Какие записи содержатся в поле адреса назначения его таблицы маршрутизации? Варианты ответов:

а) номера всех сетей Интернета;

б) номера некоторых сетей Интернета;

в) номера некоторых сетей и адреса некоторых конечных узлов Интернета;

г) номера сетей, подсоединенных к интерфейсам данного маршрутизатора.

5. Сколько записей о маршрутах по умолчанию может включать таблица маршрутизации?

6. Приведите примеры, когда может возникнуть необходимость в использовании специфических маршрутов?

7. Передается ли в IP-пакете маска в тех случаях, когда маршрутизация реализуется с использованием масок?

8. Какие преимущества дает технология CIDR? Что мешает ее широкому внедрению?

9. Пусть префикс непрерывного пула IP-адресов составляет 15 двоичных разрядов. Сколько адресов, входит в этот пул? Варианты ответов:

а) 215; 6)217; в) 215 - 2; г) 152.

10. Почему в записи о маршруте по умолчанию в качестве адреса сети назначения часто указывается 0.0.0.0 с маской 0.0.0.0?

11. Какие элементы сети могут выполнять фрагментацию? Варианты ответов:

а) только компьютеры;

б) только маршрутизаторы;

в) компьютеры, маршрутизаторы, мосты, коммутаторы;

г) компьютеры и маршрутизаторы.

12. Что произойдет, если при передаче пакета он был фрагментирован и один из фрагментов не дошел до узла назначения после истечения тайм-аута? Варианты ответов:

а) модуль IP получателя сообщит о неполучении одного фрагмента, а IP-модуль узла-отправителя повторит передачу недошедшего фрагмента;

б) модуль IP получателя сообщит о неполучении одного фрагмента, а IP-модуль узла-отправителя повторит передачу всего пакета, в состав которого входил недошедший фрагмент;

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

13. Верно ли утверждение, что широковещательная рассылка является частным случаем групповой рассылки? Произвольной рассылки?

14. В разделе «Перекрытие адресных пространств» этой главы приведен пример того, как администратор планирует сеть своего предприятия. Решите ту же задачу по планированию сети, но для случая, когда для сети Ethernet требуется 300 адресов, для сети Token Ring — 30, для DMZ — 20 и для соединительной сети — 8. Какой пул адресов необходимо получить у поставщика услуг на этот раз? (Для определенности будем считать, что поставщик услуг выделит непрерывный пул адресов.) Как администратор распределит адреса между своими четырьмя сетями? Как будут выглядеть таблицы маршрутизации R1 и R2?

ГЛАВА 17 Базовые протоколы TCP/IP

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

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

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

Протоколы транспортного уровня TCP и UDP

К транспортному уровню стека TCP/IP относятся:

? протокол управления передачей (Transmission Control Protocol, TCP), описанный в стандарте RFC 793;

? протокол пользовательских дейтаграмм (User Datagram Protocol, UDP), описанный в стандарте RFC 768.

Протоколы TCP и UDP, как и протоколы прикладного уровня, устанавливаются на конечных узлах.

Порты и сокеты

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

Каждый компьютер может выполнять несколько процессов, более того, даже отдельный прикладной процесс может иметь несколько точек входа, выступающих в качестве адресов назначения для пакетов данных. Поэтому доставка данных на сетевой интерфейс компьютера-получателя — это еще не конец пути, так как данные необходимо переправить конкретному процессу-получателю. Процедура распределения протоколами TCP и UDP поступающих от сетевого уровня пакетов между прикладными процессами называется демультиплексированием (рис. 17.1).

Рис. 17.1. Мультиплексирование и демультиплексирование на транспортном уровне

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

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

Если процессы представляют собой популярные системные службы, такие как FTP, telnet, Нттр d^S и т п^ то за ними закрепляются стандартные назначенные номера,

называемые также хорошо известными (well-known) номерами портов. Эти номера закрепляются и публикуются в стандартах Интернета (RFC 1700, RFC 3232). Так, номер 21 закреплен за серверной частью службы удаленного доступа к файлам FTP, а 23 — за серверной частью службы удаленного управления telnet. Назначенные номера из диапазона от 0 до 1023 являются уникальными в пределах Интернета и закрепляются за приложениями централизованно.

Для тех приложений, которые еще не стали столь распространенными, номера портов назначаются локально разработчиками этих приложений или операционной системой в ответ на поступление запроса от приложения. На каждом компьютере операционная система ведет список занятых и свободных номеров портов. При поступлении запроса от приложения, выполняемого на данном компьютере, операционная система выделяет ему первый свободный номер. Такие номера называют динамическими. В дальнейшем все сетевые приложения должны адресоваться к данному приложению с указанием назначенного ему динамического номера порта. После того как приложение завершит работу, его номер возвращается в список свободных и может быть назначен другому приложению. Динамические номера являются уникальными в пределах каждого компьютера, но при этом обычной является ситуация совпадения номеров портов приложений, выполняемых на разных компьютерах. Как правило, клиентские части известных приложений (DNS, WWW, FTP, telnet и др.) получают динамические номера портов от ОС.

Все, что было сказано о портах, в равной степени относится к обоим протоколам транспортного уровня (TCP и UDP). В принципе, нет никакой зависимости между назначением номеров портов для приложений, использующих протокол TCP, и приложений, работающих с протоколом UDP. Приложения, которые передают данные на уровень IP по протоколу UDP, получают номера, называемые UDP-портами. Аналогично, приложениям, обращающимся к протоколу TCP, выделяются ТСР-порты.

В том и другом случаях это могут быть как назначенные, так и динамические номера. Диапазоны чисел, из которых выделяются номера TCP- и UDP-портов, совпадают: от 0 до 1023 для назначенных и от 1024 до 65 535 для динамических. Однако никакой связи между назначенными номерами TCP- и UDP-портов нет. Даже если номера TCP- и UDP-портов совпадают, они идентифицируют разные приложения. Например, одному приложению может быть назначен ТСР-порт 1750, а другому — UDP-порт 1750. В некоторых случаях, когда приложение может обращаться по выбору к протоколу TCP или UDP (например, {Порт приложения не надо путать с портами (сетевыми интерфейсами) оборудования.

таким приложением является DNS), ему, исходя из удобства запоминания, назначаются совпадающие номера TCP- и UDP-портов (в данном примере — это хорошо известный номер 53).

Стандартные назначенные номера портов уникально идентифицируют тип приложения (FTP, или HTTP, или DNS и т. д.), однако они не могут использоваться для однозначной идентификации прикладных процессов, связанных с каждым из этих типов приложений. Пусть, например, на одном хосте запущены две копии DNS-сервера — DNS-сервер 1, DNS-сервер 2 (рис. 17.2). Каждый из этих DNS-серверов имеет хорошо известный UDP-порт 53. Какому из этих серверов нужно было бы направить запрос клиента, если бы в DNS-запросе в качестве идентификатора сервера был указан только номером порта?

[

Сокет DNS-сервера 1 Ц DNS-сервер 1 (IP1, UDP-порт 53).

DNS-сервер 21 Сокет DNS-сервера 2 -(IP2, UDP-порт 53)

DNS-клиент 2

]''i:

' /v'>' , *' , ' 'цii ' '?i IP1, IP2 1Р-дейтаграмма 0йS1Порт назначения 53IP-адрес назначения IP2 UDP-дейтаграмма---КадрРис. 17.2. Демультиплексирование протокола UDP на основе сокетов

Чтобы снять неоднозначность в идентификации приложений, разные копии связываются с разными IP-адресами. Для этого сетевой интерфейс компьютера, на котором выполняется несколько копий приложения, должен иметь соответствующее число IP-адресов -на рисунке это IP1 и IP2. Во всех IP-пакетах, направляемых DNS-серверу 1, в качестве IP-адреса указывается IP1, а DNS-серверу 2 — адрес IP2. Поэтому показанный на рисунке пакет, в поле данных которого содержится UDP-дейтаграмма с указанным номером порта 53, а в поле заголовка задан адрес IP2, буден направлен однозначно определенному адресату — DNS-серверу 2.

Прикладной процесс однозначно определяется в пределах сети и в пределах отдельного компьютера парой (!Р-адрес, номер порта), называемой сокетом (socket). Сокет, определенный IP-адресом и номером UDP-порта, называется UDP-сокетом, а IP-адресом и номером ТСР-порта—ТСР-сокетом.

ПРИМЕЧАНИЕ-

Здесь мы должны уточнить описанную в предыдущих главах упрощенную картину прохождения пакета вверх по стеку Действительно, как мы и отмечали, после получения IP-пакета от протокола канального уровня протокол IP анализирует содержимое заголовка этого пакета, после чего заголовок отбрасывается, и «наверх» передается содержимое поля данных IP-пакета, например UDP-дейтаграмма. Упрощение состоит в том, что вместе с содержимым поля данных на транспортный уровень передается извлеченный из заголовка IP-адрес назначения, который и используется для однозначной идентификации приложения.

Протокол UDP и UDP-дейтаграммы

ПротбкШ УСЩ дейтаграммным протоколом, реализующим так называемый

который не гарантирует доставку сообщений адресату.

При работе на хосте-отправителе данные от приложений поступают протоколу UDP через порт в виде сообщений (рис. 17.3). Протокол UDP добавляет к каждому отдельному сообщению свой 8-байтный заголовок, формируя из этих сообщений собственные протокольные единицы, называемые UDP-дейтаграммами, и передает их нижележащему протоколу IP. В этом и заключаются его функции по мультиплексированию данных.

Рис. 17.3. Работа протокола UDP на хосте-отправителе

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

Заголовок UDP состоит из четырех 2-байтных полей:

? номер UDP-порта отправителя;

? номер UDP-порта получателя;

? контрольная сумма;

? длина дейтаграммы.

Далее приведен пример заголовка UDP с заполненными полями:

Source Port - 0x0035 Destination Port - 0x0411 Total length - 132 (0x84) bytes Checksum - 0x5333

В этой UDP-дейтаграмме в поле данных, длина которого, как следует из заголовка, равна (132 - 8) байт, помещено сообщение DNS-сервера, что можно видеть по номеру порта источника (Source Port = 0—0035). В шестнадцатеричном формате это значение равно стандартному номеру порта DNS-сервера — 53.

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

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

Протокол TCP и ТСР-сегменты

Протсифл основан

При работе на хосте-отправителе протокол TCP рассматривает информацию, поступающую к нему от прикладных процессов, как неструктурированный поток байтов (рис. 17.4). Поступающие данные буферизуются средствами TCP. Для передачи на сетевой уровень из буфера «вырезается» некоторая непрерывная часть данных, которая называется сегментом* и снабжается заголовком. 60

Рис. 17.4. Формирование TCP-сегментов из потока байтов

ПРИМЕЧАНИЕ-

В отличие от протокола UDP, который создает свои дейтаграммы на основе логически обособленных единиц данных — сообщений, генерируемых приложениями, протокол TCP делит поток данных на сегменты без учета их смысла или внутренней структуры.

2 байта

2 байта

Порт источника (sours port)

Порт приемника (destination port)

Последовательный номер (sequence number) -номер первого байта данных в сегменте, определяет смещение сегмента относительно потока отправляемых данных

Подтвержденный номер (acknowledgement number) -максимальный номер байта в полученном сегменте,

* увеличенный на единицу

Длина

заголовка

(hlen)

Резерв

(reserved)

Контрольная сумма

(checksum)

Окно (window) - количество байтов данных, ожидаемых отправителем данного сегмента, начиная с байта, номер которого указан в поле подтвержденного номера

Указатель срочности (urgent pointer) -указывает на конец данных, которые необходимо срочно принять, несмотря на переполнение буфера

Параметры (options) -

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

Заполнитель (paddind) *

это фиктивное поле может иметь переменную длину,

^ , используется для доведения

размера заголовков до целого числа 32-битовых слов

Рис. 17.5. Формат заголовка ТСР-сегмента

Логические соединения — основа надежности TCP

Основным отличием TCP от UDP является то, что на протокол TCP возложена дополнительная задача — обеспечить надежную доставку сообщений, используя в качестве основы ненадежный дейтаграммный протокол IP.

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

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

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

Рис. 17.6. TCP-соединение создает надежный логический канал между конечными узлами

При установлении логического соединения модули TCP договариваются между собой о параметрах процедуры обмена данными. В протоколе TCP каждая сторона соединения посылает противоположной стороне следующие параметры:

? максимальный размер сегмента, который она готова принимать;

? максимальный объем данных (возможно несколько сегментов), которые она разрешает другой стороне передавать в свою сторону, даже если та еще не получила квитанцию на предыдущую порцию данных (размер окна);

? начальный порядковый номер байта, с которого она начинает отсчет потока данных в рамках данного соединения.

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

Соединение устанавливается по инициативе клиентской части приложения. При необходимости выполнить обмеЦ данными с серверной частью приложение-клиент обращается к нижележащему протоколу TCP, который в ответ на это обращение посылает сегмент-запрос на установление соединения протоколу TCP, работающему на стороне сервера (рис. 17.7, а). В числе прочего в запросе содержится флаг SYN, установленный в 1.

Получив запрос, модуль TCP на стороне сервера пытается создать «инфраструктуру» для обслуживания нового клиента. Он обращается к операционной системе с просьбой о выделении определенных системных ресурсов для организации буферов, таймеров, счетчиков. Эти ресурсы закрепляются за соединением с момента создания и до момента разрыва. Если на стороне сервера все необходимые ресурсы были получены и все необходимые действия выполнены, то модуль TCP посылает клиенту сегмент с флагами АСК и SYN.

* Соединение * закрыто

а

Запрос

соединения

Состояние

ESTABLISHED

Подготовка Закрыть соединения соединен прошла успешно

Состояние

ESTABLISHED

?

t

t

Тайм-аутЗакрытьсоединение

сервера

клиента

TCP на стороне TCP на стороне

TCP на стороне TCP на стороне клиента сервера

б

Рис. 17.7. Процедура установления и разрыва логического соединения при нормальном течении процесса

В ответ клиент посылает сегмент с флагом АСК и переходит в состояние установленного логического соединения (состояние ESTABLISHED). Когда сервер получает флаг АСК, он также переходит в состояние ESTABLISHED. На этом процедура установления соединения заканчивается, и стороны могут переходить к обмену данными.

Соединение может быть разорвано в любой момент по инициативе любой стороны. Для этого клиент и сервер должны обменяться сегментами FIN и АСК, в последовательности, показанной на рис. 17.7, б (здесь инициатором является клиент). Соединение считается закрытым по прошествии некоторого времени, в течение которого сторона-инициатор убеждается, что ее завершающий сигнал АСК дошел нормально и не вызвал никаких «аварийных» сообщений со стороны сервера.

ПРИМЕЧАНИЕ-

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

Сокет одновременно может участвовать в нескольких соединениях. Так, на рис. 17.8 по-

одному приложению — APPL1, APPL2 и APPL3, сокеты которых — соответственно (IP1, nl), (IP2, n2), (IP3, пЗ), а номера TCP-портов приложений — nl, п2, пЗ.

Рис. 17.8. Один сокет может участвовать в нескольких соединениях

На рисунке показаны два логических соединения, которое установило приложение 2 с приложением 1 и приложением 3. Логические соединения идентифицируются как {(IP2, n2), (IP1, nl)} и {(IP2, n2), (IP3, пЗ)} соответственно. Мы видим, что в обоих соединениях участвует один и тот же сокет — (IP2, п2).

А теперь^эассмотрим на примере, как протокол TCP выполняет демультиплексирование. Пусть некий поставщик услуг оказывает услугу по веб-хостингу, то есть на его компьютере клиенты могут разворачивать свои веб-серверы. Веб-сервер основан на протоколе прикладного уровня HTTP, который передает свои сообщения в TCP-сегментах. Модуль TCP ожидает запросы от веб-клиентов (браузеров), «прослушивая» хорошо известный порт 80.

На рис. 17.9 показан вариант хостинга с двумя веб-серверами — сервером www1 .model.ru, имеющим IP-адрес IP1, и сервером www2.tour.ru с адресом IP2. К каждому из них может обращаться множество клиентов, причем клиенты могут одновременно работать как с сервером www1, так и с сервером www2. Для каждой пары клиент-сервер протоколом TCP создается отдельное логическое соединение.

На рисунке показаны два браузера, имеющие соответственно сокеты (IP*, я*) и (IPm, nm). Пользователь браузера k обращается одновременно к серверам WWW 1 и WWW2. Наличие отдельных соединений для работы с каждым из этих серверов обеспечивает не только надежную доставку, но и разделение информационных потоков — у пользователя никогда не возникает вопроса, каким сервером ему была послана та или иная страница. Одновременно с пользователем браузера k с сервером WWW2 работает пользователь браузера т. И в этом случае отдельные логические соединения, в рамках которых идет работа обоих пользователей, позволяют изолировать их информационные потоки. На рисунке показаны

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

www2.tour.ru - IP2 r?^(wWVV2^

Соединение браузер к-сервер www2

www1.model.ru - IP1 БуферыСоединениебраузер m-сервер www2

Соединение браузер k-сервер www1

т.). (1Р1,80)1

1 " ЯЛTCP [ ' /“Л' ? 1 Oft» nm) N/’-'Браузеры

Рис. 17.9. Демультиплексирование протокола TCP на основе соединений

|ровтчие инфррмеди^ поступающей на прйютадйой и^^сшо ито же,на осноедедентифии^^и^х

Повторная передача и скользящее окно

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

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

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

Повторная передача кадра 2

Отправленные Простой Простой Простойкадры на Ожидание Простой Ожидание Ожиданиестороне квитанции Истечение тайм-аута квитанции квитанции отправителяпи----И Полученныеквитанции, „& АСКПолученные7 Потеря / / ^ квитанции |2|/ |3|/ кадры на стороне приемникаВремя доставки кадра от отправ к получателю1мтеляРис!. 17,-“....... ?ВремяВремя доставки квитанции от получателя к отправителю кадра.10. Метод простоя источника

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

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

Рисунок 17.11 иллюстрирует применение данного метода для окна размером 5 кадров.

В начальный момент, когда еще не послано ни одного кадра, окно определяет диапазон номеров кадров от 1 до 5 включительно. Источник начинает передавать кадры и через какое-то время получать в ответ квитанции. Для простоты предположим, что квитанции поступают в той же последовательности (но не обязательно в том же темпе), что и кадры, которым они соответствуют. В момент получения отправителем квитанции 1 окно сдвигается на одну позицию вверх, определяя новый диапазон разрешенных к отправке кадров (от 2 до 6).

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

Отправле! кадры на стороне отправителя

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

После получения квитанции 2 (на кадр 2) окно сдвигается вверх на единицу, определяя диапазон разрешенных к передаче кадров от 3 до 7. Аналогичное «скольжение» окна вверх происходит после получения каждой квитанции: окно сдвигается вверх на 1, но его размер при этом не меняется и остается равным 5. После прихода квитанции 8 окно оказывается в диапазоне от 9 до 13 и остается таковым достаточно долго, так как по каким-то причинам источник перестает получать подтверждения о доставке кадров. Отправив последний разрешенный кадр 13, передатчик снова прекращает передачу с тем, чтобы возобновить ее после прихода квитанции 9.

При отправке кадра в источнике устанавливается тайм-аут. Если за установленное время квитанция на отправленный кадр не придет, то кадр (или квитанция на него) считается утерянным, и кадр передается снова. Если же поток квитанций поступает регулярно в пределах допуска в 5 кадров, то скорость обмена достигает максимально возможной величины для данного канала и принятого протокола.

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

Реализация метода скользящего окна в протоколе TCP

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

Хотя ем^и^пвр^даваемых данныхлррток^ Овсмвнт (аналог кадра в данном

KOWTeK&^f ?КДО

данных, передаваемого^

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

ТСР-сегмент Байт Байтс конечным с начальнымномером номеромРис. 17.12. Нумерация байтов в ТСР-сегменте

Когда отправитель посылает ТСР-сегмент, он помещает в поле последовательного номера номер первого байта данного сегмента, который служит идентификатором сегмента. На рис. 17.13 показаны четыре сегмента размером 1460 байт и один — 870 байт. Идентификаторами этих сегментов являются номера 32600, 34060, 35520 и т. д. На основании этих номеров получатель TCP-сегмента не только отличает данный сегмент от других, но и позиционирует полученный фрагмент относительно общего потока байтов. Кроме того, он может сделать вывод, например, что полученный сегмент является дубликатом или что между двумя полученными сегментами пропущены данные и т. д.

38440 38980 36520 34060 32600

1460 1460 ?1460

870

Направление передачи сегментов

Рис. 17.13. Порядковый номер и номер квитанции

В качестве квитанции получатель сегмента отсылает ответное сообщение (сегмент), в поле подтвержденного номера которого он помещает число, на единицу превышающее максимальный номер байта в полученном сегменте. Так, для первого отправленного сегмента, изображенного на рис. 17.13, квитанцией о получении (подтвержденным номером) будет число 34060, для второго — 35520 и т. д. Подтвержденный номер часто интерпретируют не только как оповещение о благополучной доставке, но и как номер следующего ожидаемого байта данных.

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

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

Поскольку протокол TCP является дуплексным, каждая сторона одновременно выступает и как отправитель, и как получатель. У каждой стороны есть пара буферов: один — для хранения принятых сегментов, другой — для сегментов, которые только еще предстоит отправить. Кроме того, имеется буфер для хранения копий сегментов, которые были отправлены, но квитанции о получении которых еще не поступили (рис. 17.14).

(1Р1,п1)

ТСР-соединение

*

(IP2, п2) Буфер отправления Буфер приема

Буфер приема

I

Буфер отправления

Окно

Буфер копий

Рис. 17.14. Система буферов ТСР-соединения

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

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

? Первая граница отделяет сегменты, которые уже были отправлены и на которые уже пришли квитанции. Последняя квитанция пришла на байт с номером N.

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

? Оставшаяся часть окна — это сегменты, которые пока не отправлены, но могут быть отправлены, так как входят в пределы окна.

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

Направление движения окна ^ Размер окна—wБайт N + WПриложение Потокбайт Байт N,/ Окно1V Г.......г~"1 Г^111 I I 1 1 HI 1 1TCP Сегменты1I1Сегменты !1 1 вСегменты, jСегменты, отправлены,отправлены, jкоторыекоторые еще квитанции! квитанции пока !разрешеноне разрешено полученыне полученыотправлятьотправлять Направление передачи данных из источника к приемнику

Рис. 17.15. Особенности реализации алгоритма скользящего окна в протоколе TCP

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

Получатель может послать квитанцию, подтверждающую получение сразу нескольких сегментов, если они образуют непрерывный поток байтов. Например, (рис. 17.16, я), если в буфер, плотно без пропусков заполненный потоком байтов до 2354 включительно, поочередно поступили сегменты (2355-3816), (3817-5275) и (5276-8400), где цифры в скобках означают номера первых и последних байтов каждого сегмента, то получателю достаточно отправить только одну квитанцию на все три сегмента, указав в ней в качестве номера квитанции значение 8401. Таким образом, процесс квитирования в TCP является накопительным.

Вполне возможны ситуации, когда сегменты приходят к получателю не в том порядке, в котором были посланы, то есть в приемном буфере может образоваться «прогалина» (рис. 17.16, б). Пусть, к примеру, после указанных ранее трех сегментов вместо следующего по порядку сегмента (8401-10566) пришел сегмент (1056*7—12430). Очевидно, что послать в качестве номера квитанции значение 12431 нельзя, потому что это бы означало, что получены все байты вплоть до 12430. Поскольку в потоке байтов образовался разрыв, получатель может только еще раз повторить квитанцию 8401, говоря тем самым, что все еще ожидает поступления потока байтов, начиная с 8401, то есть подтверждает получение не отдельных блоков данных, а непрерывной последовательности байтов.

Передача квитанции на получение байта 8401 2354 2355 3816 3817 5275 5276 8400 /_ t1 t2 t3 t4J--?Время t aПередача квитанции на получение байта 8401 2354 2355 3816 3817 5275 5276 840010567 12430/ Г__| , |7—J—-—С-* t1 t2 t3 t4 t5q Время tРис. 17.16. Накопительный принцип квитирования: а — плотное заполнение буфера (в момент t4 передается квитанция на байт 8401), б — неплотное заполнение буфера (в момент t5 снова передается квитанция на байт 8401)

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

Управление потоком

Какой размер окна должен назначить источник приемнику, и наоборот? Точнее, каким на каждой из сторон должно быть выбрано время ожидания (тайм-аут) очередной квитанции? От ответа на этот вопрос зависит производительность протокола TCP.

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

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

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

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

В то же время окно малого размера может ограничить передачу данных скоростью, которая определяется временем путешествия по сети каждого посылаемого сегмента. Чтобы избежать применения малых окон, в Некоторых реализациях TCP предлагается получателю данных откладывать реальное изменение размеров окна до тех пор, пока свободное место не составит 20-40 % от максимально возможного объема памяти для этого соединения. Но и отправителю не стоит спешить с посылкой данных, пока окно принимающей стороны не станет достаточно большим. Учитывая эти соображения, разработчики протокола TCP предложили схему, согласно которой при установлении соединения заявляется большое окно, но впоследствии его размер существенно уменьшается. Существуют и другие прямо противоположные алгоритмы настройки окна, когда вначале выбирается минимальное окно, а затем, если сеть справляется с предложенной нагрузкой, его размер резко увеличивается.

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

Признаком перегрузки TCP-соединения является возникновение очередей на промежуточных узлах (маршрутизаторах) и на конечных узлах (компьютерах). При переполнении приемного буфера конечного узла «перегруженный» модуль TCP, отправляя квитанцию, помещает в нее новый уменьшенный размер окна. Если он совсем отказывается от приема, то в квитанции указывается окно нулевого размера. Однако даже после этого приложение может послать сообщение на отказавшийся от приема порт. Для этого сообщение должно сопровождаться указателем срочности. В такой ситуации порт обязан принять сегмент, даже если для этого придется вытеснить из буфера уже находящиеся там данные. После приема квитанции с нулевым значением окна протокол-отправитель время от времени делает контрольные попытки продолжить обмен данными. Если протокол-приемник уже готов принимать информацию, то в ответ на контрольный запрос он посылает квитанцию с указанием ненулевого размера окна.

Как видно из нашего далеко не полного описания двух протоколов транспортного уровня стека TCP/IP, на один из них — TCP — возложена сложная и очень важная задача: обеспечение надежной передачи данных через ненадежную сеть.

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

Общие свойства и классификация протоколов маршрутизации

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

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

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

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

Тем не менее большинство протоколов маршрутизации нацелено на создание таблиц маршрутизации.

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

Различные протоколы маршрутизации обладают разным временем конвергенции.

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

Различают протоколы, выполняющие статическую и адаптивную (динамическую) маршрутизацию.

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

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

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

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

? дистанционно-векторные алгоритмы (Distance Vector Algorithm, DVA);

? алгоритмы состояния связей (Link State Algorithm, ISA).

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

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

Затем он выбирает из нескольких альтернативных маршрутов к каждой сети тот маршрут, который обладает наименьшим значением метрики. Маршрутизатор, передавший информацию о данном маршруте, отмечается в таблице маршрутизации как следующий (next hop).

Дистанционно-векторные алгоритмы хорошо работают тояьков небольших сетях. В больших сетях они периодически засоряют линии связи инхенр*$йЦм трафиком, изменения

конфигурации не всегда корректно могут отрабатывэт%^^П|^ь^| этого как марш

рутизаторы не имеют точного представления о тополо(>4]|с^^й э сетЦ а р^к^олагаютто^ько : косвенной информацией-* аакгяо^|рщр^ни^< ' "

Наиболее распространенным протоколом, основанным на дистанционно-векторном алгоритме, является протокол RIP (см. далее).

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

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

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

В результате служебный^трафик, создаваемый Протоколами LSA, гораздо менее интенсивный, чем у протоколов PVA.

Протоколами, основанными на алгоритме состояния связей, являются протокол IS-IS стека OSI (этот протокол используется также в стеке TCP/IP) и протокол OSPF стека TCP/IP.

Протокол RIP

Протокол RIP (Routing Information Protocol — протокол маршрутной информации) является внутренним протоколом маршрутизации дистанционно-векторного типа.

Будучи простым в реализации, этот протокол чаще всего используется в небольших сетях. Для IP имеются две версии RIP — RIPvl и RIPv2. Протокол RIPvl не поддерживает масок. Протокол RIPv2 передает информацию о масках сетей, поэтому он в большей степени соответствует требованиям сегодняшнего дня. Так как построение таблиц маршрутизации в обеих версиях протокола принципиально не отличается, в дальнейшем для упрощения записей будет описываться работа версии 1.

Построение таблицы маршрутизации

Для измерения расстояния до сети стандарты протокола RIP допускают различные виды метрик: хопы, значения пропускной способности, вносимые задержки, надежность сетей (то есть соответствующие признакам D, Т и R в поле качества сервиса IP-пакета), а также любые комбинации этих метрик. Метрика должна обладать свойством аддитивности — метрика составного пути должна быть равна сумме метрик составляющих этого пути. В большинстве реализаций RIP используется простейшая метрика — количество хопов, то есть количество промежуточных маршрутизаторов, которые нужно преодолеть пакету до сети назначения.

Рассмотрим процесс построения таблицы маршрутизации с помощью протокола RIP на примере составной сети, изображенной на рис. 17.17. Мы разделим этот процесс на 5 этапов.

Рис. 17.17. Сеть, построенная на маршрутизаторах RIP

Этап 1 - создание минимальной таблицы. Данная составная сеть включает восемь IP-сетей, связанных четырьмя маршрутизаторами с идентификаторами: Rl, R2, R3 и R4. Маршрутизаторы, работающие по протоколу RIP, могут иметь идентификаторы, однако для протокола они не являются необходимыми. В RIP-сообщениях эти идентификаторы не передаются.

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

Таблица 17.1 позволяет оценить примерный вид минимальной таблицы маршрутизации маршрутизатора R1.

Таблица 17.1. Минимальная таблица маршрутизации маршрутизатора R1 Номер сетиАдрес следующего маршрутизатораПортРасстояние 201.36.14.0201.36.14.311 132.11.0.0132.11.0.721 194.27.18.0194.27.18.131

Минимальные таблицы маршрутизации в других маршрутизаторах будут выглядеть соответственно, например, таблица маршрутизатора R2 будет состоять из трех записей (табл. 17.2).

Таблица 17.2. Минимальная таблица маршрутизации маршрутизатора R2 Номер сетиАдрес следующего маршрутизатораПортРасстояние 132.11.0.0132.11.0.10111 132.17.0.0132.17.0.121 132.15.0.0132.15.0.631

Этап 2 — рассылка минимальной таблицы соседям. После инициализации каждый маршрутизатор начинает посылать своим соседям сообщения протокола RIP, в которых содержится его минимальная таблица. RIP-сообщения передаются в дейтаграммах протокола UDP и включают два параметра для каждой сети: ее IP-адрес и расстояние до нее от передающего сообщение маршрутизатора.

По отношению к любому маршрутизатору соседями являются те маршрутизаторы, которым данный маршрутизатор может передать IP-пакет по какой-либо своей сети, не пользуясь услугами промежуточных маршрутизаторов. Например, для маршрутизатора R1 соседями являются маршрутизаторы R2 и R3, а для маршрутизатора R4 — маршрутизаторы R2 и R3.

Таким образом, маршрутизатор R1 передает маршрутизаторам R2 и R3 следующие сообщения:

? сеть 201.36.14.0, расстояние 1;

? сеть 132.11.0.0, расстояние 1;

? сеть 194.27.18.0, расстояние 1.

Этап 3 — получение RIP-сообщений от соседей и обработка полученной информации. После получения аналогичных сообщений от маршрутизаторов R2 и R3 маршрутизатор R1 наращивает каждое полученное поле метрики на единицу и запоминает, через какой порт

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

Таблица 17.3. Таблица маршрутизации маршрутизатора R1 Номер сетиАдрес следующего маршрутизатораПортРасстояние 201.36.14.0201.36.14.311 132.11.0.0132.11.0.721 194.27.18.0194.27.18.131 132.17.0.0132.11.0.10122 132.15.0.0132.11.0.10122 194.27.19.0194.27.18.5132 202.101.15.0194.27.18.5132 4-32.11.0.04-32. 11.0.10122 494:27:18.0194.27.18.5132

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

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

Аналогичные операции с новой информацией выполняют и остальные маршрутизаторы

сети.

Этап 4 — рассылка новой таблицы соседям. Каждый маршрутизатор отсылает новое RIP-сообщение всем своим соседям. В этом сообщении он помещает данные обо всех известных ему сетях: как непосредственно подключенных, так и удаленных, о которых маршрутизатор узнал из RIP-сообщений.

Этап 5 — получение RIP-сообщений от соседей и обработка полученной информации. Этап 5 повторяет этап 3 — маршрутизаторы принимают RIP-сообщения, обрабатывают содержащуюся в них информацию и на ее основании корректируют свои таблицы маршрутизации.

Посмотрим, как это делает маршрутизатор R1 (табл. 17.4).

На этом этапе маршрутизатор R1 получает от маршрутизатора R3 информацию о сети

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

Таблица 17.4. Таблица маршрутизации маршрутизатора R1 Номер сетиАдрес следующего маршрутизатораПортРасстояние 201.36.14.0201.36.14.311 132.11.0.0132.11.0.721 194.27.18.0194.27.18.131 132.17.0.0132.11.0.10122 132.15.0.0132.11.0.10122 132:15.0.0194.27.18.5133 194.27.19.0194.27.18.5132 194.-2-7:19-.0182:11-0:10123 202.101.15.0194.27.18.5132 202.101.16.0132.11.0.10123 202:101.16.0194.27.18.5433

О сети 202.101.16.0 маршрутизатор R1 узнает на этом этапе впервые, причем данные о ней приходят от двух соседей — от R3 и R4. Поскольку метрики в этих сообщениях указаны одинаковые, то в таблицу попадают данные, пришедшие первыми. В нашем примере считается, что маршрутизатор R2 опередил маршрутизатор R3 и первым переслал свое RIP-сообщение маршрутизатору R1.

Если маршрутизаторы периодически повторяют этапы рассылки и обработки RIP-сообщений, то за конечное время в сети установится корректный режим маршрутизации. Под корректным режимом маршрутизации здесь понимается такое состояние таблиц маршрутизации, когда все сети достижимы из любой сети с помощью некоторого рационального маршрута. Пакеты будут доходить до адресатов и не зацикливаться в петлях, подобных той, которая образуется на рис. 17.17, маршрутизаторами Rl, R2, R3 и R4.

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

Для адаптации к изменениям в сети протокол RIP использует ряд механизмов.

Адаптация маршрутизаторов RIP к изменениям состояния сети

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

Для уведомления о том, что некоторый маршрут недействителен, используются два механизма:

? истечение времени жизни маршрута;

? указание специального (бесконечного) расстояния до сети, ставшей недоступной.

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

Время тайм-аута связано с периодом рассылки векторов по сети. В протоколе RIP период рассылки выбран равным 30 секундам, а в качестве тайм-аута выбрано шестикратное значение периода рассылки, то есть 180 секунд. Шестикратный запас времени нужен для уверенности в том, что сеть действительно стала недоступной, а не просто произошли потери RIP-сообщений (а это возможно, так как протокол RIP использует транспортный протокол UDP, который не обеспечивает надежной доставки сообщений). Если какой-либо маршрутизатор отказывает, переставая слать своим соседям сообщения о сетях, которые можно достичь через него, то через 180 секунд все записи, порожденные этим маршрутизатором, у его ближайших соседей станут недействительными. После этого процесс повторится уже для ближайших соседей — они вычеркнут подобные записи уже через 360 секунд.

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

Когда же сообщение послать можно, маршрутизаторы RIP используют прием, заключающийся в указании бесконечного расстояния до сетиу ставшей недоступной. В протоколе RIP бесконечным условно считается расстояние в 16 хопов. Получив сообщение, в котором расстояние до некоторой сети равно 16 (или 15, что приводит к тому же результату, так как маршрутизатор наращивает полученное значение на 1), маршрутизатор должен проверить, исходит ли эта «плохая» информация о сети от того же маршрутизатора, сообщение которого послужило в свое время основанием для записи о данной сети в таблице маршрутизации. Если это тот же маршрутизатор, то информация считается достоверной и маршрут помечается как недоступный.

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

Пример зацикливания пакетов

Рассмотрим случай зацикливания пакетов на примере сети, изображенной на рис. 17.17. Пусть маршрутизатор R1 обнаружил, что его связь с непосредственно подключенной сетью 201.36.14.0 потеряна (например, по причине отказа интерфейса 201.36.14.3). Маршрутизатор R1 отмечает в своей таблице маршрутизации, что сеть 201.36.14.0 недоступна. В худшем случае он обнаружит это сразу же после отправки очередных RIP-сообщений, так что до начала нового цикла его объявлений, в котором он должен сообщить соседям, что расстояние до сети 201.36.14.0 стало равным 16, остается почти 30 секунд. Каждый маршрутизатор работает на основании своего внутреннего таймера, не синхронизируя работу по рассылке объявлений с другими маршрутизаторами. Поэтому весьма вероятно, маршрутизатор R2 опередит маршрутизатор R1 и передаст ему свое сообщение раньше, чем R1 успеет передать новость о недостижимости сети 201.36.14.0. А в этом сообщении имеются данные, порожденные записью в таблице маршрутизации R2 (табл. 17.5).

Таблица 17.5. Таблица маршрутизации маршрутизатора R2 Номер сетиАдрес следующего маршрутизатораПортРасстояние 201.36.14.0132.11.0.712

Эта запись, полученная от маршрутизатора R1, была корректна до отказа интерфейса 201.36.14.3; теперь она устарела, но маршрутизатор R2 об этом не знает.

Далее маршрутизатор R1 получает новую информацию о сети 201.36.14.0 — эта сеть достижима через маршрутизатор R2 с метрикой 2. Раньше R1 также получал эту информацию от R2, но игнорировал ее, так как его собственная метрика для 201.36.14.0 была лучше. Теперь R1 должен принять данные о сети 201.36.14.0, полученные от R2, и заменить запись в таблице маршрутизации о недостижимости этой сети (табл. 17.6).

Таблица 17.6. Таблица маршрутизации маршрутизатора R1 Номер сетиАдрес следующего маршрутизатораПортРасстояние 201.36.14.0132.11.0.10123

В результате в сети образуется маршрутная петля: пакеты, направляемые узлам сети

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

? Время 0-180 с. После отказа интерфейса в маршрутизаторах R1 и R2 будут сохраняться некорректные записи. Маршрутизатор R2 по-прежнему снабжает маршрутизатор R1 своей записью о сети 201.36.14.0 с метрикой 2, так как ее время жизни не истекло. Пакеты зацикливаются.

? Время 180-360 с. В начале этого периода у маршрутизатора R2 истекает время жизни записи о сети 201.36.14.0 с метрикой 2, так как маршрутизатор R1 в предыдущий период посылал ему сообщения о сети 201.36.14.0 с худшей метрикой, чем у R2, и они не могли подтверждать эту запись. Теперь маршрутизатор R2 принимает от маршрутизатора R1 запись о сети 201.36.14.0 с метрикой 3 и трансформирует ее в запись с метрикой 4. Маршрутизатор R1 не получает новых сообщений от маршрутизатора R2 о сети 201.36.14.0 с метрикой 2, поэтому время жизни его записи начинает уменьшаться. Пакеты продолжают зацикливаться.

? Время 360-540 с. У маршрутизатора R1 истекает время жизни записи о сети 201.36.14.0 с метрикой 3. Маршрутизаторы R1 и R2 опять меняются ролями — R2 снабжает R1 устаревшей информацией о пути к сети 201.36.14.0, уже с метрикой 4, которую R1 преобразует в метрику 5. Пакеты продолжают зацикливаться.

Если бы в протоколе RIP не было выбрано расстояние 16 в качестве недостижимого, то описанный процесс длился бы бесконечно (вернее, пока не была бы исчерпана разрядная сетка поля расстояния, и при очередном наращивании расстояния было бы зафиксировано переполнение).

В результате маршрутизатор R2 на очередном этапе описанного процесса получает от маршрутизатора R1 метрику 15, которая после наращивания, превращаясь в метрику 16, фиксирует недостижимость сети. Таким образом, в нашем примере период нестабильной работы сети длился 36 минут!

Ограничение в 15 хопов сужает область применения протокола RIP до сетей, в которых число промежуточных маршрутизаторов не может быть больше 15. Для более масштабных сетей нужно применять другие протоколы маршрутизации, например OSPF, или разбивать сеть на автономные области.

Приведенный пример хорошо иллюстрирует главную причину нестабильности маршрутизаторов, работающих по протоколу RIP. Эта причина коренится в самом принципе работы дистанционно-векторных протоколов — использовании информации, полученной из «вторых рук». Действительно, маршрутизатор R2 передает маршрутизатору R1 информацию о достижимости сети 201.36.14.0, за достоверность которой он сам не отвечает.

ПРИМЕЧАНИЕ-

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

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

Методы борьбы с ложными маршрутами в протоколе RIP

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

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

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

Однако расщепление горизонта не помогает в тех случаях, когда петли образуются не двумя, а большим числом маршрутизаторов. Рассмотрим более детально ситуацию, которая возникнет в сети, приведенной на рис. 17.17, в случае потери связи маршрутизатора R1 с сетью 201.36.14.0. Пусть все маршрутизаторы этой сети поддерживают технику расщепления горизонта. Маршрутизаторы R2 и R3 не будут возвращать маршрутизатору в этой ситуации данные о сети 201.36.14.0 с метрикой 2, так как они получили эту информацию от маршрутизатора R1. Однако они будут передавать маршрутизатору информацию о достижимости сети 201.36.14.0 с метрикой 4 через себя, так как получили эту информацию по сложному маршруту, а не непосредственно от маршрутизатора R1. Например, маршрутизатор R2 получает эту информацию по цепочке R4-R3-R1, поэтому маршрутизатор R1 снова может быть обманут, пока каждый из маршрутизаторов в цепочке R3-R4-R2 не вычеркнет запись о достижимости сети 201.36.14.0.

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

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

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

Протокол OSPF

Протокол OSPF (Open Shortest Path First — выбор кратчайшего пути первым) является последним (он принят в 1991 году) протоколом, основанном на алгоритме состояния связей, и обладает многими особенностями, ориентированными на применение в больших гетерогенных сетях.

Два этапа построения таблицы маршрутизации

OSPF разбивает процедуру построения таблицы маршрутизации на два этапа, к первому относится построение и поддержание базы данных о состоянии связей сети, ко второму — нахождение оптимальных маршрутов и генерация таблицы маршрутизации.

Построение и поддержание базы данных о состоянии связей сети. Связи сети могут быть представлены в виде графа, в котором вершинами графа являются маршрутизаторы и подсети, а ребрами — связи между ними (рис. 17.18). Каждый маршрутизатор обменивается со своими соседями той информацией о графе сети, которой он располагает к данному моменту. Этот процесс похож на процесс распространения векторов расстояний до сетей в протоколе RIP, однако сама информация качественно иная — это информация о топологии сети. Сообщения, с помощью которых распространяется топологическая информация, называются объявлениями о состоянии связей (Link State Advertisement, LSA) сети. При транзитной передаче объявлений LSA маршрутизаторы не модифицируют информацию, как это происходит в дистанционно-векторных протоколах, в частности в RIP, а передают ее в неизменном виде. В результате все маршрутизаторы сети сохраняют в своей памяти идентичные сведения о текущей конфигурации графа связей сети.

Для контроля состояния связей и соседних маршрутизаторов OSPF-маршрутизаторы передают друг другу особые сообщения HELLO каждые 10 секунд. Небольшой объем этих сообщений делает возможным частое тестирование состояния соседей и связей с ними. В том случае, когда сообщения HELLO перестают поступать от какого-либо непосредственного соседа, маршрутизатор делает вывод о том, что состояние связи изменилось с работоспособного на неработоспособное и вносит соответствующие коррективы в свою топологическую базу данных. Одновременно он отсылает всем непосредственным соседям объявление LSA об этом изменении, те также вносят исправления в свои базы данных и, в свою очередь, рассылают данное объявление LSA своим непосредственным соседям.

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

Если состояние связей в сети изменилось и произошла корректировка графа сети, каждый маршрутизатор заново ищет оптимальные маршруты и корректирует свою таблицу маршрутизации. Аналогичный процесс происходит и в том случае, когда в сети появляется новая связь или новый сосед, объявляющий о себе с помощью своих сообщений HELLO. При работе протокола OSPF конвергенция таблиц маршрутизации к новому согласованному состоянию происходит достаточно быстро, быстрее, чем в сетях, в которых работают дистанционно-векторные протоколы. Это время состоит из времени распространения по сети объявления LSA и времени работы алгоритма Дийкстры, который обладает быстрой сходимостью. Однако вычислительная сложность этого алгоритма предъявляет высокие требования к мощности процессора маршрутизатора.

Когда состояние сети не меняется, то объявления о связях не генерируются, топологические базы данных и таблицы маршрутизации не корректируются, что экономит пропускную способность сети и вычислительные ресурсы маршрутизаторов. Однако у этого правила есть исключение: каждые 30 минут OSPF-маршрутизаторы обмениваются всеми записями базы данных топологической информации, то есть синхронизируют их для более надежной работы сети. Так как этот период достаточно большой, то данное исключение незначительно сказывается на загрузке сети.

Метрики

При поиске оптимальных маршрутов протокол OSPF по умолчанию использует метрику, учитывающую пропускную способность каналов связи. Кроме того, допускается применение двух других метрик, учитывающих задержки и надежность передачи пакетов каналами связи. Для каждой из метрик протокол OSPF строит отдельную таблицу маршрутизации. Выбор нужной таблицы происходит в зависимости от значений битов TOS в заголовке пришедшего IP-пакета. Если в пакете бит D (Delay — задержка) установлен в 1, то для этого пакета маршрут должен выбираться из таблицы, в которой содержатся маршруты, минимизирующие задержку. Аналогично, пакет с установленным битом Т (Throughput -пропускная способность) должен маршрутизироваться по таблице, построенной с учетом пропускной способности каналов, а установленный в единицу бит R (Reliability — надежность) указывает на то, что должна использоваться таблица, для построения которой критерием оптимизации служит надежность доставки.

Протокол OSPF поддерживает стандартные для многих протоколов (например, для протокола покрывающего дерева) значения расстояний для метрики, отражающей пропускную способность: так, для сети Ethernet она равна 10, для Fast Ethernet — 1, для канала Т-161, обладающего пропускной способностью 1,544 Мбит/с, — 65, для канала с пропускной способностью 56 Кбит/с — 1785. При наличии высокоскоростных каналов, таких как Gigabit Ethernet или STM-16/64, администратору нужно задать другую шкалу скоростей, назначив единичное расстояние наиболее скоростному каналу.

При выборе оптимального пути на графе с каждым ребром графа связывается метрика, которая добавляется к пути, если данное ребро в него входит. Пусть в приведенном на рис. 17.18 примере маршрутизатор R5 связан с маршрутизаторами R6 и R7 каналами Т-1, а маршрутизаторы R6 и R7 связаны между собой каналом 56 Кбит/с. Тогда R7 определит оптимальный маршрут до сети 201.106.14.0 как составной, проходящий сначала через R5, а затем через R6, поскольку у этого маршрута метрика будет равна 65 + 65 = 130 единиц. Непосредственный маршрут через R6 не будет оптимальным, так как его метрика равна 1785.

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

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

Маршрутизация в неоднородных сетях

Взаимодействие протоколов маршрутизации

В одной и той же сети могут одновременно работать несколько разных протоколов маршрутизации (рис. 17.19). Это означает, что на некоторых (не обязательно всех) маршрутизаторах сети установлено и функционирует несколько протоколов маршрутизации, но при этом, естественно, через сеть взаимодействуют только одноименные протоколы. То есть если маршрутизатор 1 поддерживает, например, протоколы RIP и OSPF, маршрутизатор 2 — только RIP, а маршрутизатор 3 — только OSPF, то маршрутизатор 1 будет взаимодействовать с маршрутизатором 2 по протоколу RIP, с маршрутизатором 3 — по OSPF, а маршрутизаторы 2 и 3 вообще непосредственно друг с другом взаимодействовать не смогут.

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

чТаблица маршрутизации г1' 'pi 1 { 'RIP I ?, r.s '.л; . ТаблицамаршрутизацииI

Рис. 17.19. Применение нескольких протоколов маршрутизации в одной сети

По умолчанию каждый протокол маршрутизации, работающий на определенном маршрутизаторе, распространяет только «собственную» информацию, то есть ту информацию, которая была получена данным маршрутизатором по данному протоколу. Например, если о маршруте к некоторой сети маршрутизатор узнал по протоколу RIP, то и распространять по сети объявления об этом маршруте он будет с помощью протокола RIP.

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

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

Внутренние и внешние шлюзовые протоколы

Такое решение было найдено для самой крупной на сегодня составной сети — Интернета. Это решение базируется на понятии автономной системы.

Автономная система (Autonomous System, AS) — это совокупность сетей под единым административным управлением, обеспечивающим общую для всех входящих в автономную систему маршрутизаторов политику маршрутизации.

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

В соответствии с этой концепцией Интернет выглядит как набор взаимосвязанных автономных систем, каждая из которых состоит из взаимосвязанных сетей (рис. 17.20), соединенными внешними шлюзами.

Рис. 17.20. Автономные системы Интернета

Основная цель деления Интернета на автономные системы — обеспечение многоуровневого подхода к маршрутизации. До введения автономных систем предполагался двухуровневый подход, то есть сначала маршрут определялся как последовательность сетей, а затем вел непосредственно к заданному узлу в конечной сети (именно этот подход мы использовали до сих пор).

С появлением автономных систем появляется третий, верхний, уровень маршрутизации — теперь сначала маршрут определяется как последовательность автономных систем, затем — как последовательность сетей и только потом ведет к конечному узлу.

Выбор маршрута между автономными системами осуществляют внешние шлюзы, использующие особый тип протокола маршрутизации, так называемый внешний шлюзовой протокол (Exterior Gateway Protocol, EGP). В настоящее время для работы в такой роли сообщество Интернета утвердило стандартный пограничный шлюзовой протокол версии 4 (Border Gateway Protocol, BGPv4). В качестве адреса следующего маршрутизатора в протоколе BGPv4 указывается адрес точки входа в соседнюю автономную систему.

За маршрут внутри автономной системы отвечают внутренние шлюзовые протоколы (Interior Gateway Protocol, IGP). К числу IGP относятся знакомые нам протоколы RIP, OSPF и IS-IS. В случае транзитной автономной системы эти протоколы указывают точную последовательность маршрутизаторов от точки входа в автономную систему до точки выхода из нее.

ПРИМЕЧАНИЕ-

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

Концепция автономных систем скрывает от администраторов магистрали Интернета проблемы маршрутизации пакетов на более низком уровне — уровне сетей. Для администратора магистрали неважно, какие протоколы маршрутизации применяются внутри автономных систем, для него существует единственный протокол маршрутизации — BGPv4.

Протокол BGP

Пограничный (внешний) шлюзовой протокол (Border Gateway Protocol, BGP) версии 4 является сегодня основным протоколом обмена маршрутной информацией между автономными системами Интернета. Протокол BGP пришел на смену протоколу EGP62, использовавшемуся в тот начальный период, когда Интернет имел единственную магистраль. Эта магистраль являлась центральной автономной системой, к которой присоединялись в соответствии с древовидной топологией все остальные автономные системы. Так как между автономными системами при такой структуре петли исключались, протокол EGP не предпринимал никаких мер для того, чтобы исключить зацикливание маршрутов.

BGPv4 успешно работает при шбой топологий тпщш между автономными еиотейамй* что соответствует ооврвмонному сщтнт Интернета,

Поясним основные принципы работы BGP на примере (рис. 17.21).

Рис. 17.21. Поиск маршрута между автономными системами с помощью протокола BGP

В каждой из трех автономных систем (AS 1021, AS 363 и AS 520) имеется несколько маршрутизаторов, исполняющих роль внешних шлюзов. На каждом из них работает протокол BGP, с помощью которого они общаются между собой.

Маршрутизатор взаимодействует с другими маршрутизаторами по протоколу BGP только в том случае, если администратор явно указывает при конфигурировании, что эти маршрутизаторы являются его соседями. Например, маршрутизатор EG1 в рассматриваемом примере будет взаимодействовать по протоколу BGP с маршрутизатором EG2 не потому, что эти маршрутизаторы соединены двухточечным каналом, а потому, что при конфигурировании маршрутизатора EG1 в качестве соседа ему был указан маршрутизатор EG2 (с адресом 194.200.30.2). Аналогично, при конфигурировании маршрутизатора EG2 его соседом был назначен маршрутизатор EG1 (с адресом 194.200.30.1).

Такой способ взаимодействия удобен в ситуации, когда маршрутизаторы, обменивающиеся маршрутной информацией, принадлежат разным поставщикам услуг (ISP). Администратор ISP может решать, с какими автономными системами он будет обмениваться трафиком, а с какими нет, задавая список соседей для своих внешних шлюзов. Протоколы RIP и QSPF, разработанные для применения внутри автономной системы, обмениваются маршрутной информацией со всеми маршрутизаторами, находящимися в пределах их непосредственной досягаемости (по локальной сети или через двухточечный канал). Это означает, что информация обо всех сетях появляется в таблице маршрутизации каждого маршрутизатора, так что каждая сеть оказывается достижимой для каждой. В корпоративной сети это нормальная ситуация, а в сетях ISP нет, поэтому протокол BGP и исполняет здесь особую роль.

Для установления сеанса с указанными соседями BGP-маршрутизаторы используют протокол TCP (порт 179). При установлении BGP-сеанса могут применяться разнообразные способы аутентификации маршрутизаторов, повышающие безопасность работы автономных систем.

Основным сообщением протокола BGP является сообщение UPDATE (обновить), с помощью которого маршрутизатор сообщает маршрутизатору соседней автономной системы о достижимости сетей, относящихся к его собственной автономной системе. Само название этого сообщения говорит о том, что это — триггерное объявление, которое посылается соседу только тогда, когда в автономной системе что-нибудь резко меняется: появляются новые сети или новые пути к сетям либо же, напротив, исчезают существовавшие сети или пути.

В одном сообщении UPDATE можно объявить об одном новом маршруте или аннулировать несколько маршрутов, переставших существовать. Под маршрутом в BGP понимается последовательность автономных систем, которую нужно пройти на пути к указанной в адресе сети. Более формально информация о маршруте (BGP Route) к сети (Network/ Mask_length) выглядит так:

BGP Route = AS_Path; NextHop; Network/Mask length;

Здесь AS_P&th — набор номеров автономных систем, NextHop — IP-адрес маршрутизатора, через который нужно передавать пакеты в сеть Network/Mask_length. Например, если маршрутизатор EG1 хочет объявить маршрутизатору EG2 о том, что в AS 1021 появилась новая сеть 202.100.5.0/24, то он формирует такое сообщение:

AS 1021; 194.200.30.1; 202.100.5.0/24,

после чего передает его маршрутизатору EG2 автономной системы AS 363 (с которым у него, конечно, должен быть установлен BGP-сеанс).

Маршрутизатор EG2, получив сообщение UPDATE, запоминает в своей таблице маршрутизации информацию о сети 202.100.5.0/24 вместе с адресом следующего маршрутизатора 194.200.30.1 и отметкой о том, что эта информация была получена по протоколу BGP. Маршрутизатор EG2 обменивается маршрутной информацией с внутренними шлюзами системы AS 363 по какому-либо протоколу группы IGP, например OSPF. Если у EG2 установлен режим перераспределения маршрутов BGP в маршруты OSPF, то все внутренние шлюзы AS 363 узнают о существовании сети 202.100.5.0/24 с помощью объявления OSPF, которое будет внешним. В качестве адреса следующего маршрутизатора маршрутизатор EG2 начнет теперь объявлять адрес собственного внутреннего интерфейса, например 192.17.100.2.

Однако для распространения сообщения о сети 202.100.5.0/24 в другие автономные системы, например в AS 520, протокол OSPF использоваться не может. Маршрутизатор EG3, связанный с маршрутизатором EG4 автономной системы 520, должен пользоваться протоколом BGP, генерируя сообщение UPDATE нужного формата. Для решения этой задачи он не может задействовать информацию о сети 202.100.5.0/24, полученную от протокола OSPF через один из своих внутренних интерфейсов, так как она имеет другой формат и не содержит, например, сведений о номере автономной системы, в которой находится эта сеть.

Проблема решается за счет того, что маршрутизаторы EG2 и EG3 также устанавливают между собой BGP-сеанс, хотя они и принадлежат одной и той же автономной системе. Такая реализация протокола BGP называется внутренней (Interior BGP, iBGP), в отличие от основной, внешней (Exterior BGP, eBGP). В результате маршрутизатор EG3 получает нужную информацию от маршрутизатора EG2 и передает ее внешнему соседу — маршрутизатору EG4. При формировании нового сообщения UPDATE маршрутизатор EG3 трансформирует сообщение, полученное от маршрутизатора EG2, добавляя в список автономных систем собственную автономную систему AS 520, а полученный адрес следующего маршрутизатора заменяет адресом собственного интерфейса:

AS 363, AS 1021; 132.15.64.3; 202.100.5.0/24.

Номера автономных систем позволяют исключать зацикливание сообщений UPDATE. Например, когда маршрутизатор EG5 передаст сообщение о сети 202.100.5.0/24 маршрутизатору EG6, то последний не будет его использовать, так как оно будет иметь вид:

AS 520, AS 363, AS 1021; 201.14.110.3; 202.100.5.0/24.

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

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

Протокол ICMP

сообщений (Internet Control Message Protocol, ICMP) (RFC 792) является вспомогательным протоколом» йолользующимся для диагностики и мониторинга сети. ' ? *г ? * ? 4

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

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

Протокол ICMP также служит дополнением, компенсирующим ненадежность протокола IP, но несколько другого рода. Он не предназначен для исправления возникших при передаче пакета проблем: если пакет потерян, ICMP не может послать его заново. Задача ICMP другая — он является средством оповещения отправителя о «несчастных случаях», произошедших с его пакетами. Пусть, например, протокол IP, работающий на каком-либо маршрутизаторе, обнаружил, что пакет для дальнейшей передачи по маршруту необходимо фрагментировать, но в пакете установлен признак DF (не фрагментировать). Протокол IP, обнаруживший, что он не может передать IP-пакет далее по сети, прежде чем отбросить пакет, должен отправить диагностическое ICMP-сообщение конечному узлу-источнику.

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

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

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

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

1 байт^->1 байт-*<-2 байта-? ТипКодКонтрольнаясумма Зависит от типа и кода сообщенияЗависит от типа и кода сообщения ? ч ; ,v “уЭаемт^штипаитдаеооЛитий " Рис. 17.22. Формат ЮМР-сообщения

Заголовок ICMP-сообщения состоит из 8 байт:

? тип (1 байт) — числовой идентификатор типа сообщения;

? код (1 байт) — числовой идентификатор, более тонко дифференцирующий тип ошибки;

? контрольная сумма (2 байта) — подсчитывается для всего ICMP-сообщения.

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

На рис. 17.23 показана таблица основных типов ICMP-сообщений. Эти сообщения можно разделить на две группы (помеченные на рисунке условными символами):

? сообщения об ошибках-,

? сообщения запрос-ответ.

Сообщения типа запрос-ответ связаны в пары: эхо-запрос — эхо-ответ, запрос маски -ответ маски, запрос времени — ответ времени. Отправитель сообщения-запроса всегда рассчитывает на получение соответствующего сообщения-ответа.

Таблица кодов Таблица типов ICMP-сообщенийпричин ошибок 3 в/ / / 1V /'КодПричина Значение в поле «Тип»Тип сообщения0Сеть недостижима 1Узел недостижим 2Протокол недостижим 0Эхо-ответ 3Порт недостижим 4Ошибка фрагментации 3Узел назначения недостижим /_L 5Ошибка в маршруте источника 4Подавление источника 16Сеть назначения не известна 5Перенаправление маршрута *7Узел назначения не известен 8Узел-источник изолирован 8Эхо-запросч ? /9Административный запрет • ••••• 11Истечение времени диаграммы V 12Проблема с параметрами пакета^ ? сообщение-запрос СГ> сообщение-ответ / ^ V сообщение-ошибкаЧхУ, ? N^хУ 13Запрос отметки времени 14Ответ отметки времени 17Запрос маски 18Ответ маски Рис. 17.23. Типы и коды ICMP-сообщений

Сообщения, относящиеся к группе сообщений об ошибках, конкретизируются уточняющим кодом. На рисунке показан фрагмент таблицы кодов для сообщения об ошибке недостижимости узла назначения, имеющей тип 3. Из таблицы мы видим, что это сообщение может быть вызвано различными причинами, такими как неверный адрес сети или узла (код О или 1), отсутствием на конечном узле-адресате необходимого протокола прикладного уровня (код 2 — «протокол недостижим») или открытого порта UDP/TCP (код 3 — «порт недостижим»). Узел (или сеть) назначения может быть также недостижим по причине временной неработоспособности аппаратуры или из-за того, что маршрутизатор не имеет данных о пути к сети назначения. Всего таблица содержит 15 кодов. Аналогичные таблицы кодов существуют и для других типов сообщений об ошибках.

Утилита traceroute

В качестве примера рассмотрим использование сообщений об ошибках в популярной утилите мониторинга сети traceroute.

Когда маршрутизатор не может передать или доставить IP-пакет, он отсылает узлу, отправившему этот пакет, сообщение о недостижимости узла назначения. Формат этого сообщения показан на рис. 17.24. В поле типа помещается значение 3, а в поле кода — значение из диапазона 0-15, уточняющее причину, по которой пакет не был доставлен. Следующие за полем контрольной суммы четыре байта заголовка не используются и заполняются , нулями.

-1 байт—? <—1 байт—

-2 байта-

Тип = 3

Код ? -15

Контрольная

сумма

Не используется

CL

,1

0

1 го со

Поле данных

Заголовок + 8 первых бейт поля денных, вызвавшего ошибку 1Р-пвквта

’*!• '’Vx-V* •; /Гл' V у. }

Рис. 17.24. Формат ICMP-сообщения об ошибке недостижимости узла назначения

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

ICMP-сообщения об ошибках лежат в основе работы популярной утилиты traceroute Unix, имеющей в Windows название tracert. Эта утилита позволяет проследить маршру удаленного хоста, определить среднее время оборота (RTT), IP-адрес и в некоторых сл; ях доменное имя каждого промежуточного маршрутизатора. Такая информация помо найти маршрутизатор, на котором обрывается путь пакета к удаленному хосту.

Утилита traceroute осуществляет трассировку маршрута, посылая серию обычных пакетов в конечную точку изучаемого маршрута. Идея метода состоит в следующем. Зн. ние времени жизни (TTL) первого отправляемого пакета устанавливается равным 1. К< протокол IP первого маршрутизатора принимает этот пакет, то он в соответствии со св> алгоритмом уменьшает значение TTL на 1 и получает 0. Маршрутизатор отбрасывает ш с нулевым временем жизни и возвращает узлу-источнику ICMP-сообщение об ошв истечения времени дейтаграммы (значение поля типа равно 11) вместе с заголовкох и первыми 8 байтами потерянного пакета.

Получив ICMP-сообщение о причине недоставки пакета, утилита traceroute запомш адрес первого маршрутизатора (который извлекает из заголовка IP-пакета, несуии ICMP-сообщение).

Затем traceroute посылает следующий IP-пакет, но теперь со значением TTL, равных Этот пакет благополучно проходит первый маршрутизатор, но «умирает» на втором, о1 немедленно отправляется аналогичное ICMP-сообщение об ошибке истечения врехи дейтаграммы. Утилита traceroute запоминает адрес второго маршрутизатора и т. д. Та

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

Далее приведена копия экранной формы, выведенной утилитой tracert (Windows) при трассировке хоста ds.jnternic.net [198.49.45.29]:

1 311 ms 290 ms 261 ms 144.206.192.100

2 281 ms 300 ms 271 ms 194.85.73.5

3 2023 ms 290 ms 311 ms moscow-m9-2-S5.relcom.eu.net [193.124.254.37]

4 290 ms 261 ms 280 ms MSK-M9-13.Relcom.EU.net [193.125.15.13]

5 270 ms 281 ms 290 ms MSK.RAIL-l-ATM0-155Mb.Relcom.EU.net [193.124.254.82]

6 300 ms 311 ms 290 ms SPB-RASC0M-l-E3-l-34Mb.Relcom.EU.net [193.124.254.78]

7 311 ms 300 ms 300 ms Hssill-0.GW1.STK2.ALTER.NET [146.188.33.125]

8 311 ms 330 ms 291 ms 421.ATM6-0-0.CR2.STK2.Alter.Net [146.188.5.73]

9 360 ms >331 ms 330 ms 219.Hssi4-0.CR2.LND1.A1ter.Net [146.188.2.213]

10 351 ms 330 ms 331 ms 412.Atm5-0.BRl.LNDl.Alter.net [146.188.3.205]

11 420 ms 461 ms 420 ms 167.ATM8-0-0.CR1.ATL1.Alter.Net [137.39.69.182]

12 461 ms 441 ms 440 ms 311.ATM12-0-0.BR1.ATL1.A1ter.Net [137.39.21.73]

13 451 ms 410 ms 431 ms atlantal-brl.bbnplanet.net [4.0.2.141]

14 420 ms 411 ms 410 ms viennal-br2.bbnplanet.net [4.0.3-.154]

15 411 ms 430 ms 2514 ms viennal-nbr3.bbnplanet.net [4.0.3.150]

16 430 ms 421 ms 441 ms viennal-nbr2.bbnplanet.net [4.0.5.45]

17 431 ms 451 ms 420 ms cambridgel-brl.bbnplanet.net [4.0.5.42]

18 450 ms 461 ms 441 M C cambridgel-crl4.bbnplanet.net [4.0.3.94]

19 451 M C 461 M C 460 M C attbcstoll.bbnplanet.net [206.34.99.38]

20 501 M C 460 M C 481 M C shutdown.ds.internic.net [198.49.45.29]

Последовательность строк соответствует последовательности маршрутизаторов, образующих маршрут к заданному узлу. Первое число в строке — число хопов до соответствующего маршрутизатора. Утилита traceroute тестирует каждый маршрутизатор трижды, поэтому следующие три числа в строке — это значения RTT, вычисленные путем посылки трех пакетов, время жизни которых истекло на этом маршрутизаторе. Если ответ от какого-либо маршрутизатора не приходит за заданное время, то вместо времени на экране печатается звездочка (*).

Далее идут IP-адрес и доменное имя (если оно имеется) маршрутизатора. Видно, что почти все интерфейсы маршрутизаторов поставщиков услуг Интернета зарегистрированы в службе DNS, а первые два, относящиеся к локальным маршрутизаторам, — нет.

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

Утилита ping

А сейчас давайте рассмотрим представителей другой группы ICMP-сообщений — эхо-запросы и эхо-ответы и поговорим об использовании этих сообщений в известной утилите ping.

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

Формат эхо-запроса и эхо-ответа показан на рис. 17.25. Поле типа для эхо-ответа равно 0, для эхо-запроса — 8; поле кода всегда равно 0 и для запроса, и для ответа. В байтах 5 и 6 заголовка содержится идентификатор запроса, в байтах 7 и 8 — порядковый номер. В поле данных эхо-запроса может быть помещена произвольная информация, которая в соответствии с данным протоколом должна быть скопирована в доле данных эхо-ответа.

<—1 байт^-^г<—1 байт-><-2 байта-? Тип * 0/8Код *0Контрольнаясумма ИдентификаторзапросаПорядковыйномер Потданных •' astern" Рис. 17.25. Формат ICMP-сообщений типа эхо-запрос и эхо-ответ

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

Утилита ping обычно посылает серию эхо-запросов к тестируемому узлу и предоставл пользователю статистику об утерянных эхо-ответах и среднем времени реакции сетг запросы. Утилита ping выводит на экран сообщения следующего вида обо всех постуг ших ответах:

# ping serverl.citmgu.ru

Pinging serverl.citmgu.ru [193.107.2.200] with 64 bytes of data:

Reply from Reply from Reply from Reply from

193.107.2.200

193.107.2.200

193.107.2.200

193.107.2.200

bytes=64 time=256ms bytes=64 time=310ms bytes=64 time=260ms bytes=64 time=146ms

TTL= 123 TTL= 123 TTL= 123 TTL= 123

Из приведенной распечатки видно, что в ответ на тестирующие запросы, посланные узлу server! .mgu.ru, было получено 4 эхо-ответа. Длина каждого сообщения составляет 64 байта. В следующей колонке помещены значения времени оборота (RTT), то есть времени от момента отправки запроса до получения ответа на этот запрос. Как видим, сеть работает достаточно нестабильно — время в последней строке отличается от времени во второй более чем в два раза. На экран выводится также оставшееся время жизни поступивших пакетов.

Выводы

В то время как задачей протокола IP является передача данных между сетевыми интерфейсами в составной сети, основная задача протоколов TCP и UDP заключается в передаче данных между прикладными процессами, выполняющимися на разных конечных узлах сети.

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

Системные очереди к точкам входа прикладных процессов называют портами. Порты идентифицируются номерами и однозначно определяют приложение в пределах компьютера. Если процессы представляют собой популярные общедоступные службы, такие как FTP, telnet, HTTP, TFTP, DNS и т. п., то за ними централизовано закрепляются стандартные (назначенные) номера.

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

Сокетом прикладного процесса называется пара из IP-адреса и номер порта.

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

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

Адаптивная маршрутизация обеспечивает автоматическое обновление таблиц маршрутизации после изменения конфигурации сети.

Адаптивные протоколы маршрутизации делятся на дистанционно-векторные алгоритмы (например, RIP) и алгоритмы состояния связей (например, OSPF).

Протоколы маршрутизации Интернета делятся на внешние (EGP), которые переносят маршрутную информацию между автономными системами, и внутренние (IGP), которые применяются только впределах определенной автономной системы.

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

Вопросы и задания

1. Какой объем данных получен в течение TCP-сеанса отправителем TCP-сегмента, в заголовке которого в поле квитанции помещено значение 180005? Известно, что первый полученный байт имел номер 15000.

2. Может ли работать маршрутизатор, не имея таблицы маршрутизации? Варианты ответов:

а) может, если выполняется маршрутизация от источника;

б) нет, это невозможно;

в) может, если в маршрутизаторе задан маршрут по умолчанию;

г) может, если выполняется лавинная маршрутизация.

3. Можно ли обойтись в сети без протоколов маршрутизации?

4. Система DNS может использовать для доставки своих сообщений как протокол UDP, так и TCP. Какой вариант вы считаете более предпочтительным? Аргументируйте свой ответ.

5. По какой причине в протоколе RIP расстояние в 16 хопов между сетями полагается недостижимым? Варианты ответов:

а) поле, отведенное для хранения значения расстояния, имеет длину 4 двоичных разряда;

б) сети, в которых работает RIP, редко бывают большими;

в) для получения приемлемого времени сходимости алгоритма.

6. Какие параметры сети учитывают метрики, поддерживаемые протоколом OSPF? Варианты ответов:

а) пропускная способность;

б) количество хопов;

в) надежность каналов связи.

7. ICMP-сообщение об ошибке не посылается, если ошибка возникла при передаче IP-пакета:

а) несущего ICMP-сообщение об ошибке;

б) являющегося последним фрагментом пакета;

в) несущего ЮМР-запрос;

г) упакованного в кадр с широковещательным МАС-адресом.

8. Кому адресовано ICMP-сообщение? Варианты ответов:

а) протоколу IP узла-отправителя пакета, вызвавшего ошибку;

б) протоколу IP ближайшего маршрутизатора, от которого поступил пакет, вызвавший ошибку;

в) протоколу транспортного или прикладного уровня узла-отправителя пакета, вызвавшего ошибку.

9. Предложите варианты метрики, которая одновременно учи+ывает пропускную способность, надежность и задержку линий связи.

ГЛАВА 18 Дополнительные

функции

маршрутизаторов

IP-сетей

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

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

Сравнительно новым свойством IP-сетей является поддержка параметров качества обслуживания (QoS). Отдельные механизмы, необходимые для контроля и предотвращения перегрузок, IP-маршрутизаторы поддерживают на протяжении уже долгого времени, однако стандарты систем обеспечения QoS были разработаны для IP-сетей только в конце 90-х. Существуют две технологии поддержания параметров QoS для IP-сетей — это интегрированное и дифференцированное обслуживание. Первая обеспечивает качество обслуживания для отдельных потоков, а вторая разработана для агрегированных потоков, представляющих небольшое число классов трафика.

Еще одним очень перспективным направлением в развитии стека TCP/IP является групповое вещание (multicast). Помимо больших коммерческих перспектив эта технология увлекает исследователей своей сложностью. Действительно, немного задач можно сравнить по грандиозности с проблемой создания эффективного механизма одновременной доставки информации миллионам и миллиардам людей и устройств во всемирном масштабе.

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

Фильтрация

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

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

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

Фильтрация пользовательского трафика

Под фильтрацией понимается нестандартная обработка |Р-пакет08 маршрутизаторами, приво*

С дящая к отбрасыванию некоторых пакетов или изменение йх мзрщрута.

Фильтрация пользовательского трафика маршрутизаторами аналогична по принципу действия фильтрации, выполняемой коммутаторами локальных сетей (см. главу 14).

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

? IP-адреса источника и приемника;

? МАС-адреса источника и приемника;

? идентификатор интерфейса, с которого поступил пакет;

? тип протокола, сообщение которого несет IP-пакет (то есть TCP, UDP, ICMP или OSPF);

? номер порта TCP/UDP (то есть тип протокола прикладного уровня).

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

Рассмотрим примеры фильтров, написанных на командном языке маршрутизаторов Cisco. Эти фильтры, называемые списками доступа, сегодня в IP-маршрутизаторах являются очень распространенным средством ограничения пользовательского трафика.

Наиболее простым является стандартный список доступа; в нем в качестве условия фильтрации учитывается только IP-адрес источника.

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

access-list номер_списка_доступа { deny | permit }

{ адрес_источника [ метасимволы_источника ] | any}

Стандартный список доступа определяет два действия с пакетом, который удовлетворяет описанному в фильтре условию: отбросить (deny) или передать для стандартной обработки в соответствии с таблицей маршрутизации (permi t). Условием выбора того или иного действия в стандартном списке доступа является совпадение IP-адреса источника пакета с адресом источника, заданным в списке. Совпадение проверяется в том же стиле, что и при проверке таблицы маршрутизации, при этом метасимволы являются аналогом маски, но в несколько модифицированном виде. Двоичный нуль в поле метасимволов источника означает, что требуется совпадение значения этого разряда в адресе пришедшего пакета и в адресе, заданном в списке доступа. Двоичная единица означает, что совпадения в этом разряде не требуется. Практически, если вы хотите задать условие для всех адресов некоторой подсети, то должны использовать инвертированное значение маски этой подсети. Параметр any означает любое значение адреса — это просто более понятная и краткая форма записи значения 255.255.255.255 в поле метасимволов источника.

Пример стандартного списка доступа:

access-list 1 deny 192.78.46.0 0.0.0.255 Здесь:

? 1 — номер списка доступа;

? deny — действие с пакетом, который удовлетворяет условию данного списка доступа;

? 192.78.46.0 — адрес источника;

? 0.0.0.255 — метасимволы источника.

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

Список доступа может включать более одного условия. В этом случае он состоит из нескольких строк с ключевым словом access-1 i st и одним и тем же номером списка доступа. Так, если мы хотим разрешить прохождение через маршрутизатор пакетов хоста 192.78.46.12, запрещая передачу пакетов одному из хостов сети 192.78.46.0/24, то список доступа будет выглядеть следующим образом:

access-list 1 permit 192.78.46.12 0.0.0.0 access-list 1 deny 192.78.46.0 0.0.0.255 access-list 1 permit any

Условия списка доступа проверяются по очереди, если какое-либо из них дает совпадение, то выполняется действие permi t или deny, определенное в этом условии. После этого остальные условия списка уже не проверяются. Считается по умолчанию, что в конце каждого списка имеется неявное условие вида:

[access-list 1 deny any]

Однако, если вам все же требуется пропускать все пакеты, не определенные явно в условиях, необходимо добавить в последней строке условие:

access-list 1 permit any

Список доступа можно применять к любому интерфейсу маршрутизатора и в любом направлении: если список применяется с ключевым словом i п, то он действует на входящие в интерфейс пакеты, а если с ключевым словом out — на выходящие. Например, написанный нами список доступа 1 можно применить к некоторому интерфейсу для обработки входящего трафика, используя следующую команду: access-group 1 in

Существуют также и более мощные типы списков доступа для маршрутизаторов Cisco, например, расширенные списки доступа. Общий формат этих списков следующий:

access-list номер_списка_доступа { deny | permit }

{ protocol | ключевое_слово_протокола }

{ адрес_источника [ метасимволы_источника ]] [ порт_источника ] | any }

[ адрес_приемника [ метасимволы_приемника ]] [ порт_приемника ]

Пользуясь расширенными списками доступа, можно запретить прохождение во внутреннюю сеть предприятия FTP-пакетов. Как известно, служба FTP использует для приема запросов от клиентов протокол TCP с хорошо известным портом 21. Для этого в список доступа нужно включить условие: access-list 102 deny TCP any 21 any

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

Администраторы корпоративных сетей из соображений безопасности1 часто запрещают возможность трассировки извне внутренних хостов утилитой ping. Это делается с помощью условия:

access-list 101 deny ICMP any 192.78.46.8 0.0.0.0 eq 8

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

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

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

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

См. об этом в главе 24.

Фильтрация маршрутных объявлений

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

Пусть, например, маршрутизаторы Cisco должны ограничить распространение маршрутных объявлений о какой-нибудь сети. Для этого нужно включить описание данной сети в стандартный список доступа, а затем применить к интерфейсу специальную команду с ключевым словом distribute-list (вместо access- group, как в случае фильтрации пользовательского трафика).

Например, если администратор не хочет, чтобы информация о внутренних сетях -194.12.34.0/24 и 132.7.0.0/16 предприятия распространялась по внешним сетям, ему достаточно написать следующий стандартный список доступа:

access-list 2 deny 194.12.34.0 0.0.0.255 access-list 2 deny 132.7.0.0 0.0.255.255 access-list 2 permit any

После этого достаточно применить его к интерфейсу с помощью команды

distribute-list 2 out serial 1

Стандарты QoS в IP-сетях

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

^результате были разработаны две системы стандартов QoS для 1Р-сетей:

2 система интефированного обслуживания (Integrated Services, IntServ) ориентирована на предоставление гарантий QoS для потоков конечных пользователей (именно Поэтому технология intServ применяется в основном на периферии сети);

3 система дифференцированного обслуживания (Differentiated Services, DiffSetv) делает то же самое для классов трафика, и следовательно, ее предпочтительнее использовать на магистрали.

Обе системы опираются на все базовые элементы основанной на резервировании схемы поддержания параметров QoS, к которым относятся:

? кондиционирование трафика;

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

? резервирование пропускной способности интерфейсов маршрутизаторов для потоков и классов;

? приоритетные и взвешенные очереди.

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

Модели качества обслуживания IntServ и DiffServ

Направление IntServ начало разрабатываться в IETF еще в начале 90-х годов и было первым направлением, в рамках которого проблема обеспечения параметров QoS в сетях ТСР/ IP начала решаться систематически. Базовая модель IntServ предполагает интегрированное взаимодействие маршрутизаторов сети по обеспечению требуемого качества обслуживания вдоль всего пути микропотока между конечными компьютерами.

Ресурсы маршрутизаторов (пропускная способность интерфейсов, размеры буферов) распределяются в соответствии с QoS-запросами приложений в пределах, разрешенных политикой QoS для данной сети. Эти запросы распространяются по сети сигнальным протоколом резервирования ресурсов (Resource reSerVation Protocol, RSVP), который позволяет выполнять резервирование ресурсов для потоков данных.

Однако система IntServ обеспечения параметров QoS нашла довольно много противников, преимущественно среди поставщиков услуг Интернета (ISP). Дело в том, что при интегрированном обслуживании магистральные ISP-маршрутизаторы должны оперировать информацией о состоянии десятков тысяч микропотоков, проходящих через ISP-сети. Такая нагрузка на маршрутизаторы требует коренного пересмотра их архитектуры и, естественно, ведет к резкому повышению стоимости IP-сетей и предоставляемых ими услуг.

Поэтому в конце 90-х была создана другая более экономически эффективная технология QoS в IP-сетях, получившая название дифференцированного обслуживания (DiffServ). Она изначально была ориентирована на применение в пределах ISP-сетей, а конечные узлы, генерирующие микропотоки, в расчет не брались. Для технологии DiffServ поддержка параметров QoS начинается на пограничном маршрутизаторе ISP-сети, на который поступает большое количество микропотоков из сетей пользователей. Каждый пограничный маршрутизатор классифицирует и маркирует входящий трафик, разделяя его на небольшое числа классов, обычно 3-4 (максимум — 8). Затем каждый маршрутизатор сети обслуживает классы трафика дифференцированно в соответствии с произведенной маркировкой, выделяя каждому классу определенное количество ресурсов. Резервирование ресурсов маршрутизаторов производится статически, чаще всего вручную администратором сети. Роль сигнального протокола играют метки принадлежности пакетов к тому или иному классу.

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

Модель DiffServ существенно снижает нагрузку на маршрутизаторы ISP-сети, так как требует хранить информацию о состоянии только небольшого количества классов. Кроме того, эта модель удобна для поставщиков услуг тем, что позволяет поддерживать параметры QoS автономно, только в пределах своих сетей. Однако за эти преимущества приходится платить, и прежде всего, отказом от гарантии сквозной поддержки параметров QoS. Даже если каждый поставщик услуг обеспечит дифференцированное обслуживание в своей сети, общая картина получится фрагментированной, так как за каждый фрагмент отвечает отдельный администратор, и согласование параметров резервирования остается исключительно субъективной процедурой, не поддерживаемой никакими протоколами.

Ведутся также работы по комбинированному применению технологий IntServ и DiffServ. Каждая технология в этих моделях работает в своей области, IntServ — в сетях доступа, где количество микропотоков относительно невелико, a DiffServ — в магистральных сетях. Еще одним компонентом, дополняющим DiffServ, является технология MPLS (см. главу 20).

Обе технологии (IntServ и DiffServ) опираются на одни и те же базовые механизмы QoS. В частности, 6 IP-маршрутизаторах для профилирования и формирования трафика применяется алгоритм ведра маркеров.

Алгоритм ведра маркеров

Алгоритм ведра маркеров позволяет оценить и ограничить среднюю скорость и величину пульсации потока пакетов. Этот алгоритм основан на сравнении потока пакетов с некоторым эталонным потоком. Эталонный поток представлен маркерами, заполняющими условное «ведро» маркеров (рис. 18.1).

Генератор

Под маркером в данном случае понимается некий абстрактный объект, носитель «порции» информации, используемый для построения эталонного потока. Генератор маркеров периодически с постоянным интервалом w направляет очередной маркер в «ведро» с ограниченным объемом b байт. Все маркеры имеют одинаковый объем т байт, а генерация маркеров происходит так, что «ведро» заполняется со скоростью г бит/с. Нетрудно подсчитать, что г = 8m/w. Эта скорость г и является максимальной средней скоростью для трафика пакетов, а объем ведра соответствует максимальному размеру пульсации потока пакетов. Если ведро заполняется маркерами «до краев» (то есть суммарный объем маркеров в ведре становится равным Ь)у то поступление маркеров временно прекращается. Фактически, ведро маркеров представляет собой счетчик, который наращивается на величину т каждые w секунд.

При применении алгоритма ведра маркеров профиль трафика определяется средней скоростью г и объемом пульсации Ъ.

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

Пакет из входной очереди продвигается сервером на выхрд только в том случае, если к моменту его поступления на сервер «ведро» заполнено маркерами до уровня не ниже М байт, где М — объем пакета.

При продвижении пакета из ведра удаляются маркеры общим объемом в Мбайт (с точностью до размера одного маркера, то есть до т байт).

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

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

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

Алгоритм ведра маркеров допускает пульсацию трафика в определенных пределах. Пусть пропускная способность выходного интерфейса, который моделируется выходом сервера, равна R. Это значит, что сервер не может передавать данные на выход со скоростью, превышающей R бит/с. Можно показать, что на любом интервале времени t средняя скорость исходящего с сервера потока равна минимуму из двух величин: R и г + b/t. При больших значениях t скорость выходного потока стремится к г — это и говорит о том, что алгоритм обеспечивает желаемую среднюю скорость. В то же время в течение небольшого времени t пакеты могут выходить из сервера со скоростью, большей г. Если г + b/t < Я, то они

выходят из сервера со скоростью г + b/t, в противном случае интерфейс ограничивает эту скорость до величины R. Период времени t соответствует пульсации трафика. Эта ситуация наблюдается тогда, когда в течение некоторого времени пакеты не поступали в сервер, так что ведро полностью заполнилось маркерами (то есть времени, большего, чем Ь/r). Если после этого на вход сервера поступит большая группа пакетов, следующих один за другим, то эти пакеты будут передаваться на выход со скоростью выходного интерфейса R также один за другим, без интервалов. Максимальное время такой пульсации составляет b/(R - г) секунд, после чего обязательно наступит пауза, необходимая для наполнения опустевшего ведра. Объем пульсации составляет Rb/(R - г) байт. Из приведенного соотношения видно, что алгоритм ведра маркеров начинает плохо работать, если средняя скорость г выбирается близкой к пропускной способности выходного интерфейса. В этом случае пульсация может продолжаться очень долго, что обесценивает алгоритм.

Случайное раннее обнаружение

Механизм профилирования TCP-трафика, названный случайным ранним обнаружением

(Random Early Detection, RED), разработан сообществом Интернета для предотвращения перегрузок на магистралях Интернета.

RED работает с протоколом TCP, используя свойство последнего, которое заключается в том, что при потерях пакетов источник трафика замедляет передачу пакетов в сеть. В алгоритме RED имеются два конфигурируемых rtopora уровня перегрузки (рис. 18.2). Когда уровень перегрузки не превышает первого (нижнего) порога, то пакеты не отбрасываются. Когда уровень перегрузки находится между двумя порогами, пакеты отбрасываются с линейно возрастающей вероятностью из диапазона от 0 до конфигурируемой величины (максимальной вероятности отбрасывания пакета). Максимальная вероятность отбрасывания действует при достижении второго (верхнего) порога. Когда же перегрузка превышает второй порог, пакеты начинают отбрасываться с вероятностью 100 %.

Вероятность отбрасывания пакетов

В качестве показателя перегрузки используется вычисляемое среднее значение длины очереди пакетов, относящейся к определенному ТСР-сеансу.

ПРИМЕЧАНИЕ-

Заметим, что для UDP-трафика механизм RED неприменим, так как протокол UDP работает без установления логического соединения и, следовательно, потерь пакетов не замечает.

В том случае, когда нужно обеспечить разные параметры обратной связи для разных классов трафика, применяется взвешенный алгоритм случайного раннего обнаружения (Weighted Random Early Detection, WRED). Этот вариант алгоритма RED позволяет задавать для каждого класса трафика свои значения нижнего и верхнего порогов, а также вероятность отбрасывания пакетов. Обычно механизмы WRED и WFQ применяются совместно, обеспечивая надежную доставку TCP-трафика с гарантированной скоростью.

Интегрированное обслуживание и протокол RSVP

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

IG Р-марш рутизатор

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

Далее описана процедура резервирования необходимых ресурсов сети с помощью протокола RSVP, а в табл. 18.1 сведены воедино все упоминаемые в этом описании типы сообщений.

1. Источник данных (компьютер С1 на рис. 18.3) посылает получателям по уникальному или групповому (как на рисунке) адресу специальное РАТН-сообщение, в котором указывает рекомендуемые параметры для качественного приема своего трафика: верхние и нижние границы пропускной способности, задержки и вариации задержки. Эти параметры составляют спецификацию трафика источника. РАТН-сообщение передается маршрутизаторами сети в направлении ко всем указанным в групповом адресе получателям. В качестве параметров трафика применяются параметры алгоритма ведра маркеров, то есть средняя скорость и глубина ведра. Кроме того, дополнительно могут быть заданы максимально допустимая скорость и предельные размеры пакетов потока.

2. Каждый маршрутизатор, поддерживающий протокол RSVP, получив РАТН-сообщение, фиксирует «состояние пути», которое включает предыдущий адрес источника РАТН-сообщения, то есть последний по времени шаг в обратном направлении (ведущий к источнику). Это необходимо для того, чтобы ответ приемника прошел по тому же пути, что и РАТН-сообщение.

3. После получения PATH-сообщения приемник отправляет в обратном направлении маршрутизатору, от которого он получил это сообщение, запрос на резервирование ресурсов, то есть RESV-сообщение. На рис. 18.3 показано два приемника, компьютеры С2 и СЗ. В дополнение к спецификациям трафика источника С1 (которые содержат параметры для качественного приема его трафика: верхние и нижние границы пропускной способности, задержки и вариации задержки) RESV-сообщение дополнительно включает спецификацию запроса приемника, в которой указываются требуемые приемнику параметры качества обслуживания, и спецификацию фильтра, которая определяет, к каким пакетам сеанса применять данное резервирование (например, по типу транспортного протокола и номеру порта). Вместе спецификации запроса и фильтра представляют собой дескриптор потока, для которого выполняется резервирование. Запрашиваемые параметры QoS в спецификации запроса могут отличаться от указанных в спецификации трафика. Например, если приемник решает принимать не все посылаемые источником пакеты, а только их часть (что указывается в спецификации фильтра), то ему нужна, соответственно, меньшая пропускная способность.

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

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

6. Когда последний в обратном направлении маршрутизатор получает RESV-сообщение и принимает запрос, то он посылает подтверждающее сообщение узлу-источнику. При групповом резервировании учитывается тот факт, что в точках разветвления дерева доставки несколько резервируемых потоков сливаются в один. Так, в маршрутизаторе R1 в рассматриваемом примере сливаются RESV-сообщения от приемников С2 и СЗ. Если для всех резервируемых потоков запрашивается одинаковая пропускная способность, то она требуется и для общего потока, а если запрашиваются различные величины пропускной способности, то для общего потока выбирается максимальная.

7. После установления состояния резервирования в сети источник начинает отправлять данные, которые обслуживаются на всем пути к приемнику (приемникам) с заданным качеством обслуживания.

Таблица 18.1. Таблица сообщений протокола резервирования ресурсов (RSVP) Типы сообщенийСодержание сообщений РАТН-сообщение от источника к приемникуСпецификация трафика источника Спецификация трафика источникаРекомендуемые параметры для качественного приема своего трафика: верхние и нижние границы пропускной способности, задержки и вариации задержки, параметры алгоритма ведра маркеров, то есть среднюю скорость и глубину ведра, дополнительно могут быть заданы максимально допустимая скорость и предельные размеры пакетов потока Спецификация фильтраОпределяет, к каким пакетам сеанса применять данное резервирование (например, по типу транспортного протокола и номеру порта) Спецификация запроса приемникаТребуемые приемнику параметры качества обслуживания Дескриптор потокаСпецификация фильтра плюс спецификация запроса приемника RESV-сообщение — запрос на резервирование ресурсовСпецификация трафика источника плюс дескриптор потока

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

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

ВНИМАНИЕ-

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

-

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

Для протокола RSVP в настоящее время разработано большое количество расширений, которые делают его пригодным не только для работы в рамках архитектуры RSVP. Одними из наиболее важных являются расширения, относящиеся к инжинирингу трафика. Эти расширения применяются в технологии MPLS, рассматриваемой в главе 20.

Дифференцированное обслуживание

Дифференцированное обслуживание (DiffServ) опирается на ту же обобщенную модель QoS, что и интегрированное обслуживание, однако в качестве объектов обслуживания рассматриваются не отдельные потоки, а классы трафика.

В отличие от потока в классах трафика пакеты не различаются в зависимости от их маршрутов; это отличие иллюстрирует рис. 18.4. Так, маршрутизатор R1 относит все потоки, требующие приоритетного обслуживания и втекающие в его интерфейс il, к одному классу, независимо от их дальнейшего маршрута. Маршрутизатор R2 оперирует уже другим составом приоритетного класса, так как в него вошли не все потоки интерфейса il маршрутизатора R1.

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

действия с другими маршрутизаторами. Такой подход назван независимым поведением маршрутизаторов (Per Hop Behavior, РНВ). Так как в модели DiffServ маршруты пакетов не отслеживаются, то здесь не используется сигнальный протокол резервирования ресурсов, подобный протоколу RSVP в модели IntServ. Вместо этого маршрутизаторы сети выполняют статическое резервирование ресурсов для каждого из поддерживаемых сетью классов.

Рис. 18.4. В модели DiffServ объектами обслуживания являются классы трафика, а не потоки

В качестве признака принадлежности IP-пакета к определенному классу в DiffServ используется метка, переносимая в поле приоритета IP-пакета (ToS-байт), которое с появлением стандартов DiffServ было переопределено и названо DS-байтом. Как показано на рис. 18.5, DS-байт переопределяет значения битов ToS-байта, определенных ранее в соответствующих спецификациях (RFC 791, RFC 1122, RFC 1349).

Биты: 0

Биты: 0 1 2 3 4 5 6 7 • ТипПриоритет; оврв|СаRFC 1122 RFC 1349 Рис. 18.5. Соответствие битов DS-байта битам поля типа сервиса

2 3 4 5 6 7

К

ZZXJ

“нН

Этот бит должен быть нулевым

Код класса дифференцированного Поле типа сервиса (TOS)

обслуживания RFC 791

RFC 2474

В настоящее время используются только старшие 6 битов DS-байта, причем только старшие три из них требуются для определения класса трафика (что дает не более 8-ми различных классов). Младший бит (из используемых шести) DS-байта обычно переносит признак IN - индикатор того, что пакет «вышел» из профиля трафика (аналогично признакам DE в технологии Frame Relay и CPL в технологии АТМ). Промежуточные два бита обычно описывают различные варианты обслуживания пакетов внутри одного класса трафика. Маршрутизатор, поддерживающий модель DiffServ, должен обеспечивать классификацию, маркирование, измерение и кондиционирование трафика, его обслуживание в приоритетной или взвешенной очереди и сглаживание.

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

Модель DiffServ подразумевает существование соглашения об уровне обслуживания (SLA) между доменами с общей границей. Это соглашение определяет критерии политики предоставления сервиса, профиль трафика, а также гарантируемые параметры QoS. Ожидается, что трафик будет формироваться и сглаживаться в выходных точках домена в соответствии с SLA, а во входной точке домена будет кондиционироваться в соответствии с правилами политики. Любой трафик «вне профиля» (например, выходящий за верхние границы полосы пропускания, указанной в SLA) не получает гарантий обслуживания (или же оплачивается по повышенной стоимости в соответствии с SLA). Правила политики предоставления сервиса могут включать время дня, адреса источника и приемника, транспортный протокол, номера портов. В том случае, когда соблюдаются правила политики и трафик удовлетворяет оговоренному профилю, DiffServ-домен должен обеспечить при обслуживании этого трафика параметры QoS, зафиксированные в SLA.

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

? Быстрое продвижение (Expedited Forwarding, EF) характеризуется значением кода 10111 и представляет собой высший уровень качества обслуживания, обеспечивая минимум задержек и вариаций задержек. Любой трафик, интенсивность которого превышает указанную в профиле, отбрасывается.

? Гарантированная доставка (Assured Forwarding, AF) характеризуется четырьмя классами трафика и тремя уровнями отбрасывания пакетов в каждом классе — всего получается 12 различных типов трафика. Каждому классу трафика выделяются определенные минимум пропускной способности и размер буфера для хранения его очереди. Трафик, параметры которого превышают указанные в профиле, доставляется с меньшей степенью вероятности, чем трафик, удовлетворяющий условиям профиля. Это означает, что качество его обслуживания может быть понижено, но он не обязательно будет отброшен.

На основе этих пошаговых спецификаций и соответствующих соглашений об уровне обслуживания (SLA) могут быть построены сервисы для конечных пользователей «из конца вконец» — это EF-сервис и AF-сервис соответственно.

Основное назначение EF-сервиса — обеспечение качества обслуживания, сопоставимого с качеством обслуживания выделенных каналов, поэтому этот сервис называется также сервисом виртуальных выделенных каналов.

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

Четыре класса AF-сервиса ориентированы на гарантированную доставку, но без минимизации уровня задержек пакетов, как это оговорено для EF-сервиса. Гарантированная доставка выполняется в том случае, когда входная скорость трафика не превышает отведенной данному классу минимальной пропускной способности. Реализация классов AF-трафика хорошо сочетается с EF-сервисом — EF-трафик может обслуживаться по приоритетной схеме, но с ограничением интенсивности входного потока. Оставшаяся пропускная способность распределяется между классами AF-трафика в соответствии с алгоритмом взвешенного обслуживания, который обеспечивает необходимую пропускную способность, но не минимизацию задержек. Реализация AF-сервиса предполагает (но не требует) взвешенного обслуживания для каждого класса с резервированной полосой пропускания, а также применения обратной связи (в форме RED).

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

Рис. 18.6. Неопределенность уровня обслуживания в мрдели DiffServ

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

Несмотря на такое достаточно жесткое ограничение, интерфейсы маршрутизаторов сети оказываются под воздействием разной нагрузки. На рис. 18.6 для упрощения ситуации показаны только потоки, требующие особого обслуживания. Так, выходной интерфейс ill маршрутизатора R1 обслуживает два таких потока и нагружен на 40 %, в то время как выходной интерфейс i21 маршрутизатора R2 — только один из них, так как второй поток уходит через другой выходной интерфейс. Выходной же интерфейс i31 маршрутизатора $3 перегружен, обслуживая три таких потока, так что его коэффициент использования равен 60 %. Учитывая факторы, влияющие на образование очередей (см. главу 7), мы знаем, что коэффициент использования является наиболее существенным фактором и значения в районе 50 % являются критическими. Поэтому в интерфейсе i31 возникают длинные очереди пакетов класса особого обслуживания, которые снижают качество такого обслуживания, так как приводят к длительным задержкам и их вариациям, а также потерям пакетов. Кроме того, страдает трафик класса обслуживания с максимальными усилиями, проходящий через этот интерфейс, так как ему достается только 40 % пропускной способности интерфейса.

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

Однако все эти меры не дают гарантии, что все интерфейсы всех маршрутизаторов сети будут работать в нужном диапазоне значений коэффициента использования, а следовательно, обеспечивать заданное качество обслуживания. Для того чтобы дать такие гарантии, необходимо «улучшить» модель DiffServ и применять методы инжиниринга трафика, то есть контролировать не классы, а потоки трафика, в данном случае агрегированные. Под агрегированным понимается поток, состоящий из пакетов одного класса, имеющих общую часть пути через сеть. Эта общая часть не обязательно включает полный путь от входного интерфейса одного из пограничных маршрутизаторов до выходного интерфейса другого пограничного маршрутизатора. Достаточно, чтобы пакеты проходили хотя бы два общих интерфейса, чтобы считать их агрегированным потоком, как, например, в случае потока, проходящего через интерфейсы ill и i22 (см. рис. 18.6).

Затем, зная путь прохождения каждого агрегированного потока через сеть, можно проверить, имеются ли достаточные ресурсы вдоль пути следования каждого потока, например, не превышают ли коэффициенты использования интерфейсов заданного порога. Для этого нужно провести профилирование с учетом адресов назначения пакетов. Однако реализация такого подхода в IP-сетях сталкивается с несколькими трудностями. Во-первых, в технологии Diffserv не предусмотрен сигнальный протокол, такой как, например, RSVP в технологии IntServ. Это означает, что все проверки наличия ресурсов у маршрутизаторов для каждого агрегированного потока нужно выполнять в автономном режиме, вручную или с помощью какого-то специального программного обеспечения. Во-вторых, для проведения таких расчетов нужно знать пути потоков через сеть. Такие пути определяются таблицами маршрутизации, которые строятся протоколом маршрутизации, например RIP или OSPF (либо их комбинацией, если в сети используются несколько протоколов маршрутизации класса IGP), или вручную. Поэтому для ручного или автоматизированного расчета нужно знать таблицы маршрутизации всех маршрутизаторов сети и следить за их изменениями, а это непросто, учитывая, что отказы линий связи или маршрутизаторов приводят к перестройке таблиц. Нужно также учитывать, что маршрутизаторы могут применять методы балансировки нагрузки, разделяя агрегированный поток на несколько подпотоков, что также усложняет расчеты.

«Улучшенная» версия DiffServ, обеспечивающая учет адресов назначения, повышает качество услуг оператора связи, но вместе с тем усложняет саму идею метода, в основе которого лежит идея независимого обслуживания классов трафика каждым маршрутизатором сети.

Трансляция сетевых адресов

Маршрутизация в составной сети осуществляется на основе тех адресов назначения, которые помещены в заголовки пакетов. Как правило, эти адреса остаются неизменными с момента их формирования отправителем до момента поступления на узел получателя. Однако из этого правила есть исключения. Например, в широко применяемой сегодня технологии трансляции сетевых адресов (Network Address Translation, NAT) предполагается продвижение пакета во внешней сети (в Интернете) на основании адресов, отличающихся от тех, которые используются для маршрутизации пакета во внутренней (корпоративной) сети.

Причины подмены адресов

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

Для того чтобы узлы с частными адресами могли связываться через Интернет между собой или с узлами, имеющими глобальные адреса, необходимо использовать технологию NAT.

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

Традиционная технология NAT

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

Идея технологии NAT состоит в следующем. Пусть сеть предприятия образует тупиковый домен, узлам которого присвоены частные адреса (рис. 18.7). На маршрутизаторе, связывающем сеть предприятия с внешней сетью, установлено программное обеспечение NAT. Это NAT-устройство динамически отображает набор частных адресов {IP*} на набор глобальных адресов {IP}, полученных предприятием от поставщика услуг и присвоенных внешнему интерфейсу маршрутизатора предприятия.

Внутренняя сеть

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

Традиционная технология NAT подразделяется на технологии базовой трансляции сетевых адресов (Basic Network Address Translation, Basic NAT) и трансляции сетевых адресов и портов (Network Address Port Translation, NAPT). В технологии Basic NAT для отображения используются только IP-адреса, а в технологии NAPT — еще и так называемые транспортные идентификаторы, в качестве которых чаще всего выступают TCP- и UDP-порты.

Базовая трансляция сетевых адресов

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

Внутренняя сеть А

181.230.25.1181.230.25.2181.230.25.3 Сеть 10.0.2.0/24

Внутренняя сеть В

Таблица NAT-отображения ЧастныеадресаГлобальныеадреса 10.0.1.4181.230.25.1 10.0.2.15181.230.25.2 10.0.2.3181.230.25.3 10.0.1.2 185.127.125.2185.127.125.3185.127.125.4 Сеть 10.0.1.0/24 Таблица NAT-отображения ЧастныеадресаГлобальныеадреса 10.0.1.1185.127.125.2 10.0.1.2185.127.125.3 10.0.1.4185.127.125.4

Рис. 18.8. Базовая трансляция сетевых адресов для исходящих сеансов

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

В нескольких тупиковых доменах могут быть совпадающие частные адреса. Например, в сетях А и В на рис. 18.8 для внутренней адресации применяется один и тот же блок адресов 10.0.1.0/24. В то же время адреса внешних интерфейсов обеих сетей (181.230.25.1/24, 181.230.25.2/24 и 181.230.25.3/24 в сети А и 185.127.125.2/24, 185.127.125.3/24 и 185.127.125.4/24 в сети В) уникальны глобально, то есть никакие другие узлы в составной сети их не используют. В данном примере в каждой из сетей только три узла имеют возможность «выхода» за пределы сети своего предприятия. Статическое соответствие частных адресов этих узлов глобальным адресам задано в таблицах пограничных устройств обеих сетей.

Когда узел 10.0.1.4 сети А посылает пакет хосту 10.0.1.2 сети В, то он помещает в заголовок пакета в качестве адреса назначения глобальный адрес 185.127.125.3/24. Узел-источник направляет пакет своему маршрутизатору R1 по умолчанию, которому известен маршрут к сети 185.127.125.0/24. Маршрутизатор передает пакет на пограничный маршрутизатор R2, которому также известен маршрут к сети 185.127.125.0/24. Перед отправкой пакета модуль NAT, работающий на данном пограничном маршрутизаторе, используя таблицу отображения, заменяет в поле адреса источника частный адрес 10.0.1.4 соответствующим ему глобальным адресом 181.230.25.1/24. Когда пакет после путешествия по внешней сети поступает на внешний интерфейс NAT-устройства сети В, глобальный адрес назначения 185.127.125.3/24 преобразуется в частный адрес 10.0.1.2. Пакеты, передаваемые в обратном направлении, проходят аналогичную процедуру трансляции адресов.

Заметим, что в описанной операции не требуется участия узлов отправителя и получателя, то есть она прозрачна для пользователей.

Трансляция сетевых адресов и портов

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

Для однозначной идентификации узла отправителя привлекается дополнительная информация. Если в IP-пакете находятся данные протокола UDP или TCP, то в качестве такой информации выступают номер UDP- или TCP-порта соответственно. Но и это не вносит полной ясности, поскольку из внутренней сети может исходить несколько запросов с совпадающими номерами портов отправителя, а значит, опять возникает вопрос об однозначности отображения единственного глобального адреса на набор внутренних адресов. Решение состоит в том, что при прохождении пакета из внутренней во внешнюю сеть каждой паре {внутренний частный адрес; номер TCP- или UDP-порта отправителя} ставится в соответствие пара {глобальный IP-адрес внешнего интерфейса; назначенный номер TCP- или UDP-порта}. Назначенный номер порта выбирается произвольно, однако должно быть выполнено условие его уникальности в пределах всех узлов, получающих выход во внешнюю сеть. Соответствие фиксируется в таблице.

Эта модель при наличии единственного зарегистрированного IP-адреса, полученного от поставщика услуг, удовлетворяет требованиям по доступу к внешним сетям большинства сетей средних размеров.

На рис. 18.9 приведен пример, когда в тупиковой сети А используются внутренние адреса из блока 10.0.0.0. Внешнему интерфейсу маршрутизатора этой сети поставщиком услуг назначен адрес 181.230.25.1.

ЧастныйадресПортГлобальныйадресНазначенныйпорт 10.0.1.41245181.230.25.13451 10.0.2.151245181.230.25.13452 10.0.2.31045181.230.25.13455 Внутренняя сеть Серверtelnet136.56.28.8

Рис. 18.9. Трансляция сетевых адресов и портов для исходящих TCP- и UDP-сеансов

Когда хост 10.0.1.4 внутренней сети посылает во внешнюю сеть пакет серверу telnet, то он в качестве адреса назначения использует его глобальный адрес 136.56.28.8. Пакет поступает маршрутизатору R1, который знает, что путь к сети 136.56.0.0/16 идет через пограничный маршрутизатор R2. Модуль NAPT маршрутизатора R2 транслирует адрес 10.0.1.4 и порт TCP 1245 источника в глобально уникальный адрес 181.230.25.1 и уникально назначенный TCP-порт, в приведенном примере — 3451. В таком виде пакет отправляется во внешнюю сеть и достигает сервера telnet. Когда получатель генерирует ответное сообщение, то он в качестве адреса назначения указывает единственный зарегистрированный глобальный адрес внутренней сети, являющийся адресом внешнего интерфейса NAPT-устройства. В поле номера порта получателя сервер помещает назначенный номер TCP-порта, взятый из поля порта отправителя пришедшего пакета. При поступлении ответного пакета на

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

ВНИМАНИЕ-

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

В технологии NAPT разрешаются только исходящие из частной сети TCP- и UDP-сеансы. Однако возникают ситуации, когда нужно обеспечить доступ к некоторому узлу внутренней сети извне. В простейшем случае, когда служба зарегистрирована, то есть ей присвоен хорошо известный номер порта (например, WWW или DNS), и, кроме того, эта служба представлена во внутренней сети в единственном экземпляре, задача решается достаточно просто. Служба и узел, на котором она работает, однозначно определяются хорошо известным зарегистрированным номером порта службы.

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

Групповое вещание

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

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

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

Концепция группового вещания (multicast) нашла свое воплощение в ряде спецификаций протоколов группового взаимодействия в Интернете. В 1992 году появилась экспериментальная магистраль МВопе, которая объединила 20 сетей через Интернет. С помощью этой магистрали была проведена первая аудиоконференция, которая позволила группе, образованной из членов IETF по всему миру, слышать то, что говорилось на собрании IETF в Сан-Диего.

Стандартная модель группового вещания IP

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

Источник S Узел, желающий получить пакет Узел, желающий получить пакетУзел, желающий Узел, не желающийполучить пакет получить пакетРис. 18.10. Групповая доставка на основе индивидуальных адресов

При индивидуальной рассылке (unicast) на основе уникальных адресов источник данных, которые надо доставить некоторой группе узлов, генерирует их в количестве экземпляров, равном количеству узлов-получателей, состоящих в данной группе (рис. 18.10). То есть передача по принципу «один ко многим» сводится к нескольким передачам «один к одному». Очевидно, что передача нескольких идентичных копий на участках, где маршруты к разным членам группы перекрываются (это особенно характерно для начальных участков), приводит к избыточному трафику.

При широковещательной рассылке (broadcast) станция направляет пакеты, используя широковещательные адреса (рис. 18.11). В этой схеме, для того чтобы доставить данные группе узлов-получателей, источник генерирует один экземпляр данных, но снабжает этот экземпляр широковещательным адресом, который диктует маршрутизаторам сети копировать эти данные и рассылать их всем конечным узлам независимо от того, «заинтересованы» узлы в получении этих данных или нет. В этом случае, как и в предыдущем, существенная доля трафика является избыточной.

Узел, желающий Узел, не желающийполучить пакет получить пакетРис. 18.11. Групповая доставка на основе широковещательного адреса

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

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

Рис. 18.12. Групповая доставка на основе сервисов прикладного уровня

Главная идея группового вещания состоит в следующем: источник генерирует только один экземпляр сообщения с групповым адресом, которое затем, по мере перемещения по сети, копируется на каждой из «развилок», ведущих к тому или иному члену группы, указанной в адресе данного сообщения (рис. 18.13). В конце концов, пакет с групповым адресом достигает маршрутизатора, к которому непосредственно подключена сеть с хостами-членами данной группы. Напомним, что у хостов, относящихся к той или иной группе, интерфейс наряду с индивидуальным адресом имеет еще и групповой адрес — адрес класса D, называемый также адресом группового вещания. Интерфейс может иметь даже несколько групповых адресов — по числу групп, в которых состоит данный хост.

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

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

Рис. 18.13. Схема группового вещания

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

? Дейтаграммный подход. Источник может посылать пакеты UDP/IP в любое время без необходимости регистрировать или планировать передачи, реализуя сервис «по возможности».

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

? Динамические группы. Хосты могут присоединяться к группам или покидать группы без необходимости регистрации, синхронизации или переговоров с каким-либо централизованным элементом группового управления. Членство в группе является динамическим, поскольку хосты могут присоединиться к группе или выйти из группы в любой момент времени, к тому же они могут быть членами нескольких групп.

Из концепции открытых групп следует, что групповое вещание может быть организовано как по схеме «один ко многим», так и по схеме «многие ко многим».

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

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

В соответствии с традиционной моделью группового вещания узлы могут делать заявки на трафик, направляемый той или иной конкретной группе (по тому или иному групповому адресу), при этом не имеет значения, каким источником генерируется этот трафик. Для описания такой модели часто используют термин групповое вещание из любого источника (Any Source Multicast, ASM). Модель ASM включает обе схемы: и «один ко многим», и «многие ко многим».

В более поздней модели, называемой групповым вещанием из конкретного источника

(Source Specific Multicast, SSM), хосты могут регистрировать свою заинтересованность не только относительно определенной группы, указывая соответствующий групповой адрес, но и в отношении совершенно определенных источников группового трафика, указывая соответствующие индивидуальные адреса. Возможность запроса конкретных источников является ключевой в модели SSM. Модель сервиса группового вещания SSM строится по схеме «один ко многим» и предусматривает возможность работы хостов в двух дополнительных режимах:

? в режиме исключения хост может требовать, чтобы ему направлялись пакеты для его группы, но только те, которые поступают от источников, не входящий в его список исключенных источников;

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

Адреса группового вещания

Ранее в главе 15, изучая типы IP-адресов, мы отмечали, что адреса IPv4 из диапазона

224.0.0.0-239.255.255.255 относятся к классу D и они зарезервированы для группового вещания.

Адреса из этого диапазона используются:

? для идентификации групп;

? для идентификации адресов источников группового вещания (в рамках модели SSM);

? для административных нужд при реализации группового вещания.

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

Информацию о том, какие адреса уже закреплены для выполнения некоторой постоянной роли, а также о том, как использовать адресное пространство адресов класса D, дает документ RFC 3171 полномочной организации по цифровым адресам Интернета (Internet Assigned Numbers Authority, IANA).

Некоторые сведения из этого документа можно найти на сайте www.olifer.co.uk в разделе «Структурирование адресного пространства группового вещания».

Основные типы протоколов группового вещания

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

? В первую входит один протокол — протокол IGMP, с помощью которого, во-первых, хосты сообщают о своем «желании»65 присоединиться к некоторой группе, во-вторых, маршрутизатор узнает о принадлежности хостов в непосредственно подключенных к нему подсетях к той или иной группе. Протокол IGMP работает в тесном взаимодействии с протоколами второй категории — протоколами маршрутизации группового вещания.

? Протоколы маршрутизации группового вещания необходимы для продвижения пакетов, несущих в себе информацию для групповых получателей, через сеть произвольной конфигурации. Эти протоколы — DVMRP, MOSPF, PIM — опираются на разные подходы, но в конечном итоге все они сводятся к построению графа, связывающего все хосты в определенной группе, причем между двумя хостами существует только один путь. Такой граф называют покрывающим деревом. Протоколы маршрутизации осуществляют постоянный мониторинг покрывающего дерева и время от времени отсекают те ветви дерева, которые из-за изменения состояния сети уже не ведут к членам той или иной группы.

Протокол IGMP

Протокол группового управления в Интернете (Internet Group Management Protocol, IGMP) был разработан в 1989 году для обеспечения более эффективной рассылки информации по IP-адресам, чем традиционные методы одноадресной и широковещательной передачи. Существует три версии IGMP: IGMPvl (RFC 1112), IGMPv2 (RFC 2236) и IGMPv3 (RFC 3376).

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

ПРИМЕЧАНИЕ-

Источник не нуждается в протоколе IGMP. Любой компьютер, подключенный к Интернету, может стать источником группового вещания, при этом ему не требуется никакого дополнительного программного обеспечения, кроме того, которое включено в состав обычной реализации стека TCP/IP.

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

Оповещение маршрутизатора о желании хоста быть включенным в группу. Чтобы стать получателем групповых данных, узел должен «выразить» свою заинтересованность маршрутизатору, к которому непосредственно подсоединена его сеть. Для этого хост должен установить взаимодействие с маршрутизатором по протоколу IGMP. Версия IGMP для хоста прямо зависит от типа операционной системы, установленной на хосте. Так, ранние версии Windows (Windows 95) поддерживали только версию IGMPvl, более поздние (Windows 2000) — версию IGMPv2, а начиная с Windows ХР, поддерживается версия IGMPv3. Протоколы IGMPv2 и IGMPv3 поддерживаются во многих версиях Mac OS, Linux, Unix-подобных операционных системах.

Опрос членов группы. Для выполнения этой функции один из маршрутизаторов локальной сети выбирается доминирующим. Доминирующий маршрутизатор средствами протокола IGMP периодически опрашивает все системы (групповой адрес 224.0.0.1) в непосредственно присоединенных к нему подсетях, проверяя, активны ли члены всех известных ему групп. Остальные (не выбранные) маршрутизаторы прослушивают сеть, и если обнаруживают отсутствие сообщений-запросов в течение некоторого периода (обычно 250 секунд), то повторяют процедуру выбора нового доминирующего маршрутизатора.

В IGMPv2 определено три типа сообщений:

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

? Отчет о членстве (membership report). Этим сообщением хосты отвечают маршрутизатору, который послал в сеть запрос о членстве. В сообщении содержится информация об адресе группы, в которой они состоят. Маршрутизатор, являясь членом всех групп, получает сообщения, направленные на любой групповой адрес. Для маршрутизатора, получающего ответные сообщения, важен только факт наличия членов той или иной группы (групп), а не принадлежность конкретных хостов конкретным группам. Этот факт будет использован другими маршрутизаторами сети для продвижения пакетов группового вещания в ту часть сети, за которую «отвечает» данный маршрутизатор. Отчет о членстве хост может послать не только в ответ на запрос маршрутизатора, но и по собственной инициативе, когда он пытается присоединиться к определенной группе. После такого сообщения хост может рассчитывать на то, что трафик для этой группы действительно будет доставляться в сеть, к которой этот хост принадлежит.

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

Сообщения с запросами о членстве посылаются маршрутизатором регулярно с некоторой частотой. На каждом из интерфейсов с установленными средствами IGMP маршрутизаторами поддерживаются кэш-таблицы групп. Кэш-таблица содержит список всех групп, в составе которых есть хотя бы один член. Для каждой строки таблицы установлен таймаут. Маршрутизатор регулярно посылает запросы (по умолчанию — каждые 125 секунд), чтобы проверить, что в каждой группе еще имеются члены. Если для некоторой группы ответ не поступает в течение установленного для нее тайм-аута, то соответствующая строка удаляется из кэш-таблицы, и маршрутизатор считает, что членов этой группы в сети больше нет.

Локальная сеть может иметь несколько хостов, заинтересованных в получении трафика одной и той же группы, но маршрутизатору достаточно подтверждения только от одного хоста для того, чтобы продолжить передавать трафик в сеть для этой группы. При использовании протокола IGMPvl или IGMPv2 для ограничения числа ответов хостов на запрос маршрутизатора любой хост, состоящий в группе, вместо того чтобы немедленно ответить на запрос, сначала ждет в течение некоторого интервала времени, не появится ли в сети ответ какого-нибудь другого хоста. Если по истечении этого времени он так и не смог дождаться появления в сети ответа другого хоста, то он посылает маршрутизатору собственный отчет о членстве. (Если же используется протокол IGMPv3, то никаких пауз не устанавливается, и хосты сразу генерируют сообщения о членстве.)

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

Все типы IGMP-сообщений имеют длину 8 байт и состоят из четырех полей. В зависимости от версии протокола IGMP назначение полей может несколько меняться. На рис. 18.14 показана структура сообщения для версии IGMPv2.

1-4 байтыТипМаксимальноеКонтрольная сообщениявремя ответасумма Адрес группового 5-8 байтывещания (Multicast group address) Рис. 18.14. Структура IGMP-сообщения

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

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

ПРИМЕЧАНИЕ-

Чтобы хост смог получать трафик группового вещания, недостаточно установить на нем протокол IGMP, с помощью которого хост может отправить сообщение своему маршрутизатору о желании присоединиться к группе. Помимо этого, надо сконфигурировать сетевой интерфейс хоста так, чтобы он стал захватывать из локальной сети кадры, несущие в себе пакеты группового вещания для той группы, к которой присоединился хост. Для этого необходимо настроить интерфейс на прослушивание определенного группового адреса канального уровня, соответствующего групповому IP-адресу. К сожалению, адресное пространство групповых IP-адресов в 32 раза объемнее пространства групповых М AC-адресов. То есть отображение этих двух адресных пространств оказывается далеко неоднозначным — на один и тот же групповой МАС-адрес отображается целый блок из 32 различных групповых IP-адресов. Следовательно, когда сетевой адаптер захватывает кадр, содержащий пакет группового вещания, существует значительная вероятность того, что этот пакет был направлен совсем другой группе. Однако эта ошибка скоро обнаруживается. Когда кадр передается вверх по стеку, протокол IP проверяет, совпадает ли групповой IP-адрес в поле адреса назначения инкапсулированного пакета с групповым IP-адресом данного интерфейса. (Отметим, что ни групповые IP-адреса, ни групповые МАС-адреса никогда не используются в качестве адресов отправителя.)

Принципы маршрутизации трафика группового вещания

Среди принципов маршрутизации трафика группового вещания можно отметить:

? маршрутизацию на основе доменов;

? учет плотности получателей группового трафика;

? два подхода к построению маршрутного дерева;

? концепцию продвижения по реверсивному пути.

Маршрутизация на основе доменов. Значительный объем хранимой и передаваемой по сети служебной информации, используемой для поддержания группового вещания, стал фактором, ограничивающим масштабируемость данной технологии. Для улучшения масштабируемости разработчики технологии группового вещания предложили традиционный для Интернета иерархический подход, основанный на доменах. Подобно автономным системам (доменам маршрутизации) и DNS-доменам, вводятся домены группового вещания. Для доставки информации в пределах домена предлагаются одни методы и протоколы маршрутизации группового вещания, называемые внутридоменными, а в пределах многодоменной структуры — другие, называемые междоменными. Мы ограничимся в этом учебнике описанием средств продвижения пакетов группового вещания в пределах отдельного домена.

Учет плотности получателей группового трафика. Внутридоменные протоколы маршрутизации разделяются на два принципиально отличных класса:

? Протоколы плотного режима (Dense Mode, DM) разработаны в предположении, что в сетевом домене существует большое число принимающих узлов. Отсюда следует главная идея этих протоколов: сначала «затопить» сеть пакетами группового вещания по всем направлениям, останавливая продвижение пакетов, лишь когда находящийся на пути распространения трафика маршрутизатор явно сообщит, что далее ниже по потоку членов данной группы нет.

? Протоколы разряженного режима (Sparse Mode, SM) рассчитаны на работу в сети, в которой количество маршрутизаторов с подключенными к ним членами групп невелико по сравнению с общим числом маршрутизаторов. В такой ситуации выгоднее не усекать некоторые пути распространения широковещательной рассылки, а использовать явные сообщения о необходимости присоединения подсетей к дереву рассылки.

В сети, использующей протокол класса SM, необходимо существование центрального элемента, обычно называемого точкой рандеву, или встречи (Rendezvous Point, RP). Точка встречи должна существовать для каждой имеющейся в сети группы и быть единственной для группы. Все узлы, заинтересованные в получении информации, предназначенной той или иной группе, должны регистрироваться в соответствующей точке встречи. Функции точки (или нескольких точек) встречи выполняет специально назначенный для этого маршрутизатор. В сети может быть несколько маршрутизаторов, играющих роли точек встречи.

ПРИМЕЧАНИЕ-

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

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

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

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

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

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

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

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

Проверка факта выполнения данного условия называется продвижением по реверсивному пути (Reverse Path Forwarding, RPF). Такое название объясняется тем, что эта процедура связана не столько с путями, ведущими вперед от текущего места нахождения пакета к пункту назначения, сколько с обратным (реверсивным) путем, который уже пройден пакетом от того места, где он находится сейчас, до источника. Только пакеты, которые прошли RPF-проверку, являются кандидатами для дальнейшего продвижения вдоль путей, ведущих к потенциальным получателям трафика группового вещания.

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

На этом этапе мы йе предъявляли специфических требований к таблицам маршрутизации, на основании которых выполняется RPF-проверка. Некоторые протоколы, такие как DVMRP, строят собственную таблицу маршрутизации, в то время как, например, протокол PIM работает с таблицами маршрутизации, построенными другими протоколами.

Протокол DVMRP

Дистанционно-векторный протокол маршрутизации группового вещания (Distance Vector Multicast Routing Protocol, DVMRP), описанный в спецификации RFC 1075, может быть характеризован с самых общих позиций следующим образом:

? как следует из его названия, он основан на дистанционно-векторном алгоритме и, следовательно, обладает всеми особенностями, свойственными данному алгоритму;

? относится к классу протоколов плотного режима, использующих проверку продвижения по реверсивному пути;

? продвигает пакеты на основе деревьев с вершинами в источниках;

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

Протокол DVMRT был одним из первых протоколов продвижения группового трафика в исследовательской сети МВопе. Групповая маршрутизация в ранней версии МВопе была, в сущности, управляемой формой широковещания, когда пришедший пакет с групповым адресом передавался через все интерфейсы, кроме входного. Для борьбы с зацикливанием пакетов с групповыми адресами маршрутизаторы запоминали факт продвижения данного пакета и при его поступлении в следующий раз просто отбрасывали. Для сокращения бесполезного трафика в сети применялся протокол IGMR С помощью этого протокола маршрутизаторы выясняли, имеются ли в непосредственно подключенных к нему сетях конечные узлы, принадлежащие к определенной группе, или нет. В том случае, когда маршрутизатор определял, что к некоторому интерфейсу подключена сеть, в которой нет членов группы, являющихся получателями группового пакета, он не передавал копию этого пакета чрез данный выходной интерфейс.

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

Рис. 18.15. Управляемое широковещание

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

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

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

ПРИМЕЧАНИЕ-

Для построения деревьев с вершиной в источнике пригодны различные алгоритмы, в частности один из таких алгоритмов, разработанный и стандартизованный IEEE для мостов локальных сетей под названием STA, мы рассмотрели ранее в главе 14.

Дальнейший прогресс в области алгоритмов маршрутизации для группового вещания был связан с разработкой алгоритма плотного режима, получившего название широковещание и усечение (broadcast-and-prune). Этот алгоритм рассчитан на то, что сети плотно «населены» членами различных групп, поэтому ситуация, когда в какой-либо подсети члены группы отсутствуют, считается редкой и отрабатывается особо. В этом «особом» случае маршрутизатор, обнаруживший подсеть, не содержащую членов группы, оповещает об этом другие маршрутизаторы и инициирует процедуру усечения избыточных маршрутов.

Результирующее дерево называется деревом реверсивного кратчайшего пути. Для его

построения необходимо выполнить следующие действия:

1. Источник отправляет пакет по своей локальной сети с групповым адресом. Присоединенный к локальной сети маршрутизатор получает пакеты и отправляет их на все выходные интерфейсы.

2. Каждый маршрутизатор, который получает пакеты, выполняет RPF-проверку. Маршрутизатор принимает пакеты по некоторому интерфейсу только в том случае, если считает, что через него проходит самый эффективный обратный путь к источнику. Все пакеты, принимаемые с «правильного» интерфейса, продвигаются на все выходные интерфейсы. Все остальные просто отбрасываются.

3. В конце концов пакет достигает тупикового маршрутизатора (лист на графе маршрутизаторов) с некоторым количеством присоединенных хостов. Такой маршрутизатор должен проверить, имеются ли в какой-либо из присоединенных к нему сетей члены группы, адрес которой указан в данном пакете. Для этого маршрутизатор периодически рассылает IGMP-запросы. Если члены группы присутствуют, то маршрутизатор распространяет пакет по локальной сети, а сообщение об усечении (prune) не посылает. Если же у маршрутизатора-листа нет получателей для группы, то он посылает сообщение об усечении по направлению к источнику через интерфейс RPF, то есть через интерфейс, который маршрутизатор-лист должен использовать для продвижения пакетов к данному источнику.

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

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

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

Этот недостаток и стал толчком к разработке нового класса протоколов, названных протоколами разряженного режима. Вместо ориентации на существование большого количества членов группы, протоколы разряженного режима подразумевают наличие их в небольшом количестве, причем рассеянном по сети, как это часто и бывает в действительности. Мы рассмотрим два протокола «разряженного» режима — MOSPF и PIM-SM.

Протокол MOSPF

Протокол MOSPF (Multicast extensions to OSPF — расширения протокола OSPF для группового вещания), описанный в спецификации RFC 1584, опирается на обычные механизмы OSPF для поддержки группового вещания. MOSPF-маршрутизаторы добавляют к информации о состоянии связей, распространяемой по протоколу OSPF, данные о членстве в группах узлов в непосредственно присоединенных сетях. Эти данные рассылаются по сети в дополнительном сообщении о членстве в группе (group membership). В результате помимо топологии связей, MOSPF-маршрутизаторам становится известно о наличии членов каждой из групп в каждой подсети области. На основании этой информации маршрутизатор находит дерево кратчайших путей для каждой группы. Это позволяет распространять групповые пакеты не широковещательно, а по кратчайшим путям от источника до подсетей, в которых есть активные члены группы.

Для получения данных о том, в какие группы входят конечные узлы в связанных с ним подсетях, MOSPF-маршрутизатор использует запросы и ответы протокола IGMP. При каждом подключении узла к группе или исключении узла из группы маршрутизатор рассылает по сети новое сообщение о членстве в группе, так что можно считать, что протокол MOSPF задействует механизм явных уведомлений Ьб изменении состава групп и поэтому относится к группе протоколов разряженного режима. Кроме того, известные положительные свойства протокола OSPF — устойчивое поведение при изменениях топологии сети, меньшие объемы служебного трафика по сравнению с протоколом RIP, а также возможность деления сети на области — полностью наследуются протоколом MOSPF, что делает его весьма привлекательным для применения в больших сетях.

Протокол PIM-SM

Протокол PIM-SM является одной из двух версий протокола PIM (Protocol Independent Multicast — независимое от протокола групповое вещание), описываемого в спецификации RFC 2362:

? версии плотного режима PIM-DM (Protocol Independent Multicast — Dense Mode);

? версии разряженного режима PIM-SM (Protocol Independent Multicast — Sparse Mode).

Эти версии существенно отличаются друг от друга способом построения и использования покрывающего дерева, но у них есть и одно общее свойство. Оно вынесено в название каждого из этих протоколов и означает независимость данного протокола от конкретных протоколов маршрутизации. Если DVMPR использует в своей работе механизмы RIP, а протокол MOSPF является расширением протокола OSPF, то протокол PIM может работать совместно с любым протоколом маршрутизации. Протокол PIM задействует готовые таблицы маршрутизации для продвижения групповых пакетов и служебных сообщений и для него не имеет значения, с помощью какого протокола маршрутизаторы строят эти таблицы.

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

Главной особенностью протокола PIM-SM является то, что он рассчитан на работу в разряженном режиме, то есть он посылает групповые пакеты только по явному запросу получателя. Для доставки данных каждой конкретной группе получателей протокол PIM-SM строит одно разделяемое дерево, общее для всех источников этой группы (рис. 18.16).

Рис. 18.16. Разделяемое дерево протокола PIM-SM

h у h Ид

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

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

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

Процесс доставки протоколом PIM-SM группового трафика от источника к получателям, принадлежащим некоторой группе, может быть представлен трехэтапным:

1. Построение разделяемого дерева с вершиной в точке встречи, которое описывает пути доставки групповых пакетов между точкой встречи и членами данной группы. Это дерево называют также деревом точки встречи (Rendezvous Point Tree, RPT).

2. Построение дерева кратчайшего пути (Shortest Path Tree, SPT), которое будет доставлять пакеты между источником данной группы и точкой встречи.

3. Построение набора SPT-деревьев, которые ради повышения эффективности будут использованы для доставки пакетов непосредственно между источником и каждым из получателей группы.

ПРИМЕЧАНИЕ-

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

Рассмотрим работу протокола PIM-SM на простом примере. На рис. 18.17 показана однодоменная сеть, в которой прртокол PIM-SM устанавливает связь между одним получателем Л и одним источником 5. Будем считать, что работа сети соответствует модели ASM (групповое вещание из любого источника), на всех узлах сети развернут протокол IGMP и все маршрутизаторы поддерживают протокол PIM-SM. Будем считать также, что точка встречи сконфигурирована статически: и источники, и получатели знают индивидуальный адрес точки встречи, роль которой в этой сети играет маршрутизатор D. Для оповещения узлов сети об адресе точке встречи имеется стандартный протокол автоматического оповещения, называемый протоколом загрузки.

В

Этап 1 — построение разделяемого RPT-дерева от получателя к точке встречи. Когда разделяемое дерево уже построено, трафик группового вещания передается от точки встречи в направлении заинтересованных получателей. Однако процесс построения разделяемого дерева движется в обратном направлении — от получателей к точке встречи на основе пошагового (hop-by-hop) подхода.

Итак, пусть хост Л решает присоединиться к группе G, по этой причине он посылает IGMP-сообщениё отчета о членстве, содержащее адрес группы G, в локальную сеть, к которой он подключен. Это сообщение будет получено маршрутизатором С, через который данная локальная сеть подключена к другим сетям.

Маршрутизатор С, получив от хоста А это IGMP-сообщение, посылает сообщение протокола PIM-SM о присоединении (join) на индивидуальный адрес маршрутизатора Д выполняющего функции точки встречи. Это сообщение продвигается обычным образом на основе таблиц маршрутизации, построенных любыми протоколами маршрутизации. На всех промежуточных маршрутизаторах, расположенных вдоль пути от хоста-получателя к точке встречи, фиксируется состояние продвижения для данной группы. Каждый маршрутизатор добавляет интерфейс, принявший сообщение протокола PIM-SM о присоединении, к своему списку интерфейсов, через которые заинтересованным получателям может быть доставлен трафик группы, упомянутой в сообщении. В результате для данной группы формируется разделяемое дерево, и его корнем является точка встречи.

В нашем примере на данном этапе нет активных источников, поэтому данные группового вещания еще не поступают к точке встречи (см. рис 18.17).

Этап 2 — построение SPT-дерева от источника к точке встречи. Когда источник S становится активным и начинает посылать пакеты с групповым адресом в свою локальную сеть, маршрутизатор F, к которому эта сеть непосредственно подключена, замечает, что источник 5 стал источником группового вещания. Маршрутизатор F посылает РШ-сообщение о регистрации (register) на индивидуальный адрес точки встречи (маршрутизатора D). При этом сообщение о регистрации инкапсулируется в пакет группового вещания от источника S (рис. 18.18).

Когда маршрутизатор D (точка встречи) получает сообщение о регистрации, он реагирует на это двумя действиями. Во-первых, он продвигает инкапсулированные данные группового вещания по разделяемому дереву (RPT) от точки встречи до получателя, во-вторых, посылает РШ-сообщение о присоединении назад по направлению к источнику с тем, чтобы создать дерево кратчайшего пути (SPT). Это сообщение передается от одного маршрутизатора к другому, при этом информация о присоединении к группе фиксируется на соответствующих интерфейсах.

Как только дерево кратчайшего пути от источника к точке встречи построено, маршрутизатор D начинает получать по две копии каждого пакета группового вещания. Одна копия приходит от источника 5 по вновь созданному кратчайшему пути, другая — от маршрутизатора F, который, продолжая реагировать на выявленную активность источника 5, снова посылает сообщение о регистрации, в котором в инкапсулированном виде содержится вторая копия группового пакета. Когда маршрутизатор точки встречи распознает эту ситуацию, он посылает маршрутизатору F сообщение с требованием прекратить регистрацию (register stop). Получив это сообщение для данной пары источник-группа, маршрутизатор F прекращает генерировать сообщения о регистрации и инкапсулировать в них групповые пакеты источника66. Вместо этого он начинает посылать их в исходном виде с групповым

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

В ХостА, желающий войти в группу G Рис. 18.18. Этап 2 — регистрация источника с построением дерева кратчайшего пути

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

Этап 3 — построение дерева кратчайшего пути от источника к получателю. Когда маршрутизатор С получает первый групповой пакет, он узнает из его заголовка IP-адрес отправителя, каковым в данном случае является источник S. На основании этого адреса маршрутизатор С пытается построить дерево кратчайшего пути непосредственно от источника до самого себя. В нашем примере кратчайший путь — это путь через маршрутизатор В. Маршрутизатор С посылает сообщение о присоединении маршрутизатору В, который затем, в свою очередь, посылает сообщение о присоединении маршрутизатору F. При этом каждый из них фиксирует интерфейс, на который он будет направлять пакеты да данной группы.

Теперь, когда дерево кратчайшего пути для пары (источник 5, получатель Л) построено, маршрутизаторы F, В и С начинают продвигать пакеты группового вещания вдоль него. Когда пакеты начинают прибывать на маршрутизатор С, он обнаруживает по две копии каждого пакета — одна приходит по новому кратчайшему пути через маршрутизатор В, другая по разделяемому дереву от маршрутизатора D. Чтобы прекратить дублирование, маршрутизатор С посылает PIM-сообщение об отсечении точки встречи (маршрутизатору D), который отсекает источник от разделяемого RPT-дерева (рис. 18.19).

ВИсточник S Хост А, желающий войти в группу G Рис. 18.19. Этап 3 — построение дерева кратчайшего пути от источника к получателю

С этого момента маршрутизатор С получает только по одной копии каждого пакета от и точника 5 через свое отдельное дерево кратчайшего пути и передает его в локальную сет в которой находится получатель.

Для упрощения мы описали случай, когда в сети имеется только одна точка встречи и с здается только одно разделяемое дерево. Однако технология допускает наличие в сет нескольких точек встречи. Решение о том, сколько в сети должно быть точек встречи и к; их расположить, составляет предмет планирования сети и протоколом PIM не опред ляется.

Информацию об иерархическом подходе к организации группового вещания вы можете найти на сайте www.olifer.co.uk в разделе «Междоменное групповое вещание».

IPv6 как развитие стека TCP/IP

В начале 90-х годов стек протоколов TCP/IP столкнулся с серьезными проблемами. Име] но в это время началось активное промышленное использование Интернета: переход к п строению сетей предприятий на основе транспорта Интернета, применение веб-технолог* для доступа к корпоративной информации, ведение электронной коммерции через И] тернет, внедрение Интернета в индустрию развлечений (распространение видеофильмо звукозаписей, интерактивные игры).

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

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

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

Наряду с добавлением новых функций непосредственно в протокол IP, необходимо было обеспечить его тесное взаимодействие с новыми протоколами — членами стека TCP/IP, что также требовало добавления в заголовок IP новых полей, обработку которых осуществляли бы эти протоколы. Например, для работы RSVP было желательно введение в заголовок IP-поля метки потока, а для протокола IPSec — специальных полей для передачи данных, поддерживающих его функции обеспечения безопасности.

В результате сообщество Интернета после достаточно долгого обсуждения решило подвергнуть протокол IP серьезной переработке1, выбрав в качестве основных целей модернизации:

? создание масштабируемой схемы адресации;

? сокращение объема работы, выполняемой маршрутизаторами;

? предоставление гарантий качества транспортных услуг;

? обеспечение защиты данных, передаваемых по сети.

Система адресации протокола IPv6

Новая (шестая) версия протокола IP (IPv6) внесла существенные изменения в систему адресации. Прежде всего, это коснулось увеличения разрядности адреса: вместо 4 байт IP-адреса в версии IPv4 в новой версии под адрес отведено 16 байт. Это дает возможность пронумеровать огромное количество узлов:

340 282 366 920 938 463 463 374 607 431 762 211 456.

^августе 1998 года были приняты пересмотренные версии группы стандартов, определяющих как общую архитектуру протокола IPv6 (RFC 2460), так и его отдельные аспекты, например, систему адресации (RFC 4291).

Масштаб этого числа иллюстрирует, например, такой факт: если разделить это теоретически возможное количество IP-адресов между всеми жителями Земли (а их сегодня примерно 6 миллиардов), то на каждого из них придется невообразимо, если не сказать бессмысленно большое количество IP-адресов — 5,7 х 1028! Очевидно, что такое значительное увеличение длины адреса было сделано не только и даже не столько для снятия проблемы дефицита адресов.

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

Вместо прежних двух уровней иерархии адреса (номер сети и номер узла) в IPv6 имеется 4 уровня, из которых три уровня используются для идентификации сетей, а один — для идентификации узлов сети. В новой версии не поддерживаются классы адресов (А, В, С, D, Е), но широко используется технология CIDR. Благодаря этому, а также усовершенствованной системе групповой адресации и введению адресов нового типа IPv6 позволяет снизишь затраты на маршрутизацию.

Произошли и чисто внешние изменения — разработчики стандарта предложили использовать вместо десятичной шестнадцатеричную форму записи IP-адреса. Каждые четыре шестнадцатеричные цифры отделяются друг от друга двоеточием. Вот как, например, может выглядеть адрес IPv6: FEDC:0A98:0:0:0:0:7654:3210. Для сетей, поддерживающих обе версии протокола (IPv4 и IPv6), разрешается задействовать для младших 4 байтов традиционную для IPv4 десятичную запись: 0:0:0:0:0:FFFF:129.144.52.38.

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

Основным подтипом индивидуального адреса является глобальный агрегируемый уникальный адрес. Такие адреса могут агрегироваться для упрощения маршрутизации. В отличие от уникальных адресов узлов версии IPv4, которые состоят из двух полей — номера сети и номера узла, — глобальные агрегируемые уникальные адреса IPv6 имеют более сложную структуру, включающую шесть полей (рис. 18.20).

3138241664 FPTLANLASLAИдентификаторинтерфейса Рис. 18.20. Структура глобального агрегируемого уникального адреса в пакете IPv6

? Префикс формата (Format Prefix, FP) для этого типа адресов имеет размер 3 бита и значение 001.

? Поле TLA (Top-Level Aggregation, TLA) предназначено для идентификации сетей самых крупных поставщиков услуг. Конкретное значение этого поля представляет собой общую часть адресов, которыми располагает данный поставщик услуг. Сравнительно небольшое количество разрядов, отведенных под это поле (13), выбрано специально для ограничения размера таблиц маршрутизации в магистральных маршрутизаторах самого верхнего уровня Интернета. Это поле позволяет перенумеровать 8196 сетей поставщиков услуг верхнего уровня, а значит, число записей, описывающих маршруты между этими сетями, также будет ограничено значением 8196, что ускорит работу магистральных маршрутизаторов. Следующие 8 разрядов зарезервированы на будущее для расширения при необходимости поля TLA.

? Поле NLA (Next-Level Aggregation, NLA) предназначено для нумерации сетей средних и мелких поставщиков услуг. Значительный размер поля NLA позволяет путем агрегирования адресов отразить многоуровневую иерархию поставщиков услуг.

? Поле SLA (Site-Level Aggregation, SLA) предназначено для адресации подсетей отдельного абонента, например подсетей одной корпоративной сети.

? Идентификатор интерфейса является аналогом номера узла в IPv4. Отличием версии IPv6 является то, что в общем случае идентификатор интерфейса просто совпадает с его локальным (iаппаратным) адресом, а не представляет собой произвольно назначенный администратором номер узла. Идентификатор интерфейса имеет длину 64 бита, что позволяет поместить туда МАС-адрес (48 бит), адрес конечного узла АТМ (48 бит) или номер виртуального соединения АТМ (до 28 бит), а также, вероятно, даст возможность использовать локальные адреса технологий, которые могут появиться в будущем. Такой подход делает ненужным протокол ARP, поскольку процедура отображения IP-адреса на локальный адрес становится тривиальной — она сводится к простому отбрасыванию старшей части адреса. Кроме того, в большинстве случаев отпадает необходимость ручного конфигурирования конечных узлов, так как младшую часть адреса — идентификатор интерфейса — узел узнает от аппаратуры (сетевого адаптера и т. п.), а старшую — номер подсети — ему сообщает маршрутизатор.

Рассмотрим пример (рис. 18.21). Пусть клиент получил от поставщика услуг пул адресов

IPv6, определяемый префиксом 20:0А:00:С9:74:05/48. Поскольку первые три бита этого

числа равны 001, это — глобальный агрегируемый уникальный адрес.

Префиксы провайдеров 48 бит для конечного абонента 80 бит

3138241664 FPTLAРезервNLASLAИдентификаторинтерфейса 001Wio^tio6cioiei Пользователь 1 может JI организовать I 65 535 сетей |L________I

20:0А:00:С9:74:05/48

_______

МАС-адрес АТМ-адрес Телефонный номер 1Ру4-адрес

Рис. 18.21. Пример глобального агрегируемого адреса

Адрес этот принадлежит поставщику услуг верхнего уровня, у которого все сети имеют префикс 20:0А/16. Он может выделить поставщику услуг второго уровня некоторый диапазон адресов с общим префиксом, образованным его собственным префиксом, а также частью поля NLA. Длина поля NLA, отводимая под префикс, определяется маской, которую поставщик услуг верхнего уровня также должен сообщить своему клиенту — поставщику услуг второго уровня. Пусть в данном примере маска состоит из 32 единиц в старших разрядах, а результирующий префикс поставщика услуг второго уровня имеет вид 20:0А:00:С9/32.

В распоряжении поставщика услуг второго уровня остается 16 разрядов поля NLA для нумерации сетей своих клиентов. В качестве клиентов могут выступать поставщики услуг третьего и более низких уровней, а также конечные абоненты — предприятия и организации. Пусть, например, следующий байт (01110100) в поле NLA поставщик услуг использовал для передачи поставщику услуг более низкого (третьего) уровня, а тот, в свою очередь, использовал последний байт поля NLA для назначения пула адресов клиенту. Таким образом, с участием поставщиков услуг трех уровней был сформирован префикс 20:0А:00:С9:74:05/48, который получил клиент.

Протокол IPv6 оставляет в полном распоряжении клиента 2 байта (поле SLA) для нумерации сетей и 8 байт (поле идентификатора интерфейса) для нумерации узлов. Имея такой огромный диапазон номеров подсетей, администратор получает широкие возможности. Для сравнительно небольшой сети он может выбрать плоскую организацию, назначая каждой имеющейся подсети произвольные неповторяющиеся значения из диапазона в 65 535 адресов, игнорируя оставшиеся. В крупных сетях более эффективным способом (сокращающим размеры таблиц корпоративных маршрутизаторов) может оказаться иерархическая структуризация сети на основе агрегирования адресов. В этом случае используется та же технология CIDR, но уже не поставщиком услуг, а администратором корпоративной сети.

ПРИМЕЧАНИЕ-

Очевидно, что при таком изобилии сетей, которое предоставляется клиенту в IPv6, совершенно теряет смысл операция использования масок для разделения сетей на подсети, в то время как обратная процедура — объединение подсетей — приобретает особое значение. Разработчики стандартов IPv6 считают, что агрегирование адресов является основным способом эффективного расходования адресного пространства в новой версии протокола IP.

Работа по детализации подтипов адресов протокола IPv6 еще далека от завершения. Сегодня определено назначение только 15 % адресного пространства IPv6, а оставшаяся часть адресов еще ждет своей очереди, чтобы найти применение для решения одной из многочисленных проблем Интернета.

Снижение нагрузки на маршрутизаторы

Одной из основных цеЛей изменения формата заголовка протокола IPv6 было снижение накладных расходов, "го есть уменьшение объема служебной информации, передаваемой с каждым пакетом. Для этого в новом протоколе IP были введены понятия основного и дополнительных заголовков. Основной заголовок присутствует всегда, а необязательные дополнительные заголовки могут содержать, например, информацию о фрагментации исходного пакета, полный маршрут следования пакета при маршрутизации от источника, информацию, необходимую для защиты передаваемых данных.

Основной заголовок имеет фиксированную длину в 40 байт, его формат показан на рис. 18.22.

4 байта

Версия

Приоритет

Метка

Л

Длина Сл. заголовок Лимит переходов

Адрес источника

(16 байт)

40 байт

Адрес приемника (16 байт)

J

Рис. 18.22. Формат основного заголовка

Поле следующего заголовка соответствует по назначению полю протокола в версии IPv4 и содержит данные, определяющие тип заголовка, который следует за данным. Каждый следующий дополнительный заголовок также содержит поле следующего заголовка. Если IP-пакет не содержит дополнительных заголовков, то в этом поле будет значение, закрепленное за протоколом TCP, UDP, RIP, OSPF или другим, определенным в стандарте IPv4.

В предложениях по поводу протокола IPv6 фигурируют пока следующие типы дополнительных заголовков:

? заголовок маршрутизации — указание полного маршрута при маршрутизации от источника;

? заголовок фрагментации — информация, относящаяся к фрагментации IP-пакета (поле обрабатывается только в конечных узлах);

? заголовок аутентификации — информация, необходимая для аутентификации конечных узлов и обеспечения целостности содержимого IP-пакетов;

? заголовок системы безопасности — информация, необходимая для обеспечения конфиденциальности передаваемых данных путем шифрования и дешифрирования;

? специальные параметры — параметры необходимые для последовательной обработки пакетов на каждом маршрутизаторе;

? параметры получателя — дополнительная информация для узла назначения.

Таким образом, IP-пакет может иметь, например, формат, показанный на рис. 18.23.

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

Основной заголовок IPv6 Заголовок маршрутизации Заголовок фрагментации Заголовок аутентификации Заголовок системы безопасности

Дополнительные данные для узла назначения

Пакет протокола верхнего уровня

Рис. 18.23. Структура 1Р/6-пакета

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

? Перенесение функций фрагментации с маршрутизаторов на конечные узлы. Конечные узлы в версии IPv6 обязаны найти минимальное значение MTU вдоль всего пути, соединяющего исходный узел с узлом назначения (эта техника под названием Path MTU Discovery уже используется в IPv4). Маршрутизаторы IPv6 не выполняют фрагментацию, а только посылают ICMP-сообщение о слишком длинном пакете конечному узлу, который должен уменьшить размер пакета.

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

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

? Отказ от обработки не обязательных параметров заголовка.

? Использование в качестве номера узла его МАС-адреса избавляет маршрутизаторы от необходимости применять протокол ARP.

Новая версия протокола IP, являющаяся составной частью проекта IPv6, предлагает встроенные средства защиты данных. Размещение средств защиты на сетевом уровне делает их прозрачными для приложений, так как между уровнем IP и приложением всегда будет работать протокол транспортного уровня. Приложения переписывать при этом не придется. Новая версия протокола IP со встроенными средствами обеспечения безопасности называется IPSec (Security Internet Protocol — защищенный протокол IP). Возможности этого протокола подробно рассматриваются в главе 24.

Переход на версию IPv6

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

? Трансляция протоколов. Трансляция протоколов реализуется шлюзами, которые устанавливаются на границах сетей, использующих разные версии протокола IP. Согласование двух версий протокола IP происходит путем преобразования пакетов IPv4 в IPv6, и наоборот. Процесс преобразования включает, в частности, отображение адресов сетей и узлов, различным образом трактуемых в этих протоколах. Для упрощения преобразования адресов между версиями разработчики IPv6 предлагают использовать специальный подтип ПМ)-адреса — 1Ру4-совместимый 1Ру6-адрес, который в младших

4-х байтах переносит ПЧ^-адрес, а в старших 12 байтах содержит нули (рис. 18.24). Это позволяет получать ПЧ4-адрес из ПЧ^б-адреса простым отбрасыванием старших байтов.

1Ру4-адрес (4 байта)

Исходный 1Ру6-адрес (16 байт)(I Ру4-совмести мый 1Ру6-адрес)Рис. 18.24. Преобразование IPv6 в IPv4

Для решения обратной задачи — передачи пакетов IPv4 через части Интернета, работающие по протоколу IPv6, — предназначен 1Ру4-отображенный 1Ру6-адрес. Этот тип адреса также содержит в 4-х младших байтах 1Ру4-адрес, в старших 10-ти байтах — нули, а в 5-м и 6-м байтах 1Ру6-адреса — единицы, которые показывают, что узел поддерживает только версию 4 протокола IP (рис. 18.25).

IPv6 (16 байт)(^4-отображенный IPv6-aflpec) Исходный IPv4-aflpec (4 байта)Рис. 18.25. Преобразование IPv4 в IPv6

? Мультиплексирование стеков протоколов. Мультиплексирование стеков протоколов означает установку на взаимодействующих хостах сети обеих версий протокола IP. Обе версии стека протоколов должны быть развернуты также на разделяющих эти хосты маршрутизаторах. В том случае, когда IPv6-xoct отправляет сообщение 1Ру6-хосту, он использует стек IPv6^a если тот же хост взаимодействует с IPv4-xoctom — стек IPv4. Маршрутизатор с установленными на нем двумя стеками называется маршрутизатором IPv4/IPv6, он способен обрабатывать трафики разных версий независимо друг от друга.

? Инкапсуляция, или туннелирование. Инкапсуляция — это еще один метод решения задачи согласования сетей, использующих разные версии протокола IP. Инкапсуляция может быть применена, когда две сети одной версии протокола, например IPv4, необходимо соединить через транзитную сеть, работающие по другой версии, например IPv6 (рис. 18.26) При этом пакеты IPv4 помещаются в пограничных устройствах (на рисунке роль согласующих устройств исполняют маршрутизаторы) в пакеты IPv6 и переносятся через «туннель», проложенный в IPv6-ceTH. Такой способ имеет недостаток заключающийся в том, что узлы IPv4-ceTeft не имеют возможности взаимодействовав с узлами транзитной IPv6-cera. Аналогичным образом метод туннелирования може^ использоваться для переноса пакетов IPv6 через сеть маршрутизаторов IPv4.

Рис. 18.26. Согласование технологий IPv4 и IPv6 путем туннелирования (инкапсуляции)

Переход от версии IPv4 к версии IPv6 только начинается. Сегодня уже существуют фра менты Интернета, в которых маршрутизаторы поддерживают обе версии протокола. 3i фрагменты объединяются между собой через Интернет, образуя так называемую маг страль бВопе.

Маршрутизаторы

Функции маршрутизаторов

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

(hvHIflIMM МЯПШПЛГГИЯЯТГтЯ МОГУТ быть ПЯябиТЫ НЯ ТПМ ГПУППЫ П РООТИРТРТПИМ Г УПОВНЯ

Порт 1 Порт 2 Порт 3 Порт 4Ethernet Ethernet Token Ring V.35 (X.25, frame relay, ISDN)Рис. 18.27. Функциональная модель маршрутизатора

Уровень интерфейсов

На нижнем уровне маршрутизатор, как и любое устройство, подключенное к сети, обеспечивает физический интерфейс со средой передачи, включая согласование уровней электрических сигналов, линейное и логическое кодирование, оснащение определенным типом разъема. В разных моделях маршрутизаторов часто предусматриваются различные наборы физических интерфейсов, представляющих собой комбинацию портов для подсоединения локальных и глобальных сетей. С каждым интерфейсом для подключения локальной сети неразрывно связан определенный протокол канального уровня, например семейства Ethernet, Token Ring, FDDI. Интерфейсы для присоединения к глобальным сетям чаще всего определяют только некоторый стандарт физического уровня, поверх которого в маршрутизаторе могут работать различные протоколы канального уровня. Например, глобальный порт может поддерживать интерфейс V.35, поверх которого могут работать различные протоколы канального уровня: РРР (передает трафик протокола IP и других сетевых протоколов), LAP-B (используемый в сетях X.25), LAP-F (используемый в сетях Frame Relay), LAP-D (используемый в сетях ISDN), ATM. Разница между интерфейсами локальных и глобальных сетей объясняется тем, что технологии локальных сетей определяют стандарты как физического, так и канального уровней, которые могут применяться только вместе.

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

ПРИМЕЧАНИЕ-

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

Перечень физических интерфейсов, которые поддерживает та или иная модель маршрутизатора, является его важнейшей потребительской характеристикой. Маршрутизатор должен поддерживать все протоколы канального и физического уровней, используемые в каждой из сетей, к которым он будет непосредственно присоединен. На рис. 18.27 показана функциональная модель маршрутизатора с четырьмя портами, реализующими физические интерфейсы 10Base-T и 10Base-2 для двух портов Ethernet, UTP для Token Ring, а также интерфейс V.35, поверх которого может работать протокол LAP-B, LAP-D или LAP-F, обеспечивая подключение к сетям Х.25, ISDN или Frame Relay.

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

Уровень сетевого протокола

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

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

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

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

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

Уровень протокола маршрутизации

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

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

Классификация маршрутизаторов по областям применения

По областям применения маршрутизаторы делятся на несколько классов (рис. 18.28).

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

Для решения этой задачи магистральные маршрутизаторы оснащаются высокоскоростными интерфейсами, такими как АТМ 155/622 Мбит/с, Gigabit Ethernet и 10G Ethernet, а также интерфейсами SONET/SDH со скоростями от 155 Мбит/с до 10 Гбит/с. Для получения отказоустойчивой топологии магистральной сети магистральные маршрутизаторы должны поддерживать несколько таких интерфейсов.

Очевидно, что для того чтобы не создавать «узких мест» в магистральной сети, магистральный маршрутизатор должен обладать очень высокой производительностью. Например, если маршрутизатор оснащен 8 интерфейсами по 10 Гбит/с (Ethernet или SDH), то его общая производительность должна составлять 80 Гбит/с. Для достижения такой производительности магистральные маршрутизаторы обладают распределенной внутренней архитектурой, подобной архитектуре коммутаторов локальных сетей. Каждый порт или группа портов оснащается собственным процессором, который самостоятельно выполняет продвижение IP-пакетов на основании локальной копии таблицы маршрутизации. Для передачи пакетов между портами служит коммутирующий блок на основе разделяемой памяти, общей шины или коммутатора каналов. Общие задачи, включая построение таблицы маршрутизации, хранение конфигурационных параметров, удаленное управление маршрутизатором и т. п., решает центральный блок управления.

Рис. 18.28. Классы маршрутизаторов

Понятно, что функции продвижения IP-пакетов существенно сложнее, чем продвижения кадров Ethernet и других технологий локальных сетей. Поэтому процессоры портов обычно не нагружают дополнительными функциями, такими как фильтрация трафика или трансляция адресов. Даже обеспечение параметров QoS не всегда реализуется таким процессором в полном объеме — обычно дело ограничивается поддержанием очередей, а до профилирования трафика не доходит. Это связано с тем, что магистральный маршрутизатор работает внутри сети и не взаимодействует с внешним миром, а значит, не выполняет пограничные функции, требующие фильтрации и профилирования. Другими словами, основная задача магистрального маршрутизатора — передача пакетов между своими интерфейсами с как можно большей скоростью.

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

доступа, соединяют магисяреяьн^л^ маршрутизаторы образуют особый

слой, приношению к магистрали

сетей» , ' '' '' ..........

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

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

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

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

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

потоков данных, что необходимо для биллинговых схем. Необходимость высокой надежности объясняется значительной стоимостью простоя маршрутизатора при оказании коммерческих услуг. Требования к надежности услуг передачи данных постоянно растут, пользователи Интернета и виртуальных частных сетей хотят, чтобы эти услуги были такими же надежными, как услуги телефонной сети. Поэтому когда мы говорим о том, что готовность некоторых моделей маршрутизаторов достигла рубежа 0,999 и стремится к показателям телефонного оборудования в 0,99999, то в первую очередь это относится к маршрутизаторам операторов связи, как магистральным, так и пограничным. Корпоративные маршрутизаторы предназначены для применения в пределах корпоративной сети, поэтому требования к надежности здесь ниже, а функциональность для работы в Интернете в качестве самостоятельной автономной системы не требуется.

Конечно, характеристики маршрутизаторов операторов связи и корпоративных маршрутизаторов в значительной степени зависят от масштаба и специфики оператора связи или корпорации. Для крупного международного оператора связи сегодня требуются магистральные маршрутизаторы с интерфейсами 10 Гбит/с, которые в недалеком будущем будут заменены маршрутизаторами с портами 100 Гбит/с. Пограничные маршрутизаторы такого оператора также будут относиться к лучшим маршрутизаторам этого класса по производительности, работая с портами доступа со скоростями от 622 Мбит/с до 2,5 Гбит/с.

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

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

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

Если он выполнен на основе шасси, то количество слотов его шасси меньше (4-5). Возможен также конструктив с фиксированным количеством портов. Поддерживаемые интерфейсы локальных и глобальных сетей менее скоростные. Это наиболее обширный класс выпускаемых маршрутизаторов, характеристики которых могут приближаться к характеристикам магистральных маршрутизаторов, а могут и опускаться до характеристик маршрутизаторов удаленных офисов.

Мйршру^^торы удан»нныхофис^б»(Шкя^ вд#Ц^ввн1^

УАа^#й^0грйфИ0$С1 - ЪВЯЗИ.'и

Как правило, интерфейс локальной сети представляет собой Ethernet 100/1000 Мбит/с, а интерфейс глобальной сети — выделенную линию со скоростью 2-100 Мбит/с. Маршрутизатор удаленного офиса может поддерживать работу по коммутируемой телефонной линии в качестве резервной связи для выделенного канала. Существует очень большое количество типов маршрутизаторов удаленных офисов. Это объясняется как массовостью потенциальных потребителей, так и специализацией такого типа устройств, проявляющейся в поддержке какого-либо конкретного типа глобальной связи. Например, существуют маршрутизаторы, работающие только в сетях ISDN, существуют модели только для аналоговых выделенных линий и т. п.

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

Программный маршрутизатор, являясь одной из популярных реализаций такой схемы, пред ставляет собой программный модуль универсальной операционной системы семейства Unix или Windows.

И только появление в глобальных сетях высокоскоростных технологий, таких как ATM, Ethernet, SONET/SDH, DWDM, привело к резкому повышению требований к производительности маршрутизаторов, в результате представители наиболее совершенного класса маршрутизаторов повсеместно перешли на многопроцессорные схемы с коммутирующим блоком, успешно опробованные на коммутаторах локальных сетей.

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

Многие маршрутизаторы этого типа ведут свое происхождение от коммутаторов локальных сетей, что и дало им второе название — коммутаторы 3-го уровня. Коммутаторы 3-го уровня выполняют все функции маршрутизаторов, но, кроме того, могут работать как обычные коммутаторы локальных сетей, то есть коммутаторы 2-го уровня. Режим работы (маршрутизатор или коммутатор) зависит от конфигурационных параметров. Возможен также комбинированный режим работы, когда несколько портов коммутатора 3-го уровня имеют один и тот же IP-адрес сети (рис. 18.29). В этом случае передача пакетов между группой портов, принадлежащих одной сети, выполняется в режиме коммутации на канальном уровне, то есть на основе МАС-адресов. Если же порты принадлежат разным IP-сетям, то тогда коммутатор выполняет маршрутизацию между сетями. Выбор режима передачи пакета определяется конфигурированием IP-адресов портов и, соответственно, компьютеров.

Коммутатор 3-го уровня 194.100.15.5194.100.15.6194.100.15.7194.100.15.8194.100.15.10194.100.15.9 255.255.255.0255.255.255.0255.255.255.0255.255.255.0255.255.255.0255.255.255.0 МАС-Р1МАС-Р2МАС-РЗМАС-Р4МАС-Р5МАС-Р6 Р1Р2РЗР4Р5Р6 EiOl_Г.А__i_i_,i ii i_i_i_

Рис. 18.29. Комбинированный режим работы коммутатора 3-го уровня

ПРИМЕР

Например, если два компьютера (С1 и С2 на рис. 18.29) имеют адреса, принадлежащие одной сети, то при обмене информацией они не будут передавать пакеты маршрутизатору по умолчанию, а задействуют протокол ARP, чтобы узнать МАС-адрес компьютера назначения. Пусть компьютеру С1 требуется передать пакет компьютеру С2. Коммутатор 3-го уровня передает кадр ARP-запроса компьютера С1 с широковещательным МАС-адресом всем портам, принадлежащим одной IP-сети, то есть портам PI, Р2, РЗ и Р4. Компьютер С2 распознает свой IP-адрес (194.100.15.3) в этом запросе и отвечает направленным кадром с МАС-адресом назначения компьютера Cl (МАС1), помещая в ответ собственный МАС-адрес (МАС2). После этого компьютер С1 направляет IP-пакдт компьютеру С2, помещая его в кадр с адресом назначения МАС2. Коммутатор 3-го уровня передает этот кадр с порта Р1 на порт Р2 в соответствии с алгоритмом моста на основе таблицы продвижения 2-го уровня. Аналогичным образом будет работать коммутатор 3-го уровня. В случае когда компьютеры принадлежат разным IP-сетям, поведение компьютера-отправителя диктует коммутатору 3-го уровня способ продвижения пакета. Если, например, компьютер С1 отправляет пакет компьютеру СЗ, находящемуся в другой сети, то он обязан передать пакет маршрутизатору по умолчанию, а не пытаться с помощью ARP узнать МАС-адрес компьютера назначения. Поэтому компьютер С1 делает ARP-запрос о М AC-адресе известного ему маршрутизатора по умолчанию, которым для него является порт Р1 с IP-адресом IP-R1. После получения МАС-адреса порта PI (МАС-Р1) компьютер С1 посылает ему IP-пакет для компьютера СЗ (то есть по IP-адресу назначения 194.100.17.11), оформив его как кадр Ethernet с адресом назначения МАС-Р1. Получив кадр с собственным МАС-адресом, коммутатор 3-го уровня обрабатывает его по схеме маршрутизации, а не коммутации.

Коммутаторы 3-го уровня поддерживают технику VLAN, являясь основным типом устройств для соединения отдельных виртуальных сетей в составную IP-сеть. Обычно каждой виртуальной сети присваивается номер IP-сети, так что передача внутри сетей идет на основе МАС-адресов, а между сетями — на основе IP-адресов. В представленном на рис. 18.29 примере сети порты Р1-Р4 могут принадлежать одной виртуальной сети, а порты Р5, Р6 — другой.

Выводы

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

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

IP-маршрутизаторы уже долгое время поддерживают многие механизмы QoS: приоритетные и взвешенные очереди, профилирование трафика, обратную связь для TCP-трафика. Однако только в середине 90-х годов, когда через Интернет стал передаваться чувствительный к задержкам трафик, начались работы по созданию системы стандартов QoS для 1Р-сетей.

Сегодня существует две системы стандартов QoS для IP-сетей — IntServ и DiffServ. Первая обеспечивает гарантированное качество обслуживания микропотоков, используя сигнальный протокол RSVP для резервирования ресурсов маршрутизаторов. Недостатком такого подхода является большая нагрузка на магистральные маршрутизаторы, которые должны хранить информацию о состоянии тысяч пользовательских потоков.

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

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

Маршрутизатор часто строится по мультипроцессорной схеме, причем используется симметричное мультипроцессирование, асимметричное мультипроцессирование и их сочетание.

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

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

Вопросы и задания

1. Чем результат фильтрации объявлений маршрутизации отличается от результата фильтрации пользовательского трафика?

2. Какую смысловую нагрузку несет термин «интегрированные» в названии технологии IntServ?

3. Какой параметр можно использовать, чтобы ограничить пульсацию входного потока пакетов, профилируемого по алгоритму ведра маркеров? Варианты ответов:

а) объем маркера;

б) скорость наполнения ведра;

в) интервал поступления маркеров;

г) объем ведра маркеров.

4. Почему для UDP-трафика неприменим механизм RED?

СЗ

IP = 194.100.15.2 Маска = 255.255.255.0 Шлюз по умолчанию =

194.100.15.5 МАС1

IP = 194.100.15.3 Маска = 255.255.255.0 Шлюз по умолчанию =

194.100.15.6 МАС2

IP = 194.100.17.11 Маска = 255.255.255.0 Шлюз по умолчанию = 194.100.17.9 МАСЗ

5. В чем назначение технологии NAT? Варианты ответов:

а) отражение DOS-атак;

б) решение проблемы дефицита адресов в протоколе IPv4;

в) защита внутреннего адресного пространства сети предприятия.

6. Заполните столбец «Назначенный порт» в таблице.

Частный адресПорт отправителяГлобальный адресНазначенный порт 10.0.25.11035193.55.13.79 10.0.25.21035193.55.13.79 10.0.25.21047193.55.13.79

7. Протокол IGMP используется при взаимодействии:

а) маршрутизатора с получателем группового трафика;

б) источника группового трафика с маршрутизатором;

в) маршрутизаторов, передающих групповой трафик.

8. В чем состоит принципиальное отличие протоколов маршрутизации группового вещания плотного режима от соответствующих протоколов разряженного режима?

9. Каково отношение администратора 1Ру6-сети к маскам? Варианты ответов:

а) использует и для объединения подсетей, и для разделения на подсети;

б) использует для разделения на подсети;

в) использует для объединения подсетей;

г) игнорирует как ненужное средство.

Более 800 000 книг и аудиокниг! 📚

Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением

ПОЛУЧИТЬ ПОДАРОК