авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 18 | 19 || 21 | 22 |   ...   | 30 |

«С^ППТЕР В. Олифер Н. Олифер Компьютерные сети Принципы, технологии, протоколы 4-е издание РЕКОМЕНДОВАНО ...»

-- [ Страница 20 ] --

2 Протокол недостижим 0 Эхо-ответ Порт недостижим А 4 Ошибка фрагментации Узел назначения недостижим / 5 Ошибка в маршруте источника 6 Сеть назначения не известна Подавление источника 7 Узел назначения не известен Перенаправление маршрута 5 VI 8 Узел-источник изолирован 9 Административный запрет Эхо-запрос Истечение времени диаграммы 11 V ? сообщение-запрос Проблема с параметрами пакета СТ) сообщение-ответ Запрос отметки времени 13 7 сообщение-ошибка / CD' Ответ отметки времени / Запрос маски \х' 18 Ответ маски Рис. 17.23. Типы и коды ICMP-сообщений Сообщения, относящиеся к группе сообщений об ошибках, конкретизируются уточняющим кодом. На рисунке показан фрагмент таблицы кодов для сообщения об ошибке недостижи мости узла назначения, имеющей тип 3. Из таблицы мы видим, что это сообщение может быть вызвано различными причинами, такими как неверный адрес сети или узла (код О или 1), отсутствием на конечном узле-адресате необходимого протокола прикладного уровня (код 2 — «протокол недостижим») или открытого порта U D P / T C P (код 3 — «порт недостижим»). Узел (или сеть) назначения может быть также недостижим по причине временной неработоспособности аппаратуры или из-за того, что маршрутизатор не имеет данных о пути к сети назначения. Всего таблица содержит 15 кодов. Аналогичные таблицы существуют и для других типов сообщений об ошибках.

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

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

594 Глава 17. Базовые протоколы TCP/IP •1 байт—•—1 байт—•гЧ- 2 байта • Контрольная Тип = 3 Код = - 1 5 сумма о ш о Не используется Поле данных Заголовок + 8 первых байт поля денных, вызвавшего ошибку IP-пакета Рис. 1 7. 2 4. Формат ЮМР-сообщения об ошибке недостижимости узла назначения Помимо причины ошибки, указанной в заголовке (в полях типа и кода), дополнительная диагностическая информация передается в поле данных ICMP-сообщения. Именно туда помещается заголовок IP и первые 8 байт данных того IP-пакета, который вызвал ошибку.

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

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

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

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

Затем traceroute посылает следующий IP-пакет, но теперь со значением TTL, равным 2.

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

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

1 311 ms 290 ms 261 ms 144.206.192. 2 281 ms 300 ms 271 ms 194.85.73. 3 2023 ms 290 ms 311 ms moscow-m9-2-S5.re1com.eu.net [193.124.254.37] 4 290 ms 261 ms 280 ms MSK-M9-13.Relcom.EU.net [ 1 9 3. 1 2 5. 1 5. 1 3 ] 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 [ 1 9 3. 1 2 4. 2 5 4. 7 8 ] 7 311 ms 300 ms 300 ms Hssill-O.GWl.STK2.ALTER.NET [146.188.33.125] 8 311 ms 330 ms 291 ms 421.ATM6-0-0.CR2.STK2.A1ter.Net [ 1 4 6. 1 8 8. 5. 7 3 ] 9 360 ms 331 ms 330 ms 219.Hssi4-0.CR2.LN01.A1ter.Net [ 1 4 6. 1 8 8. 2. 2 1 3 ] 10 351 ms 330 ms 331 ms 4 1 2. A t m 5 - 0. B R l. L N D l. A l t e r. n e t [146.188.3.205] 11 420 ms 461 ms 420 ms 167.ATM8-0-0.CR1.ATL1.A1ter.Net [ 1 3 7. 3 9. 6 9. 1 8 2 ] 12 461 ms 441 ms 440 ms 311.ATM12-0-0.BR1.ATL1.A1ter.Net [ 1 3 7. 3 9. 2 1. 7 3 ] 13 451 ms 410 ms 431 ms a t l a n t a l - b r l. b b n p l a n e t. n e t [ 4. 0. 2. 1 4 1 ] 14 420 ms 411 ms 410 ms v i e n n a l - b r 2. b b n p l a n e t. n e t [4.0.3-.154] 15 411 ms 430 ms 2514 ms v i e n n a l - n b r 3. b b n p l a n e t. n e t [4.0.3.150] 16 430 ms 421 ms 441 ms v i e n n a l - n b r 2. b b n p l a n e t. n e t [ 4. 0. 5. 4 5 ] 17 431 ms 451 ms 420 ms c a m b r i d g e l - b r l. b b n p l a n e t. n e t [ 4. 0. 5. 4 2 ] 18 450 ms 461 ms 441 M С c a m b r i d g e l - c r l 4. b b n p l a n e t. n e t [4.0.3.94] 19 451 M С 461 M С 460 M С a t t b c s t o l l. b b n p l a n e t. n e t [206.34.99.38] | 20 501 M С 460 M С 481 M С s h u t d o w n. d s. i n t e r n i c. n e t [198.49.45.29] Последовательность строк соответствует последовательности маршрутизаторов, образую щих маршрут к заданному узлу Первое число в строке — число хопов до соответствующего маршрутизатора. Утилита traceroute тестирует каждый маршрутизатор трижды, поэтому следующие три числа в строке — это значения RTT, вычисленные путем посылки трех па кетов, время жизни которых истекло на этом маршрутизаторе. Если ответ от какого-либо маршрутизатора не приходит за заданное время, то вместо времени на экране печатается звездочка (*).

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

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

596 Глава 17. Базовые протоколы TCP/IP Утилита ping А сейчас давайте рассмотрим представителей другой группы ICMP-сообщений — эхо запросы и эхо-ответы и поговорим об использовании этих сообщений в известной утилите ping.

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

Формат эхо-запроса и эхо-ответа показан на рис. 17.25. Поле типа для эхо-ответа рав но 0, для эхо-запроса — 8;

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

1 байт—• •—1 байт—• 2 байта И Контрольная Код = Тип = 0/8 сумма Идентификатор Порядковый запроса номер Поле данных Э хо-данные запроса/ответа Рис. 1 7. 2 5. Формат ICMP-сообщений типа эхо-запрос и эхо-ответ Поля идентификатора запроса и порядкового номера используются одинаковым об разом всеми сообщениями типа запрос-ответ. Посылая запрос, приложение помещает в эти два поля информацию, которая предназначена для последующего встраивания ее в соответствующий ответ. Сообщение-ответ копирует значения этих полей в свои поля того же назначения. Когда ответ возвращается в пункт отправки сообщения-запроса, то на основании идентификатора он может «найти и опознать» приложение, пославшее за прос. А порядковый номер используется приложением, чтобы связать полученный ответ с соответствующим запросом (учитывая, что одно приложение может выдать несколько однотипных запросов).

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

Выводы # ping s e r v e r l. c i t m g u. r u Pinging s e r v e r l. c i t m g u. r u [ 1 9 3. 1 0 7. 2. 2 0 0 ] w i t h 64 bytes of data:

Reply from 193.107.2.200 bytes=64 time=256ms TTL= Reply from 193.107.2.200 bytes=64 time=310ms TTL= Reply from 193.107.2.200 bytes=64 time=260ms TTL= Reply from 193.107.2.200 bytes=64 time=146ms TTL= Из приведенной распечатки видно, что в ответ на тестирующие запросы, посланные узлу serverl.mgu.ru, было получено 4 эхо-ответа. Длина каждого сообщения составляет 64 байта.

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

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

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

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

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

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

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

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

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

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

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

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

598 Глава 17. Базовые протоколы TCP/IP Вопросы и задания 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, что позволило повысить пропускную способность сети з счет сокращения объема работы, выполняемой маршрутизаторами.

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

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

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

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

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

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

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

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

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

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

• номер порта T C P / U D P (то есть тип протокола прикладного уровня).

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

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

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

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

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

Наиболее простым является стандартный список доступа;

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

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

a c c e s s - l i s t номер_списка_доступа { deny | permit } ( адрес_источника [ метасимволы_источника ] | any) Стандартный список доступа определяет два действия с пакетом, который удовлетворяет описанному в фильтре условию: отбросить (deny) или передать для стандартной обра ботки в соответствии с таблицей маршрутизации (permi t). Условием выбора того или иного действия в стандартном списке доступа является совпадение IP-адреса источника пакета с адресом источника, заданным в списке. Совпадение проверяется в том же стиле, что и при проверке таблицы маршрутизации, при этом метасимволы являются аналогом маски, но в несколько модифицированном виде. Двоичный нуль в поле метасимволов ис точника означает, что требуется совпадение значения этого разряда в адресе пришедшего пакета и в адресе, заданном в списке доступа. Двоичная единица означает, что совпадения в этом разряде не требуется. Практически, если вы хотите задать условие для всех адресов некоторой подсети, то должны использовать инвертированное значение маски этой под сети. Параметр any означает любое значение адреса — это просто более понятная и краткая форма записи значения 255.255.255.255 в поле метасимволов источника.

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

a c c e s s - l i s t 1 deny 192.78.46.0 0.0.0. Здесь:

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

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

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

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

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

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

: access-list 1 permit 192.78.46.12 0. 0. 0. access-list 1 deny 192.78.46.0 0. 0. 0. 2 5 access-list 1 permit any Условия списка доступа проверяются по очереди, если какое-либо из них дает совпадение, то выполняется действие permit или deny, определенное в этом условии. После этого остальные условия списка уже не проверяются. Считается по умолчанию, что в конце каждого списка имеется неявное условие вида:

I [access-list 1 deny any] Однако, если вам все же требуется пропускать все пакеты, не определенные явно в усло виях, необходимо добавить в последней строке условие:

Г access-list 1 permit any Список доступа можно применять к любому интерфейсу маршрутизатора и в любом на правлении: если список применяется с ключевым словом i п, то он действует на входящие винтерфейс пакеты, а если с ключевым словом out — на выходящие. Например, написан 602 Глава 18. Дополнительные функции маршрутизаторов IP-сетей ный нами список доступа 1 можно применить к некоторому интерфейсу для обработки входящего трафика, используя следующую команду:

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

a c c e s s - l i s t номер_списка_доступа f deny | permit I p r o t o c o l | ключевое_слово_протокола I ( адрес_источника [ метасимволы_источника ] ] [ порт_источника ] | any ) [ адрес_приемника [ метасимволы_приемника ] ] [ порт_приемника ] Пользуясь расширенными списками доступа, можно запретить прохождение во внутрен нюю сеть предприятия FTP-пакетов. Как известно, служба FTP использует для приема запросов от клиентов протокол TCP с хорошо известным портом 21. Для этого в список доступа нужно включить условие:

a c c e s s - l i s t 102 deny TCP any 21 any Затем можно применить его к интерфейсу маршрутизатора, к которому подключена вну тренняя сеть, с ключевым словом out.

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

a c c e s s - l i s t 101 deny ICMP any 192.78.46.8 0. 0. 0. 0 eq Как видно из условия, его синтаксис для протокола ICMP несколько отличается от обще го синтаксиса расширенных списков доступа. Параметр eq 8 означает, что запрещается передача ICMP-сообщений типа 8, соответствующего эхо-запросам, с помощью которых функционирует утилита ping.

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

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

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

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

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

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

Пусть, например, маршрутизаторы Cisco должны ограничить распространение маршрут ных объявлений о какой-нибудь сети. Для этого нужно включить описание данной сети в стандартный список доступа, а затем применить к интерфейсу специальную команду сключевым словом d i s t r i b u t e - ! 1st (вместо access - group, как в случае фильтрации пользовательского трафика).

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

access-list 2 deny 194.12.34.0 0.0.0. access-list 2 deny 132.7.0.0 0.0.255. access-Hst 2 permit any После этого достаточно применить его к интерфейсу с помощью команды distribute-1 i s t 2 out serial Стандарты QoS в IP-сетях Технологии стека T C P / I P были разработаны для эластичного трафика, который доста точно терпим к задержкам и вариациям задержек пакетов. Поэтому основное внимание разработчиков протоколов TCP/IP было сосредоточено на обеспечении надежной передачи трафика с помощью TCP. Тем не менее для борьбы с перегрузками на медленных линиях доступа в IP-маршрутизаторы со временем были встроены многие механизмы QoS, в том числе механизмы приоритетных и взвешенных очередей, профилирования трафика и об ратной связи. Однако эти механизмы использовались каждым сетевым администратором по своему усмотрению, без какой-либо стройной системы. И только в середине 90-х годов начались работы по созданию стандартов QoS для IP-сетей, на основе которых можно было бы создать систему поддержки параметров QoS в масштабах составной сети и даже Интернета.

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

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

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

604 Глава 18. Дополнительные функции маршрутизаторов IP-сетей Обе системы опираются на все базовые элементы основанной на резервировании схемы поддержания параметров QoS, к которым относятся:

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

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

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

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

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

Модели качества обслуживания IntServ и DiffServ Направление IntServ начало разрабатываться в IETF еще в начале 90-х годов и было пер вым направлением, в рамках которого проблема обеспечения параметров QoS в сетях TCP/ 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). Затем каждый маршрутизатор сети обслужива ет классы трафика дифференцированно в соответствии с произведенной маркировкой, вы деляя каждому классу определенное количество ресурсов. Резервирование ресурсов марш рутизаторов производится статически, чаще всего вручную администратором сети. Роль сигнального протокола играют метки принадлежности пакетов к тому или иному классу.

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

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

Ведутся также работы по комбинированному применению технологий IntServ и DiffServ.

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

Обе технологии (IntServ и DiffServ) опираются на одни и те же базовые механизмы QoS.

В частности, b IP-маршрутизаторах для профилирования и формирования трафика при меняется алгоритм ведра маркеров.

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

Генератор Рис. 1 8. 1. Алгоритм ведра маркеров 606 Глава 18. Дополнительные функции маршрутизаторов IP-сетей Под маркером в данном случае понимается некий абстрактный объект, носитель «порции»

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

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

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

Сервер также имеет выход, на который он передает пакеты из входной очереди пакетов.

Вход 1 сервера моделирует входной интерфейс маршрутизатора, а выход — выходной интерфейс.

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

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

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

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

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

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

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

Случайное раннее обнаружение Механизм профилирования TCP-трафика, названный случайным ранним обнаружением (Random Early Detection, RED), разработан сообществом Интернета для предотвращения пере грузок на магистралях Интернета.

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

Вероятность отбрасывания пакетов Рис. 1 8. 2. Вероятность отбрасывания пакетов алгоритмом RED 608 Глава 18. Дополнительные функции маршрутизаторов IP-сетей В качестве показателя перегрузки используется вычисляемое среднее значение длины очереди пакетов, относящейся к определенному ТСР-сеансу.

ПРИМЕЧАНИЕ Заметим, что для UDP-трафика механизм RED неприменим, так как протокол U D P работает без установления логического соединения и, следовательно, потерь пакетов не замечает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

В отличие от потока в классах трафика пакеты не различаются в зависимости от их марш рутов;

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

Обычно в сети DiffServ поддерживается дифференцированное обслуживание небольшого количество классов трафика, например двух (чувствительного к задержкам и эластично го) или трех (к первым двум прибавляется класс, требующий гарантированной доставки I пактов с определенным минимумом скорости трафика). Небольшое количество классов I определяет масштабируемость этой модели, так как маршрутизаторы не должны запоми I нать состояния каждого пользовательского потока. Высокая степень масштабирумости I Diffserv обеспечивается также тем, что каждый маршрутизатор самостоятельно принимает I решение о том, как он должен обслуживать тот или иной класс трафика, не согласуя свои 612 Глава 18. Дополнительные функции маршрутизаторов IP-сетей действия с другими маршрутизаторами. Такой подход назван независимым поведением маршрутизаторов (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 1 2 3 4 5 6 К Байт типа Тип сервиса Приоритет сервиса DS-байт DSlCP протокола IPv4 X ;

: N Y Y Этот бит должен Код класса Пока RFC 1122 RFC быть нулевым трафика не используется Поле типа сервиса (TOS) Код класса дифференцированного RFC обслуживания RFC Рис. 18.5. Соответствие битов DS-байта битам поля типа сервиса В настоящее время используются только старшие 6 битов DS-байта, причем только стар шие три из них требуются для определения класса трафика (что дает не более 8-ми различ Стандарты QoS в IP-сетях ных классов). Младший бит (из используемых шести) DS-байта обычно переносит признак IN — индикатор того, что пакет «вышел» из профиля трафика (аналогично признакам DE в технологии Frame Relay и CPL в технологии ATM). Промежуточные два бита обычно описывают различные варианты обслуживания пакетов внутри одного класса трафика.

Маршрутизатор, поддерживающий модель 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-сервиса — обеспечение качества обслуживания, сопоставимого с качеством обслуживания выделенных каналов, поэтому этот сервис называется также сервисом виртуальных выделенных каналов.

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

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

Относительная простота определяет недостатки дифференцированного обслуживания.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внутренняя сеть А | 10.0.1. 10.0.1.4 10.0.2.15 \ \ •ч & 10.0.2. 10.0.1.7 181.230.25. 181.230.25. Сеть 10.0.1.0/24 10.0.2. 181.230.25. / 10.0.2. Сеть 10.0.2.0/ Таблица NAT-отображения Частные Глобальные адреса адреса Внутренняя сеть В 10.0.1.4 181.230.25. 10.0.2.15 181.230.25. 10.0.2.3 181.230.25. 10.0.1. 185.127.125. 185.127.125. 185.127.125. Сеть 10.0.1.0/ Таблица NAT-отображения Частные Глобальные адреса адреса 10.0.1.1 185.127.125. 10.0.1.2 185.127.125. 10.0.1.4 185.127.125. Рис. 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-адрес. Возникает законный во прос, каким образом внешние пакеты, поступающие в ответ на запросы из частной сети, находят узел-отправитель, ведь в поле адреса источника всех пакетов, отправляющихся во внешнюю сеть, помещается один и тот же адрес — адрес внешнего интерфейса погра ничного маршрутизатора?

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

номер TCP- или UDP-порта отправителя} 620 Глава 18. Дополнительные функции маршрутизаторов IP-сетей ставится в соответствие пара {глобальный IP-адрес внешнего интерфейса;

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

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

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

Внутренняя сеть Сервер telnet 136.56.28. Частный Глобальный Назначенный Порт порт адрес адрес 10.0.1.4 181.230.25.1 181.230.25.1 10.0.2.15 10.0.2.3 1045 181.230.25.1 Рис. 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-сеансы.

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

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

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

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

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

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

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

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

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

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

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

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



Pages:     | 1 |   ...   | 18 | 19 || 21 | 22 |   ...   | 30 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

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