Компьютерные сети

Еще более гибким является язык фильтров программного маршрутизатора, работающего во многих версиях 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)
Типы сообщений
Содержание сообщений
РАТН-сообщение от источника к приемнику
Спецификация трафика источника
Спецификация трафика источника

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